Machine-Learning-Modell technisch validieren: Testdaten, Metriken, Overfitting und Datenleckage

Machine Learning & KI

Eine Modellkennzahl ist nur dann technisch nachvollziehbar, wenn bekannt ist, welcher Modellstand, welcher Datenbestand, welche Ziel- oder Referenzwerte, welche Metrik und welches Auswertungsverfahren ihr zugrunde liegen. Ebenso muss geprüft werden, ob Informationen aus dem Testbestand bereits in Training, Modellwahl oder Vorverarbeitung eingeflossen sind.

1. Prüfgegenstand und Validierungsdesign

Vor der Validierung muss der konkrete Modellstand feststehen

Eine Leistungskennzahl kann nur einem bestimmten Modellzustand zugeordnet werden, wenn dieser hinreichend identifiziert ist.

Dazu können beispielsweise gehören:

• Modellartefakt,
• Hashwert,
• Modellversion,
• Parameterzustand,
• Vorverarbeitung,
• Schwellenwerte,
• relevante Laufzeitumgebung.

Die technische Bestimmung eines solchen Modellstands ist Gegenstand des Beitrags Machine-Learning-Modell als Untersuchungsgegenstand: Modellversion, Parameter, Datenbasis und Laufzeitumgebung .

Eine Validierungsfrage benötigt einen definierten Prüfmaßstab

Die Aussage „das Modell ist gut“ bezeichnet keinen eindeutigen technischen Prüfmaßstab.

Vor der Messung sollte deshalb geklärt werden:

• welche technische Aufgabe bewertet wird,
• welche Zielvariable oder Referenz vorliegt,
• welche Fehlerarten relevant sind,
• welche Metrik verwendet wird,
• welcher Datenbestand als Bewertungsgrundlage dient.

Technischer Prüfpfad Von der Prüfgrundlage zur belastbaren Aussage

1 Prüfgegenstand Modellstand · Datenstand · Zielvariable

2 Trennung & Leakage Split · Cross-Validation · Pipeline

3 Messung Testbestand · Metrik · Schwellenwert

4 Einordnung Unsicherheit · Reproduzierbarkeit · Grenze

Revision: neue Daten · Modellwechsel · Pipelineänderung · neue Evidenz → erneute Validierung

2. Datenaufteilung und unabhängige Evaluation

Trainings-, Validierungs- und Testdaten haben unterschiedliche Rollen

Bei einem überwachten Machine-Learning-Verfahren können unterschiedliche Datenbestände für unterschiedliche Schritte verwendet werden.

Vereinfacht können dabei unterschieden werden:

• Trainingsdaten zur Anpassung des Modells,
• Validierungsdaten für Auswahl- oder Abstimmungsentscheidungen,
• Testdaten für eine hiervon getrennte abschließende Leistungsbewertung.

Welche konkrete Aufteilung fachlich geeignet ist, hängt von Datenstruktur und Untersuchungsfrage ab.

Training und Test auf denselben Daten messen keine unabhängige Generalisierung

Wird ein Modell auf denselben Beobachtungen bewertet, mit denen seine Parameter gelernt wurden, ist diese Messung keine unabhängige Prüfung des Verhaltens auf bislang ungesehenen Daten.

Die scikit-learn-Dokumentation bezeichnet das Lernen und anschließende Testen auf denselben Daten ausdrücklich als methodischen Fehler und erläutert dies im Zusammenhang mit Overfitting.

Overfitting betrifft die Übertragbarkeit auf ungesehene Daten

Ein Modell kann die Trainingsdaten sehr gut abbilden und dennoch auf neuen Beobachtungen deutlich schlechter abschneiden.

Für eine technische Untersuchung ist deshalb nicht nur die Trainingsleistung relevant, sondern insbesondere die Leistung auf Daten, die nicht zur Modellanpassung verwendet wurden.

Der finale Testbestand darf nicht schrittweise zum Optimierungsziel werden

Werden Hyperparameter, Features, Schwellenwerte oder Modellvarianten wiederholt anhand desselben Testbestands ausgewählt, fließt Wissen über diesen Bestand mittelbar in die Modellentwicklung ein.

Die gemessene Testleistung ist dann nicht mehr im selben Sinn eine unabhängige Abschlussmessung.

Hyperparameterwahl und finale Testmessung sind zu trennen

Für Modell- und Hyperparameterentscheidungen können beispielsweise Validierungsdaten oder Cross-Validation eingesetzt werden.

