Oltre la classifica: benchmarking degli LLM su un compito reale di sicurezza

Per i problemi più difficili – il ragionamento visivo astratto come ARC-AGI-2, la matematica a livello di ricerca come FrontierMath, o domande multidisciplinari di livello esperto come Humanity's Last Exam – la classifica pubblica è una guida ragionevole: scegli il modello con il ranking più alto e probabilmente otterrai il risultato migliore.

Per i problemi semplici, come la classificazione del testo o l'estrazione di entità, il fine-tuning di un piccolo modello su poche migliaia di esempi etichettati spesso basta, a una frazione del costo.

Il divario interessante si trova nel mezzo: compiti che sono genuinamente complessi, che richiedono conoscenza reale del dominio e capacità di giudizio – ma non così difficili da poter essere gestiti solo da modelli di frontiera. In pratica, eseguire un modello di frontiera su ogni richiesta su larga scala non è sostenibile. Ma non è ovvio se modelli più piccoli ed economici possano reggere il confronto su compiti come questi.

Questo articolo esplora come abbiamo affrontato questa domanda in Red Sift – cosa abbiamo misurato, come lo abbiamo misurato, e cosa ci dicono i risultati sulla selezione dei modelli per compiti come questo.

Radar Lite esegue controlli di sicurezza automatizzati sui domini in tre aree: sicurezza email, integrità DNS e configurazione web/TLS. L'output grezzo è un registro strutturato dei risultati dei test – superato, fallito, avviso, neutro – con prove e osservazioni per ogni riscontro.

Il compito del sintetizzatore è tradurre tutto questo in un report leggibile in markdown: evidenziando i fallimenti più importanti, spiegando l'impatto nel mondo reale e fornendo raccomandazioni concrete.

Questo è un compito di benchmarking ideale per diversi motivi:

• Richiede una conoscenza reale del dominio. DMARC, SPF, DKIM, MTA-STS, DNSSEC, catene di certificati TLS – questi non sono argomenti che compaiono in modo significativo nei dati di addestramento generici. Un modello che tratta DMARC p=none come un risultato superato, o scambia una catena DNSSEC interrotta per un avviso minore invece che per un rischio di interruzione, produrrà sintesi che fuorviano attivamente i team di sicurezza.
• È difficile, ma non estremamente difficile. Le prove sono fornite – il modello non deve scoprire nulla, deve solo interpretarle correttamente e scrivere in modo chiaro. Il limite massimo è la scrittura strutturata e basata sul dominio, non il ragionamento aperto o la dimostrazione matematica.
• La qualità è misurabile. Accuratezza, completezza, struttura, chiarezza – ci sono dimensioni concrete e valutabili, il che rende possibile una valutazione coerente.
• La posta in gioco in termini di costo e latenza è reale. Radar Lite è uno strumento gratuito. Eseguire modelli di frontiera su ogni richiesta non è sostenibile su larga scala, quindi il compromesso costo-qualità ha conseguenze dirette in produzione.

Prima di eseguire qualsiasi controllo di sicurezza, Radar Lite analizza la query in linguaggio naturale dell'utente per rilevare due cose:

• Intento – su quale dominio di sicurezza sta chiedendo l'utente: EMAIL (DMARC, SPF, DKIM, MTA-STS), DNS (DNSSEC, record CAA), WEB (configurazione TLS, HTTPS, HSTS), oppure ANY per una valutazione completa su tutte e tre le aree
• Ambito – quanti domini sono coinvolti e come: SINGLE per un singolo dominio, MULTI per diversi domini valutati indipendentemente, o COMPARE per un confronto affiancato

Entrambi determinano quali controlli vengono eseguiti e, soprattutto, cosa ci si aspetta che il sintetizzatore produca – una sintesi COMPARE deve tracciare contrasti e dichiarare un vincitore; una sintesi MULTI necessita di una sezione separata per ogni dominio. Questo è ciò che rende il benchmark non banale da campionare: il compito cambia forma a seconda di cosa ha chiesto l'utente.

Abbiamo estratto circa 3.000 query di produzione reali dallo storage e le abbiamo campionate riducendole a un dataset di benchmark di 100 voci. Il campionamento casuale avrebbe favorito il tipo di query più comune – dominio singolo, intento any – quindi abbiamo utilizzato un campionamento stratificato per garantire che fosse coperta l'intera gamma di comportamenti del sintetizzatore:

Il dataset ha quattro proprietà chiave:

