检索质量优化

flowchart LR
  A["检索质量优化"]
  A --> B["分类：检索增强 (RAG)"]
  A --> C["关键词：RAG"]
  A --> D["关键词：检索"]
  A --> E["关键词：BM25"]
  A --> F["关键词：Embedding"]

RAG 的核心不是“让模型更会说”，而是先让系统找对资料。如果检索阶段把正确资料漏掉了，后面的 Prompt、Rerank、再强的 LLM 都只能在错误或不完整的上下文上继续发挥。

很多初学者会把检索想成“一次向量搜索”，但在生产系统里，检索通常已经不是一个单点动作，而是一套多阶段检索系统（multi-stage retrieval pipeline）：

Query
↓
Query Transformation
↓
Recall（Sparse / Dense / Hybrid）
↓
Rerank（精排）
↓
Top-K Context

👉 关键认知：

检索 ≠ 一次向量搜索检索 = Recall + Ranking

这意味着，第一阶段的目标通常是找全，第二阶段的目标是找准。很多现代 RAG 系统之所以效果比“直接向量检索”稳定，核心原因就在这里。LangChain 的 retrieval 文档也明确把 query enhancement、retrieval validation、post-generation checks 等放进更复杂的 Hybrid RAG 流程里，而不是把 retrieval 看成一步结束。(LangChain 文档)

延伸阅读

HyDE 原始论文

Elastic: Practical BM25 Part 2

一、为什么生产级 RAG 往往是多阶段检索

先明确一个事实：

在真实知识库里，“最相关文档”通常不是一步就能稳定找到的。

原因很简单。用户问题和文档内容之间，常常同时存在两类差异：

字面差异：用户说“改密码”，文档写“密码重置流程”
结构差异：用户只给一句问题，文档里相关信息散在标题、正文、脚注、表格里

如果你只靠一种检索信号，通常只能覆盖其中一部分：

只靠关键词：能抓精确术语，但不懂同义表达
只靠向量：懂语义，但可能漏掉精确实体、编号、错误码、函数名

所以生产系统里很常见的做法是：

召回阶段（Recall）：先尽量把可能相关的候选找回来
精排阶段（Rerank / Ranking）：再从候选里挑出最值得给模型看的前几条

这个思路和传统搜索系统非常一致。RAG 本质上并没有绕开搜索工程，而是把它重新带回了 LLM 系统里。

二、Sparse Retrieval（稀疏检索）

先看定义：Sparse Retrieval 更擅长抓“词面命中”，尤其适合实体、术语、编号、函数名、法条编号这类必须精确匹配的内容。

最典型的 sparse retrieval 方法就是 BM25。Elastic 官方文档明确说明，BM25 是 Elasticsearch 默认的相关性排序算法，并详细解释了它如何利用词频、逆文档频率和长度归一化来计算相关性。(Elastic)

Sparse Retrieval 为什么仍然重要

很多人进入 RAG 以后，会下意识觉得：

既然有 embedding，传统关键词检索应该过时了。

这在工程上并不成立。BM25 之类的稀疏检索今天仍然很重要，尤其在下面这些场景里：

法律条文
API / SDK 文档
日志与错误码
代码检索
产品型号、版本号、表名、字段名
医疗术语、药物名、标准编号

这些内容有一个共同点：

精确 token 命中，本身就携带了极强的相关性信号。

例如：

用户问 429 rate limit
文档里正好有 HTTP 429 Too Many Requests

这时 BM25 之类方法经常比纯 dense retrieval 更直接、更稳定。

Sparse Retrieval 的优缺点

维度	表现
优点	对关键词、实体、编号、代码 token 很敏感
缺点	缺少真正的语义理解，不擅长同义表达
适用	技术文档、法律文书、代码、精确搜索场景

👉 工程结论：

BM25 并没有过时，它仍然是很多生产 RAG 系统的重要组成部分。(Elastic)

三、Dense Retrieval（稠密检索）

先看定义：Dense Retrieval 的核心优势是语义匹配能力，它更擅长处理“用词不同但意思接近”的查询和文档。

Dense retrieval 的典型流程是：

用 embedding 模型把 query 编成向量
把文档 chunk 也编码成向量
在向量空间里做近邻搜索
返回最相似的 top-k chunk

这类方法的好处非常明显：

