哈Ha！ 最近，我们
简要讨论了自然语言接口。 好吧，今天我们还没有简要介绍。 在剪辑下，您将找到有关为Web-API创建NL2API的完整故事。 我们来自Research的同事尝试了一种独特的方法来收集框架的培训数据。 立即加入！
注解
随着Internet向面向服务的体系结构的发展，软件接口（API）作为提供对数据，服务和设备的访问的方式变得越来越重要。 我们正在研究为API（NL2API）创建自然语言界面的问题，重点是Web服务。 NL2API解决方案具有许多潜在的好处，例如，有助于简化Web服务到虚拟助手的集成。
我们提供第一个综合平台（框架），使您可以为特定的Web API创建NL2API。 关键任务是收集用于训练的数据，即“ NL命令-API调用”对，从而使NL2API可以研究两个没有严格定义格式和形式化API调用的NL命令的语义。 我们提供我们自己的独特方法来使用众包收集NL2API的培训数据-吸引了许多远程工作人员来生成各种NL团队。 我们优化了众包流程，以降低成本。
特别是，我们提供了一个根本上全新的分层概率模型，该模型将帮助我们分配众包预算，主要是在那些对学习NL2API具有高价值的API调用之间进行分配。 我们将我们的框架应用于真实的API，并表明它使您能够以最低的成本收集高质量的培训数据，并从头开始创建高性能的NL2API。 我们还证明了我们的众包模型提高了此过程的效率，也就是说，在其框架内收集的训练数据提供了更高的NL2API性能，该性能大大超过了基线。
引言
由于诸如面向服务的体系结构（SOA），云计算和物联网（IoT）等技术的发展，应用程序编程接口（API）在虚拟和物理世界中都扮演着越来越重要的角色。 例如，通过Web API托管在云中的Web服务（天气，体育，金融等）为最终用户提供数据和服务，而IoT设备使其他网络设备能够使用其功能。
图1.组装成对的“ NL命令（左）和API调用（右）”
我们的框架，并与IFTTT进行比较。 GET-Messages和GET-Events是分别用于查找电子邮件和日历事件的两个Web API。 可以使用各种参数来调用API。 我们专注于完全参数化的API调用，而IFTTT限于具有简单参数的API。通常，API用于各种软件：桌面应用程序，网站和移动应用程序。 它们还通过图形用户界面（GUI）为用户提供服务。 GUI为计算机的普及做出了巨大的贡献，但是随着计算机技术的发展，它的许多局限性越来越明显。 一方面，随着设备变得更小，更移动和更智能，例如，对于便携式设备或连接到IoT的设备，屏幕上图形显示的要求不断增加。
另一方面，用户必须适应于各种服务和设备的各种专用GUI。 随着可用服务和设备数量的增加，培训和用户适应的成本也随之增加。 Apple Siri和Microsoft Cortana虚拟助手之类的自然语言界面（NLI），也称为对话或对话界面（CUI），作为用于多种服务器服务和设备的单一智能工具，具有巨大的潜力。
在本文中，我们考虑为API（NL2API）创建自然语言接口的问题。 但是，与虚拟助手不同的是，它们不是通用的NLI，
我们正在开发为特定的Web API创建NLI的方法，例如ESPN1多运动服务之类的Web服务API。 这样的NL2API通过启用分布式开发可以解决通用NLI的可伸缩性问题。 虚拟助手的有用性在很大程度上取决于其功能的广度，即其支持的服务数量。
但是，一次将Web服务集成到虚拟助手中是一项艰巨的工作。 如果各个Web服务提供商有一种便宜的方法为其API创建NLI，则集成成本将大大降低。 虚拟助手不必为不同的Web服务处理不同的界面。 对于他来说，仅集成单个NL2API就足够了，这些NL2API通过自然语言实现了统一性。 另一方面，NL2API还可以简化Web服务以及API的编程建议和辅助系统的发现，从而无需记住大量可用的Web API及其语法。
示例1.图1中显示了两个示例。可以使用各种参数来调用API。 对于电子邮件搜索API，用户可以按特定属性过滤电子邮件，也可以按关键字搜索电子邮件。 NL2API的主要任务是将NL命令映射到相应的API调用。
挑战。 培训数据的收集是与NLI接口开发及其实际应用相关的研究中最重要的任务之一。 NLI使用受控的训练数据，在NL2API的情况下，该训练数据由成对的“ NL命令-API调用”组成，以研究语义并将NL命令明确映射到相应的形式化表示形式。 自然语言非常灵活，因此用户可以用语法上不同的方式来描述API调用，即，解释会发生。
请考虑图1中的第二个示例。用户可以按如下表述此问题：“下一次会议将在哪里举行”或“找到下一次会议的地点”。 因此，收集足够的训练数据非常重要，这样系统才能进一步识别这些选项。 现有的NLI通常在数据收集中遵循“最佳可能”原则。 例如，我们将NL命令与API调用进行比较的方法中最接近的类似物使用IF-This-Then-That（IFTTT）的概念-“如果是，那么”（图1）。 培训数据直接来自IFTTT网站。
但是，如果不支持或不完全支持该API，则无法解决此问题。 此外，以这种方式收集的训练数据不适用于支持具有多个参数的高级命令。 例如，我们分析了匿名的Microsoft API调用日志以搜索当月的电子邮件，发现其中大约90％使用两个或三个参数（数量相同），并且这些参数非常不同。 因此，我们努力为API参数化提供全面支持并实现高级NL命令。 当前仍未解决部署针对特定API的活动且可定制的收集培训数据的过程的问题。
将NLI与其他形式化表示形式（如关系数据库，知识库和Web表格）结合使用时，已经很好地解决了问题，而针对Web API的NLI的开发几乎没有引起注意。 我们提供第一个综合平台（框架），使您可以从头开始为特定的Web API创建NL2API。 在Web API的实现中，我们的框架包括三个阶段：（1）演示。 原始的HTTP Web API格式包含许多冗余，因此从NLI的角度分散了细节。
我们建议为Web API使用中间语义表示，以免NLI不必要的信息过载。 （2）一组训练数据。 我们提供了一种基于众包获取受控培训数据的新方法。 （3）NL2API。 我们还提供了两种NL2API模型：基于语言的提取模型和递归神经网络模型（Seq2Seq）。
这项工作的主要技术成果之一是从根本上基于众包的新方法主动收集NL2API的培训数据-与NL命令进行比较时，我们使用远程执行人员注释API调用。 通过提供以下功能，您可以实现三个设计目标：（1）可定制性。 您必须能够指定要使用哪个API的参数以及要收集多少训练数据。 （2）成本低。 众包工作者的服务比专业专家的服务便宜一个数量级，这就是为什么应该雇用他们的原因。 （3）高质量。 培训数据的质量不应降低。
设计这种方法时，会出现两个主要问题。 首先，如图1所示，具有高级参数化的API调用对于普通用户而言是难以理解的，因此您需要确定如何表述注释问题，以便众包员工可以轻松应对。 我们首先为Web API开发一个中间语义表示（请参阅第2.2节），这使我们能够无缝生成具有所需参数的API调用。
然后，我们考虑一下将每个API调用自动转换为规范的NL命令的语法，这可能相当麻烦，但对于一般的众包员工来说是显而易见的（请参阅第3.1节）。 表演者只需要改写规范的团队，使其听起来更加自然。 这种方法可以防止培训数据收集中的许多错误，因为重新安排任务对于普通的众包员工而言要简单得多，也更容易理解。
其次，您需要了解如何仅定义和注释那些对学习NL2API真正有用的API调用。 在参数化过程中出现的“组合爆炸”导致这样的事实，即甚至对一个API的调用次数也可能很大。 注释所有调用是没有意义的。 我们为实施众包过程提供了一个全新的分层概率模型（请参阅第3.2节）。 通过与语言建模进行类比以获取信息，我们假设NL命令是基于相应的API调用生成的，因此应将语言模型用于每个API调用以注册此“生成”过程。
我们的模型基于API调用的组成性质或整个语义结构的形式化表示。 从直观的角度来看，如果API调用包含更简单的调用（例如，“未读有关理科学位候选人的电子邮件” =“未读电子邮件” +“针对理学学位候选人的电子邮件”，我们可以构建它从简单的API调用甚至没有注释的语言模型，因此，通过注释少量的API调用，我们可以为其他所有人计算语言模型。
当然，所计算的语言模型远非理想，否则我们已经解决了创建NL2API的问题。 不过，将语言模型外推到未注释的API调用可以使我们全面了解API调用的整个空间，以及自然语言和API调用的交互作用，从而可以优化众包流程。 在第3.3节中，我们描述了一种用于选择性地注释API调用的算法，以帮助使API调用更具可区分性，即最大程度地提高其语言模型之间的差异。
我们将框架应用于Microsoft Graph API2程序包中的两个已部署的API。 我们证明，如果使用建议的方法，则可以以最低的成本收集高质量的培训数据3。 我们还表明，我们的方法可以改善众包。 以相似的成本，我们收集了更好的培训数据，大大超出了基线。 因此，我们的NL2API解决方案可提供更高的准确性。
总的来说，我们的主要贡献包括三个方面：
- 我们是最早研究NL2API问题的人之一，并提出了一个从头开始创建NL2API的综合框架。
- 我们提出了一种使用众包的独特方法来收集训练数据，并使用一种全新的分层概率模型来优化此过程。
- 我们将框架应用于实际的Web API，并演示了可以从头开始创建足够有效的NL2API解决方案。
表1. OData查询参数。前言
RESTful API
最近，由于其简单性，符合REST体系结构样式的Web API（即RESTful API）正变得越来越流行。 RESTful API也用于智能手机和物联网设备。 Restful API使用通过URI寻址的资源，并使用简单的HTTP命令（GET，PUT，POST等）为广泛的客户端提供对这些资源的访问。我们将主要使用RESTful API，但是可以使用基本方法和其他API。
例如，采用流行的RESTful API的开放数据协议（OData）和Microsoft Graph API包中的两个Web API（图1），分别用于搜索电子邮件和用户日历事件。 OData中的资源是实体，每个实体都与一系列属性相关联。 例如，消息实体（电子邮件）具有诸如主题（主题），来自（来自），isRead（读取），receivedDateTime（接收日期和时间）等属性。
此外，OData定义了一组查询参数，使您可以对资源执行高级操作。 例如，使用FILTER参数可以搜索来自特定发件人的电子邮件或在特定日期收到的信件。 表1中列出了我们将使用的请求参数。我们将HTTP命令和实体（或实体集）的每种组合称为API（例如GET-Messages）以搜索电子邮件。 任何参数化的请求，例如FILTER（isRead = False），都称为参数，API调用是具有参数列表的API。
NL2API
NLI的主要任务是将一条语句（一种自然语言的命令）与某种形式化的表示形式进行比较，例如，在我们的案例中，是逻辑形式或对知识库或Web API的SPARQL查询。 当需要专注于语义映射而不被无关紧要的细节分散注意力时，通常使用中间语义表示，以便不直接与目标协同工作。 例如，组合分类语法被广泛用于创建数据库和知识库的NLI。 对于NL2API，类似的抽象方法也非常重要。 许多细节（包括URL约定，HTTP标头和响应代码）可以“分散” NL2API来解决主要问题-语义映射。
因此，我们使用名称API框架为RESTful API创建了一个中间视图（图2）；该视图反映了框架的语义。 API框架包括五个部分。 HTTP Verb（HTTP命令）和Resource是RESTful API的基本元素。 返回类型允许您创建复合API，即组合多个API调用以执行更复杂的操作。 必需参数最常在API的PUT或POST调用中使用，例如，消息的地址，标头和正文是发送电子邮件的必需参数。 可选参数通常出现在API的GET调用中，它们有助于缩小信息请求的范围。
如果缺少必需的参数，我们将对API框架进行序列化，例如：GET消息{FILTER（isRead = False），SEARCH（“ PhD应用程序”），COUNT（）}。 API框架可以确定性地转换为真实的API调用。 在转换过程中，将添加必要的上下文数据，包括用户ID，位置，日期和时间。 在第二个示例（图1）中，在将API框架转换为实际API调用期间，FILTER参数中的now值将替换为相应命令的执行日期和时间。 此外，API框架和API调用的概念将互换使用。
图2. API框架。 上图：自然语言团队。 中间：框架API。 下：API调用。
图3.众包输送机。训练数据收集
本节介绍了我们使用众包为NL2API解决方案收集培训数据提供的全新方法。首先，我们依靠简单的语法（见第3.1节）生成API调用，并将每个调用转换为规范的团队（然后参阅第3.1节），然后吸引众包工作者重新定义规范的团队（图3）。考虑到API调用的组成性质，我们提出了一个分层的概率众包模型（第3.2节），以及一个众包优化算法（第3.3节）。
图4.规范命令生成。左：词典和语法。右：推导的例子。API调用和规范命令
API API. , , API, API . , Boolean, (True/False).
, Datetime, , today this_week receivedDateTime. , API (, ) API API.
, API . . , TOP, ORDERBY. , Boolean, isRead, ORDERBY . « » API API.
API. API . API API ( 4). ( HTTP, , ). , ⟨sender → NP[from]⟩ , from «sender», — (NP), .
(V), (VP), (JJ), - (CP), , (NP/NP), (PP/NP), (S) . .
, API , RESTful API OData — « » . 17 4 API, ( 5).
, API. ⟨t1, t2, ..., tn → c[z]⟩,
, z API, cz — . 4. API , S, G4, API . C , , - «that is not read».
, . , VP[x = False] B2, B4, x. x VP, B2 (, x is hasAttachments → «do not have attachment»); JJ, B4 (, x is isRead → «is not read»). («do not read» or «is not have attachment») .
我们可以使用上述方法生成大量的API调用，但是使用众包注释所有这些调用在经济上并不可行。 因此，我们提出了一种用于众包的分层概率模型，可帮助您确定应该对哪些API调用进行注释。 据我们所知，这是使用众包创建NLI接口的第一个概率模型，它使我们能够解决对自然语言表示和形式化语义结构表示之间的交互进行建模的独特而有趣的任务。 语义结构的形式化表示通常，尤其是API调用，实际上是组成性的。 例如，z12 = GET-Messages {COUNT（），FILTER（isRead = False）}由z1 = GET-Messages {FILTER（isRead = False）}和z2 = GET-Messages {COUNT（）}组成（这些示例更加详细）进一步讨论）。
图5.语义网络。 第i层由带有i参数的API调用组成。 肋骨是成分。 顶点处的概率分布表征了相应的语言模型。我们研究的主要结果之一是证实了这种组合性可用于对众包流程进行建模。
首先，我们基于一组API调用参数定义组合。
定义3.1（组成）。 接受一个API和一组API调用
如果我们将r（z）定义为z的一组参数，则
是一个组成
当且仅当
是一部分
根据API调用的组成关系，您可以将所有API调用组织到一个层次结构中。 具有相同数量参数的API调用表示为一层的顶点，而成分表示为
层之间的定向肋。 我们将此结构称为语义网络（或SeMesh）。
通过与基于信息检索中的语言建模的方法进行类比，我们假设使用一个以语言模型为特征的随机过程来生成与一个API z调用相对应的语句
。 为了简化，我们专注于单词的概率，因此
在哪里
表示字典。
由于稍后会变得明显的原因，我们建议使用一组伯努利分布（Bagoulli包，BoB），而不是标准的语言单字组模型。 每个伯努利分布对应于一个随机变量W，确定单词w是否出现在基于z生成的句子中，并且BoB分布是所有单词的伯努利分布的集合
。 我们将使用
作为简写
。
假设我们形成了（多个）语句集
对于z
BoB分布的最大似然估计（MLE）允许您选择包含w的语句：
示例2.关于上面的API调用z1，假设我们得到两个语句u1 =“查找未读的电子邮件”和u2 =“未读的电子邮件”，则u = {u1，u2}。 pb（“ emails” | z）= 1.0，因为两个语句中都包含“ emails”。 类似地，pb（“未读” | z）= 0.5，而pb（“会议” | z）= 0.0。
在语义网络中，在顶点级别有三个基本操作：
注释，布局和插值。
注释（用于注释）意味着收集语句
用众包解释顶点z的规范命令并评估经验分布
最大似然法。
COMPOSE （compose）尝试基于合成来推导语言模型以计算预期分布
。 如我们实验所示，
是z的成分。 如果我们假设相应的语句具有相同的组成联系，那么，
应该放在
：
其中f是一个合成函数。 对于BoB分发，组合功能将如下所示：
换句话说，如果ui是语句zi，则u是语句
组成u，则单词w不属于u。 当且仅当它不属于任何ui。 当z具有许多组成时，分别计算θex并取平均值。 标准语言会标模型不会导致自然的合成功能。 在归一化单词概率的过程中，涉及句子的长度，这又考虑了API调用的复杂性，这违反了公式（2）中的分解。 这就是我们提供BoB分发的原因。
示例3.假设我们为前面提到的API调用z1和z2准备了注释，每个注释都有两个语句：
= {“查找未读电子邮件”，“未读电子邮件”}和
= {“我有多少电子邮件”，“查找电子邮件数量”}。 我们对语言模型进行了评级
和
。 作文操作正在尝试评估
不问
。 例如，对于单词“电子邮件”，pb（“电子邮件” | z1）= 1.0，而pb（“电子邮件” | z2）= 1.0，因此从等式（3）得出pb（“电子邮件” | z12）= 1.0，也就是说，我们认为该单词将包含在z12的任何语句中。 类似地，pb（“ find” | z1）= 0.5，而pb（“ find” | z2）= 0.5，因此pb（“ find” | z12）= 0.75。 一个单词很可能从任何z1或z2生成，因此它出现z12的可能性应该更高。
当然，语句并非总是组合在一起。 例如，可以用自然语言的单个单词或短语来表达语义结构的形式化表示中的几个元素，这种现象称为次词汇组合性。 图3中显示了一个这样的示例，其中三个参数-TOP（1），FILTER（立即开始）和ORDERBY（开始，递增）用单个词“下一个”表示。 但是，如果不注释API调用就无法获得此类信息，因此问题本身类似于鸡肉和鸡蛋的问题。 在没有此类信息的情况下，有理由遵循默认假设，即语句的特征与API调用具有相同的组成关系。
这是一个合理的假设。 值得注意的是，此假设仅用于对众包过程进行建模，目的是收集数据。 在测试阶段，真实用户的陈述可能与此假设不符。 如果收集的训练数据涵盖了非组合情况，那么自然语言界面将能够应对这些非组合情况。
INTERPOLATE （内插）将有关z的所有可用信息（即带注释的话语z）和从合成中获得的信息进行组合，并获得更准确的估算值
通过插值
和
。
平衡参数α控制注释之间的权衡
准确但足够的当前峰值，以及基于成分假设从成分获得的信息可能不那么准确，但覆盖范围更广。 从某种意义上说
与语言建模中的抗锯齿功能相同，目的是在数据（注释）不足的情况下更好地估计概率分布。 超过
越重
。 对于没有成分的根顶点，
=
。 对于无注释的顶部
=
。
接下来，我们描述语义网络更新算法，即计算
对于所有z（算法1），即使仅对一小部分顶点进行了注释。 我们假设值
已经为所有带注释的站点更新。 从上到下依次计算
和
对于每个顶点z。 首先，您需要更新上层，以便可以计算下层顶点的预期分布。 我们注释了所有根顶点，因此我们可以计算
所有的顶点。
算法1.更新语义网格的节点分布
3.3众包优化
语义网络形成了API调用整个空间以及语句和调用的交互的整体视图。 基于此视图，我们可以选择性地仅注释高价值API调用的子集。 在本节中，我们描述了优化众包的差异化分销策略。
考虑一个具有多个顶点Z的语义网络。我们的任务是确定迭代过程中的一部分顶点
由众包工人注释。 先前注释的顶点称为状态state，
那么我们需要找到政策政策
根据当前状态评估每个未注释的顶点。
在深入讨论计算有效政策的方法之前，假设我们已经有一个方法，并对我们的众包算法（算法2）进行了高级描述，以描述随附的方法。 更具体地说，我们首先注释所有根顶点，以评估Z中所有顶点的分布（第3行）。 在每次迭代中，我们更新顶点分布（第5行），计算
一个基于语义网络当前状态的策略（第6行），选择评分最高的未注释的顶点（第7行），并在新状态下注释该顶点和结果（第8行）。 实际上，您可以在迭代过程中对多个顶点进行注释，以提高效率。
图6.差异分布。 z12和z23代表正在研究的一对顶点。 w是基于d（z12，z23）计算的估计，并且从下到上迭代传播，在每次迭代中翻倍。 顶点的估计值将是其估计值与z12和z23的绝对差（因此为差分）。 z2的得分为0，因为它是z12和z23的公共父实体； 在这种情况下，注释在确保z12和z23的可区分性方面几乎没有用。从广义上讲，我们解决的任务可以归因于主动学习的问题，我们为自己设定的目标是识别注释示例的子集，以便获得可以改善学习成果的训练集。 但是，几个主要差异不允许直接使用经典的主动式教学方法，例如“采样不确定性”。 通常，在主动学习的过程中，以我们的情况为NLI界面的学生尝试研究映射f：X→Y，其中X是输入空间模式，由一小组标记的样本和大量未标记的样本组成，而Y通常是一组标记类。
学生评估未标记示例的信息价值，并选择信息最丰富的示例，以从众包工作者中获得Y标记。 但是在我们要解决的问题的框架内，注释问题的构成方式有所不同。 我们需要从一个大型API调用空间Y中选择一个实例，并要求众包工作者通过在X空间（句子空间）中指定模式来对其进行标记。 此外，我们不受特定学员的束缚。 因此，我们提出了一个解决当前问题的新方法。 我们从主动学习的众多来源中汲取灵感。
首先，我们确定目标，在此目标的基础上，将评估节点的信息内容。 显然，我们希望区分不同的API调用。 在语义网络中，这意味着分布
不同的峰有明显的差异。 首先，我们介绍每个分布
像n维向量
其中n = |
| -字典的大小。 通过向量距离d的某个度量（在我们的实验中，我们使用向量pL1之间的距离）来表示
即两个顶点之间的距离等于它们的分布之间的距离。
显而易见的目标是使所有顶点对之间的总距离最大。 但是，所有成对距离的优化对于计算而言可能过于复杂，甚至没有必要。 一对遥远的峰之间已经有足够的差异，因此进一步增加距离是没有意义的。 取而代之的是，我们可以专注于引起最大混淆的顶点对，即它们之间的距离最小。
在哪里
如果我们按距离将所有节点对按升序排列，则指向前K对顶点。
算法2.使用策略迭代地注释语义网格
算法3.基于差分传播的计算策略
算法4.将分数从源节点递归传播到其所有父节点
注释后具有较高信息含量的顶点可能会增加Θ的值。 为了在这种情况下进行量化，我们建议使用差分分配策略。 如果一对顶点之间的距离较小，我们将检查其所有父顶点：如果父顶点对于一对顶点是公共的，则其应具有较低的评级，因为注释会导致两个顶点的变化相似。
否则，顶点必须具有很高的评级，并且一对顶点越近，评级越高。 例如，如果“关于PhD应用程序的未读电子邮件”和“关于PhD应用程序的电子邮件有多少”的顶点之间的距离很小，则从区分这些顶点的角度来看，注释其父顶点“关于PhD应用程序的电子邮件”就没有多大意义。 最好对父节点不常见的注释：“未读电子邮件”和“多少电子邮件”。
这种情况的一个示例如图6所示，其算法为算法3。作为一个估计，我们采用以一个常数为界的节点距离的倒数（第6行），因此最接近的顶点对影响最大。 当使用一对顶点时，我们同时将每个顶点的评估分配给它的所有父顶点（第9、10和4条算法）。 未注释的顶点的估计值是相应的一对顶点的估计值的绝对差，其中所有顶点对的总和（第12行）。
自然语言界面
要评估提出的框架，有必要使用收集的数据来训练NL2API模型。 目前，尚无法使用完整的NL2API模型，但是我们正在从其他领域改编两个经过测试的NLI模型，以将其应用于API。
语言模型提取模型
基于NLI知识库领域的最新发展，我们可以考虑在信息提取问题的背景下创建NL2API，以使基于语言模型（LM）的提取模型适应我们的条件。
要说出u，您需要在语义网络中找到与u最匹配的API z调用。 首先，我们改变BoB的分布
API z对语言字母组合模型的每次调用：
这里我们使用加法平滑，0≤β≤1是平滑参数。 更高的价值
，尚未分析的单词的权重就越大。 API调用可以按其对数概率进行排序：
（服从统一的先验概率分布）
评分最高的API调用用作模拟结果。
Seq2Seq重述模块
神经网络作为NLI的模型正变得越来越普遍，而Seq2Seq模型在此方面比其他模型要好，因为它允许您自然地处理可变长度的输入和输出序列。 我们将此模型调整为NL2API。
对于输入序列e
，模型估算所有可能输出序列的条件概率分布p（y | x）
。 长度T和T'可以变化并且取任何值。 在NL2API中，x是输出语句。 y可以是序列化的API调用或其规范命令。 我们将使用规范命令作为目标输出序列，这实际上将我们的问题变成了改述问题。
实施为具有受控递归单元（GRU）的递归神经网络（RNN）的编码器首先将x表示为固定大小的向量，
其中RN N是将GRU应用于整个输入序列的简短表示，一个接一个的标记，然后是最后一个隐藏状态的输出。
解码器（也是带有GRU的RNN）将h0用作初始状态，并逐个标记地处理输出序列y，以生成状态序列，
输出层将每个解码器状态作为输入值，并生成字典分布
作为输出值。 我们只使用仿射变换，然后使用多变量逻辑函数softmax：
最终的条件概率使我们能够评估规范命令y重新表达输入语句x的程度，
。 然后，通过API调用的规范命令的条件概率对它们进行排序。 我们建议您熟悉源代码，其中详细介绍了模型学习过程。
实验
通过实验，我们研究以下研究主题：[PI1]：我们可以使用提出的框架以合理的价格收集高质量的培训数据吗？ [PI2]：与最大似然评估相比，语义网络是否提供对语言模型的更准确评估？ [PI3]：差异化分销策略是否可以提高众包效率？
众包
-API Microsoft — GET-Events GET-Messages — . API, API ( 3.1) . API 2. , Amazon Mechanical Turk. , API .
. API 10 , 10 . 201 , . 44 , 82 , 8,2 , , , . , 400 , 17,4 %.
(, ORDERBY a COUNT parameter) (, , ). . NLI. , , [1] . .
, , , , API (. 3). API . , . 61 API 157 GET-Messages, 77 API 190 GET-Events. , , API (, ) , , .
2. API.
3. : ()., , . , α = 0,3, LM β = 0,001. K, , 100 000. , , Seq2Seq — 500. ( ).
NLI, . .
. , , . LM: , . , . ROOT — . TOP2 = ROOT + 2; TOP3 = TOP2 + 3. .
4. LM (MLE) ,
, . , , , MLE .
MLE,
,
- , . API . 16 API (ROOT) LM SeMesh Seq2Seq API (TOP2) , 500 API (TOP3).
, , , , ( 3.2) . , GET-Events , GET-Messages. , GET-Events
, , , .
4. . LM, Seq2Seq, . , .LM + , ,
θem with
。
, , ROOT,
。 , , . MLE. , , [2] .
0,45 0,6: , NLI . , API. API (. 7) , RNN , . .
. : |u | α. - LM ( 7). , |u | < 10, 10 . GET-Events, GET-Messages .
, , , . , , . , α, ([0.1, 0.7]). α , , .
(DP) . API . 50 API, , NL2API .
, . LM, . . , ( 5.1), API .
7. .
8. . : GET-Events. : GET-Messages
breadth first (BF), . . . API , API .
8. NL2API API DP . 300 API, Seq2Seq, DP 7 % API. , . , DP API, NL2API. , , [3] .
- . - (NLI) . NLI . , , . .
NLI , -, API . NL2API : API , - , . . API REST .
NLI. NLI « ». , Google Suggest API, API IFTTT. NLI, . , .
NLI, . NLI , . , , .
API . , -API. .
-API. , -API. , -API API, -API . NL2API , , API.
- -API (NL2API) NL2API . NL2API . : (1) . , , ? (2) .
? (3) NL2API. , API. (4) API. API? (5) : NL2API ?