📖 ZKIZ Archives

如果行行都像華爾街 世界將會怎樣？

金融業是個古怪的行當。無論是媒體談的、外行用的，還是學校教的金融，好像都和其他行業不一樣，又都各執一詞。曾榮獲美國財經編輯與記者協會（SABEW）年度優秀報道獎的專欄作者Morgan Housel認為，要了解金融這麽特別的行業，最好的方法或許是想象其他行業也像華爾街那樣行事，比如——

如果學校老師打分像企業財務工作那樣：

即使老師給學生小明打分為F，小明也可以說自己實際上拿了A，因為只要去掉模擬財務信息中的臨時錯誤，小明就能拿最高分。老師會認可這種說法。

如果天氣預報員采用股票交易高手的選股標準：

天氣預報員小明會預計，邁阿密將很快降下暴風雪，依據是上世紀70年代以來邁阿密曾迎來一場暴風雪，積雪一度達到兩英尺。雖然幾十年來邁阿密的氣溫都沒有低於攝氏10度，但小明會憑借自己“對邁阿密天氣的奇準預測”入選氣象學家名人堂。

如果幹園藝像做投資那麽不耐煩：

園藝師小明在後院種了一些植物，四小時以後他就翻開土查看，那些種子什麽動靜也沒有。小明又把它們埋進土里。過了四小時他再看，還是一無所獲。一周以後，他見到院子里還沒有任何成果，就心灰意冷，說種子是水貨。

如果從事農業像華爾街玩轉全球金融：

小明和小紅每人各有一頭奶牛。他們沒有擠出奶牛的牛奶，然後把奶加工乳制品出售，而是把這兩頭牛都用去抵押，換回一款結構性票據，將它出售給冰島的養老基金，得到一筆資金，再用那筆錢買下附近農場的信用違約互換（CDS）。然後他們就開始造謠，引起附近那家農場資產的投資者拋售其資產，出現擠兌，迫使那家農場申請破產。接下來，小明和小紅利用之前買那家農場CDS獲得的回報，通過盧森堡的空殼公司跨境進行非法交易，向美國亞利桑那州的一位寡婦出售對方想當然以為會存在牛奶商品的牛奶期貨。至於小明和小紅，他們真正擁有的兩只奶牛還在農場里悠哉悠哉地哞哞叫，兩個人一年已經賺了3490萬美元。

如果平時做體檢像檢查投資組合那樣：

小明清早一醒就查了查自己的血壓，早飯前、吃早飯時、早飯後、離開家去上班以前又各檢查了一次。開始工作的時候，他測了一下體內的膽固醇，午飯前測了一次，到晚上睡覺以前又測過兩次。白天小明稱了四次體重，有一次發現自己輕了113.5克。他給醫生打電話，想搞清楚體重到底為什麽減輕。

如果醫生得到執業資格的難度像股票經紀拿資格證：

小明會背誦“髖骨與腿骨連接”這樣的理論，所以他可以當上神經外科醫生，我們的性命就掌握在他手中。

如果評葡萄酒就像把次級抵押貸款支持的債券評為A級：

小明把一瓶果汁飲料Capri Sun放在戶外，幾小時後就稱它是1945年的木桐酒莊頂級幹紅。而葡萄酒的專家要花十年功夫才具備品評這種高級紅酒的能力。即便成為專家，他們還會為酒的香調和余味爭論。

如果手機話費像買共同基金那樣收費：

小明有一部手機，他根本不知道手機每個月花了自己多少錢，因為所有的費用都自動從銀行賬戶里扣掉，卻不會寄給他賬單。他付費的過程從沒離開過銀行，每季度都靜悄悄地扣掉那部分費用。只有查看下每年有多少個人資產，小明才知道手機費到底有多少，因為那部分費用相當於年度資產總額的1%，這麽算下來，一年他共付2萬美元。可他平時根本不清楚，移動運營商最喜歡這種收費方式。

如果把私人公司當作公開上市的企業：

小明開了一家烘焙坊，通常一年可以賣掉1052塊松餅。明年他預計會賣出1051塊松餅。主動投資者、投資大佬Carl Icahn就站在他的店門口高聲出言不遜，說小明沒有能力開店。

如果醫生像金融顧問那樣毫無歧視地提供建議：

醫生小明在電視節目上談論一種抗癌新藥的益處，卻不會提到，除非觀眾已經罹患癌癥，否則他的建議就和觀眾毫無關系。結果是，盡管並未確診為癌癥，還有半數該節目的觀眾開始服用該醫生推薦的那種新藥。

如果像看待股市波動那樣看房產：

某一天，租房網站Zillow的一名編程員小明心情不好，索性調整了網站的算法，讓美國市場出售的每間房看起來都比前一天市值貴了10%。小明因此丟了飯碗，接替他的程序員小紅又把房價調回原來的價位。這種房價波動導致美國房產市場集體下滑。

當天的晚間新聞采訪了多位專家，他們都將買房稱為騙局，說這種行為是欺詐。10%的業主次日賣掉了房產。其中一位業主說：“我愛不愛自己的房子、供不供得起按揭、有沒有打算在這兒住上二十年都不重要。就是風險太高了。”

如果人人都像華爾街那樣對待犯罪行為：

小明打了人。全過程被錄了像。他到底做了什麽已經無關緊要，換了誰都可能入獄。不過，只要小明交一筆錢，就能了結官司，既不必承認罪行，也不用否認行為不當。所以，小明的孩子為他交了250萬美元罰金，這樣他就洗脫了罪責。

（更多精彩財經資訊，點擊這里下載華爾街見聞App)

為什麽現在的人工智能助理都像人工智障？

S先生 2017-04-01 11:55

本文由S先生（微信ID: TheMisterS）授權i黑馬發布。

－ 什麽是智能助理？ －

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%的識別率」而言。

文章評論

匿名用戶

發布

全部評論：10

發布

李純恩：上機的都像壞人