Colay / 指南
根据您的产品实际需要的提示来比较 AI 模型
在构建评估管道之前，您可以在 Colay 中运行小型结构化比较。为可用的智能体提供相同的允许输入，检查他们单独的答案并记录他们满足哪些要求。这是一次实用的首次筛选，无需编写代码或提供提供商 API 密钥；它不是自动基准运行程序，也不是模型在您的产品中表现相同的证明。
将功能转变为可测试的案例
先明确用户需要什么输出，而不是从模型排行榜出发。如果功能是提取待办事项，合格答案应保留正确的负责人、任务和截止日期，并将缺失字段标为未知。即使摘要写得流畅，只要虚构了截止日期，这个案例就应判定为不通过。
作为说明性的起始集，准备 12 个允许的示例：4 个普通输入、4 个不明确输入和 4 个边缘情况。这些数字是可管理的练习，而不是经过统计验证的样本量。删除您无权共享的个人和机密信息。在每个案例旁边保留预期结果或明确的接受规则。
运行您可以解释的比较
Anthropic 的评估指南区分一项任务及其多次试验，因为每次输出可能不同。本文将这个基本区别用于人工初筛。少量正确答案无法确定生产环境中的失败率。
不要在一个候选模型失败后，只给另一个模型改进过的提示词。如果需要修改提示词，请保存新版本，并用它重新测试所有候选模型。否则，比较的差异既来自模型，也来自指令。
- 从当前目录中明确选择候选智能体。当您需要知道哪个候选模型回答时，请勿使用Auto。
- 保持摘要、源材料和要求的格式相同。使用Ask separately获取第一个答案并保留其标签。
- 记录日期、显示的智能体名称、提示版本和任何可见设置。将缺失的响应与错误的响应分开记录。
- 在比较文字表达质量之前，根据规则检查每个结果。重复重要或不明确的案例并保留每一次尝试，包括失败的尝试。
示例：会议记录中的操作项
虚构输入：“Mira 将于周二发送草稿。团队仍需为定价审核指定负责人。”预期结果应包含一项已指定负责人的任务和一项尚未指定负责人的任务，不应把两项任务都交给 Mira，也不应编造定价审核的日期。
有用的交付物是案例表，而不是最好答案的屏幕截图。将准确返回的文本附加到每一行，以便队友可以挑战您的分数。将格式化失败与实际失败分开：可修复的表格布局和虚构的承诺会产生不同的后果。
| 检查 | 通过条件 | 需要记录的失败情况 |
|---|---|---|
| 负责人 | Mira 只负责草稿任务 | 在没有证据的情况下分配定价审核 |
| 截止日期 | 周二是草稿任务的截止日期 | 虚构定价审核的截止日期 |
| 未知字段 | 定价审核的负责人仍标为未知 | 擅自补全缺失信息 |
| 可用性 | 这两个任务都出现在请求的结构中 | 任务省略或格式不可用 |
筛选运行的提示
将评估说明保存在应用于答案的单独清单中。您可以要求另一个智能体来识别可能的错误，但其结论是另一个要检查的输出。 Consensus可以帮助总结第一次比较后观察到的权衡；明确提供标记的结果和您的分数。
从提供的会议记录中提取操作项：[允许的记录]。返回包含任务、所有者、截止日期和支持摘录的表格。仅使用提供的文本。对于未指定的所有者或截止日期，请写未知。不要将建议变成商定的承诺。单独保留未解决的问题。输入 ID：[案例 ID]。
使用下一次测试的候选名单
总结每位候选模型处理的案例、其严重失败以及尚未解答的问题。仅当候选者的行为符合功能的最低要求时才保留候选者。如果没有人符合条件，请在选择获胜者之前缩小功能范围或改进所提供的上下文。
集成试验必须单独检查实际模型端点、工具访问、系统指令、延迟、使用成本和故障处理。 Colay 的积分并不是该 API 工作负载的报价。从 Colay 开始，从一个真实的、去识别化的案例开始，您可以自己评分，然后仅在比较改变您的候选名单时才进行扩展。
问题及解答
不提供 API 密钥，也能比较模型吗？
是的，用于 Colay 中的最终用户比较。将这些模型构建到您自己的产品中是一个单独的集成，具有自己的访问权限、条款和成本。
这是一个统计上可靠的基准吗？
不能将其视为统计上可靠的基准。小规模人工测试能揭示具体行为和失败案例。更广泛的结论需要有代表性的案例、重复试验，以及与决策相匹配的评估设计。
我应该使用Consensus来选择获胜者吗？
首先根据您的接受规则对单独的输出进行评分。使用综合来组织证据，使原始结果和人类决策保持可见。
来源和方法
- Anthropic — Demystifying evals for AI agents
区分任务和重复试验的主要工程指南。它不会评估 Colay 或验证示例样本大小。
将您的下一个问题提交给 Colay
选择一个模型、使用 Auto，或通过 Consensus 汇集多种观点。