← Voltar aos guias
Reconhecimento facialVerificação 1:1Identificação 1:NFRVTBenchmarkLimiar

Como escolher um modelo de reconhecimento facial: testes 1:1, 1:N e definição de limiar

Um guia alinhado ao FRVT para escolher um modelo de reconhecimento da InsightFace, montar benchmarks 1:1 e 1:N, definir limiares e decidir quando migrar dos packs open source para os modelos comerciais da InsightFace.

Leitura de 14 min

O que você vai construir

A maior parte dos erros em reconhecimento facial não está no código, mas na escolha do modelo e no ajuste do limiar. Um modelo bem colocado em um ranking público pode falhar nos seus dados porque o ponto de operação, a composição demográfica, a qualidade de captura e o tamanho da galeria são diferentes.

Este guia apresenta um framework de avaliação independente de fornecedor, alinhado à metodologia do NIST FRVT. Cobre a verificação 1:1, a identificação 1:N, as métricas que de fato importam, como construir um teste defensável, os números públicos esperáveis dos packs open source da InsightFace e as condições nas quais os modelos comerciais da InsightFace fazem sentido — explicando, em números concretos, o que significa essa precisão maior.

Antes de começar

  • Familiaridade com a execução do InsightFace via pacote Python insightface ou ONNX Runtime para detecção, alinhamento e extração de embeddings.
  • Um conjunto de validação representativo cobrindo demografia, faixa etária, pose, iluminação, oclusão (máscara, óculos, cabelo), qualidade de câmera e distância de captura do tráfego de produção.
  • Conhecimento básico de numpy e scikit-learn para análise de ROC, DET e distribuição de scores de similaridade.
  • Um ponto de operação alvo claramente definido em FMR ou FPIR (por exemplo, FMR = 1e-5), e não apenas um percentual de acurácia.

1. Decida se o problema é 1:1 ou 1:N

A verificação 1:1 responde a "esta pessoa é mesmo a identidade alegada?". Compara um template-sonda com um template inscrito e devolve um score de similaridade e a decisão igual/diferente. Casos típicos: desbloqueio de dispositivo, KYC (selfie versus documento), confirmação de pagamento e reautenticação.

A identificação 1:N responde a "quem é esta pessoa, se houver, entre N identidades inscritas?". Compara uma sonda contra uma galeria de N templates e devolve uma lista de candidatos. Casos típicos: catracas de controle de acesso, alertas de listas de vigilância, presença e deduplicação. Um modelo no topo do LFW 1:1 não escala automaticamente para 1:N em galerias de 10^5 ou 10^6, e é por isso que o NIST publica FRVT 1:1 e FRVT 1:N como relatórios separados.

  • O tráfego 1:1 é dominado por comparações de mesma pessoa; o custo de uma falsa correspondência é por transação.
  • O tráfego 1:N é dominado por comparações de pessoas distintas (em listas de vigilância, a maioria das sondas nem está na galeria); a taxa de falsos positivos cresce com N.
  • Defina primeiro a carga de trabalho. O mesmo backbone exige limiares distintos para 1:1 e 1:N.

2. Adote métricas no estilo FRVT

Abandone a "accuracy" como número único. Os relatórios FRVT publicam, em um ponto de operação fixo, duas taxas de erro complementares e traçam a curva para mostrar o trade-off.

Em 1:1, use FMR (False Match Rate) e FNMR (False Non-Match Rate). Defina uma FMR alvo (tipicamente 1e-4, 1e-5 ou 1e-6) e reporte a FNMR nesse ponto. Em 1:N, use FPIR (False Positive Identification Rate) e FNIR (False Negative Identification Rate). Sempre informe o tamanho da galeria N, o rank e se o teste é de conjunto fechado (a sonda está sempre na galeria) ou aberto (pode não estar).

  • Sempre publique o limiar junto da métrica; FNMR sem FMR ou FNIR sem FPIR não significa nada.
  • Trace curvas DET (Detection Error Tradeoff) em vez de ROC; são mais legíveis em regimes de baixa taxa de erro.
  • Reporte por estrato demográfico, e não só o agregado, em linha com os estudos de efeitos demográficos do FRVT.

3. Construa um conjunto de teste defensável

Pares de mesma pessoa e de pessoas distintas são amostrados separadamente. Para estimar com confiança estatística uma FMR = 1e-6 em 1:1 são necessárias da ordem de 10 / FMR = 10^7 comparações de pessoas distintas. Reaproveitar a mesma sonda em vários pares é aceitável, mas o tamanho efetivo da amostra deve ser reportado com honestidade.

