implementing-mlops

MLOps 模式

将机器学习模型从实验阶段投入生产部署并进行监控。

用途

为 ML 工程师和平台团队提供战略指导，帮助其构建生产级 ML 基础设施。涵盖完整生命周期：实验跟踪、模型注册表、特征存储、部署模式、流水线编排和监控。

何时使用此技能

在以下情况下使用此技能：

• 为生产 ML 系统设计 MLOps 基础设施
• 选择实验跟踪平台（MLflow、Weights & Biases、Neptune）
• 实现在线／离线特征服务所需的特征存储
• 选择模型服务解决方案（Seldon Core、KServe、BentoML、TorchServe）
• 构建用于训练、评估和部署的 ML 流水线
• 设置模型监控和漂移检测
• 建立模型治理与合规框架
• 优化 ML 推理成本和性能
• 从笔记本迁移到生产 ML 系统
• 实现持续训练和自动化再训练

核心概念

1. 实验跟踪

系统化地跟踪实验，确保可复现性并促进协作。

关键组件：

• 参数：每次训练运行记录的超参数
• 指标：随时间跟踪的性能指标（准确率、损失、F1）
• 工件：模型权重、图表、数据集、配置文件
• 元数据：标签、描述、Git 提交 SHA、环境详情

平台对比：

MLflow（开源标准）：

• 与框架无关（PyTorch、TensorFlow、scikit-learn、XGBoost）
• 可自托管或部署于任意云平台
• 集成模型注册表
• 基础 UI，可满足大多数使用场景
• 免费，但需要管理基础设施

Weights & Biases（SaaS，以协作为重点）：

• 高级可视化和仪表板
• 集成超参数优化（Sweeps）
• 出色的团队协作功能
• SaaS 费用随使用量增长
• 一流的 UI

Neptune.ai（企业级）：

• 企业功能（RBAC、审计日志、合规）
• 集成生产环境监控
• 费用高于 W&B
• 适用于受监管行业

选择标准：

• 需要开源 → MLflow
• 团队协作至关重要 → Weights & Biases
• 企业合规（RBAC、审计）→ Neptune.ai
• 主要需求是超参数优化 → Weights & Biases（Sweeps）

详细比较和决策框架，请参阅 references/experiment-tracking.md。

2. 模型注册表和版本控制

集中管理模型工件，并进行版本控制和阶段管理。

模型注册表组件：

• 模型工件（权重、序列化模型）
• 训练指标（准确率、F1、AUC）
• 训练期间使用的超参数
• 训练数据集版本
• 特征架构（输入／输出签名）
• 模型卡片（文档、使用场景、局限性）

阶段管理：

• None：新注册的模型
• Staging：在预生产环境中测试
• Production：为实时流量提供服务
• Archived：已弃用，为满足合规要求而保留

版本控制策略：

模型语义化版本控制：

• 主版本（v2.0.0）：输入／输出架构发生不兼容变更
• 次版本（v1.1.0）：新增功能，向后兼容
• 补丁版本（v1.0.1）：修复错误，使用新数据重新训练模型

基于 Git 的版本控制：

• 在 Git 中管理模型代码（训练脚本、配置）
• 在 DVC（Data Version Control）或 Git-LFS 中管理模型权重
• 通过提交 SHA 和数据版本哈希确保可复现性

有关模型溯源跟踪和注册表模式，请参阅 references/model-registry.md。

3. 特征存储

集中管理特征工程，确保训练和推理之间保持一致。

**解决的问题：**训练与服务偏差

• 训练：使用未来信息计算特征（数据泄漏）
• 推理：仅使用过去的数据计算特征
• 结果：模型在训练中表现良好，但在生产环境中失效

特征存储解决方案：

在线特征存储：

• 目的：以低延迟检索特征，用于实时推理
• 存储：Redis、DynamoDB、Cassandra（键值存储）
• 延迟：特征查询低于 10 毫秒
• 使用场景：实时预测（欺诈检测、推荐）

离线特征存储：

• 目的：存储历史特征数据，用于训练和批量推理
• 存储：Parquet 文件（S3/GCS）、数据仓库（Snowflake、BigQuery）
• 延迟：数秒到数分钟（批量检索）
• 使用场景：模型训练、回测、批量预测

时点正确性：

• 确保训练期间不会发生未来数据泄漏
• T 时刻的特征值仅使用 T 时刻之前可用的数据
• 对于避免训练指标过于乐观至关重要

