前端进阶之旅前端进阶之旅
基础篇
进阶篇
高频篇
精选篇
手写篇
原理篇
面经篇
AI 面试
自检篇
每日一题
  • 综合
    • 综合题型
    • 其他问题
    • 设计模式
    • 思维导图
    • 学习路线
  • 前端基础
    • HTTP
    • 浏览器
    • 计算机基础
  • 进阶学习
    • NPM工作流
    • Docker
    • Canvas
    • Node学习指南
    • 前端综合文章
  • 其他
    • Handbook
    • 职场话题
    • CSS可视化
小程序题库
公众号动态
博客动态
AI 热点
开发者导航
基础篇
进阶篇
高频篇
精选篇
手写篇
原理篇
面经篇
AI 面试
自检篇
每日一题
  • 综合
    • 综合题型
    • 其他问题
    • 设计模式
    • 思维导图
    • 学习路线
  • 前端基础
    • HTTP
    • 浏览器
    • 计算机基础
  • 进阶学习
    • NPM工作流
    • Docker
    • Canvas
    • Node学习指南
    • 前端综合文章
  • 其他
    • Handbook
    • 职场话题
    • CSS可视化
小程序题库
公众号动态
博客动态
AI 热点
开发者导航
返回 AI 情报前线
All News · 全部资讯4062
  • Google 开源 PaliGemma:视觉任务微调的轻量基础模型
  • 多 Agent 并行工程:从审查瓶颈到可扩展工作流架构
  • 医疗网络用 Agent 批量验证医生提供者注册信息
  • pytest 测试套件静默失败:模块级 sys.exit() 打破收集器
  • MCP集成:让Claude访问实时食品检查数据
  • DBOS:数据库操作系统化解复杂时序任务容错难题
  • 构建高效AI辅助调试工作流:上下文优先于粘贴错误
  • 国际刑警报告:AI已成非洲网络犯罪核心驱动力
  • 谷歌AI编程课35万人参与:vibe coding大规模实践
  • Strands 框架实现多智能体游戏设计编排
  • AI 项目生产维护:如何应对「第二天」问题
  • 用 Apify MCP 为 Claude 添加食品召回实时查询
  • 用 Apify MCP 为 Claude 添加 FDA 药物不良事件查询
  • Google Agent Skills:规模化构建和维护 AI Agent 指令库
  • Claude Code vs Codex CLI:终端编码 Agent 2026 对比
  • 别再凭直觉选参数:系统扫描找到最优点
  • FDA 药物标签工具:MCP 实战集成指南
  • 用 MCP 为 Claude 接入欧盟制裁名单实时查询
  • 基准测试陷阱:重复测试前的准确性检查
  • 用 MCP 为 Claude 接入欧盟 VAT 验证服务
  • 用 AI 评分前必测评判者本身的离散度
  • Agent 系统设计:模型负责智能,Harness 负责可靠性
  • 优化 OCR 功耗不靠加速,靠减少调用
  • 开源视频模型首次登顶排行
  • 生产 AI 助手的周度日志审计工程实践
  • 新模型发布后应先做验收测试再切换
  • DeepSeek 小模型性能反超旗舰版
  • 在被迫迁移前准备LLM供应商退出方案
  • OpenAI悄悄降价80%、价格追踪工具如何失效
  • JFrog 曝光:54 个虚假 CVE 建议通过审批流程
  • 用 Apify MCP 为 Claude 接入实时 OFAC 制裁查询
  • 生产 Agent 的决胜因素:系统架构而非模型选择
  • Cloudflare Workers RPC 跨语言对象交互
  • 大模型推理优化:量化、压缩与安全验证
  • 突破容器限制:为 Agent 设计专用运行时
  • JetBrains 分享 AI 工具成本管理经验
  • Karpathy实测Claude Opus:一段文本变5500行3D代码
  • 商汤开源 4K 图像生成模型 SenseNova U1.5 Lite
  • SQLite"漏洞"还是AI幻觉?JFrog安全剖析
  • Nightcrawler:离线运行在手机的AI安全测试Agent
  • 企业 AI 7 大误区:RAG 优于 fine-tuning 的成本优化
  • 阿里 Qwen3.8-Max 对标 Fable 5 和 OpenAI 前沿模型
  • 阿里开源 Qwen3.8-Max:2.4 万亿参数长链条模型
  • GPT-5.6独立破解量子密码:两队竞速仅差3小时
  • DeepSeek-V4-Flash 开源:304B 模型成本降 65%
  • Markdown 规范如何指导 AI Agent 改代码
  • 无人值守 AI Agent 的异步审批模式
  • AI 时代工程师哪些角色在消退,哪些在成长
  • Agent失控:OpenAI与Anthropic的沙箱逃逸事件
  • AI推理强大不代表适合工作流:架构决策的反思
  • Pipe语言:将AI操作设计为一等公民的新范式
  • 已加载 51 / 4062
