本指南提供設計所有類型代理程式的一般最佳做法。
您也應參閱專門設計語音代理程式的語音代理程式設計指南,以及使用 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?」- 因為使用者可能會回答「是」。請改問:你比較喜歡哪一個? |
角色
最佳做法 | 說明 |
---|---|
代理程式回應應獨具風格和語調,符合品牌特色且在整個代理程式中保持一致。 | 由於使用者是與您的代理程式在交談,因此應該要讓他們有一種和某個人物角色對話的感覺。確保所有回應都要能呈現出您選定的人格特質和個性。 |
代理程式應謹慎考量文化、性別、宗教信仰、能力和年齡等因素。 | 就算是以開玩笑的口吻,刻板印象也可能會冒犯到使用者,導致他們不願意再返回與您的代理程式互動。 |
語音設計
最佳做法 | 詳細資料 |
---|---|
避免使用需要視覺化或鍵盤和滑鼠互動的內容。 | 請勿使用超連結、表格、圖片和縮寫。你可以直接說出網站名稱來收聽該節目。提供選項清單時,請傳回最相符的選項,並詢問使用者是否要聽取其他選項。 |
不要讓對話出現尷尬的沉默。請務必以問題收尾。引導對話,促進互動。 | |
撰寫簡潔易懂的對話。 | 在螢幕上,文字可以很長,並包含多個段落。你可以略過不感興趣的部分。不過,如果虛擬服務專員講太久,使用者可能會不滿意。 |
使用 SSML | 使用 SSML 結構並變更句子的語氣,讓語音聽起來更自然。 |
如要進一步瞭解如何設計語音功能,請參閱「語音助理設計」。
保護消費者隱私
最佳做法 | 詳細資料 |
---|---|
為符合 GDPR 規定,請在代理程式設定中停用資料記錄功能。 | 您可以在代理程式設定中,停用 Dialogflow 中的互動記錄功能。停用這項功能後,Dialogflow 就不會儲存任何 PII 資料。這也表示您將無法使用某些功能,例如數據分析。 |
將即時通訊對話資料儲存在 BigQuery 中,以便控管區域性儲存空間。 | 您可以透過 Cloud Logging 或使用 Dialogflow API,將收到的即時通訊對話內容傳送至 BigQuery。採用這種做法,您就能控管要儲存資料的區域。此外,您也可以使用 資料遺失防護 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。 |
測試
最佳做法 | 說明 |
---|---|
請未參與開發過程的使用者一起徹底測試您的應用程式。 | 請不熟悉該代理程式的人來試用應用程式,您才能知道整個對話的流程是否足夠自然順暢。請測試者幫忙就準確度、長時間停頓、對話路徑遺失、節奏、不自然的轉折語等方面檢查是否有問題。 |
在您打算支援的所有平台上測試您的應用程式。 | 如果您的代理程式將用於一或多個平台,請確認複合式訊息和回應在所有平台上均可正常顯示。 |