Full Stack Deep Learning追劇筆記大全

作者

字節，觀遠數據聯合創始人，知乎主頁：https://www.zhihu.com/people/zijie0

文章來源：https://zhuanlan.zhihu.com/p/218468169

正文

專欄的上一篇文章：字節：走馬觀花AutoML https://zhuanlan.zhihu.com/p/212512984 寫了兩萬多字有點累，今天來發個輕鬆點的內容。

最近看了這個非常不錯的來自Berkeley的課程Full Stack Deep Learning https://fall2019.fullstackdeeplearning.com/，介紹了實際深度學習項目落地過程中的各個方面，包括項目設定，團隊組織，框架工具，數據管理，開發調優實踐，測試與生產上線等。這方面其它的經典包括Google的兩篇paper：《Hidden Technical Debt in Machine Learning Systems》和《The ML Test Score》，Rules of Machine Learning，Andrew Ng的Machine Learning Yearning，Martin Fowler的CD4ML，以及《Hands-On Machine Learning with Scikit-Learn, Keras, and TensorFlow》，《Building Machine Learning Powered Applications》，《Building Machine Learning Pipelines》等優秀書籍。

下面是這個課程的一些簡單筆記。

Setting up Machine Learning ProjectsOverview

Pieter Abbeel說，深度學習更像是一門藝術，而不是科學。雖然目前深度學習很多方面缺乏堅實的理論支撐，但並不妨礙在各個業務領域深度學習的應用蓬勃發展。所以在探究深度學習理論原理的同時，我們同樣可以在工程化的方向探索算法應用如何借鑑軟體工程的思想，使得其應用落地有跡可循，逐漸形成一系列的規範和最佳實踐。

算法項目很多還是沒有脫離研究性質，有數據表明，85%的AI項目會失敗。有各種可能原因：

技術可行性：基於數據統計學習構建的模型，在實際使用中有很多限制。

項目範圍：對於AI技術有過高的期望，容易導致項目需求設定方面失去控制，最終難以達成。

目標定義：對於是否成功交付的定義不明確，或者定義的目標與實際業務沒有很好的掛鈎。

從實驗室到生產環境：機器學習建模過程偏研究性質，沒有為實際業務落地做足夠的準備。

組織變革：在技術和產品層面外，對於流程，組織都有一定要求，執行推進難度較大。

Lifecycle

整個機器學習的項目基本流程大家應該都很熟悉，值得注意的是這個流程並不是線性關係，會反覆迭代跳轉。所以遇到問題時不要把自己的思維局限在當前這個點上，要把目光放到整個項目流程上來尋找機會點。

計劃立項：明確需求和目標，項目資源的準備，項目排期等

數據收集：數據系統和流程的梳理，訓練數據的收集，數據質量監控

建模與調優：構建baseline模型，嘗試使用SoTA模型，debug模型并迭代優化

測試與部署：內部/小範圍試點，添加各類測試，監控，部署上線，應用推廣

實驗室pilot時發現模型效果不達標，需要回到訓練調優階段

訓練數據與實際上線數據的不一致，或情況更複雜，需要回到數據收集階段進一步優化

優化目標與最終業務價值有出入，或者現實情況下的結果沒有達到既定目標，需要重新評估項目

另外還有跨項目的基礎架構，包括團隊和組織，支持框架和工具（後續會介紹）。

Prioritizing

考慮項目影響力和可行性兩個維度。

項目影響力方面，參考《AI極簡經濟學》及Karpathy的一些觀點：

可行性：

問題的難度，是否有成熟的技術和方案，對算力需求等。可以從輸出複雜度，可靠性需求和泛化需求等方面來評估。

準確率的需求，模型給出錯誤預測的代價有多高，預測準確率對系統可用性影響有多大。準確率越高，需要投入的調優精力會越大，例如對rare case數據的需求。

數據的可用性，獲取數據的難度，數據量的需求，數據標籤是否容易獲得。一般也是可行性方面最大的障礙。

Archetypes

在公司的各種業務場景中，如何找到適合使用機器學習來提效的機會點並構建原型嘗試呢？有如下幾種模式可以參考：

