Warum Datenqualität über Modellqualität entscheidet

Die KI-Branche debattiert Modellarchitekturen, Parametergrößen und Trainingsverfahren während das eigentliche Problem systematisch übersehen wird: die Qualität der Inputdaten. Wer schlechte Daten in ein leistungsstarkes Modell eingibt, bekommt schlechte Ergebnisse zurück. Das ist kein neues Prinzip. Unter dem Begriff Garbage In, Garbage Out ist es seit Jahrzehnten bekannt. Aber im Zeitalter von Large Language Models wird es gefährlicher als je zuvor — weil Fehler schwerer sichtbar sind, sich langsamer manifestieren und tiefer in Produktionssysteme eingebettet sind, bevor jemand sie bemerkt.

Was klassische ML-Systeme noch relativ transparent machten, eine schlechte Confusion Matrix, ein auffälliger Validierungsverlust, liefern moderne Foundation Models nicht mehr mit der gleichen Direktheit. Outputs wirken kohärent, auch wenn die zugrundeliegenden Daten fehlerhaft sind. Das macht Datenqualität nicht weniger wichtig, sondern schwerer kontrollierbar.

Das strukturelle Problem hat einen Namen

Forscherinnen von Google Research haben 2021 in einer vielzitierten Studie einen Begriff geprägt, der das Problem treffend beschreibt: Data Cascades. Sambasivan et al. befragten 53 KI-Praktikerinnen und -Praktiker aus Indien, den USA und afrikanischen Ländern — alle tätig in hochriskanten Anwendungsfeldern wie Kreditvergabe, Gesundheitsversorgung und öffentlicher Sicherheit. Das Ergebnis ist ernüchternd: 92 % der Befragten berichteten von mindestens einer Data Cascade in ihrem Projekt. Fast die Hälfte erlebte zwei oder mehr davon.

Eine Data Cascade ist kein einzelner Fehler, sondern ein sich verstärkender Effekt: Ein Datenproblem im Upstream — etwa beim Labeling oder der Erhebung — pflanzt sich durch die gesamte Pipeline fort und manifestiert sich oft erst Monate oder Jahre später im Produktionssystem. Die Kaskaden entstehen dabei nicht trotz, sondern wegen konventioneller KI-Praktiken: schnell zum Proof-of-Concept, Modell-Performance optimieren statt Datenpipeline sanieren, Datenarbeit als operative Nebenaufgabe behandeln.

Der prägnanteste Befund der Studie ist nicht die Statistik, sondern ein Zitat eines Praktikers aus dem Bereich Healthcare: "Everyone wants to do the model work, not the data work." Dieser Satz beschreibt ein strukturelles Incentive-Problem, das weit über einzelne Projekte hinausgeht.

ThinkBeyondAi | LinkedIn

ThinkBeyondAi | 3 followers on LinkedIn. thinkbeyondai: Midjourney-Mentalität – kritisch auf AI blicken, Berufe im Wandel verstehen, Zukunft denken. | thinkbeyondai ist eine Plattform für Reflexion, Analyse und Debatte im Zeitalter von Künstlicher Intelligenz. Wir beleuchten, wie AI Berufe, Karrieren und ganze Branchen verändert – von der Anwaltskanzlei über die Unternehmensberatung bis hin zu M&A und Corporate Finance. Kern unseres Ansatzes ist die Midjourney-Mentalität: eine kritische Haltung gegenüber oberflächlicher AI-Nutzung.

LinkedIn

Die vier Kaskaden-Typen und ihre Verbreitung

Sambasivan et al. identifizieren vier konkrete Auslöser, die Data Cascades in der Praxis triggern. Der häufigste — bei 54,7 % der Befragten — ist die Interaktion mit der physischen Welt: Modelle werden auf sauberen, kontrollierten Trainingsdaten entwickelt, treffen im Produktionseinsatz aber auf chaotische Realität. Kameras, die sich durch Witterung verschieben, Sensoren mit Wartungsrückständen, veränderte Umgebungsbedingungen — all das erzeugt Daten, die das Modell nie gesehen hat. Diese Kaskaden manifestieren sich am spätesten, teils erst zwei bis drei Jahre nach dem Deployment.

Der zweithäufigste Auslöser — 43,4 % — ist fehlende Domänenexpertise beim Labeling. Wenn KI-Entwickler ohne ausreichendes Fachwissen entscheiden müssen, was korrekte Ground Truth ist — ob ein Versicherungsanspruch berechtigt war, ob ein Kreditausfall als vermeidbar gilt — fließen ihre Annahmen direkt in die Datenbasis ein. Im Finance-Kontext ist das besonders kritisch: Historische Kreditentscheidungen spiegeln oft die subjektive Einschätzung einzelner Sachbearbeiter wider, nicht eine objektive Realität.

Dahinter folgen konfligierende Anreizsysteme (32,1 %): Feldpartner, die Daten erheben — Ärzte, Sachbearbeiter, Analysten — haben eigene Prioritäten, die mit den Anforderungen der Datenpipeline kollidieren. Unvollständige Erfassung, falsche Frequenzen, motivationsbedingte Datenfabrikation sind die Folge. Abgeschlossen wird das Bild durch schlechte organisationsübergreifende Dokumentation (20,8 %): Fehlende Metadaten zwingen Teams zu Annahmen über Datensätze, was in kostspieligen Fällen zum vollständigen Verwerfen von Monaten an Datenarbeit führt.

