如何評價arXiv上的最新論文：「可自動編程」的人工智慧程序員(AI Programmer)？

01-05

彭博和英特爾實驗室的研究人員提出了一種基於遺傳演算法的人工智慧程序 AI Programmer（Autonomously Creating Software Programs Using Genetic Algorithms），摘要為「In this paper, we present the first-of-its-kind machine learning (ML) system, called AI Programmer, that can automatically generate full software programs requiring only minimal human guidance. At its core, AI Programmer uses genetic algorithms (GA) coupled with a tightly constrained programming language that minimizes the overhead of its ML search space. Part of AI Programmer"s novelty stems from (i) its unique system design, including an embedded, hand-crafted interpreter for efficiency and security and (ii) its augmentation of GAs to include instruction-gene randomization bindings and programming language-specific genome construction and elimination techniques. We provide a detailed examination of AI Programmer"s system design, several examples detailing how the system works, and experimental data demonstrating its software generation capabilities and performance using only mainstream CPUs.」。
1、該研究是否過於「標題黨」？
2、該研究與微軟在ICLR 2017上的DeepCoder有何異同？
3、如何看待該研究與github上五年前的項目（primaryobjects/AI-Programmer）重複？是否有學術抄襲嫌疑？

謝邀。

總結來看，這個項目並不會導致程序員失業，說是「人工智慧程序員」有標題黨之嫌。我認為這是一個探索性質的實驗，屬於概念性驗證(Proof of Concept)，並沒有技術上的飛躍。

項目的本質還是在有限時間搜索最優解的優化問題，即如何評估機器產生的代碼是正確、有效、達成目標的。技術上來說，作者使用了極小編程語言和遺傳演算法，使得優化搜索在有限時間內變得可能。但依然逃脫不了兩個問題，1是定義編程目標依然非常繁瑣，而且還需要人為的提供全面的評估標準 2是僅能處理比較簡單的程序，稍微複雜的程序所需運行時間很長。這兩個問題導致了現階段使用這個方法依然需要耗費大量的人力，且只能運行簡單程序。

但即使這個文章的創新度有限，並且有很多技術上的障礙使得其實用性不高，我們還是要支持鼓勵這樣的實驗性項目。只有機器學習在不同領域落了地，我們才能最終迎來更加智能的AI。尤其是軟體工程領域的學者很多都對機器學習持懷疑態度，多一些類似的項目也可以促進不同領域的理解:)

同時回答一下題主的問題：首先，我沒有看到這個項目是Bloomberg和英特爾共同資助的，應該僅僅是文章作者的工作單位。我google了一下，猜測是作者的個人項目。至於是否抄襲了Github的項目(primaryobjects/AI-Programmer) ，明顯沒有。因為這個Github的所有者就是Kory Becker，也就是這篇文章的第一作者，是同一個人。顯然不存在什麼學術抄襲，不要總想搞個大新聞好嘛！

1. 這篇文章的思路是什麼？

簡單的說，作者想開發一個可以自動完成編程任務的機器學習模型，他們把這個模型叫做「人工智慧程序員」(AI Programmer)。作者在摘要中提到：「這是第一個可以在最低限度人類指導下完成編程任務的機器學習模型。」根據作者介紹，他們的項目可以實現的程序包括:

簡單程序比如輸出一行字元串，如"Hello World"、"Hi"等
相對複雜的程序比如：反轉字元串、斐波那契數列等

文章的主要賣點：1. 提出了一個「人工智慧程序員」模型 2. 使用了遺傳演算法(Genetic Algorithm)進行優化搜索 3. 模型可以在大部分普通機器上運行且僅需要最低限度的人類指導。

但我覺得這個描述不是非常準確，而且據我所知這也不是第一個使用優化演算法來求程序最優解的模型，而且依然需要大量的人為輸入和干預。我會在後文進行深入分析。

2. 文章中使用了什麼技術？

2.1. 機器編程語言：文章中使用的編程語言不是給人類設計的那一種(Human-intended Programming Languages)，比如Java和Python，而是一個叫做BrainFxxK的極小編程語言。如下圖所示，指令集(Instruction Set)由8個指令構成，分別用8個符號對應。所以Hello World經過這個語言的詮釋就是下圖中右邊那一串長長的符號。

