„Daten mit einem Satz abfragen“ klingt einfach, wirft in der Praxis aber viele Fragen auf: uneinheitliche Fachdefinitionen, komplexe Tabellenstrukturen, möglicherweise fehlerhaftes SQL, Berechtigungen, die nicht überschritten werden dürfen, und Ergebnisse, die erklärbar bleiben müssen. Der Kern einer KI-API für Datenanalyse besteht nicht darin, dass das Modell „SQL schreiben kann“, sondern darin, natürlichsprachige Fragen stabil auf vertrauenswürdige Daten und Berichte abzubilden.

Dieser Artikel beschreibt ein Umsetzungskonzept für Unternehmen mit Architektur, Schema-Design, Prompt, Prüfung, Berechtigungen, Genauigkeitstests und Kosten.

Hinweis: Datenbanken, BI-Plattformen und Modellschnittstellen unterscheiden sich. Der Artikel verwendet das verbreitete Muster „schreibgeschützte Datenbank plus OpenAI-kompatible Dialogschnittstelle“; Modelle und Preise entnehmen Sie den Modellpreisen.

1. Gesamtarchitektur

Empfohlen ist eine beobachtbare Kette in mehreren Schritten:

Natürlichsprachige Frage
  → Absichtserkennung (Abfrage / Erklärung / Klärung)
  → Schema-Retrieval (Tabellen, Felder, Kennzahlen, Beispiele)
  → SQL-Generierung
  → Statische Prüfung + Rechte-Injektion
  → Schreibgeschützte Ausführung (Timeout, Zeilenlimit)
  → Ergebnisprüfung
  → Diagrammkonfiguration + Textinterpretation

Zentrale Prinzipien:

  1. Das Modell verbindet sich nicht direkt mit der Produktionsdatenbank, sondern nur mit einem Read-Replica oder Data Warehouse.
  2. Berechtigungen werden serverseitig injiziert und nicht durch Prompt-Anweisungen erzwungen.
  3. Jeder Schritt wird protokolliert: Frage, abgerufene Tabellen, generiertes SQL, Ausführungsdauer, zurückgegebene Zeilen.
  4. Bei Fehlern erhält der Nutzer eine verständliche Erklärung statt der rohen Datenbankmeldung.

2. Schema-Design ist wichtiger als das Modell

Das Modell kennt die unternehmensspezifischen Definitionen von „aktiver Nutzer“ oder „gültiger Bestellung“ nicht. Dieses Wissen muss explizit bereitgestellt werden.

Empfohlen ist eine „Schema-Karte“ pro Tabelle:

Feld Beispielinhalt
Tabellenname dwd_order
Fachliche Bedeutung Bestellpositionen, eine Zeile pro bestelltem Artikel
Primärschlüssel / Granularität order_id + sku_id
Häufige Felder Bestellzeit, Zahlungsbetrag, Bestellstatus, Kanal
Kennzahlendefinition Zahlungsbetrag = tatsächlich gezahlter Betrag, ohne Erstattungen
Verknüpfte Tabellen Nutzer-, Produkt- und Kanaltabelle
Verbot create_time nicht als Zahlungszeit verwenden
Beispielfrage Zahlungsbetrag je Kanal in den letzten 30 Tagen

Zusätzlich vorbereiten:

  • Fachliche Synonyme: GMV, Umsatz und Transaktionsvolumen verweisen auf dieselbe Kennzahl.
  • Kennzahlenlexikon: Definition, Zähler und Nenner, Zeitbezug, Datenverzögerung.
  • Einige Beispiele „Frage → SQL“ für häufige Abfragen.
  • Join-Pfade zwischen Tabellen, damit das Modell Verknüpfungsschlüssel nicht raten muss.

Für das Schema-Retrieval lassen sich Stichwortsuche und Vektorsuche kombinieren, um die fünf bis zehn relevantesten Tabellen und Kennzahlendefinitionen in den Kontext zu legen. Das vollständige Schema ist teuer und stört eher.

3. Prompt formulieren

Der Prompt soll einschränken, nicht zu freier Gestaltung ermutigen. Eine nutzbare Vorlage:

Du bist ein Assistent für Unternehmensdatenanalyse. Übersetze die Nutzerfrage anhand des gegebenen Schemas und der Kennzahlendefinitionen in SQL.
Anforderungen:
1. Erzeuge genau eine SELECT-Anweisung; INSERT/UPDATE/DELETE/DDL sind verboten.
2. Verwende nur die bereitgestellten Tabellen und Felder und erfinde keine Felder.
3. Die Kennzahlendefinition richtet sich nach dem Kennzahlenlexikon und ist in assumptions zu erläutern.
4. Ist der Zeitraum unklar, standardmäßig die letzten 30 Tage verwenden und die Annahme nennen.
5. Bei mehrdeutiger Frage zuerst clarifying_question zurückgeben, nicht raten.
6. Ausgabe als JSON: {"sql": "", "assumptions": [], "clarifying_question": null}

