Korrektes SQL, falsche Kennzahl: Text-to-SQL reicht nicht

Teil 2 von 3 der Serie „KI auf Unternehmensdaten – verlässlich statt plausibel": Teil 1: ChatGPT vs. oneAgent · Teil 2: Korrektes SQL, falsche Kennzahl (dieser Artikel) · Teil 3: Data Warehouse mit KI abfragen

Wenn eine SQL-Abfrage mit einer Fehlermeldung abbricht, ist sofort klar:

Das Ergebnis kann nicht verwendet werden.

Gefährlicher ist eine Abfrage, die technisch einwandfrei läuft, eine plausible Zahl liefert und von der KI überzeugend erklärt wird – obwohl sie fachlich falsch ist.

Genau darin liegt eine der größten Herausforderungen KI-gestützter Datenanalyse.

Sprachmodelle können natürliche Sprache inzwischen erstaunlich gut in SQL übersetzen. In einer Demo mit wenigen verständlich benannten Tabellen sieht das beeindruckend aus.

Reale Unternehmensdaten bestehen jedoch aus historisch gewachsenen Modellen, unterschiedlichen Definitionen und Regeln, die nicht im Spaltennamen stehen.

Deshalb reicht es nicht, wenn eine KI SQL erzeugen kann.

Sie muss wissen, welche fachliche Logik verwendet werden darf.

Das Problem ist nicht nur die SQL-Syntax

Eine Abfrage kann:

• syntaktisch korrekt sein,
• ausschließlich existierende Tabellen nutzen,
• ohne Fehler ausgeführt werden,
• und ein plausibles Ergebnis liefern.

Trotzdem kann sie die falsche Frage beantworten.

Nehmen wir die Frage:

„Wie hoch war unser Umsatz im Mai?"

Eine mögliche Abfrage lautet:

SELECT SUM(total_amount)
FROM orders
WHERE order_date >= '2026-05-01'
  AND order_date < '2026-06-01';

Technisch ist daran zunächst nichts auffällig.

Fachlich bleiben aber viele Fragen offen:

• Ist total_amount brutto oder netto?
• Sind Versandkosten enthalten?
• Zählen stornierte Bestellungen?
• Wie werden Retouren behandelt?
• Ist das Bestell- oder Rechnungsdatum relevant?
• Wie werden Fremdwährungen umgerechnet?

Je nach Antwort kann dieselbe Datenbank unterschiedliche Umsatzzahlen liefern.

Alle Abfragen können technisch korrekt sein.

Warum plausible Fehler so gefährlich sind

Ein offensichtlicher Fehler wird entdeckt.

Eine plausible falsche Zahl kann dagegen direkt weiterverwendet werden:

• in Management-Berichten,
• Budgetentscheidungen,
• Vertriebsplanungen,
• oder Präsentationen.

Das wiederkehrende Problem aus praktischen Text-to-SQL-Projekten ist daher nicht nur die fehlerhafte Abfrage.

Es ist die Abfrage, die erfolgreich läuft und ein überzeugendes, aber falsches Ergebnis liefert. Ein verwandtes Risiko – frei erfundene statt falsch berechnete Zahlen – beschreiben wir in ChatGPT-Halluzinationen bei Geschäftsdaten.

Deshalb empfehlen viele Data Engineers, ein Sprachmodell nicht völlig frei gegen das rohe Datenmodell arbeiten zu lassen.

Stattdessen sollte es auf definierten Kennzahlen, Dimensionen und kontrollierten Berechnungen aufsetzen.

Warum echte Data Warehouses schwieriger sind

Demo-Datenbanken sind häufig klein und verständlich aufgebaut.

Ein reales Data Warehouse enthält dagegen:

• Hunderte Tabellen und Views,
• historisierte Daten,
• alternative Join-Pfade,
• technische Hilfstabellen,
• unterschiedliche Granularitäten,
• uneinheitliche Bezeichnungen,
• und fachliche Sonderregeln.

Ein Sprachmodell muss dort nicht nur SQL-Syntax beherrschen.

Es muss beurteilen:

• welche Tabelle fachlich relevant ist,
• welche Beziehung genutzt werden darf,
• ob ein Join Datensätze vervielfacht,
• und welche Unternehmensdefinition gilt.

Je komplexer und geschäftskritischer die Daten sind, desto weniger darf die Qualität allein von der spontanen Interpretation des Modells abhängen. Wie stark die Trefferquoten von sauberen Benchmarks auf realen Unternehmensdaten einbrechen, zeigen wir mit konkreten Zahlen in Wie zuverlässig ist KI-Datenanalyse?

Kennzahlen sollten nicht neu erfunden werden

