Um modelo linguístico pode apresentar resultados fortes em um benchmark limpo e, depois, falhar nos casos ambíguos que realmente importam aos usuários no ambiente de produção. Essa é a lição central apresentada pelo GitHub em um material escrito por Mariko Wakabayashi e Zixiao Chen em 25 de agosto de 2026, com base em uma experiência de avaliação de um sistema que utiliza um modelo linguístico para ajudar a reduzir falsos positivos no GitHub secret scanning.
A verificação de segredos procura credenciais, como tokens e chaves, que podem ter sido inseridas em um repositório de software. Porém, algumas cadeias de caracteres se parecem com segredos sem serem credenciais reais, levando os desenvolvedores a revisar alertas que não exigem tratamento. Por isso, a pergunta da equipe não era se o modelo conseguia classificar uma cadeia de caracteres isolada, mas se conseguia reduzir o ruído mantendo um nível de recall suficiente para tornar seguro um fluxo de trabalho de segurança sensível.
Comece pela decisão do produto, não pela escolha do modelo
O GitHub recomenda definir a decisão que a avaliação deve apoiar antes de ajustar o prompt, adicionar contexto ou trocar o modelo. No caso da verificação de segredos, o objetivo era reduzir falsos positivos e aumentar a precisão, enquanto o recall era usado como restrição de segurança. Ocultar por engano uma credencial real pode ser mais perigoso do que pedir a um desenvolvedor que revise um alerta adicional.
Na prática, os critérios de avaliação foram divididos em três camadas: um resultado principal que mede a utilidade para o usuário, isto é, a redução de falsos positivos e a precisão; uma restrição de segurança representada pelo recall; e barreiras operacionais, incluindo latência, custo, confiabilidade e compatibilidade com o ambiente de produção. Assim, uma melhoria na precisão não é automaticamente considerada um sucesso se vier acompanhada de uma queda inaceitável no recall ou tornar o sistema lento, caro ou difícil de integrar.
Transforme a avaliação em um teste de integração reproduzível
A avaliação não é uma única etapa realizada antes do lançamento. Prompts, modelos, a forma de construir as entradas e a lógica do sistema ao redor deles mudam continuamente, e qualquer alteração pode melhorar, piorar ou deslocar o padrão de erro para outro ponto. Por isso, o GitHub repetiu a avaliação após cada mudança importante e registrou, a cada vez, a versão do prompt e do modelo, o conjunto de dados e as configurações do sistema.
A equipe também isolou uma variável principal em cada experimento, comparando uma alteração no prompt com uma linha de base conhecida antes de testar uma atualização do modelo com ela. Os prompts e as configurações de avaliação foram descritos como se fossem código: foram versionados, as alterações foram documentadas e foi mantida a possibilidade de executar novamente as configurações anteriores e revertê-las. Essa prática permite saber a causa de uma melhoria ou de uma regressão, em vez de atribuí-la erroneamente à alteração mais recente.
Simule a tarefa de produção e não se limite a dados limpos
Os resultados da avaliação offline são mais úteis quando se assemelham à tarefa real. Na verificação de segredos, o modelo não necessariamente observa um valor isolado, mas um candidato dentro de um código circundante e de informações auxiliares que podem estar incompletas ou dispersas. Ele pode se concentrar em outro valor que pareça mais relacionado à segurança, como um token de teste no código, em vez do candidato que deveria avaliar.
Por isso, devem ser preservadas as características da tarefa de produção, incluindo o candidato em avaliação, o contexto ao redor, as informações auxiliares, a forma de formatar as entradas e impor restrições e a lógica mais ampla do sistema. Se a avaliação utilizar exemplos mais claros e um contexto mais completo do que o existente na realidade, o resultado poderá refletir um problema mais fácil do que aquele que o sistema enfrentará após a implantação.
Trate rótulos e dados como evidências que podem ser examinadas
O resultado de uma determinada ação no produto não significa que ele represente uma verdade fundamental confiável. Fechar um alerta na verificação de segredos pode significar que a credencial foi substituída, que o risco foi aceito, que o alerta foi fechado para abrir um fluxo de trabalho ou que ele foi classificado incorretamente. Esses casos parecem semelhantes nos dados do fluxo de trabalho, mas não respondem à mesma pergunta na avaliação.
Antes de usar dados de produção, é necessário saber como o rótulo foi criado, se ele corresponde à pergunta da avaliação e se resultados diferentes foram agrupados em uma única categoria. O GitHub sugere uma revisão humana das categorias importantes ou ambíguas, em vez de presumir que todo rótulo esteja correto. Dados sintéticos e benchmarks abertos podem preencher lacunas de cobertura, especialmente em casos raros, como contexto ausente, formatação incomum e valores semelhantes a credenciais, mas devem complementar os dados próximos da produção, não substituí-los.
Analise os erros e use o modelo avaliador com cautela
As métricas agregadas informam à equipe se o sistema melhorou, mas não explicam o que deve ser alterado em seguida. Por isso, o GitHub revisou amostras de falsos positivos e falsos negativos e classificou suas possíveis causas como relacionadas ao modelo, ao prompt, às entradas, ao pipeline, ao conjunto de dados ou aos rótulos. Essa classificação transforma um problema geral de qualidade em uma tarefa de engenharia específica: um enquadramento melhor das entradas, uma construção diferente de contexto, uma limpeza dos dados ou uma política de produto mais clara.
Outro modelo linguístico pode ser usado como avaliador para reduzir a carga da revisão humana, processando os casos claros e priorizando os casos ambíguos. Porém, suas saídas não são uma verdade de referência; ele pode errar ou concordar com o modelo avaliado pelo motivo errado. O padrão mais seguro é encaminhar para humanos os casos de baixa confiança, conflitantes ou de alto impacto, coletar periodicamente amostras dos casos que o avaliador classificou com alta confiança, acompanhar suas divergências em relação ao sistema e aos revisores e versionar e avaliar seu prompt.
O que a experiência realmente comprovou?
O GitHub informou ter alcançado uma redução de 95% nos falsos positivos no conjunto de dados offline avaliado, mantendo o recall dentro da restrição de segurança definida. No entanto, a empresa não apresentou esse resultado como prova de que o sistema se comportará da mesma forma em todos os cenários de produção. O valor mais importante esteve em compreender como chegar ao resultado: uma avaliação mais próxima da tarefa real, linhas de base reproduzíveis e padrões de falha documentados.
Leitura editorial da certi.news: a mudança efetiva aqui não é o lançamento de um novo modelo, mas a transformação da avaliação de sistemas de LLM, de um experimento baseado em benchmark em um processo de engenharia contínuo, vinculado a uma decisão clara e a limites de segurança e operação. Isso é relevante para equipes de software, segurança e ferramentas para desenvolvedores porque melhorar uma única métrica pode ocultar uma regressão perigosa no recall ou um aumento de custo. Por outro lado, o resultado continua limitado pelo conjunto de avaliação, pela qualidade dos rótulos e pela lacuna que não pode ser eliminada entre o teste offline e o comportamento em produção; por isso, as avaliações representam uma base para avançar para um experimento de produção controlado, não um substituto para o monitoramento de riscos após o lançamento.