TraceSQL：无参考文本到SQL验证的可追溯可回答性估计

# 面向无参考文本到SQL验证的可追溯可回答性评估
来源：https://arxiv.org/html/2608.17795
## TraceSQL：面向无参考文本到SQL验证的可追溯可回答性评估
CCS：计算方法学 自然语言处理
CCS：计算方法学 机器学习
CCS：信息系统 数据库查询处理

Debasmita Panda (甲骨文公司，印度)
Srutanik Bhaduri (甲骨文公司，印度)
Aditya Banerjee (甲骨文公司，美国)
Viji Krishnamurthy (甲骨文公司，美国)

© 无

###### 摘要

文本到SQL系统通常使用真实SQL查询或参考执行结果进行评估，但在实际部署中，推理时无法获取此类监督信息。这就产生了一个关键的验证问题：仅根据用户问题、数据库上下文和生成的SQL，系统能否估计生成的查询是否可能正确回答该问题？近期方法使用大语言模型（LLM）作为裁判或专用代理来检查生成的SQL，但其决策可能难以追溯。结果奖励模型（ORM）通过从带有执行标签的候选SQL中学习来解决此问题，并为未见过的查询分配正确性分数，但它们对于每次验证背后的信号仍提供有限的可见性。为解决此局限性，我们提出了TraceSQL，一个基于显式诊断特征构建的轻量级可追溯验证模型。TraceSQL结合了67个特征，捕捉问题的歧义性、问题要求、问题-模式-SQL一致性、SQL结构以及意图对齐。这些信号可用于检查哪些因素影响每个预测，并将决策追溯到诊断证据。在BIRD开发数据库上，TraceSQL在相同的生成SQL评估中，取得了66.47%的F1分数和64.48%的ROC-AUC，而GradeSQL-7B ORM基线分别为61.87%和58.26%。特征归因进一步表明，模型同时依赖于语义基础和确定性的SQL结构信号。这些结果表明，可以在使用轻量级学习模型执行SQL验证的同时，保留特征级证据以检查和诊断其预测。

###### 关键词：

文本到SQL，可回答性评估，验证，可解释性，可追溯性，自动机器学习，BIRD

## 1. 引言

文本到SQL系统随着大语言模型（LLMs）的发展而快速进步。Spider和BIRD等基准测试在复杂问题和未见过的数据库模式上评估系统。近期方法通过分解、示例选择、自我纠正、多代理推理和大规模合成监督进一步改进了生成。尽管有这些进步，生成的SQL可能包含微妙的语义、模式对齐或结构错误。因此，可靠的文本到SQL不仅需要生成查询，还需要确定生成的查询是否可被信任。在基准评估期间，此决策可以通过真实SQL或参考执行结果来支持。然而，在部署中，此类参考通常不可用，因此生成后验证必须依赖于用户问题、数据库上下文、生成的SQL以及从它们关系中推导出的信号。现有方法以不同方式提供生成后可靠性。基于LLM的方法使用自我纠正或专用代理来检查和改进生成的SQL。更近期的工作也探索了基于推理的SQL裁判和显式的基于规则的验证。这些方法展示了不同形式的验证证据，例如纠正推理、代理反馈、执行信号和基于规则的检查。然而，这些证据通常与各个方法的设计相关联，并未以统一的、可量化的方式表示，因此无法进行系统性分析或与学习到的验证决策相关联。

结果奖励模型（ORM）提供了这些方法的一种学习替代方案。GradeSQL在训练期间生成多个候选SQL，通过执行与参考SQL的匹配获得正确性标签，并微调LLM来估计候选的正确性。在推理时，训练好的ORM分配一个基于概率的正确性分数，而无需参考SQL。这表明执行推导的监督可用于训练专用的文本到SQL验证器。然而，产生的预测主要以标量分数形式呈现。虽然这对排名或选择候选很有用，但该分数对于贡献于决策的特定语义或结构信号提供有限的可见性。

