Construire un pipeline d'étiquetage de données IA pour l'imagerie de défense

Un modèle d'IA de défense ne vaut que par les données sur lesquelles il a été entraîné. Cette phrase est répétée assez souvent pour avoir perdu son poids opérationnel – mais en pratique, la plupart des déploiements d'IA de défense ratés ne remontent pas à des choix d'architecture de modèle mais à des problèmes de qualité d'étiquetage invisibles au moment de l'entraînement et catastrophiques au moment de l'inférence. Construire un pipeline rigoureux d'étiquetage de données pour l'imagerie de défense est un problème d'ingénierie des systèmes, pas un problème de saisie de données. Cela exige des outils d'annotation, la gestion de la classification, l'automatisation du contrôle qualité, des boucles d'apprentissage actif et une discipline de gouvernance des jeux de données capable de survivre au renouvellement du personnel, aux audits de classification et aux cycles itératifs de développement du modèle.

Cet article parcourt chaque étape d'un pipeline d'étiquetage d'IA de défense en production : ingestion et tri, définition du schéma, conception du flux d'annotation, mesure de l'accord inter-annotateurs, intégration de l'apprentissage actif et les contrôles qualité automatisés qui font office de barrière pour un jeu de données avant son approbation pour l'entraînement du modèle. Le cas échéant, il se connecte aux préoccupations amont de la génération de données synthétiques et aux préoccupations aval de la validation du modèle – le pipeline d'étiquetage est le pont entre ces deux disciplines.

1. ingestion et tri de l'imagerie

Le pipeline commence avant qu'un annotateur humain ne voie une image. L'imagerie brute provient de sources hétérogènes : flux de capteurs ISR, moteurs de rendu de simulation, événements de collecte sur le terrain et jeux de données aériens en domaine ouvert approuvés utilisés pour compléter les collectes classifiées. Chaque source a des caractéristiques de qualité différentes, et les traiter uniformément sans une étape de tri produit un jeu de données étiqueté avec une variance de qualité cachée.

Le tri automatisé couvre quatre catégories de rejet. Fichiers corrompus ou illisibles – images qui échouent au décodage, fichiers tronqués ou fichiers dont les métadonnées rapportent des dimensions incohérentes avec le tampon de pixels. Trames en double – doublons exacts identifiés par hachage de contenu, et quasi-doublons identifiés par hachage perceptuel (pHash avec un seuil de distance de Hamming configurable). Les doublons dans un ensemble d'entraînement gonflent la taille apparente du jeu de données, amènent le modèle à mémoriser des trames spécifiques au lieu de généraliser, et introduisent des fuites de données entre les jeux d'entraînement et de validation si le doublon apparaît des deux côtés de la partition. Échecs de qualité – images sous un score de netteté minimal (variance laplacienne sous un seuil), images avec une sur- ou sous-exposition extrême (écrêtage d'histogramme au-dessus de 5 % des pixels) et images avec des artefacts de capteur (pixels bloqués, bandes, vignettage au-delà d'un seuil calibré). Images sources hors sujet ou mal étiquetées – un filtre qui applique un classifieur binaire léger pour rejeter les images qui n'appartiennent clairement à aucune classe cible du schéma (par ex. des photos d'équipement de station au sol accidentellement ingérées dans un jeu de détection de véhicules en perspective UAV).

L'attribution des marquages de classification se fait à l'ingestion, pas au moment de l'annotation. Chaque image qui entre dans le pipeline doit se voir attribuer un niveau de classification avant d'entrer dans une quelconque file. Le pipeline applique le contrôle d'accès à ce niveau : les annotateurs à habilitation inférieure ne peuvent pas se voir attribuer d'images au-dessus de leur niveau d'habilitation, et toute tentative en ce sens doit être journalisée et signalée par une alerte. Il s'agit d'une contrainte système stricte, pas procédurale – la plateforme d'annotation doit l'appliquer, sans se reposer sur la vérification manuelle des gestionnaires de file.

2. conception et versionnage du schéma d'annotation

Le schéma d'annotation est le contrat entre l'équipe d'étiquetage et le pipeline d'entraînement du modèle. Un schéma ambigu, insuffisamment spécifié ou modifié en cours de projet produit un jeu de données où différents lots ont été étiquetés sous des règles différentes – une incohérence qui dégrade la généralisation du modèle de façons presque impossibles à diagnostiquer après coup.

Un schéma d'annotation de qualité production pour l'imagerie de défense spécifie :

