干货！ ICLR：将语言模型绑定到符号语言中个人信息

点击蓝字

关注我们

AI TIME欢迎每一位AI爱好者的加入！

╱ 作者简介╱

承洲骏

上海交通大学硕士生，研究方向为代码生成，目前在香港大学余涛老师的实验室担任研究助理。

个人主页：http://blankcheng.github.io

谢天宝

香港大学一年级博士生，由余涛教授（主要）和孔令鹏教授指导，研究方向为代码生成和自然语言界面。

内容简介

尽管端到端(End-to-end)的方法最近在性能和易用性方面主导了NLP任务，但它们缺乏可解释性和鲁棒性。我们提出 Binder，一种无需训练的神经符号框架，可将任务输入映射到程序，它(1)允许将语言模型(LM)功能的统一API绑定到编程语言（例如SQL、Python）以扩展它的语法覆盖范围，从而大幅增加了可解决问题的范围，(2)采用LM作为程序解析器和API，在执行期间调用的底层模型，(3)只需要少量(10个左右)上下文中的示例注释，区别于与过去需要大量人工标注的程序生成方法。

具体来说，我们使用GPT-3 Codex作为LM。在生成程序阶段，Codex只需要少量的上下文范例，就能识别任务输入中原始编程语言无法回答的部分，正确生成API调用提示Codex解决无法回答的部分，并识别在与原始语法兼容的同时放置API调用的位置。在执行阶段，Codex可以在API调用中给出适当提示的情况下执行多种功能（例如，常识性问答、信息提取）。Binder 在WikiTableQuestions和TabFact数据集上取得了最先进的结果，且生成有利于人工调试的显式输出程序。以前最好的系统都是在数万个特定于任务的样本上进行微调的，而Binder仅使用数十个注释作为上下文范例，无需进行任何训练。

Background knowledge and paradigms

on solving NLP tasks

下图中表示的问题是：北美最畅销的不含化学成分的衬衫是哪一种？表中显示的内容类似于购物的一个真实场景，其中包含商品的标签以及一些细节性的描述，而蓝色字体描述的内容是无法从图中获取的，Binder的提出也就是为了解决这个问题。

下面先介绍一些常用的方法。第一种是最常见的End-to-End模式。由于大模型具有较强的自学能力，不需要进行训练，所以在End-to-End中，会将knowledge、question、answer等组合对以及测试样本一起作为输入，让GPT-3或者Codex直接生成答案。End-to-End的好处在于通用性很强，任何形式的formulation都可以作为输入，大模型都能够给出一个输出作为答案，但也存在一些缺点，比如可解释性差、可扩展性差、鲁棒性弱。

第二种是思维链方法，它与End-to-End的核心区别在于其在输出答案之前，会输出一段解释性的文字，描述推理的过程。这相对于End-to-End来讲提升了可解释性，但是可解释性是不高的，会存在一些错误，并且仍然会有可扩展性差、鲁棒性弱的问题。

第三种方法是Semantic parsing，在这个场景下也可以称之为Code generation，Binder是基于该方法的一种变形。它在给定自然语言输入的情况下生成可执行程序，生成有助于解决问题的中间结构，并提高神经方法的可解释性，而且可扩展性和鲁棒性也会更强。但是语义解析方法受限于其语法覆盖范围，无法解决需要外部知识或功能的问题。

Binder: Binding language models in

symbolic languages

所以我们根据上述方法存在的问题提出了Binder，Binder通过调用语言模型的API去解决语义分割解析方法中存在的局限，且相对于End-to-End和思维链方法具有更强的可解释性、可扩展性以及鲁棒性。

具体来介绍一下Binder的整个过程。Binder首先提示经过代码预训练的GPT-3模型 – Codex，将问题输入解析为Binder程序，其中Codex必须决定（1）输入中的哪些部分可以转换为目标编程语言（图1中以灰色突出显示的问题部分），（2）相应的任务API调用（例如，f（“北美？”；Made_in））提示Codex解决其他部分，以及（3）在哪里插入Binder程序中的API调用。接下来，Binder再次提示Codex生成任务API调用的答案（给定生成的任务提示），将生成的结果集成回编程语言。具体如图1，将API调用中的提示（如“北美？”）和数据（如Made_in列）送入Codex，输出为根据输入数据回答提示的新列（即，Made_in列中的国家是否来自北美）。最后，使用标准编程语言执行程序，得出最终答案。

相比传统的Semantic parsing方法，Binder基于大模型上下文学习的能力，只需要标注少量的样本就能取得很好的效果。

我们在实验中也做了很多定量的分析去判断Binder是否有效果及性能上的提升。我们选择的两个数据集是WikiTableQuestions (WikiTQ)和Table Fact Checking (TabFact)。WikiTQ需要复杂的表格推理技能来回答问题，存在一些WikiTQ问题无法用纯SQL回答，这要么是因为需要额外的知识，要么是因为SQL语法的覆盖范围有限。TabFact与WikiTQ的区别在于对于每一张表它都会给出一个陈述，一个陈述中有多个事实需要去验证，也就是说需要很复杂的推理步骤，并且也不能完全用符号语言来解决问题。

下图是我们的实验结果。我们的方法仅用到14个标注样本，相比已有的Finetuned的SOTA方法，性能的提升非常显著。与大模型的方法相比，相对于End-to-end以及普通的语义分割解析方法，在性能上都有明显的提升。这也就验证了最初提出Binder的研究动机，我们希望在需要SQL或者大模型的时候都能够便捷地融入各自的功能。

效果的提升大部分是源于program-unsolvable questions，即普通SQL和Python无法解决的问题，就需要一些额外的知识或者其他模态的推理。我们将这部分的结果拆解开看，在下图中可以看到Codex Binder在程序无法解决的问题上明显优于Codex SQL 10.1%，所以这是性能主要提升的关键。

除了性能优势以外，我们也探索了很多binder其他的优势。

首先是可解释性，显式的程序可以协助研究者去进行人工调试和错误分析，这一点End-to-End是做不到的。

第二点是可扩展性和鲁棒性。我们通过提示Codex用相关的行填充原始表，扩展成100、200和500行的表，并人工修改相应的问题和答案。我们发现随着表大小的增加，End-to-end的性能急剧下降，而Binder始终优于它，性能仅略有下降。当存在与问题相关内容相似的干扰因素时，End-to-end方法对嘈杂的输入更脆弱，更容易被相似的文本和数字混淆。

Extending Binder to more diverse

tasks and domains

我们尝试将Binder扩展到不同的领域和语言。首先是多模态的输入，我们使用的数据集是Multi-modal QA，它的输入包括表格、文本及图片。在这样的场景下，我们的方法几乎可以达到之前的SOTA水平，如果使用更好的模型作为语言模型API的话，性能会提升更多。