算法量产中的业务算法平台

简化算法开发者和业务开发者的协作。通过对算法和业务配置的复用，增强业务的扩展性，提升业务系统中算法迭代速度。

背景介绍

算法落地难一直是 AI 领域面临的核心困境。为了加速算法迭代速度，自动化落地流程，扩展算法变现领域，业界提出了很多解决方案。

MLOps

MLOps 将 DevOps 理念应用到 ML 领域，将数据团队、模型开发团队和运维团队联系起来，建立起一个标准的模型开发、部署、运维流程。

更多介绍细节参考文章 MLOps 科普。

算法量产

MLOps 无疑加速了单个算法应用的落地，但缺乏应用级别的可扩展性，缺少对算法的复用，限制了变现领域。

我们知道算法的核心是模型，但只有模型并不能变现，必须要在模型的基础上提供应用，比如 ChatGPT。对于新兴的大模型领域，MLOps 可以工作的很好，这个研发闭环搭配一个 toC 的应用外壳就可以迎来很多受众。但对于 toB 的企业而言，面临着业务类型、硬件环境等差异。为填补这些差异，算法量产作为 MLOps 的扩展应运而生。

简单来说，算法量产就是对模型算法的复用，主要的扩展方向包含以下两类：

• 适配不同硬件计算平台，包括嵌入式算法，服务器算法等，对于服务器算法还需要对不同的 GPU 类型进行适配。
• 适配不同业务应用系统，比如同一个人脸识别模型可以被封装成门禁业务系统与抓逃业务系统。

在这种场景下，企业需要维护 M 个算法适配 N 个计算平台的算法，又需要被封装成 K 个业务系统。

我们称可以直接被业务使用的算法为业务算法，一般而言，公司需要维护的业务算法规模为 M*N*K。

算法量产指的是一套适配多平台、多业务的算法落地流程。

• 训练平台训练的模型经由算法适配平台产出适配不同计算平台的通用算法。
• 通用算法经由业务算法平台被封装成若干个业务算法。
• 业务算法上传到训练平台，训练平台来运行通用算法，并将业务配置透传给业务系统。

业务算法平台

业务算法平台主要关注多个业务如何适配通用的算法， 通过复用算法与业务配置提升对 K 这一维度的可维护性。

业务对算法的适配主要包括两点：

• 业务需要根据通用算法的输入输出生成一份转译配置，比如转译成 json schema 供业务前端渲染出表单，而不同系统可能存在不同的术语描述。
• 对算法模型的宏观配置（参数）的调整。
• 不同业务对算法模型有着不同的加密授权需求。

历史背景

在业务算法平台出现前，业务开发者与算法开发者协作十分不畅，主要分为两种方式。

代码耦合

算法逻辑与业务配置代码耦合，算法开发者和业务开发者同时维护一个 git repo。

好处是通过 VCS，所有的变更可追溯，相应的 CI 可以自动化打包发布流程；问题是算法与业务紧耦，一旦某一方需要变更时需要全量发布。算法的发布是很重的操作，仅业务配置的变更不应引入全量重新打包的开销。

人工关联

算法开发者与业务开发者建立联系，当算法开发者发布一个新算法时，会告知业务开发者，业务开发者结合算法的参数、输入输出等手动添加业务配置，并发布业务算法包。

好处是算法逻辑与业务配置耦合度低，业务变动可以单独发布新版本；问题是需要大量的人工处理和跨部门沟通，业务配置变更不可追溯。

为使得算法侧与业务侧协作更通畅，业务算法平台的构建迫在眉睫。

功能

业务算法平台主要提供了对通用算法、业务配置、业务算法进行三方管理，并加入打包、鉴权、审计等功能。

通用算法管理

通用算法指能在推理平台上运行的、具有特定格式的算法包，具备完备的推理功能但不具备特殊的业务属性的平台级算法。

通用算法的发布模式是由算法开发者构建的一套基于 GitOps 的流程。对于发布的通用算法包，通常需要经过算法开发者的测试后流转到业务开发侧，需要大量的跨部门沟通的工作。

为避免繁乱的临时版本算法的干扰，业务算法平台接管了已发布的通用算法，避免大量中间不稳定版本给业务开发者造成困扰。平台提供算法订阅机制，一旦有算法发布了新版本，可以通知到订阅方，使得跨职能的协作更具流程化。

业务插件管理

业务配置的复用是很有意义的，因为大部分情况下业务配置不需要变更，且算法对计算平台的差异不会影响业务配置。常见的算法变更场景及发生概率如下：

• 新开发一个领域算法 < 1%
• 新开辟一个业务场景 < 1%
• 新增加一个计算平台 < 1%
• 非算法驱动的业务配置变更 < 5%
• 算法的配置、输入输出参数发生变化 < 5%
• 算法优化更新、bugfix > 90%