平台对比：

Feast（开源、云无关）：

• 最受欢迎的开源特征存储
• 支持 Redis、DynamoDB、Datastore（在线）以及 Parquet、BigQuery、Snowflake（离线）
• 云无关，无供应商锁定
• 社区活跃，采用率不断上升

Tecton（托管、生产级）：

• 兼容 Feast API
• 完全托管的服务
• 集成监控和治理
• 成本较高，面向企业

SageMaker Feature Store（AWS）：

• 与 AWS 生态系统集成
• 托管在线/离线存储
• 受 AWS 生态系统锁定

Databricks Feature Store（Databricks）：

• 与 Unity Catalog 集成
• 使用 Delta Lake 进行离线存储
• 受 Databricks 生态系统锁定

选择标准：

• 开源、云无关 → Feast
• 托管解决方案、生产级 → Tecton
• AWS 生态系统 → SageMaker Feature Store
• Databricks 用户 → Databricks Feature Store

有关特征工程模式和实现，请参阅 references/feature-stores.md。

4. 模型服务模式

部署模型以支持同步、异步、批量或流式推理。

服务模式：

REST API 部署：

• 模式：用于同步预测的 HTTP 端点
• 延迟：可接受 <100ms
• 用例：请求-响应应用
• 工具：Flask、FastAPI、BentoML、Seldon Core

gRPC 部署：

• 模式：用于低延迟推理的高性能 RPC
• 延迟：目标 <10ms
• 用例：微服务、对延迟要求严格的应用
• 工具：TensorFlow Serving、TorchServe、Seldon Core

批量推理：

• 模式：离线处理大型数据集
• 延迟：可接受数分钟至数小时
• 用例：每天或每小时对数百万条记录进行预测
• 工具：Spark、Dask、Ray

流式推理：

• 模式：对流式数据进行实时预测
• 延迟：毫秒级
• 用例：欺诈检测、异常检测、实时推荐
• 工具：Kafka + Flink/Spark Streaming

平台对比：

Seldon Core（原生支持 Kubernetes，功能高级）：

• 高级部署策略（金丝雀、A/B 测试、多臂老虎机）
• 支持多种框架
• 集成可解释性（Alibi）
• 复杂度高，学习曲线陡峭

KServe（CNCF 标准）：

• 标准化的 InferenceService API
• 无服务器伸缩（通过 Knative 实现缩容至零）
• 原生支持 Kubernetes
• 应用日益广泛，获得 CNCF 支持

BentoML（以 Python 为先，简单易用）：

• 最容易上手
• 出色的开发者体验
• 本地测试 → 云端部署
• 复杂度低于 Seldon/KServe

TorchServe（PyTorch 官方）：

• 专用于 PyTorch 的模型服务
• 达到生产级别，针对 PyTorch 模型进行了优化
• 用于多框架场景时灵活性较低

TensorFlow Serving（TensorFlow 官方）：

• 专用于 TensorFlow 的模型服务
• 达到生产级别，针对 TensorFlow 模型进行了优化
• 用于多框架场景时灵活性较低

选择标准：

• Kubernetes、高级部署 → Seldon Core 或 KServe
• 以 Python 为先、简单易用 → BentoML
• 专用于 PyTorch → TorchServe
• 专用于 TensorFlow → TensorFlow Serving
• 托管式解决方案 → SageMaker/Vertex AI/Azure ML

有关模型优化和服务基础设施，请参阅 references/model-serving.md。

5. 部署策略

安全地部署模型，并具备回滚能力。

蓝绿部署：

• 两个相同的环境（蓝色：当前环境，绿色：新环境）
• 部署到绿色环境并进行测试，然后立即切换全部流量
• 可立即回滚（切回蓝色环境）
• 权衡：需要 2 倍基础设施，切换方式非此即彼

金丝雀部署：

• 逐步向部分流量推出
• 随时间按 5% → 10% → 25% → 50% → 100% 的比例路由流量
• 在每个阶段监控指标，若性能下降则回滚
• 权衡：路由逻辑复杂，部署时间较长

影子部署：

• 新模型接收流量，但不使用其预测结果
• 离线比较新旧模型
• 对生产环境零风险
• 权衡：需要 2 倍计算资源，反馈延迟

A/B 测试：

• 在不同模型版本之间分配流量
• 衡量业务指标（转化率、收入）
• 进行统计显著性检验
• 用例：优化业务结果，而不只是 ML 指标

