Sieben Fragen entscheiden, ob Ihr KI-Projekt scheitert

In unseren Mid-Cap-Implementations-Gesprächen taucht ein Befund mit ermüdender Regelmäßigkeit auf: KI-Pilots scheitern nicht am Modell. Sie scheitern an der Datenqualität, die niemand vorher auditiert hat. Die Diskussion landet dann beim Anbieter, beim Feature-Engineering oder beim Hyperparameter-Tuning - selten dort, wo der Fehler tatsächlich liegt.

Wir wollten ein Werkzeug haben, das ein Datensatz in zehn Minuten gegen die sieben Dimensionen prüft, die unserer Erfahrung nach über Erfolg oder Misserfolg eines KI-Vorhabens entscheiden. Wir haben es gebaut und veröffentlichen es heute. Dieser Artikel beschreibt die sieben Dimensionen, die methodische Grundlage und die Befunde aus einem ersten Test gegen einen synthetischen Datensatz mit bekannten Mängeln.

1 · Die sieben Dimensionen

Jede Dimension misst einen anderen Aspekt der Datenqualität und produziert eine Ampel-Bewertung (Grün, Gelb, Rot) plus einen numerischen Wert.

Drei davon (5, 6, 7) sind optional und werden nur ausgewertet, wenn der Audit-Aufruf die nötigen Informationen mitgibt (Zeit-Spalte, Foreign-Key-Spezifikation, Split-Definition).

2 · Das Tool

Installation und Ausführung in zwei Minuten:

git clone https://github.com/myBytesResearch/data-quality-audit.git
cd data-quality-audit
pip install -e .

# Erst eine Kopie machen! Niemals auf Produktionsdaten direkt.
cp /pfad/zur/produktion.csv /tmp/audit_kopie.csv

dqa audit /tmp/audit_kopie.csv \
    --report mein_report.md \
    --json scorecard.json

Das Tool gibt einen Markdown-Report mit allen sieben Dimensionen plus eine JSON-Scorecard für nachgelagerte Automation aus. Die CLI druckt vor jedem Datenlese-Vorgang eine Sicherheits-Warnung und verlangt eine ausdrückliche Bestätigung, wenn der Pfad nicht sichtbar als Sample oder Kopie markiert ist (--sample oder --copy).

Technische Garantien des Werkzeugs:

• Die Eingabedatei wird ausschließlich im Lesemodus geöffnet.
• Keine Netzwerk-Aufrufe zur Laufzeit. Keine Telemetrie. Keine externen Pfade.
• Keine automatische Daten-Reparatur. Das Werkzeug diagnostiziert, es repariert nicht. Reparatur ist eine bewusste Entscheidung im Daten-Engineering-Workflow.

Der vollständige Code, die sieben Dimensions-Module, die Tests und ein synthetischer Datensatz mit bekannten Mängeln liegen im Companion-Repository data-quality-audit.

3 · Test gegen einen synthetischen Datensatz

Wir haben einen synthetischen Datensatz mit fünf bewusst eingeschleusten Mängeln gebaut und das Werkzeug darauf angewendet. Die Mängel:

1. email-Spalte mit 40 % Missing-Anteil
2. phone-Spalte mit 20 % Missing-Anteil
3. Eine mixed_col mit gemischten Python-Typen (Strings und Integer)
4. 50 duplizierte Zeilen
5. Drei extreme Ausreißer in amount (1·10⁹ und −1·10⁶)

Das Werkzeug hat die ersten vier vollständig erkannt und korrekt bewertet. Beim fünften Mangel (gemischte Typen) zeigte sich eine interessante Limitation: Beim Laden aus CSV werden alle Werte zunächst als Strings interpretiert, sodass die gemischten Typen in der Zeilen-Granularität verloren gehen. Das Werkzeug erkennt diesen Fall bei Parquet-Eingaben sauber; bei CSV wird er erst im nachgelagerten Lade-Schritt sichtbar. Diese Limitation steht explizit im Companion-Repository und im Limitations-Abschnitt weiter unten.

Auszug aus dem generierten Report:

**Overall verdict:** 🟡 YELLOW
**Reason:** Yellow on: completeness, schema_consistency,
uniqueness, value_plausibility

## Dimension 1 · Completeness
🟡 YELLOW - Overall missing share: 6.6 %. Worst column: `email`
at 40.4 % missing.

## Dimension 4 · Value plausibility
🟡 YELLOW - `amount`: 407 Tukey-Ausreißer, 1 |z| > 5σ
(Wertebereich −1 Mio … 1 Mrd).

Die Ampel-Auswertung pro Dimension plus der gewichtete Gesamt-Verdikt sind der eine Output, den ein Head of Data im Stand-up zeigen kann, ohne Erklärung anhängen zu müssen.

