通过 Amazon Lex Assisted NLU 提高 Bot 准确率

标题：使用 Amazon Lex 辅助型 NLU 提高机器人准确率 | Amazon Web Services

URL 来源：https://aws.amazon.com/blogs/machine-learning/improve-bot-accuracy-with-amazon-lex-assisted-nlu/

发布时间：2026-05-14T09:28:44-08:00

在 Amazon Lex 中提高机器人准确率的第一步，是处理客户自然表达的方式。您的客户会用数十种不同的方式表达相同请求，将多个信息点合并到一句话中，并且常常表述模糊。Amazon Lex 中的 辅助型 NLU（自然语言理解）功能可帮助您应对这些自然语言变化，从而提升机器人准确率。传统的自然语言理解系统难以应对这种多样性，可能导致用户重复输入或放弃对话。

挑战所在：基于规则的 NLU 系统要求开发人员手动配置每一种可能的用户语句变体，这是一项耗时的任务，仍可能存在覆盖盲区。例如，一个训练为识别“预订酒店”的酒店预订机器人，当客户说“我想为我的旅行预订住宿”时就会失败。像“请为我预订 12 月 15 日至 18 日位于西雅图市中心的套房”这样的复杂请求，往往会导致关键信息（如房型、位置、日期）丢失。而“我需要帮助处理我的预订”这类模糊语句则会让机器人无法判断用户是想预订、查看、修改还是取消订单。

解决方案：Amazon Lex 的辅助型 NLU 功能利用大语言模型（LLM）来理解自然语言的多种表达方式，从而提高机器人的准确率，无需任何手动配置。通过将传统机器学习（ML）与 LLM 相结合，辅助型 NLU 能够有效处理真实客户沟通中的各种情况，打造更自然的对话体验并提升识别准确率。

辅助型 NLU（包括主模式、回退模式和意图消歧）已包含在标准 Amazon Lex 定价中，无需额外费用。

本文将介绍如何高效实施辅助型 NLU，包括如何通过优化意图和槽位描述来改进机器人设计，使用测试工作台验证实现效果，以及为新旧机器人制定从传统 NLU 迁移至辅助型 NLU 的计划。

前提条件：本指南假定您已熟悉 Amazon Lex 的基本概念，如意图（intents）、槽位（slots）和语句（utterances）。如果您是初次接触 Amazon Lex，请先阅读 入门指南。

辅助型 NLU 简介

Amazon Lex 辅助型 NLU 利用大语言模型（LLM）增强意图分类和槽位解析能力。它通过分析您的意图和槽位的名称及描述来理解用户输入，能够处理拼写错误、复杂句式以及多槽位提取，而无需手动配置所有语句变体。辅助型 NLU 在各类自然语言理解任务中显著提升了性能，平均实现 92% 的意图分类准确率和 84% 的槽位解析准确率。已有数百名活跃客户启用该功能，实际部署中的用户反馈证实了这些改进效果——客户报告称意图分类准确率提升了 11–15%，回退响应减少了 23.5%，对噪声输入的处理能力提高了 30%。早期采用者普遍反映其对话式 AI 实现取得了显著进步，部分客户已计划根据初步测试结果进行更大范围的推广。

辅助型 NLU 支持两种运行模式：

• 主模式（Primary mode）：使用 LLM 作为处理每个用户输入的主要方式
• 回退模式（Fallback mode）：优先使用传统 NLU，仅在置信度较低或即将路由至 FallbackIntent 时调用 LLM

您只需在 Amazon Lex 控制台中进行几次选择即可启用辅助型 NLU。进入机器人的区域设置页面，开启辅助型 NLU，选择所需模式，然后重建机器人即可。

如需详细的配置说明、API 参考和分步启用指南，请参阅 Amazon Lex 开发人员指南中的 启用辅助型 NLU。

如需编程方式配置，请参考 NluImprovementSpecification API 参考。

1. 辅助型 NLU 实施最佳实践

以下最佳实践可帮助您充分发挥辅助型 NLU 的潜力，涵盖模式选择、描述撰写、槽位优化和意图消歧等方面。

1.1 运行模式：主模式 vs 回退模式

主模式对每个用户输入都使用 LLM 处理；回退模式则先使用传统 NLU，仅在置信度低或将要路由至 FallbackIntent 时才调用 LLM。

