刚接触 RAG 的人常有两个困惑：检索、增强、生成三个词到底指哪三步，为什么不是叫「知识库问答」或者「外挂资料」；另一个困惑是，既然模型能读长文档，为什么还要多搭一层检索。这篇不铺开讲架构和调参，只把命名拆开对着实际流程走一遍，告诉你每个字对应哪段代码、解决哪类问题，以及什么场景下这套东西其实用不上。
刚接触 RAG 的人常有两个困惑。第一个是名字本身：检索、增强、生成这三个词到底指哪三步，为什么这套东西不叫「知识库问答」或者「外挂资料」，偏要起一个念起来很拗口的名字。第二个困惑更实际：现在的模型能读很长的文档，直接把资料整段贴进去不就行了，为什么还要多搭一层检索。
这篇不铺开讲架构和调参，只把命名拆开对着实际流程走一遍。你会发现这三个字不是硬凑的缩写，而是一条按顺序排好的最短流水线，每个字都对应工程里一段真实存在的动作，也各自对应模型的一个短板。顺着这条线索记，比背一堆术语定义省力得多。
把三个词拆开：检索、增强、生成各指哪一步
先看「检索」。它对应的是找资料这一步：把用户的问题变成向量去库里比对，或者走关键词匹配，先拿到一批候选片段。判断这段做得好不好，看的不是向量分数高不高，而是召回来的内容里有没有答案本该在的那几段。分数漂亮但漏掉了正确答案，这一步就是失败的。
再看「增强」。它对应的是把资料塞进提示词这一步。召回的片段不能原样倒进去，要先筛一筛、排一排、拼成一段上下文，再和用户问题一起交给模型。这里拼得乱、塞得太多、把不相关的段落也夹带进来，模型照样会答歪。所以「增强」是一个需要设计动作的环节，不是复制粘贴。
最后是「生成」：模型基于拼好的上下文写答案，并且要求它引用来源，没有依据就直说不知道。命名把这三步按顺序串起来，恰好就是一条最短的流水线。少任何一环都撑不起「用自己的资料回答问题」这件事：没有检索就是瞎答，没有增强就是喂错料，没有受约束的生成就是白干。
- 检索
- 把问题变成查询，从资料库里捞出最可能相关的一批片段
- 增强
- 把这些片段筛选、排序、拼成上下文，和问题一起交给模型
- 生成
- 模型照着上下文组织答案，并尽量标出依据在哪
为什么不能只靠长上下文，非要单独加一层检索
上下文窗口再大也是有限的，而且是要花钱的。把一个几十万字的知识库整段塞进去，每问一次就要重新付一遍这笔账，长对话里更难持续。想感受不同档位的额度口径差别，到站内 /plans 与 /coding-plans 这类页面核对当时的数字，就能看出「全塞」这条路在日常使用里跑不了几轮。
还有个容易被忽略的问题：模型对上下文中间部分的注意力往往不如开头和结尾，这就是常说的「中间忘」。资料越长，最关键的那句话越容易被淹掉。检索的价值就是把最可能相关的那几段顶到前面去，让重要内容待在模型更容易看见的位置。
第三点是知识会过期。模型权重不会天天更新，但事实一直在变。把事实放在模型外面、用检索随时取，改一条资料第二天就能生效，不用等下一次训练或微调。反过来说，如果资料量很小、更新很慢、问题又高度固定，把这几十页整理进提示词里反而更省事，这时候上检索层就属于过度设计。
| 情况 | 直接塞进上下文 | 加一层检索 |
|---|---|---|
| 资料量小、更新慢 | 够用，搭建成本低 | 多一层维护，收益不明显 |
| 资料量大、天天变 | 每次都要重塞，费钱费时 | 改一条资料就能生效 |
| 问题固定、范围窄 | 提示词写死更稳 | 召回波动反而添乱 |
| 问题发散、覆盖多主题 | 容易互相干扰 | 按问题取相关片段更可控 |
它真正解决的三个问题：不知道、记不住、说不清来源
「不知道」指的是训练数据截止之后发生的事、公司内部文档、你自己写的规范，模型一概没见过。检索负责在回答之前把这些补进上下文，相当于把闭卷默写换成开卷考试。模型本身没变聪明，只是手边有了可以翻的资料。
「记不住」指的是模型记的是压缩过的统计规律。具体到某个编号、某条金额、某句原文，它很容易编出一个读起来很顺的答案。检索把原文摆到眼前，才谈得上照着说。这两点合起来，基本就是 RAG 存在的主要理由。
- 不知道：训练之后的新事实、内部资料，靠检索在回答前补进来
- 记不住：具体编号、原文表述这类细节，让模型照着上下文说而不是凭印象
- 说不清来源：带回片段和出处，答案能标引用，错了能追到是哪条资料的问题
- 不适用：纯创作、写代码、做数学推导这类不依赖外部事实的任务，检索帮不上忙
- 反效果：资料本身质量差、切片切得碎、问题又太宽泛时，检索会往里灌垃圾，先治理资料比上 RAG 划算
第三点「说不清来源」在客服、法务、内部知识问答里比答案本身还重要。答错了要能追到是哪条资料的问题，而不是只能看着一段流畅但没法核对的文字发呆。带出处这一点，也是 RAG 和纯生成最容易讲清楚的区别。
自己动手验证命名与流程对得上
光看定义记不牢，拆开跑一遍就清楚了。下面这个顺序的好处是每一步只动一个变量，出了问题能立刻定位到是三步里的哪一步。整条链路最忌讳的就是一上来就调模型参数，结果连资料有没有召回来都不知道。
- 先只管检索拿一个你明确知道答案在文档哪一页的问题去问，只看召回的片段里有没有那几段。没有就先别怪模型，回去调切片粒度和召回数量。这一步不过关，后面全是白搭。
- 再拆生成把召回内容手工换成正确的那几段，看模型能不能答对。如果手工喂对资料它就能答，说明问题出在检索环节；如果喂对了还答错，那就是提示词写法或模型选型的问题。
- 最后量整体表现固定一批问题做成小用例集，改一次切片或提示词就跑一次，别凭感觉说「好像变好了」。相关做法站内 /guide 里有讲评测与回归的篇目，可以顺着看。
想知道自己手上的资料到底值不值得搭这套东西，或者想先看看别人踩过哪些坑，站内 /tools 的工具目录和指南中心里有现成的判断清单可以对照。先判断要不要做，再决定怎么做，比先搭起来再回头补资料治理省事得多。
常见问题
「检索」「增强」「生成」必须按这个顺序吗，能不能只做两步？
顺序是流程顺下来的：先检索拿资料，再增强拼上下文，最后生成答案。可以只做前两步不做生成，那就是单纯的检索工具；也可以把检索结果直接给人看而不让模型改写。但只要目标是「让模型用上你自己的资料」，这三步基本绕不开，缺哪一步都会塌。
RAG 和把文档直接贴进对话框有什么区别？
贴进对话框是手工版的「增强」，省了检索那一步。文档少、就问一两次，这样做最简单也最准。区别在于规模和重复：文档一多、问题一杂、同一份资料要被问很多遍时，每次手工找和贴就成了瓶颈，检索这一步就是把这件手工活固定成流程，顺带解决资料更新和出处标注。
搞懂命名对实际开发有什么用？
有用，因为它就是排查顺序。答得不对时先分锅：召回里有没有该有的片段，有就是生成环节的事，没有就回去修检索。很多新手一上来就换更大的模型，结果问题出在切片或召回条数上，换了模型照样错。把三个词当成三个可单独检查的环节，能省下大量瞎试的时间。
