检索增强生成：你以为是在给模型补知识，其实是在给它装一条能被核对的证据链

一句话

你以为检索增强生成（RAG，retrieval-augmented generation）是「给模型补知识」的省钱替代品，其实它真正交付的是一条可核对的证据链：知识当天可换、来源可点回、答错了能定位到是哪一环坏的——这三样微调和超长上下文都给不了。而整章最该记住的工程结论只有一句：RAG 的质量上限由检索那一半决定，生成模型只是在这个上限之下打折。

Glossary · 术语表

坐标

Part II 十道真题的第五道，也是文本簇的收官题。上承 Ch4 ChatGPT——那里的知识全靠参数记忆；这一章第一次把外部知识库接进生成链路，Ch7 起则转入图像生成。现实对应企业知识库问答、客服助手、文档助理，以及今天所有带「引用来源」的搜索型 AI 产品。

这章要解决什么

参数记忆有三宗罪，且每一宗都不是把模型做大能解决的。

一是过期。权重冻结在训练截止那天，而知识库每天都有文档在改。为一次政策更新重跑微调，从数据准备到评估上线通常以周计，而文档改动以分钟计——差了四五个数量级，不是调优能补上的。

二是指不出出处。模型说「住宿上限 800 元」时，这个数字糊在几万亿 token 的语料里，定位不到任何一句原文。而在法务、医疗、金融场景，不能核对的正确答案和错误答案价值相同——你分不出手里这条是哪种。

三是私有数据进不去。内网文档、用户自己的资料、有权限分级的材料，不该也不能塞进一份全员共享的权重——权重没有 ACL（访问控制表），一旦记住，就没法只对一部分人忘掉。

不解决会怎样？模型在它不知道的事情上依然流畅作答，且全链路没有任何一处可供核对。这正是上一章那个结论的升级版：生成式系统最危险的失败不是答不上来，是错得流畅。

核心内容，讲透

① 两个阶段：离线把知识摆好，在线只做取用

整条流水线被一条硬边界切成两半，看懂它，后面所有权衡都好解释。

离线（索引期）：文档 → 分块 → 逐块算嵌入 → 写进向量索引。百万级文档切成千万级片段、算完嵌入建好索引，是个批处理作业，耗时按小时算——因为没人在等。

在线（问答期）：问题 → 算嵌入 → 检索 → 重排序 → 拼进 prompt → 生成。整体要压在一两秒内，而生成往往就吃掉一秒以上，留给检索加重排的常只有 100–300 毫秒——这个预算才是后面索引选型的真正约束。

② 分块：全链路最被低估的一个决策

检索的单位不是文档，是块。块怎么切，几乎决定了后面能不能检到。

直觉是「越小越准」：一块只讲一件事，嵌入不被稀释，容易对上。但小块会把完整论述撕成两半——模型拿到半截话，更容易自行补全出错的那一半。块太大则一块混了五六个主题，嵌入被平均成一个谁也不像的向量，检索分数低，还白占 prompt 预算。

常见落点是 200–500 token 一块、相邻块留 10%–20% 重叠（overlap，防止答案正好卡在切口上）。但比调参更重要的是三件事：按结构切（沿标题与段落边界，别按固定字数把表格拦腰砍断）；带上元数据（标题、章节路径、日期、权限标签，既用于过滤也用于排序）；上下文化——把所属章节标题或一句摘要拼回块首。最后一条针对一个具体毛病：一块写着「该上限自次月起调整为 1000 元」，孤立看根本不知道说的是哪项费用，检索永远对不上。

③ 检索：关键词、向量与它们的合并

两条路的失手方式几乎正好互补。

BM25（关键词）在精确串上无敌：错误码 ERR_5021、型号 X-200、人名、法条编号——这些东西算嵌入毫无意义，字面匹配却百发百中。死穴是同义改写：用户问「怎么退钱」、文档写「退款流程」，词面不重合就是零分。

稠密检索（向量）正好相反：能跨过用词差异抓语义，却常在罕见专名上翻车——嵌入模型没见过这个型号，就当它是一串普通字符，返回一堆「看着像技术文档」的无关块。

混合检索把两路的排名合起来（常用倒数排名融合 RRF：按名次而非分数加权，省掉两套分数量纲不一致的麻烦）。这是绝大多数生产系统的默认选择，代价是两套索引都要维护、还多一个融合权重要调。

另一层是怎么在千万级向量里快速找出最近的几条。逐条算距离召回 100%，但千万量级下单次查询要几百毫秒到秒级，直接撑爆预算。ANN 用结构换速度：HNSW 建一张分层邻居图，查询从稀疏的顶层起跳、逐层逼近，能压到毫秒级，代价是可能漏掉真正的最近邻。漏多少由搜索宽度这一个旋钮控制，调大则召回和延迟同涨。它是连续可调的旋钮、不是开关——该当成 SLO 的一部分来定，而不是抄个默认值。

