ProSPy：面向企业文本到SQL的剖析驱动的SQL-Python智能体框架

# ProSPy：面向企业级Text-to-SQL的Profiling驱动SQL-Python智能体框架

来源：https://arxiv.org/html/2606.05836
杨赵瑞¹，郑华威²，杨森²，张宇辉³，李浩轩¹，余志臻⁵，易璇⁴，侯晨³，谢德峰³，胡超³，朱敏锋⁵，邓大臻¹²，冯浩哲³，黄丹青³，吴颖才¹，陈鹏³，陈为¹
¹浙江大学CAD&CG国家重点实验室 ²浙江大学软件技术学院 ³腾讯TEG ⁴北京大学数学科学学院 ⁵浙江大学

###### 摘要

大语言模型显著推动了Text-to-SQL系统的发展，但将其应用于企业级数据库仍然充满挑战。现实世界的数据库通常包含庞大且异构的模式、不完整的元数据、特定方言的SQL语法以及难以通过单个SQL查询解决的复杂分析问题。为应对这些挑战，我们提出ProSPy，一个面向企业级Text-to-SQL的Profiling驱动SQL-Python智能体框架。ProSPy将推理过程分为四个阶段：首先通过自动数据画像提取细粒度的数据证据，逐步将大型模式剪枝为任务相关的上下文，通过方言无关的SQL接口获取中间视图，最后利用Python进行灵活的下游分析。该设计结合了SQL在大型数据库上的高效性与Python分析的灵活性，同时减少了对不可靠元数据的依赖，提升了跨SQL方言的鲁棒性。在Spider 2.0-Lite和Spider 2.0-Snow上的实验表明，ProSPy在使用开源和闭源模型时均显著优于强基线方法，在Claude-4.5-Opus上分别达到60.15%和60.51%的执行准确率，且无需使用多数投票。进一步分析显示，ProSPy对SQL方言变化具有鲁棒性，并在模式召回率和精确率之间取得了良好的平衡。

ProSPy：面向企业级Text-to-SQL的Profiling驱动SQL-Python智能体框架

杨赵瑞¹，郑华威²，杨森²，张宇辉³，李浩轩¹，余志臻⁵，易璇⁴，侯晨³，谢德峰³，胡超³，朱敏锋⁵，邓大臻¹²，冯浩哲³，黄丹青³，吴颖才¹，陈鹏³，陈为¹
¹浙江大学CAD&CG国家重点实验室 ²浙江大学软件技术学院 ³腾讯TEG ⁴北京大学数学科学学院 ⁵浙江大学

††脚注：本研究完成于杨赵瑞在腾讯TEG数据计算平台部的实习期间。

## 1 引言

