PV-SQL: Synergizing Database Probing and Rule-based Verification for Text-to-SQL Agents¶

会议: ACL 2026
arXiv: 2604.17653
代码: GitHub
领域: Text-to-SQL / Agent
关键词: Text-to-SQL, 数据库探测, 规则验证, 语义约束, Agent框架

一句话总结¶

本文提出 PV-SQL，一个 Agent 式 Text-to-SQL 框架，通过 Probe（迭代生成探测查询发现数据库值格式/列语义/表关系）和 Verify（基于模式匹配提取可验证约束并构建检查清单）两个互补组件，在 BIRD 基准上比最佳基线高 5% 执行准确率和 20.8% 有效效率分。

研究背景与动机¶

领域现状：Text-to-SQL 在 LLM 加持下取得重大进展，但面临持续挑战——schema 理解、值锚定（将自然语言映射到精确数据库值）和约束满足（确保 SQL 忠实捕捉所有语义）。

现有痛点：(1) 约 41% 的失败来自数据库误解——模型不知道"California"存为"CA"还是全称；(2) 即使理解正确，SQL 生成本身缺乏验证机制——可能产生语法正确但语义错误的查询；(3) 现有验证方法（LLM 自验证/测试用例生成）不可靠或计算昂贵。

核心矛盾：仅依赖 schema 描述（DDL）不包含实际数据值，但将所有值放入提示又不可行。需要按需、问题驱动地探索数据库内容。

本文目标：通过自适应数据库探测解决理解错误，通过确定性规则验证解决合成错误。

切入角度：Probe 增强输入（用真实数据库证据丰富上下文），Verify 增强输出（确保语义约束被满足）——两者解决互补的失败类型。

核心 idea：让 SQL Agent 像数据分析师一样先"看看数据长什么样"再写查询，然后像代码审查者一样逐条检查约束是否满足。

方法详解¶

整体框架¶

分两阶段：(1) Probe 阶段——Agent 迭代生成临时 SQL 查询探索数据库（最多 5 轮），发现值格式、列语义等并积累到上下文 \(G\) 中；(2) Verify & Repair 阶段——用模式匹配从问题中提取 10 类可验证约束（如 DISTINCT/TOP-K/COUNT 等），生成 SQL 后检查约束满足情况，不满足则迭代修复（最多 5 轮）。

关键设计¶

自适应数据库探测 (Database Probing):
- 功能：按需发现数据库中的值格式和语义信息
- 核心思路：Agent 在循环中决定是否需要更多探测。如果需要，生成带 LIMIT 子句的 SELECT 查询检索相关记录样本。执行后总结发现（如"California 存为 CA"、"late 表示 ship_date > required_date"）并积累到上下文 \(G\)
- 设计动机：与静态上下文增强（基于相似度检索）不同，探测是问题自适应的——不同问题需要探索不同的数据库方面
规则验证与修复 (Verify & Repair):
- 功能：确保 SQL 满足问题中隐含的语义约束
- 核心思路：用模式匹配从问题中提取 10 类约束（DISTINCT→"unique"/"distinct"，TOP-K→"top/first N"，COUNT→"how many"等），生成确定性检查清单。SQL 经语法检查→执行检查→约束检查的流水线，每个违规生成描述性错误消息指导修复
- 设计动机：规则验证可靠（确定性模式匹配）、轻量（无需 LLM 调用）、可解释（每个约束来源明确）。优先精确度而非召回——遗漏约束可接受，误报会引入不必要的修复
Probe + Verify 的互补性:
- 功能：分别解决理解错误（ε_D + ε_Q）和合成错误（ε_S）
- 核心思路：Probe 通过真实数据库证据解决 41.3% 的数据库误解和部分 24.8% 的问题误解；Verify 通过约束检查清单解决 33.9% 的合成错误
- 设计动机：错误分析驱动的设计——两个组件各自针对一类主要失败模式

损失函数 / 训练策略¶

免训练框架。支持 6 种基础 LLM（GPT-4o/4.1、Claude 3.5/3.7、Gemini 2.0/2.5）。

实验关键数据¶

主实验¶

BIRD 基准执行准确率

方法	执行准确率(%)	有效效率分
最佳基线 (TS-SQL)	~60	~66
PV-SQL	65.12	86.9

消融实验¶

配置	执行准确率	说明
PV-SQL	65.12	完整
w/o Probe	60.8	去掉探测，-4.3pp
w/o Verify	62.1	去掉验证，-3.0pp
w/o 两者	57.3	回退到基线

关键发现¶

Probe 和 Verify 分别贡献约 4.3pp 和 3.0pp 的提升，且两者叠加效果接近各自之和
PV-SQL 的 token 消耗比 TS-SQL 更低——规则验证比 LLM 生成测试用例更高效
Probe 在"hard"难度问题上提升最大——这些问题最需要值锚定
约束提取的精确度 > 90%——确认了优先精确度策略的正确性

亮点与洞察¶

"先看数据再写查询"是一个非常实用且直觉化的策略——模拟了人类数据分析师的工作流
规则验证作为 SQL 的"测试用例"是一个巧妙的类比——SQL 天然缺少测试用例，但问题本身蕴含可验证的约束
10 类约束的模式匹配规则简单但有效——体现了"简单方案优先"的工程哲学

局限与展望¶

规则验证只覆盖 10 类约束，复杂语义约束仍依赖 LLM 理解
探测最多 5 轮可能不足以处理非常复杂的数据库
仅在 BIRD 系列基准上验证
探测查询可能泄露敏感数据信息

评分¶

新颖性: ⭐⭐⭐⭐ Probe+Verify的互补设计新颖，规则验证的切入角度实用
实验充分度: ⭐⭐⭐⭐⭐ 7基线+6LLM+3基准+详细消融+错误分析
写作质量: ⭐⭐⭐⭐⭐ 问题驱动，动机清晰，例子生动
价值: ⭐⭐⭐⭐⭐ 对Text-to-SQL实用化有直接推进