第 5 章：AI 工作流

目标

是什么样的系统化框架指导着机器学习系统从开发到生产部署的工程实践？

生产级机器学习系统需要系统性思维和结构化框架。工作流将机器学习开发划分为标准化阶段：数据采集、模型开发、验证与部署。这些结构化流程用于管理数据质量与一致性，协调模型训练与实验，自动化优化管道，并在多环境中编排部署。系统化方法将实验直觉转化为工程纪律，为机器学习系统建立了思维框架。这一基础保障了系统开发的可复现性、质量标准的维护，以及全生命周期内的科学决策。

学习目标

• 对比机器学习生命周期与传统软件开发流程，指出至少三点根本性差异。
• 分析机器学习生命周期的六大核心阶段（从问题定义到维护）及其反馈关系。
• 运用系统思维追踪约束如何在多个生命周期阶段间传递影响。
• 利用具体量化指标，评估模型性能与部署约束之间的权衡。
• 设计兼顾实际部署环境与运维需求的数据采集策略。
• 实现能捕获生产系统多尺度反馈环的监控框架。
• 评估问题定义决策对后续模型开发与部署选择的影响。
• 构建在资源受限环境下兼顾计算效率与性能需求的部署架构。

机器学习开发的系统化框架

在第一部分的基础（系统特性、部署环境、数学框架与架构模式）上，本章将视角从组件级分析提升到系统级工程。理论到实践的转变，需要一套系统化框架来规范生产级机器学习系统的开发。

本章引入机器学习工作流，作为系统化开发的主导方法论。传统软件工程遵循确定性的需求到实现路径，而机器学习系统开发则有本质不同。ML 系统通过迭代实验不断演进：模型从数据中提取模式，性能指标需统计验证，部署约束又反向影响早期开发阶段。这种以实证和数据为中心的方法，要求专门的工作流以适应不确定性、协调并行开发、建立持续改进机制。

本章提出的系统化框架，为理解后续设计原则奠定理论基础。工作流视角阐明了为何需要专门的数据工程管道（第 6 章）、软件框架如何支持迭代开发（第 7 章）、以及模型训练如何融入完整系统生命周期（第 8 章）。没有这一概念支撑，后续技术组件就会显得零散而非有机整体。

本章以糖尿病视网膜病变筛查系统为案例，展示工作流原则如何贯穿从实验室研究到临床部署。案例揭示了数据采集、架构设计、部署约束与运维需求之间的复杂相互作用，这些系统化模式不仅适用于医疗，更体现了可靠 ML 系统工程的普适规律。

理解机器学习生命周期

机器学习生命周期是一套结构化、迭代的流程，指导 ML 系统的开发、评估与持续改进。这一方法融合了系统化实验、评估与适应，在吸收传统开发流程¹ 的基础上，解决了数据驱动系统的独特挑战。

理解生命周期需采用系统思维²，把握四大基本模式：约束传递（一个阶段的决策如何影响全局）、多尺度反馈环（系统如何跨时间尺度自适应）、涌现复杂性（系统整体行为与组件行为的差异）、资源优化（权衡带来的依赖关系）。这些模式贯穿糖尿病视网膜病变案例，为 ML 系统为何需要集成式工程方法提供分析框架。

机器学习生命周期定义

机器学习（ML）生命周期 是一套 结构化、迭代 的流程，定义了 ML 系统 开发、部署与优化 的 关键阶段。涵盖 问题定义、数据采集、模型训练、评估、部署、监控 等 相互关联 的步骤。生命周期强调 反馈环与持续改进，确保系统在 变化需求与真实环境 下依然 健壮、可扩展、响应迅速。图 1 以两条并行管道可视化了完整生命周期：数据管道（绿色，上排）将原始输入转化为 ML 可用数据集，模型开发管道（蓝色，下排）则以这些数据集为基础，完成训练、评估、验证与部署。关键在于两者的交互——曲线反馈箭头显示部署反馈如何驱动数据优化，形成 ML 独有的持续改进循环。

这一工作流框架为后续技术章节提供了支撑。数据管道将在 第 6 章：数据工程 详细展开，聚焦如何保障数据质量与全生命周期管理。模型训练将在 第 8 章：AI 训练 深入探讨大规模高效训练。支持迭代开发的软件框架详见 第 7 章：AI 框架 。部署与运维则在 第 13 章：ML 运维 系统讲解。本章首先阐明这些环节如何互联，理解整体系统后，细节才有意义。

本章聚焦 ML 生命周期的概念阶段——即开发流程的“是什么”和“为什么”。而生命周期的自动化、工具化与基础设施实现——即“怎么做”——属于 MLOps 的范畴，详见 第 13 章：机器学习运维 。二者区分至关重要：生命周期提供理解 ML 开发阶段的系统框架，MLOps 则是大规模落地这些阶段的运维实践。理解生命周期基础，才能让 MLOps 工具与实践不再零散。

ML 与传统软件开发的对比

机器学习需要专门的生命周期方法，因为其开发方式与传统软件工程有本质区别。传统生命周期为线性阶段：需求、设计、实现、测试、部署³。每阶段产出特定成果，作为下阶段输入。例如金融软件开发，需求阶段会详细列出交易处理、安全协议、合规要求，这些规范直接转化为系统行为，与 ML 系统的概率性本质（见 第 1 章：绪论 ）形成鲜明对比。

机器学习系统则完全不同。传统软件的确定性（行为由代码明确规定），与 ML 系统的概率性形成对照。例如金融反欺诈：传统系统用规则（如余额>交易额则允许），而 ML 反欺诈系统⁴则通过历史数据学习可疑模式。这种从“规则驱动”到“学习驱动”的转变，彻底改变了开发生命周期，也影响了系统可靠性与健壮性（详见 第 16 章：稳健 AI ）。

这些本质差异带来了新的生命周期动态。ML 系统需通过持续反馈环不断优化，部署反馈反向影响早期开发。ML 系统本质上是动态的，需通过持续部署⁵适应数据分布和目标的变化。

这些差异在生命周期各维度上尤为明显，见下表 @tbl-sw-ml-cycles。这些差异反映了“数据为一等公民”的核心挑战，传统方法对此无能为力⁶。

六大维度揭示了核心规律：ML 系统用概率优化取代确定性规范，用动态适应取代静态行为，用持续反馈取代孤立开发。这也解释了为何传统项目管理方法在 ML 项目中屡屡失效。

