AI Agent Engineer

AI Agent Engineer

持续评测、供应商漂移与治理

13 min read

持续评测、供应商漂移与治理

本节目标

学会把生产 Trace、用户反馈和供应商状态转成可审计的评测证据；识别供应商/API/行为/价格漂移；为继续、调查、暂停、降级、回滚和人工复核设置清晰边界。

为什么离线评测通过还不够

离线回归集只能代表已经收集和标注的分布。上线后可能出现新任务、节日峰值、标签延迟、工具状态变化、供应商容量问题和从未见过的攻击方式。因此发布不是评测的终点，而是一个新证据窗口的开始。

持续评测（continuous evaluation） 不是“每条线上请求都让另一个模型打分”。它是一套反复运行的闭环：

生产请求与 Trace
  → 按风险和任务分层采样
  → 最小化、脱敏、授权访问
  → 确定性检查 / 人工标注 / 经校准的自动评分
  → 与固定 release、rubric、grader 和策略比较
  → 继续、调查、暂停、降级、回滚或人工复核
  → 经审查的失败样本进入下一版回归集

这条链中任何组件变化，都可能改变分数含义。评分器升级不能与应用升级混在一次比较中，否则无法知道“分数变了”是应用行为还是尺子变化。

五类常见漂移

漂移例子先看什么证据可能动作
API/契约漂移字段、错误码、SDK 或弃用时间线变化合同测试、SDK 锁文件、官方变更记录阻断发布、适配后重测
服务漂移错误率、限流、首 token 或尾延迟变化网关 Metrics、供应商请求 ID、跨 release 对照暂停扩大、切预验降级路径
行为漂移模型名未变但任务/工具选择分布变化固定回归集、Trace 轨迹、人工复核调查、回滚或重新批准
经济漂移价格、缓存计费或重试放大改变价格策略版本、token/缓存/重试台账暂停、重新做成本门
数据与控制面漂移保留能力、数据区域或策略配置变化当前合同、控制面导出、审批记录停止敏感流量、治理复核

“漂移分数”只是线索，不能自己解释根因。比如输出长度变化可能来自 Prompt、用户分布、模型或工具返回；必须与 manifest 差异、时间线和对照组一起看。

线上信号如何进入决策

一个最小观察窗口应绑定：release_id、发布清单完整SHA-256、candidate gate完整SHA-256、观察窗口、样本量、任务/风险切片、Trace 完整性、数据处理策略、质量/安全结果、延迟、费用、供应商错误与降级路径状态。质量、安全和关键切片结果应保留可审计的分子与分母，零分母表示未知而不是零失败；只有率没有计数，无法检查覆盖和聚合是否自洽。短摘要只用于展示；完整摘要才可跨发布门、审计和线上窗口核验，且应进入Trace/受控Log而非Metric label。

决策顺序可采用风险优先级：

  1. 隐私、越权或明确安全失败：停止扩大，必要时回滚或禁用功能；
  2. 任务或高风险切片显著退化：回滚完整 manifest，保留证据；
  3. 供应商错误/行为漂移：只有备选路径已经用同一任务集、工具契约和数据边界验证，且当前 candidate 窗口的样本量、标签/关键切片覆盖、安全检查和新鲜度足以支撑自动动作时，才能降级；否则人工审查或暂停扩大；
  4. 延迟或费用超出策略：暂停扩大，先分解重试、排队、输出长度和缓存；
  5. 样本不足或标签未回流：保持范围并调查，不能把“尚未发现失败”写成成功；
  6. 全部门满足：按预注册阶梯继续，并保留持续观察。

不同信号可能冲突。动作应按风险升级，而不是投票取多数。例如质量正常但脱敏失败，不能因为五个性能指标都好就继续。

反馈不是天然真值

线上反馈常有以下偏差：

  • 只有非常满意或非常不满的用户愿意点击反馈；
  • 任务失败的用户可能直接离开，不会留下标签；
  • “用户复制了答案”不等于答案正确；
  • 退款、人工接管等结果可能几天后才发生；
  • 自动评分器会受 Prompt injection、文风和长度影响；
  • 人工标注者可能对 rubric 理解不一致。

因此要记录标签来源和延迟，按任务/风险切片报告覆盖率，用专家样本校准自动评分器，并定期测量标注一致性。生产样本先进入受控人工分诊，再经去重、脱敏、许可、泄漏检查和最小复现后才可接纳到下一版回归集；不能把全部日志或告警自动变成训练数据或冻结测试。

