From Prototype to Production — Evals 作为 AI 系统的单元测试范式
来源：Palantir Blog（2024-10-21，13 分钟阅读，Engineering Responsible AI 系列 #3；Arnav Jagasia / Head of SE for Privacy & Responsible AI，Colton Rusch / Privacy & Civil Liberties Engineer）。证据定级 medium：核心方法（test bench + evaluator + iteration loop）是软件工程单元测试范式的延伸，可独立验证；产品包装在 "AIP Evals" branding 与虚构案例（Titan Industries），但案例数字链（41.3%→93.3%→tool handoff 修复）具有方法论示范价值。
编译摘要
1. 浓缩
- 核心结论1：GenAI 系统天然非确定（幻觉 + 透明度缺失 + 提示敏感），从 prototype 到 production 的桥梁不是更大的 demo，而是 T&E（Testing & Evaluation）框架——aggregate 指标 + 失败案例 drill-down + prompt/parameter/tool 迭代三位一体
- 关键证据: 与传统 ML T&E 的关键差异：GenAI 开发者可以"take specific failures from test cases and more readily improve the AI system through prompt engineering, augmenting the model with data, and providing tools for handoffs"——失败案例直接指向三种可操作修复路径。
- 核心结论2：AIP Evals = 单元测试范式移植，五大组件：Test Bench（ontology 历史数据 + Object Set-backed Test Cases）→ Evaluators（内置 no-code / 自定义 Python/TypeScript / LLM-as-judge）→ Running（每个 test case 默认 3x 以应对非确定性）→ Results（aggregate + individual dashboard）→ Iteration（drill down 到 inputs/intermediate outputs/final response → 修改 → re-run）
- 核心结论3：迭代必须可度量才能"with confidence"——案例中产品召回 AI 系统准确率 41.3% → 改 prompt（补充 expert review 触发条件）→ 93.3% → 剩余失败定位为 LLM 数学错误（1.865 vs 正确 1.864）→ hand off 给 Calculator tool → 通过
- 关键证据: 两个附带洞见：(a) "human in the loop" 的正确实现是 AI 判断"是否触发专家 review"而非替专家决策——41.3% 的根因是 prompt 未说明这一点；(b) LLM 语言处理强、数值计算弱，必须架构上允许 tool handoff（与 [[20260730-palantir-responsible-ai-black-box-explainability|系列 #2]] 的透明交接呼应）。
2. 质疑
- 关于"结论1"的质疑: "T&E is the cornerstone" 是行业共识级主张，增量有限；真正的方法论贡献在"失败案例→三种修复路径"的映射，但该映射依赖失败可归因——现实中多数失败是多因叠加（提示+数据+模型能力边界），drill-down 未必能定位单一修复点。
- 关于"结论2"的质疑: "每个 test case 默认 3x"是对非确定性的朴素处理，未讨论 3 次中 2 次通过算什么、pass@k 阈值如何设定、评测集本身的分布偏差如何校正——这些恰是 evals 工程化的真正难点（参见库中 Evaluator-Miscalibration）。
- 关于"结论3"的质疑: 41.3%→93.3% 的跃升来自单一 prompt 缺陷（expert review 条件缺失），属于"明显的提示 bug"，不能代表典型迭代曲线；且整个评测基于历史人工决策（"Should Recall" 字段），ground truth 本身携带人类专家偏差——evals 只能收敛到人类历史判断，不能超越它。
- 数据可靠性: 案例数字内部自洽但为虚构场景；方法论骨架可移植。
3. 对标
- "evals are the new PRDs" 的平台侧实现: Anthropic 产品团队主张 evals 取代 PRD 的需求定义功能（20260730-lenny-anthropic-first-technical-pm-dianne-penn，PM 视角：用户反馈→失败轨迹→eval set）；本文是同一命题的平台基础设施视角（企业客户如何在产品内运行 evals 循环）。两者构成 Why（PM 工作流变革）/How（平台提供什么）的完整配对，应交叉引用。
- Evaluation-Set 获得完整生命周期: 库中评测集条目此前聚焦"FDE 把隐性知识显式化为评测集"与"评测集 IP 归属"（采购视角）；本文补上评测集的运行时生命周期——构建→评估→drill-down→修复→防回归，使其从"资产"升级为"迭代引擎"。
- 与 Operational Responsibility 的 debug 文化同构: OR 的 "treat every major incident as an opportunity to improve" = evals 的 "toggle to failures tab, drill down"——生产事故的 paging 文化与评测失败的 drill-down 文化是同一反馈原理在运维侧和开发侧的投影。
- 约束分析（3c）: 硬约束——非确定性系统不可用单次运行验证（统计本质）；软约束——3x 重复、evaluator 类型选择、pass 阈值（工程参数）；自设约束——"ground truth 必须来自人类历史决策"在探索性场景中自设——无历史数据时 evals 需要从合成案例或对抗生成启动。