RL にタスク専門知識を組み込み Text-to-SQL で最高性能を達成

多くの産業で、リレーショナルデータベースが SQL を用いてクエリされています。SQL の多くは機械によって書かれていますが、人間が毎月数十億件のカスタム SQL クエリをビジネス上の質問に応答するために独自に作成している可能性が高いです。

彼らは非常に得意としており、自然言語の質問から SQL への変換を評価する現実的なベンチマークである BIRD では、人間は 92.96% のスコアを獲得しています。

しかしながら、AI のテキストから SQL への生成性能は遅れをとっています。LLM の BIRD リーダーボードでのスコア は、2024 年にはわずかに 70% を下回る水準でしたが、現在は 82% に改善されています。GPT-5.6 Sol Ultra や Claude Fable 5 といった最先端モデルは中程度の 80 台後半のスコアを達成できますが、大量処理アプリケーションにはコストが高すぎて現実的ではありません。

これは学習データの不足によるものではありません。SQL は LLM の事前学習に使用されるインターネット上のコンテンツに広く含まれています。AI が直面する真の課題は、実世界で頻出するあいまいな質問や、文脈に強く依存するスキーマをどのように処理するかという点にあります。

AI のパフォーマンスを人間が理解しやすいタスクで向上させる一般的なアプローチとして、エージェント型の足場（スキャフォールディング）を構築する手法があります。OpenHands や AI コーサイエンティスト、MetaGPT といったシステムは、タスクを複数の段階に分解し、各段階ごとに独自のプロンプトやモデル呼び出しを行います。

Text-to-SQL の分野でも同様のパターンが採用されています。まずスキーマリンクの段階で、数千ものカラムの中から候補となるセットへと絞り込みます。現実世界のエンタープライズデータシステム（データベース、データウェアハウス、データレイクハウスを含む）には最大数百万のカラムが存在します。ビジネス上の質問に答えるためには、どのカラムを使用すべきかを理解することが不可欠です。

一方、学術的なベンチマークは比較的単純化されています。生成段階ではクエリをサンプリングし、自己修正段階で実行エラーを修復します。さらに選別段階で生き残った候補の中から投票によって最終結果を選び出します。各コンポーネントは独立した呼び出しとして機能し、オーケストレーション（調整）は特定のベンチマーク向けに最適化されています。

最先端の Text-to-SQL スキャフォールディングシステム [1][2][3] は、それぞれの構成要素の組み合わせには違いがありますが、共通する設計思想を持っています。それは「モデル自体を固定したまま、その呼び出し回数や構造を増やすことでタスクのパフォーマンスを向上させる」という考え方です。

[1]: https://arxiv.org/pdf/2509.24403

[2]: https://arxiv.org/pdf/2410.01943

[3]: https://github.com/jd-opensource/joyagent-jdgenie/tree/dataagent

スクフォールディング（Scaffolding）は、モデルの推論能力の限界を克服しようとする試みで、人間がタスクに取り組む手順に似た一連のステップに従わせることで実現されます。しかし、最良のスキャフォールド付きモデルでも、SQL 処理においては依然として人間の性能より 11 ポイントも劣っています。

プロの専門家は、与えられた指示リストを覚えるのではなく、反復的な経験を通じてスキルを習得します。LLM（大規模言語モデル）についても同様であるべきです。タスクへの経験を基に、モデルに対してクエリやデータベースに対する推論能力をより深く学習させるべきであり、単にスキャフォールドから受け取るプロンプトを更新するだけでは不十分です。

本ブログ記事では、Tinker 上で検証可能な報酬を用いた強化学習（RLVR）を活用し、スクフォールディングなしで人間のレベルの精度を達成するモデルのファインチューニングについて解説します。

SQL を用いて正解を抽出するタスクは検証可能であり、比較的 straightforward な方法で学習可能です。しかし、既存の SQL モデルのパフォーマンス格差から、標準的なアプローチには改善の余地があることが示唆されています。我々のアプローチには 2 つの重要な改良点があります。

1 つ目は、ラベル誤りを取り除き、RLVR を汚染するリスクを排除した専門家検証済みトレーニングセットです。これにより poison RLVR の問題を回避できます。

