【Line AI生产力关键2：ML品质监控自动化】自建MLOps监控平台，上百项ML产品模型漂移能即时调校

“我们有100多个机器学习产品，横跨20多个部门中运作！”Line机器学习开发部工程师石河纯辉说。当AI深化到企业内部各流程，就得有套机制来监控模型，以便在模型偏移时即时调整。这种机制就是MLOps。

高度仰赖AI的Line深知MLOps重要性，但仍面临不少挑战，像是收集模型各类指标、模型异常侦测和监控视觉化等问题。经过一番琢磨，他们找出一套解法，自行开发一套MLOps监控工具Lupus，提供专属监控主机、专用函式库和视觉化仪表板的网页应用，让开发者、维运者和专案成员更容易掌握ML模型的动态和品质，甚至可用来即时重新训练模型，修正模型预测的偏差。

为何MLOps不好做？资料漂移、周期性特性比DevOps复杂好几倍

谈起维运，最为人熟知的就是DevOps，诸如资源使用状况（CPU、内存等）、网络流量变化、硬盘读写能力等，都能靠一套成熟的监控机制来自动、定时把关，还能用逻辑简单的警报系统来提醒维运者。

但，MLOps远比DevOps要复杂。石河纯辉指出，MLOps是“ML + Dev + Ops”这三种工作流程（也是团队）的整合，工作流程涵盖了ML阶段的模型设计、分析、评估，再加上Dev阶段的资料收集、工作流程建立，还有与Ops阶段重叠的模型派送工作等。甚至，Ops阶段还需要进行模型维运和监控。

要发展一套MLOps流程，得涉及资料和模型两大层面。就资料来说，维运者得注意输入资料的变化，也就是资料是否发生漂移，另也需注意输入值的目标模式变化，即是否发生概念漂移。在模型部分，则要注意模型准确度、推荐值的多样性，以及模型公平性。

而且，石河纯辉指出，MLOps监控频率会因模型而异，无法像传统DevOps作法，只是简单地设置阈值警示通知即可。有些模型数小时就得检测一次，有些是数天才需要，得依不同ML应用的生命周期来设定。

Line跨部门上线100多个ML产品，自建管理工具仍不足

对Line来说，负责管理ML模型应用的就是机器学习开发部门。他们专门设计ML产品，来给不同单位使用。石河纯辉透露，他们至今已上线100多个ML产品，遍布内部20多个部门。为管理这些模型，Line机器学习部门也设置一系列MLOps工作流程和工具。

他们以K8s和自建的Hadoop丛集资料统一平台“IU”为主要运算环境，并自建Jupyter主机Jutopia来提供模型开发环境，让开发者用来分析资料、进行实验。同时，Line采用3套工作流程引擎如Airflow、Argo Workflows和Azkaban来处理批次工作，并以CI/CD工具ArgoCD、Drone CI进行模型部署派送工作。

除了使用开源工具，Line机器学习部门也自建了专属工具来管理AI模型，像是共用特征向量管理器，用来收集使用者行为日志和产品后设资料（Metadata），让不同ML专案也能使用这些共通性的资料。此外，还有一套内部函式库，来进行模型收集、分散式训练和推论、管理输入和输出，以及推荐自动化等工作，在测试工具上，也自建一套外部实验管理软件，来管理AB测试、生成推荐的展示等。

“这些工具解决了ML + Dev + Ops的大部分工作，”但石河纯辉话锋一转，唯独Ops中的模型表现监控尚未做到。

Line MLOps三大挑战：资料遗失、模型更新、手动监控

也因此，他坦言，随着自家上线的ML产品越多，监控成本越来越大，再加上Line当时的监控和通报机制是每个专案各自建置一套系统，在这种做法下，监控系统的效果不强，只能根据最少量的变动指标来通报。也因为没有一套好的监控系统，团队无法察觉资料缺失、模型输出值的变化等状况，甚至曾造成已上线ML模型停摆。

