RAG란? 검색 증강 생성의 개념과 작동 방식

**검색 증강 생성(RAG)**은 시스템이 외부 문서 인덱스에서 관련 구절을 검색하고, 언어 모델이 답변을 생성하기 전에 그 구절을 전달하는 방식입니다. 모델은 학습 중에 고정된 가중치에만 의존하지 않고 비공개 정보, 내부 정보 또는 최근에 업데이트된 정보를 이용해 답할 수 있습니다.

일반적인 언어 모델은 지식 기준일까지의 학습 데이터에 포함된 내용만 알고 있습니다. 사용자가 회사 내부 환불 정책, 새로 공개된 API 명세 또는 다섯 분 전에 업데이트된 계정 기록을 물어보면 기본 모델은 기억만으로 답을 알 수 없습니다. RAG는 검색 단계와 생성 단계를 결합해 이 간극을 메웁니다. 먼저 관련 사실을 검색한 다음 검색된 텍스트를 근거로 답변을 생성합니다.

검색 증강 생성이란 무엇인가요?

검색 증강 생성은 정보 검색 시스템과 텍스트 생성 모델을 결합해 질의 시점에 가져온 외부 문서를 바탕으로 출력을 만드는 것을 뜻합니다. 신경망이 모든 사실을 매개변수에 기억하기를 기대하는 대신, RAG는 외부 텍스트 인덱스를 모델이 답변하기 전에 참고할 수 있는 펼쳐진 책처럼 취급합니다.

크게 보면 모든 RAG 워크플로는 두 가지 핵심 단계를 따릅니다.

1. 검색: 사용자가 프롬프트를 입력하면 시스템은 질의를 외부 데이터 저장소에 대한 검색 요청으로 바꾸고 가장 관련성이 높은 텍스트 구절을 가져옵니다. 저장소에는 벡터 데이터베이스, 키워드 검색 인덱스 또는 둘을 결합한 방식이 있습니다.
2. 생성: 시스템이 검색한 구절을 사용자의 원래 질문과 함께 모델의 컨텍스트에 넣으면, 언어 모델이 제공된 구절을 토대로 답변을 생성합니다.

참고 텍스트는 요청마다 동적으로 검색되므로 기반 모델을 다시 학습시키는 대신 문서 인덱스를 업데이트해 시스템의 지식을 갱신할 수 있습니다. 이 때문에 RAG는 지원 어시스턴트, 내부 문서 검색, 특정 분야의 질의응답 도구를 구축하는 표준적인 방식 중 하나입니다. 팀이 미디어 제작에는 AI Studio Video 같은 전용 워크플로 도구를 쓰고 지식 검색에는 텍스트 API를 사용하는 창작 애플리케이션에서도 활용됩니다.

2020년 RAG 논문은 오늘날의 RAG 방식과 어떻게 달랐나요?

‘검색 증강 생성’이라는 용어는 Patrick Lewis와 동료들의 2020년 논문(arXiv:2005.11401)에서 나왔습니다. 이 논문은 사전 학습된 시퀀스 대 시퀀스 모델과 Wikipedia의 밀집 벡터 인덱스를 결합했습니다. 반면 오늘날 개발자들은 보통 더 단순한 프롬프트 구성 파이프라인을 이 용어로 부릅니다. 두 방식을 모두 이해하면 연구 논문과 엔지니어링 문서에서 ‘RAG’를 조금씩 다르게 설명하는 이유를 알 수 있습니다.

2020년 Lewis 등의 아키텍처

2020년 원 논문과 함께 나온 Meta AI 연구 글에서 저자들은 언어 모델에 두 종류의 메모리가 있다고 설명했습니다.

• 매개변수 메모리: 신경망의 가중치에 저장된 지식으로, 구체적으로는 사전 학습된 BART 시퀀스 대 시퀀스 모델입니다.
• 비매개변수 메모리: Wikipedia 문서의 외부 밀집 벡터 인덱스에 저장된 지식으로, Dense Passage Retrieval(DPR)이라는 신경망 검색기를 사용해 조회합니다.

