SQLens：一种用于文本到 SQL 错误检测与修正的端到端框架

龚岳 ${}^{\circ }\cdot \hat{}$ 雷川 ${}^{\circ }$ 秦晓 ${}^{\circ }$ 卡皮尔·瓦伊达亚 ${}^{\circ }$
巴拉克里希南·纳拉亚纳斯瓦米 ${}^{\circ }$ 蒂姆·克拉什卡 ${}^{\circ }\cdot {}^{\text{D }}$
${}^{\circ }$ 亚马逊网络服务公司 \quad 芝加哥大学 \quad 麻省理工学院
yuegong@uchicago.edu, {chuanlei,drxqin,kapivaid,muralibn,timkraska}@amazon.com

摘要

文本到 SQL 系统将自然语言（NL）问题转化为 SQL 查询，使得非技术用户能够与结构化数据进行交互。尽管大型语言模型（LLMs）在文本到 SQL 任务上取得了令人满意的结果，但它们常常生成语义错误但语法正确的查询，并且对其可靠性知之甚少。我们提出了 SQLens，这是一个用于细粒度检测和修正 LLM 生成的 SQL 中语义错误的端到端框架。SQLens 综合了来自底层数据库和 LLM 的错误信号来识别 SQL 子句中的潜在语义错误。它进一步利用这些信号来指导查询修正。在两个公开基准上的实证结果表明，SQLens 在 F1 分数上比最好的基于 LLM 的自我评估方法高出 $25.78\%$，并且将现成的文本到 SQL 系统的执行准确性提高了高达 $20\%$。我们的代码及完整文档可在 https://anonymous.4open.science/r/sqlens-7DE6/ 上获取。

1 引言

文本到 SQL 系统将自然语言（NL）问题转化为一个 SQL 查询，使得非技术人员能够查询关系数据库并提取见解 [28]。大型语言模型（LLMs）已显著推动了这一任务的发展，最近的方法 [39, 30, 25, 13] 在 BIRD [21] 和 Spider [50] 等公共基准测试中取得了令人满意的结果。这样的基于 LLM 的文本到 SQL 解决方案已被 AWS [3]、Databricks [9]、Snowflake [36] 等数据平台采用。
尽管取得了这些进展，LLM 生成的查询仍然容易出错 [11]。BIRD 排行榜 [4] 上表现最好的方法在开发集上的执行准确率仅为约 $75\%$，在 1534 个 NL 问题中仍然会产生超过 400 个不正确的 SQL 查询。虽然已有大量努力致力于改进基于 LLM 的文本到 SQL 系统中的检索和生成阶段 [39, 30, 25]，例如模式链接、思维链（CoT）提示、任务分解以及单元值的包含，但这些方法仍不足以完全消除错误，因为 LLM 并不总是遵循所提供的指令。
文本到 SQL 系统的一个主要空白在于缺乏细粒度的、可解释的错误检测——尤其是对于那些查询执行但返回错误结果的语义错误。检测此类错误需要理解查询逻辑和数据库结构，而大多数现有方法未能捕捉到这一点 [29, 43, 20]。它们在生成 SQL 查询时不估计质量或置信度，这使得用户难以调试 [37]。在本文中，我们解决了错误检测和修正中的三个挑战：

挑战 1：识别子句级别的语义错误。语义错误通常由多种原因引起，从外部知识的不一致到 LLM 对数据库的理解错误。

图 1：SQLens 的概述。
架构。由于 NL 歧义以及 SQL 查询、数据和模式的复杂性，识别这些问题具有挑战性 [42, 15]，需要对所有这些来源进行联合推理。

挑战 2：预测带有噪声错误信号的 SQL 查询的正确性。错误信号是真实语义错误的嘈杂代理。每个信号从特定的角度评估生成的 SQL 的语义正确性，可能遗漏整体上下文。挑战在于聚合多个嘈杂信号的决策，以确定 SQL 查询是否语义错误。

挑战 3：在没有正确性 oracle 的情况下修复 SQL 查询。修正 SQL 查询很困难，因为它必须谨慎地进行，以免破坏可能已经正确的查询，因为不假设存在正确性 oracle。此外，修复错误的顺序至关重要，因为错误可能是相互依赖的，解决根本原因可以解决许多相关问题。

最先进的方法。现有的文本到 SQL 方法通常依赖于 LLM 自我反思来进行错误检测和修正 [29, 20, 30]，但遭受自我偏好偏差 [27, 47]，导致召回率低。基于 RL 的方法正在兴起，使用基于执行准确性、语法正确性或 LLM 评估的奖励 [32, 23]，但仍缺乏精确错误识别所需的粒度。这些方法通常仅提供整个 SQL 查询的单个置信度评分，而不指出具体的错误子句或解释原因——限制了可调试性并减少了对文本到 SQL 助手的信任 [5]。

SQLens 概述。我们介绍了 SQLens，这是一种利用来自数据库和 LLM 的多样化错误信号来检测和修正语义 SQL 错误的端到端框架。如图 1 所示，SQLens 将 SQL 查询解析为抽象语法树（AST），并使用其错误检测器收集用于识别潜在错误的噪声信号（挑战 1）。为了处理噪声信号，SQLens 使用弱监督将它们组合成概率标签——不需要地面实况——并训练分类器来预测语义正确性并生成详细的错误报告（挑战 2）。然后，SQLens 的错误选择器分解 SQL 修正任务，并引导 LLM 根据优先级错误进行迭代修正（错误修正器）（挑战 3），SQL 审计员则在原始版本和修订版本之间选择更好的查询。

贡献。我们的贡献可以总结如下：(1) 我们提出的 SQLens 整体利用细粒度错误信号来预测 SQL 查询的语义正确性并使用这些信号修正错误查询；(2) SQLens 利用 LLM 和数据库信号诊断 SQL 查询，并采用弱监督框架聚合噪声错误信号以估计语义正确性；(3) 我们设计了一种序列错误修正策略，引导 LLM 逐步修正 SQL 查询，优先考虑最关键错误以最小化连锁错误；(4) 在 BIRD [21] 和 Spider [50] 上的实验结果显示，SQLens 在 F1 分数上比最好的 LLM 自我评估方法提高了 $25.78\%$ 的语义错误检测效果，并且平均将现有文本到 SQL 解决方案的执行准确性提高了 $3\%$。

2 相关工作

文本到 SQL。大型语言模型（LLMs）随着模型规模的增加，在自然语言理解方面表现出显着的能力。基于 LLM 的文本到 SQL 系统，如 DIN-SQL [29] 和 MAC-SQL [43]，使用多代理框架将任务分解为子任务

图 2：来自 BIRD 的运行示例，其中每个客户端都保证有一个账户。
以实现有效的执行。其他方法如 MCS-SQL [20]、CHESS [39] 和 Chase-SQL [30] 遵循类似的流程——检索相关上下文、选择模式和合成 SQL 查询。最近探索了基于 RL 的文本到 SQL 推理模型，其中奖励通常基于执行准确性、语法正确性或基于 LLM 的自我评估 [32, 23]。我们提出的错误检测可以自然集成到这个框架中作为奖励函数，提供更有意义的语义监督以指导和增强模型推理。

文本到 SQL 中的错误检测和修正。早期的方法 [6, 48, 49, 51] 主要集中在二元正确性分类上，对错误的本质提供了有限的见解。基于 LLM 的文本到 SQL 系统 [29, 43, 31, 20] 通常依赖于 SQL 执行反馈或 LLM 自我反思来判断正确性。相比之下，SQLENS 产生可解释的子句级错误信号，可以指导用户调试和下游学习框架。LLM 自我评估技术 [17, 14] 评估响应质量，而 Tian 等人 [40] 和 Self-RAG [1] 通过微调和基于检索的自我批评提高置信度估计和事实准确性。然而，这些都是为一般任务构建的，并没有解决文本到 SQL 的特定挑战。

3 方法论

3.1 问题公式化

在本文中，表 $T$ 由一组列 C = { C 1 , C 2 , … , C n } \mathcal{C}=\left\{C_{1}, C_{2}, \ldots, C_{n}\right\} C={C1​,C2​,…,Cn​} 组成。两个表 $T_i$ 和 $T_j$ 之间的连接关系 $J$ 基于共同属性（即，可连接的列 $T_i.C_m$ 和 $T_j.C_n$）。数据库实例 D = { ( T 1 , T 2 , … , T n ) , J } \mathcal{D}=\left\{\left(T_{1}, T_{2}, \ldots, T_{n}\right), \mathcal{J}\right\} D={(T1​,T2​,…,Tn​),J} 包括一组表和一组表之间的连接关系 $\mathcal{J}$。

定义 1（文本到 SQL 算法） 文本到 SQL 算法 $f$ 输入自然语言问题 $\mathcal{Q}$、数据库实例 $\mathcal{D}$，以及可选的外部知识 $\mathcal{K}$，并生成 SQL 查询 $q=f(\mathcal{Q},\mathcal{D},\mathcal{K})$。

图 2 展示了一个使用 BIRD 基准中问题的例子，询问在 Jesenik 分行开户的女性客户数量。该基准还提供了外部知识，例如列名和单元格值的注释。预测的 SQL 查询是由文本到 SQL 算法生成的，以回答该问题。

定义 2（语义错误） 语义错误 e 导致 SQL 查询 q 无法正确回答自然语言查询 $\mathcal{Q}$。形式上，

$$do(e)\Rightarrow \mathcal{O}(q,\mathcal{D})\ne \mathcal{O}(\mathcal{Q},\mathcal{D})$$

操作 $do(e)$ 表示由于 $e$ 导致 $q$ 生成中的干预，导致观察输出 $\mathcal{O}(q,\mathcal{D})$ 和预期正确输出 $\mathcal{O}(\mathcal{Q},\mathcal{D})$ 之间的不匹配，从而标识 $e$ 为语义错误。

例如，图 2 中生成的 SQL 查询语义错误，输出为 0，而根据地面实况 SQL 查询，正确输出应为 26。首先，查询错误地使用了 jesenik 谓词，导致空结果。其次，查询违反了外部知识中指定的证据

图 3：语义错误和信号的因果图
使用 gender=‘Female’ 而不是 gender=‘F’ 的证据。即使谓词正确，SQL 查询仍会由于错误的连接谓词和次优连接路径而产生 23 的错误结果。具体来说，client 和 account 表之间没有有效的连接路径，表明查询中的连接谓词 client.client_id = account.account_id 是虚构的。此外，涉及连接路径的 account 表是冗余的，因为 client 和 district 表可以根据数据库直接连接。

问题 3.1（语义错误检测）给定一个自然语言问题 $\mathcal{Q}$，一个数据库实例 $\mathcal{D}$，可选的外部知识 $\mathcal{K}$，以及由文本到 SQL 算法 $f$ 生成的输出 SQL 查询 $q=f(\mathcal{Q},\mathcal{D},\mathcal{K})$，任务是确定 $q$ 是否语义正确，如果不正确，则识别 $q$ 中的一组潜在语义错误 $\mathcal{E}$。