ML 的实验本质不同于传统测试。ML 实验本身就是开发核心，通过系统性假设检验（数据源、特征、模型结构、超参数）寻找最优解，是科学发现过程而非 QA 步骤。传统测试只验证代码是否符合规范，ML 实验则探索不确定空间，追求最优实证结果。

这些差异凸显了需要强大 ML 生命周期框架，以适应迭代开发、动态行为和数据驱动决策。理解这些区别后，才能深入探讨 ML 项目的生命周期各阶段及其独特挑战。

这一基础为后续各阶段的详细探讨奠定了前提。

六大核心生命周期阶段

AI 系统需要专门的开发流程。ML 生命周期的具体阶段为此提供了结构化框架，各阶段既承接前序基础，又为后续环节铺路。

从图 1 的细致管道视角，转向更高层次的抽象。图 2 将细节管道归纳为六大阶段，帮助我们把握 ML 系统开发的整体进程。此视角强调阶段性推进，但各阶段间依然通过反馈环紧密相连。

图 2 展示了 AI 系统开发的六大核心阶段：问题定义明确目标与约束，数据采集与准备涵盖完整数据管道，模型开发与训练聚焦模型创建，评估与验证保障质量，部署与集成实现生产上线，监控与维护确保持续有效。各阶段通过反馈环循环，后期洞见常常反哺前期优化，体现了 ML 开发的实验性与数据驱动特征。

生命周期始于问题定义与需求分析，团队需明确系统目标、设定可量化性能指标、识别关键约束。精准的问题定义确保目标与预期结果一致，为后续工作奠定基础。

随后，进入数据资源的组建阶段。数据采集与准备包括收集相关数据、清洗与预处理，为模型训练做好准备。此阶段涉及多样数据集的构建、高质量标注与预处理管道开发，详见 第 6 章：数据工程 。

数据准备就绪后，进入模型开发与训练阶段。需选择合适算法、设计模型结构、用准备好的数据进行训练。成功依赖于技术选择与模型设计的不断迭代。高级训练方法与分布式训练详见 第 8 章：AI 训练 ，底层架构详见 第 4 章：DNN 架构 。

模型训练完成后，需通过严格评估确保其满足性能要求。评估与验证阶段通过预设指标和多场景测试，确保模型在真实环境下的准确性、可靠性与健壮性。

验证通过后，模型通过部署与集成阶段进入生产系统。需解决系统兼容性、可扩展性与多种部署环境下的运维挑战，详见 第 2 章：机器学习系统 。

最后，已部署系统需持续监控与维护，保障性能与适应环境变化。监控与维护阶段聚焦于实时性能追踪与系统更新，确保系统随数据、需求或外部环境变化而持续有效。

案例分析：糖尿病视网膜病变筛查系统

为便于理解，将以糖尿病视网膜病变（DR）筛查系统从研究到临床部署为案例。本章将贯穿此案例，展示生命周期各阶段如何在实际中相互作用。

注：本案例基于公开报道的 DR 系统部署经验（如 Google 项目），为教学目的适当改编与综合，旨在展示生命周期原则，而非还原具体项目细节。

从研究成功到临床落地

DR 筛查最初看似简单：开发 AI 系统分析视网膜图像，检测糖尿病视网膜病变，准确率媲美专家。实验室阶段模型表现优异，但从研究到临床的转变揭示了 AI 生命周期的复杂性——技术卓越需与运维、法规、部署约束深度融合。

医疗挑战的规模决定了 AI 筛查的必要性。全球 DR 患者超 1 亿，是可防盲的主要原因之一⁷。图 3 展示了临床挑战：区分健康与早期病变视网膜（如暗红色出血点）。表面上是图像分类，实际却涉及全生命周期的复杂性。

系统工程启示

DR 系统开发贯穿生命周期各阶段的核心原则。数据质量难题催生分布式数据验证，农村诊所的基础设施约束推动边缘计算优化，临床流程集成凸显人机协作设计的重要性。可见，构建健壮 AI 系统不仅要模型准确，更需系统化工程应对真实部署复杂性。

这一完整案例反映了医疗 AI 部署的普遍规律。每个生命周期阶段的决策都会影响后续，反馈环驱动持续改进，系统涌现行为需整体性解决。医疗 AI 部署的难题⁸，在大多数实际 ML 应用中普遍存在。

案例说明，AI 生命周期的集成性要求从一开始就采用系统思维。DR 案例表明，只有理解并设计好各阶段间的复杂互动，才能构建可持续的 AI 系统。

明确了框架与案例后，接下来逐一剖析各生命周期阶段，从问题定义开始。

问题定义阶段

机器学习系统开发的首要挑战在于定义系统的学习目标。传统软件通过确定性规范直接映射行为，而 ML 系统则需通过数据学习在真实约束下优化表现⁹。如图 1 所示，这是 ML 生命周期的基础阶段。

以 DR 筛查为例，表面简单的医学图像任务，实际涉及多重相互关联目标的定义，影响后续每个生命周期阶段。

开发团队需平衡多重约束：诊断准确性（确保患者安全）、计算效率（适应农村诊所硬件）、工作流集成（促进临床采用）、法规遵从（满足医疗器械审批要求）、成本效益（实现可持续部署）。每个约束相互影响，形成复杂的优化问题，传统软件开发方法无能为力。多维的成功标准驱动数据采集策略、模型架构选择和部署基础设施决策。

约束的相互作用

问题定义的决策在 DR 系统中产生连锁反应。最初对诊断准确率的关注，逐步扩展到部署环境的约束与机遇。

例如，确保 90% 以上的糖尿病视网膜病变敏感性（防止漏诊导致失明）与 80% 以上的特异性（避免误诊导致的过度筛查）成为关键。这些指标需在不同患者群体、相机设备和图像质量条件下保持一致，尤其是在资源有限的农村诊所。

农村诊所的部署要求模型在计算能力有限、网络连接不稳定的设备上运行，并在临床工作流程时间内提供可靠结果。这些系统需由技术培训不足的医务人员操作。

医疗器械法规要求广泛的验证、审计追踪和性能监控能力，影响数据采集、模型开发和部署策略。

这些相互关联的要求表明，ML 系统的问题定义需理解系统运行的完整生态。及早识别这些约束，使团队能够在开发初期就做出关键架构决策，确保成功部署，而非在投入大量开发后才发现局限。

