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

9 評論 11693 瀏覽 74 收藏 13 分鐘

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

開篇(《智能對話機器人產品設計——開篇》)里我們已經簡單介紹了智能對話機器人的產生背景以及當下的現(xiàn)狀(并非理想中的智能),AI產品經理應該如何做好充足的準備以便于設計出一款在當下技術邊界內有較好用戶體驗的對話機器人產品。

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

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

智能對話機器人的主體框架:

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

01 輸入/輸出

對話機器人,那對話就是一個核心的交互方式,那么基于具體的產品是軟件or硬件,硬件里面是有屏or無屏,其實都會在輸入輸出的交互方面產生細微的差異。

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

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

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

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

因此,如果你的產品有讓用戶可以進行操作的屏幕,那么在輸入/輸出端,最好支持多模態(tài),比如語音、文字、以及觸覺(通過屏幕點擊、完成部分對話場景的信息交互)等適應用戶復雜的使用場景,提升用戶使用效率。

當然,在信息輸出的部分,目前也有多款純軟件類產品僅支持文字圖片等結果輸出,不支持語音輸出,究其原因大概有以下3個方面:

  1. 信息輸出效率低;
  2. 基于第一點,部分產品場景不適合使用語音輸出,比如任務型對話機器人結果較為復雜時;
  3. 產品實現(xiàn)復雜度增加,進行語音輸出過程中是否支持打斷,打斷后是否需要重新喚醒,上次對話結果是否保留等等;

綜上:在輸入輸出方面,可依據自己的產品場景進行合適的選擇。

02 語音識別(ASR)/ 語音合成(TTS)

一般的智能對話機器人產品目前直接使用主流廠商提供的功能即可,包括:訊飛、百度、騰訊等。業(yè)內總體語音識別準確率在量級上相差不是很大,一般分免費和付費兩種,用戶體量小一般免費即可夠用,稍大點的產品需要對比各家不同的資費進行選擇即可。

在語音識別方面目前可能存在的問題是:大廠的語音識別語料基于更廣泛的場景,而一旦你的產品屬于垂直領域,即有一些特殊行業(yè)的詞匯時,就會出現(xiàn)通用識別能力識別不準的情況,從而造成整個流程識別錯誤最終反饋給用戶錯誤的結果。

當然,大廠也是可以做定制的,目前也支持用戶進行詞庫的導入,從而在一定程度上解決這個問題。同時,多數(shù)廠商也有語音識別糾錯的功能,總體體驗都還可以。此處不再贅述,相關信息可自行查詢。

03 自然語言理解(NLU)

這個模塊即為機器人理解用戶輸入信息的核心模塊,即讓機器人“理解”用戶。主要分為2個部分:意圖識別(intent)和槽位填充(slot filling)。

意圖識別需要由產品所需要支持的功能進行圈定,可以識別單個意圖也可以識別多個。比如,你是一個單純的查天氣的機器人,那么你的意圖識別領域就是需要界定出用戶輸入的信息是否是“查天氣”,又比如你是一個出行領域的機器人,那么你的意圖識別就需要確定是“訂機票”還是“訂火車票”“訂汽車票”等等。

意圖識別目前涉及到的技術主要分兩大類:基于規(guī)則、基于算法。而意圖識別的難點就在于每一種意圖都有多種多樣的表達,比如用戶要“訂機票”,可能存在的表達如下:

  • 我要訂機票
  • 幫我查一下從北京飛上海多少錢
  • 我下周要出差,查下航班
  • 查一下五一飛廈門的頭等艙

僅僅基于規(guī)則很難準確識別用戶的多種表達方式,所以目前主流做法是【少量規(guī)則+算法模型】,而比較主流的算法模型包括:CNN、LSTM等。

槽位填充即是想要達成目標意圖所需要的必備或者識別等關鍵內容。比如意圖識別為“查天氣”那么所需要填充的槽位就是“地點”,機器人需要回答天氣,必須是指定城市或區(qū)縣的天氣,這個“地點”即為必填的【槽位】。而如果是“訂機票”的場景,那么需要的槽位就包括“出發(fā)地”“到達地”“出行日期”,而用戶如果說了機票業(yè)務場景內的“公務艙”則可以作為非必填但需要識別的實體信息。

04 對話管理(DM)

一般多輪對話機器人均需要做對話管理,因為對話是持續(xù)進行的,所以每次機器人進行答復時需要針對當前的會話狀態(tài)給出合適的回復。對話管理分為兩個模塊:狀態(tài)跟蹤(DST)、策略優(yōu)化(DPO)。

