自己回帰LLMなしでSQLを1パス生成できるか？ 動的アクションマスキングによる構文保証（61.7%）と未知スキーマの壁
SELECT句やWHERE句をトークンごとに自己回帰生成せず、7つの構造スロットを並列予測するエンジンのクロスDB検証（訓練16ドメイン・未見テスト4ドメイン60クエリ）から、30ms以下の型安全設計で解ける問題と解けないボトルネックを解剖します。
- SQLの固定構文を1文字ずつ自己回帰生成せず、7つの構造スロット（主テーブル・SELECT列・集計関数・WHERE列・演算子・ソート順・件数上限）を1パスで並列予測し動的スキーママスクを掛けることで、未知DBでも61.67%のクエリがエラーなく実行（Valid Execution）できた。
- しかし、未知スキーマにおける「SELECTカラム選択（18.33%）」と「WHEREカラム選択（31.67%）」が最大のボトルネックとなり、実行結果の完全一致（EX）は10.00%（Healthcareドメインでは0.0%）にとどまった。
- スロット並列＋動的マスクは「既知スキーマでの高速ルーティング」や「ORDER/LIMIT句（86.67%）・主テーブル特定（55.00%）」には有効だが、未知のカラム名と自然言語の意味的アライメントにはCross-EncoderやLLMの文脈推論が不可欠である。
1. 条件別の比較表 列見出しクリックで数値ソート可能
| order_direction (ソート方向) | スロット個別精度 | 86.67 % | 60 件 | 昇順・降順・指定なしの3値分類であり、未知DBでも安定 |
|---|---|---|---|---|
| limit (取得件数上限) | スロット個別精度 | 86.67 % | 60 件 | クエリ内の数値表現と直結しておりスキーマ変化の影響を受けにくい |
| Valid Execution (構文有効実行) | 全体実行指標 | 61.67 % | 60 件 | 動的マスクで存在しない識別子は排除されるが、型の不整合等で約38%は失敗 |
| primary_table (主テーブル選択) | スロット個別精度 | 55.00 % | 60 件 | 複数テーブルが候補となるドメインで類似テーブル名と混同 |
| operator (比較演算子) | スロット個別精度 | 41.67 % | 60 件 | WHERE列や集計条件との組み合わせ依存で誤選択が発生 |
| agg_func (集計関数) | スロット個別精度 | 31.67 % | 60 件 | COUNT / SUM / AVG の選択が対象カラムの粒度に依存する |
| where_column (条件カラム選択) | スロット個別精度 | 31.67 % | 60 件 | 未知スキーマの列名と自然言語の条件表現のアライメント不足 |
| select_column (出力カラム選択) | スロット個別精度 | 18.33 % | 60 件 | 最大のボトルネック。1パス並列予測ではテーブル選択後の列絞り込み文脈が不足 |
| Automotive ドメイン EX | 未知ドメイン別EX | 15.38 % | 13 件 | 比較的明快なテーブル構造だが列選択の取りこぼしが響く |
| Finance / Airline ドメイン EX | 未知ドメイン別EX | 13.33 % | 30 件 | 金額・日付・ステータス列など類似カラム間の識別に失敗 |
| Healthcare ドメイン EX | 未知ドメイン別EX | 0.00 % | 17 件 | 専門用語とカラム名の乖離が大きく、全スロット同時正解が0件 |
2. 未知4ドメイン（N=60）におけるSQL構造スロット別の正解率と全体精度のギャップ 単位: %
結果をどう読むか
検証の狙い：なぜSQLを1トークンずつ自己回帰生成したくないのか
汎用LLMでデータベース操作やツール呼び出しを行う際、`SELECT` や `FROM` といった固定構文トークンを1文字ずつ自己回帰（Autoregressive）で生成すると、数百ミリ秒〜数秒のレイテンシとトークン課金が発生します。また、フラットな選択肢しか扱えない軽量分類器では「テーブルを選ぶと選べるカラムが変わり、カラムを選ぶと有効な演算子が変わる」という従属引数（Dependent Arguments）の組み合わせ爆発を扱えません。そこで本検証では、SQLクエリを7つの構造スロット（`primary_table`, `select_column`, `agg_func`, `where_column`, `operator`, `order_direction`, `limit`）に分解し、Slot-Parallel Multi-Head分類器と動的スキーママスキング（Dynamic Action Masking）を組み合わせて、30ms以下の単一〜極小フォワードパスで直接SQL構造を出力できるかを実験しました。
効いた部分：動的アクションマスキングによる61.67%の実行保証と意図スロット
16種類のドメインDB（CRM、DevOps、EC、人事、物流など）で学習させた後、学習時に一度も登場していない4つの未知ドメイン（Automotive、Finance、Healthcare、Airlineの計60クエリ）でゼロショット評価を行いました。スキーマに存在しないテーブル名やカラム名をサンプリング前にマスク（確率ゼロ化）する機構とSQLite実行検証（RLEV）により、自己回帰LLMを使わずとも61.67%のクエリが構文エラーなくSQLite上で有効実行（Valid Execution）されました。特にスキーマ構造に依存しない `order_direction`（86.67%）や `limit`（86.67%）、および最初の起点となる `primary_table`（55.00%）は、1パスの軽量ヘッドでも実用的な水準で予測できています。
ぶつかった壁：なぜ未知スキーマのカラム選択（18.33%）で急落するのか
一方で、クエリ全体の実行結果が正解と完全一致した割合（Execution Accuracy: EX）は10.00%（Exact Matchは1.67%）、専門用語が多いHealthcareドメインではEX 0.00%にとどまりました。スロット別の正解率を分解すると原因は明白で、`select_column` が18.33%、`where_column` と `agg_func` が31.67%と大きく落ち込んでいます。SQLは7つのスロットすべてが同時に正解しなければ正しい結果集合が返りません（例えば7スロットの平均正解率が50%でも、独立なら0.5^7 = 0.78%にしかなりません）。特に1パスで全スロットを並列予測する設計では、「どのテーブルを選んだか」が確定する前の共有表現からカラムを予測するため、未知DBの似たような列名（例：`amount` と `balance` と `fee`）を自然言語の微妙なニュアンスと照合する表現力が決定的に不足します。
設計上の結論：1パス並列予測を使うべき場所、LLMに残すべき場所
このネガティブリザルトから得られる実務上の境界線は明確です。（1）スキーマが固定された自社アプリの操作ルーティングや、フィルタ条件・ソート順・件数上限（`ORDER BY` / `LIMIT`）の高速抽出には、30ms以下のスロット並列＋動的マスクが非常に有効です。（2）しかし、未知のデータベーススキーマに対するText-to-SQLのように「初めて見るカラム名とユーザー意図の深い意味的アライメント」が求められるタスクでは、1パス並列分類器だけで完結させようとするとカラム選択（18.3%）がボトルネックになります。未知スキーマを扱う場合は、無理に自己回帰を全廃するのではなく、「テーブル特定と構文制約（Grammar / Schema Constrained Decoding）だけマスクで保証し、カラム選択にはCross-Attentionまたは小規模LLMの段階的推論を使う」ハイブリッド構成が現実的です。
よくある疑問
Q. Valid Execution（61.67%）と Execution Accuracy（10.00%）は何が違うのですか？
Valid Execution（VE）は「生成されたSQLが対象データベースのスキーマに対して構文エラーや存在しないカラム参照を起こさず、SQLite上で正常に実行完了した割合」です。Execution Accuracy（EX）は「実行した結果のデータ行が、正解SQLの実行結果と完全に一致した割合」を指します。
Q. なぜ1パスで全スロットを並列予測するとカラム選択の精度が落ちるのですか？
本来、SELECT句やWHERE句のカラムは「どのテーブル（primary_table）を選んだか」に強く従属します。推論時にテーブル予測マスクを適用しても、エンコーダ内部の特徴量自体が「未知スキーマの全カラム候補と質問文の細かな対応関係」を1回のフォワードパスで解きほぐすには容量不足となるためです。
Q. 動的アクションマスキング自体はText-to-SQLに有効と言えますか？
はい。マスクなしでは未知スキーマに対して存在しないテーブル名やカラム名を出力してほぼ100%実行エラーになりますが、動的スキーママスクを入れることで61.67%を実行可能なクエリに収束させられます。LLMのConstrained Decoding（構造化出力制約）と組み合わせるのが最も効果的です。
検証条件と出典
https://nodus-lab.pages.dev/articles/slot-parallel-sql-generation-dynamic-masking-benchmarks.html