Schema-Annotationsschicht
Kryptische Spalten und codierte Werte (z. B. 1=Kunde, 2=Lieferant) werden erkannt, Ihnen vorgeschlagen und nach Ihrer Freigabe dem Modell beigebracht. Bei Legacy-Schemata ist das der wichtigste Treiber der Genauigkeit.
GENAUIGKEIT & METHODIK
Wir behaupten Genauigkeit nicht. Wir messen sie.
Eine generierte Abfrage ist nicht richtig, nur weil sie läuft. Unsere Tests vergleichen die DATEN, die eine Abfrage zurückgibt, mit einer Referenzantwort — eine fehlerfrei laufende Abfrage mit falscher Antwort zählt als Fehlschlag.
638/661
97%
Ergebnisgenauigkeit — vollständiger Goldstandard-Satz
661 echte Fragen auf vier Datenbank-Engines (PostgreSQL, SQL Server, MySQL, Oracle), ausgeführt über den Produktionspfad des Produkts (3. September 2026). Bewertet wird nicht die Ähnlichkeit des SQL-Textes, sondern ob die zurückgegebenen Daten mit der Referenzantwort übereinstimmen: Eine fehlerfrei laufende Abfrage mit falschen Daten gilt als Fehler. Der Satz enthält bewusst kryptische Altsystem-Schemata.
Eine Verteilung statt einer einzelnen Zahl
Eine aggregierte Quote ist eine Behauptung; eine Verteilung ist ein Beleg. Unten die Segmente desselben Laufs. Wir zeigen auch die Nenner, denn eine hohe Quote auf kleiner Stichprobe sagt wenig aus.
| Segment | Korrekt / Fragen |
|---|---|
| NACH DATENBANK-ENGINE | |
| PostgreSQL | 22/22 |
| SQL Server | 92/93 |
| MySQL | 266/276 |
| Oracle | 258/270 |
| NACH FRAGETYP | |
| Einstufige Fragen | 187/188 |
| Mehrstufige analytische Fragen | 451/473 |
| NACH SCHEMATYP | |
| Aussagekräftig benanntes Schema | 506/528 |
| Kryptisches Schema, Annotationsebene aktiv | 132/133 |
Zwei Hinweise. Die kryptischen Sätze in der Schemazeile werden mit aktiver Annotationsebene gemessen. Das Ergebnis bedeutet also nicht „kryptische Schemata sind einfacher“, sondern dass die Annotationsebene den Unterschied schließt. Ohne Annotationen sinkt die Quote. Zweitens hat das PostgreSQL-Segment einen kleinen Nenner (22 Fragen); diese Zeile nicht mit gleichem Gewicht lesen wie die übrigen.
Wie wir messen
Wir verwenden ein Testset mit Hunderten türkischer Fragen über realistische Schemata aus verschiedenen Geschäftsbereichen (Vertrieb, Gesundheitswesen, Fertigung, Legacy-ERP) und führen es über vier Datenbank-Engines aus. Ein Teil des Sets nutzt bewusst kryptische 'schlechte' Schemata voller codierter Spalten, denn so sieht die reale Welt aus. Diese Schemata werden mit aktiver Annotationsebene gemessen: Gemessen wird also eine Installation, in der ein Operator die Spaltenbedeutungen eingetragen hat.
- 01Für jede Frage generiert die Produktions-Pipeline von PerSight eine SQL-Abfrage — es gibt keine Abkürzung für Tests.
- 02Die generierte Abfrage und eine handgeschriebene Referenzabfrage werden jeweils gegen eine echte Testdatenbank ausgeführt.
- 03Die von beiden zurückgegebenen Daten werden verglichen: Die Frage gilt nur als bestanden, wenn Zeilen und Werte übereinstimmen. Eine laufende Abfrage mit falschen Daten fällt durch.
- 04Bewusst unbeantwortbare Fragen sind Teil des Sets: Statt eine Abfrage zu erfinden, muss das Modell ehrlich 'Ich kann das nicht beantworten' sagen — Erfinden zählt als Fehlschlag.
Vier Schichten gegen das Falsche-Ergebnis-Problem
Der heimtückischste Fehler von Abfragewerkzeugen mit natürlicher Sprache ist die Abfrage, die sauber läuft, aber die falsche Antwort liefert. Die Hauptursache ist nicht das Sprachverständnis — es ist die Fehlinterpretation des Schemas. PerSight begegnet dem mit vier Schichten:
Beziehungsdisziplin
Tabellen werden nur über im Schema definierte Beziehungen verknüpft; spekulative Verknüpfungen auf Basis von Namensähnlichkeit werden durch Regeln blockiert.
Selbstreparierende Abfragen
Eine zur Laufzeit fehlschlagende Abfrage wird zusammen mit der Fehlermeldung an das Modell zurückgegeben und einmal repariert — die meisten transienten Fehler erreichen den Nutzer nie.
Ehrliche Ablehnung
Kann eine Frage aus Ihrem Schema nicht beantwortet werden, sagt PerSight, was fehlt, statt eine plausibel wirkende Abfrage zu erfinden. Ein ehrliches 'Ich kann das nicht beantworten' schlägt eine falsche Antwort.
Eine ehrliche Anmerkung
Dieser Wert wurde auf unserem eigenen Testset gemessen; er ist kein unabhängiger Benchmark. Die reale Genauigkeit hängt von der Qualität Ihres Schemas und der Nutzung der Annotationsschicht ab. In unserer eigenen Messung entsteht der Schwierigkeitsunterschied inzwischen weniger durch die Sauberkeit des Schemas als durch die Komplexität der Frage: mehrstufige analytische Fragen sind deutlich schwerer als einstufige. Enterprise-Teams, die Methodik und Testset prüfen möchten, geben wir gerne Einblick.
Häufige Fragen
Was bedeuten 97 Prozent genau?
97 Prozent der generierten Abfragen lieferten exakt dieselben Daten wie die Referenzantwort. Das Kriterium ist Ergebnisgleichheit: Selbst eine fehlerfrei laufende Abfrage zählt als Fehlschlag, wenn die Daten falsch sind.
Warum nicht 100 Prozent?
Die verbleibenden Fragen scheitern überwiegend an den schwierigsten analytischen Szenarien und an bewusst kryptisch gehaltenen Schemata. Unser Kriterium ist streng: Jede laufende Abfrage mit falschen Daten ist ein Fehlschlag. Wir messen Fortschritt, indem wir das Set härter machen — nicht, indem wir den Wert aufblähen.
Gilt das auch für mein Schema?
Das hängt von der Qualität Ihres Schemas ab. Bei Schemata mit sprechenden Tabellen- und Spaltennamen kann die Quote über unserem Testwert liegen; bei kryptischen Schemata steigt sie deutlich, sobald Sie die Annotationsschicht freigeben. Unsere Tests messen beide Arten.
Wie würde ich ein falsches Ergebnis bemerken?
Das generierte SQL ist immer auf dem Bildschirm sichtbar und wird verständlich erklärt; Sie können es vor der Ausführung bearbeiten und freigeben. Kann eine Frage aus Ihrem Schema nicht beantwortet werden, sagt PerSight das offen, statt eine Abfrage zu erfinden. Und jede Abfrage ist schreibgeschützt — selbst eine falsche kann Ihre Daten nicht anfassen.
Testen Sie es mit Ihren eigenen Daten
Der beste Test ist Ihr eigenes Schema. Erstellen Sie ein kostenloses Konto und stellen Sie Ihre erste Frage an Ihre eigene Datenbank.