2 つ目は、このドメインにおける RLVR で頻発する 2 つの失敗モードに特化した報酬整形（reward-shaping）手法です。

学習済みモデル「ReViSQL-K2.6」は、16 個のサンプルから選択する自己一貫性選定（SC-16）において、92.96% という人間の基準値を突破しました。SC-16 とは、実行結果に基づいて同時に生成された SQL クエリをグループ化し、多数派グループの中からランダムに 1 つのクエリを選択する手法です。

このアプローチには、従来のエージェント型フレームワークで使われるような複雑な要素は一切含まれていません。サンプル生成は単に同じプロンプトから複数の出力を引き出すだけであり、中間ステップを個別にプロンプトする必要はありません。また、多数決投票も追加のモデル呼び出しを必要としません。この手法は、1 タスクあたり 0.56 ドルのコストで実現されています。

Fable 5 や GPT-5.6 Sol Ultra と比較すると、そのコストはわずか 12〜15% で済むのに、精度はそれらを上回っています。さらに、リーダーボード上の他のすべてのスキャフォールド型モデルよりも圧倒的に高精度です。

単一モデルである ReViSQL-K2.6 は、専門家による検証済みベンチマーク「Arcwise-Plat-SQL」において、最先端のモデルや既存のオープンソースのスキャフォールド型パイプラインを上回る精度を達成しました。16 サンプルの自己一貫性選定（SC-16）を用いることで、ReViSQL-K2.6 は初めて人間の基準値である 92.96% を超える結果を出しています。

コード、データ、トレーニングレシピは github.com/uiuc-kang-lab/ReViSQL で公開されています。また、手法の詳細については技術報告書をご覧ください。

高品質なトレーニングデータのキュレーション#

RLVR はドメイン固有の推論能力を向上させるのに効果的ですが、誤ったラベルを含むデータに対しては非常に敏感です。RLVR においては、スカラー報酬が学習ステップにおける唯一の学習シグナルとなります。ラベル付けに誤りがある事例は、このシグナルを逆転させ、学習性能を著しく低下させてしまいます。

私たちの研究では、アルゴリズムの微調整でこの損失を補うことはできないことが判明しました（参照）。RLVR を成功させるためには、データのクリーニングが不可欠です。

既存の Text-to-SQL データセットには極めて多くのノイズが含まれていることを私たちは発見しました。このデータセットのノイジーさは、Pourreza と Rafiei（2023）[1] や Wretblad ら（2024）[2] など、多くの研究者によって指摘されています。

私たちの分析 [3] によると、広く知られているベンチマークの多くにも大量のノイズが含まれていました。Text-to-SQL の学習用データセットである BIRD Train から 2,500 インスタンスをサンプリングして調査した結果、データセットのあらゆる構成要素にエラーが見つかりました。具体的には、質問文、提供された外部知識、そしてモデルの回答と比較対象となる「正解 SQL クエリ（golden SQL queries）」の半数以上で不具合が確認されました。

[1] Pourreza, M., & Rafiei, D. (2023). Text-to-SQL: A Survey.

[2] Wretblad, P., et al. (2024). The Noisy Reality of Public SQL Datasets.

[3] Our analysis on text-to-sql data quality.

表 1: BIRD Train からサンプリングした 2,500 インスタンス全体における注釈エラー率。カテゴリは重複するため、合計値は単純な総和ではありません。

トレーニングセットのクリーンアップには多段階のプロセスを採用しました。まず、LLM（OpenAI の o3）と人間のエキスパートが各インスタンスをレビューし、エラーを特定しました。その結果、LLM による監査は注釈ミスを検出する精度が高い一方で（90.6%）、人間が指摘したエラーの検出率は 24.5% に留まりました。この第一段階で発見されたエラーと提案された修正内容は、別のエキスパートによって検証されました。検証者が最初の監査結果に異議を唱えた場合は、サンプルは追加のコンフリクト解決ループのために再度送り返されます。

クリーンアップ済みのトレーニングセットは、コミュニティ向けに BIRD-Platinum として公開されています。

*人間のエキスパートを交えた BIRD-Platinum データ修正パイプライン*

