联络中心 AI 的 Apigee 最佳实践

可能在某个时刻已经与客户服务聊天机器人进行过交互。然而，许多互动仍存在不足之处。现代消费者期望的不仅是用预定义答案回答问题的简单机器人，更希望一个能够解决实际问题的虚拟代理。

Google Cloud Contact Center AI (CCAI) 使组织能够通过 AI 支持的对话提供自然交互，从而高效地支持最终客户。本指南将分享七个 Apigee 最佳实践，帮助构建具有安全 API 的快速、有效的聊天机器人。

本文假设具备 CCAI 和 Apigee API 管理的基本知识。

良好的对话具有挑战性

组织面临的众多挑战之一是，随着信息驻留在比以往更多的地方，如何为客户提供高质量的机器人体验。创建最佳虚拟代理通常涉及使用 REST API 与分布在本地和云环境中的新旧系统集成。

Dialogflow CX 是 CCAI 的自然语言处理模块，能够将对话中的文本或音频转换为结构化数据。其一项强大功能是实现与后端系统连接的 Webhook 功能。

一旦虚拟代理触发 Webhook，Dialogflow CX 会连接到后端 API，使用响应并将所需信息存储在上下文中。这种集成使虚拟代理能够与最终用户进行更明智、更有目的的交互，例如验证商店营业时间、确定特定商品是否有库存以及检查订单状态。

开发用于 CCAI 实现的 API 并非易事，可能面临诸多挑战，包括：

复杂性：可能需要访问未向外部公开的 API，这需要大量协作和规则来访问现有数据和系统。如果缺乏 API 网关实时转换数据系统复杂性并将其转发给客户，容易导致技术债务和效率低下。
增加客户挫败感：联络中心通常是客户体验的主要驱动因素之一。提高响应速度可以增强体验，但任何摩擦或延迟都可能被放大。缓存和预取数据是实现更快虚拟代理响应的常用方法。
API 编排：API 通常不仅需要公开端点，还需要频繁更改以响应客户需求。这种灵活性可能需要 API 编排，使 API 与严格的服务解耦，并集成到根据与 Dialogflow CX 交互的预期消费模式和安全要求定制的界面中。

如果缺乏 API 平台，实时转换数据系统复杂性并高效转发给调用者将非常困难。

Dialogflow 和 Apigee 提供更好的聊天机器人体验

通过 API 融入业务结构时，CCAI 的效果更佳。添加的功能越多（API 也越多），简化 API 集成流程就越重要。需要整合重复性工作，验证安全状况，并实施优化，以确保良好的最终用户体验。

Apigee API Management 为更快、更轻松地实现这一目标铺平道路。Apigee 是一个直观的平台，供机器人设计师和架构师将关键业务流程和见解融入工作流程。具体而言，Apigee 使 Dialogflow 能够与后端系统对话。

Apigee 的内置策略可用于检查 Dialogflow 请求、设置响应、验证定义的参数以及实时触发事件。例如，如果一次呼叫满足定义的业务标准，Apigee 可以在 BigQuery 等数据仓库中增强“360 度视图”，将客户添加到营销活动列表中，或发送短信/文本提醒，所有这些都不会显著影响路由时间。

通过将 CCAI 与 Apigee 配对，能够充分利用 Google Cloud 转换工具集，减少对话架构师集成 API 所需的时间，创建更具凝聚力的开发环境以解决呼叫中心挑战。

使用 Apigee 充分利用联络中心 AI API 开发的七种方法

以下是用于 Dialogflow CX API 实现的 Apigee API 开发的一些最佳实践：

1. 创建单个通用 Apigee API 代理

假设有一个 Dialogflow CX 虚拟代理，需要由 Apigee 提供的三个实现 API：

获取电影列表
将电影票添加到购物车
订购购物车中的商品

从技术上讲，可以为每个 API 创建一个单独的 Dialogflow CX Webhook，指向三个单独的 API 代理。

然而，由于 Dialogflow 具有专有的请求和响应格式，为这些履行 API 创建三个单独的 API 代理会产生三个非 RESTful 代理，除了 Dialogflow CX 虚拟代理外，其他客户端难以使用这些代理。