多臂老虎机（MAB）：

• Epsilon-greedy：探索（尝试新模型）与利用（使用最佳模型）
• Thompson Sampling：通过贝叶斯方法进行探索
• 用例：持续优化，比 A/B 测试更快收敛

选择标准：

• 低风险模型 → 蓝绿部署（立即切换）
• 中风险模型 → 金丝雀部署（逐步推出）
• 高风险模型 → 影子部署（在生产环境测试，不产生影响）
• 业务优化 → A/B 测试或 MAB

有关部署架构和示例，请参阅 references/deployment-strategies.md。

6. ML 流水线编排

自动化训练、评估和部署工作流。

训练流水线阶段：

1. 数据验证（Great Expectations、架构检查）
2. 特征工程（转换原始数据）
3. 数据拆分（训练集／验证集／测试集）
4. 模型训练（超参数调优）
5. 模型评估（准确率、公平性、可解释性）
6. 模型注册（指标达到阈值时推送到注册表）
7. 部署（晋级到预发布环境／生产环境）

持续训练模式：

• 监控生产数据是否发生漂移
• 检测数据分布变化（KS 检验、PSI）
• 检测到漂移时触发自动重新训练
• 部署前验证新模型
• 通过金丝雀或影子策略部署

平台比较：

Kubeflow Pipelines（原生支持 ML、基于 Kubernetes）：

• 面向 ML 的流水线编排
• 原生支持 Kubernetes（随 K8s 扩展）
• 基于组件（可复用的流水线步骤）
• 与 Katib 集成（超参数调优）

Apache Airflow（成熟、通用）：

• 最成熟的编排平台
• 生态系统庞大，集成丰富
• 基于 Python 的 DAG
• 并非专为 ML 设计，但广泛用于 ML 工作流

Metaflow（Netflix 出品，适合数据科学）：

• 以人为中心的设计，方便数据科学家使用
• 出色的本地开发体验
• 内置版本控制
• 比 Kubeflow/Airflow 更简单

Prefect（现代化、原生支持 Python）：

• 动态工作流，而非静态 DAG
• 错误处理优于 Airflow
• 现代化的 UI 和开发者体验
• 社区不断壮大

Dagster（基于资产、注重测试）：

• 基于资产的思维方式（不只是任务依赖关系）
• 强大的测试和数据质量功能
• 采用现代化方法，适合数据团队
• 社区规模小于 Airflow

选择标准：

• 专用于 ML、基于 Kubernetes → Kubeflow Pipelines
• 成熟、经过实战检验 → Apache Airflow
• 面向数据科学家、易于使用 → Metaflow
• 面向软件工程师、注重测试 → Dagster
• 现代化、比 Airflow 更简单 → Prefect

如需了解流水线架构和示例，请参阅 references/ml-pipelines.md。

7. 模型监控与可观测性

监控生产模型的漂移、性能和质量。

数据漂移检测：

• 定义：输入特征的分布随时间变化
• 影响：模型基于旧分布训练，预测效果下降
• 检测方法：
  • Kolmogorov-Smirnov（KS）检验：比较分布
  • Population Stability Index（PSI）：衡量分布变化
  • 卡方检验：用于类别特征
• 操作：检测到漂移时触发自动重新训练

模型漂移检测：

• 定义：模型预测质量随时间下降
• 影响：准确率、精确率、召回率下降
• 检测方法：
  • 真实标签准确率（延迟标签）
  • 预测分布变化
  • 校准漂移（预测概率与实际结果之间的差异）
• 操作：通知团队，触发重新训练

性能监控：

• 指标：
  • 延迟：P50、P95、P99 推理时间
  • 吞吐量：每秒预测数
  • 错误率：失败的预测数／预测总数
  • 资源利用率：CPU、内存、GPU 使用率
• 告警阈值：
  • P95 延迟 > 100ms → 告警
  • 错误率 > 1% → 告警
  • 准确率下降 > 5% → 触发重新训练

业务指标监控：

• 下游影响：转化率、收入、用户满意度
• 模型预测与业务结果的相关性
• 用例：优化模型以提升业务价值，而不只是 ML 指标

工具：

• Evidently AI：数据漂移、模型漂移、数据质量报告
• Prometheus + Grafana：性能指标、自定义仪表板
• Arize AI：ML 可观测性平台
• Fiddler：模型监控和可解释性

