斯图加特大学：函数助手：用于NL查询API的工具

你和“懂AI”之间，只差了一篇论文

很多读者给芯君后台留言，说看多了相对简单的AI科普和AI方法论，想看点有深度、有厚度、有眼界……以及重口味的专业论文。

为此，在多位AI领域的专家学者的帮助下，我们解读翻译了一组顶会论文。每一篇论文翻译校对完成，芯君和编辑部的老师们都会一起笑到崩溃，当然有的论文我们看得抱头痛哭。

同学们现在看不看得懂没关系，但芯君敢保证，你终有一天会因此爱上一个AI的新世界。

这是读芯术解读的第83篇论文

EMNLP 2017 System Demonstrations

函数助手：用于NL查询API的工具

Function Assistant: A Tool for NL Querying of APIs

斯图加特大学

Universität Stuttgart

【摘要】在本文中，我们描述了一个函数助手，这是一个轻量级的基于Python的工具包，用于使用自然语言查询和探索源代码库。该工具包旨在帮助目标API的终端用户通过高级自然语言查询和描述快速查找有关函数的信息。对于给定的文本查询和背景API，该工具使用Richardson和Kuhn（2017）的语义分析方法，通过在API中执行从文本到已知表示的翻译来查找候选函数。在示例API中，翻译会自动从示例文本代码对中学习。该工具包包含用于为任意源代码项目构建翻译管道和查询引擎的特征。为了探索这后一个特性，我们在Github上托管的27个知名Python项目上进行了新实验。

1 引言

开发新应用程序时，软件开发人员经常转换使用不同的第三方软件库或API。大部分开发时间都致力于理解这些API的结构，弄清楚目标功能的位置，并了解这些软件的结构特征或命名约定是如何工作的。当目标API很大时，找到所需的功能可能是一项艰巨且耗时的任务。通常开发人员会使用如Google或StackOverflow这样的资源来寻找（通常是间接的）问题的答案。

我们在图1中使用著名的NLTK工具包中的两个示例函数来说明这些问题。每个函数都与一个简短的文档字符串配对，即每个函数下的引用描述，它为软件用户提供了功能描述。尽管理解文档和代码需要依赖分析和图形方面的技术知识，但即使具备这些知识，函数命名约定也是相当随意的。函数add_arc也可以成为create_arc。期望另一个命名约定的最终用户在搜索此功能时可能会误入歧途。同样，可用的描述可能会偏离最终用户描述的这种功能。

图1 示例函数文档Python NLTK依赖图

相比之下，理解remove_by_address函数需要了解正在使用的特定DependencyGraph实现的细节。尽管如此，该功能对应于从依赖图中移除节点的标准操作。在这里，有关如何删除特定于某个给定的地址的技术细节可能会混淆该功能的整体目的，使其很难找到或理解。

在第一个近似值中，导航给定的API需要知道文本描述和源代码表示之间的对应关系。例如，知道图1中的英语表达式添加一个弧，可以翻译（有点任意地）add_arc，或者给定地址翻译为地址address。还必须知道如何检测某些目标实体或动作的释义，例如添加一个弧意味着在这种情况下创建一个弧。必须学习其他技术对应，例如地址和目标依赖图实现之间的关系。

在我们以前的工作（Richardson and Kuhn（2017），此后记为RK）中，我们将从各种编程语言和源代码自然语言的示例API集合中学习这些类型的对应关系。我们把每个给定的API（包括文本和函数表示对）作为一个平行的语料库来训练一个简单的语义分析模型。除了学习上述类型的翻译对应外，我们还通过添加有助于学习其他技术对话的文档级功能来实现改进。

在本文中，我们将重点放在使用我们的模型作为查询API集合的工具。给定一个目标API，我们的模型学习一个基于MT的语义解析器，将文本翻译为API中的代码表示。终端用户可以为后台API制定自然语言查询，我们的模型将转化为候选函数表示，目标是找到所需的功能。我们的称为函数助手的工具有两种使用方式：作为黑箱管道，用于直接从任意API集合构建模型。而且，可以使用该工具灵活的内部Python API将其定制并与其他外部组件或模型集成。

在本文中，我们重点介绍我们的工具的第一次使用。为了探索新的API集合的构建模型，我们从著名的Awesome Python项目列表中运行了27个开源Python项目（github.com/vinta/awesome-python）的管道。与以前的工作一样，我们对这些数据集进行了综合实验，这些实验测量了我们的模型，为看不见的API描述生成函数表示，模仿用户查询。

2 相关工作

