Feyn AI が DB 事前検査型 Text-to-SQL モデル「SQRL」発表

テキストから SQL を生成するシステムは、往々にして「翻訳」の問題として扱われます。しかし、YC ベースのスタートアップである Feyn AI は、このタスクを「検査（インスペクション）」を中心に再定義しました。

Feyn チームが公開した SQRL は、自然言語の質問を SQL 文に変換するモデルファミリーです。SQRL は即座にクエリを生成するのではなく、まずデータベースを検査します。これにより曖昧さを解消し、データが実際に存在する範囲内でのみ有効なクエリのみを書き出すことが可能になります。

Feyn チームによると、フラッグシップモデルである SQRL-35B-A3B は、BIRD Dev ベンチマークにおいて 70.6% の実行精度を達成しました。これは、同じ評価条件下で Claude Opus が示した 68.77% をわずかに上回る結果です。

現在、Hugging Face では SQRL-4B、SQRL-9B、SQRL-35B-A3B の 3 つのチェックポイントがオープンソースとして公開されています。

SQL 文として正しくても、結果は間違っている可能性がある

テキストから SQL を生成する問題は「翻訳」問題と説明されることが多いですが、その枠組みでは最も難しい部分を見落としてしまいます。生成されたクエリが文法的に完璧な SQL であっても、返される答えが間違うことはよくあります。

例えば、結合対象のテーブルを間違えたり、曖昧なカラムを誤って解釈したり、存在しない値でフィルタリングを行ったりするケースです。これらすべてのミスはエラーとして検出されないため、実行結果だけを見ていても発見できません。

スキーマ情報だけではこれらのミスを防ぐことはできません。スキーマにはテーブル名、カラム名、データ型、場合によっては関係性が記載されていますが、「county」という情報が「Alameda」なのか「Alameda County」なのか「ALAMEDA」なのかといった詳細までは開示されません。また、どの結合方法を使えば重複行が発生するかを教えることもできません。

BIRD ベンチマークは、これらの失敗を定量化する指標となります。同ベンチのデータベースは実世界のドメインにまたがり、不完全な値や曖昧な列、複雑な関係性を含んでいます。システムの評価は、生成された SQL を実行し、その結果行を正解データと比較することで決定されます。クエリ言語において、構文が正しいだけでは不十分です。

Feyn の核心的な洞察は、不足している情報はすでにデータベース内に存在するという点にあります。モデルに必要なことは、それを問い合わせる許可を得ることだけです。

SQRL は回答する前にデータベースを検査します

SQRL は質問とスキーマ、そしてデータベースに関する任意の証拠を受け取ります。この文脈だけで十分であれば、即座にクエリを返します。しかし何らかの曖昧さが残っている場合、読み取り専用のクエリを実行し、その結果行をもとに最終的な回答を構成します。検査を行うかどうかは状況次第です。単一のテーブルの行数を数える程度なら参照する必要はなく、SQRL は即座に回答します。

この相互作用には 2 つの異なるアクションが用いられます。` ブロックはデータベースからの観測値を要求するものであり、 ブロックは最終クエリへのコミットを表します。ハーン（実行環境）は探索用のクエリを読み取り専用モードで実行し、その結果行を ` タグ内に返します。SQRL は最大 5 回まで検査を行えますが、多くの質問はそれより少ないステップで完了します。

以下の解説では、実際の例を通じて両方の動作を順を追って説明し、その後 BIRD Dev における SQRL ファミリーと最先端モデルの比較を行います。

従来の戦略を両方取り入れたモデル

Text-to-SQL（自然言語から SQL を生成する技術）の歴史には、主に 2 つのアプローチがありました。それぞれに重要なトレードオフがあります。

シングルショットモデルは、一度の呼び出しでクエリ全体を生成します。コストを抑えられますが、スキーマ情報だけからすべての論理を推測する必要があり、結果として論理的な誤りが生じるリスクがあります。一方、最先端のパイプライン方式では、まず文脈を取得し、候補を生成して批判的に検討した上で回答を選択します。精度は最大化できますが、質問ごとに複数の高コストな処理と、データベースとの往復が必要になります。このコストのため、こうしたパイプラインをホットパス（頻繁に利用される経路）に配置するのは現実的ではありません。

SQRL はこれら 2 つのアプローチを単一のモデルに統合しました。簡単な質問には短く対応し、曖昧な質問にはデータベースの検査を行います。必要な時だけ、そのコストを支払う仕組みです。

検査を行うかどうかの判断を学習する

モデルにデータベースへのアクセス権限を与えるだけでは、いつ・どのように検索すべきかは教わりません。この振る舞いは訓練によって習得する必要があり、実行ベースの学習は非常に厳しいものです。もし参照となるクエリ自体が間違っていれば、正解した回答に対して誤った報酬が与えられてしまいます。そこで Feyn はまずトレーニングデータを精査しました。BIRD と Spider のデータセットから始め、参照 SQL が実用的な結果を返さない事例を除外します。その後、3 つのモデル判定者が残りのペアを検証し、質問に答えていないクエリも削除しました。テスト用スプリットは、未使用の Spider スプリットと BIRD の開発データ（dev）を組み合わせて構成され、残りのデータがトレーニングに回されました。