如需了解监控架构和实现，请参阅 references/model-monitoring.md。

8. 模型优化技术

缩小模型体积并降低推理延迟。

量化：

• 将模型权重从 float32 转换为 int8
• 模型体积缩小 4 倍
• 推理速度提升 2–3 倍
• 精度影响：通常极小（降幅 <1%）
• 工具：PyTorch quantization、TensorFlow Lite、ONNX Runtime

模型蒸馏：

• 训练小型学生模型，模仿大型教师模型
• 将教师模型（BERT-large）的知识迁移到学生模型（DistilBERT）
• 体积缩小 2–10 倍
• 速度提升 2–10 倍
• 使用场景：在边缘设备上部署小型模型，降低推理成本

ONNX 转换：

• 将模型转换为 Open Neural Network Exchange (ONNX) 格式
• 跨框架兼容性（PyTorch → ONNX → TensorFlow）
• 使用 ONNX Runtime 优化推理
• 速度提升：比原生框架快 1.5–3 倍

模型剪枝：

• 移除神经网络中不太重要的权重
• 稀疏度：将 30–90% 的权重设为零
• 体积缩小 2–10 倍
• 精度影响：采用结构化剪枝时极小

如需了解优化技术和示例，请参阅 references/model-serving.md。

9. LLMOps 模式

通过专门的模式实现大模型的运营化。

LLM 微调工作流：

• LoRA（低秩适配）：参数高效的微调方法
• QLoRA：量化 LoRA（4-bit 量化）
• 工作流：基础模型 → 微调数据集 → LoRA 适配器 → 合并后的模型
• 工具：Hugging Face PEFT、Axolotl

提示词版本管理：

• 对提示词进行版本控制（Git、提示词管理平台）
• 对提示词进行 A/B 测试，以优化质量和成本
• 随时间监控提示词效果

RAG 系统监控：

• 检索质量：检索到的文档的相关性
• 生成质量：答案准确性、幻觉检测
• 端到端延迟：检索 + 生成时间
• 工具：LangSmith、Arize Phoenix

LLM 推理优化：

• vLLM：高吞吐量 LLM 服务
• TensorRT-LLM：NVIDIA 优化的 LLM 推理
• Text Generation Inference (TGI)：Hugging Face 服务
• 批处理：通过动态批处理提升吞吐量

嵌入模型管理：

• 与模型一同对嵌入进行版本管理
• 监控嵌入漂移（分布变化）
• 底层模型变化时更新嵌入

如需了解 LLMOps 模式和实现，请参阅 references/llmops-patterns.md。

10. 模型治理与合规

建立模型治理机制，以管理模型风险并满足法规要求。

模型卡：

• 文档：模型用途、训练数据、性能指标
• 局限性：已知偏见、失效模式、范围外使用场景
• 伦理考量：公平性、隐私、社会影响
• 模板：Model Card Toolkit (Google)

偏见与公平性检测：

• 衡量不同人口群体间的差异化影响
• 工具：Fairlearn、AI Fairness 360 (IBM)
• 指标：人口统计均等、均等化赔率、校准
• 缓解方法：重新加权、对抗式去偏、阈值优化

法规合规：

• EU AI Act：高风险 AI 系统需要文档记录和监控
• 模型风险管理 (SR 11-7)：银行业要求
• GDPR：自动化决策的解释权
• HIPAA：医疗数据隐私

审计追踪：

• 记录所有模型版本、训练运行和部署
• 跟踪批准模型状态变更（暂存 → 生产）的人员
• 保留历史预测结果，以供合规审计
• 工具：MLflow、Neptune.ai（审计日志）

如需了解治理框架和合规要求，请参阅 references/governance.md。

决策框架

框架 1：实验跟踪平台选择

决策树：

从主要需求入手：

• 要求开源、可自托管 → MLflow
• 团队协作、高级可视化（预算充足） → Weights & Biases
• 团队协作、高级可视化（无预算） → MLflow
• 企业合规（审计日志、RBAC） → Neptune.ai
• 主要用例是超参数优化 → Weights & Biases（Sweeps）

详细标准：

标准	MLflow	Weights & Biases	Neptune.ai
成本	免费	$200/用户/月	$300/用户/月
协作	基础	优秀	良好
可视化	基础	优秀	良好
超参数调优	外部（Optuna）	集成（Sweeps）	基础
模型注册表	包含	附加项	包含
可自托管	是	否（仅付费版）	有限
企业功能	无	有限	优秀