最近，人们越来越关注API学习代码表示的机器学习，特别是使用GitHub或StackOverflow等资源。然而，这项工作往往是从许多API集合中学习（Gu et al.，2016），使得这样的系统很难评估并应用于查询特定的API。其他工作则着眼于学习从自然语言编程的源代码注释中生成更长的代码（Allamanis et al.，2015），通常狭隘地集中在特定的编程语言（如Java）或一组API上。据我们所知，这些方法都不包括帮助为特定的API和查询构建定制管道的辅助软件。

从技术上讲，我们的方法与语义分析的工作有关，该语义分析从自然语言理解应用程序的文本输入生成正式表示，特别是问答。MT（Wong和Mooney，2006）和解析（Zettlemoyer和Collins，2009）的许多现有方法都直接受到启发。请参阅RK以获得更多的讨论和相关工作的联系。

3 技术方法

在本文中，我们重点学习如何从源代码集合或API中的文本描述生成函数表示。我们将这些目标函数表示作为API组件。每个组件都指定一个函数名称，参数列表和其他可选信息，如命名空间。给定一个示例文本组件对的例子API，，目标是学习如何为每个文本x生成正确的，构建良好的组件z∈C。当被视为语义分析问题时，我们可以将每个z视为与目标逻辑形式类似。在本文中，我们将重点放在Python源代码项目和Python函数z上，但是我们的方法对输入的自然语言和输出编程语言是不可知的，如RK所示。

当用于查询时，我们的模型会接受一个文本输入并尝试生成所需的函数表示。从技术上讲，我们的方法遵循我们以前的工作，有两个组成部分：一个简单轻量级的基于单词的翻译模型，生成候选的API组件，以及一个区分模型，使用附加的短语和文档级功能排名翻译模型输出结果。所有这些模型都是在我们的工具中本地实现的，我们依次描述每个部分。

3.1 翻译模式

给定一个输入文本(或查询)序列x =w1，…，w |x |，目标是生成一个输出API分量z = ui，…，u|z |，这涉及到学习一个条件分布p(z | x)，我们追求的噪声信道的方法，

因此，通过假设输出分量上的一致的先验p（z），该模型涉及计算p（x | z），其在基于词的翻译模型下可以表示为：

其中，求和范围在从x→z的所有多对一（字）对齐集a的范围内。

虽然存在许多不同的基于单词模型的表达方式，但是我们以前发现最简单的词汇翻译模型或者IBM Model 1（Brown et al。，1993）优于具有位置参数的更高阶的对齐模型。该模型使用以下公式精确计算所有路线：

其中，定义了对于所有单词的给定分量项的多项分布。

虽然许多参数估计策略存在训练基于单词的模型，我们同样发现，最简单的EM程序Brown et al. (1993)的作品效果最好。在RK中，我们描述了一个线性时间解码策略（即用于从输入生成组件）的数量C，我们在本文中使用。我们的工具还实现了我们类型的常规MT解码策略，它们更适合大型API和更复杂的语义语言。

3.2 判别排序

遵循大多数语义分析方法（Zettlemoyer和Collins，2009），我们使用一个有区别的对数-线性模型来重新排列从底层翻译模型生成的组件。这样的模型定义了一个条件分布：对于一个参数向量和一组特征函数，。

我们的工具实现了几种不同的训练和优化方法。为了本文的目的，我们使用在最大条件对数似然目标下的在线随机梯度上升算法来训练我们的模型。

3.2.1 特性

对于给定的文本输入x和输出分量z，定义这两个条目之间的一组特征。默认情况下，我们的管道实现使用三类功能，与RK中使用的功能集相同。第一类包括额外的单词级别功能，如单词/组件匹配，重叠，组件语法信息等。第二类包括文本和元素候选之间的短语和层次短语特征，它们是从对称的字级对齐启发式提取的。

另一类功能包括文档级功能。这包括有关基础API类层次结构的信息，以及此层次结构中的单词/短语和抽象类之间的关系。此外，我们使用文档中的参数的附加文本描述来指示在这些描述中是否有单词分量候选对重叠。

4 实施和使用

以上所有功能都是在函数助手工具包中实现的。该工具是我们以前的工作Zubr的配套软件版本的一部分。为了提高效率，核心功能是用Cython （http://cython.org/）编写的，Cython是Python语言的编译超集，有助于本地C/C++集成。

该工具被设计为以两种方式使用：首先，作为黑盒来构建定制翻译管道和API查询引擎。该工具也可以使用我们的Cython和Python API与其他组件集成。我们侧重于第一种功能。

4.1 库设计和管道

我们的库使用依赖注入OOP设计原则。所有核心组件都是作为完全独立的类来实现的，每个类都有许多相关的配置值。这些组件通过名为Pipeline的类进行交互，该类将各种用户指定的组件和依赖关系粘合在一起，并从这些组件构建全局配置。对象的后续实例化和共享由这些全局配置设置来决定或注入，这些设置可以在整个管道运行中动态地改变。

