鮑捷博士於5月10日在將門創投的線上 talk 中盤點了人工智慧專案的大坑小坑，選出了看上去非常反常識的十個經典坑。
這是一篇大實話合集，但別絕望，最後將會放出從二十年踩坑經驗中總結出的彩蛋，共勉。
作者介紹
鮑捷博士，文因互聯 CEO。擁有20年學術界和工業界的相關經驗。美國Iowa State University人工智慧博士，RPI博士後，MIT訪問研究員，W3C OWL(Web本體語言)工作組成員，前三星美國研發中心研究員，三星問答系統SVoice第二代系統核心設計師。主要研究領域涵蓋人工智慧的諸多分支，包括機器學習、神經網路、資料探勘、自然語言處理、形式推理、語義網和本體工程等，發表了70多篇領域內相關論文。是中文資訊學會語言與知識計算專委會委員，中國計算機協會會刊編委，W3C顧問會員會代表。2010年以來關注金融智慧化的研究和應用，成果有XBRL語義模型，基於知識圖譜的基本面分析、金融問答引擎、財務報告自動化提取、自動化監管等。
以下為演講原文：
鮑捷博士：我今天的題目是《確保搞砸人工智慧專案的十種方法》，按照這十種方法，基本上可以搞砸專案。（笑）
之所以能夠講這個題目，是因為我自己之前也搞砸過很多專案，下面列表裡超過一半的專案最後是失敗的：
我開始想，為什麼大部分的專案最後做不成？
我經歷了好幾次很痛苦的時刻，比如剛到RPI（倫斯特理工學院）做博士後，這個學校有全美做知識圖譜最好的實驗室，實驗室的James Hendler和Deborah Mcguinness，都是這個領域最好的老師。
我在那裡做了一個知識管理系統，在我看來，我們是世界上最好的語義網實驗室，也是最專業的一群人，不用這個技術來武裝自己好像說不過去，所以我就做了一個語義檢索系統，但是後來沒有人用。
我就在反思到底問題在哪，為什麼這行真正最好的專家，做出這樣一個系統，連自己都不用？
我不停地在想，人工智慧專案失敗的核心原因到底有哪些？
當然，後來經歷了更多的失敗。基於這些直接或者間接失敗的經歷，我逐漸總結出來確保一個專案會失敗的一些原因。這些原因很多時候看起來是反直覺的，我會逐一地跟大家講。
在最後，我也會總結如果想要避免這10個坑，應該做什麼。
NO.1 一下子砸很多的錢
第一種確保你的專案失敗的方法：一下子砸很多的錢。
我目前也在創業，有VC問我：“你們做的這個事，如果BAT砸很多的錢，是不是就一下子能趕上你們？”
我說不會，通常舉的例子，就是日本的五代機。當初日本舉全國之力，砸了幾百億日元，最終沒有做成。
五代機是什麼？1970年代末是人工智慧的第一次冬天開始回升的時候。80年代開始進入人工智慧第二個高峰。這時候，日本啟動了一個新的專案，叫第五代計算機。
什麼叫第五代計算機？前四代計算機，分別是電子管的、電晶體的、積體電路的，和大規模積體電路的。日本到第五代計算機的時候，他們認為要想做人工智慧，就必須用人工智慧的專有硬體。
（《知識資訊處理系統的挑戰：第五代計算機系統初步報告》中第五代計算機系統概念圖）
這個話是不是聽起來很耳熟？最近在做深度學習的時候，看到了很多關於深度學習晶片的想法。這個想法並不新，因為在30年前，日本人在五代機的計算裡，就已經有這樣的想法了，只是當時的人工智慧晶片，不是現在深度學習的晶片，而是Prolog的晶片。
Prolog是人工智慧的一種語言，主要是一種邏輯建模語言。如果能夠用Prolog來建計算機，計算機就可以進行思維，可以處理各種各樣認知的任務。這是一個非常大型的國家專案，最終花了幾百億日元，耗掉10年時間以後，在1992年，終於勝利地失敗了。
這不是個例，很多大型的專案，最後都失敗了。
一開始砸很多錢，為什麼還會失敗？你要想，做一個專案，通常是有目標的。當你有一個大預算的時候，你的目標通常也定得很高。像五代機的目標，不單當時是做不到的，三十年後的今天，也是做不到的。
雖然五代機失敗了，但是日本的人工智慧技術，在五代機的研發當中得到了很大的提升，所以到了20年後，語義網興起的時候，日本的語義網研究水平還是相當好的，那些錢沒有白花，它培養了很多的人才。
在日本做五代機的同時，美國也有類似的研究，主要是LISP machine，LISP是人工智慧的另外一種語言，也是邏輯建模的語言。其中有一個公司叫think machine。當時至少有100家LISP公司。
為什麼單獨要提到think machine？創始人在失敗之後沉寂了一段時間，開了一個新的公司叫MetaWeb，MetaWeb是2005年的時候成立的，這個公司有一個產品叫Freebase，用Wikipedia做了一個很好的知識庫。
2010年這個公司被谷歌收購，改名叫谷歌知識圖譜。所以今天谷歌的知識圖譜有很多歷史淵源，可以追溯到30年前LISP machine的研究裡面。
羅馬不是一天建成的，所以一下子砸很多錢，就會導致專案的目標過高，從而導致這個專案有極大的失敗機率。
我曾經遇到過一個大型國企的人，他跟我說，他們要花3000萬建一個企業內部知識管理系統。我就問他，你那個3000萬是怎麼投的？他說我第一年就要投3000萬。然後我沒說話，因為我的想法是這個專案一定會失敗。後來這個專案的的確確失敗了。
也有一些大公司投比這還多得多的錢來做AI專案。這些都不一定讓事情更容易成功。
這是第一種方法，一下子砸很多錢。
NO.2 根據最新論文來決定技術路線
第二種方法：根據最新的論文來決定技術路線，這可能也是一個反常識的事情。
因為最新的技術不是最好的技術，要注意，在工程領域裡面，通常面臨著實際的約束來解決問題的。而論文是一種實驗室的環境，是不一樣的。
比如說實驗室裡，可以假設有一些資料，可以假設這些資料已經被整合了，被清洗了，是沒有噪聲的。可以假設目標是清晰的，但所有的這些假設在現實中都不一定成立的。
最好的例子，就是資訊抽取，這是2013年的EMNLP上的一篇文章，我拆出來的圖。
這個圖告訴我們做NLP的論文和實際的工業系統所採用的技術路線有什麼不一樣的地方。
從2003年到2012年整整10年，學術界所發表的自然語言處理論文的實體抽取子領域裡，完全用機器學習的方法論文佔到了75%，混合機器學習和基於規則的方法論文佔到了21%，完全只用規則方法的論文，只有百分之一點幾，非常低的比例。但是當看到工業界的實際應用的時候，發現了完全不同的技術佔比分佈，用規則方法的佔到了45%。
如果光看大型的供應商，比如說IBM這樣的公司，67%的軟體是完全基於規則方法的。完全基於統計方法即machine learning方法的軟體，在所有的供應商那裡佔33%，在大型的供應商那裡只佔了17%。
所以從學術界的研究到工業界的實踐，有一個非常巨大的差異。為什麼會有這樣的差異？就是我剛才提到的，在發表論文的時候，完全不需要考慮現實中所會遇到的那些約束條件。在知識提取、實體提取領域，儘管現在從理論上來說，已經解決了，比如說實體識別問題、NER問題、分詞問題，但是到了真正現實的語料中，發現這些方法都不好用。這也可以用另外一個問題來驗證這一點，就是問答系統。
今天看到大部分的論文——我沒有做精確的統計，只是基於模糊定性的看法——能看到大部分發表的問答系統的論文都是基於統計方法的。特別是這兩年基於NLP的方法，尤其是基於端到端的方法的。無一例外，能夠真正在工業中應用起來的問答系統，除了小冰這樣的閒聊系統之外，真正的面向解決任務型的問答系統，全部都是用規則系統的。我還不知道哪一個是用深度學習的，當然也可能有用在某一個具體的細節，或者某一個元件上面，我沒有見到過用於整體架構上。
所以當決定一個工程問題技術路線的時候，不一定要按照最新的論文趨勢來做這件事情，甚至，論文和十年之後的技術都不一定有相關性。一定要根據現實的情況，根據現實的約束，來決定技術路線。
NO.3 脫離真正的應用場景
第三種方法：如果脫離了真正的應用場景，專案就註定會失敗。
這裡我用OWL2來說明。OWL2是一種語言，對於做語義網的同學們很熟悉了。
在Web上所知道的所有的這些標準化的格式，比如說HTML都是W3C，即全球資訊網聯盟設計的。全球資訊網聯盟也會負責Web上其他的協議，其中有一個協議叫OWL。它是在講，在網際網路上如何表達我們的知識。
比如說，一個餐館要釋出它的選單，該用什麼樣的格式來發布？或者我現在要在網上釋出我的簡歷，希望被谷歌更好地檢索到。我要告訴谷歌，我是一個人，我姓什麼，叫什麼，出生年月是什麼，我應該用什麼樣的格式釋出這樣的資料。其中一個格式就是OWL。OWL的第一個版本在2004年釋出，第二個版本是在2010年釋出。
OWL WORKING GROUP比較活躍的工作組的成員裡面，有相當多的知名大學的老師，還有一些知名公司的科學家，包括IBM、Oracle、惠普。你們注意到，我剛才提到這些大公司的時候，有一些名字沒有出現，比如說谷歌和Facebook。
OWL2本來希望想做的事情，是設計如何在網上表達併發布日常生活衣食住行資訊的。但是，最終工作組成員的構成，一種是大學研究人員，另外一種是大公司做企業級應用的，大部分是遠離場景的。
最終設計出來的產品，也就是OWL2語言，脫離了真正想去服務的那個場景。OWL WORKING GROUP在開會的時候，寫了大概好幾十個應用案例，但是大部分的案例都是這樣的：一個製藥公司要做一個藥，應該怎麼表達製藥的知識，或者一個醫生如何表達病歷、疾病或基因，大體上都是這樣的應用。沒有任何一個案例是在講述在網上如何找一個朋友，或者如何跟朋友聊天，或者如何去訂餐，日常生活中的案例都是沒有的。
OWL2最終寫出來以後，有600頁紙，這是一個非常複雜的語言。事實上，也就是在一些少量的企業級應用裡面被用到了，在真正的日常應用當中，成功的案例幾乎沒有。這就是個典型的脫離了應用場景的專案，所以這個專案，花了很多錢，最終沒有達到真實想達到的目標。
NO.4 使用過於領先的架構
第四種方法，使用過於領先的架構。
這也是跟前面第二種方法相呼應的，第二種方法說，你不能根據最新的論文來決定你的技術路線。第四種方法是在講，如果你使用了一種特別先進的架構，反而有可能導致你的專案失敗。
Twine在2007年被稱為世界上第一個大規模的語義網的應用。當時是一個明星企業，這個公司到了2010年的時候關門了。為什麼？Twine在成立的時候，想做一個語義書籤的應用。比如說我讀了一篇文章，我覺得很好，把它儲存下來，留著以後再讀。Twine的機器人就會分析我儲存下來的這篇文章到底在說啥，然後給這個文章一個語義標籤。如果有人訂閱了我的標籤，他就可以不斷地看到我這個標籤下收藏的好東西，就這麼一個想法。
Twine在底層用了一個叫RDF的新資料庫，RDF是一種語義網的語言，比關聯式資料庫增強很多，它是可以進行推理的資料庫。但是當Twine使用者量達到200萬的時候，它就遇到了一個瓶頸，資料庫的效能不夠。所以Twine的CEO就決定，開發一個新的資料庫。
當時這個公司大概是40個人，用20個人來研發基礎性的東西——一個新的語義資料庫。2008年的時候，情況還不錯，他們發現自己做的東西是個很好的東西，突然就在想，我們做的東西為什麼只搜尋書籤？完全可以搜尋整個Web上的東西。於是他們就做了一次轉型，去做整個Web的語義搜尋。步子太大，就把公司拖死了。到了2008年經濟危機爆發的時候，資金鍊斷裂，撐了一年以後就死了。
在死的時候，Twine的CEO Nova Spivack ，是我們領域非常值得尊重的一個先行者，也是一個技術大拿，同時也是一個非常成功的投資人。他就檢討了Twine的失敗。他說我試圖在太多的地方進行革新，我應該要麼革新一個平臺，要麼革新一個應用，要麼革新一個商業模式，但是我似乎在太多的地方都進行革新了，而且我使用了一種非常超前的架構，就是RDF資料庫，導致了我要追求的目標太大，我無法達到這個目標。
我想他說的這個話，即使到今天，也是非常值得思考的。
這個專案相關的分析文章，我差不多每過兩年都要仔仔細細地看一遍。Twine失敗了以後， Nova Spivack 對公司進行了一次轉型，成立了一個新的公司叫 Bottlenose，還是用了同樣的技術，用在了更聚焦的應用場景上，從2C的服務轉到2B的服務上去。
Bottlenose這個公司，到目前為止已經8年時間了，還是很成功的。2B的應用相對而言不太需要這麼大量的資料，不用解決系統可伸縮性問題，突出了這個系統最核心的優勢，即語義分析和理解能力。
像Twine這樣失敗的例子是不罕見的。用一個過於先進的架構的時候，通常會面臨一開始很難去預期的一些風險，甚至不僅僅是像RDF資料庫這樣的小眾的產品，更加大眾的產品，也有可能會遇到這樣的情況。
比如說有人經常會問我說，你們做知識圖譜的應用，是不是一定要用圖資料庫？我就通常回答說不一定。
如果你熟悉圖資料庫，比如說你對 Neo4j 整個運維都非常地熟悉了，你知道它的JAVA虛擬機器如果出錯的時候，該如何處理；你知道它記憶體不夠的時候，該怎麼辦；你知道怎麼進行資料的分片，知道怎麼進行主從的複製……所有這些運維問題都很熟悉的時候，你就可以試一試上這個應用。
在上應用的時候不要太著急，如果你只是一個線上應用，可以放一放，先把離線的這部分運維的工作搞清楚以後，然後再上線，也可以先用一個小資料集試一試。總之，步子不要太大。
NO.5 不能管理使用者預期
第五種方法，不能管理使用者預期。
這是一個特別常見的專案失敗的原因，甚至不是因為技術上做不到，而是使用者預期更大。
我先說一個技術上完全做不到的，比如說有一個銀行，他們推出了所謂的機器人大堂經理，你可以跟一個機器人對話辦理業務。顯然，這個東西如果真的能夠做到，應該是非常令人吃驚的事情，這已經遠遠超出當前技術邊界。
最近有一個比較有名的騙局，就是機器人索菲亞。沙烏地阿拉伯還給了它第一個公民的身份，這是一個非常典型的詐騙。
這種型別的機器人是不太可能出現的。
在其他應用當中也會遇到這樣的情況，尤其是對話機器人是最容易引起使用者的圖靈測試慾望。當使用者發現跟他對話的是一個機器人的時候，他就會試圖去調戲這個機器人。比如很多人都會去調戲siri，所以siri積累了很多段子，準備應對大家調戲。
如果你是提供了一個搜尋引擎，那麼大家的預期是比較低的。但如果你以一個問答引擎的形式，提供同樣的內容，大家的預期就會高很多。
我們最早提供了一個終端級產品，使用者的評價就不是特別好，後來我們調整了一下定位，把它調整成用搜尋介面來提供服務，系統頂層的智慧程度沒有太大改變，但是使用者的預期和評價馬上就好起來了，因為使用者預期降低了。這樣的語義搜尋引擎，相比其他的搜尋引擎，其實還是好一些的。
對話機器人其實也一樣，如果你給使用者的預期，是能夠跟他平等對話的機器人的話，通常是很難達到的。使用者通常玩一玩就會發現好傻，然後就不玩了，所以大家注意到谷歌機器人跟Apple的siri機器人定位有很大區別，谷歌機器人不僅僅做對話，它能夠預先幫你去做一些事情，甚至主動地去幫你做一些自動化的事情，其實這是非常聰明的選擇。
目前能夠跟人長期進行互動的機器人，其實是一個更加偏秘書型的，或者說它就是一個幫助你進行任務自動化的機器。如果你是立足於對話，其實很難滿足使用者預期，但是如果你立足於自動化，就比較容易達到使用者預期。同樣的技術，你用不同的方法去服務使用者，使用者預期不一樣，使用者的感覺就完全不一樣。所以要儘可能地讓使用者感知到產品的成熟度，在他的預期之上，這個產品才有可能成功，他才願意付費。
NO.6 不理解認知複雜性
第六點叫做不能理解認知複雜性。
這個事情我在剛開始的時候就提到了，這個例子就是Semantic Wiki，我寫了很多個這樣的系統，Semantic Wiki是什麼呢？大家肯定都用過維基百科或者百度百科，這只是一個典型的維基系統，有很多人去寫一個頁面。Semantic Wiki也是基於協作的，也是一個Wiki，只不過在這個Wiki的頁面上，你可以打一些標籤，加一些註釋。
它可以解決什麼問題呢？比如可以解決頁面之間的資料一次性問題，就是一個頁面上的資料，可以流到另外一個頁面上去，舉個例子，比如說在維基百科上面，可以看到很多國家的GDP，就是國民生產總值，在中國的頁面上，會有中國GDP，在亞洲國家的GDP列表上面，也會有中國GDP，然後在世界國家的GDP列表上，也會有中國GDP，那麼是不是可以有一個機制，比如在一個頁面，寫下中國的GDP是多少，只要這個數字改變，其他所有頁面上的數字會同步改變，用Semantic Wiki技術就可以做到這一點。當然Semantic wiki還可以做很多很酷的其他的事情，很強大。
我從2004年開始就開始寫Semantic Wiki系統，前前後後寫了三個Semantic Wiki系統，後來我加入了一個開源社群，叫 Semantic MediaWiki， 基於這樣的系統，我做了一個很好的知識管理系統。
2010年我們試圖來推廣這個系統，當時是做了一個實驗，也是一個美國的國家機構委託我們做的，就是要測試用這種協作的知識管理系統來記錄一些事件，能不能記錄得很好，好到可以後面讓機器自動進行處理。
當時做的對比實驗是找了一群RPI的計算機系本科生，讓他們來看電視連續劇，看完以後描述情節。一部分人用自然語言來進行描述，一部分人用Semantic Wiki，以更加結構化的方式來進行描述。然後再找了學生來分別閱讀前兩組學生的描述，最後讓他們來做題，看哪個組能夠更精準地來複原電視劇情節。最後得到的結果發現是用自然語言描述是更容易，就是描述得更精準，速度更快。
然後我們仔細去看那些學生寫的結構化的描述，發現是錯誤百出，比如說張三擁抱了李四，對於一般的所謂有過知識工程訓練的人來看，很明顯擁抱應該是一個關係，張三和李四應該是兩個人，一個是主語，一個是賓語，那麼就應該是主謂賓，張三擁抱李四是很清楚的一個知識建模，但是相當多的學生，他們把這麼一個特別簡單的建模就給搞錯了，他們沒有辦法理解什麼叫概念？什麼叫關係？什麼叫屬性？甚至他們不知道什麼叫主語和賓語？然後發現在一開始設想這件事情的時候，忽視了絕大多數的人，在他們的教育生涯中比如高中教育裡面，是沒有結構化思維的訓練的，這是一種事先無法意識到的認知複雜性。
由於我們都經過十年以上的訓練，所以就完全把這些東西當成是天然的事情。後來在OWL WORKING GROUP也遇到了同樣的事情，有人說這個東西太複雜了，其中有一個邏輯學家就抗議說，這東西不復雜，這東西在計算機上跑的時候，它的演算法複雜性只是多項式複雜性而已，然後我聽了這句話以後，突然意識到了一個事情，就是在這些邏輯學家的腦子裡面，他們所提到的複雜性是指一個語言對於機器的複雜性，所以我們通常把它稱為計算複雜性。
但是實際上普通人所理解的複雜性不是這樣的，比如說你半頁紙就能說明白的東西，那是一個簡單的東西，如果讓我看到20頁紙，才能看明白，那這個東西是一個複雜的東西。所以一個技術，你能不能夠讓程式設計師用起來，能不能讓使用者用起來，最核心的事情，你是不是能夠讓他們在認知上面覺得這東西，一看就懂，一聽就懂，一開啟就懂，不用解釋，這才叫簡單。
在很多演算法的設計上面也好，文件的設計上面也好，應用的設計上也好，它最終能不能用得好，關鍵是讓人感覺到它簡單好用，這就是一個很重要的因素。史丹佛Parser，為什麼在NLP領域裡面被用的這麼廣，一個很重要的原因，它的文件寫的好，每一個類都有文件，提供了足夠多的案例。
所以好的文件可以極大地降低一個產品的認知複雜性，即使你的產品本身是複雜的，你把文件寫好，也足以有助於推廣這個產品，所以儘可能地讓能夠接觸到你產品的人，不管是搞語言的，搞技術的，搞演算法的人都感覺到這東西簡單，是保證你的產品成功的一個關鍵。
NO.7 專業性不足
第七點，這一點就很好理解了，專業性不足。
我經常會遇到這樣一些人，說某某公司現在想做一個問答系統，希望投入三五個人，可能大多數情況下沒有博士，多數情況下可能就是一個工程人員，試圖很快的時間，兩三個月之內，甚至三五個月之內，把這樣一個東西做出來，也是一種幻想。當然我不會直接說破。
人工智慧產品，的的確確是有它的專業性的。很多機構想試圖自己去做這樣的事情，花了1000萬、2000萬、3000萬冤枉錢，結果做不到。確實，如果沒有一個足夠專業的人是很難把這種事情給做成的。
我也經歷了很多這樣的事情，在曾經做過的一個語義理解系統裡面，也經歷了這樣的問題。我想能夠完成這樣一個系統，實際上是要綜合很多不同的演算法，不是一個演算法就能夠解決掉的。比如說，從正面的例子來看，IBM Watson 系統裡面有幾十種不同的演算法，有機器學習的演算法，有自然語言處理的演算法，有知識圖譜的演算法。你要把所有的這些演算法恰到好處地組合在一起，拿捏的尺度就是一個特別重要的能力。你該用什麼樣的東西，你該不用什麼樣的東西。
比如說規則系統，任何一個人都可以寫10條正規表示式，這是沒有問題的。但是如果你能夠寫好100條正規表示式，那你一定是一個非常優秀的工程人員，你的軟體工程能力很過硬。如果你能夠管理好1,000條正規表示式，那你一定是一個科班出身的，有專業級的知識管理訓練的人。如果你能夠真正地管理好10,000條正規表示式，那你一定是一個有非常豐富的規則管理經驗的人。
當然我說的1,000條、10,000條，並不是說你 copy paste 10,000次，改其中幾個字，那個不算。人工智慧的很多事情，困難就在這兒。你到網上去拿一個什麼開源包啥的，你把它做到80%，都很容易做得到。但難度就在於最後的20%，通常可能需要98%、99%的正確率，才能夠滿足使用者的需求，但是如果專業性不夠，最後的這些點是非常難的。
打個比方說，你要登月的話，你需要的不是梯子，是火箭。你搬個梯子，最後只能爬到樹上去，再也沒辦法往上走了。你需要的是停下來造火箭，造火箭就是專業性，如果專業性不足，你永遠只是停留在80%的水平上，再也升不上去。
回到剛才講的語義理解的專案。當時就遇到了蠻多困難，要能夠整合規則的方法，整合統計的方法，整合自然語言處理的方法。當時全球有很多實驗室一起來做這件事情，但缺這樣一種角色，能夠把所有的尺度拿捏得特別好的。
其實IBM把Watson系統做出來，也是經歷了很多內部變遷，包括專案管理人的變化，包括各種技術選型的變化，能夠做到這一些，這種人才是非常短缺的。在中國，能夠真正從頭到尾把一個語義的理解系統架構做好的人，是非常非常少的，也許10個，也許20個，數量確實不多。我相信在其他人工智慧領域，也面臨著同樣的情況。
專業性也不會僅僅只侷限於程式或者技術這一塊，人工智慧的產品經理，人工智慧專案的運營，還有整個後面的知識系統，資料的治理，都是需要很專業的人來做，現在這些人才都非常地短缺。
NO.8 工程能力不足
第八種方法就是工程能力不足。
我的博士論文是一個分散式推理機，但因為程式設計能力不夠，一直到我畢業為止，都沒有能夠把它實現出來。當然後來到了2012年、2013年之後，圖計算，包括基於訊息交換的圖計算出來之後，那時候我再來做分散式推理機就比較容易了。
但這是我特別大的一個教訓。
在這之後，我就比較關注，如果做一件事情，先能夠把我的工程能力補足。這個工程能力，包括軟體工程能力，如何寫程式碼，如何管理程式碼，如何做系統整合，還有迴歸測試，如何進行程式碼的版本控制等等。後來我面試人的時候，也比較關注這些東西。
一個人工智慧的技術能不能做得好，核心往往不僅僅是演算法，而是底下的架構，還有系統。比如論文中其實是很好的分散式推理演算法，但是我因為缺少這個架構，就沒有辦法把這個東西實現出來。後來像深度學習也是這樣的。最近看到陳天奇他們的實驗室，把演算法、架構、作業系統都放在一個實驗室裡面來運作，覺得這是一個特別好的事情。目前演算法和架構之間的裂縫太大了。
工程是解決人工智慧的核心鑰匙。如果程式碼能力不行，架構能力不行，工程能力不行，在這個情況下，根本就不應該去談演算法。優先應該把工程能力補起來，然後再談演算法。
NO.9 陣容太豪華
第九點，陣容太豪華。
這一點不太好說具體的專案是什麼，太敏感了。
但是我就從邏輯上給大家講一下。因為一個專案如果太豪華，核心的問題就是沉沒成本。
我們也經常看到一些初創公司，不管是從商務上，還是從技術上，特別優秀的人組成了一個公司，最後還是會失敗。為什麼？因為比較優秀的人，就是想要做大的事情。一個大的事情，很難一下子就做對。通常大的事情，是從小的事情成長起來的。如果我們不能夠讓豪華的陣容，從小事做起，通常這樣一個事情是會失敗的。
邏輯很簡單，我就不多說了。
NO.10 時機不到，運氣不好
第十點，我可以把所有其他的因素丟到這兒，就是時機不到、運氣不好。
其實可以把所有其他的事情都歸結為運氣不好。
比如說我們現在看深度學習，比如像attention、卷積、LSTM、聯想記憶等等所有這些概念在90年代，我讀研究生的時候，這些概念都已經有了，但是當時是做不到的。當時即使有了這些演算法，也沒有這樣的算力，即使有了這樣的算力，沒有這樣的資料。
在2000年的時候，我在碩士畢業之後，就在研究一種分層的多層神經網路。我們把它稱為hierarchical neural network，跟後來深度學習的想法非常接近。我帶著這個想法，去見我的博士導師。說我想繼續沿著這個方向往前走，但他說現在整個神經網路都已經拿不到投資了，你再往前走，也走不下去，所以後來就放棄了這個方向，準備做語義網了。10年之後，這個方法終於找到了機會，後來就變成了深度學習的東西。
很多時候，時機不到，即使你有這個演算法，你也做不到。90年代的神經網路，差不多花了10年的時間，才等到了自己的復甦。
知識圖譜也是一樣的，知識圖譜大概也等了十幾年的時間，到了最近這幾年才真正地得到了大規模的應用。
總結
讓我們來取個反，做個總結：
最後一點，時機和運氣再囉嗦一下。
很多時候，我們是真的不知道這件事情能不能做得成，也真的不知道，自己處於什麼樣的歷史階段。很難預言未來是什麼，但是至少有一點，如果我們多去了解一些演算法層面的發展，包括人工智慧的發展史，包括相關的這些技術的發展史，能夠更好地理解未來。
所以我也推薦一下尼克老師的《人工智慧簡史》這本書。我看了兩遍都挺有收穫的。看了這東西，能更多地理解什麼是時機，什麼是運氣。
有時候我也經常會讀一些經典的文章，十年前或20年前的書，我讀了還是挺有啟發的。比如說，今年我又把Tim Berners-Lee《編織全球資訊網》那本書又重新讀了一遍，讀了一遍以後，我就堅定信心了。
知識圖譜這樣一個互聯全世界的記憶的系統，大機率到2030年能夠實現，這還是一個很遙遠的時間，但是根據歷史規律，應該到2030年能實現了。
一方面，降低我們現在的預期，另一方面也給我們前進更大的鼓勵。
場景躍遷理論
剛才反反覆覆提到了，要控制使用者的預期，控制自己的預期。做一個專案，要從小到大，循序漸進。最後把所有的東西抽象到更高層面上，我自己總結為一個理論，叫場景躍遷理論。
這個理論的核心，是說一個人工智慧的公司需要多次的產品市場匹配，就是Product-Market Fit。如果提供了一個產品，市場恰恰需要，而這個市場恰恰又很大，就說得到了一個產品市場匹配。
經典的網際網路創業，通常做一次產品的市場匹配，就可以成功了。但人工智慧往往要做好幾次，網際網路公司和人工智慧公司很不一樣。
一個稱為養雞場模式，一個稱為養小孩模式。
網際網路公司是一種養雞場模式，它是一個大規模的複雜系統Complex system。它的關鍵是可擴充套件性。我養了一隻雞，我發現這隻雞不錯，我養1萬隻雞，這就是養雞場模式。核心就是如何能養一萬隻雞，這就叫可擴充套件性。
人工智慧應用是另外一種型別的複雜系統，叫Complicated system，它是有非常多的元件，通常是上百種奇奇怪怪的元件組合在一起。它的核心並不是養一萬隻雞，更多像養小孩一樣，生完孩子，從小給他換尿布，給他餵奶，教他走路，教他說話，逗他玩，小學、中學、大學，一路把他養大，每一個階段所面臨的主要任務都不一樣。你如何能夠讓這小孩成長，我們把它稱為可演進性，這才是AI公司最核心的因素。
把一個AI的公司給養大，其實是特別不容易的事情。就跟養小孩一樣，往往前5年的時間，都在搭團隊，搞基礎，特別辛苦。公司存活的觀念就是，如何能夠在演進的過程中，逐步地掙錢，而不是試圖一步到位地找到市場產品結合點。不僅僅是在人工智慧的階段要掙錢，在人工智障的階段，也要能夠掙錢。
沒有一個完整的系統，怎麼能掙錢？只能夠把系統中的某些元件拿出去，做部分的商業化。就好像毛毛蟲到蝴蝶一樣，毛毛蟲要蛻皮，蛻好幾次，才能變成一個蝴蝶。毛毛蟲階段，它要吃樹葉子，在蝴蝶那個階段，它是要吃花蜜，所以它在兩個不同的階段，它的商業模式是完全不一樣的。人工智慧公司也要蛻好幾次皮。在早期的時候，因為產品還不夠完善，所以人工智慧公司早期都是外包公司，這是正常的，就應該接受，這是發展必經的階段。
總結今天所說的一切，人工智慧是一種新興的事物，它是非常複雜的東西。很難用傳統的舊經驗來套這樣一種東西的發展，必須經過很長時間的演化，才能夠達到成熟的狀態。而這個演化力才是我們想做一個成功的商業的嘗試，最關鍵的因素。如何保證在一次又一次的場景躍遷當中，團隊不散架，這樣的能力，才是決定了某一個商業上面能不能成功的最大的關鍵。
我覺得不僅僅是商業，不管是在學校裡做研究也好，還是在大型跨國公司裡做研究也好，很多道理都是一樣的。就是如何能夠循序漸進地，從小到大地來做，謝謝大家！