Riepilogo Tecnico: FAME – Mixture-of-Experts Consapevole dei Guasti per il Rilevamento di Anomalie a Livello di Messaggio nei Log

Enunciato del Problema

I sistemi distribuiti di produzione generano milioni di righe di log ogni giorno, eppure i rilevatori di anomalie esistenti operano tipicamente a livello di finestra o di sessione. Questa granularità grossolana assegna un'unica etichetta di anomalia a un gruppo contiguo di righe, costringendo gli operatori a ispezionare manualmente centinaia di messaggi di routine per individuare il guasto specifico. Sebbene il rilevamento a livello di messaggio (o di riga) offra la precisione necessaria per la localizzazione diretta dei guasti, affronta tre sfide significative:

1. Ambiguità del Template (C1): Un singolo template di evento (derivato dall'analisi dei log) può contenere sia istanze normali che anomale a seconda dei valori dei parametri, rendendo l'identità del template insufficiente per la classificazione.
2. Modalità di Guasto Eterogenee (C2): Le anomalie abbracciano sottosistemi diversi (ad esempio, errori di memoria, partizioni di rete, guasti al filesystem). Un singolo classificatore globale fatica ad adattare un unico confine decisionale a queste popolazioni eterogenee senza sacrificare precisione o richiamo.
3. Scarsità di Etichette (C3): L'etichettatura manuale di milioni di righe a granularità di messaggio è operativamente impraticabile. Sebbene i Large Language Models (LLM) possano ragionare sulla semantica dei log, invocarli per ogni riga in un flusso continuo comporta costi API e latenza proibitivi.

Metodologia: Framework FAME

FAME (Failure-Aware Mixture-of-Experts) affronta queste sfide attraverso un'architettura Mixture-of-Experts (MoE) consapevole dei guasti ed efficiente nelle etichette. L'idea centrale è che il ragionamento degli LLM è richiesto solo una volta durante una fase di configurazione offline; tutte le successive inferenze vengono eseguite su modelli leggeri e on-premise.

1. Fase di Configurazione Offline

• Analisi dei Log e Campionamento K-Shot: I log grezzi vengono analizzati in EventID utilizzando Drain3. Per controllare i costi di annotazione, il sistema campiona al massimo K righe etichettate per EventID (ad esempio, K=100). Questi campioni vengono suddivisi in sottoinsiemi di addestramento e calibrazione.
• Partizionamento Semantico Guidato da LLM: Un LLM viene invocato una volta offline. Riceve statistiche ed esempi rappresentativi per ogni EventID e propone una partizione dei template in domini di guasto semanticamente coerenti (ad esempio, "Errori di Memoria DDR", "Guasti ai Collegamenti di Rete").
• Certificazione: La proposta dell'LLM viene validata in modo deterministico rispetto alle etichette K-shot:
  • Domini Puri-Anomalia: Se tutti i K campioni in un dominio sono anomali, il dominio è certificato come "puro-anomalia". Nessun classificatore viene addestrato; il meccanismo di instradamento agisce esso stesso come rilevatore.
  • Domini Misti: Se i campioni contengono sia righe normali che anomale, viene addestrato un classificatore esperto dedicato.
  • Normale Universale: I template non assegnati o non anomali vengono assegnati a un pool normale universale.
• Addestramento del Modello:
  • Router: Un modello DistilBERT leggero viene addestrato per instradare le righe in arrivo al corretto dominio di guasto (o al pool Normale Universale). È composto da un Gate binario (esperto vs normale) e da un Selettore multiclasse (esperto specifico).
  • Esperti: I domini misti vengono addestrati utilizzando un approccio a Due Fasi:
    1. Pre-addestramento MLM Adattivo al Dominio: BERT viene sottoposto a pre-addestramento continuo su un vasto corpus di log normali per adattarsi alla sintassi dei log.
    2. Fine-tuning Supervisionato: Gli esperti vengono affinati con Focal Loss per gestire lo squilibrio di classe severo, utilizzando i dati etichettati K-shot e un pool di righe normali.

2. Fase di Inferenza Online

• Instradamento: Le righe di log in arrivo vengono elaborate dal Gate. Se il punteggio è inferiore alla soglia, la riga viene instradata all'esperto Normale Universale. Se superiore, il Selettore la instrada a un dominio di guasto specifico.
• Rilevamento:
  • Le righe instradate a domini Puri-Anomalia vengono immediatamente segnalate come anomalie.
  • Le righe instradate a domini Misti vengono valutate dall'esperto specifico e confrontate con una soglia calibrata.
  • Le righe instradate al Normale Universale vengono valutate da un modello fuso (che combina il punteggio dell'esperto e l'output del gate) per catturare anomalie instradate erroneamente.
• Output: Il sistema restituisce una decisione binaria di anomalia e un'etichetta di dominio di guasto, consentendo la localizzazione diretta del guasto senza ricostruzione della sessione.

Contributi Chiave

1. Rilevamento a Livello di Messaggio con Instradamento per Dominio di Guasto: FAME produce sia una decisione binaria di anomalia che un'etichetta di dominio di guasto nominata per ogni riga di log, consentendo la localizzazione diretta del guasto.
2. MoE Asimmetrico Consapevole dei Guasti: Il framework formalizza una proprietà di confidenza asimmetrica sotto il campionamento K-shot: osservare etichette tutte-anomale in un dominio è statisticamente conclusivo (permettendo il rilevamento tramite instradamento solo), mentre le etichette tutte-normali non lo sono. Ciò permette al sistema di evitare l'addestramento di classificatori per i domini puri-anomalia.
3. Inferenza Completamente On-Premise con Etichettatura Minima: Dopo una singola invocazione offline dell'LLM, tutte le inferenze vengono eseguite su modelli locali, eliminando costi API ricorrenti ed egress dei dati. Il sistema ottiene prestazioni elevate con una riduzione di 76× dello sforzo di annotazione rispetto all'etichettatura completa a livello di riga.

Risultati Sperimentali

Il framework è stato valutato su due benchmark: BGL (Blue Gene/L, eterogeneo e difficile) e Thunderbird (log di supercomputer, strutturalmente separabili).

• Prestazioni su BGL: Con K=100, FAME raggiunge un punteggio F1 di 98,16 (Precisione: 98,18, Richiamo: 98,14). Questo supera significativamente le baseline a modello singolo (ad esempio, Single BERT F1 ≈ 29,65) e i rilevatori classici. Rileva l'86,3% delle anomalie da EventID non visti (EventID non osservati durante l'addestramento), dimostrando una forte generalizzazione.
• Prestazioni su Thunderbird: FAME raggiunge F1 = 99,95 con richiamo perfetto, eguagliando le prestazioni di baseline più semplici su questo dataset più semplice.
• Efficienza dei Costi:
  • Annotazione: Con K=100, FAME richiede solo 53.287 righe etichettate su BGL, una riduzione di 76× rispetto all'etichettatura dell'intero dataset di 4,7 milioni di righe.
  • Costo di Inferenza: FAME sostiene un costo di configurazione una tantum di 10,23 $ (inclusi addestramento e una singola chiamata LLM). Al contrario, l'inferenza diretta con LLM per la stessa attività costerebbe tra 6.698 $e 10.047$ per esecuzione.
  • Throughput: Il sistema elabora fino a 1,20 milioni di righe/ora su un singolo nodo con 4 GPU.
