Quando 90% de Accuracy Não Significa Nada: Avaliando IA em Produção

A discussão recente no Hacker News que atingiu 365 pontos tocou em algo que muitos times de ML já sabem na prática: modelos com métricas impressionantes em benchmarks podem falhar espetacularmente em produção. O GPT-4 alcança cerca de 90% no MMLU, um dos benchmarks mais citados. Ainda assim, comete erros básicos de raciocínio lógico que qualquer desenvolvedor júnior evitaria.

A Netflix documentou que 23% dos incidentes de ML em produção eram edge cases presentes em menos de 0.1% dos dados de treinamento, mas com impacto desproporcional. Esses casos não apareciam em nenhuma métrica de accuracy tradicional. Quando você deploya um modelo que responde perguntas de clientes ou gera código, accuracy agregada não captura o que realmente importa: hallucinations silenciosas, outputs contraditórios, ou degradação em inputs levemente diferentes do esperado.

O problema não é falta de ferramentas. Frameworks como HELM da Stanford avaliam 7 dimensões diferentes além de accuracy, mas implementar avaliação realista tem custos: HELM custa $10k-50k por modelo completo, tornando iteração rápida inviável. A questão central é construir pipelines de avaliação que capturem falhas reais sem explodir o orçamento ou tempo de desenvolvimento.

O Gap Entre Benchmarks e Realidade de Produção

MMLU e BIG-bench dominam discussões sobre performance de modelos. Ambos têm limitações bem documentadas: 67% das 204 tarefas do BIG-bench correlacionam fortemente com accuracy simples, limitando a diversidade real de cenários testados. MMLU usa formato de múltipla escolha, que sistematicamente infla scores comparado a tarefas de geração livre. Modelos podem memorizar padrões dos datasets de treino sem realmente entender os conceitos.

Esses benchmarks não preveem performance em seguir instruções complexas ou manter consistência ao longo de múltiplas interações. O Uber Engineering reportou que testes de metamorphic relations (verificar se mudanças previsíveis no input produzem mudanças esperadas no output) detectaram 40% mais bugs que testes de accuracy isolados.

A Google Cloud AI identificou 5 tipos de falha que accuracy ignora completamente:

1. Silent failures: o modelo retorna algo sintaticamente correto mas factualmente errado, sem sinalizar incerteza
2. Distribution drift: performance degrada gradualmente conforme dados em produção divergem do treino
3. Long-tail inputs: edge cases raros mas críticos para experiência do usuário
4. Contradictory outputs: respostas diferentes para perguntas semanticamente equivalentes
5. Latency spikes: P95/P99 de tempo de resposta que accuracy tests não capturam

Databricks documentou que shadow mode testing (rodar modelo novo em paralelo com produção sem afetar usuários) captura 3-5x mais falhas que testes offline. Você expõe o modelo a distribuição real de inputs, incluindo casos que ninguém pensou em incluir no test set.

Frameworks Práticos Para Ir Além de Accuracy

Implementar avaliação holística não precisa ser um projeto de meses. Existem frameworks com implementações concretas que você pode integrar gradualmente.

Métricas de Confiabilidade Fundamentais

MLflow 2.9+, lançado em 2024, introduziu suporte nativo para avaliar LLMs em dimensões além de accuracy. O framework mede relevância (output realmente responde a pergunta), groundedness (claims são suportados por fontes fornecidas), e rastreabilidade (é possível verificar de onde informações vieram). Essas métricas capturam problemas que aparecem constantemente em produção: modelos que respondem coisas tangencialmente relacionadas mas não úteis, ou que inventam fatos plausíveis sem base.

Azure AI Studio implementa evaluation flows medindo safety, coherence, fluency, groundedness e relevance como métricas separadas. Cada dimensão expõe tipos diferentes de falha. Um modelo pode ter alta fluency mas baixa groundedness - gera texto bonito mas factualmente questionável. Ou alta relevance mas baixa safety - responde a pergunta mas viola políticas de uso.

Para detectar hallucinations especificamente, TruthfulQA contém 817 questões adversariais projetadas para induzir modelos a gerar informações falsas mas plausíveis. HaluEval vai além com 35,000 exemplos cobrindo QA, summarization e dialogue. Esses datasets focam em tipos de erros que humanos raramente perceberiam sem verificação cuidadosa - exatamente o cenário perigoso em produção.

Robustez e Fairness na Prática

RobustBench documenta que modelos com 95%+ de clean accuracy caem para 60-70% sob ataques adversariais pequenos (epsilon de 8/255). Esses ataques não são teóricos: representam perturbações naturais como typos, variações de sintaxe ou paráfrases que usuários reais produzem.

O Robustness Gym permite testar sistematicamente 20+ tipos de perturbações: typos intencionais, negação, mudanças de ordem de palavras, inserção de contexto irrelevante. A ferramenta identifica quais transformações quebram seu modelo. Para um sistema de atendimento ao cliente, descobrir que adicionar “por favor” muda completamente a resposta é um bug crítico que accuracy não revelaria.

