RAG 检索中的两个误区：高相似度不等于正确，向量检索也不能替代关键词检索

摘要：在 RAG（Retrieval-Augmented Generation）系统中，"召回"是决定最终答案质量的第一道关口。本文从一个直观现象切入------Top1 相似度 0.94，但正确答案可能是 Top2------分析语义相似度与业务正确性之间的错位，并进一步讨论为何在企业级场景中，向量检索必须与传统关键词检索结合（Hybrid Search）。文中涉及 Metadata 过滤、两阶段检索（Bi-Encoder + Cross-Encoder Rerank）、结果融合策略等工程实践。

一、引子：那个 0.94 的相似度

先看一个直觉上"反常识"的案例：

用户的问题是某设备的故障处理。向量检索返回：

Top1 ：A 系列 1025 的故障手册，相似度 0.94

Top2 ：A 系列 1024 的故障手册，相似度 0.86

从模型角度看，Top1 的向量距离确实更近，检索本身没有"算错"。但业务上，用户查询的机型是 1024 ------Top1 型号错了，答案再通顺也是错的。

这正是 RAG 系统中最典型的一类误区：

最相似 ≠ 最正确（Most similar ≠ Most correct）

相似度衡量的是"语义距离"，而正确性还受实体精确性、业务约束、时效性等因素影响。向量模型对此是无感知的。

二、为什么高相似度会"骗人"

2.1 相似度度量的是什么

向量检索的本质是：把 query 和文档都映射到同一向量空间，用**余弦相似度（或内积、欧氏距离）**度量"语义接近程度"。

Embedding 模型（如 BERT 系列、bge、m3e、OpenAI text-embedding 等）训练目标是捕捉整体语义。
因此，"A 系列 1024 手册" 和 "A 系列 1025 手册" 由于 90% 文字重合，向量表示会非常接近。

问题在于：Embedding 是"读大意"的，它天然会对局部关键实体（型号、版本、编号）做平滑，而这些恰恰是业务上的"一票否决项"。

2.2 常见的"高相似却错误"场景

场景	Top1（高相似）	真实需要	失效原因
设备/产品手册	A1025 手册	A1024 手册	型号差异被语义平滑
制度/政策文档	旧版本制度	最新版本	新旧文字几乎一致，旧版甚至相似度更高
合同/订单	相似编号的其它合同	指定合同	编号差一个字符含义全变
时效性知识	过期的操作规范	当前有效规范	语义不变但已失效

可以看到，凡是涉及"精确实体 + 业务约束"的内容，单纯靠 similarity score 都无法判断"该不该采用"。

三、解法一：用 Metadata 前置过滤（Filter First）

既然向量模型分不清"1024"和"1025"，那就不要让它们进入同一次排序竞争 。正确做法是：先用结构化条件把明显不符的文档剔除，再做向量检索。

常见的 Metadata 过滤字段：

实体标识：设备型号、产品 SKU、合同/订单编号
版本与时序 ：文档版本号、生效/失效时间、updated_at
组织权限：部门、业务线、数据权限范围、保密等级
文档类型：手册 / 制度 / FAQ / 工单

典型流程（Metadata-Aware Retrieval）：

text 复制代码

Query
  │
  ├─ 1. 解析出过滤条件（型号=1024、部门=售后、version=latest）
  ├─ 2. 用 Metadata 条件做前置过滤（数据库 / 搜索引擎 filter）
  ├─ 3. 在过滤后的候选集上做向量 ANN 检索
  └─ 4. 返回 Top-K

经验法则：能结构化的约束，就不要交给 Embedding 去"理解"。过滤条件越精确，向量检索的"犯错空间"就越小。

四、解法二：两阶段检索与 Rerank（重排序）

即使做了过滤，候选集里仍可能有多个"语义都接近、但相关性有高低"的文档。这时需要第二阶段：Rerank（重排序）。

4.1 为什么需要 Rerank：召回 ≠ 排序

第一阶段（召回） ：目标是高召回率（Recall） ，宁可多召一些，不能漏。此时常用 Bi-Encoder（query 和 doc 分别编码，可离线建库、支持 ANN 加速），但它对 query-doc 交互建模较弱。
第二阶段（排序） ：目标是高精度（Precision@K） ，用 Cross-Encoder 把 query 和整篇文档拼接后打分，能精细捕捉细粒度相关性，但计算量大、无法用于全库检索。

这就是经典的 "召回 + 精排"两阶段架构：

text 复制代码

全量文档库
    │  ANN 向量检索（快、粗）
    ▼
   Top-N 候选 (N=50~200)
    │  Cross-Encoder Rerank（慢、精）
    ▼
  Top-K 证据 (K=5~10)  ──▶  送入 LLM 生成

4.2 常见 Rerank 模型与策略

Cross-Encoder ：如 bge-reranker、Cohere Rerank、Jina Reranker，直接输出相关性分数。
打分方式 ：对候选文档逐一计算 score(query, doc)，再重新排序。
输入粒度 ：建议使用文档全文或较大片段，而非检索时的小块（chunk），避免"小块高相似但整篇不相关"。

