Métriques Person ReID : évaluer un système de ré-identification

Évaluer un système Person ReID avec un unique taux de « précision » conduit presque toujours à une lecture trompeuse. Il faut associer un protocole et plusieurs métriques : définir des requêtes et des galeries réalistes, mesurer le classement avec Rank-k et la mean Average Precision (mAP), puis évaluer la décision réellement proposée par le produit — afficher, accepter, rejeter ou envoyer en revue.

La ré-identification est d’abord un problème de recherche visuelle. Un modèle peut placer une bonne image en première position tout en dispersant les autres images pertinentes. Il peut aussi réussir sur un jeu de référence et se dégrader face à une nouvelle caméra, un recadrage flou ou une galerie remplie de tenues similaires. Le guide d’intégration Person ReID précise cette frontière entre vecteur d’apparence, recherche et décision.

Écrire le protocole avant de lancer le calcul

Chaque recadrage requête est comparé à une galerie de candidats. Un candidat est pertinent lorsqu’il correspond à la même identité d’évaluation selon la vérité terrain documentée. Le protocole doit fixer :

• la séparation des identités entre entraînement, calibration et test final ;
• la présence éventuelle d’images issues de la même caméra ou du même événement ;
• le traitement des doublons, des images voisines et des recadrages invalides ;
• l’existence d’au moins un résultat pertinent pour chaque requête conservée ;
• la représentation des changements de tenue, de lieu ou de session ;
• les révisions exactes du modèle et du prétraitement.

Ces choix définissent la difficulté du test. Des frames presque identiques réparties entre requête et galerie peuvent gonfler artificiellement le résultat. Un seuil choisi après observation du jeu de test transforme ce dernier en jeu de calibration et invalide la mesure finale.

L’article fondateur du jeu Market-1501 décrit une évaluation requête-galerie avec courbe CMC et mAP. C’est une référence méthodologique, pas un protocole à recopier aveuglément dans un contexte métier. Le projet Torchreid permet également d’examiner une implémentation publique des conventions courantes.

Rank-k mesure la présence rapide d’un bon résultat

Rank-k répond à une question simple : au moins un candidat pertinent apparaît-il dans les (k) premières positions ? Pour (Q) requêtes valides :

Rank-k = (1 / Q) × Σ 1[premier rang pertinent de la requête q ≤ k]

Rank-1 porte donc sur le premier candidat. Rank-5 correspond mieux à une interface qui affiche cinq propositions. Rapporter Rank-20 n’apporte guère d’information si l’opérateur n’ouvre jamais autant de résultats.

Cette métrique reste partielle. Une liste avec une image correcte en tête, puis une longue série d’erreurs, obtient le même succès Rank-1 qu’une liste parfaitement ordonnée. Rank-k ne dit pas non plus combien de faux candidats devront être examinés.

La mAP tient compte de tous les éléments pertinents

L’Average Precision récompense les classements qui remontent tôt l’ensemble des éléments pertinents. Pour une requête (q) possédant (R_q) résultats pertinents :

AP(q) = (1 / Rq) × Σ Précision@k × pertinent(k)
mAP   = moyenne des AP(q) sur les requêtes valides

La précision est relevée chaque fois qu’un résultat pertinent apparaît. La mAP convient donc bien à une collection de photos d’événement où une même personne peut figurer sur plusieurs images.

Elle reste dépendante de la galerie. Ajouter des négatifs faciles, des sosies vestimentaires ou des images pertinentes supplémentaires modifie le score. Toute publication de mAP devrait mentionner les règles d’exclusion, la distribution de taille des galeries et la révision du modèle. Deux chiffres issus de protocoles différents ne sont pas directement comparables.

Mesurer la fonction réellement livrée

Rank-k et mAP décrivent un classement. Une application ajoute souvent un seuil et une revue humaine. Il faut alors compléter avec :

