跳转到主要内容

检索空洞问题:为什么你的 RAG 拒绝说“我不知道”

阅读需 1 分钟Tian PanTian Pan

向生产环境中的 RAG 系统提一个你的语料库无法回答的问题,看看会发生什么。它很少会说“我没有那方面的信息”。相反,它会检索出五个排名最高的片段——由于没有更好的匹配项,这五个片段其实是五个最不糟糕的无关内容——然后将它们交给模型,并配上类似“请使用以下上下文回答用户的问题”的提示词。模型在被训练为要乐于助人的同时,手中握着与主题有几分相似的文本,于是产生了一个自信的回答。这个答案的错误在架构上是不可见的:检索成功了,生成也成功了,每个片段都在检索到的文档中有据可查,但用户却被误导了。

这就是检索空洞问题。它不是任何单一层级的 bug。它是一个流水线的涌现行为,该流水线将 “top-k” 视为一种契约,却从不询问 top-k 的质量如何。ICLR 2025 上发表的一项关于“充分上下文”(sufficient context)的研究量化了这一影响:当 Gemma 获得充分的上下文时,其在事实性问答上的幻觉率约为 10%。当它收到的上下文不足时——即检索到的文档实际上并不包含答案——该比率会飙升至 66%。向描述不足的查询中添加检索到的文档会让模型错得更自信,而不是更少。

大多数团队采取的补救措施是“提高相似度阈值”。这起初有一点帮助,但很快就会失效。真正的解决方案需要将检索重新构想为一个分类问题,其输出空间包含“空答案”,而不是一个输出始终为列表的排序问题。

为什么 top-k 是错误的抽象

向量搜索是一个排序原语。你给它一个查询嵌入(embedding),它会返回余弦空间中排序后的 k 个最近邻。这个原语对于这些邻居是否“相关”是持中立态度的。在一个烹饪食谱语料库中查询“德国股票期权的税务处理”,仍然会返回五个食谱,排序依据是哪些食谱恰好与查询向量共享了最多的偶然词汇。嵌入空间中的距离并不等于语义相关性;它仅代表“这是我们能找到的最接近的东西”。

问题在提示词组装阶段进一步加剧。标准的 RAG 提示词通常以祈使句形式编写:“请使用以下上下文来回答问题。”模板中没有预留位置来说“这些上下文都不相关,所以请承认你不知道”。LLM 收到五个无关的段落以及使用它们的指令,它照做了。研究人员称之为弃权悖论(abstention paradox):检索本应通过将输出建立在真实文档之上来减少幻觉,但当文档偏离主题时,检索反而会 增加 幻觉,因为添加任何上下文都会提高模型不合理的自信。

2025 年一项关于 LLM 弃权行为的调查将其归结为校准失败。模型不知道检索到的上下文意味着什么——它们只是将其视为真理。上游流水线从未发出过“此次检索置信度低”的信号。因此,“低置信度检索”和“高置信度检索”在到达模型时是无法区分的。模型对它们一视同仁。生成的答案建立在排名最高(但并非真正响应)的文本之上。

相似度阈值是必要的,但并不充分

大多数团队的第一反应是增加余弦相似度截断:如果最高分低于 0.7,则返回“无答案”。这是一个正确的方向,但实施方式不对。几乎立即就会出现三个问题。

首先,0.7 这个数字只是一个民间默认值,而非经过校准的值。常见的阈值区间通常如下:0.9+ 表示近乎精确匹配,0.7–0.8 表示相关但非完美,0.5–0.6 表示松散相关,0.3–0.4 表示弱连接。但这些区间是特定于模型和特定于语料库的。从 text-embedding-3-small 切换到多语言模型,整个分布都会发生偏移。索引一个高度相似的技术文档库,每个分数都会向 0.9 压缩,使得 0.7 变得毫无意义。系统的正确阈值只能通过保留部分查询、打标签并观察信噪比拐点来凭经验发现。

其次,即使在单一系统中,全局阈值也是错误的,因为不同的查询类型具有不同的分数分布。一个具体的事实性查询(“Jane 的邮箱是什么?”)应该达到 0.75+ 的精准层级匹配,而一个探索性查询(“关于定价策略我们知道些什么?”)合理地检索到 0.5–0.6 的文档时,这些文档实际上也是非常有用的。对两者都坚持 0.7 的阈值,要么会丢失有用的探索性结果,要么会通过糟糕的具体查询结果。按查询类别进行校准——将阈值视为查询意图的函数——通常比全局截断能带来 2-3 倍的精确度提升。

第三,相似度是相关性的代理指标,而非衡量标准。两个句子可能因为共享词汇和句法结构而具有很高的余弦相似度,即使它们讨论的是不同的事情。一个关于股票期权的税务问题会在余弦上匹配一份关于公司薪酬的文档,即使该文档从未涉及税务。双编码器(bi-encoder)嵌入针对检索速度进行了优化,而非针对相关性判断。将阈值提高到一定程度后,它在过滤掉那些“自信的无关项”之前,就会开始丢弃真正有用的匹配项。

两阶段模式:宽检索,窄分类

真正有效的生产模式将检索和相关性视为两个独立的问题。第一阶段撒大网 —— 从向量搜索中检索 50 或 100 个候选结果,不设置严格的阈值。第二阶段在这些候选结果上运行 交叉编码重排序器 (cross-encoder reranker),使用专门为判断相关性(而非快速生成相似度)而训练的模型,为每个 (query, document) 对评分。

会员专享

余下内容仅对会员开放。

会员可读完整内容 —— 每一个公开发布的观点背后,那些框架、决策与推理的全貌。

  • 完整文章,包含未公开存档的部分
  • 可落地的工作框架,附带权衡与决策依据
  • 新文章抢先看,先于公开发布

随时取消 · 一次订阅,畅读全部

参考资料

保持联系,关注我获取更多内容

阅读需 10 分钟

RAG 数据契约问题:摄取管道如何悄然破坏检索质量

Schema 漂移、嵌入模型更新和过时文档可能在数周内悄然降低 RAG 检索质量,而不产生任何错误日志。数据契约和摄取层监控能在用户察觉之前阻止质量腐化。

insider
rag
阅读需 8 分钟

知识图谱回归:为什么 RAG 团队正在为检索添加结构化数据

基线 RAG 在多跳问题上仅能覆盖 22-32% 的答案,而 GraphRAG 可达到 72-83%。本文提供了一份实用指南,介绍如何在检索管道中添加知识图谱结构——包括构建模式、路由策略,以及何时不值得引入 schema 开销。

insider
knowledge-graphs
阅读需 9 分钟

评估了错误的 RAG 管道环节

一个 RAG 系统本质上是由两台机器组成的,但大多数评估框架只给生成器评分。本文将解释为什么检索环节需要独立的评分体系,以及如何构建它。

insider
rag
阅读需 10 分钟

RAG 流水线中被你忽略的查询重写层

大多数检索失败源于查询形态的问题,而非嵌入模型本身。本文将深入探讨 HyDE、查询分解、多查询并行分发以及排名融合等技术,并教你如何在盲目更换编码器之前,诊断出你的 RAG 流水线真正需要的优化方案。

insider
rag
阅读需 8 分钟

RAG 位置偏差:为什么分块顺序会影响你的答案

检索正确性还不够——你的分块出现在提示词中的位置决定了模型实际使用哪些内容。本文探讨生产环境 RAG 系统中位置偏差的工作原理及应对方法。

insider
rag