在 RAG(检索增强生成)系统中,大语言模型并不是每次都直接从整个知识库中寻找答案。通常,系统会先从大量文档中检索出一部分相关内容,再将这些内容交给大语言模型生成回答。
因此,RAG 的回答质量不仅取决于大语言模型本身,还取决于一个非常关键的环节:检索。
假设一份企业操作手册中明确写着:
“应用升级失败时,可以按照回滚流程恢复到之前验证通过的版本。”
用户却问:
“新版本出问题了,怎么切回之前能正常运行的版本?”
两句话的表达方式不同,但可能指向同一条操作规则。
如果系统只搜索完全匹配的词语,就可能找不到这段内容。
反过来,如果系统只根据语义相似度进行搜索,也可能找到一份措辞相近、但适用条件完全不同的文档。
那么,如何让 RAG 既能理解不同表达之间的语义关联,又能准确识别关键词、数字和关键条件?
这需要理解五个核心概念:
- 关键词检索
- 语义检索
- 混合检索
- Top-K 与重排序
- 检索质量评估
本文将逐步解释这些技术的工作原理,以及它们之间的关系。
一、关键词检索:为什么精确匹配依然重要?
关键词检索(Keyword Search)是一种根据用户输入的词语,在文档中查找匹配内容并进行相关性排序的检索方式。
例如,用户搜索:
ERROR-503
知识库中可能有以下文档:
- 文档 A:错误代码 ERROR-503 的处理方法。
- 文档 B:服务不可用的常见原因。
- 文档 C:应用性能优化指南。
如果用户正在排查一个明确的错误代码,文档 A 显然值得优先查看。
关键词检索特别适合处理专有名称、错误代码、产品型号、版本号和其他需要精确匹配的信息。
1. 关键词检索不只是简单地查找相同的文字
现代全文检索系统通常还会对匹配结果进行相关性排序。
一种经典的相关性算法叫 BM25。
BM25 会综合考虑查询词在文档中的出现情况、词语在整个文档集合中的普遍程度,以及文档长度等因素,计算文档与查询之间的相关性分数。
例如,当用户搜索“数据库连接失败”时,一份多次讨论数据库连接故障的技术文档,可能比只在某个段落偶然提及该词语的文档排名更靠前。
不过,BM25 并不是业务规则引擎,也不能保证所有精确查询都得到正确结果。
如果用户要求查找某个特定版本,最好将版本号作为结构化字段进行精确过滤,再使用全文检索寻找相关操作说明。
2. 关键词检索的优势
- 对明确的词语和标识符有较好的匹配能力。
- 适合错误代码、产品型号、专有名称等精确查询。
- 通常不需要 Embedding 模型。
- 可以与数据库的结构化字段和过滤条件配合使用。
3. 关键词检索的局限
假设文档中写的是:
“恢复到之前验证通过的版本。”
用户问的却是:
“怎么切回旧版?”
两者的含义接近,但用词不同。如果系统过度依赖词语匹配,就可能遗漏真正相关的文档。
这就是语义检索能够发挥作用的地方。
二、语义检索:找到措辞不同、含义相近的内容
语义检索(Semantic Search)主要利用文本的语义表示,寻找与用户问题含义相关的内容。
在基于向量的语义检索中,系统通常会使用 Embedding 模型,将文档片段和用户问题转换为向量,再通过相似度或距离计算寻找候选结果。
关于 Embedding 的原理,可以参考前一篇文章《Embedding、向量与向量数据库:彻底理解 AI 是如何进行语义检索的》。
1. 语义检索如何工作?
假设知识库中有这样一段文字:
“应用升级失败后,可以按照回滚流程恢复到之前验证通过的版本。”
用户输入:
“新版本出问题了,怎么切回之前能用的版本?”
两句话并不完全相同,但经过合适的 Embedding 模型处理后,系统可能识别到它们在语义上的关联。
典型流程包括:
- 将用户问题转换成查询向量。
- 计算查询向量与文档向量之间的相似度或距离。
- 按照检索结果进行排序。
- 返回排名靠前的候选内容。
语义检索可以帮助系统跨越部分表达差异,而不必要求用户和原文使用完全相同的词语。
2. 语义检索的优势
它适合处理自然语言中的同义表达、不同句式和相近意图。
例如:
- “怎样降低接口响应时间?”与“有哪些减少 API 延迟的方法?”
- “应用为什么无法启动?”与“服务启动失败的常见原因是什么?”
- “怎么切回之前的版本?”与“如何恢复旧版本?”
这些表达可能不同,但它们指向的知识主题可能高度相关。
3. 语义检索为什么仍然可能出错?
语义相似度并不等于事实正确。
假设知识库中有两条规则:
- 规则 A:测试通过后,可以发布新版本。
- 规则 B:测试失败后,不应直接发布新版本。
这两句话在词语和主题上高度相似,但关键条件完全不同。
如果系统只根据整体语义相似度排序,就可能将两条规则都作为候选结果返回。
因此,语义检索不能完全替代关键词检索、结构化字段过滤和业务规则判断。
关键词检索更关注词语匹配,语义检索更关注文本含义之间的关联。两者解决的是相关但不同的问题。
三、混合检索:为什么要同时使用关键词和语义检索?
既然两种检索各有优势,能否让系统同时执行它们,再将结果合并?
可以。这就是混合检索(Hybrid Search)。
混合检索通常会结合关键词检索和语义检索的结果,尝试提高相关资料的覆盖率,并改善最终候选列表的质量。
1. 用一个例子理解混合检索
假设用户询问:
“如何解决 ERROR-503 服务不可用的问题?”
知识库中有三份文档:
- 文档 A:ERROR-503 错误代码的处理指南。
- 文档 B:服务不可用的常见原因与排查方法。
- 文档 C:HTTP 服务异常的综合故障排查手册。
关键词检索可能优先找到文档 A,因为它包含精确的错误代码。
语义检索可能优先找到文档 B,因为它的内容与“服务不可用”这一问题的整体含义相关。
文档 C 则可能同时出现在两种检索结果中。
如果只采用关键词检索,系统可能忽略一些措辞不同、但确实有帮助的排查资料。
如果只采用语义检索,系统又可能没有优先处理精确错误代码。
混合检索可以综合两边的结果,为后续回答提供更全面的候选资料。
需要注意,以上是概念示例,不代表所有检索系统都一定会产生相同的排序。
2. 两种检索的结果如何合并?
一种常见方法叫 RRF(Reciprocal Rank Fusion,倒数排名融合)。
可以先将它理解为一种融合多个排序列表的方法。
例如:
- 关键词检索生成一份排序列表。
- 语义检索生成另一份排序列表。
- 系统根据每份列表中的排名,为文档计算融合分数。
- 最后重新排列文档,得到统一的候选列表。
RRF 主要利用文档在不同列表中的排名,而不是直接将关键词检索分数和向量相似度分数相加。
这样做的一个好处是,两种检索的原始分数可能处于完全不同的数值范围,直接相加不一定合理。
但 RRF 不是万能的。如果两种检索都没有找到正确资料,或者重要文档在初始列表中排名太靠后,融合之后仍然可能漏掉它们。
3. 混合检索什么时候值得使用?
以下场景通常值得评估混合检索:
- 用户既会提出自然语言问题,也会提供精确标识符。
- 知识库包含大量技术文档、错误代码和专有名称。
- 单一检索方式经常遗漏相关内容。
- 需要同时考虑语义关联和关键词匹配。
不过,混合检索也会增加系统复杂度,可能需要维护多套索引、调整融合参数并评估检索质量。
如果简单的关键词检索或语义检索已经足够满足需求,就没有必要为了架构复杂而强行增加混合检索。
四、Top-K:为什么检索结果的数量很重要?
无论采用哪一种检索方式,系统通常都不会将整个知识库交给大语言模型,而是先选择排名靠前的一部分候选内容。
这里涉及一个重要参数:Top-K。
Top-K 表示从排序结果中取前 K 个候选项。
例如:
- Top-3:取前三个结果。
- Top-5:取前五个结果。
- Top-20:取前二十个结果。
K 的设置会影响检索结果的覆盖范围,也会影响后续处理的成本。
1. K 太小会发生什么?
假设一个问题需要参考以下三类资料:
- 基本操作步骤。
- 操作前必须满足的条件。
- 操作失败后的处理方式。
如果系统只返回 Top-1,而排名第一的文档仅介绍基本操作步骤,后续回答就可能缺少重要条件和异常处理信息。
这意味着,K 太小可能导致系统在检索阶段就遗漏了必要证据。
2. K 太大会发生什么?
假设系统返回 100 个候选片段,但其中只有 5 个真正相关。
其余内容可能只是主题相近,却不能直接回答问题。
这些无关片段会增加后续排序、上下文组装和模型处理的负担。如果最终上下文容量有限,还可能导致一些重要资料无法进入模型输入。
不过,K 大并不必然让检索效果变差。扩大候选范围也可能找回更多相关内容。
真正需要注意的是:扩大候选范围与最终交给模型的内容数量,是两个不同的参数。
3. 初次检索的 K 与最终上下文的 K 可以不同
一些系统会采用多阶段检索:
- 初次检索返回一批候选内容。
- 对候选内容进行过滤或重排序。
- 选择少量高相关内容,交给大语言模型。
例如,系统可以先获取 Top-20,再经过重排序后选出 Top-5。
这里的数字仅用于说明流程,并不是所有 RAG 系统都应该采用相同的参数。
初次检索需要尽可能减少重要资料的遗漏;最终上下文则需要在信息完整性、相关性和模型输入成本之间取得平衡。
五、重排序:为什么找到候选资料后,还需要再次排序?
初次检索通常需要在速度与覆盖范围之间取得平衡。即使它找到了相关资料,排序也不一定完全符合当前问题的需要。
重排序(Reranking)就是进一步评估候选结果与查询之间的相关性,再重新排列候选文档的过程。
例如,初次检索获得 20 个候选片段,其中可能有:
- 直接回答问题的操作说明。
- 与主题有关、但不能直接回答问题的背景介绍。
- 只包含部分相关关键词的文档。
重排序模型可以对查询与每个候选片段进行更细致的相关性判断,尝试将更适合当前问题的内容排到前面。
一种常见方式是使用 Cross-Encoder 模型,将查询和候选文本共同输入模型,计算它们的相关性分数。
与通常分别编码查询和文档、再比较向量的双编码器检索方式相比,Cross-Encoder 可以对查询和候选文本进行联合建模,但通常需要对每个候选分别评分,计算成本也更高。
因此,常见的设计是先用关键词检索、向量检索或混合检索获取候选集,再使用重排序模型对候选集进行精细排序。
这里必须明确一个边界:
重排序只能重新排列已经进入候选集的内容,无法直接找回初次检索完全遗漏的文档。
如果初次检索的召回率太低,就应该先检查索引、查询方式、分块和候选数量,而不是只依赖重排序。
六、如何判断检索效果好不好?
如果我们调整了检索方式或 Top-K,怎么知道结果是否真的改善?
不能只凭感觉判断,需要建立一套可重复的评估方法。
1. 建立评估数据集
首先,为一组代表真实使用场景的问题,预先标记哪些文档或文本片段与每个问题相关。
例如:
| 测试问题 | 预期相关内容 |
|---|---|
| 如何解决错误代码 ERROR-503? | 对应错误代码的处理说明 |
| 怎样恢复之前的版本? | 版本恢复操作步骤 |
| 什么情况下不允许发布? | 发布条件与限制 |
| 如何处理服务启动失败? | 服务启动故障排查指南 |
这些标注构成了评估的参考标准。
同一问题可能对应多份相关文档,因此评估时需要先明确相关性的标注规则,确保不同检索方案是在相同标准下比较。
2. Recall@K:应该找到的内容,实际找回了多少?
Recall@K,也称 K 个结果内的召回率。
它衡量的是:针对当前问题,所有预先标记为相关的文档中,有多少比例出现在系统返回的前 K 个结果中。
计算公式:
Recall@K = 前 K 个结果中的相关文档数 ÷ 全部相关文档数
例如:
- 全部相关文档:4 份。
- 系统返回 Top-5,其中有 3 份相关文档。
那么:
Recall@5 = 3 ÷ 4 = 75%
这意味着,系统找回了全部相关文档中的 75%。
Recall@K 较低,说明系统可能遗漏了重要资料。
注意,分母不是整个知识库的文档总数,而是针对当前问题被标记为相关的文档总数。
3. Precision@K:找回来的内容,有多少是真正相关的?
Precision@K,也称 K 个结果内的精确率。
它衡量的是:系统返回的前 K 个结果中,有多少比例是真正相关的。
计算公式:
Precision@K = 前 K 个结果中的相关文档数 ÷ K
继续使用上面的例子:
- 系统返回 Top-5。
- 其中 3 份相关,2 份不相关。
那么:
Precision@5 = 3 ÷ 5 = 60%
这意味着,系统返回的 5 份文档中,有 60% 被标记为相关。
Recall 和 Precision 的区别可以这样理解:
- Recall 关注有没有遗漏应该找到的资料。
- Precision 关注返回的资料中有多少真正有用。
两者的分母不同,不能混为一谈。
4. 为什么不能只看一个指标?
假设两个检索方案的评估结果如下:
| 指标 | 方案 A | 方案 B |
|---|---|---|
| Recall@5 | 60% | 90% |
| Precision@5 | 80% | 50% |
方案 B 找回了更多相关资料,但同时返回了更多无关内容。
方案 A 的结果更精简,但可能漏掉部分重要证据。
哪个方案更好,需要根据实际任务判断。
如果任务要求尽可能完整地搜集证据,就需要关注召回率;如果上下文容量有限,希望交给模型的内容尽可能相关,就需要关注精确率。
在实际应用中,往往需要同时观察两项指标,并结合检索延迟、生成质量和成本进行评估。
5. 检索质量与答案质量是两回事
即使系统找到了正确文档,大语言模型仍然可能误读其中的条件,或生成资料不支持的结论。
反过来,如果系统没有找到正确文档,模型也可能凭借已有知识生成一个看似合理、但不符合当前资料的答案。
因此,RAG 评估至少需要区分两个层面:
检索评估:系统是否找到了正确、相关且足够的证据?
生成评估:模型是否正确使用这些证据,给出了有依据的回答?
只有把这两个环节分别检查,才能更准确地判断系统究竟出了什么问题。
七、不同问题应该选择什么检索方式?
理解了各种检索方法之后,可以根据查询特征建立一个初步的选择思路。
| 查询类型 | 优先考虑的方式 | 主要原因 |
|---|---|---|
| 精确错误代码、版本号和产品型号 | 关键词检索或结构化字段过滤 | 需要准确匹配标识符 |
| 措辞不同但含义接近的自然语言问题 | 语义检索 | 需要识别语义关联 |
| 同时包含自然语言和精确标识符 | 混合检索 | 结合语义与关键词匹配 |
| 候选结果较多,需要进一步提升排序质量 | 重排序 | 更精细地比较查询与候选文本 |
| 涉及文档版本、时间或访问权限 | 元数据过滤结合检索 | 需要严格遵守结构化条件 |
需要注意,这不是一张绝对规则表。
实际系统可以根据评估结果调整检索流程,也不一定要一次性引入所有技术。
例如,基础关键词检索已经能够满足精确查询需求,就不必为了复杂架构而增加语义检索;简单向量检索已经表现良好,也不必立即引入重排序模型。
真正重要的是:根据实际问题验证每一种技术是否带来明确收益。
八、总结:RAG 检索不是单纯地寻找相似文字
通过本文,我们建立了 RAG 检索的基本知识框架。
关键词检索能够利用词语匹配寻找候选内容,尤其适合精确标识符和专业术语。
语义检索利用 Embedding 和向量相似度寻找含义相关的资料,帮助系统跨越部分表达差异。
混合检索结合不同检索方式的优势,但仍然需要合理的候选数量、排序和评估。
Top-K 决定了检索结果的候选范围,而重排序可以进一步改善候选列表的排序质量。
Recall@K 和 Precision@K 则分别帮助我们衡量相关内容是否被找回,以及返回结果中有多少真正相关。
这些技术共同构成了 RAG 检索优化的重要基础。
一个可靠的 RAG 系统,不仅要找到看起来相关的文字,更要尽可能完整地找到能够支持答案的证据,并通过评估验证检索策略是否真正有效。
下一篇文章将继续深入研究重排序(Reranking),解释初次检索为什么可能不够精确,以及如何利用更精细的相关性判断改善最终提供给大语言模型的资料。
参考资料
- Qdrant,Hybrid and Multi-Stage Queries。介绍混合检索、RRF 和多阶段检索。
- Qdrant,Hybrid Search with Reranking。介绍候选检索、混合搜索和重排序。
- pgvector,官方 GitHub 仓库。介绍 PostgreSQL 向量检索及与全文检索结合的能力。
- Robertson, S. and Zaragoza, H. (2009), The Probabilistic Relevance Framework: BM25 and Beyond。介绍 BM25 等概率相关性检索方法。
- Lewis, P. et al. (2020), Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks。经典 RAG 研究论文,帮助理解检索与生成相结合的基本思想。