依据证据选择模型

明确要作出的决定

比较模型需要明确用途。能很好地解释小函数的模型，未必同样擅长大型代码仓库修改。成本较低的模型可能已能满足常规转换任务的质量要求。复杂调查则可能需要更强的推理能力。

先写明任务和约束，包括允许的数据、必要工具、响应时间和最高可接受成本。有些约束是必须满足的。不能因为其他得分很高，就通过求平均忽略数据处理限制。

根据团队实际工作建立小型评估集。除非评估环境获准处理相关数据，否则应移除敏感数据。纳入简单任务、困难任务，以及正确做法是请求补充信息的任务。

对于一个虚构的报表服务，可以使用已知日期缺陷、小型筛选功能，以及授权规则的解释。运行比较前准备好预期结果。加入一个能够检出已知缺陷的反向测试。

保留一些不参与提示词调试的任务。如果反复针对每个示例调整提示词，最终得分可能夸大一般表现。单独保留的任务集，有助于检验改进后的提示词能否处理调试示例之外的情况。

记录准确的模型版本、提示词、提供的上下文、工具和权限。使用等效的初始状态。如果一个模型获得完整代码仓库，另一个只获得单个文件，结果比较的就不只是模型，还包括工作流。

工作流比较也可能有用，但必须准确标明。智能体产品不只有模型：上下文选择、工具、执行限制和恢复行为都可能影响结果。

如果输出波动会影响结论，就重复运行。记录失败尝试，不要只报告最好结果。对于主观标准，在可行时采用书面评分规则，并安排多位审查者。

先检查必须满足的验收标准。修改是否符合要求？是否保留访问控制？相关测试是否通过？审查者能否理解 diff？

再针对可接受的结果，比较投入、总历时和成本。计入重试和人工审查。一个价格低但需要反复修正的回答，在完整任务层面可能很贵。

公开基准可以帮助筛选候选模型，但它们使用特定任务集和评分方法。不要把基准得分当作团队生产力的直接测量值。

评估结果可以是一条范围有限的建议。例如：“在这个代码仓库中，按照现有审查要求，使用此模型补充小型测试。”不必让一个模型承担所有任务。

说明哪些情况需要重新评估，例如模型版本变化、工具配置改变、新的数据类别或持续出现的失败模式。对于超出所选模型能力的任务，保留备用方案。

评估的目的是减少实际决策中的不确定性。避免把模型比较变成永久竞赛，让它耗费的工作量超过其所支持的工作。