La taxonomie des classes. Chaque classe cible, organisée hiérarchiquement si le modèle sera utilisé à plusieurs niveaux de spécificité (par ex. véhicule → véhicule à roues → véhicule léger à roues → variante HMMWV). Chaque classe a une définition, un ensemble d'exemples positifs, un ensemble d'exemples de négatifs durs (objets similaires qui ne devraient PAS recevoir cette étiquette) et des règles explicites pour les cas ambigus. Les cas ambigus sont la partie la plus importante du schéma – ce sont les cas où deux annotateurs raisonnables seraient en désaccord, et résoudre cette ambiguïté par écrit avant le début de l'annotation est de plusieurs ordres de grandeur moins coûteux que d'arbitrer les désaccords résultants dans les données étiquetées.

Le type de géométrie et les contraintes. Si chaque classe est étiquetée avec des boîtes englobantes alignées sur les axes, des boîtes englobantes pivotées (importantes pour l'imagerie aérienne où les véhicules ne sont pas toujours alignés sur les axes), des polygones ou des points-clés. Les contraintes sur la taille d'annotation minimale (par ex. aucune boîte englobante inférieure à 10×10 pixels n'est étiquetée, pour éviter d'annoter des cibles sous-résolution qu'un détecteur ne peut pas localiser de façon réaliste).

Les champs d'attributs. Des attributs par annotation au-delà de l'étiquette de classe : niveau d'occlusion (aucune / partielle / forte), troncature (si l'objet est coupé au bord de l'image), confiance (certitude auto-évaluée par l'annotateur) et tout champ propre au domaine (cap d'orientation du véhicule, type de camouflage, état d'activité).

Les versions du schéma doivent être suivies dans un dépôt de documents, chaque lot étiqueté étant lié à la version du schéma sous laquelle il a été produit. Lorsque le schéma change – une classe se divise en deux, un cas ambigu est résolu différemment, une contrainte de géométrie est resserrée – une montée de version du schéma est requise, et tous les lots précédemment étiquetés qui relèvent des règles modifiées doivent être signalés pour réaudit. Mélanger des annotations de différentes versions de schéma dans un seul jeu de données d'entraînement sans réconciliation explicite est l'une des sources les plus courantes de bruit d'étiquette dans les programmes d'IA de défense de longue durée.

3. flux d'annotation et accord inter-annotateurs

Le flux d'annotation est un problème de gestion de file. Les images circulent du système de tri vers une file d'annotation, les annotateurs tirent des tâches de la file, les annotations terminées sont écrites dans le magasin du jeu de données, et un sous-ensemble des annotations terminées est acheminé vers un second annotateur pour la mesure de l'accord inter-annotateurs (IAA).

La mesure de l'IAA est le signal de qualité le plus important du pipeline. Pour les tâches de classification, le kappa de Cohen est la métrique standard – il mesure l'accord au-delà du hasard, donc il est insensible au déséquilibre des classes d'une façon dont le pourcentage d'accord brut ne l'est pas. Pour les tâches de boîtes englobantes, l'intersection sur union moyenne (mIoU) entre paires d'annotateurs sur la même image est la norme – un seuil de 0,7 mIoU est un minimum raisonnable pour des classes d'objets bien définies, mais les classes aux frontières intrinsèquement ambiguës (feuillage, emplacements partiellement déconstruits) peuvent fonctionner à des seuils inférieurs avec une justification explicite.

La mesure de l'IAA devrait couvrir 10 à 15 % de chaque lot, sélectionnés aléatoirement. Les résultats devraient être affichés dans un tableau de bord qui montre l'IAA par annotateur, par classe et par section de schéma. Un faible IAA pour une classe spécifique est un signal que le schéma de cette classe a besoin de clarification, pas que les annotateurs sont peu performants. Un faible IAA pour un annotateur spécifique est un signal pour une calibration ciblée. Le pipeline devrait déclencher automatiquement une étape d'arbitrage lorsque l'IAA d'une classe tombe sous le seuil défini : la paire d'annotations en désaccord est acheminée vers un annotateur senior qui produit l'étiquette de référence. Les images arbitrées alimentent ensuite l'ensemble de calibration des annotateurs utilisé lors de l'intégration pour les lots suivants.

Outils pour les plateformes d'annotation de défense

Les plateformes d'annotation de défense ont des exigences que les outils d'étiquetage grand public ne couvrent pas : déploiement sur site ou en réseau isolé (pas d'envoi d'imagerie classifiée vers des services d'annotation cloud), contrôle d'accès au niveau de classification par partition de jeu de données, journalisation d'audit de chaque action d'annotateur et conformité ITAR/export pour les programmes multinationaux. CVAT (Computer Vision Annotation Tool) est une plateforme open source largement déployée qui prend en charge l'hébergement sur site et dispose d'une communauté d'intégration de défense active. Label Studio est une autre option dotée d'une architecture de plugins plus flexible. Pour les programmes nécessitant une certification formelle de l'environnement d'étiquetage, des plateformes spécialisées axées sur la défense existent et sont disponibles via des canaux d'approvisionnement spécifiques à la défense.

4. intégration de l'apprentissage actif

Les jeux de données de défense sont généralement volumineux en nombre brut d'images mais coûteux à étiqueter. Un événement de collecte sur le terrain pour un programme ISR peut produire des centaines de milliers de trames, dont seule une fraction contient les classes cibles d'intérêt. Étiqueter l'ensemble du pool uniformément est un gaspillage – une part substantielle de l'imagerie sera non informative pour l'entraînement (trames d'arrière-plan vides, scènes en double, conditions déjà bien représentées dans l'ensemble étiqueté existant). L'apprentissage actif dirige l'effort des annotateurs vers les images que le modèle trouve les plus incertaines, réduisant le budget total d'annotation requis pour atteindre un niveau de performance cible du modèle.

La boucle standard d'apprentissage actif pour un pipeline d'étiquetage d'IA de défense se déroule comme suit. Un ensemble de départ initial (typiquement 1 000 à 5 000 images étiquetées, sélectionnées par échantillonnage stratifié à travers les classes et les conditions) est utilisé pour entraîner un modèle de référence. Le modèle entraîné est ensuite exécuté en mode inférence sur l'ensemble du pool non étiqueté. Chaque image non étiquetée se voit attribuer un score d'incertitude : pour les têtes de classification, l'entropie de prédiction (l'entropie de Shannon de la distribution softmax) ou la moindre confiance (un moins la probabilité de la classe la plus prédite) sont les choix les plus courants. Pour les modèles de détection, une approximation courante consiste à agréger les scores de confiance par détection sur l'image – les images où le détecteur produit de nombreuses détections à faible confiance ou conflictuelles sont considérées à haute incertitude.

Les images à plus haute incertitude – généralement les 5 à 10 % supérieurs du pool non étiqueté par score d'incertitude – sont ajoutées au lot d'annotation suivant. Après étiquetage, le modèle est réentraîné sur l'ensemble étiqueté élargi et le cycle se répète. Le suivi de la courbe mAP par rapport au nombre cumulé d'annotations à travers les cycles quantifie le gain d'efficacité de l'apprentissage actif. Dans les programmes de défense de production avec de grands pools non étiquetés, l'apprentissage actif réduit généralement le nombre d'annotations nécessaires pour atteindre un mAP cible de 30 à 60 % par rapport à l'échantillonnage aléatoire du pool non étiqueté.

Une mise en garde importante : l'apprentissage actif optimise pour l'incertitude du modèle, qui n'est pas identique à l'optimisation pour la performance du modèle sur les cas opérationnels les plus difficiles. Les classes cibles rares mais opérationnellement critiques (nouveaux types de véhicules, configurations inhabituelles, camouflage adverse) peuvent avoir une très faible représentation dans le pool de haute incertitude si le modèle n'a jamais vu d'exemples de celles-ci. L'apprentissage actif devrait être combiné à une collecte ciblée – l'acquisition et l'étiquetage délibérés d'exemples de modes de défaillance connus du modèle – et non utilisé comme remplacement complet de la curation de la file d'étiquetage par des experts du domaine.

5. gestion de la classification et gouvernance des jeux de données

Dans un contexte de défense, « classification » a deux significations distinctes que le pipeline doit gérer simultanément : la tâche d'apprentissage automatique consistant à attribuer une étiquette de classe à un objet, et la classification de sécurité de l'information de l'imagerie elle-même. Confondre ces deux significations dans la conception du pipeline produit soit des violations de sécurité, soit des flux d'étiquetage inutilement restrictifs – les deux sont coûteux.

L'architecture de gestion de la classification du pipeline devrait séparer explicitement ces préoccupations. La classification de sécurité de l'information est une propriété de l'image et est appliquée par la couche de contrôle d'accès – les annotateurs ne voient que les images à leur niveau d'habilitation ou en dessous, et les marquages de classification voyagent avec l'image à travers chaque étape du pipeline. La taxonomie de classes ML est une propriété du schéma d'annotation et est gouvernée par le flux d'étiquetage. Ces deux systèmes de classification opèrent sur des axes orthogonaux : une seule image peut être NON CLASSIFIÉE (sécurité de l'information) tout en contenant un VÉHICULE-À-ROUES-HOSTILE (classe ML), et une image CONFIDENTIELLE pourrait ne contenir que de l'arrière-plan sans aucun objet annoté.

La gouvernance des jeux de données – l'ensemble des politiques qui déterminent comment un jeu de données étiqueté peut être utilisé, partagé et modifié – doit être codifiée avant la production de la première annotation, pas après. Une carte de jeu de données est l'artefact standard pour cela : un document structuré qui enregistre la version du schéma du jeu de données, le niveau de classification, le nombre d'annotateurs et leurs niveaux d'habilitation, les scores IAA, la distribution des classes, le statut réussite/échec du CQ pour chaque contrôle automatisé, les exécutions d'entraînement qui ont consommé le jeu de données et toutes limitations ou biais connus. La carte de jeu de données voyage avec chaque export du jeu de données et est mise à jour lorsque le jeu de données est modifié, augmenté ou réétiqueté sous une nouvelle version de schéma.

6. contrôles qualité automatisés avant l'approbation pour l'entraînement

Aucun jeu de données ne devrait être approuvé pour l'entraînement du modèle sans passer une suite de contrôles qualité automatisés. Ces contrôles détectent les problèmes systématiques que la revue humaine manque parce que les relecteurs examinent les annotations individuelles plutôt que les statistiques au niveau du jeu de données.

Audit de distribution des classes. Vérifiez que chaque classe atteint un seuil minimal de nombre d'instances. Les classes sous le seuil sont signalées – soit l'effort de collecte et d'étiquetage pour cette classe doit être augmenté, soit la classe doit être fusionnée avec une classe parente pour l'exécution d'entraînement actuelle. Vérifiez aussi le ratio de déséquilibre entre la classe la plus courante et la moins courante : un déséquilibre extrême (plus de 100:1) sans stratégies de compensation (sur-échantillonnage, pondération de la perte) est un prédicteur fiable d'un faible rappel sur les classes minoritaires.

Cohérence des boîtes englobantes. Signalez les annotations d'aire nulle ou négative, les annotations qui s'étendent au-delà de la limite de l'image et les annotations dont les ratios d'aspect sont hors de la plage physiquement plausible pour la classe annotée. Une boîte englobante autour d'une personne debout avec un ratio largeur/hauteur de 3:1 est presque certainement une erreur. Ces contrôles détectent les erreurs d'annotateur individuellement rares mais cumulativement significatives à l'échelle du jeu de données.

Détection des doublons et des fuites. Exécutez la suite complète de détection des doublons (hachage exact + hachage perceptuel) sur l'ensemble étiqueté final avant de le partitionner en jeux d'entraînement, de validation et de test. Après partitionnement, vérifiez qu'aucune image n'apparaît dans plus d'une partition. Si le jeu de données a été augmenté (retournements, rotations, recadrages), exécutez une détection de quasi-doublons sur l'ensemble post-augmentation et assurez-vous que les variantes augmentées de la même image source ne sont pas réparties entre entraînement et validation.

Couverture des annotations. Vérifiez que chaque image est soit annotée, soit explicitement marquée comme négatif dur (une image confirmée ne contenant aucune instance d'une quelconque classe cible). Les images sans annotation et sans drapeau de négatif dur sont ambiguës – elles peuvent être des positifs non annotés (annotations manquées) ou de véritables négatifs. Les deux états sont nuisibles : les positifs non annotés produisent un signal d'entraînement faux-négatif ; les images d'arrière-plan non vérifiées ajoutent du bruit à l'ensemble de négatifs durs. Le contrôle de couverture détecte les images qui sont passées à travers la file d'annotation sans être correctement traitées.

Une fois tous les contrôles passés, le jeu de données est exporté vers le format cible – COCO JSON pour les pipelines multitâches, YOLO TXT pour l'entraînement spécifique aux détecteurs – avec les marquages de classification intégrés dans les métadonnées de chaque fichier de sortie. L'événement d'export est journalisé avec la version de la carte de jeu de données, le rapport de CQ et l'identité de l'ingénieur qui a approuvé l'export. Cette piste d'audit est la dernière ligne de défense contre le lancement d'une exécution d'entraînement sur un jeu de données non approuvé ou incorrectement versionné.