能处理同义改写
对口语化提问更友好
对“问题语言”和“文档语言”不完全一致的情况更稳
比纯关键词检索更接近“按意思找资料”

Dense Retrieval 的典型优势

比如用户问：

“怎么改密码？”

文档写：

“账户密码重置流程如下”

Sparse 检索未必稳定命中，但 dense retrieval 往往能把它们拉近。

Dense Retrieval 的典型局限

Dense retrieval 并不是“语义万能”。它最常见的问题包括：

对精确 token 不够敏感
对版本号、错误码、字段名这类内容可能不稳定
embedding 模型不匹配领域时，容易语义漂移
在语义上相似但业务上不相关的文档之间，可能混淆

所以 dense retrieval 通常不是生产系统的终点，而是非常强的基础召回层。

向量数据库选型要点

Dense retrieval 一旦进入生产，向量数据库的选型会直接影响系统体验。常见考量包括：

延迟（latency）
扩展性（sharding / clustering）
metadata filtering 能力
成本
写入更新能力
与现有数据栈的兼容性

这一层你在前面的“向量数据库”一章已经展开过，这里最重要的认知是：

Dense retrieval 的质量，不只由 embedding 模型决定，也受索引实现和过滤能力影响。

四、Hybrid Retrieval：为什么它越来越像生产默认选项

先看定义：Hybrid Retrieval 不是“两个方法都上一遍那么简单”，而是利用 sparse 和 dense 的互补性，让系统同时拥有关键词精度和语义召回能力。

在很多真实场景里，dense 和 sparse 各有盲点：

sparse 能命中精确实体，但不懂同义表达
dense 懂语义，但对精确 token、编号和代码词不够敏感

这就导致两类错误类型是互补的。于是最自然的工程结论就是：

把 sparse 和 dense 的候选结果融合起来。

这就是 Hybrid Retrieval。

LangChain 检索文档里虽然讲的是更广义的 Hybrid RAG，但其中非常明确的一点就是：系统会在 query enhancement、retrieval、validation 等多个阶段组合不同信号，而不是只依赖单一路径。(LangChain 文档)

常见融合方法

方法	特点
RRF（Reciprocal Rank Fusion）	不依赖分数尺度统一，稳定、常用
线性加权	可以调权重，但需要调参与分数归一化
后融合（先各取 top-k 再合并）	实现简单，但排序质量一般

为什么 RRF 常常是好起点

RRF 的优势在于：

不需要强行统一 BM25 和向量相似度的原始分数
对不同检索器的排序结果更稳
经常比手工线性加权更容易先跑出不错的 baseline

所以如果你第一次做 Hybrid Retrieval，一个非常实用的建议是：

先从 RRF 开始，而不是一上来就调复杂权重。

一个非常实用的工程判断

在很多企业文档、技术文档、FAQ、知识库问答场景中，Hybrid Retrieval 往往比纯 dense retrieval 更稳。原因不是 dense 不强，而是现实世界里的 query 往往同时含有：

语义表达
精确术语
领域 token
缩写、版本号、编号

这些信号只靠一种检索方式，很难全吃到。

👉 经验结论：

在大量真实业务场景中，Hybrid 常常比纯 Dense 更接近生产默认。

五、Query Transformation：别急着搜，先把问题变成更适合检索的形式

先看定义：用户写出来的问题，往往不是最适合检索的 query。Query Transformation 的作用，就是在真正检索前先做一次“检索友好化”。

这一步在很多系统里被严重低估。用户会这样提问：

口语化
含糊
省略上下文
带错别字
混用中英术语
只描述现象，不给关键词

如果你把这些 query 原样拿去搜，效果通常不会是最优。

1. HyDE

HyDE（Hypothetical Document Embeddings） 的核心思想是：

先让 LLM 根据 query 生成一篇“假设性的相关文档”
再把这篇假设文档做 embedding
用它去做 dense retrieval

HyDE 原始论文明确指出，这样做的目的是通过一个“假设文档”来桥接查询和相关文档之间的表示差异，从而提升零样本 dense retrieval 效果。(arXiv)

为什么 HyDE 有时有效

因为很多 query 太短、太口语、太抽象，直接 embedding 后表达力不够。 HyDE 等于先把问题“展开成一篇可能长什么样的答案文档”，再去检索更像这篇文档的真实内容。

代价

