本指南提供設計各種代理的一般最佳做法。
您也應參閱語音代理設計指南，瞭解如何設計語音代理，以及最佳做法指南，瞭解如何使用 Dialogflow 服務。
在建構代理程式之前
本節提供開始建構代理程式之前應注意的一些資訊。
目標
思考您代理程式的總體目標：
- 您的業務目標是什麼？
- 您的使用者對代理程式有什麼預期？
- 使用者與代理程式互動的頻率為何？
平台
考量使用者會如何存取您的代理程式。 在建立內容之前，請先查看 Dialogflow 支援的平台。 選擇要支援的平台時，請據此準備內容。 部分 Dialogflow 平台整合支援複合式訊息，也就是可納入圖片、連結及建議內容方塊等元素。
疊代建構代理程式
如果您的代理程式龐大或複雜，建議一開始先建構只處理頂層要求的對話。 將基本結構建立完成後，即可進行對話路徑疊代作業，確保使用者可能會採行的所有路徑都已經涵蓋在內。
預先建構的代理
Dialogflow 提供預先建構的代理程式清單，可協助您順利上手。 預先建構的代理程式適用於訂房、導覽及線上購物等常見用途。 這些代理程式會納入意圖及實體，能因應最常見要求。 您可以根據業務新增特定回應，快速建構有效運作的代理程式。
系統實體
使用者提出要求時，從要求的內容中可以剖析一些重要資訊。 在 Dialogflow 中，這些重要資訊稱為「實體」。 而其中，「系統實體」是由 Dialogflow 提供的預先建構實體，能處理最常見的資訊類型。
Small Talk
開發對話方塊時，您可能也會想處理一些偏離主題的要求。 Dialogflow 提供稱為 Small Talk 的選用功能。 這項功能啟用時，您的代理程式即可回應使用者的一般對話、情緒反應以及與代理程式本身有關的問題。 無論您的品牌風格傾向休閒、商務或介於兩者之間，所有 Small Talk 回應都會根據品牌風格對不同的內容進行調整，確保提供良好的對話體驗。
代理程式設計最佳做法
本節列出最佳做法，協助您建構面面俱到、精準、效能高且實用的代理程式。
問候語及結語
| 最佳做法 | 說明 |
|---|---|
| 「歡迎意圖」應讓使用者瞭解代理程式的功能並達到品牌宣傳效果。 | 「歡迎意圖」應提示使用者代理程式可協助執行的 2 到 3 項工作；如有需要，可進一步簡短描述如何使用這些功能。 |
| 成功完成互動之後，代理程式應傳達恰當的離開訊息。 | 使用者在您的代理程式內完成一項工作後，代理程式應總結該次交易/工具，並傳達類似「下次見」的訊息。 |
機器學習和訓練
| 最佳做法 | 詳細資料 |
|---|---|
| 意圖應至少有 10 到 20 個訓練詞組 (視意圖複雜度而定)。 | 每個意圖應有的訓練詞組實際數量取決於代理的複雜程度，但建議至少要有 10 到 20 個 (視意圖複雜程度而定)。意圖中使用的參數越多，提供用來訓練機器學習模型的詞組數量也要增加。 |
| 訓練詞組應該各不相同。 | 盡量納入各種形式的問題、指令、動詞和常見名詞的同義詞，確保詞組涵蓋的範圍足以應付可能的要求。 |
| 註解應一致。 | |
| 為系統實體使用有語意意義的註解。 | 訓練詞組中其他部分的文字，可能會影響選取用於註解的訓練詞組部分的語意。例如：
舉例來說，請勿使用 @sys.duration 系統實體為上述第一個「7 年」範例加上註解。「7 年」的語意與單純的時間長度不符。請改用 @sys.age 系統實體。 |
| 自訂實體應涵蓋廣泛的範例。 | 實體是指項目清單。機器學習功能會處理文法形式的部分，但您必須納入所有可能的項目。此外，請查看定義同義詞選項，並納入一些變化類型。 |
| 儘可能減少為意圖停用機器學習。 | 對已停用機器學習的意圖來說，在訓練您的代理程式時不會使用訓練詞組。使用者查詢與意圖中的訓練詞組非常相似，但該意圖的機器學習已停用時，此時如果其他有啟用機器學習的意圖與這個使用者查詢有點類似時，可能會與錯誤的意圖配對。如果您遇到誤判問題，請提高機器學習分類門檻，而非停用機器學習。 |
| 對於只有少數訓練資料的代理程式，請勿設定偏高的機器學習分類門檻。 | 如果門檻偏高，而訓練資料數量不大時，只有接近完全符合訓練詞組的使用者查詢才能產生意圖配對效果。如果您想使用偏高的門檻，則必須提供大量的訓練資料。 |
| 代理程式應有備用意圖。 | 如果沒有備用意圖，不相符的使用者查詢可能導致回應空白。 |
| 代理程式應提供負例。 | 負例可防止使用者查詢與訓練詞組有點類似時，就意外與意圖配對。 |
| 請勿定義幾乎與什麼都相符的實體。 | 這樣會降低機器學習的成效和品質。在每個訓練詞組中，近乎全部就等於可能相符。建議您改用 @sys.any。同樣，複合實體不應包含單一 @sys.any 作為同義詞。 |
| 請勿定義由填充字詞或無意義文字組成的實體。 | 填充字詞和無意義文字的例子有：「嗯」、「我看看」、「請」、「能否麻煩你」。如果您試圖使用這樣的實體來使實體豐富多樣，只會降低機器學習的成效。Dialogflow 早已擴增資料來處理這類情況的多樣性。對於這類的詞組，您應該加到訓練詞組，而不是實體。 |
| 實體應有範圍限制，可擷取某一類型資訊的不同值。 | 使您的實體集中重點、簡短和簡單。如果您的實體值很複雜，可能是因為意圖訓練詞組更適合您的情況。舉例來說，想想看「使用方案 A 要怎麼撥打國際電話？」和「在方案 B 中使用漫遊服務」這類的說法。請勿為動作 (「怎麼撥打國際電話」和「使用漫遊服務」) 和方案 (「方案 A」和「方案 B」) 都建立實體。相反地，您應該使用訓練詞組和意圖比對來擷取動作和實體來擷取計畫。 |
| 訓練詞組中的加註文字應豐富多樣。 | 例如，如果您提供的時間值應如同訓練詞組的 @sys.time 系統實體進行剖析，則不要在所有訓練詞組中提供相同的時間。您的訓練詞組應包含各種時間示例，例如：「上午 7 點」、「下午 8 點」、「9 點」。 |
| 含有多個參數的意圖也應該包含多個訓練詞組。 | 一般來說，訓練詞組的數量應至少是參數的三倍，且至少要有 10 到 20 個訓練詞組 (視意圖的複雜程度而定)。 |
| 每個參數都應該用於多個訓練詞組。 | 通常，每個參數應至少用於 5 個訓練詞組。 |
避免在訓練詞組中使用多個 @sys.any 實體。 |
一個訓練詞組不應包含兩個連續的 @sys.any 或總共三個的 @sys.any 實體，Dialogflow 可能無法從中區分。 |
| 在不同的意圖中請勿使用類似的訓練詞組。 | 不同的意圖不應包含類似的訓練詞組，因為這樣會造成 Dialogflow 無法瞭解如何辨認這些詞組。 |
| 啟用自動拼字修正功能 | 如果您要使用文字輸入，請啟用自動拼字校正功能。 |
| 請勿套疊複合式實體 | 在複合式實體中，請勿使用超過一層的巢狀結構。巢狀結構的每一層都會大幅降低品質。 |
| 避免在訓練詞組中使用特殊字元。 | 訓練詞組中的特殊字元，如 {、_、# 和 [ 等都會被忽略。表情符號則例外，可正常運作。 |
意圖命名
如果代理程式有許多意圖，建議您採用命名配置，以便整理。意圖名稱通常會以標點符號分隔，具體程度由左至右遞增。此外，意圖名稱應反映使用者在一輪對話中的意圖。
命名方案有很多種，以下舉例說明：
- 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
實用的意圖功能
| 最佳做法 | 說明 |
|---|---|
| 應用程式應支援背景資訊相關要求。 | 例如，假設您的代理程式處理天氣相關要求，有個使用者問「舊金山的天氣」時，請務必加入背景資訊來進一步支援「明天如何？」 |
| 代理程式應對是、否、取消、下一步、上一步等要求進行後續追蹤。 | 後續意圖用於回覆常見的回應。如要新增後續意圖，請將滑鼠游標懸停在意圖上，然後按一下「Add follow-up」(新增後續意圖)。 |
| 意圖應具有至少一則文字回應。 | 回應區段是在意圖頁面的最下方。新增變化類型能讓系統輪流選用回應，盡量避免讓使用者收到重複的回應。 |
| 代理程式應收集所有能履行使用者要求的必要資訊。 | 如有需要，不妨建立必要的參數；因為代理程式會持續提示使用者回答問題，直到取得需要的資訊。這就是所謂的「運算單元填充」。 |
| 回應應視情況重複重要資訊 (例如確認訂單的訊息)。 | 使用者提出下單或修改資訊等要求時，您的代理程式應重複指出目前正在進行的動作，以達到確認目的。建立這些確認回應時，請務必納入重複實體和參數的所有可能組合。 |
對話補救
| 最佳做法 | 說明 |
|---|---|
| 代理程式應在對話方塊的每個步驟都有實用的補救提示訊息。 | 舉例來說，如果初始提示是「您想要什麼顏色？」，而使用者回覆「叢林鸚鵡」，則備用/後續意圖應重新表述問題，例如「抱歉，您說的是什麼顏色？」 |
| 代理程式的預設備用意圖應有符合品牌特色的自訂回應。 | 使用者提及的要求若非符合代理程式意圖，就是符合備用意圖。因此備用意圖應自訂為能反映品牌特色的回應，並提供相關資訊來引導使用者提出有效的要求。 |
| 對於自訂的執行要求，代理程式應具備允許使用者重複資訊的意圖。 | 一個意圖可以處理「再說一次」、「重複」、「再播放一次」等要求。這可以是後續意圖。 |
| 協助使用者成功，引導他們說出您想聽到的答案 | 舉例來說，如果你提供選項，請不要問「你要 A 還是 B？」，- 因為使用者可能會回答「是」。請改問：「我有 A 和 B。你比較喜歡哪一個？ |
角色
| 最佳做法 | 說明 |
|---|---|
| 代理程式回應應獨具風格和語調，符合品牌特色且在整個代理程式中保持一致。 | 由於使用者是與您的代理程式在交談，因此應該要讓他們有一種和某個人物角色對話的感覺。確保所有回應都要能呈現出您選定的人格特質和個性。 |
| 代理程式應謹慎考量文化、性別、宗教信仰、能力和年齡等因素。 | 就算是以開玩笑的口吻，刻板印象也可能會冒犯到使用者，導致他們不願意再返回與您的代理程式互動。 |
設計語音功能
| 最佳做法 | 詳細資料 |
|---|---|
| 避免需要視覺化或鍵盤和滑鼠互動的內容。 | 請勿使用超連結、表格、圖片和縮寫。你可以使用網站名稱來參照網站。列出選項時，請傳回最符合的項目，並詢問使用者是否想聽其他選項。 |
| 避免尷尬的沉默。一律以問題結尾。引導對話，持續互動。 | |
| 撰寫簡潔易懂的對話。 | 螢幕上的文字可能很長，且包含多個段落。您可以略過不感興趣的部分。但如果虛擬服務專員說話時間太長，使用者可能會感到不耐煩。 |
| 使用 SSML | 使用 SSML 調整語句結構和語調，讓語音聽起來更自然。 |
如要進一步瞭解如何設計語音功能，請參閱「語音代理設計」。
保護消費者隱私
| 最佳做法 | 詳細資料 |
|---|---|
| 在代理設定中停用資料記錄功能，以符合 GDPR 規範。 | 您可以在代理設定中，停用 Dialogflow 的互動記錄功能。停用這項功能後，Dialogflow 就不會儲存任何 PII 資料。這也代表你無法使用某些功能，例如數據分析。 |
| 將即時通訊對話資料儲存在 BigQuery，控管區域儲存空間。 | 您可以透過 Cloud Logging 或 Dialogflow API，將外來通訊語句傳送至 BigQuery。這樣一來，您就能控管資料的儲存區域。此外，您也可以使用 Data Loss Prevention API 遮蓋機密資訊。請參閱在 GCP 上建構 AI 輔助客服中心的藍圖。 |
使用知識庫連接器
| 最佳做法 | 詳細資料 |
|---|---|
| 匯入公開常見問題時，請使用有效的 HTML5 標記。 | 舉例來說，請使用含有 schema.org 標記法的文章元素，例如 schema.org/Question 和 schema.org/Answer。 |
| 確認 Google 機器人已為常見問題網站建立索引 | 網站必須允許 Google 機器人，並透過 Google 網站管理員工具新增至 Google 搜尋引擎。pages.github 等網站無法檢索，因此不適用。 |
| 使用 1 到 200 個常見問題 | 每個知識庫必須有至少一組問答，最多 200 組。如有需要，可以載入多個知識庫。 |
實作 Dialogflow API
| 最佳做法 | 詳細資料 |
|---|---|
| 請勿在行動或網頁應用程式的用戶端程式碼集中，公開服務帳戶私密金鑰。 | 這不安全。任何熟悉 Chrome 開發人員工具的人，都能竊取您的金鑰，並透過您的帳戶發出 (付費) API 呼叫。建議您一律讓 API Proxy 伺服器處理 Google Cloud 驗證。這樣一來，服務帳戶就不會公開，金鑰也能安全儲存。} |
設計單一代理，同時處理語音和文字
| 最佳做法 | 詳細資料 |
|---|---|
| 請勿在預設平台回覆中使用 SSML。 | 如果代理能以語音和文字回覆，文字回覆會包含原始 SSML 程式碼。在預設平台回覆中使用純文字，在平台專屬回覆中使用 SSML。或者，您也可以使用 Webhook，只在需要語音回覆時生成 SSML。 |
測試
| 最佳做法 | 說明 |
|---|---|
| 請未參與開發過程的使用者一起徹底測試您的應用程式。 | 請不熟悉該代理程式的人來試用應用程式，您才能知道整個對話的流程是否足夠自然順暢。請測試者幫忙就準確度、長時間停頓、對話路徑遺失、節奏、不自然的轉折語等方面檢查是否有問題。 |
| 在您打算支援的所有平台上測試您的應用程式。 | 如果您的代理程式將用於一或多個平台，請確認複合式訊息和回應在所有平台上均可正常顯示。 |