🤖 AI

SREGym: A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios

Este artigo apresenta o SREGym, um benchmark ao vivo modular, de código aberto e de alta fidelidade, construído sobre pilhas nativas de nuvem do mundo real que simula cenários complexos de falha para avaliar rigorosamente o desempenho de agentes de IA em Engenharia de Confiabilidade de Sites (SRE).

Autores originais: Jackson Clark, Yiming Su, Saad Mohammad Rafid Pial, Yifang Tian, Lily Gniedziejko, Hans-Arno Jacobsen, Yinfang Chen, Tianyin Xu

Publicado 2026-05-11

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Jackson Clark, Yiming Su, Saad Mohammad Rafid Pial, Yifang Tian, Lily Gniedziejko, Hans-Arno Jacobsen, Yinfang Chen, Tianyin Xu

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você tem uma equipe de mecânicos muito inteligentes, alimentados por IA. Sua função é consertar uma nave espacial gigante e complexa que voa (um sistema moderno de computação em nuvem) enquanto ela ainda está no ar. Esses mecânicos de IA estão ficando melhores em escrever código para construir a nave, mas o teste real é: Eles conseguem realmente consertar a nave quando ela começa a quebrar em pleno voo?

Este artigo apresenta o SREGYM, um novo campo de treinamento de alto risco projetado especificamente para testar esses mecânicos de IA.

Aqui está a explicação do que o artigo diz, usando analogias simples:

1. O Problema: O Teste "Muito Fácil"

Anteriormente, os testes para esses mecânicos de IA eram como dar a eles uma imagem estática de um motor quebrado e perguntar: "O que há de errado?"

A Falha: A vida real não é uma imagem estática. No mundo real, o motor pode estar fazendo um barulho estranho (uma distração), o medidor de combustível pode estar piscando (uma mentira) e o problema pode ser uma mistura de um fio quebrado e um filtro entupido acontecendo ao mesmo tempo.
O Resultado: Os antigos testes eram muito simples. Eles não prepararam a IA para o caos de um sistema de produção real.

2. A Solução: SREGYM (O Simulador de "Fogo Real")

Os autores construíram o SREGYM, que é como um simulador de voo para desastres de TI.

É Ao Vivo: Em vez de uma imagem estática, a IA tem que interagir com um sistema real em execução.
É Bagunçado: O simulador injeta "ruído". Imagine que a IA está tentando encontrar um vazamento em um cano, mas alguém também está batendo nas paredes, deixando cair ferramentas e acendendo luzes próximas. A IA tem que descobrir qual ruído é o problema real e qual é apenas uma distração.
É Profundo: Os problemas não são apenas "o aplicativo travou". O simulador pode quebrar coisas profundamente dentro do sistema, como o sistema operacional, o hardware (discos rígidos) ou a rede, não apenas o código do software.

3. Os Três Tipos de "Armadilhas"

O artigo destaca três maneiras específicas pelas quais eles tornam o simulador complicado, semelhante a como uma emergência real pode ser confusa:

O Problema "Fantasma" (Falha Metastável): Imagine um carro que funciona bem até que você atinge uma certa velocidade, então ele começa a tremer, e mesmo que você diminua a velocidade, ele continua tremendo. A IA tem que perceber que o tremor não é apenas um glitch aleatório; é um ciclo auto-sustentável causado por uma configuração específica.
O "Duplo Problema" (Falhas Concorrentes): Duas coisas quebram ao mesmo tempo. Uma é um problema menor (uma luz de aviso) e a outra é um problema grave (um pneu furado). A IA tem que ignorar a luz de aviso e consertar o pneu furado primeiro.
A "Reação em Cadeia" (Falhas Correlacionadas): Uma parte quebrada faz com que outras cinco partes falhem. A IA tem que rastrear a cadeia de volta para o único elo quebrado, em vez de tentar consertar todos os cinco sintomas.

4. Os Resultados do Teste: A IA Enfrenta Dificuldades

Os pesquisadores colocaram três diferentes "mecânicos" de IA neste simulador (90 cenários diferentes). Eis o que aconteceu:

Eles são bons em coisas simples: Se o problema for um erro de digitação simples no software, as IAs se saem razoavelmente bem.
Elas se perdem no ruído: Quando há distrações (como um computador travando que não é a causa real), as IAs frequentemente se distraem e tentam consertar a coisa errada.
Elas ignoram as coisas profundas: Quando o problema está profundo no hardware (como um disco rígido defeituoso) ou em uma interação complexa entre camadas, as IAs frequentemente chutam errado. Elas tendem a culpar o aplicativo de software em vez do hardware.
O Erro "Avarento": As IAs frequentemente agem como um cachorro perseguindo uma bola. Elas veem a primeira coisa estranha (um sintoma), assumem que esse é o problema e tentam consertá-lo imediatamente, sem olhar mais profundamente para ver se é apenas um efeito colateral de outra coisa.

5. O Veredito

O artigo conclui que, embora a IA seja ótima em escrever código, ela ainda não está pronta para ser o mecânico principal para consertar falhas de sistemas complexos do mundo real sozinha.

