搭 RAG 或站内搜索时，绕不开一个选型问题：用向量检索、传统的 BM25 关键词检索，还是两个都上（Hybrid Search）？社区的主流答案是「都上」，但很多团队并不清楚为什么，也不清楚融合参数怎么定。这篇文章把三种方式的能力边界讲透，再给出按场景的选型建议——因为「都上」也是有成本的，不是所有场景都值得。
向量检索按「意思」找，BM25 按「字面」找，两者的失手场景刚好互补。
三种检索方式各自在干什么
BM25：按词找，精确但死板
BM25 是经典的词频统计算法（Elasticsearch 的默认打分方式）：查询和文档共享的词越多、越稀有，分越高。它的强项是精确匹配——产品型号、错误码、人名、法条编号、API 名称，只要用户输入的词出现在文档里，基本跑不掉。弱项也很直接：换个说法就找不到。用户搜「报销流程」，文档里写的是「费用核销办法」，BM25 一分不给。中文场景还要注意分词质量，分词切错，BM25 直接失明。
向量检索：按意思找，聪明但会看走眼
向量检索把查询和文档都通过 Embedding 模型映射成向量，在向量数据库里按相似度找最近邻。它天然理解同义改写——「报销流程」和「费用核销办法」在向量空间里离得很近。但它的弱点恰好是 BM25 的强项：
- 专有名词和编号失手：「ERR-4032」和「ERR-4033」的向量几乎重合，但对用户是两个完全不同的问题；
- 域外词汇不认识：公司内部的项目代号、黑话，embedding 模型训练时没见过，向量表达接近随机；
- 永远返回结果：不管库里有没有相关内容，最近邻总是存在的，需要靠阈值兜底，否则给下游喂噪声。
Hybrid Search：并跑再融合
Hybrid Search 就是同一个查询同时走 BM25 和向量检索，把两份结果融合成一个排序。最常用的融合方法是 RRF（Reciprocal Rank Fusion）：不看两边各自的分数（量纲不同没法直接比），只看排名，每个文档的融合分是 Σ 1/(k + rank)（k 通常取 60）。在哪边排名靠前都能加分，两边都靠前的文档融合后最靠前。
查询: "ERR-4032 上传失败怎么处理"
BM25 结果: 向量检索结果:
1. ERR-4032 处理指南 1. 文件上传常见问题
2. 错误码总表 2. 上传接口超时排查
3. 上传接口文档 3. ERR-4032 处理指南
RRF 融合后:
1. ERR-4032 处理指南 ← 两边都命中，稳居第一
2. 上传接口文档 / 错误码总表 / 文件上传常见问题 ...比 RRF 更进一步的是加权融合（如 Weaviate 的 alpha 参数、Milvus 的 WeightedRanker），可以调节语义和关键词的比重；再往上就是把融合交给 Rerank 模型统一重排——见《Rerank 是什么？为什么 RAG 经常需要重排》。
实测感受：Hybrid 好在哪，好多少
我们在一个混合了技术手册、制度文档和工单记录的中文知识库上对比过三种模式，结论和学术界、各向量库官方的评测方向一致：
| 查询类型 | BM25 | 向量 | Hybrid |
|---|---|---|---|
| 含型号/编号/专名 | 强 | 弱 | 强 |
| 同义改写、口语化提问 | 弱 | 强 | 强 |
| 长句多条件描述 | 中 | 强 | 强 |
| 库外问题（应返回空） | 较好 | 差 | 中（需配阈值） |
整体检索命中率上，Hybrid 相对单独向量检索通常有个位数到十几个百分点的提升，提升幅度取决于查询里「精确匹配型」问题的占比——技术支持、法务、电商 SKU 这类场景提升最明显；纯闲聊式问答提升有限。
判断要不要上 Hybrid，先统计你的真实查询里有多少是「带编号、带专名」的精确匹配型问题。
按场景选型
- 内部知识库 / 技术支持 / 法务合同：Hybrid，几乎无悬念。这类场景专名和编号密集，单向量必然漏。
- 口语化 C 端问答、闲聊式助手：先上纯向量，够用就不加。查询里几乎没有精确匹配需求时，Hybrid 收益小。
- 代码检索：BM25 权重要高（标识符就是关键词），配合按函数切分；纯向量检索代码效果普遍一般。
- 电商 / 商品搜索：Hybrid + 结构化过滤（类目、价格、品牌走 metadata filter），检索只负责语义部分。
- 已有 Elasticsearch 的团队：ES 8.x 自带 dense vector 和 RRF，直接在现有集群上开 Hybrid，不必新引入向量库。
工程上还有一个隐藏成本要提醒：Hybrid 意味着同时维护两套索引（倒排 + 向量），写入、删除、重建都要双写，数据一致性问题会多一倍。Qdrant、Weaviate、Milvus、pgvector（配 pg_trgm/tsvector）等主流方案现在都内置了稀疏向量或 BM25 支持，尽量选「一个库里开两种索引」的方案，别自己缝合两个系统。
落地清单
- 从真实查询日志里抽 100 条，人工分类：精确匹配型占比多少？
- 精确型 > 20%，直接上 Hybrid；否则先纯向量 + 阈值兜底。
- 融合先用 RRF 默认参数（k=60），不要一上来就调权重。
- 建 50 条评估集，分别跑 BM25 / 向量 / Hybrid 三组，用数据确认收益。
- 上线后把「检索空结果」和「低分命中」的查询记下来，它们是语料和分词的补课清单。
选型顺序：先看查询构成，再跑小规模对比，最后才是调融合参数。
适用人群与替代方案
适合正在做 RAG 检索层选型、或对现有检索效果不满意的工程团队。两个替代思路值得知道：一是查询改写，用模型把口语化问题改写成规范查询，有时比换检索方式更有效，成本也低；二是对小语料（几万字以内）直接放弃检索，把全文塞进上下文窗口，检索层的所有复杂度都消失了。检索只是手段，答准才是目的。
常见问题
Q：Hybrid Search 会显著增加延迟吗？ A：两路检索是并行的，延迟取决于慢的那一路，通常增加 10–50ms 量级，对 RAG 整体延迟（生成占大头）影响很小。
Q：中文 BM25 有什么特别要注意的？ A：分词器质量决定一切。建议用 IK、jieba 等成熟分词器并维护自定义词典，把产品名、项目代号加进去；也可以考虑字级 n-gram 兜底。
Q：稀疏向量（如 SPLADE、BGE-M3 的稀疏输出）算 BM25 吗？ A：思路同源但更强——它用模型学出来的词权重代替统计词频，还能做词扩展。如果你的向量库支持稀疏向量，用它替代 BM25 做 Hybrid 是目前效果更好的组合。
小结
三句话总结选型：查询里专名编号多，Hybrid 必上；纯口语化问答，向量加阈值就够；无论选哪种，先建评估集再下结论。检索层的目标不是技术先进，而是让下游的生成环节拿到干净、相关、可引用的材料。