RAG 系统为什么效果不稳：先排查检索链路再谈生成

很多人做 RAG 时，最先盯着的是模型回答得准不准。但实际项目里，RAG 效果不稳的时候，问题往往不在“生成”这半段，而在“检索”前面就已经歪了。

用户觉得回答不靠谱，常见现象通常有：

1. 明明知识库里有内容，却没检出来
2. 检出来的片段很多，但和问题不贴
3. 回答看着流畅，实际上引用错了上下文
4. 同一个问题多问几次，答案风格和依据飘得很厉害

这些问题如果只从 prompt 或模型温度去修，通常治标不治本。

第一步先分清楚：是没检到，还是检到了没用上

RAG 排查最关键的一步，是先把问题拆成两层：

1. 检索是否正确
2. 生成是否正确利用了检索结果

很多人把两层混在一起看，结果会非常难定位。其实只要把检索结果单独拿出来，你很快就能知道问题发生在哪一段。

如果检索内容本身已经不对，那后面生成再强也救不回来。

切块策略是最容易被低估的一环

知识文档切块如果做得太粗，模型拿到的信息块会太大，噪声很多；切得太碎，又会让上下文断裂，重要信息被拆开。

这一步最常见的问题包括：

1. 按固定长度机械切分
2. 不考虑标题和段落边界
3. 代码、表格、说明文混切
4. 上下文延续信息没保留

RAG 的很多“回答不稳”，其实从切块那一刻就埋下来了。

向量检索不是加上就万事大吉

不少系统一接入向量库，就默认检索问题已经解决了。实际中，向量检索也很容易出现偏差，尤其是在：

1. 问题很短
2. 用户说法和文档表达不一致
3. 文档中概念很相近
4. 需要时间、版本、状态等结构化条件过滤

这时候只靠相似度，往往不够。

更稳的做法通常是把：

1. 关键词召回
2. 向量召回
3. 元数据过滤

一起组合起来，而不是单押一种方式。

重排这一步经常决定上限

很多系统召回了十几条片段，就直接把前几条喂给模型。问题是召回不等于排序正确。

如果没有重排，真正最相关的内容可能排在后面，模型最终吃到的上下文就不够准。

所以在中小项目里，哪怕先不上很复杂的架构，至少也值得考虑：

1. 对召回结果做相关性重排
2. 按问题意图重新排序
3. 控制进入生成阶段的上下文数量

不然文档越多，噪声越大，效果反而更不稳。

很多问题其实不是“模型幻觉”，而是证据不完整

用户看到答错，第一反应常常是“模型幻觉了”。但在 RAG 里，更常见的情况其实是：

1. 检索片段不完整
2. 关键约束没被召回
3. 引用片段互相矛盾
4. 历史版本和当前版本混在一起

这种情况下，模型不是完全凭空乱说，而是在不完整证据上做了看似合理的拼接。

所以提升 RAG 稳定性，很多时候优先级应该是“提升证据质量”，而不是一味压模型自由度。

元数据设计会直接影响可控性

如果文档入库时没有带好元数据，后面排查和过滤会很难做。

比较有价值的元数据通常包括：

1. 文档来源
2. 更新时间
3. 业务分类
4. 产品版本
5. 权限范围

一旦这些信息缺失，系统就很难在检索阶段把“旧文档”和“当前文档”、“公开文档”和“内部文档”分清楚。

一个更实用的排查顺序

如果你的 RAG 回答不稳，我更建议按这个顺序查：

1. 先看原始问题
2. 再看召回的片段是不是对
3. 再看排序是不是合理
4. 再看送进模型的上下文是不是太多或太杂
5. 最后才去调 prompt 和生成参数

这样你能更快判断问题到底在数据、检索还是生成层。

中小项目先把哪几步做好最划算

如果资源有限，我更建议优先补这几件事：

1. 合理切块
2. 召回结果可观测
3. 基础重排
4. 文档元数据过滤
5. 回答里保留引用依据

只要这几步做稳，RAG 系统的可靠性通常就会比“只接一个向量库 + 直接问模型”高很多。

结语

RAG 效果不稳，很多时候不是因为模型不够强，而是检索链路本身没有梳顺。只要先把切块、召回、重排和上下文质量这几个环节看清楚，再去谈生成，系统效果才更容易稳定下来。

对个人知识库和中小型应用来说，这一步往往比盲目换模型更值。