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