Text-to-SQLの評価データセットを作って最新LLMモデルの性能評価をしてみた

Text-to-SQLの評価データセットを作って最新LLMモデルの性能評価をしてみた
AIエージェントの実用化に向けて、データベースアクセスの精度は超重要！でも既存のベンチマークって実際のビジネスシーンとは違う。
そこで、実際のeCommerceデータセットを使って独自の評価データセット（60問）を作成し、最新のLLMモデル7種類（Claude Opus 4、Claude Sonnet 4、GPT-4.1、GPT-4o、o3、Gemini 2.5 Pro/Flash）の性能を比較しました。

【主な内容】
・実用的なText-to-SQL評価データセットの作り方
・各LLMモデルの実行精度比較（意外な結果も！）
・より正確な評価のための独自指標の開発

結果：Claude Sonnet 4とGPT-4.1が最強でした！Opus 4やGemini 2.5は意外と苦戦...

Transcript

1. Text-to-SQLの評価データセットを作って最新 LLMモデルの性能評価をしてみた
 2025/6/12 #StudyCo

2. Claude Code
 
 Zennで伸びた記事⇒ 
 自己紹介
 Gota (相原 豪太)
 所属
 データアナリスト and AIエージェント開発
 趣味
 AIエージェント作り (MCP) / 軽登山 / アニメ (進撃の巨人にハマり中)
 SNS
 X (@gota_bara) / note (@gotalab)
 好きな
 Coding Agent

3. 現在のチャレンジ: 自律型分析エージェントの開発 
 問題定義から資料作成までの一連の分析業務全体を AIにやらせることには成功！ 

4. 理想と現実: 品質の壁
 ビジネスユーザーに展開するには、下流のデータ集計・抽出の信頼性が全て 
 • 意思決定を支援できるレポートか？
 • ドメイン知識を加味して解釈している？
 • レポートの数値は合ってる？
 • 数値を出すためのコードは合ってる？
 • …
 -> 人間のレビューがある状態だと（レビュー面倒臭すぎて）かなりきつい...

5. まずはText-to-SQLから！
 データ抽出・集計の土台の精度を測り、信頼性を把握したい 
 • データ集計は、データ分析の初期段階（前処理・EDA・抽出・集計）で必ず行う 必要がある
 • エンタープライズではDBアクセスは必須
 • コンテキストをどう与えれば精度が出るのかが分かれば、マルチエージェント の計画段階タスク分解の調整が可能となる

6. Text-to-SQLの評価データセットを作って
 LLMモデルの性能を比較した

7. まずは結果から！
 • Claude Sonnet 4とGPT-4.1が実行精度が高い
 • 意外だったのがOpus 4, Gemini 2.5は実行精度が低い...
 ※インストラクションは全て同じ。評価データセットは 60問
 ※ Claude CodeのおかげでLT会に間に合いました！ 

8. 今回の全体像
 ※ Claude CodeのおかげでLT会に間に合いました！ 
 ※ 今回はtheLook eCommerceのデータセットに対して評価データセットを作成 
 質問リストの生成
 合成SQL生成
 人間レビュー
 gold SQL 
 データセット
 質問
 SQLクエリ
 実行結果
 DBスキーマ 等
 Gold SQL 実行結果
 ① 独自の簡易評価データセットの作成 
 ② 評価データセットを用いて、各種 LLMモデルでtext-to-sqlの評価
 +
 実行
 評価

9. データ分析、集計、抽出に必要な質問を作成する
 • Text-to-SQLの質問とビジネスユーザーの質問が必ずしも一致する必要はな く、質問に含めるコンテキストが鍵
 • ここで重要なのが、いかにアウトプットの精度が上がる質問の仕方ができる か...
 • 過去のSQLの履歴があるならそれらを基に作成するとより実稼働状況に近い 質問を作成出来る
 Step 1: 質問リストの生成

10. Step 2: 合成SQL 生成
 ここはText-to-SQLと一緒なので深く話さないが、実環境と違って必 要な情報を含めるだけで良い！
 • 該当データセットのスキーマ情報、データモデル（ER図）を与え る
 • 各スキーマの具体体な値を与える
 • ドメイン知識やビジネスコンテキストを与える
 ※ コンテキストの与え方は、 SnowflakeのSemantic Modelの仕様の英語版が参考になる

11. Step 3: 人間レビュー
 気合と根性！ 
 一人でやると地獄 

12. Step 4: Gold SQLの完成
 今回は質問/SQLの正解ペアを60問用意
 • 複数観点の評価軸を用意
 ◦ 難易度: easy/medium/hard
 ◦ 質問種別: 時系列, セグメント分け, 集約, ランキング, …
 ◦ SQL句のタグ: window, group_by, join

13. 難易度別の各LLMの結果（実行精度）
 • 難易度のタグ付けが怪しい!? タグ付けは評価後にやるべき!?

14. Text-to-SQLの評価指標
 完全一致度 (EM)
 実行精度 (EX) 
 有効効率スコア (VES)
 生成されたSQLが正解クエリと文字列とし て完全に一致するかを評価
 
 
 SQLの実行結果が正解クエリの実行結果 と一致するかを評価 (今回はこれ )
 
 
 実行精度と実行効率の両方を評価する総 合指標
 実行精度と簡単に言うが、問いに対して正解の実行結果は無数にある
 ⇒実行結果をより正しく測れるように独自EX指標を作成
 ▪ メリット
 ・評価が高速
 ・一貫性がある
 
 ▪ デメリット 
 ・同じ結果の異なる構文を誤判定
 ・実用性が低い
 ▪ メリット
 ・ビジネス要求にも耐えうる実用的な評価
 ・構文の違いを許容
 
 ▪ デメリット 
 ・実行環境が必要
 ・評価に時間がかかる
 
 大規模データベースでは特に重要になる 指標

15. 実行結果は正しいが、出力形式が 異なる結果も正しく取得出来るよう に！
 EXから修正箇所
 • 同義の列名マッチング
 • 数値の端数処理
 • 日付・比率の正規化
 • NULL値の処理
 今回作成した既存の実行精度(EX) vs 独自評価指標
 x軸が既存実行精度 , y軸が独自の実行精度 

16. • 実ユースケースを再現可能な雑Evalsを早い段階で用意し、Evals自体を洗 練させていく手法は改善サイクルが一番早く回る感あり！
 • 正しさを担保するならText-to-SQL単体だと厳しいため、セマンティックモデル の導入が出来るようAI ReadyなDB整備早めに終わらせておくのが大切
 分析エージェントやAIエージェントについてディスカッションしたいです。 
 お気軽にX(@gota_bara)からご連絡ください！
 まとめ
 Claude Code最高！