為了讓機器學習為用戶帶來真正的價值，我們需要將其部署到生產系統中。人工智能銷售軟件開發公司 Toucan AI 的 ML 工程師 Marifel 介紹了他們在打造生成級機器學習時所考慮的一些問題，希望這些經驗能為你的工作帶來幫助。

 [[314163]]

這些年，隨著數據和計算技術的發展，「機器學習」和「深度學習」已經變成了熱門研究領域。對公司來說，雖然使用機器學習很時髦，但首先還是需要評估一下自己的業務能否從中受益。如果你的公司已經認定機器學習對公司的下一步發展來說是必需的，那么作為機器學習工程師的你就該思考如何為生產環境構建機器學習過程了。希望本文能幫你明晰你需要考慮的一些東西。

注：本文所提到的「創業公司」都是指有軟件「產品」的公司；對于提供軟件「服務」的公司，則會專門指明。軟件產品公司的業務重心是開發自己的軟件產品，而軟件服務公司（如代理商或咨詢公司）則是為客戶開發軟件。盡管這篇文章是根據作者在早期階段的軟件產品創業公司擔任機器學習工程師的經歷寫的，但其中某些思考也適用于其它階段的公司或其它公司類型。

[[314164]]

本文作者、Toucan AI 公司 ML 工程師 Marifel。

尋找對你有用的工具

機器學習軟件的選擇有很多，有開源的工具，比如 PyTorch、TensorFlow 和 scikit-learn；也有企業提供的機器學習服務，比如 Google AI Platform、Amazon SageMaker 和 Azure Machine Learning。光是 PyTorch 和 TensorFlow，就有很多開源的軟件庫可用，這些直接可用的模型可用作開發產品的起點。

此外，每年還有大量不同領域的機器學習研究論文發表，有的研究者還會以開源形式提供代碼。https://paperswithcode.com/ 這個網站可用來尋找帶有代碼的論文資源。

選擇合適工具所要考慮的關鍵因素包括：

• 文檔的質量；
• 工具的開發情況（有的工具仍有人維護，有的則已經中止開發或已被啟用，或者有嚴重的問題等等）；
• 圍繞該工具的其它工具所構成的生態系統；
• 參與該工具開發的開發者社區；
• 團隊成員對該工具的熟悉程度；
• 將會使用該工具的團隊的規模；
• 該工具所涉及的資金成本。

 在作者個人看來，如果你在一家處于早期階段的創業公司，則不必搞清楚所有這些因素。你可以先選擇一種強大的工具，然后就此出發。另外，在開始的時候使用企業提供的機器學習服務也是完全可以的，只要你覺得這樣做所帶來的收益能超過你的投入。

何時做機器學習以及圍繞機器學習的發展過程

 開發伊始，使用簡單的基準模型是很好的做法。從更簡單的模型開始操作能幫助你找出工作流程中的問題，還能幫你了解是否值得采用更耗時間的解決方案。那么，你該如何選用簡單的基準模型呢？

首先，「簡單」是相對的。在某些案例中，簡單的意思是模型簡單，比如硬編碼一些直觀理解的結果。而在另一些案例中，模型本身可能很復雜，但是很容易應用。某些被廣泛應用的數據集有一些開源的當前最佳模型，你能在研究論文或排行榜等地方找到它們；比如斯坦福問答數據集（SQuAD）就有這樣一個排行榜。你可以尋找一些當前最佳的解決方案，然后尋找與該研究論文相關的代碼。這能為你提供很好的起點。

在早期階段的創業公司，你可能沒有時間馬上動手開發機器學習過程。通常而言，你的工作重心是早點做出一些有效的東西展示給你的投資者或客戶。他們通常不是很關心過程的優化。所以不要在意你的初始部署完美與否；它們只需能得到有效的結果就行，即真實可見的最終產品。你可以在做好基礎產品之后再去考慮機器學習過程的相關事項，這時候你會有更多的空閑時間，可以為你的機器學習過程應用小型的增量改進。

相反，如果你是一家代理商，因為你已經將成品提供給了不同的客戶，并已經事先修復了所有漏洞，因此出錯的空間更小。在向客戶發貨了產品之后，你會轉向下一個客戶合同，因此通常不會有資源來進行進一步的改進。盡管如此，作為一家代理商，你仍然必須快速行動。為了做到更快，擁有一個更細化的機器學習工作過程會大有裨益。因此對于代理商的模型而言，如果事先花更多時間來進行細化和自動化，也許能為更長遠業務節省時間。

