本指南提供設計所有類型代理程式的一般最佳做法。
您也應參閱語音代理程式設計指南，瞭解如何設計語音代理程式，以及參閱最佳做法指南，瞭解如何使用 Dialogflow CX 服務。
一般建議
疊代建構代理程式
如果您的代理程式龐大或複雜，建議一開始先建構只處理頂層要求的對話。 將基本結構建立完成後，即可進行對話路徑疊代作業，確保使用者可能會採行的所有路徑都已經涵蓋在內。
隨著代理程式不斷演進，建議使用測試案例功能進行測試驅動開發。
預先建構的代理
Dialogflow CX 提供代理程式範本，可協助您順利上手。 預先建構的代理程式適用於金融服務、電信和旅遊等常見用途。這些代理程式會納入意圖及實體，能因應最常見要求。 您可以根據業務新增路線和履行方式，快速建構有效運作的代理程式。
整合及連結服務
與 Dialogflow CX 代理程式整合的方法有很多種。本節提供選擇整合方式的最佳做法。
整合
Dialogflow CX 整合提供代理程式的即用型使用者介面。如果您使用整合服務，就不需要直接呼叫 Dialogflow CX API，因為整合服務會為您處理這項作業。這些整合項目可提供文字代理程式，方便您嵌入網站、連結其他訊息平台，或提供電話介面。
Dialogflow CX API
如果現成的整合功能都不適用，或您想自訂系統的介面，可以直接使用 Dialogflow CX API。採用這種做法時，您需要為代理程式實作使用者介面，或使用現有的使用者介面。
Webhook
除非代理程式完全由靜態資料定義，否則您必須使用網路鉤子連結服務，並提供可處理動態情境的代理程式。無論您是使用整合功能或 Dialogflow CX API，都適用這項規定。
服務專員資源
Dialogflow CX 虛擬服務專員資源有多種用途，可協助您達成所需結果。本節提供建議，協助您為合適的情境選擇合適的資源。
流程和頁面
流程和頁面可為虛擬服務專員提供結構。您可以將頁面視為狀態機中的節點，而流程則視為相關頁面的群組。您可以使用狀態處理常式控制節點之間的轉換，系統會在意圖相符、符合條件或叫用事件時呼叫這些處理常式。
簡單的代理程式可能適用於單一流程，但複雜的代理程式幾乎都適合採用多個流程設計。每個流程都應代表代理程式的高階主題，且與流程相關聯的每個頁面都有助於處理該主題。此外，每個流程都可以有自己的設定，且可由部分團隊成員擁有，有助於設計大型代理程式時分配工作。
設計大型複雜的代理程式時，請務必考量每個代理程式的流程數和每個流程的頁面數限制。這些限制有助於確保代理程式的效能。
如果每個代理程式的流程過多，請將相關主題合併為單一流程。舉例來說，您可以將下列主題合併為單一「取得餘額」流程：
- 查看支票帳戶餘額
- 取得儲蓄餘額
- 取得抵押貸款餘額
- 查看消費金餘額
如果每個流程的代理程式設計頁面過多，請合併相關頁面，並在每個頁面使用多個路徑。
如果仍難以處理流程和頁面限制，可能是因為您在代理程式本身中建構了過多的業務邏輯。建議將這項邏輯移至 Webhook。
以下列出代理程式資源的對話控制精細度，並依精細度遞增順序排列：
- 服務專員 (一位服務專員處理所有對話)
- 流程 (一個流程處理一或多個相關對話主題)
- 頁面 (一個頁面處理一或多個相關對話回合)
- 路徑 (一條路徑處理一項使用者意圖或條件檢查)
意圖參數與表單參數
系統從使用者取得結構化資料的主要方式是透過參數。 您可以為意圖 (意圖參數) 或頁面 (表單參數) 使用參數。
部分網頁的主要目的是向使用者收集特定資訊。例如，網頁可能設計為收集使用者的聯絡資訊。在這種情況下，您應一律使用表單參數收集這項資訊。
在某些情況下，您可能想在從一個網頁轉換到另一個網頁時，擷取使用者資訊。舉例來說，如果使用者在對話開始時要求特定產品，您希望在轉移至適當的訂購頁面時擷取所需產品。在這種情況下，請將意圖參數做為意圖路徑的一部分。
在某些情況下，同時使用意圖參數和表單參數是理想做法。舉例來說，如果使用者在對話開始時要求購買小號襯衫，您希望在轉移至襯衫訂購頁面時，擷取所需尺寸參數 (小號)。襯衫訂購頁面可能會要求提供額外資訊，例如所需顏色。襯衫訂購頁面應包含尺寸和顏色表單參數。 在本範例中，系統已提供尺寸參數並傳播，因此代理程式只會要求提供顏色。不過，其他對話可能遵循不同路徑，也就是在襯衫訂購頁面啟動時，使用者尚未提供所需尺寸。以這兩種方式定義參數，可讓代理程式更靈活地擷取資訊。
路徑和路徑群組
如要在比對到意圖或符合條件時，轉換至其他頁面、將回覆訊息加入佇列或呼叫 Webhook，請使用路徑。
如果您發現自己在多個網頁上使用同一組路徑，請使用路徑群組。這樣可避免代理程式設計中出現不必要的重複內容。
重複使用意圖
如果您發現自己定義多個意圖時，使用了類似的訓練詞組，請考慮在多個頁面中重複使用意圖。理想情況下，您應該定義一些用於多個網頁的一般用途意圖，以及一些僅用於單一網頁的特定意圖。這樣可避免代理程式設計中出現不必要的重複內容。
舉例來說，確認意圖通常最適合定義為可重複使用的意圖。confirmation.yes 意圖的訓練詞組可能如下：
- 是
- yeah
- 沒錯
- 確定
- 是的
- 沒錯
- 當然
- 好，謝謝
confirmation.no 意圖的訓練詞組可能如下：
- 否
- 不對啦
- 否
- 不可能
- 不適合我
- 絕對不會
- 不用了，謝謝
這些可重複使用的確認意圖可用於代理程式的許多情境。
在某些情況下，您也應考慮建立專門的確認意圖。舉例來說，確認訂單時，您可能需要使用專門的order.confirmation.yes意圖，並提供下列訓練詞組：
- the order looks good to me
- 我接受這項訂單
以及含有下列訓練詞組的專屬order.confirmation.no意圖：
- 我不要這筆訂單
- 我拒絕接受這項訂單
訂單確認頁面啟用後，這四種意圖的所有意圖路徑都應在範圍內。 確保系統能適當處理使用者的一般或特定確認。
預設負面意圖
您應使用使用者可能會說的詞組填入預設否定意圖，但這些詞組不應與代理程式中的任何意圖相符。
Fulfillment
您可以使用完成功能，以多種方式回覆使用者。在對話回合中，代理程式可以將多則訊息附加至回應佇列，並在對話回合結束時，將串連的佇列傳送給使用者。本節說明建立個別訊息的各項選項。
- 頁面項目完成：
頁面最初處於有效狀態時，系統會呼叫這項完成作業。
如果您想在網頁處於啟用狀態時，只說一次說明網頁用途的訊息，這項功能就非常實用。例如：
- 你想瞭解支票帳戶的哪些資訊？
- 你想購買哪種產品？
- 請提供要訂購的襯衫相關資訊。
- 路徑：
當呼叫意圖路徑或附帶條件的路徑時，就會呼叫這項完成動作。
當您想向使用者傳送訊息，說明意圖相符、符合條件 (可能是表單填寫完成條件) 或轉換時，這項功能就非常實用。例如：
- 可以，你的國際方案包含日本。(意圖比對)
- 確定要購買 300 件襯衫嗎？(比較條件符合)
- 好的，預約時間是明天早上 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 | Borderline |
| 20 | 2000 | 是 |
實體使用次數和訓練詞組數量
針對意圖中使用的所有實體類型：
- 為實體類型的每個範例加上註解。
- 請為每個實體類型提供至少五個訓練詞組，其中包含註解範例。
- 訓練詞組的數量應至少是實體類型的三倍。 舉例來說，如果您在某個意圖中使用 10 種不同的實體類型進行註解，則應至少有 30 個訓練詞組。
訓練詞組應自然
訓練詞組應自然且貼近對話， 與使用者實際說出的內容相符。 盡可能使用生產環境中發生的使用者輸入內容做為訓練資料，並特別留意最常見的輸入內容。
訓練詞組必須各不相同
盡量納入各種形式的問題、指令、動詞和常見名詞的同義詞，確保詞組涵蓋的範圍足以應付可能的要求。
建議加入「繳納帳單」等較短的詞組，以及「我剛收到郵件，內容提到我需要支付月結單餘額」等較長的詞組和句子。我們不會建議短句和長句的比例，但您應根據傳送至正式版代理程式的實際使用者輸入內容來決定。
定義長度、措辭和句型各異的訓練詞組，對確保代理程式訓練品質至關重要。不一定要為了多樣性而增加多樣性，但必須提供足夠的多樣性，讓 NLU 模型能從各種使用者輸入內容中，成功偵測使用者的意圖。如果變化不足，可能會導致過度擬合。換句話說，模型可能會過度配合您提供的特定範例，無法充分推論到其他範例。
大小寫變化
大小寫的敏感度會因代理程式使用的NLU 模型而異。
標準 NLU
標準 NLU 模型不區分大小寫，在極少數情況下，您可能需要新增只有大小寫不同的訓練詞組。這通常適用於您希望使用者提供全大寫文字輸入內容的情況。
替代做法包括：
- 調低機器學習分類門檻
- 在將使用者輸入內容傳送至 Dialogflow CX 前，先將內容轉換為小寫。
進階 NLU
進階 NLU 模型會區分大小寫，這與標準 NLU 模型不同。建議您測試並加入相關的大寫訓練資料，提高意圖相符率。
不必要的訓練詞組變化
避免訓練詞組出現微不足道的變化，因為這會向 NLU 模型提供重複資訊。舉例來說，請勿加入僅因下列因素而有所差異的子類：
- 大寫：如果使用標準 NLU 模型，請避免重複的片語，例如「訂票」和「訂票」，除非極少數情況。不過，進階 NLU 模型會區分大小寫，且需要更多訓練詞組，才能提高意圖比對率。詳情請參閱「 大小寫變體」一節。
- 贅字： 例如「好，訂票」和「訂票」。
- 標點符號： 例如：「可以幫忙嗎？」和「可以幫忙嗎！？」
註解一致性
針對註解所選取的訓練詞組部分應包括符合實體所需的所有文字 (請勿超過所需的長度)。此外，請確保整個意圖的訓練詞組中，相似部分都已加上註解。
舉例來說，下表顯示使用 @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 中使用漫遊服務」。
請勿為動作和方案都建立實體類型，例如：
| 動作實體類型 | 方案實體類型 |
|---|---|
| 「How can I make an international call」(如何撥打國際電話) | 「方案 A」 |
| 「使用國際數據漫遊」 | 「Plan B」 |
相反地，您應該使用訓練詞組和意圖比對來擷取動作和實體來擷取計畫。
使用規則運算式實體擷取非單字 ID
擷取涉及非單字 ID 的使用者輸入內容時，應使用正則運算式實體。舉例來說，如要擷取「AA-256」或「AC-436」等產品 ID，請使用「[A-Z]{2}-\d{3}」等 Regexp 實體。
請勿套疊複合式實體
在複合式實體中，請勿使用超過一層的巢狀結構。 巢狀結構的每一層都會大幅降低品質。
避免類似意圖
每個意圖都應擷取使用者的意圖。 如果您使用類似的訓練詞組定義不同的意圖，比對結果可能不可靠，因為 NLU 模型無法充分確信要比對哪個意圖。
如果兩個訓練詞組代表相同意圖，則應屬於相同意圖。舉例來說，「變更目前帳單的到期日」和「延長付款期限」都應屬於同一意圖，因為兩者都是要求變更到期日。不過，「使用方案 A 要怎麼撥打國際電話？」和「在方案 A 中使用漫遊服務」可能屬於不同意圖，因為使用者在每種情況下想達成的目標不同。
避免使用類似的實體類型
請避免定義多個具有類似實體項目的實體類型，因為這可能會導致 NLU 模型產生模糊不清的結果。
在正式環境中使用不相符事件，改善意圖
在實際運作環境中執行代理程式時，部分使用者輸入內容難免會導致不相符事件。您可以透過以下三種方式，運用這些機會來改善代理程式：
- 將使用者輸入內容新增為所需意圖的訓練詞組。 不過，這不一定是最佳選擇。 如果對意圖執行這項操作多次，可能會導致意圖偏誤。
- 清理所需意圖的訓練詞組，確保所有詞組都能準確反映意圖。在某些情況下，訓練詞組差異過大的意圖可能會導致意圖無法比對。
- 如果意圖不應與使用者輸入內容相符，但訓練詞組可能與使用者輸入內容相符，請刪除這些訓練詞組。
避免使用特殊字元
訓練詞組中的特殊字元 ({、_、#、[ 等) 會遭到忽略。但表情符號是例外，可正常運作。
避免使用贅字
填充字詞是指可以忽略，但仍能理解文字內容的字詞。例如：
- 請
- 可以請你
- 嗯
- 如何？
在訓練詞組中使用填充詞並無必要，但不會造成任何影響，因為 NLU 模型會忽略這些詞彙。不過，您不應定義僅因填充字詞而異的訓練詞組。
請勿定義由填充字詞組成的實體。
測試機器學習設定
您可以透過ML 設定調整使用者輸入內容的處理方式。在大多數情況下，預設設定都能正常運作。不過，您可能需要微調設定，以提升代理程式效能。
回覆使用者
本節提供使用執行要求回應使用者的準則。
歡迎使用者
新建立的代理程式會自動建立歡迎意圖的意圖路徑。您應編輯這條路徑，加入歡迎使用者的完成訊息。這則訊息應說明代理程式，讓使用者瞭解代理程式的功能。
確認使用者資訊
在回覆中重複使用者提供的資訊，通常是最好的做法。讓使用者知道代理程式瞭解他們的要求。
如果系統比對出相符的意圖並發生轉移，請讓使用者知道對話會根據他們的要求繼續進行。例如：
| 對話 | 說明 |
|---|---|
| 使用者：我對支票帳戶有疑問。 代理程式：好的，請問您想瞭解支票帳戶的哪些資訊？ |
使用者輸入的內容與意圖相符，因此系統按照路徑傳送了完成訊息，並轉移至處理支票帳戶問題的頁面。請注意，代理程式會確認使用者想瞭解支票帳戶資訊。 |
填寫完畢後，請重複使用者提供的資料。例如：
| 對話 | 說明 |
|---|---|
| 消費者：明天 服務人員：好的，已為你預約明天晚上 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 錯誤頁面。
工具
本節提供使用工具改善代理程式設計的建議。
使用驗證工具
請務必使用驗證工具檢查代理程式。這項工具會找出本指南所述的部分問題。
使用測試案例功能
您應一律為代理程式定義測試案例。這些測試案例有助於防止迴歸，同時讓代理程式演進，以處理更多情境。