Para fairness, IBM AIF360 oferece 70+ métricas incluindo disparate impact (razão de outcomes positivos entre grupos) e equalized odds (taxas de erro balanceadas). A documentação oficial não especifica thresholds universais porque fairness depende do contexto específico, mas o framework permite quantificar se seu modelo trata diferentes populações de forma consistente.

Avaliação Adversarial Sistemática

OpenAI Evals implementa 1000+ testes incluindo adversarial robustness. AdvBench contém 520 comportamentos nocivos testando jailbreaks em modelos comerciais. Modelos comerciais têm taxa de sucesso de ataque adversarial de 20-88% no AdvBench - range massivo que accuracy padrão nunca revelaria.

A técnica “LLM-as-judge” ganhou popularidade em 2024 para avaliar qualidade quando ground truth não existe. Você usa um modelo mais forte (geralmente GPT-4) para julgar outputs de modelos menores segundo critérios específicos. Weights & Biases documenta casos onde essa abordagem detecta problemas sutis de qualidade que métricas automáticas perdem. A limitação óbvia é que você está avaliando um modelo potencialmente falho com outro modelo potencialmente falho, mas empiricamente funciona melhor que não ter avaliação qualitativa nenhuma.

Custos Reais e Trade-offs de Implementação

Implementar avaliação completa tem custos que precisam ser explicitados. HELM oferece avaliação compreensiva mas custa $10k-50k por modelo, tornando inviável para iteração rápida. Isso não significa que você não deve fazer - significa que precisa priorizar quais dimensões são críticas para sua aplicação.

O case study da Anthropic sobre Constitutional AI mostra trade-offs quantificados: testes adversariais reduziram harmful outputs de 18% para 2%, mas aumentaram recusas legítimas de 3% para 8%. Seu modelo ficou mais seguro mas também mais conservador. Para aplicações onde false positives (recusar pedidos legítimos) são tão ruins quanto false negatives (aceitar pedidos problemáticos), esse trade-off pode não ser aceitável.

Cohere documentou que gradient-based adversarial training aumentou custo de treinamento em 3x mas melhorou robustez em 45%. Você precisa decidir se o custo adicional vale a pena. Para sistemas críticos como moderação de conteúdo ou diagnóstico médico, provavelmente sim. Para features experimentais internas, talvez não.

Monitoramento Contínuo em Produção

AWS SageMaker Model Monitor detecta quatro tipos de drift: data drift (distribuição de features muda), concept drift (relação entre features e target muda), feature attribution drift (importância de features muda), e bias drift (fairness metrics degradam). Cada tipo requer resposta diferente - data drift pode precisar re-treino, concept drift pode indicar mudanças fundamentais no domínio.

A Meta AI usa “canary queries” - 1000+ inputs cuidadosamente selecionados testados em cada deploy para capturar regressões. A abordagem é simples mas efetiva: você mantém um set de casos críticos e verifica que novos deploys não quebram nada que funcionava. Frameworks open-source maduros para implementar isso de forma generalizada ainda não estão disponíveis, então você precisará construir internamente.

A correlação quantificada entre métricas offline (HELM, BIG-bench) e incidentes reais em produção não está publicamente documentada. Essa lacuna é significativa - não temos evidência sólida de quanto avaliações offline realmente preveem problemas em produção. Shadow mode testing resolve isso parcialmente ao expor modelos a dados reais antes do deploy completo.

Implementando Avaliação Realista Sem Explodir Orçamento

Começar com avaliação holística não requer implementar tudo simultaneamente. Uma abordagem pragmática:

Fase 1: Adicione métricas básicas além de accuracy usando MLflow ou Azure AI Studio. Groundedness e relevance capturam maioria dos problemas críticos com overhead mínimo. Implemente logging estruturado de inputs/outputs para análise posterior.

Fase 2: Integre testes adversariais focados em seus failure modes específicos. Use Robustness Gym para identificar perturbações que quebram seu modelo. Se você processa user input livre, teste typos e variações sintáticas. Se faz retrieval, teste contextos contraditórios.

Fase 3: Implemente shadow mode testing antes de deploys significativos. Rode modelo novo em paralelo por dias/semanas capturando divergências de comportamento. Databricks documenta que isso captura 3-5x mais problemas que testes offline.

Fase 4: Construa sistema de canary queries mantendo set de casos críticos testados continuamente. Comece pequeno - 50-100 queries cobrindo edge cases conhecidos e vá expandindo conforme descobre novos problemas.

A ordem importa menos que implementar incrementalmente. Accuracy sozinha é insuficiente, mas você não precisa implementar framework de $50k no primeiro sprint. Comece medindo o que impacta seus usuários mais diretamente e expanda conforme entende melhor seus failure modes específicos.

Benchmarks públicos como MMLU continuarão sendo usados para comparar modelos, mas sua utilidade em prever performance real de produção é limitada. Para sistemas onde confiabilidade importa - e se você está deployando em produção, confiabilidade importa - você precisa de métricas que capturam como modelos falham, não apenas quão frequentemente acertam.