• Rappresentativo – la suddivisione per ambito rispecchia le proporzioni di produzione, sovracampionando deliberatamente MULTI e COMPARE, che sono strutturalmente più difficili e più propensi a rivelare i punti deboli del modello
• Diversificato – la suddivisione per intento garantisce che tutti e tre i domini di sicurezza siano coperti, invece di privilegiare il tipo di query più comune
• Non distorto – il vincolo di unicità del dominio significa che ogni voce è un'osservazione genuinamente indipendente; nessuna infrastruttura di una singola organizzazione influenza in modo sproporzionato i risultati
• Statisticamente significativo – con 100 voci, differenze di punteggio di circa 3-5 punti sono rilevabili in modo affidabile sulla scala normalizzata 0-1, rendendo possibile distinguere le differenze reali tra modelli dal rumore statistico

Le metriche automatiche standard come BLEU o ROUGE non funzionano in questo caso. Una buona sintesi non è quella che corrisponde a una stringa di riferimento – è quella accurata, ben strutturata e concretamente utile. Abbiamo utilizzato un approccio LLM-come-giudice, ma ci sono alcune varianti da considerare.

• Il confronto a coppie – chiedere a un modello giudice di scegliere il migliore tra due output – è popolare, ma con un gran numero di configurazioni di modelli e 100 voci ciascuna, servirebbero migliaia di confronti solo per classificarli. E anche allora, si saprebbe quale modello ha vinto senza sapere perché.
• Il punteggio diretto evita il problema della scalabilità, ma il giudice di fatto inventa la propria rubrica ogni volta, il che produce risultati incoerenti tra le esecuzioni.
• Una rubrica strutturata affronta entrambi i problemi: i criteri sono fissati in anticipo, quindi il giudice non ha margine di deriva, e i punteggi per criterio mostrano esattamente dove ogni modello risulta carente. Abbiamo usato una scala 0-2 anziché binaria perché alcuni criteri hanno uno stato intermedio genuino – parzialmente corretto è significativamente diverso da giusto o sbagliato.

Siamo arrivati a una rubrica di 13 criteri basata sui requisiti di output di Radar Lite:

