260テーブルから6つを選ぶ：テキストからSQLへのテーブル選択の落とし穴

背景と概要

テキストからSQLへの変換システムは、自然言語をそのままクエリに変換しているように見える。しかし実際の導入では、誰も書き記さない重要なステップが隠されている。モデルが任何のSQLを生成する前に、そのモデルがどのテーブルを参照できるかを誰かが決定しなければならない。実際のデータベースには260個のテーブルが存在することがあるが、プロンプトの窓口に全スキーマを収めることはできない。収めたとしても、注意力が散漫になり、レイテンシとコストが上昇するだけだ。そのためシステムは生成前に候補を絞り込まなければならない。

この絞り込みはほぼ常に検索問題として扱われる。各テーブルのスキーマをベクトル埋め込みに変換し、ユーザーの質問で検索し、類似度でランク付けして上位6つを選ぶ。この処理はデモ環境では十分に機能する。デモで使われるのは命名が規則正しく整然とした40テーブルのスキーマであり、質問とテーブル名が直接的に対応するため、検索の自然な命中率が高く保たれる。その結果、業界はこの問題は解決済みだと黙認してきた。

深掘り分析

著者はこのデモレベルの自信と生産レベルの脆弱性のギャップに気づき、意図的にこの機構を壊すように設計されたスキーマを構築し、自分のライブラリで実測した。その結果、公開したくないような_recall_の数値が得られたが、それは最も価値のある発見だった。核心は、検索の関連性はクエリの正解性と等しくないということだ。RAG方式のテーブル選択は質問テキストとスキーマの语义的類似度に依存する。しかしSQLが本当に必要なのは、テーブルとクエリ意図との論理的到達可能性だ。

名前やフィールドが質問と一切共通しないテーブルでも、回答に必須であることがある。`audit_log`というテーブルを、今月パスワードを変更したユーザー数を答えるために使う場合を设想してみよう。実際の答えは、`user_actions`テーブルのaction_type=7としてハードコードされたレコードに依存する可能性がある。一方、passwordやchangeという言葉はスキーマに一切登場しない。テキスト類似度による検索は迷わずこれを除外する。逆に、名前に質問のキーワードが偶然一致するテーブルは単なるノイズである。外鍵関係は状況をさらに悪化させる。正解は複数テーブルのjoinを必要とすることが多いが、Top-K检索は各テーブルを独立に採点するため、Aテーブルを選べばBテーブルも必須といった構造的依存を検出できない。

業界への影響

この発見は、多くの既存テキストからSQLへの変換製品の暗黙の前提を揺るがす。BIやデータ分析ツールを構築する企業にとって、テーブル選択は最終的な精度を決定する上流のゲートだ。このゲートが失敗すれば、下流のSQL生成や誤り修正のいかなる努力も取り返せず、ユーザーは答えられるはずの質問に答えないシステムを見るだけだ。なぜそうなるのかは理解できないままだ。

中小企業や内部ツームのチームは特に脆弱だ。彼らのデータベースは命名が混乱し、歴史的な包袱が重く、语义が高度に暗黙的であることが多く、まさに意図的に壊されたスキーマが威力を発揮する条件だ。デモでのパフォーマンスと実際の体験の隔たりは際立つ。開発者コミュニティにとって、この分析の価値は、モデルが十分に大きいか、プロンプトをどう書くかといった热门话题から、スキーマの检索と組織化というより基礎的だが未研究な工程の関心へと注意を向ける点にある。テーブル選択はモデル能力の附属品ではなく、独立した研究対象なのだ。

今後の展望

注目すべき方向がいくつかある。最も重要なのは、join関係や制約、フィールド値の分布情報を检索に組み込めるかどうかだ。テキスト類似度だけに依存せず、これが現在の天井を破る鍵となる可能性がある。第二に、意図的に構築したトラップスキーマを用いてrecallの真の下限を測定する、テーブル選択専用の評価ベンチマークが登場するかどうかだ。単に美しいデモの数値を報告するだけでは不十分だ。第三に、混合检索と並べ替えが構造的依存問題 genuinelyに解決できるかどうかだ。まず粗く絞り込み、その後グラフ構造を用いて関係を展開する方法などが考えられる。

テキストからSQLへの変換システムを構築または選定するチームにとって、最も実務的な方法は、デモスキーマの指標を結論として扱うのをやめることだ。自分のデータベースの複雑さに近いデータでテーブルのrecallを実行し、必要なテーブルが選ばれなかった場合にエンドツーエンドの精度がどの程度低下するかを観測する。その数値は、どのモデルベンチマークよりも多くのことを語ってくれる。