---
title: AI 评测与可靠性：知道什么时候可以交付
description: 用真实任务、小型测试集、失败分类和完整成本比较 AI 工作流，识别一次成功与稳定可用之间的差别。
updated: 2026-10-03
sources_checked: 2026-09-20
---

# AI 评测与可靠性：知道什么时候可以交付

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

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

## 从任务开始定义合格

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

把检查分为两层：

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

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

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

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

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

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

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

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

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

Anthropic 2026 年 1 月的评测文章把一次评测拆成几个不能混用的对象：**任务**是固定输入与成功条件，**尝试**是该任务的一次运行，**过程记录**包含工具调用和中间交互，**结果**是环境最后的实际状态，**评测或智能体 harness**负责把运行、记录和评分串起来。多轮系统应分别保存这些对象；“模型说已完成”不能替代数据库、文件或用户可见结果的检查。这里引用评测概念；以下示例、规则与工作纸是本指南自己的练习设计。参见 [Demystifying evals for AI agents](https://www.anthropic.com/engineering/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 评测记录模板](../../templates/ai-evaluation.md)。如果你还没有真实任务，先回到 [客户验证](customer-discovery.md)：再精细的评测，也不能证明一个无人需要的结果值得生产。