Der finale Testbestand sollte davon getrennt bleiben, wenn gerade eine möglichst unabhängige Schlussbewertung untersucht wird.

Cross-Validation ersetzt nicht automatisch einen finalen Testbestand

Cawley und Talbot zeigen für untersuchte Modellwahlverfahren, dass auch das Auswahlkriterium überangepasst werden kann. Wird dasselbe Ergebnis anschließend als unabhängige Leistungsschätzung verwendet, kann ein optimistischer Selection Bias entstehen. Wie stark dieser Effekt im Einzelfall ist, lässt sich daraus allein nicht bestimmen.

Bei k-facher Cross-Validation wird ein Datenbestand in mehrere Folds geteilt. In jedem Durchlauf dienen andere Teilmengen zum Lernen und Bewerten.

Die scikit-learn-Dokumentation weist darauf hin, dass für die abschließende Evaluation weiterhin ein separater Testbestand zurückgehalten werden kann beziehungsweise soll.

Ein Cross-Validation-Ergebnis ist mehr als nur sein Mittelwert

Neben einem Mittelwert können auch die einzelnen Fold-Ergebnisse für die technische Interpretation relevant sein.

Starke Schwankungen zwischen Folds können Hinweise darauf geben, dass das Ergebnis von der konkreten Datenaufteilung beeinflusst wird.

Die Ursache einer solchen Schwankung muss anschließend gesondert untersucht werden.

Das Split-Verfahren muss zur Datenstruktur passen

Eine zufällige Aufteilung ist nicht für jede Datenstruktur automatisch sachgerecht.

Abhängigkeiten zwischen Beobachtungen können dazu führen, dass technisch sehr ähnliche oder zusammengehörige Datenpunkte auf Trainings- und Testseite gelangen.

Gruppenbezüge können einen gewöhnlichen Zufallssplit verfälschen

Enthält ein Datenbestand beispielsweise mehrere Beobachtungen derselben Person, Maschine, Einrichtung oder sonstigen Gruppe, kann eine gruppenweise Trennung erforderlich sein.

scikit-learn stellt hierfür unter anderem gruppenbezogene Cross-Validation-Verfahren wie GroupKFold bereit.

Zeitreihendaten benötigen eine zeitlich passende Evaluation

Bei Zeitreihen können zeitlich benachbarte Beobachtungen voneinander abhängig sein.

Eine zufällige Mischung von Vergangenheit und Zukunft kann deshalb eine andere Frage beantworten als die spätere Vorhersage tatsächlich zukünftiger Beobachtungen.

scikit-learn beschreibt hierfür unter anderem TimeSeriesSplit.

Wann verliert ein Testbestand seine Funktion als unabhängige Abschlussmessung?

Entscheidend ist nicht nur, ob Testzeilen formal vom Trainingsbestand getrennt sind. Auch indirekte Informationsübertragung kann die Unabhängigkeit der Schlussmessung schwächen.

• Modellvarianten werden wiederholt anhand desselben Testbestands ausgewählt.
• Schwellenwerte oder Features werden mit Kenntnis der Testergebnisse angepasst.
• Skalierung, Imputation oder Merkmalsauswahl werden vor dem Split auf allen Daten gelernt.
• Der Testbestand beeinflusst damit mittelbar die Entwicklung des später bewerteten Modells.

3. Datenleckage und Pipeline

Datenleckage ist mehr als eine doppelte Zeile im Datensatz

Data Leakage beziehungsweise Datenleckage liegt methodisch insbesondere dann nahe, wenn Informationen, die beim späteren Vorhersagezeitpunkt nicht verfügbar wären, bereits beim Modellaufbau verwendet werden.

Dadurch können zu optimistische Leistungswerte entstehen.

Vorverarbeitung kann Datenleckage erzeugen

Auch scheinbar vorgelagerte technische Verarbeitungsschritte können Informationen aus dem Testbestand aufnehmen.

Beispiele können sein:

• Skalierung,
• Imputation,
• Dimensionsreduktion,
• Merkmalsauswahl,
• andere datenabhängig gelernte Transformationen.

Werden solche Transformationen auf dem Gesamtdatensatz gelernt, bevor der Testbestand sauber getrennt wurde, können Testinformationen in die Trainingspipeline gelangen.

fit und fit_transform dürfen den Testbestand nicht lernen lassen

Die scikit-learn-Dokumentation empfiehlt, Trainings- und Testdaten vor datenabhängiger Vorverarbeitung zu trennen.

