[바미] AI도 구글 검색을 한다면 어떨까요?

논문 : Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
저자: Patrick Lewis et al. (Facebook AI Research, UCL, NYU)
arXiv: 2005.11401
| 2020년 발표

 

LLM은 왜 어제 일을 모를까?

GPT나 BART 같은 대형 언어 모델(LLM)은 인상적인 성능을 보여주지만 실무에서 쓰다 보면 아래에 보이는 불편한 진실과 마주치게 됩니다.

모델이 학습 당시에 없던 정보는 모릅니다.

 

아니 더 정확히 말해보자면 LLM은 파라미터 안에 지식을 녹여 넣는 방식으로 학습합니다.

즉 모든 지식이 파라미터에 암묵적으로 압축되어 있습니다. 이 구조에서 오는 한계는 세 가지입니다

1. 지식 업데이트 불가 - 세상이 바뀌어도 모델의 파라미터를 재학습하지 않으면 반영이 안 됩니다.
2. Hallucination - 모르는 것을 마치 아는 것처럼 그럴듯하게 생성해버립니다.
3. 근거 불투명 - 왜 이렇게 답했는지 출처 추적이 사실상 불가능합니다.

2020년, Facebook AI Research 팀은 이 문제를 정면 돌파하는 아이디어를 들고 나왔습니다. 바로 RAG(Retrieval-Augmented Generation) 입니다.

 

RAG는 왜 찾아보는 방식을 택했나

RAG의 철학은 생각보다 단순합니다.

모델이 모든 걸 외울 필요 없습니다. 필요할 때 찾아보면 됩니다.

인간이 시험을 볼 때는 머릿속 기억만 쓰지만 실제 업무를 할 때는 구글 검색, 문서 참조, 데이터베이스 조회를 병행합니다.

RAG는 이 직관을 그대로 모델에 적용합니다.

 

구분	종류	설명
파라메트릭 메모리	BART (seq2seq 생성 모델)	파라미터에 녹아있는 언어 지식
비파라메트릭 메모리	Wikipedia 밀집 벡터 인덱스	언제든 수정·교체 가능한 외부 문서

 

RAG는 이 두 가지를 확률적으로 결합하여 end-to-end로 학습합니다.

 

RAG 모델 구조

전체 파이프라인

RAG는 크게 두 단계로 동작합니다. 먼저 Retriever가 입력 쿼리를 받아 관련 문서를 검색하고, 그 문서를 Generator에 넘겨 최종 답변을 생성합니다. 두 컴포넌트는 end-to-end로 함께 학습됩니다.

      입력 x (질문 또는 쿼리)
              │
              ▼
┌─────────────────────────────┐
│  Retriever (p η)          │
│  - Query Encoder (BERTq)  │
│  - Document Index (FAISS) │
│  → Top-K 문서 z 반환       │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│  Generator (p θ)         │
│  - BART-large            │
│  - 입력: [x ; z] concat   │
│  → 출력 y 생성             │
└─────────────────────────────┘

 

Retriever - DPR (Dense Passage Retrieval)

검색 컴포넌트는 DPR 기반의 Bi-Encoder 구조입니다.

pη(z|x) ∝ exp( d(z)ᵀ · q(x) )

d(z) = BERTd(z)   ← 문서 인코더
q(x) = BERTq(x)   ← 쿼리 인코더

 

동작 방식은 다음과 같습니다.

입력으로 들어온 질문(쿼리)과 검색 대상 문서를 각각 별도의 BERT 모델로 벡터로 변환합니다. 이렇게 변환된 두 벡터의 내적(Inner Product) 값을 계산하는데 값이 클수록 질문과 문서가 의미적으로 가깝다고 판단합니다.

키워드가 똑같이 없어도 의미가 비슷한 문서를 찾아낼 수 있다는 게 기존 키워드 검색 방식과의 핵심 차이죠.

그런데 Wikipedia 전체에서 가장 유사한 문서를 찾으려면 수천만 개의 벡터를 전부 비교해야 합니다. 이 문제를 MIPS(Maximum Inner Product Search), 즉 내적 값이 가장 큰 벡터를 찾는 문제라고 부릅니다.

이를 효율적으로 풀기 위해 FAISS 라이브러리를 사용하는데 FAISS는 모든 벡터를 다 비교하지 않고도 가장 유사한 문서를 sub-linear 시간, 즉 데이터 크기보다 훨씬 빠르게 찾아줍니다.

