Trainings- und Testdaten

Trainings- und Testdaten sind die zwei Teile, in die ein beschrifteter Datensatz (Beispiele mit bekannter Antwort) vor dem Trainieren eines Machine-Learning-Modells zerlegt wird: Trainingsdaten bringen dem Modell das Muster bei, Testdaten prüfen an bisher ungesehenen Beispielen, wie gut es sich auf neue Fälle überträgt. Ein dritter Teil, die Validierungsdaten, dient zwischendurch dem Vergleich verschiedener Modell-Varianten und der Einstellung ihrer Stellschrauben (Hyperparameter).

Was sind Trainings- und Testdaten?

Trainings- und Testdaten sind das Standard-Werkzeug, um beim Lernen aus Beispielen mit bekannter Antwort (überwachtes Lernen, englisch supervised learning) zwei Dinge sauber zu trennen: das Anlernen des Modells und die Prüfung, wie gut es tatsächlich funktioniert. Der beschriftete Datensatz besteht aus Merkmalen (Eingabewerten wie Alter, Umsatz, Klickzahl) und dem Zielwert, den das Modell später vorhersagen soll. Er wird vor dem Training in nicht überlappende Teile zerlegt. Die Trainingsmenge liefert die Beispiele, an denen das Verfahren seine internen Werte einstellt; die Testmenge enthält Beispiele, die das fertige Modell nie gesehen hat, und misst darauf die erwartete Leistung im späteren Produktivbetrieb.

Praktisch relevant ist meist eine Drei-Teilung. Zwischen Training und Test steht eine Validierungsmenge, auf der Hyperparameter (Lernrate, Baumtiefe, Regularisierung), Modell-Familie und Early Stopping ausgewählt werden. Die Testmenge bleibt dabei unangetastet und liefert erst ganz am Ende die abschließende Leistungs-Schätzung. Typische Verhältnisse sind 80/10/10 oder 70/15/15, bei kleineren Datenmengen 60/20/20. Bei [Classification](/insights/glossar/classification/) wird stratifiziert gesplittet, sodass die Klassenverteilung in allen Teilmengen konstant bleibt und seltene Klassen im Test präsent sind.

