「RAG」大概是过去几年被提及频率最高的技术名词之一。但你未必知道，这个如今几乎和「大模型应用」画等号的词，最初是一篇 2020 年、由 Facebook AI Research 发表的论文标题——Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks。读懂这篇原论文，你才能分清「真正的 RAG」和后来各种被泛化的「检索+生成」之间，到底差在哪。
一、论文速览卡
| 论文标题 | Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks |
| 作者 | Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Küttler, Mike Lewis, Wen-tau Yih, Tim Rocktäschel, Sebastian Riedel, Douwe Kiela |
| 机构 | Facebook AI Research（Meta AI） |
| arXiv | 2005.11401（2020 年 5 月 22 日提交，2021 年 4 月 12 日修订 v4） |
| 正式发表 | NeurIPS 2020 |
| 核心思想 | 把预训练的「参数记忆」（seq2seq 生成模型）与「非参数记忆」（维基百科稠密向量索引）结合，用可微分的检索器在生成时动态取回相关知识。 |
| 两种公式 | RAG-Sequence（整条序列用同一批检索段落）与 RAG-Token（每个 token 可用不同段落） |
| 一句话结论 | 在三个开放域问答任务上达到当时的 SOTA，且生成的语言比纯参数模型更具体、更多样、更符合事实。 |
二、为什么这篇论文值得精读
这篇论文解决的是一个根本性的矛盾：大模型把知识「背」在参数里，带来两个绕不开的问题——一是知识有保质期，世界变了模型不会自动更新，除非重新训练；二是决策不可溯源，模型答错了你也不知道它「凭什么这么说」。
RAG 的答案是：别让模型什么都记住，给它接一个随时能查的外部知识库。生成的时候先检索、再依据检索结果作答。这听上去简单，但在当时是一次范式级的转向——它把「知识」从「模型内部」剥离到了「模型外部」，一举解决了更新慢和不可溯源两个痛点。
为什么今天尤其值得重读原论文？因为现在绝大多数的「RAG 应用」其实只是「拼一个向量库 + 把检索结果塞进 prompt」，而这和原论文里「检索器与生成器联合端到端训练」的 RAG，在机制上是两回事。搞清原版定义，是理解后续一切 RAG 变体的地基。
三、背景：参数记忆的瓶颈
论文开篇就点出了预训练模型的处境。大型预训练语言模型确实把大量事实「存」进了参数，微调后能在下游任务上拿 SOTA；但一旦进入知识密集型任务（knowledge-intensive tasks，比如开放域问答、事实验证），它们的表现就落后于任务专用架构。原因很直接：
- 知识访问不精确：参数化存储是「模糊的、压缩过的」，模型没法像查数据库一样精确取出某条事实；
- 决策无法溯源：模型说不出答案的「出处」，这在需要证据链的任务里是硬伤；
- 知识更新困难：世界变了，只能重新训练。
论文的洞察是：如果给模型配一个可微分的、能访问显式非参数记忆的机制，这些问题就能缓解。之前也有人尝试过（比如 REALM、ORQA），但它们都只做了抽取式（extractive）下游任务——也就是只「找到答案」，不「生成答案」。RAG 论文的关键一步，是把这个思路推广到生成式（generative）任务上，给出一个通用的微调配方。
这里有必要把「为什么生成比抽取更难、也更重要」说清楚。抽取式任务只需要「从原文里抠出答案片段」，检索到对的段落基本就成功了一半；而生成式任务要求模型「在检索到的知识基础上，用自己的话组织出一个完整、连贯的答案」，这既考验检索质量，也考验「把检索结果正确消化进生成过程」的能力。RAG 把检索增强从「找答案」推进到了「写答案」，这才是它能成为「生成式 AI 时代基础设施」的原因。
四、核心方法：参数记忆 + 非参数记忆
4.1 两个记忆，一个联合框架
RAG 模型由两部分组成：
- 参数记忆（parametric memory）：一个预训练的 seq2seq 生成模型（论文里用的是 BART）；
- 非参数记忆（non-parametric memory）：一个维基百科的稠密向量索引，通过一个预训练的神经网络检索器来访问。
生成一个回答时，模型先用检索器从维基百科索引里取回与输入最相关的若干段落（top-k），再把这些段落作为额外上下文喂给生成器，让它「边查边写」。这个检索过程是可微的，意味着检索器和生成器可以联合端到端训练——这是它和「把检索结果当普通输入塞进去」的本质区别。
「可微」这个词是整个方法的技术核心，值得展开。一个普通的「查数据库 → 拼接 → 喂模型」流程里，检索那一步是「硬」的、不可导的，模型无法通过梯度反传去「学习怎么检索得更好」。而 RAG 里，检索器输出的是一组「候选段落 + 概率权重」，这个概率权重参与了后续生成的概率计算，因此梯度可以一路从生成器反传回检索器，让检索器「知道哪些检索结果对生成有帮助、哪些没用」。这种「检索与生成互相反馈」的机制，是原版 RAG 区别于所有「工程拼接式 RAG」的灵魂。
4.2 两种公式：RAG-Sequence 与 RAG-Token
论文定义了 RAG 的两种具体实现，区别在于「检索结果在整条生成序列里如何使用」：
- RAG-Sequence：对整条回答序列，固定使用同一批检索到的段落来生成全部 token。它更简洁，也更容易和现有生成框架对接。
- RAG-Token：每个 token 可以依赖不同的检索段落。生成更灵活，理论上能对不同位置的 token 调取不同知识，但代价是计算更复杂。
用概率公式能看得更清楚。RAG-Sequence 的概率是「先选一批段落，再基于这批段落生成整条序列」：p(y|x) 近似等于对所有候选段落 z 求和 [ p(z|x) · Π_i p_θ(y_i | x, z, y_1…y_{i-1}) ]。而 RAG-Token 的概率是「每个 token 分别选段落」：p(y|x) 近似等于 Π_i [ 对所有候选段落 z 求和 p(z|x) · p_θ(y_i | x, z, y_1…y_{i-1}) ]。区别就在那个求和符号的位置——一个在整条序列外，一个在单个 token 内。这个区分在工程上很有意义：RAG-Sequence 是后来大多数系统采用的形态，而 RAG-Token 的「逐 token 检索」思路，则启发了后续一系列更精细的检索融合研究。
4.3 训练与推理
训练时，RAG 的检索器和生成器一起被微调，检索器用的是 DPR（Dense Passage Retrieval）那套双编码器结构。推理时，先做一次检索取 top-k 段落，再做生成。论文还引入了边际化（marginalization）来处理「检索结果不确定」的情况，让模型对不同检索结果做概率求和，从而更稳健。
「边际化」这个细节也值得多说一句：检索器返回的 top-k 段落，每一段都有一定概率是「真正相关的那段」。朴素做法是只取概率最高的那段，但这样一旦检索「押错」就满盘皆输；边际化则是对 top-k 段落的生成结果按检索概率加权求和，让模型「综合参考所有候选段落」，从而在检索有噪声时更稳。这种「不把鸡蛋放在一个篮子」的概率化处理，体现了原版 RAG 在统计建模上的严谨，也是后来「多路召回 + 融合」思路的理论雏形。
五、实验结果：关键数据逐字保留
论文在多个知识密集型任务上做了评测，最核心的成绩在开放域问答上。摘要里给出了明确的结论：
「We fine-tune and evaluate our models on a wide range of knowledge-intensive NLP tasks and set the state-of-the-art on three open domain QA tasks, outperforming parametric seq2seq models and task-specific retrieve-and-extract architectures.」
也就是说，RAG 在三个开放域问答任务上拿到了当时的 SOTA，超过了纯参数的 seq2seq 模型，也超过了任务专用的「先检索后抽取」架构。三个任务分别是 Natural Questions、TriviaQA 和 WebQuestions。
更值得注意的是生成质量的对比，摘要原文写道：
「For language generation tasks, we find that RAG models generate more specific, diverse and factual language than a state-of-the-art parametric-only seq2seq baseline.」
翻译过来：在语言生成任务上，RAG 生成的语言比 SOTA 纯参数 seq2seq 基线「更具体、更多样、更符合事实」。这三点（specific、diverse、factual）正是后来 RAG 被广泛采纳的核心卖点——它不只是答得更准，而是「答得更有依据、更丰富」。
论文还用消融实验说明了一个重要结论：联合训练检索器和生成器，比固定检索器只训练生成器效果更好。这验证了「可微分检索」的价值，也解释了为什么简单粗暴的「向量库 + prompt」并不等价于原版 RAG。此外，论文还展示了「增加检索段落数量」「换更强的检索器」等变量对结果的影响，整体指向同一个结论：检索环节的质量和「检索-生成」的耦合程度，是 RAG 效果的两大决定因素。
六、局限与不足：原论文自己承认的问题
一份奠基性工作，往往也有被后来者反复修补的短板。RAG 的局限主要有这几条：
- 检索质量是天花板：整个系统好坏的瓶颈在检索器——检索错了，生成器再强也「巧妇难为无米之炊」；
- 当时的检索器本身不算强：DPR 时代的能力上限，远不如今天的向量模型和大模型重排序，所以当年的绝对分数在今天看并不惊艳；
- 架构相对固定：BART + 维基百科索引的设定，缺乏对「多跳推理」「结构化知识」等更复杂场景的支持；
- 无法处理需要「综合多条证据」的问题：单轮 top-k 检索对「需要跨多篇文档拼接答案」的复杂问题能力有限。
这些短板，恰好划出了后来 RAG 研究的主战场——更好的检索器、重排序、多跳检索、以及和大模型结合后的各种工程化改进。还有一点值得补充：原版 RAG 的「可微分联合训练」虽然理论上更优雅，但在大模型时代成本很高，所以工程实践里多数人退而求其次，用「冻结的强检索器 + 冻结的大模型 + 精心设计的 prompt」来做 RAG，牺牲了「联合优化」换来了「即插即用」。理解这个「理论版本」和「工程版本」的分野，是读懂 RAG 生态的关键。
七、横向对比：RAG 在检索增强路线里的位置
把 RAG 放进检索增强这条时间线，它的承前启后关系很清晰。
在它之前，REALM（2020）和 ORQA（2019）已经提出了「预训练阶段就引入检索」的思路，但都局限在抽取式任务；DPR（2020）则解决了「怎么训一个更好的稠密检索器」的问题。RAG 的贡献是把这几条线捏合起来，第一次给出了一个面向生成任务的、端到端可微的通用检索增强框架。
在它之后，检索增强的研究蓬勃发展：FiD（Fusion-in-Decoder）探索了「把多段检索结果融合进解码器」的更优方式；Atlas、RETRO把检索做进了更大规模的预训练；而到了大模型时代，Self-RAG、RAPTOR、GraphRAG等则在「何时检索、检索什么、怎么组织知识」上做了大量演进。
但无论怎么演化，所有后来者共享同一个地基：「参数记忆」负责生成，「非参数记忆」负责提供可更新的、可溯源的知识——这个分工，正是 RAG 这篇论文确立的。
八、从原版 RAG 到今天的「工程化 RAG」
今天的 RAG 和原论文的 RAG，其实已经走了两条不太一样的路，这个分野值得单独说清。
原版 RAG 是一套端到端可微的模型：检索器和生成器绑定训练，检索结果是「概率化」地融入生成过程的。而今天绝大多数的「RAG 应用」，是一套工程流水线：用一个（往往是第三方、冻结的）向量模型做检索，把召回段落拼进 prompt，交给一个大模型生成。两者共享「先检索、再生成」的骨架，但在「检索是否参与优化」这个点上分道扬镳。
这种分野带来的实际后果是：今天 RAG 系统的上限，几乎完全由「检索质量」和「prompt 设计」决定，而不是由「生成模型大小」决定。因为生成模型已经不参与检索优化了，检索错了就是错了，生成模型只能「基于错误的上下文硬编」。所以，如果你在做 RAG 应用，把精力放在「召回更准、排序更精、上下文组织更好」上，通常比「换个更大的生成模型」收益更大。这个结论，其实在原论文「联合训练优于固定检索器」的消融里就已经埋下了伏笔。
八点五、RAG、微调与提示工程：三条路怎么选
在实际落地「让模型更懂某个领域」时，团队面前往往摆着三条路：提示工程（prompt engineering）、RAG、微调（fine-tuning）。把三者的边界和取舍搞清楚，是 RAG 实践者绕不开的功课。
- 提示工程：最轻，改 prompt 就能试，适合「一次性、少量知识、通用能力」的场景。但它能塞进的知识量受上下文长度限制，且每次都要重复写，无法「固化」。
- RAG：把知识放在外部知识库，生成时动态检索。适合「知识量大、更新频繁、需要溯源」的场景——比如企业知识库问答、客服、新闻问答。它的优势是「知识可随时更新、答案可追溯」，缺点是「多了一套检索系统的复杂度」，且效果高度依赖检索质量。
- 微调：把知识「训进」模型参数。适合「风格、格式、行为模式」这类难以用检索表达的东西——比如让模型学会某种口吻、某种输出格式。它的缺点是「知识会过期、更新要重新训练」，且成本高。
一个常见的误区是「遇到知识问题就微调」。RAG 论文其实早就给出了答案：对于「易变、需溯源的事实性知识」，检索比记进参数更合理。所以现在的工程共识是：「知识」交给 RAG，「风格/格式」交给微调，「临时任务」交给提示工程。三者不是互斥，而是按「知识的新鲜度、可溯源性、以及要固化的东西」来分工。理解了这个分工，你就不会被「要不要上 RAG」这类问题困扰了。
八点六、RAG 的典型落地场景与工程要点
RAG 从论文走向生产，已经沉淀出一批成熟的落地场景和工程要点，这里做一个简明盘点，方便对照自己的项目。
典型场景：企业/机构知识库问答（让大模型基于内部文档回答）、客服机器人（基于产品手册和 FAQ 作答）、法律/医疗/金融等专业领域的「带出处」问答、以及「让模型能引用最新信息」的实时问答（如接新闻、接数据库）。这些场景的共同点是：答案高度依赖「外部、可更新、需溯源」的知识，正好是 RAG 的甜点区。
工程要点，按「召回 → 排序 → 组装 → 生成」四步拆：
- 召回要准：选好向量模型、做好文档切分（chunking）和索引，这是 RAG 的第一道关卡，召回错了后面全白搭；
- 排序要精：召回 top-k 后加一个 reranker 精排，把「真正相关的」排到最前，能显著提升答案质量；
- 组装要巧：把检索段落和问题组织成 prompt 时，注意「相关性排序、截断、去重、以及标注来源」，让生成模型拿到干净、相关的上下文；
- 生成要可控：用 prompt 约束模型「只依据给定材料回答、材料没有就说不知道」，并做好「引用标注」让答案可溯源。
这套「四步流水线」，是今天绝大多数 RAG 系统的通用骨架。掌握它，你就能快速判断一个 RAG 项目「瓶颈在哪一步」——是召回不准、排序不精、还是组装时塞了太多噪声。这也反过来印证了 RAG 论文的核心洞见：瓶颈永远在检索和知识组织，而不是生成模型本身。
八点七、怎么评估一个 RAG 系统好不好
RAG 系统做出来了，怎么知道它好不好？这需要一个「既有检索、又有生成」的评估框架。理解 RAG 的评估，才能避免「检索指标好看、实际答案稀烂」的陷阱。
RAG 的评估通常分两个层次：
- 检索层评估：看检索器「有没有把对的段落捞回来」，常用指标是召回率、top-k 命中率、以及 MRR（平均倒数排名）等。检索评估是必要的，但还不够——检索对了不代表最终答案对。
- 端到端评估：看「最终生成的答案」好不好，通常从三个维度打分：忠实度（faithfulness）——答案是否忠于检索到的材料、有没有「编造」；相关性（relevance）——答案是否回答了用户的问题；正确性——答案本身对不对。这三个维度要分开看，因为「相关但编造」「忠实但答非所问」是两种不同的失败。
工程上，早期靠人工打分，后来发展出了「用 LLM 当裁判」的自动评估（比如 RAGAS 这类框架，用大模型自动判断答案的忠实度和相关性）。但要注意：「LLM 当裁判」本身也可能有偏差，最好和人工抽检结合，别全信自动分。
这套「检索 + 忠实度 + 相关性」的评估视角，其实是对 RAG 论文核心洞见的一个自然延伸：既然「瓶颈在检索、答案要可溯源」，那评估就应该「既查检索、又查答案有没有乱编」。一个「检索命中率 90%、但生成时常胡编」的系统，和一个「检索一般、但生成严格忠于材料」的系统，哪个更好？答案取决于场景——但「忠实度」这个维度，正是 RAG 相对纯生成模型最该守住的优势。
九、总结：这篇论文留给我们三个启示
第一，知识应该「存」还是「查」，是一个可以重新选择的问题。RAG 最大的思想遗产，是告诉我们：不是所有知识都得塞进参数。把易变的、需要溯源的事实交给外部记忆，模型就能既保持强大又保持「新鲜」。
第二，「可微分检索」和「拼接 prompt」是两码事。原版 RAG 的精髓在于检索器与生成器联合训练、让检索真正参与优化。今天很多「RAG 系统」只是工程上的检索增强，理解原论文能帮你判断一个系统的上限到底由谁决定。
第三，瓶颈永远在检索侧。RAG 论文已经暗示了这一点，后来的实践反复验证：一个 RAG 系统做不好，十有八九是检索和知识组织的问题，而不是生成模型不够大。把精力放在「取回对的东西」上，往往比盲目换更大的模型更有效。
参考来源
- RAG 论文（arXiv:2005.11401）：arxiv.org/abs/2005.11401
- Facebook AI 官方博客介绍：Retrieval Augmented Generation: Streamlining the creation of intelligent natural language processing models
- DPR 论文（arXiv:2004.04906）：arxiv.org/abs/2004.04906