作者使用的指令集是圖靈完備的(Turning Completeness)。在可計算理論(Theory of Computation)領域我們這麼定義，如果一個編程語言是圖靈完備的，那麼理論上這個語言可以在無限的時間和內存需求下完成任何計算機可完成的任務。但事實上尷尬的是，僅使用這8個指令導致作者發現在進行複雜任務時需要過長的時間，所以在處理複雜任務時，作者引入了更多指令集，暫時按下不表。

在實際計算中，作者用數字來替代符號，[0,0.125]代表符號&>，即指針加一。將符號平均的取在0-1之間為了易於使用遺傳演算法進行優化，但如果需要更多符號那麼對遺傳演算法來說有新的挑戰。如下圖所示，符號都是用0-1之間的數字來表示。

2.2. 遺傳演算法：遺傳演算法(Genetic Algorithm)是一種有指導的隨機搜索(Guided Random Search)演算法，主要被用於優化領域。和粒子群優化(Partical Swarm Optimization)、模擬退火(Simulated Annealing)、蟻群演算法(Ant Colony Optimization)、禁忌搜索演算法(Tabu Search)是主要的啟發式搜索演算法，這些演算法不要求目標函數連續可微，所以用途比較廣泛。遺傳演算法的思路主要是受到遺傳學啟發，簡單講遵循這個流程圖：

初始化「群體」，一般是隨機出 $m$ 個個體，假設每個個體攜帶 $n$ 個特徵。
通過評估函數(Fitness Function)對每個個體的 $n$ 個特徵評估來確定適應度 $F_{i= 1,2,3,..,m}$
根據適應度，對不同的個體進行不同的操作：

選擇(Survival)：對於適應度低的個體，直接從群體中淘汰中淘汰。對於表現優良的個體，繼續存活。
交叉(Crossover)：對於適應度高的兩個個體，交換其部分特徵產生後代(offspring)，就跟生物繁衍是一個道理。
變異(Mutation)：對於適應度高的個體，隨機改變其部分特徵。

不斷重複上述過程直到某個個體滿足了我們的需求。

遺傳演算法最大的好處就是在有限的時間中可以得到一個相對不錯的解，這也是大部分啟發式演算法的優點。選擇保證了我們淘汰了表現不佳的個體，變異、遺傳和雜交保證我們可以產生新的優良個體，方式陷入到局部最優，有更大的可能得到全區最(次)優解。

3. 「人工智慧程序員」到底怎麼寫出一個程序？

根據文章介紹，在使用AI程序員前，除了必要的硬體和準備工作，你還需要根據要實現的程序提供一些關鍵的信息。以Hello World程序為例，需要：

定義程序的要求：輸入格式和輸出格式。這個例子中就是輸出一行字元，不需要用戶有任何輸入。在更複雜的例子中，還需要列出程序運行中是否需要用戶輸入等情況。
給出適應度函數(Fitness Function)：即怎麼評估AI程序員得到的結果是我們想要的。在這個例子中，就是檢測 AI輸出的字元串長度是否等於11且字元與"Hello World"相符。在更複雜的程序中，用戶還需要給出程序的邏輯順序，比如 a. 要求輸入 b. 輸出一個字元 c. 要求另一個輸入。

我簡單畫了一個流程圖供大家參考：

簡單的說，就是初始化一系列「種子代碼」，每次用適應度函數計算每個「種子代碼」的質量。拋棄表現差的「種子代碼」，保留優秀的「種子」進行變異和雜交操作，產生後代。重複以上過程直到有符合我們需求的代碼出現。再一次，這個程序的核心就是用遺傳演算法進行啟發式隨機搜索。和我圖中表示的一樣，不良的個體會被去除(被斜線划去)優秀的個體會保留；變異過程中，某個基因從0.1變到了0.2，從">"成為了"&<"。

這個項目作者提供了Github代碼，框架是C#，作者在文章中給出了如何使用他們的框架。有興趣的朋友可以去primaryobjects/AI-Programmer自行嘗試。

4. 這個文章中的「AI程序員」可能存在什麼問題？

