原文：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 为什么使用对话式人工智能？

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH01_F01_Freed2.png

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

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH01_F02_Freed2.png

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

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

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

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

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

1. 确定用户想要什么。

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

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

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH01_F03_Freed2.png

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH01_F04_Freed2.png

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

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

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

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

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

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

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH01_F05_Freed2.png

图 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 模型在创意任务上的影响。不同的任务需要不同的参数。当使用你提供的文档中的文本时，低重复惩罚是有用的。在创意任务如列表生成中，高重复惩罚是有帮助的。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH01_F07_Freed2.png

图 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 显示了一个以流程为导向的机器人转换漏斗，展示了到达每个步骤的相对用户数量。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH01_F08_Freed2.png

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

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

• 吸引他们（A）

• 理解他们（B）

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

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

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

1.3.2 持续改进周期

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH01_F09_Freed2.png

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

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

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

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

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

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

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

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH01_F10_Freed2.png

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

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

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

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH01_F11_Freed2.png

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

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

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH01_F12_Freed2.png

图 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 所示。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH02_F01_Freed2.png

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

此配置总结如下：

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

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

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

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

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

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

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

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

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

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

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

2.1.2 静态问答

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH02_F02_Freed2.png

图 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 显示了开始此动作定义的用户界面。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH02_F03_Freed2.png

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

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

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

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

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

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH02_F04_Freed2.png

图 2.4 定义触发动作的表述

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH02_F05_Freed2.png

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

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH02_F06_Freed2.png

图 2.6 聊天预览链接

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH02_F07_Freed2.png

图 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 所示。当你的对话具有动态性时，创建流程图和示例对话很有帮助。你的团队成员中有些人可能更喜欢图表，有些人更喜欢对话，有些人可能两者都需要。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH02_F08_Freed2.png

图 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 展示了这些步骤在我们助手中的实现方式。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH02_F09_Freed2.png

图 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 就是我们能做的最好了。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH02_F10_Freed2.png

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

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

2.2.1 路由代理

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH02_F11_Freed2.png

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH02_F12_Freed2.png

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

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

按 1 预约……

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

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

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

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

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

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH02_F13_Freed2.png

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH02_F14_Freed2.png

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

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

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

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

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

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH02_F15_Freed2.png

图 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 扩展。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH02_F16_Freed2.png

图 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 任务看起来类似，但具有不同的配置值。此参数集是为提供食谱而调整的。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH02_F17_Freed2.png

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

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

2.3.2 将请求路由到 LLM

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH02_F18_Freed2.png

图 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 显示了动作响应配置。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH02_F19_Freed2.png

图 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 高效地识别这些意图。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH03_F01_Freed2.png

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

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

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

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

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

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

• 我接种后可以旅行吗？

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

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

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

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

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

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

3.2 您的跨职能团队

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

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

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

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH03_F02_Freed2.png

图 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 的第一个商业目标：提供关于新流行病准确且最新的信息。准确性是关键指标。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH03_F03_Freed2.png

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH03_F04_Freed2.png

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH03_F05_Freed2.png

图 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 的有效性。总对话次数帮助我们理解流量，但它并不能帮助我们评估有多少人成功完成了聊天，或者他们聊到了什么程度。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH03_F06_Freed2.png

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

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH03_F07_Freed2.png

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH03_F08_Freed2.png

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

对话结果

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

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

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

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

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

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

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

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH03_F09_Freed2.png

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH03_F10_Freed2.png

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH03_F11_Freed2.png

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

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

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

对于问答机器人：

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

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

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

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

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

• 不需要聊天机器人：

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

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

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

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

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

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

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

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

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

• 不需要聊天机器人：

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

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

对于路由代理：

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

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

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

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

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

• 不需要聊天机器人：

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

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

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH03_F12_Freed2.png

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

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH03_F13_Freed2.png

图 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 团队。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH03_F14_Freed2.png

图 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 展示了问题的一个样本评估。为了更全面地描述，洞察可能包括问题的数量、对话结果、受影响用户的修复复杂性、其他受影响的流程等等。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH03_F15_Freed2.png

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH03_F16_Freed2.png

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

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH03_F17_Freed2.png

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

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

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

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

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

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

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

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

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

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

解决高级修复方案

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

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

为所有修复分配优先级

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH03_F18_Freed2.png

图 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），指示计划中的冲刺。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH03_F19_Freed2.png

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

3.5.2 再次衡量

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH03_F20_Freed2.png

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

练习

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

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

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

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

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

摘要

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

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

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

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

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

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

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

第二部分模式：AI 不理解

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

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

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

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

本章涵盖

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

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

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

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

• 解释初始日志数据

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

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

4.1 理解的基础

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

4.1.1 理解能力薄弱的影响

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH04_F01_Freed2.png

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

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

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

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

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

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

4.1.2 弱理解的原因是什么？

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

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

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

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

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

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH04_F02_Freed2.png

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

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

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

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

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

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

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

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH04_F03_Freed2.png

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

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

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

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH04_F04_Freed2.png

图 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 所示。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH04_F05_Freed2.png

图 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 显示了一个示例训练集。目前还没有太多信息可以提取，但当我们组装测试数据时，这将为我们提供一个比较的基础。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH04_F06_Freed2.png

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

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

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

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

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

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

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

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

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

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

练习

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

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

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

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

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH04_F07_Freed2.png

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

4.4.1 获取生产日志

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

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

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

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH04_F08_Freed2.png

图 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 显示了训练示例的理想化、相对平衡的分布，与日志中观察到的发生次数相比。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH04_F09_Freed2.png

图 4.9 深色条形表示系统中训练示例的数量。浅色条形表示每个意图的标注语料数量。如果您的图表遵循类似的模式，那么您的训练优先级可能与解决方案的需求良好对齐。

