ESQ-Bench：一个多层企业Oracle基准，用于评估NL2SQL方言泛化和静默语义差异

# ESQ-Bench：一个用于评估NL2SQL方言泛化与静默语义差异的多层企业级Oracle基准测试
来源：https://arxiv.org/html/2608.23569  
Divya Chukkapalli，独立研究员，美国北卡罗来纳州Apex市，ORCID: 0009-0005-4691-3395  
Ganesh R. Naik，澳大利亚托伦斯大学，ORCID: 0000-0003-1790-9838

###### 摘要

最先进的自然语言转SQL（NL2SQL）模型在诸如Spider和BIRD等现有基准测试上报告的执行准确率已超过89%。然而，这些基准测试依赖于简化的学术模式和不反映企业数据库环境复杂性的开源SQL方言。我们引入了ESQ-Bench，这是一个以Oracle为优先的NL2SQL基准测试，包含系统性的复杂度层次，并在三个企业模式复杂度层次上评估静默差异。我们构建并发布了六个已填充的模式（465张表，164,682行，零空表），在Oracle、PostgreSQL、MySQL和SQL Server上使用相同的种子数据，以及一个包含四项指标的评估工具包（EM、EX、SR、SD），并包含550对经过黄金标准验证的问题-查询对（层次1：95对；层次2：228对；层次3：227对）。使用GPT-4o进行的模式链接提示显示出执行匹配率随层次增加而单调下降——在已执行查询上的EX（2026年6月）分别为79.8%/60.3%/57.2%——相比之下，早期142个问题的试验片段上则为75.6%/80.4%/95.8%。精确匹配（EM）在各层次上均低于7%；在EX通过的查询中，操作性静默差异率（SD_op）达到73-99%。故障分析（F1-F4）表明，在更高层次上，错误结果语义（F3）占据主导。一个次要发现是：Claude Sonnet 4.6在使用模式链接提示时，在已执行查询上的EX达到87.4%/74.9%/68.7%，在每个层次上都超过了GPT-4o SL。GPT-4o零样本在已执行查询上的EX（78.7%/73.5%/77.8%）在层次2-3上由于零样本分析中较低的执行率和幸存者偏差而逆转了SL的表现。本地Llama 3.2模式链接仅达到银行范围13.3%的EX（73/550），凸显了闭源API模型与开源基线模型在企业Oracle模式上的差距。

关键词：企业基准测试；评估指标；自然语言转SQL；NL2SQL；Oracle数据库；模式复杂度；语义差异；文本转SQL。

## 1 引言

使用自然语言查询关系数据库的能力一直是数据库和自然语言处理社区的长期目标。近期基于大型语言模型的方法报告了显著的准确率：DAIL-SQL在Spider上达到了86.6%的执行准确率，而基于GPT-4的系统在同一基准测试上超过了91%。在更新、更具挑战性的BIRD基准测试上，最先进的模型接近67%。这些数字引发了对NL2SQL在生产环境中可部署性的普遍乐观。

然而，尝试将这些系统部署到真实企业数据库的从业者报告了截然不同的体验。企业数据库——特别是那些建立在Oracle Database之上的数据库（Oracle在《财富》500强和金融服务领域占据主导地位）——呈现出任何已发布基准测试都无法检验的模式复杂性和SQL方言特征。基准准确率与生产准确率之间的差距是真实存在的、巨大的，并且未被充分理解。

我们识别了导致这种差距的三个结构性机制：

1.  **模式复杂度不匹配**。Spider模式平均包含5.1张表，具有完整的外键文档和清晰的命名规范。企业Oracle模式通常包含150-500张表，外键执行不完全，列名具有歧义（例如，仅STATUS这样的单一名称就可能在七张表中出现，且值域不同），以及源于数十年系统迁移的遗留缩写命名（如ACCT_BAL_DT_AMT_USD）和反规范化结构。
2.  **Oracle方言盲区**。每个主要的NL2SQL基准测试都针对SQLite或PostgreSQL。Oracle Database的语法和语义在某些方面有所不同，会导致查询静默出错或显式失败：例如，使用FETCH FIRST进行分页、使用CONNECT BY进行层级遍历、用MINUS代替EXCEPT、将空字符串强制转换为空值（NULL）、以及默认的NULLS LAST排序规则等。
3.  **指标盲区**。执行匹配（EX）——该领域的主导评估指标——仅确定生成的查询是否返回与黄金标准查询相同的行。它无法检测那些由于Oracle特定的空值处理、隐式类型转换或边界条件差异而执行成功但返回语义错误结果的查询。我们将这些称为*静默语义差异*，并引入了一个指标来量化它们。

为了解决这些差距，我们做出了以下贡献：