35B-A3B の教師モデルは、MiniMax の M1 研究から生まれた強化学習手法「CISPO」を用いて直接訓練されています。CISPO はポリシー比ではなく、重要性サンプリングの重みをクリップする仕組みを採用しており、稀だが決定的なトークンからの勾配信号を保持します。各質問に対してモデルは 8 つの完全な軌道（トラジェクトリ）を生成し、Feyn は最終的なクエリを実行しました。参照結果と一致した回答には報酬が与えられ、これは文章の表現ではなく返された行のみをチェックするバイナリ信号です。

グループ相対学習では、各グループ内に多様性が必要です。8 つすべてが成功しても失敗しても、どの判断が役立ったのかというシグナルは得られません。そこで Feyn は「ミックスゾーン」で訓練を行いました。ここでは 8 つの試行のうち一部のみが成功するケースを扱い、各グループ内で正しい軌道と誤った軌道を分ける選択を強化できるようにしたのです。これが教師モデルに「いつデータベースを検索すべきか」を学ばせた方法です。

実用化に向けて、Feyn チームは教師モデルの完全な実行軌跡をサンプリングし、最終的な SQL クエリが正解を返すもののみを選別しました。これにより、推論プロセスや探索クエリ、観測結果、そして最終回答を含む約 10,200 の事例データが作成されました。4B と 9B の学生モデルはこれらの軌跡で微調整され、さらに CISPO による実行報酬を用いて洗練されています。SQRL は Qwen3.5 および Qwen3.6 モデルファミリーを基盤に構築されています。

ファミリー全体での性能評価

Feyn は BIRD Dev ベンチマークで SQRL を評価しました。ここでは、参照結果と同じ出力を返すクエリが正解とみなされます。SQRL-35B-A3B は 70.60% のスコアを記録し、トークンあたり約 3B パラメータを活性化します。一方、9B の学生モデルは 69.80% とほぼ同等の性能を維持しています。4B モデルも 68.80% を達成しており、Claude Opus 4.6 に匹敵する結果です。このサイズならどこでもホスト可能で、スキーマやクエリ、観測データをユーザーが管理するインフラ上に保持できるため、セキュリティ面でも安心です。

Feyn が報告した比較では、最先端モデル群も SQRL には及びませんでした。Claude 4.5 Sonnet は 67.34%、Qwen3-Coder-480B-A35B は 66.17%、GLM-4.7 は 63.82%、DeepSeek-R1 は 61.67%、Kimi-K2-Thinking は 60.63% です。

デプロイに関する推奨事項

Feyn では、SQRL-9B をデフォルトチェックポイントとして推奨しています。予算が限られる場合は SQRL-4B を、最高精度が必要な場合に SQRL-35B-A3B を選択するのが良いでしょう。9B モデルは vLLM で動作します。

vllm serve feyninc/sqrl-9b \
  --served-model-name sqrl-9b \
  --gpu-memory-utilization 0.90 \
  --max-model-len 32768

アプリケーションのループは非常にシンプルです。データベースの実行は常に読み取り専用とし、モデルが回答を出力するまで、各観測結果を逐次返します。

ただし、一つだけ注意すべき点があります。サービング層に推論用パーサーを有効化しないことです。アクションプロトコルは、閉じタグの直後のコンテンツ内に記述されるため、その部分を削除するとモデルの思考（think）やアクションが失われてしまいます。そのため、生のメッセージ内容を解析し、最終的な「think」タグ以降の内容はすべて保持する必要があります。

モデルカードには、完全なシステムプロンプトと参照用ハッチェンが含まれています。

主なポイント

SQRL は、最終クエリを実行する前にデータベースを検査するための読み取り専用プローブを実行するテキストから SQL へのモデルファミリーです。

Feyn が報告した SQRL-35B-A3B の BIRD Dev ベンチマークにおける実行精度は 70.6% で、同じ評価における Claude Opus の 68.77% を上回っています。

フラッグシップモデルは 4B と 9B の学生モデルに蒸留されており、SQRL-4B はこのテストで Opus と同等の性能を維持しながら、自己ホスティングも可能です。

トレーニングでは BIRD と Spider データセットをクリーニングし、実行結果の一致に対して報酬を与えました。また、CISPO（Contrastive Instruction Selection for Prompt Optimization）と蒸留手法を組み合わせて、モデルに「いつ検査を行うべきか」を学習させました。

これら 3 つのチェックポイントはすべて Hugging Face で公開されており、vLLM を介して読み取り専用ハッチェンで提供されています。このハッチェンは、観測結果をモデルへフィードバックする役割を果たします。

SQRL は Feyn によって開発されました。チームは GitHub、Hugging Face、X（旧 Twitter）でも確認できます。

※本記事は MarkTechPost に掲載された「Feyn AI Releases SQRL, a Text-to-SQL Model Family That Inspects the Database Before Writing a Query」の続編です。