• la précision des candidats proposés : quelle part des résultats affichés est pertinente ?
• le rappel : quelle part des éléments pertinents a été retrouvée ?
• les faux rapprochements par requête ;
• le taux sans résultat au-dessus du seuil de revue ;
• la charge opérateur, notamment le nombre médian et les cas extrêmes à inspecter ;
• le taux de correction, lorsque l’opérateur rejette, fusionne ou sépare une proposition.

Ces métriques doivent être calculées avec la règle de décision réellement envisagée. Le guide sur le choix d’un seuil de similarité Person ReID explique pourquoi un seuil universel n’existe pas. La règle se choisit sur un jeu de calibration, puis se mesure une seule fois sur un test resté intact.

Si le produit ne fournit qu’une liste ordonnée, un taux de réussite sur des paires ne suffit pas. À l’inverse, si le système accepte automatiquement des rapprochements, les seules métriques de classement ne décrivent pas le risque de faux positif.

Découper les résultats pour repérer les angles morts

Une moyenne globale peut masquer une faiblesse récurrente. Les segments d’analyse doivent être décidés avant lecture des résultats :

• caméra ou position de prise de vue ;
• salle et condition lumineuse ;
• source du recadrage et version du détecteur ;
• niveau de flou, de troncature et d’occlusion ;
• changement de tenue ou costumes très proches ;
• taille de galerie et nombre de résultats pertinents ;
• groupes opérationnels ou démographiques lorsque l’analyse est licite, pertinente et correctement gouvernée.

Indiquez toujours le nombre de requêtes par segment. Un fort écart calculé sur quelques exemples signale surtout une grande incertitude. Lorsque l’échantillon le permet, estimez un intervalle de confiance en rééchantillonnant les requêtes, plutôt qu’en considérant chaque paire comme indépendante.

La qualité d’entrée mérite une analyse dédiée. La checklist de qualité des recadrages aide à distinguer une faiblesse du modèle d’une image contenant deux personnes, trop peu de corps ou un fort flou. Pour un nouveau lieu ou de nouvelles caméras, il faut aussi tester le changement de domaine : une distribution de scores stable ne garantit pas que les voisins restent pertinents.

Séparer modèle, vecteurs et moteur de recherche

Chaque rapport doit conserver la révision du modèle, la version de prétraitement, la normalisation et la métrique de distance. Le guide français des vecteurs d’apparence explique pourquoi des vecteurs issus de révisions incompatibles ne doivent pas être comparés.

Le moteur d’indexation doit aussi être testé. Une recherche approximative peut omettre un voisin que la recherche exacte aurait trouvé. Comparez sa configuration à une référence exacte sur un échantillon représentatif, puis distinguez le rappel de l’index de la qualité de classement du modèle. Sinon, une modification HNSW ou IVF peut être interprétée à tort comme une régression du réseau.

La page publique de l’API PolyReID décrit le contrat documenté du service et ses champs de version. Elle ne transforme pas une mesure de référence en garantie pour un autre jeu de données.

Contenu minimal d’un rapport exploitable

Un document court peut rester auditable s’il contient :

1. l’usage visé et les interprétations interdites ;
2. l’origine des données et la construction des partitions ;
3. les règles de requête, galerie et exclusion ;
4. la politique de création et de contrôle des recadrages ;
5. les versions immuables du modèle, du prétraitement et de l’index ;
6. Rank-k et mAP avec le nombre de requêtes ;
7. précision, rappel et charge de revue au seuil retenu ;
8. les segments prédéfinis et leur incertitude ;
9. des exemples d’échec, pas seulement les réussites ;
10. le responsable de validation et les événements déclenchant un nouveau test.

Il faut recommencer l’évaluation après un changement de modèle, de chaîne de recadrage, de caméra, de réglage d’index ou de règle métier. L’objectif n’est pas d’obtenir le chiffre le plus flatteur, mais de produire une preuve limitée, versionnée et compréhensible sur le comportement d’un workflow donné.