已有流程的提升項目，需要提升impact，比如思考整個流程的優化能否提升數據流的效率，不斷在這個任務上提升效果。而帶來的更多數據，有機會給下遊業務的優化提升構建更好的基礎。

人工流程的增強輔助，可以通過更好的產品設計以提升整體的可行性，儘早發布good enough的版本，獲取用戶反饋。比如友好的交互方式，讓用戶自己決定是否採納，對於模型的精度需求會有所降低。

人工流程的自動化需要提升可行性，一方面是引入human-in-the-loop的思想，另一方面，控制項目scope適用範圍等。自動駕駛方面有很多這類例子，例如需要人工關注的自動駕駛，或者在特定環境中達到無需人類幹預的狀態。

Metrics

對於算法來說，有一個唯一的可量化的優化指標是非常重要的。但現實業務場景中的需求往往有多個優化目標，需要一些方法來綜合這些指標由模型來進行優化。

需要不時的評估你的metrics，達成情況，與實際業務的聯繫程度等，並根據實際情況來做出調整。

Baselines

模型基線的選擇很重要，可以幫助評估項目可行性和目標設置。一般有兩種構建baseline的方式：

Infrastructure and ToolingOverview

算法應用的理想狀態是，提供更多數據，然後系統自動訓練提升模型效果。但實際上需要引入的系統組件和工具非常多，需要把各個環節的infra基礎打好，後續才有可能實現更高效率的一體化自動化系統。

Software Engineering

語言選擇，基本沒有異議，Python。

IDE支持，VS Code和PyCharm都不錯，個人更喜歡後者。兩者都支持遠程執行和debug，很實用的功能。

Linters and Type Hints，Python還是挺需要各類代碼檢查和類型提示的支持的，可以預防很多問題，提升開發效率。

Jupyter Notebook，比較適合探索開發。Netflix把整個數據科學流程構建在notebook之上，做了很複雜的二次開發，作者覺得不值得。我個人一般也是notebook的draft後續會在IDE中重新組織編寫。Notebook原生的一些缺點有，難以版本管理，缺乏IDE支持，難以測試，執行順序混亂，長時間運行任務支持差等。

Streamlit，一個快速構建data app的工具，個人沒有用過。

Computing and GPUs

深度學習領域有很多進展都得益於強大的計算能力，當然除了「暴力美學」，如何利用少量資源來達到同樣的效果也是非常值得投入研究的。

GPU方面基本上也是沒有懸念，選NVIDIA。具體購買建議方面，V100是目前server端最強大的選擇。Consumer card其實性價比很高，如1080Ti, 2080Ti等。Kepler，Maxwell架構太老了，不建議選購。

雲服務方面建議選購AWS或GCP，作者還黑了下Azure……另外Paperspace和Lambda Labs等也可以考慮。如果架構設計上允許，spot instance會便宜很多。

目前最划算的還是自己買GPU機器。從成本分析來看，5-10周的使用量以上，就是自建的成本更低了。雲服務的優勢主要在可擴展性，運維成本更低等。

Resource Management

需求：多個用戶，使用多臺機器，來運行各自的workload。

最簡單的解決方案，使用各類電子表格來登記管理。

用軟體管理的方式，如SLURM Workload Mananger。

現在比較流行的方案，用Docker + Kubernetes來管理環境和集群資源。以及在此基礎上提供更完善功能的Kubeflow，Polyaxon等。

Frameworks and Distributed Training

除非有特殊的理由，否則建議使用TensorFlow或PyTorch。這兩者的很多功能特性也在逐漸趨於一致，例如TF 2.0裡把eager execution設置為默認模式，使其更易於交互式開發。而PyTorch中也利用TorchScript增加對生產環境部署的支持度。另外fast.ai庫也非常值得一試。目前研究領域PyTorch更火，工業界TensorFlow/Keras應用更多一些。

數據並行化是目前實踐中更常用的做法。模型並行更加複雜，只有單模型無法在單卡上保存時才會考慮。儘可能利用更多RAM的GPU來避免這種情況。

