1、治理需求
1.1、背景
- 如果企业和政府想要有比较好的ROI，就需要积极面对MLOps带来的风险，对过程进行较为严谨的治理。
1.2、提出方
- 政府
- 企业
1.3、缺点
- 减缓模型交付
- 耗费业务资金
- 官僚主义
- ...
1.4、优点
- 有效的管理风险
- 有力的决策依据
- 流程的闭环
- ...
2、风险级别
2.1、评估风险的几个方面
- 模型的受众
- 模型的生命周期
- 模型的结果
- 模型结果产生的影响
2.2、案例
-
了解项目重要性和操作话的分解
3、现行法规
3.1、行业特定法规
3.1.1、说明
- 金融、医疗行业等独有的法律法规
3.1.2、案例
- 美国药品法规GxP
- 可追溯性
- 问责制
- 数据完整性
- 可靠性
- 英国审慎监管局（PRA）金融模型风险治理MRM的四个原则
- 模型定义
- 将此类模型记录在册
- 风险治理
- 建立模型风险治理框架、政策、程序和控制
- 生命周期管理
- 模型开发、实现和使用的鲁棒性
- 模型定义
3.2、广泛法规
- 解决数据隐私等问题的相关法规
- 案例
- 欧盟通用数据保护条例（GDPR）
- 了解收集或处理的数据
- 访问收集的数据
- 了解处理过程
- 纠正不准确的数据
- 删除数据需要被完全删除
- 限制个人数据的处理
- 获得收集的数据并在其他地方重复使用
- 反对自动决策
- ...
- 加州消费者隐私法案（CCPA）
- 与GDPR类似
- 欧盟通用数据保护条例（GDPR）
3.3、人工智能特定法规
- 欧盟确定了遵循7项关键要求
- 人类机构的监督
- 技术鲁棒性和安全性
- 隐私和数据治理
- 透明度
- 多样性、非歧视性、公平性
- 社会和环境福祉
- 问责制
- 主要影响特定的高风险领域
- 医疗保健
- 交通
- 能源
- 部分公共部门
- ...
3.4、负责任的人工智能
3.4.1、共识
- 负责任的开发
- 可持续
- 可治理
3.4.2、方法
- 以人为本
- 为人们提供、了解并执行工具和训练
3.4.3、具备
- 意向性
- 模型的设计和行为符合目的
- 数据合规
- 数据来源无偏见
- 确保对潜在模型的多重检查
- 平衡人工智能项目的协作方法
- 系统结果由人类解释
- ...
- 问责制
- 集中控制、管理和审计企业人工智能工作的能力
- 总体把控哪些团队正在使用哪些数据
- 总体把控如何使用数据
- 总体把控在哪些模型中使用数据
- 数据是否是可靠的且合法的
- 总体把控哪些业务流程用了哪些模型
- ...
3.4.4、关键要素
3.4.4.1、数据
- 来源
- 如何收集？
- 如何达到使用标准？
- 实时获取
- 可治理的
- 安全的
- 可追踪的
- 长期数据
- 一致性
- 完整性
- 所有权
- 偏差数据
- 导致模型偏差
- 偏差不容易被察觉
3.4.4.2、偏见
- 偏见问题
- 雇佣歧视
- 种族歧视
- 皮肤歧视
- 地域歧视
- ...
- 解决方法
- 偏见检查整合到治理框架
- 尽可能利用人类的专业知识
3.4.4.3、包容性
- 人机回圈方法
- 目的
- 将人类智能的精华与机器智能结合
- 应用
- 模型在生产中的使用方式
- 模型的构建方式
- 目的
- 作用
- 降低出现盲点和遗漏风险
- 目标
- 将适当的人类知识纳入MLOps流程中。
3.4.4.4、大规模模型规模管理
- 背景
- 随着部署数量的增加，风险与挑战也快速增加
- 注意事项
- 可扩展的模型生命周期需要很大程度上实现自动化和简化
- 错误会迅速广泛地传播
- 现有的软件工程技术可以在规模上帮助ML
- 决策必须可解释、可审计以及可追踪
- 再现性是关键
- 模型会随着时间的推移而下降
- 技术发展迅速需要整合新技术的方法
3.4.4.5、治理
- （1）目的
- 实现公平和信任
- （2）过程
- 确定意图
- 明确职责
- CEO
- 问责制
- CTO
- 持续性
- 数据主管
- 治理
- 执行者
- 通过适当的规则，集中化工具
- CEO
- 集成目标
- 定义过程目标
- 构建过程目标
- 建立和传达流程规则
- 定义指标
- 监控偏差
- 管道检查
- 通过教育来增强人的能力
- 通过教育来防止用户面临的风险
3.5、治理模版：步骤
3.5.1、监控和细化
- 尽可能的将度量标准自动化
- 清晰理解目标与KPI
- 鼓励机制
- 用简单的方式实现治理过程游戏化，例如排行榜等竞争元素
- 治理环境的变化
- 对问题采取行动
3.5.2、参与和教育
- 内容
- 必须做什么
- 什么时候做
- 如何做
- 过程
- 传达MLOps治理的广阔愿景
- 强调现状的危险
- 细说工程的应用
- 直接和团队沟通并一起制定培训计划
3.5.3、选择用于集中治理的工具
- 所有模型状态的单一视图
- 带有签售机制的过程们，允许随时跟踪决策制定的历史
- 跟踪模型所有版本的能力
- 链接到工件存储、度量快照和文档的能力
- 专门为每类分析用例定制流程的能力
- 集成生产系统运行状况监控的能力
- 根据原始业务关键KPI跟踪模型性能的能力
3.5.4、将政策整合到MLOps过程
- 业务范围界定
- 定义目标、定义KPIs和记录签署
- 构思过程
- 数据发现：数据质量和法规遵从性约束
- 算法选择：受可解释性要求的影响
- 开发
- 数据准备：考虑PII合规性、法律区域范围分离、避免输入偏差
- 模型开发：考虑模型再现性和可审计性
- 模型测试和验证：偏差和危害测试、可解释性
- 预生产
- 使用生产数据验证性能、偏差
- 生产就绪测试：验证可扩展性
- 部署
- 部署策略：由操作话水平驱动
- 部署验证测试
- 使用影子测试或A/B测试技术进行生产验证
- 监控和反馈
- 性能指标和警报
- 针对输入漂移的警报预测日志分析
3.5.5、确定治理策略
3.5.5.1、遵循
- 建立广泛的政策领域并接受经验，有助于发展细节。
- 不太关注风险或法规遵从性的计划，选择重量轻，成本低的措施
3.5.5.2、注意事项和措施
- 再现性和可追溯性
- 在实现快速和精确的模型重新实例话方面，需要完整的VM和数据快照
- 能够重新创建环境并使用数据样本再训练
- 仅记录部署模型的度量标准
- 审计和文档
- 实验运行和所做选择的原因
- 仅包括已部署模型的自动化文档
- 开发过程所有变更的完整日志
- 人机回圈签收
- 每次环境迁移都要进行多次签收（开发、QA、预生产、生产）
- 预生产验证
- 对模型进行手工编码、比较结果
- 在类似生产的环境中重新创建全自动测试管道
- 对数据库、软件版本和命名标准进行广泛的单元和端到端测试用例或自动检查
- 透明和可解释性
- 使用手动编码的决策树来获得最大的可解释性
- 使用回归算法的可解释性工具，例如夏普利值
- 接受不透明的算法，如神经网络
- 偏差和伤害测试
- 使用特定“队伍”对抗式手动测试
- 使用多种工具和攻击媒介
- 对特定群体进行自动偏差检查
- 生产部署模型
- 容器化部署到弹性、可扩展、高可用性多节点配置
- 在部署或单个生产服务器之前自动进行压力/负载测试
- 生产监控
- 实时错误报警
- 动态多臂赌博机模型平衡
- 自动隔夜再训练
- 模型评估
- 重新部署或每周输入漂移监控
- 手动再训练或基本基础设施警报
- 无监控
- 无基于反馈的再训练
- 数据质量和合规
- 了解数据的来源、质量和适当性
- 匿名化
- 记录
- 审查列级沿袭
- 等其他PII考虑因素
- 针对异常情况的自动化数据质量检查
- 了解数据的来源、质量和适当性
3.5.6、确立责任
- 确定治理人员
- 从管理层级到执行层级都参与
- 强调广泛参与与共同信念
- 避免创建全新的治理结构
- 已存在的治理结构纳入MLOps治理中
- 获得高级治理层对治理过程的支持
- 分层考虑治理
- 战略：制定愿景
- 战术：实施和执行愿景
- 运营：每天执行
- RACI矩阵
3.5.7、确立道德立场
- 社会福祉
- 平等
- 隐私
- 尊严
- 就业
- 民主
- 偏见
- ...
- 心理影响
- 欺骗
- 操纵
- 剥削
- ...
- 金融影响
- 市场操纵
- 决策透明
- ...
- 发生错误后企业接受何种程度的问责
3.5.8、理解并分类分析用例的治理需求
- 每个用例都要遵守哪些法规？
- PII地区特定行业法规有哪些？
- 谁消费模型的结果？
- 部署模型的可用性要求是什么？
- 实时评分
- 计划批量评分
- 临时运行评分
- ...
- 任何错误和不足的影响是什么？
- 法律
- 金融
- 个人
- 公公信托
- ...
- 发布的节奏和紧迫性是什么？
- 模型的生命周期和决策影响的生命周期是什么？
- 模型质量下降的可能速度？
- 对可解释性和透明度的需求是什么？
495
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
