Sechs Tabellen aus 260: Die Fallstricke der Tabellenauswahl bei Text-zu-SQL

Hintergrund

Text-zu-SQL-Systeme erwecken den Eindruck, als würden sie natürliche Sprache direkt in Abfragen verwandeln. Die Praxis verbergt jedoch einen Schritt, über den kaum jemand schreibt. Bevor ein Modell irgendetwas erzeugen kann, muss jemand entscheiden, welche Tabellen es zu Gesicht bekommt. Eine echte Datenbank kann 260 Tabellen enthalten, und ein Prompt-Fenster fasst nicht deren gesamte Schema-Struktur, geschweige denn ohne Nachteile: Je mehr man einquetscht, desto mehr verdünnt sich die Aufmerksamkeit des Modells und steigen Latenz und Kosten. Das System muss also vor der Generierung auf eine kleine Auswahl an Tabellen reduzieren.

Dieser Filter wird fast immer als Retrieval-Problem behandelt. Jede Tabelle wird in einen Vektor eingebettet, die Frage des Nutzers durchsucht diese Einbettungen, die Ergebnisse werden nach Ähnlichkeit sortiert und die besten sechs Tabellen ausgewählt. In Demonstrationsumgebungen funktioniert diese Pipeline zufriedenstellend, denn dort sind die Schemas sauber benannt und strukturiert. Die Fragen lassen sich direkt auf Tabellennamen abbilden, sodass die natürliche Trefferquote hoch bleibt, und die Industrie hat stillschweigend angenommen, das Problem sei gelöst.

Tiefenanalyse

Der Autor erkannte die Kluft zwischen dieser演示-Confidence und der Produktionsfragilität und konstruierte deshalb bewusst ein Schema, das genau darauf ausgelegt ist, den Mechanismus zu durchbrechen. Er ließ seine eigene Bibliothek dagegen laufen und erhielt eine Recall-Zahl, die er lieber nicht veröffentlicht hätte – zugleich die wertvollste Erkenntnis. Der Kern des Problems liegt darin, dass Retrieval-Relevanz nicht mit Abfrage-Richtigkeit gleichzusetzen ist. Die RAG-Table-Auswahl stützt sich auf semantische Ähnlichkeit zwischen Frage und Schema, SQL benötigt jedoch die logische Erreichbarkeit zwischen Tabelle und Abfrageintention.

Eine Tabelle kann mit der Frage weder im Namen noch in den Feldern gemeinsam haben und doch essenziell für die Beantwortung sein. Stellen Sie sich eine Tabelle audit_log vor, die der Frage dient, wie viele Nutzer diesen Monat ihr Passwort geändert haben. Die eigentliche Antwort hängt möglicherweise von einem Datensatz in user_actions ab, in dem eine Spalte als action_type=7 hartkodiert ist, während die Wörter Passwort und Ändern im Schema gar nicht vorkommen. Textähnlichkeits-Retrieval wirft sie ohne Zögern raus. Umgekehrt kann eine Tabelle, deren Name zufällig mit einem Stichwort zusammenstößt, reine Störgröße sein.

Schlimmer noch ist die Lage bei Fremdschlüsseln. Richtige Antworten erfordern oft das Joinen mehrerer Tabellen, doch Top-K-Retrieval bewertet jede Tabelle unabhängig und weiß nichts über ihre Nachbarn. Es erkennt strukturelle Abhängigkeiten nicht, etwa dass die Auswahl von Tabelle B die von Tabelle A voraussetzt. Selbst bei genügender Einzeltabellen-Relevanz bleibt die zusammengesetzte Abfrage unvollständig. Die Reduktion auf Vektorretrieval setzt also voraus, dass die ähnlichste Tabelle die am meisten benötigte ist – eine Annahme, die in komplexen Schemas fast unvermeidlich zusammenbricht.

Branchenwirkung

Diese Erkenntnis untergräbt eine stillschweigende Voraussetzung zahlloser existierender Text-zu-SQL-Produkte. Für Unternehmen, die BI- und Datenanalyse-Werkzeuge bauen, ist die Tabellenauswahl das vorgelagerte Tor, das die Endgenauigkeit bestimmt. Wenn dieses Tor versagt, kann selbst beste nachgelagerte Abfragegenerierung oder Fehlerkorrektur nicht retten, und die Nutzer sehen schlicht ein System, das Fragen nicht beantwortet, die sie für beantwortbar halten – ohne zu verstehen warum.

Kleine Unternehmen und interne Tool-Teams sind besonders exponiert. Ihre Datenbanken tragen oft unsaubere Benennung, schweren historischen Ballast und hochgradig implizite Semantik – genau die Bedingungen, unter denen ein bewusst gebrochenes Schema glänzt. Die Kluft zwischen Demo-Leistung und realer Erfahrung wird dabei augenfällig. Für die Entwicklergemeinschaft lenkt die Analyse die Aufmerksamkeit vom Streit um Modellgröße und Prompt-Führung zurück auf das grundlegendere, untererforschte Ingenieurthema der Schema-Retrieval- und Organisationsstrategie selbst.

Ausblick

Mehrere Richtungen verdienen Aufmerksamkeit. Die wichtigste ist, ob sich Join-Beziehungen, Constraints und Informationen über die Verteilung von Feldwerten in das Retrieval einbauen lassen, anstatt sich allein auf Textähnlichkeit zu verlassen – möglicherweise der Schlüssel zum Durchbrechen der aktuellen Decke. Zweitens stellt sich die Frage, ob dedizierte Bewertungs-Benchmarks entstehen, die mit bewusst konstruierten Trap-Schemas die wahre Untergrenze des Recall messen, statt nur schöne Demo-Zahlen zu berichten. Drittens, ob Hybrid-Retrieval und Reranking strukturelle Abhängigkeiten wirklich lösen können, indem etwa grob vorselektiert und anschließend über Graphenstrukturen erweitert wird.

Für Teams, die ein Text-zu-SQL-System bauen oder auswählen, ist der pragmatischste Schritt, aufzuhören, Demo-Schema-Metriken als Schlussfolgerung zu behandeln. Stattdessen sollte man den Table-Recall gegen Daten laufen lassen, die der realen Komplexität der eigenen Datenbank entsprechen, und beobachten, wie stark sich die End-to-End-Genauigkeit einbricht, wenn benötigte Tabellen schlicht nicht ausgewählt werden. Diese Zahl sagt oft mehr aus als jedes Modell-Benchmark.