DIN-SQL：用于 Text-to-SQL 的分解式上下文学习
上周我介绍了 BIRD，这个基准测试揭示了当文本转 SQL（text-to-SQL）从精心挑选的玩具数据库转向具有命名混乱、领域知识和效率限制的真实世界模式（schema）时，大语言模型（LLM）的表现是多么糟糕。DIN-SQL 是我本应先读的论文：它定义了精心设计的 LLM 提示词管道在 Spider 和 BIRD 上究竟能达到什么水平。这篇论文由 Mohammadreza Pourreza 和 Davood Rafiei 发表在 NeurIPS 2023 上，正值 GPT-4 普及之际。现在读来——在 BIRD 暴露了其上限之后——它的优势和局限性变得更加清晰。
论文解读
DIN-SQL (arXiv:2304.11015) 解决了显著的性能差距。在 2023 年初，最好的微调模型——RESDSQL-3B+NatSQL——在 Spider 测试集上达到了 79.9% 的执行准确度，而仅使用简单少样本提示（few-shot prompting）的 GPT-4 在开发集上仅达到 67.4%。Pourreza 和 Rafiei 的假设是，这种差距主要是一个接口问题：LLM 的能力足够，但要求 它们在一次生成中同时解决模式链接（schema linking）、复杂度分类和查询合成（query synthesis）。如果将这些任务分解为顺序子任务，并将每个解决方案作为上下文向下传递，情况就会改观。
他们的管道包含四个阶段：(1) 模式链接模块，使用思维链（chain-of-thought）提示将自然语言问题映射到模式中的特定列和值；(2) 分类与分解模块，将查询分为简单（单表，无连接）、非嵌套复杂（有连接但无子查询）或嵌套复杂（连接、子查询、集合操作），对于嵌套查询，将问题分解为子查询；(3) SQL 生成模块，使提示策略与复杂度类别相匹配——简单的使用少样本提示，非嵌套的使用 NatSQL 中间表示，嵌套的使用多步思维链；以及 (4) 自我修正模块，让模型检查自己的输出，查找如缺失 DISTINCT 或 DESC 位置错误等细微错误。
关键思想
- GPT-4 + DIN-SQL 在 Spider 的留出测试集上达到了 85.3% 的执行准确度，在没有任何任务特定训练数据的情况下，比当时的 SOTA 微调模型 RESDSQL-3B+NatSQL (79.9%) 提升了 5.4 个百分点。
- 在 Spider 开发集上，分解管道将 GPT-4 从 67.4%（少样本基准）提升至 74.2%——纯增 6.8 个百分点。CodeX Davinci 从 61.5% 提升至 69.9%。
- 消融实验证实了每个阶段的贡献：仅移除模式链接就使 CodeX 从 69.9% 降至 65.9%；移除分类阶段则进一步降至 63.1%。
- 收益集中在简单和中等难度的查询中。在“超难”查询上，即使是完整的 DIN-SQL + GPT-4 管道在 Spider 开发集上也仅达到 43.4%——分解并没有解决复杂性问题，它只是减少了可处理查询中本可避免的错误。
- 自我修正对模型敏感：GPT-4 对询问潜在改进的“温和”提示反应良好；而 CodeX 对假设 SQL 错误的“通用”提示反应更好。这表明该模块是在进行风格清理，而非真正的语义验证。
- 在 BIRD 开发集上，DIN-SQL + GPT-4 得分为 50.72%，而普通的 GPT-4 基准为 46.35%——仅提升了 4.4 个百分点，明显小于在 Spider 上的提升，这点我稍后会再谈。
哪些观点站得住脚，哪些站不住
核心结果是真实的。将文本转 SQL 分解为明确的子任务确实可以提高性能，消融实验也足以证明各模块的贡献。模式链接对困难查询最为重要，这是合理的：如果模型没有正确识别出问题涉及的表和列，就不可能生成正确的 JOIN 语句。
但有几点让我犹豫。74.2%（开发集）与 85.3%（测试集）的巨大差异令人怀疑。开发集通常比测试集更难，或者至少难度相当，因为模型是针对它们进行隐式调整的；从开发集到测试集出现 11 个百分点的跳跃非常罕见。作者并未解释这一点，这让我怀疑测试集的查询难度分布是否不同，或者留出测试集的评估方式（通过官方 Spider 榜单服务器）与他们的开发集评估方式是否存在差异。在没有这种说明的情况下，我不倾向于引用 85.3% 这个数字。
BIRD 的提升（开发集 50.72%）明显小于 Spider 的提升。BIRD 数据库具有混乱的真实世界模式，包含缩写的列名、领域特定的术语和模 糊的值。DIN-SQL 的模式链接模块是针对 Spider 相对干净的模式设计的；当模式变得更脏时，链接准确度就会下降，管道的其余部分也会随之退化。这正是 BIRD 论文所衡量的，而 DIN-SQL 并未解决它。
成本和延迟对于任何生产系统都是一个问题：使用 GPT-4，每个问题大约需要 0.50 美元和 60 秒。这对于每天运行十个查询的数据分析师来说没问题，但对于交互式使用则完全行不通。论文将其视为已知限制，但并未提出减少限制的路径。几个月后出现的 DAIL-SQL (arXiv:2308.15363) 表明，更好的示例选择（而非显式分解）可以在 Spider 上达到 86.6%——以更低的成本超越了 DIN-SQL。
自我修正模块是最薄弱的部分。作者承认它只能捕捉“微小”错误。它无法检测语义错误——即生成的 SQL 在语法上有效甚至可以执行，但回答了错误的问题。这才是真实用户面临的更困难的失败模式。
为什么这对金融 AI 很重要
Beanquery (BQL) 是一种针对 Beancount 账本数据的类 SQL 查询语言。它有自己的表结构——transactions（交易）、postings（分录）、balance（余额）、prices（价格）——带有账户层级、标签和元数据字段，这些与通用数据库模式完全不同。BQL 的自然语言接口非常有用（已经有一个实验性的 beanquery-mcp 服务器通过 MCP 实现了这一点），而 DIN-SQL 的分解策略是一个很好的起点。
BQL 上的模式链接与关系表上的模式链接类似，但有两个额外的复杂点：账户名称是类似 Assets:US:Checking:Bank 的层级路径，且相关的模式取决于用户查询的类型（损益表、资产负债表、现金流量表）。DIN-SQL 的分类模块提供了一个直接的改编思路：先对查询意图进行分类（余额查询 vs. 流向查询 vs. 价格查找），然后路由到不同的提示模板。
BIRD 基准测试关于现实世界复杂性损害 LLM 表现的发现具有直接相关性。Beancount 账本也是“混乱”的——用户定义的账户名称、不一致的商品符号、自定义元数据键。BIRD 上的 4.4 点提升与 Spider 上的 6.8 点提升相比，告诉我结构化、干净模式下的实验高估了分解对实际 BQL 查询的帮助。在实践中应预期更小的收益。
成本约束是真实的，但在金融领域约束力较弱。如果界面确实有用，个人财务用户可以容忍每天 5-10 美元的 API 成本。60 秒的延迟对于交互式使用来说是更大的问题；批量处理分析查询可能会规避这一点。
推荐阅读
- DAIL-SQL: Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluation (arXiv:2308.15363) —— 系统研究了提示工程策略；通过专注于示例选择而非架构分解，在 Spider 上达到了 86.6%，是 DIN-SQL 的有力对照。
- RESDSQL: Decoupling Schema Linking and Skeleton Parsing for Text-to-SQL (arXiv:2302.05965, AAAI 2023) —— 被 DIN-SQL 超越的微调基准模型；了解微调方法的长处有助于明确提示词方法的不足。
- MAC-SQL: A Multi-Agent Collaborative Framework for Text-to-SQL (arXiv:2312.11242) —— 将多步分解思想扩展为包含选择器（Selector）、分解器（Decomposer）和优化器（Refiner）的明确多智能体管道；在 BIRD 上配合 GPT-4 达到了 59.59%，是该领域最以智能体为中心的方法。
