做了3个RAG项目，我把召回率从78%折腾到了92%

一、第一个项目，上线第一天就翻车了

去年做一个技术文档问答系统，上线第一天，用户问了一个问题：

“怎么处理登录超时？”

系统回答：“timeout参数的默认值是30秒。”

用户当场炸了：“我问的是怎么处理，不是参数是多少！”

我查了日志，发现问题出在检索环节——用户问题里的“处理”，和文档里的“排查步骤”，向量距离很远，根本没召回来。

那一刻我才意识到：RAG的核心不是大模型，是检索。大模型再强，没召到对的文档，也是白搭。

二、第一次优化：换Embedding模型，白捡5个点

一开始图省事，用了开源的通用Embedding模型。跑测试集，召回率只有78%。用户问10个问题，有2个答案根本不在前5条结果里。

后来换了BGE-large-zh，什么都没改，只是换了模型，召回率直接到了83%。

教训很直接：Embedding模型是召回率的天花板。天花板低了，下面怎么折腾都没用。

选型建议（纯经验）：

• 中文通用场景：BGE-large-zh，平衡效果和速度
• 追求极致效果：text-embedding-3-large（效果好，但走API）
• 本地部署、资源有限：M3E-large

怎么做判断？拿3个模型跑你的测试集，谁高用谁。

三、第二次优化：加混合检索，又涨了5个点

换完模型，发现还有漏网之鱼。

用户问：“API key怎么申请？”文档里写的是“获取访问凭证”。语义相近，用词完全不同，向量检索表现一般。

解决方案是混合检索：向量检索 + 关键词检索（BM25）。向量负责语义，关键词负责精确匹配，两个结果融合排序。

加了混合检索后，召回率从83%到了88%。

这一步是性价比最高的优化，不需要换模型，不需要重新训练，改几行代码就能看到效果。

四、第三次优化：加Reranker，首位命中率大幅提升

混合检索之后，Top 5召回率到了88%。但用户反馈还是有问题：正确答案虽然在Top 5里，但经常排在第4、第5位。用户没耐心往下翻，直接说“系统找不到”。

解决方案：加Reranker。在召回结果上，用CrossEncoder模型重新打分，把最相关的排到最前面。

加了Reranker之后，首位命中率从45%提到了68%。用户满意度明显上升，因为第一个就是对的。

注意：Reranker不需要对全量文档做，只对召回后的Top 20做就行，否则太慢。

在具体实现上，我们后来用了ZGI作为RAG检索的编排平台，混合检索和Reranker都是内置能力，省了不少自研时间。

五、完整链路数据

我一个实验一个实验做下来的数据：

• 基线：纯向量检索 → 召回率78%
• 第一轮：换BGE模型 → 召回率83%（+5%）
• 第二轮：加混合检索 → 召回率88%（+5%）
• 第三轮：加Reranker → 召回率92%（+4%）
• 第四轮：领域微调 → 召回率94%（+2%）

结论：

• 混合检索是性价比最高的优化，改几行代码涨5个点
• Reranker是提升体验的关键，决定用户第一眼看到什么
• 领域微调收益最低，不是非常刚需可以先不做

六、三个最容易踩的坑

坑一：不用测试集，凭感觉优化

没有测试集，你根本不知道改完是变好了还是变差了。花一天时间标注100个问题-答案对，后面所有优化都有方向。

坑二：召回和排序混为一谈

召回阶段的目标是“别漏掉”，排序阶段的目标是“把最对的放第一个”。两个阶段的优化手段不同，不要混着调。

坑三：一上来就搞Reranker

Reranker很慢，也很贵。先用好Embedding和混合检索，这两步能解决80%的问题。

七、给同行的实操建议

• 先跑通测试集。没有测试集，所有优化都是盲人摸象。
• 优化顺序别搞反。先换Embedding模型，再加混合检索，最后上Reranker。这个顺序的投入产出比最高。
• 线上一定要加Reranker。它不是召回率的瓶颈，但是体验的关键。用户没耐心翻到第3条。

八、写在最后

RAG召回优化没有什么秘籍。

就是选对Embedding、加上混合检索、配上Reranker。一步步来，效果是累计的。

如果你也正在被召回率困扰，希望这篇文章能帮你少踩几个坑。毕竟，这些坑我都帮你踩过了。

本文基于RAG项目实战经验整理。