协作式问题定义过程

明确可行的问题定义需系统化工作流，连接技术、运维与用户需求。首先需识别系统核心目标：要执行的任务和需满足的约束。团队与利益相关者协作，收集领域知识、勾勒需求、预判真实部署中可能遇到的挑战。

以 DR 项目为例，需与临床医生紧密合作，确定农村诊所的诊断需求。平衡模型复杂度与硬件限制、确保结果可解释性等关键决策，皆在此阶段形成。同时，需考虑法规要求，如患者隐私保护和医疗标准合规。协作过程确保问题定义在技术可行性与临床相关性间取得一致。

随规模调整的定义

随着 ML 系统的扩展，问题定义需适应新的运维挑战¹⁰。最初仅针对少数诊所、设备一致的项目，扩展至设备多样、人员素质参差不齐、患者群体差异大的诊所时，原有问题定义需调整以适应这些变化。

扩展还带来了数据挑战。更大数据集可能包含更多边缘案例，暴露模型设计的弱点。部署到新地区时，成像设备和患者群体的差异需要进一步调整系统。问题定义若能从一开始就考虑到这些多样性，将确保系统在未来扩展时无需全面重设计。

在 DR 案例中，问题定义过程直接影响数据采集策略。对多样人群验证的要求驱动了对多样化训练数据的需求，而边缘部署的约束则影响数据预处理方法。法规合规需求决定了标注协议和质量保证标准。这些相互关联的要求表明，有效的问题定义能够预见后续生命周期阶段中将出现的约束，为集成系统开发奠定基础，而非孤立、顺序的优化。

在明确问题定义后，开发过程转向组建实现这些目标所需的数据资源。

数据采集与准备阶段

数据采集与准备是 ML 生命周期的第二个阶段（见图 1），原始数据在此阶段被收集、处理和准备好用于模型开发。此阶段面临独特挑战，超出单纯收集足够训练样本的范畴¹¹。这些挑战是 第 6 章：数据工程 的核心内容。对于像 DR 筛查这样的医疗 AI 系统，数据采集必须在统计严谨性与操作可行性之间取得平衡，同时满足最高的诊断准确性标准。

问题定义驱动了 DR 示例中的数据需求。多维的成功标准（不同人群的准确性、硬件效率、法规合规）要求数据采集策略超越典型的计算机视觉数据集。

例如，构建一个开发数据集可能需要收集 128,000 张视网膜底片，每张需经过 54 位专家中的 3-7 位进行审阅¹²。这种专家共识方法解决了医疗诊断中固有的主观性问题，同时建立了经得起法规审查的真值标签。标注过程捕捉了微动脉瘤、出血和硬性渗出等临床相关特征，涵盖了疾病严重程度的各个阶段。

高分辨率视网膜扫描生成的文件大小从 10MB 到 120MB 不等，具体取决于分辨率和压缩率，带来了巨大的基础设施挑战。一个典型的诊所每天处理 50 名患者，每周生成的影像数据在 5GB 到 15GB 之间，迅速超过农村地区互联网连接的承载能力（通常限制在 2-10 Mbps 的上传速度）。这一数据量限制迫使架构决策倾向于边缘计算解决方案，而非基于云的处理。

实验室数据与真实数据的桥接

当此系统在泰国和印度的农村诊所部署时，真实数据与实验室精心策划的训练集差异巨大。

这些差异威胁到模型性能，暴露出对稳健预处理和质量保证系统的迫切需求。

数据量的限制驱动了基础架构的根本性决策，如 第 2 章：机器学习系统 中讨论的部署范式：边缘计算而非云端推理。地方预处理将带宽需求从每周 15GB 压缩至 750MB，但需要在地方设备上提供 10 倍的计算资源，这又反过来影响了模型优化策略和部署硬件要求，后者使用了像 NVIDIA Jetson 这样的专用边缘设备¹³。

典型解决方案架构由数据采集限制决定：NVIDIA Jetson 边缘设备（视型号而定，2-32GB RAM，64-2048 CUDA 核心）用于本地推理，诊所聚合服务器（8 核 CPU，32GB RAM）用于数据管理，云端训练基础设施则使用 32-GPU 集群进行每周模型更新。这一分布式方案在覆盖 200 多个诊所的部署中，实现了低于 80 毫秒的推理延迟和 94% 的正常运行时间。

患者隐私法规要求采用联邦学习架构，使模型训练无需集中敏感患者数据。这一方法增加了数据采集工作流和模型训练基础设施的复杂性，但对获得法规批准和临床采用至关重要。

这些经验教训清晰地表明了约束传播的原则：数据采集阶段的生命周期决策在整个系统开发过程中创造了约束和机遇，影响从基础设施设计到模型架构的方方面面。

分布式部署的数据基础设施

理解数据特征和部署约束如何驱动架构决策，在大规模应用中至关重要。每张视网膜图像都经历了复杂的旅程：在诊所相机上拍摄、地方存储和初步处理、质量验证、数据安全传输到中央系统、与训练数据集的集成。

不同的数据访问模式需要不同的存储解决方案。团队通常实施分层方法，平衡成本、性能和可用性：频繁访问的训练数据需要高速存储以便快速模型迭代，而历史数据集则可以容忍较慢的访问速度以换取成本效率。智能缓存系统根据使用模式优化数据访问，确保相关数据随时可用。

农村诊所面临的显著连接性限制，要求灵活的数据传输策略。实时传输适用于互联网可靠的诊所，而存储转发系统则支持在连接不稳定地区的操作。这种自适应方法确保无论当地基础设施如何，系统都能稳定运行。

基础设施设计必须预见从试点部署到数百个诊所的扩展。架构需兼顾不同的数据量、硬件配置和操作要求，同时保持数据一致性和系统可靠性。这一可扩展性基础在系统扩展到新地区时尤为重要。

大规模数据管理

从系统思维角度看，随着 ML 系统的扩展，数据采集挑战呈指数级增长。在 DR 示例中，从初始诊所扩展到更广泛的网络，带来了设备、工作流程和操作条件的显著变化。每个诊所实际上成为一个独立的数据节点¹⁴，但系统需要确保所有位置的一致性能。遵循之前建立的协作协调模式，团队实施了专门的编排，利用共享工件库、版本化 API 和自动化测试管道，实现对大型诊所网络的高效管理。

