服務使用最佳做法

本指南提供使用 Dialogflow 服務的最佳做法。這些規範的目的是提高服務的效率和準確性，並實現最佳回應時間。

您也應參閱一般代理程式設計指南 (適用於所有代理程式類型)，以及語音代理程式設計指南 (專為設計語音代理程式而設)。

正式版

在正式環境中執行代理程式之前，請務必採用下列最佳做法：

啟用稽核記錄

在專案中啟用 Dialogflow API 的資料存取稽核記錄。這有助於追蹤連結至這個專案的 Dialogflow 代理程式在設計階段的變更。

代理程式版本

建議您一律使用代理程式版本處理正式流量。詳情請參閱「版本和環境」。

建立代理程式備份

保留最新匯出的代理程式備份。這樣一來，如果自己或團隊成員不慎刪除代理程式或專案，就能快速復原。

用戶端重複使用

在應用程式的執行生命週期內重複使用 *Client 用戶端程式庫執行個體，即可提升應用程式效能。

最重要的是，重複使用 SessionsClient 用戶端程式庫執行個體，即可提升偵測意圖 API 呼叫的效能。

請參閱工作階段參考資料。

如要瞭解詳情，請參閱「用戶端程式庫最佳做法指南」。

代理程式的批次更新

如果在短時間內傳送多個個別代理程式更新 API 要求，要求可能會受到節流。這些設計階段 API 方法未實作，無法處理單一代理程式的高更新率。

部分資料類型提供批次方法，可達到這個目的：

  • 請改用 batchUpdate 或 batchDelete 方法，不必傳送多個 EntityTypes create、patch 或 delete 要求。
  • 請改用 batchUpdate 或 batchDelete 方法，不要傳送多個 Intent create、patch 或 delete 要求。

API 錯誤重試

呼叫 API 方法時，您可能會收到錯誤回應。有些錯誤應重試，因為通常是暫時性問題所致。兩種錯誤類型如下：

此外，您應為重試作業實作指數輪詢。這樣一來，系統就能在 API 服務負載過重時，找出可接受的速率。

Cloud API 錯誤

如果您使用 Google 提供的用戶端程式庫，系統會為您實作指數輪詢的 Cloud API 錯誤重試機制。

如果您使用 REST 或 gRPC 實作自己的用戶端程式庫，則必須為用戶端實作重試機制。如要瞭解應重試或不應重試的錯誤，請參閱「API Improvement Proposals: Automatic retry configuration」。

Webhook 錯誤

如果 API 呼叫觸發 Webhook 呼叫，Webhook 可能會傳回錯誤。即使您使用 Google 提供的用戶端程式庫，系統也不會自動重試 Webhook 錯誤。程式碼應重試從 Webhook 收到的 503 Service Unavailable 錯誤。如要瞭解 Webhook 錯誤類型和檢查方式，請參閱 Webhook 服務說明文件。

負載測試

建議您在將程式碼發布至實際工作環境前，先對系統執行負載測試。執行負載測試前，請先考量以下幾點：

摘要 詳細資料
增加負重。 負載測試必須逐步增加套用至 Dialogflow 服務的負載。這項服務的設計目的並非處理負載突然暴增的情況，而這種情況在實際流量中很少發生。服務需要時間調整以因應負載需求，因此請緩慢提高要求比率，直到測試達到所需負載為止。
系統會收取 API 呼叫費用。 測試期間會收取 API 呼叫費用，且呼叫次數會受專案配額限制。
使用測試替身。 您可能不需要在負載測試期間呼叫 API。如果負載測試的目的是判斷系統如何處理負載，通常最好使用測試替身，取代對 API 的實際呼叫。測試替身可以模擬 API 在負載下的行為。
使用重試。 您的負載測試必須執行重試，並進行輪詢。

從使用者裝置安全地呼叫 Dialogflow

您絕不應將用於存取 Dialogflow API 的私密金鑰儲存在一般使用者裝置上。這適用於直接在裝置上儲存金鑰，以及在應用程式中硬式編碼金鑰。當用戶端應用程式需要呼叫 Dialogflow API 時，應在安全平台上將要求傳送至開發人員擁有的 Proxy 服務。Proxy 服務可以進行實際的 Dialogflow 驗證呼叫。

舉例來說，您不應建立直接呼叫 Dialogflow 的行動應用程式。如要這麼做，您必須在使用者裝置上儲存私密金鑰。行動應用程式應改為透過安全 Proxy 服務傳送要求。

效能

本節將說明 Dialogflow 中各種作業的效能資訊。瞭解延遲時間有助於設計回應式代理程式，並設定實際的效能期望，但這些值不屬於 Dialogflow 服務等級協議。

建構監控和快訊工具時，請注意大型語言模型 (LLM) 和語音處理通常是使用串流方法處理。系統會盡快將回應傳送給用戶端，通常會比方法呼叫的總時間早得多。詳情請參閱「大型語言模型 (LLM) 最佳做法」。

每項作業的效能

下表提供 Dialogflow 作業的一般效能資訊：

動作 附註
意圖偵測 (文字) 快速操作
偵測參數 (文字) 快速操作
語音辨識 (串流) 系統會盡快處理資料並傳回回應。總執行時間主要取決於輸入音訊的長度。不建議使用總執行時間測量延遲時間。
語音合成 (串流) 總執行時間主要取決於輸出音訊的長度。系統會盡快處理資料並傳回回應。
Webhook 呼叫 效能直接取決於 webhook 中程式碼的執行時間。
進出口代理商 效能取決於代理程式的大小。
訓練代理程式 效能取決於流程、意圖和訓練詞組的數量。訓練大型代理程式可能需要數十分鐘。
建立環境 建立環境需要訓練代理程式，因此總時間取決於代理程式的大小和複雜度。

重要事項：

  • 串流：如果是串流呼叫 (語音辨識和合成)，系統會在收到資料時立即處理，並盡快傳回回應。也就是說，初步回覆通常比通話總時間快上許多。
  • 應對手冊：系統會根據應對手冊指令、對話脈絡和工具輸入內容，建構 LLM 提示。您可以在單一劇本呼叫中執行多個 LLM 提示。因此，劇本的執行時間會因發出的提示數量和呼叫的複雜度而異。

延遲時間的重要考量

  • 不保證延遲時間：即使在佈建輸送量的情況下，Dialogflow 服務水準協議也不會考量延遲時間。
  • LLM 延遲：請注意，LLM 處理作業可能會造成明顯延遲。請將這點納入代理程式設計和使用者預期考量。
  • 監控和快訊：設定監控和快訊時，請考量 LLM 和語音服務的回覆會以串流形式傳送。請勿將完整回覆時間視為首次回覆時間。