向量检索、关键词检索和重排，分别解决什么问题

这是一篇检索技术学习导读，解决一个具体问题：向量检索、关键词检索和重排到底应该按什么顺序学，又分别在 RAG 链路里承担什么责任。

先说结论。向量检索擅长找“意思相近”，关键词检索擅长找“字面必须命中”，重排擅长对已经召回的候选做更细判断。三者不是互相替代的产品选项，而是可以组合的检索层次。

一句话解读：先把它们看成召回、补漏和精排三个动作，再去看具体框架，学习会清楚很多。

适合谁：已经理解 RAG 基本链路、准备亲手比较检索结果的后端或 AI 应用开发者。开始之前最好会使用 HTTP/JSON 和 Python，并理解索引、Top-K 与基本向量概念；只想快速调用现成问答 API 的读者不必一次学完三层。

来源边界与核验说明

本文讲的是相对稳定的概念边界，不给产品排名，也不引用易变的性能数字。学习入口以公开官方文档为主，已于 2026-07-15 核验：

• Elasticsearch 全文检索入门：<https://www.elastic.co/guide/en/elasticsearch/reference/current/full-text-filter-tutorial.html>
• Qdrant 混合与多阶段查询：<https://qdrant.tech/documentation/search/hybrid-queries/>
• Sentence Transformers Cross-Encoder：<https://www.sbert.net/examples/cross_encoder/applications/README.html>

具体 API、版本和部署方式可能变化，实践时应回到当前官方文档。本文不假设某个引擎一定优于另一个，而是给出可迁移的判断框架。

三份资料卡与使用边界

资料卡 1：Elasticsearch 全文检索入门

• 类型：官方教程。
• 适合：需要理解词项分析、全文查询和结构化过滤的后端开发者。
• 前置：会发送 HTTP/JSON 请求，理解索引和字段。
• 学习成本：先完成教程并用自己的小语料改写查询；官方未给统一学习时长。
• 最值得看：Query DSL 中全文查询与过滤怎样组合。
• 不适合：只想快速理解向量语义，不准备运行检索引擎的人。
• 维护与许可：Elastic 官方文档持续更新；默认发行版与源代码许可并不等同，当前发行版采用 ELv2，免费源代码部分另有 AGPLv3、SSPL 1.0 与 ELv2 选项，实际部署前应核对官方许可说明。

资料卡 2：Qdrant 混合与多阶段查询

• 类型：官方概念文档与可运行请求示例。
• 适合：已经会基础向量检索，想理解 dense、sparse、融合与多阶段查询的人。
• 前置：理解向量、集合、Top-K 和 payload。
• 学习成本：先复现一个 dense 与 sparse 融合请求，再更换自己的语料；官方未给统一学习时长。
• 最值得看：prefetch、RRF/DBSF 与多阶段查询的关系。
• 不适合：还没有真实问题集，却想直接调融合权重的人。
• 维护与许可：文档由 Qdrant 官方维护；Qdrant 主仓库采用 Apache-2.0，托管服务与具体部署责任需另看服务条款。

资料卡 3：Sentence Transformers Cross-Encoder

• 类型：官方库文档与示例。
• 适合：已有候选召回，希望学习 query-document 成对打分与重排的人。
• 前置：会用 Python，理解 Bi-Encoder 召回与候选集。
• 学习成本：先对一小批候选运行现成 Cross-Encoder，再记录排序和延迟；官方未给统一学习时长。
• 最值得看：为什么 Cross-Encoder 更适合小候选集，而不是扫描整个语料库。
• 不适合：召回阶段仍经常漏掉正确文档的人。
• 维护与许可：Sentence Transformers 仓库由 Hugging Face 维护，代码采用 Apache-2.0；具体模型还要分别核对模型卡许可。

一句话解读：三份资料分别提供词法召回、混合召回和候选精排入口，但许可与托管边界不能从“官方文档可阅读”直接推导。

三种技术先放回同一条链路

用户问题进入系统后，第一步通常是从大量文档里召回一个候选集合。向量和关键词都可以承担召回，也可以并行工作。重排通常不直接扫描全库，而是对较小候选集重新评分。