随着系统向更多诊所扩展，数据量的增加也带来了更高分辨率成像设备的普及，生成更大、更详细的图像。这些进步加大了存储和处理基础设施的压力，要求进行优化以在不影响质量的前提下保持效率。患者人口统计、诊所工作流程和连接模式的差异进一步凸显了稳健设计的必要性，以优雅地处理这些变化。

扩展挑战突显了数据采集阶段决策如何在生命周期后续阶段产生涟漪效应，影响模型开发、部署和监控等各个环节。例如，数据采集时对更高分辨率数据的适应直接影响训练和推理的计算需求，强调了即使在早期阶段也需考虑生命周期整体。

质量保证与验证

质量保证是数据采集过程的一个重要环节，确保数据满足后续阶段的要求。在 DR 示例中，采集时的自动检查会标记焦点不清或构图错误等问题，便于诊所工作人员及时处理。这些主动措施确保低质量数据不会在管道中传播。

验证系统在地方和中央两个层面上扩展了这些努力，不仅验证图像质量，还确保标注正确、患者信息关联准确、符合隐私法规。通过这些系统，确保数据的可靠性和稳健性，维护整个 ML 管道的完整性。

此阶段的数据采集经验直接影响模型开发方法。数据采集过程中发现的基础设施限制（带宽有限、多样化硬件、间歇性连接）对模型效率提出了要求，进而推动了架构决策。隐私约束下采用的分布式联邦学习方法影响了训练管道设计。不同诊所环境中观察到的质量差异则塑造了验证策略和稳健性要求。数据采集与模型开发之间的这种耦合，正是系统化生命周期规划胜过顺序阶段优化的典范。

图 4 描述了这些关键反馈环，使系统得以持续改进。数据采集奠定的基础在于约束与机遇的双重作用，既支持又限制了有效模型的技术路径——这一动态关系在接下来的模型开发阶段愈加明显。

模型开发与训练阶段

模型开发与训练（见图 1 的第三阶段）是机器学习系统的核心，但这一阶段面临的挑战远超算法选择和超参数调优¹⁵。训练方法、基础设施需求和分布式训练策略在 第 8 章：AI 训练 中有详细介绍。在医疗等高风险领域，每个设计决策都可能影响临床结果，因此将技术性能与操作约束相结合至关重要。

早期生命周期决策在模型开发中产生连锁反应。DR 示例中确立的性能要求（专家级准确性与边缘设备兼容性）带来了模型架构和训练策略的创新挑战。

通过对 ImageNet 的迁移学习¹⁶，结合精心标注的 128,000 张图像数据集，开发者在 DR 项目中实现了 0.91-0.95 的 F 值¹⁷，在受控环境下的表现可与眼科医生相媲美。这一结果验证了大规模预训练与特定领域微调相结合的方法——利用 第 3 章：深度学习基础 中的梯度优化原理，调整 第 4 章：DNN 架构 中的预训练卷积架构，以适应医学影像分析。

但追求高准确率仅是挑战的开始。数据采集阶段洞察的边缘部署约束，带来了严格的效率要求：模型需在 98MB 内运行，推理延迟低于 50ms，操作时内存占用低于 400MB。最初的研究模型（一个 2.1GB 的集成模型¹⁸，准确率 95.2%）在所有部署约束上均不合格，需经过系统优化，最终达到 96MB、准确率 94.8% 的模型，同时满足所有操作要求。

这些约束驱动了架构的创新，包括用于模型大小、推理加速和高效部署场景的优化技术——在 第 4 章：DNN 架构 中平衡深度卷积网络的计算需求与 第 2 章：机器学习系统 中边缘设备的资源限制。

遵循迭代开发框架，模型开发过程需在准确性优化与效率优化之间反复迭代。每个架构决策（从卷积层数到激活函数的选择，见 第 3 章：深度学习基础 和 第 4 章：DNN 架构 ）都必须根据测试集指标和数据采集阶段确定的基础设施约束进行验证。这种多目标优化方法体现了约束传播的原则，即部署约束塑造开发决策。

性能与部署约束的平衡

DR 示例中的模型开发经历了临床效果与部署可行性之间的基本权衡，这也是现实 AI 系统的特征。

医疗应用需要特定的性能指标¹⁹，与 第 3 章：深度学习基础 中介绍的标准分类指标有显著不同。DR 系统要求 >90% 的敏感性（防止漏诊导致失明）和 >80% 的特异性（避免误诊导致的过度筛查）。这些指标必须在不同患者群体和图像质量条件下保持一致。

单纯优化临床性能是不够的。数据采集阶段的边缘部署约束带来了额外要求：模型必须在资源有限的硬件上高效运行，同时保持与临床工作流兼容的实时推理速度。这就形成了一个多目标优化问题，模型容量（见 第 4 章：DNN 架构 ）与部署可行性（见 第 2 章：机器学习系统 ）之间存在着根本的矛盾。团队发现，最初的 2GB 模型（准确率 95.2%）可以通过量化、剪枝和知识蒸馏等系统优化技术，优化到 96MB，同时保持 94.8% 的准确率，满足所有部署要求。

选择使用轻量级模型的集成而非单一大模型，体现了模型开发决策如何在系统生命周期中传播。这一架构决策降低了单个模型的复杂性（便于边缘部署），但增加了推理管道的复杂性（影响部署和监控策略）。团队需为模型集成开发编排逻辑，并创建能够跟踪多个模型组件性能的监控系统。

这些模型开发经验强化了我们之前确立的生命周期集成原则。从选择 CNN 架构进行空间特征提取（见 第 4 章：DNN 架构 ），到配置训练超参数（见 第 3 章：深度学习基础 ），再到评估和验证策略，模型开发的每个环节都必须考虑后续部署和监控的需求。这表明，成功的模型开发需要预见后续生命周期阶段的约束，而非孤立优化模型，反映了我们的系统思维方法。

约束驱动的开发过程

现实约束贯穿模型开发的整个过程，从初步探索到最终优化，要求对实验采取系统化方法。

开发始于数据科学家与领域专家（如医学影像中的眼科医生）之间的合作，识别出与目标病症相关的特征。这一跨学科方法确保了模型架构能够捕捉临床相关特征，同时满足数据采集阶段识别的计算约束。

