企业数字化转型：为什么需要做 ModelOps 模型全生命周期管理-Toy模板网

这篇具有很好参考价值的文章主要介绍了企业数字化转型：为什么需要做 ModelOps 模型全生命周期管理。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

现如今，以大数据、云计算、人工智能、工业互联网为代表的数字科技正飞速发展，带领技术与产业向数字化、智能化的方向展开变革——数字科技正逐渐成为推动世界经济高质量发展的核心驱动力，数字经济应运而生。而对于企业来说，数字化转型则是发展数字经济的必由之路。

（数学）模型，作为企业数字化转型的重要资产正受到越来越多的瞩目——从“微观”到“宏观”再到“新的微观”，模型能够帮助人们拨开迷雾、简化人们的认知成本。然而目前，模型在开发、应用的工作流中也存在不少普遍性的问题，很大程度地影响着效率。下文将聚焦于此，引入 ModelOps 的概念，以探寻解决此类问题的可行性。

从真实世界中模型开发应用的场景说起

本节将以三个真实的典型案例阐述模型在各行业企业的使用现状与现存问题。除所属行业各不相同外，三个场景下模型在对应企业生产中发挥的具体作用也大相径庭。

场景一

当模型参与到企业产品设计、研发、决策生产的全流程中…

企业 A 是一家航空航天制造公司，主要研制中大型运载火箭等系列工业产品，数学模型作为强有力的工具手段被广泛应用于其火箭产品设计研发的全流程中——得益于计算机技术水平的飞速发展，多学科的研发人员能够发挥其不同的专业能力，通过不同的建模软件、编程语言输出阶段性的产研成果。

而针对步骤与步骤间的模型成果传递，由于企业 A 需要传递的不是模型文件，而是模型跑出的结果，因此他们选用传统文档作为载体，以自然语言 + 截图的形式记录模型相关公式、数据、关键计算过程、计算结果及分析内容。而这样一份以文档为载体的模型成果在后续工作中将参与以下几个步骤：被引用，前序模型跑出的结果可能是下一阶段模型的输入；被汇报，传统文档将作为模型成果展示的重要材料汇报给上级人员，由他们拍板做出决策；被修改，火箭研发的相关参数需要成百上千次的实验，繁复的修改、优化需一应被记录于模型成果中。

而企业 A 在重复进行上述操作后，敏锐察觉到了该流程中存在系列问题：

对于产品设计研发流程本身来说，目前的操作存在技术上的壁垒——由传统文档承载的所谓“成果”不能精确表达设计元素之间的关系与模型结果，设计语言及模型语言在与自然语言进行转化时常存在歧义，受限于撰写人的主观想法与文字能力，这其中的“人为误差”少则降低工作效率，多则影响模型相关的人为决策。

而对于研发流程中涉及到的各部门工作人员，工作流也并未完全打通——工业产品设计研发作为多学科系统工程，由于各部门人员所选用的建模软件、编程语言都各有不同，极容易出现协同困难，最终形成“信息孤岛”。

最后，模型的成果与成果间存在传承关系，产研流程本身牵一发而动全身，上游模型成果中微小的改变所引起的连锁效应需要相关人员在下游成果中手动一一更迭，不仅繁琐，且从下游成果中难以追溯首次发生改变的模型究竟存在于哪一步。

场景二

当模型赋能企业的生产调优…

企业 B 扎根国内新能源业，主营风机发电业务。不同于企业 A 在产品设计研发全流程中都有数学模型的参与，企业 B 在生产风机阶段主要使用传统办法，而需要模型介入的是风机投入使用后的发电场景。

企业 B 基于 Pycharm 开发模型，一方面根据不同风机发电时的实际风电风场环境，输入环境数据调用模型，进行风机使用时的参数调优，并做使用预警；另一方面基于模型，比对风机实际运行情况与风机出厂时的原始发电数据，分析风电业务的关键指标，进行风机的生产调优。

而优化过后，企业 B 会生产出新的风机、使用新的运行参数，此时原有模型不再适用，开发人员将优化原模型以匹配新场景——生产调优结果反哺建模工作，企业 B 因此实现风机、模型一轮轮的循环迭代。