当验证不仅需要支持预测，还需要支持理解和诊断时，这就留下了一个重要的空白。一个候选失败可能是因为错误的模式对齐、不受支持的分析要求、缺失或不适当的SQL操作、错误的分组，或与预期结果不匹配。知道一个候选获得了低验证分数本身并不能区分这些情况。为了使验证器支持系统分析，其决策应是可解释的（基于有意义的信号）、可解释的（说明这些信号如何影响预测）和可追溯的（追溯到这些信号来源的证据）。

我们引入TraceSQL，一个围绕这三个特性设计的轻量级学习型验证器。TraceSQL通过显式的诊断信号表示每个问题-候选对，而不仅仅依赖最终的验证器分数。这种表示结合了五个互补的诊断族系：问题歧义性、问题规划、问题、模式和生成SQL之间的配对分析、确定性SQL结构以及意图对齐。它们共同产生了67个紧凑特征，描述了问题表达的要求、候选的对齐和语义一致性、SQL中存在的操作及其与预期请求的对齐。

该表示提供了三个层次的可见性以审视验证过程。首先，模型输入是具有明确语义含义的命名诊断特征，使得表示本身可解释。其次，特征重要性方法可以应用于学习到的模型，以确定哪些信号影响其预测，提供模型级的可解释性。第三，更丰富的诊断输出（特征由此派生）被单独保留，允许将有影响力的特征追溯到其支持证据。因此，TraceSQL将最终的验证决策连接到可测量的特征级信号及其诊断溯源。

我们使用GradeSQL发布的平衡BIRD ORM训练数据中的生成候选SQL来训练TraceSQL。然后，我们在相同的保留BIRD数据库的生成候选SQL上评估TraceSQL和GradeSQL-7B。TraceSQL取得了66.47%的F1分数和64.48%的ROC-AUC，而GradeSQL-7B分别为61.87%和58.26%。除了预测性能外，我们的特征分析表明，学习到的验证器同时利用了语义诊断信号和确定性的SQL结构属性，使得其行为可以根据生成查询的具体属性进行审视。

##### 贡献

我们做出了三项主要贡献。首先，我们引入了TraceSQL，一个将SQL验证与可解释性、可解释性和可追溯性相结合的轻量级学习型验证器。其次，我们从五个诊断族系中开发了一个67特征表示，其中模型输入保持语义意义并保留了对底层诊断证据的溯源。第三，我们在相同的保留生成候选SQL上对TraceSQL与GradeSQL-7B进行了评估，并分析了驱动其预测的语义和结构信号，展示了验证决策如何与显式的特征级证据相关联。

## 2. 相关工作

### 2.1. 文本到SQL生成

近期基于LLM的文本到SQL方法改进了生成过程的不同部分。DIN-SQL将生成分解为模式链接、查询分解、SQL生成和自我纠正。DAIL-SQL关注提示构建和示例选择用于上下文学习。MAC-SQL使用多代理框架，包含用于分解、上下文缩减和SQL优化的专用组件。OmniSQL通过大规模合成监督解决了专用文本到SQL模型的训练数据瓶颈。这些方法主要改进SQL生成或优化，而TraceSQL在生成之后运行，专注于验证已生成的候选，同时保留验证决策背后的证据。

### 2.2. 生成后验证与学习型验证器

近期工作越来越关注在SQL生成后检测和纠正错误。MAGIC使用专用代理从生成失败中推导出自我纠正准则，而DPC通过将SQL行为与独立构建的执行路径进行比较来执行无训练候选验证。学习型验证也作为一种替代方案出现：STaR-SQL在测试时推理中纳入了基于结果监督的奖励模型来对生成的候选进行排名。

