Come scegliere un modello di IA locale usando le tue attività

La domanda utile non è quale modello sia migliore in assoluto

Se hai diversi modelli locali tra cui scegliere, un punteggio pubblicato o una dimostrazione convincente non bastano per capire quale sarà davvero utile nel tuo flusso di lavoro. La decisione pertinente è più circoscritta: quale di questi modelli svolge in modo accettabile l’attività che vuoi effettivamente affidargli, con il dispositivo e la configurazione che intendi usare?

Un test di accettazione risponde a questa domanda usando un insieme limitato di attività reali o rappresentative, criteri stabiliti prima di vedere le risposte e condizioni di esecuzione confrontabili. Per esempio, un gruppo che vuole classificare richieste potrebbe verificare se ciascun modello assegna la categoria corretta e restituisce un risultato che il suo sistema può elaborare. La valutazione non consiste nello scegliere la risposta che suona meglio, ma nel verificare requisiti osservabili.

Un campione ridotto non diventa, per questo, una classificazione generale dei modelli. Il test può far emergere incompatibilità pratiche, come il mancato rispetto di un formato o errori in un tipo di input frequente; non dimostra però che il candidato sia affidabile in attività diverse, con altri utenti o su un altro hardware. Le conclusioni devono restare entro i limiti di ciò che è stato effettivamente testato.

Anche lo scopo è diverso da quello del confronto tra quantizzazioni: in questo test conviene mantenere fissa la configurazione pertinente, anziché decidere tra 4, 6 o 8 bit. Non si tratta nemmeno di un test di concorrenza, che esamina richieste simultanee, né di una verifica della privacy, che riguarda il traffico di rete. Se una di queste questioni è decisiva, serve una valutazione separata.

Inizia definendo l’attività e la soglia di accettazione

Prima di scaricare i candidati, descrivi il lavoro che vuoi delegare. Evita obiettivi vaghi come «rispondere bene» o «essere intelligente». Specifica che cosa riceve il modello, quale risultato ti aspetti e quali errori ne impedirebbero l’utilizzo. Più la descrizione assomiglia a un’attività concreta del flusso di lavoro, più sarà facile progettare esempi che permettano di distinguere i candidati.

Definisci anche che cosa significa «accettabile». Una bozza può essere utile anche se richiede una revisione; un’estrazione di dati inserita automaticamente in un database potrebbe invece dover contenere tutti i campi ed essere valida in ogni caso critico. Sono decisioni del gruppo, non proprietà universali di un modello. Metterle per iscritto prima del confronto riduce il rischio di cambiare i criteri a favore di un candidato.

Separa i criteri che descrivono risultati diversi. Correttezza dei contenuti, rispetto delle istruzioni e validità del formato non sono intercambiabili. Una risposta può essere corretta ma non rispettare lo schema richiesto; un’altra può avere il formato perfetto e contenere un dato errato. Se queste dimensioni vengono combinate senza spiegazioni in un unico voto, si perde un’informazione che potrebbe cambiare la decisione.

Quando ci sono più persone a valutare, concordate in anticipo come gestirete i disaccordi. Per le attività soggettive, è utile che almeno una parte degli esempi venga valutata separatamente da due persone, che poi confrontano le proprie motivazioni. Se non sono d’accordo, annotate quale regola era ambigua e chiaritela prima di interpretare differenze ridotte tra i modelli. Non è necessario fingere che una preferenza stilistica abbia una risposta oggettiva.

Seleziona i candidati e fissa le condizioni

Confronta candidati adatti allo stesso uso. Per ciascun modello, annota l’identificativo esatto e la versione disponibile, insieme al runtime, al dispositivo, al sistema di esecuzione e ai parametri pertinenti. Se non conservi questi dati, una differenza osservata potrebbe dipendere dall’ambiente e non dal modello, e sarà più difficile per un’altra persona ripetere il test.