分布式訓練可以考慮的一些庫：Ray，Horovod等。

Experiment Management

知乎上Deep Learning效率神器問題下，很多回答都提到實驗管理方面的工具。

這裡提到的一些工具：Spreadsheet，TensorBoard，Losswise，Comet.ml，Weights and Biases，MLflow。

Hyperparameter Tuning

前面AutoML的文章裡有提到很多具體的原理和技術。

這裡提到的一些工具：Hyperopt(Hyperas)，SigOpt，Ray Tune，Weights and Biases。

All-in-one Solutions

組合了上面提到的一系列的功能點的全功能軟體平臺，提供包括模型開發，分布式訓練，實驗記錄，模型版本，模型發布，模型監控等功能的一站式服務。

舉例：FBLearner Flow，Michelangelo，TFX，Amazon SageMaker，Neptune，FloydHub，Paperspace，Determined AI，Domino Data Lab（進入了Gartner DSML魔力四象限）。

Data ManagementOverview

數據太重要了，為什麼叫Data Scientist而不是Model Scientist是有原因的 ：）

業界對這方面的重視也在快速提升，因為實際工作中對於數據方面能做的空間和回報都非常大。研究領域受到benchmark等因素影響，往往只能使用相對固定的數據集來做模型方面的工作。

Sources

大多數的深度學習應用都需要大量的訓練數據。

可以使用公開數據集作為開始，然後通過產品構建起data flywheel。

半監督學習也是近期熱門方向，可以減輕給數據打標的人工開銷。

數據增強在CV領域是一個非常普遍應用的技術，其它領域的應用會困難些。對於表格數據，可以隨機刪除一些cell來形成更多的數據。自然語言處理方面也有一些類似嘗試，例如替換近義詞，改變詞語順序等。總體思路還是把一些領域知識通過變換，或者噪音的方式進行添加，使得模型更加穩定和通用。

生成數據，CV領域的應用比較多一些，比如可以在仿真場景中訓練自動駕駛系統。

Labeling

數據打標方面，需要使用打標工具，制定相應規則來讓打標人員來正確高效的進行數據標記。相比使用公司內部人力，crowdsourcing和外包是更常見的方式。其中比較關鍵的是需要先自己做一些打標工作，了解其中的複雜度，設計好規範和質量檢查點。

打標服務公司：FigureEight，Scale.ai

打標軟體舉例：Hive，Prodigy等。除了用戶交互的便利性，還可以使用active learning等技術來提高效率。

Storage

數據存儲的各種形式：文件系統，對象存儲，資料庫，data lake等。

Binary data一般會以object store形式存儲。

系統元數據以資料庫形式存儲較為常見。

非結構化的數據存儲在data lake中，到使用時再進行後續處理。

訓練時的數據讀寫一般會在文件系統中進行，提供了較為完整的POSIX API。

對於結構化數據的處理，SQL是最合適的方式。

Feature store在數據存儲上一層進行了一些封裝，在原始數據基礎上做了transformation，後續在使用時可以直接進行調用。Uber，airbnb等實踐了這個方案，而netflix反對這個想法，業界看起來還沒有較為統一的認知。

Versioning

Level 0: 無版本管理。

Level 1: 用snapshot方式在訓練時產生相應的版本。

Level 2: 使用assets和代碼混合的方式進行版本管理。大致的做法就是把數據相關的元信息也在代碼裡進行管理。

Level 3: 使用專門的管理工具來做數據版本管理，例如DVC，Pachyderm，Quill，Dolt等。

另外Delta Lake也是一個值得關注的框架。

Processing

工作流的編排和運行。最簡單的做法，使用makefile，但是有很多使用限制。在這方面使用最廣泛的框架是Apache Airflow。其它有很多專注在數據科學領域的框架，例如MLflow，metaflow等，為算法實驗，問題排查等提供了很多功能支持。

不要過度工程，使用簡單的技術手段滿足目前的需求，當碰到無法解決的複雜情況時再考慮引入其它工具框架。一旦引入框架，出現問題時不止要排查項目代碼，還需要排查工具框架層面的問題 :)

Machine Learning TeamsOverview

