Google Developer Relations团队分享构建结构化自动评估管道的方法,强调从"感觉测试"升级为可量化基准。
在 Google 工作期间,我在 GitHub 上发布了一套面向 Google 产品和技术的 Agent Skills。这些 agent skills 旨在帮助 AI agent 与我们的技术进行交互。但如何验证这些技能是有用的且按预期工作的?我的 Developer Relations 团队一直专注于这个问题,因为获取关于它们性能的可靠信号,对于帮助我们持续改进至关重要。
就像不会在不写单元测试的情况下部署生产 API 一样,你对 AI agent 也应该采用同样的标准。正如 Joe Spiro 在《设计 AI 评估》系列文章中所示,扩展 AI 工具意味着超越在终端里「凭感觉测试」。相反,你应该建立一套结构化的自动化评估流水线,来对你的集成进行基准测试。评估(evals)是你让 agent 执行的动作,使用评分器(例如评分量规)进行评分,以判断 agent 是否成功。在这篇文章中我们将专注于评估,下一篇再讨论评分量规的技巧。
然而,AI 评估消耗真实的 token。你需要确保尽可能高效地使用这些 token。它们需要提供真正的价值,帮助你构建更好的工具。编写好的评估至关重要。糟糕的评估提供虚假信号,浪费你的 token 预算,并在指标中制造噪音。
以下是我们学到的五条设计可信评估的原则。遵循它们,确保你花的每一个 token 都产生有用的指标。
在编写评估之前,你需要了解所选框架的设置和限制。这包括 Harbor、Inspect AI 或 Agent Development Kit 等开发工具中的集成系统。它使用临时沙箱吗?有哪些可用工具?如何捕获输出?
根据环境调整评分器:例如,如果你能确定性访问沙箱来评估代码,那是一种选择。或者,让 agent 将响应打印到控制台。你的框架可以捕获此输出并直接传递给评分器。调整评分器以适配这些环境。
注意依赖限制和对「真实」资源的访问:如果评估任务需要访问「真实」资源(例如具有 Google Cloud 项目访问权限的已认证 gcloud 会话),创建临时资源或凭证来隔离和限制访问,这样它们不会影响其他评估。或者,你可以提供模拟工具而不是真实的测试凭证。
评估计划而非难以隔离的任务:一种更简单的方法可能是评估完成任务所需的计划,而不是实际执行。
避免交互式提示:多轮 agent 会话评估起来很复杂。入门阶段,使用一次性提示来设计你的评估。
如果你的评估显示出高基线准确率(即不使用你的 agent 工具的情况下),它可能无法证明其价值,或者评估提示太简单了。
编写更难的提示:如果基线模型已经知道答案,你就无法衡量新 agent 工具或技能的影响。
要求多步推理:设计反映复杂、真实世界用例的提示,在这些用例中你的工具能真正将自己与模型预训练区分开来。
重新审视工具的范围:如果测试反复报告高准确率但没有使用你的工具,可能是时候重新审视它了。底层模型和 agent 可能已经改进,能够在无需额外帮助的情况下完成任务。是时候重新定位或弃用你的工具了。
你不能对 agent 没有被明确要求做的事情进行评分。你的评估提示词和评分器应该是互补的。这意味着它们只应该测试提示词中包含的内容。
避免范围蔓延:如果你问了一个宽泛的问题,你可以期待一个同样宽泛的响应。例如,如果你的提示词是「如何保护 Google Cloud Run 的安全?」,你的评分器不能因为 agent 遗漏了某个未在提示词中指定的特定 IAM 角色而扣分。
要明确:如果你想评估特定知识或精确的实现细节,你必须在提示词中清楚地说明这些要求。
Agent 拥有内在的模型知识,可能完全跳过你的自定义工具而得出正确答案。(这本身就是一个有用的反馈!)
不要评估轨迹:避免编写检查 agent 是否使用了特定帮助命令或遵循了严格步骤序列的评分器。
评估最终答案:评估客观输出。如果你绝对必须评估 agent 的规划阶段,明确要求它输出详细的执行计划,然后评估该计划。
一个强大的评估套件测试真实的、多样化的用例。但重复测试相同的能力会导致过拟合并产生嘈杂的指标。
使用真实世界的例子:评估应该包括真实的用户旅程,并专注于用户想要实现的目标。考虑添加额外的上下文,例如脱敏的样本数据,以使评估更加落地。
最大化你的信号:确保评估套件中的每个提示词都测试一个不同的概念或独特的能力。可以把这想象成传统测试的代码覆盖率。
移除重叠:合并冗余的提示词。更小、更精选的数据集提供更清晰的指标,防止过拟合并节省 token。
如果你无法准确衡量 AI 工具,你就无法改进它们。如果你像对待传统单元测试一样对待 AI 评估,你就能提高指标的质量,获得更可靠的信号。
应用这五条原则,你可以消除浪费 token 预算的虚假信号。你的测试套件不再产生噪音,而是给你可操作的反馈,你可以用它来指导工程决策并改进你的工具。
弄清楚要测试什么只是第一步。一个设计良好的评估只有在评分答案的评分器可靠且返回有意义的结果时才有用。在我的下一篇文章中,我们将看看如何测试。你将学习如何编写精简、原子化的评分量规,最大程度减少 LLM 评分器的歧义,让每一个 token 都有价值。
Photo by William Warby on Unsplash
进一步操作,你可以考虑屏蔽此人和/或举报滥用行为