智慧對話機器人如何設計產品主流程框架？

智慧對話機器人是一種極度類人的人與物的溝通媒介，它可以幫助個體透過類人的溝通方式達到自己的目的。你知道智慧對話機器人產品主流程框架是如何設計的嗎？本文作者對此進行了詳細介紹，與大家分享。

開篇（《 裡我們已經簡單介紹了智慧對話機器人的產生背景以及當下的現狀（並非理想中的智慧），AI產品經理應該如何做好充足的準備以便於設計出一款在當下技術邊界內有較好使用者體驗的對話機器人產品。

從功能實現層面對智慧對話機器人的做了 五個類別區分，如果從對話機器人實際解決的問題範圍來看，也可以將其分為兩個大類： 封閉域對話機器人和 開放域對話機器人。不難從字面上就很容易理解，封閉域即為在限定的領域內完成對話，而這些領域是由設計產品的人進行人為限定的；而開放域則沒有限制，一般支援的會話是廣泛領域內的公共範疇。

但就目前的最終效果來看，開放域對話機器人很難做好使用者體驗，一旦給使用者設定什麼問題都可以問什麼話都可以聊，那使用者就一定會問出bug… 實際大多數的產品設計目前都聚焦於一個或幾個特定領域內（開放域僅作為分支補充功能），便於為目標使用者提供更好的產品體驗。

智慧對話機器人的主體框架：

通常來說如上圖所示，智慧對話機器人整個框架分為7個模組，但也可根據實際設計的產品功能進行增減，增減的部分主要聚焦在輸入/輸出的部分，後面會進行具體解釋。

01 輸入/輸出

對話機器人，那對話就是一個核心的互動方式，那麼基於具體的產品是軟體or硬體，硬體裡面是有屏or無屏，其實都會在輸入輸出的互動方面產生細微的差異。

語音輸入當然是便捷的，它突破了用手打字的部分侷限，從而擴充套件了智慧化產品的使用場景，比如開車時的語音地圖導航，比如臨睡前的語音關燈等等。

另一方面，我們必須意識到， 語音輸入自身存在的侷限性：

• 語音輸入因為有後面一步語音識別的技術瓶頸（一方面是遠場語音識別的準確率，一方面是各類方言的識別準確率），會有一定的識別錯誤導致最終結果翻車，影響使用者體驗，給使用者造成“智障機器人”的感覺；
• 語音輸入需要一定的使用條件，並不是所有使用者在何時何地都可以進行語音這種互動方式的輸入，使用者有需要保護隱私的使用場景；

而 語音輸出的侷限性也顯而易見，一旦機器人的回答話術比較長，那麼對於使用者來說等待機器人輸出完整的語音所花費的時間絕對比透過視覺獲取同等資訊高出很多倍，所謂“一目十行”即是這個道理。畢竟人類已經掌握了透過視覺快速從大量文字圖片資訊中獲取關鍵資訊的技巧。

因此，如果你的產品有讓使用者可以進行操作的螢幕，那麼在輸入/輸出端，最好支援多模態，比如語音、文字、以及觸覺（透過螢幕點選、完成部分對話場景的資訊互動）等適應使用者複雜的使用場景，提升使用者使用效率。

當然，在資訊輸出的部分，目前也有多款純軟體類產品僅支援文字圖片等結果輸出，不支援語音輸出，究其原因大概有以下3個方面：

1. 資訊輸出效率低；
2. 基於第一點，部分產品場景不適合使用語音輸出，比如任務型對話機器人結果較為複雜時；
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模組仍是採用傳統的基於規則的方法加上新的基於模型演算法的生成式對話。

基於傳統規則，如上文舉例的“訂機票”的場景，即可簡單的透過規則的方式實現。但是，如果在開放域進行對話聊天，那就很難基於規則去完成會話設計，同時基於規則的回覆會讓使用者感覺機器人死板，無趣。而透過模型生成的語言回覆，則更加多樣，也會在產品層面體現出機器人的情感態度等等。

當然，自然語言生成在其他應用場景有更為廣泛的應用，比如寫詩詞、寫春聯、寫文章、生成文字摘要等等，此處就不再展開講了。

以上為智慧對話機器人產品主流程框架設計的詳細介紹，希望對你有所幫助～