Prévenir les fuites d'informations entre les ensembles d'entraînement et de test dans les bibliothèques professionnelles d'images et de vidéos

Les fuites de données en apprentissage automatique se produisent lorsque des informations qui devraient être inaccessibles pendant le développement du modèle influencent l'entraînement, le prétraitement, la sélection du modèle ou l'évaluation. Elles peuvent donner l'impression que les performances de validation ou de test sont meilleures que les performances réelles sur le terrain, car la frontière d'évaluation a déjà été compromise.

Pour les équipes qui construisent des modèles à l'aide d'ensembles de données d'entraînement pour l'IA, l'une des formes de fuite les plus faciles à manquer est la contamination train-test via du contenu visuel lié. Des noms de fichiers et des identifiants d'actifs différents peuvent néanmoins correspondre à la même image (à une autre résolution, recadrée ou retouchée), à des images adjacentes issues d'un même enregistrement, ou à des observations partageant une même identité ou une même session de production censées rester invisibles.

La question pratique est celle de l'indépendance. Une partition de test n'est utile que si elle mesure le type de généralisation dont le système aura besoin après son déploiement, plutôt que de récompenser le modèle d'avoir vu, pendant l'entraînement, une version étroitement liée de la même source sous-jacente.

Un identifiant d'actif non vu ne signifie pas nécessairement une source visuelle non vue.

La fuite de données se produit lorsque des informations qui devraient rester exclues du développement du modèle influencent le modèle entraîné ou les décisions prises pour le construire. Le résultat est généralement un score d'évaluation qui ne reflète pas le contexte de déploiement prévu. Dans cet article, « data leakage » se réfère à un problème d'évaluation en apprentissage automatique, et non au sens de la cybersécurité désignant la divulgation non autorisée de données.

La contamination train-test se produit lorsque des informations d'entraînement passent dans les données de validation ou de test, ou inversement. Les enregistrements strictement dupliqués sont l'exemple le plus simple, mais le même problème peut surgir lorsque des échantillons censément différents partagent une source, une identité, une session, une séquence ou une autre dépendance que l'évaluation était censée isoler.

La fuite lors du prétraitement se produit lorsqu'une transformation est apprise en utilisant des informations provenant de données qui auraient dû rester mises à l'écart. Des exemples courants incluent l'ajustement des paramètres de normalisation, des imputeurs, la sélection de caractéristiques ou d'autres prétraitements appris sur l'ensemble du jeu de données avant l'évaluation au lieu de les ajuster uniquement sur les données d'entraînement.

La fuite de la cible se produit lorsque les entrées du modèle contiennent des informations sur l'issue qui ne seraient pas légitimement disponibles au moment de la prédiction.

L'objectif principal ici est la contamination train-test dans les ensembles de données d'images et de vidéos : maintenir les données d'évaluation réellement indépendantes des données d'entraînement tout en préservant les relations nécessaires pour vérifier cette séparation.

La fuite de données diffère également du surapprentissage ordinaire. Un modèle peut surapprendre un jeu d'entraînement parfaitement propre. La fuite compromet la frontière d'évaluation elle-même, si bien que la métrique de test rapportée peut devenir une estimation peu fiable de la généralisation. Pour une discussion plus large de ce problème dans le cadre de la science basée sur l'apprentissage automatique, voir Kapoor and Narayanan’s Leakage and the reproducibility crisis in machine learning based science.

Ceci est particulièrement important dans les jeux de données de vision par ordinateur, où l'unicité au niveau des fichiers ne garantit pas l'indépendance des observations. Les images et les vidéos peuvent être fortement liées même si chaque nom de fichier est différent.

Une banque d'images professionnelle peut contenir la même photographie à plusieurs résolutions, des dérivés édités ou non, des photographies prises à une fraction de seconde d'intervalle, ou de nombreux angles d'une même personne ou du même produit lors d'une séance.

La vidéo introduit encore plus de relations. Un enregistrement peut être fourni sous plusieurs montages, rapports d'aspect, codecs, résolutions ou sous forme de clips courts. Un processus d'extraction d'images par trame peut alors transformer un enregistrement en milliers d'images individuelles.

