本指南介绍了使用 Dialogflow 服务的最佳实践。 这些指导准则旨在提高操作效率和准确性，同时保证服务的合理响应时间。
您还应该查看所有代理类型的一般代理设计指南以及专门用于设计语音代理的语音代理设计指南。
生产化
在生产环境中运行代理之前，请确保实现以下最佳做法：
启用审核日志
在您的项目中为 Dialogflow API 启用数据访问审核日志。与“更改 记录”功能类似，审核日志可以 帮助您跟踪与 项目关联的 Dialogflow CX 代理中的设计时更改。
代理版本
您应始终使用代理版本来处理生产流量。如需了解详情，请参阅 版本和环境 。
创建代理备份
保留最新的 导出 代理备份。这样，如果您或团队成员不小心删除了代理或项目，就可以快速恢复。
客户端重复使用
在应用执行生命周期内重复使用 *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 错误。
- 网络钩子服务发送的错误。
此外，您还应该重试执行指数退避算法。这样，您的系统就可以在 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 操作的典型性能的信息：
| 操作 | 备注 |
|---|---|
| 流操作：状态处理程序 | 最快操作 |
| 流：意图检测（文本） | 最快操作 |
| 流：参数检测（文本） | 快速操作 |
| 语音识别（流式传输） | 数据会尽快处理并返回响应。总执行时间主要取决于输入音频的长度。不建议使用总执行时间来衡量延迟时间。 |
| 语音合成（流式传输） | 总执行时间主要取决于输出音频的长度。数据会尽快处理并返回响应。 |
| 数据存储区：生成式 AI 已停用 | 实际时间取决于数据存储区的大小。 |
| 数据存储区：生成式 AI 已启用 | 性能取决于数据存储区的大小、使用的语言模型以及提示输出和输入的长度，按此顺序排列。 |
| 生成式后备 | 性能取决于使用的语言以及提示输出和输入长度，按此顺序排列。 |
| 生成器 | 性能取决于使用的语言模型、提示输入和输出长度的复杂性以及轮次中的生成器数量。单个轮次中的多个生成器会导致对语言模型进行多次调用。 |
| Playbook 执行 | 性能取决于 playbook 的复杂性、提示的数量以及任何被调用工具的执行时间。提示输出和输入的长度会影响此性能。多个语言模型提示可能会按顺序执行，从而增加总调用时间。 |
| Playbook：工具 | 性能取决于工具的底层执行情况。 |
| 网络钩子调用 | 性能直接取决于网络钩子中代码的执行时间。 |
| 导入 / 导出代理 | 性能取决于代理的大小。 |
| 代理训练 | 性能取决于流、意图和训练短语的数量。训练大型代理可能需要几十分钟。 |
| 环境创建 | 创建环境涉及训练代理，因此总时间取决于代理的大小和复杂性。 |
重要说明：
- 流式传输： 对于流式传输调用（语音识别和合成），数据会在到达时进行处理，并尽快返回响应。 这意味着初始响应通常比调用的总时间要快得多。
- Playbook： 系统会根据 playbook 说明、对话上下文和工具输入构建 LLM 提示。可以在单个 playbook 调用中执行多个 LLM 提示。这就是 playbook 执行是可变的原因，具体取决于发出的提示数量和调用的复杂性。
重要的延迟时间注意事项
- 无延迟时间保证： Dialogflow SLA 不考虑延迟时间，即使在预配吞吐量下也是如此。
- LLM 延迟时间： 请注意，LLM 处理可能会引入显著的延迟时间。在代理设计和用户预期中考虑此因素。
- 监控和提醒： 设置监控和提醒时，请考虑 LLM 和语音服务响应的流式传输特性。 不要假设完整响应时间等于首次响应时间。