你怎么知道它管用？

你改了一句 prompt。输出在你盯着的那个例子上看起来更好了。上线。

你根本不知道自己是把系统改好了，还是把失败挪到了你没在看的地方。这就是大多数 LLM 工作的默认状态，也正是为什么评测（eval）——一组在固定样例上可重复运行的测试——是投入产出比最高的工程投入。

为什么直觉在这里不管用

三个原因，都跟这项技术本身有关。

不确定性。采样意味着同一个 prompt 会给出不同答案。跑出一次好结果，什么也证明不了。

**改 prompt 有副作用。**为了修好 A 而加上一条约束，常常会把 B 弄坏。没有固定的样例集，你永远看不到 B 的变化。

**流畅掩盖错误。**不管对不对，输出读起来都很像样。扫一眼不叫评测，而自信的错误正是扫一眼最容易漏掉的那类失效。

再加上静默的模型更新和不断漂移的输入分布，一个没有被度量的系统会悄悄退化，没人发现。

从十二个样例开始

评测不需要基础设施，需要的只是把样例存下来。

维护一个文件：输入，以及一个好的输出长什么样。十到二十个用例，覆盖你的真实分布，再加上你踩过的那些失败。每次改完 prompt 就跑一遍。

这就是一个真正的评测。大部分价值在这个规模上就已经拿到了，而这个文件会自然长大——**每一次生产环境的失败都会变成一条测试用例。**光凭这个习惯，一个项目的走向就会改变。

打分

难的是定义什么叫「正确」，而这因任务类型而异。

**完全匹配。**分类、抽取、结构化字段。自动化轻而易举，而且没有歧义。只要能安排成这种形式，就优先用它。

**包含 / 不得包含。**该有的事实都在，不该有的内容都不在。粗糙，但经常够用。

**schema 合法性。**能不能解析、字段合不合规。可以自动化，而且覆盖了一类真实存在的失败。见结构化输出。

**人工判断。**慢、贵，但对于任何主观的东西，它仍然是标准答案。十个仔细审过的用例，胜过一百个草率打分的用例。

**模型裁判。**让一个模型按标准给输出打分。它能扩展到很大的量，但需要小心：裁判偏爱啰嗦的答案，偏爱与自己风格相近的输出，而且给出的分数会挤在一个很窄的区间里。信任它之前，先在样本上用人标注的结果验证这个裁判；并且优先用两两比较——「哪个更好」——而不是绝对打分，两两比较更稳定。

对 agent 来说，要评的是结果，不是路径。通往同一结果的有效路径有很多条，而给路径打分，会惩罚合理的差异。

该量什么

除了正确性：

**一致性。**每个用例多跑几次。方差大说明 prompt 约束不足，而这与「答错了」是两种不同的可行动信号。

**失效模式分布。**不只是错了多少，还要看错在哪。十个格式错误和十个事实错误，需要的修法完全不同。

**检索增强生成（RAG） 系统，检索质量要单独量。**正确的文本块有没有被检索到？把这一项与生成分开诊断很关键，因为大多数 RAG 失败其实是检索失败，而改 prompt 根本碰不到它们。

**成本与延迟。**一个把准确率提上去、却让成本翻了三倍的 prompt 是一种取舍，不是胜利——没有数字，你根本看不出来。

怎么用好一个评测

**动手改之前先跑基线。**否则你分不清方向。

**一次只改一处。**同时改两处、总体变好，你仍然不知道是哪一处起了作用。

**留出用例。**拿全部样例来调，就会过拟合到它们身上。留一些在迭代过程中不看的。

**模型更新后重跑。**服务商的模型会在版本号不变的情况下发生变化。只有评测能让你发现这件事。

**有意识地接受回归。**有时一次改动修好五个用例、弄坏一个。这没问题——前提是明明白白做的决定，而不是意外。

不要做什么

**不要依赖公开基准测试。**它们量的是通用能力，不是你的任务。用来缩小候选模型范围有用，用来验证你的系统没用。

**不要先搭基础设施。**一个存样例的文件加一个脚本，胜过你花一周搭起来的框架。

**不要只追一个数字。**一个总分，会把失效模式的变化藏起来。

要点回顾

• 不确定性、用例之间的副作用、以及流畅的错误，让直觉变得不可靠——你需要固定的样例。
• **存下十二个用例就是一个真正的评测。**每一次生产环境的失败都会变成一条测试用例。
• 优先用可自动化的打分方式；用模型裁判时，先做验证，并优先用两两比较。
• 量一致性、失效模式分布、单独的检索质量，以及成本。
• 先跑基线，一次只改一处，留出用例，模型更新后重跑。

下一篇： 从 Demo 到生产环境