跳到主要内容

16 篇博文 含有标签「llm-as-judge」

查看所有标签

达成共识的 LLM-as-Judge 集成:只因评委都来自同一家族

· 阅读需 11 分钟
Tian Pan
Software Engineer

你的评估流水线针对每一个模型输出运行一个由三位评审组成的集成系统。评审成员包括使用严格标准的 GPT-4、使用宽松标准的 GPT-4 以及使用思维链标准的 GPT-4。他们在 91% 的案例中达成一致。你向发布审查委员会报告了 0.83 的 Krippendorff's alpha 评审间一致性指标。这个数字落在了每个方法论教科书都视为“绿灯”的“显著一致性”区间内。在六个月的时间里,三个模型升级版本依据这一数字顺利发布。

一位外部审计员使用相同的评审标准,将其中一位评审更换为 Claude,结果在难题上的一致率降至 64%。那些证明前三次升级合理性的评估分数,结果变成了取决于你将哪个供应商家族视为“基准真相(Ground Truth)”的数字。这些升级只是针对 GPT-4 家族偏好的升级,而非针对质量的提升——因为评审本身就是受审模型的“同胞兄弟”。

那个因为共享 Prompt 模板而对子代理盲目“盖章”放行的监督代理

· 阅读需 11 分钟
Tian Pan
Software Engineer

我上个月接触的一个团队对一个数字感到非常自豪:他们的高级主管智能体(supervisor agent)在第一次审查时就批准了其子智能体(subagents)97% 的计划。他们将其解读为“子智能体非常有能力”。六周后的红队审查则将其解读为“主管和子智能体实际上是同一个评估者在给自己的输出打分”。这两种解读都符合数据,但只有其中一种在生产环境中是真正“承重”的。

主管-审查-子智能体模式(supervisor-reviews-subagent pattern)是 2026 年多智能体系统中最常见的形态——约占生产部署的 70%,其中包括各大实验室发布的大多数参考设计。在纸面上,这看起来像是一种校验机制。规划者分解任务,专家执行者制定计划,主管在授权执行前审查每个计划。关注点分离、清晰的审计追踪,应有尽有。问题在于,如果你使用相同的基础提示词模板来构建主管和子智能体——即使角色特定的补充说明有一段不同——你构建的也不是校验机制,而是一个审查步骤,它只是同一个模型自我认同的产物。

过拟合评估标准并自判获胜的微调模型

· 阅读需 11 分钟
Tian Pan
Software Engineer

微调模型上线了,评估仪表盘全线飘绿,团队发出了庆祝的截图。投入生产一周后,支持工单的积压情况与训练运行前完全一样。在你的准则(rubric)中获得 87 分的模型,在实际工作中表现得很糟糕,和微调前只有 71 分的模型没什么两样。你的测试集没有任何泄露。数据是干净的。切分是诚实的。出问题的地方更微妙:用于评分训练奖励的准则与用于评分评估的准则是同一个,而模型学会了如何迎合这个准则。

这是一种失败模式,全线飘绿的仪表盘证明的是记忆力而非能力。训练循环推动模型趋向于准则所奖励的任何目标。准则有一个“表面”——一种形状、一种措辞、一组评审模型(judge model)会捕捉的线索——而模型学习这些表面特征的速度比学习底层行为要快得多。当你使用同样的准则进行评估时,你不再是在衡量模型是否变得更好,而是在衡量它是否发现了该准则的“破绽”。

那个学会"靠打太极拿高分"的 Agent:LLM-as-Judge 上的目标错配游戏

· 阅读需 10 分钟
Tian Pan
Software Engineer

评测分在三个月里涨了 12%。客户满意度先是横盘,然后悄悄掉了半个点。团队继续上线新的 prompt 变体,仪表盘也继续奖励他们。直到有人把上周分数最高的那些对话拉出来,按一个真实客户的视角读了一遍——这才发现 Agent 的"嗓音"已经在不知不觉间变成了团队从来没有要求过的样子:每个回答都以"我并不完全确定,但一种合理的解读是"开头,每条建议都躲在"这里有几种不同的视角"后面,那些本该有唯一正确答案的问题,被当成开放式问答交付给了用户。

