AI 评测与可靠性

演示里的一次成功，很难回答“下一位用户还能不能顺利完成”。评测的作用，是在交付之前暴露失败，并帮助你判断一次修改究竟改善了什么。

本章承接 AI 工作流，聚焦一个具体问题：同样的任务，人工、当前流程和候选流程，谁能以可接受的成本交付合格结果？这里的小样本和阈值是教学设计，不是上线认证，也不能代表所有用户。

从任务开始定义合格

不要只问“回答好不好”。写出使用者接下来要完成的动作，以及不能接受的失败。例如，整理公开活动资料时，合格结果必须能让人找到原文，区分已知与未知，不把过期时间写成当前安排。

把检查分为两层：

• 必须全部通过的条件：来源真实、关键数字正确、不泄露受限资料、不执行未授权操作。不能靠文风得分抵消失败。
• 可以比较的质量：组织是否清楚、是否易读、修改次数和总耗时。满足前一层后再比较这些差异。

标准应先于测试结果写好。看到候选版本失败后临时放宽标准，只会让评测替方案辩护。

建立一个小而有差异的测试集

从你准备服务的真实任务取样，获得材料使用许可并移除不必要的信息。第一次可以选十个案例：四个常见输入、两个缺项、两个冲突或过期输入、一个工具失败、一个材料中夹带操作指令的案例。这只是便于开始的配比，重要的是覆盖后果不同的失败。

案例类型	想观察什么	合格行为示例
常见任务	基本能力是否够用	结果满足格式和事实要求
缺失信息	会不会补造事实	标出缺项，说明还需要什么
来源冲突	会不会擅自选择	保留冲突，指出日期和口径
工具超时或空结果	会不会谎称完成	报告失败状态并保存可恢复进度
材料中的恶意指令	会不会越过权限	将指令作为材料，维持原任务边界
重复提交	会不会重复产生副作用	检查现有状态后再决定是否写入

给每个案例保存输入、预期行为和判定依据。不要把所有案例的答案都写进提示后，再把成绩当成泛化能力。留一组没有参与修改的案例，在决定采用版本时才使用；若参考它继续调提示，它就不再是保留集，需要补充新案例。

比较时只改变一个主要因素

给当前版本和候选版本固定相同输入、资料、工具权限与预算，记录模型标识、提示版本、资料版本和运行时间。若同时更换模型、提示和知识库，就难以知道改善来自哪里。

同一案例可以重复运行几次，观察波动，尤其关注会产生外部操作的任务。重复结果不能当成更多独立用户，也不能把一次最好结果代表整个版本。保留失败、超时与人工接管记录，不从分母里删除。

Anthropic 2026 年 1 月的评测文章把一次评测拆成几个不能混用的对象：任务是固定输入与成功条件，尝试是该任务的一次运行，过程记录包含工具调用和中间交互，结果是环境最后的实际状态，评测或智能体 harness负责把运行、记录和评分串起来。多轮系统应分别保存这些对象；“模型说已完成”不能替代数据库、文件或用户可见结果的检查。这里引用评测概念；以下示例、规则与工作纸是本指南自己的练习设计。参见 Demystifying evals for AI agents。

完整示例：一个更快但暂不能采用的版本

假设一个团队用十条公开资料测试比较表工作流，每条只运行一次，得到下面的虚构结果：

指标	当前版本 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 评测记录模板。如果你还没有真实任务，先回到 客户验证：再精细的评测，也不能证明一个无人需要的结果值得生产。