本指南提供設計各種代理的一般最佳做法。
您也應該查看語音代理設計指南，瞭解如何設計語音代理，以及最佳做法指南，瞭解如何使用 Dialogflow CX 服務。
一般建議
疊代建構代理程式
如果您的代理程式龐大或複雜，建議一開始先建構只處理頂層要求的對話。 建立基本結構後，請疊代對話路徑，確保涵蓋使用者可能採取的各種路徑。
隨著代理不斷演進，建議您使用測試案例功能，進行測試導向開發。
預先建構的代理
Dialogflow CX 提供代理範本，協助您快速上手。預先建構的代理涵蓋金融服務、電信和旅遊等常見用途。這些代理程式會納入意圖及實體，能因應最常見要求。 新增貴商家專屬的路由和執行要求，即可快速建構功能正常的代理。
整合及連結服務
您可以透過多種方式與 Dialogflow CX 代理整合。本節提供選擇整合方式的最佳做法。
整合
Dialogflow CX 整合功能為代理提供立即可用的使用者介面。如果使用整合功能，就不需要直接呼叫 Dialogflow CX API，因為整合功能會為您處理這項作業。這些整合項目可提供文字代理，您可以嵌入網站、連結其他訊息平台，或提供電話介面。
Dialogflow CX API
如果沒有適合的現成整合項目，或您想自訂系統介面，可以直接使用 Dialogflow CX API。如果採用這種方法，您必須為代理實作使用者介面，或使用現有的使用者介面。
Webhook
除非代理可以完全由靜態資料定義，否則您需要使用 Webhook 連結服務，並提供可處理動態情境的代理。無論您是使用整合功能或 Dialogflow CX API，都適用這項規定。
代理資源
Dialogflow CX 代理資源有多種用途，可協助您達成預期結果。本節提供建議，協助您根據情境選擇合適的資源。
流程和頁面
流程和頁面可為代理提供結構。您可以將頁面視為狀態機中的節點，並將流程視為相關頁面的群組。您可以使用狀態處理常式控制節點之間的轉換，當意圖相符、符合條件或叫用事件時，系統就會呼叫狀態處理常式。
簡單的代理可能只需要一個流程，但複雜的代理通常需要多個流程。每個流程都應代表代理的高階主題，而與流程相關聯的每個頁面都有助於處理該主題。此外，每個流程都可以有自己的設定，並由部分團隊成員擁有，有助於在設計大型代理時分工。
設計大型複雜的代理時，請務必考量「每個代理的流程數量」和「每個流程的頁面數量」限制。這些限制有助於維持代理效能。
如果代理設計中每個代理的流程過多，請將相關主題合併到單一流程中。舉例來說，您可以將下列主題合併為單一「取得餘額」流程：
- 取得支票帳戶餘額
- 取得節省餘額
- 取得房貸餘額
- 取得抵免餘額
如果代理設計的每個流程有太多頁面，請合併相關頁面，並在每個頁面使用多個路徑。
如果流程和頁面數量仍超過限制，可能是因為代理本身內建過多商業邏輯。建議將這項邏輯移至 Webhook。
以下列出代理資源的對話控制精細程度，依精細程度遞增排序：
- 代理 (一個代理處理所有對話)
- 流程 (一個流程可處理一或多個相關對話主題)
- 頁面 (一個頁面可處理一或多個相關對話回合)
- 路由 (一個路由處理一個使用者意圖或條件檢查)
意圖參數與表單參數
系統從使用者取得結構化資料的主要方式是透過參數。您可以將參數用於意圖 (意圖參數) 或頁面 (表單參數)。
某些頁面的主要目的是向使用者收集特定資訊。例如，某個頁面可能設計用來收集使用者的聯絡資訊。在這種情況下，請一律使用表單參數收集這項資訊。
在某些情況下，您可能需要在從一個頁面轉換到另一個頁面時，擷取使用者資訊。舉例來說，如果使用者在對話開始時要求特定產品，您會希望在轉換至適當訂購頁面的同時，擷取所需產品。在這種情況下，請將意圖參數做為意圖路徑的一部分。
在某些情況下，同時使用意圖參數和表單參數是理想的做法。舉例來說，如果使用者在對話開始時要求小號襯衫，您會希望在轉換至襯衫訂購頁面時，擷取所需的大小參數 (小號)。T 恤訂購頁面可能會要求提供其他資訊，例如想要的顏色。襯衫訂購頁面應有尺寸和顏色的表單參數。 在這個範例中，系統已提供大小參數並傳播，因此代理只會要求顏色。不過，其他對話可能會遵循不同的路徑，例如在襯衫訂購頁面啟用時，使用者尚未提供所需尺寸。透過這兩種方式定義這項參數，代理就能更靈活地擷取資訊。
路由和路由群組
如要在意圖相符或符合條件時，轉換至其他頁面、將回覆訊息排入佇列，或呼叫 Webhook，請使用路徑。
如果您發現自己在多個頁面使用同一組路由，請使用路由群組。這樣可以避免代理設計中出現不必要的重複內容。
重複使用意圖
如果發現自己定義的多個意圖具有相似的訓練詞組，請考慮在多個頁面中重複使用意圖。理想情況下，您應該定義一些用於多個頁面的一般用途意圖，以及一些僅用於單一頁面的特定意圖。這樣可以避免代理設計中出現不必要的重複內容。
舉例來說，確認意圖通常最適合定義為可重複使用的意圖。confirmation.yes 意圖可能包含以下訓練詞組：
- 是
- yeah
- 沒錯
- 確定
- 是，我有
- 當然
- 絕對
- 好，謝謝
confirmation.no 意圖可能包含以下訓練詞組：
- 否
- 不
- 不
- 不可能
- 不適合我
- 絕對不是
- 不用了，謝謝
這些可重複使用的確認意圖，能用於代理的多種情境。
在某些情況下，您也應考慮建立專門的確認意圖。舉例來說，確認訂單時，您可能需要一個專門的 order.confirmation.yes 意圖，並使用下列訓練詞組：
- 這個順序沒問題
- 我接受這筆訂單
以及專門的 order.confirmation.no 意圖，訓練詞組如下：
- 我不需要這筆訂單
- 我不接受這筆訂單
訂單確認頁面啟用時，這四個意圖的意圖路徑都應在範圍內。這樣一來，無論使用者提供一般或具體確認，系統都能妥善處理。
預設負面意圖
您應在預設排除意圖中填入使用者可能會說，但不應與代理中任何意圖相符的詞組。
Fulfillment
您可以使用多種執行要求選項來回覆使用者。在對話回合中，代理可以將多則訊息附加至回覆佇列，並在對話回合結束時，將串連的佇列傳送給使用者。本節說明建立個別訊息的各個選項。
- 頁面進入點執行要求：頁面首次啟用時，系統會呼叫這個執行要求。如果想用訊息說明頁面用途，且在頁面啟用時只說一次，這個屬性就非常實用。例如：
- 你想知道支票存款帳戶的哪些資訊？
- 您想購買哪種類型的產品？
- 我需要收集一些關於你要訂購的襯衫的資訊。
- 路徑：呼叫意圖路徑或條件路徑時，系統會呼叫這個執行要求。如果想針對意圖比對、符合條件 (可能是表單填寫完成條件) 或轉換，向使用者傳送訊息，這項功能就非常實用。例如：
- 是的，你的國際方案包含日本。(意圖比對)
- Are you sure you would like to purchase 300 shirts? (符合比較條件)
- 好的，預約時間是明天早上 7 點。 (完成填寫表單)
- 好的，現在來談談土豚。(轉場)
- 事件處理常式：叫用事件時，系統會呼叫這個執行要求。如果想在事件發生時顯示訊息，這個方法就很實用。例如：
- 你考慮購買的股票價值剛上漲了 10%。(自訂事件)
- 可以換個方式說嗎？ (不相符事件)
- 表單的初始提示：代理執行表單填寫時，會呼叫這個執行要求。這些訊息應向使用者提出特定問題。每個表單參數都有自己的初始提示執行。例如：
- 您需要什麼尺寸的襯衫？
- 您想要什麼顏色的襯衫？
- 表單的重新提示處理常式：當代理執行表單填寫，且不瞭解使用者對目前參數的選取時，系統會呼叫這個執行要求。只有在您希望重新提示訊息與初始提示訊息不同時，才需要執行這項要求。如果沒有再次提示處理常式，代理程式會直接使用初始提示做為再次提示訊息。例如：
- 我不懂你的意思。請提供有效的襯衫顏色。
命名
本節提供命名代理資源的建議。
意圖命名
如果代理程式有許多意圖，建議您採用命名配置，以便整理。意圖名稱通常會以標點符號分隔，具體程度由左至右遞增。此外，意圖名稱應反映使用者在一輪對話中的意圖。
命名方案有很多種，以下舉例說明：
- phone-service.order.cancel
- phone-service.order.create
- phone-service.order.change
- tv-service.order.cancel
- tv-service.order.create
- tv-service.order.change
- account.balance.get
- account.balance.pay
- account.address.get
- account.address.update
轉換
狀態處理常式中定義的轉換可變更有效頁面，進而控管對話。本節提供整理代理轉換的建議。
免費轉換
定義觸發轉場效果的路徑時，請考量可能會有互補或反向路徑。
例如：
- 如果您有 confirmation.yes 的意圖路徑，請考慮為 confirmation.no 定義另一個路徑。
- 如果您使用布林值
=運算子定義條件路徑，請考慮定義另一個使用!=的路徑。
處理使用者輸入內容
本節提供意圖和訓練詞組的指南，讓代理能以最佳方式處理使用者輸入內容。
定義至少 20 個訓練詞組
每個意圖至少應有 20 個訓練詞組。否則，NLU 模型可能沒有足夠的資訊來適當比對意圖。這是最基本的準則。 理想情況下，您應該定義更多語句，尤其是大型代理的主要意圖，建議數量約為 50 個。
留意意圖偏誤
若一或多個意圖的訓練詞組數量遠多於其他意圖，會導致資料不平衡，使 NLU 模型過度偏向數量較大的意圖。當訓練詞組的數量差異達一個數量級以上，就可能發生意圖偏誤。
在某些情況下，這是預期的行為，因為您可能會定義某些應較常比對相符的意圖，因為這類訓練詞組會對應到較常出現在實際流量中的使用者輸入內容。
在其他情況下，這種行為可能不理想，因為您不希望過度偏向數量較大的意圖。若是如此，請減少較大型意圖的訓練詞組數量，維持與其他意圖相同的規模。例如：
| 意圖 A 訓練詞組 | 意圖 B 訓練詞組 | 意圖 B 的偏誤 |
|---|---|---|
| 20 | 50 | 否 |
| 20 | 200 | 可能有營業 |
| 20 | 2000 | 是 |
實體使用和訓練詞組數量
針對意圖中使用的所有實體類型：
- 為實體類型的每個範例加上註解。
- 請為每個實體類型提供至少五個訓練詞組，其中包含已加上註解的範例。
- 訓練詞組數量至少應為實體類型的三倍。舉例來說，如果您在意圖中使用 10 種不同的實體類型進行註解，則至少應有 30 個訓練詞組。
訓練詞組應自然
訓練詞組應自然且符合對話情境，與使用者實際說的話一致。請盡可能使用實際工作環境中發生的使用者輸入內容做為訓練資料，並特別注意最常見的輸入內容。
訓練詞組必須多樣化
請加入各種問題、指令、動詞和常見名詞的同義詞，確保詞組涵蓋各種可能的要求。
最好同時加入「繳帳單」等較短的詞組，以及「我剛收到郵件，說我需要支付對帳單餘額」等較長的詞組和句子。詞組並沒有建議的長短，應取決於實際使用者在正式環境中，傳送給代理的輸入內容。
定義長度、措辭和句型結構各異的訓練詞組，是確保代理訓練成效良好的關鍵。您不必為了多樣化而多樣化，但必須提供足夠的多樣性，NLU 模型才能成功從各種使用者輸入內容中偵測使用者的意圖。如果資料不夠多元，可能會發生過度配適。換句話說，模型可能會過度依賴您提供的特定範例，無法充分推論其他範例。
大小寫變化
是否區分大小寫，取決於代理使用的 NLU 模型。
標準 NLU
標準 NLU 模型不區分大小寫。在極少數情況下，您可能需要新增只有大小寫不同的訓練詞組。這通常適用於您預期使用者會提供全大寫文字輸入的情況。
替代做法包括：
- 調低機器學習分類門檻
- 將使用者輸入內容轉換為小寫，再傳送至 Dialogflow CX。
進階 NLU
與標準 NLU 模型不同，進階 NLU 模型會區分大小寫。建議您測試並新增相關的大寫訓練資料，提高意圖媒合率。
不必要的訓練詞組變化
請避免在訓練詞組中加入不重要的變化版本，因為這會為 NLU 模型提供重複資訊。舉例來說，請勿加入僅有下列差異的子類：
- 大寫：如果使用標準 NLU 模型，請避免使用重複的詞組，例如「Order a ticket」和「order a ticket」，除非是極少數情況。不過，進階 NLU 模型會區分大小寫，且需要更多訓練詞組，才能提高意圖比對率。詳情請參閱大小寫變化版本一節。
- 填充詞：例如「好，訂票」和「訂票」。
- 標點符號：例如「can you please help?」和「can you please help!?」
註解一致性
為註解選取的訓練詞組部分，應包含比對實體所需的所有文字，但切勿超過必要長度。此外，請確保整個意圖中訓練詞組的相似部分都有加上註解。
舉例來說，下表顯示使用 @sys.date 系統實體加上註解的正確和錯誤方式：
| 良好 | 不佳 |
|---|---|
| 9 月 7 日出發 | 9 月 7 日出發 |
| 7 月 4 日出發 | 7 月 4 日離開 |
為系統實體使用具有語意意義的註解
訓練詞組中其他文字，可能會影響選取註解的訓練詞組部分的語意。例如：
| 加上註解的訓練詞組 | 已加上註解的文字語意 |
|---|---|
| 我 7 歲 | 年齡 |
| 合約效期為 7 年 | 時間長度 |
Dialogflow CX 的機器學習模型在比對系統實體時，會考量語意。訓練詞組部分的語意必須與系統實體的預期語意相符。
舉例來說，請勿使用 @sys.duration 系統實體來標註上述第一個「7 年」範例。「7 年」的語意與簡單的時間長度不符。請改為選取「7」做為註解，並使用 @sys.number 系統實體。
定義意圖，處理不符合規定的表單填寫答案
建議您定義意圖，處理不符合規定的表單填寫答案。舉例來說，代理可能會詢問「您的旅遊日期是哪一天？」，使用者則回答「我還不知道」。這個答案不符合表單參數提示，但如果代理有範圍內的意圖路徑可比對這個答案，就能妥善處理這種情況。
避免使用 @sys.any
避免使用 @sys.any 系統實體類型。只有在您已用盡所有方法 (包括建構自訂實體) 後，才應使用這個方法。這個實體類型非常廣泛，可能會導致非預期的行為。
如果使用這個實體類型，請避免將單一訓練詞組的多個部分加上這個實體類型的註解，因為這會造成語意模糊，且代理行為會未定義。
搭配表單參數使用 @sys.any 較不危險，因為代理在提示表單參數時，會預期取得特定資訊。
註解應包含多種實體值
定義已加上註解的訓練詞組時，請在詞組中使用各種實體值範例。請勿一律使用相同的實體範例進行註解。以下範例顯示產品實體類型的良好和不良註解：
| 良好 | 不佳 |
|---|---|
| 我想買襯衫 | 我想買襯衫 |
| 訂購新帽子 | 訂購新襯衫 |
| 將手錶加入購物車 | 將襯衫加入購物車 |
自訂實體應包含多種變化版本
自訂實體應涵蓋多種範例。NLU 模型會提供各種文法形式，但您必須加入所有可能的項目。
避免使用過於積極比對的實體
請勿定義幾乎與任何內容都相符的實體。這會降低機器學習的效能和品質。系統會評估每個訓練詞組中的幾乎所有內容，判斷是否可能相符。
對應和清單實體應著重於不重複的值
對應和清單實體類型的範圍應有限，可擷取一種類型資訊的不同值。實體應簡短扼要，重點明確。
如果實體值很複雜，可能是因為意圖訓練詞組更適合您的情況。舉例來說，假設使用者輸入以下內容：
- 「如何使用方案 A 撥打國際電話？」
- 「使用方案 B 的國際漫遊服務。」
請勿同時為動作和計畫建立實體類型，例如：
| 動作實體類型 | 方案實體類型 |
|---|---|
| 「如何撥打國際電話」 | 「Plan A」 |
| 「使用國際漫遊服務」 | 「Plan B」 |
請改用訓練詞組和意圖比對來擷取動作，並使用實體來擷取方案。
使用規則運算式實體擷取非字詞 ID
擷取涉及非字詞 ID 的使用者輸入內容時，應使用規則運算式實體。舉例來說，如要擷取「AA-256」或「AC-436」等產品 ID，請使用「[A-Z]{2}-\d{3}」等規則運算式實體。
避免巢狀複合實體
複合實體中的巢狀結構不應超過一層。巢狀結構的每一層都會大幅降低品質。
避免類似意圖
每個意圖都應擷取使用者意圖。如果定義的不同意圖具有相似的訓練詞組，比對結果可能不穩定，因為 NLU 模型無法充分判斷要比對哪個意圖。
如果兩個訓練詞組代表相同意圖，則應屬於同一個意圖。舉例來說，「變更目前帳單到期日」和「延長付款時間」都屬於同一個意圖，因為兩者都是要求變更到期日。不過，「我可以用方案 A 撥打國際電話嗎？」和「我可以用方案 A 使用國際漫遊服務嗎？」可能屬於不同意圖，因為使用者在各個情況下想要的東西不同。
避免使用類似的實體類型
請避免定義多個實體項目相似的實體類型，以免 NLU 模型產生混淆。
在正式環境中使用無相符事件來改善意圖
在正式環境中執行代理時，部分使用者輸入內容難免會導致不相符事件。您可以透過下列三種方式之一，利用這些機會改善代理：
- 將使用者輸入內容新增為所需意圖的訓練詞組。不過，這不一定是最佳做法。如果多次對意圖執行這項操作，可能會導致意圖偏誤。
- 清理所需意圖的訓練詞組，確保所有詞組都能準確反映意圖。在某些情況下，如果意圖的訓練詞組不一致，可能會導致意圖無法比對。
- 如果意圖不應與使用者輸入內容相符，但訓練詞組可能與使用者輸入內容相符，請刪除這些訓練詞組。
避免使用特殊字元
系統會忽略訓練詞組中的特殊字元 ({、_、#、[ 等)。但表情符號是例外，會正常運作。
避免使用填充詞
填充詞是指即使忽略，也不會影響理解文字內容的字詞。例如：
- 請
- 可以請你
- 嗯
- how about
在訓練詞組中使用填充詞並非必要，但也不會造成影響，因為 NLU 模型會忽略這些詞。不過，請勿定義只有填充詞不同的訓練詞組。
請勿定義由填充詞組成的實體。
實驗機器學習設定
機器學習設定可用於調整使用者輸入內容的處理方式。在多數情況下，預設設定都能正常運作。不過，您可能需要微調設定，提升代理效能。
回覆使用者
本節提供使用執行要求回覆使用者的指南。
歡迎使用者
新建立的代理會自動建立歡迎意圖的意圖路徑。請編輯這條路徑，加入歡迎使用者的執行要求訊息。這則訊息應說明代理，並讓使用者瞭解其功能。
確認使用者資訊
最好的做法通常是在回覆中重複使用者提供的資訊。這能讓使用者知道代理理解他們的要求。
當意圖相符且發生轉換時，請讓使用者知道對話會根據他們的要求繼續進行。例如：
| 對話 | 說明 |
|---|---|
| 使用者：我對支票存款帳戶有疑問。 代理：好的，您想瞭解支票存款帳戶的哪些資訊？ |
使用者輸入內容與意圖相符，系統會按照路徑提供執行訊息，並轉移至處理支票存款帳戶問題的頁面。請注意，代理會確認使用者是否想瞭解支票存款帳戶。 |
填寫完表單後，請重複使用者提供的資料。例如：
| 對話 | 說明 |
|---|---|
| 使用者：明天 代理：好的，已為您預約明天晚上 7 點剪髮。還有什麼需要我幫忙的嗎？ |
使用者提供了日期表單參數，這是運作頁面上的最後一個表單參數。服務專員確認預約剪髮的時間和日期。 |
引導對話
代理應一律引導與使用者的對話。只要在每次回覆結尾加上類似以下的問題，就能輕鬆達成這個目標：
- 還有什麼需要我幫忙的嗎？
- 你想瞭解米格魯的什麼資訊？
- 要取消還是提交訂單？
- 今天需要什麼協助呢？
- 你是獨自旅行還是與他人同行？
定義這些問題時，請務必避免提出多個問題，例如：
- 你還在嗎？您想瞭解哪項服務？
- 你仍需要這筆訂單嗎？要新增任何內容嗎？
使用者可能只回答其中一個問題，而代理可能無法正確處理這種情況。
處理錯誤和未預期的使用者輸入內容
本節提供處理錯誤和非預期使用者輸入內容的建議。
為內建事件建立事件處理常式
請視需要為內建事件建立事件處理常式。處理這些事件的方式，類似於在軟體程式設計中擷取例外狀況。視情況而定，您可能需要使用參數專屬、特定網頁或流程專屬的事件處理常式來處理事件。
處理 Webhook 錯誤
當 Webhook 服務失敗時，代理應能妥善處理失敗。如要達到這個目的，請為 Webhook 專用的內建事件定義事件處理常式。以下是處理 Webhook 錯誤的建議做法：
- 請勿從觸發 Webhook 呼叫的狀態處理常式提供轉換目標，否則系統不會叫用 Webhook 錯誤事件處理常式。請改為在 Webhook 服務的 Webhook 回應中設定轉換目標。
選擇可將錯誤計數器初始化為零的頁面。這個頁面必須在觸發 Webhook 呼叫的頁面之前啟用。這個頁面的項目執行作業應使用執行作業參數預設值，將錯誤計數器初始化為
0。例如：參數 值 webhook-error-count0建立 Webhook 錯誤頁面，用於處理 Webhook 錯誤事件：
進入執行作業應向使用者確認失敗，並使用執行作業參數預設值，遞增錯誤計數器工作階段參數。例如：
參數 值 webhook-error-count$sys.func.ADD($session.params.webhook-error-count, 1)定義條件路徑，其中條件為錯誤計數小於允許的最大值。(例如
$session.params.webhook-error-count <= 3)。這個路徑應有執行要求，通知使用者代理會重試。這個路徑的轉換目標應設為 PREVIOUS_PAGE，或任何可再次嘗試呼叫 Webhook 的頁面。定義條件路徑，其中包含錯誤計數大於允許上限 (例如
$session.params.webhook-error-count > 3) 的條件。這個路徑應有執行要求，通知使用者代理不會再重試。這個路徑應將轉換目標設為不會觸發 Webhook 重試的頁面。
Webhook 事件處理常式應有轉換目標，可轉換至 Webhook 錯誤頁面。
工具
本節提供使用工具改善代理設計的建議。
使用驗證工具
請務必使用驗證工具檢查服務專員。這項工具可找出本指南所述的部分問題。
使用測試案例功能
請務必為代理定義測試案例。這些測試案例可協助您在代理程式演進以處理更多情境時，防止迴歸。