一种基于语义层的异构企业数据库自然语言转SQL智能体

# 一种语义层中介的自然语言到SQL智能体：面向异构企业数据库
来源：https://arxiv.org/html/2606.31041
2ndSaksonita Khoeurn3rdYe Ji YoonHa Jeong Kim and Saksonita Khoeurn 对本文贡献均等。通讯作者：Saksonita Khoeurn ([email protected])。

###### 摘要

在真实企业数据库上实现自然语言到SQL（NL2SQL）的任务，远比在学术基准上困难：模式包含数百张物理表，列名晦涩难懂，不同引擎的方言各异，单个分析问题可能涉及嵌套聚合、时间窗口逻辑和多表连接。直接用原始模式文本提示大型语言模型（LLM）会将其暴露于所有这些复杂性之中，从而生成脆弱的查询。本文提出一种语义层中介的NL2SQL智能体架构，将*意图*与*物理执行*解耦。不同于让LLM针对原始表编写SQL，该智能体通过一种紧凑的中间表示——我们称之为语义模型查询（SMQ）——在精选的语义层上进行推理；一个确定性引擎将SMQ编译为方言正确的SQL，智能体随后检查、组合并执行该SQL。系统遵循单工具思考-行动循环，在SQLite、BigQuery和Snowflake后端之间路由执行，并被打包为端到端评估框架。在由Gemini 3 Pro驱动下，该系统在包含547个任务的Spider2-snow基准（一套在Snowflake上执行的真实企业NL2SQL任务）上达到了94.15%的执行准确率——这是官方排行榜上第三高的成绩，远高于仅基于模式的基线方法。我们描述了组件设计、SMQ表示、智能体的探索策略以及各后端的结果，并讨论了在维护语义层作为LLM智能体上下文来源时，质量与过拟合之间的固有张力。

## I. 引言

将自然语言问题转化为可执行SQL（NL2SQL）是数据访问民主化的长期目标。近期的大语言模型（LLM）在Spider[2]和BIRD[3]等学术基准上取得了强劲结果，这些基准的模式较小，问题与单个查询的映射相对直接。企业环境则不仅在程度上，而且在本质上有所不同。Spider2基准[1]正是为了捕捉这一差距而引入：其任务针对生产级数据仓库，包含数百列、晦涩的命名约定、特定方言的函数，以及黄金答案通常跨越数十行SQL（包含公共表表达式（CTE）、窗口函数和多步聚合）的问题。Spider2上报告的准确率远低于Spider上接近饱和的数字，这证实了“将模式放入提示并要求生成SQL”的方法无法迁移到实际工作负载。

我们认为，这一困难有两个不同的来源。第一个是*接地（grounding）*：模型必须从庞大且自描述性差的模式中发现哪些物理表和列是相关的，以及它们如何连接。第二个是*组合（composition）*：模型必须在知道正确构建块后，组装出正确且符合方言的SQL。将这两个问题混淆在单一的自由形式生成步骤中，正是朴素提示方法脆弱的原因——一个错误的列名或连接谓词就足以使整个查询失败，而模型没有结构化的恢复表面。

本文提出*spider2-daquv-quvi*的架构，这是一个通过将*语义层*置于LLM与数据库之间来分离接地与组合的NL2SQL智能体。语义层是对每个数据库的精炼、面向业务的描述：表被封装为*语义模型*，暴露命名的*维度（dimensions）*、*度量（measures）*和*指标（metrics）*，并附有人类可读的描述以及它们映射到的物理列表达式。智能体从不直接看到原始模式；相反，它针对语义层发出紧凑的结构化查询——语义模型查询（SMQ）。一个确定性引擎将每个SMQ编译为方言正确的SQL并返回。智能体将这些编译后的片段用作*验证过的构建块*：它检查它们揭示的物理列表达式和连接模式，将它们组合成最终查询（添加SMQ编译器不支持的结构，如窗口函数或递归CTE），并在适当的后端上执行该查询。

本文的贡献如下：

- • 一种通过语义层和结构化中间表示（SMQ）中介LLM推理，从而将模式接地与SQL组合分离的NL2SQL系统架构（第三–四节）。
- • 一种单工具思考-行动智能体循环，其中SMQ编译用于*探索*，直接SQL执行是唯一的终端动作，以及执行此纪律的提示策略（第五节）。
- • 一个多后端执行与评估框架，可将查询路由到SQLite、BigQuery和Snowflake，并按照Spider2协议评分（第六节）。
- • 在包含547个任务的Spider2-snow基准上的实证研究，报告了94.15%的执行准确率，附带各后端细分结果，并与已发布排行榜方法进行比较，同时讨论了语义层质量与评估集过拟合之间的实际张力（第七–八节）。

