隨著數(shù)據(jù)和計(jì)算能力的崛起，“機(jī)器學(xué)習(xí)”(ML)和“深度學(xué)習(xí)”(deep learning)這兩個(gè)術(shù)語已經(jīng)熱議了好幾年。雖然追隨ML的潮流似乎很酷，但公司的第一步是評估業(yè)務(wù)是否真的能從中受益 —— 這是一個(gè)獨(dú)立的職位。既然你的公司已經(jīng)決定ML是一個(gè)必要的下一步，那么作為一個(gè)ML工程師，現(xiàn)在是時(shí)候考慮為生產(chǎn)系統(tǒng)構(gòu)建ML過程的真正內(nèi)容了。希望這篇文章能幫助你理解這些問題。

在這篇文章中，只要提到“初創(chuàng)”這個(gè)詞，就意味著軟件“產(chǎn)品”公司，除非特別提到軟件“服務(wù)”公司。軟件產(chǎn)品公司專注于構(gòu)建自己的軟件產(chǎn)品，而軟件服務(wù)公司(如代理或咨詢公司)則為客戶構(gòu)建軟件。雖然這篇文章是為早期軟件產(chǎn)品初創(chuàng)公司的ML工程師寫的，但其中的一些考慮可能仍然適用于其他階段或公司類型。

找到合適的工具

有多個(gè)機(jī)器學(xué)習(xí)軟件可供選擇，從開源工具如PyTorch， TensorFlow以及scikit-learn到管理機(jī)器學(xué)習(xí)服務(wù)的平臺如，Google AI平臺，亞馬遜SageMaker和Azure機(jī)器學(xué)習(xí)平臺。僅使用PyTorch和TensorFlow，就有許多像Hugging Face的transformer這樣的開源庫，它們提供了現(xiàn)成的模型作為起點(diǎn)。此外，ML在不同領(lǐng)域的研究論文每年都會發(fā)表，其中一些提供了開源代碼。Papers With Code：https://paperswithcode.com/是查找?guī)Тa的論文的好資源。

在選擇合適的工具時(shí)要考慮的關(guān)鍵因素有：

文檔的質(zhì)量

工具的開發(fā)狀態(tài)(maintained vs. halted or deprecated，問題的嚴(yán)重程度，等等)

圍繞該工具的其他工具的生態(tài)系統(tǒng)

開發(fā)人員社區(qū)對這個(gè)工具的參與是否積極

你對該工具的熟悉程度

使用該工具的團(tuán)隊(duì)規(guī)模

與工具有關(guān)的貨幣成本

就我個(gè)人而言，我覺得如果你是一家處于早期階段的初創(chuàng)公司，你不需要權(quán)衡和找出所有這些因素。你總是可以從一個(gè)強(qiáng)大的候選工具開始，然后從那里開始。此外，如果你認(rèn)為收益大于成本，則可以從一開始就使用托管ML服務(wù)。

何時(shí)開始做機(jī)器學(xué)習(xí) vs. 機(jī)器學(xué)習(xí)周圍的操作

在第一次開始時(shí)，最好從一個(gè)簡單的基線模型開始。從更簡單的模型開始可以幫助你調(diào)試pipeline中的問題，并幫助你確定更耗時(shí)的解決方案是否值得。那么如何建立一個(gè)簡單的基線模型呢?

首先，“簡單”是相對的。在某些情況下，簡單實(shí)際上意味著一個(gè)簡單的模型，例如硬編碼一些啟發(fā)式。而在其他情況下，模型本身可能很復(fù)雜，但是很容易應(yīng)用。一些最廣泛使用的數(shù)據(jù)集擁有最先進(jìn)的模型，這些模型是開源的，列在研究論文或排行榜等地方，斯坦福問答數(shù)據(jù)集(SQuAD)就有這樣一個(gè)排行榜。一種方法是查看一些頂級的解決方案，看看你是否能找到附加到相關(guān)研究論文的代碼。

在早期啟動階段，你可能沒有時(shí)間立即構(gòu)建ML流程。通常情況下，你需要專注于讓你的投資者和客戶很容易就能看到的東西運(yùn)行起來。調(diào)優(yōu)過程很少出現(xiàn)在他們的腦海中。所以不要擔(dān)心你最初的部署是否完美，只需要有一個(gè)工作成果 —— 一個(gè)看得見的最終產(chǎn)品。在基本產(chǎn)品構(gòu)建之后，你可以更多地?fù)?dān)心ML周圍的流程，因?yàn)橥ǔＰ枰嗟耐C(jī)時(shí)間來對ML流程進(jìn)行小的、漸進(jìn)的改進(jìn)。

