为什麽87% 的资料科学专案没办法产品化？ | MLOps落地指南 - 技术篇

“为什麽87% 的资料科学专案没办法产品化？”在Transform 2019 of VentureBeat[1] 的一篇报导给予了这样的宣告。这并不是一个小数字，这样的数字来自於(1)团队在执行的时候没有正确的视野与方向(2)资料来自不同的格式、结构化和非结构化的资料。结构化的资料像是我们一般所熟悉的database里面所储存的资料。非结构化的资料如影音、文本和图像可能保存在不同的地方，电脑用不同的方式理解这这些资料，并且这些资料具有不同的安全和隐私要求(3)系统需要大量的团队合作，彼此对彼此要做的事情若是不熟悉，就要花去许多时间沟通。如何让自己所在的团队不要成为那些87％的专案，我们接下来就来看，透过技术可以怎麽切入。

技术

MLOPs落地的三个关键：团队、技术、流程。在ML专案当中，把模型从实验阶段推向产品化的过程，开发者在资料、模型、程序的管理与合作上都需要有更近一步的要求。近几年的软件开发常谈到的持续交付，也同样反映在ML专案上。一个成熟度高的ML产品在CI(持续整合)、CD(持续部署)、CT(持续训练)上也有系统性的方式维护，让合作的开发者能够轻易地接手、维护该专案。

资料

资料的收集可以说是整个专案最重要的步骤之一。(另一个步骤我会说是商业与ML问题的相映，但可以找另外一篇详述。)

ML模型学习的对象就是我们提供给模型训练的资料，处理资料的工作包括：

• (1)资料撷取：收集内外部的资料来源。外部来源像是向其他厂商购买资料、爬虫。内部资料可能包含跨部门以及跨单位的资料授权。
• (2)验证：验证资料收集的格式，是否符合需求。
• (3)探索：透过视觉化或者统计指标，来看资料的各特徵是否与我们理解的相符。
• (4)特徵工程：在验证资料以及探索资料的过程，根据应用情境决定是否要将资料集去除某些资料，或是跟其他部门沟通，将资料整理过转换成适合这个专案的资料集。
• (5)标记：在监督式学习的情境下，需要标记哪些资料相对应於哪些标签、类别。
• (6)资料集拆分：训练、验证和测试资料集。

这些工作内容时常是Data engineer的工作范畴。当一个资料及被称作是高品质的资料集，通常符合以下条件：

• (1)内容格式一致：包含(a)档案编码(utf-8, 或其他)、(b)同一栏位使用语言统一(非中英夹杂)、(c)资料表里面没有空值，当没有相对应的数值时，至少会有预设值。

• (2)资料逻辑对应商业逻辑：(a)资料表里面若有分类或是标签，一率有相对应的号码解释对照文件可查阅、(b)若是不同地域性、不同国家，则须标示清楚时区、使用币别、测量单位(例如公尺、英尺)。

• (3)即时性：(a)资料表具有建立时间和更新时间、(b)资料的更新程度与公司提供的服务热门程度、使用者使用网站所建立的资料量是相对应的、(c)收集资料的过程当中如果有偶发性事件，或是特殊事件，同时也必须反映在资料及的处理上。

当资料的品质越好，模型就越能反映出在这个资料相对的业务问题。在未来市场扩展的时候，也需要时常回头看，资料是否因为数据局部性，而不足以反映整个市场的样貌。开资料取样则应该调整，针对不同用户的人口资料收集与训练。

模型

刚谈完资料，模型的部分除了大家时常谈到的(1)演算法选择之外，这部分还包含了(2)超参数(hyper-parameter)训练、(3)模型测试、(4)模型评估、(5)模型注册、(6)模型发布、(7)模型监测。

