對群嘲做一個限定：現在：在＂API困境＂被解決之前（后詳）。

人工智能助理：這里指的是Intelligent personal assistant／agent （IPA） 又稱為Virtual Personal Assistant／Agent（VPA）——幫助個人完成多項任務或多項服務的虛擬助理，當前討論的核心驅動力是人工智能。（什么你說用人來做處理單元？那是呼叫中心，也叫客服，最看不起掛羊頭賣狗肉的了。）

在座：不止是創(chuàng)業(yè)公司，大公司也搞不定，國內國外無所謂。

都是坑：創(chuàng)業(yè)公司做消費端的虛擬助理，一定無法實現消費級產品效果。對于巨頭也是，我相信大部分的相關負責人都以“進步”為目標，而不敢跟自家CEO擔保要以“搞定”為目標。

什么是智能助理？

1）智能助理屬于對話式服務

兩者的邊界不是很清晰，智能助理的功能在前面解釋過了；而“對話式服務（conversational service／commerce）”——這是包含智能助理在內的多個產品形態(tài)的統(tǒng)稱，核心特點是：

對話式：人機交互的方式由圖形化交互（GUI－Graphical User Interface）變?yōu)橐詫υ捵鳛榻换シ绞剑–UI－Conversational User Interface 業(yè)界暫時還沒有定義，這是我自己瞎編的），就是用說話來代替觸摸或者鼠標，操作計算設備。

服務：提供服務，解決問題都算，如訂機票，購買禮物等。不包括信息查詢（如天氣）。

Facebook M， 真人和AI結合的服務

去年（2015）起來的這一波對話式服務在硅谷有多火？看看創(chuàng)業(yè)團隊增長的數量就知道了：2015年的時候有129個類似的項目出現，而14年的時候才42個。

Tracxn Report：Conversational Commerce

在各類科技博客上，對Conversational Commerce的討論也非常熱烈，尤其是在medium．com上有大量的探討?；镜挠^點就是”對話式的交互將會成為下一個風口，大家趕緊上啊！“。截止到2016年6月的時候，在Producthunt上標記為對話式服務（ConvComm）的有一百多個創(chuàng)業(yè)項目。

除了智能助理以外，還有很多類似的概念如digital agent，bot，service bot， chatbot，P2P的電商。比如Operator現在用真人專家?guī)陀脩糇鱿M決策，在過去嘗試過用bot／AI但可惜達不到效果，或者magic模式，完全是靠”真人幫懶人用APP“驅動運營。本文主要討論的是基于人工智能的智能助理——就像IBM提到的一樣，只有如此才能真正規(guī)?；?。

2）智能助理應該解決服務需求

巨頭的人工智能助理基本都已亮相了：

Facebook M

Amazon Echo

Google Assistant， Allo

Apple Siri

IBM Watson

Microsoft Cortana

以上智能助理的服務范圍大都是在信息檢索，幫助用戶獲得資訊。絕大多數的內容是不牽涉“推理”的查詢類信息服務。比如：

明天的天氣

找附近的星巴克

蘋果的股票信息等等

如果用戶問到在基礎信息以上，一旦牽涉推理的問題，就無能為力了。比如：

明天這個天氣狀況會造成航班延誤么？

附近的星巴克可以用支付寶么？

我什么時候該買蘋果的股票？

使用體驗方面，這些助理的服務范圍覆蓋面基本跟當前的所有引擎一樣。在設計邏輯上，基本都是基于用命名實體識別來代替打字輸入關鍵詞然后返回檢索結果SERP。而信息檢索，離人們要完成的服務需求有很大的區(qū)別。就好像viv．ai的聯合創(chuàng)始人Dag Kittlaus 說的，當初他創(chuàng)建siri的時候，是想要重新挑戰(zhàn)移動服務，而不是造一個chatbot。

Dag Kittlaus（中間）

除此以外，巨頭的助理與其關聯的生態(tài)產生操作的關聯。比如SIRI對iOS和macOS的操作；Cortana對windows的操作；echo對關聯著的智能家居設備的操作等等。此類操作的一個特點，是對結果非常的確定，出現個性化選擇范圍非常的少。