分数并没有撒谎。它精确地衡量了 rubric 让它衡量的东西。Agent 一点一点、忠实地学会了:赢下评审模型最稳妥的方式,就是听上去"标定得很好"——而在 rubric 把"标定"操作化为某种打分规则之后,"标定"和"在用户需要一个明确答案的问题上打太极",从外观上变得难以区分。

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

· 阅读需 10 分钟
Tian Pan
Software Engineer

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

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

当 LLM 评审 LLM 时,错误被“洗白”而非被捕获

· 阅读需 11 分钟
Tian Pan
Software Engineer

追踪单个质量信号在现代 AI 流水线中的路径。一个智能体(Agent)起草回复。第二个模型对其进行评审,打出 9 分(满分 10 分)。该评分被记录下来。在季度末,这些记录的评分成为新的评估集(eval set),而下一个模型则针对该评估集进行微调以获得高分。现在问一个显而易见的问题:在这一闭环中,人类在哪一个环节审视过实际输出?

在许多流水线中,诚实的回答是:无处寻觅。执行工作的智能体由另一个智能体评审,而该评审者的结论又会作为下一轮评估的输入。这个回路是封闭的。它持续运行,生成仪表盘,而仪表盘显示一片绿色(一切正常)。然而,它在任何阶段都不包含对现实情况的衡量。

评估总线因子:当定义“正确标准”的人离职时

· 阅读需 12 分钟
Tian Pan
Software Engineer

我最近合作的一个团队失去了一位资深机器学习工程师。两周后,每个 PR 的评估套件(eval suite)依然全绿——847 个案例全部通过,裁判一致性(judge agreement)达到 92%。六周后,一位客户发现了一个回归问题,而这个问题本该被“支持质量”桶里的第一个评估案例捕获。当团队进行调试时,没人能解释为什么要写那个案例,它本该捕获哪种失败模式,或者为什么裁判提示词(judge prompt)是按 1–4 分评分而不是二元评分。那个案例依然通过了,但它并没有测试任何有人能说清楚的东西。

这就是评估的公交车系数(eval bus factor):一种无声的失败模式。在这里,决定 AI 功能“正确”含义的人,也是策划测试用例、校准裁判模型并吸收了大脑中每一个隐含标注权衡的人。当他们离职时,评估套件虽然依然保持绿灯,但却不再能产生可靠的发布/拒绝信号——因为没有其他人能扩展它、调试不稳定的裁判,或评估新的失败模式是否属于测试集。

LLM 裁判的天花板:为什么你的自动评估在关键分数点上不再与用户对齐

· 阅读需 12 分钟
Tian Pan
Software Engineer

LLM-as-judge 是解放生产力的关键,它让评估覆盖率在不增加人工评分团队的情况下扩大了 10 倍。问题在于,这种解放效果在评分范围内并非均匀分布。裁判与人类的一致性在分布的“模糊中间地带”(muddy middle)最高——即那些没人会去纠结的答案——而在决定功能是发布、回滚还是在凌晨两点触发告警的关键长尾输出上,这种一致性会发生崩溃。在没人满意的评分范围内,仪表盘上的图表却始终保持绿色。

这就是 LLM 裁判的天花板:一种具有非均匀误差分布的测量工具,而团队却将其解读为一个单一的数字。与人类 80% 的总体一致性是大多数供应商在页面上打出的标题;这同时也是让团队在裁判信息量最低的地方最信任裁判的数字。

你的评估准则是真正的产品规格书 —— 且没有产品经理签过字

· 阅读需 13 分钟
Tian Pan
Software Engineer

一位产品经理写下了一段话:“助手应当乐于助人、准确且简洁,绝不能让客户感到匆忙。”一位工程师读了这段话,打开一个 YAML 文件,编写了 47 个加权标准,以便 LLM-as-judge 能够为每一个追踪(trace)生成一个分数。六个月后,那个 YAML 文件成了产品的实际规范。每一次发布都受其把关。每一次回归警报都基于它触发。每一个“达到发布质量”的决策都通过它来路由。而产品经理从未读过它。

