机器之心分析师网络
作者：Yuanyuan Li
编辑：H4O
本文主要对 OpML 2020 大会上的一些议题进行了探讨，如生命周期管理等，并对大会嘉宾提出的一些从业观点以及作者个人的经验进行了整理分析。
1. 介绍
受到新冠疫情影响，本届 OpML（USENIX Conference on Operational Machine Learning）和其他许多大会一样，改于八月初在线上举办。但也得益于此，会议上展示的所有 talk 目前都对公众开放，既展示了目前工业界主要关注的机器学习问题，也给了大众一个了解目前机器学习在业内发展情况的窗口。
作为专注于可操作的机器学习（Operational Machine Learning）的会议，OpML 关注的重点是将机器学习部署到生产中并对其进行产品生命周期管理 （life cycle management）。OpML 试图将 ML 研究人员和实践者（例如，数据科学家，数据工程师，系统 / IT 管理员和 DevOps 专家）聚集在一起，以开发并付诸实践具有影响力的研究和前沿解决方案。
本届 OpML 共有 8 个 session，分 8 天进行，相当于每天有一个不同的主题，包括嵌入数据科学分析算法的框架的搭建（Deep Learning and GPU Accelerated Data Science）、产品的生命周期管理（Model Life Cycle）、产品 / 模型的可解释性（Features, Explainability, and Analytics）、算法（algorithms）、模型的部署（Model Deployment Strategies）、从产品角度看人工智能（Applications and Experiences）、模型训练（training）以及隐私和道德问题（Bias, Ethics, Privacy）。
由于 OpML 是以不同主题展示会议内容的，并且个别受邀嘉宾只分享了一个 talk，并没有相应的论文以供讨论。笔者也将挑选自己感兴趣的主题进行讨论，侧重点更多集中在嘉宾所分享的从业观点和笔者个人的经验，而非理论方面。
2. 生命周期管理 （life cycle management）
在这个主题下，以 Netflix 的 talk——Runway - Model Lifecycle Management at Netflix（https://www.usenix.org/conference/opml20/presentation/cepoi）——为例，我们可以探讨一下目前产品生命周期的管理。
痛点 1：模型批量管理
在工业界进行机器学习模型的研发，最终的目标是将该模型部署到一个完整的系统中作为一个产品呈现给消费者。许多产品在研发初始阶段就要创建产品卡 （production card），将产品的各项指标或者预期指标记录在案。这一方面是为了方便档案管理，另一方面是为了方便产品真正上线以后的更新迭代，比如对更多平台 / 地区的兼容、或一些顺应消费者需求的新特征。
在这种情况下，工程师需要对产品中的每一个部件，包括软件，进行版本记录。以产品内部署的神经网络为例，工程师需要记录的信息包括从深度学习平台到随机种子。在此之上有时还需要设置一些简单的加密——如 sha256——来对模型进行核对。但神经网络的训练是具有一定随机性的，一个好的神经网络模型的产生，往往建立在几百次的实验之下。
如何管理在研发过程中产生的大量冗余模型，是开发机器学习产品的第一个痛点。具体来说，模型的管理应该包括单不限于：
能够记录创造该模型的数据科学家
能够快速查看模型的一些基本数据，比如输入数据的形状（input shape）
能够可视化神经网络的结构
能够比较多个模型的表现
能够像数据库一样进行查找、删除等操作
根据每个公司的主要业务和计算资源不同，其理想中的模型管理器的功能也会有些区别。以 Netflix 的模型生命周期管理器为例 Runaway 为例，使用者首先能够在其中进行搜索。
图：Runaway feature 1。图源：Eugen C. and Liping P. (2020). Runway - Model Lifecycle Management at Netflix. OpML.
点开具体的模型后，页面上能够显示该模型的相关信息。如果是已经在云端部署的模型，还能够显示发布时间、使用情况等等。
图：Runaway feature 2。图源：Eugen C. and Liping P. (2020). Runway - Model Lifecycle Management at Netflix. OpML.
另一个非常有用的功能是对模型进行可视化。不管是由于时间久远，还是由于不好的命名习惯，相信每一位数据科学家都有过面对自己创建的模型却想不起来模型涉及到的具体操作 （operation）的情况。Runaway 提供了对模型进行可视化的机会，可以帮助数据科学家对自己的工作进行快速回顾，以及非模型创建者对模型的基本原理有一个大致理解。
图：Runaway feature 3。图源：Eugen C. and Liping P. (2020). Runway - Model Lifecycle Management at Netflix. OpML.
除此之外， 一个常被忽略但却非常重要的功能是对训练用到的数据版本进行追踪的功能。这个功能一般是通过在生成一个数据集的时候同时生成一个 hash，然后将该 hash 以及其他元数据 （meta data）一起存储在一个单独的配置文件里实现的。在训练模型时数据集中的元数据也会被复制过来，并一起存储在模型的配置文件中。
目前对于模型的管理业内还没有一个统一的解决方案，基本上是公司内部根据自己的需求进行搭建和开发。需求较小的公司会选择向相关的咨询公司购买相关服务或者由雇员自己进行简单管理。如果在开始一个项目时没有这方面的意识，对后期工作的分享和移交都会造成很多不必要的麻烦。
痛点 2：数据漂移和概念漂移
如下图所示，数据漂移 （data drift）主要指的是在产品在实际使用环境中所面对的数据和训练数据不同，比如随着时间的变化，数据不再服从正态分布。
概念漂移 （concept drift）则指的是实际使用环境中 ground truth 标签和训练数据的 ground truth 标签不符的情况，比如由于潮流的影响，消费者对于时尚的定义每年都在变化。
如果在产品部署后不及时对其表现进行追踪，就会造成由于模型表现变差而带来的收益下降现象。
图：数据漂移和概念漂移。图源：Prophecy Labs, CTG & NannyML. (2020). Monitoring AI in Production. AI4Growth.
笔者目前见到的大部分模型管理系统主要是针对云端部署的系统的，一方面也是因为如果模型是在云端部署的获得其表现要相对容易一些。一般来说，这样的管理系统主要是通过以下几个步骤对模型表现进行监控的：
利用如描述性统计等手段，对模型的输入数据和预测进行监控
根据一些指标定期检查模型的表现，比如用户转化率是否有所下降
如果检测到模型的表现下降超过警戒值，触发警报
由相应的数据科学家进行详细的调查，判断是否需要利用重新训练等手段对模型进行修正
一个问题是目前的解决手段主要是对模型进行重新训练或者修改偏置（bias），这对云端部署的模型来说还算比较可行，但对嵌入式部署的模型就不那么容易了。不过这个问题本身也属于 open research field，笔者目前只见到过在进行内测的产品，还没有直接在市场上见到待售的产品，希望在未来几年随着机器学习 / 人工智能发展的更加成熟这个问题能够得到更好的解决。
3. 产品及经验（Applications and Experiences）
3.1 无人驾驶
本次 OpML 2020 上无人驾驶技术的分享是由 Nvidia 的无人驾驶团队带来的，他们展示了 NVIDIA 内部端到端 AI 平台 MagLev，以及如何将其用于开发其自动驾驶汽车软件 DRIVE。虽然这个分享实际上首发于此前的 Nvidia GTC 开发者大会，并且这里展示的只是一个简化版，但笔者仍然这是本次大会上最值得一看的 talk。它最大的价值就在于完整的展示了 Nvidia 搭建一个框架的过程，包括从产品的需求去系统性的设计框架、如何解决实操中遇到的问题、如何最大化利用团队的资源。
MagLev 项目启动的目的之一在于解决海量数据的管理和应用。NVIDIA 团队根据无人驾驶模型训练的流程，记录下了每一步所需要的系统和平台：
数据收集：为自动驾驶汽车收集数据，往往涉及到不同传感器——相机、雷达、GPS 等——数据的融合，以及每分钟海量高清数据的产生所造成的存储困难。往往针对不同的子任务，比如识别交通信号，同一数据集还需要有不同的 ground truth 标签和维度 （2D vs 3D，有无深度信息等等）。MagLev 为此配备了数据插入平台（ingestion platform）和数据管理功能（campaign management）。
生成数据集：这一步往往涉及到对收集到的数据进行筛选、标注，自然的，MagLev 也需要有相应的数据标注平台。
模型训练：这里是数据科学家的主要阵地，MagLev 除了提供足够的计算资源，还提供了追溯功能（experiment tracking）。
模型部署：由于资源（耗电量、计算速度以及模型大小）的限制，很少有训练好的神经网络可以不经过量化 （quantization） 等优化就直接进行部署。而进行优化的风险之一就是模型表现下降，为此 TensorFlow Lite 和 TensorRT 等产品没少挨骂。MagLev 本身不直接提供优化工具，而主要提供云端计算资源和模型调试工具。
模型检验：一个产品的表现需要由其在最终使用环境中的表现决定，但对于自动驾驶这类产品来说，实地测试费时费力费钱。MagLev 提供一个仿真和回放平台，可以在上面利用仿真数据和已有的测试数据对模型进行预测试，通过测试的模型再考虑进行实地测试。
图：Maglev 平台功能一览。图源：CLEMENT F. & NICOLAS K. (2020). INSIDE NVIDIA’S AI INFRASTRUCTURE FOR CREATING SELF-DRIVING VEHICLES. OpML.
看到这里，相信很少能有人不羡慕 Nvidia 所拥有的资源以及它们已经搭建起来的平台，毕竟不是每个公司都能够提供几千块 GPU 和专门搭建的数据仓库供其开发人员使用。但本次 talk 除了带领我们一览全貌并诱发嫉妒以外，还有 3 个亮点值得参考。
亮点 1：主动学习（ACTIVE LEARNING ）
主动学习是一种通过模型与数据科学家之间的交互来降低训练所需要数据量更准确的手段。简单来说，数据科学家需要根据模型的预测结果来挑选出 “难” 学习的样本，并人工标注这些样本用以对模型训练。以二元分类任务为例，可以用随机初始化的模型对所有数据进行预测，如果预测的概率接近 0 或 1，则认为该样本具有某些模型可以识别的明显特征。若预测概率接近 0.5，则认为该样本是不容易学习的样本，需要人工标注。
在使用人工标注的样本训练模型后，可以用训练好的模型对剩余的数据再次进行预测。如此循环，直到模型的表现达到预期或所有数据都已被标注。
根据笔者的理解，Nvidia 使用的 active learning 并不完全是上面所描述的流程。Nvidia 更多的是利用已经训练好的模型对所有数据进行预测。然后结合贝叶斯学习等算法利用模型预测的不确定性进行打分，选出预测结果不好的样本单独进行标注，再用这些样本对模型进行再训练。Nvidia 在之前的开发者大会中透露他们主要关注 pool-based active learning 方面的研究。整个过程如下图所示：
图：Active learning。图源：CLEMENT F. & NICOLAS K. (2020). INSIDE NVIDIA’S AI INFRASTRUCTURE FOR CREATING SELF-DRIVING VEHICLES. OpML.
其实，这种工作方式在数据标注平台上几乎是“标配”，相关的研究也不少见，但在产品的研发平台上如此大规模的应用笔者还是第一次见。
Nvidia 分享了他们对主动学习进行 A/B 测试的结果——由数据科学家手动选择并标注 19k 帧数据，和利用主动学习由模型自主选择 19k 帧数据。下图中的结果显示利用主动学习模型的表现相对于手动学习大概提升了 2-5 倍，同时甄选数据的效率也大有提升。
图：主动学习 A/B 测试。图源：CLEMENT F. & NICOLAS K. (2020). INSIDE NVIDIA’S AI INFRASTRUCTURE FOR CREATING SELF-DRIVING VEHICLES. Nvidia GTC.
亮点 2：目标学习
目标学习 （Targeted Learning）应该是 Nvidia 团队自创的一个名词，实际上其概念与主动学习十分相似。
在主动学习中，数据科学家需要根据模型的预测结果找到 “难” 学习的样本。在目标学习中，数据科学家也需要做到这一点。不同点在于，根据模型在测试集上表现，“难”学习的样本是已知的。接下来，利用一些提前定义的相似矩阵，数据科学家可以从未标注的数据中提取所需的样本，并进行人工标注和重新训练。
下图展示了目标学习的流程，可以看到其基本框架与主动学习是一模一样的。
图：targeted learning。图源：CLEMENT F. & NICOLAS K. (2020). INSIDE NVIDIA’S AI INFRASTRUCTURE FOR CREATING SELF-DRIVING VEHICLES. OpML.
这里的关键主要在于用于抽取数据的相似矩阵的定义，笔者猜测 Nvidia 的团队应该是借鉴了图片搜索方面的一些算法，比如感知哈希算法（Perceptual hash algorithm）等。
亮点 3：仿真数据的运用
MagLev 团队在此前的 GTC 大会上提到了 Nvidia 目前拥有强大的仿真能力。从光线到天气，Nvidia 几乎可以模拟出驾驶环境中的一切要素。利用这一优势，Nvidia 可以合成一些比较罕见的驾驶场景用以训练自动驾驶模型，以增强模型的稳健型。比如下图就展示了一张在行车道上摆满了障碍物的合成图片。
图：仿真合成驾驶场景示例。图源：CLEMENT F. & NICOLAS K. (2020). INSIDE NVIDIA’S AI INFRASTRUCTURE FOR CREATING SELF-DRIVING VEHICLES. Nvidia GTC.
MagLev 的仿真平台提供了从传感器信号输入到控制器设置的全部接口，数据科学家通过在 Python 中对想要测试的场景进行描述，就可以直接测试整个产品在该场景下的表现。
看完这场 talk，除了大开眼界外，剩下的就只有感慨了。要开发一个集如此多的功能于一身的如此大规模的平台，所需要的资源是巨大的，大约也只有巨无霸公司才能做到。
近几年，驾驶行业内的巨头公司也开始发力，比如 dSPACE 目前也能够提供仿真软件对驾驶环境进行模拟。dSPACE 可以直接对电控单元（electronic control unit， ECU）进行开发，能够对底层硬件有更好的控制，在安全等方面有不小的优势。
再加上 GPU 存在能耗大、成本高、体积大的问题，FPGA 生产商 Xlinx 等也在联合各类传统生产 / 研发厂商，积极推进神经网络在 FPGA 上的部署。接下来的几年，市场上的竞争只会随着技术的成熟而变得越发激烈。
3.2 时间序列的崛起
近两年，除了对计算机视觉和自然语言处理的关注之外，更多的从业人士也开始将目光转向了时间序列——比如传感器数据和日志数据——的应用。
本届 OpML 大会与此相关的 talk 有来自 VMware 的 Challenges and Experiences with MLOps for Performance Diagnostics in Hybrid-Cloud Enterprise Software Deployments，利用用户数据——I/O、CPU 使用情况等——进行异常检测和根本原因分析（root cause analysis），如下图所示。
图：时间序列应用示例。图源：VMware (2020). Challenges and Experiences with MLOps for Performance Diagnostics in Hybrid-Cloud Enterprise Software Deployments. OpML.
这个方向算是笔者今年见到的比较多的一个机器学习的落地方向，主要涉及到从日志或者一些很容易获取的时间序列数据中进行故障检测 （fault detection）/ 异常检测 （anomaly detection）。原因之一是数据的易得性。
大部分公司都有软件自动对日志数据进行存储和清醒，个别行业的公司——比如拥有生产流水线的公司——还有专门产品检测数据。要训练机器学习模型，不需要单独构建数据集，已有的数据量往往已经足够，并且还横跨时间等多个维度。
当然，这个方向的应用难点之一也在于此——数据量太大。如果传感器的采样频率在几千次每秒，一条生产线上有十个传感器，那么 处理包含了 3 个月内所有传感器一天 24 小时不停采样的数据集，就已经要造成内存问题了。对于这样的数据，特征工程（feature engineering）非常重要，因为数据科学家必须要先从原始数据中提出特征才能进行建模。
分析时间序列的另外一个难点在于数据标注。公司虽然能够轻易获得大量的原始数据，但是其一般都是没有标签的。在理想情况下，时间序列中的每一个数据点应当都有对应的数据标签，但在实际情况中，笔者只见到过通过提前设计好的实验人为收集的小型数据能够做到每一个数据点都有对应的标签，这样的数据量又往往不足以支撑模型的训练。从目前的情况看，常用的有监督神经网络在这类时间序列上的应用有限，反而是 XGBoost、SVM 这样的模型更受青睐。
当然，时间序列的应用也有其优势，比如应用范围极其广泛。计算机视觉技术虽然应用范围也不窄，但是其发展方向往往不是已经竞争者众多，就是对安全问题特别敏感。或者两者兼有，比如自动驾驶行业。这也导致过去几年我们常听到有传言说 CV 能够落地的领域已经几乎饱和了。
而开发基于时间序列的产品，一方面还算是这两年比较新兴的方向，竞争者较少，其服务的对象还可以进一步开发不以人工智能为核心业务的传统企业；另一方面产品涉及到的应用——比如对用户数据进行异常分析、对工厂生产流程进行质量监控、寿命监控——都对安全性要求更宽松一些。
目前笔者了解到的这方面的模型的发展方向主要是混合使用基于规则的模型 （rule-based learning）和机器学习模型，产品整体以完整性、易用性和用户交互为主要竞争力。
完整性方面，产品要能够提供一整套流程的操作。以 VMware 的框架为例——如下图所示——其包括能够提供接口灵活的接口对数据进行录入、清晰、标记、整合等的数据插入平台；能够人工或自动的训练模型的机器学习平台，其中又包括从数据集中全自动生成一系列特征，并利用选择的特征对模型进行训练等功能；其次还要包括能够提供快速部署模型，并且能够对模型表现进行监控、接收用户的评价等的控制平台。
图：VMware 产品框架全貌。图源：VMware (2020). Challenges and Experiences with MLOps for Performance Diagnostics in Hybrid-Cloud Enterprise Software Deployments. OpML.
其中，记录模型的表现和用户评价的模块是重要性不逊于训练机器学习模型的模块。因为目前大部分产品依靠用户反馈来确定模型是否需要更新迭代。在 VMware 的框架中，用户可以对机器学习模型的预测结果—比如 I/O 延迟过久—表示支持或反对。若平台检测到过多反对，则表示可能出现系统目前还没有遇见过的问题，需要由数据科学见或相关工作人员进行专门的根本原因分析。在问题得到解决后，再选择对模型进行修正或直接重新训练。
图：VMware 用户反馈平台。图源：VMware (2020). Challenges and Experiences with MLOps for Performance Diagnostics in Hybrid-Cloud Enterprise Software Deployments. OpML.
总体来说，这类产品的关键词主要是极强的易用性 + 用户互动 + 快速迭代。笔者认为在接下来的几年里，这类业务可能增长极快。
4. 结语
从以上的分享中不难看到，机器学习 / 人工智能已经开始向细分市场渗透，而相应的产品设计也更多的从用户需求考虑。而非像过去一样，先设计产品，再创造用户需求了。从业者常用的神经网络模型在过去的两年里已经不怎么变化了，大部分人关注的是怎么样以一个完整的产品获得盈利。
笔者期待在接下来的几年里，一些常规的工作——比如神经网络的训练和管理——能够更加的规范化、流程化，因为一个好的框架能够事半功倍，让这些固定工作能够被更快的完成。
图：AI 的发展趋势。图源：Prophecy Labs, CTG & NannyML. (2020). Monitoring AI in Production. AI4Growth.
而从自身来说，一个优秀的从业者应该做到精通一个环节，同时对产品涉及到的每个环节都有一定的了解。作为一个数据科学家，不必拘泥于工作职称，将自己局限在计算机屏幕前。
如果供职于一个小公司或者大公司内的一个新建部门，就应该利用这个机会去积极的参与到研发中从数据收集到产品测试的各个环节上。同时，这样也会对自己使用的数据集质量、模型的表现等由更好的预期。
图：数据科学的生命周期。图源：https://mc.ai/the-data-science-life-cycle-for-deep-learning/
随着机器学习 / 人工智能越来越深入的进入到各行各业，该行业和机器学习 / 人工智能的交叉学科方面的人才相对于纯粹的算法工程师将会有更大的竞争力。
分析师介绍：
本文作者为Yuanyuan Li，几次转行，本科国际贸易，研究生转向统计，毕业后留在比利时，从事机械研发工作，主要负责图像处理，实现计算机视觉算法的落地。欣赏一切简单、优雅但有效地算法，试图在深度学习的簇拥者和怀疑者之间找到一个平衡。
机器之心全球分析师网络是由机器之心发起的全球性人工智能专业知识共享网络。在过去的四年里，已有数百名来自全球各地的 AI 领域专业学生学者、工程专家、业务专家，利用自己的学业工作之余的闲暇时间，通过线上分享、专栏解读、知识库构建、报告发布、评测及项目咨询等形式与全球 AI 社区共享自己的研究思路、工程经验及行业洞察等专业知识，并从中获得了自身的能力成长、经验积累及职业发展。
来源：oschina
链接：https://my.oschina.net/u/4324735/blog/4541006