工業機器學習：10 個設計原則
如今，每天都有新的服務、應用程式和其他重要程式被創建，使得創造令人難以置信的事物成為可能：從控制 SpaceX 火箭的軟體到透過智慧型手機與隔壁房間的水壺互動。
有時，每個新手程式設計師，無論他是熱情的創業者還是普通的全端或資料科學家，遲早都會意識到程式設計和創建軟體有一定的規則可以大大簡化生活。
在本文中，我將簡要描述如何對工業機器學習進行程式設計的 10 個原則，以便基於 12 因素應用程式方法論將其輕鬆整合到應用程式/服務中。 。 我的倡議是提高人們對這項技術的認識，這可以幫助許多開發人員和數據科學人員。
本文是一系列有關工業機器學習的文章的序言。 在其中，我將進一步討論如何實際建立模型並將其投入生產、為其建立 API，以及來自各個領域和系統中內建 ML 的公司的範例。
原則 1：同一個程式碼庫
一些處於第一階段的程式設計師出於懶惰（或出於他們自己的某種原因）而忘記了 Git。 他們要么完全忘記這個詞，也就是說，他們在驅動器中互相扔文件/只是扔文本/通過鴿子發送，或者他們不思考他們的工作流程，並將每個文件提交到自己的分支，然後提交到掌握。
該原則規定： 擁有一個程式碼庫和多個部署。
Git 既可用於生產，也可用於研究和開發 (R&D)，但在這方面它的使用並不頻繁。
例如，在研發階段，您可以使用不同的資料處理方法和模型進行提交，以便選擇最佳的方法和模型並輕鬆地繼續進一步使用它。
其次，在生產中，這是一個不可替代的東西- 您需要不斷地查看程式碼如何變化，並知道哪個模型產生了最好的結果，哪些程式碼最終有效，以及發生了什麼導致它停止工作或開始產生不正確的結果。 這就是提交的目的！
您也可以建立專案的套件，例如將其放置在 Gemfury 上，然後簡單地從其中匯入其他專案的函數，以免重寫它們 1000 次，稍後會詳細介紹。
原則 2：明確聲明並隔離依賴關係
每個專案都有不同的庫，您可以從外部匯入這些庫，以便將它們套用到某個地方。 無論是Python庫，或是各種用途的其他語言的函式庫，或是系統工具－你的任務是：
- 明確聲明依賴項，即包含專案中使用的且必須安裝的所有程式庫、工具及其版本的檔案（例如，在 Python 中，可以使用 Pipfile 或requirements.txt 來完成。易於理解的連結： )
- 在開發過程中專門隔離您的程式的依賴關係。 您不想不斷更改版本並重新安裝，例如 Tensorflow？
這樣，將來加入您團隊的開發人員將能夠快速熟悉項目中使用的庫及其版本，並且您還將有機會管理為特定項目安裝的版本和庫本身項目，這將幫助您避免庫或其版本的不相容。
您的應用程式也不應該依賴可能安裝在特定作業系統上的系統工具。 這些工具還必須在依賴項清單中聲明。 為了避免工具版本（及其可用性）與特定作業系統的系統工具不符的情況，這是必要的。
因此，即使curl可以在幾乎所有電腦上使用，您仍然應該在依賴項中聲明它，因為當遷移到另一個平台時它可能不存在或版本不是您最初需要的版本。
例如，您的requirements.txt可能如下所示：
# Model Building Requirements
numpy>=1.18.1,<1.19.0
pandas>=0.25.3,<0.26.0
scikit-learn>=0.22.1,<0.23.0
joblib>=0.14.1,<0.15.0
# testing requirements
pytest>=5.3.2,<6.0.0
# packaging
setuptools>=41.4.0,<42.0.0
wheel>=0.33.6,<0.34.0
# fetching datasets
kaggle>=1.5.6,<1.6.0
原則 3：配置
許多人都聽過這樣的故事：各種開發人員不小心將程式碼上傳到GitHub，並使用來自AWS 的密碼和其他金鑰將程式碼上傳到公共儲存庫，第二天醒來時發現自己負債6000美元，甚至50000 美元。
當然，這些案例是極端的，但意義重大。 如果您將配置所需的憑證或其他資料儲存在程式碼中，那麼您就犯了錯誤，我認為無需解釋原因。
另一種方法是將配置儲存在環境變數中。 您可以閱讀有關環境變量的更多信息 .
通常儲存在環境變數中的資料範例：
- 網域
- API URL/URI 的
- 公鑰和私鑰
- 聯絡方式（郵件、電話等）
這樣，如果您的配置變數發生變化，您就不必不斷更改程式碼。 這將幫助您節省時間、精力和金錢。
例如，如果您使用Kaggle API進行測試（例如，下載軟體並透過它運行模型來測試運行時模型是否運作良好），那麼來自Kaggle的私鑰，例如KAGGLE_USERNAME和KAGGLE_KEY，應該儲存在環境變數中。
原則 4：第三方服務
這裡的想法是以這樣的方式創建程式：本地資源和第三方資源在程式碼方面沒有區別。 例如，您可以連接本機MySQL，也可以連接第三方MySQL。 對於各種 API（例如 Google 地圖或 Twitter API）也是如此。
為了停用第三方服務或連接另一個服務，您只需更改環境變數中配置中的鍵，我在上面的段落中已經討論過。
因此，例如，與其每次在程式碼中指定帶有資料集的檔案的路徑，不如使用 pathlib 庫並在 config.py 中聲明資料集的路徑，這樣無論您使用什麼服務（例如例如，CircleCI），考慮到新服務中新檔案系統的結構，程式能夠找到資料集的路徑。
原則 5. 建置、發佈、運行時
許多數據科學領域的人發現提高軟體編寫技能很有用。 如果我們希望我們的程式盡可能少地崩潰並儘可能長時間地無故障運行，我們需要將發布新版本的過程分為3個階段：
- 階段 組件。 您將帶有單獨資源的裸代碼轉換為包含所有必要代碼和資料的所謂包。 這個包稱為程序集。
- 階段 釋放 - 這裡我們將我們的配置連接到組件，沒有它我們將無法發布我們的程式。 現在這是一個完全可以發布的版本。
- 接下來就是舞台 履行。 在這裡，我們透過運行我們的版本中的必要進程來發布應用程式。
這種用於發布模型或整個管道的新版本的系統可讓您區分管理員和開發人員之間的角色，可讓您追蹤版本並防止程式意外停止。
對於發布任務，已經創建了許多不同的服務，您可以在其中編寫流程以在 .yml 檔案中運行自己（例如，在 CircleCI 中，這是支援流程本身的 config.yml）。 Wheely 非常擅長為專案創建包。
您可以使用不同版本的機器學習模型建立套件，然後將它們打包並引用必要的套件及其版本以使用您從那裡編寫的函數。 這將幫助您為您的模型建立 API，並且您的套件可以託管在 Gemfury 上。
原則 6. 將模型作為一個或多個行程運行
此外，進程不應該共享資料。 也就是說，進程必須單獨存在，各種資料也必須單獨存在，例如在MySQL或其他第三方服務上，具體取決於您的需求。
也就是說，絕對不值得將資料儲存在進程檔案系統中，否則可能會導致下次發布/更改配置或傳輸程式運行的系統時清除這些資料。
但有一個例外：對於機器學習項目，您可以儲存庫的緩存，以便在沒有其他庫或對其版本進行任何更改的情況下，每次啟動新版本時都不必重新安裝它們。 這樣，您將減少在行業中推出模型所需的時間。
若要將模型作為多個進程運行，您可以建立一個 .yml 文件，在其中指定必要的進程及其順序。
原則 7：可回收性
在模型應用程式中運行的進程應該易於啟動和停止。 因此，這將允許您快速部署程式碼變更、配置更改，快速且靈活地擴展，並防止工作版本可能發生的故障。
也就是說，您使用模型的過程應該：
- 最小化啟動時間。 理想情況下，啟動時間（從發出啟動命令到進程開始運行）不應超過幾秒鐘。 如上所述，庫緩存是一種減少啟動時間的技術。
- 正確結束。 即該服務連接埠的監聽實際上被暫停了，提交到該連接埠的新請求將不會被處理。 在這裡，您要么需要與 DevOps 工程師建立良好的溝通，要么自己了解它是如何工作的（當然最好是後者，但在任何專案中都應該始終保持溝通！）
原則 8：持續部署/集成
許多公司將應用程式開發和部署團隊分開（使應用程式可供最終用戶使用）。 這會大大減慢軟體開發和改進進度。 它也破壞了 DevOps 文化，粗略地說，開發和整合是結合在一起的。
因此，該原則指出您的開發環境應盡可能接近您的生產環境。
這將允許：
- 減少發佈時間數十倍
- 減少由於程式碼不相容而導致的錯誤數量。
- 這也減少了員工的工作量，因為開發人員和部署應用程式的人員現在都是一個團隊。
允許您使用此功能的工具有 CircleCI、Travis CI、GitLab CI 等。
您可以快速新增模型、更新模型並立即啟動它，同時在發生故障時可以輕鬆快速地返回工作版本，最終用戶甚至不會注意到它。 如果您有良好的測試，這可以特別容易和快速地完成。
盡量減少差異！！！
原則 9. 你的日誌
日誌（或“日誌”）是應用程式（事件流）內發生的事件，通常以文字格式記錄。 一個簡單的例子：“2020-02-02 - 系統級別 - 進程名稱。” 它們的設計目的是讓開發人員可以清楚地看到程式運行時發生的情況。 他看到流程的進展並了解是否符合開發人員自己的意圖。
該原則指出，您不應將日誌儲存在檔案系統中 - 您應該將它們「輸出」到螢幕，例如，在系統的標準輸出上執行此操作。 這樣就可以在開發過程中監控終端機的流量。
這是否意味著根本不需要保存日誌？ 當然不是。 您的應用程式不應該這樣做 - 將其留給第三方服務。 您的應用程式只能將日誌轉發到特定檔案或終端進行即時查看，或將其轉發到通用資料儲存系統（例如Hadoop）。 您的應用程式本身不應儲存日誌或與日誌互動。
原則 10. 測試！
對於工業機器學習來說，這個階段非常重要，因為您需要了解模型是否正確運作並產生您想要的結果。
如果您有回歸/分類任務，可以使用 pytest 建立測試，並使用小資料集進行測試。
不要忘記為深度學習模型設定相同的種子，這樣它們就不會不斷地產生不同的結果。
這是對 10 條原則的簡要描述，當然，如果不嘗試並了解它們是如何工作的，就很難使用它們，因此本文只是一系列有趣文章的序言，在這些文章中我將揭示如何創建工業機器學習模型，如何將它們整合到系統中，以及這些原理如何使我們所有人的生活更輕鬆。
我還將嘗試使用很酷的原則，任何人都可以根據需要在評論中留下這些原則。
來源： www.habr.com