AI 工作流上线前怎么做影子运行？先让真实流量验证它

本文目录

AI 工作流通过离线测试后，团队常会面临一个尴尬的选择：继续用测试集，担心覆盖不了真实情况；直接开放给用户，又担心第一批错误已经影响业务。

影子运行提供了一个中间阶段。现有流程继续处理真实请求，候选 AI 工作流同步接收一份输入副本并产出结果，但它的结果不返回给用户，也不能写入业务系统。团队先观察它在真实任务分布中的表现，再决定是否进入小流量灰度。

这里的“真实输入”仅限已经获得授权、且候选环境有权处理的数据。未经业务、数据与隐私责任人确认，不应复制完整生产流量，也不应把含有个人信息、客户资料或受限内容的输入发送给外部模型或服务。

它的价值不是“多跑一遍模型”，而是在不转移业务责任的前提下，验证离线测试中的判断能否在真实环境成立。

影子运行和灰度发布有什么不同

两者都会让候选版本接触真实输入，但承担的后果不同：

阶段	候选版本接收真实输入	结果影响用户或业务	主要目的
离线回放	是，通常来自历史样本	否	快速回归和调试
影子运行	是，来自当前流量副本	否	验证真实分布、稳定性和成本
小流量灰度	是	是，仅限受控范围	验证真实使用效果和运营流程

Google SRE 关于 Canary Release 的章节把复制生产流量给测试部署、丢弃候选响应的方式称为 traffic teeing（流量镜像）。它能提供更具代表性的输入，也提醒团队注意状态共享带来的干扰。影子运行可以借用这个工程思路，但需要进一步处理 AI 工作流里的知识检索、工具调用和敏感数据。

第一步：先写清这次要证明什么

先看一个常见问题。

如果目标只是”看看新版本表现如何”，影子运行很容易积累大量日志，却得不出上线结论。开始前应明确验证问题和退出条件。

可以从三类问题中选择：

• 任务质量：分类、字段提取、引用和草稿是否达到业务要求；
• 运行表现：高峰时段的时延、超时、重试和调用成本是否可接受；
• 风险控制：资料不足时是否拒答，越权请求是否被拦截，高后果动作是否进入审批。

退出条件应与首次上线验收使用同一套核心指标，避免测试阶段和生产阶段各自定义“成功”。站内的AI 工作流验收框架提供了业务结果、任务质量、运行效率和风险控制四层指标。

不要预先套用通用正确率或固定运行天数。更重要的是：主要任务类型和关键边界是否已经出现，高后果样本是否完成复核，剩余错误是否有明确处置方式。

第二步：选择有代表性的流量

先破除一个常见误解。

影子运行不等于复制全部生产流量。第一版可以按业务类型、用户范围、时间窗口或风险等级选择样本，确保常见任务和重要边界都有覆盖。

复制前要回答：

• 候选环境是否有权处理这些数据；
• 哪些个人信息和敏感字段可以删除或替换；
• 输入、输出和检索材料保留多久；
• 谁可以查看对照结果；
• 外部模型或服务是否满足当前数据要求。

如果脱敏会改变任务含义，例如删除的字段正是分类依据，就不能一边破坏输入，一边声称结果代表真实效果。此时应缩小参与用户范围、使用符合要求的处理环境，或继续使用经过授权的历史回放。

第三步：彻底切断副作用

这是最核心的安全约束。

影子版本最重要的技术约束，是可以计算，不能行动。不要只在提示词里告诉模型”不要真的发送”，而要在系统层切断写入和外发路径。

至少采用这些控制：

• 使用独立的只读服务账号和最小数据权限；
• 将创建工单、发送邮件、修改记录等工具替换为模拟实现；
• 把候选结果写入独立的评测存储，不进入生产消息队列；
• 对外部链接、Webhook 和通知通道设置白名单或直接禁用；
• 限制单次任务的步骤、重试、并发和预算；
• 用明显的环境标识防止人工把影子结果误当成正式结果。