石河纯辉进一步分析，Line MLOps有三大痛点要克服。首先是资料缺失，当模型训练的资料发生遗漏或延迟发送，就会造成模型预测不佳，甚至产出无效预测值。举例来说，Line有套Email预测系统，每天根据外部单位传送的表格资料，来进行行为预测，再将预测结果回传给外部单位。若表格上的资料有缺漏，就会影响模型表现，没有好的监控系统，工程师也不会察觉异常，“这发生过几次了，”他说。

第二个痛点是模型更新。他回忆，团队曾经在模型架构更新时，忽略了新旧模型的预测值分布状况，即便新模型的预测值更准确，只要预测值分布明显改变，就会大幅影响个别使用者属性，给出截然不同的内容，降低使用者体验。“这种现象，当时要2个礼拜后才发现、改善，”石河纯辉强调。

第三个痛点则是手动监控问题。因为Line针对各专案，在Jupyter Notebook中建置了专属监控系统，来追踪模型指标、视觉化呈现结果。这个做法虽然方便，但手动收集的指标，只在当下有用，很难重复利用。而且，触发警报的条件只能套用简单规则，更是常常无法审查整体监控程式码的品质。

瞄准指标收集、异常侦测和视觉化，自建监控机制Lupus

为克服这些痛点，Line机器学习开发部门决定打造一款MLOps监控工具，要具备三要素，要能轻松收集指标、快速侦测异常，还要有友善的视觉化界面，让专案成员随时掌握模型动态。

这款工具就是Lupus，由三大部分组成，首先是建置Lupus主机，用来管理变动指标、提供异常侦测API，再来是一套Lupus函式库，可提供各种指标聚合工具和API客户端。最后是Lupus SPA应用程序，这是一款网页App，可视觉化图表来呈现指标状况和异常侦测结果，也内建验证功能和后设资料管理。

在这套ML模型监控系统中，指标收集任务启动后，Lupus函式库会随之启动，Lupus SPA也会同步显示指标状态。再来，Lupus主机作为入口点，所有请求都由这台主机处理，也负责授权验证工作。启动后，Lupus主机还会发送请求给不同Worker，平行执行指标收集工作和异常侦测工作。这些工作会使用前述的Airflow等工具来排程执行，而Lupus也有一套Worker机制来管理工作流程，以及记录后设资料。

Line自行打造的MLOps监测工具中，包含一套网页App：Lupus SPA，可让专案成员查看模型指标变化图表，让模型变动资讯更容易分享、讨论。图片来源_Line

至于收集到的指标和异常侦测资料，则长期储存于开源的资料仓储Hive，并利用开源搜索引擎ElasticSearch来提供资讯搜寻和视觉化呈现。

指标收集运作上，Lupus函式库可用来整合不同指标，将指标所需的资料推送到Lupus主机，主机再上传指标至S3相容的储存库，并提交收集工作至伫列。最后，工作流程工具会将资料储存于ElasticSearch和Hive中。石河纯辉指出，指标收集可用来衡量资料漂移、概念漂移，也能决定模型是否要替换。

而在异常侦测机制上，可以利用Lupus函式库的API来发送侦测请求，进而促发工作流程工具来读取储存于Hive的指标，开始进行侦测，并将异常资讯储存于ElasticSearch和Hive。这些都内建在Lupus函式库中，方便ML开发者容易整合到ML专案中。

最后，ML专案所有成员都可以利用Lupus SPA，在App上查看各指标的趋势图表和异常侦测结果，也能直接展开细节说明。石河纯辉总结，这套MLOps监控工具，让每日的指标收集工作更容易进行，也能侦测到之前未注意的异常，更能发现新洞察，像是模型准确度的变化，进而激发成员改善ML产品。此外，这个方法也让Line团队的监控程式码经层层审查，比过去的自制方式更可靠。而视觉化的网页App，则让团队更容易分享模型资讯，提高沟通效率。