Choisir un modèle de reconnaissance faciale : tests 1:1, 1:N et choix du seuil
Une démarche alignée sur FRVT pour choisir un modèle de reconnaissance InsightFace, construire des bancs d'essai 1:1 et 1:N, fixer les seuils et décider quand passer des packs open source aux modèles commerciaux InsightFace.
Ce que vous allez mettre en place
La plupart des erreurs en reconnaissance faciale ne se trouvent pas dans le code, mais dans le choix du modèle et le réglage du seuil. Un modèle bien classé sur un classement public peut très bien dérailler sur vos données, parce que le point de fonctionnement, la composition démographique, la qualité de capture et la taille de la galerie ne sont pas les mêmes.
Ce guide propose un cadre d'évaluation indépendant des fournisseurs, aligné sur la méthodologie NIST FRVT. Il couvre la vérification 1:1, l'identification 1:N, les métriques qui comptent vraiment, la mise en place d'un test défendable, les ordres de grandeur publics des packs open source InsightFace, ainsi que les conditions dans lesquelles les modèles commerciaux InsightFace s'imposent, en chiffrant ce que recouvre concrètement leur précision supérieure.
Avant de commencer
- Maîtrise de l'exécution d'InsightFace via le paquet Python insightface ou via ONNX Runtime pour la détection, l'alignement et l'extraction d'embeddings.
- Un jeu de validation représentatif couvrant la démographie, la tranche d'âge, la pose, l'éclairage, l'occultation (masque, lunettes, cheveux), la qualité d'appareil photo et la distance de capture du trafic de production.
- Bases de numpy et scikit-learn pour les analyses ROC, DET et de distribution de scores de similarité.
- Un point de fonctionnement cible clairement défini en FMR ou FPIR (par exemple FMR = 1e-5), pas seulement un pourcentage de précision.
1. Trancher : problème 1:1 ou 1:N
La vérification 1:1 répond à "cette personne est-elle bien l'identité revendiquée ?". Elle compare un gabarit de sonde à un seul gabarit enrôlé et renvoie un score de similarité ainsi qu'une décision identique/différent. Cas typiques : déverrouillage d'appareil, KYC (selfie versus pièce d'identité), confirmation de paiement, ré-authentification.
L'identification 1:N répond à "qui est cette personne, le cas échéant, parmi N identités enrôlées ?". Elle compare une sonde à une galerie de N gabarits et renvoie une liste de candidats. Cas typiques : sas de contrôle d'accès, alertes liste de surveillance, présence, déduplication. Un modèle bien classé en LFW 1:1 ne se transpose pas automatiquement à des galeries 1:N de 10^5 ou 10^6 entrées : c'est précisément pour cela que le NIST publie FRVT 1:1 et FRVT 1:N comme des rapports distincts.
- Le trafic 1:1 est dominé par les comparaisons "même personne" ; le coût d'une fausse correspondance se compte par transaction.
- Le trafic 1:N est dominé par les comparaisons "personnes différentes" (sur les listes de surveillance, l'écrasante majorité des sondes ne sont pas en galerie) ; le taux de faux positifs croît avec N.
- Choisissez d'abord la charge de travail. Le même backbone réclame des seuils différents selon que l'on est en 1:1 ou en 1:N.
2. Adopter des métriques de type FRVT
Renoncez à "l'accuracy" comme chiffre unique. Les rapports FRVT donnent à un point de fonctionnement fixé deux taux d'erreur complémentaires et tracent la courbe pour visualiser le compromis.
En 1:1 : FMR (False Match Rate) et FNMR (False Non-Match Rate). Fixez une FMR cible (typiquement 1e-4, 1e-5 ou 1e-6) et reportez la FNMR à ce point. En 1:N : FPIR (False Positive Identification Rate) et FNIR (False Negative Identification Rate). Indiquez systématiquement la taille de galerie N, le rang et si le test est en ensemble fermé (la sonde est toujours dans la galerie) ou ouvert (elle peut ne pas l'être).
- Publiez toujours le seuil avec la valeur reportée ; une FNMR sans FMR ou une FNIR sans FPIR n'a aucun sens.
- Tracez des courbes DET (Detection Error Tradeoff) plutôt que des ROC ; elles se lisent mieux dans les régimes de faibles taux d'erreur.
- Reportez les chiffres par strate démographique, et pas seulement en agrégé, dans la lignée des études FRVT sur les effets démographiques.
3. Construire un jeu de test défendable
Les paires de même individu et de individus différents s'échantillonnent séparément. Pour estimer une FMR = 1e-6 en 1:1 avec une confiance statistique correcte, il faut de l'ordre de 10 / FMR = 10^7 comparaisons "individus différents". Réutiliser une même sonde dans plusieurs paires est admissible, mais la taille effective d'échantillon doit être annoncée honnêtement.
Stratifiez par groupe démographique, dispositif de capture, intérieur/extérieur, écart d'âge entre l'enrôlement et la sonde, type d'occultation et pose de tête. Reportez par strate, pas seulement la moyenne. Maintenez le jeu de test strictement disjoint de toute donnée d'entraînement, de fine-tuning ou de pré-entraînement (Glint360K, WebFace42M, MS1MV3, etc.) et documentez la provenance et le consentement.
- Au moins 10 / FMR cible comparaisons "individus différents" ; en deçà, l'intervalle de confiance sur la FMR est très large.
- Figez le jeu de test. Un jeu de test sur lequel on règle en boucle devient de fait un jeu de validation.
- Maintenez un sous-ensemble "golden", petit et verrouillé, qui est rejoué à chaque changement de modèle ou de prétraitement.
4. Calculer embeddings, similarité et seuils
Utilisez le prétraitement officiel du paquet : détection RetinaFace ou SCRFD, alignement 5 points, recadrage 112x112 RGB et la mean/std fournie avec le pack de reconnaissance. Un prétraitement non aligné est de loin la première raison pour laquelle des chiffres publiés ne se reproduisent pas.
Standardisez sur la similarité cosinus entre embeddings normalisés en L2. L'API Python InsightFace expose face.normed_embedding exactement à cette fin. Choisissez le seuil sur un split de validation, figez-le, puis évaluez sur le jeu de test ; le choisir sur le test gonfle artificiellement les résultats.
- Les seuils 1:1 typiques pour les packs InsightFace se situent autour de 0,30-0,45 en cosinus à FMR = 1e-4 - 1e-5 ; la valeur exacte dépend du backbone, des données d'entraînement et de votre population, donc recalculez-la systématiquement.
- La normalisation de scores (z-norm, t-norm) aide quand la distribution de la galerie change entre déploiements.
- Si vous fine-tunez, recalculez le seuil ; ne réutilisez jamais un seuil d'une version de modèle à une autre.
import numpy as np
from insightface.app import FaceAnalysis
app = FaceAnalysis(
name="buffalo_l",
providers=["CUDAExecutionProvider", "CPUExecutionProvider"],
)
app.prepare(ctx_id=0, det_size=(640, 640))
def embed(image_bgr):
faces = app.get(image_bgr)
if not faces:
return None
# use the largest detected face
face = max(faces, key=lambda f: (f.bbox[2] - f.bbox[0]) * (f.bbox[3] - f.bbox[1]))
return face.normed_embedding.astype(np.float32) # already L2-normalized
def cosine(a, b):
return float(np.dot(a, b)) # both vectors are already L2-normalizedimport numpy as np
# scores collected on a held-out validation split
genuine = np.array(genuine_scores) # same person pairs
impostor = np.array(impostor_scores) # different people pairs
# pick the operating point you must defend in production
target_fmr = 1e-5
# threshold = score above which (1 - target_fmr) of impostors fall
threshold = float(np.quantile(impostor, 1.0 - target_fmr))
fnmr = float(np.mean(genuine < threshold))
print(f"threshold = {threshold:.4f}")
print(f"FNMR @ FMR = {target_fmr:.0e} -> {fnmr:.4f}")import numpy as np
# gallery_emb: (N, d) L2-normalized embeddings of enrolled identities
# probe_emb: (P, d) L2-normalized embeddings of probes
# probe_label: (P,) ground-truth gallery index, or -1 for non-mate probes (open-set)
scores = probe_emb @ gallery_emb.T # (P, N) cosine similarity
top1_idx = scores.argmax(axis=1)
top1_score = scores.max(axis=1)
# choose threshold from validation, then evaluate FPIR / FNIR
threshold = 0.40
mate = probe_label >= 0
non_mate = ~mate
fnir = float(np.mean(
(top1_idx[mate] != probe_label[mate]) | (top1_score[mate] < threshold)
))
fpir = float(np.mean(top1_score[non_mate] >= threshold))
print(f"FNIR = {fnir:.4f}, FPIR = {fpir:.4f} at threshold {threshold:.2f}")5. Benchmarker les modèles open source InsightFace
Le paquet Python insightface distribue des packs prêts à l'emploi qui combinent un détecteur et un backbone de reconnaissance. Les packs de reconnaissance les plus utilisés sont buffalo_sc et buffalo_s (mobile / edge), buffalo_m (équilibré), buffalo_l avec la tête w600k_r50 (par défaut serveur) et antelopev2 avec la tête glintr100 (gros serveur). Le Model Zoo publie aussi les poids bruts R50 et R100 ArcFace.
Les résultats publics sur les bancs académiques standards (LFW, CFP-FP, AgeDB-30, IJB-B, IJB-C) situent ces packs dans les ordres de grandeur ci-dessous. À traiter comme indication ; recalculez sur vos données.
- Précision LFW 1:1 : 99,50 % (MBF mobile) à 99,85 % (R100, w600k_r50) — LFW est saturé et ne sert qu'à un test de cohérence.
- CFP-FP (frontal vs profil) : 96-99 % sur toute la gamme, classe R100 nettement devant en profil.
- AgeDB-30 : 96-98,5 % sur toute la gamme ; les gros packs encaissent mieux les écarts d'âge.
- IJB-C TAR @ FAR = 1e-4 : environ 90-93 % pour MBF / mobile, 95-96 % pour R50, 96-97,5 % pour R100 / w600k_r50 / glintr100.
- MFR (Multi-racial Face Recognition, protocole de la challenge ICCV-21 / 22 couvrant les cohortes African, Caucasian, East Asian, South Asian et Mixed à FMR = 1e-6 / 1e-5) : l'écart de TAR entre la meilleure et la pire cohorte se creuse à mesure que le modèle rapetisse. Les packs de classe R100 (w600k_r50, glintr100) restent en général à quelques points de pourcentage entre cohortes, R50 s'ouvre à des écarts de l'ordre du milieu des unités, et MBF mobile peut afficher des écarts à deux chiffres sur la cohorte la plus difficile — reproduisez sur votre propre population avant de figer un point de fonctionnement.
- Débit (un seul GPU, batch 32, FP16) : MBF atteint plusieurs milliers d'embeddings par seconde, R100 reste dans les bas centaines. Toujours mesurer sur le matériel cible.
6. Adapter le pack open source à la charge
Pour la majorité des développements produit, il suffit de choisir entre deux packs open source : buffalo_s (et sa version plus légère buffalo_sc) pour le mobile et l'edge, et buffalo_l pour le serveur.
buffalo_s / buffalo_sc sont le bon défaut pour le déverrouillage facial sur appareil, les intégrations SDK mobile, les boîtiers embarqués et toute charge où la latence et la taille du binaire pèsent davantage que la précision absolue. buffalo_l (w600k_r50) est le bon défaut pour toute reconnaissance côté serveur : vérification 1:1, identification 1:N sur des galeries jusqu'à quelques centaines de milliers d'identités, et FMR cible autour de 1e-5.
- Mobile / edge : choisissez buffalo_s, ou buffalo_sc lorsque la mémoire ou le budget de calcul sont contraints.
- Serveur : choisissez buffalo_l. C'est le pack de reconnaissance open source le plus puissant que nous livrons et il couvre la majorité des scénarios de vérification et d'identification en capture coopérative.
- Les packs open source suffisent pour la plupart des fonctionnalités produit opérant à FMR >= 1e-5 sur captures coopératives. Au-delà, voir la section suivante.
7. Quand basculer vers les modèles commerciaux InsightFace
Les modèles commerciaux de reconnaissance InsightFace sont entraînés sur des ensembles d'identités sensiblement plus grands et plus diversifiés, avec des formulations de perte et des recettes d'entraînement propriétaires, et livrés avec des points de fonctionnement documentés et des artefacts signés. Ce ne sont pas "le modèle open source avec plus de paramètres".
Concrètement, sur des protocoles internes 1:1 démographiquement équilibrés à FMR = 1e-6, les modèles commerciaux divisent typiquement la FNMR par 2 à 5 par rapport au meilleur pack open source (par exemple, la FNMR passe d'environ 5-8 % à 1-2 % sur des sous-ensembles difficiles : masque, grande pose, basse résolution). En 1:N démographiquement équilibré sur des galeries de 1 M+, la FNIR à FPIR fixée chute dans des proportions comparables, et l'écart entre le meilleur et le pire sous-groupe démographique aux points de fonctionnement stricts se resserre.
Pour rendre cette décision facile à valider sur vos propres données, nous proposons une évaluation gratuite de 2 semaines des modèles commerciaux de reconnaissance, dès la signature d'un accord préliminaire de coopération (NDA / accord de pilote). Pendant l'essai, vous bénéficiez d'un accès limité dans le temps aux artefacts du modèle commercial ou à l'API hébergée, vous pouvez exécuter les tests 1:1 et 1:N de style FRVT décrits dans ce guide et comparer les chiffres directement avec le pack open source actuellement utilisé, avant tout engagement commercial.
- Choisissez les modèles commerciaux quand vous opérez à FMR <= 1e-6, par exemple contrôle aux frontières, autorisation de paiement, KYC réglementé.
- Choisissez-les quand la galerie dépasse 100k-1M identités et que la stabilité du rang 1 est critique.
- Choisissez-les quand des audits d'équité exigent de réduire l'écart entre le meilleur et le pire sous-groupe démographique aux points stricts.
- Choisissez-les quand la production inclut des conditions difficiles : occultation forte, grande pose, basse résolution (distance interpupillaire inférieure à ~48 px) ou capture non coopérative.
- Choisissez-les quand vous avez besoin d'un SLA entreprise, d'une licence on-premise, d'un PAD / liveness intégré, d'artefacts signés et d'une indemnisation contractuelle.
- Signez un accord préliminaire de coopération pour démarrer une évaluation gratuite de 2 semaines sur vos propres données avant tout engagement commercial.
8. Mise en production et évaluation continue
Verrouillez ensemble, comme une seule unité de release, l'artefact de modèle (hachage cryptographique), le chemin de code du prétraitement, le seuil et la définition des métriques. Les changements de prétraitement déplacent silencieusement la FMR ; versionner le prétraitement compte au moins autant que versionner les poids.
Réévaluez régulièrement sur des échantillons frais de production, au moins une fois par trimestre. La métrique vivante la plus importante est la FMR au seuil de production, calculée contre un nouveau jeu d'imposteurs ; elle dit si le point de fonctionnement promis au métier tient encore.
- Suivre conjointement la dérive FMR / FNMR, le taux de fausse alerte, le taux d'override opérateur et les deltas démographiques.
- Disposer d'un plan de rollback. Seuil et modèle sont co-versionnés ; jamais l'un sans l'autre.
- Lors d'un changement de modèle, recalculez le seuil et republiez le point de fonctionnement avant de basculer le trafic.
Besoin d’aide pour le déploiement en production ?
Contactez InsightFace pour les licences de modèles, l’optimisation runtime et le support de déploiement sur votre matériel cible.
Nous contacter