相反，如果你是一個(gè)代理商，出錯的空間就更小，因?yàn)槟阋獙⑼瓿傻漠a(chǎn)品交付給不同的客戶，并試圖事先修復(fù)所有的bug。在交付一個(gè)或一組客戶端產(chǎn)品之后，你將轉(zhuǎn)移到下一個(gè)客戶端合同上，并且通常沒有足夠的精力來進(jìn)行進(jìn)一步的改進(jìn)。盡管如此，你還是要迅速行動。為了進(jìn)展得更快，最好有更精細(xì)的ML過程。因此，對于代理商模型，從長遠(yuǎn)來看，也許在優(yōu)化和自動化上預(yù)先花費(fèi)更多的時(shí)間可以節(jié)省時(shí)間。

實(shí)驗(yàn)管理中的考慮

在ML中管理實(shí)驗(yàn)不是一件小事，當(dāng)你在運(yùn)行盡可能多的實(shí)驗(yàn)時(shí)，你的項(xiàng)目工作區(qū)很容易變得混亂。然而，在初創(chuàng)階段，你沒有幾個(gè)月的時(shí)間來做數(shù)百個(gè)實(shí)驗(yàn)。你只需要推動一些更好的東西，然后盡快更新。不管怎樣，進(jìn)行某種實(shí)驗(yàn)管理總比什么都不做要好。以下是管理ML實(shí)驗(yàn)時(shí)需要考慮的一些事項(xiàng)。

模型版本

在Toucan AI，我們使用GitHub來存儲我們代碼的版本。GitHub很棒，但它不是用來對大型數(shù)據(jù)文件進(jìn)行版本控制的。盡管存儲庫可以達(dá)到100GB，但GitHub建議將存儲庫的大小保持在1GB以下，此外，單個(gè)文件不能超過100MB。

你可以使用其他云存儲選項(xiàng)，如谷歌云存儲或Amazon S3。使用云提供商的命令行工具或web用戶界面，只需創(chuàng)建一個(gè)bucket(文件夾)，允許對其對象(文件或文件夾)進(jìn)行版本控制。但是，如果希望將云存儲中的文件與GitHub上的項(xiàng)目存儲庫同步，則需要額外的手工工作。

因此，我們選擇了最自然的集成，它結(jié)合了Git平臺和其他云存儲選項(xiàng)的最佳特性：數(shù)據(jù)版本控制(DVC)，被標(biāo)記為“機(jī)器學(xué)習(xí)項(xiàng)目的開源版本控制系統(tǒng)”。DVC是一個(gè)命令行工具，它的子命令與Git子命令非常相似。在Git平臺和云存儲設(shè)置完成后，你可以運(yùn)行DVC的‘add’和‘push’命令來設(shè)置版本，并在云存儲中存儲文件或文件夾。同時(shí)，可以通過DVC文件引用在Git項(xiàng)目存儲庫中跟蹤大型數(shù)據(jù)文件。DVC的一個(gè)優(yōu)點(diǎn)是只需要一些額外的類Git命令，這與現(xiàn)有的Git工作流沒有太大的區(qū)別。

實(shí)驗(yàn)文檔化

如果你正在進(jìn)行超參數(shù)調(diào)優(yōu)，則很容易忽略在指定日期為某個(gè)模型運(yùn)行的特定設(shè)置。你可能還需要回顧你為準(zhǔn)備或預(yù)處理上述模型所需的數(shù)據(jù)集所做的工作。你的Jupyter Notebooks有描述性的文件名，但是它仍然需要相當(dāng)多的時(shí)間來處理首先發(fā)生的事情，或者如果你將預(yù)處理A或B應(yīng)用于實(shí)驗(yàn)7。

一種解決方案是，在創(chuàng)建新的Notebook時(shí)，將Notebooks編號作為文件名的一部分(我喜歡使用“01_”步驟)，以后可以重新編號。對你的Notebooks編號有一個(gè)明確的命名約定對你的同事(以及未來的你)了解你是如何進(jìn)行實(shí)驗(yàn)的非常有幫助。除了在實(shí)驗(yàn)中為Notebooks編號外，我們還使用開源平臺MLflow來提供查看實(shí)驗(yàn)超參數(shù)和度量結(jié)果的web界面。

