在過往的 IT 技術變遷史中，不乏有將代碼庫遷移到主流或更高效語言，如 Java 或 C++ 的案例，這需要開發(fā)人員具備源語言和目標語言方面的專業(yè)知識，而且通常成本很高。例如，澳大利亞聯(lián)邦銀行在 5 年內(nèi)花費了約 7.5 億美元將其平臺從 COBOL 轉(zhuǎn)換為 Java。超編譯器在理論上可以提供幫助，它們消除了從頭開始重寫代碼的過程，但在實踐中卻很難應用，因為不同的語言可能有不同的語法，并依賴于不同的平臺 API、標準庫函數(shù)和變量類型。

為簡化這一問題，F(xiàn)acebook 推出了 TransCoder ，該工具采用無監(jiān)督學習，可以讓代碼在 C ++，Java 和 Python 之間進行轉(zhuǎn)換。

論文地址：https:///pdf/2006.03511.pdf

根據(jù)研究人員的說法，TransCoder 在實驗過程中展示了對每種語言特有的語法、數(shù)據(jù)結構及其方法的理解，并且在跨編程語言的情況下正確對齊了庫，同時適應了較小的修改（例如當輸入已重命名）。盡管它并不完美，例如 TransCoder 在生成過程中未能考慮某些變量類型，但它的性能仍然比一些框架要優(yōu)秀。

該工具的一位共同作者寫道：TransCoder 可以輕松推廣到任何編程語言，不需要任何專業(yè)知識，并且在很大程度上優(yōu)于商業(yè)解決方案。我們的研究結果表明，通過向解碼器添加簡單的約束以確保生成的函數(shù)在語法上是正確的，或者通過使用專用架構，可以輕松解決該模型所犯的許多錯誤。

對于 TransCoder，F(xiàn)acebook 考慮了一個帶注意力的 seq2seq 模型，這個模型由一個編碼器和一個帶有 transformer 架構的解碼器組成。所有的編程語言都共享同一個模型，使用 Lample et al. 中定義的無監(jiān)督機器翻譯的三個原理來訓練它，即初始化、語言建模和回譯。本節(jié)總結了這些原理，并詳細介紹了如何在實例中編譯編程語言（下圖 1 給出了方法說明）。

預訓練是無監(jiān)督機器翻譯 Lample 中的重要一環(huán)。它能確保具有相似意義的序列被映射到相同的 latent representation 上，而不用考慮它們是哪種編程語言。最初，預訓練是通過用跨語言詞匯表征初始化模型來完成的。在無監(jiān)督英法翻譯語境中，“cat”這個詞的嵌入與其法語翻譯 “chat”的嵌入接近。通過訓練單語言詞匯嵌入并讓這些嵌入以無監(jiān)督的方式訓練，可以得到跨語言詞匯嵌入。

隨后的工作表明，以跨語言的方式預訓練整個模型（而不僅僅是詞匯表征）可以使無監(jiān)督機器翻譯得到顯著改善。特別是，遵循 Lample 和 Conneau 的預訓練原則進行訓練時效果尤為明顯——即在單語言源代碼數(shù)據(jù)庫上，用掩碼語言建模 objective 預訓練跨語言模型（XLM）。

所得模型的跨語言性質(zhì)來自于不同語言間存在的海量通用標記（錨點）。在英法翻譯的語境中，錨點基本上由數(shù)字、城市和人名組成。在編程語言中，這些錨點通常由常見的關鍵詞組成（如 for、while、if、try），也包括數(shù)字、數(shù)學運算符和源代碼中出現(xiàn)的英文字符串。

對于掩碼語言建模（MLM）objective 來說，在每次迭代時，F(xiàn)acebook 都會考慮源碼序列的輸入流，隨機屏蔽掉一些標記，并訓練 TransCoder 來根據(jù)上下文預測被屏蔽掉的標記。在不同語言的批次流之間來回切換，這使得該模型能夠創(chuàng)建高質(zhì)量、跨語言的序列表征。圖 1 展示了一個 XLM 預訓練的例子。

圖 1

