觀點 | 論機器學(xué)習(xí)和編程語言：ML需要專用的計算機語言嗎？

taotao_2016 2017-12-15

展開全文

選自Julia Blog

作者：Mike Innes等人

機器之心編譯

任何機器學(xué)習(xí)系統(tǒng)復(fù)雜到一定程度，都會包含一個臨時開發(fā)的、不合規(guī)范的、充滿錯誤的、運行速度很慢的、只有一半功能的編程語言實現(xiàn)。（格林斯潘第十定律）

我們很高興看到機器學(xué)習(xí)大爆發(fā)，以及機器學(xué)習(xí)模型的復(fù)雜度和用來構(gòu)建模型的框架。越來越多的頂尖模型更多地涉及到編程問題，通常它們需要支持循環(huán)和遞歸等編程結(jié)構(gòu)，這給創(chuàng)建它們的工具（編程語言）帶來了一些有趣的問題。

盡管機器學(xué)習(xí)沒有專用的語言，但有的機器學(xué)習(xí)框架（如 TensorFlow）在 Python API 下高效地創(chuàng)建了「新語言」，而一些系統(tǒng)（如 PyTorch）重新使用 Python 作為建模語言。我們想問的是，需要為機器學(xué)習(xí)定制新語言嗎？如果需要，為什么？更重要的是，未來完美的機器學(xué)習(xí)語言可能是什么樣子？

隱藏在機器學(xué)習(xí)系統(tǒng)后的語言

TensorFlow（TF）已經(jīng)算是著一種「編程語言」了，因為在這個框架下我們完全可以使用它所提供的類和對象編寫一個模型。大家使用 Python 和 TF 庫進行編程，因此這個結(jié)論似乎有點令人驚訝。但是，TF 要求你在其內(nèi)部語言內(nèi)使用 Python 代碼構(gòu)建表達式樹，然后 TF 再進行評估。

事實上，你可以用任何語言進行「懶惰的」TensorFlow 風(fēng)格編程。如下面的 JavaScript 代碼，就在這種風(fēng)格中實現(xiàn)了一個小功能（add）：

function add(a,b) {
return `${a}+${b}`;
}
x = 1; y = 2
z = add('x', 'y') // 'x+y'
eval(z) // 3
x = 4
eval(z) // 6

這里，我們進行的是元編程（metaprogramming）——編寫寫代碼的代碼。上例中，源語言和目標(biāo)語言是一樣的（JavaScript），它們也可以是不同的語言（如在處理 C 語言的 C 預(yù)處理器中），我們也可以使用數(shù)據(jù)結(jié)構(gòu)（AST）來代替字符串，原則是一樣的。在 TensorFlow 中，Python 是元語言，我們使用 TF 這種基于靜態(tài)計算圖的語言編寫程序。如果你不信，想一下 TensorFlow 的圖甚至支持變量適應(yīng)范圍（variable scoping）和控制流（control flow）等編程結(jié)構(gòu)，而不是使用 Python 語法，你可以通過一個 API 管理這些結(jié)構(gòu)。

TensorFlow 和類似工具的呈現(xiàn)方式是「庫」，但它們是極其不尋常的庫。大部分庫提供一套簡單的函數(shù)和數(shù)據(jù)結(jié)構(gòu)，而不是全新的編程系統(tǒng)和運行時（runtime）。

為什么創(chuàng)建新語言？

創(chuàng)建新語言的核心原因非常簡單：ML 研究需要極高的算力，簡化建模語言可以使添加特定的優(yōu)化和特征變得簡單。訓(xùn)練模型要求極高的硬件支持、合適的數(shù)值、低解釋器開銷和多種并行化。通用語言如 Python 勉強可以提供這些特征，但 TensorFlow 可以無縫處理它們。

不過有一個障礙。這些優(yōu)化依賴于簡單化的假設(shè)（ML 模型不是遞歸的，或不需要自定義梯度），這使得將這些優(yōu)化或應(yīng)用部署到小型設(shè)備變得簡單。不幸的是，對于工程師來說，模型復(fù)雜度目前出現(xiàn)直線上升的趨勢，而研究者享受破壞這些假設(shè)的過程?，F(xiàn)在模型要求條件分支（比較簡單）、重復(fù)循環(huán)（沒有那么簡單但也不是不可能）、遞歸樹（幾乎不可能）。在 ML 的很多分支，包括神經(jīng)網(wǎng)絡(luò)和概率編程中，模型越來越像程序，包括推斷其他程序的程序（如程序生成器和解釋器），且具備不可微組件，如蒙特卡羅樹搜索。構(gòu)建提供完全靈活性且達到頂尖性能的運行時非常困難，但是最強大的模型和突破性的結(jié)果需要這二者。使用機器學(xué)習(xí)和復(fù)雜樹結(jié)構(gòu)數(shù)據(jù)需要可微且遞歸的算法。