Warum sich das Problem so hartnäckig hält

Das Incentive-Problem ist tiefer verwurzelt als es auf den ersten Blick scheint. In der akademischen ML-Community werden neue Modelle durch Publikationen, Benchmark-Ergebnisse und Konferenzbeiträge sichtbar — Datenarbeit dagegen kaum. Wer eine neue Architektur veröffentlicht, baut Reputation auf. Wer eine Datenpipeline sorgfältig dokumentiert und bereinigt, tut das weitgehend unsichtbar.

Dasselbe Muster findet sich in Unternehmen: Datenpflege lässt sich schlecht in Quartalsberichten ausweisen, Modell-Upgrades schon. Das führt dazu, dass Ressourcen systematisch in die sichtbare Seite des KI-Stacks fließen — in Modelle, Infrastruktur, Inference-Optimierung — während die Datenbasis vernachlässigt wird. Sambasivan et al. zeigen, dass dieser strukturelle Bias nicht auf einzelne Organisationen beschränkt ist, sondern branchenweit gilt. Datenkaskaden waren in ihrer Studie die Regel, nicht die Ausnahme — und das obwohl alle befragten Praktiker um die Bedeutung von Datenqualität wussten.

Login • Instagram

Welcome back to Instagram. Sign in to check out what your friends, family & interests have been capturing & sharing around the world.

Was passiert, wenn Labels falsch sind

Sambasivan et al. dokumentieren, wie Datenprobleme entstehen und sich durch Produktionspipelines fortpflanzen. Northcutt et al. setzen einen Schritt früher an — und zeigen, dass das Problem nicht erst im Deployment beginnt, sondern bereits in den Datensätzen steckt, auf denen die Branche ihre Modelle bewertet.

Die Forscher vom MIT untersuchten 2021 systematisch die Testdatensätze von zehn der meistgenutzten ML-Benchmarks — darunter ImageNet, CIFAR-10 und Amazon Reviews. Ihr Befund: Im Durchschnitt enthielten diese Datensätze mindestens 3,3 % fehlerhafte Labels. Beim ImageNet-Validierungsset liegt die Schätzung nach ergänzender Expertenprüfung sogar bei rund 20 %

Diese Zahl allein wäre schon bemerkenswert. Noch aufschlussreicher ist jedoch, was die Fehler mit der Modellauswahl machen. Auf den bereinigten Testdaten kehrt sich das Ranking der Modelle teilweise vollständig um: Das komplexe NASNet-large fällt von Platz 1 auf Platz 29 von 34 getesteten Modellen. Das deutlich einfachere ResNet-18 steigt von Platz 34 auf Platz 1.

Der Grund ist strukturell: Große Modelle lernen alle statistischen Muster in den Daten — einschließlich der systematischen Fehler im Labeling. Sie optimieren auf den Benchmark, nicht auf die Realität. Kleinere Modelle haben nicht genug Kapazität, um diese Fehlerstrukturen zu memorieren, und performen deshalb auf korrekten Daten besser. Das ist kein klassisches Overfitting. Es ist ein Overfitting auf die Fehlerstruktur des Datensatzes selbst.

Die Studie von Northcutt et al. und ihre Implikationen für Modellauswahl und Benchmark-Stabilität werden in einem separaten Artikel ausführlich behandelt.

Preview: Was ist ein Label Error? Ein Label Error bezeichnet einen Datenpunkt, dem eine falsche Kategorie zugewiesen wurde. Auf einem Bild eines Schwarzstorchs steht das Label „Weißstorch". Ein Modell, das auf solchen Daten trainiert wird, lernt den Fehler der Annotatoren — nicht die tatsächliche Realität.

Was das für Finance-Anwendungen bedeutet

Beide Studien sind nicht im Finance-Kontext entstanden — ihre Implikationen treffen den Sektor jedoch direkt.

Erstens: Credit Scoring mit historisch verzerrten Daten. Modelle, die auf Kreditentscheidungen aus Perioden vor 2008 oder vor COVID-19 trainiert wurden, haben ein fundamentales Datenproblem — nicht weil das Modell falsch konfiguriert ist, sondern weil der Datenschnitt ein Marktregime abbildet, das nicht mehr existiert. Eine Data Cascade klassischer Prägung: Der Fehler entsteht im Upstream, sichtbar wird er erst im Produktionseinsatz.

Zweitens: Sentiment-Analyse auf Earnings Calls. Wer ein Sprachmodell auf generischen Textdaten trainiert und für Financial-NLP einsetzt, bekommt systematische Fehlklassifikationen — weil Begriffe wie „liability" oder „hedging" im Finanzkontext eine andere Bedeutung tragen als in der Allgemeinsprache. Die Qualität der Primärquelle — hier: domänenspezifische Trainingsdaten — entscheidet über die Qualität des Outputs, nicht die Größe des Modells.

Fazit

Wer in bessere Modelle investiert, ohne die Datenpipeline zu sanieren, kauft sich teurere Fehler. Die Forschungslage ist eindeutig: Datenqualität ist keine operative Nebenaufgabe, sondern die entscheidende Variable für die Leistungsfähigkeit jedes KI-Systems. Das gilt für Bildklassifikation genauso wie für Kreditrisikomodelle. Solange Datenarbeit als weniger prestigeträchtig gilt als Modellentwicklung, werden Data Cascades die Regel bleiben — nicht die Ausnahme.