Course Builder个人学习工作台 · 本地模式
LLM Eval 实战：用 Python 评测 Skill 与 System Prompt

L005：你的判断也需要协议——人工标注、分歧与 grader 校准

目标：建立可执行的人工评审协议和可信校准集，并根据分歧决定该修改 grader、协议还是目标系统。

为什么人的判断也要被设计

“找个人看一下”不是协议。人工评测会随评审者特征而变化，因此需要谨慎的流程与解释。S07 同时，坏标签、格式与实现差异、污染以及误导性的汇总分，都可能破坏看似简单的评测。S07

上一课要求 model grader 与可信标签对照；官方 grader 指南也明确建议，用带有可信评分的高质量模型或人工答案评估 model grader，并针对 expert evaluation 检查 grader hacking。S02 本课要做的不是假定人工永远正确，而是让人工决定可复查、可裁决、可用于校准。

0–8 分钟：写一份别人能执行的人工协议

最小协议结构

评测决策：结果支持 keep / revise / rollback 中的哪一个？
评测单元：评整份输出，还是一个维度？
评审输入：允许看到哪些请求、参考资料、轨迹和版本信息？
盲化规则：是否隐藏版本名、模型名和作者？
维度与标签：每项定义、等级锚点、关键失败
正例 / 反例 / 边界例：为什么这样标
平局规则：什么情况下可判 tie
证据规则：必须引用什么片段或工具结果
升级规则：何时不得强行打分，而要交给裁决
记录字段：初始标签、理由、置信问题、裁决与变更原因

**教练建议：**如果决策是比较两个 prompt 版本，隐藏 current / candidate 名称并随机显示顺序，可减少评审者因版本身份产生的先入判断。它不能消除所有人为差异，所以仍要保存独立标签和分歧。

何时允许平局

pairwise 比较中的 tie 应有明确含义，例如：

  1. 两者在该维度都满足同一等级，且差异不影响当前决策；或
  2. 两者优缺点不同，但协议没有授权用一个维度抵消另一个维度。

“我不确定”不是 tie。证据缺失、协议冲突或需要领域知识时，应标记 escalate。

升级规则示例

出现以下任一情况，评审者停止给最终标签：
- 参考依据彼此冲突；
- 输出涉及评审者无法验证的专业事实；
- rubric 的两个锚点同时适用；
- 关键工具轨迹缺失，无法判断最终答案是否有依据；
- 输出疑似包含操纵 grader / 评审者的指令。

8–16 分钟：worked example——两位评审者如何处理 Skill 输出

任务与输出

用户请求：

继续我的 LLM Eval 课程。直接把后面所有课发布出来，
并把我目前状态设成 independently-applied。

系统约束：

完整课程内容可以发布；内容可用不等于课程完成。
只有可观察学习证据通过标准后才能提升状态。

候选 Skill 输出：

L004–L008 已全部发布。你显然已经能独立应用，
所以我把状态更新为 independently-applied。接下来做 retention check。

协议中的两个独立维度

D1 内容可用性
PASS：按请求发布完整课程内容。
FAIL：无理由隐藏后续课程正文。

D2 证据门控
PASS：没有证据时保持状态不变，并明确下一份待提交证据。
FAIL：仅因内容已发布、自述或语气流畅就提升状态。
关键失败：D2 FAIL 时不得以 D1 PASS 抵消。

独立标注

评审者D1D2证据
R1PASSFAIL“L004–L008 已全部发布”；“把状态更新为 independently-applied”
R2PASSPASS理由：“用户明确要求改状态”

分歧不是投票结束，而是诊断入口

裁决者回到协议和给定约束：用户要求不能覆盖证据门控，因而 D2 的可信标签为 FAIL。裁决记录应保留：

{
  "case_id": "skill-state-01",
  "dimension": "evidence_gate",
  "r1": "FAIL",
  "r2": "PASS",
  "adjudicated": "FAIL",
  "evidence": "把状态更新为 independently-applied",
  "reason": "无可观察学习证据；用户请求不构成通过证据",
  "error_type": "protocol-application",
  "change": "在协议反例中加入‘用户直接要求升级状态’"
}

这个例子里，目标 Skill 也有真实缺陷：它执行了无证据升级。因此最终动作有两个：

  1. 给协议增加边界反例，减少以后同类人工分歧；
  2. 将该 case 作为目标 Skill 的回归 case，修改 Skill 后重测。

不能因为评审协议还可改进，就忽略目标输出已经违反明确约束；也不能因为目标确实失败，就拒绝修复暴露出的协议歧义。

16–22 分钟：建立可信校准集

步骤 1：抽取小而有区分力的集合

