[Azure botframework sdk]bot framework Orchestrator技术概述

Orchestrator是自2018年以来在聊天机器人中使用的Bot Framework Dispatcher的替代品。它为机器人开发人员提供了最先进的自然语言理解方法，同时使语言建模过程快速，不需要深度神经网络（DNN）、Transformers或自然语言处理（NLP）方面的专业知识。这项工作是与该领域的行业专家共同撰写的，其中包括通用语言理解评估（GLUE）排行榜中使用的一些顶级方法。Orchestrator将继续发展并采用科学和行业的最新进展。

Orchestrator支持机器人的可组合性，允许以简单的方式重用社区贡献的技能或整个机器人，而不需要耗时的语言模型再培训。我们的目标是支持社区并继续对提供的反馈做出回应。

设计目标和亮点

感谢社区的反馈，我们编制了一份目标和要求清单，这些目标和要求在Orchestrator的初始版本中得到了解决。路线图部分描述了即将发布的版本中计划的额外工作。

无需ML或NLP专业知识

到目前为止，在传统方法中，为了训练一个健壮的语言模型，需要大量的专业知识和时间来生成一个鲁棒的模型。例如，聊天机器人作者会关注适当的数据分布、数据不平衡、特征级问题，包括各种同义词列表的生成等。如果不注意这些方面，最终的模型质量往往很差。对于Orchestrator，开发人员不再关心这些方面，也不需要相关的专业知识来创建健壮的语言模型（评估结果见模型）。

需要最少或不需要模型训练

构建语言模型需要多次迭代，添加或删除训练示例，然后训练模型并进行评估。这个过程可能需要几天甚至几周的时间才能达到令人满意的结果。此外，当使用变换器模型进行分类任务时，会添加和训练一个或多个分类层，这使得这个过程昂贵、耗时，并且通常需要GPU。

为了解决这些问题，我们选择了一种基于示例的方法，其中语言模型被定义为一组标记的示例。在Orchestrator中，模型示例表示为从给定文本的转换器模型中获得的数字向量（嵌入），相应的技能能够处理该文本（这是Orchestrator中应用程序语言模型的定义）。在运行时，根据技能计算新示例与现有模型示例的相似性。采用K个最接近样本的加权平均值（KNN算法）来确定分类结果。这种方法不需要显式的训练步骤，只需要计算模型示例的嵌入。该操作在没有GPU和远程服务器往返的情况下在本地执行。

本地快速库，而不是远程服务

Orchestrator核心是用C++编写的，可以作为C#、Node.js以及Python和Java的库使用。该库可以直接由bot代码使用（首选方法），也可以在proc之外或远程服务器上托管。在本地运行消除了额外的服务往返成本（延迟和计价器）。当使用Orchestrator跨不同的LU/QnA服务进行调度时，这尤其有用。

例如，使用英语预训练语言模型（pretraining.20200924.microsoft.com.dte.00.06.en.onx）大约需要260 MB，使用此初始模型对新示例进行分类大约需要10毫秒（取决于文本长度）。这些数字只是为了说明性能。随着我们改进模型或添加其他语言，这些数字可能会发生变化。

最先进的分类，训练示例很少

开发人员经常面临一个问题，即可用的培训示例很少，无法正确定义语言模型。有了Orchestrator使用的强大的预训练SOTA模型，这不再是一个问题。即使只是一个意图/技能的例子，在做出相当准确的预测方面也会有很大的帮助。例如，仅用一个例子“你好”定义的“问候”意图可以成功预测“你今天怎么样”或“早上好”等例子。预训练模型的强大功能及其使用极少数简单（简短）示例的泛化能力令人印象深刻。这种能力通常被称为“少量学习”，包括编排器也支持的“一次性学习”。这种能力之所以成为可能，得益于在大数据集上训练的预训练模型，然后针对大数据上的对话进行了优化。

无需额外示例即可对“未知”意图进行分类

开发人员在处理意图分类决策时面临的另一个常见挑战是确定是否应该触发得分最高的意图。Orchestrator为此提供了一种解决方案。它的分数可以被解释为以这样的方式校准的概率，即0.5的分数被定义为以平衡精确度和召回率的方式选择的“未知”意图的最大分数。如果最高意图的得分为0.5或更低，则查询/请求应被视为“未知”意图，并可能触发机器人的后续问题。另一方面，如果两个意图的得分高于0.5，则两个意图（技能）都可能被触发。如果机器人一次只处理一个意图，那么应用程序规则或其他优先级可以选择在这种情况下触发的意图。