此方法中使用的無監(jiān)督機器翻譯三個原理的說明。第一個原理是用跨語言掩碼語言模型預訓練來初始化模型。因此，無論使用哪種編程語言，表達相同指令的代碼塊都會被映射到相同的表征上。第二個原理是去噪自動編碼，訓練解碼器始終生成有效序列，即使輸入的是噪聲數(shù)據(jù)，也能提高編碼器對輸入噪聲的魯棒性。最后一個原理是回譯，允許模型生成可以用于訓練的并行數(shù)據(jù)。當 Python 語言模型轉(zhuǎn)換成 C++ 語言模型性能更優(yōu)時，它會為 C++ → Python 模型生成更準確的數(shù)據(jù)，反之亦然。

Facebook 用上述提到的預訓練 XLM 模型來初始化 seq2seq 模型的編碼器和解碼器。編碼器的初始化很簡單，因為它的架構與 XLM 模型相同。然而，transformer 解碼器有一些與源注意力機制相關的額外參數(shù)。根據(jù) Lample 和 Conneau，隨機初始化這些參數(shù)。

XLM 預訓練能使 seq2seq 模型生成高質(zhì)量的輸入序列表征。然而，由于解碼器從未被訓練去解碼一個基于源表征的序列，因此它缺乏翻譯能力。為了解決這個問題，F(xiàn)acebook 以去噪自動編碼（DAE）為目標來訓練模型編碼和解碼序列。DAE objective 的操作就像一個監(jiān)督的機器翻譯算法，使用這種算法可以訓練模型來預測一個給定損壞的標記序列。為了損壞一個序列，可以使用與 Lample et al. 中描述相同的噪聲模型。也就是說，隨機遮擋、刪除和打亂這些輸入標記。

輸入到解碼器中的第一個符號是一個特殊標記，表示輸出的編程語言。在測試時，Python 序列可以被模型編碼，并使用 C++ 起始符號進行解碼，生成 C++ 翻譯。C++ 翻譯的質(zhì)量將取決于模型的 '跨語言能力'：如果 Python 函數(shù)和有效的 C++ 翻譯被編碼器映射到相同的 latent representation，解碼器將成功生成 C++ 翻譯。DAE objective 還訓練了模型的 “語言建模 ”能力，也就是說，盡管有時編碼器的輸出是嘈雜的，但 Facebook 一直訓練解碼器去生成一個有效函數(shù)。此外，這種方法還訓練了編碼器對輸入噪聲的魯棒性，這在回譯的語境中非常有用，因為在回譯過程中，模型是在有噪聲的輸入序列中訓練的。圖 1 對 DAE 進行了說明。

在實際操作中，僅 XLM 預訓練和去噪自動編碼就足以產(chǎn)生翻譯。然而，這些翻譯的質(zhì)量往往很低，因為模型在測試時的效果未達到預期水準，即將函數(shù)從一種語言翻譯到另一種語言。為了解決這個問題，F(xiàn)acebook 引入了回譯，這是在弱監(jiān)督場景下利用單語言數(shù)據(jù)的最有效方法之一。最初引入回譯是為了提高監(jiān)督環(huán)境下機器翻譯的性能，后來發(fā)現(xiàn)回譯變成了無監(jiān)督機器翻譯中的重要一環(huán)。在無監(jiān)督環(huán)境下，source-to-target 模型與并行訓練的后向 target-to-source 模型耦合。Target-to-source 模型用于將目標序列翻譯成源語言，產(chǎn)生與實際目標序列相對應的噪聲源序列。然而以弱監(jiān)督的方式訓練 source-to-target 模型，從 target-to-source 模型產(chǎn)生的噪聲源序列重建目標序列，反之亦然。兩個模型并行訓練，直至實現(xiàn)趨同。圖 1 中展示了一個回譯的例子。

Facebook 使用具有 6 個 layer，8 個 attention head，并將模型的維度設置為 1024。對于所有編程語言，我們都使用單個編碼器和解碼器。XLM 預訓練期間，在 C ++，Java 和 Python 之間進行了轉(zhuǎn)換，它們由 512 個令牌的 32 個源代碼序列組成。訓練時，在去噪自編碼器和回譯 objectives 之間交替，并使用幾批總數(shù)約 6000 個的標記。Facebook 使用 Adam 優(yōu)化 TransCoder，學習速率為 10^(?4)，并使用與 Vaswani 等相同的學習速率調(diào)度器。Facebook 在 PyTorch 中實現(xiàn)了模型，并在 32 個 V100 GPU 上對其進行訓練，使用 float16 操作來加快訓練速度并減少模型的內(nèi)存使用量。