실제 규모를 보면 상당합니다. Wikipedia 전체 문서를 100단어 단위로 잘라 약 2,100만 개의 청크로 만들고, 각 청크를 벡터로 변환하여 FAISS 인덱스에 저장합니다. 이 인덱스 전체를 CPU 메모리에 올려두는 데 약 100GB 가 필요하죠.

 

 

💡핵심 구현 포인트: 훈련 중 문서 인코더(BERTd)는 고정하고, 쿼리 인코더(BERTq)와 BART 생성기만 파인튜닝합니다. 
문서 인덱스를 매 스텝마다 갱신하는 REALM 방식보다 훨씬 효율적입니다.

 

Generator: BART-large

생성기는 4억 파라미터 규모의 BART-large를 사용합니다. BART는 입력 텍스트를 인코더로 읽고, 디코더로 새로운 텍스트를 생성하는 seq2seq 구조입니다. RAG에서는 Retriever가 찾아온 문서 z와 원래 질문 x를 단순히 이어붙여(concatenation) BART의 입력으로 넣습니다.

💡 seq2seq(sequence-to-sequence)란? 텍스트를 입력받아 텍스트를 출력하는 구조입니다. 인코더가 입력 문장 전체를 읽어 의미를 압축하고, 디코더가 그 압축된 정보를 바탕으로 출력 문장을 한 토큰씩 생성합니다.
번역("안녕하세요" → "Hello"), 요약, QA 등 입출력이 모두 텍스트인 태스크에 폭넓게 쓰입니다. RAG에서는 Retriever가 찾아온 문서 z와 원래 질문 x를 단순히 이어붙여(concatenation) BART의 입력으로 넣습니다.

 

input = "question: {x}  context: {z}"

 

구조는 단순하지만 효과는 강력합니다. BART가 질문과 문서를 함께 읽으면서 문서에 없는 내용은 자신의 파라미터에 저장된 언어 지식으로 보완하고, 문서에 있는 내용은 그대로 활용해 답변을 생성합니다.

 

RAG-Sequence vs RAG-Token

만약 Retriever가 Top-K개의 문서를 가져오면 Generator는 이 문서들을 어떻게 활용해서 최종 답변을 만들까요? 우리가 살펴보고 있는 논문은 두 가지 방식을 제안합니다.

 

1. RAG-Sequence: 문서 하나로 답변 전체를 생성

P_RAG-Seq(y|x) ≈ Σ_{z ∈ top-k} pη(z|x) · ∏ᵢ pθ(yᵢ|x, z, y₁:ᵢ₋₁)

 

Top-K개의 문서 각각에 대해 답변을 완성한 뒤, 각 문서의 검색 확률을 가중치로 삼아 최종 답변을 선택합니다. 

하나의 문서가 답변 전체를 책임지는 방식이기 때문에, 단일 출처로 충분히 답할 수 있는 단답형 QA나 사실 확인 태스크에 적합합니다.

 

2. RAG-Token: 토큰마다 다른 문서를 참조해서 생성

P_RAG-Token(y|x) ≈ ∏ᵢ Σ_{z ∈ top-k} pη(z|x) · pθ(yᵢ|x, z, y₁:ᵢ₋₁)

 

답변의 각 토큰을 생성할 때마다 Top-K 문서 전체를 고려합니다. 예를 들어 '헤밍웨이'에 대한 Jeopardy 문제를 만들 때

'태양은 다시 떠오른다'는 부분은 문서 A를 참조하고, '무기여 잘 있거라'는 부분은 문서 B를 참조하는 식입니다.

여러 출처의 정보를 하나의 답변에 자연스럽게 녹여야 하는 긴 형태의 생성 태스크에 유리합니다.

검색 방법을 따로 알려주지 않아도 됩니다

RAG에서 가장 흥미로운 부분 중 하나는 학습 방식입니다. 보통 검색 시스템을 학습시키려면 '이 질문에는 이 문서가 정답'이라는 식의 레이블이 필요합니다. 그런데 RAG는 "어떤 문서를 검색해야 한다"는 직접적인 supervision 없이 retriever와 generator를 함께 학습합니다.

 

어떻게 가능할까요? 목적 함수는 단순히 정답 y의 negative marginal log-likelihood를 최소화하는 것입니다

L = Σⱼ -log p(yⱼ|xⱼ)

 

쉽게 말해보자면 정답을 잘 맞히도록 이라는 목표 하나만 줍니다. 이 loss가 역전파될 때 generator는 '어떤 문서가 있어야 정답을 잘 생성할 수 있는지'를 gradient로 retriever에게 전달합니다. retriever는 그 신호를 받아 '좋은 문서를 찾는 방향'으로 쿼리 인코더를 자동으로 업데이트합니다.

 