供应商故障时为什么不能随意换模型

备选模型即使“能力更强”，也可能：

  • 不支持相同结构化输出或工具调用契约；
  • 在同一 Prompt 下采用不同的拒绝和格式行为；
  • 位于不允许的数据区域，或有不同保留条款；
  • token 计数、上下文限制、缓存和费用口径不同；
  • 没通过关键风险切片和副作用工具测试。

正确做法是事先维护 fallback manifest：固定备选供应商/模型、Prompt 适配、工具 schema、数据边界、任务回归集、成本门和批准者。运行时只能切到这个已验证单元。没有安全备选时，清楚地降级为只读、检索结果展示或人工流程，通常比“临时换一个模型”更可靠。

评测治理的最小记录

每次持续评测至少保留：

  • release、数据集、rubric、grader、代码和策略版本；
  • 样本选择条件、覆盖率、排除条件和数据处理依据；
  • 自动与人工评分结果，以及校准/一致性证据；
  • 样本级失败分类、关键切片和不确定性；
  • 决策、理由、审批者、时间与证据指纹；
  • 采取的流量动作、回滚/降级目标和复核时间。

人工审批不是免责按钮。审批者应看到固定 manifest 和证据，系统应记录“批准了什么”，而不是只记录一个人名。

其中“证据指纹”应明确区分：完整SHA-256用于跨系统绑定，短前缀仅用于人读。哈希证明的是被绑定内容未变，不证明内容真实、来源可信、访问已授权或审批已完成。

当前工具与版本提醒

截至 2026-07-22，OpenAI 官方 Evaluation best practices 强调任务特定评测、真实分布、持续评测及用人工反馈校准自动评分。其文档同时标明旧 Evals 平台正在弃用：计划于 2026-10-31 变为只读、2026-11-30 关闭；Graders 文档也说明相关工作流正在弃用。这里的日期是供应商当前公告，不是永久事实，迁移时必须重新检查官方弃用页。

MLflow的当前文档还区分经典ML的mlflow.models.evaluate()/EvaluationMetric与GenAI的mlflow.genai.evaluate()/Scorer，两套对象不可互操作；自动Trace评测当前只支持LLM judge，通常按采样/异步作业运行，也不会自动重评全部历史记录，不能替代确定性检查、人工检查或受控的冻结回归集更新。OpenTelemetry 的 GenAI semantic conventions 已迁移到独立官方仓库。它可以帮助统一 Trace 字段，但字段兼容性仍应通过固定实际修订/schema URL、契约测试和迁移记录管理。不要把观测标准的升级与应用 release 偷偷绑定在一起。

动手实践

使用 离线发布门项目与自测 的 online_observations.json：

  1. 分别运行健康、样本不足、供应商漂移、质量回归和成本退化观察；
  2. 对照脚本输出解释为什么动作不同；
  3. 将供应商漂移案例的 fallback_evidence 改为 null，确认系统从 FALLBACK 降为 HUMAN_REVIEW；再篡改其中一个摘要，确认错绑会作为契约错误被拒绝；
  4. 新增一个质量正常但脱敏失败的观察，验证隐私失败优先；
  5. 为每种动作写出执行者、证据保存和复核时间。

自测

  1. 为什么持续评测不等于对全部线上输出做模型评分？
  2. 为什么更换 grader 后不能直接与旧分数比较？
  3. 模型名没变时，哪些证据仍可支持“行为发生漂移”？
  4. 什么条件满足时才允许自动切换供应商？
  5. 为什么样本不足应产生 investigate，而不是 continue？

掌握检查

  • 能区分 API、服务、行为、经济和数据控制面漂移；
  • 能为一个观察窗口列出版本、样本、质量、安全、性能和数据边界证据；
  • 能解释反馈选择偏差、标签延迟和评分器漂移；
  • 能设计已验证的 fallback manifest 与无备选时的功能降级；
  • 能将持续评测结论写成可审计动作，而不是只有仪表盘分数。

小结与下一步

持续评测的价值不是持续地产生更多分数，而是用固定证据和风险优先级控制线上变化。出现用户影响或无法控制的漂移时，进入 事故响应与持续改进。

参考资料

以下动态资料均核验于 2026-07-22：

Backlinks