Ces enregistrements peuvent tous avoir des raisons légitimes d'exister séparément dans un catalogue de médias. Cela ne signifie pas qu'ils doivent automatiquement être traités comme des observations indépendantes dans une expérience d'apprentissage automatique.

Pour la conception de l'évaluation, la question pertinente est de savoir si une relation entre les éléments rend le test plus facile que le problème de déploiement que l'expérience prétend mesurer.

Une partition propre dépend de ce que "unseen" est censé signifier.

Il n'existe pas de clé de regroupement universellement correcte pour les jeux de données visuels.

Une partition aléatoire est raisonnable lorsque les échantillons peuvent véritablement être considérés comme des observations indépendantes de la distribution cible. Les problèmes apparaissent lorsque les données contiennent une dépendance qui est pertinente pour la conclusion de l'évaluation.

Choisissez d'abord l'unité de séparation à partir de l'énoncé de généralisation, puis appliquez la randomisation à cette unité si la randomisation est appropriée.

Les outils de validation prenant en compte les groupes mettent en œuvre le même principe de manière computationnelle. Par exemple, le GroupShuffleSplit de scikit-learn permet de s'assurer que les échantillons partageant une même étiquette de groupe restent ensemble, de sorte qu'un groupe soit retenu comme unité lors de la création des partitions train-test.

Il est utile de distinguer trois problèmes, car ils nécessitent des preuves différentes.

1. Doublons exacts

Il s'agit de fichiers identiques octet par octet. Un hachage cryptographique suffit généralement. Si deux fichiers produisent le même hachage robuste du contenu, ils peuvent être traités comme identiques pour les opérations ordinaires de déduplication d'un jeu de données. Cette vérification est peu coûteuse et devrait en général faire partie de l'ingestion ou du contrôle qualité du jeu de données. C'est aussi le cas le plus simple.

2. Variantes visuelles quasi-dupliquées

Il s'agit à peu près de la même observation, après des transformations telles que la recompression, le redimensionnement, un recadrage modeste, un ajustement des couleurs, une rotation ou une autre modification. Le hachage octet-à-octet ne les détectera pas car les octets sous-jacents ont changé. Le hachage perceptuel peut être utile ici car il encode des aspects de la structure de l'image dans une signature compacte qui peut être comparée en utilisant la distance de Hamming. Il ne faut pas le considérer comme un oracle parfait des doublons. Des modifications locales, des recadrages plus importants, des superpositions ou des transformations plus substantielles peuvent produire des faux négatifs, tandis qu'un seuil de distance trop permissif peut regrouper des images distinctes. Les seuils doivent être testés sur des paires représentatives de la collection réelle.

3. Échantillons apparentés ou dépendants

La catégorie la plus difficile n'est pas nécessairement constituée de contenus dupliqués. Deux photographies peuvent montrer la même personne sous des angles différents. Deux extraits peuvent provenir du même enregistrement mais contenir des moments différents. Deux photographies d'un produit peuvent être visuellement distinctes tout en partageant la même configuration de studio contrôlée. La recherche par embeddings peut aider à faire apparaître ces relations car des représentations apprises peuvent mettre en évidence des éléments visuellement ou sémantiquement liés que des hachages simples ne détectent pas. Mais la similarité n'est qu'une preuve. Un score élevé de similarité cosinus ne prouve pas à lui seul que deux enregistrements appartiennent au même groupe de fuite. La décision correcte dépend du modèle d'embedding, du seuil, des métadonnées disponibles, de la traçabilité de la source et, surtout, de l'objectif de l'évaluation.

Les actifs dérivés traversent la partition

Une photographie source peut exister sous forme de fichier en pleine résolution, ou sous forme de versions livrées redimensionnées, retouchées, recadrées ou réexportées.

La vidéo crée encore plus de relations dérivées : multiples encodages, recadrages verticaux et horizontaux, extraits, aperçus, versions tronquées et séquences d'images.

Si les dérivés reçoivent des identifiants d'actif indépendants et que la partition est effectuée au niveau des identifiants, différentes représentations d'une même source peuvent apparaître dans l'entraînement et le test.

Les sessions de capture traversent la partition

