なぜText-to-SQLはエンタープライズ環境で失敗するのか
ほとんどのText-to-SQLのデモは、あまりにも綺麗すぎる。
それらはシンプルなスキーマや分かりやすいテーブル名を使用している。1つか2つのテーブルが完璧に紐付いていることを前提としている。これはデモとしては機能するが、実際の企業では失敗する。
エンタープライズのデータベースにおいて、難しいのはSELECT句ではない。難しいのはジョインパス（結合パス）だ。
モデルは「顧客別の収益」を求める有効なクエリを書くかもしれない。SQLは実行され、ダッシュボードには数字が表示される。しかし、その答えは間違っている。
なぜこのようなことが起こるのか？
- 顧客テーブルが公式のマスターリストではない。
- 収益フィールドが財務部門によって承認されたバージョンではない。
- 地域間でレコードが重複している。
- ジョインによってファンアウト（データの増幅）エラーが発生する。
- 会計年度のカレンダーが暦年と異なる。
構文的に正しいクエリが、信頼できるクエリであるとは限らない。
本番環境のシステムは混沌としている。外部キーの欠落、レガシーなテーブル、数値を膨らませてしまう1対多のリレーションシップなどに直面することになる。人間でさえ、ジョインを信頼する前に古いレポートを確認したり、財務部門に問い合わせたりする必要がある。
AIモデルが見ているのは名前とカラムだけだ。モデルは推測する。その推測が時に危険な結果を招く。
ファンアウトを例に考えてみよう。注文（orders）を注文明細（order lines）にジョインし、さらに出荷（shipments）にジョインすると、1つの注文が複数回カウントされてしまうことがある。SQLは正しい。しかし、結果は間違っている。
メタデータは助けにはなるが、それだけでは不十分だ。カラム名を見ても、そのリレーションシップが財務報告において安全かどうかは分からない。外部キーは、過去の例外的なケースを説明してはくれない。
Text-to-SQLにはリレーションシップ・インテリジェンス（関係性の知能）が必要だ。
信頼できるシステムは、以下のことを知っていなければならない：
- 特定のビジネス上の問いに対して承認されたジョインパス。
- リレーションシップのカーディナリティ。
- 既知のファンアウトのリスク。
- どのパスが非推奨であるか。
単にコードを書くのではなく、システムは安全性について推論すべきである。信頼できるパスを選択するか、パスが不明確な場合には助けを求めるべきだ。
現在のシステムにおけるギャップは、「名前のマッピング」から「SQLの生成」への飛躍にある。そこにリレーションシップのコンテキスト（文脈）というレイヤーを追加しなければならない。
Text-to-SQLは単なる言語の問題ではない。コンテキストの問題なのだ。
モデルがどのジョインが安全であるかを理解できるようになるまで、デモでは機能しても本番環境では失敗し続けるだろう。
Source: https://dev.to/arisyndata/why-text-to-sql-breaks-when-the-join-path-is-not-obvious-3bk0
Optional learning community: https://t.me/GyaanSetuAi