在 RAG 系统中，检索层决定了 LLM 能看到什么证据。即使生成模型能力很强，如果关键文档没有被召回，最终答案仍然很难可靠。

因此，生产级 RAG 通常不会只依赖一种检索方式，而是组合：

Dense Search：按语义相似度检索
Sparse Search：按词项或稀疏特征检索

两者并行召回候选文档，再通过 RRF 等算法融合排名。这种方案通常称为 Dense + Sparse Hybrid Search。Qdrant、Elasticsearch、OpenSearch 和 Azure AI Search 等主流搜索产品都已原生支持混合检索。(Qdrant)

1. Dense Search：按语义检索

Dense Search 会使用 Embedding 模型，将查询和文档转换成固定维度的稠密向量：

用户问题
“孩子出生后可以暂停工作吗？”
        ↓ Embedding
[0.13, -0.28, 0.51, ...]

然后通过向量相似度搜索，找到语义上最接近的文档。

即使文档写的是：

员工可以根据育儿休业制度申请休假。

查询中没有出现“育儿休业”，Dense Search 仍可能理解两者表达的是相近概念。

Dense Search 擅长

  • 自然语言问题
  • 同义词和近义表达
  • 查询改写
  • 跨语言语义检索
  • 用户用词与文档原文不同的场景

Dense Search 的局限

Dense Search 对精确标识符通常不够稳定，例如：

ERR-1047
RFC 9110
X-Telegram-Bot-Api-Secret-Token
订单号 A-2026-0715

Embedding 可能认为两个相似编号在语义上接近，但在业务上，ERR-1047 和 ERR-1048 可能代表完全不同的问题。

此外，Dense Search 容易召回“主题相似”但不能真正回答问题的内容。

2. Sparse Search：按词项和稀疏特征检索

Sparse Search 的表示空间通常非常大，但每个文档只有少数维度非零。传统的 BM25 和倒排索引，是企业搜索中最常见的 Sparse 检索方式。

BM25 主要考虑：

  • 查询词是否出现在文档中
  • 词频
  • 词在整个语料库中的稀有程度
  • 文档长度

OpenSearch 默认使用 BM25 进行关键词搜索，并指出它擅长包含明确关键词的查询，但无法充分理解查询背后的语义。(OpenSearch Documentation)

Sparse Search 擅长

  • 产品型号
  • 错误代码
  • API 名称
  • 人名、公司名和专有名词
  • 法律条款编号
  • 精确短语
  • 数字、日期和缩写

例如查询：

ERR-1047 是什么？

BM25 通常能够直接找到包含 ERR-1047 的文档，而不会因为其他错误代码语义相似而混淆。

Sparse Search 的局限

Sparse Search 对表达变化不够敏感。

例如文档写：

育児休業

用户问：

为了照顾孩子，可以暂时停止工作吗？

如果没有同义词扩展或其他语言处理，传统关键词检索可能无法命中。

3. Sparse 不一定等于 BM25

实际讨论 Hybrid Search 时，“Sparse”可能指两类技术。

传统词法检索

BM25
TF-IDF
倒排索引

它依赖文档和查询中的实际词项，特点是高效、可解释、精确匹配能力强。

Neural Sparse Retrieval

例如 SPLADE 或搜索引擎提供的 Neural Sparse 模型。

模型会为词项生成稀疏权重，并可能扩展查询相关词，因此能够在保留倒排索引效率和一定可解释性的同时，加入部分语义能力。OpenSearch 将 Neural Sparse Search 定义为基于稀疏表示和倒排索引的检索方式，并支持将其与 Dense Search 组合。(OpenSearch Documentation)

对大多数第一版 RAG 系统而言，通常可以从以下方案开始：

Dense Embedding + BM25

只有当评估结果表明传统 BM25 无法满足召回要求时，再考虑引入 Neural Sparse 模型。

4. 为什么两者一起使用

Dense 和 Sparse 的优势与失败模式具有互补性：

Dense：
理解“用户想表达什么”

Sparse：
确认“用户说出的具体词是什么”

例如查询：

如何撤销刚才购买的商品？

Dense Search 可能找到标题为“退货和取消订单流程”的文档，即使原词不同。

而查询：

订单 A-20260715-009 当前状态

Sparse Search 更适合精确匹配订单编号。

因此 Hybrid Search 能同时覆盖：

  • 语义表达差异
  • 精确关键词
  • 专有术语
  • 编号和代码
  • 长尾自然语言问题

Elastic 将 Hybrid Search 描述为将关键词检索和语义检索合并为统一排名，从而同时利用词法精确性与语义理解能力。(Elastic)

但这不意味着 Hybrid Search 在所有数据集上必然优于单路检索。它增加了索引、查询、调参和评估复杂度，实际收益必须通过自己的检索评估集验证。

5. 两路结果如何融合

Dense 和 Sparse 的原始分数通常不能直接相加。

例如：

Dense cosine score：0.82
BM25 score：14.6

