LLM 裁判置信度验证法

前置分流：对每个失败模式先问一个问题——它是客观规则可判的（"输出是否包含用户 ID"），还是需要主观判断的（"语气是否符合人设"）？客观的用 code-based evaluator（快、便宜、确定，如 JSON 合法性/关键词/可执行性检查）；只有主观的才建 LLM-as-judge。

LLM judge 对齐流程（输出是针对特定错误的 binary pass/fail 指标）：

1. 建立 ground truth：由 principal domain expert 对每条交互给出 binary pass/fail + 详细批注。拒绝 1-5 Likert 量表——"3 和 4 的区别"主观且不一致，是个陷阱；二元判断逼出清晰度，细微差别不会丢失，它进了批注（解释为什么这样判）。批注是构建高保真 judge 的秘密原料。评估系统的上限就是 ground truth 的质量。
2. 切分数据防过拟合：不要用全部数据既造 judge 又测 judge。切三份——train 10%-20%（清晰样例+专家批注，放进 judge prompt 做 few-shot）；dev 40%-45%（迭代打磨 judge prompt）；test 40%-45%（开发期间不碰，最终无偏测量）。打磨 judge 是"评估你的评估器"的元评估，也是你澄清自身质量标准的过程（criteria drift 研究）。
3. 用 TPR/TNR 而非单一 accuracy 衡量 judge：想象系统 99% 成功——一个永远说 pass 的 judge accuracy 高达 99%，却一个失败都抓不到（类不平衡陷阱）。TPR=该 pass 的样本中 judge 判对的比例；TNR=该 fail 的样本中 judge 判对的比例。两者合看才知道 judge 会怎样犯错。可接受的取舍取决于产品：医疗建议类，漏放有害内容（假阴性）代价远高；创意写作类，误杀好回答（假阳性）可能更糟（扼杀创造力）。
4. 统计校正：已知 judge 的 TPR/TNR 后，可对其生产读数做修正，估计系统真实失败率（如 judge 在 1000 条新样本上报 95% 通过率，但已知它有 10% 概率把 fail 误标为 pass，可据此调整）。

为什么值得：当仪表盘显示关键功能 5% 失败率时，干系人必须相信这个数字反映现实——信任只能来自这种以人工标注为锚的验证，不是 prompt 技巧。