由于诸如面向服务的体系结构，云计算和物联网（IoT）等技术的发展，应用程序编程接口（API）在虚拟和物理世界中都扮演着越来越重要的角色。 今天，微软研究部的同事们分享了他们在自然语言界面（自然语言界面）领域的最佳实践。 立即加入！
通过Web API专门用于天气，体育和金融的基于云的Web服务向最终用户提供数据和服务，而IoT设备使网络上的其他设备能够使用其功能。
通常，API用于各种软件：桌面应用程序，网站和移动应用程序。 它们还通过图形用户界面（GUI）为用户提供服务。 图形界面为计算机的普及做出了巨大的贡献，但是，随着计算机技术的发展，它们的许多局限性越来越明显。 随着设备变得越来越小，越来越移动，越来越智能，例如在便携式设备或连接到IoT的设备上，对屏幕上的图形显示提出了越来越多的要求。
当使用各种服务和设备时，用户还被迫习惯于各种各样的图形界面。 随着可用服务和设备数量的增加，培训和适应用户的成本也随之增加。 自然语言接口（NLI）作为单个智能工具在各种服务器端服务和设备中具有巨大的潜力。 NLI具有不可思议的功能，可以确定用户意图并识别上下文信息，这使应用程序（例如虚拟助手）对用户而言更加方便。
我们研究了API的自然语言接口（NL2API）。 与通用NLI（例如虚拟助手）不同，我们试图了解如何为单个Web API（例如日历服务API）创建NLI。 将来，这些NL2API将能够使API民主化，从而帮助用户与软件系统进行交互。 他们还可以通过启用分布式开发来解决通用虚拟助手的可伸缩性问题。 虚拟助手的有用性在很大程度上取决于其功能的广度，即其支持的服务数量。
但是，一次将Web服务集成到虚拟助手中是一项艰巨的工作。 如果单个Web服务提供商可以轻松地为其API创建NLI，则集成成本可以大大降低。 虚拟助手不必为不同的Web服务处理不同的界面。 对于他来说，仅集成单个NL2API就足够了，这些NL2API通过自然语言实现了统一性。 NL2API还可以促进Web服务，编程推荐系统的开发以及API的帮助。 因此，您不必记住大量可用的Web API及其语法。
图1.为API创建自然语言接口的方法。 左：传统方法教语言感知模型识别自然语言中的意图，其他模型学习提取与每个意图相关的单元格，然后手动将它们与API请求匹配。 正确：我们的方法可以将自然语言直接转换为API请求。NL2API的主要任务是识别用户自然语言中的表达式并将其转换为API请求。 更准确地说，我们专注于以REST体系结构的相似性创建的Web API，即RESTful API。 RESTful API被广泛用于Web服务，物联网设备以及智能手机应用程序。 Microsoft Graph API的示例如图1所示。
图的左侧显示了构建自然语言的传统方法，在该方法中，我们教语言感知模型来识别意图，并教其他模型来提取与每个意图相关联的单元格，然后通过编写代码将其与API请求手动匹配。 而是（如图右侧所示），我们可以学习如何将自然语言中的表达式直接转换为API请求。 作为研究的一部分，我们将系统用于
Microsoft Graph API包中的
API 。 Microsoft Graph Web API使开发人员可以访问可提高工作效率的数据：邮件，日历，联系人，文档，目录，设备等。
图2. Microsoft Graph Web API使开发人员能够访问可提高生产率的数据：邮件，日历，联系人，文档，目录，设备等。我们正在开发的模型的要求之一是能够创建详细的用户界面。 如果团队没有得到正确的认可，大多数现有的NLI都无法为用户提供帮助。 我们建议更详细的用户体验可能会使NLI更加方便。
我们开发了一个基于“从序列到序列”的模块化模型（请参见图3），以提供与NLI的详细交互。 为此，我们使用一种基于“从序列到序列”原理的体系结构，但与此同时，我们将解密结果分解为几个解释的单元，称为模块。
每个模块都会尝试预测预定结果，例如，通过使用基于NL2API中收到的语句的特定参数来预测预定结果。 通过简单的比较，用户可以轻松了解任何模块的预测结果，并在模块级别与系统进行交互。 我们模型中的每个模块都会产生一致的结果，而不是连续的状态。
图3.从序列到序列的模块化模型。 控制器激活多个模块，每个模块创建一个参数。模块：首先，我们定义什么是模块。 模块是专门的神经网络，旨在执行预测序列的特定任务。 在NL2API中，不同的模块对应于不同的参数。 例如，在GET-Messages API中，模块将是FILTER（发送方），FILTER（isRead），SELECT（附加），ORDERBY（receivedDateTime），SEARCH等。模块的任务是识别传入的语句并在激活时创建完整参数。 为此，模块必须根据传入的语句确定其参数的值。
例如，如果传入的语句听起来像“关于博士学位论文的未读信”，则SEARCH模块必须预测SEARCH参数的值为“博士论文”，并生成完整的“ SEARCH Doctors Dissertation”参数作为输出序列。 以此类推，FILTER（isRead）模块应该记住诸如“未读电子邮件”，“未读电子邮件”和“尚未读电子邮件”之类的短语表示其参数值应为“ False” 。
很自然，下一步就是创建解码器模块来确定要关注的内容，就像通常的“从序列到序列”模型一样。 但是，我们现在有了几个解码器，而不是一个用于所有功能的解码器，每个解码器专门用于预测特定参数。 此外，由于每个模块都有明确定义的术语，因此在模块级别配置用户交互变得更加容易。
主持人：每个介绍短语仅使用几个模块。 调节器的任务是确定它将运行哪些模块。 因此，调节器还是确定值得关注的内容的解码器。 通过编码一条语句并将其转换为输入，它创建了一系列称为电路的模块。 然后，模块创建与它们相对应的参数，最后，这些参数被组合以形成对API的最终请求。
通过将标准“按序排列”模型中的复杂预测过程分解为称为模块的小型，高度专业化的预测单元，可以轻松地向用户解释该预测模型。 然后，利用用户的反馈，将有可能在最低级别上纠正可能的预测误差。 在我们的研究中，我们通过比较交互式NLI和非交互式版本的NLI（通过模拟或通过涉及使用真正有效API的人员的实验）来检验我们的假设。 我们可以证明，使用交互式NLI，用户可以更频繁，更快地获得成功，从而提高用户满意度。
很快，我们将发布
一篇文章 ，详细介绍为Web API创建自然语言接口的过程。 敬请期待！