評価用データセットである BIRD Mini-Dev にも同様に注釈エラーが含まれている可能性があると推測しました。Arcwise による最初のクリーンアップパスで、32.3% のインスタンスにおけるエラーが修正されました。その後、私たちが第 2 パスを実施し、Arcwise が指摘した項目のほとんどを確認するとともに、さらに多くのエラーを発見しました。その結果、BIRD Mini-Dev 全体の検出済みエラー率は 52.8% に達しました。ゴールドクエリのエラーを修正した評価セットは、Arcwise-Plat-SQL として公開されています。

BIRD-Platinum を用いた RLVR が、従来最良モデルを上回る性能を実現

Kimi-K2.6 に RLVR（Reinforcement Learning from Verifiable Rewards）を適用し、BIRD-Platinum データセットで微調整することで「ReViSQL-K2.6」を開発しました。検証済みデータのみを用いて学習させた結果、Arcwise-Plat-SQL において、最先端の汎用大規模言語モデル（LLM）や、主要なオープンウェイトの微調整済みテキストから SQL を生成するモデルを大きく上回る精度 88.55% を達成しました。これは、標準的な学習データに含まれる注釈エラーが、RLVR の性能におけるボトルネックだったことを示しています。

*BIRD-Platinum で微調整された ReViSQL-K2.6 は、専門家によって検証された BIRD の派生バージョンにおいて最高精度を記録し、GPT-5.6 Sol Ultra や Claude Fable 5、そして最も強力なオープンウェイトのテキストから SQL を生成するモデル（Infly-RL-SQL-32B、OmniSQL-32B、XiYanSQL-32B、Arctic-R1-7B）を凌駕しています。

このアプローチが、私たちが直接触れていない他のモデルや評価セットにも一般化できることを示すため、Qwen3-235B-A22B を BIRD-Platinum と元の BIRD Train データセットで RLVR 適用し微調整しました。その後、BIRD よりもはるかに難易度が高いと広く認識されている 2 つの新しいテキストから SQL を生成するベンチマークでモデルをテストしました。

Spider2-SQLite は、Arcwise-Plat-SQL に比べて平均して 5.2 倍のトークン数を持つ複雑なクエリを含む、Spider2 ベンチマークの派生版です。

Spider2-Snow も同様に Spider2 の派生版ですが、Snowflake SQL ダイアレクトを使用します。

BIRD-Platinum で微調整された Qwen3-235B-A22B は、Arcwise-Plat-SQL、Spider2-SQLite、Spider2-Snow において、それぞれ 16%、12%、14% の精度向上を達成し、オリジナルの BIRD Train で訓練された同一モデルを上回りました。

より慎重に選別された BIRD-Platinum で学習させることで、BIRD Train に比べて Arcwise-Plat-SQL では 16%、Spider2-SQLite では 12%、Spider2-Snow では 14% の精度向上が確認されました。これは、検証済みのデータがベンチマークや SQL ダイアレクトを超えて、より汎用的な学習シグナルを提供することを示しています。

Text-to-SQL RLVR における正確な報酬信号

クリーンなデータでの学習により微調整モデルは人間並みの性能に近づきましたが、依然として 4% を超える差が残っていました。そこで私たちは、モデルがパターンを特定できなかったケースを検討し、学習プロセスで使用される報酬関数に注目しました。

標準的なテキストから SQL への強化学習（RLVR）では、生成されたクエリがベンチマークデータベース上で正解のクエリと同じ結果を返す場合にのみ報酬 1 を付与します。これは評価時のスコアリング方式と一致していますが、モデルに学習させるべき一般的な振る舞いを十分に反映していません。

私たちは、結果ベースの報酬が意図した振る舞いとズレが生じる 2 つのパターンに注目し、その課題を解決するために報酬関数を修正しました。

ズレ 1：実行結果の一致は意味的な等価性を保証しない

標準的な結果ベースの報酬は、生成されたクエリが単一のデータベースインスタンスでどのような出力を返すかを確認するだけです。しかし、これでは別のデータベースインスタンスでも同じ結果が得られるとは限りません。

結合キーが間違っていたり、条件式（述語）が抜け落ちていたりする場合でも、特定のデータベースインスタンス上でそのエラーが顕在化しない限り見逃されてしまいます。意味的に等価なクエリだけが、あらゆるデータベースインスタンスで同じ結果を生成することが保証されます。

