案例

案例將告訴機器人Closed 代替真人客服專員處理客戶互動的軟體應用程式。在互動的背景下如何回覆訊息Closed 聯絡人在與機器人互動時表達的任何內容,無論是問題還是陳述,以文字形式還是話語形式。。 當訊息的上下文很重要時,請使用案例。 這有助於機器人學習如何根據聯絡人之前傳送的訊息預測正確的回應。

另一種配置機器人回應的方法是建立規則。 規則適用於每次回應都相同,且上下文無關的訊息。 當上下文對了解聯絡人的需求很重要時,請使用案例。 如果上下文無關緊要,而且聯絡人的訊息一直都是相同的意思,請使用規則。

例如,如果聯絡人說「您的工作時間是多少」,機器人可能不需要任何上下文,您可以使用規則。 但如果聯絡人說「我要怎麼做」,機器人就需要了解訊息的上下文。 交流中聯絡人先前問的問題會幫助機器人了解如何進行適當地回應,因此您應該使用案例。

滿意、不滿意和範圍外路徑

在計劃案例時,以路徑的方式思考很有幫助:

  • 快樂路徑:訓練快樂路徑的案例描述聯絡人按照您所期望的交流流程進行。 聯絡人總是在提示時提供預期的資訊和回覆。 在快樂路徑中沒有發生異常情況。
  • 不快樂路徑:不快樂路徑描述聯絡人偏離「指令碼」的情況,並插入意料之外的問題、評論、閒聊或其他類型的中斷。
  • 範圍外路徑:範圍外路徑的案例教您的機器人如何處理聯絡人的要求超出機器人能力範圍的情況。

針對所有的意圖,為滿意和不快樂路徑設計案例非常重要。 快樂路徑可確保機器人知道如何針對每個意圖完成作業。 不快樂路徑確保機器人不會因意外而偏離方向。 有時候,機器人仍無法確保如何正確地預測回應,而必須遵循範圍外路徑。 但是,透過訓練大量不快樂路徑,可以幫助機器人學習讓對話回到正軌的方法。

範圍外路徑

範圍外路徑不同於遞補。 遞補用於機器人在沒有足夠信心執行指定動作或意圖的情況。 當聯絡人要求您的機器人做它未受過訓練的事情時,範圍外路徑就很有用。 您可以為這些請求建立範圍外意圖以便機器人識別它們。 然後,您可以使用案例中的意圖來教導機器人如何回應這些請求。

例如,聯絡人可能會經常要求您的機器人更新他們的帳號資訊,但您的機器人尚未設定為可執行此動作。 您可以建立 accountUpdates 意圖,提供訓練範例,並配置機器人的回應為「對不起,我還不知道該怎麼做。 我可以幫您處理 [任務],或將您轉接至人工客服專員來協助您處理帳戶」。

案例與上下文切換

當對話需要多個輪次時,案例對訓練機器人處理上下文轉換很有用。 下面的範例顯示聯絡人改變主意並先後說出兩個意圖的交流:

聯絡人:嗨,我想支付我的發票。

機器人:當然,沒問題。 您的發票號碼是什麼?

聯絡人:其實我想轉帳。

機器人:當然可以。 您想轉帳到哪個帳戶?

聯絡人:從儲蓄帳戶轉帳 $200 到支票帳戶。

機器人:沒問題。 您的轉帳已完成。 我已從您的儲蓄帳戶轉帳 $200 到您的支票帳戶。

機器人:現在要繼續支付發票嗎?

使用不快樂路徑,您可以訓練您的機器人處理聯絡人沒有以預期方式回答的情況。

對於某些類型的上下文切換,規則Closed 用於定義機器人對訊息回覆,不隨內容變化。可能更適合。 有時聯絡人可能會插入單個不相干的訊息。 如果訊息是機器人可以在一個輪次內回應,然後再回到之前的意圖,您可以使用規則。 以下對話範例顯示聯絡人插入詢問天氣的交流:

聯絡人:嗨,我想支付我的發票。

機器人:當然,沒問題。 您的發票號碼是什麼?

聯絡人:您所在地的天氣如何?

機器人:外面陽光明媚。

聯絡人:真幸運! 哦,我的發票號碼是 123456。

機器人:謝謝,您要如何為此發票付款?

聯絡人關於天氣的問題很容易使用規則來處理。 機器人的回應可以每次都一樣。

檢查點

