智能對話機器人是一種極度類人的人與物的溝通媒介，它可以幫助個體通過類人的溝通方式達到自己的目的。你知道智能對話機器人產品主流程框架是如何設計的嗎？本文作者對此進行了詳細介紹，與大家分享。
開篇（《智能對話機器人產品設計——開篇》）里我們已經簡單介紹了智能對話機器人的產生背景以及當下的現狀（並非理想中的智能），AI產品經理應該如何做好充足的準備以便於設計出一款在當下技術邊界內有較好用戶體驗的對話機器人產品。
從功能實現層面對智能對話機器人的做了五個類別區分，如果從對話機器人實際解決的問題範圍來看，也可以將其分為兩個大類：封閉域對話機器人和開放域對話機器人。不難從字面上就很容易理解，封閉域即為在限定的領域內完成對話，而這些領域是由設計產品的人進行人為限定的；而開放域則沒有限制，一般支持的會話是廣泛領域內的公共範疇。
但就目前的最終效果來看，開放域對話機器人很難做好用戶體驗，一旦給用戶設定什麼問題都可以問什麼話都可以聊，那用戶就一定會問出bug…實際大多數的產品設計目前都聚焦於一個或幾個特定領域內（開放域僅作為分支補充功能），便於為目標用戶提供更好的產品體驗。
智能對話機器人的主體框架：
通常來說如上圖所示，智能對話機器人整個框架分為7個模塊，但也可根據實際設計的產品功能進行增減，增減的部分主要聚焦在輸入/輸出的部分，後面會進行具體解釋。
01 輸入/輸出
對話機器人，那對話就是一個核心的交互方式，那麼基於具體的產品是軟體or硬體，硬體裡面是有屏or無屏，其實都會在輸入輸出的交互方面產生細微的差異。
語音輸入當然是便捷的，它突破了用手打字的部分局限，從而擴展了智能化產品的使用場景，比如開車時的語音地圖導航，比如臨睡前的語音關燈等等。
另一方面，我們必須意識到，語音輸入自身存在的局限性：
- 語音輸入因為有後面一步語音識別的技術瓶頸（一方面是遠場語音識別的準確率，一方面是各類方言的識別準確率），會有一定的識別錯誤導致最終結果翻車，影響用戶體驗，給用戶造成「智障機器人」的感覺；
- 語音輸入需要一定的使用條件，並不是所有用戶在何時何地都可以進行語音這種交互方式的輸入，用戶有需要保護隱私的使用場景；
而語音輸出的局限性也顯而易見，一旦機器人的回答話術比較長，那麼對於用戶來說等待機器人輸出完整的語音所花費的時間絕對比通過視覺獲取同等信息高出很多倍，所謂「一目十行」即是這個道理。畢竟人類已經掌握了通過視覺快速從大量文字圖片信息中獲取關鍵信息的技巧。
因此，如果你的產品有讓用戶可以進行操作的屏幕，那麼在輸入/輸出端，最好支持多模態，比如語音、文字、以及觸覺（通過屏幕點擊、完成部分對話場景的信息交互）等適應用戶複雜的使用場景，提升用戶使用效率。
當然，在信息輸出的部分，目前也有多款純軟體類產品僅支持文字圖片等結果輸出，不支持語音輸出，究其原因大概有以下3個方面：
- 信息輸出效率低；
- 基於第一點，部分產品場景不適合使用語音輸出，比如任務型對話機器人結果較為複雜時；
- 產品實現複雜度增加，進行語音輸出過程中是否支持打斷，打斷後是否需要重新喚醒，上次對話結果是否保留等等；
綜上：在輸入輸出方面，可依據自己的產品場景進行合適的選擇。
02 語音識別（ASR）/ 語音合成（TTS）
一般的智能對話機器人產品目前直接使用主流廠商提供的功能即可，包括：訊飛、百度、騰訊等。業內總體語音識別準確率在量級上相差不是很大，一般分免費和付費兩種，用戶體量小一般免費即可夠用，稍大點的產品需要對比各家不同的資費進行選擇即可。
在語音識別方面目前可能存在的問題是：大廠的語音識別語料基於更廣泛的場景，而一旦你的產品屬於垂直領域，即有一些特殊行業的辭彙時，就會出現通用識別能力識別不準的情況，從而造成整個流程識別錯誤最終反饋給用戶錯誤的結果。
當然，大廠也是可以做定製的，目前也支持用戶進行詞庫的導入，從而在一定程度上解決這個問題。同時，多數廠商也有語音識別糾錯的功能，總體體驗都還可以。此處不再贅述，相關信息可自行查詢。
03 自然語言理解（NLU）
這個模塊即為機器人理解用戶輸入信息的核心模塊，即讓機器人「理解」用戶。主要分為2個部分：意圖識別（intent）和槽位填充（slot filling）。
意圖識別需要由產品所需要支持的功能進行圈定，可以識別單個意圖也可以識別多個。比如，你是一個單純的查天氣的機器人，那麼你的意圖識別領域就是需要界定出用戶輸入的信息是否是「查天氣」，又比如你是一個出行領域的機器人，那麼你的意圖識別就需要確定是「訂機票」還是「訂火車票」「訂汽車票」等等。
意圖識別目前涉及到的技術主要分兩大類：基於規則、基於演算法。而意圖識別的難點就在於每一種意圖都有多種多樣的表達，比如用戶要「訂機票」，可能存在的表達如下：
- 我要訂機票
- 幫我查一下從北京飛上海多少錢
- 我下周要出差，查下航班
- 查一下五一飛廈門的頭等艙
僅僅基於規則很難準確識別用戶的多種表達方式，所以目前主流做法是【少量規則+演算法模型】，而比較主流的演算法模型包括：CNN、LSTM等。
槽位填充即是想要達成目標意圖所需要的必備或者識別等關鍵內容。比如意圖識別為「查天氣」那麼所需要填充的槽位就是「地點」，機器人需要回答天氣，必須是指定城市或區縣的天氣，這個「地點」即為必填的【槽位】。而如果是「訂機票」的場景，那麼需要的槽位就包括「出發地」「到達地」「出行日期」，而用戶如果說了機票業務場景內的「公務艙」則可以作為非必填但需要識別的實體信息。
04 對話管理（DM）
一般多輪對話機器人均需要做對話管理，因為對話是持續進行的，所以每次機器人進行答覆時需要針對當前的會話狀態給出合適的回復。對話管理分為兩個模塊：狀態跟蹤（DST)、策略優化（DPO）。
狀態跟蹤就是表示：t+1 時刻的對話狀態，依賴於之前時刻 t 的狀態，和之前時刻 t 的系統行為，以及當前時刻 t+1 對應的用戶行為。因此確認當前意圖和槽位信息是狀態跟蹤的核心，需要明確當下的對話狀態進展到哪一步。
策略優化則是根據狀態跟蹤的結果給出機器人應該在當前對話狀態下需要給出的正確回復。
舉例來說在「訂機票」這個對話過程中，需要根據用戶當前不同的對話狀態節點給出不同的回復，如下兩種狀態：
場景一：
- 用戶：訂機票
- 機器人：請問您要訂去哪裡的機票呀？
- 用戶：去北京
- 機器人：請問您從哪個城市出發？
- 用戶：上海
- 機器人：請問您打算什麼時候出發？
- 用戶：下周一
- 機器人：給出具體的機票信息結果
場景二：
- 用戶：我要訂從上海飛北京的機票
- 機器人：請問您打算什麼時候出發？
- 用戶：下周一
- 機器人：給出具體的機票信息結果
從以上兩種場景可以看出，機器人給出的回復需要判斷用戶之前信息給出的狀態，如果設定的必填【槽位】全部滿足則給出最終結果，否則需要根據設定的順序依次進行詢問。當然，這裡面還有一種情況是，用戶在對話過程中跳出了當前的意圖，比如訂機票的過程中詢問目的地的天氣，那麼機器人需要根據已有的設定給出新的意圖所需要回答的話術。
05 自然語言生成（NLG）
自然語言生成即是通過對話管理之後確認需要給用戶的答覆內容的過程。目前，多數產品的NLG模塊仍是採用傳統的基於規則的方法加上新的基於模型演算法的生成式對話。
基於傳統規則，如上文舉例的「訂機票」的場景，即可簡單的通過規則的方式實現。但是，如果在開放域進行對話聊天，那就很難基於規則去完成會話設計，同時基於規則的回復會讓用戶感覺機器人死板，無趣。而通過模型生成的語言回復，則更加多樣，也會在產品層面體現出機器人的情感態度等等。
當然，自然語言生成在其他應用場景有更為廣泛的應用，比如寫詩詞、寫春聯、寫文章、生成文本摘要等等，此處就不再展開講了。
以上為智能對話機器人產品主流程框架設計的詳細介紹，希望對你有所幫助～
本文作者：丸子妹，微信公眾號：丸子筆記