機器學(xué)習(xí)中的設(shè)計模式

根據(jù)其定義，設(shè)計模式是對常見問題的可重用解決方案。在軟件工程中，這一概念可以追溯到1987年，當(dāng)時Beck和Cunningham開始將其應(yīng)用到編程中。到2000年代，設(shè)計模式（尤其是面向OOP的SOLID設(shè)計原則）被認(rèn)為是程序員的常識。快進15年，我們進入了Software 2.0的時代：機器學(xué)習(xí)模型開始在越來越多的代碼位置取代經(jīng)典功能。今天，我們將軟件視為傳統(tǒng)代碼，機器學(xué)習(xí)模型和基礎(chǔ)數(shù)據(jù)的融合。這種融合需要這些組件的無縫集成，考慮到這些領(lǐng)域通常不同的歷史和演變，這通常并非易事。

今天，我們將軟件視為傳統(tǒng)代碼，機器學(xué)習(xí)模型和基礎(chǔ)數(shù)據(jù)的融合。

但是，尚未擴展設(shè)計模式以應(yīng)對這個新時代的挑戰(zhàn)。在Software 2.0中，常見的挑戰(zhàn)不僅出現(xiàn)在代碼級別，而且還出現(xiàn)在問題定義，數(shù)據(jù)表示，訓(xùn)練方法，擴展以及支持AI的系統(tǒng)設(shè)計的道德方面。這為實踐機器學(xué)習(xí)反模式創(chuàng)造了沃土。不幸的是，今天，即使是博客文章和會議，有時也會采用反模式：被認(rèn)為可以改善但實際上卻使情況更糟的做法。由于反模式也需要技能，因此其從業(yè)人員通常不會認(rèn)識到這種技能。因此，在下文中，我將給出兩個常見的ML挑戰(zhàn)示例，但我將首先介紹其解決方案反模式，而不是從設(shè)計模式入手。

該模型在評估指標(biāo)上顯示出較差的性能

在常見情況下，在收集，清理和準(zhǔn)備數(shù)據(jù)之后，工程師會訓(xùn)練第一個模型，并發(fā)現(xiàn)該模型在測試數(shù)據(jù)上顯示出較差的性能。常見的反模式是用更復(fù)雜的模式（例如，通常是梯度增強樹）替換第一個模型，并以此來提高性能。通過例如通過模型平均來組合多個模型，該反模式的變型可以跟隨該步驟。

這些方法的問題在于它們僅關(guān)注問題的一部分，即模型，并選擇通過增加模型的復(fù)雜性來解決問題。這一步迫使我們接受過度擬合的高風(fēng)險，并以可解釋性換取其他預(yù)測能力。盡管有一些有效的方法可以減輕這種選擇的副作用（例如LIME），但我們無法完全消除它們。

設(shè)計模式是錯誤分析。實際上，這意味著通過評估模型在不同測試集上的擬合度，甚至通過查看模型錯誤的個別情況，來查看模型出錯的地方。盡管我們都聽到過“垃圾進，垃圾出去”的說法，但即使數(shù)據(jù)存在一點點不一致，也很少有人意識到這是正確的。標(biāo)簽可能來自不同的評分者，每個評分者對標(biāo)簽指南的解釋都略有不同。也許收集數(shù)據(jù)的方式已經(jīng)隨著時間而改變。對于小數(shù)據(jù)問題，錯誤分析的效果尤其明顯。但是，我們還應(yīng)記住，在大比例的大數(shù)據(jù)情況下，我們還會處理長尾事件（例如，通過入學(xué)考試確定稀有人才）。

錯誤分析的真正威力來自于這樣一個事實，即我們不通過應(yīng)用它來交換可解釋性或過度擬合的風(fēng)險，實際上僅應(yīng)用它就可以得出有關(guān)數(shù)據(jù)分布的關(guān)鍵知識。此外，錯誤分析使我們能夠選擇以模型為中心的解決方案（例如，更復(fù)雜的模型）和以數(shù)據(jù)為中心的解決方案（例如，進一步的清潔步驟）。

部署模型的性能隨時間下降

該模型經(jīng)過廣泛的驗證，并被部署到生產(chǎn)中。用戶很高興，并給出了積極的反饋。然后，一個月/一個季度/一年之后，就會出現(xiàn)有關(guān)預(yù)測缺陷的報告。這通常是概念漂移的體現(xiàn)，模型在輸入和輸出之間學(xué)習(xí)的聯(lián)系已隨時間而改變。在某些地方，這種概念漂移是眾所周知的（單詞語義，垃圾郵件檢測器），但“概念”漂移可能發(fā)生在任何領(lǐng)域。例如，口罩和社會疏遠法規(guī)也挑戰(zhàn)了許多先前部署的計算機視覺模型。

常見的反模式是將這些示例歸因于噪聲，并希望情況隨著時間的推移而趨于穩(wěn)定。這不僅意味著缺乏行動，而且還包括錯誤的歸因，在數(shù)據(jù)驅(qū)動的業(yè)務(wù)中通常應(yīng)避免這種歸因。稍微好一點的反模式是通過快速重新培訓(xùn)和部署新模型來對報告做出反應(yīng)。即使在團隊假設(shè)他們遵循敏捷軟件開發(fā)原則并因此選擇對變化做出快速反應(yīng)的情況下，這也是一種反模式。問題在于該解決方案可以解決癥狀，但不能解決系統(tǒng)設(shè)計中的缺陷。

設(shè)計模式是對性能的連續(xù)評估，這意味著您預(yù)計會發(fā)生漂移，因此，請設(shè)計系統(tǒng)以使其盡快注意到。這是一種完全不同的方法，因為重點不是反應(yīng)速度而是檢測速度。這使整個系統(tǒng)處于更加受控的過程中，從而為任何反應(yīng)的優(yōu)先級分配了更大的空間。持續(xù)評估意味著建立流程和工具，以不斷為一小部分新數(shù)據(jù)生成基本事實。在大多數(shù)情況下，這涉及手動標(biāo)簽，通常使用眾包服務(wù)。但是，在某些情況下，我們可以使用其他更復(fù)雜的方法，但是在部署環(huán)境中，不可行的模型和設(shè)備會生成地面真相標(biāo)簽。例如，在自動駕駛汽車的開發(fā)中，一個傳感器（例如LiDAR）的輸入可用于生成另一傳感器（例如攝像機）的地面真實情況。

機器學(xué)習(xí)的SOLID設(shè)計原則

我之所以寫設(shè)計模式，是因為該領(lǐng)域已經(jīng)達到成熟水平，我們不僅應(yīng)該分享我們的最佳實踐，而且還應(yīng)該能夠?qū)⑺鼈兂橄鬄閷嶋H的設(shè)計模式。幸運的是，這項工作已經(jīng)由多個小組開始。實際上，最近有兩本關(guān)于主題[ 1 ]，[ 2 ]的書出版了。我很喜歡閱讀它們，但我仍然感到，盡管我們朝著正確的方向前進，但距離為ML從業(yè)人員制定SOLID設(shè)計原則還差幾步之遙。我相信，雖然已經(jīng)掌握了基礎(chǔ)知識，并已用于構(gòu)建當(dāng)今的支持AI的產(chǎn)品，但設(shè)計模式和反模式的工作是邁向軟件2.0時代的重要一步。