LLM-as-a-Judge：自由格式提示、量表评分，还是带弃权的类型化评审

LLM-as-a-Judge 是一种评测模式：模型读取任务、被测系统的输出，有时还有参考答案，然后给出评分。命名这一模式的研究（Zheng 等，2023，《Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena》）描述了三种形式——成对比较、单答案评分和参考引导评分。无论哪种形式，评审衡量的都是“另一个模型理解下的、与你所写标准的一致程度”。除非你的标准和人工标签与真实性、用户满意度或业务结果相关联，否则它并不衡量这些。因此评审本身必须像任何分类器一样被评估。本页讨论的是评审其他 AI 输出——聊天回答、摘要、RAG 回复、智能体步骤。要用标签评估 JevModel 工作流本身，请看 evaluation。

三种方案的主要区别在于输出是否稳定、不确定性是否可见。自由提示上手快；量表让不同运行间的分数可比；类型化评审再加上固定 schema 和可设阈值的概率。下表比较的是工程取舍，不是评审模型排名。

Zheng 等（2023）报告了三种值得在设计时规避的偏差。位置偏差：成对比较时，两个回答交换位置后结论可能翻转，所以每对都按两种顺序各跑一次，只有两次一致才算胜出，否则记为平局。冗长偏差：即使多出的篇幅毫无价值，评审也可能偏好更长的回答，所以标准要奖励“满足要求”而非“覆盖面”，并在夹具里加入简短但正确的回答。自我增强偏差：评审可能偏爱与自身相似的输出，所以不要让被测模型给自己打分，并隐藏每个回答出自哪个系统。另外两个习惯也有帮助：每个问题只评一个标准，不要打一个笼统的“质量”分；事实类任务给评审提供参考答案，因为评审可能被一个自信但错误的回答带偏，哪怕它自己本能做对。

抽取真实输出（包括难例），让两个人按同一书面标准盲标。如果两人经常不一致，先修改标准，再怪评审——人与人都无法达成一致时，评审没有稳定的目标可对齐。然后在相同样本上运行评审，按类别报告一致率，而不仅是总体：当大多数输出本来就没问题时，一个“全部通过”的评审看起来也很准。评审与人工的混淆表，加上团队惯用的机会校正统计量（如 Cohen’s kappa），能显示它在哪里失败。接着检查概率区间：评审给出高概率的样本中，人工也这样判的有多少？据此选出自动接受区间和复核区间。把样本冻结为回归集，每当评审提示、标准或模型改变时重新运行。JevModel 的 Console → Batch 可以对上传的多行数据运行同一个固定评审问题，并导出答案供你做这类对齐。

把任务、可选的参考答案和一个候选输出放进 state，然后每个标准问一个问题。在 JevModel 中，Noul 是返回 0 到 1 概率的是/否问题，适合“每条论断是否都有所给上下文支持？”这类二元检查。Score 接收 2–10 条有序等级描述，并返回该量表上的一个值，可能落在等级之间；它适合有用性这类分级标准，但不是 0–1 概率，所以要为它单独设定区间。一次请求可带 1–8 个具名问题，序列化后的 state 与完整请求各自不得超过 8,000 字符，所以长回答或检索段落需要摘录。做成对比较时，把两个候选按相反顺序各发一次请求，只接受结果一致的情况。接近中间的 Noul 概率，或落在通过与不通过等级之间的 Score，就是你的弃权信号：把这些样本交给人，而不是计入统计。调用 POST /api/v1/systemone，经 OpenRouter 使用固定模型 typesafe/jev-1.13。

{
  "state": {
    "task": "Answer the customer using only the help-center context.",
    "context": "Refunds are available within 30 days of purchase for annual plans.",
    "candidate_answer": "You can get a refund within 30 days if you are on an annual plan."
  },
  "questions": {
    "grounded": {
      "type": "noul",
      "instructions": "Is every factual claim in candidate_answer supported by the context?",
      "criteria": {
        "true": "All claims appear in or follow directly from the context.",
        "false": "At least one claim is missing from or contradicts the context."
      }
    },
    "helpfulness": {
      "type": "score",
      "instructions": "How well does candidate_answer resolve the task? Do not reward length.",
      "criteria": [
        "Does not address the task or is misleading.",
        "Addresses part of the task or needs a follow-up.",
        "Fully resolves the task in the needed detail."
      ]
    }
  }
}

当代码就能检查答案时，就不要用评审：JSON 是否合法、是否与期望标签完全一致、单元测试是否通过、SQL 是否返回正确的行。确定性检查更便宜，也不会漂移。不要把评审当作法律、医疗、金融或安全决策的唯一签核；用它来给人工复核排优先级。不要信任从未与人工标签比较过的评审，也不要让模型给自己的输出打分。对数学、代码正确性和多步推理要谨慎，评审可能被它所评的答案误导；优先使用参考答案或基于执行的测试。具体到 JevModel，它是面向文本和 JSON 的决策模型：不运行代码、不浏览网页、不读图片，所以它评判的是 state 里写了什么，而不是输出被执行后发生了什么。它不开源；已验证免费账号每个 UTC 日 5 次成功运行——够你试一试评审，但不够每天给大型评测集打分。