編輯：LRS
【新智元導讀】程式設計師的死對頭就是各種bug！最近微軟在NeurIPS 2021上帶來了一個好訊息，研究人員設計了一個類似GAN的網路，透過選擇器和檢測器來互相寫和改bug，而且還不需要標註資料！
常言道，「一杯茶，一包煙，一個bug改一天」。
寫程式碼是軟體工程師們每天的工作，但當你辛辛苦苦寫了一大堆程式碼，卻發現無法執行的時候，內心一定是崩潰的。
找bug不僅費時費力，最關鍵的是還經常找不著，並且有時候改了一個bug又會引入更多bug，子子孫孫無窮盡也。
簡直就是找bug找到吐血。
隨著AI技術的發展，各大公司開發的程式碼助手如GitHub Copilot等也能幫你少寫一些有bug的程式碼。
但這還遠遠不夠！
深度學習要是能幫我把程式碼裡的bug也給修了，我上班只負責摸魚，豈不是美滋滋！
微軟在NeurIPS 2021上還真發了一篇這樣的論文，其中提出了一個新的深度學習模型BugLab，並透過自監督的學習方法，可以在不借助任何標註資料的情況下檢測和修復程式碼中的bug，堪稱程式設計師的救世主！
https://arxiv.org/pdf/2105.12787.pdf
修bug難在哪？
所謂的bug，就是程式碼的實際執行和自己的預期不符。
該執行的沒執行，該輸出a，結果卻輸出個b，這種程式碼故意找茬的行為都屬於bug。
所以想要找到並修復程式碼中的bug，不僅需要對程式碼的結構進行推理，還需要理解軟體開發者在程式碼註釋、變數名稱等方面留下的模糊的自然語言提示。
例如一段程式的意圖是，如果名字的長度超過了22個字元，那就只擷取前22個。但原始程式碼中錯誤地把大於號寫成了小於號，導致條件判斷錯誤，程式執行結果和預期不符。
這種小錯誤在寫程式碼的過程也是太常見了，稍不注意就會把條件弄反。
還有一種bug就是使用了錯誤的變數，例如下面的例子裡面write和read弄錯了，就會導致條件判斷失敗，這種bug的修復只有在理解了變數名的意義後才能修復，傳統的修復手段對此是無能為力。
這種錯誤看起來很簡單，但往往盯著看程式碼的時候卻很難發現，屬於一改改一天的那種。
並且每個程式設計師有自己的程式設計風格，比如不同的命名、縮排、判斷以及重構的方式，想讓程式碼來給自己找bug，一個字，難！
對於微軟來說，好在有GitHub程式碼庫可以用來訓練模型。但問題來了，GitHub上帶bug的程式碼有那麼多嗎？有bug誰還commit啊？就算能找到程式碼，也沒人來標註資料啊！
微軟提出的BugLab使用了兩個相互競爭的模型，透過玩躲貓貓（hide and seek）遊戲來學習，主要的靈感來源就是生成對抗網路（GAN）。
由於有大量的程式碼實際上都是沒有bug的，所以需要設計一個bug selector來決定是否修改正確的程式碼來引入一個bug，以及以何種方式引入bug（例如把減號改為加號等）。當選擇器確定了bug的類別後，就透過編輯原始碼的方式引入bug。
另一個用來對抗的是bug detector，用來判斷一段程式碼是否存在bug，如果存在的話，它需要定位並修復這個bug。
選擇器和檢測器都能夠在沒有標記資料的情況下共同訓練，也就是說整個訓練過程都是以自監督的方式進行，併成功在數百萬個程式碼片段上訓練。
selector負責寫bug，並把它藏（hide）起來，而detector負責找bug，並修復，整個過程就像躲貓貓一樣。
隨著訓練的進行，selector寫bug越來越熟練，而detector也能夠應對更復雜的bug。
整個過程與GAN的訓練大體相似，但目的卻大不相同。GAN的目的是獲得一個更好的生成器來修改圖片，但BugLab的目的是找到一個更好的檢測器（GAN中的判別器）。
並且整個訓練也可以看作是一個teacher-student模型，選擇器教會檢測器如何定位並修復bug。
為開源社群修bug！
雖然從理論上來說，使用這種hide and seek的方式可以訓練更復雜的selector來生成更多樣的bug，從而detector的修bug能力也會更強。
但以目前的AI發展水平來說，還無法教會selector寫更難的bug。
所以研究人員表示，我們需要集中精力關注那些更經常犯的錯誤，包括不正確的比較符，或者不正確的布林運算子，錯誤的變數名引用等等其他一些簡單的bug。並且為了簡單起見，實驗中只針對python程式碼進行研究訓練。
雖然這些解釋聽起來都像是藉口。
為了衡量模型的效能，研究人員從Python包索引中手動註釋了一個小型bug資料集，和其他替代方案（例如隨機插入bug的selector）相比，使用hide and seek方法訓練的模型效能最多可以提高30%
並且實驗表明大約26%的bug都可以被發現並自動修復。在檢測器發現的bug中，有19個在現實生活中的開源GitHub程式碼中都屬於是未知的bug。
但模型也會對正確的程式碼報告存在bug，所以這個模型在離實際部署上線還有一段距離。
如果更深入地研究selector和detector模型的話，就會引出那個老生常談的問題：深度學習模型到底有沒有，又怎麼樣去「理解」一段程式碼的作用？
過去的研究表明，將程式碼表示為一個token序列就能夠產生次優的（suboptimal）效果。
但如果想要利用程式碼中的結構，例如語法、資料、控制流等等，就需要將程式碼中的語法節點、表示式、識別符號、符號等等都表示為一個圖上的節點，並用邊來表示節點間的關係。
有了圖以後就可以使用神經網路來訓練detector和selector了。研究人員使用圖神經網路（GNN）和relational transformer都進行了實驗，結果發現GNN總體上優於relational transformer。
如何讓AI幫助人類來寫程式碼和改bug一直都是人工智慧研究中的一項基礎任務，任務過程中AI模型需要理解人類對程式程式碼、變數名稱和註釋提供的上下文線索來理解程式碼的意圖。
雖然BugLab離真正解放程式設計師改bug還很遙遠，但距離我們消滅bug總算又向前走了一步！
參考資料：
https://www.microsoft.com/en-us/research/blog/finding-and-fixing-bugs-with-deep-learning/
