当前位置： 首页>数据库>正文

DukeMTMCreid数据集论文 数据集论文怎么写

数据库2024-04-22 20:17:17

过去一些优秀的模型例如seq2seq架构已经能够实现80%以上的匹配精确度在SQL查询上，但是这些工作实际上是在做语义匹配而非语义解析。现有的语义解析数据集存在两个问题，一个是数据集规模太小，无法训练一个更加现代化的模型，同时单一数据库同时用于训练和测试当中，那任务难度肯定简单很多；二是逻辑形式的SQL标签规模很小，并且每个program中都多多少少存在一些在数据集规模变大时查询有误的问题。

论文来源：Spider: A large-scale human-labeled dataset for complex and cross-domain semantic parsing and text-to-sql task

1. Introduction

  1. 过去一些优秀的模型例如seq2seq架构已经能够实现80%以上的匹配精确度在SQL查询上，但是这些工作实际上是在做语义匹配而非语义解析。现有的语义解析数据集存在两个问题，一个是数据集规模太小，无法训练一个更加现代化的模型，同时单一数据库同时用于训练和测试当中，那任务难度肯定简单很多；二是逻辑形式的SQL标签规模很小，并且每个program中都多多少少存在一些在数据集规模变大时查询有误的问题。
  2. 有人测试了尝试分开训练集和测试集上的数据库以后，发现模型无法推广到没看到过的数据库中，也就是泛化能力较差，另外数据集类似WikiSQL，SQL查询难度过于简单，无法很好的测试模型在复杂问题上的表现，因此亟需一个包含大量复杂程序和多表数据库的SP数据集。
  3. 创建此类的SP数据集有以下难度：在线平台上很难找到那么多的数据库同时有很多表；另外标注的人也必须要理解复杂数据库的模式从而创建出一系列的查询问题并且包含了所有SQL的查询类型。并且还需要对问题和SQL进行审查和质量检查，这些都需要非常充足的数据库知识。
  4. Spider的好处在于可以在SQL查询上实现训练集和测试集在database上的区分，克服了之前数据集的两个缺点。并且定义了一个新的任务模式，模型不仅需要推广到新的程式，也就是查询组合方式，同时还需要推广到新的数据库。测试发现目前最先进的模型仅实现了12.4%的精确匹配精度。表明提升空间还很大。

2. Related Work and Existing Datasets

  1. 具有不同查询的语义解析数据集已经有很多了，但是都是针对于特定的domain，并且没有针对多SQL查询的标签规范
  2. 以前的工作训练模型都不需要考虑schema作为输入，因为他们使用的是单一的数据库作为训练和测试。
  3. 我们希望模型不仅能够泛化未看到过的SQL查询，同时也能够泛化到未看见的数据库，WikiSQL似乎做到了这一点，但是它的SQL标签仅仅包含了简单的SELECT语句，所有的数据库只包含了单一的table，并且没有JOIN，GROUP BY，ORDER BY等语句。

3. Corpus Construction

  1. 收集具有复杂模式的数据库是很困难的 ，大部分工业界和学术界的数据库都不是公开可用的。论文提出的数据库共有200个，来源于三种渠道：一、大学数据库课程、SQL教程网站、在线csv、教科书示例（70个）；二、DatabaseAnswers1中收集了40个；三、基于WikiSQL创建了剩余的90个数据库
  2. 如果存在一些无意义的列名以及遗漏相关的外键，则会手动更正一些数据库模式；同时对于学生id，通常数据库中都会使用stuid这种缩写形式，但为了保证系统仅需要处理语义解析问题，因此把stuid这种形式转回student id的形式
  3. 对于question和sql标注，都是人工由精通sql的cs专业学生来完成，同时确保了以下三方面：A）SQL查询类别常见的全部都覆盖到了，并且确保每个表都至少出现在一次查询中；B）设计了一个SQL注释协议，避免多个可接受的SQL查询影响模型训练，都采取一套标注模式；C）没有创建模棱两可的问题，同时也没有创建那些需要额外的数据库以外的知识才能回答的问题。模棱两可就比如说学校里最受欢迎的课程是什么，这个最受欢迎也许是指学生的评价，或者也可能是选课人数最多的课程，尽管这些最受欢迎的概念可以通过系统与用户多轮询问来确定具体的含义，但是本数据库的目的不是探讨这个问题，并且在单数据集的问题当中，模棱两可性不是大问题，而就复杂的跨域问题，即使问题不是模棱两可的，对于目前最佳的模型跑出来的效果都很差，所以就避免了模棱两可性；第二点说的是，比如查询语句为：请告诉我向John汇报工作的员工的id号，汇报工作在人类的理解当中当然知道是John的手下，而这个知识是额外需要提供的，这一点是未来的研究方向。
  4. 标注的工具采用的是sqlite web3
  5. 审阅过程首先查看SQL语句能否正确执行，同时对于同一问题多个SQL同时成立的问题，审阅者需要查看SQL标注是否符合之前规定的协议。最后是检查当前数据库中的所有SQL标签是否涵盖了所有常见的SQL子句。
  6. 检查完SQL标注后，英语母语的人需要重新审阅修改每一个查询的问题，包括语法上是否正确自然，并且检查问题是否正确反映了对应的SQL查询属性和标注。最后为了提高问题的多样性，还会要求标注者给一些问题添加一个释义版本【不理解】。
  7. 最后的最后，让最有经验的标注者进行最后的审查，如果之前多个审阅者对于某个标注问题上产生了歧义，则由这个最有经验的人负责拍版。另外还写了一个脚本来执行和解析所有SQL标注，确保都是正确无误的。