此外，在記錄實(shí)驗(yàn)時(shí)，力求邏輯結(jié)構(gòu)和簡潔。充分利用文件夾結(jié)構(gòu)和名稱來組織你的Notebooks和訓(xùn)練腳本。假設(shè)當(dāng)讀者查看你的Notebook時(shí)，他們會從頭到尾地閱讀，所以要刪除你臨時(shí)插入的任何“草稿”單元格。根據(jù)經(jīng)驗(yàn)，將Notebook上的試驗(yàn)限制在一個(gè)模型和一個(gè)數(shù)據(jù)集上，如果當(dāng)前的筆記本太長，則創(chuàng)建一個(gè)新的筆記本。盡量讓你最后的筆記本版本不包含訓(xùn)練或推理代碼，這些應(yīng)該放在可以在Notebook中調(diào)用的獨(dú)立腳本中。最后，當(dāng)使用像MLflow這樣的軟件生成實(shí)驗(yàn)記錄時(shí)，嘗試將運(yùn)行實(shí)驗(yàn)的筆記本自動引用到生成的實(shí)驗(yàn)輸出文件中。

測試框架

更好的度量結(jié)果并不總是與真實(shí)樣本中改進(jìn)的推理性能相關(guān)。此外，在生產(chǎn)ML系統(tǒng)中，ML模型并不是獨(dú)立操作的：例如，你可能將啟發(fā)式、預(yù)處理和緩存作為pipeline的一部分。因此，當(dāng)嘗試改進(jìn)你已經(jīng)擁有的ML模型時(shí)，你會意識到，生成適合真實(shí)世界的推理樣本需要大量的時(shí)間。你需要深入研究更大的生產(chǎn)代碼，以發(fā)現(xiàn)你試圖改進(jìn)的模型實(shí)際上在什么地方被調(diào)用。然后，你不希望只檢查模型本身的輸入和輸出，還要檢查整個(gè)ML系統(tǒng)的pipeline。你的“更好”模型如何影響整個(gè)系統(tǒng)，它是更好還是更壞?

為了將重點(diǎn)放在模型改進(jìn)上，而不是提出推理樣本或擔(dān)心破壞生產(chǎn)pipeline中的某些東西，我們需要有一個(gè)自動化的系統(tǒng)或端到端測試框架。

在Toucan AI，由于我們的主要產(chǎn)品是AI銷售代理，測試覆蓋主要邏輯分支的樣本對話就足夠了，同時(shí)也提供了一種回歸測試的形式。我們目前正在開發(fā)一個(gè)命令行接口(CLI)工具，它將在一系列示例對話中運(yùn)行pytest斷言。使用一個(gè)命令，所有的對話都可以被測試，如果任何測試用例中斷，我們可以手動更新測試或者認(rèn)為我們的“更好的”模型實(shí)際上并不更適合生產(chǎn)。

簡而言之，有一個(gè)適當(dāng)?shù)臏y試框架對于理解當(dāng)前和實(shí)驗(yàn)?zāi)Ｐ驮谏a(chǎn)ML系統(tǒng)中的表現(xiàn)是至關(guān)重要的。有了一個(gè)合適的測試框架，你的模型改進(jìn)pipeline應(yīng)該更有效地推進(jìn)，允許你比以前運(yùn)行更多的實(shí)驗(yàn)。

使用工具快速演進(jìn)

從快速發(fā)展的庫中提取代碼并將其寫入使用該庫的修改過的舊版本的生產(chǎn)系統(tǒng)是很困難的。如何修改一個(gè)快速發(fā)展的庫以滿足你的需要并盡可能高效地應(yīng)用它的最新更新?

我覺得沒有正確的答案，只有許多不同的途徑。一種方法是把他們的代碼和你的代碼結(jié)合起來，讓它工作。另一種方法是使用他們的代碼并完全升級舊版本，但這通常需要更長的時(shí)間。簡而言之，考慮一下你有多少時(shí)間進(jìn)行重構(gòu)，以及重構(gòu)的優(yōu)先級是什么。在你自己的代碼庫和快速發(fā)展的工具變得更加穩(wěn)定之后，你應(yīng)該關(guān)注優(yōu)先級，并考慮完整的重構(gòu)。

