Vermeidung von Train-Test-Leakage in professionellen Bild- und Videobibliotheken

Datenleckage im maschinellen Lernen tritt auf, wenn Informationen, die während der Modellentwicklung nicht verfügbar sein sollten, das Training, die Vorverarbeitung, die Modellauswahl oder die Evaluation beeinflussen. Sie kann Validierungs- oder Testergebnisse stärker erscheinen lassen als die tatsächliche Leistung in der realen Welt, weil die Evaluationsgrundlage bereits kompromittiert wurde.

Für Teams, die mit KI-Trainingsdatensätzen arbeiten, ist eine der am leichtesten zu übersehenden Formen von Leckage die Kontamination zwischen Training und Test durch verwandte visuelle Inhalte. Unterschiedliche Dateinamen und Asset‑IDs können trotzdem dasselbe Bild in einer anderen Auflösung, einen Ausschnitt oder eine Bearbeitung derselben Quelle, benachbarte Frames einer Aufnahme oder Beobachtungen darstellen, die eine gemeinsame Identität oder Produktionssitzung teilen und eigentlich verborgen bleiben sollten.

Das praktische Problem ist die Unabhängigkeit. Ein Testsplit ist nur dann nützlich, wenn er die Art von Generalisierung misst, die das System nach dem Einsatz benötigen wird, statt das Modell dafür zu belohnen, dass es während des Trainings eine eng verwandte Version derselben zugrundeliegenden Quelle gesehen hat.

Eine unbekannte Asset‑ID bedeutet nicht zwangsläufig eine unbekannte visuelle Quelle.

Data leakage tritt auf, wenn Informationen, die außerhalb der Modellentwicklung bleiben sollten, das trainierte Modell oder die Entscheidungen zu dessen Erstellung beeinflussen. Das Ergebnis ist meist eine Bewertungskennzahl, die nicht die beabsichtigte Einsatzumgebung widerspiegelt. In diesem Artikel bezieht sich „data leakage“ auf ein Evaluationsproblem im maschinellen Lernen, nicht auf die Cybersecurity‑Bedeutung unautorisierter Datenoffenlegung.

Train-Test-Kontamination tritt auf, wenn Trainingsinformationen in Validierungs- oder Testdaten einfließen oder umgekehrt. Exakte Duplikate sind das einfachste Beispiel, doch dasselbe Problem kann entstehen, wenn scheinbar unterschiedliche Stichproben eine gemeinsame Quelle, Identität, Sitzung, Sequenz oder eine andere Abhängigkeit teilen, die bei der Evaluation eigentlich ausgeklammert werden sollte.

Leakage bei der Vorverarbeitung tritt auf, wenn eine Transformation unter Verwendung von Informationen aus den Daten gelernt wird, die eigentlich zurückgehalten werden sollten. Häufige Beispiele sind das Anpassen von Normalisierungsparametern, das Trainieren von Imputern, die Merkmalsauswahl oder andere gelernte Vorverarbeitungen am gesamten Datensatz vor der Evaluation statt nur an den Trainingsdaten.

Target-Leakage tritt auf, wenn Modelleingaben Informationen über das Ergebnis enthalten, die zum Zeitpunkt der Vorhersage nicht verfügbar wären.

Der Schwerpunkt hier liegt auf Train-Test-Kontamination in Bild- und Video-Datensätzen: Evaluationsdaten wirklich unabhängig von Trainingsdaten zu halten und gleichzeitig die Beziehungen zu bewahren, die nötig sind, um diese Grenze zu prüfen.

Data leakage unterscheidet sich auch vom gewöhnlichen Overfitting. Ein Modell kann an einem völlig sauberen Trainingssatz überfitten. Data leakage kompromittiert die Evaluationsgrenze selbst, sodass die berichtete Testmetrik zu einer unzuverlässigen Schätzung der Generalisierung werden kann. Für eine ausführlichere Diskussion dieses Problems im wissenschaftlichen Machine Learning siehe Kapoor and Narayanan’s Leakage and the reproducibility crisis in machine learning based science.