| 技术 | 一句话解读 | 典型优势 | 典型盲区 | | --- | --- | --- | --- | | 向量检索 | 用语义表示寻找表达不同但意思接近的内容。 | 同义改写、自然语言问题 | 编号、专有名词和精确条件可能不稳 | | 关键词检索 | 用词项、字段和匹配规则保留精确命中。 | 型号、错误码、条款名 | 问法变化大时容易漏召回 | | 重排 | 对候选和问题做更细粒度的相关性判断。 | 改善前排证据顺序 | 增加延迟，不能补回未召回内容 |

一句话解读：重排只能重新整理“已经找到的牌”，不能找回第一阶段根本没召回的证据。

向量检索要学的是语义边界

向量检索把问题和片段映射到表示空间，再按距离寻找候选。学习重点不是先背距离公式，而是观察哪些表达变化仍能匹配，哪些精确条件会被弱化。

可以用一组同义问题做实验，例如“怎么取消订单”和“订单不想要了如何处理”；再加入型号、日期和否定条件，观察结果变化。

判断向量检索是否适合，要看用户是否经常用自然语言改写同一意图，以及文档是否能形成清楚的语义片段。

关键词检索保住精确业务信号

关键词检索不只是简单字符串包含。它通常涉及分词、字段权重、短语匹配、过滤和相关性评分。

在错误码、产品编号、法规条款、姓名和固定术语场景里，精确词是不能丢的信号。用户输入“E1047”时，语义相近不是主要目标，正确命中编号才是。

一句话解读：关键词检索的价值不是“更传统”，而是让业务里不能被改写的词保持重量。

重排解决候选很多但前几名不准

初始召回为了避免漏掉证据，往往会取较宽候选。重排模型可以同时看问题与候选内容，对相关性做更细判断，把真正支持答案的片段推到前面。

难点是成本和延迟。候选越多，重排工作越重。因此要先评估召回是否覆盖，再决定重排数量，不能把它当成修复所有检索问题的按钮。

如果正确证据从未进入候选集，应修召回、切片或过滤；如果证据在候选中但位置靠后，重排才更对症。

学习曲线应分三个阶段

第一段是低门槛、高反馈。用一小批文档分别跑关键词和向量检索，输出每个问题的前几条结果。难点是建立直觉，产出是一张失败对比表。

一句话解读：第一阶段不做聊天页面，只看“问题进来后找回了什么”。

第二段是概念和变量增多。加入字段过滤、混合召回、分数融合和重排。必须带真实问题集学习，产出是可重复运行的检索评估脚本。

第三段进入生产约束。开始处理权限、索引更新、延迟、成本、版本和监控。目标不是再提高一个离线分数，而是保证用户只能检索可见且有效的内容。

最小学习路径

如果只想用 30 到 50 小时建立第一轮理解，可以这样做：

1. 准备三十到五十篇结构清楚的小文档和二十个真实问题。
2. 只做关键词检索，记录命中与漏召回。
3. 换成向量检索，用同一批问题对比。
4. 做混合召回，并给候选加入重排。
5. 按“未召回、顺序错误、版本错误、权限错误”归类失败。

每一步只改一类变量，保留结果。这样学习产出不是一张架构图，而是一套能解释取舍的实验记录。

常见误区与失败原因

最常见的误区是只看最终回答，不看检索结果。模型可能用常识补全，让错误召回暂时不明显。

第二个误区是看到向量检索后放弃关键词。精确编号和专名会立刻暴露这个问题。第三个误区是候选越多越安全，结果重排和生成上下文都变得更慢、更嘈杂。

还要避免用随手编的问题做评估。问题应来自实际搜索、客服记录或业务人员整理，并注明期望证据。

限制、反例与下一步

小型、字段高度结构化的数据，直接数据库查询可能比三种检索都合适。对极短的 FAQ 集，复杂重排也可能得不偿失。检索技术不能替代文档治理和权限设计。

下一步建议把实验整理成一张“问题类型—召回方式—失败原因”表。它还能继续拆成四个站内选题：混合分数怎样融合，重排候选数怎样影响延迟，权限过滤应放在哪一层，检索评估集怎样从真实问题建立。前两篇适合做实验复盘，后两篇适合进入 RAG 工程专题。

我的判断是：学习三种检索最有效的方式，不是比较谁更先进，而是让同一批真实问题依次经过它们，亲眼看到每一层补了什么、又留下什么。