O Google publicou esta semana um preprint descrevendo o Auto-Diagnose, um sistema baseado em LLM que lê logs de testes de integração e diz aos engenheiros por que um teste falhou. A motivação vem de uma pesquisa interna do Google: 38,4% das falhas de testes de integração levam mais de uma hora para diagnosticar, e 8,9% levam mais de um dia. Testes unitários são triados quase instantaneamente porque a superfície de falha é uma única função; testes de integração se espalham por serviços, data centers e camadas de runtime, então a análise de causa-raiz vira um trabalho de arqueologia de logs. O Auto-Diagnose automatiza essa arqueologia com engenharia de prompts sobre um modelo de fronteira, não um fine-tunado.
O modelo é o Gemini 2.5 Flash à temperatura 0,1 e top-p 0,8, sem fine-tuning no corpus de testes do Google. O pipeline coleta logs do driver de teste e logs de componentes através dos data centers, une-os cronologicamente em um fluxo único, e submete tudo ao modelo. Carga média por execução: 110.617 tokens de entrada e 5.962 tokens de saída. Latência p50 de 56 segundos, p90 de 346 segundos. O prompt guia o modelo por fases explícitas: escanear seções de log, ler contexto, localizar falhas, resumir erros e concluir. A escolha crítica de engenharia é uma restrição anti-alucinação dura que força o modelo a recusar em vez de chutar quando a evidência é insuficiente. Esse comportamento de recusa é o que mantém a precisão acima de 90% em um domínio onde um diagnóstico confiantemente errado desperdiça horas de engenheiro.
Números em produção desde maio de 2025: 224.782 execuções de testes avaliadas, 52.635 testes falhados distintos diagnosticados. Avaliação manual em 71 falhas do mundo real através de 39 equipes: 90,14% de precisão em causa-raiz. Feedback dos desenvolvedores: 84,3% de "please fix" dos revisores, razão de utilidade de 62,96% entre respostas de desenvolvedores, e rank 14 entre 370 ferramentas Critique internas (top 3,78%) por utilidade. O notável é o que está faltando: sem fine-tuning, sem camada RAG, sem modelo custom. Apenas Gemini 2.5 Flash com prompting cuidadoso e uma regra de recusa-sob-ambiguidade. O sistema também se beneficia da centralização extrema de logs do Google, então você não pode simplesmente enviar o mesmo prompt no AWS CloudWatch e obter os mesmos números, porque o prompt assume que os logs já estão unidos cronologicamente através de serviços.
Se você roda qualquer tipo de CI multi-serviço, o playbook aqui é replicável mas não é barato. O custo do modelo é insignificante (Gemini 2.5 Flash a ~116k tokens por triagem custa centavos), então o investimento real é a encanação de logs: coletar, normalizar e unir através de serviços antes que o LLM veja qualquer coisa. O padrão recusa-sob-ambiguidade é a ideia mais transferível do conjunto. A maioria dos pipelines LLM em CI não está ajustada para recusar e acaba alucinando causas que parecem plausíveis, o que é pior que silêncio porque direciona engenheiros para correções erradas. Se você está ligando triagem LLM para sua suíte de testes, copie esse padrão primeiro, preocupe-se com o modelo depois. A segunda lição é que um modelo de fronteira off-the-shelf com prompting cuidadoso agora é competitivo com abordagens fine-tunadas em tarefas especializadas, desde que você molde a entrada com cuidado. Isso aumenta o teto do que equipes pequenas podem entregar sem infraestrutura de ML.