Das ist besonders wichtig bei Computer-Vision-Datensätzen, wo Einzigartigkeit auf Dateiebene keine unabhängigen Beobachtungen garantiert. Bilder und Videos können stark miteinander verwandt sein, selbst wenn jeder Dateiname unterschiedlich ist.

Eine professionelle Bildbibliothek kann dasselbe Foto in mehreren Auflösungen enthalten, bearbeitete und unbearbeitete Derivate, Fotos, die in Abständen von Bruchteilen einer Sekunde aufgenommen wurden, oder viele Ansichten derselben Person oder desselben Produkts aus einem Shooting.

Video fügt weitere Beziehungen hinzu. Eine Aufnahme kann als mehrere Schnitte, Seitenverhältnisse, Codecs, Auflösungen oder kurze Clips geliefert werden. Eine Frame-Extraktions-Pipeline kann dann eine Aufnahme in Tausende einzelner Bilder verwandeln.

All diese Aufzeichnungen können legitime Gründe dafür haben, getrennt in einem Mediakatalog zu existieren. Das bedeutet nicht, dass sie automatisch als unabhängige Beobachtungen in einem Machine-Learning-Experiment behandelt werden sollten.

Für das Evaluationsdesign ist die relevante Frage, ob eine Beziehung zwischen Assets den Test einfacher macht als das Einsatzproblem, das mit dem Experiment gemessen werden soll.

Ein sauberer Split hängt davon ab, was „unseen“ bedeuten soll.

Es gibt keinen universell richtigen Gruppierungsschlüssel für visuelle Datensätze.

Ein zufälliger Split ist sinnvoll, wenn Stichproben wirklich als unabhängige Beobachtungen aus der Zielverteilung behandelt werden können. Probleme beginnen, wenn die Daten eine Abhängigkeit enthalten, die für die Evaluationsaussage relevant ist.

Wählen Sie zunächst die Aufteilungseinheit entsprechend Ihrer Generalisierungsannahme und führen Sie die Randomisierung anschließend auf dieser Einheit durch, falls eine Randomisierung angebracht ist.

Gruppenbezogene Validierungswerkzeuge setzen dasselbe Prinzip rechnerisch um. Zum Beispiel erlaubt die GroupShuffleSplit-Implementierung von scikit-learn, dass Stichproben ein gemeinsames Gruppenlabel haben, sodass eine Gruppe beim Erstellen von Train-Test-Partitionen als Einheit zurückgehalten wird.

Es ist nützlich, drei Probleme zu unterscheiden, da sie unterschiedliche Nachweise erfordern.

1. Exakte Duplikate

Dabei handelt es sich um byte‑identische Dateien. Ein kryptografischer Hash ist in der Regel ausreichend. Wenn zwei Dateien denselben starken Inhalts‑Hash erzeugen, können sie für gewöhnliche Datensatz‑Deduplizierungszwecke als identisch behandelt werden. Diese Prüfung ist kostengünstig und sollte generell Teil der Ingestion oder der QA des Datensatzes sein. Es ist zudem der einfachste Fall.

2. Nahe Duplikate (visuelle Varianten)

Hier handelt es sich größtenteils um dieselbe Aufnahme nach Transformationen wie Rekompression, Größenänderung, moderatem Zuschnitt, Farbkorrektur, Rotation oder einer anderen Bearbeitung. Byte‑Hashing wird diese nicht finden, weil sich die zugrunde liegenden Bytes geändert haben. Perzeptuelles Hashing kann hier nützlich sein, da es Aspekte der Bildstruktur in einer kompakten Signatur kodiert, die sich mittels Hamming‑Distanz vergleichen lassen. Es sollte nicht als perfektes Duplikaterkennungsorakel betrachtet werden. Lokale Bearbeitungen, größere Zuschnitte, Überlagerungen oder umfassendere Transformationen können zu falschnegativen Ergebnissen führen, während ein zu großzügiger Distanzschwellenwert unterschiedliche Bilder zusammenfassen kann. Schwellenwerte sollten anhand repräsentativer Paare aus der tatsächlichen Sammlung getestet werden.

3. Verwandte oder abhängige Samples