按组织规模推荐：

• 初创公司（<50 人）：MLflow（免费，足够用）或 W&B（预算充足时）
• 成长期（50-500 人）：Weights & Biases（团队协作）
• 企业（>500 人）：Neptune.ai（合规）或 MLflow（成本）

如需详细的决策框架，请参阅 references/decision-frameworks.md。

框架 2：特征存储选择

决策矩阵：

主要需求：

• 开源、与云无关 → Feast
• 托管解决方案、生产级、多云 → Tecton
• AWS 生态系统 → SageMaker Feature Store
• GCP 生态系统 → Vertex AI Feature Store
• Azure 生态系统 → Azure ML Feature Store
• Databricks 用户 → Databricks Feature Store
• 带 UI 的可自托管方案 → Hopsworks

标准对比：

因素	Feast	Tecton	Hopsworks	SageMaker FS
成本	免费	$$$$	免费（自托管）	$$$
在线服务	Redis、DynamoDB	托管	RonDB	托管
离线存储	Parquet、BigQuery、Snowflake	托管	Hive、S3	S3
时点一致性	是	是	是	是
监控	外部	集成	基础	外部
云锁定	无	无	无	AWS

推荐：

• 开源、自行管理 → Feast
• 托管、生产级 → Tecton
• AWS 生态系统 → SageMaker Feature Store
• Databricks 用户 → Databricks Feature Store

如需详细的决策框架，请参阅 references/decision-frameworks.md。

框架 3：模型服务平台选择

决策树：

基础设施：

• 基于 Kubernetes → 是否需要高级部署模式？
  • 是 → Seldon Core（功能最全面）或 KServe（CNCF 标准）
  • 否 → BentoML（更简单，以 Python 为先）
• 云原生（托管） → 云服务提供商？
  • AWS → SageMaker Endpoints
  • GCP → Vertex AI Endpoints
  • Azure → Azure ML Endpoints
• 特定框架 → 框架？
  • PyTorch → TorchServe
  • TensorFlow → TensorFlow Serving
• 无服务器 / 最少基础设施 → BentoML 或 Cloud Functions

详细标准：

功能	Seldon Core	KServe	BentoML	TorchServe
Kubernetes 原生	是	是	可选	否
多框架支持	是	是	是	仅 PyTorch
部署策略	优秀	良好	基础	基础
可解释性	集成	集成	外部	无
复杂度	高	中	低	低
学习曲线	陡峭	中等	平缓	平缓

推荐：

• Kubernetes、高级部署 → Seldon Core 或 KServe
• 以 Python 为先、追求简洁 → BentoML
• 专用于 PyTorch → TorchServe
• 专用于 TensorFlow → TensorFlow Serving
• 托管解决方案 → SageMaker/Vertex AI/Azure ML

如需详细的决策框架，请参阅 references/decision-frameworks.md。

框架 4：ML 流水线编排选择

决策矩阵：

主要用例：

• ML 专用流水线、原生支持 Kubernetes → Kubeflow Pipelines
• 通用编排、成熟的生态系统 → Apache Airflow
• 数据科学工作流、易于使用 → Metaflow
• 现代方式、基于资产的思维 → Dagster
• 动态工作流、原生支持 Python → Prefect

标准对比：

因素	Kubeflow	Airflow	Metaflow	Dagster	Prefect
ML 专用性	出色	良好	出色	良好	良好
Kubernetes	原生支持	兼容	可选	兼容	兼容
学习曲线	陡峭	陡峭	平缓	中等	中等
成熟度	高	非常高	中等	中等	中等
社区	大型	非常庞大	不断壮大	不断壮大	不断壮大

建议：

• ML 专用、Kubernetes → Kubeflow Pipelines
• 成熟、久经考验 → Apache Airflow
• 数据科学家 → Metaflow
• 软件工程师 → Dagster
• 现代且比 Airflow 简单 → Prefect

如需详细的决策框架，请参阅 references/decision-frameworks.md。

实现模式

模式 1：端到端 ML 流水线

自动化从数据到部署的完整 ML 工作流。

流水线阶段：

1. 数据验证（Great Expectations）
2. 特征工程（转换原始数据）
3. 数据拆分（训练集／验证集／测试集）
4. 模型训练（含超参数调优）
5. 模型评估（准确率、公平性、可解释性）
6. 模型注册（推送到 MLflow 注册表）
7. 部署（推广至预发布／生产环境）

