Dlaczego Text-to-SQL zawodzi w przedsiębiorstwach

Większość demonstracji Text-to-SQL jest zbyt idealna.

Używają prostych schematów i oczywistych nazw tabel. Zakładają, że jedna lub dwie tabele łączą się idealnie. To działa w wersji demonstracyjnej. Zawodzi w prawdziwej firmie.

W bazach danych klasy enterprise najtrudniejsza nie jest klauzula SELECT. Najtrudniejsza jest ścieżka łączenia (join path).

Model może napisać poprawne zapytanie dotyczące przychodów według klienta. SQL się wykonuje. Dashboard pokazuje liczby. Ale odpowiedź jest błędna.

Dlaczego tak się dzieje?

  • Tabela klientów nie jest oficjalną listą główną.
  • Pole przychodu nie jest wersją zatwierdzoną przez dział finansowy.
  • Rekordy są duplikowane w różnych regionach.
  • Łączenie (join) powoduje błędy typu fanout.
  • Kalendarze fiskalne różnią się od kalendarzowych.

Zapytanie poprawne składniowo nie jest zapytaniem godnym zaufania.

Prawdziwe systemy produkcyjne są chaotyczne. Możesz napotkać brakujące klucze obce, tabele legacy i relacje jeden-do-wielu, które zawyżają liczby. Nawet ludzie muszą sprawdzić stare raporty lub zapytać dział finansowy, zanim zaufają wynikowi łączenia tabel.

Model AI widzi tylko nazwy i kolumny. Zgaduje. Czasami to zgadywanie bywa niebezpieczne.

Rozważmy fanout. Jeśli połączysz zamówienia z pozycjami zamówienia, a następnie z przesyłkami, jedno zamówienie może zostać policzone wielokrotnie. SQL jest poprawny. Wynik jest błędny.

Metadane pomagają, ale to za mało. Nazwy kolumn nie mówią, czy dana relacja jest bezpieczna dla raportowania finansowego. Klucze obce nie wyjaśniają historycznych wyjątków.

Text-to-SQL potrzebuje inteligencji relacyjnej.

Niezawodny system musi wiedzieć:

  • Zatwierdzone ścieżki łączenia dla konkretnych pytań biznesowych.
  • Kardynalność relacji.
  • Znane ryzyka fanout.
  • Które ścieżki są przestarzałe.

Zamiast tylko pisać kod, system powinien rozumować w kwestii bezpieczeństwa. Powinien wybierać zaufaną ścieżkę lub prosić o pomoc, gdy ścieżki są niejasne.

Luka w obecnych systemach to skok od mapowania nazw do generowania SQL. Należy dodać warstwę kontekstu relacyjnego.

Text-to-SQL to nie tylko problem językowy. To problem kontekstowy.

Dopóki modele nie będą rozumiały, które połączenia są bezpieczne, będą działać w demonstracjach, ale zawiodą w produkcji.

Źródło: https://dev.to/arisyndata/why-text-to-sql-breaks-when-the-join-path-is-not-obvious-3bk0

Opcjonalna społeczność edukacyjna: https://t.me/GyaanSetuAi