狀態(tài)跟蹤就是表示:t+1 時刻的對話狀態(tài),依賴于之前時刻 t 的狀態(tài),和之前時刻 t 的系統(tǒng)行為,以及當前時刻 t+1 對應的用戶行為。因此確認當前意圖和槽位信息是狀態(tài)跟蹤的核心,需要明確當下的對話狀態(tài)進展到哪一步。

策略優(yōu)化則是根據狀態(tài)跟蹤的結果給出機器人應該在當前對話狀態(tài)下需要給出的正確回復。

舉例來說在“訂機票”這個對話過程中,需要根據用戶當前不同的對話狀態(tài)節(jié)點給出不同的回復,如下兩種狀態(tài):

場景一:

  • 用戶:訂機票
  • 機器人:請問您要訂去哪里的機票呀?
  • 用戶:去北京
  • 機器人:請問您從哪個城市出發(fā)?
  • 用戶:上海
  • 機器人:請問您打算什么時候出發(fā)?
  • 用戶:下周一
  • 機器人:給出具體的機票信息結果

場景二:

  • 用戶:我要訂從上海飛北京的機票
  • 機器人:請問您打算什么時候出發(fā)?
  • 用戶:下周一
  • 機器人:給出具體的機票信息結果

從以上兩種場景可以看出,機器人給出的回復需要判斷用戶之前信息給出的狀態(tài),如果設定的必填【槽位】全部滿足則給出最終結果,否則需要根據設定的順序依次進行詢問。當然,這里面還有一種情況是,用戶在對話過程中跳出了當前的意圖,比如訂機票的過程中詢問目的地的天氣,那么機器人需要根據已有的設定給出新的意圖所需要回答的話術。

05 自然語言生成(NLG)

自然語言生成即是通過對話管理之后確認需要給用戶的答復內容的過程。目前,多數(shù)產品的NLG模塊仍是采用傳統(tǒng)的基于規(guī)則的方法加上新的基于模型算法的生成式對話。

基于傳統(tǒng)規(guī)則,如上文舉例的“訂機票”的場景,即可簡單的通過規(guī)則的方式實現(xiàn)。但是,如果在開放域進行對話聊天,那就很難基于規(guī)則去完成會話設計,同時基于規(guī)則的回復會讓用戶感覺機器人死板,無趣。而通過模型生成的語言回復,則更加多樣,也會在產品層面體現(xiàn)出機器人的情感態(tài)度等等。

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

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

 

本文作者:丸子妹,微信公眾號:丸子筆記

本文由 @丸子筆記 原創(chuàng)發(fā)布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協(xié)議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前的打斷機制,你也是跟根據關鍵詞來設置的嗎?

    來自廣東 回復
    1. 如果是指對話過程被打斷,那么打斷機制其實包含兩個方面問題:
      1.如何判定打斷;
      2.如何恢復對話;

      針對問題1,需要通過主導者制定規(guī)則給到機器人,比如重新喚醒、接打電話等;
      針對問題2,則是包含2個層面的機制:a.記錄用戶的對話歷史;b.主動(指定中斷時間)/被動(等用戶重新對話)重新啟動對話;

      來自江蘇 回復
    2. 對話過程中,對話被主動打斷,打斷后,機器人是恢復對話是重復前面說的那句話,還是執(zhí)行下個流程;

      來自廣東 回復
    3. 結論:任務型對話機器人如沒有走到流程結束,那么采用的是恢復之前的對話,依照保存的會話的最新對話狀態(tài)節(jié)點告知用戶,進行顯性確認。否則,可執(zhí)行下一個流程。

      原因:產品設計的核心是滿足用戶當前情景下的需求,對話被打斷且流程未到最終結果,那我們認為用戶需求并沒有被滿足,基于產品效率(快速進入之前流程)和用戶體驗(因對話中斷導致用戶不知道機器人已經收集到哪些信息,需要重新確認),應在會話恢復時將保存的最新對話節(jié)點狀態(tài)告知用戶,并需要用戶進行顯性確認,確認是否繼續(xù),如用戶給予肯定確認則按照當前意圖繼續(xù)進行,否則進入下一個流程。

      來自江蘇 回復
    4. 明白,怎么聯(lián)系,加你好友,交流一下

      來自廣東 回復
  2. 自然語言生成是靠什么實現(xiàn)的呀?會有對應的語料庫嗎?

    回復
    1. NLG也是需要根據機器人所覆蓋的領域儲備相應的語料庫,否則生成的內容就不可控了~
      但目前因NLG在實際對話生成過程中的應用瓶頸:采用神經網絡的高級NLG(更貼合人類自然語言)會出現(xiàn)不可控的風險,因此多數(shù)采用的仍然是模板化的NLG,除非是開放域的閑聊機器人~

      來自江蘇 回復
  3. 寫的真好,通俗易懂~

    來自北京 回復
    1. 感謝認同~ ??

      來自江蘇 回復