如何在发布之前评估 LLM 申请

指南内容

Anthropic 的 2026 年 1 月指南将代理测试分为任务、重复运行、评分规则和测试环境。它还将代理所说的与实际所做的分开。例如，当记录从未更改时，代理可能会说它保存了记录。对结果和对话进行评分。这是模型供应商的建议，并不能证明一种方法适用于每个系统。

证据： 揭秘人工智能代理的评估 [1]

选择您的测试必须支持的决定

用一句话写出发布问题。例如：我们的支持助理能否在不承诺无法批准的退款的情况下解释帐户政策？这为测试提供了明确的用户、任务和风险。诸如“更有帮助”之类的模糊目标可能会奖励错误的顺利答案。

决定要测试多少工作流程。对于一个总结工具来说，一个答案可能就足够了。聊天助理可能需要整个对话。如果客服人员编辑记录，也请检查已保存的记录。保存模型版本、提示、搜索设置和工具权限。其中任何一个的改变都可能改变结果。

构建一个您可以查看的小型测试集

Rubrex 建议三组案例：常见任务、边缘案例和已知故障。对于每个案例，写下预期的行为以及该案例属于测试的原因。在调整系统时保留一些情况。在使用分数支持发布之前，使用第一次测试运行来找出不明确的需求。

使用代码检查确切的规则，例如必填字段或允许的记录 ID。使用评分指南来了解意义、缺失的细节和诚实的不确定性。要求审阅者自己对一个小型共享集进行评分。在信任自动法官处理更多案件之前，先讨论他们的不同意见。将无法评分的案例保留在报告中并解释原因。

• 保存原始版本和每个答案，包括失败的请求。
• 在相同的输入和限制上运行更改后的版本。
• 检查好转的病例和恶化的病例。
• 为每个阻止释放的故障指定一个指定的所有者。

示例：解释政策的助理

假设助理必须引用当前政策、解释例外情况并避免承诺批准。它可能满足前两条规则，但仍然无法承诺退款。对每条规则进行评分，以便团队能够找到问题。还要记录答案是否通过了每条必需的规则。

现在假设一个新的提示修复了引用，但做出了更多不受支持的承诺。这是一个好坏参半的结果。测试针对承诺的更改，然后重新运行之前的案例以检查是否有新的失败。这是一个示例测试计划，而不是来自 Rubrex 客户端的结果。

给下一个工程师足够的时间来重新运行测试

分享案例、评分规则、系统版本、原答案。按原因对失败进行分组并解释仍未知的内容。包括重新运行测试和添加启动后发现的故障的步骤。另一位工程师应该能够检查决策，而无需作者的幻灯片。当证据太弱而无法做出决定时，请列出缺失的数据和下一个测试。

记录每个分数的含义

Choose measures that answer the release question.对于支持助理，Rubrex 建议跟踪错误答案、不受支持的声明、已完成的任务以及有用答案的成本。说明每个计数涵盖的内容。 Ten failed answers out of 100 answers means something different from ten failed sessions out of 100 sessions.包括没有产生答复的请求。

一项测试检查一项要求。测试套件检查多个要求以及系统可能失败的方式。将您的应用程序结果与公共模型基准分数分开。写一份简短的决策记录，其中包含新旧版本、测试的案例、分数定义以及阻止发布的故障。列出下一个测试的负责人。

常见问题