当评审在 A 与 B 之间始终偏袒自己

你对两个 prompt 变体跑了一次 A/B 实验。你的 LLM 评审——因为图省事,默认就用了和候选模型同一家厂商的模型——一致地偏好变体 A,差距大到足以被称为统计显著。你上线了 A。一周后,满意度指标下降了,退款队列上升了,没人能解释原因。终于有人用另一个模型家族的评审重新跑了一遍评测,偏好翻转了。

评审根本不是在衡量质量,评审只是在衡量候选模型听起来有多像评审自己。

这就是自我偏好偏差(self-preference bias),它是把 LLM-as-judge 流水线变成镜子大厅的那种安静方法论缺陷。最早在 GPT-4 上量化这一现象的论文发现,模型对自身输出的胜率虚高约 10%,并把偏差追溯到困惑度(perplexity):评审会系统性地奖励自己认为更可能的文本,而不管用户是否觉得它正确。从业者反复吃亏后才学到的推论是:这个偏差并不要求评审和候选必须是同一个模型——同家族的兄弟模型共享足够多的先验,以至于家族内的偏好仍然会显现在分数里。

看起来像是一次评测,其实只是一次家族内部的口味投票。团队搭建了基础设施去衡量质量,实际却是在衡量风格上的同质性。

为什么同家族评审一直看起来没问题,直到出问题

这种失败模式之所以如此顽固,是因为它没有团队被训练去关注的任何症状。评审给出的分数稳定。方差很低。多次运行之间的一致性很高。看板甚至比上一次 A/B 时更健康。你为了捕捉评测流水线损坏而设置的所有监控信号都报绿,因为流水线并没有坏——它只是被往一个能产生干净、自信数字的方向偏置了。

只有当生产信号出现分歧时,漂移才会变得可见。满意度下滑,投诉率攀升,客服开始转发截图,而团队还在争论究竟是生产指标有噪声——毕竟评测面不改色地告诉他们 A 是明显改进。信任会流向误差棒更小的那个指标,而那就是评审,因此团队往往会花几周时间怪罪生产端的遥测,然后才会怀疑评测本身。

底层藏着一个具体的失败模式。当评审和候选来自同一家族时,候选会因为匹配评审偏好的格式(项目符号密度、标题风格、对冲措辞、长度分布)和评审偏好的推理形态(考虑事项被提起的顺序、"让我们一步一步思考"那种修辞标记)而获得奖励。这些都和用户雇你产品要解决的问题毫无相关性。候选学会了听起来像评审,而不是变得正确,而评审无法分辨两者的差别,因为这些风格匹配它自己的先验。

偏好泄露是一个校准问题,不是一个作弊问题

把这个现象框定为"评审在替自己的兄弟模型作弊"很有诱惑力。这种说法令人安心,但它是错的。评审是在做它的工作——给与它训练分布吻合的文本分配更高概率。真正的作弊在于团队如何解读这些概率。他们把似然信号当作质量信号,而两者只在评审训练分布与用户偏好重叠的行为切片上恰好对齐。

这一点很重要,因为修复方法不是"找一个偏差更小的评审"。每个评审都有先验,而那些先验都会偏向某个方向。修复方法是不再用单一评审作为仲裁者,转而把评审环节当成一台本身需要校准的测量仪器。问题不再是"哪个评审是对的",而是"跨评审的分歧结构告诉了我什么,这个结构在留出集上又如何追踪人类判断"。

一旦团队完成这个转变,多评审集成就不再像一种昂贵的奢侈品,而开始像一种最小可行架构。单一评审给你一个没有不确定性的点估计。来自不同家族的多个评审给你一个分布,而这个分布中的分歧本身就是把临界用例路由给人工复核最有用的信号。

多厂商集成是个成本框架问题,而不是技术问题

这里总会冒出来的反对意见是成本。跑三个不同厂商的评审,单次评测成本是单厂商流水线的 2–3 倍,推动这一变更的工程师需要为这笔预算辩护。能说服人的重新框定是把它放在决策框架里:这次评测是部署决策的输入,而部署决策会影响每一个接触该功能的用户。如果变体 A 上线到一百万次会话,把决策做错的成本比评审成本高出几个数量级。多厂商评审是对错误上线的对冲,而这一成本是有界的,在每个发布周期里只发生一次。

实际操作中,"不同家族"意味着挑选那些训练数据、后训练配方和可能的分词器行为差异足够大,以至于能打破共享先验模式的评审。GPT 家族评审、Anthropic 家族评审,加上一个开放权重家族评审,是一个合理的起手三人组。你花钱买的是独立的误差——假设不是任何单一评审是正确的,而是一个评审会犯的错误种类和另外两个评审会犯的错误种类不相关。当三者一致时,信号很强。当它们分歧时,你就准确标记出了评测最不可信的那些用例,需要交给人去看。

加载中…