你的检索管道从未衡量的中间上下文盲区

检索日志很干净。针对你手动标注的查询集，Recall@10 在几个月内都没有出现退化。答案质量仪表盘显示忠实度（faithfulness）保持在 90% 以上。然后，一位客户向你的支持代理粘贴了一个问题，金标准文本（gold passage）就在组合提示词的 12 个位置中的第 7 位，而模型的回答却好像从未检索到它一样。

检索团队会告诉你该分块（chunk）确实在那里。提示词团队会告诉你提示词是正确的。两者在技术上都是对的。模型关注了前一千个标记（tokens），关注了最后一千个标记，却略过了答案所在的中间地带。你的流水线正面临着一种位置注意力偏置（positional attention bias），没有哪个团队对此负责，没有哪个仪表盘在追踪它，也没有哪个基准测试能捕捉到它。

没人画在你的仪表盘上的 U 形曲线

“迷失在中间”（lost in the middle）效应由 Liu 等人在 2023 年命名。实验设置很简单：将单个包含答案的文档放在 10、20 或 30 个文档的列表中，并要求前沿模型根据其进行回答。准确率随金标准文档位置的变化曲线呈 U 形——在第 1 位时很强，在最后一位时也很强，但中间部分会出现塌陷。名义上具有 16K 窗口的模型在回答时的表现，就好像它只有一个 4K 窗口且中间存在一个盲区一样。

三年过去了，这条曲线依然存在。最近针对 128K+ 上下文模型的基准测试显示了同样的模式，有时虽然有所缓解，但从未消失。其原因是结构性的：因果掩码（causal masking）将注意力质量集中在序列的开头，而针对短序列的模型训练方式又将注意力推回了尾部。中间频带是一个数学计算变弱的槽位（slot），而不是模型选择忽略的槽位。

你的 RAG 流水线是建立在相反的假设之上的。检索评分将组合提示词中的所有槽位视为等效的。重排序器（reranker）最大化相关性，然后组装器按评分顺序或原始文档顺序追加段落。系统提示词位于顶部。用户问题位于底部。检索评分排名第一的段落经常落在中间地带的第二个或第三个槽位，而曲线显示模型的注意力在那里已经变薄了。

检索系统为该段落打分了，模型却根据另一个段落给出了回答。

为什么 retrieval@10 保持健康，而 answer@10 却在悄悄漂移

两阶段 RAG 流水线为你提供了两个天然的评估面。Retrieval@K 询问：金标准分块是否出现在前 K 个中？忠实度（faithfulness）询问：答案中的每一个主张是否都能追溯到检索到的分块？两者都可以显示为绿色，而用户体验却在下降。

Retrieval@10 是针对候选列表计算的，而不是针对模型实际使用的内容。只要分块在前 10 名中，检索就是“正确的”——即使模型因为从未阅读第 7 个分块而根据第 1 个分块进行了回答。忠实度评估响应中的主张是否符合检索到的集合。当模型根据高注意力段落即兴创作出一个听起来合理的答案时，忠实度仍然会将该响应评为“有据可依”（grounded），因为支持性文本确实在候选集中的某个地方。支持性文本是错误的那一个，这一事实是你的评估无法衡量的语义鸿沟。

这种情况首先出现在看起来很随机的用户投诉中。检索看起来是正确的，提示词看起来也是正确的，回答看起来很自信，但答案是错误的。事后分析将责任归咎于模型。实际原因则是提示词组装中一个确定性的属性，而目前无人衡量。

正确的指标长什么样

加载中…