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，幾次轉行，本科國際貿易，研究生轉向統計，畢業後留在比利時，從事機械研發工作，主要負責影像處理，實現計算機視覺演算法的落地。欣賞一切簡單、優雅但有效地演算法，試圖在深度學習的簇擁者和懷疑者之間找到一個平衡。
關於機器之心全球分析師網路 Synced Global Analyst Network
機器之心全球分析師網路是由機器之心發起的全球性人工智慧專業知識共享網路。在過去的四年裡，已有數百名來自全球各地的 AI 領域專業學生學者、工程專家、業務專家，利用自己的學業工作之餘的閒暇時間，透過線上分享、專欄解讀、知識庫構建、報告發布、評測及專案諮詢等形式與全球 AI 社群共享自己的研究思路、工程經驗及行業洞察等專業知識，並從中獲得了自身的能力成長、經驗積累及職業發展。