然而，由于模型本身具备特殊性（详见第二节），它们的优化迭代并不仅仅是“将 A4 纸上的字迹划掉重写”，而意味着大量“版本管理”工作。事实上，模型本身及一切与模型相关联的元素，包括开发环境、数据、项目、训练记录等都需要版本管理，且相关元素的版本管理不是“孤立的”，而要与模型本身存在“映射关联”。打个比方，一篇论文需要引用一份数据，但此时数据出现更新，撰写者在保留原始数据的基础上修改数据、记录修改时间，这是对数据本身的版本管理，而论文的引用部分也要做出相应修改，这就是映射关联。作为具备一定规模的中大型企业，在繁复的版本管理工作前，企业 B 不堪其忧。

另一方面，企业 B 还面临计算资源调度方面的问题。由于上万台风机的迭代优化都是持续且同步的，涉及到数量繁多的模型计算工作，而每个企业的计算资源又是有限的，企业 B 目前首先希望能够充分有效地利用全部资源，其次需要一套合理的计算资源调度规则。企业 B 的技术人员不希望再花费精力于计算资源的分配使用上，而可以专注于模型研发。

场景三

除了后台生产，企业前台工作中同样也有模型的广泛参与…

企业 C 是一家供应链咨询公司，为食品、日化等快消、零售企业提供供应链相关的解决方案，如选品下单系统等。企业 C 内部开发、部署模型主要供销售人员调用以完成产品售卖、提升销售效率——基于所开发的模型，销售人员通过输入客户背景信息等能够完成用户画像构建与高潜客户识别，通过输入客户与客服的对话内容能够完成语音语义分析等智慧营销动作。

模型在企业 C 中的应用场景十分清晰，但其同样面临工作流上的种种问题：

首先，在企业 C 内部，开发部署模型的人员与实际调用模型的人员是不同的，一方面，现有的模型研发方式忽略了公司内部跨部门、跨角色的协同需求；另一方面，企业 C 缺少供开发人员与销售人员同时使用的、统一的模型开发管理平台，因此模型的开发与管理工作是割裂的——类比一下便是，在计算机内完成文档撰写后，无法将文档置于计算机文件夹内收纳，而需要将其打印出来统一收于实体抽屉。

其次则是模型的部署调用问题。企业 C 场景下，模型主要面向公司一线的内部人员，模型的部署工作不应该是模型全生命周期中的重点，但由于目前缺少敏捷部署模型的途径，因此浪费了模型开发的时间。另外，销售人员调用模型在企业 C 中属于高可用的并发场景，服务器能否支撑是首当其冲的问题；而模型的调用记录应如何完整记录并管理，才能使其反哺相关的迭代优化工作也正是企业 C 所思考的问题。

基于以上的种种问题，企业面对模型工作流的期待是什么？

为了能够顺畅地开发并应用数学模型，企业们期望：

首先，对于模型本身来说，从开发训练，到部署调用，再到优化迭代，每一个步骤都应该是极致顺滑的，如，开发训练阶段有合适的环境即开即用；部署调用阶段若没有特殊需求，应能够做到一键部署、一键调用；优化迭代步骤不需要开发人员花费额外的精力复现环境、做版本管理等。

其次，企业希望模型在公司内部跨部门、跨角色的全工作流程中能够跑通，不存在技术、信息上的壁垒。例如，模型在成果传递时信息传达能够在无误、无歧义的基础上做到高效、便捷；而对于企业模型工作流上不同角色的人员来说，希望能够发挥其自身优势、做到有效协同。

最后，在计算资源的问题上，企业们希望有合理的调度规则，能够使计算资源最大程度地跟得上使用需求。

接下来，我们将引入 ModelOps 的概念

为解决上述应用场景中出现的种种问题、匹配企业们在模型工作流中的种种需求，我们将在本节引入 ModelOps 的概念。那么首先，ModelOps 是什么？

ModelOps 是…

