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

Warum eine hohe Modellkennzahl noch kein belastbarer Validitätsnachweis ist und welche Daten-, Split-, Metrik- und Verfahrensinformationen für eine nachvollziehbare Prüfung benötigt werden.

Von Mathias Ellmann Stand: 19.09.2026

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.

Kurzantwort

Eine technische Modellvalidierung sollte nicht bei einer Zahl wie „Accuracy 95 Prozent“ enden. Zunächst muss der Modellstand feststehen. Anschließend sind Testdatenstand, Referenzwerte, Datenaufteilung, Metrikdefinition, Vorverarbeitung, Hyperparameterwahl und mögliche Datenleckagen nachvollziehbar zu untersuchen.

Eine praktikable methodische Kette lautet: Modellstand → Testdatenstand → Referenz beziehungsweise Zielvariable → Split-Verfahren → Metrik → Leakage-Kontrolle → Messergebnis → Unsicherheit → Aussagegrenze.

1. 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:

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

2. 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:

3. 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:

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

4. 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.

5. 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.

6. 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.

7. 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.

8. Cross-Validation ersetzt nicht automatisch einen finalen Testbestand

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.

9. 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.

10. 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.

11. 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.

12. 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.

13. 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.

14. Vorverarbeitung kann Datenleckage erzeugen

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

Beispiele können sein:

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

15. 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.

16. 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.

17. 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.

18. 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.

19. 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 .

20. 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.

21. 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.

22. 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.

23. 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.

24. 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.

25. 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.

26. 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.

27. 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.

28. 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.

29. 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.

30. 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.

31. Eine berichtete Kennzahl braucht Provenienz

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

32. 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.

33. 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.

Methodische Grenze: Aus fehlender Nachvollziehbarkeit darf nicht ohne weitere Befunde auf einen konkreten Leakage-Vorgang geschlossen werden. Technisch feststellbar ist zunächst, welche Trennungs- und Verarbeitungsschritte belegt beziehungsweise nicht belegt werden können.

34. 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.

Rechtliche Grenze: Daraus folgt nicht automatisch, dass ein Modell vertraglich ausreichend, regulatorisch zulässig, haftungsrechtlich fehlerhaft oder für einen bestimmten rechtlichen Zweck geeignet ist. Solche Bewertungen sind vom technischen Validierungsbefund zu trennen.

35. Praktische Dokumentationsstruktur einer Modellvalidierung

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

Konstruiertes Beispiel

Für ein Klassifikationsmodell wird eine Accuracy von 96 Prozent berichtet.

Bei der technischen Rekonstruktion zeigt sich, dass zunächst auf dem vollständigen Datenbestand eine Merkmalsauswahl durchgeführt wurde. Erst danach wurden Trainings- und Testdaten getrennt.

Damit hatte die Feature-Auswahl bereits Informationen aus dem späteren Testbestand zur Verfügung. Die ursprüngliche Kennzahl kann deshalb nicht ohne weitere Prüfung als unabhängige Testleistung eingeordnet werden.

Für eine neue Untersuchung wird der dokumentierte Datenstand zuerst in Trainings- und Testdaten getrennt. Die Merkmalsauswahl wird ausschließlich auf dem Trainingsanteil gelernt. Anschließend wird das Modell auf dem unverändert zurückgehaltenen Testbestand bewertet.

Die beiden Kennzahlen beziehen sich damit auf unterschiedliche Evaluationsverfahren und dürfen nicht als methodisch identische Messungen behandelt werden.

Das Beispiel ist vollständig konstruiert und stellt kein reales Mandat und keine gerichtliche Beauftragung dar.

Quellen und fachliche Grundlage

  • Technische Primärquelle scikit-learn: Cross-validation: evaluating estimator performance . Technische Grundlage zur Trennung von Training, Validierung, Test, Overfitting und Cross-Validation. Geprüft am 19.09.2026.
  • Technische Primärquelle scikit-learn: Common pitfalls and recommended practices . Grundlage zur inkonsistenten Vorverarbeitung, Data Leakage, Trennung von Trainings- und Testdaten, fit, fit_transform und Pipelines. Geprüft am 19.09.2026.
  • Technische Primärquelle scikit-learn: Metrics and scoring: quantifying the quality of predictions . Technische Grundlage zu Klassifikations- und Regressionsmetriken sowie zur Scoring-Schnittstelle. Geprüft am 19.09.2026.
  • Technische Primärquelle scikit-learn: sklearn.metrics . Referenz zu konkreten Metriken wie Accuracy, Precision, Recall, F1, ROC AUC, Mean Absolute Error, Mean Squared Error, Root Mean Squared Error und R². Geprüft am 19.09.2026.
  • Eigene Fachliteratur Mathias Ellmann: Von Modellen zu Entscheidungen in Machine Learning mit Python . Fachlicher Hintergrund zu Training, Evaluation, Metriken, Modellvergleich und datenbasierten Entscheidungen.
  • Eigene fachliche Einordnung Die Kette Modellstand → Testdatenstand → Referenz → Split-Verfahren → Metrik → Leakage-Kontrolle → Messergebnis → Unsicherheit → Aussagegrenze dient hier als methodische Struktur für eine technische Modellvalidierung.

Weiterführende Beiträge

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.

IT-Sachverständiger Mathias Ellmann

Machine-Learning-Modell technisch validieren

Wenn Testdaten, Metriken, Overfitting, Cross-Validation oder mögliche Datenleckagen technisch untersucht werden sollen, können Modellstand, Datenbasis, Prüfmaßstab und Evaluationsverfahren zunächst fachlich eingegrenzt werden.

Data-Science- & KI-Gutachten ansehen