Die schwierigste Kategorie muss nicht zwangsläufig doppelten Inhalt bedeuten. Zwei Fotografien können dieselbe Person aus unterschiedlichen Blickwinkeln zeigen. Zwei Clips können aus derselben Aufnahme stammen, aber unterschiedliche Momente enthalten. Zwei Produktfotos können visuell unterschiedlich sein und dennoch dieselbe kontrollierte Studioaufstellung teilen. Embedding‑Retrieval kann helfen, diese Beziehungen sichtbar zu machen, weil gelernte Repräsentationen visuell oder semantisch verwandte Assets abrufen können, die einfache Hashes übersehen. Ähnlichkeit ist jedoch nur ein Indiz. Ein hoher Kosinus‑Ähnlichkeitswert beweist für sich genommen nicht, dass zwei Einträge zu derselben Leakage‑Gruppe gehören. Die richtige Entscheidung hängt vom Embedding‑Modell, dem Schwellenwert, den verfügbaren Metadaten, den Herkunftsangaben und vor allem vom Evaluationsziel ab.

Abgeleitete Assets überschreiten die Aufteilung

Ein Originalfoto kann als Datei in voller Auflösung, als verkleinerte Lieferdatei, als bearbeitete Version, als Ausschnitt oder als Re-Export vorliegen.

Video erzeugt noch mehr Ableitungsbeziehungen: mehrere Encodes, vertikale und horizontale Zuschnitte, Auszüge, Vorschauen, gekürzte Versionen und Bildsequenzen.

Wenn Ableitungen eigene Asset-IDs erhalten und die Aufteilung auf ID-Ebene erfolgt, können unterschiedliche Darstellungen einer Quelle sowohl im Training als auch im Test auftauchen.

Aufnahmesitzungen überschreiten die Aufteilung

Ein Fotoshooting kann Dutzende oder Hunderte zusammenhängender Aufnahmen erzeugen.

Ob sie zusammenbleiben müssen, hängt von der Aufgabe ab. Wenn die Evaluation die Generalisierung auf neue Sitzungen messen soll, führt das zufällige Verteilen von Aufnahmen einer Sitzung zu einem unrealistisch einfachen Test. Gleiches gilt für wiederholte Takes bei einem kontrollierten Videodreh.

Benachbarte Videoframes überschreiten die Aufteilung

Videoframes sind per Konstruktion zeitlich korreliert. Wenn Frames dicht extrahiert und dann unabhängig voneinander gemischt werden, können Frames, die nur Bruchteile einer Sekunde auseinanderliegen, in unterschiedlichen Partitionen landen. Bei framebasierten Datensätzen sollten das Quellvideo, die Sequenzposition und der Zeitstempel erhalten bleiben, anstatt jedes extrahierte Bild als unabhängiges Beispiel zu behandeln.

Verwandte Daten stammen aus mehreren Sammlungen

Große Mediatheken werden oft im Laufe der Zeit zusammengestellt. Derselbe zugrunde liegende Inhalt kann durch separate Erwerbungen eintreffen oder sowohl im Originalarchiv als auch in einer späteren Derivatsammlung existieren. Wenn die Quellherkunft unvollständig ist, kann ein deduplizierender Durchlauf pro Sammlung die übergreifende Beziehung zwischen Sammlungen nicht entdecken.

Visuelle Suche kann daher über den gesamten Kandidatenkorpus nützlich sein, nicht nur innerhalb eines einzelnen Anbieters oder Ordners.

Öffentliche Benchmarks überschneiden sich mit Trainingskorpora

Ein separates Problem entsteht, wenn Evaluations-Assets öffentlich verfügbar sind und ein Modell auf großen externen Korpora vortrainiert wurde.

Eine Studie der ICCV-Workshops 2025, Data Leakage in Visual Datasets, untersuchte Überschneidungen innerhalb und zwischen visuellen Datensätzen und nutzte Bildretrieval, um zu zeigen, dass alle analysierten Datensätze irgendeine Form von Leckage aufwiesen; die Autoren stellten außerdem fest, dass diese Leckagen die Zuverlässigkeit nachgelagerter Bewertungen beeinträchtigten.