Une séance photo peut produire des dizaines ou des centaines d'images liées.

La nécessité de les conserver ensemble dépend de la tâche. Si l'évaluation est censée mesurer la généralisation à de nouvelles sessions, distribuer aléatoirement des images issues d'une même session crée un test irréaliste et trop facile. Il en va de même pour les prises répétées d'un tournage vidéo contrôlé.

Des images vidéo adjacentes traversent la partition

Les images vidéo sont corrélées temporellement par construction. Si l'on extrait les images de façon dense et qu'on les mélange indépendamment, des images séparées par une fraction de seconde peuvent se retrouver dans des partitions différentes. Pour les jeux de données au niveau des images, conservez la vidéo source, la position dans la séquence et l'horodatage au lieu de traiter chaque image extraite comme un exemple indépendant.

Des données liées arrivent via plusieurs collections

Les grandes bibliothèques multimédias sont souvent assemblées au fil du temps. Le même contenu sous-jacent peut parvenir par des acquisitions séparées ou exister à la fois dans une archive d'origine et dans une collection dérivée ultérieure. Si la filiation des sources est incomplète, une passe de déduplication par collection peut ne pas détecter la relation entre collections.

La recherche visuelle peut donc être utile sur l'ensemble du corpus de candidats, pas seulement au sein d'un fournisseur ou d'un dossier.

Les benchmarks publics chevauchent les corpus d'entraînement

Un problème distinct survient lorsque les éléments d'évaluation sont accessibles publiquement et qu'un modèle a été pré-entraîné sur de grands corpus externes.

Une étude des Workshops ICCV 2025, Data Leakage in Visual Datasets, a examiné les recouvrements au sein des jeux de données visuels et entre eux et a utilisé la recherche d'images pour montrer que tous les jeux de données analysés présentaient une forme de fuite de données ; les auteurs ont également constaté que cette fuite compromettait la fiabilité des évaluations en aval.

Ce type de contamination est plus difficile à exclure lorsque l'évaluateur n'a pas accès au corpus de pré-entraînement du modèle. Une séparation propre pour le fine-tuning ne prouve donc pas qu'un benchmark public a été absent du pré-entraînement.

Un flux de travail défendable commence par définir par rapport à quoi l'ensemble de test doit être indépendant, puis par préserver et auditer ces relations avant et après la séparation finale.

1. Définir l'objectif de l'évaluation

Consignez par écrit ce que l'on attend du modèle en matière de généralisation : nouveaux fichiers, sessions d'enregistrement, personnes, lieux, caméras, périodes temporelles ou un autre facteur. Cette décision détermine quelles relations doivent rester isolées.

2. Préserver la filiation des sources

Utilisez les informations de production existantes avant d'essayer de reconstruire chaque relation avec la vision par ordinateur. Les champs utiles peuvent inclure l'identifiant de la source originale, l'identifiant du dérivé, l'identifiant de tournage ou de session, l'identifiant d'enregistrement, le contributeur ou la source d'acquisition, l'identifiant du participant ou du sujet lorsque cela est approprié et légalement disponible, les horodatages et la position de la trame, ainsi que les relations d'édition ou d'export. La filiation est souvent une preuve de dépendance plus solide que la seule similarité visuelle.

3. Créer des empreintes pour la collection

Utilisez un audit en plusieurs étapes. Commencez par des hachages cryptographiques pour l'identité exacte. Ajoutez des hachages perceptuels là où des duplicatas transformés sont plausibles. Utilisez la recherche par embeddings lorsque la recherche de contenus quasi-doublons ou liés est nécessaire. À grande échelle, un index de plus proches voisins approximatifs peut récupérer des voisins candidats sans comparer exhaustivement chaque paire possible. Traitez la similarité comme un signal de filtrage, pas comme une décision automatique de regroupement.

4. Constituer des groupes avec prudence

Ne fusionnez pas automatiquement chaque asset connecté par une quelconque arête de similarité. Si l'image A est similaire à B et que B est similaire à C, cela ne prouve pas que A et C doivent partager un même groupe d'évaluation. Décidez quelles relations sont légitimement transitives. Combinez les métadonnées de source, les preuves visuelles et la revue manuelle pour les cas ambigus. Inspectez les grappes anormalement grandes car elles peuvent révéler un seuil trop permissif ou un enchaînement sémantique.

