type
status
date
slug
summary
tags
category
icon
password
⚠️
设计模式是一系列针对软件开发中常见的问题场景的药方，使用得当则可以拿来快速解决当前问题。本文是O’Reilly的《机器学习设计模式》一书前半部分的整理笔记，涉及到数据表示、问题表示和模型训练的模式。这本书前半段偏向于建模，后半段则偏向于MLOps。
本文中提及的许多事情都是MLOps里要面对的常见问题，解决方案通常都由云平台包揽了，在本文中我会尽量跳出书本，描述一些在AWS上对应的落地措施，这部分内容对应MLA和MLS（2026年4月废止）的考试内容体系。

具有弹性服务的设计模式

模式16：无状态服务函数

无状态服务函数的核心思想，是将训练好的模型导出为独立的推理包（如TensorFlow SavedModel、ONNX等），并部署到可弹性伸缩的函数计算平台（如AWS Lambda、Google Cloud Functions、Cloud Run）。
无状态意味着每次调用之间互不依赖，所有输入输出都由请求本身决定，任何状态信息（用户、缓存）需存放在外部系统中。这样可轻松应对波动的吞吐量，并通过API为下游应用提供即开即用的推理服务。
不过Serverless平台更适合轻量、低延迟任务；若模型较大或需要GPU推理，则应使用长期运行的服务（如SageMaker Endpoint或Kubernetes部署）。

模式17：批处理服务

批处理服务主要用于定期对大规模数据集执行模型预测的场景，例如每小时对全量用户日志进行打分或排序。模型通常会以序列化形式存储在模型仓库中，再由分布式计算引擎（如BigQuery ML、Spark等）批量加载执行预测，并将结果写回数据仓库或对象存储中供下游使用。
与在线推理不同，批处理关注的是高吞吐、可扩展性和结果幂等性，而非实时响应。它常与数据管道调度系统（如 Airflow、Step Functions）结合，用于周期性模型运行与结果刷新。

模式18：持续的模型评估

在机器学习系统中，常假设训练、验证与现实数据分布一致。然而随时间推移，特征分布或标签规律可能发生漂移，导致模型性能下降。为此，需要建立持续的模型评估机制。
一类方法是基于标注反馈的性能监控：收集预测结果与真实标签，计算混淆矩阵、AUC、RMSE等指标，人工或自动判定模型是否退化。另一类方法是基于分布漂移检测：持续比较线上数据与训练数据的特征分布（如PSI、K-S检验），当偏差超过阈值时触发再训练。
再训练可以是全量重训，也可以采用滑动窗口或增量学习方式。整个过程通常由MLOps流水线自动化实现，以维持模型在现实环境下的长期有效性。
对应到AWS环境中有些工具的组合使用可以达到上述监控评估意图，比如SageMaker Model Monitor, SageMaker Clarify等。

模式19：两阶段预测

两阶段预测指将模型分为轻量版与完整版，分别部署在边缘端与云端，以兼顾响应速度和预测精度。
轻量模型通常负责本地触发或粗略识别，例如语音唤醒、候选筛选；云端模型则承担复杂语义理解、精确推理等任务。两者通过中间特征或触发信号交互，保证在网络可用时获得最优效果，在离线或低功耗场景下仍具备基本功能。
常见实践包括：Siri的本地唤醒与云端语言理解、Google翻译的在线高精度版与离线压缩版。还有AWS提供的AWS Panorama作为离线CV计算设备配合IoT摄像头使用。
实现上往往结合模型蒸馏、量化、OTA更新与降级策略，以在精度、延迟、功耗之间取得平衡。

模式20：带键值预测

带键值预测的思想是在预测API的输入输出中携带唯一识别键，用于标识每一次推理请求。这样做有助于在分布式或无状态部署中实现幂等性、缓存复用和可追踪性：即便同一请求被多节点处理，依然能唯一对应预测结果。在工程实践中，请求键可用于对齐异步预测输入与输出，在日志与监控中进行全链路追踪，检测重复请求、避免重复推理等。
书中提供了Keras级别的实现代码，但在AWS环境中，可通过API Gateway或SageMaker Endpoint在请求header或payload中传递唯一ID。
 

可复现设计模式

模式21：变换

