强化学习：通过Self-Play来扩增多轮次Text-to-SQL数据集 Augmenting Multi-Turn Text-to-SQL Datasets with Self-Play

https://arxiv.org/abs/2210.12096

1介绍

主要发现：

• Self-Play有助于文本到SQL模型学习各种会话主题关系并改善跨领域的泛化能力。

• Self-Play提高了多数SQL类型的性能。模型在中等难度的查询上表现尤其出色。

• Self-Play提高了束搜索的性能。

2.1任务定义

Text-to-SQL可以在给定数据库 D、当前用户语句 Ut 和对话上下文 Ct（通常是之前的用户语句 U<t）的情况下，生成有效且可执行的 SQL 查询 Qt：

3方法

3.1 The SQL-to-Text Model

设计了一个用户模拟器（SQL-to-text 模型）与文本-SQL 模型进行对话，以生成合成交互。用户模拟器能在每次转折时产生一个人类用户会提出的有意义的问题。在每次交互中，用户都有一个要实现的目标。我们明确地将用户目标 G 作为 SQL 文本转换模型的条件，以鼓励用户模拟器提出与该目标相关的问题。从形式上看，SQL-to-text 模型每次都会计算以下条件：

其中上下文 Ct 包含之前的用户问题 U<t。在训练过程中，G 是最终回合 T 的 SQL 查询，即 QT。 SQL-to-Text 可以生成新的问题，从而增加数据集中用户对话流的多样性，提高泛化能力。

3.2 Self-Play

在gold training data上对文本到SQL和SQL到文本模型进行预训练，然后使用生成的模型进行对话以生成合成交互。生成的交互会被评估并过滤，只保留与目标SQL查询相似的交互。

通过最小化负对数似然在gold training data上对文本到 SQL 和 SQL 到文本模型进行预训练

使用相似度分数score(QT, G)比较最后一轮的生成的SQL查询QT和采样的目标G。（将SQL查询QT和G分解成SQL子结构QTs, Gs（例如select, where, group_by, order_by语句），并计算每个子结构的准确性。让score(QT, G)成为所有子结构准确性的平均值。如果score(QT, G)大于阈值w，就保留合成对话。）

3.3 Self-Training

使用gold training data和过滤后的合成交互数据重新训练一个新的texttoSQL 模型和一个新的 SQLtotext模型。

 

先在gold interactions预训练T2S和S2T模型

for

  取样目标查询

  两个模型生成交互

  计算交互的score(QT, G)

  如果大于阈值则

  取用该交互

在gold interactions和新生成交互上重新训练两个模型

 

可以将过滤后的合成数据与gold training data结合起来，或者在使用gold training data上进行微调之前在合成交互上进行预训练。采用了第二种方法，因为发现第二种方法的性能略优于第一种方法。

4数据集和主要结果

数据集

我们在两个大规模基准数据集SParC（Yu et al., 2019b）和CoSQL（Yu et al., 2019a）上评估我们的方法，表1总结了这两个数据集的统计信息：

SParC是一个跨越200个数据库的多轮文本到SQL数据集，其中的表覆盖了138个不同的领域。交互中的每个问题都属于四种主题关系之一：细化、主题-实体、主题-属性和答案细化（Bertomeu等人，2006）。例如，给定一个问题“哪个专业的学生最少？”，下一个查询可以是一个“细化”查询，“最受欢迎的是哪一个？”，这个问题询问的是与前一个问题相同的实体，但是有一个不同的约束。

CoSQL是SParC的对话版本。在CoSQL中，系统除了生成SQL查询外，还生成自然语言响应。它采用了奥兹巫师设置（Budzianowski等人，2018）进行收集。这个数据集用于三个任务，包括状态跟踪、用户行为预测和响应生成。我们使用这个数据集进行状态跟踪，目标是在每个轮次将用户话语映射到一个SQL查询。

评估指标