결과적으로 retriever와 generator가 서로 영향을 주고받으며 함께 발전하는 구조입니다. 별도의 검색 레이블 없이도 태스크 성능만으로 retriever가 점점 더 유용한 문서를 찾도록 학습되는 것이죠.

 

단, 한 가지 설계 선택이 있습니다. 문서 인코더(BERTd)는 학습 중 고정하고, 쿼리 인코더(BERTq)만 업데이트합니다. 문서 인코더까지 학습시키면 인덱스 전체를 매 스텝마다 다시 만들어야 하는데 2,100만 개의 문서를 매번 다시 인코딩하는 건 현실적으로 너무 비쌉니다. 쿼리 인코더만 업데이트해도 충분한 성능이 나온다는 것이 논문의 결론입니다.

실험 결과 - 규모보다 구조가 중요하다.

Open-Domain QA

4개의 공개 QA 벤치마크에서 당시 최고 성능 모델들과 비교한 결과입니다. EM(Exact Match)은 정답과 완전히 일치하는 비율을 의미합니다.

 

모델	NQ (EM)	TQA (EM)	WQ (EM)	CT (EM)
T5-11B (Closed Book)	34.5	50.1	37.4	-
DPR (Open Book)	41.5	57.9	41.1	50.6
RAG-Sequence	44.5	68.0	45.2	52.2

 

위 결과에서 눈에 띄는 점이 두 가지 있습니다.

첫째, 파라미터 효율입니다. T5-11B는 당시 모델을 키우면 성능이 오른다.는 흐름을 대표하는 110억 파라미터짜리 모델입니다. RAG는 그 1/17 수준인 6.26억 파라미터로 이를 전 벤치마크에서 앞질렀습니다. 무작정 모델을 키우는 것보다 구조적 설계가 더 중요할 수 있다는 것을 보여준 결과입니다.

둘째, 추출 기반 모델의 한계를 넘었습니다. 기존 Open Book 방식은 검색된 문서에서 답을 직접 뽑아내는 방식이라 문서에 정답이 없으면 무조건 틀립니다. 반면 RAG는 검색된 문서에 정답이 없는 경우에도 11.8% 정확도를 기록했습니다. BART의 파라메트릭 메모리, 즉 모델이 학습 중 쌓은 언어 지식이 보완재로 작동한 덕분입니다.

생성 다양성 (Diversity)

모델	검색 기반 질의응답 (MSMARCO)	퀴즈 질문 생성 (Jeopardy QGen)
BART	70.7%	32.4%
RAG-Token	77.8%	46.8%
RAG-Sequence	83.5%	53.8%

 

이 지표는 생성된 텍스트에서 3단어 조합이 얼마나 다양하게 나오는지를 측정합니다. BART는 비슷한 표현을 반복하는 경향이 있는 반면, RAG는 여러 문서에서 다양한 정보를 가져오기 때문에 자연스럽게 더 풍부하고 구체적인 텍스트를 생성합니다. 

별도의 다양성 촉진 기법 없이도 이런 결과가 나왔다는 점이 인상적입니다.

 

Human Evaluation (Jeopardy 질문 생성)

모델	사실성(Factuality)	구체성(Specificity)
BART가 더 좋음	7.1%	16.8%
RAG가 더 좋음	42.7%	37.4%

 

자동 지표만으로는 부족할 수 있어 사람이 직접 452쌍의 생성 결과를 비교 평가했습니다. 평가자들은 두 모델이 생성한 질문을 보고 어느 쪽이 더 사실에 부합하고 구체적인지를 판단했습니다. 사실성 기준에서 RAG가 더 낫다는 응답이 BART보다 6배 가까이 높았고, 구체성에서도 2배 이상 차이가 났습니다. 자동 평가와 사람 평가 모두에서 RAG의 우위가 일관되게 확인된 셈입니다.

재학습 없이 지식을 바꿀 수 있다면

RAG의 가장 실용적인 장점 중 하나는 모델을 다시 학습시키지 않아도 지식을 업데이트할 수 있다는 점입니다. 

비파라메트릭 메모리, 즉 문서 인덱스만 교체하면 됩니다.

 

이게 왜 중요할까요? T5나 BART 같은 순수 파라메트릭 모델은 지식이 파라미터 안에 고정되어 있습니다. 세상이 바뀌면 수억 개의 파라미터를 다시 학습시켜야 하는데 이는 시간과 비용이 엄청납니다. 반면 RAG는 외부 문서 인덱스를 통째로 교체하는 것만으로 모델이 참조하는 지식 전체를 바꿀 수 있습니다.

 

