4.1 评估（evals）

在构建Agentflow/Workflow时，如何提升效果是个重要问题。而想提升效果，就要研究到底是哪个环节导致了效果变差——此时，就要请出我们的评估系统了。

和刀耕火种的肉眼观察法不同，构建评估测试集可以让你的Agent系统拥有客观的，可溯源的，易于扩展的评估方式。但是很显然，在项目刚启动时，从哪里开始评估似乎是个模糊的问题。

此时，快速原型和迭代是关键。推荐采用快速而粗糙的迭代方法：

• 先构建一个非常简易，但功能完整的原型系统。
• 试运行并观察输出，找出表现不佳的地方。
• 利用观察结果来确定后续开发工作的优先级和方向，避免脱离实际过度空想。

理论总是抽象的，所以接下来我们看两个构建测试集的例子：

---

案例一：发票处理工作流程（提取到期日）

本系统想要从发票中提取四个必填字段并保存，特别是到期日，用于及时付款。

通过手动测试并检查 10-20 张发票的输出，发现一个常见的出错点是系统混淆了发票的开具日期和到期日。

进而，我们需要改进系统以更好地提取到期日，并编写一个评估（Eval）来衡量日期提取的准确性。

具体怎么构建这个评估呢？

1. 测试集： 找到 10-20 张发票，人工记录每个发票的正确到期日，作为正确对照。
2. 标准化格式： 在提示词中要求 LLM 始终以固定的年-月-日格式输出到期日，便于代码自动检查。
3. 评估方式： 编写代码（如正则表达式）提取日期，然后测试提取出的日期是否等于基本事实日期。
4. 用途： 调整提示或其他系统组件后，用这个指标的变化来衡量准确率是否有提升。

总结一下我们的改进流程： 构建系统 - 查看输出 - 发现错误 - 针对重要错误建立小型评估 - 调整系统以提高评估指标。

---

案例二：营销文案助理（限制字数）

本系统希望实现为 Instagram 图片生成标题，要求标题最多 10 个词。

通过观察输出，发现生成的文案内容还不错，但经常超过 10 个词的长度限制。

于是很显然的，我们就可以这样构建评估：

1. 测试集： 准备 10-20 个测试任务，如太阳镜、咖啡机图片和对应的提示词。
2. 评估方式： 编写代码计算输出的词数。
3. 判断标准： 将生成的文本长度与 10 个词的目标限制进行比较。
4. 与案例一的区别： 这个评估没有每个例子的基本事实，因为目标（10 个词）对所有例子都是一样的。

---

上面两个案例比较好做，因为AI输出可以被代码格式化，比如判断日期，判断长度。但是如果是“内容讲的对不对”这种比较抽象的评估，如何构建呢？我们来看下一个例子：

案例三：研究智能体（捕捉重要观点）

我们希望Agent能够根据用户输入的主题，如黑洞、机器人采摘，撰写研究文章。

通过检查输出，我们发现对于人类专家撰稿人会捕捉到的高知名度或重要观点，Agent生成的文章有时会遗漏。

所以我们可以这样构建评估：

1. 测试集： 针对每个场景，人工准备 3 到 5 个黄金标准讨论点作为每个例子的正确范例。
2. 评估方式： 由于提及这些观点的方式多种多样，简单的代码匹配不可行，因此使用 LLM 作为裁判员。
3. LLM 提示词： 要求评判 LLM 统计文章中提到了多少个黄金标准点，并返回得分和解释。

---

现在，我们基本上了解了如何对系统进行评估。

评估方式可以从两个维度划分，形成一个 2x2 的矩阵，用于指导评估的设计：

以及重申一下本节提到过的技巧：

1. 从快速而粗糙的评估开始： 不要因为觉得评估是一个大型项目，就不敢轻易建立，或者花漫长的时间去做理论调研。先用 10-20 个例子开始，快速获得一些指标来辅助人工观察。
2. 迭代改进评估：
   1. 随着系统和评估的成熟，可以增加评估集的规模。
   2. 如果系统改进了但评估分数没有提高，意味着该改进评估本身了。
3. 以专业人士的行为为灵感： 对于自动化人类任务的系统，观察系统在哪些方面性能不如人类专家，以此作为下一阶段工作的重点。