管理技術團隊有很多挑戰，對於機器學習組織，在技術團隊困難的基礎上還引入了更多的挑戰：

Roles

ML產品經理：制定任務優先級，推進項目進展

DevOps工程師：部署和運維線上系統

數據工程師：構建data pipeline，數據存儲基礎，相關監控等

機器學習工程師：訓練和部署模型

機器學習研究員：更面向未來的算法技術調研和前沿探索

數據科學家：一個非常廣義的職位，總體來說會更偏向算法，數據分析與業務連接部分

X軸是機器學習技術的需求，Y軸是計算機工程技術的需求，圓圈的大小表示溝通/技術協作能力的需求。

這個session的QA部分也有很多信息量。比如構建機器學習組織的時候，優先從哪種類型的角色開始。各個角色的職業發展等。

Team Structure

Ad-Hoc ML：沒有專職的ML工程師，以ad-hoc的方式來做一些基礎的機器學習應用，很多中小型公司的做法。主要的問題是ML項目缺乏支持，也比較難招聘和留住相關人才。

ML R&D：在研發部門中融入機器學習相關職能崗位，是更大一些的能源，製造，電信行業公司的做法。主要問題，數據難以獲取，機器學習項目也很少實際上線產生價值，因此後續投入也比較少。

Embeded ML：在業務/產品部門中融入機器學習職能，大多數的軟體科技類公司，金融服務公司的做法。主要問題是比較難吸引和培養出top級別的人才。另外軟體工程的管理和發布節奏與機器學習項目的管理髮布節奏容易有衝突。而且長周期的項目難以發展。

Independent ML：有獨立的ML部門，直接匯報給CEO/CTO層級，有一些大型的金融服務公司會使用這種做法。這種做法的問題是與業務部門的交流合作會有一些gap，需要業務方認可和積極的合作，學習模型的使用方式，給出快速的反饋等。

ML-First：ML部門會專注於有挑戰的，長周期投入的項目，而且在各個業務線也會有ML專家尋求算法快速落地，產生業務價值的機會，一般超大型的科技公司或者專注於機器學習領域的創業公司會採用這種方式。主要挑戰是這個形式非常難達到，比如招聘足夠的人才，公司文化的轉變等。

Design choices:

QA裡有個彩蛋，想做ML方面的話，讀數學博士還是計算機科學博士更好？講師毫不猶豫的回答：計算機科學。

Managing Projects

機器學習項目的管理太難了。

上圖是一個kaggle比賽的例子，整個比賽中的效果提升大部分是在第一周達到的。

一些解決方案。使用概率性的方式來管理項目，令人震驚！

需要在項目過程中嘗試多組方案，每組方案預估成功概率，根據進展及時調整。

評估組員產出時，根據他們的輸入，例如做了哪些嘗試，得出什麼結論。而不是直接用最終結果來評估。

先快速構建起end-to-end的pipeline，再不斷迭代。Rules of ML中也強調了這點。

對於管理層，需要對他們進行機器學習項目不確定性的教育。

Hiring

作為manager，需要明確招聘目標的畫像，必需的技能點等。建議招聘對機器學習有興趣的軟體工程師。

裡面還提到了不少招聘，建聯渠道，如何吸引ML人才等，例如：

明確公司的願景和產品的潛在影響力

在工具鏈和基礎設施方面加大投入提升工作便捷度

構建學習型組織氛圍

利用高人才密度來吸引更多的人才

另外對於招聘面試流程，以及求職方面的指導，session中也給出了一些建議，可供參考。

Training and DebuggingOverview

模型開發優化的過程中，80-90%的時間會花在debugging和tuning上，只有10-20%的時間在做implementation。

模型結果的復現很有難度，包括確保實現沒有bug，超參的選擇，數據的構建，模型是否適合對應的數據集等挑戰。

總體策略：

Start Simple

選擇從簡單的網絡結構開始

選擇常見的默認超參

優化器：adam with lr 3e-4

激活函數：ReLU for MLP and conv nets，tanh for LSTM

參數初始化：He init for ReLU，Glorot for tanh

先不添加regularization和normalization