根据Yu等人（2018b），我们使用问题匹配（QM）和交互匹配（IM）来衡量性能，这两者都基于精确的集合匹配准确性。通过将预测的 SQL 分解为 SELECT、WHERE、GROUP BY 等子句并计算每个子句的集合匹配分数来计算精确的集合匹配。如果交互中问题的完全匹配集为 1，则 QM 为 1。如果交互中所有问题的完全匹配项为 1，则 IM 为 1。过滤前为 SParC （CoSQL） 生成的self-play训练数据数量为 100,000 （100,000） 和过滤后 49,623 （48,291）。附录 A.2 显示了我们实验的实现细节。

主要结果

我们在表2中报告了主要结果。我们观察到，“w/ PICARD w/ self-play”配置在两个数据集上都取得了最佳结果（通过 QM 和 IM 测量）。这证明了Self-Play好处。Self-Play带来的改进在 SParC 上比在 CoSQL 上更为突出，而 T5-Large w/ PICARD w/ self play 的性能优于 Scholak 等人（2021 年）报告的原版 T5-3B。因此，我们得出结论，self-play是一种有效的数据增强方法，以提高跨域上下文相关文本转 SQL 的性能

5分析

Self-Play产生较短的交互，平均长度为 2.53，而训练数据的平均值为 2.97。图 3 显示了按问题轮次分层的问题匹配 （QM） 准确性。Self-Play后的性能在回合数 ≤ 3 时增加，在回合数 4 时降低。这是因为Self-Play不会产生足够长的交互，如图 2 所示。

如图 4 所示，Self-Play简单模板和超困难模板比例较高，中等和困难模板比例较低。

 

我们在表 3 中比较了 SParC 验证集Self-Play前后的性能。Self-Play为中等难度的互动带来了最大的提升，其次是困难和简单的互动。

6相关工作

Data Augmentation for Semantic Parsing （用于语义解析的数据增强）

数据增强（Feng et al.， 2021）是一种有效的策略，可以在不手动收集新数据的情况下增加训练数据的多样性。数据增强已在 NLP （Jia and Liang， 2016） 中应用于各种任务，例如释义提取 （Barzilay and McKeown， 2001）、机器翻译 （Sennrich et al.， 2016;Liu 等人，2021 年）和问答（Longpre 等人，2019 年）。数据增强在语义解析任务中也被广泛采用（Jia and Liang， 2016;侯等人，2018;Yu 等人，2020 年;Zhong 等人，2021 年;Wang 等人，2021 年;Yang 等人，2022 年）。以前大多数关于文本到 SQL 任务的数据增强工作都使用单轮数据集，例如 SPIDER。Yu et al. （2018a） 使用从 Spider 中提取的 question-SQL 模式创建跨域增强数据。Guo et al. （2018） 使用语法和表感知语义解析器和基于副本的潜在变量模型分别生成 SQL 和问题。Wu et al. （2021） 应用抽象语法树语法生成 SQL 和分层 SQL-toquestion 生成模型来生成问题。

多轮次 SQL 转文本数据集的数据增强尚未得到充分探索。与单轮数据集相比，该任务更具挑战性，因为它需要考虑复杂的上下文依赖关系和用户目标的顺序生成。Zhong et al. （2021） 将前向语义解析器与后向话语生成器相结合，以生成多轮交互。这种算法将上下文窗口截断为 2，并且在生成过程中不以全局用户目标为条件。因此，此方法无法考虑长期上下文依赖关系。不同的是，我们的方法对每个打开都设置了其完整的历史上下文和采样的用户目标。这样可以捕获更长的上下文依赖关系。有关我们提出的Self-Play方法与Zhong et al. （2021）之间的模型性能的进一步比较，请参阅附录A.3（我们进一步研究了在生成交互时是否有必要以用户目标 G 为条件。当我们消融用户目标时，SParC 上的 QM 分数从 62.4 下降到 59.8）

Self-Play in Task-Oriented Dialogue（面向任务的对话中的Self-Play）

由于向真实用户学习既昂贵又耗时，因此在面向任务的对话系统中采用了用户模拟器的Self-Play（Levin et al.， 2000）。两种类型的用户模拟器，包括基于规则的（Schatzmann et al.， 2006， 2007;Schatzmann 和 Young，2009 年;Shah 等人，2018b，a））和数据驱动（Asri 等人，2016 年;Gür 等人，2018 年;Kreyssig 等人，2018 年;Tseng et al.， 2021） 被广泛采用。

