RAG 搭起来容易，但要准很难。很多知识库问答答非所问，根子不在大模型，而在检索这一步只用了一种办法。混合检索加重排序，是把它准确率拉上去的两块拼图。很多团队一上来怪模型不行，其实根子在召回。
快速结论
- 只用向量检索遇专有名词、型号、编号会失准，关键词匹配反而更靠谱。
- 混合检索把向量和 BM25 融合，语义相关加精确命中，覆盖率直接上去。
- 重排序用更细的小模型把对的顶到第一，很多 RAG 效果差一倍就在这一步。
- 只对召回的几十候选重排，别对全库排；中文场景特意测中文 query 质量。
只用向量检索的短板
向量检索按「意思接近」找，但遇到专有名词、型号、编号这类靠精确匹配的词，它反而不准。用户搜「型号 XT-200」，向量可能给你一堆意思沾边但完全不是这个型号的内容。这时候关键词匹配反而更靠谱。纯向量方案在口语化长尾上强，在专业术语密集的文档上弱，这是它的结构性短板，不是调参能补的。
混合检索与重排序
图：核心要点 核心要点（运营GO 整理）
| 步骤 | 做什么 | 参数建议 |
|---|---|---|
| 检索层 | 同时跑向量和关键词 | 融合前 30 条左右 |
| 重排序 | rerank 模型重新打分 | 精选前 3 到 5 段 |
| 召回数 | 先捞多再精排 | 20 到 50 条候选 |
| 评估 | 看前几段对不对题 | 用真实问题复测 |
怎么落地
检索层同时跑向量和关键词，融合前 N 条；用 rerank 模型对这 N 条重新排序，只取前几段喂给大模型。召回数调大一点（比如先捞 30 条），再让 rerank 精选，比只捞 5 条更稳。上线前拿真实问题看「召回的前几段材料对不对题」，如果材料都错了，换再强的模型也白搭。融合后若某类查询仍偏科，单独调那一路权重而非整体重来。融合权重没有定值：专业术语多的场景关键词权重调高，口语化长尾多的场景向量权重调高，上线前拿真实查询看召回，哪个偏了就调哪个。
rerank 模型怎么选
重排序模型不是越贵越好，要看它和你语种的匹配。中文场景特意测一下中文 query 的重排质量，别直接套英文默认的。很多开源 rerank 模型中文表现已经不错，小团队从开源起步足够，等量大了再考虑更重的方案。小团队先用开源 rerank 跑通链路、跑出基线再谈升级。重排序模型每次调用也要算钱和耗时，所以别对全库重排，只对召回的几十候选排。量小的内部知识库，混合加轻量 rerank 足够；真到百万级文档再考虑更重的重排方案。
评估要贯穿始终
混合检索加重排序每一步都能量化：召回率、前 N 命中率、最终答案准确率。每次调参数都拿同一批问题复测，你才知道哪一步真的起了作用。离线用固定题集看召回率，在线看用户实际是否满意（比如有没有继续追问），两者结合才完整：离线过了但线上仍答非所问，多半问题出在生成或资料本身，不是检索。把每周新增的真实问题回流进题集，评估才不会被自己的历史题带偏。RAG 的准确率七成在检索、三成在生成，这一步做好了，答案质量常有肉眼可见的提升。
在线和离线评估
离线用固定题集看召回率，在线看用户实际是否满意（比如有没有继续追问、有没有点踩）。两者结合才完整：离线过了但线上仍答非所问，多半问题出在生成或资料本身，不是检索。建议每周拉一批真实用户问题进离线题集，题集越像生产流量，评估越准。
候选数怎么定
召回多少条去 rerank 有讲究：太少漏掉对的，太多拖慢且稀释。一般先捞 20 到 50 条候选，rerank 精选出前 3 到 5 条喂模型。用你的真实查询调这个数，别照抄别人的配置——文档量小取下限，百万级文档取上限并配合更重的重排。
一个最小可行链路
别一上来就上最重的方案。最小可行链路是：向量库接 BM25，两者结果各取前 20 融合成 30 到 40 条，用一个轻量 rerank 模型精排到前 5，再喂大模型。这条链路在几万到几十万文档上就能看到明显提升，成本也低。跑通并拿到评估数字后，再决定是否换更重的重排或加精排层。先有可测量的基线，每一步优化才知道值不值。
常见踩坑
坑一：只调模型不调检索，答非所问却怪模型弱。坑二：召回数太小，对的材料根本没进候选，rerank 再强也救不回。坑三：融合权重写死，术语多的库却让向量占大头。坑四：拿别人的题集评估，和你生产流量分布不符，上线才露馅。每个坑对应的解法都是「先用真实问题看召回的前几段对不对题」，这一关过了再谈别的。
下一步行动清单
- 在现有向量库上叠加 BM25 关键词检索，做一层融合。
- 选一个 rerank 模型，对召回的 20 到 50 条候选重新排序。
- 用真实业务问题建一套固定题集，记录每一步的命中率。
- 按数据类型调融合权重，中文 query 单独测重排质量。
- 上线前确认召回的前几段材料对题，再谈换更贵的模型。