应该：

• 在构建新机器人或训练数据有限（每个意图的样本语句少于 20 条）时使用主模式。
• 示例：一个处理预约挂号的医疗健康机器人，患者可以说“我需要看下我的膝盖”或“下周帮我约一位心脏病专家”，而无需大量语句工程支持。

• 对于已有且表现良好的机器人，建议使用回退模式。
• 示例：一个已稳定运行的银行机器人，当前准确率为 95%，但偶尔会在类似“我的余额怎么样？”而非“查询余额”的表达上失败，此时 LLM 可捕捉这些边缘情况。

• 监控 Amazon CloudWatch Logs 中的 _fulfilledByAssistedNlu_ 指标，以确定适合您场景的模式。如果在回退模式下超过 30% 的请求触发了 LLM 调用，建议切换为主模式以保证一致性。

不应：

• 如果你的机器人表现良好，请切换到主模式（Primary mode）而不进行 A/B 测试，因为引入 A/B 测试可能会增加不必要的延迟，却无法提升准确率。
• 不要假设某一种模式适用于所有场景，因为具体的数据分布和用户语言模式决定了最适合的模式。

1.2 编写高效的意图描述

意图描述本质上是给大语言模型（LLM）的提示词（prompt），而不是供团队查阅的文档。它们是用于分类的主要信号，其质量直接决定识别准确率，正如提示词的质量决定了 LLM 输出的质量。采用一致的结构可带来可靠的结果：Intent to [动作动词] [对象/实体] [上下文/限制条件]

• “Intent to…” 将描述锚定在用户目的上，与 LLM 判断用户意图的方式保持一致。
• 动作动词 能够清晰区分不同意图。例如 Book（预订）、cancel（取消）、modify（修改）和 check（查询）等动词含义明确，有助于 LLM 自信地区分各个意图。
• 对象和实体 明确操作目标。例如 "Book a hotel"（预订酒店）、"book a car"（预订汽车）和 "book a flight"（预订航班）分别对应不同的用户目标。
• 上下文 可解决边界情况。添加如 "Intent to cancel a flight due to medical emergency"（因医疗紧急情况取消航班）或 "Intent to cancel a flight for schedule conflict"（因日程冲突取消航班）等上下文，有助于判断是否符合豁免条件及退款政策。

应该做：

• 使用 "Intent to..." 开头，并紧随一个清晰的动作动词。
• 示例："Intent to book a hotel room for overnight accommodation"（预订用于过夜住宿的酒店房间）。

• 从已有的样本语句中提炼描述内容。这些语句反映了用户真实表达方式，能为 LLM 提供最强的识别信号。
• 示例：像 "book a room" 和 "reserve a suite" 这样的表达可归纳为："Intent to book or reserve a hotel room or suite for an overnight stay"（预订或保留一间用于过夜的酒店客房或套房）。

• 当存在相似意图需要区分时，加入领域上下文。
• 示例："Intent to book a hotel room on StayBooker"（在 StayBooker 上预订酒店房间）有助于 LLM 更准确理解上下文。

• 使用来自真实对话分析中的用户实际用语。
• 示例：如果客户常用 "reservation"（预订），则应始终使用该术语。

• 在部署前，用边界情况的语句测试意图描述的有效性。
• 示例：验证 "I need a place to stay"（我需要一个住的地方）是否正确路由到 BookHotel 意图。

不应该做：

• 留空描述或使用占位符文本。
• 错误示例："TBD" 或 "Intent 1" 对 LLM 完全没有提供任何有效信号。

• 在单个意图中合并多个动作。
• 错误示例："Intent to book and manage hotel reservations"（预订并管理酒店预订）应拆分为多个独立意图。

• 在不同意图之间使用重叠的语言表达。
• 错误示例："Check account balance"（查询账户余额）和 "Check account transactions"（查询账户交易）容易导致分类混淆。

• 在描述中包含槽位值或具体示例。
• 错误示例："Intent to book a hotel in Seattle for 2 nights"（预订西雅图的一家酒店住两晚）过度限制了匹配范围。

1.3 优化槽位描述