要多一次 LLM 调用
增加延迟和成本
有时会生成偏题假设，反而引入噪声

所以 HyDE 更像一种高阶 recall 增强手段，不是每个系统都必须上。

2. Query Expansion / Multi-query

这类方法的思路更直观：

生成多个同义改写 query
补全省略术语
生成中英文双语 query
用多个 query 分别检索，再合并结果

适合的场景包括：

文档用词很规范，但用户提问很口语
多语言混合知识库
用户问题有多种表达方式
query 本身太短

优点

提高召回覆盖率
对表达差异更鲁棒

缺点

检索次数增加
候选集变大
后续 rerank 成本上升

所以 multi-query 很强，但一定会带来成本和延迟的上升。

3. Query Routing（很容易被忽略，但非常关键）

并不是所有 query 都该走同一条检索路径。

例如：

Query 类型	更合适的策略
精确查询（错误码、表名、法条号）	BM25 / Sparse 优先
自然语言问答	Dense
混合查询（既有术语又有语义）	Hybrid
特殊领域问题	路由到专门知识库或专门 retriever

这就是 Query Routing 的价值。

它背后的工程认知是：

检索策略不该一刀切，而应该根据 query 类型动态选择。

这在生产系统里非常重要，因为你面对的 query 分布通常很杂，不可能每个问题都靠同一套默认配置解决。

六、Recall、Precision、Latency：检索优化的三个核心权衡

检索优化不是追求某个算法“理论最优”，而是在三个维度之间做权衡：

Recall：能不能把正确资料找回来
Precision / Ranking Quality：找回来的资料里，前几条是不是最值得给模型看
Latency / Cost：这套系统值不值得上线

1. Recall vs Latency

Top-k ↑ → recall 往往 ↑ → latency 和噪声也 ↑
multi-query ↑ → recall 往往 ↑ → 成本也 ↑
hybrid ↑ → recall 常常 ↑ → 系统复杂度也 ↑

2. Dense vs Hybrid

场景	推荐
语义理解为主	Dense
精确实体很多	Hybrid
法律 / 代码 / 日志 / 错误码	Sparse 或 Hybrid

3. 成本 vs 效果

方法	成本	效果
Dense baseline	中	通常不错
Hybrid	中偏高	往往更稳
HyDE / Multi-query	高	在复杂场景下可能显著提升 recall

👉 一个非常重要的工程顺序是：

先把 recall 做够，再优化 ranking；先把 baseline 做稳，再上昂贵增强。

七、评估指标：没有评估，就没有检索优化

先看定义：检索优化不能靠“感觉回答变好了”，而要靠检索指标和样例集来验证。

常见指标

指标	含义
Recall@k	正确文档是否出现在前 k 条里
Precision@k	前 k 条结果里有多少是真相关
MRR	正确答案排得有多靠前
NDCG	考虑排序位置和相关度等级的综合指标

一个很实用的优先级

对大多数 RAG 系统来说，建议先看：

Recall@10 / Recall@20
再看 MRR / NDCG
最后再看最终答案质量

因为如果正确文档根本没被召回，再好的 LLM 也无能为力。

为什么不能只看最终回答质量

因为最终回答质量是很多环节共同决定的：

检索
Rerank
Prompt
模型能力
输出约束

如果你不单独测 retrieval，很容易出现这种情况：

回答变差了，但你不知道是检索差了，还是 prompt 改坏了
回答变好了，但你不知道是模型更强了，还是检索真改进了

所以检索层必须有自己独立的评估。

八、调优实践：一条更稳的工程路线

1. Top-k 选择

k	适用场景
3–5	已有 rerank，且候选质量较高
10–20	常见 baseline
50+	多阶段召回、需要更高 recall 的场景

一个很常见的套路是：

第一阶段召回较大的 top-k
第二阶段 rerank 后只保留 top-n
最终给 LLM 的 context 再进一步裁剪

2. Filtering 策略

这一步经常被低估，但在生产里非常关键。

常见做法包括：

metadata filtering
时间过滤（freshness）
文档类型过滤
语言过滤
租户 / 权限过滤

Filtering 的意义在于：

先把明显不该出现的候选排除掉，再谈相关性。

这往往比单纯改相似度阈值更有效。

3. 相似度阈值

相似度阈值的作用通常不是“提高召回”，而是：