计算约束深刻影响实验方法。生产 ML 工作流的成本呈乘法级增长：10 个模型变体 × 5 个超参数搜索（学习率从 1e-4 到 1e-2，批量大小从 16 到 128，优化算法见 第 3 章：深度学习基础 ） × 3 种预处理方法（原始图像、直方图均衡、自适应滤波） = 150 次训练。以每次训练约 $500-2000 计算成本计算，迭代成本可达 $150K。这个经济现实推动了高效实验的创新：智能作业调度将空闲 GPU 时间减少 60%，中间结果缓存节省 30% 预处理时间，早停技术在 20% 完成时终止无望实验，自动化资源优化实现 2.3 倍成本效率。

机器学习模型开发具有涌现特性，使得结果具有不确定性，要求遵循科学方法原则：通过固定随机种子和环境版本控制变量，系统性消融研究²⁰ 隔离组件贡献，混杂因素分析区分架构效应与优化效应，以及通过 A/B 测试²¹ 框架进行多次运行的统计显著性检验。这一方法对于区分真实性能提升与统计噪声至关重要。

在整个开发过程中，团队根据早期生命周期阶段确定的部署约束验证模型。每一项架构创新都必须同时评估其对准确性的提升以及与边缘设备限制和临床工作流要求的兼容性。这种双重验证方法确保开发工作与部署目标的一致性，而不是仅仅针对实验室条件进行优化。

从原型到生产级开发

随着 DR 示例等项目从原型演变为生产系统，团队在多个维度上遇到涌现复杂性：更大的数据集、更多的模型变体、并行实验和分布式训练基础设施。这些扩展挑战说明了适用于大规模 AI 系统开发的系统思维原则。

从单机训练到分布式系统的转变，引入了协调需求，需在训练速度提升与系统复杂性增加之间取得平衡。这导致实施容错机制和自动故障恢复系统。编排框架实现了基于组件的管道构建，具有可重用的阶段、自动资源扩展和跨分布式组件的监控。

随着实验生成工件²²（如模型检查点、训练日志和性能指标）的数量激增，系统化跟踪变得至关重要。没有结构化的组织，团队可能会在实验过程中丧失宝贵的知识积累。为此，团队实施了系统化的实验标识、自动化工件版本控制和基于性能特征与配置参数查询实验的搜索能力。

大规模模型开发需要在训练计算和支持基础设施之间分配资源。有效的实验管理虽然需要计算开销，但通过加速开发周期和改善模型质量，带来了可观的回报。

模型开发过程建立的能力和约束，直接影响到下一个生命周期阶段。针对边缘优化的集成架构虽然实现了诊所部署，但对服务基础设施提出了更高要求。法规验证要求则塑造了部署验证协议。这些相互关联的要求表明，开发决策为后续部署环节奠定了基础和限制。

模型开发的这些成就，最终为部署阶段带来了新挑战。尽管优化后的集成架构满足了边缘设备的约束，但仍需复杂的服务基础设施。支持快速迭代的分布式训练方法，要求在诊所部署中实现模型版本控制和同步。指导模型开发的法规验证要求，进一步影响部署验证和监控策略。这些相互关联性表明，成功的模型开发必须预见部署挑战，确保技术创新能够转化为交付价值的操作系统。

部署与集成阶段

在部署与集成阶段（见图 1 的第五阶段），训练好的模型被集成到生产系统和工作流中。部署需要解决系统兼容性、可扩展性和操作约束等实际挑战。成功的集成确保模型的预测在真实环境中是准确且可操作的，而资源限制和工作流中断则可能成为障碍。部署和维护的操作细节在 第 13 章：机器学习运维 中有详细说明。

在 DR 示例中，部署策略受限于前述多样环境。边缘部署实现了在网络连接不稳定的农村诊所对视网膜图像的本地处理，而自动化质量检查则能标记出低质量图像以便重新采集，确保预测的可靠性。这些措施表明，部署必须在技术复杂性与可用性、可扩展性之间架起桥梁，以适应临床环境。

技术与操作要求

部署要求源于模型的技术规范和预期环境的操作约束。在 DR 系统中，模型必须在计算资源有限、网络连接间歇的农村诊所中运行。它必须融入现有的临床工作流程，快速提供可解释的结果，以辅助医疗提供者的决策，而不造成工作流程中断。

这些要求影响了部署策略。尽管基于云的部署在技术上更简单，但由于许多诊所的连接不可靠，可能无法实施。因此，团队通常选择边缘部署，即模型在诊所硬件上本地运行。这一方法要求对模型进行优化，以满足特定硬件的约束：目标指标可能包括模型大小低于 98MB、推理延迟低于 50ms、边缘设备上内存使用低于 400MB。实现这些目标需要系统化应用优化技术，以减少模型大小和计算需求，同时平衡准确性权衡。

与现有系统的集成则面临额外挑战。ML 系统必须与医院信息系统（HIS）对接，以访问患者记录和存储结果。隐私法规要求在每个步骤都安全处理数据，影响部署决策。这些考虑确保系统在日常使用中符合临床和法律标准。

分阶段的部署与集成过程

DR 示例中的部署与集成工作流，突显了模型功能、基础设施与用户体验之间的复杂相互作用。该过程始于在模拟环境中进行全面测试，这些环境复制了目标诊所的技术约束和工作流程。通过这些模拟，团队能够及早识别潜在瓶颈和不兼容之处，从而在全面推广前优化部署策略。

一旦部署策略确定，团队通常会实施分阶段的推广。初始部署限制在少数试点网站，以便在真实条件下进行受控测试。这种方法提供了来自临床医生和技术人员的宝贵反馈，帮助识别模拟中未暴露的问题。

集成工作则专注于确保 ML 系统与现有工具的无缝交互。例如，DR 系统必须从 HIS 中提取患者信息，处理来自连接相机的视网膜图像，并以临床医生易于理解的格式返回结果。这些任务需要开发稳健的 API、实时数据处理管道和用户友好的界面，以满足医疗提供者的需求。

多站点部署挑战

在多个诊所部署 DR 系统，暴露了将 AI 系统扩展超出受控实验室环境的基本挑战。每个诊所都有其独特的约束：成像设备不同、网络可靠性差异、操作人员技能水平不同、工作流程模式各异。