이 연구에서는 검색기와 생성기를 엔드투엔드로 함께 학습했습니다. 논문은 검색된 구절이 생성에 영향을 미치는 두 가지 방식을 제시했습니다.

• RAG-Sequence: 모델이 동일한 검색 구절을 사용해 전체 출력 시퀀스를 생성합니다.
• RAG-Token: 모델이 생성하는 개별 토큰마다 서로 다른 검색 구절을 활용할 수 있습니다.

논문 표에 보고된 오픈 도메인 질의응답 벤치마크(arXiv:2005.11401)에서 RAG-Sequence는 Natural Questions 벤치마크에서 44.5 Exact Match 점수를 기록했습니다. 이는 연구에서 시험한 매개변수 전용 seq2seq 기준 모델과 검색 후 추출하는 아키텍처를 모두 앞선 결과입니다.

오늘날의 엔지니어링 방식

현대 애플리케이션 개발에서는 검색기와 생성기를 함께 학습시키는 경우가 드뭅니다. 대신 ‘RAG’는 거의 항상 기성 임베딩 모델과 범용 LLM API를 중심으로 구축된 추론 시점 파이프라인을 뜻합니다.

1. 문서를 더 작은 구절인 청크로 나눕니다.
2. 청크를 벡터 임베딩으로 변환해 인덱스에 저장합니다.
3. 질의할 때 가장 잘 맞는 청크를 검색합니다.
4. 필요하면 관련성을 높이기 위해 결과의 순위를 다시 매깁니다.
5. 검색된 텍스트 청크를 프롬프트에 직접 넣고 LLM에 답변을 요청합니다.

2020년의 엔드투엔드 신경망 아키텍처와 오늘날 텍스트를 프롬프트에 넣는 파이프라인은 모두 RAG라고 불립니다. 일상적인 소프트웨어 엔지니어링에서는 검색기를 seq2seq 모델과 함께 학습한다고 명시하지 않는 한 현대적인 파이프라인 방식을 의미합니다.

현대적인 RAG 파이프라인은 단계별로 어떻게 작동하나요?

운영 환경의 RAG 시스템은 작업을 두 가지 별도 워크플로로 나눕니다. 문서를 준비하고 인덱싱하는 오프라인 수집 파이프라인과 사용자가 질문할 때마다 실행되는 온라인 질의 파이프라인입니다. AWS의 검색 증강 생성 안내와 AWS Generative AI Innovation Center의 RAG 가이드 같은 아키텍처 가이드는 이 단계들을 독립적으로 조정할 수 있는 구성 요소로 나눕니다.

1. 수집 파이프라인(데이터 인덱싱)

사용자가 프롬프트를 보내기 전에 시스템은 원본 문서를 검색할 수 있도록 준비해야 합니다.

• 문서 로드 및 정제: PDF, 위키, 데이터베이스 또는 마크다운 파일에서 일반 텍스트와 메타데이터(제목, URL, 타임스탬프, 접근 권한)를 추출하고 깨진 서식이나 반복되는 페이지 요소를 제거합니다.
• 청크 분할: 긴 문서를 작은 구간으로 나누어 전체 매뉴얼 대신 관련 구절만 검색합니다. 청크가 너무 작으면 주변 맥락이 사라지고 내용이 중간에 끊깁니다. 너무 크면 관련 없는 정보가 섞이고 토큰 사용량이 늘어납니다. 경계에 있는 문장의 의미가 사라지지 않도록 인접 청크를 조금 겹치게 만드는 경우가 많습니다.
• 임베딩: 각 청크를 임베딩 모델에 통과시켜 텍스트를 의미를 나타내는 밀집 숫자 벡터로 변환합니다.
• 인덱싱: 벡터를 원문 및 메타데이터 필터와 함께 벡터 데이터베이스나 벡터 유사도와 키워드 일치를 결합하는 하이브리드 검색 엔진(BM25 등)에 저장합니다.

