Chi sceglie un modello guardando SWE-bench e LiveCodeBench rischia di comprare un motore tarato su un circuito di prova. Un gruppo di ricercatori ha costruito una suite di valutazione basata su Django e ha messo a confronto modelli foundation e checkpoint sottoposti a fine-tuning su traiettorie SWE-bench. Il risultato è netto: i ranking spesso non si generalizzano, il trasferimento tra task è scarso e i guadagni ottenuti su SWE-bench non si traducono in miglioramenti sulla suite Django né su LiveCodeBench.

Il problema non è il benchmark in sé, ma il divario tra punteggio misurato e capacità dichiarata. Quando un modello viene ottimizzato su un benchmark, quel benchmark smette di essere un campione rappresentativo e diventa un obiettivo di addestramento. Ciò che misura, da quel momento, è la performance su un task specifico, non la capacità generale di coding. Nel caso studiato, anche il fine-tuning su singole modalità di Django non ha prodotto trasferimento: un segnale che l'ottimizzazione non costruisce competenze trasversali, ma specializza il checkpoint su una distribuzione ristretta.

Per chi gestisce LLM self-hosted, questa distorsione ha conseguenze concrete. La scelta di un modello on-premise non si ferma alla scheda tecnica: determina quanta VRAM serve, quale livello di quantization è accettabile, quanto costa l'inference e quali garanzie di sovranità dei dati si possono mantenere senza uscire dal perimetro aziendale. Se il punteggio su un benchmark pubblico è gonfiato da un'ottimizzazione specifica, il calcolo del TCO parte da una premessa fragile: si può sovradimensionare l'infrastruttura per un modello che poi non regge sul codice proprietario, oppure scartare un modello più adatto perché meno visibile in classifica. In entrambi i casi, il costo non è solo economico: è un costo di fiducia nel processo di selezione.

I ricercatori non chiedono solo più benchmark. Propongono una valutazione differenziata: assessment olistico per i modelli di frontiera, suite multi-task per la ricerca, studi con umani nel loop per applicazioni ristrette. A questo si aggiunge un punto strutturale: serve una tassonomia delle capacità e una manutenzione continua dei benchmark, non release una tantum. È una posizione scomoda per chi produce modelli, perché riduce la possibilità di presentare un singolo numero come prova di superiorità. Ma senza standard di valutazione affidabili, ingegneri e ricercatori che usano LLM e agenti restano con evidenze insufficienti per decidere sviluppo, ricerca e deployment.

Per chi valuta deployment on-premise, il messaggio non è 'evita i benchmark', ma 'non usarli come scorciatoia'. AI-RADAR offre framework analitici su /llm-onpremise per confrontare i trade-off tra modelli, infrastruttura e costi operativi quando i benchmark non bastano a raccontare la realtà di un ambiente locale.