• (1)演算法选择：这个问题属於ML问题的哪一类，根据资料集的特徵，例如资料偏移(data skew)、或是空资料很多的状况下，有哪些演算法可以克服这些状况？提供相对好的预测？
• (2)超参数(hyper-parameter)训练：在设计演算法实验的时候，有许多参数是可以影响实验结果的，这些参数少则3-5种，多则20种也是可能的。在这些参数的组合当中，要如何找到最好的组合，常常也是资料科学家在跑实验的必要过程。关於演算法的选择跟超参数的选择，现在都已经有一些工具可以协助完成，资料科学家可以不必再用手动一次次纪录实验结果，而是透过自动化的实验去完成这些选择。
• (3)模型测试：完成模型与超参数训练之後，接下来则是要测试模型的训练结果。由於资料量的大小不同，以及各种演算法的复杂程度不同，有些模型训练的时间特别长，因此也会花更久的时间才能够对模型测试，决定要不要修正模型，还是准备要送出模型到下一个阶段。在模型训练期间，资料科学家们也会运用Tensorboard、SageMaker Debugger等工具在训练进行的过程中，就可以看到模型的训练以及测试状况，让时间的成功与失败可以被及早观察，及早修正。
• (4)模型评估：模型测试与评估的不同点在於：模型测试完全注重於演算法的metrics，像是precision、accuracy、F1-score等等。模型评估则必须与商业期待相互对齐，举例来说，符合公司重要VIP的轮廓的使用者都能够准确地被预测，因此公司可以带给重要的客户更好的品质。或是说公司希望给客户一个慷慨大方的形象，即便不符合VIP的条件还是有可能会收到奖励等等。在这个阶段确保模型的表现比过去更加优秀、或者更有效地提供使用者好的服务。
• (5)模型注册：在评估过後，发现新的模型相对过去的版本表现较优良，这时候就可以将模型注册，将模型的参数档案送往储存的地方。以便系统可以使用该档案发布或者回溯到某一版本。
• (6)模型发布：模型的发布与服务使用者的产品息息相关，我们曾经谈过，ML产品本身是依附在某一产品之下，也就是说使用者大多会先接触到使用者面向的产品，该产品的服务後端再去呼叫ML产品。因此模型发布包含的细节像 (a)开发环境 ：模型上线时所对接的服务，同样也有开发、测试、产品等开发环境，如何让产品在不同环境，都能使用到预设的模型版本，并确保在各环境的行为都相同。(b)A/B test：另一个则是在发布的过程当中，是否会需要A/B test，将使用者导流到不同版本的模型，这些导流是要从ML产品这边进行交通引流，抑或是在使用者产品的阶段就有规划引流了。(c)可扩张性：ML产品本身是否支援高稳定度、安全以及可扩张性等等规格，让使用者产品在呼叫ML产品的时候，可以享有同样规格的体验。
• (7)模型监测：模型监测的同时，也须观察使用者呼叫模型时候的资料，也可能会与过去收集的资料分布不大相同，我们称这个状况叫做模型衰减、资料偏移。

程序

将训练好的模型整合到公司的业务产品的过程。包括 (1)资料前处理、(2)模型预测、(3)预测後资料处理、(4)效能监控和(5)效能日志记录 等。其中会使用到的程序码需要分为训练和预测这两个开发周期，以助於确保资料的安全运行环境以及有效的测试周期。

如果对执行细节想要了解，前阵子我也整理了另一篇史丹佛cs329课程内容，谈到根据资料验证、版本控制、模型监测、标签资料、CI/CD 测试、部署、模型压缩、推理效能优化、隐私，这几个主题可以使用的开发框架。

结语

当我们对於MLOps有了一些了解，也知道有哪些工具可以协助我们从技术上实作的时候，也开始对专案的未来觉得更明朗了。在这过程当中其实应该让ML专案尽量保持简单，随持回到初衷去思考：想传递的价值是什麽？是不是一定要使用这个架构、实作方式？如果这个功能没办法如期完成，或是第三方的产品不支援，可以用什麽方式去完成？

ML专案不是一夜魔法，当我们拥有技术的时候，就是让自己的产品与使用者回馈可以快速收集资料、快速调整的时候。有了最简单版本的模型之後，可以再加入更复杂的数据集、更复杂的使用者族群，甚至跨地域性、跨市场的实验及部署。无论是再怎麽新颖或老旧的技术或是模型，大家的目标都是希望带给客户最好的体验。

Reference
[1]. Why do 87% of data science projects never make it into production?
https://venturebeat.com/2019/07/19/why-do-87-of-data-science-projects-never-make-it-into-production/

[2]. How to Use MLOps for an Effective AI Strategy | Exploring the ML pipeline (CI/CD/CT)
https://www.kdnuggets.com/2021/01/mlops-effective-ai-strategy.html