混合检索
稠密向量（语义）+ 稀疏向量（关键词）+ RRF融合，生产级RAG系统的标准检索组合
简介
混合检索（Hybrid Search）是结合多种检索方式的技术策略，在RAG系统中特指**稠密向量检索（Dense Vector）+ 稀疏向量检索（Sparse Vector）+ 结果融合（RRF）**的组合。稠密向量通过深度学习模型捕获文本的语义相似性，擅长理解同义词和隐含意图；稀疏向量（如BM25）基于统计方法捕获关键词精确匹配，擅长处理专有名词和特定术语。两者结合后通过Reciprocal Rank Fusion（RRF）融合排序，既不遗漏语义相关的结果，也不丢失关键词精确匹配的结果，是生产级RAG系统的常见架构选择。
关键信息
| 项目 | 内容 |
|---|---|
| 类型 | 技术方法 |
| 核心组成 | 稠密向量 + 稀疏向量 + 结果融合 |
| 稠密向量 | FloatVector，维度通常512-1024-3072，捕获语义相似性 |
| 稀疏向量 | SparseFloatVector（BM25），捕获关键词匹配 |
| 融合策略 | RRF（Reciprocal Rank Fusion） |
| 适用场景 | 企业文档检索、客服知识库、法律/医疗专业领域 |
核心特性
为什么需要混合检索
单一稠密向量的局限：
- 对专有名词、产品型号、法条编号等精确匹配需求不敏感
- 可能召回语义相近但事实不符的文档
- 例如：用户问”SK-II神仙水”，纯语义检索可能返回”雅诗兰黛小棕瓶”（都是精华液），而用户需要的是包含”SK-II”精确品牌名的文档
单一关键词检索的局限：
- 无法理解同义词和隐含意图
- 对查询改写和语序变化敏感
- 例如：用户问”如何退款”，关键词检索只能匹配”退款”，无法召回”退货流程""订单取消”等语义相关文档
混合检索的优势：
- 稠密向量捕获语义，召回率高
- 稀疏向量补强精确匹配，准确率高
- RRF融合避免单一排序的偏差
技术实现架构
以Milvus为例的混合检索架构：
文档入库流程：
原始文档 → 文本切分 → 稠密向量化（Embedding模型）+ 稀疏向量化（BM25）→ Milvus集合
↓
集合字段：content / dense_vector / sparse_vector
查询流程：
用户问题 → 查询向量化（稠密+稀疏）→ Milvus混合检索 → RRF融合排序 → TopK结果Milvus集合字段设计：
{
"dense_vector": "FloatVector, dim=1024", # 稠密语义向量
"sparse_vector": "SparseFloatVector (BM25)", # 稀疏关键词向量
"content": "VarChar", # 原文文本
"metadata": "JSON" # 元数据（标题、来源等）
}检索权重调整：
- 默认：稠密向量权重0.7，稀疏向量权重0.3
- 专有名词密集领域（如医药、法律）：可调整为0.5 : 0.5
- 用户意图模糊场景（如泛化问答）：可调整为0.8 : 0.2
RRF融合策略
Reciprocal Rank Fusion（倒数排名融合）是一种简单但有效的结果融合方法：
# 伪代码
for doc in all_docs:
score = 0
if doc in dense_results:
score += 1 / (k + rank_in_dense_results)
if doc in sparse_results:
score += 1 / (k + rank_in_sparse_results)
final_score[doc] = score
# k 通常取 60，用于平滑排名差异RRF的优势：
- 不依赖于每种检索方法的原始分数（避免分数尺度不一致问题）
- 对排名靠前的文档给予更高权重
- 计算简单，无需训练
不同素材中的观点
来自 2026-05-30-ai-rag-production-100-yuan：
- 天涯轩在100元RAG实验中使用Milvus 2.5.x实现稠密向量（1024维）+ BM25稀疏向量的混合检索
- 集合字段包含：document_id（分区键）、content、dense_vector（1024维）、sparse_vector（BM25）、chunk_index、metadata JSON，以及doc_type、source、author等过滤字段
- 设计意图：稠密向量捕获语义，稀疏向量补强关键词匹配；混合检索 + RRF融合是生产RAG的常见组合
- 核心经验：相似度阈值不应在retrieve阶段硬过滤（通义v3分数常在0.2-0.45，设0.7阈值会全部被过滤），而应由后续的Rerank和Grade节点承担质量控制
实用信息
适用场景
- 企业文档检索：内部文档既包含专有名词（产品型号、项目代号）也包含自然语言描述
- 客服知识库：用户可能用口语化表达（“订单没了”）也可能用精确术语（“订单编号12345”）
- 法律/医疗专业领域：需要精确匹配法条编号、药品名称，同时理解自然语言查询
- 多语言混合场景：稠密向量支持跨语言语义检索，稀疏向量补强原语言关键词匹配
不适用场景
- 纯精确查询：如数据库主键查询、订单号查询（传统数据库更高效）
- 实时性要求极高：混合检索比单一检索慢（需两次检索+融合），延迟敏感场景需权衡
- 简单FAQ匹配：如果FAQ库很小（<100条）且问题固定，关键词检索或规则匹配更简单
实现工具
- Milvus：原生支持稠密+稀疏向量混合索引，提供RRF融合API
- Elasticsearch + 向量插件：Elasticsearch 8.0+支持dense_vector字段，可结合BM25实现混合检索
- Weaviate：支持混合检索，但稀疏向量需自行实现BM25
- LangChain：提供EnsembleRetriever封装多个检索器并融合结果
调优建议
- 权重调优：根据业务场景A/B测试稠密/稀疏权重比例
- 阈值后置：不在检索阶段硬过滤低分结果，由Rerank或LLM评估承担质量控制
- 分块策略配合：文档切分时保留标题、章节等元数据，便于稀疏向量匹配关键词
- Embedding模型选择：稠密向量效果高度依赖Embedding模型质量，建议实测不同模型在自家语料上的表现