模型撰写，裁判测量：LLM裁判剖析

本文探讨了如何构建一个独立的LLM裁判来评估AI助手在解释钻石时的输出质量。作者Sam Wen指出，AI助手可能生成流畅但误导性的陈述，例如“在这样的净度级别下，肉眼什么也看不到”——这句话看似合理，但实际上净度级别SI1是在10倍放大镜下评定的，并不直接决定肉眼可见性。这种问题无法通过简单的关键词过滤解决，因为它是句子与证据之间关系的错误。

为了解决这个问题，团队设计了三个层次的防护机制。第一层是预防，通过代码在管道中阻止模型提出无法从证据中回答的问题。例如，当助手生成关于钻石的后续问题时，必须指明从哪条证据路径获取答案，若没有可用路径，问题会被代码直接拒绝。第二层是捕捉，使用确定性验证器检查脚本中是否出现禁止词汇，如“惊人”、“必须拥有”等。这些规则基于领域专家的风格指南，但需要谨慎处理上下文相关词汇——例如“flawless”在钻石领域是专业等级而非空洞赞美，因此交由裁判判断而非简单过滤。第三层是裁判，由另一个LLM负责检查那些看似合理但缺乏支持的陈述。

裁判的设计非常独特。它不返回简单的1-10分，而是提供详细的裁决：逐句分类，区分关于此石头的声明和一般性知识，并检查是否有证据支持。它还能处理归属错误——例如将实验室的评级归功于商家。裁判必须列出所有声明及其分类，形成可审计的记录。此外，裁判还测量语气和格式，但保持正交信号互不干扰，温暖语气不能掩盖不支持的声明。

为了保持裁判本身的诚实，团队采用了多种方法。裁判与作者共享同一套规则文档，确保标准一致。裁判从不评价自己的输出，而是使用不同的模型（最初用GPT-5.5，后改用Claude Opus 4.8）。裁判仅在开发环境中使用，不会增加生产环境的延迟或成本。团队还通过校准循环处理裁判的错误——例如，针对“flaw”一词的过滤规则曾错误地拦截了“not a flaw”这一诚实表述，于是规则被修正为仅禁止声称无瑕疵的绝对化表达。

最后，作者分享了引入裁判后结束的三个争论：选择哪个模型（Claude Sonnet 5明显优于Haiku 4.5，前者平均0.8个违规而后者约10个）、提示词的长度（更长不一定更好）、以及如何测量质量（裁判提供客观基准）。裁判不仅解决了质量问题，更让团队能够基于数据而不是个人偏好做出决策。