Sintesi Tecnica: Co-progettazione di Tokenizzazione Sensibile ai Protocolli e dell'Architettura per Modelli Fondativi di Pacchetti Wireless

Problema

Costruire modelli fondativi per le tracce di pacchetti wireless affronta una sfida critica: determinare se i guadagni di prestazioni siano guidati dall'architettura del modello (ad esempio, Transformer vs. Modelli a Spazio di Stato) o dalla rappresentazione dell'input (tokenizzazione). I dati dei pacchetti wireless possiedono una struttura nativa distinta dal linguaggio naturale, caratterizzata da intestazioni di protocollo a livelli, campi tipizzati e conversazioni governate da macchine a stati. Il lavoro precedente che utilizza tokenizer generici (ad esempio, BPE o codifiche a livello di byte) tratta queste tracce strutturate come testo piatto, frammentando i confini dei campi del protocollo e costringendo i modelli a spendere capacità per riscoprire strutture deterministiche già definite nella specifica del protocollo.

Le iterazioni precedenti del framework PLUME (Protocol Language Understanding Model for Exchanges) hanno introdotto un tokenizer sensibile al protocollo accoppiato a un backbone GPT a 12 livelli. Sebbene efficace, questo design lasciava aperte domande riguardo allo scaling ottimale (profondità vs. ampiezza) e alla trasferibilità del tokenizer sensibile al protocollo verso famiglie di architetture fondamentalmente diverse, come i Modelli a Spazio di Stato (SSM).

Metodologia

Gli autori conducono un'indagine controllata e sistematica per disaggregare gli effetti della tokenizzazione e dell'architettura. Lo studio utilizza un corpus curato di 7.890 file PCAP 802.11 enterprise (149K pacchetti, 48,9M di token), con il traffico beacon ridotto tramite HDBSCAN e campionamento MMR per concentrarsi sui dati conversazionali.

Il design sperimentale si basa su un confronto 2×2 attraverso due assi:

1. Tokenizzazione: Sensibile al protocollo (nomi di campi atomici, valori consapevoli del tipo, confini di livello) vs. Generica (a livello di byte).
2. Architettura: Transformer (GPT) vs. Modello a Spazio di Stato (Mamba-2).

Sono valutate quattro configurazioni primarie:

• PLUME-DEEP: Un GPT a 24 livelli (467M di parametri) che utilizza il tokenizer sensibile al protocollo. Questo modello testa l'ipotesi che la profondità sia l'asse di scaling corretto per i dati di protocollo gerarchici.
• PLUME-MAMBA: Un SSM Mamba-2 a 12 livelli (447M di parametri) che utilizza lo stesso tokenizer sensibile al protocollo. Questo testa la trasferibilità del tokenizer a un'architettura a tempo lineare.
• NETSSM: Un SSM Mamba-2 (170M di parametri) che utilizza un tokenizer generico a livello di byte. Serve come baseline per isolare l'impatto della tokenizzazione sul backbone SSM.
• Byte-GPT: Un modello GPT che utilizza un tokenizer generico a livello di byte per completare la matrice 2×2.

Tutti i modelli sono addestrati da zero utilizzando la previsione del next-token (perdita cross-entropy) sullo stesso dataset. La valutazione si concentra sulla precisione della previsione del next-packet su cinque categorie di guasto reali (ad esempio, Bad Password, EAPOL Timeout) e include metriche per throughput, perplexity e perdita.

Contributi Chiave

1. PLUME-DEEP: Un GPT da 467M di parametri e 24 livelli che raggiunge una precisione top-1 del 98,2% e una perplexity di 1,10 nella previsione del next-packet 802.11. Ciò rappresenta un guadagno di precisione di 32 punti rispetto al design originale a 12 livelli.
2. PLUME-MAMBA: Un SSM Mamba-2 che riutilizza il tokenizer sensibile al protocollo, raggiungendo una precisione top-1 del 96,1% con un throughput 1,7× superiore e finestre di contesto 2× più lunghe (8K vs. 4K token) rispetto alla variante transformer.
3. Confronto Controllato 2×2: Lo studio stabilisce che la tokenizzazione sensibile al protocollo è il principale leva di prestazione, mentre la scelta dell'architettura agisce come un comando di deployment.
   • Cambiare il tokenizer (sullo stesso backbone Mamba) produce uno scarto di precisione di 32 punti (64,1% vs. 96,1%).
   • Cambiare l'architettura (sotto lo stesso tokenizer sensibile al protocollo) produce solo uno scarto di precisione di 2 punti (98,2% vs. 96,1%).
4. Insight sullo Scaling: Il documento dimostra che per i dati di protocollo strutturati in un regime di dati limitati, la profondità è l'asse di scaling superiore. Aumentare la profondità da 12 a 24 livelli produce guadagni significativi, mentre aumentare l'ampiezza (dimensione dell'embedding) a profondità fissa porta a rendimenti decrescenti e overfitting.

Risultati

• Precisione: Entrambi i modelli sensibili al protocollo superano significativamente le baseline generiche. PLUME-DEEP guida in precisione (98,2% top-1), mentre PLUME-MAMBA raggiunge il 96,1%. Le baseline generiche (NETSSM e Byte-GPT) rimangono sotto il 65% di precisione top-1.
• Efficienza: PLUME-MAMBA raggiunge un throughput di 16.107 token/secondo rispetto ai 9.327 token/secondo di PLUME-DEEP, attribuito alla complessità in tempo lineare degli strati selettivi a spazio di stato di Mamba rispetto alla complessità quadratica dell'attenzione dei Transformer.
• Contesto: PLUME-MAMBA supporta un contesto di 8K token (circa 25 pacchetti), il doppio di PLUME-DEEP (4K token, circa 12 pacchetti), consentendo la modellazione di sequenze di transazione più lunghe come le catene RADIUS enterprise.
• Impatto della Tokenizzazione: Il tokenizer sensibile al protocollo comprime le sequenze di 6,2× (327 token/pacchetto vs. 2.014 per il livello di byte) e aumenta l'entropia dell'informazione per token da 6,70 a 7,61 bit. Questa compressione permette al modello di catturare più efficacemente la logica della macchina a stati tra i pacchetti.

Significato e Rivendicazioni

Il documento afferma che per i dati di protocollo strutturati, la rappresentazione conta più dell'architettura. L'insight principale è che un tokenizer che rispetta la struttura deterministica delle specifiche di protocollo (confini dei campi, informazioni sul tipo, gerarchia dei livelli) fornisce un bias induttivo che qualsiasi architettura a valle può sfruttare. Una volta stabilita questa rappresentazione, la scelta del backbone diventa un compromesso tra precisione (favorendo i Transformer profondi) e velocità/contesto (favorendo gli SSM), piuttosto che una differenza fondamentale di capacità.

Gli autori posizionano questo lavoro come un template di co-design per i modelli fondativi nativi del dominio, suggerendo che il principio di "prima la tokenizzazione consapevole della struttura, poi l'architettura" si estenda oltre il networking wireless ad altri domini gerarchici come la genomica, la chimica e i sistemi di controllo industriale. Il lavoro chiarisce inoltre che per le sequenze di protocollo, aumentare la profondità del modello è una strategia di scaling più efficace rispetto all'aumento dell'ampiezza, specialmente quando i dati etichettati sono scarsi.