Mantieni uguali le condizioni che puoi controllare: hardware, runtime e relativa versione, testo delle istruzioni, esempi di input, limite di contesto, parametri di generazione e trattamento dell’output. Se un modello richiede una configurazione diversa per avviarsi, documenta l’eccezione e valuta se il confronto risponde ancora alla stessa domanda. Non modificare i parametri a metà test per migliorare le risposte di un favorito senza poi rieseguire anche gli altri candidati in condizioni equivalenti.

Nei sistemi di generazione in cui le risposte possono variare tra un’esecuzione e l’altra, registra anche i parametri che influiscono sulla generazione e ripeti alcuni casi selezionati. Ripetere non elimina ogni incertezza, ma può mostrare che il risultato dipende da un’uscita particolarmente fortunata. Per esempio, la documentazione di Ollama descrive parametri di generazione configurabili nel formato Modelfile; le opzioni disponibili e il loro significato vanno verificati nella documentazione aggiornata del runtime utilizzato.

Anche la registrazione di latenza e memoria deve descrivere il metodo, non limitarsi a riportare un numero. Annota quale operazione hai misurato, quale strumento hai usato, quante ripetizioni hai eseguito e se il sistema stava svolgendo altre attività. Una misurazione locale può essere utile per decidere su quel dispositivo, ma non è automaticamente trasferibile a un altro.

Crea un piccolo insieme di esempi che rappresenti il lavoro

Non scegliere soltanto esempi facili o casi che ricordi perché un candidato li ha risolti bene. Raccogli input tipici dell’uso previsto e aggiungi situazioni che tendono a creare problemi. Il primo campione può essere ridotto, purché ogni caso abbia uno scopo esplicito; l’importante è non presentarlo come una rappresentazione statistica di tutto il lavoro.

Includi almeno tre tipi di input: casi comuni, casi limite e casi in cui il modello dovrebbe riconoscere che le informazioni disponibili non bastano. Se l’attività dipende dal rispetto di un formato, inserisci esempi che lo mettano alla prova. Se dipende dai contenuti forniti dall’utente, verifica se il modello si attiene a essi invece di colmare le lacune con supposizioni.

Prepara una risposta attesa o una guida di valutazione per ogni esempio prima di eseguire i modelli. Non è sempre necessario fissare un’unica frase come risposta corretta: per un riassunto può essere più adatto elencare i fatti che devono comparire e le affermazioni che non dovrebbero essere aggiunte. Per un’estrazione strutturata, invece, potrebbero esserci valori specifici e un formato atteso.

Proteggi la qualità del campione. Evita di includere informazioni riservate se non sono necessarie, rimuovi gli identificativi personali che non fanno parte del caso e conserva gli input in modo che chi valuta sappia quali dati erano disponibili. Se modifichi un esempio dopo aver visto i risultati, contrassegnalo come una nuova versione: non mescolare senza indicarlo il test originale e quello rivisto.

Valuta dimensioni distinte e registra gli errori

Una griglia di valutazione pratica distingue almeno la correttezza rispetto all’attività, il rispetto delle istruzioni, l’utilizzabilità del formato e gli errori critici. Definisci che cosa costituisce un errore critico per l’uso previsto: per esempio, un’estrazione errata che verrebbe elaborata senza revisione può avere conseguenze diverse da una frase poco elegante in una bozza. Un elenco generico di rischi non sostituisce la definizione del gruppo.

Oltre alla qualità del risultato, misura separatamente latenza e memoria osservata. Queste dimensioni rispondono a domande diverse: se il risultato è utile, quanto tempo impiega secondo il metodo scelto e quali risorse il sistema ha mostrato di utilizzare durante l’esecuzione. Evita di riunirle in un unico voto, a meno che tu non spieghi come sono state ponderate e perché quei pesi riflettono un’esigenza reale. Spesso è più utile presentare una tabella per dimensione e discutere i compromessi.

