Resumo Técnico: FAME – Mixture-of-Experts Consciente de Falhas para Detecção de Anomalias em Nível de Mensagem em Logs

Declaração do Problema

Sistemas distribuídos em produção geram milhões de linhas de log diariamente, contudo, os detectores de anomalias existentes operam tipicamente em nível de janela ou sessão. Essa granularidade grosseira atribui um único rótulo de anomalia a um grupo contíguo de linhas, forçando os operadores a inspecionarem manualmente centenas de mensagens rotineiras para localizar a falha específica. Embora a detecção em nível de mensagem (nível de linha) ofereça a precisão necessária para a localização direta de falhas, ela enfrenta três desafios significativos:

1. Ambiguidade de Modelo (C1): Um único modelo de evento (derivado da análise de logs) pode conter instâncias normais e anômalas dependendo dos valores dos parâmetros, tornando a identidade do modelo insuficiente para classificação.
2. Modos de Falha Heterogêneos (C2): As anomalias abrangem diversos subsistemas (por exemplo, erros de memória, partições de rede, falhas de sistema de arquivos). Um classificador global único luta para ajustar uma única fronteira de decisão entre essas populações heterogêneas sem sacrificar precisão ou revocação.
3. Escassez de Rótulos (C3): Rotular manualmente milhões de linhas na granularidade de mensagem é operacionalmente impraticável. Embora Modelos de Linguagem de Grande Escala (LLMs) possam raciocinar sobre a semântica dos logs, invocá-los para cada linha em um fluxo contínuo incorre em custos de API e latência proibitivos.

Metodologia: Framework FAME

O FAME (Failure-Aware Mixture-of-Experts) aborda esses desafios através de uma arquitetura Mixture-of-Experts (MoE) eficiente em rótulos e consciente de falhas. A ideia central é que o raciocínio do LLM é necessário apenas uma vez durante uma fase de configuração offline; todas as inferências subsequentes rodam em modelos leves e locais.

1. Fase de Configuração Offline

• Análise de Logs e Amostragem K-Shot: Os logs brutos são analisados em EventIDs usando o Drain3. Para controlar os custos de anotação, o sistema amostra no máximo K linhas rotuladas por EventID (por exemplo, K=100). Essas amostras são divididas em subconjuntos de treinamento e calibração.
• Particionamento Semântico Guiado por LLM: Um LLM é invocado uma única vez offline. Ele recebe estatísticas e exemplos representativos para cada EventID e propõe uma partição dos modelos em domínios de falha semanticamente coerentes (por exemplo, "Erros de Memória DDR", "Falhas de Link de Rede").
• Certificação: A proposta do LLM é validada deterministicamente contra os rótulos K-shot:
  • Domínios Puro-Anomalia: Se todas as K amostras em um domínio forem anômalas, o domínio é certificado como "puro-anomalia". Nenhum classificador é treinado; o mecanismo de roteamento atua como o detector.
  • Domínios Misto: Se as amostras contiverem linhas normais e anômalas, um classificador especialista dedicado é treinado.
  • Normal Universal: Modelos não atribuídos ou não anômalos são direcionados para um pool normal universal.
• Treinamento de Modelos:
  • Roteador: Um modelo DistilBERT leve é treinado para rotear linhas de entrada para o domínio de falha correto (ou para o pool Normal Universal). Ele consiste em um Portão binário (especialista vs. normal) e um Seletor multiclasse (especialista específico).
  • Especialistas: Domínios mistos são treinados usando uma abordagem de Duas Fases:
    1. Pré-treinamento MLM Adaptativo ao Domínio: O BERT continua o pré-treinamento em um grande corpus de logs normais para se adaptar à sintaxe dos logs.
    2. Ajuste Fino Supervisionado: Os especialistas são ajustados finamente com Focal Loss para lidar com desequilíbrio severo de classes, utilizando os dados rotulados K-shot e um pool de linhas normais.

2. Fase de Inferência Online

• Roteamento: As linhas de log de entrada são processadas pelo Portão. Se a pontuação estiver abaixo do limiar, a linha é roteada para o especialista Normal Universal. Se estiver acima, o Seletor a roteia para um domínio de falha específico.
• Detecção:
  • Linhas roteadas para domínios Puro-Anomalia são imediatamente sinalizadas como anomalias.
  • Linhas roteadas para domínios Misto são pontuadas pelo especialista específico e comparadas a um limiar calibrado.
  • Linhas roteadas para Normal Universal são pontuadas por um modelo fundido (combinando a pontuação do especialista e a saída do portão) para capturar anomalias mal roteadas.
