Weil natürliche Sprache mehrdeutig ist und echte Schemata unordentlich sind. Auch die besten Systeme erreichen auf akademischen Benchmarks keine 100 %. Behauptet ein Tool 100 %, fragen Sie nach der Methode; vermutlich zählt es Textähnlichkeit.

Sieht das Modell die Testfragen vorab?

Nein. Die Fragen laufen über denselben Weg wie in Produktion: Das Modell sieht Frage und Schema zum ersten Mal, das erzeugte SQL läuft, das Ergebnis wird verglichen.

Welche Genauigkeit erwartet mich auf meinem eigenen Schema?

Mit sprechenden Namen verhält es sich wie die typischen Geschäftssuiten (94 %+); voller kryptischer Abkürzungen wie die Legacy-Suiten (60 bis 80 %). Die gute Nachricht: Spaltenbeschreibungen bewegen Sie von der zweiten Gruppe in Richtung der ersten.

Wie oft messen Sie neu?

Das volle Set läuft neu, sobald sich Modell oder Erzeugungsweg ändern. Die aktuelle Zusammenfassung steht immer auf der Genauigkeitsseite; die Zahlen in diesem Artikel stammen aus dem Lauf vom Juli 2026.

← Alle BeiträgeDas PerSight-Team · Zuletzt aktualisiert: 25. Juli 2026 · 7 Min. Lesezeit

Wie misst man die Genauigkeit von Text-to-SQL? Unsere Zahlen, Fehler inklusive

Wie Text-to-SQL-Genauigkeit gemessen werden sollte und warum eine "richtig aussehende" Abfrage nicht reicht. Die Methode hinter unserem Testset mit 661 Fragen, Ergebnisse pro Suite und unsere häufigsten Fehler.

Wenn auf einer Text-to-SQL-Produktseite "97 % Genauigkeit" steht, lautet die erste Frage: Was haben Sie gezählt? In diesem Feld werden zwei sehr verschiedene Dinge als "korrekt" gemessen, und der Abstand dazwischen ist der Abstand zwischen einer Entscheidung auf richtiger und auf falscher Zahl.

Warum eine "richtig aussehende" Abfrage nicht reicht

Die billige Methode vergleicht den erzeugten SQL-Text mit einem Referenz-SQL. Aber Dutzende verschiedene Abfragen können dieselbe Frage korrekt beantworten, und eine Abfrage, die der Referenz stark ähnelt, kann wegen eines einzigen Wortes falsche Daten liefern. Die Abfrage läuft, eine Zahl kommt zurück, die Zahl ist falsch, eine Fehlermeldung gibt es nicht. Deshalb schauen wir gar nicht auf den Text.

Unsere Methode: das Ergebnis zählt, nicht der Text

Jede Testfrage hat eine handgeschriebene Referenzabfrage mit bekannter Korrektheit.
Die vom Modell erzeugte Abfrage läuft tatsächlich auf einer Live-Datenbank.
Die zurückgegebenen Daten werden Zeile für Zeile mit dem Referenzergebnis verglichen. Andere Spaltenreihenfolge mit richtigen Werten besteht; zusätzliche Kontextspalten bestehen, solange die verlangten Werte enthalten sind.
Das Set enthält bewusst unbeantwortbare Fragen: Hat eine Frage keine Antwort in den Daten, testen wir, ob das Modell das sagt, statt SQL zu erfinden.

Aktuelle Ergebnisse, ungefiltert

Der letzte vollständige Lauf umfasste 661 echte Fragen über vier Engines (PostgreSQL, SQL Server, MySQL, Oracle) und Schemata aus verschiedenen Domänen: Vertrieb, Krankenhaus, HR, Universität. Das Gesamtergebnis: 593 von 661, also 90 %. Auf typischen Geschäftsschemata, also solchen mit sprechenden Tabellen- und Spaltennamen, liegen die Suiten zwischen 94 % und 100 %; die 94 % auf unserer Website fassen diese Klasse zusammen.

Wohin verschwindet der Rest? In absichtlich erschwerte "Legacy"-Suiten: alte Schemata voller kryptischer Abkürzungen ohne Beschreibungen. Dort fällt das Ergebnis in das Band von 60 bis 80 %. Wir verstecken das nicht, denn genau hier liegt die nützlichste praktische Lehre: Die wichtigste Variable der Text-to-SQL-Genauigkeit ist nicht das Modell, sondern die Lesbarkeit Ihres Schemas. Beschreibungen an kryptischen Spalten sind der wirksamste einzelne Hebel.

Welche Fehler passieren am häufigsten?

Zusätzliche Zeilen: Ein Join vervielfacht mehr Zeilen als erwartet, etwa 6 statt der 5 der Referenz. Der Ergebnisvergleich fängt das sofort.
Falsche Spaltenwahl: von zwei ähnlich benannten Spalten die falsche nutzen. Der Klassiker kryptischer Schemata.
Andere Lesart einer mehrdeutigen Frage: "die vollste Station" über eine andere Metrik interpretieren. Technisch vertretbar, aber anders als die Referenz; wir zählen es trotzdem als Fehler.

Keine dieser Fehlerklassen kann Daten beschädigen, denn die Erzeugung ist schreibgeschützt; das Risiko ist falsche Information. Das Gegenmittel ist die Messung selbst plus eine stets sichtbare Abfrage: Sie sehen, worauf Sie schauen, bevor Sie der Zahl vertrauen.

Häufig gestellte Fragen

Warum nicht 100 %?: Weil natürliche Sprache mehrdeutig ist und echte Schemata unordentlich sind. Auch die besten Systeme erreichen auf akademischen Benchmarks keine 100 %. Behauptet ein Tool 100 %, fragen Sie nach der Methode; vermutlich zählt es Textähnlichkeit.
Sieht das Modell die Testfragen vorab?: Nein. Die Fragen laufen über denselben Weg wie in Produktion: Das Modell sieht Frage und Schema zum ersten Mal, das erzeugte SQL läuft, das Ergebnis wird verglichen.
Welche Genauigkeit erwartet mich auf meinem eigenen Schema?: Mit sprechenden Namen verhält es sich wie die typischen Geschäftssuiten (94 %+); voller kryptischer Abkürzungen wie die Legacy-Suiten (60 bis 80 %). Die gute Nachricht: Spaltenbeschreibungen bewegen Sie von der zweiten Gruppe in Richtung der ersten.
Wie oft messen Sie neu?: Das volle Set läuft neu, sobald sich Modell oder Erzeugungsweg ändern. Die aktuelle Zusammenfassung steht immer auf der Genauigkeitsseite; die Zahlen in diesem Artikel stammen aus dem Lauf vom Juli 2026.

Die Kurzfassung der Methode und der aktuelle Wert stehen auf persight.ai/de/genauigkeit. Der gesündeste Test ist das Verhalten auf Ihren eigenen Daten; die Beta-Warteschlange finden Sie unter persight.ai/beta.