• Studi di Ablazione: Rimuovere l'instradamento MoE (utilizzando un singolo rilevatore globale) causa un crollo drastico delle prestazioni, confermando che la decomposizione del problema in sottoproblemi specializzati è il principale motore del successo. Rimuovere il raggruppamento basato su LLM (utilizzando TF-IDF) produce comunque risultati solidi (F1=93,01 su BGL), indicando che l'architettura di decomposizione in esperti è il fattore dominante, mentre gli LLM fungono da potenziatori semantici.

Significato e Affermazioni

Il paper afferma che FAME dimostra che è possibile ottenere un rilevamento a livello di messaggio robusto senza i costi proibitivi dell'inferenza continua degli LLM o dell'etichettatura manuale esaustiva. Sfruttando un'architettura di esperti instradati e le proprietà statistiche del campionamento K-shot, FAME sposta l'onere del ragionamento su una configurazione offline una tantum.

Gli autori sottolineano che il contributo principale è l'architettura stessa piuttosto che la dipendenza dagli LLM. L'LLM viene utilizzato semplicemente per proporre una partizione semantica, che viene poi validata e fissata. La capacità del sistema di generalizzare a template non visti e di fornire etichette di dominio di guasto lo rende una soluzione pratica per ambienti di produzione reali, dove gli operatori necessitano di alert precisi e azionabili senza sostenere costi API massicci o oneri di revisione manuale. Il framework è presentato come una base per lavori futuri nell'adattamento online e nell'analisi causale degli incidenti, ma il lavoro corrente si concentra rigorosamente sull'efficacia della pipeline di inferenza on-premise con configurazione offline.