通过编写管道脚本来创建管道，如图2所示。该文件是一个普通的Python文件，带有两个必需的变量。第一个参数变量指定了与管道相关的各种高级配置参数。在这种情况下，有一个设置基线 --baseline，它可以被引发来运行基线实验，并将影响后续的处理管道。

图2 用于构建的示例传递方法脚本一个翻译模型和查询服务器

第二个也是最重要的变量称为任务（tasks），它指定了应该执行的子过程的顺序。这个列表中的字段是指向底层Zubr工具包中的核心实用程序（每个都带有前缀zubr）的指针或用户定义的函数。这个特定的管道通过使用DocExtractor从用户指定的源代码存储库构建数据集开始，然后通过各种中间步骤构建对称转换模型SymmetricAlignment，特征提取器FeatureExtractor，判别式reranker Optimizer。它通过构建一个查询接口和查询服务器QueryInterface和QueryServer来完成，然后可以用它来查询输入的API。

如前所述，每个子进程都有许多相关的配置设置，通过管道Pipeline实例将其加入全局配置对象中。对于翻译模型，设置包括例如要使用的翻译模型类型，训练模型时要使用的迭代次数等。所有这些设置都可以在终端上指定，也可以在单独的配置文件中指定。同样，用户可以自由定义自定义函数，例如过程数据或可用于修改默认处理管道或实现新的机器学习功能的类。

4.2 Web服务器

这个管道的最后一步是建立一个可以用来查询输入API的HTTP Web服务器。在内部，服务器推送给被训练的翻译模型和判别式重排器，它接受用户查询并尝试将它们翻译成API函数表示。然后将这些候选翻译作为潜在的查询答案返回给用户。根据结果，如果目标函数没有找到，用户可以改变他/她的问题，或者通过链接到函数的源代码来查看实现。

查询服务器的示例屏幕截图如图3所示。这里，后台API是NLTK工具包，查询是训练序列标记器模型。虽然没有明确提到，但该模型返回隐马尔科夫模型标注器HiddenMarkovModelTagger的训练函数。图的右侧显示了训练函数的Github中原始源的超链接路径。

图3 函数辅助Web服务器的示例屏幕快照

5 实验

我们目前的DocExtractor实现支持从原始Python源代码集合构建并行数据集。在内部，该工具使用Python标准库中的抽象语法树实用程序ast读取源代码，并提取函数和描述对的集合。另外，该工具还提取类描述，参数和返回值描述以及关于API的内部类层次结构。然后使用这最后一类信息来定义文档级功能。

表1 新英语GitHub的数据集

为了试验这个功能，我们建立了管道并为27个流行的Python项目进行了实验。这些实验的目标是测试我们的提取器的鲁棒性，并看看我们的模型如何使用我们以前的实验设置来回答这些资源的不可见的查询。

5.1 数据集

示例项目如表1所示。每个数据集按照＃对，或并行功能组件表示的数量，组件输出语言中的＃符号，＃（NL）字和单词大小进行量化。

5.2实验设置

每个数据集被随机分成训练、测试和开发等集合。设置使用了70％-30％（或15％/ 15％）的分割。我们可以将外挂集合看作模仿用户可能会询问模型的查询。一般来说，所有模型都是在训练集上进行训练的，并且超参数被调整到开发集。

对于在测试期间看不见的文本输入，模型会生成一个候选的组件输出列表。如果输出与黄金函数表示完全匹配，则认为输出正确。像以前一样，我们测量准确度@ 1，精度在前十（准确度@ 10）和MRR。

正如我们以前的工作一样，使用了三个额外的基线。首先是一个简单的词袋（BoW）模型，它使用词组成对作为特征。第二个是术语匹配基线，它根据输入单词和分量单词之间的匹配数目对候选者进行排序。不用Reranker模型我们也比较翻译的结果（模型）。

6 结果与讨论

测试结果如表2所示，基本符合我们以前的发现。BoW和术语匹配基线的性能优于所有其他模型，这再次表明API查询比简单的单词组件匹配更复杂。 与只使用翻译模型相比，Reranker模型导致所有数据集的改进，表明文档级别和短语功能可以帮助该数据集的改进。

表2 我们新的Github数据集的测试结果

7 结论

我们介绍了函数助手，一个轻量级的工具，用于使用无应变的自然语言来查询API集合。用户可以为我们的工具提供目标源代码项目，并从头构建自定义翻译或处理管道和查询服务器。除了这个工具之外，我们还创建了新的资源，用于学习API查询，以从27个流行的Github项目构建的数据集的形式。虽然我们的方法使用简单的组件，但我们希望我们的工具和资源将成为未来在这一领域的工作的基准，并最终帮助解决日常软件搜索和可重用性问题。

留言 点赞 发个朋友圈

我们一起探讨AI落地的最后一公里