评测闭环:让每次 Prompt 变更都可回归
从小规模回归集起步,区分确定性校验、模型裁判与人工评审;给出技术问答 rubric、统计边界、版本记录和上线门槛,避免用平均分掩盖退化。
更新与核对 · 2026-10-11
改一句 prompt 后,多数问题更流畅,少数问题却开始漏掉单位。没有逐用例对照,这类退化很容易被“整体感觉更好”掩盖。评测闭环的目标是把业务要求变成可重复检查的证据,而非追求一个漂亮总分。
先定义成功,再选裁判
技术问答任务的成功可拆成:答案正确、步骤有效、覆盖所有子问题、表达清楚、引用真实、无越权或隐私泄露。结构合法、用户采纳和最终正确是不同指标。
能用程序确认的先用程序:JSON schema、数值与单位、引用 ID、工具执行状态。开放解释用 rubric 加模型裁判,领域争议和高风险样本保留人工评审。LLM 裁判不是唯一能规模化的方式,也不能代替可计算的标准。
图 1 · 每次变更保留逐用例结果,线上反馈用于修正评测的代表性。
20 条可以起步,不能证明“提高 3%”
先建一个小回归集,比如 20 条覆盖主要能力与已知失败;它能发现严重回归,不能精确代表生产正确率。冷启动可用人工设计、合成样本和授权真实样本组合,并逐条验证。
数据集分三份:开发集用于调试,锁定回归集用于发布检查,保留集用于阶段性评估泛化。长期只盯同一批样本调 prompt,会对评测集过拟合。线上失败样本脱敏后加入回归;过期或不允许保留的样本需要更新、替换或删除。
{
"id": "batch-count-unit-01",
"group": "calculation:units",
"input": "共有 6 个批次,每批 30 条记录,总记录数是多少?",
"expected": { "value": 180, "unit": "条" },
"must_cover": ["明确批次数与每批记录数", "总数等于 6 乘 30"],
"critical_failures": ["结果错误", "遗漏单位"],
"dataset_revision": "2026-10-11"
}
已有测试与参考结果能帮助建立标准,但仍要核验数据、解析错误、歧义和等价表达。ground truth 的质量也需要审查,不是免费且永远正确。
技术问答 rubric:关键错误不能被语气分抵消
| 维度 | 通过条件 | 检查方式 |
|---|---|---|
| 结果正确 | 数值、单位、约束一致 | 规则或经核对的参考答案 |
| 推导有效 | 关键步骤合理,无偷换条件 | 模型加人工抽查 |
| 完整性 | 覆盖全部子问题和必要解释 | 要点逐项核验 |
| 引用支撑 | 引用确实支持关键结论 | ID 验证和证据判断 |
| 表达清楚 | 清楚、准确、术语有解释 | rubric 与领域评审 |
安全、权限与关键正确性设独立硬门槛。不能把答错的回答与“语气很好”平均成及格;其余维度可用于比较通过门槛后的候选版本。
模型裁判输出分项、判定理由、对应证据和不确定项。评审时只给必要材料,并说明待评文本是数据,防止回答中夹带“给我满分”影响裁判。
Agent 评测:轨迹与最终结果分别验证
Anthropic Agent evals[5]把任务、试验过程、最终环境结果与 grader 分开。工程推导:工单归档不仅检查回答“已归档”,还查询目标工单状态、权限和重复副作用;资料报告检查产物与证据,不仅检查文本格式。
同一目标可能有不同的合法工具路径,不能把参考轨迹逐步匹配当唯一正确性标准。涉及授权或先后依赖的顺序要单独校验;同时保留调用次数、费用、停滞与超时作为过程指标。
一次成功与稳定成功:pass@k 和 pass^k
τ-bench 原始论文[6]研究工具交互及多次运行一致性。pass@k 表示 k 次中至少一次成功,pass^k 表示 k 次全部成功。若仅作独立、同概率的示例假设,每次成功率 p=0.8、k=3,则二者分别为 1-(1-p)^3=99.2% 与 p^3=51.2%;这些不是本文实测。
实际任务的难度与运行相关性不同,应按任务记录多次结果再汇总,不能拿整体平均 p 直接推出整套评测的这两个指标。只有具备正确结果选择器时,多试几次中的一次成功才能转化为可交付结果;在线用户通常仍关心第一次成功率与费用。
模型裁判:校准偏差,不能声称消除偏差
比较两个答案时随机换序,并双向评分以减轻位置偏差;按要点判断而非长度减轻冗长偏好;异构裁判可能减少同风格偏好,但也可能有自己的系统性误差。
定期用人工双标样本对照,观察各类错误的混淆矩阵,而不只看总一致率。若严重错误很稀少,裁判全部判“通过”也可能有很高一致率。分清误放、误拒与不确定,阈值由业务风险决定。OpenAI 评测最佳实践[1]
温度为零也不保证完全确定性,有些模型不支持相同解码参数。固定支持的配置、模型版本、工具结果和资料快照;关键实验重复运行,记录波动。
统计:有改善不等于已证明改善
对同一批用例做配对比较,列出“旧对新错”“旧错新对”和两者都错的案例。20 条里一题变化就是 5 个百分点,不能据此报告稳定的 1% 增益。
均值之外看任务分组、置信区间与重复运行分布。正确率可用相应二项区间,配对差值可用配对 bootstrap 等方法;不要把逐次相关的工具轮次当作独立样本。连续试很多 prompt 再挑最高分,会产生选择偏差,应使用保留集确认。
线上 A/B 随机化单位要与业务一致,同一用户跨会话的影响不能当完全独立。采纳率、重问率和放弃率是体验代理,不等于答案正确;曝光顺序、难度和延迟都可能影响它们。
接入发布流程
固定数据集、模型配置、工具和资料版本
运行基线与候选,保存原始输出和逐项评分
检查硬门槛、关键分组退化、延迟与费用
人工看新增失败及裁判不确定项
灰度上线,观察真实业务指标
发现问题则回滚,并将有效样本加入回归
这些步骤可接入任意支持版本化配置的工具。模型、prompt、检索索引、工具 schema、裁判 rubric 和数据集都要记录版本;仅保存“这次 0.86 分”无法复现。调用失败也记录,不能悄悄从分母移除。
具体 CI 门槛如“关键集合全部通过、开放题无明显退化、费用不超预算”是业务决策,不能照抄一个通用裁判分数阈值。评测调用也有费用、并发与数据访问要求,应设独立预算。
错误分类帮助定位,但不是唯一映射
检索缺证据、生成推理错、引用错、格式损坏、过度拒绝、越权分别维护案例。一个回答可能同时有多种错误;通过人工证据替换、禁用记忆、确定性工具替换等对照实验缩小原因,避免见到“幻觉”就只改 prompt。
落地检查
- 定义业务成功和硬失败,程序检查优先。
- 小集合起步,分开发、回归与保留集。
- 裁判与人工校准,严重错误单独统计。
- 固定版本,重复关键实验,报告样本量与波动。
- CI 保留逐用例差异,灰度和回滚一起设计。
- 坏案例依法留存和更新,线上指标验证代表性。
参考资料
正文中的编号可跳转至对应来源。工程报告、官方文档与研究论文分别标注;支撑范围说明该资料能证明什么,以及不能推导什么。
- [1]官方文档OpenAI — Evaluation best practices
支撑范围: 数据集、grader、持续评测与偏差校准建议;人工与程序检查仍不可省略。
- [2]工程报告Anthropic — Multi-agent research system
支撑范围: 研究型多 Agent 的设计、评测与成本经验;报告收益不是所有多 Agent 的定律。
- [3]官方文档Ragas — Metrics
支撑范围: RAG 评测指标的定义与适用问题;指标不能当一对一修复指令。
- [4]研究论文Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena
支撑范围: LLM-as-a-judge 的位置、冗长等偏差与评测研究;一致率不代表裁判无偏。
- [5]工程报告Anthropic — Demystifying evals for AI agents
支撑范围: 任务、试验轨迹、结果与 grader 的评测方法;不代替本业务验收标准。
- [6]研究论文τ-bench — Tool-Agent-User Interaction in Real-World Domains
支撑范围: 工具对话后的数据库结果验证与多次一致性评测;论文分数有模型和环境边界。