ROSE:一种以意图为中心的NL2SQL评估指标 ROSE: An Intent-Centered Evaluation Metric for NL2SQL
提出Prover-Refuter对抗级联，以意图取代标准SQL进行NL2SQL评估
前置知识
NL2SQL（自然语言到SQL）
NL2SQL任务的目标是把用户自然语言问题 $Q$ 转换为可在数据库 $D$ 上执行的SQL $S$。BIRD、Spider等基准提供标准SQL $S_g$，按执行结果 $E_g$ 与预测结果 $E_p$ 是否匹配判断正确性。它是数据库自然语言接口和Text-to-SQL系统的核心。
ROSE直接重新定义NL2SQL任务中最关键的评估环节，是这一领域判断'模型答对了没有'的事实标准。
Execution Accuracy（EX）
EX是NL2SQL最常用的评估指标，定义为 $EX(S_p,S_g,D) = (E_p \equiv E_g)$，即只有当预测SQL的执行结果与标准SQL的结果集完全一致才算正确。它被BIRD、Spider等基准默认采用，但严格要求单一参考SQL的等价性。
ROSE的所有动机都源自EX的三个系统性缺陷，理解EX的局限性是理解ROSE工作必要性的前提。
LLM-as-a-Judge（以大模型为裁判）
LLM-as-a-Judge范式利用大模型的推理能力评估模型输出，常见做法是把问题、预测答案、标准答案与执行结果打包为prompt喂给LLM并由其给出判断。本文的SQL Prover与Adversarial Refuter都建立在OpenAI o3、DeepSeek-R1等推理模型之上。
ROSE本质上是LLM-as-Judge范式在NL2SQL领域的特定化设计，了解这一范式有助于把握ROSE的能力上限与失败模式。
Cohen's Kappa（κ）
Cohen's Kappa衡量两位标注者之间的一致性：$\kappa = (p_o - p_e)/(1 - p_e)$，其中 $p_o$ 是观测一致率，$p_e$ 是偶然一致率。相比简单的Accuracy，它对类别不平衡更鲁棒，常被视为衡量'判断质量'的金标准。
ROSE把Cohen's κ 作为主指标，相比Accuracy更能反映其在'正确类'样本稀缺的不平衡验证集上的真实优势。
研究动机
NL2SQL领域长期以Execution Accuracy（EX）作为评估的事实标准，但EX存在三种结构性缺陷，已经严重误导了模型排行榜和研究方向。第一，实现变体问题：例如预测SQL与gold SQL只是投影列顺序不同、列名加引号、SELECT后字段顺序调整、值格式化方式不同，EX就给判错；ETM等结构感知指标通过复杂归一化能缓解，但仍然在'距离参考有多近'的层面比对，而非在'是否回答了用户问题'的层面判断。第二，问题歧义：很多自然语言问题存在多种合理解读，不同解读可能产生不同但都合理的SQL，作者团队的审计显示BIRD Dev上大约25%的样本被至少一位标注者标记为有疑义。第三，gold SQL错误：标注本身的错误也会被EX放大传播。NL2SQL-BUGs（Liu et al., 2025b）报告BIRD Dev的ground-truth错误率高达6.91%；Ambrosia（Saparina and Lapata, 2024）则发现超过一半的'失败'实际由歧义导致。换言之，EX惩罚的不是'模型错了'，而是'模型没去匹配某一个特定的参考SQL'。
本文的目标是本文的目标是构建一个**以意图为中心**的评估指标，摆脱'必须与单一参考SQL一致'的范式。ROSE要回答的核心问题是：'预测SQL是否回答了用户的问题？'同时它还要能诊断数据集问题——能够自动识别哪些样本是ground-truth错误（GoldX），哪些是问题本身有歧义（AmbQ）。可量化目标包括：在585条专家一致标注的验证集上把Cohen's κ 从当前最强基线FLEX的56.70%提升到80%以上，并作为工具对19个主流NL2SQL方法做大规模重评估，揭示EX范式下的'模型进步'中有多少其实是评估失真。
与已有工作不同的是，现有LLM-as-Judge方案（如LLM-SQL-Solver、FLEX）虽然把一致率推到高于EX的水平，但仍然把ground-truth当作'必须对齐的参考'，因此会延续前两类缺陷——相同的实现变体会被打错，同样的歧义会被单方面归咎于模型。本文的核心切入角度是**把ground-truth SQL从'匹配标准'重新定位为'对抗证据'**：SQL Prover先独立判断（不看gold），Adversarial Refuter再用gold作为'反方证据'挑战Prover的肯定判断，从而在抑制过度宽松的同时降低对单一参考的依赖。这一'先独立判断、后对抗裁决'的两级级联结构，是本文最独特的视角。
核心方法
ROSE的整体直觉是：与其用一份参考SQL去'卡'模型的输出，不如让模型先独立判断'这条SQL在数据库 $D$ 上是否回答了用户的问题 $Q$'，再用ground-truth SQL去做有针对性的对抗挑刺。具体而言，ROSE把评估拆成三个串联的关卡：(1) 对预测SQL做执行与执行比较——若执行结果一致（$E_p \equiv E_g$）直接放行；(2) SQL Prover独立评估——仅使用 $Q$、$D$、$S_p$、$E_p$ 和用户接受的判据 $C$ 判断语义正确性；(3) Adversarial Refuter对抗复核——拿到 $S_g$、$E_g$ 和Prover推理后，挑出是否存在决定性差异并裁决是否推翻Prover。仅当三级全部通过才记1分，否则记0。技术路线上，第一步是确定性的，几乎免费；第二、三步由强力推理LLM（OpenAI o3、Gemini-2.5 Pro或DeepSeek-R1）驱动，Prover必须给出结构化JSON判断与推理链，Refuter必须给出布尔裁决、诊断标签与gold正确性评估。这种'先独立后对抗'的流程在保留LLM推理能力的同时，让ground-truth SQL退居'挑刺证据'而非'决策标准'。
ROSE的核心创新是把参考SQL的角色从'匹配标准'彻底改造为'对抗证据'，并通过**SQL Prover + Adversarial Refuter的级联**实现意图中心的评估。具体而言，SQL Prover被设计为完全不看 $S_g$，只根据问题、数据库 schema、用户判据 $C$ 与执行结果，给出独立的语义正确性判断和详尽推理 $R$。这一步解决了'模型因ground-truth错误被错杀'和'实现变体被错杀'两个问题：只要预测SQL在数据库上确实回答了问题意图，就能得到pass。Adversarial Refuter是真正的新颖之处——它有Prover的全部输入，同时额外拿到gold SQL $S_g$、gold结果 $E_g$ 和Prover推理链，用于'挑战Prover的肯定判决'：当 $E_p \equiv E_g$ 时，它负责识别偶然正确（防止假阳性）、标注gold错误；当 $E_p \not\equiv E_g$ 时，它对比两边的逻辑并以问题意图为准仲裁，可能推翻Prover、标记gold错误，或将问题判为AmbQ。这一'有ground-truth作为反方但不让ground-truth拍板'的设计，本质上是让评估过程从'单裁判判定'升级为'主审-陪审团+反方辩护'结构，是与FLEX/LLM-SQL-Solver等仍把ground-truth当作比对基准的方法的本质区别。
方法步骤详情
ROSE的工作流是显式的三段级联。**步骤一，执行与执行比较**：首先检查 $S_p$ 的语法（$\sigma_{syn}$）和可执行性；如果 $S_p$ 不可执行直接判0分。可执行且 $E_p \equiv E_g$，则绕过后两步直接给1分，进入Refuter仅作诊断（识别偶然正确、标注gold错误）。**步骤二，SQL Prover独立评估**：把 $(Q, D, S_p, E_p, C)$ 打包送入推理模型，Prover函数 $\mathrm{Pro}(Q, S_p, E_p | D, C) \to (j_p, R)$ 输出布尔判断 $j_p \in \{true, false\}$ 和结构化理由 $R$，遵循'先确定期望答案、再理解预测SQL在做啥、再判断结果是否匹配、最后下结论'的推理顺序，并在prompt中显式枚举歧义接受、单位换算、DISTINCT/NULL处理、tie-breaking等判据。**步骤三，Adversarial Refuter对抗复核**：当 $E_p \not\equiv E_g$ 时，调用Refuter，其形式为 $\mathrm{Ref}(Q, S_p, S_g; E_p, E_g, R | D, C) \to (j_r, L_q)$，$j_r$ 表示是否推翻Prover，$L_q \in \{\text{AmbQ}, \text{GoldX}, \text{Na}, \ldots\}$ 用于诊断。Refuter默认采用'宽容但有原则'（uphold by default，仅在anchor缺失、schema误用等'硬证据'出现时推翻）。当 $E_p \equiv E_g$ 时，使用省略版的Refuter prompt（不携带执行结果，但保留ground-truth SQL），通过对比两边逻辑一致性识别假阳性。**输出**：仅当语法可执行、Prover不拒绝、Refuter未推翻时才返回1，否则返回0；同时返回每条样本的GoldX和AmbQ诊断标签，可用于数据清洗。所有LLM调用都被设计为可条件触发：执行匹配时只用一次Prover级调用，超过54.66%的样本在单次调用内解决（ROSEo3-2504平均1.45次调用/题）。
技术新颖性
技术新颖性体现在三个层面。第一，**流程架构**：把NL2SQL评估从'单裁判对齐参考'升级为'主审独立判断 + 反方基于参考挑刺'的两段对抗级联，这种'Prover-Refuter cascade'在NL2SQL评估中尚属首次提出，且与FLEX（仍要求对齐参考）、LLM-SQL-Solver（直接问LLM是否等价于gold）等参考依赖方案有本质差异。第二，**评估粒度**：每条样本除二元得分外还输出 $\{\text{GoldX}, \text{AmbQ}\}$ 诊断标签，使评估指标同时成为数据集质检工具，o3-2504在ROSE-VEC上对ground-truth错误的识别precision为84.32%、对AmbQ为91.23%。第三，**版本治理**：通过 $\mathrm{ROSE}_{\text{model-time}}$ 命名规范与'新候选模型必须在ROSE-VEC上四个指标上同时优于老模型才允许升级'的策略，解决LLM-as-Judge类指标在模型迭代下面临的版本漂移问题。这些设计与工业界Defog.ai、Arize的'直接用LLM给SQL打分'的轻量方案相比，更接近'专家-反方-陪审团'的判断结构。
实验结果
**实验一：指标有效性**。在ROSE-VEC 585条专家一致标注样本上，ROSE显著优于所有基线。表1显示OpenAI o3驱动的ROSE（ROSEo3-2504）取得Cohen's $\kappa = 80.43\%$、Accuracy 91.79%、MCC 81.04%、F1 94.16%，相对最强的FLEXo3-2504（$\kappa = 56.70\%$）提升约24个百分点，相对EX（$\kappa = 25.56\%$）提升超过55个百分点。Gemini-2.5 Pro和DeepSeek-R1驱动的ROSE同样保持领先（$\kappa$ 分别为69.68%和64.49%）。重要的是，即使去掉Refuter的消融版本ROSE w/o Refuter在o3下也达到60.74%，已经超过FLEX的56.70%，说明'独立判断'本身就是关键，'对抗复核'则再贡献约20个百分点的 $\kappa$ 增益。**实验二：诊断能力**。表2显示ROSEo3-2504对GoldX的precision达84.32%，对AmbQ达91.23%；Gemini-2.5 Pro分别为68.42%和73.02%。换言之，ROSE既是评估指标，也是数据集审计工具。**实验三：19个方法的大规模重评估**。表3在BIRD mini-Dev上对14个prompting方法与5个fine-tuned方法做ROSE与EX双轨评估，并由此得出四个关键结论：(i) **基模型主导**：系统表现按基模型代次分层（GPT-3.5 → GPT-4 → GPT-4o → GPT-5），同一基模型下系统级工程带来的提升有限，例如RSL-SQL(DeepSeek-Chat)总ROSE 74.15% 与 DeepSeek-Chat基座 72.21% 几乎重合。(ii) **EX失效加剧**：图3显示ROSE与EX的差距从2023年中期的<5%放大到2025年中的>20%，且这种分化主要由GoldX和AmbQ两类'模型答对了但EX判错'的样本驱动。(iii) **基准缺陷是主因**：表4显示在GoldX子集上EX与ROSE的discordance率超过80%（例如OpenSearch-SQL 86.00%、Alpha-SQL-32B 90.00%），在AmbQ子集约60%，远超全集18-20%的平均分歧率；图4进一步显示GoldX和AmbQ合计贡献超过一半的EX-ROSE不一致。(iv) **Fine-tuning的副作用**：图5显示prompting方法在简单/中等难度上与ROSE的差距约为fine-tuned方法的四倍，因为fine-tuning让模型模仿BIRD Train的SQL风格（'stylistic conformity'而非真正的语义推理），OmniSQL（基于SynSQL）反而保持更大的指标gap。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| Rosen-VEC 综合一致性 (OpenAI o3 backbone) | Cohen's κ (%) | 80.43 | FLEX 56.70 / EX 25.56 | +23.7 vs FLEX, +54.9 vs EX |
| ROSE-VEC-BIRD (BIRD子集, o3) | Cohen's κ (%) | 80.68 | FLEX 55.20 / EX 43.56 | +25.5 vs FLEX, +37.1 vs EX |
| ROSE-VEC-Spider (Spider子集, o3) | Cohen's κ (%) | 78.61 | FLEX 57.85 / EX 11.09 | +20.8 vs FLEX, +67.5 vs EX |
| GoldX 诊断 (o3-2504, ROSE-VEC) | Precision (%) | 84.32 | Gemini-2.5 Pro 68.42 / DeepSeek-R1 61.84 | +15.9 vs 第二名 |
| AmbQ 诊断 (o3-2504, ROSE-VEC) | Precision (%) | 91.23 | Gemini-2.5 Pro 73.02 / DeepSeek-R1 51.85 | +18.2 vs 第二名 |
| BIRD mini-Dev 重评估 (GPT-5 vs RSL-SQL/GPT-4o) | Overall ROSE (%) | GPT-5 88.93 | RSL-SQL(GPT-4o) 81.92 | +7.0 vs 同类最强系统 |
| BIRD mini-Dev 重评估 (CSC-SQL-32B, fine-tuned) | EX vs ROSE 差距 (Challenge) | EX 53.06 / ROSE 67.35 | EX-vs-ROSE gap 14.29pp | Challenge集上fine-tuned方法gap放大 |
局限与改进
作者在Limitations章节坦承了三类局限。**第一，对底层推理LLM的依赖**：表1显示Backbone换成不同模型时性能差异显著（o3 80.43% vs DeepSeek-R1 64.49%），意味着ROSE的可靠性直接受'当前最强推理模型是谁'所左右，未来出现更优模型时需要重新走完整ROSE-VEC验证流程，存在版本漂移风险（作者在附录E给出'必须在所有四个指标上同时超越旧模型才允许升级'的治理策略以缓解）。**第二，ROSE-VEC的选择偏差**：585条样本是5位NL2SQL经验专家在'两人完全一致'的强共识过滤下保留的，这会使得验证集偏向'语义判断清晰'的样本，而真正'标注者也意见分歧'的边界案例被滤除，导致报告的'与专家一致性'可能高于在实际分布上的真实表现。**第三，计算成本与延迟**：表8-9显示单线程下ROSE每题22.48秒、8线程3.35秒，单题成本ROSEo3-2504为$0.0070（FLEXo3-2504为$0.0118，ROSE反而更便宜，但EX只要1.22秒）；由于对每个样本平均调用1.45次LLM（最多2次），快速迭代开发场景下ROSE仍比EX重数倍。从error analysis（附录I）的29个ROSE反例看，ROSE本身也存在三类失败模式：(i) 半数（约15/29）是ROSE对'偶然结果一致但逻辑脆弱'的过度保守，例如不区分distinct账户的COUNT；(ii) 三分之一（11/29）是对单位/格式过度严格，例如把[0,1]比例与百分比视为不同；(iii) 少数（3/29）受常识/歧义/Schema命名相似影响，例如把 'highest longitude' 解释为'距离本初子午线最远'而非'数值最大'。
独立分析的弱点
**弱点一：Prover过度宽容与Refuter纠正的'反向不对称'**。SQL Prover被prompt为'lenient but principled'（宽容但有原则），目的是不想把好的预测错杀，但这使它的肯定判断偏宽松，特别是对'看似合理但实质脆弱'的实现（例如把COUNT(account)用COUNT(DISTINCT account)蒙混过关）。29个反例中15个属于'逻辑脆弱但执行巧合'，表明Refuter虽然能补位，但在单次pass中难以识别所有这类问题。**改进方向**：可以让Prover在肯定前显式输出一个'假设检验'清单（如是否存在distinct丢失、是否存在单位换算、单位是否齐备），由Refuter定向复核。**弱点二：对微小实现变体的过度严格**。在29个反例中有11个属于'标注者接受但ROSE不接受'的格式/单位差异，例如[0,1]比例vs百分比、SELECT *与具体列、K-Month日期过滤vsBETWEEN。Prover和Refuter都被训练为'enforce explicit anchors'，但实战中难以穷尽所有'语义等价但表达不同'的边界。**改进方向**：在prompt中加入更明确的'syntactic equivalence classes'白名单（如'分钟/小时换算'、'百分比/比例互换'、'反序近义'），或训练一个轻量的'语言层去同义化器'在Prover输入前做归一化。**弱点三：AmbQ诊断的低精度依赖于推理模型**。DeepSeek-R1在ROSE-VEC-BIRD上AmbQ的precision仅27.87%，但在Spider上82.98%；说明'问题是否真有歧义'在领域间难度差异极大，单一prompt难以覆盖所有场景。**改进方向**：可以把AmbQ判定独立成单独的'模糊度分类器'，针对不同数据库schema的特点自适应阈值，而不是让Refuter顺带完成。**弱点四：ground-truth错误的间接诊断能力**。GoldX判定实际是当Refuter认为gold SQL有fault时给出，但prompt强调'Avoid labeling as gold fault unless absolutely certain'，这导致对ground-truth错误的诊断精度被压制，反过来加剧了'明明基准数据有问题但还是被当作正确答案使用'的循环。**改进方向**：可以允许Refuter在'高置信度发现gold有疑义时同时输出confidence，并对足够多样本的co-occurrence做统计检验。**弱点五：成本结构与延迟**。尽管ROSE在多线程时单题3.35秒、FLEXo3-2504需要18.19秒，但ROSE仍是EX的几十倍成本，对训练中的快速迭代不友好。**改进方向**：可以训练一个14B以下的小模型作为ROSE学生模型，对小规模候选SQL预筛，仅把'执行结果不一致'和'高难度样本'升级给o3。
未来方向
作者明确的方向是'消除参考依赖'——已有结构感知、图匹配（Zhan et al., 2025）和LLM基于参考等多种评估，但都依赖单一gold SQL，ROSE-VEC和Prover-Refuter范式可平移到其他'复杂任务且成功应被定义为满足用户意图'的领域，例如代码生成（用户意图是功能）、结构化信息抽取（用户意图是字段语义）、data agents的多跳规划。**作者提出的方向**：在Appendix B留出了 $\sigma_{sem}$ 的形式化框架，鼓励把'理想'评估函数 $\mathcal{I}$ 分解为可近似计算的子任务，并允许'诊断标签'作为副产品服务于基准迭代。**可延伸方向**：(i) 把Prover和Refuter的训练数据公开，让社区复现并benchmark；(ii) ROSE-VEC目前585条且仅覆盖BIRD和Spider的可公开输出，应扩展到更多基准（KaggleDBQA、EHRSQL、Spider 2.0等）以验证跨域一致性；(iii) 把Prover的设计原则'lenient but principled'模块化为可重用的prompt组件库（歧义接受规则、单位换算库、tie-breaking约定等），让其他领域评估指标可以快速构造；(iv) 在'模型迭代越来越快、评估跟不上'的危机下，把ROSE诊断标签做成持续集成的CI流水线，自动监测'新模型在哪些子集上拉跨'来反推数据集改进。
复现评估
复现评估整体较友好。**代码与数据**：作者在GitHub仓库github.com/CedricPei/ROSE承诺开源ROSE评分脚本与ROSE-VEC验证集，streamlit标注界面也在附录N中给出截图说明，复现门槛主要在API权限而非代码量。**数据集**：ROSE-VEC 585条样本来自7个公开方法（DAIL-SQL、RSL-SQL、Super-SQL在Spider Test；TA-SQL、CSC-SQL、OpenSearch-SQL、Alpha-SQL、RSL-SQL在BIRD Dev）的预测输出，外部研究者可直接基于这些方法的公开leaderboard预测重新分配样本。**算力**：推理侧使用OpenAI o3-2504、Gemini-2.5 Pro-2506和DeepSeek-R1-2505，附录G还包含Qwen3-235B、Qwen3-30B、DeepSeek-R1-Distill-Qwen-32B等开源骨架的结果，可在本地8xA100级别GPU上跑开源backbone；单条样本在o3上平均成本$0.0070、调用1.45次，整套ROSE-VEC-BIRD一次性跑完约$2.25。**复现难度**：中等到偏低——prompt在附录O.1/O.2完整给出（含代码块可复制），但要复现OpenAI o3等专有模型的精确结果需要对应的API访问权限；开源骨架和ROSE-VEC BIRD子集预计可低成本重跑。**潜在风险**：作者坦诚底层LLM版本会变，建议沿用 $\mathrm{ROSE}_{\text{model-time}}$ 命名规范并在新版本上重走ROSE-VEC四指标验证。
论文图表
