Text-to-SQL模型可以将自然语言（NL）问题解析为可执行的SQL查询，越来越多地应用于实际应用中。然而，在实际应用中部署这些模型通常需要针对特定应用使用的高度专业化的数据库模式进行调整。我们发现，现有的Text-to-SQL模型在应用于新模式时性能显著下降，主要原因是缺乏用于微调的领域特定数据。这种数据稀缺也限制了在新领域有效评估模型性能的能力。在实际场景中，持续获得高质量的Text-to-SQL数据以适应不断变化的模式成本极高。为了解决这一问题，我们提出了 SQLsynth ，这是一个基于人类参与的Text-to-SQL数据标注系统。 SQLsynth 通过结构化的工作流程，利用人机协作简化高质量Text-to-SQL数据集的创建。一项对比 SQLsynth 与手动标注和ChatGPT的受试者内用户研究显示， SQLsynth 显著加速了Text-to-SQL数据标注过程，减少了认知负荷，并生成了更准确、自然和多样的数据集。我们的代码可在 https://github.com/adobe/nl_sql_analyzer 获取。
自然语言接口可以显著简化复杂数据分析和决策过程，使最终用户能够通过自然语言表达其意图。这些接口主要由Text-to-SQL模型驱动，将自然语言问题转换为SQL查询 。生成的SQL查询然后在数据库上执行以检索结果。最近的进展，特别是在大型语言模型（LLMs）方面，显著增强了自然语言接口，并开辟了一个预计将在五年内增长三倍的市场 。
尽管取得了这些进展，Text-to-SQL模型在实际应用中的准确性和可靠性仍然不理想，尤其是在金融和医疗等高风险领域，错误可能导致严重后果。一个导致不准确的根本原因是领域迁移，这是机器学习中的常见挑战 。具体来说，将自然语言接口应用于实际数据库需要底层Text-to-SQL模型理解该数据库模式，而公共数据集如Spider 和 BIRD 并未涵盖。我们对Adobe工程师的初步研究表明，对于新增列，Text-to-SQL准确性至少下降了13.3%，对于新表则下降了9.1%。此外，随着数据库模式的变化，Text-to-SQL模型的性能继续下降。为了充分释放Text-to-SQL模型在新领域的计算能力，需要在目标模式下注释足够的文本和SQL数据对以进行微调。
最近的研究表明，LLMs可以在图像字幕、代码生成和主题检测等领域用作数据标注员。虽然我们可以使用LLMs来标注Text-to-SQL数据集，但这引入了新的挑战，例如幻觉。此外，LLMs本质上不具备生成多样化数据的能力，经常生成重复的数据，并且由于长上下文中的有限注意力难以保持大型数据集的一致性 (Y. Tian 和 Zhang 2024; Beltagy, Peters, 和 Cohan 2020) 。因此，我们认为在整理Text-to-SQL数据集时结合人类知识并改善人类控制是至关重要的。据我们所知，之前没有工作研究过Text-to-SQL生成中的人机协作数据标注方法。
为了解决这一差距，我们提出了 SQLsynth , 一种用于创建定制模式下的高质量Text-to-SQL数据集的交互式Text-to-SQL数据标注系统。我们的见解是自动化劳动密集型程序（例如初始化SQL查询和自然语言问题），同时提供有效的错误检测和修复机制，使标注人员能够高效地验证和改进数据，与LLM协作。图 [fig:overview] 比较了传统Text-to-SQL标注与使用 SQLsynth 时的管道。传统上，给定一个数据库模式，标注人员必须理解模式架构并从头开始手动创建新的SQL查询和自然语言问题。这个过程往往精神负担重且容易产生偏差，因为个人假设可能会影响查询模式和措辞。
相比之下， SQLsynth 将数据库模式可视化为一个交互式的可编辑图，以便更好地理解。根据定制模式， SQLsynth 使用基于规则的方法填充数据库，生成大量多样化的记录。然后，它使用填充后的数据库通过概率上下文无关语法（PCFG）采样SQL查询。 SQLsynth 利用基于语法的方法和LLM逐步分析SQL查询。根据分析结果，它将SQL查询翻译成相应的自然语言问题。LLM通过逐步分析自动将自然语言问题与SQL查询对齐。基于这种对齐， SQLsynth 识别潜在错误，并允许标注人员通过结构化的工作流程指示LLM高效纠正这些问题。具体来说，标注人员可以注入缺失信息或删除自然语言问题中的冗余文本。最后， SQLsynth 分析标注数据，提供关于属性分布（例如当前数据集中特定引用实体的统计数据）的动态数据集组成。此功能使标注人员能够迭代监控和改进数据集的多样性和质量。
我们通过一项12名参与者的受试者内研究评估了 SQLsynth 。与手动标注和使用ChatGPT相比，使用 SQLsynth 的参与者标注了4.4倍和2.3倍更多的数据，分别减少了87%和84%的错误。我们使用Flesch-Kincaid分数和人工评分评估了标注数据的自然度。结果表明，由 SQLsynth 标注的自然语言问题比ChatGPT生成的问题更自然。为了评估数据集的多样性，我们分析了SQL查询中的子句、表、列和值的数量。结果显示 SQLsynth 实现了更高的辛普森多样性指数，表明整体多样性更好。此外，在标注过程中，参与者报告说使用 SQLsynth 时认知负荷较小，信心更大。
总之，这项工作做出了以下贡献：
- 一项 初步研究与工业从业者 确定了实践中Text-to-SQL标注的五大用户需求。
- 一个 全面的交互式Text-to-SQL标注系统 , SQLsynth , 简化了Text-to-SQL数据集的标注过程。它促进了数据库理解、数据库填充、Text-to-SQL数据生成、错误检测和修复以及数据集分析。
- 一项 全面的评估 评估了 SQLsynth 的可用性和有效性，证明了与手动标注和对话式AI助手（如ChatGPT）相比，标注速度、准确性、自然度和数据集多样性有显著提高。
2 相关工作
2.1 从自然语言生成SQL
自1970年代以来，开发数据库的自然语言接口一直是一个长期存在的问题。1972年，LUNAR (Woods, Kaplan, 和 Webber 1972) 被提出，使地质学家能够查询月球岩石的化学分析数据。早期的研究集中在基于逻辑 (Grosz 1983; Warren 和 Pereira 1982) 和基于规则 (Baik, Jagadish, 和 Li 2019; Yaghmazadeh 等 2017b; Saha 等 2016; Popescu 等 2004; F. Li 和 Jagadish 2014a) 的方法上。然而，这些方法需要大量的人工努力来创建翻译规则，并且仅限于一组确定的查询 (Kim 等 2020; Popescu 等 2004) 。
许多公开的Text-to-SQL数据集的出现 (Yu, Zhang, 等 2018; Zhong, Xiong, 和 Socher 2017a; Yaghmazadeh 等 2017b; J. Li 等 2023) 推动了研究人员开发基于学习的Text-to-SQL模型 (Rubin 和 Berant 2021; Y. Tian, Zhang, 等 2024; B. Wang 等 2020; Zhang 等 2019; Scholak, Schucher, 和 Bahdanau 2021; Hwang 等 2019) 。 早期的Text-to-SQL模型主要依赖编码器-解码器架构 (Lin, Socher, 和 Xiong 2020; Zhong 等 2020; Zhong, Xiong, 和 Socher 2017b) , 其中编码器将自然语言问题和数据库模式映射到潜在状态，解码器将潜在状态映射到SQL查询。最近，更多工作 (Yingqi Gao 等 2024; D. Gao 等 2023; Maamari 等 2024) 集中于利用大型语言模型（LLMs）。这些LLMs预训练于大型语料库，表现出一般性的语义解析能力。它们可以在零样本设置下或通过少量示例有效解决Text-to-SQL任务 (Thorpe, Duberstein, 和 Kinsey 2024; Gur 等 2018) 。与此同时，一些工作通过微调现有LLMs以实现更好的性能 (H. Li 等 2024; Rebei 2023; Wong 和 Srivastava 2023; Numbers Station Labs 2023) 。然而，这些方法针对的是通用的Text-to-SQL能力，可能在专业模式上表现不佳。 SQLsynth 通过即时获取特定模式下的Text-to-SQL数据集弥合了这一差距，从而促进有针对性的微调和评估。
2.2 Text-to-SQL数据集创建
2.2.1 人工标注的Text-to-SQL数据集
近年来出现了越来越多的Text-to-SQL数据集 (Hemphill, Godfrey, 和 Doddington 1990; Iyer 等 2017; Tang 和 Mooney 2000; Zelle 和 Mooney 1996; F. Li 和 Jagadish 2014b; Yaghmazadeh 等 2017a; Finegan-Dollak 等 2018; Zhong, Xiong, 和 Socher 2017a; Yu, Zhang, 等 2018; Gan 等 2021; Gan, Chen, 和 Purver 2021; L. Wang 等 2020; Lee, Polozov, 和 Richardson 2021; J. Li 等 2023) 。例如，WikiSQL (Zhong, Xiong, 和 Socher 2017a) 包含了来自24,241个维基百科表格的80,654个手动生成的问题和SQL查询。Spider (Yu, Zhang, 等 2018) 是一个跨域Text-to-SQL数据集，由11名大学生标注。它包含来自200个数据库的10,181个问题和5,693个SQL查询，涵盖了138个不同领域。另一个值得注意的数据集BIRD (J. Li 等 2023) 包含来自95个数据库的12,751个查询，覆盖了37个专业领域，由众包创建。
尽管这些数据集试图纳入现实世界的查询场景，但它们受到模式数量的限制。在实际应用中，不同的应用程序可能会使用显著不同的模式架构和查询流量，导致与现有数据集相比存在显著差异。此外，尽管每个数据集中包含数千个查询，但每个数据库的查询数量仍然不足，无法涵盖所有类型的查询，因为人工标注的成本很高。
2.2.2 Text-to-SQL数据增强与合成
与手动标注相比，已经有很多努力致力于自动化数据集构建过程。第一类研究集中在数据增强，即将现有数据集转换或扩展为新数据集 (Yu, Yasunaga, 等 2018; D. Wang 等 2024; Barzilay 和 McKeown 2001; Sennrich, Haddow, 和 Birch 2016; Q. Liu, Kusner, 和 Blunsom 2021; Longpre 等 2019) 。例如，SyntaxSQLNet (Yu, Yasunaga, 等 2018) 使用Spider数据集中的查询模板生成跨域数据。CONDA (D. Wang 等 2024) 通过对SParC (Yu, Zhang, Yasunaga, 等 2019) 和CoSQL (Yu, Zhang, Er, 等 2019) 中的SQL对话状态进行修改以生成不同的查询和问题。然而，这种数据增强局限于现有数据集，难以显著增加数据的多样性。
为了解决数据增强的多样性限制，第二类研究集中在基于SQL语法采样各种查询，然后将其翻译成自然语言问题 (D. Wang 等 2024; Guo 等 2018a) 。虽然基于语法的采样是可行的，但将SQL查询翻译回自然语言问题仍然是一个挑战。现有方法要么是基于模板 (Y. Tian, Zhang, 等 2024; Y. Tian, Kummerfeld, 等 2024; Kokkalis 等 2012; Koutrika, Simitsis, 和 Ioannidis 2010; K. Xu 等 2018; Narechania 等 2021; F. Li 和 Jagadish 2014c) 或基于模型 (Lian 等 2023; Guo 等 2018b; Wu 等 2022; B. Wang 等 2021) , 两者都有局限性。基于模板的方法根据预定义的模板将正式查询翻译成自然语言问题，这缺乏生成问题的多样性和自然度。基于模型的方法训练或使用预训练模型从正式查询生成自然语言问题。例如, (B. Wang 等 2021) 训练了一个基于BART的翻译模型，将SQL映射为自然语言问题 (M. Lewis 等 2020) 。然而，这些翻译模型可能会引入错误，使数据集不可靠。
最近的研究表明，LLMs可以作为有效的数据标注员 (Tan et al. 2024; He et al. 2024; Choi et al. 2024; Gilardi, Alizadeh, 和 Kubli 2023; Y. Wang 等 2023; Wei et al. 2024; C. Xu et al. 2023) 。虽然LLMs可以通过提示生成Text-to-SQL数据，但它们不适合从头生成大量多样的数据。
为了解决这些问题， SQLsynth 首先根据语法规则采样SQL查询，并使用LLM将其翻译成自然语言问题。为了处理潜在的翻译错误， SQLsynth 采用了一种人机协作的检查和修复方法。它检测并突出显示SQL查询和自然语言问题之间的任何潜在错位，供用户检查。然后，它允许用户通过与LLM协作注入缺失信息或删除冗余文本来高效修正这些问题。
2.3 交互式数据标注
虽然纯合成数据集不可靠，人工标注耗时且劳动密集。为了平衡这一点，交互式数据标注方法 (Benato et al. 2021; C. Huang et al. 2024; Klie et al. 2018a, 2018b; Le et al. 2021; Xiao et al. 2023; Y. Li et al. 2021) 被引入以减少标注工作量并保持标注质量。这些方法通常使用一个标注模型，为人工审查员提供建议以批准或更正。
与手动标注相比，交互式标注的优势在于标注人员只需验证模型生成的标注，而无需从头创建数据。这可以显著加速标注过程并减少人工工作量。交互式标注的一个常见策略是利用主动学习 (C. Huang et al. 2023; Casanova et al. 2020; Laws, Scheible, 和 Schütze 2011; Y. Li et al. 2021; Klie et al. 2018a) , 即战略性选择最有价值的数据点进行标注。这种方法旨在用最少的人工标注数据增量优化模型性能。然而，主动学习的一个主要局限是它倾向于强化数据偏差。虽然这种方法选择性地采样被认为对模型改进最有价值的数据点，但它可能会无意中关注非典型的例子，不能代表整个数据集的全貌。因此，基于此类数据集训练的模型可能会形成偏斜的理解，导致性能不佳。
智能系统和人类之间的高效协作长期以来一直是HCI研究的核心主题，最初出现在关于人机共生的经典工作中 (Licklider 1960) 。如今，AI模型在高风险领域的不完善凸显了增强人机协作的需求。交互式数据标注正是这种协作的体现，旨在实现更准确和可信的结果。然而，据我们所知，在此之前没有有效的交互式Text-to-SQL标注工具。
3 初步研究
为了了解Text-to-SQL数据集标注的具体需求，我们采访了Adobe的5名工程师。这些受访者在其工作中经历过Text-to-SQL数据集的标注。我们在第 3.1 节描述了我们的访谈过程。基于这些访谈，我们在第 3.2 节中确定了五个主要用户需求。最后，我们在第 3.3 节讨论了设计原理，旨在解决用户需求。
3.1 访谈
我们通过对话和思考过程进行了20分钟的半结构化访谈。在访谈中，我们首先询问了他们标注Text-to-SQL的原因，特别是他们工作的模式及为什么获得更多数据很重要。受访者表示，当公司推出新服务时，通常需要引入新实体并重新构建原始模式。但在更新模式后，他们通常发现模型性能大幅下降。他们的回归测试显示，对于新添加的列，总体准确性下降了13.3%，对于新表则下降了9.1%。随着模式进一步更新，性能继续下降。此外，随着模式发生重大变化，他们需要大量新数据来进行稳健评估。
其次，我们询问了他们的详细工作流程以及是否使用任何工具辅助数据标注。受访者表示，他们并未使用任何特定的标注工具，尽管有时会要求ChatGPT生成初始数据。此外，他们经常通过改编先前的查询以适应新模式来利用之前的数据库，例如将过时的列名称替换为新的名称。标注完成后，他们的同事进行同行评审以检查和改进数据。
第三，我们询问了他们在数据集标注过程中遇到的挑战及其速度。总的来说，他们认为标注非常昂贵。受访者提到一名工程师每天只能标注50个有效的SQL和自然语言对。他们经常失去方向并感到不知所措。尽管进行了同行评审，他们仍然对标注数据的质量缺乏信心。他们指出，整个过程中存在随机性。我们在第 3.2 节总结了更多挑战作为用户需求。
3.2 用户需求
N1: 有效的模式理解。 Text-to-SQL标注假定用户可以轻松理解以特定格式指定的数据库模式（例如数据定义语言）。然而，我们的访谈表明，用户浏览和理解复杂模式的规格格式既繁琐又易出错。
N2: 创建新查询。 创建SQL查询需要深入了解数据库模式和SQL语法。在创建Text-to-SQL数据集时，用户需要不断生成新的、多样的SQL查询。然而，摆脱以前见过的查询所带来的先入之见对他们来说具有挑战性。
N3: 检测标注数据中的错误。 标注数据集中可能存在错误，这会降低模型性能和评估结果。我们的访谈表明，标注人员需要一种有效的机制来检测构建查询中的潜在错误或歧义。
N4: 高效纠正检测到的错误。 发现错误后，用户需要一种高效的方法来纠正这些错误，以确保数据集的准确性和可靠性。他们需要确保SQL查询在语法上是正确的，并且自然语言问题在语义上与SQL查询等价。
N5: 改善数据集多样性。 数据集的多样性对于提高模型性能和确保严格的评估至关重要。人工标注容易引入偏差，因为个人知识的不足和对数据集组成的整体理解缺乏。因此，受访者报告说需要一种有效的方法来改善数据集的多样性和消除偏差。
3.3 设计原理
为了支持 N1 , 我们的方法将数据库模式可视化为一个动态的、可编辑的图。这使用户能够快速掌握数据库的整体结构以及实体之间的关系。用户可以通过进一步与图进行交互来探索详细信息，如数据类型。
为了支持 N2 , 我们的方法减轻了手动创建新SQL查询的负担。我们设计了一种算法，根据SQL语法随机采样SQL查询模板，然后用从数据库中检索到的实体和值填充此模板。我们使SQL生成高度可配置——用户可以手动调整关键字概率，或通过现有数据集自动调整概率。
为了支持 N3 , 我们的方法通过逐步分析渲染SQL查询和自然语言问题之间的对齐情况。然后，我们的方法提示LLM向用户突出显示潜在的错位。随后，我们的方法执行文本分析以检查SQL查询和自然语言问题的等价性，并为用户提供关于其一致性的置信度评分。
为了支持 N4 , 我们处理两种常见错误——自然语言问题中缺失信息和包含无关信息。我们的方法允许用户通过注入缺失信息或移除无关细节来修复错误，基于LLM生成的建议。
为了支持 N5 , 我们的方法首先根据从真实世界数据中学到的概率分布采样SQL查询，而不是手动创建。此外，我们的方法支持通过图表可视化各种数据集组成。例如，用户可以查看柱状图，显示SQL查询中的列数分布。此功能使用户能够在标注过程中监控数据集组成，保持对标注方向的控制并提高数据多样性。
4 实现
SQLsynth 包含多个UI组件，每个组件对应于Text-to-SQL数据集标注的一个步骤，并解决第 3.2 节中提到的具体用户需求。我们在本节描述每个组件。附加的实现细节，如算法和提示设计，在附录 11 和附录 12 中讨论。
4.1 模式可视化
标注Text-to-SQL数据集要求标注人员理解相应的数据库模式。然而，实际的数据库模式可能非常复杂且难以理解。 SQLsynth 使用户能够通过交互式图形可视化模式，如图 [fig:page1] 所示。用户可以通过将模式文件拖放到画布上或使用上传按钮来上传模式。每个表被可视化为一个框，其中列出各列。主键标为蓝色并标记“PK”。不同表之间列的引用关系用虚线表示，带有指示引用方向的流动动画。要查看详细信息，用户可以悬停在列和表上以查看数据类型或实体描述。界面允许拖动表格、缩放和平移视图。
该图是可编辑的，允许用户根据需要更新模式。要添加新表，用户可以点击左上角的“添加表”按钮（图 [fig:page1] a⃝ )。悬停在表上时，用户可以添加新列或指定主键（图 [fig:page1] b⃝ )。用户可以为每列指定数据类型，并直接链接两个列以建立外键关系（图 [fig:page1] c⃝ )。要删除列，用户可以点击悬停时出现的垃圾桶图标。表和引用链接可以通过键盘上的退格键删除。
鉴于实际数据库实体通常使用缩写，清晰的文档可以帮助LLMs更好地解释模式并在后续步骤中提供更准确的标注建议。 SQLsynth 鼓励用户为表和列添加描述（图 [fig:page1] e⃝ )。为了更好的模式管理，用户可以快速删除整个模式，或者以JSON格式下载或上传它（图 [fig:page1] f⃝ )。
4.2 数据库填充
SQL查询通常引用数据库中的特定值。然而，在标注过程中，数据库中往往没有现有记录可供引用。为了解决这一限制， SQLsynth 使用户能够即时创建一个填充有多种值的沙盒数据库（图 [fig:page2] )。这个沙盒数据库有两个目的：(1) 提供获取值的来源，(2) 允许执行已标注的SQL查询以验证其正确性。
为了填充数据库，用户可以指定所需的记录数量并单击创建（图 [fig:page2] a⃝ )。 SQLsynth 采用基于规则的方法根据数据类型随机合成记录，目前支持八种数据类型，包括 text , boolean , int , timestamp , float , double , decimal , 和 enum 。我们为每种数据类型设计了随机生成规则。例如，在图 [fig:page2] 中，“apt_id”是一个文本字段， SQLsynth 通过将“ apt_id ”作为前缀并附加一个随机UUID来生成值； “ status_date ”是一个时间戳字段，生成类似“ 2022-05-01T06:04:32 ”的值；“ is_available ”是一个布尔字段，因此只会在记录中产生“ True ”或“ False ”。
虽然这些基于规则的合成值可能不反映现实世界的分布，但这不影响标注过程。这些值主要作为占位符，确保已标注的SQL查询能够按预期执行。此外，这些值用于参考，不会改变查询的基本结构或含义。模型不会直接在此类值上进行训练。
SQLsynth 与其他仅在SQL查询中加入虚拟值而未提供可执行环境的方法不同。所有由 SQLsynth 创建的SQL查询都关联其执行结果，帮助用户更好地理解查询行为。
4.3 SQL查询生成
创建无偏SQL查询具有挑战性，尤其是在处理新的和复杂的数据库模式时。为了解决这一挑战， SQLsynth 提供了一个建议的SQL查询（图 [fig:page3_A] a⃝ )，该查询是使用SQL语法和填充数据库中的值随机采样的。具体来说, SQLsynth 使用预定义的概率上下文无关语法（PCFG）专门为SQL查询定制。此PCFG可以在配置文件中轻松修改，如附录 11 所示。虽然用户可以手动配置语法, SQLsynth 也支持从导入的数据集中自动学习关键字概率分布。用户可以直接编辑建议的SQL查询以满足特定需求，并通过“执行”按钮（图 [fig:page3_A] b⃝ )检查执行结果。
与直接使用LLMs生成SQL查询相比，我们的PCFG方法提供了更细粒度的查询多样性和正确性控制。它减少了LLMs引入的偏差或幻觉问题。这是我们决定首先生成SQL查询然后再将其翻译成自然语言（NL）的原因。另一种方法是先生成自然语言问题，然后生成SQL查询。然而，与我们的方法相比，这种方法存在局限性。首先，从头开始生成大量多样的自然语言问题是困难的。自然语言缺乏固定的语法，降低了对数据多样性的控制。相比之下，我们的方法通过直接控制SQL模式确保了数据多样性。其次，从自然语言生成SQL查询本质上意味着解决Text-to-SQL任务。在这种情况下，我们只能通过模型生成SQL查询，而这些模型可能会产生幻觉并引入SQL查询中的生成错误 (Ning 等 2023, 2024) 。相比之下，我们方法生成的SQL查询保证在语法上是正确的。
4.4 自然语言问题生成
4.5 错误检测与修复
4.5.1 SQL逐步步解释为自然语言
为了增强用户对SQL查询的理解并检测潜在错误, SQLsynth 将SQL查询逐步解释为自然语言（图 [fig:page3_A] c⃝ )。我们重用了来自STEPS (Y. Tian, Zhang, et al. 2024) 的基于规则的解释生成方法，该方法解析SQL查询并将查询的每一部分翻译成基于模板的自然语言描述。 SQLsynth 通过以下两种方式增强了这种方法：首先，如果SQL查询无法完全覆盖翻译规则, SQLsynth 会通过少量示例学习提示LLM生成逐步步解释。其次, SQLsynth 会根据模式和文档提示LLM重新表述生成的解释，以提高流畅性和自然度。图 [fig:prompt_explanation] 显示了提示。为了进一步提高可读性, SQLsynth 以不同颜色突出显示解释中的列、表和值。此外，对于每个步骤, SQLsynth 在用户悬停时在左侧渲染相应的子问题（图 [fig:page3_A] f⃝ )。子问题是从仅涉及该步骤的简单SQL查询翻译而来的。
4.5.2 SQL查询、自然语言问题和逐步解释之间的视觉对应
逐步解释充当SQL查询和自然语言问题之间的桥梁。当用户点击“检查对齐”按钮（图 [fig:page3_A] g⃝ ) 时, SQLsynth 在这些元素之间创建三重连接。首先，由于逐步解释是基于语法的，因此SQL组件和解释步骤之间有一对一的映射。其次, SQLsynth 使用LLM将逐步解释与自然语言问题对齐。对于每个解释步骤，LLM会识别出自然语言问题中的相关子字符串，保持一对一或多对一的映射。当用户悬停在解释步骤上（图 [fig:page3_A] f⃝ ) 时, SQLsynth 会将相应的SQL组件和相关问题子字符串高亮显示为黄色。这种三重连接有助于用户将SQL查询和建议的自然语言问题联系起来，增强用户对数据的理解，并辅助检测潜在错误。
4.5.3 错位检测与修正
尽管 SQLsynth 保证了由PCFG采样的SQL查询在语法上的正确性，但由LLM生成的自然语言问题可能存在错误或歧义。 SQLsynth 提出了一种新颖的交互式错误检测和修正策略，通过逐步解释将自然语言问题与SQL查询对齐。受研究 (Tran 等 2025) 的启发， SQLsynth 通过两步提示完成这项任务。我们在图 [fig:prompt_alignment_analysis] 和图 [fig:prompt_alignment_map] 中包含了提示设计，进一步细节参见附录 12 。如果自然语言问题中的任何子字符串未能映射到解释中的任何步骤，该子字符串将以红色突出显示（图 [fig:page3_A] i⃝ )，表明这段文本可能与该SQL查询无关。用户可以专注于红色文本并考虑删除它们。同样，如果某个解释步骤未能映射到自然语言问题中的任何部分文本，该步骤将以红色突出显示（图 [fig:page3_A] h⃝ )，表明该步骤中提到的内容可能在自然语言问题中缺失。在这种情况下，用户可以通过点击相应步骤上的“注入”按钮（图 [fig:page3_A] j⃝ ) 更新自然语言问题。然后，LLM会通过放大该步骤中提到的内容来更新当前的自然语言问题。图 [fig:prompt_inject] 显示了提示。
4.5.4 置信度评分
为了帮助用户更好地评估标注数据的质量, SQLsynth 通过“后标注分析”按钮（图 [fig:page3_B] a⃝ ) 提供了标注后的分析。最近的研究表明，LLMs可以确定SQL查询之间的语义等价性 (Zhao 等 2024) 并通过自我反思生成准确的置信度评分 (Spiess 等 2024; K. Tian 等 2023) 。基于这些发现, SQLsynth 提示LLM提供最终报告和评分，指示数据的质量和正确性。此步骤使用的提示如图 [fig:prompt_equivalence] 所示。评分经过多轮分析后平均，以确保稳定性。此评分作为置信水平，指导用户更多关注检查低分数据，因为这些数据可能存在潜在问题。
根据 SQLsynth 提供的分析，用户可以选择接受或拒绝数据（图 [fig:page3_B] b⃝ )。已接受的数据收集在右侧面板（图 [fig:page3_A] k⃝ )，用户可以随时查看和下载数据集。
4.6 自动化数据集标注
虽然 SQLsynth 使用户能够以交互方式标注Text-to-SQL数据集, SQLsynth 还支持完全自动化的数据标注，无需人工干预（图 [fig:page3_B] c⃝ )。这对于用户需要大量数据而不需要完美数据集质量的情况非常有用（例如，用于微调LLMs）。用户可以指定要合成的查询数量并一键启动。所有生成的数据将自动收集在右侧（图 [fig:page3_A] k⃝ )。
4.7 数据集多样性分析
为了确保标注数据集的多样性和消除潜在偏差, SQLsynth 允许用户监控数据集组成和属性分布。用户可以通过拖放上传数据集（图 [fig:page4] a⃝ )。 SQLsynth 然后以饼图、柱状图或折线图的形式渲染各种属性分布，包括SQL结构、关键字、子句数量、列使用等（图 [fig:page4] b⃝ )。例如，用户可以通过柱状图监控引用值的数量。如果用户发现当前数据集中引用值数量充足的SQL查询代表性不足，他们可以调整PCFG概率以生成引用更多值的SQL查询。并且他们可以选择性地只接受包含足够数量值的查询。除了确保多样性，此UI组件总体上提高了人类在与LLM协作时的控制能力，使用户能够更好地管理标注进度和重点。
5 使用场景
Bob是一名在一家快速增长的技术公司工作的数据科学家。现在，他的任务是为公司最近更新的数据库系统创建高质量的Text-to-SQL数据集，用于训练和评估自然语言（NL）接口。Bob面临几个挑战，使得这项任务特别艰巨。首先，公司刚刚完成了数据库模式的重大更新，引入了新表和关系以适应不断扩展的业务需求。这次更新使以前的数据集过时且与当前模式不兼容。因此，无法基于更新后的数据库准确评估NL接口的性能。其次，模式变得非常复杂，包含众多表和引用关系。手动更新先前的数据集以反映这些变化是不切实际的。Bob意识到他需要一种解决方案，能够高效准确地处理这种复杂性。此外，Bob需要大规模创建多样化、无偏见的SQL查询及其对应的自然语言问题。手动完成这项工作既耗时又具有挑战性，特别是考虑到新模式的复杂性。认识到这些挑战，Bob决定使用新开发的Text-to-SQL数据标注工具 SQLsynth 来简化工作流程，并确保创建一个可控且高质量的数据集。
模式理解。 Bob首先通过将包含公司更新后的数据库模式的JSON文件上传到 SQLsynth 开始。随着模式加载到拖放画布上，Bob立即对 SQLsynth 将复杂的JSON结构转换为直观的视觉表示印象深刻。表以清晰定义的框形式出现，内部列出各列，而表间关系则以动画虚线显示。这种视觉布局使Bob能够快速掌握数据库的整体结构，节省了他原本需要花费数小时来解析JSON文件的时间。通过直观的界面，Bob进行了必要的调整。他双击编辑表名，拖动线条建立引用关系，并为缩写的列名添加说明。缩放功能进一步帮助Bob浏览复杂结构。在工作中，Bob感到效率显著提升，与直接编辑原始模式定义文件相比，不仅速度快得多，而且准确性更高，信心更足。最后，Bob下载了更新后的模式。他相信，这个新文档良好的模式将为未来的项目奠定坚实的基础。
数据库填充。 为了更方便地进行数据标注，Bob使用 SQLsynth 填充数据库中的合成记录。他指定了需要1,000条员工记录。点击SYNTHESIZE按钮后, SQLsynth 立即创建这些记录。Bob审查生成的数据，注意到合成的员工姓名看起来很多样。他继续为其他表生成记录。对数据生成满意后，Bob下载了数据库以备将来使用，并进入下一步。
数据标注。 给定数据库后，Bob准备通过创建SQL查询及其对应的自然语言问题来标注Text-to-SQL数据。Bob觉得从头创建SQL查询具有挑战性，因此决定使用 SQLsynth 生成一个随机的SQL查询：
SELECT Employees.name FROM Employees
WHERE Employees.department_id = 5 AND Employees.salary > 50000
Bob认为这个SQL查询是合理的。为了确认他的理解,Bob点击了ANALYZE SQL按钮, SQLsynth 展示了逐步分析
当Bob悬停在每个步骤上时，对应的子问题会在工具提示中呈现，同时相应的SQL组件也会高亮显示。 SQLsynth 然后为该查询生成一个建议的自然语言问题：
“ 营销部门中哪些员工的薪资高于$50,000且已在公司工作超过5年？ ”
然而，Bob注意到这个问题与SQL查询并不完全匹配，决定使用对齐功能进行优化。Bob点击CHECK ALIGNMENT按钮，急切地想看看生成的问题与SQL查询对齐得如何。他立即注意到问题中一个被红色高亮显示的短语：“ 营销部门 ”，表明在SQL查询中没有对应的元素。Bob意识到这部分信息是无关的，需要删除。为了更好地理解建议查询的质量，Bob悬停在逐步解释上。令他惊讶的是, SQLsynth 进一步通过同时高亮显示将每个解释步骤与自然语言问题中的子串视觉对应。他注意到一个解释步骤，“ 筛选来自部门5的员工 ”，被红色高亮显示。这个视觉提示告诉Bob，这个步骤在当前问题中未得到体现。
Bob决定逐一解决这些问题。首先，他通过删除红色高亮显示的短语“ 营销 ”和无关条件“ 且已在公司工作超过5年 ”来移除无关信息。接下来，他将注意力转向缺少的部门信息。他悬停在红色高亮显示的解释步骤“ 筛选来自部门5的员工 ”上，出现了INJECT按钮。Bob点击此按钮，当前的自然语言问题通过引入该步骤进行了更新。问题现在变为：
部门5中哪些员工的薪资高于$50,000？
兴奋地看到编辑结果后，Bob再次点击CHECK ALIGNMENT按钮。这次，Bob注意到解释和自然语言问题中都没有红色高亮显示。作为最终检查，Bob悬停在解释步骤上，满意地看到每个步骤成功映射到了SQL组件和自然语言问题的子串。
根据视觉对齐结果，Bob确信自然语言问题与SQL查询匹配。为进一步验证，他点击了POST-SYNTHESIS按钮。 SQLsynth 随后在一个简短的段落中报告了等价性分析，并给出了98的高置信度评分。Bob对结果非常满意，接受了这个Text-to-SQL实例，并将其收集到右侧面板。他赞赏交互式对齐功能和直观的三重连接可视化，使他能够高效地识别并纠正错位，对数据质量充满信心。
随着工作的进展，Bob定期使用 SQLsynth 分析数据集组成，以确保创建一个多样且平衡的数据集。他注意到涉及新添加表和关系的查询代表性不足，因此调整了查询生成参数以增加这些查询的频率。一天结束时，Bob创建了一个大量高质量的Text-to-SQL数据集，准确反映了公司更新后的数据库模式。这个新的数据集对于训练和评估他们的自然语言接口至关重要，这是以前由于缺乏相关评估数据而无法实现的。Bob感到成就感满满。他成功地更新并记录了一个复杂的模式，这在手动修改时将极其耗时且容易出错。他还创建了一个特定于公司当前数据库模式的数据集，包括新表、列和关系。更重要的是，该数据集为更新后的模式提供了一个强大的评估基准，使团队能够准确评估其NL接口的性能。工具的交互性质使Bob能够利用他的领域知识，同时受益于自动化生成和分析功能。他欣赏工具如何将通常繁琐且具有挑战性的过程转变为高效且引人入胜的过程，最终提升了公司的数据交互能力。
6 用户研究
为了调查 SQLsynth 的可用性和有效性，我们进行了一项受试者内用户研究，共有12名参与者。该研究比较了 SQLsynth 与手动标注和使用对话式AI助手的情况。
6.1 参与者
我们招募了12名参与者（4名女性，8名男性）来自Adobe。他们分别担任机器学习工程师、研究科学家、数据科学家和产品经理等不同角色。他们的工作直接或间接涉及到数据库查询。所有参与者均拥有硕士学位或博士学位。参与者自评了他们在SQL方面的熟练程度（ 3名初学者 , 3名基础 , 4名 中级 , 2名高级 ) 和使用LLMs的频率（6名 每年 , 2名 每月 , 2名 每周 , 3名 每天 )。
6.2 任务
我们从广泛使用的Text-to-SQL基准Spider中随机抽取了9个模式 (Yu, Zhang, et al. 2018) 。我们将这些模式以JSON格式提供给参与者，其语法所有参与者都能理解。基于模式，参与者被要求在优化数据数量和质量的前提下标注Text-to-SQL数据。
6.3 对比基线
据我们所知，在用户研究时没有现成的Text-to-SQL数据标注工具可以用于比较。因此，我们将 SQLsynth 与两种常见应用于Text-to-SQL数据集标注的方法进行了比较：手动标注和使用AI助手。
手动。 我们要求参与者手动审查并定制模式，创建SQL查询，并编写相应的自然语言问题。他们将结果记录在一个Excel表格中。
AI助手。 我们允许参与者使用最先进的对话式AI助手ChatGPT (GPT-4)。例如，参与者可以直接将整个模式文件上传到与ChatGPT的对话中，并请求生成足够的Text-to-SQL数据。我们不对参与者如何使用ChatGPT施加任何限制。
6.4 协议
每次研究开始时都进行人口统计调查和研究介绍。然后，参与者观看了4分钟的 SQLsynth 教程视频，并花3分钟练习以熟悉它。同时，我们收集了用户的质量反馈。
在参与者熟悉 SQLsynth 后，他们按照分配的条件进行标注（即手动标注、AI助手、 SQLsynth )。每个任务包含三个5分钟的会话，每个条件一个。我们会随机化分配条件的顺序以减少学习效应。在每个会话中，参与者被提供一个数据库模式，并要求尽可能多地标注Text-to-SQL数据集。我们要求参与者不仅要关注数据的数量，还要关注数据的质量。
每次会话结束后，参与者完成了一份事后调查，以评价分配条件下的体验。调查包括系统可用性评分（SUS） (Brooke 2013) 和NASA任务负荷指数（TLX） (Hart 和 Staveland 1988) 问卷，使用7点李克特量表来评估他们的感知。在研究结束时，参与者填写了一份最终调查，分享他们的体验、意见和想法。整个研究大约持续70分钟。
7 结果
本节描述了我们的用户研究结果。我们首先展示了不同条件下用户的标注表现分析，测量了标注速度和质量。然后，我们报告了用户对不同条件的感知，例如他们对标注数据的信心水平和感知的认知负荷。
7.1 标注速度
SQLsynth 在任务完成方面有显著提升，表明它可以在实际应用中提高生产力。与ChatGPT相比, SQLsynth 提供了更好的解释和验证支持。P3说，“ 即使ChatGPT可以给我很多数据，我也需要手动检查它的输出。我觉得在有限的时间内将它的输出SQL与模式连接起来很有挑战性。 ”此外, SQLsynth 作为一个交互界面，允许用户迭代改进数据。P6和P9对此功能表示赞赏。P9说，“ 使用此工具测试和迭代这些数据更容易也更快。 ”
7.2 标注质量
我们将Text-to-SQL数据集的质量定义为以下三个方面：(1) 正确性 （是否有语法错误，以及自然语言问题是否与SQL查询匹配），(2) 自然度 （自然语言问题是否足够自然，符合日常人类提问的习惯），以及(3) 多样性 （数据集是否涵盖了不同的实体和查询类型，且无明显偏差）。
7.2.1 正确性
为了评估参与者的标注正确性，我们手动审查了用户研究期间收集的所有数据。我们在标注数据中评估了两种类型的错误。首先，我们查找SQL语法错误或数据库模式中的实体和引用误用。我们通过在一个充分填充的沙盒数据库中执行SQL查询来识别这种类型的错误。错误会导致执行失败或返回空结果。其次，我们评估SQL查询与自然语言问题的等价性。虽然SQL查询在模式上可能是语法正确的，但它可能不能准确表示自然语言问题的意图。在这种情况下，我们手动评估它们的等价性。表 [tab:correctness_annotation] 显示了每种条件下的两类错误率和总体准确性。
我们观察到手动标注与使用AI助手时错误原因不同。在手动标注过程中，SQL熟练度较低的参与者经常犯语法错误（29.24%）。然而，由于他们倾向于编写简单的SQL查询，等价性错误较少（5.15%）。AI助手ChatGPT很少引入语法错误。然而，它往往生成更复杂的SQL查询（例如多个JOIN），尽管经过参与者修正，这些查询仍然难以与复杂模式匹配，导致SQL执行错误（18.73%）。此外，这些复杂查询在保持与自然语言问题的等价性方面更具挑战性，导致最高的等价性错误率（8.34%）。
与手动标注和使用AI助手相比，使用 SQLsynth 实现了最高的准确性（95.56%）。对于SQL错误，由 SQLsynth 采样的查询保证在语法上是正确的。关于自然语言与SQL的等价性, SQLsynth 通过逐步分析对齐SQL和自然语言，经过人工修正后达到了最佳的等价性。然而，我们观察到在某些情况下（4.44%），它们并不完全等价，表明自然语言生成的准确性仍有改进空间。
7.2.2 自然度
除了正确性，自然语言问题的自然度对于Text-to-SQL数据的质量至关重要。虽然自然语言问题可能与其SQL查询准确匹配，但可能会显得冗长。在现实世界中，人们倾向于提出简洁的问题，遵循一定的自然语言模式。为了评估自然度，我们首先计算了 Flesch-Kincaid可读性评分 (Flesch 1943) , 这是一个自动指标，衡量文本的可读性，评分范围从0到100。为了更好地评估自然度，我们进一步对所有标注问题进行了1到7分的人工评分，隐藏了条件信息。 2
如表 [tab:Flesch-Kincaid] 和表 [tab:natural_rating] 所示, Flesch-Kincaid可读性评分 与人工评分一致。正如预期的那样，手动标注获得了最高评分（Flesch-Kincaid评分：76.94，人工评分：6.25），而通过 SQLsynth 标注的自然语言问题也取得了相当的评分（Flesch-Kincaid评分：73.32，人工评分：6.19）。我们发现使用ChatGPT的自然语言问题自然度最差（Flesch-Kincaid评分：56.14，人工评分：6.02）。值得注意的是，ChatGPT生成的问题常常包含SQL关键字或遵循SQL查询模式（例如： 返回按成绩分组的学生姓名。 )。参与者通常接受ChatGPT的生成而不做修改。虽然 SQLsynth 也基于ChatGPT构建，但它采用逐步分析和从真实问题中学习的方法，从而更好地将真实问题模式融入生成的问题中。此外, SQLsynth 提供了更好的界面，并提供了改进问题的有用建议。参与者报告说，他们更愿意在使用 SQLsynth 时改进LLM生成的数据。P8说，“ 我真的很喜欢这个工具的UI。它提供了如何改进数据的建议。而且我喜欢使用对齐功能来看看可以用现有数据做什么。 ”
7.2.3 多样性
为了评估标注数据集的多样性和潜在偏差，我们从四个维度分析了参与者标注的数据，包括子句数、列数、表数和涉及的值。我们使用辛普森多样性指数 (Simpson 1949) 来衡量每个维度的多样性，该指数用于量化某一属性的异质性水平。
表 [tab:diversity] 显示了每种方法和数据集属性的多样性和平均值。 SQLsynth 在大多数维度上的生成SQL显示出更好的多样性，除了AI助手生成的列。这是因为ChatGPT倾向于在 FROM 子句中加入过多的表（平均值 = 5.75）并在 SELECT 子句中包含过多的列（平均值 = 3.73）。相比之下, SQLsynth 从真实世界数据集中学习分布，从而得出更合理的分布。对于手动标注，参与者通常编写简单的SQL查询。例如，他们很少使用JOIN子句，导致多样性较低。
7.3 用户认知负荷和可用性评分
结果显示，与手动标注和使用ChatGPT相比, SQLsynth 可以显著减少用户的认知负荷。P1说，“ 借助工具生成NL2SQL数据感觉毫不费力。 ”。我们认为这是通过人类与LLM之间更顺畅的合作实现的。P1还全面讨论了 SQLsynth 如何减少用户的认知负荷，“ 该系统使我能够在不付出任何认知努力的情况下生成各种SQL。这很好，因为我无需考虑SQL语法或可能提出的关于数据集的不同查询。我还喜欢系统为每个SQL生成对应的自然语言问题。虽然生成的自然语言问题并非总是准确的，但系统已经提供了一些我可以迭代改进的内容。这几乎就像有人给你一份草稿让你修订，而不是让你从头开始写作。 ”
图 [fig:sus1] 显示了参与者报告的SUS评分，在所有维度上都得到了一致的好评。值得注意的是，没有任何参与者不同意任何维度。虽然少数参与者对 SQLsynth 建议的SQL查询和自然语言问题表达了中立意见，但大多数持积极态度。所有参与者对使用 SQLsynth 标注的数据质量和数量表示高度信心。
8 讨论
8.1 设计启示
SQLsynth 相较于手动标注和使用ChatGPT表现出显著的性能提升。基于参与者的反馈，我们认为这种改进归功于 SQLsynth 的四个关键设计理念：(1) 结构化工作流程，(2) 数据建议，(3) 错误检测和修复，以及(4) 数据可视化。
首先，手动标注和AI辅助方法缺乏结构和标准。相比之下, SQLsynth 将工作流程结构化为具体步骤并提供明确指导（例如，UI中闪烁的下一个组件）。P11写道，“ 总的来说，这个工具非常有用，简化了原本开放的任务。它为非结构化的任务增添了结构。 ”其次，基于语法规则的建议SQL查询和基于LLM的自然语言问题作为无偏见且可靠的起点。标注人员无需从头创建数据，只需改进建议的数据。P3写道，“ 尽管ChatGPT可以给我很多数据，但我需要手动检查它的输出。我认为在有限的时间内将其输出SQL与模式连接起来很具挑战性。 ” P5写道，“ 这对生成合成问题和SQL对非常有用。 ” P1写道，“ 这几乎就像有人给了你一份草稿让你修改，而不是让你从头开始写作。 ”第三, SQLsynth 根据SQL和自然语言之间的错位突出显示潜在错误，节省了错误检查和修正的努力。P6写道，“ 我可以看到对齐功能对复杂查询非常有用。 ” SQLsynth 然后提供修复错位的建议，这进一步减少了错误修正的工作量。P8写道，“ 通过简单点击按钮进行编辑非常有帮助。 ”这两个功能有效地将人类知识融入系统，提供了一种简单的方式让人类与LLM协作。第四, SQLsynth 通过可视化减少了理解复杂数据库模式和数据集组成的心理负担。可视化有助于在整个标注过程中改善人类控制。P2写道，“ 我非常喜欢模式页面，它比查看JSON格式更好地可视化表格结构。 ” P6写道，“ 数据分析帮助我理解数据并知道接下来该做什么。 ”
虽然 SQLsynth 是为Text-to-SQL设计的，但这些设计理念可以应用于其他相关领域。例如，在数学表达式的语义解析中，系统可以根据结构模式（如特定运算符或变量数量的方程式）建议公式，并允许人类在可视化表达树的同时验证数学关系。系统可以通过检测自然语言描述和数学符号之间的一致性，根据常见的数学写作规范提出改进建议。在Python等其他形式语言的语义解析中，系统可以通过代码属性（如测试用例以指示语义模式和控制流图以指示语法模式）配置性地建议代码片段。在图像字幕生成中，系统可以遵循预定义模板生成结构化的字幕，如“一个 [主体] 正在 [动作] 接近一个 [对象]”。系统会使用预定义的对象渲染场景。这种可视化帮助人类快速验证字幕是否准确描述了图像中的关键对象及其空间关系。
SQLsynth 还通过提供置信度评分和多样性检查等功能确保公平性并减少数据标注中的偏差。这些功能使用户能够识别并纠正由AI系统引入的偏差，使标注过程透明且受人类控制。
8.2 局限性和未来工作
尽管 SQLsynth 在Text-to-SQL数据标注方面表现出显著的有效性，参与者还是提出了几项改进建议。P1和P7指出，当SQL查询复杂时，建议的自然语言问题可能不准确，这需要后端更先进的SQL到文本方法。P7提到生成建议的自然语言问题可能需要几秒钟，希望优化生成时间。我们认为可以通过在后台生成后续SQL查询和自然语言问题来优化这一点，让用户在处理前一批数据时无需等待系统动态生成建议数据。P3和P11建议在复杂模式可视化中添加实体名称搜索功能。为了进一步增加可控性，P4建议添加选项以控制生成SQL的属性，而不是完全随机。我们认为所有这些建议对未来改进 SQLsynth 都有价值。
9 结论
本文介绍了 SQLsynth , 一种新型的交互式Text-to-SQL标注系统，使用户能够创建高质量的、特定模式的Text-to-SQL数据集。 SQLsynth 集成了多种功能，包括模式定制、数据库合成、查询对齐、数据集分析以及置信度评分等附加功能。一项有12名参与者的研究表明，结合这些功能, SQLsynth 显著减少了标注时间并提高了标注数据的质量。 SQLsynth 有效弥合了新或未探索模式下训练和评估数据集不足带来的差距。
我们感谢匿名审稿人的详细反馈以及他们花在审阅我们工作的宝贵时间和精力。我们也感谢所有参与访谈和用户研究的参与者提供的宝贵意见。这项工作得到了Adobe的支持，特别是第一作者实习期间的支持。
10 额外用户研究：数据库定制
Text-to-SQL数据标注过程可以分为两个阶段：(1) 数据库模式定制，(2) 基于给定模式的Text-to-SQL数据标注。作为 SQLsynth 的核心贡献，我们主要在主研究中评估了Text-to-SQL数据标注阶段。在本节中，我们报告了数据库模式定制作为额外研究的评估。参与者和条件与主研究相同。
对于结果，我们首先分析了参与者在不同条件下的模式定制表现，重点关注准确性和速度。然后，我们报告了用户对各种条件的感知，包括他们的信心和认知负荷。
10.1 任务
为了评估模式定制表现，我们创建了一个模式编辑任务池。对于每个采样模式，我们手动创建了30个需要编辑现有模式的任务，例如“ 向‘airlines’表添加新列 ‘Founded’（日期）。 ”参与者需依次完成这些任务，因为一些任务依赖于之前任务的完成。我们在不同模式间保持了任务类型的分布一致性（例如，“添加列”任务的数量）。
10.2 协议
有三个会话对应三个条件。每个会话中，参与者被给予一个数据库模式和30个描述如何编辑模式的任务。这三个会话对应三个数据库模式。鉴于任务数量较多，参与者被要求在5分钟的时间限制内尽可能多地完成任务。
每个会话结束后，参与者完成了一份事后调查，以评价分配条件下的体验。调查包括系统可用性评分（SUS） (Brooke 2013) 和NASA任务负荷指数（TLX） (Hart 和 Staveland 1988) 问卷，使用7点李克特量表来评估他们的感知。
10.3 模式定制表现
我们手动审查了参与者完成任务的正确性。对于每个任务，如果参与者满足所有要求，则标记为正确；否则标记为错误。表 [tab:schema_edit_performance] 报告了每个条件下的完成任务数量及其准确性。
结果显示，使用 SQLsynth 可以帮助用户在5分钟内实现最高的定制速度（10.73）和准确性（96.86%）。当在JSON文件中手动定制模式时，用户实现了最低的定制速度（7.18）和准确性（81.27%）。使用ChatGPT时，用户实现了中间速度（9.73）和准确性（67.48%）。
使用ChatGPT时，我们观察到一些参与者直接将整个模式和任务描述复制粘贴到提示中。这种方法在模式简单且只包含几张表和几列时有效。然而，随着模式变得复杂，ChatGPT可能会因幻觉而犯错 (L. Huang et al. 2023) 。
使用 SQLsynth 时，尽管后端没有LLM，参与者通过直接编辑图形非常快速地完成了模式定制任务。用户可以通过可视化精确编辑并立即检测错误。事实上，除了一名误解实体名称的参与者外，所有其他参与者都实现了100%的任务完成准确性。
10.4 用户认知负荷和可用性评分
参与者赞赏将模式可视化为可编辑图形，这促进了理解和修改。P2报告说，“ 我非常喜欢模式编辑页面，它比查看JSON格式更好地可视化表格结构。 ” P11写道，“ 模式编辑更容易，能够可视化编辑非常有用。 ” P9评论道，“ 我确实发现这个工具在快速编辑和理解不同表之间的依赖关系方面非常方便。 ”
图 [fig:sus2] 展示了任务2的SUS评分，揭示了用户在所有维度上的高度正面感知。参与者同意或强烈同意 SQLsynth 帮助他们理解模式。他们还觉得更新模式更简单快捷，并对结果有很高的信心。
11 SQL采样中的PCFG示例
表 [tab:sql-pcfg] 展示了用于随机采样的概率上下文无关语法（PCFG），对应于第 4.3 节中描述的方法。请注意，这些概率是说明性的例子，并非来自真实世界查询分布。在实际应用中，这些概率可以通过大量真实世界的SQL查询进行调整。为了保护客户数据隐私，我们不显示实际的概率分布。
12 SQLsynth 中使用的提示
在本节中，我们展示了 SQLsynth 在不同功能中使用的提示。每个提示都经过精心设计，以引导语言模型生成特定输出，同时保持一致性和质量。提示包括相关背景、目标和结构化输出格式，以便后续解析。
图 [fig:prompt_explanation] 显示了生成逐步解释和子问题的提示。请注意，仅当基于规则的解释生成失败时才会调用此提示并调用LLM。图 [fig:prompt_question] 显示了自然语言问题生成的提示。图 [fig:prompt_subquestion] 展示了子问题生成的提示。图 [fig:prompt_alignment_analysis] 和图 [fig:prompt_alignment_map] 分别显示了对齐分析和映射生成的提示。作为 SQLsynth 的核心功能之一，我们将此任务分解为两个较小的子任务：自由形式文本分析和结构化输出生成。这种分解受研究 (Tran et al. 2025) 的启发，研究表明多代理协作可以提高生成准确性。图 [fig:prompt_inject] 展示了通过强调特定步骤来更新自然语言问题的提示。最后，图 [fig:prompt_equivalence] 显示了分析和评分NL-SQL等价性的提示。
扫一扫
4592
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
