CD4ML / MLOps 与 AI 连续交付

配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是 docs/AI_MLOPS_CONTINUOUS_DELIVERY_RELEASE_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。 本篇为经典论文精读（历史回顾/经典打底定位），机制正文以原文（CD4ML, martinfowler.com, 2019-09）为锚点；最新进展见文末「SOTA 检查」。

Source Anchors

核心导读

CD4ML 的核心不是把模型训练自动化，而是让 AI 系统在 code、data、model、prompt、knowledge、policy、threshold 和 evaluator 都会变化的情况下，仍然可复现、可验证、可审计、可回滚地发布。AI 发布的难点在于多 artifact 共同决定系统行为。

欺诈阈值、信贷策略、RAG 知识库、客服话术、Agent 工具权限、vendor model 版本和监控门槛都可能改变客户影响。CD4ML 的架构价值是一套 release engineering 思维：每次发布都必须有版本化发布包、分层门禁、shadow / canary / ramp、生产监控和明确的停止规则。

核心问题

传统软件发布主要关注代码。AI 发布不是这样。一个 AI 系统的行为通常由多种 artifact 共同决定。欺诈系统的行为来自服务代码、特征管道、模型版本、阈值、规则、队列策略、客户通知模板和人工处理 SOP。客服 RAG 的行为来自模型、system prompt、知识库、文档版本、chunking、embedding、index、reranker、引用策略、拒答策略和监控阈值。agent 系统的行为来自模型、工具权限、工作流、记忆、审批点、交易上限、重试策略和安全拦截。如果只把“模型文件部署成功”当发布完成，AI 系统很快会陷入三种状态。第一，不可复现。离线评测用的是某个 prompt 和 eval set，生产用的是另一个 prompt 和更新后的知识库。第二，不可回滚。事故发生后只回滚模型，阈值、知识索引、policy router 和供应商版本仍停在新状态。第三，不可审计。半年后无法说明某个客户收到的 AI 回答对应哪个模型、哪个文档版本、哪个 prompt 和哪个上线批准。CD4ML 要解决的核心问题是：如何把 AI 发布从单点部署改造成多 artifact、多风险、多团队的连续交付系统。

方法贡献

Continuous Delivery for Machine Learning 的核心贡献是指出 ML 系统的交付必须同时处理 code、data 和 model。代码可以通过 CI/CD 管理。数据需要 schema、quality、drift 和 lineage 验证。模型需要训练、评估、比较、注册、部署和监控。这三者任何一个变化，都可能改变生产行为。GenAI 和 agent 系统让这个问题继续扩大。除了 code、data、model，还要管理 prompt、knowledge base、retriever、embedding、tool permissions、guardrails、eval rubric、LLM judge、cost routing、memory policy 和 human handoff。因此，现代 CD4ML 可以扩展为：

continuous integration for code
continuous validation for data and knowledge
continuous evaluation for model / prompt / policy behavior
continuous delivery for versioned release bundles
continuous monitoring for production quality, risk, cost and drift

这套方法的贡献不只是自动化，而是把“上线判断”从主观感觉变成可执行证据链。

机制原理：三轴变更多轴化

经典 CD4ML 强调三轴变更：

code changes
data changes
model changes

金融零售 GenAI 系统至少要扩展到更多轴：

code
data
model
prompt
knowledge source
retriever and index
feature and threshold
policy and guardrail
tool permission
evaluator and rubric
human workflow
monitoring trigger
vendor version

每一轴都可能独立变化。业务更新收费政策，不需要改模型，却会改变 RAG 答案。风险团队调整欺诈阈值，不需要重新训练，却会改变客户摩擦和人工队列。供应商升级 LLM，不需要团队提交代码，却会改变摘要风格、拒答率和成本。合规更新禁用话术，不需要重建知识库，却会改变 prompt、policy 和 eval rubric。多轴变化的管理原则是：生产行为由一组 artifact 决定，因此发布也必须以一组 artifact 为单位。这就是 release bundle。

Release Bundle：AI 发布的最小可审计单位

release bundle 是 CD4ML 在 AI 系统中的关键概念。它回答一个问题：这次发布到底把什么组合推到了生产。一个完整的 release bundle 可以包含：

没有 release bundle，就没有真正的可复现。事故发生时，团队必须能重建：

• 当时系统接收到什么输入。
• 用了哪个模型和 prompt。
• 检索了哪个文档版本。
• 哪些规则和阈值生效。
• 哪些 eval 和审批支持上线。
• 哪些监控阈值应该触发告警。

