Come valutare un LLM locale prima di usarlo in produzione

Un modello può ottenere buoni risultati su benchmark pubblici e fallire comunque nel lavoro che gli vogliamo affidare. Un workload aziendale contiene formati, strumenti, dati sporchi, vincoli di latenza, output strutturati e conseguenze operative che il benchmark non rappresenta.

Per questo la domanda utile non è «qual è il modello migliore?», ma «questa combinazione di modello, runtime e workload rispetta il contratto che ci serve?».

Il test dovrebbe partire da un contratto osservabile: input ammessi, output atteso, strumenti disponibili, tempo massimo, errori tollerabili e casi che devono fermare il flusso.

Se questi confini non esistono, un risultato apparentemente corretto può diventare una falsa autorizzazione.

Quantizzazione, context window, prompt format, tool calling, memoria disponibile e librerie del runtime possono cambiare il comportamento del modello. Lo stesso modello può quindi produrre risultati diversi in ambienti diversi.

Un test utile registra configurazione, versione, input, output, tempi e condizioni. In questo modo il risultato può essere ripetuto e confrontato.

Una prova riuscita dimostra una capacità entro condizioni precise. Non dimostra che il modello possa operare senza limiti su input diversi, dati nuovi o strumenti aggiuntivi.

Per workload sensibili conviene separare qualification e authorization: prima dimostrare la capacità, poi autorizzare un perimetro operativo ristretto e osservabile.

Questo approccio permette anche a modelli più piccoli di essere utili quando soddisfano un contratto specifico, e impedisce di affidare lavoro critico a un modello grande soltanto perché è forte in media.

L'obiettivo non è trovare il modello migliore in assoluto. È sapere cosa può fare, in quale ambiente, con quali prove e con quali limiti.