RAG 检索质量怎么提升？从关键词到 Hybrid Search

前面几篇文章里，我们已经讨论了 RAG 的基础链路、文档切分、Embedding 模型和向量数据库。

到这里，一个最小 RAG 系统已经可以跑起来了：

文档切分
  ↓
Embedding 向量化
  ↓
写入向量数据库
  ↓
用户提问
  ↓
向量检索
  ↓
大模型生成答案

这个流程看起来很完整。

但很多系统真正进入使用后，会遇到一个非常典型的问题：

文档明明在知识库里，系统就是检索不到，或者检索到的内容看起来相关，但不能回答问题。

这时候很多人第一反应是换 Embedding 模型、换向量数据库、调大 TopK。

这些方法可能有帮助，但不一定能解决根因。

因为真实 RAG 检索质量的问题，往往不是单一向量检索能完全覆盖的。

尤其在企业文档、技术文档、产品文档、接口文档里，很多问题并不是纯语义相似问题，而是精确匹配、关键词命中、术语对齐、编号定位和业务过滤共同作用的问题。

这篇文章就讨论一个核心问题：

RAG 检索质量应该怎么提升，为什么很多系统需要从单一向量检索走向关键词检索和 Hybrid Search。

为什么只靠向量检索不够？

向量检索很适合处理语义相似。

比如：

用户问题：还没转正能不能休年假？
文档片段：试用期员工年休假按入职时间折算。

这里“还没转正”和“试用期”并不是完全一样的词，但语义上接近。Embedding 模型如果效果不错，就有机会把它们匹配到一起。

再比如：

用户问题：线上数据库多久备份一次？
文档片段：生产环境数据库每日凌晨执行全量备份。

“线上数据库”和“生产环境数据库”也是近义表达。

这类问题是向量检索擅长的。

但真实知识库里还有很多问题并不适合只靠向量检索。

比如：

ERR_1024 表示什么？
POST /orders 的 quantity 参数怎么填？
v2.3.1 是否支持批量导入？
P-7003 这个产品型号的功耗是多少？

这些问题里，错误码、接口路径、参数名、版本号、产品型号是关键。

它们不是普通语义表达，而是精确符号。

如果只靠向量检索，系统可能召回语义相似但编号错误的内容。

比如用户问 ERR_1024，系统召回 ERR_1025。

从文本相似度上看，它们很接近；从业务上看，它们完全不同。

这就是单一向量检索的局限。

向量检索擅长“相似”，但很多业务问题需要“准确”。

向量检索容易漏掉什么？

在实际项目里，只靠向量检索容易漏掉几类内容。

第一类是编号和代码。

比如错误码、订单号、工单号、版本号、产品型号、接口路径。

这些内容通常需要精确命中。

第二类是短关键词。

比如某个字段名、配置项、模块名、表名、函数名。

短词在向量空间里信息量有限，很容易被更长、更语义化的内容淹没。

第三类是专有名词。

比如内部系统名、项目代号、部门简称、产品缩写。

通用 Embedding 模型不一定理解这些词。

第四类是表格字段。

比如用户问“最大并发数是多少”，答案可能藏在参数表里。表格被切分和转换后，如果字段名没有很好保留，向量检索可能不稳定。

第五类是相似业务流程。

合同审批、采购审批、报销审批、立项审批都很像。向量检索可能把它们混在一起。

第六类是版本和时间敏感内容。

旧制度、新制度、旧接口、新接口在语义上可能很相似，但真实答案应该来自最新版本。

这些问题说明一个事实：

RAG 的检索不只是语义相似度问题。

它还包括关键词命中、结构化过滤、版本选择、权限控制和业务边界判断。

关键词检索解决什么问题？

关键词检索最典型的代表是 BM25。

它和向量检索的思路不同。

向量检索关注语义相似，关键词检索关注词项匹配。

比如用户问：

ERR_1024 是什么意思？

关键词检索会非常重视 ERR_1024 这个词是否出现在文档里。

