你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

计划 LUIS 应用

重要

LUIS 将于 2025 年 10 月 1 日停用，从 2023 年 4 月 1 日开始，你将无法创建新的 LUIS 资源。 我们建议迁移 LUIS 应用程序到对话语言理解，以便获得持续的产品支持和多语言功能并从中受益。

语言理解 (LUIS) 应用架构包含与主题域相关的意向和实体。 意向对用户言语分类，实体从用户言语中提取数据。 与主题域相关的意向和实体。 意向会将用户语句分类。

LUIS 应用在迭代开发时学习和执行效率最高。 下面是典型的迭代周期：

1. 创建新版本
2. 编辑 LUIS 应用架构。 这包括：
   • 意向和示例言语
   • 实体
   • 功能
3. 训练、测试和发布
4. 通过查看发送到预测终结点的语句来测试主动学习
5. 从终结点查询收集数据

标识域

LUIS 应用以主题域为中心。 例如，可能有一个用于预订门票、航班、酒店和租车的旅行应用。 另一应用则用于提供与锻炼、跟踪健身活动和设定目标相关的内容。 标识域可帮助你查找与你的域相关的单词或短语。

提示

LUIS 提供许多常见场景的预生成域。 检查是否可使用预生成域作为应用的起始点。

标识意向

考虑一下对应用程序的任务极为重要的意向。

以旅行应用为例，该应用可预订航班并检查用户目的地的天气。 可为这些操作定义两个意向：BookFlight 和 GetWeather。

对于具有更多功能的复杂应用，意向可能也就更多，应仔细进行定义，使其不要太具体。 例如，BookFlight 和 BookHotel 可能是单独的意向，但 BookInternationalFlight 和 BookDomesticFlight 则过于相似。

备注

最佳做法是仅使用所需意向来执行应用功能。 如果定义的意向过多，LUIS 将难以对话语进行正确分类。 如果定义的太少，则言语可能太过笼统以致于重叠。

如果不需标识整个用户意向，请将所有示例性的用户言语添加到 None 意向。 如果应用需要更多意向，可以在以后创建它们。

为每个意向创建示例陈述

首先，避免为每个意向创建太多语句。 确定应用所需的意向后，为每个意向创建 15 到 30 个示例语句。 每个言语应不同于前面提供的言语。 包括各种字数统计、单词选择、动词时态和标点。

有关详细信息，请参阅了解适用于 LUIS 应用的言语。

标识实体

在示例陈述中，标识要提取的实体。 若要预订航班，则需要“目的地”、“日期”、“航空公司”、“机票类别”和“旅行舱位”等信息。 为这些数据类型创建实体，然后在示例言语中标记实体。 实体对于实现意向很重要。

确定要在应用中使用哪些实体后，请记住，有不同类型的实体可用于捕获对象类型间的关系。 有关不同类型的详细信息，请参阅 LUIS 中的实体。

提示

LUIS 提供预生成的实体，用于常见的聊天式用户方案。 考虑从使用预生成的实体着手，方便应用程序开发。

意向与实体

意向是整个言语的所需结果，而实体是从言语中提取的数据片段。 意向通常与客户端应用程序应采取的操作相关联。 实体是执行此操作所需的信息。 从编程的角度讲，意向会触发方法调用，而实体将用作该方法调用的参数。

以下言语肯定包含意向，同时可能包含实体：

“购买从西雅图飞往开罗的机票”

以下言语包含单个意向：

• 购买机票

以下言语可能包含多个实体：

• Seattle（出发地）和 Cairo（目的地）的地点
• 数量为一张机票

解决具有多个功能或意向的语句

在许多情况下，尤其是在处理自然聊天时，用户提供的言语可能包含多个功能或意向。 为了解决此问题，一般的策略是理解输出可以由意向和实体表示。 此表示形式应可映射到客户端应用程序的操作，不必局限于意向。

Int-ent-ties 是一个概念，即操作（通常被理解为意向）也可作为应用输出中的实体被捕获，并映射到特定操作。 例如，求反通常依赖于意向和实体来进行完全提取。 请考虑以下两个语句，它们在选词方面相近，但结果却有所不同：

• “请帮我预定从开罗飞往西雅图的航班”
• “取消我从开罗飞往西雅图的航班”

你应该使用 FlightAction 机器学习实体创建单个意向，而不是拥有两个单独的意向。 此机器学习实体应该针对预定请求和取消请求以及出发地或目的地提取操作的详细信息。

此 FlightAction 实体将由以下顶级机器学习实体和子实体构成：

• FlightAction
  • 操作
  • 源
  • 目标

为了帮助进行提取，可以在子实体中添加特征。 你将根据自己期望在用户语句中看到的词汇和自己希望在预测响应中返回的值来选择特征。

最佳实践

规划架构

开始构建应用的架构之前，应确定你计划如何以及在何处使用此应用。 规划越细致、越具体，应用就越好。

• 调查目标用户
• 定义端到端角色以表示应用 - 声音、头像、问题处理（主动、被动）
• 确定用户交互通道（例如文本或语音），将其提供给现有解决方案或为此应用创建新解决方案
• 端到端用户旅程
  • 希望此应用执行哪些操作？不执行哪些操作？ 操作的优先级是什么？
  • 主要用例有哪些？
• 收集数据 - 了解如何收集和准备数据

请勿使用添加的每个话语示例进行训练和发布

在进行训练和发布之前添加 10 或 15 个话语。 这样可以了解对预测准确性的影响。 添加单个话语可能不会对分数产生明显影响。

请勿将 LUIS 用作培训平台

LUIS 特定于语言模型的域。 但并不意味着将其用作常规自然语言训练平台。

使用版本以迭代方式生成应用

每个创作周期都应包含在从现有版本克隆的新版本中。

不要过快发布

如果过快地发布应用并且没有进行适当的规划，可能会导致出现多个问题，例如：

• 在实际场景下，你的应用将无法在可接受的性能级别上运行。
• 架构（意向和实体）可能不适用，如果已按该架构开发了客户端应用逻辑，则可能需要从做。 这可能会导致正在处理的项目意外延迟并产生额外的费用。
• 你添加到模型中的语句可能会对示例语句造成难以调试和识别的偏差。 它还会导致在已提交到特定架构后难以消除歧义。

应监视应用的性能

使用批量测试集监视预测准确性。

保留一个独立的言语集，不将其用作示例言语或终结点言语。 针对测试集不断改进应用。 调整测试集以反映真实的用户话语。 使用此测试集来评估每次迭代的或每个版本的应用。

不要创建包含所有可能值的短语列表

在短语列表中提供一些示例，但无需包含所有字词或短语。 LUIS 会对上下文进行一般化并将其纳入考虑。

后续步骤

意向