补齐 Oracle 方言约束，轻量模型首答率跃升

dev.to · AI#提示词#数据库#评测

Editor brief · 编辑速览

作者在 UniQL 的 1534 道 Oracle 题上，为 Gemini 2.5 Flash 补充表别名禁用 AS、保留字列名加引号两条规则，首次执行准确率从 35.0% 升至 64.5%。加入错误修复后的成绩却从 69.9% 降至 67.6%，说明首答能力和修复收益需要分别评估。

文章思维导图

Knowledge map

拖拽缩放

Full translation

完整中文译文

UniQL 是一个新的 benchmark，将 BIRD 的 1,534 道 text-to-SQL 问题转换为 16 种 SQL 方言。其中，Oracle 这一项很难。目前公布的最好成绩是 49.61%（Claude Sonnet 4.5），Gemini 2.5 Pro 的得分则为 26.14%。

我用 schemagate 搭配轻量模型 Gemini 2.5 Flash 跑了这个 benchmark。下文的分数均由 UniQL 自带的评估器在 Oracle Free 23ai 上测得。

第一次跑出来的成绩看着不错，但原因并不对。69.9% 的准确率主要靠的是 schemagate 的修复循环：执行查询，把 Oracle 的报错展示给模型，再让模型修正。如果只看首次尝试，Flash 的准确率只有 35%。这低于直接使用模型的成绩，也意味着不能拿包含修复循环的分数，与它们的单次尝试成绩公平比较。

几乎所有问题都源于两类错误。在首次查询失败的 694 条中：

551 条写了 FROM account AS a。Oracle 不允许在表别名前使用 AS。

100 条使用了名为 DATE 或 NUMBER 的列，却没有加引号。这两个名称都是保留字。

因此，现在只要目标数据库是 Oracle，schemagate 就会在 prompt 中告诉模型 Oracle 的这些规则。首次尝试的准确率从 35.0% 提升到了 64.5%，用更轻量的模型，比目前公布的最佳模型成绩高出了约 15 个百分点。首次查询失败的数量从 694 条降到了 85 条。其他数据库的 prompt 保持不变。

我从中得到的经验是：先测量，再调优；报告成绩时，要确保统计口径与其他人一致。修复循环是一种不错的设计，但它的成绩不该放进单次尝试结果那一栏。

结果已提交至 UniQL 排行榜：JerryGao818/UniQL#2。预测结果、评估器输出，以及用于复现结果的工作流，均位于 schemagate 仓库的 benchmarks/results/uniql_oracle 目录。

如果还要采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。