1.  **ESQ-Bench基础设施**：六个具有企业代表性的模式（465张表，164,682行种子数据，零空表），分为三个层次，具有方言保真的DDL，以及在Oracle（主要）、PostgreSQL、MySQL和SQL Server上相同的数据——这是首批专为生产验证而设计的以Oracle为优先的NL2SQL基准测试之一，通过特定于方言的构造和SD测量，补充了面向企业的套件（如Spider 2.0）。
2.  **完整的550个问题库（v0.3）**：包含跨层次1-3的95/228/227对经黄金标准验证的问答对，关键条件与种子数据相关（空值陷阱、状态域分离、CONNECT BY层级、实体重叠连接和歧义消解陷阱）。
3.  **一个包含四项指标的评估框架**：包括精确匹配（EM）、执行匹配（EX）、语义召回（SR）和静默差异率（SD），并提供了正式定义、操作性工具包定义和可复现的计算方法。
4.  **全库GPT-4o评估**（550个问题，模式链接SAL，2026年6月）：各层次执行匹配率为79.8%/60.3%/57.2%，EM低于7%，操作性SD_op较高（73-99%），单调复杂度退化，以及F1-F4故障分类法（第6节和第9节）。
5.  **公开的基准测试发布**：包含模式、种子脚本、全部550个问题、评估工具包（run_esq_tier1_evaluation.py）、故障分类法（analyze_esq_failures.py）、完整的GPT-4o和Claude Sonnet 4.6基线结果（表11）。

本文其余部分结构如下：第2节定义NL2SQL任务和Oracle方言特征。第3节综述先前的基准测试并识别差距。第4节描述ESQ-Bench的设计与构建。第5节形式化我们的四项指标框架。第6节展示实验结果，包括多模型基线以及模式链接与零样本分析。第7节提供复杂度预测器分析。第8节讨论影响和局限性。第9节识别开放的研究问题。第10节总结。

## 2 背景

### 2.1 任务定义

给定一个自然语言问题Q和一个数据库模式S={T1,T2,...,Tn}，其中每个表Ti包含列{ci,1,...,ci,mi}及其关联的数据类型和约束，NL2SQL任务要求生成一个SQL查询q，使得在符合S的数据库实例D上执行q返回的结果集R(q,D)满足问题Q的*意图*。

“意图”一词至关重要。现有评估指标评估的是R(q,D)是否等于R(q*,D)，其中q*是指定的黄金标准查询。这是正确性的必要但不充分条件：R(q,D)可能在特定测试实例D上等于R(q*,D)，但在具有不同数据分布的其他实例上产生差异——特别是当这种差异源于Oracle特定的空值语义或测试数据未暴露的隐式类型转换时。

### 2.2 Oracle方言特征

Oracle Database引入了SQLite或PostgreSQL中不存在的语法和语义。以下特性出现在真实企业查询中，并且在所有现有的NL2SQL基准测试中均未涉及。

#### 2.2.1 分页

Oracle历史上使用ROWNUM进行行限制，并在12c版本中引入了SQL:2008标准的FETCH FIRST n ROWS ONLY语法。在Spider/BIRD上训练的模型生成LIMIT n，这是无效的Oracle语法，会产生ORA-00933错误。

#### 2.2.2 层次查询

Oracle专有的CONNECT BY/START WITH子句能够无需递归CTE即可遍历自引用层次结构。这对于组织结构图、账户层次、总账账户树和保险保单层次结构是必需的。没有具有相同语义的标准SQL等效物。

#### 2.2.3 集合操作

Oracle在SQL标准指定EXCEPT的地方使用MINUS。模型生成EXCEPT，Oracle会以ORA-00933错误拒绝。

#### 2.2.4 空值语义

Oracle将空字符串（''）视为空值（NULL）——这种行为在其他任何主要RDBMS中都不存在。此外，Oracle在升序排序时空值默认排在最后（NULLS LAST），这与PostgreSQL和MySQL（默认NULLS FIRST）相反。当测试数据中不包含空值时，这些差异是不可见的，而当存在空值时，它们会创建静默的语义差异。

#### 2.2.5 Oracle特定函数

DECODE、NVL、NVL2、NULLIF、LISTAGG、SYS_CONNECT_BY_PATH和RATIO_TO_REPORT是Oracle特定或Oracle扩展的函数，在其他方言中没有直接等效物。在开放方言数据上训练的模型会用近似的替代方案，这可能产生微妙不同的结果。

## 3 相关工作

### 3.1 基准测试演变

WikiSQL引入了大规模NL2SQL评估，包含80,654个示例，但仅限于单表查询，无法进行多连接和子查询评估。

