检索增强生成

它是什么

检索增强生成（RAG）是在生成之前先检索的一套做法：先到外部知识源取回相关片段，再把「问题 + 片段」一起交给模型，让它基于这些证据作答。

换个说法，它是让模型开卷答题——知识不是背进它脑子里的，而是答题前翻到的那几页。所以它属于知识层：不负责让模型更聪明，负责让它在回答之前先去你的资料里查一次。

它要分开的是两件事——模型参数里的语言能力（怎么把话说通顺、怎么推理）与外部知识（你司的制度、昨天更新的文档）。RAG 的思路是不动前者、去补后者：不改模型权重，改的是每次提问时它看到什么。

所以它不是一种模型，也不是一次训练，而是一条由多个环节组成的链路。这一点决定了后面所有判断：链路上任何一环出错，最终答案都会变形，而「模型答得不好」常常是被冤枉的那一环。

为什么需要它

模型的训练知识有三个绕不过去的毛病：会过时（训练截止之后的事它不知道）、缺内部资料（你司的制度从没进过它的训练集）、无法逐句追溯（它说得对，但你指不出依据是哪一句）。

RAG 一次解决这三点：知识放在外部、随时可更新，答案能附出处，改知识不必重新训练。最后一条的工程含义最实际——更新知识从「重新训练」变成「重新索引」，成本与周期完全不是一个量级。

代价是它把问题从「模型行不行」换成了「检索准不准 + 上下文放得对不对」。问题没消失，只是换了地方。

它如何工作

这条链路分成两段，两段的时间尺度完全不同，这是理解 RAG 工程的关键：

离线段（建索引：慢、可批量）——解析文档 → 切片（文档切片）→ 为每个片段生成嵌入 → 写入向量数据库。

在线段（每次提问：快、有延迟预算）——问题改写（把口语化的问法改成利于检索的查询）→ 召回候选（检索）→ 可选重排 → 把精选片段拼进有限的上下文 → 生成答案与引用。

两段之间还有一个容易被忽略的点：权限与评测要贯穿两段。同样一句问题，不同的人应召回到不同的片段；而「召回了什么、最终答了什么」如果不记下来，后面就没法判断是哪一环坏了。

2026 年的普遍现状是：纯向量检索基本不够用了。生产系统多是「关键词 + 向量」的混合检索先扩大召回，再用重排把真正相关的挑上来；同时把评测当成固定环节——有了评测集，切片策略和重排模型才有得比，否则每次改动都只是感觉。

必须澄清的误会

RAG ≠ 微调（Fine-tuning）。 这是最开始就该分清的二分。知识要更新，用 RAG；行为要改变（语气、格式、判断口径），用微调。「你司的报销制度」是知识，交给 RAG；「回答必须用短句、并且先给结论」是行为，那才是微调的活。两者常被混为一谈，是因为它们都在回答「模型不知道 / 不听话」，但一个改的是看到什么，一个改的是权重。而且它们可以叠加，不是二选一。

顺序上还有一条默认规则：先检索。遇到「答不对」，先问是不是资料根本没被检索到——绝大多数情况属于这一类；只有当检索已经做到位、问题仍然出在输出风格或某种固定的推理模式上，才轮到微调。把微调当成第一手段，通常是用最贵的方式解决最便宜的问题。

RAG ≠ 接上知识库就准。 把文档喂进去就以为它「知道」了，是第二常见的错觉。检索的上限由三件事决定：切片切得对不对（一段话被从中间切断，谁检索都救不回来）、召回率够不够（正确答案压根没进候选，模型再强也没用）、重排排得准不准。这三处任一环出问题，症状都长得一样——「模型在胡说」。所以先怀疑检索，再怀疑模型。

RAG ≠ 长上下文。 「窗口都到 1M 了，把文档全塞进去不就行了」——这个疑问在窗口越来越大之后变得很响。答案是两笔账：成本上，全量塞入意味着每问一次都按全部 token 付费；精度上，证据越长，模型越容易被无关内容带偏。而检索的价值恰恰是把上下文变短、变准。长上下文降低了「必须检索」的紧迫性，但它替代不了「选对证据」这件事。