架构：

Data Lake → Data Validation → Feature Engineering → Training → Evaluation
    ↓
Model Registry (staging) → Testing → Production Deployment

如需实现详情和代码示例，请参阅 references/ml-pipelines.md。

模式 2：持续训练

根据漂移检测自动重新训练模型。

工作流：

1. 监控生产数据的分布变化
2. 检测数据漂移（KS 检验、PSI）
3. 触发自动重新训练流水线
4. 验证新模型（准确率、公平性）
5. 通过金丝雀策略部署（5% → 100%）
6. 监控新模型的性能
7. 如果指标下降则回滚

触发条件：

• 定期：每日／每周重新训练
• 数据漂移：KS 检验 p 值 < 0.05
• 模型漂移：准确率下降 > 5%
• 数据量：新增训练数据超过阈值（10K 个样本）

如需实现详情，请参阅 references/ml-pipelines.md。

模式 3：特征存储集成

确保训练和推理使用一致的特征。

架构：

Offline Store (Training):
  Parquet/BigQuery → Point-in-Time Join → Training Dataset

Online Store (Inference):
  Redis/DynamoDB → Low-Latency Lookup → Real-Time Prediction

时间点正确性：

• 训练：获取特定时间戳对应的特征（不使用未来数据）
• 推理：获取最新特征（仅使用过去的数据）
• 保证：训练和推理使用相同的特征逻辑

如需实现详情和代码示例，请参阅 references/feature-stores.md。

模式 4：影子部署测试

无风险地在生产环境中测试新模型。

工作流：

1. 以影子模式部署新模型（v2）
2. v2 接收生产流量的副本
3. 响应使用 v1 的预测结果（不影响用户）
4. 离线比较 v1 和 v2 的预测结果
5. 分析差异，衡量 v2 的准确率
6. 如果性能可接受，则将 v2 推广到生产环境

用例：

• 高风险模型（金融、医疗保健、关键安全领域）
• 切换前需要进行广泛测试
• 在真实生产数据上比较模型行为

如需部署架构，请参阅 references/deployment-strategies.md。

工具建议

生产就绪工具（采用率高）

MLflow - 实验跟踪与模型注册表

• GitHub Stars：20,000+
• 信任评分：95/100
• 使用场景：实验跟踪、模型注册表、模型服务
• 优势：开源、与框架无关、支持自托管
• 入门：pip install mlflow && mlflow server

Feast - 特征存储

• GitHub Stars：5,000+
• 信任评分：85/100
• 使用场景：在线/离线特征服务、保证时间点正确性
• 优势：与云平台无关，最受欢迎的开源特征存储
• 入门：pip install feast && feast init

Seldon Core - 模型服务（高级）

• GitHub Stars：4,000+
• 信任评分：85/100
• 使用场景：Kubernetes 原生服务、高级部署模式
• 优势：金丝雀发布、A/B 测试、MAB、可解释性
• 局限：复杂度高，学习曲线陡峭

KServe - 模型服务（CNCF 标准）

• GitHub Stars：3,500+
• 信任评分：85/100
• 使用场景：标准化服务 API、无服务器扩缩容
• 优势：CNCF 项目、集成 Knative、采用率不断提高
• 局限：需要 Kubernetes

BentoML - 模型服务（简单易用）

• GitHub Stars：6,000+
• 信任评分：80/100
• 使用场景：轻松打包、Python 优先的部署方式
• 优势：学习曲线最平缓，开发者体验出色
• 局限：高级功能少于 Seldon/KServe

Kubeflow Pipelines - ML 编排

• GitHub Stars：14,000+（Kubeflow 项目）
• 信任评分：90/100
• 使用场景：ML 专用工作流、Kubernetes 原生工作流
• 优势：ML 原生、组件可复用、集成 Katib
• 局限：需要 Kubernetes，学习曲线陡峭

Weights & Biases - 实验跟踪（SaaS）

• 信任评分：90/100
• 使用场景：团队协作、高级可视化、超参数调优
• 优势：一流的 UI、集成 Sweeps、社区活跃
• 局限：SaaS 定价，没有免费的自托管版本

详细的工具对比请参阅 references/tool-recommendations.md。

按组织类型推荐的工具栈

初创公司（成本优化、简单易用）：