Registra ogni errore indicando il caso, la risposta, il criterio non rispettato e la gravità assegnata. Raggruppa gli errori per tipologia, come omissione, dato inventato, formato non valido o istruzione ignorata, se queste categorie sono pertinenti all’attività. Potrai così distinguere uno schema ricorrente da un errore isolato. Non nascondere un errore critico dietro una media elevata ottenuta su casi semplici.

Le misurazioni delle prestazioni richiedono una nota metodologica. Lo strumento llama-bench di llama.cpp documenta le ripetizioni e statistiche come media e deviazione standard, oltre a misure distinte per l’elaborazione del prompt e la generazione. Indica anche i limiti di ciò che viene incluso nella misurazione. È un esempio del motivo per cui conviene descrivere esattamente che cosa è stato misurato, invece di trattare qualsiasi cifra come una misura universale di velocità.

Esegui il test, esamina i risultati e prendi una decisione circoscritta

Esegui ogni caso usando lo stesso prompt e le condizioni registrate. Conserva gli output originali, compresi quelli difettosi: modificare o scartare una risposta prima di valutarla rende il test meno riproducibile. Se le risposte variano, ripeti i casi scelti seguendo una procedura definita e salva ogni output, non soltanto quello che sembra più rappresentativo.

Per ridurre i pregiudizi, valuta le risposte senza mostrare il nome del modello, quando è possibile. Se non puoi nasconderlo, applica almeno la stessa griglia a tutti i candidati e registra i disaccordi. In una revisione umana, criteri espliciti e valutatori aggiuntivi, quando disponibili, aiutano a individuare le decisioni soggettive. Se riporti l’accordo tra valutatori, spiega che cosa è stato confrontato e come sono state risolte le differenze.

Al termine, decidi se adottare ciascun candidato per un uso limitato, modificarlo e testarlo di nuovo oppure scartarlo. Una modifica cambia le condizioni del test: conserva la versione precedente e ripeti il confronto in modo comparabile. La scelta può dipendere da un requisito vincolante, per esempio che tutti i campi obbligatori siano validi, e non da chi ha ottenuto il punteggio complessivo più alto.

Una decisione responsabile può anche essere «nessuno è idoneo». Se gli errori riguardano requisiti essenziali, non è necessario scegliere il meno peggio solo per concludere il confronto. Se un candidato sembra adatto, la conclusione resta comunque provvisoria e limitata agli esempi, alla configurazione e al dispositivo testati.

Limiti, manutenzione e risorse correlate

Un test piccolo è esposto al bias di selezione: gli esempi possono favorire un modo di scrivere, un ambito o un tipo di input. Inoltre, il risultato dipende dal prompt e dalla configurazione. Pubblica quali casi hai usato, quali criteri hai applicato e in quali condizioni hai eseguito il test; non estendere la conclusione ad altre attività, versioni, dispositivi o gruppi di utenti senza ulteriori prove.

Se cambia l’uso previsto, rivedi il test. Aggiungere una nuova fonte di dati, modificare il formato di input o automatizzare una risposta che prima veniva controllata da una persona può cambiare gli errori importanti. Conserva le versioni del campione e della griglia, così da poter interpretare un confronto successivo. Un vecchio punteggio non garantisce che il comportamento resti accettabile dopo una modifica del sistema.

Gli strumenti di valutazione possono aiutare a organizzare attività e metriche, ma non stabiliscono che cosa significhi avere successo nel tuo caso. Il progetto lm-evaluation-harness documenta attività, metriche, prompt personalizzati e valutazioni locali. Può essere un riferimento o uno strumento utile quando è adatto alle tue esigenze; un punteggio ottenuto con un’attività standard, tuttavia, non sostituisce esempi propri e non dimostra che il modello rispetti i tuoi requisiti.

Questa guida riguarda l’accettazione o l’esclusione di candidati per un’attività specifica. Per approfondire, consulta la guida ai modelli locali, il comparatore e l’area di scoperta. Se la domanda successiva riguarda quantizzazione, concorrenza o privacy, affrontala separatamente: cambiare argomento senza modificare anche il protocollo può far sì che il confronto non risponda più alla domanda iniziale.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.