Facebook 通過 Google BigQuery4 獲得 GitHub 公共數(shù)據(jù)集，其包含超過 280 萬個開源 GitHub 存儲庫，過濾其中許可證明確允許重新分發(fā)的項目，并選擇其中的 C ++，Java 和 Python 文件。理想情況下，轉(zhuǎn)編譯器應該能夠翻譯整個項目。在這項工作中，F(xiàn)acebook 決定在函數(shù)級別進行轉(zhuǎn)換。與文件或類不同，函數(shù)足夠短以適合單個批處理，并且在函數(shù)級別上可以通過單元測試對模型進行更簡單的評估。Facebook 會在所有可用的源代碼上對 TransCoder 進行預訓練，并僅對函數(shù)進行去噪自動編碼和回譯 objectives，以獲取有關提取功能的更多詳細信息以及有關訓練集的統(tǒng)計信息。Facebook 進行了一項消融研究，以確定保留還是刪除源代碼中的注釋更好。在源代碼中保留注釋會增加跨語言的定位點數(shù)量，從而提高整體性能。因此，F(xiàn)acebook 將它們保留在最終數(shù)據(jù)集和實驗中。

多語言自然語言處理的最新方法趨向于使用通用分詞器和所有語言的共享詞匯表，這減少了整體詞匯量，并使語言之間的令牌重疊最大化，從而改善了模型的跨語言性。在本次實驗中，通用令牌生成器不是最佳的，因為不同的語言使用不同的模式和關鍵字。邏輯運算符 && 和||在 C ++ 中存在，它們應該被單個標記，但在 Python 中不存在。縮進在 Python 中很重要，因為它們定義了代碼結構，但在 C ++ 或 Java 之類的語言中沒有任何意義。Facebook 在 Java 中使用 javalang tokenizer，Python 標準庫的 tokenizer，C ++ 中使用 clang tokenizer。這些 tokenizer 可確保代碼中無意義的修改（例如，添加額外的新行或空格）不會對 tokenized 序列產(chǎn)生任何影響。Facebook 在提取的令牌上學習 BPE 代碼，并將其拆分為子單元。

GeeksforGeeks 是一個包含計算機科學和編程相關文章的在線平臺，收集了許多編碼問題，并提供了幾種編程語言的解決方案。從這些解決方案中，F(xiàn)acebook 提取了一組 C ++、Java 和 Python 并行函數(shù)，以創(chuàng)建驗證和測試集。這些函數(shù)不僅返回相同的輸出，而且使用相似的算法計算結果。下圖顯示了一個 C ++、Java 和 Python 并行函數(shù)的示例，該函數(shù)確定由字符串表示的整數(shù)是否可以被 13 整除。

圖 2：顯示了無監(jiān)督 Python 到 C++ 轉(zhuǎn)換

大多數(shù)源代碼轉(zhuǎn)換研究都使用 BLEU 來評估生成的函數(shù) [1、10、22、36] 或其他度量（基于翻譯和參考中 token 之間的重疊度）。一個簡單的度量是計算參考匹配，即與真實結果之間的匹配度，這些度量標準的局限性在于未考慮語法正確性，語法差異小則得分高，而它們可能導致完全不同的編譯和計算輸出。相反，具有不同實現(xiàn)方式的語義等效程序?qū)⒕哂休^低的 BLEU 分數(shù)。取而代之的是，F(xiàn)acebook 引入了一種新的度量標準，即計算精度，該度量標準可以評估轉(zhuǎn)換后函數(shù)在給定相同輸入時是否生成與參考函數(shù)相同的輸出。如果每個輸入給出的輸出與參考相同，則認為轉(zhuǎn)換是正確的。

驗證集和測試集中帶有單元測試的函數(shù)數(shù)量

在表 1 中報告了測試集上的結果。在表 2 中，報告了使用集束搜索解碼的結果，并將 TransCoder 與現(xiàn)有的 baseline 進行了比較。圖 2 給出了一個從 Python 到 C++ 的無監(jiān)督翻譯的例子。

