MLOps实战（1）
2022年11月正式接触MLOps，本篇记录理论学习。
理论概念
- 传统系统模块化设计，松耦合；
ML系统牵一发动全身（数据、model、参数改变触发新版本） - ML技术可能适用的场景：
（1）无法通过经验给出规则；
（2）已有好数据，业务依赖数据作决策；
（3）目标问题不断发生变化；
（4）无法扩展； - 业务需求是一个问题或者痛点，需要在冲突的需求之间找到合适的平衡点，并将其转化为模型的输入和输出、损失函数和性能指标的选择。
- MLOps提供所有已部署模型以及所有经过A/B测试的模型的性能的可见性。
- ML实验跟踪
（1）简化从实验到生产的模型迁移
（2）模型投产后的版本控制
（3）在ML模型注册中心管理模型工件
（4）在生产中测试各种模型版本
（5）serving - A/B test：统计技术，用于online模型评估
（1）确定商业目标的衡量指标（通常为代理指标）
（2）确定实验本身的参数（样本量、持续时间） - CI：持续集成，经常测试每个软件单元的代码库，以及通过单元测试、集成测试、系统测试来测试不同软件工件共同工作的完整性。在ML领域，需要：
（1）测试和验证模型代码及依赖组件的有效性
（2）测试和验证数据、数据模式、模型的性能
CD：持续部署，模型开发人员将更新后的模型、模型代码（含预测代码）上传至中央存储，然后部署到生产环境中。设计一个ML pipeline，将模型预测所涉及的流程和依赖自动部署或更新到一个ML服务。
建议：使用进程锁的单节点+基于Kubernetes的多节点部署方案。
交付：构建一个完全打包并经过验证的模型版本的过程，该版本可以部署到生产环境中。 - 模型衰退/出错的原因：
（1）新训练集质量不高
（2）数据漂移P(X) or 概念漂移P(y|X)-持续、周期性出现
（3）特征修复
（4）依赖资源改变 - 版本控制：假设条件、随机性、数据、设定值、结果、执行、环境，将版本控制和再现性相关的基础文档任务自动化，通过集成平台进行设计和部署。
- 模型评估指标
（1）统计：准确度、精准度、召回
（2）计算：平均延迟、延迟的95百分位等 - 模型监控
（1）资源层面：CPU、RAM、网络使用率和磁盘空间是否符合预期？请求是否以预期的速度得到处理？
（2）性能层面：随着时间的推移，模型仍然是新输入数据模式的准确表示吗？性能和设计阶段一样好吗？
ML
- 监督学习：分类、回归；无监督学习：聚类
- model choose –》algorithm + config + training;
error & performance trade off - 泛化：对新鲜样本进行准确预测的能力
Engineering
- 特征工程：对原始数据或中间特征进行一系列工程化处理，映射为一个更适合建模的新的表现形式，以降低原始数据的噪声和冗余。
- 基类（接口）：定义一个标准和基础功能，独立软件块之间的“边界”，定义不同组件的交流方式。
- 工件：可测试和可部署的项目包
MLOps
- ML模型需要两个版本的管道：一个用于训练-history，一个用于服务-real time。
将管道中的节点进行抽象，整个管道作为产品进行集中化开发和维护。
可用于抽象的节点：
（1）特征存储
（2）训练过程各节点模块化
（3）Maas，服务管道封装成通用的模型服务接口，一键生成模型服务 - 首先确定业务可以产生哪些数据，目标输出是什么，然后界定哪些模型适合加工这类输入和输出;
规划ML任务的步骤：
（1）将业务目标框定在一个ML范式中
（2）评估该任务的可行性，根据评估结果，重新调整ML框架和算法，直到获取满意的结果为止 - 数据准备-特征工程-模型开发-模型部署-模型监控
- 评估指标
（1）模型表现（代理指标-模型侧指标）-模型目标-模型开发时期
（2）业务表现-业务目标-模型部署时期 - ML项目生命周期
（1）定业务目标-行业专家和数据科学家合作
（2）数据准备：clean-feature engineering-sample
（3）模型实验：通过离线评估进行最佳模型的选择
（4）模型工程：对实验过程进行脚本封装并生成ML管道
（5）模型评估
（6）模型预测
（7）模型监控 - 模型部署
-生成代码&模型的序列化：将代码、环境依赖、模型实例部署到中央存储，为后续模型的版本化及回溯使用。
-模型的服务化：通过数据库批量推理模式（offline）、推入式推理模式、单服务推理模式和微服务推理模式为应用提供服务。
本博客所有文章除特别声明外，均采用 CC BY-SA 4.0 协议 ，转载请注明出处！