實(shí)驗(yàn)整理

當(dāng)你專注于取得成果時(shí)，往往很容易忽略整潔?？紤]下一組要運(yùn)行的實(shí)驗(yàn)，以及它的超參數(shù)集。發(fā)生了一個(gè)錯誤?沒問題，更改輸出文件夾上的時(shí)間戳并重新運(yùn)行實(shí)驗(yàn)。然而，你最終得到的是由于試驗(yàn)不完整而生成的額外文件或文件夾。之后，你在MLflow中滾動一長串記錄，尋找完成的實(shí)驗(yàn)，結(jié)果卻讓他們摸不著頭腦。

解決方案是自動刪除不想保存的所有試運(yùn)行。例如，最好在第一次訓(xùn)練迭代完成執(zhí)行之前就刪除失敗的運(yùn)行。為了我們的同事和未來的自己，我們都應(yīng)該盡我們最大的努力保持實(shí)驗(yàn)池的整潔。

關(guān)注點(diǎn)的分離

當(dāng)你研究并嘗試各種ML項(xiàng)目以希望改進(jìn)你的模型時(shí)，你將遇到相互沖突的Python包需求。你最初可能在兩個(gè)開發(fā)人員之間共享一個(gè)云服務(wù)器，但這很快就變得不方便了，因?yàn)槟愕陌惭b可能會覆蓋你的同事的運(yùn)行環(huán)境。

進(jìn)入Docker生態(tài)系統(tǒng)，這是一個(gè)輕量級的容器化軟件平臺，用于管理你的項(xiàng)目環(huán)境和依賴項(xiàng)。通過為每個(gè)ML模型和應(yīng)用程序服務(wù)使用單獨(dú)的Docker容器，我們可以主動減少“它在我的機(jī)器上工作”問題的數(shù)量，并防止項(xiàng)目之間發(fā)生依賴沖突。與其設(shè)置更多的開發(fā)服務(wù)器，你的每個(gè)同事可以在單個(gè)共享服務(wù)器上設(shè)置自己的Docker容器，如果這樣做更劃算的話。

此外，你可能想知道，為什么選擇Docker而不是Conda，而且Conda還允許你使用不同的包版本創(chuàng)建不同的環(huán)境。我們選擇Docker是因?yàn)樗峁┑墓ぞ吒m合于生產(chǎn)和處理云的環(huán)境。如果要在遠(yuǎn)程機(jī)器上使用Conda，則必須先與機(jī)器連接并處理文件傳輸。但是，只需在Docker中使用幾個(gè)命令，你就可以對本地文件進(jìn)行更改，并將它們反映到遠(yuǎn)程機(jī)器的Docker容器中。此外，運(yùn)行項(xiàng)目所需的一切都在Dockerfile或Docker Compose文件中指定。

另一方面，對于Conda，如果不引用README，就不清楚是否需要其他步驟。最后，利用Docker Compose的強(qiáng)大功能，如果ML項(xiàng)目需要運(yùn)行其他服務(wù)，它們可以在其他Docker容器中單獨(dú)運(yùn)行，并根據(jù)Docker Compose文件設(shè)置相互通信。據(jù)我所知，在Conda中不能跨環(huán)境通信。

準(zhǔn)備好做擴(kuò)展

作為一個(gè)處于早期階段的初創(chuàng)公司，你現(xiàn)在可能不需要擴(kuò)大規(guī)模，但最好是開始考慮可以擴(kuò)大規(guī)模的技術(shù)。其中一種技術(shù)是Celery，這是一個(gè)異步任務(wù)隊(duì)列系統(tǒng)，可以將任務(wù)分配給多個(gè)工作者。目前，對于每種類型的服務(wù)(服務(wù)器、客戶機(jī)、embeddings模型等)，我們都有一個(gè)單獨(dú)的worker，但是如果有必要的話，為相同的服務(wù)啟動更多的worker應(yīng)該不需要太多的工作。通過嵌入進(jìn)行緩存會成為瓶頸嗎?沒問題，讓我們啟動另一個(gè)嵌入的Celery工作程序，或者增加當(dāng)前工作程序的“并發(fā)”計(jì)數(shù)，它允許多個(gè)子進(jìn)程并行運(yùn)行。在我們的Toucan AI配置中，一個(gè)Celery worker在一個(gè)Docker容器中運(yùn)行，因此也遵循關(guān)注點(diǎn)分離。