2. 질의 파이프라인(질문에 답하기)

실행 중 사용자가 질문하면 질의 파이프라인이 프롬프트를 구성합니다.

• 질의 처리 및 임베딩: 사용자 입력을 받아 필요하면 명확하게 다시 쓰거나 확장한 다음, 수집 단계에서 사용한 것과 정확히 같은 임베딩 모델로 벡터로 변환합니다.
• 검색: 질의 벡터에 가장 가까운 벡터를 가진 청크를 인덱스에서 검색합니다. 의미 검색과 키워드 일치, 메타데이터 필터링을 함께 쓰는 경우가 많습니다. 예를 들어 현재 사용자가 읽을 권한이 있는 문서로 결과를 제한할 수 있습니다.
• 선택적 재순위화: 처음 찾은 후보 청크를 크로스 인코더 재순위화 모델에 통과시킵니다. 이 모델은 각 구절이 특정 질의에 얼마나 직접적으로 답하는지 평가하고 가장 적합한 결과로 목록을 줄입니다.
• 프롬프트 구성 및 생성: 상위 구절을 사용자 질문과 함께 구조화된 프롬프트 템플릿에 넣고 전체 입력을 LLM에 보낸 다음 생성된 답변을 반환합니다. 출처 메타데이터를 가리키는 인용이 함께 제공되는 경우가 많습니다.

RAG는 긴 컨텍스트 윈도 및 파인튜닝과 어떻게 다른가요?

RAG, 긴 컨텍스트 윈도, 파인튜닝은 모델 맞춤화에서 서로 다른 부분을 해결합니다. 운영 시스템에서는 이들을 상호 배타적인 선택지로 보기보다 함께 사용하는 경우가 많습니다. 적절한 접근법은 변화하는 사실, 단일 세션에서의 폭넓은 이해, 모델 행동의 변화 중 무엇이 필요한지에 따라 달라집니다.

비교 항목	검색 증강 생성(RAG)	긴 컨텍스트 윈도	파인튜닝
주요 목표	크거나 계속 바뀌는 문서 집합에서 질의마다 관련 사실 제공	한 번의 요청으로 모델이 많은 텍스트를 읽게 함	모델의 문체, 어조, 형식 또는 전문 작업 수행 방식 변경
지식 업데이트 방법	외부 인덱스의 문서를 업데이트하거나 교체	프롬프트에 넣는 원본 문서를 교체	새 학습 예제를 수집하고 다시 학습 실행
요청당 토큰 영향	낮음~보통(검색된 청크만 전송)	높음(모든 문서가 프롬프트 입력에 남음)	낮음(지식이나 행동이 모델 가중치에 반영됨)
출처 표기	검색된 특정 청크를 쉽게 인용 가능	가능하지만 방대한 입력에서 위치를 특정하기 어려움	어려움. 가중치는 명시적인 문서 인용을 기록하지 않음
접근 제어	인덱스 메타데이터 필터로 질의마다 적용	프롬프트 구성 전에 필터링 필요	분리가 어려워 가중치의 모든 내용이 어느 사용자에게나 유출될 수 있음

RAG와 긴 컨텍스트 윈도

현대 모델은 큰 컨텍스트 윈도를 지원하므로 검색을 건너뛰고 전체 지식 베이스를 모든 프롬프트에 붙여 넣고 싶을 수 있습니다. 짧은 문서 몇 개라면 이 방법도 잘 작동합니다. 특히 반복되는 접두 부분을 처음부터 다시 처리하지 않도록 프롬프트 캐싱과 이미 채워진 KV cache를 함께 사용하면 더욱 그렇습니다.

하지만 문서 집합이 수천 개 파일로 커지면 모든 내용을 프롬프트에 넣는 방법은 두 가지 벽에 부딪힙니다.