4.1. 極簡編程語言與遺傳演算法之間的「矛盾」

作者發現如果想實現相對複雜的程序，那麼使用僅有8個指令的編程語言需要很長時間。像上文提到到，雖然作為圖靈完備語言，這8個指令可以完成任何計算機操作，但代價是內存消耗和時間。在實現斐波那契等相對複雜一點的程序時，作者被迫引入了更多的指令集。但引入更多指令集的代價就是影響遺傳演算法的表現，換句話說如何挑選合適的指令集將會影響這個程序的表現，作者還無法給出答案。

4.2. 依然需要大量的人為干預

和作者在摘要中提出的不同，現階段的模型依然需要大量依賴人為干預。這主要表現在：1.需要定義適應度函數 2. 提供所有期待的輸入輸出值格式 3. 提供所有邏輯順序，如if/else等。換句話說，現階段模型會需要更多的時間來「節省時間」。

在模型和研究初期是可以理解的，但我懷疑對於複雜程序，人無法給出所有的邏輯順序和適應度函數，那這個方法還是否奏效？

4.3. 程序開銷與特例(corner cases)

作者發現當輸出結果的長度上升時，程序所需時間大幅度上升，如輸出「Hello world」所需要的時間是「hello」時間的5倍。這僅僅是字元串長度變化就帶來了這麼大的影響，當邏輯複雜度上升後，會不會程序會變得像NP-complete問題一樣。

作者同時提到有許多陷阱，比如「死循環」等，他們現在人為的限制了最大的運行次數來避免。作者提到在複雜情況下，用戶在適應度函數中還需要檢查編譯器的寄存器等。隨著程序複雜度上升，我懷疑可能會有更多的複雜問題是肉眼/直覺不可觀測或者解決的。

4.4. 創新性

越來越多的文章都打著「人工智慧」和「機器學習」的旗號吸引目光和資金，這是好事也是壞事。這篇文章中和人工智慧最大的關係可能就是使用了遺傳演算法，然而遺傳演算法更是優化領域的經典演算法，有標題黨之嫌。同理，如果我們將本文中的遺傳演算法替換成其他啟發式演算法，或許效果也非常類似，甚至更好。

作者在文中幾次提到這個項目是第一個人工智慧程序員，我覺得這個有點誇大的嫌疑，因為本質上應該叫遺傳演算法在軟體工程上的應用更貼合。但不管怎麼說，做研究做實驗是一方面，講故事也很重要。憑著作者在這個項目上已經超過五年，這種精神和毅力還是值得鼓勵的！

5. 總結

Becker的這篇文章提供了一個很有趣的應用實例，即如何用機器學習和優化演算法進行編程自動化。在我看來，這篇文章最大的貢獻是提供了一個自動化編程的框架，給出了一些設計實驗的參考。首先在選擇測試語言上，挑選較為簡單的編程語言較為可行。其次，要考慮到各種複雜情況，如死循環。

從機器學習的角度上看，這篇文章更貼近於試驗性質的可行性測試(feasibility test)，並沒有什麼理論突破意義。從實驗結果上來看，也看不到大規模的推廣的可能性。希望作者能把文章提交到peer review的會議上，得到更多的反饋，多聽聽同行怎麼說。如果作者能夠在後續的工作裡面真的能夠給出實驗結果證明在相對複雜的程序中，AI程序員所需時間低於普通的程序員，那麼這個工作才會得到更好的關注和應用。

親愛的碼農朋友，讓我們抱抱自己，飯碗暫時保住了 ?????

純技術的問題 @阿薩姆說的已經很清楚了。我稍微多說兩點吧：

首先這個肯定不是抄襲。對此我contact了一下http://primayobjects.com 的owner。以下是回復：

Thank you for reading the paper! Yes, the GitHub repository is the same project. You can also read more about the research on my blog at the link below. Thank you.
Using AI to Write Self-Modifying Improving Programs
http://www.primaryobjects.com/2013/01/27/using-artificial-intelligence-to-write-self-modifying-improving-programs/
Kory Becker

另外呢，關於這個方向我的感覺。