Spider通过跨200个数据库的10,181个示例推动了该领域的发展，要求跨域泛化和复杂SQL。然而，Spider的模式平均有5.1张表，所有外键约束都强制执行且有文档记录，列命名清晰，所有查询都针对SQLite。Spider将执行匹配确立为标准指标。

SParC和CoSQL分别将Spider扩展到多轮和基于对话的交互。两者都保留了Spider的模式简单性和SQLite方言。

Spider-Syn通过用同义词替换自然语言来测试词汇鲁棒性，揭示了模型对列名匹配的依赖。它没有解决模式复杂度或方言差异的问题。

Dr. Spider引入了17种扰动类别以系统性地测试鲁棒性。这是先前最严格的鲁棒性研究，也是ESQ-Bench最接近的激励性工作，但所有扰动都应用于Spider模式和SQLite查询。企业模式特征和Oracle语义不在其范围之内。

KaggleDBQA使用了来自Kaggle竞赛的八个真实数据库，提供了首个在非策划模式上的NL2SQL评估。包含272个问题，其规模不足以进行统计可靠的类别级别断言。其中没有模式针对Oracle。

BIRD引入了12,751个问题，分布在更大、更复杂的模式中，并要求外部知识。BIRD代表了当前具有挑战性的NL2SQL评估的标准。模式平均有7.3张表（相比Spider的5.1张），但仍远低于企业复杂度。所有执行目标都是SQLite或PostgreSQL。

Spider 2.0针对企业级任务，包括数据仓库和复杂分析查询。它在生产相关性方面迈出了一大步，但未包含特定于Oracle的构造、系统性的模式复杂度层次或静默差异指标；ESQ-Bench通过在种子数据的企业代表性模式上隔离Oracle方言和SD效应，对Spider 2.0进行了补充。

### 3.2 对比分析

表1总结了ESQ-Bench相对于先前基准测试所解决的差距。对于每个先前的基准测试，Oracle方言列和静默差异指标列都是空的。

表1：NL2SQL基准测试对比。平均表数指每个模式的平均表数。企业列指示是否使用企业代表性模式特征。生产/真实数据库指在非合成的生产或竞赛数据库实例上评估（不是模式设计风格）。✓ = 存在，∘ = 部分，× = 缺失。
| 基准测试 | 年份 | 方言 | 平均表数 | 问题数 | 企业 | Oracle | SD指标 | 生产/真实数据库 |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| WikiSQL | 2017 | SQLite | 1.0 | 80,654 | × | × | × | × |
| Spider | 2018 | SQLite | 5.1 | 10,181 | × | × | × | × |
| SParC | 2019 | SQLite | 5.1 | 3,034 | × | × | × | × |
| CoSQL | 2019 | SQLite | 5.1 | 3,007 | × | × | × | × |
| Spider-Syn | 2021 | SQLite | 5.1 | 10,181 | × | × | × | × |
| KaggleDBQA | 2021 | 混合 | 8.0 | 272 | ∘ | × | × | ✓ |
| Dr. Spider | 2023 | SQLite | 5.1 | 10,181 | × | × | × | × |
| BIRD | 2023 | SQLite/PG | 7.3 | 12,751 | ∘ | × | × | ∘ |
| Spider 2.0 | 2024 | 混合 | 12.4 | 632 | ∘ | × | × | ∘ |
| ESQ-Bench | 2026 | Oracle+PG+MySQL+SS | 10/48/177 | 550 | ✓ | ✓ | ✓ | ∘ |
六个*合成企业代表性*模式（465张表，已填充数据）；550对经黄金标准验证的问题（2026年6月）。

## 4 ESQ-Bench设计

### 4.1 设计原则

ESQ-Bench被设计为一个*诊断工具*，而不仅仅是一个性能基准测试。其设计遵循四个原则：

**P1：分层复杂度**。模式复杂度不是二元的。仅测试简单或复杂模式的基准测试无法生成退化曲线，也无法识别模型失效的复杂度阈值。ESQ-Bench使用三个层次使退化函数可测量。

**P2：Oracle优先**。每个问题、模式和黄金标准查询都针对Oracle Database。这不是现有基准测试的方言翻译，而是为Oracle语义、语法和企业惯例从头开始的设计。

**P3：指标完整性**。该基准提供语义意图标注和干扰查询，从而能够进行超越执行匹配的评估，包括第5节中定义的静默差异率新指标。

**P4：完全可复现性**。所有模式、DDL、数据填充脚本、问题记录、黄金标准查询、语义标注和评估工具包都公开发布，并附有固定的依赖关系和模型版本规范。

### 4.2 构建状态

在当前版本中，所有六个模式均已完全定义、填充和验证。单个清单驱动方言感知DDL生成（generate_schemas.py）和确定性种子填充（seed_all.py），并通过逐表修正注入基准关键条件（空值比例、状态域分离、层级深度等）。