4 · Drei reale Audits, drei lehrreiche Befunde

Wir haben das Werkzeug auf drei öffentliche Datensätze angewendet - jeden in seiner unveränderten Originalfassung, ohne Vorab-Reinigung. Die Ergebnisse stehen in den audit-reports/ des Companion-Repositories zur eigenständigen Nachprüfung.

4.1 UCI Adult Income (32 561 Zeilen) - 🔴 Rot

Klassischer Klassifikations-Benchmark, häufig in Lehrveranstaltungen verwendet.

Der fnlwgt-Befund ist methodisch interessant: das ist ein Sampling-Weight aus dem Census-Design, kein echtes Beobachtungs-Feature. Statistisch zeigt es heavy-tail-Charakter; fachlich ist es legitim. Dieser Fall ist ein Lehrbeispiel dafür, warum eine Werkzeug-Diagnose immer durch Domänen-Kenntnis interpretiert werden muss.

4.2 Titanic (891 Zeilen) - 🔴 Rot

Der notorische Einführungs-Datensatz für ML-Tutorials.

Der Cabin-Befund (77,1 % missing) ist seit Jahren in jedem Kaggle-Notebook zu Titanic präsent. Das Werkzeug findet ihn in zehn Sekunden, ohne dass jemand vorher gewusst haben muss, dass es ihn gibt. Genau das ist der operative Wert: nicht das Erinnern, sondern das systematische Finden.

4.3 Apple-Daily-Prices, 25 Jahre (6 288 Zeilen) - 🔴 Rot

Yahoo Finance, AAPL 2000-01-01 bis 2024-12-31.

Der Date-als-String-Befund ist die häufigste Ursache für still scheiternde Time-Series-Splits, die wir im Mid-Cap-Implementations-Alltag sehen.