Diese Art von Kontamination lässt sich schwerer ausschließen, wenn der Bewertende keinen Zugriff auf das Pretraining-Korpus eines Modells hat. Eine saubere Fine-Tuning-Aufteilung beweist daher nicht, dass ein öffentliches Benchmark während des Pretrainings unbekannt war.

Ein verteidigungsfähiger Workflow beginnt damit, festzulegen, wovon das Testset unabhängig sein soll, und dann diese Beziehungen vor und nach dem finalen Split zu erhalten und zu prüfen.

1. Definieren Sie die Evaluationsaussage

Schreiben Sie auf, worauf das Modell verallgemeinern soll: neue Dateien, Aufnahmesitzungen, Personen, Orte, Kameras, Zeiträume oder einen anderen Faktor. Diese Entscheidung bestimmt, welche Beziehungen isoliert bleiben müssen.

2. Herkunftslinien bewahren

Verwenden Sie vorhandene Produktionsinformationen, bevor Sie versuchen, jede Beziehung mit Computer Vision zu rekonstruieren. Nützliche Felder können die ursprüngliche Quellen-ID, die ID des Derivats, Shoot- oder Session-ID, Aufnahme-ID, Beitragender oder Erwerbsquelle, Teilnehmer- oder Subjekt-ID, wo angemessen und rechtlich verfügbar, Zeitstempel und Frame-Position sowie Bearbeitungs- oder Exportbeziehungen umfassen. Herkunftsinformationen sind oft stärkere Belege für Abhängigkeiten als alleinige visuelle Ähnlichkeit.

3. Die Sammlung fingerprinten

Verwenden Sie ein gestuftes Audit. Beginnen Sie mit kryptografischen Hashes zur Identifizierung exakter Übereinstimmungen. Ergänzen Sie perzeptuelle Hashes, wenn transformierte Duplikate plausibel sind. Verwenden Sie Embedding-Retrieval, wenn eine Suche nach nahezu identischen oder verwandten Inhalten nötig ist. Bei großem Umfang kann ein Approximate Nearest Neighbor-Index Kandidaten abrufen, ohne jedes mögliche Paar exhaustiv zu vergleichen. Betrachten Sie Ähnlichkeit als Screening-Signal, nicht als automatische Gruppierungsentscheidung.

4. Gruppen konservativ bilden

Führen Sie nicht automatisch alle Assets zusammen, die über irgendeine Ähnlichkeitsverbindung verbunden sind. Wenn Bild A ähnlich zu B ist und B ähnlich zu C, beweist das nicht, dass A und C dieselbe Evaluationsgruppe teilen sollten. Entscheiden Sie, welche Beziehungen legitim transitiv sind. Kombinieren Sie Quell-Metadaten, visuelle Belege und manuelle Überprüfung bei mehrdeutigen Fällen. Ungewöhnlich große Cluster sollten inspiziert werden, da sie auf eine zu nachgiebige Schwelle oder auf semantische Kettenbildung hindeuten können.

5. Gruppen zuweisen, nicht einzelne Datensätze

Sobald die relevanten Gruppen definiert sind, weisen Sie ganze Gruppen dem Training, der Validierung oder dem Test zu. Die Gruppe kann eine Familie exakter Duplikate, eine Quellaufnahme, ein Shoot, ein Teilnehmer, ein Ort oder eine andere aufgabenspezifische Einheit sein. Randomisierung kann weiterhin verwendet werden; sie erfolgt einfach auf der entsprechenden Einheitsebene.

6. Gelernte Vorverarbeitung innerhalb der Trainingsgrenze belassen

Gruppierung und feste Duplikaterkennung vor der Split-Zuordnung sollten nicht mit dem Anpassen einer Modelltransformation auf das gesamte Datensatz verwechselt werden. Sobald die Evaluationspartitionen festgelegt sind, sollte Vorverarbeitung, die Parameter aus Daten lernt, nur mit Trainingsdaten angepasst und anschließend auf Validierungs- oder Testdaten angewandt werden, sofern zutreffend. Das geschützte Testset darf nicht zu einem iterativen Modell-Entwicklungswerkzeug werden.

7. Das Evaluationsset einfrieren und versionieren