槽位描述为 LLM 提供了关于需提取信息及其解释方式的上下文信号。描述越强、越具体，LLM 就越能有效识别并优先提取相关值。随着 Assisted NLU 的发展，槽位描述在提取决策中的权重将越来越大。现在编写精确的槽位描述，可让你的机器人自动受益于未来的功能改进。有效的描述应遵循以下模式：[槽位捕获的内容] [上下文限制] [有效值指引]

• 槽位捕获的内容 定义了该槽位从用户输入中提取的具体信息，例如城市名称、日期或数量。
• 上下文限制 缩小范围。例如 "Check-in date for the hotel reservation, not the checkout or booking date"（酒店预订的入住日期，而非退房或预订日期）可帮助 LLM 从 "December 15th through the 18th"（12月15日至18日）中正确提取入住日期。
• 有效值指引 解决歧义。例如 "Three-letter ISO currency code such as USD, EUR, or JPY"（三位字母的 ISO 货币代码，如 USD、EUR 或 JPY）能让 LLM 将“euros”（欧元）或“Japanese yen”（日元）自动转换为标准代码，而无需在槽位类型中维护完整的货币列表。

应该做：

• 使用槽位描述来提取没有专用内置槽位类型支持的信息。
• 示例：要捕获机场代码，可使用 AMAZON.AlphaNumeric 类型，并添加描述 "A valid IATA airport code (for example, SEA, JFK, LAX)"（有效的 IATA 机场代码，例如 SEA、JFK、LAX）。LLM 会利用此上下文从自然语言中提取代码，例如将 "I'm flying out of Seattle"（我要从西雅图出发）映射为 SEA，而无需在自定义槽位类型中枚举所有可能值。

• 如果有两个 AMAZON.Number 类型的槽位（如“入住天数”和“客人数量”），描述就尤为重要，以帮助 LLM 区分相似的槽位类型。
• 示例："Number of nights for the hotel stay"（酒店住宿的天数）与 "Number of guests checking in"（办理入住的客人数量）——若无此类描述，LLM 可能难以将数字 "3" 正确分配到对应槽位。

• 明确槽位在特定意图中的角色。
• 示例：在酒店预订意图中使用 "Date of check-in"（入住日期）可消除与退房日期、预订日期之间的歧义。

• 添加符合业务规则的约束说明。
• 示例："Number of nights in the hotel stay"（酒店住宿的天数）明确这是持续时间计数，而非房间数量或客人数量。

• 使用槽位描述为启用了扩展值解析的自定义槽位定义每个值的含义。
• 示例：一个 RoomType 自定义槽位包含 Standard（标准间）、Deluxe（豪华间）和 Suite（套房）三个值，并附描述 "Type of hotel room. Standard is a basic room, Deluxe is a mid-tier room with extra amenities, Suite is the top-tier luxury room with the most space and best features and kitchen attached"（酒店房间类型。标准间为基本房型，豪华间为中档房型并配有额外设施，套房为顶级奢华房型，空间最大、配置最佳且带厨房）。LLM 可基于该语义上下文，将用户说的“带厨房的房间”或“最大的房间”正确解析为 Suite。

不应该做：

• 保持槽位描述为空，尤其是自定义槽位。
• 反面示例："Payment" 没有描述，导致大语言模型（LLM）无法判断应预期哪些货币格式。

• 假设仅凭槽位类型就已提供足够上下文。
• 反面示例：AMAZON.Number 可能表示入住晚数、客人数量、房间数或确认号码，若无描述则容易混淆。

• 使用与槽位类型冲突的描述。
• 反面示例：描述为 "account number" 却使用 AMAZON.Number 类型，可能导致带格式的账号无法正确提取。

• 在业务逻辑变更后忘记更新描述。
• 反面示例：服务范围已扩展至国际城市，但描述中仍保留 "United States only"。

1.4 意图消歧最佳实践

当多个意图可能匹配用户输入时，辅助 NLU 会提供消歧选项以明确用户目标。设计良好的消歧机制可减少交互摩擦，使对话顺利进行。

应该做到：

• 使用清晰、互不重叠的意图名称和描述。这些是 LLM 进行消歧决策的主要依据。
• 示例："BookHotelRoom" 描述为 "为未来日期预订酒店房间"，对比 "CancelHotelReservation" 描述为 "取消现有酒店预订" —— 目的明确区分。