SQL クエリの意味的等価性を検証するために VeriEQL を使用しました。これは有界検証（bounded verification）を用いるソルバーであり、総トレーニングコストに対して無視できるほどの CPU 負荷しかかかりません（0.1% 未満）。パイロット実験のトレーニング結果では、正解のクエリと完全に等価ではないクエリにも報酬が与えられていたケースが、結果ベースの報酬のうち 32.8% に上ることが判明しました。つまり、約 3 回に 1 回の割合で、間違ったクエリに対して報酬が与えられていたことになります。

質問： ルーカス・ワイルドボアは、本注文に対して平均してどのくらいの金額を使っていますか？

正解の SQL クエリ

SELECT AVG(order_total)
FROM (
  SELECT o.order_id,
         SUM(i.price)
           AS order_total
  FROM orders o JOIN items i
    ON o.order_id = i.order_id
  WHERE o.customer = 'Lucas...'
  GROUP BY o.order_id
);

不正なクエリ（正解とみなされる報酬）

SELECT AVG(i.price)
FROM orders o JOIN items i
  ON o.order_id = i.order_id
WHERE o.customer = 'Lucas...'

このクエリは注文ごとの合計金額ではなく、行単位の価格の平均を計算しています。ただし、各注文に商品が1品しかないという特殊なケースでは、結果が一致してしまいます。

*誤った正解報酬：生成されたクエリは注文全体の合計ではなく行単位の価格の平均を算出していますが、各注文に商品が1品しかないため結果が一致し、実行ベースの評価では「正解」と判定されてしまいました。*

そこで、実行結果の一致によって受け入れられた場合でも、VeriEQL による等価性チェックで不一致と判断されたケースでは報酬を減衰させるよう報酬信号を更新しました。検証ソースを追加することで、異なるデータベースインスタンスにも一般化できる正しいクエリへの学習が促進されます。

乖離2：結果ベースの報酬は提供された知識を見逃す#

BIRD スタイルの問題では、質問とともに外部知識がプロンプトに付与されます。しかし、結果ベースの報酬は最終的な出力のみを条件とするため、「提供された情報を正しく読み取ったモデル」と「事前学習の前提に基づいて推測して正解したモデル」を区別することができません。

例えば、「sodium = 0」と「sodium < 5」は同じ結果セットを返すため、結果ベースの報酬では、「外部知識を用いて正しく 'sodium = 0' を選択したモデル」と、「'sodium < 5' という情報を記憶または幻覚として出力したモデル」を見分けることができません。外部知識を組み込むようモデルを導く勾配が存在しない場合、モデルは事前学習の前提に依存する傾向があります。

検証セットでのパイロット分析では、失敗事例の 24.2% が、提供された必要な情報を無視したことによるものだと特定されました。

質問: The California Tree Fruit Agreement のレシピのうち、ナトリウムを含まない（sodium-free）レシピの割合を計算してください。

外部知識: sodium-free とは「sodium = 0」のことです。

正解の SQL クエリ

SELECT CAST(SUM(

CASE WHEN sodium = 0

THEN 1 ELSE 0 END

) AS REAL) * 100

/ COUNT(*)

FROM recipes r

WHERE r.source = 'California...'

外部知識を無視したクエリ

SELECT CAST(SUM(

CASE WHEN sodium < 5

THEN 1 ELSE 0 END

) AS REAL) * 100

/ COUNT(*)

FROM recipes r

WHERE r.source = 'California...'

外部知識を無視することによる失敗例です。外部知識では「ナトリウムフリー」はナトリウム濃度が 0 を意味すると定義されていますが、生成されたクエリでは閾値としてナトリウムが適用されてしまいました。これを解決するためにルールベースのプロセス報酬を導入しました。

モデルには、外部知識の各項目を明示的なクエリ制約に変換する「要件ブロック」と、その制約に対して生成されたクエリを検証する「検証ブロック」の両方を出力させる必要があります。非遵守の場合はペナルティが課されます。このプロセス報酬は、モデルが事前学習で得た先入観に盲目的に頼るのではなく、提供された知識に基づいて推論と生成を行うよう促すものです。

