在此页面上
简短的回答
当有关测试用例的信息以破坏预期测量的方式影响系统时，就会发生基准污染。私有集减少了一些泄漏，但重复调整、共享示例和评估期间获取的信息仍然可能会影响结果。
拿走什么
- 将开发反馈与最终决策证据分开。
- 记录每次运行期间的工具访问和可用信息。
- 披露污染的不确定性，而不是在没有证据的情况下宣布清洁测试。
已检查来源 .研究综合和 Rubrex 建议。示例和本地实验均已标记；它们不是客户结果。
最近的分类法拓宽了这个问题
2026 年 8 月的预印本围绕其可以击败的缓解措施组织了污染，包括评估期间获得的暴露。它还报告了其披露工具部分可靠性的局限性。它的贡献是提出更尖锐问题的一种方式，而不是证明任何基准未被污染的检测器。
追踪评价信息如何到达系统
列出测试材料可以出现的位置：提示、检索到的文档、少量示例、开发人员注释、微调数据、共享对话和工具。案例可以保留在模型训练之外，但在反复调试后仍然可以合并到应用程序的提示中。这改变了案件成功的含义。
对于支持网络的系统，还要考虑测试问题是否直接导致其发布的答案。这对于检索任务来说可能是合法的，而对于闭卷能力声明来说可能是无效的。根据评估合同，相同的行为可能是可接受的，也可能是污染性的。
使用与预期声明相匹配的控件
Rubrex 建议维护单独的开发、回归和决策集。即使工程师已经看到已知的故障，也应该进行回归测试。保留集有不同的目的：测量超出这些修复的转移。不要仅仅因为案件不再是秘密就抹去回归价值。
限制对决策集的访问，记录其暴露时间，并在运行最终比较之前冻结评分规则。如果允许使用工具，记录其访问边界。应审查新问题是否与之前的示例相似，以及标识符或参考文档中的意外线索。
说明性示例：记忆的升级
团队在支持升级后修复了助手，并将确切的交互添加到其提示中作为示例。下一个评估将通过该交互。这是一个有用的回归结果，但不足以证明助理处理不熟悉的同类案件。
建立单独的案例，使用不同的证据、措辞和边界条件来执行相同的基本规则。保留原始升级，标记其暴露情况，并单独报告泛化案例。透明的区别比更大的成功率更有用。
在分数旁边包含曝光记录
紧凑的记录应描述数据集来源、谁看到了案例、如何调整应用程序、工具是否可以检索相关材料以及未知的内容。将其附加到运行中，因为执行之间的曝光可能会发生变化。基准标签本身并不能描述获得分数的条件。
- 命名测试旨在支持的功能或工作流程声明。
- 记录已知的训练或调整暴露（如果有）。
- 解释评估期间的检索和网络权限。
- 将最终决策集与常规调试反馈分开。
证据的局限性
污染通常只能部分观察到。新颖的措辞并不能证明独立性，私有存储也不能证明信息从未影响过系统。引用的分类法是预印本，具有报告的测量限制。
常见问题
曝光的案例是否应该删除？
不会自动。如果他们的暴露被记录下来并且他们的分数不作为独立的概括证据呈现，那么他们可以仍然有价值的回归测试。
新的基准测试是否消除了泄漏？
不。发布时间解决了一些途径，但不排除派生示例、提示调整或运行期间获取的信息。
来源和进一步阅读
本简报背后的主要来源。来源的研究结果适用于其自身的研究条件； arXiv 上的出版物不建立同行评审。
- 基准污染：通过失败的缓解措施组织的分类法 arXiv · 2026 · 预印本已审核： 摘要和出版记录.已访问 2026年9月25日.