AI Shadow Mode：影子模式与反事实评估架构
Shadow mode 不是“悄悄上线看看效果”, 而是在真实业务上下文中运行 AI, 同时不让它影响客户、员工动作、系统状态或监管承诺。它的价值在于暴露离线测试看不到的问题: 输入分布、流程噪声、工具调用失败、结果延迟、人工行为、队列压力、边界越权和证据缺口。
AI 影子模式架构：Shadow Mode / Counterfactual Evaluation / Silent Launch
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_SHADOW_MODE_COUNTERFACTUAL_EVALUATION_SILENT_LAUNCH_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
Source Anchors
| Source | Link | 本文使用方式 |
|---|---|---|
| NIST AI Risk Management Framework | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 组织 shadow mode 的风险识别、评估、处置和证据语言。 |
| NIST AI RMF Resources and TEVV | https://www.nist.gov/itl/ai-risk-management-framework/ai-risk-management-framework-resources | 用 test, evaluation, verification and validation 思维支持 counterfactual evaluation、measurement 和 independent challenge。 |
| ISO/IEC 42001 | https://www.iso.org/standard/81230.html | 用 AI management system 的 operation、performance evaluation、continual improvement 语境组织 operating model。 |
| ISO/IEC 23894 | https://www.iso.org/standard/77304.html | 用 AI risk management vocabulary 支撑 risk identification、risk treatment 和 monitoring。 |
| Google Rules of Machine Learning | https://developers.google.com/machine-learning/guides/rules-of-ml | 参考 ML 系统工程中的上线前检查、监控、数据和训练/服务一致性原则。 |
| DORA metrics | https://dora.dev/ | 作为 delivery reliability、change quality、rollback/restore thinking 的工程治理锚点, 不把 shadow mode 简化为发布速度指标。 |
| OpenTelemetry docs | https://opentelemetry.io/docs/ | 作为 trace、metric、log、context propagation 的可观测性锚点, 支撑 event-to-outcome 追踪。 |
核心导读
Shadow mode 不是“悄悄上线看看效果”, 而是在真实业务上下文中运行 AI, 同时不让它影响客户、员工动作、系统状态或监管承诺。它的价值在于暴露离线测试看不到的问题: 输入分布、流程噪声、工具调用失败、结果延迟、人工行为、队列压力、边界越权和证据缺口。
成熟的 shadow mode 要回答的不只是“新模型比旧模型准吗”, 而是“如果当时采用 AI 的建议, 会发生什么; 证据是否足以支持受控放量; 哪些场景必须继续限制; 哪些风险在静默运行时已经出现”。这需要反事实日志、结果对齐、泄漏控制和发布门禁共同设计。
问题定义
离线评估通常使用标注集、历史数据或 synthetic case, 但生产环境中的 AI 风险来自动态系统:
- 真实输入比测试集更脏、更长、更含糊, 并且经常跨越政策边界。
- 上游系统字段缺失、延迟或语义变化会影响模型行为。
- AI 结果如果呈现给人, 会改变人的行动, 因而污染对照。
- 许多业务结果延迟出现, 例如贷后表现、投诉、复核结果、欺诈损失。
- 工具调用、检索、权限和策略在生产环境中可能与实验环境不一致。
- 用户和员工的工作流限制会让高分模型无法创造价值。
Shadow mode 的目标是在不造成真实影响的前提下, 观察 AI 在真实上下文中的行为。它不是发布仪式, 而是 evidence generation architecture。
核心原理/方法
Traffic mirroring without influence 将真实业务请求、上下文和必要状态复制给 shadow 系统, 但 shadow 输出不进入客户界面、员工任务、决策系统或下游状态。任何被人看到并可能影响行为的输出, 都不再是纯 shadow。
Counterfactual decision object shadow 系统必须生成结构化决策对象, 记录如果它有权行动会做什么: 建议、置信状态、证据、工具调用、拒绝理由、升级条件、替代方案和禁止动作。自然语言输出不足以支持反事实评估。
Outcome joining shadow 决策要和真实流程的后续结果连接: 人工最终动作、质检结果、客户反馈、风险损失、投诉、返工、收入、队列变化。没有 outcome join, shadow 只能评估输出相似性, 不能评估业务影响。
Leakage control shadow 结果不能影响生产行为, 否则对照被污染。泄漏可能发生在界面、日志、通知、数据回写、人工抽样、主管查看、模型训练反馈和运营会议中。需要明确隔离边界。
Gate-based rollout shadow 不是自动通向全量发布。它应产生通过、限制、重测、扩大样本、调整策略或停止的证据。不同风险场景需要不同门槛。
系统/架构模型
参考架构
Production request / event
-> Mirror and context capture
-> Shadow feature builder
-> Shadow model / agent / rules
-> Counterfactual decision store
-> Production outcome joiner
-> Evaluation and risk analysis
-> Gate decision
-> Limited rollout / redesign / stop
核心组件
| 组件 | 职责 | 设计要求 |
|---|---|---|
| Mirror gateway | 复制生产请求和上下文给 shadow 系统 | 不影响生产延迟和状态 |
| Context snapshot service | 保存当时可见的数据、权限、规则和知识版本 | 支持重放和训练/服务一致性检查 |
| Shadow runtime | 运行候选模型、agent、RAG 或策略 | 与生产隔离, 输出不可见且不可执行 |
| Counterfactual decision store | 保存候选建议、行动、证据和禁用原因 | 结构化, 可查询, 可连接结果 |
| Leakage guard | 防止 shadow 输出进入界面、任务、告警或下游系统 | 包括权限、网络、日志和数据回写控制 |
| Outcome joiner | 将 shadow 决策与真实后续结果对齐 | 处理延迟、缺失、多个结果和主键映射 |
| Evaluation engine | 计算准确性、价值、风险、公平性、稳定性和运营影响 | 输出分层结果, 不只看总体均值 |
| Gate board evidence pack | 汇总发布门禁所需证据 | 支持继续、限制、回滚或停止 |
| Rollout controller | 从 shadow 切换到小流量、人工可见、建议可采纳或自动化 | 每一步都有独立阈值和回滚条件 |
Counterfactual decision object
shadow_decision_id: sh-aml-2026-0001
production_event_id: prod-alert-77821
context_snapshot:
data_version: aml-features-2026-06-30
policy_version: aml-policy-v14
knowledge_version: typology-kg-v8
shadow_runtime:
model_version: aml-triage-candidate-v3
prompt_version: triage-prompt-v11
decision:
recommended_priority: high
recommended_action: investigator_review
rationale_codes: [new_counterparty_pattern, structuring_signal]
uncertainty: medium
escalation_required: true
prohibited_effects:
visible_to_user: false
visible_to_operator: false
state_change: false
outcome_links:
production_decision_id: prod-decision-882
qa_result_id: pending
customer_outcome_id: pending
关键机制与取舍
真实度 vs 隔离度 越接近生产, 越能暴露真实问题; 隔离越强, 越能保护客户和对照。可行模式是复制真实输入和上下文, 但严格隔离输出、工具副作用和人工可见性。涉及外部系统写操作的工具必须 mock 或只读。
静默运行 vs 员工可见试点 纯 shadow 不影响行为, 适合评估候选系统本身。员工可见试点能评估人机协作, 但不再是无污染反事实, 需要新的对照设计。两者不要混为一个阶段。
总体指标 vs 分层风险 总体准确率可能掩盖高风险子群、复杂案例、边界样本和低置信场景。发布门禁应按任务类型、客户群、渠道、风险等级、数据完整性和时间窗口分层。
结果延迟 vs 发布速度 欺诈损失、贷后表现、投诉和客户留存可能延迟出现。若业务结果需要 60 天才稳定, 7 天 shadow 只能证明运行可靠和短期 proxy, 不能证明最终价值。可以用分层门槛: 短期运行门槛、长期结果门槛、持续监控门槛。
反事实评估 vs 因果推断 shadow 只能告诉我们 AI 会建议什么, 以及这些建议和真实结果如何相关。它不能自动证明“如果采用 AI, 结果一定更好”, 因为人和系统行为会改变。高影响发布仍需要受控试点或实验设计。
成本与覆盖 全量 mirror 会增加计算、存储和隐私压力。可以按风险、业务量、边界场景和代表性采样, 但采样策略必须记录, 否则评估会偏向容易处理的样本。
证据与控制
发布门禁
| 门禁层 | 关注点 | 证据 |
|---|---|---|
| Technical parity | shadow runtime 与目标生产配置一致 | 配置 diff、版本记录、服务延迟、失败率 |
| Data readiness | 输入数据质量、权限和特征一致性 | 缺失率、延迟、训练/服务一致性报告 |
| Decision quality | 候选建议与标注、人工结果或业务规则的关系 | 分层准确性、拒绝/升级质量、错误样本 |
| Risk controls | 越界、偏差、幻觉、工具误用和安全控制 | red-team case、policy violation、leakage test |
| Operational impact | 若可见或可采纳, 对队列、复核和 SLA 的影响 | capacity simulation、review load、fallback plan |
| Outcome evidence | 与真实后续结果的连接和证据强度 | outcome join rate、delay handling、proxy validity |
| Rollout readiness | 放量、回滚、暂停和监控能力 | rollout plan、kill switch、SLO、alert thresholds |
关键指标
- Shadow coverage: 进入 shadow 的目标流量比例和代表性。
- Decision completeness: 生成完整决策对象的比例。
- Context fidelity: shadow 使用的数据和生产当时可见数据的一致性。
- Leakage incidents: shadow 输出影响生产行为的任何迹象。
- Outcome join rate: shadow 决策能连接到真实结果的比例。
- Disagreement quality: AI 与真实人工/系统决策不一致时, 哪一方更合理。
- High-risk error rate: 高影响场景中的错误建议、漏升级和越界建议。
- Stability: 不同时间、渠道、队列和数据质量下的行为波动。
证据包
shadow 结束后不应只交一张分数表, 而应包含:
- 样本覆盖和采样策略。
- 上下文快照、模型、规则、知识和工具版本。
- 决策对象完整性和泄漏控制测试。
- 分层结果、错误样本和边界样本分析。
- outcome join 方法、延迟结果处理和无法评估的盲区。
- 与现有流程的差异、潜在运营负荷和人工复核影响。
- 推荐的 rollout 范围、限制条件、监控指标和停止条件。
金融零售/AI产品场景
信用额度管理 候选模型可在 shadow 中对真实账户生成额度调整建议, 但不得影响额度、客户通知或员工任务。评估要连接后续逾期、使用率、投诉、客户流失和人工策略差异。短期 proxy 不足以替代贷后结果。
AML alert triage AI 可以 shadow 排序警报和建议调查路径。关键是评估漏升高风险警报、误降优先级、typology 覆盖、调查员最终动作和质检结果。结果延迟和标注噪声要明确处理。
KYC onboarding shadow 系统可判断材料缺失、风险等级和下一步请求。评估要看与人工处理差异、补件成功、客户放弃、异常升级和政策例外。输出不能影响客户补件通知。
Payment fraud intervention 欺诈拦截场景对时效敏感。shadow 可以生成拦截/放行建议, 但真正损失和误拦影响可能滞后。需要高风险错误优先于总体准确率。
Collections contact strategy AI 可 shadow 推荐联系时间、渠道和话术风险。评估不能只看回款概率, 还要看客户脆弱性、投诉、禁止联系规则和长期关系影响。
Agent assist silent launch 客服助手可先在 shadow 中生成回复草稿, 不展示给坐席。该阶段评估草稿质量和政策引用; 一旦展示给坐席, 就进入人机协作试点, 需要重新设计对照。
反模式
| 反模式 | 风险 | 替代做法 |
|---|---|---|
| 把 shadow 输出给运营人员看 | 人的行为被影响, 反事实失效 | 纯 shadow 与可见试点分阶段 |
| 只比较模型分数 | 忽略流程、工具、结果和风险 | 连接 decision object 与 outcome |
| 没有泄漏测试 | 输出可能通过日志、告警或回写影响生产 | leakage guard 和隔离审计 |
| 样本只选简单案例 | 发布后复杂场景失效 | 风险分层采样和边界样本覆盖 |
| 结果未成熟就全量发布 | 长期损失、投诉或贷后风险未显现 | 短期 gate + 长期 outcome gate |
| 不记录上下文版本 | 事后无法解释差异 | context snapshot 和版本化 |
| shadow 通过后直接自动化 | 跳过人机协作、容量和控制验证 | shadow -> visible assist -> limited action -> automation |
最终心智模型
Shadow mode 的成熟度不在于它有多“静默”, 而在于它能否用真实上下文生成可重放的反事实证据, 并证明候选系统在数据、工具、流程、风险和运营约束下具备受控放量条件。
正确问题不是“shadow 分数是否高于旧模型”, 而是“如果 AI 的建议进入真实流程, 哪些客户、任务和控制会被影响; 现有证据支持到什么自动化深度; 哪些场景仍需要限制、人工复核或继续观察”。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。