用極簡語言做ML的編程開發確實是一個比較好的思路。用BrainF做語言也確實比較容易提升這種速度。但是，我們都知道真正在編程開發中，維護用的時間遠遠多於開發的。

那麼問題來了，如果將來ML的程序真的是用這種極簡語言開發的，那麼怎麼維護呢？不管是計算機還是人類，維護起來，都會是極大的麻煩。

所以我個人感覺微軟的DSL的思路，更加接近正確的道路一點。用極簡語言往下走的話，到了一定的程度我相信會遇到一個坎。

並且，這個短時間內，應該很難做到代替人類編程。

可自動編程的人工智慧程序員，這都只能看著玩玩的，噱頭。

人都不能自動編程，何況程序？用眼睛看一幅圖，理解是直觀的，瞬時的，看一段話，理解是迅速的。程序員編程，是要推理的，是要抽象的，是要規劃的，是要「靈感突現」有突破的。

現在AI的水平是達到眼睛看一幅圖的水平了。離看一段話理解的水平還想去甚遠。

CNN重現眼睛到高級語義這個轉換，可以說基本上可用。

但用LSTM/Attention和CNN在NLP上搞搞，都還沒有抓到關鍵點，還不行的。還達不到「理解」這個層次。

只有NLP這個層次搞定了，後續才能搞邏輯推理，才有「人工智慧的程序員」這個概念，在此之前，都是越庖代俎，瞎弄的。

所以目前的所謂人工智慧程序員，只能從數控機床對照傳統機床的這個層次去理解。起這種名字噱頭太大，還不如之前微軟那個Deep Coder自覺點。

非常感謝 @阿薩姆對EA的的科普。

作為EA從業人士，稍微對 @阿薩姆提出的drawback進行分析與解釋:

" 4.1. 極簡編程語言與遺傳演算法之間的「矛盾」 "

這個問題本質是:複雜語言與複雜語言哪個搜索空間更小？這個不好說，但是肯定可以有tradeoff。這是一個非常有趣的問題。

"4.2 依然需要大量的人為干預"

切以這個問題並不大，按文中描述了給出fitness function的方法。雖然我不太認同他的方法，但是給出一個合理的目標函數，不見得會很難。而需要給出if else控制類語句純粹是因為文中使用了簡單語言。

"4.3. 程序開銷與特例"

EA在很多時候確實容易陷入特殊狀態而導致搜索不全面。但是，這絕對可以解決。具體事例要具體分析。很可惜原文並未深入討論此問題。

分割線________

以下是我對原文的一些看法:

總體來說，此文離發表還有很長的路，但是想法非常有意思，如果落在我手裡審，我絕對會是讓他修改，而不是拒掉。

1. CODING很不合理。採用real編碼會很低效。搜索效果完全與指令數目有關。並且丟失了coding前的真實含義。一種可能的編碼方式是轉為二進位編碼。可參見S. Dragon針對water distribution network 問題上設計coding的文章。(抱歉暫時忘記了名字日後補上)

2.搜索時間。這個是文章成敗所在。很可惜文章中僅給出了相對簡單程序的例子，但並沒有說明代碼長度與搜索速度關係。

____

說到最後，有很多人士喜歡抬高ML貶低EA，我不知道你勇氣何來。今年 Trans on Evolutionary Computation 影響因子10.6了你造嗎？

Genetic algorithms。。。。。。

雖說是這年頭流行炒古典AI演算法的冷飯，但你也不能隨便抓把土放鍋里炒一炒就端上來了嗎。。。。。

這特么連狗都不吃！

發表一下拙見：這就是標題黨。

看到遺傳演算法我就笑了，用這種暴力的搜索方式，正確的結果是建立在無數次的迭代之上的，而且收斂速度很難保證啊，給他個演算法問題，某一個運算符號差一點點，結果就差之千里的那種，甚至我懷疑他迭代一天都找不到解。然後為了避免這種問題，好把，可以人工干預，對於不同的問題修改一下適應性函數，不過連求個斐波那契數列都得人工干預了，任何問題都需要大量修改適應性函數，有寫適應性函數那個功夫，三下五除二的程序都編完了。

