IBM推出DeepTriage，利用深度學習實現Bug自動分類
作者｜Senthil Mani 等
譯者｜Debra
編輯｜Emily
AI 前線導讀：當系統給出軟體 bug 報告的時候，第一件應該做的事是選擇一個合適的開發人員來修復這個 bug，也是執行 bug 分類過程的首要任務。大多數 bug 跟蹤系統都有 bug 標題（摘要）和詳細描述。bug 自動分類演算法可以被視作分類問題，它將 bug 標題和描述作為輸入，將其反饋給開發人員（類標籤）。這個過程的主要挑戰是 bug 描述通常包含很多非結構化的文本、代碼片段和堆棧跟蹤，使得輸入數據非常雜亂。而目前的詞庫（BOW）特徵模型不考慮非結構化文本的句法和詞序信息。
在本研究中，我們提出了一種基於注意機制的深度雙向遞歸神經網路（DBRNN-A）的新型 bug 報告表示演算法，該模型可以無監督的方式從長字序列中學習句法和語義特徵，然後使用基於 DBRNN-A 的 bug 表示來訓練分類器，而不是用 BOW 特徵。使用注意機制可以使模型學習 bug 報告中長詞序列的上下文表示。未修復的 bug 報告（在開放源代碼 bug 跟蹤系統中佔比約 70％）為本研究做出了重要貢獻，為訓練特徵學習模型提供了大量數據，而它們在之前的研究中幾乎完全被忽略。另外，三個開源 bug 跟蹤系統（Google Chromium，Mozilla Core 和 Mozilla Firefox）提供的開源代碼構建了我們的 bug 報告公共基準數據集，讓這個實驗具有可重複性。在此實驗中，我們使用來自 Google Chromium 的 383,104 個 bug 報告，Mozilla Core 的 314,388 個 bug 報告，以及來自 Mozilla Firefox 的 162,307 個 bug 報告數據，並對我們提出的方法與 BOW 模型和 softmax 分類器、支持向量機、樸素貝葉斯和餘弦距離進行比較，得到使用 DBRNN-A 進行分類的平均準確率。
更多乾貨內容請關注微信公眾號「AI 前線」，（ID：ai-front）
簡介
一般來說，當終端用戶在系統工作遇到 bug（也稱為錯誤或缺陷）會在 bug 跟蹤系統中報告該問題 [8]。
圖 1：Google Chromium 項目中的 bug 報告屏幕截圖，bug ID：638277。bug 報告通常由簡短摘要和詳細描述組成。
bug 報告通常包含 bug 摘要和詳細的描述，以及重新操作的步驟。bug 的固定格式還包含修復 bug 的開發人員，被稱為所有者。bug 分類的過程分為多個步驟，其中第一步主要是將 bug 分配給有可能解決這個 bug 的開發人員。因此，在本研究的其餘部分，bug 分類指的是為 bug 報告分配開發人員的任務 [1]。在大規模的系統中，有大量的輸入 bug，手動分析和修改 bug 報告是一項艱巨的任務。手動進行 bug 分類時，開發人員通常使用 bug 報告內容，報告主要包括摘要和描述。儘管此前已經有文獻探討了額外的輸入來源，例如 github 的開發者分析 [3] 和使用組件信息 [5]，但大多數研究工作仍集中在利用 bug 報告內容進行分類 [2] [14] [ 27] [28] [29] [32] [33]。使用 bug 報告內容，可以將 bug 自動分類制定為分類問題，並將 bug 標題和描述反饋給開發者（類標籤）。但是，bug 報告可能包含大量雜亂的文本信息，包括代碼片段和堆棧跟蹤詳細信息，如圖 1 所示。處理這種非結構化和有雜訊的文本數據是學習分類器面臨的主要挑戰。
bug 存儲庫的 bug 報告，用作訓練分類器的標籤模板。
激活示例
但是，根據 BOW 特徵，測試報告＃1 和訓練報告共有 12 個相同的字，測試報告＃2 和訓練報告則共有 21 個字。因此，BOW 模型將 id 為 616034 的測試 bug 報告誤分類的報告＃2 應該由 brettw@chromium.org 修復。bug 分類的原因是：（1）BOW 特徵模型認為句子是一個丟失單詞排序（上下文）的片語，（2）不考慮句子中同義詞之間的語義相似性。儘管 n-gram 模型考慮到了詞序的上下文，但是受到了高維和稀疏的數據 [12 的影響]。我們可以使用一個基於連續跳躍元語法，被稱為 word2vec [22] 的神經網路模型來學習詞語標記之間的語義相似性。這種模型依賴於分布假說，認為在句子中出現在同一語境中的辭彙具有語義意義。Ye 等人 [34] 使用 word2vec 建立了一個共享詞表示，用於代碼語言和描述語言中的詞語標記。word2vec 的主要缺點是它僅學習了單個單詞記號的語義表示，但是不會將一個單詞記號（如句子）的序列考慮在內。word2vec 的一個段落矢量 [19] 考慮了單詞的排序，但僅限於在小的語境中。
本文的其餘部分如下：第 2 節重點介紹了研究工作中涉及的主要研究問題和主要貢獻，第 3 節詳細介紹了包括深度學習演算法和分類器在內的方法，第 4 節討論了此次研究收集的實驗數據，第 5 節討論實驗結果和分析，第 6 節討論了一些可能推翻我們的結論結論的因素，第 7 節討論可以應用我們提出的特徵學習演算法解決問題的其他程序，第 8 節解釋了一些密切相關的工作成果，第 9 節以對未來的展望結束本文。
研究成果
從大量文本中學習語義表達（例如在 bug 報告的描述中），保留單詞的順序是一個具有挑戰性的研究課題。因此，我們提出了一種深度學習技術，它將以無監督的方式學習對 bug 報告內容進行簡潔和長度固定的表示，即直接使用數據學習表示，而無需手動完成特徵工程。本文研究的主要研究問題（RQ）如下：
（1）RQ1：使用深度學習來執行自動化 bug 分類是否可行？
這將使 gcc_toolchain從調用中轉發數值，而無需知道整個構建中所有被覆寫的構建參數。
未分類 bug 報告＃2：616034修正：machenb ... @ chromium.org標題：GN toolchain_args 應該是一個範圍，而不是一個函數說明：可以在谷歌瀏覽器中重寫 v8_use_external_startup_data 嗎？一方面，默認為 gn arg，這是正確的。另一方面，在 v8 中有一個「v8_use_external_startup_data =！is_ios」作為谷歌瀏覽器構建覆蓋。如果用戶更改 gn arg，所有的邏輯將被覆寫。這同樣適用於 v8_optimized_debug。這說明默認的 arg 不能通過命令行被覆蓋。
圖 3：來自谷歌瀏覽器 bug 存儲庫的兩個 bug 報告示例，需要合適的開發人員來修復。實際上，bug 報告＃1 由訓練實例中的開發者修復。而 bug 報告＃2 的 BOW 特徵比 bug 報告＃1 與訓練實例更相似。
（2）RQ2：與傳統特徵工程方法相比，無監督特徵工程方法如何實現？
（3）RQ3：每類訓練樣本的數量對分類器的性能是否有影響？
（4）RQ4：與使用描述相比，僅使用 bug 報告的標題（或摘要）進行分類的效果如何？
（5）RQ5：使用深度學習的遷移學習是否有效，深度學習模型僅使用一個數據集進行訓練，並用於在另一個數據集中進行分類效果如何？
最近，基於遞歸神經網路（RNN）的深度學習演算法已經徹底改變了單詞序列表示的概念，並在許多應用，如語言建模和機器翻譯方面取得了巨大的突破。Lam 等人 [17] 使用深度神經網路（DNN）和 rSVM 來學習源代碼和 bug 報告之間的共同表示，並將其用於有效的 bug 定位。 White 等人 [30] 也為如何在軟體庫中使用深度學習來解決一些具有挑戰性的問題提供了開闊的思路。本研究的主要成果歸納如下：
圖 4：演算法流程圖，突出顯示了重要步驟
方法
軟體 bug 自動分類是一種監督式分類方法，輸入數據是 bug 報告摘要（標題）和 bug 描述。圖 4 突出顯示了自動化 bug 分類演算法的主要步驟，原理如下：
（1）從開放源代碼 bug 跟蹤系統中提取 bug 報告的標題、描述、報告時間、狀態和所有者信息，
（2）在非結構化描述中處理 URL、堆棧跟蹤、十六進位代碼，以及需要對深度學習模型進行專門訓練的代碼片段，這些內容將在預處理階段被刪除，
（3）在語料庫中出現至少 k 次的辭彙被提取出來作為辭彙表，
（4）分類 bug（D2）用於分類器訓練和測試，而所有的未分類 / 開放 bug（D1）用於學習深度學習模型，
（5）具有注意機制技術的深度雙向遞歸神經網路，通過組合 bug 標題和描述作為一個詞序列來學習 bug 表示，
（6）將分類 bug（D2）分成訓練和測試數據集，並進行 10 倍交叉驗證以消除訓練偏差，
（7）使用 DB-RNN 演算法提取訓練 bug 報告的特徵表示，
（8）訓練監督分類器用於執行為開發者分配 bug 報告的任務，
（9）使用經過訓練的深度學習演算法提取測試 bug 的特徵表示，
（10）使用提取的特徵和學習分類器，預測每個潛在的開發者的概率分數，並在測試集合中計算準確度。
（i）在步驟 4 中，完全忽略了未發生的 bug（D1），（ii）步驟中 bug 報告表示是基於深度學習而不是片語，方法也隨著傳統的自動 bug 分類管道而變化。增加步驟 4 和 5，模型可以從數據本身自動學習 bug 報告表示，而不是通過手動訓練。
深度雙向遞歸神經網路（DBRNN-A）
本研究提出的基於 DBRNN-A 的特徵學習方法，如圖 5 所示，主要具有以下優點：
圖 5：具有 LSTM 單元的深度雙向遞歸神經網路（RNN）詳細說明。可以看出，深度網路具有多個隱藏層，從輸入數據中學習複雜的分層表示。
直觀地說，bug 報告中所有單詞在 bug 分類時可能並沒有用處。為了添加這些單詞，我們引入注意機制 [20]，它在分類過程中只學習 bug 報告中的比較重要的單詞。
由於注意機制在分類過程中只選擇了若干個詞，因此 DBRNN-A 可以從真正的長詞序列中學習上下文的表示。
一個雙向的 RNN [9] 均考慮到了正向（第一個字到最後一個字）和反向（最後一個字到第一個字）的單詞序列，併合並這兩個表示。因此，特定單詞的上下文既包括前幾個單詞，又包括幾個增強語義的單詞。
對於每個單詞來說，使用辭彙表來提取一個單一的熱 V 維表示法，在熱 V 維表示法上學習 a P 維的 word2vec 表示 [23]。如圖 5（a）所示，通過此辭彙表示學習一個帶有 LSTM 單元的 DBRNN-A，以獲得整個 bug 報告（標題 + 描述）的 D 維特徵表示。RNN 是一個包含一個隱藏層的序列網路，其中有 m 個隱藏單元，h = 。系統的輸入是一系列的辭彙表示，x = ，並生成一個輸出序列 y = 。每個隱藏單元都是一個狀態模型，將前一個狀態 si-1 和一個單詞 xi 轉換成下一個狀態 si 和一個輸出單詞 yi。 「循環」這個術語說明，每一個隱藏的單位都以循環方式執行同樣的功能：。直觀上來說，狀態 si 攜帶了前一個詞的累積信息。從最後一個隱藏節點獲得的輸出 ym 是整個句子的累積表示，例如，圖 5 中被標記的輸入句。當 i = 1 時，xi 是輸入字的 P 維的 word2vec 表示，無響應和先前的狀態 s0 被隨機初始化。使用 LSTM 函數 f，可以預測當前狀態 s1 和辭彙輸出 y1。如果下一個字是「stop」，當前狀態為 s1，使用相同的函數 f 預測 s2 和 y2。共享函數減少了可學習參數的數量，並保留了序列中所有單詞的上下文。對於語言建模或學習句子表示，yi 實際上是序列 xi + 1 中的下一個單詞，即網路通過記憶句子中先前出現的單詞來預測下一個單詞。LSTM 函數 [9] 具有用於特殊用途的內置存儲器單元，將上下文信息存儲在更長的句子中。
此外，為了有選擇地記憶和學習 bug 報告中的重要單詞，我們使用了注意機制模型。注意矢量是通過對所有計算輸出 yi 進行加權求和得到的，如下所示：
直觀上，αi 將每個單詞用於分類的重要性權重進行關聯。兩種基於 RNN 的不同深度特徵模型，一種是輸入字序列向前運行，另一種是輸入字序列向後運行，經過訓練學習後獲得的 bug 報告最終表示 r 如下所示：
⊕表示這些向量的連接。相比之下，如圖 5（b）所示，對於一份相同的 bug 報告，一個基於頻率的 BOW 模型將生成一個 V 維表示，其中 V 表示辭彙的大小。通常， P 的大小被選為 300 [23]，D 小於 4 P （
表 1：實驗中使用的三種不同 bug 庫概覽，谷歌瀏覽器、Mozilla Core、Mozilla Firefox
例如，如果使用 10000 個 bug 數據用於訓練（250000 個單詞（ V ）），BOW 模型表示將生成一個大小為 10 000×250 000 的稀疏特徵矩陣，而我們提出的 DBRNN-A 模型將生成一個密集緊湊的表示，其特徵矩陣的大小為 10 000×1200。
整個深度學習模型使用的是 Python 的 Keras 庫。就我們所知，這是第一次有人使用深度序列學習模型來學習 bug 表示，並用這些功能來學習自動化軟體 bug 分類監督模型。
分類 bug 報告
監督分類器的目標是學習一個函數 C，可以將 bug 特徵表示圖匹配給一組合適的開發者。將自動化 bug 分類作為監督分類的問題已經在文獻 [5] [32] 中得到了充分的證實。然而，分類和特徵的質量相差無幾，這一點很好理解。因此，本研究的主要成果，是提出了一個更好的 bug 報告表示模型，並提高了現有分類器的性能。在這項研究中，我們使用深度學習 [9][7][10] 從業者喜歡的 softmax 分類器。Softmax 分類器對多類分類進行邏輯回歸，提取特徵並提供了長度等於類數的分數向量。softmax 分類器對這些分值進行歸一化，並得到該類的第 i 個 bug 報告的可解釋的概率值。
大規模公開 bug 數據集
數據提取
我們下載了 Google Chromium 從 2008 年 8 月（Bug ID：2）—2016 年 7 月（Bug ID：633012）期間的 bug 報告，總共收集了 383104 個 bug 數據，包括 bug 的標題、描述、bug 所有者和報告時間。 「所有者」欄位中的開發人員被視為給定 bug 的真正分類。狀態為「已驗證」或「已修正」，並且類型為 bug，具有有效的 bug 所有者數據被用於訓練和測試分類器，其餘 bug 用於學習 bug 表示。
但是，我們注意到共計有 11044 個被驗證或修復的 bug 並沒有對應的所有者。這些公開的 bug 共有 263,936（68.9％）個，均用於深度學習，118,643（31％）個 bug 報告被用於分類器的訓練和測試。
我們從 Mozilla 兩個 bug 資料庫 Core 和 Firefox 中提取數據，包括 1998 年 4 月（Bug ID：91）和 2016 年 6 月（Bug ID：1278040）之間 Mozilla Core 的 314,388 個 bug 報告，以及 1999 年 7 月（Bug ID：10954）到 2016 年 6 月（bug 號 1278030）期間 Mozilla Firefox 的 162307 個 bug 報告。被「分配」的開發人員在分類過程中被認為是實際上的分類。在分類器的訓練和測試中，我們使用了狀態為已驗證修復、已解決修復狀和已關閉修復 bug 報告。然而，有些修復報告沒有對應的分配開發人員，例如在 Core（7219/135434 = 5.33％）和 Firefox（3716/27930 = 13.3％）中。忽略這些 bug，Core 中的 1,28,215 個 bug， Firefox 中的 24,214 個 bug 被用於分類器的訓練和測試，數據集總結見表 1。
數據預處理
我們使用相同的步驟對三個數據集進行單獨的預處理，並創建基準協議，每個 bug 報告中相同的 bug 標題和描述文本內容。預處理非結構化文本內容的過程包括刪除 URL、十六進位代碼和堆棧跟蹤信息，並將所有文本轉換為小寫字母，並使用斯坦福大學的 NLTK 包進行辭彙標記。所有單詞的辭彙都是使用整個語料庫構建的。為了去除很少出現的單詞並減少辭彙量，系統通常選擇高頻詞或出現頻率極低的辭彙 [34]。對於提取的數據，我們通過實驗觀察到，辭彙的最小頻率為 5 會讓辭彙大小和性能之間達到很好的平衡。
深入學習數據訓練
在我們的數據分割機制中，分類器測試數據是不可見的數據，因此不能用於深度學習演算法。我們的設計是不使用分類器訓練數據來訓練深度學習模型，因為這些數據對提高準確性幫助極小，但卻大大增加了訓練時間。因此，只有非故障的 bug（在數據提取小節中解釋）被用於訓練深度學習模型。此外，使用非重疊數據集來訓練特徵模型和分類器模型，則突出了特徵的泛化能力。
訓練分類數據
對於監督分類器的訓練和測試，我們使用 Betternburg 等 [4] 提出的 10 倍交叉驗證模型，將所有已修復的 bug 報告數據按時間順序排列分成 11 組。從第二次交叉驗證開始，每一次驗證被視為一個測試集合，此前的驗證用於訓練。
圖 6：DBRNN-A 的體系結構，包括模型的所有參數。
通常情況下，在開源項目中，開發人員會不斷更改時間，因此按時間順序分類可確保訓練和測試集的開發人員高度重合。此外，為了保證訓練的有效性，我們需要每個開發者更多的訓練樣本。在最近的一項研究中，Jonsson 等 [14] 使用那些至少修復了 50 個 bug 報告的開發者樣本進行訓練，即每類訓練樣本的最小數目為 50。從文獻 [2] [5] 的不同研究可以看出，閾值參數會影響分類性能。因此，在這個研究中，我們研究閾值和分類性能之間的直接關係，通過對每個類別的最小訓練樣本數量具有四個不同的閾值 0,5,10,20。為了進行閉合的訓練實驗，確保測試中可用的所有類都可用於訓練，我們在測試集中還加入了訓練集中不包括的分類。因此，對於每個有所有者的測試 bug 報告，分類器已經經過了同一所有者修復 bug 的訓練。
實驗評估
評估協議和度量
對於給定的 bug 報告，訓練的 softmax 分類器給出每個開發者的概率值，表示它們與 bug 報告的關聯。因此，所使用的評估度量達到 top-k 準確率，表示實際開發人員在 top-k 檢索得出的結果。交叉驗證（CV）集包括不同類別或一組開發人員。因此，在 CV＃1 期間，用於訓練和測試的類別與 CV＃2 中使用的類別不同。由於整個 CV 的分類器模型是在不同的類別上進行訓練的，所以平均準確度只能給出一個性能表現的大概範圍，而不能達到可解釋的準確率。因此，需要報告每個交叉驗證集前 k 個數據的準確性，以了解其在模型訓練中導致的方差 [16]。
為了學習深度表示，我們構建了具有 300 個 LSTM 單元的 DBRNN-A，其丟失概率為 0.3。Adam 優化器使用了基於分類交叉熵的損失函數，學習率為 0.001，訓練了 100 個具有早期停止的時期，所用的模型架構和參數如圖 6 所示。
與現有演算法相比
演算法性能交叉比較的主要挑戰，是缺少公開的基準數據集和已有研究的源代碼。因此，之前的研究工作獲得的 bug 分類準確性無法與我們所提出的方法進行比較，除非結果在相同的數據集中顯示。為此，我們採用文獻 [2] [32] [14] 中提到的一些已經實驗成功的自動化 bug 分類方法，與使用了我們的基準數據集的演算法進行了比較。我們使用了基於詞頻的 BOW 表示 bug 報告中的標題和描述，如圖 5 所示。我們使用這些功能，評估四個不同分類器的性能：（i）Softmax 分類器 [26]，（ii）支持向量機（SVM）[31]，（iii）多項樸素貝葉斯（MNB）[15]，以及（iv）基於餘弦距離的匹配 [21]。四個監督分類器均使用了 Python scikit-learn 包，且僅使用了分類器訓練和測試數據，而未使用非分類 bug 報告。
圖 7：深度學習演算法在所有三個數據集的平均準確率。可以看到，隨著每個類別訓練樣本數量增加，解決 RQ3 的分類準確性整體提高。
表 2：谷歌瀏覽器 bug 報告十次交叉驗證的準確率。報告中包含所有驗證和標準偏差信息，性能最好的結果加粗顯示。
表 3：Mozilla Core bug 報告十次交叉驗證的準確率。報告中包含所有驗證和標準偏差信息，性能最好的結果加粗顯示。
表 4：Mozilla Firefoxbug 報告十次交叉驗證的準確率。報告中包含所有驗證和標準偏差信息，性能最好的結果加粗顯示。
結果分析
使用 Google Chromium、Mozilla Core 和 Mozilla Firefox 數據集得出的結果如表 2、表 3、表 4 所示，回答了本文的重點研究問題。
RQ1：使用深度學習來自動執行 bug 分類是否可行？
圖 8：在 bug 報告中，僅使用標題或標題和描述，所有三個數據集上的深度學習演算法精準度。未使用描述會顯著降低分類的準確性，解答了 RQ4 提出的問題。
從獲得的結果可以清楚地看到，深度學習 bug 報告表示是完全可以勝任 bug 分類任務的可行方法。我們提出的 DBRNNA 方法分類準確性達到 34 - 47％，並且所有的實驗都是在 Intel（R）Xeon（R）CPU E5-2660 v3 上運行，運行頻率為 2.60GHz，配置 Tesla K80 GPU。
學習特徵表示模型和訓練分類器通常是離線任務，對測試時間沒有影響。例如，使用 Google Chroimum 數據集來訓練 DBRNN-A，每小節需要大約 300 秒。對於整個 CV＃10 子集，softmax 分類器的訓練和測試時間分別為約 121 秒和 73 秒。但是，在對模型進行訓練之後，使用我們提出的方法（特徵提取 + 分類），為開發者分配新的 bug 報告僅需要 8 毫秒，這樣的速度讓人印象深刻。
RQ2：與傳統方式相比，無監督的方法性能如何？
從結果中可以看到，DBRNN-A 的特徵學習性能優於傳統的 BOW 特徵模型。使用 Chromium 數據集，BOW + Softmax 分類的平均精確度在 9-12％左右，而最好的分類器準確率可以達到 26-28％。這突出了在我們創建的大型數據集中進行 bug 分類十分具有挑戰性。然而，DBRNN-A 的精準度達 37-43％，精準度提高 12-15％。同樣，在 Mozilla Core 和 Mozilla Firefox 數據集中，使用了深度學習功能後，平均精準度分別提高 3-5％和 7-17％。因為深度學習模型可以從 bug 報告中記憶更長的句子，從而使得性能大幅提高。從結果中，我們觀察到，BOW 特徵 MNB 和基於餘弦距離的匹配性能優於 SVM（支持向量機）和 softmax 分類器。
RQ3：每類訓練樣本的數量對分類器的性能是否有影響？
實驗證明，隨著每類訓練樣本的最小數量增加，通過更好地學習分類邊界，所有 bug 報告庫中的分類性能均有所提高。例如，在 Chromium 數據集中，當分類器訓練閾值為零時，DBRNNA 的平均準確率為 37.9％，而當閾值為 20 時則穩定地上升到 42.7％。圖 7 表示三個數據集分類平均準確率均提高。然而，當閾值大於 20 時，分類的準確率不再上升。另外，CV＃10 到 CV＃1 的數據也表明，DBRNN 的性能提高了。儘管測試數據種類數量有所增加，但分類性能隨著訓練數據的增加不斷提高。因此，從經驗上來說，分類器可用的訓練數據越多，性能就越好。
而且，在所有的交叉驗證中，所有數據集都存在大約（2 - 7）％的標準偏差。這強調了研究每個交叉驗證集的性能以及平均準確率的重要性。
RQ4：與使用描述相比，只使用 bug 報告的標題（或摘要）進行分類的效果如何？
我們僅使用 bug 報告的標題（摘要）並完全忽略描述信息，對深度學習模型的性能進行了測試。在所有三個數據集上進行實驗時，最小訓練樣本數量為 N = 20，CV＃10。圖 8 對在使用描述內容和不使用描述內容的情況下所有三個數據集上的平均準確率進行了比較。結果，我們可以清楚地看到，未使用描述顯著降低了 Firefox 數據集中分類的性能，降幅高達 23％。
RQ5：當學習模型使用一個數據集進行訓練，並用於在另一個數據集中進行分類時，使用深度學習、遷移學習或交叉數據學習是否有效？
通過重複使用已經過其他數據集訓練的模型，轉移學習可以顯著減少離線訓練所需的時間。但是，大多數模型在跨數據集學習的過程以失敗告終。我們在 Chromium 數據集中訓練模型，然後在 Core 和 Firefox 數據集（Mozilla 數據集）中進行測試，以探究深度學習模型在轉移學習中的有效性。測試結果顯示，使用在 Chromium 數據集上訓練的深度學習模型，當 N = 20 時，Chromium 測試集中的平均準確率為 42.7％，Core 為 39.6％，Firefox 為 43％。通過這種方法獲得的結果與在相同數據集上訓練和測試獲得的結果相差無幾。這表明，我們所提出的方法能夠有效地使用在數據集上訓練的模型，在另一數據集中完成 bug 報告分類任務。
實驗的影響因素
我們的實驗結果可能受到一些因素的影響。雖然任何基於學習的分類系統普遍都會受到一些因素的影響，但這些因素並不是我們的方法面臨的問題，而是另外一些因素，具體如下：
（1）使用三個具有不同特徵的開源 bug 庫得出結果，以確保泛化。
然而，商業化 bug 跟蹤系統可能會採用不同的模型，因此我們的結果可能不能直接應用到這樣的庫。
（2）目前，我們的方法只測試了 bug 報告的標題和描述。雖然實驗結果顯示，這兩個非結構化的文本數據在得出充分的 bug 報告過程中是必要的，但可能還需要其他額外的信息。
（3）為了進行對比，我們還重新測試了一些文獻中提到，目前還未公開應用的 bug 分類演算法。雖然我們已經儘力以最好的方式應用這些演算法，但結果還是與原始應用有一定偏差。
（4）在分類器的訓練和測試期間，我們假設每個 bug 報告只對應一個修復所有者。但是，根據已解決的 bug 報告模式和歷史記錄，項目中可能有多個活躍的開發人員可以解決該 bug。
其他應用
bug 表示是直接從數據中以無監督的方式習得的，且功能的實現不依賴於任務。這使我們可以靈活地使用這些功能，來學習所有任務或應用程序的監督分類器。我們還討論了這一特徵表示方法在其他應用中的可能性。
相關結果
表 5 按照時間順序（2010 年至 2016 年）列出了與 bug 分類密切相關的結果列表。以前的大多數技術都使用了 bug 摘要 / 標題和描述 [2] [28] [32] [33] 數據，因為它們在報告提交時是可用的，並且不會隨著報告的周期而改變。Bhattacharya 等人 [5] 將產品、組件和最後的開發人員活動也加入了開發者名單，Shokripour 等人 [27] 使用代碼信息以改善性能，而 Badashian 等人 [3] 使用堆棧溢出和 bug 描述中的關鍵字來識別開發人員的專業知識。
表 5 顯示，我們採用了許多不同的特徵模型，如 tf、歸一化 tf、tf-idf 和 n-gram。我們通過工程設計來選擇要使用哪種特徵模型，然而，選擇哪個特徵模型最能代表所收集的數據是一項具有挑戰性的任務。在這項研究中，我們設計了一個深度雙向 RNN 解決了這個問題，它以無監督的方式從數據中直接學習到最優特徵表示。此外，我們還超越單詞級別的表示模型，提出了一個多單詞序列表示模型，學習整個 bug 報告的統一表示方法。
結論
在這項研究中，我們提出了一個基於深度雙向注意機制的遞歸神經網路（DBRNN-A）的新型軟體 bug 報告（標題 + 描述）表示演算法。該深度學習演算法可以學習保留了較長上下文詞序和語義關係的段落級表示方法。我們對四種不同分類器、多項樸素貝葉斯、餘弦距離、支持向量機和 softmax 分類器的性能進行了對比。為了進行實驗分析，我們收集了來自三個受歡迎的開源 bug 庫的 bug 報告數據：谷歌瀏覽器（383,104）、Mozilla Core（314,388）和 Mozilla Firefox（162,307）。實驗結果表明，DBRNN-A 和 softmax 分類器的性能優於 bag-of-words（詞庫）模型，三個數據集的平均準確率均有所提高。此外，研究結果還顯示，僅使用標題信息進行分類會顯著降低分類的性能，突出了描述的重要性。值得注意的是，深度學習模型的轉換學習能力得以體現，Chromium 數據集上學習的模型在調整 Mozilla bug 時表現出競爭性。
此外，該實驗的數據集連同其完整的基準測試協議和實施的源代碼是公開的，以實現實驗的可重複性。
小彩蛋：如果您平常有閱讀論文的習慣，並且願意做一些論文編譯整理的工作，或者有論文導讀類稿件希望可以發布，歡迎關注 AI 前線（ai-front），在後台留下聯繫方式，我們將與您聯繫，並進行更多交流！
※全球第一款開源線下搜索引擎OpenGenus，線下搜索代碼、演算法
TAG:AI漫遊 |