针对知识密集型 NLP 任务的检索增强生成

Lewis 等人的《针对知识密集型 NLP 任务的检索增强生成》（Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020）可能是对当今生产级人工智能系统架构影响最深远的一篇论文。在发表五年后，它仍然是衡量几乎所有基于文档生成的语言系统的基准。我之所以现在读它，是因为我在 Bean Labs 待办事项中的所有内容——从账本问答到异常解释——最终都会遇到检索问题，我想在研究其后续方案之前，清晰地理解最初的设计决策。

论文详解

RAG 解决的核心问题是：预训练语言模型在训练时将知识固化在权重中，导致知识是静态的、不透明的，且不经过重新训练就无法更新。Lewis 等人提出了一种混合架构：将参数化记忆（作为生成器的 BART-large）与非参数化记忆（包含 2100 万个维基百科段落的稠密 FAISS 索引）结合起来，并通过基于稠密文档检索（DPR, Karpukhin et al. 2020）的学习型检索器连接。在推理时，模型检索前 K 个相关的段落，然后对它们进行边缘化处理（marginalize）以产生最终输出。

该论文介绍了两个变体。RAG-Sequence 仅检索一次，并在生成整个序列过程中使用同一组文档——这使得输出更连贯，但适应性较弱。RAG-Token 则允许模型在生成每个 token 时关注不同的检索文档，使其能够在句子中间综合来自多个来源的信息。两个变体在微调期间都会联合学习检索器和生成器，尽管文档编码器会被冻结，以避免在训练期间重建 FAISS 索引的高昂成本。

关键核心点

• RAG-Sequence 在 Natural Questions 上达到了 44.5 的精确匹配（Exact Match），在 TriviaQA 上达到 56.8 EM，在 WebQuestions 上达到 68.0 EM——在发表时均处于顶尖水平（SOTA）。
• 在 MS-MARCO 抽象式问答中，RAG-Sequence 的 ROUGE-L 得分为 40.8，而仅使用 BART 的基准得分为 38.2——提升虽小但表现稳定。
• Jeopardy 问题生成：人类评估者认为 RAG 的输出在 42.7% 的情况下比 BART 更符合事实（BART 仅在 7.1% 的情况下更符合事实）。
• 在 FEVER 事实核查任务中，RAG 在没有任何任务特定工程的情况下达到了 72.5% 的三分类准确率（仅比专门的 SOTA 低 4.3 个百分点）。
• 训练期间冻结文档编码器在 NQ 任务上仅损失了约 3 个 EM 点（44.0 → 41.2），这在计算上是可行的，代价是索引知识可能会过时。
• 稠密检索在除 FEVER 之外的所有任务上均优于 BM25，而在 FEVER 中，以实体为中心的查询更有利于词项重叠——这发出了一个明确信号：稀疏检索并非一无是处。

哪些经受住了时间考验——哪些没有

其核心洞见——将知识库与推理引擎分离——经受住了时间的考验。它为你提供了可更新的知识（只需重新建立索引）、来源归属（检索到的段落是可查验的），并且可以跨越开放域问答、生成和事实核查而无需特定任务的架构。在实践中，这些属性仍然比具体的精确匹配数字更重要。

NeurIPS 的审稿人指出技术创新有限，这是正确的。DPR 和 BART 已经存在；RAG 是一种精心的整合，而不是根本性的算法突破。冻结文档编码器的决定也产生了一个论文略微回避的微妙问题：索引是一次性构建的快照。索引构建后发生的任何事实变化对模型来说都是不可见的。对于像 SEC 备案文件这样的静态语料库，这是可以接受的。但对于实时系统——实时价格、每日交易流水——这是一个真实的架构约束，而非细枝末节。

检索崩溃（retrieval collapse）的发现值得更多关注。在故事生成任务中，模型学会了完全忽略检索到的文档，转而从参数化记忆中生成。论文指出，当任务不需要“特定知识”时会发生这种情况，但并未解释其机制，也没有为从业者提供一种原则性的检测方法。一个静默停止检索但表面运行正常的智能体，正是让我在生产金融系统中担心的故障模式。

内存占用也不容小觑：仅维基百科索引就需要约 100 GB 的 CPU 内存。论文将其描述为一个特性（非参数化记忆“更新快”），但在随后的几年里，这成为了一项真正的运营成本，塑造了该技术向压缩索引和近似检索进化的方向。

为什么这对金融 AI 很重要

检索架构非常自然地映射到了 Beancount 的问题结构上。Beancount 账本是一个大型的、仅追加的文档语料库，其中单个条目在语义上相互关联：一项可扣税支出引用一个类别，类别引用一条规则，规则引用一个财政年度。没有任何在公开数据上训练的参数化模型知道用户的特定会计科目表。RAG 将推理与知识分离的特性使其成为了正确的结构化答案：在会计任务格式上微调生成器，但在用户真实的账本索引中进行事实查询。

实际应用中的担忧与论文中识别但未充分重视的问题一致：过时的索引。如果一个 Beancount 智能体从昨天构建的索引中检索，它可能会错过今天的交易。增量索引和账本写入时的触发式重新索引必须从一开始就成为系统设计的一部分，而不是事后补丁。另一个担忧是结构化数据的检索精度。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) —— 对不同任务中知识注入方法的系统性比较；在决定是微调账本特定的生成器还是仅仅改进检索之前，这是你需要的实证证据。