I leaderboard degli agenti ingannano — fai benchmark sui tuoi strumenti

I leaderboard pubblici degli agenti sembravano autorevoli — finché i team hanno iniziato a spedire in produzione con il modello classificato al primo posto. A quel punto, il tasso di errore nelle tool call in produzione non assomigliava per niente al punteggio sul grafico. Il motivo è strutturale: ogni benchmark pubblicato testa un insieme fisso e curato di strumenti generici, e il tuo stack interno quasi certamente non è nessuna di quelle cose. La posizione onesta è che la scelta del modello per workload agentici è impossibile da rispondere senza un eval harness puntato sulle tue tool surface.

Come è cambiato il modo in cui il settore misura le capacità degli agenti

Il post del team di Hugging Face "Is it agentic enough?" rende esplicita la critica strutturale. I benchmark agentici dominanti — incluse suite ampiamente citate costruite attorno a web search, calcolatrici e file I/O — condividono un unico vincolo di progettazione: le tool surface sono fisse e standardizzate in modo che i risultati siano comparabili tra i laboratori. Questa è la proprietà giusta per un leaderboard comparativo. È la proprietà sbagliata per un operatore che vuole scegliere un modello per un agente interno che chiama un ERP proprietario, una API custom di document retrieval e un servizio SOAP legacy avvolto in un sottile shim REST.

Il post fa emergere anche il problema del compounding a più passi. Un modello che raggiunge l'80% di accuratezza nelle tool call a singolo step non consegna l'80% di task completion su una catena a 5 step — consegna circa il 33% (0,8⁵). I leaderboard quasi sempre riportano punteggi a singolo step o a orizzonte breve. Il divario tra quei punteggi e il task completion nel mondo reale si allarga in modo non lineare con la lunghezza della catena — ed è esattamente lì che vive il lavoro enterprise sugli agenti: lookup multi-hop, branch condizionali, step di write-back.

I rilasci di modelli open hanno accelerato questo problema nel 2025 e nella prima metà del 2026. Quando un nuovo modello segna un miglioramento di 3 punti su un benchmark pubblico, la model card viaggia veloce. Lo schema di tool call su cui è stato addestrato — se preferisce il function calling in JSON rigido, uno scratchpad in stile ReAct, o un loop di code execution — riceve molta meno attenzione nell'annuncio, ma è quello che determina se il modello degrada in modo controllato o catastrofico sul tuo schema.

Perché questo cambia i conti sull'ownership della tua eval degli agenti

La maggior parte dei team nella fascia 50–500 FTE non ha infrastruttura di eval per gli agenti. Hanno un ambiente di staging, un manciata di test manuali e qualcuno che esegue il modello su qualche prompt rappresentativo prima di un deployment. Era sufficiente quando gli LLM completavano testo. Non è sufficiente quando il modello chiama strumenti con effetti collaterali — scrive record, attiva workflow, aggiorna stato.

L'implicazione strategica è che la decisione "quale modello usare per il nostro agente interno?" viene presa attualmente senza dati validi nella maggior parte delle aziende. I team fanno pattern matching sui titoli dei benchmark, sulla reputazione del vendor, o sul costo per token. Tutti e tre sono criteri di spareggio ragionevoli quando due modelli sono altrimenti equivalenti per il tuo task. Nessuno dei tre è un sostituto per misurare accuratezza delle tool call, aderenza allo schema e tasso di completion multi-step sui tuoi strumenti reali.

C'è anche un rischio di sourcing che taglia dall'altra parte. Se non hai costruito l'eval harness, non puoi nemmeno rilevare regressioni quando aggiorni il modello o cambi lo schema di uno strumento. Gli stack agentici non sono statici — gli strumenti evolvono, i modelli vengono sostituiti, i template dei prompt derivano. Senza eval continua su trace rappresentative, voli senza strumenti ogni volta che qualcosa cambia.

La mossa del lunedì mattina

La prima domanda è se hai le precondizioni per eseguire un eval significativo. Segui questa sequenza prima di spendere tempo nel confronto tra modelli:

• Hai trace di tool call da produzione o staging? Se no, strumenta il tuo agent framework per loggare ogni tool call, lo schema di input inviato, l'output grezzo del modello e il risultato parsato. 2-3 giorni di traffico anche a volume moderato ti danno abbastanza per costruire un corpus di replay.
• Hai label ground-truth per un sottoinsieme di quelle trace? Ti servono almeno 50-100 esempi etichettati — strumento corretto selezionato, argomenti corretti, risposta finale corretta — per ottenere un segnale che non sia rumore. A etichettare devono essere gli esperti di dominio nel tuo team, non gli ML engineer.
• Il tuo numero di strumenti è abbastanza alto da far contare la scelta del modello? Sotto circa 5 strumenti, quasi qualsiasi modello open capace si comporta in modo simile. Sopra 10 strumenti, specialmente con schema sovrapposti o ambigui, la scelta del modello inizia a contare significativamente. Sopra 20, è probabilmente la variabile dominante nell'affidabilità degli agenti.

Una volta soddisfatte quelle precondizioni, l'eval effettiva non è costosa da eseguire. Scegli 2-3 modelli candidati — come minimo quello che stai usando, uno challenger dalla coorte open-weight attuale e un modello più piccolo ottimizzato per il costo come baseline. Esegui tutti e tre sul tuo corpus di replay con prompt identici. Misura separatamente accuratezza delle tool call a singolo step, validità degli argomenti rispetto allo schema ed end-to-end task completion su trace multi-step. I delta ti diranno più in un pomeriggio che un anno di lettura di post sui leaderboard.

Se il tuo team non ha la capacità di costruire l'harness questa settimana, la versione minima praticabile è un log strutturato e un campione etichettato. Il replay runner puoi costruirlo dopo. Non lasciare che l'infrastruttura di eval perfetta ti blocchi dal iniziare a raccogliere i dati di cui avrai bisogno.

Quanto costa, e quanto fa risparmiare

Costruire un eval harness minimale per agenti richiede circa 2-4 settimane-ingegnere per farlo bene — strumentazione, un replay runner, un workflow di labeling e un layer di reporting abbastanza semplice da essere letto da un product manager. È un costo reale, e sembrerà una tassa infrastrutturale in un trimestre in cui la feuille de route è già piena.

Il costo alternativo è più difficile da vedere ma più grande. I team che saltano l'eval tipicamente scoprono in produzione i failure mode specifici del modello. Nel caso migliore, significa un'esperienza utente degradata per un ciclo di sprint mentre si fanno hot-fix ai template dei prompt. Nel caso peggiore — quando gli agenti hanno accesso in scrittura ai system of record — significa problemi di integrità dei dati che ci vogliono settimane a dipanare. Il rischio di regressione da solo giustifica l'investimento infrastrutturale: ogni aggiornamento del modello senza un harness è una modifica non controllata a un sistema con effetti collaterali. Le aziende che avranno un vantaggio duraturo nell'affidabilità degli agenti nei prossimi 18 mesi non sono quelle che hanno scelto il modello giusto da un leaderboard. Sono quelle che hanno costruito prima il layer di misurazione.