候选系统也不应和生产系统共享会被它改变的缓存、会话或中间状态。Google SRE 在讨论 traffic teeing 时特别指出，共享缓存可能让候选流量反过来影响生产测量。对 AI 工作流而言，共享对话记忆、知识索引写入队列或任务状态表也会产生类似问题。

对于必须执行后才能判断效果的任务，例如真正发送后才知道客户是否回复，影子运行只能验证执行前的计划、参数和审批路径，不能替代小流量灰度。

第四步：让新旧结果可以逐条对照

对照的前提是可追溯。

每个被复制的任务都要有统一追踪 ID，并记录完整版本组合：

• 输入及其业务类型；
• 正式流程的结果和处理状态；
• 候选模型、提示词、知识库和工具版本；
• 检索到的证据与候选工具调用；
• 端到端时延、重试和资源消耗；
• 自动规则与人工复核结论。

没有版本记录时，团队只能发现“这一批结果不一样”，却无法判断差异来自模型、提示词还是知识库更新。关于如何把这些组件作为一个可回滚组合管理，可以参考AI 工作流变更管理。

对照也不应只比较最终文字是否相同。开放式回答可以措辞不同但结论一致，也可能文字相似却引用了错误依据。应按任务节点选择比较方法：

任务	优先比较的内容
分类	类别、置信条件和严重漏判
字段提取	必填字段、格式和来源位置
知识检索	关键证据是否召回、权限是否正确
回复草稿	事实支持、限制条件和人工改写量
工具计划	工具、参数、权限和是否需要审批

第五步：把人工复核放在最有价值的位置

自动指标有它的边界。

自动指标适合检查结构、延迟和确定性规则，但业务可接受性仍需要领域人员抽样判断。复核样本应同时包含：

• 新旧版本结论不一致的任务；
• 候选版本自行拒答或升级人工的任务；
• 涉及敏感数据和高后果动作的任务；
• 随机抽取的一般任务，避免只看异常；
• 生产流程后来被人工纠正的任务。

复核时尽量隐藏版本身份，先按统一评分规则判断结果，再查看它来自正式流程还是候选版本。这样能减少“新模型应该更好”或“旧流程更可靠”的先入判断。

NIST AI RMF Core在 Measure 2.3 中提出，应在接近部署条件的环境中衡量系统表现；Measure 4.2 则强调结合领域专家和相关使用者的意见验证结果。影子运行正好能把真实输入与领域复核放到同一个验证阶段，但它仍然是企业自定义的工程方法，不是 NIST 规定的固定流程。

影子运行结束后只有三种决定

结果不应自动导向上线。完成预定覆盖后，团队应明确选择：

1. 进入小流量灰度：关键场景已覆盖，没有未解决的严重错误，监控、人工接管和回滚已准备好；
2. 继续影子运行：主要证据仍不足，或某些边界样本尚未出现；
3. 停止并修正：发现系统性错误、成本不可接受、权限设计有缺口，或当前方案没有优于原流程。

进入灰度也不意味着立刻取消人工确认。对外发送、资金变化、权限修改和不可逆写入仍应按动作后果设置审批，具体可参考人工确认点设计。

一份最小执行清单

开始影子运行前，至少确认：

• 验证问题、指标、样本覆盖和退出条件已写明；
• 流量复制范围与数据权限已经审批；
• 候选版本使用只读身份，所有写工具均被替换或禁用；
• 正式与影子环境不共享可变状态；
• 每个任务能关联新旧结果、组件版本和人工结论；
• 高风险样本、差异样本和随机样本都有复核安排；
• 进入灰度、继续观察和停止修正的负责人已经明确。

影子运行不能证明 AI 工作流永远不会出错，也不能代替真实用户反馈。它解决的是更具体的问题：在系统第一次影响业务之前，先让团队看到它面对真实输入时会怎样判断、会在哪里失败，以及这些失败是否已经可以被发现和接管。