RAG 效果上不去，先别换模型：一条链路上的四段排查

引言

知识库问答效果不佳时，最常见的反应是 “换个更强的生成模型”。但一条 RAG（检索增强生成）链路里，生成只是最后一环，前面还有文档切分、向量化、召回、重排，任何一段出问题，最终表现都是 “答得不准”，而换生成模型往往收效甚微。更麻烦的是，这四段接口常常来自不同服务商，参数口径不一致，A/B 对比做起来非常费劲。本文按四段链路给出排查顺序与验证方法，并说明统一接入层如何让这条链路可观测，示例以 Token5u 的统一入口为参照。

一、先定位是哪一段出了问题

判断方法很直接：把召回结果单独打印出来看。如果召回片段里根本没有正确答案，问题在检索段，生成模型再强也救不回来；如果召回片段包含答案但回答里没用上，问题在生成段的提示组织；如果召回片段相关但顺序混乱、噪音多，问题在重排段。这一步不做，后面所有优化都是盲调。工程上建议在链路里加一个调试开关，把命中的 chunk、相似度分值、重排后顺序一次性打出来。

二、四段各自的常见失效点

1.切分段：粒度与语义完整性

切分粒度太粗，一个 chunk 里混了多个主题，向量表达被稀释；太细又丢失上下文，答案被切断。常见做法是按语义边界切分并保留一定重叠，同时在 chunk 头部补上所属文档标题，让向量化时带上领域信号。

2.向量化段：模型与维度必须成对管理

向量化模型一换，历史库里的向量就全部失效，必须重建索引。这是最容易忽略的一致性约束：embedding 模型版本、维度、归一化方式三项要作为一个整体版本号管理，写进索引元数据。查询时用错版本的模型，召回质量会断崖式下降，而且不报错。

3.重排段：小模型决定上限

向量召回的 top-k 里常有语义相近但主题偏离的片段，重排模型的作用是把真正相关的那几条顶上来。这一段的价值在长文档场景尤其明显，往往是 “上了重排之后准确率突然跳一档” 的原因。

4.生成段：提示组织比模型选择更重要

同一批召回片段，组织方式不同结果差别很大：给编号、要求引用来源编号、明确 “资料不足时说不知道”，这三条约束能显著降低编造率。生成模型换不换，放在这之后考虑。

三、多段接口不在同一家时的统一入口

RAG 链路天然是多模型的：向量模型、重排模型、生成模型往往来自不同厂商。如果每段各自接一套 SDK，参数口径和错误处理都会分裂，回归测试几乎无法自动化。

用统一网关把四段收敛到同一个入口，好处有三个：调用代码只有一套，切换任意一段的模型只改 model 参数；日志集中，能按请求维度看到四段的耗时与 token 消耗，定位瓶颈不再靠猜；回归测试可以整链回放，改一个参数就能重跑全量评测集。Token5u 这种把多模型接入与调用明细放在同一入口的方式，对做链路级回归的团队来说省掉的正是最枯燥的那部分工作。

四、回归测试要做成固定动作

链路稳定后，把它固化成一套回归集：50 到 100 条覆盖典型问题类型的样本，每次改动切分参数、换向量模型、调提示模板之前跑一遍，记录准确率、引用命中率、平均 token 消耗三个指标。这套基线建立起来之后，任何 “感觉变差了” 的模糊反馈都能落到具体数字上。

总结

RAG 效果问题要先分段定位，再逐段优化：切分看粒度与语义完整性、向量化看版本一致性、重排看上限、生成看提示组织。四段接口尽量收敛到一个统一入口，链路才具备可观测和可回归的基础。把回归集当成上线前的固定动作，比每次凭感觉换模型要可靠得多 —— 毕竟多数 “模型不行” 的结论，最后都落在了检索上。