Benchmark pubblici e classifiche dicono poco su come un modello si comporterà nel tuo use case con l’AI. Ecco i parametri che guardiamo davvero e come li misuriamo.
Quando si parla di differenze tra modelli LLM, la maggior parte delle persone pensa alle classifiche: il modello X supera il modello Y di due punti su un benchmark accademico. La realtà è molto diversa: quei due punti quasi mai si traducono in una differenza percepibile quando il modello deve rispondere a un cittadino che chiede come rinnovare un documento o a un cliente che vuole capire una bolletta.
In questo articolo raccontiamo come confrontiamo i modelli LLM nella pratica: quali parametri contano davvero per un Agente AI in produzione, quali metodi di valutazione usiamo nei nostri test interni e perché la risposta alla domanda “qual è il modello migliore?” è quasi sempre “dipende dal tuo caso d’uso”.
Perché i benchmark pubblici non bastano
I benchmark generalisti misurano capacità astratte: ragionamento matematico, cultura generale, coding. Utili per farsi un’idea, ma un Agente AI per il customer service lavora in condizioni diverse. Per prima cosa risponde in una o più lingue, spesso su domini regolati e con terminologia specifica; poi recupera le informazioni da una knowledge base aziendale tramite retrieval e non dalla memoria del modello. E infine deve seguire istruzioni precise: quando rispondere, quando dire “non lo so”, quando fare escalation a un operatore.
Un modello eccellente nei benchmark può inciampare proprio qui. E un modello più piccolo ed economico, con un buon retrieval, può bastare e avanzare. Per questo la domanda giusta non è “quale modello è il migliore?”, ma “quale modello è adeguato per questo compito, a questo costo?”.
Le differenze tra modelli LLM che pesano davvero
Nella nostra esperienza, le differenze che si vedono in produzione si concentrano su pochi assi.
- Qualità sulla lingua e sul dominio. Non tutti i modelli hanno la stessa resa in italiano (NdA: la lingua principale nei nostri Agenti AI in produzione), soprattutto su testi burocratici o tecnici. La differenza si nota nella precisione terminologica e nella naturalezza delle risposte.
- Aderenza alle istruzioni. Un Agente AI vive di istruzioni operative: prompt di sistema, policy, tono, limiti, formato delle risposte, regole di escalation e utilizzo dei tool. I modelli differiscono molto nella capacità di seguirle con continuità, decidendo quando usare gli strumenti disponibili.
- Comportamento con il contesto recuperato. Quando il retrieval fornisce i passaggi giusti, il modello li usa o li ignora? Quando il contesto non contiene la risposta, ammette di non sapere o inventa? Questa è forse la differenza più importante per un sistema RAG.
- Finestra di contesto utile. Non conta solo quanto contesto un modello accetta, ma quanto ne usa bene. Contesti lunghi e mal sfruttati producono risposte che ignorano informazioni presenti nei documenti.
- Latenza e costo. In una conversazione in tempo reale, la differenza tra 6 e 18 secondi di risposta cambia l’esperienza. E il costo per token, moltiplicato per milioni di messaggi, cambia il business case.
Come si testano: i metodi di valutazione che usiamo
I parametri elencati sopra restano opinioni finché non vengono misurati. Nei nostri test interni utilizziamo una serie di metriche per valutare scenari diversi, dalle modifiche ai modelli ai cambiamenti nell’architettura di un flusso agentico.
Il golden dataset: domanda e comportamento atteso
Tutto parte da un testbook: un dataset di domande reali, ciascuna abbinata al comportamento atteso dell’agente. Non solo “la risposta giusta“, ma cosa dovrebbe fare l’agente: rispondere con certe informazioni, chiedere un chiarimento, fare escalation. Senza questo riferimento, ogni confronto tra modelli rimane semplicemente “un’impressione“.
LLM-as-judge: un modello che valuta le risposte
Valutare manualmente migliaia di risposte è costoso e difficilmente scalabile. La soluzione pratica è l’LLM-as-judge: un modello valutatore confronta la risposta effettiva con il comportamento atteso e assegna un punteggio su una scala definita (per esempio 1.0 se soddisfa pienamente, 0.5 se va nella direzione giusta ma perde dettagli, 0.0 se fallisce), motivando il giudizio. Il criterio chiave è l’equivalenza semantica: non conta la formulazione esatta, conta se l’agente ha fatto ciò che doveva.
Le metriche di similarità testuale
Oltre al giudizio dell’LLM usiamo metriche classiche come BLEU e ROUGE-L, che misurano la sovrapposizione tra la risposta generata e un testo di riferimento. Da sole dicono poco, perché una risposta corretta può essere formulata in modo del tutto diverso dal riferimento. Ma come segnale complementare, su grandi volumi, aiutano a intercettare derive.
Le metriche di retrieval
Se l’agente lavora su una knowledge base, metà della qualità si gioca prima del modello. Per questo misuriamo separatamente retrieval precision e retrieval recall. Isolare il retrieval dal modello è essenziale: se il contesto recuperato è sbagliato, nessun LLM produrrà una buona risposta, e cambiare modello non risolverà nulla.
Confronti a parità di condizioni
L’ultimo principio è il più banale e il più violato: si cambia una variabile alla volta. È anche il motivo per cui abbiamo progettato Userbot attorno a blocchi componibili. Nell’Agent Builder ogni blocco è un agente specializzato: l’Agente Retriever che interroga la knowledge base, l’Agente Q&A per le risposte guidate, l’Agente Router che smista le richieste, fino ai blocchi di esecuzione codice per i test più tecnici. Questa modularità rende i confronti a parità di condizioni un gesto naturale: duplichi il flusso, sostituisci un solo blocco o una sola configurazione, e misuri la differenza. Il resto del flusso, i prompt e i dati restano identici, quindi il delta nei punteggi appartiene davvero alla variabile che hai toccato.
Cosa abbiamo imparato
Due lezioni ricorrenti dai nostri test.
- L’impatto del modello dipende dal ruolo che gli affidi. Nella generazione di risposte su knowledge base, molti problemi attribuiti all’LLM nascono a monte, nel retrieval o nella preparazione dei documenti. Ma in compiti come il routing, dove un Agente Router deve classificare la richiesta e smistarla verso l’agente giusto, la scelta del modello ha un impatto rilevante e diretto: un errore lì compromette tutto quello che viene dopo. Prima di cambiare modello, misura la pipeline e chiediti quale blocco stai davvero ottimizzando.
- Le differenze tra modelli LLM emergono sui casi difficili. Sulle domande semplici i modelli moderni si equivalgono. Le differenze si vedono sulle domande ambigue, su quelle senza risposta nella knowledge base e sulle istruzioni complesse. Il golden dataset deve contenere anche questi casi, non solo quelli facili.
Conclusione
Le differenze tra modelli LLM esistono e si pagano, in qualità o in costi. Ma non si leggono nelle classifiche: si misurano sul tuo use case, con i tuoi flussi e le tue domande reali, con metriche separate per ogni blocco della pipeline, dal retrieval al routing alla generazione. Un impianto di valutazione ben fatto vale più della scelta del singolo modello, perché è ciò che ti permette di scegliere, e di cambiare idea, ogni volta che il mercato si muove.
Se vuoi vedere come questo approccio funziona su un caso concreto, parla con un esperto Userbot → È gratuito, oppure stima l’impatto economico con il calcolatore ROI.