相信大部分 IT 从业者们都对 XOps 的概念并不陌生。在经历了 DevOps 与 MLOps 的时代后，2018年12月，IBM Research 的 AI 研究员 Waldemar Hummer 与 Vinod Muthusamy 在 IBM Programming Languages Day 上首次提出 ModelOps。作为 MLOps 的突破与延申，ModelOps 面向一切“可复用、独立于平台且可组合的 AI 工作流的编程模型”，提供强大的管理能力解决模型开发与模型部署之间的问题，确保所有模型都能够运行投产，并能够将技术与业务绩效指标联系、管理相应风险。

无独有偶，国际知名行研咨询公司 Gartner 于2021年9月发布了有关“AI 信任、风险和安全管理”的 Market Guide，Gartner 认为，ModelOps 'is primarily focused on the end-to-end governance and life cycle management of all analytics, AI and decision models'。

综合两方观点，我们可以认为，ModelOps 专注于模型全生命周期的端到端管理，目的是解决模型工作流中出现的种种问题。

从 ModelOps 中的 Model 谈起

现在我们已经知道了 ModelOps 是可以帮助解决模型工作流中种种问题的途径，但还有些概念还未被界定，比如 ModelOps 具体面向哪些 Model？Ops (Operations) 又具体包含哪些步骤？

作为数字化转型的重要资产，对于许多企业来说，应用模型的根本目的是“从数据中找寻规律”，因此 ModelOps 中的 Model 应泛指一切能够从数据中找寻规律的模型。回归到 Gartner，Gartner 认为 ModelOps 应面向人工智能与决策模型，决策模型包括机器学习、知识图谱、规则、优化、语言学和基于 Agent 的模型等，是一个比较宽泛的定义。

正因为如此，ModelOps 中的 Model 不局限于 MLOps 中的 Machine Learning，也不局限于 AI 中的 Artificial Intelligence，因为 ML 或 AI 都只是高级模型中的一种。事实上，国内大部分企业的大部分时间在使用的都是更基础的决策模型，而由于种类各异、部署环境也各不相同，这些基础决策模型的载体与流程反而是缺乏重视的，这也就是在 MLOps 的基础上提出 ModelOps 这一概念的原因之一。

ModelOps 中的 Ops (Operations) 具体包含…？

作为全球最具影响力的独立研究咨询公司之一，Forrester 认为模型的全生命周期管理有以下六个步骤：

理解数据：从真实世界的众多数据中筛选与待解决问题相关的一批——对应到第一节的场景二，即从风机发电这一真实世界，挑选真正与发电效果息息相关的环境数据，诸如“周期”、“范围”等。

准备数据：运用计算机技术处理从真实世界中取出的相关数据，使其成为有研究价值的“研究数据集”。

开发模型：通过统计学方法或机器学习等算法，研发能够解决真实世界问题的模型，回归到第一节的场景中，三类模型分别解决火箭的设计问题、风机的高效运营问题及销售的效率问题。

评估：开发人员将对模型进行数次的训练与测试，以确保模型在部署后能够完成工作任务。

部署：将模型投入企业真实的生产工作中。

监控：监控模型在真实世界的运作情况，一般来说，模型在真实世界的使用情况会与研发情形有所出入，那么就会涉及到模型的优化迭代，随后，回归到模型全生命周期管理的第一步，理解数据。

modelops,大数据,云计算,人工智能,devops,Powered by 金山文档

除了由 Forrester 提出的六个步骤外，我们认为还有第七个步骤同样隐藏于 ModelOps 的 Operations 中，那就是辅助决策，在此我们会提到 BI（Bussiness Intelligence）。商务智能，是人们对于技术的某种期望，期望能够通过技术的手段实现某种智能化甚至是自动化，辅助人们做出正确的商业决策。作为决策的辅助工具，BI 最典型的应用是仪表报表，通过仪表报表，企业管理层能够了解企业的经营状况，随后通过人为分析进行决策与行动。而企业中，模型同样应该具备该功能。例如场景一，技术人员通过模型解决火箭的研发设计问题，将模型跑出的成果交由上级，由他们拍板定论后，设计成果才会投入生产。