RAG ≠ 直接查数据库。 制度、合同、文档这类非结构化内容没有「字段」可查，只能按语义找；而需要精确数值（余额、库存、实时价格）时，直接调用数据库或工具才是对的——那种场景用 RAG 去「检索」，等于用概率方法回答确定性问题。所以正确的形态往往是两者并存：结构化数据走工具调用，非结构化知识走 RAG。

真实例子

员工问「最新的差旅报销标准是什么」。这条链路的每一步都在起作用：系统只召回他有权访问且仍然有效的制度片段（权限 + 时效），重排后把额度与例外条款交给模型，回答附上原文链接与生效日期。

这个例子里值钱的不是答案本身，而是三件事：权限在召回阶段就生效（不是答完再遮）、失效版本不会混进来、答案可回链到原文。反过来，如果只做了「向量检索 + 生成」，你会拿到一个听起来笃定、依据却是两年前旧制度的答案——而且它看起来完全正常。

什么时候适合与不适合

适合：知识分散在大量非结构化文档里、经常更新、需要引用出处、且不同人可见范围不同的问答。一个简单的判断标志是「人也要翻文档才能答」——那就适合 RAG。

不适合：主要依赖实时交易数据、复杂计算或确定性流程的任务——这些该直接调用数据库、规则或工具，让概率方法去做确定性的活是最常见的误用。此外，知识量很小且稳定时（比如就一页 FAQ），把内容直接写进提示词比搭一条检索链路更省事。

还有一个更细的判断：RAG 的收益随资料规模与更新频率上升。如果资料只有十来页、也几乎不变，检索带来的复杂度很可能收不回来。

亲自试一下

拿 5 份真实文档建一个最小检索集，然后问两个问题：一个资料里明确有答案，一个资料里根本没有。

全程约 30 分钟。观察点不是「答得对不对」，而是「资料里没有答案时，它是拒答还是编」——后者才是 RAG 有没有真正接上外部知识的判据。它要是答得又顺又具体、还引用了不存在的页码，说明模型在用自己的参数知识补空，检索这一环等于没起作用。

顺带记一笔：如果「有答案」那题引用的片段不是最相关的那一段，问题多半在切片或重排，不在模型。

接下来学什么

RAG 是第 3 站 给知识 · 怎么让它知道你家的资料 的入口概念：它把切片、嵌入、检索、重排串成一条能回答内部问题的链路。

顺着这条链路的每一环往下读：切片看文档切片，语义表示看嵌入与向量数据库，召回质量看检索与重排；想弄清「关键词 + 向量」为什么成了默认，读混合检索。

另外两个方向值得接着看：想判断 RAG 到底有没有生效，去第 7 站 给判断 读评测与依据性；想知道「知识入口」与「行为改造」怎么分工，读微调。完整链路可以按 RAG 学习路线 复盘一遍。

来源与修订

原始方法——把「参数化记忆」与「可检索的外部记忆」结合起来，并在生成时使用检索到的文档——来自 RAG 的原始论文 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（arXiv 2005.11401，2020-05-22）。离线/在线两段的链路划分与工程环节参考 AWS 的 Understanding Retrieval Augmented Generation 指南（访问于 2026-09-19）。

一处必须点明的边界：原始论文发布于 2020 年，它定义的是方法原型；「混合检索 + 重排 + 评测成为生产默认」是此后的工程演进，不是论文内容。本文把它单列，是为了避免拿一篇论文的 demo 当作今天的生产基线。另外三条对比（对微调、对长上下文、对直接查库）里，「RAG ≠ 长上下文」与「RAG ≠ 直接查数据库」属于本站按工程取舍整理的判断，用于回答近两年最常见的两个疑问，不是来源原文。

修订日期 2026-09-19：本条由生成模板改为决策页——补「必须澄清的误会」一节，把离线/在线两段链路写实，去掉生成期的引用标记，补 boundaries 与 minAction。若上述来源更新，应优先核对两段链路的环节划分与论文的原始定义再修订。