Einige Details:

  • Das Modell soll Annahmen ausgeben, damit Fachbereiche die Definition prüfen können.
  • „Erst klären, dann abfragen“ reduziert Antworten am Thema vorbei deutlich.
  • Für „Vorjahr/Vorperiode/Anteil“ eigene Formeln vorgeben und das Modell nicht frei formulieren lassen.
  • In mehrstufigen Dialogen Kennzahl und Zeitraum der vorherigen Runde behalten, aber kein veraltetes SQL.

4. SQL-Prüfung und Ausführungsleitplanken

Das generierte SQL ist nur der Anfang. Vor der Ausführung sind mindestens fünf Prüfungen nötig:

  1. Syntaxprüfung: Mit einem SQL-Parser analysieren und mehrere Anweisungen ablehnen.
  2. Anweisungstyp: Nur SELECT zulassen, Schreiboperationen und Stored Procedures verbieten.
  3. Objekt-Whitelist: Tabellen und Felder müssen in der freigegebenen Liste stehen.
  4. Rechte-Injektion: Filter für Mandant, Abteilung und Region automatisch ergänzen.
  5. Kostenkontrolle: Zeitraum, LIMIT, Timeout und maximale Scanmenge setzen.

Die Ausführungsschicht sollte ein separates Read-only-Konto auf einem Replica verwenden und Folgendes setzen:

  • Abfrage-Timeout, beispielsweise 30 Sekunden.
  • Maximale Rückgabezahl, beispielsweise 1000 Zeilen.
  • Bei großen Tabellen zuerst EXPLAIN ausführen und die Scanmenge schätzen.
  • Höchstens ein bis zwei Wiederholungen; die Datenbankmeldung zur Korrektur an das Modell zurückgeben.
  • Gleiche Fragen cachen; der Cache-Schlüssel enthält den Berechtigungsumfang des Nutzers.

5. Berechtigungen: Das Modell ersetzt kein Rechtssystem

Der häufigste Vorfall bei Datenfragen ist, dass Nutzer Daten sehen, die sie nicht sehen dürfen. Richtig ist die Wiederverwendung des Berechtigungsmodells von BI oder Data Warehouse:

  • Datensatzebene: Auf welche Tabellen darf der Nutzer zugreifen?
  • Zeilenebene: Filter nach Mandant, Abteilung, Region.
  • Spaltenebene: Telefonnummern, Ausweisnummern und Einkaufspreise maskieren oder ausblenden.
  • Kennzahlenebene: Sensible Kennzahlen separat freigeben.
  • Sitzungsebene: Bei Nutzerwechsel Kontext und Cache leeren.

Das Modell erzeugt nur die Abfrageabsicht; die Berechtigung wird serverseitig in der SQL-Außenschicht oder View-Schicht erzwungen. Protokolle enthalten Originalfrage, endgültiges SQL, Ausführenden und Zeilenzahl für Audits. Exportfunktionen separat freigeben, damit nicht „wer abfragen darf, auch alles herunterladen kann“.

6. Vom Ergebnis zum Diagramm

Ein Abfrageergebnis ist noch kein Bericht. Lassen Sie das Modell eine „Diagrammkonfiguration plus Textfazit“ ausgeben, nicht direkt ein Bild:

Datenform Empfohlenes Diagramm
Zeitreihe Liniendiagramm
Kategorienvergleich Balkendiagramm
Anteile Kreis- oder gestapeltes Balkendiagramm
Korrelation Streudiagramm
Einzelkennzahl Kennzahlenkarte

Das Textfazit sollte Definition, Zeitraum, zentrale Zahlen und Auffälligkeiten enthalten, etwa „Der Zahlungsbetrag ist in den letzten 30 Tagen um 8 Prozent gesunken, vor allem im Kanal Ostchina“, mit verlinkbaren Details. Ein Satz wie „Die Daten entwickeln sich gut“ genügt nicht.

7. Genauigkeit messen

Bereiten Sie 100 bis 300 echte Geschäftsfragen vor, nach Schwierigkeit gestuft:

  • EinzelTabellen-Abfragen und Aggregationen.
  • Joins über mehrere Tabellen.
  • Vorjahr, Vorperiode, Anteile.
  • Mehrdeutige Fragen, die eine Klärung erfordern.
  • Fragen ohne Daten oder ohne Berechtigung.