从开发到部署的转变，暴露了显著的性能挑战。成像设备和操作人员专业知识的差异，导致数据质量不一致，模型可能难以处理。基础设施的限制可能迫使紧急模型优化，表明部署现实如何反过来影响开发过程中的决策，包括预处理策略、架构选择和验证方法。

团队发现，部署架构决策在整个系统中产生级联效应。边缘部署将延迟降至最低，以满足实时临床工作流程，但对模型复杂性施加了严格的限制。云部署则允许模型灵活性，但可能引入超过 200ms 的延迟，这在时间敏感的医疗应用中是不可接受的。

成功的部署不仅需要技术优化。临床医生的反馈常常表明，初始系统界面需要重大重新设计，以实现广泛采用。团队必须在技术复杂性与临床可用性之间取得平衡，认识到用户信任和熟练程度与算法性能同样重要。

在分布式部署中管理改进，需要复杂的协调机制。集中版本控制系统和自动化更新管道确保性能改进能够迅速传播到所有部署地点，同时尽量减少对临床操作的干扰。如图 2 所示，部署挑战产生了多个反馈路径，推动系统的持续改进。

确保临床级可靠性

在临床环境中，可靠性至关重要。DR 系统需要在各种条件下无缝运行，从高患者流量到次优成像设置。为确保稳健性，团队实施了故障安全机制，能够检测和处理常见问题，如数据不完整或质量差。机制包括自动图像质量检查和备用工作流程，以防系统遇到错误。

测试在确保可靠性中发挥核心作用。团队进行广泛的压力测试，以模拟高峰使用场景，验证系统在性能不下降的情况下处理高吞吐量的能力。关键组件的冗余设计将停机风险降到最低，所有与外部系统（如 HIS）的交互都经过严格测试，以确保兼容性和安全性。

此类系统的部署经验揭示了开发活动向运营活动的过渡。来自真实部署的反馈（如临床可用性问题、硬件性能问题）产生的洞见，指导最后一个生命周期阶段：持续监控与维护策略。分布式边缘部署架构带来了对系统级监控和协调更新的新要求。与医院信息系统的集成挑战，建立了在不干扰临床工作流程的情况下管理系统演变的协议。

成功的部署为有效的监控和维护奠定了基础，创建了操作基础设施和反馈机制，实现持续改进。部署经验表明，这一阶段不是终点，而是进入持续运营阶段的过渡，体现了我们的系统思维方法。

监控与维护阶段

一旦 AI 系统从部署过渡到生产运营，就进入了与传统软件系统截然不同的操作阶段。如图 1 所示，监控与维护形成了一个持续循环，保持系统可靠运行。传统应用在明确更新前行为保持静态，而 ML 系统则必须考虑数据分布的演变、使用模式的变化和模型性能的漂移。

监控与维护是确保已部署机器学习系统持续有效性和可靠性的关键过程。传统软件保持静态行为，而 ML 系统则必须应对数据分布的变化²³、使用模式的变化和操作需求的演变²⁴。监控提供了适应这些挑战所需的反馈，而维护则确保系统不断演变以满足新需求。这些操作实践构成了 第 13 章：机器学习运维 的基础。

正如图 2 所示，监控是系统改进的核心枢纽，生成三个关键反馈环：“性能洞察”反馈至数据采集以填补空白，“数据质量问题”触发数据准备的优化，“模型更新”则在性能漂移时启动再训练。在 DR 示例中，这些反馈环实现了系统的持续改进：识别出被代表性不足的人群（触发新数据采集）、检测到图像质量问题（改善预处理）、应对模型漂移（启动再训练）。

对于 DR 筛查系统，持续监控在不同诊所跟踪系统性能，检测患者人口统计或新成像技术的变化，这些变化可能影响准确性。主动维护计划则包括了对 3D 成像技术如 OCT 的支持，扩展系统诊断更多病症的能力。这体现了设计能够适应未来挑战的系统，同时保持对严格医疗法规和 第 17 章：可信 AI 中探讨的负责任 AI 原则的合规性。

动态系统的生产监控

监控与维护的要求源于技术需求和操作现实。在 DR 示例中，从技术角度看，监控需要持续跟踪模型性能、数据质量和系统资源使用情况。然而，操作约束为监控系统增加了复杂性：监控系统必须与临床工作流程对接，检测患者人口统计的变化，并为技术团队和医疗提供者提供可操作的洞察。

初始部署通常会突出系统未能满足真实世界需求的多个方面，例如在设备超过 5 年或图像分辨率低于 1024x1024 像素的诊所，准确率下降 15-25%。监控系统能够检测到特定亚群体的性能下降：如增殖性糖尿病视网膜病变患者（占筛查人群 2%）的准确率下降 18%，而严重白内障患者（占 65 岁以上老年患者 12%）的敏感性下降 22%。这些在实验室验证中不可见但在临床实践中至关重要的盲点，促使维护策略的调整，包括有针对性的数据采集（增加 15,000 张受白内障影响的图像）和架构改进（具有专门病理检测器的集成模型）。

这些要求显著影响系统设计。此类系统的关键特性要求具备实时监控能力，而非定期离线评估。团队通常会建立量化的性能阈值和明确的行动触发机制：P95 延迟超过基线的 2 倍会立即发出警报并在 5 分钟内响应，模型准确率下降超过 5% 会触发每日警报并自动启动再训练工作流，数据漂移的 PSI 分数超过 0.2 会启动每周警报并通知数据团队，资源利用率超过 80% 会激活自动扩展机制并监控成本。

监控系统的设计还需考虑到临床工作流程的特点，确保监控数据以清晰、可操作的方式呈现给临床和技术人员。

通过反馈环实现持续改进

DR 示例中的监控与维护工作流，揭示了自动化系统、人类专业知识和不断发展的医疗实践之间的复杂相互作用。该工作流始于定义完整的监控框架，建立关键绩效指标（KPI），并实施仪表板和警报系统。该框架必须平衡监控深度与系统性能、隐私考虑，收集足够的数据以检测问题，但又不至于给系统带来过大负担或侵犯患者隐私。

随着系统的成熟，维护变得越来越动态。由于新的医学知识或性能改进驱动的模型更新，需要仔细验证和控制发布。团队利用 A/B 测试框架在真实条件下评估更新，并实施回滚机制²⁵，以便在出现问题时迅速应对。与传统软件的持续集成和部署²⁶ 不同，ML 系统必须考虑数据演变²⁷，这会影响模型行为，传统 CI/CD 管道并未针对这种情况进行设计。