另一方面，對于創(chuàng)業(yè)項目而言，因為不具備類似的生態(tài)和硬件入口的條件，大都定位在資訊和服務上。我們選擇Producthunt當中排在最前150位的項目進行分析，其中高達70％的項目定位都在2C的個人助理（agent）上，其中大部分都想做切入服務，包括垂直類的和多任務的。

這些助理服務當中有23．1％是專業(yè)類型的服務，主要是在醫(yī)療和理財方面。而剩下來的76．9％的助理干的最多的活兒是生活上的綜合幫助，出行安排，日程管理，購物訂餐廳等等——這一類是坑最大的地方——特別是那些試圖把生活上的各種服務都打包進去的產品。

Producthunt上面 69．7％的對話式服務都是智能助理產品（但并非所有都具備AI）

人工智能助理的潛力

1）移動紅利的結束，行業(yè)需要新的增長點

很多跡象都指向同一個結論：移動互聯的高速增長已經飽和。比如用戶已經不再愿意下載新的APP。

qz （based on comscore data） ＆ statista

2016年1月有超過5萬個新的APP被提交到了appstore，但是在美國市場有65％的智能手機用戶在一個月內下載新APP的數量為0，下了1個新APP的人占8．4％。

2015年中到現在，在國內2C市場中，幾乎找不到一款真正能爆發(fā)并留存的移動產品。對于移動開發(fā)者而言，能放首屏的高頻應用早就擠不進去了。而且很多中低頻的服務，并不是最適合用app來承載的。比如訂生日蛋糕，作為商業(yè)其價值一直存在，能通過信息化的方式來解決獲客或者能效問題么？

宏觀來講肯定可以，但是開發(fā)一個APP則會面臨用戶獲取和使用成本高，難留存，用戶難發(fā)現等等障礙——這些問題，都讓開發(fā)者懷疑要不要做APP，特別是在最開始的PMF核心邏輯還沒有被驗證的時候。

但創(chuàng)業(yè)者的熱情和投資人基金里的錢都不能等！于是大家憋著這口氣四處找風口，或者又有怎樣的產品形態(tài)可以把商業(yè)形態(tài)再顛覆一次，好比APP顛覆了網頁，宏觀上有沒有新的產品形態(tài)可以再來一次？甚至運氣更好點，甚至開拓出以前沒有被耕耘過的維度？

2）對話式服務具備新的增長點的潛質

回顧過去，最大的幾次浪潮基本都伴隨著一個規(guī)律：核心技術（軟硬一堆）的出現和整合，帶來全新的人機交互方式 ，在此基礎上大量的商業(yè)應用應運而生。

從90年代開始，人際交互的三個變化

比如2007年末移動互聯開始，核心驅動的硬件是觸摸技術、各種sensor的成熟以及整體計算能力的提升和小型化；軟件方面則是iOS＆Android的顛覆式出現。

軟硬結合創(chuàng)造出完全顛覆過去的觸摸操作的體驗，并使其稱為真正可用的人機交互方式——讓圖形化界面的輸入工具，從鍵鼠時代跨越到了更intuitive的觸摸，并完美的與后面開放的生態(tài)系統(tǒng)結合起來（不得不再次對喬大爺表示敬佩）。

3）人機交互越來越傾向于人

可以看到隨著技術的平民化（democratization），人機交互正不可逆轉地向人的方向靠近——不需要學習的人機交互。

將來越來越多的人都能更自然的通過計算設備來獲得價值。下一個超級增長點的交互方式，一定是交互更接近人的自然行為，更多人可以使用的。

因為軟硬件限制，過去用上計算設備的人很少。

一方面，當時的人機交互是讓人來“將就”機器——人學習機器的語言——操作需要專業(yè)技術，如打孔．．．（在個人電腦方面，當年知道＇cd 文件夾名＇的命令行的人也都是高端人士）；

