アーカイブ / LLM
自然文からSQLを作る前に必要な列を選ぶExSL
Extractive Schema Linking for Text-to-SQL
Extractive Schema Linking for Text-to-SQLの原論文から掲載した図です。細部はクリックして拡大できます。
原論文の図の説明を読む
Figure 1: Text-to-SQL System Architecture Overview
概要
- ExSLはDBの定義と質問から候補列ごとの関連確率を予測し、SQL生成に渡す列を選ぶ。
- 著者らのSpider開発分割では、SQL実行精度は全スキーマ入力78.7、ExSLf82.4だった。
- 導入時は対象DBの質問・正解SQLから列ラベルを作り、必要列の再現率とSQL実行精度を比較する。
補足：編集した模式図で仕組みを確認する
VISUAL EXPLAINER
図でつかむ、Extractive Schema Linking for Text-to-SQLの仕組み
- 01DB定義と質問
- 02候補列を再掲
- 03列別の確率を予測
- 04閾値で列を選択
- 05SQL用の定義
原論文の説明をもとにした模式図です。処理の細部は省略しています。
研究の背景
Text-to-SQLは、自然文の質問をデータベースの問い合わせ文であるSQLに変える技術だ。未知のDBにも使う方式では、表・列・型・表間の接続を示す「スキーマ」を質問とともに入力する。
実務のスキーマには多数の列があっても、一つの質問に必要な列は一部に限られる。全体を渡すと入力長や処理費用が増える。先に必要な部分を特定する「スキーマリンク」が、後段のSQL生成に渡す情報を決める。
手法
ExSLはDBの定義と質問の後ろに、印で囲んだ候補列を再掲する。文章を左から順に読むLLMでも、この位置なら前にある定義と質問を参照できる。印の位置に対応する内部表現から各列の関連確率を計算し、閾値を超えた列を残す。定義が長すぎる場合は、表を複数の入力に分けて判定する。
例えば「本の題名を出版価格の高い順に示す」なら、題名、価格、表の結合に使う列が候補になる。ExSLfはさらに各列のSQL内での役割を予測する。選んだ列と役割を含む定義を、別のSQL生成モデルへ渡す。
新規性
ExSLは、文章を順に生成するLLMの内部表現を使い、候補列ごとの関連確率を直接予測する。全スキーマと質問を読ませた後に列を再掲するため、判定時に両方の情報を参照できる。
ExSLfは関連性に加え、列がSQLの取得、表結合、条件、並べ替え、グループ化のどこで使われるかも予測する。列を残す閾値を調整できる点も著者らの主張する特徴だ。
従来手法との違い
比較対象は、列名の一覧を生成する方式、RESDSQLの分類方式、表を選ぶDTS-SQLなど。著者らは、評価した生成方式に対し、ExSLの抽出方式は20倍超高速だったと報告する。
表単位の評価では、ExSLcとExSLfはSpiderとBIRDの掲載分割でDTS-SQLの適合率・再現率をともに上回った。ただしBIRD開発分割のChallengingに限るSQL実行精度は、生成方式46.53、ExSLf43.75だった。
実験結果
著者らはSpiderとその派生データ、BIRDで列・表の選択とSQL実行精度を評価した。Spider開発分割の列選択PR AUCは、生成方式78.69、RESDSQL96.51、ExSLc98.52。BIRDの列選択PR AUCは生成方式69.18、ExSLc93.77だった。PR AUCは、閾値を変えたときの適合率と再現率の関係を要約する指標である。
正解SQLと実行結果が一致する割合は、Spider開発分割で全スキーマ入力78.7、ExSLf82.4、正解列を与えるGTc84.0。BIRD開発分割の全難度合計では生成方式59.71、ExSLf63.23だった。
応用の可能性
編集上の応用案 · 論文が実証した用途とは区別しています。
編集上の応用案：社内の売上DBで「月別の取引先別売上」を求める質問を受け、SQL生成前に必要な表と列を絞る。入力は質問、表名・列名・型・表間の接続情報で、出力は選んだ列と役割を添えたスキーマ、続いて生成したSQLとする。
適応には対象DBのスキーマと、質問・正解SQLの組が要る。正解SQLを解析して列と役割の教師ラベルを作り、対象の表の接続関係を反映する。新たなセンサーは想定しないが、この用途での改善は検証が必要だ。
導入時の検証
導入時の検証案 · 対象データでの再評価が必要です。
導入時の検証案：対象DBのスキーマと、実際の質問・正解SQLの組を集める。正解SQLを解析し、必要な表・列と、取得や結合などの役割ラベルを作る。センサーは不要だが、表間の接続情報や列名の変更を対象DBに合わせて反映する。
同じ質問集合で、全スキーマを渡す方式を基準に、ExSLで絞った定義を渡す方式を比べる。必要列の再現率、余分な列の割合、入力長、SQLの実行結果の一致率を記録する。閾値を変え、列の取りこぼしと結果の変化も確認する。
限界と課題
著者らは、大きなスキーマを含むBIRDでは全スキーマ入力とのSQL実行精度を比較していない。掲載値では、BIRDのChallengingで生成方式がExSLfを上回り、Spider開発分割でもExSLfは正解列を与えた条件に届かない。
編集上の検証事項は、正解SQLから作った列ラベルが実務上の必要列を表すか、表や列の変更後も選択が安定するかである。確認できた本文の範囲では、日本語の社内質問や権限管理を含む運用結果は確認できない。
出典
元のタイトル・要旨を確認する（英語）
Extractive Schema Linking for Text-to-SQL
Text-to-SQL is emerging as a practical interface for real world databases. The dominant paradigm for Text-to-SQL is cross-database or schema-independent, supporting application schemas unseen during training. The schema of a database defines the tables, columns, column types and foreign key connections between tables. Real world schemas can be large, containing hundreds of columns, but for any particular query only a small fraction will be relevant. Placing the entire schema in the prompt for an LLM can be impossible for models with smaller token windows and expensive even when the context window is large enough to allow it. Even apart from computational considerations, the accuracy of the model can be improved by focusing the SQL generation on only the relevant portion of the database. Schema linking identifies the portion of the database schema useful for the question. Previous work on schema linking has used graph neural networks, generative LLMs, and cross encoder classifiers. We introduce a new approach to adapt decoder-only LLMs to schema linking that is both computationally more efficient and more accurate than the generative approach. Additionally our extractive approach permits fine-grained control over the precision-recall trade-off for schema linking.
論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。解説更新：2026-10-01