很多人第一次听 RAG，会以为它是给模型换个更强的版本，其实它动的是「模型回答前先看什么资料」这一段。常见卡点是：资料明明放进去了，答案还是老样子，于是怀疑 RAG 没用。这篇不堆概念，只讲 RAG 在大模型链路里负责哪几件事、什么时候它帮不上忙，以及怎么用几个动作验证它有没有真的起作用。
很多人第一次听 RAG，会以为它是给模型换个更强的版本。其实它动的是「模型回答前先看什么资料」这一段：模型还是会说错、会编，只是你先把相关资料递到它面前，让它有东西可依。所以 RAG 不是升级模型，而是给模型加了一套查资料的动作。
最常见的卡点是：资料明明放进去了，答案还是老样子，于是怀疑 RAG 没用。这篇不堆概念，只讲 RAG 在大模型链路里负责哪几件事、什么时候它帮不上忙，以及怎么用几个动作验证它有没有真的起作用。如果你还在选型阶段，可以先到 /tools 看工具目录，再回来对照这篇的判断标准。
RAG 接在大模型的哪一环，替你挡掉什么问题
模型本身只会输出训练时见到的内容。你公司的产品手册、内部流程、客服话术，它训练时根本没见过，所以直接问就是瞎猜。RAG 的作用就是在生成之前，把相关资料塞进上下文，让答案有据可依。它专门对付三类毛病：答不上内部资料、答错还说得头头是道、资料更新了但模型不知道。
- 答不上内部资料：文档只在你自己手里，模型训练时没见过，RAG 负责把这一段补上；
- 答错还嘴硬：模型会编出看起来合理的答案，RAG 给它真实片段，让它少编；
- 资料更新不及时：新版本说明、新政策，RAG 每次现查现用，不用重训模型；
- 需要推理和算术的题：RAG 帮不上，它只负责找资料，不负责算数；
- 需要实时行情的数据：要靠接口拿实时值，别指望文档检索；
- 资料里根本没有答案的问题：检索再准也召不回不存在的内容，该说不知道就说不知道。
拆成四件事：找资料、筛资料、拼上下文、约束输出
RAG 不是一个动作，而是一条小流水线。拆开看，它在大模型链路里干四件事，每件事出问题，最终答案都会变形。下面按顺序说，每一步你都该能在自己的系统里找到对应环节。
- 找资料把用户问题变成可检索的形式，从你的资料库里召回一批候选片段。这一步只看「有没有把对的片段捞进来」，先别管排序。
- 筛资料候选里噪音很多，需要重新排序再截断，只留最相关的几段。这一步决定答案质量的上限，捞得再多，筛不好也是白搭。
- 拼上下文把片段按固定模板塞进提示里，同时给模型明确的指令：只依据这些内容回答，不要自己发挥。模板写清楚，模型才不容易跑偏。
- 约束输出要求模型带上出处、答不了就说不知道。把幻觉压到可接受范围，而不是追求一次都不错。出错了能回溯到哪一段资料，比错了强。
| 环节 | 干什么 | 出问题的典型表现 |
|---|---|---|
| 找资料 | 问题转成可检索形式，召回候选片段 | 答非所问，答案来自完全无关的文档 |
| 筛资料 | 重新排序并截断，只留最相关几段 | 答案沾边但抓不住重点，噪音片段被当成依据 |
| 拼上下文 | 按模板塞进提示，并给「只依据这些回答」的指令 | 模型自由发挥，开始编造资料里没有的内容 |
| 约束输出 | 要求带出处、答不了就说不知道 | 没有来源、无法追溯，错了也不知道错在哪一步 |
什么时候 RAG 会失效，先做这四项自检
RAG 不是万能的。资料质量差、检索对不上、问题本身含糊、上下文给太多，都会让效果回落。遇到「资料放进去了还是答不好」，别急着换模型，按下面四个方向各查一遍，通常问题就出在其中一项。
- 资料侧：文档格式太乱、扫描件没做文字提取、切片把一句话切断，检索再准也白搭；
- 检索侧：问题和文档用词对不上，纯向量召回会漏，需要配合关键词类检索一起用；
- 问题侧：一次问了好几件事，或者问题指代不清，检索到的片段自然对不上；
- 模型侧：上下文给得太多太杂，模型抓不住重点，反而答偏。
这里有个容易忽略的边界：RAG 只解决「资料里有答案但模型不知道」这一类问题。资料本身没有答案的问题、需要现场计算的题、需要实时数据的场景，都不在它的职责范围内。硬用 RAG 去解，只会得到一段看起来很完整、实际站不住的答案。
怎么判断 RAG 真的起作用了：三步验收
验收不要凭单次体验下结论。准备一小批固定的问题，分两类：资料里明确有答案的、明确没有答案的。看模型是否分别答对和承认不知道。这两类问题混着问，比只看一两个顺利的例子靠谱得多。
- 先看检索结果把召回的片段单独打印出来看一遍。如果人看着都觉得不相关，就不用往下查模型了，问题在检索或切片。
- 再看答案出处检查模型给出的答案能不能对应到具体片段。对不上，说明约束输出的指令没起作用。
- 改动前后对比调检索或切片参数前后各跑同一批问题，只对比变化。不要混着改多项，否则不知道是哪一项起了作用。
落地时最容易忽略的几件工程事
概念都懂了，真上手还是容易踩坑。检索服务是链路上新增的一跳，超时、缓存、日志、评测这几件事不提前想，后面排查会非常痛苦。下面几条是入门阶段最该先补的工程动作。
- 超时和重试
- 检索是链路里新增的一跳，要给它单独的等待上限，避免整条问答卡死。
- 缓存
- 高频问题会反复检索、拼长上下文，缓存能减少重复开销；具体效果到 /price-watch 看当时的数字。
- 日志
- 把召回片段、命中分数、最终提示都记下来，出问题才有得复盘。
- 评测
- 留一批固定问答用例，每次改参数都跑一遍，比凭感觉可靠。
如果你还在挑服务商，别只看模型列表。中转站的稳定性和计费口径会直接影响这套链路的体验，可以到 /sites 对照各家情况，再回到这里检查自己的工程动作有没有补齐。
下一步先把你的资料和问题类型对照本文的自检清单过一遍，再去工具目录挑一个检索或评测工具试跑。→常见问题
RAG 是不是就是给模型喂文档？
不完全是。喂文档只是把资料存进去，RAG 还包括把问题转成可检索形式、从库里召回片段、排序筛掉噪音、再拼进上下文这几步。只存不检，或者检出来直接全塞进去，效果通常都不好。
有了 RAG，模型还会瞎编吗？
会。RAG 只是把「有依据可查」的概率提高，不能保证模型一定照着资料说。所以提示里要明确只依据给定内容回答、答不了就说不知道，并保留出处，让人能自己核验。
什么样的资料适合做 RAG，什么样的不适合？
成段叙述、结构相对规整的文档最适合，比如产品说明、内部规范、常见问答。表格密集、扫描件、强依赖实时变化的数据就不太适合，通常要先做清洗和格式转换，否则检索出来的片段本身就不可用。