对于语义错误的 SQL 查询，我们的目标是修正它，使其能够正确回答给定的 NL 问题。
问题 3.2（语义错误修正）给定一个语义错误的 SQL 查询 q，任务是修正 $q$，使得修正后的查询 $q^{\prime }$ 能够准确回答自然语言问题 $\mathcal{Q}$，使得 $\mathcal{O}(\mathcal{Q},\mathcal{D})=\mathcal{O}\left(q^{\prime },\mathcal{D}\right)$。

3.2 SQLENS 错误检测

由于 SQL 查询的复杂性以及自然语言 (NL) 查询、数据和数据库模式中存在的歧义，准确识别语义错误本质上是困难的。我们的洞察力是，LLM 生成的查询中的许多语义错误表现出可以通过精心设计的信号检测到的常见模式。基于近期文本到 SQL 研究的观察和见解 [43, 20, 31]，我们将常见的语义错误归类如下。

1. 问题歧义。用户的问题可能本身就包含歧义，并且可以从多个角度解释。例如，如果用户问“上一季度的总销售额是多少？”在一个销售表中包括 gross_sales 和 net_sales 列的数据库中，任一列都可以用来回答这个问题。
2. 2. 数据歧义。在现实世界的数据库中，由于数据整合、版本控制、表转换和其他因素，可能会出现多个名称相似或相同的表或列，导致歧义。例如，如果用户问“各部门的平均工资是多少？”，但数据库中包含 dept 表和 department 表，选择错误的表会导致查询结果错误。
3. 3. 语义不对齐。即使 NL 问题和数据库没有歧义，语义差距仍可能导致生成的 SQL 和 NL 问题之间的不匹配。例如，如图 2 所示，由于 LLM 错误解释了金融数据库中的连接关系，导致了错误的连接谓词 (client.client_id = account.account_id)。
      错误信号充当检测 SQL 查询中语义错误的代理。SQLENS 的错误检测器结合了来自数据库和 LLM 的信号来检测这些错误。图 3 说明了 SQLENS 中的每个信号如何对应常见的语义错误类型。

基于数据库的错误信号。基于数据库的信号旨在识别数据中的语义不对齐和固有歧义。这些信号的灵感来自于各种 SQL 工作负载，包括现实生活场景和基准测试，如 TPC-DS [26]、Redset [41]、BIRD [21] 等。这些信号可以通过以下方式可靠且高效地获得，无需使用 LLM：(1) 从查询计划中提取信息（例如，空谓词），(2) 检查（元）数据信息

图 4：使用弱监督的信号聚合。
来自底层数据库（例如，次优连接树，值歧义），或者 (3) 利用从上述查询工作负载中得出的一般启发式方法（例如，不必要的子查询）。在附录 B 中，我们展示了基于实际应用中的 NL 问题的错误和正确 SQL 查询对的例子，突出了每个信号针对的具体 SQL 子句。

基于 LLM 的错误信号。对于由于不足的证据或 LLM 幻觉引起的语义错误，我们需要同时考虑 NL 问题和 SQL 查询，并理解 LLM 的推理过程。因此，SQLENS 引入了基于 LLM 的错误信号，深入探讨问题歧义和 LLM 的推理过程 [45]。所有基于 LLM 的信号都是通过一次 LLM 调用获得的，与多次单独调用相比，大大降低了成本和延迟。错误信号的详细描述以及示例在附录 C 中提供。用于收集这些信号的相应提示包含在附录 D 中。
在文本到 SQL 中进行有效的错误检测需要整合基于数据库和基于 LLM 的信号：前者擅长识别结构或值错误，而后者捕获需要对 NL 问题和查询进行细致解释的逻辑不一致性。由于这些信号本质上是嘈杂的，SQLENS 避免依赖任何单一来源。相反，它采用一种基于学习的方法（第 3.3 节）来聚合互补信号，结合数据库分析和 LLM 推理。这使 SQLENS 成为一个通用且可扩展的稳健错误检测和纠正框架。

3.3 使用弱监督聚合所有信号

我们收集的信号本质上是嘈杂的——每个信号可能错误地标记正确的 SQL 子句或忽略实际错误。为缓解此问题，我们采用了一个弱监督框架（如图 4 所示），该框架聚合这些不同的信号，将每个信号视为一个提供部分和嘈杂监督的标记函数（LF）。受先前工作的启发 [34, 12]，这种方法不仅结合了信号，还学习了它们的准确性和相关性，以更好地近似真实情况。在 SQLENS 中，每个错误信号 $s$ 充当 LF，识别 SQL 查询 $q$ 中的潜在问题。形式上，

