PExA: Parallel Exploration Agent for Complex Text-to-SQL¶
会议: ACL2026
arXiv: 2604.22934
代码: 未公开
领域: LLM Agent / Text-to-SQL / 数据库问答
关键词: Text-to-SQL, LLM Agent, 并行探索, 软件测试, Spider 2.0
一句话总结¶
PExA 把复杂 Text-to-SQL 改写成“为自然语言查询生成并执行一组语义测试用例”的并行探索问题，通过 Planner、Test Case Generator 和 SQL Proposer 三个子代理在 Spider 2.0 上提升执行准确率，并把延迟控制在与强基线相近的水平。
研究背景与动机¶
领域现状：Text-to-SQL 已经从早期的解析模型发展到 LLM agent。面对 Spider 2.0 这类真实复杂数据库基准，系统通常需要 schema linking、数据库压缩、多步推理、执行反馈和自我修正，才能处理大表、多库、嵌套类型和长 SQL。
现有痛点：强性能往往靠更长的 sequential reasoning 或更多工具调用换来。一个 agent 先规划，再查 schema，再写 SQL，再执行，再修正，性能可能上升，但延迟也按步骤累加。交互式数据分析里，用户很难接受每个问题都等待很久。
核心矛盾：复杂查询确实需要探索更多数据库信息，但探索不一定必须串行。现有方法把用户问题当作单个长 SQL 生成任务，容易在一条推理链里卡住；如果拆成可并行验证的语义需求，就能同时收集证据。
本文目标：作者希望改善 Text-to-SQL 的性能-延迟 Pareto 前沿：既要在 Spider 2.0 上取得更高执行准确率，又要避免通过线性增加推理步骤来堆性能。
切入角度：论文借鉴软件测试。复杂程序不是一次性证明正确，而是通过覆盖不同功能需求的测试套件来验证。复杂 NL 查询也可以被看成若干语义需求的集合，先生成一批更简单的 SQL “测试用例”覆盖过滤、连接、聚合、存在性检查等局部语义，再用这些执行结果支撑最终 SQL。
核心 idea：把 Text-to-SQL 从单链生成改成测试覆盖式并行探索，用多条可执行 test-case SQL 同时探测数据库，最后聚合证据生成完整 SQL。
方法详解¶
PExA 的关键是把“想清楚最终 SQL”前置为“先验证一组小问题”。这些小问题不是普通 query decomposition，因为它们可以探索原始问题之外但相关的数据库信息，例如某个字段有哪些值、某个 join 是否能返回非空结果、某个过滤条件是否合理。测试用例执行结果成为最终 SQL 的 grounding context。
整体框架¶
系统包含三个子代理和两个工具。Planner 接收原始自然语言问题，生成一组自包含测试用例，并决定是否继续探索或进入最终生成。Test Case Generator 把每个自然语言测试用例转成 SQL，调用 SQL Executor 执行并根据错误反馈修正。SQL Proposer 只拿原始问题、测试用例 SQL 和执行结果，不拿完整数据库元数据，然后合成最终长 SQL。两个工具分别是 SQL Executor 和 Semantic Verifier：前者返回编译错误、空结果或成功结果；后者把 SQL 回译成自然语言并与原问题比较，识别语义偏差。
并行性贯穿三个位置。Planner 一次前向生成多条测试计划；Test Case Generator 对互不依赖的测试用例并行生成和执行；每个测试用例内部还一次性生成多种候选 SQL，形成 single-step multi-path search。最终延迟近似由最慢的一条分支决定，而不是所有分支延迟之和。
关键设计¶
-
测试覆盖式查询建模:
- 功能：把一个复杂用户问题拆成若干能独立执行的小 SQL 测试，用测试覆盖来逼近原查询语义。
- 核心思路：测试用例可以覆盖 filter、join、aggregation、existence check、值分布等局部要求，也可以探测原查询周边的数据库信息。每条测试 SQL 都应自包含、可执行，并返回能帮助最终合成的证据。
- 设计动机：普通子问题分解只复述原问题中的显式语义，而测试用例可以主动探索数据库的隐含结构和中间结果，更适合 Spider 2.0 这类真实复杂场景。
-
三子代理分工:
- 功能：把规划、局部 SQL 执行和最终 SQL 合成拆开，减少单个代理的上下文负担。
- 核心思路：Planner 负责语义需求和流程控制；Test Case Generator 结合轻量 schema linking 和压缩 schema 生成可执行局部 SQL；SQL Proposer 聚合测试结果生成最终 SQL，并用执行器和语义验证器检查。
- 设计动机：复杂 Text-to-SQL 的错误常来自早期规划和长上下文推理。分工后，每个代理只解决一个更窄的问题，最终 Proposer 也不需要读完整数据库元数据。
-
并行探索与单步多路径搜索:
- 功能：在不线性增加 wall time 的情况下扩大搜索宽度。
- 核心思路：规划阶段一次生成多条测试，执行阶段并行运行多个测试 SQL，每个测试又在一次 LLM 调用里产生多个候选方案，然后通过执行反馈快速筛除失败路径。
- 设计动机：Text-to-SQL 的不确定性往往来自 schema 选择、值约束和 join 路径。宽度搜索能提高命中正确语义的概率，而并行化避免把宽度全部转化成延迟。
损失函数 / 训练策略¶
PExA 是推理时 agent 框架，不训练新的模型，也没有监督损失或强化学习目标。主要“优化目标”体现在推理过程：最大化测试覆盖和最终 SQL 执行准确率，同时通过并行执行约束 wall time。实现上使用 LangGraph 组织 agent，并限制每个 LLM agent 的最大迭代次数防止循环；主实验使用 GPT-o3，部分分析比较 GPT-5、Claude Sonnet-4、Claude Opus-4 以及不同组件混搭。
实验关键数据¶
主实验¶
实验使用 Spider 2.0 的 Snow 和 Lite 版本。Snow 有 547 个样例、150+ 数据库，平均每个数据库约 800 列，使用 Snowflake dialect；Lite 排除 BigQuery 样例。指标为 Execution Accuracy (EX)、EX@4 和平均 wall time。
| 方法 | Snow EX | Snow EX@4 | Lite* EX | Lite* EX@4 | Wall Time (min) |
|---|---|---|---|---|---|
| Spider-Agent | 25.2 | 27.4 | 26.2 | 28.7 | 5.90 |
| ReFoRCE | 36.6 | 39.7 | 36.2 | 39.5 | 5.44 |
| Chat2DB | 44.1 | - | - | - | - |
| AgenticData | - | - | 44.5 | - | - |
| PExA | 45.7 | 49.5 | 46.6 | 49.9 | 5.55 |
| 额外对比 | Snow EX | Snow EX@4 | 说明 |
|---|---|---|---|
| PExA | 45.7 | 49.5 | 默认 schema linking |
| PExA w/ Gold Schema | 47.2 | 50.8 | 使用金标 schema 只提升约 1.5 点 |
| 更新 leaderboard 结果 | 70.2 | - | 论文称投稿时达到 Spider 2.0 新 SOTA |
消融实验¶
| 配置 | EX | 相对 Full | 解释 |
|---|---|---|---|
| PExA Full | 42.9 | - | 单次运行 Snow 分析设置 |
| w/o Plan-time parallelization | 40.0 | -2.9 | 规划阶段并行测试套件很关键 |
| w/o Test-time parallelization | 39.9 | -3.0 | 测试 SQL 并行生成/执行贡献最大 |
| w/o Semantic Verifier | 42.3 | -0.6 | 语义验证能修掉部分偏差，但不是主要瓶颈 |
| w/o Proposer | 41.1 | -1.8 | 直接由测试阶段产物返回会损失整合能力 |
| 并行度设置 | 执行分支=1 | 执行分支=2 | 执行分支=无限制 |
|---|---|---|---|
| 规划分支=1 | 38.4 | 39.1 | 40.0 |
| 规划分支=2 | 38.9 | 39.5 | 41.1 |
| 规划分支=无限制 | 39.9 | 41.6 | 42.9 |
| 延迟模式 | 总延迟估计 |
|---|---|
| 顺序执行相同搜索空间 | 680 秒 |
| 并行执行 | 351 秒 |
关键发现¶
- PExA 在 Snow 和 Lite 上都超过 ReFoRCE，Snow EX 从 36.6 提到 45.7，Lite EX 从 36.2 提到 46.6，且 wall time 5.55 分钟与 ReFoRCE 的 5.44 分钟接近。
- 消融显示两个并行组件各自贡献约 3 个 EX 点，比 Semantic Verifier 的 0.6 点更大，说明性能主要来自并行搜索宽度，而不是最后的语义检查。
- 限制规划分支和执行分支会连续降低准确率，从 42.9 降到 38.4；这给系统部署提供了可调旋钮，可以用更少分支换更低成本。
- Gold schema 只带来约 1.5 点提升，说明当前主要瓶颈不是 schema linking，而是复杂语义规划和长程逻辑组合。
- 错误分析指出主要失败来自语义误解和初始规划缺陷，而不是 SQL 语法错误。这与作者“未来应改进问题理解和计划搜索”的结论一致。
亮点与洞察¶
- 软件测试视角非常贴合复杂 Text-to-SQL。好的 SQL 不是凭空写出来的，而是要确认每个局部假设都能在数据库中跑通；PExA 把这种工程直觉显式变成 agent 结构。
- PExA 的测试用例不局限于原问题分解，可以探索非目标但相关的数据库信息。这比传统 decomposition 更主动，也更接近数据分析师在真实库里边查边写 SQL 的工作方式。
- 并行化不是简单“多采样”。它让每条探索路径有明确语义目标，避免无控制的 self-consistency 浪费 token。单步多路径搜索也比多轮串行反思更适合低延迟场景。
- Gold schema 对性能影响小这一点很有价值：在 Spider 2.0 这种大 schema 场景里，很多人直觉上会先优化 schema linking，但 PExA 表明高层计划和语义覆盖可能更值得投入。
局限与展望¶
- PExA 依赖强闭源 LLM，主实验使用 GPT-o3，成本和可复现性受限。虽然论文分析了其他模型混搭，但完整开放模型版本仍需验证。
- 并行探索降低 wall time，但不一定降低总 token 和 API 成本。对于生产环境，如何动态选择分支数、提前停止、复用测试结果，是关键工程问题。
- 测试用例质量高度依赖 Planner。如果一开始覆盖方向错了，后续并行执行只会更快地收集无关证据；错误分析也确认规划错误是主要瓶颈。
- Semantic Verifier 通过 SQL 回译自然语言判断语义，仍可能被 LLM 自身误判影响。更强的验证可能需要基于结果集、单元测试或符号约束。
- 目前只验证了 Spider 2.0，未来值得迁移到企业 BI、跨数据库方言、代码生成和其他需要“可执行测试覆盖”的 agent 任务。
相关工作与启发¶
- vs Spider-Agent: Spider-Agent 更像传统工具增强 agent，PExA 的差异在于把探索显式组织成并行测试套件，因此准确率和延迟前沿更好。
- vs ReFoRCE: ReFoRCE 强调数据库压缩和 inference-time scaling，PExA 也借鉴轻量 schema linking，但核心增量是 test-case SQL 的并行覆盖和最终证据聚合。
- vs query decomposition: 普通分解只拆原始问题的显式子语义，PExA 的测试用例可主动探索周边 schema、值分布和中间结果，覆盖范围更大。
- vs self-consistency / 多采样: 多采样常缺少方向控制；PExA 的每个分支都有测试目标和执行反馈，因此更像结构化搜索，而不是随机多生成。
评分¶
- 新颖性: ⭐⭐⭐⭐⭐ 用软件测试覆盖来重构 Text-to-SQL agent，很有辨识度，也自然解释了为什么能并行。
- 实验充分度: ⭐⭐⭐⭐☆ Spider 2.0 主结果、组件消融、并行度和延迟分析都到位，但闭源 LLM 依赖和开放复现不足。
- 写作质量: ⭐⭐⭐⭐☆ 方法叙述清晰，表格直接支持主张；若能给更多真实 test case 轨迹会更直观。
- 价值: ⭐⭐⭐⭐⭐ 对 Text-to-SQL、数据分析 agent 和一般工具使用 agent 都有可复用启发，尤其是“测试先行”的并行探索范式。