具備基于上下文的對話能力 (contextual conversation)
具備理解口語中的邏輯 (logic understanding)
所有能理解的需求，都要有能力履行（full-fulfillment）
1、基于上下文的對話能力(contextual conversation)
在當(dāng)前，做助理的產(chǎn)品的底層技術(shù)基本都是圍繞NLU（自然語言理解）打造的，很多還沒有涉及到NLP?？墒菬o論是大公司還是小公司的NLU都是讓人失望的。舉個簡單的例子，在大公司的幾個產(chǎn)品上提出需求：我下周五要去北京，幫我查一下航班。
需要識別意圖：查機(jī)票
需要識別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é)果，看上去比幾個巨頭更強(qiáng)大。
我們繼續(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ù)問問題而已。
不能真正理解上下文的對話（機(jī)票查詢）：
AGENT： 從哪里出發(fā)？
用戶：上海虹橋機(jī)場
AGENT：到哪里？
用戶：還是從浦東走吧
AGENT：好的，從虹橋出發(fā)到浦東的航班是......
在上面的對話，AI Agent在問第二個問題的時候，不能理解用戶對前一個回答的修改（出發(fā)地從“虹橋”改為“浦東”），只是按照預(yù)先設(shè)計對話的順序，填上命名實體識別得來的entity。繼而查詢不到結(jié)果，給用戶的感覺就是笨。
真正理解上下文的對話（機(jī)票查詢）：
AGENT：從哪里出發(fā)？
用戶：上海虹橋機(jī)場
AGENT：到哪里？
用戶：算了，從浦東走吧
AGENT：好的，出發(fā)改為浦東。那到達(dá)城市呢？
用戶：北京
AGENT：好的，從浦東到北京的航班是...（給出正確的結(jié)果）
而具備真正上下文理解的對話，agent可以正確理解用戶第二個回答的內(nèi)容（從浦東走），其實是在修改上一問題的回答（出發(fā)機(jī)場），而不是真的在回答第二個問題（到達(dá)地在哪里）。
這只是上下文的例子，而對于服務(wù)類agent而言，所有后續(xù)的NLP功能都基于上下文對話為前提。這些看上去其實都是非常簡單的需求，但是當(dāng)前沒有任何一個2C的agent可以做到。
可能有人會問，大部分用戶都應(yīng)該在第一時間把需求表達(dá)出來吧，為什么還需要對話？實際上，真正操作過大量案例的同學(xué)就會發(fā)現(xiàn)，用戶不可能如此”貼心“地按照開發(fā)者的設(shè)計來提出需求。