O protótipo responde bem, a demonstração impressiona e o benchmark mostra um número bonito. A tentação é apertar o botão de publicar. O problema começa quando chegam entradas ambíguas, contexto incompleto, usuários fazendo perguntas que ninguém previu e erros que o conjunto de teste nunca mostrou.
Avaliar um sistema de IA antes da produção não é perguntar apenas se o modelo acerta. É descobrir se ele ajuda na decisão certa, quais erros são aceitáveis, onde uma pessoa precisa revisar e quanto custa manter o comportamento sob controle.
O GitHub publicou as lições que aprendeu ao avaliar um sistema com LLM criado para reduzir falsos positivos no secret scanning. O caso envolve segurança, mas o método serve para assistentes, automações, análise de documentos, atendimento e ferramentas de programação.
Comece pela decisão, não pelo modelo
Quando um sistema de IA falha, a reação mais comum é mexer no prompt, adicionar contexto ou trocar de modelo. Antes disso, escreva a decisão que a avaliação precisa sustentar.
No caso do GitHub, a pergunta não era “o modelo classifica uma string corretamente?”. A pergunta era mais específica: o sistema consegue reduzir alertas falsos sem deixar passar credenciais reais em um fluxo de segurança?
Essa diferença muda as métricas. Reduzir falsos positivos melhora a experiência do desenvolvedor, mas perder um segredo verdadeiro pode criar um risco muito maior. Por isso, o GitHub separou os critérios em três grupos:
- resultado principal: redução de falsos positivos e melhora da precisão;
- limite de segurança: recall dentro de uma faixa aceitável;
- limites operacionais: latência, custo, confiabilidade e compatibilidade com a produção.
Uma configuração que melhora muito a precisão, mas derruba o recall abaixo do limite, não vence. Outra que melhora menos, preserva a segurança e funciona dentro do orçamento pode ser a escolha correta.
Monte um conjunto de teste que pareça com a vida real
Um benchmark limpo ajuda a comparar modelos. Ele não representa necessariamente o que o produto recebe. Em produção, o valor analisado pode aparecer no meio de código, comentários, exemplos, placeholders e outras strings parecidas.
Imagine que o sistema precisa avaliar candidate_value, mas o trecho ao redor também contém uma variável chamada example_token. O modelo pode produzir uma explicação convincente sobre a variável errada. Se o conjunto de teste tiver apenas um candidato isolado por exemplo, essa falha não aparece.
O conjunto representativo precisa manter as características que tornam a tarefa difícil:
- contexto incompleto ou truncado;
- mais de um elemento parecido na entrada;
- casos raros, mas perigosos;
- formatação estranha;
- rótulos incertos;
- dados próximos do fluxo que o sistema realmente receberá.
Dados sintéticos podem preencher lacunas, especialmente em casos raros ou sensíveis. Eles devem complementar dados reais, não substituí-los. Um exemplo fabricado consegue testar um formato de chave; dificilmente reproduz sozinho a ambiguidade de um repositório real.
Desconfie dos rótulos de produção
O histórico do produto parece uma fonte perfeita de verdade, mas muitas vezes registra o fim de um fluxo, não a resposta correta. Um alerta encerrado pode significar que a credencial foi rotacionada, que o risco foi aceito ou que alguém precisava liberar uma tarefa. Isso não prova que o alerta era falso.
Antes de transformar eventos do produto em dataset, pergunte:
- quem criou esse rótulo?
- qual decisão levou ao estado final?
- estamos agrupando motivos diferentes?
- os casos ambíguos passaram por revisão humana?
Não é necessário revisar cada linha manualmente. É necessário entender onde o rótulo pode enganar a avaliação.
Trate a avaliação como teste de integração
Prompts, modelos, contexto e lógica ao redor mudam com frequência. A avaliação precisa rodar novamente sempre que uma mudança relevante acontece, como um teste de integração.
Registre em cada execução:
- versão do prompt;
- modelo utilizado;
- versão do dataset;
- configuração do pipeline;
- métricas e limites;
- observações sobre os erros encontrados.
Também altere uma variável importante por vez. Se você troca o prompt e o modelo no mesmo teste, pode até melhorar o resultado, mas não sabe o que causou a mudança. Isso dificulta reproduzir, manter e desfazer.
Olhe os erros, não apenas a média
Uma métrica agregada informa se o resultado geral subiu ou desceu. Ela não explica o que corrigir. Para avançar, separe falsos positivos e falsos negativos por padrão.
Para cada falha, tente classificá-la:
- o modelo interpretou mal?
- o prompt orientou a tarefa errada?
- faltou contexto?
- o pipeline montou uma entrada incorreta?
- o dataset não cobre aquele cenário?
- o rótulo está errado?
Essa classificação transforma “o modelo está ruim” em uma tarefa de engenharia. Às vezes a solução é melhorar o prompt. Em outros casos, o problema está no dado, no recorte do contexto ou numa regra fora do LLM.
Use outro LLM para triagem, não como verdade
Um LLM avaliador pode ajudar a separar casos claros, identificar possíveis rótulos errados e priorizar divergências. Ele também erra e pode concordar com o primeiro modelo pelo motivo errado.
O uso mais seguro é como funil:
- processe automaticamente casos claros e de baixo risco;
- mande baixa confiança, divergências e alto impacto para pessoas;
- amostre periodicamente casos classificados como fáceis;
- acompanhe a discordância entre modelo, avaliador e revisão humana;
- versione e teste o prompt do avaliador.
A automação reduz o volume da revisão. A decisão humana continua concentrada onde um erro muda o produto ou cria risco.
Crie regressão antes do lançamento
Cada erro importante corrigido deve virar um caso permanente. Assim, uma nova versão do prompt ou do modelo não reintroduz o mesmo problema silenciosamente.
Guarde um baseline e compare toda mudança contra ele. Teste também upgrades de modelo com regularidade. Um modelo novo pode funcionar com um prompt mais simples, mas também alterar custo, latência, formato e desempenho em categorias específicas.
Depois da avaliação offline, faça um lançamento controlado. Comece com tráfego limitado, monitore guardrails e mantenha rollback. Avaliação não elimina a incerteza da produção; ela mostra onde essa incerteza está.
Roteiro enxuto para a primeira avaliação
- escreva a decisão que o produto precisa tomar;
- defina uma métrica principal, um limite de segurança e guardrails operacionais;
- monte dados parecidos com a entrada real;
- revise rótulos ambíguos;
- registre prompt, modelo, dataset e configuração;
- mude uma variável por experimento;
- classifique os erros por causa provável;
- transforme falhas corrigidas em regressão;
- use revisão humana nos casos de maior impacto;
- faça um rollout controlado e mantenha rollback.
O GitHub relata uma redução de 95% nos falsos positivos dentro do conjunto offline avaliado, mantendo o recall no limite definido. O número é relevante, mas a principal lição é o processo que permitiu entendê-lo: dados próximos da produção, baseline reproduzível, análise de erro e limites claros.
Antes de confiar em um sistema de IA, tente explicar por que ele deve avançar, quais erros ainda comete e o que fará a equipe interromper o lançamento. Se essas respostas não estão registradas, o sistema ainda está em demonstração.
Fonte: GitHub Blog — How to evaluate LLMs before production.