隨著項目代碼量，複雜程度的提高，複雜度增長是指數級別的，而且我們的項目編譯一次假設要1分鐘怎麼辦呢？迭代一萬次就要一萬分鐘？這程序一跑就是一個星期。。。

這個AI能做的事是那種隨便一個初級程序員一分鐘就能解決的，為了讓該AI去做某件事，可能要調試它很久，得不償失。

即便你說他是給出了一個demo，一種研究思路，但是我覺得這種方法不具有可拓展性，它只能解決a+b。

我根本就沒有發現這個東西的實際意義何在，我覺得就是噱頭。

現在什麼文章都可以往arXiv上放。

先不說作者關於這個論文的motivation在哪裡，如果沒有投會而是把自己的idea放在arXiv上，這件事本身想要引起關注的可能性大於真的想做contribution的可能性。可能想拋磚引玉，或者單純想要peer review。

在演化計算領域有一些古老而成熟的技術用於類似編程他的名字叫做 genetic programming。不知道作者為何不直接用gp來演化而要自己單獨用ga。此外，最近很多大新聞讓演化演算法和機器學習結合。做演化的，了解機器學習的當前是個大好機會

Genetic programming出來很久了如果加上早期在自動機上進行的計算智能就更早

沒有什麼很新鮮的東西

「AI啊，我想打的，但又懶得下樓攔。。。」

於是AI寫了個滴滴。

「AI啊，這公交怎麼等了這麼久都不見一個車來啊？」

於是AI寫了個車來了。

「AI啊，天天買東西都得花現金或者刷卡，多麻煩啊。。」

於是AI寫了個支付寶。

「AI啊，我最近老是睡過頭。。。」

於是AI寫了個鬧鐘提醒。

「AI啊，別人都是怎麼裝X的？我也想學學。」

於是AI寫了個知乎（逃

私以為，只有當一款AI可以實現上述情景時，它才配稱作可以替代程序員的人工智慧，它完全具備程序員的需求分析，問題建模，解決方案設計以及代碼實現的能力。而且說白了，如果AI具備這種能力，那應該啥事都難不倒它了，這種人工智慧造的出來，那應該是強人工智慧滿天飛的時代了，顯然現在還馬達馬達。。。

不過說實話，造出強人工智慧，怕不是程序員們的終極目標。革自己的命，從來都是最騷的。

看了下，發現是brainf**k語言。。。

而且用GA做這個也不是開創性的啊。。Lee Spector的Push和PushGP感覺比這個好多了呢。

看有的回答貼了圖，滿腦子brainfvck。。。。。

現在的做新聞的吶，聽到風就是雨。當真沾到機器學習沾到人工智慧就有個大牛逼可以吹啦，遺傳演算法這麼牛逼怎麼不算算怎麼去四維世界創造新地球咧？

人工智慧能寫程序嗎？

Can AI take the jobs from professional programmers?

Let"s see how computers write programs. Researchers created a simpler but Turing-complete programming language for the machine. The code can be represented by a gene which represent the whole code segment. The genes are mutated and results are checked, towards the goal of creating a piece of code that works.

This process is very different from human programmers. Humans need to first understand what to be written. This requires understanding of natural languages. Then, human programmers need to analyze the problem, and design the algorithm. At last, data structures are chosen and the code is implemented. Machines are not duplicated exactly the human activities for creating programs. So what are their pros and cons?

One of the pros is, of course, simplicity. We don"t know yet, but might hope that AI can rely on simple principles, and automatically "learn" to perform a tasks better and better, and eventually surpass humans, like AI Go players. The cons are, of course, if human languages are not plugged into the process, how do we communicate the requirements to AI programmers? Maybe each of them can only write the same code over and over again? Maybe it takes billions of years for them to evolve to write another program?

Therefore, what we need to do is not just finding a formal description of a robot that produces code for one purpose, but a robot to understand human requirements, think on its own, and then produce the code. This type of coding is beyond AI programmers right now.

In summary, AI programming research will depend on natural language understanding before making true progress. Current research is far from replacing real humans.

轉自作者專欄：人工智慧能寫程序嗎？

Huh? 這個玩意兒幾十年了吧？

最最最根本上和Evolutionary programming / planning 差不多