回到引子案例：经 Rerank 综合判断"能否真正回答该问题"，Top2（1024 手册）的相关性格会反超 Top1，从而被选中。

五、第二个误区：有了向量检索，为什么还要关键词检索

上面的讨论解决的是"同一检索通道内的精度 "问题。另一个更根本的问题是：向量检索本身的能力边界。

5.1 向量检索的短板：精确匹配

Embedding 的优势是语义泛化------"苹果手机"和 "iPhone" 文字完全不同，但语义接近，向量能召回。这非常适合自然语言问题。

但反过来，泛化恰恰是企业场景中的风险：

用户输入 设备 A1024 的维修记录
系统必须精确匹配 A1024，差一个字符就是另一条完全不同的数据

企业中大量信息是靠"字面"而不是"意思"判断的：

设备编号、订单号、合同号、产品型号
错误码、API 名称、配置项 key、代码片段
专有缩写、内部代号

对这些内容，关键词检索（BM25 / 倒排索引）反而是更强的工具------它不做任何"猜测"，就是字符级精确匹配。

5.2 关键词 vs 向量：能力对比

维度	向量检索（Dense）	关键词检索（Sparse / BM25）
匹配方式	语义相似	词项精确匹配
泛化能力	强（同义词、 paraphrases）	弱
精确匹配	弱（实体易被平滑）	强
未登录词/编号	易失效	不受影响
可解释性	低	高（命中词明确）
检索速度	ANN 较快	倒排索引极快
典型场景	自然语言问答、FAQ	编号、术语、代码片段

可以看到，两者是互补关系，而非替代关系。

六、Hybrid Search：把两条路合并

企业级 RAG 的实践共识是：向量检索 + 关键词检索并行，再融合排序 。这就是 Hybrid Search（混合检索）。

6.1 标准架构

text 复制代码

                ┌──▶ 向量召回 (Dense)  ──┐
                │                         │
   Query ───────┤                         ├──▶ 结果融合 (Fusion) ──▶ Rerank ──▶ LLM
                │                         │
                └──▶ 关键词召回 (BM25) ───┘

完整流程通常包含四个环节：

向量召回：语义理解，覆盖同义、描述性问题
关键词召回：精确匹配，覆盖编号、术语、专有名词
结果融合：把两路候选合并成统一的候选集
Rerank：对融合后的候选做精细重排，形成最终证据

6.2 常见的融合策略

RRF（Reciprocal Rank Fusion） ：基于排名的倒数加权，不依赖原始分数，鲁棒性好，工程中最常用：
score(d)=∑i∈{dense,bm25}1k+ranki(d)score(d) = \sum_{i \in \{dense, bm25\}} \frac{1}{k + rank_i(d)}score(d)=i∈{dense,bm25}∑k+ranki(d)1
其中 k 通常取 60。
归一化加权 ：将两路分数各自归一化（min-max / softmax）后加权：α·s_dense + (1-α)·s_bm25，α 可调。
加权经验：实体/编号密集的场景调高 BM25 权重；开放式问答调高向量权重。

实践中往往还会在融合之前先做 Metadata 过滤（见第三节），即 Filter → Hybrid Recall → Rerank 的完整链路。

七、延伸讨论：Top-K 是不是越大越好？

（这也是原视频系列留下的一个自然问题，简述于此，供进一步展开。）

直觉上"多召回一些再精排"似乎更安全，但 Top-K 并非越大越好：

噪声放大：K 过大，相关性低的文档混入，干扰 LLM 判断（Lost in the Middle 问题）。
Rerank 成本：精排阶段是 O(N)，候选过多直接推高延迟与费用。
上下文窗口：即使塞得下，冗余信息也会稀释关键证据。

一般经验：召回阶段 N 取 50~200，精排后 K 取 5~10，并结合业务做相关性阈值截断（低于阈值直接丢弃，宁缺毋滥）。

八、工程实践小结

把全文串起来，一个相对完整的企业级 RAG 检索链路应做到：

认清边界：向量相似度 ≠ 业务正确性，关键实体不能只靠语义判断。
前置过滤：用 Metadata（型号、版本、时间、权限）先把"明显不对"的过滤掉。
混合召回：向量检索管"语义理解"，关键词检索管"精确匹配"，两条腿走路。
两阶段排序：Bi-Encoder 召回 + Cross-Encoder Rerank，兼顾召回率与精度。
合理设 K：Top-K 宁精勿滥，配合阈值截断。

一句话总结：

向量检索不是传统检索的替代品，而是它的补充。 企业 RAG 真正需要的，是既"理解用户的意思"，又"尊重精确的数据"。

参考资料

Dense Retrieval / Bi-Encoder 与 Cross-Encoder 的经典范式（DPR、ColBERT、Cross-Encoders）
RRF（Reciprocal Rank Fusion）：Cormack et al., SIGIR 2009
Rerank 模型：bge-reranker-v2、Cohere Rerank、Jina Reranker
Hybrid Search 在 Elasticsearch、Milvus、Weaviate、pgvector 等引擎中的实现文档
Lost in the Middle: How Language Models Use Long Contexts（长上下文中的证据位置偏差）