过滤明显低相关结果
减少噪声上下文
避免系统在“根本没找到答案”时还硬凑材料

但阈值不能拍脑袋设，最好结合验证集来调。否则你可能会：

设太高，漏掉边缘但真实相关的结果
设太低，引入大量噪声

九、失败模式分析：很多优化，其实是在修不同类型的错误

这是最贴近实战的一节。

1. 检索不到（Recall Failure）

表现

正确文档根本没进入候选集。

常见原因

query 表达方式和文档差异大
chunk 切分不合理
embedding 模型不适配领域
只用 sparse 或只用 dense，信号太单一

常见解决方向

query expansion
HyDE
Hybrid Retrieval
调整 chunking
换 embedding 模型

2. 检索错（Precision Failure）

表现

系统检索到“看起来很像，但其实不回答这个问题”的材料。

常见原因

dense retrieval 把语义相似但业务不相关的文档拉近
sparse retrieval 命中了关键词，但上下文不对
top-k 太大，噪声混进来

常见解决方向

rerank
metadata filtering
调低最终送入模型的 top-n
优化 prompt，要求模型只基于最相关证据回答

3. 排序问题（Ranking Failure）

表现

正确文档找到了，但排得太靠后，没进入最终 prompt。

常见原因

初检打分不够精细
sparse 和 dense 的融合策略不合理
缺少 rerank

常见解决方向

加 rerank
改融合策略
调整 top-k 与 top-n
用 query-aware reranker 对候选再排序

十、为什么 Hybrid 往往更强

可以把 Hybrid 的优势归结为三点：

BM25 抓实体和精确 token
Dense 抓语义和同义表达
两者错误类型互补

所以 Hybrid 更强，不是因为“融合听起来更高级”，而是因为：

现实世界里的 query 本来就同时包含关键词信号和语义信号。

这也是为什么在很多真实知识库、技术文档、FAQ、企业搜索场景中，Hybrid 经常比单纯 Dense 更稳。

十一、一个实用的检索优化迭代路径

不要一上来把所有高级技巧全开。更稳的顺序通常是：

先做 Dense baseline
加 Hybrid（优先 RRF）
再考虑 Query 变换
调 top-k / 阈值 / filtering
最后上 Rerank

这个顺序的好处是：

每一步都能单独评估
更容易知道是哪一步带来了增益
不容易把系统复杂度一次性堆爆

👉 关键原则：每一步都要做 A/B 或离线评测。

十二、常见反模式（Anti-pattern）

下面这些做法在真实系统里非常常见，而且经常导致“RAG 看起来接上了，但效果很不稳定”。

只用 Dense，不做任何对照
完全不做评估，只看主观回答
chunk 切分非常随意
没有 metadata filtering
top-k 一路拉大，靠“多塞点”解决问题
不做 rerank，却要求前几条极准
一上来就上 HyDE、多 query、多模型，结果系统过于复杂

先看定义：

检索优化不是不停加组件，而是先搞清楚错误类型，再加对应手段。

十三、小结

检索优化的核心，不是迷信某一个算法，而是构建一个多阶段检索系统：

Recall：尽量找全可能相关的候选
Ranking：把真正最相关的排到前面
Query Transformation：让系统朝着更容易检索成功的方向去搜

Sparse、Dense、Hybrid 不是谁取代谁的关系，而是不同信号源的组合方式。BM25 依然在生产系统里很重要；Dense retrieval 是现代语义检索的基础；Hybrid 则经常成为企业场景里更稳的默认路线。HyDE、multi-query、routing 这些方法，本质上都在做同一件事：提高召回成功率和候选质量。(arXiv)

核心概念速查

概念	一句话
Sparse Retrieval	基于词项匹配的检索，擅长实体、术语、编号命中
Dense Retrieval	基于 embedding 语义相似度的检索，擅长自然语言匹配
Hybrid Search	融合 sparse 和 dense，兼顾关键词精度与语义召回
Query Transformation	在检索前改写、扩展或路由 query，以提高召回质量
Multi-stage Retrieval	把检索拆成 Recall + Ranking 两个阶段的系统设计
RRF	一种常见的混合排序融合方法，不依赖原始分数尺度统一
HyDE	先生成假设文档再做 dense retrieval 的 query 增强方法
Recall@k	正确文档是否在前 k 条里被找回来
MRR / NDCG	衡量排序质量的常见指标