TRUST-SQL：面向未知数据库模式的工具集成多轮强化学习文本转SQL框架 TRUST-SQL: Tool-Integrated Multi-Turn Reinforcement Learning for Text-to-SQL over Unknown Schemas
通过四阶段交互协议和双轨GRPO训练，让LLM自主探索未知数据库并生成准确SQL
前置知识
Text-to-SQL
Text-to-SQL是将用户的自然语言问题自动转换为可在关系型数据库上执行的SQL查询的任务。例如，用户问「查询去年消费超过一百万的VIP客户姓名」，系统需要生成 SELECT name FROM vip_customers WHERE spending > 1000000 AND year = 2025 这样的SQL语句。该任务的核心挑战在于理解自然语言的语义意图，并将其精确映射到数据库的表结构（schema）、列名和查询逻辑上。近年来，随着大语言模型（LLM）的发展，Text-to-SQL取得了显著进步，但这些进步几乎都建立在一个隐含前提之上：模型在生成SQL之前，已经获得了完整的数据库模式信息。
这是本文研究的核心任务。理解Text-to-SQL的传统范式（即Full Schema Assumption）才能理解本文提出的Unknown Schema设置的根本意义。
Full Schema Assumption（全模式假设）
Full Schema Assumption是现有Text-to-SQL研究中的主流前提，即假设在任务开始时，数据库的完整模式（所有表名、列名、列类型、外键关系等元数据）已经全部注入到模型的输入上下文中。在这个假设下，模型只需要根据给定的schema和问题进行静态翻译，无需主动探索数据库。这一假设在学术基准测试（如Spider、BIRD）中普遍成立，因为这些数据集的数据库规模较小，模式可以完整放入上下文窗口。
本文的核心论点就是挑战这一假设。在真实企业环境中，数据库可能包含数百张表和海量噪声元数据，全模式假设不成立，因此需要全新的范式。
POMDP（部分可观测马尔可夫决策过程）
POMDP是一种序贯决策框架，由状态空间 $\mathcal{S}$、动作空间 $\mathcal{A}$、转移函数 $\mathcal{T}$、奖励函数 $\mathcal{R}$、观测空间 $\Omega$、观测函数 $\mathcal{Z}$ 和折扣因子 $\gamma$ 组成。与完全可观测的MDP不同，智能体无法直接观测到真实环境状态 $s_t$，只能获得部分观测 $o_t$。在本文中，真实环境状态代表完整的数据库模式，但智能体只能通过工具调用获得部分元数据反馈。智能体维护一个内部上下文状态 $c_t = (q, h_t, K_t)$ 来整合用户问题 $q$、交互历史 $h_t$ 和已验证的模式知识 $K_t$。
将Text-to-SQL任务形式化为POMDP是本文的理论基础，它精确刻画了Unknown Schema设置下智能体面对的信息不对称问题，并为后续的奖励设计和策略优化提供了数学框架。
GRPO（群组相对策略优化）
GRPO是DeepSeek-R1提出的强化学习算法，是PPO的简化变体。给定一个问题 $q$，GRPO采样一组 $G$ 条轨迹 $\{\tau^1, \tau^2, \ldots, \tau^G\}$，计算每条轨迹的奖励 $R^i$，然后通过组内归一化计算优势值 $A^i = (R^i - \mu) / (\sigma + \epsilon)$，其中 $\mu$ 和 $\sigma$ 是组内奖励的均值和标准差。该算法的核心思想是通过组内比较来消除基线估计的偏差，从而简化策略优化过程。相比PPO，GRPO不需要额外的价值网络，训练更加高效。
本文的Dual-Track GRPO是在标准GRPO基础上的关键创新，通过在token级别进行掩码优势值计算，解决了多轮交互中的信用分配问题。
信用分配问题（Credit Assignment Problem）
在多轮强化学习中，信用分配是指将最终结果的好坏归因到轨迹中具体哪一步动作的问题。在Text-to-SQL场景中，一个完整的交互轨迹可能包含多轮探索（查询元数据）和最终的SQL生成。最终的执行成功或失败可能是由多种原因造成的：模式探索阶段选错了表、SQL生成逻辑有误、或者两者兼有。如果使用单一的终端奖励来训练，模型无法区分探索质量和生成质量的贡献，导致优化信号混淆。
信用分配是本文提出的Dual-Track GRPO要解决的核心问题。通过将轨迹分成Schema Track和Full Track并施加token级掩码，本文实现了探索奖励和执行奖励的解耦优化。
研究动机
现有Text-to-SQL方法几乎全部建立在Full Schema Assumption之上，即假设完整数据库模式已预先注入模型上下文。这一假设在学术基准测试（如Spider、BIRD）中可以成立，因为这些数据集的数据库规模较小。但在真实企业环境中，数据库通常包含数百张表，模式结构复杂且频繁变动（表的增删、列的重构等）。将这些海量、嘈杂且可能过时的元数据一次性注入上下文是不现实的：一方面，有限的上下文窗口无法容纳如此大量的信息；另一方面，无关或过时的表信息会严重干扰模型推理，导致幻觉——即模型凭空编造不存在的表名或列名。更根本的问题是，现有方法都是被动翻译器（passive translator），它们只能在给定的静态上下文中工作，缺乏主动探索和验证数据库的能力。
本文的目标是本文的目标是提出一个能够在Unknown Schema设置下自主探索数据库并生成准确SQL的智能体框架。具体而言，TRUST-SQL旨在：（1）设计一种结构化的交互协议，引导智能体逐步探索、验证和提交数据库模式，防止幻觉；（2）提出一种新的强化学习训练策略，解决多轮交互中探索质量和SQL生成质量的信用分配问题；（3）在无需预加载任何数据库元数据的条件下，匹配甚至超越依赖全模式注入的现有方法。
与已有工作不同的是，本文的独特切入角度体现在两个层面。在任务层面，本文首次将Unknown Schema设置形式化为POMDP问题，将数据库模式视为隐藏状态，将工具调用反馈视为部分观测，为智能体的主动探索行为提供了理论基础。在方法层面，本文发现了两个关键设计原则：（1）通过实证研究发现，模式验证（schema verification）是抑制幻觉的关键——添加Propose阶段可将幻觉错误减少9.4倍；（2）通过将轨迹按Propose检查点分割为Schema Track和Full Track，实现了探索奖励和执行奖励的解耦优化。这两个设计相互支撑：Propose检查点既是推理的认知边界，也是训练的结构边界，使得Dual-Track GRPO能够为探索和生成提供独立的优化信号。
核心方法
TRUST-SQL的整体思路可以概括为「先探索验证，再生成确认」。从直觉上看，这就像一个有经验的DBA在面对一个陌生数据库时的工作方式：他不会凭记忆猜测表名和列名，而是先通过查询系统表（如sqlite_master）了解数据库结构，然后通过探查实际数据值来验证自己的理解，最后才基于确认无误的模式来编写SQL。在技术路线上，TRUST-SQL首先将这一交互过程形式化为POMDP，然后设计了一个四阶段交互协议（Explore-Propose-Generate-Confirm），其中Propose阶段作为强制性的认知检查点，迫使智能体在SQL生成之前提交已验证的模式知识。最后，通过Dual-Track GRPO训练策略，利用Propose检查点的结构边界，将探索质量和生成质量的奖励信号解耦，实现两者的协同优化。
TRUST-SQL的核心创新在于两个相互支撑的设计：四阶段交互协议和Dual-Track GRPO。与现有方法的本质区别在于：（1）现有方法要么是单轮静态翻译（假设全模式已知），要么虽然支持多轮交互但缺乏强制性的验证机制，导致智能体容易退化为参数化幻觉——即凭记忆猜测数据库结构。TRUST-SQL通过Propose阶段强制智能体提交已验证的模式知识，建立了从探索到生成的因果链。（2）现有多轮RL方法使用单一终端奖励或简单聚合中间信号，无法区分探索失败和生成失败。TRUST-SQL通过Dual-Track GRPO将轨迹按Propose检查点分为两个Track，并在token级别施加掩码，确保Schema Track只接收探索奖励，Full Track接收执行奖励。这种精细的信用分配带来了9.9%的相对提升。简而言之，Propose检查点既是推理的认知边界（防止幻觉），也是训练的结构边界（解耦奖励）。
方法步骤详情
TRUST-SQL的方法分为三个层面。第一层是POMDP形式化：状态 $s_t$ 代表完整数据库模式（对智能体隐藏），动作 $a_t$ 来自四类动作空间 $\mathcal{A}$，观测 $o_t$ 是工具执行反馈，内部状态 $c_t = (q, h_t, K_t)$ 整合用户问题、交互历史和已验证模式知识 $K_t$（初始化为空集 $K_0 = \emptyset$）。第二层是四阶段交互协议：（1）Explore阶段，智能体调用工具查询数据库元数据（如表名、列定义、外键关系），获得环境反馈；（2）Propose阶段，智能体提交已验证的模式知识 $K_t$，包括表名、列名和可选的关联关系，作为后续SQL生成的唯一依据；（3）Generate阶段，智能体基于 $K_t$ 生成候选SQL并执行，观察执行结果；（4）Confirm阶段，智能体提交最终SQL答案。协议允许非线性转换（如Generate后发现模式不完整可回退到Explore）。第三层是Dual-Track GRPO训练：对每个问题 $q$ 采样 $G$ 条轨迹，将每条轨迹 $\tau^i$ 分为Schema Track（从开始到Propose步骤，$T_{schema} = t_{propose}$）和Full Track（从开始到Confirm步骤，$T_{full} = T$），分别分配Schema奖励 $R_{schema}(\hat{K}, K^*)$ 和执行奖励 $R_{exec}(y, y^*) + R_{fmt}(\tau)$，通过token级掩码计算优势值，最终联合优化损失 $\mathcal{L}(\theta) = \mathcal{L}_{full}(\theta) + \lambda \cdot \mathcal{L}_{schema}(\theta)$。
技术新颖性
TRUST-SQL的技术新颖性体现在多个维度。首先，在任务定义层面，本文首次将Unknown Schema设置形式化为POMDP问题，区别于现有方法假设的全模式可观测环境，这一形式化为智能体的主动探索行为提供了坚实的理论基础。其次，在交互协议设计上，Propose阶段作为强制性认知检查点的设计是独创的。现有方法（如EGC、EC）缺乏这一中间验证步骤，导致智能体容易在长交互中失去上下文连贯性，退化为参数化幻觉。实证表明，添加Propose阶段可将幻觉错误从26.4%降至2.8%，实现了9.4倍的降低。再次，在训练策略上，Dual-Track GRPO利用Propose检查点的结构边界，在token级别施加掩码来隔离探索和执行的奖励信号。这是对标准GRPO的重要扩展——标准GRPO在多轮场景下面临严重的信用分配问题，因为单一终端奖励无法区分探索失败和生成失败。最后，在数据构建上，本文采用多模型共识策略（GPT-4.1、LongCat-Flash、Gemini-2.5-Pro）提取Ground Truth模式 $K^*$，至少两个模型一致才接受标注结果，确保了训练信号的可靠性。
实验结果
TRUST-SQL在五个基准测试上进行了全面评估，覆盖了4B和8B两个模型规模。在BIRD-Dev基准上，TRUST-SQL-4B通过Greedy解码达到64.9%，通过Majority Voting达到67.2%，超越了依赖全模式注入的强基线MTIR-SQL-4B（63.1%/64.4%）。TRUST-SQL-8B进一步提升至65.8%/67.7%，在BIRD-Dev上取得最佳成绩。在鲁棒性基准测试上，TRUST-SQL-4B在Spider-DK上达到71.6%/73.8%（超越MTIR-SQL-4B的71.2%），在Spider-Realistic上达到79.9%/82.5%（大幅超越MTIR-SQL-4B的78.7%）。TRUST-SQL-8B在Spider-Syn上达到75.4%/77.4%（超越OmniSQL-7B的69.7%/69.6%），在Spider-Realistic上达到82.1%/84.1%（超越所有基线）。最关键的是，与各自基模型相比，TRUST-SQL-4B在BIRD上相比Qwen3-4B（未知模式）提升了35.6%，五个基准的平均绝对提升达30.6%；TRUST-SQL-8B平均绝对提升16.6%。Schema Prefill实验表明，TRUST-SQL对预加载模式几乎不敏感——对TRUST-SQL-4B注入全模式反而导致Spider-DK下降2.4%，证明其主动探索策略已足够精确。Dual-Track GRPO相比标准GRPO在BIRD-Dev上带来了9.9%的相对提升（64.5% vs 60.9%）。训练两阶段消融实验显示，仅SFT达到46.2%，仅RL达到59.9%，两阶段联合达到64.9%，验证了SFT热身和RL优化的协同效果。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| BIRD-Dev（大规模真实数据库） | Execution Accuracy (Greedy) | 64.9%（4B）/ 65.8%（8B） | MTIR-SQL-4B 63.1% / SQL-R1-7B 63.7% | +1.8%（4B vs MTIR-SQL-4B）/ +2.1%（8B vs SQL-R1-7B） |
| Spider-Test（跨域组合泛化） | Execution Accuracy (Greedy) | 82.8%（4B）/ 83.9%（8B） | MTIR-SQL-4B 83.4% / OmniSQL-7B 87.9% | 4B略低于MTIR-SQL但无需预加载模式；8B超越MTIR-SQL-8B 83.4% |
| Spider-DK（领域知识鲁棒性） | Execution Accuracy (Greedy) | 71.6%（4B）/ 72.1%（8B） | MTIR-SQL-4B 71.2% / OmniSQL-7B 76.1% | +0.4%（4B）；8B低于OmniSQL-7B但无需预加载模式 |
| Spider-Syn（同义词替换鲁棒性） | Execution Accuracy (Greedy) | 74.7%（4B）/ 75.4%（8B） | MTIR-SQL-4B 78.6% / SQL-Trail-7B 72.8% | +2.6%（8B vs SQL-Trail-7B）；4B低于MTIR-SQL-4B但后者需全模式 |
| Spider-Realistic（歧义消解鲁棒性） | Execution Accuracy (Greedy) | 79.9%（4B）/ 82.1%（8B） | MTIR-SQL-4B 78.7% / SQL-Trail-7B 79.6% | +1.2%（4B）/ +2.5%（8B） |
| Spider 2.0 SQLite子集（企业级复杂数据库） | Execution Accuracy (Greedy / Pass@8) | 14.8% / 24.9%（8B） | GPT-4o 15.6% / DeepSeek-V3 15.6% | Pass@8显著超越所有基线（OpenSearchSQL+Arctic-7B 20.7%） |
局限与改进
作者明确承认了三个局限性。第一，推理开销：多轮交互范式天然比单轮方法带来更高的推理成本，每轮交互都涉及一次实时数据库调用。虽然附录D.1显示TRUST-SQL-4B的延迟仅为0.6秒、token消耗仅为2.83K（相比CHESS的251.3秒和320.8K token已有500倍和113倍的降低），但对于延迟敏感的部署场景仍有优化空间。第二，仅支持SQLite方言：训练和评估均在SQLite基准上进行，因为BIRD和Spider数据库均使用SQLite。扩展到PostgreSQL、MySQL等其他SQL方言是未来的重要方向。第三，固定轮次预算：最大交互轮次 $T$ 在训练时固定为10，这可能限制对具有极复杂模式的数据库的探索深度。从作者未提到的角度来看，我认为还有几个值得关注的局限：（1）训练数据规模受限——虽然使用了高效的9.2K SFT和11.6K RL样本，但这可能限制了模型对罕见SQL模式（如窗口函数、CTE）的泛化能力；（2）Ground Truth模式提取依赖多模型共识，对于特别模糊的数据库可能产生标注噪声；（3）未评估在动态变化的数据库环境中的适应能力——现实中的schema会持续演化，而训练环境假设模式固定。
独立分析的弱点
独立分析TRUST-SQL的弱点，我发现了几个值得改进的方向。首先，Schema Track和Full Track之间的权衡参数 $\lambda$ 需要手动调优。实验表明 $\lambda = 0.25$ 是最优值，但 $\lambda = 0.375$ 会导致智能体过度探索，平均轮次飙升且准确率急剧下降至54.2%。这说明两轨之间的平衡机制不够自适应，未来可以考虑基于当前策略的探索-利用平衡状态动态调整 $\lambda$。其次，训练轮次预算为10轮时表现最优，增加到12轮反而导致训练不稳定。这说明当前的奖励设计对冗余探索的惩罚不够有效——格式奖励 $R_{fmt}$ 仅为0.1的固定值，而探索行为的多样性奖励完全缺失。未来可以引入探索效率奖励（如每轮信息增益）来引导更高效的探索。再次，在Robustness基准上，TRUST-SQL-4B在Spider-Syn上（74.7%）明显低于MTIR-SQL-4B（78.6%），这说明主动探索策略在面对同义词替换时可能过度拟合了特定的列名模式，未来可以引入列名增强或语义匹配机制来提升鲁棒性。
未来方向
作者在结论和限制性分析中提出了多个未来研究方向。第一，推理效率优化：虽然TRUST-SQL的推理开销已远低于无训练的管道方法（如CHESS），但对于在线服务场景仍需进一步降低延迟。可能的方向包括早期终止策略（当置信度足够高时跳过后续轮次）和并行工具调用。第二，跨方言扩展：将框架从SQLite扩展到PostgreSQL、MySQL等企业常用SQL方言，这需要处理方言特定的语法差异和工具接口。第三，动态轮次预算：根据数据库复杂度自适应调整最大交互轮次，而非使用固定的10轮预算。从本文成果可延伸的方向包括：（1）将Unknown Schema设置推广到更广泛的数据库任务，如Text-to-API、数据集成等需要主动探索未知数据源的场景；（2）利用Pass@K与Greedy之间的差距（BIRD-Dev上Pass@8达到67.7% vs Greedy 65.8%），通过更长时间的RL训练或更精细的奖励函数来缩小这一差距；（3）将Schema Prefill实验中观察到的「预加载模式反而有害」的现象（Spider-DK下降2.4%）系统化研究，探索噪声模式注入对模型的干扰机制。
复现评估
复现评估方面，TRUST-SQL的复现条件较为理想。作者在论文中明确声明将完全开源代码（https://github.com/JaneEyre0530/TrustSQL），并在接受后公开训练数据集和模型权重。所有数据构建流程在附录A中有详细描述，训练超参数和硬件配置在附录B中汇总（Qwen3-4B使用8×A100 GPU进行60小时RL训练，Qwen3-8B使用32×A100 GPU进行40小时RL训练）。训练框架基于开源的SLIME框架。然而，复现仍面临几个挑战：（1）SFT阶段需要调用GPT-4.1-mini、GPT-4o-mini和DeepSeek-R1进行标注，涉及一定的API成本；（2）Ground Truth模式提取需要三个强模型（GPT-4.1、LongCat-Flash、Gemini-2.5-Pro）的共识，增加了数据准备的复杂度；（3）RL训练需要8到32张A100 GPU，对算力有一定要求。总体而言，代码和数据的开源将大幅降低复现门槛，但算力和API成本仍是制约因素。
论文图表
该图对比了两种Text-to-SQL范式。左侧展示现有范式（Existing Paradigm）：模型作为被动翻译器（Passive Translator），假设完整模式已预加载，在上下文窗口限制下直接生成SQL。面对未知表名（如用户问vip_customers但实际表名为client_orders），模型容易产生幻觉或执行错误。右侧展示TRUST-SQL范式（Active Explorer）：智能体通过工具调用（Tool Call）主动探索数据库环境（Hidden Schema），通过SchemaNeeded机制逐步确认实际的表名和列名（如确认实际表名为client_orders），最终生成基于验证元数据的SQL。
这张图直观地展示了本文的核心论点——从被动翻译到主动探索的范式转变。它是理解全文动机和方法设计的关键入口。
该图对比了同一问题在两种设置下的交互过程。左侧（Unknown Schema，6轮）：智能体先查询表名（T1），再查询表定义（T2），然后探查Charter_Funding_Type列的实际值（T3，发现Directly_funded），在T4提交验证后的模式，T5生成包含Directly_funded条件的正确SQL。右侧（Schema Prefill，4轮）：预加载全模式后，智能体跳过探索直接生成SQL，但由于未探查实际列值，无法发现Directly_funded谓词，生成的SQL仅过滤Charter_School_(Y/N)=1，遗漏了资金类型条件。
这个案例研究生动展示了Unknown Schema范式相比全模式预加载的核心优势：主动探索不仅发现了模式结构，还发现了驱动SQL生成逻辑的关键数据值。