UniQL：面向文本到SQL的方言通用基准测试

# UniQL：面向方言通用的文本到SQL基准测试
来源：https://arxiv.org/html/2606.08018
高建玲¹，陶重阳¹，白佳媛¹，杨柳¹，潘轩光¹，刘金瑞¹，邢世豪，徐晓涵²，梁杰¹，马帅¹  ¹北京航空航天大学计算机学院 ²香港大学  ¹\{jianlingg,chongyang,baijiayuan,panxg,mashuai\}@buaa\.edu\.cn  ²shawnxxh@gmail\.com

UniQL：面向方言通用的文本到SQL基准测试

高建玲¹，陶重阳¹，白佳媛¹，杨柳¹，潘轩光¹，刘金瑞¹，邢世豪，徐晓涵²，梁杰¹，马帅¹  ¹北京航空航天大学计算机学院 ²香港大学  ¹\{jianlingg,chongyang,baijiayuan,panxg,mashuai\}@buaa\.edu\.cn  ²shawnxxh@gmail\.com

## 1 引言

结构化查询语言仍然是现代数据库系统交互的主要接口。尽管经过了数十年的标准化努力，SQL生态系统在PostgreSQL、MySQL、Oracle等数据库引擎之间仍然高度碎片化。虽然这些系统都采用类似SQL的接口，但它们在语法、内置函数和优化行为上往往存在显著差异。因此，语义等价的查询通常需要方言特定的实现，这使得SQL的可移植性成为实际数据系统中一个长期存在的挑战。

