RAG 答非所问,八成不在模型,在检索

「我们换了最新最强的模型,知识库怎么还是答不准?」这是我们被问得最多的问题之一。每次听到,我们的第一反应都是:先别动模型,把检索这一段拆开看看。

RAG 的全称是检索增强生成,关键词是「检索」在前。模型再聪明,如果你递给它的参考资料本身就是错的、缺的、或者驴唇不对马嘴,它也只能基于错误的信息一本正经地胡说。大多数答不准的问题,根子都在生成之前的那几步。

第一步:文档到底解析对了没

很多人忽略了最前面这一步。一份带复杂表格的 PDF、一个扫描版的合同、一张嵌在文档里的流程图,如果解析环节就把内容读错、读漏、把表格拍扁成一行乱码,那后面再精细的检索都是在错误的素材上打转。我们做项目时,通常会先抽查一批文档的解析结果,确认关键信息没有在第一步就丢掉。

第二步:切分,粗暴按字数切是大忌

把文档切成小块再向量化,是 RAG 的常规操作。但如果只是机械地每 500 字切一刀,很容易把一段完整的论述拦腰斩断,或者把一个表格的表头和数据分到两块里。检索时召回了半截内容,模型自然答不全。按语义、按章节结构来切,效果往往立竿见影。

“RAG 优化是个体力活:别指望一个参数搞定一切,得一层一层往下看,问题常常藏在你以为最不会出错的地方。

第三步:召回和重排序,不是一回事

向量召回负责从海量片段里快速捞出一批「大概相关」的内容,但它捞得快、也捞得糙。如果直接把召回的前几条塞给模型,里面常常混着相关性一般的噪音。加一层重排序(rerank),用更精细的模型对召回结果再排一次序,把真正相关的顶上来,准确率往往能上一个台阶。这一步,很多团队直接跳过了。

第四步:别忘了提示词和兜底

前面都做对了,最后还要管好生成。比如明确告诉模型「只能依据给定资料回答,没有就说不知道」,能大幅减少一本正经的瞎编。再比如把答案的来源片段一并展示出来,让用户能点开核对,既增加了可信度,也方便排查问题。

一个排查顺序

下次再遇到知识库答不准,不妨按这个顺序往下查,而不是第一时间换模型:

1. 1抽几个答错的问题,看模型拿到的参考片段对不对
2. 2片段不对,往回查召回和重排序
3. 3召回里压根没有正确内容,往回查切分
4. 4切分没问题但内容是错的,往回查文档解析
5. 5参考片段都对、模型还答错,这时候才轮到提示词和模型本身

还有一个慢性病:知识过期

前面说的多半是「一次性」的问题,还有一类是慢性的:文档更新了,知识库却还停在旧版本。用户问的是最新政策,系统却信誓旦旦地拿一份去年就作废的文件来回答。这种错误最危险,因为它看上去一点毛病都没有。所以知识库上线之后,得有一套机制保证文档变了、索引也跟着更新,而不是建完就撒手不管。

怎么知道到底改好没有

优化 RAG 还有个常被跳过的环节:评估。很多团队凭感觉调,改完随手问几个问题,觉得「好像好点了」就上线。更靠谱的做法,是攒一批真实问题加标准答案,每次改动后都跑一遍,用数字看准确率到底是涨了还是跌了。没有这把尺子,你永远在凭手感,改了半天也说不清有没有真进步。

我们的经验是,十次里有八九次,问题在你换模型之前就能找到。RAG 不是玄学,它是一条有头有尾的流水线,耐心顺着查,总能找到那个掉链子的环节。

留下你的场景和痛点,我们帮你判断从哪一步开始。