該方法的另一個缺陷是，目前需要上面討論的元編程。構(gòu)建和評估表達樹對程序員和編譯器都是額外的負擔(dān)。很難進行推斷，因為現(xiàn)在代碼有兩個執(zhí)行時間，每個具備不同的語言語義（language semantics），逐步調(diào)試等操作將變得更加困難。這可以通過為新的運行時創(chuàng)建語法來解決，但是其工作量不亞于創(chuàng)建全新的編程語言。

僅用 Python 就可以了嗎？

機器學(xué)習(xí)模型開始需要編程語言的全部力量，Chainer 和其他人率先使用「define-by-run」方法，該方法中 Python 程序本身就是模型，使用運行時自動微分（AD）作為導(dǎo)數(shù)。從易用性的角度來看這種方法很有意思：如果你想要一個進行樹運算的遞歸模型，只需要寫下來，讓 AD 來施展它的魔力！我們很難不高估這種感覺，使用新的無障礙方法對于研究來說是寶貴的。

但是，讓 Python 滿足機器學(xué)習(xí)的復(fù)雜計算要求比你想象的還要難得多。大量研究開始開發(fā)快速語言（如 PyTorch），但并沒有加快 Python 的速度。Python 的語義使它很難提供模型級別的并行化，或者為小型設(shè)備編譯模型。

MXNet Gluon 正在探索利用二者，至少在一定程度上。其想法是將基礎(chǔ)的動態(tài)自動微分和生成可優(yōu)化「靜態(tài)子圖」的代碼追蹤方法聯(lián)系起來。不幸的是，這只是把不相關(guān)的實現(xiàn)和 API 混在一起而已。這種方法也受限制，MXNet 不僅使用它的圖來做 kernel 級別的優(yōu)化，還用于高級別的圖調(diào)度（graph scheduling），如在多個 GPU 上分割模型。此外，目前尚不明確這些混合如何對此進行處理。

適合機器學(xué)習(xí)的語言是什么樣的？

很少有其它領(lǐng)域像機器學(xué)習(xí)一樣有語言級的設(shè)計需求，但在形式化推理或集群計算等領(lǐng)域，量身定制的語言已經(jīng)證明它們是高效的解決方案。同樣，我們希望看到新的或現(xiàn)有的語言能完美地支持機器學(xué)習(xí)所需要的數(shù)值計算、自動微分計算、并行計算和概率計算等能力。

當(dāng)前機器學(xué)習(xí)語言一個明顯的挑戰(zhàn)是在性能方面難以取得一致性，即早期的混合方法需要更多的開發(fā)工作。我們期待未來的機器學(xué)習(xí)語言將支持任意混合的方法（即靜態(tài)計算圖內(nèi)可能混合了其它動態(tài)或靜態(tài)計算圖），并且在編譯動態(tài)代碼時能更好地部署。理想情況下，這種新型語言將只有單個靈活的「計算圖格式」。這種計算圖格式應(yīng)該有一種語法和靜態(tài)描述的方法以表示動態(tài)的行為，換句話說，它應(yīng)該看起來更像一個標(biāo)準(zhǔn)的編程語言。

可編程語義將達到新的靈活性水平，并且它可以通過類似宏（Macros）的特征實現(xiàn)。這將允許通過指定代碼應(yīng)該有怎樣的純數(shù)據(jù)流語義，而在核心系統(tǒng)的頂部構(gòu)建像多 GPU 訓(xùn)練那樣的特征。此外，它也能允許概率編程語言所需要的各種編程操作，或 NLP 模型中常需要手動實現(xiàn)的向量化或批量化等。

與編程語言社區(qū)一樣，機器學(xué)習(xí)工程師非常關(guān)注傳統(tǒng)的自動微分領(lǐng)域。機器學(xué)習(xí)語言可以從真正實現(xiàn)一階導(dǎo)的語言中獲取靈感與經(jīng)驗，這樣的語言可以很容易將符號與運行時（runtime）技術(shù)結(jié)合在一起，將正向與反向模式的自動微分技術(shù)混合在一起，所有這些都不會導(dǎo)致性能上的損失。

ML 研究將需要越來越強大的類型系統(tǒng)（type systems）、用戶自定義類型和更多的擴展手段。目前在英偉達 GPU 上對陣列式支持的硬編碼已經(jīng)足夠了，但像前沿的稀疏機器學(xué)習(xí)，新型 TPU、Nervana 和 FPGA 等面向機器學(xué)習(xí)模型部署的硬件都需要更高的靈活性。

