Kern•6–10 Stunden

Labor für KI-Metrikabgleich

Validiere KI-generiertes SQL und Metriken mit semantischem Vertrag, deterministischen Kontrollen, autoritativem Abgleich und Regression Cases, bevor eine Zahl in Dashboard oder Entscheidung gelangt.

MetrikverträgeSQL-ValidierungDatenabgleichFehleranalyseRegressionstests

Szenario

Aufgabe

KI hat SQL für einen zentralen KPI erzeugt, aber das Dashboard zeigt einen anderen Wert. Die Query läuft fehlerfrei, doch das beweist nichts: Ursache können Grain, Zeitzone, Join-Kardinalität, Filter, verspätete Daten oder die Business-Definition selbst sein. Baue einen Prüfpfad, der syntaktischen Erfolg von semantischer Korrektheit trennt und einen reproduzierbaren Evidence Trail hinterlässt.

Schrittweise Umsetzung

1. Semantik vor der SQL-Generierung einfrieren

Ergebnis: Die KI erhält einen expliziten Metrikvertrag und errät keine Business-Regeln aus Spaltennamen.

Aufgaben

→Grain und Analyseeinheit dokumentieren
→Zähler, Nenner, Filter und Ausschlüsse fixieren
→Zeitzone, Period Close und Freshness Rule definieren
→Autoritative Tabelle oder Report und Owner benennen

Prüfungen

✓Eine Metrik hat genau einen versionierten Vertrag
✓Unklare Business-Regeln werden als offene Fragen markiert
✓Die KI darf Policy-Ambiguität nicht selbst auflösen

2. Generiertes SQL als Candidate Artifact behandeln

Ergebnis: Erfolgreiche Ausführung kann keinen logischen Fehler mehr verdecken.

Aufgaben

→Prompt, Kontext und exakte Query speichern
→Schema und referenzierte Felder prüfen
→Row-Count-, Null- und Duplicate-Checks hinzufügen
→Join Keys und One-to-many- oder Many-to-many-Fan-out prüfen

Prüfungen

✓Query Success ist kein Acceptance Criterion
✓Unbekannte Felder oder implizite Casts führen zu explizitem Failure
✓Join-Kardinalität wird getrennt von Totals geprüft

3. Autoritativen Abgleich durchführen

Ergebnis: Die Schlüsselzahl wird unabhängig reproduziert und jede Abweichung erklärt.

Aufgaben

→KPI mit autoritativem Report oder Source vergleichen
→Totals über unabhängige Query oder Formel neu berechnen
→Edge Segments und Boundary Dates prüfen
→Tolerance nur mit fachlicher Begründung verwenden

Prüfungen

✓Mismatch wird nie zu PASS gerundet
✓Tolerance hat Owner und Begründung
✓Jede Abweichung wird Definition, Daten, Query oder Source State zugeordnet

4. Fehler in eine Regression Suite überführen

Ergebnis: Spätere SQL-, Schema- oder Modelländerungen bringen bekannte Fehler nicht unbemerkt zurück.

Aufgaben

→Wrong Join, stale Partition, Zeitzonenverschiebung, fehlenden Filter und Duplikate simulieren
→Erwartetes deterministisches Signal dokumentieren
→Severity und Release Action zuweisen
→Dataset-, Query- und Contract-Fingerprint versionieren

Prüfungen

✓Kritischer Reconciliation Failure blockiert Publication
✓Regression Cases laufen ohne LLM Judge
✓Änderungen am Metrikvertrag starten Baseline-Verifikation neu

Akzeptanzkriterien

Der Metrikvertrag enthält Grain, Definitionen, Filter, Zeitsemantik, Freshness und autoritative Quelle
Generiertes SQL ist mit Annahmen als versioniertes Candidate Artifact gespeichert
Join-Kardinalität, Duplikate, Nullwerte, Totals und Edge Segments besitzen deterministische Checks
Der Schlüssel-KPI ist unabhängig abgeglichen oder hat eine explizite offene Abweichung
Mindestens fünf Failure Cases werden permanente Regression Tests