相反，建议创建一个通用 Apigee API 代理，负责处理所有履行 API。Dialogflow CX 将只有一个 Webhook，配置为将请求发送到通用 Apigee API 代理。每个 Webhook 调用带有一个唯一标识正确履行 API 的标签。

2. 尽可能利用 Dialogflow 策略

Apigee 提供了两个特定于 Dialogflow 的策略：ParseDialogflowRequest 和 SetDialogflowResponse。强烈建议尽可能使用这些策略。

这样不仅遵循了优先选择内置策略而非自定义代码的一般最佳实践，还确保 Dialogflow 请求和响应的解析与设置标准化、强化和高性能。

作为一般规则：

ParseDialogflowRequest 在 API 代理中仅需一次，并在身份验证后放置在 PreFlow 中。
SetDialogflowResponse 可用于每个不同的履行响应（即，每个唯一的 Webhook 标签）。如果 SetDialogflowResponse 不满足所有要求，可使用 AssignMessage 或 JavaScript 策略进行补充或替换。

3. 对每个 Webhook 标签使用条件流

应使用条件流来分离不同履行 API 的逻辑。实现此目的的最简单方法是在 PreFlow 中放置 ParseDialogflowRequest 策略。添加该策略后，流变量 google.dialogflow.<Optional-prefix>.fulfillment.tag 将使用 Webhook 标签的值填充。然后，该变量可用于定义请求进入特定条件流的条件。

以下是使用相同三个履行 API 的条件流示例：

4. 考虑使用代理链

Dialogflow CX Webhooks 有自己的请求和响应格式，不遵循 RESTful 约定（如 GET 用于读取、POST 用于创建、PUT 用于更新等），这使得传统客户端难以使用为 Dialogflow CX 创建的 API 代理。

因此，建议使用代理链。通过代理链，可以将 API 代理分为两类：Dialogflow 代理和资源代理。

Dialogflow 代理：专注于 Dialogflow 客户端特定操作的轻量级代理，如验证请求、将 Dialogflow CX 请求转换为 RESTful 格式、向资源代理发送 RESTful 请求、将资源代理的响应转换回 Dialogflow 格式。
资源代理：承担任何涉及连接到后端和数据交换的任务，像任何其他 Apigee API 代理一样创建资源代理，专注于为所有类型的客户端提供统一的 RESTful 界面。

代理链提供了一种重用代理的方法。然而，当调用从一个代理转移到另一个代理时，可能会产生一些额外开销。另一种方法是使用可重用共享流，开发明确设计为可重用的组件。共享流将策略和资源组合在一起，可抽象为共享库，允许在多个位置使用的功能被捕获。它们还使安全团队能够标准化可信系统连接的方法和规则，确保安全合规性，同时不影响创新速度。希望以这种方式连接的代理必须位于同一组织和环境中。

5. 通过缓存预取提高性能

在创建聊天机器人或任何其他自然语言理解增强型应用程序时，响应延迟是一个重要指标。最大限度地减少延迟有助于保留用户注意力，避免用户怀疑机器人是否已损坏。

如果 Dialogflow 虚拟代理依赖的后端 API 响应时间较长，可通过预取数据并将其存储在 Apigee 的缓存中提高性能。可以包含令牌和其他元信息，这些信息可能直接影响客户输入与 Dialogflow 返回提示之间的时间。Apigee 缓存是可编程的，提供更大灵活性，从而提升对话体验。可使用 Response Cache（或 Populate Cache）结合 Service Callout 策略实现数据预取和缓存。

6. 使用单个复杂参数而非多个标量参数进行响应

使用 SetDialogflowResponse 策略响应虚拟代理时，可通过 <Parameters> 元素一次返回多个值。该元素接受一个或多个子 <Parameter> 元素。如果可能，将单个参数作为 JSON 对象返回，通常比将响应分解为多个参数（每个参数包含单个字符串或数字）更有效。可通过 <JSONPath> 利用此策略。

推荐这种方法的原因：