Ein Split sollte reproduzierbar sein. Halten Sie ein versioniertes Manifest mit stabilen Asset-IDs, Gruppen-IDs, Ausschlussaufzeichnungen, Referenzlabels und der Split-Zuordnung. Wenn sich die Bibliothek ändert, ändern Sie das Benchmark nicht stillschweigend. Entscheiden Sie, ob eine neue Akquisition in das Training, in eine zukünftige Evaluationsaktualisierung oder in keines von beiden gehört.

8. Die Grenze nach dem Split prüfen

Nachdem der Split erstellt wurde, vergleichen Sie Test-Assets mit dem Trainingsindex. Untersuchen Sie die stärksten Cross-Split-Übereinstimmungen und dokumentieren Sie, warum jeder Kandidat als problematisch oder unproblematisch angesehen wird. Das Audit ist der Nachweis, dass der Split geprüft wurde; ein Ähnlichkeitswert allein ist es nicht.

Nützliche Auditergebnisse sind:

• exakte Cross-Split-Übereinstimmungen

• Kandidaten für Nahe-Duplikate

• gemeinsame Quellenbeziehungen

• geteilte Identitäten, wo Identitätsisolation erforderlich ist

• Sequenz- oder Frame-Nachbarschaft

• unerwartete Clustergrößen

• Ergebnisse manueller Überprüfungen

• ungelöste Einschränkungen

In der Praxis ist der Workflow in der Regel eine Kombination der Methoden, nicht ein Wettbewerb zwischen ihnen. Ein Byte-Hash ist günstig genug, um ihn breit einzusetzen. Perceptual Hashing bietet eine weitere, kostengünstige Kandidatenebene. Embedding-Retrieval kann Beziehungen finden, die diese Methoden übersehen. Quellenmetadaten können dann Beziehungen bestätigen, die allein anhand von Pixeln nicht festgestellt werden können.

Video-Datensätze für das KI-Training benötigen zusätzliche Kontrollen, weil eine einzelne Aufnahme viele stark korrelierte Clips oder tausende extrahierter Frames erzeugen kann.

Mindestens sollte eine Hierarchie wie folgt beibehalten werden: production/session  - > Quellaufnahme  - > abgeleiteter Clip  - > extrahierter Frame.

Entscheiden Sie dann, auf welcher Ebene die Evaluierungsgrenze liegt. Wenn mehrere Clips aus derselben Aufnahme stammen und das Ziel die Generalisierung auf ungesehene Aufnahmen ist, sollten alle diese Clips zusammengehalten werden.

Wenn Frames extrahiert werden, bewahren Sie Zeitstempel und Quell‑IDs. Teilen Sie zeitlich eng beieinanderliegende Frames nicht auf und werten Sie die zurückgehaltenen Frames nicht als völlig neue Videoaufnahmen.

Wiederkehrende Personen oder Orte erfordern eine separate Entscheidung. Wenn vom Modell erwartet wird, dass es auf unbekannte Individuen generalisiert, ist Identität ein Gruppierungsfaktor. Wenn das eingesetzte Produkt explizit mit einer bekannten Gruppe von Personen arbeitet, kann Identitätsüberschneidung angemessen sein. Auch hier bestimmt die Generalisierungsbehauptung die Gruppierung.

Die Folgen sind nicht hypothetisch. Im CVPR-2026-Paper Data Leakage Detection and De-duplication in Large Scale Geospatial Image Datasets, berichteten Forschende, die das AICrowd Mapping Challenge-Dataset untersuchten, dass fast 90 % (etwa 250.000) der Trainingsbilder identische Kopien aufwiesen und dass ungefähr 56.000 von 60.000 Validierungsbildern ebenfalls im Training vorhanden waren, was einer Leckage von 93 % zwischen Training und Validierung entspricht.

Das ist ein Extremfall, keine allgemeine Schätzung für Bilddatensätze. Sein Wert liegt darin, zu zeigen, wie ein Benchmark strukturell plausibel wirken kann, während er genügend Redundanz enthält, um Auswertungsergebnisse irreführend zu machen.

