开发阶段可以用一个循环跑十条样本。等到三个团队同时改 Prompt、检索和工具，再加上每天进入系统的新问题，最难的部分变成：这份分数属于哪个版本，失败有没有被遗漏，线上问题怎样回到下次发布之前。
生产评测系统的核心是保存能够重建判断的证据。界面和排行榜建立在这层数据之上。
从一条案例走过整条流水线
数据集提供公开输入和环境引用，Runner 在隔离环境执行被测系统，得到输出、动作和业务状态。Evaluator 读取这些观测及隐藏期望，产生各项评分。实验记录把它们与模型、Prompt、工具和数据版本关联起来。
版本化案例 → 隔离环境 + 被测系统 → 输出 / 轨迹 / 最终状态
↓
隐藏期望 + 评分器版本 ───────────────→ 逐条评分
↓
切片报告 → 人工复核 → 发布判断example_id 指向案例，trial_id 区分重复尝试，experiment_id 标识配置组合，trace_id 连接过程记录。把这些都塞进一个自增 ID，会使重复实验和线上回流难以对齐。
配套 suite.py下载 提供纯标准库的完整离线闭环：独立初始化场景、运行两个确定性策略、核验业务效果、记录错误、输出 JSON 报告。它演示评测机制，不声称测量真实模型能力。另有可选的 model_eval.py下载，使用真实模型决定工具调用，再由同一套 oracle 检查本地虚构账本。它限制调用轮数、保存 Token 用量，并区分运行错误和评分错误；本轮未进行在线调用。
为什么要分开运行失败和评分失败
Agent 超时意味着任务没有在预算内完成；评分器超时意味着暂时不知道结果。Runner 应分别记录 run_error 和 evaluation_error，保留原始输出，以便只重跑评分而不用再次执行业务动作。
重试也有边界。读取模型服务可以按预算重试，但写工具必须具备稳定业务键和隔离环境。一次评分失败不能触发退款再跑一遍。缓存键需要包含输入、模型配置、Prompt 和评分器版本；跨版本复用缓存会让实验比较失真。
并发提高吞吐，也会造成供应商限流或环境争用。应限制并发、隔离每条案例的状态、记录排队时间和实际执行时间。性能评测要说明是冷缓存、热缓存还是模拟结果，不能把命中旧答案的速度当成模型响应速度。
发布门禁是一项业务决策
先检查严重权限和副作用违规，再检查质量、评分覆盖、延迟和成本。没有完成评分的任务需要处理，而不能因为平均分达标就忽略。对于少量未知项，可以让报告显示成功率上下界，并由发布策略决定是否等待人工。
上线阈值需要来自业务目标和实际基线。文中的 90% 或 95% 只是教学数字，不能直接复制。一次风险集零失败也不证明自然流量永远安全，门禁是基于已有证据的判断。
报告应附上新修复和新退化案例。例如整体提升五点，但“审批撤销”切片出现退化，这比一张绿色仪表盘更有助于决定是否发布。
在线抽样需要知道自己漏掉了什么
普通问题随机抽样，退款和权限边界增加覆盖。若抽样概率不同，未经加权的样本平均不能直接当成全量流量平均。可以分别报告切片，或在适当假设下按已知抽样概率估计总体；高风险定向发现集仍应独立展示。
线上没有完整标准答案时，可以检查格式、工具错误、可核验事实和经过校准的语义标准。用户好评与任务真正完成有关，但不是等价关系：用户可能还没发现错退金额。人工复核负责把候选坏例变成可信案例。
Shadow 与 A/B 各自解决什么
Shadow 将相同输入交给候选版本，但写工具应路由到隔离环境或明确模拟器；仅隐藏候选的回复，不会阻止真实副作用。带状态任务还需要初始快照和可重复的工具响应，不能让影子任务改变正式任务接下来看到的世界。
A/B 用随机分配比较实际业务效果。多轮任务应按用户或 Thread 等合适单元稳定分桶，避免同一任务中途切换版本。预先确定主指标、护栏、实验单元和停止规则；同一用户的多次请求具有相关性，统计时不能都当独立样本。
遇到严重安全信号可以止损，但不能把因好看而提前结束的普通检验当作无偏结论。回滚还要处理未完成任务的版本绑定，而不只是切换一个模型名称。
平台怎样选择
先让候选平台完成同一组任务：导入有版本的数据，运行 Python 与 Java 结果，组合规则和 Judge，关联 Trace，送人工复核，导出原始记录。检查数据能否带走、访问控制如何实现，以及开源组件和托管服务的功能边界。
Ragas 更适合深入指标与语义评分；Promptfoo 适合配置驱动的回归和断言；Inspect AI 将任务、执行与评分组织成评测框架；DeepEval 提供测试式的应用评测。Phoenix 可用于 Trace、实验与评分关联，使用时检查具体版本许可证；LangSmith 的平台能力不应被默认当成一个可完全自托管的开源项目。
不必为每个名字引入一套数据格式。先定义内部实验记录与评分契约，再让平台适配它。只有现成方案不能满足数据、规模或组织要求时，才承担自建控制面的长期维护。
反馈回流需要一道质量关
线上失败先脱敏、去重、确认事实，再补充初始状态与允许结果，产生新数据集版本。保留原始事故与案例的关联，但删除无关个人信息、密钥和未经授权的数据，设置访问权限及保留期限。
评测系统自身也要有预算和故障降级。离线报告可以等待重试，在线异步评分不应该阻塞用户主流程；关键授权检查则属于业务执行层，不能因为评分器不可用而跳过。
官方能力入口：Inspect AI、DeepEval、Phoenix、LangSmith 评测概念。
继续阅读与配套材料
上一篇：怎样知道 Judge 值得信任：人工标注、偏差与校准。
下一篇：多模态 Agent 怎样评测：文档、图片与实时语音。
完整示例、运行方式和验证边界见评测实验指南下载。本系列的订单、政策、金额和实验数据均为教学示例。