大语言模型（LLM）的最新进展显著提升了语义解析能力，使Text-to-SQL成为通过自然语言访问关系数据库的有前景的接口。在Spider（Yuet al.，2018 (https://arxiv.org/html/2606.05836#bib.bib19)）和BIRD（Liet al.，2023b (https://arxiv.org/html/2606.05836#bib.bib9)）等标准基准上，已有工作通过提示学习和上下文学习（Pourreza and Rafiei，2023 (https://arxiv.org/html/2606.05836#bib.bib11)；Zhanget al.，2023 (https://arxiv.org/html/2606.05836#bib.bib12)；Gaoet al.，2024 (https://arxiv.org/html/2606.05836#bib.bib13)）、测试时搜索与多路径推理（Liet al.，2025a (https://arxiv.org/html/2606.05836#bib.bib17)；Yuanet al.，2026 (https://arxiv.org/html/2606.05836#bib.bib16)；Pourrezaet al.，2025a (https://arxiv.org/html/2606.05836#bib.bib18)），以及通过监督微调或强化学习的后训练（Liet al.，2024 (https://arxiv.org/html/2606.05836#bib.bib15)，2023a (https://arxiv.org/html/2606.05836#bib.bib14)；Pourrezaet al.，2025b (https://arxiv.org/html/2606.05836#bib.bib23)；Liet al.，2025b (https://arxiv.org/html/2606.05836#bib.bib22)）取得了强劲性能。

尽管取得了这些进展，传统基准设置与企业级数据库环境仍存在显著差异。现实世界的模式通常更大、更异构，包含大量表、模糊的命名约定以及深层嵌套或半结构化字段。近期方法通过检索增强选择（Wanget al.，2025 (https://arxiv.org/html/2606.05836#bib.bib4)，2026 (https://arxiv.org/html/2606.05836#bib.bib3)）和智能体探索工作流（Leiet al.，2025 (https://arxiv.org/html/2606.05836#bib.bib1)；Caoet al.，2026 (https://arxiv.org/html/2606.05836#bib.bib10)）来应对这些挑战。然而，这些方法通常需要重复调用LLM和数据库探测来识别相关的模式元素并检查数据值，导致显著的延迟和计算开销。

参见图1的说明图1：ProSPy的概述，它结合了用于SQL检索的方言无关DSL和基于Python的分析，以支持可扩展的检索、屏蔽SQL方言差异，并为企业级Text-to-SQL执行复杂的数据分析。参见图2的说明图2：ProSPy框架的示意图。ProSPy包含四个阶段：（A）数据画像，（B）渐进式模式剪枝，（C）智能体数据获取，以及（D）Python分析。它从原始表中提取结构化数据证据，将大型模式剪枝为任务相关的上下文，通过方言无关的DSL-to-SQL接口获取中间视图，并利用Python解释器进行最终分析，生成结果CSV。除了模式规模，企业数据库通常还存在不完整或不可靠的元数据，使得模式语义难以解释。现实世界的查询也经常需要涉及多个中间视图和下游统计计算的复杂分析工作流（Leiet al.，2025 (https://arxiv.org/html/2606.05836#bib.bib1)）。虽然强化学习可以增强LLM的推理能力（Guoet al.，2025 (https://arxiv.org/html/2606.05836#bib.bib27)），但现有的推理数据主要集中在数学和编码领域（Maet al.，2026 (https://arxiv.org/html/2606.05836#bib.bib29)），而SQL生成领域的此类数据仍然稀缺（Yaoet al.，2025 (https://arxiv.org/html/2606.05836#bib.bib28)）。再加上数据库引擎之间的方言差异，这些因素使得直接生成SQL变得脆弱，导致在简单基准上表现良好的方法在企业级场景中性能下降。

为应对这些挑战，我们提出ProSPy，一个面向企业级Text-to-SQL的Profiling驱动SQL-Python智能体框架。如图1 (https://arxiv.org/html/2606.05836#S1.F1) 所示，ProSPy的动机源于SQL和Python互补的优势。SQL非常适合在大型数据库上进行可扩展的检索和轻量级聚合，但复杂的分析问题往往难以用单个查询表达。相比之下，Python为多步骤分析提供了灵活支持，但在直接访问大规模关系数据库方面效率低下且不切实际。因此，ProSPy将企业级数据推理分解为基于SQL的检索和基于Python的分析。

图2 (https://arxiv.org/html/2606.05836#S1.F2) 展示了ProSPy的整体框架。为了减少对提供的元数据的依赖，ProSPy首先对原始表执行自动数据画像，并提取结构化证据，如类型信息、统计信息、样本和嵌套字段结构。基于这些画像，ProSPy逐步将大型模式从表剪枝到列，生成紧凑的任务相关模式上下文。基于剪枝后的模式，ProSPy执行智能体数据获取，通过轻量级的、与方言无关的DSL构建中间视图，该DSL从可执行的SQL语法中抽象出检索意图，并编译成目标SQL方言。然后将视图作为CSV文件导出到Python环境，智能体在此执行灵活的下游分析并生成最终答案。

我们在Spider 2.0-Lite和Spider 2.0-Snow上系统评估了ProSPy，使用了一套全面的指标，包括用于端到端性能的执行准确率，以及用于模式链接质量的SRR、NSR、NSP和NSF。使用开源和闭源模型的实验表明，ProSPy显著优于强基线，在Spider 2.0-Lite和Spider 2.0-Snow上分别实现了60.15%和60.51%的执行准确率，且不依赖多数投票等测试时扩展策略。值得注意的是，两个基准上的性能相当，表明ProSPy对SQL方言变化具有鲁棒性，这得益于其方言无关的数据获取设计。进一步分析表明，ProSPy在模式召回率和精确率之间取得了良好的平衡，为下游推理提供了紧凑且任务相关的模式上下文。

## 2 预备知识与相关工作

##### 预备知识。

Text-to-SQL任务可以形式化定义如下。给定数据库模式E\mathcal{E}、自然语言问题Q\mathcal{Q}和辅助文档K\mathcal{K}，由θ\theta参数化的语义解析器ff旨在生成目标SQL查询SS：

S=f(Q,E,K∣θ)。S=f(\mathcal{Q},\mathcal{E},\mathcal{K}\mid\theta)。为了评估解析器，生成的查询SS在底层数据库引擎上执行，得到执行结果RR，然后与真实结果R⋆R^{\star}进行比较，以确定执行准确率（Leiet al.，2025 (https://arxiv.org/html/2606.05836#bib.bib1)；Liet al.，2023b (https://arxiv.org/html/2606.05836#bib.bib9)）。形式化地，给定包含NN个示例的基准，执行准确率（EX）定义为：

EX=1N∑i=1NI(Ri=Ri⋆)，\mathrm{EX}=\frac{1}{N}\sum_{i=1}^{N}\mathbb{I}(R_{i}=R_{i}^{\star})，其中I(⋅)\mathbb{I}(\cdot)表示指示函数。

对于模式链接评估，令Ti⋆\mathcal{T}_{i}^{\star}表示第ii个示例所需的黄金表集合，令T^i\hat{\mathcal{T}}_{i}表示检索到的表集合。严格召回率（SRR）衡量所有黄金表都被检索到的示例比例：

SRR=1N∑i=1NI(Ti⋆⊆T^i)。\mathrm{SRR}=\frac{1}{N}\sum_{i=1}^{N}\mathbb{I}\left(\mathcal{T}_{i}^{\star}\subseteq\hat{\mathcal{T}}_{i}\right)。非严格召回率（NSR）、非严格精确率（NSP）和非严格F1（NSF）进一步衡量表级别的检索质量。对于第ii个示例，它们定义为：

NSRi=|T^i∩Ti⋆||Ti⋆|,NSPi=|T^i∩Ti⋆||T^i|。\mathrm{NSR}_{i}=\frac{|\hat{\mathcal{T}}_{i}\cap\mathcal{T}_{i}^{\star}|}{|\mathcal{T}_{i}^{\star}|},\quad\mathrm{NSP}_{i}=\frac{|\hat{\mathcal{T}}_{i}\cap\mathcal{T}_{i}^{\star}|}{|\hat{\mathcal{T}}_{i}|}。NSFi=2⋅NSRi⋅NSPiNSRi+NSPi。\mathrm{NSF}_{i}=\frac{2\cdot\mathrm{NSR}_{i}\cdot\mathrm{NSP}_{i}}{\mathrm{NSR}_{i}+\mathrm{NSP}_{i}}。最终的NSR、NSP和NSF分数通过对所有NN个示例的相应逐示例分数取平均得到。

##### 相关工作。

大语言模型（LLM）强大的语言理解和代码生成能力，激发了大量将其应用于Text-to-SQL解析的研究。早期方法主要依赖于提示工程和上下文学习（Pourreza and Rafiei，2023 (https://arxiv.org/html/2606.05836#bib.bib11)；Zhanget al.，2023 (https://arxiv.org/html/2606.05836#bib.bib12)；Gaoet al.，2024 (https://arxiv.org/html/2606.05836#bib.bib13)），其中设计示例、分解策略和中间推理步骤，以从通用LLM中引出SQL生成能力。最近的研究进一步通过测试时计算提升性能，包括蒙特卡洛树搜索（Liet al.，2025a (https://arxiv.org/html/2606.05836#bib.bib17)；Yuanet al.，2026 (https://arxiv.org/html/2606.05836#bib.bib16)）和多路径推理或候选选择策略（Pourrezaet al.，2025a (https://arxiv.org/html/2606.05836#bib.bib18)）。这些方法在BIRD（Liet al.，2023b (https://arxiv.org/html/2606.05836#bib.bib9)）和Spider 1.0（Yuet al.，2018 (https://arxiv.org/html/2606.05836#bib.bib19)）等既定基准上取得了强劲结果。

尽管效果显著，现有方法在应用于Spider 2.0（Leiet al.，2025 (https://arxiv.org/html/2606.05836#bib.bib1)）等企业级Text-to-SQL基准时仍面临重大挑战。与早期基准相比，该设置涉及显著更大的模式、海量数据、异构的SQL方言、不精确的元数据以及复杂的分析工作流。这些特性使得模型难以识别相关上下文、构建合适的中间计算以及生成可执行的SQL查询。虽然监督微调（Liet al.，2024 (https://arxiv.org/html/2606.05836#bib.bib15)，2023a (https://arxiv.org/html/2606.05836#bib.bib14)）和强化学习（Pourrezaet al.，2025b (https://arxiv.org/html/2606.05836#bib.bib23)；Liet al.，2025b (https://arxiv.org/html/2606.05836#bib.bib22)）技术可以增强Text-to-SQL模型的推理和生成能力，但其实际部署仍受到数据标注成本高、SQL方言多样性以及难以覆盖企业特定分析模式等限制。

受LLM智能体最近成功的启发，越来越多的研究探索了复杂Text-to-SQL任务的智能体工作流。这些方法通常涉及两个阶段：模式链接，识别任务相关的模式E′⊆E\mathcal{E}'\subseteq\mathcal{E}；以及SQL生成，从选定模式中生成可执行的查询。对于模式链接，现有方法使用LLM识别相关表和列（Denget al.，2025 (https://arxiv.org/html/2606.05836#bib.bib2)；Caoet al.，2024 (https://arxiv.org/html/2606.05836#bib.bib6)），或采用带有迭代查询优化的向量检索（Wanget al.，2025 (https://arxiv.org/html/2606.05836#bib.bib4)，2026 (https://arxiv.org/html/2606.05836#bib.bib3)）。并行工作EviLink（Anonymous，2026 (https://arxiv.org/html/2606.05836#bib.bib30)）进一步引入了多路径假设模式 grounding 并通过投票估计不确定性。虽然有效，这些方法主要将模式 grounding 优化为中间步骤，而ProSPy则针对端到端的问题解决过程。

对于SQL生成，许多方法依赖测试时扩展，通过生成多个候选查询，通过自纠正进行优化（Pourreza and Rafiei，2023 (https://arxiv.org/html/2606.05836#bib.bib11)），并通过多数投票（Wanget al.，2026 (https://arxiv.org/html/2606.05836#bib.bib3)）或LLM重排序（Caoet al.，2024 (https://arxiv.org/html/2606.05836#bib.bib6)；Pourrezaet al.，2025a (https://arxiv.org/html/2606.05836#bib.bib18)）选择最终答案。虽然有效，但此类策略带来了巨大的计算开销和延迟，限制了它们在企业级场景中的实用性，因为在这些场景中，重复的模型调用和数据库执行代价高昂。

最近的一些方法进一步引入迭代探索，以应对大型数据库中不精确的元数据和复杂的模式结构（Haoet al.，2025 (https://arxiv.org/html/2606.05836#bib.bib24)；Caoet al.，2026 (https://arxiv.org/html/2606.05836#bib.bib10)；Wanget al.，2025 (https://arxiv.org/html/2606.05836#bib.bib4)）。这些方法与LLM和数据库引擎交互，以发现模式语义、检查数据分布并优化中间决策。然而，重复探索