4. Dataset Statistics and Comparison

  1. Spider数据集有很多独特特性，包括相较于之前text2sql数据集总数的 10倍的ORDER BY和GROUP BY语句，Spider是目前唯一一个同时包含复杂 SQL查询和跨域多表数据库的text2sql数据集，它不仅可以测试系统泛化查询语句的能力，也能够检测系统泛化到新的domain的能力。

5. Task Defifinition

  1. 模型需要能够真正理解问题的语义含义才能够做出正确的推断预测，而不是死记硬背。模型在这个人物上的表现可以反映真实的语义解析的能力。
  2. 泛化能力不是这个数据集当前最主要的考察任务，目前最主要的任务是考察如何能够预测准确SQL结构以及列（因为目前最优秀的模型跑出来的预测结果都很一般），现实当中一般都要多次和用户确认需求，实际上大多数人知道怎么用自然语言表达而不知道SQL的逻辑。
  3. 外部知识诸如XX的寿命有多长这种，在本数据集中不是主要考察的能力内容
  4. 需要假设所有的表名和列名都是直观清晰的，因此对于stu id这种都需要转换成student id

6. Evaluation Metrics

  1. 根据查询的难度来衡量系统的准确性，伴随语料库一起发布了官方的评测脚本
  2. 组件匹配：对SELECT/WHERE/GROUP BY/KEYWORDS这些组件分解成多个子组件，例如SELECT avg(col1), max(col2), min(col1)，首先解析并分解为一个集合(avg, min, col1), (max, col2)，然后再查看是否匹配；在评估中，将每个组件视为一个集合，也就是调整顺序不影响结果，例如SELECT avg(col1), min(col1), max(col2)和SELECT avg(col1), max(col2), min(col1)被认为是相同的查询。对于每个组件的整体性能，采用的是在每个精确集匹配上的F1 score
  3. 精确匹配：当且仅当每个组件都正确时，预测的查询才是正确的。
  4. 精确匹配可能会导致false negative【不理解】的评估，因此还考虑了执行准确度，同样的如果返回的结果是和标准一样，但语义不同时，可能会出现false positive的报错，这一点也可以彼此互补；最后如果出现了JOIN和GROUP在查询语句中，则评估可以接受多个keys。
  5. 为了更好地了解模型在不同查询上的性能，将SQL查询分为了4个级别：简单、中等、困难、特别困难。根据SQL组件的数量、选择和条件来定义难度，包含更多SQL关键字例如GROUP BY、ORDER BY、INTERSECT、嵌套子查询、列选择和聚合语句等会被认为难度是很大的。

7. Methods

  1. 为了更好地分析语料库的难度，尝试了几种最先进的语义解析模型，由于数据集有着根本性差异，所以调整任务，将数据库的所有表中列连接在一起创建一个大列列表来给到model输入，同时对于每个模型，都把问题实例的列选择空间限制到所查询的数据库的所有列，而不是整个语料库中的所有列

8. Experimental Results and Discussion

  1. 示例拆分：分为8659个train，1034个dev，以及2147个test
  2. 数据库拆分：将206个数据库拆分为146个train，20个dev，以及40个test，同一个数据库的所有问题都在同一个分组中（train/dev/test）
  3. 基于seq2seq的模型表现性能非常低，在可能某一的特别难的示例中能够取得好的结果，但大多数情况下都会出现语法错误，注意力机制也帮助不大
  4. 相比之下SQLNet和TypeSQL表现明显优于seq2seq，尽管能够生成有效查询，但是无法生成嵌套以及带关键字的查询
  5. 所有的模型在WHERE子句预测方面都遇到了很大的困难。
  6. 总体来说所有模型表现都很低，表明此任务挑战难度很大。
  7. 在示例拆分和数据库拆分中，数据库拆分后的性能远低于示例拆分的性能，特别是TypeSQL的性能在数据库拆分数据集上降幅最大，这可以总结为该模型在复杂的SQL预测上表现良好，但是未能推广到新的数据库中（泛化能力不足）
  8. 所有模型在数据库拆分的情况下，对于列选择的表现都要比示例拆分差很多。
  9. 对于复杂的数据库模式，外键数量越多，模型的性能会快速下降（参照图4），一个原因是模型从复杂数据库模式很多候选键中选取表名和列名，另外，复杂的模式使得模型更难捕捉拥有外键的几张表之间的关系。这表明这个任务需要更加有效的方法来编码表和外键的关系。

9. Conclusion

  1. 本论文介绍了Spider数据集，是一个相较于之前的数据集有着更大挑战性的语义解析任务。通过测试表现发现现有模型依旧有很大的提升空间。




https://www.xamrdz.com/database/6vx1928771.html

相关文章：