监控与维护形成了一个迭代循环，而非离散阶段。监控所获洞见会指导维护活动，而维护工作往往又需要更新监控策略。团队开发工作流，实现从问题检测到解决的无缝过渡，涉及技术和临床领域的协作。

大规模分布式系统监控

如 DR 示例所示，从 5 个试点站点扩展到 200 多个诊所的部署，使监控和维护的复杂性呈指数级增长。每个新增诊所每周生成 2-5GB 的操作日志（包括推理时间、图像质量指标、错误率和使用模式），形成每周 400-1000GB 的系统级数据量，需自动化分析。每个诊所还引入了环境变量：15 种以上不同的相机型号（从 2 百万像素的移动设备到 1200 万像素的专业系统）、不同的操作人员技能水平（从训练有素的技术人员到社区卫生工作者）、以及不同的人口统计模式（城市与农村、年龄分布相差 20 岁以上）。

全球性能指标与特定站点行为的监控需求，要求复杂的基础设施。监控系统跟踪各阶段的指标，包括处理时间、错误率和资源利用率，维护完整的数据血缘追踪（源头到预测的审计追踪，确保合规性），将生产问题与特定训练实验关联，以便快速根因分析，并提供成本归属，追踪跨团队和项目的资源使用情况。

持续适应带来额外复杂性。真实世界的使用使系统面临不断扩展的场景范围。从这些场景中捕获洞见并驱动系统更新，要求高效的机制将新数据整合到训练管道中，并在不干扰临床工作流程的情况下部署改进模型。

预见和防止系统退化

仅靠被动维护不足以应对动态操作环境。主动策略变得至关重要，以便在问题影响临床操作之前预见和防止它们。

预测性维护模型根据操作数据中的模式识别潜在问题。持续学习管道使系统能够根据新数据进行再训练和适应，确保其在临床实践或患者人口统计变化时的相关性。这些能力需要仔细平衡，以确保安全性和可靠性，同时保持系统性能。

评估适应性和弹性的指标与准确性同样重要，反映系统随操作环境演变的能力。主动维护确保系统能够应对未来挑战，而不牺牲可靠性。

这些监控和维护经验使我们生命周期的旅程回归原点，展示了如图 1 所示的持续反馈环。生产洞察推动问题定义、数据质量、架构和基础设施规划的优化，形成 ML 系统与传统线性开发的根本区别。

这种持续反馈和改进循环，体现了系统思维方法的精髓，区别于传统软件开发。成功源于对各生命周期阶段的整体把握，而非对单一阶段的完美追求。

整合系统思维原则

在通过糖尿病视网膜病变案例研究每个 AI 生命周期阶段后，涌现出一些系统级模式，区分了成功的 AI 项目与那些在集成挑战中挣扎的项目。DR 示例表明，构建有效的机器学习系统不仅需要技术卓越，还需要理解技术决策如何创造相互依赖关系，这些关系会贯穿整个开发和部署过程。

我们的分析中涌现出四种基本的系统思维模式：约束传播、多尺度反馈、涌现复杂性和资源优化。这些模式为理解后续技术章节的相互关联奠定了分析框架，表明数据工程、框架、训练和运维的专门方法如何集成成系统，使得单一优化无法实现的整体效益得以实现。

决策如何在系统中传播

约束传播是 ML 开发中最关键的系统思维模式：早期决策会产生连锁效应，塑造后续的每个阶段。我们的 DR 示例清晰地阐明了这一模式：对 >90% 敏感性的法规要求，驱动了数据采集策略（需要专家共识标注），影响了模型架构选择（需要高容量网络），决定了部署约束（需要边缘优化），进而塑造了监控方法（需要分布式性能跟踪）。

这种传播是双向的，形成动态约束网络，而非线性依赖。当农村诊所部署暴露出带宽限制（平均 2-10 Mbps）时，团队必须重新设计数据预处理管道，以实现 95% 的压缩比，这又要求优化模型架构以适应压缩输入，进而影响训练策略以应对数据退化。理解这些连锁关系，使团队能够做出适应系统约束的架构决策，而非与之对抗。

协调多时间尺度的反馈

ML 系统的成功在于协调跨越多个时间尺度的反馈环，每个环路服务于不同的系统优化目的。我们的 DR 部署实例体现了这一模式：以分钟为单位的快速反馈（实时质量检查、自动图像验证）、以日为单位的中频反馈（200 多个诊所的模型性能监控）、以周为单位的聚合反馈（准确性分析、漂移检测）、以月为单位的战略反馈（人口统计偏差评估、硬件性能审查）以及以季度为单位的架构评估和新区域的容量规划。

这些反馈环的时间结构反映了 ML 系统固有的动态特性。快速反馈使得操作问题能够迅速得到修正——诊所的错误配置相机可以在几分钟内被检测和修正。较慢的反馈则支持战略适应——识别出人口统计变化需要扩展训练数据，通常需要几个月的监测才能可靠地检测到。这种多尺度的方法防止了过度反应（对日常波动的过度反应）和反应迟缓（对重要趋势的反应不足）。

理解系统级行为

复杂系统表现出的涌现行为，在分析单个组件时是不可见的，但在系统规模扩大时变得显而易见。我们的 DR 部署揭示了这一模式：尽管单个诊所可能显示出稳定的 94% 准确率，但系统范围的分析却检测到特定人口群体的轻微性能下降——这些在单一站点监测中不可见但对公平医疗服务至关重要的模式。

ML 系统中的涌现复杂性与传统软件不同。传统分布式系统通过确定性级联失败（服务器崩溃、网络分区），而 ML 系统则通过数据漂移、模型偏见放大和跨异构环境的细微性能下降表现出概率性退化。管理这种复杂性需要分析框架，能够检测分布式部署中的统计模式，提前采取主动干预措施，以防系统性问题的出现。

多维资源权衡

ML 系统中的资源优化涉及多维权衡，产生复杂的相互依赖关系，这在传统软件开发中是不存在的。我们的 DR 案例说明了这些权衡：将模型准确率从 94.8% 提高到 95.2% 需要将模型大小从 96MB 扩展到 180MB，这迫使部署从边缘设备（每个$200-600）转向更强大的硬件（每个$800-2000），在 200 多个诊所中乘以这一成本，单单为了 0.4% 的准确性提升，基础设施成本就增加了$160,000。

