【论文浅尝】CODEIE: Large Code Generation Models are Better Few-ShotInformation Extractors

INTRODUCTION

        在本文提出将结构化输出转换为代码而不是自然语言的形式，并利用代码的生成法学硕士(code -LLMs)，如Codex来执行IE任。与nl - llm相比，我们展示了代码- llm可以通过设计代码样式提示并将这些IE任务制定为代码生成任务来与这些IE任务很好地对齐。

以下图中的示例输入“Steve在1998年成为Apple的CEO”为例，我们将其包装成一段Python代码，并将结构化实体输出制定为带有键“text”和“type”的Python字典。我们将它们组合成一个Python函数，该函数在语义上等同于NER示例：

文中在NER和RE任务的七个基准上进行了实验，并仔细分析了我们的方法(称为CODEIE)的好处。研究结果如下:

1)具有代码样式输入的提示code- llm(Codex) 始终优于微调UIE，这是一种针对IE任务的特别预训练模型，并且在少量设置下提示nl - llm(GPT-3)。

2)对于相同的LLM(无论是NL-LLM还是CodeLLM)，代码风格的提示符比线性化的文本提示符表现得更好，展示了用代码表示结构化目标的优势。

3)在相同的提示符(自然语言或代码)下，Code - LLM(即Codex)比NL-LLM(即GPT-3)实现了更好的性能，证明了使用code - llm执行IE任务的优点。

4)与自然语言提示相比，使用代码样式的提示对输出结构的保真度更高，即输出的结构错误率更低

下图总结了IE任务中等规模模型、nl - llm和code - llm之间的层次差异。 

CODEIE 

Task Formulation

给定一个输入句子x，其中有l个标记, , . . . , , IE任务是从x预测结构化目标y。

NER的目标y是一组(e, t)对，其中e是一个实体跨度(如“Steve”)，t是对应的实体类型(如“person”)。实体跨度是来自x的令牌序列，实体类型属于预定义的实体类型集T。

RE的预测目标y由一组三元组(, r, )组成，其中和是x的两个实体跨度，r∈r是两个实体之间的语义关系(例如，“work for”)。

这里R表示一个预定义的关系类型集。除了提取实体之间的关系外，我们通常还对同时预测实体e1和e2的实体类型t1和t2感兴趣。

在few-shot设置中，我们得到一个小的带注释的样本集, ，它由每个类的k个样本组成，以组成k-shot设置。

Formulating IE Tasks into Code Generation Task

        代码生成任务是在给定一段不完整的代码的情况下预测后续的代码序列。因此，我们可以将IE任务的输入和输出分别重铸为一段不完整的代码和待预测的代码，这样它们就可以组成一段完整的代码，在语义上等同于原始示例，同时保持编程语言的语法。

        作者使用Python函数来表示IE任务。我们将输入文本x包装成代码样式的提示符，并用结构化的Python元素(如列表、字典等)表示输出结构y。如下图所示，对于NER和RE任务，我们首先将任务名称转换为Python函数的名称，并添加一个文档字符串来说明任务的目标。将输入文本字符串x赋值给变量input_text。然后，我们初始化一个空列表来保存输出，并附加一个描述性注释，如“# extract named entities”，以提示code - llm将命名实体放入列表中。我们将上述代码打包为代码提示符。

对于结构化目标y，我们利用Python列表的追加方法，并将每个基本信息单元(例如，NER任务的一对或RE任务的三元组)表示为Python字典。

因此，code - llm要预测的目标被重新表述为一个字典列表。对于NER，我们向列表中添加键为“text”和“type”的Python字典，其中字典的值是相应的实体跨度和实体类型。对于RE，我们类似地将带有键“rel_type”、“ent1_type”、“ent1_text”、“ent2_type”和“ent2_text”的字典添加到列表中，以表示结构化目标。

Code Format Prompts

func def:主代码格式提示符，将IE任务转换为代码格式

 class init:我们用Python类描述IE任务。

func exec :将IE任务描述为一个函数执行过程。

func init: 通过交换NER和RE任务的格式设计，扰乱了合理的格式设计。

Prompting Code-LLMs with In-Context Demonstrations

在没有任何示例的情况下，通过提示code-llm来执行IE任务并非易事。因此，有必要让code - llm知道在典型的少射设置中有几个标记的样本。 

作者从训练数据集中选择n个样本，并将它们转换为对应的代码风格对。我们将它们连接成一个字符串来组成上下文中的演示⊕…⊕。给定一个到达的测试示例x，我们首先将其转换为代码提示符，并添加演示上下文，即⊕…⊕。

在将构造好的输入输入到Code-LLM之后，我们期望得到一个格式与、、…。

Experiments

Dataset：CoNLL03、ACE04和ACE05E来评估我们在NER任务上的方法。对于关系提取，我们对数据集CoNLL04 、ACE05-R、NYT和SciERC进行了评估。

Code-LLMs：code-davinci-002

Baselines：

Fine-tuning：对T5和UIE的基本版本和大版本进行了微调。

Prompting：与prompt nl - llm，特别是GPT-3进行比较。

Few-Shot Setting：对于每个IE任务，我们为每个实体或关系类型随机抽取k个训练样本，以构建k-shot训练集。k的值在不同的数据集上是不同的，以满足GPT-3的最大长度限制(4097)。

Evaluation：与之前的工作一样，使用Entity F1和Relation Strict F1作为NER任务和RE任务的评估指标。

Result

如上图所示，LLM(GPT-3和Codex)在few-shot设置下的表现优于中等规模的模型(T5和UIE)，在IE任务中表现出强大的few-show学习能力。 

本文提出的Codex + code prompt (Codex + code prompt)方法取得了最好的结果，T5-large和T5-base分别提高了132%和327%。

我们比较代码提示和文本提示的性能，即比较GPT-3 +text prompt 与GPT-3 +code prompt。因此，我们发现用代码提示llm可显著提高(GPT-3为23%，Codex为16%)。令人惊讶的是，代码提示对GPT-3更有利。

当使用相同类型的提示符并比较使用的llm时，即GPT-3 +text prompt和Codex +text prompt，比较GPT-3 +code promp和Codex +code promp，我们发现Codex始终优于GPT-3，这表明代码预训练对IE任务是有益的。

在CoNLL03和CoNLL04上，作者进一步比较了这些方法在不同射击次数下的差异。当增加拍摄次数时，所得到的现象仍然成立。

作者还探索文本提示和代码提示的其他提示设计。作者发现代码提示始终优于文本提示。因此，使用代码提示符的优越性能主要取决于代码风格，而不是提示符设计的某些特定实例。

为了验证所提出方法的多功能性和观察到的结果，作者进一步对GPT-3的text- davincii -001版本和Codex的code- davincii -001版本进行了实验，我们发现前面的结果仍然适用。