评分面板：60/30/10 混合比例，为何绝不能只靠裁判 LLM
每一条 golden-set 用例都由一个评分器面板（panel of scorers）打分，业内趋同的比例是约 60% 确定性评分 / 约 30% LLM 裁判（LLM-as-judge）/ 约 10% 人工。承重规则是：绝不能只依赖一个 LLM 裁判——这会把评分器自身的随机性叠加在系统本身的随机性之上，而且裁判给出的绝对分数会随模型版本漂移。确定性评分器是基准事实；裁判负责代码看不到的部分；人工负责裁判不可信任的部分。
确定性的 60%（便宜、不容争辩）
Schema/JSON 合法性 · 必需实体/数字是否存在（正则/精确匹配）· 禁用内容零命中 · 长度、延迟、成本是否在范围内 · 引用的 URL 是否真的可解析 · 工具调用参数是否类型正确。凡是能用代码表达的，就必须用代码——这和 um 的 lint 是同一种直觉（"硬性规则由代码检查——你无法靠争辩绕过去"）。
LLM 裁判的 30%——三种具体形式
- G-Eval（DeepEval 的旗舰方法）：给裁判一份自然语言评分标准（"按 1–10 分评估答案是否基于给定上下文；如有…扣分"），得到一个带推理过程的评分结果。
- DAG / 决策树式评判：把"好"分解成一棵二元判断的树（先问：回答了问题吗？→ 只有答了才问：语气对吗？→ 再往下…）。每个节点都是一个容易判断的问题；这能防止裁判把一切都平均成一个 7 分的"一坨分数"失败模式。
- 成对比较（Pairwise comparison）：不做绝对打分——把两个候选并排放，选出更好的那个（LMSYS-Arena 的原则）。相对判断比绝对分数稳定得多；A 提示词 vs B 提示词的决策要用成对比较。
- 裁判校准是强制项：在一份带标签的子集上测量裁判与人工的一致率；低于阈值 → 重写评分标准，而不是重写系统。
人工的 10%
只处理裁判不可信任的那些用例（品味判断、高风险的模糊情形）；每一条人工判定都会回流成一条带标签的用例，用来校准裁判。
与 um 的关系： um 采用和主流一样的分层——T0（机械检查）/ T1（agent 审查）/ T3（owner）——但 um 的 T1 补上了主流裁判缺的东西：全新上下文、只看产物字节的输入、前提重新推导、逐条判定的引用证据。主流则补上了 T1 缺的东西：用带标签的基准事实来校准裁判。
来源：evals 主流实践（DeepEval 的裁判分类法、Braintrust 评分器文档，2026-07 现状核查）