Der Split muss zur Datenstruktur passen. Bei zeitreihennahen Daten wie Absatzzahlen, Sensor-Streams oder Kundenverhalten wird zeitlich getrennt: Training vor einem Cut-off, Validierung und Test danach. Ein zufälliger Split würde Zukunftsinformation ins Training ziehen und die Leistung systematisch überschätzen. Diese Klasse von Fehlern gehört zum breiteren Problem des Data Leakage, das [Kaufman et al. 2012](https://www.cs.umb.edu/~ding/history/470_670_fall_2011/papers/cs670_Tran_PreferredPaper_LeakingInDataMining.pdf) kanonisch aufgearbeitet haben. Feature-Statistiken wie Mittelwerte, Encoder-Parameter und Imputations-Werte werden aus demselben Grund ausschließlich auf der Trainingsmenge berechnet und dann auf Validierung und Test angewendet.

Bei kleinen Datensätzen liefert ein einzelner Split unzuverlässige Schätzwerte. Hier greift die K-Fold-Kreuzvalidierung: der Datensatz wird in K Teilmengen (Folds) zerlegt, das Modell K-mal trainiert (jeweils auf K-1 Folds) und auf der ausgelassenen Faltung bewertet. Der Mittelwert über alle K Läufe reduziert die Varianz der Schätzung. Kreuzvalidierung ersetzt dabei die Rolle des Validierungs-Sets; eine echte Testmenge bleibt trotzdem erforderlich. Die Grundlagen gehen auf [Stone 1974](https://www.jstor.org/stable/2984809) zurück; als Standardreferenz für Trainings-, Validierungs- und Testdaten gilt Hastie, Tibshirani und Friedman in „The Elements of Statistical Learning", Kapitel 7.

Abgrenzung zu Validierungsdaten, Holdout, Kreuzvalidierung und Golden Dataset

Rund um die Trainings-/Test-Trennung existieren mehrere Begriffe, die häufig synonym verwendet werden, technisch aber Unterschiedliches meinen.

Validierungsdaten sind ein dritter Split zwischen Training und Test. Auf ihnen werden Hyperparameter und Modell-Kandidaten bewertet, ohne die Testmenge zu verbrauchen. In gängigen Rezepten fließen die Validierungsdaten am Ende in das Training des finalen Modells zurück, während die Testmenge bis zur Freigabe unberührt bleibt.

Ein Holdout-Set ist ein besonders geschütztes Test-Set. Es wird ganz zu Beginn abgetrennt, während Entwicklung und Hyperparameter-Suche nie berührt und erst kurz vor Produktivsetzung ausgewertet. Der Begriff überschneidet sich mit „Testdaten", wird aber vor allem dann verwendet, wenn zusätzlich Kreuzvalidierung im Einsatz ist und die abschließende Prüfung strikt vom Entwicklungs-Kreislauf getrennt sein soll.

Kreuzvalidierung bezeichnet ein Bewertungs-Verfahren, keinen einzelnen Datensplit. Statt einmalig zu teilen, werden mehrere Trainings-/Prüfungs-Aufteilungen nacheinander gebildet. Kreuzvalidierung ersetzt die Rolle des Validierungs-Sets und liefert stabile Leistungs-Schätzungen bei kleinen Datenmengen; die Testmenge bleibt trotzdem erforderlich.

Ein Golden Dataset stammt aus der Evaluation generativer Modelle. Es besteht aus kuratierten Prompt-Antwort-Paaren oder Referenz-Ausgaben und dient qualitativer Bewertung von Chat-Modellen, Retrieval-Pipelines und Agenten. Statistische Splits kommen hier meist nicht zum Tragen; der Vergleich läuft über Referenz-Metriken und Judge-Modelle.

Beispiel: Churn-Prognose mit stratifiziertem 70/15/15-Split

Ein Handelsunternehmen will kündigungsgefährdete Kunden vorhersagen. Als Datengrundlage stehen 500.000 gelabelte historische Kundenprofile bereit; das Label ist binär (gekündigt innerhalb der folgenden zwölf Monate: ja/nein) mit einer Positivrate unter fünf Prozent. Der Datensatz wird stratifiziert nach Klasse in 70 Prozent Training, 15 Prozent Validierung und 15 Prozent Test gesplittet, damit alle Teilmengen dieselbe Kündigungsquote tragen.

Auf der Trainingsmenge läuft ein Gradient-Boosting-Modell (LightGBM) mit fünffacher stratifizierter Kreuzvalidierung. Die Kreuzvalidierung dient der Hyperparameter-Suche über Lernrate, Baumtiefe und Regularisierung; das Validierungs-Set wählt anschließend zwischen den besten Kandidaten und legt den Schwellenwert entlang der Business-Kosten von False Positives und False Negatives fest. Die 15 Prozent Testdaten bleiben während der gesamten Entwicklung unberührt und liefern erst am Ende F1-Score, PR-AUC und die Verwirrungsmatrix als finale Leistungs-Schätzung vor der Produktivsetzung.

Der gleiche Aufbau kommt in vielen Anwendungsfeldern vor: Ticket-Klassifikation im Kundenservice mit Macro-F1, Kredit-Scoring mit unbalancierten Klassen und PR-AUC, Predictive Maintenance mit gelabelten Ausfällen. Bei Nachfrage-Forecasting oder Predictive-Maintenance-Setups mit Zeitreihen-Charakter wird der Zufalls-Split durch einen zeitlichen Split ersetzt; alles andere bliebe ein klassischer Data-Leakage-Fall. Auf einer integrierten Data- und AI-Plattform wie in [Databricks Mosaic AI](/insights/databricks/artificial-intelligence/) sind Trainings-, Validierungs- und Testdaten Teil der versionierten Feature- und Trainings-Tabellen im Lakehouse; Split-Strategie und Metriken werden mit MLflow zusammen mit dem Modell versioniert.