爲什麼人工智能助手更像人工智障？真相了
在確定這個話題之前，有必要先對羣嘲做個限定：
現在：在“API困境”被解決之前（後詳）。
人工智能助理：這裡指的是Intelligent personal assistant/agent (IPA) 又稱爲Virtual Personal Assistant/Agent(VPA)——幫助個人完成多項任務或多項服務的虛擬助理，當前討論的核心驅動力是人工智能。（什麼你說用人來做處理單元？那是呼叫中心，也叫客服，最看不起掛羊頭賣狗肉的了。）
都是坑：創業公司做消費端的虛擬助理，一定無法實現消費級產品效果。對於巨頭也是，我相信大部分的相關負責人都以“進步”爲目標，而不敢跟自家CEO擔保要以“搞定”爲目標。
【什麼是智能助理？】
智能助理屬於對話式服務
兩者的邊界不是很清晰，智能助理的功能在前面解釋過了；而“對話式服務（conversational service/commerce）”——這是包含智能助理在內的多個產品形態的統稱，核心特點是：
對話式：人機交互的方式由圖形化交互（GUI-Graphical User Interface）變爲以對話作爲交互方式（CUI-Conversational User Interface業界暫時還沒有定義，這是我自己瞎編的），就是用說話來代替觸摸或者鼠標，操作計算設備。
服務：提供服務，解決問題都算，如訂機票，購買禮物等。不包括信息查詢（如天氣）。
Facebook M, 真人和AI結合的服務
去年（2015）起來的這一波對話式服務在硅谷有多火？看看創業團隊增長的數量就知道了：2015年的時候有129個類似的項目出現，而14年的時候才42個。
Tracxn Report:Conversational Commerce
在各類科技博客上，對Conversational Commerce的討論也非常熱烈，尤其是在medium.com上有大量的探討。基本的觀點就是”對話式的交互將會成爲下一個風口，大家趕緊上啊！“。截止到2016年6月的時候，在Producthunt上標記爲對話式服務（ConvComm）的有一百多個創業項目。
除了智能助理以外，還有很多類似的概念如digital agent，bot，service bot, chatbot，P2P的電商。比如Operator現在用真人專家幫用戶做消費決策，在過去嘗試過用bot/AI但可惜達不到效果，或者magic模式，完全是靠”真人幫懶人用APP“驅動運營。本文主要討論的是基於人工智能的智能助理——就像IBM提到的一樣，只有如此才能真正規模化。
智能助理應該解決服務需求
巨頭的人工智能助理基本都已亮相了：
Facebook M
Amazon Echo
Google Assistant, Allo
Apple Siri
IBM Watson
Microsoft Cortana
以上智能助理的服務範圍大都是在信息檢索，幫助用戶獲得資訊。絕大多數的內容是不牽涉“推理”的查詢類信息服務。比如：
1）明天的天氣如何？
2）找附近的星巴克在哪兒？
3）蘋果的股價如何？
如果用戶問到在基礎信息以上，一旦牽涉推理的問題，就無能爲力了。比如：
1）明天這個天氣狀況會會造成航班延誤麼？
2）我只有支付寶，附近的星巴克可以用麼？
3）我什麼時候該買蘋果的股票？
使用體驗方面，這些助理的服務範圍覆蓋面基本跟當前的所有引擎一樣。在設計邏輯上，基本都是基於用命名實體識別來代替打字輸入關鍵詞然後返回檢索結果SERP。而信息檢索，離人們要完成的服務需求有很大的區別。就好像viv.ai的聯合創始人Dag Kittlaus 說的，當初他創建siri的時候，是想要重新挑戰移動服務，而不是造一個chatbot。
Dag Kittlaus 中間
除此以外，巨頭的助理與其關聯的生態產生操作的關聯。比如SIRI對iOS和macOS的操作；Cortana對windows的操作；echo對關聯着的智能家居設備的操作等等。此類操作的一個特點，是對結果非常的確定，出現個性化選擇範圍非常的少。
另一方面，對於創業項目而言，因爲不具備類似的生態和硬件入口的條件，大都定位在資訊和服務上。我們選擇Producthunt當中排在最前150位的項目進行分析，其中高達70%的項目定位都在2C的個人助理（agent）上，其中大部分都想做切入服務，包括垂直類的和多任務的。
這些助理服務當中有23.1%是專業類型的服務，主要是在醫療和理財方面。而剩下來的76.9%的助理乾的最多的活兒是生活上的綜合幫助，出行安排，日程管理，購物訂餐廳等等——這一類是坑最大的地方——特別是那些試圖把生活上的各種服務都打包進去的產品。
Producthunt上面69.7%的對話式服務都是智能助理產品（但並非所有都具備AI）
【人工智能助理的潛力】
移動紅利的結束，行業需要新的增長點
很多跡象都指向同一個結論：移動互聯的高速增長已經飽和。比如用戶已經不再願意下載新的APP。
qz (based on comscore data) & statista
2016年1月有超過5萬個新的APP被提交到了appstore，但是在美國市場有65%的智能手機用戶在一個月內下載新APP的數量爲0，下了1個新APP的人佔8.4%。
2015年中到現在，在國內2C市場中，幾乎找不到一款真正能爆發並留存的移動產品。對於移動開發者而言，能放首屏的高頻應用早就擠不進去了。而且很多中低頻的服務，並不是最適合用app來承載的。比如訂生日蛋糕，作爲商業其價值一直存在，能通過信息化的方式來解決獲客或者能效問題麼？宏觀來講肯定可以，但是開發一個APP則會面臨用戶獲取和使用成本高，難留存，用戶難發現等等障礙——這些問題，都讓開發者懷疑要不要做APP，特別是在最開始的PMF核心邏輯還沒有被驗證的時候。
但創業者的熱情和投資人基金裡的錢都不能等！於是大家憋着這口氣四處找風口，或者又有怎樣的產品形態可以把商業形態再顛覆一次，好比APP顛覆了網頁，宏觀上有沒有新的產品形態可以再來一次？甚至運氣更好點，甚至開拓出以前沒有被耕耘過的維度？
對話式服務具備新的增長點的潛質
回顧過去，最大的幾次浪潮基本都伴隨着一個規律：核心技術（軟硬一堆）的出現和整合，帶來全新的人機交互方式 ，在此基礎上大量的商業應用應運而生。
從90年代，人機交互的三種變化
比如2007年末移動互聯開始，核心驅動的硬件是觸摸技術、各種sensor的成熟以及整體計算能力的提升和小型化；軟件方面則是iOS&Android的顛覆式出現。軟硬結合創造出完全顛覆過去的觸摸操作的體驗，並使其稱爲真正可用的人機交互方式——讓圖形化界面的輸入工具，從鍵鼠時代跨越到了更intuitive的觸摸，並完美的與後面開放的生態系統結合起來（不得不再次對喬大爺表示敬佩）。
人機交互越來越傾向於人
可以看到隨着技術的平民化(democratization)，人機交互正不可逆轉地向人的方向靠近——不需要學習的人機交互。
將來越來越多的人都能更自然的通過計算設備來獲得價值。下一個超級增長點的交互方式，一定是交互更接近人的自然行爲，更多人可以使用的。
因爲軟硬件限制，過去用上計算設備的人很少。一方面，當時的人機交互是讓人來“將就”機器——人學習機器的語言——操作需要專業技術，如打孔...（在個人電腦方面，當年知道'cd 文件夾名'的命令行的人也都是高端人士）；另一方面計算設備巨貴，還不屬於個人設備，大衆都買不起；再者，日常應用和普通生產力應用幾乎沒有，所以買來設備學會了UI也沒啥用。而移動設備出現就讓更多的人從使用計算設備中獲利，更多不會鍵盤鼠標的人，通過觸摸手機屏來操作。將來人們想要獲得服務的時候，或許不需要有“計算設備”這個中間載體的概念。直接提出需求，就能獲得結果。
下一代的交互方式，似計算設備能覆蓋更廣的商業。
Google Assistant Allo
看看過去app如何顛覆web的，在沒有移動互聯之前，大衆點評只是一個不知道幾流的小衆產品，web也並非最合適這個商業模式的產品形態——比如大部分情況下，人們想要找餐廳的時候，身邊都沒有PC來獲得其他人的點評信息；而移動互聯的APP解決了這個問題。
這並不是說app代替了web（比如PS還是在桌面端更好用），而是藉由移動設備，app開啓了過去沒有的維度，繼而大衆點評的商業模式有了更合適的產品形態。我相信APP顛覆web的歷史，也會同樣發生在下一代人機交互的形態來顛覆當前app的時候。不僅很多商業模式和形態都可以被重新考慮一次，甚至幾乎可以肯定CUI會打開新的維度，解放更多的商業價值。
如果一個C端產品做得好，傳播不受硬件束縛，沒有用戶的使用成本的障礙，並且不需要下載新的APP，直接在熟悉的IM或者SNS裡實現過去用app承載的服務，甚至還能開拓新的形態...比起當前的其他選擇AR/VR/IoT/區塊鏈，CUI帶來的想象空間更大。所以，就有很多人，巨頭小頭沒頭的都來嘗試。
【對CUI的特點的理解決定產品價值】
不可否認的，真正的CUI產品一定是基於人工智能的自然語言處理的。如何深入利用CUI的特點，是產品打造的關鍵。
話說當前國內有很多投資人認爲，只要是做人工智能的團隊，就必須是MIT，Caltech出來的機器學習博士或者是GOOGLE，FACEBOOK的AI團隊的人；如果團隊不是頂級院校的學者或者是巨頭出來的項目帶頭人，就沒有什麼好搞的——這是典型的誤區，或者說對行業的理解太淺了。這種理解基本等於 “聽說你是計算機專業畢業的，幫我裝一下電腦吧”這樣的水平。很不幸國內好多年輕點的投資經理基本都是這種水平（爲什麼年紀大點的不是？因爲他們理解'不懂就不要輕易判斷'這樣的人生道理）。看不懂本質，就看表面，也是不得已。
這裡，我非常贊同順爲資本的孟醒的幾個觀點：1）所謂“做AI的”也有幾個類型，底層研發和做應用的是兩碼事。2）人工智能的底層交給大公司，小創業公司可以做點小模塊。而應用層則有大量的空間給創業公司來實現商業化。3）“這個行業缺AI的產品經理，不缺一般意義上的明星，特別牛x的算法達人，牛x的北京的BAT出來的人。” 這方面吳恩達也有類似的觀點，“人工智能社區是極其開放的，大多數頂級研究者會出版他們的著作／分享他們的想法身子開源代碼。因此，在這個技術開元環境下，數據和人才就是稀缺的資源。”
有點跑題了，在這裡就強調一下，CUI的核心技術是AI（不僅限NLP後面會提到）。對CUI作爲新一代顛覆性人機交互的理解，纔在產品形態上能發揮底層技術的商業價值。最後，再舉個例子，GUI的核心突破是技術大牛（xerox）帶領的，而其商業應用的發揚光大則是產品經理喬布斯從xerox那兒“偷來”的。
1973年，xerox推出第一款GUI技術個人電腦；
在1983年，蘋果也推出了他們首款GUI電腦Lisa（喬老爺“ 完美借鑑 ”）
年輕人不懂就要多看書。
CUI的不可延續GUI的特點
爲了深入理解這個問題，我們可能要先分析一下，CUI和GUI究竟給用戶體驗帶來什麼影響？因爲這絕不是現在主流的“把按鈕變成語言操控”那麼簡單的事情。
當移動設備出現的時候，大家對如何在智能手機上開發產品還沒有來得及有深入的瞭解。所以當時開發者基本都是從最明顯的地方起步，也就是觸摸代替鍵鼠操作。早期的大量應用，都是從“如何把web縮小到手機屏幕”的思路出發來設計APP的。——這是典型的延續上一代交互的思路。
隨着開發者不斷思考和挖掘移動端的潛力，慢慢有了對移動端真正的核心特質的理解——這些“聖盃屬性”纔是真正讓移動端產品設計出衆的要素。比如“碎片時間”、“個人身份綁定“、”LBS”等等，這些特質纔是真正讓移動產品體現價值的——這些是完全顛覆上一代交互的屬性。而且我們發現這些屬性幾乎跟“觸摸”這個明顯的交互行爲沒有直接關係。
現在CUI出現的時候，產品經理也會面臨類似的問題。當前大多數智能助理的設計思路都是“過去APP是怎麼用的，我現在用語言來代替觸摸操作”。好比是用語言來代替手指去觸摸屏幕，或者是用說話來代替手指打字。而能讓用戶感覺真正智能的核心，我認爲依然藏在CUI的“聖盃屬性”裡，有待大家發掘。
CUI的特點：高度個性化
舉一個例子，根據實際研發和市場運作的經驗，我們發現有一個算得上“聖盃屬性”是特質是：“高度個性化”。
在GUI時代，用戶使用產品時，有一個可視化的界面，比如找餐廳，我們打開點評看上去是這樣：
這看上去是一個大家非常熟悉的界面，只是所有用戶能做的選擇範圍，都明確的顯示在界面上（所見即所選）。找美食，用戶能做的選擇基本就是：附近，類型，智能排序（不點開可能還不知道是什麼意思）以及排序。當用戶自己不知道該如何決策的時候，這些視覺化的框架，給了用戶提示該從這些方面根據自己的需求來做篩選和匹配。
但是在智能助理的界面，用戶看到的是這樣的：
用戶對可以做哪些選擇一無所知——在沒有可視化的參考下，面對如此開放的交互，當用戶要找一個餐廳的時候，他們提出的要求，大都不在GUI設定的範圍以內。
根據我們實際操作的經驗，用戶提出的問題是這樣的：
只有“在外灘附近的”是之前GUI的查詢範圍當中的，其他的需求都是過去GUI的類型當中不存在的維度。但因爲CUI的開放性，用戶很容易給出上面這樣的高度個性化（非結構化）的需求。
如果GUI的產品試圖在個性化同樣給用戶那麼多選擇，就不得不面臨用戶使用成本的問題。一個界面可能會被大量的下拉列表，層級關係，各種填空和操作充滿。如此是加深了個性化程度了，但是操作的成本會讓用戶放棄使用。
如果在智能助理的產品設計上，不尊重用戶“高度個性化”的需求，只提供過去APP本身提供的個性化程度“在XX附近找個YY菜”，那麼用戶在實際提需求的時候得靠運氣撞到既定的條件上，不然就是無法識別的範圍，繼而失望。另一方面，如果CUI只是在做GUI範圍內的事情，會遠不足以顛覆APP。
除此之外，CUI還有一些專屬的特點。比如
使用流程非線性：比如GUI是線性的流程，界面引導用戶一步一步走到結果；而CUI則可以是完全無視先後順序的，用戶可以再最開始就提出本來到排在最後的條件當中。
可避免信息過載：用戶打開GUI的一個界面，比如點評上找一個餐廳，用戶得在一個列表裡去找尋自己最想要的選項（典型的案例是，GUI讓用戶選擇國家的時候那一長排的列表）。而CUI則可以規避用戶的信息過載，直接給出期望的結果。這個特點的另一面是，GUI因此是informative的，給不熟悉場景的用戶更多的提示，或者比較結果的機會。
複合動作：“明天或後天，晚上最便宜的機票”——從用戶的操作和實際體驗來看，GUI無法一次給出結果，只能用戶先查一次明天的機票，再查一次後天的機票，然後手動來對比。CUI完勝——可以直接給出相關條件的檢索結果，前提是AI足夠優秀。
這裡只是拋磚引玉，詳細更多特質會不斷被開發者發掘出來。在這裡就不詳細展開了。在另一篇《人工智能時代的產品經理》文章當中，會做更多關於CUI的分析。
【什麼樣的AI Agent能滿足C端的需求？ 】
爲什麼現在的助理產品都是坑？很多團隊不是底層的算法差，而是團隊對產品的理解有問題。
要滿足C端用戶的需求，確實非常難。10次使用，有一次因爲任意原因的失望，用戶心理就會開始有疑慮。從體驗上來看，在用戶熟悉的場景下得全面理解用戶提出的需求；在用戶自身不清楚場景下，得自然的協助用戶挖掘需求；獲得需求後得幫助用戶做決策，並最終呈現結果。以此來看，對話式的agent就得至少滿足以下功能：
具備基於上下文的對話能力 (contextual conversation)
具備理解口語中的邏輯 (logic understanding)
所有能理解的需求，都要有能力履行（full-fulfillment）
1、基於上下文的對話能力(contextual conversation)
在當前，做助理的產品的底層技術基本都是圍繞NLU（自然語言理解）打造的，很多還沒有涉及到NLP。可是無論是大公司還是小公司的NLU都是讓人失望的。舉個簡單的例子，在大公司的幾個產品上提出需求：我下週五要去北京，幫我查一下航班。
需要識別意圖：查機票
需要識別entities：時間（下週五），目的地（北京），出發地（無/當前地理位置）
我們看看結果，首先看三家的回覆，從左到右分別是蘋果的SIRI, 微軟的CORTANA, Google的ALLO。
沒有一個能識別出來意圖，全部做爲用關鍵詞來檢索網頁(SERP)。沒有識別出意圖，繼而也就沒有可能識別entity所在的場景。對於C端用戶而言，這可能算是最基礎的服務之一，而三大巨頭提供的產品完全不能用。
不過當我們看到國內的創業公司，卻能按照需求識別出意圖，並且識別出對應的entity，組合查詢出結果，看上去比幾個巨頭更強大。
我們繼續測試上下文的對話。比如，我是國航的會員，agent給出上面的結果裡沒有國航的航班，我自然會問：”有沒有國航的？“
結果並沒有如期望那樣，在給出的列表裡找到國航的航班。而是開始了重新的一次查詢。
換一句話來說，沒有結合上下文的對話。我並不是爲了黑，事實上這個產品在國內的創業公司中也算不錯的技術了。但是不會結合上下文的對話，會造成的最嚴重的問題就是這個agent基本不能獨立完成服務。因爲用戶不會在一個句子裡把所有的條件都列出來。
以上是基本要素，就當前的產品形態來看，只有非常少的產品能真正做到第一點。大部分號稱能做到的，都是濫竽充數，連續問問題而已。
不能真正理解上下文的對話（機票查詢）：
AGENT： 從哪裡出發？
用戶：上海虹橋機場
AGENT：到哪裡？
用戶：還是從浦東走吧
AGENT：好的，從虹橋出發到浦東的航班是......
在上面的對話，AI Agent在問第二個問題的時候，不能理解用戶對前一個回答的修改（出發地從“虹橋”改爲“浦東”），只是按照預先設計對話的順序，填上命名實體識別得來的entity。繼而查詢不到結果，給用戶的感覺就是笨。
真正理解上下文的對話（機票查詢）：
AGENT：從哪裡出發？
用戶：上海虹橋機場
AGENT：到哪裡？
用戶：算了，從浦東走吧
AGENT：好的，出發改爲浦東。那到達城市呢？
用戶：北京
AGENT：好的，從浦東到北京的航班是...（給出正確的結果）
而具備真正上下文理解的對話，agent可以正確理解用戶第二個回答的內容（從浦東走），其實是在修改上一問題的回答（出發機場），而不是真的在回答第二個問題（到達地在哪裡）。
這只是上下文的例子，而對於服務類agent而言，所有後續的NLP功能都基於上下文對話爲前提。這些看上去其實都是非常簡單的需求，但是當前沒有任何一個2C的agent可以做到。
可能有人會問，大部分用戶都應該在第一時間把需求表達出來吧，爲什麼還需要對話？實際上，真正操作過大量案例的同學就會發現，用戶不可能如此”貼心“地按照開發者的設計來提出需求。
幫我看看下個星期五去北京，下午3點多，從虹橋出發，國航的航班。“——這一類的表達方式在幾乎從來沒有出現過。哪怕是在用戶最熟悉的場景，也很難確保一個句子的表達裡包含了所有必須的檢索條件。而且，用戶還會不停的補充更多的個性化需求。
對於用戶自己比較瞭解的場景，如：訂機票需要提供到達地，用戶提出的大多數需求，在最初都是非常簡單，然後逐漸開始細化的。所以需要當用戶提出不完整需求的時候，根據其意圖，結合之前已經給過的條件，通過對話，向用戶提出問題，再獲得答案來補全剩下還需要的條件，最後再完成服務。
對於用戶自己不熟悉的場景，用戶根本就不知道自己該提出哪些方面的需求。如：不懂酒的用戶，想買一瓶合適的威士忌。他就根本很難提出除了價格以外的需求，比如產地，年份，釀造原料，水源等等。因此，Agent得以合適的方式來提問，引導用戶給出偏好，並且用對話提出推薦。
而且對於agent而言，很難判斷哪些用戶對服務的認知有多深。如果不做識別，就容易問”老手“一些”新手問題“，繼而讓老手覺得我還不如自己下單；而給新手又留下”你在說什麼我都不懂“的印象，也是不聰明。
所以要有好的體驗，這是非常困難的。而基於上下文的對話，只是最基礎的用戶需求之一。
2、理解口語中的邏輯 (logic understanding)
在我們的實踐中，我們發現對”邏輯“的理解直觀重要。原因也是因爲用戶的正常對話，大部分都不是開發者預設那樣的。
再做一個簡單的測試，比如找餐廳，試試：幫我推薦一個附近的餐廳，不要日本菜。
這是一個簡單邏輯，但是你看所有的服務，這次包括剛剛那個國內創業公司C一樣，都會是一個結果：全部推薦日本菜。
也讓朋友測試了亞馬遜echo的alexa，結果也無法識別”不要“這個最簡單的邏輯
這次其實比剛剛好多了，至少4家裡面除了google allo，都識別出來我的意圖是找餐廳——但是，當我明確提出不要日本菜的時候，給出結果的三家全部都是日本菜......也就是說“不要” 兩個字被完全忽略了。
觀察大量的用戶案例表明，當用戶越是個性化需求強烈的時候，對話中出現邏輯和指代關係的頻次越高。
“有沒有更便宜的？”
“除了大牀房以外的房間有麼？”
“後天會比今天更冷麼？”
“就要剛剛的那個2千多的吧。”
“除了廉價航空，其他的航班都可以。”
以上這些需求是提需求的時候，在對話中經常出現的表達方式，而且看似簡單，但是目前沒有任何一個NLU的系統或產品能夠正確的理解。主要的阻礙就是對邏輯的理解，還有在基於上下文對話中的指代關係的理解失敗。
3、NLP不是全部，還要有能力履行（API困境）
NLU並不是智能助理髮展的瓶頸，供給端的數據纔是。
我們假設如果有一個黑科技出現，使得NLP有了極大的進步，以至於兩個條件：1）基於上下文場景的對話；2）口語邏輯，都能被理解了，甚至還能基於場景和上下文用NLG來生成各類問題——它能理解我們所有講出來的需求。
在用戶熟悉的範圍內，它能結合所有的過去的對話，歷史記錄等等內部外部條件，幫助用戶儘可能的實現“不用開口，就知道我在這個的需求”。比如當用戶提出“推薦餐廳的需求”：
用戶：“女朋友週日過生日，推薦一個餐廳，找有江景的，最好桌子旁邊有一個大落地窗戶，能看到外面的夜景。吃的不要太貴，環境好點，有現場音樂的最好是爵士，不要太吵的。” （btw，這是一個真實需求）
Agent：“菜系有偏好麼？”
用戶：“意大利餐和法餐都可以，對了不要離外灘太遠了”
agent解析出以下選擇餐廳的條件：
週日晚（營業）
適合女朋友過生日
有江景
有大落地窗
不要太貴
環境好
有現場音樂，爵士
不能太吵
意大利餐或者法餐
距離外灘不能太遠
然後它去哪裡找到這樣的餐廳呢？在地圖服務提供商，或者點評的API提供的信息裡只有8，9，兩項能找到數據。假設評論中有這樣的數據，該用什麼方式來傳遞呢？接口提供的都是結構化的數據，而“環境好”這樣的非結構化數據，最多以標籤的方式來做，但是這樣的話，標籤就會有無止境的多也不現實。
這就是我們所謂的“API困境”——當前基於API的數據傳遞方式，只能1）承載結構化數據；2）承載數量非常有限的結構化數據。
當前基於GUI的產品，都是用API來傳遞結構化數據。但大量個性化數據往往是非結構化的，以當前API的方式很難被處理。這還是在使用場景或者服務比較簡單的情況下。
在用戶不熟悉的場景下，agent面對稍微專業一點的服務，就會遇到知識圖譜的問題。簡單來講，agent要做推薦的前提是對推薦的內容得先有了解。好比，要向一位不懂酒的用戶推薦一款威士忌，那就不能依賴這位用戶自己提出的問題（很可能提不出要求），而得依賴“懂行”的自己對威士忌的理解的方方面面來引導用戶做合適他的選擇。一個助理顯然無法擁有所有服務所需的知識圖譜。
從知識圖譜的結構來看，是相對可被結構化。一個服務可以以各種方式被拆解成很多個方面，但大量的方面在當前是沒有結構化數據的（比如我們沒有每家餐廳的”營業面積“的數據）；甚至很多方面無法用結構化數據來表達（比如每家餐廳有否”適合浪漫約會“的環境）。
因此，智能助理就算有了強大的NLP，還需要全面的知識圖譜（結構化數據）和處理並傳遞非結構化數據的能力——而這兩點，在目前是無解的。
總結
在“API困境”解決之前，再加上NLP本身還有很長的路要走，基於人工智能的多任務服務agent不大可能達到C端滿意的水平。
創業團隊各自最基礎的認知計算的能力不會有太大的區別，都是踩在世界頂尖大牛的肩膀上——在這個領域創業團隊想和大公司鋼正面，不是很理性。
創業團隊在垂直領域有些自己的技術突破可以創造一些階段性的優勢，但面對教育市場的大山而言，這點差異遠不足以make a difference。
在各自領域，開發者對人工智能相關技術的理解和其帶來的交互層面的有效應用，可能會在垂直商業應用上創造更大的差異——比較起”95% VS 98%的識別率“ 而言。