[Paper] CA‑SQL：复杂度感知推理时间推理用于 Text-to‑SQL 的探索与计算预算分配

Source: arXiv - 2605.08057v1

概述

本文介绍了 CA‑SQL，一种新的 Text‑to‑SQL 推理管道，它会根据每个查询的估计难度自适应搜索力度。通过对更难的问题动态分配更多计算资源，并采用进化式提示种子策略，作者在极具挑战性的 BIRD 基准的 “challenging” 级别上，推动了一个体量适中的大语言模型（GPT‑4o‑mini）所能达到的极限。

关键贡献

• Complexity‑aware compute budgeting – 一个轻量级的难度估计器决定为每个自然语言问题生成多少候选 SQL 语句。
• Exploratory prompt seeding – 一个自定义提示词，注入多样的 “种子” 查询，灵感来源于进化搜索，鼓励基础 LLM 产生更广阔的解空间。
• Novel voting selector – 生成后，一个简单而有效的投票方案根据执行反馈和软相似度指标挑选最有前景的候选。
• State‑of‑the‑art results on BIRD – 仅使用 GPT‑4o‑mini 在 “challenging” 开发集上取得 51.72 % 的准确率，超越更大模型基线。
• Open‑source‑friendly design – 该流水线依赖标准 LLM API，无需微调，易于集成到现有开发者工作流中。

方法论

1. 难度估计 – 对每个自然语言问题，使用快速启发式方法（例如，长度、提及的表/连接数量、词汇复杂度）预测一个难度分数。
2. 计算资源分配 – 该分数映射到预算：简单查询使用单次生成，而较难的查询则触发多次生成（例如，5‑10 个候选）。
3. 提示种子 – 与单纯的 “将此翻译为 SQL” 提示不同，系统会在前面添加一小组合成的种子查询，这些查询在结构上各不相同（不同的连接顺序、子查询、别名）。这会引导大模型探索替代的表述方式。
4. 候选生成 – 大模型根据每个预算槽位生成一批 SQL 语句，每个语句都以不同的种子为条件。
5. 执行与投票 – 将每个候选在目标数据库（或沙盒）中执行以收集执行结果。投票算法结合执行成功率、与其他候选的相似度以及软 F1‑style 的 token 重叠度，对输出进行排序。排名最高的 SQL 被返回为最终答案。

整个流水线仅在推理阶段运行；不需要梯度更新或模型再训练。

结果与发现

关键要点

• 动态预算对简单查询的收益递减，但对困难案例显著提升，验证了“一刀切”生成方式并非最佳。
• 提示种子在挑战层带来约 6‑8 % 的绝对提升，表明即使是冻结的 LLM 也能从更丰富的上下文中受益。
• 投票选择器优于简单的“首候选”或“多数投票”策略，尤其在执行反馈噪声较大时表现更好。

Practical Implications

• 开发者工具 – 将用户问题转换为 SQL 的 IDE 插件或低代码平台可以嵌入 CA‑SQL 的预算逻辑，仅在需要时分配更多计算资源，从而保持常规查询的低延迟。
• 成本效益扩展 – 组织可以通过在困难问题上有选择地使用额外的 API 调用，利用更便宜的 LLM 接口（例如小模型），实现接近最先进水平的性能。
• 稳健的数据访问层 – 需要生成临时分析（例如 BI 仪表盘）的应用程序可以使用投票选择器，防止出现会导致运行时错误的错误 SQL。
• 教育工具 – 自动化辅导系统可以向学生展示多种合理的查询表达式，促进对关系代数的更深入理解。

限制与未来工作

• 启发式难度估计器 – 当前的估计器是手工制作的；学习型预测器可以更好地捕捉细微的复杂性。
• 执行沙箱需求 – 投票依赖运行候选查询，在高度受限的环境或涉及隐私敏感数据时可能不可行。
• 对大规模模式的可扩展性 – 该方法已在 BIRD（中等规模模式）上验证；处理拥有数百张表的企业级目录可能需要额外的剪枝策略。
• 作者提出的未来方向 包括集成强化学习以在线适应预算，探索更丰富的种子生成（例如使用程序合成），以及将框架扩展到 SQL 之外的其他代码生成任务。

作者

• James Petullo
• Nianwen Xue

论文信息

• arXiv ID: 2605.08057v1
• 分类: cs.CL, cs.AI
• 出版时间: 2026年5月8日
• PDF: 下载 PDF