测试是如何设置的

作者围绕两份支付规则手册文档构建了一个微型的检索增强生成 (RAG) 系统，并进行了两项检查：

  • 召回率测试 (Recall test) – 正确的页面是否出现在前五个结果中？结果：60%。
  • 回答测试 (Answer test) – 生成器产生的最终答案是否正确？结果：90%。

40% 的差距看起来是不可能的。如果检索器在十次中有四次没能找到正确的页面，模型怎么可能在十次中有九次都能回答正确呢？

尝试“修复”检索器的初步尝试

开发人员尝试了两种常见的技巧：

  • 混合搜索 (Hybrid search) – 结合词法和向量信号。召回率保持不变。
  • 重排序器 (Reranker) – 对检索到的五个页面进行重新排序。召回率上升到了 70%，但仍远低于 90% 的回答准确率。

这两种工具都只是对已经检索到的内容进行重新排列；它们无法凭空变出一个从未进入候选集中的页面。问题出在别处。

出问题的是指标，而不是模型

作者没有通过页面标签来判断成功与否，而是检查了检索到的分块 (chunks) 中的实际事实。在四次“失败”中有三次，正确的事实其实是存在的，只是它所在的页面与测试脚本预期的不同。评估机制因为检索器在非预期页面上找到了正确答案而对其进行了惩罚。

当指标切换为“任何检索到的分块是否包含所需事实？”时，召回率跃升至 90%，与回答准确率相匹配。检索器工作正常，出问题的是评估框架。

为什么传统的召回率可能会产生误导

  • 页面级标注会产生虚假失败。 一个事实可能会出现在多个页面上。如果仅将一个页面标记为真值 (ground truth)，那么所有其他正确的命中都会被视为错误。
  • 小规模语料库会放大这种影响。 在文档较少的情况下，单个标注错误的页面可能会剧烈影响召回率，而回答准确率却保持稳定。
  • 嵌入噪声会掩盖事实。 向量会对整个页面进行评分；周围的法律或技术文本会稀释目标句子的相关性信号，即使事实存在，也会降低该页面的排名。

RAG 从业者的实践启示

  • 将排序问题与检索失败区分开来。 重排序器只能解决前者；如果正确的分块从未进入候选集，那么重新排序也无济于事。
  • 在事实层面标注测试数据。 将每个查询与它所需的特定信息关联起来，而不是关联到单个文档标识符。
  • 不要对微型数据集盲目信任大规模基准测试。 小型、特定领域的语料库表现不同，通用的召回率分数可能会具有误导性。
  • 注意嵌入粒度。 页面大小的分块包含大量词汇，周围的法律文本可能会降低你所关注的事实的排名。

核心结论： 当评估方式与任务不匹配时，高回答准确率得分可能与低传统召回率数值并存。修复指标而不是修复模型，可以节省时间、减少误报，并实现更可靠的 RAG 部署。