导语

Binder模型是最近借助Codex进行自然语言到SQL/Python等转换的方法，它仅需少量标注就可以适配多种不同的编程语言。

链接：arxiv.org/abs/2210.02…
Demo：huggingface.co/spaces/hkun…

摘要

尽管end-to-end的神经网络方法由于在性能和易用性方面的优点，几乎统治了整个NLP领域，但这类方法缺乏可解释性和健壮性。本文提出Binder，一种无需训练的neural-symbolic框架，能够将任务输入映射为程序代码，同时(1)允许将语言模型(LM)函数的统一API绑定到编程语言(如SQL、Python)，以扩展其语法覆盖范围，从而解决更多样化的问题，(2)采用LM作为程序解析器和API在执行过程中调用的底层模型，(3)只需要少量上下文示例注释。具体来说，采用GPT-3 Codex作为LM。在解析阶段，由于只有少量上下文示例，Codex能够识别任务输入中原始编程语言无法回答的部分，正确生成API调用以提示Codex解决无法回答的部分，并在与原始语法兼容的情况下确定将API调用放置在哪里。在执行阶段，如果在API调用中给出适当的提示，Codex可以执行多种功能(例如，常识QA、信息提取)。Binder在WIKITABLEQUESTIONS和TABFACT数据集上实现了最先进的结果，具有显式输出程序，有利于人工调试。请注意，以前的最佳系统都是在数万个特定于任务的样本上进行微调的，而BINDER只使用几十个注释作为上下文示例，而没有进行任何训练。代码可在github.com/hkunlp/bind… 获得。

1 简介

作者首先对比了end-to-end方法和symbolic方法的优劣：

end-to-end：灵活易用，但缺少可解释性和鲁棒性；
symbolic：可解释，更鲁棒，但受限于人工设计的语法。

接着又讲到最近的一些进展，如结合了两种方法neural-symbolic，但需要结合特定语言进行精巧的设计，但仍局限于某一特定语言或领域，使用到新的语言和领域时需要重新人工设计语法规则。

作者希望构建一个neural-symbolic system，能支持灵活的神经模块调用（即对多种符号语言都有很好的覆盖），同时只需要少量的标注。为此，本文设计了Binder框架，如下图所示：

整个Binder的pipeline分为两步：

parsing：使用LM将原始输入转换为一个Binder程序，其中有一些API调用；
execution：使用LM结合prompt来实现这些API调用。

最后，作者使用Binder在WIKITABLEQUESTIONS和TABFACT数据集上进行了实验，结果表明：Binder不用Fine-tune，仅需要几个in-context的标注就能达到SOTA或者差不多的效果。

2 方法

2.1 Binder框架

Binder框架用于解决NLP任务，其定义如下：给定一个自然语言问句 $Q$ 和可选地上下文 $D$ （比如文章、表格、图片或者上述几种资料的集合）作为输入，Binder程序 $Z$ 作为输出，最终通过Binder解释器执行 $Z$ 得到输出答案 $A$ 。主要分为以下两个模块：

Binder Parsing

该阶段的任务是将输入自然语言问句 $Q$ 解析为Binder程序 $Z$ 。这里说的Binder程序是一种带有可选API调用的符号表示，其中API的被定义为一个函数： $f(\hat{Q};\hat{D})$ ， $\hat{Q}$ 指的是原始问句中无法被回答的部分， $\hat{D}$ 指的是跟 $\hat{Q}$ 有关的上下文。

举个例子，图1中的North America就是 $\hat{Q}$ ，然后它对应的 $\hat{D}$ 则是column “Made_in”。API调用 $f(\hat{Q};\hat{D})$ 为 $\hat{Q}$ 的答案，并将其表示为与符号语言语法兼容的变量，以便程序能够执行。

Binder Execution

在执行阶段，Binder解释器由一个标准符号语言解释器和实现API调用的模型组成。执行阶段包括词法分析、语法分析和程序评估。在词汇和语法分析中， $f(\hat{Q};\hat{D})$ 作为一个新的标识符添加到语法中，并将程序解析为基于此扩展语法的抽象语法树(AST)。在程序评估中，API调用是通过调用底层神经模型来评估的。API调用输出被保存为与标准符号语言语法兼容的变量，因此程序最终可以由一个现成的符号语言解释器执行，从而获得输出。具体地说，BINDER扩展了符号语言生成规则，以方便解析BINDER程序的AST，并且以自底向上的顺序计算AST，以便还支持嵌套的API调用。下图给出了一个示例：

可能大家理解起来还是比较抽象，可以参考他的demo就很容易理解。下图展示了一个demo的执行过程：

可以看到，第一步模型将用户的问句和context转换为一个Binder程序，

SELECT COUNT ( * ) FROM w WHERE QA("map@is it from france?"; `current club`) = "yes"

其中包含一个子API调用QA("map@is it from france?"; current club)，接下来分别对当前column中的各个元素进行查询，得到各自API调用的结果。

最后，将API执行结果反馈到原始Binder程序中，得到最终的结果。

2.2 Binder中的In-context learning

In-context learning是由GPT-3所提出的，即不需要Fine-tune语言模型（如GPT-3），只需要在输入中给出一些提示，GPT-3就可以按照我们的提示来进行相应的操作。Binder也是这样的过程。