GradeSQL通过特定任务的结局奖励模型（ORM）进一步发展了这一方向，ORM在基于执行的候选标签上训练，并在推理时用于分配连续的正确性分数。TraceSQL遵循从执行推导的候选标签中学习的理念，但在验证的表示方式上有所不同。TraceSQL不是仅暴露一个标量正确性分数，而是保留了一组固定的诊断信号，这些信号可以被单独分析并追溯到其底层证据。

### 2.3. 可解释、可理解和可追溯的验证

近期的验证方法提供了不同形式的透明度，包括纠正准则、结构化推理和显式的验证约束。TraceSQL采取了一种互补的方法，将验证证据表示为显式的、可测量的特征，这些特征可以直接与学习型验证器的行为相关联。

TraceSQL在三个层面上提供透明度。可解释性来自语义定义的诊断特征，这些特征被用作模型输入。可解释性通过特征重要性和归因方法提供，包括排列重要性和SHAP，这些方法揭示了哪些信号影响模型的预测。可追溯性通过将这些特征链接回派生它们的诊断证据来保持。这些特性共同使得验证器不仅能暴露其预测，还能暴露与该决策相关的语义和结构信号。

## 3. 任务表述

令 q 表示自然语言问题，s 表示相应的数据库上下文，x 表示待验证的候选SQL。验证任务是仅使用验证器可获得的信息，估计 x 是否正确回答了 q。在主要设置中，x 是生成的候选SQL；相同的验证管道也应用于BIRD开发数据库提供的真实SQL。

在训练和评估期间，候选正确性通过执行匹配确定：
\(1\) y = \[Exec(x) = Exec(x^\star)\]
其中 x^\star 表示参考SQL，y ∈ \{0,1\} 是候选级别的正确性标签。参考SQL和由此产生的执行匹配标签仅用于构建离线监督，不作为输入提供给TraceSQL。

给定 (q, s, x)，诊断管道构建一个67维的特征表示：
\(2\) \mathbf{z} = f(q, s, x)
其中 \mathbf{z} 捕获与问题歧义性、问题要求、问题-模式-SQL一致性、SQL结构和意图对齐相关的显式信号。TraceSQL然后估计：
\(3\) \hat{p} = P(y=1 \mid \mathbf{z})
其中 \hat{p} 是候选SQL正确的估计概率。

使用固定的决策阈值 τ = 0.50，最终的验证决策为：
\(4\) \hat{y} = \mathbb{1}[\hat{p} \geq \tau]
\mathbf{z} 中的特征保持单独可检查性并保留其诊断溯源。这允许根据影响学习预测的语义、对齐和结构信号来审视验证决策。

## 4. 可追溯的可回答性信号

### 4.1. 诊断证据生成

TraceSQL从三个上游诊断模块获取其验证证据：歧义性检测器、配对分析器和SQL修复模块。它们共同捕捉了问题级别的歧义性、问题-模式-SQL一致性以及用户请求与候选SQL之间的对齐。它们的结构化输出被保留为诊断证据，并随后转换为第4.2节中描述的模型特征。

#### 4.1.1. 歧义性检测器

歧义性检测器评估用户问题相对于可用数据库上下文是否被充分指定。它产生：
- • 歧义性状态：指示问题是否被认为有歧义。
- • 歧义性概率：以0-100的尺度估计歧义程度。
- • 解释：提供支持歧义性评估的证据或原理。

这些输出为构建下游歧义性特征提供了源证据。

#### 4.1.2. 配对分析器

配对分析器评估候选SQL是否得到用户问题和数据库上下文的支持。它应用预定义的验证规则，涵盖模式和列对齐、连接、标识符、数据类型、时间语义、指标、空值和有效性逻辑，以及业务术语映射。其诊断输出包括：
- • 支持状态：将候选分类为受支持、部分受支持、不受支持或不清楚。
- • 配对分数和摘要：提供候选支持的整体评估。
- • 规则级结果：记录每个验证规则的状态、分数、解释和支持证据。
- • 发现：描述检测到的对齐或一致性差距以及受影响的数据库或SQL元素。

规则级的状态用于构建配对