线上评估与回归

一句话理解：离线评测决定“能不能发”，线上评估决定“发出去之后是不是真的更好”。每一次修改 Prompt、工具、模型、知识库或规则，都要先过回归，再小流量验证，最后才全量。

离线评测集再好，也只是真实世界的一个样本。上线后会出现评测集里没有的工单类型，用户会用意想不到的方式提问，下游系统的数据格式会悄悄变化，模型服务商也可能更新或下线某个模型版本。反过来，没有离线评测就直接上线，等于拿真实用户做实验。

Anthropic 在《Demystifying evals for AI agents》中用“瑞士奶酪模型”来描述这种关系：自动化评测、生产监控、A/B 测试、用户反馈、人工阅读运行记录、系统性的人工研究，每一层都有漏洞，但叠在一起，从一层漏过去的问题会被另一层拦住。这一课把这些层串成一条发布流水线。

离线评估与线上评估各管什么

维度	离线评估	线上评估
数据	固定的评测集	真实流量
标准答案	有，由专家标注	通常没有，或要很久之后才知道
速度	几分钟到几小时，可以每次修改都跑	需要积累足够的流量和时间
风险	不影响用户	问题会直接影响真实用户
擅长发现	已知问题的回归、版本间的对比	新的输入分布、真实的业务效果、评测集没覆盖的失败

两者不是替代关系。OpenAI 的评估最佳实践也建议：每次变更都运行评测，监控应用以发现新的不确定性，并让评测集随时间持续增长。

发布流水线

一次变更从提交到全量，依次经过五道关口：

图 1 · 发布流水线：每道关口都有明确的拦截动作；A/B 实验只在需要验证业务效果时做

不是每次变更都要走完五步。修改一个错别字可能只需要第 1 步；更换模型、改动核心工具，则应该完整走一遍。团队可以按变更的风险等级约定必须经过的步骤。

影子运行要特别注意：客服工单处理 Agent 会创建工单、修改状态，影子版本必须把写操作替换为“只记录、不执行”的空运行，否则同一个问题会被建两张工单。相关设计见不可逆操作。

什么算一次“变更”：Agent 的版本不只是代码

传统软件的版本就是代码版本。Agent 的行为却由很多部分共同决定，其中任何一个变了，都应该视为一次需要回归的变更。建议为每次运行记录一份版本清单（示例）：

agent_release: support-agent 2026.09.17-r2
model:
  provider_model_id: <固定到具体的模型版本号，而不是“最新”别名>
  temperature: 0
instructions: system-prompt v8
tools: support-tools v3.2
skills: [ticket-sop v5]
knowledge_index: sop-docs snapshot 2026-09-15
rules: refund-rules v4
eval_set: support-tickets v1.3

容易被忽略的变更包括：知识库的一次例行更新、工具接口返回里新增的一个字段、业务方修改的一条退款规则，以及模型服务商对某个模型别名指向的版本做了调整。模型尽量固定到具体版本，并关注服务商关于版本更新和下线的通知。

回归检查：怎样判断“没有变坏”

只比较总分是不够的。下面是一份回归对比报告（全部为示例数字）：

基线 v7 与候选 v8 对比
评测集：support-tickets v1.3（100 个任务，每个任务 3 次试验，按多数票判定）

                       v7        v8        变化
任务成功率             87%       90%       +3 个百分点
错误率                  8%        5%       -3 个百分点
单任务成本（元）        0.38      0.44      +16%
P95 延迟（秒）          41        47        +6

逐题翻转
  由失败变为成功        7 个    主要是日志缺失类（新增了超时重试）
  由成功变为失败        4 个    其中 3 个属于“企业客户退款规则”  ← 必须逐条查看

逐题翻转把净增的 3 个百分点拆开来看：

图 2 · 净增 3 个百分点，背后是 7 个变好、4 个变坏

这份报告至少要讨论三件事：

净增 3 个，背后是 7 个变好、4 个变坏。 变坏的 4 个集中在企业客户这一高风险切片，可能是新规则引入了副作用，不能被总分掩盖。
3 个百分点是否显著？ 100 个任务上，这个幅度很可能在噪声范围内。Anthropic 的文章《A statistical approach to model evaluations》建议，比较两个版本时利用同一批题目做配对差异分析，并报告标准误；最实用的做法是像上面这样逐题比较翻转情况。
成本和延迟上升是否可以接受？ 成功率提升需要和单任务成本增加 16% 一起权衡。