Eine Kennzahl wie Nettoumsatz sollte im Unternehmen einmal fachlich definiert werden.

Zum Beispiel:

Nettoumsatz ist der fakturierte Warenwert abzüglich Rabatten, Stornierungen und Retouren, ohne Umsatzsteuer und Versandkosten.

Diese Definition muss anschließend mit den technischen Daten verbunden werden:

• Welche Tabelle enthält Rechnungen?
• Welche Statuswerte gelten?
• Wo stehen Retouren?
• Welche Datumsspalte wird verwendet?
• Welcher Wechselkurs gilt?

Ist diese Logik geprüft, sollte sie bei jeder Frage reproduzierbar angewendet werden.

Das Sprachmodell erkennt die gewünschte Kennzahl. Die freigegebene Logik berechnet sie.

Was ein Metric Layer leistet

Ein Metric Layer verbindet fachliche Begriffe mit technischer Berechnungslogik.

Er definiert beispielsweise:

• welche Kennzahlen verfügbar sind,
• wie sie berechnet werden,
• welche Dimensionen genutzt werden dürfen,
• welche Filter gelten,
• und welche Zeitlogik dazugehört.

Aus der freien Frage

„Wie hoch war unser Umsatz im Mai?"

wird dadurch eine strukturierte Anfrage:

Kennzahl: Nettoumsatz
Zeitraum: Mai 2026
Gruppierung: keine
Filter: freigegebene Unternehmenslogik

Das Modell muss nicht mehr jede Berechnung vollständig neu erzeugen.

Es übersetzt die Frage in bekannte fachliche Bausteine.

Freies Text-to-SQL:

Nutzerfrage
→ Sprachmodell erzeugt SQL
→ Datenbank liefert Ergebnis

Kontrollierter Ansatz:

Nutzerfrage
→ Kennzahl und Dimensionen erkennen
→ geprüfte Logik anwenden
→ kontrollierte Abfrage
→ nachvollziehbares Ergebnis

Das Sprachmodell bleibt wichtig. Es übernimmt aber nicht die Aufgaben, die eindeutig programmatisch gelöst werden können.

Drei korrekte Umsatzzahlen

Angenommen, eine Datenbank enthält Bestellungen, Rechnungen und Retouren.

Die Frage lautet:

„Wie hoch war unser Umsatz im letzten Monat?"

Bestellwert

Alle angelegten Bestellungen werden summiert.

Ergebnis: 1.250.000 Euro

Darin können stornierte oder unbezahlte Bestellungen enthalten sein.

Rechnungswert

Alle erstellten Rechnungen werden summiert.

Ergebnis: 1.080.000 Euro

Darin können Rechnungen für ältere Bestellungen enthalten sein.

Realisierter Nettoumsatz

Fakturierte Nettobeträge werden um Stornierungen und Retouren reduziert.

Ergebnis: 935.000 Euro

Welche Zahl ist richtig?

Das entscheidet nicht die SQL-Syntax.

Es entscheidet die Unternehmensdefinition.

Dokumentation allein reicht nicht

Gut dokumentierte Tabellen und Spalten verbessern die Ergebnisse deutlich.

Trotzdem muss das Modell weiterhin entscheiden:

• welche Definition zur Frage passt,
• welcher Join verwendet werden soll,
• und wie verschiedene Regeln kombiniert werden.

Dokumentation sollte deshalb durch kontrollierbare Strukturen ergänzt werden:

• definierte Kennzahlen,
• zulässige Dimensionen,
• geprüfte Beziehungen,
• Validierungen,
• und gezielte Rückfragen.

Rückfragen sind ein Qualitätsmerkmal

Die Frage

„Welche Kampagne hatte den besten Umsatz?"

kann mehrere Bedeutungen haben:

• First-Touch- oder Last-Touch-Attribution?
• Bruttoumsatz oder Umsatz nach Retouren?
• alle Kunden oder nur Neukunden?
• Umsatz oder Deckungsbeitrag?

Ein System sollte nicht einfach eine Variante auswählen.

Es sollte nachfragen.

Eine Rückfrage kostet wenige Sekunden. Eine falsche Interpretation kann eine Entscheidung verzerren.

Welche Prüfungen zusätzlich notwendig sind

Neben Kennzahlendefinitionen müssen weitere Punkte geprüft werden:

• Existieren Tabellen und Spalten?
• Ist der Join fachlich erlaubt?
• Werden Werte durch den Join mehrfach gezählt?
• Stimmen die Granularitäten überein?
• Werden Benutzerrechte eingehalten?
• Ist das Ergebnis plausibel?

Keine einzelne Prüfung garantiert eine perfekte Antwort.