實驗管理中所要考慮的事項

 在機器學習工作中，實驗管理并不輕松。當你正盡可能多地運行實驗時，很容易就會把你的項目工作區搞得一團糟。但是，在早期階段的創業公司，你沒有辦法投入幾個月的時間來運行數百場實驗。你只得必須關注更好的東西，然后盡可能快地進行更新。無論如何，在實驗管理方面，有肯定比沒有好。下面是在管理機器學習實驗時需要考慮的一些地方。

模型版本控制

我們 Toucan AI 使用 GitHub 來存儲不同版本的代碼。GitHub 很不錯，但不適合對大型數據文件進行版本控制。盡管一個代碼庫可以高達 100GB，但 GitHub 建議將代碼庫的規模保持在 1GB 以下；此外，單個文件的大小也不能超過 100MB。

你可以使用其它云存儲服務，比如 Google Cloud Storage 或 Amazon S3。使用云提供商的命令行工具或網絡用戶接口，只需創建一個存儲空間（文件夾），就能實現對目標（文件或文件夾）的版本控制。但是，如果你希望同步你的云存儲和你的 GitHub 項目代碼庫，還需要進行一些額外的人工操作。

因此，我們選擇了最自然的集成方案，其中組合了 Git 平臺的最佳特性以及其它云存儲選擇的優勢：數據版本控制（DVC，https://dvc.org/。該項目的宣傳語是「用于機器學習項目的開源版本控制系統」。

DVC 是一款命令行工具，其帶有的子命令與 Git 子命令非常類似。設置好 Git 平臺與云存儲之后，你可以運行 DVC 的 add 和 push 命令，在云存儲中以文件或文件夾的形式保存不同的版本。同時，你還可以通過 DVC 文件的引用功能在你的 Git 項目代碼庫中跟蹤較大的數據文件。DVC 的一大優勢是僅需要少量類 Git 的命令，讓你不至于與已有的 Git 工作流程脫節。

為實驗編寫文檔

如果你在調節超參數，可能很容易就會忘記你在特定時間運行過的某個模型的某種設置。為了為這個模型準備或預處理數據集，你可能還必須回顧一下你之前的工作。你的 Jupyter Notebook 可能具有大致了描述了其中內容的文件名，但你仍然需要些時間才知道當時做了什么——先做了 A 還 B？

針對這個問題，一種解決方案是在你的筆記文件名中加入排序號（我喜歡使用 step 01_），而且你之后也可以重新調整順序。為筆記文件使用清晰明了的命名規則和排序方式能為你的團隊（以及未來的你）提供很大的幫助，讓他們能快速了解你究竟是如何做實驗的。除了在實踐中為筆記文件排序，我們也可使用開源平臺 MLflow（https://mlflow.org (https://mlflow.org/)），其提供了可用于查看實驗超參數和度量結果的網絡接口。

此外，在為實驗編寫文檔時，你還應關注邏輯結構和簡潔性。對于一個又一個模型的筆記和訓練腳本，你需要充分利用文件夾結構的命令規則來進行組織管理。假設有讀者在閱讀你的筆記本，他們通常會從上到下閱讀，所以你要移除那些臨時倉促添加的部分。根據過往經驗，你應該為一個模型和一個數據集寫一個筆記，如果當前的筆記過長，也要創建一個新筆記。你的最終版筆記不應該包含訓練和推理過程的代碼；這些應被放在另外的腳本中，然后你可以在筆記中調用它們。最后，當你在使用 MLflow 等軟件來生成實驗記錄時，可以試試將運行實驗的筆記自動引用到所生成的實驗輸出文件中。

測試框架

在某個指標上得到更好的分數并不意味著你的模型能在真實世界樣例上取得更好推理結果。此外，在生產級機器學習系統中，機器學習模型通常并不單獨工作。舉個例子，你的工作流程中可能包含探索方法、預處理和緩存的結果。因此，當你嘗試改進你已有的機器學習模型時，你要意識到打造出適用于真實世界的推理樣例需要大量時間。

