Warum eine Genauigkeit von 90 % bei Textual content-to-SQL zu 100 % nutzlos ist

Ich arbeite seit über 20 Jahren im Analytics-Bereich. Damals hieß es noch nicht „Analytics“, sondern „Enterprise Intelligence“ oder früher sogar „Determination Assist Methods“. Die Begriffe ändern sich, von Knowledge Warehouses über Massive Knowledge bis hin zu Lakehouses, und mit der KI bleibt die Essenz und das ewige Versprechen von Self-Service Analytics dasselbe: Wahrheit aus Daten extrahieren, um Benutzer zu befähigen, ohne sich auf jemanden aus dem Datenteam verlassen zu müssen. KI ohne Menschen im Kreislauf? Das klingt kontrovers.

Mit dem Aufkommen von Giant Language Fashions (LLMs) ist ein Anwendungsfall, den ich faszinierend finde, die Entwicklung von Konversationsschnittstellen zum Chatten mit Datenbanken (Textual content-to-SQL). Das Potenzial hier ist immens und verspricht, den Datenzugriff organisationsübergreifend zu demokratisieren.

Für diesen speziellen Anwendungsfall muss die Lösung jedoch binär sein. Entweder es funktioniert oder nicht.

Eine Genauigkeit von 80 % oder gar 90 % reicht leider nicht aus. Es ist kein Scherz, Ihren Endbenutzern eine KI-Analyseanwendung zur Verfügung zu stellen, die Tabellen halluziniert oder Filter falsch interpretiert. Bei der Genauigkeit dürfen Sie keine Kompromisse eingehen, da dadurch das Vertrauen sofort untergraben wird. Und was passiert, wenn ein System das Vertrauen verliert? Es wird nicht verwendet. Die Akzeptanz wird zurückgehen, ohne dabei das katastrophale Risiko zu vergessen, dass Geschäftsentscheidungen auf der Grundlage falscher Daten getroffen werden.

Die Komplexität der RAG-Pipeline

Ich habe vor über anderthalb Jahren mit der Recherche zu diesem Thema begonnen und mir wurde schnell klar, dass die Orchestrierung einer robusten Textual content-to-SQL-RAG-Anwendung (Retrieval-Augmented Era) nicht trivial ist. Sie benötigen mehrere Komponenten in Ihrer Pipeline, die perfekt harmonieren:

• Ein Absichtsklassifikator um das Ziel der Frage zu erkennen.
• A Vektordatenbank um zusätzlichen Kontext (wie Geschäftsdefinitionen) zu speichern, den die Sprachmodelle benötigen.
• Ein Einbettungsmodell dieses zusätzliche Wissen zu vektorisieren.
• A Abrufmechanismus für die gespeicherten Daten.
• Zugriff auf die Datenbank.
• Die Möglichkeit, SQL im zu generieren spezifischer Dialekt der Datenbank.
• Und die Fähigkeit dazu auswerten die Ergebnisse.

Dieser letzte Teil, die Bewertung, wird meines Erachtens oft weggelassen oder als nachträglicher Einfall behandelt, aber er ist vielleicht die wichtigste Komponente, um die in einem Unternehmensumfeld erforderliche Zuverlässigkeit sicherzustellen.

BigQuery: Eine Fallstudie zur nativen KI-Integration

Die Verwaltung dieser komplexen Pipeline erfordert oft die Integration mehrerer Plattformen. Ich battle kürzlich beeindruckt davon, wie BigQuery die Fusion von Analytics und generativer KI nativ in seine Plattform integriert hat.

Sie haben die Möglichkeit, mit Ihrem SQL in der BigQuery-IDE zu arbeiten und Gen AI sofort zu nutzen, ohne auf eine andere Plattform oder ein anderes Produkt umsteigen zu müssen. Beispiel: Sie können die Datenbank abfragen und die abgerufenen Ergebnisse können sofort an Gemini gesendet werden (oder Sie können über Vertex auch andere Modelle hinzufügen). Mit Gemini können Sie Absichten klassifizieren, Einbettungen erstellen und diese in den Vektordatenbankfunktionen von BigQuery speichern, eine semantische Suche durchführen und SQL generieren.

Und das alles mit nur einer Plattform, ohne dass Sie mehrere Abonnements verwalten müssen.

Natürlich hat es, wie alles im Leben, seine Nachteile.

Einer der Hauptnachteile besteht darin, dass BigQuery möglicherweise nicht die günstigste Datenbank ist, und ich habe Geschichten von Startups gehört, bei denen eine einzige falsche Abfrage Ihre Kreditkarte belasten kann. Es ist mir noch nicht passiert, aber ich kann nachvollziehen, wie so etwas passieren kann. Ein weiterer Nachteil wäre, dass Sie vollständig an Google gebunden sind. Vielleicht ist das keine schlechte Sache; Genauso sind wir alle an Gmail gebunden. Vielleicht wird KI in Zukunft eine Ware sein, so wie es E-Mails heute sind.