• Saída: O sistema emite uma decisão binária de anomalia e um rótulo de domínio de falha, permitindo a localização direta de falhas sem reconstrução de sessão.

Contribuições Principais

1. Detecção em Nível de Mensagem com Roteamento por Domínio de Falha: O FAME produz tanto uma decisão binária de anomalia quanto um rótulo de domínio de falha nomeado para cada linha de log, permitindo a localização direta de falhas.
2. MoE Assimétrica Consciente de Falhas: O framework formaliza uma propriedade de confiança assimétrica sob amostragem K-shot: observar rótulos todos-anômalos em um domínio é estatisticamente conclusivo (permitindo detecção apenas por roteamento), enquanto rótulos todos-normais não o são. Isso permite que o sistema pule o treinamento de classificadores para domínios puro-anomalia.
3. Inferência Totalmente Local com Rotulagem Mínima: Após uma única invocação offline do LLM, toda a inferência roda em modelos locais, eliminando custos recorrentes de API e saída de dados. O sistema alcança alto desempenho com uma redução de 76× no esforço de anotação em comparação com a rotulagem completa em nível de linha.

Resultados Experimentais

O framework foi avaliado em dois benchmarks: BGL (Blue Gene/L, heterogêneo e difícil) e Thunderbird (logs de supercomputador, estruturalmente separáveis).

• Desempenho no BGL: Com K=100, o FAME alcança um F1 score de 98,16 (Precisão: 98,18, Revocação: 98,14). Isso supera significativamente as linhas de base de modelo único (por exemplo, Single BERT F1 ≈ 29,65) e detectores clássicos. Ele detecta 86,3% das anomalias de EventIDs não vistos (EventIDs não vistos durante o treinamento), demonstrando forte generalização.
• Desempenho no Thunderbird: O FAME atinge F1 = 99,95 com revocação perfeita, igualando o desempenho de linhas de base mais simples neste conjunto de dados mais fácil.
• Eficiência de Custos:
  • Anotação: Com K=100, o FAME requer apenas 53.287 linhas rotuladas no BGL, uma redução de 76× em comparação com a rotulagem do conjunto de dados completo de 4,7 milhões de linhas.
  • Custo de Inferência: O FAME incorre em um custo de configuração única de $10,23 (incluindo treinamento e uma única chamada de LLM). Em contraste, a inferência direta de LLM para a mesma tarefa custaria entre $6.698 e$10.047 por execução.
  • Vazão: O sistema processa até 1,20M linhas/hora em um único nó de 4 GPUs.
• Estudos de Ablação: Remover o roteamento MoE (usando um detector global único) causa uma queda drástica no desempenho, confirmando que a decomposição do problema em subproblemas especializados é o principal motor do sucesso. Remover o agrupamento baseado em LLM (usando TF-IDF) ainda produz resultados fortes (F1=93,01 no BGL), indicando que a arquitetura de decomposição por especialistas é o fator dominante, enquanto os LLMs servem como um impulsionador semântico.

Significado e Alegações

O artigo afirma que o FAME demonstra que detecção forte em nível de mensagem pode ser alcançada sem os custos proibitivos da inferência contínua de LLM ou da rotulagem manual exaustiva. Ao alavancar uma arquitetura de especialista roteado e as propriedades estatísticas da amostragem K-shot, o FAME transfere o ônus do raciocínio para uma configuração offline única.

Os autores enfatizam que a contribuição principal é a própria arquitetura e não a dependência de LLMs. O LLM é usado meramente para propor uma partição semântica, que é então validada e fixada. A capacidade do sistema de generalizar para modelos não vistos e fornecer rótulos de domínio de falha torna-o uma solução prática para ambientes de produção do mundo real, onde os operadores precisam de alertas precisos e acionáveis sem incorrer em custos massivos de API ou sobrecarga de revisão manual. O framework é apresentado como uma base para trabalhos futuros em adaptação online e análise causal de incidentes, mas o trabalho atual foca estritamente na eficácia do pipeline de inferência local com configuração offline.