升级模型之前先迭代提示

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

较低的评估分数说明模型出错的案例太多，但并不能说明该归咎于模型还是您的提示。

先检查提示，因为更大的模型会提高切换之后您发送的每一个请求的价格。修改提示只需几分钟，而且您可以立即测试这个改动。

Meridian 是一家虚构的工程咨询公司，它有一个提示，用于从每份月度项目报告中提取三个字段：项目 ID、进度状态和首要风险。其评估是一个包含 50 个案例的测试，每个案例都是一份报告配上其预期答案。

Claude Sonnet 5 和 Claude Opus 5 全部 50 个都答对了。Claude Haiku 4.5 在三者中成本最低，但它只答对了 84%，未达到准确率下限，而 Meridian 要求模型在使用前必须达到 90% 的准确率下限。

在 Meridian 为更大的模型多花钱之前，它执行了五个步骤：

1. 阅读失败的案例，找出它们的共同点。
2. 为不受支持的答案选择修复方案。
3. 把改动写入提示中。
4. 在全部三个模型上重新运行全部 50 个案例。
5. 检查每一列，然后再决定是否升级。

阅读失败的案例，找出它们的共同点

按报告的种类和出错的字段对失败的案例进行分类。 分数只会计算失败次数，却无法解释原因。阅读失败的内容能让您看清出了什么问题以及为什么出问题，而这正是您判断该归咎于模型还是提示的方式。

Meridian 的 50 个案例中，30 个是典型报告，10 个涵盖多个项目，还有 10 个是缺失风险的案例，即报告中没有风险部分。下表展示了使用旧提示时 Haiku 4.5 的表现——这是 Meridian 最初使用的提示。

使用旧提示的 Haiku 4.5 在 50 个案例中失败了 8 个。

八个失败案例中有五个是缺失风险的案例，全部出在 top_risk 上。每一个本应返回 null，但模型每次都编写了一句指出某个风险的句子。案例 r045 就是其中之一。

这份许可证只得到了一句例行提示，报告本身也说明预计不会有麻烦，但模型却把它选为首要风险。

旧提示中 top_risk 那一行以“or null”（或为 null）结尾，这允许返回 null，但从未告诉模型什么时候该这样做。当失败案例集中在某一种报告和某一个字段上时，它们通常有共同的原因，而这里正是提示遗漏了某些内容。

为不受支持的答案选择修复方案

从五种让不受支持的答案变少的标准方法中选择您的修复方案。 不受支持的答案，也就是文档内容并不支持的答案，也被称为幻觉。以下前三种方法是能让幻觉变少的基本步骤。

1. 允许它说“我不知道”。 告诉模型，当文档中没有答案时应返回什么，对 Meridian 来说这就是 null。
2. 先引用后作答。 让模型先提取出支持其答案的那句话，然后根据这句话再作答。
3. 回引文档。 在模型作答之后，让它为每一个论述找到一句支持它的引文，并收回任何找不到支持的论述。之后人工就能逐一核查剩下的每一项论述。
4. 增加一道验证流程。 发送第二个请求，其任务是检查第一个请求给出的答案。
5. 限制外部知识。 告诉模型只根据文档本身作答，而不要带入它在训练中学到的内容。

Meridian 采用了前两种方法，因为第一种正好填补了第一步中发现的缺口。第二种方法让每个答案都能对应报告中的一句话。两者都只需要在 Meridian 已有的提示中加上一两行内容。

把改动写入提示中

在提示中说明什么时候 null 才是正确答案，并要求在给出答案之前先给出引文。 下面的框中是新的提示，也就是 Meridian 做出这两处改动后的提示。找出完成每项任务的那一行，并附有说明该处改动内容的注释。

再来看案例 r045。现在模型必须指出一句表明存在风险的话，而报告本身的话并没有这样的句子：“团队预计续期不会出现任何问题。”当报告中没有这样的句子时，新提示说明了应返回什么：<source>none</source>，然后是 null。

您的代码也多了一项新任务。由于引文现在排在回复的最前面，整段文本就不再是合法的 JSON 了，对它执行 json.loads 会失败。只解析紧跟在结束标签 </source> 之后的内容。

answer = json.loads(text.split("</source>")[-1])

在全部三个模型上重新运行全部 50 个案例

用新提示重新运行评估，保持相同的 50 个案例和相同的三个模型。

Haiku 4.5 在旧提示和新提示下答对案例的比例。

五个不受支持的答案一个都没有再出现，Haiku 4.5 现在的得分已超过了准确率下限。

在下表中，运行成本是单个模型处理全部 50 个案例一次所花的价格，而每完成一项任务的成本则是将该数字除以正确答案的数量所得。

在 2026 年 8 月的标准价格下，使用新提示的全部三个模型在 50 个案例、90% 准确率下限标准下的表现。参见当前价格。

现在每个模型都超过了下限，因此您应根据每完成一项任务的成本来做选择，而 Haiku 4.5 的成本最低。

检查每一列，然后再决定是否升级

查看两次运行中的每一列，而不只是您最初想修复的那一列。 一项有助于某种案例的改动可能会破坏另一种案例，因此每次改动之后都要检查这一点。

统计不受支持的答案的数量，以及任何由正确变为错误的答案。Meridian 没有损失任何一个正确答案。

那三个在 schedule_status 上失败的典型案例这次通过了，尽管没有任何改动涉及那个字段所在的那一行。同一个模型在不同的运行中对同一个案例也可能给出不同的答案，因此在信任某个分数之前，应该对每种设置运行两次或以上。

在分数还在变化时，持续修改提示并重新运行。当分数不再变化、却仍未达到您的准确率下限时，说明模型缺乏某种能力，这时才该考虑升级。

总结

1. 先阅读失败的案例，按报告的种类和出错的字段进行分组。
2. 通过说明文档中没有答案时应返回什么、以及要求先给出引文，来修复提示中遗漏的内容。
3. 将相同的案例重新运行两次或以上，并检查不受支持的答案是否减少，且没有正确答案变为错误。
4. 只有在提示的改动不再推动分数变化之后，才升级到更大的模型。