“未知”意图的分类是在不需要任何定义“未知”（通常称为“零样本学习”）的例子的情况下完成的，这将是具有挑战性的。如果没有经过大量预训练的语言模型，很难实现这一点，尤其是机器人应用程序可能会在未来扩展到迄今为止“未知”的额外技能。

扩展以支持Bot Builder技能

虽然调度器的重点是帮助在多个路易斯应用程序和QnA Maker KB之间触发，但编排器将此功能扩展为支持通用的机器人构建技能，以允许机器人技能的可组合性。社区开发和提供的技能可以很容易地重用并集成到新的机器人中，而不需要重新培训语言模型。Orchestrator提供了一个工具包来评估此扩展，以识别开发人员应审查的模糊示例。

易于组合

社区提供的技能甚至整个机器人程序的语言模型可以通过添加快照集成到新的机器人程序中（有关更多信息，请参阅API参考资料）。模型快照代表技能、技能组甚至整个机器人，包含触发它们所需的所有语言模型数据。导入新的模型快照可以在运行时完成，只需要几毫秒。这为有趣的场景提供了机会，在这些场景中，可以修改模型以强调可能触发的更深入、更专业的技能。这种灵活性在复杂对话的情况下是有益的，甚至在处理可能包括模型快照的对话上下文时也是有益的。

解释分类结果的能力

解释分类结果的能力在应用程序中可能很重要。一般来说，试图解释深度学习模型（如变压器）的结果可能非常具有挑战性。Orchestrator通过在模型中提供与被评估的示例最接近的示例来实现这一点。在分类错误的情况下，这个简单的机制可以帮助开发人员确定是否应该添加一个定义技能的新示例，或者模型中的现有示例是否被错误标记。此功能简化了机器人主动学习的实现，非专家也可以完成（只需要语言流利）。

高性能

Orchestrator的核心是用C++编写的。由于其运行时算法可以很容易地矢量化，Orchestrator核心利用了主流CPU（SIMD）支持的矢量运算符，而不需要GPU。因此，即使对于最大的模型，与其他局部处理任务相比，KNN推理过程中的相似性计算时间也可以忽略不计。

紧凑型模型

Orchestrator中的转换器模型生成的嵌入相对较大，每个示例的大小超过3kB（嵌入的大小）。如果直接使用这些大型嵌入，不仅会显著增加运行时的内存需求，还会增加大量的CPU处理成本。一种常用的相似性度量，余弦相似性，具有这种大小的嵌入和KNN处理，将在推理过程中增加大量开销。与这种方法不同，Orchestrator使用了一种量化方法，将嵌入的大小缩小到100字节以下，在保持相同精度的同时将处理时间减少了50倍以上。这项技术已经在Orchestrator的初始公开预览版中可用。

运行时灵活性

需要重申的是，Orchestrator运行时比典型的转换器或通用ML运行时具有更大的灵活性和功能性。除了推理功能外，开发人员还可以选择在机器人代码中启用以下功能：

实时修改语言模型-添加额外的功能（用额外的技能或示例扩展语言模型）或使用主动学习技术进行持续的模型改进（在即将发布的版本中将发布辅助主动学习的专用工具）。

实时修改语言模型行为-可以调整运行时参数，而无需重新启动进程，甚至无需重新加载模型。这包括调整意图触发的严格程度（在精确度和召回率之间进行权衡），可以根据对话的阶段动态调整；或者通过修改KNN-K值来调整对定义模型的错误标记或低质量示例的弹性（例如，模型示例是众包的，尚未清理，或者允许许多人动态调整模型，或者将技能语言模型定义添加到机器人中，但尚未评估）。

请点击此处查看更多关于定量模型分析的信息。

路线图

在即将发布的版本中，我们计划在几个领域扩展Orchestrator：

实体识别

作为意图触发的一部分，一个常见的功能是为触发的意图提供“参数”，这些意图是查询文本中识别的实体。已经是初始预览的一部分的Orchestrator接口支持处理识别的实体。此功能以及相应的预构建语言模型将在即将发布的版本中提供。

多语言模型

在即将发布的版本中，一个重要的扩展是支持多语言模型，也可能支持其他微软产品支持的语言优先的专业国际模型。

基于社区反馈的可能的其他改进

随着我们从社区收集更多反馈，我们可能会在即将发布的版本中解决其他改进领域。我们鼓励用户通过GitHub提交。