用戶：“意大利餐和法餐都可以，對了不要離外灘太遠(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%的識別率“ 而言。
登陸|注冊歡迎登陸本站，認(rèn)識更多朋友，獲得更多精彩內(nèi)容推薦！