构建最小可行评估

本视频中的演示录制于 2026 年 8 月。它运行在 Claude Haiku 4.5、Claude Sonnet 5 和 Claude Opus 5 上。在更新的模型上结果会有所不同。每节课的演示都是一次独立的评估运行，因此其分数和成本不会与其他课程中的相匹配。

评估是模型要参加的测试。 它有三个部分：真实的输入、每个输入的期望答案，以及对每个模型返回结果进行评分的方法。每个模型都在每个输入上运行您的提示。一个输入连同其期望答案构成一个案例（case），而对每个案例评分则得到一个分数。

Meridian 的提取提示从每份月度项目报告中提取三个字段：项目 ID 和进度状态（两者都是简短的值），以及最大风险（一个句子）。

构建评估就像进行一场考试，您是老师，而模型是学生。

LLM 评判者是第二个检查答案并判断其是否正确的模型。任何对答案进行评分的事物都称为评分者（grader），无论它是代码、模型还是人。您将分六步构建 Meridian 的评估：

1. 为每个字段选择评分者
2. 设计案例集
3. 写下期望答案
4. 为最大风险字段设置 LLM 评判者
5. 运行模型并对其答案评分
6. 在信任评判者之前先对样本进行人工评分

为每个字段选择评分者

给答案评分有三种方式。规则是选择最快且同时可靠、可扩展的方法。

1. 基于代码的评分。 您的代码检查某个答案是否与期望答案完全匹配，或是否包含某个关键短语。这是最快、最可靠的方式，并且能扩展到任意数量的案例。
2. LLM 评判者。 当两个不同的句子都可能是正确的时候，评判者适合这种情形。它同样快速、灵活且可扩展。
3. 人工评分。 人工阅读每个答案，这能提供最好的质量，但速度慢、成本高，因此排在最后。对于专业化、高风险的工作，以及取决于判断力的答案，人仍然是合适的评分者。

对每一个能够精确检查的字段使用代码，只把剩下的交给评判者。 以下是这三个字段在 Meridian 某个案例（报告 r032）上的具体做法。

不过，当一份报告未指出任何风险时，期望的 top_risk 答案就是 null，即 JSON 的空值。代码可以用精确匹配来检查这一点。

设计案例集

四条规则塑造了整个案例集。它们建立在文档中的评估设计原则之上。

1. 让案例具有任务针对性。 用您自己的真实报告来构建案例，因为样例数据只能展示模型在样例上的表现。
2. 自动化评分。 您会一遍又一遍地运行这个案例集，所以日常评分必须能在没有人的情况下进行。
3. 重量不重精。 在相同的工作量下，许多自动评分的案例比少数精心手工评分的案例能告诉您更多信息。
4. 对边缘案例进行分层。 边缘案例是生产环境仍会发送的不常见输入，例如一份扫描版报告。按照每种边缘案例在生产中所占的比例，给每种类型大致相应比例的案例，比如如果扫描报告占到达报告的 5%，就让它们在案例集中也占大约 5%。

最重要的是，案例组合应该看起来像生产环境发给您的东西。 团队往往把"大量"理解为数百个案例，但一套 20 到 50 个简单案例的集合就是很好的起点。

Meridian 确定了 50 个案例。其中 30 个是典型报告，10 个涉及多个项目，10 个是缺失风险案例，也就是没有风险部分的报告。这两种不常见的类型在 Meridian 收到的报告中出现得足够频繁，因此它希望都有所覆盖。

写下期望答案

由人写下期望答案的案例集称为带标签集（labeled set）。在任何模型运行之前，自己从报告中写下每个期望答案。 代码评分者会将模型的答案与这些答案进行比较。

Meridian 将其带标签集保存在一个文件 golden.json 中，每个案例对应一条记录。一条记录包含该案例的 id、其 category，以及每个字段的期望答案。category 的值是 typical、multi_project 或 missing_risk。

为最大风险字段设置 LLM 评判者

top_risk 字段存放一个句子。代码无法判断两个不同的句子是否指的是同一个风险，因此这个字段要交给评判者。这就是那道论述题，就像那位助教一样，评判者也需要一份评分指南。

这份指南就是评分标准（rubric），一套书面规则，规定什么算正确、什么算不正确。它应当详细且清晰。

评判者的提示中包含报告、答案和评分标准。每一项都放在自己的 XML 标签中，这样评判者就不太可能把它们混淆。您的期望答案不在提示中，因为评判者要根据报告本身来判断。这样，答案不会仅仅因为风险的措辞与您的不同就失分。不过您仍要保留您的期望答案，因为在您手动给样本评分时，那就是您对正确答案的记录。

评判者对某个答案的判定称为其裁定（verdict）。只有当裁定以您的代码能够统计的形式返回时，它才有用。 结构化输出正好提供了这一点。您随请求一起发送一个 JSON schema，响应必须与其匹配。JSON schema 描述了 JSON 可以包含哪些字段，以及每个字段可以填入什么内容。

Meridian 的 schema 有两个字段，explanation 和 verdict。裁定必须是 correct、incorrect 或 unknown。explanation 是对评判者为何做出该判断的简短说明，所以当您想了解某个答案哪里出了问题时，读的就是这个字段。

最重要的值是 unknown。它给评判者提供了一条退路，一个说"我无法判断"的选项。如果没有这个选项，每当评判者拿不准时，就不得不在另外两个选项之间做猜测。

运行模型并对其答案评分

在评分开始之前，您需要先有答案。用您要测试的每个模型，对每个案例运行提示，并将每个答案保存到文件中。Meridian 用 Claude Haiku 4.5、Claude Sonnet 5 和 Claude Opus 5，在全部 50 个案例上运行了其提取提示。

先在代码也能评分的案例上测试一次评判者，看这两个评分者是否一致。 Meridian 的第一次评判者运行只取了 10 个缺失风险案例，三个模型合计产生了 30 个答案。它们的期望答案是 null，所以代码也能对它们评分。把每个裁定和对应答案保存在一起，以便您之后手动核查评判者。

评判者的第一次运行，针对代码也能评分的 10 个缺失风险案例。

对于没有风险部分的报告，Meridian 现在为每个模型都有了一个数字，而以前只有各种看法。

Haiku 4.5 的五个不正确答案都是同一种错误，案例 r045 就展示了一个例子。

评判者的解释指出了该答案所犯错误的类型。该错误来自提取提示，因为提取提示从未说明当报告未指出风险时该怎么做。

在信任评判者之前先对样本进行人工评分

评判者在全部 30 个答案上都与代码一致，但这些答案本来代码也能检查。评判者真正的工作是评判自由文本，而代码对此无能为力。在把这项工作交给它之前，先测试它是否可靠。 有两种做法会有所帮助。

1. 亲自给样本评分。 手动对一批已保存的答案进行评分，并将您的评分与评判者的裁定进行比较，因为评判者的判断应当与人类专家高度一致。在您和评判者意见不一致的地方，把评分标准写得更清楚，然后再次运行。
2. 使用没有写出这些答案的评判者。 通常最好用与生成输出不同的模型来评分。

要点总结

1. 在精确检查能够奏效时用代码评分，在两个不同句子都可能正确时用评判者评分，在取决于判断力时用人来评分。
2. 在任何模型运行之前先写下期望答案，并构建一套看起来像生产环境的案例集。
3. 给评判者一份评分标准、一个其裁定必须匹配的 schema，以及说 unknown 的选项。
4. 在信任评判者之前，先对其工作的一个样本进行人工评分。