Os modelos de IA atuais acertam o diagnóstico apenas cerca de 39% a 73% das vezes.
Eles acertam o conserto cerca de 57% a 78% das vezes.
Quando você combina ambas as etapas (diagnosticar e consertar), a taxa de sucesso cai significativamente, especialmente nos cenários "bagunçados".

Resumo

O SREGYM é uma nova academia realista onde agentes de IA podem praticar o conserto de sistemas quebrados. O artigo mostra que, embora esses agentes de IA sejam inteligentes, eles são atualmente facilmente distraídos pelo ruído, lutam com problemas profundos de hardware e frequentemente consertam a coisa errada. A academia está agora aberta para que outros pesquisadores a utilizem para treinar melhores mecânicos de IA para o futuro.

Resumo Técnico: SREGym – Um Benchmark ao Vivo para Agentes de SRE de IA

1. Declaração do Problema

O artigo aborda a lacuna crítica na avaliação de agentes de IA para Engenharia de Confiabilidade de Sites (SRE). Embora agentes de IA estejam cada vez mais implantados para diagnosticar e mitigar falhas em produção, os benchmarks existentes são insuficientes por três razões principais:

Simplificação Excessiva: Os benchmarks atuais (por exemplo, conjuntos de dados estáticos de perguntas e respostas, tarefas de detecção de anomalias) não capturam a natureza dinâmica e multi-etapa da resposta a incidentes do mundo real. Frequentemente, avaliam agentes em dados estáticos ou sintomas isolados, em vez de resolução ponta a ponta.
Falta de Fidelidade: Benchmarks ao vivo existentes (por exemplo, AIOpsLab, ITBench) simulam falhas, mas carecem da complexidade dos ambientes de produção. Geralmente focam em problemas da camada de aplicação, ignoram o "ruído ambiente" (eventos transitórios não relacionados) e falham em modelar modos de falha complexos, como estados metastáveis ou falhas correlacionadas.
Problemas de Extensibilidade: Muitos benchmarks dependem de scripts personalizados e codificados manualmente (por exemplo, Ansible), o que dificulta a composição de novos cenários, a coordenação de eventos distribuídos ou a escalabilidade do espaço de problemas.

Além disso, o surgimento de código gerado por IA introduz novos desafios de confiabilidade, com relatórios indicando que o código de IA introduz significativamente mais defeitos e escapa dos testes com mais frequência do que o código escrito por humanos. Isso exige capacidades robustas de SRE agentic que vão além da codificação para incluir mitigação em tempo real.

2. Metodologia: O Framework SREGym

Os autores apresentam o SREGym, um benchmark ao vivo de alta fidelidade construído sobre pilhas de sistemas nativos da nuvem do mundo real (Kubernetes). Diferentemente de conjuntos de dados estáticos, o SREGym fornece um ambiente ao vivo onde agentes interagem com sistemas em execução por meio de uma interface padronizada.

Arquitetura Central

Ambiente do Sistema: O SREGym implanta um catálogo de aplicações nativas da nuvem (por exemplo, DeathStarBench, TrainTicket, Astronomy Shop) e sistemas de back-end (MongoDB, TiDB, Kafka) gerenciados por operadores do Kubernetes.
Interface do Agente: Os agentes interagem por meio do Protocolo de Contexto do Modelo (MCP), acessando ferramentas para métricas (Prometheus), logs (Loki), rastreamentos (Jaeger) e controle de cluster (kubectl).
Injeção de Falhas e Ruído: O framework utiliza um conjunto modular de injetores para simular:
- Falhas: Causas raiz em toda a pilha, incluindo falhas de hardware (via eBPF), falhas do kernel do SO, más configurações, bugs de código e erros de operador.
- Ruídos: Perturbações transitórias e de auto-recuperação (por exemplo, falhas de pod, pacotes descartados) que não estão relacionadas à falha alvo, projetadas para testar a capacidade do agente de distinguir sinal de ruído.
Definição do Problema: Um problema é definido como uma tupla $P = (E, I, F, O)$ , compreendendo o ambiente, a interface do agente, falhas/ruídos e oráculos.
Oráculos de Avaliação:
- Oráculo de Diagnóstico: Utiliza uma abordagem de LLM como Juiz com uma lista de verificação estruturada (9 perguntas Sim/Não em três dimensões: Localização de Falha, Caracterização de Falha e Escopo de Falha) para avaliar diagnósticos em linguagem natural. Isso evita correspondência de strings frágil e permite uma avaliação mais sutil.
- Oráculo de Mitigação: Verifica programaticamente se a falha alvo foi resolvida e se o sistema retornou a um estado saudável, utilizando tanto observabilidade do lado do cliente (taxas de sucesso de solicitações) quanto do lado do sistema.

Princípios de Design Chave