你需要深入理解更大規模的生產代碼，了解你想要改進的模型在實際情況中被調用的時機。你不能只是檢查一下輸入和輸出，僅了解模型本身的情況，而要檢查整個機器學習系統工作過程。你改進的模型將如何影響整個系統？效果更好還是更差？

為了真正實現模型提升，而不只是想出一些新的推理樣例或改變生產流程中的某些東西，我們需要配置一個自動化系統或端到端的測試框架。

我們 Toucan AI 的主要產品是一款 AI 銷售智能體，因此測試覆蓋主要邏輯分支的示例對話就足夠了，并且我們還提供了一種形式的回歸測試。我們目前正在開發一款命令行工具（command-line interface，CLI），該工具可以基于一系列示例對話運行 pytest 審定： https://docs.pytest.org/en/latest/。只需一行命令就可以測試所有對話，如果有任何測試不過關，我們就會以人工方式更新該測試或評估我們的「更好」模型是否真的能更好地應對生產環境。

簡而言之，為了了解你當前的實驗模型在生產機器學習系統中的表現，配備一個測試框架是非常重要的。有了好用的測試框架，你的模型改進工作流程能更高效地運行，讓你可以比之前運行更多實驗。

使用還在快速演進的工具

在我們的生產系統中，我們往往使用的是更老版本代碼庫的修改版；如果這個代碼庫正在快速演進，我們可能很難將新的改進整合到生產系統中。因此，對于正在快速演進的代碼庫，你該如何對其進行修改以滿足自己的需求以及盡可能高效地應用其最新的更新呢？

我認為這個問題不存在唯一的正確答案，而是有很多不同的路徑可走。其中一條路是將他們的一部分代碼與你的一部分代碼組合起來，做成可用的系統；另一條路是取用他們的代碼；并且完全升級你的舊版本，但這種做法需要更長的時間。

簡而言之，你要仔細考慮重新開發需要多少時間，以及什么是優先事項。把重心放在優先事項上，之后再考慮要不要完全重構；你可以在你自己的代碼庫和這個快速演進的工具更加穩定之后再做這件事。

實驗清理

當你關注的重點是獲得結果時，你很容易就會忽視整潔性。你會思考要運行的下一組實驗及其超參數設置。出現了一個錯誤？沒有問題，修改輸出文件夾上的時間戳，然后再次運行實驗。但是，你最后得到的不過是另一些由不完整實驗生成的文件或文件夾。之后，查看實驗記錄的人會深感頭痛，他們被迫在 MLflow 中查看長長的列表，搜尋那些完整運行了的實驗。

解決方案很簡單，自動刪除那些你不想保存的試驗性運行。舉個例子，最好刪除那些在第一輪訓練迭代之前就已經失敗的實驗。為了團隊的未來，我們應當盡己所能地保持實驗記錄的整潔干凈。

隔離問題

為了改善你的模型，你會研究和嘗試各種不同的機器學習項目，你會遇到一些互相沖突的 Python 軟件包需求。一開始，你可能會使用在兩個開發者之間共享的云服務器，但很快你就會發現這樣很不方便，因為你的安裝可能會覆蓋己方團隊的安裝。

使用 Docker 吧！這是一種輕量級的容器化軟件平臺，可用于管理你的項目環境和依賴。你應該為你的每個機器學習模型和應用服務使用不同的 Docker 容器，這樣可以主動地減少「這只在我的機器上有效」的問題，防止項目之間出現依賴沖突。你和你的團隊無需設置更多開發服務器，而是可以每個人都在同一個共享服務器上設置自己的 Docker 容器，這樣做一般也更具成本效益。

此外，你可能會疑惑為什么選 Docker 而不是 Conda，畢竟 Conda 讓你能用不同的軟件版本創建不同的環境？我們選擇 Docker 的原因是其提供的工具更適合生產以及在云上操作。如果你要在一臺遠程機器上使用 Conda，就必須首先連接到該機器，然后處理文件傳輸問題。而在使用 Docker 時，只需要幾行命令，就能將本地文件修改同步到遠程機器的 Docker 容器中。

此外，運行項目所需的一切都會在 Dockerfile 或 Docker Compose 文件中說明。而在使用 Conda 時，如果不參考一下 README，我們不知道是否還需要額外的步驟。