除了允許你的生產(chǎn)系統(tǒng)擴(kuò)展之外，Celery還非常適合執(zhí)行長時(shí)間運(yùn)行的任務(wù)，比如ML模型推斷任務(wù)。與允許服務(wù)器響應(yīng)掛起不同，服務(wù)器響應(yīng)(代理的應(yīng)答)可以立即返回給與Toucan AI代理對話的最終用戶，而異步任務(wù)(如緩存機(jī)制)可以在后臺悄悄運(yùn)行。此外，我們使用Celery beat來運(yùn)行我們每天計(jì)劃的分析工作者任務(wù)。

與同事和未來的你合作

隨著ML研究的不斷發(fā)布，作為ML工程師，你如何讓你的團(tuán)隊(duì)成員保持一個(gè)從嘗試到使用的模型或技術(shù)的循環(huán)?沒有什么魔法可以將他們獲得的所有知識、經(jīng)驗(yàn)和洞察力傳授給你。但是你能做的就是交流。經(jīng)常交流。

盡可能的交流，尤其是在寫文檔的時(shí)候。因?yàn)橥ǔＧ闆r下，你是在做你自己的項(xiàng)目，所以你現(xiàn)在正在做的事情可能和你的同事正在做的事情并不完全相關(guān)。然而，將來他們可能需要審查或擴(kuò)展你已經(jīng)實(shí)現(xiàn)的內(nèi)容。甚至可能是你幾個(gè)月后，不得不對你自己的項(xiàng)目做出改變，而你已經(jīng)忘記了其中的關(guān)鍵部分。文檔，文檔，文檔。怎么強(qiáng)調(diào)都不為過。

另一方面，肯定會有文檔不夠用的時(shí)候。如果你有一些東西不確定，你想要他們的誠實(shí)的意見，你覺得說話是一個(gè)更有效的溝通媒介的時(shí)候，注意你的同事的精神集中的狀態(tài)，尋求與他們討論項(xiàng)目的方向。從一開始就盡可能的清晰，這對于防止誤解，徒勞的工作，和悔恨是非常重要的。

作為機(jī)器學(xué)習(xí)工程師的內(nèi)部斗爭

作為一名機(jī)器學(xué)習(xí)工程師，你必須學(xué)會權(quán)衡好你想要修復(fù)的東西的想法以及讓流程變得更好以完成當(dāng)前的需求之間的關(guān)系。你必須學(xué)會接受采取最直接的方式來完成工作。例如，我很想花時(shí)間改進(jìn)第三方的訓(xùn)練/評估代碼，但當(dāng)時(shí)，我只需要采用最短路徑來查看我們的推理結(jié)果是否會得到改進(jìn)。

由于我有web開發(fā)的背景，所以大多數(shù)情況下我必須編寫自己的代碼，但是在ML工程中，我必須學(xué)習(xí)如何應(yīng)用其他人的代碼。當(dāng)你經(jīng)常使用的代碼不是你自己的 —— 通常是學(xué)生和研究人員花了幾個(gè)月或幾年研究出來的代碼 —— 有時(shí)很難不覺得自己很失敗，尤其是當(dāng)你試圖理解不是直接部署到生產(chǎn)系統(tǒng)中的那方面的代碼的時(shí)候。

在一天結(jié)束的時(shí)候，只要記住我們是天性好奇的生物，想要學(xué)習(xí)比你需要學(xué)習(xí)的更多是可以的。如果有你想探索的途徑，與你的隊(duì)友保持透明是關(guān)鍵。一個(gè)好的工作環(huán)境不會因?yàn)槟阆胍獙W(xué)習(xí)更多而責(zé)備你，如果你足夠及時(shí)地實(shí)現(xiàn)了目標(biāo)。只要你有優(yōu)先考慮的事情，盡量少擔(dān)心，多享受。

結(jié)論

為生產(chǎn)系統(tǒng)構(gòu)建ML流程并不簡單。盡管在這篇文章中提到了所有的內(nèi)容，有時(shí)候，你能做的最好的決定就是簡單地做一個(gè)決定。如果沒有成功，那就繼續(xù)下一條路。不管怎樣，我希望這篇文章能夠幫助我們更好地理解各種不同的想法。