Estratifique por grupo demográfico, dispositivo de captura, interno/externo, diferença de idade entre a inscrição e a sonda, tipo de oclusão e pose. Reporte por estrato e não apenas a média. Mantenha os dados de teste estritamente disjuntos de qualquer dado usado em treino, fine-tuning ou pré-treino (Glint360K, WebFace42M, MS1MV3, etc.) e documente origem e consentimento.

  • Use ao menos 10 / FMR alvo de comparações entre pessoas distintas; abaixo disso o intervalo de confiança da FMR fica largo.
  • Congele o conjunto de teste. Um conjunto de teste contra o qual se ajusta continuamente vira, na prática, conjunto de validação.
  • Mantenha um subconjunto pequeno e travado, chamado "golden", reexecutado a cada troca de modelo ou de pré-processamento.

4. Calcule embeddings, similaridade e limiares

Use o pré-processamento oficial do pacote: detecção com RetinaFace ou SCRFD, alinhamento de 5 pontos, recorte 112x112 RGB e a mean/std que acompanha o pack de reconhecimento. Pré-processamento divergente é, de longe, o motivo mais comum de não conseguir reproduzir números publicados.

Padronize a similaridade do cosseno sobre embeddings normalizados em L2. A API Python do InsightFace expõe face.normed_embedding exatamente para isso. Escolha o limiar em uma partição de validação, congele-o e depois avalie no teste; escolher o limiar no teste infla os resultados.

  • Os limiares 1:1 típicos para os packs do InsightFace ficam em cosseno 0,30–0,45 a FMR = 1e-4 — 1e-5; o valor exato depende do backbone, dos dados de treino e da sua população, então recalcule sempre.
  • Normalização de scores (z-norm, t-norm) ajuda quando a distribuição da galeria muda entre deployments.
  • Se houver fine-tuning, recalcule o limiar; nunca arraste limiar entre versões de modelo.
Calcular e normalizar (L2) embeddings
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-normalized
Varredura de limiar até atingir a FMR alvo em 1:1
import 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}")
Calcular FPIR / FNIR em um teste 1:N de conjunto aberto
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 dos modelos open source da InsightFace

O pacote Python insightface distribui packs prontos que combinam um detector e um backbone de reconhecimento. Os packs de reconhecimento mais usados são buffalo_sc e buffalo_s (mobile / edge), buffalo_m (equilibrado), buffalo_l com cabeça w600k_r50 (default de servidor) e antelopev2 com cabeça glintr100 (servidor grande). O Model Zoo também publica os pesos crus R50 e R100 ArcFace.

Resultados públicos em benchmarks acadêmicos padrão (LFW, CFP-FP, AgeDB-30, IJB-B, IJB-C) posicionam esses packs nos seguintes patamares de ordem de grandeza. Tome como referência e recalcule nos seus dados.

  • Acurácia LFW 1:1: 99,50 % (MBF mobile) a 99,85 % (R100, w600k_r50). LFW está saturado e só serve como sanity check.
  • CFP-FP (frontal vs perfil): 96–99 % na linha toda, classe R100 claramente à frente em perfil.
  • AgeDB-30: 96–98,5 % na linha toda; packs grandes lidam melhor com diferença de idade.
  • IJB-C TAR @ FAR = 1e-4: cerca de 90–93 % para MBF / mobile, 95–96 % para R50 e 96–97,5 % para R100 / w600k_r50 / glintr100.
  • MFR (Multi-racial Face Recognition, protocolo do challenge ICCV-21 / 22 cobrindo as coortes African, Caucasian, East Asian, South Asian e Mixed a FMR = 1e-6 / 1e-5): a diferença de TAR entre a melhor e a pior coorte aumenta à medida que o modelo encolhe. Packs da classe R100 (w600k_r50, glintr100) costumam ficar dentro de poucos pontos percentuais entre coortes, R50 abre para diferenças de um dígito médio e o MBF mobile pode chegar a diferenças de dois dígitos na coorte mais difícil — reproduza esse teste na sua própria população antes de fixar um ponto de operação.
  • Throughput (uma única GPU, batch 32, FP16): MBF chega a vários milhares de embeddings por segundo, R100 fica na casa baixa de centenas. Sempre meça no hardware alvo.

6. Casamento entre pack open source e carga de trabalho

Para a maioria dos desenvolvimentos de produto basta escolher entre dois packs open source: buffalo_s (e o seu irmão mais leve buffalo_sc) para mobile e edge, e buffalo_l para servidor.