Lernende Schritte werden auf den Trainingsdaten angepasst. Auf den Testbestand wird anschließend die bereits gelernte Transformation angewendet.

Feature Selection vor dem Split kann Leistungswerte verzerren

Wird eine Merkmalsauswahl unter Kenntnis des gesamten Datenbestands durchgeführt, kann auch die spätere Testmenge die Auswahl der Features beeinflussen.

Eine formal getrennte Modellanpassung danach beseitigt diese vorherige Informationsübertragung nicht automatisch.

Pipelines können die korrekte Reihenfolge technisch absichern

Eine Pipeline kann Vorverarbeitung und Modellschritt zu einer gemeinsamen Verarbeitungskette verbinden.

Richtig eingesetzt unterstützt dies dabei, dass lernende Transformationen innerhalb von Training und Cross-Validation nur auf den jeweils vorgesehenen Trainingsanteilen angepasst werden.

4. Testdaten, Labels und Metriken

Die Qualität des Testbestands begrenzt die Aussage über das Modell

Auch ein methodisch sauber vom Training getrennter Testbestand liefert nur dann eine aussagekräftige Messung, wenn seine Daten und Referenzwerte zur konkreten Prüfungsfrage passen.

Herkunft, Datenstand und Transformationen können mit den Methoden aus Daten als Untersuchungsgegenstand: Herkunft, Datenstand und Reproduzierbarkeit untersucht werden.

Referenzwerte beziehungsweise Labels sind selbst Untersuchungsgegenstand

Klassifikations- und Regressionsmetriken vergleichen Vorhersagen regelmäßig mit Referenzwerten.

Sind diese Referenzwerte fehlerhaft, uneinheitlich, nur teilweise verfügbar oder nachträglich verändert worden, begrenzt dies auch die Aussagekraft der darauf berechneten Modellkennzahl.

Zur technischen Datenqualitätsprüfung siehe Datenqualität technisch prüfen: Vollständigkeit, Konsistenz, Genauigkeit und Aktualität .

Eine Metrik ist Teil des Prüfmaßstabs

Unterschiedliche Metriken messen unterschiedliche Eigenschaften eines Vorhersageverfahrens.

Deshalb sollte nicht nur der Zahlenwert, sondern auch die exakte Metrikdefinition Bestandteil der technischen Dokumentation sein.

Accuracy beantwortet eine andere Frage als Precision oder Recall

Bei Klassifikationsaufgaben können beispielsweise Accuracy, Precision, Recall oder F1-Score verwendet werden.

Diese Kennzahlen sind nicht austauschbar. Sie gewichten beziehungsweise beschreiben richtige und falsche Entscheidungen auf unterschiedliche Weise.

Klassenverteilung und Support gehören zur Interpretation

Eine Modellkennzahl sollte im Kontext der tatsächlich vorhandenen Klassen und ihrer Häufigkeiten betrachtet werden.

Besonders bei stark unterschiedlichen Klassenhäufigkeiten kann eine aggregierte Kennzahl wichtige Unterschiede zwischen Klassen verdecken.

Eine Konfusionsmatrix macht Fehlerarten sichtbar

Eine Konfusionsmatrix kann für Klassifikationsaufgaben sichtbar machen, welche tatsächlichen Klassen welchen vorhergesagten Klassen gegenüberstehen.

Damit lässt sich eine aggregierte Kennzahl durch konkretere Fehlerzahlen ergänzen.

ROC AUC verwendet Scores und beantwortet nicht dieselbe Frage wie Accuracy

scikit-learn stellt unter anderem roc_auc_score für Vorhersagescores bereit.

Eine solche scorebasierte Kennzahl ist von einer Klassifikationskennzahl bei einem festgelegten Schwellenwert zu unterscheiden.

Der Schwellenwert kann die gemessene Klassifikationsleistung verändern

Erzeugt ein Modell zunächst einen Score oder eine Wahrscheinlichkeit, kann die daraus abgeleitete Klasse von einem Schwellenwert abhängen.

Deshalb sollte bei schwellenwertabhängigen Kennzahlen dokumentiert werden, welcher Threshold der Auswertung zugrunde lag und ob dieser Threshold anhand von Trainings-, Validierungs- oder Testdaten gewählt wurde.

Regressionsmodelle benötigen andere Leistungsmaße

Für Regressionsaufgaben stellt scikit-learn andere Metriken bereit, beispielsweise Mean Absolute Error, Mean Squared Error, Root Mean Squared Error oder R².

