幫我看看下個星期五去北京，下午3點多，從虹橋出發(fā)，國航的航班。“——這一類的表達方式在幾乎從來沒有出現(xiàn)過。哪怕是在用戶最熟悉的場景，也很難確保一個句子的表達里包含了所有必須的檢索條件。而且，用戶還會不停的補充更多的個性化需求。
對于用戶自己比較了解的場景，如：訂機票需要提供到達地，用戶提出的大多數(shù)需求，在最初都是非常簡單，然后逐漸開始細化的。所以需要當(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)的表達方式，而且看似簡單，但是目前沒有任何一個NLU的系統(tǒng)或產(chǎn)品能夠正確的理解。主要的阻礙就是對邏輯的理解，還有在基于上下文對話中的指代關(guān)系的理解失敗。
3、NLP不是全部，還要有能力履行（API困境）
NLU并不是智能助理發(fā)展的瓶頸，供給端的數(shù)據(jù)才是。
我們假設(shè)如果有一個黑科技出現(xiàn)，使得NLP有了極大的進步，以至于兩個條件：1）基于上下文場景的對話；2）口語邏輯，都能被理解了，甚至還能基于場景和上下文用NLG來生成各類問題——它能理解我們所有講出來的需求。
在用戶熟悉的范圍內(nèi)，它能結(jié)合所有的過去的對話，歷史記錄等等內(nèi)部外部條件，幫助用戶盡可能的實現(xiàn)“不用開口，就知道我在這個的需求”。比如當(dāng)用戶提出“推薦餐廳的需求”：
用戶：“女朋友周日過生日，推薦一個餐廳，找有江景的，最好桌子旁邊有一個大落地窗戶，能看到外面的夜景。吃的不要太貴，環(huán)境好點，有現(xiàn)場音樂的最好是爵士，不要太吵的。” （btw，這是一個真實需求）
Agent：“菜系有偏好么？”