1. 비용과 지연: 매 대화 차례마다 거대한 프롬프트를 보내면 API 비용과 첫 토큰까지의 시간이 늘어납니다. 그래서 선택적 검색은 AI API 비용을 줄이는 방법을 찾을 때 핵심 전략 중 하나입니다.
2. 주의력 저하: 모델은 거대한 프롬프트의 모든 부분에 똑같이 주의를 기울이지 못합니다. 관련 없는 텍스트가 윈도에 쌓이면 정확도가 떨어지는 경우가 많으며, 이를 컨텍스트 부패라고 합니다. RAG는 현재 질문에 중요한 구절만 검색해 프롬프트의 초점을 유지합니다.

RAG와 파인튜닝

파인튜닝은 선별된 예제로 모델의 가중치를 업데이트합니다. 모델이 엄격한 출력 스키마를 따르거나 특정 브랜드의 어조를 사용하거나 분야별 구문을 배우도록 할 때 효과적입니다. 빠르게 바뀌는 사실을 모델에 가르치는 방법으로는 적합하지 않습니다.

2020년 Lewis 등의 논문(arXiv:2005.11401)은 인덱스 ‘핫 스왑’ 실험을 통해 변화하는 사실에 비매개변수 메모리가 중요한 이유를 보여 주었습니다. 저자들은 2016년 십이월의 Wikipedia 덤프와 2018년 십이월의 Wikipedia 덤프를 각각 사용해, 그 사이에 교체된 세계 지도자에 관한 질문으로 모델을 시험했습니다.

• 질문의 연도와 인덱스 연도가 일치할 때 모델은 2016년 인덱스로 2016년 지도자에 관한 질문의 70%, 2018년 인덱스로 2018년 지도자에 관한 질문의 **68%**를 정확히 답했습니다.
• 인덱스가 질문과 일치하지 않을 때 정확도는 12%(2016년 지도자에 2018년 인덱스 사용)와 4%(2018년 지도자에 2016년 인덱스 사용)로 떨어졌습니다.

외부 인덱스를 교체하기만 해도 모델 가중치를 하나도 재학습하지 않고 시스템의 세계에 대한 사실 지식을 업데이트할 수 있었습니다.

RAG는 어디에서 실패하나요?

언어 모델에 검색 기능을 추가하면 비공개 또는 최신 주제에 대한 추측은 줄지만, AI 환각을 없애거나 정확한 답변을 보장하지는 못합니다. RAG 시스템은 여러 구성 요소로 이루어져 있으므로 검색 단계나 생성 단계 어느 쪽에서든 실패할 수 있습니다.

• 검색 누락: 사용자가 원본 문서와 다른 용어로 질문하거나 청크 분할 과정에서 표가 머리글과 분리되면 검색기가 실제 답변이 들어 있는 구절을 찾지 못할 수 있습니다. 올바른 청크가 프롬프트에 도달하지 못하면 모델은 근거 없이 답해야 합니다.
• 잡음이 많거나 오래된 문서: 인덱스의 품질은 그 안에 있는 파일에 달려 있습니다. 지식 베이스에 온보딩 가이드의 2023년 버전과 2026년 버전이 함께 있고 폐기된 버전을 명확히 걸러내지 않으면 검색기가 오래된 지침을 모델에 전달할 수 있습니다.
• 과도한 검색: ‘혹시 몰라서’ 청크 25개를 가져오면 오히려 역효과가 나는 경우가 많습니다. 관련성이 낮은 구절로 프롬프트를 채우면 실제 답변이 희석되고 지연이 늘어나며, 모델이 비슷하지만 맞지 않는 세부사항에 주의를 빼앗기는 컨텍스트 부패가 발생할 수 있습니다.
• 검색된 텍스트를 통한 간접 프롬프트 인젝션: 인덱스가 수신 이메일, 공개 웹페이지 또는 사용자가 제출한 티켓처럼 신뢰할 수 없는 외부 콘텐츠를 수집하면 공격자가 문서에 악의적인 지시를 심을 수 있습니다. 해당 문서가 검색되어 프롬프트에 들어가면 모델의 행동을 가로채는 프롬프트 인젝션 공격이 발생할 수 있습니다.
• 모델의 컨텍스트 무시 또는 오독: 정확히 맞는 구절이 프롬프트에 들어가더라도 생성기는 부정을 잘못 해석하거나 별개의 두 청크를 부정확하게 섞을 수 있습니다. 검색된 구절이 상식과 상충하면 사전 학습에서 얻은 지식을 제공된 텍스트보다 우선할 수도 있습니다.

