Why Do AI Agents Systematically Fail at Cloud Root Cause Analysis?

Este artigo apresenta uma análise de falhas em nível de processo de agentes de IA baseados em LLMs para Análise de Causa Raiz (RCA) em nuvem, identificando que os principais erros decorrem de falhas arquiteturais compartilhadas em vez de limitações individuais dos modelos e demonstrando que enriquecer o protocolo de comunicação entre agentes é mais eficaz para mitigar falhas do que apenas o ajuste de prompts.

O essencial

Imagine que você tem um super-gerente de TI feito de Inteligência Artificial (IA). O trabalho dele é resolver quebras em sistemas gigantes de nuvem (como os que sustentam bancos, operadoras de celular e lojas online). Quando algo dá errado, o sistema gera milhões de pistas: logs de texto, gráficos de memória, rastros de pedidos, etc.

O objetivo desse agente de IA é agir como um detetive: olhar para todas essas pistas, conectar os pontos e dizer exatamente: "O problema começou aqui, naquela hora, por causa daquela peça específica".

O problema? Segundo este estudo, esses detetives de IA estão falhando miseravelmente. Mesmo usando os modelos de IA mais inteligentes e caros do mercado, eles acertam o diagnóstico perfeito em menos de 13% dos casos.

Mas o mais importante que os pesquisadores descobriram não é que eles falham, mas por que eles falham. E a resposta é surpreendente: não é culpa da "inteligência" do modelo, mas sim de como eles foram organizados.

Aqui está a explicação simplificada, usando analogias do dia a dia:

1. O Cenário: Uma Equipe de Detetives Desconectada

O sistema de IA não é uma única pessoa pensando. É uma equipe com dois papéis principais:

• O Chefe (Controller): Pensa, planeja e dá ordens.
• O Executor (Executor): Pega as ordens, escreve o código para analisar os dados e traz o resultado de volta.

Eles se comunicam apenas por resumos em linguagem natural (como se o Chefe mandasse um bilhete para o Executor e o Executor respondesse com outro bilhete, sem mostrar o trabalho feito).

2. Os 3 Grandes Vilões (Onde tudo dá errado)

Os pesquisadores analisaram mais de 1.600 tentativas de diagnóstico e encontraram 12 tipos de erros. Vamos agrupá-los em três categorias principais:

A. O "Alucinação" do Chefe (Raciocínio Interno)

• O que acontece: O Chefe recebe os dados, mas em vez de ler o que está escrito, ele inventa uma história que faz sentido para ele, mas que é falsa.
• A Analogia: É como um detetive que chega num crime, vê um copo quebrado e, em vez de analisar as digitais, diz: "Ah, o ladrão deve ter sido o gato, porque gatos amam vidro". Ele criou uma narrativa que soa lógica, mas não tem base na realidade.
• O Problema: Isso acontece em 71% das vezes, em todos os modelos, do mais simples ao mais avançado. Não adianta pedir para o modelo "ser mais inteligente"; o erro está no modo como ele "sonha" com os dados.

B. O "Pulo do Gato" na Investigação (Exploração Incompleta)

• O que acontece: O agente olha apenas para uma parte do problema e ignora o resto.
• A Analogia: Imagine que você está procurando a causa de um vazamento de água. O agente olha apenas a torneira da cozinha, vê que está pingando e diz: "Pronto, é isso!". Ele ignora que o cano principal no porão está rachado. Ele pula etapas importantes porque acha que já achou a resposta.
• O Problema: Isso acontece em 64% dos casos. Eles não exploram todas as pistas disponíveis.

C. O "Telefone Sem Fio" (Comunicação entre Agentes)

• O que acontece: O Chefe manda uma ordem, o Executor entende errado, faz algo diferente, e o Chefe não percebe porque só recebe um resumo vago.
• A Analogia:
  • Chefe: "Vá até a loja e compre 5 maçãs vermelhas."
  • Executor: (Entende mal e compra 5 maçãs verdes).
  • Resumo do Executor: "Comprei as frutas."
  • Chefe: "Ok, ótimo!" (Mas ele não sabe que são verdes).
  • Resultado: O trabalho é feito, mas está errado.
• O Problema: Como eles não mostram o "rascunho" ou o código que escreveram, o Chefe fica cego para os erros do Executor.