具体来说，假设输入是k个 $\{(Q_ i, D_i, Z_i)\}_{i= 1}^{k}$ 的上下文内示例和推理示例 $(Q, D)$ 。k个示例应该在问题类型的多样性和模型的最大输入容量之间进行权衡，模型的最大输入容量可以根据推理示例手动选择(固定)或自动检索(动态)。模型输出是n个候选BINDER程序Z = {z1，…接下来，程序Z由B INDER解释器执行，产生n个答案 $A = \{A_1，…， A_n\}$ 。最后，输出答案A是通过对生成答案A集的多数投票策略得到。k和n的值是上述过程中的超参数。

2.3 Binder实现

本小节演示如何在结构化数据上进行BINDER的实现。首先，作者实现了两种API，即 $f_{col}(\hat{Q}; \hat{D})$ 和 $f_{val}(\hat{Q}; \hat{D})$ 。基于 $\hat{Q}$ ， $f_{col}$ 将 $\hat{D}$ 映射为一个column，而 $f_{val}$ 将 $\hat{D}$ 映射为一个value。由于两种返回类型，即列和值，都与SQL和Python的语法兼容(带有Pandas包)，因此插入 $f_{col}$ 和 $f_{val}$ API来替换列和值，从而形成有效的Binder程序。

以图1中的“which is the best-selling shirt made in North America and with no chemicals?”为例。Made_in列中的国家名称本身并没有提供足够的信息来表明它们的大洲是什么，因此纯SQL无法解决这个问题(使用这个表的数据)。然而，(大型)语言模型很容易回答一个国家是否来自北美，这是由位于标准SQL中列名位置的 $f_{col}("North America?";Made_in)$ 表达式表示的。类似地，表达式 $f_{col}(“No chemicals?”;Shirt)$ 调用一个(大的)语言模型，根据衬衫列中的文本细节来确定衬衫是否不含化学品(即，在本例中为纯棉)。

当一个(子)问题太复杂或不可用 $f_{col}$ 创建一个中间新列来解决时，我们转向 $f_{val}$ 来直接推导答案。例如，当被问到“which shirt is the most suitable for a formal event?”，很难将Shirt映射到一个新的列“formality value”，然后使用一个SQL的“ORDER BY”子句来排序。因此，表达式将是 $f_{val}(" the most formal? ";Shirt)$ ，它输出一个值作为答案。 $f_{val}$ 看起来更像端到端QA，有两个重要的区别:(1)它可以使用结果作为值集成到更组合的SQL查询中，(2)它输入子表而不是整个表，这可以减轻输入容量的挑战。

3 实验

主要在WikiTQ和TabFact数据集上进行实验，其中大约20%的WikiTQ问题不能由纯SQL回答，要么是因为需要额外的知识，要么是因为SQL语法的覆盖范围有限，这两个问题都是设计binder的目的。评估指标为执行准确率。

实验结果如下图所示：

4 分析

如表3所示，Codex BINDER在程序无法解决的问题上明显优于Codex SQL 10.1%，这与本文设计的动机一致。

作者从Codex BINDER(关于SQL)的WikiTQ验证集(约占所有错误示例的10%)中抽样了100个错误案例，以进行错误分析。我们将错误分为语法错误、语义错误、错误执行和假阴性，如表4所示。

同时，本文还用一个例子来说明使用BINDER进行调试和解释结果的优点。如表5中的示例所示，端到端系统的结果是1967，这是不正确的，但没有提供这一预测背后的原因的线索。来自BINDER的结果是不正确的，因为程序对表中的win_team列使用了不正确的值和运算符(应该是" LIKE "%kansas state%" ")，并且它可以在未来通过添加类似的上下文样例或模糊匹配后处理来修复。

当表太大，无法满足Codex的最大令牌限制(8000令牌)时，我们会截断表行，直到它适合。如图2所示，随着表大小的增加，Codex端到端QA性能急剧下降，而BINDER的性能一直优于它，但性能只有轻微下降。注意，对于所有大小的表，binder的输入只有三个表行。

端到端方法对于有噪声的输入更加脆弱，特别是当存在与问题相关内容相似的干扰时。我们建立了一个带干扰的噪声WikiTQ开发子集(随机150个样本)，如图3所示，BINDER在面对干扰时是稳定的(1.3%↓)，而端到端QA更容易被相似的文本和数字混淆(6.7%↓)。

如表6所示，使用Python的BINDER有效地提高了困难子集上的Python覆盖率。表7展示了在Codex少次次数设置下，BINDER的性能优于端到端QA和经过调优的基线隐式分解，显示了BINDER在多模态知识源上的可行性。

5 相关工作

略

6 总结

本文提出了BINDER，这是一个无需训练的神经符号框架，它将任务输入映射到一个程序，该程序允许绑定一个统一的LM API用于附加功能。binder旨在结合端到端方法(高覆盖率)和符号方法(高可解释性)的优点。使用Codex作为LM, BINDER在WikiTQ和TabFact上实现了最先进的性能，只需要几十个上下文演示，没有额外的培训。相比之下，最好的现有系统是在数千个任务特定的训练样本上进行微调，可能需要进一步的领域特定的预训练。我们还对BINDER进行了一系列分析，分解性能增益，检查对大型或噪声输入的鲁棒性，将其应用于多模态知识源，并将其扩展到Python语言。我们认为binder是一种新的、以语言模型为中心的尝试，它集成了NLP中被广泛采用的两种范式:端到端和符号方法。随着最近强大的大型语言模型的出现，以不需要训练的方式正确地生成和执行binder程序已经成为可能。在未来，我们相信BINDER可以用适当的编程语言和功能扩展到更多的场景，我们希望它能激发更多关于平衡模型能力和可解释性的创造性想法。

Text-to-SQL学习整理（三十）：BINDER模型

导语

摘要