本指南介绍了设计所有类型的代理时的一般最佳做法。
您还应该查看专门用于设计语音代理的语音代理设计指南，以及使用 Dialogflow 服务的最佳做法指南。
构建代理的准备工作
本部分提供了在开始构建代理之前应该考虑的信息。
目标
请考虑代理的整体目标：
- 您的企业想要实现什么目标？
- 用户对代理有何期望？
- 用户与代理互动的频率如何？
平台
请考虑用户访问代理的方式。在创建内容之前，请查看 Dialogflow 支持的平台。当您选择支持的平台时，请相应地准备内容。Dialogflow 的部分平台集成支持富消息，其中可包含图片、链接和建议内容信息卡等元素。
以迭代方式构建代理
如果代理很大或很复杂，请先构建一个仅处理顶级请求的对话。建立起基本的结构后，再迭代对话路径，确保涵盖用户可能会采用的所有路由。
预建代理
Dialogflow 提供了几个帮助您入门的预建代理，涵盖酒店预订、导航和在线购物等常见用例。这些代理附带意图和实体，以涵盖最常见的用户查询。只要添加特定于您的企业的响应，就能快速构建一个正常运行的代理。
系统实体
当用户提出请求时，他们所说的话语中有重要的信息待解析。在 Dialogflow 中，这些信息称为实体。需要特别指出的是，系统实体是 Dialogflow 提供的预建实体，用于处理最普遍的信息类型。
Small Talk
在开发对话时，您可能已经考虑过如何处理偏离主题的请求。Dialogflow 提供了一个名为 Small Talk 的可选功能。启用此功能后，代理将响应一般对话、情绪响应以及有关代理本身的问题。所有 Small Talk 响应都可以进行自定义，以确保无论是休闲、商务还是介于两者之间的体验都能体现您的品牌。
代理设计最佳做法
本部分提供了构建强大、准确、高效且实用的代理的最佳做法列表。
问候和道别
| 最佳做法 | 详情 |
|---|---|
| 欢迎意图应该让用户了解代理的功能，同时不忘品牌塑造。 | 代理的“欢迎意图”应该告知用户代理可帮助执行的 2-3 项任务，以及根据需要告知如何使用这些功能的简要说明。 |
| 顺利结束交互之后，代理应该显示合适的退出消息。 | 当用户在代理中完成任务时，代理应该总结事务/任务并表达“Until next time”之类的内容。 |
机器学习和训练
| 最佳做法 | 详情 |
|---|---|
| 意图应该至少具有 10-20 个训练短语（具体取决于意图的复杂程度）。 | 每个意图应该具有的实际训练短语数量取决于代理的复杂程度，但最好不少于 10-20 个（具体取决于意图的复杂程度）。意图中的参数越多，您提供以用来训练机器学习模型的短语就应该越多。 |
| 训练短语应该多种多样。 | 包含问题、命令、动词和常见名词的同义词的各种变体，以确保短语涵盖各种可能的请求。 |
| 注释应该一致。 | |
| 为系统实体使用具有语义意义的注解。 | 选择用作注解的训练短语部分的语义可能会受到训练短语中其余文本的影响。例如：
例如，请勿使用 @sys.duration 系统实体为上面第一个“7 年”示例进行注解。“7 年”的语义含义与简单的时间时长不符。您应改用 @sys.age 系统实体。 |
| 自定义实体应涵盖广泛的示例。 | 实体是项目列表。机器学习将处理语法形式，但您必须囊括所有可能的项目。另外，请选中定义同义词选项并加入一些变体。 |
| 为尽可能少的意图停用机器学习功能 | 当您训练代理时，系统将不使用停用了机器学习功能的意图的训练短语。一个与停用了机器学习功能的意图中的训练短语非常接近的用户查询，有可能被错误地匹配到与该用户查询略有相似，但却启用了机器学习功能的其他意图。如果您遇到假正例问题，请提高机器学习分类阈值，而不是停用机器学习功能。 |
| 请勿为只有少量训练数据的代理设置较高的机器学习分类阈值。 | 如果该阈值较高但训练数据不多，则只有与训练短语几乎完全匹配的用户查询才会导致意图匹配。如果您想要使用较高的阈值，则需要提供大量训练数据。 |
| 代理应具有后备意图。 | 如果没有后备意图，则不匹配的用户查询将导致产生空响应。 |
| 代理应该提供反例。 | 反例可防止与训练短语略有相似的用户查询无意中与意图匹配。 |
| 请勿定义几乎与任何内容都匹配的实体。 | 这样做会降低机器学习的性能和质量。每个训练短语中几乎所有内容都将被评估为可能的匹配。请考虑使用 @sys.any 来代替。同样，复合实体不应包含单个 @sys.any 作为同义词。 |
| 请勿定义包含填充词或无意义文本的实体。 | 例如，“hmmm”、“let's see”、“please”、“could you please”都是填充词和无意义文本。如果您尝试使用此类实体来增添多样性，只会降低机器学习的性能。Dialogflow 已经增强了数据来应对此类多样性。您应该将这类语句添加到训练语句中，而不是添加到实体中。 |
| 实体应具有有限的范围，可捕获一种信息类型的不同值。 | 实体应尽可能集中、简短、简洁。如果您的实体值很复杂，那么可能意图训练短语更适合您的情况。例如，假设最终用户的表述为“How can I make an international call with Plan A?”和“Using international data roaming with Plan B”。请不要同时为两种操作（“How can I make an international call”和“Using international data roaming”）和方案（“Plan A”、“Plan B”）创建实体。相反，您应使用训练语句和意图匹配来捕获操作，并使用实体来捕获方案。 |
| 训练语句中添加了注释的文本应该丰富多样。 | 例如，如果要提供应在训练短语中被解析为 @sys.time 系统实体的时间值，请勿在所有训练短语中都提供相同的时间。训练短语应该有各种各样的时间示例，如：“7 a.m.”、“8 p.m.”、“9 o'clock”。 |
| 具有多个参数的意图也应该有多个训练语句。 | 通常，请尝试使用至少三倍于参数数量、而且不少于 10-20 个（具体取决于意图的复杂程度）的训练短语。 |
| 每个参数都应该用于多个训练短语。 | 通常，每个参数应至少用于 5 个训练短语。 |
避免在一个训练短语中使用多个 @sys.any 实体。 |
一个训练短语不应包含两个连续的 @sys.any 或者总共三个 @sys.any 实体。Dialogflow 可能无法区分它们。 |
| 请勿在不同的意图中使用类似的训练短语。 | 不同的意图不应包含类似的训练语句，因为这样会阻止 Dialogflow 学习如何识别这些语句。 |
| 启用自动拼写更正。 | 如果您使用的是文本输入，则应启用自动拼写更正。 |
| 请勿嵌套复合实体 | 请勿在复合实体中使用多于一层嵌套。每层嵌套都会显著降低质量。 |
| 避免在训练语句中使用特殊字符。 | 训练短语中的特殊字符（如 {、_、# 和 [）将被忽略。但表情符号除外；它们将发挥预期的效果。 |
意图命名
如果您的代理有许多意图，则应考虑使用可帮助您有序组织这些意图的命名方案。常见的做法是使用标点符号细分意图名称，使含义的具体性从左到右逐渐增强。此外，意图名称应反映最终用户在一轮对话中的意图。
有很多合适的命名架构，以下是一个示例：
- phone-service.order.cancel
- phone-service.order.create
- phone-service.order.change
- tv-service.order.cancel
- tv-service.order.create
- tv-service.order.change
- account.balance.get
- account.balance.pay
- account.address.get
- account.address.update
实用的意图功能
| 最佳做法 | 详情 |
|---|---|
| 代理应支持上下文请求。 | 例如，如果代理处理天气请求并且用户询问“Weather in San Francisco”，请确保添加上下文以支持更多请求，例如“How about tomorrow?” |
| 代理应该对是、否、取消、下一步、后退等请求进行后续跟进。 | 后续意图用于回复常见响应。要添加后续意图，请将鼠标悬停在意图上，然后点击 Add follow-up。 |
| 意图应该至少有一条文本响应。 | 响应部分位于意图页面的底部。添加变体后，系统将会随机显示所选择的响应，从而减少重复性体验。 |
| 代理应收集所有必要的信息以满足用户的请求。 | 考虑将必要的参数设为必需参数。代理将持续提示用户，直到它获得所需的信息为止。这称为槽位填充。 |
| 响应应该根据需要重复信息，例如确认订单。 | 当用户提出下订单或更改信息之类的请求时，代理应该重复叙述发生的事情以进行确认。创建这些确认响应时，请确保包含重复实体和参数的所有可能组合。 |
对话修复
| 最佳做法 | 详情 |
|---|---|
| 在对话的每个步骤中，代理应该提供实用的恢复提示信息。 | 例如，如果初始提示是“What color do you want?”，而用户回答“jungle parrot”，则后备/后续意图应该更改这个问题的措辞，比如“Sorry, what color was that?” |
| 代理应在默认后备意图中具有特定于品牌的自定义响应。 | 当用户说出与意图不匹配的话语时，系统将匹配默认后备意图。应对默认后备意图进行自定义，以反映您的品牌并提供信息指导用户提出有效的请求。 |
| 对于自定义的 fulfillment，代理应具有允许用户重复信息的意图。 | 一个意图可以处理“再说一遍”、“重复一遍”、“再播放一遍”之类的请求。这可以是一个后续意图。 |
| 帮助用户取得成功，引导他们准确地告诉您您希望听到的答案 | 例如：如果您提供选项，请不要询问“您喜欢 A 还是 B？”。- 因为用户会回答“是”，而不会问：“我有 A，也有 B。您喜欢哪一个？” |
角色
| 最佳做法 | 详情 |
|---|---|
| 代理的响应风格和基调应该适合您的品牌，并且在整个代理中一致。 | 当用户与您的代理对话时，应该感觉他们正在与某个角色对话。请确保您选择的品质和个性会体现在您的所有响应中。 |
| 代理应该对文化、性别、宗教信仰、能力和年龄保持敏感。 | 刻板印象有可能会冒犯用户（即使您是在开玩笑），他们可能因此不会再回来使用代理。 |
语音设计
| 最佳做法 | 详情 |
|---|---|
| 避免使用需要直观呈现或键盘和鼠标互动的内容。 | 请勿使用超链接、表格、图片、缩写。您可以通过名称引用网站。在显示选项列表时，返回最佳匹配并询问用户是否希望听到其他选项。 |
| 请勿创建不适用的静音。始终以问题结束。增进对话，推动互动。 | |
| 撰写简短的对话，以便于理解。 | 在屏幕上，文本可以很长，而且可以包含多个段落。您可以跳过不感兴趣的部分。但您的用户可能并不乐意听到虚拟代理的长篇大论。 |
| 使用 SSML | 使用 SSML 来构建和更改句子的语调，让您的声音更自然。 |
如需详细了解如何针对语音进行设计，请参阅语音代理设计。
保护消费者隐私权
| 最佳做法 | 详细信息 |
|---|---|
| 在 GDPR 合规性的代理设置中停用数据日志记录。 | 在代理设置中，您可以停用 Dialogflow 中的互动日志记录。停用此功能后，Dialogflow 中不会再存储 PII 数据。这也意味着，某些功能（例如分析）将不可用。 |
| 将聊天会话数据存储在 BigQuery 中，以便控制 Regional 存储空间。 | 通过 Cloud Logging 或使用 Dialogflow API，您可以将传入的聊天话语发送到 BigQuery。使用此方法，您可以控制要存储数据的地区。此外，您还可以使用 Data Loss Prevention API 来遮盖敏感信息。请参阅用于在 GCP 上构建 AI 赋能的客户服务的蓝图。 |
使用知识库连接器
| 最佳做法 | 详情 |
|---|---|
| 导入公开的常见问题解答时，请使用有效的 HTML5 标记。 | 例如，请使用带有 schema.org 表示法的文章元素，例如 schema.org/Question 和 schema.org/Answer。 |
| 确保您的常见问题解答网站被 Google 漫游器编入索引 | 该网站需要启用 Google 机器人，并且需要通过 Google 网站站长工具添加到 Google 搜索引擎。类似于 pages.github 的网站将无法正常运行，因为此类网站无法被抓取。 |
| 使用 1-200 个常见问题解答 | 您需要多个常见问题解答对，每个知识库不超过 200 个。如需了解详情，您可以加载多个知识库。 |
实现 Dialogflow API
| 最佳做法 | 详情 |
|---|---|
| 请勿在移动设备或 Web 应用的客户端代码库中公开您的服务账号私钥。 | 该操作不安全。任何熟悉 Chrome 开发工具的人都可以窃取您的密钥，并通过您的账户进行 API 调用（付费）。更好的方法是始终让 API 代理服务器处理 Google Cloud 身份验证。这样，服务账号就不会泄露，并且密钥可以安全地存储。} |
在一个代理中设计语音和文本
| 最佳做法 | 详细信息 |
|---|---|
| 请勿在默认平台响应中使用 SSML。 | 当代理可以同时使用语音和文本进行响应时，文本响应将包含原始的 SSML 代码。在默认平台响应中使用纯文本，并在平台专用响应中使用 SSML。或者，只有在需要语音响应时，才能使用网络钩子生成 SSML。 |
测试
| 最佳做法 | 详情 |
|---|---|
| 与没有参与应用开发的人员一起对应用进行全面测试。 | 让不熟悉代理的人使用应用可让您深入了解对话流的流畅程度。请让他们注意准确性、长时间停顿、缺少对话路径、节奏、不自然的过渡等问题。 |
| 在您计划支持的所有平台上测试应用。 | 如果将在一个或多个平台上提供代理，请确保富消息和响应在所有的平台上都符合预期显示。 |
企业最佳做法
- 请参阅 Google Cloud 架构框架。