3. A Grande Descoberta: Não é o Modelo, é a Arquitetura

O estudo testou 5 modelos de IA diferentes (do mais barato ao mais caro).

• A surpresa: O modelo mais "burro" e o mais "inteligente" falharam exatamente da mesma maneira e na mesma frequência.
• A conclusão: O problema não é a "inteligência" do cérebro (o modelo de IA). O problema é o sistema de comunicação e a estrutura da equipe. É como ter um time de futebol onde o técnico não vê o que o jogador está fazendo no campo; não adianta contratar o melhor jogador do mundo se o sistema de jogo é falho.

4. As Soluções: O que Funciona e o que Não Funciona

Os pesquisadores tentaram consertar isso de duas formas:

• Tentativa 1: Melhorar as Instruções (Prompt Engineering)

  • Eles escreveram instruções mais detalhadas para o Chefe: "Por favor, não invente histórias! Olhe todos os dados!"
  • Resultado: Falha. O agente até leu a instrução, mas continuou alucinando e pulando etapas. É como dar um manual de instruções para alguém que não sabe ler; o problema é estrutural, não de falta de vontade.

• Tentativa 2: Mudar a Estrutura da Comunicação (O Grande Sucesso)

  • Eles mudaram a regra do jogo: O Executor agora mostra o código que escreveu e os erros que encontrou, não apenas um resumo.
  • Resultado: Sucesso total!
    • O Chefe pôde ver: "Ei, você escreveu código errado aqui!" e corrigiu na hora.
    • O número de erros de comunicação caiu em 15%.
    • A IA ficou mais rápida e precisa.
    • Analogia: Em vez de apenas pedir um resumo, o Chefe agora tem acesso ao "quadro negro" onde o Executor está escrevendo. Ele pode ver o erro antes que ele vire um desastre.

Resumo Final

Este paper nos ensina que, para consertar IAs que analisam falhas em sistemas complexos, não basta comprar o modelo mais caro ou escrever melhores instruções.

O segredo é construir uma equipe onde a comunicação seja transparente. Se o "Executor" mostrar seu trabalho bruto (código, dados, erros) para o "Chefe", a IA para de alucinar e começa a funcionar de verdade. É uma mudança na "arquitetura da equipe", não apenas na "inteligência do cérebro".

Resumo técnico

1. O Problema

Falhas em sistemas de nuvem em grande escala resultam em paradas significativas e perdas financeiras, tornando a Análise de Causa Raiz (RCA) automatizada essencial para a estabilidade operacional. Embora as abordagens recentes utilizem Agentes de Grandes Modelos de Linguagem (LLM) para automatizar essa tarefa, os sistemas existentes apresentam uma precisão de detecção extremamente baixa (variando de 3,9% a 12,5% em benchmarks como o OpenRCA).

O principal gargalo identificado pelos autores não é apenas a capacidade dos modelos, mas a falta de compreensão sobre por que o raciocínio ou a colaboração dos agentes falha. As estruturas de avaliação atuais focam apenas na correção da resposta final, ignorando os processos intermediários. Sem uma análise de falhas em nível de processo, os praticantes não conseguem determinar se devem investir em modelos mais fortes, melhores prompts ou em redesenho dos frameworks de agentes.

2. Metodologia

Os autores desenvolveram uma metodologia de análise de falhas em nível de processo para diagnosticar sistematicamente as causas da baixa performance dos agentes de RCA.

• Escopo do Experimento: Execução completa do benchmark OpenRCA (335 incidentes de falha em três domínios: Telecom, Banco e Mercado) utilizando 5 modelos LLM diferentes (incluindo Gemini 2.5 Pro, GPT-5 mini, GPT-OSS 120B, Solar Pro 2 e Claude Sonnet 4).
• Volume de Dados: Foram gerados 1.675 runs de agentes, consumindo aproximadamente 1,38 bilhão de tokens e 609,9 horas de tempo de relógio.
• Framework de Análise: Foi construído um pipeline de diagnóstico usando um agente de análise (Claude Code) para classificar as falhas em 12 tipos de armadilhas (pitfalls), divididas em três categorias arquitetônicas:
  1. Raciocínio Intra-Agente: Falhas dentro da lógica de um único agente (ex: alucinação, exploração incompleta).
  2. Comunicação Inter-Agente: Falhas na troca de informações entre o "Controlador" e o "Executor" (ex: incompatibilidade instrução-código, repetição sem sentido).
  3. Interação Agente-Ambiente: Falhas relacionadas ao ambiente de execução (ex: esgotamento de memória, limite de passos).