$$\mathcal{I}={\lambda }_s(q)=\{\begin{array}{ll}1& \text{ 如果 }|s(q)|>0\\ -1& \text{ 如果 }|s(q)|=0\end{array}$$

其中 $\mathcal{I}=1$ 表示错误信号 $s$ 检测到至少一个有问题的 SQL 子句（即，可能不正确），$\mathcal{I}=-1$ 表示未发现任何问题。然而，仅依赖否定信号会限制覆盖范围。为提高召回率，我们引入了三个正向标签器，当未检测到问题时分配 $\mathcal{I}=0$（即，可能正确）：(1) ${\lambda }_{all}$ 标签器在未检测到错误信号时将 SQL 查询标记为正确；(2) ${\lambda }_{db}$ 标签器在未检测到基于数据库的信号时将 SQL 查询标记为正确；(3) ${\lambda }_{llm}$ 标签器在未检测到基于 LLM 的信号时将 SQL 查询标记为正确。
每个查询 $q$ 因此表示为决策向量 ${\Lambda }_q=⟨{\lambda }_{s_1}(q),\dots ,{\lambda }_{s_n}(q),{\lambda }_{all}(q),{\lambda }_{db}(q)$, ${\lambda }_{llm}(q)⟩$。我们使用生成模型来估计联合分布 $p(\Lambda ,Y)$，其中 $Y$ 是未观测的真实标签，通过优化：

$${\theta }_{\text{opt }}=\arg \underset{\theta }{\min }-\log \sum _Y{p}_{\theta }(\Lambda ,Y)$$

生成的概率标签 $p(\Lambda ,Y)$ 反映了每个 SQL 查询的估计正确性，我们使用这些标签来训练分类器以进行下游语义错误检测。

3.4 SQLens 错误修正

如第 1 节所述，基于 LLM 的文本到 SQL 方法 [29, 7] 通常依赖于自我反思而没有对修正进行基础。这导致了两个问题：(1) 由于生成

{
“signal description”: “SQL 查询在 JOIN 子句中使用了比必要更多的表，这可能导致潜在错误。”,
“correction instruction”: “审查并修改 SQL 查询，只在 JOIN 子句中包含必要的表。”,
“problematic clauses”: {
“tables used in the JOIN clauses”: [“client”, “account”, “district”],
“optimal set of tables to join”: [“client”, “district”]
},
“confidence”: “high”
}

图 5：次优连接树的示例错误报告
偏见 [27, 47] 和有限的事实基础 [35] 导致幻觉，以及 (2) 当依赖单一不可靠的正确性估计时，原本正确的查询退化。其他方法同样假设所有 SQL 查询都不正确 [8, 2]，忽视了过度修正的风险。

SQLens 错误报告。在 SQLens 中，错误信号与 SQL 子句相关联，并提供详细的错误报告。错误报告包括 (1) 信号描述，解释错误信号及其触发条件；(2) 示例（可选），澄清信号的含义；(3) 修正指令，用于修正 SQL 查询；(4) 被识别为潜在错误源的问题子句。这样的错误报告为 SQL 查询中识别出的错误提供了丰富的上下文；以及 (5) 根据错误检测中为每个标签器分配的权重，将置信度分为高、中、低三档。图 5 展示了由次优连接树信号为图 2 中显示的 SQL 查询生成的错误报告示例。

SQLens 修正策略。使用错误信号进行 SQL 查询修正的一种直观方法是将所有检测到的错误信息串联起来，并要求 LLM 一次性修正所有错误。然而，提供过多的信息会使 LLM 过载，导致其失去焦点 [22]。为了解决这个问题，SQLens 分解了 SQL 修正任务，指导 LLM 逐步修正查询。SQLens 在每次迭代中优先修正最关键错误，允许 LLM 专注于逐一解决问题，减少分心的风险 [18, 44, 46]。通过首先处理最关键错误，也可以更快地减少总错误数，因为相关的错误可以在根源被修正后自动解决。这个迭代过程继续进行，直到没有剩余错误信号或达到最大迭代次数为止。附录 E 中的算法 1 提供了错误修正的伪代码。修正提示在附录 D.8 中提供。

• 错误选择器。给定一个 SQL 查询、模式和按排名排序的错误报告列表，错误选择器使用一个 LLM 来优先决定首先修正哪个错误，根据与原始查询的相关性调整排名 [38, 24, 33]。最高优先级的错误随后传递给错误修正器。
• • 错误修正器。错误修正器接收查询和选定的错误报告，使用上下文信号应用有针对性的修正（算法 1），并通过 SQL 解析器验证修订后的查询。如果出现语法问题，修正器使用解析器反馈迭代地解决它们。修正后的查询由错误检测器重新评估；该过程重复进行，直到没有错误或达到最大迭代次数。固定信号被移除以防止冗余修正。
• • SQL 审计员。为了避免遗漏持续错误，可以指定一个高精度信号作为护栏来触发最终调整。为了避免原生正确查询的退化，最终修订查询和原始查询都由基于 LLM 的 SQL 审计员评估，选择最符合输入问题的版本。

4 实验评估

4.1 实验设置

数据集。我们在两个标准的文本到 SQL 基准测试集 dev sets 上进行评估：BIRD [21] 和 Spider [50]。用于评估的 SQL 查询使用四个最先进的文本到 SQL 系统生成，Claude 3.5 Sonnet 作为主干 LLM：(1) 一个基本的模式感知提示（Vanilla），列出在附录 D.1 中，(2) DIN-SQL [29]，(3) MAC-SQL [43]，和 (4) CHESS [39]。语义正确性通过将生成的查询与黄金 SQL 查询进行比较来确定。
表 1：BIRD 上的端到端准确率提升。

	方法	Δ Acc. (N_net)	Δ Acc. (N_fix)	N_net	N_fix	N_break
Vanilla	自我反思	59.07 (+0.00%)	60.6(+1.53%)	1	22	21
	SQLENS w. Fix-ALL	61.15 (+2.08%)	62.34 (+3.27%)	30	47	17
	SQLENS	62.54 (+3.47%)	63.66(+4.59%)	50	66	16
DIN-SQL	自我反思	54.63 (+15.14%)	56.37(+16.88%)	209	233	24
	SQLENS w. Fix-ALL	58.11 (+18.62%)	59.71(+20.22%)	257	279	22
	SQLENS	59.99 (+20.50%)	61.45 (+21.96%)	283	303	20
MAC-SQL	自我反思	60.12 (+0.80%)	62.63(+2.59%)	12	39	27
	SQLENS w. Fix-ALL	62.43 (+2.39%)	63.84(+3.80%)	36	57	21
	SQLENS	64.03 (+3.99%)	65.23 (+5.19%)	60	78	18
CHESS	自我反思	67.99 (+0.08%)	69.42 (+1.51%)	12	23	11
	SQLENS w. Fix-ALL	68.96 (+1.05%)	70.21(+2.30%)	16	35	19
	SQLENS	69.74 (+1.83%)	70.53(+2.62%)	28	40	12

评估指标。我们在两个任务上评估 SQLENS：(1) 端到端修正，测量基准测试中的执行准确率增益；(2) 语义错误检测，框定为二分类问题。对于修正，在执行准确率增益 Δ Acc. 之外，我们还报告了 N_fix（不正确 → 正确）、N_break（正确 → 不正确）和净改进 N_net=N_fix−N_break。对于错误检测，我们将语义不正确的查询视为正类，并报告准确率、AUC 和精度/召回率/F1，基于 5 折交叉验证。

端到端修正基线。(1) 自我反思：标准 LLM 提示 [29]，模型被给予模式、样本值和原始 SQL 查询，并在没有任何明确错误信息的情况下进行调试。(2) SQLENS + Fix-ALL：同时向 LLM 提供 SQLENS 检测到的所有错误信号，提示其基于完整的错误报告集修正查询。

语义错误检测基线。(1) LLM 自我评估（Bool）：按照 Kadavath 等人的方法 [17]，LLM 被问及 SQL 查询是否正确回答了问题（是/否）。(2) LLM 自我评估（Prob）：基于 Tian 等人的方法 [40]，LLM 输出查询正确性的置信度分数（0-1）；高于 0.5 的分数被视为正确。(3) 监督 SQLENS：训练一个分类器，使用错误信号输出作为特征，并使用 AutoGluon [10] 自动生成最佳性能模型，基于生成的 SQL 与真实情况对比得到的黄金正确性标签。
所有方法，包括 SQLENS，均使用 Claude 3.5 Sonnet 作为主干 LLM。我们的代码可在 https://anonymous.4open.science/r/sqlens-7DE6/ 获取，其中包括我们方法和所有基线的完整实现。

4.2 主要结果

如表 1 所示，SQLENS 在所有现成的文本到 SQL 系统中始终提高了端到端的准确性，并且在 BIRD 上优于自我反思和 Fix-ALL。在这种现实情况下——输入包括正确和不正确的查询——SQLENS 达到了最高的净改进（N_net），修正了更多查询并引入了更少的回归。例如，使用 vanilla 提示生成的查询，SQLENS 修正了比自我反思和 Fix-ALL 多 49 和 20 个查询，分别实现了 3.47% 和 2.08% 的更高准确性。它将 DIN-SQL 的性能提高了 20.5%，并将 CHESS 从 67.91% 提高到 69.74%。当假设所有输入都不正确时——正如其他方法所做的那样——SQLENS 平均增益为 4.13%。值得注意的是，LLM 自我反思破坏了最多的正确查询，强调了基于信号驱动的修正的必要性。Spider 上的结果在附录 F.1 中。

4.3 消融研究

错误检测性能分析。我们评估了 SQLENS 在预测语义正确性方面的有效性。BIRD 上的结果如表 2 所示，Spider 上的额外结果在附录 F.2 中提供。
表 2：BIRD 上 SQLENS 错误检测的有效性。

	方法	准确率	AUC	精确率	召回率	F1
Vanilla	LLM 自我评估 (Bool)	60.53(±2.30)	x	57.70(±18.90)	10.02(±4.54)	16.97(±7.35)
	LLM 自我评估 (Prob)	59.76(±1.10)	64.23(±2.98)	64.22(±22.97)	2.72(±1.89)	5.17(±3.49)
	监督 SQLENS	66.58†(±2.56)	65.12†(±3.88)	71.83†(±9.55)	31.77(±7.38)	43.32†(±6.47)
	SQLENS	64.63(±1.97)	61.90(±2.18)	58.11(±2.80)	48.74†(±4.31)	52.94†(±3.24)
DIN-SQL	LLM 自我评估 (Bool)	61.52(±1.20)	x	86.83(±2.18)	42.99(±2.72)	57.43(±2.20)
	LLM 自我评估 (Prob)	49.57(±1.56)	73.01(±0.86)	92.27†(±5.05)	17.84(±2.19)	29.83(±3.09)
	监督 SQLENS	76.96†(±2.10)	83.55†(±2.33)	85.90(±2.14)	74.13(±3.27)	79.53†(±2.14)
	SQLENS	75.29(±2.33)	81.49(±1.74)	81.64(±2.17)	76.41†(±3.50)	78.88(±2.19)
MAC-SQL	LLM 自我评估 (Bool)	61.50(±1.47)	x	65.51(±14.72)	7.83(±2.16)	13.94(±3.69)
	LLM 自我评估 (Prob)	61.37(±0.81)	64.60(±2.19)	72.69†(±12.19)	5.16(±1.53)	9.61(±2.76)
	监督 SQLENS	67.09(±3.56)	65.07†(±4.30)	66.19(±10.83)	38.11(±2.90)	48.16(±4.29)
	SQLENS	67.43†(±4.38)	64.27(±4.42)	63.27(±8.64)	45.10†(±3.90)	52.63†(±5.62)
CHESS	LLM 自我评估 (Bool)	67.98(±1.95)	x	50.89(±10.76)	15.71(±3.96)	23.81(±5.22)
	LLM 自我评估 (Prob)	68.50(±0.82)	64.23†(±1.65)	61.87(±13.09)	4.90(±1.63)	9.03(±2.87)
	监督 SQLENS	72.10†(±1.27)	62.95(±3.23)	72.43†(±8.93)	23.06(±7.23)	33.96(±8.04)
	SQLENS	69.35(±1.60)	63.34(±2.90)	52.54(±2.91)	44.69†(±6.03)	48.17†(±4.33)

x 表示分类不是基于阈值的。† 最佳结果；前两名加粗。

在 BIRD 上，SQLENS 在准确率、召回率和 F1 方面均优于所有基线，显示出其在识别错误 SQL 查询方面的卓越能力。对于 DIN-SQL，SQLENS 的 F1 得分为 78.88，比最佳 LLM 自我评估基线（57.43）高出 21.45 分。尽管 LLM 自我评估（Prob）在 MAC-SQL 上获得了最高的精确度，但它在召回率方面表现最差。

在聚合信号时，监督版的 SQLENS 在训练期间访问黄金标签以更好地评估信号可靠性，从而在准确率、AUC 和精确度方面取得更高的成绩。相比之下，弱监督变体通过利用信号之间的一致性而不依赖地面真值，提高了召回率和 F1。虽然这导致精确度和准确率略有下降，但它能够通过捕捉 SQL 错误的各种方面来实现更广泛的错误覆盖。

我们进一步通过消融研究分析了 SQL 审计员和看门狗信号对 SQLENS 错误修正的影响，如表 3 所示。

SQL 审计员的影响。SQL 审计员有助于减少修正过程中断的 SQL 查询数量。然而，这样做的代价是修正的整体查询数量减少。启用 SQL 审计员的决定取决于期望的目标：是优先保守修正以最小化回归，还是采取更激进的修正以最大化修正的查询总数。

看门狗信号的影响。为了隔离看门狗信号的影响，我们在运行 SQL 审计员之前比较了使用和不使用看门狗信号的结果。如表 3 所示，使用看门狗信号增加了净改进，提高了总的修正数量，同时减少了总的回归数量。

4.4 各个信号的有效性

我们在 BIRD 上进行了微观基准测试，以评估各个信号在错误检测和修正中的有效性。
表 4：使用单个错误信号进行错误检测。

信号名称	DIN-SQL			MAC-SQL			CHESS
基于数据库的错误信号	精确率	召回率	N_m	精确率	召回率	N_m	精确率	召回率	N_m
异常结果	99.68	37.01	509	100	6.66	40	98.48	13.27	65
空谓词	96.07	46.83	391	75.81	7.82	47	81.25	10.61	32
子查询中的错误过滤	无检测到的查询			76	3.16	19	无检测到的查询
错误的 GROUP BY	68.75	5.27	44	66.67	3.0	18	50	0.2	1
错误的 JOIN 谓词	100	0.12	1	92.86	2.16	13	100	0.41	2
次优的 JOIN 树	73.86	15.57	130	62.24	10.15	61	55.13	8.78	43
表相似性	73.08	4.55	38	67.31	5.82	35	63.27	6.33	31
不必要的子查询	92.31	1.44	12	62.77	10.15	61	100	0.2	1
值歧义	86.22	5.87	49	58.49	5.16	31	58.89	5.71	28
基于 LLM 的错误信号	精确率	召回率	N_m	精确率	召回率	N_m	精确率	召回率	N_m
列歧义	88.69	17.84	149	75.0	3.49	21	50	4.69	23
证据违反	91.24	14.97	125	87.1	4.49	27	82.86	1.22	6
证据不足	82.4	12.34	103	62.07	3.0	18	41.03	3.27	16
LLM 自检	86.71	43.0	339	65.28	7.82	47	58.33	15.71	77
问题子句链接	87	12.34	103	60.71	5.66	34	53.49	4.69	23

表 5：MAC-SQL 上的每个错误信号的错误修正。

信号名称	N_bs	N_text	N_m
基于数据库的信号
异常结果	9	0	4
空谓词	8	1	7
子查询中的错误过滤	9	3	6
错误的 GROUP BY	5	2	3
错误的 JOIN 谓词	5	1	4
次优的 JOIN 树	16	7	9
表歧义	2	1	1
不必要的子查询	6	4	2
值歧义	4	1	3
基于 LLM 的信号
列歧义	4	1	3
证据违反	9	1	8
LLM 自检	10	3	7

个体信号在错误检测中的表现。表 4 显示了 BIRD 上 MAC-SQL、DIN-SQL 和 CHESS 生成的 SQL 查询的个别错误信号的表现。对于 MAC-SQL，14 个信号中有 13 个信号的精确率超过 60%。值得注意的是，异常结果在识别 40 个错误时达到了 100% 的精确率，次优的 JOIN 树检测到了最多错误，尽管精确率为 62%。像空谓词和错误的 JOIN 谓词这样的信号在所有系统中表现一致良好。
相比之下，诸如不必要的子查询和证据不足等信号由于 MAC-SQL 和 CHESS 生成的查询覆盖率较低，表现出较低的精确率和有限的影响。在基于 LLM 的信号中，LLM 自检是最可靠的，与表 2 中的结果一致。

在 MAC-SQL 和 CHESS 中，次优的 JOIN 树的较低精确率源于冗余的 JOIN，这些 JOIN 不影响查询结果，尽管建议的最佳树通常与黄金查询一致。虽然这些 JOIN 不会导致语义错误，但它们会影响执行效率。错误的 JOIN 谓词始终保持超过 90% 的精确率。总体而言，基于数据库的信号比基于 LLM 的信号提供了更好的覆盖范围和精确率。

个体信号在错误修正中的表现。我们使用 MAC-SQL 生成的 SQL 查询评估了个别错误信号的修正效果。对于每个信号，我们将所有标记的查询及其相应的错误报告传递给相关的信号修正器。结果如表 5 所示。在基于数据库的信号中，次优的 JOIN 树以 N_bs=16 和 9 个修正查询的净收益产生了最强的效果。空谓词也表现良好，修正了 8 个查询，仅打破了 1 个查询。对于基于 LLM 的信号，证据违反产生了最高的净收益，修正了 8 个查询。所有信号都产生了正的净修正，突出了 SQLens 错误信号的有用性。

5 结论

我们提出了一种新框架 SQLens，利用数据库和 LLM 基础的错误信号进行文本到 SQL 中的子句级语义错误检测和修正。SQLens 使用弱监督聚合噪声信号，预测查询正确性，并应用 LLM 指导的迭代修正。它在错误检测中优于 LLM 自我评估，并且在不依赖正确性 oracle 的情况下，提高了现成的文本到 SQL 系统的执行准确性高达 20%。

6 局限性

SQLens 在 SQL 错误检测和修正中利用了 LLM，因此继承了底层 LLM 的某些局限性。例如，上下文窗口的限制可能会限制一次传递的错误信息量，一些修正可能超出 LLM 当前的推理能力。在我们对未修正的 SQL 查询的分析中（附录 F.3），我们观察到 SQLens 正确识别了语义错误并提供了适当的指导的情况，但 LLM 无法应用修正。SQLens 在聚合多个信号和执行迭代修正时还会产生计算开销，这在实时设置中可能引入高延迟。然而，SQLens 被设计为离线通用 SQL 调试工具，旨在异步完善和验证生成的查询，而不是部署在对延迟敏感的管道中。

参考文献

[1] Akari Asai, Zeqiu Wu, Yizhong Wang, Avirup Sil, 和 Hannaneh Hajishirzi. Self-rag: Learning to retrieve, generate, and critique through self-reflection. In The Twelfth International Conference on Learning Representations, ICLR 2024, Vienna, Austria, May 7-11, 2024. OpenReview.net, 2024. URL https://openreview.net/forum?id=hSyW5go0v8.
[2] Arian Askari, Christian Poelitz, 和 Xinye Tang. Magic: Generating self-correction guideline for in-context text-to-sql, 2024. URL https://arxiv.org/abs/2406.12692.
[3] AWS. Amazon q generative sql. https://tinyurl.com/yjwcfwmc, 2024. 访问日期：2024-10-17.
[4] BIRD-bench. Bird leaderboard. https://bird-bench.github.io/, 2023. 访问日期：2025-05.
[5] Nik Bear Brown. Enhancing trust in llms: Algorithms for comparing and interpreting llms. arXiv preprint arXiv:2406.01943, 2024.
[6] Shijie Chen, Ziru Chen, Huan Sun, 和 Yu Su. Error detection for text-to-sql semantic parsing. arXiv preprint arXiv:2305.13683, 2023.
[7] Xinyun Chen, Maxwell Lin, Nathanael Schärli, 和 Denny Zhou. Teaching large language models to self-debug, 2023. URL https://arxiv.org/abs/2304.05128.
[8] Ziru Chen, Shijie Chen, Michael White, Raymond Mooney, Ali Payani, Jayanth Srinivasa, Yu Su, 和 Huan Sun. Text-to-sql error correction with language models of code, 2023. URL https://arxiv.org/abs/2305.13073.
[9] Databricks. Databricks assistant. https://tinyurl.com/cdva2bjx, 2023. 访问日期：2024-10-17.
[10] Nick Erickson, Jonas Mueller, Alexander Shirkov, Hang Zhang, Pedro Larroy, Mu Li, 和 Alexander Smola. AutoGluon-Tabular: Robust and Accurate AutoML for Structured Data, March 2020. URL http://arxiv.org/abs/2003.06505. arXiv:2003.06505 [cs, stat].
[11] Avrilia Floratou, Fotis Psallidas, Fuheng Zhao, Shaleen Deep, Gunther Hagleither, Wangda Tan, Joyce Cahoon, Rana Alotaibi, Jordan Henkel, Abhik Singla, Alex Van Grootel, Brandon Chow, Kai Deng, Katherine Lin, Marcos Campos, K. Venkatesh Emani, Vivek Pandit, Victor Shnayder, Wenjing Wang, 和 Carlo Curino. NL2SQL is a solved problem… not! In 14th Conference on Innovative Data Systems Research, CIDR 2024, Chaminade, HI, USA, January 14-17, 2024. www.cidrdb.org, 2024. URL https://www.cidrdb.org/cidr2024/papers/p74-floratou.pdf.
[12] Daniel Fu, Mayee Chen, Frederic Sala, Sarah Hooper, Kayvon Fatahalian, 和 Christopher Re. Fast and three-rious: Speeding up weak supervision with triplet methods. In Hal Daumé III 和 Aarti Singh 编辑，Proceedings of the 37th International Conference on Machine Learning, volume 119 of Proceedings of Machine Learning Research, pages 3280-3291. PMLR, 13-18 Jul 2020. URL https://proceedings.mlr.press/v119/fu20a.html.
[13] Dawei Gao, Haibin Wang, Yaliang Li, Xiuyu Sun, Yichen Qian, Bolin Ding, 和 Jingren Zhou. Text-to-sql empowered by large language models: A benchmark evaluation, 2023. URL https://arxiv.org/abs/2308.15363.
[14] Jiahui Geng, Fengyu Cai, Yuxia Wang, Heinz Koeppl, Preslav Nakov, 和 Iryna Gurevych. A survey of confidence estimation and calibration in large language models. In Kevin Duh, Helena Gomez, 和 Steven Bethard 编辑，Proceedings of the 2024 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies (Volume 1: Long Papers), pages 6577-6595, Mexico City, Mexico, June 2024. Association for Computational Linguistics. doi: 10.18653/v1/2024.naacl-long.366. URL https://aclanthology.org/2024.naacl-long.366.
[15] Zezhou Huang, Pavan Kalyan Damalapati, 和 Eugene Wu. Data ambiguity strikes back: How documentation improves gpt’s text-to-sql, 2023. URL https://arxiv.org/abs/2310.18742.
[16] Pallavi Jayawant 和 Kerry Glavin. Minimum spanning trees. Involve, a Journal of Mathematics, 2(4):439-450, 2009.
[17] Saurav Kadavath, Tom Conerly, Amanda Askell, Tom Henighan, Dawn Drain, Ethan Perez, Nicholas Schiefer, Zac Hatfield-Dodds, Nova DasSarma, Eli Tran-Johnson, Scott Johnston, Sheer El-Showk, Andy Jones, Nelson Elhage, Tristan Hume, Anna Chen, Yuntao Bai, Sam Bowman, Stanislav Fort, Deep Ganguli, Danny Hernandez, Josh Jacobson, Jackson Kernion, Shauna Kravec, Liane Lovitt, Kamal Ndousse, Catherine Olsson, Sam Ringer, Dario Amodei, Tom Brown, Jack Clark, Nicholas Joseph, Ben Mann, Sam McCandlish, Chris Olah, 和 Jared Kaplan. Language Models (Mostly) Know What They Know, November 2022. URL http://arxiv.org/abs/2207.05221. arXiv:2207.05221 [cs].
[18] Tushar Khot, Harsh Trivedi, Matthew Finlayson, Yao Fu, Kyle Richardson, Peter Clark, 和 Ashish Sabharwal. Decomposed prompting: A modular approach for solving complex tasks. arXiv preprint arXiv:2210.02406, 2022.
[19] Joseph B Kruskal. On the shortest spanning subtree of a graph and the traveling salesman problem. Proceedings of the American Mathematical society, 7(1):48-50, 1956.
[20] Dongjun Lee, Choongwon Park, Jaehyuk Kim, 和 Heesoo Park. MCS-SQL: Leveraging Multiple Prompts and Multiple-Choice Selection For Text-to-SQL Generation, May 2024. URL https://arxiv.org/abs/2405.07467v1.
[21] Jinyang Li, Binyuan Hui, Ge Qu, Jiaxi Yang, Binhua Li, Bowen Li, Bailin Wang, Bowen Qin, Rongyu Cao, Ruiying Geng, Nan Huo, Xuanhe Zhou, Chenhao Ma, Guoliang Li, Kevin C. C. Chang, Fei Huang, Reynold Cheng, 和 Yongbin Li. Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs, November 2023. URL http://arxiv.org/abs/2305.03111. arXiv:2305.03111 [cs].
[22] Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, 和 Percy Liang. Lost in the middle: How language models use long contexts, 2023. URL http://arxiv.org/abs/2307.03172.
[23] Peixian Ma, Xialie Zhuang, Chengjin Xu, Xuhui Jiang, Ran Chen, 和 Jian Guo. Sql-r1: Training natural language to sql reasoning model by reinforcement learning, 2025. URL https://arxiv.org/abs/2504.08600.
[24] Xueguang Ma, Xinyu Zhang, Ronak Pradeep, 和 Jimmy Lin. Zero-shot listwise document reranking with a large language model, 2023. URL https://arxiv.org/abs/2305.02156.
[25] Karime Maamari, Fadhil Abubaker, Daniel Jaroslawicz, 和 Amine Mhedhbi. The death of schema linking? text-to-sql in the age of well-reasoned language models, 2024. URL https://arxiv.org/abs/2408.07702.
[26] Raghunath Othayoth Nambiar 和 Meikel Poess. The making of tpc-ds. In VLDB, volume 6, pages 1049-1058, 2006.
[27] Arjun Panickssery, Samuel R. Bowman, 和 Shi Feng. Llm evaluators recognize and favor their own generations, 2024. URL https://arxiv.org/abs/2404.13076.
[28] Liana Patel, Siddharth Jha, Carlos Guestrin, 和 Matei Zaharia. Lotus: Enabling semantic queries with llms over tables of unstructured and structured data. arXiv preprint arXiv:2407.11418, 2024.
[29] Mohammadreza Pourreza 和 Davood Rafiei. DIN-SQL: Decomposed In-Context Learning of Text-to-SQL with Self-Correction, April 2023. URL https://arxiv.org/abs/2304.11015 v 3.
[30] Mohammadreza Pourreza, Hailong Li, Ruoxi Sun, Yeounoh Chung, Shayan Talaei, Gaurav Tarlok Kakkar, Yu Gan, Amin Saberi, Fatma Ozcan, 和 Sercan O. Arik. Chase-sql: Multi-path reasoning and preference optimized candidate selection in text-to-sql, 2024. URL https://arxiv.org/abs/2410.01943.
[31] Mohammadreza Pourreza, Hailong Li, Ruoxi Sun, Yeounoh Chung, Shayan Talaei, Gaurav Tarlok Kakkar, Yu Gan, Amin Saberi, Fatma Ozcan, 和 Sercan O Arik. Chase-sql: Multi-path reasoning and preference optimized candidate selection in text-to-sql. arXiv preprint arXiv:2410.01943, 2024.
[32] Mohammadreza Pourreza, Shayan Talaei, Ruoxi Sun, Xingchen Wan, Hailong Li, Azalia Mirhoseini, Amin Saberi, 和 Sercan O Arik. Reasoning-sql: Reinforcement learning with sql tailored partial rewards for reasoning-enhanced text-to-sql, 2025. URL https://arxiv.org/abs/2503.23157.
[33] Ronak Pradeep, Sahel Sharifymoghaddam, 和 Jimmy Lin. Rankvicuna: Zero-shot listwise document reranking with open-source large language models, 2023. URL https://arxiv.org/abs/2309.15088.
[34] Alexander Ratner, Stephen H. Bach, Henry Ehrenberg, Jason Fries, Sen Wu, 和 Christopher Ré. Snorkel: rapid training data creation with weak supervision. Proceedings of the VLDB Endowment, 11(3):269-282, November 2017. ISSN 2150-8097. doi: 10.14778/3157794.3157797. URL https://dl.acm.org/doi/10.14778/3157794.3157797.
[35] Kurt Shuster, Spencer Poff, Moya Chen, Douwe Kiela, 和 Jason Weston. Retrieval augmentation reduces hallucination in conversation. arXiv preprint arXiv:2104.07567, 2021.
[36] Snowflake. Snowflake copilot. https://tinyurl.com/mtry8z7p, 2024. 访问日期：2024-10-17.
[37] Claudio Spiess, David Gros, Kunal Suresh Pai, Michael Pradel, Md Rafiqul Islam Rabin, Amin Alipour, Susmit Jha, Prem Devanbu, 和 Toufique Ahmed. Calibration and correctness of language models for code, 2024. URL https://arxiv.org/abs/2402.02047.
[38] Weiwei Sun, Lingyong Yan, Xinyu Ma, Shuaiqiang Wang, Pengjie Ren, Zhumin Chen, Dawei Yin, 和 Zhaochun Ren. Is chatgpt good at search? investigating large language models as re-ranking agents, 2023. URL https://arxiv.org/abs/2304.09542.
[39] Shayan Talaei, Mohammadreza Pourreza, Yu-Chen Chang, Azalia Mirhoseini, 和 Amin Saberi. CHESS: Contextual Harnessing for Efficient SQL Synthesis, June 2024. URL http://arxiv.org/abs/2405.16755. arXiv:2405.16755 [cs].
[40] Katherine Tian, Eric Mitchell, Allan Zhou, Archit Sharma, Rafael Rafailov, Huaxiu Yao, Chelsea Finn, 和 Christopher D. Manning. Just Ask for Calibration: Strategies for Eliciting Calibrated Confidence Scores from Language Models Fine-Tuned with Human Feedback, October 2023. URL http://arxiv.org/abs/2305.14975. arXiv:2305.14975 [cs].
[41] Alexander van Renen, Dominik Horn, Pascal Pfeil, Kapil Eknath Vaidya, Wenjian Dong, Murali Narayanaswamy, Zhengchun Liu, Gaurav Saxena, Andreas Kipf, 和 Tim Kraska. Why tpc is not enough: An analysis of the amazon redshift fleet. In VLDB 2024, 2024. URL https://www.amazon.science/publications/why-tpc-is-not-enough-an-analysis-of-the-amazon-redshift-fleet.
[42] Bing Wang, Yan Gao, Zhoujun Li, 和 Jian-Guang Lou. Know what i don’t know: Handling ambiguous and unknown questions for text-to-sql. In Anna Rogers, Jordan Boyd-Graber, 和 Naoaki Okazaki 编辑，Findings of the Association for Computational Linguistics: ACL 2023, pages 5701-5714, Toronto, Canada, July 2023. Association for Computational Linguistics. doi: 10.18653/v1/2023.findings-acl.352. URL https://aclanthology.org/2023.findings-acl.352.
[43] Bing Wang, Changyu Ren, Jian Yang, Xinnian Liang, Jiaqi Bai, Linzheng Chai, Zhao Yan, Qian-Wen Zhang, Di Yin, Xing Sun, 和 Zhoujun Li. MAC-SQL: A Multi-Agent Collaborative Framework for Text-to-SQL, June 2024. URL http://arxiv.org/abs/2312.11242. arXiv:2312.11242 [cs].
[44] Lei Wang, Chen Ma, Xueyang Feng, Zeyu Zhang, Hao Yang, Jingsen Zhang, Zhiyuan Chen, Jiakai Tang, Xu Chen, Yankai Lin, 等。大型语言模型自主代理调查。计算机科学前沿，18(6):186345，2024。
[45] Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Fei Xia, Ed Chi, Quoc V Le, Denny Zhou 等。思维链提示在大型语言模型中激发推理。神经信息处理系统进展，35:24824-24837，2022。
[46] Zhuofeng Wu, He Bai, Aonan Zhang, Jiatao Gu, VG Vinod Vydiswaran, Navdeep Jaitly, Yizhe Zhang。分解或征服？你应该提炼你的 LLM 的哪一部分？2024。URL https://arxiv.org/abs/2402.15000。
[47] Wenda Xu, Guanglei Zhu, Xuandong Zhao, Liangming Pan, Lei Li, William Wang。自豪与偏见：LLM 放大自修中的自我偏见。In Lun-Wei Ku, Andre Martins, 和 Vivek Srikumar 编辑，第 62 届计算语言学协会年会论文集（第一卷：长篇论文），15474-15492 页，泰国曼谷，2024 年 8 月。计算语言学协会。doi: 10.18653/v1/2024.acl-long.826。URL https://aclanthology.org/2024.acl-long.826。
[48] Ziyu Yao, Yu Su, Huan Sun, 和 Wen-tau Yih。基于模型的交互式语义解析：统一公式和文本到 SQL 案例研究。In EMNLP’19，2019。
[49] Ziyu Yao, Yiqi Tang, Wen-tau Yih, Huan Sun, 和 Yu Su。通过用户交互学习语义解析器的模仿游戏。arXiv 预印本 arXiv:2005.00689，2020。
[50] Tao Yu, Rui Zhang, Kai Yang, Michihiro Yasunaga, Dongxu Wang, Zifan Li, James Ma, Irene Li, Qingning Yao, Shanelle Roman, Zilin Zhang, 和 Dragomir Radev。Spider：大规模人工标注的复杂和跨领域语义解析和文本到 SQL 任务数据集。In Ellen Riloff, David Chiang, Julia Hockenmaier, 和 Jun’ichi Tsujii 编辑，EMNLP 2018 会议论文集，3911-3921 页，比利时布鲁塞尔，2018 年 10 月。计算语言学协会。doi: 10.18653/v1/D18-1425。URL https://aclanthology.org/D18-1425。
[51] Jichuan Zeng, Xi Victoria Lin, Caiming Xiong, Richard Socher, Michael R Lyu, Irwin King, 和 Steven CH Hoi。Photon：一个鲁棒的跨领域文本到 SQL 系统。arXiv 预印本 arXiv:2007.15280，2020。

A SQLens 使用案例

图 6 显示了一个文本到 SQL 的解决方案，为给定的 NL 问题生成 SQL 查询。尽管生成的查询没有语法错误，但用户执行该查询后发现其产生空结果，表明查询不正确。在当前的文本到 SQL 助手 [3,9,36] 中，用户必须投入大量时间手动调试查询中的语义错误。我们的目标是为用户提供一个调试 SQL 功能，该功能自动对该查询进行深度语义分析，识别 FROM 子句中的错误连接谓词或 WHERE 子句中提供的外部知识的错误使用等错误。接下来是一个自动生成更新后的 SQL 查询的过程，供用户验证。使用调试 SQL，用户在查询故障排除中的手动工作量显著减少，从而建立了对文本到 SQL 助手的信任。

图 6：文本到 SQL 调试用例。

B 基于数据库的错误信号

以下信号检测语义不一致，当 LLM 错误解释问题或错误使用数据时发生。

• 次优连接树信号目标 FROM 和 JOIN 子句，检查 SQL 查询是否使用最优连接树连接回答 NL 问题所需的表。虽然查询优化器可以消除不影响查询结果的冗余表，但 LLM 可能生成不必要的复杂连接树，可能导致错误结果。让 ${\mathcal{D}}_{req}\subseteq \mathcal{D}$ 表示回答问题所需的表。最优连接树是跨越 ${\mathcal{D}}_{req}$ 的最小 Steiner 树 $T^{\ast }$ [16]。如果查询包含 ${\mathcal{D}}_{req}$ 以外的额外表，则标记次优连接树信号。例如，图 7（右）显示连接表 $A$ 和 $C$ 的最优连接树。SQLEnS 识别不在 JOIN 子句中的列为 ${\mathcal{D}}_{req}$，并使用 Kruskal 箱 [19] 在预建的连接图上找到最小 Steiner 树。如果查询涉及的表多于最小 Steiner 树所需，就标记次优连接树信号。当存在多个有效连接树时，可能会出现假阳性。

• 
  图 7：跨越 $A$ 和 $C$ 的 Steiner 树
  为了实现此信号，SQLEnS 首先识别 SQL 查询中不参与 Join 子句的列。根据这些列，SQLEnS 搜索预建的连接图上的最小 Steiner 树以连接相关表。如果 SQL 查询涉及的表多于最小 Steiner 树所需的表，SQLEnS 会标记次优连接树标志。当次优连接策略不影响 SQL 查询的正确性时，此信号可能会产生假阳性。例如，如果查询要求特定商店的总销售额，可以直接从 store_sales 表中选择 sales 列。但是，如果查询不必要地将 store_sales 表与 store_location 表连接，即使 store_location 表不需要获得正确的销售数据，结果仍然正确，但连接次优。

• 错误连接谓词信号检查 SQL 查询是否使用无效的连接谓词。例如，在图 2 中，预测的 SQL 错误地将 client_id 与 account_id 连接，这在相应的模式图中不存在。为了实现此信号，SQLEnS 首先从 SQL 查询中提取所有连接谓词。然后识别两种正确的连接谓词：(1) 使用数据库模式中明确定义的主键-外键 (PK/FK) 连接，(2) 派生自 PK/FK 连接。具体来说，如果两列 $C_i$ 和 $C_j$ 都引用同一主键 $C_k$（即，它们指代同一实体），则 $C_i$ 和 $C_j$ 可以用于连接谓词。当 PK/FK 关系未在数据库中充分记录时，此信号可能会产生假阳性。

• • 空谓词信号检测 SQL 查询中是否存在产生空结果的谓词。此信号用于检测语义不一致错误，包括错误列选择、错误值使用或错误比较运算符。SQLEnS 从给定 SQL 中提取所有列与字面值的比较，分别执行它们并记录输出大小。如果有产生空行的谓词，则标记此信号。当空谓词是有意为之时，此信号可能产生假阳性。
• • 异常结果信号检测 SQL 是否输出不提供太多信息的异常结果。SQLEnS 执行 SQL 并记录其输出。输出被认为是异常的，如果（1）它是空的，（2）它包含全零的列，或（3）它包含全 NULL 的列。此信号超越了空谓词，评估整个 SQL 输出。除了检测空谓词，它还可以识别空的中间执行结果，使其在捕捉 SQL 查询中间步骤中的语义不一致时有效。当异常结果是有意为之时，此信号可能会错误标记 SQL 查询，尽管这种情况在实践中很少见。
• • 子查询中的错误过滤信号检测子查询中的问题过滤。子查询中的过滤器通常遵循 column $=($ SELECT…) 的模式。当子查询返回多行时，

• 表 6：基于数据库的错误信号。
  | 信号名称 | 错误 SQL 查询 | 正确 SQL 查询 | SQL 子句 |
  | :–: | :–: | :–: | :–: |
  | 异常结果 | SELECT c.id FROM cards c WHERE c.cardKingdondVolld = c.cardKingdondd AND c.cardKingdondd IS NOT NULL AND c.haeVol = 1 AND c.isFullArt = 0 AND c.isPromo $=0$ AND c.isOvervised $=0$; 输出大小：0 | SELECT id FROM cards WHERE cardKingdondVolld IS NOT NULL AND cardKingdondd IS NOT NULL;
  输出大小：25061 | WHERE |
  | 空
  谓词 | SELECT c.atom_id, c.atom_id2 FROM connected c JOIN bond b ON c.bond_id $=$ b.bond_id WHERE b.bond_id = ‘TR_000_2_5’; | SELECT Y.atom_id FROM connected AS Y WHERE Y.bond_id = ‘TR000_2_5’; | WHERE |
  | 子查询中的错误过滤 | SELECT Name FROM badges WHERE UserId =
  ( SELECT Id FROM users
  WHERE DisplayName = ‘Pierre’ ); | SELECT Name FROM badges WHERE UserId IN ( SELECT Id FROM users
  | SUBQUERY |
  | 错误的 GROUP BY | SELECT s.City, f.Enrollment (K-12)
  FROM 6pns f JOIN schools s
  ON f.CDSCode $=$ s.CDSCode
  GROUP BY s.City, f.’ Enrollment (K-12)’ ORDER BY SUMt: ‘Enrollment (K-12)’; ASC LIMIT 5; | SELECT T2.City FROM 6pns AS T1
  INNER JOIN schools AS T2
  ON T1.CDSCode $=$ T2.CDSCode
  GROUP BY T2.City
  ORDER BY SUMtT1:‘Enrollment (K-12)’; ASC LIMIT 5; | GROUP BY |
  | 错误的 Join 谓词 | SELECT (SELECT COUNT(DISTINCT client.client_id) FROM client INNER JOIN account ON client.client_id = account.account_id INNER JOIN district ON account.district_id = district.district_id WHERE district.a2 = ‘Jesenik’ AND client.gender $=$ ’ $F$ '; AS num_female_clients; | SELECT COUNT(T1.client_id) FROM client AS T1 INNER JOIN district AS T2 ON T1.district_id $=$ T2.district_id WHERE T1.gender $=$ ’ $F$ ’ AND T2.A2 = ‘Jesenik’; | JOIN |
  | 次优 Join 树 | SELECT d.a3 FROM client c JOIN disp di ON c.client_id = di.client_id JOIN account s ON di.account_id = s.account_id JOIN district d ON s.district_id WHERE c.client_id = 3541 LIMIT 1; | SELECT T1.a3 FROM district T1
  INNER JOIN client T2
  ON T1.district_id $=$ T2.district_id
  WHERE T2.client_id $=3541$; | FROM
  JOIN |
  | 表相似性 | SELECT AVGo (points) AS avg_score
  FROM results r JOIN drivers d ON r.driverld $=$ d.driverld JOIN races ra ON r.raceld $=$ ra.raceld
  WHERE d.formance $=$ ‘Lewis’ AND d.surname $=$ ‘Hamilton’ AND ra.raceld IN ( SELECT raceld FROM races WHERE name LIKE ‘%Turkish Grand Prix%’ ); | SELECT AVGoT2.points FROM drivers AS T1
  INNER JOIN driverStandings AS T2
  ON T1.driverld $=$ T2.driverld
  WHERE dOIN races AS T3 ON T3.raceld $=$ T2.raceld
  WHERE T1.formance $=$ ‘Lewis’ AND T1.surname $=$ ‘Hamilton’ AND T3.name $=$ ‘Turkish Grand Prix’ | SELECT
  FROM |
  | 不必要的子查询 | SELECT (SELECT c.name FROM cards c WHERE c.mid = (SELECT smid FROM rulings) AS card_name;
  (SELECT c.ation FROM cards c WHERE c.mid = (SELECT smid FROM rulings) AS artist,
  (SELECT c.syprons FROM cards c WHERE c.mid = (SELECT smid FROM rulings) AS is_promo; | SELECT T1.name, T1.artist, T1.isPromo
  FROM cards AS T1 INNER JOIN rulings AS T2
  ON T1.msid $=$ T2.msid WHERE T1.isPromo $=1$
  GROUP BY T1.artist ORDER BY
  COUNT(DISTINCT T1.mid) DESC LIMIT 1 | SUBQUERY |
  | 值歧义 | SELECT c ‘artist’ FROM ‘cards’ c JOIN ‘foreign_data’ f ON c ‘mid’ $=$ f ‘mid’ WHERE c ‘watermark’ $=$ ‘phyrexian’ AND c ‘artist’ IS NOT NULL GROUP BY c ‘artist’; | SELECT T1.artist FROM cards AS T1
  INNER JOIN foreign_data AS T2
  ON T1.msid $=$ T2.msid
  WHERE T2.language $=$ ‘Phyrexian’; | SELECT
  WHERE |

过滤条件变得模糊（例如 IN 或 ’ $=$ '），这可能导致错误。SQLens 使用正则表达式匹配此模式并单独执行提取的子查询。如果它返回多于一行，则标记该信号。此外，SQLite 对 SQL 语义比较宽容，允许 column $=($ SELECT… $)$ 只匹配子查询返回的第一个值。虽然当第一个值恰好是所需值时查询可能仍然正确，但依赖这种行为通常被认为是 SQL 编写中的不良实践。

• 错误的 GROUP BY 信号检测任何没有伴随 Max、Count 等聚合函数的独立 Group By 子句。误用 Group By 子句可以改变 SQL 的语义并导致不正确的结果。在 SQLite 中，独立的 GROUP BY 的行为与 DISTINCT 运算符相同。即使在使用 GROUP BY 作为 DISTINCT 替代时查询可能仍然正确，这种方法通常也被认为是不良实践。

• • 不必要的子查询信号表示 SQL 查询中是否过度使用了子查询，这会导致效率低下、复杂度增加和错误的可能性更高。此信号计算 SQL 查询中的子查询数量，并在计数超过指定阈值时将其标记为问题。在我们的评估中，这个阈值设置为 3 。当子查询对于性能优化或特定逻辑是必要时，可能会出现假阳性，即使它们超过了阈值。
    以下信号旨在捕捉数据中的固有歧义。

• 值歧义信号检测 NL 问题中使用的值出现在多个列中的情况下的错误列选择。例如，“New York”可以同时出现在“state”和“city”列中。为了识别歧义值，该信号提取 SQL 中使用的所有值，并通过离线构建的倒排索引找到包含所用值的列。如果存在更接近问题语义的替代列，则将相应的值标记为歧义。可能存在这样的情况：SQL 中最初选择的列是正确的，但由于语义距离不一定能准确确定哪个包含值的列最适合回答问题，系统会错误地将可能的错误标记出来。
  表 7：基于 LLM 的错误信号。

信号名称	错误 SQL 查询	正确 SQL 查询	SQL 子句
列 歧义	SELECT x.School, x.Steeni.khr FROM sateconte sat JOIN schools x ON sat.cds $\to$ x.CDSCode ORDER BY sat.ArgScrMath DESC LIMIT 1 OFFSET 5;	SELECT T2.MailStreet, T2.School FROM sateconte AS T1 INNER JOIN schools AS T2 ON T1.cds = T2.CDSCode ORDER BY T1.ArgScrMath DESC LIMIT 5, 1;	SELECT
证据 违反	证据：带有 “Angel of Mercy” 的集合 是指 name = ‘Angel of Mercy’ SELECT COUNT(*) FROM set_translations WHERE setCode = ‘UNH’;	SELECT COUNT(DISTINCT translation) FROM set_translations WHERE setCode IN ( SELECT setCode FROM cards WHERE name = ‘Angel of Mercy’) AND translation IS NOT NULL;	任何子句 由 LLM 识别
证据 不足	Q: 单键分子中有多少碘和硫元素的原子？ 证据：含碘元素指的是 element $={\gamma }^{\prime }$； 含硫元素指的是 element $={\gamma }^{\prime }$； 单键类型指的是 bond_type $={\gamma }^{\prime }$；	SELECT COUNT(DISTINCT CASE WHEN T1.element $={\gamma }^{\prime }$ THEN T1.atom_id ELSE NULL END) AS iodine_nums, COUNT(DISTINCT CASE WHEN T1.element $={\gamma }^{\prime }$ THEN T1.atom_id ELSE NULL END) AS sulfur_nums FROM atom AS T1 INNER JOIN connected AS T2 ON T1.atom_id = T2.atom_id INNER JOIN bond AS T3 ON T2.bond_id = T3.bond_id WHERE T3.bond_type $={\gamma }^{\prime }$;	任何子句 由 LLM 识别
错误的问题 子句链接	Q: 列出身高高于 180 的前 10 名球员的名字，按平均头球准确性降序排列。 SELECT p.player_name FROM Player p.JOIN Player_Attribute pa ON p.player_api_id = pa.player_api_id WHERE p.height $>180$ ORDER BY pa.heading_accuracy DESC LIMIT 10;	SELECT t1.player_name FROM Player AS t1 INNER JOIN Player_Attributes AS t2 ON t1.player_api_id = t2.player_api_id WHERE t1.height $>180$ GROUP BY t1.id ORDER BY CAST(SUM(t2.heading_accuracy) AS REAL) ( COUNT(t2=player_fea_api_id) DESC LIMIT 10;	任何子句 由 LLM 识别
LLM 自检	SELECT p.Paragraph_Text FROM Paragraphs p JOIN Documents d ON p.Document_ID = d.Document_ID WHERE d.Document_Name = ‘Welcome to NY’;	SELECT T1.paragraph_text FROM Paragraphs AS T1 JOIN Documents AS T2 ON T1.document_id $<$ T2.document_id WHERE T2.document_name $=$ ‘Customer reviews’;	任何子句 由 LLM 识别

原始 SQL 中选择的列可能是正确的，因为语义距离并不总能准确判断哪个包含值的列最适合回答问题。

• 表相似性信号通过识别具有相似结构的替代表来检测表选择中的潜在错误。它提取 SQL 中使用的所有列，按表对列进行分组，并搜索包含相同列组的其他表。如果发现这样的表，表明替代表可能被使用，指示原始选择的表可能存在错误。当所选表实际上正确但存在另一个结构相似的表时，可能会出现假阳性，导致系统错误地标记可能的错误。
  在表 6 中，我们展示了基于实际应用中的 NL 问题的错误和正确 SQL 查询对的例子，突出了每个信号针对的具体 SQL 子句。

C 基于 LLM 的错误信号

• 证据违反信号识别生成的 SQL 查询与问题或外部知识提供的证据相矛盾的情况。例如，如果问题指定只检索关于在职员工的行，但 SQL 查询未包括过滤掉非在职员工的条件，就会触发证据违反。SQLens 所使用的提示可在附录 D.2 中找到。
• • 证据不足信号评估现有证据是否足以确认 SQL 查询正确回答用户问题。例如，如果问题缺乏对领域特定概念的明确解释，LLM 容易产生幻觉。此信号本质上验证 LLM 是否拥有提供正确响应所需的信息和上下文。提示见附录 D.3。
• • 错误问题子句链接信号评估 LLM 对生成的 SQL 子句的信心。此信号首先提示 LLM 将用户问题中的概念、实体和表达映射到 SQL 查询中的相应子句。对于每个识别的链接，LLM 然后被要求通过简单的是或否回答来表明其对生成的子句的信心。当至少有一个子句信心较低时，该信号被标记。提示可以在附录 D.4 中找到。
• • 列歧义信号识别数据库中是否存在与 SQL 查询中使用的列非常相似且也可以用来回答用户问题的列。此信号表明 SQL 易于选择错误的列。此信号的提示在附录 D.5 中共享。
• 上述信号为 LLM 提供了具体的错误原因以进行检测。鉴于研究表明 LLM 具备验证自己答案的能力 [17, 40]，我们还引入了一个信号，提示 LLM 提供对其输出的整体评估。
• LLM 自检询问一个 LLM，根据数据库和任何可用的外部知识，提出 SQL 是否正确回答了用户的问题。提示可以在附录 D.6 和 D.7 中找到。
  信号示例在表 7 中列出。当 LLM 误解问题、对指定知识的理解有限、产生幻觉或评估自己的输出时表现出偏见时，基于 LLM 的信号可能会产生假阳性。

D 提示

D.1 Vanilla Text-to-SQL 的提示

角色：您是一位专家级 SQL 数据库管理员，负责编写精确的 SQL 查询以解决用户问题。
背景信息：您将获得以下信息：

1. 一个 SQLite 数据库模式
2. 2. 用户的问题
3. 3. 与用户问题相关的证据
4. 数据库模式：
5. • 包括表描述
6. • 每个表包含多个列描述
7. • 提供每列的频繁值
8. 您的任务：
9. 1. 仔细分析用户问题、证据和数据库模式。
      10.2. 编写一个正确回答用户问题的 SQL 查询
      请使用以下格式化方式格式化您的 SQL 查询：
      sql
      您的 SQL 查询在这里

[问题]
{问题}
[证据]
{证据}
[数据库信息]
{db_desc_str}
回答

D.2 证据违反的提示

您将收到一个用户问题和一个解决用户问题的提议 SQL 查询。您的任务是确定提议的 SQL 查询是否反映了问题中指定的所有证据。
以下是典型示例：
==== 示例 ====
问题] 有多少用户获得了超过 5 个徽章？超过 5 个徽章指的是 Count (Name) > 5；用户指的是 UserId

[SQL 查询] SELECT UserId FROM ( SELECT UserId, COUNT(DISTINCT Name) AS num FROM

徽章 GROUP BY UserId ) T WHERE T.num > 6;
回答:
json
{{
“violates_evidence”: true
“explanation”: "此 SQL 查询违反了问题中的证据，因为它
~ 计算了超过 6 个徽章的用户数量，而不是超过 5 个徽章。
~ 此外，它使用 COUNT(DISTINCT Name) 而不是问题中指定的 COUNT(Name)。
}}

问题已解决。确保生成有效的 JSON 回复。
$============$
以下是新示例，请开始回答：
[问题] {问题}。{证据}
[SQL 查询] {sql_query}
回答

D.3 证据不足的提示

您将收到一个 SQLite 数据库模式、一个用户问题和一个解决用户问题的提议 SQL 查询。您的任务是确定是否有足够的证据来判断 SQL 是否正确回答了用户问题。
按照以下格式输出 JSON 对象。确保生成有效的 JSON 回复。
回答
json
{{
“insufficient_evidence”: true/false
“explanation”: “为什么证据不足”
}}

问题已解决。
$============$
以下是新示例，请开始回答：
[问题] {问题}。{证据}
{db_desc_str}
[SQL 查询]
{sql_query}
回答

D.4 问题-子句链接提示

您将获得一个 SQLite 数据库模式、一个用户问题以及一个旨在解决用户问题的提议 SQL 查询。请遵循以下步骤：

1. 将用户问题中的概念、实体和表达与 SQL 查询中的相应子句联系起来。
2. 对于您识别的每个链接，通过回答“是”或“否”来表明您是否对该生成的子句有信心。
3. 按照以下格式输出 JSON 对象。确保生成有效的 JSON 回复。
4. 回答
5. ’ 'json
6. {{

7. "<(问题中的实体, 相应的 SQL 子句)>": "<yes/no>"
   

8. }}

・
请开始回答以下问题：
[问题] {问题}。{证据}.
{db_desc_str}
[SQL 查询] {sql_query}
回答

D.5 列歧义提示

作为一名经验丰富且专业的数据库管理员，您将获得一个

SQLite 数据库模式、一个用户问题以及一个旨在解决用户问题的提议 SQL 查询。数据库模式由表描述组成，

每个表包含多个列描述。
您的任务是确定数据库中是否存在与 SQL 查询中使用的列非常相似且也可用于回答用户问题的列。
这是一个典型的例子：
==== 示例 ====
[问题] 哪些州特殊学校有从1到12年级注册人数最多的？

州特殊学校指的是 DOC = 31；1到12年级指的是 K-12
[DB_ID]california_schools
[数据库模式]

表: frpm

[
(CDSCode, CDSCode.),
(Enrollment (K-12), Enrollment (K-12).),
]
# 表: satscores
[
(cds, cds. 列描述：加利福尼亚州教育部学校),
(sname, 学校名称。值示例: [None, ‘Middle College High’, ‘John F.
~ Kennedy High’, ‘Independence High’, ‘Foothill High’, ‘Washington High’,
~ ‘Redwood High’].),
(enroll12, 注册人数 (1至12年级).),
]
# 表: schools
[
(CDSCode, CDSCode.),
(DOC, District Ownership Code. 值示例: [‘54’, ‘52’, ‘00’, ‘56’, ‘98’,
~ ‘02’].),
]

[SQL 查询] SELECT T2.sname FROM schools AS T1 INNER JOIN satscores AS T2 ON
\ T1.CDSCode = T2.cds WHERE T1.DOC = ‘31’ AND T2.enroll12 IS NOT NULL ORDER BY
\ T2.enroll12 DESC LIMIT 1;
回答
json
[[ “alternative_column”: true
“explanation”: “frpm.Enrollment (K-12) 也可用于确定从1到12年级的注册人数。这一列与提议 SQL 中使用的 satscores.enroll12 非常相似。”
}}

问题已解决。确保生成有效的 JSON 回复。
$============$
请开始回答以下问题。
[问题] {问题}。{证据}
{db_desc_str}
[SQL 查询] {sql_query}
回答

D.6 LLM 自检提示 (真/假)

您将收到一个 SQLite 数据库模式、一个用户问题和一个旨在解决用户问题的提议 SQL 查询。您的任务是确定提议的 SQL 查询是否正确回答了用户问题。您的答案应该是一个包含两个键 “correct” 和

“explanation” 的 JSON 对象。仅当 SQL 不正确时才提供解释。
您需要按照以下格式生成答案:
回答:
json
{{ “correct”: false,
“explanation”: “SQL 不正确的解释”
}}
确保生成有效的 JSON 回复。
请开始回答以下问题:
[问题]
{问题}. {证据}
[数据库信息]
{db_desc_str}
[SQL 查询]
{sql_query}
回答

D.7 LLM 自检提示（概率）

您将收到一个用户问题、一个 SQLite 数据库模式和一个旨在解决用户问题的提议 SQL 查询。
$\sim$ 你的任务是评估提议的 SQL 查询并提供它正确回答用户问题的概率。

请将此概率作为一个介于 0 和 1 之间的十进制数字提供。
你需要按照以下格式生成答案：

" “probability”: <介于 0.0 和 1.0 之间，表示 SQL 正确回答问题的概率>

・。
确保生成有效的 JSON 回复。
$=======================$
请开始回答以下问题：
[问题]
{问题}. {证据}
[数据库信息]
{db_desc_str}
[SQL 查询]
{sql_query}
回答

D.8 SQL 查询修正提示

角色：您是一名经验丰富的专业数据库管理员，任务是分析和修正可能错误的 SQL 查询。
$\sim$ 背景：您将获得以下信息：

1. 一个 SQLite 数据库模式

2. 2. 一个用户问题
3. 3. 一个旨在回答用户问题的提议 SQL 查询。
4. 4. 一个提议 SQL 查询的错误报告。错误报告建议 SQL 中的潜在错误。

5. 数据库模式：

6. • 包括表描述
7. • 每个表包含多个列描述
8. • 提供每列的频繁值
     您的任务：

9. 分析错误报告
   10.2. 确定 SQL 查询是否需要修正。如果查询正确，您可以选择不修改 SQL。

10. 如果提议的 SQL 不正确，生成一个正确的 SQL 查询以回答用户问题

说明：

11. 仔细审查提供的信息
    12.2. 在代码块中使用 SQL 格式
12. 解释您的推理过程和所做的任何更改
    13.4. 避免使用过于复杂的查询。例如，…EXISTS(SELECT 1 FROM table WHERE condition) 可以替换为 JOIN。
    [问题]
    {问题}
    [证据]

{证据}
[数据库信息]
{db_desc}
[旧 SQL]
’ ’ sql
{old_sql}
[错误报告]
{error_report}
现在，请分析错误报告，决定是否需要修正 SQL 并生成一个正确的 SQL 来回答用户问题，如果您认为提议的 SQL 确实错误。
[修正后的 SQL]

E SQLens 错误修正伪代码

算法 1：SQLens 错误修正
输入：ctx: 修正上下文，包括数据库、外部知识和自然语言问题；
q: 原始 SQL 查询；S: 错误信号集；max_iter: 最大迭代次数；
eg: 护栏信号
输出：修正后的 SQL 查询，q’
E ← ErrorDetector(ctx, q, S)
i ← 0
q’ ← q
while |E| > 0 或 i < max_iter do
/* 选择当前最关键错误 /
e ← ErrorSelector(ctx, E)
q’ ← ErrorFixer(ctx, e, q’)
/ 移除之前已经修正的错误信号 /
S ← S \ {e}
E ← ErrorDetector(ctx, q’, S)
i ← i + 1
end
/ 如果检测到修正护栏信号 */
if |ErrorDetector(ctx, {eg})| = 1 then
q’ ← ErrroFixer(ctx, eg, q’)
end
q’ ← SQLAuditor(ctx, q’, q)
return q’

算法 1 展示了错误修正的伪代码。本质上，SQLEnS 的错误修正是一种贪婪的顺序算法。原始 SQL 查询首先由 SQLens 的错误检测器处理，该检测器在输入查询上评估给定的信号集并生成检测到的信号的错误报告列表（第 1 行）。在实践中，用户可以选择一组信号来修正查询，基于这些信号在开发数据集上检测错误的精度。然后将这些报告发送到错误选择器，错误选择器识别出当前迭代要解决的最关键错误（第 5 行）。
错误选择器组件输入原始 SQL 查询、数据库模式和按置信度排序的错误报告列表，然后使用 LLM 确定要首先解决的最关键错误。实质上，LLM 根据其对这些错误报告与原始 SQL 的相关性的理解调整这些错误报告的排名 [38, 24, 33]。一旦识别出最关键错误，下一步是使用该信号提供的错误信息修正查询，由错误修正器处理（第 6 行）。
表 8：现成的文本到 SQL 系统生成的 SQL 查询统计。

方法	数据集	准确率 1 ${}^1$	准确率 2 ${}^2$	# SQLs	# 错误	# 语义错误
Vanilla	BIRD	55.41	59.07	1534	684	589
DINSQL	BIRD	35.53	39.49	1534	989	835
MACSQL	BIRD	58.87	60.04	1534	631	601
CHESS	BIRD	67.60	67.91	1534	497	490
Vanilla	Spider	79.11	79.65	1034	216	209
DINSQL	Spider	76.31	77.66	1034	245	227
MACSQL	Spider	78.92	79.69	1034	218	208

${}^1$ 所有查询的准确率 ${}^2$ 没有语法错误的查询的准确率

错误修正组件接收原始 SQL 查询和特定错误报告以及修正上下文（如算法 1 所述）作为输入。它分析错误，确定如何修正查询，并生成新的查询。为了避免修订过程中引入语法错误，我们在错误修正器中包含了一个语法检查器，该检查器使用 SQL 解析器验证语法。如果有任何语法错误，错误修正器使用解析器的错误消息迭代地修改 SQL 查询，直到其有效。请注意，SQLens 通过在使用后从信号集合中删除错误信号来避免重复修正相同的错误（第 7 行）。一旦修正了当前错误，我们就在修订后的 SQL 查询上运行错误检测器。如果它不包含进一步的错误，则返回修正后的 SQL 查询。否则，修正过程迭代进行，直到所有错误都得到解决或达到最大迭代次数（第 4-10 行）。
以上过程生成了修订后的 SQL 查询，但它可能仍包含需要修正的一些错误。为了确保修正最关键错误，我们引入了最终检查以识别是否需要进一步调整。在检测错误的 SQL 查询中具有最高精度的信号可以配置为“护栏信号”以捕获和修正剩余错误（第 11-13 行）。如前所述，修订过程可能会破坏原本正确的 SQL 查询。为了解决这个问题，原始 SQL 和最终修订的 SQL 被传递给基于 LLM 的 SQL 审核员进行最终评估（第 14 行）。

F 附加实验评估

表 8 展示了 BIRD 和 Spider 上基础 SQL 生成器的文本到 SQL 性能。

F.1 Spider 上的端到端评估

表 9 展示了在 Spider 基准上的端到端评估结果。在净改进方面，SQLens 分别在 MAC-SQL、DIN-SQL 和 Vanilla 提示上比自我反思多修正了 10、20 和 9 个 SQL 查询。与基线相比，SQLens 修正了更多的 SQL 查询（N_fix）。它的表现与其变体 Fix-ALL 类似，SQLens 在 MACSQL 上多修正了 2 个 SQL 查询，在其他两种方法上几乎修正了相同数量。然而，SQLens 比 Fix-ALL 产生了更多回归。这是因为错误信号在 Spider 上的准确率低于 BIRD，导致 SQLens 触发了更多修正，从而产生了更多回归。

F.2 Spider 上的错误检测

在 Spider 基准上，我们观察到了类似的结果，SQLens 在召回率和 F1 分数上优于 LLM 自我评估方法（表 10）。一个显著的观察是，LLM 自我评估往往对生成的 SQL 查询过于自信，导致识别错误查询的召回率低。例如，LLM 自我评估（Prob）仅识别出 MAC-SQL 生成的错误 SQL 查询的 5.16%。Spider 上的整体 F1 分数低于 BIRD，因为在 Spider 上文本到 SQL 算法已经达到约 80% 的准确率，这明显高于 BIRD。这创造了一个更具挑战性的场景，因为大多数剩余错误属于长尾分布。
表 9：Spider 上的端到端准确率提升。

方法	Δ Acc. (N_net)	Δ Acc. (N_fix)	N_net	N_fix	N_break
Vanilla (初始准确率 =79.65%) ; 输入 SQL 数量 =1027
自我反思	80.14(+0.49%)	80.72(+1.07%)	5	11	6
SQLens w. Fix-ALL	81.11 (+1.46%)	81.4(+1.75%)	15	18	3
SQLens	81.11 (+1.46%)	81.5(+1.85%)	15	19	4
DIN-SQL (初始准确率 =77.66%) ; 输入 SQL 数量 =1016
自我反思	80.51(+2.85%)	81.1(+3.44%)	29	35	6
SQLens w. Fix-ALL	82.58 (+4.92%)	82.88(+5.22%)	50	53	3
SQLens	82.48(+4.82%)	83.27(+5.61%)	49	57	8
MAC-SQL (初始准确率 =79.69%) ; 输入 SQL 数量 =1024
自我反思	81.06(+1.37%)	81.45(+1.76%)	14	18	4
SQLens w. Fix-ALL	81.74(+2.05%)	82.03(+2.34%)	21	24	3
SQLens	81.93 (+2.24%)	82.23(+2.54%)	23	26	3

x 表示分类不是基于阈值的。
† 最佳结果。前两名结果加粗。

表 10：Spider 上 SQLENS 错误检测的有效性。

方法	准确率	AUC	精确率	召回率	F1
Vanilla
LLM 自我评估 (Bool)	74.39(±3.12)	x	21.59(±13.00)	9.13(±5.21)	12.77(±7.42)
LLM 自我评估 (Prob)	77.41(±1.43)	57.42(±1.30)	13.33(±17.78)	2.90(±3.89)	4.77(±6.38)
监督 SQLENS	80.72†(±1.06)	61.02†(±3.28)	75.79†(±17.24)	10.56(±4.53)	17.79(±6.62)
SQLENS	74.49(±4.86)	59.49(±5.91)	34.91(±14.18)	29.22†(±11.61)	31.76†(±12.75)
DIN-SQL
LLM 自我评估 (Bool)	75.69(±2.46)	x	40.38(±11.33)	16.78(±4.24)	23.64(±6.01)
LLM 自我评估 (Prob)	76.58(±1.23)	58.60(±1.78)	41.07(±17.97)	5.73(±2.23)	9.90(±3.72)
监督 SQLENS	82.48†(±2.27)	67.89†(±3.66)	73.68†(±7.45)	33.57(±9.14)	45.51(±9.91)
SQLENS	76.38(±2.75)	67.14(±4.30)	47.18(±5.76)	48.09†(±6.91)	47.59†(±6.17)
MAC-SQL
LLM 自我评估 (Bool)	76.85(±1.60)	x	31.20(±11.26)	11.52(±4.11)	16.81(±5.98)
LLM 自我评估 (Prob)	78.51(±1.21)	57.81(±4.42)	42.52(±30.00)	5.31(±2.41)	9.07(±3.74)
监督 SQLENS	79.98†(±1.39)	61.59†(±3.11)	54.83†(±21.06)	9.65(±8.11)	15.10(±11.29)
SQLENS	74.41(±2.24)	58.99(±3.19)	35.88(±5.22)	32.23†(±4.33)	33.88†(±4.49)

x 表示分类不是基于阈值的。
† 最佳结果。前两名结果突出显示为粗体。

F.3 未修正的 SQL 查询分析

有些 SQL 查询确实不正确但未被修正。我们调查了原因并确定了三个主要原因：

• SQL 查询已被修正，但与真实执行结果不完全匹配。例如，修正后的 SQL 可能与真实查询语义等价，但投影了一组不同的列或以不同方式表示某一列。这是精确匹配指标的固有局限性。
• • 正确识别了语义错误，我们的错误报告向 LLM 提供了正确的指令。然而，LLM 未能遵循 SQLens 提供的指导而无法修正查询。这源于 LLM 本身的局限性。
• • 检测到的语义错误并未完全捕捉到根本原因，即使修正了识别到的错误，SQL 查询中仍有一些错误存在。

• F.4 讨论

正如实验结果所证实的那样，SQLENS 在错误检测和修正方面非常有效，尤其有利于缺乏 SQL 知识的非技术用户。然而，像许多其他基于 LLM 的文本到 SQL 解决方案一样，我们的方法也会产生一些成本和延迟。平均而言，SQLENS 进行大约 5 次 LLM 调用，端到端延迟不到 30 秒。为进一步降低成本和延迟，用户可以配置更便宜的错误信号，提供 SQL 正确性的地面真相标签，或限制 SQLENS 错误修正过程中的迭代次数。正如在引言部分的动机示例中所述，SQLENS 并非设计用于实时交互式 SQL 查询修正。相反，它作为一个调试工具，异步检测和修正 SQL 查询中的错误。

F.5 BIRD 和 Spider 上各个错误信号的有效性

表 11：个别错误信号的表现（Vanilla+BIRD）。

信号名称	精确率	召回率	N_se
基于数据库的信号
异常结果	98.96	16.13	95
空谓词	85.34	11.88	70
子查询中的错误过滤	无检测到的查询
错误的 GROUP BY	40.0	2.38	14
错误的 JOIN 谓词	100	1.87	11
次优的 JOIN 树	45.9	14.26	84
表相似性	67.35	5.6	33
不必要的子查询	33.33	0.34	2
值歧义	53.85	7.13	42
基于 LLM 的信号
列歧义	68.75	1.87	11
证据违反	61.11	1.87	11
证据不足	29.03	1.53	9
LLM 自检	60.82	10.02	59
问题子句链接	53.49	3.9	23

表 13：个别错误信号的表现（DIN-SQL+Spider）。

信号名称	精确率	召回率	N_se
基于数据库的信号
异常结果	73.61	23.35	53
空谓词	82.98	17.18	39
子查询中的错误过滤	无检测到的查询
错误的 GROUP BY	43.33	5.73	13
错误的 JOIN 谓词	92.86	11.45	26
次优的 JOIN 树	33.33	5.73	13
表相似性	无检测到的查询
不必要的子查询	0	0	0
值歧义	25.0	1.32	3
基于 LLM 的信号
列歧义	80	1.76	4
证据违反	80	1.76	4
证据不足	40	7.93	18
问题子句链接	53.33	3.52	8
LLM 自检	39.58	16.74	38

表 12：个别错误信号的表现（Vanilla+Spider）。

信号名称	精确率	召回率	N_se
基于数据库的信号
异常结果	60.0	14.35	30
空谓词	50.0	2.39	5
子查询中的错误过滤	100.0	0.48	1
错误的 GROUP BY	64.29	4.31	9
错误的 JOIN 谓词	100.0	5.26	11
次优的 JOIN 树	42.86	5.74	12
表相似性	无检测到的查询
不必要的子查询	100.0	0.48	1
值歧义	33.33	1.44	3
基于 LLM 的信号
列歧义	33.33	0.48	1
证据违反	100	1.44	3
证据不足	7.14	1.44	3
LLM 自检	20.65	9.09	19
问题子句链接	70.0	3.35	7

表 14：个别错误信号的表现（MAC-SQL+Spider）。

信号名称	精确率	召回率	N_se
基于数据库的信号
异常结果	58.82	14.42	30
空谓词	52.94	4.33	9
子查询中的错误过滤	100	1.44	3
错误的 GROUP BY	50	3.37	7
错误的 JOIN 谓词	100	3.85	8
次优的 JOIN 树	38.71	5.77	12
表相似性	无检测到的查询
不必要的子查询	33.33	0.48	1
值歧义	25.0	1.44	3
基于 LLM 的信号
列歧义	0	0	0
证据违反	58.33	3.37	7
证据不足	18.92	3.37	7
LLM 自检	31.17	11.54	24
问题子句链接	40	2.88	6

参考论文：https://arxiv.org/pdf/2506.04494