而向量检索可能认为 ERR_1025、ERR_1042、错误码说明 都很相似。

在这种场景下，关键词检索往往更可靠。

关键词检索特别适合：

• 错误码。
• 接口路径。
• 参数名。
• 配置项。
• 产品型号。
• 版本号。
• 文件名。
• 表名。
• 精确术语。

比如：

POST /orders
tenant_id
max_connections
v2.3.1
P-7003

这些内容不一定需要语义理解，而是需要精确定位。

所以在 RAG 系统里，关键词检索不是过时技术。

它仍然非常重要。

尤其是技术文档和企业文档，很多问题如果没有关键词检索，召回质量会很不稳定。

向量检索和关键词检索各自擅长什么？

可以简单对比一下。

向量检索擅长：

• 同义表达。
• 口语化问题。
• 概念相似。
• 长文本语义匹配。
• 用户不知道准确关键词时的模糊查询。

关键词检索擅长：

• 精确词命中。
• 编号、代码、参数名。
• 短文本查询。
• 专有名词。
• 字段、路径、版本号。

举个例子。

用户问：

还没转正能不能休年假？

文档里写：

试用期员工年休假按入职时间折算。

这时向量检索更有优势。

再看另一个问题：

ERR_1024 是什么意思？

文档里写：

ERR_1024：用户认证失败，请重新登录。

这时关键词检索更有优势。

所以不要把向量检索和关键词检索看成二选一。

它们解决的是不同问题。

真实系统里，很多时候需要两者配合。

Hybrid Search 是什么？

Hybrid Search 通常指混合检索。

最常见的形式是：

向量检索 + 关键词检索

也就是同一个用户问题，同时走两条召回链路：

用户问题
  ├─ 向量检索：召回语义相似内容
  └─ 关键词检索：召回关键词命中内容
        ↓
      合并结果
        ↓
      去重和排序
        ↓
      交给后续 Rerank 或生成模型

Hybrid Search 的目标不是炫技，而是把不同检索方式的优势组合起来。

向量检索负责找“意思接近”的内容。

关键词检索负责找“词命中准确”的内容。

两者结合后，系统对真实问题的覆盖面通常会更好。

比如用户问：

v2.3.1 版本支持批量导入吗？

关键词检索可以确保 v2.3.1 被命中。

向量检索可以找到“批量导入”“批量上传”“批处理导入”等语义相关内容。

如果只靠其中一种，都可能不够稳定。

这就是 Hybrid Search 的价值。

Hybrid Search 不是简单把结果拼起来

很多人理解 Hybrid Search 时，会以为它就是：

向量检索 TopK + 关键词检索 TopK

然后直接把结果全部塞给模型。

这样做很容易出问题。

因为多路召回之后，会出现几个新问题。

第一，结果重复。

同一个 Chunk 可能同时被向量检索和关键词检索召回。

第二，分数不可直接比较。

向量相似度和 BM25 分数不是一个尺度，不能简单放在一起排序。

第三，召回内容质量不一。

关键词命中的内容可能只是出现了某个词，但并不能回答问题。

向量召回的内容可能语义相关，但缺少精确条件。

第四，TopK 变多后，上下文容易超长。

如果两个检索器各召回 10 条，合并后可能有 20 条候选内容，不能全部无脑塞进 Prompt。

所以 Hybrid Search 的关键不只是“多路召回”，还包括：

• 合并。
• 去重。
• 分数归一化。
• 初步过滤。
• 重排序。
• 上下文压缩。

这些步骤决定了 Hybrid Search 是否真正有效。

多路召回结果怎么合并？

一个简单的合并策略是取并集。

比如：

向量检索返回 A、B、C、D、E
关键词检索返回 C、E、F、G、H
合并结果为 A、B、C、D、E、F、G、H

然后按某种规则重新排序。

这比只用一种检索方式覆盖更广。

但真实系统里，需要更细致地处理。

可以考虑几个因素：

