企业数字化转型|如何跑通模型开发、部署的工作流

01 02月 2023

2023-02-01 15:37

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

企业数字化转型具体的实施路径太过多元，一篇文章大体上叙述不清，那么本文就以企业数字化转型的重要资产之一，模型，为着眼点，以小见大地探讨相关问题。

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

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

以不同工作流步骤为突破口总结现存问题
企业面对模型工作流的期待是什么？

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

ModelOps是…
从ModelOps中的Model谈起
ModelOps中的Ops (Operations)具体包含…？
为什么非ModelOps不可？

基于ModelOps的产品实现

模型的研发与优化迭代
模型的交付
模型工作流中跨部门、跨角色的协作协同

结束语

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

企业A在开展业务时广泛使用到数学模型，在模型开发应用的工作流上具备较高的成熟度，本节将以其为例，浅谈真实世界中企业的模型工作流中与其中存在的普遍性问题。

首先，在后台生产工作中，模型辅助企业A进行产品设计研发——多学科的研发人员发挥其不同的专业能力，通过不同的建模软件、编程语言输出阶段性的产研成果、拉通整个产研流程。此时，比起开发出的模型本身，模型的成果价值在于其跑出的结果、生成的报告。由于产品设计研发是一个较长且需多人协作的过程，对于模型结果传递，企业A选用传统文档作为载体，以自然语言+截图的形式记录模型相关公式、数据、关键计算过程、计算结果及分析内容。阶段性结果传递对齐后，由产研线上的相关负责人员输出总报告作为设计研发的最终成果。

在完成设计研发后，企业A会将产品投入使用进行生产调优，而模型就是生产调优的有力工具。模型研究人员开发模型后，操作人员会将影响产品使用的相关数据输入以调用模型，进行产品使用的参数调优，同时比对产品实际使用情况与出厂预期，以优化下一次产品的生产工作。在本阶段，相比于模型跑出的结果，模型服务本身变成了最重要的成果价值。调优结束后，企业A的产品、所选用的模型服务都会进行迭代，且这种迭代是循环的、高频的。

以上，模型主要参与的是企业A的中后台工作，而另一方面，模型同样赋能相关企业的前台营销。在进行产品售卖时，企业A内部开发、部署相关模型供销售人员调用以提升销售效率——基于所开发的模型，销售人员通过输入客户背景信息等能够完成用户画像构建与高潜客户识别，通过输入客户与客服的对话内容能够完成语音语义分析等智慧营销动作。同样将服务作为模型成果价值，但在此场景下，相关人员将模型的部署调用而非优化迭代作为工作流的重点。

综上，企业A在整个业务过程中处处运用数学模型，概括地说，阶段一，模型成果以报告承载，工作流重点为成果传递；阶段二与三，模型成果以服务承载，工作流重点分别为迭代优化与部署调用。

我们以不同工作流步骤为突破口，总结企业A遇到的种种问题

成果传递：受限于传统文档+自然语言，目前的成果传递方式不能精确表达设计元素之间的关系与模型结果，对于产品设计研发流程本身来说，操作存在技术上的壁垒；而对于研发流程中涉及到的各部门工作人员，工作流也并未完全打通，一方面，多学科的研发人员间存在协同困难、信息孤岛，另一方面，无数成果报告的引用、汇总、更迭带来了繁复的底层工作。

优化迭代：由于模型本身具备特殊性（详见第二节），在进行优化迭代时，不仅是模型本身，一切与之相关联的元素，包括开发环境、数据、项目、训练记录等都需要做版本管理，且相关元素的版本管理不是“孤立的”，而要与模型本身存在“映射关联”——在繁复的版本管理工作前，企业A不堪其忧。

部署调用：由于模型主要面向公司内部人员，理论上，部署工作不应占据模型开发的过多时间，目前，企业A缺少敏捷部署模型的途径；此外，销售人员调用模型在企业A中属于高可用的并发场景，服务器能否支撑、模型的调用记录应如何完整记录并管理，都很值得关注；最后，由于开发部署模型的人员与实际调用模型的人员天差地别，现有的模型研发方式忽略了公司内部跨部门、跨角色的协同需求，模型的开发与管理工作也是割裂的。

最后，由于以上三个步骤都涉及到数量繁多的模型计算工作，企业A目前还面临计算资源调度方面的问题、缺少合理的计算资源调度规则。

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

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

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

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

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

接下来，我们将引入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认为模型的全生命周期管理有以下六个步骤：

理解数据：从真实世界的众多数据中筛选与待解决问题相关的一批——对应到第一节的场景二，即从风机发电这一真实世界，挑选真正与发电效果息息相关的环境数据，诸如“周期”、“范围”等。
准备数据：运用计算机技术处理从真实世界中取出的相关数据，使其成为有研究价值的“研究数据集”。
开发模型：通过统计学方法或机器学习等算法，研发能够解决真实世界问题的模型，回归到第一节的场景中，三类模型分别解决火箭的设计问题、风机的高效运营问题及销售的效率问题。
评估：开发人员将对模型进行数次的训练与测试，以确保模型在部署后能够完成工作任务。
部署：将模型投入企业真实的生产工作中。
监控：监控模型在真实世界的运作情况，一般来说，模型在真实世界的使用情况会与研发情形有所出入，那么就会涉及到模型的优化迭代，随后，回归到模型全生命周期管理的第一步，理解数据。

除了由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代码，省去了从零编写的时间。

用Canvas快速搭建项目分析流程

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