添加input normalization

簡化問題

用少量數據/仿真數據來實驗

使用固定數量的類別，input size等設置

Debug

5個最常見的bug：

實現模型的3個建議：

開發中的第一步，讓模型跑起來：

Shape mismatch或casting之類的問題，可以用ipdb, tfdb等方法來做斷點調試

Out-of-memory問題，可以逐個排除消耗內存較大的操作來定位

其它問題，Google/StackOverflow驅動開發……

第二步，在一個batch上過擬合：

Error不降反升，可能有地方符號用反了

Error爆炸，一般是數值處理問題，也可能是learning rate太大

Error震蕩，先降低learning rate，再看看是不是label跟數據沒對上，或者錯誤的augmentation

Error保持在一個中間狀態不下降，可以嘗試提高learning rate，移除regularization。後續還可以檢查一下loss function的實現，以及數據pipeline的正確性

第三步，與已知結果比較：

例如與一個官方模型實現進行比較，把相同的數據集用到你實現的模型上

也可以嘗試與非官方實現比較，不過很多github上的實現都有bug，要注意

或者直接與論文中提到的準確率比較

最後，可以與簡單的baseline比較，包括規則，簡單模型等

Slides中有更多細節，感覺總結的挺好。

Evaluate

使用經典的bias variance decomposition來對模型進行評估。

Improve

解決under-fitting問題

增加模型複雜度

降低regularization

Error analysis

使用更複雜的架構

超參調優

添加特徵

解決over-fitting問題

解決distribution shift問題

Error analysis的時候，需要對各類錯誤的優先級進行評估排序，這部分跟《Machine Learning Yearning》裡內容類似。

最後，可以考慮rebalance數據集。例如validation集上的表現明顯比test集好，可能需要考慮重新選擇一下validation/test集。

QA中提到，調優RL算法的時候，random seed也應該視為超參中的一部分 :)

Tune

不同的參數對模型效果的敏感度不同：

低敏感度：optimizer，batch size，non-linearity

中敏感度：參數初始化，模型深度，layer parameters，regularization

高敏感度：learning rate，learning rate schedule，loss function，layer size

參數優化的方法：手動調參，grid search，random search，coarse-to-fine search，貝葉斯優化等。

Testing and DeploymentProject Structure

給出了項目結構中不同類型的測試，與傳統的測試金字塔裡的分類很不一樣。

ML Test Score

我的專欄文章 https://zhuanlan.zhihu.com/p/55032862中之前也寫過這兩篇經典的論文，最近幾年好像也沒有見到新的相關文章出來。

CI/Testing

單元測試，集成測試，持續集成的一些基本概念，與軟體工程中基本一致。CD4ML https://martinfowler.com/articles/cd4ml.html中有更詳細的闡述。

一些工具介紹：CircleCI，Travis CI，Jenkins，Buildkite等。

Docker

簡單介紹了Docker的使用場景，原理，使用方式等。後面簡單提了下容器編排相關的工具，如kubernetes等。

有經驗的同學可以直接跳過。

Web Deployment

一般模型預測會以RESTful API的方式對外進行服務。幾種部署方式：

在虛擬機上部署，通過添加intance來scale

在container上部署，通過k8s之類的編排軟體來scale

通過serverless的方式部署（AWS Lambda，Google Cloud Functions，Azure Functions），自動擴展，自帶負載均衡，監控等服務

通過模型服務來部署（TF Serving，Model Server for MXNet，Clipper，Seldon或其它SaaS服務）

如果使用CPU inference，一般會使用Docker部署或者serverless形式。

如果使用GPU inference，TF Serving，Ray Serve之類的模型服務中提供adaptive batching等功能會很有用。

Monitoring

這一節同樣參考《The ML Test Score》。

Serving systems, training pipelines, and input data，這幾塊都需要監控。出問題時發出alarm，並記錄下來方便後續調查調優。

所有可以被日誌記錄的內容，都可以被監控，所以當你設計info/warning/error log時，同時考慮下是否要觸發監控告警機制。

數據分布監控方面的現成服務或方案比較少。