④ 重排序与上下文装配：把一百条压成五条

检索阶段是双塔：问题和片段各自独立编码，片段向量能离线算好存起来——这正是它快的原因，但两边从未「见过面」，只能比粗略的相似度。

重排序器反过来：把问题和片段拼成一条送进模型一起算，能捕捉「这段是否真的回答了这个问题」。代价是它没法预计算，每个候选都要现场跑一次——所以它比双塔慢一到两个数量级，只能用在少量候选上。标准做法因此是漏斗：ANN 粗召 100 条 → 重排精算 → 留 3–5 条进 prompt。

「装配」还有两个易漏的细节。其一，位置有影响：摆在长上下文正中间的材料最容易被忽略，所以最相关的片段该放首尾，而不是按相似度一路铺下去。其二，每块都按 token 收费、也按 token 吃延迟：5 块 × 400 token = 2000 token，每问一次付一次。k 从 5 调到 20，答对率通常不怎么涨，账单和首字延迟却实打实地涨。

⑤ 生成侧：接地、引用与拒答

拿到片段后，生成的任务不是「发挥」，而是受约束地复述。三条落地要求：提示里写死「只依据给定材料作答」；逐句挂片段编号，让引用能被程序校验而不只是给人看；允许说不知道——检索分数低于阈值或片段互相矛盾时，正确输出是「材料中未提及」。

最后一条是整套系统里最反直觉的产品决策：拒答率是一个要主动调的旋钮，不是一个越低越好的缺陷。企业问答场景宁可多拒答几个百分点，也不愿放出一条看不出错的编造。

关键权衡与选型

第一个决策在动手之前：这份知识到底该怎么进模型。

表 1 · 四条给模型补知识的路

注意最后一行：微调和 RAG 从来不是竞品——前者改「怎么说」，后者补「说什么」，生产系统里常常同时存在。

第二个决策是检索路线，它直接决定 recall@k 的天花板。

表 2 · 四种检索配置

第三个决策是索引形态，本质是在召回、延迟、内存、更新代价四者之间挑两样。

表 3 · 三类向量索引

一条实用建议：无论最终上哪种索引，都先用暴力检索在一批标注好的问题上量一次 recall@k 当基准线。ANN 掉了多少召回、值不值，只有对着这条线才谈得清。

为什么重要 / 落到真实系统

三个落点已在大规模跑：企业知识库问答（内网文档 + 权限过滤，商业价值最集中）、带引用的搜索型回答（答案下方挂可点来源，用户自己核对）、客服与技术支持（工单、手册、变更记录一起索引，答案能追到具体哪份文档的哪一段）。第三个最能看出它的真身：这不是一个更聪明的模型，而是把组织已有文字资产接进生成链路的基础设施。

易错点与争议

• 只评生成、不评检索。 最常见的错误。要分两段量：检索侧看 recall@k，生成侧看忠实度与拒答率。答得不好，八九成是没检到，不是模型笨。
• 把「相似」当成「相关」。 向量检索永远返回 k 条，哪怕库里根本没有答案——它没有「查无此项」这个输出。不自己设分数阈值，模型就会拿着一堆无关片段硬答。
• 以为块越小越好。 块小提升的是命中率，牺牲的是完整性；被撕成两半的论述反而更容易诱发编造。
• 引用变成装饰。 模型标了片段编号，不等于那句话真的出自那一块。引用必须被程序校验，否则它只是幻觉的一层包装。
• 权限靠提示词兜底。 「不要透露 HR 文档」这种话挡不住任何东西。过滤必须发生在检索层：无权的片段根本不该进候选集。
• 索引陈旧无人察觉。 文档改了、嵌入没重算，系统会自信地给出旧答案且毫无异常信号。索引新鲜度要像数据管道一样监控。
• 争议：长上下文会不会吃掉 RAG。 窗口越做越大，「全塞进去」看着越发可行。但三件事没变：每次问答都为整份资料付 token 费、延迟随材料线性涨、整个知识库本来就塞不进任何窗口。更现实的判断是二者合流——用检索收窄范围，再用大窗口容下更多候选。
• 时代局限。 本章以「一次提问 → 一次检索」的单轮形态为主线；此后实践大量转向多轮与代理式检索（模型自己决定要不要再查、查什么），以及 GraphRAG 这类针对全局性问题的结构化路线。底层结论一条没变：检索决定上限。

要点