LLM para triagem de alertas: o que dá para automatizar e o que precisa continuar humano

Tese

Um LLM ajuda de verdade na triagem de alertas quando o trabalho dele é agrupar, resumir e sugerir causa provável — não quando ele decide o que fazer. A linha que separa "reduz ruído" de "piora a fadiga de alerta" não é a sofisticação do modelo, é se a decisão que ele toma tem baixo custo de erro e é fácil de reverter.

Razões

Correlacionar alertas duplicados, resumir logs longos e puxar contexto de deploys recentes é trabalho que um LLM faz bem, porque é essencialmente uma tarefa de leitura e síntese de texto — o tipo de tarefa em que o modelo já tem bastante sinal no que foi treinado. O ganho aparece em reduzir o tempo que alguém gasta entendendo "o que aconteceu" antes de poder agir.

Decidir se um problema é sério o suficiente para acordar alguém, ou executar uma remediação, é diferente: depende de contexto que geralmente não está todo no texto do alerta — SLA do cliente afetado, se já tem manutenção programada, se aquele serviço específico tem um histórico de falso positivo. Sem esse contexto completo, o modelo está preenchendo lacuna com padrão estatístico, não com informação real do seu ambiente.

Contraponto

Um agente de triagem mal calibrado piora a fadiga de alerta em vez de reduzir — se o resumo ou a causa sugerida está errada com frequência, o time aprende a desconfiar do enriquecimento automático e volta a olhar o alerta cru, e agora tem uma camada a mais pra checar. "Automatizar a triagem" só é uma melhoria se a taxa de acerto do agente for mensuravelmente maior do que a triagem manual que ele substitui — não simplesmente mais rápida.

Entradas, saídas e avaliação

• Entrada: texto do alerta, logs correlacionados, histórico de deploys recentes, alertas relacionados na mesma janela de tempo.
• Saída esperada: resumo do que mudou, correlação com outros alertas (é o mesmo incidente aparecendo em três lugares, ou são três coisas diferentes?), e no máximo um link para o runbook relevante — não uma ação já executada.
• Como avaliar: não é "a explicação pareceu plausível". É comparar a causa sugerida pelo agente com a causa raiz confirmada depois, num conjunto de incidentes já fechados — e medir isso ao longo do tempo, não validar uma vez e assumir que continua bom.
• Onde entra revisão humana: qualquer decisão que execute uma mudança no ambiente (reiniciar serviço, escalar automaticamente, abrir rollback) fica com uma pessoa decidindo. O agente prepara a decisão, não toma ela.

Quando isso muda

Para alertas de baixíssimo risco, alta frequência e remediação sempre igual — disco cheio num ambiente de desenvolvimento, por exemplo, sempre resolvido do mesmo jeito e fácil de reverter — faz sentido dar mais autonomia ao agente, incluindo executar a correção sem esperar aprovação. A régua não é fixa: desliza conforme o custo real de uma decisão errada nesse alerta específico, não conforme uma política genérica de "IA pode ou não pode agir".

Próximo passo

Antes de automatizar qualquer parte da triagem, vale mapear os últimos alertas resolvidos manualmente e classificar cada um: o que precisou de julgamento humano de verdade, e o que foi só reunir informação que já estava disponível em algum lugar. Essa segunda categoria é onde um agente de triagem compensa o esforço de implementar.