報酬の評価はモデルによる採点ではなくルールベースで行うため、コストがかからず、評価者となるモデルの先入観による汚染も防ぐことができます。

学習レシピ#

ReViSQL-K2.6 の学習レシピを公開します。このレシピは、Tinker APIs を基盤とした当社のコードを用いれば再現可能です。

表 2：トレーニング設定

結果

ReViSQL-K2.6 は、Tinker で検証済みデータを用いて微調整され、報酬関数の改良も施されたモデルです。貪欲デコーディング（単一サンプリング、温度パラメータ = 0）では、Arcwise-Plat-SQL において 91.37% の精度を達成し、タスクあたりのコストはわずか$0.035 です。これは、既存の最強オープンソースパイプラインである OpenSearch を 8.4 ポイント上回る結果であり、かつコストを 37% 削減したことになります。このコスト優位性は、モデル周囲に設けられていた補助的な足場を取り除いた直接の結果です。

ReViSQL-K2.6 が温度パラメータ = 1 で生成された 16 の候補から投票を行う場合、精度は 92.97% に向上し、タスクあたりのコストは$0.56 となります。これは、私どもの知る限りにおいて、テキストから SQL を生成する AI システムが人間のベンチマークを初めて上回った事例です。

*ReViSQL-K2.6 の Arcwise-Plat-SQL における性能（1, 4, 8, 16, 32 サンプリング）と、5 つのオープンソースパイプラインとの比較。ベースラインは GPT-5.2（GenaSQL, OpenSearch, SHARE）または XiYanSQL-QwenCoder-32B-2412（CSC-SQL, Contextual）を基に構築されています。人間のレベルである 92.96% は線引きで示しています。当社のモデルは、クエリあたりのコストが同等かそれ以下という条件下で、すべてのパイプラインを 8〜22 ポイント上回っています。

結論

AI が特定のドメインタスクで性能を発揮できない場合、一般的な対応はタスク実行の周囲に補助的な仕組み（スキャフォールディング）を追加することです。このアプローチは Text-to-SQL モデルの性能をある程度上げましたが、最終的にはベースモデルが持つ能力という天井にぶつかります。

これはスキャフォールディングが無意味だと言っているわけではありません。むしろ、スキャフォールディングに含まれるタスク知識こそが、トレーニング信号の中に組み込まれるべきだと示唆しています。つまり、モデル全体の能力を高めるための学習プロセスそのものに、その知識を含める必要があるのです。

先ほどの「金融判断のために訓練された AI」に関する私たちの研究との共通点は、専門家の勘や判断力を要する幅広いタスクにおいて、カスタムモデルが最先端モデルを上回る性能を発揮し、かつコストは大幅に抑えられるという点です。これを実現するには、AI の失敗箇所を特定したり、トレーニングデータのラベル付けを行ったり、意図した動作に合わせて学習を調整したりといったプロセスに、専門家の判断力を組み込む必要があります。

Text-to-SQL のケースでは、データの詳細なクリーニングと、モデルに正しいスキルを教えるための報酬関数の設計という二つの取り組みにより、大きな改善が見られました。これには初期段階で多くの労力が必要でしたが、その結果として得られたモデルは、人間やスキャフォールディングを適用したモデルよりも、より高い性能をより低いコストで達成しています。タスク固有の専門知識を、そのタスクに特化したトレーニングに組み込むことが、最終的にスケーラビリティを実現する鍵なのです。

引用#

本論文を引用する際は、以下のように記載してください：

タスク専門知識を強化学習に組み込むことで、Text-to-SQL において最先端の性能を実現

（読み切り：約18分）

BibTeX:

Zhu, Yuxuan et al., "Human-Level Text-to-SQL via Reinforcement Learning on Verified Data, Without Pipeline Engineering", arXiv:2603.20004 (2026).

@article{zhu2026revisql,
  title = {Human-Level Text-to-SQL via Reinforcement Learning on Verified Data, Without Pipeline Engineering},
  author = {Zhu, Yuxuan and Jin, Tengjun and Choi, Yoojin and Kang, Daniel},
  journal = {arXiv preprint arXiv:2603.20004},
  year = {2026}
}