• 实验跟踪：MLflow（免费、自托管）
• 特征存储：初期不使用 → 需要时再使用 Feast
• 模型服务：BentoML（简单易用）或云函数
• 编排：Prefect 或 cron 作业
• 监控：基础日志记录 + Prometheus

成长型公司（均衡）：

• 实验跟踪：Weights & Biases 或 MLflow
• 特征存储：Feast（开源、生产就绪）
• 模型服务：BentoML 或 KServe（基于 Kubernetes）
• 编排：Kubeflow Pipelines 或 Airflow
• 监控：Evidently + Prometheus + Grafana

企业（全栈）：

• 实验跟踪：MLflow（自托管）或 Neptune.ai（合规性）
• 特征存储：Tecton（托管）或 Feast（自托管）
• 模型服务：Seldon Core（高级）或 KServe
• 编排：Kubeflow Pipelines 或 Airflow
• 监控：Evidently + Prometheus + Grafana + PagerDuty

云原生（托管服务）：

• AWS：SageMaker（端到端平台）
• GCP：Vertex AI（端到端平台）
• Azure：Azure ML（端到端平台）

针对特定场景的建议，请参阅 references/scenarios.md。

常见场景

场景 1：初创公司 MLOps 工具栈

背景： 一家有 20 名员工的初创公司，拥有 5 名数据科学家和 3 个模型（欺诈检测、推荐、客户流失），预算有限。

建议：

• 实验跟踪：MLflow（免费、自托管）
• 模型服务：BentoML（简单，便于快速迭代）
• 编排：Prefect（比 Airflow 更简单）
• 监控：Prometheus + 基础漂移检测
• 特征存储：初期跳过，使用数据库表

理由：

• 尽量降低成本（全部开源、自托管）
• 快速迭代（BentoML 易于部署）
• 避免过度设计（只有 3 个模型，无需 Kubeflow）
• 扩展到 10 个以上模型时再添加特征存储（Feast）

详细场景请参阅 references/scenarios.md。

场景 2：企业级 ML 平台

**背景：**拥有 500 名员工、50 名数据科学家、100 多个模型的公司，需要满足法规合规要求并支持多云。

建议：

• 实验跟踪：Neptune.ai（合规、审计日志）或 MLflow（成本）
• 特征存储：Feast（可自托管、与云无关）
• 模型服务：Seldon Core（高级部署模式）
• 编排：Kubeflow Pipelines（原生支持 ML、Kubernetes）
• 监控：Evidently + Prometheus + Grafana + PagerDuty

理由：

• 需要满足合规要求（Neptune 审计日志、RBAC）
• 支持多云（Feast 与云无关）
• 支持高级部署（Seldon 金丝雀发布、A/B 测试）
• 支持规模化（通过 Kubernetes 管理 100 多个模型）

详细场景请参阅 references/scenarios.md。

场景 3：LLM 微调流水线

**背景：**针对特定领域的用例微调 LLM，并将其部署用于生产服务。

建议：

• 实验跟踪：MLflow（跟踪微调运行）
• 流水线编排：Kubeflow Pipelines（GPU 调度）
• 模型服务：vLLM（高吞吐量 LLM 服务）
• 提示词版本控制：Git + LangSmith
• 监控：Arize Phoenix（RAG 监控）

理由：

• 跟踪微调实验（LoRA 适配器、超参数）
• GPU 编排（在 Kubernetes 上运行 Kubeflow）
• 高效的 LLM 服务（vLLM 针对吞吐量进行了优化）
• 监控 RAG 系统（检索 + 生成质量）

详细场景请参阅 references/scenarios.md。

与其他技能集成

直接依赖：

• ai-data-engineering：特征工程、ML 算法、数据准备
• kubernetes-operations：K8s 集群管理、ML 工作负载的 GPU 调度
• observability：ML 系统的监控、告警、分布式追踪

互补技能：

• data-architecture：为 ML 模型提供数据的数据流水线、数据湖
• data-transformation：使用 dbt 构建特征转换流水线
• streaming-data：使用 Kafka、Flink 实现实时 ML 推理
• designing-distributed-systems：ML 工作负载的可扩展性模式
• api-design-principles：ML 模型 API、REST/gRPC 服务模式

下游技能：

• building-ai-chat：使用 ML 模型的 LLM 驱动应用
• visualizing-data：ML 指标和监控仪表板

最佳实践

1. 对所有内容进行版本控制：

   • 代码：使用 Git 提交 SHA 确保可复现性
   • 数据：使用 DVC 或数据版本哈希
   • 模型：语义化版本控制（v1.2.3）
   • 特征：特征存储版本控制

