Ein Churn-Modell, das sich innerhalb eines Quartals verschlechtert, sieht nach einem Algorithmusproblem aus. Das ist es fast nie. Die Features, die es speisen, wurden einmal für eine Momentaufnahme der Daten erstellt, und nichts in der Pipeline rekonstruiert sie beim nächsten Durchlauf identisch.
Die Vorbereitung von Daten für eine Machine Learning-Pipeline ist keine Bereinigungsaufgabe, die vor Beginn der Modellierung durchgeführt wird. Sie ist eine strukturelle Disziplin, die bestimmt, ob das Modell bei jeder Datenaktualisierung präzise bleibt. Eine Gartner-Umfrage aus dem Jahr 2025 unter 1.203 Führungskräften im Datenmanagement ergab, dass 63 % entweder nicht über die richtigen Datenmanagementpraktiken für KI verfügen oder sich nicht sicher sind, ob sie darüber verfügen, und Gartner prognostiziert, dass Unternehmen bis Ende 2026 60 % der KI-Projekte einstellen werden, die nicht durch KI-fähige Daten unterstützt werden.
Dieser Beitrag erläutert die vierstufige Disziplin, die Trainingsdaten modellbereit hält, zeigt, wo diese Disziplin in der Praxis scheitert, und erklärt, wie Sie damit beginnen können, sie aufzubauen, ohne gleich eine gesamte Pipeline neu aufzubauen. Sowohl Analysten als auch Analytics-Führungskräfte haben ein Interesse daran: Der Analyst betreut die Pipeline im Tagesgeschäft, und die Führungskraft muss letztlich erklären, warum ein Modell, das in Q1 funktionierte, in Q3 nicht mehr funktionierte.
Das Ergebnis: Daten, die modellbereit bleiben, nicht Daten, die einmal bereinigt wurden
Ein einmalig bereinigtes Dataset ist nicht das Ziel. Ein Prozess, der bei jeder Aktualisierung dasselbe Schema, dieselben Typen und dieselben Feature-Definitionen erzeugt, hingegen schon.
Model-ready bedeutet etwas Konkretes und Operatives: identisches Schema, identische Typen, identische Null-Handhabung und identische Feature-Definitionen bei jedem Durchlauf der Pipeline. Eine Datenvorbereitung, die diesen Standard nur einmal erfüllt, ist nicht abgeschlossen; es ist eine Momentaufnahme, der die nächste Aktualisierung widersprechen wird.
Der Unterschied ist wichtig, weil das Risiko bei einer fehlerhaften Pipeline unbemerkt und nicht offensichtlich ist. Die Pipeline läuft weiterhin und erzeugt nach wie vor Ausgaben; erst eine nachgelagerte Metrik, eine Churn-Warteschlange, die fehlerhaft aussieht, oder eine Prognose, die nicht stimmt, zeigt schließlich, dass sich vorgelagert etwas geändert hat.
Der am weitesten nachgelagerte Schritt, bei dem ein Modell an Daten angepasst wird, reagiert im Allgemeinen am empfindlichsten auf diese Art von vorgelagerter Änderung. Eine umbenannte Spalte oder eine andere Regel zur Behandlung von Nullwerten kann die Ergebnisse verändern, ohne dass jemals ein Fehler in der Pipeline auftritt.
Vier Schritte sorgen dafür, dass Trainingsdaten bei jeder Aktualisierung modellbereit bleiben: Sie sichern die Schema-Konsistenz, erkennen Drift, bevor sie das Modell erreicht, erstellen Features einmalig und verwenden sie wieder und validieren Daten, bevor sie bewertet werden. Jeder davon verhindert auf spezifische Weise, dass Pipelines unbemerkt von ihrer vorgesehenen Form abweichen.
Die Methode: ein vierstufiger Prozess, um Trainingsdaten modellbereit zu halten
Diese Reihenfolge gilt unabhängig davon, ob eine Pipeline in einem visuellen Workflow, in Python oder in SQL und dbt ausgeführt wird. Das Tool ändert sich; die zugrunde liegende Disziplin nicht. Das Überspringen eines dieser vier Schritte führt selten sofort zum Ausfall einer Pipeline; stattdessen schlägt eine künftige Aktualisierung fehl – und zwar so unbemerkt, dass sich die Ursache nur schwer zurückverfolgen lässt.
Schemakonsistenz vor allem anderen sperren
Schemakonsistenz bedeutet, dass bei jeder Aktualisierung dieselben Spaltennamen, -typen und dieselbe Reihenfolge erzeugt werden, auf die das Modell trainiert wurde. Diese Garantie entsteht nicht von allein; etwas muss sie erzwingen.
Hier neigen Pipelines auch dazu, unbemerkt auszufallen. Ein Quellsystem fügt ein Feld hinzu, benennt eines um oder ändert einen Typ, und es wird kein Fehler ausgegeben. Das Modell erhält einfach andere Eingaben und liefert andere, unerklärliche Ergebnisse.
Die praktische Lösung folgt unmittelbar auf die Erfassung, bevor eine Umwandlung ausgeführt wird: ein Schritt zur Typvalidierung, der das eingehende Schema mit den Erwartungen des Modells abgleicht. Weisen Sie jedem Feld explizite Datentypen zu, anstatt sich standardmäßig auf die automatische Erkennung von Feldtypen zu verlassen, da die automatische Erkennung eine praktische Hilfe ist, aber keine Absicherung dagegen bietet, dass ein Quellsystem unbemerkt seine Struktur ändert. Ein Feld, das bisher ganze Zahlen enthielt und jetzt Dezimalzahlen enthält, oder eine Spalte, die unbemerkt von Position vier auf Position sieben verschoben wurde, ist genau die Art von Änderung, für deren Erkennung dieser Schritt entwickelt wurde, bevor nachgelagerte Prozesse erreicht werden.
Drift erkennen und behandeln, bevor er das Modell erreicht
Data Drift bezeichnet das, was geschieht, wenn die statistischen Eigenschaften eingehender Daten von den Daten abweichen, mit denen das Modell trainiert wurde. Bleibt dies unkontrolliert, beeinträchtigt es die Genauigkeit, ohne dass ein einzelnes Ereignis den Moment markiert, in dem es geschah.
Zwei Arten sind hier wichtig. Ein Feature Drift liegt vor, wenn sich die Eingabeverteilungen verschieben – beispielsweise wenn eine Kategorie, die früher in 5 % der Fälle vorkam, plötzlich in 20 % der Fälle auftritt. Concept Drift ist anders: Die Beziehung zwischen Features und dem eigentlichen Ergebnis ändert sich, sodass dieselbe Eingabe nicht mehr dasselbe Ergebnis vorhersagt.
Die praktische Methode ist ein Baseline-Vergleich: Vergleichen Sie bei jeder Aktualisierung Zusammenfassungsstatistiken, Null-Rate, Kategorieanzahlen und Mittelwerte mit einem gespeicherten Baseline-Profil und kennzeichnen Sie Abweichungen, bevor das Scoring ausgeführt wird. Genau deshalb versagen einmal vorbereitete Daten mit der Zeit, denn Drift sammelt sich unsichtbar an, Aktualisierung für Aktualisierung, bis die Trainingsbedingungen und die aktuellen Bedingungen weit genug auseinanderliegen, um sich in den Ergebnissen bemerkbar zu machen. Ein Abwanderungsmodell, das beispielsweise auf einem Jahr Abrechnungsverhalten trainiert wurde, kann weiterhin zuversichtlich Scorings durchführen, selbst wenn sich der zugrunde liegende Kundenstamm unter ihm verändert.
Features einmal erstellen, bei jedem Durchlauf wiederverwenden
Das Erstellen eines Features bedeutet das Ableiten eines Felds – ein Alter aus einem Geburtsdatum, eine Dauer der Betriebszugehörigkeit aus zwei Datumsangaben –, das einem Modell ein Signal liefert, das Rohdatenfelder allein nicht enthalten. Es lohnt sich, diese Disziplin, Feature Engineering, zu verstehen, bevor Sie entscheiden, wie Sie sie codieren.
Das Fehlermuster hier ist eine schleichende Drift in der Logik selbst. Feature-Berechnungen, die bei jeder Aktualisierung manuell neu erstellt werden, weichen häufig von ihrer ursprünglichen Definition ab – etwa durch eine Datumsbereichsregel, die bei einem Durchlauf etwas anders berechnet wird als beim vorherigen –, bis zwei Durchläufe des „gleichen“ Features nicht mehr vergleichbar sind.
Die Lösung besteht darin, die Umwandlung als wiederverwendbaren, versionierten Pipeline-Schritt zu kodieren, anstatt als einmalige Berechnung, die aus dem Gedächtnis oder aus einem alten Skript erneut ausgeführt wird. Sobald sich die Logik eines Features an einem zentralen Ort befindet, wird sie bei jeder Aktualisierung auf dieselbe Weise berechnet, und jede Änderung an dieser Logik wird zu einer gezielten Bearbeitung statt zu einem Versehen. Außerdem bietet es allen, die das Modell später prüfen, eine einzige Definition zur Überprüfung anstelle einer Reihe leicht unterschiedlicher Tabellenkalkulationsformeln über ein Dutzend Monatsordner hinweg.
Validieren, bevor die Daten das Modell erreichen, nicht danach
Die Validierung ist die Prüfung, die nach der Datenvorbereitung und vor dem Scoring durchgeführt wird und bestätigt, dass die Daten dem Format und den Wertebereichen entsprechen, die das Modell erwartet. Das Überspringen beseitigt das Risiko nicht; es verlagert das Risiko lediglich nachgelagert auf diejenigen, die die Modellausgabe lesen.
Neue Daten, die in ein trainiertes Modell eingespeist werden, müssen dem Format entsprechen, mit dem es trainiert wurde. Eine unangekündigte Schema- oder Typabweichung führt unbemerkt zu falschen Vorhersagen anstatt zu einer Fehlermeldung, sodass in der Pipeline nichts beanstandet wird, bevor eine Entscheidung auf Grundlage fehlerhafter Ausgaben getroffen wird.
Ein Validierungs-Gate, Schwellenwerte für Null-Raten, Listen erwarteter Kategorien, Bereichsprüfungen sollten die Pipeline anhalten, anstatt fragwürdige Daten durchzuleiten. Besteht die Lücke aus einer Handvoll fehlender Werte in einem numerischen Feld, kann die Imputation diese durch einen Durchschnitt, Median oder Modalwert ersetzen, anstatt eine Null zu belassen, die die Modellausgabe verzerrt.
Dies ist dieselbe zuvor erwähnte Empfindlichkeit: der Schritt zur Modellanpassung reagiert stärker auf vorgelagerte Änderungen als jede andere Phase. Genau deshalb gehört die Validierung direkt davor und nicht an eine frühere Stelle, an der sich im Nachhinein noch mehr ändern kann.
Wo dies in der Praxis scheitert: das unbemerkte Versagen eines Churn-Modells
Das Modell zur Kundenabwanderung eines Abonnement-Ops-Analytics-Teams war zwei volle Quartale lang blind gegenüber seiner neuesten, am schnellsten wachsenden Kundenkohorte, und das Modell selbst war nie das Problem.
Das Team erstellte seine monatlichen Trainingsdaten durch die Zusammenführung von drei Systemen: Chargebee für Abrechnungs- und Mahndaten, Zendesk für Support-Ticket-Volumen und Sentiment sowie einen CRM-Export für die Kundenzugehörigkeitsdauer. Jedes System trug seinen eigenen Teil zum Gesamtbild bei: Historie fehlgeschlagener Zahlungen von Chargebee, Ticket-Häufigkeit und Stimmungswerte von Zendesk sowie die Kundenzugehörigkeitsdauer aus dem CRM. Ein daraus resultierendes Feature, days_since_last_invoice_failure, wurde aus der Mahnhistorie von Chargebee erstellt und jeden Monat zusammen mit allem anderen aktualisiert.
Nach der Migration des Abrechnungssystems verharrte dieses Feld bei jedem nach dem Migrationsdatum erstellten Konto stillschweigend auf seinem Wert vor der Migration. Diese neueren Konten meldeten fortlaufend dieselbe Zahl für „Tage seit dem Ausfall“, und das Modell interpretierte diese eingefrorene Zahl als durchweg solides Zahlungsverhalten.
Die Kosten machten sich keineswegs bei der Pipeline selbst bemerkbar. Zwei Quartale lang war das Abwanderungsmodell strukturell blind gegenüber seiner neuesten, am schnellsten wachsenden Kohorte – nicht, weil das Modell eine falsche Prognose lieferte, sondern weil seine Trainingsdaten die gesamte Kohorte einheitlich als risikoarm erscheinen ließen. Das ist ein gravierender blinder Fleck: KI-gestützte Customer-Experience-Intelligence kann Kunden identifizieren, die eine bis zu fünfmal höhere Abwanderungswahrscheinlichkeit aufweisen, wenn das zugrunde liegende Signal intakt ist – genau der Vorteil, den ein eingefrorenes Feld stillschweigend zunichtemacht.
Ein Analyst bemerkte schließlich, dass in der Churn-Risiko-Warteschlange des Retention-Teams verdächtigerweise niemand zu finden war, der sich in den letzten beiden Quartalen registriert hatte, und führte diese Lücke auf das eingefrorene Feld zurück. Eine Drift-Prüfung, die Werteverteilungen nach Registrierungskohorte vergleicht – so wie oben beschrieben –, hätte das Problem sofort gemeldet: Dass jedes Konto in einer Kohorte denselben identischen, unveränderlichen Wert aufweist, ist eine Anomalie, die ein Kohortenvergleich aufdeckt, obwohl sie in einem aggregierten Durchschnitt verschwindet.
Mit Schritten zur Schemakonsistenz und Abweichungserkennung wird dieselbe Art von Abrechnungsmigrationsereignis innerhalb eines Aktualisierungszyklus statt nach zwei Quartalen erfasst. Die oben genannten Grundlagen – gesperrtes Schema, überprüfte Abweichungen, versionierte Features – sind genau der richtige Ausgangspunkt; ein Schritt-für-Schritt-Überblick über das weitere Vorgehen geht noch genauer darauf ein.
Wie eine fertige, modellbereite Pipeline aussieht
Eine fertige, modellbereite Pipeline führt alle vier Schritte gemeinsam aus: Schema bei der Erfassung gesperrt, Drift anhand einer gespeicherten Baseline überwacht, Features versioniert und wiederverwendet statt neu erstellt und ein Validierungs-Gate vor dem Scoring. All dies wird nach einem wiederkehrenden Zeitplan ausgeführt, sodass Trainingsdaten aktualisiert werden, ohne dass jemand sie manuell neu erstellen muss.
Eine Pipeline, die bei jedem Durchlauf noch manuell überprüft wird, ist nicht automatisiert. Es ist eine geplante Aufgabe, an der ein unbezahlter Prüfer hängt – und dieser Prüfer ist die erste Person, der die Schuld gegeben wird, wenn sich vorgelagert unbemerkt etwas ändert.
Eine Version davon war das Analytics-Team von McGraw Hill Education, das Geschäftsanalysten zu Menschen machte, die ohne Code eigene Prognosemodelle erstellen. „Damit konnten wir Geschäftsanalysten zu Data Scientists machen, ohne eine einzige Zeile Code schreiben zu müssen“, sagte Fabio Italiano, Vice President of Analytics and Information Management des Unternehmens, und beschrieb einen auf Alteryx One erstellten Workflow zur Abwanderungsprognose.
Das ist die gleiche Abfolge, die die Assistierte Modellierung von Anfang bis Ende durchläuft: Zielauswahl, Bestätigung des Datentyps, Bereinigung fehlender Werte, Feature-Scoring und Algorithmenvergleich auf einer Bestenliste – ganz ohne tiefgehendes Data Science-Fachwissen. Es läuft innerhalb von Designer für Teams der Professional- oder Enterprise-Edition mit Vollnutzer-Zugriff als Teil des separaten Intelligence Suite-Add-ons.
Der Modellanpassungsschritt am Ende dieser Sequenz ist ausdrücklich als empfindlich gegenüber vorgelagerten Änderungen dokumentiert – dieselbe Empfindlichkeit, vor der dieser gesamte Prozess vom ersten Schritt an geschützt hat. Neue Daten, die später bewertet werden, müssen weiterhin dem Format entsprechen, das zum Trainieren des Modells verwendet wurde – dieselbe Begründung für das Validierungs-Gate wie zuvor, nur in der Bewertungsphase statt in der Vorbereitungsphase durchgesetzt.
Nichts davon erfordert, den Überblick darüber aufzugeben, was sich geändert hat oder wann. Workflows, die versioniert sind und automatisch ausgeführt werden, hinterlassen außerdem einen Datensatz darüber, wer was geändert hat und wann eine bestimmte Aktualisierung ausgeführt wurde. Dies unterstützt die Art von Prüfbarkeit, die eine wiederholbare Pipeline unabhängig von dem zugrunde liegenden Tool benötigt. Diese Nachverfolgbarkeit ist eine allgemeine Plattform-Governance und kein Anspruch auf modellspezifische Aufsicht, aber sie ermöglicht es einem Team dennoch, die Frage „Was hat sich seit dem letzten Monat geändert?“ zu beantworten, ohne die Antwort aus dem Gedächtnis rekonstruieren zu müssen.
Wann eine Code-First-Pipeline besser geeignet ist
Ein Team mit einer dedizierten ML-Engineering-Funktion, das bereits Feature Stores in Python oder dbt verwaltet, muss kein zweites Tool hinzufügen, um einen der vier oben genannten Schritte umzusetzen. Disziplin, Schemaprüfungen, versionierte Features und Validierungs-Gates sind wichtiger als die Frage, welches Tool sie durchsetzt.
Die integrierten Tests von dbt implementieren bereits zwei dieser Schritte in einem SQL-basierten Workflow, den Engineering-Teams ohnehin täglich nutzen. Tests auf Nicht-Null-Werte, zulässige Werte und Beziehungen stellen die Konsistenz und Validierung des Schemas sicher, ohne dass die vertraute Transformationsschicht verlassen werden muss.
Python-basierte Pipelines, die auf pandas und scikit-learn aufbauen, bieten die vollständige Kontrolle über benutzerdefinierte Feature-Logik und Schwellenwerte zur Erkennung von Datenabweichungen (Drift), die ein visuelles Tool möglicherweise nicht bereitstellt. Für Data Engineers, die mit der Wartung dieses Codes vertraut sind, ist dies oft der flexiblere Weg.
Die Abwägung der Vor- und Nachteile ist in beide Richtungen legitim. Code-First-Pipelines benötigen jemanden, der diesen Code lesen und pflegen kann – ein echter Kostenfaktor, wenn diese Person das Unternehmen verlässt oder in ein anderes Team wechselt. Ein visueller Workflow tauscht einen Teil dieser Flexibilität gegen eine Pipeline ein, die jede/r Data Analyst im Team öffnen, lesen und prüfen kann, ohne einen Data Engineer bitten zu müssen, sie zu erläutern.
Die Entscheidungsregel ist einfach: Wenn Data Engineers diese Pipeline bereits in dbt oder Python verwalten, ist dieser Weg meist vorzuziehen, da die Einführung eines zweiten Tools lediglich zusätzlichen Aufwand bedeutet. Wenn die Pipeline derzeit nur im Kopf von Mitarbeiter:innen und in einem Ordner voller Tabellenexporte existiert, schließt ein geführtes Tool die Lücke schneller, als die Engineering-Kapazität von Grund auf neu aufzubauen – insbesondere für ein Team, das keinen dedizierten Engineer für das Projekt entbehren kann.
So fangen Sie klein an
Bauen Sie nicht die gesamte Pipeline auf einmal neu auf. Wählen Sie das einzelne Feature aus, das am häufigsten aus dem Gedächtnis neu erstellt wird, und kodieren Sie es zuerst als wiederverwendbaren, versionierten Schritt. Allein diese eine Änderung beseitigt in der Regel die häufigste Ursache für unbemerkte Abweichungen (sog. Slow Drift).
Fügen Sie als Nächstes eine Validierungsprüfung hinzu: einen Schwellenwert für die Null-Rate für das Feld, bei dem am ehesten unbemerkt Fehler auftreten, also jene Art von eingefrorenem oder fehlendem Wert, die im oben genannten Churn-Szenario zunächst unauffällig wirkten, bis der Fehler mühsam zurückverfolgt werden musste. Eine tatsächlich implementierte Regel ist besser als ein Dutzend geplanter Regeln, die nie umgesetzt werden.
Erstellen Sie ein Basisprofil des aktuellen Trainingsdatasets, bevor Sie irgendetwas anderes ändern: Zeilenanzahlen, Null-Raten und Kategorienverteilungen im aktuellen Zustand. Diese Basis dient als Vergleichsgröße für die nächste Aktualisierung. Ohne sie fehlt der Drift-Erkennung der Maßstab.
Planen Sie einen automatischen Einzeldurchlauf der kleinsten funktionsfähigen Version der Pipeline ein, noch bevor jeder einzelne Schritt automatisiert ist. Dieser eine Durchlauf ist der eigentliche Test dafür, ob die Konsistenz zwischen den Aktualisierungen gewahrt bleibt. Ein Plan auf dem Papier reicht dafür nicht aus.
Betrachten Sie diese erste erfolgreiche automatisierte Aktualisierung als den entscheidenden Nachweis, nicht die fertiggestellte Pipeline. Bauen Sie von dort aus Schritt für Schritt weiter aus – ein Feature, eine Validierungsregel, eine Drift-Prüfung nach der anderen –, bis sich die gesamte Trainings-Pipeline bei jedem Durchlauf gleich verhält.
Alteryx One bietet eine kostenlose Testversion für Teams, die diese Art von Pipeline von der Datenvorbereitung bis hin zur unterstützten Modellierung ausprobieren möchten, bevor sie sich für ein komplettes Rollout entscheiden. Starten Sie eine kostenfreie Testversion.