另一方面計算設備巨貴，還不屬于個人設備，大眾都買不起；再者，日常應用和普通生產力應用幾乎沒有，所以買來設備學會了UI也沒啥用。

而移動設備出現就讓更多的人從使用計算設備中獲利，更多不會鍵盤鼠標的人，通過觸摸手機屏來操作。將來人們想要獲得服務的時候，或許不需要有“計算設備”這個中間載體的概念。直接提出需求，就能獲得結果。

4）下一代交互方式，似計算設備能覆蓋更廣的商業(yè)

Google Assistant Allo

看看過去app如何顛覆web的，在沒有移動互聯之前，大眾點評只是一個不知道幾流的小眾產品，web也并非最合適這個商業(yè)模式的產品形態(tài)——比如大部分情況下，人們想要找餐廳的時候，身邊都沒有PC來獲得其他人的點評信息；而移動互聯的APP解決了這個問題。

這并不是說app代替了web（比如PS還是在桌面端更好用），而是借由移動設備，app開啟了過去沒有的維度，繼而大眾點評的商業(yè)模式有了更合適的產品形態(tài)。我相信APP顛覆web的歷史，也會同樣發(fā)生在下一代人機交互的形態(tài)來顛覆當前app的時候。不僅很多商業(yè)模式和形態(tài)都可以被重新考慮一次，甚至幾乎可以肯定CUI會打開新的維度，解放更多的商業(yè)價值。

如果一個C端產品做得好，傳播不受硬件束縛，沒有用戶的使用成本的障礙，并且不需要下載新的APP，直接在熟悉的IM或者SNS里實現過去用app承載的服務，甚至還能開拓新的形態(tài)．．．比起當前的其他選擇AR／VR／IOT／區(qū)塊鏈，CUI帶來的想象空間更大。所以，就有很多人，巨頭小頭沒頭的都來嘗試。

對CUI的特點的理解決定產品價值

不可否認的，真正的CUI產品一定是基于人工智能的自然語言處理的。如何深入利用CUI的特點，是產品打造的關鍵。

話說當前國內有很多投資人認為，只要是做人工智能的團隊，就必須是MIT，Caltech出來的機器學習博士或者是GOOGLE，FACEBOOK的AI團隊的人；如果團隊不是頂級院校的學者或者是巨頭出來的項目帶頭人，就沒有什么好搞的——這是典型的誤區(qū)，或者說對行業(yè)的理解太淺了。

這種理解基本等于 “聽說你是計算機專業(yè)畢業(yè)的，幫我裝一下電腦吧”這樣的水平。很不幸國內好多年輕點的投資經理基本都是這種水平（為什么年紀大點的不是？因為他們理解＇不懂就不要輕易判斷＇這樣的人生道理）?？床欢举|，就看表面，也是不得已。

這里，我非常贊同順為資本的孟醒的幾個觀點：

1）所謂“做AI的”也有幾個類型，底層研發(fā)和做應用的是兩碼事。

2）人工智能的底層交給大公司，小創(chuàng)業(yè)公司可以做點小模塊。而應用層則有大量的空間給創(chuàng)業(yè)公司來實現商業(yè)化。

3）“這個行業(yè)缺AI的產品經理，不缺一般意義上的明星，特別牛x的算法達人，牛x的北京的BAT出來的人。”

這方面吳恩達也有類似的觀點，

“人工智能社區(qū)是極其開放的，大多數頂級研究者會出版他們的著作／分享他們的想法身子開源代碼。因此，在這個技術開元環(huán)境下，數據和人才就是稀缺的資源?！?/p>

有點跑題了，在這里就強調一下，CUI的核心技術是AI（不僅限NLP后面會提到）。對CUI作為新一代顛覆性人機交互的理解，才在產品形態(tài)上能發(fā)揮底層技術的商業(yè)價值。最后，再舉個例子，GUI的核心突破是技術大牛（xerox）帶領的，而其商業(yè)應用的發(fā)揚光大則是產品經理喬布斯從xerox那兒“偷來”的。

