谁来判分？怎么评分？

目前主流的判分方法有三类：

- 程序化评估（Code-based Evaluators）

- LLM-as-a-Judge

- 人工评估（Human Evaluation）

Code-based Evaluators

Code-based Evaluators 适合有硬规则、明确状态或可计算答案的任务。

这类评估速度快、成本低、结果稳定，很适合放进 CI/CD，作为每次模型、Prompt、工具和工作流变更后的回归测试。

对于具体的任务执行，评估应该关心最终结果或系统状态，而不只看模型说了什么。对于存在明确答案的任务，则可以直接检查模型输出与预期结果是否一致。

在研发过程中，我们往往需要快速确定优化方向，例如选择模型、修改 Prompt 或调整超参数。这个过程需要运行大量实验，如果每次都依靠人工标注和评分，评估周期、人工成本和主观差异都会成为干扰项，实验也很难稳定复现。

这时便需要 Code-based Evaluators：通过自动化、标准化、可复现和可量化的方式完成判分。

其核心涉及两个部分：数据集和评估指标。数据集已经在上一篇介绍，本篇略过。

如何选择指标

指标选择本质上是将业务目标转化为可量化问题的建模过程。不同任务类型需要匹配不同的评估指标。

在分类任务中，Accuracy 是常见的基础指标。但在医疗诊断等类别不平衡的场景中，仅看 Accuracy 很容易产生误导。此时可能需要额外关注 Recall，并根据实际问题选择 F1-Score、MCC（Matthews Correlation Coefficient）或 ROC 曲线等指标。

如果任务存在明确答案，例如数学题的最终数值、分类标签或固定标识符，评估相对容易。Exact Match 可以直接检查输出是否一致；`pass@k` 则衡量模型在 k 次采样中至少成功一次的概率。

相比之下，LLM 生成回答的评估更有挑战。

Exact Match 适用于答案表达受严格约束的场景，但对开放域问答存在明显局限。BLEU、ROUGE 等 n-gram 指标关注词汇重叠，难以反映完整的语义关系；BERTScore 等方法通过 Embedding 计算语义相似度，但增加了新的模型变量，而且相似度通常是相对数值，使用时仍需校准和对照。

这类开放文本任务通常需要引入 LLM-as-a-Judge。

随着模型能力增强，评估目标也逐渐从准确性扩展到安全性、可信度、稳定性和成本等更多维度。

不要让指标替代任务目标

BLEU、ROUGE 和 Embedding Similarity 都可以由代码自动计算，但"能够自动计算"不代表它能够有效反映业务质量。

语义相似度很高的回答，仍然可能遗漏关键限制；词汇重叠较低的回答，也可能完全正确。指标只是业务目标的测量代理。代理一旦与真实目标脱节，优化指标反而可能让系统偏离真正需要解决的问题。

LLM-as-a-Judge

很多任务没有唯一答案。

比如判断一段回答是否完整、是否忠于参考资料、是否遗漏风险，或者一份分析是否真正回应了用户的问题。这些标准可以用语言说明，却很难写成一组穷举规则。

这时可以使用 LLM-as-a-Judge。常见方式有：

  • 分类：判断通过或不通过，或者属于哪一种错误。

  • 打分：按照明确的 Rubric 给出 1～5 分。

  • 成对比较：比较版本 A 和版本 B，判断哪一个更符合标准。

  • （and more…）

其中，成对比较通常比直接给出绝对分数更加稳定。人类面对两个具体答案时，也往往更容易判断哪个更好，而不是精确解释"为什么这是 3 分而不是 4 分"。

LLM Judge 的价值在于规模。它可以对大量开放文本进行初筛和重复评估，也能输出错误类别和判分理由，帮助团队定位问题。

但 Judge 给出的分数仍然是一次模型输出。一种可扩展的判断近似，也需要被评估和校准。

LLM Judge 需要注意什么

一次只判断一个清晰维度

“请综合评价这段回答的质量"很难得到稳定结果。将其拆成事实正确性、完整性、相关性和安全性，并为每一项写出可观察的得分点，结果会更容易解释。

让 Rubric 可执行

“内容专业"“体验良好"都过于抽象。更有效的 Rubric 会写明必须包含哪些事实、哪些错误属于严重失败，以及不同分值分别对应什么表现。