2. 自动化测试：

   • 单元测试：模型能否加载、接受输入并生成输出
   • 集成测试：端到端流水线执行
   • 模型验证：准确率阈值、公平性检查

3. 持续监控：

   • 数据漂移：分布随时间发生变化
   • 模型漂移：准确率下降
   • 性能：延迟、吞吐量、错误率

4. 从简单方案开始：

   • 从 MLflow + 基础服务（BentoML）开始
   • 按需增加复杂性（特征存储、Kubeflow）
   • 避免过度设计（不要为了 2 个模型构建 Kubeflow）

5. 确保时点正确性：

   • 使用特征存储，避免训练与服务之间的偏差
   • 确保训练过程中没有未来数据泄漏
   • 确保训练和推理使用一致的特征逻辑

6. 部署策略：

   • 中风险模型使用金丝雀发布（逐步推出）
   • 高风险模型使用影子部署（对生产环境零影响）
   • 始终准备回滚方案（立即切换到上一版本）

7. 治理：

   • 模型卡片：记录模型用途、局限性和偏见
   • 审计跟踪：跟踪所有模型版本、部署和审批
   • 合规：EU AI Act、模型风险管理（SR 11-7）

8. 成本优化：

   • 量化：将模型大小缩小 4 倍，将推理速度提升 2-3 倍
   • 抢占式实例：在可抢占式 VM 上训练（降低 60-90% 的成本）
   • 自动扩缩容：根据负载调整推理端点的规模

反模式

❌ 在生产环境中使用 Notebook：

• 切勿将 Jupyter Notebook 部署到生产环境
• Notebook 仅用于实验
• 生产环境：使用脚本、Docker 容器和 CI/CD 流水线

❌ 手动部署模型：

• 使用 CI/CD 流水线自动化部署
• 使用模型注册表的阶段转换（staging → production）
• 消除人为错误，确保可复现性

❌ 不进行监控：

• 未经监控的生产模型会在无声无息中退化
• 实施漂移检测（数据漂移、模型漂移）
• 为准确率下降和延迟激增设置告警

❌ 训练与服务偏差：

• 训练与推理使用不同的特征逻辑
• 使用特征存储确保一致性
• 在部署到生产环境之前测试特征一致性

❌ 忽视数据质量：

• 垃圾进，垃圾出（GIGO）
• 验证数据架构、范围和分布
• 使用 Great Expectations 验证数据

❌ 过度设计：

• 不要为了 2 个模型就搭建 Kubeflow
• 从简单方案开始（MLflow + BentoML）
• 仅在必要时增加复杂度（10 个以上模型）

❌ 没有回滚计划：

• 始终确保能够回滚到之前的模型版本
• 蓝绿、金丝雀和影子部署支持即时回滚
• 在部署到生产环境之前测试回滚流程

延伸阅读

参考文件：

• 实验跟踪 - 深入了解 MLflow、W&B、Neptune
• 模型注册表 - 版本控制、沿袭关系、阶段转换
• 特征存储 - Feast、Tecton、在线/离线模式
• 模型服务 - Seldon、KServe、BentoML、优化
• 部署策略 - 蓝绿、金丝雀、影子、A/B
• ML 流水线 - Kubeflow、Airflow、训练流水线
• 模型监控 - 漂移检测、可观测性
• LLMOps 模式 - LLM 微调、RAG、提示词
• 决策框架 - 工具选择框架
• 工具推荐 - 详细比较
• 场景 - 初创公司、企业、LLMOps 使用场景
• 治理 - 模型卡、合规性、公平性

示例项目：

• examples/mlflow-experiment/ - 完整的 MLflow 配置
• examples/feast-feature-store/ - Feast 在线/离线
• examples/seldon-deployment/ - 金丝雀、A/B 测试
• examples/kubeflow-pipeline/ - 端到端流水线
• examples/monitoring-dashboard/ - Evidently + Prometheus

脚本：

• scripts/setup_mlflow_server.sh - 使用 PostgreSQL + S3 配置 MLflow
• scripts/feast_feature_definition_generator.py - 生成 Feast 特征
• scripts/model_validation_suite.py - 自动化模型测试
• scripts/drift_detection_monitor.py - 定时漂移检测
• scripts/kubernetes_model_deploy.py - 部署到 Seldon/KServe