服务使用最佳实践

本指南介绍了使用 Dialogflow 服务的最佳做法。这些指导准则旨在提高操作效率和准确性，同时保证服务的合理响应时间。

您还应该查看所有代理类型的一般代理设计指南以及专门用于设计语音代理的语音代理设计指南。

生产化

在生产环境中运行代理之前，请确保实现以下最佳做法：

• 使用代理版本
• 重复使用会话客户端
• 通过重试实现错误处理

启用审核日志

在您的项目中为 Dialogflow API 启用数据访问审核日志。这有助于跟踪与此项目关联的 Dialogflow 代理中的设计时更改。

代理版本

您应始终使用代理版本来处理生产流量。如需了解详情，请参阅版本和环境。

创建代理备份

保留最新的导出代理备份。这样，如果您或您的团队成员不小心删除了代理或项目，您就可以快速恢复。

重复使用客户端

您可以通过在应用的执行生命周期内重复使用 *Client 客户端库实例来提高应用的性能。

最重要的是，您可以通过重复使用 SessionsClient 客户端库实例来提高检测 intent API 调用的性能。

请参阅会话数参考。

如需了解详情，请参阅“客户端库最佳实践”指南。

批量更新代理

如果您在短时间内发送多个单独的代理更新 API 请求，您的请求可能会受到限制。这些设计时 API 方法不能用于处理更新速率较高的单一代理。

为此，某些数据类型提供了批处理方法：

• 使用 batchUpdate 或 batchDelete 方法，而无需发送多个 EntityTypes create、patch 或 delete 请求。
• 使用 batchUpdate 或 batchDelete 方法，而无需发送多个 Intents create、patch 或 delete 请求。

API 错误重试

调用 API 方法时，您可能会收到错误响应。有些错误应该重试，因为这些错误通常是暂时性问题所致。错误分为以下两种类型：

• Cloud API 错误。
• 网络钩子服务发送的错误。

此外，您还应该重试执行指数退避算法。这样，您的系统就可以在 API 服务负载过重时找到一个可接受的速率。

Cloud API 错误

如果您使用的是 Google 提供的客户端库，则系统会为您执行采用指数退避算法的 Cloud API 错误重试。

如果您已使用 REST 或 gRPC 实现自己的客户端库，则必须为您的客户端实现重试。 如需了解哪些错误应重试或哪些错误不应重试，请参阅 API 改进建议：自动重试配置。

网络钩子错误

如果 API 调用触发了网络钩子调用，则您的网络钩子可能会返回错误。即使您使用 Google 提供的客户端库，系统也不会自动重试网络钩子错误。您的代码应该重试从网络钩子接收到的 503 Service Unavailable 错误。如需了解网络钩子错误类型以及如何检查这些错误，请参阅网络钩子服务文档。

负载测试

在将代码发布到生产环境之前，最好对系统执行负载测试。在实现负载测试之前，请考虑以下几点：

摘要	详情
提升负载。	负载测试必须增加应用于 Dialogflow 服务的负载。该服务的目的不是处理突然的负载突发事件，这在实际流量中很少见。该服务需要一段时间才能根据负载需求进行调整，所以需缓慢提高请求速率，直到测试达到所需负载。
系统会对 API 调用收费。	在测试期间，您需要支付 API 调用费用，且调用次数会受到项目配额的限制。
使用 test doubles。	在负载测试期间，您可能不需要调用 API。如果负载测试的目的在于确定系统如何处理负载，那通常最好使用 test double代替对 API 的实际调用。您的 test double 可以模拟 API 在负载下的行为。
使用重试。	负载测试必须使用退避算法执行重试。

从最终用户设备安全地调用 Dialogflow

切勿将用于访问 Dialogflow API 的私钥存储在最终用户设备上。这适用于直接在设备上存储密钥以及在应用中对密钥进行硬编码的情况。当您的客户端应用需要调用 Dialogflow API 时，应向安全平台上开发者拥有的代理服务发送请求。代理服务可以进行实际的经过身份验证的 Dialogflow 调用。

例如，您不得创建直接调用 Dialogflow 的移动应用。执行此操作需要您将私钥存储在最终用户设备上。您的移动应用应改为通过安全的代理服务传递请求。

性能

本部分简要介绍了 Dialogflow 中各种操作的性能信息。虽然这些值不属于 Dialogflow SLA 的范围，但了解延迟时间对于设计响应迅速的客服人员和设定切实的效果预期至关重要。

构建监控和提醒工具时，请注意，大语言模型 (LLM) 和语音处理通常使用流式方法处理。系统会尽快将响应发送给客户端，通常比方法调用的总时长要早得多。如需了解详情，请参阅大语言模型 (LLM) 最佳实践。

每次操作的性能

下表提供了有关 Dialogflow 操作典型性能的信息：

操作	备注
意图检测（文本）	快速操作
参数检测（文本）	快速操作
语音识别（流式）	系统会尽快处理数据并返回响应。总执行时间主要取决于输入音频的长度。不建议使用总执行时间来衡量延迟时间。
语音合成（流式传输）	总执行时间主要取决于输出音频的长度。我们会尽快处理数据并返回结果。
网络钩子调用	性能直接取决于 webhook 中代码的执行时间。
导入 / 导出代理	性能取决于代理的大小。
客服人员培训	性能取决于流程、intent 和训练短语的数量。训练大型代理可能需要几十分钟。
环境创建	创建环境需要训练代理，因此总时间取决于代理的大小和复杂程度。

重要说明：

• 流式：对于流式调用（语音识别和合成），系统会在数据到达时进行处理，并尽快返回响应。这意味着，初始响应通常比调用总时间要快得多。
• Playbook：系统会根据 Playbook 说明、对话上下文和工具输入构建 LLM 提示。在单次 Playbook 调用中可以执行多个 LLM 提示。因此，Playbook 的执行时间会因发出的提示数量和调用的复杂性而异。

有关延迟时间的重要注意事项

• 无延迟保证：Dialogflow SLA 不考虑延迟时间，即使在预配吞吐量的情况下也是如此。
• LLM 延迟时间：请注意，LLM 处理可能会导致明显的延迟。请将这一点考虑在您的客服人员设计和用户期望中。
• 监控和提醒：设置监控和提醒时，请考虑 LLM 和语音服务的回答是流式传输的。请勿假设完整响应时间等于收到首个响应的等待时间。