这些资源权衡表现出非线性关系，无法通过简单的优化方法解决。数据量的增加使训练时间呈平方级增长，但模型准确性的提升却递减。边缘部署将推理延迟减少 85%，但模型复杂性却被限制 90%。云部署则允许无限的模型复杂性，但可能引入超过 200ms 的延迟，违反临床工作流程要求。理解这些权衡关系，使团队能够做出战略性的架构决策，而非试图孤立优化单个组件。

ML 系统的工程纪律

这四种系统思维模式——约束传播、多尺度反馈、涌现复杂性和资源优化——汇聚成对机器学习系统的工程方法，与传统软件开发截然不同。成功的 ML 系统不是通过对单个组件的独立优化，而是通过集成优化，考虑跨组件依赖、时间动态和资源约束的综合方法而成。

DR 案例研究表明，这种集成方法所产生的系统，比通过顺序优化单个阶段开发的系统更为健壮、适应性强且有效。当团队设计数据采集策略以适应部署约束，创建模型架构以符合操作现实，并实施监控系统以推动持续改进时，他们实现的性能水平是孤立优化方法无法达到的。这种系统化集成代表了将机器学习从实验技术转变为可靠系统工程实践的核心工程纪律。

常见误区与陷阱

机器学习开发引入了与传统软件工程不同的复杂性，但许多团队在不自觉中试图应用熟悉的开发模式，而未意识到这些差异。ML 的实验性质、数据质量的核心作用以及模型的概率行为，带来了传统方法无法应对的工作流挑战。

误区： ML 开发可以不加修改地遵循传统软件工程工作流。

这一误解导致团队将传统软件开发实践直接应用于机器学习项目。正如我们对比传统与 AI 生命周期所示，ML 系统通过数据变异、算法随机性和模型性能演变引入了根本的不确定性，传统的确定性方法无法处理。强行将 ML 项目纳入僵化的瀑布或标准敏捷方法，往往导致错过截止日期、模型验证不足和部署失败。成功的 ML 工作流需要专门的阶段来进行数据验证（见 第 6 章：数据工程 ）、实验跟踪（见 第 7 章：AI 框架 ）和迭代模型优化（见 第 8 章：AI 训练 ）。

陷阱： 将数据准备视为一次性预处理步骤。

许多从业者将数据采集和预处理视为工作流的初始阶段，一旦完成便不再变动。这种方法未能考虑到真实世界数据的动态特性，数据分布的变化、质量的波动和新数据源的不断出现，均需持续的数据验证、漂移监测和自适应预处理管道（见 第 6 章：数据工程 ）。将数据准备视为已完成的里程碑，往往会导致意外的模型退化，尤其是在部署系统遇到与训练条件不同的数据时，凸显了 第 16 章：稳健 AI 中探讨的稳健性挑战。

误区： 开发环境中的模型性能可以准确预测生产性能。

这一信念假设在开发阶段达到良好指标，就能确保成功部署。然而，开发环境通常使用干净、精心策划的数据集和受控的计算资源，创造了与生产现实截然不同的条件。生产系统面临数据质量问题、延迟约束、资源限制和对抗性输入，而这些在开发阶段并不存在。表现优异的模型，可能因环境差异而在生产中失效，因此需要专门的工作阶段来弥合实验室与生产之间的差距，通过稳健的部署实践（见 第 13 章：机器学习运维 和 第 2 章：机器学习系统 ）来实现。

陷阱： 为加快开发进度而跳过系统验证阶段。

在快速交付的压力下，团队常常省略验证、测试和文档阶段。这种做法将验证视为额外负担，而非工程纪律的核心。验证不足会导致模型存在隐性偏见、泛化能力差或意外的失败模式，这些问题往往在生产中显现。事后修复这些问题的成本，远高于在开发阶段投入时间进行系统验证的成本。稳健的工作流将验证嵌入开发过程的各个环节，而非视其为最后的检查点，具体体现在 第 12 章：AI 基准测试 中的评估和验证原则。

总结

本章建立了 ML 生命周期作为机器学习系统工程的系统化框架，构建了数据、模型与部署基础设施在开发过程中的相互关联的思维导图。图 1 通过两条并行管道可视化了这一框架：数据管道通过采集、摄取、分析、标注、验证和准备，将原始输入转化为 ML 准备好的数据集；模型开发管道则以这些数据集为基础，完成训练、评估、验证和部署，形成生产系统。关键在于两者的交互：反馈箭头显示部署洞察如何触发数据优化，形成 ML 独有的持续改进循环。

理解这一框架，解释了为何机器学习系统需要与传统软件截然不同的专门方法。ML 工作流用迭代实验取代确定性规范，用动态适应取代静态行为，用持续反馈环取代孤立开发。这一系统化视角使我们认识到，成功不是来自于单一阶段的完美，而是来自于对数据质量如何影响模型性能、部署约束如何塑造训练策略、生产洞察如何优化开发迭代的全面理解。

关键要点

• ML 生命周期为理解后续技术章节的相互关联提供了支撑框架——数据工程、框架、训练和运维各自解决这一完整系统中的特定环节
• ML 开发的特征在于两条并行管道：数据处理（采集→准备）和模型开发（训练→部署），通过持续反馈环统一
• ML 工作流通过迭代实验、数据驱动的适应和反馈机制实现持续系统改进，根本不同于传统软件的线性推进
• 系统思维模式——约束传播、多尺度反馈、涌现复杂性和资源优化——贯穿后续技术实现的各个方面，展示了专门的数据工程、框架、训练和运维方法如何集成成系统，实现单一优化无法达到的整体效益

本章奠定的工作流框架，为第二部分的技术章节提供了组织结构。数据工程（ 第 6 章：数据工程 ）扩展了我们探讨的数据管道阶段，解决如何保障数据质量与管理。框架（ 第 7 章：AI 框架 ）审视了支持这一迭代开发过程的软件工具。训练（ 第 8 章：AI 训练 ）详细讲解如何高效地进行大规模模型训练。运维（ 第 13 章：机器学习运维 ）探讨了系统如何通过图 1 中所示的反馈环，在生产中维持性能。每一章节在此完整工作流的基础上，深入探讨其特定技术，建立在此系统化视角之上。