Ein weiterer Nachteil ist das Fehlen einer detaillierten Rückverfolgbarkeit der Token-Kosten und einer Artwork „Schein-LLM“ für die Entwicklung; Sie möchten das wirklich teure LLM in Ihrer Entwicklungsphase nicht wirklich nutzen.

Wenn Sie mit den oben genannten Nachteilen einverstanden sind, erhalten Sie ein großartiges Produkt, das mehrere Instruments in einer einzigen Cloud-Plattform vereint, die große Datenmengen verarbeiten kann.

Ich habe das folgende Repo erstellt, das Teil des Kaggle-Hackathons battle, bei dem ich diese nativen BigQuery-Funktionen weiter untersucht habe. Für weitere Informationen besuchen Sie bitte das Repo hier:

https://github.com/garyzava/bigq-ethereum-rag

Das fehlende Stück: Strenge Bewertung

Kommen wir nun zurück zu den Evaluierungsframeworks. Plattformen wie BigQuery vereinfachen das Architekturaber sie lösen das Downside nicht automatisch Genauigkeit Downside. Ich sehe mehrere Lösungen, aber den meisten mangelt es an robusten Evaluierungsfunktionen.

Wenn wir akzeptieren, dass Textual content-to-SQL binär sein muss (richtig oder falsch), brauchen wir Bewertungsstrategien, die die chaotische Realität von Unternehmensdaten widerspiegeln, und nicht die makellosen Umgebungen akademischer oder Demo-Datensätze.

Die Bewertung eines Textual content-to-SQL-Methods ist aufgrund der deklarativen Natur von SQL und der Komplexität Ihres Datenbankschemas bekanntermaßen schwierig. Hat es Tausende von Tischen? Sind diese Tabellen intestine dokumentiert? Wahrscheinlich nicht. Sind die Namenskonventionen in allen Tabellen konsistent? Zwei Abfragen können syntaktisch völlig unterschiedlich aussehen (z. B. unterschiedliche Verknüpfungsreihenfolgen, Aliasing oder Verwendung von CTEs), aber identische Ergebnisse liefern.

Um Ihre RAG-Anwendung während der Entwicklung und in der Produktion wirklich einem Benchmarking zu unterziehen, müssen Sie die richtigen Metriken verwenden.

Wichtige Kennzahlen

Um auf das Versprechen von Self-Service-BI oder -Analysen zurückzukommen: Das bedeutet, dass sich der Endbenutzer zu 100 % auf sich selbst verlassen kann; Leider gibt es keinen Human-in-the-Loop oder Datenexperten, der die Ergebnisse validieren könnte. Aus diesem Grund müssen wir eine erklärbare KI oder einen Bewertungsrahmen mit einer Reihe von Metriken etablieren, um die Qualität des generierten SQL zu messen.

1. Der Wandel zur Ausführungsgenauigkeit (EX): Frühe Benchmarks basierten auf Actual Match (EM), das die vorhergesagte SQL-Zeichenfolge mit der Grundwahrheit verglich. Dies battle zutiefst fehlerhaft, da es gültige syntaktische Variationen bestrafte. Der moderne Customary ist Execution Accuracy (EX). Diese Metrik führt sowohl das vorhergesagte SQL als auch das „Gold“-SQL (Floor Fact) mit der tatsächlichen Datenbank aus und vergleicht die zurückgegebenen Ergebnismengen. Dadurch werden Abfragen korrekt validiert, unabhängig davon, wie sie geschrieben sind.
2. Fokussierte Bewertung: In Unternehmenskontexten kann eine Abfrage zusätzliche, nicht wesentliche Spalten zurückgeben (z. B. eine ID-Spalte, die für einen Be part of verwendet wird). Eine strikte Ausführungsgenauigkeit kann dies als Fehler markieren. „Ausführungsbasierte, fokussierte Auswertung“ ermöglicht einen differenzierteren Vergleich, prüft, ob die Zielspalten und -werte korrekt sind, und geht gleichzeitig nachsichtiger mit überflüssigen Daten oder der Zeilenreihenfolge um.
3. Die „Tender-F1“-Metrik: Um die binäre Natur der Ausführungsgenauigkeit (bei der eine falsche Zelle den gesamten Check nicht besteht) abzuschwächen, wird zunehmend Tender-F1 verwendet. Diese Metrik liefert eine teilweise Anerkennung, indem sie die Überschneidung zwischen den vorhergesagten und den Gold-Ergebnissen berechnet. Wenn eine Abfrage 99 von 100 korrekten Zeilen zurückgibt, spiegelt Tender-F1 eine hohe Leistung wider, während EX 0 zurückgeben würde. Dies ist für das Debuggen von entscheidender Bedeutung.
4. LLM-als-Richter: Manchmal ist die Ausführung unmöglich (z. B. fehlende personal Daten, Umgebungsfehler). In diesen Fällen kann ein erweitertes LLM veranlasst werden, die semantische Logik des vorhergesagten SQL mit dem Gold SQL zu vergleichen. Obwohl es weniger objektiv ist als die Ausführung, korreliert es doch stark mit dem menschlichen Urteilsvermögen.

