選自maiot blog
作者：Benedikt Koller
呆板之心編譯
編輯：Panda、張倩
在呆板進修社區，越來越多的人開始接頭研究的可復現性，但這些接頭大部門范圍于學術情況。如何確保出產情況的ML可復現？克日，呆板進修開拓處事提供商 maiot.io 的 CTO Benedikt Koller 宣布一篇博客文章，先容了他基于自身履歷總結的開拓可復現出產級呆板進修所要留意的 12 個要素。
已往二十年來，我們對軟件開拓的領略有了大幅晉升。個中一大部門原因是 DevOps 觀念的呈現及其在軟件開刊行業的遍及應用。
領先的軟件公司都遵循著同樣的模式：首先是在軟件開拓進程中快速迭代，然后舉辦一連集成、一連交付、一連陳設。每個特性都要顛末測試，看其提供代價的本領如何，并且軟件始終要處于停當的狀態，而且通過自動化要領舉辦陳設。
呆板進修這個規模雖差異于傳統的軟件開拓，但我們也能從軟件開刊行業羅致許多實用的履歷教導。已往幾年里，我們一直在開拓出產型呆板進修項目。我們的方針并不可是觀念驗證，而是與軟件開拓一樣的可復現本領（reproducibility）。因此，我們構建了一套流程協調器、強大的自動化本領并成立了一套用于實現該方針的事情流程。
為什么不直接利用 Jupyter Notebook？從新開始構建一組包括所有處理懲罰步調的條記需要多長時間？為團隊納入新成員的難易水平如何？你此刻可以復現兩個月前的功效嗎？能以多快的速度復現？你能將本日的功效和汗青功效舉辦比擬嗎？你能在練習進程中存眷到數據的出處嗎？假如你的模子過期了又會產生什么？
我們碰著過所有這些問題。此刻，我們將這些履歷舉辦了歸納總結，獲得了樂成構建出產型呆板進修的 12 個要素（雷同于軟件開拓中的十二要素應用/12 factor app）。
1. 版本節制
對軟件工程師來說，版本節制根基上是理所雖然需要做的，可是這一要領論還尚未被數據科學家遍及接管。讓我引述一下 Gitlab 上一些人的說法：
版本節制可促進整個軟件開拓團隊之間的協調、共享和協作。版本節制軟件讓團隊可以在漫衍式和異步情況中事情、打點代碼和文件的修改和版本以及辦理歸并斗嘴和相關異常。
簡樸來說，版本節制能讓你安詳地打點軟件開拓中會變革的部門。
呆板進修其實是一種非凡的軟件開拓，有著本身特定的要求。首先，呆板進修中會變革的部門不止一種，而是兩種：代碼和數據。其次，模子練習的方法是（快速）迭代，而且代碼中的差別會很大（好比拆分、預處理懲罰、模子）。
只要數據產生變動，就需要生存一個版本，這樣才氣擔保能復現功效以及反復執行嘗試和練習模子。簡樸粗暴的版本節制（硬拷貝）具有很大的改造空間，不外尤其是在團隊共享的環境下，可以或許保持穩定的版本節制是至關重要的。
代碼的版本節制還要越發重要。除了上面引述的內容，預處理懲罰代碼不只在練習階段很重要，并且在處事階段也很重要，需要與模子有保持穩定的相關性。為了在數據科學家的事情流程和投入出產的要求之間成立一種中臺，一種利便的要領是提供無處事器的成果。
總結：你需要對代碼舉辦版本節制，也需要對數據舉辦版本節制。
2. 明晰的特征依賴干系
在抱負世界中，發生你的輸入數據的對象應該老是會發生同樣的數據，至少布局上是這樣。但這個世界并不是完美的，你從上游處事獲取的數據也是由人類構建的，因此大概會產生變革。最終，特征也大概產生改變。最好的環境是你的模子會直接妨礙報錯，但尚有最壞的環境：你的模子暗暗繼承事情，但獲得的功效都是垃圾。
明晰界說的特征依賴干系可以或許盡快展現出失敗案例。假如系統設計得好，還能在處事時舉辦一連練習，然后調解依賴干系并加以適應。
總結：明晰代碼中的特征依賴干系。
3. 描寫性的練習和預處理懲罰
優良的軟件都有優良的描寫和注釋——讓人無需閱讀每一行代碼就能輕松閱讀和領略代碼成果。
盡量呆板進修是一類非凡的軟件開拓，但它并不勉勵實踐者背離已有的代碼書寫準則。在代碼書寫尺度中，最根基的一條是能讓人在短時間內不艱辛地閱讀。
預處理懲罰和模子的代碼都應該遵循 PEP8 類型。代碼中該當利用有意義的工具名并包括有助于領略的注釋。遵循 PEP8 類型可晉升代碼的可讀性，低落巨大度并加速調試速度。SOLID 之類的編程范式提供了顛末深思熟慮的框架，可讓代碼在將來用例中的可維護性、可領略性和機動性都獲得改進。
設置應該與代碼疏散。不要將數據分派比例硬編碼到代碼之中，而是通過設置方法提供，以便在運行時修改。人們在超參數調理方面已經熟知這一點了：利用疏散的設置文件可以顯著加速迭代速度，而且讓代碼庫可以反復利用。
總結：晉升代碼可讀性而且將代碼和設置分隔。
4. 練習功效的可復現性
假如你不能復現練習功效，那么這個功效就是不行信的。盡量這是本文的主題，但在可復現性方面有一些細節需要說明。不只是你本身需要能復現練習功效，你的整個團隊都要能做到這一點。不管是在 PC 照舊在 AWS 虛擬機上，恍惚處理懲罰 Jupyter Notebook 中的練習功效都與可復現性南轅北轍。
通過設定練習的事情流程，整個團隊都可以透明地會見已執行的嘗試和已運行的練習。通過綁定可復用的代碼庫以及疏散的設置文件，每小我私家都可在任何時間樂成從頭練習。
總結：利用管道式事情流程和自動化。
5. 測試
測試的形式有許多。舉兩個例子：
1）單位測試是原子層面上的測試——基于各自的尺度單獨測試每個函數和成果。
2）集成測試則相反，是將代碼庫的所有元素都放到一起舉辦測試，同時還會測試上下游處事的克隆版本或模仿版本。
這兩種范式都適應于呆板進修。預處理懲罰代碼是預先確定的，直到測試階段——這樣的轉換能在差異的輸入下都獲得正確功效嗎？模子是集成測試的一個絕佳案例——在出產情況中提供處事時，你的模子的表示是否與評估時相當？
總結：測試你的代碼，測試你的模子。
6. 偏移與一連練習
在出產場景中，任務產生偏移是公道存在的問題。只要數據存在變革的大概性，你就需要思量偏移的大概性。對付此問題的風險，有兩種可以采納的法子：
1）監控出產系統中的數據。成立自動化陳訴機制，在數據產生變革時通知團隊，這種變革甚至大概高出明晰界說的特征依賴干系。
2）基于新輸入的數據一連練習。精采自動化的管道化流程可以基于新數據反復運行，然后與汗青練習功效舉辦較量，展示機能變革環境以及將練習獲得的模子快速投放到出產中，從而讓模子表示更好。
總結：假如你的數據會產生變革，那就回收一種一連練習的管道化流程。
7. 跟蹤功效
Excel 并非一種跟蹤嘗試功效的好要領。并且還不可是 Excel，任何分手的人工跟蹤要領獲得的信息都是不足權威的，也因此是不行信的。
正確的做法是以一種中心化的數據存儲方法自動記錄練習功效。自動化可以或許擔保靠得住地跟蹤每次練習，從而利便之后較量每次練習的功效。對功效舉辦中心化存儲，能為團隊提供透明，實現一連性闡明。
總結：通過自動化要領跟蹤功效。
8. 嘗試模子與出產模子
我們需要盡力才氣領略數據集。凡是來說，我們會通過嘗試來實現領略， ST貼片鋁電解電容，尤其是當我們存眷的規模具備大量隱含規模常識時。建設一個 Jupyter Notebook，將部門/全部數據導入 Pandas Dataframe，舉辦幾個小時無序研究，練習第一個模子，評估功效——任務完成。但幸運的是，現實并不如此。
在呆板進修的生命周期中，嘗試有本身的目標。這些目標并不是模子，而是領略。基于摸索性 Jupyter Notebook 的模子是為了領略，而不是為出產開拓的制品。領略之后，還需要進一步開拓和適應，才氣開始打造用于出產的練習流程。
不外，所有與規模特定的常識無關的領略都可以自動化。你可以基于你利用的每個數據版本生成統計信息，從而可以跳過那些你在 Jupyter Notebook 中做過的一次性的姑且摸索事情，然后直達第一個管道式流程。你在流程中嘗試舉辦得越早，你就能越早地在中間功效長舉辦協作，也就能更早地實現可投入出產的模子。
總結：條記不能投入出產，因此要在流程中盡早嘗試。
9. 練習和處事之間的要領差別
練習和實際處事之間往往存在要領差別，為了正確地將所有數據預處理懲罰進程都納入到模子處事情況中，需要淘汰這些差別。這雖然是正確的，你也需要僵持這一原則。可是，這只是對這一問題的部門解讀。
先來簡樸看一段陳腐的 DevOps 汗青：2006 年，亞馬遜的 CTO Werner Vogels 締造了一個說法「You build it, you run it（你構建的對象你要運行）」。這是一個描寫性的短語，意思是開拓者的責任不可是寫措施，還需要運行它們。
呆板進修項目也需要雷同的機制——領略上游的數據生成以及下游的模子利用都在數據科學家的職責范疇內。你練習用的數據是通過什么體系生成的？它會出問題嗎？該體系的處事級方針（SLO）是什么？這與實際處事的方針一致嗎？你的模子的處事方法是奈何的？運行時情況是奈何的？奈何在處事時對函數舉辦預處理懲罰？這些都是數據科學家需要領略息爭答的問題。
總結：正確地將預處理懲罰嵌入隨處事之中，確保你領略數據的上下游。
10. 可較量性
從為項目引入第二個練習劇本開始，可較量性就成了將來事情的重要構成部門。假如第二個模子的功效無法與第一個模子的功效舉辦較量，則整個進程就揮霍了，個中至少有一個是多余的，甚至大概兩個都多余。
按照界說，所有試圖辦理同一問題的模子練習都需要可以較量，不然它們就不是在辦理同一問題。盡量迭代進程大概導致所要較量的對象產生變革，可是在技能上實現模子練習的可較量性需要一開始就作為首要成果內置于練習架構之中。
總結：構建你本身的管道式流程，以便輕松較量各個流程的練習功效。
11. 監控
大致地說，呆板進修的方針應該是通過進修數據來辦理問題。為了辦理這個問題，需要分派計較資源。首先是分派給模子的練習，然后是分派給模子的處事。認真在練習期間提供資源的不管是人照舊部分，都需要認真將這些資源轉移給處事。模子在利用進程中大概呈現許多機能下降問題。數據可以偏移，模子大概成為整體機能的瓶頸，毛病也是一個真實存在的問題。
結果：數據科學家和團隊認真監控他們建設的模子。他們并不必然要認真實施監控，尤其是當組織布局很大時，但他們必定需要認真監控數據的領略息爭釋。最低限度上，需要監控的內容包羅輸入數據、推理次數、資源利用環境（CPU、RAM）和輸出數據。
總結：同樣，「You build it, you run it（你構建的對象你要運行）」。監控出產進程中的模子是數據科學的部門事情。
12. 模子的可陳設性
從技能層面講，每個模子練習流程都需要獲得可陳設到出產情況中的制品。毫無疑問，這些模子功效大概很糟糕，但它需要做成可以陳設到出產情況的形態。
這是軟件開拓中的常見模式，也叫做一連交付（Continuous Delivery）。團隊需要可以或許隨時陳設他們的軟件，為了滿意這個方針，迭代周期需要足夠快。
呆板進修也需要回收雷同的要領。這樣才氣迫使團隊首先思量現實與期望之間的均衡。所有好處相關者都該當清楚，在模子功效方面，哪些功效是理論上大概的。所有好處相關者都該當在模子的陳設方法以及如何與更大的軟件架構整合上告竣一致。可是， 東莞貼片鋁電解電容廠家，這也大概需要自動化，也需要前文提到的一些要素。
總結：每個練習流程都需要獲得可陳設的制品，而不「只是」模子。
原文鏈接：https://blog.maiot.io/12-factors-of-ml-in-production/
從算法到應用，入門聲紋技能。
10月19日，第一講：音頻基本與聲紋識別。谷歌資深軟件工程師、聲紋識別與語言識別團隊認真人王泉老師將先容聲紋識別技能相關基本常識，包羅成長過程、聽覺感知和音頻處理懲罰相關根基觀念與要領、聲紋規模最焦點的應用聲紋識別等。
添加呆板之心小助手（syncedai5），備注「聲紋」，進群一起看直播。
? THE END
轉載請接洽本公家號得到授權
投稿或尋求報道：content@jiqizhixin.com喜歡此內容的人還喜歡
原標題：《你的出產型ML復現不了，大概是事情流程出了問題》