Como avaliar LLMs antes da produção, além dos benchmarks

Um modelo de linguagem pode ir bem em benchmarks e ainda falhar nos casos decisivos da produção: entradas reais são ambíguas, rótulos inconsistentes e o contexto pode faltar ou chegar truncado. A equipe do GitHub enfrentou esses problemas ao avaliar um sistema baseado em LLM para reduzir falsos positivos no secret scanning, ferramenta que identifica credenciais como tokens e chaves possivelmente cometidas em repositórios. Strings candidatas podem lembrar segredos sem representar credenciais reais, e desenvolvedores acabam investigando alertas que não exigem correção. A questão central não era saber se o LLM classificava strings corretamente, mas se o sistema reduziria alertas ruidosos mantendo recall suficiente para ser seguro num fluxo de segurança.

Começar pela decisão de produto

O primeiro passo recomendado é definir a decisão de produto que a avaliação deve sustentar, antes de mexer em prompt, contexto, pipeline ou modelo. Os critérios foram organizados em três níveis: resultado primário (redução de falsos positivos e precisão), restrição de segurança (recall, tratado como guarda-corpo, já que suprimir uma credencial real seria mais grave que pedir revisão extra de um alerta) e guardas operacionais (latência, custo, confiabilidade e compatibilidade com produção). Nenhuma métrica era intercambiável: num exemplo hipotético, um experimento com grande ganho de precisão, mas recall abaixo do limite, não avançava; outro com melhoria moderada dentro do limite continuava em teste.

Off-line como teste de integração

Como prompts, modelos, entradas e lógica de negócio mudam depois da primeira avaliação bem-sucedida, a avaliação foi tratada como teste de integração de ponta a ponta, rerodada a cada mudança relevante. Cada execução registrava prompt, modelo, versão do conjunto de dados e configuração, permitindo comparação contra uma linha de base conhecida. Mudava-se uma variável principal por vez, porque pequenos ajustes de prompt deslocam o comportamento do modelo e trocas de modelo afetam qualidade, custo, latência e formato da saída. Prompts e configurações foram versionados como código, e era possível reverter versões anteriores. O texto observa que um modelo mais forte pode render melhor com um prompt simples do que um modelo antigo muito ajustado, mas toda atualização exige avaliação cuidadosa: ela pode melhorar uma categoria e introduzir regressões em outras.

Espelhar a produção e duvidar dos rótulos

A avaliação off-line só é útil quando imita a tarefa de produção, preservando candidato avaliado, contexto disponível, informações de apoio, formatação e lógica envolvente. No secret scanning, o modelo pode ignorar o valor alvo e raciocinar sobre outra variável cujo nome parece relacionado a seguranças, produzindo uma explicação plausível sobre o valor errado - falha invisível em exemplos limpos e revelada justamente por manter as ambiguidades reais. Rótulos de produção devem ser lidos como sinais, não verdades inquestionáveis: um alerta resolvido pode significar credencial rotacionada, risco aceito, desbloqueio de fluxo ou erro de classificação, estados diferentes que parecem iguais nos dados. Exemplos sintéticos e conjuntos abertos ajudam a cobrir lacunas, como entradas ambíguas, contexto faltante e formatos incomuns, mas complementam sem substituir dados semelhantes aos de produção.

Análise de erros e LLM como juiz

Métricas agregadas dizem se houve melhora, mas não o que ajustar. Revisar amostras de falsos positivos e negativos e agrupá-las por origem provável - modelo, prompt, entrada, pipeline, conjunto de dados ou rótulo - converte um problema vago de qualidade em tarefa concreta de engenharia, e cada categoria sugere uma resposta diferente. Como revisar tudo manualmente não escala, os autores usaram LLM-as-judge para triagem: processar automaticamente casos claros de baixo risco, encaminhar casos conflitantes ou de alto impacto a revisores humanos e amostrar periodicamente casos de alta confiança. Como o juiz também erra, sua saída é tratada como mais uma previsão, jamais como verdade absoluta, e seu prompt é versionado como qualquer outro componente.

Resultado e conclusão

Após avaliações repetidas e análise direcionada de erros, o sistema alcançou 95% de redução de falsos positivos no conjunto off-line avaliado, mantendo o recall dentro do guarda-corpo definido - com a vantagem de explicar como o resultado foi produzido. Antes de seguir adiante, a equipe propõe um checklist cobrindo metas de produto, dados e rótulos, rigor experimental e prontidão para produção. A avaliação off-line não provou o comportamento em todos os cenários, mas gerou evidência estruturada para iniciar a experimentação on-line com riscos conhecidos. A mensagem final: incerteza na produção é inevitável, e a avaliação a torna visível, mensurável e gerenciável.