Die Evaluation vergleicht nicht die Ähnlichkeit des SQL, sondern die Übereinstimmung der Ausführungsergebnisse. Empfohlene Kennzahlen:

Metrik Erläuterung
Ausführungsgenauigkeit Ergebnis stimmt mit manueller Referenz überein
Klärungsquote Werden mehrdeutige Fragen korrekt zurückgespielt?
Blockquote bei Rechteverstößen Werden unberechtigte Anfragen abgelehnt?
Erklärbarkeit von Fehlern Werden Fehler in verständliche Sprache übersetzt?
Durchschnittliche Latenz Von der Frage bis zum Diagramm

Wöchentlich eine Regression ausführen; nach Modell- oder Schemaänderungen zwingend erneut. In der Anfangsphase den Modus „SQL manuell bestätigen“ beibehalten und erst nach Stabilisierung automatisch ausführen.

8. Kosten und Performance

Die Kosten der Datenanalyse-KI entstehen vor allem aus drei Teilen: Schema-Retrieval, SQL-Generierung und Ergebnisinterpretation.

  • Vektorsuche reduziert den Kontext auf relevante Tabellen.
  • Absichtserkennung und einfache Abfragen mit kleinen Modellen, komplexe Abfragen mit starken Modellen.
  • Häufige Fragen und gleiche Berechtigungsumfänge cachen.
  • Für die Interpretation nur aggregierte Daten übergeben, nicht alle Details.
  • Lange Tabellenstrukturen zusammenfassen, statt jedes Mal das vollständige DDL zu senden.

Kalkulationsformel:

Kosten pro Anfrage =
  Schema-Kontext-Token × Eingabepreis
+ Ausgabe-Token für SQL × Ausgabepreis
+ Token für Ergebnisinterpretation × Preis
+ Datenbank-Ausführungskosten

Konkrete Preise entnehmen Sie den Modellpreisen; Datenbankkosten sind separat zu berechnen, insbesondere bei großen Tabellenscans.

9. Häufige Fehler und Behandlung

Symptom Häufige Ursache Behandlung
Feld existiert nicht Schema nicht abgerufen oder Modell hat es erfunden Whitelist-Prüfung + Fehlermeldung zurückspielen und wiederholen
Uneinheitliche Definition Kennzahlendefinition fehlt Kennzahlenlexikon ergänzen, Annahmen ausgeben lassen
Join vervielfacht Zeilen Falscher Verknüpfungsschlüssel oder Granularität Join-Pfade bereitstellen, Zeilenzahl prüfen
Falscher Zeitraum Zeitzone oder Standardwert unklar Zeitzone vereinheitlichen, Standardzeitraum festlegen
Rechteüberschreitung Nur Prompt als Einschränkung Serverseitig Filter erzwingen
Antwort am Thema vorbei Frage mehrdeutig Erst klären, dann abfragen

Häufige Fragen

Ersetzt Datenanalyse-KI BI?

Nein. Sie eignet sich für Ad-hoc-Fragen, schnelle Datenabrufe und die Erklärung von Berichten; komplexe Standardberichte gehören weiterhin in BI.

Muss die gesamte Datenbankstruktur an das Modell übergeben werden?

Nein. Schema-Retrieval übergibt nur relevante Tabellen und Kennzahlen. Das spart Kosten und reduziert Fehlverwendungen.

Kann generiertes SQL direkt ausgeführt werden?

Nicht empfohlen. Es muss Syntax-, Whitelist-, Rechte- und Kostenprüfung durchlaufen und auf einem Read-Replica ausgeführt werden.

Welche Genauigkeit ist erreichbar?

Das hängt von Schemaqualität, Frageschwierigkeit und Evaluationskriterien ab. Zuerst mit echten Fragen eine Basis ermitteln und wöchentlich verbessern; Demonstrationsfragen sind nicht repräsentativ.

Wie beginnt ein kleines Team?

Zuerst eine Domäne wählen, etwa Vertrieb oder Betrieb, 10 bis 20 Tabellen und ein Kennzahlenlexikon zusammenstellen, ein Evaluationsset mit 50 Fragen aufbauen und dann über die Erweiterung entscheiden.

Nächste Schritte

Der Erfolg von Datenanalyse-KI hängt zu etwa 80 Prozent von Schema, Kennzahlendefinitionen und Berechtigungsdesign ab, nicht von Modellparametern. Beginnen Sie mit einem POC in einer Domäne und schließen Sie den Kreis „Frage, Prüfung, Ausführung, Diagramm, Erklärung“, bevor Sie erweitern. Für einen einheitlichen Modelleinstieg und Verbrauchsverwaltung können Sie sich im ZSQH AI Gateway registrieren; Modelle und Preise entnehmen Sie den Modellpreisen.

Weiterlesen: