지식 집약적 NLP 작업을 위한 검색 증강 생성(RAG)

Lewis 등의 "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks"(NeurIPS 2020)는 아마도 오늘날 프로덕션 AI 시스템이 설계되는 방식에 가장 큰 영향을 미친 단일 논문일 것입니다. 발표된 지 5년이 지났음에도 불구하고, 이 논문은 여전히 거의 모든 문서 기반 언어 시스템의 성능을 측정하는 기준점으로 남아 있습니다. 제가 지금 이 논문을 읽는 이유는 원장 QA부터 이상 징후 설명에 이르기까지 Bean Labs의 백로그에 있는 모든 작업이 결국 검색 문제에 직면하게 되기 때문이며, 후속 모델로 넘어가기 전에 독창적인 설계 결정을 명확히 이해하고 싶기 때문입니다.

논문 소개

RAG가 해결하고자 하는 핵심 문제는 사전 학습된 언어 모델이 학습 시점에 가중치에 지식을 고착시켜버려, 재학습 없이는 해당 지식을 수정하거나 업데이트하는 것이 불가능하고 불투명하다는 점입니다. Lewis 등은 하이브리드 아키텍처를 제안합니다. 즉, 파라미터형 메모리(생성기 역할을 하는 BART-large)와 비파라미터형 메모리(2,100만 개의 위키피디아 구절에 대한 밀집 FAISS 인덱스)를 결합하고, 이를 밀집 구절 검색(DPR, Karpukhin et al. 2020) 기반의 학습된 검색기로 연결하는 방식입니다. 추론 시 모델은 상위 K개의 관련 구절을 검색한 다음, 이를 종합하여 최종 출력을 생성합니다.

논문은 두 가지 변형을 소개합니다. RAG-Sequence는 한 번 검색하여 생성된 전체 시퀀스에 대해 동일한 문서 세트를 사용하며, 이는 더 일관성이 있지만 적응력은 떨어집니다. RAG-Token은 모델이 각 생성 단계마다 다른 검색 문서를 참조할 수 있게 하여 문장 중간에 여러 소스의 정보를 합성할 수 있도록 합니다. 두 변형 모두 미세 조정 중에 검색기와 생성기를 공동으로 학습시키지만, 학습 중 FAISS 인덱스를 재구축하는 비용을 피하기 위해 문서 인코더는 고정(frozen)됩니다.

주요 개념

• RAG-Sequence는 Natural Questions에서 44.5 Exact Match(EM), TriviaQA에서 56.8 EM, WebQuestions에서 68.0 EM을 달성하여 발표 당시 최고 수준(SOTA)을 기록했습니다.
• MS-MARCO 생성형 QA에서 RAG-Sequence는 BART 전용 베이스라인의 38.2점과 비교하여 40.8 ROUGE-L을 기록하며 작지만 일관된 성능 향상을 보였습니다.
• Jeopardy 질문 생성: 인간 평가자들은 42.7%의 사례에서 RAG의 출력이 BART보다 더 사실적이라고 판단했습니다(BART가 더 사실적이라는 판단은 7.1%).
• FEVER 사실 검증에서 RAG는 작업별 엔지니어링 없이도 72.5%의 3방향 정확도(전문 SOTA보다 4.3점 낮음)에 도달했습니다.
• 학습 중 문서 인코더를 고정함으로써 발생하는 성능 손실은 NQ에서 약 3 EM 점수(44.0 → 41.2)에 불과하여, 인덱스 지식이 다소 오래될 수 있다는 대가로 계산적 타당성을 확보했습니다.
• 밀집 검색(Dense retrieval)은 엔티티 중심 쿼리가 용어 중첩(term overlap)에 유리한 FEVER를 제외한 모든 작업에서 BM25를 능가했습니다. 이는 희소 검색(sparse retrieval)이 일률적으로 열등하지 않다는 구체적인 신호입니다.

유지되는 가치와 한계

지식 저장소를 추론 엔진에서 분리한다는 근본적인 통찰은 매우 성공적으로 자리 잡았습니다. 이를 통해 업데이트 가능한 지식(인덱스 재구성만으로 가능), 출처 표시(검색된 구절 검토 가능), 그리고 특정 작업에 국한되지 않은 범용성(오픈 도메인 QA, 생성, 사실 검증 등)을 확보할 수 있었습니다. 이러한 특성은 실제 환경에서 특정 EM 점수보다 훨씬 더 중요합니다.