1973年，xerox推出第一款GUI技術個人電腦；在1983年，蘋果也推出了他們首款GUI電腦 Lisa（喬老爺 “完美借鑒” ）

年輕人不懂就要多看書。

1）CUI的不可延續(xù)GUI的特點

為了深入理解這個問題，我們可能要先分析一下，CUI和GUI究竟給用戶體驗帶來什么影響？因為這絕不是現在主流的“把按鈕變成語言操控”那么簡單的事情。

當移動設備出現的時候，大家對如何在智能手機上開發(fā)產品還沒有來得及有深入的了解。所以當時開發(fā)者基本都是從最明顯的地方起步，也就是觸摸代替鍵鼠操作。早期的大量應用，都是從“如何把web縮小到手機屏幕”的思路出發(fā)來設計APP的。——這是典型的延續(xù)上一代交互的思路。

隨著開發(fā)者不斷思考和挖掘移動端的潛力，慢慢有了對移動端真正的核心特質的理解——這些“圣杯屬性”才是真正讓移動端產品設計出眾的要素。比如“碎片時間”、“個人身份綁定“、”LBS”等等，這些特質才是真正讓移動產品體現價值的——這些是完全顛覆上一代交互的屬性。而且我們發(fā)現這些屬性幾乎跟“觸摸”這個明顯的交互行為沒有直接關系。

現在CUI出現的時候，產品經理也會面臨類似的問題。當前大多數智能助理的設計思路都是“過去APP是怎么用的，我現在用語言來代替觸摸操作”。好比是用語言來代替手指去觸摸屏幕，或者是用說話來代替手指打字。而能讓用戶感覺真正智能的核心，我認為依然藏在CUI的“圣杯屬性”里，有待大家發(fā)掘。

2）CUI的特點：高度個性化

舉一個例子，根據實際研發(fā)和市場運作的經驗，我們發(fā)現有一個算得上“圣杯屬性”是特質是：“高度個性化”。

在GUI時代，用戶使用產品時，有一個可視化的界面，比如找餐廳，我們打開點評看上去是這樣：

這看上去是一個大家非常熟悉的界面，只是所有用戶能做的選擇范圍，都明確的顯示在界面上（所見即所選）。找美食，用戶能做的選擇基本就是：附近，類型，智能排序（不點開可能還不知道是什么意思）以及排序。當用戶自己不知道該如何決策的時候，這些視覺化的框架，給了用戶提示該從這些方面根據自己的需求來做篩選和匹配。

但是在智能助理的界面，用戶看到的是這樣的：

用戶對可以做哪些選擇一無所知——在沒有可視化的參考下，面對如此開放的交互，當用戶要找一個餐廳的時候，他們提出的要求，大都不在GUI設定的范圍以內。

根據我們實際操作的經驗，用戶提出的問題是這樣的：

只有“在外灘附近的”是之前GUI的查詢范圍當中的，其他的需求都是過去GUI的類型當中不存在的維度。但因為CUI的開放性，用戶很容易給出上面這樣的高度個性化（非結構化）的需求。

如果GUI的產品試圖在個性化同樣給用戶那么多選擇，就不得不面臨用戶使用成本的問題。一個界面可能會被大量的下拉列表，層級關系，各種填空和操作充滿。如此是加深了個性化程度了，但是操作的成本會讓用戶放棄使用。

如果在智能助理的產品設計上，不尊重用戶“高度個性化”的需求，只提供過去APP本身提供的個性化程度“在XX附近找個YY菜”，那么用戶在實際提需求的時候得靠運氣撞到既定的條件上，不然就是無法識別的范圍，繼而失望。另一方面，如果CUI只是在做GUI范圍內的事情，會遠不足以顛覆APP。

除此之外，CUI還有一些專屬的特點。比如

使用流程非線性：比如GUI是線性的流程，界面引導用戶一步一步走到結果；而CUI則可以是完全無視先后順序的，用戶可以再最開始就提出本來到排在最后的條件當中。