Zusammen verhindern sie aber, dass zu viele Entscheidungen unkontrolliert beim Sprachmodell liegen.

Was „geprüfte Antwort" bedeutet

„Geprüft" bedeutet nicht, dass jede beliebige Frage immer perfekt beantwortet wird.

Es bedeutet, dass wichtige Bestandteile nicht vollständig der freien Modellinterpretation überlassen werden.

Dazu gehören:

• freigegebene Kennzahlendefinitionen,
• bekannte Tabellen und Spalten,
• kontrollierte Beziehungen,
• strukturierte Filter,
• Berechtigungen,
• und Rückfragen bei Mehrdeutigkeit.

Das Ziel ist nicht, Unsicherheit zu verstecken.

Das Ziel ist, sie zu erkennen und sichtbar zu behandeln.

oneAgent ist mehr als Text-to-SQL

Text-to-SQL beantwortet die Frage:

„Wie übersetzen wir diesen Satz in eine Datenbankabfrage?"

oneAgent beantwortet eine umfassendere Frage:

„Wie übersetzen wir eine Business-Frage in eine nachvollziehbare und fachlich definierte Analyse?"

Dafür muss das System unter anderem klären:

1. Welche Kennzahl ist gemeint?
2. Welche Definition gilt?
3. Welche Filter und Dimensionen sind zulässig?
4. Welche Daten darf der Nutzer sehen?
5. Ist eine Rückfrage notwendig?

SQL ist ein Teil dieses Prozesses.

Es ist nicht der gesamte Prozess. Warum diese Abgrenzung gegenüber allgemeinen KI-Assistenten so wichtig ist, zeigt Teil 1: ChatGPT vs. oneAgent.

Warum das verwendete LLM nicht alles entscheidet

Ein größeres Sprachmodell löst nicht automatisch:

• widersprüchliche KPI-Definitionen,
• unklare Beziehungen,
• doppelte Datensätze,
• fehlende Berechtigungen,
• oder unterschiedliche Granularitäten.

Es kann eine falsche Interpretation lediglich überzeugender formulieren.

Deshalb ist die Architektur des Gesamtsystems wichtiger als nur der Name des Modells.

Vertrauen in BI ist binär

Bei kreativen Aufgaben kann eine Antwort zu 90 Prozent richtig und trotzdem nützlich sein.

Bei Unternehmenskennzahlen ist das anders.

Ein Umsatz von 9,5 Millionen Euro ist nicht fast genauso gut wie der korrekte Umsatz von 10 Millionen Euro.

Eine einzige selbstbewusst präsentierte falsche Zahl kann das Vertrauen in das gesamte System beschädigen.

Deshalb darf ein Data Agent nicht nur überzeugend klingen.

Er muss nachvollziehbar machen, welche Logik verwendet wurde.

Warum wir oneAgent so bauen

Wir möchten die Einfachheit eines Chats mit der Kontrolle klassischer BI verbinden.

Der Nutzer soll kein SQL schreiben und keine Tabellennamen kennen müssen.

Gleichzeitig sollen zentrale Kennzahlen nicht spontan vom Sprachmodell definiert werden.

Unsere Grundidee lautet:

Das Sprachmodell versteht die Frage. Die geprüfte Datenlogik bestimmt die Berechnung.

Wie dieser Ansatz Halluzinationen bei Geschäftsdaten verhindert, zeigen wir auf KI ohne Halluzinationen.

Das ist aufwendiger, als ein Modell direkt auf eine Datenbank loszulassen.

Aber genau darin liegt der Unterschied zwischen einer guten Demo und einer Lösung, der Unternehmen vertrauen können.

Fazit

Die größte Gefahr bei KI-Datenanalyse ist nicht die Abfrage, die fehlschlägt.

Es ist die Abfrage, die erfolgreich läuft, eine plausible Zahl liefert und trotzdem die falsche Unternehmenslogik verwendet.

Deshalb reicht Text-to-SQL allein nicht aus.

Es braucht eine kontrollierte Ebene zwischen Frage und Datenbank:

• geprüfte Kennzahlen,
• definierte Dimensionen,
• kontrollierte Beziehungen,
• Rückfragen,
• und nachvollziehbare Ergebnisse.

Das Sprachmodell darf verstehen, was Sie fragen. Es sollte aber nicht neu erfinden, wie Ihr Unternehmen die Antwort berechnet.

Weiterlesen

Im dritten Teil der Serie zeigen wir, wie oneAgent auf einem vorhandenen Data Warehouse aufsetzt – und warum die bestehende Datenplattform dafür die wichtigste Voraussetzung ist. Weiter zu Teil 3: Data Warehouse mit KI abfragen.