buffalo_s / buffalo_sc são a escolha certa para desbloqueio facial em dispositivo, integrações do SDK mobile, caixas embarcadas e qualquer carga em que latência e tamanho do binário pesem mais do que precisão absoluta. buffalo_l (w600k_r50) é a escolha certa para qualquer reconhecimento do lado servidor: verificação 1:1, identificação 1:N em galerias de até algumas centenas de milhares de identidades e FMR alvo em torno de 1e-5.

  • Mobile / edge: escolha buffalo_s, ou buffalo_sc quando estiver limitado em memória ou orçamento de cômputo.
  • Servidor: escolha buffalo_l. É o pack open source de reconhecimento mais forte que entregamos e cobre a maioria dos cenários de verificação e identificação com captura cooperativa.
  • Os packs open source bastam para a maioria das funcionalidades de produto que operam a FMR >= 1e-5 em capturas cooperativas. Além disso, veja a próxima seção.

7. Quando migrar para os modelos comerciais da InsightFace

Os modelos comerciais de reconhecimento da InsightFace são treinados em conjuntos de identidades substancialmente maiores e mais diversos, com formulações de loss e receitas de treino proprietárias, e entregues com pontos de operação documentados e artefatos assinados. Não são simplesmente "o modelo open source com mais parâmetros".

Em números concretos, em protocolos internos 1:1 demograficamente equilibrados a FMR = 1e-6, os modelos comerciais costumam reduzir a FNMR em um fator de 2 a 5x em relação ao pack open source mais forte (por exemplo, FNMR caindo de cerca de 5–8 % para 1–2 % em subconjuntos difíceis como máscara, pose grande ou baixa resolução). Em 1:N demograficamente equilibrado com galerias de 1 M+, a FNIR a FPIR fixa cai em proporções semelhantes, e a diferença entre o melhor e o pior subgrupo demográfico em pontos estritos diminui.

Para que a decisão de migrar seja fácil de validar com seus próprios dados, oferecemos uma avaliação gratuita de 2 semanas dos modelos comerciais de reconhecimento mediante a assinatura de um acordo preliminar de cooperação (NDA / acordo de piloto). Durante o trial você recebe acesso por tempo limitado aos artefatos do modelo comercial ou à API hospedada, pode rodar os mesmos testes 1:1 e 1:N no estilo FRVT descritos neste guia e comparar os números diretamente com o pack open source que está usando hoje, antes de qualquer compromisso comercial.

  • Escolha os modelos comerciais quando operar a FMR <= 1e-6, por exemplo controle de fronteira, autorização de pagamento ou KYC regulado.
  • Escolha-os quando a galeria ultrapassar 100 mil – 1 M de identidades e a estabilidade do rank-1 for crítica.
  • Escolha-os quando auditorias de equidade exigirem fechar a diferença entre melhor e pior subgrupo demográfico em pontos estritos.
  • Escolha-os quando a produção incluir condições difíceis: oclusão pesada, pose grande, baixa resolução (distância interpupilar abaixo de ~48 px) ou captura não cooperativa.
  • Escolha-os quando precisar de SLA empresarial, licenciamento on-premise, PAD / liveness integrado, artefatos assinados e indenização contratual.
  • Assine um acordo preliminar de cooperação para iniciar uma avaliação gratuita de 2 semanas com seus próprios dados antes de qualquer compromisso comercial.

8. Rollout em produção e avaliação contínua

Trave em conjunto, como uma única unidade de release, o artefato do modelo (hash criptográfico), o caminho de código do pré-processamento, o limiar e a definição da métrica. Mudanças no pré-processamento deslocam silenciosamente a FMR; versionar o pré-processamento importa pelo menos tanto quanto versionar pesos.

Reavalie em amostras frescas de produção em cadência regular, no mínimo trimestral. A métrica viva mais importante é a FMR no limiar de produção, calculada contra um conjunto fresco de impostores; ela diz se o ponto de operação prometido ao negócio ainda se sustenta.

  • Acompanhe deriva de FMR / FNMR, taxa de falso alarme, taxa de override do operador e deltas demográficos em conjunto.
  • Tenha plano de rollback. Limiar e modelo são versionados juntos; nunca reverter um sem o outro.
  • Ao trocar o modelo, recalcule o limiar e republique o ponto de operação antes de virar o tráfego de produção.

Precisa de ajuda com implantação em produção?

Fale com a InsightFace sobre licenciamento de modelos, otimização de runtime e suporte para o hardware alvo.

Entrar em contato