最后，在 Docker Compose 的幫助下，如果一個機器學習項目需要其它服務才能運行，那么就可以將這些額外服務運行在其它 Docker 容器中，然后讓這些容器根據 Docker Compose 文件設置進行通信。就我所知，使用 Conda 不能實現跨環境通信。

做好在有需要時擴展規模的準備

當創業公司還處于早期階段時，還不需要擴展規模，但還是有必要思考一下用于實現擴展的技術。其中之一是 Celery：http://www.celeryproject.org/。這是一個異步任務隊列系統，可以將任務分發給多個工作器處理。我們目前是為每種類型的服務（服務器、客戶端、嵌入式模型）使用一個工作器，但如無必要，不應該花太多精力來為同一服務設置更多工作器。

此處有一個疑問，通過嵌入進行緩存是你的擴展瓶頸嗎？沒有問題，我們可以再做另一個嵌入式 Celery 工作器或增加當前工作器的并發數量，這能讓你并行運行多個子進程。我們 Toucan AI 的配置是在一個 Docker 容器中運行單個 Celery 工作器，這同時也考慮到了隔離問題。

Celery 不僅能擴展你的生產系統，還非常適合用于執行那些需要長時間運行的任務，比如機器學習模型推理任務。除了允許服務器響應掛起，服務器響應（智能體的回復）可以立即返回給與 Toucan AI 智能體對話的終端用戶，同時還可以在后臺安靜地運行異步任務（比如緩存機制）。

此外，我們還使用 Celery beat 來運行我們日常安排的分析工作器任務。Celery beat 有助于使用 cron 來安排工作器任務。

與團隊和未來的自己合作

機器學習研究論文正在大量發表，作為一位機器學習工程師，你需要知道你的團隊正在開發以及嘗試過哪些模型和技術。那么你該怎么做呢？你沒有任何捷徑可以獲得他們的知識、經驗和見解，但你可以與他們溝通，并且要多多溝通。

無論什么時候，都要保持溝通，尤其是通過書面溝通。很多時候，你做著自己的項目，而你當前所做的事情可能與你的團隊所做的事情完全無關。盡管如此，也許未來某個時間他們需要審查或擴展你已經實現的東西。可能在你完成那項任務的幾個月后，你需要對你自己的項目進行一些修改，而這時你可能已經忘記了你做過了什么。所以記得做文檔，做文檔，做文檔！重復三篇，現在你知道做文檔的重要性了吧？

另外要注意，有時候光有筆記是不夠的。你需要讓你的團隊也了解你做的事情。如果你有些不確定的地方，當你需要他們的誠實意見時，或你感覺口語是更有效率的溝通媒介時，你都可以與他們談談你的項目的發展方向。注意從一開始就要保持溝通清楚，這是非常重要的，可以防止誤解、徒勞、擔憂和悔恨。

機器學習工程師的內心掙扎

 作為一位機器學習工程師，你必須學會調整自己的思想，不要老想著查漏補缺，把事情做得比實際所需的更好。你必須學會接受不完美，把重要的時間放在完成最緊迫的任務上。舉個例子，我喜歡花時間改進第三方的訓練/評估代碼，但這個時候我也許只需要盡快知道推理結果是否有所改善。

我有做網站開發的背景，那時候我基本必須完全自己寫代碼，但在機器學習工程開發中，我必須學會如何應用其他人的代碼。當你總是使用別人的代碼時（這些代碼往往是學生和研究者花費幾個月乃至幾年的時間研究出來的），有時候難免覺得失落，覺得自己的工作不完整，尤其是當你過于在意地想要理解那些代碼的方方面面時。但是，這是不必要的，你要做的只是將他們的模型成功地部署到你的生產系統中。

不管怎么說，我們本質上都是好奇的生物，很自然會想要理解超過實際所需的東西。如果你想要做些探索，最好讓你的團隊也知道這一點。如果你能足夠及時地完成你的目標工作，互相理解的工作環境能為你提供學習更多的機會。只要你知道什么是優先事項，那就不要太擔憂，開心去探索吧。

總結

 為生產系統打造機器學習過程并非易事。盡管文中列出了這么多所要考慮的東西，但有時候，你要做的僅僅是一個決定。如果這條路不同，那就走另一條。雖說如此，但還是希望這篇文章能幫你了解這些需要考慮的東西。