How to Design AI Evaluations You Can Actually Trust
编译摘要
1. 浓缩
- 核心结论1：可信评测首先是环境适配问题，而不是把同一套 grader 套到所有任务上。评测者要先明确 sandbox、工具、依赖、真实资源和输出捕获方式，再决定使用确定性检查、mock 资源、隔离凭证，还是只评估计划；初始设计优先采用 one-shot prompt。
- 关键证据：原文
Know Your Evaluation Environment节要求根据 sandbox 能否确定性访问、资源是否需要隔离以及输出如何被捕获来调整 grader，并建议避免 interactive prompts。
- 关键证据：原文
- 核心结论2：评测必须让被测工具产生可观测差异，同时只惩罚 prompt 明确要求的结果，并评估最终目的而非一条预设路径。若 baseline 已接近满分，应提高任务难度或重新审视工具范围；若 agent 绕过自定义工具仍得到正确答案，这本身是工具价值的反馈。
- 关键证据：
Avoid the Ceiling Effect、The Prompt-Grader Mismatch和Grade the Destination, Not the Journey三节分别要求提高区分度、避免 scope creep、不要把工具调用轨迹当成最终质量。
- 关键证据：
- 核心结论3：评测集的信号质量来自真实且互不重复的能力覆盖，而不是样本数量本身。每个 prompt 应对应独立概念或能力，覆盖真实用户旅程，并合并重复题以降低过拟合、噪声和 token 浪费。
- 关键证据：
Curate Your Evaluation Dataset节要求使用真实用户旅程、把 prompt 当作传统测试中的 code coverage，并删除重叠题目。
- 关键证据：
2. 质疑
- 关于环境适配的前提：文章假定评测框架能够可靠捕获输出，或任务可以被 mock、隔离或转化为计划评估。对必须验证真实多轮交互、权限变化或外部副作用的工作流，one-shot 和计划评估可能遗漏关键失败。
- 关于“评估目的而非旅程”的边界：如果工具使用、审批顺序、审计轨迹或安全停机本身就是需求，不能简单把路径降为无关细节；应在 prompt 中显式要求这些过程，并分别设计过程 rubric。
- 关于五条规则的证据强度：这是 Google Developer Relations 的实践性指南，不是包含对照组、样本量和置信区间的实验报告。它给出设计原则，但没有证明不同规则对准确率、成本或稳定性的独立因果贡献。
- 关于 baseline ceiling 的更新条件：模型能力、工具说明或数据环境变化后，原本有区分度的题目可能失效；高 baseline 既可能说明工具无增量，也可能说明题目过易，需要重新分解这两种解释。
3. 对标
- 评测集作为工程测试资产：与传统 unit test 同构，但 Agent 评测的测试对象是工作流动作和最终结果；与 评测集 的共同点是把真实判断、边界案例和验收规则变成可复用样本。
- 评测与验证链：环境检查、结果评分和数据集维护分别对应 Agent 验证 的环境可观察性、基于评价标准的评估 的行为判定和评测集的持续维护。三者结合后，评测不只是分数，而是工具设计的反馈回路。
- 跨来源结构（综合判断）：本篇把“可信”落在题目设计上；OpenAI 把它延伸到工作流的 owner、permissions、evaluations 和 review points；Databricks 则要求每个业务域有 question set、ground truth、source validation 和 acceptance threshold。共同结构是：先定义可观察的成功边界，再把失败回流到产生问题的那一层。
证据边界
原文事实来自 Google Developer Relations 的单篇实践文章；“评测是工作流契约”和与另外两篇形成共同结构属于本次编译的综合判断，不是原文的实验结论。文章提到的下一篇 rubric 文章尚未作为本次来源使用。