适用场景：Agent 系统输出的内容质量评测（意图识别、计划生成等）
核心原则：能代码断的不上裁判，裁判只做 Binary，不校准不上线
核心原则
- 能代码断言的不上裁判。代码快、准、零成本重复。裁判是兜底，不是默认选项。
- 裁判只做 Binary（YES/NO），不打分。1-5 分两个人判都不一致，假精度没有意义。
- 裁判不校准不上线。TPR 和 TNR 不到 80%，不直接用。
一、断言作用点
1.1 链路断言点
断言不只打在最终输出上，链路每个跳转节点都是断言点。只断最终输出会漏掉中间节点的错误。
| 断言点 | 断什么 | 断言类型 |
|---|
| 意图识别 | 是否命中正确意图 | 代码断言 |
| 路由分发 | 是否路由到正确 Agent | 代码断言 |
| 工具调用 | 是否调用了正确的工具/能力 | 代码 or LLM 裁判 |
| 最终输出 | 内容是否正确、完整、安全 | 代码 + LLM 裁判 + 人工 |
1.2 错误检测 vs 遗漏检测
| 类型 | 定义 | 断言方式 |
|---|
| 错误检测 | 输出里有矛盾/错误（如"休息训练"） | LLM 裁判可主动发现 |
| 遗漏检测 | 输出里缺了该有的内容（如膝盖不好没给风险提示） | 需要must-have checklist作为裁判锚点 |
must-have checklist 按场景类型维护：
| 触发条件（从用户输入提取） | must-have 项 |
|---|
| 用户提到伤病/身体限制 | 必须包含风险提示 + 动作替代 |
| 用户指定了特定器械 | 不能出现该器械以外的替代 |
| 用户有明确目标（减脂/增肌） | 训练配比必须与目标一致 |
触发条件用代码匹配，内容是否覆盖由 LLM 裁判判断。
二、落地流程
阶段 1：从真实 trace 反推断言维度
| 输入 | 20-30 条 Agent 真实输出（覆盖正常 + 异常） |
|---|
| 操作 | 人工逐条看，记录问题，按类型分类 |
| 输出 | 问题分类表（每类问题 + 频次 + 具体 case） |
| 完成标准 | 连续 5 条没有新类型出现 |
不要从通用指标开始（“测一下 helpfulness”）。从真实 bad case 反推。
阶段 2：设计 Binary 断言 + must-have checklist
| 输入 | 阶段 1 的问题分类表 |
|---|
| 操作 | 每类问题转化为一条 Binary 断言（YES/NO），梳理场景级 must-have checklist |
| 输出 | 断言维度表 + checklist |
| 完成标准 | 每条断言有明确判断标准，无"合不合理"式模糊表述 |
断言维度表模板：
| 维度ID | 维度名称 | Binary 断言 | 断言类型 | 触发条件 |
|---|
| J-01 | 内容无矛盾 | 是否存在语义矛盾描述 | LLM 裁判 | 所有输出 |
| J-02 | 目标一致性 | 训练配比是否与用户目标一致 | LLM 裁判 | 用户有明确目标时 |
| J-03 | 安全约束 | 是否规避风险动作并给出替代 | LLM 裁判 | 用户有伤病/限制时 |
阶段 3：标注金标准
| 输入 | 10-20 条已知质量的输出（坏 case 占比 ≥ 20%） |
|---|
| 操作 | 人工对每条每个维度标注 PASS/FAIL |
| 输出 | 金标准数据集（JSONL） |
| 完成标准 | 最好两人独立标，不一致的讨论对齐 |
{"case_id": "G-001", "input": "用户输入", "output": "Agent输出", "labels": {"J-01": "PASS", "J-02": "FAIL"}, "notes": "目标减脂但配比偏增肌"}
阶段 4：调试裁判 prompt + 校准
| 输入 | 金标准数据集 + 裁判 prompt 初稿 |
|---|
| 操作 | 裁判跑金标准，逐维度算 TPR / TNR |
| 输出 | 校准报告（每维度 TPR/TNR + 误判分析） |
| 完成标准 | 每维度 TPR ≥ 80% 且 TNR ≥ 80% |
TPR = 裁判正确判 FAIL 的坏 case 数 / 人标的全部坏 case 数 TNR = 裁判正确判 PASS 的好 case 数 / 人标的全部好 case 数
未达标调整：TPR 低 → prompt 加漏判的坏 case 示例；TNR 低 → 检查 rubric 是否过严，加误判的好 case 反例。
阶段 5：部署 + 日常运行
| 输入 | 校准通过的裁判 prompt + 代码断言集 |
|---|
| 操作 | 代码过滤 → 裁判判剩余 → 人工看 flag 项 |
| 输出 | 评测报告（通过率 + flag 列表 + 人工复核结果） |
| 节奏 | 每轮迭代跑一次；每 20-30 条随机抽检（不只看 flag，也抽 PASS） |
新发现的 bad case：能代码化 → 加代码断言；不能 → 加裁判维度。
三、裁判 prompt 模板
你是一个 AI 输出质量裁判。判断以下 Agent 输出是否满足指定维度。 ## 待评测内容 - 用户输入：{user_input} - Agent 输出：{agent_output} ## 评测维度 {dimension_name}：{binary_assertion} ## 判断规则 - 只回答 YES 或 NO - YES = 满足，NO = 不满足 - 先给判断结果，再给一句话理由 ## 示例 [从金标准提取 2-3 个，YES/NO 各至少一个] ## 输出格式 判断：YES/NO 理由：[一句话]
每个维度单独调用一次，不要多维度塞一个 prompt。
四、常见坑速查
| 坑 | 规避 |
|---|
| 从通用指标开始 | 从真实 bad case 反推维度 |
| 打分制（1-5 分） | Binary（YES/NO） |
| 只看 agreement 率 | 拆开看 TPR 和 TNR |
| 裁判和被测同模型 | 必须用不同模型 |
| 不校准就上线 | 先过金标准，TPR/TNR ≥ 80% |
| 只断最终输出 | 链路每个节点都断 |
| 只断错误不断遗漏 | must-have checklist 作为锚点 |
| Rubric 模糊 | 可操作化：“有没有 X” |
五、重新校准触发条件
| 触发条件 | 原因 |
|---|
| Agent prompt / 模型版本更新 | 输出分布变化，校准基线失效 |
| 新增场景类型 | 原有维度可能不覆盖 |
| 裁判连续 3 条与人工不一致 | 裁判已偏移 |
| 金标准新增 ≥ 5 条 | TPR/TNR 需重算 |
附录：参考来源
| 来源 | 关键观点 |
|---|
| Anthropic | 三种打分器递进：代码 → 模型 → 人类 |
| Hamel Husain | Binary 优于打分；LLM 不能做初始错误分析 |
| OpenAI | Binary labels + TPR/TNR 校验 |