Affinamento iterativo con esempi

Quando un prompt non dà buoni risultati, gli architetti ricorrono a correzioni vaghe come "sii più preciso" o "impegnati di più". Raramente queste indicazioni producono un miglioramento significativo. La leva affidabile è costituita da criteri espliciti ed esempi concreti.

Confronta: "sii più preciso" con "segnala un commento solo quando contraddice il codice". La seconda indicazione dice al modello esattamente dove si trova il confine decisionale. In questa lezione imparerai a portare un prompt alla qualità necessaria per la produzione usando 2-4 esempi mirati di input/output e un ciclo rigoroso di test e iterazione.

Il prompting few-shot aggiunge alle istruzioni un piccolo insieme di esempi svolti. L'intuizione chiave è che il modello generalizza a partire dagli esempi, non si limita a copiarli. Dati 3 casi rappresentativi, deduce la regola sottostante e la applica a input mai visti.

Il few-shot è particolarmente efficace per quattro attività:

• Coerenza tra numerose chiamate
• Casi limite difficili da descrivere bene solo a parole
• Formato dell'output che il modello deve replicare
• Riduzione delle allucinazioni ancorando il comportamento

Puntate a 2-4 esempi per ogni ambiguità: abbastanza per definire il modello, ma non troppi, così da mantenere contenuto il contesto.

Un esempio few-shot efficace consiste in una coppia formata dall'input e dall'output esatto che desiderate ottenere. L'output deve corrispondere allo schema o alla struttura effettivamente utilizzati in produzione: stessi campi, stessa capitalizzazione, stessa struttura.

Di seguito, ogni esempio mostra un commento di input insieme al verdetto preciso. Il modello apprende il confine: segnalare solo le contraddizioni reali, non i dettagli di stile.

Gli esempi e i criteri espliciti sono complementari, non alternativi. I criteri stabiliscono la regola; gli esempi calibrano la zona grigia che la regola non riesce a descrivere completamente a parole.

Un errore comune degli architetti consiste nel riversare esempi senza alcuna istruzione guida. Il modello finisce così per adattarsi eccessivamente alle caratteristiche superficiali dei campioni. Iniziate sempre con un criterio chiaro, ad esempio "segnalare solo quando X contraddice Y", poi usate 2-4 esempi per definire con precisione i casi in cui X e Y si confondono.

Regola pratica: se non riuscite a formulare il criterio in una sola frase, l'attività è ancora poco specificata e altri esempi non risolveranno il problema.

Il perfezionamento iterativo è guidato dai test. Prima di ottimizzare il prompt, create un piccolo set etichettato di input rappresentativi con output corretti già noti. Questa è la vostra verità di riferimento: ogni modifica al prompt viene valutata rispetto a questo set, non in base a una semplice impressione.

Tenete il set di test separato dagli esempi few-shot. Se ottimizzate sugli stessi casi con cui insegnate, state memorizzando, non generalizzando.

Il ciclo di perfezionamento è meccanico e ripetibile:

• Eseguite il prompt su ogni caso di test
• Confrontate l'output con l'etichetta prevista
• Esaminate gli errori: quale confine non ha colto il modello?
• Aggiungete o rendete più preciso un esempio (o un criterio) mirato a quell'errore
• Eseguite di nuovo l'intero set e verificate che non si siano introdotte regressioni

Modificate una sola cosa per iterazione. Le modifiche raggruppate rendono impossibile capire quale intervento abbia migliorato o peggiorato il risultato.

Automatizzate il confronto per rendere rapida l'iterazione. Un piccolo harness esegue ogni caso, lo valuta e mostra quelli errati. Con un output strutturato potete confrontare direttamente i campi, invece di analizzare del testo discorsivo.

Notate tool_choice qui sotto: forzare una chiamata a uno strumento garantisce che il modello restituisca ogni volta JSON conforme allo schema, evitando che il valutatore si imbatta in testo libero.

Quando analizzate un errore, chiedetevi: quale ambiguità lo ha causato? Poi aggiungete un esempio che si trovi esattamente su quel confine, non un caso nuovo scelto a caso. Un esempio mirato per ogni modalità di errore generalizza molto meglio di dieci esempi generici.

Supponiamo che il modello abbia segnalato erroneamente un commento che parafrasava il codice. Aggiungereste un esempio associato che mostri parafrasi = nessuna contraddizione. Il modello aggiorna il proprio confine interno e l'intera classe di errori simili scompare.

Resistete alla tentazione di continuare ad accumulare esempi. Oltre i 4 circa per ambiguità, appesantite il contesto e rischiate il fenomeno lost-in-the-middle, in cui il modello presta meno attenzione alla parte centrale di un prompt lungo.

Alcuni errori riguardano il formato o la struttura, non il ragionamento: un campo malformato, un totale aritmetico errato, una parentesi mancante. In questi casi, la soluzione è retry-with-feedback: inviate nuovamente l'input originale, l'output errato e l'errore di convalida esatto.

Limite fondamentale: il nuovo tentativo è utile quando il modello è in grado di produrre la risposta corretta, ma ha commesso un errore. Non serve invece quando l'informazione richiesta è semplicemente assente dalla fonte: nessun numero di tentativi può inventare dati che non sono presenti.

Una volta che gli esempi hanno definito il comportamento, bloccate la struttura con uno schema JSON tramite l'uso degli strumenti. Questo elimina gli errori di sintassi e impone i campi obbligatori. La disciplina più importante è una sola: contrassegnate un campo come obbligatorio solo se è sempre presente.

Non rendete mai obbligatorio un campo che potrebbe essere assente: il modello inventerà un valore per soddisfare lo schema. Per dati facoltativi o aperti, usate un enum con un valore "other" più un campo di dettaglio a testo libero: in questo modo il contratto resta estensibile senza obbligare il modello ad allucinare.

Prima di fidarvi del prompt perfezionato, convalidatelo con un'istanza indipendente e nuova, non con la stessa sessione che ha prodotto l'output. Un'auto-verifica nella stessa sessione è soggetta a distorsioni: l'autore conserva il proprio ragionamento e non tende a metterlo in discussione.

Non affidatevi nemmeno al solo punteggio aggregato. Un valore come 97% di accuratezza può nascondere un campo o un tipo di input con prestazioni molto scarse. Prima di automatizzare, usate campionamento stratificato e confidenza a livello di campo, calibrati su un set di convalida etichettato. Il perfezionamento non è concluso quando la media appare buona, ma quando ogni segmento supera la soglia.

Punti chiave:

• Gli esempi sono più efficaci degli aggettivi. Criteri espliciti più 2-4 esempi mirati superano istruzioni vaghe come "siate più precisi".
• Il modello generalizza dagli esempi few-shot, particolarmente utili per la coerenza, i casi limite, il formato dell'output e la riduzione delle allucinazioni.
• Adottate un approccio guidato dai test: create un set etichettato, valutatelo, aggiungete un esempio sul confine per ogni modalità di errore, eseguite nuovamente il set e modificate una cosa alla volta.
• Retry-with-feedback corregge gli errori di formato (inviando l'originale, l'output errato e l'errore esatto), ma non i dati mancanti nella fonte.
• Bloccate la struttura con uno schema JSON; rendete obbligatori solo i campi sempre presenti; per l'estensibilità usate enum + "other" + dettaglio.
• Convalidate in modo indipendente: la verifica con una nuova istanza è migliore dell'auto-verifica nella stessa sessione, e i controlli stratificati a livello di campo sono migliori della sola accuratezza aggregata.