大公司如何管理数据、环境等重要模型生产资料
在数字化转型日益普及的今天，（数学）模型越来越被视为企业数字化转型的关键资产。从“微观”到“宏观”再到“新微观”，模型帮助人们消除迷雾，简化人们的认知成本。相比之下，在模型开发和应用的工作流程中，对效率产生重大影响的问题越来越多，许多企业管理者对模型和相关生产资料的管理提出了质疑。在回答这个问题之前，让我们扩大视野，谈谈企业内部的模型生命周期管理。下面，我们将从真实场景开始，引入一个名为ModelOps的新概念，并探索解决此类问题的可能性。从现实世界的企业应用模型开发场景开始，以不同的工作流程步骤作为突破口总结现有问题，企业模型对工作流程有何期望？接下来，我们将介绍ModelOps的概念。ModelOps包括ModelOps中的模型，以及ModelOps中的Ops Operations，具体地说，为什么它是ModelOps？基于ModelOps的产品实现模型的研究开发和优化迭代模型的提供模型工作流中的部门间、角色间的协作结果从世界上企业开发应用模型的场景来看，企业A在开展业务时广泛使用数学模型，在模型开发应用程序的工作流中具有很高的成熟度。在本节中，将以此为例，对现实世界的企业模型工作流程中的普遍性问题点进行解说。首先，在后台生产工作中，模型支持A企业的产品设计研发。多学科研发人员发挥不同的专业能力，通过不同的建模软件和编程语言输出分阶段的生产研究成果，拉动整个生产研究过程。此时，模型的成果价值更多地体现在生成的报告中，而不是开发的模型本身。由于产品设计研发是一个漫长而多人合作的过程，所以对于模型结果的传递，A企业选择传统的文件作为载体，对模型相关的公式、数据、主要的计算过程、计算结果进行分析。以自然语言+屏幕截图的形式记录分析。分阶段的结果传递在校准后，生产线上的相关人员将输出一份完整的报告，作为设计、研究和开发的最终结果。设计研发完成后，A企业将利用产品进行生产调优，模型是生产调优的有力工具。模型研究人员开发出模型后，操作员通过输入影响产品使用的相关数据来调用模型，调整产品使用参数，将产品的实际使用情况与出厂预期进行比较，从而优化下一个产品生产工作。在这个阶段，模型服务本身成为最重要的结果价值，而不是运行模型的结果。一旦调优完成，公司A的产品和选定的模型服务将被迭代，这种迭代是循环的，频率很高。在上面，模型主要涉及到A企业的中间和后台业务，另一方面，模型也为相关企业的前台营销提供了力量。在产品销售方面，我们会在内部开发和部署相关模型，供销售人员调用，以提高销售效率。基于开发的模型，销售人员可以通过输入客户背景信息等来完成用户图像构建和潜在客户识别，通过输入客户与客户服务对话内容来完成语音语义分析等智能营销行动。服务作为模型的结果也很有价值，但在这种情况下，参与者将模型的部署调用作为工作流的焦点，而不是优化迭代。总而言之，A公司在整个业务流程中到处都使用数学模型。总而言之，在第一阶段，模型的结果由报告携带，工作流程的重点作为结果传达。在第二阶段和第三阶段，模型结果由服务承载，工作流分别侧重于迭代优化和部署调用。本文以不同的工作流程步骤为突破口，总结了A企业遇到的各种问题。它局限于传统的文档+ 自然语言，目前的成果传递方式不能准确表达设计元素与模型结果之间的关系，对产品设计研发过程本身来说，操作上存在技术障碍。对于参与研发过程的各部门员工来说，工作流程并不完全开放，一方面是跨学科研发人员之间存在协同效应和信息孤岛，另一方面是对无数成果报告的引用、总结和修改，带来了复杂的基础工作。优化迭代：由于模型本身的特殊性（见第二节），在优化迭代中，不仅要模型本身，还要对所有与之相关的元素进行版本控制，包括开发环境、数据、项目、训练记录等，对相关元素的版本控制不是“孤立的”，而是与模型本身有“映射关联”。在复杂的版本控制工作之前，企业A并不担心。部署调用：由于模型主要面向内部，理论上，部署工作不应该占用过多的时间进行模型开发，目前企业A缺乏敏捷部署模型的方法。另外，销售代表的呼叫模式在企业A属于高可用性的同时方案，服务器能否支持，如何完全记录和管理模型的呼叫记录值得关注;最后，由于开发部署模型的人和实际调用模型的人是不同的，现有的模型开发方法忽略了内部跨部门和跨角色协同的要求，模型开发和管理是分开的。最后，由于上述三个步骤都涉及大量的模型计算工作，A企业目前面临着计算资源调度方面的问题，缺乏合理的计算资源调度规则。基于这些问题，企业对模型工作流程的期望是什么？为了顺利地开发和应用数学模型，我们首先期望模型本身的每一步都非常顺利，从开发训练到部署调用，再到优化迭代。例如，一个适合开发培训阶段的环境将立即可用。部署调用阶段可以进行一键部署和一键调用，只要没有特殊要求。迭代步骤的优化不需要在环境再现、版本控制等方面花费额外的精力。其次，公司希望模型能够在跨部门和跨角色的内部工作流程中运行，没有技术和信息障碍。例如，当模型传递结果时，它可以有效和方便地传递信息，没有错误和模糊性。在企业模式工作流程中具有不同角色的人希望利用他们的优势并有效地协作。最后，当涉及到计算资源时，企业希望有合理的调度规则，以便他们能够充分利用计算资源。为了解决这些用例中出现的问题，并满足企业对模型工作流的需求，本节介绍了ModelOps的概念。首先，什么是ModelOps？ModelOps认为，大多数IT专业人员并不了解XOps的概念。在DevOps和MLOps时代之后，IBM Research的AI 研究人员Waldemar Hummer和Vinod Muthusamy在2018年12月的IBM编程语言日上首次宣布了ModelOps。作为MLOps的突破和扩展，ModelOps专注于所有“可重用、平台独立、可配置的AI工作流编程模型”，解决模型开发和模型部署之间的问题，确保所有模型都能运行，提供强大的管理功能，将技术与业务绩效指标联系起来，并管理风险。在2021年9月发布的“AI信任、风险和安全管理”市场指南中，Gartner表示，Model Ops“专注于所有分析、AI和决策模型的端到端治理和生命周期管理”。从这两个角度来看，我们都可以说ModelOps专注于模型整个生命周期的端到端管理，以解决模型工作流中出现的问题。虽然我们发现ModelOps是解决模型工作流中各种问题的有用方法，但仍有一些概念尚未定义，例如ModelOps针对的是哪个模型。Ops（Operations）的具体步骤是什么？作为数字化转型的重要资产，对于许多企业来说，应用模型的基本目的是“从数据中找到规则”，因此ModelOps中的模型应该指向所有能够从数据中找到规则的模型。回到Gartner，Gartner认为ModelOps应该被引导到人工智能和决策模型上。
除了Forrester提出的六个步骤之外，我们认为还有第七个步骤隐藏在ModelOps的操作中。这是对决策的支持。本节介绍Bussiness Intelligence（BI）商业智能是人们对技术的期望，他们希望通过技术手段实现特定的智能或自动化，以帮助人们做出正确的商业决策。作为决策的辅助工具，BI最典型的应用是通过计量报告，使企业管理者能够了解企业的运行情况，通过人工分析进行决策和行动。在企业中，模型应该具有相同的功能。例如，在场景1中，工程师通过模型解决火箭研发和设计中的问题，将模型结果传递给上级，由上级决定后，设计结果投入生产。如果您将模型视为BI的典型应用程序之一，那么ModelOps操作包括七个步骤：理解数据;准备数据;开发、评估和部署模型;支持决策和监控。从整体上看，开启上述运营的全流程，是解决模型资产管理、模型稳定性、模型风险、模型连续运营等问题的前提，真正提升机器学习、AI等决策模型开发和运营服务的效率。为什么要使用ModelOps？如前所述，ModelOps的概念是在DevOps和MLOps之后出现的，但为什么它是ModelOps呢？与传统的DevOps和MLOps相比，ModelOps如何应用于企业中的不同模型？DevOps源自软件工程，是一种强调软件开发、IT运营维护和质量保证沟通与协作的管理方法，通过自动化软件交付和架构更改过程，使软件构建、测试和发布更快、更频繁、更可靠。然而，DevOps主要针对商业软件，而ModelOps则针对决策模型。管理模型的“优化迭代”是ModelOps的一个持久主题，因为模型在大多数场景中没有最佳概念，并且随着数据的变化和业务的变化，持续迭代是必不可少的。模型的输入是数据流，数据随业务而变化，数据的积累可以引导模型迭代。在大多数情况下，模型的效果评估是异步行为，异步周期很长，模型效果数据的获取将指导模型的选择和优化。模型开发过程涉及三个特殊元素：数据、图像和计算能力。模型和模型之间存在着依赖关系。由于模型通常用于决策支持，因此生成模型的过程也必须被视为结果的一部分。另一方面，DevOps并不专注于“优化迭代”，在业务软件的情况下，从整个DevOps流程到“交付”的步骤几乎是停顿。ModelOps可以说是DevOps从面向决策的模型的开发和更新中衍生出来的新系统、新思想、新技术。如果比较对象是MLOps，事情就会容易得多。正如机器学习是人工智能和决策模型的子集一样，MLOps是ModelOps的子集。与MLOps相比，MLOps只专注于机器学习，专注于Ops本身，ModelOps专注于所有类型的人工智能和决策模型，并作为“模型生命周期”的管理工具，涵盖模型从诞生到消亡（迭代）的所有步骤。
ModelOps植根于DevOps，是MLOps的延伸。然而，目前的ModelOps还没有达到与DevOps相同的成熟度。CB Insights China的一项研究发现，平均87%的企业决策模型尚未真正投入使用，ModelOps系统需要进一步开发和扩展。在基于ModelOps的产品实现中，ModelOps本身是概念性的，可以告诉人们“模型的端到端生命周期管理”可以解决“模型工作流问题”。2019年6月，ModelOps的创始人Hummer和Muthusamy提出，ModelOps应该被视为一个基于云的框架或平台。经过各种探索，总结一下，ModelOps概念的具体实现是构建一个自动化、标准化、流程化、可视化的模型集成运维平台。ModelWhale是一个数据科学协作平台，我们希望将ModelOps构建为一个逻辑设计产品，为上述场景中不同行业的公司的模型工作流问题提供具体的解决方案。在本节中，我们将讨论模型的研发优化迭代阶段、模型的交付阶段、模型工作流程中的跨部门角色协作以及三个模块所考虑的问题。模型开发和优化迭代在模型开发和优化的迭代阶段，ModelWhale的产品关键词是“版本控制”。首先，让我们看看版本控制和模型迭代优化之间的关系，这是ModelOps的重点。事实上，所有需要更改的东西都需要版本控制。例如，每当你在写毕业论文时做出重大更改时，大多数人倾向于创建一个新的.docx并对其进行日期，而不是直接更改到原来的版本。那么，为什么只对模型进行版本控制如此困难呢？首先，与模型相关的元素太多。所有的元素，包括开发环境、数据、项目和培训记录，都需要进行版本控制。第二，模型的开发和应用不是“一个人”，而是多人协作的过程，不同人的不同输出结果也是一种“版本”。综上所述，ModelWhale专注于版本控制，为公司内所有生产数据提供相应的功能，用户可以随时对数据、项目代码等进行版本比较和回译。
模型相关项目代码版本比较和版本回退，接受历史版本只需点击一下，当然，“孤立”版本控制是不够的。在情景2中，我们还提到了“映射相关”的概念，以确保与模型相关的不同元素在版本更新后不会出现相关偏差。ModelWhale提供数据、研究项目和模型结果的映射，并且可以在三者之间进行跟踪。例如，对于数据和研究项目，模型研究人员可以直接基于不同版本的数据创建项目，然后跳转到分析界面。对于研究项目和模型应用，模型应用发布后，平台默认会记录模型所使用的项目版本，模型研究人员可以在模型应用页面上选择相应的项目版本并进行回溯。最后，ModelWhale强调数据、项目和模型的可描述性，并为任何版本信息提供文本描述区域。
数据源版本控制，允许直接从版本创建项目
特别是对于开发环境（模型研究的一个重要组成部分），ModelWhale不仅仅是“版本控制”或“映射相关”。ModelOps强调模型开发的流动性，理想情况下可以立即开始模型研究，但实际上不同的操作系统、系统依赖关系、编程语言和必要的工具包，不仅让模型研究人员很难“启动”新项目。这也使得“复制”前任和团队合作伙伴的现有成就变得困难。ModelWhale在云中提供了一个现成的分析环境，使用容器（图像）封装项目所需的环境信息，甚至对于特定的研究项目或项目的特定版本，用户也可以通过ModelWhale跟踪他们使用的特定图像。
内置多个镜子，可供不同领域的模型研究人员使用
解决了模型研究中的数据和图像三个特殊要素，下一步是计算资源问题。在场景2中，计算资源的缺乏严重降低了企业B的模型工作流效率。实际上，计算资源被用于ModelOps步骤的每一步，从理解数据到监控。ModelWhale为模型研究人员提供计算资源。通过这个平台，企业模型开发部门的管理员可以使用图形化操作界面来管理计算能力。计算能力支持按需和镜像，模型研究人员可以在项目开始之前选择所需的计算能力，只需点击一下就可以完成资源调用，开始模型研究工作。一旦项目结束，计算能力的使用结束，资源就会自动释放，供需要它的其他人使用。
从生产数据的版本控制、映射关联、环境的可重复性和计算资源的调度管理，将计算资源按需分配给不同的模型研究组，实际上解决了模型代码的可执行性问题。然而，模型之间的好处并不仅仅是代码本身。它是一个特定的训练记录，也就是ModelOps的“评估”步骤，与最终生成的模型文件相关联。换句话说，如果代码保持不变，调整模型的训练参数，或者调整相应的计算资源，生成的模型文件也会有所不同。针对模型的这一特性，ModelWhale提供了训练记录的产品功能。通过训练记录，模型研究人员可以实时查看和记录模型训练中每个实验的损失、准确性和硬件使用情况。对于训练记录的每个版本，ModelWhale都提供了可视化的比较分析。最后，通过ModelWhale，研究人员可以直观地查看每个网络节点的模型组成、模型结构、输入和输出以及相应的参数描述。
在交付模型之前，ModelWhale实现了只需点击一下就可以打包研究项目的结果和相关元素。这意味着在交付后，模型可以轻松地“向前”返回，返回到版本控制功能，有效地帮助后续模型优化迭代。ModelOps是XOps的一种形式，与其他Ops一样，它专注于管理交付，但是模型交付应该如何扩展呢？在传统的模型应用中，首先，模型的发布和部署过程复杂，专业门槛高，例如，以APP格式发布模型，会由于一系列的调试设置操作而消耗大量开发人员的精力。此外，通过第三方软件输入数据时，很容易以本地执行模型的形式出现效率低下和速度缓慢的问题。ModelWhale开发了相关的产品功能，因为模型的发布部署不应该是模型开发工作流的优先级。对于模型结果，研究人员只需单击一下就可以将其部署为REST服务或从项目页面脱机预测，从而降低了模型发布操作的专业知识门槛。在调用模型时，用户可以通过API或Web服务两种方式进行调用操作，当模型作为Web应用程序发布时，用户在Web端填写表单后，只需点击一下就可以获得模型的运行结果。此外，ModelWhale后端还保存了一套完整的企业模型调用历史。记录企业内外用户调用模型的历史记录，以便企业能够了解模型的使用情况，以便重新训练模型和迭代优化。
模型服务作为Web应用程序公开，除了成为API和Web应用程序之外，模型结果还具有更加多样化的交付形式。例如，形成模型的项目代码片段可以沉淀下来，以便在开发下一个类似模型时直接使用。通过ModelWhale Jupyter Notebook侧边栏中的代码片段库功能，模型研究人员可以提前收集以前研究中可能重用的代码片段，然后在后续研究中找到相应的代码片段并直接插入代码库的“My Collection”中，完成重用。
如前所述，企业决策模型中平均有87%实际上并没有运行，任何未作为应用程序部署的模型文件都可以作为逐步的结果，以供以后使用。使用ModelWhale算法库，用户可以将生成的算法模型进行文本描述沉淀，实现模型的组织和共享。
算法库功能模型沉淀管理，跨部门、跨角色协作在一次一键重现模型工作流ModelOps注重模型整个生命周期的流畅性，而模型开发应用程序往往是由多个人完成的。ModelWhale开发了一套功能来应对团队合作中经常发生的“冲击碰撞”。例如，上面提到的生产元素的版本控制、环境的可重复性、计算资源的调度等等，都支持跨部门和跨角色的开放性。在模型项目代码中，不同的人可以同时进行协作。对于镜子，不是每个人都需要制作轮子，任何镜子都可以分发和重用给组织中的任何成员。在计算能力方面，除了正常的计算能力分配外，ModelWhale还提供了资源申请机制。如果现有的计算资源不够，模型项目团队的管理员可以通过启动应用程序来及时获得计算能力，以满足不同的研发需求。在模型交付阶段的基于代码库+算法的功能中，代码片段和模型文件支持组织内的权限管理和分发。此外，ModelWhale还具有用于任务规划的项目管理工具，允许项目负责人将新任务分解为子任务并进行分配，与模型开发团队合作完成复杂的项目研究。
项目管理工具、任务规划界面甚至ModelWhale都为团队协作提供了更高维度的模型结果。如果公司希望模型资产变得更加“先进”，模型研究人员不仅需要计算机开发人员，还需要包括更多的“商业人士”。例如，在开发与医疗相关的模型时，除了在现场“敲代码”的人员外，还需要在模型的研究团队中有临床医生（业务人员）然而，计算机技术并不是临床医生的强项。那么，我们该如何忽略细颗粒代码来理解模型并提供适当的指导呢？ModelWhale提出，模型代码可以封装在可视化组件和过程模板中，因此业务人员不再需要了解代码本身，而只需要了解代码块的作用。这样，当业务人员提供相关指导时，他们就可以使用此模板构建一个简单的模型过程，并与开发工程师进行良好的协作。此外，技术人员可以将业务人员构建的模型过程直接还原为笔记本代码，从而节省从头开始编写的时间。
在Canvas中快速构建项目分析流程需要解决的最后一个问题是将模型结果逐步转移到公司内部。首先，您可以使用算法库功能，但如果您的业务更多地关注模型结果而不是模型文件本身，那么这种方法将不起作用。它看起来像第一节中的场景1。ModelWhale升级了Notebook，因为A公司长期以来一直在努力用传统文档+ 自然语言来承载模型结果。Jupyter笔记本不仅具有版本控制、多人高效协作、随时重现分析过程，还具有图像交互、交叉引用等功能。单元级的直接引用可以将模型结果直接汇总到一个整体的结果报告中，从而支持有效的可追溯性。最后，笔记本还支持多种格式的导出，如HTML，Word和PDF，开发人员可以选择。
本文重点介绍了企业数字化转型的关键资产--模型，介绍了生产工作流中出现的问题、ModelOps概念和数据科学协作平台ModelWhale，并探讨了ModelOps产品实现和相关问题的具体解决方案。作为数据科学领域的工具和平台，真正发挥平台的产品能力是关键。ModelWhale利用其积累的经验和方法论，帮助企业组织使用场景，完成模型的生命周期管理，希望能给绝大多数企业带来实质性的帮助。如果您想更好地了解ModelWhale的功能和模型开发应用程序的实际用例，欢迎访问ModelWhale官方网站。