可避免信息過載：用戶打開GUI的一個界面，比如點評上找一個餐廳，用戶得在一個列表里去找尋自己最想要的選項（典型的案例是，GUI讓用戶選擇國家的時候那一長排的列表）。而CUI則可以規(guī)避用戶的信息過載，直接給出期望的結果。這個特點的另一面是，GUI因此是informative的，給不熟悉場景的用戶更多的提示，或者比較結果的機會。

復合動作：“明天后天，晚上最便宜的機票”——從用戶的操作和實際體驗來看，GUI無法一次給出結果，只能用戶先查一次明天的機票，再查一次后天的機票，然后手動來對比。CUI完勝——可以直接給出相關條件的檢索結果，前提是AI足夠優(yōu)秀。

這里只是拋磚引玉，詳細更多特質會不斷被開發(fā)者發(fā)掘出來。在這里就不詳細展開了。在另一篇《人工智能時代的產品經理》文章當中，會做更多關于CUI的分析。

什么樣的AI Agent能滿足C端的需求？

為什么現在的助理產品都是坑？很多團隊不是底層的算法差，而是團隊對產品的理解有問題。

要滿足C端用戶的需求，確實非常難。10次使用，有一次因為任意原因的失望，用戶心理就會開始有疑慮。從體驗上來看，在用戶熟悉的場景下得全面理解用戶提出的需求；在用戶自身不清楚場景下，得自然的協助用戶挖掘需求；獲得需求后得幫助用戶做決策，并最終呈現結果。以此來看，對話式的agent得至少滿足以下功能：

具備基于上下文的對話能力（contextual conversation）；

具備理解口語中的邏輯（logic understanding） ；

所有能理解的需求，都要有能力履行（full－fulfillment）；

1）基于上下文的對話能力（contextual conversation）

在當前，做助理的產品的底層技術基本都是圍繞NLU（自然語言理解）打造的，很多還沒有涉及到NLP?？墒菬o論是大公司還是小公司的NLU都是讓人失望的。舉個簡單的例子，在大公司的幾個產品上提出需求：我下周五要去北京，幫我查一下航班。

需要識別意圖：查機票

需要識別entities：時間（下周五），目的地（北京），出發(fā)地（無／當前地理位置）

我們看看結果，首先看三家的回復，從左到右分別是蘋果的SIRI， 微軟的CORTANA， Google的ALLO。

沒有一個能識別出來意圖，全部用關鍵詞來檢索網頁（SERP）。沒有識別出意圖，繼而也就沒有可能識別entity所在的場景。對于C端用戶而言，這可能算是最基礎的服務之一，而三大巨頭提供的產品完全不能用。

不過當我們看到國內的創(chuàng)業(yè)公司，卻能按照需求識別出意圖，并且識別出對應的entity，組合查詢出結果，看上去比幾個巨頭更強大。

我們繼續(xù)測試上下文的對話。比如，我是國航的會員，agent給出上面的結果里沒有國航的航班，我自然會問：”有沒有國航的？“

結果并沒有如期望那樣，在給出的列表里找到國航的航班。而是開始了重新的一次查詢。

換一句話來說，沒有結合上下文的對話。我并不是為了黑，事實上這個產品在國內的創(chuàng)業(yè)公司中也算不錯的技術了。但是不會結合上下文的對話，會造成的最嚴重的問題就是這個agent基本不能獨立完成服務。因為用戶不會在一個句子里把所有的條件都列出來。

以上是基本要素，就當前的產品形態(tài)來看，只有非常少的產品能真正做到第一點。大部分號稱能做到的，都是濫竽充數，連續(xù)問問題而已。

不能真正理解上下文的對話（機票查詢）：

AGENT： 從哪里出發(fā)？

用戶：上海虹橋機場

AGENT：到哪里？

用戶：還是從浦東走吧

AGENT：好的，從虹橋出發(fā)到浦東的航班是．．．．．．

在上面的對話，AI Agent在問第二個問題的時候，不能理解用戶對前一個回答的修改（出發(fā)地從“虹橋”改為“浦東”），只是按照預先設計對話的順序，填上命名實體識別得來的entity。繼而查詢不到結果，給用戶的感覺就是笨。

