为什么离线测试仍会漏掉回归
Eval 集通常来自已知场景，而生产环境会不断出现新的语言、文件、账户配置、工作流和边界条件。模型升级可能提高平均分，却破坏一个关键客户依赖的细分任务。
用户也会感知离线指标没有覆盖的质量：语气是否可信、格式能否进入下一步、答案是否考虑真实约束、Agent 是否在正确时机确认。客户反馈是生产 Eval 的发现机制，而不是 Eval 的替代品。
回归不是“新版本分数更低”，而是某个原本可用的客户结果，在变更后变得不可用。
为所有可能改变行为的部分加版本
- 基础模型、路由策略与推理参数。
- System Prompt、任务 Prompt 和模板。
- 检索索引、Embedding、切块和过滤规则。
- 工具 Schema、权限与外部 API 版本。
- Agent 工作流、发布版本与实验分组。
反馈记录必须保存当时实际使用的版本，而不是当前配置。否则配置更新后，历史报告将无法解释。
什么样的客户信号最像回归
- “更新前还能用”或“最近开始出错”。
- 相似抱怨集中在一个 Release、模型或 Prompt。
- 特定工作流的点踩率或人工接管率突然变化。
- 高价值账户重复报告相同输出差异。
- 支持团队发现新的手动替代步骤。
单条评论不是结论，但它可以成为切分数据的线索。围绕版本、用户群和任务检查是否存在一致变化。
一套从反馈到调查的回归发现流程
- 在反馈时绑定 Response ID、Trace ID 和完整版本信息。
- 追问用户预期、受阻任务与影响。
- 把相似反馈按版本、工作流、用户群和时间聚类。
- 比较变更前后的报告率、成功行为和离线 Eval。
- 抽取代表案例，在旧版本与新版本上重放。
- 确认回归后分配负责人，并记录临时缓解措施。
根据暴露和业务影响排序
不是所有回归都要回滚。评估受影响用户数、账户价值、严重程度、可用替代方案、扩散速度和证据置信度。一个只影响少量边缘格式的退化，与阻断核心付费工作流的退化需要不同响应。
同时检查收益面：某次变更可能改善主要工作流，却损害少数用户群。保留分项指标，避免平均值掩盖取舍。
验证恢复，而不是只验证发布
- 让代表案例通过回归 Eval。
- 检查受影响 Cohort 的点踩、重试与完成率。
- 确认新 Trace 使用了预期版本和路径。
- 邀请报告用户验证真实工作流。
- 观察修复后是否继续出现同类反馈。
把已确认的客户案例永久加入 Eval，未来每次发布前重放。这样，用户指出的问题会逐步变成产品的质量护栏。