此外，回归集里有两类题目应该要求全部通过：已经修复过的历史失败案例（防止旧问题复发），以及安全类案例（越权、注入、未审批写操作）。

线上没有标准答案时，看什么

线上的大多数请求没有专家标注。可以综合以下几类信号：

信号类型	例子	优点	局限
显式反馈	点赞 / 点踩；用户修改了 Agent 的结论	直接	反馈率低，有抱怨的人更愿意反馈
隐式行为	是否采纳处置建议；是否转人工；同一问题是否反复提问；工单是否被重开	覆盖面大	需要谨慎解读含义
业务结果	工单平均关闭时长；错误退款金额；客户投诉量	最接近真实价值	滞后，受很多其他因素影响
在线自动评分	对抽样运行记录运行代码检查与 LLM 评审（不依赖标准答案的维度，例如证据是否可追溯、是否有未审批写操作）	可规模化、较及时	只能评估不需要标准答案的维度
人工抽检	每天抽取一定数量的运行记录由专家复核	质量最高	量有限
运行指标	成本、延迟、工具错误率、升级率	实时	只反映运行状况，不反映结论对错

有一点要特别小心：**用户采纳不等于结论正确。**业务人员很忙时，可能不加核对就采纳 Agent 的建议。采纳率上升，既可能是 Agent 变好了，也可能是用户变得过度信任它。所以采纳率要与人工抽检的准确率一起看。运行指标的看板与告警设计见日志、指标与告警。

A/B 实验在 Agent 场景的注意事项

按用户或团队分流，而不是按请求分流。 同一个人时而用到 v7、时而用到 v8，体验会不一致，数据也会互相干扰。
事先定好主指标、护栏指标和样本量。 不要边看数据边决定什么时候停，否则很容易“看到想看的结果”。
考虑结果的滞后。 工单是否被重开、退款是否出错，可能要一两周后才知道，实验周期要覆盖这段时间。
高风险动作从低风险切片开始。 例如先在只给建议、不自动执行的团队上试验。
护栏指标触发时立即停止。 例如错误退款金额、安全违规数超过预设阈值。

回流：让评测集随产品一起长大

线上发现的每一个失败，都应该有机会变成评测题：

图 3 · 回流闭环：线上发现的失败经过脱敏与标注进入评测集，修复并回归后再发布

这就是持续改进闭环。同时要定期检查评测集的分布是否与线上一致：如果线上出现了评测集里几乎没有的新工单类型，就要补题；如果某类题目的离线成功率很高，线上抽检却经常出错，说明评测集或评分器出了问题。

常见误区

离线分数高就直接全量。 离线评测覆盖不了真实流量的全部分布，缺少灰度就少了一道防线。
只看总分，不看逐题翻转。 净提升掩盖了关键切片上的退化。
不固定模型版本。 使用“最新”别名，服务商调整后行为变化，团队却不知道发生了什么。
线上只看运行指标。 成本和延迟正常，不代表结论正确，需要抽样评审。
灰度期间没有预设回滚阈值。 出问题时临时讨论要不要回滚，损失已经扩大。
线上失败不回流。 同样的问题在下一个版本里再次出现。

产品经理检查清单

Agent 的版本清单是否包含模型版本、指令、工具、Skill、知识库快照、规则与评测集版本？
不同风险等级的变更，分别必须经过流水线中的哪几步？
回归报告是否包含逐题翻转，并要求逐条查看“由成功变为失败”的案例？
历史失败案例与安全类案例是否要求全部通过？
影子运行时，写操作是否被可靠地拦截？
灰度阶段的护栏指标和自动回滚阈值是什么？
线上用哪些信号判断质量？是否有人工抽检？
线上失败从发现到进入评测集，平均需要多久？

练习

客服工单处理 Agent 准备从 prompt v7 升级到 v8，同时把日志查询工具升级到新版本。请用 30–60 分钟写一份发布计划：

列出这次变更涉及的版本清单项。
写出离线回归的门槛，包括总体指标、关键切片和必须全部通过的题目类别。
设计灰度方案：放量节奏、每个阶段观察的指标与持续时间、自动回滚的阈值。
列出上线后两周内要看的线上信号，并说明其中哪个信号可能“误导”你，应该怎样交叉验证。
写出线上失败案例回流评测集的流程和负责人。

下一步

线上评估离不开完整的运行数据。下一个模块「可观测性与成本」从「Tracing」开始，讲怎样记录一次 Agent 运行的每一个模型调用、工具调用、参数、返回与耗时。

线上评估与回归