博客园-RAG系统召回率上不去的三个工程坑

RAG系统召回率上不去？我们项目踩过的三个工程坑

最近在做企业知识库RAG落地，前前后后调了快两个月，一开始召回率死活上不去，以为是向量模型选得不好，换了好几个开源模型，结果发现根本不是模型的问题，全是工程实现上踩的坑。今天把我们踩过的三个最典型的坑写出来，给做RAG的同行做个参考。

第一个坑：文档切片切得太粗或太细

最开始我们的切片策略特别简单：按固定长度切，每片512个token，重叠64个。结果一测召回率，才40%多。
为啥？因为很多长文档里，一个完整的知识点被切成了两半，向量检索的时候只召回来一半，大模型看到的是不完整的内容，回答自然不对。
后来我们改成了按语义切片：先按章节、标题拆分，再根据段落语义切，一个完整的段落不拆开。改完之后召回率直接涨到了70%多。
当然也不能切太细，把一个句子拆成好几片，那样每片的语义太碎，向量相似度计算根本不准。这个切片大小还是要根据自己的文档类型调，我们现在企业文档一般切成300-500token一片，效果最好。

第二个坑：只做向量检索，不做混合检索

一开始我们纯靠向量相似度召回，就是用户query做embedding，跟文档向量算余弦相似度，取top5。
结果测试的时候发现，很多包含专有名词的query，向量检索根本召不回来。比如用户问"我们公司的报销流程是什么"，因为query里的"报销"和文档里的"费用审批流程"语义接近，但向量检索的相似度就是不够，排到十几名去了，根本进不了top5。
后来我们加了BM25关键词检索，把向量检索的结果和关键词检索的结果做融合，就是常说的混合检索。加完之后，那些带专有名词的query召回率一下子就上去了，整体召回率到了85%以上。
这个真的是我们踩了特别久的坑，一开始觉得纯向量检索是银弹，结果实际落地的时候，纯向量对专有名词的召回就是不好用，必须加关键词检索做补充。

第三个坑：召回了top5，但没做重排序

最开始我们就是向量检索取top5，直接丢给大模型做生成。
后来发现一个问题：有时候最相关的那段文档，向量相似度排到了第6、第7名，被我们截掉了，而排前面的几个其实相关度没那么高。
我们加了个重排序模型，把向量检索召回的top20个结果，用rerank模型重新打分排序，再取最相关的前5个丢给大模型。这一步改完之后，回答的准确率又涨了10%左右。
很多人觉得重排序是个可有可无的优化，但实际做下来，这一步带来的提升比换个向量模型还明显。

最后说两句

RAG这个东西，看起来简单：embedding+向量数据库+大模型，好像拼起来就能用。但真要做好，全是工程细节。很多人上来就追最新的模型、最大的向量库，结果基础的切片、检索、重排序都没做好，召回率当然上不去。
我们现在整体的回答准确率已经到90%多了，回头看，80%的提升都是来自工程细节的优化，不是靠换什么牛逼的模型。