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

去年参与一个技术文档问答系统开发，上线第一天就遭遇用户提问：

“怎么处理登录超时？”

系统回答：“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做即可，否则速度太慢。

五、完整链路数据

一个实验一个实验积累下来的数据：

• 基线：纯向量检索 → 召回率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。一步步来，效果是累积的。

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