如果直接使用原始数据训练模型，许多特征变换的细节将难以追踪，例如日期字符串被解析为星期几时所使用的时区与历法，或文本清洗中标点、停用词处理的规则。这些隐含变换无法复现，会导致模型解释性和可维护性大幅下降。
为此，需要在原始数据与训练数据之间建立显式的特征变换层。这一层可以通过多种方式实现：
  • 在数据管道中以BigQuery的Transform语法形式记录；
  • 在模型结构中加入输入特征处理层（如TensorFlow Transform）；
  • 使用特征存储库（Feature Store）集中管理特征定义与版本。
这种中间层能让模型训练具备可追踪性与可复现性，也能保证线上与线下特征一致。

模式22：可重复拆分

如何合理地拆分训练、验证和测试集，是模型可复现性的关键一环。
仅凭随机种子进行划分可能导致数据分布失衡或信息泄露，尤其在日期或用户相关特征上：同一天的数据或同一用户的多条记录可能被分到不同集合，破坏了样本独立性。
更稳健的做法是基于哈希拆分（Hash-Based Split）。通过对某些关键列（如date、userid或其组合）取Farm指纹哈希，再按哈希结果区间划分数据，可以保证：
  • 拆分结果稳定且可重复；
  • 相同实体或时间块不会被打散；
  • 数据追加或重跑时不会改变旧样本的划分。
在AWS体系中，可通过Glue SQL的FARM_FINGERPRINT()、Data Wrangler的自定义变换或SageMaker Processing Job实现，并将结果保存为可追踪的manifest文件。
这种方法不仅解决了随机拆分的不可复现性问题，也为数据治理和模型回溯打下基础。
在将不同日期的数据整合为训练集时，还需考虑时间依赖与季节性。如果把连续发生特定事件的日期（如几天连着的台风、促销、假期）拆成不同数据集，模型就会在训练阶段“提前看到”未来情境，从而产生信息泄露。
为减少这种风险，可以采用时间块划分：例如将每个月前 20 天作为训练集，中间 5 天作为验证集，最后 5 天作为测试集。这样的切分方式能保持时间顺序，同时尽量让每个周期都包含代表性样本。
在工程上，可通过SQL、Glue、Data Wrangler或Feature Store明确定义日期规则，实现可复现的时间划分逻辑。对于趋势性更强的任务，还可使用滚动窗口（rolling split）进行多次验证，以评估模型在不同时间段的稳定性。

模式23：桥接模式

桥接模式用于在数据模式或标签空间发生变更时，让新旧数据共存并保持模型可训练，它的目标不是“修正”老数据，而是让模型在过渡期内不崩溃。
当数据集中的增加某种分类（比如支付方式变多）后，如何让老数据集适应新的分类方式则成为了一个问题，毕竟老数据可能有上百万条，新数据可能只有几千条。
应对方式通常有两种，一种是概率方法，将老数据集中的支付方式字段按照新数据集中的比例随机分配，但这也只能保证数据在这一个维度上的分布。这种方式快速，无需修改特征结构，但会破坏数据整体的一致性。
另一种方式是静态方法，把“卡”的独热编码做一些修改，来描述新增的“积分卡”，以此作数据兼容。通常更推荐使用静态方法。这种方法能做到结构兼容，但会导致特征空间膨胀，可能引入稀疏噪声。
第三个做法是尽量使用新数据，对老数据狠狠地下采样，保证模型能收敛到不错的位置，至于下采样到多少个样本，则需要尝试。这种方法的好处是模型收敛稳定，问题是信息损失大。
相对理想的做法是，先通过静态方法让新旧数据共享语义空间，再逐步减少旧数据保证特征分布稳定。

模式24：窗口推理

通过在时间或序列维度上维持滑动窗口，保存有限的上下文信息，在流式环境中实现状态化推理。它是离线批处理与实时流推理之间的折中设计：既保持局部记忆，又能在高吞吐环境中稳定运行。
在训练阶段，我们通常拥有完整的数据集，可以直接计算全局统计量或训练时间序列模型。但在生产推理环境中，数据是逐条到达的流式输入（例如航班到港信息、传感器数据或网站点击流），模型无法一次看到所有历史样本。因此，窗口推理通过维护一个固定时长的滑动窗口来保留近期数据，用于：
  • 建立局部时间段的模型状态（如平均值、方差、模型参数）；
  • 在窗口关闭时（例如每10分钟）重新训练或更新模型；
  • 对最新到达的数据进行实时预测与异常检测
