RAG 中的混合检索是什么？常见实现方式一篇讲清楚
在 RAG 系统中，混合检索（Hybrid Retrieval）就是把多种检索方法结合起来，取长补短，从而提高召回率和检索准确性。
最典型的组合就是：
关键词检索（BM25）
+
向量检索（Vector Search）
为什么需要两种？
因为它们各有优缺点。
假设用户搜索：
如何修改数据库密码？
知识库里写的是：
How to reset database credentials
虽然关键词不一样，但语义相同。
这种情况：
向量检索 ✅
关键词检索 ❌
但如果用户搜索：
ERR-10293
SKU-A9281
GPT-5.6
这种 Error Code、型号、专有名词，关键词搜索通常更可靠。
所以：
BM25：擅长精确匹配
Vector：擅长理解语义
把两者结合起来，就是最常见的 Hybrid Search。
一、最常见：并行召回 + 加权融合
我之前比较常用的一种方式就是：
用户 Query
│
┌────────┴────────┐
↓ ↓
Vector Search BM25 Search
↓ ↓
Top K Top K
└────────┬────────┘
↓
Score Fusion
↓
Top K
也就是同时执行：
KNN 向量检索
+
全文关键词检索
然后把两个结果合并。
最简单的方法就是加权：
Final Score
=
α × Vector Score
+
(1-α) × BM25 Score
比如：
Vector = 0.8
BM25 = 0.6
α = 0.7
最终：
Score
= 0.7 × 0.8
+ 0.3 × 0.6
= 0.74
如果系统主要是自然语言问答，可以让 Vector 权重大一点。
如果系统里有很多：
产品型号
人名
Error Code
API 名称
法律条款
专业术语
则可以提高 BM25 权重。
不过这里有一个坑：
BM25 Score 和 Vector Score 的数值范围往往不同，不能总是直接相加。
因此实际工程中通常要先做 Score Normalization，再加权。Elastic 将这种方式称为 Linear/Convex Combination；Pinecone 的 dense+sparse hybrid 也需要考虑两种信号的尺度并进行权重控制。(Elastic )
二、RRF：比手动调权重更省心
另一种非常常见的方法叫：
RRF（Reciprocal Rank Fusion）
它和上面的思路不同。
RRF 不太关心：
Vector Score = 0.87
BM25 Score = 12.6
而更关心：
这篇文档在各个检索结果里面排第几名？
例如：
Vector Search：
1. Doc A
2. Doc C
3. Doc B
BM25：
1. Doc B
2. Doc A
3. Doc D
Doc A：
Vector 第 1
BM25 第 2
两边表现都很好，所以最终排名会非常高。
RRF 大致可以理解为：
RRF Score =
1 / (k + Vector Rank)
+
1 / (k + BM25 Rank)
最大的好处就是：
不用纠结 BM25 和 Vector Score 的单位和范围。
Elastic 目前也把 RRF 作为 Hybrid Search 的推荐融合方法之一。(Elastic )
所以如果你不知道权重怎么调：
BM25 + Vector
↓
RRF
通常是一个非常不错的起点。
三、串行检索：先召回，再过滤
还有一种就是我之前采用过的思路：
Query
↓
KNN Vector Search
↓
召回 Top 100
↓
关键词 Filter
↓
Top 20
这和前面的“并行检索 + 加权融合”是不一样的。
它属于：
级联检索 / 串行检索。
例如用户问：
GPT-5.6 的缓存策略是什么？
可以先通过 Vector Search 找到：
100 个语义相关 Chunk
然后要求里面必须：
包含 GPT-5.6
最终只留下相关结果。
这种方法简单，而且可以明显减少误召回。
不过它有一个风险：
如果第一阶段 Vector Search 根本没有召回正确文档，那么第二阶段已经救不回来了。
因此：
第一阶段：
重点提高 Recall
第二阶段：
重点提高 Precision
这是多阶段 Retrieval 很重要的设计原则。
四、反过来也可以：BM25 召回 + Vector 重排
串行检索不一定非得 Vector 在前。
也可以：
Query
↓
BM25
↓
Top 100
↓
计算 Semantic Similarity
↓
重新排序
↓
Top 20
这种方式特别适合：
技术文档
法律文档
代码搜索
产品数据库
因为用户 Query 里面经常带有非常重要的精确关键词。
先用 BM25 保证：
关键词必须相关
再使用 Embedding：
判断语义到底有多相关
同样是很实用的 Hybrid Retrieval。
五、Dense + Sparse 混合检索
还有一种现在非常常见的方案：
Dense Vector
+
Sparse Vector
Dense Vector 就是我们熟悉的 Embedding：
[0.13, -0.82, 0.31, ...]
负责理解：
语义
同义词
上下文
Sparse Vector 更接近关键词检索思想：
database → 1.8
password → 2.4
reset → 1.2
负责：
关键词
专有名词
精确术语
然后：
Dense
+
Sparse
↓
Hybrid Score
例如 Pinecone 就支持把 Dense 和 Sparse 信号结合起来，并通过类似 alpha 的思想控制语义和 lexical 信号的相对权重。(Pinecone Docs )
本质上还是：
一个负责“意思像不像”，一个负责“词对不对”。
六、更成熟的方案：多路召回 + Reranker
生产环境里，我更推荐把 Hybrid Search 再往前走一步：
Query
│
┌──────────┼──────────┐
↓ ↓ ↓
BM25 Vector Sparse
↓ ↓ ↓
Top 50 Top 50 Top 50
└──────────┼──────────┘
↓
Fusion / RRF
↓
Top 50
↓
Reranker
↓
Top 5
↓
LLM
这里不同组件的任务非常明确。
第一阶段：
Retrieval
目标：
宁可多找一点，也尽量不要漏掉正确答案。
所以关注：
Recall
第二阶段：
Reranker
目标：
从召回结果中真正找出最相关的几个。
所以关注：
Precision
这也是很多生产级 RAG 常见的 Retrieval Pipeline：
多路召回
→ Fusion
→ Rerank
→ LLM
七、还可以动态调整 Hybrid 权重
更高级一点，不需要所有 Query 都使用：
Vector 70%
BM25 30%
而是先判断 Query 类型。
例如：
“公司报销流程是什么？”
属于自然语言问题：
Vector ↑
BM25 ↓
而：
ERR-92831 怎么解决？
明显包含 Error Code：
Vector ↓
BM25 ↑
于是系统可以变成：
Query
↓
Query Analyzer
↓
判断 Query 类型
↓
动态调整 Retrieval Strategy
例如：
自然语言问题
→ 80% Vector + 20% BM25
专有名词
→ 50% Vector + 50% BM25
Error Code / SKU / ID
→ 20% Vector + 80% BM25
这其实已经开始从简单 Hybrid Search 走向：
Adaptive Retrieval。
八、实际项目应该怎么选？
可以简单记成：
方案一：Weighted Fusion
BM25 + Vector
↓
Score 加权
优点：
简单
直观
权重可控
适合大多数基础 RAG。
方案二：RRF
BM25 Ranking
+
Vector Ranking
↓
RRF
优点：
不用处理不同 Score 的尺度
参数少
比较稳定
不知道怎么调权重时，可以优先尝试。
方案三：串行检索
Vector
↓
Keyword Filter
或者：
BM25
↓
Vector Rescore
优点：
架构简单
速度容易控制
但第一阶段 Recall 非常重要。
方案四：多路召回 + Reranker
BM25
+
Dense Vector
+
Sparse Vector
↓
Fusion
↓
Reranker
优点：
效果通常最好
缺点：
成本更高
延迟更高
架构更复杂
更适合生产级 RAG。
九、总结
所谓 RAG Hybrid Retrieval，本质并不复杂：
不要把找到正确文档的希望全部压在一种检索算法上。
关键词搜索擅长：
精确匹配
专有名词
ID
型号
Error Code
向量搜索擅长：
语义理解
同义表达
自然语言问题
因此一个比较成熟的 RAG Pipeline 往往是：
Query
│
┌────────┴────────┐
↓ ↓
BM25 Vector
↓ ↓
└───────┬─────────┘
↓
Weighted / RRF
↓
Top 50
↓
Reranker
↓
Top 5
↓
LLM
如果项目刚开始：
BM25 + Vector + RRF
通常已经是一个非常不错的方案。
等数据和 Query 越来越复杂，再逐渐升级到：
Query Rewrite
↓
Query Classification
↓
Multi-Retrieval
↓
Dynamic Weight / RRF
↓
Reranker
↓
LLM
这就是从基础 RAG逐渐走向生产级 RAG Retrieval Pipeline的过程。