本指南提供使用 Dialogflow 服務的最佳做法。這些規範的目的是提高服務的效率和準確性，並實現合理的回應時間。
您也應參閱所有代理程式類型的一般代理程式設計指南，以及專門針對語音代理程式設計的語音代理程式設計指南。
正式化
在實際執行服務前，請務必實作下列最佳做法：
代理程式版本
您應一律使用代理程式版本來處理實際工作流量。詳情請參閱「版本和環境」一文。
建立服務專員備份
請保留最新的匯出代理程式備份。這樣一來，如果您或團隊成員不小心刪除代理程式或專案，就能快速復原。
用戶端重複使用
您可以在應用程式執行期間重複使用 *Client 用戶端程式庫例項，藉此提升應用程式的效能。
最重要的是，您可以重複使用 SessionsClient 用戶端程式庫例項，改善意圖偵測 API 呼叫的效能。
選取工作階段參照項目的通訊協定和版本：
| 通訊協定 | V3 | V3beta1 |
|---|---|---|
| REST | 工作階段資源 | 工作階段資源 |
| RPC | 工作階段介面 | 工作階段介面 |
| C++ | SessionsClient | 不適用 |
| C# | SessionsClient | 不適用 |
| Go | SessionsClient | 不適用 |
| Java | SessionsClient | SessionsClient |
| Node.js | SessionsClient | SessionsClient |
| PHP | 不適用 | 不適用 |
| Python | SessionsClient | SessionsClient |
| Ruby | 不適用 | 不適用 |
詳情請參閱用戶端程式庫最佳做法指南。
API 錯誤重試
呼叫 API 方法時，您可能會收到錯誤回應。有些錯誤通常是因為暫時性問題而發生，因此應重新嘗試。兩種錯誤類型如下：
- Cloud API 錯誤。
- 從 Webhook 服務傳送的錯誤。
此外，您應實作指數輪詢以便重試。這樣一來，系統就能在 API 服務負載過重時，找出可接受的頻率。
Cloud API 錯誤
如果您使用 Google 提供的用戶端程式庫，系統會為您實作 Cloud API 錯誤重試，並採用指數型延遲機制。
如果您已使用 REST 或 gRPC 實作自有的用戶端程式庫，則必須為用戶端實作重試機制。如要瞭解應或不應重試的錯誤，請參閱「API 改善建議：自動重試設定」。
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 作業的一般效能：
| 動作 | 附註 |
|---|---|
| 流程動作：狀態處理常式 | 最快的作業 |
| 流程：意圖偵測 (文字) | 最快的作業 |
| 流程：參數偵測 (文字) | 快速運作 |
| 語音辨識 (串流) | 系統會盡快處理資料並傳回回應。總執行時間主要取決於輸入音訊的長度。我們不建議使用總執行時間來評估延遲時間。 |
| 語音合成 (串流) | 總執行時間主要取決於輸出音訊的長度。系統會盡快處理資料並傳回回應。 |
| 資料儲存庫：已停用生成式 AI | 實際時間取決於資料儲存庫的大小。 |
| 資料儲存庫：已啟用生成式 AI | 效能取決於資料儲存庫的大小、使用的語言模型，以及提示輸出內容和輸入內容的長度，依序排列。 |
| 生成式備用答覆 | 效能取決於使用的語言，以及提示輸出內容和輸入內容的長度 (依序)。 |
| 發電機 | 效能取決於使用的語言模型、提示輸入內容的複雜度和輸出長度，以及回合中產生器的數量。單一回合中有多個產生器，會導致多次呼叫語言模型。 |
| 應對手冊執行作業 | 效能取決於 Playbook 的複雜度、提示數量，以及呼叫任何工具的執行時間。提示輸出內容和輸入內容的長度會影響這項效能。系統可能會依序執行多個語言模型提示，因此通話時間會增加。 |
| 應對手冊：工具 | 效能取決於工具的基礎執行作業。 |
| Webhook 呼叫 | 效能直接取決於 webhook 中程式碼的執行時間。 |
| 匯入 / 匯出代理程式 | 效能取決於代理程式大小。 |
| 專員訓練 | 效能取決於流程、意圖和訓練詞組的數量。訓練大型服務機器人可能需要數十分鐘的時間。 |
| 建立環境 | 建立環境時需要訓練代理程式，因此總時間會視代理程式的大小和複雜度而定。 |
重要事項：
- 串流：對於串流呼叫 (語音辨識和合成)，系統會在資料傳送到時立即處理，並盡快傳回回應。也就是說，初始回應通常比通話的總時間快上許多。
- Playbook：系統會根據 Playbook 指示、對話內容和工具輸入內容，建立 LLM 提示。單一 Playbook 呼叫中可以執行多個 LLM 提示。因此，Playbook 執行作業的時間會因發出的提示數量和呼叫的複雜度而異。
重要延遲時間考量因素
- 不保證延遲時間：即使在已配置的傳輸量下，Dialogflow 服務水準協議也不考量延遲時間。
- LLM 延遲：請注意，LLM 處理作業可能會造成明顯的延遲。請將這項因素納入代理程式設計和使用者預期。
- 監控和警示：設定監控和警示時，請考量 LLM 和語音服務回應的串流特性。請勿假設完整回應時間等於首次回應時間。