php做网站安全在线游戏网页版

当前位置： 首页 > news >正文

php做网站安全,在线游戏网页版,陕西网站备案流程,销售成功案例分享NL2SQL进阶系列(5)#xff1a;论文解读业界前沿方案#xff08;DIN-SQL、C3-SQL、DAIL-SQL#xff09;、新一代数据集BIRD-SQL解读 NL2SQL基础系列(1)#xff1a;业界顶尖排行榜、权威测评数据集及LLM大模型#xff08;Spider vs BIRD#xff09;全面对比优劣分析[Text2…NL2SQL进阶系列(5)论文解读业界前沿方案DIN-SQL、C3-SQL、DAIL-SQL、新一代数据集BIRD-SQL解读 NL2SQL基础系列(1)业界顶尖排行榜、权威测评数据集及LLM大模型Spider vs BIRD全面对比优劣分析[Text2SQL、Text2DSL] NL2SQL基础系列(2)主流大模型与微调方法精选集Text2SQL经典算法技术回顾七年发展脉络梳理 NL2SQL进阶系列(1)DB-GPT-Hub、SQLcoder、Text2SQL开源应用实践详解 NL2SQL进阶系列(2)DAIL-SQL、DB-GPT开源应用实践详解[Text2SQL] NL2SQL进阶系列(3)Data-Copilot、Chat2DB、Vanna Text2SQL优化框架开源应用实践详解[Text2SQL] ☆☆NL2SQL进阶系列(4)ConvAI、DIN-SQL、C3-浙大、DAIL-SQL-阿里等16个业界开源应用实践详解[Text2SQL] NL2SQL实践系列(1)深入解析Prompt工程在text2sql中的应用技巧 NL2SQL实践系列(2)2024最新模型实战效果(Chat2DB-GLM、书生·浦语2、InternLM2-SQL等)以及工业级案例教学 NL2SQL任务的目标是将用户对某个数据库的自然语言问题转化为相应的SQL查询。随着LLM的发展使用LLM进行NL2SQL已成为一种新的范式。在这一过程中如何利用提示工程来发掘LLM的NL2SQL能力显得尤为重要。 1.DIN-SQL-V3 2023.11.02 [v1] Fri, 21 Apr 2023 15:02:18 UTC (8,895 KB)[v2] Thu, 27 Apr 2023 17:49:23 UTC (8,895 KB)[v3] Thu, 2 Nov 2023 20:30:12 UTC (2,202 KB) 论文链接DIN-SQL: Decomposed In-Context Learning of Text-to-SQL withSelf-Correction 摘要我们研究将复杂的文本到 SQL 任务分解为更小的子任务的问题以及这种分解如何显着提高大型语言模型 (LLM) 在推理过程中的性能。目前在具有挑战性的文本到 SQL 数据集例如 Spider上微调模型的性能与使用 LLM 的提示方法之间存在显着差距。我们证明 SQL 查询的生成可以分解为子问题并且这些子问题的解决方案可以输入到 LLM 中以显着提高其性能。我们对三个 LLM 进行的实验表明这种方法持续将其简单的小样本性能提高了大约 10%将 LLM 的准确性推向 SOTA 或超越它。在 Spider 的 Holdout 测试集上执行准确度方面的 SOTA 为 79.9使用我们方法的新 SOTA 为 85.3。我们的情境学习方法比许多经过严格调整的模型至少高出 5%。 在本文中我们提出了一种基于少样本提示few-shot prompting的新颖方法将自然语言文本到 SQL称为 text-to-SQL的任务分解为多个步骤。之前使用 LLM 进行文本到 SQL 提示的工作仅在零样本 zero-shot设置中进行评估。然而零样本提示仅提供了LLM对于大多数任务的潜在能力的下限。在这项工作中我们首先评估了 LLM 在少样本设置中的性能然后提出了我们的分解方法该方法大大优于少样本提示方法。为了将我们的方法与以前的方法进行比较我们使用执行精度和匹配精度这两个官方评估指标。我们利用 CodeX 系列的两个变体即 Davinci 和 Cushman以及 GPT-4 模型进行prompt。在Spider的测试集上我们的方法使用GPT-4和CodeX Davinci模型分别实现了85.3和78.2的执行精度并且使用相同模型分别实现了60和57的匹配精度。 1.1 Few-shot Error Analysis 为了更好地了解 LLM 在少样本设置下失败的地方我们从 Spider 数据集的训练集中的不同数据库中随机抽取了 500 个查询排除提示中使用的所有数据库。我们搜索的查询产生的结果与Spider官方给出的标准的结果不同因此执行准确性不合格。我们手动检查了这些故障并将其分为六类如图 1 所示并在接下来进行讨论。 Schema Linking 此类别包含最大数量的失败查询并包含模型无法识别问题中提到的列名称、表名称或实体的实例。在某些情况下查询需要聚合函数但会选择匹配的列名称。例如问题 “所有体育场的平均容量和最大容量是多少” 的数据库模式包括一个名为 “average” 的列该列是由模型选择的而不是取容量列的平均值。 JOIN 这是第二大类别包括需要 JOIN 的查询但模型无法识别所需的所有表或连接表的正确外键。 GROUP BY 此类别包括以下情况SQL 语句需要 GROUP BY 子句但模型无法识别分组的需要或者使用了错误的列对结果进行分组。 Queries with Nesting and Set Operations 对于此类别Spider 给出的标准查询使用嵌套或集合操作但模型无法识别嵌套结构或无法检测正确的嵌套或集合操作。 Invalid SQL 一小部分生成的 SQL 语句存在语法错误无法执行。 Miscellaneous 此类别包括不属于上述任何类别的案例。示例包括包含额外谓词、缺少谓词或缺少或冗余 DISTINCT 或 DESC 关键字的 SQL 查询。此类别还包括缺少 WHERE 子句或查询具有冗余聚合函数的情况。 1.2 Methodology 尽管少样本比零样本模型有所改进但少样本模型在处理更复杂的查询时遇到了困难包括那些模式链接不那么简单的查询以及使用多个联接或具有嵌套结构的查询如第 3 节中所述。 我们应对这些挑战的方法是将问题分解为更小的子问题解决每个子问题并使用这些解决方案构建原始问题的解决方案。 类似的方法例如思想链提示Wei et al, 2022b和从最少到最多的提示Zhou et al, 2022已被用来提高法学硕士在任务上的表现这些任务可以分解为多个步骤例如数学应用题和构图概括Cobbe 等人2021Lake 和 Baroni2018。与这些任务具有过程结构其中一个步骤直接进入下一步的领域不同SQL 查询在大多数部分都是声明性的可能的步骤及其边界不太清晰。然而编写 SQL 查询的思维过程可以分解为 (1) 检测与查询相关的数据库表和列(2) 识别更复杂查询的一般查询结构例如分组、嵌套、多重联接 、集合运算等3制定任何可以识别的过程子组件以及4根据子问题的解决方案编写最终查询。 基于这个思维过程我们提出的分解文本到 SQL 任务的方法由四个模块组成如图 2 所示1模式链接2查询分类和分解3SQL 生成 (4) 自我修正将在以下小节中详细解释。虽然这些模块可以使用文献中的技术来实现但我们都使用提示技术来实现它们以表明如果问题被简单地分解到正确的粒度级别LLM 就有能力解决所有这些问题。 Schema Linking Module模式链接 模式链接负责识别自然语言查询中对数据库模式和条件值的引用。 它被证明有助于跨领域的通用性和复杂查询的综合Lei 等人2020使其成为几乎所有现有文本到 SQL 方法的关键初步步骤。在我们的案例中这也是 LLM 失败次数最多的一个类别图 2。我们设计了一个基于提示的模式链接模块。提示包括从 Spider 数据集的训练集中随机选择的 10 个样本按照思路链模板Wei 等人2022b提示以 “让我们一步一步思考” 开头正如 Kojima 等人2022建议的那样。 方案是用10-Shot Prompt zero-shot COT的引导词(Let’s think Step by Step)让模型逐步思考给出针对用户问题应该查询的表以及表中需要查询的字段过滤条件字段和Join条件字段。 Schema Link的输出会作为后续SQL生成任务的输入帮助模型先定位字段再编写SQL。Prompt如下 对于问题中每次提到的列名都会从给定的数据库模式中选择相应的列及其表。还从问题中提取可能的实体和单元格值。图 3 给出了一个示例完整的提示可以在附录 A.3 中找到。 Classification Decomposition Module查询分类和分解模块 对于每个连接都有可能未检测到正确的表或连接条件。随着查询中联接数量的增加至少一个联接无法正确生成的可能性也会增加。缓解该问题的一种方法是引入一个模块来检测要连接的表。此外一些查询具有过程组件例如不相关的子查询它们可以独立生成并与主查询合并。为了解决这些问题我们引入了查询分类和分解模块。该模块将每个查询分为三类之一简单、非嵌套复杂和嵌套复杂。 **easy *类包括无需连接或嵌套即可回答的单表查询。medium允许多表Join但是没有嵌套查询;非嵌套类包括需要连接但没有子查询的查询hard多表Join 嵌套查询:嵌套类中的查询可以需要连接、子查询和集合操作 类标签对于我们的查询生成模块很重要该模块对每个查询类使用不同的提示。除了类标签之外查询分类和分解还检测要为非嵌套和嵌套查询以及可能为嵌套查询检测到的任何子查询连接的表集。图 4 显示了提供给模型的示例输入以及模型生成的输出。 SQL Generation ModuleSQL生成 随着查询变得更加复杂必须合并额外的中间步骤来弥合自然语言问题和 SQL 语句之间的差距。这种差距在文献中被称为不匹配问题Guo et al, 2019对 SQL 生成提出了重大挑战这是因为 SQL 主要是为查询关系数据库而设计的而不是表示自然语言中的含义。 虽然更复杂的查询可以从思路链式提示中列出中间步骤中受益但此类列表可能会降低更简单任务的性能Wei 等人2022b。在相同的基础上我们的查询生成由三个模块组成每个模块针对不同的类别。 对于我们划分的简单类别中的问题没有中间步骤的简单的少量提示就足够了。此类示例 Ej 的演示遵循格式 Qj, Sj, Aj其中 Qj 和 Aj 分别给出英语和 SQL 的查询文本Sj 表示模式链接。 我们的非嵌套复杂类包括需要连接的查询。我们的错误分析第 3 节表明在简单的几次提示下找到正确的列和外键来连接两个表对于法学硕士来说可能具有挑战性特别是当查询需要连接多个表时。为了解决这个问题我们采用中间表示来弥合查询和 SQL 语句之间的差距。文献中已经介绍了各种中间表示。特别是SemQLGuo et al, 2019删除了在自然语言查询中没有明确对应项的运算符 JOIN ON、FROM 和 GROUP BY并合并了 HAVING 和 WHERE 子句。 NatSQLGan 等人2021基于 SemQL 构建并删除了集合运算符。作为我们的中间表示我们使用 NatSQL它与其他模型结合使用时显示出最先进的性能 (Li et al, 2023a)。非嵌套复杂类的示例 Ej 的演示遵循格式 Qj, Sj, Ij, Aj其中 Sj 和 Ij 分别表示第 j 个示例的模式链接和中间表示。 嵌套复杂类是最复杂的类型在生成最终答案之前需要几个中间步骤。此类可以包含不仅需要使用嵌套和集合操作​​例如 EXCEPT、UNION 和 INTERSECT的子查询而且还需要多个表连接的查询与上一个类相同。为了将问题进一步分解为多个步骤我们对此类的提示的设计方式是 LLM 应首先解决子查询然后使用它们生成最终答案。此类提示遵循格式 Qj, Sj , Qj1, Aj1, …, Qjk, Ajk , Ij, Aj其中 k 表示子问题的数量Qji 和 Aji 分别表示第 i 个问题 - 第一个子问题和第 i 个子查询。和之前一样Qj 和 Aj 分别表示英语和 SQL 的查询Sj 给出模式链接Ij 是 NatSQL 中间表示。
附录 A.4 中提供了所有三个查询类别的完整提示并且这三个类别的所有示例均从为分类提示选择的完全相同的数据库中获得。 同样对应以上的3种分类论文采用的3种few-shot-prompt如下 easy直接使用指令表结构 schema Link few-shot Medium表结构和schema Link相同指令加入了zero-shot的思维链激活思维链每一步会对应中间的SQL sub query。But这里有些奇怪的是论文中Medium部分的few-shot很多也是单表查询不需要join的 Hard:few-shot是加入多表查询和嵌套结构的样例 Self-correction Module自我纠正模块 论文的自修正并未引入SQL执行只针对SQL本身修复一些小的语法错误例如缺少DESCDISTINCT等通过zero-shot指令来让模型对生成的SQL直接进行修正。指令如下 instruction #### For the given question, use the provided tables, columns, foreign keys, and primary keys to fix the given SQLite SQL QUERY for any issues. If there are any problems, fix them. If there are no issues, return the SQLite SQL QUERY as is.