• 为技术性意图名称提供用户友好的显示名称。确保显示名称与实际意图名称一致并能清晰表达其含义。
• 示例：意图名称 "ModifyReservationDates" 对应显示名称 "更改我的预订日期"，让用户立即理解该选项。

• 合理配置最大意图选项数量。通过测试平衡选项数量，既要提供足够选择，又要避免因选项过多导致决策困难。
• 示例：最多限制为 3–4 个选项；如果 "book hotel" 匹配到 6 个意图，则说明意图设计过于碎片化。

• 编写简洁的消歧提示语，并回应用户的原始输入。自然引导用户选择正确的意图选项。
• 示例：使用 "我可以帮您处理酒店预订。您是想：" 后接清晰选项，而不是 "请选择一个意图："。

• 使用模糊表达充分测试。验证消歧流程是否自然，并始终呈现正确的意图选项。
• 示例：用 "我需要帮助处理我的预订" 测试预订、修改和取消等意图，确保正确选项出现。

不应做的：

• 忽视消歧模式。监控哪些意图频繁触发消歧，并优化它们以减少混淆。
• 反面示例：如果 "check my reservation" 频繁在 "ViewReservation"、"ModifyReservation" 和 "VerifyReservation" 之间触发消歧，应合并或澄清这些意图。

• 将消歧作为万能解决方案。如果大多数对话都进入消歧流程，说明意图设计本身需要根本性改进。
• 反面示例：大多数用户请求都触发消歧，表明意图定义存在重叠问题，需重新设计，而非仅优化消歧消息。

• 忽略消歧失败的处理。当用户未选择任何选项时，应有明确的备用策略。
• 反面示例：当用户说 "都不是" 或 "其他" 时反复显示相同消歧选项，而不转接人工支持。

• 将消歧视为一劳永逸的设置。应持续分析用户选择，识别混淆点并逐步优化意图划分。
• 反面示例：从不查看用户选择了哪些消歧选项；如果每次展示三个选项时用户总是选第二个，说明第一和第三个选项可能是多余的。

应用上述最佳实践后，需通过系统性测试验证配置效果。

2. 测试您的辅助 NLU 实现

完成意图和槽位描述配置后，下一步是验证。使用 Amazon Lex 测试工作台（Test Workbench）评估您的辅助 NLU 配置对现实世界多样化表达的处理能力。

有关测试工作台的设置和使用方法，请参阅 测试工作台文档 和 演示视频。

重要提示：配置测试集执行时，请确保选择已启用辅助 NLU 的机器人及其别名。只有当所选别名指向配置了 Fallback 或 Primary 模式的版本时，测试才会触发辅助 NLU 功能。

2.1 应测试的内容

重点关注辅助 NLU 最具价值的场景：边缘情况 —— 使用偏离标准表达方式的测试输入，验证辅助 NLU 是否能处理现实中的复杂情况：

• 拼写错误和语法错误："i wanna book an hotell"
• 口语化表达："hook me up with a room downtown"
• 模糊请求："I need transportation"
• 不完整语句："booking for next week"

#### 槽位变体

对于内置槽位，测试各种变体，如日期格式（“next Tuesday”、“the 15th”）、地点别名（“NYC”、“New York City”）、名字变体（“Bob” vs “Robert”）以及邮箱格式（“john dot doe at gmail dot com”）。

对于自定义槽位，测试用户表达是否能正确映射到预定义值，尤其是在扩展模式下。例如，验证“largest room”能否正确解析为 RoomType 槽位的“Suite”。

与开放式生成式 AI 应用中大语言模型（LLM）直接向用户输出自由形式文本不同，辅助型自然语言理解（Assisted NLU）严格将 LLM 用作受你的机器人定义约束的分类和提取引擎。LLM 只能选择你在机器人定义中设定的意图，并提取预定义的槽位值，无法创建新的意图、触发机器人定义之外的操作，或向最终用户返回原始的 LLM 生成文本。这种以机器人定义为边界架构显著缩小了提示注入攻击的攻击面，但你仍应验证对抗性输入是否可预测地路由到 FallbackIntent。

2.2 分析测试结果

