Progettare esempi efficaci

Nel prompting few-shot, le dimostrazioni sono il set di addestramento, semplicemente fornito al momento dell'inferenza. Ogni proprietà importante per i dati di fine-tuning vale anche in questo caso: rappresentatività, copertura, accuratezza delle etichette, diversità e assenza di leakage.

Esempi poco curati insegnano comportamenti poco curati. Il modello imiterà fedelmente le cautele, la prolissità, la formattazione incoerente e gli errori di ragionamento sottili presenti nelle dimostrazioni.

Scelga dimostrazioni la cui distribuzione degli input corrisponda al traffico di produzione. Un set di dimostrazioni impeccabili, brevi e semplici fallirà sugli input disordinati, lunghi e ambigui che gli utenti inviano realmente.

Campioni i log reali, li raggruppi in cluster e scelga un rappresentante per ciascun cluster. In questo modo coprirà le modalità della distribuzione molto meglio che selezionando manualmente esempi impressionanti ma atipici.

Oltre agli input tipici, includa deliberatamente gli edge case che il modello gestisce male: negazioni, input multi-etichetta, sarcasmo, unità e risposte nulle. Una singola dimostrazione che mostri la gestione corretta di un rifiuto esplicito o di un risultato vuoto insegna un comportamento che le istruzioni in prosa raramente riescono a garantire.

Mantenga un insieme aggiornato di casi problematici raccolti in produzione e inserisca a rotazione nel prompt quelli più istruttivi.

Ogni dimostrazione deve usare una formattazione identica: stessi delimitatori, stesso ordine delle chiavi, stesso uso di maiuscole e minuscole, stessa spaziatura e stesso stile di ragionamento. Il modello presta attenzione alle regolarità superficiali; qualsiasi incoerenza diventa rumore che potrebbe riprodurre in modo imprevedibile.

Esegua programmaticamente il lint degli esempi. Se gli output sono JSON, convalidi ciascuno rispetto allo schema prima che entri in un prompt.

Le dimostrazioni ridondanti sprecano contesto e amplificano qualsiasi bias condividano. Massimizzi l'informazione per token selezionando un sottoinsieme diversificato, per esempio tramite Maximal Marginal Relevance, che bilancia la rilevanza con la dissimilarità rispetto agli esempi già scelti.

La diversità dovrebbe estendersi alle dimensioni rilevanti per il task, non soltanto alla forma lessicale superficiale.

Per i task di ragionamento, l'output della dimostrazione dovrebbe modellare l'esatto percorso di pensiero desiderato: conciso, corretto e sempre nella stessa struttura. Se una dimostrazione ragiona in tre passaggi e un'altra in sette, il modello non apprende alcuna strategia stabile.

Preferisca un ragionamento conciso e verificabile a una narrazione prolissa; motivazioni lunghe aumentano i costi e possono insegnare a divagare.

Le dimostrazioni possono introdurre segnali spurii. Se ogni esempio positivo è casualmente lungo e ogni esempio negativo è breve, il modello impara la lunghezza, non il sentiment. Verifichi le dimostrazioni per individuare correlazioni accidentali tra caratteristiche superficiali ed etichette.

Eviti inoltre di rivelare la risposta attraverso la formulazione dell'input (per esempio, una dimostrazione il cui input contiene già l'etichetta target come parola).

Mescoli livelli di difficoltà, così il modello vede sia corrispondenze semplici sia complesse, ma mantenga sotto controllo la lunghezza degli esempi. Dimostrazioni molto lunghe comprimono la query corrente e possono innescare fenomeni di perdita nel mezzo, in cui il contesto centrale riceve meno attenzione.

Raggruppi le dimostrazioni per lunghezza e punti a un set equilibrato e compatto che copra comunque l'intera gamma di difficoltà.

Per definire i confini, includa dimostrazioni di ciò che il modello non dovrebbe fare, abbinate alla risposta corretta. Mostri una richiesta che deve essere rifiutata o un input fuori ambito che produca una risposta nulla appropriata.

Queste dimostrazioni negative sono spesso gli esempi con il maggiore impatto sulla sicurezza, sul controllo dell'ambito e sulla gestione strutturata dei valori nulli.

I set di dimostrazioni sono artefatti da sottoporre a controllo versione e test di regressione. Quando sostituisce un esempio, esegua nuovamente il proprio harness di valutazione; una singola dimostrazione errata può ridurre l'accuratezza di diversi punti o modificare il formato dell'output.

Associ a ogni deployment del prompt l'hash del set di dimostrazioni, così potrà attribuire i cambiamenti di qualità e ripristinare con precisione la versione precedente.

In sintesi: raccolga gli input reali, li etichetti con attenzione, li raggruppi in cluster per garantire la copertura, applichi MMR per la diversità, bilanci la lunghezza, esegua il lint del formato, verifichi la presenza di scorciatoie e infine convalidi tutto su un set messo da parte prima della pubblicazione.

Questa pipeline trasforma la progettazione degli esempi da intuizione in un processo ingegneristico riproducibile.

Applichi i principi di progettazione degli esempi a una modalità di errore sottile.

Punti chiave:

• Le dimostrazioni sono dati di addestramento al momento dell'inferenza: li curi con il rigore riservato ai dataset.
• Faccia corrispondere la distribuzione degli input a quella di produzione tramite il clustering e copra deliberatamente gli edge case difficili.
• Imponga una rigorosa coerenza della formattazione ed esegua il lint degli output rispetto a uno schema.
• Massimizzi la diversità per token con MMR e bilanci difficoltà e lunghezza.
• Verifichi la presenza di scorciatoie spurie e leakage, includa dimostrazioni negative e di rifiuto e assegni una versione a ogni set di dimostrazioni.