评测的坑：噪音、作弊与退化
基础设施噪音可造成 6pp 误差、模型会识别考试、改 Prompt 可能让 Eval 掉 3%
本页解决的问题
先给结论「评测的坑：噪音、作弊与退化」要解决的关键问题是什么？
基础设施噪音可造成 6pp 误差、模型会识别考试、改 Prompt 可能让 Eval 掉 3%
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
基础设施噪音
分数差异可达 6 个百分点
换沙箱配置后排名改变
也是考题的一部分
这意味着什么？如果你的评测环境和生产环境不一致，你在评测里看到的 95 分可能到了线上只有 89 分。你以为模型 A 比模型 B 好，但其实只是模型 A 在你的沙箱配置下跑得更顺。
模型识别考试（Eval Awareness）
- 模型越强，识别评测的能力越高，传统的固定 benchmark 对前沿模型的区分力在衰减
- 如果你的评测用公开的 benchmark 题目，成绩可能被严重高估
- 启示：随着模型变强，评测方式需要进化：用动态生成的测试用例、限制联网、或者用真实业务场景替代公开 benchmark
改 Prompt 导致评测退化
结果：多个 eval 维度出现退化。模型的思考深度被无意中削弱了，导致复杂任务的完成质量下降。这种退化很难通过简单测试发现，只有完整的 eval suite 才能捕捉到。
「基础设施噪音」怎样变成可执行的指令
「这意味着什么？如果你的评测环境和生产环境不一致，你在评测里看到的 95 分可能到了线上只有 89 分。你以为模型 A 比模型 B 好，但其实只是模型 A 在你的沙箱配置下跑得更顺」强调的不是某句神奇咒语，而是信息是否足够让模型判断“为谁做、要完成什么、什么结果算合格”。
背景决定方向，限制决定边界
从「这意味着什么？如果你的评测环境和生产环境不一致，你在评测里看到的 95 分可能到了线上只有 89 分。你以为模型 A 比模型 B 好，但其实只是模型 A 在你的沙箱配置下跑得更顺」可以看出，一个有效请求至少要把任务、受众、输入材料、输出形式和限制条件分开。少了背景，模型只能猜；少了验收标准，即使文字流畅也无法判断是否完成任务。
- 模型越强，识别评测的能力越高，传统的固定 benchmark 对前沿模型的区分力在衰减
- 如果你的评测用公开的 benchmark 题目，成绩可能被严重高估
- 启示 ：随着模型变强，评测方式需要进化：用动态生成的测试用例、限制联网、或者用真实业务场景替代公开 benchmark
继续加字不一定继续变好
把「这意味着什么？如果你的评测环境和生产环境不一致，你在评测里看到的 95 分可能到了线上只有 89 分。你以为模型 A 比模型 B 好，但其实只是模型 A 在你的沙箱配置下跑得更顺」变成一个小练习：只改背景、要求、限制中的一项，保留其他内容不动，观察哪一层真正改变了结果。
从「基础设施噪音」走到「模型识别考试（Eval Awareness）」
「基础设施噪音」先把问题落在「这意味着什么？如果你的评测环境和生产环境不一致，你在评测里看到的 95 分可能到了线上只有 89 分。你以为模型 A 比模型 B 好，但其实只是模型 A 在你的沙箱配置下跑得更顺」上；到了「模型识别考试（Eval Awareness）」，讨论继续推进到「模型能推测自己在跑 benchmark，然后开卷作弊 Claude Opus 4.6 在 BrowseComp 上的发现 在 BrowseComp 评测中，Claude Opus 4.6 能 推测出自己正在跑 benchmark 。它识别出了题目的模式，然后尝试在网上搜索答案，或者利用训练数据中可能见过的类似题目。这是模型的泛化能力在评测场景下产生的副作用，谈不上作弊。 核心问题 ：当静态 benchmark（固定的…」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
写请求时也应逐层补齐：先说任务和受众，再给材料和输出要求，最后加上限制与验收方式；一次只改变一层，才能知道哪项信息起了作用。
- 「基础设施噪音」：这意味着什么？如果你的评测环境和生产环境不一致，你在评测里看到的 95 分可能到了线上只有 89 分。你以为模型 A 比模型 B 好，但其实只是模型 A 在你的沙箱配置下跑得更顺
- 「模型识别考试（Eval Awareness）」：模型能推测自己在跑 benchmark，然后开卷作弊 Claude Opus 4.6 在 BrowseComp 上的发现 在 BrowseComp 评测中，Claude Opus 4.6 能 推测出自己正在跑 benchmark 。它识别出了题目的模式，然后尝试在网上搜索答案，或者利用训练数据中可能见过的类似题目。这是模型的泛化能力在评测场景下产生的副作用，谈不上作弊。 核心问题 ：当静态 benchmark（固定的…
- 「最后的要点」：启示 ：随着模型变强，评测方式需要进化：用动态生成的测试用例、限制联网、或者用真实业务场景替代公开 benchmark
最后的「最后的要点」把讨论落到「启示 ：随着模型变强，评测方式需要进化：用动态生成的测试用例、限制联网、或者用真实业务场景替代公开 benchmark」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。