LLM 裁判二元对齐框架

LLM As Judge Binary Alignment · llm-as-judge-binary-alignment--shreya-shankar

解决什么问题

某个失败模式太主观、无法用代码断言检查（如"该不该把对话转接给人工"），想用 LLM 自动判断，但直接写个裁判 prompt 就当真会产出不可信的 evals——团队一旦发现 eval 不可信，就再也不信你的 evals。

核心内容

一个 judge 只判一个失败模式。不要造通用质量裁判。正因任务范围极窄，judge 比你的主应用容易做得可靠得多——"这不是和原问题一样难的问题"。
输出必须二元 pass/fail。禁用 1-5 / 1-7 Likert 打分：打分是"不做决定的鸡贼方式"，没人知道均分 3.2 和 3.7 的区别，也无法与人对齐。
judge prompt 写法：要求输出 true/false，然后枚举该失败模式的具体判定规则（以"人工转接"为例：用户明确要求转人工却被忽略/绕圈、政策强制转接场景、敏感住户事务、工具查不到数据、当天 walk-in 看房请求等）。规则全部来自 error analysis 里真实看到的错误，可让 LLM 起草，但必须人工审改。
上线前先与人对齐（最常被跳过的一步）：拿已人工标注的数据测 judge，做"人类判定 × judge 判定"的 2×2 混淆矩阵。不要只看 agreement 百分比——错误在长尾（如只占 10%）时，judge 无脑全判 pass 也能拿 90% agreement。要分别盯住两个非对角格（人说有错 judge 说没错、人说没错 judge 说有错），迭代 prompt 把它们压到接近零。注意切分数据集，避免用调 prompt 的同一批数据自证。
两个用途：(a) 放进单元测试 / CI，把历史失败样例固化为回归测试；(b) 在线监控——每天从生产 traces 采样（如 1000 条）跑 judge，得到真实失败率仪表盘。evals 不只是上线前的事。
数量预期：一个产品通常只需 4-7 个 LLM judge。大多数失败模式改 prompt 就能修，只给顽固的主观问题建 judge——这是优先级游戏，资源有限，不要为一切写 eval。

适用边界

只用于代码断言做不了的主观失败模式；能用代码检查的（JSON 格式、markdown、长度）用代码，更便宜。
未对齐的 judge 等于没有 evals。管理者听到"agreement 75%，没问题"却拿不出混淆矩阵，就是坏信号，应要求返工。
对齐后仍会有残余不一致，可接受（还可做统计校正，课程内容，本集未展开）。

关键引述 · 原话

Shreya Shankar: "The output of this LLM judge is pass or fail. So it is a very, very tightly scoped thing that LLM judges are very capable of doing very reliably."

Hamel Husain: "When people lose trust in your evals, they lose trust in you."

— Shreya Shankar & Hamel Husain

关联卡片

LLM错误分析生命周期评估标准漂移

- 上游：`ai-evals-error-analysis-lifecycle--hamel-husain`（judge 判什么由 error analysis 决定） - 呼应"evals 是新的 PRD"：judge prompt 本质是一份持续自动执行的产品需求说明，且随数据演化（见 `criteria-drift--shreya-shankar`）

出处：Shreya Shankar & Hamel Husain (AI Evals 课程创作者；研究员 / ML 顾问) · 03-podcasts/hamel-husain--shreya-shankar.md
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast（2019–2026）。本站为个人学习用途的二次创作，与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2