第一，同一个 Chunk 被多路召回，说明它可能更重要。

如果一个片段同时被向量检索和关键词检索命中，可以提高它的优先级。

第二，关键词命中精确标识符时，应该提高权重。

比如命中 ERR_1024、POST /orders、tenant_id，比命中普通词更重要。

第三，向量检索分数高但关键词不命中，不一定要降权。

因为用户问题可能是口语化表达，关键词不一致很正常。

第四，重复内容要去掉。

同一文档、同一段落、相邻高度重叠 Chunk，都需要处理，否则会浪费上下文。

第五，要考虑 metadata。

版本、权限、租户、文档状态等过滤条件，最好在检索阶段就参与，而不是等生成阶段再处理。

合并策略不是越复杂越好。

早期可以先用简单规则，然后通过真实问题集逐步调整。

Rerank 在 Hybrid Search 后更重要

多路召回之后，候选内容会变多。

这时 Rerank 的作用会更明显。

Retriever 负责把可能相关的内容召回来。

Rerank 负责在候选内容中进一步判断哪些更值得交给模型。

比如 Hybrid Search 召回了 20 个 Chunk，最终可能只选 5 个进入 Prompt。

这时 Rerank 可以帮助过滤掉：

• 只命中关键词但不回答问题的片段。
• 语义相似但业务对象错误的片段。
• 旧版本文档。
• 重复内容。
• 只包含背景但没有答案依据的片段。

所以 Hybrid Search 和 Rerank 经常一起使用。

可以理解为：

Hybrid Search 提升召回覆盖面
Rerank 提升最终上下文精度

不过 Rerank 本身也有成本。

如果候选太多，Rerank 调用会变慢、变贵。

所以前面的召回数量、过滤策略、去重策略仍然很重要。

哪些场景必须重视精确匹配？

不是所有场景都必须上复杂 Hybrid Search。

但下面这些场景一定要重视精确匹配。

第一，接口文档。

接口路径、参数名、返回字段、错误码都需要准确命中。

第二，运维文档。

配置项、命令、服务名、端口号、版本号都很关键。

第三，产品文档。

产品型号、规格参数、功能版本、兼容性说明不能混淆。

第四，制度文档。

不同制度、不同流程、不同部门规则可能很相似，需要业务边界过滤。

第五，合同和合规文档。

条款编号、责任主体、时间范围、适用条件都需要准确。

第六，知识库里存在大量缩写和内部代号。

通用 Embedding 模型不一定知道这些词是什么意思。

这些场景如果只靠向量检索，很容易出现“看起来相似但实际错误”的召回结果。

检索质量不要只靠调 TopK

很多系统召回效果不好时，会直接调大 TopK。

比如从 Top5 改成 Top10，从 Top10 改成 Top20。

调大 TopK 有时有帮助。

因为正确片段可能原本排在第 8 位，Top5 看不到，Top10 就能看到。

但调大 TopK 不是根本方案。

它也会带来问题：

• 更多无关内容进入候选集。
• Prompt 变长，成本增加。
• 模型更容易被干扰。
• Rerank 成本增加。
• 引用来源更难判断。

如果正确内容经常排得很靠后，说明召回策略本身需要优化。

可能是：

• Query 没有改写。
• 文档切分不合理。
• Embedding 模型不适合。
• 关键词检索缺失。
• metadata filter 缺失。
• 相似内容太多，需要 Rerank。

所以 TopK 是一个参数，但不是万能开关。

真正要提升检索质量，需要回到召回链路设计。

Query 处理也会影响检索质量

检索质量不只取决于数据库和模型，也取决于用户问题怎么进入系统。

用户问题经常是口语化、模糊的。

比如：

这个接口怎么传数量？

如果没有上下文，系统不知道“这个接口”指哪个接口。

再比如：

线上库那个备份规则是什么？

这里“线上库”可能对应“生产环境数据库”，“备份规则”可能对应“备份策略”。

Query 处理可以做几件事：