基于规则的用户模拟器利用手工制定的规则来构建对话计划，

数据驱动的用户模拟器则在gold对话上进行训练。

在面向任务的对话系统中，每个域都有自己的槽值对，这些值对是多元独立的。因此，使系统适应新领域通常需要数据收集、模型重新设计和重新训练。与此不同的是，对于文本到 SQL 任务，SQL 与域无关。Self-Play非常适合跨域文本到 SQL 任务，因为它可以合成用户和系统交互以泛化到新域。

Mitigating the Exposure Bias （减轻接触偏差）

接触偏差（Exposure bias）（Bengio等人，2015; Ranzato等人，2015）是指当模型仅接触到真实的（ground-truth）交互，而没有根据其自身预测的交互进行条件化时，训练和生成过程之间出现的不匹配。已经有几种方法（Ranzato等人，2015; Shen等人，2016; Leblond等人，2017; Welleck等人，2019）被提出来弥合这种训练和测试时的差异。我们的模型证明了使用高质量预测交互来重新训练原始模型的好处，这是一种合理的方式来让模型依赖其自身的预测，从而缓解暴露偏差（exposure bias）问题。

7总结

我们探索了在跨领域会话语义解析任务中使用Self-Play作为生成合成对话的数据增强方法，以应对数据稀缺和跨领域泛化的挑战。

局限：

尽管Self-Play后过滤的对话大多基于采样的用户目标，但一些合成对话是不自然的，如第 table5 所示，因此，更可控的Self-Play 生成会惩罚产生重复性问题，并鼓励持续更长回合的对话是可取的。这些实验需要大量的 GPU 资源，并限制了我们运行一轮的Self-Play。使用重新训练的模型迭代运行多轮Self-Play可能会进一步改善结果。数据集方面，在现实世界中，由于人类不会像 SParC 和 CoSQL 那样在受控环境中提问，因此数据分布可能会更加嘈杂和复杂。Self-Play无法生成与训练数据不同的合成对话来模拟真实世界的场景。

多轮问答SParC数据集

https://yale-lily.github.io/sparc

https://drive.google.com/uc?export=download&id=13Abvu5SUMSP3SJM-ZIj66mOkeyAquR73

 

SParC是一个跨领域的多轮Text-to-SQL数据集。它包含有4298个问题轮次，大约有12k+的自然语言问句到SQL标注的Question-SQL对。这些问题来自于138个不同领域的200个复杂数据库。

SParC对研究者带来的挑战主要有以下三点：

1. 这是一个多轮对话形式的Text-to-SQL解析，模型需要考虑复杂的上下文依赖关系；

2. 由于对话的引入，使得数据集具有更大的语义多样性；

3. 具有跨域特性，即验证和测试是在与训练集完全不同的数据库schema上进行，因而模型需要有足够强的泛化性能。

如上图所示，数据库的简介记为D1，简要介绍了这个数据库的信息，即是一个关于学生宿舍的数据库，包含有5个数据表。而这次交互的目的是C1，即找到住在拥有电视机休息室的宿舍的学生的姓名。为了实现这个目标，一共进行了四次对话。用户的自然语言问句记为Q，系统解析后的SQL语句记为S。

SParC数据集的创建包括四个阶段：

1. 选择交互目标；

2. 提出问题；

3. 进行SQL标注；

4. 检查回顾。

SParC共邀请了15个SQL经验的大学生来进行提问和标注。每个系列中的相邻问题之间有着如下四种主题关联：

1. 约束更加细化：当前的问句和上一个问句相比，问了一个相同类型的实体但是有着不同的约束。比如，前一个问题问：”哪一个专业的学生人最少？；而当前的问题问：”那最受欢迎的专业呢？“

2. 主题扩展：当前的问句询问上一个问句的同一个实体的另外的属性。例如，前一个问句问：”Anonymous Donor Hall的容量是多少？“；而当前的问句问：”列出它所有的设施。“

3. 属性转移：当前的问句询问另一个实体的相同属性。例如，前一个问句问：”告诉我那部叫做Double Down的电视剧的评分。“；而当前的问题则是：”那Keepers（这部电视剧）呢？“