Spider 2.0: Der Enterprise Actuality Verify

Derzeit gibt es drei bemerkenswerte Evaluierungsframeworks: Spider 2.0, BIRD (BIg Bench for LaRge-scale Database Grounded Textual content-to-SQL) und SynSQL (basierend auf synthetischen Daten). Allerdings leidet die Branche unter einem falschen Sicherheitsgefühl, das durch veraltete Benchmarks entsteht. Jahrelang vertraute die Branche auf Spider 1.0. Der Schwerpunkt lag auf kleinen, sauberen SQLite-Datenbanken (durchschnittlich weniger als 10 Tabellen). Die Modelle erreichten eine Genauigkeit von über 90 %, was viele zu der Annahme veranlasste, das Downside sei „gelöst“.

Der Rahmen, den ich immer betone, der diese modernen Metriken einbezieht und die Unternehmensbereitschaft wirklich testet, ist Spinne 2.0.

Spider 2.0 (veröffentlicht in Verbindung mit ICLR 2025) ist ein Paradigmenwechsel, der darauf abzielt, diese „Realitätslücke“ zu schließen, indem die Komplexitäten eingeführt werden, die LLMs in der Produktion zerstören:

1. Massiver Maßstab: Unternehmensschemata sind riesig. Spider 2.0-Datenbanken umfassen durchschnittlich 812 Spalten, einige davon über 3.000. Dieser Umfang überschreitet häufig die Kontextgrenzen des LLM und zwingt Modelle dazu, „Schema Linking“-Strategien (Abrufstrategien) zu verwenden, nur um die relevanten Tabellen zu identifizieren, bevor SQL generiert wird.
2. Dialektvielfalt: Echte Unternehmen nutzen Snowflake, BigQuery und T-SQL, nicht nur SQLite. Spider 2.0 erzwingt die Dialektvielfalt und erfordert, dass Modelle eine bestimmte Syntax beherrschen (z. B. den Umgang mit verschachtelten JSON-Daten mithilfe von UNNEST oder FLATTEN).
3. Externes Wissen: Die Geschäftslogik (wie die Definition der „Abwanderungsrate“) liegt in der Dokumentation oder in Projektcodebasen (wie DBT), nicht im Schema. Spider 2.0 simuliert dies, indem es externe Dateien (Markdown, YAML) bereitstellt, die das Modell lesen muss, um seine Argumentation zu begründen.
4. Der Agenten-Workflow: Entscheidend ist, dass Spider 2.0 den Arbeitsablauf eines modernen Dateningenieurs modelliert. Es geht über die statische Übersetzung hinaus und bewertet die Fähigkeit des Modells, das Dateisystem zu erkunden, Dokumentation zu lesen, mit Reside-Datenbankinstanzen zu interagieren und Fehler iterativ zu debuggen.

Der Unterschied im Schwierigkeitsgrad ist gewaltig. Bei Modellen, die Spider 1.0 dominieren, sinken die Erfolgsquoten beim vollständigen Spider 2.0-Benchmark auf 10–20 %, was die Mängel aktueller LLMs im Umgang mit der Komplexität der realen Welt verdeutlicht.

Fazit: Die Binärleiste für Unternehmensdaten

Der Weg von Enterprise Intelligence zu KI-gesteuerten Analysen battle von zunehmender Abstraktion geprägt, doch die grundlegende Anforderung an die Datenintegrität bleibt unverändert. Während das Versprechen von Textual content-to-SQL näher denn je ist, müssen wir der Verlockung hoher Punktzahlen bei veralteten Benchmarks widerstehen.

Das Erreichen einer Genauigkeit von 90 % magazine akademisch interessant sein, im Unternehmen ist es jedoch industriell nutzlos. Der Balken ist binär: Es funktioniert oder es bricht das Vertrauen.

Da Plattformen wie BigQuery die Integration von KI und Daten vereinfachen, ist es unerlässlich, dass wir gleichzeitig ausgefeilte Bewertungsmethoden und strenge Benchmarks wie Spider 2.0 übernehmen. Nur durch Checks mit der chaotischen Realität der Unternehmensdaten können wir Textual content-to-SQL-Anwendungen entwickeln, die zuverlässig genug sind, um das Geschäft darauf zu setzen.

Bis zum nächsten Mal hoffe ich, dass Sie dieses Thema genauso faszinierend finden wie ich.

Weiterführende Literatur

Spider 2.0: Evaluierung von Sprachmodellen in realen Textual content-to-SQL-Workflows für Unternehmen Autoren: Fangyu Lei, Jixuan Chen, Yuxiao Ye, et al. Veröffentlicht: arXiv (November 2024), angenommen zum ICLR 2025 (mündlich). Hyperlink: https://arxiv.org/abs/2411.07763

Sicherlich muss dieses Gespräch, wie alles heutzutage mit KI, hier nicht enden. Ich würde gerne Ihre Beiträge und Ihre Sichtweise unter hören www.gyza.org