Use the following instructions for fixing the SQL QUERY:

1. Use the database values that are explicitly mentioned in the question.
2. Pay attention to the columns that are used for the JOIN by using the Foreign_keys.
3. Use DESC and DISTINCT when needed.
4. Pay attention to the columns that are used for the GROUP BY statement.
5. Pay attention to the columns that are used for the SELECT statement.
6. Only change the GROUP BY clause when necessary (Avoid redundant columns in GROUP BY).
7. Use GROUP BY on one column only.生成的 SQL 查询有时可能会缺少或冗余关键字例如 DESC、DISTINCT 和聚合函数。我们对多个 LLM 的经验表明这些问题在较大的 LLM 中不太常见例如GPT-4 生成的查询比 CodeX 生成的查询具有更少的错误但仍然存在。为了解决这个问题我们提出了一个自我纠正模块指示模型纠正这些小错误。 这是在零样本设置中实现的其中仅向模型提供有错误的代码并要求模型修复错误。我们为自我纠正模块提出了两种不同的提示通用和温和。通过通用提示我们要求模型识别并纠正 “BUGGY SQL” 中的错误。另一方面温和提示并不假设 SQL 查询有错误而是要求模型检查任何潜在问题并提供有关要检查的子句的一些提示。我们的评估表明通用提示可以在 CodeX 模型中产生更好的结果而温和的提示对于 GPT-4 模型更有效。除非另有明确说明否则 DINSQL 中的默认自我更正提示对于 GPT-4 设置为“温和”对于 CodeX 设置为“通用”。通用和温和的自我纠正提示的示例可以在附录 A.6 中找到。 主要方法讲完更多内容细节和测评效果参考原论文 1.3 案例 Zero-shot prompting 用于零样本提示场景的提示灵感来自于 Liu 等人的工作 (2023a) 为 ChatGPT 的提议。在图 6 中我们演示了我们工作中使用的零样本提示的一个示例。 Few-shot prompting 2.C3: Zero-shot Text-to-SQL-2023.07.14 论文链接https://arxiv.org/pdf/2307.07306.pdf 代码 https://github.com/bigbigwatermalon/C3SQL 在DIN-SQL提出的Few-shot方案的基础上C3使用chatgpt作为基座模型探索了zero-shot的方案这样可以进一步降低推理成本。并且在生成效果上和DIN-SQL不相上下。C3方法的框架如图1所示。C3由三个关键组件组成清晰提示CP、Clear Prompting、提示校准CH和一致性输出CO它们分别对应模型输入、模型偏差和模型输出。每个组件的细节如下介绍。 C3也通过Schema Linking先定位问题相关的数据表和查询字段。不过在指令构建上论文认为在编写指令时简洁的文本格式(clear layout)以及不引入不相关的表结构(clear context)会降低模型理解难度对模型效果有很大提升。下面我们分别看下这两个部分 2.1 Clear Prompting Clear Prompting (CP) 组件的目标是为文本到SQL解析提供有效的prompt。它包括两个部分clear layout and clear context 类型 1复杂布局这种提示布局直接将说明、问题和上下文数据库模式直接连接在一起显得混乱不堪。 类型 2清晰布局这种布局通过采用清晰的符号将说明、上下文数据库模式和问题分开看起来清晰明了。 2.1.1 Clear Layout 后面的SQL-Palm也进行了类似的消融实验对比符合人类自然语言描述的Table Schema使用符号表征的prompt效果显著更好在执行准确率上有7%左右的提升。 2.1.2 Clear Context 把整个数据库的全部表结构放入schema linking Context一方面增加了推理长度一方面会使得模型有更大概率定位到无关的查询字段。因此C3通过以下两步先召回相关的数据表和表字段再进行schema linking 数据表召回 C3使用以下zero-shot指令让大模型基于数据表schema召回问题相关的数据表。这一步作者采用了self-consistency来投票得到概率最高的Top4数据表。当前的一些开源方案例如ChatSQL等也有采用相似度召回的方案更适合低延时面向超大数据库的场景。不过需要先人工先对每张表生成一段表描述描述该表是用来干啥的然后通过QueryDescription的Embedding相似度来筛选TopK数据表。 首先表格应基于其与问题的相关性进行排名。 其次模型应检查是否考虑了所有表格。 最后输出格式被规定为一个列表 为确保Table Recall的稳定性我们采用了一种self-consistency。具体而言模型生成了十组检索结果每组包含前四个表格。最终的结果由在这十组中出现最频繁的一组确定。 instruction Given the database schema and question, perform the following actions: 1 - Rank all the tables based on the possibility of being used in the SQL according to the question from the most relevant to the least relevant, Table or its column that matches more with the question words is highly relevant and must be placed ahead. 2 - Check whether you consider all the tables. 3 - Output a list object in the order of step 2, Your output should contain all the tables. The format should be like: [table_1, table_2, …]表字段召回 在以上得到问题相关的数据表之后会继续执行表字段召回的操作同样使用了Self-Consistency多路推理投票得到概率最高的Top5字段。这一步同样可以使用相似度召回尤其在中文场景以及垂直领域的数据表场景直接使用字段名并不足够也需要对表字段名称生成对应的描述然后使用相似度进行召回。 首先基于它们与问题的相关性对每个候选表格内的所有列进行排名。 然后输出格式被规定为一个字典。
   instruction Given the database tables and question, perform the following actions: 1 - Rank the columns in each table based on the possibility of being used in the SQL, Column that matches more with the question words or the foreign key is highly relevant and must be placed ahead. You should output them in the order of the most relevant to the least relevant.Explain why you choose each column.2 - Output a JSON object that contains all the columns in each table according to your explanation. The format should be like: {table_1: [column_1, column_2, ……], table_2: [column_1, column_2, ……],table_3: [column_1, column_2, ……],…… } 在提示中我们还强调了与问题词或外键更匹配的列应该放在前面以协助更准确的检索结果。同样我们采用了self-consistency。具体而言对于每个表格我们一次生成十组检索到的列。然后我们选择在每组中出现最频繁的五列作为最终结果。除了被检索到的表格和列之外我们还将被检索到的表格的外键信息添加到上下文部分以指定join操作所需的列。 2.2 self-consistency Schema Linking之后c3没有像DIN一样去判断问题的难度而是用统一的zero-Prompt来对所有问题进行推理。不过在推理部分引入了Self-Consistency的多路投票方案。 针对每个问题会随机生成多个SQL然后去数据库进行执行过滤无法执行的sql对剩余sql的执行结果进行分组从答案出现次数最多的分组随机选一个sql作为最终的答案也就是基于sql执行结果的major vote方案。效果上c3在spider数据集上使用干净简洁的zero-shot-promptself-consistency基本打平了Few-shot的DIN-SQL 2.3 Calibration of Model Bias(模型校准) 通过分析生成的SQL查询中发生的错误我们发现其中一些错误是由ChatGPT固有的某些biases引起的。如图3所示ChatGPT倾向于提供额外的列和额外的执行结果。本文总结了它们为以下两种biases。 bias1ChatGPT在输出中倾向于保守通常选择与问题相关但不一定必需的列。此外我们发现在涉及数量的问题时这种倾向尤为明显。例如在图3左侧中的第一个问题中ChatGPT在SELECT子句中选择了Year和COUNT()。然而Spider数据集中的正确SQL仅选择了Year因为COUNT()仅用于排序目的。 bias2ChatGPT在编写SQL查询时倾向于使用LEFT JOIN、OR和IN但通常未能正确使用它们。这种偏见常常导致执行结果中出现额外的值。图3右侧中可以找到这种偏见的一些例子。 2.3.1 Calibration with Hints (CH)策略校准 为了校准这两个偏见我们提出了一种插件校准策略称为Calibration with Hints (CH)。CH通过使用包含历史对话的上下文提示将先验知识引入ChatGPT。在历史对话中我们最初将ChatGPT视为出色的SQL撰写者并引导它遵循我们提出的去偏提示。 提示1针对第一个偏见我们设计了一个提示引导ChatGPT仅选择必要的列。这个提示在图1的右上部分有图示。它强调在仅用于排序目的时不应在SELECT子句中包括诸如COUNT()之类的项目。 提示2针对第二个偏见我们设计了一个提示防止ChatGPT滥用SQL关键字。如图1右上部分所示我们直接要求ChatGPT避免使用LEFT JOIN、IN和OR而是使用JOIN和INTERSECT。我们还指示ChatGPT在适当时使用DISTINCT或LIMIT以避免重复的执行结果。
   2.4 Consistency Output 一致性输出 使用CP和CH方法ChatGPT能够生成更高质量的SQL。然而由于大型语言模型的固有随机性ChatGPT的输出是不稳定的。为了了解ChatGPT不确定性输出的影响我们分析了在不同提示下在30次独立实验中开发集上正确计数的分布如图4所示。在这个图中ChatGPT-SQL是文献中提出的方法Liu等2023此外CP和CP CH分别表示我们提出的Clear Prompt和Clear Prompt与Clear Hint方法的组合。无论使用哪种方法只有不到65%的SQL语句能够一致地被正确撰写。这意味着通过提高输出的一致性模型有很大潜力正确地撰写大多数查询。 Self-consistency的动机是在复杂的推理问题中存在多个不同的推理路径可以得出唯一正确的答案。它首先对多个不同的推理路径进行抽样然后选择最一致的答案显著提高输出的质量。Text-to-SQL问题类似于推理问题在其中有多种编写SQL查询的方式可以表示相同的含义如图5所示。因此我们实施了基于执行的自一致性。 具体而言我们首先对多个推理路径进行抽样生成多样化的SQL答案。然后在数据库上执行这些SQL查询并收集执行结果。在从所有结果中删除错误之后我们通过对这些执行结果应用投票机制确定最一致的SQL作为最终SQL。例如在图5中我们根据执行结果对SQL查询进行分类并用不同的颜色表示它们。然后我们比较这些类别确定哪个类别包含更多的SQL查询并从该类别中选择一个SQL作为最终SQL。这种方法使我们能够利用从这些多个路径中得出的集体知识在生成SQL查询时产生更可靠的结果。 2.5 最终Prompt 样例 当然从工程化角度看调用了太多模型会导致性能偏低 3.DIAL-SQL 2023.11.20 论文链接https://arxiv.org/pdf/2308.15363.pdf 大型语言模型LLMs已成为Text-to-SQL任务的一种新范式。然而缺乏系统性的基准限制了设计有效、高效和经济的以大型语言模型为基础的 Text-to-SQL 解决方案的发展。为了应对这一挑战本文首先对现有的提示工程方法进行了系统和广泛的比较包括问题表示、示例选择和示例组织并通过这些实验结果阐述了它们的优缺点。基于这些发现我们提出了一种新的综合解决方案名为 DAIL-SQL它在 Spider 排行榜上以 86.6% 的执行准确性刷新了纪录树立了新的标杆。为了挖掘开源大规模语言模型的潜力我们在各种场景中探讨它们的表现并通过有监督的微调进一步优化它们的性能。我们的研究揭示了开源大规模语言模型在Text-to-SQL 领域的潜力以及有监督微调的优缺点。此外为了实现高效且经济的大规模语言模型为基础的Text-to-SQL解决方案我们强调了提示工程中的token效率并以此为准则比较了先前的研究。我们希望我们的工作能加深对大规模语言模型中Text-to-SQL 的理解并激发进一步的研究和广泛的应用。 3.1 研究方法 3.1.1 基础方法 • Basic Prompt ( B S P \mathrm BS_P BSP​). Basic Prompt [31] is a simple representation shown in Listing 1. It is consisted of table schemas, natural language question prefixed by “Q: ” and a response prefix “A: SELECT” to prompt LLM to generate SQL. In this paper we named it as Basic Prompt due to its absence of instructions. 基本提示 ( B S P \mathrm BS_P BSP​)。基本提示 [31] 是一个简单的表示如 Listing 1 所示。它由表模式、前缀为 “Q:” 的自然语言问题和提示 LLM 生成 SQL 的响应前缀 “a:SELECT” 组成。在本文中由于它没有指令我们将其命名为基本提示。 文本表示法提示 ( T R P \mathrm TR_P TRP​)。如 Listing 2 所示文本表示提示 [25] 表示自然语言中的模式和问题。与基本提示相比它在提示的最开始就添加了指导 LLM 的指令。在 [25] 中在零样本场景中它在 Spider-dev 上实现了 69.0% 的执行准确率。 OpenAI 演示提示 ( O D P \mathrm OD_P ODP​)。OpenAI 演示提示Listing 3首次在 OpenAI 的官方文本到 SQL 演示 [28] 中使用并在 [2231] 中进行了评估。它由指令、表模式和问题组成其中所有信息都用磅号 “#” 进行注释。与文本表示提示相比OpenAI 演示提示中的指令更具体有一条规则“仅完成 sqlite SQL 查询无需解释”我们将在第 4.3 节中进一步讨论并结合实验结果。 代码表示提示 C R P \mathrm CR_P CRP​。代码表示提示 [525] 以 SQL 语法表示文本到 SQL 任务。具体来说如 Listing 4 所示它直接呈现“CREATTABLE”SQL并在注释中用自然语言问题提示 LLM。与其他表示相比 C R P \mathrm CR_P CRP​它之所以引人注目是因为它能够提供创建数据库所需的全面信息例如列类型和主键 / 外键。有了这样的表示[25] 使用 LLM CODE-DAVINCI-002 正确预测了约 75.6% 的 SQL。 Alpaca SFT 提示 ( A S P \mathrm AS_P ASP​)。Alpaca SFT 提示是一种用于监督微调的提示 [38]。如 Listing 5 所示它提示 LLM 按照指示并根据 Markdown 格式的输入上下文完成任务。我们将其包括在内以检查其在即时工程和监督微调场景中的有效性和效率。 如表 1 所示不同的表示用不同的 LLM 进行实验并集成在不同的框架中这使得很难公平有效地进行比较。此外外国关键信息和规则含义等个别组成部分所扮演的具体角色仍不清楚。因此有必要进行系统的研究以更好地理解问题表征并通过公平的比较来考察它们的优缺点。 3.2 Text-to-SQL 的上下文学习 3.2.1 示例选择 我们先总结一下先前研究中各种示例选择策略如下。 随机选择。此策略随机采样 可用候选人的示例。先前的工作 [112425] 已经将其作为示例选择的基线。 问题相似性选择QTS。QTS [24] 选择与目标问题最相似的个示例。具体来说它使用预训练的语言模型将示例问题 Q 和目标问题嵌入在一起。然后它对每个示例 - 目标对应用预定义的距离度量如欧氏距离或负余弦相似度。最后利用近邻KNN算法从 Q 中选择个与目标问题相近的示例。 遮蔽问题相似性选择MQS 。对于跨领域文本到 SQLMQS [11] 通过使用掩码标记替换所有问题中的表名、列名和值消除了领域特定信息的负面影响然后使用最近邻算法计算其嵌入的相似性。 查询相似性选择 (QRS )。与使用目标问题相比QRS [25] 不使用目标问题 而是旨在选择与目标 SQL 查询 ∗ 相似的个示例。具体来说它使用初步模型根据目标问题和数据库生成 SQL 查询′其中这个生成的 ′ 可以视为对 ∗ 的近似。然后它根据关键词将示例中的查询编码为二进制离散语法向量。然后通过考虑与近似查询 ′ 的相似性和所选示例之间的多样性选择了个示例。 上述策略重点是仅使用目标问题或查询来选择示例。然而上下文学习本质上是通过类比进行学习。在文本到 SQL 的情况下目标是生成与给定问题匹配的查询因此大型语言模型应该学习从问题到 SQL 查询的映射。因此我们指出在示例选择过程中考虑问题和 SQL 查询可能有助 Text2SQL 任务。 3.2.2 示例组织 示例组织在决定上述选定示例的哪些信息将被组织到提示中方面发挥了关键作用。我们将先前研究中的现有策略总结为两个类别即 Full-Information Organization 和 SQL-Only Organization如 Listing 6 和 Listing7 所示。在这些示例中 D A T A B A S E S C H E M A 表示数据库模式 {DATABASE_SCHEMA} 表示数据库模式 DATABASES​CHEMA表示数据库模式{TARGET_QUESTION} 代表清单 4 中的问题表示。 Full-Information Organization 完整信息组织 F I O FI_O FIO​ F I O FI_O FIO​ [5, 25] 将示例组织成与目标问题相同的表示形式。如 listing 6 所示示例的结构与目标问题完全相同唯一的区别是选定的示例在 “SELECT” 后有相应的 SQL 查询而不是在最后有 “SELECT” 标记。 SQL-Only Organization 仅 SQL 组织 S O O SO_O SOO​ S O O SO_O SOO​在提示中包括选定示例的仅 SQL 查询并在前缀中附加指示如 listing 7 所示。这种组织旨在最大程度地利用有限的令牌长度来包括示例数量。然而它去除了问题和相应 SQL 查询之间的映射信息而这些信息可能很有用我们将在后面加以证明。
   3.3 DAIL-SQL 为了解决示例选择和组织中的上述问题在本小节中我们提出了一种新的文本到 SQL 方法名为 DAIL-SQL。 对于示例选择受到 MQS 和 QRS 的启发我们提出了 DAIL 选择DAIL 考虑了问题和查询来选择候选示例。具体来说DAIL 选择首先屏蔽了目标问题和候选集 Q 中的示例问题中的领域特定词。然后它根据屏蔽的 和的嵌入之间的欧几里得距离对候选示例进行排名。同时它计算了预测的 SQL 查询 ′ 和 Q 中的之间的查询相似度。最后选择标准通过问题相似度对排序后的候选示例进行优先排序同时其中查询相似度大于预定义的阈值。通过这种方式选择的前个示例在问题和查询上都具有很好的相似性。 为了保留问题和 SQL 查询之间的映射信息并提高令牌效率我们提出了一种新的示例组织策略DAIL 组织DAIL 以在质量和数量方面进行权衡。具体来说DAIL 呈现了示例的问题和相应的 SQL 查询 如 listing 8 所示。作为 FI 和 SO 之间的折中DAIL 保留了 question-SQL 映射并通过去除具有 token 成本的数据库模式来减少示例的 token 长度。 在 DAIL-SQL 中我们采用 CR 作为问题表示形式。原因是与其他表示形式相比CR 包含了数据库的全部信息包括主键和外键这可能会为 LLMs 提供更多有用的信息例如用于 “JOIN” 子句预测的外键。此外在广泛的编码语料库上进行预训练LLMs 可以更好地理解 CR 中的提示而无需太多额外的工作。 总之DAIL-SQL 使用 CR 作为问题表示根据问题和查询的信息选择示例并组织它们以保持问题到 SQL 的映射。在这种提示设计中LLM 可以更好地应对 Text-to-SQL 任务而在 Spider 排行榜中提出的 DAIL-SQL 通过 86.2% 的执行准确性刷新了性能。 3.4 Text-to-SQL 的监督微调 为了在 zero-shot 场景中提高 LLM 的性能现有的文本到 SQL 方法普遍采用的策略是上下文学习这在上述小节中有讨论。作为一种替代但富有前景的选项监督微调至今还鲜有探讨。与各种语言任务的监督微调类似我们也可以将其应用于文本到 SQL 领域以提高 LLM 在这个下游任务的性能。为了进一步了解监督微调如何应用于文本到 SQL我们首先简要介绍一下如下形式。 对于 Text-to-SQL 任务考虑一个大型语言模型 M \mathcal M M以及一组 Text-to-SQL 的训练数据 T { ( q i , s i , D i ) } \mathcal T {(q_i, s_i, \mathcal D_i)} T{(qi​,si​,Di​)}其中和分别是自然语言问题和其在数据库 D i \mathcal D_i Di​上的相应查询监督微调的目标是最小化以下损失 其中 L \mathcal L L 是用来衡量生成的查询与真实查询之间差异的损失函数。与问题表示一样 确定了具有来自数据库 D \mathcal D D 的有用信息的问题表示。在这个定义中文本到 SQL 的监督微调包括两个子任务包括使用监督数据 T \mathcal T T 微调给定的 LLM M \mathcal M M以获得最佳的 M ∗ \mathcal M^ M∗以及寻找最佳的问题表示 。由于问题表示 已经讨论过因此本节将主要集中在数据准备 T \mathcal T T 和微调上。 对于通用领域监督数据 T { ( p i , r i ) } \mathcal T {(p_i, r_i)} T{(pi​,ri​)} 中的每个项目包含一个输入提示 和来自 LLM 的期望响应。为了确保与推理过程的一致性我们使用监督微调并从给定的文本到 SQL 数据集生成提示 - 响应对。具体来说给定一个文本到 SQL 数据集 T { ( q i , s i , D i ) } \mathcal T {(q_i, s_i,\mathcal D_i)} T{(qi​,si​,Di​)} 我们使用生成的微调数据通过使用目标问题和给定的数据库作为提示来微调 LLM将 LLM 的期望查询视为响应即 T { ( p i σ ( q i , D i ) , r i s i ) } \mathcal T {(p_i \sigma(q_i,\mathcal D_i), r_i s_i)} T{(pi​σ(qi​,Di​),ri​si​)}。一旦数据准备就绪我们可以根据可用的计算资源使用现有的工具包通过全面微调 [29] 或参数高效微调 [13] 来调整给定的 LLM M \mathcal M M。微调完成后优化的 LLM M ∗ \mathcal M^* M∗ 可以用于进行推理即要求它通过自然语言问题生成查询。请注意我们在微调和推理过程中使用相同的问题表示 。我们将进行一系列实验讨论监督微调在 Text-to-SQL 领域的巨大潜力。 更多请参考论文原文 3. SQL-PaLM V4–2024.03.30 [V1 2023.3.26] SQL-PaLM: Improved large language model adaptation for Text-to-SQL (extended) 论文链接https://arxiv.org/abs/2306.00739 [v1] Fri, 26 May 2023 21:39:05 UTC (315 KB)[v2] Wed, 7 Jun 2023 07:23:56 UTC (389 KB)[v3] Sun, 25 Jun 2023 06:44:48 UTC (389 KB)[v4] Sat, 30 Mar 2024 17:22:44 UTC (1,204 KB) 文本到SQL将自然语言翻译成结构化查询语言(SQL)的过程代表了大型语言模型(LLMs)的变革性应用有可能彻底改变人类与数据的交互方式。本文介绍了SQL-PaLM框架这是一个使用LLMs理解和增强文本到SQL的综合解决方案用于少样本提示和指令微调的学习体制。通过少样本提示我们探索了基于执行错误过滤的一致性解码的有效性。通过指令微调我们深入了解了影响调优LLMs性能的关键范式。特别是我们研究了如何通过扩大训练数据覆盖率和多样性、合成数据增强和集成特定查询的数据库内容来提高性能。我们提出了一种测试时间选择方法通过以执行反馈为指导集成来自多个范式的SQL输出进一步提高准确性。此外本文还解决了导航具有大量表和列的复杂数据库的实际挑战提出了准确选择相关数据库元素以增强文本到SQL性能的有效技术。我们的整体方法在文本到SQL方面取得了实质性的进展这在两个关键的公共基准测试Spider和BIRD上得到了证明。通过全面的消融和错误分析我们揭示了框架的优势和弱点为文本到SQL未来的工作提供了有价值的见解。 推荐参考☆☆NL2SQL进阶系列(5)论文解读业界前沿方案DIN-SQL、C3-SQL、DAIL-SQL、新一代数据集BIRD-SQL解读 和以上两种方案不同的是SQL-Palm没有进行问题拆解而是直接基于few-shot prompt进行sql的推理生成并且尝试了微调方案微调后的模型会显著超越DIN-SQL。 指令构建和以上的C3有两点相似 Self-consistency: 同样使用了基于执行结果的多路投票来选择sqlclean prompt同样实验了偏向于人类自然表达的表结构表述和符号化的简洁表结构描述结论和以上C3相同。在有few-shot样本时指令长啥样影响都不大在zero-shot指令下符号化的简洁表结构描述效果显著更好。对比如下上图是符号化表结构下图是自然语言式的表结构描述 例子 4.BIRD-SQL 论文https://arxiv.org/abs/2305.03111主页https://bird-bench.github.io代码https://github.com/AlibabaResearch/DAMO-ConvAI/tree/main/bird 这是一篇 text2sql 领域比较新的文章23 年 5 月发布由多位作者联合创作一作是港大二作是阿里达摩院还有来自其他多位大学的作者作者们既有学校也有公司相信他们的研究是可以促进学界与工业界的。 text2sql 这是近年来备受关注的领域尤其是Codex和ChatGPT在这个任务上展示了令人印象深刻的结果。但是大多数流行的基准测试如Spider(https://github.com/taoyds/spider)和WikiSQL(GitHub - salesforce/WikiSQL: A large annotated semantic parsing corpus for developing natural language interfaces.)主要关注的是具有少量数据库内容行的数据库模式这使得学术研究与实际应用之间存在差距。为了缩小这个差距作者们提出了BIRDa BIg Bench for LaRge-Scale Database这是一个大规模数据库中基于文本到SQL任务的大型基准测试包含了12,751 个SQL样本和95个数据库总大小为33.4 GB涵盖了37个专业领域。这个基准测试强调了数据库值的新挑战包括脏数据库内容、自然语言问题和数据库内容之间的外部知识以及在大型数据库环境下的SQL效率。为了解决这些问题text2sql 模型除了语义解析之外还必须具备数据库中对数据的理解能力。实验结果表明对于大型数据库数据库的值在生成准确的SQL中也是非常重要的。当下即使是最强模型如ChatGPT其执行准确率也只有40.08%远低于人类的92.96%这说明了仍然存在挑战。此外他们还做了效率分析以提供 text2sql 的深入见解这对于工业界是有益的。我们相信BIRD将有助于推动 text2sql 的实际应用。 该研究主要面向真实数据库的 Text-to-SQL 评估过去流行的测试基准比如 Spider 和 WikiSQL仅关注具有少量数据库内容的数据库 schema导致学术研究与实际应用之间存在鸿沟。BIRD 重点关注海量且真实的数据库内容、自然语言问题与数据库内容之间的外部知识推理以及在处理大型数据库时 SQL 的效率等新三个挑战。 首先数据库包含海量且嘈杂数据的值。在左侧示例中平均工资的计算需要通过将数据库中的字符串String转化为浮点值 (Float) 之后再进行聚合计算Aggregation其次外部知识推断是很必要的在中间示例中为了能准确地为用户返回答案模型必须先知道有贷款资格的账户类型一定是 “拥有者”“OWNER”这代表巨大的数据库内容背后隐藏的奥秘有时需要外部知识和推理来揭示最后需要考虑查询执行效率。在右侧示例中采用更高效的 SQL 查询可以显著提高速度这对于工业界来讲具有很大价值因为用户不仅期待写出正确的 SQL还期待 SQL 执行的高效尤其是在大型数据库的情况下 4.1数据标注 BIRD 在标注的过程中解耦了问题生成和 SQL 标注。同时加入专家来撰写数据库描述文件以此帮助问题和 SQL 标注人员更好的理解数据库。 数据库采集作者从开源数据平台如 Kaggle 和 CTU Prague Relational Learning Repository收集并处理了 80 个数据库。通过收集真实表格数据、构建 ER 图以及设置数据库约束等手动创建了 15 个数据库作为黑盒测试来避免当前数据库被当前的大模型学习过。BIRD 的数据库包含了多个领域的模式和值 37 个领域涵盖区块链、体育、医疗、游戏等。问题收集首先作者雇佣专家先为数据库撰写描述文件该描述文件包括完整的表明列名、数据库值的描述以及理解值所用到的外部知识等。然后招募了 11 个来自美国英国加拿大新加坡等国家的 native speaker 为 BIRD 产生问题。每一位 speaker 都至少具备本科及以上的学历。SQL 生成面向全球招募了由数据工程师和数据库课程学生组成的标注团队为 BIRD 生成 SQL。在给定数据库和参考数据库描述文件的情况下标注人员需生成 SQL 以正确回答问题。采用双盲Double-Blind标注方法要求两位标注人员对同一个问题进行标注。双盲标注可以最大程度减少单一标注人员所带来的错误。质量检测质量检测分为结果执行的有效性和一致性两部分。有效性不仅要求执行的正确性还要求执行结果不能是空值NULL。专家将逐步修改问题条件直至 SQL 执行结果有效。难度划分text-to-SQL 的难度指标可以为研究人员提供优化算法的参考。Text-to-SQL 的难度不仅取决于 SQL 的复杂程度还与问题难度、额外知识易理解程度以及数据库复杂程度等因素有关。因此作者要求 SQL 标注人员在标注过程中对难易程度进行评分并将难度分为三类简单、适中和具有挑战性。 4.2 数据统计 问题类型统计问题分为两大类基础问题类型Fundamental Type和推理问题类型Reasoning Type。基础问题类型包括传统 Text-to-SQL 数据集中涵盖的问题类型而推理问题类型则包括需要外部知识来理解值的问题 数据库分布作者用 sunburst 图显示了数据库 domain 及其数据量大小之间的关系。越大的半径意味着基于该数据库的 text-SQL 较多反之亦然。越深的颜色则是指该数据库 size 越大比如 donor 是该 benchmark 中最大的数据库所占空间: 4.5GB。 SQL 分布作者通过 SQL 的 token 数量关键词数量n-gram 类型数量JOIN 的数量等 4 个维度来证明 BIRD 的 SQL 是迄今为止最多样最复杂的。 评价指标 执行准确率对比模型预测的 SQL 执行结果与真实标注 SQL 执行结果的差异有效效率分数同时考虑 SQL 的准确性与高效性对比模型预测的 SQL 执行速度与真实标注 SQL 执行速度的相对差异将运行时间视为效率的主要指标。 4.3 实验分析 作者选择了在之前基准测试中表现突出的训练式 T5 模型和大型语言模型LLM作为基线模型Codexcode-davinci-002和 ChatGPTgpt-3.5-turbo。为了更好地理解多步推理是否能激发大型语言模型在真实数据库环境下的推理能力还提供了它们的思考链版本Chain-of-Thought。并在两种设置下测试基线模型一种是完全的 schema 信息输入另一种是人类对涉及问题的数据库值的理解总结成自然语言描述knowledge evidence辅助模型理解数据库。 作者给出了一些结论 额外知识的增益增加对数据库值理解的知识knowledge evidence有明显的效果提升这证明在真实的数据库场景中仅依赖语义解析能力是不够的对数据库值的理解会帮助用户更准确地找到答案。思维链不一定完全有益在模型没有给定数据库值描述和零样本zero-shot情况下模型自身的 COT 推理可以更准确地生成答案。然而当给定额外的知识knowledge evidence后让 LLM 进行 COT发现效果并不显著甚至会下降。因此在这个场景中 LLM 可能会产生知识冲突。如何解决这种冲突使模型既能接受外部知识又能从自身强大的多步推理中受益将是未来重点的研究方向。与人类的差距BIRD 还提供了人类指标作者以考试的形式测试标注人员在第一次面对测试集的表现并将其作为人类指标的依据。实验发现目前最好的 LLM 距离人类仍有较大的差距证明挑战仍然存在。作者执行了详细的错误分析给未来的研究提供了一些潜在的方向。 5. 更多前沿论文推荐 序号类型标题1MainBenchmarking and Improving Text-to-SQL Generation under Ambiguity2MainEvaluating Cross-Domain Text-to-SQL Models and Benchmarks3MainExploring Chain of Thought Style Prompting for Text-to-SQL4MainInteractive Text-to-SQL Generation via Editable Step-by-Step Explanations5MainNon-Programmers Can Label Programs Indirectly via Active Examples: A Case Study with Text-to-SQL6FindingsBattle of the Large Language Models: Dolly vs LLaMA vs Vicuna vs Guanaco vs Bard vs ChatGPT - A Text-to-SQL Parsing Comparison7FindingsEnhancing Few-shot Text-to-SQL Capabilities of Large Language Models: A Study on Prompt Design Strategies8FindingsError Detection for Text-to-SQL Semantic Parsing9FindingsReFSQL: A Retrieval-Augmentation Framework for Text-to-SQL Generation10FindingsSelective Demonstrations for Cross-domain Text-to-SQL11FindingsSemantic Decomposition of Question and SQL for Text-to-SQL Parsing12FindingsSQLPrompt: In-Context Text-to-SQL with Minimal Labeled Data 正会论文Main Conference 中稿的这 5 篇正会论文来看主要还是围绕着 Text-to-SQL 的评测、实际系统交互和 LLM 在 Text-to-SQL 任务的应用为主。 5.1 Benchmarking and Improving Text-to-SQL Generation under Ambiguity -2023.10.20 链接https://arxiv.org/pdf/2310.13659v1.pdf摘要在文本到 SQL 转换的研究中大多数基准测试都是针对每个文本查询对应一个正确的 SQL 的数据集。然而现实生活中的数据库上的自然语言查询经常由于模式名称的重叠和多个令人困惑的关系路径而涉及对预期 SQL 的显著歧义。为了弥合这一差距我们开发了一个名为 AmbiQT 的新基准其中包含超过 3000 个示例每个文本都可以由于词汇和 / 或结构上的歧义而被解释为两个合理的 SQL。 面对歧义时理想的 top-k 解码器应该生成所有有效的解释以便用户可能的消歧Elgohary 等2021 年Zhong 等2022 年。我们评估了几个文本到 SQL 系统和解码算法包括那些使用最先进的大型语言模型LLMs的系统发现它们距离这一理想还很远。主要原因是流行的束搜索算法及其变体将 SQL 查询视为字符串并在 top-k 中产生无益的令牌级别多样性。 我们提出了一种名为 LogicalBeam 的新解码算法该算法使用基于计划的模板生成和受限填充的混合方法来导航 SQL 逻辑空间。逆向生成的计划使模板多样化而仅在模式名称上分支的束搜索填充提供了值多样性。LogicalBeam 在生成 top-k 排名输出中的所有候选 SQL 方面比最先进的模型高出 2.5 倍的效果。它还提高了 SPIDER 和 Kaggle DBQA 上的前 5 名精确匹配和执行匹配准确率。 要点主要关注于自然语言到 SQL 转换时的歧义现象作者先是自己设计了一个评测基准 AmbiQT然后针对性设计了一种 LogicalBeam 的新解码算法改善原有的 beam-search 带来的 token-level 的 beam 差异。 5.2 Evaluating Cross-Domain Text-to-SQL Models and Benchmarks–2023.10.27 链接https://arxiv.org/pdf/2310.18538v1.pdf摘要文本到 SQL 的基准测试在评估该领域的进展和不同模型的排名方面起着关键作用。然而由于各种原因比如自然语言查询的不明确、模型生成的查询和参考查询中固有的假设、以及在某些条件下 SQL 输出的非确定性特性导致基准测试中模型生成的 SQL 查询与参考 SQL 查询的准确匹配失败。在本文中我们对几个著名的跨领域文本到 SQL 基准测试进行了广泛的研究并对这些基准测试中表现最佳的一些模型进行了重新评估包括手动评估 SQL 查询和用等效表达式重写它们。我们的评估揭示由于可以从提供的样本中得出多种解释所以在这些基准测试中达到完美表现是不可行的。此外我们发现这些模型的真实性能被低估了而且在重新评估后它们的相对性能发生了变化。最值得注意的是我们的评估揭示了一个令人惊讶的发现在我们的人类评估中一种基于最新 GPT4 模型的模型超越了 Spider 基准测试中的金标准参考查询。这一发现突显了谨慎解读基准测试评估的重要性同时也认识到进行额外独立评估在推动该领域进步中的关键作用。 要点主要讨论了现有 Text-to-SQL 评测基准中存在的语言不明确、数据值不明确等导致的评估标准失真的现象作者对部分存在上述问题的 Question-SQL Pair 进行重写后对现有的一些 SOTA 模型进行了再评估。 5.3 Exploring Chain of Thought Style Prompting for Text-to-SQL 2023.10.27 链接https://arxiv.org/abs/2305.14215摘要使用大型语言模型LLMs进行上下文学习由于在各种任务上的卓越的少样本表现近来引起了越来越多的关注。然而其在文本到 SQL 解析上的表现仍有很大的提升空间。在本文中我们假设改善 LLMs 在文本到 SQL 解析上的一个关键方面是其多步推理能力。因此我们系统地研究了如何通过思维链CoT风格的提示来增强 LLMs 的推理能力包括原始的思维链提示Wei 等2022b和最少到最多提示Zhou 等2023。我们的实验表明像 Zhou 等2023中的迭代提示可能对文本到 SQL 解析来说并不必要而使用详细的推理步骤往往会有更多的错误传播问题。基于这些发现我们提出了一种新的 CoT 风格的提示方法用于文本到 SQL 解析。与不带推理步骤的标准提示方法相比它在 Spider 开发集和 Spider 真实集上分别带来了 5.2 和 6.5 点的绝对提升与最少到最多提示方法相比分别带来了 2.4 和 1.5 点的绝对提升。要点本文探索了应用 LLM 解决 Text-to-SQL 任务时的 Prompt Engineering。作者设计了一种 “问题分解” 的 Prompt 格式并结合每个子问题中的表列名进行融合实现了与 RASATPICARD 模型相当的表现。 笔记Text-to-SQL 任务中的思维链Chain-of-thought探索 5.4 Non-Programmers Can Label Programs Indirectly via Active Examples: A Case Study with Text-to-SQL –2023.10.23 链接https://arxiv.org/abs/2205.12422摘要非程序员能否通过自然语言标注来间接地表示其含义的复杂程序我们介绍了 APEL 框架其中非程序员通过选择由种子语义解析器例如 Codex生成的候选程序来进行标注。由于他们无法理解这些候选程序我们要求他们通过检查程序的输入输出示例来间接选择。对于每个表达APEL 会主动搜索一个简单的输入在此输入上候选程序倾向于产生不同的输出。然后我们仅要求非程序员选择合适的输出从而推断出哪个程序是正确的并可以用来微调解析器。作为一个案例研究我们招募了非程序员人类使用 APEL 重新标注 SPIDER一个文本到 SQL 数据集。我们的方法达到了与原始专家标注者相同的标注准确率75%并揭露了原始标注中的许多微妙错误。 要点本文提出了 APEL 框架使非程序员能通过选择候选程序的示例输出来注释文本到 SQL 的语义。这一方法在文本到 SQL 数据集 SPIDER 上达到了与专家相当的注释准确性并揭示了原始注释中的一些错误。 5.5 Interactive Text-to-SQL Generation via Editable Step-by-Step Explanations 链接https://arxiv.org/abs/2305.07372摘要关系数据库在这个大数据时代扮演着重要角色。然而对于非专家来说由于他们不熟悉 SQL 等数据库语言充分释放关系数据库的分析能力是具有挑战性的。虽然已经提出了许多技术来自动从自然语言生成 SQL但它们存在两个问题1特别是对于复杂查询它们仍然会犯许多错误2它们没有为非专家用户提供一种灵活的方式来验证和修正错误的查询。为了解决这些问题我们引入了一种新的交互机制允许用户直接编辑不正确的 SQL 的逐步解释来修复 SQL 错误。在 Spider 基准测试上的实验表明我们的方法在执行准确性方面至少比三种最先进的方法高出 31.6%。另外一项包括 24 名参与者的用户研究进一步表明我们的方法帮助用户在更少的时间内以更高的信心解决了更多的 SQL 任务展示了其拓宽数据库访问特别是对于非专家的潜力。 要点提出了一个名为 STEPS 的交互式文本到 SQL 系统允许用户通过直接编辑逐步解释来修正错误的 SQL 查询。Spider 上实验显示STEPS 在提高任务完成速度、准确性和用户自信度方面相比现有方法有显著优势。 参考链接 https://zhuanlan.zhihu.com/p/685628406 https://zhuanlan.zhihu.com/p/685790327 论文阅读DIN-SQL: Decomposed In-Context Learning of Text-to-SQL withSelf-Correctionhttps://blog.csdn.net/qq_42681787/article/details/132420526 【论文阅读】《Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluationhttps://blog.csdn.net/weixin_45606499/article/details/133905621 DAIL-SQLLLM在Text-to-SQL任务中的详细评估 https://zhuanlan.zhihu.com/p/685347478