Auch hier muss die verwendete Kennzahl zusammen mit Zielvariable, Einheit und Testdatenstand dokumentiert werden.

5. Unsicherheit und Reproduzierbarkeit

Ein einzelner Score ist eine Messung auf einem bestimmten Datenbestand

Ein Leistungswert ist zunächst ein technischer Befund für die konkrete Kombination aus Modell, Daten, Referenz, Metrik und Auswertungsverfahren.

Er ist nicht automatisch eine zeit- und populationsunabhängige Eigenschaft des Modells.

Stichprobengröße und Datenabdeckung begrenzen die Aussage

Eine Modellbewertung auf wenigen Beobachtungen besitzt eine andere Aussagebasis als eine Bewertung auf einem umfangreichen Testbestand.

Deshalb sollten mindestens Anzahl der geprüften Fälle, Datenabdeckung und gegebenenfalls relevante Teilgruppen dokumentiert werden.

Cross-Validation-Ergebnisse enthalten Variabilität

Wird ein Modell in mehreren Folds bewertet, entstehen mehrere Leistungswerte.

Neben dem Mittelwert kann deshalb auch die Streuung beziehungsweise Variation der Ergebnisse Teil des technischen Befunds sein.

Zufallszustände und Split-Definitionen gehören zur Reproduzierbarkeit

Randomisierte Datenaufteilungen oder stochastische Schätzverfahren können von Zufallszuständen abhängen.

Für eine reproduzierbare Auswertung sollten deshalb Split-Verfahren, konkrete Indizes oder geeignete Random-State-Angaben soweit verfügbar dokumentiert werden.

Eine berichtete Kennzahl braucht Provenienz

Wird beispielsweise in einem Projektbericht eine „Accuracy von 94 Prozent“ genannt, sollte nachvollziehbar sein:

• für welchen Modellstand,
• auf welchem Testdatenstand,
• mit welchen Referenzlabels,
• nach welcher Split-Regel,
• mit welcher Metrikdefinition,
• mit welcher Vorverarbeitung,
• mit welchem Schwellenwert,
• mit welchem Auswertungscode der Wert erzeugt wurde.

Reproduzierbare Evaluation benötigt mehr als den Modellcode

Selbst wenn das Modellartefakt und der Inferenzcode vorliegen, kann eine historische Leistungskennzahl ohne den damals verwendeten Testbestand oder die Referenzwerte möglicherweise nicht reproduziert werden.

Umgekehrt reicht ein Testdatensatz allein nicht, wenn der zugehörige Modellstand, die Vorverarbeitung oder die Metrikdefinition fehlen.

6. Aussagegrenzen und Dokumentation

Fehlende Split- oder Leakage-Nachweise begrenzen die Schlussfolgerung

Ist nicht mehr nachvollziehbar, wann Trainings- und Testdaten getrennt wurden, welche Transformationen vor dem Split erfolgt sind oder ob der Testbestand zur Modellwahl verwendet wurde, kann dies die technische Aussage über die Unabhängigkeit der Evaluation begrenzen.

Fehlende Dokumentation ist dabei nicht automatisch der Nachweis einer tatsächlich erfolgten Datenleckage.

Prüfcheck

Ist der Validierungsbefund belastbar?

• Ist der geprüfte Modell- und Softwarestand eindeutig?
• Sind Trainings-, Validierungs- und Testdaten methodisch getrennt?
• Wurde Datenleckage einschließlich Vorverarbeitung und Feature Selection geprüft?
• Passen Testbestand und Referenzlabels zur konkreten Untersuchungsfrage?
• Ist begründet, warum die verwendete Metrik die relevante Fehlerfrage beantwortet?
• Sind Variabilität, Fallzahlen und Unsicherheit sichtbar dokumentiert?
• Lassen sich Split, Pipeline, Zufallszustände und Auswertung reproduzieren?
• Bleibt ausdrücklich erkennbar, für welche Bedingungen die Schlussfolgerung nicht gilt?

Technische Modellvalidierung und rechtliche Bewertung sind zu trennen

Eine technische Untersuchung kann beispielsweise feststellen, ob eine Leistungskennzahl auf einem getrennten Testbestand reproduzierbar ist, ob Vorverarbeitung den Testbestand beeinflusst hat oder welche Metrik tatsächlich verwendet wurde.

Praktische Dokumentationsstruktur einer Modellvalidierung