신뢰할 수 있는 RAG 시스템 구축 체크리스트

RAG 프로토타입을 운영 환경으로 옮길 때 몇 가지 원칙 있는 엔지니어링 습관으로 흔한 실패를 방지할 수 있습니다.

• 인덱스를 최신 상태로 유지하고 중복 제거: 삭제된 문서를 제거하고 대체된 버전을 보관하며 인덱싱된 각 청크에 명확한 타임스탬프와 출처 URL을 붙이는 자동 파이프라인을 구축합니다.
• 더 적게, 더 좋은 결과 검색: 관련성이 낮은 결과 수십 개를 프롬프트에 넣는 대신 하이브리드 검색(벡터 + 키워드)을 메타데이터 필터링 및 재순위화 모델과 결합해 유용한 소수의 구절만 생성기에 전달합니다.
• 신뢰할 수 없는 검색 텍스트와 시스템 지시를 명확히 분리: 검색된 청크를 XML 태그나 레이블이 붙은 문서 블록 같은 명시적인 구조 구분자로 감싸고, 이 블록을 실행 가능한 명령이 아닌 수동적인 참고 데이터로만 취급하도록 시스템 프롬프트에 지시합니다.
• 컨텍스트가 없으면 답변을 삼가도록 지시: 제공된 구절에 질문에 답할 정보가 충분하지 않을 때 모델이 그 사실을 분명히 밝히도록 합니다. 프롬프트 지시가 항상 준수를 보장하지는 않지만, 검색 결과가 없을 때 조용히 추측하는 것보다 명확한 대안을 제공합니다.

자주 묻는 질문

RAG에는 항상 벡터 데이터베이스가 필요한가요?

아니요. 검색 증강 생성에는 모델을 호출하기 전에 관련 텍스트를 가져올 방법만 필요합니다. 벡터 데이터베이스는 의미적 유사성 검색에 널리 쓰이지만, 운영 환경의 많은 RAG 시스템은 기존 키워드 검색 엔진(Elasticsearch의 BM25나 PostgreSQL의 전문 검색 등) 또는 키워드와 벡터 검색을 결합한 하이브리드 검색을 사용합니다.

RAG가 LLM의 환각을 완전히 막을 수 있나요?

아니요. RAG는 참고 텍스트를 프롬프트에 직접 제공하므로 누락되거나 오래된 학습 데이터로 인한 환각을 줄입니다. 하지만 모델이 구절을 잘못 읽거나 서로 관계없는 두 청크의 사실을 잘못 결합하거나, 검색기가 관련 없는 문서를 가져왔을 때 답을 추측할 수는 있습니다.

회사 내부 문서에는 RAG와 파인튜닝 중 무엇을 사용해야 하나요?

시간에 따라 바뀌는 내부 문서에 관해 모델이 질문에 답하게 하려면 RAG부터 시작하세요. RAG를 사용하면 인덱스의 파일을 즉시 추가, 수정, 삭제하고 질의 시 사용자별 접근 권한을 적용할 수 있습니다. 파인튜닝은 일관된 형식, 어조 또는 작업 흐름을 가르치는 데 더 적합합니다.

출처

• Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — arXiv:2005.11401
• Meta AI Research Blog — Retrieval-Augmented Generation: Streamlining the creation of intelligent natural language processing models
• AWS Prescriptive Guidance — Understanding LLMs and RAG
• AWS Machine Learning Blog — From RAG to fabric: Lessons learned from building real-world RAGs at GenAIIC – Part 1