Breiter gefasst stellte die Studie aus dem Jahr 2025 Data Leakage in Visual Datasets Leckagen in allen untersuchten visuellen Datensätzen fest und berichtete, dass diese Leckagen, von schwerwiegenden bis zu subtilen Fällen, die Zuverlässigkeit nachgelagerter Evaluierungen beeinträchtigten.

Dasselbe Prinzip zeigt sich außerhalb der Computer Vision. Das 2023 von Kapoor und Narayanan in Patterns veröffentlichte Paper Patterns article on leakage and reproducibility kommt zur gleichen methodischen Schlussfolgerung: Wenn mehrere Stichproben einen Patienten, eine Familie, eine Aufnahme, einen Zeitblock oder eine andere Abhängigkeit teilen, die für das Vorhersageproblem relevant ist, sollte die Evaluierung diese Abhängigkeit berücksichtigen, statt Unabhängigkeit auf Zeilenebene anzunehmen.

Vor dem Training sollte der/die Verantwortliche für die Evaluation diese Fragen beantworten können:

Ein gutes Audit sagt nicht nur, dass eine Deduplizierung durchgeführt wurde. Es beschreibt, welche Beziehung getestet wurde, wie sie erkannt wurde, welcher Schwellenwert oder welche Gruppierungsregel verwendet wurde und was ungewiss bleibt.

Käufer von AI-Datensätzen, die Bild- oder Videodaten bewerten, sollten mehr fragen als nur nach der Anzahl verfügbarer Assets. Sie sollten fragen, was der Anbieter bewahren, ausschließen, gruppieren und dokumentieren kann, damit die endgültige Evaluierungsaufteilung der beabsichtigten Generalisierungsbehauptung entspricht.

• Können Quellen- und Derivatbeziehungen im Liefermanifest erhalten bleiben?
• Sind Shoot-, Session- oder Aufnahmeidentifikatoren verfügbar?
• Können bekannte Trainings-Assets als Ausschlussliste oder Hash-Inventar bereitgestellt werden?
• Wie werden exakte und nahezu identische Duplikatkandidaten erkannt?
• Wie wurden Ähnlichkeitsschwellen validiert?
• Können verwandte Frames, Clips, Personen, Orte oder Produktionssequenzen entsprechend unserem Evaluationsziel gruppiert werden?
• Kann der Anbieter eine neue, zurückgehaltene Evaluationssammlung erstellen oder bereitstellen?
• Wird die Aufteilung und die Ausschlüsse in einem versionierten Manifest geliefert?

• Welche Einschränkungen hindern den Anbieter daran, zu behaupten, dass die Evaluationsdaten vollständig unbekannt sind?

Für visuelle AI-Projekte sind diese Fragen oft aussagekräftiger als eine bloße Angabe der Asset-Anzahl.

Train-Test-Leakage ist nicht grundsätzlich ein Datei-Management-Problem. Es ist ein Evaluations-Design-Problem: Der Split muss die Beziehung schützen, über die das Modell hinweg generalisieren soll.

Ein Datensatz kann eindeutige Dateinamen, eindeutige IDs und keine byteidentischen Duplikate enthalten und trotzdem einen unrealistisch einfachen Test erzeugen. Umgekehrt bedeuten zwei visuell ähnliche Samples nicht automatisch Leakage, wenn die geteilte Information Teil der beabsichtigten Einsatzverteilung ist.

Die nützliche Frage ist daher nicht einfach, ob zwei Assets ähnlich aussehen. Vielmehr lautet die Frage, ob Informationen eine Evaluationsgrenze überschreiten, über die das Modell hinweg generalisieren soll.

Definieren Sie diese Grenze zuerst. Bewahren Sie die Herkunftslinie. Verwenden Sie Hashes und Retrieval-Methoden, um Beziehungen zu finden, die von Metadaten übersehen werden. Gruppieren Sie Proben entsprechend dem tatsächlichen Evaluationsanspruch. Halten Sie erlernte Vorverarbeitung und Modellselektion innerhalb der Trainingsgrenze. Frieren Sie dann das resultierende Testset ein, versionieren Sie es und auditieren Sie es.

Ein sauberer Split ist eine Aussage über Unabhängigkeit, nicht über Datei-IDs.