训练示例与日志中实际发生之间的明显差异本身并不表明存在问题，但如果准确率低，它可以告知您的优先级。图 4.10 显示了一个与系统训练严重不匹配的标注语料的示例。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH04_F10_Freed2.png

图 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 显示了可视化这些可能结果的混淆矩阵：

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH05_F01_Freed2.png

图 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 中。它还显示了真阴性值（这些值在我们的计算中未使用，但已包括以展示其他结果的范围）。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH05_F02_Freed2.png

图 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 显示了一个虚构场景，其中分类器模型做出了十个完美的预测。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH05_F03_Freed2.png

图 5.3 一条实线对角线表明每个预测意图（用一个字母表示）都与实际意图相匹配。

从对角线偏离的阴影框提供了关于模型在哪里混淆的有用见解，如图 5.4 所示。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH05_F04_Freed2.png

图 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 中，我们可以比较为每个意图训练的示例数量与用于测试的随机选择的日志中存在的示例数量。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH05_F05_Freed2.png

图 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 显示了我们的测试工具提供的混淆矩阵。

在我们的模型中，我们观察到与被盗物品相关的意图之间存在相当多的混淆。解决这个问题的方法之一是合并意图。这必须仔细考虑。意图可能是由设计分别创建的，因为它们都有不同的答案。然而，可以使用实体检测来将流量路由到适当的答案。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH05_F06_Freed2.png

图 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 混淆矩阵看起来也有所改进，有一个相当暗的对角线。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH05_F07_Freed2.png

图 5.7 基线（V1）混淆矩阵与 V8 更新的比较

我们可以进一步迭代以尝试提高一点，但对于这个用例，分类器的准确性目前已经足够好了。使用我们目前有限的现有数据进行的任何进一步调整都可能使我们的模型过度拟合当前的盲测试集。请记住，一个健康的策略是在机器人的整个生命周期中迭代，使用新的日志和更新的盲测试集。

5.3.2 何时停止添加意图

在审查您的日志时，您可能遇到了各种各样的问题，这些问题对于该领域来说是完全合理的，但非常罕见。在我们的日志中，我们看到了以下问题，但没有类似目标的额外表述：

• 我需要一份医生填写的形式，说明一名驾驶员不再安全驾驶。

• 我有一个关于电子签名的问题。

• 获得特殊牌照的过程是怎样的？

我们如何知道何时停止添加意图？最好的做法是让我们的手动注释日志数据来引导我们。我们可以按意图汇总所有示例，并将其绘制成图表，如图 5.8 所示。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH05_F08_Freed2.png

图 5.8 长尾图表的示例。我们用来描述可用训练数据量分布的术语是“短头”和“长尾”。这些术语描述了在柱状图上渲染我们的数据的视觉表示。高量级的意图位于左侧（短头），随着每个意图的量级减少，数据看起来像是从右侧掉落的长尾。

在我们的长尾图表中，我们选择了一个点来区分应该包含在范围内还是范围外。这个点不是一个静态的、规定性的位置。这是一个应该与业务方通过建立创建新意图所需的最小训练示例数量来做出的决定。所有落在这条线左侧的内容可能都应该包含在训练中，因为有证据表明这些主题将被更频繁地询问。所有落在这条线右侧的内容将不会在当前的分类器中进行训练。随着时间的推移，您可能在日志中找到足够的数据来证明添加新意图的合理性。在此之前，您的解决方案将不得不使用以下策略之一来处理这些主题：给出一个响应说机器人不理解，回退到代理升级，添加一个搜索集成以在文档存储库中查找答案，或者实现检索增强生成（RAG）或大型语言模型（LLM）组件来生成答案。

练习

1. 根据您的日志识别新主题，并从日志中找到的表述构建新的意图。

2. 将表述添加到您的盲集中，并测试您的更改。

3. 您的分类器能否在不会对现有意图的性能产生负面影响的情况下识别新的意图？

5.4 使用生成内容补充传统人工智能

在对话式人工智能中，我们通常认为提供的是静态答案（如在经典意图驱动实现中）或完全生成的答案（如在 RAG 模式中）。静态答案满足了一个需求，即答案必须在内容或结构上保持一致性。尽管个性化是可能的，但它通常仅限于定义的实体或其他由上下文驱动的对话条件。这往往会导致更冷、更缺乏个性化的机器人响应。图 5.9 显示了具有相同一般目标但个人情况非常不同的三个用户都收到相同机器人响应的情况。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH05_F09_Freed2.png

图 5.9 在传统的（基于分类的）对话模式中，识别了一个意图，并且对话被配置为提供静态或最小个性化的答案。

5.4.1 为意图结合传统和生成人工智能

我们可以使用混合响应模式来增强用户体验，该模式结合了个性化的生成内容与我们为意图编写的静态预定义答案。我们的目标是承认用户的问题，同时确保重要信息以一致性传达。许多大型语言模型在总结任务上表现出色，因此可以提示模型编写一个传达个性化理解水平的同情信息。图 5.10 显示了从用户的角度看这会是什么样子。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH05_F10_Freed2.png

图 5.10 一个输出响应使用传统人工智能识别正确的意图，然后在其为该意图配置的静态输出响应之前添加生成的文本。生成的问候和总结向用户传达机器人理解了他们的目标以及用户特定的情况细节。

这种模式使用 API 调用 LLM 作为对话步骤。内容由 LLM 生成，并在预定义的输出响应之前交付。图 5.11 显示了这种模式的高级步骤。

https://github.com/OpenDocCN/ibooker-dl-zh/raw/master/docs/eff-cvrs-ai/img/CH05_F11_Freed2.png

图 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 解决方案，这增强了理解的感觉。