引用
Humbatova N, Jahangirova G, Bavota G, et al. Taxonomy of real faults in deep learning systems[C]//Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering. 2020: 1110-1121.
Abstract深度神經網路在安全關鍵（safety-critical）領域的應用日益廣泛，這使得對此類系統中發生的錯誤進行分析變得非常重要。在本文中，我們介紹了深度學習（DL）系統中的一個大的錯誤分類。我們已經手動分析了 1059 個從 GitHub 提交和使用最流行的 DL 框架（TensorFlow、Keras 和 PyTorch）的專案問題以及相關的 Stack Overflow 帖子中收集的問題。我們對 20 名研究人員和實踐者的結構化訪談，描述了他們在他們的經驗中遇到的問題，這使我們的分類更加豐富，並增加了其他兩個來源中沒有出現的各種錯誤。我們的最終分類透過一項調查得到了驗證，該調查涉及額外的 21 名開發人員，保證了至少有 50%的調查參與者都經歷過幾乎所有的錯誤類別（13/15）
1. Introduction深度學習（DL）正逐漸進入科學和工業中越來越多的領域。它的應用範圍包括支援日常活動，如將語音轉換為文字、將文字從一種語言翻譯到另一種語言，以及更為關鍵的任務，如信用卡公司的欺詐檢測、醫療領域疾病的診斷和治療、車輛的自動駕駛。安全關鍵系統對 DL 網路的依賴性日益增加，這類系統中可能發生的錯誤型別成為一個重要的課題。然而，DL 系統中的錯誤概念比傳統軟體更為複雜。事實上，構建 DL 網路的程式碼可能沒有 bug，但是由於在訓練階段引入的錯誤，例如某些學習引數的錯誤配置或使用不平衡/非代表性的訓練集，網路仍然可能偏離預期的行為。
本文的目標是建立 DL 系統中實際錯誤的分類。主題 DL 系統的一個例子可以是自主汽車中的目標檢測子系統。這樣的分類可以幫助開發人員避免常見的缺陷，或者可以作為測試人員的檢查表，激勵他們定義解決特定錯誤型別的測試場景。我們認為，當 DL 元件的行為不適合手頭的任務時，就發生了 DL 錯誤（i.e.,根據 ISO/PAS 21448:2019[6]的規定，這是“功能不足”），這種缺陷的根本原因是在 DL 開發和培訓過程中發生的人為錯誤。由於與真實錯誤的相似性是人工注入錯誤的一個重要特徵，因此該分類也可用於錯誤播種（fault seeding）。
分類學主要是一種分類機制[28]。分類學主要是一種分類機制[28]。根據 Rowley 和 Farrow[22]，分類方法主要有兩種：列舉式和分面式。在列舉分類中，類是預定義的。然而，在不成熟或不斷髮展的領域中很難列舉所有類，這就是 DL 系統的情況。因此，使用經過審查的錯誤分類[13]不適合我們的目的。相反，在分面分類中，類的新特徵可以被擴充套件和組合。為此，我們使用了分面分類，即透過分析有關 DL 錯誤的各種資訊源，以自下而上的方式建立了分類的類別/子類別。
我們的方法基於對非結構化來源和訪談的手動分析。我們首先手動分析 477 個 Stack Overflow（SO）討論和 GitHub 中 271 個問題和拉取請求（pr）和 311 個提交。在這些討論中，開發人員討論/修復在使用三個流行的 DL 框架時遇到的問題。手動分析的目的是找出問題背後的根本原因。這個步驟的輸出是第一個與 DL 框架的使用相關的錯誤的層次分類。然後，兩位作者採訪了 20 位研究人員和實踐者，以收集他們在使用 DL 框架方面的經驗。所有的採訪都被錄音和轉錄，允許在所有作者之間開放編碼程式，透過這個程式，我們可以識別被採訪者提到的錯誤類別。這使得我們可以補充我們的初步分類併產生它的最終版本。
為了驗證我們的最終分類，我們進行了一項調查，另外 21 名研究人員/實踐者對此作出了迴應。在調查中，我們包括了分類的類別以及它們所代表的錯誤型別的描述，並要求參與者指出在開發 DL 系統時，這些錯誤是否在他們以前的經驗中遇到過。大多數錯誤（13/15）發生在 50%或更多的參與者身上，沒有一個錯誤類別是未經驗證的（24%的參與者確認了最低頻率的類別）。
本文的主要貢獻是對 DL 系統中的實際錯誤進行了有效的分類。據我們所知，我們是最先做這個工作的，包括與開發人員就與 DL 系統開發相關的錯誤進行訪談。如果沒有這樣的訪談，分類學的 2 個內部節點和 27 個葉節點將完全丟失。其他幾個節點在訪談中有很高的代表性，但它們很少出現在其他被分析的人為現象（artefact）中。
2. Methodology2.1 Manual Analysis of Software Artefact為了得到我們最初的分類，我們考慮了三個最流行的 DL 框架[2]，TensorFlow，Keras 和 PyTorch。我們使用 TensorFlow、Keras 或 PyTorch 手動分析了四種資訊來源：提交、問題、來自 GitHub 儲存庫的請求請求（pull requests，PRs），以及與這三種框架相關的討論。
2.1.1 Mining github我們使用 GitHub 搜尋 API 來識別使用我們研究的三個 DL 框架主題的程式碼庫。API 將搜尋字串作為輸入，並從 GitHub 儲存庫中獲取與搜尋查詢匹配的原始碼檔案。例如，在 Python 中，可以使用 import TensorFlow as tf 語句匯入 TensorFlow。因此，我們使用搜索字串“tensorflow”來標識使用 tensorflow 的所有 Python 檔案。顯然，這可能導致大量誤報，因為字串“tensorflow”可能由於其他原因出現在原始檔中（例如，作為字串文字的一部分）。然而，此搜尋的目標只是使用這三個框架來識別候選專案，並且在後續步驟中排除誤報。我們定義的搜尋字串是“tensorflow”、“keras”和“torch”。我們將搜尋限制為使用了”language:Python”引數的 Python 原始檔。
使用 GitHub 搜尋 API 時，一個請求最多可以返回 1000 個結果。為了克服這個限制，我們生成了幾個請求，每個請求都有一個特定的大小範圍。我們用了大小：min..max 引數只檢索特定大小範圍內的檔案。透過這種方式，我們將返回結果的數量增加到 1000×n，其中 n 是考慮的大小範圍的數量。對於每個搜尋字串，我們搜尋大小從 0 到 500000 位元組的檔案，步長為 250 位元組。總的來說，我們生成了 6000 個搜尋請求，每個框架有 2000 個。
對於每個檢索到的 Python 檔案，我們標識了相應的 GitHub 程式碼庫，並提取了相關的屬性，如：提交數、貢獻者數、問題數/pr、star 數[3]和 fork 數[4]。然後，我們排除了：（i）個人程式碼庫，分類為擁有少於 5 個貢獻者的程式碼庫；（ii）不活動的程式碼庫，即沒有未解決的問題；（iii）具有瑣碎歷史的程式碼庫，即少於 100 個提交；以及（iv）不受歡迎的程式碼庫，我們將其定義為少於 10star，10fork 的程式碼庫。
這一過程最終選擇了 151 個 TensorFlow 專案、237 個 Keras 專案和 326 個 Pytorch 專案。然後，其中一位作者檢查了選定的程式碼庫，目的是排除教程、書籍或程式碼示例集合，不代表開發人員在實踐中使用的真實軟體系統，以及誤報（即，專案在其 Python 檔案中包含搜尋字串，但實際上沒有使用相關框架）。
這個過程給我們留下了 121 個 TensorFlow、175 個 Keras 和 268 個 Pytorch 專案。對於每個保留的 564 個專案，我們收集了可能與解決問題/討論問題相關的問題、pr 和提交。對於問題和 pr，我們使用 GitHub API 檢索所有標記為 bug、缺陷或錯誤的內容。對於提交，我們挖掘了程式碼庫的更改日誌，以識別所有包含模式[15]：（“fix”或“solve”）和（“bug”或“issue”或“problem”或“defect”或“error”）的訊息。
然後，對於每個框架，我們選擇了 100 個專案樣本進行手動分析。我們沒有隨機選擇，而是選擇了 issue 和 PR 數量最多的那些。。對於不到 100 個專案至少有一個相關 issue/PR 的框架，我們選擇剩餘的專案，按照相關提交的數量對它們進行排序（即，與上述模式匹配的提交）。100 個選定的專案共涉及 8577 個 issue 和 PR 以及 28423 個提交。
2.1.2 Mining Stack Overflow我們使用 StackExchange Data Explorer[9]獲得了與 TensorFlow、Keras 和 PyTorch 相關的 SO 帖子列表。StackExchange Data Explorer 是一個 web 介面，允許對來自 Q&A 站點的資料執行 SQL 查詢，包括 SO。對於每個框架，我們建立了一個查詢來獲取相關帖子的列表。我們首先檢查一個框架的名稱是否顯示在帖子的標籤中。然後，我們過濾掉標題中包含“如何”、“安裝”或“構建”的帖子，以避免一般的操作問題和要求安裝說明。我們還排除了沒有被接受答案的帖子，以確保我們只考慮有確定答案的問題。結果，我們為 Tensorflow 獲得了 9935 個帖子，為 Keras 獲得了 3116 個帖子，為 Pytorch 獲得了 653 個帖子。我們根據帖子的瀏覽次數對每個查詢的結果進行排序。然後，為了選擇可能解決最相關錯誤的帖子，我們選擇了前 1000 篇瀏覽量最高的帖子（總共 2653 篇）。
2.1.3 Manual Labeling從 GitHub 和 SO 收集的資料由所有作者按照開放編碼程式進行手動分析[23]。我們開發了一個 web 應用程式來支援標記過程，該應用程式用於對文件進行分類（即，描述問題背後的原因）並解決作者之間的衝突。每個作者都透過定義一個描述錯誤的標籤來獨立地標記分配給她的文件。在標記期間，web 應用程式顯示已建立的標籤列表，如果現有標籤應用於正在分析的錯誤，則評估者可以使用這些標籤。儘管原則上，這與開放編碼的概念相違背，但對 DL 錯誤的瞭解仍然很少，而且可能的標籤數量可能會過度增長。因此，這樣的選擇是為了幫助編碼人員使用一致的命名，而不引入實質性的偏差。
作者遵循嚴格的程式處理特殊情況。具體而言，（i）我們將任何分析過的 artefact 標記為false positive，這些 artefact 要麼與任何問題修復活動無關，要麼恰好是框架本身而不是 DL 系統中的問題。（ii）如果所分析的 artefact 涉及修復，但錯誤本身不是 DL 系統特有的，而是一種常見的程式設計錯誤（例如 for 迴圈中錯誤的停止條件），我們將其標記為generic。（iii）如果 artefact 與問題修復活動有關，並且它是 DL 系統特有的，但評估者無法追溯問題的根本原因，則分配了unclear的標籤。
標記過程包括六個回合，每一輪之後，所有作者都會開會討論這個過程並解決衝突。表 1 報告了六輪標記中每一輪的統計資料，包括：（i）由至少兩名作者分析的 artefact 的數量；（ii）在下一次會議上解決衝突的 artefact 的數量；（iii）收到標識與 DL 系統相關錯誤的標籤的 artefact 的數量；（四）錯誤分類學中新的 top/inner/leaf 的數量。
在前三輪中，我們共定義了 21 個（5+11+5）葉類，將 35 個與 DL 相關的人工製品分組。隨著第四輪中類別數量的增加，我們開始建立層次分類（參見圖 1），內部節點將類似的“葉類別”分組。
表 1 顯示了按級別組織的第四、第五和第六輪建立的內部類別的數量（第一級類別是最普遍的）。我們跟蹤標記過程中產生的內部類別的數量，並決定在新的標記輪不建立任何新的內部類別時停止該過程。
2.2 Developer InterviewsDL 與傳統系統不同，它們的決策邏輯不僅由原始碼決定，而且還由訓練階段和 DL 模型的結構（例如，層數）決定。雖然 SO posts 和 GitHub artefact 是我們研究的有價值的資訊來源，但這些平臺的性質限制了報告的問題主要是程式碼級別的問題，因此可能會排除在模型定義或訓練期間遇到的問題。為了更全面地瞭解這一情況，我們採訪了 20 位具有不同背景和專業水平的研究人員/實踐者，重點討論了基於 DL 的系統開發過程中遇到的錯誤型別。
2.2.1 Participant Recruitment為了對實際 DL 系統開發中出現的問題有一個平衡而普適的看法，我們讓兩組開發人員參與進來：研究人員和實踐者。在前一組中，我們將頻繁使用 DL 的博士生、博士後和教授作為他們研究的一部分。第二組受訪者包括在行業工作的開發人員或自由職業者，對他們來說，開發 DL 應用程式是他們的主要專業領域。
我們利用了三種不同的候選來源來吸引參與者。首先，我們透過私人聯絡選出候選人。在 39 位開發者中，有 20 位是透過電子郵件聯絡到的。我們收到了 9 名研究人員和 3 名從業人員的 12 份肯定答覆。為了平衡研究人員和從業人員之間的比例，我們參考了其他兩個候選來源。其中一個來源是 Stack Overflow，他們的熱門回答者是經驗豐富的 DL 開發人員，他們有能力幫助其他開發人員解決反覆出現的 DL 問題。為了訪問最熱門的回答者，我們參考了與標籤相關的統計資料，這些標籤代表了我們研究的三個框架。我們使用了“過去 30 天”和“所有時間”兩個類別的最佳回答者，並從這兩個類別中為每個標籤（DL 框架）選擇了前 10 名回答者，結果總共有 60 名候選人。
由於沒有內建的聯絡方式，所以無法與入圍的 60 位使用者全部取得聯絡。我們設法找到了其中 17 人的電子郵件地址，這些地址來自使用者在 SO 個人資料上留下的個人主頁連結。在 17 個接觸的使用者中，我們收到了 6 個回覆，其中 4 個是積極的回覆（分為 3 個從業者和 1 個研究人員）。
另一個來源是 Upwork[10]，一個大型的自由職業者平臺。我們在 Upwork 網站上建立了一個招聘啟事，上面描述了採訪過程。這個職位只限於受邀的公眾。根據以下標準選擇受邀候選人：（i）候選人簡介應代表個人和非公司；（ii）候選人的職位應與公司相關；（iii）候選人最近完成的專案大部分應與 DL 相關；（iv）候選人的 Upwork 成功率應高於 90%；（v）應徵者在 Upwork 平臺上的收入應超過 10000 美元。從發出的 23 份邀請函中，有 5 名候選人接受了邀請，但其中一人後來被排除在外，他是一個開發團隊的經理，而不是開發人員本人。
總的來說，參與者招募程式給我們留下了 20 個成功的採訪，平均分配給研究人員和實踐者（每組 10 個）。有關參與者的 DL 經驗分享的詳細資訊，請參閱我們的 replication package[8]。就“總體編碼經驗”而言，在受訪候選人中，最低值為 2.5 年，最高值為 20 年（中位數=5.4）。至於 DL 特定的“相關經驗”，範圍從 3 個月到 9 年（中位數=3）。
被採訪者使用 Python 作為主要的程式語言來開發 DL 應用程式，其中有幾個也用到了 MATLAB、R、java、Scala、C++和 C#。關於 DL 框架的使用，TensorFlow 被提到了 12 次，Keras 11 次，PyTorch 8 次。受訪者的專業領域涵蓋了廣泛的領域，從金融和機器人到法醫學和醫學成像。
2.2.2 Interview Process因為我們是從頭開始建立一個分類，而不是將問題和問題分類到一些已知的結構中，採訪問題必須儘可能通用和開放。我們選擇了半結構化的訪談[23]，它將開放式問題（引出意想不到的資訊型別）與具體問題（將訪談保持在範圍內，並向受訪者提供特定問題）相結合。
在半結構化採訪中，採訪人需要根據受訪者的回答即興提出新問題，這可能是一項具有挑戰性的任務。因此，有一個額外的採訪人是必要的，他可以提出後續問題，並在需要時為主採訪人提供幫助。因此，我們的採訪由兩位採訪人同時進行，但角色不同：一位負責訪談，另一位則在適當的時候提出附加問題。在所有采訪中，每個角色都由同一人扮演。霍夫等人的工作[16] 研究顯示，當由兩名而不是一名採訪人進行採訪時，一半的受訪者會說更多的話。在我們的經驗中也是如此，因為在所有的採訪中，第二位採訪人至少會問兩個額外的問題。
在收集了受訪者的一般和特定於 DL 的程式設計經驗的資訊後，我們繼續進行採訪指南[8]中的問題。
我們的第一個問題非常籠統，措辭是“在開發 ML/DL 系統時，您遇到過哪些型別的問題和 bug？”. 我們提出這個問題的目的是儘可能開放性地提出這個話題，讓受訪者在談論自己的經歷的同時，又不把自己引向任何具體的錯誤。然後，我們繼續進行更具體的問題，跨越非常廣泛的 DL 主題，如訓練資料、模型結構、超引數、損失函式和使用的硬體。我們詢問受訪者是否遇到過與這些話題相關的問題，然後，如果答案是肯定的，我們繼續提出更詳細的問題，以瞭解相關的錯誤。
我們所有的採訪都是遠端進行的（使用 Skype 影片通話），只有一次是面對面進行的。採訪時間在 26 到 52 分鐘之間，平均 37 分鐘。每次採訪兩位採訪人中的一位也記錄員。對於記錄，我們使用了 Descript[1]，一種自動語音識別工具，可以將音訊/影片檔案轉換為文字。自動記錄完成後，記錄員會進行檢查，並在需要時進行手動更正。
2.2.3 Open Coding為了對轉錄的訪談進行公開編碼，每個訪談都分配了一名主持人和兩名評估員。主持人總是採訪者之一。第一個評價者是另一個採訪者，而第二個評價者是沒有參加採訪的作者之一。每個評估者的角色是執行開放編碼任務。相比之下，主持人的作用是識別和解決評價者之間標記不一致的文字片段（例如，同一文字片段上附加的不同標籤）。我們決定讓採訪人在這項任務中扮演兩個角色（評估者和主持人），因為他們更瞭解訪談的內容和背景，已經接觸到了與受訪者溝通的非正式和元方面。第二位沒有參與訪談的評估者確保了不同觀點的存在。
20 次採訪平均分配給沒有參加採訪過程的作者。每個採訪人都是 10 次採訪的評估者和剩下 10 次採訪的主持人。開放編碼是在 GoogleDocs 線上工具中手動執行的。評估者標記了 297 條文字。其中，只有 6 個文字衝突，評估者在同一文字片段上附加了不同的標籤。此外，有 196 個文字中，一個評估者在文字片段上加了標籤，而另一個沒有。在這些文字中，有 146 個文字由主持人保留，其餘文字則被丟棄。透過這個過程，提取出 245 個最終標籤。每次採訪的標籤數量在 5 到 22 個之間，平均 12 個標籤。
2.3 Taxonomy Construction and Validation為了構建分類，我們使用了自底向上的方法[29]，我們首先將與相似概念對應的標籤分組到類別中。然後，我們建立父類別，確保類別及其子類別遵循“是”關係。分類的每個版本都由所有作者在與每輪標記工作相關的會議上討論和更新。在構建過程的最後，在一次會議上，作者一起討論了最終分類的所有類別、子類別和葉子節點，以進行最後的微調整。
為了確保分類能夠全面、全面地反映出真實的 DL 錯誤，我們透過一項涉及新的從業者/研究人員的調查對其進行了驗證，這些從業者/研究人員與參與訪談的人不是同一批人。
為了招募參加調查的候選人，我們採用了與採訪過程相同的策略和選擇標準（第 3.2.1 節）。我們接觸的第一批候選人來自作者的私人聯絡。我們聯絡了最初名單上剩下的 23 個人，其中 13 人實際填寫了調查。第二組和第三組候選人分別來自 SO 和 Upwork。從 SO 平臺中，我們從“過去 30 天”和“所有時間”兩個類別中選出了前 20 名的回答者，分別對應於三個我們研究的框架。我們從 120 名使用者中剔除了那些已經聯絡過的使用者。在剩下的候選人中，我們只能獲得 20 名使用者的聯絡方式。我們聯絡了他們，其中 4 人已經完成了調查。對於 Upwork 組，我們建立了一個新的招聘公告，每個工作完成後固定支付 10 美元，並向 26 個使用者發出了報價。他們中有四個人完成了調查。總體而言，有 21 名參與者參與了我們的調查（10 名研究人員和 11 名從業者），他們的總體編碼經驗最少為 1 年，最多為 20 年（中位數=4）。關於相關的 DL 經驗，最少為 1 年，最多為 7 年（中位數=3）。
為了建立我們的調查表格，我們使用了 Qualtrics[7]，一個基於網路的工具來進行調查研究、評估和其他資料收集活動。我們開始調查時提出了與採訪中相同的背景問題。然後，我們繼續討論與我們最後的分類有關的問題。把整個分類結構放在調查的一個圖表中會使閱讀和理解變得過於複雜，因此，我們按照內部類別對其進行劃分，當它不是太大的時候選擇最頂端的內部類別，或者當它是一個大類別的時候選擇它的後代。
對於分類中的每個內部類別的劃分，我們建立了一個文字描述，包括其葉標籤的示例。在調查表格中，我們給出了類別的名稱、文字描述，然後是與之相關的三個問題。第一個問題是一個“是”或“否”的問題，關於參與者是否遇到過這個問題。在肯定回答的情況下，我們還有兩個 Liker-scale 的問題，關於問題的嚴重性以及識別和修復它所需的工作量。透過這種方式，我們不僅評估了分類錯誤的發生，還評估了開發人員感知到的錯誤嚴重性。
在調查的最後一部分，我們以自由文字的形式要求參與者列出他們遇到但在調查中沒有提及的與 DL 相關的問題。透過個方式我們可以檢查我們的分類是否涵蓋了開發人員經歷過的所有錯誤，如果沒有，我們可以找出缺少的內容。
3. Result3.1 The Final Taxonomy最終分類分為 5 個頂級類別，其中 3 個進一步劃分為內部子類別。完整的分類如圖 1 所示。在每一次採訪中，用一個編號和一個編碼符號分別在一個類別和兩個編碼後分配給該類別的位置。
Model 這個類別涵蓋了與 DL 模型的結構和屬性相關的錯誤。
Model Type & Properties 此類別考慮影響模型整體的錯誤，而不是其單個方面/元件。其中一個錯誤是模型型別的錯誤選擇，例如，在需要後者的任務中使用遞迴網路而不是卷積網路時。此外，還存在一些模型初始化不正確的情況，這會導致梯度的不穩定性。這一類別的另一個常見缺陷是使用的層太少或太多，導致網路結構不理想，進而導致模型的效能較差。我們的一位受訪者提供了一個例子：“當我們開始的時候，我們認為在編碼器和解碼器中至少需要四個層，然後我們最終擁有了其中的一半，就像實際上非常淺的模型，它甚至比更大更深層的模型更好”。
Layers 這類錯誤會影響神經系統的某一特定層網路。這是一個更大的分類分為以下三個內部子類別：
Missing/Redundant/Wrong Layer 這些錯誤表示需要新增、刪除或更改特定層的型別來彌補網路的低精度。在這一類中，與區域性最優模型不同的是區域性最優解，而不是區域性最優模型。我們通常把這種型別的被採訪者描述為一個錯誤的層次，而不是一個錯誤的層次。Layer Properties 這一類表示由於某些層的內部屬性不正確而導致的錯誤，例如它的輸入/輸出形狀、輸入樣本大小、其中的神經元數量。根據被採訪者的描述，“我們設定了太多的神經元，而且我們的訓練和驗證都很慢”。Activation Function 神經網路的另一個重要方面是神經元的啟用功能。如果選擇不當，它會極大地破壞模型的效能。一位受訪者指出，“當我把語音識別中的 sigmoid 啟用函式變為線性啟用函式時，這給了我一個收穫”。Tensors & Inputs 此類別處理與錯誤的資料形狀、型別或格式有關的問題。我們在這一類中遇到了兩類不同的錯誤：
Wrong Tensor Shape 在對形狀不相容的張量或形狀定義不正確的單個張量進行操作時，會出現錯誤行為。如圖 1 所示，錯誤的張量形狀有許多可能的原因，例如，缺少輸出填充、缺少索引，或者，正如在一次訪談中所提供的那樣，開發人員“正在使用張量的轉置版本而不是普通張量”。Wrong Input 錯誤行為是由於格式、型別或形狀不相容的資料用作層或方法的輸入。方法的錯誤輸入是傳統軟體和 DL 程式設計中經常遇到的問題。然而，在 DL 中，這些錯誤恰好具有特定的性質，從輸入具有意外的資料型別（例如，字串而不是 float）或形狀（大小為 5x5 而不是 5x10 的張量）到輸入格式完全錯誤的情況（例如，錯誤的資料結構）。Training 這類訓練中最大的問題是訓練質量的最佳化，而這類訓練中的引數選擇是與訓練質量有關的。它還解釋了在測試/驗證之前訓練過的模型時發生的錯誤。
Hyperparameters 開發人員在調整 DL 模型的超引數時面臨大量問題。報告的錯誤超引數最多的是 learning rate、batch size 和 epoch。雖然這些引數的次優值不一定會導致崩潰或錯誤，但它們會影響訓練時間和模型實現的總體效能。採訪中的一個例子是“當學習率從 1 個或 2 個數量級改變時，我們發現它會影響 10%到 15%的準確率”。Loss Function 此類別包含與損失函式相關的錯誤，特別是其選擇和計算。損失函式的錯誤選擇或預定義損失函式的使用可能不足以代表模型預期實現的最佳化目標。反過來，當實現自定義損失函式時，會發生損失函式的錯誤計算，並且在實現過程中的某些錯誤會導致次優或錯誤行為。正如一位受訪者所指出的，他們需要“得到一個更平衡的損失函式，而不僅僅是那些能夠很好地預測一個類，然後搞亂其他類的東西”。Validation/Testing 它包括與測試和驗證訓練模型相關的問題，例如效能指標的錯誤選擇或錯誤地將資料分割為訓練和測試資料集。Preprocessing of Training Data 訓練資料集的預處理是一個勞動密集型的過程，它會顯著影響 DL 系統的效能。這反映在這一類元素的數量多，種類多，葉數多。在抽象層面，我們將這類錯誤分為兩組：缺少預處理和錯誤預處理。前一種情況是指一個可以提高效能的預處理步驟根本沒有被應用。在後一種情況下，實際上已經應用了預處理步驟，但要麼是不合適的型別，要麼是應用的方式不正確。最常見的例子是缺少標準化步驟、缺少輸入縮放或子取樣以及錯誤的畫素編碼。值得注意的是，訓練資料的預處理步驟很大程度上依賴於一個應用領域。這就解釋了這一類中葉標記的多樣性。由於空間不足，我們不得不在分類圖中省略其中一些。Optimiser 此類別與為模型訓練選擇不合適的最佳化函式有關。錯誤地選擇最佳化器（例如，Adam 最佳化器而不是隨機梯度下降）或其引數的次優調整（對於 Adam 最佳化器來說，ε 太低）可能會破壞模型的效能。Training Data Quality 在這一組中，所有與訓練資料質量相關的方面。一般來說，由於資料的複雜性以及需要手動操作來確保高質量的訓練資料（例如，標記和清理資料、刪除異常值）會導致問題的發生。更具體的資料收集挑戰包括醫療領域的隱私問題和不斷變化的網頁使用者介面，從中自動收集資料。所有這些都導致了這一類別中最常見的問題，即訓練資料不足。這個問題的一個變體是不平衡的訓練資料，其中資料集中的一個或多個類被低估了。此外，為了得到一個好的分類模型，必須確保為訓練資料提供正確的標籤。然而，在受訪者的經驗中，給訓練資料貼上錯誤的標籤是一個常見而惱人的問題。與訓練資料質量有關的一系列其他問題，例如缺乏標準格式、資料缺失或存在不相關的資料（例如，來自其他域的影象）被集中在一個相當普遍的標籤“訓練資料質量低”，因為具體問題取決於應用領域。Training Process 這一類別代表了開發人員在模型訓練過程中所面臨的錯誤，例如錯誤地管理記憶體資源或缺少資料擴充。它還包含一些葉子，表示在模型恢復過程中，模型太大，無法放入可用記憶體或引用不存在的檢查點。關於資料擴增，其中一位受訪者指出，這有助於“使資料更真實，以便在微光環境下更好地工作”，而另一位受訪者則表示，有時會向資料集新增更多圖片，結果可能會面臨網路過擬合的問題。因此，有時資料擴增會有所幫助，有時可能造成損害。GPU Usage 這個頂級類別收集了在使用 DL 時與 GPU 裝置的使用有關的各種錯誤。在這個例子中沒有進一步的劃分，因為我們發現的所有例子都代表了非常具體的問題。
這一類的一些亮點是：錯誤地引用 GPU 裝置，失敗的並行性，子程序之間不正確的狀態共享，錯誤地將資料傳輸到 GPU 裝置。
API 這一部分代表了由框架的 API 使用引起的一大類問題。最常見的是 API 使用錯誤，這意味著開發人員使用 API 的方式不符合框架開發人員設定的邏輯。另一個示例可能是丟失或位置錯誤的 API 呼叫。
對於生成的分類的每個內部節點，我們計算了在執行時可檢測到的導致 SO/GIT 錯誤的百分比（即導致崩潰或錯誤）。我們在計算中沒有考慮訪談，因為在許多情況下，我們不知道錯誤是否導致了崩潰/錯誤。分類的張量和輸入分支包含的節點中此類錯誤的比例最高，具體來說，錯誤輸入的節點數為 100%、86%和 80%，Wrong Tensor Shape的節點數為 76%。另一個由相關錯誤引起的大量崩潰/錯誤的類別是Model分支（85%）和API分支（80%）的Layer properties節點。
3.2 Contributions to the Taxonomy最終的分類是使用從兩個不同的資訊源提取的標籤構建的：SO&GitHub artefact 和研究人員/從業者訪談。從 SO&GitHub 獲取的前 5 個標記及其各自的出現次數（顯示為 NN+MM，其中 NN 指 SO&GitHub；MM to interviews）是 wrong tensor shape（21+5）、wrong shape of input data for a layer（16+2）、missing preprocessing（11+22）、wrong API usage（10+0）以及wrong shape of input data for a method（6+0）。
在採訪中，前 5 位的標籤分別是missing preprocessing（11+22）、suboptimal network structure（1+15）、wrong preprocessing（2+15）、not enough training data（0+14）和wrong labels for training data（1+12）。這些列表只有一個標籤的交集（missing preprocessing）。前 5 個 SO&GitHub 列表包含兩個在其他源中沒有出現的標籤（wrong API usage、wrong shape of input data for a method）。前 5 名採訪列表包含一個這樣的標籤（not enough training data）。此外，這兩個來源之間的出現次數是不平衡的：對於前 5 個 SO&GitHub 標籤，出現的次數是 64+29 次，而對於前 5 個採訪標籤，出現的次數變成了 15+78 次。這表明這兩個選擇的來源是相當互補的。
實際上，這些資訊來源之間的互補性反映在整個分類結構中。如果我們考慮分類中的五個頂級類別（即分類中根節點的五個直接子類），我們可以找到一個訪談標籤根本沒有參與的類別，即API類。這可能是因為 API 相關的問題是特定的，因此，在訪談中並沒有出現這些問題，因為受訪者往往會談論更一般的問題。類似地，在GPU Usage類中只有一個採訪標籤。Tensors&Inputs是另一個由 SO&GitHub 標籤控制的類別，其數量是採訪標籤數量的兩倍。相比之下，Model類別的主要貢獻者是訪談。
最大的不同是在Training類，其中採訪貢獻了 4 倍多的標籤，這導致增加了兩個子類別。只有在採訪中才會出現與訓練相關的錯誤，因為這類問題通常無法透過在 SO 上提問或在 GitHub 上公開問題來解決。在 18 個 pre-leaf 類別中，一個由 SO&GitHub（API）提供的標籤組成，另一個僅由訪談（Training Process）提供的標籤組成。另一個 pre-leaf 分類（Training Date Quality）是在收集了大量訪談資料後，從現有的少量葉子中提取出來的。剩下的 16 個由兩個來源組成，其中 6 個的 SO&GitHub 標籤數量較高，8 個採訪標籤數量較高，2 個標籤數量相同。
3.3 Validation Results表 2 總結了驗證調查的結果。對於每一個類別，我們報告“是”和“否”回答的百分比，詢問參與者是否遇到過相關問題。我們還顯示了每個故障類別的嚴重性以及識別和修復此類故障所需的代價。沒有調查參與者在他們的經驗中從未遇到過的錯誤類別，這證實了分類中的所有類別都是相關的。最受認可的類別是Training Data，95%的“是”。根據受訪者的說法，這一類別的嚴重程度為“嚴重”，需要付出“高”代價的參與者分別為 61%和 78%。最不被認可的類別是Missing/Redundant/Wrong Layer，24%的調查參與者都經歷過這種情況。在所有類別中，“是”答案的平均比率為 66%，表明最終分類包含的類別與大多數參與者的經驗相匹配（只有兩個類別低於 50%）。參與者在所有調查中平均確認了 9.7 個類別（共 15 個類別）。
一些參與者提供了一些他們認為不屬於現有分類的錯誤示例。其中三個是通用的編碼問題，而一個參與者描述了錯誤的影響，而不是其原因。
剩下的三個實際上可以放在我們的分類中的 missing API call、wrong management of memory resources和wrong selection of features。我們認為參與者無法在分類中找到合適的類別，因為調查中的描述沒有包括足夠的與他們的具體經驗相符的範例。
4. Conclusion我們根據對 1059 個 github&SO artefact 和對 20 名開發人員的訪談，構建了一個真正的 DL 錯誤的分類。該分類由 5 個主要類別組成，包括 92 個獨特型別的 375 個例項。為了驗證分類，我們對 21 名不同的開發人員進行了一項調查，他們確認了所識別類別的相關性和完整性。在我們未來的工作中，我們計劃使用所提出的分類作為指導來改進 DL 系統測試，並作為定義新的變異運算元的來源。