Für eine technisch nachvollziehbare Modellbewertung können beispielsweise folgende Angaben dokumentiert werden:

• Modellstand und Modellartefakt,
• Trainingsdatenstand,
• Validierungsdatenstand,
• Testdatenstand,
• Zielvariable beziehungsweise Referenzlabels,
• Split-Verfahren und Split-Indizes,
• Gruppen- oder Zeitbezüge,
• Vorverarbeitung und Feature-Erzeugung,
• Leakage-Kontrollen,
• Hyperparameter- und Modellwahlverfahren,
• Metrikdefinition,
• Schwellenwert,
• Einzel- und Aggregatergebnisse,
• verwendeter Auswertungscode,
• Zufallszustände,
• Unsicherheiten und Aussagegrenzen.

Weiterführende Beiträge

Wie Trainings- und Testdaten hinsichtlich Zielpopulation, Stichprobe, Klassen- und Merkmalsverteilungen sowie Data Skew und Data Drift technisch untersucht werden können, erläutert Trainings- und Testdaten auf Repräsentativität prüfen: Stichprobe, Verteilung und Verteilungsverschiebung .

Wie der zu validierende Modellstand technisch bestimmt wird, erläutert Machine-Learning-Modell als Untersuchungsgegenstand: Modellversion, Parameter, Datenbasis und Laufzeitumgebung .

Wie Trainings-, Validierungs- und Testdaten nach Herkunft und Datenstand bestimmt werden, erläutert Daten als Untersuchungsgegenstand: Herkunft, Datenstand und Reproduzierbarkeit .

Zur Prüfung von Referenzlabels und anderen Qualitätsmerkmalen eines Testbestands siehe Datenqualität technisch prüfen: Vollständigkeit, Konsistenz, Genauigkeit und Aktualität .

Wie aus einer allgemeinen KI-Streitfrage eine technisch prüfbare Frage wird, erläutert Welche technische Fragestellung kann ein IT-Sachverständiger tatsächlich beantworten? .

Der allgemeine Quellen- und Dokumentationsstandard ist unter Quellen und Methodik beschrieben.

Kritische Gegenprüfung und methodische Aussagegrenze

Eine Validierungsmetrik ist Evidenz über einen definierten Datensatz und Prüfaufbau. Sie beantwortet nicht automatisch, ob das Modell für jeden Einsatzkontext geeignet oder freigegeben ist.

• Leakage und Split-Design: Auffällig gute Ergebnisse können aus Informationsleckage, Duplikaten oder einer unpassenden Datenaufteilung entstehen.
• Verteilungsbezug: Testdaten können historische Modellgüte zeigen, ohne die spätere Zielpopulation oder einen veränderten Produktionsbetrieb abzubilden.
• Metrik versus Entscheidung: Accuracy, F1, AUC, Calibration oder andere Kennzahlen beschreiben unterschiedliche Eigenschaften; die fachliche Einsatzentscheidung benötigt zusätzlich Fehlerfolgen, Alternativen und Akzeptanzkriterien.

Prüfregel: Eine fachliche Schlussfolgerung wird nicht stärker formuliert als die dokumentierte Untersuchungsgrundlage. Plausible Alternativerklärungen, widersprechende Evidenz, nicht untersuchte Bereiche und technische Detection Limits bleiben sichtbar Bestandteil der Aussagegrenze.

Eigene Fachliteratur und Veröffentlichungen

Die folgenden eigenen Arbeiten dienen der fachlichen Vertiefung und methodischen Einordnung. Sie ersetzen keine erforderlichen Primär-, Norm-, Hersteller- oder sonstigen unabhängigen Fachquellen. Unveröffentlichte Manuskripte, Entwürfe und Lehrunterlagen werden hier bewusst nicht als öffentliche Quellen ausgewiesen.

• Eigenes Fachbuch Kritisches Denken in Data Science mit Python – Vom Beobachten zur verantwortbaren Entscheidung
• Eigener veröffentlichter Fachbeitrag Verantwortungsvoller KI-Einsatz in der Praxis: Frameworks, Tools und regulatorische Einbettung in 15 Anwendungsfeldern

Müssen Sie die Validierung eines Machine-Learning-Modells technisch prüfen?

Ich untersuche Modellstand, Datenaufteilung, Testbestand, Leakage-Risiken, Metriken, Unsicherheit und Reproduzierbarkeit. Technischer Befund und Aussagegrenzen werden nachvollziehbar dokumentiert.

Data-Science-Gutachten ansehen