Simular Falhas, Não Sintomas: O sistema injeta causas raiz (por exemplo, uma variável de ambiente ausente) em vez de apenas sintomas (por exemplo, um pod falhado), exigindo que os agentes raciocinem sobre o defeito subjacente.
Composabilidade: Um runtime baseado em Python orquestra injetores de falhas e ruído, permitindo cenários complexos como falhas metastáveis (degradação auto-sustentada) e falhas concorrentes/correlacionadas.
Extensibilidade: O framework é projetado para ser "botão de pressão" para a criação de problemas, permitindo que pesquisadores mutem cenários existentes ou criem novos por meio de APIs.

3. Contribuições Principais

Benchmark SREGym: Um benchmark ao vivo e de código aberto contendo 90 problemas realistas e desafiadores de SRE que abrangem camadas de hardware, SO e aplicação.
Modelagem de Falhas de Alta Fidelidade: Introdução de modos de falha complexos anteriormente não abordados em benchmarks, incluindo:
- Falhas Metastáveis: Sistemas que degradam em resposta a eventos transitórios e não se recuperam sem intervenção específica.
- Falhas Concorrentes: Múltiplas falhas independentes ocorrendo simultaneamente.
- Falhas Correlacionadas: Múltiplos componentes falhando devido a uma causa raiz compartilhada.
Simulação de Ruído Ambiente: A capacidade de injetar perturbações transitórias e de baixo impacto que desafiam os agentes a filtrar dados irrelevantes.
Protocolo de Avaliação Robusto: Um método de avaliação baseado em lista de verificação com LLM que alcança alta concordância com especialistas humanos ( $\kappa = 0,90$ ) enquanto escala para grandes conjuntos de dados.

4. Resultados Experimentais

Os autores avaliaram três agentes: Stratus (um agente especializado em SRE), Claude Code e OpenAI Codex, alimentados por modelos de ponta (Sonnet-4.6, GPT-5.4, Kimi K2.5).

Desempenho Geral

Taxas de Sucesso: As taxas de sucesso de diagnóstico variaram de 38,9% a 72,6%, e as taxas de sucesso de mitigação de 57,3% a 78,5%.
Desempenho Ponta a Ponta (E2E): A taxa de sucesso E2E (diagnóstico correto + mitigação correta) variou significativamente, com diferenças de até 40% entre pares de agente-modelo.
Impacto do Ruído: A presença de ruído reduziu consistentemente as taxas de sucesso de diagnóstico em todos os agentes. A mitigação foi mais robusta, mas ainda impactada.

Principais Descobertas

Fraquezas Específicas por Camada: Os agentes performaram bem em problemas da camada de aplicação, mas lutaram significativamente com falhas enraizadas em camadas inferiores (SO, hardware) ou padrões complexos. Por exemplo, em cenários de falha de hardware (erros de setor de disco), os agentes não conseguiram identificar a causa raiz de hardware, atribuindo-a frequentemente à lógica da aplicação.
Desafios de Falhas Metastáveis: Os agentes conseguiam identificar gatilhos no nível da aplicação, mas frequentemente falhavam em conectá-los a restrições de infraestrutura (por exemplo, cotas de recursos) necessárias para resolver o estado metastável.
Diagnóstico Ganancioso: Um modo de falha recorrente foi a "abordagem gananciosa", onde os agentes se agarravam à primeira anomalia plausível (frequentemente um ruído ou problema não relacionado) e falhavam em investigar mais a fundo, levando a uma atribuição incorreta da causa raiz.
Eficiência de Tokens: Agentes especializados em SRE (Stratus) foram significativamente mais eficientes em tokens (usando ~3x menos tokens) do que agentes de codificação (Claude Code, Codex) ao pré-processar dados de observabilidade, sem sacrificar as taxas de sucesso E2E.
Correlação Diagnóstico-Mitigação: O diagnóstico correto correlacionou-se fortemente com a mitigação bem-sucedida ( $P(M|D) \approx 0,69\text{--}0,88$ ). No entanto, os agentes às vezes conseguiam mitigar falhas mesmo com diagnósticos incorretos, observando e ajustando iterativamente o sistema, embora isso fosse menos eficiente.

5. Significado e Alegações

O artigo posiciona o SREGym como um passo fundamental em direção a SRE agentic pronto para produção.

Realismo: Ao simular a natureza "ruidosa" e "eventual" dos ambientes de produção, o SREGym fornece uma medida mais precisa da prontidão de um agente para implantação no mundo real do que benchmarks estáticos.
Recurso Comunitário: Como um framework de código aberto e extensível, visa acelerar a pesquisa ao fornecer um terreno comum para avaliar diversas arquiteturas e modelos de agentes.
Limitações: Os autores reconhecem modestamente as limitações, incluindo a escala menor das aplicações implantadas em comparação com sistemas de produção de hiperescala, modelos de ruído simplificados e a avaliação atual de apenas alguns pares de agente-modelo. Eles enfatizam que altas pontuações no SREGym são uma condição necessária, mas não suficiente, para a segurança em produção.

Em conclusão, o SREGym demonstra que, embora agentes de IA de ponta mostrem promessa em tarefas de SRE, lacunas significativas permanecem no manuseio de cenários de falha de alta fidelidade, multicamadas e ruidosos, destacando a necessidade de desenvolvimento contínuo na engenharia de confiabilidade agentic.