8.0
热点
AI SCORE
技术实践2026-08-03 22:10

用 AI 评分前必测评判者本身的离散度

dev.to · AI#LLM评估#性能度量#AI可靠性
Editor brief · 编辑速览

LLM-as-judge 的陷阱:同一输入两次评分差 6.1 分,掩盖真实改进。强调先测量评判者的噪声,低于该阈值的差异都是虚假。

文章思维导图
Knowledge map
拖拽缩放
Full translation

完整中文译文

“上下文带来 +7 分”只是假象——先测量评审的波动范围

当我让 AI 给质量打分时,仅仅对同一份内容重复测量两次,分数就相差了 6.1 个百分点。而这个波动,恰好与我正准备采纳的“提升 7.2 个百分点”几乎一样大。把两个方案放在一起直接比较,胜率只有 53%——与势均力敌没有可辨别的差异。

评审是一种测量工具,而任何测量工具都有自己的噪声和偏差。在测清楚这些之前,不要根据它的输出做决定。

一句话概括:先测量评审的波动范围,任何小于或等于这一范围的差异,都不要称为提升。

把质量转化成数字并不容易。一份翻译是否优秀、一段摘要是否切中要点、一个回答是否有帮助——对于这种“好”,并不存在一把客观的尺子。因此,现在大家都会想到一种做法:让 AI 来评分(LLM-as-judge;下文中,“评审”均指负责评分的 AI)。它比人工更快、更便宜,而且无论面对 100 条还是 1,000 条内容,都能给出“这一条通过、那一条不通过”的判断。

我曾经把翻译质量的判断完全交给这个评审。尝试一种改动,让它评分;如果分数提高,就采纳改动。看起来,这是最理所当然的运作方式。

但后来我意识到,顺序完全反了。我一直在测量改进效果,却从未测量过评审本身。如果尺子本身会伸长、缩短,那么用它测出来的“提升”究竟意味着什么?当我真正回过头来质疑评审时,才发现自己正准备采纳的一项改进——其实只是假象。

发现一:同一份内容测量两次,分数相差 6 个百分点

最初让我产生怀疑的,只是一次非常简单的检查:如果把同一份翻译交给同一个评审,让它评分两次,会发生什么?

如果两次返回的结果相同,就说明这把尺子是稳定的。但事实并非如此。在绝对评分模式下(即逐条判断每份翻译是否通过),我用完全相同的模型和完全相同的设置生成翻译,第一次评分结果是 89.6%,第二次则是 95.7%。什么都没有改变,两次评分却相差了 6.1 个百分点。

在翻译领域,6 个百分点已经足以算得上一次“显著提升”。换句话说,评审自身的噪声,就相当于一整次改进的幅度。

而且,这种噪声确实造成了实际影响。当时我有一个假设:如果把上下文(前后的对话内容)提供给模型,翻译质量就会提高。绝对评分的结果是:无上下文 89.6% → 有上下文 96.8%,提升 7.2 个百分点。看起来是一次毫无争议的胜利。我差一点就得出“上下文有效”的结论。

发现二:直接对决时,胜率只有 53%——势均力敌

但 7.2 个百分点的提升,几乎与评审仅仅重复测量同一份内容所产生的 6.1 个百分点差距一样大。一个没有超过波动范围的差异,本身并不可信。于是,我改变了测量方法。

我放弃绝对评分,改用 pairwise(相对评分:把两份翻译并排放在一起,只问“哪一份更好?”)。对于同一段源文本,我把无上下文和有上下文的翻译分别放在左右两侧,让评审只选择更好的一份。左右顺序会随机打乱,以抵消位置偏差。

结果是:有上下文版本的胜率为 53%(排除平局后的胜率——而且平局很多)。本质上,两者不分胜负。并且,这个 53% 只是一个点估计;当时我没有记录样本量 n,也没有计算置信区间。因此,准确地说,这并不是“以 53% 的胜率获胜”,我最多只能说:“它与 50% 没有可辨别的差异,双方势均力敌。”无论如何,原来的 7.2 个百分点提升已经消失了。