## II. 相关工作

文本到SQL基准。Spider[2]确立了跨领域、多表语义解析的标准任务；BIRD[3]增加了更大、更脏的数据库，并强调效率和外部知识。Spider2[1]将标准提升至BigQuery、Snowflake和本地引擎上的企业级数据仓库，包含长且真实的黄金查询；这是我们针对的基准。我们的工作在Spider2-snow分片上进行评估。

用于文本到SQL的LLM方法。诸如DIN-SQL[4]、DAIL-SQL[5]和C3[6]等提示与分解方法通过模式链接、少样本选择和自我纠正改进了单次生成。诸如MAC-SQL[7]和CHESS[8]等多智能体和流水线系统引入了专门的分解器/选择器/精炼器角色以及模式修剪阶段。这些方法直接在物理模式上操作；我们的系统则通过一个精选的语义层来路由推理，将编译后的SMQ→SQL片段视为经过验证的接地证据，而非依赖模型从扁平模式转储中回忆物理名称。

语义层。商业智能语义层和指标框架（例如，dbt的MetricFlow[10]）允许分析师一次性定义维度、度量和指标，并在查询中重复使用。我们将此思想重新用作*LLM接地基板*：语义层既是模型对数据的视图，也是可编译、方言正确的SQL的来源。

LLM智能体与工具使用。ReAct[9]的思考-行动范式将推理轨迹与工具调用交织。我们的智能体采用严格的每步单工具变体，其中一个工具（SMQ编译）用于探索，另一个（SQL执行）是唯一的终止动作，从而约束智能体的动作空间以减少错误传播。

## III. 系统架构

图1展示了端到端架构。系统分为四层：（1）*编排层*，加载基准实例并驱动批量并行执行；（2）*QUVI NL2SQL服务*，托管LLM智能体和语义层；（3）一个确定性的*SMQ到SQL引擎*；以及（4）一个*多后端执行器*，在正确的数据库上运行最终SQL。每个实例作为一个独立工作流处理，由实例标识符和时间戳键控。

参见标题

图1：端到端架构。编排器将NL问题分派给QUVI服务，该服务在语义层上运行智能体循环。SMQ由引擎编译为SQL；最终SQL根据实例前缀路由到SQLite、BigQuery或Snowflake执行器。结果写入提交文件，并由Spider2评估套件评分。

### III-A. 编排层

入口点解析运行规范——数据库分片（lite/snow）以及实例选择器（显式ID、范围、前缀或全部）。实例加载器读取Spider2实例文件，其中包含自然语言问题和元数据。然后，执行服务通过线程池分派实例进行并行批处理，对速率限制（例如HTTP 429）进行退避，设置每实例超时和有界重试。对于每个实例，它生成一个工作流标识符并调用NL2SQL客户端，该客户端在每个数据库用户身份验证后，将问题发送给QUVI服务。

### III-B. QUVI NL2SQL服务

QUVI托管智能体和语义层。收到问题后，它（i）查找目标数据库的相关语义模型，（ii）运行思考-行动智能体循环（第五节），该循环生成SMQ和SQL，以及（iii）将SMQ编译委托给引擎。语义层是每个数据库的一个目录，包含源表定义、连接图、日期和时间骨架构配置，以及每个语义模型一个YAML文件。

### III-C. SMQ到SQL引擎

一个独立的引擎端点将SMQ确定性地编译为SQL（SmqToSql）。它将引用的每个维度/度量/指标解析为其物理列表达式，从连接图注入连接谓词，并以目标方言输出SQL。此组件是*物理名称的真实来源*：智能体在其最终查询中使用的每个表名和列表达式都来自编译器输出，而非幻觉。

### III-D. 多后端执行器

一个自定义执行服务器暴露单个端点，并根据实例ID前缀路由到正确的后端（表I）。每个执行器持有适当的凭据/驱动程序，并将结果作为行字典列表返回，编排器将其序列化为SQL文件和CSV以供评分。

表I：按实例标识符前缀的后端路由

## IV. 语义层与SMQ

### IV-A. 语义模型