• Accuratezza fattuale – nessun problema allucinato, tutti i fallimenti segnalati
• Linguaggio e tono – nessun gergo interno trapelato, formattazione corretta, registro professionale
• Gravità e struttura – uso corretto delle emoji, livelli di intestazione, raggruppamento dei problemi
• Profondità – specificità della causa radice, raccomandazioni concrete
• Correttezza del dominio – regole di soppressione MX-null (ad es. non segnalare l'assenza di MTA-STS su un dominio senza posta), formattazione specifica per l'ambito nelle query multi-dominio

Ogni criterio è valutato da 0 a 2, per un massimo di 26 punti grezzi, normalizzati su una scala 0-1.

Prima di utilizzare il giudice su larga scala, lo abbiamo validato. Tre modelli giudice candidati sono stati eseguiti ciascuno 5 volte in modo indipendente sulle stesse voci, e abbiamo misurato la coerenza per criterio – quanto spesso lo stesso modello ha dato lo stesso punteggio per lo stesso input in esecuzioni indipendenti. GPT-5.4 con basso sforzo di ragionamento è risultato il migliore: 11 criteri su 13 hanno prodotto punteggi identici in tutte le 5 esecuzioni, e le medie per criterio tra le esecuzioni sono variate da 0,81 a 0,88 – un intervallo ristretto che indica una calibrazione stabile. È stato selezionato come giudice per l'esecuzione completa del benchmark.

Abbiamo valutato modelli sia di fornitori commerciali che di rilasci open-source:

• OpenAI: GPT-5, GPT-5 mini, GPT-5 nano
• Anthropic: Claude Sonnet 4.6, Claude Haiku 4.5
• Google: Gemini 3.1 Pro, Gemini 3 Flash, Gemini 3.1 Flash Lite, Gemma 4 26B (via Vertex AI)
• Open-source self-hosted: Qwen3.5 122B, Qwen3.6 35B, Gemma 4 26B

Gemma 4 compare in entrambi gli elenchi – è stato eseguito sulla nostra infrastruttura e tramite Vertex AI, per verificare che la nostra configurazione produca risultati comparabili a quelli del fornitore gestito. Diversi modelli sono stati testati sia con che senza ragionamento esteso, per capire se la latenza aggiuntiva e il costo in token producano sintesi significativamente migliori.

Abbiamo eseguito ogni configurazione sull'intero dataset di 100 voci, con GPT-5 come giudice. Ecco cosa è emerso.

Gemini 3.1 Pro e Claude Sonnet 4.6 si trovano al vertice con 0,93 e 0,92. Ma non sono in una categoria diversa rispetto ai modelli sottostanti. Diversi modelli di fascia media – la maggior parte con qualche forma di ragionamento attivato – si raggruppano tra 0,88 e 0,90, tutti entro 0,05 dal miglior risultato: GPT-5 con basso ragionamento, Gemma 4 26B con ragionamento esteso e Gemini 3 Flash con basso ragionamento.

Gemini 3 Flash ha prodotto il miglior equilibrio complessivo nei nostri risultati: punteggio 0,88, latenza di 7 secondi, 0,76$ per 100 query – più di 5 volte più economico e più del doppio più veloce di Gemini 3.1 Pro. L'unico modello più veloce è GPT-5 nano senza ragionamento, che ottiene un punteggio significativamente più basso, 0,58.

Gemma 4 su Vertex AI è l'opzione praticabile più efficiente in termini di costi, con 0,17$ totali, un punteggio di 0,86 e una latenza di 13 secondi. Si posiziona appena sotto Gemini 3 Flash in termini di qualità, ma a meno di un quarto del costo. Per applicazioni ad alto volume, questa differenza si accumula rapidamente.

GPT-5 mini con basso ragionamento merita anch'esso una menzione: 0,87 a 0,46$, pari al punteggio del modello GPT-5 completo eseguito senza ragionamento (1,70$) – stessa qualità, un quarto del costo.

Eseguiamo Gemma 4 sulla nostra infrastruttura oltre che tramite Vertex AI. I risultati sono sostanzialmente identici in entrambe le modalità di ragionamento – 0,85 (self-hosted) contro 0,86 (Vertex AI) senza ragionamento, e 0,90 contro 0,89 con ragionamento attivato. Anche il numero totale di token di output su 100 query senza ragionamento è strettamente allineato: 51.223 (self-hosted) contro 52.405 (Vertex AI). Per i team che eseguono modelli aperti in produzione, questo tipo di verifica incrociata è importante: quando l'output self-hosted si allinea con l'API gestita sia in termini di qualità che di verbosità, si può essere sicuri che la propria implementazione sia configurata correttamente e che i risultati del benchmark si trasferiscano tra gli ambienti.

Nei modelli in cui sono state testate entrambe le modalità, il ragionamento esteso o basso aggiunge in genere 0,02-0,03 al punteggio:

• GPT-5: 0,89 (basso) contro 0,87 (nessuno)
• Claude Haiku 4.5: 0,86 (esteso) contro 0,83 (nessuno)
• Qwen3.5 122B: 0,85 (esteso) contro 0,83 (nessuno)

Se questo miglioramento giustifichi la latenza e il costo dipende dalla propria situazione. Per una sintesi di sicurezza – dove il compito è scrittura strutturata a partire da prove fornite piuttosto che ragionamento a più fasi – i guadagni sono reali ma non trasformativi.

L'eccezione evidente è GPT-5 nano: senza ragionamento ottiene 0,58, il punteggio più basso dell'intero benchmark, ed è l'unico modello che ha prodotto regolarmente sintesi incomplete o mal strutturate. Con un basso sforzo di ragionamento sale a 0,72. Per i modelli più piccoli con capacità intrinseca inferiore, il ragionamento potrebbe fare gran parte del lavoro pesante.

Eseguire questa valutazione ha cambiato il nostro modo di pensare alla selezione dei modelli per i compiti di produzione nell'intervallo "impegnativo ma non da frontiera":

1. Le classifiche generali testano l'ampiezza, non la profondità. Il ranking di un modello sui benchmark generali non predice come si comporterà su un compito specifico di dominio. L'unico modo per saperlo è fare un benchmark sul proprio carico di lavoro effettivo con i propri dati effettivi.
2. Il ragionamento è un compromesso, non un aggiornamento gratuito. Per la maggior parte dei modelli aggiunge 0,02-0,03 al punteggio a costo di una latenza significativa. Se ne valga la pena dipende dal proprio compito – per la scrittura strutturata basata su prove fornite, i guadagni sono reali ma modesti.
3. Fai il benchmark su dati di produzione, non su campioni sintetici. Il campionamento stratificato da query reali ha rivelato l'intera gamma di tipi di compito che un benchmark su dati sintetici avrebbe mancato. Il modello scelto può comportarsi in modo molto diverso sulla coda della propria distribuzione.
4. Il self-hosting è praticabile se lo si convalida. I modelli open-source eseguiti sulla propria infrastruttura possono eguagliare la qualità dell'API gestita – ma solo se lo si verifica. Punteggio, lunghezza dell'output e comportamento di ragionamento dovrebbero essere tutti allineati prima di distribuirlo in produzione.

Se vuoi vedere il tipo di sintesi che questi modelli generano, Radar Lite è gratuito da usare – basta inserire un dominio e porre una domanda.