Text-to-SQLの課題—「正しいSQL」が必ずしも「正しい答え」ではない

多くのText-to-SQLシステムは、自然言語からSQLへの「翻訳」としてタスクを扱ってきました。しかし、このアプローチには本質的な課題があります。

生成されたSQLクエリが文法的に正しくても、それが常に正しいデータ結果を返すとは限りません。間違ったテーブル結合、曖昧なカラムの誤解釈、存在しない値でのフィルタリングなど、これらはSQLエラーを引き起こさないため、実行時に間違いが検出されにくいのです。

Text-to-SQLにおいて、構文的に正しいクエリが必ずしも正しい答えを返さないという点が、この分野の最も難しい課題です。

スキーマ情報だけでは、これらの問題を完全に防ぐことはできません。スキーマはテーブル、カラム、データ型、そして時にはリレーションシップを示しますが、例えば「ある郡が Alameda、Alameda County、あるいは ALAMEDA のどれで格納されているか」といった具体的なデータの内容までは教えてくれません。これは、実際にデータベースと対話しなければ得られない情報です。

SQRLのアプローチ—クエリ生成前にデータベースを「検査」

Feyn AIのSQRLは、この課題に対して「データベースの検査（inspection）」という独自のアプローチを導入しました。SQRLは、質問、スキーマ、およびデータベースに関する任意の証拠を受け取ります。もしこれらの情報で十分であれば、すぐにクエリを返します。

しかし、何らかの曖昧さが残る場合、SQRLはリードオンリーのクエリを実行し、その結果を使って最終的な回答をドラフトするのです。これにより、データが実際にサポートするクエリのみが生成されるようになります。

SQRLの対話は2つの明確なアクションで構成されます。

  • <sql> ブロック：データベースからの「観測（observation）」を要求します。
  • <answer> ブロック：最終的なクエリを確定します。

システムは探索クエリをリードオンリーモードで実行し、その結果を <observation> タグ内に返します。SQRLは最大5回まで検査を行うことができますが、ほとんどの質問はそれよりも少ないステップで完了するとのことです。

自分の個人プロダクトでも、ユーザーからの自然言語入力でデータベースを操作する機能は以前から検討していました。SQRLのようにデータベースを事前に検査するアプローチは、誤った結果を返すリスクを大幅に減らせるため、ユーザー体験の向上に直結すると感じます。Pythonバインディングがあれば、ぜひ試してみたいですね。

BIRDベンチマークでの驚異的な精度と提供モデル

Feyn AIチームは、フラッグシップモデルである「SQRL-35B-A3B」がBIRD Devセットで70.6%の実行精度を達成したと報告しています。これは、同じ評価条件下でのClaude Opusの68.77%を上回る数字です（出典）。

BIRDベンチマークは、実際のドメインデータ、不完全な値、曖昧なカラム、そして複雑なリレーションシップを持つデータベースを対象としており、クエリ言語にとって構文の正しさだけでは不十分であることを示しています。SQRLがこのベンチマークで高い精度を叩き出したことは、そのアプローチの有効性を強力に裏付けていると言えるでしょう。

SQRLモデルファミリーの比較

モデル名 パラメータ数 BIRD Dev実行精度 特徴
SQRL-4B 40億 未公開 小規模で推論コストが低い
SQRL-9B 90億 未公開 中規模で汎用性が高い
SQRL-35B-A3B 350億 70.6% フラッグシップモデル、最高精度、Claude Opus超

現在、以下の3つのチェックポイントがHugging Faceでオープンに公開されています（出典）：

これは開発者にとって非常に魅力的なニュースです。特に、大規模なLLMに依存せず、ある程度ローカルで実行可能なサイズのモデルも提供されているのは好感が持てます。

うちのスクリプトで、特定のデータセットに対してSQLを生成する部分に使えそうな予感がしますね。ドキュメントが充実していれば、Claude Codeに投げてみたら案外すぐ動きそうだと感じます。