用表筛选与错误重试提升文本转 SQL

一个 text-to-SQL 方案拿到榜首，靠的却不是多轮 Agent 协作：先筛出问题需要的表，再让 Claude Opus 5.5 生成 SQL，执行报错才重试。schemagate 作者称，这套组合已经在 BIRD Mini-Dev 的三种数据库方言中排名第一。

对做数据库问答的程序员，更有参考价值的是它怎样控制模型看到的 schema。不过，榜单成绩、权限安全和真实业务可用性是三件事，这篇短文只提供了其中一部分证据。

三种方言第一，具体是在比什么

BIRD Mini-Dev 包含 500 道问题、11 个数据库，并提供 SQLite、PostgreSQL、MySQL 三种版本。 它根据 SQL 是否返回正确的结果行评分，而不是要求生成的 SQL 与参考答案逐字一致。BIRD 维护榜单并检查提交。

作者称，自己维护的 Apache-2.0 开源库 schemagate 已在三个方言栏目中全部排名第一。这里的成绩属于整套方案，包括表筛选、提示词中的列说明，以及负责生成 SQL 的 Claude Opus 5.5，不能全部归因于某个库。

还要分清两个榜单：Mini-Dev 不是使用隐藏测试集的 BIRD 主榜。作者披露，方案在主榜的首次测试结果为 72.11，重新运行的结果仍在等待中。

原文没有列出 Mini-Dev 三个方言的具体分数、领先幅度，也没有提供主榜重跑结果。因此，「三个栏目第一」不能扩展成「已经在 BIRD 主榜全面领先」。

先缩小表范围，再让模型写一条 SQL

作者描述的流程很短：

1. schemagate 挑出回答问题需要的表。
2. 提示词只携带这些表，以及 BIRD 提供的列说明。
3. Claude Opus 5.5 生成一条 SQL。
4. 如果查询执行报错，就把错误交给模型，让它再试一次。

这里没有生成多条候选 SQL 再投票，也没有持续规划、调用工具的 Agent 循环。执行报错后的重试仍然构成反馈步骤，但原文没有交代最多重试几次、怎样停止。

这个做法背后的思路不难理解：让模型面对更小的 schema，减少无关表干扰；同时保留列说明，帮助它理解字段的业务含义。但作者没有给出「完整 schema」与「筛选后 schema」的对照数据，无法据此量化筛表究竟贡献了多少收益。

想安装这个库，原文给出的命令是：

pip install schemagate

注意这里安装的是 Python 包；原文没有提供 Node API，也没有给出完整接入示例。

我的判断

我更看重它把权限处理放在模型看到 schema 之前。schemagate 的主要职责是访问控制：先移除调用者无权读取的表，再把剩余信息交给模型。这比只在提示词里要求模型「不要查询某些表」，多了一道明确的信息边界。

不过，隐藏表结构不能替代数据库执行层的权限校验。 原文没有说明查询执行时用了什么数据库身份，也没有展开行级、列级权限如何处理。开发者仍需单独设计这些边界。

作者认为，榜单表现说明过滤 schema 不损失准确率。这个表述需要收窄：现有成绩能说明，这套带过滤的组合可以取得较好的结果；缺少同模型、同提示词条件下的对照实验，还不能证明过滤完全没有准确率代价。Mini-Dev 也没有测试它的权限控制能力。

与候选投票或 Agent 循环相比，这套流程更容易理解和排查问题。但原文没有公布延迟、调用成本或失败类型，不能顺势认定它更快、更便宜。它提供的是一个值得验证的简洁方案，而不是复杂流程已经失去价值的证据。

能拿来做什么

• 做数据库问答原型时，可以先验证「筛表、补充列说明、生成一条 SQL、报错重试」这条流程，再根据实际失败案例决定是否增加候选投票或 Agent。
• 为业务库准备模型输入时，除了表名和字段类型，也整理字段的业务说明。原文明确使用了 BIRD 的列说明，复现时不能只保留筛表步骤。
• 给前端查询界面配套后端时，把调用者身份与可读表范围关联，并在数据库执行层校验权限；不要把权限约束只写进提示词。
• 评估方案时，分别记录 SQL 执行报错和结果错误。原文只描述了执行报错后的修复，查询能运行却答错问题，仍需要另外验证。