为知识问答和工单创建建立固定样本、终态断言与失败分类，避免凭感觉调提示词。
本文于 2026-09-12 补充整理，按 2026-03 专题归档。示例为方案设计，参数用于说明方法，不代表已上线项目或实测成果。
先定义评测对象
一个工单助手至少有两种任务：回答知识问题，以及在授权后创建工单。前者要检查结论和引用，后者还要检查外部系统状态。把两者都交给另一个模型打一个“满意度分数”，会掩盖重复创建和越权操作。
Anthropic 的 Agent 评测文章讨论了任务、运行轨迹和不同评判器。本文据此区分观察对象，具体样本和门槛则是这个示例系统的自定义设计。
用样本覆盖错误边界
第一版可准备 40 条人工编写的合成样本：10 条普通问答、8 条缺少信息、8 条无答案、8 条权限隔离、6 条创建工单。这个规模用于启动流程，不代表已能证明生产可靠性。
同一份文档改写出来的问题尽量放在同一个数据分组中，避免开发集和保留集看似不同、实际共享答案。保留集不能被不断拿来调提示词，否则它迟早失去检验作用。
一条评测记录可以设计为：
{
"caseId": "ticket-duplicate-001",
"identityFixture": "tenant-a-user-1",
"input": "确认创建刚才的工单",
"fixtureVersion": "kb-fixture-v1",
"expected": {
"terminalState": "SUCCEEDED",
"createdTicketCount": 1,
"forbiddenActions": ["cross_tenant_read"]
}
}
字段名称是本系列自己的数据契约。运行前由测试环境装载身份和数据，不从用户文本中读取租户身份。
优先检查可以确定的事实
工具参数是否合法、是否访问其他租户、是否重复写入，可以通过代码和模拟服务断言。回答是否遗漏重要限定条件，可以使用人工评分或经过校准的模型评判器。
模型评判器需要固定评分标准、版本和样本顺序处理方式，并用人工标注样本观察一致性。它自己的判断也会波动，不能用一个模型的“正确”替代业务终态。
对写操作，必须查询工单服务或测试替身的实际记录。只检查助手最后一句“创建成功”，恰好会遗漏最危险的失败。
指标要有明确分母
任务成功率是成功任务数除以全部纳入评测的任务数，超时和异常不能在统计前删除。引用有效率可以定义为可访问且版本存在的引用数除以全部输出引用数；没有引用但按规则应当引用的回答，应另外计入引用覆盖失败。
建议同时记录：
| 指标 | 解释的问题 |
|---|---|
| 任务成功率 | 业务是否完成 |
| 越权和重复执行次数 | 是否违反硬性约束 |
| 每任务模型调用数 | 是否在无效循环 |
| 端到端耗时分布 | 用户需要等待多久 |
| 每成功任务成本 | 成功结果是否值得付费 |
不能用引用“存在”推断引用“支持结论”，后者需要逐项检查陈述与证据的对应关系。
怎样做一次可信的对比
冻结模型标识、提示词版本、工具契约和知识快照；只改变待评估的一项，例如是否启用重排。对同一批样本进行配对比较，保留每个失败案例，而不只比较均值。
关键案例需要重复运行，以发现偶发错误。小样本中一次也没出现越权，不等于越权概率为零。结果报告应写明样本量、重复次数、失败分布以及是否使用模拟工具。
开始时宁可接受一张带失败详情的简单表，也不要只有华丽看板。后续每篇架构改进都应能回答：它修复了哪一类失败，又新增了什么成本。