release bundle 也是回滚单位。回滚不应只回滚模型。RAG 事故可能需要回滚 index、prompt 和 citation policy。欺诈事故可能需要回滚阈值、规则和队列策略。agent 事故可能需要禁用工具权限、回滚 prompt 和启用人工审批点。

Pipeline：从变更到生产的证据链

CD4ML pipeline 的目的不是让每个步骤看起来自动化，而是让每个步骤都能生成下一步需要的证据。

source control
  -> data and knowledge validation
  -> feature / prompt / policy validation
  -> training or model selection
  -> offline evaluation
  -> segment, safety and robustness evaluation
  -> release bundle build
  -> risk and architecture approval
  -> staging and shadow
  -> canary and ramp
  -> production monitoring
  -> rollback, retrain or recalibrate

pipeline 中每个环节都应有失败动作。数据 schema 不匹配时，训练或发布应阻断。知识库 freshness 不满足要求时，RAG 不应发布。offline eval 未通过 critical threshold 时，不能进入 canary。关键 segment 表现下降时，应缩小范围或回到人工路径。shadow mode 发现输出与 champion 差异过大时，不应影响客户。canary 中投诉、override、延迟、成本或高风险错误超阈值时，应自动暂停或回滚。因此，CD4ML 的 pipeline 是 release governance 的执行层。

Continuous Training 不等于自动上线

很多团队把 continuous training 理解成“新数据来了就训练，新模型好了就上线”。这在高风险金融场景是危险的。更合理的分解是：

new data
  -> validate data
  -> retrain candidate
  -> compare with champion
  -> evaluate critical segments
  -> run safety / fairness / robustness checks
  -> shadow or canary
  -> approve, hold or reject

训练可以自动化。评估可以高度自动化。候选模型推荐可以自动化。但生产发布不一定应该自动化。越接近客户权益、资金、信贷、合规、账户访问和正式沟通，越需要明确的人类批准、残余风险接受和可回滚计划。这并不反对自动化。它只是把自动化放在正确边界内。低风险内部分类器可以接近自动发布。中风险员工 Copilot 可以自动评估、人工批准、灰度发布。高风险信贷、欺诈、AML、KYC 和客户可见 RAG 需要更强门禁。

Release Gate：从模型指标到上线决策

AI release gate 不能只有 accuracy。它要覆盖数据、系统、风险、业务和运营。

上线决策也应该更精细。

approve internal pilot
approve shadow
approve limited ramp
approve with added controls
hold pending remediation
rollback to prior bundle
retire candidate

这种语言让业务、风险、工程和运营能围绕同一组证据讨论。

Shadow、Canary、Ramp 的系统边界

shadow、canary 和 ramp 是 CD4ML 中非常重要的生产验证方式。shadow mode 让新模型或新策略接收真实请求，但不影响生产结果。它适合信贷、欺诈、AML、投诉和高风险客服场景的早期验证。shadow 的价值是观察真实分布下的差异，而不让客户承担风险。canary 让一小部分真实流量使用新版本。它必须有明确 stop rule 和快速 rollback。没有 stop rule 的 canary 只是小规模冒险。ramp 是分阶段扩大范围。每个阶段都需要检查质量、风险、成本、延迟、投诉、人工负载和 segment 表现。champion-challenger 是金融风控常见模式。champion 是当前生产策略，challenger 是候选策略。它适合比较模型、阈值、规则、RAG 策略和 agent workflow。但对客户有高影响的 challenger 不应直接自动决策，可以先只给人审建议或影子评分。

生产监控：发布之后才真正开始

AI 系统发布不是结束，而是进入运行风险。生产监控至少要覆盖以下层次：

监控要连接动作。指标只展示不触发行动，不能算有效控制。例如：

• prohibited claim rate 超阈值，暂停客户可见生成。
• high-risk escalation recall 下降，增加人工复核并冻结 ramp。
• RAG citation precision 下降，回滚 index 或禁止回答特定意图。
• fraud false positive complaint 上升，回滚阈值并启动 incident review。
• vendor latency 上升，切换 fallback model 或降级功能。

CD4ML 的生产监控不是只服务 SRE。它同时服务产品、风险、运营和管理评审。

为什么有效

CD4ML 有效，是因为它把 AI 系统的不确定性放进可重复的工程流程。AI 的不确定性不会消失。数据会漂移，模型会更新，用户会改变行为，知识库会过期，供应商会升级，业务政策会变化。CD4ML 不假设系统永远稳定。它假设系统会变化，并要求每次变化都被版本化、评估、批准、监控和可回滚。它还把“上线质量”从模型团队的局部指标，扩展为跨团队证据。模型团队提供 eval 和 drift。数据团队提供 lineage 和 quality。产品团队提供任务成功和用户控制。风险团队提供残余风险和控制要求。运营团队提供人工队列和异常处理能力。架构团队提供系统边界、发布包和回滚能力。因此，CD4ML 是工程方法，也是组织协作机制。