真实发生的情况是这样的:在绝对评分中,评判标准会随着每次评分时评审究竟更严格还是更宽松而变化。无上下文版本碰巧是在严格标准下评分,而有上下文版本碰巧是在宽松标准下评分——所谓的 7.2 个百分点,真正反映的是这种“心情差异”。如果针对同一段源文本,让两个版本直接对决,那么这种心情会同等作用于双方,相互抵消,最后留下的就只有真实差异——而真实差异几乎为零。

这不只是一个关于“我以为有效的杠杆,最终被证明只是假象”的故事。它改变了我的工作方式:任何曾经通过绝对评分被判定为“胜出”的方案,都值得用 pairwise 方式重新测量。

发现三:AI 评审会把意译视为错误

还有一个问题:我委托评分的 AI(也就是评审)存在一种系统性偏差。它对改写和意译的要求过于严格。

让它判断一份翻译是否匹配时,评审会毫不犹豫地把“含义相同、措辞不同”归类为“不匹配(即错误)”。任何人都能看出表达了相同含义的翻译,却会被它机械地打上叉号。而且,无论我怎样调整 prompt,这种现象都顽固存在。换用更聪明的模型担任评审、向它提供上下文、把评审流程设计得更加谨慎——这种偏差依然不会消失。即使使用最聪明的评审,也有接近 80% 的“错误”判定其实是误报(详细数据见附录)。

这会让整体统计结果出现严重偏差。我人工审核了 90 对翻译:真实失败率是 6.7%。与此同时,评审却对 15%~20% 的内容高喊“失败”,高估了 2~3 倍。如果直接把这个原始失败率当作 KPI,就会因为质量不佳的虚假警报,让人们投入根本没有必要的返工。

解决办法是校准。对于这个评审:真实失败率 6.7% ÷ 原始失败率 15%~20% = 0.3~0.45 的校准系数。在汇总数据之前,应先乘以这个经过测量的系数范围——绝不能直接使用评审给出的原始数字。不同评审的校准系数并不相同,因此每次都要通过人工审核重新测量。

因此,我改变了自己的工作方式

这三项发现看起来像是三个彼此独立的问题,但它们有着共同的根源。评审是一种测量工具,而任何测量工具都有自己的噪声和偏差。在测清楚这些之前,不要根据它的输出做决定。

先测量评审的波动范围,任何小于或等于这一范围的差异,都不要称为提升。所谓的 7.2 个百分点提升,与重复测量同一份内容产生的 6.1 个百分点波动处于同一量级,因此单凭这个结果,不能把它称为提升。

使用直接对决(pairwise)进行评审,而不是依赖绝对分数。在绝对评分中,评判标准本身会随着评审的“心情”变化。让相同的两个条件重新直接对决后,原来的 7.2 个百分点提升变成了 53% 的胜率——也就是势均力敌。

如果一定要使用绝对比率,就通过人工审核测量校准系数。评审给出的原始失败率是真实值的 2~3 倍。未经校准的绝对比率,会直接扭曲业务决策。

在实际工作中,最终可以归结为四条规则。

只有先建立经过校准的评审,“把小模型培养成专用模型所带来的 42% → 84%”,或者“通过 gate 比较模型所得到的 +14.7 个百分点”——这两个改进数字在其他文章中有所介绍——才值得相信。修好尺子,是开始测量之前必须完成的工作。

“先测量”并不意味着“测量很多东西”。它意味着测量正确的对象,并以正确的方式测量。而通常来说,第一个需要正确测量的对象,正是测量工具本身。

术语:precision = 在被评审判定为 X(不匹配)的项目中,真正属于 X 的比例。better-match = 一种评审流程:评审先从一对翻译中选出最接近的对应版本,然后再进行判断。

本文最初发布于 LYR Performance Note #023,是“Measure & tune——先正确测量,再调整设置”系列的一部分。完整系列见 lyr.jp/en/research。

如需采取进一步措施,你可以考虑屏蔽此人和/或举报滥用行为。

Original source

本文由 AI 翻译整理自 dev.to · AI,原文版权归原作者所有。

阅读英文原文
上一篇
用 MCP 为 Claude 接入欧盟 VAT 验证服务
下一篇
Agent 系统设计:模型负责智能,Harness 负责可靠性