NeurIPS 리뷰어들이 지적했듯이 기술적 참신함은 제한적일 수 있습니다. DPR과 BART는 이미 존재했으며, RAG는 이를 근본적인 알고리즘 발전이라기보다는 정교하게 통합한 결과물입니다. 또한 고정된 문서 인코더 결정은 논문에서 다소 간과된 미묘한 문제를 야기합니다. 인덱스는 한 번 구축되면 스냅샷이 됩니다. 인덱스 구축 이후에 변경된 사실은 모델이 알 수 없습니다. SEC 공시 자료와 같은 정적 코퍼스에는 수용 가능하지만, 실시간 가격이나 일일 거래 피드와 같은 실시간 시스템에서는 단순한 세부 사항이 아닌 진정한 아키텍처적 제약이 됩니다.

검색 붕괴(retrieval collapse) 현상은 현재 받는 관심보다 더 주목받아야 합니다. 스토리 생성 작업에서 모델은 검색된 문서를 완전히 무시하고 파라미터형 메모리에서만 생성하는 법을 학습했습니다. 논문은 작업이 "특정 지식을 요구하지 않을 때" 이런 일이 발생한다고 언급했지만, 그 메커니즘을 설명하거나 실무자가 이를 감지할 수 있는 원칙적인 방법을 제시하지는 않았습니다. 겉으로는 정상적으로 작동하는 것처럼 보이지만 조용히 검색을 중단하는 에이전트는 프로덕션 금융 시스템에서 가장 우려되는 실패 모드입니다.

메모리 점유 공간 또한 무시할 수 없습니다. 위키피디아 인덱스만으로도 약 100GB의 CPU RAM이 필요합니다. 논문은 이를 비파라미터형 메모리의 장점("빠른 업데이트 가능")으로 포장했지만, 이는 이후 몇 년 동안 압축 인덱스와 근사 검색(approximate retrieval) 방향으로 기술이 진화하게 만든 실제적인 운영 비용이었습니다.

금융 AI에 중요한 이유

검색 아키텍처는 Beancount의 문제 구조와 자연스럽게 매칭됩니다. Beancount 원장은 개별 항목들이 의미적으로 연결된 대규모 추가 전용(append-only) 문서 코퍼스입니다. 예를 들어 세금 공제 비용은 카테고리를 참조하고, 카테고리는 규칙을 참조하며, 규칙은 회계 연도를 참조합니다. 공개 데이터로 학습된 파라미터형 모델은 사용자의 특정 계정과목표(chart of accounts)를 알지 못합니다. RAG의 지식-추론 분리는 이를 위한 올바른 구조적 해답입니다. 생성기는 회계 작업 형식에 맞춰 미세 조정하되, 사실 확인은 사용자의 실제 원장 인덱스를 바탕으로 수행하는 것입니다.

실질적인 우려는 논문에서도 확인되었지만 과소평가된 '오래된 인덱스' 문제입니다. Beancount 에이전트가 어제 구축된 인덱스에서 검색한다면 오늘의 거래를 놓칠 수 있습니다. 원장 기록 시 증분 인덱싱(incremental indexing)과 트리거 기반 재인덱싱이 시스템 설계 초기 단계부터 포함되어야 하며, 이는 나중에 덧붙여질 기능이 아닙니다. 또 다른 문제는 구조화된 데이터에 대한 검색 정밀도입니다. RAG는 위키피디아 산문을 위해 설계되었습니다. Beancount 원장에는 날짜 범위, 계층적 계정 구조, 통화 단위가 포함되어 있으며, 산문에 최적화된 검색기는 이를 기본적으로 처리하지 못합니다. 제가 이전에 탐구했던 "LLM이 표 형식의 데이터를 추론할 수 있는가"라는 질문은 RAG가 유용하게 검색할 수 있는 범위를 직접적으로 제한합니다.

다음 읽을거리

• Fusion-in-Decoder (FiD), Izacard & Grave 2020 (arXiv:2007.01282) — 검색된 각 구절을 독립적으로 처리하고 디코더에서 융합하여 RAG보다 더 높은 NQ 점수를 달성하면서도 아키텍처적으로 더 단순합니다. RAG-Token의 공동 읽기 방식을 채택하기 전에 이해할 가치가 있습니다.
• FLARE: Active Retrieval Augmented Generation, Jiang et al. 2023 (arXiv:2305.06983) — 모델이 환각을 일으킬 시점을 예측하여 생성 중에 온디맨드로 검색을 수행합니다. RAG의 아이디어를 더 적응형 에이전트로 확장한 가장 자연스러운 결과물입니다.
• "Fine-Tuning or Retrieval?" Ovadia et al. 2023 (arXiv:2312.05934) — 다양한 작업에 걸친 지식 주입 방법의 체계적인 비교 연구입니다. 원장 전용 생성기를 미세 조정할지, 아니면 검색 기능을 개선할지 결정하기 전에 필요한 실증적 증거를 제공합니다.