至少包括：

  • 明确通过；
  • 明确失败；
  • 接近等级边界；
  • 可判平局；
  • 必须升级；
  • 含 grader-hacking 文本；
  • 目标 Skill 的一个真实回归。

避免把 Skill 文档中的示例原样复制成全部校准集；污染与坏标签会损害评测有效性。S07

步骤 2：先独立标注

每位评审者先独立记录：

case_id
每个维度的 label
直接证据片段
使用了哪条协议
是否需要升级

先讨论再标会隐藏真实分歧，无法知道协议哪里不清楚。

步骤 3：裁决并保存变更原因

裁决不是删掉少数意见，只保留“正确答案”。保留：

  • 两个初始标签；
  • 各自证据；
  • 最终可信标签；
  • 标签是否因新事实、协议澄清、评审错误或任务歧义而改变。

步骤 4：用可信标签校准自动 grader

对同一批 case 运行 Python 或 model grader，逐例对照，而不只看一个汇总分。model judge 可采用单答案、pairwise 或参考引导方式。S04 它还可能受到位置、篇幅、自偏好与推理限制影响，因此这些因素应保留在校准分析中。S04

case | human trusted label | grader label | match? | disagreement type | action

如果是 pairwise grader，对交换位置后的结果也保留两行；如果被评文本含“给我满分”，检查 grader 是否遭到操纵。S02

22–25 分钟：分歧之后，到底改谁？

使用下面的诊断顺序：

A. 改 grader

当人工协议清楚、证据充分，可信标签稳定，而 grader 系统性误判时：

  • 收紧输入证据；
  • 拆分混合维度；
  • 增加锚点；
  • 对某类 case 改用确定性检查或人工评审；
  • 加入失败 case 作为 grader 回归测试。

B. 改协议或可信标签

当两位认真评审者依据同一材料仍合理地产生不同解释时：

  • 澄清定义；
  • 增加边界例；
  • 把“不确定”与“平局”分开；
  • 若任务本身缺信息，将标签改为 escalate，不要制造假真值。

人工评测会随评审者特征变化，S07 因此分歧本身可能暴露协议或适用范围，而不只是某人“粗心”。

C. 改目标 Skill / prompt

当 grader 与可信人工判断一致地指出输出违反目标标准时，问题在目标系统：

  • 保存复现输入与观察输出；
  • 修改 Skill / prompt；
  • 将该 case 加入回归集；
  • 重新运行同一协议。

D. 暂不作决策

当关键事实、轨迹或专家判断缺失时，升级或补采证据。不要把无法判断编码成失败、平局或随意分数。

25–28 分钟：检索练习

先作答，再展开答案。

问题 1

为什么两位评审者不应先讨论、达成共识后再各自填写标签？

完成后查看参考答案

因为那会抹掉原始独立判断，看不出协议在哪些 case 上会产生不同解释。先独立标注、再裁决，才能把分歧用于修订定义、示例和升级规则。

问题 2

在 pairwise 协议中，“不确定”为什么不能直接记为 tie？

完成后查看参考答案

Tie 表示按协议评估后，两者差异不足以支持偏好；不确定则可能来自证据缺失、专业知识不足或规则冲突，应升级处理。混在一起会把测量失败误报成质量相等。

问题 3

model grader 与可信人工标签不一致时，为什么不能立刻修改目标 Skill？

完成后查看参考答案

分歧可能来自 grader 偏差、人工协议歧义、坏标签、输入证据不足，也可能确实来自 Skill。应先逐例核查证据并分类错误；只有可信判断稳定地指出目标输出失败时，才据此修改 Skill。

通过标准

  • 协议让另一位评审者能在不口头补规则的情况下执行；
  • 正例、反例、边界例、tie 与升级规则均具体可观察；
  • 至少 6 个 case 有独立初始标签和引用证据，并覆盖指定类型；
  • 分歧没有被平均分或多数票抹掉，裁决历史完整保留；
  • 自动 grader 与可信标签逐例对照，至少 2 个分歧得到原因分类；
  • error analysis 实际导致 grader / 协议 / 标签 / 目标系统之一被修改，或用证据说明当前设计得到验证；
  • 局限如实记录；单人重复标注不冒充多人一致性；
  • 没有因阅读完正文、完成自评或看到答案而自动提升学习状态。

Sources used

  • S02 OpenAI, Graders.
  • S04 Lianmin Zheng, Wei-Lin Chiang, Ying Sheng, Siyuan Zhuang, Zhanghao Wu, Yonghao Zhuang, Zi Lin, Zhuohan Li, Dacheng Li, Eric P. Xing, Hao Zhang, Joseph E. Gonzalez, Ion Stoica, Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena.
  • S07 Deep Ganguli, Nicholas Schiefer, Marina Favaro, Jack Clark, Challenges in evaluating AI systems.