局限和误用

第一类误用是 pipeline 崇拜。有 CI/CD 工具、model registry 和 dashboard，不等于具备 CD4ML。如果发布包不完整、门禁不反映风险、监控不触发行动，工具只是外壳。第二类误用是过度自动发布。低风险系统可以高度自动化，高风险金融 AI 不能把 continuous training 直接接到生产。第三类误用是只版本模型。GenAI 系统中 prompt、knowledge、index、policy 和 evaluator 改动往往比模型改动更频繁。只记录 model version 会让事故复盘失真。第四类误用是 eval set 污染。如果开发反复针对同一 golden set 调 prompt，指标会虚高。eval 需要版本治理、holdout、edge case 和生产抽样反馈。第五类误用是 shadow 数据误读。shadow 不影响客户，因此某些客户行为反馈不会出现。canary 和 pilot 才能观察真实交互，但必须控制范围和风险。第六类误用是没有回滚演练。写了 rollback plan 不代表系统能回滚。高风险能力应定期验证回滚包是否真的能恢复上一版本行为。

架构和产品价值

CD4ML 给 AI 架构的价值是定义 release boundary。它要求团队明确：什么是一组可以一起发布、验证、监控和回滚的系统行为。对产品而言，它把“功能上线”改成“受控能力进入生产”。一个客户服务 RAG 的功能完成，不代表能全量上线。它可能先进入内部 shadow，再给客服员工辅助，再给低风险 FAQ 客户可见，再逐步扩展到复杂服务场景。对架构而言，平台需要支持：

• source control。
• dataset registry。
• model registry。
• prompt registry。
• knowledge registry。
• feature store。
• eval service。
• release bundle builder。
• approval workflow。
• deployment controller。
• observability。
• evidence binder。
• rollback controller。

典型结构可以表示为：

git / registry / data catalog / prompt registry
  -> pipeline orchestrator
  -> validation and eval services
  -> release bundle builder
  -> approval and evidence workflow
  -> deployment controller
  -> shadow / canary / ramp
  -> monitoring and incident system
  -> rollback / retrain / recalibrate

成熟平台的目标不是把所有团队限制在同一种模型，而是让不同模型和 AI pattern 都遵循一致的发布证据和风险边界。

金融零售系统案例

客服 RAG 发布

客服 RAG 的一次发布可能只是更新政策文档。但生产行为可能大幅变化。新的费用政策文档、chunking、index、embedding、reranker、system prompt 和引用格式共同决定答案。CD4ML 发布包应绑定这些 artifact。上线前需要跑 policy freshness eval、citation precision、unsupported answer、high-risk intent refusal、language tone 和 latency。上线方式可以是：

internal staff shadow
  -> low-risk FAQ canary
  -> limited customer ramp
  -> full rollout for approved intents

stop rule 包括 unsupported claim、旧政策引用、投诉上升、人工升级命中率下降、延迟或成本超阈值。

欺诈模型升级

欺诈模型升级不应只比较 AUC。发布包应包含 feature version、model version、score calibration、threshold policy、rule interaction、queue capacity、customer notification 和 rollback threshold。shadow 阶段可以比较 champion 和 challenger 的 score distribution、命中 case、false positive proxy、segment impact 和人工队列压力。canary 可以先从低金额、可逆动作或 step-up authentication 开始。高金额冻结、账户限制或高摩擦动作需要更强人工控制和客户影响监控。

AML Alert Triage Copilot

AML Copilot 不直接提交 SAR，但会影响 analyst 判断。CD4ML 发布要评估 critical fact omission、citation precision、observed fact 与 hypothesis 区分、typology recall 和 analyst over-reliance。shadow 阶段让 Copilot 处理真实 case，但只供 QA 比较。pilot 阶段给部分 analyst 使用，同时保留人类最终责任。监控不仅看处理时长，也要看 narrative 质量、reviewer edits、escalation 和 missed signals。

信贷解释助手

信贷解释助手的发布包必须绑定 decision code mapping、policy version、approved wording、model/prompt、禁止话术、adverse action reason eval 和 fairness review。它不能通过“语言自然”证明可上线。上线门禁要验证每条客户解释都能回到真实 underwriting record。如果 policy version 或 reason code mapping 变化，必须触发 regression eval。