我们定义了一套业务处理规范，以通用算法为输入、业务算法为输出，将相应的业务配置注入到通用算法包里。我们按业务处理规范定义了业务插件，以声明处理流程。业务插件的实现支持以下四种类型：

• Service

  • 构建 web server 提供 rest api 完成业务配置的注入，一般需要在插件中声明 service 的访问方式。
  • 优势：
    • 灵活性强，后向兼容性满足时，可以大大减少业务插件版本管理的复杂度。
    • 可以利用 cache，提升处理速度。
    • 安全性高，当处理过程需要访问数据库时，不需要将密码透露给平台。
  • 劣势：
    • 可能需要维护多个 server 版本。
    • Web server 为常驻服务，资源消耗较高。

• File

  • 插件中包含要注入的完整业务配置文件。
  • 优势：
    • 简单。
    • 组装速度快。
  • 劣势：
    • 只能注入静态文件，不支持对通用算法中的配置进行动态调整。

• Job

  • 将业务配置注入脚本封装在容器内，平台以提交异步任务的方式进行处理。
  • 优势：
    • 非常驻服务，按需触发，节省资源。
    • 异步的方式对于处理耗时较大的应用比较友好。
  • 劣势：
    • 搭建 job 的速度慢，会大幅增加延迟。
    • 异步的方式对交互不友好。

• Function

  • 用户需要写处理函数，由 FaaS 平台负责构建镜像，支持按需启动。
  • 优势：
    • 按需启动，相比于 service 节省资源。
  • 劣势：
    • 环境管理复杂，依赖 FaaS 平台的支持。

业务算法组装

组装过程可以简单描述为：通用算法包 + 业务插件[1…N] = 业务算法包

参考 CoreDNS 的链式插件机制，组装的中间阶段产物为业务算法包，这样的链式处理有以下两个好处：

• 易于支持业务系统进行集成，只需要将两个系统的配置链式注入到通用算法包即可。
• 可以将业务配置处理逻辑打散，将其分为通用逻辑与特殊逻辑，在业务层进行复用。

业务算法包管理

业务算法是最终交付的算法包，而通用算法包只在内部流转。这意味着通用算法包的使用不需要考虑运行环境，而业务算法包则需要考虑完备的运行环境。

这里运行环境指的是其依赖的制品，如镜像、模型等能够使业务系统运行起来的软件环境。

基于这种交付模式，算法包被划分为 thin 包与 full 包两种类型。

• Thin 包仅包含算法的描述内容、输入输出等信息。
• Full 包在 thin 包基础上添加了运行环境，如二进制包、算法镜像等。

通常，算法包存在的形态总结如下：

• 通用算法包全部是 thin 包，只在内部进行算法测试。
• 业务算法包在内部进行业务测试时，使用 thin 包，交付测试时使用 full 包。
• 业务算法包正式交付到现场时，使用 full 包。
• 对于服务器算法包而言，thin 包的尺寸为 KB 量级, full 包 尺寸为 GB 量级。
• 对于嵌入式算法包，其内嵌可在设备上运行的二进制文件，因此不区分 thin 包与 full 包。嵌入式算法包一般是 MB 量级。

平台组装的业务算法包都是 thin 包，平台需要支持业务算法打 full 包并在打包的同时引入加密授权避免模型滥用。

Full 包的管理通常需要考虑以下几个方面：

• 可能存在多种授权方式的 full 包。
• Full 包需要与 thin 包一一对应。为了提升使用体验，当前实现允许通用算法覆盖更新并组装成新的 thin 包，以方便算法测试与迭代。而一旦打过 Full 包后，意味着算法包处于可交付状态，禁止 thin 包及同版本的通用算法发生变更。

实现

前端

基于 React 框架，使用 Next.js + NextAuth.js + Material UI 的技术栈。参考 React前端快速构建。

后端

后端主要实现了权限管理、业务算法的组装、打 full 包、算法包和业务插件的版本管理、审计、订阅、下载等功能。

下面列出一些着重考虑过的点：

• 包管理策略参照 私有化交付平台——打包篇 使用 OCI Registry 作为统一存储，存储 thin 包和镜像。这样做的好处是无需依赖额外的对象存储，减小平台的复杂度，便于该平台的私有化改造。

• 打 full 包的过程并不产生完整的 full 包，只构建出相应的镜像，通常会在通用算法镜像的基础上扫描 rootFS，并对模型文件进行加壳、授权。

• 平台不存储 full 包实体，用户在下载 full 包时，平台会自动将镜像等运行环境注入到 thin 包中，形成 full 包，以边下载边组装的形式减小额外的存储及多次 IO 开销，提升下载速度。

• 不同授权方式的 full 包体现在镜像 tag 上，如通用算法镜像为some-model:v1，威布软狗授权的镜像为some-model:v1-soft，威布硬狗授权的镜像为some-model:v1-hard，需同步更新算法配置中的标识。