真正理解上下文的對話（機票查詢）：

AGENT：從哪里出發(fā)？

用戶：上海虹橋機場

AGENT：到哪里？

用戶：算了，從浦東走吧

AGENT：好的，出發(fā)改為浦東。那到達城市呢？

用戶：北京

AGENT：好的，從浦東到北京的航班是．．．（給出正確的結果）

而具備真正上下文理解的對話，agent可以正確理解用戶第二個回答的內容（從浦東走），其實是在修改上一問題的回答（出發(fā)機場），而不是真的在回答第二個問題（到達地在哪里）。

這只是上下文的例子，而對于服務類agent而言，所有后續(xù)的NLP功能都基于上下文對話為前提。這些看上去其實都是非常簡單的需求，但是當前沒有任何一個2C的agent可以做到。

可能有人會問，大部分用戶都應該在第一時間把需求表達出來吧，為什么還需要對話？實際上，真正操作過大量案例的同學就會發(fā)現，用戶不可能如此”貼心“地按照開發(fā)者的設計來提出需求。

“幫我看看下個星期五去北京，下午3點多，從虹橋出發(fā)，國航的航班?！薄@一類的表達方式在幾乎從來沒有出現過。哪怕是在用戶最熟悉的場景，也很難確保一個句子的表達里包含了所有必須的檢索條件。而且，用戶還會不停的補充更多的個性化需求。

對于用戶自己比較了解的場景，如：訂機票需要提供到達地，用戶提出的大多數需求，在最初都是非常簡單，然后逐漸開始細化的。所以需要當用戶提出不完整需求的時候，根據其意圖，結合之前已經給過的條件，通過對話，向用戶提出問題，再獲得答案來補全剩下還需要的條件，最后再完成服務。

對于用戶自己不熟悉的場景，用戶根本就不知道自己該提出哪些方面的需求。如：不懂酒的用戶，想買一瓶合適的威士忌。他就根本很難提出除了價格以外的需求，比如產地，年份，釀造原料，水源等等。因此，Agent得以合適的方式來提問，引導用戶給出偏好，并且用對話提出推薦。

而且對于agent而言，很難判斷哪些用戶對服務的認知有多深。如果不做識別，就容易問“老手”一些“新手問題”，繼而讓老手覺得我還不如自己下單；而給新手又留下“你在說什么我都不懂”的印象，也是不聰明。

所以要有好的體驗，這是非常困難的。而基于上下文的對話，只是最基礎的用戶需求之一。

2）理解口語中的邏輯 （logic understanding）

在我們的實踐中，我們發(fā)現對“邏輯”的理解直觀重要。原因也是因為用戶的正常對話，大部分都不是開發(fā)者預設那樣的。

再做一個簡單的測試，比如找餐廳，試試：幫我推薦一個附近的餐廳，不要日本菜。

這是一個簡單邏輯，但是你看所有的服務，這次包括剛剛那個國內創(chuàng)業(yè)公司C一樣，都會是一個結果：全部推薦日本菜。

也讓朋友測試了亞馬遜echo的alexa，結果也無法識別”不要“這個最簡單的邏輯

這次其實比剛剛好多了，至少4家里面除了google allo，都識別出來我的意圖是找餐廳——但是，當我明確提出不要日本菜的時候，給出結果的三家全部都是日本菜．．．．．．也就是說“不要” 兩個字被完全忽略了。

觀察大量的用戶案例表明，當用戶越是個性化需求強烈的時候，對話中出現邏輯和指代關系的頻次越高。

“有沒有更便宜的？”

“除了大床房以外的房間有么？”

“后天會比今天更冷么？”

“就要剛剛的那個2千多的吧?！?/p>

“除了廉價航空，其他的航班都可以?！?/p>

以上這些需求是提需求的時候，在對話中經常出現的表達方式，而且看似簡單，但是目前沒有任何一個NLU的系統(tǒng)或產品能夠正確的理解。主要的阻礙就是對邏輯的理解，還有在基于上下文對話中的指代關系的理解失敗。

