Auswahl eines Gesichtserkennungsmodells: 1:1- und 1:N-Tests sowie Schwellenwertbestimmung
Ein FRVT-konformes Vorgehen, um ein InsightFace-Erkennungsmodell auszuwählen, 1:1- und 1:N-Benchmarks aufzubauen, Schwellenwerte zu setzen und zu entscheiden, wann ein Wechsel von den Open-Source-Paketen zu den kommerziellen InsightFace-Modellen sinnvoll ist.
Was Sie umsetzen
Die meisten Fehler bei Gesichtserkennungssystemen entstehen nicht im Code, sondern bei der Modellauswahl und der Schwellenwertbestimmung. Ein Modell, das in einer öffentlichen Bestenliste vorne liegt, kann auf Ihren Daten dennoch versagen, weil Betriebspunkt, demografische Verteilung, Aufnahmequalität und Galerie-Größe abweichen.
Diese Anleitung beschreibt ein anbieterneutrales Bewertungsschema in Anlehnung an die NIST-FRVT-Methodik. Sie behandelt 1:1-Verifikation und 1:N-Identifikation, die wirklich relevanten Kennzahlen, den Aufbau eines belastbaren Tests, die öffentlich dokumentierten Werte der InsightFace-Open-Source-Pakete sowie die Bedingungen, unter denen die kommerziellen InsightFace-Modelle angemessen sind und was deren höhere Genauigkeit konkret in Zahlen bedeutet.
Vor dem Start
- Erfahrung darin, InsightFace über das Python-Paket insightface oder ONNX Runtime für Gesichtsdetektion, Ausrichtung und Embedding-Extraktion zu betreiben.
- Ein repräsentativer Validierungsdatensatz, der Demografie, Altersbereich, Pose, Beleuchtung, Verdeckung (Maske, Brille, Haar), Kameraqualität und Aufnahmedistanz Ihres Produktivverkehrs abbildet.
- Grundkenntnisse von numpy und scikit-learn für ROC-, DET- und Score-Analysen.
- Ein klar definierter Zielbetriebspunkt, ausgedrückt als FMR oder FPIR (z. B. FMR = 1e-5), nicht nur als Genauigkeitsprozent.
1. Klären, ob es sich um ein 1:1- oder ein 1:N-Problem handelt
Die 1:1-Verifikation beantwortet die Frage "Ist diese Person identisch mit der angegebenen Identität?". Sie vergleicht ein Probe-Template mit einem registrierten Template und liefert einen Ähnlichkeitswert sowie eine Übereinstimmungsentscheidung. Typische Anwendungen sind Geräte-Entsperrung, KYC (Selfie gegen Ausweis), Zahlungsfreigabe und Re-Authentifizierung.
Die 1:N-Identifikation beantwortet die Frage "Wer, falls überhaupt, ist diese Person unter N registrierten Identitäten?". Sie vergleicht eine Probe gegen eine Galerie aus N Templates und liefert eine Kandidatenliste. Typische Anwendungen sind Zutrittsschleusen, Watchlist-Alarme, Anwesenheitserfassung und Deduplikation. Ein Modell, das auf 1:1-LFW vorn liegt, skaliert nicht automatisch auf 1:N-Galerien mit 10^5 oder 10^6 Einträgen - genau deshalb veröffentlicht das NIST FRVT 1:1 und FRVT 1:N als getrennte Berichte.
- 1:1-Verkehr besteht überwiegend aus Mate-Vergleichen; die Kosten einer Falschübereinstimmung fallen pro Transaktion an.
- 1:N-Verkehr besteht überwiegend aus Non-Mate-Vergleichen (auf Watchlists ist die Mehrheit der Proben nicht in der Galerie); die Falsch-Positiv-Rate skaliert mit N.
- Wählen Sie zuerst die Workload. Selbst dasselbe Backbone braucht für 1:1 und 1:N unterschiedliche Schwellenwerte.
2. FRVT-konforme Kennzahlen verwenden
Verlassen Sie sich nicht auf eine einzelne "Accuracy". FRVT-Berichte geben an einem festen Betriebspunkt zwei komplementäre Fehlerraten an und stellen sie als Kurve dar, sodass der Trade-off sichtbar bleibt.
Für 1:1 verwenden Sie FMR (False Match Rate) und FNMR (False Non-Match Rate). Definieren Sie eine Ziel-FMR (typischerweise 1e-4, 1e-5 oder 1e-6) und berichten Sie die FNMR an genau diesem Punkt. Für 1:N verwenden Sie FPIR (False Positive Identification Rate) und FNIR (False Negative Identification Rate). Geben Sie immer Galerie-Größe N, Rang und an, ob es sich um Closed-Set (Probe ist immer in der Galerie) oder Open-Set (Probe kann fehlen) handelt.
- Veröffentlichen Sie zu jeder Kennzahl auch den Schwellenwert; eine FNMR ohne FMR oder eine FNIR ohne FPIR ist bedeutungslos.
- Verwenden Sie DET-Kurven (Detection Error Tradeoff) statt ROC; sie sind im Bereich kleiner Fehlerraten besser ablesbar.
- Berichten Sie Werte je demografischer Schicht, nicht nur als Gesamtmittel - analog zu den FRVT-Demographic-Effects-Studien.
3. Einen belastbaren Testdatensatz aufbauen
Mate- und Non-Mate-Paare werden getrennt gezogen. Um für 1:1 eine FMR = 1e-6 statistisch belastbar zu schätzen, sind in der Größenordnung 10 / FMR = 10^7 Non-Mate-Vergleiche erforderlich. Mehrfache Verwendung derselben Probe in unterschiedlichen Paaren ist zulässig, aber die effektive Stichprobengröße muss ehrlich angegeben werden.
Stratifizieren Sie nach demografischer Gruppe, Aufnahmegerät, Innen-/Außenaufnahme, Altersabstand zwischen Enrollment und Probe, Verdeckungsart und Kopfpose. Berichten Sie die Werte je Schicht, nicht nur den Mittelwert. Halten Sie die Testdaten strikt getrennt von Trainings-, Fine-Tuning- und Vortrainingsdaten (Glint360K, WebFace42M, MS1MV3 etc.) und dokumentieren Sie Herkunft und Einwilligung.
- Mindestens 10 / Ziel-FMR Non-Mate-Vergleiche verwenden, sonst hat die FMR-Schätzung große Konfidenzintervalle.
- Den Testdatensatz einfrieren. Ein Testdatensatz, gegen den fortlaufend optimiert wird, ist faktisch ein Validierungsdatensatz.
- Eine kleine, gesperrte "Golden"-Teilmenge pflegen, die bei jedem Modell- oder Vorverarbeitungswechsel erneut durchläuft.
4. Embeddings, Ähnlichkeit und Schwellenwerte berechnen
Verwenden Sie die offizielle Vorverarbeitung des Pakets: RetinaFace oder SCRFD zur Detektion, 5-Punkt-Ausrichtung, 112x112-RGB-Crop und die mit dem Erkennungspaket gelieferten Mittelwert/Std-Werte. Eine abweichende Vorverarbeitung ist mit Abstand der häufigste Grund, warum berichtete Zahlen sich nicht reproduzieren lassen.
Standardisieren Sie auf die Kosinus-Ähnlichkeit zwischen L2-normalisierten Embeddings. In der InsightFace-Python-API steht dafür face.normed_embedding bereit. Wählen Sie den Schwellenwert auf einem Validierungs-Split, frieren Sie ihn ein und werten Sie ihn anschließend auf dem Testdatensatz aus; die Schwellenwertwahl auf dem Testdatensatz blasen die Ergebnisse künstlich auf.
- Typische 1:1-Schwellenwerte für InsightFace-Erkennungspakete liegen bei FMR = 1e-4 bis 1e-5 im Kosinusbereich 0,30-0,45; der genaue Wert hängt von Backbone, Trainingsdaten und Zielpopulation ab und muss neu berechnet werden.
- Score-Normalisierung (z-norm, t-norm) hilft, wenn sich die Galerie-Verteilung zwischen Deployments verschiebt.
- Bei Fine-Tuning unbedingt den Schwellenwert neu bestimmen; nie über Modellversionen hinweg übernehmen.
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. InsightFace-Open-Source-Modelle benchmarken
Das Python-Paket insightface verteilt einsatzbereite Modellpakete, die einen Detektor und ein Erkennungs-Backbone bündeln. Am häufigsten verwendet werden buffalo_sc und buffalo_s (Mobile / Edge), buffalo_m (ausgewogen), buffalo_l mit dem Kopf w600k_r50 (Server-Standard) sowie antelopev2 mit dem Kopf glintr100 (großer Server). Im Model Zoo finden sich zusätzlich die rohen R50- und R100-ArcFace-Gewichte.
Öffentlich gemeldete Werte auf Standard-Benchmarks (LFW, CFP-FP, AgeDB-30, IJB-B, IJB-C) ordnen diese Pakete in folgenden Größenordnungen ein. Diese Werte dienen nur als Referenz; rechnen Sie auf Ihren Daten nach.
- LFW 1:1-Genauigkeit: 99,50 % (mobile MBF) bis 99,85 % (R100, w600k_r50) - LFW ist gesättigt und nur als Plausibilitätsprüfung sinnvoll.
- CFP-FP (frontal vs. Profil): 96-99 % über die gesamte Reihe, R100-Klasse deutlich vorn bei Profilansichten.
- AgeDB-30: 96-98,5 % über die gesamte Reihe; große Pakete kommen besser mit Altersabstand zurecht.
- IJB-C TAR @ FAR = 1e-4: rund 90-93 % für MBF / Mobile, 95-96 % für R50, 96-97,5 % für R100 / w600k_r50 / glintr100.
- MFR (Multi-racial Face Recognition, Protokoll der ICCV-21/22-Challenge mit den Kohorten African, Caucasian, East Asian, South Asian und Mixed bei FMR = 1e-6 / 1e-5): Der Abstand zwischen der besten und der schlechtesten Kohorte wächst, je kleiner das Modell wird. Pakete der R100-Klasse (w600k_r50, glintr100) bleiben über die Kohorten hinweg meist innerhalb weniger Prozentpunkte TAR, R50 öffnet auf mittlere einstellige Lücken, und mobile MBF kann an der schwierigsten Kohorte zweistellige Lücken zeigen - vor jedem Festlegen eines Betriebspunktes auf Ihrer eigenen Population reproduzieren.
- Durchsatz (eine GPU, batch 32, FP16): MBF erzielt mehrere Tausend Embeddings pro Sekunde, R100 im niedrigen Hunderterbereich. Immer auf Zielhardware messen.
6. Open-Source-Pakete an die Workload anpassen
Für die meisten Produktentwicklungen reicht es, zwischen zwei Open-Source-Paketen zu wählen: buffalo_s (und das noch kleinere buffalo_sc) für Mobile und Edge sowie buffalo_l für den Server.
buffalo_s / buffalo_sc sind die richtige Wahl für Face-Unlock auf dem Gerät, mobile SDK-Integrationen, Embedded-Boxen und alle Workloads, in denen Latenz und Binärgröße wichtiger sind als die absolute Genauigkeit. buffalo_l (w600k_r50) ist die richtige Wahl für jegliche serverseitige Erkennung: 1:1-Verifikation, 1:N-Identifikation auf Galerien bis zu einigen hunderttausend Identitäten und Ziel-FMR um 1e-5.
- Mobile / Edge: buffalo_s wählen, oder buffalo_sc, wenn Speicher- oder Compute-Budget knapp sind.
- Server: buffalo_l wählen. Es ist das stärkste von uns ausgelieferte Open-Source-Erkennungspaket und deckt die Mehrzahl kooperativer Verifikations- und Identifikationsszenarien ab.
- Open-Source-Pakete reichen für die meisten Produktfunktionen, die bei kooperativen Aufnahmen mit FMR >= 1e-5 betrieben werden. Darüber hinaus siehe nächsten Abschnitt.
7. Wann ein Wechsel auf die kommerziellen InsightFace-Modelle sinnvoll ist
Die kommerziellen Erkennungsmodelle von InsightFace werden auf wesentlich größeren und vielfältigeren Identitätsmengen mit proprietären Loss-Formulierungen und Trainingsrezepten trainiert und mit dokumentierten Betriebspunkten sowie signierten Artefakten ausgeliefert. Sie sind nicht einfach das "Open-Source-Modell mit mehr Parametern".
Konkret: Auf internen, demografisch ausgewogenen 1:1-Protokollen bei FMR = 1e-6 reduzieren die kommerziellen Modelle die FNMR typischerweise um den Faktor 2-5 gegenüber dem stärksten Open-Source-Paket (z. B. fällt die FNMR auf schwierigen Teilmengen wie maskiert, große Pose oder niedriger Auflösung etwa von 5-8 % auf 1-2 %). Auf demografisch ausgewogenem 1:N mit Galerien ab 1 Mio. Einträgen sinkt die FNIR bei festgelegter FPIR um ähnliche Verhältnisse, und der Abstand zwischen bester und schlechtester demografischer Untergruppe an strengen Betriebspunkten wird kleiner.
Damit Sie die Wechselentscheidung auf Ihren eigenen Daten leicht überprüfen können, bieten wir nach Abschluss einer vorbereitenden Kooperationsvereinbarung (NDA / Pilotvertrag) eine 2-wöchige kostenlose Evaluierung der kommerziellen Erkennungsmodelle an. Während des Trials erhalten Sie zeitlich begrenzten Zugriff auf die kommerziellen Modellartefakte oder die gehostete API, können dieselben FRVT-konformen 1:1- und 1:N-Tests aus diesem Leitfaden durchführen und die Werte direkt mit dem aktuell genutzten Open-Source-Paket vergleichen, bevor eine kommerzielle Bindung erfolgt.
- Wählen Sie die kommerziellen Modelle, wenn Sie bei FMR <= 1e-6 betreiben, etwa Grenzkontrolle, Zahlungsfreigabe oder regulierter KYC.
- Wählen Sie sie, wenn die Galerie 100k bis 1 Mio. Identitäten überschreitet und Rang-1-Stabilität wichtig ist.
- Wählen Sie sie, wenn Fairness-Audits den Abstand zwischen bester und schlechtester demografischer Untergruppe an strengen Betriebspunkten schließen müssen.
- Wählen Sie sie, wenn die Produktion schwierige Bedingungen umfasst: starke Verdeckung, große Pose, niedrige Auflösung (unter ca. 48 px Pupillenabstand) oder nicht-kooperative Aufnahme.
- Wählen Sie sie, wenn Sie Enterprise-SLA, On-Premise-Lizenzierung, integrierte PAD/Liveness, signierte Modellartefakte und Haftungsfreistellung benötigen.
- Schließen Sie eine vorbereitende Kooperationsvereinbarung ab, um vor jeder kommerziellen Bindung eine 2-wöchige kostenlose Evaluierung auf Ihren eigenen Daten zu starten.
8. Produktiver Rollout und laufende Bewertung
Sperren Sie Modellartefakt (kryptografischer Hash), Vorverarbeitungs-Codepfad, Schwellenwert und Metrikdefinition gemeinsam als eine Release-Einheit. Änderungen an der Vorverarbeitung verschieben die FMR unbemerkt; das Versionieren der Vorverarbeitung ist mindestens so wichtig wie das der Gewichte.
Bewerten Sie regelmäßig - mindestens quartalsweise - mit frischen Produktionsdaten. Die wichtigste Live-Kennzahl ist die FMR am produktiven Schwellenwert, gemessen gegen einen frischen Impostor-Satz; sie zeigt, ob der dem Geschäft zugesagte Betriebspunkt noch hält.
- FMR-/FNMR-Drift, Falschalarmquote, Operator-Override-Rate und demografische Deltas gemeinsam tracken.
- Einen Rollback-Plan vorhalten. Schwellenwert und Modell sind gemeinsam versioniert; nie nur eines zurückrollen.
- Bei Modellwechseln zuerst den Schwellenwert neu bestimmen und den Betriebspunkt neu veröffentlichen, bevor produktiver Verkehr umgeschaltet wird.
Benötigen Sie Hilfe beim Produktions-Deployment?
Kontaktieren Sie InsightFace für Modelllizenzen, Runtime-Optimierung und Deployment-Support für Ihre Zielhardware.
Kontakt aufnehmen