人工智障 （1/3）
本文轉自 微信公眾號“S先生” （ID：TheMisterS），作者Mingke
我不是針對誰，只是在座現在所有做 C端智慧助理的都是坑。
對群嘲做一個限定：
- 現在：在"API困境"被解決之前（後詳）。
- 人工智慧助理：這裡指的是 Intelligent personal assistant/agent (IPA) 又稱為Virtual Personal Assistant/Agent(VPA)——幫助個人完成多項任務或多項服務的虛擬助理，當前討論的核心驅動力是人工智慧。（什麼你說用人來做處理單元？那是呼叫中心，也叫客服，最看不起掛羊頭賣狗肉的了。）
- 在座：不止是創業公司，大公司也搞不定，國內國外無所謂。
- 都是坑：創業公司做消費端的虛擬助理，一定無法實現消費級產品效果。對於巨頭也是，我相信大部分的相關負責人都以“進步”為目標，而不敢跟自家CEO擔保要以“搞定”為目標。
什麼是智慧助理？
1、智慧助理屬於對話式服務
兩者的邊界不是很清晰，智慧助理的功能在前面解釋過了；而“對話式服務（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提到的一樣， 只有如此才能真正規模化 。
2、智慧助理應該解決服務需求
巨頭的人工智慧助理基本都已亮相了：
- Facebook M
- Amazon Echo
- Google Assistant, Allo
- Apple Siri
- IBM Watson
- Microsoft Cortana
以上智慧助理的服務範圍大都是在資訊檢索，幫助使用者獲得資訊。絕大多數的內容是不牽涉“推理”的查詢類資訊服務。比如：
- 明天的天氣
- 找附近的星巴克
- 蘋果的股票資訊等等
如果使用者問到在基礎資訊以上，一旦牽涉推理的問題，就無能為力了。比如：
- 明天這個天氣狀況會造成航班延誤麼？
- 附近的星巴克可以用支付寶麼？
- 我什麼時候該買蘋果的股票？
使用體驗方面，這些助理的服務範圍覆蓋面基本跟當前的所有引擎一樣。在設計邏輯上，基本都是基於用命名實體識別來代替打字輸入關鍵詞然後返回檢索結果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）
人工智慧助理的潛力
1、移動紅利的結束，行業需要新的增長點
很多跡象都指向同一個結論：移動互聯的高速增長已經飽和。比如使用者已經不再願意下載新的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顛覆了網頁，巨集觀上有沒有新的產品形態可以再來一次？甚至運氣更好點，甚至開拓出以前沒有被耕耘過的維度？
2、對話式服務具備新的增長點的潛質
回顧過去，最大的幾次浪潮基本都伴隨著一個規律：核心技術（軟硬一堆）的出現和整合，帶來全新的人機互動方式 ，在此基礎上大量的商業應用應運而生。
從90年代開始，人際互動的三個變化
比如2007年末移動互聯開始，核心驅動的硬體是觸控技術、各種sensor的成熟以及整體計算能力的提升和小型化；軟體方面則是iOS&Android的顛覆式出現。軟硬結合創造出完全顛覆過去的觸控操作的體驗，並使其稱為真正可用的人機互動方式——讓圖形化介面的輸入工具，從鍵鼠時代跨越到了更intuitive的觸控，並完美的與後面開放的生態系統結合起來（不得不再次對喬大爺表示敬佩）。
3、人機互動越來越傾向於人
可以看到隨著技術的平民化(democratization)，人機互動正不可逆轉地向人的方向靠近——不需要學習的人機互動。
將來越來越多的人都能更自然的通過計算裝置來獲得價值。下一個超級增長點的互動方式，一定是互動更接近人的自然行為，更多人可以使用的。
因為軟硬體限制，過去用上計算裝置的人很少。一方面，當時的人機互動是讓人來“將就”機器——人學習機器的語言——操作需要專業技術，如打孔...（在個人電腦方面，當年知道'cd 資料夾名'的命令列的人也都是高階人士）；另一方面計算裝置巨貴，還不屬於個人裝置，大眾都買不起；再者，日常應用和普通生產力應用幾乎沒有，所以買來裝置學會了UI也沒啥用。而移動裝置出現就讓更多的人從使用計算裝置中獲利，更多不會鍵盤滑鼠的人，通過觸控手機屏來操作。將來人們想要獲得服務的時候，或許不需要有“計算裝置”這個中間載體的概念。直接提出需求，就能獲得結果。
4、下一代互動方式，似計算裝置能覆蓋更廣的商業
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（喬老爺 “完美借鑑” ）
年輕人不懂就要多看書。
1、CUI的不可延續GUI的特點
為了深入理解這個問題，我們可能要先分析一下，CUI和GUI究竟給使用者體驗帶來什麼影響？因為這絕不是現在主流的“把按鈕變成語言操控”那麼簡單的事情。
當移動裝置出現的時候，大家對如何在智慧手機上開發產品還沒有來得及有深入的瞭解。所以當時開發者基本都是從最明顯的地方起步，也就是觸控代替鍵鼠操作。早期的大量應用，都是從“如何把web縮小到手機螢幕”的思路出發來設計APP的——這是典型的延續上一代互動的思路。
隨著開發者不斷思考和挖掘移動端的潛力，慢慢有了對移動端真正的核心特質的理解——這些“聖盃屬性”才是真正讓移動端產品設計出眾的要素。比如“碎片時間”、“個人身份繫結“、”LBS”等等，這些特質才是真正讓移動產品體現價值的——這些是完全顛覆上一代互動的屬性。而且我們發現這些屬性幾乎跟“觸控”這個明顯的互動行為沒有直接關係。
現在CUI出現的時候，產品經理也會面臨類似的問題。當前大多數智慧助理的設計思路都是“過去APP是怎麼用的，我現在用語言來代替觸控操作”。好比是用語言來代替手指去觸控式螢幕幕，或者是用說話來代替手指打字。而能讓使用者感覺真正智慧的核心，我認為依然藏在CUI的“聖盃屬性”裡，有待大家發掘。
2、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%的識別率” 而言。
關於作者：
作者Mingke：正在從事人工智慧方面的創業，合夥人做演算法和框架，我做產品和商業。我們親身經歷過C端助理的坑，結合過去一段時間和各家VC機構以及同一個戰壕的朋友溝通下來的一些心得，與大家分享。拋磚引玉，歡迎互噴。微信：mingke27