Python、JavaScriptなどの汎用言語におけるLLMコード生成が注目を集める中、SQLは見過ごされがちです。
Beekeeper Studioは無料のオープンソースのデータベースGUIです
これまで使った中で最高のSQLクエリ＆エディタツールです。データベースの管理に必要なものがすべて揃っています。 - ⭐⭐⭐⭐⭐ Mit
Beekeeper Studioは高速で直感的、そして使いやすいツールです。多数のデータベースに対応し、Windows、Mac、Linuxで快適に動作します。
しかし、SQLは世界経済を支えていると言っても過言ではありません。そこで問うべきなのは、LLMはどれだけ上手にSQLを書けるのか、ということです。
この問いを投げかけたのは私たちが初めてではありません。研究者もベンダーも、SQL生成におけるLLMの性能を測るベンチマークをすでに公開しています。
この記事では、それらのベンチマークをいくつか取り上げ、そこから何が分かるのかを探り、意味のあるSQLコード生成ベンチマークの条件について考えます。
LLMのSQLコード生成における良いベンチマークとは?
LLMが一発で動くコードを生成したときの驚き、そして少しの感動を味わったことがある方は多いでしょう。しかし同じくらいの頻度で、存在しないライブラリを呼び出したり、変数を忘れたり、プロンプトで明示したエッジケースを見落としたりと、つまずくこともあります。
SQLの場合、開発が細かく反復的に進むため、LLMが正しく書くことはさらに難しくなります。通常は、クエリを書いて実行し、出力を確認し、その結果をもとに修正します。これは、データそのものがSQLと同じくらいプロセスの重要な一部だからです。
そのため、LLMのSQL生成能力を評価しようとするベンチマークには、特有の要件が求められます。私たちは、良いSQLベンチマークには次のことが必要だと考えます。
- 複数のデータベースを対象とする: Postgres、MySQL、SQL Server、ClickHouseなどにはそれぞれ癖があるため、公平なベンチマークには複数のエンジンを含める必要があります。
- 多様なタスクを含める: クエリには、シンプルなSELECT … WHERE句から、複雑な結合、ウィンドウ関数、スキーマを理解する必要がある課題まで幅があります。ベンチマークはその幅を反映すべきです。
- 構文だけでなく結果を確認する: 本当に問うべきなのは、SQLが実行できるかではなく、正しいデータを返すかどうかです。
- 反復を考慮する: 有用なベンチマークは、最初の試行だけでなく、クエリを修正していくやり取りも捉える必要があります。
- 透明性を確保する: スキーマ、データセット、評価コードが公開されていなければ、結果を信頼しにくくなります。
では、これらの基準を満たすAI SQLコード生成ベンチマークは存在するのでしょうか?
SQLベンチマーク
もちろん、SQLベンチマークはLLMより前から存在します。おそらく最も有名なのは、2018年にtext-to-SQL研究コミュニティ向けのデータセットとして公開されたSpiderです。LLMではなく意味解析のために設計されたものですが、その後LLM評価における一種の基準となりました。ただし、その後研究者やベンダーによって他のベンチマークも登場しています。
Spider
概要: 2018年に公開されたSpiderは、200以上のデータベースと数千件の自然言語からSQLへの変換タスクからなる大規模データセットで、もともとはtext-to-SQL研究コミュニティ向けに作られました。
長所: 幅広いスキーマをカバー。ある程度複雑でドメインをまたぐクエリ。学術評価およびLLM評価(Codex、GPT-3.5、GPT-4を含む)における長年の基準。
短所: 雑然とした本番データベースとはかけ離れた、整ったSQLiteスキーマが前提。一発生成の評価に重点を置いており、クエリの反復的な修正を反映していません。
評価: 有用な基準であり、今も最も多く報告されているベンチマークですが、実際のSQLワークフローを捉えるには学術的すぎる可能性があります。
BIRD-SQL
概要: Spiderの後継として2023年に登場したBIRD-SQLは、より現実的なBI系ワークロードで大規模モデルに挑戦するために特別に設計されました。
長所: より大きく雑然としたスキーマ。スキーマの推論や、場合によっては外部知識を必要とするクエリ。Spiderより難易度が高い。
短所: 設計はまだ学術的。シングルターンの評価が中心で、研究分野以外の実務者には扱いにくい。
評価: 現実のデータの課題に一歩近づいていますが、反復的でもマルチエンジン対応でもありません。
Tinybird SQL Benchmark
概要: Tinybirdによる業界主導のベンチマークで、自社プラットフォーム(ClickHouseベース)を使って19のLLMを分析系SQLタスクで評価し、人間のベースラインと比較しています。
長所: 分かりやすい提示方法。大規模なデータセット(数億行)。複数モデルの結果を並べて比較できる。
短所: Tinybird独自のインフラに依存。一発のクエリ生成に限定。結果が同社の環境以外に一般化できない可能性があります。
評価: 洗練されていて実用的ですが、対象範囲が狭く、さまざまなデータベースや反復的なワークフローでのLLMの性能を代表するものではありません。
SQL-EVAL
概要: SQL-EVALは、LLMが生成したSQLの正しさを評価するオープンソースの評価フレームワークです。各タスクには、人間が確認した参照SQLクエリが用意されています。SQL-Evalはモデルのクエリと参照クエリの両方を実行し、結果を比較します。
長所: 完全にオープンソースで再現可能。SQLの複雑さ(ネストしたクエリ、複数の結合)、意味的な多様性、正しいクエリが複数存在するケースにも対応。
短所: クエリの品質や効率ではなく、参照と同じ結果を返すかどうかに焦点を当てています。一発生成のみに対応し、反復的な修正はシミュレートしません。
評価: モデルが正しい結果をどれだけ返せるかを判断するための貴重なリソースで、透明性も優れていますが、実際のSQL利用における反復的なワークフローはやはり反映していません。
その他の注目すべきベンチマーク
新しいプロジェクトは、SpiderやBIRD-SQLが残した課題の一部を埋めようとしています。
- BIRD-CRITIC: BIRD-SQLをベースにした新しいベンチマークです。モデルに一度クエリを書かせるだけでなく、モデルが自分のミスを修正できるかを確認します。たとえば、最初の試行でエラーや誤った結果が返された場合、ベンチマークはモデルに修正して再試行するよう求めます。さらに、これを複数のデータベースシステム(Postgres、MySQL、SQL Server、Oracle)で行います。
- BEAVER: 目的別に作られた学術データセットではなく、企業のデータウェアハウスから取得した実際のクエリをもとに構築されたベンチマークです。金融、小売、オペレーションで見られるような、大きく雑然としたスキーマが含まれています。
まとめ
各ベンチマークは、SQLの課題の異なる側面に光を当てています。SpiderとBIRD-SQLは大規模なtext-to-SQL評価を標準化しましたが、そのデータセットは実際の本番システムよりもはるかに整っています。Tinybirdはベンチマークをより身近で比較しやすくする別のアプローチを示し、SQL-Evalはマルチエンジン対応という重要な観点をもたらしています。
これらを総合すると、次のチャンスが見えてきます。静的な一発生成のクエリを超えて、SQL開発における試行錯誤のやり取りを捉えるベンチマークです。
Beekeeper StudioでAIによるSQLクエリ
ベンチマークは管理された環境でモデルを比較するのに役立ちますが、本当の試金石は、AIが日々のワークフローに実際にどれだけ馴染むかです。
そこで役立つのがBeekeeper Studioです。お気に入りのLLMと接続し、会話型インターフェースと手書きのSQLクエリの両方でデータの探索やクエリを支援するSQL GUIです。高速でオープンソース、クロスプラットフォームに対応し、Postgres、MySQL、SQLite、MongoDBなどをサポートしています。
