对话式人工智能高效指南-全-

对话式人工智能高效指南（全）

原文：zh.annas-archive.org/md5/d86f89acbe21f7fcef4144cfb6044073

译者：飞龙

协议：CC BY-NC-SA 4.0

第一部分 提升对话式 AI 的框架

你是否有过与聊天机器人糟糕的体验？可能是一个总是告诉你“请仔细聆听——我们的菜单选项最近已更改”的语音系统，或者是一个永远不理解你问题的聊天机器人。希望你也曾有过与 AI 的美好体验——一个似乎了解你并能主动识别你需求的 AI。是什么让好的对话式 AI 与差的 AI 区分开来？

随着公司寻求通过这项技术提升客户体验和自身盈利能力，对话式 AI 比以往任何时候都更加重要。生成式 AI 重新点燃了对这项技术的兴趣，并使得向聊天机器人添加智能变得比以往任何时候都更容易。许多这些聊天机器人在原型阶段看起来很棒，但在生产阶段却失败了。本书的这一部分为构建和改进对话式 AI 奠定了基础。

第一章介绍了对话式 AI 和生成式 AI 技术，它们的优缺点以及它们如何相互补充。它还概述了许多 AI 解决方案遇到的问题点。第二章展示了如何构建和演进聊天机器人，逐步增加复杂性和能力，最终结合传统和生成技术。第三章演示了如何客观评估你的 AI 并制定改进计划。

第一章：对话式 AI 如何运作？

本章涵盖

• 识别和最小化对话式 AI 风险

• 评估生成式 AI 如何帮助你在对话式 AI 中

• 安全使用生成式 AI

• 持续改进你的 AI 并设定明确的目标

我们都遇到过让我们感到痛苦的计算机化对话代理，例如一个不理解我们说话内容的聊天机器人、一个启动令人困惑对话流程的机器人声音，或者一个让我们立即选择转接到人类代表的电话助手。当你的对话式 AI 解决方案引起这些问题时，你该如何解决它们？你该如何从一开始就正确构建它们？这本书将向你展示如何创建聊天机器人和其他对话式 AI 解决方案，让你的客户愿意使用。

作为对话式 AI 从业者，我们与刚开始部署自动化代理执行有限任务的客户以及面临高商业风险的大型组织合作——在这些情况下，一个生成式 AI 的幻觉可能抵消数十次正确且流畅交互的好处。我们将通过从我们的工作中抽取的各种例子，展示实施和改进对话式 AI 的选项，包括和不含生成式 AI。

我们将首先简要介绍经典的对话式 AI 技术，然后介绍生成式 AI 以及我们推荐的用于安全有效地充分利用对话式 AI 的持续改进过程。然后，在第二章中，你将使用经典和生成式 AI 技术构建自己的聊天机器人。

1.1 对话式 AI 简介

对话式 AI，也称为聊天机器人、虚拟代理、AI 助手和数字员工，是一套旨在使用书面或口语自然语言模拟或替代人类交互的技术。对话式 AI 通常用于自动化客户服务、提供类似 Alexa 和 Siri 的“语音助手”服务，或预先筛选最终的人与人交互。一般来说，你可以将对话式 AI 分为三个类别：

• 问答——也称为 FAQ 机器人，这些 AI 解决方案直接对用户的问题做出回应，通常不需要任何后续操作。

• 面向流程或交易型解决方案——用户通过机器人的问题系列被引导实现某个目标；例如，检查账户余额、预约或检查保险索赔的状态。此类对话式 AI 可能执行交易或收集信息以供人工完成。

• 路由代理——在这种情况下，机器人的唯一任务是确定将用户重定向到何处。重定向可能是到另一个专门的机器人或人类代理。

一些人工智能解决方案包含所有三种混合。一个零售银行聊天机器人可能对诸如“你们什么时候营业”和“你们在哪里”等简单问题进行问答，处理开户和检查账户余额的流程，并将用户引导到专家处理诸如欺诈报告等案例。

这些类型的聊天机器人具有相似的架构，但重点不同。一个路由代理只需要理解用户的初始意图，但一个以流程为导向的机器人不仅需要理解意图，还需要在整个流程中保持用户的参与。在这本书中，我们将向您介绍几个对话式人工智能的挑战和成功案例，如表 1.1 所示。

表 1.1 我们已解决的对话式人工智能挑战

痛点	成功案例	本书
没有理解用户意图	将意图识别准确性从 76%提高到 92%	第二部分（第 4-7 章）
过多的复杂性强加给用户	搜索成功率从 40%提高到 90%	第三部分（第 8-10 章）
用户立即退出	立即退出减少了 15%	第四部分（第 11-12 章）

所有聊天机器人类型都面临着理解用户的挑战。以流程为导向的机器人尤其容易让用户负担过重，我们还发现所有聊天机器人类型都可能受到立即退出的困扰。本书的后半部分专注于具体的挑战，尽可能多地提供来自多种聊天机器人类型的例子。您可以自由地跳到您感兴趣的部分。

对话式人工智能解决方案旨在解决问题。如果它们没有解决问题，它们就会给用户带来痛苦。痛点告诉我们应该如何改进系统。但在我们能够改进现有解决方案之前，我们需要了解最初是什么动机促使解决方案的产生。

1.1.1 为什么使用对话式人工智能？

一个有效的对话式人工智能提供卓越的用户体验和好处，节省用户的时间和精力，同时节省公司的支持成本。它永远不会感到疲倦，因此可以全天候帮助用户。它是个性化的，高效的，甚至可能是主动的，引导用户实现他们的目标。

图 1.1 与一个以流程为导向的聊天机器人进行痛苦聊天体验，该机器人给用户带来了认知负担。在三个对话回合中，人工智能没有提供任何价值。

一个糟糕的对话式人工智能会起到相反的作用——它会挫败用户，降低满意度，或者因为“机器人没有理解我的需求”而使支持线变得繁忙。它让用户忍受过于冗长的信息，问他们不需要问的问题，或者对他们冷漠无礼。图 1.1 展示了一个以流程为导向的聊天机器人的痛苦聊天体验。

对话式 AI 不必痛苦，它可以提供比需要人工干预更好的、更流畅的体验。图 1.1 中的场景给用户带来了沉重的负担。从技术上讲，对话流程是合理的——用户可以询问任何声明。也许用户不是在询问他们自己的声明。但这忽略了普遍情况——大多数用户是在询问他们自己的声明。大多数用户可以被识别——通过他们登录的电子邮件地址识别聊天用户，或通过他们的电话号码识别语音用户。图 1.2 展示了使用这些合理的假设以用户为中心的方式快速解决同一索赔状态问题的方法。这些假设也个性化了体验。这个系统提供的答案比人类更快！

图 1.2 使用上下文和合理的假设快速完成用户目标的愉悦体验。上下文可以从登录过程（聊天）或呼叫者的电话号码（语音）中加载。

有时可以通过改进流程来修复面向过程的机器人。记住，聊天机器人不仅仅是技术问题。聊天机器人与人互动，而人往往是混乱的。仅靠技术无法解决所有聊天机器人的体验问题。

在看到过好的和坏的聊天体验之后，让我们回顾一下对话式 AI 是如何工作的。

1.1.2 对话式 AI 是如何工作的？

对话式 AI 解决方案通常包括三个步骤：

1. 确定用户想要什么。

2. 收集满足该需求所需的信息。

3. 给用户提供他们想要的东西。

解决方案应尽可能快速、轻松地实现这些目标，同时遵循法律和道德规范，例如安全处理敏感信息，并不要假装 AI 是真人。如果 AI 解决方案无法实现这些目标，或者给过程带来太多摩擦，用户将放弃 AI 并寻找其他解决方案。这可能意味着去找能帮助他们的人，或者放弃你的服务。

图 1.3 展示了对话式 AI 解决方案的高级流程，这些步骤由图 1.4 所示的架构支持，该架构基于面向过程的机器人“重置密码”场景进行标注。

图 1.3 对话式 AI 流程图。在许多用例中，“附加信息”包括用户配置文件数据。

图 1.4 带有密码重置示例的对话式 AI 逻辑架构标注

让我们详细说明这三个主要步骤：

• 确定用户想要什么——用户通常以自然语言提出他们的请求，因此自然语言理解模块接收这条消息并确定其背后的意图。这通常是通过机器学习算法完成的，例如文本分类器。示例意图包括“重置密码”或“查找商店”。意图驱动着流程中的下一步。

• 收集满足这些需求所需的信息—用户的初始请求通常不包含足够的信息来满足它——请求只是开始了一段旅程。对话引擎引导用户完成满足请求所需的所有步骤。它可能需要询问澄清或后续问题，如“您的账户号码是什么”或“您的邮政编码是多少”。它可能使用编排层通过应用程序编程接口（API）调用与其他系统交互。对话引擎管理会话状态并应用逻辑来响应用户。

• 提供用户所需的内容—当用户的请求得到满足时，流程结束。他们的密码已被重置，或者他们收到了您商店的地址，或者他们已经连接到能够满足他们需求的人。

在不同类型的机器人中，这些步骤可能会有细微的差别。例如，一个问答机器人很少使用 API，但一个以流程为导向的机器人经常使用。路由代理只是间接地提供给用户他们想要的内容（通过将用户路由到正确的专家）。

1.1.3 如何构建对话式人工智能

建立对话式人工智能解决方案最好是在团队中涉及一系列多样化的技能，如图 1.5 所示。如果您试图改进这些解决方案，了解这些解决方案是如何构建的很重要。在本节中，我们将总结构建过程。对于更完整的处理，请参阅对话式人工智能（Manning Publications，2021）。

图 1.5 建立一个企业级对话式人工智能需要一支拥有多种技能的梦幻团队。

对话式人工智能的起点是用户设计。看看您的用户想要实现什么，以及您如何帮助他们快速且无摩擦地实现这些目标。图 1.5 中的所有参与者都应贡献于这些以用户为中心的问题：

• 您的用户最常见的问题是什么？

• 他们需要做什么？

• 他们可能拥有哪些信息？（以及他们可能不拥有哪些信息？）

• 他们可能如何表达他们的需求？

一旦你知道用户需要什么，思考你需要什么来满足用户。例如，假设您的用户经常被锁在账户外面。他们需要一个密码重置功能。你需要做什么来重置密码？通常，你需要至少做三件事来重置密码：

• 从用户陈述中提取意义（确定他们有一个密码问题，即使他们没有使用特定的术语，如“密码”或“重置”）。

• 访问一个可以验证用户并重置密码的 API。

• 收集足够关于用户的信息以重置他们的密码。

这些需求推动了你构建过程的其余部分。

提取意义

聊天机器人首先从用户那里提取意义，通过文本分类器从用户的自然语言表述中识别意图。表述是用户说的话，意图是它的含义（即，用户想要什么），而分类器将表述分类到意图中。

聊天机器人平台正变得越来越容易使用，趋势是低代码或无代码，但这并不意味着它们将在没有人类参与的情况下理解您的需求。最好让数据科学家优化代表性强、平衡性和多样性的训练数据，并执行测试以确保训练的分类器尽可能准确。如果这没有做好，它将导致“机器人不理解我”的痛点，因为 AI 通常被编程为将未识别的表述路由到通用响应。

此训练过程最佳输入数据来自之前的用户交互，例如历史聊天记录、呼叫中心记录或电子邮件。本书的第二部分涵盖了收集良好数据以及如何使用它来改进意图识别。

使用 API

开发者需要向虚拟助手公开 API。他们需要明确定义所需的输入参数、输出响应格式和错误条件，以便清楚如何将 API 集成到聊天机器人中。API 公开的功能可以用任何编程语言实现——重要的是要有助手可以安全访问的 API 端点。

如果 API 不存在，您的聊天机器人项目可能是构建它的完美理由。或者，聊天机器人的设计可能需要更改 API。API 对于将结构化信息传递给用户（检查他们的账户余额、查找他们的开放索赔）或代表用户操作（重置他们的密码、开设账户）很有用——如果没有合适的 API，您可能无法满足用户的需求。

API 通常用于面向过程的机器人，但它们对于向问答和路由代理提供额外的用户上下文也很有帮助。

收集更多信息

您需要一个会话流程，以获取调用 API 或回答用户初始问题的必要信息。这将受到您正在构建的渠道（如网页或电话）以及您合理期望用户拥有的信息的影响。例如，在网页上的密码重置场景中，通常需要询问安全问题。但是，通过电话收集这些信息可能很困难，通过短信收集信息也不安全。相比之下，电话和短信渠道可能能够使用用户的电话号码作为认证谜题的一部分。

可用的 API 可能会影响对话设计，或者对话设计可能会影响 API，或者它们可能相互影响。如果收集更多信息的过程对用户变得困难，那么当用户了解到他们可能无法成功使用助手时，可能会导致“过于复杂”或“立即退订”的痛点。

值得注意的是，并非每个对话式 AI 都需要我们讨论的这三件事：

• 一些 API 可能不需要额外的信息。例如，一个“商店营业时间”API 无论谁询问都会返回相同的响应。

• 常见问题解答（FAQ）机器人可能根本不需要调用任何 API，只需将用户的表述与意图/响应对进行匹配即可。

• 一个回退到搜索的机器人可能甚至不包含任何意图。这是使用生成式 AI 构建的对话式搜索解决方案的流行模式，无论是使用大型语言模型（LLM）的内置知识，还是通过搜索知识库并从搜索结果中生成答案来补充 LLM。这种模式也可以构建为混合模型，其中为最常见的问题构建意图，所有其他问题都路由到搜索或生成式 AI。

练习

1. 回顾你最近互动过的几个聊天机器人（或者你自己构建的）。它们是问答型、流程型还是路由代理？为什么？

2. 这些聊天机器人各自面临了哪些挑战？你希望它们如何表现得更好？

1.2 对话式 AI 中生成式 AI 的介绍

任何足够先进的技术都和魔法无法区分。——亚瑟·C·克拉克

生成式 AI（一种动态生成新内容的方法）是一项令人兴奋的新技术。你可能已经看到它做了些酷炫的技巧：“写一首莎士比亚式的十四行诗”、“描述 AI 但说话像海盗”或“为我制定一个合法赚取 100 美元的计划。”但它不是魔法，也不是万能的。生成式 AI 可以帮助你获得好处，但你还需要努力避免像幻觉这样的有害结果。

生成式 AI 可以帮助我们解决对话式 AI 解决方案中的几个痛点：

• 未理解用户意图—生成式 AI 可以帮助我们在对话式 AI 中训练更强的意图。或者，它可以通过检索增强生成（RAG）来替代部分或全部意图识别，通过总结来自搜索（检索）过程的内容。它还可以更适应用户意图的细微差别。

• 给用户施加过多复杂性—生成式 AI 可以帮助我们在对话或测试系统时写出更简单的散文。

• 用户立即退订—生成式 AI 可以帮助我们写出更吸引人的散文，同时也有助于我们的用户。

我们可以在对话式 AI 中使用生成式 AI，让它直接通过回答用户的问题或搜索信息来帮助我们的用户。我们还可以使用生成式 AI 来帮助我们构建对话式 AI，例如使用它来构建更好的对话流程和消息，并分析之前的对话。生成式 AI 不是经典对话式 AI 技术的替代品——它们最好一起使用。

1.2.1 什么是生成式 AI

生成式 AI是一个总称，指的是由基础模型驱动的 AI，这些基础模型是在一系列广泛的任务上训练的通用 AI 模型。虽然存在几种基础模型，但本书重点介绍 LLMs——在巨大的文本数据集上训练的机器学习模型。有多大？用“互联网上的所有文本”作为您的心理模型。

看过“互联网上的所有文本”的模型应该非常擅长理解单词和句子序列。该模型被训练接收一系列单词并预测一个可能跟随前一个单词的单词。通过重复预测下一个单词的过程，LLMs 可以生成单词、句子、段落，甚至整页的文本！

您可以在您的对话式 AI 系统中使用 LLMs。LLMs 可以执行直接面向用户的任务，或者执行帮助您构建对话式 AI 的任务。表 1.2 列出了这些任务中的几个。

表 1.2 对话式 AI 构建者可以快速高效使用 LLMs 的示例任务

消费者面向的任务	构建助手任务

| 生成答案（来自检索增强生成） | 概括对话记录

| 编辑或编写对话和流程 | 增强您的训练数据

|

LLMs 可以在几乎没有训练的情况下执行这些任务，并加快您的开发过程，并且对用户问题的微小变化具有弹性，这些变化传统分类器可能无法理解。但它们也伴随着潜在的危险：

• LLMs 从它们的训练数据中学习。您是否曾在互联网上？互联网充满了偏见、仇恨言论和错误信息。检索增强生成是一种生成答案的好方法，因为它将 LLMs 的输出基于您的文档，而不是使用 LLMs 的内部数据（通常是在互联网内容上训练的）。

• LLMs 不知道它们的回答是否真实，只知道这些回答是它们“提示”的可能的扩展。这是幻觉的基础——看起来不错但无用的回答。您永远不知道 LLMs 可能会说什么。这就是为什么将它们用作对话写作助手是极好的，因为您可以在使用之前审查它们的输出。

LLM 们会毫无顾忌地欺骗您。或者它们会在几秒钟内生成比专家水平更好的回答。LLMs 可以表现出惊人的创造力或令人恐惧的偏见——互联网上两者都有！要在您的对话式 AI 解决方案中自信地使用 LLMs，您需要设置一些安全措施。

1.2.2 生成式 AI 的护栏

我们的第一道防线在于模型的选择。大多数从业者选择使用现有的模型，而不是自己构建。这是因为训练一个全新的 LLM 可能需要数百万美元，并且耗时数月。

预过滤输入以防止仇恨、辱骂和粗俗语言

上下文指令和提示

我们下一个安全栏是通过对 LLM（大型语言模型）提供的提示指令。图 1.6 展示了有效上下文在引导 LLM 方面的作用。

图 1.6 在提示中添加上下文是引导一个大型语言模型的重要方式。

上下文使大型语言模型（LLM）不必使用其自身的（过时）数据，并减少了幻觉发生的可能性。检索增强生成（第六章）提供了来自您信任的文档的上下文。上下文还可以用来为 LLM 分配一个角色，例如“你是一位友好的校对编辑”，这对于修订内容草稿（第十章）非常有用。

为 LLM 提供上下文是一种强大的技术。

后处理输出

与预过滤选项类似，你还可以扫描 LLM 的输出以查找某些内容。例如，你可以扫描关键词或其他仇恨、滥用和亵渎（HAP）的迹象。库可以帮助你完成这项工作——一个例子是位于 pypi.org 的亵渎检查库（pypi.org/project/profanity-check/)。

对于某些用例，你还可以将答案与提示的部分内容进行比较。在检索增强生成中，LLM 应该只回答由搜索过程检索到的文档中的问题。你可以进行文本相似性分析，以查看大部分或所有答案文本是否出现在使用的文档中。

人工介入

最安全的选项是永远不要让 LLM 自由发挥。有人工“介入”可以确保你知道你的 LLM 在做什么。这有两种版本：反向审查和事先审查。

反向审查意味着你定期监控 LLM 提供的响应。例如，你可能有一个每周流程，审查 LLM 输入和输出的样本。这不能防止不良结果发生，但至少你会知道已经发生了，并且你可以调整 LLM。

相比之下，事先审查意味着你使用 LLM 来协助人类，而人类有最终决定权。一个例子是将 LLM 用作校对编辑——它生成静态对话消息，由人类插入到对话引擎中。

以这种方式使用大型语言模型（LLM）可以通过生成训练数据来解决“未理解用户意图”和重写对话以减少“对话流程过于复杂（或粗鲁）”等问题，从而帮助减少用户体验痛点。

1.2.3 在对话 AI 中有效使用生成式 AI

有效使用生成式 AI 的两个基本要求是使用适合工作的正确模型，并通过应用适当的限制措施来降低风险。

适合工作的正确模型（和参数）

有数千个 LLM，它们被训练在不同的任务上。你可以通过实验提示和参数来细化 LLM 在这些任务上的行为。图 1.7 展示了“重复惩罚”参数对 Flan-ul2 模型在创意任务上的影响。不同的任务需要不同的参数。当使用你提供的文档中的文本时，低重复惩罚是有用的。在创意任务如列表生成中，高重复惩罚是有帮助的。

图 1.7 改变一个 LLM 参数（重复惩罚）的影响

在这本书中，我们将使用几个不同的模型和参数集来展示各种技术。我们希望表明我们的技术具有广泛的应用性。你可能不会在本文中看到你选择的模型被引用，你可能需要在你的用例中使用不同的提示、参数或模型。在你阅读这本书的时候，可能已经有一套全新的模型可供使用！

对于每个任务，你可能还想尝试多个模型。例如，Flan-UL2 是一个在包括问答和信息检索在内的 50 个任务上训练的 LLM（huggingface.co/google/flan-ul2）—它是一个通用模型。MPT-7B-Instruct 是一个专注于单一任务的 LLM—短形式指令遵循（huggingface.co/mosaicml/mpt-7b-instruct）。模型也有不同的成本概况和性能特征。你可能在选择适合你任务的正确模型之前会尝试几个不同的模型。你可能在同一解决方案内为不同的任务选择不同的模型。表 1.3 包括了一些关于选择 LLM 的“应该做”和“不应该做”的事项。

表 1.3 LLM 的“应该做”和“不应该做”事项

不要	不要做	为什么
不要仅仅因为你在某个任务上看到它表现良好（而你不需要这个任务）就使用该模型。	选择适合你任务的模型，或者尝试几个这样的模型。	性能取决于任务，包括任何参数或提示工程。任务包括生成、分类、提取、问答、检索增强生成、摘要和翻译。
不要因为一次失败的实验就放弃一个模型或提示。	在多个输入、模型和参数上进行测试。	有时你会运气不佳。需要多次测试才能对 LLM 配置有信心。
不要盲目让 LLM 完全控制，尤其是在回应你的对话式 AI 用户时。	在多个级别上应用护栏。	你（或你的组织）拥有最终输出。“LLM 说了这样”不是借口。

“LLM 说了这样”并不是一个合理的借口

2024 年，一家加拿大航空公司的聊天机器人提供了一项不存在的折扣。在法庭上，他们辩称聊天机器人是一个“独立的法律实体，对自己的行为负责。”法院不同意。公司被命令支付聊天机器人提供的折扣。（参见 BBC 网站上的故事：mng.bz/GejV。）

在每一步都应用适当的护栏

确保你在使用 LLM 的所有阶段都考虑到了护栏：

• 在...之前—选择一个适合你目的的 LLM，其数据集与你的价值观相符。决定 LLM 将有多少自由和监管—它能否从头到尾执行任务，还是所有输出都需要由人类审查？

• 在...期间—实验性地使用 LLM，调整和适应它以完成你的任务，并验证任何内容控制的功效。

• 在...之后—定期评估 LLM 的过往表现，并确保它仍然满足你的业务需求。

考虑 LLM 的最坏结果，并确保你有应对策略。例如，在问答中，你可能最担心 LLM 会编造没有现实基础的答案（幻觉）。你可以通过分配上下文界限或持续审查 LLM 的响应来减轻这一点。

练习

1. 想想你在上一组练习中提到的聊天机器人。它们如何能够通过生成式 AI 得到改进？

2. 对于生成式 AI 的每个用途，你将如何安全地使用它？对于每个用例，幻觉是一个问题吗？你需要担心仇恨、滥用和亵渎吗？

1.3 在对话式 AI 中引入持续改进

软件就像熵。它难以把握，毫无重量，并遵循热力学第二定律；即，它总是增加。——诺曼·拉尔夫·奥古斯丁

“熵”广义上意味着不断趋向混乱。——西德·斯里兰姆

软件永远不会第一次就完美无缺。需求没有得到完美的理解，需求发生变化，或者用户反馈推动软件的改变。AI 软件也不例外。没有改进，AI 软件很可能会滑向衰退。

1.3.1 为什么需要持续改进

即使我们将对话式 AI 调整得完美无缺以适应当今时代，我们的需求也会发生变化：

• 用户将提出新的请求并以不同的方式使用软件。

• 您的业务将会有满足流程的新规则。

• 生成式 AI 等技术将使曾经不可能的事情成为可能。

• 将会有更先进且性能更好的 AI 模型可用。

对话式 AI 有几个组成部分，包括理解用户的初始意图，根据需要收集更多信息，并完成用户的需求。这些组成部分中的每一个都可能会随着时间的推移而改变，需要持续改进。这些组成部分的任何退化都会增加用户的挫败感并降低业务成果。

就像链条一样，对话式 AI 解决方案的强度仅取决于其最薄弱的环节。也许我们有一个很好的流程来向用户展示信息，但我们从未达到它，因为我们很少理解他们的初始意图。图 1.8 显示了一个以流程为导向的机器人转换漏斗，展示了到达每个步骤的相对用户数量。

图 1.8 在流程中的累积成功依赖于每个单独步骤的成功。从视觉上看，它就像在每个步骤之后变窄的漏斗。

成功是多方面的。为了让用户得到他们想要的，我们需要

• 吸引他们（A）

• 理解他们（B）

• 展示他们所需的一切（C）

我们可以将任何流程中的成功视为 A 乘以 B 乘以 C。如果我们看到我们的成功率不是我们想要的，我们需要调查成功链中的每个组成部分。很可能我们可以找到改进每个部分的方法。我们甚至可以使用这个框架来思考问答机器人，每个后续问题都是流程中的下一步。第三章将扩展这个框架。

再次强调，流程中的失败可能不仅仅通过技术来解决。生成式人工智能仍然可能误解用户，仍然可能给出错误的答案。需要一些手动工作来识别改进区域并执行改进工作。持续和渐进的改进方法增加了你成功的机会。

1.3.2 持续改进周期

对于任何给定的挑战，完美的解决方案可能并不明显，甚至可能不可能。这在人工智能领域尤其如此，因为可能性每天都在变化，变化可能产生意外的副作用。因此，通过一系列的小变化来改进你的对话人工智能是很重要的。在第三章中，我们将向你展示如何估计每次变化的影响。现在，认识到一个变化可能会带来小的改进，大的改进，或者可能会使事情变得更糟！每次变化都会产生额外的学习机会。

图 1.9 展示了适用于任何聊天机器人的典型持续改进周期。

图 1.9 对话人工智能的持续改进生命周期

典型的持续改进周期包括以下内容：

• 测量—在做出改变之前，你需要有一个系统性能的基线。

• 识别问题—找出错误、损坏或非最优化的东西。理想情况下，这个问题将直接与业务指标相关联。例如，“当我们<条件>时，我们注意到很多电话转接到客服。”

• 实施—假设问题重要到需要解决，实施一个解决问题的方案。例如，更新意图训练或编辑你的对话。

• 部署—实施变化并记录对原始问题的影响。

• 重复—根据需要重复。如果变化是成功的，恭喜你，如果不成功，你可以撤销变化。继续下一个问题，或者迭代改进相同的问题。

我们更喜欢小而可预测的变化，而不是大而不可预测的变化。为了减少“机器人不理解用户”，我们更喜欢只更改表现最差的单一意图（请求类型），而不是一次性更改许多（或所有）意图。对于面向流程的低完成率，我们更喜欢一次更改一个步骤，而不是更改或重新排列许多步骤。

图 1.10 展示了对一个系统进行重大变更的例子。由于变更很大，它需要很长时间才能部署到生产环境中，并且会有各种各样的结果。它可能带来巨大的利益，小的利益，或者小的损害。我们只有在将这个重大变更部署之后才会知道。这种方法风险很大——如果变更出现问题，你将如何向利益相关者解释？“我们花了很长时间进行这个变更，出乎我们的意料，我们使事情变得更糟。我们不确定是变更的哪个部分导致了这种情况，所以我们将不得不撤销一切并重新开始。”天哪！这比大多数人愿意承担的风险要大。

图 1.10 大变更——如重新训练所有意图——需要很长时间，并且结果不太可预测。

与图 1.11 进行对比。在这里，我们不是进行一次主要变更，而是进行四次小变更。每个变更都有相同的可能结果（非常好，稍微好一些，或者更差），但规模较小。这种方法有几个好处：

• 每个变更都更容易理解——如果我们只改变一件事，将结果与变更联系起来就更容易。较小的变更也更易于调试。

• 更多学习机会——我们不是只有一次学习的机会，我们有四次。

• 更多选择——通过较小的变更和较小的风险，如果我们达到目标，我们可以更早地停止。

图 1.11 进行许多小的变更——如一次重新训练一个意图——每个变更的“爆炸区”较小，带来更快的价值和更多的学习。

在图 1.11 中，我们可能已经决定前两个变更已经足够。我们可以停止在这个适度改进上。第三个变更使系统变得更差，但由于它是一个小变更，所以很容易撤销。我们学到了很多，而且很快。

最令人兴奋的是，增量变更方法让我们能够更早地锁定改进（和商业价值）！让我们将图表转换为捕捉商业价值。较小的变更和较快的变更在“大爆炸”变更完成之前就带来了积极的变化。这将使我们的利益相关者和用户都感到高兴。

使用持续改进和小的变更，我们要么会得到一个小的改进，快速产生商业价值，要么是一个小的性能下降，我们可以轻松地撤销并从中学习。图 1.12 展示了频繁的小变更如何快速产生价值。

图 1.12 虚线以上的区域是相对于“大爆炸”变化的额外商业价值。在生产环境中运行的代码能够产生价值。

更好的 AI 性能应该会为您的利益相关者带来更好的商业价值。但您如何以他们能够理解的方式传达这种增值？

1.3.3 向利益相关者传达持续改进

成功人工智能解决方案的定义各不相同，但你可能正在使用以下标准成功指标之一：

• 成本降低—通过控制或平均处理时间来衡量。（完成通话而不涉及任何人工，或帮助人工更快地工作。）

• 客户满意度—通过净推荐者分数（NPS）调查、解决时间或减少客户流失率来衡量。

你的利益相关者投资于对话式 AI 以实现业务成果，因此你应该将你的 AI 解决方案与该成果进行衡量。检查你的当前表现和表现趋势，以确保你在改进（或者至少没有变得更糟）。你解决方案不断变化的需求意味着你一直在与熵作斗争。有时，你只需要不断改进，以保持当前的成功水平。

在这本书中，你将学习到提高你的 AI 解决方案的几种技术，其中一些将是高度技术性的。你可能很兴奋地想尝试这些技术，但你可能需要说服你的利益相关者支付改进的费用。使用他们的语言说话至关重要：减少技术术语，增加商业价值！

考虑以下描述“机器人不理解用户”的修复示例：

• 技术术语繁重—“我们将提高#claim_status意图的准确性。分类器以 0.92 的 F1 分数识别这个意图，大部分混淆来自#claim_submission和#auth_status。”

• 专注于商业价值—“我们将通过更准确地识别索赔状态呼叫来提高控制率、提高用户满意度和减少错误的呼叫路由。这是我们最受欢迎的呼叫类型。准确性问题会让用户感到沮丧，因为他们不得不重复自己，导致退出率增加。此外，误解的呼叫者可能会被路由到错误的人工客服，增加我们的成本。这个问题也会降低用户满意度。”

技术细节非常适合放入你的技术待办事项列表中，但对于只对它对他们意味着什么的利益相关者来说，这只是行话。

我们建议将你的改进工作分类，使其与业务目标一致。你也可以添加技术分类以方便管理你的待办事项列表——每个人都应该知道你待办事项列表中工作的商业影响。表 1.4 将改进对话式 AI 的通用原因与特定的业务指标相连接。

表 1.4 将改进原因与业务指标对齐

改进原因	业务指标	描述
成本降低	控制	减少转接到人工的通话数量。这主要适用于面向流程的机器人。
成本降低	平均处理时间	通过增加 AI 中的生产力工作来减少人工花费的时间。例如，如果 AI 验证了呼叫者，人工客服就不需要了。这主要适用于面向流程的机器人。
成本降低	人工接触	减少接触电话的人数。（当电话被错误路由到不正确的人时，会增加。）这主要是针对路由代理的。
用户满意度	净推荐者得分（NPS）	改善售后服务调查结果。
用户满意度	解决时间	减少从首次接触到问题解决的时间量。
合规性	N/A	必须遵守的约束，否则将面临严重处罚。这是业务成本的一部分。

注意，一些改进可能会影响多个业务指标，如表 1.5 所示。

表 1.5 技术改进可能会影响多个业务指标。

技术改进	受影响的业务指标

| 提高意图识别准确性 | 提高控制率（呼叫者不会因挫败感而放弃）提高人工接触（路由时，转到正确的人） |

改善平均处理时间

改善解决时间（从减少重试次数）

可能提高 NPS（从减少重试次数）

|

| 澄清一个令人困惑的问题 | 提高控制率（呼叫者不会因挫败感而放弃）提高解决时间（从减少重试次数） |

|

| 缩短冗长的信息 | 改善解决时间 | 改善 NPS

|

注意：一些业务目标可能相互矛盾。例如，一家医疗保险公司提高了“索赔拒绝原因”意图的准确性。呼叫者以前会立即转接，因为 AI 没有识别出意图；因此，他们不会在 AI 完成任务时进行电话后的调查。在意图准确性提高后，呼叫者可以自助服务并发现他们的索赔被拒绝。这提高了控制率，但现在那些不满意的呼叫者会进行调查以投诉，导致该保险公司的助手 NPS 下降。

练习

1. 考虑其他技术改进，例如“减少流程复杂性”、“缩短对话”和“减少摩擦点”。它们会影响哪些业务目标？

2. 你会如何逐步解决这些改进领域？

1.4 跟随

在本书中，我们将使用两种类型的软件平台演示对话式 AI 实践。我们使用的技巧适用于许多不同的平台：

• 对话式 AI 平台——一个核心软件平台，提供对话式 AI 功能，如自然语言理解和对话管理。有许多选择，如 Amazon Lex、Google Dialogflow、Microsoft Azure AI Bot 和 Rasa，仅举几例。我们是 IBM watsonx Assistant 的专家，并在本书中使用它。

• 生成式 AI 模型平台——一种提供一个或多个 LLM（语言模型）的服务，您可以通过 API 与之交互。流行的选择包括 Anthropic、ChatGPT、Gemini、Hugging Face 和 Ollama。在我们的日常工作中，我们使用 IBM watsonx.ai 及其 Prompt Lab，并使用它来构建和测试本书中的提示。

为什么选择商业云平台？

安装 AI 应用的先决软件可能具有挑战性。LLMs 通常资源密集。使用商业云平台可以让你快速开始，并专注于构建对话式 AI 和生成式 AI。

本书描述的技术在多种对话式 AI 和生成式 AI 平台上具有广泛的应用性。在适当的情况下，我们将指出任何术语差异。有许多优秀的选择——你可以使用你感到舒适的科技平台，或者探索一个新的平台！

摘要

• 对话式 AI 必须以用户体验为出发点。好的对话式 AI 能帮助用户快速完成任务。差的对话式 AI 会令用户感到沮丧。

• 有成千上万的生成式 AI 模型。大型语言模型（LLMs）是擅长生成文本的生成式 AI 模型的一个子类型。

• LLMs 可以执行许多任务，并表现出令人印象深刻的效果，但也存在显著的风险，包括幻觉。要有效地和负责任地使用 LLMs，需要深思熟虑的指导和限制措施。

• LLM 技术可以补充对话式 AI。LLMs 可以直接响应用户，并帮助你构建你的对话式 AI。

• 持续改进对于有效的对话式 AI 是可能且必要的。

• 逐步改进可以以较低的风险带来更高的商业价值。

第二章：构建对话式人工智能

本章涵盖

• 构建 FAQ 对话式人工智能

• 构建面向流程的对话式人工智能

• 在你的对话式人工智能中使用生成式人工智能

在生产中，对话式人工智能可能相当复杂，在本书中，我们将涵盖许多解决你在构建和部署自己的解决方案时面临的现实世界问题的技术。在本章中，我们将构建蛋糕机器人（Cake Bot），这是一个包含几种不同类型对话式人工智能元素的对话式人工智能解决方案。这将为我们理解对话式人工智能结构提供一个坚实的基础。

我们将跟随一家虚构的美国俄亥俄州小面包店——蛋糕店。这家公司制作定制蛋糕，并接受送货或自取订单。他们想在网站上添加一个对话式人工智能解决方案来帮助他们的客户。由于他们以前从未构建过机器人，他们打算从小规模开始，但希望快速扩大解决方案的范围和能力。他们决定从回答他们最常问的问题的人工智能解决方案开始。

本章中的许多任务可以使用大型语言模型完成。然而，这个面包店非常谨慎。他们特别希望控制对几种问题类型给出的回答措辞。因此，他们的解决方案将结合传统和生成式技术。

我们将使用对话式人工智能平台（IBM 的 watsonx Assistant）来演示构建过程，稍后我们将整合一个生成式人工智能平台（IBM 的 watsonx.ai）。我们展示的关键概念适用于许多不同的 AI 平台。你可以轻松地使用你选择的对话式人工智能和生成式人工智能平台。

2.1 构建 FAQ 机器人

大多数对话式人工智能构建者都是从问题-回答机器人开始的。也称为 FAQ 机器人，这些 AI 解决方案直接对用户的提问给出回答，通常不需要后续问题。用户提问，机器人返回答案，当用户完成提问时，对话结束。这些机器人在只有少数（经常问的）问题时特别有效。

在本节中，我们将为蛋糕店构建一个常见问题解答（FAQ）机器人。有些问题将有静态回答，无论问题如何提出，回答都将相同。其他问题将有动态回答，根据问题中的信息而变化。但在我们对任何问题-回答进行训练之前，我们首先将建立一些基本框架。

2.1.1 FAQ 机器人基础

每个对话式人工智能都需要能够开始对话并在不知道如何行动时做出反应。大多数对话式人工智能平台在创建新的聊天机器人时默认提供这种功能。快速检查这些配置并根据您的需求进行调整是值得的。

蛋糕店开始构建他们的对话式人工智能（“助手”），并将其命名为“蛋糕机器人”。从对话式人工智能的主菜单中，他们的开发者导航到“动作”，列出了所有助手的技能。第一个列表标题为“由您创建”，为空；第二个列表标题为“由助手设置”，列出了默认技能，如表 2.1 所示。

表 2.1 新助手的默认技能

技能	执行时
欢迎客户	助手首次打开或互动。打开助手开始对话。
无匹配动作	无法匹配到用户的消息（消息不被理解）。其他平台可能称之为“回退意图”。
触发词检测	检测到侮辱性关键词等。
回退	用户需要离开聊天机器人。

第一个功能是最重要的，因为它给了我们第一次定制助手的机会。默认文本是“欢迎，我能帮您什么？”蛋糕店团队将此文本更改为“欢迎来到蛋糕机器人。我能帮您什么？”这是一个最低程度的定制——最好包括额外的信息，比如机器人能为用户做什么。然而，机器人目前还没有任何功能，所以蛋糕店团队保留了这个信息不变。

接下来，应该审查“无匹配动作”动作。当机器人不理解用户时，将调用此动作。由于机器人还没有接受训练，因此此动作将是针对任何用户输入的默认响应。默认配置如图 2.1 所示。

图 2.1 助手中“无匹配动作”的默认配置

此配置总结如下：

1. 动作计数器统计在对话中调用的次数。

2. 如果三次或更少，响应是“恐怕我不理解。请重新措辞您的问题。”

3. 如果四次或更多，它将转向回退程序。（默认回退程序是提供人工代理。）

蛋糕店团队决定通过将 3 改为 1 来降低这个阈值。这样，他们的用户就不会陷入困境。

回退动作和连接到人工代理

大多数对话式人工智能平台都有无代码和低代码集成，可以通过聊天或语音将用户连接到人工代理。我们不会深入探讨这一点，因为细节是平台特定的。只需说，这是一个常见的模式。为了本章的目的，我们将专注于对话设计和人工智能训练。

到目前为止，我们有一个聊天机器人，它能做三件事：

1. 当用户打开聊天时，他们会收到“欢迎来到蛋糕机器人。我能帮您什么？”的问候。

2. 无论他们接下来说什么，聊天机器人都会回应说它不理解。

3. 之后无论他们说什么，聊天机器人都会提供人工代理。

无聊！让我们训练这个机器人来正确回答一些问题。

2.1.2 静态问答

让我们从聊天机器人组件的心理模型开始，这些组件参与回答问题。

在某些平台上，你可以直接将问题连接到答案。在其他平台上，引入了一个额外的层来将类似的问题分类到称为 intents 的组中。基于意图的问答系统让构建者完全控制由对话人工智能生成的响应。图 2.2 展示了这种设计的通用版本，以 Cake Bot 为例。

图 2.2 问答机器人将用户的 Utterance 映射到意图，这些意图映射到答案。

让我们回顾一下这个图中的术语：

• Utterance—这是提供给聊天机器人的输入。对于一个问答机器人，这些是问题。

• Intent—这是具有相似意义的 Utterance 的逻辑分组。

• Response—这是聊天机器人的输出。对于一个问答机器人，这些是答案。

对于你的第一个聊天机器人，意图可以节省很多时间。注意，作为一个构建者，你不需要区分意义相似的提问。“你什么时候开门？”和“你的营业时间是什么？”都与你的商店的营业时间有关。对于机器人来说，区分这些并不是关键。我们通过 #store_hours 意图给它们相同的“意义”。“你卖什么蛋糕？”有不同的意义，因此有不同的 #cake_options 意图。

对于你的机器人服务的每个意图，机器人都会用示例 Utterance 进行训练。现代基于意图的系统每个意图只需要五个示例 Utterance。这不是一个糟糕的权衡；询问商店营业时间有几乎无限种方式，通过提供一些示例，你可以很好地训练你的机器人。

基于意图的问答系统既是祝福又是诅咒：对于每个你训练的意图，你可以控制响应，这既提供了优点也带来了缺点。

优点：

• 你对响应有完全的设计控制权。你可以编辑它，格式化文本，甚至包括图形元素。你知道响应的确切内容。

• 对于少数意图，这可以快速完成。你可以在不到一个小时的时间内设置你的第一个聊天机器人。

缺点：

• 随着意图数量的增加，训练机器人识别所有这些意图变得更加困难。

• 响应不会适应用户问题的细微差别。对于“你今天开门吗？”这个问题，机器人仍然以通用的方式响应：“我们每天都开门。”

• 不准确或未调优的响应会给用户带来“聊天机器人不理解”的痛苦感觉。

我们将在接下来的几章中解决这些问题问答机器人的几个缺点：如何收集正确的数据来训练你的机器人（第四章），如何使用这些数据来训练更强的意图（第五章），如何通过文档和生成式人工智能的答案来补充这些意图（第六章），以及如何使用生成式人工智能进行更多训练和测试任务（第七章）。

让我们先从训练聊天机器人的第一个问答能力开始。对于每一个，我们需要一个用户意图，一组相关的用户表述，以及一个响应。我们将定义的第一组问题和答案将涵盖蛋糕店的背景，店铺的营业时间，提供的蛋糕种类，蛋糕的大致价格，以及他们的蛋糕俱乐部信息。这些基于意图的问答响应显示在表 2.2 中。

表 2.2 初始 FAQ 意图集，包括相关的表述和响应

意图	示例表述	响应

| #background | 介绍一下蛋糕店，你的业务背景是什么？

蛋糕店历史

由蛋糕奶奶于 1980 年创立，我们为当地居民制作了超过 10,000 个蛋糕！

| #store_hours | 店铺营业时间，你的店铺营业时间是什么时候？

你们什么时候开门？

我们周一至周五营业，上午 9:00 至晚上 9:00。

| #cake_options | 蛋糕选项，你们制作婚礼蛋糕吗？

你们卖什么种类的蛋糕？

我们提供多种场合的蛋糕，如婚礼、生日、周年纪念日、退休和通用场合蛋糕。

| #cost | 蛋糕的价格是多少？有最低订单金额吗？

配送是否有额外费用？

我们蛋糕的价格通常在 30 美元左右，加上 5 美元的配送费。

| #cake_club | 蛋糕俱乐部奖励

有任何特别促销或折扣吗？

我们的蛋糕俱乐部奖励计划，每购买十个蛋糕，你将获得 10 美元的礼品券。

在助手中，我们定义了一个检测意图并给出响应的动作——问答动作。这是我们可以在任何对话 AI 平台上定义的最简单类型的动作。图 2.3 显示了开始此动作定义的用户界面。

图 2.3 创建我们第一个动作的用户界面

对于这些动作中的每一个，我们需要配置它们如何开始（用户的表述）以及它们做什么（用答案进行响应）。你会注意到这些是表 2.2 中最右侧的列。一些对话 AI 平台也使用动作的意图标签；我们的标签基于触发它的用户表述之一。我们在图 2.4 中开始定义触发#background动作的表述之旅。

注意，用户界面指出，随着更多示例的增加，聊天机器人对该动作的识别将得到改善。为了我们的演示，我们将为每个动作使用三个示例，这足以让我们开始。我们将在后续章节中展示多种找到额外训练示例的方法。

我们的问题-回答动作几乎完成了。我们有了触发它的提问；现在我们需要定义聊天机器人的响应。我们的#background动作的响应如图 2.5 所示。这个动作有三个部分：

• 条件逻辑——对于静态的问答动作，不需要逻辑。动作仅在检测到意图时开始。

• 响应—“助手说”是对用户的响应。我们的响应是简单的文本。

• 下一步—对于静态问答动作，不需要下一步。给出答案就结束了动作。

图 2.4 定义触发动作的表述

图 2.5 定义问答动作的响应。最简单的形式在检测到意图后只有一步——给出响应。

我们将为五个意图中的每一个重复这些动作创建步骤。每个动作都通过触发它的示例和它应该给出的响应进行训练。这些动作中的每一个都是一个单步动作，一旦给出答案就结束。

当所有五个动作都创建完成后，我们就准备好进行一些测试了。图 2.6 显示了我们的聊天机器人的测试界面。

图 2.6 聊天预览链接

让我们提出一些问题！图 2.7 显示了样本问题的测试结果。

图 2.7 Cake Bot 的示例问答响应

注意，提出的问题并不完全匹配我们的任何训练示例。这表明机器人已经学会了示例中的含义。以下列表显示了机器人的一些附加测试。

列表 2.1 使用更多问题测试 Cake Bot

User: hours of operation?
Bot: We are open Monday through Friday, 9am to 9pm.
User: why did the chicken cross the road
Bot: I'm afraid I don't understand. Please rephrase your question.
User: cost for a cake?
Bot: Our cakes typically cost around $30, with a $5 delivery fee.

这是我们机器人的一个很好的开始。我们可以对更多的意图进行训练，并且可以通过为这些意图提供更多示例来使其更加准确。但让我们考虑一些不同的事情。

我们创建的所有问答动作都是单步动作。无论用户问什么，他们都会得到相同的响应。在下一节中，你将看到如何根据附加信息将静态响应演变成动态响应。

2.1.3 动态问答

甜点店目前有四个地点：哥伦布、都柏林、韦斯特维尔和格兰德维尤。当机器人最初创建时，这四个地点的营业时间都是一样的：工作日早上 9:00 到晚上 9:00。情况已经改变——哥伦布的商店需要提前一小时开门和关门（早上 8:00 到晚上 8:00）。单个聊天机器人的响应不再涵盖所有商店。现在当用户询问商店营业时间时，我们需要弄清楚他们需要哪个商店的时间。如果他们没有指定，我们需要问他们澄清问题。

下一个列表显示了我们在一系列样本问题中希望机器人如何处理商店营业时间的问题。

列表 2.2 根据位置存储时间的示例对话

User: hours of operation?  #1
Bot: To view our store hours, please select a location. 
Bot: (Columbus, Dublin, Westerville, Grandview)
User: Columbus 
Bot: Our Columbus store is open Monday through Friday, 8am - 8pm.

User: hours of operation?
Bot: To view our store hours, please select a location.
Bot: (Columbus, Dublin, Westerville, Grandview)
User: Dublin 
Bot: Our Dublin store is open Monday through Friday, 9am - 9pm.

User: hours of operation for Grandview? #2
Bot: Our Grandview store is open Monday through Friday, 9am - 9pm.

1 在回答之前澄清了模糊的问题

2 明确的问题直接回答

我们还可以绘制一个涵盖这些示例对话的流程图，如图 2.8 所示。当你的对话具有动态性时，创建流程图和示例对话很有帮助。你的团队成员中有些人可能更喜欢图表，有些人更喜欢对话，有些人可能两者都需要。

图 2.8 特定位置的#store_hours意图的处理流程

“营业时间”流程可以分三步实现：

1. 显示“要查看我们的营业时间，请选择一个位置”以及位置列表。用户必须选择一个位置。

2. 如果步骤 1 = “Columbus”，显示 Columbus 的营业时间，并结束操作。

3. 显示步骤 1 商店的营业时间，并结束操作。

这是因为在我们的平台上，步骤是“逐级传递”的。以下是一些对话的工作方式：

• 用户输入“营业时间”，步骤 1 被触发。用户选择“Columbus”，步骤 2 被触发并完成操作。

• 用户输入“营业时间”，步骤 1 被触发。用户选择“Grandview”，步骤 2 的条件未满足。步骤 3 被触发并完成操作。

• 用户输入“Columbus 的营业时间”。步骤 1 的退出条件得到满足，因此步骤 2 被触发并完成操作。

• 用户输入“Grandview 的营业时间”。满足步骤 1 的退出条件，但步骤 2 的条件未满足。步骤 3 被触发并完成操作。

图 2.9 展示了这些步骤在我们助手中的实现方式。

图 2.9 #store_hours动作的三个步骤

Cake Bot 起步良好。它可以回答一些关于蛋糕店的基本问题，甚至还有一些活力。奶奶蛋糕不必再在电话上回答那么多的重复问题！但 Cake Bot 目前还不能为用户执行任何操作。我们将在下一节中探讨这一点。

练习

1. 从本书的 GitHub 网站下载本章的聊天机器人代码：github.com/andrewrfreed/EffectiveConversationalAI。在 watsonx Assistant 中加载聊天机器人，并使用预览面板测试聊天机器人的问答流程。

2. 或者，在您首选的对话 AI 平台上实现 Cake Bot：

   • 定义一个问候消息。

   • 定义一个回退意图和/或回退消息。

   • 实现表 2.2 中的五个意图。

2.2 路由代理和面向过程的机器人

并非所有机器人都是问答机器人。问答机器人擅长提供答案，但如果用户需要的不仅仅是答案——如果他们需要机器人执行操作呢？对于蛋糕店来说，我们希望顾客能够通过机器人订购蛋糕。如果我们只有问答能力，那么图 2.10 就是我们能做的最好了。

图 2.10 Cake Shop 的蛋糕订购流程作为问答。但这实际上并没有真正回答问题！

用户想要完成一个流程，但无法在机器人内部完成。他们只能获得如何完成流程的说明。因此，问答机器人通常是更强大解决方案的早期迭代。

2.2.1 路由代理

蛋糕店提供各种不同口味和装饰选项的蛋糕。有婚礼、毕业典礼、生日等活动的装饰套餐。有香草、巧克力、草莓等口味选择。此外，还有支付和配送方式。考虑到所有这些选项，合理地假设用户可能想要或需要与人类讨论这个过程。

对于许多聊天机器人开发者来说，他们聊天机器人的下一个逻辑迭代是路由代理。路由代理从用户的表述中检测意图，并确定谁最能帮助满足这个意图。图 2.11 重新构想了我们带有路由代理功能的蛋糕机器人。

图 2.11 路由代理检测用户意图并将它们路由到合适的专家。

对于原始的问答请求，机器人仍然按照之前的方式工作。但对于蛋糕订购请求，这个机器人根本不尝试回答问题——它只是将电话转接到合适的专家。请参见图 2.12 中的我们的实现。一旦检测到意图，动作就只有一个步骤：将用户转接到专家。

图 2.12 为#cake_orders的路由代理配置。一旦检测到意图，用户就会被转接到人工专家。

这个路由代理只是对传入的请求进行初步分类，这些请求可以转接到人工代理或专门的 AI 解决方案。人工代理可以使用电话或实时网络聊天。在这本书中，我们将这些人类通称为呼叫中心代理。

按 1 预约……

你可能拨打过一个交互式语音响应（IVR）系统，它会朗读一个选项菜单并提示你选择一个（“按 1 预约”）。这也是一个路由代理。这些系统的缺点之一是读取菜单所需的时间长度。对话人工智能路由代理允许你表达你的意图，这比听一个漫长的菜单更方便。

路由代理允许您迭代地实现对话人工智能解决方案，而不是需要一次性处理所有事情。

路由代理系统中的人工代理通常知道他们接收到的请求类型，但除此之外知之甚少。在图 2.12 中，他们只知道用户想要订购蛋糕。对于一些具有高度复杂性和敏感性的流程，这可能很理想。例如，“报告欺诈”意图可能应该立即连接到人类。

在其他场景中，将对话早期转接到人工代理对于代理来说是平凡的，但对于雇主来说却是昂贵的。对于处理索赔状态、成员 ID 和索赔日期的保险系统，在执行更高价值任务（如解释索赔发生了什么）之前，必须收集这些信息。在这里，人工智能助手可以先收集成员 ID 和索赔日期，然后再将对话转接到人类。

因此，路由代理的下一步进化是将更多的工作转移到自动化。让我们为蛋糕机器人构建这个功能。

2.2.2 从路由代理过渡到面向过程的机器人

订购蛋糕的通用流程流程图如图 2.13 所示。它包括四个步骤，用于明确订购的蛋糕的细节，然后是确认步骤，最后是履行。为了简洁起见，我们将省略本章剩余部分的履行细节——示例代码可在我们的 GitHub 网站上找到：github.com/andrewrfreed/EffectiveConversationalAI。

图 2.13 从蛋糕店订购蛋糕的流程图

在完整的过程流程设计完成后，我们可以从路由代理过渡到面向过程的机器人。蛋糕机器人将通过在路由到人工代理完成流程之前收集一些细节来处理部分蛋糕订购流程。图 2.14 显示了蛋糕机器人过渡的第一迭代的设计。

图 2.14 将路由代理过渡到面向过程的机器人。机器人现在在转交给人工之前收集两块信息。

我们的过程过去只有一步（图 2.12）。现在我们将有四步：

1. 机器人将通过回复“我可以帮助您订购蛋糕”来启动流程。

2. 询问需要哪种尺寸的蛋糕，并提供选项（小、中、大）。

3. 询问蛋糕的场合，并提供选项（生日、婚礼、周年纪念、退休、全场合）。

4. 将用户转接到人工代理。这是路由代理的原始第一步，但代理的消息已从“用户想要订购蛋糕”更改为“用户想要订购一个<尺寸> <场合>蛋糕。”助手将步骤 2 和 3 的回复注入到消息中。

这些步骤是顺序执行的。图 2.15 显示了步骤 2。

图 2.15 收集蛋糕尺寸的步骤为用户提供明确的选择。

注意，机器人可以以按钮的形式向用户提供不同的选项，让用户知道哪些选项可用。机器人还可以允许用户输入他们的回复，如果他们愿意的话。您可以在书中 GitHub 网站上提供的示例代码中探索这些选项。

还要注意，这些选项中的每一个都将支持“贯穿到底”。如果用户以“我想订购一个蛋糕”开始对话，他们将被要求提供尺寸和场合。如果他们说“我想订购一个大型周年纪念蛋糕”，他们将跳过尺寸和场合问题，因为他们已经提供了这些信息。

其余的蛋糕订购流程已在本节描述的步骤指导下在书的 GitHub 网站上实现。以下列表提供了一个示例对话。

列表 2.3 饼干订购的示例对话

User: I want to order a cake
Bot: I can take your cake order.
Bot: What size cake do you need?
Bot: (small, medium, large)
User: large 
Bot: (birthday, wedding, anniversary, retirement, all-occasion)
User: birthday
Bot: What flavor cake would you like?
Bot: (vanilla, chocolate, marble)
User: vanilla
Bot: Which frosting would you like?
User: strawberry
Bot: Ok, I've got you down for a small vanilla birthday cake with   #1
strawberry frosting. Is that correct? 
User: yes
Bot: Great. Your order has been accepted.  #2
Your order subtotal is $30.00\. 
Bot: Would you like to schedule your order for pickup or delivery? Please note there is a $5 delivery fee.
Bot: (pickup, delivery)
User: delivery
(fulfillment details are omitted)

1 第 7 步的确认信息会回放之前步骤收集的信息。

2 第 8 步的订单确认会触发蛋糕价格的逻辑条件。

Cake Bot 的能力正在增强。它具有关于蛋糕的静态问答能力，关于店铺营业时间的动态问答能力，以及订购蛋糕的过程导向流程。蛋糕店团队部署了其聊天机器人，并对结果（以及用户对他们的蛋糕感到满意！）感到高兴。接下来，我们将面对本章的最后一个挑战：添加具有大型语言模型（LLM）的生成式 AI 能力。

练习

1. 请参考您从本书 GitHub 网站下载的本章聊天机器人代码（github.com/andrewrfreed/EffectiveConversationalAI）。在 watsonx Assistant 中加载聊天机器人，并使用预览面板测试聊天机器人的蛋糕订购流程。

2. 或者，在您偏好的对话式 AI 平台上实现 Cake Bot 的订单处理过程：

   • 检测订购蛋糕的意图。

   • 直接将意图路由到人工客服。

   • 收集所有四个蛋糕数据点，并得出总结。

2.3 使用生成式 AI 响应用户

Cake Bot 目前仅使用传统的对话式 AI 技术。问答过程由基于意图的分类器完成。订单处理是通过一系列顺序规则完成的。到目前为止，这已经很好地满足了蛋糕店的需求。

当蛋糕店团队审查 Cake Bot 的表现时，他们发现了一个不寻常的趋势。用户在点蛋糕之前会向机器人询问他们打算在晚餐上提供的食谱。没有其他食谱请求的模式——有烤菜、沙拉、炒菜等多种请求。团队对用户群体的多样性感到鼓舞，但不知道如何在 Cake Bot 中处理这些请求。他们如何能够检测到所有这些不同类型的食谱，更不用说对它们做出回应了？

这对于蛋糕店团队将一些生成式 AI 整合到他们的解决方案中是一个绝佳的地方。他们可以使用现有的意图机制来检测食谱请求，然后将这些请求路由到 LLM 以生成答案。他们需要将 LLM 集成到他们的聊天机器人中，并向该 LLM 发送特定请求。

让我们看看他们如何做到这一点。

2.3.1 与 LLM 集成

对于许多对话式 AI 平台，与外部系统集成的最主要方式是通过应用程序编程接口（API）。这些是普遍的集成模式，幸运的是，它们得到了大量生成式 AI 平台的支持，这些平台公开了 LLM。API 在对话式 AI 中的具体集成方式会因平台而异。在某些平台上，这种集成是通过代码完成的；在其他平台上，则是低代码和可视化界面。不同的平台对其集成能力的命名不同，例如扩展、集成和履行。许多平台允许您通过 OpenAPI 规范来集成 API。

我们将添加一个生成式 AI 平台作为扩展以进行基于 LLM 的文本生成。在我们的平台上添加扩展有四个步骤（步骤的详细信息包含在本书的 GitHub 仓库中）：

1. 从集成菜单中选择“构建自定义扩展”。

2. 提供一个名称和描述，例如“生成式 AI 平台 API 调用”。

3. 提供一个 OpenAPI 规范文件。该文件记录了扩展的功能，包括它公开的方法、其必需和可选参数以及它提供的响应。OpenAPI 规范文件是 API 的常见文档格式。它们通常由生成式 AI 平台提供。

4. 提供连接和身份验证详细信息，例如 API 实现的 URL 和访问它所需的 API 密钥。

我们添加扩展，并在助手内部可视地探索它。图 2.16 显示了我们在平台中的 LLM 文本生成 API 扩展。

图 2.16：我们的 LLM 文本生成 API 的 OpenAPI 规范，包含可能的请求参数的子集

在撰写本文时，我们的文本生成 API 包括 15 个输入参数和 6 个输出参数——比图 2.16 中显示的还要多！还有一些参数无需任何定制即可使用，例如响应的 HTTP 状态码。其他生成式 AI 平台将有类似的参数集，可能参数名称或位置不同。让我们回顾一下最重要的参数：

• input (请求)—对 LLM 的提示。它将包括 LLM 的指令、上下文和数据。其中一些数据可能直接来自用户。

• model_id (请求)—用于任务的 LLM 标识符。大多数生成式 AI 平台允许您从几个模型中选择。

• parameters (请求)—调整 LLM 行为的键值对。这些包括解码方法（贪婪或采样）、要生成的输出标记数以及几个其他参数。

• generated_text (响应)—LLM 的输出。

我们可以使用任何动作中任何步骤的扩展。在本章的早期，我们使用了“助手说”，“继续到下一步”和“连接到代理”等能力。对于扩展，该能力被称为“使用扩展”。图 2.17 显示了我们的食谱动作的扩展调用看起来是什么样子。其他 LLM 任务看起来类似，但具有不同的配置值。此参数集是为提供食谱而调整的。

图 2.17 从助手动作中调用 LLM 文本生成 API

让我们看看如何在 Cake Bot 中将所有这些连接起来。

2.3.2 将请求路由到 LLM

图 2.18 中的流程图概述了在 Cake Bot 中如何涵盖食谱生成。我们首先创建一个新的动作。就像我们的问答动作一样，我们从一些触发此动作的示例语句开始。我们的前三个语句是“给我一个食谱”， “我怎样才能做”，和“告诉我如何烤”。鉴于可能的食谱种类繁多，我们不包含菜肴名称，只包含食谱请求可能看起来像的方式。

图 2.18 Cake Bot 通过 LLM 生成食谱的流程图

新动作的第 1 步是将用户原始语句的整个内容（来自系统变量input.text）存储在一个名为recipe_query_text的变量中。这是我们之前步骤中没有使用过的技术。对于蛋糕订购动作，每个选项都有一个明确且有限的响应集。即使用户说“请给我一个大蛋糕”，我们也只想存储“大”。对于食谱请求，我们不知道用户会说什么，所以我们将捕获他们的整个语句。

动作的第 2 步是定义 LLM 的提示。我们将一个简单的系统提示与用户的请求连接起来。下一个列表演示了构建recipe_prompt变量所使用的表达式。

列表 2.4 构建食谱提示，存储在recipe_prompt变量中

"You are a helpful kitchen assistant. Create a recipe as instructed by 
the user.\n\nInput: ".append(recipe_query_text).append("\n\nOutput: ")

动作的第 3 步是调用 LLM。参数已在图 2.17 中显示，但让我们深入了解具体的值：

• input—我们将recipe_prompt变量的值分配为输入。这会将用户的食谱请求注入到 2.4 列表中显示的通用提示格式中。

• model_id—有许多模型可供选择，但在撰写本文时，mistralai/mixtral-8x7b-instruct-v01 在这个生成任务上表现良好。

• project_id—这是来自生成 AI 平台项目实例的标识符。

• min_tokens和max_tokens—这些分别设置为0和1000，从默认的0和200增加，因为食谱通常比较长。

• decoding_method—设置为greedy以方便调试，因此如果给出相同的输入，模型将做出相同的响应。

• repetition_penalty—设置为1（无惩罚），因为互联网上的食谱通常有一些重复。

• 版本—表示请求的 API 的次要版本。我们在写作时使用了默认版本：2023-05-29。

行动的第 4 步是检查 API 调用是否成功，如果是，则向用户显示响应。我们将从一些静态文本“这是你的食谱”开始生成响应，并附加 LLM 的响应。我们不需要编写任何 JSON 解析代码；OpenAPI 规范告诉我们我们可以引用generated_text的值。图 2.19 显示了动作响应配置。

图 2.19 显示 LLM 调用向用户显示的输出

在 Cake Bot 中构建这个功能非常有趣！列表 2.5 显示了与该机器人进行的一次示例对话。由于食谱较长，所以为了简洁起见，大部分内容被省略。加载 Cake Bot 并亲自尝试一下吧！

列表 2.5 Cake Bot 的样本简略对话

User: I need a quick recipe for peanut butter pie
Bot: Sure! I'm looking up a recipe for you. Please wait a few seconds.
Bot: Here's your recipe:
...
Ingredients:
1 pre-made graham cracker crust
1 cup creamy peanut butter
...

Instructions:
In a large mixing bowl, beat together the peanut butter, powdered sugar, and softened cream cheese until smooth and creamy.
...
Serve chilled and enjoy your quick and easy peanut butter pie!
Let me know if you need any further assistance or clarification.

练习

1. 请参考本书 GitHub 网站（github.com/andrewrfreed/EffectiveConversationalAI）上下载的本章聊天机器人代码。在 watsonx Assistant 中加载聊天机器人，并按照说明将其与 watsonx.ai 集成。使用预览面板测试聊天机器人的食谱流程。

2. 或者，在你的首选对话式和生成式 AI 平台上实现 Cake Bot 的订单处理过程：

   • 检测食谱意图。

   • 从一组指令和用户的输入中构建提示。

   • 将 LLM 的响应直接指向用户。

摘要

• 问答（Q&A）机器人是开始构建你的第一个对话式 AI 的绝佳方式。

• 使用问题的示例来训练问答机器人，让你能够为相关问题组（意图）提供预定义的答案。

• 行动始于意图，并可能产生多种结果：回答问题、将用户引导至人工客服、提出后续问题以及调用 API。

• 路由代理识别意图并将信息传递给人工客服。这是一个在依赖人工能力的同时，逐步增加对话式 AI 能力的好方法。

• 对话式 AI 可以使用传统和基于规则的技术以及生成式 AI 的组合。

第三章：计划改进

本章涵盖

• 建立一个实现对话式人工智能成功的跨职能团队

• 通过业务目标、关键指标和用户痛点来定义成功

• 通过结果和指标分析有效性，以指导改进

• 实施结构化流程以识别、报告、分诊和优先处理问题

每个对话式人工智能解决方案都应该以成功为目标，而成功根据所涉及的聊天机器人的类型而有所不同。例如，问答机器人必须提供快速、准确的响应，同时最大限度地减少后续交互。面向流程或交易型的机器人必须有效地引导用户达到特定目标。路由代理必须无缝地将用户引导到适当的目的地。

然而，误解用户意图、过度复杂化和立即退出可能会阻碍进步并给用户带来痛苦。解决这些挑战可以提高聊天机器人的性能，并帮助其取得成功。那些持续改进其聊天机器人的组织最有可能实现最佳结果。

在跨职能团队中结合多样化的专业知识对于持续改进至关重要。团队成员可以通过他们独特的视角、技能和洞察力推动变革。然而，团队需要就如何改进他们的解决方案达成一致。

对话式分析师希望简化对话，但企业希望传达具体信息。谁是对的？在本章中，我们将展示 MediWorld 公司（一家虚构公司）的团队如何适应和改进他们的聊天机器人。他们的团队最初通过增强他们的问答机器人开始，但随着用户需求的变化，他们转向开发面向流程的聊天机器人的额外功能。

3.1 知道何时需要改进

想象以下场景：

MediWorld，一家大型药店，其呼叫中心因有关大流行的问题而超负荷运转。他们部署了一个聊天机器人来提供与 COVID-19 相关的信息。该机器人检测到关于病毒的一组集中意图，并提供了可靠的信息。

图 3.1 展示了 PharmaBot 高效地识别这些意图。

图 3.1 PharmaBot 高效地从用户查询中检测到信息意图。

疫苗即将可用时，客户的问题性质发生了巨大变化。突然之间，每个人都有一系列不同的问题：

• 我是否有资格接种疫苗？

• 我可以预约接种疫苗吗？

• 我何时可以接种第二剂疫苗？

• 我必须打电话预约，还是可以在这里设置？

• 我接种后可以旅行吗？

PharmaBot 最初在理解这些问题方面很弱，经常回答：“抱歉，我不确定你在问什么。请重新表述你的问题。”用户感到沮丧和不满意，更多的对话在机器人失败后结束在呼叫中心。还有立即退出率的增加，反映出用户期望与 PharmaBot 应对不断变化的环境的能力之间明显的脱节。MediWorld 的团队着手改进这个机器人，但他们首先必须就“改进”的含义达成一致。

注意：持续改进的需求从未如此关键，因为不断变化的患者期望和技术进步要求不断的精炼和适应。布里奇特·范·克拉林曾打趣说：“任何人任何地方最后一次最好的体验，成为他们希望在任何地方都能获得的最低期望。”改进需求可能来自内部来源（如对新功能的支持）或外部来源（其中某个事件引发了以前从未见过的全新问题）。

认识到在对话式人工智能方面需要改进是确保其有效性和相关性的关键。虚拟助手不是一个静态的解决方案；其性能必须随着用户行为、业务需求和技术进步而发展。改进的必要性通常通过关键绩效指标（KPIs）如低包含率、高回退意图使用或频繁的代理升级等迹象显现出来。规划实际改进的起点是建立一个跨职能团队，明确成功标准，分析结果，并实施结构化的问题管理流程。

当决定何时开始改进您的对话式人工智能时，最佳实践建议在您注意到重复出现的问题、下降的参与率或未实现的企业目标时就开始。主动方法可以防止小问题升级成大问题。建立定期的审查周期确保改进与不断变化的患者期望和组织目标保持一致。

在第一次部署之前，通过规划全面的数据收集策略开始您的改进之旅。记住，仅仅拥有日志文件并不能自动揭示痛点。在识别用户交互中的趋势和模式时，必须要有条不紊。许多团队倾向于解决孤立的问题，而没有考虑到这些问题的整体量或频率。虽然解决一次性问题可能看起来很有成效，但这很少能导致整体性能的实质性改进。通过关注具有重大影响的系统性问题，您可以确保您的努力始终指向有形的进步，让您感到专注和投入。

记住，在部署更改前后衡量性能同样重要。在实施修复之前建立基线指标，并与部署后的数据进行比较，以评估更改是否带来了预期的改进。如果结果与您的预期不符，请不要担心。进一步分析根本原因，并迭代您的解决方案，以有效解决任何差距或未预见到的问题。这个过程将给您带来信心和保证，您的努力正在带来实际的进步。

3.2 您的跨职能团队

MediWorld 认识到其 PharmaBot 在提供及时准确客户支持中的关键作用。由对话分析师、客户支持专家和数据分析师组成的跨学科团队聚集在一起，评估并提升 PharmaBot 的性能。该团队的目标不仅在于解决现有挑战，还积极预测并满足用户群体的不断变化需求：

MediWorld 的开发者专注于提升 PharmaBot 的自然语言处理能力。他们找到了增强聊天机器人理解用户查询的方法，使其能够提供精确且具有上下文意识的响应。

同时，负责接听转接电话的客户服务中心代理分享了从他们那里转接的电话中的宝贵见解，揭示了常见的痛点以及频繁询问的问题。

MediWorld 的数据分析师深入分析了用户交互数据。他们确定了聊天机器人“失败”的区域，并按机器人最后尝试的任务对这些失败进行了分类。

图 3.2 展示了每个小组带来的各种见解。

图 3.2 该团队利用其多样化的技能确定了改进区域，为有效的改进计划奠定了基础。

让我们超越 PharmaBot 的例子，关注通常参与对话式人工智能改进计划的团队。具体角色、责任和团队规模可能根据您组织的规模、目标以及聊天机器人的复杂性而有所不同。在较小的项目中，个人可能承担多个角色。第一章介绍了构建对话式人工智能的“梦幻团队”（图 1.5）。为了改进和精炼现有的聊天机器人，也需要一个类似的多样化团队。虽然这个团队的结构在不同组织之间可能有所不同，但它通常由三个关键子团队组成，所有团队共同协作。

首先是聊天机器人的支持和维护团队。该团队的任务是分析和评估聊天机器人的性能。此外，他们还作为技术主题专家（SMEs）。他们了解聊天机器人处理的现有意图、这些意图的训练数据以及聊天机器人的对话流程。他们可以实施代码和技术更改。他们的角色和任务在表 3.1 中概述。

表 3.1 聊天机器人支持和维护团队

角色	任务
数据分析师/数据工程师	分析用户交互和反馈，就变更、修复和增强提出有根据的建议。
聊天机器人开发者/对话分析师	实施聊天机器人的技术更改和增强。这可能包括新的集成（更多是开发者的角色）或更新聊天机器人的对话和动作（对话分析师）。
质量保证（QA）测试员	验证变更、修复或增强是否产生预期结果，并且不会导致任何意外或负面结果。测试可能是手动进行，也可能涉及自动化测试工具。
项目经理	协调任务；确保持续改进过程按计划进行。
其他领域专家	在聊天机器人生态系统特定领域提供专业知识；根据需要被吸纳到团队中。例如，安全专家评估潜在威胁，并推荐适当的安保措施或补救策略，以确保聊天机器人保持安全和能够抵御不断变化的风险。

第二个子团队是业务利益相关者。他们共同确保聊天机器人的改进与更广泛的组织目标和业务需求保持一致。业务利益相关者确保聊天机器人在技术上熟练，并与组织目标、用户需求和法律标准保持一致。该团队在表 3.2 中详细说明。

表 3.2 聊天机器人的业务利益相关者

角色	任务
高级管理层	参与将改进或改进优先级与整体业务战略保持一致
客户服务	负责聊天机器人所处理的业务流程和工作流程
产品经理（聊天机器人）	负责监督聊天机器人的开发和战略方向，确保其满足业务目标
IT 部门	为聊天机器人的开发、部署和维护提供技术支持和基础设施
运营经理	协同工作，将聊天机器人整合到运营流程中，简化工作流程
法律和合规团队	确保改进符合行业法规和法律要求

最后一个子团队是治理团队。他们的职责是确保聊天机器人的部署、使用和持续改进与组织政策、标准和道德考量保持一致。他们在表 3.3 中列出。

表 3.3 聊天机器人的治理团队

角色	任务
企业伦理/合规焦点	解决关于聊天机器人行为和决策的伦理问题，以及人工智能模型的风险管理。他们还确保在改进阶段遵循其负责任的 AI 指南。
治理执行团队	对系统路线图、待办事项和与系统相关的所有成本（支持或业务团队）的优先级有最终决定权。

拥有一个多元化和跨职能的改进团队确保不同的视角和专业知识为聊天机器人项目的开发和监督做出贡献。定期的会议、清晰的沟通渠道和治理政策的记录对于团队的有效性至关重要。再次强调，具体涉及的利益相关者可能根据项目的性质和范围而有所不同。

练习

1. 想想你最近的一次聊天机器人实施，并列出你所有的利益相关者。讨论利益相关者对改善聊天机器人的共同目标的观点，以及这一目标如何与他们的具体目标相一致。考虑利益相关者利益之间的潜在冲突以及解决这些冲突的策略。

2. 或者，以 MediWorld 的 PharmaBot 为例，考虑各种利益相关者和他们的目标。

3.3 驱向同一目标

即使在一个单一的改进团队中，不同的成员可能对应该首先解决的问题有不同的优先级。考虑以下场景：

当 PharmaBot 团队首次见面时，他们无法就如何开始达成一致。每个人都带来了他们的“必须修复”清单。有些是基于直觉，有些是基于阅读了几份记录，还有些是基于详细的分析。团队一致认为理解问题的频率是关键：这些问题是否出现在每一次对话中，还是偶尔出现？问题频率是优先排序修复和改进的关键组成部分，帮助 MediWorld 提高其聊天机器人的性能。

开发人员和数据分析师主张改进 PharmaBot 的自然语言处理能力，分析最近的互动以确定理解复杂和上下文相关问题的改进领域。同时，主要呼叫中心代理强调 PharmaBot 需要提供更详细和富有同理心的回应，关注他们遇到的重现用户关注的问题。

数据驱动的方法有助于优先级排序。解决最常见的痛点将导致用户体验的整体立即和实质性的改进。图 3.2 展示了多个团队成员如何贡献不同的观察和见解。每个成员都从他们各自的职位和专业知识带来了独特的视角。

3.3.1 回顾业务目标

对话式人工智能改进团队成员必须就改进的共同目标达成一致。第一步是就成功意味着什么达成共识——团队必须重新审视最初推动聊天机器人实施的商业目标。例如，问答机器人必须能够持续快速且准确地响应用户问题。以流程为导向的机器人必须帮助用户高效地实现目标，如安排预约或检查账户。路由代理必须根据用户的查询将用户引导到能够满足他们需求的地方或专家。评估聊天机器人性能是否符合这些目标涉及响应准确性、用户满意度以及机器人处理广泛相关主题和用例的能力等指标。

随着商业格局的发展，适应性变得至关重要。用户期望的变化或技术进步可能需要增强或战略转变，以保持聊天机器人的最佳性能。因此，团队必须持续重新评估和细化聊天机器人策略，确保其与整体组织目标和用户目标保持一致。这个迭代过程满足了业务及其用户不断变化的需求。

从业务成果到指标

定义正确的指标始于理解商业目标如何随时间演变。考虑以下场景：

PharmaBot 团队需要将他们的努力与高效疫苗分配和可及性的重要性对齐。虽然最初的企业目标是回答问题并减轻他们的呼叫中心的负担，但商业目标已经转变为有效分配疫苗和自动化预约流程，这需要不同的指标。

当有疑问时，考虑你的用户——他们需要什么，这些需求如何推动业务？最初的企业目标是什么？用户想要什么？两者是如何对齐的？认识到这些答案可能会随时间而变化。图 3.3 显示了 PharmaBot 的第一个商业目标：提供关于新流行病准确且最新的信息。准确性是关键指标。

图 3.3 PharmaBot 最初是一个简单的问答机器人。许多问题种类都得到了相同的答案。

一旦建立了稳定的基础，PharmaBot 团队就增加了问答机器人的复杂性和智能。他们检测实体（与意图相关的上下文元素）以向用户提供更有针对性的答案并提高准确性，如图 3.4 所示。

图 3.4 通过检测用户话语中的实体，问答变得更加复杂，从而在共同意图内提供更具体的答案。

然后，外部影响再次改变了业务目标。疫苗的可获得性改变了机器人的性质。用户不再仅仅与关于病毒的纯问答互动，而是希望通过机器人直接安排疫苗预约。这需要以流程为导向的流程来收集多份信息。图 3.5 显示了这一流程的开始。

图 3.5 一些问题类型没有单一的静态答案，但需要完整的流程来满足。

这些新功能带来了复杂性。自动化测试和疫苗预约需要与调度系统和数据库集成。这增加了对安全和隐私措施的关注。保护用户个人信息、遵守医疗保健法规和确保安全交易变得至关重要。

并非所有对话式人工智能解决方案都必须应对这种演变，至少不是像 PharmaBot 那样迅速。管理聊天机器人的演变需要仔细考虑与聊天机器人转型每个方面相关的成本和收益。

任何对话式人工智能解决方案的主要业务目标都围绕着提升整体业务成果。每个企业都有对话系统的目标或目标，这归结为两个关键因素：收入生成和成本降低。这些目标转化为如提高转化率、更高的平均订单价值（AOV）和增强客户终身价值（CLV）等指标，以促进收入增长。在成本方面，如降低平均处理时间（AHT）、降低运营成本和改善首次接触解决率（FCR）等指标反映了成本节约。组织期望投资回报率（ROI）可衡量，这些绩效指标指导持续改进工作，将对话式人工智能的成功直接与关键业务成果对齐。

业务目标必须转化为可衡量的指标。这允许对对话式人工智能满足其目标的情况进行量化评估。表 3.4 中的示例展示了各个行业的业务如何定义与特定目标一致的可衡量指标。

表 3.4 从各个行业的业务目标中得出的样本指标

业务目标	结果指标	机器人类型
提高在线销售额，降低客户服务成本。	未经人工干预完成结账的聊天机器人百分比：实现 75%的自动化结账，每天减少 10 万个客户服务咨询，导致每天节省 500,000 美元。	问答
提高客户支持效率，并最小化服务中断。	成功路由到适当部门或专家的查询百分比：90%的查询直接路由到相关支持团队，无需人工干预，导致每天支持工单减少 40,000 件，从而每天节省 700,000 美元。	路由代理
提升预订体验，并降低支持成本。	无需代理干预的自动化预订确认百分比：实现 70%的自动化预订确认，每天减少 80,000 项支持查询，从而每天节省 640,000 美元。	流程导向
提高患者参与度，并优化预约安排。	虚拟助手自主安排的预约百分比：90%的预约由虚拟助手自主安排，每天减少 30,000 项手动安排任务，从而每天节省 700,000 美元。	流程导向

对话式指标需要与商业价值建立清晰的联系，以证明投资回报。如呼叫中心转接和路由准确度等指标可以降低成本。如客户满意度等指标，当满意的客户消费更多服务时，会导致收入增加。PharmaBot 团队通过自动化预约安排实现了成本节约和收入增长。

其他业务驱动因素

除了与上一节讨论的核心业务目标保持一致外，组织还应考虑其他推动对话式人工智能价值的因素。成功的 AI 实施不仅仅是支持高级目标——它们还积极提升客户参与度，优化销售策略，并降低运营成本。

对话式人工智能可以加强客户互动，引导销售，并推荐相关产品。分析由聊天机器人驱动的转化率对于完善策略至关重要。探索 AI 驱动功能以进行升级销售和交叉销售的商家可以最大化收入机会。从运营角度来看，对话式人工智能通过处理常规任务，使人工代理能够专注于复杂活动。自动化流程提高效率，降低支持成本，并提升对更快响应的满意度。

详尽的分析可以发现改进机会和优化聊天机器人性能的机会。随着技术的进步，企业应扩展聊天机器人功能，以实现持续的成本降低和运营卓越。

竞争对手分析，评估自然语言理解和个性化体验等特性，可以指导持续改进。定期更新使企业能够适应竞争格局的变化，推动创新以实现积极的商业成果。

3.3.2 效果

在确定改进优先级时，另一个需要考虑的关键因素是聊天机器人的有效性。聊天机器人是否做到了它应该做的事情？虽然“有效性”的概念很简单（是否按预期工作？），但它超越了任务完成。它涉及到为用户提供积极和高效的经验。

让我们继续我们的场景，团队现在正在查看显示聊天机器人指标的仪表板。大多数聊天机器人开发平台都有一个简单的分析仪表板，包含总结用户如何与聊天机器人互动的关键绩效指标（KPIs）。这些仪表板通常包含对话数量、聊天机器人信心和对话持续时间的统计数据。它们也可能包括最常问的问题或意图。

图 3.6 展示了为 PharmaBot 创建的分析仪表板。虽然它显示了部分关键绩效指标（KPIs），但它并不能表达 PharmaBot 的有效性。总对话次数帮助我们理解流量，但它并不能帮助我们评估有多少人成功完成了聊天，或者他们聊到了什么程度。

图 3.6 PharmaBot 的基本分析仪表板显示了使用总结，但不能提供用户对机器人喜欢（或不喜欢的）什么的信息。

团队试图确定当前的协助率。基本分析给了他们每天总查询量的信息，但他们需要帮助确定其中有多少是成功的。团队需要超越仅仅对话数量的层面。每个人都清楚用户需求在增加。PharmaBot 是否满足了新的需求？他们需要找出如何衡量机器人的有效性，并找到优化其性能的方法。团队发现 45%的所有对话都转移到了呼叫中心。这个“控制”指标影响了企业的成本。他们能对这个数字做些什么呢？

在 PharmaBot 团队的情况下，衡量有效性的一个关键指标是控制率。控制对话是指聊天机器人可以独立完全处理用户查询的情况；未控制对话则需要人工介入。控制率是控制对话数除以总对话数的结果。这个指标提供了对聊天机器人性能的高层次衡量，如图 3.7 所示。

图 3.7 基本每日仪表板显示了简单的业务指标：控制率。这个指标每天都会跟踪，但仍然不能提供对机器人性能的深入洞察。

PharmaBot 的仪表板暗示了一个简单的成功定义：“控制通话即为成功。”这种思维模型总结在图 3.8 中。然而，虽然控制是一个有价值的指标，但它并不能解释为什么用户在与机器人互动时成功（或失败）。需要更详细的分析来获得更深入的见解。

图 3.8 最简单的结果定义。这并不能揭示如何改进机器人。

对话结果

为了更好地理解对话结果如何影响聊天机器人的改进，让我们回到我们的示例场景。PharmaBot 维护团队需要超越高级性能指标，并分析实际的对话结果。仅仅控制并不能捕捉到全貌——它只能告诉他们对话是否留在机器人这边。但那些对话中真正发生了什么？以下是他们对对话进行深入审查的方式：

团队深入到大量的对话记录中，以了解对话中发生了什么。它们是如何结束的？团队发现了一系列的结束方式——成功的完成、放弃的对话，以及令人困惑的大量转移。

数据分析师观察到了不同的成功类型。首先，是 PharmaBot 对查询做出良好响应，用户感到满意的预期情况。其次，由于业务规则，如用户居住在 MediWorld 无法进行短信确认的州，导致向呼叫中心的移交。这些移交也是成功的，因为它们与 PharmaBot 的初衷一致：收集所需信息，以便人类专家不必这么做。团队一致认为，他们需要分别记录这两种情况。他们将它们标记为“自动解决”和“有意转移”。

然后是明确的失败场景。用户在机器人误解了他们之后要求人工代理。当机器人连续误解用户时，也会自动转移用户。还有一些用户在预约安排中途断开连接。

最后，PharmaBot 团队发现了用户甚至没有尝试的对话。用户要么在机器人问候后默默断开连接，要么以“agent”这个词开始对话。一位团队成员评论说：“也许这里有一个心理因素在起作用：一些用户不想与机器人互动。让我们也将这些对话分开。”

团队最终开发了一套细致的分类系统：成功（自动解决和有意转移）、失败（放弃和升级）、不需要机器人（立即断开连接和立即升级）。

一旦分类系统建立，计算每个分类中的对话数量就变得容易了。PharmaBot 团队开始真正理解他们机器人的性能。

定义与你的指标相关的详细对话结果将为你提供关于解决方案性能的见解。对话结果描述了用户与聊天机器人的交互如何结束，分类了聊天机器人是否解决了查询、需要人工帮助，或者导致不完整的会话。定义这些结果是评估和改进你的解决方案以符合业务目标的关键。一旦你的解决方案部署，分析你的对话日志，并根据结果模型对它们进行分类。

图 3.9 展示了新的详细结果模型。它从左边的遏制开始，然后详细分解了遏制（和非遏制）结果及其原因。最后，这些原因被映射回成功和失败类别。这些原因帮助我们了解机器人哪里做得对，哪里做错了。例如，对话可能因为“失败”而未能遏制：可能是用户选择退出，或者机器人反复不理解。有些对话根据业务流程有意转交给人类——这些不算失败。

图 3.9 分解对话为何未能遏制，可以更深入地了解机器人性能，并显示你的机器人需要改进的地方。实现这一目标的一种方法是通过使用详细的结果分类，这些分类定义了聊天机器人交互的具体结果。这些分类根据对话的解决方式、用户体验和下一步行动对对话进行分类。

现在我们已经介绍了细粒度结果模型的概念，考虑对话可能如何（在哪里以及为什么）结束，让我们看看图 3.7 中我们看到过的相同指标仪表板。我们不再关注 45%的遏制率，而是更好地理解对话。在图 3.10 的仪表板上，我们用成功率图表替换了遏制率图表，表示成功/失败/不希望作为最高级别的类别。

图 3.10 通过成功率增强总结仪表板。并非所有包含的呼叫都成功；并非所有转接的呼叫都是失败。

实际上，你可能还想展示结果细节。在图 3.11 中，我们展示了这可能是什么样子。这种方法使你能够快速将高级结果分解为详细结果，这也有助于你获得利益相关者对改进的认可。

图 3.11 的详细结果模型描绘了在一段时间内汇总的对话结果和结果细节。这比二元的“遏制或不遏制”模型提供了对机器人性能的更多洞察。

详细结果模型的优点在于其灵活性。每个对话式人工智能项目都可以定义自己的独特结果分类。图 3.11 中所示模型是一个有用的示例实现。一如既往，根据您的需求调整此模型。例如，如果您的聊天机器人没有人工转接，则可以省略升级和转移结果。

这里有一些常见对话式人工智能解决方案的推荐分类。

对于问答机器人：

• 成功——对话完成场景：

  • 自动解决——问答机器人成功回答用户的问题或提供相关信息，无需人工干预。

• 失败——交互未能实现预期结果：

  • 放弃——用户在得到满意的答案之前离开对话，可能是因为对机器人响应的挫败感或不满。

  • 升级——问答机器人不理解用户，交互升级到人工代理以获得进一步的帮助。这可能是由用户请求引起的，或者机器人可能在多次连续误解后自动升级。

• 不需要聊天机器人：

  • 立即断开连接——用户在未向机器人发送任何消息的情况下退出对话。

  • 立即升级——用户对机器人的第一次发言是请求人工代理。

对于交易型或流程导向型机器人：

• 成功——对话完成场景：

  • 自动解决——流程导向型机器人成功完成用户的预期任务，例如预约，无需人工干预。

  • 故意转移——如果业务规则要求，即使没有遇到“错误”，机器人也会将交互转移到人工代理。

• 失败——交互未能实现预期结果：

  • 放弃——用户在交易中途放弃对话，可能是因为复杂性或对机器人界面的困惑。

  • 升级——机器人开始但无法完成流程，因为误解了用户或用户请求人工代理。

• 不需要聊天机器人：

  • 立即断开连接——用户在未向机器人发送任何消息的情况下退出对话。

  • 立即升级——用户对机器人的第一次发言是请求人工代理。

对于路由代理：

• 成功——对话完成场景：

  • 故意转移——路由代理成功将用户引导到正确的部门或专家，可能传递到目前为止收集的所有信息。路由代理可能有 0%的包含率，但工作得非常好！

• 失败——交互未能实现预期结果：

  • 放弃——用户在机器人路由之前退出对话。

  • 升级——路由代理无法收集足够的信息来路由用户，无论是由于误解还是用户请求人工代理。

• 不需要聊天机器人：

  • 立即断开连接——用户在未向机器人发送任何消息的情况下退出对话。用户不能自动路由。

  • 立即升级：用户的第一次与机器人的对话请求是要求人工客服，绕过了所有自动化路由。

当你这样对对话进行分类时，每个类别中的对话数量可以帮助你评估聊天机器人实施的有效性并确定改进领域。

详细的结果模型应该与对话设计集成。一个很好的方法是定义每个机器人“快乐路径”问题的里程碑。图 3.12 显示了 PharmaBot 的这种设计。阴影框中显示的“安排预约”里程碑标志着机器人完成调度过程的关键步骤。“需要帮助其他任何事情吗？”也被阴影覆盖，表示机器人在完成主要任务后准备进一步协助。

图 3.12 PharmaBot 的高级设计，包括对话重要部分的里程碑。“安排预约”和“需要帮助其他任何事情吗？”都被标记为成功路径。

常见问题解答（FAQ）的意图只有一个里程碑（FAQ 响应），而预约流程则收集多个数据点。应该标记声明成功完成的里程碑。

当详细的结果模型与设计叠加时，它最为强大。当每次对话都有一个结果和一个“最后里程碑”时，你可以快速找到洞察。在图 3.13 中，我们看到 PharmaBot 在失败对话中的指标随时间变化，包括最后的部署日期。

图 3.13 当结果模型和对话设计叠加时，洞察变得明显。此图表按失败前的最后一步分解失败对话，有助于确定用户最困难的领域。不同的类别——如预约安排、意图检测和邮政编码输入——显示了它们随时间对总体失败相对贡献。在“部署更改”之后的峰值突出了最近更新的影响，为需要进一步优化的领域提供了洞察。

PharmaBot 团队可以进一步深入到失败的对话中，查看废弃和升级的详细结果。结合结果模型和对话设计可以启动你的数据驱动分析。它可以告诉你从哪里开始调查。

图 3.11 中的详细结果模型通过揭示对话失败的原因和地点，提供了对用户体验的更深入洞察。在这种情况下，结果是失败，主要原因是用户升级。然而，查看用户升级的具体点——在失败前的最后一步——提供了可操作的建议。图表中的分解突出了关键的升级点：在预约安排、意图检测、会员 ID 收集和邮政编码输入期间。部署更改后，意图检测步骤的失败率显著下降，而会员 ID 和邮政编码收集的失败率略有下降。然而，预约安排的失败率激增，表明一个新的摩擦领域。这种分析水平使团队能够有效地确定改进的优先级，确保他们的修复针对最紧迫的用户痛点。虽然遏制率通常被用作衡量有效性的高级指标，但它并不能讲述全部故事——一些遏制可能仍然导致糟糕的用户体验，一些转移可能是为了成功的结果所必需的。图 3.13 中的结果模型帮助对话人工智能团队区分这些情况，并相应地调整机器人。

客户满意度

在结果模型中，我们通过对话结果推断客户满意度。这是一个快速的方法，但它是间接的，可能会遗漏一些细节。更直接地了解客户满意度是有用的。

可以通过收集用户的直接反馈来衡量客户满意度。点赞或踩或数值满意度评分是标准的。这些指标的唯一缺点是用户响应率通常很低——许多用户讨厌提供反馈——尽管不满意的用户更有可能抓住机会抱怨。

您可以在聊天机器人结束互动后实施调查。调查可以包括关于易用性、有用性和对机器人整体满意度的提问。此外，还可以向用户展示净推荐者得分（NPS）调查。请保持调查简短：调查越长，用户完成的可能性就越小。

您还可以通过审查对话样本来评估客户满意度。审查可以包括完成对话的人类代理人的聊天记录或摘要。这些日志和摘要甚至可以使用大型语言模型进行分类。表 3.5 显示了您可以在每种对话结果类型中寻找的反馈类型。

表 3.5 将反馈与对话结果细节关联

对话结果细节	用户反馈	注意事项和警告
自动解决（成功）	正面反馈或无	用户可能会给出正面反馈来结束互动（“谢谢！”）。但这种情况不太可能：大多数用户一旦得到他们需要的东西就会断开连接。
转接（成功）	正面口头反馈或无反馈。不在聊天记录中。	用户可能对人类代理关于机器人的口头反馈，而不是直接对聊天机器人进行反馈。
放弃（失败）	负面反馈或无反馈（在流程完成前断开连接）	用户对机器人的最后评论可能带有负面情绪（“我讨厌这个！”）。但许多用户不会麻烦表达他们的挫败感——他们只是断开连接。

| 用户升级（失败） | 负面反馈 | 在流程中请求代理的用户不满意（“让我联系代理！”）。 |

|

机器人升级（失败）	无	当机器人启动升级时，我们无法证明用户不满意，但我们可以合理地假设如此。
立即断开连接（不希望使用聊天机器人）	未提供反馈（无参与）	立即断开连接的用户可能讨厌所有聊天机器人，可能讨厌你的聊天机器人，或者可能意外地连接到它。你无法确定。
立即升级（不希望使用聊天机器人）	未提供反馈，或口头负面反馈表示希望获得人类帮助而不是使用聊天机器人	立即升级的用户可能讨厌所有聊天机器人，可能讨厌你的聊天机器人，或者可能只是更喜欢人类。你无法确定。

3.3.3 覆盖范围

作为提高聊天机器人有效性的部分，识别机器人可以处理的内容（或者说，其覆盖范围）的差距，与解决升级问题一样重要。在持续的分析中，很明显，一些用户的问题并不是因为理解错误——它们只是没有被机器人的现有知识覆盖。随着团队发现这些差距并努力扩展 PharmaBot 的功能，场景继续进行：

该团队优先处理升级问题，因为它们对指标的影响最大。他们分析了升级对话的记录，并开始出现一些模式。用户通常在机器人不理解他们之后立即升级。数据分析师将这些实例与对话流程进行了交叉参考，并建议如何改进机器人的自然语言处理能力。在分析过程中，他们发现了一些 PharmaBot 无法回答的问题：

• “我听说有罕见的副作用。我如何区分疫苗接种后的症状和需要医疗注意的更严重情况？”

• “如果我错过了推荐的 COVID-19 疫苗的第二剂，几天后它仍然有效，还是需要重新开始？”

• “我怀孕了，我不确定是否可以接种 COVID-19 疫苗。你能提供有关孕妇安全性和潜在益处的信息吗？”

• “我被诊断出患有自身免疫性疾病。我还能接种 COVID-19 疫苗吗？我需要采取哪些额外的预防措施？”

• “我阅读了关于 COVID-19 疫苗长期效果的矛盾信息。关于它们在长期内的安全性有何了解，目前是否有正在进行的研究？”

对于这类问题，即使用户尝试重新措辞，PharmaBot 也会回答“抱歉，我不理解”。团队寻找具有相似特征的提问集群，以确定机器人接下来应该训练的内容。除了其他意图外，还出现了一组与疫苗安全相关的查询。

覆盖率衡量聊天机器人尝试有效回答的用户问题数量。覆盖率低的聊天机器人要么缺乏关键主题的训练数据，要么在重叠和模糊的意图上挣扎，类似的问题会混淆模型，并阻止它自信地选择正确的响应。

团队必须分析用户交互来提高覆盖率，识别聊天机器人无法提供有意义响应的空白点。这个过程涉及评估录音、跟踪失败的查询和确定当前未得到支持的重复用户需求。解决这些空白点可能需要细化训练数据、重构意图分类或引入检索增强生成（RAG）等替代方法。

几种方法可以增强聊天机器人的覆盖率，每种方法都针对不同的挑战：

• 第五章探讨了通过细化训练数据、解决缺失意图和优化标注策略来提高薄弱理解的方法。

• 第六章讨论了如何使用基于检索的技术结合生成式 AI（RAG）来绕过意图限制，提供更动态和更信息丰富的响应。

• 第七章展示了生成式 AI 如何生成额外的训练和测试数据，以扩展聊天机器人处理多样化查询的能力。

无论采用何种方法，提高聊天机器人覆盖率都需要对现实世界交互进行持续分析。检查用户话语、识别常见的失败点并对机器人的设计进行迭代，以确保它更有效地满足用户需求。

练习

1. 考虑以下聊天机器人和它们的企业目标。为每种聊天机器人类型制定合适的指标和目标，以评估其有效性和性能：

   • Bot 1——电子商务网站的客户支持机器人（问答机器人）

   • Bot 2——银行账户管理机器人（交易或流程导向型机器人）

   • Bot 3——电信公司的客户服务机器人（路由机器人）

2. 检查以下在 PharmaBot 聊天记录中发现的场景。根据 PharmaBot 对每个场景的响应，从模型中分配一个结果。一旦为每个场景分配了结果，请反思您观察到的任何有关机器人性能和潜在改进领域的模式或趋势。请记住，对话结果为成功、失败和用户不希望聊天机器人。

   • 场景 1

User: "I heard about rare side effects. How can I distinguish between post-vaccine symptoms and something more serious that requires medical attention?" 
PharmaBot: "Hello! It's essential to be informed about potential side effects. Common side effects of COVID-19 vaccines include soreness at the injection site, fatigue, and mild fever. However, it's crucial to seek medical attention immediately if you experience severe symptoms like difficulty breathing or chest pain." 
User: "Thanks for the information, but what if I'm unsure whether my symptoms are severe enough to warrant medical attention?" 
PharmaBot: "If you're unsure, it's always better to err on the side of caution and consult a healthcare professional. They can assess your symptoms and provide guidance tailored to your specific situation." 
PharmaBot: "Would you like me to connect you with a healthcare professional to discuss your concerns further?" 
User: "Yes, please. That would be helpful." 
PharmaBot: "Great! Please hold for a moment while I transfer you to a human agent who can provide personalized assistance. Your health is our top priority." 
PharmaBot: (Initiates transfer to a human agent)

1. • 场景 2

User: "If I missed the recommended second dose of my COVID-19 vaccine by a few days, will it still be effective, or do I need to start over?" 
PharmaBot: "Hello! It's important to follow the recommended vaccination schedule for optimal protection. If you've missed the second dose by a few days, it's best to contact your healthcare provider for guidance on the next steps." 
User: "I see. Will the delayed second dose affect the effectiveness of the vaccine?" 
PharmaBot: "The delay may impact the vaccine's effectiveness, but receiving the second dose as soon as possible is essential. Your healthcare provider can assess your individual situation and advise accordingly." 
User: "Got it, I'll contact my doctor for advice. Thanks for your help!" 
PharmaBot: "You're welcome! It's always best to consult with a healthcare professional for personalized guidance. If you have any more questions, feel free to ask."

1. • 场景 3

User: "Hi there. I have a question about the COVID-19 vaccine." 
PharmaBot: "Hello! I'm here to help. What would you like to know about the COVID-19 vaccine?" 
User: "Agent" 
PharmaBot: "Of course! Let me connect you with one of our human agents who can assist you further." 
PharmaBot: (Initiates transfer to a human agent)

1. • 场景 4

User: "Can you tell me about the ingredients in the COVID-19 vaccine?" 
PharmaBot: "Sorry, I don't understand. Could you please rephrase your question?" 
User: "What are the components of the COVID-19 vaccine?" 
PharmaBot: "I'm sorry, I still didn't quite get that. Can you try asking in a different way?" 
User: "What is the composition of the COVID-19 vaccine?" 
PharmaBot: "I'm having trouble understanding your question. Could you provide more context or try asking in simpler terms?" 
User: (hangs up)

3.4 识别和解决问题

识别问题对于持续改进对话式人工智能至关重要。聊天机器人团队需要一个处理问题的方法论，包括如何发现问题、如何作为团队进行推理以及如何确定何时解决问题。这个方法论将使团队能够朝着共同的目标努力。

3.4.1 发现问题

开始寻找问题的最佳方式是检查对话结果的趋势。看到成功的对话固然很好，但应关注失败和“用户不希望聊天机器人”的对话。深入研究具有上升趋势的结果。如前所述，当这些结果与您的对话设计叠加时，它们最具洞察力。用户在负面结果发生前做了什么？图 3.14 仪表板帮助了 PharmaBot 团队。

图 3.14 按最后一步操作分解结果，观察随时间的变化。

理想情况下，您的分析工具可以按以下方式计数和绘制对话：

• 对话结果

• 对话中的最后一步

• 对话的日期和/或时间

您的对话式人工智能平台可能已经跟踪了这些数据点。其他平台可能需要通过在对话流程的关键部分添加上下文变量来进行配置。有了这些指标，团队能够发现影响聊天机器人性能的意外用户行为。例如，当 PharmaBot 团队分析升级的对话时，他们发现了一个令人惊讶的模式：

PharmaBot 团队深入分析了升级的对话。他们发现当 PharmaBot 询问用户预约是否为疫苗或检测时，出现了许多失败。许多用户回答“是”——这个回答与预期的格式不符。

认识到理解用户行为的重要性，团队意识到机器人无法解释这种模糊的“是”响应，这导致用户感到沮丧。有些用户甚至在 PharmaBot 重复提问时再次说“是”。这是导致对话放弃和升级的令人惊讶的原因。

一旦找到问题区域，你就可以开始设计解决方案。设计受到问题遇到和解决方式的影响。在“意外肯定”场景中，有两种出路：处理“肯定”，或者尝试让用户停止说“肯定”。

让我们看看更多发现问题的方法。

定性问题探索

虽然指标和对话日志提供了有价值的见解，但一些聊天机器人问题仅通过定量分析难以检测。通过收集和分析用户反馈来启动定性改进工作，可以帮助你发现更多用户痛点。让我们看看 PharmaBot 团队是如何进行他们的调查的：

为了揭示更深层次的用户挫折，PharmaBot 团队通过收集和分析直接用户反馈启动了定性改进工作。他们鼓励用户通过调查分享他们挑战和期望的详细描述。一旦收集到反馈，团队将其分类以识别常见的痛点，如表 3.6 所示。

表 3.6 调查回应导致识别出的痛点（第一部分）

用户	调查回应	识别出的问题
1	我尝试询问不同州的疫苗资格问题，但机器人无法提供明确的信息。当我计划旅行时，不知道自己是否有资格接种疫苗，这让人感到沮丧。回复看起来很笼统，并没有解决不同地点资格标准的复杂性问题	PharmaBot 理解了基本意图（资格），但未能提供特定州的信息。聊天机器人没有考虑用户的地理位置或他们咨询的州，导致回复无助于解决问题。
2	我尝试安排疫苗预约，但整个过程感觉很混乱。机器人的指示不明确，我感到不确定我的预约是否成功预订。如果机器人能在整个预约过程中提供更多指导将很有帮助。	预约工作流程缺乏清晰性，导致用户对他们的预约是否成功预订感到不确定。
3	（未提供调查回应；用户离开了聊天）	过于复杂的步骤阻碍了用户完成流程。用户 3 没有完成调查。

与对话日志不同，定性反馈提供了对用户挫折的直接洞察——你不必推断出了什么问题。结合相应的对话记录，这种反馈为改进团队创造了一个更清晰的画面，使得诊断和解决聊天机器人缺陷变得更加容易。

招募用户提供可操作性的反馈可以显著提高聊天机器人的性能和用户满意度。然而，大多数用户都不愿意留下反馈。提供小额奖励或甚至简单的、真诚的感谢可以鼓励参与。如果反馈是您改进策略的关键部分，请考虑实施一个为用户和您的团队都创造双赢局面的系统。

警告：提供的示例提供了关于特定用户挑战的宝贵见解，但它们可能不具有统计学意义。不要基于孤立实例仓促采取解决方案。寻找已识别问题的重复发生，以衡量每个问题的规模和影响。

问题发现的数量化评估

虽然定性反馈有助于揭示用户的挫败感，但它也可以揭示可衡量的功能问题。像缓慢的响应时间或令人困惑的对话流程这样的挑战可以通过对话日志进行量化，这有助于团队诊断问题并优先考虑改进。让我们继续我们的场景，看看还发现了哪些其他问题：

除了找到描述性的 问题**之外，PharmaBot 团队还发现了可解决的功能 问题**。一个示例 问题 *在表 3.7 中展示。

表 3.7 导致识别出痛点的调查响应（第二部分）

用户	调查响应	识别出的问题
4	机器人几乎花了 5 分钟才告诉我疫苗预约的可用性。延迟非常不便，尤其是在尝试安排我的日程时。更快的响应会更有帮助。我去了机器人，以免被长时间等待！	过长的响应时间让用户感到沮丧，并降低了聊天机器人作为传统客户支持更快替代方案的价值。

通过分析对话日志中每一步所需的时间，可以识别出这类问题。你可以跟踪每个步骤的平均时间和最大时间。异常值可能表明后端系统性能不佳或用户花费大量时间思考的令人困惑的问题。

这种分析甚至可以在对话子集上进行。例如，响应缓慢的 API 更有可能导致用户断开连接。深入分析被遗弃的对话，审查用户说了什么以及各个步骤花费了多长时间。这种分析可以在不直接要求用户反馈的情况下进行。

通过识别与对话流程相关的具体挑战，分析师可以有效地针对对话系统的改进进行定位。

3.4.2 组合审查

在审查他们的对话结果指标和用户反馈后，PharmaBot 团队列出了一系列具体的 问题**。现在他们必须制定改进计划，从优先考虑 *问题**开始。

问题分级

在这些指标到位后，团队可以揭示影响聊天机器人性能的意外用户行为。例如，当 PharmaBot 团队分析升级的对话时，他们发现了一个令人惊讶的模式：

在 PharmaBot 中确定的最关键问题是频繁误解用户查询，尤其是在区分关于 COVID-19 检测和疫苗相关预约的查询时。当机器人不理解时，用户会感到沮丧，经常导致对话中断或升级。呼叫中心代理们一致认为，他们在听到沮丧的用户时听到了这个问题。分析确认了这个问题的高频次。

团队同意解决这个高优先级问题。业务目标是完成设置预约而无需人工代理干预。他们发现了一个预约完成失败的原因重复出现的模式：机器人对用户想要的预约类型感到困惑，用户感到被误解——许多交易都失败了。机器人既让人难以理解，又过于复杂。

在发现问题后，团队必须系统地评估和根据其感知价值和预期对系统的影响优先级排序问题。这包括评估诸如问题发生的频率、实施修复的成本以及解决问题的潜在好处等因素。通过采用结构化的优先级排序方法，他们可以确保改进带来最大的价值，同时利用可用的资源。在 PharmaBot 场景中，最高优先级是解决关于预约类型的误解，因为这直接影响了完成预订工作流程的能力，这是核心业务目标。图 3.15 展示了问题的一个样本评估。为了更全面地描述，洞察可能包括问题的数量、对话结果、受影响用户的修复复杂性、其他受影响的流程等等。

图 3.15 Schedule Appointment 流程中升级对话增加的分析，确定潜在原因（引导用户联系代理的新措辞）并提供改进建议

图 3.15 中展示的问题分析可以通过帮助根据效果和解决复杂度优先级排序聊天机器人改进，从而对更广泛的三级分类过程做出贡献。每个问题都以类似的方式进行记录，包括对问题的洞察、可能的原因和提出的解决方案。在完整的三级分类过程中，许多此类问题条目根据效果、频率和解决努力进行评估，以确定优先级。最佳的优先级实践考虑价值、预期成果和预期回报。你必须进行成本/效益分析。效益可能是直接的（提高控制），也可能是间接的（改善用户体验）。成本可能包括时间、努力和修复的复杂性，需要多个部门同意的修复将花费更长的时间。预期回报考虑了效益和成本，并按受影响的对话量进行缩放。目标是关注那些预期回报足以证明时间和资源投资的领域。图 3.16 展示了问题预期回报计算的示例。

图 3.16 用户在放弃聊天机器人对话并感到沮丧后达到呼叫中心代理的成本评估

当给定的对话流程由人工代理处理而不是通过聊天机器人时，成本效果可以很容易地计算。这个计算考虑了每次通话的代理成本、每天的总通话次数以及转交给人工代理的对话率。当有这种财务效果的支持时，为这个问题分配优先级要容易得多。这个计算可以重复应用于所有问题类型。记住，一些成本是间接的：例如，一个粗鲁的机器人可能会降低客户满意度，这使得量化财务效果变得具有挑战性。

努力是另一个重要的优先级驱动因素。正如问题本身有成本一样，实施修复也有成本。努力指的是实施过程中涉及的时间、资源和复杂性。关键是平衡问题的紧迫性与实施速度。最好的修复问题是效果高且努力低的问题。首先，解决那些效果高且容易解决的问题。图 3.17 根据效果和实施它们所需的努力对改进机会进行分类。

图 3.17 一个效果-努力矩阵展示了所需努力与提议变更潜在效果之间的关系。

高优先级项目具有高效果和低努力，其次是中等优先级项目产生渐进式结果。低优先级项目是那些效果低且努力高的项目，它们是修复的较差候选者。这个矩阵可以帮助团队有效地优先处理他们的努力，专注于那些以最少的努力提供最大潜在效果的改变。

我们可以更深入地探讨矩阵中提出的分类。对于每个分类，我们可以提供示例问题、它们引起的用户痛点以及它们可能发生的原因。表 3.8 从一些高效、低努力问题开始，表 3.9 展示了高效、高努力问题的示例。表 3.10 概述了一些中效、高努力问题。

表 3.8 高效和低努力问题示例

问题	用户痛点	问题可能发生的原因
对话响应不正确或不足	聊天机器人不理解	由于意图识别不良、输入验证不足或未能适应用户的上下文，导致响应不正确。
对话响应差	聊天机器人过于复杂	格式和/或文本没有清楚地传达信息。
对话树损坏	聊天机器人无法工作	由于对话流程中的条件和不正确的转换配置错误，聊天机器人无法正常工作。这些错误发生在确定聊天机器人如何从一个步骤移动到另一个步骤（“跳跃”）的逻辑有缺陷或未经过彻底测试时。结果，用户可能会遇到死胡同、不相关的响应或突然的对话中断，这会负面影响控制和用户满意度。
流程增强	聊天机器人过于复杂	有特别复杂的步骤，用户难以完成。这在长时间对话中尤其可能。

表 3.9 高效、高努力问题示例

问题	用户痛点	问题可能发生的原因
用户无法完成流程	聊天机器人过于复杂	在流程的许多不同步骤中发生故障，需要完全重新设计流程。
用户问题完全没有得到解答	聊天机器人不理解	实现的意图不足以覆盖用户需求。这可能需要添加搜索或检索增强生成来处理不常见的问题类型。

表 3.10 中效、高努力问题示例

问题	用户痛点	问题可能发生的原因
对话响应不完整（由于 API 失败）	聊天机器人不理解	由于 API 失败，响应不完整。机器人可能不支持所有 API 请求或响应变体。
意图混淆	聊天机器人不理解	当训练数据不平衡时，可能会发生意图混淆，这意味着某些意图的示例语句太少或太多，导致错误分类。此外，训练数据与现实世界用户查询之间的差异可能会使聊天机器人难以识别正确的意图。

这些分类并不是固定不变的。您应根据问题发生的频率调整变更的相对优先级。

解决高级修复方案

一旦确定了高优先级问题，下一个关键步骤就是解决问题—概述一个高级修复方案以纠正问题。这需要团队的合作努力，共同制定一个全面的解决方案。为确保结构化的方法，团队必须解决三个基本问题：谁将负责实施修复？需要做出哪些改变？解决方案将如何实施？“谁”涵盖了实施修复的团队的具体角色和责任。“什么”定义了解决方案的性质，无论是改进机器人的自然语言处理能力、提高上下文理解能力，还是实施更复杂的意图识别系统。“如何”概述了实施所需的技术方法和方法论。

此外，团队必须确定涉及的开发工作量，考虑因素包括编码复杂性、集成需求和对外部系统的潜在依赖。这个解决问题阶段对于制定持续改进的明智计划至关重要。

为所有修复分配优先级

优先级修复表是指导改进活动的不可或缺的工具。该表通过分配优先级编号、阐述已识别问题的简洁描述、提出推荐变更、量化对用户体验的潜在影响，以及提供直接链接到相关 GitHub 问题，封装了一个结构化的方法。这个全面的框架不仅简化了开发过程，而且促进了团队成员之间的高效沟通和协作。图 3.18 显示了优先级修复表的示例。

图 3.18 优先级修复表的示例

表格中的每一列在有效组织和解决问题上都发挥着关键作用：

• 优先级—有助于确定每个问题的紧迫性，确保首先解决关键问题。

• 描述—提供对已识别问题的简要但清晰的概述。

• 推荐变更—指定为纠正问题而提出的解决方案或修改，指导开发工作。

• 价值/效果—量化了推荐变更带来的预期改进，在优先级排序中提供帮助。

• ID—建立与项目问题跟踪器中相应问题的直接链接，例如 GitHub 仓库。这简化了协作并跟踪每个问题的解决进度。GitHub 问题也可能提供对问题的进一步阐述、进度和状态。

3.4.3 确定验收标准

一旦关键问题有了优先级和高级解决方案，下一步就是定义修复的接受标准。简单来说，我们如何知道这个问题已经解决？接受标准对于验证开发环境中的功能以及在生产中验证改进是有用的。

例如，当 PharmaBot 无法处理“是”对“您的预约是疫苗还是检测？”的响应时，接受标准可能如下所示：

1. 当 PharmaBot 询问用户是选择疫苗还是检测，并且他们回答“疫苗”时，他们会得到疫苗预约。

2. 当 PharmaBot 询问用户是选择疫苗还是检测，并且他们回答“检测”时，他们会得到检测预约。

3. 当 PharmaBot 询问用户是选择疫苗还是检测，并且他们回答“是”时，它会要求他们确认他们想要疫苗预约。

这些接受标准帮助测试团队验证当前功能（标准 1 和 2）和新功能（标准 3）。修复不能部署，直到它满足接受标准。

一旦修复部署，团队可以验证“疫苗或检测”问题的“是”回答导致对话结束（和失败）的数量显著减少或完全消失——例如，原始指标是否有所改善？清晰和可衡量的标准确保您的团队与用户期望和项目目标保持一致，为聊天机器人改进的成功奠定基础。

练习

1. 以下示例问题与对话式人工智能实施相关，每个问题的复杂程度不同。您的任务是根据这些问题对对话式人工智能系统有效性和效率的影响进行优先排序，同时考虑定性和定量量度指标。将问题的复杂性作为您优先排序的输入。这些例子涵盖了各种行业，因为改进和优先排序的努力适用于各种聊天机器人和领域。

   1. 不准确的响应生成：

   • 描述：聊天机器人偶尔会提供不准确或不相关的响应来回答用户查询，导致用户不满和困惑。

   • 影响：高——它影响用户体验和对聊天机器人能力的信任。

   • 量度指标：每天不准确响应的频率（例如，总响应量的 15%）。

Sample Chat: 
User: "Can you tell me about the vaccine side effects?" 
Chatbot: "The COVID-19 vaccine is safe and effective."
User: "But I heard about people experiencing severe reactions.   Can you provide more information?" 
Chatbot: "The vaccine is safe and effective."
Users: (hangs up)

1. 1. b. 响应时间慢：

      • 描述：聊天机器人生成响应的时间太长，导致用户沮丧和缺乏耐心，尤其是在时间敏感的情况下。

      • 影响：中等——它负面地影响用户对聊天机器人的满意度和参与度。

      • 量度指标：每天误解语言的用户查询百分比（例如，总查询量的 8%）。

Sample Chat: 
User: "Can you give me the scoop on the COVID jab?" 
Chatbot: "I'm sorry, I don't understand what you are asking. Could you please rephrase your question?"

1. 1. c. 有限的语言理解能力：

      • 描述：聊天机器人难以理解使用口语化语言、俚语或复杂语法的查询，导致误解和不充分的响应。

      • 影响：中等——这限制了机器人与用户有效互动的能力，导致用户沮丧和满意度降低。

      • 量度指标：每个用户查询的平均响应时间（例如，8 秒）。

Sample Chat: 
User: "Can you provide information about COVID testing locations?" (Long pause, user hangs up.)

1. 1. d. 与后端系统集成不一致：

      • 描述：聊天机器人在与后端系统集成时出现不一致，导致向用户提供的信息不完整或不正确。

      • 影响：高——这损害了聊天机器人的可靠性，并侵蚀了用户对其提供准确信息的信任。

      • 量度指标：每天与后端集成错误的对话百分比（例如，总对话的 12%）。

Sample Chat: 
User: "Can you check if there are any vaccine appointments available tomorrow?" 
Chatbot: "I'm sorry, I'm experiencing some technical difficulties. Please try again later."

1. 2. 使用您最新实施中的样本对话，并使用聊天机器人的数据重复前面的练习。

3.5 开发和交付修复

持续改进通常通过固定周期的迭代实现，通常称为冲刺。冲刺迭代从一到四周不等，具体取决于您组织的偏好。虽然优先级修复表提供了一个大致的路线图，但冲刺计划具体定义了下一批要交付给用户的功能。冲刺计划受资源可用性的影响：在特定时间内您可以开发并测试多少工作量。它还使利益相关者为接下来可以从您的解决方案中期待什么做好准备。

3.5.1 冲刺规划

此过程建立了一个系统性的问题跟踪和解决方法。它作为良好协调、敏捷开发旅程的基石，确保您的机器人与提出的解决方案保持一致，并在指定的时限内发展。存在各种工具，如看板，用于在整个冲刺期间可视化冲刺的状态。最基本冲刺可视化应包括正在解决的问题及其在计划或执行周期中的状态。图 3.19 显示了一种可视化，它通过增加两个额外的列（状态和时间线）来增强修复表（图 3.18），指示计划中的冲刺。

图 3.19 显示了一个包括开发冲刺的优先级表。可能还会添加更多列，包括 UAT 时间和预期部署日期。

3.5.2 再次衡量

PharmaBot 团队努力进行改进。当这些改进进入生产阶段时，团队监控了他们预期会影响的指标。通过跟踪与过去两次部署的失败结果，他们确认了修复按预期工作。

图 3.20 显示了 PharmaBot 团队使用的仪表板。

图 3.20 跟踪对话结果与变更部署的关系

练习

1. 冲刺计划对于解决 PharmaBot 的开发和交付过程中的修复和改进至关重要。在这些练习中，你将模拟一个冲刺计划会议，以优先考虑 PharmaBot 迭代开发周期中的修复和增强。你拥有两位对话分析师、一位兼职后端开发人员和一位测试人员：

   • 审查你在上一项练习中创建的优先级修复表。

   • 考虑开发团队的容量和速度，并分配资源。

   • 创建冲刺计划。使用看板或类似工具创建一个冲刺计划，包括优先考虑的修复和增强，以及估计的努力程度和预期完成时间。考虑添加状态和冲刺包含列以跟踪进度并确保冲刺过程中的透明度。

   • 讨论针对冲刺计划中计划的修复和增强功能的预期部署日期。

摘要

• 对话系统的持续改进周期是一个持续、迭代的进程。

• 所有改进都应朝着预定义的商业目标和用户满意度驱动。

• 严谨的指标定义、正确的监控工具选择以及对最佳实践的承诺是关键。

• 使用与你的机器人相关的“正确”指标，而不是那些最容易衡量的指标。

• 详细的对话结果允许你针对特定的一组对话进行改进。

• 几个因素可以确定问题的优先级，例如其发生频率、预期的改进和修复的复杂性以及团队的容量。

• 回归测试和改进分析对于确保改进已经发生至关重要。

第二部分模式：AI 不理解

“聊天机器人不理解我”是用户在与对话式人工智能互动时遇到的最常见的痛点。对于传统聊天机器人，这通常是由于分类器训练不当造成的；对于其他聊天机器人，可能是由于搜索机制不佳或简单地没有访问到正确的信息。

无论你正在构建哪种类型的聊天机器人，你需要的核心能力是理解用户的需求并做出相应的回应。能够理解请求的聊天机器人会给出有用的回答；而那些不理解请求的聊天机器人可能会说“很抱歉，我没有理解——你介意重新表述吗？”

有多种方法可以解决理解能力不足的问题，所有这些方法都依赖于识别用户想要完成什么以及他们如何表述他们的请求。第四章重点介绍如何从日志和其他来源中提取这些数据。第五章展示了如何通过训练分类器来提高聊天机器人的理解能力，第六章通过检索增强生成（RAG）将生成式 AI 添加到运行时组合中。第七章在训练和测试时使用生成式 AI，通过使用 LLMs 创建新的训练和测试数据。

第四章：理解用户真正想要什么

本章涵盖

• 识别理解能力薄弱的指标

• 衡量聊天机器人的理解能力

• 评估您的聊天机器人的当前状态

• 收集和准备日志数据以衡量聊天机器人的理解能力

• 解释初始日志数据

一款好的聊天机器人体验通常与聊天机器人能够识别（理解）用户需求相关。这是您将用来衡量性能的关键指标之一。有时，聊天机器人部署后，其初始理解能力很强（或者至少对于试点项目来说“足够好”）。然而，随着时间的推移，您可能会注意到它返回了错误的答案。也许您的用户开始更多地抱怨，无论是直接向聊天机器人（“这没有回答我的问题！”）还是通过调查反馈。参与度可能呈下降趋势，而放弃率可能呈上升趋势。您可能会从呼叫中心那里听到关于本应由虚拟助手处理的升级问题。这些都是您的对话解决方案可能存在理解能力薄弱的迹象。

理论上，聊天机器人应该随着时间的推移而变得更好，但理解能力下降的情况并不少见。我们希望帮助您识别在您的解决方案中何时以及为什么会发生这种情况。我们将解释如何避免一些陷阱并规划解决方案生命周期中的常见情况。在本章中，我们将探讨您的对话人工智能在正确识别或分类用户目标（即理解用户）方面的“良好性能”意味着什么。我们还将提供用于测量分类器性能或评估生成响应的数据准备技术。

4.1 理解的基础

被理解是人类交流的基本方面。在对话人工智能中，我们使用自然语言处理技术来尝试理解用户想要或需要什么。由于用户可能想要的事情的范围几乎是无限的，以及他们可能用词语组合来表达这些愿望或需求的方式也是无限的，因此这是一个非常难以解决的问题。

4.1.1 理解能力薄弱的影响

被聊天机器人不理解可能是用户最大的挫折来源。他们来到您的聊天机器人是为了获取答案，他们可能得到了答案，但这可能与他们的问题无关。也许聊天机器人指示他们重新措辞问题，所以他们用不同的词语来表达相同的目标。有时这有效，有时他们会收到要求他们重新措辞（再次！）的响应。通常情况下，如图 4.1 所示，您的用户在失败一两次后最终会要求与代理交谈。

图 4.1 准确性或覆盖问题会使用户感到沮丧，因为这需要更多的时间——有时需要多次联系才能达到他们的目标。这也导致用户对虚拟代理失去信心。

如果这种情况发生在您的用户身上，您的聊天机器人很可能存在准确性（聊天机器人匹配所听到的内容与所知道的内容的能力）、覆盖范围（解决方案预期了解的主题范围）或两者兼而有之的问题。从外部来看，几乎无法判断根本原因是什么。为此，您需要收集数据。没有这些信息，很难知道要修复什么——修复错误的事情可能会使现有问题更加复杂。很快，您的对话解决方案就会变得昂贵且难以维护。更糟糕的是，它没有提供它承诺的价值（未能减少，甚至可能增加，对人工干预的需求）。

聊天解决方案最大的成功因素之一是组织如何处理解决方案的持续维护。理想情况下，项目发起人和支持团队将设定预期，即解决方案需要迭代改进——尤其是在开始时——因为它会接触到来自现实世界用户的更多数据。尽管自动学习、大型语言模型和生成式 AI 取得了进展，但聊天机器人并不倾向于随着时间的推移而神奇地变得更好。

预计在整个聊天机器人的生命周期内投入支持资源

组织是否认为聊天机器人应该是一个“设置后即可忘记”的解决方案？是否存在对虚拟助手持续维护和喂养的缺乏承诺？这些都是忽视的红旗，几乎可以保证最终会失败。

聊天机器人本质上是一个数字员工。就像人力资源一样，它需要初始培训以及偶尔的再培训、强化和获得新技能的机会。

4.1.2 弱理解的原因是什么？

这些是聊天机器人理解能力下降最常见的原因：

• 制造的训练数据（不反映代表性用户词汇的训练示例）

• 范围不足或主题覆盖范围存在差距

• 世界上新信息未传递给虚拟助手

• 在添加新意图、更新现有意图或更改模型推理参数时缺乏审查或守门人流程

那最后一个观点——缺乏守门人流程——导致了最难以解决的薄弱理解问题。如果没有知识渊博的所有者或专门的模型训练团队的监督，未经审查的更改会迅速加剧薄弱理解的问题。在传统的分类器中，不熟悉整个训练集的人所做的模型更新往往会引入重复、意图训练冲突以及在意图之间训练示例数量的不合理差异。未经测试的模型参数或提示更改会在生成模型中引起意外的行为。

事实上，我们看到了一个客户在修改他们的分类器训练集时发生的情况，在九次生产部署过程中，总意图从 21 增长到 53。业务并没有立即看到效果；相反，随着时间的推移，这些未经测试的更改的结果表现为调查结果不佳、旅程不完整、不必要的升级和大量的负面反馈。主题专家报告说，机器人对于它曾经回答正确的问题现在给出了错误的答案。这些都是理解薄弱的经典症状，但他们无法确切指出这一切是从何时开始的。一系列针对他们先前版本的逆向实验讲述了这个故事，如图 4.2 所示。

图 4.2 对分类器性能的逆向评估显示了关于未经测试的更改随时间影响的艰难教训。如果每个版本都作为预部署过程的一部分进行测试，团队就会推迟任何版本更新，直到分类器问题得到解决。恢复分类器良好工作状态花费了数周时间。

4.1.3 我们如何通过传统的对话式人工智能实现理解？

传统的（非生成式）对话式人工智能系统是通过摄入按意图分组（有时称为分类或聚类）的用户请求示例进行教学的。意图包含各种释义，它们都表达了相同的目标。一些系统还纳入了实体，这些实体就像关键词，进一步细化请求的意义或规格。

对话逻辑被配置为识别意图（或意图+实体的组合）并根据该识别采取行动。这个行动可能只是回答一个问题，或者它可以启动一个复杂的交易性交流。表 4.1 显示了对话交流中意图、实体和可能的下一步的示例。

表 4.1 示例话语可能根据实体的存在与否而有所不同。

话语	意图	实体	可能的下一步
“我能检查多少件行李？”	Bag_Allowance		显示行李检查政策
“我想预订一张机票”	Book_Flight		收集目的地
“我需要一张单程机票去哥斯达黎加”	Book_Flight	哥斯达黎加	收集出发详情
“我想升级我的座位到头等舱”	Flight_Upgrade	头等舱	启动升级流程

使用传统分类技术的机器人类型通常是主题路由代理、问答（FAQ）机器人，以及在某种程度上以流程为导向（自助）助手。请记住，基于分类的机器人依赖于一组预定义的问题主题（意图）。你需要提前知道你期望你的机器人遇到哪些问题。

从实际的角度来看，你教给系统的主题或意图的范围将特定于你的领域和解决方案的使用案例或目的。作为解决方案的所有者，我们的一项主要和持续的任务是调整我们的系统，以正确理解最大量的用户需求。在主题广度和深度之间找到理想的平衡可能很困难，通常需要权衡。例如，训练一个分类器以理解所有可能的主题并不经济。此外，试图这样做可能会削弱其对用户关注的主题的理解。

当一个组织试图训练一个分类器以检测所有可能的主题时，分类器在所有意图中看到清晰区分的能力可能会减弱。如果你系统中训练的意图不能代表用户需求（意味着你有大量低频主题），它们往往会引起准确性和置信度方面的问题。图 4.3 展示了“长尾”图表；基于分类器的聊天机器人最大的商业价值通常是通过关注高至中频请求来实现的。低频请求通常由某种回退机制处理，例如升级、搜索或生成式 AI。

图 4.3 随着请求量向右减少，图表呈现出长尾的形状。每个用例都必须定义与主题覆盖相关的深度和广度的最佳权衡。商业价值的截止点通常在中等频次范围内。这并不是说应该排除所有低频请求，但扩展你的分类器对这些主题的覆盖范围可能带来递减的回报。

在初始发布之前，你需要预测哪些主题对于你的机器人理解来说将是最重要的。这些预测通常基于人类交互的日志、呼叫中心指标、焦点小组、调查或其他研究或信息收集活动。你的重点应该是训练你的模型擅长识别这些请求，以及任何其他辅助对话维护意图（如问候、闲聊、重复和升级）。一旦你的解决方案投入生产，你需要通过收集和分析你的对话交互数据来验证这些预测。

4.1.4 我们如何使用生成式 AI 实现理解？

生成式 AI 模型是如何实现理解的？这是一个陷阱问题，因为生成式 AI 并不是真正理解话语的意义，而是创建看起来像它所训练的数据的新数据，使用话语作为参考点。这是一个细微的区别，但使用生成式 AI，我们试图通过指示模型从一个特定的观点评估输入，然后生成特定类型的输出来模拟理解。

尤其对于对话式 AI，我们的目标是生成反映或针对用户请求的具体和/或个性化的输出（而不仅仅是高级分类，如主题分类或实体提取）。图 4.4 展示了分类模型输出和生成模型输出之间的基本区别。

图 4.4 传统的分类模型使用监督学习来预测几个预定义分类中的一个。它们寻找用户输入的意图或含义。生成模型使用解码器变压器来创建文本补全。它们预测用户输入之后最有可能出现的下一个序列的标记（大致上，是单词或字符）。

关于 LLM 基础架构的简要说明

仅编码器架构最适合非生成用例，例如基于文本嵌入训练预测模型。它们专注于从输入中提取有意义的内容，并需要标记数据进行微调。

仅解码器架构专门为生成 AI 用例设计。它们通过摄入大量数据以无监督方式“训练”。它们专注于预测序列中的下一个标记，并可以指示执行特定任务，包括分类、问答和摘要。

一些 LLM 模型架构是编码器-解码器，这意味着它们可以支持生成和非生成用例。这些通常用于输入很大但输出相对较小的场景，如翻译或摘要。

与基于传统分类器的 AI 不同，生成模型没有预定义的意图列表，这些意图是“在范围内”的。但像传统 AI 一样，你仍然需要很好地掌握领域知识以及用户可能带到你的机器人那里的问题的范围。这将指导你采用的策略，以促使你的 LLM 产生响应，表明用户输入已被理解。你可以使用以下几种有效的工具来完成这项任务：

• 选择适合工作的正确模型——一些模型更适合对话输出（而不是生成代码或撰写文章或新闻文章）。

• 提示工程——这种技术向模型提供输入以产生最佳输出。这些输入可能包括指令、上下文、输入数据和输出指示器。提示工程通常可以实现良好的理解模拟，并可以指示模型以对话风格产生输出。

• 单次或少量提示——你可以通过一个或多个你希望模型生成的输出和格式的示例来增强你的提示。

• 参数调整——温度、top-p和 top-k等参数会影响生成文本的随机性和多样性。增加这些值通常会提高生成响应中的“创造力”。

• 检索增强生成（RAG）——RAG 可以增强机器人理解的感觉，同时保持生成的答案基于你的领域。许多企业在其对话式解决方案中使用 RAG，以确保生成的响应基于外部、可验证的事实和最新信息。

在撰写本文时，企业对话式解决方案最常使用生成式 AI 作为问答（Q&A）机器人。大多数使用这项技术的面向商业的聊天机器人并不是完全生成式的——它们通常采用混合方法，包括分类（具有预定义的响应对）、面向任务的流程和生成响应。生成的响应可以纳入对话设计，作为后备选项（例如，当分类无法以足够的信心预测意图时）或两者兼而有之。

生成式 AI 也可以通过在提供“预配置”（预先配置的）对话响应或启动任务流程之前插入个性化的问候或问题摘要来增强分类响应输出。做得好，这可以在更深的层面上吸引聊天机器人用户，通过承认用户的特定情况来表现出“理解”和同情。

练习

反思你目前正在构建或支持的解决方案。问问自己这些问题：

1. 我的解决方案是否表现出任何弱理解的症状，例如

   • 给出错误的答案，尤其是与输入主题不相关或完全不相关的答案

   • 比预期更频繁地采取后备/其他/升级路线

   • 在看似简单的请求中，比预期更频繁地进行去歧义或明确主题（对于采用去歧义功能的解决方案）

   • 产生过时或不正确的信息

   • 收到负面反馈或较差的 NPS 评分

2. 我的解决方案最初是如何进行训练和测试的？如果它已经被部署，是否进行了基线测量？

3. 解决方案是否已经更新以识别新的主题并产生准确和最新的答案？

4. 谁被允许对解决方案进行修改？这些修改是否被记录？在修改后是否对解决方案进行了监控以确保修改产生了预期的效果？

4.2 如何衡量理解？

对于聊天解决方案，理解通常以准确性来衡量。对于分类器，这意味着能够准确预测意图。对于生成模型，这是创建正确和有用输出的能力。有多种方法和工具可以衡量解决方案理解用户输入的程度。你采取的方法将取决于你的解决方案使用的技术（传统、生成或两者兼有）以及你目前所处的阶段（预部署或已部署）。

4.2.1 衡量传统（基于分类）AI 的理解

分类器的性能是通过准确率、精确率和召回率来衡量的。准确率是指正确预测的比例。召回率指的是分类器识别正确意图的能力，而精确率是指分类器避免给出错误意图的能力。较高的准确率通常与“良好的理解”感知相关联。如果聊天机器人不理解用户的意图，它就无法提供预定义的响应或调用正确的流程导向流程。

您可以使用一些数据科学技术来评估分类器的性能，例如k折交叉验证或盲测试。盲测试指的是给定的测试话语在训练集中尚未存在；即，分类器之前没有“看到”这个话语。您的测试集可能是人工制造的，例如使用 AI 生成数据，或者具有代表性（从日志中提取的实际用户话语构建）。k折和盲测试可以提供有关模型整体准确性的信息，以及报告其召回率和精确率。此类测试产生的指标有助于确定模型表现良好的地方以及可能混淆的地方。第五章包含改进分类器理解的详细说明，因此我们在这里只概述测试方法。

使用 k 折交叉验证来衡量理解程度

如果您的聊天机器人尚未部署，k折交叉验证测试是衡量准确率最简单、最易于访问的方法，因为它不需要额外的标注数据。它仅使用现有的训练集。这种方法本质上衡量的是您数据标注的内部一致性——高准确率分数主要表明您的训练示例与其他类似示例分组。该过程涉及从训练集中抽取一定比例的数据，创建一个临时的盲测试集。剩余的数据用于创建临时的分类器。接下来，每个盲示例都运行在分类器上，并对预测进行评分。最后，临时盲集被折叠回训练集中。这个过程重复k次，以便每个示例都用作训练示例和测试话语，但永远不会同时用作两者。

k折测试将为您提供分类器准确率的预测，假设您用于训练模型的数据代表模型在生产部署时将遇到的输入。然而，这可能导致一种虚假的安全感，尤其是如果您的训练数据高度人工制造或与实际用户话语不太相似。另一个注意事项是，如果数据不足以保留用于测试的示例，同时仍然用最小足够的示例训练每个意图，小型数据集可能会产生不可靠的测量结果。因此，一旦解决方案投入生产，k折测试不是首选的测试方法。

使用 AI 生成的盲测试数据衡量理解

通过生成过程获取测试数据与获取生成的训练数据的方式相同：你提示模型生成示例的变体，并将它们用作“盲”测试集。这种方法最适合在部署前使用，但在上线初期阶段也可能适当，以补充生产日志中的空白。

与k-折测试一样，你的准确性测量的有效性完全取决于测试数据是否紧密地反映了模型在生产运行时接收的输入。这种方法可能容易受到偏差和过拟合的影响。因此，我们建议谨慎行事，并建议你一旦可用，就验证你的生成数据与生产日志。

使用代表性盲测试数据衡量理解

如果你的聊天机器人已经部署，生产日志是评估聊天机器人准确性的关键工具之一。这些日志包含了关于用户提出的问题以及他们如何表述这些请求的真实代表性数据。当我们说“代表性”时，指的是系统触发意图的实际情况以及能够捕捉用户目标的表述——无论他们自然地使用什么样的词语组合。

使用生产日志将产生最少的偏差测试数据，但也需要一定程度的初始手动努力。然而，这种努力是值得的，因为你将创建一个可重复使用的资产，用于测量未来的变化。你需要获取这些日志的样本，并对照系统返回的意图审查客户输入（表述）。这些数据需要由能够识别表述所属的最终正确（即“黄金”）意图的人类进行标注。你的初始标注将为你提供一个基线准确性。然后，这些数据将被用来构建你的代表性盲测试集，这实际上是一个包含测试问题和答案关键的所有内容都在一个文件中的列表。

选择适合你情况的最佳方法

每种方法的成本和努力之间的权衡完全取决于你解决方案的大小和当前阶段（部署前或部署后）：

• K-折交叉验证可能看起来“便宜且容易”，因为它不需要除训练目的之外的人工标注。然而，运行你的实验k次可能会有 API 成本。对于较小的系统，这种成本通常可以忽略不计，但对于较大的系统，每次实验可能会产生数千或数万次 API 调用。

• 生成的测试数据集除了生成数据所需的成本外，还包括运行实验的 API 成本。

• 一个代表性的盲测试集可能在运行实验时具有较低的 API 成本（与k-折相比，假设您的测试集小于您的训练集），但人工标注的成本可能很高。这也要求解决方案处于生产状态，与真实用户互动。好处是实验结果将比k-折和生成的测试集结果更有意义。

总结来说，有三种主要方法可以衡量您的分类器理解用户的能力。您选择的方法应与您当前的开发或部署阶段相一致，如图 4.5 所示。

图 4.5 K-折交叉验证和生成的测试数据适用于无法获取代表性数据的情况。一旦解决方案部署到生产环境，代表性的盲测试数据将产生对您的分类器理解能力的最可靠测量。

4.2.2 测量生成式 AI 的理解能力

测量一个生成的答案是否展示了“良好的理解”是一项艰巨的任务，并且自动测试方法仍在不断发展。我们的挑战是生成式 AI 的本质：每个生成的响应都是可能的，或者很可能对每个用户输入都是独特的。

在您部署带有生成式 AI 的解决方案之前，您应该定义您的机器人如何展示良好的理解。对于生成式对话 AI，我们建议您通过以下维度定义“良好的理解”：

• 生成的答案符合任何指定的输出格式或风格，包括

  • 机器人的定位（机器人角色的目的和视角）

  • 机器人角色的指定语气和个性

• 生成的答案在内容长度和结构上适合用户的输入（例如，用户输入的性质是否需要简短回答、逐步说明或详细论文？）。

• 生成的答案不包含虚假信息（幻觉）。

• 生成的答案不包含仇恨、滥用、粗俗、偏见和歧视。

• 生成的答案不包含有害信息——即使内容真实——这样一家公司可能会因法律责任或声誉受损（例如，对竞争对手的负面评论或泄露敏感数据）。

• 生成的答案对提示注入尝试具有抵抗力。

• 生成的答案正确且完整，要么成功终止流程，要么推进流程到下一步或最佳下一步行动。

如果您的解决方案已经部署，请获取您日志的代表样本。进行手动审查以评估您机器人的理解水平。每个生成的答案将根据您为解决方案定义的维度进行判断，判断其是否正确、充分或适当。

当然，这会耗费时间，但付出的努力将得到回报。你的注释集可以用作未来改进的黄金测试集。这个测试集将为你提供跟踪模型参数（如温度、top p、top k）和其他 LLM 配置设置变化影响的基准。这些样本还可以告知你在提示工程或微调中包含的任何少样本示例（样本输入与期望输出配对）。

4.2.3 使用直接用户反馈衡量理解

一种在规模上衡量良好理解的方法是将答案反馈机制直接融入用户体验中，例如点赞/踩回复选项。这种方法可以用于传统和生成式解决方案。

注意你征求反馈的频率，并了解你的反馈有何目的。评分意在反映体验的哪个方面：对特定答案（针对问答用例）的满意或不满意，自助流程及其结果（针对流程导向型机器人），还是整体对话体验？

练习

1. 探索并记录你的解决方案（或根据需要审查和更新它），重点关注最负责展示理解的部分：

   • 对于分类器，这意味着审计训练数据。

   • 对于包含搜索和检索的解决方案，审计源文档或 URL、任何补充文档丰富化以及摄入计划，以确保你的知识库包含最相关和最新的信息。

   • 对于生成式 AI 解决方案，审计引发生成响应的对话流程，并将提示、参数和 LLM 设置映射到预期结果。

2. 反思你当前的测试方法，如果有。你是否有任何可以与当前理解薄弱症状相关的历史测试指标？

3. 思考本节中提出的测试方法。哪种方法对你的解决方案生命周期当前阶段最优化？

4.3 评估当前状态

在开始制定改进计划之前，你将想要评估解决方案在准确识别用户目标和需求方面的能力。你的评估性质将取决于你的解决方案使用的技术。分类和生成模型执行非常不同的功能，因此有不同的方面需要评估。

4.3.1 评估你的传统（基于分类）AI 解决方案

对于传统 AI，首先审查训练集，以便了解领域和当前范围：

• 你的解决方案中使用了多少个分类器？

• 系统或每个分类器处理了多少个不同的意图？

• 每个意图的独特性如何？

• 任何意图的训练示例是否似乎与其他意图重叠？

• 主题范围（意图）是否与你对聊天机器人目的的印象相符？

• 解决方案如何处理它不理解输入？

• 对话的复杂性如何？是否存在复杂的流程、后端集成或搜索集成？

将您的分类器训练数据量以图表形式可视化可能会有所帮助。图 4.6 显示了一个示例训练集。目前还没有太多信息可以提取，但当我们组装测试数据时，这将为我们提供一个比较的基础。

图 4.6 该分类器有 13 个意图。训练示例数量从 7 到 30 不等。

通常情况下，我们期望具有更多训练示例的意图更受欢迎。我们希望最受欢迎的主题在大多数时候都能被理解。高容量的意图也可能代表处理更多样化短语的议题。在大多数情况下，我们不希望看到训练集中存在巨大的容量差异。例如，一个训练集中有些意图使用了数百个示例，而其他意图只有少数几个示例，可能会表现出性能问题，如过度选择（由于训练容量的偏差，频繁选择错误意图）。

4.3.2 评估您的生成式 AI 解决方案

在生成式 AI 方面，就像在传统 AI 中一样，您需要了解您的机器人操作的领域和范围。然而，您不需要关注输入的分类，而需要评估当模型产生输出时，它将从哪些数据源中抽取答案。在您的解决方案中，生成式 AI 是否用于生成答案或响应？如果是，熟悉以下情况：

• 是否为每个用户输入生成答案？

• 您是否将生成答案作为分类器的后备选项？

• 您是否在对话中调用生成文本来补充基于分类的“预定义”答案？

• 您的解决方案是否使用了不止一个大型语言模型（LLM），例如针对不同类型响应的不同模型、多语言支持等？

• 您的解决方案是否使用了提示工程、提示调整、微调或其他定制设置？这些是否记录在案，以及每个设置最初实施的目标成果？

• 您的解决方案是否使用了 RAG？如果是，数据源是什么？它多久更新一次？它是否包含额外的数据丰富？

练习

1. 使用本节中描述的标准（根据您使用的 AI 类型）评估您的解决方案。

2. 在您完成初始解决方案评估后，务必记录其当前状态——这将成为您的基线系统配置。

3. 随着您跟随本书中给出的改进建议和示例，请准备好以有助于您将所做的任何更新与后续的性能测量相关联的方式记录您的更改。

4.4 从日志中获取和准备测试数据

在本章的剩余部分，我们将假设你确实有一个生产系统并可以访问日志。我们将向你展示如何获取和准备这些数据，以创建一个可以用来衡量当前状态（以及验证未来变化）的资产。

从生产日志中构建测试集需要一些初始工作。图 4.7 显示了准备测试数据（或训练数据）所涉及的主要任务。

图 4.7 一旦你获得了一些数据，每个发言首先应该被分类到不同的桶中，以识别潜在的候选者；这将把好的、可用的测试数据与差的或无关的用户输入分开。数据可能还需要被清理，以修复如个人可识别信息（PII）等问题。之后，数据需要被标注（对于分类器，它需要用正确的意图进行标记；对于生成式 AI，它需要与理想的输出响应相关联）。最后，数据需要被转换成一个或多个可以被你的测试工具消费的集合。

4.4.1 获取生产日志

理想情况下，你将能够访问跨越一整年或更长时间的生产日志。这将有助于确保你的测试集将有一个真正代表性的样本，涵盖你的机器人可能遇到的各类主题范围，以及影响你行业的各种季节性和事件。从一年中的不同周或月收集日志样本。如果你的解决方案较新，预期在解决方案的前 12 到 18 个月内，你需要更频繁地刷新测试集。

一旦你获得了某些生产日志，你可能发现将此数据转换为 CSV 或 Excel 文件（如果尚未更新）是最容易的（如果它尚未更新）。我们发现将数据转换为每条对话交换一行（一个用户输入和一个机器人输出），按对话 ID 分组，非常有用。根据你选择的时段、用户数量、解决方案的复杂性和目的，你的文件可能只有几百行数据，或者可能有 1 万行或更多的对话交换。

将对话音量减少到可管理的集合的一个简单快捷方法是选择每次对话中的第一个用户发言。这可能在所有情况下都不适用，但图 4.8 显示，这通常是收集日志中有用数据的一种可靠方法。在自然语言驱动的交流中，用户往往会在初始输入中表达他们最重要的需求。如果你的平均对话持续十个回合，一个包含 10 万行原始数据的对话日志可以减少到大约 1 万行数据供审查。去重通常可以进一步减少几千行。这是一个非常实用的音量，通常包含丰富多样的例子，你可以用它们来测试你的解决方案。

图 4.8 原始聊天日志显示，用户的初始目标通常在对话的第一轮中被捕捉到，但有时它会在对话的后期或交换了礼貌用语后作为一个额外的请求出现。它甚至可能跟随一个退出请求。选择第一行通常会提供足够的数据，同时减少你的注释员在分类器无用的表述中（如按钮点击、常见回复、PII 或其他用户特定信息）进行排序所花费的时间。（你的日志结构可能因工具而异。）

4.4.2 确定候选测试表述的指南

无论你如何获取和预处理日志，你的下一个任务是确定潜在的盲测试候选者。我们将此视为“初步筛选”练习：只需确定一个表述是否可能可用。此外，我们建议审稿人不要过度分析他们看到的内容；如果你在一分钟内无法对任何给定的表述做出判断，请丢弃该表述并继续。 （如果你感到非常矛盾或感觉到某种模式，请将其标记为稍后审查并继续。）我们使用以下标准从生产日志中识别潜在的测试候选者，以及任何特殊处理说明：

• 表述是否无法理解？

• 这个表述与领域完全无关吗？

• 表述是否含糊不清？

• 表述是否包含多个意图？

• 表述与领域相关但超出范围吗？

• 这个表述是否表达了在领域和范围内的目标？

让我们逐一查看这些内容。

表述是否无法理解？

可能是猫走过了键盘，或者用户在愤怒中乱按键盘。也许语音到文本技术将呼叫者的提问转录成了无法理解的混乱。语音解决方案也可能捕捉到背景噪音和对话，尤其是如果它们没有为环境正确调优。你的文件可能包含许多用户输入，这些输入根本没有任何意义。

这些是不理解或不相关的表述的例子：

• “does it school”（不连贯——如果这是来自语音解决方案的，可能是语音转录错误。）

• “她没有她说有四个只给了我们一个是的你可以那样做我马上要赶飞机了等我到办公室我会检查的”（可能是呼叫方背景对话的语音转录。）

• “klewtkhaccalifornia liense”（可能是拼写错误，严重到使表述无法理解。）

这些行可以从你的盲测试集中排除。任何可识别的模式，如可能的语音转录问题，应留待进一步评估或转发给适当的团队。

表述与领域完全无关吗？

你可能会偶尔遇到一些可以理解但与领域或机器人预期目的完全不相关的问题。例如，如果你的解决方案旨在帮助电力公司客户管理他们的账户和服务，那么如果这些关于流行文化琐事的问题出现在日志中，你可以排除这些问题。

尽管您可以配置解决方案将未识别的主题发送到 LLM，但这些语句不属于您的分类器测试集，因为无法分配一个黄金意图。这些语句可用于负面测试，这有助于您了解您的解决方案是否适当地识别了它不应该尝试回答的情况。

这个语句是否模糊？

可能你会找到一个与领域相关但未表达明确目标的单个单词或短语。例如，如果一个银行聊天机器人的用户只是说“账户”，他们想要做什么？他们是想要开设账户？关闭账户？检查账户余额？谁知道呢？

模糊语句的子集可能包括由按钮点击或作为信息收集流程的一部分生成的响应。（如果你选择了每次对话的第一个自然语言语句，你可能看不到这些。）这些通常对分类器性能测试没有太大帮助，除非它们与流程中使用的意图相一致。只有在适当的时候才包括这样的语句。

这些是模糊语句的例子：

• “驾照”（可能与领域相关，但没有表达明确的目标。）

• “那一个”（一个指代先前语句中提供但可能已失去意义的上下文信息的代词。）

• “2”（可能指按钮选择或电话渠道选择，或者是对上一个问题的响应中提供的数量或数量。）

在大多数情况下，这些语句不应包含在您的分类器准确度测试中，因为它们可能不会与任何单一意图相匹配，而是与多个意图。然而，它们并非没有意义。将这些语句放在一边，以了解您的用户以这种方式沟通的频率。确定您的其他聊天机器人功能，如消歧或澄清问题，是否适当处理了它们。

这个语句是否包含多个意图？

大多数基于分类器的聊天机器人在一次只给定一个目标时表现最佳。表达多个有效、不同目标的语句应排除在您的分类器准确度测试集之外，因为您无法明确分配一个“正确”的意图。

这一规则的例外情况将是如果您的解决方案有一个消歧机制。消歧是通过展示分类器识别出的前n个意图来澄清用户的主要目标的方式。对于这些解决方案，您可能希望将您的多意图语句与您的分类器进行对比，以验证所有列出的意图都会以适当的消歧选择呈现。

这些是具有多个意图的表述示例：

• “你有 COVID 加强针吗？我该如何预约？”（表达了两个目标：1）疫苗加强针的可用性，2）预约。）

• “我想更新我的驾照地址，并了解获得商用驾照所需的信息。”（表达了两个目标：1）更新地址，2）获取获得 CDL 所需的信息。）

• “我目前有 95,000 个忠诚度积分。它们会过期吗？我还需要多少积分才能达到白金状态？我可以购买积分以提升到更高等级吗？”（表达了三个目标：1）了解奖励积分是否会过期，2）了解当前积分余额与下一等级奖励状态之间的差异，3）获取关于购买积分以提升到更高等级的信息。）

• “我想和客服人员谈谈关于报告被盗车辆的事情。”这种情况非常常见。用户通常会将与客服人员的请求和他们的真实目标结合起来。如果你的分类器训练集中存在这两个意图，你可以通过以下两种方式处理此类表述：

  • 如果无法标记单个“正确”的意图，则将这些内容排除作为候选人。

  • 包含这些候选人，但根据“首选”意图进行标记。（首选意图可能是如果控制是优先事项，那么竞争意图将会升级。）

与模糊表述一样，这些表述应该单独放置并分别评估，以更好地了解你的用户。如果你发现这些情况经常发生，你可能需要制定额外的策略来处理这些情况。如果用户倾向于提出相关问题，或者他们在单个表述中结合了常见的请求，那么在这些意图中的输出响应可以更新，以预测或满足所有需求。对于我们给出的第一个例子——“你有 COVID 加强针吗？我该如何预约？”——你的关于加强针可用性的回答可能包括一个预约链接。

关于处理多个意图的分类模型的注意事项

我们已经看到了在对话式人工智能解决方案中处理多个意图的广泛和英勇的尝试。这通常涉及收集前n个意图并将它们存储在上下文中，然后是更多的逻辑来在回答第一个意图之后呈现附加主题。在大多数情况下，结果是过度设计的解决方案，它脆弱、难以扩展，或者只是浪费了努力。这种方法也存在一个主要缺陷：这样的逻辑无法可靠地区分一个真正包含多个目标的表述和一个包含可能触发多个意图的单个目标的表述。

许多现代聊天机器人框架提供自动化的主题消歧（例如，“你是指：[意图 1] [意图 2] [意图 3]”）。我们的总体建议是允许消歧功能完成其工作。有时，这意味着用户必须一次提出一个问题或陈述一个目标。这种场景的频率和重要性通常不值得花费构建和维护处理多个意图的基于分类聊天机器人的自定义逻辑所需的努力。

生成式 AI 通常在处理多个意图方面比基于分类的解决方案要好得多，所以如果你的解决方案有这种能力，你可以将这些表述作为测试集的候选。

这个表述是否与领域相关但超出范围？

你可能会遇到表达一个与领域相关的单一、明确目标的表述，但当前解决方案尚未配备处理这些的能力。例如，一个银行聊天机器人可能允许用户检查账户余额，但可能没有训练来识别关于利率的请求。一个航空公司聊天机器人可能对航空政策了如指掌，但可能没有关于机场安全的实际知识。

这样的问题可能从用户的角度来看非常合理，但主题覆盖的差距往往会导致用户感到沮丧。这尤其在你没有生成式 AI 或搜索回退的情况下更为明显。如果你的聊天机器人响应，“很抱歉，我不理解。请重新措辞你的问题”，无论怎样重新措辞都无法让用户得到满意的答案。这些应该如何处理？

如果你的分类器没有训练好的意图来处理此类请求，这些应该被暂时搁置。在进一步审查后，它们可能被分组到主题或类别中，但它们目前将不会包含在你的测试集中，因为无法分配黄金意图。根据适当的情况，监控这些主题的量并添加到你的改进待办事项中。

同样，如果你的生成式解决方案尚未准备好回答此类问题（例如，RAG 解决方案中的文档库没有内容来处理该主题），暂时将这些内容搁置，但监控其量。

这个表述是否表达了一个在领域和范围内的目标？

得分！属于你的解决方案和领域范围内的提问或请求应属于你的黄金测试集。

4.4.3 准备和清洗数据以用于迭代改进

如果你从未见过聊天机器人的生产日志，你可能会惊讶它们有多混乱。你将看到很多不良或非正式的语法、拼写错误或打字错误（在基于文本的渠道上）、语音误转录（在语音渠道上），以及可能的各种形式的个人信息（PII）。以下是我们推荐的处理方法。

不良或非正式的语法

在大多数情况下，让它保持原样！人类表达自己的方式有很多多样性。用户可能不知道如何准确传达他们的需求——尤其是向机器传达。如果可以识别出目标，它就是一个代表性的例子，应该保持原样。

错别字和拼写错误

除非错别字或拼写错误显著改变了整个短语的含义，否则请保持原样。常见的拼写错误代表了您的用户是如何沟通的。您的分类器应该能够给出良好的答案，无论用户是询问“贷款余额和本金有什么区别？”还是“whats teh diffrence between loan balance and principle？”

正确的大小写和标点通常会被分类器忽略，但您可能需要与您的技术平台核实这一点。

语音误转录

如果您的解决方案使用语音转文本（也称为自动语音识别），您不会遇到错别字，但您可能会看到意外的单词，这很可能是语音误转录的结果。首先的攻击方法是尽可能训练您的语音模型。聊天机器人分类器的底层技术是文本驱动的，因此在用户的话语触及文本分类器之前，最好有用户话语的最忠实表现。

如果您发现语音模型仍然持续地将您领域内的关键词误转录，请将这些关键词包含在您的测试集中（并且最终，您可能需要补充您的训练数据）。例如，对于一家电力公用事业公司，我们持续看到重要的领域术语“residential”被误转录为“presidential”。由于语音模型更新可能需要更长的时间来实现，这导致通话控制丢失，一个立即的解决方案是将“presidential”添加到我们的聊天解决方案的同义词中。另一个例子是将“VIN”误转录为“BIN”，这对于需要理解“车辆识别号码”的用例。为此，我们确保训练数据包含这两种变体。我们还保留了误转录以供我们的测试目的。

个人可识别信息

您还可能发现各种形式的个人身份信息（PII），例如姓名、电话号码、物理或电子邮件地址、社会保障号码、账户号码等。这些信息不应包含在您的训练或测试数据中。理想情况下，这些信息应该在日志中屏蔽，但即使这项技术也不完美。如果您的解决方案具有 PII 屏蔽功能，您应将任何真实数据替换为相同类型的屏蔽字符（例如，###-###-####用于十位电话号码）。如果没有，则可以完全删除 PII，或者用显然是虚构的表现形式替换，例如“username@email.com”。

4.4.4 标注过程

在您将数据缩小到表达清晰目标的语句（属于您的领域，并在适当的地方进行了清理）之后，它们需要针对当前任务进行适当的标注。

为传统的（基于分类器的）AI 标注黄金测试集

为分类器标注测试集涉及将每个语句标注为适当的意图。这项任务说起来容易做起来难，你将在构建测试集上花费最多的时间。

识别和丢弃不可理解或模糊的用户输入相对容易。然而，一旦你知道一个语句属于你的领域，就需要更多的时间来标注它正确的意图。负责标注（将每个语句标注为正确的意图）的个人或团队需要熟悉当前的训练数据。这个过程肯定会暴露出你的意图中重叠的问题，因为你的人类注释者会陷入如何标注语句的疑问。

一个团队可能采取几种方法来完成为测试或训练标注数据的任务。有时一个人被分配这项工作。有时整个团队会尝试承担这项任务。当这种情况发生时，他们通常会认为“分而治之”的方法最有效。根据我们的经验，这可能会导致需要更长时间解决的问题。

在一个理想的世界里，每个人都应该坐在同一个房间里，共同判断每一句话。这种方法有助于讨论每个意图的目的。所有注释者都需要理解用于区分具有许多相同关键词但目标不同的意图的标准。另一个同样有效的方法是让多个注释者分别判断相同的数据（或者至少是部分重叠的数据），并将任何差异进行比较以达成共识。

如果你的日志包括每个语句在运行时预测的意图，我们不会犹豫采取一个捷径：先进行一次预判并判断预测的意图是否正确。然后你只需要判断并标记剩余的不正确语句，并给出正确的意图。

这个练习可能需要几个小时到几天不等，可能会对你的视觉和认知负荷造成压力。作为第一次运行，指导你的注释者做出最佳判断并继续前进。如果判断一个语句需要超过六十秒，就跳过它，稍后再回来。每小时或两小时休息一下也很重要。走开一段时间再回来有助于恢复精力。

我能否只用 LLM 来完成所有这些工作？

如果你正在构建你的第一个分类器，你当然可以将语句与 LLM（大型语言模型）进行匹配，作为标记或分类数据的初步尝试。然而，如果你已经有了生产日志，将语句与单独的分类 LLM 进行匹配将不会增加任何价值，因为你仍然需要一个人类裁判来审查由这项练习产生的分类。

一旦你标注了测试集，你将拥有一个由人工判断、标记的数据的金色集。根据你的用例，这可能包括几百到几千个话语。这个资产将为你提供一些关于你的分类器当前准确性的即时信息。它还将被用来帮助你调整系统。

你需要做的最后一件事是将你的数据转换为可以被测试工具消费的文件。这将产生一个可以用来衡量未来更新影响的资产。格式可能因工具而异，但通常将是一个包含每行一个测试话语在一列和金色意图在另一列的文本或 CSV 文件。表 4.2 展示了测试集可能的样子。

表 4.2 每行一个话语/意图对的样本测试集

话语	金色意图
我想和真人说话	Request_Agent
我可以和经理通话吗	Request_Agent
让我找客服	Request_Agent
你星期日是否开门	Office_Hours
你什么时候开门	Office_Hours
你的办公室什么时候关门	Office_Hours
你的周末营业时间是什么时候	Office_Hours

为生成式 AI 标注金色测试集

创建一个用于衡量生成式 AI 的测试集需要判断你的解决方案（如果你正在使用生产日志）产生的答案质量，并根据你之前为解决方案定义的维度对其进行更新或替换为理想答案。主题专家需要审查每个示例输出，以确保其事实性和完整性，代表品牌，并反映虚拟代理角色的目的和定位。

一旦你审查了输出，你将有一组与金色答案或响应配对的话语。这个资产将为你提供一些关于你生成响应质量的即时信息。它还将被用来调整你的提示和 LLM 配置。

你需要做的最后一件事是将你的数据转换为可以被测试工具消费的文件。格式可能因工具而异，但通常将是一个包含每行一个测试话语在一列和金色响应在另一列的文本或 CSV 文件。表 4.3 展示了样本测试集。

表 4.3 每行一个话语/答案对的样本测试集

话语	金色响应
我可以把我滑雪板作为托运行李带上飞机吗？	你可以带一套滑雪板设备作为托运行李。这套设备必须在一个包里，可以包括最多两块滑雪板和一个雪靴包。如果这套设备重量超过 50 磅（23 公斤），你将不得不支付超重行李费。
我要退款需要等多久？	信用卡退款将在请求后的五个工作日内处理。所有其他退款将在请求后的 20 个工作日内处理。

练习

1. 从您自己的日志中获取数据，并确定候选测试语料。

2. 根据需要清理数据以删除 PII。

3. 评估分类预测或生成的答案内容。将这些结果记录为基线性能测量。

4. 分配一个黄金意图或理想响应。

5. 以测试工具可以消费的格式保存文件。

4.5 数据告诉我们什么？

如果您的日志中包含了原始意图预测或生成的答案，您现在就有所需的数据来计算解决方案当前理解准确率的基线测量。（将正确预测或答案的数量除以总候选数量。）您标注的语料将显示用户向聊天机器人提出的话题的范围和频率。

4.5.1 解释传统（基于分类）AI 的标注日志

对于基于分类器的系统，您可能对查看意图之间的数量分布感兴趣。这与每个意图的训练示例量相比如何？图 4.9 显示了训练示例的理想化、相对平衡的分布，与日志中观察到的发生次数相比。

图 4.9 深色条形表示系统中训练示例的数量。浅色条形表示每个意图的标注语料数量。如果您的图表遵循类似的模式，那么您的训练优先级可能与解决方案的需求良好对齐。

训练示例与日志中实际发生之间的明显差异本身并不表明存在问题，但如果准确率低，它可以告知您的优先级。图 4.10 显示了一个与系统训练严重不匹配的标注语料的示例。

图 4.10 训练示例计数（深色条形）与标注日志数据（浅色条形）相比，在许多意图上存在很大的差异。没有每个意图的准确率数字，我们无法立即判断这种差异是否会产生负面影响。然而，我们可以进行一些观察，例如 1）前五个意图并不像我们想象的那么重要，2）日志中意图量最高的（意图 6、10、11 和 12 的浅色条形）可能比我们预测的更受用户重视。

您还应该回顾那些被判定为属于领域但超出当前范围的语料量。（这些语料在 4.1.4 节中描述的准备任务中已被识别并留出。）是否似乎存在对分类器尚未训练的主题的需求？用户期望能够提出的问题与分类器训练以识别的内容之间的不匹配，会导致对理解能力薄弱的感知。

您的整体准确性提供了对解决方案理解能力的整体视图。下一步是深入具体意图。您可能从查看您的解决方案中表现最差且高量/高价值的意图开始。在第五章中，我们将深入探讨改进分类器理解的过程。

4.5.2 解释生成式 AI 的标注日志

您为生成式 AI 解决方案提供的标注日志将展示用户提供的各种问题和请求的范围。在整个标注过程中，您可能发现了关于领域的覆盖范围方面的差距。您也可能更好地理解了提示工程或微调改进如何使生成的答案更好。如果您的解决方案采用 RAG，您可能会开始将答案的质量与您存储库中的文档相关联。

您的整体准确性提供了对解决方案理解能力的整体视图。在第六章中，我们将深入探讨改进您生成式 AI 的过程，使其能够传达良好的理解。

4.5.3 逐步改进的案例

到目前为止，您应该已经拥有了开始规划改进周期所需的数据。您的性能发现将作为改进的路线图。请记住，这是一个迭代的过程。您将做出改变。然后您将进行测量，以确定您的更改对理解产生了积极、中性或消极的影响。

还要注意，您的盲测或黄金测试集在整个解决方案的生命周期中都需要更新。回想一下，聊天机器人可能变得不准确的一个原因是世界上的新信息。以下是我们看到的一些例子：

• 全球 COVID-19 大流行，它改变了几乎每个人的工作方式、公共空间的导航以及支持家庭的方式。

• 新的立法通过，导致政府机构收到相关问题的咨询。

• 市场上的新产品或产品召回。

• 一家公司遭遇了数据泄露，一旦消息公布，聊天机器人就遭到了诸如“我的数据安全吗？”和“我想了解更多关于黑客攻击的信息。”等问题的大量询问。

计划定期审查您的日志。根据您解决方案的量级，这可能从启动后的每日开始，然后是每周、每月和每季度。别忘了根据您所做的更改更新您的测试集：

• 如果您的系统中添加了新的意图，需要向测试集中添加新的话语。

• 如果意图在您的改进工作中合并或拆分，受影响的意图需要在您的测试集中更新。

• 如果在您的生成式解决方案引用的知识库中添加了新的覆盖范围区域，您的测试集应包括对此的验证。

• 如果您的解决方案添加了新的 LLM 场景或提示定制，这些应该反映在测试集中。

练习

1. 回顾你的标注数据并反思发现。是否有表现不佳的理解区域？

   • 如果是这样，你会假设什么根本原因？

   • 是否存在多个根本原因？

2. 你会如何优先考虑实现更好理解所需的改进？

摘要

• 当聊天机器人能够识别用户想要什么并提供令人满意的答案或帮助用户实现目标时，它们表现出良好的理解。

• 对于传统 AI，理解依赖于至少两种机制：对意图的正确分类以及根据该分类提供输出的能力。（额外的机制，如实体检测或上下文，可能会修改或个性化输出。）

• 对于生成式 AI，理解依赖于话语及其伴随的提示来创建一个旨在解决用户问题或目标的响应。

• 理解薄弱对商业价值有害，通常表现为聊天机器人返回错误答案或完全无答案。

• 在收集一些数据之前，你无法评估你的聊天机器人的性能。

• 聊天机器人的理解通常以准确性或解决方案提供正确答案或采取正确行动的速率来衡量。

• 存在多种工具和方法来衡量理解。其中一些取决于 AI 的类型和/或当前阶段，无论是预部署还是后部署。

• 一个代表性的黄金测试集，由真实用户话语（生产日志）精心挑选，可以用来衡量机器人的基准性能，并且可以转化为可重复使用的资产，以衡量未来变更的影响。

• 你应该计划在整个聊天机器人生命周期内监控和重新训练你的解决方案。

• 训练的更新可能需要相应更新盲测试集。

第五章：提升对传统人工智能的薄弱理解

本章涵盖

• 识别分类器可能犯的错误类型

• 建立当前分类器性能的基线

• 使用数据科学方法来识别和优先处理改进

• 将生成内容融入你的传统人工智能以增强理解

在本章中，我们将展示一种系统性的、迭代的方法来提高基于分类的对话解决方案的理解。本章建立在上一章中介绍的概念之上，并使用第 4.4 节中产生的最终输出（你在其中创建了一个测试集，每个话语都分配了黄金意图，并且格式可以用于你的测试工具）。在本章的后面部分，我们将探讨大型语言模型如何补充意图驱动的输出响应，以提供更稳健的体验。（如果你在寻找生成式人工智能改进技术，可以自由地跳到下一章。）

我们将首先制定一个改进计划，并确定你的分类器可能犯的错误类型。接下来，我们将通过七个改进周期来解决你可能在自己的文本分类器中看到的各种问题。尽管使用了数据科学技术，但你不需要是数据科学家，就可以使用本章中介绍的方法从你的数据中提取有意义的见解。

5.1 制定你的改进计划

如果你使用生产日志中的样本构建了一个盲测试集，你应该有一个可靠的“代表性分布”测试集。这意味着用户最常询问的主题在你的测试数据中都有相应的数量表示。这将是在优先处理测试结果中暴露出来的任何问题的一个关键因素。

如果你正在处理第四章中讨论的k-折测试的结果，你将无法确定哪些主题是最重要的，因此最严重的准确度得分是一个合理的起点。

在任何情况下，现在是时候深入挖掘那些测试结果了。改进计划从识别机器人训练中的最大问题区域开始。

5.1.1 识别误解话语中的问题模式

第一个会吸引你注意的分数是测试结果的整体准确率。这就像拿到一份拼写或数学测试，看到页面顶部的红墨水。如果你的测试有 100 个问题，你答对了 79 个，你的准确率就是 79%。对于分类器来说，这个数字可以提供一个“一目了然”的模型视图，但它并不提供关于正在发生的事情或从哪里开始改进的完整画面。为了做到这一点，我们需要了解我们分类器可能犯的错误和可能的结果类型。这体现在回收率、精确率和 F1 分数的测量中。

回收率、精确率和 F1 分数的简要说明

在第四章中，我们将召回率描述为分类器预测正确意图的能力，将精确率描述为避免预测错误意图的能力。你可以从正面和负面预测的角度来考虑这一点。对于我们要测试的每个话语，都有四种可能的结果，它们不是互斥的，这意味着每个预测都会同时发生两个或三个这些结果。图 5.1 显示了可视化这些可能结果的混淆矩阵：

图 5.1 在一个 2×2 的混淆矩阵中，可能的结果是通过比较预测意图和实际意图得出的。

• 真阳性—与正确意图匹配的预测

• 真阴性—不匹配错误意图的预测

• 假阳性—匹配错误意图的预测

• 假阴性—不匹配正确意图的预测

我们可能感兴趣的第一个指标是意图的召回率。为此，我们需要知道真阳性和假阴性。返回假阴性的意图正在犯选择不足的错误。按意图衡量，这看起来像是一个准确率分数。如果我们的测试有五个关于#Request_Agent意图的问题，分类器正确回答了四个，那么该意图的召回率将是 80%：

召回率 = 真阳性 / (真阳性 + 假阴性)

帮助我们理解分类器的下一个指标是精确率。这衡量我们的分类器在避免给出假阳性方面的好坏。返回假阳性的意图正在犯选择过多的错误。表 5.1 的最后两行提供了一个选择过多的例子：

精确率 = 真阳性 / (真阳性 + 假阳性)

表 5.1 测试结果显示有七个话语，其中五个被标记为正确的#Request_Agent意图。前四个预测是真阳性。最后两行显示了在不应预测#Request_Agent意图的话语中预测了两次（“我可以问您什么？”和“有人撞了我的车”）。这些假阳性贡献于我们的精确率计算：4 / (4 + 2) = 0.66。

话语	正确意图	预测意图	正确
客户服务	Request_Agent	Request_Agent	1
与代理交谈	Request_Agent	Request_Agent	1
我可以和某人说话吗？	Request_Agent	Request_Agent	1
与真人交谈	Request_Agent	Request_Agent	1
我什么时候能接到真人？	Request_Agent	Office_Hours	0
我可以问您什么？	VA_Capabilities	Request_Agent	0
有人撞了我的车	Report_Accident	Request_Agent	0

#Request_Agent 的所有可能结果的全面分析显示在图 5.2 中。它还显示了真阴性值（这些值在我们的计算中未使用，但已包括以展示其他结果的范围）。

图 5.2 用于计算 #Request_Agent 的精确度和召回率的突出列。

现在我们知道了召回率和精确度，我们还可以计算 F1 分数，它是召回率和精确率的调和平均值。这个计算如下：

F1 分数 = (2 × 精确度 × 回忆) / (精确度 + 回忆)

对于我们的 #Request_Agent 目标，这将计算为 (2 × 0.66 × 0.8) / (0.66 + 0.8) = 0.72。表 5.2 显示了所有三个分数。

表 5.2 #Request_Agent 的召回率、精确度和 F1 分数

目标	回忆	精确度	F1 分数
Request_Agent	0.80	0.66	0.72

真阴性值如何？

在本节前面，我们提到了真阴性值——一个不匹配错误意图的预测。只要我们有一个以上的训练目标，就会发生真阴性值。然而，它们并不是我们方法中的有用度量。

为什么不呢？好吧，对于模型做出的每一个预测，它只有一种正确的方式，但有两种错误的方式。这似乎有点不公平，如果你只是看两个目标，就很难理解这一点。但想象一下，我们有一个用 20 个目标训练的模型。每次我们做出一个返回真阳性的单个预测时，我们也会得到 19 个真阴性值。而对于每一个假阳性预测，

我们有 1 个假阴性值和 18 个真阴性值。所以所有这些真阴性值加起来是一个非常大的数字，对于我们来说，这并不提供太多洞察。因此，我们不将真阴性值纳入我们的计算中。

决定哪个指标很重要

召回率、精确度、F1 分数：我们应该关注哪个数字？这是一个很好的问题！答案是，这取决于你的组织在解决方案需要交付的内容中最重视什么。以下是一些指导你找到答案的考虑因素：

• 当与假阴性相关的高成本时，召回率是有用的。想象一下，如果欺诈检测工具错过了它评估的 25%的欺诈交易，会有什么影响。（对于聊天机器人来说，这看起来像是一个正确的意图，但 25%的时间没有被预测到。）

• 当与假阳性相关的高成本时，精确度是有用的。想想《危险边缘》这个游戏节目，它会惩罚试图回答并答错题目的参赛者（或者一个过度选择 #Request_Agent 目标的聊天机器人，导致不必要的升级）。

• 当与假阳性和假阴性都相关的高成本时，F1 分数是有用的。我们喜欢使用这个指标，因为它反映了召回率和精确率分数的良好平衡。

使用混淆矩阵可视化你的数据

在本节前面，我们展示了 2×2 混淆矩阵以展示潜在的结果。混淆矩阵可以帮助你通过可视化模型做出的预测摘要来评估分类模型的性能。一些测试工具会在其结果输出中生成此信息。

图 5.3 显示了一个虚构场景，其中分类器模型做出了十个完美的预测。

图 5.3 一条实线对角线表明每个预测意图（用一个字母表示）都与实际意图相匹配。

从对角线偏离的阴影框提供了关于模型在哪里混淆的有用见解，如图 5.4 所示。

图 5.4 显示，该模型有九个正确的预测，但在实际意图是 E 时错误地预测了意图 G。

5.1.2 逐步改进

逐步改进的方法将以可管理的方式影响可衡量的变化。你对分类器所做的每一次更改都可能影响多个意图。有时这种影响是积极的，但有时则不然。你可能会同时更新多个意图而不会出现问题，但如果测试显示性能下降，追踪问题根源可能会很困难。你将不得不在效率需求与对返工的容忍度之间取得平衡。

5.1.3 从哪里开始：识别最大的问题

通常，最好的起点是具有最低 F1 分数的最高量意图。企业也可能对优先级提出意见。如果一个低量意图未能识别其设计用来处理的那种请求，但这种失败导致了昂贵的人工干预，它可能会被优先考虑。

在本章的剩余部分，我们将探讨一个虚构的用例：一个服务于与州机动车管理局（一种美国政府机构，负责监管和管理州身份证、驾驶执照、某些许可证和车辆注册的发放）互动的人群的聊天机器人。

首先，让我们遵循第四章中给出的建议，快速、高层次地查看我们的当前训练数据，如表 5.3 所示。

表 5.3 基线训练集中具有示例计数的意图

意图名称	示例数量
Accident_Report	2
Appointment	6
Change_Contact_Records	3
Chitchat_Goodbye	3
Chitchat_Hello	4
Chitchat_Thanks	2
Chitchat_VA_About	8
Fee_Info	5
General_Negative_Feedback	6
General_Request_Agent	5
Get_ID_Number	4
Item_Not_Received	8
License_or_ID	5
License_Reinstatement	4
Login_Issue	4
Name_Change	6
Office_Information	6
Payment_Methods	3
Refund_Overcharge	4
Report_Sold_Vehicle	6
Report_Stolen_License_Permit_ID	5
Report_Stolen_Plates_Registration	3
Report_Stolen_Vehicle	2
Request_Receipt	4
Vehicle_Permit	5
Vehicle_Title	6
Walk_In	6
总计	125

我们可以对这个训练集做出一些定量陈述。它有 27 个意图，总共有 125 个训练示例。示例分布相对均匀。作为定性评估，我们可能会说许多意图看起来是独特的，但其中一些可能存在一些重叠。一些术语肯定在意图名称中重叠。查看完整的训练语句集（未显示）揭示了许多术语出现在多个意图中，例如“ID”、“title”、“permit”、“vehicle”、“stolen”。然而，如表 5.4 所示，这些词出现的上下文被认为是适当标注的。

表 5.4 基线训练集中提取的语句显示了多个意图之间重叠的各种术语。

语句	标注意图
身份证多少钱？	Fee_Info
我需要找出我的身份证号码	Get_ID_Number
我没有收到我的身份证	Item_Not_Received
标题从未到来	Item_Not_Received
将人添加到标题中	Vehicle_Title
我如何获得驾驶执照？	License_or_ID
替换我的程序停车许可证	Vehicle_Permit
我卖掉了一辆车	Report_Sold_Vehicle
我需要报告一辆被盗的汽车	Report_Stolen_Vehicle
我的身份证被盗了	Report_Stolen_License_Permit_ID

总体来说，对于聊天机器人的目的而言，主题范围似乎是合理的，在这种情况下，其目的是回答用户在处理州机动车辆局时可能遇到的问题。

建立基线

现在我们已经对训练数据进行了初步评估，我们需要了解它当前的性能。我们将从运行一个 k-折交叉验证测试来建立基线开始。考虑到训练集中数据量较低，表 5.5 中显示的初步版本（V1）的结果并不算太差。

表 5.5 基线（V1）k-折结果

意图	样本数量	预测数量	召回率	精确率	F1 分数
Accident_Report	2	2	1	1	1
Appointment	6	8	1	0.75	0.8571
Change_Contact_Records	3	0	0	0	0
Chitchat_Goodbye	3	0	0	0	0
Chitchat_Hello	4	6	1	0.6667	0.80
Chitchat_Thanks	2	2	1	1	1
Chitchat_VA_About	8	8	1	1	1
Fee_Info	5	2	0.40	1	0.5714
General_Negative_Feedback	6	7	1	0.8571	0.9231
General_Request_Agent	5	4	0.80	1	0.8889
Get_ID_Number	4	6	1	0.6667	0.80
Item_Not_Received	8	6	0.6250	0.8333	0.7143
License_Reinstatement	4	4	1	1	1
License_or_ID	5	5	0.60	0.60	0.60
Login_Issue	4	4	1	1	1
Name_Change	6	8	1	0.75	0.8571
Office_Information	6	6	1	1	1
Payment_Methods	3	3	1	1	1
Refund_Overcharge	4	4	1	1	1
Report_Sold_Vehicle	6	5	0.8333	1	0.9091

|

Report_Stolen_License_
Permit_ID

5	6	1	0.8333	0.9091

|

Report_Stolen_Plates_
Registration

3	3	0.3333	0.3333	0.3333
Report_Stolen_Vehicle	2	3	1	0.6667
Request_Receipt	4	4	1	1
Vehicle_Permit	5	6	1	0.8333
Vehicle_Title	6	9	1	0.6667
Walk_In	6	4	0.6667	1

我们的k-fold 测试共有 125 个问题（我们训练集的总数），其中正确回答了 105 个，总体准确率为 84%。有几个意图具有完美的召回率和精确度（这通常是人工数据集的一个标志）。有两个意图的召回率为 0；它们各自只有三个训练示例。这揭示了k-fold 测试的一个缺陷——简单地没有足够的示例可以分配到自动生成的训练和测试集中。很可能，这些意图在生产中的表现将优于 0。然而，具有完美召回率的意图可能不会表现得那么好。如果您正在推出试点项目并且没有其他训练数据可用，这些结果通常足够上线，但应向利益相关者发出强烈警告，他们应预期实际性能在可用代表数据用于训练更新之前会较低。

一旦解决方案上线，应使用从日志中创建的盲测试集来获取一个新的基线。表 5.6 中有一个这样的例子，它确实强调了我们的k-fold 测试与实际用户输入相比预测的性能差距。

表 5.6 基线（V1）盲测试结果

意图	样本数量	预测数量	召回率	精确度	F1 分数
Accident_Report	2	2	1	1	1
Appointment	7	5	0.7143	1	0.8333
Change_Contact_Records	4	4	1	1	1
Chitchat_Goodbye	1	1	1	1	1
Chitchat_Hello	1	1	1	1	1
Chitchat_Thanks	1	1	1	1	1
Chitchat_VA_About	1	2	1	0.50	0.6667
Fee_Info	11	9	0.8182	1	0.90
General_Negative_Feedback	2	3	1	0.6667	0.80
General_Request_Agent	3	2	0.6667	1	0.80
Get_ID_Number	3	5	1	0.60	0.75
Item_Not_Received	16	9	0.4375	0.7778	0.56
License_Reinstatement	5	5	0.60	0.60	0.60
License_or_ID	7	5	0.5714	0.80	0.6667
Login_Issue	9	5	0.4444	1	0.6153
Name_Change	9	9	1	1	1
Office_Information	9	11	1	0.8182	0.90
Payment_Methods	2	2	1	1	1
Refund_Overcharge	3	4	1	0.7500	0.8571
Report_Sold_Vehicle	6	7	1	0.8571	0.9231

|

Report_Stolen_License_
Permit_ID

7	8	0.8571	0.75	0.80

|

Report_Stolen_Plates_
Registration

5	4	0.80	1	0.8889
Report_Stolen_Vehicle	2	2	0.50	0.50
Request_Receipt	4	4	1	1
Vehicle_Permit	4	5	1	0.80
Vehicle_Title	2	8	1	0.25
Walk_In	8	5	0.3750	0.60

在我们盲测试的第一轮中，134 个问题中有 102 个是正确的，总体准确率为 76%——比我们预测的 84%低 8 个百分点。

验证您的初始训练策略

一旦您获得了标注日志并进行了某些基线性能测量，您就可以验证那些指导您初始训练策略的决定。

代表性训练数据的稀缺是对话式人工智能项目非常常见的问题。就像许多其他新推出的聊天机器人一样，我们的初始训练集是由主题专家（SMEs）开发的，他们为他们认为最可能发生的话题制造了训练示例。在图 5.5 中，我们可以比较为每个意图训练的示例数量与用于测试的随机选择的日志中存在的示例数量。

图 5.5 将训练示例与我们的代表性盲测试集中的话语进行比较，显示在图表左侧的许多最流行意图（代表性的盲话语）在音量上存在一些差异。我们还在几个不太受欢迎的意图（右侧的意图）中看到了差异。

每个意图的训练数据与代表性盲话语的并排音量比较可以帮助我们了解我们的解决方案的主题覆盖范围是否与实际世界的交互一致。我们首先注意到的是#Item_Not_Received是最受欢迎的实际意图。这验证了为该意图提供更多训练示例（相对于大多数其他意图）的初始构建策略。我们还注意到，与日志中该主题出现的频率相比，#Chitchat_VA_About有大量的训练示例。这个意图可能过度训练了。它显然不像我们想象的那么受欢迎。然而，在我们查看这些意图的性能指标之前，我们无法得出任何明确的结论。相反，这些观察结果可能会为我们的改进建议提供信息。

练习

1. 使用您自己的数据运行代表性盲测试，并确定哪些意图（如果有的话）表现出较差的性能。

2. 您的训练音量与日志中看到的意图音量一致吗？

3. 您会如何优先考虑对表现最差的意图进行改进？

5.2 解决“意图匹配错误”

当你的聊天机器人返回错误的意图时，它犯了两种类型的错误：假阳性（预测错误的意图）和假阴性（未能预测正确的意图）。让我们通过一个改进周期来演示我们将如何处理这个问题。

5.2.1 提高一个意图的召回率

我们将从#Login_Issue开始，这是第五个最受欢迎的主题，但召回率相当低，为 0.44。在我们的盲测集中有九个测试话语；它正确回答了四个问题（真阳性）和五个错误（假阴性）。这个意图有一个完美的精确度分数，这意味着它从未作为其他意图的错误预测出现。表 5.7 显示了总结指标。

表 5.7 #Login_Issue的总结指标；对基线分类器进行的盲测集运行显示召回率低但精确度完美。

意图	样本数量	预测数量	召回率	精确度	F1 分数
Login_Issue	9	5	0.4444	1	0.6153

在表 5.8 中，我们可以深入到盲测的结果细节。我们的分类器五次未能预测正确的意图。其中三次是错误意图的预测。两次是置信度如此之低，以至于分类器没有返回预测。

表 5.8 基线盲测结果细节显示，我们有一个召回率为 44%的分数。在九个话语中，正确的（即金色）意图被预测了五次。

话语	金色意图	预测意图	置信度
BMV 门户密码重置	Login_Issue		n/a
我无法进入我的个人资料	Login_Issue	Item_Not_Received	0.8131
我需要帮助登录我的 BMV 个人资料	Login_Issue		n/a
我从未收到我的安全验证码	Login_Issue	Item_Not_Received	0.2358
我尝试登录但失败了	Login_Issue	Login_Issue	0.8033
我无法进入门户	Login_Issue	Login_Issue	0.6680
密码被锁定	Login_Issue	Login_Issue	0.5520
密码重置	Login_Issue	Login_Issue	0.4875
你从未发送安全码	Login_Issue	Item_Not_Received	0.2091

如果我们看看我们当前的训练示例，很容易看出为什么错过了这么多问题。只有四个示例：

• 我无法在网站上登录

• 在线账户问题

• 在线问题

• 登录我的账户有问题

我们的训练示例缺乏在与真实用户互动中看到的丰富词汇和短语。用户可能会将他们的账户称为他们的“个人资料”。他们列出明确的问题，例如“被锁定”、“需要密码重置”和“未能收到安全码”。如果我们添加一些代表性的示例（从我们的日志中获取），我们应该会看到改进：

• 帮助登录在线门户

• 我需要重置我的密码

• 我需要安全码来登录

通过这些新增功能，我们将我们的分类器更新到 V2 版本，并重新运行了盲测试集。让我们看看这对表 5.9 中#Login_Issue的召回率有何影响。

表 5.9 盲测试结果细节显示，我们最新分类器版本（V2）的召回率有所提高。在九个表述中，正确的（即金色）意图被预测了八次。

表述	金色意图	预测意图	置信度
BMV 门户密码重置	Login_Issue	Login_Issue	0.8253
我无法登录我的资料库	Login_Issue	Item_Not_Received	0.8131
我需要帮助登录我的 BMV 资料库	Login_Issue	Login_Issue	0.6846
我从未收到我的安全验证码	Login_Issue	Login_Issue	0.7179
我尝试登录但没成功	Login_Issue	Login_Issue	0.8899
我无法进入门户	Login_Issue	Login_Issue	0.7840
密码锁定	Login_Issue	Login_Issue	0.9083
密码重置	Login_Issue	Login_Issue	0.9204
你从未发送过安全码	Login_Issue	Login_Issue	0.2551

我们的整体准确率从 76%提高到 79%（106 个正确中的 134 个），表 5.10 显示了召回率和 F1 分数的显著提高。精确度分数也保持稳定。

| 表 5.10 比较总结指标；我们的 V2 分类器与基线（V1）相比，在#Login_Issue上显示出整体改进。

意图	样本数量	预测数量	召回率	精确度	F1 分数
Login_Issue—基线（V1）	9	5	0.4444	1	0.6153
Login_Issue—V2	9	8	0.8889	1	0.9412

5.2.2 提高一个意图的精确度

接下来，让我们尝试提高一个意图的精确度。#Chitchat_VA_About意图在基线测试结果和 V2 测试结果之间保持不变。（在每次更改后查看最新结果是很重要的。）表 5.11 显示，召回率完美，但精确度仅为 50%。这意味着我们的分类器对这个主题的重要性略有增加，并在另一个意图中显示为假阳性（过度选择）。

表 5.11 V2 更新后的指标显示，#Chitchat_VA_About的召回率完美，但精确度较差。

意图	样本数量	预测数量	召回率	精确度	F1 分数
Chitchat_VA_About	1	2	1	0.50	0.6667

在表 5.12 中，我们看到我们盲测试集中这个意图只有一个测试问题，但我们的分类器预测了这个意图两次。

表 5.12 V2 盲测试结果细节显示对#Chitchat_VA_About的过度选择。

表述	金色意图	预测意图	置信度
你叫什么名字？	Chitchat_VA_About	Chitchat_VA_About	0.8042
我的标签在哪里？	Item_Not_Received	Chitchat_VA_About	0.3015

我们的训练有八个示例。我们知道这些示例是人为制造的（实际上，它们是由模板提供的），但我们的日志显示这并不是一个非常常见的话题。我们的盲测集只包含一个关于这个意图的表述。

提高精度的策略之一是修剪训练示例。这告诉我们的分类器，意图并不像我们解决方案中的其他意图那样占主导地位。我们将丢弃三个示例，因为它们要么过于冗余，或者在“你来自哪里”的情况下，日志中没有证据表明这是一个相关的问题：

• 你是机器人吗？

• 我可以问你什么？

• 你能做什么？

• 我可以帮你做什么？（从训练中移除）

• 你叫什么名字？

• 你来自哪里？（从训练中移除）

• 我在跟谁说话？（从训练中移除）

• 你是谁？

一旦训练更新（现在是 V3），我们再次进行了盲测并审查了结果。我们发现#Chitchat_VA_About意图从 V2 到 V3 的精度有所提高——所有指标都是满分。奇怪的是，我们的整体准确率下降到 78%（从 79%），我们失去的一个问题是来自我们的#Login_Issue意图。表 5.13 显示了两个意图从 V2 到 V3 的指标变化。

表 5.13 V3 更新前后#Chitchat_VA_About和#Login_Issue的指标显示，改变一个意图可能会影响另一个意图。

意图	样本数量	预测数量	召回率	精确率	F1 分数
Chitchat_VA_About—V2	1	2	1	0.50	0.6667
Chitchat_VA_About—V3	1	1	1	1	1
Login_Issue—V2	9	8	0.8889	1	0.9412
Login_Issue—V3	9	7	0.7777	1	0.875

虽然#Login_Issue略有下降，但当前的 F1 分数为 0.875，仍然远优于基线 F1 分数 0.6153。记住，较小的数据集对微小变化更敏感，任何意图的变化都可能影响每个意图。这些变化可能会有负面影响或正面结果。然而，我们不会专注于这一点，而是在其他地方进行一些更改，并检查意图是否有所改善。

5.2.3 提高一个意图的 F1 分数

让我们继续提高#Item_Not_Received的 F1 分数。表 5.14 显示，在我们的 V3 更新后，它的 F1 分数为 56%。

表 5.14 在 V3 更新后，#Item_Not_Received的 F1 分数保持不变，为 0.56。

意图	样本数量	预测数量	召回率	精确率	F1 分数
Item_Not_Received—V2	16	9	0.4375	0.7777	0.56
Item_Not_Received—V3	16	9	0.4375	0.7777	0.56

该意图有八个训练示例，但我们的日志显示这是一个非常热门的话题，因此我们需要它表现得更好。我们将从我们的日志中添加 10 个更多示例到该意图（现在是 V4）并运行另一个实验。

表 5.15 显示，我们对于这个意图的召回率现在已经超过了两倍，尽管精确度略有下降，但 F1 分数得到了显著提高。分类器的整体准确率也从 78% 提高到了 81%。

表 5.15 #Item_Not_Received 在更新前后的指标显示 F1 分数有所提高。

意图	样本数量	预测数量	召回率	精确度	F1 分数
Item_Not_Received—V3	16	9	0.4375	0.7777	0.56
Item_Not_Received—V4	16	19	0.875	0.7368	0.8

5.2.4 提高多个意图的精确度和召回率

有时，由于具有相似目标的意图之间术语的重叠度很高，会导致混淆。图 5.6 显示了我们的测试工具提供的混淆矩阵。

在我们的模型中，我们观察到与被盗物品相关的意图之间存在相当多的混淆。解决这个问题的方法之一是合并意图。这必须仔细考虑。意图可能是由设计分别创建的，因为它们都有不同的答案。然而，可以使用实体检测来将流量路由到适当的答案。

图 5.6 V4 更新后的混淆矩阵。阴影密度表示针对特定意图预测的问题量。如果一个分类器测试具有完美的准确度分数，你将看到一个从左上角到右下角的实心黑色对角线。偏离这条对角线的阴影方块表示模型中的混淆区域。

我们将所有这些合并成一个名为 #Report_Stolen 的单一意图。这些示例列在表 5.16 中。别忘了盲测试集也需要反映这一变化，以及相关的对话流程。

表 5.16 将合并到新的 #Report_Stolen 意图中的三个意图的示例

意图名称	训练示例
Report_Stolen_Vehicle	报告一辆被盗的汽车
Report_Stolen_Vehicle	我需要报告一辆被盗的汽车
Report_Stolen_Plates_Registration	我的车牌被盗
Report_Stolen_Plates_Registration	我的注册证被盗
Report_Stolen_Plates_Registration	车辆上的车牌被盗
Report_Stolen_License_Permit_ID	被盗的真实身份证
Report_Stolen_License_Permit_ID	钱包被盗
Report_Stolen_License_Permit_ID	我的驾照被盗
Report_Stolen_License_Permit_ID	我的身份证被盗
Report_Stolen_License_Permit_ID	我的许可证被盗

对话流程将被更新，以便在话语中检测到定义的实体值或同义词时，提供相应的原始答案。你可能还需要一个默认条件来消除歧义或提供通用答案，以防话语触发了新意图但没有检测到实体。表 5.17 是这种情况可能看起来像的例子。

表 5.17 使用实体检测更新新 #Report_Stolen 意图的对话

实体/同义词检测	处理
车辆、汽车、卡车、摩托车	到 #Report Stolen Vehicle 的原始答案路由
车牌，注册，标签	到 #Report_Stolen_Plates_Registration 的原始答案路由
ID、执照、许可证	到 #Report_Stolen_License_Permit_ID 的原始答案路由
(未检测到)	分歧消除（“听起来像有什么东西被盗了；你能告诉我是什么吗？”）

通过这些更改，我们的分类器现在处于 V5 版本。表 5.18 显示了 V4 下三个旧意图的指标以及 V5 中我们新意图的指标。

表 5.18 V5 更新前后的指标显示，将三个意图合并为单个 #Report_Stolen 意图，在这个主题上实现了完美的分数。

意图	样本数量	预测数量	召回率	精确率	F1 分数

|

Report_Stolen_License_Permit_
ID

—V4

7	5	0.5714	0.8	0.6666

|

Report_Stolen_Plates_
Registration

—V4

5	4	0.8	1	0.8888
Report_Stolen_Vehicle—V4	2	2	0.5	0.5
Report_Stolen—V5 中的新意图	14	14	1	1

我们最新的更改显著提高了这个主题的性能，并将整体准确率提升至 85%，这现在高于我们的基线 k-fold（为 84%）。

更新完成之后，我们可以继续处理其他需要改进的意图。按照迭代过程，我们通过添加日志中的更多示例来更新表现最差的剩余意图。这成为了我们分类器的 V6 版本。表 5.19 是更新意图的概述。

表 5.19 从 V5 到 V6 训练示例数量的增加以及与代表性盲测试集中存在的体积更接近。

| 意图 | V5 训练示例数量 | V6 训练示例数量 | 代表性盲测试中的测试话语 |
| --- | --- | --- | --- | --- | --- |
| License_or_ID | 5 | 6 | 7 |
| License_Reinstatement | 4 | 6 | 5 |
| Login_Issue | 7 | 8 | 9 |
| Walk_In | 6 | 8 | 8 |

这次更新使得最新分类器的整体准确率达到 92%（现在处于 V6 版本）。在自然语言分类的世界里，这对于代表性盲测试集来说是一个非常不错的分数。你永远无法达到 100%；即使是人与人之间的交流也无法接近那个水平。

每个数据集都是不同的，如果数据量充足，我们可以花费更多几个周期微调我们的训练。然而，追求接近 100%的结果会有递减的回报。还有可能过度拟合你的模型到当前的盲测集。一旦有额外的日志可用并创建了一个新的测试集，你可能会发现更多的差距（或者你的过度拟合将被暴露）。

表 5.20 显示了基准分类器与最新更新之间的盲测 F1 分数的比较。十二个意图没有变化（并且它们已经表现得很出色）。一个意图从 90%下降到 80%，其余的 14 个意图有所改进。我们认为这是一个良好且合理的权衡，在牺牲一个意图略有下降的情况下，使超过一半的意图得到改进。

表 5.20 基准 F1 分数与 V6 F1 分数比较

意图	基准（V1）F1 分数	V6 F1 分数	变化
Accident_Report	1	1	(no change)
Appointment	0.8333	0.833	(no change)
Change_Contact_Records	1	1	(no change)
Chitchat_Goodbye	1	1	(no change)
Chitchat_Hello	1	1	(no change)
Chitchat_Thanks	1	1	(no change)
Chitchat_VA_About	0.6667	0.9524	+ 0.2857
Fee_Info	0.90	0.80	- 0.1
General_Negative_Feedback	0.80	0.80	(no change)
General_Request_Agent	0.80	0.80	(no change)
Get_ID_Number	0.75	0.8571	+ 0.1071
Item_Not_Received	0.56	0.8750	+ 0.315
License_Reinstatement	0.60	0.75	+ 0.15
License_or_ID	0.6667	1	+ 0.3333
Login_Issue	0.6153	0.9412	+ 0.3259
Name_Change	1	1	(no change)
Office_Information	0.90	1	+ 0.1
Payment_Methods	1	1	(no change)
Refund_Overcharge	0.8571	0.8571	(no change)
Report_Sold_Vehicle	0.9231	1	+ 0.0769
Report_Stolen_License_Permit_ID	0.80	(n/a - merged)	+ 0.2
Report_Stolen_Plates_Registration	0.8889	(n/a - merged)	+ 0.1111
Report_Stolen_Vehicle	0.50	(n/a - merged)	+ 0.5
Report_Stolen	n/a	1	(n/a – merged)
Request_Receipt	1	1	(no change)
Vehicle_Permit	0.8889	1	+ 0.1111
Vehicle_Title	0.40	0.8	+ 0.4
Walk_In	0.4615	0.75	+ 0.2885

练习

1. 使用前一个练习的输出（你最差表现意图的优先级列表），确定每个意图所犯错误的类别：召回、精确度或两者都有。

2. 通过迭代训练调整来改进每个意图。

3. 测量每次变化以验证

   • 预期的效果已经实现

   • 没有其他意图受到负面影响

5.3 解决“没有匹配意图”问题

现在我们已经将分类器调整得适合当前范围，如果需要的话，我们可以专注于扩展领域。在初步审查您的生产日志时，您几乎肯定会遇到一些未包含在初始训练集中的主题。其中一些主题可能是显而易见的，但也许在初始发布时没有足够的数据来训练意图。也许业务当时还没有准备好为某些主题编写答案。有时，由于这些主题没有成为任何人的首要任务（例如，税务季节、飓风季节、财政年度结束等），季节性主题可能没有被包括在内。其他主题可能是完全出乎意料的（例如，数据泄露）。

尽管您没有定义任何意图来匹配这些语句，但分类器总是会尝试做出预测；它不知道自己不知道什么，所以它会尽力将语句与已知的内容相匹配。在一个理想的世界里，分类器会返回非常低的置信度，这将触发“其他”或“没有匹配的动作”类型的响应。在现实中，这样的用户语句通常包含出现在您的训练中的某些单词，因此分类器可能会预测一个具有类似单词的训练示例的意图。

5.3.1 为新意图聚类语句

在第四章中描述的指南中，我们建议将那些与领域相关但未包含在原始范围内的语句留出。现在是时候解决这些问题了。

我们日志中揭示的一个主题与用户想要取消他们的执照或注册有关。我们知道从我们的日志中，在语句被提出时，分类器是如何预测每个语句的。现在我们可以用我们最新的分类器（V6）来测试它们，以获得新的模型预测。

在表 5.21 中，我们看到我们的分类器在语句包含“取消”这个词的任何形式时，表现出了低置信度或错误。

表 5.21：来自日志的未匹配语句与 V6 分类器的预测

语句	预测意图	置信度
取消注册	Appointment	0.2681
取消我的汽车注册	License_or_ID	0.3651
取消驾驶执照	License_Reinstatement	0.3042
取消注册	Appointment	0.2417
注册取消	Fee_Info	0.2786
取消我的注册	Item_Not_Received	0.3004
取消更换执照	Vehicle_Permit	0.3264
取消执照	License_Reinstatement	0.3237
取消车牌或注册	Vehicle_Title	0.5913
取消车辆注册	Item_Not_Received	0.2914
商业驾驶员执照取消	License_Reinstatement	0.2995
驾驶执照取消	Get_ID_Number	0.3387
我如何取消我的车辆注册？	License_or_ID	0.4324
我需要取消车辆注册	License_or_ID	0.3481
我需要取消我的身份证	Get_ID_Number	0.3205
我想取消我的车辆注册	Change_Contact_Records	0.3147
我想取消我的汽车注册	License_or_ID	0.3447
我想取消我的州身份证	Change_Contact_Records	0.2982
我想取消注册	Item_Not_Received	0.3155
我想确认取消我的注册	Item_Not_Received	0.4092
关于取消车辆注册的问题	Fee_Info	0.2795
我想取消我的皮卡注册	Item_Not_Received	0.4761

我们将这些随机分成包含九个表述的新#Cancel_Registration_or_License意图的训练集，并将剩余的十三个添加到我们的盲测试集中。

当我们将更新的盲测试集与更新的分类器（现在是 V7）运行时，我们得到整体准确率为 92%，这通常是一个非常好的，如果不是理想的结果。这并不总是如此，所以如果你的整体性能急剧下降，你需要迭代适用于受影响意图的适用改进步骤（取决于问题是召回、精确度还是两者），以解决这些问题。

让我们再通过一个添加新意图的例子来了解一下。日志中包含了几条关于数据泄露的表述。这是一个例子，说明了聊天机器人如何因为世界上的新信息而表现出下降的性能。在这种情况下，该组织之前从未经历过数据泄露。但是当它发生时，并且这个消息公开后，用户突然对它提出了很多问题。这表现为不匹配和不正确的预测，如表 5.22 所示。

表 5.22 从日志中关于“数据泄露”主题的不匹配表述，以及 V7 分类器的预测。分类器对大多数提到“黑客”或“数据泄露”的表述缺乏足够的信心进行匹配，这是好的，因为我们还没有教它关于这个主题的任何东西。但是，包含“被盗”一词的大多数表述都强烈匹配我们的#Report_Stolen意图。这可能不会对用户很好，因为我们的解决方案还没有关于被盗数据的任何答案。

表述	预测意图	置信度
我想了解 BMV 上的黑客攻击情况		n/a
我想了解 BMV 信息泄露的情况以及我是否处于风险之中		n/a
我的身份信息被盗	Report_Stolen	0.9483
我的许可证号码被盗	Report_Stolen	0.9240
需要回答关于数据泄露的问题		n/a
不，我对当前被盗身份证的泄露情况感到好奇	Report_Stolen	0.8604
有人黑客攻击了我的信息	Report_Stolen	0.4662
有人在使用我的驾照号码	Get_ID_Number	0.4067
有人偷了我的身份信息	Report_Stolen	0.7705
有人偷走了我的信息	Report_Stolen	0.8043
被盗的个人身份	Report_Stolen	0.9263
被盗的个人身份信息	Report_Stolen	0.9166
被盗的社会保障号码	Report_Stolen	0.7515
我的账户是否受到了最近数据黑客攻击的影响？		n/a
我的账户是否被黑客攻击？	Login_Issue	0.3998
是否发生了数据泄露？		n/a
嗯，我想知道我的驾照是否被泄露	Report_Stolen	0.4092
是的，我在 BMV 的数据泄露事件中该怎么办？		n/a
在黑客攻击中我的社会保障号码是否被盗？	Report_Stolen	0.7806
我想了解我的信息是否被盗	Report_Stolen	0.9198

为了解决这种不匹配的意图问题，我们从日志中选择了七个代表性语句来创建一个新的意图，称为#Data_Breach。我们的选择确保将各种重要术语，如“黑客”、“泄露”和“被盗”，添加到我们的新训练集中。其余的语句被添加到我们的盲测试集中，我们测试了最新的分类器 V8。新的#Data_Breach意图得到了满分，表 5.23 中的 F1 分数比较显示，几乎所有其他指标自基线以来都保持稳定或有所提高。

表 5.23 基线版本（V1）和最终版本（V8）的最终分数比较

意图	基线（V1）F1 分数	V8 F1 分数
Accident_Report	1	1
Appointment	0.8333	0.8333
Cancel_Registration_or_License	n/a (NEW)	0.9630
Change_Contact_Records	1	0.8889
Chitchat_Goodbye	1	1
Chitchat_Hello	1	1
Chitchat_Thanks	1	1
Chitchat_VA_About	0.6667	1
Data_Breach	n/a (NEW)	1
Fee_Info	0.90	0.9524
General_Negative_Feedback	0.80	0.80
General_Request_Agent	0.80	0.80
Get_ID_Number	0.75	1
Item_Not_Received	0.56	0.8750
License_Reinstatement	0.60	0.75
License_or_ID	0.6667	1
Login_Issue	0.6153	0.9412
Name_Change	1	1
Office_Information	0.90	1
Payment_Methods	1	1
Refund_Overcharge	0.8571	0.80
Report_Sold_Vehicle	0.9231	1
Report_Stolen_License_Permit_ID	0.80	(n/a - merged)
Report_Stolen_Plates_Registration	0.8889	(n/a - merged)
Report_Stolen_Vehicle	0.50	(n/a - merged)
Report_Stolen	n/a	0.9630
Request_Receipt	1	1
Vehicle_Permit	0.8889	1
Vehicle_Title	0.40	0.6667
Walk_In	0.4615	0.75

我们的总体准确率保持在 92%。（我们的更新后的盲测试集有 160 个问题，其中 147 个是正确的。）您可能还记得，我们第一次盲测试的总体准确率是 76%，所以这是一个很大的改进。图 5.7 中显示的 V8 混淆矩阵看起来也有所改进，有一个相当暗的对角线。

图 5.7 基线（V1）混淆矩阵与 V8 更新的比较

我们可以进一步迭代以尝试提高一点，但对于这个用例，分类器的准确性目前已经足够好了。使用我们目前有限的现有数据进行的任何进一步调整都可能使我们的模型过度拟合当前的盲测试集。请记住，一个健康的策略是在机器人的整个生命周期中迭代，使用新的日志和更新的盲测试集。

5.3.2 何时停止添加意图

在审查您的日志时，您可能遇到了各种各样的问题，这些问题对于该领域来说是完全合理的，但非常罕见。在我们的日志中，我们看到了以下问题，但没有类似目标的额外表述：

• 我需要一份医生填写的形式，说明一名驾驶员不再安全驾驶。

• 我有一个关于电子签名的问题。

• 获得特殊牌照的过程是怎样的？

我们如何知道何时停止添加意图？最好的做法是让我们的手动注释日志数据来引导我们。我们可以按意图汇总所有示例，并将其绘制成图表，如图 5.8 所示。

图 5.8 长尾图表的示例。我们用来描述可用训练数据量分布的术语是“短头”和“长尾”。这些术语描述了在柱状图上渲染我们的数据的视觉表示。高量级的意图位于左侧（短头），随着每个意图的量级减少，数据看起来像是从右侧掉落的长尾。

在我们的长尾图表中，我们选择了一个点来区分应该包含在范围内还是范围外。这个点不是一个静态的、规定性的位置。这是一个应该与业务方通过建立创建新意图所需的最小训练示例数量来做出的决定。所有落在这条线左侧的内容可能都应该包含在训练中，因为有证据表明这些主题将被更频繁地询问。所有落在这条线右侧的内容将不会在当前的分类器中进行训练。随着时间的推移，您可能在日志中找到足够的数据来证明添加新意图的合理性。在此之前，您的解决方案将不得不使用以下策略之一来处理这些主题：给出一个响应说机器人不理解，回退到代理升级，添加一个搜索集成以在文档存储库中查找答案，或者实现检索增强生成（RAG）或大型语言模型（LLM）组件来生成答案。

练习

1. 根据您的日志识别新主题，并从日志中找到的表述构建新的意图。

2. 将表述添加到您的盲集中，并测试您的更改。

3. 您的分类器能否在不会对现有意图的性能产生负面影响的情况下识别新的意图？

5.4 使用生成内容补充传统人工智能

在对话式人工智能中，我们通常认为提供的是静态答案（如在经典意图驱动实现中）或完全生成的答案（如在 RAG 模式中）。静态答案满足了一个需求，即答案必须在内容或结构上保持一致性。尽管个性化是可能的，但它通常仅限于定义的实体或其他由上下文驱动的对话条件。这往往会导致更冷、更缺乏个性化的机器人响应。图 5.9 显示了具有相同一般目标但个人情况非常不同的三个用户都收到相同机器人响应的情况。

图 5.9 在传统的（基于分类的）对话模式中，识别了一个意图，并且对话被配置为提供静态或最小个性化的答案。

5.4.1 为意图结合传统和生成人工智能

我们可以使用混合响应模式来增强用户体验，该模式结合了个性化的生成内容与我们为意图编写的静态预定义答案。我们的目标是承认用户的问题，同时确保重要信息以一致性传达。许多大型语言模型在总结任务上表现出色，因此可以提示模型编写一个传达个性化理解水平的同情信息。图 5.10 显示了从用户的角度看这会是什么样子。

图 5.10 一个输出响应使用传统人工智能识别正确的意图，然后在其为该意图配置的静态输出响应之前添加生成的文本。生成的问候和总结向用户传达机器人理解了他们的目标以及用户特定的情况细节。

这种模式使用 API 调用 LLM 作为对话步骤。内容由 LLM 生成，并在预定义的输出响应之前交付。图 5.11 显示了这种模式的高级步骤。

图 5.11 LLM 可以在传统对话模式中调用，以问候用户并在提供预定义或静态答案之前总结他们的问题。

5.4.2 提示以传达理解

在对话式人工智能中，您的机器人的角色通常是作为您公司的代表。他们是“数字”资源，而不是“人类”资源。尽管如此，他们的工作是要成为公司的面孔。人类代理擅长传达同情和理解。事实上，他们经常会重申用户的问题，以表明他们理解。可以提示 LLM 来模拟这种总结行为。

由于我们的传统 AI 已经根据这种模式对用户的意图进行了分类，我们可以制定一个提示，指导 LLM 执行特定任务。在这种情况下，我们希望 LLM 生成一个个性化的、富有同情心的问候语，可以与额外的静态内容搭配。下面的列表显示了总结用户输入的提示指令。

列表 5.1 指示模型问候和总结用户问题

<|instruction|>
You are a customer service agent for Friendly Skies Airline. Each input contains a customer problem. Greet the customer and summarize their problem. 

<|input|>
Hello! This is Chihiro — I had a flight credit for a cancelled flight from earlier this year. I don’t find the credit anymore. Can you look for me if you can locate it? This is for booking # WKRP01\. My frequent flyer # is 8675309\. Thanks a lot in advance!

<|output|>
Hello Chihiro. It seems you had a flight credit for a cancelled flight from earlier this year and you need assistance locating the credit for booking number WKRP01.

练习

1. 收集一组用户话语以测试和调整一个 LLM 提示，该提示可以在适当的时候问候用户并总结他们的问题。

   尝试各种指令提示。目标是创建一个高效的提示指令，以便为大多数话语测试集产生良好的结果。

摘要

• 分类器的性能可以用准确率、召回率、精确率和 F1 分数来衡量。这些测量反映了分类器可能犯的错误类型。

• 你的测试产生的性能指标将指导你下一步提高分类器性能的步骤。具有低性能的高体积意图是一个好的起点。

• 迭代测试和训练周期将显示你更改的效果。

• 一个聊天机器人可以使用额外的策略，例如消除歧义、澄清问题和实体检测，以克服混淆或为合并的意图路由答案。

• 一个具有强大分类器的聊天机器人可以通过在第一次尝试就给出正确答案，并转移由人工代理处理的工作，从而提供更多的商业价值。你应该计划在整个聊天机器人生命周期内监控和重新训练你的解决方案。

• 生成式 AI 可以通过在静态聊天机器人响应中注入个性化和同情心来补充传统 AI 解决方案，这增强了理解的感觉。

第六章：通过检索增强生成来增强响应

本章节涵盖

• 无需编码意图来增强聊天机器人响应

• 使用 RAG 改进薄弱理解

• 评估使用 RAG 相对于传统搜索模型的优势

• 为你的对话式 AI 选择合适的 RAG 技术

• 评估和改进你在对话式 AI 系统中 RAG 的性能

在前面的章节中，我们看到了问答机器人“不理解”的痛点。我们首先通过帮助聊天机器人理解更多意图来解决它，但在这个策略上，回报是递减的。来自“长尾”的不常见问题可能永远不会有意义地实现为意图。本章介绍了处理“长尾”的方法，包括搜索和检索增强生成（RAG）。这些是提高聊天机器人薄弱理解能力的好方法。

我们在第五章的结尾给出了关于何时避免添加新意图的建议，尤其是在处理多样化、不频繁的领域相关问题时。在本章中，我们将添加搜索功能来提高薄弱理解。

搜索和 RAG 都允许你通过添加数据和文档来改进聊天机器人，而无需编写新的意图。这使得你能够以仅训练少数几个的简单性来服务数千个意图。这些方法提供的答案更容易更改——只需更改文档而不是更改你的聊天机器人。

对于你作为构建者来说，搜索和 RAG 可能更容易，对于你的用户来说，它们可能更高效。让我们探索聊天机器人如何通过搜索和 RAG 功能来进化。

6.1 超出意图：搜索在对话式 AI 中的作用

传统的对话式 AI 集中在理解用户意图上。系统被训练来识别预定义的用户查询类别，并提供预编写的响应。

图 6.1 展示了基于意图的聊天机器人最简单的概念架构。聊天机器人的分类器检测意图并确定适当的对话流程。当分类器无法识别用户的意图时，答案是通用的“我没有理解”响应风格，导致“聊天机器人不理解我”的痛点。基于意图的问答是处理常见问题的好方法——你可以为不同的问题类型定义一个确切的答案。最初，这非常有效，但会崩溃。用户经常提出偏离预定义意图的问题。当预定义的意图不足以处理用户的问题时，用户可能会收到不相关或不正确的响应，导致挫败感。此外，维护和演进这些意图需要大量的努力。

图 6.1 基于意图的聊天机器人首先检测意图，然后将其映射到答案。

在答案的特定性和覆盖的变体数量之间存在权衡。图 6.2 展示了我们在第三章中引入的 PharmaBot 的例子。答案是准确的但通用的——它检测到一个关于副作用的问题，但没有回答用户问题中的所有细微差别。

图 6.2 基于意图的系统识别话语的主旨，并经常给出静态或通用的答案。

我们可以通过添加搜索功能来处理这种细微差别。有两种主要方法：

• 传统搜索向用户提供与他们的查询相关的文档或段落。用户使用这些文档来找到他们的答案。

• RAG从搜索过程开始，但通过总结段落为答案来扩展（增强）它。

图 6.3 说明了 RAG 如何通过定位相关文档段落并将它们综合成特定、情境化的答案来细化信息检索。与传统基于意图的系统不同，这些系统通常以固定或一般的答案响应，RAG 动态地拉入内容来回答用户的独特查询，展示了关于布洛芬和血压的具体段落是如何提炼成有针对性的建议的。

图 6.3RAG 找到相关段落并总结它们，给出有针对性的答案。

让我们更深入地探讨如何有效地添加这些功能。

6.1.1 在对话式 AI 中使用搜索

用户问题遵循“短头，长尾”分布，如图 6.4 所示。这种分布具有高频的常见或流行问题（短头）。大多数交互涉及较少见、利基或专业查询（长尾）。

图 6.4 用户问题分布。意图解决最常见的、高频率的问题，而低频率、独特的问题可能需要搜索集成。

对于 PharmaBot 来说，简短头部包括一般的 COVID 咨询，例如疫苗信息和预约。每个机器人将有一个不同的简短头部，但它将涵盖最常见的问题。当聊天机器人训练得很好时，这些问题会以高置信度被识别。意图允许构建者完全控制简短头部查询，尽管可能会忽略细微的区别。

我们之前看到 PharmaBot 没有很好地处理细微的问题，因为它使用了静态的#side_effects意图。图 6.5 显示了 PharmaBot 使用传统的搜索能力处理相同细微问题的方法。

图 6.5 搜索找到相关段落并直接显示给用户，通常还带有指向源文档的链接。

在这个例子中，响应包括了用户问题的所有细微差别。段落引用了疫苗副作用、布洛芬、血压和疼痛。然而，聊天机器人并没有提供一个单一、连贯的回答。相反，它提供了文档链接和片段。用户需要将这些文档和段落的答案结合起来。

6.1.2 传统搜索的优点

传统搜索可以通过使聊天机器人能够从文档存储库中检索相关信息来补充基于意图的聊天机器人。这种方法提供了几个优点：

• 广度—机器人可以访问您的文档存储库中的各种材料，为不同类型的问题提供答案。

• 维护—将知识添加到您的机器人中可以像在您的存储库中添加或编辑文档一样简单。

• 技术—搜索是一项成熟的技术，具有成熟的算法和实现方法。它可以用相对较低的计算资源和基础设施来实现。

• 速度—虽然比静态的基于意图的回答慢，但传统搜索执行得相当快。

因此，搜索是意图系统的一个很好的补充。将意图和搜索最常见的结合方式是在聊天机器人的自然语言理解（NLU）组件中使用置信度阈值。NLU 试图从用户的表述中检测意图。如果检测到意图的置信度较高，则返回基于意图的回答。否则，将用户的表述传递到搜索组件（在某些对话 AI 系统中，这被称为回退操作或意图）。高级架构如图 6.6 所示。

图 6.6 意图和搜索具有互补功能。一个搜索增强型机器人当它对识别到的表述有高置信度时，会使用基于意图的回答；否则，它将推迟到搜索。使用意图和搜索一起可以提高聊天机器人的能力，但这种方法仍然存在一些局限性。

6.1.3 传统搜索的缺点

当将传统搜索与聊天机器人应用集成时，存在两个基本问题领域：搜索结果的质量以及搜索结果呈现的用户体验。

搜索质量的一个主要缺点是它依赖于关键词匹配，这可能会根据用户的表述方式而变得不准确或脆弱。考虑之前的例子问题：“我可以和我的血压药物一起服用布洛芬吗？接种疫苗后我的手臂很疼。”这可能会被转换为“布洛芬 血压 药物 手臂 疼痛 疫苗”，强调最相关的关键词，但失去了问题的细微差别。

并非所有搜索引擎都局限于关键词匹配，但这是普遍现象。较新的搜索引擎支持通过意义而非关键词进行搜索。这种方法使用向量数据库，将在下一节中更详细地描述。像传统搜索一样，向量数据库搜索接受一个输入查询，并返回一组相关文档和段落。

基于搜索的选项的另一个主要缺点是接收文档和段落的用户体验。一些用户体验限制源于聊天机器人窗口的空间有限以及展示多个搜索结果所面临的挑战。这些问题通常通过显示少量结果（可能询问用户是否想查看更多）来解决。

有时通过显示文档链接（而非段落）来保留屏幕空间。在这种情况下，用户必须离开聊天界面，这会打断对话流程，可能导致用户放弃聊天机器人，继续在文档链接所指向的地方。

通过语音界面处理搜索结果也具有挑战性，导致长时间的朗读和非最佳的用户体验。

最重要的是，搜索并没有产生一个连贯的答案。一些用户可能更喜欢从相关文档中构建自己的答案。然而，当没有给出连贯的答案时，大多数用户都会感到沮丧，他们必须自己拼接——“我最初为什么要使用聊天机器人？我自己也能搜索。”

注意：您可能考虑将网络搜索与答案综合相结合。虽然聊天机器人可以从网络搜索结果中创建综合答案，但这种方法也有局限性。它需要更复杂的处理，但通过消除用户筛选多份文档的需求，解决了用户体验的局限性。这种方法在很大程度上取决于单个段落与查询的匹配程度，如果检索到的数据不全面，总结可能会遗漏细微差别或上下文。

基于答案综合的搜索通常依赖于基于规则的提取方法、排名算法、关键词匹配或预定义的启发式方法。通过结合检索到的文档中的信息来呈现这些响应。虽然这可以有效地呈现相关信息，但它可能难以处理不完整或模糊的查询。系统并不真正“理解”内容。相反，它选择并重新表述现有文本，这可能导致遗漏上下文、响应碎片化或过度依赖最突出的检索结果而不是最准确的结果。它缺乏生成方法的灵活性。

这正是 RAG 作为一个强大替代方案的地方。RAG 不仅仅是从文档中提取文本——它结合了检索与生成，使得聊天机器人能够使用来自各种来源的相关内容，生成一个连贯、情境感知的答案。与传统搜索和摘要方法不同，RAG 可以通过结合实时检索和语言生成能力，适应更广泛的用户问题，并提供更深入、更准确的回答。

下一节将探讨 RAG 如何通过提高准确性和保持上下文，即使在复杂或细微的查询中，也能增强聊天机器人的响应。

6.2 超越搜索：使用 RAG 生成答案

缺乏明确的答案是传统搜索方法的局限性。为了克服这些局限性，我们将探讨 RAG 作为一个高级替代方案。在其核心，RAG 结合了基于搜索的信息检索的优势和生成模型的灵活性，提供了一种更全面的方法来理解和回应用户查询。最重要的是，这个响应包括一个答案。

6.2.1 在对话式 AI 中使用 RAG

RAG 结合了检索和生成技术的最佳之处，以提升用户体验。像传统搜索一样，它检索相关段落来处理长尾问题。然后 RAG 将段落和用户的请求输入到生成 AI 中，生成答案。RAG 通过生成答案“增强”检索到的段落，创建一个无缝的对话流程，即使是复杂或长尾查询也是如此。

图 6.7 展示了 PharmaBot 使用 RAG 回答我们熟悉的例子：

User: “Can I take Ibuprofen with my blood pressure medication? My arms are sore after getting the vaccine?” 
Chatbot: Do not use over-the-counter ibuprofen for pain relief. Instead, use a painkiller less likely to increase your blood pressure, like aspirin.”

图 6.7 RAG 检索相关段落，并通过综合信息生成一个基于事实的答案来增强响应。

PharmaBot 可能仍然会检索到与传统搜索相同的段落，但现在它会总结它们来生成答案。这个答案承认了用户的特定关注点，并提供了定制建议。最重要的是，这个答案基于 PharmaBot 的源文档——而不是生成 AI 的一般知识。PharmaBot 可能会提供支持文档的链接，但它已经使答案突出，而不是文档段落。这对用户来说是一个更轻松的体验。

RAG 赋予聊天机器人更好地理解用户问题的能力，并通过最小化显式意图分类的需求来简化开发工作。这种方法的转变提高了用户满意度，并为对话式 AI 系统在未来人类语言和用户需求不断变化的环境中提供了保障。

使用 RAG（检索与生成）引入了动态性并减少了用户努力，前提是避免幻觉。虽然 RAG 本身可以减少幻觉，但并不能完全消除它们。应关注检索到的文档质量、生成模型的行为，以及当检索未能找到相关文档时的情况，我们将在后面讨论。

当用户与对话 AI 交互时，检索系统连接到受信任的内容来源，执行搜索（关键词、语义或向量），并为检索到的结果提供相关性评分。大型语言模型（LLM）随后使用检索到的信息增强其响应。它从检索的内容中生成响应，并通过聊天机器人界面将其呈现给用户。如有需要，它还可以应用翻译。

与传统搜索一样，RAG 可以补充基于意图的系统。短尾通过意图处理，而 RAG 处理长尾。答案与文档来源一样最新。文档比聊天机器人更容易更新！

6.2.2 RAG 的好处

RAG 是问答机器人的一个伟大补充。通过从您的知识库（而不是生成式 AI 模型知识）中检索信息，RAG 确保答案基于准确和最新的数据，从而增强机器人的可信度和可靠性。此外，RAG 通过使对话 AI 系统能够有效地处理广泛的用户查询和任务，扩展了其多功能性。它还减少了“机器人不理解”和“用户面临过多复杂性”的痛点。

RAG 的好处包括增强答案的相关性、适应性和改进的手动转接给代理。

增强相关性

RAG 的基本优势在于其访问和整合您知识库最新信息的能力。知识库提供的信息比预训练的意图更加多样化，LLM 可以将您的文档中的知识适应到答案中。

让我们再考虑 PharmaBot 的另一个例子。最初的 PharmaBot 包含了几个意图，包括餐馆用餐的指导。它根据一般指南进行响应，并包括“检查当地法规”的引用。没有针对用户的响应定制——这是一个一刀切式的答案。

表 6.1 比较了基于意图和基于 RAG 的 PharmaBot 版本。基于意图的提供通用答案，而基于 RAG 的则根据用户的问题本地化到纽约。

表 6.1 意图和 RAG 的答案比较

基于意图的机器人交互	基于 RAG 集成的机器人交互

| 用户：纽约餐馆当前的 COVID-19 指南是什么？ PharmaBot：餐馆餐饮的当前 COVID-19 指南包括限制室内容量、非就座时工作人员和顾客需佩戴口罩，以及加强清洁程序。请查阅当地法规以获取最新信息。

| 用户：纽约餐馆当前的 COVID-19 指南是什么？ PharmaBot：COVID-19 仍然是纽约人的一个重大关注点。确保您了解 2023-2024 季节更新的 COVID-19 疫苗，这些疫苗可以提供对新兴变异株的保护并增强整体免疫力。口罩仍然是减轻 COVID-19 和其他呼吸道病毒传播的有效工具，在各项活动中减少飞沫传播。为了最大限度地减少感染 COVID-19 的风险，建议个人在拥挤的室内公共场所佩戴口罩。

来源：纽约市卫生部门

|

集成 RAG 的聊天机器人承认用户位于纽约市。它提供更具体的信息，针对当地指南和法规，从当前的纽约市卫生指南中提取并总结，以适应餐馆就餐。这种个性化的方法通过根据用户的环境提供更相关和可操作的指导来增强用户体验。

适应性

在对话方面，RAG 的另一个优点在于对话式人工智能生成响应的方式——RAG 可以调整其生成的响应以适应用户问题的风格。如果用户的语气更倾向于寻求事实，则响应可以相应地更加正式。对用户独特问题的响应是实时生成的。有时用户期望一个简洁直接的答案（“是或否，餐馆就餐有限制吗？”），有时他们期望一个更长且更复杂的回答（“我可以带我的大家庭去餐馆，我们是否需要戴口罩？”）。这两个问题可能使用相同的源文档，但会收到非常不同的答案。

转接到人工代理（或不回答）

有时候，对话式人工智能无法找到明确的答案。在这种情况下，机器人回答不知道或转接用户到人工代理会更好。图 6.8 描述了用户向一个无法回答问题的聊天机器人提问的情况。

图 6.8 补充 RAG 与人工代理。如果答案与检索到的文档在语义上重叠度较差，则将用户转接到人工代理。

Sample chat:
User: I have achalasia. Will my dysphagia get worse if I get a Booster and experience side effects?

当用户提出问题时，对话式人工智能会遵循一个多步骤的过程来检索信息、生成响应，并在交付最终响应之前确定答案是否足够基于检索到的证据。以下步骤说明了这一过程，展示了系统如何检索相关段落、生成候选答案、评估其准确性，并最终决定是否响应或将用户转接到人工代理：

1. 段落检索——系统检索与贲门失弛缓症、吞咽困难以及疫苗副作用的一般信息相关的段落：

示例段落 1: "贲门失弛缓症 是 一种 影响 食管 的 疾病，导致 吞咽 困难。"`

示例段落 2：“疫苗的常见副作用包括疼痛、发烧和疲劳。”

示例段落 3：“吞咽困难，或吞咽困难，可能是食管疾病如贲门失弛缓症的症状。”

1. 2. 答案生成—LLM 基于检索到的段落生成一个候选响应：

Getting a booster might lead to common side effects, but there is no clear evidence linking it to worsening dysphagia in people with achalasia.

1. 3. 比较检查—系统将此生成的答案与检索到的段落进行比较，并识别出一个潜在问题：生成的答案包含一个“没有明确证据将其与吞咽困难恶化联系起来”的元素，而这个元素并未直接由检索到的段落支持。
2. 4. 转移决策—鉴于答案与检索到的段落之间的匹配率较低，对话式 AI 确定该答案可能缺乏足够的依据，可能会误导。然后，它提出将用户转移到人工代理以获得更可靠的答案：

Chatbot response: I apologize. I could not find a clear answer to your question in our resources. Let me connect you with a specialist who can provide more detailed information.

在这种情况下，对话式系统搜索相关文档段落，并将它们提供给 LLM。LLM 生成一个答案，然后对话式 AI 将生成的答案与检索到的段落进行比较。这种比较包括检测生成的答案中有多少单词和短语出现在段落中。如果百分比低，对话式 AI 决定该答案没有在文档中得到支持。然后，对话式 AI 优雅地承认其无法提供合适的基于文档的回答，并提出了另一种解决方案路径。

或者，搜索过程可能没有检索到任何文档。在这种情况下，对话式 AI 就不需要调用 LLM 来生成答案，它可以直接回避问题。对于这两种情况，对话式 AI 可以返回“我不知道”或其他后备响应。这两种选择都减少了产生幻觉和不相关答案的可能性。

6.2.3 将 RAG 与其他生成式 AI 用例结合

RAG 也可以与其他生成式 AI 用例结合使用。例如，RAG 可以处理信息查询，而其他生成式 AI 模型则专注于情感分析或语言翻译等任务。通过结合 AI 能力，对话式 AI 系统可以为用户提供全面的服务范围，进一步提高效率和满意度。

RAG 只是几个增强对话式 AI 的生成式 AI 模式之一。当用户提出常见问题或寻求有关产品或服务的详细信息时，RAG 会利用企业知识库提供准确和最新的答案。通过将回答建立在组织的特定领域，RAG 确保用户获得符合他们需求的相关信息。

然而，特定的用户查询可能需要比信息性回应更多的内容，需要采取可操作性的步骤（信息寻求与交易性问题）。在这种情况下，对话式人工智能系统执行交易并引导用户完成特定的任务或流程。例如，用户在从 RAG 获取有关产品或服务的相关信息后可能会表达出购买的兴趣。作为回应，对话式人工智能可以无缝过渡到交易性行动，例如启动结账流程或安排疫苗接种，从而促进用户旅程的顺畅和高效。

虽然 RAG 在高效和准确地响应用户查询方面表现出色，但额外的选项，如转交给人工代理或结合 RAG 与其他生成式人工智能用例，可以进一步优化用户体验。这些选项确保用户以最有效的方式获得他们需要的支持和帮助。

注意：对于 RAG 回应可能不足的情况——例如提供实时数据或满足特定客户请求——可以集成函数调用以动态地从外部系统检索信息。这种方法允许聊天机器人识别与实时响应相关的意图和参数，扩展 RAG 在复杂交互中的效用。虽然这里没有深入探讨，但如果您寻求一个更具动态性的对话式人工智能系统，函数调用是有价值的。

6.2.4 比较意图、搜索和 RAG 方法

表 6.2 总结了三种类型聊天机器人的功能和性能：基于意图的聊天机器人、与搜索集成的聊天机器人和 RAG 集成的聊天机器人。每种聊天机器人类型都是根据用户和聊天机器人创建者对对话式人工智能的期望和要求进行评估的。您可以通过比较这些属性来辨别最适合您特定需求的聊天机器人解决方案。

表 6.2 比较基于意图的聊天机器人、与搜索集成的聊天机器人和 RAG 集成的聊天机器人的功能

要求	基于意图的聊天机器人	与搜索集成的聊天机器人	RAG 集成的聊天机器人
处理查询的灵活性	限制于短头预定义的意图。可能忽略细微差别。	通过返回链接和片段处理长尾查询	通过返回答案处理长尾查询
回复的准确性和相关性	当意图以高置信度被识别时，答案准确且预先制作。	提供上下文相关且准确的文档，帮助用户找到答案	提供基于您的文档的上下文相关且准确的答案
向机器人添加新知识	手动添加或修改手动精选的意图-响应对	添加或修改您的知识库中的文档	添加或修改您的知识库中的文档
维护和可扩展性	当意图训练数据发生变化时进行广泛的回归测试。	文档库需要通过添加新文档和删除过时文档来维护。	文档库需要通过添加新文档和删除过时文档来维护。
响应生成质量	展示预定义的响应。	用户必须从检索到的段落和文档中自行组合答案。	答案基于源文档，但根据问题的细微差别进行了调整。

虽然传统聊天机器人帮助组织自动化简单任务并提供基本客户支持，但整合 RAG 技术增强了它们提供更准确、上下文感知的响应的能力，从而最终改善了用户体验。

练习

1. 考虑你上一次的聊天机器人实现，并考虑长尾概念：

   • 列出三个传统基于意图的聊天机器人可能无法充分解决的细分或罕见用户查询的例子。

   • 讨论这些查询如何体现对话式人工智能中的长尾现象。

2. 对于相同的聊天机器人实现，考虑使用传统搜索与 RAG 可以提供哪些答案。

6.3 RAG 是如何实现的？

如“检索增强生成”（RAG）的名称所暗示的，RAG 有两个阶段：检索和生成。在检索阶段，算法搜索并检索与用户提示或问题相关的信息片段。在开放域消费者环境中，这些事实可以来自互联网上的索引文档；在封闭域企业环境中，通常使用更窄的私有源以增加安全性和可靠性。

6.3.1 高级实现

使用 RAG，系统在知识库中搜索与问题相关的信息，并使用这些信息生成对话式答案。让我们分解步骤：

1. 用户向聊天机器人提问问题。

2. 系统使用其 NLU 能力来确定用户问题的意图：

   • 如果它以高置信度识别问题——例如，如果它是它训练的意图之一——它将能够回答，并且不需要搜索。这结束了流程。

   • 如果它无法识别查询，它将转到搜索。系统会将用户的查询发送到搜索工具以搜索文档内容，并生成和排名搜索结果。

3. 它将排名搜索结果返回给聊天机器人进行显示。（在 RAG 之前，排名链接和摘要列表会被返回给聊天机器人——使用搜索结果处理长尾问题仍然比提供“抱歉，我无法理解”的响应更有帮助。）

4. 而不是简单地显示结果，原始问题和搜索结果会被发送到一个 LLM。LLM 可能会重新排名搜索结果，但最重要的是，它生成一个简洁、总结、语言正确的答案。

5. 然后将答案返回给系统。

6. 答案通过聊天机器人用户界面呈现给用户。

注意：既不需要原始用户问题也不需要生成的答案与文档“完全”一致。虽然逐字回复确实可能发生，有时甚至出于法律原因更受欢迎，但主要关注的是将内容建立在知识库的基础上，确保生成的答案根植于精心挑选的文档集中。

由于 LLM 的本质，每次处理查询时都不会生成一致的结果。这些模型可以根据上下文或措辞的微妙变化对相同的问题产生不同的回答。这种可变性是由于 LLM 的概率性质，它们基于学习到的模式生成文本，而不是检索固定的回复。虽然这种灵活性允许提供更细腻和上下文相关的答案，但它也可能导致对一致输出的期望，而这并不是这些模型的工作方式。

强调这一点至关重要，因为对 LLM（大型语言模型）的工作原理不熟悉的团队成员通常会期望得到一致的结果。这种期望可能会阻碍项目进展，导致团队成员在解决问题的方法上存在差异。理解 LLM 优先考虑相关性和上下文，而不是精确复制文档内容，有助于调整期望并改善团队内部的协作。

在某些情况下，生成的回复可能与文档中的措辞非常相似，甚至完全一致。这通常发生在文档中包含直接针对用户问题的相关和有信息量的段落时。在这种情况下，RAG 模型可能会在生成的回复中包含文档的逐字摘录，以向用户提供最准确和相关的信息。

在其他情况下，RAG 模型利用知识库中的信息来理解与用户问题相关的上下文和概念。然后，它利用这种理解来生成与文档中找到的内容一致的回复，即使用户的提问或生成的答案的具体措辞在文档中并未逐字出现。这种方法允许在开发有效解决用户查询的回复时具有更大的灵活性和适应性，同时利用精心挑选的文档集中的信息。

6.3.2 为 RAG 准备您的文档存储库

让我们再考虑一下在 RAG 搜索过程中如何检索文档内容。图 6.9 提供了更多关于创建适当数据的信息。

图 6.9 RAG 在构建时间和运行时间都使用向量数据库。

一个系统的预处理管道确保了原始数据和用户的问题（或 LLM 对其的重述）都得到了优化，以便在基于 RAG 的搜索中使用。这个管道对于将数据转换为嵌入至关重要，使得模型能够高效地将用户的查询与相关信息匹配。然后应用如余弦相似度或其他方法来识别最佳匹配，确保准确和上下文适当的搜索结果。以下列表概述了该管道中涉及的关键步骤，详细说明了数据在用于检索之前是如何被处理的：

1. 预处理数据—系统（通常是一个数据管道，而不是 LLM 本身）处理原始文档，使其可搜索。例如，PDF 文档被转换为文本，或表格结构被转换为可处理语句。可能添加元数据以增强原始内容。然后文本被划分为连贯的语义单元，称为块。例如，文档可能在段落边界处被分割。分割是一种常见的识别和提取句子中有意义的单词组（“块”）的过程，用于进一步分析或处理。分割策略影响整体结果。有一些开源工具可以帮助可视化和理解不同的分割或拆分策略。

2. 嵌入生成—嵌入模型将这些块转换为嵌入或高维向量空间中单词或短语的数值表示。嵌入捕捉了单词和文档之间的语义关系，使得对连接的理解更加高效。相似的意义或上下文在向量空间中映射到附近，而不同的意义则映射到更远的点。这比关键字匹配提供了更相关的搜索结果。

3. 向量数据库中的存储—生成的嵌入向量存储在向量数据库中，这使得高效的相似性搜索成为可能。每个文档块都使用其向量表示进行索引，允许基于意义而非精确的单词匹配进行快速检索。

4. 运行时的检索和匹配—在运行时，最终用户与聊天机器人交互。他们的问题将使用相同的嵌入模型转换为向量，并在向量数据库中搜索，根据语义相似性找到最相关的段落（块）。然后检索到的段落被传递给 LLM，它将它们综合成对用户展示的响应。

这些步骤中的每一个都确保检索过程得到优化，使得 LLM 能够基于检索到的最相关数据生成准确、上下文感知的响应。

列表 6.1 显示了嵌入函数的示例代码。您可以使用任何自定义嵌入函数或其他向量数据库，性能可能取决于所使用的嵌入模型。这是 RAG 最常见的方法：您创建知识库的密集向量表示，以计算与用户查询的语义相似度。对于这个样本，我们使用了 Chroma 作为向量数据库。

列表 6.1 将文件分割成块，嵌入并存储在向量数据库中

from langchain.document_loaders import TextLoader
from langchain.text_splitter import CharacterTextSplitter
from langchain.vectorstores import Chroma

loader = TextLoader(filename)
documents = loader.load()
text_splitter = CharacterTextSplitter(chunk_size=1000, chunk_overlap=0)
texts = text_splitter.split_documents(documents)

from langchain.embeddings import HuggingFaceEmbeddings

embeddings = HuggingFaceEmbeddings()
docsearch = Chroma.from_documents(texts, embeddings)

在其核心，RAG 通过根据用户的查询检索相关文档或段落，然后使用自然语言生成技术生成响应来运行。这个过程可以通过使用其他文档检索和语言生成方法，而不进行显式的分块或嵌入来实现。

例如，使用 Lucene 作为分块和嵌入的替代方案，涉及使用其文档索引和检索功能。Lucene 可以处理检索部分，根据查询检索最相关的文档。检索后，RAG 的生成部分可以接管，根据检索文档的内容生成连贯的响应。Lucene 在文本检索方面非常高效，这把生成类似人类响应的复杂任务留给了 RAG 模型中更专业的生成组件。这种方法在强调检索准确性和速度而不仅仅是细微理解的系统中特别有利。

练习

1. 文本分块—在这个练习中，您将尝试不同的分块策略和嵌入：

   • 选择您的样本文本数据（您选择的任意小文本文件）。

   • 确定分块策略（按句子或单词分割）。对于您的实验，尝试使用分块工具。

   • 使用开源嵌入模型嵌入块，然后将块加载到向量数据库（Chroma）中。

2. 设置摄取管道—本练习将指导您构建一个简单的摄取管道，用于处理 RAG 系统中的文档：

   • 选择与您组织领域或聊天机器人特定用例相关的文档集。从简单的纯文本文档开始，即没有表格等。

   • 考虑易用性和与 RAG 兼容性等因素构建摄取管道。对于查询，使用开源模型、Hugging Face 嵌入模型和 llama 索引。

   • 实现数据集的摄取管道，以便预处理和结构化数据集以用于与 RAG 一起使用。

   • 使用样本数据测试摄取管道，以确保其正常功能和数据完整性。

6.4 RAG 实现的附加考虑

传统搜索返回相关文档的链接、段落或全文，用户需要筛选这些信息以找到他们的答案。RAG 相反，直接返回答案，用户可以选择查看所用的文档。

6.4.1 我们就不能直接使用一个 LLM 吗？

如果对话式 AI 将用户的查询传递给 LLM 并得到答案呢？毕竟，LLM 是在大量数据上训练的。

首先，由于 LLM 是在互联网规模的数据上训练的，其局限性是由于其训练数据的性质。这些数据代表了从公开来源在训练时间点的快照——它不包含特定业务、个人或机密信息，也不包含截止日期之后创建的公开数据。因此，即使是最新 LLM 的知识也可能过时，随着时间的推移导致不准确的结果。RAG 通过在 LLM 训练后提供数据来解决这一问题。

其次，由于 LLM 是从大量数据集中训练的，很难追踪其响应到来源，这损害了模型输出的可靠性和可信度。RAG 本质上是基于事实的，因为您确切知道为给定问题提供给 LLM 的数据是什么。

广泛领域的 LLM 带来了另一个重大挑战。由于可以访问大量信息，它们可能会在没有具体证据或上下文的情况下，自信地生成响应。这种产生看似合理但实际上错误或未经证实的信息的倾向被称为幻觉。相比之下，您希望您的对话式 AI 提供正确且基于事实的答案。高级提示技术可以帮助减轻幻觉，但通过 RAG 提供源数据更为可靠。

您还希望优先考虑基于特定文档或语料库的答案，而不是 LLM 所训练的文档。RAG 系统的主要重点是提供基于您文档的内容和上下文的响应，因此答案直接从语料库中的信息生成，从而提高了提供给用户的响应的准确性、相关性和可信度。

在选择特定的大型语言模型（LLM）用于您的用途之前，考虑其训练数据和领域是很重要的。如果 LLM 是在通用数据上训练的，而您需要特定领域的成果，它可能无法产生期望的结果。在这种情况下，您可以探索诸如模型混合等技术，通过结合多个模型来利用每个模型的优点，从而在特定领域提高性能。如果您有资源和可用数据，您还可以考虑微调所选模型以更好地满足您的需求。然而，这可能需要大量的计算资源和数据预算，因此首先考虑提示微调。尽管微调成本正在下降，并将继续下降，但它们仍然需要仔细考虑。其他针对特定领域训练的方法也正在出现，提供了更多的灵活性。

6.4.2 使用 RAG 保持答案的时效性和相关性

RAG 在问答方面直接使用 LLM 具有显著优势。虽然 RAG 仍然使用 LLM 进行自然语言生成，但 LLM 是从搜索到的文档中构建准确响应的。实时检索将在构建阶段添加新或更新文档时找到最新信息。RAG 确保答案反映了搜索知识源的最新文档。这种企业内容的实时集成增强了响应的相关性和准确性，并增强了用户的信心，因为他们知道他们正在接收最新和可靠的信息。

此外，RAG 不仅限于访问企业内容。它能够访问特定的段落，并从多份文档中检索信息。这种粒度允许 RAG 追踪和验证答案的确切来源，为用户提供全面透明度和可信度。这也为您的开发团队提供了责任和验证过程的便利，确保您知道您的机器人正在做什么以及为什么这么做。

此外，RAG 定义了 LLM 理解的范围，使其能够识别其知识和专长的限制。与直接使用且可能尝试在其领域之外提供答案的 LLM 不同，RAG 在遇到超出其范围的问题时能够承认。这种说“我不知道”的能力防止了它给出不准确答案，并在对话交互中促进了透明度。通过为其理解设定清晰的边界，RAG 使开发者能够构建优先考虑准确性、可靠性和完整性的 AI 系统，从而最终提升整体用户体验。

“我不懂”和“我找不到你问题的答案”之间有区别。虽然 RAG 的主要目标是根据检索到的文档内容生成有信息和相关的响应，但在某些情况下，系统可能找不到足够或适当的信息来生成有意义的响应。在这种情况下，RAG 模型通常会承认其无法提供令人满意的答案，并将此信息传达给用户。

然而，需要注意的是，RAG 系统的特定行为，例如返回“我不知道”的响应，可能受到检索组件的设计、知识库的质量、生成模型的设置或参数的影响。此外，开发者可以选择实施特定的策略或回退机制来处理系统无法生成响应的情况，例如提供替代建议或提示用户提供更多信息。

6.4.3 设置摄取管道有多容易？

设置一个能够有效保留文档结构的摄取管道对于确保 RAG 检索系统中的搜索结果准确性至关重要。必须考虑几个关键领域。本质上，您在组件上做出的每一个架构决策都将影响结果的总体准确性。

首先，您必须建立机制将现有内容存储连接到检索系统或迁移内容到新的存储库。这将允许检索系统访问必要的数据并保持数据完整性。

下一个挑战是在摄取过程中正确提取结构（如标题、表格和列表）。这些格式元素有助于文档的组织和清晰度。通过在摄取过程中保留这些结构信息，检索系统可以使用它来提高搜索准确性和相关性。

还有一些与分块相关的问题。将大型文档分割成代表性的子文档以进行索引的能力提高了检索过程的效率。这允许进行更细粒度的索引和检索信息，从而加快对长文档中特定内容的访问。此外，选择适当的搜索方法，如向量、语义、联邦、关键词或混合，进一步增强了检索系统的功能。

使用 LangChain 简化了设置摄取管道的过程。回想一下，您将需要

• 文档加载器——从各种格式加载数据。

• 文档转换器——处理和结构化数据以实现高效检索。

• 检索器——在查询时获取最相关的文档片段。

文档加载器简化了不同文档格式的摄取。这些加载器简化了工作流程，确保了高效处理和检索与 LLM 相关的上下文，以提供精确的响应。它们从源文档中加载数据，将每个提取的部分视为包含文本内容和相关元数据的文档。LangChain 提供了处理各种文件的内建功能：目录中的所有文件、PDF、CSV、JSON、HTML、markdown、txt 等。

例如，您可以从网页、字幕或企业文档中加载文本。文档加载器提供了一种load方法，用于从配置的源加载数据作为文档：

• 文本加载器：

from langchain_community.document_loaders import TextLoader

# Load text data from a file using TextLoader
loader = TextLoader("./your_data/YourText.txt")
document = loader.load()

• CSV 加载器：

from langchain_community.document_loaders import CSVLoader

# Load data from a CSV file using CSVLoader
loader = CSVLoader("./your_data/Yourspreadsheet.csv")
document = loader.load()

查看 LangChain 关于自定义 CSV 解析和加载的文档。例如，您可能希望指定您的分隔符、字段名等。同样，LangChain 提供了一个DirectoryLoader用于目录中的所有文档，一个UnstructuredHTMLLoader用于加载 HTML 文档，等等，用于常见类型。了解AzureAIDocumentIntelligenceLoader非常重要，这对于 Microsoft Office 类型的文档非常有用。

• 微软文档加载器：

%pip install --upgrade --quiet langchain langchain-community 
↪azure-ai-documentintelligence

from langchain_community.document_loaders import AzureAIDocumentIntelligenceLoader

file_path = "<your_filepath>"
endpoint = "<Your_endpoint>"
key = "<key>"
loader = AzureAIDocumentIntelligenceLoader(
    api_endpoint=endpoint, api_key=key, file_path=file_path, 
    ↪ sapi_model="prebuilt-layout"
)

documents = loader.load()

一旦你加载了文档，你需要查看文档转换器，它可以将长文档分割成 LLM 可以处理的更小的块。LLMs 有一个“上下文窗口”属性，决定了它们在一次遍历中可以有效地处理的文本长度，因此块必须适合 LLM 的上下文窗口。很容易假设设置更广泛的上文（即更长的文本段落）会自然而然地导致在各种语言理解任务上的性能提升。然而，最近的研究表明，这并不总是如此。证据表明，当呈现的文本总体较少时，语言模型可以达到更好的性能，但文本必须与当前任务高度相关。

较大的上下文窗口允许在推理过程中包含更多信息，但这种通常称为提示填充的技术有其权衡之处。处理更多文本需要更多的计算资源，这会减慢推理并增加成本——尤其是对于按字符付费的公司，总结长文档（如年度报告或会议记录）可能会变得昂贵。虽然较大的上下文窗口可以在一定程度上提高结果，但回报是递减的。像人类一样，LLMs 也可能经历信息过载；当面对过多的细节时，它们可能会忽略关键点。研究表明，LLMs 更有可能在提示的开始或结束时关注关键信息，可能会错过隐藏在中间的关键见解。

我们需要文档转换器来预处理文档，提取相关信息，并将其转换成语言模型在生成过程中可以高效使用的结构化表示。LangChain 有几个内置的转换器，使得文档操作变得简单。

分割过程如下：

1. 将文本分成更小的块。

2. 将这些较小的块组合成一定大小的较大块，通常可以通过某些函数来衡量。

3. 一旦达到那个大小，它就变成了文本的新单元。然后，你创建一个新的文本段，并保留一些重叠以保持片段之间的上下文。

你可以选择你的分割规则（字符、单词、标记）以及如何衡量块的大小。再次强调，LangChain 在 langchain-text-splitters 包中提供了许多不同类型的分割器。以下是一些文本分割器的示例：

1. 递归—递归分割文本是推荐的开始方式。它的目的是将相关的文本片段保持在一起。

2. HTML—一个“结构感知”的块分割器基于 HTML 特定的字符分割文本；示例见列表 6.2。它在元素级别进行分割，为块的相关性添加元数据。它保留文档结构中的语义分组和丰富的上下文信息：

   • 字符—它在用户定义的字符处（例如，"\n\n"）打断文档。

   • Code——它使用 Python 和 JavaScript（以及其他 13 种语言）的代码语法和语法标识符，将代码组织成逻辑组。

   • Markdown——它识别 markdown 语言并将文档组织成结构化格式（类似于 HTML）。

   • Tokens——它使用分词器，如 tiktoken，根据代码中定义的模型令牌限制来分割文本。

列表 6.2 HTML 分割器

# Install langchain-text-splitters if not already installed
%pip install -qU langchain-text-splitters

# Import necessary modules
import langchain
import langchain_text_splitters

print("Langchain version:", langchain.__version__)
print("Langchain Text Splitters module loaded successfully!")
from langchain_text_splitters import HTMLHeaderTextSplitter
from langchain.schema import Document  # Ensure Document is properly imported

from bs4 import BeautifulSoup

print("BeautifulSoup is installed successfully!")

# Sample HTML content to be split
html_string = """
<!DOCTYPE html>
<html>
<body>
<div>
<h1>Introduction</h1>
<p>This is the introduction section of the document.</p>
<div>
<h2>Chapter 1: Getting started</h2>
<p>This section covers the basics of getting started.</p>
<h3>Section 1.1 Setup</h3>
<p>This subsection explains the setup process.</p>
<h3>Section 1.2 Configuration</h3>
<p>This subsection details the configuration options.</p>
</div>
<div>
<h2>Chapter 2: Advanced Techniques</h2>
<p>This section dives into more advanced techniques.</p>
</div>
<br/>  <!-- Fix: Ensuring self-closing tag is correctly formatted -->

<p>What you learned in the Introduction.</p>
</div>
</body></html>
"""

# Define header tags to split on (h1, h2, h3 represent different levels of headers)
headers_to_split_on = [
    ("h1", "Header 1"),  # Top-level headers
    ("h2", "Header 2"),  # Subsection headers
    ("h3", "Header 3"),  # Sub-subsection headers
]

# Initialize the HTML header text splitter with the specified header levels
html_splitter = HTMLHeaderTextSplitter(headers_to_split_on=headers_to_split_on)

# Split the HTML document into structured chunks
html_header_splits = html_splitter.split_text(html_string)

# Display structured output
for doc in html_header_splits:
    print(f"Content:\n{doc.page_content}\nMetadata: {doc.metadata}\n{'-'*40}")

接下来，我们需要处理嵌入。数据类型和语言支持要求决定了嵌入模型的选择。此外，当处理特定领域或行业术语时，这些模型可能需要扩展。

LangChain 中的嵌入模型将文本转换为数值表示，或嵌入，以便进行处理。LangChain 与不同的模型提供商（OpenAI、Cohere、Hugging Face 等）集成以生成嵌入。例如，OpenAIEmbeddings 类使用 OpenAI API 创建嵌入，这可以通过 OpenAI 的 API 密钥或 Azure 的 OpenAI API 密钥来完成。

from langchain.embeddings import OpenAIEmbeddings
embeddings = OpenAIEmbeddings()

text = "This is a test document."
query_result = embeddings.embed_query(text)
query_result[:5]

其他集成包括 CohereEmbeddings、TensorFlowEmbeddings 和 HuggingFaceInferenceEmbeddings。

在获得嵌入后，您必须将它们存储在向量数据库中，例如我们之前使用的 Chroma。在选择向量数据库时，您需要考虑运行时性能、它如何根据您的数据集大小进行扩展以及整体性能。另一个重要考虑因素是集成 LangChain 等工具，它正在不断改进。LangChain 通过提供处理嵌入和集成各种机器学习和 AI 工作流的简化流程来增强向量数据库的功能。这种组合确保了高效的数据管理和检索，使其成为可扩展和高性能应用的稳健选择。

Retrievers 在嵌入和用户查询之间架起桥梁。虽然嵌入在向量数据库中存储了文档的数值表示，但检索器根据相似度评分识别和检索最相关的片段。

检索器的工作方式如下：

1. 使用在摄取期间使用的相同嵌入模型将用户的查询嵌入。

2. 向量数据库搜索最语义相似的嵌入。

3. 检索器检索最相关的匹配项并将它们传递给 LLM 以生成响应。

LangChain 包含多种检索方法。例如，LangChain 中有一个基于相似度的检索器：

from langchain.vectorstores import Chroma retriever = vector_db.as_retriever(search_type="similarity", search_kwargs={"k": 5}) retrieved_docs = retriever.get_relevant_documents(query)

检索器在仅返回最相关的文档片段中扮演着关键角色，确保 LLM 在专注、高质量上下文中工作，而不是原始、未处理的数据。

6.4.4 处理延迟

处理延迟的通用最佳实践尚未开发。对于用户来说，长响应时间令人沮丧，但这些技术可以增强他们的体验：

• 使用高效的搜索质量向量存储。 Facebook AI 相似性搜索（FAISS）库允许您快速搜索相似嵌入。有许多专门构建的向量数据库，如 Chroma、Milvus、Pinecone 和 Weaviate，还有更多正在出现。传统的数据库和搜索系统，如 Elasticsearch，提供向量搜索插件。每个都有其独特的优势，可以根据您的需求进行选择，包括可扩展性、功能、性能和成本。

• 预处理和整理您的数据集。 相同文档的多个相似版本会增加搜索时间并降低搜索结果质量。

• 在执行慢动作之前通知用户。 一个适当的语气信息，例如“只需稍等片刻”，可以安抚用户并填补延迟。

• 流式响应以在生成每个标记时向用户展示答案。 LLM 可能需要 1.5 到 5 秒或更长时间来生成答案，搜索可能需要 5 到 10 秒。如果对话式 AI 等待 LLM 完成，用户可能会认为聊天机器人已损坏。

• 考虑缓存。 通过缓存每个用户的向量数据库和聊天历史，可以存储与用户交互相关的常用信息。这减少了每次都需要从头生成响应的需求，从而节省了所需的计算资源。虽然缓存可能会消耗额外的标记，但权衡的结果是提高了效率。

6.4.5 何时使用回退机制和何时搜索

确定是否使用 RAG 的响应或转向人工代理涉及几个关键考虑因素。例如，如果检索没有产生适当的结果，则不应调用 RAG 的生成部分。在这种情况下，对话式 AI 可以优雅地退出查询，并响应提出将用户转交给人工代理的提议。通过绕过基于可能较差的搜索结果生成答案，您有效地减少了最终用户的延迟，确保他们能够收到及时的响应，同时节省了计算资源。

图 6.10 展示了确定是否使用 RAG 响应或手动将查询转交给人工代理的决策过程：

1. 对话式 AI 处理用户查询并将其传递给检索系统，检索系统搜索知识库以找到相关信息。

2. 检索结果将被评估以确定它们是否适合生成响应。

3. 如果检索结果被认为合适，系统将使用全功能的 RAG 方法生成响应。

图 6.10 当 RAG 的答案与检索到的段落不匹配时，提供人工代理可能更好。

1. 4. 如果检索结果不合适（例如，结果不足或无结果），系统将优雅地提出将查询转交给人工代理。
2. 5. 响应（无论是系统生成还是传递给人工代理）将返回给用户。

6.5 评估和分析 RAG 性能

在对话式人工智能系统中评估 RAG 模型的能力是多方面的。必须对每个能力进行评估以得出总体结果。大多数评估考虑了三个方面：

• 这是否是正确的响应？ 答案是否直接回答了用户的问题？例如，如果用户询问重置密码，响应应清楚地解释步骤，而不是讨论更广泛的账户安全问题。

• 这个用户是否处于正确的上下文中？ 响应是否考虑了用户的特定情况或历史？例如，如果用户之前报告了账户问题，系统应提供定制的后续解决方案，而不是通用的建议。

• 响应是否基于文档（或由生成过程虚构或编造）？ 响应是否准确反映了从源文档中检索的信息，而没有编造细节？例如，在解释退货程序时，应正确引用公司的政策文件，而不是创建不存在的政策。

一个 LLM 可以根据关键标准对响应进行评分，以增强评估过程。这种方法与人工审查结合使用时效果最佳：LLM 提供初步评估，然后人工评估人员验证响应的准确性和上下文相关性。

这些评估标准有助于确定聊天机器人的回答的真实性。如果源文档准确且 RAG 检索了正确的文档，则生成的答案也应准确。响应的评估可以分解为评估 RAG 的不同组件，可以单独评估其整体性能，包括文档索引的质量、检索过程的有效性和答案生成的准确性。

6.5.1 索引指标

索引指标提供了关于系统如何高效组织、存储和检索大量数据的见解。关键考虑因素包括索引速度、存储需求、可扩展性以及系统处理高维数据（如向量）的能力。表 6.3 总结了这些重要方面，提供了快速概述和相关示例。

表 6.3 影响 RAG 系统文档索引效率和准确性的关键指标

方面	摘要	示例
索引指标	评估速度、存储需求和可扩展性。对大规模数据系统至关重要	对于新闻聚合器，速度和规模至关重要
向量数据库性能	衡量处理高维数据的性能	对于技术支持，必须为多个文档组装准确的故障排除步骤。例如，“为什么我的设备过热？”
召回率	表示检索相关数据的准确性。高召回率对于完整检索至关重要。	在法律文件检索中，高召回率确保找到所有相关案例。
查询复杂性	根据查询的具体情况、维度和数据集多样性影响性能	处理多个数据点的金融数据库中的复杂查询
基准测试工具	像 ANN-Benchmark 这样的工具会在诸如召回率与 QPS（每秒查询数）之类的指标上比较算法。	评估哪种算法在视频搜索引擎中最好地平衡了速度和准确性

首要的关键组成部分是评估索引指标，这涉及到评估在一个系统知识库中组织和访问数据的效率和效果。这包括检查诸如索引速度、存储需求和索引过程的可扩展性等因素。高效的索引对于 RAG 系统至关重要，因为它影响信息检索的速度和准确性。无效的索引可能导致响应时间慢和数据检索不准确，从而损害响应质量。

向量数据库的性能是另一个重要的指标，专注于存储和检索表示复杂数据（如文本、图像或嵌入）的高维向量。这些数据库执行近似匹配搜索而不是精确匹配搜索，因此需要超越传统数据库性能指标（如每秒查询数 QPS 和延迟）的性能评估。虽然这些指标对于评估系统速度和响应性很重要，但它们并不能直接捕捉检索结果的准确性。因此，除了 QPS 和延迟之外，召回率也是向量数据库的另一个重要性能指标。如果向量数据库表现良好，RAG 模型可以访问高质量、相关的信息，从而生成更准确和上下文适当的生成内容。相反，性能不佳可能导致检索时间慢，以及使用不相关或不那么有用的数据生成。

考虑一个客户支持场景，其中由 RAG 系统驱动的聊天机器人被用来处理询问。在高召回率的情况下，聊天机器人能够从知识库中访问广泛的信息，有效地解决客户查询并提高满意度。然而，低召回率可能导致关键信息的遗漏，导致响应不足并增加客户的不满。因此，聊天机器人的有效性在很大程度上取决于其全面检索相关信息的能力，这突出了在自动化支持系统中高召回率的重要性。

查询复杂度，受查询的维度和特定性、数据多样性等因素影响，也会影响向量数据库的性能。高维查询需要更多的计算资源，因为向量之间的距离计算变得更加复杂。这可能导致检索任务的时间和内存使用增加。更具体的查询可能针对向量空间中的非常狭窄的片段，这可能会挑战索引系统有效地隔离和检索相关向量，尤其是在大型数据集中。高查询复杂度可能会使系统压力增大，可能导致检索时间变慢和返回的数据相关性降低。此外，复杂的查询使得区分相关和不相关结果变得困难。

想象一个电子商务平台上的聊天机器人，它旨在帮助客户使用涉及多个属性（如品牌、颜色、尺码和用户评分）的复杂查询来查找产品。例如，客户可能会要求聊天机器人提供“6.5 号蓝色阿迪达斯运动鞋，最低 4 星评分。”这个查询由于其跨多个维度的特定性而提出了多方面的挑战。这些属性中的每一个在数据库中代表一个不同的向量。

像 ANN-Benchmarks 和 VectorDBBench 这样的基准测试工具通过比较不同的算法和配置来帮助评估这些方面，确保 RAG 系统建立在稳健的检索基础上，以实现持续的高质量内容生成。ANN-Benchmarks 在x轴上绘制召回率，在y轴上绘制每秒查询数（QPS），说明了每种算法在不同检索准确度水平上的性能。VectorDBBench 分别显示 QPS 和召回率。

6.5.2 检索指标

下一个能力是检索指标，它衡量系统从索引数据中检索相关信息的能力。关键方面包括检索准确度、精确度、召回率和响应时间。有效的检索指标确保用户收到准确和相关的响应，从而提高对对话式人工智能系统的满意度和信任度。表 6.4 总结了这些重要方面，随后是更详细的解释。

表 6.4 影响检索指标的关键方面

方面	概述	示例
检索准确度	评估系统从索引数据中检索相关信息的能力	确保聊天机器人从大型数据集中检索准确的故障排除指南
精确度和召回率	精确度衡量检索文档的相关性；召回率衡量检索到的相关文档数量。	在电子商务聊天机器人中检索产品推荐时平衡精确度和召回率
上下文精确度和上下文召回率	特定于 RAG：上下文精确度检查相关性；上下文召回率检查相关信息覆盖范围	评估生成的响应在支持聊天机器人中与查询上下文匹配的程度
参数优化	调整搜索参数和算法以提高结果的速率、准确性和相关性	调整 FAISS 集群或 Elasticsearch 设置以改善法律数据库的文档检索
嵌入模型	使用不同的嵌入通过提高精确度或召回率来影响检索质量	在法律建议聊天机器人中使用 BERT 进行精确的上下文理解
过滤和重新排序	策略用于去除噪声并重新排序结果以提高相关性和准确性	在新闻聚合聊天机器人中过滤掉不相关的文章，然后重新排序顶级结果
标准化折现累积增益 (NDCG)	通过考虑检索文档的相关性和位置来评估排名质量	确保在技术支持聊天机器人中，最相关的帮助文章出现在顶部

这些指标评估搜索质量、文档相关性和用户查询与响应的匹配程度。检索准确性衡量系统从其索引数据中检索最相关信息的能力。如果检索准确性低，聊天机器人可能返回仅与用户查询松散相关的响应或无法检索关键细节。

精确度衡量检索到的相关文档的比例。召回率衡量系统检索到的相关文档的数量。高召回值表示系统从数据库中检索到许多相关文档。相比之下，高精确度值表示检索到的文档大多与用户的查询相关。平衡召回率和精确度对于确保全面覆盖相关信息并最小化无关结果至关重要。

对于 RAG 模型，上下文精确度和上下文召回率评估生成的响应与用户查询的对应关系和覆盖范围。上下文精确度衡量检索到的上下文与用户查询的匹配程度，表明生成响应的相关性和准确性。上下文召回率衡量生成的响应如何全面地覆盖检索上下文中的相关信息。

您应该实施各种策略来增强检索过程：

• 优化搜索参数

• 使用不同的嵌入模型

• 实施过滤和重新排序

第一种策略是调整检索参数以改善速度和准确性。调整搜索参数，如 FAISS 中的集群数量或 Elasticsearch 中的搜索查询复杂性，可以显著提高检索文档的精确度和召回率。这确保了系统返回最相关的文档，提高了精确度，并检索所有相关文档，提高了召回率。

参数优化还可以减少响应时间，使系统更加响应迅速。调整索引和查询算法可以导致检索时间更快，而不会影响准确性。

第二个策略是利用不同的嵌入模型来找到检索相关文档的最有效组合。嵌入可以极大地影响检索质量。例如，BERT 和 Sentence-BERT 可以提高系统对用户查询的上下文和语义的理解，从而提高精确度。GPT-3 嵌入可以提供更广泛的上下文理解，通过从不同的上下文中检索更多相关文档来提高召回率。

第三个策略是实现过滤和重新排序。过滤和重新排序策略通过移除无关文档进一步提高了精确度，并通过优先考虑相关文档来提高召回率。如特定领域过滤器或上下文感知重新排序等技术可以显著提高顶部结果的相关性。

标准化折现累积增益（NDCG）在检索文档顺序很重要时很有用。它通过评估搜索结果中文档的相关性和位置来衡量排名算法的有效性，提供全面的排名质量评估。

6.5.3 生成指标

评估的最后一个领域是生成本身：生成的输出是否提供了相关且完整的答案。表 6.5 提供了一个关于这些关键指标、提高生成质量策略及其应用实例的简要概述，随后是更详细的说明。

表 6.5 影响生成指标的关键方面

方面	摘要	示例
忠实度	根据检索到的上下文评估生成输出的事实准确性	确保聊天机器人回答在回答问题时是事实正确的。例如，“违反合同会有什么后果？”
答案相关性	评估生成的答案与特定用户问题的相关性	“我的订单状态如何？”聊天机器人检索到相关数据后，回答：“您的订单编号 12345 目前正在运输中，预计将于 8 月 15 日交付。”此响应直接与用户的问题相关，提供了关于订单状态的特定信息，而没有不必要的细节。
微调	通过将 LLM 与特定领域的数据对齐，提高生成内容的准确性和相关性	微调 LLM 以提供法律建议，确保生成的响应准确且具有法律相关性
提示工程	通过构建提示来引导 LLM 生成更符合语境和相关的响应	使用提示工程确保医疗聊天机器人提供清晰、相关的医疗建议
模型融合	结合专业模型以提升生成质量，平衡准确性和流畅性	将以检索为重点的模型与以语言为重点的模型融合，以生成准确、流畅的响应
敏感性与特异性平均值（SSA）	衡量开放域聊天机器人的响应质量，确保响应既合理又具体	评估开放域聊天机器人的响应，以确保它们有意义且不过于模糊
忠诚度评估器	通过与检索到的上下文对齐来评估生成的响应是否避免了幻觉	使用 FaithfulnessEvaluator 确保金融聊天机器人的响应基于检索到的文档

评估 LLM 性能的两个主要指标是忠诚度和答案相关性。忠诚度根据检索到的上下文评估答案的事实准确性，而答案相关性评估答案与给定问题的相关性。一个答案可能是事实准确的（忠诚的），但与问题不太匹配（相关性较低），或者可能是准确的，但不是基于来源文档的。

可以采用几种策略来提高生成指标。通过在特定领域的数据上微调 LLM，可以通过使模型更紧密地与它将运行的上下文对齐来提高忠诚度和相关性。这确保了生成的响应是准确且与特定领域相关的。您还可以考虑结合提示工程。通过在提示中明确包含必要的上下文或约束，生成过程变得更加专注并符合用户的意图。模型混合也可能被使用。结合多个模型，每个模型在任务的各个方面都专门化，可以帮助提高生成质量。例如，一个模型可能在检索准确信息方面表现出色，而另一个模型可能在生成流畅且上下文适当的语言方面更出色。混合这些模型可以导致更平衡和有效的输出。

敏感性与特异性平均值（SSA）指标评估开放域聊天机器人的响应质量。敏感性确保响应在上下文中有意义，而特异性平均值确保全面性而不含糊。历史上，人类交互对于分配这些评分是必要的。

避免模糊的回答是至关重要的，但防止大型语言模型（LLMs）产生幻觉同样关键。LlamaIndex 建立了一个 FaithfulnessEvaluator 指标，通过评估响应是否与检索到的上下文一致来衡量幻觉。LlamaIndex 的开发旨在解决将 LLMs 与各种数据源连接的挑战，以便 LLMs 可以访问、查询并从结构化和非结构化数据中生成见解。它是一个用于构建上下文增强生成式 AI 应用的框架。它提供了数据集成、索引、丰富查询处理等功能。请关注 LlamaIndex 的最新更新。

集成 RAG 的对话式人工智能有效地解决了罕见或复杂的问题。然而，从 RAG 中实现这些优势需要持续监控所有组件，尤其是在失败常见的领域，如检索和生成过程中。

6.5.4 比较 RAG 的索引和嵌入解决方案的效率

在前面的章节中，我们介绍了影响 RAG 系统效率的因素。索引和嵌入组件对于有效地检索相关文档和确保系统的响应性至关重要。在将 RAG 实施于对话式人工智能系统中时，重要的是要衡量其对检索准确性和响应相关性的影响。基准测试对于创建有效的 RAG 系统至关重要。您必须有一种方法来评估系统提示的变化是否提高了用户查询命中率。这种改进是 1%、2% 还是更多？这是了解您的 RAG 系统是否真正有效的基本途径。

此外，如果没有适当的监控、验证和评估，将很难证明您系统的有效性。RAG 本身就非常复杂，典型的实现最初准确率在 50% 到 60% 之间。您希望将准确率提高到 80% 以上，以实现一个实用的解决方案。

PharmaBot 最初作为一款用于处理一般咨询的 COVID-19 聊天机器人而开发，例如疫苗信息和预约安排，现在将增强 RAG 功能。目标是扩展 PharmaBot 的功能，以回答更细微的问题，例如“我可以和我的血压药物一起服用布洛芬吗？”以及“接种疫苗后我的手臂很疼。我该怎么做？”首先，我们将选择一个包含医学文章、研究论文和来自卫生组织的指南的数据集，所有这些都关注各种健康问题和药物与疫苗的相互作用。接下来，我们将编制一组代表性的查询，如之前所列，这是用户可能会提出的问题。

我们将选择我们想要使用的索引解决方案和嵌入。对于索引，我们将考虑几个选项，例如 FAISS 和 Elasticsearch。最新的文本嵌入模型性能基准的最受欢迎来源是 Hugging Face 主办的 MTEB 排行榜。虽然 MTEB 提供了一个有价值的起点，但显示的结果是自行报告的，许多模型在应用于真实世界数据时可能不会那么准确。BERT、Sentence-BERT 或 GPT-3 嵌入值得考虑，因为它们已在许多解决方案中使用。然后我们将运行我们的选择来为我们内容生成嵌入，并使用所选方法索引我们的嵌入。最后，我们将运行我们的查询并衡量我们的性能。

当评估增强 RAG 的 PharmaBot 时，我们可以使用表 6.6 来确定相关指标，为这些指标建立基线和目标，以评估由不同的索引（FAISS，Elasticsearch）和嵌入（BERT，Sentence-BERT，GPT-3）解决方案组合引入的改进，并比较解决方案。例如，我们可以比较 RAG 组件的组合如何与业务目标相匹配。

表 6.6 基于业务目标的 RAG 评估优先指标

业务目标	优先指标	为什么？	示例

| 客户满意度 | 响应准确性 | 相关性

直接影响用户体验和满意度	PharmaBot 为用户提供准确答案

| 运营效率 | 延迟 | 吞吐量

确保系统可以快速处理大量查询	为大型电子商务平台提供客户支持聊天机器人应优先考虑低延迟，以便在购物高峰时段提供快速响应。

| 可扩展性 | 每秒处理的查询数 | 资源利用率

评估系统在不断增加的负载下的性能	用于管理季节性预约和查询高峰的医疗服务提供商聊天机器人

| 成本效益 | CPU 使用率 | 内存使用率

确保高性能而不过度消耗资源	为提供 24/7 心理健康支持的慈善组织提供聊天机器人

你可以创建一个类似于表 6.7 中的比较表。这些样本数字是假设的，应根据实际选定的组件和基准测试结果进行调整。例如，一种配置可能是选择 Elasticsearch，然后使用三种不同的嵌入模型来得出你的数字。

表 6.7 PharmaBot 各种配置的评估

| 指标 | | 配置 1 | 配置 2 | 配置 3 |
| --- | --- | --- | --- |
| 响应准确性 | 召回率 | 0.85 | 0.87 | 0.88 |
| | 精确度 | 0.75 | 0.77 | 0.78 |
| | F1 分数 | 0.8 | 0.82 | 0.83 |
| 相关性 | 平均倒数排名（MMR） | 0.70 | 0.72 | 0.74 |
| | 平均精确度 | 0.65 | 0.68 | 0.70 |
| 延迟 | 平均延迟（ms） | 50 | 55 | 60 |
| 吞吐量 | 每秒查询数 | 20 | 18 | 16 |
| 资源利用率 | CPU 使用率（%） | 70 | 65 | 90 |
| | 内存使用量 | 8 | 7 | 12 |

当尝试使用 RAG 满足 PharmaBot 的整体业务需求时，必须根据评估指标考虑各种权衡。一个索引组件与选定的嵌入组件的组合提供了高响应准确性和相关性，同时具有较低的延迟和较高的吞吐量，这使得它们适用于需要快速和准确响应的系统。然而，这些组合表现出中等至高的资源利用率，可能会增加运营成本。相反，将另一个嵌入组件与各种索引策略集成，可以提供更优的响应准确性和相关性，但代价是显著更高的延迟和较低的吞吐量，这是由于所选嵌入的计算需求。这可能会影响系统高效处理高查询量的能力。高 CPU 和内存使用也可能对资源造成压力，增加运营成本。最终，选择最佳组合需要在高准确性和相关性需求与系统高效处理查询的能力之间，以及管理资源利用率以控制成本之间取得平衡。

此外，应考虑对 RAG 系统的持续重新评估和改进。表 6.7 并不全面，但关键点是确定关键评估指标，然后使用结构化评估方法。系统测试和关注 RAG 组件提供了一个稳健的 RAG 评估流程。总体目标是看到最终的趋势呈上升趋势，如图 6.11 所示。系统地应用本章讨论的策略，然后分析结果，可以揭示不同配置对 RAG 性能的影响。一些调整显示出显著的改进，强调了实验和调整的重要性。没有最佳方法；在调整你的 RAG 系统时探索多个方向至关重要。

图 6.11 不同的配置和增强提高了 RAG 系统的准确性。

此外，你可能还想使用 RAG 评估框架，从专有付费解决方案到开源工具。选择正确的解决方案需要在维护的便利性和运营负担之间取得平衡，以及工具观察到的指标如何映射到你的 RAG 管道和你的业务目标。以下是一些当前示例，但更多正在开发中，提供了更多的选择：

• Arize—一个专注于精确度、召回率和 F1 分数的模型监控平台。它在需要持续性能跟踪的场景中非常有用，确保 RAG 系统在实时应用中持续满足准确度阈值。Arize 是一个专有付费产品，为企业的部署提供强大的支持和持续更新。

• RAGAS—一个开源工具，提供了一种简化的、无需参考的评估方法，重点关注平均精度（AP）和忠诚度等自定义指标。它评估生成内容与提供上下文的一致性，适用于初步评估或参考数据稀缺的情况。

练习

1. 评估 RAG 模型在对话式 AI 系统中生成的响应的相关性：

   • 定义评估标准以衡量 RAG 模型生成的响应的相关性。

   • 建立一个评分系统，根据语义相似性和信息性等因素量化响应的相关性。

   • 设计一套用户查询以进行评估。

   • 创建一组预期响应（手动）。

   • 将生成的响应与先前创建的响应进行比较，以确定相关性的程度。

   • 计算评估指标，如精确度、召回率和 F1 分数，以定量评估 RAG 模型在生成相关响应方面的性能。

   • 分析评估结果，以识别 RAG 模型在生成相关响应方面表现优异或失败的模式或区域。

   • 讨论可能影响响应相关性的因素以及提高 RAG 模型在此方面性能的策略。

2. 使用 RAG 评估文档基础：

   • 使用 RAG 模型对用户查询生成响应，并识别响应来源的文档或段落。

   • 通过比较源文档或段落的相关性来评估定位程度。

   • 开发一种评分机制，根据文档相关性和覆盖范围等因素量化 RAG 模型的定位有效性。

摘要

• 通过集成搜索功能，传统的基于意图的聊天机器人可以大大增强。

• 意图非常适合回答常见的简短问题，而搜索非常适合长尾问题。

• 传统的搜索返回链接或文档段落，而不是答案。

• RAG 通过从搜索检索到的文档中生成答案来扩展搜索功能。

• 通过使用 RAG，聊天机器人可以实时提供上下文相关的响应，减少用户的不满，并增强对话体验。在组织的领域内定位答案也解决了开发者的意图维护和增强问题。

• RAG 实现必须考虑从处理延迟到提供回退机制或转交给人工代理以防止幻觉的几个问题。

• 对 RAG 的评估必须考虑索引、检索和生成等不同组件。

第七章：使用生成式人工智能增强意图数据

本章涵盖

• 使用生成式人工智能创建新的训练和测试示例

• 识别你当前对话式人工智能数据中的差距

• 使用 LLMs 在对话式人工智能中构建新的意图

对话式人工智能用户在人工智能无法理解他们时感到沮丧——尤其是如果这种情况发生多次的话！这适用于所有对话式人工智能类型，包括问答机器人、面向流程的机器人和路由代理。我们已经看到了多种提高人工智能理解能力的策略。第一种策略——手动改进意图训练（第五章）——赋予人类构建者完全控制权，但这需要时间和专业技能。第二种策略——检索增强生成（RAG，第六章）——赋予生成式人工智能更多的控制权，随着时间的推移减少人类构建者的角色。本章介绍了一种混合方法，其中生成式人工智能增强构建者。这适用于基于规则或基于生成式人工智能的系统。

将生成式人工智能作为人类构建者的“灵感之源”可以减少人类构建者的努力和时间，增加可用于数据科学活动的测试数据量，并让人类构建者拥有最终决定权，从而消除了大多数幻觉机会（即人工智能说出看似合理但实际上不正确的话）。

假设你正在构建一个对话式人工智能解决方案来帮助你的 IT 帮助台。从访谈中，你知道密码重置是人工智能需要支持的最频繁的任务。因此，人工智能需要对密码重置意图有深入的理解。

由于对话式人工智能解决方案是新的，你没有任何生产用户话语来训练。当你询问服务台用户通常如何开始对话时，你听到“嗯，他们通常会说一些关于‘忘记密码’或‘无法登录’的话。”你很合适地怀疑——当然，用户的词汇量比这要广——但你很难想象这个词汇量可能是什么。生成式人工智能可以帮助你想象。

让我们看看人类构建者和生成式人工智能如何成为合作伙伴。

7.1 开始

大型语言模型（LLMs）擅长执行许多技术任务，包括分类和问答。这些任务与对话式人工智能的核心任务相同。那么，我们为什么不直接使用生成式人工智能来完成我们的核心对话式人工智能任务呢？

LLMs 之所以具有可推广性，是因为它们在大量数据上进行了训练。这使得它们在许多任务上学习迅速，但也带来了一些成本。使用 LLM 作为对话式人工智能中的分类器的成本是什么？

• 货币成本——LLMs 的运行成本可能很高。

• 速度——由于 LLMs 考虑了数十亿个参数，它们可能会更慢（时间成本）。

• 声誉风险——LLMs 过于通用，可能会产生使你的机器人看起来很糟糕或让你面临法律风险的输出。

• 缺乏透明度和可解释性——大型语言模型（LLMs）通常是一个“黑盒”。

相比之下，对话式 AI 使用专为特定目的设计的科技。因为其分类器仅被训练执行当前任务，所以它成本更低，并且运行速度快，因为它考虑的参数更少。虽然这可能会降低准确性，但系统保证使用一组受控的响应。这些比较总结在表 7.1 中。

表 7.1 比较和对比传统自然语言处理（NLP）在对话式 AI 和生成式 AI 在分类任务上的差异

特征	传统 NLP	生成式 AI
模型	专为仅在一个任务上表现出色而定制：分类	适用于许多任务的通用模型
运行时速度	快速	慢速
运行时成本	低	高
准确性	主要准确（在少量数据上由你训练）	主要准确（在大量数据上预训练）
可扩展性	可管理多达 100 个意图；之后非常困难	通过 RAG 模式很好地泛化
可控性	严格受人类控制；需要大量测试	当给予完全控制时容易产生幻觉；自动检测幻觉很困难

我们可以使用混合方法来获得两种方法的最佳效果。

7.1.1 为什么这样做：优点和缺点

一个 LLM 可以大大减少人类构建者所花费的时间和精力。LLM 和人类最佳合作——作为合作伙伴。训练对话式 AI 分类器需要人力，但也需要数据，而这些数据可能很难收集。有时，这些数据只能在对话式 AI 投入生产后才能收集。即使在我们的熟悉例子中检测“忘记密码”问题，我们仍然不知道用户可能表达问题的所有方式。他们可能会使用“错误”的词语！

LLMs 在这些场景中特别有帮助：

• 自举—AI 存在“冷启动”问题。当你没有数据时如何训练？LLM 可以生成一组初始的训练数据。

• 扩展—当没有足够的数据来优化你的分类器精度时，使用 LLM 来填补现有数据的空白。这对于理解罕见但重要的意图（例如用户报告欺诈）特别有用。

• 鲁棒测试—LLMs 可以生成额外的测试数据，增加你对对话式 AI 鲁棒性的信心。（即使生成式 AI 创建答案，如 RAG，这也很有帮助。）

一个 LLM 可以帮助你运行许多实验，其中一些将生成可以直接由你的应用程序使用的输出，无论是作为训练数据还是测试数据。你和 LLM 也可以互相帮助。例如，LLM 可以提供用户可能使用的主题和变体。你可以选择你最喜欢的，并要求 LLM 通过更新提示指令或少量示例来扩展这些内容。

你与 LLM 的互动将是迭代和协作的。例如，你不太可能第一次就设计出正确的提示。LLM 可能无法正确理解任务，或者可能给你提供不太有帮助的内容。在获得理想结果之前，你可能会进行几轮实验。之后，你可以快速生成所有意图的建议，并提高你 AI 对用户理解的能力。

7.1.2 你需要什么

许多 LLM 可以帮助我们生成更多用于“忘记密码”意图的训练或测试数据。那么我们是不是只需要挑选一个并放手？并非如此。LLM 会帮助你，但你不应期望它完成所有工作。相反，你应该有一个起点，比如知道你解决方案中的哪些差距。你还需要选择一个适合你用例的 LLM。

使用 LLM 来增强你的对话 AI 的一个明显前提是能够访问 LLM。在选择 LLM 时，还有一些不那么明显的考虑因素：

• 条款和条件——一些 LLM 明确禁止你使用它们的 LLM 来“构建或改进另一个模型”。这个条款的目的是防止你构建一个具有竞争力的 LLM，但使用 LLM 来改进对话 AI 可能会被这样解读，而你愿意承担的法律风险可能各不相同。（请咨询你的法律部门——他们可能已经为你的公司选择了可用的 LLM。）

• 数据隐私——当你使用 LLM 时，它是否允许在未来保留你的数据并在其上进行训练？你对话 AI 中的数据可能对你公司来说是机密的。如果是这样，你不能随意将其与任何 LLM 共享。

• 能力——并非每个 LLM 都具备创意生成任务的能力。确保你选择一个能够遵循指令的模型。

• 开源或专有——对于许多用例，可解释性很重要。开源模型通常让你对模型的训练过程有更多的了解，例如模型的训练数据和源代码。专有模型通常不会公开这些信息，但通常使用起来更方便。这也可能影响你的道德和监管合规性。

• 延迟和响应时间——存在速度和准确性的权衡；较大的模型可能既更准确又运行得更慢。

在本章和本书的其余部分，我们将使用多个提示和模型来提供示例。这些示例将适用于你选择的模型（或模型）。请随意尝试其他模型，特别是那些在我们撰写本书时不可用的模型。

你还需要将一些领域知识带到 LLM（大型语言模型）中。这可以包括你用户向你的对话 AI 提出的问题的背景，你系统需要支持的目的，以及属于这些目的的表述。尽可能多地带来现实世界的数据。然后使用 LLM 来增强这些数据。

7.1.3 如何使用增强数据

一个大型语言模型（LLM）可以帮助你为你的聊天机器人生成额外的数据。在构建时使用 LLM 可以减少幻觉的风险和影响。这些选项包括向你的训练数据添加内容、向你的测试数据添加内容以及修改你现有的数据（例如，改变语法结构和同义词）。

最佳数据来源是来自生产系统真实用户的数据。我们认识到这引入了一个鸡生蛋的问题——如果你还没有投入生产，你可能没有任何数据。你的意图分类器需要用多样化的数据进行训练，以便它能理解多样化的数据。聊天机器人应该用它未训练过的数据进行测试。

当你没有任何训练数据时，你倾向于生成低变异性语句。你会在心中记住几个关键词，并“锚定”于它们。即使有几十个示例，低变异性语句也不传达很多信息。高变异性语句快速覆盖了大量内容，如表 7.2 所示，并且它们通常会使你的分类器更强。

表 7.2 比较低变异性与高变异性语句。高变异性语句增加了分类器的鲁棒性。

低变异性语句集	高变异性语句集

| • 我忘记了密码 • 忘记密码

• 忘记密码

• 帮助，我忘记了密码

| • 我无法登录 • 账户被锁定

• 忘记密码

|

尽管数量较少，高变异性语句仍然可以覆盖低变异性语句。单个语句“忘记密码”就足以预测所有四个低变异性语句的意图。反之则不成立，即使我们在低变异性集中添加几十个“忘记密码”的微小变化，情况也不会改变。“我无法登录”没有直接词汇重叠——低变异性集不包含它。

我们更喜欢一个小而高变异性训练数据集，它能覆盖大量低变异性测试语句。与其训练 100 个弱变异性，不如训练 10 个强变异性。这使得聊天机器人对生产中将要看到的多样化语句具有鲁棒性。这也减少了你意外不平衡训练集（导致理解薄弱）的机会。

我们可以在图 7.1 中可视化语句传达的信息。第一个图显示了表 7.2 中的低变异性语句。由于它们只传达两个单词，你可以认为这些语句紧密聚集在一起。第二个图显示了高变异性语句。由于没有词汇重叠，语句散布在整个网格上，但有很多空隙。第三个图显示了理想的测试集，其中网格覆盖范围广泛。第四个图显示了理想的训练集，在少量示例中覆盖最大变异性。测试数据集可以比训练数据集大得多。我们希望测试集具有变异性，但如果我们有近似重复的数据集也行。

在本章中，我们将首先展示如何使用生成式 AI 来创建高变异性的话语。然后，我们将通过许多细微的变化来扩展这些话语。到本章结束时，你将看到如何生成与第三和第四个图表匹配的话语。

图 7.1 从不同种类的话语集中可视化覆盖范围。我们的理想训练数据集是第 4 集，它覆盖了少量话语中的大量变化。第 3 集是理想的测试数据。

练习

1. 想象你正在为一家典型的零售店构建聊天机器人。为#store_location意图创建十个话语，当用户询问“你的商店在哪里？”时使用。记录这需要多少时间。

2. 创建十个更多的话语，不使用“where”、“store”、“located”或“location”这些词。（再次计时。）这些话语是否更有变化？

3. 为#store_hours意图重复前两个练习。首先使用你想要的任何词语，然后限制自己不要使用“when”、“time”和“hours”。

7.2 增强现有意图的强度

我们将开始我们的练习，知道我们需要改进哪个意图：“忘记密码”意图。我们需要足够的训练数据，以便对话式 AI 能够检测到这个意图。记住，我们的支持人员不知道用户可能表达这个问题的所有方式。他们说：“用户通常会提到‘忘记密码’或‘无法登录’。”这不足以训练聊天机器人以稳健的“忘记密码”意图。

我们将使用 LLM 作为我们的合作伙伴。首先，LLM 将帮助我们生成上下文同义词，以便我们看到广泛的词汇。接下来，LLM 将使用这些词汇生成完整的话语。然后，我们将让 LLM 生成不同的语法变体，例如疑问句与陈述句以及过去时与现在时。我们还将让 LLM 将构建一个意图（“忘记密码”）时学到的经验教训应用到构建下一个意图（“寻找商店”）中。

我们将从最简单的步骤开始——寻找同义词。

我可以使用不同的 LLM 吗？

是的！在这本书中，我们将使用多个模型。生成式 AI 领域正在快速发展，本书写作期间使用的模型可能在本书出版或你阅读它的时候被更好的模型所取代。我们将展示的原则比我们将使用的具体模型更重要。

7.2.1 用同义词发挥创意

第一步是设计提示。一个好的提示确保你的 LLM 理解其任务，在这个例子中，第一个任务是生成广泛的同义词。提示工程的过程需要实验的迭代过程。

我们的主题专家建议话语中经常包括“忘记密码”。提高你的聊天机器人鲁棒性的方法之一是确保你覆盖了名词短语和动词短语。让我们让一个 LLM 生成一些可能的名词短语同义词。

我该如何设置和运行我的 LLM？

设置 LLM 环境有多种选择。您可以在自己的机器上本地运行 LLM，使用像 Ollama 这样的工具，或者在一个商业托管平台上运行它们。由于我们熟悉它，我们使用了 IBM 的 watsonx.ai 平台上的 Prompt Lab，但本章中没有任何内容是平台依赖的。使用您喜欢的平台。

在这个练习中，我们将使用 falcon-40b-8lang-instruct 模型 (huggingface.co/tiiuae/falcon-40b) 并使用贪婪解码。贪婪解码指示模型在每一步生成下一个最可能的词，并且每次都产生相同的输出。

虽然我们希望最终得到完整的句子片段，但通过将任务分解成几个部分，我们得到了更好的结果。用户陈述通常是句子或片段，主要由名词和动词短语组成。让我们从一个简单的提示开始——只是要求同义词——以获取我们的名词。

列表 7.1 基于上下文生成名词的同义词

Generate a list of nouns.  #1
The nouns should be synonyms of 'password'. 

List of 5 nouns  #2
credentials, secret, key, code, accesscode  #3

1 简单指令

2 对 LLM 的提示性提示

3 LLM 输出

在前面的列表中，我们将 LLM 作为通用同义词典使用。虽然输出名词是“密码”的同义词，但它们不是在登录上下文中经常使用的同义词。我们需要向 LLM 提供更多上下文以获得更好的结果。

这次让我们告诉 LLM 我们为什么要求同义词以及我们想要哪种同义词。以下列表显示了改进的提示和结果。

列表 7.2 基于上下文生成名词的同义词

You are a consumer contacting an online retailer via their   #1
chat service. 
Generate a numbered list of nouns a consumer might use while  #2
describing their inability to log in to your service in the   #2
phrase "I forgot my password".   #2
The nouns should be synonyms of 'password'.  #2

List of 5 nouns  #3
1\. "account information" 2\. "credentials" 3\. "login information"  #4
4\. "authentication" 5\. "identifier"  #4

1 给 LLM 的背景信息

2 将任务与忘记密码联系起来的详细说明

3 LLM 提示

4 LLM 回复

这些同义词听起来更熟悉。接下来，让我们创建上下文动词同义词。

列表 7.3 基于上下文生成动词的同义词

You are a consumer contacting an online retailer via 
their chat service. 

Generate a numbered list of verbs a consumer might  #1
use while describing their inability to log in to   #1
your service in the phrase "I forgot my password".   #1
The verbs should be synonyms of 'forgot'.  #1

List of 5 verbs  #2
1\. Forgot 2\. Lost 3\. Mislaid 4\. Misplaced 5\. Err  #3

1 更新动词而非名词的指令

2 更新动词而非名词的提示

3 LLM 输出

虽然最后一个动词在这个上下文中有点奇怪，但结果还不错。另一个限制是所有生成的动词都是过去时。鉴于我们的例子也是过去时，这是合适的，但我们希望我们的 LLM 为我们生成更多样化的内容。让我们尝试从 动词 扩展到 动词短语。

列表 7.4 基于上下文生成动词短语的同义词

You are a consumer contacting an online retailer via their chat service. 

Generate a numbered list of verb phrases a consumer   #1
Might use while describing their inability to log in   #1
to your service in the phrase "I forgot my password".   #1
The verb phrases should be synonymous with 'forgot'.  #1
#1
List of 5 verb phrases  #1
1\. I forgot my password.  #2
2\. I lost my password.   #2
3\. I misremembered my password.  #2
4\. I misplaced my password.  #2
5\. I cannot remember my password.  #2

1 更新“动词短语”的指令和提示

2 LLM 输出

3 LLM 输出

LLM 给我们提供了完整的句子（哎呀！），但现在我们得到了一些现在时的陈述（“不能记得”）以及其他过去时的陈述。我们在进步！仅仅几分钟的提示，我们就让 LLM 给我们提供了很多值得思考的变体。以前，我们可能认为我们的聊天机器人只需查找“忘记”和“密码”。现在我们有了一打其他有用的词可以考虑，当我们测试机器人时。

让我们再实验一下。这次我们将通过转向采样解码和增加温度来提高模型的创造性。我们还将通过要求“10 个同义词”而不是“5 个名词”来修改提示。列表 7.5 显示了名词，列表 7.6 显示了动词短语。

NOTE　使用贪婪解码时，LLM 每次都会生成相同的结果。采样解码生成非确定性输出。如果你尝试这些提示，你可能会得到不同的结果。这是可以的！我们只是在用 LLM 激发我们的创造力。

列表 7.5 使用增加创造性的设置生成名词的同义词

You are a consumer contacting an online retailer via their chat service.

Generate a numbered list of synonyms a consumer might  #1
use for 'password' while they described a problem like   #1
"I forgot my password".  #1
#1
List of 10 synonyms for 'password'  #1
1\. "Secret" 2\. "Personal Identification Number" 3\. "PIN" #2
4\. "Access Code" 5\. "Log-in Information" 6\. "Log-in Data"  #2
7\. "Account Information" 8\. "Account Data"   #2
9\. "Identification Number" 10\. "Security Code"  #2

1 更新后的提示和引导

2 LLM 输出

太棒了！这是一个很棒的名词列表。您的系统可能不会使用所有这些，但这是一个全面的测试列表。

让我们接下来尝试动词。

列表 7.6 使用增加创造性的设置生成动词短语的同义词

You are a consumer contacting an online retailer via their chat service.

Generate a numbered list of synonyms a consumer might  #1
use for 'forgot' while they described a problem like   #1
"I forgot my password". #1
#1
List of 10 synonyms for 'forgot'  #1
1\. Forgot 2\. Did not remember 3\. Didn’t know 4\. Unknown  #2
5\. Not applicable 6\. Unable to access 7\. Couldn’t recall  #2
8\. Didn’t memorise 9\. OMG Failed to remember  #2
10\. Unable to login  #2

1 更新后的指令和引导

2 LLM 输出

这是一个更具创造性的同义词列表。虽然这个列表中有些奇怪之处（“未知”，“不适用”），但也有一些不错的创意火花：

• 稍微错误的动词——“没有记住”很奇怪，但它让你想到“不能记住”。

• 错误的时态——“不知道”让你考虑“不知道”。

• 情感——“OMG”让你意识到表达可能包括挫败感。

我们仅用几分钟的努力就生成了与我们的领域相关的同义词，但我们仍然只有部分内容。我们从一个表达“我忘记了我的密码”开始，现在可以插入新的名词和动词短语，但我们仍然被困在简单的主语-谓语-宾语结构中。我们的用户肯定会使用更多样化的语法。我们不希望聊天机器人只依赖于一种语法形式。我们希望它能够对更多样化的表达有弹性。让我们使用 LLM 来生成更多的语法变化。

7.2.2 生成新的语法变化

而不是要求 LLM 生成单词或单词对，让我们尝试让它生成完整的表达。我们需要设计一个提示来引入单词变化，但我们不想让模型过于偏向“我忘记了我的密码”。我们将使用一个类似的提示来设定上下文，但不是直接包含短语“我忘记了我的密码”，而是描述用户的问题（他们无法登录）。

我们第一次尝试的示例如下所示。

列表 7.7 生成完整的表达

You are a consumer contacting an online retailer via their chat service. 

Generate a numbered list of example utterances a   #1
consumer might start conversation with if they couldn't   #1
log in.  Use a variety of nouns and verbs related to    #1
logging in, passwords, and accounts.  #1
#1
List of 10 utterances  #1
1\. I can't log in          #2
2\. My password isn't working  #2
3\. I don't know my password  #2
4\. I forgot my username  #2
5\. I forgot my password  #2
6\. My account is locked  #2
7\. I didn't get my password reset email # #2
8\. I need help with my account  #2
9\. Can you help me log in?  #2
10\. I tried resetting my password but it didn't work  #2

1 更新后的指令和引导

2 LLM 输出

我们开始获得更多样化了。这个表达列表有几个我们还没有看到的想法（比如“密码重置电子邮件”）。更好的是，我们在句子结构上得到了更多的变化。输出列表有以下语法变化：

• 主语-谓语-宾语陈述（主动语态）——我忘记了我的密码。

• 被动语态陈述——我的账户被锁定。

• 介词短语——我需要帮助我的账户。

• 问题——你能帮我登录吗？

• 限定词——我尝试重置密码但不起作用。

我们样本话语的多样性正在提高。生成的话语可用于我们的训练或测试集，但仍存在差距。例如，所有这些话语都是完美的句子。那么，对于那些如此忙碌（或沮丧）以至于只给我们几个词的用户呢？LLM 能生成有用的句子片段吗？以下列表探讨了这一想法。

列表 7.8 生成句子片段话语

You are a consumer contacting an online retailer via their chat service. 

Generate a numbered list of example fragments a  #1
Consumer might start conversation with if they  #1
couldn't log in.  Use a variety of nouns and verbs  #1
related to logging in, passwords, and accounts. Use  #1
sentence fragments only.  #1
#1
List of 10 sentence fragments   #1
1\.  Forgot password  #2
2\.  Unable to login  #3
3\.  Account locked out  #3
4\.  Need help resetting password  #3
5\.  Can't remember email address  #3
6\.  Email is not working  #3
7\.  Unable to change password  #3
8\.  Unable to access account #3
9\.  Unable to create new account  #3
10\. Unable to delete old account  #3

1 更新指令以生成片段。提示不变。

2 在提示下方的一个单样本示例

3 LLM 输出

在我们之前的提示中，我们无法生成句子片段。这次，我们给了 LLM 额外的帮助。除了我们对提示的常规更新（将“话语”替换为“片段”）之外，我们还给了 LLM 一个额外的提示。我们提供了第一个示例片段“忘记密码。”这被称为单样本学习，因为我们给了 LLM 我们想要的例子，这有助于 LLM 学习如何处理我们的请求。

零样本？单样本？少样本？

“零样本”、“单样本”和“少样本”这些术语指的是提示中给出的示例数量（样本）。零样本提示不提供任何示例。单样本提示提供一个示例，而少样本提示提供几个示例。

对于训练数据生成，单样本学习是一种获取所需输出的绝佳方式。每当你在让 LLM 遵循你的指令时遇到困难，考虑提供一个好的例子，而不仅仅是微调指令。在撰写本章时，我们尝试了比书中包含的更多的提示，直到我们使用单样本学习，我们都没有得到句子片段。

此外，你可以使用单样本学习将构建一个意图时学到的经验应用到另一个意图上。在下一个列表中，我们使用“商店位置”意图的示例来生成“密码重置”意图的示例。

列表 7.9 使用单样本学习生成多种语法结构的示例

You are a consumer contacting an online retailer via  #1
their chat service. #1

Generate phrases a user might use to find out where #2
stores are located. Create phrases for each of the  #2
following grammatical types. #2
Direct Question: Where are you located?  #2
Indirect Question: Can you tell me how to find your  #2
stores?  #2
Fragment: Store location  #2
Command: Give me driving directions  #2

Generate phrases a user might use when they need to  #3
reset their password. #3
Create phrases for each of the following grammatical #3
types. #3
Direct Question:  I forgot my password.  #4
Indirect Question:  How can I reset my password?  #4
Fragment:  Password reset #4
Command:  Send me a password reset link  #4

1 LLM 的标准背景，与过去几个示例保持不变

2 单样本示例包括指令和期望的输出

3 对 LLM 的指令，补充了提示“直接问题：”

4 LLM 输出（在提示“直接问题：”之后开始）

通过一个提示，我们能够得到我们想要的每种语法结构的示例（LLM 在“直接问题”上犯了一个错误，但输出仍然有用）。

这是一种生成话语的额外技巧。而不是使用详细的指令，提供几个示例，并要求 LLM 生成更多。我们将使用不同的提示格式和不同的模型——granite-13b-instruct-v2 (mng.bz/DMlR)——我们将使用采样解码以增加创造性和非确定性结果。以下列表显示了提示和第一个输出。

列表 7.10 使用创意提示生成 Granite 模型的示例

<|instruction|>  #1
Here are actual utterances submitted by customers to an  #2
automated help desk. Your task is to create new   #2
examples from people having problems with their   #2
password and login ability.  #2

<|example|>  #3
I can't log in

<|example|>
My login information isn't working

<|example|>
Forgot password

<|example|>
Help me get into my account

<|example|>  #4
Hi there, I can't seem to login to my account  #5

1 指示模型指令的标记

2 实际指令

3 示例的开始

4 输出提示

5 LLM 输出

由于我们使用的是非确定性设置，模型输出每次都不同。以下是下一个五个执行相同提示的输出：

• “你能帮我恢复我的密码吗”

• “我被锁在我的账户外面”

• “我记不起用户名或密码”

• “希望你能帮我，我刚刚重置了我的密码但不起作用”

• “我已经连续 5 次登录失败”

我们没有指定我们想要的精确变化，但我们仍然得到了一些有趣的变化。我们看到了新的动词（“恢复”）和概念（“连续 5 次”）。这突出了实验不同 LLM、不同提示和不同参数设置的价值。生成训练数据需要创造力。不要依赖一个或两个实验来完成工作——你可以和生成式 AI 一起创造性地工作。

7.2.3 从 LLM 输出构建强大的意图

让我们回顾一下迄今为止的实验。我们已生成作为上下文同义词的名词和动词（而不仅仅是通用同义词）。我们已生成具有相似结构的整个话语，然后使用 LLM 生成具有不同语法结构的话语。我们使用了多个模型、提示和参数设置。生成式 AI 是一个伟大的合作伙伴！

从这些实验中，我们有很多可能性来构建一个训练集。让我们选择 10 个话语，涵盖我们之前生成的变化。对于一些话语，我们将使用 LLM 的逐字输出。对于其他话语，我们将替换一些变化。例如，生成的话语中“密码”很多——我们可以用“登录信息”或“账户信息”来替换。话语中也很多“忘记”，所以我们将用“记不起”来替换。以下列表显示了话语的一个可能选择。

列表 7.11 基于 LLM 建议的十个精选话语

1\. I can't log in
2\. My login information isn't working
3\. Forgot password
4\. Account locked out
5\. I can't remember my account information
6\. My account is locked
7\. I didn't get my password reset email
8\. Need help with resetting account
9\. Can you help me log in?
10\. I tried to reset my password but it didn't work

自从最初建议“大多数请求包括‘忘记’和‘密码’”以来，我们已经走了很长的路！如果我们将这些话语用于我们的训练集，我们将比坚持基于关键词的建议有更稳健的聊天机器人理解。

我们在多个提示会话中成功生成想法。这引发了一个问题，我们能否在一个提示中完成所有操作？我们预计需要我们迄今为止的所有技巧：为 LLM 提供上下文，一个清晰的指令，以及一个一次性示例。让我们尝试使用“忘记密码”意图的最佳示例来训练一个“商店定位器”意图。以下列表展示了使用 falcon-40b-8lang-instruct 模型和贪婪解码再次进行此操作。

列表 7.12 使用一次性学习将一个意图的教训复制到另一个意图

You are a consumer contacting an online retailer via   #1
their chat service.  #1

Generate a numbered list of example utterances a   #2
consumer might start conversation with if they couldn't  #2
log in. Use a variety of nouns and verbs related to   #2
logging in, passwords, and accounts. Use a variety of  #2
grammar structures in the utterances.  #2
#2
List of 10 utterances  #2
1\. I can't log in  #3
2\. My login information isn't working  #3
3\. Forgot password  #3
4\. Account locked out  #3
5\. I can’t remember my account information  #3
6\. My account is locked  #3
7\. I didn't get my password reset email  #3
8\. Need help with resetting account  #3
9\. Can you help me log in?  #3
10\. I tried to reset my password but it didn't work  #3

Generate a numbered list of example utterances a  #4
consumer might start conversation with if they need to   #4
find your store. Use a variety of nouns and verbs  #4
related to finding, location, and directions. Use a   #4
variety of grammar structures in the utterances.  #4
#4
List of 10 utterances  #4
1\. Where is your store located?  #5
2\. How do I find your store?  #5
3\. What direction is your store from here?  #5
4\. Which exit should I take to get to your store?  #5
5\. Is your store north or south of here?  #5
6\. Your store is on what street?  #5
7\. Where is your store exactly?  #5
8\. How far is your store from here?  #5
9\. How long will it take me to get to your store?  #5
10\. What city is your store in?  #5

1 LLM 的标准背景

2 一次性示例（密码重置）的指令和提示

3 一次性示例

4 目标（商店定位器）的指令和提示

5 LLM 输出

6 LLM 输出

还不错！这是我们新意图的合理起点。这个输出有几个积极方面：

• 动词多样性——除了“是”之外，没有重复的动词。

• 概念多样性——通过“位置”和“方向”，示例涵盖了绝对和相对概念。它们还涵盖了时间和空间（“多长时间”，“多远”）。

• 粒度多样性——表述范围从“哪个城市”到“哪个街道”以及“从这里”。

然而，这些表述也有一些局限性：

• 语法结构——这些表述都是问题。没有命令或片段。

• 名词多样性——每个例子都使用“store”。

• 明显遗漏——没有 GPS 我就迷失了。令人惊讶的是，表述没有明确包含像“你的地址是什么”或“驾驶方向”这样的内容。

这个任务太难，无法在单个提示中完成。我们向 LLM 提出了我们想要的所有内容，甚至给出了例子。LLM 能够完成我们许多请求，但也忽略了或未能完成我们的一些请求。事情并不像完美地完成一个意图然后让 LLM 复制到所有其他意图那样简单。我们的任务中有太多的指令和变量，对于当前的 LLM 来说，在一次尝试中就完全正确是非常困难的。这可能会在未来改变。

这就是为什么我们建议将 LLM 用作合作伙伴，而不是自己或完全使用 LLM 来做所有事情。您不能将您的思考外包给 LLM，但您可以让 LLM 非常快速地为您运行实验。生成同义词和语法多样性听起来很简单，但您可能无法像 LLM 那样快速和完整地完成。让 LLM 生成很多想法，然后挑选最好的。

REMEMBER LLM 无法为您思考，但它可以为您提供一个非常好的“初稿”。

表 7.3 总结了使用 LLM 生成训练和测试数据的“做”和“不要”。

表 7.3 使用 LLM 生成训练和测试数据的“做”和“不要”

做	不要

| • 将 LLM 用作合作伙伴或创意助手。您仍然驱动这个过程。 • 设置上下文指导和专注的指令 |

• 使用示例和单次学习来引导 LLM

• 尝试使用多个提示

• 使用 LLM 输出增强从用户收集的数据

| • 不审查或精炼 LLM 输出就接受它 • 期望 LLM 知道您想要什么 |

• 在单个提示中执行太多任务

• 将机密数据输入到保留的 LLM 平台，该平台“为了未来的训练目的”保留您的数据

• 假设 LLM 输出完全代表了用户数据

|

当你有一个明确的问题但没有代表性的用户表述时，LLM 非常适合生成表述训练数据。虽然我们总是更喜欢使用来自生产系统的实际用户表述，但我们并不总是享有这种奢侈。LLM 生成的数据帮助我们填补了空白。它们庞大的训练集可能包含一些来自你领域（如客户服务）的数据，但可能不包括你所有的需求。它们看到了很多“密码重置”的表述，但可能没有包含你应用程序的名称。在无训练数据、从主题专家那里编造的训练数据和 LLM 生成的训练数据之间进行选择时，LLM 生成的选项是最好的选择。

7.2.4 使用模板创建更多示例

在上一节中，我们通过结合 LLM 的多个不同输出并使用它们来生成新的表述，从而生成了一系列多样化的表述。图 7.2 展示了从列表 7.7 中突变完整表述（使用列表 7.1 到 7.6 中看到的同义词）的示例。

图 7.2 从初始 LLM 输出生成额外的示例。LLM 生成了“我的密码不起作用”，但我们现在知道相关的表述是“我的登录信息不起作用”。

TIP 创建模板中的示例是一项程序性任务，而不是特定于生成式 AI 的任务。混合和匹配多种风格可以产生最佳结果。

使用模板在 LLM 输出仅包含一个动词或名词时特别有帮助。我们能够通过手动更改引入我们的表述集合的多样性，但我们可以通过将 LLM 输出视为模板来将这种做法推向极致。从基本的表述“我忘记了密码”开始，我们随后探索了“忘记”和“密码”的上下文同义词。图 7.3 将这个表述转换成了“我<动词短语>我的<名词短语>”的模板，这可以生成更多的表述。

图 7.3 将“我忘记了密码”转换成允许我们在上下文中替换动词和名词的模板。这个模板的一个选项是“我丢失了我的凭证”。

这个模板由于有六个动词选择和六个名词选择（6×6=36），总共生成了 36 个表述。这是一大批数据，但它非常不平衡——它全部使用了完全相同的语法结构。更糟糕的是，一些表述可能永远不会被用户说出。这种方法不适合生成训练数据，因为它过分强调了单一模式。这些模板化的表述将隐藏其他更多样化的表述的影响，如“你能帮我登录吗？”“我尝试重置密码，但不起作用”，以及“账户被锁定”。

如果你认识到不平衡，模板语句对你的测试集是有用的。测试你的对话 AI 的所有 36 个语句作为理智测试并没有什么不妥。只是不要限制自己只测试一个模板并假设意图已经很好地训练过。

模板方法可以用来生成测试数据，这有助于确保聊天机器人能够在面对无关信息的情况下区分两个意图。除了我们的“忘记密码”模板外，假设我们还有一个“商店位置”模板，它使用动词“需要”、“忘记”和“想要”，以及名词“地址”、“位置”和“驾驶方向”。商店位置模板类似于图 7.3，但它使用“I your 。”我们还将假设一些用户会问候机器人（“Hi”，“hello”，“good day”）或泛地问询帮助（“can you help”，“please assist”）。这些泛化的添加并没有向用户语句中添加任何区分信息。它们会以某种方式影响聊天机器人吗？图 7.4 展示了我们如何设置测试。

图 7.4 使用常见模板来查看问候语和结束语是否会影响聊天机器人的理解。一个可能的语句是“Hello I lost my credentials please assist。”

每个意图中都有三个动词变化和三个名词变化，为每个意图提供了九种可能性（3 × 3 = 9）。不考虑问候语，我们可能已经进行了 18 次测试（每个意图 9 次）。在这个测试中，我们增加了三种问候语变化和两种结束语变化，使我们能够将测试规模扩大六倍。108（18 × 6 = 108）个语句将包括“Hi！我忘记了我的密码。你能帮忙吗？”和“Good day。我需要你的地址。请协助。”以及 106 种更多变化。这些都可以包含在测试集中。

理论上，理论与实践之间没有区别——在实践中，有区别。Yogi Berra

我们不期望添加问候语和结束语变化会影响分类，但我们可以验证这一点。如果你的训练数据严重不平衡，聊天机器人可能会受到这些额外单词的影响。因此，运行这类测试可以作为另一种理智测试，除了第五章中展示的方法。

练习

1. 使用生成式 AI 为“商店位置”意图创建示例。你能生成多少个名词、动词和语法结构？跟踪你在这项练习上花费的时间：

   • 使用仅包含指令的提示。这是一个零次示例的提示。

   • 使用包含示例的提示。这是一个单次或少量示例的提示。

   • 模型在更短的时间内生成更多样化的语句，比您手动创建语句时要多吗？

2. 为你正在构建的聊天机器人中不太理解的意图重复之前的练习（或使用）。如果可能，通过这些新的语句之一增加机器人的训练或测试数据集，并测量准确性的变化。

7.3 更加创新

第五章展示了评估和改进你的训练和测试数据的坚实基础数据科学原则。这些原则为你提供了指标，这些指标证明了你的聊天机器人理解并量化了你试图改进的效果。这些稳健的原则需要时间来实施。本节将展示在深入研究统计方法之前，如何使用 LLM 的几种创意方法。这些基于 LLM 的技术并不取代统计方法，但它们可以给你一个快速直观的认识。

7.3.1 思考更多意图

LLM 可以帮助你思考系统可能需要处理的新意图。虽然我们更喜欢从现实世界的数据开始工作，例如支持票务的积压，但一点头脑风暴并不会有害。如果你正在启动全新的支持流程，你可能没有任何数据可以工作，需要启动。以下列表演示了一个意图头脑风暴过程。

列表 7.13 思考新意图

You are a consumer contacting an online retailer via   #1
their chat service.  #1

Generate a numbered list of example problems you might  #2
have causing you to contact the retailer's chatbot.  #2
#2
List of 5 problems:  #2
1\. I want to buy something but I can't find it on your website  #3
2\. The price has changed  #3
3\. My order hasn't arrived  #3
4\. I need help with my account  #3
5\. I want to return something  #3

1 LLM 的标准背景——仍然没有改变

2 指令和提示

3 LLM 输出

这看起来是一个很好的开始。我们有产品搜索、价格争议、订单跟踪、登录问题和退货。这些似乎都值得扩展到你的对话 AI 中的意图和流程中。

7.3.2 检查混淆

我们还可以看看 LLM 是否同意我们创建的意图。我们可以选择我们已选的训练语句，并要求 LLM 将它们分类到意图中。让我们看看如果我们从“忘记密码”意图中移除意图名称会发生什么。

列表 7.14 LLM 预测的意图（“忘记密码”）与我们的一致吗？

Given a list of utterances, predict the intent   #1
classification they belong to. #1

List of utterances  #2
1\. I can't log in  #2
2\. My login information isn't working  #2
3\. Forgot password #2
4\. Account locked out  #2
5\. I can’t remember my account information  #2
6\. My account is locked  #2
7\. I didn't get my password reset email  #2
8\. Need help with resetting account  #2
9\. Can you help me log in?  #2
10\. I tried to reset my password but it didn't work  #2

Intent Classification:  #3
- "I can't log in" -> "Login" #4
- "My login information isn't working" -> "Login" #4
- "Forgot password" -> "Password Reset"  #4
- "Account locked out" -> "Login" #4
- "I can’t remember my account information" ->  #4
 "Login" #4
- "My account is locked" -> "Login"  #4
- "I didn't get my password reset email" ->  #4
"Password Reset"  #4
- "Need help with resetting account" -> "Password Reset"  #4
- "Can you help me log in?" -> "Login"  #4
- "I tried to reset my password but it didn't work" ->  #4
 "Password Reset"  #4

1 对 LLM 的指令

2 指令所属的输入

3 提示

4 LLM 输出

LLM 建议了两个意图，而我们只使用了其中一个。意图“登录”和“密码重置”与我们的原始“忘记密码”标签一致。LLM 推导出的意图感觉过于狭窄，尤其是由于这两个意图很可能有相同的答案。

LLM 输出格式并不总是一致的

在列表 7.14 中，LLM“发明”了一个带有连字符列表条目和从话语到意图的箭头的输出模式。由于我们只是从视觉上审查结果，这可以接受，但给 LLM 的额外指令可能有所帮助（例如，“以项目符号列表形式回答”）。我们还可以用一个一次性示例来展示我们想要的格式。

这个测试不如第五章中展示的其他技术稳健，但它可以用作对训练数据的快速合理性测试。如果 LLM 在你的训练数据中找不到任何连贯性，你可能存在问题。

LLM 和人类构建者可以很好地协同工作。图 7.5 总结了 LLM 可以帮助你改变你的对话 AI 以改善其理解用户能力的方式。

图 7.5 LLM 以多种方式增强人类构建者。

练习

1. 以您正在构建或使用的聊天机器人为例。描述其目的。使用该描述和创意 LLM 提示生成机器人将解决的示例问题。使用采样解码，多次运行提示以获得多个想法。这些想法与机器人处理的意图或流程一致吗？

2. 以您正在构建的聊天机器人为例。从测试数据中提取一个子集的语句。要求 LLM 预测它们所属的意图或流程。LLM 的预测与您的机器人实现方式一致吗？

摘要

• LLMs 是出色的合作伙伴，它们增强了人类构建者。人类和 LLMs 在一起会更好。

• 尝试不同的模型、提示和参数以从 LLMs 中获得最佳输出。持续迭代！不要期望你的第一次尝试就完美无缺。

• 不要只是向 LLM 下达指令。通过一次性或少量提示提供示例。

• 当您在数据中识别到差距时，您可以要求 LLM 帮助您填补。

• LLM 的输出可以直接用于您的训练数据，或者您可以先手动对其进行精炼。

• 使用贪婪解码以每次获得相同的输出。使用采样解码以获得具有额外创造性的随机响应。

第三部分模式：AI 过于复杂

复杂的聊天机器人给构建者和用户都带来了痛苦。复杂的流程对构建者来说难以维护，对用户来说难以导航。复杂性降低了用户成功完成流程的可能性，从而抵消了 AI 技术的价值主张。

没有人一开始就打算构建一个复杂的解决方案。每个人都希望得到简单的东西。但随着新功能的添加和新问题的考虑，突然之间，复杂性可能就会从天而降！本书的这一部分展示了如何驯服复杂性。

第八章展示了几个示例对话流程，并展示了如何通过简化用户完成流程的过程来从它们中去除复杂性。第九章通过使用流程中所有可用的上下文，个性化流程流程并适应它们的交付渠道来降低复杂性。第十章使用大型语言模型（LLMs）在构建时间和运行时间都降低了聊天机器人的复杂性。

第八章：简化复杂流程

本章涵盖

• 复杂性对最终用户的影响

• 复杂性对业务和支持团队的影响

• 如何权衡对话感觉与复杂实现

• 如何简化用户的旅程

不必要的复杂性对聊天机器人用户和构建者来说都是痛苦的，它往往会导致不良的商业结果或部署时间表的延误。构建一个感觉简单自然的对话需要深思熟虑的设计和对用户情况的同理心。作为这些解决方案的设计师和构建者，我们的目标是创造一种体验，帮助用户以最少的麻烦或困难达到他们的目标。为什么我们应该如此迁就？因为我们需要用户采用或接受解决方案，以证明维护技术的成本是合理的。

用户会将“自然”的对话体验与“简单”或“易于使用”联系起来。易于使用的界面往往会导致最成功的成果。相反，没有充分考虑用户视角的体验往往感觉令人困惑、不自然，可能过于复杂。这可能导致用户升级问题、放弃对话或无法达到最佳结果。

在本章中，我们将从用户和业务的角度讨论复杂性。有时在为用户降低复杂性时，不可避免地会涉及一些权衡。我们将讨论在尝试解决用户痛点时可能遇到的权衡，以及如何优先考虑或实施次优替代方案。

8.1 复杂性的痛苦

复杂性是一把双刃剑：它可以为以任务为导向的对话增加摩擦或失败点，但没有它，我们通常无法完成更有用的交易。简单的 FAQ 风格机器人很少复杂，但它们在有用性方面可能有限。需要完成任务的用户通常需要一个能够做更多事情（或代表他们）的机器人——而不仅仅是告诉他们如何做某事。以一个需要知道他们支票账户余额的用户为例。一个 FAQ 机器人可能只是告诉用户如何检查账户余额，但用户的目的是尚未满足。一个自助服务机器人会提供用户的实际账户余额，这确实满足了他们的目标。

当然，这两种解决方案之间的复杂性差异非常明显。一个 FAQ 机器人只需要识别用户的目标并生成相关答案。一个以流程为导向的机器人通常需要与外部后端系统集成。它可能需要验证用户的身份，并能够从一个或多个来源访问受保护的信息。

如您所见，在提供能够完成虚拟助手提供的更有用任务的解决方案时，往往存在固有的复杂性。虚拟代理必须服务于两个主人：最终用户和创建并维护解决方案的企业或组织。决定谁将承担或影响复杂性的负担是一个平衡行为。

8.1.1 复杂性对最终用户的影响

复杂的交易性对话可能会让用户感到令人生畏或困惑。设计不佳的流程会给用户体验带来相应的摩擦。不必要的复杂性的一个主要缺点是它引入了额外的潜在失败点。对话中的失败要么阻止用户继续前进，要么使他们不得不重试。结果，用户通常会要求与客服代表交谈或简单地放弃聊天。

我们在与一家保险公司合作时看到了不必要的复杂性的影响。他们为医疗服务提供者提供了一个语音解决方案。提供者可以通过电话获取提交的索赔的状态和付款详情，但索赔搜索流程的成功率只有 40%。该流程在搜索索赔之前需要用户提供五条信息。图 8.1 展示了索赔搜索的步骤。

图 8.1 交付索赔状态的流程涉及七个步骤。在解决方案执行搜索和（如果搜索成功）交付索赔状态之前，呼叫者必须提供五条信息。

对于用户来说，查找过程有点令人疲惫，需要在多个步骤中输入多个长串的数字。以下列表展示了从用户角度的体验。

列表 8.1 索赔搜索流程，其中呼叫者必须提供五条信息

CALLER: I want to check the status of a claim.
VIRTUAL ASSISTANT: I can help you check the status of a claim. First, please tell me your provider ID.
CALLER: <gives provider number> 
VIRTUAL ASSISTANT: Thank you. Next, please give me the Member ID.
CALLER: <gives member number> 
VIRTUAL ASSISTANT: Got it. And what is the claim date?
CALLER: <gives claim date> 
VIRTUAL ASSISTANT: Now, please tell me the claim number.
CALLER: <gives claim number> 
VIRTUAL ASSISTANT: One moment, while I look up the claim.
VIRTUAL ASSISTANT: I found your claim.

我们寻找减少该流程复杂性的方法。我们的研究显示，大多数呼叫者对于任何特定的成员和日期组合只有一条索赔。换句话说，仅基于该信息进行搜索通常会产生单一结果。这意味着对于大多数用户来说，收集索赔编号是不必要的。

图 8.2 显示了更新的索赔搜索流程，它收集执行索赔搜索所需的最少信息。如果只找到一条索赔，则立即交付索赔状态。如果逻辑检测到多条索赔，机器人将收集用户提供的索赔编号来消除歧义。

图 8.2 更新后的索赔状态交付流程，对于大多数呼叫者来说，只需要四条信息。只有在必要时才会要求呼叫者提供第五条信息。

通过消除只有一条索赔的账户的索赔编号收集步骤，我们使用户体验变得更简单。这反过来又提高了任务完成率，并将索赔编号搜索失败的发生率减半。以下列表展示了改进后的体验。

列表 8.2 在改进的体验中，大多数呼叫者只需要四条信息

CALLER: I want to check the status of a claim.
VIRTUAL ASSISTANT: I can help you check the status of a claim. First, please tell me your provider ID.
CALLER: <gives provider number> 
VIRTUAL ASSISTANT: Thank you. Next, please give me the Member ID.
CALLER: <gives member number> 
VIRTUAL ASSISTANT: Got it. And what is the claim date?
CALLER: <gives claim date> 
VIRTUAL ASSISTANT: I found your claim.

8.1.2 复杂性对业务指标的影响

过度复杂的使用体验可以从多个维度损害你的业务指标：用户退出率可能会增加，升级到支持人员可能会增加，自助任务完成率可能会减少，NPS 或用户调查分数可能会下降。

在我们的保险公司，一个业务影响的例子是在成功查找索赔之后，出现了一个无法解释的、不成比例的退出（请求代理）数量。在呼叫者导航搜索过程（涉及回答三四个问题）后，他们被问到最后一个问题：他们是否希望读取索赔信息或传真给他们？图 8.3 显示了用户对这一问题的回答分解。

图 8.3 呼叫者几乎三分之二的时间请求代表。最合理的选项——让信息读给呼叫者听（即，通过他们目前正在使用的同一渠道传递）——是第二受欢迎的选择。只有 1%的用户选择了接收他们所需信息的传真选项。

在这个流程的这个阶段，解决方案已经成功识别了用户并检索了他们所需的信息。不幸的是，用户正在退出，不知道他们已经如此接近成功完成他们的目标。这对业务来说显然是一个问题，因为失去控制意味着人工代理正在处理本应由虚拟助手（实际上，几乎已经成功完成）成功完成的任务。以下列表显示了改进前的用户体验。

列表 8.3 即使索赔搜索成功，呼叫者也会请求代理

VIRTUAL ASSISTANT: I found your claim. Would you like to have this information read to you or faxed?
CALLER: Speak to a representative.

在这个节点提供两个选项的原始设计选择在理论上可能看起来合理（主题专家说，“我们经常接到传真的请求”），但证据表明，呼叫者对复杂性的容忍度已经超过了。一个假设是，问题本身错误地发出了复杂情况的信号；否则，为什么机器人不直接读取信息呢？也可能是因为用户在回答了这么多问题而没有得到任何有价值的东西后感到沮丧。

在这个例子中，业务在多个维度上受到影响：退出率增加，升级增加，而自助任务完成率相应减少。合理的解决方案是移除这个问题，简单地读取索赔详情。提供传真选项的提议被移到了流程的后面——在提供索赔详情之后。图 8.4 显示了更新的体验和可能的后果。

图 8.4 更新的体验立即读取索赔详情，然后为需要传真的小部分用户提供传真选项。

消除一个对话回合可以保证所有提供所需索赔查找凭证的呼叫者都成功完成了任务流程，如列表 8.4 所示。一旦提供详细信息，呼叫者可以简单地挂断电话，如果他们已经得到了他们需要的一切，从而实现通话的完全控制。呼叫者还可以选择接收传真，在这种情况下，将调用一个流程来完成该任务。一些用户可能仍然要求代理，但此时要求代理的原因可能与在阅读索赔详情之前要求代理的原因不同。（在这种情况下，可能需要解决一个新的痛点。）

列表 8.4 如果搜索成功，则立即提供索赔详情

VIRTUAL ASSISTANT: I found your claim, number 10012345\. This claim was  approved and a payment for $100 was issued on October 3rd. Would you also like to receive a fax with this information?
CALLER: (may reply yes, no, ask for agent, or hang up)

当你设计你的机器人——或者努力改进现有的机器人——请记住，简单的交互（从用户的角度来看）可以更容易地达到成功的结果。成功的定义将根据用例和业务目标而有所不同。然而，通过适当的规划，可以跟踪解决方案的业务指标到构建或改进解决方案所使用的策略。良好的指标将为理解对话设计的成功率、有用性和弱点提供指导。

8.1.3 简化用户复杂性的增量成本和收益

简化用户复杂性有时会增加对话设计的复杂性。交易性对话——即与用户进行多次互动以达成目标的对话——有多个失败点，并且每个支持的功能或能力都会增加复杂性。为了减轻用户复杂性的痛苦，对话必须设计得尽可能自然和周到。换句话说，你的流程越复杂，你就应该投入更多努力来简化用户界面，以确保最佳的成功机会。

一些简化用户复杂性的策略简单且易于实施，同时又能带来高价值。其他策略，尤其是那些需要与后端系统集成的方法，在实施上更为技术复杂且/或成本高昂。每个企业和用例都必须评估在对话体验中添加如自然语言理解、个性化、自动化等强大功能时，所获得的价值与成本及其他权衡。

当然，良好的指标——本书的一个常见主题——对于良好的规划和优先级排序至关重要。是否值得为机器人可能遇到的所有可能性进行设计？当然不是！但你可以做一些事情来优化大多数用户和场景的体验。80/20 规则是决定在哪里投资改进或扩展机器人功能的好起点。如果 80%的用户将受益，那么实施它可能是有价值的。

对于用户来说，复杂性可能成为成功的障碍。设计一个有效、简化的对话交流需要彻底了解用户，包括他们是谁，是什么原因让他们来到你的虚拟助手，以及他们期望从这次体验中获得什么。用户研究应该指导你的设计。可能并不总是可行或成本效益高来实现所有的适应。然而，值得追求的是在用户所在的位置与他们相遇，并在可能的情况下消除阻碍他们成功的障碍。

练习

审查你构建或遇到的机器人流程：

1. 列出所有步骤。

2. 确定用户完成最困难的步骤。

3. 确定是否有机会重新排序或删除步骤，以使用户的过程更容易。

8.2 简化和优化用户旅程

可以使用多种策略和技术来设计自然、简化的对话体验。在本节中，我们将讨论优化用户旅程的方法。

8.2.1 发现复杂的对话流程

在复杂的流程中，每个回合或用户响应都可能将用户引向特定的路径。理想情况下，这条路径应该是达到最终目标的最高效路线。如果用户的旅程过于复杂或不高效，就有改进的空间。

你如何知道你的解决方案是否过于复杂或不高效？我们观察到了几个不必要的增加对话复杂性的对话设计反模式：

• 请求用户提供他们不太可能拥有或需要时间检索的信息

• 对用户响应的严格、僵化的输入要求

• 提出含糊不清的问题——导致对如何提供“正确”的响应的不确定性

• 以相同的方式对待所有用户和场景，特别是如果这导致提出在所有情况下可能不必要的提问

• 选择过载和不符合用户对如何实现目标的心理模型的选择

• 以不连贯的顺序请求信息

• 请求对界面或渠道来说不是最佳的信息（例如，在语音通道上请求电子邮件地址）

• 传达对界面或渠道来说不是最佳的信息（例如，在语音通道上阅读一个长或复杂的 URL）

识别对话流程中的复杂性是简化用户旅程的第一步。你的性能指标可能表明问题区域。从用户的角度审视解决方案也将揭示复杂的交互。

8.2.2 利用对用户的了解

最佳体验将充分利用在对话开始时解决方案了解的每个用户信息以及沿途学到的关于用户的信息。这些信息通常存储为对话的上下文。这些信息可能来自后端系统或直接来自用户在整个交互过程中。通过使用你所知道或学到的关于用户的信息，你可以个性化对话或动态地将用户引导到最有效的完成路径。

我们合作的一家公司为用户提供了三种查找账户的选项：13 位数的账户号码、社会保障号码或电话号码。在用户选择如何查找他们的账户后，他们必须提供那个号码。这些步骤不仅让用户感到费力，而且也是潜在的失败点。图 8.5 显示了这一流程中涉及的步骤。

图 8.5 在流程中进行之前，呼叫者必须提供两份信息

下面的列表展示了从呼叫者角度的对话体验。

列表 8.5 呼叫者被要求提供两份信息以查找账户

VIRTUAL ASSISTANT: Which would you like to use to look 
up your account? The phone number, a social security 
number, or the account number?
CALLER: The phone number
VIRTUAL ASSISTANT: What is the phone number?
CALLER: <provides phone number>
VIRTUAL ASSISTANT: One moment while I look up your
account.
VIRTUAL ASSISTANT: I found your account. Next, 
please enter your verification passcode

由于体验是基于电话的解决方案，我们通常可以检测到客户拨打的电话号码。使用这些信息，我们可以简化大多数用户的旅程。在执行搜索之前，我们不是询问两个问题，而是对呼叫者 ID 进行背景搜索。如果找到账户，我们就提供电话号码作为查找选项。用户只需确认这就是他们想要的。图 8.6 显示了更新的搜索流程。

图 8.6 利用我们对用户（他们的呼叫者 ID）的了解，我们能够减少痛点并消除在收集用户信息时可能发生的潜在失败。

下面的列表展示了从呼叫者角度更新的对话体验。

列表 8.6 通过电话号码识别的呼叫者跳过不必要的步骤

VIRTUAL ASSISTANT: Would you like to use the phone number you're calling from to look up your account?
CALLER: Yes.
VIRTUAL ASSISTANT: I found your account. Next, please enter your verification passcode

8.2.3 与用户的思维模型保持一致

信息流应与用户从对话交流中期望得到的内容相匹配。尽最大努力按照用户自然期望接收或传达信息的顺序提供或请求信息。换句话说，与他们的信息存储和检索思维模型保持一致。

这也适用于你的措辞选择。当你的聊天机器人提供选择时，确保你的术语与用户理解的内容相匹配。用户是否有足够的信息来选择最适合他们情况的选项？

与用户的思维模型保持一致的另一种方法是允许他们在一次对话中提供多个信息片段。这种技术被称为槽填充。它允许用户用自己的话表达他们的需求，这可能包括重要的细节或规格。当对话能够识别并存储关键信息时，它可能允许用户在流程中进一步前进，绕过重复或不必要的步骤。

例如，当用户预订晚餐时，系统可能需要日期、时间、晚餐人数、预订名称和联系电话。在对话式解决方案中，用户可能会说：“我想在这个周六晚上 8 点预订两个人的座位。”一个健壮的解决方案将识别用户的意图（预订）并检测五个必需细节中的三个（即所谓的实体）。解决方案可能会跳过询问日期、时间和派对人数的步骤，直接让用户收集姓名和联系电话。图 8.7 展示了各种话语如何在晚餐预订对话流程中填充槽位。

图 8.7 随着用户提供更多信息，每个提及（下划线单词）都填充了相应的槽位，消除了在后续步骤中询问此信息的需要。

8.2.4 允许预期的用户响应具有灵活性

以流程为导向的机器人需要从用户那里征求信息，以便沿着最佳路径前进。有时用户并不完全理解机器人正在询问什么。对于用户来说，未能提供正确信息或以正确格式提供信息可能会导致重试或失败。灵活的设计允许有多个“正确”的响应。这允许您为某些用户动态简化对话，同时耐心地引导那些需要更多指导的用户。

在从用户那里征求信息时，问题类型混淆是导致重试或失败的一个常见原因。这种情况最常发生在将多项选择题解释为是/否，反之亦然时。渠道通常决定了你解决问题的方法。图 8.8 展示了如何利用不同渠道的能力来减少问题类型混淆。

图 8.8 可以根据渠道定制输出响应，以确保成功的机会最大化。

如果您无法消除歧义（尤其是在语音通道上，因为按钮或下拉选项等输入选择器不可用的情况下），请确保您的机器人优雅地处理用户提供他们认为机器人正在请求的响应的善意尝试。与其重试（这被视为错误，可能会导致升级），不如澄清用户的响应。以下列表显示了一个重试体验，这暗示用户卡在了一个步骤上。

列表 8.7 步骤重试表明用户响应存在问题

VIRTUAL ASSISTANT: Would you like to get a reminder by text message or phone call?
CALLER: Yes.
VIRTUAL ASSISTANT: Sorry, I didn't get that. Please choose text message or phone call.

从用户的角度来看，区别在于重试向用户表明他们卡住了或出了问题，而消除歧义问题，如下一列表所示，意味着他们正在通过流程。

列表 8.8 提供消除歧义，确保用户正在前进的确认

VIRTUAL ASSISTANT: Would you like to get a reminder by text message or phone call?
CALLER: Yes.
VIRTUAL ASSISTANT: Great! Which would you like: a text message or a phone call?

另一种简化对话的方式是在确认问题（通常是有意询问“是”或“否”回答的问题）的响应中处理更正信息。假设我们问一个呼叫者是否想使用他们正在拨打的电话号码（呼叫者 ID）来接收短信更新。我们计划考虑的明显有效响应是肯定回答（“是的，使用那个号码”）或否定回答（“不，不要使用那个号码”）。

在这种以流程为导向的流程中，肯定回答将进入下一步。否定回答可能会触发一个流程来收集接收短信的备用号码。其他任何东西都可能导致偏离或重试。

让我们考虑我们的机器人可能在这个步骤收到的第三种类型的信息：用户有时会在确认步骤中提供更新或更正信息，而不是“是”或“否”（“使用这个其他号码：555-867-5309”）。以下列表显示了意外响应如何导致失败，进而触发重试，然后是数据收集步骤。

列表 8.9 对确认步骤的严格期望导致不必要的步骤

VIRTUAL ASSISTANT: Would you like to use the number you are calling from to receive text message updates?
CALLER: Send them to 555-867-5309 instead.
VIRTUAL ASSISTANT: Sorry, I didn't get that. Would you like to use the number you are calling from to receive text message updates? 
CALLER: (sigh) No.
VIRTUAL ASSISTANT: Ok, what number would you like to use instead?
CALLER: (sigh) 555-867-5309.

如果我们的机器人只期望“是”或“否”作为响应，逻辑将失败并触发重试。此外，用户将不得不重复他们在初始响应中提供的信息。这两个额外步骤（重试，然后是数据收集）会惩罚那些重视效率的用户。

下一列表显示了灵活设计如何将检测到的电话号码实体视为“否”等效，并且还保存电话号码，这使用户能够绕过随后的数据收集步骤。

列表 8.10 一种灵活的设计，捕捉信息并简化流程

VIRTUAL ASSISTANT: Would you like to use the number you are calling from to receive text message updates?
CALLER: Send them to 555-867-5309.
VIRTUAL ASSISTANT: Got it. Your updates will be sent to 555-867-5309.

8.2.5 使用 API/后端过程支持自助任务流程

为最终用户设计一个简化的体验可能需要个性化或加速自助体验的集成。你能利用与客户信息数据库的 API 连接来检索可以简化流程或帮助确保任务成功完成的 信息吗？

让我们回到我们的保险公司，演示后端过程如何简化用户的旅程。该系统中的成员 ID 可以是九位或十一位。此外，九位 ID 号码以字母开头。作为一个电话通道体验，涉及多个复杂层，包括通过语音通道收集字母数字信息、通过语音通道检测字母数字信息以及执行数据库查找。

通过语音通道收集字母数字信息意味着用户必须被告知说出他们的响应，或者被指导以复杂的方式使用拨号盘。由于几个字母字符（如“B”、“C”、“D”、“Z”等）的发音相似，以及数字和字母（如“8”和“H”）之间的发音相似，因此通过语音通道检测字母数字信息可能会出错。图 8.9 显示了原始流程，其失败率相当高。

图 8.9 原始流程提出了一个复杂的问题。输入容易导致高失败率。

为了降低用户的复杂性，我们添加了一个后端过程，可以检测系统是否已接收到足够数量的数字，无论是否有前面的字母字符。如果只检测到九个数字，我们会为用户添加字母字符（对所有成员都一样）。在重试时可以提供更详细的说明。图 8.10 显示了更新后的后端流程如何使用户问题更加简单。

图 8.10 通过添加后端步骤为用户执行工作，我们能够提出一个更简单的问题。

这种功能可能实施成本高昂，因此决策通常基于实施特定功能的成本效益分析。（您有可以帮助衡量这一点的指标吗？）添加这种复杂性可以提供巨大的价值，但它也引入了更多的潜在失败点。

对于每个潜在的失败点，设计对话以优雅地处理它，提供最佳替代方案或将用户引导回正确轨道的方法。这可能包括重试（重复先前的步骤）、允许用户尝试不同的路径以达到目标，以及升级到代理。

失败的类型可能决定了接下来会发生什么。例如，如果输入需要十位数字输入，但用户只输入了九位数字，则重试是合适的。如果后端系统出现故障（导致 API 失败），重试将不会产生效果。在这种情况下，最好将任务转交给人工处理。如果呼叫者输入账户号码时查找账户失败，提供通过不同方式查找的选项，例如通过电话号码。

练习

检查您当前解决方案，寻找简化用户旅程的机会：

1. 您的解决方案是否表现出任何会增加用户不必要的复杂性的反模式（见第 8.2.1 节以获取列表）？

2. 您是否充分利用了您已经了解的用户及其情况的信息？

3. 对话是否遵循一个符合各种合理用户响应的逻辑流程？

4. 解决方案是否使用了可以促进或加快用户操作或减少用户输入错误机会的 API 或后端流程？

摘要

• 对话越不自然，用户就越难成功使用聊天机器人导航复杂流程。

• 在可能的情况下，降低用户的复杂性将导致最高的容纳率和任务完成率。

• 严格或机械的交互可能会让人感到困惑，甚至听起来粗鲁——当用户参与复杂交互时，这可能会特别令人沮丧。

• 对目标用户群体的研究应指导您对话解决方案的设计。

• 为用户降低复杂性可能意味着扩展您解决方案的功能能力，这会增加聊天机器人生态系统的复杂性。

第九章：利用上下文实现自适应虚拟助手体验

本章涵盖

• 在虚拟助手交互中适当地应用上下文

• 将对话式 AI 适应不同模态

• 识别由忽略模态引起的痛点

在虚拟助手交互中有效地应用上下文对于提供无缝和直观的用户体验至关重要。用户期望虚拟助手能够理解他们的查询，并在他们的上下文中这样做。本章重点介绍了虚拟助手技术中的三个关键个性化来源：上下文、模态和检索增强生成（RAG）。这些都有助于虚拟助手更好地理解和与用户互动。

上下文是指根据用户可用的情境和历史数据定制交互。例如，通过考虑用户的当前位置和时间来回答关于天气的查询，与提供通用预报相比，这体现了有效的上下文使用。

模态指的是用户的沟通方式，如语音、文本或视觉界面。每种模态都提供了独特的优势和挑战。将虚拟助手适应所选模态确保了无缝的交互，无论用户是在键入消息、与设备交谈还是通过图形界面进行交互。

RAG 结合了传统的响应生成能力，以及从外部数据源实时提取信息的能力。这使得虚拟助手能够提供更丰富、更有见地的响应，显著提高相关性和准确性。

虚拟助手可以通过整合这三个元素来提供自适应和个性化的用户体验，本章展示了如何使用这些个性化技术来改变用户交互。本章借鉴了项目交付中获得的见解，说明了这些个性化技术是如何发展成为最佳实践的。

9.1 上下文在虚拟助手性能中的重要性

有效的虚拟助手依赖于上下文来提供有意义和高效的交互。在没有上下文考虑的情况下，用户可能会经历摩擦、误解和挫败感，即使助手在技术上很先进。为了说明这一点，考虑一下 Emma 的经历，她是一位刚刚毕业的学生，在银行聊天机器人 Max 的帮助下管理她的财务：

Emma 是一位刚刚毕业的学生，刚刚开始她的第一份工作，她很兴奋能够独立管理自己的财务。她在一家提供名为 Max 的聊天机器人以供客户支持的银行开设了账户。Emma 依赖 Max 来完成各种任务，比如查看她的余额、设置账单支付以及了解她的学生贷款选项。然而，尽管 Max 的功能很先进，Emma 经常感到沮丧和不知所措。

Emma 决定她需要一张新的信用卡，并开始了一个新的聊天机器人会话。Max 提供了一系列银行的信用卡选项，解释了每个选项的优缺点。然而，Max 没有识别出 Emma 是银行的现有客户。Max 提供的建议没有考虑到她的当前财务状况或现有账户。

Emma 决心做出明智的决定，她请求推荐哪种信用卡最适合她的需求。由于 Max 无法访问她的账户详情和交易历史，因此提供的建议与她的消费习惯或财务目标不符。Emma 不得不额外花费时间浏览银行的网站并拨打客户服务电话，以获得她需要的个性化帮助，从而抵消了 Max 本应提供的便利。

如您所见，Emma 与 Max 的互动充满了问题点：未能考虑她与银行现有关系的通用建议，错失了个性化帮助的机会，以及沟通不佳。尽管 Max 具有一定的技术能力，但 Emma 无法从聊天机器人中获得足够的价值。

使用上下文来提高聊天机器人性能至关重要。上下文理解使聊天机器人能够提供相关、及时和准确的响应——这是我们期望从聊天机器人那里获得的用户体验。表 9.1 总结了 Emma 遇到的问题点，并描述了可能的解决方案。使用上下文，像 Max 这样的聊天机器人可以从简单的任务执行者转变为智能、适应性强的助手，从而提高生产力和用户满意度。通过上下文理解解决这些问题点确保了无缝和有支持性的体验，赋予像 Emma 这样的用户能力。

表 9.1 解决 Emma 的问题点

问题点	可能的解决方案	为什么和如何
聊天机器人在回答问题时无法访问用户信息	集成账户信息	通过访问 Emma 现有的账户和财务历史，Max 可以提供个性化的建议。例如，Max 可以推荐一张与 Emma 当前账户和消费习惯相匹配的信用卡。
聊天机器人提供通用的建议	具有上下文感知的财务建议	通过访问 Emma 的交易历史和特定的财务目标，Max 可以提供更相关和定制的财务建议，节省 Emma 宝贵的时间和精力。
提供和重复标准响应	适应性响应	通过理解 Emma 的财务优先事项和消费模式，Max 可以相应地调整其响应和行动。例如，了解 Emma 最近开始工作并可能正在处理学生贷款，Max 可以主动提供关于预算和贷款管理的见解。
聊天机器人仅在单个文本通道中工作	不同情境下的模式	识别每个任务适当的模式是关键。例如，通过聊天提供个性化的信用卡推荐，通过电子邮件发送详细的财务报告，或通过通知提供快速更新，可以使交互更加高效和用户友好。

9.1.1 情境如何影响用户交互

情境在塑造用户与虚拟助手（尤其是聊天机器人）之间的交互中起着关键作用。当聊天机器人理解用户查询的情境时，它可以提供更准确、相关和个性化的响应。这导致用户体验显著改善。本节概述了情境如何影响用户交互。

增强的相关性和准确性

当聊天机器人将用户历史整合到其响应中时，它增强了交互的相关性。例如，如果艾玛经常询问她的储蓄账户，聊天机器人可以记住这个“偏好”并主动提供有关该账户的更新和信息。回忆过去的交互有助于聊天机器人提供针对用户特定兴趣和需求的定制化响应，而不是提供通用信息。这种个性化的参与节省了用户的时间，并培养了用户被理解和重视的感觉。

注意：使用历史交互调整聊天机器人以实现情境感知需要额外的开发。大多数对话式人工智能提供商不提供情境感知作为内置功能。

此外，了解用户的当前状态有助于聊天机器人提供精确的帮助。例如，当艾玛询问她的账户余额时，一个情境感知的聊天机器人应该首先通过提供她的账户选项列表来消除歧义，确定她指的是哪个账户。一旦她选择了一个账户，聊天机器人应该提供最新的和准确的余额，反映最近的交易活动——如存款、取款或待处理和计划中的支付——这样艾玛就能获得完整的画面。

在金融问题（如建议可用资金或即将到来的账单）方面，这种程度的意识至关重要。例如，知道是否有任何交易待处理，可以给艾玛提供更好的情境。根据金融机构和交易类型，待处理交易可能需要最多五天才能过账，因此可能会影响可用余额。虽然今天的大多数聊天机器人实现只提供简单的余额数字，但一个真正情境感知的系统将通过提供最相关、最及时和最准确的信息来帮助用户。

个性化体验

情境感知聊天机器人最吸引人的好处之一是提供个性化的体验。当聊天机器人识别并分析用户的财务目标和消费模式时，它可以提供符合他们需求的定制化建议。例如，经常旅行的用户可能会被推荐带有旅行奖励的信用卡。这种个性化的程度使得聊天机器人的建议更加有用，并通过理解用户的独特情况来提升整体用户体验。

此外，针对生活事件和个人里程碑的响应可以显著提高相关性。例如，如果聊天机器人知道用户最近刚刚毕业并开始了一份新工作，它可以提供针对过渡到经济独立的人的预算建议。这种个性化的互动可以让用户感到更有支持和理解，从而提高他们对服务的满意度和参与度。

表 9.2 强调了情境感知聊天机器人如何根据特定的用户情况定制建议，而不是提供通用建议。这说明了个性化的价值。

表 9.2 示例交互：非情境化、情境化和个性化响应

用户查询：我应该如何管理这个月的开支？

非情境化响应

针对经常旅行的用户的情境化响应

针对刚入职新工作的应届毕业生的情境化响应

解决问题的效率

情境感知提高了与聊天机器人进行问题解决交互的效率。当聊天机器人知道用户的近期活动或持续问题时，它可以提供更准确的解决方案。例如，如果用户最近报告了丢失的卡片，聊天机器人可以优先帮助他们追踪替换卡件的配送。这种有针对性的帮助可以更快地解决问题，减少用户因重复信息或等待通用响应而产生的挫败感。

情境理解也简化了交互。通过“记住”过去的互动，聊天机器人可以避免重复问题，使交互更流畅、更高效。这种能力在时间敏感的情况下特别有用。一个能够有效解决用户问题的聊天机器人可以增强整体用户体验并提高用户对服务的信心。

考虑一个最近报告丢失信用卡的用户。传统上，聊天机器人可能会提供一组标准选项，例如“检查账户余额”、“开设新账户”或“申请贷款”。然而，随着情境意识的增强，聊天机器人的意图分类器会根据用户的最近互动动态调整。聊天机器人不再提供标准选项，而是呈现定制选项，如“申请补发卡片”、“追踪卡片配送”或“审查最近的未授权交易”。图 9.1 展示了两种聊天机器人交互。没有情境意识的情况下，第一种提供通用选项并要求用户重复信息，导致令人沮丧的体验。有了情境意识，第二种记住用户的最近问题并提供定制选项，从而更快、更有效地解决用户的问题。

图 9.1 一个通用的聊天机器人设计没有考虑用户情境——它总是提供相同的选项。情境意识增强了整体用户体验。

图 9.1 右侧显示的改进是通过数据跟踪和机器学习模型实现的，这些模型分析用户的最近活动和记录的偏好。系统记住过去的互动，并使用这些情境来调整显示的选项，增强了聊天机器人响应的相关性和速度。这种能力使得聊天机器人能够提供更流畅、更直观的体验。

聊天机器人历史有两种形式，都与保持情境相关：

• 会话历史——当前交互会话的内容。一旦会话结束，历史记录将被记录但通常会被丢弃。这个历史可以帮助我们理解即时情境，例如在单个对话中的后续问题。

• 持久用户历史——这跨越了同一用户的多个会话历史，甚至跨越不同的模式。它可以用来推断用户偏好和倾向，但将其纳入对话需要额外的努力。使用持久历史可以改善多个交互的用户体验。

主动支持

主动支持是设计良好的、上下文感知的聊天机器人的一个标志。主动聊天机器人可以主动与用户进行对话，而不仅仅是响应查询。它们可以在问题变得紧急之前发现潜在的问题。一个主动的银行聊天机器人可以发送关于即将到来的账单、低余额或异常账户活动的即时提醒。这些主动警报帮助用户保持对财务状况的掌控，避免潜在的诸如滞纳金或透支等问题。

该聊天机器人还可以利用基于用户行为和财务模式的预测洞察。分析趋势和习惯可能导致在用户有大量月度盈余时设置储蓄计划的行动。这些预测能力使该聊天机器人能够充当财务顾问，帮助用户更有效地实现他们的财务目标。

建立信任和忠诚度

响应的一致性对于建立用户对聊天机器人的信任至关重要。一个始终提供准确和个性化协助的聊天机器人显示出可靠性和能力。当用户知道他们收到的响应将针对他们的情况定制时，他们会更有信心依赖聊天机器人。信任对于培养长期参与和忠诚度至关重要。

个性化交互和主动支持可以提高用户满意度——当用户感觉他们的聊天机器人理解并支持他们时，他们更有可能报告积极的体验并继续使用该服务。高水平的用户满意度鼓励重复互动并加深用户与聊天机器人机构的联系，最终使双方受益。

9.1.2 什么是上下文信息？

上下文信息包括任何可以个性化用户体验的数据点。这些包括用户位置、时区、设备类型、偏好、行为模式、先前交互和模式。每个都可以个性化用户交互，但可能需要额外的开发工作来将这些整合到您的聊天机器人中。

用户位置

用户位置指的是用户的地理位置。这可以通过 GPS 数据或 IP 地址来确定，无需用户明确指定他们当前的位置。了解用户的位置允许虚拟助手提供更相关和高效的协助，尤其是在实时场景中。让我们探讨这如何适用于我们之前的例子，其中 Emma 现在正在国外出差，需要帮助找到最近的 ATM：

Emma 正在国外出差。她需要找到最近的 ATM 提取当地货币，因此她向银行的聊天机器人 Max 寻求帮助。

知道用户的位置对于提供相关和及时的帮助至关重要，如图 9.2 所示。Max 可以使用 Emma 的当前位置列出附近的 ATM。此外，位置信息有助于通过标记在异常或不寻常地点发生的交易来检测和预防欺诈活动。使用地理定位 API 获取用户的位置并将其集成到聊天机器人交互中。

图 9.2 典型的聊天机器人响应不考虑用户的位置，但当考虑位置上下文时，它们会显示最合适的响应。

备注：确保安全地存储位置数据并维护用户同意以符合隐私法规至关重要。当不再需要时删除此数据！

时区

时区指的是用户的本地时区。对于调度和时间相关的功能至关重要。让我们回到我们的例子：

目前 Emma 在伦敦，英国，需要安排与她在纽约市的银行客服团队的通话。她要求 Max 帮助找到一个合适的时间。

知道用户的时区可以确保通信和提醒引用适当的时间，如图 9.3 所示。例如，Max 可以为在伦敦的 Emma 建议方便的通话时间，即使客服团队在纽约。这避免了由时差引起的任何混淆或不便。

图 9.3 许多聊天机器人响应不考虑用户时区上下文。当考虑时，响应更有用。

通过使用 pytz 等库将时间转换为用户的本地时区来实现时区转换。开发考虑用户时区的提醒和预约功能，确保通信和提醒在适当的时间发送，以避免混淆或不便。

设备类型

设备类型指的是用户用于与聊天机器人交互的设备，例如智能手机、平板电脑、桌面或可穿戴设备。让我们回到我们的例子：

Emma 更喜欢使用她的平板电脑进行详细的财务规划，而使用智能手机进行快速余额检查和通知。

知道设备类型允许聊天机器人根据用户的当前设备优化交互。例如，Max 可以为小屏幕智能手机提供简化的界面和简洁的响应，同时在更大的平板电脑上提供更详细的信息和功能。这确保了无论使用哪种设备，用户体验都是有效的。

检测用户的设备类型允许聊天机器人针对最佳显示和功能定制互动。您可以使用用户代理字符串或设备信息 API 检测用户的设备类型，并调整用户界面和响应格式以匹配设备的功能。为移动设备提供简化的界面，为桌面提供更详细的界面，确保在不同设备上提供顺畅和定制的用户体验。再次提醒，在设计或改进计划时，分配额外的发展时间。

用户偏好

用户偏好指的是用户的特定选择和设置，例如他们偏好的通信渠道、通知设置和数据展示格式。让我们再次看看我们的例子：

艾玛更喜欢通过电子邮件接收月度财务摘要，并通过短信接收紧急警报。

通过遵守艾玛的通信偏好，Max 确保以她认为最方便和最不干扰的方式传递重要信息。这种对用户偏好的尊重有助于建立信任和参与度。

实施用户偏好设置确保沟通与用户期望保持一致。允许用户设置通信渠道、通知设置和数据展示格式的偏好，并安全存储这些偏好，并一致应用。使用存储的偏好来定制互动和通知，确保聊天机器人尊重用户选择，以提升满意度和建立信任。

行为模式

行为模式指的是用户通过与其聊天机器人和其他服务的互动观察到的重复行为和习惯。让我们回到我们的例子：

艾玛每天早上都会检查她的账户余额，并在每个月的第一天支付账单。

识别行为模式使聊天机器人能够预测用户需求并提供主动支持。例如，Max 可以在每天早上自动提供余额更新，或者在月初临近时提醒艾玛支付账单。这种主动帮助通过使互动及时和更直观来提升用户体验。

分析用户行为有助于预测需求并提供主动帮助。收集用户互动和交易数据以识别模式，并使用机器学习算法分析和预测用户行为。利用行为分析洞察提供主动支持和建议，实施基于识别模式的自动调整功能。这种主动帮助通过使互动及时和更直观来提升用户体验。

之前的互动

之前的互动指的是用户与聊天机器人之间所有过去通信和交易的历史记录。这包括提出的问题、使用的服务以及由于这些互动而采取的任何行动。让我们回到我们的例子：

在过去几个月里，艾玛经常向 Max 询问预算建议和贷款还款选项。今天，她询问如何设置储蓄计划。

理解之前的互动使聊天机器人能够提供更个性化和一致的响应。例如，由于艾玛有寻求财务建议的历史，Max 可以建议符合她过去查询和财务目标的定制储蓄计划。这种连续性节省了艾玛的时间，避免了重复的问题，并建立了一种熟悉感和信任感，因为聊天机器人似乎记得并理解她的需求。

维护之前的互动日志有助于聊天机器人提供个性化的响应。为了实现这一点，在数据库中使用唯一的用户标识符记录用户互动，跟踪和检索过去的互动。使用这个互动历史根据过去的查询提供定制化的响应。实施算法分析互动模式以提供更好的推荐，确保聊天机器人的响应在连续性和熟悉性方面。

备注  用户之前的互动日志在理解聊天机器人成功方面也很有用。如果聊天机器人提供了一个答案，但用户在设定的时间段内（比如 24 小时或一周）返回了相同的问题，那么这个答案可能没有帮助。保留和分析之前的互动日志也有助于我们理解“真正的”控制。

交流方式

交流方式指的是用户在特定时间偏好或需要的交流方法或模式。这可以包括文本、语音、电子邮件、推送通知或任何其他通信渠道。让我们看看我们的例子：

艾玛总是忙碌着，并且喜欢在驾驶时通过语音命令与银行的聊天机器人 Max 互动。她让 Max 检查她的账户余额和最近的交易，确保她可以在不输入或查看手机的情况下保持信息畅通。

认识和适应用户的偏好交流方式对于有效沟通至关重要。在艾玛的情况下，Max 可以发送简明的文本消息总结她的账户活动，尊重她的当前情境。不同的情况需要其他交流方式，而能够无缝切换这些方式的聊天机器人确保用户能够尽可能方便和高效地接收信息。这种适应性通过满足个人偏好和情境需求来提高用户满意度和参与度。

通过理解和整合用户位置、之前的互动和交流方式，聊天机器人可以显著增强情境意识。这导致更准确和相关的响应，并促进更吸引人和支持性的用户体验。

实施这些策略并使用情境信息可以帮助聊天机器人提供高度个性化和吸引人的用户体验。使用用户情境的方法增强了互动的相关性和准确性，建立了用户信任和满意度，最终导致更好的参与度和忠诚度。

练习

1. 确定虚拟助手可能使用的五种上下文信息类型，以增强用户交互。以下列表提供了一个结构化的格式，以指导你的分析，其中包含一个完成的示例，说明如何收集和利用用户位置以及它如何影响用户满意度：

   • 上下文信息—用户位置

   • 收集方法—来自移动设备的 GPS 数据

   • 利用—提供基于位置的服务，例如当地天气更新或附近餐厅推荐

   • 效果—增强相关性和个性化，提高用户满意度

对于其他四个相关的上下文因素也进行同样的操作，描述它们是如何收集的，如何增强虚拟助手的交互，以及它们对用户参与度的潜在影响。

1. 2. 设计上下文感知的响应。创建三个虚拟助手可能收到的不同用户查询。对于每个查询，指定至少两件可能用于个性化响应的上下文信息。写出虚拟助手会提供的上下文感知响应，解释上下文如何改善交互。以下是一个示例：

   • 用户查询：“今天的天气怎么样？”

   • 上下文信息：用户的位置，当前时间

   • 上下文感知响应：“早上好！今天早上旧金山的天气是晴朗的，下午晚些时候最高气温将达到 75°F。”

9.2 理解模式

模式指的是用户与虚拟助手沟通的各种渠道或方法。模式包括文本、语音、图像和多模态交互。每种模式都带来其优势和挑战，影响着用户如何与助手互动以及助手如何有效地满足用户需求。有效利用模式可以使聊天机器人从功能型转变为直观和吸引人的。虚拟助手的性能受模式的影响。

例如，基于文本的交互可能更适合于打字更方便的环境，而语音交互则提供了免提便利和更自然的对话流程。多模态交互结合了文本、语音和视觉元素，可以提供更丰富和更灵活的用户体验。

评估这些模式如何影响用户参与度和交互设计对于持续改进至关重要。开发者可以应用特定的评估技术来评估不同模式下的现有虚拟助手流程，以确定改进的区域。这确保了一个有效的持续改进过程。

9.2.1 模式比较

聊天机器人最初是简单的基于文本的对话应用，但已演变为多模态通信。一般来说，模式指的是某事发生或体验的方式或模式。聊天机器人的模式与它如何与用户交互以及处理信息相关：

• 文本—文本是主要且最常用的模式。用户输入他们的问题或命令，聊天机器人以文本形式回应。

• 视觉—视觉模式是主要与文本交互的聊天机器人。尽管如此，其回应使用视觉元素，如按钮、图片、轮播图、视频和其他图形界面，以促进交互。添加视觉元素可以通过提供视觉提示和选项来增强用户体验。

• 语音—语音机器人以口语与用户交互。这包括理解口语输入和生成口语回应。通常，底层的对话引擎仍然处理文本，因此发生语音到文本和文本到语音的转换。

• 多模式—这些机器人结合了多种模式，如文本、语音、图像和视频。例如，一个多模式聊天机器人可以理解口语查询，显示相关图片，并以文本和语音的形式回应。

表 9.3 简要比较了不同的模式，突出了它们的独特特征、优点和挑战，以及何时使用它们及其对用户参与度的影响。此外，它还概述了每种模式的相应评估技术。

表 9.3 模式概述

	文本模式	视觉模式	语音模式	多模式交互
描述	通过书面文字进行沟通	使用带有额外视觉元素的文本进行沟通	通过口语进行交互	结合文本、语音和视觉元素

| 优点 | 精确的沟通。易于参考。

| 通过引人入胜的界面通过视觉增强理解 | 免提操作。自然的对话流程。

| 更丰富的用户体验。多变的交互。

|

| 挑战 | 打字可能很慢。可能缺乏情感色调。

| 视觉元素可能会分散注意力或被忽略。需要精心设计的用户界面。

| 需要清晰的语音。可能误解口音。

设计和实现更复杂。

何时使用

对用户参与度的影响

| 评估技术 | 用户反馈调查。可用性测试。

| 用户界面测试。视觉有效性分析。

| 语音识别准确性测试。用户反馈。

| A/B 测试。多模式可用性评估。

|

选择模态直接影响到用户如何与对话式人工智能互动和参与。通过识别文本、语音、视觉和跨模态交互的优势和挑战，聊天机器人设计者可以更好地定制体验以满足用户需求和偏好。虚拟助手的性能在于能够无缝集成和优化这些不同的通信渠道。

9.2.2 设计虚拟助手流程中模态的重要性

设计虚拟助手流程时，模态的选择对用户体验和交互的有效性有显著影响。

需要考虑的一个关键方面是虚拟助手将被使用的上下文。例如，当用户需要免提操作时，如驾驶或烹饪，语音模态至关重要。这需要强大的自然语言处理能力来准确解释语音命令并提供适当的响应。此外，设计者必须确保语音交互感觉自然流畅，避免机器人或过度重复的响应，这可能会让用户感到沮丧。嘈杂的环境也起着作用，因为背景噪音可能会影响语音识别系统的性能，需要先进的降噪技术。

对于语音交互来说，简洁性至关重要。由于语音是一种比文本更受限的媒介，用户从简短、直接且易于处理和理解的响应中受益。在语音交互中，冗长的回答会显得繁琐，因为用户无法像在文本中那样视觉扫描或跳过部分内容。因此，虚拟助手应优先提供清晰、简洁的信息，以支持高效的免提体验。

在基于文本的交互中，清晰度至关重要，但模态允许更广泛的沟通。虽然简洁性很有价值，但文本交互为用户提供了自己节奏下回顾细节的选项。基于文本的虚拟助手仍应设计为处理简洁的用户输入并提供可操作的回复，但它们可以使用自动建议和预测文本等特性来使交互更快更高效。使用文本时，用户可能需要多任务处理或需要更详细的响应，他们可以按需快速浏览或重新查看，因此助手的提示和响应应精心设计，以免让用户感到不知所措。

小贴士：考虑可访问性选项，例如为视障用户提供的屏幕阅读器，确保基于文本的交互具有包容性和用户友好性。

视觉模式，它结合了文本和视觉元素，如图像、按钮和图标，需要不同的设计方法。通过提供上下文线索并使界面更具互动性，视觉元素可以显著增强理解和参与度。您必须在视觉吸引力和功能性之间保持平衡。界面中过多的视觉元素可能会降低清晰度和可用性。设计师应优先考虑视觉清晰度和一致性，使用视觉元素来补充和增强文本，而不是掩盖它。这种模式在视觉辅助可以简化复杂信息的情况下尤其有效，例如故障排除指南或交互式教程。确保视觉元素能够适应不同的屏幕尺寸和分辨率，对于在多种设备上保持无缝的用户体验至关重要。

9.2.3 模式如何影响用户体验的例子

列表 9.1 和 9.2 探讨了技术支持聊天机器人如何使用不同的模式——基于文本的说明与视觉（视频）说明——来帮助用户设置新的打印机。

列表 9.1 文本模式交互

User: I need help setting up my new printer.
Chatbot: I would be happy to help you set up your printer. Please follow these steps: Unbox the printer, place it on a stable surface and connect it to power. Install the ink cartridges and load the paper. Download and install the printer drivers from our website for software setup, then connect the printer to your computer via USB or Wi-Fi.
User: I can't open the printer cover to install the ink cartridges. Where is the latch?
Chatbot: The latch should be on the front panel. Please check around the edges for any visible buttons or levers.
User: I've checked, and there's no latch. Can you help me find it?
Chatbot: I apologize for the inconvenience. If you're unable to locate the latch, please refer to the user manual for your specific printer model for detailed instructions.
User: I don't have the manual. This is really frustrating.
Chatbot: I understand your frustration. Unfortunately, I can't provide more specific guidance without knowing the exact model. Could you check our website for the support page for your model?
User: This is useless. Forget it!

列表 9.2 视觉模式交互

User: I need help setting up my new printer.
Visual bot: I would be happy to help you set up your printer. Would you like to watch a video tutorial on the setup process?
User: Yes, please.
Visual bot: Great! Here is a video that will guide you through the entire setup process step by step. [*Video starts to play*] *[User watches the video, then starts setting up the printer]*
User: I am at the part where I need to insert the ink cartridges. Can you show that part again?
Visual bot: Sure! Here is the specific section of the video that demonstrates how to insert the ink cartridges. *[Video goes to specific timestamp]*
User: Perfect, that makes it so much clearer. Thanks!

基于文本的说明，虽然提供了详细和精确的步骤指导，但当用户遇到说明中未明确涵盖的问题时，往往会引起困惑和挫败感。没有视觉提示，用户可能难以理解特定的步骤，例如在打印机上找到闩锁，这可能导致令人沮丧的来回交互。这种类型的交互在用户对不清晰的闩锁位置的日益增长的挫败感中表现得非常明显。需要额外的澄清可能会导致用户体验效率降低和更加恼人。

相比之下，视觉模式，尤其是通过视频说明，提供了一种更清晰、更吸引人的方式来遵循设置过程。视频使用户能够看到实际的过程，使其更容易理解和复制每一步。这减少了多次交互的需要，并最小化了误解或错误解释指令的机会。如果需要进一步的澄清，用户可以参考视频的特定部分，确保设置体验更加顺畅和高效。

考虑一个用户在语音聊天机器人的帮助下询问航班信息的场景。一个设计良好的语音机器人可以提供适当的信息，甚至在适当的时候切换到不同的模式，而一个设计不佳的机器人可能会导致更多的困惑和挫败感，如列表 9.3 和 9.4 所展示的。

列表 9.3 设计不佳的语音机器人交互

User: I need to check the status of my flight.
Voice bot: Please provide your flight number and departure date to check the flight status.
User: It's flight XY123 on August 5th.
Voice bot: Please hold while I retrieve this information... Your flight UA123 on August 5th is on time. Please visit our website if you need more details or have other inquiries.
User: Can you tell me the gate number?
Voice bot: Please visit our website for more details about your flight.
User: [..hangs up..]

列表 9.4 设计良好的语音机器人交互

User: I need to check the status of my flight.
Voice bot: I can help with that. What is your flight number and the departure date?
User: Flight UA123 on August 5th.
Voice bot: One moment while I check that for you... Flight UA123 on August 5th is scheduled to depart on time from gate 22B. Would you like information on baggage claim or perhaps directions to the gate?
User: Yes, directions please.
Voice bot: Gate 22B is located in Terminal C. After security, follow the signs towards the terminal. It's near the food court. Would you like a map sent to your phone?
User: Yes, please.
Voice bot: I've sent it to your phone. Anything else I can help with today?

在设计不佳的交互中，语音机器人未能提供全面的支持，迫使用户通过不那么方便的渠道寻求额外信息。相比之下，设计良好的语音机器人能够预见用户的需求，通过提供所需信息以及相关细节的补充，从而提供全面的帮助，改善整体用户体验。

9.2.4 语音机器人设计考虑因素

正如前一个章节的示例所示，为了确保积极的语音机器人用户体验，必须考虑几个关键因素。首先，沟通的清晰性和简洁性是必不可少的。机器人应该将信息分解成可管理的、一步一步的指令，使用户能够轻松跟随并理解每个过程的部分。情境意识是另一个关键方面；机器人应该识别用户的进度并提供针对他们情况的相应指导。此外，结合错误处理并提供澄清或重复的选项可以帮助可能需要额外帮助的用户。设计机器人时，保持自然、对话的语调也很重要，这样可以使交互感觉更直观，而不是那么机械。最后，提供多模态支持，例如提供视频教程或视觉辅助链接，可以满足不同的学习偏好，并增强语音机器人的整体效果。通过优先考虑这些考虑因素，设计师可以创建出既高效又用户友好，并能适应广泛用户需求和情境的语音交互。

下面是语音机器人设计的五大设计考虑因素：

• 提供逐步步骤。语音机器人应该将任务分解成清晰、可管理的步骤，并按顺序引导用户完成每个步骤。这一点至关重要，因为用户不能像阅读文本那样视觉扫描步骤。通过允许用户在继续之前确认完成，机器人确保他们不会在过程中感到不知所措或迷失方向。

• 设计鲁棒的错误处理策略。由于口音、发音障碍或背景噪音导致的语音识别错误，在语音交互中误解更为常见。设计策略以优雅地处理这些错误，而不让用户感到沮丧，这是至关重要的。这包括澄清问题和简化响应，以便重新回到正确的轨道。

• 考虑 自适应响应时间。语音机器人必须有效地管理交互的节奏。由于用户不能像阅读文本那样回顾听到的词语，机器人需要调整其说话速度，允许用户自然地处理暂停，并对用户可能需要更多时间的提示保持敏感。

• 在采取行动前提供确认。语音机器人应在采取重大行动前与用户确认。这在语音交互中尤为重要，因为它可以防止对语音命令的误解导致意外行动。

• 支持不同的语音模式**。 设计语音识别系统以理解不同的口音、方言和语音模式。这种包容性确保了更广泛的用户能够有效地与机器人交互。

值得注意的是，这些语音机器人设计考虑因素对于聊天机器人设计同样相关。两种模态都依赖于基本元素，如用户需求分析、上下文感知、自然语言处理和强大的错误处理。此外，个性化、可访问性、无缝切换和持续改进等因素在创建引人入胜、用户友好的虚拟助手方面发挥作用，无论它们使用语音还是文本。

然而，某些设计因素必须适应语音交互。与基于文本的聊天机器人不同，语音机器人需要处理语音模式、口音和背景噪音的变化，所有这些都可能影响理解和使用体验。语音交互最关键的因素是简洁和清晰，因为用户可能需要帮助来保留长的口头指令。相比之下，基于文本的聊天机器人可以提供用户可以按自己的节奏阅读的详细信息，这使得参考对话的先前部分更容易。通过针对每种模态的独特特征调整这些考虑因素，设计师可以创建更直观、更有效的虚拟助手。

练习

1. 审查以下场景，并确定每种场景（文本、语音、视觉或多模态）最有效的模态。为你的选择提供简要的解释：

   • 场景 1：用户需要帮助设置复杂的软件程序。

   • 场景 2：用户在驾驶时询问最近的加油站。

   • 场景 3：用户想要浏览新服装商品的目录。

   • 场景 4：用户请求每日励志名言。

2. 选择一个虚拟助手可能帮助用户完成的任务，例如预订航班或选择信用卡。设计一个至少包含两种不同模态的多模态交互。解释每个模态如何增强用户体验并有助于完成任务。以下是一个示例：

   • 任务：预订航班

   • 交互：助手使用语音提出初始问题（例如，目的地、日期），并使用文本显示带有图片和价格的航班选项。

   • 说明：语音交互提供了一种快速、自然的信息收集方式，而文本和视觉帮助用户比较选项并做出明智的决定。

9.3 使用 RAG 增强上下文感知和提升整体用户体验

随着虚拟助手的演变，更自适应和语境感知的交互变得越来越关键。“自适应流程”一词指的是虚拟助手根据实时上下文和用户行为动态调整交互路径的能力。这使得虚拟助手能够提供更个性化和相关的响应。通过使用第六章中介绍的先进技术如 RAG，虚拟助手可以访问和整合大量上下文信息，增强其理解和响应用户需求的能力。这种方法提高了交互的准确性和相关性，并显著提升了整体用户体验，使虚拟助手更加直观和有效。

RAG 结合了信息检索系统的优势与生成模型，使虚拟助手能够从外部来源检索相关信息并生成语境丰富的响应。这种方法允许对用户查询有更深入的理解，并生成更准确的响应，因为助手可以调用更广泛的知识库，而不仅仅是其预训练的数据。通过将 RAG 纳入自适应流程，虚拟助手可以持续学习和适应新信息，确保其交互保持最新且高度相关。本节将探讨自适应流程的原则以及如何利用 RAG 创建更响应和语境感知的虚拟助手体验。

9.3.1 使用 RAG 设计自适应流程

自适应流程需要设计考虑。适应性确保助手能够提供个性化、相关和及时的响应，从而提升用户体验。与静态流程不同，静态流程中的交互遵循预定的脚本，自适应流程灵活且响应迅速，使助手能够有效应对各种场景。

例如，考虑一个虚拟助手帮助用户进行在线购物的情况。在静态流程中，助手可能只是询问产品类别并列出可用商品：

User: Hi, I am looking for a new laptop.
Chatbot: Sure! We have options for gaming laptops, business laptops, and laptops for everyday use. What kind are you looking for?

静态流程提供了一种基本、通用的交互。聊天机器人提供标准选项，而不考虑用户的过去行为或偏好。用户必须逐个询问每个产品的详细信息，这可能耗时且缺乏吸引力。这种方法没有考虑上下文信息，如用户的先前交互或特定兴趣，导致了一种一刀切的经验，可能无法完全满足用户的需求。

然而，在自适应流程中，助手可以记住用户的先前购买、偏好的品牌和当前的促销活动，以定制购物建议。如果用户之前表现出对环保产品的兴趣，助手可以优先展示可持续选项：

User: Hi, I am looking for a new laptop.
Chatbot: Welcome back! Last time you looked at eco-friendly options. Are you still interested in sustainable products?

自适应流程使用上下文信息创建更个性化和相关的交互。通过记住用户对环保产品的先前兴趣，聊天机器人可以调整其推荐以符合他们的偏好。自适应流程还主动提供额外信息，如客户评价和产品比较，而无需用户请求。这种预见性方法通过使聊天机器人更有效地预测和满足用户需求，提高了用户体验的效率和满意度。总的来说，自适应流程展示了如何利用上下文和个人化可以显著提高虚拟助手交互的质量。

要实现这种自适应响应，RAG 提示可能告知模型在生成响应时考虑用户的历史（先前搜索的上下文），确保助手不仅反应迅速，而且具有预见性：

{
  "user_query": "Hi, I am looking for a new laptop.",
  "context": "previous searches: eco-friendly laptops",
  "generate_response": true
}

另一个例子是在技术支持领域。静态流程可能会引导用户通过一个通用的故障排除脚本，但自适应流程可以根据用户的特定设备、之前报告的问题和实时诊断数据动态调整。如果用户经常因网络问题联系支持，助手可以主动检查网络设置并建议相关解决方案，节省时间并提高效率。

通过关注初始交互并简洁地展示静态和自适应流程之间的差异，我们可以突出自适应设计的重要性。RAG 的使用还进一步允许助手有效地整合和使用上下文数据，从而创造一个更具吸引力和个性化的用户体验。对比变得清晰：静态流程提供了一种一刀切的方法，而自适应流程则根据个别用户的需求、偏好和以往互动来定制体验。

将强大的信息检索机制与高级自然语言生成能力相结合，对于使用 RAG 框架设计自适应流程至关重要。RAG 增强了助手从外部来源提取相关数据并生成上下文适当响应的能力，从而创造了一个更动态和响应性的交互体验。以下步骤概述了使用 RAG 框架创建自适应流程的过程：

1. 识别影响交互的上下文元素。 这些元素包括用户偏好、历史交互、实时数据和外部信息来源。在健康管理助手中的相关上下文元素可能包括用户的医疗历史、当前健康指标、季节性健康趋势和最新的医学研究。助手可以通过整合这些元素提供个性化的健康建议和提醒。

2. 开发检索机制。 RAG 允许助手实时查询外部数据库、文档或 API 以获取相关信息。例如，在在线购物示例中，助手可以从零售商的数据库中检索最新的产品评论、库存可用性和当前折扣。然后，这些信息被用来根据用户的需求和偏好定制购物建议。

3. 使用检索到的数据生成连贯且上下文相关的响应。 这正是助手自然语言生成能力发挥作用的地方。例如，如果用户请求环保产品推荐，助手不仅列出产品，还突出其可持续特性，如可回收包装或节能，增强响应的相关性。

持续学习和反馈整合对于确保适应性流程的有效性至关重要。助手应该能够从用户互动中学习，根据反馈和不断变化的患者偏好调整其响应。例如，在技术支持方面，如果用户持续发现有帮助的解决方案，助手应该在未来互动中优先考虑该解决方案。此外，用户反馈可用于完善检索和生成算法，确保助手的性能随着时间的推移而提高。

通过使用 RAG 框架设计适应性流程，虚拟助手可以提供更个性化、相关和及时的互动，显著提升用户体验。这种方法不仅提高了响应的准确性和质量，还使助手更加直观和用户友好，能够适应每个用户的独特需求。

9.3.2 获取和生成上下文相关响应的策略

在日常实践中，平衡个性化与可扩展性对于在管理运营效率的同时提供高质量的用户体验至关重要。个性化涉及根据用户的偏好、行为和上下文定制对单个用户的响应，使互动更加吸引人和相关。可扩展性确保这些个性化体验可以高效地维护在一个庞大且多样化的用户群体中，而不会显著增加成本或降低性能。

实现这种平衡的一种有效方式是通过实时上下文感知。虚拟助手可以通过整合实时数据，如用户的当前位置、一天中的时间或正在进行的活动，动态调整其响应。例如，旅行助手可以根据用户是否在机场或在家中浏览提供建议。实时上下文感知增强了个性化，同时保持了可扩展性。

创建相关响应的一个重要方式是通过查看用户的历史和偏好。通过分析过去的互动、购买历史、常见问题以及某人通常的沟通方式，虚拟助手可以改进其响应，更好地满足用户的需求。例如，如果用户经常询问素食食谱，助手可以在未来的互动中优先考虑素食选项，使体验感觉更加直观和个性化。

在实施利用大型语言模型（LLMs）的聊天机器人时，一个主要挑战是有效地区分简单和复杂查询以优化计算资源。为了保持响应性和成本效益，系统必须用快速、简洁的响应处理简单查询，避免在基本互动上使用不必要的处理能力。这允许计算资源被分配到最需要的地方——为更复杂的请求生成高度个性化的响应。

然而，复杂的分步查询需要更深入的理解和更复杂的处理。这些查询通常涉及多个层次的上下文和顺序信息，系统必须准确解释和整合。未能充分解决这些复杂交互可能导致响应不完整或不准确，导致用户沮丧并降低对系统能力的信任。

虽然 RAG 通过获取相关信息增强了聊天机器人的能力，但它有一个关键限制：它并不完全理解交互的深层需求和上下文。RAG 主要关注获取正确的信息，而没有真正掌握用户意图和上下文的细微差别。这种方法可能导致聊天机器人提供准确的数据，但未能满足客户对问题解决和自主任务执行的需求。用户越来越期望聊天机器人主动管理和解决他们的请求，而不仅仅是简单的信息检索。

小贴士：将 RAG 与其他技术，如上下文感知框架相结合，构建一个从仅仅反应到真正互动和自适应的聊天机器人。这种混合方法允许聊天机器人利用 RAG 在信息检索方面的优势，同时结合更深入上下文理解和自适应响应的能力。

技术上，这涉及到将 RAG 的强大检索机制与高级自然语言处理、语义理解和上下文分析功能相结合。例如，虽然 RAG 可以从庞大的数据库中检索必要的数据，但其他组件可以解释用户的情感语调、历史互动和实时上下文，以生成准确、富有同理心和与用户当前情况相关的响应。

这种组合使聊天机器人能够根据用户需求动态调整其交互风格。例如，如果用户提出一个简单的事实性问题，聊天机器人可以使用 RAG 快速提供答案。然而，如果用户显得困惑或需要进一步的帮助，负责上下文感知的组件可以提供解释和额外的资源，甚至可以自主执行任务。

实施这个混合系统需要一个复杂的架构，其中 RAG 负责信息的初始检索，而其他组件则根据上下文线索处理和细化这些信息。这种方法确保聊天机器人能够处理从简单查询到复杂问题解决场景的广泛交互，从而将用户体验提升到一个新的参与和满意度水平。

9.3.3 维护和更新自适应流程

在虚拟助手（尤其是使用 RAG 的助手）中维护和更新自适应流程对于确保长期准确性、相关性和用户满意度至关重要。随着用户交互的发展，持续改进系统以适应新上下文并给出准确响应非常重要。就像静态流程一样，必须监控用户交互以收集有关自适应流程表现情况的见解。然后，可以对聊天机器人进行迭代调整，确保它符合用户期望和需求。

由于 RAG 依赖于实时检索信息，因此 RAG 使用的数据库和信息源必须定期更新。过时的数据可能导致不准确响应，损害用户信任。需要频繁更新知识库，纳入来自可信来源的最新信息。这对于信息变化迅速的领域尤为重要，如新闻、健康和技术。

系统必须在整个对话中跟踪和更新上下文。保持上下文不仅意味着记住过去的交互，还要根据新信息调整响应。这需要高级自然语言处理（NLP）能力和复杂的数据结构，使助手能够识别上下文线索（如对先前消息的引用）并相应地更新其内部状态。上下文感知算法帮助助手提取和解释相关细节，即使它们分散在多个交流中。通过动态管理上下文，助手确保响应既准确又相关，从而提高整体用户体验。

有效的情境管理还涉及适应用户意图的实时变化。助手必须识别用户偏好何时发生变化，并相应地调整其理解。例如，如果用户最初询问预算旅行选项，但后来提到对豪华住宿的偏好，助手应相应调整其推荐。实现动态情境管理机制涉及使用能够随时间学习和预测用户偏好的机器学习模型，并纳入反馈循环以完善助手的情境理解。这种适应性对于保持响应和连贯性至关重要，使虚拟助手成为用户更有效、更直观的工具。

通过实施本章概述的策略，你可以确保虚拟助手的自适应流程保持准确、相关和响应于不断变化的需求。关键最佳实践包括保持实时情境感知、使用用户历史和偏好，以及确保对变化输入的动态适应。此外，RAG 通过基于检索到的信息提供情境相关响应，显著增强了虚拟助手。然而，如前所述，RAG 本身并不足够。有效的系统必须将其与更深入的情境理解、任务执行能力和与客户数据对齐的模型集成。通过调整语言模型以反映用户特定的信息和偏好，虚拟助手可以提供更精确、可操作和个性化的响应。定期的维护和更新对于高性能和用户满意度至关重要。遵循这些原则，虚拟助手可以提供更有效、直观和吸引人的交互。

练习

1. 设计具有情境感知的虚拟助手交互。选择一个虚拟助手的场景，例如预订旅行计划或提供客户支持。然后，创建一个对话流程，展示虚拟助手如何记住过去的交互并适应新的信息。你的对话流程应包括至少五个用户交互，并说明以下内容：

   • 助手如何跟踪和维护情境（例如，记住用户偏好或过去的问题）

   • 当用户提供新细节时，如何动态更新情境

   • 这如何通过使交互更流畅和更相关来改善用户体验

在你的流程结束时，解释虚拟助手如何在整个对话中管理情境，以及为什么这种方法增强了连贯性和可用性。

1. 2. 设计一个可扩展的虚拟助手架构，包括数据存储、处理和检索机制。

摘要

• 理解和利用情境信息，如用户位置、过去交互和偏好，对于提供个性化、相关响应和增强整体用户满意度至关重要。

• 设计能够有效处理文本、语音、视觉和多模态交互的虚拟助手，确保用户获得更吸引人和多功能的体验。根据每种模态的优势定制交互设计是满足多样化用户需求的关键。

• 将检索增强生成（RAG）与自适应流设计相结合，使得虚拟助手能够检索准确信息并生成上下文相关的响应。这种混合方法增强了助手有效管理简单和复杂查询的能力。

• 实施强大的动态上下文管理机制，使得虚拟助手能够在交互过程中维护和更新上下文。这种能力对于提供连贯、相关的响应以及实时适应用户不断变化的需求至关重要。

• 定期监控、反馈整合、自适应学习和性能优化对于保持自适应流的准确性和相关性至关重要。确保随着对话的进行，RAG 响应保持准确和上下文相关，对于维持高用户满意度至关重要。

第十章：使用生成式 AI 减少复杂性

本章涵盖

• 使用生成式 AI 设计和改进流程

• 用 LLM 判断替换歧义对话流程

• 使用生成式 AI 作为“用户”测试静态对话流程

设计一个满足所有利益相关者需求和愿望的面向流程的机器人很困难。相互竞争的优先级可能导致“委员会设计”，从而引入复杂性。而且，好心的人可能会设计出阻碍主要对话流程的边缘情况。这些复杂性会给您的用户带来负担，并使他们更有可能在使用机器人时放弃或失败。生成式 AI 可以帮助您检测和改进这些场景，帮助您去除复杂性并提高机器人的成功率。

流程构建者通常要求用户提供过多的信息。（信息越多越好，对吧？不是如果它导致聊天机器人失败的话！）有几种方法可以使用生成式 AI 改进流程：

• 使用生成式 AI 提出关于如何构建流程的建议。

• 如果您的流程已经构建，请使用生成式 AI 提出改进建议。它还可以通过充当用户来测试流程。

• 用大型语言模型（LLM）驱动的流程替换一些静态流程。

我们将首先探讨医疗保险提供商的索赔状态流程。然后我们将看到生成式 AI 如何帮助我们设计和改进这个流程以及其他流程。

10.1 构建时 AI 辅助流程

图 10.1 展示了流程的最简单视图。

图 10.1 流程的高级视图。它由识别特定意图启动，包括一个或多个顺序步骤，并以流程完成（满足意图）结束。

我们的示例流程涉及医疗保险客户通过聊天机器人查询索赔状态。起初，这个过程听起来像是一个简单的查找，但它有几个标准需要满足：

• 意图检测——确定用户的意图是“索赔状态”。这启动了一个包含多个步骤的流程。

• 流程开始——收集完成索赔状态流程所需的信息：在这种情况下，需要搜索索赔的信息。

• 流程中间——使用收集到的信息执行某些操作。在这个例子中，就是搜索用户的索赔。

• 流程结束——通过向用户提供索赔状态来完成流程。

整个索赔流程在图 10.2 中展示。

在第五章中，我们展示了如何改进聊天机器人的意图分类器以检测和理解用户的意图。在本章中，我们将专注于改进其余的流程，以成功实现用户的意图。

图 10.2 可视化索赔状态流程

10.1.1 使用生成式 AI 生成对话流程

对话式人工智能流程通常基于现有的工作流程。这个流程可以从另一个渠道、网络应用程序或呼叫中心脚本中复制。对于我们的索赔状态示例，让我们假设没有现有的流程可供工作。我们可以使用 LLM 来帮助我们设计目标工作流程。

以下列表显示了一个 LLM 提示的示例。

列表 10.1 设计医疗保险索赔状态流程的提示

Instruction: You are a conversational designer.  #1
↪You are building a chatbot to help users find  
↪information about their insurance claims. 
↪Insurance claims include the following information:  
↪a claim date, a member ID, a claim amount, and a 
↪claim status. 
Design a dialogue flow to help users find their claim. #2
↪The dialogue flow should be as brief as possible and   #2
↪easy for the users to complete.  #2
Describe why you have constructed the dialogue flow this way.  #2

Output:  #3

1 场景和背景

2 详细指令

3 输出提示

我们必须为任务提供 LLM 几条信息：

• 场景/背景——LLM 应该了解任务背后的场景（“你是一位对话设计师”）。LLM 还应提供背景假设，例如关于医疗索赔可用的信息。

• 指令——LLM 必须设计一个对话流程，以尽可能简短和容易的方式实现用户目标（找到索赔），同时描述其“推理”，这将帮助我们评估输出。

• 提示——提示“输出”让 LLM 知道指令已完成。

小的变化可能造成大的差异

LLM 可能会对非常相似的提示给出显著不同的答案。即使是格式更改，如添加空格或包括或省略换行符，也可能导致主要输出变化。本书中使用的确切提示包含在本书的 GitHub 网站上，网址为 github.com/andrewrfreed/EffectiveConversationalAI。

以下列表显示了当提示在指令中使用三行时（以“指令”、“设计”和“描述”开头的行）的输出。

列表 10.2 mixtral-8x7b-instruct-01 为索赔状态流程生成的输出（较少换行）

The dialogue flow for the insurance claim chatbot would 
look like this:

1\. User: Hi, I want to check my insurance claim.  #1
2\. Chatbot: Sure, I can help you with that. Can you   #1
please provide me with your member ID?  #1
3\. User: My member ID is 123456\.  #1
4\. Chatbot: Thank you. Now, can you tell me the date   #1
of your claim?  #1
5\. User: The claim date is January 10, 2022\. #1
6\. Chatbot: Got it. And can you tell me the claim  #1
 amount? #1
7\. User: The claim amount is $1000\.  #1
8\. Chatbot: Thank you. I have all the information I #1
 need. Let me check the status of your claim.  #1
9\. Chatbot: The status of your claim is approved and   #1
the amount of $1000 has been paid.  #1

The dialogue flow is designed to be brief and easy for   #2
the users to complete. The chatbot starts by asking for  #2
the member ID, which is the most important piece of   #2
information needed to identify the user's claims. The   #2
chatbot then asks for the claim date and the claim   #2
amount, which are necessary to locate the specific   #2
claim. By asking for the information in this order, the   #2
chatbot can quickly and efficiently retrieve the user's   #2
claim information. #2
#2
Additionally, the chatbot confirms the claim information  #2
with the user before checking the claim status. This   #2
reduces the chances of errors and ensures that the user  #2
receives accurate information. The chatbot also provides  #2
clear and concise instructions throughout the   #2
conversation, making it easy for the user to follow   #2
along and complete the process. #2
#2
Overall, the dialogue flow is designed to provide a   #2
seamless and efficient user experience, while also    #2
ensuring the accuracy and reliability of the   #2
information provided. #2

1 样本对话，包括聊天机器人和用户的消息

2 设计过程说明

LLM 设计了一个双向样本对话，展示了机器人和用户可能会说的话。这很好——这有助于可视化一个完整的对话看起来是什么样子。我们应该意识到这只是一个样本——用户可能会以多种方式对这些问题做出回应。让我们回顾一下与 LLM 的交流中发生了什么：

• 我们告诉 LLM 索赔有一个成员 ID、日期、金额和状态。它推断出状态是输出，其他三个数据点是输入。

• LLM 设计了一个流程，按顺序收集所有三个数据点。

• 生成的对话礼貌且有用。机器人用“谢谢”来认可用户的输入。它还向用户提供了关于每个步骤中期望的内容的明确指令。

有趣的是，根据我们在提示中使用换行符的方式，我们会得到非常不同的输出。以下列表显示了使用六行（在指令中的每个句号后都有一行新内容）的提示的输出。

列表 10.3 mixtral-8x7b-instruct-01 为索赔状态流程生成的输出（更多换行）

1\. The dialogue flow starts with a greeting and an introduction to the chatbot's purpose. 

   Chatbot: Hello! I'm here to help you find information about your insurance claims. May I have your member ID, please?

   Rationale: By starting with a greeting and an introduction, the user is made aware of the chatbot's purpose and what they can expect from the conversation. Asking for the member ID first helps to identify the user's account and narrow down the search for their claim.

2\. After the user provides their member ID, the chatbot confirms the member ID and asks for the claim date.

   Chatbot: Thank you for providing your member ID. To help you find your claim, could you please tell me the date of the claim?

   Rationale: Confirming the member ID ensures that the chatbot has the correct information and helps to build trust with the user. Asking for the claim date next helps to further narrow down the search for the user's claim.

3\. After the user provides the claim date, the chatbot confirms the claim date and asks for the claim amount.

   Chatbot: Thank you for providing the claim date. Just to confirm, the claim amount was [insert claim amount]. Is that correct?

   Rationale: Confirming the claim date and amount helps to ensure that the chatbot has the correct information and reduces the likelihood of errors.

4\. After the user confirms the claim amount, the chatbot provides the claim status.

   Chatbot: Great, the claim amount is correct. The status of your claim is [insert claim status]. Is there anything else I can help you with?

   Rationale: Providing the claim status is the ultimate goal of the conversation, and it is important to provide this information as soon as possible. By asking if there is anything else the user needs, the chatbot is able to provide additional assistance if necessary.

Overall, this dialogue flow is designed to be brief and easy for the user to complete. By asking for the most important information first (member ID and claim date), the chatbot is able to quickly narrow down the search for the user's claim. Confirming the member ID, claim date, and claim amount helps to ensure that the chatbot has the correct information and reduces the likelihood of errors. Providing the claim status is the ultimate goal of the conversation, and the chatbot is able to provide this information as soon as possible. Finally, by asking if there is anything else the user needs, the chatbot is able to provide additional assistance if necessary.

列表 10.3 的输出相当不同。首先，样本对话和理由是交织在一起的。对话的每一步都有一个描述、一个示例聊天机器人消息和详细的理由。其次，样本对话只包括机器人消息。我们没有看到用户响应。第三，这个过程流程暗示在收到用户每条数据后都有确认语句。最后，样本对话中包含一些小错误。指令 3 表示它将询问索赔金额，但对话显示它确认了索赔金额而没有收集。

两个提示一起为我们提供了构建对话流程以实现索赔状态流程的许多想法。由于列表 10.2 更加完整，我们将使用它作为基准。尽管它相当不错，但生成的流程似乎有点冗长。我们能改进流程吗？当然可以！让我们询问 LLM 如何改进。

10.1.2 使用生成式 AI 改进对话流程

我们可以要求 LLM 改进流程，无论它们是由 LLM 还是人类生成的。让我们改进列表 10.2 中的流程，这是我们通过 LLM 生成的，以帮助用户了解他们的索赔状态。

当前构建的流程需要三个信息点：会员 ID、日期和索赔金额。这满足了一些基本要求，例如通过会员 ID 验证呼叫者并提供搜索条件（会员 ID、日期和金额）。然而，这可能会给用户带来不便。根据直觉，似乎会员 ID 加上更多信息可以唯一标识索赔。让我们询问 LLM 如何简化流程。

列表 10.4 要求 LLM 改进列表 10.2 中的对话流程

<<Listing 10.1 prompt>>  #1
<<Listing 10.2 output>>  #2

Instruction: Simplify the dialogue flow above. Only  #3
require the user to provide two pieces of information. 

Output:  #4

1 列表 10.1 的完整内容包含在提示中，但为了简洁起见，此处省略。

2 列表 10.2 的完整内容包含在提示中，但为了简洁起见，此处省略。

3 对 LLM 的轻量级指令

4 输出提示

“改进”提示的本质很简单。我们通过包含我们过去对话的完整历史（原始提示及其响应）来模拟与 LLM 的对话。然后，我们提供一个基本指令（“简化上述对话流程”）以及简化的定义（“只要求用户提供两份信息”）。此提示的输出如下所示。

列表 10.5 LLM 提供的简化对话流程和理由

The simplified dialogue flow for the insurance claim chatbot would look like this:

1\. User: Hi, I want to check my insurance claim.
2\. Chatbot: Sure, I can help you with that. Can you   #1
   please provide me with your member ID and the claim   #1
   date?  #1
3\. User: My member ID is 123456 and the claim date is January 10, 2022.
4\. Chatbot: Thank you. I have all the information I need. Let me
   check the status of your claim.
5\. Chatbot: The status of your claim is approved and   #2
   the amount of $1000 has been paid.  #2

The simplified dialogue flow only requires the user to provide two 
pieces of information: the member ID and the claim date. This reduces
the number of steps in the conversation and makes it even easier for
the user to complete. The chatbot can use the member ID to identify
the user's claims and the claim date to locate the specific claim.

By asking for both pieces of information at once, the chatbot can 
streamline the conversation and provide a more efficient user 
experience. The chatbot still confirms the claim information with 
the user before checking the claim status, ensuring the accuracy 
and reliability of the information provided.

Overall, the simplified dialogue flow is designed to provide a quick
and easy user experience, while still ensuring the accuracy and 
reliability of the information provided.

1 第 2 步现在在一次操作中收集所有信息。

2 第 5 步将索赔金额从输入参数转换为输出参数。

我们看到 LLM 提出了两个建议：首先，不要询问索赔金额；其次，将两个问题合并为一个。让我们详细审查它们：

• 移除索赔金额——会员 ID 和索赔日期是两个最“独特”的数据元素，也是用户最有可能拥有的。它们也是最容易在网页或电话机器人中输入的，大多数聊天平台都有接受 ID 和日期的库。聊天机器人还会在读取时通知呼叫者索赔金额。

• 一次性提出两个问题——新的流程将会员 ID 和索赔日期合并为一个问题（步骤 2）。这对于希望尽可能减少步骤的资深用户来说非常出色。对于只有一条信息可用且需要帮助找到第二条信息的用户来说，这可能更具挑战性。对于聊天机器人来说，在一次对话中接受这两条信息是好的，但可能不是强制要求的最佳选择。

主题专家或 LLM？

我们建议在生产任何解决方案之前使用主题专家（SME）的建议。LLM 非常适合生成想法和快速测试想法。使用 LLM 探索可能的艺术，并快速起草潜在解决方案。

在一个简单的提示中，我们生成了两种改进对话流程的建议。你能想到其他改进对话流程的方法吗？你会给 LLM 什么样的指令？

练习

1. 尝试使用列表 10.4 中的替代指令：

   • 每次只向用户询问一条信息。

   • 引导一个说“我没有”的用户回答其中一个问题。

   • 引入额外的参数，例如索赔 ID，并查看机器人如何生成额外的流程变体。

2. 使用 LLM 为不同的场景生成流程，例如这些：

   • 预订航班

   • 购买电影票

   • 推荐度假目的地

或者使用你正在构建的聊天机器人中的一个场景！

10.2 运行时 AI 辅助流程

使用生成式 AI 构建流程设计一直是个不错的选择。到目前为止，这些流程都是相对静态的，适用于传统的对话式 AI 解决方案。索赔状态是一个“槽填充”搜索的例子，我们通过对话过程收集完成任务所需的信息。这通常表现为收集 API 调用所需的参数。这需要对问题和答案响应进行仔细的映射到 API 上。然后，答案被填充到 API 参数中，直到 API 可以执行。槽填充是最受欢迎的对话式流程模式之一。

在这些流程中，是否应该将更多控制权交给 LLM？

10.2.1 使用生成式 AI 执行对话流程

我们之前的过程流程是静态设计的。让我们尝试一些不同的方法。我们只描述流程，让 LLM 在实时对话中决定要问什么问题。图 10.3 显示了我们将如何将 LLM 纳入收集索赔搜索 API 信息的过程。

图 10.3 对话式 AI 如何使用 LLM 决定下一个要问的问题

我们在聊天机器人中假设了一些逻辑：

• 当它检测到状态意图声明时，它让 LLM 决定下一个要问的问题。

• 当它检测到 LLM 以变量列表的形式响应时，它重新获得控制权并执行声明搜索。

• 它使用像预分类器这样的护栏来确保发送给 LLM 的数据不是恶意的，比如“忽略所有之前的指令并<做些坏事>。”

下面的列表演示了 LLM 逐步生成对话。

列表 10.6 让 LLM 决定询问声明状态的问题

Instruction: You are a conversational designer. You  #1
are building a chatbot to help users find information  #1
about their insurance claims.  #1
Insurance claims include the following information: a   #1
claim date, a member ID, and a claim amount.  #1
Generate conversational responses until you have  #2
collected all three pieces of information.  #2
When you have all the information, respond with a   #2
payload in this format:  #2
{"memberID": "(the member id collected)", "claimDate":   #2
"(the claim date collected)", "claimAmount":   #2
"(the claim amount collected)"} #2

System: How can I help you?  #3
User: I need information on my claim.  #3
System:  #4

1 与之前的提示相似的指令

2 新任务的描述

3 假设对机器人的静态问候，我们输入机器人的初始问候和用户的第一次发言。

4 输出提示

这个简单的提示就足以让机器人为我们生成一些对话。（我们只用了几分钟就写了这个提示。）接下来的几个列表显示了提示的连续迭代输出。下面的列表显示了第一个轮次，使用了列表 10.6 的输出。

列表 10.7 第 2 轮对话轮次输出（LLM 生成下一个问题）

<<Listing 10.6 repeated>>  #1
System: I can help you with that. What is your member   #2
ID?  #2

1 此处包含之前的列表

2 来自第一个提示的输出

到目前为止，机器人做得很好。它决定首先询问成员 ID。让我们看看当用户响应时它会做什么。

列表 10.8 第 2 轮对话轮次输出（LLM 生成下一个问题）

<<Listing 10.7 repeated>>  #1
User: 1234567  #2
System: What is your claim date?  #3

1 此处包含之前的列表

2 将用户的响应从聊天机器人传递给 LLM

3 LLM 的响应

这又是一个合理的回应。LLM 在没有除了初始提示之外的任何指导的情况下表现良好。回应有点重复——两个问题都采用了“你的是什么”的形式。让我们看看对话的其余部分。

列表 10.9 显示第 3 和第 4 轮对话的会话输出

<<Listing 10.8 repeated>>  #1
User: May 4, 2024  #2
System: What is your claim amount?  #3
User: $1000  #4
System: "memberID": "1234567", "claimDate":  #5
"May 4, 2024", "claimAmount": "1000"

1 此处包含之前的列表

2 将用户的响应从聊天机器人传递给 LLM

3 LLM 提出最后一个问题

4 将用户的最终响应从聊天机器人传递给 LLM

5 LLM 生成聊天机器人可以用于搜索的有效负载

在对话流程结束时，LLM 已经完成了我们所需要的一切。它提出了问题，而没有使用硬编码的对话，并且它生成了一组我们可以传递给声明搜索 API 的参数集。（它没有生成有效的 JSON，但它可能从更好的提示中学会这样做。）

在这个点上完全将控制权交给 LLM 可能会很有诱惑力。在我们这样做之前，让我们看看 LLM 在不同场景下的反应。这次，用户不知道系统需要的一切。LLM 会如何反应？下一个列表演示了这个场景。

列表 10.10 当用户没有所有信息时的 LLM 生成响应

Instruction: You are a conversational designer. You are building a chatbot to help users find information about their insurance claims.
Insurance claims include the following information: a claim date, a member ID, and a claim amount.
Generate conversational responses until you have collected all three pieces of information.
When you have all the information, respond with a   #1
payload in this format: {"memberID":   #1
"(the member id collected)", "claimDate":   #1
"(the claim date collected)", "claimAmount":   #1
"(the claim amount collected)"}  #1

System: How can I help you?  #2
User: I need information on my claim.  #2
System: I can help you with that. What is your member   #2
ID?  #2
User: I don't know it.  #3
System: What is your claim date?
User: I don't know that either.  #3
System: What is your claim amount?
User: $1000
System: I can help you with that. What is your member  #4
ID?  #4

1 与之前示例中相同的指令

2 与之前示例中相同的初始对话

3 用户不知道一些信息

4 LLM 卡住了！

哎呀！在这个提示中，LLM 没有错误处理的概念。看起来 LLM 会不断地提问，直到用户因沮丧而结束聊天。用户可能也无法退出这个聊天。显然，这种方法有一些局限性。

提出多个问题以完成搜索过程并不总是成功的。让我们尝试其他方法。如果我们让 LLM 进行搜索会怎样？

10.2.2 使用 LLM 进行搜索过程

在医疗保险等场景中，仔细搜索至关重要。医疗服务提供者可能在其患者群体中有数百（或更多）未结索赔。严格的搜索标准对于成功的搜索至关重要，更不用说法律要求了。让我们想象一个搜索选项更少的不同场景。

这不是检索增强生成（RAG）吗？

有点像。我们正在根据结构化 API 的输出创建文本“段落”，并让 LLM 对它们进行推理。纯粹主义者可能不会称之为 RAG，但它有相似之处。最重要的是，无论你叫它什么，它都是你工具箱中的一个有用工具。

我们的示例场景是消费者检查他们的银行账户余额。消费者通常在一家银行有 1 到 4 个账户。聊天机器人需要知道用户询问的是哪个账户。只有少数几项元数据与账户相关，包括类型（支票或储蓄）、所有者（单独或共同）和 ID（尽管所有者可能不记得它）。

假设用户已经登录到我们的聊天机器人（我们可以通过他们的登录用户 ID 或验证过的电话号码知道他们是谁）。他们询问账户余额，聊天机器人向 LLM 寻求帮助。流程图如图 10.4 所示。

图 10.4 使用 LLM 处理用户响应

我们可以想象用户向助手提出以下问题：

• 我的账户里有多少钱？

• 我在储蓄账户里有多少钱？

• 我们共同储蓄账户里有多少钱？

• 我儿子的账户里有多少钱？

• 我刚开设的账户里有多少钱？

提示和示例输出如下所示。此提示以任何空白字符（空格或换行符）为停止条件执行。否则，LLM 将继续输出，并对其选择进行说明。

列表 10.11 使用 LLM 进行搜索

<|instruction|>
You are supporting a digital assistant. A user is asking a question  #1
about one of their bank accounts. Use the contextual information #1
provided to identify the bank account they are most likely asking about. #1

<|user|>
How much money is in my son’s account?   #2

<|context|>
User Name: Bob
Accounts: [ {"id":12345, "type":"checking", "owners":["Bob","Jane"],  #3
 "opened":"12/25/2000"}, {"id":23456, "type":"saving",  #3
"owners":["Bob","Jane"], "opened":"1/3/2005}, {"id":34567,  #3
"type":"saving", "owners":["Bob","Jack"], "opened": "2/4/2024"}] #3

<|output|>
Account id: 34567   #4

1 作为提示提供的基本指令

2 将用户的输入直接传递给 LLM

3 LLM 接收已登录用户的上下文和所有账户的元数据

4 输出提示和输出

太棒了！LLM 可以回答所有五个问题。表 10.1 显示了 LLM 的响应。回想一下，我们只要求 LLM 选择账户 ID。聊天机器人仍然将调用最终的“检查余额”API 调用并制定最终的响应。

表 10.1 列表 10.11 的几个不同输入问题的响应

问题	响应（账户 ID）
我的账户里有多少钱？	12345
我储蓄账户里有多少钱？	23456
我们共同储蓄账户里有多少钱？	23456
我儿子的账户里有多少钱？	34567
我刚刚开设的账户里有多少钱？	34567

我们可以做出几个观察：

• 可变性——我们处理了包括日期、类型和所有者在内的几个不同的搜索标准，而没有提出任何澄清问题。

• 灵活性——像“我的儿子”或“我刚刚开设的账户”这样的标准无需严格的 API 参数即可处理。

• 默认选择——对于两个模糊的问题（“我的账户”）和（“我们的共同储蓄账户”），机器人选择了第一个匹配的选择。这表明排序顺序很重要。

LLM 提供了不可思议的灵活性！如果风险足够低，让 LLM 搜索是一个绝佳的策略。假设我们的输出信息类似于“您的<类型>账户，ID 为，余额为”，那么 LLM 没有提出澄清问题可能也是可以接受的。机器人总是以准确的信息和证据进行回应。如果用户需要不同的信息，他们仍然可能会问后续问题，比如“不，我是指我的储蓄账户余额”。

让 LLM 选择账户 ID 安全吗？关于幻想又如何？

在消费者检查银行账户余额的例子中，我们通过将 API 调用与 LLM 判断分离来引入安全性。一个典型的“获取余额”API 将有两个参数：用户 ID 和账户 ID。在这种情况下，我们只让 LLM 选择账户 ID。因此，我们防止了 LLM 幻想出一个用户 ID 和账户 ID 组合，从而泄露他人的账户信息。如果 LLM 幻想出一个账户 ID，API 调用将失败；如果 LLM 为该用户选择了错误的账户，至少他们会听到自己账户中的一个。在假设设计实现是安全之前，务必彻底测试你的设计和实现。

当让 LLM 执行 API 调用时，应使用这种以安全性为导向的设计。

带有 LLM 的生成式 AI 为我们提供了增强聊天机器人的有趣可能性。我们需要仔细平衡实现速度和控制之间的权衡。但是，LLM 支持在传统聊天机器人中难以或不可能实现的事情。

练习

1. 更新列表 10.6 中的提示，以提供更多样化的响应（不仅仅是“你的”）。

2. 更新列表 10.11 中的提示，以便当用户的提问模糊时，LLM 给出类似“n/a”的哨兵值。你可以在提示中给出额外的指令或添加几个示例供 LLM 学习。

10.3 测试时的 AI 辅助流程

在前面的章节中，我们使用了生成式 AI，通过让 LLM 充当聊天机器人来设计或实现聊天解决方案。在本节中，我们将颠覆这种范式。我们将使用 LLM 生成典型或“创意”的回复，并观察聊天机器人在我们的保险索赔场景中如何处理这些回复。这种概念化的流程如图 10.5 所示。

图 10.5 测试脚本如何调用 LLM 作为聊天机器人“用户”的流程图

我们需要三样东西来组合这个测试脚本：一个通用的提示，让 LLM（大型语言模型）充当用户，一个测试脚本以调用聊天机器人和 LLM，以及一个用于审查结果的方法。

让我们开始吧。

10.3.1 设置生成式 AI 作为用户

LLM 需要三块信息才能成为一个有效的用户：任务的通用说明、我们需要测试的场景描述以及到目前为止的对话。

首先，让我们提供一些简单的背景信息，告诉 LLM 我们希望它在持续的对话中模仿一个用户。指令可以非常简单：

Act as a user of a telephone-based medical insurance chatbot. Continue the conversation with a likely response.

这个指令描述了我们希望 LLM 做的基本内容。我们告诉 LLM 以用户身份回应，而不是系统。我们不向 LLM 提供进一步的指导。

第二，我们希望 LLM 能够处理不同的场景。我们需要一个可适应的提示。以下是我们想要测试的几个场景：

• 用户拥有他们需要的所有信息（会员 ID、索赔日期、索赔金额）。

• 用户缺少一些必要的信息。

• 用户缺少一些必要的信息，但有替代方案（一个索赔 ID）。

对于每个场景，我们将对提示提供略微不同的指导。表 10.2 将一些场景映射到我们可以提供给 LLM 的详细指导。

表 10.2 场景描述和可提示的指导

描述	指导

| 用户拥有他们需要的所有信息 | 你正在试图找出你是否支付了你的医疗索赔之一。你知道你的会员 ID 是 123456，索赔日期是 2024 年 5 月 4 日，索赔金额为 1000 美元。

|

| 用户缺少一些必要的信息 | 你正在试图找出你是否支付了你最近的医疗索赔。你知道你的会员 ID 是 123456，但不知道其他任何信息。

|

| 用户缺少一些必要的信息但有替代方案 | 你正在试图找出你是否支付了你最近的医疗索赔。你知道你的会员 ID 是 123456，索赔 ID 是 987654321987654。

|

表 10.2 中的指导包含以下 LLM 可以在对话中使用的信息：

• 场景——LLM 应该尝试做的事情，例如找出是否支付了索赔。

• 测试数据——我们知道聊天机器人可以调用 API，因此我们需要 LLM 提供存在于我们系统中的数据。我们明确地给出 LLM 我们希望它使用的信息。

• 边界——我们告诉 LLM 它不知道的内容。这应该防止 LLM“发明”（产生幻觉）信息，这些信息将导致我们后续的 API 调用失败。

我们没有提供 LLM 任何其他指导。我们想看看它如何在聊天机器人中尝试实现这些结果。

最后，我们需要向 LLM 提供对话记录，以告知它如何响应下一个（以及它已经响应了什么）。测试脚本将能够跟踪记录，因为它正在调用聊天机器人和 LLM。（有许多方法可以收集聊天记录，第十二章将演示更多方法。）

我们现在可以构建一个 Python 函数来为给定场景生成提示。该函数接受两个参数：场景的指导（如表 10.2 所示）和对话记录。下一个列表展示了该函数。

列表 10.12 构建测试场景提示的 Python 函数

def get_prompt(guidance, transcript):
   prompt=f'''
INSTRUCTION:
You are a user trying to find out your claim status. #1
{guidance}  #2
Continue the conversation with a likely response.  #1

CONVERSATION:
{transcript}  #3
User: '''  #4
   return prompt

1 任务的通用描述

2 特定场景的指导和测试细节

3 注入对话记录

4 LLM 响应的提示

这段代码的功能动态地为给定场景和对话记录构建提示。

列表 10.13 展示了如何调用get_prompt()函数。它假设有一个call_llm()函数，其实现将根据 LLM 平台而异（假设它通过 API 密钥启动，允许你选择模型和配置设置，然后提供一个接收提示并返回输出的函数）。确保在你的call_llm()函数中使用采样解码，以便在响应中获得多样性。

列表 10.13 使用动态提示的 Python 代码

guidance='''You are trying to find out if one of your  #1
medical claims was paid.  #1
You know your member ID 123456, claim date of May 4,  #1
2024, and the claim amount of $100.'''
transcript='''System: How can I help?
User: I need to check my claim status
System: What's your member ID?'''  #2

prompt=get_prompt(guidance, transcript)  #3
user_response=call_llm(prompt)  #4
transcript += f"\nUser: {user_response}"  #5

1 指导测试场景的全文

2 到目前为止的完整对话记录

3 动态构建提示

4 获取 LLM 响应（例如，“当然，我的会员 ID 是 123456”）

5 更新对话记录

我们现在有了测试脚本的第一个部分。让我们设置另一半。

10.3.2 设置对话测试

接下来，测试脚本必须调用聊天机器人。脚本将获取 LLM 生成的“用户”输入并将其传递给机器人。然后脚本将获取机器人的响应，将其附加到记录中，并再次调用 LLM。我们将再次依赖于这里未实现的功能（实现将根据平台而异）——在这种情况下，该功能是call_chatbot()。这个函数预期将配置与聊天机器人的连接，使用 API 密钥进行身份验证，并管理用户对话。

以下列表展示了测试脚本的这个部分。

列表 10.14 调用聊天机器人的 Python 代码

#user_response comes from LLM call
bot_response=call_chatbot(user_response)  #1
transcript += f"\nSystem: {bot_response}"  #2

1 向聊天机器人发送消息

2 将聊天机器人响应存储在记录中

我们现在可以将所有这些部分组合在一起。在下一个列表中，我们将所有元素组合成一个单独的测试脚本。

列表 10.15 结合 LLM 用户和聊天机器人调用的 Python 代码

def run_test(guidance):
   print(f"Running test with:\n{guidance}\n")
   bot_response = call_chatbot('')  #1
   transcript = f"System: {bot_response}"
   for i in range(4):  #2
      prompt=get_prompt(guidance, transcript)
      user_response=call_llm(prompt)
      transcript += f"\nUser: {user_response}"
      bot_response=call_chatbot(user_response)  #3
      transcript += f"\nSystem: {bot_response}"  #4
   print(f"Transcript:\n{transcript}")  #5

1 对话通常以“空白”输入开始。

2 测试对话的几个回合

3 将 LLM 的响应发送到聊天机器人

4 将聊天机器人的响应存储在记录中

5 在测试结束时打印记录

该脚本启动与聊天机器人的连接，并运行固定数量的回合（四个）。根据我们的测试需求，我们可以增加或减少这个数字，或者添加额外的逻辑来检测对话何时结束（或失败）。

下面的列表显示了在测试场景之一上运行此脚本的一些示例输出。

列表 10.16 测试脚本示例输出

Running test with:
You are trying to find out if one of your medical claims was paid.
You know your member ID 123456, claim date of May 4, 2024, and the 
claim amount of $1000.

Transcript:
System: How can I help you?
User: Hi, I'd like to check the status of a medical claim.
System: I can help you with that. What is your member ID?
User: Yes, my member ID is 123456.
System: What is your claim date?
User: My claim date is May 4, 2024.
System: What is your claim amount?
User: The claim amount was $1000.
System: Thank you. I have all the information I need. Let me check the status of your claim.
The status of your claim is approved and the amount of $1000 has been paid.

该脚本设置了 LLM 作为你的聊天机器人用户的基本机制。

这种测试是其他测试努力的优秀补充。LLM 可能会生成你从未考虑过处理的聊天机器人用户输入，了解你的聊天机器人如何响应它们是很好的。记住，LLM 只是在模拟人类——真实的人类可能永远不会像 LLM 那样行动或“说话”。但另一方面，他们可能会的。

练习

1. 扮演机器人的角色。使用以下代码实现call_chatbot(user_response)函数：

return input('Enter the bot response: ')

1. 这样可以让你测试 LLM（作为用户）对你（作为聊天机器人）发送的消息的反应。这可以让你不必仅为了测试脚本如何工作就实现一个聊天机器人。

2. 2. 将call_chatbot(user_response)函数连接到你正在构建的实际聊天机器人。将call_llm(prompt)函数连接到你的首选 AI 平台。更新get_prompt函数以更适合你的场景。LLM 是否扩展了你的聊天机器人的功能？

摘要

• LLM 可以从头开始为你设计流程。只需一点提示，它们就可以生成示例对话流程并证明它们的设计选择。然后，这个流程可以在传统的对话式 AI 中实现。

• LLM 也可以改进现有的流程。一个典型的改进是简化流程。

• 你可以使用生成式 AI 执行整个对话。在实现速度和控制之间有一个权衡。这在错误路径上尤为明显。

• 你可以用 LLM 驱动的流程替换一些槽填充过程流程。这比严格匹配 API 参数要灵活得多。

• 在让大型语言模型（LLM）做出判断时，要考虑错误带来的成本。寻找那些“错误”并不关键的情况。小心选择 LLM 可以影响的 API。

• LLM 可以模拟你的对话式人工智能的用户。使用它们来生成测试对话，展示你的系统在特定场景下可能的表现。

第四部分模式：减少摩擦

人们在与聊天机器人互动时的期望与与其他人类互动时的期望不同。人类可能在互动开始时互相闲聊，但聊天机器人通常直接进入正题。人类擅长处理误解，而聊天机器人有时，嗯，有点像机器人。

用户在互动开始之前可能对聊天机器人有个人偏见。在使用基于电话的 AI 时，他们可能会立即按下并长按 0 键（以联系客服）；在聊天机器人上，他们可能会反复输入“代表”。或者，他们可能会在 AI 出错后进行这种行为。在两种情况下，我们称之为退出——用户正在选择退出 AI 体验，并选择与人类进行互动。

第十一章深入探讨了为什么用户在互动的不同阶段从开始到结束选择退出，并提供了使退出可能性降低的技术。退出是无法消除的，因此第十二章展示了当它们发生时应该做什么，即以对人类代理有用的方式总结 AI 互动，以便他们可以在 AI 停止的地方继续互动。

第十一章：减少退出

本章涵盖

• 识别用户希望人工代理的原因

• 如何防止用户立即想要退出

• 如何保持用户对你的对话人工智能的参与度

• 使用生成式人工智能创建更友好的对话消息

• 决定何时涉及人工代理（以及何时不涉及）

“退出”一词指的是用户试图退出虚拟代理体验，通常是为了联系人工代理。你也可能看到这被描述为升级或归零（在电话拨号盘上按零以获取运营商）。退出可能会造成成本。聊天机器人是一项投资，它们必须证明在商业价值上的回报，才能保持其可行性。由于退出过多导致的控制损失可能会使业务案例失败。

用户可能会出于各种原因选择退出，通常需要不同的策略和方法来解决。无论你管理的是哪种类型的机器人，无论是语音、文本、FAQ、面向流程的，甚至是路由代理，确定用户在对话中何时退出，都可以为你提供他们为何这样做的原因线索。了解用户为何退出将帮助你设计一种最小化退出的体验，这应该会提高你的控制率。

在本章中，我们将探讨一些因用户退出而遭受控制损失的对话人工智能解决方案，并讨论每个挑战是如何解决的。不同的用例可能需要不同的解决方案，这取决于组织的优先级、资源和限制，但有一些常见的模式和原则可以提高你的对话人工智能的价值，并使用户更有可能继续使用它。

11.1 什么驱动了退出行为？

一些用户遇到虚拟代理后，他们首先要求与人工代理交谈——甚至不尝试与对话人工智能互动。我们称之为立即退出。有时，用户最初会同意（选择加入）虚拟代理体验，但在对话的后期尝试退出。他们的理由通常与最初的退出驱动因素大不相同，这通常表明整体对话设计或流程中的某个特定步骤存在问题。理解不足也可能是根本原因。

11.1.1 立即退出的驱动因素

由于其本质，立即退出提供了非常有限的信息关于用户的原因。收集这方面的数据很困难，但可以通过调查或跟进代理升级（一个非常手动、耗时的工作）来获得。我们的研究揭示了导致这种行为的一些不同驱动因素，它们并不是相互排斥的。

前期对 IVR、聊天机器人或虚拟代理的糟糕体验

交互式语音响应（IVR）允许用户通过电话键盘或简单的语音命令与计算机交互。早期的 IVR 系统在 20 世纪 70 年代就已经存在，但在 21 世纪初，它们变得更容易部署，并且自那时起在现代世界中无处不在。你很难找到一个没有被公司问候语烦扰的人，这些问候语花了三十秒来告诉你如何使用他们的电话菜单。更糟糕的是，警告说“*非常重要，要听清所有选项”（因为他们的菜单可能已经改变）！

聊天机器人也与我们相伴已久，尽管成功让它们执行有功能性的任务是相对较近的事情，而且它们仍在向真正的虚拟助手发展。

用户可能无法区分 IVR、简单的聊天机器人或强大的虚拟助手。坦白说，他们并不在乎。先前的负面体验将使许多人反对自动化系统。甚至有一些互联网角落专门提供人们发现的“黑客”方法，以绕过自动化系统并直接连接到公司的真人代理队列。

用户认为他们的问题对机器来说太复杂

有时用户认为他们的情况非常独特或复杂，超出了自动化系统的能力。有时他们是对的；有时他们不是。对复杂性和独特性的判断是相对的，个人可能不知道有成千上万的人经历过类似的问题。这可能与以往的经验有关，但并不总是如此。

这些用户选择退出，因为他们认为无论如何他们最终都需要一个代理人。他们认为自动化系统是浪费时间，会延长或阻碍他们解决问题的道路。

倾向于人际互动

与其他人建立联系对我们这个物种的生存至关重要，因此有些人更愿意与真人打交道。他们的需求可能与解决方案的能力无关，可能包括孤独感、敏感或尴尬的话题、对机器和自动化系统的不信任、语言或可访问性障碍等。这正日益成为一种代际现象。老年用户更有可能选择退出，因为他们可能觉得与机器互动很困难，而数字原住民通常更容易导航自动化系统。无论年龄如何，你可能会始终有一些用户更喜欢人际互动。

11.1.2 后续退出的动机

在最初与虚拟助手互动后选择退出的用户通常是因为他们在特定的互动中遇到了困难。这些情况通常可以追溯到对话流程中的特定任务、动作或步骤，这使得识别根本原因变得稍微容易一些。

机器人无法理解用户的需求

当机器人不理解用户的请求时，用户可能会选择退出。这通常发生在对话的早期，但也可以在任何时候发生。

在将用户升级之前，允许一定数量的重试尝试是标准做法。平均值为三次，但你的用例可能有一个更高的或更低的阈值。这种做法是控制的关键工具，但用户对机器错误的容忍度可能低于人类，并且更少宽容。用户在被要求重复一次或两次后可能会选择退出，觉得机器人无法理解。

用户不理解机器人提出的问题

机器人提出的问题措辞不当可能会让用户感到困惑。用户可能不清楚机器人期望的响应类型或期望的格式。用户可能会要求机器人重复，但如果提出的是同样的问题，用户可能会仍然感到困惑。这会导致用户感到卡住，他们可能会要求一个真人来帮助他们摆脱困境。

用户没有或不知道所需的信息

如果要求用户提供他们没有的信息，他们可能会说“我不知道”或“我没有那个”，或者他们可能会简单地要求一个客服代表。如果任务流程无法在没有某些信息的情况下继续进行，且没有提供替代方案，用户就会知道他们没有客服代表的介入就无法达到目标。

用户感觉他们没有进展

如果用户觉得对话陷入循环、在菜单间跳转或已达到死胡同，他们可能会选择退出。这可能是因为你的对话逻辑中存在实际错误，或者是因为对话设计未能表明用户目标进展的情况。无论如何，他们都会感到沮丧，并寻找退出方式。

用户不喜欢答案或结果，或者他们对结果有不同期望

你的机器人可能提供技术上正确的响应，但仍然让用户不满意。他们可能会要求一个客服代表，希望达到不同的结果。他们也可能觉得信息不足，如果体验看起来没有提供后续跟进或额外请求的机会，他们可能会要求一个客服代表。

11.1.3 收集退出行为数据

为了确定你的解决方案是否因为退出而失去控制，你必须收集数据。一些对话平台提供了在对话期间报告所调用操作或任务的能力。它们也可能提供有关交互是否成功结束的数据。

有时，现成的分析工具不足以提供可操作的指标。在这些情况下，你可以在流程的关键点使用上下文变量来配置你的对话。良好的对话流程配置可以帮助你识别和优先考虑改进的区域。（你可能需要一个数据仓库和企业的或定制的报告工具来跟踪这些数据随时间的变化。）

对于一个复杂的任务导向型解决方案，你可能使用面包屑来标记主要流程和子流程的开始或完成。图 11.1 显示了请求代理发生的主要对话任务流程中分组退出的示例。

如果你的对话被配置为跟踪退出发生的确切步骤，你可以寻找趋势以帮助你揭示根本原因，如图 11.2 所示。

你可能会用这些信息做的第一件事，特别是对于像我们示例中的流程导向型机器人，是确定哪些任务流程被视为即时退出。一个简单的问答机器人可能只有初始问候。之后的所有内容都会被归类为“其他”退出。

图 11.1 按当前任务流程分解退出请求显示，即时退出（在初始问候任务流程中请求代理）比在这个自助、流程导向型机器人的对话旅程的任何其他部分都更频繁地发生。

图 11.2 按步骤分解退出发生情况有助于根本原因分析。在此图表中，即时退出在左侧突出显示，但趋势表明，在多个下游流程中收集地址详情可能也存在问题。

在我们的以流程为导向的机器人示例中，在初始问候任务流程中请求代理被视为即时退出——用户不愿意参与。所有其他退出都与对话中的某些其他任务流程相关联。图 11.3 显示了我们的示例机器人的退出请求，根据任务在完整对话流程中的位置。

图 11.3 高级流程图显示了用户在退出之前在过程中的深入程度。这些信息可以帮助进行根本原因调查。

本章的其余部分将专注于解决退出问题的策略，包括旨在减少初始退出、后续退出以及保持用户在渠道中的策略（退出保留）。

练习

反思一下你关于用户为何退出虚拟助手所学到的东西：

1. 你有能力区分即时退出和后续退出吗？

2. 你能否识别出对话流程中退出发生的模式？

11.2 减少即时退出

你可能听说过这样的话，“你永远没有第二次机会去留下第一印象。”立即退订是用户不满意的标志。你只有很短的时间来说服用户他们已经到达了正确的位置，并且你的虚拟助手是胜任的、有能力的和高效的。本节提供了减少用户立即要求代理的可能性。

在你的对话流程中，构成“立即退订”与“其他退订”之间的界限不是任意的，但它是灵活的。它可能发生在第一步或前几步。这种区分旨在确定对话流程中的某个点，用户有权利同意加入或尝试退订。对于一个 FAQ 风格的机器人，在非常第一次发言中请求代理将被视为“立即退订”，而之后的一切都将被视为“其他退订”。

以下三种策略将对减少立即退订产生最大的影响。

11.2.1 从良好的体验开始：问候和介绍

什么让用户对自动化交互感到满意？通用的客户服务原则适用：用户应该感觉到他们已经到达了正确的位置，他们处于良好的手中，并且他们的时间是宝贵的。

本章中我们讨论的第一个立即退订驱动因素是用户对 IVR、聊天机器人或虚拟代理的先前不良体验。你的机器人的问候或介绍将为对话体验定下基调。这是你赢得用户信任的机会——说服他们，你的虚拟代理在帮助用户达到目标方面可以像人类代理一样有效和高效。

在第一章中，我们预告了一个重大的改进，该改进解决了用户“立即退订”的挑战。我们与一家地区公用事业公司的虚拟助手合作，该助手有超过一半的呼叫者立即退订。助手是更大 IVR（语音）系统（主要客户服务线路）的扩展。这个试点项目旨在处理两项自助任务：停止公用事业服务或将服务转移到新地址。

假设是每个人到达我们的虚拟助手都是为了做以下两件事之一（停止或转移他们的公用事业服务），这是基于将呼叫者引导到我们解决方案的 IVR 菜单选择。用户及其菜单选择的信息被传递给虚拟助手，虚拟助手立即启动相应的用例流程。以下列表显示了用户的经验，首先是 IVR，然后是转移到虚拟助手。

列表 11.1 从 IVR 到虚拟助手的移交

IVR: Thank you for calling ABC Energy. If this is an emergency, choose one of the following: say gas emergency or press 1\. Electric emergency or press 2\. Power outage, or press 3\. If this is not an emergency, say do something else or press 4.

USER: <selects option 4>

IVR: Main menu. For billing and account information, press 1\. Payments, press 2\. Start, stop, or reconnect, press 3.

USER: < selects option 3>

IVR: Which are you calling about? Say building a new home or press 1\. Start, stop, or move service or press 2\. Reconnect or press 3\. Streetlights or press 4\. None of the above or press 5.

USER: < selects option 2>

IVR: Select one of the following. Check an existing request or press 1\. Start new service or press 2\. Stop existing service or press 3\. Move my service or press 4.

USER: < selects option 3>

<Customer transfers over to virtual agent solution, which has a different voice.>

VIRTUAL ASSISTANT: We can help you with stopping your service. First, we need to get some information about your current address. Which type of account are you calling about: residential or commercial?

USER: Speak to an agent.

在早期的生产日志中，我们注意到大量用户选择退出，通常是在一开始。尽管我们的公用事业公司虚拟代理试点在技术上非常出色，但许多呼叫者不会给它一个机会。我们听了通话录音，发现整体用户体验感觉支离破碎。客户拨打一个号码，到达一个 IVR（具有特定的 IVR“声音”），并导航到与服务相关主题的菜单。如果呼叫者选择停止或转移他们的服务，他们会被路由到我们的虚拟代理，但过渡是突然的——一个不同的声音绕过问候呼叫者（最初的理由是呼叫者已经被 IVR 问候过）并直接进入任务，似乎具有最优效率。

当一些呼叫者到达虚拟助手时，我们能够听到他们在最初沉默中的困惑。他们有长时间的犹豫、可听到的叹息或结巴（“uh…”，“um…”，“hmm”）。他们还没有被介绍给这个新代理。他们对第一个问题感到困惑，这个问题在程序上很合适，但在对话中显得非个性化且笨拙。人类代理不会以这种方式开始对话。他们会用欢迎的语气介绍自己。如果 IVR 收集了关于呼叫者目标的信息，人类代理会在继续之前与用户确认这一点（“我看到您打电话是为了转移您的公用事业服务，这是正确的吗？”）。

我们从第一行开始重新设计了体验，从情境意识的问候和介绍开始。虚拟代理被赋予了角色和更对话式的语气，如下面的列表所示。

列表 11.2 更新的虚拟助手问候和介绍

VIRTUAL ASSISTANT: Good afternoon.  #1
I'm Alice. ABC Energy's virtual agent. #2

1 情境意识问候

2 虚拟代理介绍

以问候和介绍开始互动，使我们的虚拟助手与菜单驱动的 IVR 系统区分开来。这给了呼叫者时间来适应过渡到新声音和不同风格的互动。

一个具有情境意识的问候，比如承认一天中的时间或通过名字问候用户，可以将机器人般的、非个性化的交流转变为更加温馨和欢迎的体验。在某些使用场景中，名字或角色可能并不合适，但在这个例子中，它传达了一种所有权和责任感。“Alice”在这里是为了服务客户。

11.2.2 传达能力和设定期望

在我们立即退出的驱动因素中，我们确定了那些因为感觉他们的问题是太独特或复杂而无法由机器解决的用户。有时这是一种公正的判断，但有时则不然。

在一开始就设定期望至关重要。公司推出具有有限范围或能力的试点虚拟助手并不罕见。当您的解决方案只提供用户可能想要的一小部分主题或任务时，您需要提前沟通这一点。这样做，用户要么会确信他们处于正确的位置，要么会意识到他们不在。在这些场景中，问候语（或解决方案的入口点）是宣布聊天机器人的目的和能力（或在与用户推进之前获得快速确认）的好时机。

我们的公用事业公司虚拟代理问候语扩展到确认用户的目标（使用表示他们 IVR 选择的上下文）。我们包括了用户即将开始的旅程的简要预览。因为这是一个语音渠道——更容易出现意外断开连接，所以我们也为成功完成设定了一些期望。以下列表显示了额外的措辞。

列表 11.3 更新后的问候语，传达能力和设定期望

VIRTUAL ASSISTANT: Good afternoon. I'm Alice. ABC Energy's virtual agent. 
I'm here to help you with stopping your electric  #1
service.  #1
I'll just need to collect a few details about your  #2
account so we can schedule the stop order.  #2
Be sure to stay on the line until I give the  #3
confirmation number.  #3
If we get disconnected before the confirmation, #3
your account will not be changed.  #3

1 确认机器人的目的或能力

2 预览用户的旅程

3 为旅程的成功设定期望

11.2.3 鼓励自助服务

技术熟练或经常使用的用户可能会意识到使用自动化解决方案的效率，但一次性或偶尔使用的用户不知道期望什么。他们可能会认为这个过程很困难或耗时。这些用户也可能因为偏好人际互动而立即选择退出。鼓励自助服务可能会减少立即退出。

在我们的公用事业公司用例中，完成停止服务请求的平均通话时间（包括等待时间）约为 5 到 7 分钟。我们的自助服务流程至少可以这么快。以下列表显示了我们对问候语进行的额外调整，让呼叫者知道他们可以在短时间内完成目标。

列表 11.4 通过提供快速解决方案来鼓励呼叫者

VIRTUAL ASSISTANT: Good afternoon. I'm Alice.
ABC Energy’s virtual agent. I'm here to help you with
stopping your electric service. I'll just need to
collect a few details about your account so we can
schedule the stop order. 
This process should only take a few minutes. **#1
Be sure to stay on the line until I give
the confirmation number. If we get disconnected before
the confirmation, your account will not be changed.**

#1 鼓励自助服务 为了进一步鼓励呼叫者，我们想确保他们即使在遇到自动化系统的问题时，也会得到良好的照顾。以下列表显示了更新后的信息。

列表 11.5 通过确保升级可以发生来防止立即退出

VIRTUAL ASSISTANT: Good afternoon. I'm Alice.
ABC Energy's virtual agent. I'm here to help you with
stopping your electric service. I'll just need to
collect a few details about your account so we can
schedule the stop order. This process should only take
a few minutes. Be sure to stay on the line until I give
the confirmation number. If we get disconnected before
the confirmation, your account will not be changed. 
If we run into any problems, I'll get you over to a **#1
**customer service representative.****

#1 确保问题将被升级 ### 11.2.4 允许用户选择加入

在可能的情况下，用户应该有一种自主感。这可能看起来像是获得他们同意继续虚拟代理体验的许可。这可能不适合所有用例，但这种方法的好处是清楚地识别出同意选择加入体验的用户。

我们的公用事业公司虚拟代理问候语最后更新了一次。我们询问用户是否准备好继续。

列表 11.6 邀请用户选择加入

VIRTUAL ASSISTANT: Good afternoon. I'm Alice.
ABC Energy's virtual agent. I'm here to help you with
stopping your electric service. I'll just need to
collect a few details about your account so we can
schedule the stop order. This process should only take
a few minutes. Be sure to stay on the line until I give
the confirmation number. If we get disconnected before
the confirmation, your account will not be changed. 
If we run into any problems, I'll get you over to a
customer service representative.
Are you ready to proceed? #1

1 允许用户选择加入

虽然我们希望听到“是”作为对我们问题的回应，但我们也要准备好处理其他回应。我们有一个假设，即一些用户是错误地进入我们的解决方案的。有时是因为他们对在 IVR 中选择菜单选项时会发生什么有误解。有时，这仅仅是一个“大拇指”错误——一个错误且往往未被注意到的拨号盘选择。这些“其他”回应证实了我们的假设——我们的用户会说“返回”或“不”或表达不同的目标。他们意外地到达这里，我们希望将他们引回正确的路径以实现他们的目标。图 11.4 显示了我们是如何重新设计问候流程，以便可以适当地处理每个非肯定场景。

图 11.4 本示例问候流程中的对话逻辑可以处理对问题“你准备好继续了吗？”的各种回应。如果回应是明确的，例如“不”、“返回”或“与客服交谈”，则会调用预定义的流程。否则，回应将被发送到分类器进行意图检测，并由相应的流程处理。

练习

回顾用户可能会立即退出的对话部分，并问自己以下问题：

1. 我的虚拟助手是否热情地问候用户并介绍自己？

2. 我的虚拟助手是否解释了它的目的——它能做什么，不能做什么？

3. 我的虚拟助手是否提供了低摩擦体验来满足用户需求（与替代渠道或人工干预一样好或更好）？

11.3 减少其他退出

在对话后期发生的退出通常可以与对话设计中的特定问题或差距联系起来。在本节中，我们将讨论策略和方法，以帮助最小化对话后期发生的退出。

11.3.1 努力理解

在第四章中，我们讨论了理解用户需求的重要性。退出可能表明你的机器人意图识别存在问题。当用户与一个以开放式问题问候他们的聊天机器人互动，例如“我能帮您什么忙？”时，他们会有一个期望，即他们可以询问与贵公司业务相关的任何问题，甚至是一般领域的问题。

如果解决方案没有准备好应对一系列合理的请求，当用户被要求重复或改述时，他们可能会感到沮丧。不要让你的解决方案变得过时。投资于保持你的培训相关性和代表当前用户需求。会话搜索或 RAG 模式可能非常适合某些用例——特别是那些具有广泛领域和问答机器人的用例。

11.3.2 努力让他人理解

你的词汇和措辞选择很重要，尤其是当你从用户那里获取信息时。冗长的输出或措辞不当的问题可能难以让用户理解。用户可能不理解他们被要求提供的信息类型，或者他们可能没有立即可用。当用户发现自己处于这种情况时，他们选择退出是很常见的。当你获取信息时，要清楚地说明用户应该如何回答。多项选择题有时会被误解为是/否问题：

• “你是要打电话来开始、停止，还是转移你的电力服务？”

• “您是在寻找重新考虑、索赔争议还是审查？”

图 11.5 展示了一个可能被解释为是/否问题的选择题示例以及防止此类混淆的一种方法。

图 11.5 你构建问题的方法可以帮助用户理解你正在询问的问题类型以及你期望的答案类型。

11.3.3 保持灵活和包容

定义“有效”用户输入的僵化、混乱或过度限制的条件可能会导致用户选择退出。你的对话应该足够灵活，能够处理一系列“正确”的响应，并在必要时通过消除歧义来适应用户。图 11.6 展示了消除歧义的一个例子。

图 11.6 一个有弹性的对话流程可以处理一系列有效响应。如果需要，可以调用友好的消除歧义步骤来澄清用户的目标。

语音解决方案的特殊考虑

如果语音识别是体验的一部分，请验证你的转录准确性，以避免严重的误解。由于语言模型是基于文本的，错误的转录语音输入可能会加剧理解上的问题。如果语音服务未能忠实捕捉用户的输入，你也可能错过重要的主题趋势。

对于语音解决方案，你必须将认知负荷降到最低；构建直接简洁的问题。如果需要将信息包含在问题中，确保问题出现在输出的末尾。这将提示用户现在是他们说话的时机，如图 11.7 所示。准备好处理重复问题或信息的请求。

图 11.7 坏的例子（左侧）将行动号召“我能帮您什么？”放在输出的中间。这可能会促使用户在输出仍在尝试播放时开始说话。好的例子（右侧）将信息性消息放在前面。在消息的末尾，行动号召是一个清晰的邀请，让用户开始说话。

使用技术来缓解痛点

有一些情况下，你可以使用技术来减轻用户的痛点并促进理解。例如，一家保险公司为会员提供了一种语音助手。会员的 ID 号码可能是 9 位或 13 位，有时前面会带有一个字母。我们不希望给打电话的人带来关于号码可能有多长或者是否需要包含前面的字母（如果有的话）的信息负担，这会带来太多的认知负荷，尤其是在初次尝试时。我们只是简单地问，“您的会员 ID 是多少？”一些用户会说出这个数字，包括字母。另一些用户会使用拨号盘输入数字，并忽略任何前面的字母。我们希望适应自然用户行为，因此我们使我们的逻辑更加健壮。只要我们检测到正确的数字数量以执行查找，呼叫者可以包含或排除前面的字母字符。而不是不断打扰用户进行重试，解决方案会填写一些琐碎信息，并在有足够信息的情况下尝试执行查找（例如，“123456789”和“X123456789”都是可接受的）。如果需要，我们的重试信息会稍微改变信息内容，以引导用户提供有效的输入。

如果你的技术允许，另一个提高健壮性和准确性的工具是自定义语音模型。由于音素相似性，通过语音通道收集数字或字母的语音转录很困难（例如，“8”通常听起来像“H”，因此我们选择了针对此类输入进行优化的语音模型）。

11.3.4 传达进度

自助任务流程的复杂性可以从回答问题到简单的分类再到多步骤、多流程、动态用户旅程。在这些更复杂的流程中，你的对话设计应该表明任务或过程的进展。如果用户觉得这会无限期地进行下去，或者他们正在通过一个无休止的菜单系列进行循环，他们可能会认为与人类进行对话会更有效率。

进度可以通过多种方式传达，并且应该针对媒体进行优化。在启动一个长时间的任务流程之前，设定用户对你将需要他们做什么以及需要多长时间的了解。基于文本的平台可以更加详细或提供视觉指示，例如编号问题或显示进度条。电话渠道需要更加简洁，但可以给出诸如“我们快完成了”或“只需再回答几个问题”的指示。

11.3.5 预测额外用户需求

当用户从您的机器人那里收到答案或达到任务流程的结尾时，他们可能会发现他们的目标仍未实现。您的对话流程是否有技术上正确或适当的潜在结果，但这些结果可能会倾向于未解决用户的问题？考虑用户所处的位置。他们有需求，他们得到了答案，但需求仍然存在。如果对话流程在没有解决该需求的情况下结束，用户将选择退出。他们还有什么其他选择？

您能否扩展您解决方案的自助功能，以启动一个替代的解决方案路径？图 11.8 展示了一些示例场景和避免升级需求的可能方法。

图 11.8 您可以在预测到用户在对话流程结束时可能仍有未满足的需求时，提出下一步的最佳行动方案，从而避免升级。

11.3.6 不要无礼

当您构建虚拟助手时，请记住您正在尝试模拟更类似人类的经验。同理心对人类来说是自然而然的，但它必须有意地集成到机器驱动的交互中。假设您的用户在对话的另一端也在努力。当您需要重试或修复对话时，不要让用户觉得自己有责任。对话设计师应该以引导用户回到正轨的方式设计错误信息，而不暗示错误。

例如，我们的保险公司解决方案可以通过索赔号查找索赔，该索赔号是十三位数字。最初，在重试输出中提供“信息性”信息似乎是合理的。但结果在电话中听起来很无礼，如下面的列表所示。

列表 11.7 令人不愉快的客户体验重试场景

VIRTUAL ASSISTANT: I'll need the thirteen digit claim number to look up your claim.

USER: <says a thirteen digit number but speech only picked up twelve>

VIRTUAL ASSISTANT: You didn't provide a thirteen digit number. Please say or enter the claim number.

有时用户未能提供足够的数字；有时，语音服务未能检测到所有说出的数字或误转录了用户响应。无论责任在谁，解决方案都需要重新要求用户提供信息。在第一次重试时，通常只需再次要求提供信息就足够了。如果用户难以给出正确的响应或以正确的格式提供信息，您可以逐步引导他们。

列表 11.8 重试场景的更新体验

VIRTUAL ASSISTANT: I can help you look that up. What's the claim number?

USER: <says a thirteen digit number but speech only picked up twelve>

VIRTUAL ASSISTANT: Sorry, I didn't get that. What is your claim number?

USER: <says a thirteen digit number but speech only picked up twelve> 

VIRTUAL ASSISTANT: Sorry, I still didn't get that. You can say or enter the thirteen-digit claim number.

练习

审查您对话中的下游流程，看看用户可能会选择退出的地方，并问自己以下问题：

1. 用户因为虚拟助手似乎不理解他们的请求而选择退出的频率有多高？

2. 用户是否因为不理解虚拟助手的要求而选择退出？

3. 我的虚拟助手是否友好且有帮助？它是否传达了能力、效率和同理心？

4. 是否有自动化工具可以简化或加快用户达到最终目标的过程？

5. 用户是否因为在与虚拟助手互动后仍有未满足的需求，即使在看似“成功”的流程之后，也要求人工服务？

11.4 退出保留

到目前为止讨论的策略旨在减少立即退出，但可能无法完全消除它们。为了提高包含率，你还可以在立即退出请求后或在对话流程的关键点上尝试保留用户在虚拟代理体验中。

在许多场景中，真诚地尝试让用户留在渠道中可以起作用。这必须谨慎进行——客户永远不应该感觉到他们被系统当作人质。当这种情况发生时，到用户最终到达人类代理时，他们可能会感到沮丧或敌对。

退出保留流程的目的是

1. 发现用户的真实目标或需求

2. 评估机器人是否能够满足这一需求

3. 如果是这样，说服用户机器人能够满足这一需求

4. 如果不是这样，将他们引导到下一个最佳行动（例如，另一个虚拟代理或人类）

你可以在对话交互的开始阶段实施这样的流程，以帮助改善由于立即退出而导致的包含损失。这也可以在用户似乎成功完成流程后战略性地使用。如果用户在看似完成“愉快路径”后立即要求代理，你可能遗漏了某些东西。要么用户不喜欢答案，要么它没有帮助他们达到目标。

11.4.1 立即开始收集退出数据

如果你想要立即开始，或者你仍然处于预部署构建阶段，你可以实施一个简化的退出流程，要求用户提供退出的原因。在最简化的版本中，无论说什么，助手都会升级。图 11.9 显示了一个示例数据收集退出流程。这是一个相当不侵入的策略，用于找出用户为什么选择退出。

图 11.9 收集用户退出原因的简单流程

一旦收集到指标，你可能会意识到你需要更好的培训，或者你的解决方案策略在你构建的目的和用户想要与之交互的方式之间存在不匹配。

11.4.2 实施退出保留流程

一旦你了解了用户为什么选择退出，你就可以以更有意义的方式开始处理这些请求。你首先想做的事情是更新你的分类器，以便你可以采取最适合请求的行动。这些行动可能包括

• 扩展你的机器人当前处理这些新请求的能力

• 将用户转交给不同的虚拟代理

• 在必要时（如果可用）将用户升级到人类代理

• 如果没有代理升级，提供有关最佳替代方案的信息

图 11.10 显示了可以识别哪些请求在范围内与不在范围内的对话流程，对于分类器无法理解的请求有一个回退路径。

图 11.10 典型的退订保留模式将试图找出用户的需求。它将识别一个在范围内的请求（一个它能够处理的请求）或一个超出范围的请求（一个它理解但无法处理的请求），或者它将无法识别请求。当一个在范围内的请求被识别时，机器人可能会提出激励性的提议以保持用户在渠道内。当一个超出范围的请求被提出时，机器人可以将用户直接路由到适当的技能或代理队列。当一个请求没有被识别时，用户将被路由到默认或通用等待队列。

对于我们的公用事业公司用例，我们添加了逻辑来询问用户更多关于他们需要什么的信息（并且随着时间的推移训练我们的分类器以识别请求的范围）。许多用户仍然会坚持升级，要求第二次要求代理。这些用户将被转移到通用实时代理等待队列。

一些用户表达了可以理解但确实超出了我们系统范围的目标。这些用户可以被路由到专门的代理（如果有的话），以最大限度地减少额外转接的需要。例如，一些企业有一个单一的客户服务部门来处理所有问题。其他人将用户路由到不同的客户服务代理或部门来处理特定场景，例如专门的账单部门或专注于处理预约安排的代理。

当用户表达的目标与我们的解决方案目的相一致时，我们做出了激励性的提议，并给了他们选择继续自助服务的权利。这赋予了用户自主权，并让他们感到被听到。通过提供人工代理等待时间的信息，他们可以决定如何最好地利用他们的时间。通过正确识别他们的需求，我们赢得了他们的信任。许多用户愿意继续进行，只要机器人能够展示其能力，如以下列表所示。

列表 11.9 识别目标以保持用户在渠道内的退订保留流程

VIRTUAL ASSISTANT: Good afternoon. I'm Alice. ABC Energy's virtual agent. I'm here to help you with stopping your electric service. I'll just need to collect a few details about your account so we can schedule the stop order. This process should only take a few minutes. Be sure to stay on the line until I give the confirmation number. If we get disconnected before the confirmation, your account will not be changed. If we run into any problems, I'll get you over to a customer service representative. Are you ready to proceed?

USER: speak to an agent

VIRTUAL ASSISTANT: In order to get you to the right place, please tell me more about what you need.

USER: I want to disconnect my service and close the account right away

VIRTUAL ASSISTANT: We are currently experiencing long hold times, but I can help speed things up by asking you a few more questions. It sounds like you want to stop your electric service and get a final bill. Is that correct?

USER: yes

VIRTUAL ASSISTANT: Great! Let's start with looking up your account.

虚拟代理随后将尽可能收集信息，直到发生错误或呼叫者第二次要求代理。这使得我们能够自助服务客户，要么完成服务，要么尽可能收集信息，从而减少人工代理解决通话所需的时间。

这种新的设计取得了巨大的成功。在立即退订但表达了在范围内意图的呼叫者中，38%的人被说服与虚拟代理一起留下并成功验证。当与其他在本章中描述的更新相结合时，整体用例完成率从 27% 提高到 30%。

练习

反思您关于保持用户在渠道内的策略所学到的东西：

1. 您当前解决方案中是否有用户不理解为什么要求代理的退订趋势模式？

2. 要求用户提供更多关于他们需要帮助的信息，是否可以帮助我们确定改进的领域？

11.5 使用生成式 AI 改进对话

在第五章中，我们展示了如何使用检索增强生成（RAG）在运行时生成聊天机器人响应。但如果你更喜欢静态和可控的对话，你仍然可以在项目的构建阶段使用生成式 AI 来协助你的对话设计师。对话设计师擅长制作满足系统和用户需求的对话。如果你没有设计师可用，你可以使用生成式 AI 来帮助你制作实现你目标的消息。

在本节中，我们将展示使用生成式 AI 改进静态输出响应的几种技术。

11.5.1 使用生成式 AI 改进错误信息

编写好的错误对话很困难。我们的第一反应可能是提供技术上正确但语气生硬的信息。在语音通道中，这尤其困难，因为用户可能会犯错而自己没有意识到。例如，要求用户提供一定长度标识符的用户可能会忘记一个数字（或错误地添加一个额外的数字）。

对于社会保障号码（长度为九位），一个真实但语气生硬的错误信息将是“我没有收到九位数字。现在请输入一个有效的社会保障号码。”让我们使用生成式 AI 来改进这条信息。

由于这是一个创意任务，我们将使用一个可教导模型（mixtral-8x7b-instruct-v01-q）和采样解码。使用采样解码，响应将是不确定的。我们将多次运行此提示以生成多个响应供选择。

列表 11.10 使用生成式 AI 改进错误信息——迭代 1

Instruction: You are a copy editor designing dialogue  #1
for a voice-based conversational system.  You will be 
given a scenario and an input message.  Rewrite the  
input message to an output message. 
The output must be brief. The output should be 12 words  #2
or less. 
The output must be helpful and instruct the user. 
The output must be kind. 
The output must not refer to a mistake by the user. 

Scenario: User has entered a social security number  #3
with an unexpected number of digits.  #3
Input: I did not get 9 digits. Enter a valid social  #3
security number now.  #3
Output: Please enter your 9-digit SSN.  #4

1 模型的指令和定位

2 模型的指令和定位

3 需要改进的场景和输入信息

4 LLM 输出

运行该提示三次生成了以下输出：

• “请输入您的 9 位社会保障号码。”

• “请输入您的完整 9 位社会保障号码。”

• “请输入 9 位的社会保障号码。谢谢！”

这些信息确实有所改进。如果包含道歉，它们可能会更好。让我们增强指令以包含道歉。

列表 11.11 使用生成式 AI 改进错误信息——迭代 2

Instruction: You are a copy editor designing dialogue  #1
for a voice-based conversational system.  You will be 
given a scenario and an input message.  Rewrite the 
input message to an output message. 
The output must be brief. The output should be 12 words
or less. 
The output must be helpful and instruct the user.
The output must be kind.
The output must not refer to a mistake by the user. 
The output must include an apology.  #2

Scenario: User has entered a social security number   #3
with an unexpected number of digits.  #3
Input: I did not get 9 digits. Enter a valid social   #3
security number now.  #3
Output: Please enter your 9-digit SSN.  #4

1 原始指令

2 新指令——添加道歉

3 原始场景和输入信息

4 LLM 输出

运行该提示六次生成了以下输出：

• “对不起，请输入一个 9 位的社会保障号码。”

• “抱歉。请输入正确的社会保障号码。”

• “对于麻烦表示歉意，请用 9 位数字再次尝试。”

• “对此表示歉意，让我们再试一次。请输入一个 9 位的 SSN。”

• “我道歉，请输入一个 9 位的社会保障号码。”

• “我的道歉，这并不完全正确。请用 9 位数字再次尝试。”

我们可以原样使用这些信息之一，或者混合匹配来生成一个新的信息。也许可以使用“抱歉，让我们再试一次。请输入您的 9 位社会保障号码。”

11.5.2 使用生成式 AI 改进问候信息

我们遇到了一些用户对公用事业公司打进的问候信息感到困惑的情况。用户被从一个 IVR 转接到另一个，方式令人不适。生成式 AI 能否帮助更新问候信息？让我们在以下列表中看看。

列表 11.12 使用生成式 AI 改进问候信息——迭代 1

<|instruction|>
You are a copy editor designing dialogue for a voice-based 
conversational system.  You will be given a scenario and an input
message.  Rewrite the input message to an output message.
The output must include a greeting.
The output must be helpful and instruct the user.

<|scenario|>
User dialed their energy company ABC Energy.  The user is met by a 
first conversational AI.  The conversational AI provides a menu.  The
user pushes a button.  The user is transferred to a second 
conversational AI.

<|input|>
We can help you with stopping your service. First, we need to get
some information about your current address. Which type of account 
are you calling about: residential or commercial?

<|output|>
Hello! Thank you for contacting ABC Energy. I'd be   #1
happy to assist you in stopping your service. To start,  #1
could you please tell me whether this is a residential   #1
or commercial account? Once I have that information, I   #1
can better assist you with your request. #1

1 LLM 输出

第一条输出相当不错，但我们还可以生成更多：

• “你好！欢迎来到 ABC 能源。我明白你想要取消你的服务。在我们继续之前，我可以问一下你打电话是关于哪种账户的吗：住宅还是商业？另外，你能提供你的当前地址，这样我们才能正确处理你的请求吗？谢谢。”

• “你好！欢迎来到 ABC 能源。我今天在这里帮助你。首先，你能告诉我这是住宅账户还是商业账户吗？一旦我有了这些信息，我就可以帮助你解决任何关于停止服务的问题或疑虑。”

输出信息给我们提供了几个改进问候的方法。它们都包括问候语、公司标识和前言。然后包括关键问题，以及问题之后的一些评论。只有一个问题：我们应该以一个问题结束信息——这是邀请用户发言的邀请。（这在语音解决方案中很重要，因为我们不希望询问用户问题然后继续说话——这往往会导致用户在机器人说话时回答。）我们可以手动删除最后一部分或尝试更新 LLM 的指令。

以下列表尝试了一条新的指令。

列表 11.13 使用生成式 AI 改进问候信息——迭代 2

<|instruction|>
You are a copy editor designing dialogue for a voice-based 
conversational system.  You will be given a scenario and an input
message.  Rewrite the input message to an output message.
The output must include a greeting.
The output must be helpful and instruct the user.
The output must end with a question.  #1

<|scenario|>
User dialed their energy company ABC Energy.  The user is met by a 
first conversational AI.  The conversational AI provides a menu.  The
user pushes a button.  The user is transferred to a second 
conversational AI.

<|input|>
We can help you with stopping your service. First, we need to get 
some information about your current address. Which type of account are
you calling about: residential or commercial?

<|output|>
Hello! I'm happy to assist you in discontinuing your   #2
service with ABC Energy. To start, could you please   #2
specify whether this is regarding a residential or   #2
commercial account? Thank you!  #2

1 新指令

2 LLM 输出

这条信息更好，但它仍然以“谢谢！”结束。我们指示 LLM 不要这样做，但它仍然这样做了。事实上，我们多次运行了这个提示，每次输出都以这种方式结束。我们甚至更改了指令到

The output must end with a question. The output must not end with "Thank you!

这最终只是一个小的烦恼。我们可以删除“谢谢！”并继续使用更新的信息。

通过概述机器人的功能并让用户了解我们对他们的期望，可以改进问候信息。以下列表再次改进了问候信息。

列表 11.14 使用生成式 AI 改进问候信息——迭代 3

<|instruction|>
You are a copy editor designing dialogue for a   #1
voice-based conversational system.  You will be given  
a scenario and an input message.  Rewrite the input   
message to an output message. 
The output must be helpful and instruct the user. 
The output must describe the system's capabilities. 
The system helps users stop their electric service. 
The output must let the user know they will need to   
answer a few questions that provide details about their   
service. 
The output must let the user know their account will    #2
not be changed until the process is completed. 
The output must end with a confirmation that the user  
is ready to proceed. 

<|scenario|>
User dialed their energy company ABC Energy to stop their electric  
service.  The company's conversational AI has greeted the user.

<|input|>
I'm here to help you with stopping your electric  #3
service. I need some information about your service.   #3
Are you ready? #3

<|output|> #3
Welcome to ABC Energy! I'm here to assist you in    #4
discontinuing your electric service. To ensure a smooth   #4
process, I'll need to ask a few questions about your    #4
account details. Rest assured, they won't be changed  #4
until the termination is finalized. Are you prepared    #4
to proceed?  #4

1 详细指令

2 详细指令

3 我们要求 LLM 改进的简单问候

4 LLM 输出

一个出色的问候！回想一下，我们正在使用采样解码并得到非确定性响应。你很可能会得到不同的输出。以下是 LLM 的更多输出：

• “欢迎来到 ABC 能源！我今天可以帮助您停止您的电力服务。为确保准确性，我需要询问一些关于您的账户详情的问题。请注意，在流程最终确定之前不会收取任何费用。您准备好继续了吗？”

• “欢迎来到 ABC 能源！我今天可以帮助您停止您的电力服务。为确保准确性，我会询问一些与您的账户相关的问题。请注意，在此过程中不会收取任何费用。您准备好提供必要详情了吗？”

您可以尝试不同的指令来更改问候语或继续使用您喜欢的信息。

一个改进是激励用户，让他们知道流程是快速的。我们可以增强指令来指出这一点。下一个列表增加了指令“用户应该被激励，这些问题简单且回答起来不费时。”

列表 11.15 使用生成式 AI 改进问候信息的第 4 次迭代

<|instruction|>
You are a copy editor designing dialogue for a voice-based  
conversational system.  You will be given a scenario and an input  
message.  Rewrite the input message to an output message.
The output must be helpful and instruct the user.
The output must describe the system's capabilities.  The system helps 
users stop their electric service.
The user should be incentivized that the questions are    #1
easy and don't take long to answer.  #1
The output must let the user know they will need to answer a few   #1
questions that provide details about their service.
The output must let the user know their account will not be changed  
until the process is completed.
The output must end with a confirmation that the user is ready to proceed.

<|scenario|>
User dialed their energy company ABC Energy to stop their electric  
service.  The company's conversational AI has greeted the user.

<|input|>
I'm here to help you with stopping your electric  #2
service. I need some information about your service.    #2
Are you ready?  #2

<|output|> #2
Welcome to ABC Energy! I can assist you with   #3
Discontinuing your electric service today. To ensure a    #3
smooth process, I'll need to ask a few **quick and easy **   #3
**questions** about your account. Rest assured, it won't be    #3
changed until the cancellation is finalized. Are you    #3
prepared to begin? #3

1 新指令

2 原始问候语，我们要求 LLM 进行改进

3 LLM 输出（新的输出加粗）

LLM 无缝地将信息简化：新的信息解释说，流程中的下一个问题设计为“快速且简单”（对用户而言）。

让我们再次增强问候语。用户应该确信如果需要，客户服务将介入。在下一个列表中，我们将添加指令“如果用户无法完成自动化流程，必须让用户知道将会有客户服务代表介入。”

列表 11.16 使用生成式 AI 改进问候信息的第 5 次迭代

<|instruction|>
You are a copy editor designing dialogue for a voice-based  
conversational system.  You will be given a scenario and an input message.  Rewrite the input message to an output message.
The output must be helpful and instruct the user.
The output must describe the system's capabilities.  The system helps 
users stop their electric service.
The output must let the user know they will need to answer a few  
questions that provide details about their service.  The user should  
be incentivized that the questions are easy and don't take long to answer.
The output must let the user know their account will not be changed  
until the process is completed.
The output must let the user know a customer service  #1
representative will get involved if the user cannot   #1
complete the automated process.  #1
The output must end with a confirmation that the user is ready to proceed. #1

<|scenario|>
User dialed their energy company ABC Energy to stop their electric  
service.  The company's conversational AI has greeted the user.

<|input|>
I'm here to help you with stopping your electric service. I need some   #2
information about your service.  Are you ready? 

<|output|>
Welcome to ABC Energy! I'm here to assist you with    #3
stopping your electric service. To ensure a smooth    #3
process, I'll need to ask you a few easy questions  #3
about your service. Rest assured, it won't be changed   #3
until the cancellation is finalized. **If you encounter **   #3
**any difficulties, a customer service representative **  #3
**will be happy to assist you.** Are you ready to begin?   #3

1 新指令

2 原始问候语，我们要求 LLM 进行改进

3 LLM 输出（新的输出加粗）

问候语传达了我们所需的一切，但它开始变长了。让我们要求机器人通过添加一个额外的指令来缩短它。

以下列表增加了“输出应少于 40 个单词。”

列表 11.17 使用生成式 AI 改进问候信息的第 6 次迭代

<|instruction|>
You are a copy editor designing dialogue for a voice-based  
conversational system.  You will be given a scenario and an input message.  
Rewrite the input message to an output message.
The output must be helpful and instruct the user.
The output must describe the system's capabilities.  The system helps 
users stop their electric service.
The output must let the user know they will need to answer a few  
questions that provide details about their service.  The user should  
be incentivized that the questions are easy and don't take long to answer.
The output must let the user know their account will not be changed  
until the process is completed.
The output must let the user know a customer service representative  
will get involved if the user cannot complete the automated process.
The output must end with a confirmation that the user is ready to proceed.
The output should be 40 words or less.  #1

<|scenario|>
User dialed their energy company ABC Energy to stop their electric  
service.  The company's conversational AI has greeted the user.

<|input|>
I'm here to help you with stopping your electric   #2
service. I need some information about your service.    #2
Are you ready?  #2

<|output|> #2
Sure! To stop your electric service, I'll ask a few    #3
easy, quick questions. Nothing will be changed until    #3
the process is complete. If needed, a rep will assist.    #3
Ready to proceed?  #3

1 新指令

2 原始问候语，我们要求 LLM 进行改进

3 LLM 输出

生成式 AI 是改进对话信息的优秀伙伴！

11.6 有时升级是可行的

可能存在这样的情况，您的虚拟助手将要传达用户不高兴的信息。例如，如果用户提交了一个索赔并且被告知被拒绝，他们可能不会满意，并希望纠正这种情况。如果自动解决方案不提供解决问题的途径或重新考虑的机会，他们可能会在这个时候选择退出。

通过良好的规划，您可以设计主动流程，预测后续用户需求。这样，即使升级是适当的下一步行动，您的指标也可以区分退出和出于商业原因的故意转移。在下一章中，我们将讨论如何优化向人工代理的移交。

摘要

• 退出是控制力损失的主要来源，这会导致虚拟代理在传递商业价值方面失败。

• 在对话初期就选择退出的用户，往往是因为他们对虚拟代理能力的感知以及他们是否相信虚拟代理能够引导用户达到他们的最终目标。

• 在对话后期发生的退出是虚拟代理可能对理解力薄弱或对话设计存在问题的指标。

• 退出保留是一种提高控制力的优秀策略；它还可以提供有关用户期望你的机器人能够做什么的有价值数据。

• 生成式 AI 可以补充你在对话流程中构建机智、高效回应的过程。

第十二章：对话摘要以实现平滑交接

本章涵盖

• 定义有效对话摘要的要素

• 量化你的对话 AI 以增强摘要功能

• 使用 LLM 将聊天记录摘要成散文

• 使用 LLM 从聊天记录中提取结构化细节

对话 AI 构建者希望他们的系统中包含所有用户对话。但对于大多数用例，一些百分比的用户会在与人类交互结束后结束与你的机器人的交互。对话 AI 旨在处理易于自动化的对话，并将更有价值或更具挑战性的对话引导给人类代表。希望自助服务的用户可能会因为“失败”与对话 AI 而感到沮丧，因此，在转接后为人类代表提供尽可能好的开始处理电话非常重要。

两种最简单的交接方法也是最不令人满意的。我们可以“盲目”将对话转交给人类代表，并让他们再次询问所有需要的信息。或者我们可以将完整的对话记录交给代表，并要求他们搜索所需的信息（同时用户在等待！）。更好的做法是给人类代表一个有针对性的对话摘要，这样他们可以快速接手对话 AI 留下的地方。

12.1 摘要简介

摘要使 AI 到人类的交接过程更加顺畅。首先，我们将回顾为什么需要摘要。然后，我们将探讨有效摘要的要素。

12.1.1 为什么需要摘要

大多数对话 AI 解决方案存储完整的对话记录以供审计和数据分析。当你有时间分析时，这是一座宝库。但当你是一名被 AI 转接对话的客户服务中心代表时，你没有时间阅读冗长的记录。你需要快速抓住用户问题的本质，以便开始帮助他们。我们见过 AI 聊天记录长达多页（数百个单词）。代表需要几个有针对性的要点——更多将花费太多时间阅读，而更少则无法传达足够有用的信息。

图 12.1 说明了当聊天机器人将对话转交给人类代表时，如何从完整的对话记录中生成对话摘要。

图 12.1 一个有效的摘要帮助代表快速熟悉情况，即使用户之前与机器人进行了长时间的对话。

从上一章，我们知道一些用户会立即选择转接到代表，但许多用户在感到沮丧之前会经历一系列步骤。以下列表显示了一个示例对话，其中用户似乎完成了他们的目标，但仍然要求转接到代表。

列表 12.1 用户与 AI 的示例对话

AI: Welcome to the automated assistant, how can I help?
User: Claim status
AI: Ok, claims. What's your Tax ID?
User: 123456789
AI: Thank you. What's the member's eight-digit Member ID?
User: 87654321
AI: Ok, and what's the member's date of birth?
User: 12/31/2000
AI: Is the member's name John Doe?
User: Yes
AI: Great! What's the date of service for the claim
User: "February first 2024
AI: I found your claim #111222333 from February 1,  #1
2024 for the member #87654321 and provider #123456789\.  #1
It was paid on May 23, 2024 for $201.83\.  #1
User: representative  #2

1 用户似乎完成了他们的目标

2 用户仍然选择退出

我们不确定用户为什么选择退出（可能是检查没有到达？）。但这不是重点。在大多数对话式 AI 解决方案中，用户可以在对话的任何地方选择退出。列表 12.1 中的对话有七个回合，可能大约花费了两分钟。这足够长，以至于阅读和理解需要一些努力。如果你是人工代理，你会想阅读那个完整的对话吗？如果对话更长会怎样？

平滑的转接应该迅速发生。代理应该迅速理解发生了什么，以便他们能够有效行动。用户不应该需要等待代理熟悉情况。有效的总结有助于满足所有这些需求。

12.1.2 有效总结的要素

一个对话总结只包含足够的信息来理解完整的对话。它应该包括结构化元数据和简短的文本总结；总结的内容将根据您的特定用例而变化。图 12.2 显示了示例。

元数据摘要要素

结构化摘要要素通常来自封闭形式的问题，例如“你的会员 ID 是什么？”（“开放形式”问题类似于“我能帮您什么？”）这些摘要要素可以包括在对话中收集的数据或来自对话之外提供的环境。

这些是一些示例要素：

• 已登录用户的用户 ID（聊天）或来电者的电话号码（语音/SMS）

• 聊天中收集的标识符

• 聊天中发现的标识符

• 用户曾经进行的聊天会话数量

• 用户话语的情感分析

图 12.2 一个有效的总结从对话中提取关键细节。这里包括对话总结和最后搜索的索赔。通话中的 AI 部分可能花费了两分钟，但人工代理可以在几秒钟内阅读总结。

在图 12.2 中，聊天收集了五条信息，但人工代理只需要知道三条。图 12.3 分解了总结。

图 12.3 并非每个封闭形式的问题都需要存储在总结中。在这个医疗保险索赔审查中，最重要的信息是提供者 ID、会员 ID 和索赔 ID。

在这个医疗保险索赔搜索中，需要大量信息来验证来电者。我们需要核实来电者是谁，他们打电话的原因，以及他们打电话的内容。仅通过三个数据元素就能确认会员信息：一个 ID、一个日期和姓名的确认。接收转接的人工代理只需要知道会员已被验证，会员 ID 就足够了。

同样，关于索赔的信息有很多——一些由用户（服务日期）提供，一些由 AI（状态、支付日期、支付金额）提供。摘要只包括索赔 ID，这对于代理检索完整的索赔，包括所有不属于对话的细节，将足够。

在由人类代理处理对话的软件中包含摘要元素是有用的。在接触中心软件中，这被称为屏幕弹出——一个在代理处理对话时显示上下文信息的功能。图 12.4 展示了我们医疗保险代理的一个示例屏幕弹出。他们以高亮的形式接收结构化信息，并通过后端集成，他们可以获得更多信息。点击会员 ID 应显示关于会员的信息或其身份证照片。点击索赔应显示索赔本身（例如，作为 PDF 文件）。

图 12.4 当摘要与接触中心软件集成时，人类代理可以触手可及地拥有大量信息。当保险代理在其软件中点击会员 ID 时，他们可以获得关于该会员的额外详细信息。

结构化元数据提供了到目前为止对话中的关键数据点。它防止人类代理不得不重新询问用户已经为机器人回答过的问题。当用户必须再次回答相同的问题时，他们会感到非常沮丧！人类代理从能够触手可及的信息中受益，但他们仍然需要意识到对话的整体背景。这就是自由文本摘要的作用所在。

自由文本摘要元素

一个对话在转交给人类代理之前可能包含数百个单词。（我们使用的示例记录大约有 100 个单词。）当成年人为了娱乐阅读时，平均每分钟阅读 200 个单词，对于复杂材料则更慢。我们的用户不想等待比必要的更长的时间，因此我们的人类代理需要快速熟悉情况。一个好的摘要可以减少几分钟的时间。

遵循“简单至上”的哲学。一至两句话的摘要可以快速传达大量信息。我们示例中的自由文本摘要——“用户搜索他们的索赔并发现它在提交后三个月支付”——在前五个词中封装了整个搜索过程，以及在最后八个词中提供了一个可能的转接原因。

自由文本摘要也不重复。它消除了几条冗余信息：

• 用户的初始意图——这并没有明确包含，因为它可以从进行的索赔搜索中推断出来。

• 中间问题——它没有说“机器人要求提供税务 ID、会员 ID、出生日期等。”这些都是在用户找到索赔时隐含的。系统不会找到索赔，直到提供足够的信息。

• 结构化内容——摘要不需要浪费文字重复已经以紧凑形式提供过的结构化内容。

摘要也没有识别出谁启动了传输（用户或系统）。这可以在新的结构化字段中添加。

在摘要过程中存在权衡。过于简短的摘要会省略帮助代理的信息。过于冗长的摘要与阅读原始记录相比，不会帮助代理快速学习。选择最适合你用例的摘要方法。

在本章的后面部分，我们将向您展示如何使用生成式人工智能来生成摘要。不过，首先我们需要对话式人工智能以正确的格式结构化数据以生成摘要。

练习

设计你理想的以下样本对话摘要。你将在本章的后面部分使用额外的技术来完善这些摘要：

AI: Welcome to the automated assistant, how can I help?
User: Claim status
AI: Ok, claims. What's your Tax ID?
User: 123456789
AI: Thank you. What's the member's eight-digit Member ID?
User: 87654321
AI: Ok, and what's the member's date of birth?
User: 12/31/2000
AI: Is the member's name John Doe?
User: Yes
AI: Great! What's the date of service for the claim?
User: February first 2024
AI: I found your claim #111222333 from February 1, 2024 for the member #87654321 and provider #123456789\. It was paid on May 23, 2024 for $201.83.
User: representative

1. 设计一个纯文本摘要的样本对话。

2. 设计数据元素的结构化摘要。如果呼叫者要求成员的健康计划详情或尝试主动估计程序的成本，你会提取不同的结构化元素吗？

3. 从你正在工作的聊天机器人中提取一个对话记录。以文本和结构化元素的形式总结对话。

12.2 准备你的聊天机器人进行摘要

我们假设你的聊天机器人会跟踪对话记录。大多数平台都会这样做，但并非所有平台都会。记录是构建摘要所需的最基本元素。在本节中，我们将向您展示多种收集数据的方法，这些数据对于对话的文本和结构化摘要都是必要的。

12.2.1 使用现成的元素

对话式人工智能平台通常包含内置元素以帮助进行对话摘要。最常见的一个元素是对话记录——用户和助手之间消息的运行日志。在不同的平台上，可以通过不同的方式访问它。一个常见的机制被称为会话变量。

图 12.5 展示了如何在我们的平台（watsonx）中通过一个名为“会话历史”的内置会话变量访问记录。

图 12.5 通过“会话历史”变量访问对话记录

根据你的聊天平台，对话记录将以不同的格式存储。我们的平台以 JSON 格式提供摘要，如下所示。

注意：在许多对话式人工智能平台中，除非你通过 webhooks 自己构建，否则对话记录不会作为变量提供给对话会话。我们将在本章后面部分演示如何构建包含记录的变量。

列表 12.2 通过内置的“会话历史”变量访问对话记录

[{"a":"Welcome to the automated assistant, how can I help?"},{"u":
↪"Claim status","n":true},{"a":"Ok, claims.\nWhat's your Tax ID?"},{"u":
↪"123456789"},{"a":"Thank you.\nWhat's the member's eight-digit Member 
↪ID?"},{"u":"87654321"},{"a":"Ok, and what's the member's date of 
↪birth?"},{"u":"12/31/2000"},{"a":"Is the member's name John Doe?\n
↪option: ["Yes","No"]"},{"u":"Yes"},{"a":"Great!\nWhat's the date of 
↪service for the claim?"},{"u":"2024-02-01"},{"a":"I found your claim 
↪#111222333 from Feb 1, 2024 for the member #87654321 and provider 
↪#123456789\. It was paid on 5/23/2023 for $201.83."},
↪{"u":"representative"}]

JSON 格式旨在供机器阅读，但你可以在转换过程中运行录音。我们通过将 "a" 键替换为 "Bot"，将 "u" 键替换为 "User"，以及将 \n（换行符）替换为空格，使本章中的图表更易于人类阅读。

录音还包括一些你可能选择忽略的元数据，例如通过按钮提供的“是”和“否”选项。其他对话式人工智能平台可能包括进一步的时间戳等元数据。

在本章的后面部分（第 12.3 节），我们将演示如何通过一个大型语言模型（LLM）对这个录音格式进行总结。我们将看到 LLM 对录音格式具有很强的适应性。你可以以它们的原生格式总结录音，或者重新格式化以便于人类阅读。

12.2.2 为聊天机器人配置录音功能

一些对话式人工智能平台要求你自己创建和存储对话录音。或者，你也可以选择创建你自己的版本，以你偏好的确切格式。无论如何，这都是在你的 编排层 中实现的，如图 12.6 所示。编排层负责通过 API 调用外部系统。具体的术语将根据你的对话式人工智能平台而有所不同，但这通常被称为 webhook。

图 12.6 你可以使用聊天机器人的编排层以你需要的任何格式创建对话录音。

Webhook 是一种 API 类型。Webhook 通常在机器人处理用户响应之前（“预”-webhook）、处理用户响应之后（“后”-webhook）或在其他预定义事件时可用。Webhook 可以通过原生方式或作为输入参数访问对话上下文。下面的列表展示了构建录音的伪代码。（请参考你的对话式人工智能平台文档以获取正确的术语和格式。）

列表 12.3 更新录音的 webhook 伪代码

def transcript_webhook(request, response):
  userMessage = request.input.text  #1
  botMessage  = response.output.text  #2
  if(userMessage != null)  #3
    response.context.transcript += 'User: ' +  #4
    ↪userMessage + '\n' 
  if(botMessage  != null)
    response.context.transcript += 'Bot: ' +  
    ↪botMessage + '\n'

1 用户的消息通常位于请求对象中。

2 机器人的消息通常位于响应对象中。

3 用户的消息可能并非每次都存在。例如，大多数对话都是从机器人的问候开始的。

4 录音应存储在上下文变量（会话变量）中。所有用户和机器人的消息都附加到录音中。

列表 12.3 展示了一个后 webhook，因为它可以访问请求和响应。每次机器人对用户做出响应时，webhook 都会更新录音。这个录音包括尽可能少的元素——只是用户和机器人的消息——以及一个非常简单的每行一条消息的格式，便于人类阅读。你可以以你希望的任何格式创建你的录音，例如单个字符串、字符串数组、JSON 对象或自定义对象。

如前所述，简单的转录最容易阅读。对话式 AI 平台通常每条消息都有许多可选项的数据元素，您可以在转录中使用：

• 消息时间戳—您可以使用时间戳来显示消息接收或发送的绝对时间（例如，“上午 11:25:53”）或自聊天开始以来的相对时间（例如，消息开始后 1 分 15 秒的“00:01:15”）。

• 按钮—您可以通过按钮指示机器人提供了哪些选项，以及用户何时点击了按钮。这在语音解决方案中尤其有趣，因为用户可能通过他们的键盘输入双音多频（DTMF，或“触摸音”）输入。例如，您会知道用户按下了“0”而不是说出“零”。

• 原始或后处理输入—许多对话式 AI 平台会规范化某些输入类型，如日期和数字。您可以使用原始话语，如“二零二四年二月第一”，或后处理版本如“02/01/2024”。

• 富文本和非文本元素—您的机器人可能会以 HTML 标记或甚至图像和链接的形式响应，这些可能不适合转录。

列表 12.3 中的伪代码演示了如何更新跟踪对话上下文的上下文变量，但没有演示如何初始化该变量。最简单的方法是将变量初始化为空字符串，如下所示：response.context.transcript = ''。

与对话相关的其他几个数据元素可供使用，您可能希望在转录的开头包括它们：

• 会话时间戳—对话开始的时间。

• 会话时长—对话持续了多长时间。

• 用户标识符—这可能包括有关登录用户访问聊天室的信息，例如姓名、电子邮件或用户 ID。对于电话解决方案，这可能是指叫方的电话号码。

• 设备和渠道标识符—用户如何访问您的对话式 AI，例如设备类型（例如，移动或桌面）或他们使用的渠道（例如，聊天小部件、短信、Facebook Messenger 等）。

• 转移原因—机器人将呼叫者转接到代理的原因，例如“立即退订”、“退订”或“机器人不理解用户”。

您可以选择将这些元素留给总结的结构化部分（作为键值对），而不是将它们包含在散文总结中，因为它们适用于整个对话。

所有这些数据元素以及更多通常都可在您的对话式 AI 平台中找到。它们通常包含在 AI 的系统日志中，这是构建转录的另一个数据源。这些可选数据元素由对话式 AI 平台提供，因为它们是通用的，适用于任何对话作为元数据。它们是任何对话转录的绝佳起点。

在本章前面，我们了解到一个好的摘要不仅仅是一个非结构化的记录。结构化元数据在总结对话的重要部分时非常有用。这些元数据的一些部分不是通用的——它们针对您特定的实现是特定的。在我们的医疗保险示例中，会员 ID 和索赔 ID 是唯一的。

对话式 AI 平台不会给会员 ID 赋予任何特殊含义——它们被记录为另一条用户消息。如果您想在摘要中使用实施中的特定上下文元素，您将不得不自己配置 AI 来存储它们，以便它们可以被包含在摘要中。让我们看看如何操作。

12.2.3 配置您的聊天机器人（对于数据点）

对话式 AI 平台通常允许您在变量中存储任意值，这些变量通常被称为上下文变量或会话变量。您应该利用这些变量来收集对话中的任何具有重大意义的数据，尤其是如果它有助于您稍后找到更多信息。

您存储的数据将根据您的特定应用程序而变化。以下是一些按领域划分的示例：

• 医疗保险—会员 ID，提供者 ID，索赔 ID

• 零售—订单号，产品 ID，零售地点

• 银行—账户 ID，账户类型

任何时候机器人用固定格式的响应提出问题，比如“你的索赔 ID 是什么”，这个响应都是进行配置的合适候选。

小心敏感数据

许多类型的数据需要谨慎处理。有关如何处理可能识别个人（PI）或其他敏感数据点的数据，有规则和法规。您的对话式 AI 可能已经处理了它们，但将它们添加到摘要或日志中可能需要与您的法律团队进行审查。在收集、存储以及存储时间上要尽量简约，并请您的律师确认您的选择。

您存储上下文的方式将取决于您的对话式 AI 平台。您可能能够在用户界面中这样做，或者您的平台可能要求您编写代码。图 12.7 显示了我们在平台中用于存储上下文变量的低代码方法。

您可以在对话中稍后访问存储的上下文变量，包括访问它们以创建结构化摘要。以下列表显示了访问这些上下文变量并将它们存储在结构化对象中的伪代码。

列表 12.4 创建结构化摘要的 webhook 的伪代码

def on_transfer(request, response):  #1
  summary = ConversationSummary()  #2

  summary.providerTaxID = response.context.  #3
  ↪ProviderTaxID  #3
  summary.memberID      = response.context.MemberID  #3
  summary.claimID       = response.context.ClaimID  #3

1 当对话转移到代理时，调用此方法。

2 您可以定义一个自定义对象来保存您的摘要。

3 设置您自定义摘要所需的任何值。

图 12.7 将上下文重要信息存储到上下文变量中，以便稍后通过摘要检索

你也可以直接在你的助手中使用这些变量来创建一个非结构化的摘要。图 12.8 展示了我们平台中用于将多个变量组合成更大的摘要字符串的低代码方法。

图 12.8 使用低代码表达式编辑器将多个数据元素组合成摘要

本节展示了多种收集摘要所需数据的途径。对话式 AI 平台收集了大量的数据，这些数据可以用于摘要。你可以对你的 AI 助手进行配置，以收集你需要额外数据，并且你可以控制这些数据的格式。你收集的数据对于许多用途都很有用，包括高效地将任务转交给人工客服。

练习

1. 回顾你在 12.1 节练习中创建的摘要。你现在会改变那些摘要中包含的数据元素吗？

12.3 使用生成式 AI 改进摘要

如果你根本不想修改你的对话 AI，你还能收集到制作优秀摘要所需的所有数据，并以你需要的格式进行整理吗？生成式 AI 能做更多的工作，让你有更少的工作要做吗？是的！让我们看看如何做到这一点。

你有两个关键的前提条件。首先，你需要某种形式的对话记录：来自你的对话 AI 平台的内置记录，你自己创建的记录，或者从你的平台对话日志中提取的记录。其次，你需要知道对于你的用例来说一个好的摘要是什么样的。有了这两个前提条件，你就可以与一个 LLM 合作，以获取你需要的摘要。

在本节中，我们将使用 granite-13b-chat-v2 模型并采用贪婪解码。这个模型擅长我们需要的摘要和提取技术。我们将使用贪婪解码，这样模型就不会有创造性，输出将是可重复的。（我们希望对于给定的对话生成相同的摘要和提取相同的细节。）

12.3.1 使用摘要提示生成转录本的文本摘要

我们将从一个简单的摘要提示开始我们的练习，如下所示。我们将传递给模型我们聊天记录的 JSON 版本。

列表 12.5 生成 JSON 聊天记录的摘要

Summarize the following conversation transcript between a  #1
user ("u") and the automated assistant ("a"). 
The summary should be 1-2 sentences long.  #2

Transcript:
[{"a":"Welcome to the automated assistant, how can I help?"}  #3
↪,{"u":"Claim status","n":true},{"a":"Ok, claims.\nWhat's your  #3
↪Tax ID?"},{"u":"123456789"},{"a":"Thank you.\nWhat's the   #3
↪member's eight-digit Member ID?"},{"u":"87654321"},{"a":"Ok,   #3
↪and what's the member's date of birth?"},{"u":"12/31/2000"}, #3
↪{"a":"Is the member's name John Doe?\noption: ["Yes","No"]"},  #3
↪{"u":"Yes"},{"a":"Great!\nWhat's the date of service for the   #3
↪claim?"},{"u":"2024-02-01"},{"a":"I found your claim #111222333  #3
↪from Feb 1, 2024 for the member #87654321 and provider   #3
↪#123456789\. It was paid on 5/23/2023 for $201.83."},{"u":  #3
↪"representative"}]  #3

Summary: #4
"I found your claim #111222333 from Feb 1, 2024 for the member #5
↪#87654321 and provider #123456789\. It was paid on 5/23/2023  #5
↪for $201.83."  #5

1 任务描述和解析 JSON 对象提示

2 指令以限制摘要大小

3 聊天记录的 JSON 版本

4 提示

5 模型输出

生成的摘要是从 AI 那里直接摘录的最后一句原话。一开始这可能看起来有些奇怪，但这确实是对话的一个相当好的总结。机器人的最后一句发言包含了很多细节，涵盖了对话中最重要的一部分。

通过使用采样解码和创造性的温度设置，我们可能会得到一个不同结构的摘要，但风险是引入幻觉。我们还可以更改转录格式，看看是否有助于 LLM。下一条目显示了一个以不同输入格式（非结构化文本而非 JSON）总结相同对话的提示。

列表 12.6 生成文本聊天转录摘要

Summarize the following conversation transcript between a user  #1
and an AI 

The summary should be 1-2 sentences long.  #2

Transcript:  #3
AI: "Welcome to the automated assistant, how can I help?"
User: "Claim status"
AI: "Ok, claims. What's your Tax ID?"
User: "123456789"
AI: "Thank you. What's the member's eight-digit Member ID?"
User: "87654321"
AI: "Ok, and what's the member's date of birth?"
User: "12/31/2000"
AI: "Is the member's name John Doe?"
User: "Yes"
AI: "Great! What's the date of service for the claim?"
User: "February first 2024"
AI: "I found your claim #111222333 from February 1, 2024 for the member #87654321 and provider #123456789\. It was paid on May 23, 2024 for $201.83."
User: "representative"

Summary:  #4
The AI is providing information about a claim that has been   #5
submitted by a member with the member ID 87654321 and provider  #5
ID 123456789\. The claim was paid on May 23, 2024 for $201.83\.  #5
The representative will be able to assist with any questions  #5
or concerns related to this claim.  #5

1 无额外提示的任务描述

2 相同的指令以限制摘要大小

3 聊天转录的文本版本

4 相同的提示

5 模型输出

这个生成的摘要包含与从 JSON 生成的摘要相同的信息内容。它仍然基于机器人的最后一条消息，但这次，它被改写成了散文。摘要还包括一个第三句话——与提示的指令相反——试图理解用户的最后一句发言。

注意：在本章剩余部分，我们将省略书籍中的对话转录内容以保持列表较小。我们将使用可读性更好的对话转录版本。完整的列表可在书籍的 GitHub 仓库中找到，网址为github.com/andrewrfreed/EffectiveConversationalAI。

记住本节前面给出的建议：你需要知道一个好的摘要是什么样的。到目前为止，LLM 生成的摘要还不错，但也许我们可以做得更好。一种方法是向模型提供更好的指令，如下一条目所示。因为我们强调指令，我们将切换到一个更具可指导性的模型，在这种情况下是 granite-13b-instruct-v2。模型被要求强调升级前的对话。

列表 12.7 增强对 LLM 的摘要指令

Summarize the following conversation transcript between a user    #1
and an AI  #1
The summary should be 1-2 sentences long.   #2
The summary should emphasize the last task the user was   #3
performing that led them to request a human representative.   #3

Transcript:  #4
<... human-readable transcript removed for brevity ...>

Summary:  #5
The user asks for a human representative because they want to   #5
know why their claim was denied.  #6

1 原始任务描述

2 原始指令以限制摘要大小

3 加强强调内容的指导

4 聊天转录的文本版本

5 相同的提示

6 模型输出

模型遵循指令。机器人的最后一条消息告诉用户他们的索赔已被支付（“索赔已于 2024 年 5 月 23 日支付 201.83 美元”），然后用户选择退出。LLM 的摘要简洁地说：“他们想知道为什么他们的索赔被拒绝。”这个摘要很短，但可能过于推测，因为索赔已被支付，实际上并没有被拒绝。也许用户觉得他们应该得到更多的支付，或者也许他们需要一个详细的清单。文本摘要还省略了列表 12.6 中看到的转录内容的近字面回放，将那些信息留给单独的结构化摘要。我们更接近于人类代理所需的内容。让我们改进提示以减少 LLM 的推测。

一个有用的方法是使用单次提示（带有一个示例）或少量提示（带有多个示例）来调用 LLM。创建单次示例迫使我们思考给定对话的良好总结是什么样的。使用一个或多个示例通常是改进提示最快的方式。

下面的列表展示了一个使用 granite-13b-instruct-v2 模型的单次示例。

列表 12.8 一个单次总结提示

<|instruction|>  #1
Summarize the following conversation transcript between a user    #1
and an AI  #1
The summary should be 1-2 sentences long.  #1
The summary should emphasize the last task the user was    #1
performing that led them to request a human representative.  #1

<|transcript|>  #2
AI: "Welcome to the automated assistant, how can I help?"   #2
User: "Claim status"  #2
AI: "Ok, claims. What's your Tax ID?"   #2
User: "012345678"  #2
AI: "Thank you. What's the member's eight-digit Member ID?"   #2
User: "I don't have it"  #2
AI: "Ok, let's try something else.  What's the member's date   #2
of birth?"  #2
User: "representative"  #2
#2
<|summary|>  #2
The user requested a human representative after failing   #2
to validate the member ID needed to find the claim.   #2

<|transcript|>  #3
<... human-readable transcript removed for brevity ...>

<|summary|>   #4
The user requests a human representative because they   #5
want more information about their insurance claim.   #5

1 通过“<|instruction|>”更新划分的任务描述

2 带有总结的对话记录单次示例

3 聊天记录的文本版本

4 重新结构化的提示

5 模型输出

当与结构化元数据结合时，此生成的总结也非常合理。有一些推测——“他们想要更多信息”——但再次看来，如果用户在发现声明似乎是付费的之后想要一个代理，他们可能需要更多信息。总结在示例之后也是结构化的，总结的前六个词与示例的词对词匹配。

注意，在单次总结示例（列表 12.8）中，我们使用了稍微不同的格式。我们不是使用Transcript:的划分，而是使用了特殊格式的标记，如<|transcript|>。没有这些特殊标记，我们无法生成好的总结。可能模型在区分提示部分和对话元素时遇到了困难，因为两者都使用了冒号。未来的大型语言模型（LLM）可能对提示中多次出现划分字符更具弹性。这种小的变化可以对 LLM 性能产生巨大影响。

在你的提示中强调指令或示例都是可行的。考虑以下权衡：

• 输出控制——大多数 LLM 默认训练于总结。许多对指令有反应并生成好的总结。单次和少量提示进一步限制了输出以使用你想要的语言，尽管你可能需要提供几个示例。

• 成本——添加示例会增加推理成本，因为输入的标记更多。

我们迄今为止生成的文本总结包括对话概述，但大部分不包括对代理有帮助的结构化元数据。在章节的早期，我们展示了使用各种代码和低代码方法来配置你的聊天机器人，以收集可以传递给代理的结构化元数据。如果我们不想配置我们的聊天机器人——LLM 能否提取结构化元数据？

12.3.2 使用提取提示生成对话记录的结构化总结

我们可以使用大型语言模型（LLM）从对话记录中提取结构化数据——提取是许多 LLM 训练的另一项任务。

我们的第一项任务是决定结构化输出需要看起来像什么。有许多可能性，但一个有用的格式是 JSON。这有两个原因：JSON 易于下游应用程序消费，许多 LLM 擅长生成 JSON。

我们将再次使用可指导的模型。这次我们将使用 mistral-7b-instruct-v0-2，因为它可以仅从指令中生成 JSON。以下列表显示了一个提示，该提示从对话中生成了结构化的 JSON 输出。

列表 12.9 没有示例的提取摘要

<|instruction|>
Read the following conversation transcript between a  #1
user and the automated assistant. Extract all IDs in    #1
JSON format.  #1

<|transcript|>   #2
<... human-readable transcript removed for brevity ...>

<|JSON|>  #3
{
  "TaxID": "123456789",  #4
  "MemberID": "87654321",   #4
  "DateOfBirth": "12/31/2000",  #4
  "Name": "John Doe", #4
  "ClaimNumber": "111222333",  #4
  "DateOfService": "February 1, 2024",   #4
  "ProviderID": "123456789"  #4
}  #4

1 更新后的任务描述，包含关于 JSON 格式的简单说明

2 聊天记录的文本版本

3 更新后的提示以生成 JSON

4 模型输出

这是一个出色的第一次尝试。模型生成了 JSON 并提取了收集到的所有结构化数据点。但它收集了比我们要求更多的数据——我们只想得到 ID——并且重复了一个数据点（税务 ID 是提供者的 ID）。

注意：许多模型在看到几个示例后可以生成 JSON。我们测试的所有模型都提取了几个数据点，而不是预期的三个。mistral 模型是少数几个在提示中没有示例就能生成有效 JSON 的模型之一。我们预计模型将继续在生成 JSON 数据方面取得进步。或者，您可以在指令中提供一个示例模式。

让我们用示例（以粗体显示）来增强这个提示。

列表 12.10 带有一个示例的提取摘要

<|instruction|>
Read the following conversation transcript between a  #1
user and the automated assistant. Extract all IDs in  #1
JSON format.  #1

**<|transcript|> ** #2
**AI: "Welcome to the automated assistant, how can I** ** #2
**help?" ** #2
**User: "Claim status" ** #2
**AI: "Ok, claims. What's your Tax ID?" ** #2
**User: "333444555" ** #2
**AI: "Thank you. What's the member's eight-digit Member** ** #2
**ID?" ** #2
**User: "55667788" ** #2
**AI: "Ok, and what's the member's date of birth?" ** #2
**User: "April 19, 2024" ** #2
#2
**<|JSON|> ** #2
**{"TaxID": 333444555, "MemberID": 55667788} ** #2

<|transcript|>  #3
<... human-readable transcript removed for brevity ...>

<|JSON|>  #4
{"TaxID": 123456789, "MemberID": 87654321,   #5
"DateOfService": "February 1, 2024", "ClaimNumber": #5
"111222333"}  #5****

****#1 相同的任务描述

2 一次性示例

3 聊天记录的文本版本

4 相同的提示

5 模型输出**** ****通过一个例子，我们向模型展示了我们不需要输出中的每一份数据。我们还让模型停止重复提供者的税务识别号。最后，JSON 响应现在已压缩成单行，没有换行符。提取的数据仍然准确，但我们可能需要确切的键名。如果代理的应用程序期望读取名为ClaimID的字段，那么摘要引用ClaimNumber是不可接受的。

我们在以下列表中给出了一个更详细的示例（以粗体显示）。

列表 12.11 更新后的提取摘要的一次性示例

<|instruction|>
Read the following conversation transcript between a   #1
user and the automated assistant. Extract all IDs in   #1
JSON format. # #1

**<|transcript|> **  #2
**AI: "Welcome to the automated assistant, how can I**  ** #2
**help?"** ** #2
**User: "Claim status"** ** #2
**AI: "Ok, claims. What's your Tax ID?"** ** #2
**User: "333444555" ** ** #2
**AI: "Thank you. What's the member's eight-digit Member**  ** #2
**ID?" ** ** #2
**User: "55667788" ** #2
**AI: "Ok, and what's the member's date of birth?"** ** #2
**User: "April 19, 2024" ** ** #2
**AI: "Is the member's name Jim Smith?" ** #2
**User: "Yes"** ** #2
**AI: "Great! What's the date of service for the claim?"** ** #2
**User: "April ninth 2024"** ** #2
**AI: "I found your claim #444444555 from April 9, 2024**  ** #2
**for the member #55667788 and provider #333444555\. It**  ** #2
**was paid in full on April 23, 2024 for $156.81." ** ** #2
**User: "Thanks! Goodbye"** ** #2
#2
**<|JSON|>** ** #2
**{"TaxID": 333444555, "MemberID": 55667788, "ClaimID":**  ** #2
**444444555} ** ** #2

<|transcript|>    #3
<... human-readable transcript removed for brevity ...>

<|JSON|>   #4
{"TaxID": 123456789, "MemberID": 87654321, "ClaimID":   #5
"111222333"}   #5**************************************

******#1 相同的任务描述

2 更新后的一次性示例

3 聊天记录的文本版本

4 相同的提示

5 模型输出****** ******这效果很好。我们只得到了我们想要的键。令人稍微有些沮丧的是，一次性示例需要与第二个记录如此接近。这暗示了要总结其他对话流程，我们可能需要为每个流程提供示例。（如果对话包括授权 ID、电子支付 ID 或其他 ID 怎么办？）还有一个需要注意的问题：TaxID和MemberID是数值，但ClaimID生成了字符串值——即使看到了示例。

测试幻觉

在我们的提取式摘要示例中，我们没有遇到任何幻觉，但这并不意味着它们是不可能的。任何摘要提示在部署之前都应该在多个输入上进行测试，以查看它是否会产生幻觉。部署后，你可以通过验证每个提取的值是否出现在记录文本中来检测幻觉。

让我们回到之前的一次性示例，并添加一些指令，如下面的列表中用粗体显示。

列表 12.12 包含一个示例的提取摘要

<|instruction|>
Read the following conversation transcript between a user and the automated assistant. Extract all IDs in JSON format.
Use only the following JSON keys: "TaxID", "MemberID",   #1
**"ClaimID".  ** #1
**The JSON values should be numbers, not strings.** ** #1

<|transcript|>  #2
AI: "Welcome to the automated assistant, how can I   #2
help?"   #2
User: "Claim status"  #2
AI: "Ok, claims. What's your Tax ID?"   #2
User: "333444555"  #2
AI: "Thank you. What's the member's eight-digit Member   #2
ID?"  #2
User: "55667788"   #2
AI: "Ok, and what's the member's date of birth?"  #2
User: "April 19, 2024"  #2
#2
<|JSON|>   #2
{"TaxID": 333444555, "MemberID": 55667788}  #2

<|transcript|>  #3
<... human-readable transcript removed for brevity ...>

<|JSON|>   #4
{"TaxID": 123456789, "MemberID": 87654321, "ClaimID":   #5
111222333}   #5**

#1 增强的任务描述

#2 较小的一次性示例

#3 聊天记录的文本版本

#4 相同的提示

#5 模型输出 Voila! 正是我们期望的输出。我们能够通过结合指令和示例，提示一个 LLM 生成我们想要的具有结构化的摘要。除了调用 LLM 之外，我们不需要修改我们的助手。这个调用仅限于处理将对话传递给代理的组件。

练习

1. 回顾你在第 12.1 节中为示例聊天记录创建的理想摘要。使用你最喜欢的 LLM（或你公司首选的 LLM）生成该记录的散文摘要。LLM 离你偏好的摘要有多近？你是否使用了指令、少量示例或两者都使用了？

2. 重复练习 1，但也要修改模型参数。在本章中，我们使用了贪婪解码和 1.1 的重复惩罚。尝试采样解码，或者尝试提高或降低惩罚。你是否得到了更好的性能？这符合你的预期吗？

3. 是否有可能在同一个提示中生成散文摘要并从记录中提取关键细节？设计一个提示，以生成以下输出：

{"TaxID": 123456789, "MemberID": 87654321, "ClaimID": 111222333,
"Summary": "The user requests a human representative because they 
want more information about their insurance claim."}

1. 4. 设计一个包含多个声明搜索的对话。想象一下，如果用户打电话来检查四个总声明，机器人和用户会进行怎样的对话。其中一些声明是付费的，一些声明仍在处理中，最后一个声明被拒绝。这个对话的内容将是原始样本对话的两到四倍。你希望这个摘要看起来像什么？一旦你有了目标摘要，使用 LLM 并尝试生成该摘要。
2. 5. 为以下样本对话设计一个理想的摘要：

AI: "Welcome to the automated assistant, how can I help?"
User: "coverage"
AI: "Ok, claims. What's your Tax ID?"
User: "333444555"
AI: "Thank you. What's the member's eight-digit Member ID?"
User: "55667788"
AI: "Ok, and what's the member's date of birth?"
User: "April 19, 2024"
AI: "Is the member's name Jane Williams?"
User: "Yes"
AI: "They are currently a member.  They have our PPO plan with coverage
↪for the full 2024 calendar year. Do you need anything else?"
User: "How much is their co-pay for office visits?”
AI: "Since you are an in-network provider they will owe $20"
User: "Do they need a prior authorization for a specialist?"
AI: "Yes, would you like to initiate one now?"
User: "Yes"
AI: "Let me transfer you to a specialist who can help with that."

现在为你的 LLM 构建一个提示，以生成类似的摘要。

1. 6. 将你的新提示与列表 12.1 中的原始样本对话进行测试。如有必要，调整提示，以便为这两个对话生成好的摘要。

摘要

• 将对话传递给人工代理是许多对话式 AI 解决方案的必然部分。代理从接收简短的摘要中受益，这些摘要从对话中提取了关键要点，无论是散文形式还是结构化格式。

• 摘要需要一个对话记录。大多数对话式 AI 平台都会为你生成记录，但你也可以配置你的对话式 AI 以生成你需要的格式。

• 通过增强你的对话式 AI 以存储收集到的关键数据点，或者当对话完成时使用 LLM 提取，可以生成结构化摘要。

• 在你要求 LLM 生成摘要之前，你需要知道一个好的摘要是什么样的。

• LLMs 可以生成散文摘要并从记录中提取关键细节。使用清晰的指令和示例来生成你想要的摘要。************ ******# index

A

准确性

APIs (应用编程接口)

使用

AI (人工智能)

传统的（基于分类的）, 第 2 次

Arize

标注日志

对于传统的（基于分类的）AI

答案生成

AOV (平均订单价值)

B

行为模式

盲测试

C

对话结果, 第 2 次, 第 3 次, 第 4 次, 第 5 次

比较检查

包含的对话，定义

跨职能团队, 第 2 次

复杂性, 第 2 次

对业务指标的影响, 第 2 次

对最终用户的影响

减少对用户的增量成本和收益

持续改进

上下文，在虚拟助手性能中的重要性

建立信任和忠诚

上下文信息, 第 2 次

解决问题的效率

增强相关性和准确性

影响用户交互, 第 2 次

个性化体验

主动支持

CohereEmbeddings

对话摘要

呼叫中心代理

分类模型

对话式 AI

好处

建立, 第 2 次

持续改进, 第 2 次

定义

它是如何工作的

使用生成式 AI 响应用户, 第 2 次

软件平台

理解用户

混淆矩阵, 2nd

上下文变量

复杂流程

商业云平台

D

双音多频（DTMF）

设备类型

仅解码器架构

文档转换器, 2nd

消歧特征

文档加载器

直接问题

解码方法

DirectoryLoader

E

仅编码器架构

编码器-解码器模型架构

嵌入生成

F

自由文本摘要元素

FaithfulnessEvaluator

Facebook AI 相似性搜索（FAISS）

常见问题解答（FAQ）机器人, 2nd

动态问答

基础

静态问答, 2nd

Flan-ul2 模型

G

金标准测试集

为生成式 AI 标注

为传统（基于分类器）AI 标注

生成新的语法变体, 2nd

黄金意图

生成度量, 2nd

生成式人工智能（AI）, 2nd, 3rd

为标注

使用增强意图数据

定义

有效使用, 2nd

guardrails, 2nd

使用改进摘要

模型平台

生成文本

granite-13b-instruct-v2 模型

H

人机交互

幻觉, 2nd

I

交互式语音应答（IVR）, 2nd

意图数据

使用生成式增强

改进规划

开发和交付修复, 第 2 次

驱动到相同目标, 第 2 次

索引指标, 第 2 次

意图

强化现有意图, 第 2 次

立即退订

允许用户选择加入

传达能力和设定期望

从良好的体验开始, 第 2 次

改进

识别和解决问题, 第 2 次

识别需求

K

KPIs (关键绩效指标)

看板板

k-折

交叉验证

测试

L

日志，获取和准备测试数据

准备和清理数据以用于迭代改进

LLMs (大型语言模型), 第 2 次, 第 3 次, 第 4 次, 第 5 次, 第 6 次

用增强数据增强意图数据, 第 2 次

集成

利弊

需求

使用增强数据

加载方法

M

模态

比较模态

如何模态影响用户体验的例子, 第 2 次

在设计虚拟助手流程中的重要性

消息

错误消息, 第 2 次

问候消息, 第 2 次

元数据，摘要元素

意义，提取

min_tokens

模型，选择

N

NPS (净推荐者分数)

NDCG (归一化折现累积增益)

NLU (自然语言理解)

NLP (自然语言处理)

O

OpenAIEmbeddings 类

退订

驱动因素, 第 2 次

升级

收集关于退订行为的资料

立即, 第 2 次

通过生成式 AI 改进对话

减少, 第 2 次

保留, 第 2 次

编排层

Ollama

一次性提示

P

持久用户历史

提示

提示工程

参数调整

输出后过滤

之前的交互

面向过程的机器人

精确度和召回率，为多个意图改进

精确度

面向过程或事务性解决方案

段落检索

预处理数据

提示填充

预过滤输入

PII（个人可识别信息）

流程处理

构建时 AI 辅助, 第 2 次

运行时 AI 辅助

使用生成式 AI 执行对话流程, 第 2 次

Q

定性问题探索

QPS（每秒查询数）

问答, 第 2 次

问题发现的数量评估

R

路由代理, 第 2 次

检索器

回忆

RAGAS，定义

运行时检索和匹配

RAG（检索增强生成）, 第 2 次, 第 3 次, 第 4 次, 第 5 次, 第 6 次, 第 7 次, 第 8 次

额外考虑事项, 第 2 次

好处, 第 2 次

与其他生成式 AI 用例结合

比较意图、搜索和 RAG 方法

使用设计自适应流程, 第 2 次

评估和分析性能

实现, 第 2 次

在对话人工智能中

维护和更新自适应流程

检索和生成上下文相关的响应

将请求路由到 LLMs

检索指标

S

槽填充

自助服务

激励

向量数据库中的存储

会话历史

会话变量

SSA（可感知性和特异性平均值）

SMEs（主题专家）, 第 2 版, 第 3 版

搜索在对话人工智能中的作用, 第 2 版

传统搜索的好处

传统搜索的缺点

在对话人工智能中使用搜索

使用 LLM 进行搜索过程, 第 2 版

支持资源

屏幕弹出

同义词生成, 第 2 版

敏感数据

摘要

有效元素, 第 2 版

利用生成式人工智能改进, 第 2 版

需要

概述

为聊天机器人做准备, 第 2 版

采样解码

解决问题

冲刺计划

T

传统搜索

从路由代理过渡到面向过程的机器人

转移决策

传统人工智能

改进薄弱理解, 第 2 版

模板，创建示例, 第 2 版

测试数据，从日志中获取和准备

注释过程, 第 2 版

识别候选测试语句的指南, 第 2 版

获取生产日志

为迭代改进准备和清洗数据, 第 2 版

问题分类, 第 2 版

测试时间，AI 辅助流程

设置对话测试, 第 2 次

设置生成 AI 以适应用户, 第 2 次

时区

真正的负例

传统（基于分类）AI 解决方案，评估

训练数据，选择

U

用户位置

理解

通过生成 AI 实现, 第 2 次

通过传统对话 AI 实现

注释日志, 第 2 次

基础

迭代改进

测量, 第 2 次

弱, 第 2 次

用户旅程

与用户的认知模型保持一致

允许预期用户响应的灵活性, 第 2 次

发现复杂的对话流程

通过 API/后端流程支持自助任务流程

利用对用户的了解

用户

评估你现在所在的位置, 第 2 次

理解

用户偏好

V

动词短语

虚拟助手

通过 RAG 增强上下文感知和提升整体用户体验, 第 2 次

上下文在性能中的重要性

模型性, 第 2 次

语音机器人，设计考虑因素

语音解决方案，适应

W

弱理解

建立基线

识别最大问题

在误解的表述中识别问题模式, 第 2 次

改进计划

为单一意图改进 F1 分数

为传统 AI 改进

为单一意图改进精确度

为单一意图改进召回率

渐进式改进

解决, 第 2 次, 第 3 次, 第 4 次

传统 AI, 第 2 次, 第 3 次

验证初始训练策略

意图匹配错误

Z

零样本提示******