導(dǎo)讀

這篇文章介紹了為生產(chǎn)系統(tǒng)構(gòu)建機(jī)器學(xué)習(xí)過(guò)程的很多方面的內(nèi)容，都是從實(shí)踐中總結(jié)出來(lái)的。

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

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

找到合適的工具

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

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

文檔的質(zhì)量

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

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

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

你對(duì)該工具的熟悉程度

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

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

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

何時(shí)開(kāi)始做機(jī)器學(xué)習(xí) vs. 機(jī)器學(xué)習(xí)周?chē)牟僮?/p>

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

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

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

相反，如果你是一個(gè)代理商，出錯(cuò)的空間就更小，因?yàn)槟阋獙⑼瓿傻漠a(chǎn)品交付給不同的客戶，并試圖事先修復(fù)所有的bug。在交付一個(gè)或一組客戶端產(chǎn)品之后，你將轉(zhuǎn)移到下一個(gè)客戶端合同上，并且通常沒(méi)有足夠的精力來(lái)進(jìn)行進(jìn)一步的改進(jìn)。盡管如此，你還是要迅速行動(dòng)。為了進(jìn)展得更快，最好有更精細(xì)的ML過(guò)程。因此，對(duì)于代理商模型，從長(zhǎng)遠(yuǎn)來(lái)看，也許在優(yōu)化和自動(dòng)化上預(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)階段，你沒(méi)有幾個(gè)月的時(shí)間來(lái)做數(shù)百個(gè)實(shí)驗(yàn)。你只需要推動(dòng)一些更好的東西，然后盡快更新。不管怎樣，進(jìn)行某種實(shí)驗(yàn)管理總比什么都不做要好。以下是管理ML實(shí)驗(yàn)時(shí)需要考慮的一些事項(xiàng)。

模型版本

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

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

因此，我們選擇了最自然的集成，它結(jié)合了Git平臺(tái)和其他云存儲(chǔ)選項(xiàng)的最佳特性：數(shù)據(jù)版本控制(DVC)，被標(biāo)記為“機(jī)器學(xué)習(xí)項(xiàng)目的開(kāi)源版本控制系統(tǒng)”。DVC是一個(gè)命令行工具，它的子命令與Git子命令非常相似。在Git平臺(tái)和云存儲(chǔ)設(shè)置完成后，你可以運(yùn)行DVC的‘add’和‘push’命令來(lái)設(shè)置版本，并在云存儲(chǔ)中存儲(chǔ)文件或文件夾。同時(shí)，可以通過(guò)DVC文件引用在Git項(xiàng)目存儲(chǔ)庫(kù)中跟蹤大型數(shù)據(jù)文件。DVC的一個(gè)優(yōu)點(diǎn)是只需要一些額外的類(lèi)Git命令，這與現(xiàn)有的Git工作流沒(méi)有太大的區(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í)間來(lái)處理首先發(fā)生的事情，或者如果你將預(yù)處理A或B應(yīng)用于實(shí)驗(yàn)7。

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

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

測(cè)試框架

更好的度量結(jié)果并不總是與真實(shí)樣本中改進(jìn)的推理性能相關(guān)。此外，在生產(chǎn)ML系統(tǒng)中，ML模型并不是獨(dú)立操作的：例如，你可能將啟發(fā)式、預(yù)處理和緩存作為pipeline的一部分。因此，當(dāng)嘗試改進(jìn)你已經(jīng)擁有的ML模型時(shí)，你會(huì)意識(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è)自動(dòng)化的系統(tǒng)或端到端測(cè)試框架。

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

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

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

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

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

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

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

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

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

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

進(jìn)入Docker生態(tài)系統(tǒng)，這是一個(gè)輕量級(jí)的容器化軟件平臺(tái)，用于管理你的項(xiàng)目環(huán)境和依賴項(xiàng)。通過(guò)為每個(gè)ML模型和應(yīng)用程序服務(wù)使用單獨(dú)的Docker容器，我們可以主動(dòng)減少“它在我的機(jī)器上工作”問(wèn)題的數(shù)量，并防止項(xiàng)目之間發(fā)生依賴沖突。與其設(shè)置更多的開(kāi)發(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è)命令，你就可以對(duì)本地文件進(jìn)行更改，并將它們反映到遠(yuǎn)程機(jī)器的Docker容器中。此外，運(yùn)行項(xiàng)目所需的一切都在Dockerfile或Docker Compose文件中指定。

另一方面，對(duì)于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ī)模，但最好是開(kāi)始考慮可以擴(kuò)大規(guī)模的技術(shù)。其中一種技術(shù)是Celery，這是一個(gè)異步任務(wù)隊(duì)列系統(tǒng)，可以將任務(wù)分配給多個(gè)工作者。目前，對(duì)于每種類(lèi)型的服務(wù)(服務(wù)器、客戶機(jī)、embeddings模型等)，我們都有一個(gè)單獨(dú)的worker，但是如果有必要的話，為相同的服務(wù)啟動(dòng)更多的worker應(yīng)該不需要太多的工作。通過(guò)嵌入進(jìn)行緩存會(huì)成為瓶頸嗎？沒(méi)問(wèn)題，讓我們啟動(dòng)另一個(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í)行長(zhǎng)時(shí)間運(yùn)行的任務(wù)，比如ML模型推斷任務(wù)。與允許服務(wù)器響應(yīng)掛起不同，服務(wù)器響應(yīng)(代理的應(yīng)答)可以立即返回給與Toucan AI代理對(duì)話的最終用戶，而異步任務(wù)(如緩存機(jī)制)可以在后臺(tái)悄悄運(yùn)行。此外，我們使用Celery beat來(lái)運(yùn)行我們每天計(jì)劃的分析工作者任務(wù)。

與同事和未來(lái)的你合作

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

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

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

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

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

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

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

結(jié)論

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