Die 168 zeitlichen Lücken sind methodisch keine Daten-Mängel - es sind Wochenenden und US-Börsen-Feiertage. Das Werkzeug detektiert sie korrekt; die fachliche Interpretation („das ist normal für Aktien-Tageskurse") liegt beim Domänen-Experten. Der Befund ist trotzdem operativ wertvoll: ein Time-Series-Modell-Architekt, der mit diesem Datensatz arbeitet, muss die Geschäftstage-Mechanik explizit einbauen, sonst kommt sie als Bug zurück.

4b · Drei übergreifende Lektionen aus den Audits

Die drei Datensätze sind sehr unterschiedlich, und doch zeigt sich ein gemeinsames Muster:

1. Value-Plausibilität ist die am häufigsten rot leuchtende Dimension. Heavy Tails sind in realen Daten so verbreitet, dass das Werkzeug fast immer hier Alarm schlägt. Der nächste notwendige Schritt ist immer ein menschlicher: ist der Outlier ein Sensor-Fehler, eine Einheitenverwechslung oder ein echtes seltenes Ereignis?
2. Schema-Drift auf Datums-Spalten ist quer durch die drei Datensätze unauffällig zu Beginn und wird zum Drama im Time-Series-Split. AAPL ist das Schulbeispiel.
3. Vollständigkeit kann falsch grün sein, wenn der CSV-Loader die Sentinel-Werte nicht erkennt. Das UCI-Adult-Beispiel ist instruktiv: ohne na_values='?' wäre Workclass zu 100 % befüllt; in Wirklichkeit fehlen 5,6 % der Werte. Eine methodisch ehrliche Datenqualitäts-Auswertung verlangt eine bewusste Konfiguration der Sentinel-Werte vor der Auswertung.

5 · Wie Sie es als Discovery-Trigger verwenden

Das Werkzeug ist bewusst auch ein Eintritts-Punkt zu einem Gespräch mit uns. Konkret:

1. Erstellen Sie eine Kopie eines Datensatzes, mit dem Sie arbeiten oder den Sie für ein KI-Projekt vorbereiten.
2. Lassen Sie dqa audit darüber laufen.
3. Wenn die Scorecard drei oder mehr Dimensionen Gelb oder Rot zeigt, oder wenn die Befunde Sie überraschen, sprechen Sie uns an. Wir lesen Ihre Scorecard (gerne anonymisiert) in den nächsten 48 Stunden und melden uns mit einer Einschätzung, die Sie zu Ihrer Daten-Strategie sortieren können.

Drei Wege, uns zu erreichen:

• Strukturiert über unseren Pre-Meeting-Fragebogen. Sie beschreiben Ihre Ausgangssituation in zehn Minuten, wir bereiten uns gezielt auf das Gespräch vor. Das ist der effektivste Weg, wenn Sie ein konkretes KI- oder Datenqualitäts-Vorhaben in Vorbereitung haben.
• Per E-Mail an contact@mybytes.com. Schicken Sie uns die Scorecard und ein paar Sätze zum Kontext - wir antworten in unter 48 Stunden.
• Direkt unter +49 40 60940415. Wenn Sie lieber kurz sprechen wollen, bevor Sie Material schicken.

Keine Verkaufsmasche, keine Mehrteiler-Sequenz. Ein Gespräch, in dem wir hören, ob das Werkzeug Sie an einer Stelle berührt, an der wir Ihnen mit unserem Implementations-Erfahrungs-Schatz weiterhelfen können.

6 · Steel-Man: „Wir machen Datenqualität schon mit great_expectations“

Plausible Gegenposition: „Wir haben bereits einen Datenqualitäts-Stack mit great_expectations, pydantic oder dbt tests. Brauchen wir das überhaupt?" Drei Antworten:

• Andere Schichten. great_expectations und ähnliche Frameworks sind hervorragend für erwartete Tests gegen ein bekanntes Schema. Sie verlangen, dass Sie die Erwartung vorab formulieren. Unser Werkzeug startet ohne Erwartung und zeigt Ihnen, was sich tatsächlich in Ihrem Datensatz versteckt. Es ist der erste Schritt vor den Tests.
• Zehn Minuten statt zwei Wochen. Eine great_expectations-Suite vollständig aufzusetzen kostet je nach Datenmodell zwischen einer und vier Wochen. Eine dqa-Auswertung über einen frischen Datensatz kostet zehn Minuten. Beides hat seinen Platz; sie schließen sich nicht aus.
• Methoden-Tradition. Die Dimensionen sind nicht erfunden, sondern aus der etablierten Daten-Engineering-Literatur (Tukey 1977, Kolmogorov 1933, Smirnov 1939) und der pandas-Konvention. Das Werkzeug bündelt sie in einer reproduzierbaren CLI-Form.

7 · Was dieses Werkzeug nicht leistet

Sechs methodische Vorbehalte, die zum redlichen Bild gehören:

• Es ersetzt kein Schema-Vertrag. Wenn Sie ein Daten-Engineering-Tool für Vertrags-Tests gegen ein bekanntes Schema brauchen, ist great_expectations oder pandera die bessere Wahl. dqa ist die diagnostische erste Stufe davor.
• Es repariert nicht. Das Werkzeug diagnostiziert. Die Reparatur ist eine bewusste Entscheidung, die in Ihrem Daten-Engineering-Workflow stattfinden muss.
• CSV-Limit auf Schema-Konsistenz. Beim CSV-Lese-Pfad werden gemischte Typen vom Pandas-CSV-Reader maskiert. Wenn Sie diese Dimension scharf brauchen, exportieren Sie zur Audit-Phase nach Parquet.
• Optional-Dimensionen brauchen Hinweise. Zeitliche Lücken, referentielle Integrität und Repräsentativität sind nur dann aussagekräftig, wenn der Aufruf die Zeit-Spalte, die Foreign-Key-Spezifikation oder den Split mitgibt.
• Keine Domänen-Kenntnis. „Outlier" heißt statistisch außergewöhnlich. Ob ein Wert in Ihrer Domäne tatsächlich unplausibel ist, weiß nur Ihr Domänen-Experte.
• Sicherheits-Limit. Das Werkzeug ist nur dann sicher, wenn Sie sich an den Disclaimer halten. Kopie zuerst. Audit auf der Kopie. Niemals auf der Produktion.

Die vollständige Limitations-Liste mit weiteren Punkten steht in DISCLAIMER.md und im Companion-Repo-README.

8 · Reading List

1. Tukey 1977, Exploratory Data Analysis - Klassiker, Quelle des 1,5·IQR-Outlier-Tests.
2. Kolmogorov 1933 / Smirnov 1939, Two-sample KS test - Drift-Detection-Grundlage in Dimension 7.
3. pandas documentation, Missing data - Konventionen, denen das Werkzeug folgt.
4. Great Expectations docs - die Vertrags-Test-Schicht oberhalb der Diagnose-Schicht.

Zugehörige Arbeiten

• Ein Truth-Check-Protokoll für AI-Forschungs-Output - die methodische Review-Vorlage, die wir auf jede veröffentlichte Behauptung anwenden.
• Das Single-GARCH-Limit auf Soft Commodities - die methodische Disziplin in Aktion auf einem Prognose-Stack.

Begleit-Repository

myBytesResearch/data-quality-audit - vollständiger Code, sieben Dimensions-Module, CLI, Tests, synthetischer Beispiel-Datensatz mit bekannten Mängeln. Privat zum Veröffentlichungs-Zeitpunkt; der Sichtbarkeits-Flip auf public ist eine eigene Entscheidung. Wichtig: lesen Sie zuerst DISCLAIMER.md. Anwendung auf eigene Gefahr, ausschließlich auf Backups oder Samples.