• 识别关键词。
• 提取精确实体。
• 补充同义词。
• 结合上下文改写问题。
• 拆分复杂问题。
• 为不同检索器生成不同 Query。

比如同一个用户问题，可以生成两种检索输入：

向量检索 Query：生产环境数据库备份策略是什么？
关键词检索 Query：生产环境 数据库 备份 策略

对于错误码问题，可以保留精确编号：

ERR_1024 认证失败

这样 Hybrid Search 会更稳定。

所以检索质量提升不只是后端数据库的事，也包括 Query 层的处理。

检索质量应该怎么评估？

不要只凭感觉判断检索质量。

“看起来还行”很容易误导人。

应该用真实问题集评估。

可以准备一批问题，每个问题标注期望召回的文档或 Chunk。

比如：

问题：试用期员工能不能申请年假？
期望召回：员工手册 > 请假制度 > 年假规则

问题：ERR_1024 是什么意思？
期望召回：错误码说明 > ERR_1024

问题：v2.3.1 支持批量导入吗？
期望召回：版本发布说明 > v2.3.1

评估指标可以包括：

• Top1 是否命中。
• Top3 是否命中。
• Top5 是否命中。
• 是否召回了错误相似内容。
• 是否漏掉必要上下文。
• 最终答案是否准确。

还可以按问题类型拆分评估：

• 语义类问题。
• 编号类问题。
• 接口类问题。
• 表格类问题。
• 制度流程类问题。
• 版本类问题。

这样才能知道系统到底在哪类问题上弱。

如果语义类问题好，但编号类问题差，就应该补关键词检索。

如果关键词命中好，但答案仍然混乱，可能需要 Rerank 或 Prompt 约束。

如果同类流程混淆，可能需要 metadata filter。

评估要帮助你定位问题，而不是只给一个模糊分数。

一个实用的检索质量排查清单

当用户反馈“搜不到”或“答错了”时，可以按下面顺序排查。

第一，文档里是否真的有答案？

如果知识库本身没有内容，检索再强也没用。

第二，文档是否解析成功？

PDF、表格、代码块、标题层级是否丢失。

第三，Chunk 是否合理？

答案依据是否被切散，是否缺少标题和上下文。

第四，Embedding 是否能召回？

用用户原问题测试，看正确 Chunk 是否进入 TopK。

第五，关键词检索是否能命中？

编号、参数、路径、版本号是否可以精确查到。

第六，是否需要 Hybrid Search？

如果问题类型混合，单一路检索可能不够。

第七，metadata filter 是否正确？

权限、租户、版本、文档状态是否过滤正确。

第八，是否需要 Rerank？

候选内容太多或相似内容太多时，重排序很重要。

第九，最终 Prompt 是否合理？

检索正确不代表生成正确，模型仍然需要约束。

第十，是否记录了完整链路？

如果没有 query、召回结果、分数、过滤条件和最终上下文，就很难排查。

这份清单能帮助你把“答错了”拆成具体工程问题。

总结

RAG 检索质量提升，不是简单换一个向量数据库，也不是只把 TopK 调大。

向量检索擅长语义相似，但不擅长所有精确匹配问题。

关键词检索在错误码、接口路径、参数名、产品型号、版本号等场景里仍然非常重要。

Hybrid Search 的价值在于把向量检索和关键词检索结合起来，同时提升语义召回和精确命中能力。

但 Hybrid Search 不是简单拼接结果。

多路召回之后，还需要合并、去重、过滤、排序和 Rerank。

真正可用的检索链路，应该结合文档切分、Embedding、关键词检索、metadata filter、Rerank 和 Query 处理一起设计。

最终检索质量要靠真实问题集评估，而不是靠感觉判断。

如果能把召回链路设计清楚，RAG 系统会从“偶尔答对”逐渐变成“稳定找到依据”。

下一篇文章，可以继续讨论 Rerank。

因为当召回结果越来越多时，真正决定模型看到什么的，往往就是重排序这一步。