Resumo Técnico: Modelos de Linguagem de Grande Escala para NetOps e AIOps Agentes

1. Declaração do Problema

As operações de rede modernas (NetOps) e a IA para operações de TI (AIOps) enfrentam uma desconexão crescente entre a velocidade das mudanças no sistema (implantações, edições de políticas, rotatividade de topologia) e a capacidade das equipes humanas de gerenciá-las. Embora os operadores possuam ferramentas poderosas para raciocinar sobre configuração e alcançabilidade, o ônus operacional é intensificado por evidências fragmentadas, mudanças de alta velocidade e transferências complexas de incidentes.

O surgimento de Modelos de Linguagem de Grande Escala (LLMs) oferece uma solução potencial ao unificar o trabalho operacional fragmentado em um único ciclo de leitura, raciocínio e ação. No entanto, tratar LLMs como agentes autônomos introduz riscos significativos. Diferentemente de agentes conversacionais gerais, agentes operacionais interagem com superfícies de controle críticas. Falhas aqui não são meramente "respostas erradas", mas podem resultar em alterações de configuração inseguras, interrupções de serviço e violações de segurança. O problema central é que os designs agentes atuais frequentemente carecem das restrições rigorosas, mecanismos de verificação e contratos de segurança exigidos para ambientes operacionais de alto risco. Há uma falta de terminologia compartilhada para autonomia, tarefas de avaliação estáveis e modelos de ameaça que correspondam às superfícies de ferramentas operacionais reais.

2. Metodologia e Framework

O artigo propõe um framework baseado em contratos para operações agentes, deslocando o foco das capacidades centradas no modelo para a segurança e confiabilidade centradas no sistema. A metodologia é estruturada em torno de quatro pilares principais:

A. A Escada da Autonomia

Os autores modelam a autonomia não como um estado binário, mas como uma "escada de degraus", onde cada nível é definido por um contrato de capacidade específico ($A_k$):
$$A_k = (T^{read}_k, T^{write}_k, G_k)$$

• $T^{read}_k$: Ferramentas de somente leitura (consultas, recuperação).
• $T^{write}_k$: Ferramentas com capacidade de escrita, divididas ainda em propor (rascunhar diffs) e executar (aplicar alterações).
• $G_k$: Portões não contornáveis (verificações de política, invariantes, aprovações, regras de canário/rollback).

O framework define quatro níveis distintos de autonomia:

1. Copiloto (Somente leitura): Agrega e recupera evidências.
2. Analista (Maioria leitura): Realiza diagnóstico, mantém hipóteses e gera relatórios de RCA (Análise de Causa Raiz).
3. Planejador–Executor (Escrita limitada): Propõe alterações (diffs) que devem passar por um muro de verificação antes da execução.
4. Laço Fechado (Auto-cura): Executa ações delimitadas com rollback automático e monitoramento contínuo.

B. O Contrato de Fluxo de Trabalho

Para garantir "autonomia segura", o artigo define um contrato de fluxo de trabalho explícito ($C$) que rege o comportamento do agente:
$$C = (A_k, \Pi, I, R, B, S)$$

• $\Pi$: Políticas organizacionais (política como código).
• $I$: Invariantes operacionais (alcançabilidade, isolamento, guardas de SLO).
• $R$: Obrigações de evidência necessárias (o que deve ser observado antes de agir).
• $B$: Vetores de orçamento (chamadas de ferramenta, tokens, tempo, risco).
• $S$: Regras de parada (escalonamento, rollback ou condições de interrupção).

C. O Muro de Verificação

Um padrão arquitetural central é o Muro de Verificação, um portão não contornável entre a proposta e o commit. Um agente pode raciocinar livremente, mas qualquer ação de escrita ($a$) é executada apenas se passar por uma função de portão $g(a, E, \Pi, I)$ que valida a conformidade com a política e a satisfação de invariantes. Isso garante que a "fronteira de confiança" seja a interface onde uma proposta se torna uma ação executada.

D. Avaliação e Benchmarking

O artigo argumenta que a avaliação deve ir além da resposta estática a perguntas para uma avaliação centrada no fluxo de trabalho. Métricas-chave incluem:

• Qualidade do Rastro: Valor discriminatório das chamadas de ferramenta, completude das evidências e proveniência.
• Restrições de Segurança: Taxas de violação de política, ações desnecessárias e frequência de rollback.
• Resultados Operacionais: Tempo para mitigação (MTTR), tempo para sinalização (MTTD) e robustez contra desvios.
• Custo e Latência: Contagem de invocações de ferramenta, uso de tokens e latência de ponta a ponta.

3. Principais Contribuições

A pesquisa faz quatro contribuições primárias para o campo:

1. Taxonomia Fundamentada no Fluxo de Trabalho: Um sistema de classificação para NetOps e AIOps baseados em agentes, baseado em fases operacionais (observação, diagnóstico, decisão, ação) e níveis de autonomia, em vez de arquitetura interna do modelo. Associa papéis específicos a interfaces de ferramentas e modos de falha.
2. Padrões Arquiteturais e Barreiras de Segurança: Extração de padrões de design recorrentes, incluindo geração aumentada por recuperação (RAG) com consciência de frescor/proveniência, loops de uso de ferramentas e o "muro de verificação". Mapeia esses padrões para barreiras de segurança como acesso de menor privilégio, implantações em etapas e aprovação humana.
3. Prática de Avaliação e Orientação de Benchmark: Uma síntese de metodologias de avaliação que refletem o trabalho operacional real. Propõe definições de tarefas (ex.: precisão diagnóstica sob observabilidade parcial) e argumenta por benchmarks que medem utilidade e segurança de ponta a ponta, não apenas fluência linguística.
4. Análise de Segurança, Governança e Conformidade: Uma análise de riscos específicos para operações agentes, incluindo injeção de prompt via artefatos operacionais (tickets, runbooks), envenenamento de recuperação, ataques à integridade de telemetria e "agência excessiva". Enfatiza o reaproveitamento de abstrações existentes de verificação de rede como restrições de segurança aplicáveis.

4. Resultados e Descobertas

O artigo sintetiza a literatura existente para tirar várias conclusões críticas:

• Confiabilidade é Sistêmica, Não Centrada no Modelo: A confiabilidade operacional não vem principalmente do próprio LLM, mas da "máquina ao redor do modelo": interfaces de ferramentas tipadas, recuperação consciente de proveniência, orçamentos explícitos e portões de verificação.
• Autonomia Requer Restrições: À medida que a autonomia aumenta (subindo na escada), o ônus de engenharia desloca-se da qualidade da resposta para a ação segura. Sistemas de alta autonomia exigem envelopes de ação estritos, rollback automatizado e monitoramento contínuo.
• Raciocínio Causal é Complementar: O diagnóstico puramente baseado em LLM é frequentemente frágil. Abordagens híbridas que usam inferência causal ou grafos de dependência para estreitar o espaço de hipóteses, enquanto LLMs lidam com a tradução de intenção e aquisição de evidências, oferecem um caminho mais robusto.
• Lacunas de Avaliação: Benchmarks atuais frequentemente falham em considerar interfaces de ferramenta, hipóteses intermediárias e restrições de segurança. Muitos sistemas parecem robustos em demonstrações, mas são frágeis demais para alterações reais de infraestrutura devido à falta de pontuação consciente de rollback e testes de desvio.
• Riscos de Segurança são Agudos: Quando agentes ficam próximos a superfícies de controle operacionais, riscos como injeção de prompt via tickets ou manipulação de telemetria tornam-se críticos. O problema do "vice-confuso" (onde um agente é enganado a abusar de seus privilégios) é uma ameaça primária.

5. Significado e Alegações

O artigo alega que o progresso em NetOps e AIOps inteligentes depende de tratar a autonomia como um problema de controle operacional restrito.

• Alegações Modestas sobre Autonomia: Os autores são modestos sobre o estado atual da auto-cura em laço fechado. Argumentam que, embora assistência de somente leitura e auto-cura restrita (com verificação forte) sejam práticas, a auto-cura ampla em grandes sistemas imprevisíveis permanece um desafio significativo.
• Mudança de Paradigma: O significado reside em deslocar o foco da pesquisa de "como tornar LLMs mais inteligentes" para "como restringir LLMs dentro de contratos de segurança aplicáveis".
• Realidade Operacional: O artigo enfatiza que o sucesso operacional não é apenas sobre produzir a resposta correta, mas sobre o processo: quais evidências foram coletadas, quais ferramentas foram usadas, se o sistema parou quando as evidências foram insuficientes e se as alterações propostas respeitaram políticas e gatilhos de rollback.
• Governança como Artefatos: A governança é enquadrada não como texto de política, mas como artefatos aplicáveis (diffs, pacotes de aprovação, trilhas de auditoria) que tornam as decisões revisáveis e auditáveis.

Em conclusão, a pesquisa postula que, para sistemas agentes serem implantáveis em produção, eles devem ser projetados com "autonomia segura" como um requisito de primeira classe, apoiado por contratos de garantia, artefatos auditáveis e uma separação clara entre raciocínio e ação. Sem essas medidas, os sistemas podem parecer robustos em demonstrações, mas permanecem frágeis demais para o gerenciamento de infraestrutura do mundo real.