編輯導語：隨着科技的進步和普及，AI 產品逐漸走進了大眾的視野，從手機語音助手到各類智能音箱，AI 技術不僅方便了我們的生活，還逐漸改變了我們的習慣。本文作者在做了20+個AI多輪對話項目後，為我們總結了這篇文章。
在AI走進大眾視野的這幾年，我們或多或少的都會接觸到一些AI的產品，你去諮詢天貓客服，一開始肯定是個機器人接待你的；你接到一個電話問你是否需要買保險、辦信用卡或貸款，可能對方就是一個機器人；當然最常見的就是智能音箱。
以天貓精靈為例：
- 用户：天貓精靈
- 天貓精靈：主人，您説
- 用户：放一首逃跑計劃的《夜空中最亮的星》
- 天貓精靈：好的，馬上為您播放這首好聽的歌。
看起來很不錯的樣子，但是如果用户接着説“幫我換成新褲子的《沒有理想的人不悲傷》”。
不好意思，這時天貓精靈是不會響應你的。因為天貓精靈在上一輪迴復完用户的話之後，就結束了對話。想要再次跟她對話，必須喊“天貓精靈”再次喚醒後，才能繼續對話。
以上這種每次只能進行一輪對話的模式，我們稱之為“單輪對話”。其實目前大多數機器人都是單輪對話的模式。比如説閒聊：
- 用户：你好
- 機器人：你也好呀
- 用户：我今天很開心
- 機器人：看到你這麼開心，我也是很開心呀
- 用户：我相信我的明天會更好
- 機器人：你是最棒的，加油
- …….
這裏可能你又會問了，這不是連續的對話嗎，怎麼會是單輪呢？
是的，因為這些對話，每一輪之間都是相互獨立，上下文之間沒有關聯關係，我們暫時稱之為單輪對話。與單輪對話相對的概念是多輪對話。
舉例：
- 用户：幫我訂個去深圳機票
- 機器人：請問您哪裏出發呢？
- 用户：上海出發
- 機器人：好的，上海出發，那您要幾點出發呢
- 用户：明天晚上8點左右
- 機器人：好的，為您找到明天晚上8點左右，從上海到深圳的機票有這些。
- …….
是的，這就是多輪對話，也是本文主要討論的內容。如果説NLP是AI界皇冠上的明珠，那麼多輪對話就是NLP界皇冠上的明珠。由此可見多輪的話的江湖地位。
由上面例子，跟單輪對話的對比，引出了對多輪對話的定義。
一、什麼是多輪對話1. 多輪對話的定義定義：根據上下文內容，進行連續的，以達到解決某一類特定任務為目的的對話。
這裏有3點：
- 上下文：機器人的每次出話，都是跟上文有強關聯關係的；
- 連續性：一個完整的對話內可進行多次連續的對話交互；
- 某一類特定問題：這裏主要是限定下討論範圍，討論的是一個封閉域內的問題，一個完整的對話，只負責處理一個特定的任務。比如説訂機票是一個特定的任務；訂外賣是一個特定的任務；查天氣也是一個特定的任務。
多輪對話跟機器人的關係圖：
通常來説，一個全能型的對話機器人是由很多個類型的機器人組成的，比如説閒聊機器人、任務機器人、問答機器人。而一個任務機器人內又可以包含多個多輪。
3. 多輪對話和多輪對話平台的關係那怎麼來實現多輪對話呢？市面上各大廠家的做法是開發一個用於構建多輪對話的平台。有了這樣的平台，你就可以構建出你想要的對話流程。
多輪比較擅長處理的兩類經典任務：
- 分類任務（如上左圖），用户的表達屬於分支的哪一類，每一類應該走什麼分支。
- 信息收集/查詢類任務（如上右圖），需要向用户收集哪些必要信息，如查航班，需要收集出發地、目的地、出發時間3個必要信息。
如果把多輪對話比作一輛汽車的話，那多輪對話平台就是一個組裝車間，底層的各類AI工具，就相當於汽車的零部件，因此我們可以在對輪對話平台內，用各種的工具，來組裝出你想要的對話邏輯。
這裏你可能想説，這個哪裏智能了，不就是我們實現定義好的流程嗎？是的，它確實並沒有你想象中的那麼智能，沒有你想象中的那樣通過大量的數據就能自己學習出一個流程，也沒你想象中的那樣機器可以自己生成新的答覆話術。
但是它確實能解決很多工業上的問題，特別是一些比較固定的流程，比如説：
- 電銷，機器人詢問用户是否感興趣；這裏機器人最重要的事情不是促成下單，而是篩選有意向的用户。比如説用户説感興趣，甚至是跟機器人多聊幾句，就會被標識為感興趣，然後後面就會有人工客服來跟進了。
- 自助服務，傳統的IVR是通過按鍵的形式來識別用户的意圖的（充值服務請按1，業務辦理請按2…..），那智能機器人可以直接識別並理解用户的自然語言來提供服務（如用户可以直接説：我要查詢話費）。
- 滿意度回訪，機器人通過電話回訪來收集用户對服務的滿意度情況，是否滿意、不滿意原因是什麼，有什麼改進意見等等。
- 疫情期間人員基本情況調查，如收集用户是否有從武漢回來、有沒有接觸從武漢回來的人，有沒有發燒、流鼻涕等信息。
這些固化的流程完全可以用機器人來完成，大大減少人力成本。相比於人，機器人可以一天24小時，同一時間多線路給多個人撥打電話。
二、多輪對話平台由哪些功能模塊組成1. 按流程的執行順序分1）進入多輪對話任務的條件
比如識別到有訂票的意圖，則進入到訂機票的多輪對話任務中；也可以通過關鍵字、指令等方式進入到多輪對話任務中。
2）機器人的應答話術
即用户的每一個動作（query），機器人應該用什麼話術去應答。
目前任務類型的對話通常話術都是預設的，基本不會是生成式的。因為任務性對話容錯率很低，寧可答不上，也不能答錯。生成式的應答話術，更多是在閒聊機器人中，因為閒聊容錯率相對比較高。
3）流程流轉條件的設置（if）
4）滿足條件執行動作的設置（then）
條件設置和動作設置是整個流程的核心思想，整個對話流程都是按：如果條件是什麼…那麼執行什麼動作…的格式設置。
5）退出多輪對話任務的條件
最後，這個對話肯定是不能永遠繼續下去的，需要設置結束對話的條件，比如説常見的有以下幾種情況：
- 任務已經完成結束，比如説已經收集完需要收集的信息；
- 用户主動要求轉人工結束，比如説用户跟機器人聊不下去了，要求要人工服務；
- 用户長時間未回覆結束，比如説機器人出話後，用户10分鐘內沒有響應就自動結束。
按另外一個維度，可以把多輪對話分為流程和解析工具。
1）流程–就是設定的流轉規則，如是什麼，那就做什麼
（如下圖，如果是肯定回覆那就跳轉到A節點，如果是否定回覆就跳轉到B節點）這一塊跟AI沒有什麼關係。
2）解析工具–理解用户説的話是什麼
（如上圖，如果用户説“我是他媽媽”，機器人怎麼知道這是屬於否定回覆，這就是解析工具要做的事情），也是整個多輪對話的核心。
解析工具主要分類兩大類：信息收集、文本分類。
1）信息收集
收集信息的方式主要有兩種：對話裏收集、對話外收集。
- 對話裏收集：用各種解析器在對話內容中解析出所需信息，比如説時間解析器收集時間、地址解析器收集地址、電話號碼解析器收集電話號碼等。
- 對話外收集，即不是通過對話內容來收集的，而是通過其他數據交互方式獲取的，比如説通過手機定位，來獲取用户的位置信息；通過賬號，來獲取用户的基本信息等等。
2）文本分類
對話中的文本分類，通常又分為兩大類：有較完整的句子結構類文本、超短文本。
- 有句子結構類文本（someone want to do something）描述了一個比較完整的意圖。有主謂賓這樣的句子結構。比如説意圖、FAQ，就是有句子結構的文本類型。
- 超短文本，沒有句子結構的，比如説；好的、可以、ok、行。常見的處理這類型超短文本的解析工具有：語言分類器、選擇解析器。
除了是否有句子結構外，兩類型的文本分類解析工具的應用場景也不一樣。有句子結構類文本解析工具，是全局的應用。比如説“我要轉人工服務”，可以做出一個意圖，不管在流程的哪個節點，用户表達了這樣的意圖，都可以識別。
超短文本類解析工具，是局部應用的，是強依賴上線文的。比如説用户單獨説一句“不是的”，如果沒有上下文，是沒有意義的。
機器問“請問您是深户嗎”，用户可以回覆“不是的”；
機器問“請問您是深圳高校學生嗎”，用户可以回答“不是的”；
因此同樣“不是的”，在不同的地方表達的意思是不一樣的，只有聯繫上文，才能確定明確的含義。
解析工具直接決定了多輪對話平台能力的上限，而決定解析工具能力又可以分為兩層：基礎技術層、產品層。
- 基礎技術層：取決於NLP的能力，包括分詞、詞性標註、NER識別、詞法分析、句法分析、情感分析、句子相似度等底層的能力。
- 產品層：有了強大的NLP能力，那能不能把這些技術落地，包裝成實際的解決方案，去解決實際的場景問題，就是考驗底層技術產品化的能力了。
1）例子1
- 用户：幫我訂一張機票
- 機器人：好的，請問你要從哪裏出發呢
- 用户：深圳明天會下雨嗎
問在哪裏出發後，我們往往會調用一個地址解析器來解用户接下來説的話，用户回覆“深圳明天會下雨嗎”，這時會抽到地址【深圳】，那機器人就理解為出發地是【深圳】了。
解析器確實沒有問題，解出了地址【深圳】，但是解出的地址是不是符合上文需要填充的槽位，這時機器人就無能為力了，因為解析器只管解析，不管業務。
2）例子2
問是幾月份，我們往往會在這個時候調用一個時間解析器來解用户接着説的話，用户只回復“8”，這時時間解析器解不出結果，因為時間解析器只能解“8月”、“8號”等等這個帶單位的時間。純説一個數字，機器人就懵掉了。
從上面兩個例子就可以看出，解析工具跟實際應用場景的隔閡，導致了運用起來不夠靈活，主要矛盾點體現在：
- 如果解析工具跟場景分割開，就會出現以上的問題；
- 如果解析工具跟場景緊密關聯，那通用性就比較差，這樣會導致這個解析工具僅適用於某個場景，而無法遷移到其他場景。
舉例：
- 用户：幫我訂一張機票
- 機器人：好的，請問你要從哪裏出發呢
- 用户：深圳明天會下雨嗎
還是以上面例子為例，首先來了解幾個概念：
- 主流程與輔助問答：這個多輪的主流程就是收集訂機票所需要的槽位，輔助問答是隻在主流程的過程中用户可能會問些相關的問題，如“怎麼退票”、“深圳明天天氣怎麼樣”。機器人回答完輔助問答之後，會繼續回答主流程，繼續收集槽位信息。
- 信心分：是指解析工具，匹配到結果的分數值。假設分數值是從（0–100），假設信心分高於80分機器人就採納。
- 中控優先級：是指取解析工具結果的優先順序，比如説解析工具A的優先級大於解析工具B，那解析工具A和B解析結果的信息分都是90分，那機器人會優先取A的結果。
ok，瞭解了上面的概念之後，我們再回過來看這個例子。
用户説了：深圳明天會下雨嗎？
會有兩個解析工具解到結果，假設地址解析工具得到的信心分是90分，意圖解析工具解到的【查天氣】意圖的信心分也是90，但是由於地址解析工具屬於主流程，優先級高於查天氣意圖，因此機器人最後選擇的是前者。因此機器人的動作是把【深圳】當作了出發地填入槽位。
因此，從這裏可以看到有兩個問題：
- 人為事先設定的死死的規則，是沒辦法應對在自然對話中無窮無盡的場景。因此機器人的決策機制不能全由預設規則決定，應該是要結合實際的數據，比如説可以針對單個節點做訓練，A類數據出A回覆；B類數據出B回覆。
- 解析工具與工具之間沒有建立連接，它們之間各自評分，相互之間沒有通訊，沒有協作關係。如果解析工具之間先經過討論，再給出結果，是不是會有更好的效果呢，就比如説，識別到查天氣的意圖之後，意圖工具會告訴地址解析工具，這裏的【深圳】是隻深圳的天氣，可能不是你想要的出發地，你要再考慮下。這只是一個腦洞，但值得我們去深思。
這裏先理清一對概念：
- 預設式話術：話術提前設定，不會改變
- 生成式話術：機器人根據場景的各變化因素，而創造出的話術
舉例：
- 機器人問題1：請問你平均每天運動有超過30分鐘嗎？
- 用户：我平均每天至少跑步1小時
- 機器人問題2：請問你會經常熬夜嗎？
機器人的話術已經被事先死死的設定了，問完問題1，就問問題2。沒有根據用户的話做出一些反饋，就會顯得很生硬。
假設能這樣：
- 機器人問題1：請問你平均每天運動有超過30分鐘嗎？
- 用户：我平均每天至少跑步1小時
- 機器人問題2：那你很自律啊，這麼説你應該不會經常熬夜吧？
這樣不但能對用户的回答做出響應，還根據用户前面説的話來調整問題2的問法。這就是非生成式回答無法達到的效果，這也是機器人比較死板的原因。
4. NLP理解的維度比較侷限舉例：
還記得她嗎，在採訪中她説“我已經用了洪荒之力了”。如果你只看文字，你能理解她裏面所表達的是滿意的情緒嗎？
正常人與人的對話，一般會根據語調、文字、表情、動作等維度，組合起來理解對話所表達的內容。但是目前大多數的多輪對話平台都是隻以【文字】單一維度來做解析處理，即使很多平台都亮出了自己在ASR環節的情緒理解有多麼強大，但真正跟多輪平台運用起來是隔離開的，訓練數據只是轉譯成文本的形式訓練，而不是直接拿語音去訓練。
不同語氣的“呵呵”，表達的意思是不一樣，有的是開心，有的是諷刺。如果丟失了語調的維度，那解析的結果肯定是會失真的。
4. 使用門檻高，優化難度大在以用户體驗為王的時代，如果你操作一個軟件或APP，你還要看它的説明書，甚至看了説明書還不會操作，那你肯定會瘋掉。
沒錯，多輪對話操作平台就是一個看了説明説還不會用平台，通常需要經常專業的培訓才會使用，因此是有很高的使用門檻的，而且邏輯能力不好人，還真做不來。
除了操作門檻高，後續的優化也不靈活。不是説像我們想象中的那麼簡單，加點數據，標註下就能解決的。比如説機器人詢問：你是馬先生嗎？
你一開始想到的用户可能的回答是兩類：肯定回覆（是的、我是）、否定回覆（不是、打錯了）。但是上線後，你會發現還有很多類型的回覆：中性回覆【怎麼啦、你説】、式有關係人【我是他老婆、我是他兒子】、反問【你是誰呀、是機器人吧你】
每增加一個分類，就要重新在流程圖裏增加分支，從新設定規則等等，並非直接加點數據重新訓練就能解決問題了。
四、多輪對話平台未來的發展方向是怎樣的1. 在目前的框架下去優化前面大篇幅討論了，目前多輪對話平台的核心是解析工具，因此我覺得未來的優化方向也是在解析工具上面，比如説：
- 怎麼讓解析工具通用，然後又可以跟特定的場景緊密結合在一起；
- 怎麼讓解析工具之間的協作更加高效，更加合理；
- 怎麼讓後期優化延伸性更加廣，讓機器有條不紊的接納更多的分類。
目前的做法是對話流程、對話分支是由人工搭建的，這種方式對數據的利用率是非常低的。只是根據對話記錄，人為整理出對話流程，而對話之間的上下文關係是不參與到模型訓練的。機器人不會隨着人機對話量的增加而變得更加聰明。
未來的優化方向一定是最大化的利用數據，比如説通過給機器輸入大量的對話記錄，機器能夠學習出對話之間的邏輯關係，然後自己能學習出一個對話流程。
最後，用一句話總結下目前的多輪對話平台：在解決固定化流程的問題上，確實能降低人力成本，但是對話比較死板，要想做到向人與人之間的自然交流，還有很長的路要走。
AI人，一起加油吧！
本文由 @Jimmy 原創發佈於人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。