arXiv cs.AI 在 2026 年 9 月 4 日列出的 Clean Engineering, Unstable Measurement: A Preregistered Reliability Failure of Black-Box LLM Observers on Shared Endpoints 是今天最值得读的评测论文之一。它的摘要很直接：LLM judge 已经用于训练数据筛选、生成质量评分和排行榜，但它依赖一个很少被明说的假设，即同一个请求发给同一个模型名，明天应该读出同样的测量结果。作者在预注册审计中发现，这个假设在共享端点上站不稳。
这件事的影响比一篇论文更大。过去一年，开发团队越来越依赖 LLM observer：让模型审查另一个模型的回答，让模型判断 agent 是否完成任务，让模型给 PR 质量打分，让模型决定数据能否进入训练集。表面上，评测流程变得自动化、规模化、看起来更科学。但如果 observer 自身没有被校准，它可能只是把不稳定包装成了数字。
LLM judge 是测量仪器，不是事实来源
很多评测流水线会这样写：
candidate output
-> LLM judge
-> score
-> leaderboard or release gate工程上这很方便。开放式回答很难用 exact match 判断，agent 任务也不是每次都有程序化 oracle。让一个强模型当 judge，似乎能把模糊质量变成分数。
问题是，测量仪器本身需要稳定。温度计可以有误差，但误差要可估计；秤可以有偏差，但偏差要能校准。如果一个 observer 今天把 A 排在 B 前面，明天在相同输入下又把 B 排在 A 前面，而你不知道为什么，那么它就不适合直接作为严格门禁。
论文摘要里最刺眼的数据是：52,988 次审计请求中，同窗口重复排序的 Spearman agreement 只有 0.400，而预设要求是 0.90；字节完全相同的次日回放 agreement 为 0.78，而要求是 0.99。无论你是否认同具体阈值，这个量级都说明共享端点 judge 的噪声不能忽略。
为什么共享端点特别危险
共享端点的便利，正是它的测量风险来源。你调用的是一个模型名，而不是一个完整可复现仪器。模型名背后可能有路由、热更新、混合 batch、服务降级、不同硬件、推理内核差异、供应商侧安全过滤和隐藏参数。
这些差异在聊天产品里可能无所谓，甚至是必要优化。但在评测里，它们会变成未记录变量。你以为在比较两个候选模型，其实可能在比较两个时间点的 observer 状态。
更麻烦的是，LLM judge 常用于比较“很接近”的候选。两个回答质量差距本来就小，observer 的噪声可能大过候选差距。论文摘要提到 candidate gaps 远低于仪器噪声 floor，这就是典型的测量失配：你拿分辨率不够的尺子量很细的差异。
排行榜会发生什么
排行榜最容易受到影响。假设一个榜单每周评测 20 个模型，每个模型只跑一次 judge 分数，然后按平均分排序。如果 observer 噪声足够大，名次变化可能被误读为模型能力变化。
这会引出三类错误结论。第一，模型 A “超过”模型 B，其实只是当天 observer 偏差。第二，某个 prompt 策略“显著提升”，其实只是格式更讨 judge 喜欢。第三，供应商更新模型后看似退步，实际是 observer 或评测端点漂移。
排行榜不是不能做，但必须报告不确定性。至少要有重复测量、bootstrap 区间、不同 observer 交叉验证，以及固定样本的历史回放曲线。单个数字加两位小数，在这种场景下是一种虚假的精确。
发布门禁的风险更高
比排行榜更危险的是发布门禁。很多团队已经把 LLM judge 放进 CI：
new model or prompt
-> run eval set
-> judge score above threshold
-> deploy如果阈值基于不稳定 observer，CI 会出现两种坏结果。第一种是误拦截，团队浪费时间追查不存在的质量回退。第二种是误放行，真实回退被 observer 噪声盖住。前者影响效率，后者影响用户。
正确做法是先校准仪器，再冻结门槛。论文的一个重要结论是，约 2% 调用量的 pilot 就能提前暴露不可达门槛。这个建议很实用：正式评测前，先用小样本做重复请求、次日回放、标签重排、provider 对比。如果 observer 连这些基本稳定性测试都过不了，就不要把它接进发布门禁。
训练数据筛选会更隐蔽
LLM judge 还常用于训练数据筛选，比如挑出高质量回答、过滤低质量推理链、给偏好数据排序。这时 instability 更隐蔽，因为错误会进入模型，而不是马上在 CI 报红。
如果 judge 偏好某种标签表达、某类措辞或某个结构，训练数据会被系统性扭曲。模型随后学到的可能不是更好能力，而是更会迎合 observer。这个问题在 RLHF、RLAIF、DPO 数据构造和 agent trajectory filtering 中都存在。
更稳妥的做法是把 judge 输出当成弱标签。弱标签可以用，但要混合程序化校验、人工抽检、对抗样本和多评委一致性。尤其是高价值数据，不应该由单次黑盒 judge 独自决定去留。
三层快照身份
评测系统需要一个“snapshot identity ladder”。最低层是模型名，比如 frontier-judge-latest。这几乎没有复现价值。中间层是供应商声明版本、参数、日期和区域。它比模型名好，但仍然不能覆盖服务实现细节。最高层是冻结权重、推理内核、硬件、batch 策略、采样参数和输入字节记录。
不是所有团队都能做到最高层，但至少要清楚自己在哪一层。拿最低层结果做研究论文或生产门禁时，就应该报告限制，而不是默认它是可复现仪器。
对企业来说，可以把 observer 分成两类：探索 observer 和门禁 observer。探索 observer 可以用最新共享端点，帮助快速发现问题；门禁 observer 应该尽量使用冻结版本、重复测量和保守阈值。
工程改造建议
第一，所有 judge 调用都要记录完整输入、输出、模型标识、时间、区域、参数、重试次数和解析状态。没有执行记录，就无法区分模型质量变化和评测系统故障。
第二，采用成对比较时要做顺序随机化。很多 judge 对候选 A/B 的位置敏感，如果总把新模型放在 A，分数会有结构性偏差。
第三，阈值要有缓冲区。不要把 0.801 通过、0.799 失败当成可靠边界。门禁应分成通过、失败、需要复核三个区间。
第四，保留 sentinel set。每天用固定样本回放 observer，监控 judge 自身漂移。如果 sentinel 分数变了，先暂停解释业务模型变化。
第五，高风险决策要混合 oracle。代码任务看测试，抽取任务看 schema 和字段准确率，数学任务看程序验证，安全任务看策略引擎。LLM judge 适合补充语义判断，不适合替代所有事实校验。
和 agent 评测的关系
Agent 评测特别依赖 observer，因为长流程任务经常没有简单答案。一个浏览器 agent 是否“完成报销流程”，一个 coding agent 是否“合理重构模块”，都很难用单个断言表示。
但 agent 评测也最怕 observer 不稳。Agent 本身已经有环境随机性、工具失败、网络波动和多轮状态漂移。如果再叠加不稳定 judge，你很难知道分数变化来自哪里。
因此 agent 评测应优先记录轨迹级证据：每一步动作、环境反馈、文件 diff、测试结果、权限请求、用户确认。LLM judge 只在证据之上做解释和评分。不要让 judge 直接看一段摘要就决定整个 agent 是否可靠。
结论
黑盒 LLM observer 不是坏工具，坏的是把它当成天然稳定的事实机器。它更像一台需要校准的仪器，而且在共享端点上，这台仪器可能由别人持续调整。
这篇论文给开发者的警告很具体：评测系统上线前，先评测评测器。不要先冻结阈值，再发现 observer 自己过不了重复性测试。不要把模型名当快照，不要把单次分数当结论，不要把排行榜小数点当科学精度。
AI 工程的下一阶段，可靠性不会只来自更强模型，也来自更诚实的测量。能说清楚“我用什么仪器测、仪器有多稳、误差有多大”的团队，才有资格把评测分数接进训练和发布流程。