Scegli un modello sulla base delle prove

Definisci la decisione

Il confronto tra modelli richiede un uso preciso. Un modello che spiega bene una piccola funzione potrebbe non gestire altrettanto bene una modifica ampia al repository. Un modello meno costoso può soddisfare i requisiti di qualità per trasformazioni ordinarie. Un’indagine difficile può richiedere maggiori capacità di ragionamento.

Scrivi prima il compito e i vincoli. Includi dati ammessi, strumenti richiesti, tempo di risposta e costo massimo accettabile. Alcuni vincoli sono obbligatori. Un punteggio elevato altrove non deve compensare una restrizione sul trattamento dei dati.

Usa compiti rappresentativi

Crea un piccolo insieme di valutazione dal lavoro reale del team. Rimuovi i dati sensibili, a meno che l’ambiente di valutazione sia approvato per quei dati. Includi compiti semplici, compiti difficili e compiti in cui la risposta corretta è chiedere informazioni mancanti.

Per un servizio fittizio di reportistica, usa un difetto noto sulle date, una piccola funzionalità di filtro e la spiegazione di una regola di autorizzazione. Prepara il risultato atteso prima del confronto. Includi un test negativo che rilevi il difetto noto.

Tieni alcuni compiti separati dallo sviluppo del prompt. Se perfezioni ripetutamente il prompt su ogni esempio, il punteggio finale può sovrastimare le prestazioni generali. Un insieme separato aiuta a capire se il prompt migliorato funziona oltre gli esempi usati per crearlo.

Mantieni equo il confronto

Registra versione esatta del modello, prompt, contesto fornito, strumenti e permessi. Usa stati iniziali equivalenti. Se un modello riceve un repository completo e un altro un solo file, il risultato confronta anche i flussi di lavoro.

Confrontare flussi di lavoro può essere utile. Descrivili correttamente. Un prodotto basato su agenti comprende più del modello: selezione del contesto, strumenti, limiti di esecuzione e comportamento di recupero possono influire sul risultato.

Ripeti le esecuzioni quando la variabilità dell’output conta. Registra i tentativi falliti invece di riportare solo il risultato migliore. Per i criteri soggettivi, usa una griglia scritta e più di un revisore quando possibile.

Valuta la qualità prima della velocità

Verifica prima i criteri obbligatori di accettazione. La modifica soddisfa il requisito? Mantiene i controlli di accesso? I test pertinenti passano? Un revisore riesce a capire il diff?

Confronta poi impegno, tempo trascorso e costo dei risultati accettabili. Includi nuovi tentativi e revisione umana. Una risposta economica che richiede correzioni ripetute può costare molto a livello di compito.

I benchmark pubblici possono aiutare a individuare i candidati. Usano insiemi di compiti e metodi di valutazione specifici. Non trattare il punteggio di un benchmark come misura diretta della produttività del team.

Registra la decisione e quando va rivalutata

Il risultato può essere una raccomandazione circoscritta. Per esempio: «Usa questo modello per piccole aggiunte ai test in questo repository, con i requisiti di revisione esistenti». Non serve un modello unico per ogni compito.

Indica cosa richiederebbe una nuova valutazione. Per esempio, una nuova versione del modello, una configurazione diversa degli strumenti, una nuova categoria di dati o uno schema di errore persistente. Mantieni un’alternativa per i compiti che superano le capacità del modello scelto.

La valutazione serve a ridurre l’incertezza su una decisione reale. Evita una competizione permanente tra modelli che richieda più lavoro di quello che dovrebbe aiutare.