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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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