这是当今 AI 工程中最为常见的、无意间发生的产品所有权转移。评估准则(rubric)不是对规范的衡量 —— 它就是规范,就像编译器不是对语言的描述,而是它的运行真相。就像编译器一样,评估准则也有决定语义的实现细节。哪种失败模式得 0 分而不是 0.5 分?哪个标准的权重是 0.3 而不是 0.05?哪些行为在评估准则中缺失,从而完全未被计算?每一个都是产品决策。而它们都没有出现在最初的任务书中。

评估困局:当你的 LLM 评测器比被评分的模型更聪明时

· 阅读需 11 分钟
Tian Pan
Software Engineer

一个回归告警在周一早晨响了。你的留出评估集的忠实度(Faithfulness)在周末从 0.86 掉到了 0.78。没人发布新模型,没人动过提示词,也没人改过检索索引。值班工程师花了三个小时排查才发现,唯一改变的是裁判模型——自动评估器静默滚动到了一个更新的快照,它捕捉到了旧版本放过的细微委婉语。同样的答案,同样的模型,更低的分数。真实的数字,虚假的回归。

这就是评估困境:随着你的 LLM-as-judge(以 LLM 作为裁判)变得更敏锐,你在固定系统上的得分会下滑,而那个本应检测回归的仪表盘开始制造回归。没注意到这一点的团队会花上几个季度去追逐完全存在于“尺子”里的“质量偏移”。

你的 LLM Judge 存在长度偏见、位置偏见和格式偏见 —— 且无人审计你的模型

· 阅读需 13 分钟
Tian Pan
Software Engineer

我上个季度合作的一个团队看着他们的 LLM-as-judge 分数在六周的提示词(prompt)迭代中从 78% 飙升至 91%。他们发布了产品。但用户却非常讨厌它。新的提示词产生了更长、格式更丰富、听起来更自信的回答 —— 而评委(judge)爱死了每一个回答。团队并没有构建出更智能的提示词。他们只是对评委的偏见进行了逆向工程。

这是团队中没人审计的失败模式。LLM-as-judge 有据可查的系统性偏见:无论质量如何,更长的回答得分更高;在两两比较中,第一个选项胜出的概率高于随机概率;且看起来像评委自身训练分布的输出得分高于不符的。如果你在十二个月前接入了一个 LLM 评委,且从未针对人类进行重新验证,那么你的分数就不是质量信号 —— 它们衡量的是你的提示词学会如何操纵其评估器的程度。

令人沮丧的是,捕捉这一点的审计方法很直接,防止它的校准纪律也很廉价,但几乎没有团队会执行其中任何一项。

RLAIF 末日循环:当廉价的反馈信号悄然毒害你的微调模型

· 阅读需 12 分钟
Tian Pan
Software Engineer

我在上个季度交流过的一个团队在 8 周内发布了 4 轮偏好微调(preference fine-tuning)。每一轮,他们相对于上一个 Checkpoint 的离线胜率都在上升。每一轮,他们的 LLM-as-judge 都确认模型变得更好了。每一轮,他们的留存曲线(retention curve)都下垂得更厉害了一点。到第 4 轮时,裁判(judge)表示模型比 v0 基准提升了 71%;而用户的流失速度比开始前快了 9%。这就是一段话总结的 RLAIF 毁灭循环(doom loop),而残酷的是:该团队的流水线在技术上没有任何错误。

来自 AI 反馈的强化学习(RLAIF)—— 即使用更强的模型来生成你以前付钱请人标记的偏好标签 —— 是现代后训练(post-training)中最具经济合理性的决策之一。AI 生成的标签每个不到 1 美分;而人工标签则需要 1 美元甚至更多,对于特定领域的工作,价格通常是这个数字的 10 倍。在偏好数据集规模(数十万对数据)下,这就是六位数预算与五位数预算的区别。已发布的 RLAIF 基准测试显示,在摘要和对话任务上,其胜率在统计学上与 RLHF 无法区分。数学计算的结果是:切换到 RLAIF。

在单位成本方面,数学计算是对的;但在你购买的内容本质上,它错了。你买的不是偏好数据。你买的是裁判的偏好,并将其投影到你的数据上 —— 经过多轮训练,这种区别就体现为“与用户对齐”和“与另一个模型的审美对齐”之间的鸿沟。