5. Attribuer des groupes, pas des enregistrements individuels

Une fois les groupes pertinents définis, affectez des groupes entiers à l'entraînement, à la validation ou au test. Le groupe peut être une famille de doublons exacts, un enregistrement source, un tournage, un participant, un lieu ou une autre unité spécifique à la tâche. La randomisation peut toujours être utilisée ; elle s'applique simplement à l'unité appropriée.

6. Maintenir le prétraitement appris à l'intérieur de la partition d'entraînement

Le regroupement et la détection de doublons fixes avant l'affectation des partitions ne doivent pas être confondus avec l'ajustement d'une transformation de modèle sur l'ensemble du jeu de données. Une fois les partitions d'évaluation établies, le prétraitement qui apprend des paramètres à partir des données doit être ajusté uniquement sur les données d'entraînement, puis appliqué aux données de validation ou de test selon le cas. L'ensemble de test protégé ne doit pas devenir un outil itératif de développement de modèle.

7. Geler et versionner l'ensemble d'évaluation

Une séparation doit être reproductible. Conservez un manifeste versionné contenant des identifiants d'assets stables, des identifiants de groupe, des enregistrements d'exclusion, des étiquettes de référence et l'affectation des partitions. Si la bibliothèque change, ne modifiez pas silencieusement le benchmark. Décidez si une nouvelle acquisition appartient à l'entraînement, à un futur rafraîchissement d'évaluation, ou à aucun des deux.

8. Auditer la frontière après la séparation

Après la création de la séparation, interrogez les assets de test contre l'index d'entraînement. Inspectez les correspondances inter-partitions les plus fortes et consignez pourquoi chaque candidat est ou n'est pas considéré comme problématique. L'audit est la preuve que la séparation a été vérifiée ; un score de similarité seul ne l'est pas.

Résultats d'audit utiles :

• correspondances exactes entre partitions

• candidats quasi-doublons

• relations de source commune

• identités partagées lorsque l'isolation des identités est requise

• séquence ou adjacence de trames

• tailles de grappes inattendues

• résultats de la revue manuelle

• limitations non résolues

Dans la pratique, le flux de travail combine généralement plusieurs méthodes plutôt que de les opposer. Un hachage d'octets est suffisamment peu coûteux pour être largement utilisé. Le hachage perceptuel offre une autre couche, également peu coûteuse. La recherche par embeddings peut repérer des relations que ces méthodes ne détectent pas. Les métadonnées de la source peuvent alors confirmer des relations que les pixels seuls ne permettent pas d'établir.

Les Jeux de données vidéo pour l'entraînement de l'IA nécessitent des contrôles supplémentaires car un seul enregistrement source peut produire de nombreux clips fortement corrélés ou des milliers d'images extraites.

Au minimum, conservez une hiérarchie telle que : production/session  - > enregistrement source  - > clip dérivé  - > image extraite.

Décidez ensuite à quel niveau se situe la frontière d'évaluation. Si plusieurs clips proviennent du même enregistrement et que l'objectif est la généralisation à des enregistrements non vus, tous ces clips doivent rester groupés.

Si des images sont extraites, conservez les horodatages et les identifiants source. Ne séparez pas de manière indépendante des images échantillonnées de façon dense, et n'interprétez pas celles mises de côté comme de véritables nouvelles observations vidéo.

Les personnes ou lieux récurrents nécessitent une décision distincte. Si l'on attend du modèle qu'il généralise à des individus inconnus, l'identité est un facteur de groupement. Si le produit déployé fonctionne explicitement sur un groupe de personnes connu, un recoupement d'identité peut être approprié. Encore une fois, la revendication de généralisation détermine le groupe.

Les conséquences ne sont pas hypothétiques. Dans l'article CVPR 2026 Data Leakage Detection and De-duplication in Large Scale Geospatial Image Datasets, des chercheurs étudiant le jeu de données AICrowd Mapping Challenge ont rapporté que près de 90 % (environ 250 000) des images d'entraînement avaient des copies identiques et qu'environ 56 000 des 60 000 images de validation étaient également présentes dans l'entraînement, soit une fuite entraînement-validation de 93 %.