• Validação: Cada classificação foi verificada por humanos para garantir precisão, seguindo o princípio "human-in-the-loop".

3. Principais Contribuições

1. Taxonomia de Falhas: Uma classificação sistemática de 12 tipos de falhas que permite diagnosticar agentes de RCA além da avaliação baseada apenas no resultado final.
2. Análise Empírica de Arquitetura: A descoberta de que as falhas dominantes são compartilhadas entre todos os modelos, independentemente de sua capacidade ou custo, indicando que a origem do problema está no framework do agente e não nas limitações individuais dos modelos LLM.
3. Experimentos de Mitigação Controlada: Demonstração de que intervenções no nível de prompt (engenharia de prompt) são insuficientes para resolver as falhas principais, enquanto modificações estruturais no framework (especialmente na comunicação entre agentes) produzem melhorias mensuráveis.

4. Resultados Chave

A. Padrões de Falha (Armadilhas)

• Alucinação na Interpretação (71,2%): O agente mais prevalente. O Controlador impõe uma narrativa interpretativa aos dados que parece coerente, mas não reflete a realidade dos valores retornados. Isso ocorre em todos os modelos (>66%).
• Exploração Incompleta (63,9%): Os agentes ignoram categorias inteiras de componentes ou KPIs (ex: analisam apenas CPU e ignoram rede), mesmo quando o framework fornece listas completas de candidatos.
• Erro de Geração de Código (27,2%): Varia drasticamente entre modelos (de 1,8% no Gemini 2.5 Pro a 65,5% no Claude Sonnet 4), indicando que a confiabilidade na geração de código é um fator diferenciador.
• Incompatibilidade Instrução-Código (Inter-Agente): O Executor gera código que não reflete a intenção do Controlador devido à perda de contexto na interface de linguagem natural.

B. Limitações da Engenharia de Prompt

Experimentos com Prompting (baseado em hipóteses e consciente de falhas) no modelo Claude Sonnet 4 mostraram que:

• Conseguiram ampliar o escopo de exploração (os agentes começaram a verificar mais KPIs).
• Falharam em corrigir a Alucinação: Os agentes continuaram a fabricar interpretações incorretas dos dados corretos. Isso sugere que a alucinação é uma propriedade estrutural do processo de geração, não uma falta de instrução.

C. Eficácia de Modificações Estruturais

• Comunicação Enriquecida: Ao modificar o protocolo de comunicação para que o Executor retorne o código Python gerado, a saída completa e os rastreamentos de erro (em vez de apenas um resumo em linguagem natural), observou-se:
  • Redução de falhas de comunicação em até 15 pontos percentuais.
  • Aumento na detecção perfeita (ex: GPT-5 mini subiu de 0% para 4,9% no domínio de Banco).
  • Ganho de Eficiência: Apesar de aumentar o consumo de tokens por passo, o número total de passos diminuiu, resultando em uma redução líquida de 22,3% no tempo de execução.
• Isolamento de Estado: A implementação de um "observador de memória" eliminou 100% das falhas de Out-of-Memory (OOM), que antes encerravam sessões inteiras de diagnóstico.

5. Significado e Conclusão

O trabalho conclui que a baixa precisão dos agentes de RCA em nuvem não é um problema de "modelo fraco", mas sim de arquitetura de agente inadequada.

• Diagnóstico: As falhas mais críticas (alucinação e exploração incompleta) persistem em todos os modelos, apontando para o framework compartilhado como o gargalo principal.
• Solução: Intervenções puramente baseadas em prompt são insuficientes para corrigir falhas de raciocínio profundo. A solução exige modificações estruturais, como:
  • Protocolos de comunicação que exponham dados brutos (código, erros) entre agentes.
  • Módulos de verificação externa para validar interpretações contra dados brutos.
  • Gerenciamento explícito de estado e recursos.

Este estudo fornece uma base fundamental para projetar agentes autônomos mais confiáveis para operações de nuvem (AIOps), deslocando o foco da busca por modelos maiores para o redesenho da arquitetura de interação e verificação dos agentes.