Sostituire una chiamata a un LLM con un modello di classificazione veloce sembra la mossa giusta per ridurre costi e latenza nei pipeline degli agenti. Ma una valutazione paired e auto-auditata su 11 punti decisionali racconta una storia diversa: il risparmio può dissolversi quando il costo del pre-screening viene incluso e l’accuratezza di un gate non equivale alla qualità end-to-end.

Il lavoro parte da 7.283 casi base e 6.640 varianti di robustezza costruite da 18 fonti pubbliche. Confronta due modelli System-1: Laya, open-weight, e Jev, ospitato. Su 11 compiti tipici di un agent harness, Jev è significativamente più accurato su 9 punti, con un vantaggio da +10,8 a +46,0 punti percentuali. Il routing di modelli in zero-shot resta al livello del caso per entrambi, e il gating di rilevanza per la RAG finisce in parità.

La fragilità di Laya emerge nelle varianti. Quando l’ordine delle opzioni viene invertito, il modello open-weight cambia il 30% delle risposte. Nei casi con uno strumento corretto univoco, la precisione scende al 31% con 50 strumenti vicini, contro il 98% di Jev. Non è un semplice calo medio: è un comportamento instabile che può cambiare la decisione di routing in produzione.

L’aspetto più significativo è l’audit della pipeline degli stessi autori. Tre errori di analisi e un confondimento di design hanno distorto le conclusioni iniziali. Il risparmio dichiarato del 23,9% scende al 4,3% quando si include il costo del pre-screening. L’accuratezza del gate riportata come qualità end-to-end confonde un 58% con un 98% reale. Le soglie calcolate in-sample promettevano un 5% di mancati, ma sui dati held-out gli errori arrivano fino al 17%. Un effetto canale sui falsi positivi da injection svanisce quando i contenuti sono nativi del canale.

Il punto strutturale è che nei pipeline agentici il modello veloce non è il prodotto finale. Un decision model va valutato sull’intera catena di decisioni, non sul singolo task. Per chi valuta deployment on-premise, esistono trade-off tra modelli aperti self-hosted e servizi ospitati: il controllo e l’ispezionabilità di un modello open-weight non bastano se non lo si sottopone a test di robustezza che includano ordine delle opzioni, numero di candidati e contenuti nativi del canale. AI-RADAR offre framework analitici su /llm-onpremise per valutare questi trade-off. Il repository con casi, output grezzi e codice di analisi è pubblico: un segnale di metodo che dovrebbe diventare prassi.