这也是上一篇为什么建议把 Golden Answer 拆成 Statements 和 Rubric：Judge 核对一组明确的判定点，比比较两段长文本是否"相似"更加稳定。

要求证据和理由

仅保留一个分数，很难发现 Judge 在哪里误判。让 Judge 引用被评答案中的证据，并输出结构化理由，便于人工抽检和后续分析。

处理已知偏差

Judge 可能偏好更长的答案、更熟悉的格式、靠前出现的选项，以及与自身表达风格接近的内容。

进行成对比较时，可以随机交换答案顺序，减少位置偏差；关键 Case 可以重复执行，通过 Self-consistency 检查结果是否一致；必要时也可以汇总多个 Judge 的结果。

对于"部分正确、局部严重错误"的内容，Judge 仍然可能漏判。特定专业领域中的知识边界和幻觉问题，也需要人工检查。

固定并记录版本

Judge 模型、Prompt、Temperature 和 Rubric 都属于评估器的一部分。任意一项发生变化，评测尺度都可能漂移。实验记录中应保留完整版本和最终分数。

用人工样本校准

在正式大规模运行前，先准备一小组由领域专家判定的样本，检查 Judge 与人工结论的一致性。高风险或专业领域还需要持续抽检。

人工评估

人工评估成本最高，速度也最慢，但它承担着另外两类方法无法独立完成的工作。

人类对复杂语义的理解能力和价值判断力，让 Human Evaluation 始终占据不可替代的地位，同时也意味着更高的成本。

系统化的 Human Evaluation，根据评估资源的完备程度，可以分成几种形式：

  • 当缺乏现成数据集时，需要提供完整的任务说明和结构化评分指南。例如评估对话系统时，需要明确定义"连贯性"“相关性"“安全性"等维度，并要求标注员提供评分理由。

  • 已有数据集时，将模型输入、输出结果和评分指南一并提供给标注员。

  • 既有数据集也有自动评分结果时，由人工标注员通过 Error Annotation 对结果进行审查。

人工评估不能简化成"找几个人凭感觉试用”。系统化的人评至少需要提供任务说明、模型输入与输出、评分维度、分值定义和示例；必要时还要让标注员记录错误类别、严重程度和判分理由。

相比笼统打分，Error Annotation 往往更有用。让领域专家指出错误发生在哪里、属于哪一类、严重程度如何，得到的信息可以直接进入错误分析和评测集迭代。

人工评估需要注意什么

选择真正具备判断能力的人

语言是否流畅可以交给普通标注员，专业结论是否可靠则需要领域专家。专家时间稀缺，应该集中用于确实需要专业判断的部分。

降低标注的认知负担

上一期提到一条原则：能做判断题就不做选择题，能做选择题就不做问答题。把复杂任务拆成明确判断点，可以降低成本，也能减少标注员之间的理解差异。

先做小规模试标

正式扩大标注前，先用少量样本检查说明是否清晰、边界 Case 是否存在分歧。如果不同标注员长期无法达成一致，问题可能出在 Rubric 本身。

记录分歧

分歧不只是噪声。它可能说明任务定义存在歧义，或者业务内部尚未形成统一标准。需要进一步判断分歧来自知识不足、说明不清，还是价值判断不同。

评估器也需要控制变量

不论采用哪一种判分方法，评估结果都会受到实验设置影响。

Prompt 会影响结果。一个合理的 Prompt 应包括清晰的任务描述、完成任务所需的上下文，以及具体、无歧义的问题。

重复实验减少随机误差。针对同一任务设计多种 Prompt，不同温度，不同顺序等。

Structured Output 也是实验变量。结构化输出有助于提高评测的可控性，减少无关内容，但也可能改变模型的输出分布。实际部署使用 JSON、Schema 或 Tool Calling 时，评估最好在相同接口条件下进行。

小结

Code-based Evaluators 适合可以通过硬规则、明确答案或系统状态直接验证的任务。

LLM-as-a-Judge 适合需要开放语义判断、又希望规模化运行的任务，但它自身存在随机性、偏差和尺度漂移。

人工评估负责定义标准、校准自动评估结果，并处理专业性强、风险较高或存在争议的样本。