悄然渗入你提示词中的评估集

基准测试指标连续四个季度上升。用户满意度却没有。团队中没有人能解释这种差距，直到有人对提示词模板进行了 diff，并注意到 Few-shot 示例正从评估器读取的同一个 CSV 文件中获取。评估集已悄然变成了上下文示例。这个指标不再衡量泛化能力。它衡量的是模型在刚被告知答案的情况下，复制与之最接近问题的能力。

这就是我想命名的失效模式：评估集到提示词的泄露 (eval-to-prompt leakage)。它在结构上与传统机器学习中的测试集污染 (test-set contamination) 完全一致，但它是通过团队刻意构建的后端通道发生的。Few-shot 检索是一个合理的工程举措。评估库是一个合理的工程产物。当两者在没有人划定界限的情况下汇集到同一个存储层时，污染就产生了。

两个语料库是如何合二为一的

大多数团队并不是故意泄露评估集的。合并是循序渐进发生的，且每一步在局部看来都是合理的。

第一季度，一个小团队精选了 200 个涵盖请求分布的示例。CSV 文件存放在与提示词模板相同的代码库中，因为当时还没有独立的评估基础设施。核心准确率指标是通过将每个示例输入当前提示词，并将输出与标注的答案进行对比来计算的。

第二季度，有人在推理提示词中添加了动态 Few-shot 检索。检索索引需要一个标注示例的来源。评估 CSV 是团队拥有的唯一标注语料库，因此检索索引指向了它。推理提示词现在会在运行时从评估 CSV 中选择三个示例并包含在上下文中。评估流水线没有变化；它仍然迭代同一个 CSV，调用同一个提示词模板，而该模板现在从它正在迭代的 CSV 中检索内容。

第三季度，团队添加了更多示例以扩大 Few-shot 覆盖范围。示例进入了同一个 CSV，因为那是存放示例的地方。评估集与 Few-shot 池同步增长，因为它们是同一个文件。

到了第四季度，评估指标已经与用户能感知到的任何东西脱节了。核心准确率是对包含答案的索引进行最近邻查找的衡量。每一个提高检索相关性的提示词更改都会拉升基准测试。但没有一个能提高泛化能力。

根本原因不是 Few-shot 检索这一举措。根本原因在于示例库和评估库是同一个物理产物，同时被服务路径和评估路径查询，且没有强制隔离。这两个语料库从未被赋予不同的名称，因此它们合并了。

为什么仪表盘上很难发现这种污染

这种泄露看起来不像是 bug。它看起来像是基准测试在按设计运行。

最近的污染研究表明，即便只是部分暴露在基准测试内容中，也能给模型提供足够的信号，使其在不学习任务的情况下获得高分。大模型会利用提示词中的微小模式，而一个能选出词法相似的评估示例的 Few-shot 检索路径，正在完美执行它的预定任务。模型并没有作弊；它只是按照工程团队的指示使用上下文窗口。基准测试输出和服务输出一起偏离了用户体验，而从仪表盘内部看，并没有任何异常需要标记。

团队的本能是信任趋势线。趋势线是真实的 —— 模型在“针对与刚在上下文中展示的标注示例非常相似的输入，产生一个与标注答案相匹配的输出”这一任务上确实变得更强了。这与用户执行的任务不同，但仪表盘没有字段来体现这种区别。

这种差距首先出现在定性审查中。产品经理打开一个采样会话，看到一个措辞稍偏离分布的问题得到了一个自信的错误答案，并询问为什么基准测试没有捕捉到它。答案是基准测试无法捕捉到它，因为基准测试只衡量模型在与其正在检索的 Few-shot 池相似的输入上的表现。分布外的案例是用户可见的全部失效模式，而这正是评估流水线在结构上无法看到的唯一情况。

这是学术基准测试团队在过去两年中一直记录的污染问题的后端通道版本。导致排行榜分数虚高的相同机制 —— 训练语料库与测试语料库之间的隐性重叠 —— 现在正在单个生产流水线内部运行，且反馈循环更短，可见度更低。

在被正式定性前的征兆

加载中…