除了技術層面的監控，對於業務，終端用戶的監控同樣非常重要。

Closing the Flywheel，一個需要思考的點。

Hardware/Mobile

在mobile上部署模型會遇到計算資源受限的問題，一般解決方法：減小模型大小（類似MobileNet），quantizing weights，知識蒸餾（例如DistillBERT）等。

一些工具框架介紹：TensorFlow Lite，PyTorch Mobile，CoreML，MLKit，FritzAI等。ONNX可以作為中間層，再部署到各種硬體平臺上。對於嵌入式系統，最好的解決方案是NVIDIA for Embeded。

Research Areas

Pieter Abbeel介紹了few-shot learning，RL，imitation learning，domain randomization，NAS，unsupervised learning等幾個方面的話題，主要還是集中在他比較擅長的強化學習和機器人應用領域。不過沒看出跟課程主題之間的特別關係，可能主要是擴展一下大家的視野，尤其是有些問題通過了解學術領域的解決思路，SoTA水平等，對於解決工業界的問題也有一定借鑑意義。另一方面是建立起兩者之間的連接，讓工業界的同學也大致了解如何follow學術界的一些研究思路和最新進展，給出了一些參考建議。

Labs

一共有8個lab，感興趣的同學可以跟著一起深入了解實踐一下。

Guest Lectures

邀請了十位業界大咖，例如阿里的 

@賈揚清  

https://www.zhihu.com/people/jiayangqing

 大神，fast.ai的Jeremy Howard，Tesla的Andrej Karpathy等來給大家做演講。每個session在40-60分鐘，大致感受如下：

Xavier Amatriain (Curai) 之前在Netflix，Quora工作過，分享的內容還是相當有趣且實用的，大多數還給了相關論文做進一步參考，推薦一看。印象比較深的一點是舉了一個學術界的數據集從提出到應用到工業界，平均要3年，而算法模型從提出到應用到工業界，平均要18年。

Chip Huyen (Snorkel) 主要介紹了算法面試相關的內容，挺實在，值得一看。講座中舉了個比較有意思的數據，統計公司on-site和offer的比例，以及candidate最後接offer的概率。

Lukas Biewald (Weights & Biases) 作者的背景是之前FigureEight的創始人，講座中有不少內容強調了數據的重要性，以及算法與人工結合的實踐。很多內容在Xavier的session裡也有提到。

Jeremy Howard (fast.ai · Making neural nets uncool again) 前面重點介紹了augmented ML的概念，結合人類和模型的長處來更好的構建模型。後面的部分主要介紹了fast.ai庫中提供的各種高效的訓練神經網絡的手段，包括test-time augmentation，progressive resizing，1cycle，AdamW，gradient clipping等。

Richard Socher (Salesforce) 主要介紹了decaNLP，用QA形式來統一多種NLP任務的benchmark框架，另外也介紹了他們的MQAN網絡結構。比較適合對NLP感興趣的同學觀看學習。

Yangqing Jia (Alibaba) 介紹了深度學習框架的發展歷史，框架特性，選擇的一些思考框架。後續擴展到應用層，library層，runtime, compilers, optimizers層等進行了整體的介紹。最後總結了一些行業趨勢和思考，例如實驗管理方面的投入，將更多的計算機科學方面的思想應用到機器學習領域等。

Andrej Karpathy (Tesla) 介紹了他的software 2.0的概念，利用數據，指定目標後，通過訓練來生成可以執行的程序。前半部分講了他在Tesla碰到的各種數據部分的挑戰，後面一部分對software 2.0的IDE，github等做了一些暢想。

Jai Ranganathan (KeepTruckin) 介紹了他在Uber時負責的COTA平臺中使用機器學習技術的end-to-end案例，包括探索，問題定義，到後面的模型開發，上線，監控等環節。跟課程內容還挺貼近的。

Where to go next

https://fall2019.fullstackdeeplearning.com/course-content/where-to-go-next 提供了非常多的學習資源。學完一個，todo list上 又加了10個有沒有。

文末附：添加微信jjnuxjp5x，拉您進1)ml,dl,rl+組合優化群以及2）強化學習群！