与此同时，大语言模型（LLM）的近期进展迅速将数据交互从以SQL为中心的接口转向以自然语言为中心的接口。现代文本到SQL系统越来越允许用户直接用自然语言表达查询意图（Wang等人，2025 (https://arxiv.org/html/2606.08018#bib.bib227)；Pourreza和Rafiei，2023 (https://arxiv.org/html/2606.08018#bib.bib228)；Qin等人，2025 (https://arxiv.org/html/2606.08018#bib.bib229)；Pourreza等人，2025 (https://arxiv.org/html/2606.08018#bib.bib230)），减少了手动编写方言特定SQL查询的需求。这一趋势引发了一种更通用查询范式的可能性，其中自然语言作为异构数据库系统上的统一接口。这种范式在数据代理和自动化分析时代变得越来越重要，因为用户请求可能涉及跨不同数据库系统的查询、集成和操作，而不是与单一后端交互。

然而，当前的文本到SQL评估仍然主要以SQLite为中心，这使得现有模型在实践中能否支持这种跨系统查询尚不明确。现有主流基准测试如Spider（Yu等人，2018 (https://arxiv.org/html/2606.08018#bib.bib209)）和BIRD（Li等人，2023 (https://arxiv.org/html/2606.08018#bib.bib231)）主要关注SQLite执行，因此无法评估可执行的跨方言泛化能力。更近期的基准测试如Spider 2.0（Lei等人，2025 (https://arxiv.org/html/2606.08018#bib.bib232)）引入了跨不同数据库系统的企业级文本到SQL工作流，但其任务是系统特定的，而不是同一自然语言意图在不同方言中的对齐实现。因此，它们无法直接分离方言变化与模式、任务或数据库环境的差异。在一个方言中可执行且语义正确的查询，在另一个数据库系统中可能会失败、行为不同或需要大量改写，原因包括执行语义、函数库、排序行为、隐式类型转换、聚合规则和方言特定语法的差异。因此，当前的基准测试设置可能高估了文本到SQL系统的鲁棒性和通用性，同时忽视了它们对方言变化的敏感性。

为弥补这一差距，我们引入了UniQL，一个用于跨方言文本到SQL评估的人工验证可执行基准测试。基于BIRD开发集，UniQL将1,534个自然语言问题与跨16种SQL方言的可执行SQL实现对齐，产生了24,544个方言特定的SQL标注。所有方言共享相同的自然语言意图、对齐的数据库模式和底层数据库内容，从而实现了方言泛化的受控评估。为构建该基准测试，我们开发了一个混合流水线，结合了数据库迁移、基于工具的翻译、基于LLM的翻译、带执行反馈的自我反思、迭代翻译规则演化和针对长尾情况的人工验证。利用UniQL，我们在仅推理设置下评估了广泛的开源和闭源LLM。我们的结果揭示了一个被现有以SQLite为中心的评估所隐藏的差距：当前LLM通常能在某些数据库系统中解决一个意图，但无法跨方言一致地表达同一意图。即使强大的模型平均也只解决了约一半的基准测试，表现出显著的模型-方言交互，并且从SQLite正确性到其他数据库系统的迁移能力有限。这些发现表明，方言通用的文本到SQL不仅仅是提高整体模型能力的问题，还需要显式评估和建模跨方言鲁棒性。总结而言，本文的贡献如下：

- • 我们引入了UniQL，一个将同一自然语言意图与跨16种方言的SQL实现对齐的人工验证可执行基准测试。
- • 我们提出了一个用于构建UniQL的SQL翻译框架，该框架集成了基于工具的翻译、基于LLM的翻译、基于执行的验证、带执行反馈的自我反思、迭代翻译规则演化和人工验证。
- • 我们在UniQL上全面评估了开源和闭源LLM，结果表明当前模型仍然难以实现方言通用的文本到SQL生成。

## 2 相关工作

文本到SQL基准测试已被广泛研究，用于评估从自然语言生成可执行SQL的能力。早期的语义解析和自然语言接口数据集，如ATIS（Dahl等人，1994 (https://arxiv.org/html/2606.08018#bib.bib252)）、GeoQuery（Zelle和Mooney，1996 (https://arxiv.org/html/2606.08018#bib.bib249)）和Restaurants（Tang和Mooney，2000 (https://arxiv.org/html/2606.08018#bib.bib250)），专注于领域特定的数据库查询。随后的工作重新审视了文本到SQL的评估方法论，并标准化了多个数据集（Finegan-Dollak等人，2018 (https://arxiv.org/html/2606.08018#bib.bib251)）。后来的基准测试将任务从WikiSQL（Zhong等人，2017 (https://arxiv.org/html/2606.08018#bib.bib191)）中的单表查询扩展到Spider（Yu等人，2018 (https://arxiv.org/html/2606.08018#bib.bib209)）中的复杂跨域多表查询，并进一步扩展到BIRD（Li等人，2023 (https://arxiv.org/html/2606.08018#bib.bib231)）中基于值的真实查询。然而，这些基准测试主要基于SQLite。近期的基准测试如Spider 2.0（Lei等人，2025 (https://arxiv.org/html/2606.08018#bib.bib232)）覆盖了多个数据库系统，但它们的任务是系统特定的，而不是同一自然语言意图在不同方言中的对齐实现。对话数据集如SParC（Yu等人，2019b (https://arxiv.org/html/2606.08018#bib.bib159)）和CoSQL（Yu等人，2019a (https://arxiv.org/html/2606.08018#bib.bib158)）关注多轮交互，但也主要仍是单方言。相比之下，UniQL将同一自然语言意图与跨16种人工验证方言的可执行SQL实现对齐，从而实现了跨方言鲁棒性的受控评估。

另一相关工作是SQL方言翻译，它将源SQL查询重写为另一个数据库系统的等价查询。基于规则的系统如SQLGlot (SQLGlot, https://arxiv.org/html/2606.08018#bib.bib233)、JOOQ (JOOQ, https://arxiv.org/html/2606.08018#bib.bib234)和SQLines (SQLines, https://arxiv.org/html/2606.08018#bib.bib235)依赖手动维护的方言映射，而近期的基于LLM或混合系统如MALLET（Ngom和Kraska，2024 (https://arxiv.org/html/2606.08018#bib.bib236)）、RISE（Xie等人，2026 (https://arxiv.org/html/2606.08018#bib.bib238)）和CrackSQL（Zhou等人，2025b (https://arxiv.org/html/2606.08018#bib.bib184)；2025a (https://arxiv.org/html/2606.08018#bib.bib185)）则结合了LLM、执行反馈或方言特定规则。近期的基准测试如PARROT（Zhou等人，2026 (https://arxiv.org/html/2606.08018#bib.bib237)）进一步评估了跨多个生产级数据库系统的系统间SQL到SQL翻译。这些工作与UniQL互补：它们专注于SQL到SQL的可移植性，而UniQL评估模型是否能在对齐的跨方言条件下直接从自然语言生成可执行的、方言特定的SQL。

## 3 数据集构建

参照图注：图1：UniQL构建流水线。UniQL通过数据库迁移、混合SQL翻译、基于执行的验证、迭代翻译规则演化和人工验证，将广泛使用的BIRD SQLite开发集扩展到16种SQL方言。

构建一个高质量的跨方言文本到SQL基准测试不仅仅是转换SQL字符串。翻译后的查询必须在目标数据库系统上可执行，并且必须保留原始自然语言问题的意图。UniQL的总体构建流水线如图1 (https://arxiv.org/html/2606.08018#S3.F1) 所示。UniQL将BIRD开发集从SQLite扩展到16种SQL方言，为1,534个自然语言问题生成了24,544个可执行的SQL标注。SQLite作为源方言，其他15种目标方言通过一个结合数据库迁移、自动SQL翻译、基于执行的验证、迭代翻译规则演化和人工验证的混合流水线构建。

### 3.1 数据库迁移

由于可执行的跨方言评估需要在实际的数据库系统上运行SQL查询，我们首先将原始的BIRD数据库迁移到每个目标系统。尽管迁移后的数据库旨在尽可能保留原始模式和值，但在异构DBMS之间精确的一对一迁移并不总是可能的。不同系统在类型名称、标识符规则、大小写敏感性、命名空间组织、保留关键字和支持的约束方面存在差异。例如，有些系统通过模式或用户来组织数据，而不是独立的数据库命名空间，而另一些系统则对表和列名施加不同的约定。因此，我们在迁移过程中执行轻量级的模式和数据归一化，包括类型映射、标识符归一化、命名空间适配和必要的格式更改。这一迁移步骤为在每个目标方言下验证翻译后的SQL查询提供了所需的执行环境。

### 3.2 自动翻译与验证

给定自然语言问题 \(x\)、其源SQLite查询 \(q_s\)、源数据库 \(D_s\) 以及迁移后的目标数据库 \(D_t\)，目标是构建一个目标查询 \(q_t\)（方言 \(\tau_t\)），使得 \(q_t\) 在 \(D_t\) 上可执行且保持 \(q_s\) 的语义。我们首先应用一个确定性基于规则的翻译器（例如，SQLGlot (SQLGlot, https://arxiv.org/html/2606.08018#bib.bib233)）来获得初始目标查询：

\[
q_t^{(0)} = \mathcal{F}_{tool}(q_s, \tau_s, \tau_t),
\]
其中 \(\tau_s\) 是SQLite，\(\tau_t\) 是目标方言。这一步高效地处理了常见的语法映射和标准SQL构造。

然后通过基于执行的验证来检查翻译后的查询。设 \(E(q, D)\) 表示查询 \(q\) 在数据库 \(D\) 上的执行结果。只有在翻译后的查询在目标数据库上成功执行，并且其结果在我们保守的验证协议下等同于源执行结果时，才自动接受该翻译：

\[
\mathcal{V}(q_s, q_t, D_s, D_t) = \mathbb{I}\left[E(q_t, D_t) \equiv E(q_s, D_s)\right].
\]
这里，我们在构建过程中使用保守的接受标准（详见第5节 (https://arxiv.org/html/2606.08018#S5)）。先前单方言基准测试中的标准执行精度通常将查询输出转换为无序集合后再进行比较。这可能引入跨方言构建中的假阳性，因为排序信息和重复的基数可能被丢弃。因此，我们的自动验证在处理具有显式排序语义的查询时保留排序，并在无序比较中保留对重复敏感的输出。在构建阶段，这种保守的验证策略确保了自动接受的翻译的质量。

如果基于规则的翻译无法被自动接受，我们调用一个基于LLM的翻译器，其条件包括源SQL、目标模式、方言信息和当前规则集 \(\mathcal{R}\)：

\[
q_t^{(1)} = \mathcal{F}_{LLM}(q_s, S_t, \tau_t, \mathcal{R}),
\]
其中 \(S_t\) 表示目标模式。当生成的查询仍然无法通过等价验证时，模型进入一个有界的自我反思循环。在第 \(k\) 次迭代中，反馈对象 \(F_k\) 包含先前的目标SQL、执行错误或结果不匹配。然后模型优化查询为：

\[
q_t^{(k+1)} = \mathcal{F}_{reflection}(q_s, q_t^{(k)}, F_k, S_t, \tau_t, \mathcal{R}).
\]
这一过程重复，直到查询被自动接受或达到最大优化轮数。在我们的实现中，LLM翻译器使用GPT-5-mini。对于每次失败的翻译，我们允许最多三轮执行反馈反思，然后将其路由到后续构建阶段。翻译器提示模板见附录B (https://arxiv.org/html/2606.08018#A2)。

### 3.3 迭代翻译规则演化

自动翻译失败不会被当作孤立的查询级错误处理。相反，我们将它们收集到失败日志中，并将重复出现的错误模式抽象为可重用的方言转换规则。对于每个目标方言，设 \(\mathcal{L}_{fail}\) 表示在执行导向优化后失败的翻译集。这些失败与当前规则集 \(\mathcal{R}^n\) 以及方言文档一起分析，以产生更新的规则集：

\[
\mathcal{R}^{n+1} = \mathcal{G}_{rule}(\mathcal{R}^n, \mathcal{L}_{fail}, \mathcal{D}_{doc}),
\]
其中 \(\mathcal{G}_{rule}\) 表示规则总结过程，\(\mathcal{D}_{doc}\) 表示目标方言文档或教程。

精炼后的规则集随后被纳入后续翻译尝试中。这一反馈循环使构建流水线能够逐步处理重复的方言特定失败，例如函数重写、类型转换、日期和时间操作、聚合行为或系统特定的语法约束。通过这种方式，流水线结合了确定性翻译的效率、基于LLM的重写的灵活性以及累积方言知识的可重用性。我们使用Gemini-2.5-Pro实例化规则总结器，并运行三轮规则演化。总结器提示模板见附录B (https://arxiv.org/html/2606.08018#A2)。

### 3.4 人工验证

在自动翻译、自我反思和规则精炼之后，剩余的