若目前存在添加新型硬件支持或新型數(shù)據(jù)表征的新型語言，那么用戶可以簡單地通過高級代碼，而不需要改變原來的系統(tǒng)就能添加硬件支持或數(shù)據(jù)表征方式。當(dāng)然，我們期望機器學(xué)習(xí)語言能從現(xiàn)有的數(shù)值計算語言中獲取靈感，因為這些語言已經(jīng)能很好地處理特定的任務(wù)了。

此外，機器學(xué)習(xí)工程師對傳統(tǒng)的軟件工程問題越來越感興趣，例如在維護和擴展生產(chǎn)系統(tǒng)等方面。機器學(xué)習(xí)編程模型使得在組件之間更難以創(chuàng)建接口，對模型的重訓(xùn)練可以輕松地實現(xiàn)向后兼容。機器學(xué)習(xí)語言可以像常規(guī)語言一樣將這些問題的解決方案結(jié)合起來，但這仍然是一個開放性問題。

軟件工程 2.0？（圖片來自 XKCD）

任何新語言共同面臨的問題就是它們都需要一套新的庫和生態(tài)系統(tǒng)，從而讓人們編寫的代碼能夠不斷從中獲得支援。例如：如果選擇不重用 Python 的生態(tài)系統(tǒng)，TensorFlow 開發(fā)者們需要為圖語言中的圖像處理和文件 IO 等任務(wù)重新寫庫，在這一部分做出巨大貢獻的項目是 SciPy。這可能是我們快速發(fā)展的唯一出路，機器學(xué)習(xí)參與者們也不能從更為廣泛的 HPC 和數(shù)學(xué)社區(qū)中分裂出去。一個理想條件下的機器學(xué)習(xí)生態(tài)系統(tǒng)是理想的數(shù)學(xué)生態(tài)系統(tǒng)，這些社區(qū)之間的合作將使所有人的力量都獲得倍增。

我們期待新的發(fā)展來自各個維度。Graph IR 和 XLA、ONNX、NNVM 等格式正在變得前所未有的復(fù)雜，同時也在受到傳統(tǒng)語言設(shè)計的啟發(fā)，甚至可能會出現(xiàn)表面語法，以成為完整意義上的編程語言。TensorFlow XLA 已經(jīng)開始面向?qū)Ｓ镁幾g器堆棧發(fā)展，現(xiàn)在包含 TVM、DLVM、myelin，以及其它正在進行的工作。除此之外，像 PyTorch JIT、Gluon 和 Tangent 正努力使 Python 本身成為更好的建模語言，盡管這項任務(wù)面臨的挑戰(zhàn)很大。在剛剛把機器學(xué)習(xí)歸類為數(shù)值編程語言問題后，我們在 Julia 社區(qū)中看到了解決這些語言級別問題的極好的基礎(chǔ)，開發(fā)者們正在持續(xù)推動像 Knet、Flux、Cassettle、CUDAnative、DataFlow.jl 等工具的發(fā)展。

結(jié)論：機器學(xué)習(xí)推理工具

機器學(xué)習(xí)模型已經(jīng)成為極度泛化的信息處理系統(tǒng)，被用于進行越來越高級、越來越復(fù)雜、抽象的任務(wù)；循環(huán)、遞歸、高階模型、甚至堆棧機和語言解釋器全部都可以以基本組建的組合形式來實現(xiàn)。機器學(xué)習(xí)是一種新的編程范式，盡管對于初學(xué)者來說其中含有太多的數(shù)值、可微分和并行化。對于任何工程領(lǐng)域，這些可用工具都會對未來工作的質(zhì)量和范圍產(chǎn)生深遠影響。

所有這些都預(yù)示著機器學(xué)習(xí)系統(tǒng)的設(shè)計者們面臨著非常大的挑戰(zhàn)。盡管如此，我們還有一些好消息：如果有一方面仍未解決的話，過去的幾十年里，計算機語言的研究者們已經(jīng)深入討論了同樣的問題。為了深入探知這一領(lǐng)域的全部，機器學(xué)習(xí)和編程語言社區(qū)需要通力合作，所以，真正的挑戰(zhàn)是整合這兩個群體之間不同的專業(yè)知識。

我們能否建立起一套面向數(shù)學(xué)、衍生和并行，同時又不犧牲傳統(tǒng)編程思想優(yōu)勢的新語言工具？這將是未來十年里計算機語言領(lǐng)域里人們面臨的主要問題。