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.
94%
Ergebnisgenauigkeit
Gemessen über vier Datenbank-Engines (PostgreSQL, SQL Server, MySQL, Oracle) an einem Testset mit Hunderten echter Fragen. Der Wert misst, ob die zurückgegebenen Daten der Referenzantwort entsprechen — nicht die Ähnlichkeit des SQL-Textes: Selbst eine fehlerfrei laufende Abfrage zählt als Fehlschlag, wenn die Daten falsch sind.
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, undokumentierte 'schlechte' Schemata — denn so sieht die reale Welt aus.
- 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. Enterprise-Teams, die Methodik und Testset prüfen möchten, geben wir gerne Einblick.
Häufige Fragen
Was bedeuten 94 Prozent genau?
94 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. Reihen Sie sich in die Beta-Warteschlange ein und stellen Sie Ihre erste Frage an Ihre eigene Datenbank.