評估度量標準之間的差異。在表 1 中，F(xiàn)acebook 發(fā)現(xiàn)大部分翻譯與參考不同，雖然它們成功通過了單元測試，但是通過與參考匹配度量標準進行對比，這些翻譯被認為是無效的。例如，當從 C++ 翻譯到 Java 時，雖然 60.9% 的翻譯達到了預期水準，但僅有 3.1% 的生成結果與實際參考完全相同。此外，其性能在 BLEU 上也表現(xiàn)平平，與計算精度相關性不高。測試結果顯示了這種方法在該領域中常用的傳統(tǒng)參考匹配指標和 BLEU 指標上存在一些問題。

集束搜索解碼。在表 2 中，F(xiàn)acebook 研究了集束搜索的影響，要么考慮集束中所有通過單元測試的假設（Beam N），要么只考慮對數(shù)概率最高的假設（Beam N - Top 1）。與 greedy 解碼（Beam 1）相比，集束搜索顯著提高了計算精度，使 Beam 25 Java → Python 的計算精度提高了 33.7%。當模型只返回對數(shù)概率最高的假設時，性能就會下降，這說明 TransCoder 經(jīng)常能找到有效的翻譯，盡管它有時會給錯誤的假設一個較高的對數(shù)概率。文中給出了通過集束搜索糾正錯誤的解釋。

表 1：TransCoder 在測試集上 greedy 解碼的結果。

表 2：集束搜索解碼計算準確率和以及和 Baseline 的對比

在實際用例中，檢查生成的函數(shù)是否在語法上正確并被編譯過，或者從輸入函數(shù)中創(chuàng)建單元測試，這些方法都比對比對數(shù)概率更好。附錄中的表 5 顯示，當目標語言是 Java 或 C++ 時，編譯錯誤是測試失敗的最主要原因之一。這表明 “Beam N - Top 1”指標可以很容易地進行改進。

與現(xiàn)有 baseline 相比。Facebook 將 TransCoder 與現(xiàn)有的兩種方法進行比較：第一種是 j2py10 ，一個從 Java 翻譯到 Python 的框架；第二種是 Tangible Software Solutions11 的商業(yè)解決方案，從 C++ 翻譯到 Java。這兩個系統(tǒng)都依賴于用專業(yè)知識手動建立的重寫規(guī)則。后者處理多種元素的轉(zhuǎn)換，包括核心類型、數(shù)組、一些集合（Vectors 和 Maps）和 lambdas。

在表 2 中，F(xiàn)acebook 觀察到 TransCoder 在計算精度上明顯優(yōu)于兩個 baseline，從 C++ 到 Java 的計算準確率能達到 74.8%，從 Java 到 Python 的計算準確率能達到 68.7%，而 baseline 在這兩種轉(zhuǎn)換上的計算準確率分別為 61% 和 38.3%。在翻譯標準庫中的函數(shù)時，TransCoder 的表現(xiàn)尤為突出。在基于規(guī)則的編譯轉(zhuǎn)換器中，需要為每個標準庫函數(shù)手動編碼重寫規(guī)則，而 TransCoder 則以無監(jiān)督的方式學習這些規(guī)則。下圖介紹了 TransCoder 的幾個成功例子，而 baseline 則無法生成正確的翻譯。

圖 3：錯誤的 baseline 翻譯與正確的 TransCoder 翻譯示例

事實上，F(xiàn)acebook 并不是唯一開發(fā)代碼生成系統(tǒng)的組織。在今年早些時候的 Microsoft Build 大會上，OpenAI 演示了一個在 GitHub 存儲庫上訓練的模型，該模型使用英語注釋生成整個功能。兩年前，萊斯大學的研究人員創(chuàng)建了一個名為 Bayou 的系統(tǒng)，該系統(tǒng)通過將公開代碼背后的“意圖”相關聯(lián)，實現(xiàn)自主編寫軟件程序。

論文地址：https:///pdf/2006.03511.pdf

擁有吃喝玩樂全場景豐富數(shù)據(jù)的美團點評，利用跨場景數(shù)據(jù)挖掘、映射、聚合與關聯(lián)構建了一個龐大的生活服務知識圖譜——“美團大腦”，這個知識圖譜可以促進每個場景下應用服務的智能升級。點擊「閱讀原文」來 AICon 上海 2020 了解新零售場景下的知識圖譜如何構建與落地。大會限時 8 折購票中，歡迎咨詢票務小姐姐：18514549229（微信同號）。