【論文】ML的系統開發流程詳解，NASA、微軟、MIT、牛津合著大作
論文連結:https://arxiv.org/abs/2101.03989
上個月，NASA、微軟、MIT、牛津等多機構作者合著了一篇「介紹完整的ML系統從研究到上線的流程」的論文，引起了廣泛的討論，今天我就要來導讀一下這篇，並且加上我自己的解讀。
我們在現代的ML產品開發時，因為現有的ML engineering的觀念仍處與初期不成熟的階段，所以其實常常邊做research邊開發產品，而這容易導致大量的「技術債」，後期才發現ML的系統上線表現不如預期、Database沒有辦法隨著Data scale、Model沒有辦法應對新的Data…等問題，而這些ML的技術債在目前是很少被討論的，NASA等機構的研究員就試圖提出一個完整的開發框架，名為Machine Learning Technology Readiness Levels，簡稱MLTRL，來把他們內部成功的流程介紹給大家。
Machine Learning Technology Readiness Levels (MLTRL) framework
MLTRL主打的就是Readiness，這裡的Readiness的意思不僅僅指我們的model accuracy夠高能夠被使用，包含著我們的系統在開發過程中已經考量了後續scale up的可能性，也包含著我們初期只有idea的時候已經考量了後續我們data收集的方法，所以這裡的readiness其實本質就是「在每一步做好足夠準備，以應付後續的需求」，而這種本質其實也就是我們原本在Software Engineer上會想要「沒有技術債」這件事，這件事的好壞我留在最後再討論，而這邊MLTRL就是提出了一個非常完備的框架，讓我們在每一步都明確化現階段的主要目標。
MLTRL把我們ML從最初發想到最後上線分成了10個level，從0到9。
Overview如下圖
下面我開始敘述每一個level的目標以及應該要做的事情。
Level 0—First Principles
這邊重點就是找到可行的研究方向，可能是處理新的data、面對新的問題、釐清新的問題、從不同角度重新切入一個問題…等，所以其實就像是一般的research的初期運行方式，最常做的就是Literature review，而我們的目標就是要產出「幾個明確的idea，並且最好有足夠的理論基礎」，並且如果我們的idea是依賴於data的方法時（絕大部分ML方法都是），我們也必須要順便考量「這個類型的data的獲取方式」，並且基礎的原則、假設、研究方向、研究方法跟文獻探討必須在這步就說明清楚，而因為這步其實就是為後期research做準備，所以這步的守門人通常就是一個資深研究員，例如phd學生。
Level 1 — Goal Oriented Research
在從idea到後期實際運用，我們必須要做非常大量的實驗來了解我們的演算法、模型的各種性質，這裡的性質除了performance以外，可能也包含著基礎的error analysis（了解我們model做錯甚麼?），model的效率（latency、though put）、甚至是我之前提過最新的behavior testing。
越多的實驗、越清晰對我們model的認識，讓我們更了解我們的模型可能有甚麼優勢、功能？在甚麼情況可用？為甚麼可用？等問題。
在這個階段的code重點放在快速實驗，只要codebase是maintainable跟organize，沒有甚麼太多的要求。
這邊特別強調一下，在ML的早期實驗階段，針對code、model、dataset的version control非常重要，因為這會直接影響到你的reproducibility，而我們實驗最重視的就是reproducibility，如果有version control也可以更明確我們實驗了甚麼、效果如何、應該怎麼改進。
Level 2 — Proof of Principle (PoP) Development
大量的R&D (Research and Design)就會在這個階段開始進行，我們在level 1已經了解了我們目前的model、algorithm的功能，而這些功能都是依附著我們level 0想出的idea，也就是所謂的principle，這個階段就是要讓這些功能在比較靠近真實情況的環境去進行測試，來驗證我們的principle，但是因為還在初期，所以我們一般是使用simulation、替代性的data，來進行測試，我們必須讓這些simulation、替代性data盡量真實情況，這個階段很重要的是建立出完整、正規的需求列表，包含著verification跟validation (V&V)。
verification: Are we building the product right?
validation: Are we building the right product?這個驗證階段非常重要，我們可以依據我們的結果決定是否往level 3繼續進行，還是回頭做更多的research，所以對產品有足夠明確的「要求」，並且讓這些要求在具體的實驗上驗證，就是這步的關鍵。
Level 3 — System Development
這步是一個check point，因為我們已經PoP了，所以我們在這裡要把我們前面亂七八糟的code，變成prototype level的code，這邊就是照software engineer那套，以interoperability, reliability, maintainability, extensibility, scalability這幾項為要求，開發出對應的unit test、integration test、coding style之類的，這邊不贅述。
因為要變成prototype level，所以這邊的開發人員從研究員慢慢轉往Applied AI或是ML engineer等職位，同時如果考慮到database scalability之類的，data engineer也會在這步進來。
同時在這個階段最好也可以定義出完整的SLA、SLO等文件。可參考下面兩篇文章。
Level 4 — Proof of Concept (PoC) Development
PoC的重點就是真正在「真實環境、data」下驗證我們的model，這裡的驗證也不僅僅指accuracy，而是各種在上線時會被考慮的指標，像是model latency、computational costs，或是更靠近end user的指標，像是推薦系統給end user top-N推薦的false positive。
為了定義出好的指標，這一步通常PM或是其他stakeholder就會進場了，而因為我們在真實環境中做測試，所以之前的模擬、替代性資料與真實環境的差異就會顯現出來，而這個差異就是我們必須要小心的事情，這代表了我們系統的robustness。
同時我們也會驗證我們的data，包含真實data的品質、有效性、獲取難度…等，security跟privacy也在這時候必須被驗證，基本上這一步就是要驗證到所有model上線後重要的指標。
作者在這段特別提，AI ethic也必須在這個階段被考量進來，雖然很多大公司目前沒有這樣做，但是PoC後面就是不斷的把model完善到上線，所以這邊必須把道德上的問題也考慮進來。
在這邊我們再度有一個決策的階段，是否要往Level 5進行，這其實就依賴於我們前面指標的設定是否完整（PM的技能），以及我們的測試是否達到我們的指標，如果未完成的話可以考慮停留在level 4等待更好的機會、更多的data、更完善的演算法、更新的model。
Level 5 — Machine Learning “Capability”
這一步我們前面的演算法已經被驗證完成，我們有一個「好的功能」，現在要把這個功能包到更大的應用中，所以我們考量的問題從model的層級變成應用的層級。
而為了讓應用的層級能夠更往上推動，我們必須擬出「新的需求列表」，包含新的V&V，而這個階段的V&V就是非常產品導向的V&V，不只我們的演算法要夠好，產品的其他面向也必須要考慮進來。
這一步要往下走通常非常困難，因為我們考量的不再只是model本身，必須從產品面、應用面完整考量我們的應用，而PM也必須基於這些考量，去規劃出完整的roadmap來推進level 6及以後。
Level 6 —Application Development
這步又是一個checkpoint，因為我們在level 5已經確定了產品的導向、相對應的需求、V&V等等，同時我們在level 4也確定了核心的functionality，所以我們在這一步就是為後續做準備，把code變成production level的code，因此並須有完整的spec、全面的testing、跟well-defined API…等
同時為了實際上線，所有潛在的系統上線的問題也必須被考量進來，包含我們的系統是要上cloud、還是要on-primise還是要hybrid，而每一種模式又會相對應影響到我們的latency、privacy issue…等等
Level 7 — Integrations
如果我們前一步該考量的問題都考量清楚了，接下來就可以慢慢整合到我們的產品系統上，在這裡作者推薦要開始平衡infrastructure engineer跟AI engineer了。
而integration大家都知道目前比較熱門的方法就是所謂的Continuous Integration （CI），而為了達到CI，我們必須定義出明確的testing method，這邊可能可以使用過去的方法，但是更重要的是去想我們的golden dataset是甚麼，甚麼dataset的performance一過關就代表我們新的應用可以被整合到現有產品系統上，同時除了golden dataset以外其他常見CI會考量的testing也要使用進來。
除了一個golden dataset以外，也必須test在多個不同的data slices，或是關鍵的情形，這可能是某些少數但重要的顧客群體的data，也有可能是某些AI ethics告訴我們必須要在意的data。
並且作者推薦metamorphic testing，也就是去檢查多個input所對應到的output之間的關係，有點類似上面講的behavior testing。
這些ML相關的QA（Quality Assurance）是目前比較少被討論，但是非常重要的一件事。
Level 8 — Flight-ready
這一步就是連帶把Continuous Deployment（CD）也建立好，並且也可以使用一些在deployment階段的testing，像是A/B test，用來確認新的模型是某有全面deploy的必要。
並且因為真實系統deployment時，會遇到的情況一定也跟我們前面的驗證不同，不論我們前面多努力收集到了真實資料，新的用戶、舊用戶的新的行為，都會讓我們的模型遇到不一樣的情況，所以這裡作者推薦先讓模型運行於shadow mode（影子模式），也就是說讓模型實際去run，但是模型的output不會影響到真實用戶。Shadow mode能讓我們新的應用、model在真正的環境中做最真實的壓力測試。
而壓力測試的結果就會決定我們是否要實際deploy。
Level 9 — Deployment
當我們真實上線後最重要的就是「維護」。
維護這裡包含了不斷monitor data quality、確認concept drift、data drift，這幾步都很重要，實際怎麼做可以參考一般我們去確認training testing distribution drift跟data quality的方法，然後改成線上版，相關方法我之後會用kaggle競賽例子來說明。
只有隨時了解到training-serving skew，或是data drift，我們才會知道我們是否要retrain model，甚至如果data quality有顯著改變，我們可能連Feature engineer、data cleaning等method都要更改，而一做更改我們就必須回頭到level 7甚至更之前去做概念驗證跟testing。
同時如果可行的話continuous evaluation也需要建立起來，隨時跟進我們的系統在最新的資料上的表現，而這代表我們必須最少要有log system在記錄我們model的output。
上面就是我們的10個steps的MLTRL，我把我個人認為每個步驟的重點記錄下來，有些資訊有遺漏，還是推薦大家去看原始論文。
大家可以再複習一下完整的架構。
可以看到MLTRL其實是一個不斷重複研究、驗證、提升code品質的過程。
同時作者也強調了這個框架的彈性，我們可以多次從高的level回朔至低的level，來設計、完善、驗證新的功能或是舊有功能的新指標，如下圖。
而大部分公司出現的情況也很簡單，就是跳過了level 5跟level 6導致後期系統不好maintain、scale，而變成當我們真的上線時，需要解決的一大堆技術債，如下圖。
除此之外作者在論文後面以他們自己的幾個project來說明這個框架的優點，這邊我推薦大家直接去看原文，能夠更清晰作者的想法，就不贅述。
後面我來針對MLTRL的評價。
MLTRL是開發標準而不是產品標準
大家可以注意要MLTRL的流程非常的「完整」，而這個完整也就是為了解決前面提到的「技術債」，但是實際上這種完整的流程往往會拖延整個產品的開發進度，而在現代lean startup的風氣，我們需要的是快速試錯、快速迭代，也就是所謂敏捷的開發流程，而MLTRL會讓我們敏捷不起來，而在當代大家對AI應用的想像還很有限的時候，敏捷、高頻率的市場驗證反而是AI產品的重點，所以我個人並沒有非常支持MLTRL。
MLTRL的起點是AI Research，這種觀點早已過時
MLTRL的前3步都是直接跟Research相關，包含著要大量做literature review跟大量跑實驗，但是這兩件事情都只會讓我們「越來越了解技術」。
但是技術的成長不見得代表我們最終產品會是好的產品，在現代我們很重視User Experience，會大量去做UX research並依照對用戶、客戶的了解去設計、開發對應產品，而MLTRL並沒有把這些可能考慮進來，其中PM甚至到第5步才進場，這樣是否可以開發出「好的產品」，實在讓人疑惑。
而原本Design Thinking步驟或是更市場導向的市場分析、競品分析等方法要如何介入MLTRL其實也是一個大大問號，或是說我們怎麼確定我們research有用的方法符合我們公司價值主張、核心方向…等也相當困難，我們可以說level 5以前如果要變得更市場導向，大概率要整個重新規劃，而level 5以後也是比較偏向瀑布型的開發方法，在新產品中也不見得是有優勢。
但是，MLTRL提供了AI技術的思維地圖
今天我認為反而是要把MLTRL當成一種思維來看，借助MLTRL提供給我們的AI研究到上線的框架，我們能夠在我們自己的設計流程中不斷思考，我們未來可能會遇到甚麼問題，現階段哪些問題是被忽略的。
而這些對現況、未來更清晰的認識，絕對不會對我們有害，只會有益，這也會讓PM在規劃roadmap時更清楚哪個階段可能會出現怎樣的技術債，而哪些技術債又必須被償還哪些其實不必要，這些資訊都是依賴於我們後續的開發需求。
所以總結來說我認為MLTRL其實是一個給工程師、PM的針對AI技術研究到上線的思維地圖，而這個地圖讓我們能夠更少走彎路，並更好做出決策。
如果有理解錯誤或是對MLTRL有其他想法歡迎找我討論~~
如果喜歡這篇文章可以幫我多拍手幾次XD，或是對於哪個類型文章有興趣都可以在留言區跟我講~ 後續會以中難度的ML/DS/AI知識為主，以及AI/HCI研究相關知識。