将 Model 视作 BI 的典型应用之一，ModelOps 的 Operations 因此有理解数据、准备数据、开发模型、评估、部署、辅助决策、监控七个步骤。

从全局看，打通上述 Operations 的全流程是解决模型资产管理、模型稳定性、模型风险、模型持续运营等问题的大前提，由此，才能够真正提升机器学习、AI 等其他决策模型的开发与运行服务效率。

为什么非 ModelOps 不可？

前文提及，ModelOps 的概念是在 DevOps 与 MLOps 之后被提出的，那么为什么一定是 ModelOps？ModelOps 相比于传统的 DevOps、MLOps，对于企业中各类模型的适用性高在哪里？

DevOps 源于软件工程，是一种强调软件开发、IT 运维及质量保障沟通合作的管理方式，通过自动化软件交付与架构变更的流程，使得软件的构建、测试、发布更加快捷、频繁、可靠。然而，DevOps 主要面向业务软件，而 ModelOps 面向的是决策模型。对于 ModelOps 来说，针对模型“优化迭代”的管理是经久不衰的主旋律，这是由于模型具备以下特质：

模型的输出在大部分场景没有最优的概念，且随着数据的变化、业务的变化，天生需要不断迭代；

模型的输入是数据流，数据会随着业务变化，且数据的积累反过来可以指导模型迭代；

模型的效果评价在大部分场景下是个异步的动作，异步的周期可能很长，模型效果数据的获取会指导模型的选择与模型的优化；

模型的研发过程会伴随着特殊的三要素：数据、镜像、算力；

模型与模型之间可能存在依赖关系；

模型经常用于决策辅助，所以生产模型的过程也需要作为成果的一部分被考虑。

另一方面，DevOps 缺乏对于“优化迭代”的关注，针对业务软件，DevOps 的全流程到“交付”步就几乎停止了。可以说，ModelOps 是 DevOps 在面向决策模型的发展与更新时衍生出的新体系、新理念、新技术。

而当比较对象是 MLOps 时，事情会变得更简单。正如机器学习是 AI 与决策模型的一个子集，MLOps 也是 ModelOps 的一个子集。与仅关注 Machine Learning 且仅将 Ops 重点放在“开发与运维”本身的 MLOps 相比，ModelOps 关注全种类的 AI 与决策模型，且作为“模型全生命周期”的管理手段，ModelOps 覆盖模型从出生到消亡（被迭代）的一切步骤。

ModelOps 扎根于 DevOps，又是 MLOps 的扩展。然而，当前 ModelOps 尚未达到与 DevOps 相同的成熟度。据 CB Insights 中国调查显示，各企业中平均仍有87%的决策模型从未真正上线运行，ModelOps 的体系因此亟待进一步的开发与拓展。

基于 ModelOps 的产品实现

可以看出，ModelOps 本身是一个比较概念化的东西，告诉人们“对模型做端到端的全生命周期管理”能够解决“模型工作流中的种种问题”，那么如何实现这种管理？2019年6月，ModelOps 的提出者 Hummer 与 Muthusamy 对其既往观点进行了扩展，他们认为，应将 ModelOps 视作一个基于云的框架或平台。经过各种探索，概括地说，ModelOps 概念的具象实现是建立自动化、标准化、流程化、可视化的模型统一运营管理平台。

数据科学协同平台 ModelWhale 基于 ModelOps，将其作为底层逻辑设计产品，期待为上述场景下各行业企业中模型工作流的种种问题提供具体的解决方案。本节将从模型的研发优化迭代阶段、模型的交付阶段、及模型工作流中跨部门跨角色的协作协同，三个 Modelops 在考虑的问题出发，展开讨论。

模型的研发与优化迭代