논문에서는 이를 실제로 검증하기 위해 2016년 Wikipedia 인덱스와 2018년 인덱스를 교체하는 실험을 진행했습니다.

'Who is the President of Peru?' 같은 질문을 던지며 인덱스와 정답 기준 연도가 일치할 때와 불일치할 때의 정확도를 비교했습니다.

 

"Who is the President of Peru?" 쿼리 예시

2016 인덱스 + 2016 리더 → 70% 정확  (일치)
2018 인덱스 + 2018 리더 → 68% 정확  (일치)
2018 인덱스 + 2016 리더 → 12% 정확  (불일치)
2016 인덱스 + 2018 리더 →  4% 정확  (불일치)

 

인덱스와 정답 연도가 맞을 때는 약 70%의 정확도를 보이지만 엇갈리면 4~12%로 급락합니다. 모델이 실제로 인덱스에 담긴 지식을 기반으로 답하고 있다는 증거입니다. 인덱스를 바꾸면 모델의 답변도 바뀐다는 것이 명확하게 실증된 셈인거죠.

실무적으로 이 특성은 매우 유용한데 사내 문서가 업데이트되었다면 인덱스만 새로 빌드하면 되고, 특정 도메인에 특화된 지식이 필요하다면 그 도메인의 문서로 인덱스를 교체하면 됩니다. 모델 재학습이 필요없어요.

지금도 RAG가 중요한 이유

2020년에 제안된 RAG가 2026년 현재에도 LLM 시스템의 표준 아키텍처로 자리잡은 이유는 무엇일까요? 이유는 아래와 같습니다.

1. LLM의 구조적 한계는 여전히 유효합니다

모델이 아무리 커져도 파라미터에 세상의 모든 최신 지식을 담는 것은 불가능에 가깝습니다. 특히 매일 바뀌는 뉴스, 분기마다 업데이트되는 사내 문서, 개정되는 법률 조항 같은 정보는 재학습 없이는 반영이 안 됩니다. RAG는 이런 도메인 특화 지식을 인덱스로 관리하고 필요할 때 꺼내 쓰는 방식이라, 지식 업데이트 비용이 훨씬 낮습니다.

2. LangChain, LlamaIndex의 기술적 근간

오늘날 개발자들이 RAG 시스템을 구축할 때 많이 쓰는 LangChain, LlamaIndex 같은 프레임워크의 핵심 아이디어가 이 논문에서 출발했습니다. 

문서를 청크로 나누고 → 벡터로 변환하고 → 유사도 검색으로 관련 청크를 찾아 → LLM에 함께 전달한다.는 흐름이 그대로입니다. RAG 논문을 이해하면 이 도구들의 동작 원리가 훨씬 명확하게 보입니다.

3. 레이블 없이도 검색을 학습할 수 있습니다

실무에서 이 질문엔 이 문서가 정답이라는 검색 레이블을 일일이 만드는 것은 매우 비쌉니다.

RAG는 정답 텍스트만 있으면 retriever가 알아서 좋은 문서를 찾도록 학습되기 때문에 별도의 검색 레이블 없이도 파이프라인 전체를 학습시킬 수 있습니다. 레이블링 리소스가 부족한 현실적인 환경에서 큰 장점입니다.

4. 모델이 왜 그렇게 답했는지 추적할 수 있습니다

순수 파라메트릭 모델은 왜 그런 답을 생성했는지 알기 어렵습니다. 반면 RAG는 어떤 문서를 검색해서 이 답을 만들었는지에 대한 출처를 함께 제공할 수 있습니다. 의료, 법률, 금융처럼 답변의 근거가 중요한 도메인이나, 기업 환경에서 AI 답변의 신뢰성을 요구하는 경우에 이 해석 가능성은 단순한 부가 기능이 아니라 필수 조건이 됩니다.

마치며

RAG는 더 큰 모델이라는 단순한 답 대신 아키텍처적 혁신으로 지식 집약적 NLP의 한계를 극복했습니다. 파라미터를 11B에서 0.6B로 줄이면서도 성능을 앞질렀다는 사실은 무작정 모델을 키우는 것보다 올바른 설계가 더 중요할 수 있다는 것을 보여주는 반증이기도 합니다.

LLM을 실제 프로덕트에 붙여보려는 개발자라면 RAG 원논문을 한 번쯤 직접 읽어볼 것을 권합니다. 오늘날 수많은 RAG 튜토리얼의 뿌리가 거기에 있습니다.