Agent 工具权限变更

agent 的一次发布可能只是增加一个工具权限。但这可能从“建议”升级为“执行”。例如内部运营 agent 从查询交易状态扩展到提交退款请求。CD4ML gate 应要求 tool permission review、transaction limit、approval checkpoint、audit log、rollback switch、abuse test 和 human escalation。这类发布不能用普通 prompt 变更处理。

学习验证

读完这一篇后，应能完成以下验证任务：

1. 为客服 RAG 写 release bundle spec，包含 model、prompt、knowledge、index、embedding、reranker、policy、eval 和 monitoring。

2. 为欺诈模型升级设计 shadow / canary / ramp 路线，并说明每一阶段的 stop rule。

3. 设计一个 AI release gate，把 data validation、offline eval、segment gate、human review、shadow、canary 和 monitoring 连接起来。

4. 为信贷解释助手写 regression eval 清单，覆盖 decision code、policy version、approved wording、fairness 和 appeal path。

5. 设计一个 rollback runbook，说明如何同时回滚模型、prompt、knowledge index、threshold、policy 和 monitoring。

6. 判断一个 continuous training pipeline 在什么条件下可以自动发布，什么条件下必须人工批准。

7. 写一个 production monitoring dashboard，覆盖质量、风险、产品、运营、成本和 SLO。

关键结论

CD4ML 的核心是把 AI 发布变成可复现、可验证、可审计、可回滚的系统能力。AI 发布不只是部署模型，而是发布一组共同决定行为的 artifact。金融零售 AI 的发布工程必须处理 code、data、model、prompt、knowledge、policy、threshold、tool permission、eval 和 monitoring 的共同变化。掌握 CD4ML 的标志，不是会说 CI/CD/CT，而是能为一个具体 AI 系统定义 release bundle、门禁、灰度路线、生产监控、停止规则和回滚方案，让 AI 能在持续变化中安全进入生产。

---

SOTA 检查 (2026-07-01)

• CD4ML 原文（2019-09）的框架仍成立，但叙事主线已由 MLOps 扩展为 LLMOps：2026 年主流实践把「code/data/model 三轴」进一步扩展为 prompt 即代码、eval 替代单元测试、幻觉率/RAG 检索质量/token 成本作为一等监控对象、供应商模型切换常态化——这正是本篇「三轴变更多轴化」一节的方向，本篇结论未被替代，而是被行业实践追认。
• 工具层现役标配：MLflow 3.0（2025-06 GA，2026 年已迭代至 3.3.x）把 prompt registry、LLM-as-a-judge scorer、trace 与 eval 血缘原生纳入开源平台；商业侧 Braintrust、Langfuse 等 LLMOps 评测/可观测平台在 2026 年对比评测中已成独立品类。本篇「架构和产品价值」列出的 prompt registry / eval service / evidence binder 平台清单与这些现役产品一一对应。
• Eval-gated CI/CD 已从建议变成主流默认：2026 年生产实践把 LLM judge 评分、幻觉交叉验证、JSON schema 校验、champion-challenger 对比直接接入 CI 阻断门禁——本库已有同款落地实现，见 docs/aipa/day19-blocking-ci-eval-gate.md（2026-06，blocking CI eval gate）与 docs/aipa/day76-daily-eval-runner.md（2026-06）。
• 治理锚点需更新引用版本：引用 NIST AI RMF 时应同时引用 GenAI Profile（NIST-AI-600-1，2024-07-26 发布），其新增 12 类 GenAI 特有风险（幻觉、prompt injection、over-reliance 等）直接对应本篇的 knowledge validation 与 human review 门禁；EU AI Act Annex III 高风险义务已推迟至 2027-12-02（Omnibus，2026-05 确认），发布门禁合规时间表按此校准，不要沿用旧的 2026-08 时间线。
• Agent 生产化改变了发布对象的边界：LangChain《State of Agent Engineering》调研（访问日期: 2026-07-01）显示 57.3% 受访组织已有 agent 在生产运行——release bundle 必须覆盖工具权限、审批点与交易上限，印证本篇「Agent 工具权限变更」案例：工具权限变更是发布事件而非配置微调。
• 不随版本过时的框架性结论：release bundle 作为最小可复现/可回滚单位、按风险分层的 release gate、shadow → canary → ramp 的生产验证路径、「监控必须连接动作」——这些抽象与具体工具/模型版本无关，是 2026 年各 LLMOps 平台共同实现的底层模型，也是本篇长期有效的部分。