Cómo elegir un modelo de reconocimiento facial: pruebas 1:1, 1:N y selección de umbral
Una guía alineada con FRVT para elegir un modelo de reconocimiento de InsightFace, construir benchmarks 1:1 y 1:N, fijar umbrales y decidir cuándo pasar de los packs open source a los modelos comerciales de InsightFace.
Qué vas a construir
La mayoría de los fallos en reconocimiento facial no están en el código, sino en la elección del modelo y en el ajuste del umbral. Un modelo bien situado en una tabla pública puede comportarse mal con sus datos porque el punto de operación, la composición demográfica, la calidad de captura y el tamaño de la galería son distintos.
Esta guía propone un marco de evaluación neutral respecto a proveedores y alineado con la metodología NIST FRVT. Cubre la verificación 1:1 y la identificación 1:N, las métricas que sí importan, cómo montar una prueba defendible, los valores públicos esperables de los packs open source de InsightFace y las condiciones bajo las cuales los modelos comerciales de InsightFace son la elección correcta, explicando en cifras concretas qué significa esa mayor precisión.
Antes de empezar
- Soltura para ejecutar InsightFace mediante el paquete Python insightface o ONNX Runtime para detección, alineación y extracción de embeddings.
- Un conjunto de validación representativo que cubra la demografía, el rango de edad, la pose, la iluminación, la oclusión (mascarilla, gafas, cabello), la calidad de cámara y la distancia de captura del tráfico de producción.
- Conocimientos básicos de numpy y scikit-learn para análisis de ROC, DET y distribuciones de similitud.
- Un punto de operación objetivo claramente definido en términos de FMR o FPIR (por ejemplo, FMR = 1e-5), no solo un porcentaje de precisión.
1. Decida si su problema es 1:1 o 1:N
La verificación 1:1 responde a "¿es esta persona la identidad reclamada?". Compara una plantilla sonda con una plantilla inscrita y devuelve un score de similitud junto con la decisión mismo/distinto. Casos típicos: desbloqueo de dispositivo, KYC (selfie contra documento), confirmación de pago y reautenticación.
La identificación 1:N responde a "¿quién, si alguien, es esta persona entre N identidades inscritas?". Compara una sonda contra una galería de N plantillas y devuelve una lista de candidatos. Casos típicos: torniquetes de control de acceso, alertas de listas de vigilancia, control de presencia y deduplicación. Un modelo puntero en LFW 1:1 no escala automáticamente a galerías 1:N de 10^5 o 10^6, y por eso NIST publica FRVT 1:1 y FRVT 1:N como informes separados.
- El tráfico 1:1 está dominado por comparaciones del mismo individuo; el coste del falso positivo se contabiliza por transacción.
- El tráfico 1:N está dominado por comparaciones de distintos individuos (en listas de vigilancia, la mayoría de las sondas no están en la galería); la tasa de falsos positivos crece con N.
- Defina primero la carga de trabajo: el mismo backbone necesita umbrales distintos para 1:1 y para 1:N.
2. Adopte métricas al estilo FRVT
Abandone la "accuracy" como número único. Los informes de FRVT dan dos tasas de error complementarias en un punto de operación fijo y trazan la curva para ver el compromiso.
En 1:1 use FMR (False Match Rate) y FNMR (False Non-Match Rate). Fije una FMR objetivo (típicamente 1e-4, 1e-5 o 1e-6) y reporte la FNMR en ese punto. En 1:N use FPIR (False Positive Identification Rate) y FNIR (False Negative Identification Rate). Especifique siempre el tamaño de galería N, el rango y si la prueba es de conjunto cerrado (la sonda siempre está en la galería) o abierto (puede no estar).
- Publique siempre el umbral junto al número reportado; una FNMR sin FMR o una FNIR sin FPIR no significa nada.
- Trace curvas DET (Detection Error Tradeoff) en lugar de ROC; se leen mejor en el régimen de tasas bajas.
- Reporte resultados por estrato demográfico y no solo el agregado, en línea con los estudios de efectos demográficos de FRVT.
3. Construya un conjunto de prueba defendible
Los pares de mismo individuo y los de distintos individuos se muestrean por separado. Para estimar con confianza estadística una FMR = 1e-6 en 1:1 hace falta del orden de 10 / FMR = 10^7 comparaciones de distinto individuo. Reutilizar la misma sonda en varios pares es admisible, pero declare honestamente el tamaño efectivo de la muestra.
Estratifique por grupo demográfico, dispositivo de captura, interior/exterior, diferencia de edad entre inscripción y sonda, tipo de oclusión y pose de cabeza. Reporte por estrato y no solo el promedio. Mantenga los datos de prueba estrictamente disjuntos respecto a los datos usados en entrenamiento, ajuste fino o preentrenamiento (Glint360K, WebFace42M, MS1MV3, etc.) y documente procedencia y consentimiento.
- Use al menos 10 / FMR objetivo comparaciones de distinto individuo; con menos, el intervalo de confianza de la FMR es muy amplio.
- Congele el conjunto de prueba. Un conjunto de prueba contra el que se itera continuamente acaba siendo, de hecho, un conjunto de validación.
- Mantenga un subconjunto pequeño y bloqueado, llamado "golden", que se vuelve a ejecutar ante cualquier cambio de modelo o de preprocesado.
4. Calcule embeddings, similitud y umbrales
Use el preprocesado oficial del paquete: detección con RetinaFace o SCRFD, alineación con 5 puntos, recorte 112x112 RGB y la mean/std que acompaña al pack de reconocimiento. Un preprocesado distinto es, con diferencia, la causa más frecuente de que las cifras publicadas no se reproduzcan.
Estandarice en similitud coseno sobre embeddings normalizados con L2. La API Python de InsightFace expone face.normed_embedding precisamente para esto. Elija el umbral en una partición de validación, congélelo y luego evalúe sobre la prueba; elegirlo sobre el conjunto de prueba infla los resultados.
- Los umbrales 1:1 típicos para los packs de InsightFace caen en coseno 0,30-0,45 a FMR = 1e-4 - 1e-5; el valor exacto depende del backbone, los datos de entrenamiento y su población, así que recalcúlelo siempre.
- La normalización de scores (z-norm, t-norm) ayuda cuando la distribución de la galería cambia entre despliegues.
- Si hace ajuste fino, recalcule el umbral; nunca lo arrastre entre versiones de modelo.
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. Benchmark de los modelos open source de InsightFace
El paquete Python insightface distribuye packs listos para usar que combinan un detector y un backbone de reconocimiento. Los packs de reconocimiento más utilizados son buffalo_sc y buffalo_s (móvil / edge), buffalo_m (equilibrado), buffalo_l con cabezal w600k_r50 (default de servidor) y antelopev2 con cabezal glintr100 (servidor grande). El Model Zoo publica además los pesos crudos R50 y R100 ArcFace.
Los resultados públicos en benchmarks académicos estándar (LFW, CFP-FP, AgeDB-30, IJB-B, IJB-C) sitúan a estos packs en los siguientes órdenes de magnitud. Tómelos como referencia y recálculelos con sus datos.
- Precisión 1:1 en LFW: 99,50 % (MBF móvil) hasta 99,85 % (R100, w600k_r50). LFW está saturado y solo sirve como prueba de cordura.
- CFP-FP (frontal vs perfil): 96-99 % en toda la gama, con clara ventaja de la clase R100 en perfil.
- AgeDB-30: 96-98,5 % en toda la gama; los packs grandes manejan mejor la diferencia de edad.
- IJB-C TAR @ FAR = 1e-4: aproximadamente 90-93 % para MBF / móvil, 95-96 % para R50 y 96-97,5 % para R100 / w600k_r50 / glintr100.
- MFR (Multi-racial Face Recognition, protocolo de la challenge ICCV-21 / 22 que cubre las cohortes African, Caucasian, East Asian, South Asian y Mixed a FMR = 1e-6 / 1e-5): la brecha de TAR entre la mejor y la peor cohorte se ensancha a medida que el modelo se vuelve más pequeño. Los packs de clase R100 (w600k_r50, glintr100) suelen quedarse dentro de unos pocos puntos porcentuales entre cohortes, R50 se abre a brechas de un dígito medio y MBF móvil puede mostrar brechas de dos dígitos en la cohorte más difícil; reproduzca esto sobre su propia población antes de fijar un punto de operación.
- Throughput (una sola GPU, batch 32, FP16): MBF logra varios miles de embeddings por segundo, R100 baja a centenas. Mida siempre en su hardware objetivo.
6. Encaje del pack open source con la carga de trabajo
Para la mayoría de los desarrollos de producto basta con elegir entre dos packs open source: buffalo_s (y su variante más ligera buffalo_sc) para móvil y edge, y buffalo_l para servidor.
buffalo_s / buffalo_sc son la opción adecuada para desbloqueo facial en dispositivo, integraciones del SDK móvil, cajas embebidas y cualquier carga en la que la latencia y el tamaño del binario manden sobre la precisión absoluta. buffalo_l (w600k_r50) es la opción adecuada para cualquier reconocimiento del lado servidor: verificación 1:1, identificación 1:N en galerías de hasta unos cientos de miles de identidades y FMR objetivo cercana a 1e-5.
- Móvil / edge: elija buffalo_s, o buffalo_sc cuando esté limitado en memoria o presupuesto de cómputo.
- Servidor: elija buffalo_l. Es el pack de reconocimiento open source más fuerte que ofrecemos y cubre la mayoría de los escenarios de verificación e identificación con captura cooperativa.
- Los packs open source bastan para la mayoría de funciones de producto que operan a FMR >= 1e-5 con captura cooperativa. Más allá de eso, vea la siguiente sección.
7. Cuándo migrar a los modelos comerciales de InsightFace
Los modelos comerciales de reconocimiento de InsightFace se entrenan sobre conjuntos de identidades sustancialmente mayores y más diversos, con formulaciones de pérdida y recetas de entrenamiento propias, y se entregan con puntos de operación documentados y artefactos firmados. No son simplemente "el modelo open source con más parámetros".
En cifras concretas, en protocolos internos de 1:1 demográficamente equilibrados a FMR = 1e-6, los modelos comerciales suelen reducir la FNMR en un factor de 2-5x respecto al pack open source más fuerte (por ejemplo, la FNMR pasa de aproximadamente 5-8 % a 1-2 % en subconjuntos difíciles como mascarilla, pose grande o baja resolución). En 1:N demográficamente equilibrado con galerías de 1 M+, la FNIR a FPIR fija baja en proporciones similares y se estrecha la brecha entre el subgrupo demográfico mejor y peor en puntos de operación estrictos.
Para que la decisión de migrar sea fácil de validar con sus propios datos, ofrecemos una evaluación gratuita de 2 semanas de los modelos comerciales de reconocimiento tras la firma de un acuerdo preliminar de cooperación (NDA / acuerdo de piloto). Durante el periodo de prueba recibe acceso temporal a los artefactos de modelo comercial o a la API gestionada, puede ejecutar las mismas pruebas 1:1 y 1:N de estilo FRVT descritas en esta guía y comparar las cifras directamente con el pack open source que utiliza actualmente, antes de cualquier compromiso comercial.
- Elija los modelos comerciales cuando opere a FMR <= 1e-6, por ejemplo control fronterizo, autorización de pagos o KYC regulado.
- Elíjalos cuando la galería supere las 100k-1M identidades y la estabilidad del rango 1 sea crítica.
- Elíjalos cuando las auditorías de equidad exijan cerrar la diferencia entre el mejor y el peor subgrupo demográfico en puntos de operación estrictos.
- Elíjalos cuando la producción incluya condiciones duras: oclusión severa, pose grande, baja resolución (distancia interpupilar inferior a ~48 px) o captura no cooperativa.
- Elíjalos cuando necesite SLA empresarial, licencia on-premise, PAD / liveness integrado, artefactos de modelo firmados e indemnización contractual.
- Firme un acuerdo preliminar de cooperación para iniciar una evaluación gratuita de 2 semanas con sus propios datos antes de cualquier compromiso comercial.
8. Despliegue en producción y evaluación continua
Bloquee el artefacto de modelo (hash criptográfico), la ruta de código del preprocesado, el umbral y la definición de métrica como una sola unidad de release. Los cambios de preprocesado mueven la FMR de forma silenciosa, por lo que versionar el preprocesado importa al menos tanto como versionar los pesos.
Reevalúe con muestras frescas de producción de forma periódica, como mínimo trimestralmente. La métrica viva más importante es la FMR al umbral de producción, calculada contra un conjunto fresco de impostores; le dice si el punto de operación que prometió al negocio sigue vigente.
- Monitorice deriva de FMR / FNMR, tasa de falsa alarma, tasa de override del operador y deltas demográficos en conjunto.
- Tenga un plan de rollback. Umbral y modelo se versionan juntos; nunca se revierte uno sin el otro.
- Al cambiar de modelo, recalcule el umbral y vuelva a publicar el punto de operación antes de redirigir el tráfico de producción.
¿Necesitas ayuda con el despliegue en producción?
Contacta con InsightFace para licencias de modelos, optimización de runtime y soporte de despliegue en tu hardware objetivo.
Contactar