4. 答案更加细化：当前的问句需要上一个问题的答案给出的实体中的某些子集的其他属性。例如，前一个问题是：”请列出所有不同的部门名称。“；而现在的问题是”在统计部门的所有员工的平均薪资是多少？“

在进行完提问后，每个标注者都将对自己的问题进行SQL转化，并确保在相应数据库上执行得到正确的答案。

多轮问答CoSQL数据集

https://yale-lily.github.io/cosql

CoSQL 数据集的收集方式和 SParC 类似，都是基于Spider数据集，从Spider 数据集中收集了 medium, hard, extra hard 难度的SQL语句，然后再分别由用户和专家进行不同类型的标注和产生序列问题。

相比于之前的多轮Text-to-SQL数据集SParC，CoSQL数据集使用了Wizard-of-Oz的标注方式，数据集更加贴近真实应用场景，也更具挑战性。

CoSQL数据集是为实际对话系统应用场景下设计的数据集，虽然 Sparc 数据集已经能够对多轮Text-to-SQL 问题进行一个很好的描述，但是仍然有一些不足之处。 比如一个完整的多轮text-to-sql系统应该能够做到下面几点：

• 检测用户的问题是否可以被系统回答

• 在可能的情况下把用户的问题转换成可以执行的SQL语句。

• 能够给用户一个可以理解和验证的反馈。

比如在用户问了一个问题之后，在系统每次产生一个SQL语句之后，都会紧接着产生一个CONFIRM_SQL 类型的回复，告诉用户本次查询做了什么事情，方便用户进行确认。同时在检测到用户的问题不清楚时，会进行一个 CLARIFY 操作，和用户确认其具体需求是什么。

ChatGPT测试

文本-SQL 模型

previous utterances:"What are all the airlines?"

current utterance:"Of these , whitch is Jetblue Airways?"

database:Airlines:id|airline|abbreviation Airports:city|airport_code|airport_name Flights:airline|flight_no|source_airport

write a SQL to answer current utterance:

To answer the current utterance "Of these, which is Jetblue Airways?", we need to check if "Jetblue Airways" exists in the "airline" column of the "Airlines" table. Here is the SQL query for this:

 

SELECT airline 
FROM Airlines 
WHERE airline = 'Jetblue Airways';

 

This query will return the airline "Jetblue Airways" if it exists in the "airline" column of the "Airlines" table. If "Jetblue Airways" does not exist in the table, the query will return an empty result.

 

用户模拟器（SQL-to-text 模型）

User goal:"SELECT Country FROM Airlines WHERE Airline = "JetBlue Airways""

previous utterances:"Of these,which is Jetblue Airways? What are all the airlines?"

last SQL query:"SELECT * FROM Airlines WHERE airline ='Jetblue Airways'"

database:Airlines:id|airline|abbreviation Airports:city|airport_code|airport_name Flights:airline|flight_no|source_airport

Further propose a user goal oriented question based on previous utterances:

Given the user goal "SELECT Country FROM Airlines WHERE Airline = 'JetBlue Airways'", the previous utterances, and the last SQL query, a user goal-oriented question could be:

 

"Can you tell me the country where JetBlue Airways is based?"

 

文本-SQL 模型

previous utterances:"What are all the airlines?Of these , whitch is Jetblue Airways?"

current utterance:"Can you tell me the country where JetBlue Airways is based?"

database:Airlines:id|airline|abbreviation Airports:city|airport_code|airport_name Flights:airline|flight_no|source_airport

write a SQL to answer current utterance:

From the schema provided, it seems like the 'Airlines' table doesn't contain a 'Country' column. Therefore, we can't directly answer the question "Can you tell me the country where JetBlue Airways is based?" using the provided database schema.

 

However, if there was a 'Country' column in the 'Airlines' table, the SQL query would look like this:

 

SELECT Country 
FROM Airlines 
WHERE airline = 'JetBlue Airways';

 

This would return the country where JetBlue Airways is based.

 

If there is additional information in the database that can indirectly provide the country of the airline, such as the location of the airline's main hub airport, we could potentially construct a more complex SQL query to retrieve this information. However, based on the provided schema, this doesn't seem to be possible.