评分方式：先问你要拿这个结果做什么

查一个回答有没有违规，和选两个 prompt 里哪个更好，不一定要用同一种输出。别因为 API 能返回一个分数，就把每个问题都变成打分题。

几种常用方式，放在同一张表里

Reference-based 是「给什么信息」，不是这张表里的另一种输出。概率加权是「怎么汇总评分分布」，也不是新的质量维度。

交换 A/B，别把位置当答案

这里故意提供 3 个很简单的「假 judge」：按给定政策选、永远选第一个、偏爱较长回答。它们不是模型，只是把不同错误放大给你看。

保持任务、rubric 和两份答案不变，仅交换显示顺序。第一次选 A，第二次仍写「第一个」，不代表两次都支持 A。

可以保存：

{"case_id":"return-01","order":["answer-A","answer-B"],"winner":"answer-A"}
{"case_id":"return-01","order":["answer-B","answer-A"],"winner":"answer-A"}

两次都回到同一个答案 ID，才是这条样本的顺序一致。对 tie、both_bad、unknown 也要事先规定处理方式。重复交换依然可能得到同样的错误答案；一致性不是正确性。位置偏差研究值得和这个演示一起读。

胜率的分母，别最后才决定

假设有 20 道独立任务：A 胜 8、B 胜 6、tie 4、both_bad 1、unknown 1。

一种明确的约定是：unknown 进入弃权统计，both_bad 进入任务失败统计；质量胜率只在其余 18 条上算：

$$W_A=\frac{8+0.5\times4}{8+6+4}=\frac{10}{18}.$$

这只是一个约定，不是唯一正确公式。报告要同时给出 20 条总任务、1 条弃权、1 条双方失败，不能只贴一个 55.6%。如果两版都不满足底线，「A 相对更好」仍然不是发布理由。

Pairwise 也可能出现 A 胜 B、B 胜 C、C 胜 A。Elo 或 Bradley–Terry 可以在特定假设下拟合整体排序，但不是从几场胜负里发现了模型的唯一真实能力。

Checklist 怎么拆才不自欺

用户要「说明条件、期限、申请步骤」。可以拆成 3 项，逐项判断有没有覆盖，而不是让模型凭感觉给完整性 0.83。

但 3 项未必同样重要。把「标点好看」加入清单，不能拿它补上「退货条件说错」。某项根本不适用时，也得明确是 N/A 还是没做，别悄悄改分母。

QAG 通常指用生成的问题和回答来分解评估；DAG 指有先后依赖的决策图。具体框架里的命名和接口可能不同，别把名字当作质量保证。

硬门槛放前面，分项保留下来

Judge 返回的 JSON 无法解析 → evaluator error，不自动判被测答案失败
必要材料缺失 → unknown / 人工复核
确认违反权限或最终状态错误 → 对应 criterion fail
其余 → 分别评 groundedness、completeness、表达质量

可以同时记录所有维度，但最终放行规则要独立写清。一个越权下单的 agent，不应该靠礼貌用语把平均分拉回及格。

这里的 JSON 指 judge 的评分输出。如果任务本来要求被测模型返回合法 JSON，它却给了坏格式，那是被测模型的格式要求没完成，可以直接判该项 fail。先问清楚“是谁的输出坏了”，再决定把错误记在哪一层。

接着读：概率分数 · 具体场景