测试运行完成后，使用通过率来确定改进工作的优先级。通过率较低的意图为高优先级关注对象：

• 0–30%：高优先级。重写意图描述，并检查是否存在与其他意图混淆的情况。
• 30–70%：中优先级。分析失败语句中的模式，并优化描述内容。
• 70–100%：低优先级。仅需微调或无需操作。下载详细结果并检查以下内容：
• 预期意图 vs 实际意图：识别分类错误
• 实际输出槽位值 vs 预期值：发现提取或解析不匹配问题
• 用户语句：导致失败的输入内容
• 错误信息：说明失败原因
• 端到端会话结果：整个对话流程的整体通过/失败状态，而不仅是单轮交互结果

2.3 迭代优化描述

当测试结果显示存在分类错误时，请使用以下迭代流程优化你的描述：

1. 导出详细结果，并筛选出失败的语句
2. 确定这些语句被错误分类到了哪个意图
3. 对比两个意图的描述
4. 重写失败意图的描述，突出其与其他意图的区别
5. 使用相同的测试集重新运行测试，验证改进效果

2.4 安全迭代的版本控制

使用 Amazon Lex 的版本控制和别名功能，在不影响生产流量的前提下安全测试描述变更：

1. 在 Draft 版本中优化描述
2. 使用 TestBotAlias 进行测试
3. 当结果符合预期时，创建一个编号版本
4. 将 BETA 别名指向新版本进行验证，再推广至 PROD
5. 如需回滚，可将 PROD 重新指向之前的版本

详情请参阅 版本控制与别名指南。

访问控制：使用 AWS 身份和访问管理（IAM）策略限制可修改机器人定义、意图和槽位描述的人员。仅授权开发人员拥有 lex:UpdateBotLocale、lex:UpdateIntent 和 lex:UpdateSlot 权限。这可以防止未经授权的更改导致 NLU 准确性下降或引入非预期行为。更多详情，请参阅 Amazon Lex 开发者指南中的 Amazon Lex 身份与访问管理。

2.5 生产环境监控

在生产环境中启用会话日志，以跟踪 Assisted NLU 在真实流量下的表现。配置方法详见 配置会话日志。

需重点监控的关键字段：

• fulfilledByAssistedNlu：布尔标志，指示 LLM 是否处理了分类或槽位解析
• nluConfidence：所选意图的置信度得分
• missedUtterance：布尔值，表示是否触发了 Fallback 意图

#### 需跟踪的内容

• Assisted NLU 调用频率：Fallback 模式下调用频率过高可能表明样本语句需要扩充
• 意图识别准确率：对比启用 Assisted NLU 前后的传统 NLU 表现
• 槽位解析准确率：对比启用 Assisted NLU 前后的传统 NLU 表现
• 未命中语句模式：按主题归类，识别意图覆盖范围或描述中的空白
• 消歧频率：监控哪些意图对最常触发澄清请求

A/B 测试模式 要比较 Primary 与 Fallback 模式，可分别为两种模式创建独立的机器人版本，将其关联到不同的别名，并在 CloudWatch 中对比各别名的指标数据。

3. 推荐的上线策略

在优化完描述并通过测试验证后，即可规划生产环境上线。如果你正在构建一个新的机器人，建议从 Primary 模式开始。每个意图先提供 10–15 条样本语句，并投入精力撰写高质量的意图和槽位描述。如果你已有表现良好的现有机器人，则建议从 Fallback 模式起步，使 LLM 仅在传统 NLU 不确定时介入。通过 A/B 测试对比性能表现，再决定是否切换至 Primary 模式；同时保留回滚能力，即维护一个可随时恢复的先前机器人版本。

上线检查清单

• [ ] 已记录基线指标
• [ ] 已在开发环境中使用边缘案例完成测试
• [ ] 已启用会话日志
• [ ] 已配置 CloudWatch 仪表板
• [ ] 已定义回滚流程

结论

本文介绍了如何利用 Amazon Lex Assisted NLU 提升机器人准确性。你学习了如何编写高效的意图和槽位描述，使用测试工作台验证配置，并通过 Primary 或 Fallback 模式安全地将 Assisted NLU 推向生产环境。

准备好了吗？立即在你的机器人上启用 Assisted NLU！

• * *

关于作者