大公司如何管理数据、环境等重要模型生产资料

在数字化转型日益盛行的今天，（数学）模型，作为企业数字化转型的重要资产，正受到越来越多的瞩目——从“微观”到“宏观”再到“新的微观”，模型能够帮助人们拨开迷雾、简化人们的认知成本。

与之相对应地，在模型开发、应用的工作流中，越来越多的问题正被暴露出来，很大程度地影响着效率，不少公司管理者会提出疑问：如何进行模型及相关生产资料的管理。在回答这个问题之前，我们不如将目光放宽放高，聊聊企业内部的模型全生命周期管理。下文中，我们将从真实场景说起，引入一个新概念 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，研发人员均可自行选择。

ModelWhale 支持 Notebook 的 Cell 级引用

结束语

本文主要关注企业数字化转型的重要资产——模型——在生产工作流中出现的种种问题、引入 ModelOps 的概念、介绍了一种数据科学协同平台 ModelWhale，以探寻 ModelOps 的产品实现与相关问题的具体解决方案。

作为一款数据科学领域的工具、平台，真正发挥平台的产品能力才是关键所在，ModelWhale 希望能用积累下来的经验与方法论，帮助企业们一起梳理使用场景，完成模型的全生命周期管理工作，为广大企业带来实质性的帮助。

若你想更深入地了解 ModelWhale 有关模型研发应用的各项功能与实际案例，欢迎进入 ModelWhale 官网 注册体验、了解更多详情。