AI 评测与可靠性：知道什么时候可以交付
演示里的一次成功，很难回答“下一位用户还能不能顺利完成”。评测的作用，是在交付之前暴露失败，并帮助你判断一次修改究竟改善了什么。
本章承接 AI 工作流，聚焦一个具体问题：同样的任务，人工、当前流程和候选流程，谁能以可接受的成本交付合格结果？这里的小样本和阈值是教学设计，不是上线认证，也不能代表所有用户。
从任务开始定义合格
不要只问“回答好不好”。写出使用者接下来要完成的动作，以及不能接受的失败。例如，整理公开活动资料时，合格结果必须能让人找到原文，区分已知与未知，不把过期时间写成当前安排。
把检查分为两层：
- 必须全部通过的条件：来源真实、关键数字正确、不泄露受限资料、不执行未授权操作。不能靠文风得分抵消失败。
- 可以比较的质量：组织是否清楚、是否易读、修改次数和总耗时。满足前一层后再比较这些差异。
标准应先于测试结果写好。看到候选版本失败后临时放宽标准，只会让评测替方案辩护。
建立一个小而有差异的测试集
从你准备服务的真实任务取样，获得材料使用许可并移除不必要的信息。第一次可以选十个案例：四个常见输入、两个缺项、两个冲突或过期输入、一个工具失败、一个材料中夹带操作指令的案例。这只是便于开始的配比，重要的是覆盖后果不同的失败。
| 案例类型 | 想观察什么 | 合格行为示例 |
|---|---|---|
| 常见任务 | 基本能力是否够用 | 结果满足格式和事实要求 |
| 缺失信息 | 会不会补造事实 | 标出缺项，说明还需要什么 |
| 来源冲突 | 会不会擅自选择 | 保留冲突，指出日期和口径 |
| 工具超时或空结果 | 会不会谎称完成 | 报告失败状态并保存可恢复进度 |
| 材料中的恶意指令 | 会不会越过权限 | 将指令作为材料，维持原任务边界 |
| 重复提交 | 会不会重复产生副作用 | 检查现有状态后再决定是否写入 |
给每个案例保存输入、预期行为和判定依据。不要把所有案例的答案都写进提示后，再把成绩当成泛化能力。留一组没有参与修改的案例，在决定采用版本时才使用；若参考它继续调提示，它就不再是保留集，需要补充新案例。
比较时只改变一个主要因素
给当前版本和候选版本固定相同输入、资料、工具权限与预算，记录模型标识、提示版本、资料版本和运行时间。若同时更换模型、提示和知识库，就难以知道改善来自哪里。
同一案例可以重复运行几次，观察波动，尤其关注会产生外部操作的任务。重复结果不能当成更多独立用户，也不能把一次最好结果代表整个版本。保留失败、超时与人工接管记录，不从分母里删除。
Anthropic 2026 年 1 月的评测文章把一次评测拆成几个不能混用的对象：任务是固定输入与成功条件，尝试是该任务的一次运行，过程记录包含工具调用和中间交互，结果是环境最后的实际状态，评测或智能体 harness负责把运行、记录和评分串起来。多轮系统应分别保存这些对象；“模型说已完成”不能替代数据库、文件或用户可见结果的检查。这里引用评测概念；以下示例、规则与工作纸是本指南自己的练习设计。参见 Demystifying evals for AI agents。
长时任务与隔离环境要单独评测
如果任务可以异步运行、等待工具返回或在中途接收输入，就把“是否完成”拆成四个问题：状态能否恢复，重试是否重复安全，网络和写入范围是否仍在授权内，人能否在不可逆动作前接管。MCP 2026-07-28 规范把 Tasks 作为可选的长时任务扩展；它提供互操作语义，不替你决定超时、权限或安全边界。
为每次运行保存唯一编号、检查点、墙钟时长、工具调用次数、网络域名、授权记录和最终环境状态。用干净环境开始每次试验，避免上一次运行留下的文件、令牌或缓存让结果看起来更好。若使用浏览器或电脑操作，将页面文字、截图和链接视为不可信材料；不要因为页面要求就扩大网络出口或上传范围。
再加入一个“评测环境故障”案例：网络本应关闭却意外开放、测试机器触达真实系统，或者重试重复写入。Anthropic 对网络安全评测事故的复盘说明，环境配置和范围说明本身就可能成为失败原因；因此通过条件应包含网络出口验证、凭证隔离、实时日志和可恢复的人工退路。参见 Investigating three incidents in our cybersecurity evaluations 与 MCP Security Best Practices。
长时任务的最小案例
| 案例 | 额外记录 | 硬门 |
|---|---|---|
| 中途暂停后恢复 | 检查点、恢复编号、已完成写入 | 不重复产生副作用，最终状态可核对 |
| 工具超时后重试 | 超时原因、重试次数、重复安全标识 | 超过上限停止并交回人工 |
| 页面夹带操作指令 | 页面 URL、截图/原文位置、授权范围 | 指令不改变任务边界或网络出口 |
| 受限网络环境 | 域名白名单、凭证范围、出口日志 | 不能触达未授权系统，凭证不跨环境复用 |
这些记录用来判断工作流是否可照看，不是用来证明某个模型“已经安全”。
完整示例：一个更快但暂不能采用的版本
假设一个团队用十条公开资料测试比较表工作流，每条只运行一次，得到下面的虚构结果：
| 指标 | 当前版本 A | 候选版本 B |
|---|---|---|
| 首次交付合格 | 8/10 | 9/10 |
| 关键事实错误 | 0 | 1：把未给出的价格写成免费 |
| 人工修改后合格 | 10/10 | 10/10 |
| 准备、运行、核验与返工 | 120 分钟 | 100 分钟 |
| 工具费用 | 6 元 | 8 元 |
若示例内部把工时按每小时 60 元估算，A 的这批任务总成本为 120 ÷ 60 × 60 + 6 = 126 元，B 为 100 ÷ 60 × 60 + 8 = 108 元。这只是过程成本示例，不含获客、税费等经营项目；计入返工后的每份合格结果成本分别为 12.6 元和 10.8 元。
B 更快、首次合格数量更多，但违反“关键事实不能编造”的条件，因此本轮决定是不扩大使用，先修复并复测。这不意味着 A 已被证明可靠；十条输入、各一次运行仍然证据有限。
这里“首次合格”和“人工修改后合格”必须分列。如果把人修好的结果全部算成模型的正确回答，会同时夸大质量和低估维护成本。
谁来评分，以及怎样处理分歧
字段、算式、文件状态等尽量用明确规则判断。语义、用途和表达由了解任务的人核对。若用模型辅助评分，先拿一批人工标注的案例对照，检查它是否偏爱更长、更自信的回答。
对高影响错误逐条看原始材料，不只看平均分。两位审阅者不一致时，记录争议点，补充评分说明，再复评；不要仅靠投票掩盖标准含糊。允许答案有不同表述，也允许“材料不足，不能判断”是正确结果。
把失败转成下一次回归检查
| 失败 | 先排查 | 下一步验证 |
|---|---|---|
| 来源不支持结论 | 材料版本、提取、引用位置 | 换一份有相似表述但不同结论的资料 |
| 没找到信息 | 检索范围、过滤条件、工具返回 | 加一个确实不存在信息的案例 |
| 输出格式漂移 | 字段约定、结构校验 | 缺字段和额外字段都能被发现 |
| 重复或越权操作 | 权限、状态检查、重试逻辑 | 用无副作用的测试环境演练中断重试 |
| 核验时间过长 | 任务范围、来源粒度、验收方式 | 比较总工时是否真的下降 |
修复后既跑触发问题的案例，也跑之前合格的案例，避免解决一处、破坏另一处。若结果依赖外部服务，保留资料与环境版本，说明哪些条件无法完整复现。
从评测走向小范围使用
模型变化以后，旧成绩不能自动沿用
一次通过说明的是某套输入、模型、材料、记忆设置和工具权限下的表现。本指南建议把这些条件一起记录；如果服务不提供固定版本，也如实记下显示的模型名称、运行日期与无法控制的部分，不伪装成完全可复现。
建立两组用途不同的样本：回归集包含已经暴露的错误，用来防止重犯；保留集用来检查未参与调优的情况。反复看着保留集修改流程以后，就应把它转入开发或回归集，再补新案例。
更换模型或工具、更新知识库、开启记忆或发现异常时，先在测试环境跑相关案例，并检查最终文件或系统状态。对检索任务分别检查“有没有找到应有材料”和“结论是否被材料支持”；对多模态任务分别检查“识别是否正确”和“解释是否成立”。这样才能知道该修哪一层。
记录采用日期、负责人和上次合格版本。出现硬性条件失败，就缩回已验证的范围；旧版本若无法恢复，保留人工流程作为退路。维护工作也计入成本，一次发布不能替代后续照看。
让每次采用都有退出办法
采用版本前，写清允许处理的任务、不支持的输入、人工接管条件、费用上限和撤回办法。小范围使用期间继续收集真实失败，定期更新样本；更换模型、提示、检索或工具后重跑相关测试。
把一次完整对比记录在 AI 评测记录模板。如果你还没有真实任务，先回到 客户验证：再精细的评测，也不能证明一个无人需要的结果值得生产。