在模型的研发与优化迭代阶段，ModelWhale 的产品关键词是“版本管理”。首先，让我们捋一下版本管理与 ModelOps 所看重的模型迭代优化之间的关系：事实上，一切需要更迭的事物都有做版本管理的必要，例如，在撰写毕业论文时做出的每次大改，大部分人比起直接在原文修改，更倾向于新建一个 .docx 并标注上日期，因为前一个版本也还有再利用的可能性。那么为什么似乎只有模型的版本管理听起来格外繁重呢？首先，模型所关联的元素太多了，包括开发环境、数据、项目、训练记录等每一项，都有做版本管理的必要；其次，模型的开发应用是多人协作的过程而非“单打独斗”，不同人员产出的不同成果同样也是“版本”的一种。综上，ModelWhale 将版本管理作为重点，为内部的所有生产资料都提供了相应功能，用户们可以随时进行数据、项目代码等的版本比对与版本回溯。

当然，仅仅“孤立的”版本管理还是不够的，在场景二中我们还提到过“映射关联”的概念，以确保模型相关的不同元素在版本更新后不会出现关联上的偏差。ModelWhale 为数据、研究项目、模型成果提供映射关系，三者之间可相互追溯。例如，对于数据与研究项目，模型研究者可以基于不同版本的数据直接创建项目、跳转至分析界面；对于研究项目与模型应用，在模型应用发布时，平台会默认记录该模型使用的项目版本，模型研究者可在模型应用页面选择对应的项目版本进行回溯。最后，ModelWhale 重视数据、项目、模型的可描述性，为任何版本信息提供文字描述区域。

特别地，针对模型研究特殊的一大要素，研发环境，ModelWhale 不仅关注其的“版本管理”与“映射关联”。ModelOps 看重模型开发的流畅性，理想中的状态是能够即时开始模型研究，而事实上，不同的操作系统、系统依赖、编程语言、所需工具包不仅让模型研究者难以“开启”一个新项目，也让其难以“复现”前人或团队伙伴的已有成果——无穷尽的环境报错正困扰着开发人员。ModelWhale 在云端提供即开即用的分析环境，利用容器——镜像——封装各项目所需的环境信息，针对特定的研究项目，甚至项目的某一具体版本，用户可通过 ModelWhale 跟踪记录其使用的具体镜像。

解决了模型研究特殊三要素中的数据与镜像，下一步便是计算资源问题。在场景二中，计算资源不足已严重拉低了企业 B 的模型工作流效率，事实上，计算资源贯穿了 ModelOps 步骤从理解数据到监控的每一步。ModelWhale 为模型研究人员提供计算资源支持。通过该平台，企业模型研发部门的管理员可利用图形化操作界面，对算力进行管理。而算力同镜像一样支持即开即用，模型研究人员在开始项目前自主选取所需算力，即可一键完成资源调用，开始模型研究工作。项目关闭、算力使用结束后，资源也会自动释放，供企业其他有需要的人员使用。

以上从生产资料的版本管理、映射关联，再到环境的可复现性与计算资源的调度管理，其实都是在解决模型代码的可运行性。然而，模型与模型间的优劣不仅仅与代码本身有关，与最后产生的模型文件关联的应是一次具体的训练记录，这也就是 ModelOps 所关注的“评估”步。换句话说，在代码不变的情况下，调整模型的训练参数，甚至调整相应计算资源，所生产出的模型文件也是不一样的。针对模型的此类特质，ModelWhale 提供训练记录的产品功能。通过训练记录，模型研究者可实时查看和记录模型训练每次实验的 Loss，Accuracy 及硬件使用情况；针对训练记录的各版本，ModelWhale 提供可视化比对分析；最后，研究者通过 ModelWhale 还可直观的查看模型组成、模型结构、及每层网络节点的输入输出与对应的参数说明。

在模型交付前，ModelWhale 实现了将研究项目成果与相关元素一键打包，意味着模型作为成果交付后依然能够轻松“向前”追溯，回到版本管理功能，有效帮助模型后续优化迭代。

模型的交付

ModelOps 作为 XOps 的一种，与其他 Ops 同样关注对交付的管理，那么模型的交付物应如何延拓？对于传统的模型应用，首先，模型的发布部署过程复杂，专业门槛高，例如将模型发布为 APP 的形式，就会因一系列的调试配置操作耗费大量开发人员的精力；另外，若通过第三方软件输入数据、本地运行模型的形式又易出现效率低、速度慢的问题。模型的发布部署不应成为模型开发工作流中的重点，因此，ModelWhale 研发了相关产品功能。