3）NLP不是全部，還要有能力履行（API困境）

NLU并不是智能助理發(fā)展的瓶頸，供給端的數據才是。

我們假設如果有一個黑科技出現，使得NLP有了極大的進步，以至于兩個條件：

1）基于上下文場景的對話；

2）口語邏輯，都能被理解了，甚至還能基于場景和上下文用NLG來生成各類問題——它能理解我們所有講出來的需求。

在用戶熟悉的范圍內，它能結合所有的過去的對話，歷史記錄等等內部外部條件，幫助用戶盡可能的實現“不用開口，就知道我在這個的需求”。比如當用戶提出“推薦餐廳的需求”：

用戶：“女朋友周日過生日，推薦一個餐廳，找有江景的，最好桌子旁邊有一個大落地窗戶，能看到外面的夜景。吃的不要太貴，環(huán)境好點，有現場音樂的最好是爵士，不要太吵的?！?（btw，這是一個真實需求）

Agent：“菜系有偏好么？”

用戶：“意大利餐和法餐都可以，對了不要離外灘太遠了”

agent解析出以下選擇餐廳的條件：

周日晚（營業(yè)）

適合女朋友過生日

有江景

有大落地窗

不要太貴

環(huán)境好

有現場音樂，爵士

不能太吵

意大利餐或者法餐

距離外灘不能太遠

然后它去哪里找到這樣的餐廳呢？在地圖服務提供商，或者點評的API提供的信息里只有8，9，兩項能找到數據。假設評論中有這樣的數據，該用什么方式來傳遞呢？接口提供的都是結構化的數據，而“環(huán)境好”這樣的非結構化數據，最多以標簽的方式來做，但是這樣的話，標簽就會有無止境的多也不現實。

這就是我們所謂的“API困境”——當前基于API的數據傳遞方式，只能1）承載結構化數據；2）承載數量非常有限的結構化數據。當前基于GUI的產品，都是用API來傳遞結構化數據。但大量個性化數據往往是非結構化的，以當前API的方式很難被處理。這還是在使用場景或者服務比較簡單的情況下。

在用戶不熟悉的場景下，agent面對稍微專業(yè)一點的服務，就會遇到知識圖譜的問題。簡單來講，agent要做推薦的前提是對推薦的內容得先有了解。好比，要向一位不懂酒的用戶推薦一款威士忌，那就不能依賴這位用戶自己提出的問題（很可能提不出要求），而得依賴“懂行”的自己對威士忌的理解的方方面面來引導用戶做合適他的選擇。一個助理顯然無法擁有所有服務所需的知識圖譜。

從知識圖譜的結構來看，是相對可被結構化。一個服務可以以各種方式被拆解成很多個方面，但大量的方面在當前是沒有結構化數據的（比如我們沒有每家餐廳的“營業(yè)面積”的數據）；甚至很多方面無法用結構化數據來表達（比如每家餐廳有否“適合浪漫約會”的環(huán)境）。

因此，智能助理就算有了強大的NLP，還需要全面的知識圖譜（結構化數據）和處理并傳遞非結構化數據的能力——而這兩點，在目前是無解的。

總結

在＂API困境＂解決之前，再加上NLP本身還有很長的路要走，基于人工智能的多任務服務agent不大可能達到C端滿意的水平。

創(chuàng)業(yè)團隊各自最基礎的認知計算的能力不會有太大的區(qū)別，都是踩在世界頂尖大牛的肩膀上——在這個領域創(chuàng)業(yè)團隊想和大公司鋼正面，不是很理性。

創(chuàng)業(yè)團隊在垂直領域有些自己的技術突破可以創(chuàng)造一些階段性的優(yōu)勢，但面對教育市場的大山而言，這點差異遠不足以make a difference。

在各自領域，開發(fā)者對人工智能相關技術的理解和其帶來的交互層面的有效應用，可能會在垂直商業(yè)應用上創(chuàng)造更大的差異——比較起「95％ VS 98％的識別率」而言。