Il s'agit d'un cas extrême, et non d'une estimation générale pour les jeux d'images. Son intérêt est de montrer comment un benchmark peut sembler structurellement plausible tout en contenant suffisamment de redondance pour rendre les résultats d'évaluation trompeurs.

Plus largement, l'étude de 2025 Data Leakage in Visual Datasets a trouvé des fuites dans tous les jeux de données visuels qu'elle a analysés, allant des cas sévères aux cas subtils, et a rapporté que ces fuites compromettaient la fiabilité des évaluations en aval.

Le même principe apparaît en dehors de la vision par ordinateur. L'article de Kapoor et Narayanan (2023) publié dans Patterns — Patterns article on leakage and reproducibility — parvient à la même conclusion méthodologique : lorsque plusieurs échantillons partagent un patient, une famille, un enregistrement, un intervalle temporel ou une autre dépendance pertinente pour le problème de prédiction, l'évaluation doit respecter cette dépendance plutôt que de supposer l'indépendance au niveau des lignes.

Avant la formation, le responsable de l'évaluation devrait être en mesure de répondre à ces questions :

Un bon audit ne se contente pas d'indiquer que la déduplication a été effectuée. Il précise quelle relation a été testée, comment elle a été détectée, quel seuil ou quelle règle de regroupement a été utilisée, et ce qui reste incertain.

Les acheteurs de jeux de données pour l'IA qui évaluent des images ou des données vidéo devraient demander davantage que le simple nombre d'éléments disponibles. Ils devraient demander ce que le fournisseur peut préserver, exclure, regrouper et documenter afin que la répartition finale d'évaluation corresponde à la revendication de généralisation prévue.

• Le fournisseur peut-il préserver les relations source/dérivées dans le manifeste de livraison ?
• Des identifiants de prise de vue, de session ou d'enregistrement sont-ils disponibles ?
• Les éléments d'entraînement connus peuvent-ils être fournis sous forme de liste d'exclusion ou d'inventaire de hachages ?
• Comment les doublons exacts et les quasi-doublons sont-ils détectés ?
• Comment les seuils de similarité ont-ils été validés ?
• Les images, clips, personnes, lieux ou séquences de production liés peuvent-ils être regroupés selon notre objectif d'évaluation ?
• Le fournisseur peut-il constituer ou produire une nouvelle collection d'évaluation mise à l'écart ?
• La répartition et les exclusions seront-elles livrées sous un manifeste versionné ?
• Quelles limitations empêchent le fournisseur d'affirmer que les données d'évaluation sont complètement inédites ?

Pour les projets d'IA visuelle, ces questions sont souvent plus informatives qu'un simple décompte brut des éléments.

La fuite entre entraînement et test n'est pas fondamentalement un problème de gestion de fichiers. C'est un problème de conception d'évaluation : la séparation doit protéger la relation que le modèle est censé généraliser au-delà de l'ensemble d'entraînement.

Un jeu de données peut contenir des noms de fichiers uniques, des identifiants uniques, et ne comporter aucun doublon identique au niveau des octets tout en produisant un test d'une facilité irréaliste. Inversement, deux échantillons visuellement similaires ne constituent pas automatiquement une fuite si l'information partagée fait partie de la distribution prévue pour le déploiement.

La question utile n'est donc pas simplement de savoir si deux éléments se ressemblent, mais de savoir si une information traverse une frontière d'évaluation que le modèle doit être capable de généraliser.

Définissez d'abord cette frontière. Préservez la filiation des sources. Utilisez des hachages et des méthodes de recherche pour trouver des relations que les métadonnées ne révèlent pas. Regroupez les échantillons en fonction de la véritable tâche d'évaluation. Conservez le prétraitement appris et la sélection du modèle à l'intérieur de la frontière d'entraînement. Ensuite, figez, versionnez et auditez l'ensemble de test obtenu.

Une séparation propre est une affirmation d'indépendance, pas une question d'identifiants de fichiers.