檢查點是一個機器人動作您可以將其指派給案例中的機器人回應。 它們允許您將案例分割成較小的子任務,並將相關部分連結起來,從而簡化案例。 這在聯絡人可能會提出多個後續問題的情況下很有幫助。 您可以為對話的每個部分建立較小的案例,而不是根據聯絡人提出的後續問題,為每個情境從頭到尾建立一個完整的案例。

您還可以使用不基於客戶訊息的檢查點。 例如,您的公司可能希望向所有客戶提供限時特別優惠。 您可以將特別優惠訊息和動作新增到每個機器人案例中,然後在優惠到期時從多個案例中移除該部分。 更簡單的方法是為特別優惠建立一個案例,然後在優惠期間為每個案例新增一個檢查點。

如圖所示,檢查點總是在開頭顯示一個帶有彎曲箭頭的藍色小圓圈。 這表明該優惠已關聯到一個或多個其他案例。 檢查點總是會結束案例,即使您在檢查點之後新增了動作。

許多聯絡人都在詢問 Classics, Inc 機器人關於 Classics, Inc. 帳號的問題,所以 Akela Wolfe 在她的機器人中新增一個意圖來處理這些問題。 聯絡人常問關於帳戶的幾個問題。 Akela 決定使用檢查點來處理這些問題。

她為 explain_account 意圖建立主要案例:

聯絡人:您好,什麼是 Classics, Inc 帳戶?

機器人:你好。 Classics, Inc. 帳戶可讓您存取從 Classics, Inc. 購買的所有電子書。

她也為三個常見的後續問題建立了案例:

  • 您能告訴我更多關於帳戶好處的資訊嗎?
  • 如何建立帳戶?
  • 是必須付費還是免費?

Akela 返回案例的 explain_account 意圖。 在最後,她新增了連結到後續問題案例的檢查點。

案例計劃最佳做法

計劃您的案例時,請遵循這些最佳做法:

  • 當上下文很重要時,請使用案例。 即使對話只涉及機器人與聯絡人之間的一輪對話,如果機器人需要上下文來了解如何回應,請使用案例。 例如,如果您有 lookup_balance 的意圖,但有些聯絡人想要查詢支票帳戶的餘額,有些則想要了解儲蓄帳戶的餘額,您可以建立一個案例來幫助您的機器人學習根據使用者指定的帳戶來正確回應。
  • 使用案例來幫助您的機器人學習預測。 謹慎選擇每個案例的主題。 確保其設計用於幫助機器人學習正確預測對機器人之前未遇到過的對話的回覆。
  • 案例需要來自實際對話。 不要編造您認為可能發生的案例。 使用真實互動資訊來建立案例。
  • 所設計的案例可以遵循快樂Closed 為意圖產生了正確結果的案例路徑或不快樂路徑Closed 為意圖產生了錯誤結果的案例

  • 使用案例來處理上下文切換。 這有助於您的機器人學習在兩個對話流程之間切換,或處理需要一個以上的對話回合才能回應的中斷。 如果中斷只需要一次回應,而且不依賴上下文,規則可能比較適合。
  • 某些意圖需要多個案例。 根據聯絡人的獨特情況和需求,如果對話有多種可能走向,請為同一意圖建立多個案例。

    • 不要在同一案例中包含多種對話流。 這可能會讓機器人產生混淆。
    • 如果有聯絡人可能會用不同的方式來表達訊息,或是意思基本相同的類似訊息,您可以將其新增為聯絡人訊息意圖的範例。

    從快樂與不快樂的路徑思考。 每個意圖可以有一個以上的快樂路徑和一個以上的不快樂路徑。

  • 為您的範圍外意圖建立案例。 這可讓您訓練您的機器人,讓其掌握聯絡人提出範圍外資訊的較常見方式。
  • 按需包含聯絡人之間的來回訊息。 案例和規則不應該是完整的對話。 當對話中的下一個陳述必然會開始一個新的意圖時,就應停止並建立一個新的案例。
  • 將您的案例分割成符合邏輯的子任務。 經常趨向於建立一個從頭到尾包含整個對話的長案例。 但是,這實際上會增加您需要的案例數量。 相反,將您的案例分割成符合邏輯的子任務。 如果您有一些非常密切關聯的子任務,您可以用檢查點連結這些子任務。
  • 不要過度使用檢查點。 檢查點可以簡化您的訓練資料。 太多檢查點會讓您的案例難以理解,而且實際上會減慢您的機器人訓練速度。