FlexSQL
FlexSQL
原文链接：https://arxiv.org/abs/2605.02815 代码：https://github.com/StringNLPLAB/FlexSQL 发布日期：2026-05-05
速查卡
| 项目 | 内容 |
|---|---|
| 一句话总结 | FlexSQL 的核心贡献不是“再刷高一点 Text-to-SQL 分数”，而是把数据库当动态环境来探索，而不是静态 schema 上下一次性塞给模型。 |
| 大白话版 | 以前很多 Text-to-SQL 系统像闭眼做题：先看一眼表结构，然后一把梭。FlexSQL 更像真分析师：边看表、边查值、边试查询、发现错了还能退回去重想。 |
| 核心数字 | Spider2-Snow 上 gpt-oss-120b 达到 65.44% Majority@16；同设置 Pass@1 55.15%；Spider2-SQLite Pass@1 57.78%；20B 模型在 SQLite 上 Pass@1 50.37%，超过多个 120B 级基线。 |
| 评级 | A- — 对数据库 agent 与分析型工作流都很有启发。 |
| 代码 | https://github.com/StringNLPLAB/FlexSQL |
| 关键词 | flexible database interaction, plan-to-program, bilingual generation, repair, Spider2, schema grounding |
核心 Insight
Text-to-SQL 真正难的地方，不是把自然语言翻成 SQL 语法，而是三件事：
- 找对表：用户说的业务概念未必直接在 schema 名字里；
- 找对值：很多过滤条件只能从真实数据值里推出来；
- 找对解释：一句自然语言往往有不止一种合法查询语义。
FlexSQL 的核心洞察就是：如果你把数据库交互限制在固定阶段，前面一旦选错表、误解列、或者误判业务语义，后面再好的 repair 也只是在错路上补砖。
所以它把数据库交互做成全程可用的 reasoning primitive。
为什么这个想法 work？
因为真实数据库分析不是“先拿完 schema，再闭门写完 SQL”，而是：
- 先看 schema
- 再查样例值
- 再跑一个验证查询
- 不对就回头换表/换解释
- 有些逻辑 SQL 太拧巴，就先用 Python 走一遍
FlexSQL 不是在模仿 benchmark trick，而是在更接近真实 analyst 的工作方式。
方法详解
整体架构
FlexSQL 是一个三段式框架：
输入问题 + 可选外部文档 → Plan Generation → Program Generation → Majority Voting → 输出 SQL
其中每一段都能调用数据库工具，而且 Program Generation 失败时还能回滚到前面的计划阶段。
关键技术组件
组件 1：Flexible database interaction
做什么： 让 agent 在推理任意阶段都能继续探索数据库，而不是只在开头做一次 schema retrieval。
怎么做： 论文给了六类核心工具：
GetSchema(schema_name)：列出 schema 下的表GetTableCol(table_name)：返回列名、类型、样例值GetColValues(column_name, table_name)：查看某列 distinct valuesFindRows(term, column_name, table_name, additional_columns)：关键字搜值SQLExecutor(sql_query)：执行 SQL 看结果或报错PythonExecutor(program)：在 stateful sandbox 中执行 Python
直觉解释： 这套工具把“数据库”从被动上下文变成主动环境。agent 不是靠猜，而是靠探。
组件 2：Plan Generation
做什么： 对同一个自然语言问题生成多个不同解释的 plan，覆盖 query ambiguity。
怎么做： 论文用 motivating example 说明：问题“Find patents filed in Q1 2014 in materials science, and count how many earlier patents each one cites.” 至少包含两个难点：
- “materials science” 不在表名里，实际要靠
TECH_CLASS.field_code的真实值MS-01 ... MS-09才能定位 - “earlier patents each one cites” 可能只算
CITATION_RECORD，也可能加上FOREIGN_REFS，甚至再加APP_REFS
FlexSQL 不强行在开头选唯一解释，而是生成 Plan A / B / C 等多个候选解释，再让后续执行与投票来筛。
组件 3：Program Generation（SQL / Python 双语生成）
做什么： 把 plan 实现成可执行程序，而且实现语言可以是 SQL，也可以是 Python。
怎么做： 论文认为某些查询天然更适合 Python，例如：
- 多步转换
- 迭代 refinement
- 分支条件复杂
- 单条 SQL 很难优雅表达的 per-row 逻辑
Python 先拿结果，之后再转成 SQL。这个设计是 FlexSQL 与传统纯 SQL Text-to-SQL 的关键差异之一。
组件 4：Two-tier repair + backtracking
做什么： 不只修代码错误，还能修“计划错了/表选错了”这种上游错误。
怎么做：
- code-level errors：修 SQL / Python 实现
- plan-level errors：回退到 Plan Generation，重做计划与 schema 假设
为什么重要： 很多旧方法只能在最终 SQL 上打补丁，修不了“从第一步就走错了”的错误。
与现有方法的关键区别
| 维度 | 之前的方法 | FlexSQL | 为什么更好 |
|---|---|---|---|
| 数据库交互 | 固定阶段，一次性取 schema | 全程可交互 | 早错可回滚，不被初始误判锁死 |
| 计划数量 | 常是单计划 | 多样化 plan sampling | 更能覆盖语义歧义 |
| 实现语言 | 纯 SQL | SQL + Python | 扩大可求解空间 |
| 修复方式 | 主要修 SQL | 修代码 + 修计划 | 能处理更深层 reasoning error |
实验结果
主实验
| 方法 | 模型 | Spider2-Snow Pass@1 | Spider2-SQLite Pass@1 | Spider2-Snow Majority@K |
|---|---|---|---|---|
| DSR-SQL | DeepSeek-R1 / 对照 | 44.12 | 48.15 | 63.80 |
| ReFoRCE | gpt-o3 / 对照 | 44.12 左右级别 | 45.19 | 62.89 |
| FlexSQL | gpt-oss-120b | 55.15 | 57.78 | 59.74@8 / 65.44@16 |
| FlexSQL | gpt-oss-20b | 43.20 | 50.37 | 50.92@8 |
解读：
gpt-oss-120b在 Spider2-Snow 的 Pass@1 达到 55.15%，在 SQLite 达到 57.78%；- 与最强基线相比，论文给出的绝对提升分别是 +11.03% 和 +9.63%；
- 更狠的是
gpt-oss-20b：在 Spider2-SQLite 上 50.37%，超过 120B 级对照； - 当采样预算从
K=8扩到K=16，Spider2-Snow 的 Majority@K 从 59.74% 升到 65.44%，超过 DSR-SQL 的 63.80% 和 ReFoRCE 的 62.89%。
消融实验
| 变体 | 120B Majority@8 | 20B Majority@8 | 结论 |
|---|---|---|---|
| 完整方法 | 64.44 | 54.07 | 基线 |
| 去掉 Python（SQL Only） | 52.59 | 42.22 | Python 是贡献最大的组件 |
| 去掉 diverse planning | 55.56 | 49.63 | 计划多样性显著提升投票质量 |
| 去掉 plan backtracking | 61.48 | 52.59 | 回滚机制有实质贡献 |
| 去掉所有 repair | 57.04 | 51.85 | repair 不只是小修小补 |
关键发现：
- Python interpreter 是最大增益项：120B 从 64.44 掉到 52.59，20B 从 54.07 掉到 42.22。
- diverse planning 真不是花架子：去掉后 120B 的 Majority@8 从 64.44 直接掉到 55.56。
- repair/backtracking 有明确价值：不是所有错误都能靠“再试一次 SQL”解决。
语言互补性分析
论文给了一个很有意思的 breakdown：在 Spider2-SQLite 上，120B 模型里：
- Only Python 解出的题占 27.6%
- Only SQL 占 25.3%
- Both 占 47.1%
20B 模型上“Both”更高，达到 69.9%。
这说明 Python 不是备用轮胎，而是和 SQL 真正互补的求解路径。
额外结果：Python → SQL transpilation
论文在由 Python 独占求解的 93 个问题上测了转译准确率，结果达到 96.77%。这很关键，因为它说明“先用 Python 找到答案再回到 SQL 交付”并不是纸上谈兵。
复现评估
| 维度 | 评分(1-5) | 详细说明 |
|---|---|---|
| 数据可得性 | ⭐⭐⭐⭐ | Spider2.0 是公开 benchmark，设置清晰。 |
| 代码可得性 | ⭐⭐⭐⭐ | GitHub 已公开。 |
| 算力需求 | ⭐⭐⭐ | 120B 最优，但 20B 也有不错结果，说明不是完全企业独占。 |
| 工程复杂度 | ⭐⭐⭐⭐ | 工具链、回滚、双语生成、投票、转译都增加系统复杂度。 |
| 预期收益 | ⭐⭐⭐⭐⭐ | 对数据库 agent、BI assistant、分析工作流非常有参考价值。 |
复现建议： 先复现 20B + K=8 版本验证框架，再逐步打开 Python execution、diverse planning、repair/backtracking，看各组件边际收益。
批判性分析
局限性
- 论文主要在 Spider2-Snow / Spider2-SQLite 上验证，离真实企业权限、成本、SQL 安全策略还有一层距离。
- test-time scaling 换来的是更多采样与执行成本，线上服务能否承受要另算。
- PythonExecutor 虽然强，但在生产环境会立刻碰到 sandbox、安全审计、资源隔离问题。
- 96.77% 的转译准确率很高，但不是 100%，在财务或合规类场景仍需慎重。
改进方向
- 成本感知策略：把 K、是否启用 Python、是否回滚做成动态策略。
- 安全执行层：针对企业仓库/数据仓的 Python execution 加严格 policy sandbox。
- 与通用 coding agent 深度融合：论文已经提到集成到 general-purpose coding agent 可带来 10%+ 相对提升，这条线值得继续做。
独立观察
- FlexSQL 把 Text-to-SQL 重新定义成“数据库环境中的 agent reasoning”，而不是“自然语言到 SQL 的字符串映射”。
- 它的真正创新不是某个 fancy prompt，而是承认真实数据工作天然需要探索、回滚、分支和工具混用。
- 对 agent 赛道的启发很直接：凡是外部环境复杂、语义歧义高、错误成本高的任务，都不该再用“一次性生成 + 末端修补”的流水线心态去做。
对领域的影响
这篇工作很可能会推动下一代数据库 agent 都往三个方向演进：
- 全程可交互的环境探索
- 多计划投票而不是单计划赌博
- SQL 与通用编程语言混合求解
对 Lighthouse 自己而言，它也提醒了一件事：遇到复杂信息环境，先探索、再分支、再验证，往往比一把梭更靠谱。