对于模型成果，研究者可在项目页将其一键部署为 REST 服务或离线预测，降低模型发布操作的专业技术门槛。在模型调用时，使用者可以通过 API 或网页服务两种方式进行调用操作，若模型被发布为网页应用，使用者即可在网页端填写表单后一键获取模型的运行结果。另外，ModelWhale 后台将为企业保留全套的模型调用记录，记录企业内外部使用者对于模型的调用历史，使企业能够掌握模型的使用情况，以便其进行模型的再训练与迭代优化。

除了变成一个 API 或者网页应用，模型成果其实还有更多元的交付形式。例如，对于形成模型的的项目代码片段，可以进行沉淀，供下一次开发类似模型直接使用。通过 ModelWhale Jupyter Notebook 侧边栏中的代码片段库功能，模型研究者可在既往研究中预先收藏有几率被复用到的代码片段，后续进行新一轮研究时，在该代码库“我的收藏”中找到相应代码片段直接插入，即可完成复用。

前文提到，各企业中平均仍有87%的决策模型从未真正上线运行，而对于未被部署为应用的模型文件，也可将其作为阶段性成果供后续使用。利用 ModelWhale 算法库，用户们可以将已产出的算法模型辅以文字说明进行沉淀，实现对模型的整理与分享。

模型工作流中跨部门、跨角色的协作协同

ModelOps 关注模型全生命周期的流畅性，而模型的开发应用又常是多人协同，因此 ModelWhale 研发了一系列功能应对团队工作中常出现的“冲击对撞”。

例如，在上文中提到的生产要素版本管理、环境的可复现性、计算资源的调度等，全都支持跨部门、跨角色的打通——对于模型项目代码，不同人员可在同时段协作协同；对于镜像，不必人人造轮子，任意镜像可分发给组织内的任意成员进行复用；对于算力，除了普通的算力分配，ModelWhale 还提供资源申用机制，当现有计算存储资源不够用时，模型项目组的管理员可直接通过发起申请及时获得算力补给，应对不同研发需求。

而针对模型交付阶段的代码库 + 算法库功能，两者中的的代码片段与模型文件都支持组织内的权限管理与分发。另外，ModelWhale 还具备任务规划的项目管理工具，项目负责人可以新建课题任务，并将其拆分成子任务进行分发，协同模型研发团队共同完成复杂的项目研究。

甚至，ModelWhale 还针对团队协作提供更高维度的模型成果承载方式。当企业内部想让模型资产变得更“高级”，那么模型的研究者就不应只包含计算机开发人员，而应包含更多的“业务人员”。举例来说，在开发医学相关模型时，除了在一线“敲代码”的工作人员，模型的研究小组还应有临床医生（业务人员）的参与。但是计算机技术并不是临床医生的强项，他们如何在忽略细颗粒度代码的前提下理解模型并提供一应的指导意见？ModelWhale 因此提出，可将模型代码封装为可视化的组件与流程模板，利用这样的封装，业务人员不再需要理解代码本身，而仅需理解一个代码块的作用。由此，业务人员在提供相关的指导意见时，就可以运用此类模板搭建简易的模型流程，与开发技术人员进行良好的协同。此外，技术人员还能够将业务人员搭建的模型流程直接还原为 Notebook 代码，省去了从零编写的时间。

最后还有一个待解决的问题，就是阶段性模型成果在企业内部的传递问题。其一，我们可以使用算法库功能，但当一个企业更关注的是模型跑出的结果而非模型文件本身时，此方法便不再适用，类似于第一节中的场景一。针对企业 A 长期苦于用传统文档 + 自然语言承载模型成果的问题，ModelWhale 对 Notebook 做了升级，Jupyter Notebook 不再仅支持版本管理、多人高效协作、随时复现分析过程，还具备图像交互、相互援引等功能——Cell 级的直接引用，可将模型结果直接汇总至总的成果报告中，同时支持高效溯源；最后，Notebook 也支持多格式导出，无论是 HTML，还是 Word、PDF，研发人员均可自行选择。