作者指出，窗口推理模式不限于时间序列或异常检测：
  • 在序列模型（如翻译模型、RNN、LSTM）中，模型需要历史上下文；
  • 对于这些模型，可以采用“窗口化上下文”输入的方式，让模型在无状态架构下仍能理解上下文。例如翻译任务中，每次提供前后各4个词的窗口，让模型在批量推理中保持局部语义一致。
  • 窗口选择过长会导致延迟与计算开销上升，过短则损失上下文。

模式25：工作流管道

它通过容器化与编排，使训练、验证、部署形成统一的自动化流水线，是将机器学习项目转化为可重复、可扩展、可追踪的软件工程系统的核心步骤，是MLOps的基础骨架。
引入流水线的好处在于无需手动运行各阶段脚本，每个步骤在独立容器中执行，数据、代码、模型参数均可复现，可与模型监控触发器联动，还可以让每一个步骤脱离云平台单独运行。
一个非常适合部署容器化工作流的方法是在K8S上部署Argo工作流管道。

模式26：特征仓库

特征仓库将特征的创建过程与使用特征的模型之间进行了分离，以简化特征的跨项目重用。
随着项目规模扩大，特征在单一notebook或管道内管理已经不切实际，如果每个项目都从头处理特征，数据治理将很困难，且阻碍了团队间知识共享和协作。
特征仓库和数据仓库不同，它充当数据工程师和数据科学家之间的接口，这样就有一个中央存储库来存放预先计算的特征。特征仓库为模型提供一致、可复现、可在线调用的特征，数据粒度关注样本级、实体级，数据形态以实体键+时间戳为核心，支持批量 + 实时流式更新，数据消费方式为训练集生成+在线推理实时特征查询，难点在训练/推理一致性。
在AWS的SageMaker中提供了Feature Store作为特征仓库。

模式27：模型版本控制

机器学习模型会随着时间老化，比如发生漂移，因此会训练新模型，但直接替换模型可能会破坏API接口或造成对老数据兼容性差的情况，因此需要导入模型版本机制。
这个模型提出，每个模型都需要以一个单独的版本存在，如独立的REST endpoint或独立的容器，而旧模型依旧通过旧有接口提供服务。这样可以保证兼容、回滚、灰度发布、溯源等各种需求的实现。
在AWS平台中，可以使用AWS SageMaker Model Registr实现这个模式。
 

负责任的人工智能

模式28：启发式基准

模型是否真的比简单规则强？如果一个复杂模型仅比几条启发式规则略优，却带来了更高的维护成本和更差的可解释性，那么它未必值得投入生产。换句话说，没有合理的基线，就无法判断模型的提升是否有意义。 启发式基准要求在开始训练之前，先定义一个可解释的启发式基准，用于和后续模型做比较。比如简单的“超过三倍标准差即判定异常”这样的规则。之后训练模型，提升精度召回率F1和AUC等数值，如果模型的性能显著高于启发式规则，才说明机器学习确实带来了价值。此外启发式基准还能在当模型的预测与人工的规则发生冲突时起到辅助判断的作用。

模式29：可解释预测

机器学习模型能输出一个预测值，却无法说明为什么，这会带来监管和信任问题，可解释预测模式强调的是，在模型预测阶段，生成或附带能说明“为何得出该结果”的可解释信息，它并不要求模型本身是可解释的（如线性回归），而是在推理结果层加一层解释机制。
可解释性分为三类，一类是模型内生性的，比如决策树，它适合低维特征强监管的场景，一类是事后解释型，适合于深层神经网络和集成树，采用LIME、SHAP、Grad-CAM等手段生成解释信息，第三类是采用代理模型，比如用决策树近似神经网络，用线性模型拟合复杂模型的输出。
在AWS平台中AWS SageMaker Clarify提供了可解释性报告。

模式30：公平性透镜

机器学习模型往往继承训练数据中的社会偏差，这个模式讲述了如何系统地检测并减少模型在不同人群间的偏差，确保模型决策“公平且可解释”。
模式要求在模型开发和部署阶段，通过一系列数据切片和公平性指标评估模型的行为是否在各子群体之间一致，它不是单一算法，而是一种观察模型的方式。
在模型训练后，要按某个特征（如性别、地区、贷款机构）进行切片，比较每个切片的准确率、假阳性率等，可视化模型在不同群体上的表现差异。