两者的数值尺度和含义不同，不能认为 14.6 比 0.82 更相关。

RRF：常见默认方案

RRF，全称 Reciprocal Rank Fusion，不直接比较原始分数，而是根据文档在不同结果列表中的排名进行融合。

简化公式是：

RRF(document) = Σ 1 / (k + rank)

其中：

  • rank 是文档在某一路检索中的名次；
  • k 是用于减弱头部排名差异的常数。

假设结果如下：

Dense 排名：
A 第 1
B 第 2
C 第 3

Sparse 排名：
C 第 1
A 第 2
D 第 3

A 和 C 在两路检索中都排名靠前，因此融合后通常会获得更高排名。

Azure AI Search 使用 RRF 合并并行运行的全文和向量查询；Elastic 也将 RRF 推荐为 Hybrid Search 的常见起点。(Microsoft Learn)

RRF 的优点是：

  • 不需要对齐两套评分尺度
  • 参数较少
  • 对不同检索器较稳健
  • 适合作为初始基线

它的不足是主要依赖排名，而不是利用原始分数中的细粒度差异；当业务需要明确控制 Dense 与 Sparse 权重时，可能需要加权融合、分数归一化或学习排序。

6. 典型生产检索链路

企业 RAG 中常见的处理过程是：

用户查询
   │
   ├── Dense Query Embedding
   │       ↓
   │   Dense Top K
   │
   └── BM25 / Sparse Encoding
           ↓
       Sparse Top K
           │
           ▼
        RRF 融合
           │
           ▼
       去重与过滤
           │
           ▼
       Cross-Encoder Rerank
           │
           ▼
       最终 Top N Chunks
           │
           ▼
          LLM

例如可以从以下配置开始实验：

Dense Top K：20～50
Sparse Top K：20～50
融合后候选：20～50
Rerank 后：5～10
最终送入 LLM：3～8

这些数值只是起始点，不是通用最佳参数。Qdrant 支持在同一集合中保存 Dense 和 Sparse 表示，并在服务端通过 RRF 或 DBSF 完成多路结果融合。(Qdrant)

7. Hybrid Search 和 Reranker 的关系

Hybrid Search 主要解决的是：

尽可能把相关文档召回到候选集合中。

Reranker 主要解决的是：

在候选集合中，更精确地判断哪些文档最相关。

两者角色不同：

Dense + Sparse Hybrid Search
→ 提高 Recall

Cross-Encoder / ColBERT / Rerank API
→ 提高最终排序精度

因此，常见的两阶段方案是：

第一阶段：
用 Dense + Sparse 快速召回几十个候选

第二阶段：
用更昂贵的模型对 Query–Document 对重新评分

如果数据量较小、查询简单，Hybrid Search 后直接返回结果可能已经足够；引入 Reranker 会增加延迟和成本，应由评估结果决定。

Hybrid Search 通常更适合：

  • 企业内部知识库
  • 技术文档和 API 文档
  • 客服知识库
  • 法律法规和合同
  • 产品手册
  • 代码搜索
  • 包含大量型号、编号、缩写和专有名词的语料
  • 多语言知识库

只使用 Dense Search 可能已经足够的情况包括：

  • 数据量较小
  • 内容主要是自然语言
  • 几乎没有精确编号和专有标识符
  • 处于快速原型阶段
  • 离线评估证明 Sparse 没有带来明显增益

合理的工程原则不是“所有 RAG 都必须 Hybrid”，而是：

先建立 Dense、Sparse 和 Hybrid 三套基线，再用真实数据决定是否承担额外复杂度。

9. 应该如何评估

不能只通过几个手工问题判断 Hybrid Search 是否有效。建议建立带有相关文档标注的检索数据集，并分别运行：

Dense-only
Sparse-only
Dense + Sparse Hybrid
Hybrid + Reranker

重点指标包括：

Recall@K
Precision@K
MRR
nDCG@K
Hit Rate
检索延迟
单次查询成本

还应按查询类型分组分析：

自然语言查询
精确关键词
错误码和编号
多语言查询
无答案查询
缩写和专有术语

可能出现的结果是：

  • Dense 在自然语言查询中最好；
  • Sparse 在编号和专有名词查询中最好；
  • Hybrid 的整体平均值最好；
  • Hybrid 增益有限，但延迟明显增加。

只有在这种评估基础上，才能判断混合检索是否适合具体系统。

结语

Dense + Sparse Hybrid Search 并不是一种全新的检索算法，而是一种组合策略：

Dense 提供语义召回
Sparse 提供词法精确性
RRF 负责融合排序
Reranker 进一步提高精度

它在企业 RAG 中广泛使用，是因为企业文档通常既包含自然语言，也包含编号、术语、产品名称和错误代码。

但 Hybrid Search 不是无条件的最佳答案。它会增加索引体积、查询延迟、系统复杂度和评估成本。更稳妥的做法是：

以 Dense-only 和 Sparse-only 为基线，通过检索评估验证 Hybrid Search 的真实增益，再决定是否进入生产。