你在做问答类功能，模型答得像模像样，一问公司内部的事就开始编；或者你已经把检索拼进请求里，上线后却总在超时、限流、答非所问之间来回修。这篇不重复讲向量和分块原理，只回答一件事：RAG 在生成式 AI 里扮演什么角色，接入工程上要盯哪几个点、怎么排查、怎么判断自己做没做对。
你在做问答类功能，模型答得像模像样，一问公司内部的事就开始编；或者你已经把检索拼进请求里，上线后却总在超时、限流、答非所问之间来回修。这类问题通常不是模型不行，而是「先查再答」这条链路有几段没管住。
这篇不重复讲向量和分块原理，只回答一件事：RAG 在生成式 AI 里扮演什么角色，接入工程上要盯哪几个点、怎么排查、怎么判断自己做没做对。下面的判断标准和动作，对自建检索和调第三方检索服务都适用。
RAG 在这条链路里到底是个什么角色
一句话定位：RAG 不是某个模型，而是「先查、再答」的一套流程，把外部资料塞进上下文，让生成模型少靠自己记忆。它和换模型、调提示词是并行的手段，不是替代关系。搞清楚这一点，后面排错才不会一上来就去换模型。
- 知识过时
- 模型训练完之后发生的事它不知道，靠检索把最新资料补进上下文
- 私域内容
- 内部文档、产品参数、工单记录模型没见过，必须从你自己的库里取
- 可追溯
- 答案要能指回原文出处，光靠模型自述做不到
适用情况：资料会变、要求可追溯、答案要引用原文。不适用情况：任务本身不依赖外部事实，比如改写、翻译、纯代码生成，硬套 RAG 只会变慢变贵，还会把简单任务搞复杂。判断标准不是「用了 RAG」，而是同一批问题上，带检索与不带检索的答案差在哪，差异写进评测用例才算数。
- 先问一句：这个问题不查资料，模型能不能答对？能答对就别加检索
- 再问一句：答错了用户能不能接受重新问一次？不能接受，就应该有出处标注
- 最后问一句：资料多久变一次？几乎不变的静态知识，缓存策略比实时检索更划算
一次 RAG 请求里，工程上真正要管的几段
把一次请求拆成四段看：进料（文档怎么进来）、检索（查得准不准）、拼装（塞多少进上下文）、生成（调用与返回）。每段的失败表现不一样，排错时先定性是哪一段，再动参数，比反复换模型有效得多。
| 链路环节 | 常见失败表现 | 先查什么 |
|---|---|---|
| 进料 | 资料缺页、格式乱、更新没生效 | 文档清洗与入库时间戳 |
| 检索 | 答非所问、召回一堆不相关内容 | 召回条数与相似度阈值 |
| 拼装 | 上下文爆掉、关键段被截断 | 上下文长度与拼接顺序 |
| 生成 | 超时、限流、断流、答一半停住 | 超时配置与并发额度 |
接第三方的检索服务时，先用一小批已标注的问题跑通，再上量。检索质量与重排的取舍，可到 /guides/rag-retrieval-pipeline 与 /guides/rag-rerank-guide 对照。另外，如果依赖外部接口出向量，请把「出向量失败」当成独立故障处理，别和生成失败混在一个重试里，否则日志里分不清到底是哪一步挂了。
上线前要配好的运行时护栏
- 超时按段设检索、生成分开配置，不要一个全局超时。连接、读取、整体三层怎么分档，参考 /guides/api-timeout-tuning；配完拿一批慢请求压一遍，确认不会互相拖死。
- 并发按额度分档检索和生成往往是不同限流口径，先量出基线再定并发，别一次把批任务全放出去。上量分几步走，每步观察错误率变化。
- 降级写成明确动作检索失败时是直接裸答、返回缓存答案，还是回复「暂时查不到」，这个决定要写进代码而不是随机发生。降级动作要能被打点统计到。
- 日志留够字段至少记请求标识、耗时、召回条数、被截断的上下文长度、最终用的模型标识，否则事后没法复盘慢在哪、错在哪。
这几条里最容易漏的是降级动作。很多团队上线时默认「检索失败就继续答」，结果用户拿到的是模型凭记忆编的答案，看起来正常，实际更危险。护栏配好之后，还得有一轮验证才敢说「做对了」。
怎么验证自己这套 RAG 真的在起作用
先建一小组回归用例：同一批问题，固定跑带检索与不带检索两版，人工比对差异；改动提示词或换模型后重跑。单看一次回答没法判断，要看多轮、多时段的表现，众测雷达这类交叉验证思路可参考 /benchmarks/crowd-radar。
- 给答案做出处标注，能引用到原文的算通过，引用不出处的单独归一类
- 把引用不出处的那类问题集中看，往往是需要加检索或改召回的信号
- 换模型、改提示词、调阈值之后，同一批用例必须重跑，不能凭印象说过得去
- 每次回归记录用时和成本口径，对应数字到 /price-watch 核对当时的情况，避免只看效果不看代价
不适用情况：资料本身质量差或格式乱，比如扫描件、表格、多版本混杂，先解决进料清洗问题，这时候调检索参数基本白费。另一个要提醒的是，回归用例数量不必多，但必须固定，否则每次结果不可比，等于没测。
下一步把你现在用的检索链路按上面四段逐一对照一遍，缺护栏的先补护栏，再去站内评测页看同类方案当时的实测表现和价格口径。→常见问题
RAG 和直接给模型喂长文档有什么区别？
长文档是「每次都把原文塞进去」，占上下文、贵、还容易漏；RAG 是先把资料存好，按问题只取相关片段再喂。资料量大、会更新、要求给出处时用 RAG 更合适；资料就是一两页且不常变，直接塞反而更省事。
RAG 能彻底解决模型胡说吗？
不能。它把「没资料可依」变成「有资料可依」，但如果检索没召回对的片段、或者片段本身有错，模型照样会顺着错的说下去。所以要做的是让答案能引用到原文、并留一小组回归用例定期跑，发现变差才知道是哪一段出了问题。
接入 RAG 需要自己训模型吗？
一般不需要。常见做法是现成的生成模型加一个检索环节，最多再配一个重排。要自己训通常是因为领域词表特殊或检索质量怎么调都上不去，这时候先确认是不是进料和分块的问题，别急着上训练。