每个物理表由一个语义模型封装，该模型赋予其业务名称，并公开带类型、带描述的数据元素。*维度*是聚合标准（分组/过滤键），*度量*是聚合目标，*指标*是预定义的聚合或基于度量和维度的衍生计算。至关重要的是，每个元素携带（a）一个人类可读的描述，在接地过程中由LLM读取，以及（b）一个`expr`字段，包含编译期间使用的精确物理列表达式。因此，抽象名称和物理表达式是分离的，这使得智能体可以推理*意图*，而引擎处理*物理映射*。清单1展示了一个片段。

```yaml
- name: RetailAnalyticsSalesModel
  table: ..._snowflake('RETAIL_ANALYTICS_SALES')
  dimensions:
    - name: asin
      type: varchar
      description: Amazon Standard Identification Number
      expr: ASIN
  measures:
    - name: orderedRevenue
      type: float
      description: ordered revenue
      expr: ORDERED_REVENUE
```

清单1：语义模型片段：一个维度和一个度量，每个都配对一个描述和一个物理表达式。

### IV-B. 连接图

模型间连接在每个数据库的连接图中声明为类型化边：`from`模型、`to`模型、连接键以及`on`谓词（给出左/右表达式，包括对脏键的转换，如`TRIM`）。编译器查询此图以自动组装连接，因此智能体无需为支持的情况重新发现连接谓词。

### IV-C. 语义模型查询（SMQ）

SMQ是智能体与引擎之间的中间表示。它是一个紧凑的JSON对象，包含三个列表——`metrics`（查询目标）、`filters`（WHERE条件）和`group_by`（分组维度）。元素通过统一的命名约定`ModelName__elementName`引用（对于维度和度量），指标则通过裸名称引用。清单2展示了一个SMQ示例及其作用。SMQ故意只涵盖常见的分析核心（选择、过滤、分组、声明的连接）；它不表达CROSS JOIN、任意子查询、高级窗口函数或递归CTE。这是有意为之：SMQ是一个*探索和接地*工具，SQL复杂性的长尾部分由智能体在编译器输出之上组合处理。

```json
{
  "metrics": ["RetailAnalyticsSalesModel__orderedRevenue"],
  "filters": ["RetailAnalyticsSalesModel__period='DAILY'"],
  "group_by": ["RetailAnalyticsSalesModel__asin"]
}
```

清单2：一个SMQ。引擎将其编译为方言正确的SQL，并返回SQL及结果预览。

## V. 智能体工作流

### V-A. 思考-行动循环

智能体运行一个受限的思考-行动循环。每轮它生成一个私有推理块，随后恰好一个工具调用。可用的工具有三个：`getModelDataElements`（列出选定模型的指标/维度）、`convertSmqToSql`（编译SMQ，返回SQL和五行结果预览）以及`execute`（运行最终SQL查询）。将每个响应限制为单一工具调用，缩小了动作空间并使轨迹可审计。算法1总结了该循环。

**算法1** 语义层中介的NL2SQL智能体循环  
1: **输入**: 问题 \(q\)，目标数据库的语义模型 \(M\)，方言 \(d\)  
2: \(E \leftarrow \textsc{getModelDataElements}(\text{relevant}(M, q))\)  ▷ 发现元素  
3: \(B \leftarrow \emptyset\)                  ▷ 已验证的SQL构建块  
4: **重复**  
5:    编写一个SMQ \(s\) 用于一个中间结果  
6:    \((sql, preview) \leftarrow \textsc{convertSmqToSql}(s)\)  
7:    \(B \leftarrow B \cup \{(\text{expr/table names from } sql)\}\)  
8: **直到** 构建块足以满足 \(q\)  
9: 从 \(B\) 组合最终SQL \(Q\)（添加CTE、窗口函数、子查询）  
10: **返回** \(\textsc{execute}(Q)\)  ▷ 单个终端动作

### V-B. SMQ用于探索的纪律

定义性的提示策略是，`convertSmqToSql`用于*探索*，而非生成最终答案。其目的是揭示抽象元素如何映射到物理列、方言的语法以及连接模式。智能体从编译后的SQL中提取物理表名和列表达式，并自行组装最终查询，应用超出SMQ表达能力之外的结构。严格的约束禁止在任何执行的SQL中将语义模型名称引用为物理表：只有从编译器输出中提取的名称才能出现。直接的模式自省（例如查询`INFORMATION_SCHEMA`）也被禁止。