- GeminiベースのText-to-SQL機能は、Google Cloud全体で開発者と非技術者の生産性向上に活用されている
- 実運用環境では、ビジネス文脈の不足、ユーザー意図の解釈の難しさ、SQL方言の違いにより、正確なSQL生成が難しい
- Googleはこれを解決するために、インテリジェントなデータ検索、文脈内学習、セマンティック階層化などの手法を導入している
- モデル自体の限界は、複数生成後に最適なものを選ぶ self-consistency、検証後の再プロンプト、SQL方言ごとの学習などで克服している
- 評価と改善の測定には、独自ベンチマークや LLM-as-a-judge を活用する手法を含め、実環境への適用可能性を高めている
Techniques for improving text-to-SQL
テキストからSQLへの変換: Google Cloudの現状
- 組織は迅速かつ正確なデータインサイトのためにSQLを活用している
- Geminiは自然言語から直接SQLを生成する text-to-SQL 機能を提供する
- この機能は開発者だけでなく非技術者にも有用である
- 現在、BigQuery Studio、Cloud SQL Studio、AlloyDB Studio、Vertex AI などでこの機能を提供している
Text-to-SQL技術の主要課題
1. ビジネス文脈を提供する難しさ
- 正確なSQLを書くには、LLMにデータベース構造、カラムの意味、実際のデータ内容など、十分なコンテキスト提供が必要
- コンテキストには、明示的な情報（スキーマ、カラム情報など）と暗黙的な情報（特定データのビジネス上の意味など）の両方が含まれる
- データベース構造やデータセットの変形、スキーマの変更などに合わせて、LLMを継続的に訓練（fine-tuning）する方法は、現実的にはコストが高い
- ビジネス知識や意味情報が適切に整理されていないことも多く、それを学習データへ変換すること自体も難しい
- 例: DBAが
pcat_extension テーブルの cat_id2 = 'Footwear' の意味を知らなければ、靴の販売を照会するSQLも書けない — LLMも同様に、コンテキスト不足では不正確なクエリを生成するリスクがある
2. ユーザー意図の解釈問題
- 自然言語クエリは SQLに比べて明確さが不足しがち
- 実際のデータアナリストやエンジニアは、質問が不明確なら追加質問で明確化できるが、LLMは与えられた質問にすぐ答えを生成しようとする傾向があり、誤情報（hallucination）のリスクがある
- 「最も多く売れた靴は？」のような質問では、「最も多く売れた」の基準（注文数、売上高など）や返す件数などの詳細基準が曖昧
- 技術力のあるユーザーは大まかなSQLを出発点にできるが、非専門家にとっては 正確に動作するSQL の方が重要
- 効果的に機能するには、LLMが 後続質問、推論の説明、ユーザーガイド 機能を備え、ユーザー意図を明確に把握できる必要がある
3. LLMの生成上の限界
- LLMは 文書要約、情報抽出 などには強い一方で、正確なSQL文法やあまり使われないSQL機能には弱点がある
- SQL方言ごとに文法は異なり、わずかな違いでも高い正確性が求められる
- 例: BigQueryでは
EXTRACT(MONTH FROM timestamp_column) を使うが、MySQLでは MONTH(timestamp_column) を使う必要がある
- 複雑な仕様遵守に継続して合わせてSQLを生成することは、LLMにとって容易ではない課題である
Google CloudのText-to-SQL改善手法
問題: スキーマとビジネス文脈
- 意味ベースの検索とランキング
- 文脈内学習
- データのサンプリングと接続
- セマンティック階層の構築
- 利用パターンと履歴の分析
問題: ユーザー意図の解釈
- LLMによる明確化
- エンティティを特定し、関連情報を確認したうえで適切な後続質問へ導く
問題: LLMの限界克服
- Self-consistency により複数クエリを生成し最適なものを選択
- 妥当性検証と再プロンプト
- SQL方言の例を含む文脈学習
- モデルのファインチューニング
主要技術の適用例
SQL-awareモデル
- Geminiは高品質なSQL生成のために、さまざまなファインチューニング版を使用している
- SQL方言ごとの精度を確保するため、モデルバージョンの混用とカスタム調整を行っている
ユーザー質問の明確化 (Disambiguation)
- 質問が曖昧な場合は 明確化の質問を生成
- 例: "最も売れている靴?" → 「注文数基準ですか、それとも売上基準ですか？」へ誘導
意味ベース検索と文脈構築
- 多段階の意味マッチングに基づくベクトル検索で、関連テーブルやカラムを特定
- ユーザークエリの履歴、ビジネスルールの例などを含めてプロンプトを構成
- 長いコンテキストウィンドウ対応により大規模スキーマにも対応可能
検証と再生成
- LLM生成クエリを パース、Dry-run などで検証し、明示的なエラーを検出
- エラーが検出されたら、再プロンプトで修正を促す
Self-consistency
- 1つのクエリではなく 複数の方法で多重にクエリを生成
- 複数モデルが同じクエリを推奨する場合、精度が向上する
評価と性能測定
- 既存ベンチマーク（BIRD-bench など）は有用だが、実際のスキーマ反映には限界がある
- Googleは独自の 合成ベンチマーク セットを構築している
評価戦略
- SQL方言とエンジンごとの機能を網羅: クエリ以外にDDL、DML、管理作業まで含む
- 評価指標: ユーザー反応、オフライン指標、LLM-as-a-judge
- 継続的評価: 新しいモデルやプロンプト技術の有効性を迅速に確認できる
まとめ
1件のコメント
Hacker Newsの意見
テキストからSQLへの変換の究極的な目標について考えさせられる。データアナリストの補助を作ることが目的なのか、それともアナリストを介さずにビジネスインサイトを得ることが目的なのかという話で、もし後者なら、どれだけ高度化しても非専門家がSQLの正確性や十分性を判断するのは不可能だという問題がある。「なぜ昨日のEコマース取引は80%にとどまったのか？」「なぜ顧客獲得コストが上がっているのか？」「なぜニューヨークのキャンペーンはサンフランシスコと比べて成績が悪かったのか？」のような質問は、text2sqlの範囲を超えている
実際には後者の目的に近いと思うが、成果物は期待に届いていない。ビジネスの現場では最後にレポートを変更したくなるものだが、アナリスト不足のため必要な情報を望むタイミングで得られない。「無限の速度」で解決しようとしているが、実際の問題はメトリクスについて十分に考えられていないことにある。データは複雑で、ビジネス知識は外部に暗黙知として保存されており、データインフラも不足しているため分析に時間がかかる。賢い分析リーダーたちはAIブームを利用して基盤インフラに投資している
上の質問は、そもそもSQLで解ける問題ではないと思う。SQLは主に「何が起きたか（what）」に答えるもので、「なぜ（why）」には答えない。text2sqlの目標は、アナリストが「what」を素早くこなせるよう時間を短縮し、その結果として「why」に集中できるよう支援することだ
その通りだが、私としては自然言語テキストがLLMシステムの普遍的な入力になり得ると思っている。text2sqlは、より複雑な問いへの回答を組み立てるための情報検索の基盤として機能できる。短期的には業務補助機能だが、長期的には自動化、結果比較、より大きなワークフローへの統合の土台を築くことが目標だ。こうした問いに答えるための基盤整備こそが重要で、まだやるべきことは多い
人ができることなら、どんなアルゴリズムでも作ってテストできる。10人のアナリストがいれば、データベースやビジネスに対する理解度もスキルもそれぞれ違う。自動化は、最低限のスキルと知識を保証する標準を提供する。新しいアナリストでもすぐにより良い成果を出せる。システムを専門家と協力して開発しながらテストし、AIがトレードオフやバグ、期待される結果との比較を踏まえて解釈できるようにするのは有用な目標だ。洞察力や「センス」を自動化するのは難しいが、ドメイン専門家がよく設計された自動化と妥当な結果を見極める感覚を持っていれば、かなり先まで進める。完璧ではないが、これが私の目標だ
OpenAI 4oモデルを使ってみた経験の共有。ビジネス上の指針、業界用語、テーブルや外部キーの説明を一緒にプロンプトへ渡す。すると複雑な結合クエリも生成し、結果まで返してくれる。SQLを知らないユーザー向けに結果を提供するのが目的だったが、参考用としてSQL自体も一緒に見せている
AIが完璧なSQLを生成する必要はない。私の場合、出力がコードで検証できたとしても、微妙な意味の違いのリスクがあるのでそのままコピーして使うことはない。その代わり、AIがアプローチを示してくれれば、それを参考に自分で最初からSQLを書く
Google AI Studioの最新Geminiを使ってみた経験。本当に驚くほど印象的で革新的だ。ClaudeやChatGPTのコーディング結果は、まるで別の世紀から来たもののように感じる。ほんの1か月前まではClaudeがすごいと思っていたのに、今ではGoogle Geminiなしでどうやってコーディングを続ければいいのかわからない。Gemini AI Studioはプログラミングにおける巨大な飛躍だ
まだこの変化を認識していない人が多いことに驚く。Claudeも小さな作業はうまく処理するが、複雑な問題になるとGeminiが圧倒的に優れている。特にコンテキスト処理能力が印象的だ。私はコーディングエージェントとして使うだけでなく、85,000語の原稿に対するベータリーディングにもGeminiを使っていて、専門家レベルのフィードバックレポートをほぼリアルタイムで受け取っている
今週、無料のGemini Proでは推論モードが無効化されたような気がする。コードを書き始める直前で止めたり、過度に一般化させないようにすればかなり有用だ。ただしGeminiはコードを書きすぎる傾向がある。私が主に使うやり方は、コード実装に縛られず、Geminiを設計探索に活用することだ。たとえばStripeでサブスクリプションサービスを作るケースのように、自分の技術スタックや事例に合わせた既存データを文脈付きで受け取り、1行もコードを書く前に設計方針を変えられた
答えは「セマンティックレイヤー（semantic layer）を使うこと」だ。正しい文脈を渡すのに最も効果的で、人が直接介入する最適なポイントでもある。人がすべての主要指標を明確に定義しておけば、LLMはそれをいつでも利用できる。たとえばMAUを定義しておけば、LLMはその定義を基準にクエリを生成する。SQLの代わりにJSONでクエリを書くと、LLMははるかに一貫した結果を出す。私たちはcubeを使っていて、最高のオープンソースのセマンティックレイヤーだ。Naverにはクローズドソースの選択肢もある。以前、私の会社が関連ブログも書いていたが、今は所有会社がホスティングをやめている
実務でAIを使ってSQLを作るのは危険だ。SQLを知らない人が誤ったクエリを書いてサーバーに深刻な影響を与える可能性がある。私たちのチームのデータベースは大半の開発者基準では大きいが、そこまで巨大ではない。たまに最適化済みのクエリをさらに改善してほしいとAIに頼んでも、AIがより良い答えを出したことはない。時にはAIがでたらめを言ったり、実際には役に立たない提案をしたりする。まるで間抜けなオウムが昔聞いた話を繰り返しているようだ
AIのテキスト→正規表現変換機能があれば本当に便利だと思う
私が使ってきたすべてのAIツールの中で最もがっかりしたのは、BigQueryに組み込まれたGeminiだ。カラム名も明確で説明も丁寧に付けていたのに、問題解決にはまったく近づけなかった
これまでで最も多くクエリを書いてきた言語はSQLだ。AIにクエリを書かせても、自分で書いた場合より結果を整えるのにずっと時間がかかる。副次的な話として、SQLをもっと速く書けるようにしてくれる機能が一つあればいいと思う。うちの会社のDSLには、外部キーを基準に自動結合する演算子があって非常に便利だ。SQLを書くうえで最も面倒なのは、10個、20個以上のJOIN句を一つ一つ書かなければならない部分だ。ほかの点はそれに比べればそれほど難しくない
経験上、明確な制約条件と適切に設定された外部キーがあれば、ほぼすべて解決する。各テーブルに明確な制約条件があれば、AIはすべての接続構造を正確に把握できる。SQLは非常に厳密な仕様を持っているが、その分、制約や外部キーが適切に定義されていなければ、AIも正確な答えを返せない
どのファウンデーションモデルでも、かなり簡単になってきている。テーブルスキーマにコメントがしっかり付いていれば、クエリ生成の依頼は簡単だ
smolagentsライブラリでモデル周辺のスキャフォールディングを作ってやるとかなり便利だ。text2sqlはデモでは単純に見えても、実際の複雑なケースへ適用するのは非常に難しいという記事もある
Step 1: スキーマに数千のテーブルがあり、注釈はほとんどない。Step 2...
本当にその通りだと思う。もはやそれほど魔法はない。テーブル作成DDLはテーブルの正確な説明そのものなので、実際にはそれ以上ほとんど必要ない。必要なクエリだけ詳しく説明すれば、たいていのLLMは簡単にクエリを生成できる
「Show HN: We open sourced our entire text-to-SQL product」（2024）で言及されていた資料として、awesome-Text2SQL や Awesome-code-llm > Benchmarks > Text to SQL などの優れたリファレンスがある