Prompt Engineering misurato: cosa cambia l’output

Prima delle misurazioni, un fatto che spiega in silenzio metà di ciò che segue.

Il modello non ha memoria. Tra due chiamate non conserva nulla: non la tua ultima domanda, non la sua ultima risposta, non il file che hai allegato, non il fatto che glielo hai già chiesto due volte. Ogni chiamata parte da una macchina vuota, e l’unica cosa che quella macchina conosce è la sequenza di token che le hai appena consegnato.

Ciò che sembra memoria in un’interfaccia chat è il tuo client che reinvia tutta la conversazione, ogni turno, dall’inizio. Il modello rilegge tutto da zero, ogni volta. Il Capitolo 13 ha misurato quanto costa quella rilettura in un forward pass; il Capitolo 16 la trasforma in una riga su una fattura. Qui conta la conseguenza per il design: il prompt non è un messaggio a un sistema che ha uno stato. È lo stato.

Questo manda in pensione una famiglia di confusioni. «Il modello ha dimenticato quello che gli avevo detto» di solito significa che non gli è mai stato inviato. «Ha ignorato la mia istruzione precedente» di solito significa che l’istruzione è uscita dalla window quando la cronologia è stata troncata. «In produzione si è comportato diversamente» di solito significa che la produzione assembla un prompt diverso da quello che hai testato. Nessuno di questi è un problema del modello, e nessuno si risolve riscrivendo qualcosa.

Dire «questo prompt è migliore» è un’affermazione su una distribuzione, e non puoi vedere una distribuzione guardando un solo output. Quello che ti serve è noioso: casi con risposte note, N varianti e un intervallo.

L’harness è cinquanta righe di TypeScript con la stessa forma del client del Capitolo 14: una richiesta, una deadline, un po’ di concorrenza, un conteggio. Ricompare nel Capitolo 19 per valutare un retriever e nel Capitolo 29 come golden set.

export type Case = { input: string; expected: string };
export type Variant = { name: string; build: (c: Case) => ChatMessage[] };

async function pooled<T, R>(xs: T[], n: number, f: (x: T) => Promise<R>) {
  const out: R[] = new Array(xs.length);
  let i = 0;
  await Promise.all(
    Array.from({ length: n }, async () => {
      while (i < xs.length) {
        const k = i++;
        out[k] = await f(xs[k]);
      }
    }),
  );
  return out;
}

export async function runVariant(v: Variant, cases: Case[], concurrency = 6) {
  const hits = await pooled(cases, concurrency, async (c) => {
    const answer = await complete(v.build(c));      
    return answer.trim().toLowerCase() === c.expected;
  });
  return { name: v.name, hits, k: hits.filter(Boolean).length, n: cases.length };
}

Il numero che torna non è il risultato. Questo lo è:

/** 95 % Wilson score interval for a proportion. Chapter 4 derives it. */
export function wilson(k: number, n: number, z = 1.96) {
  const p = k / n;
  const d = 1 + (z * z) / n;
  const centre = (p + (z * z) / (2 * n)) / d;
  const half = (z * Math.sqrt((p * (1 - p)) / n + (z * z) / (4 * n * n))) / d;
  return [Math.max(0, centre - half), Math.min(1, centre + half)] as const;
}

Il Capitolo 4 ha formulato l’argomento e questo capitolo lo incassa. Diciassette risposte giuste su venti sono l’85 %, e il suo intervallo al 95 % va dal 64 % al 95 %. Una variante che fa 13 su 20 — 65 %, che sembra chiaramente peggiore — ha un intervallo dal 43 % all’82 %. Quei due intervalli si sovrappongono per quasi tutta la loro lunghezza. Venti casi non possono distinguere un buon prompt da uno mediocre, e la maggior parte dei consigli pubblicati sui prompt è stata validata su meno casi.

Sessanta casi, che è ciò che usa questo capitolo, non sono ancora molti. Sono abbastanza per vedere effetti grandi e abbastanza onesti da ammettere quando non possono vedere quelli piccoli — e lo ammetteranno più volte qui sotto.

Tre blocchi — le regole R, il ticket T, l’istruzione I — concatenati in un unico messaggio user. Tutte e sei le permutazioni, contenuto byte-identico, sessanta casi ciascuna.

Dal migliore al peggiore ci sono 28,3 punti, e gli intervalli non si sovrappongono, quindi questa non è una storia sul rumore. Poiché ogni braccio viene valutato sugli stessi sessanta item, la domanda più precisa è quella appaiata: tra i casi in cui due bracci non concordano, quanto è sbilanciata la divisione? Passare dall’ordine peggiore al migliore ha trasformato 21 casi in giusti e 4 in sbagliati: probabilità appaiata esatta 0,0009.³

Leggi la tabella per la sua forma più che per il vincitore. Le due righe migliori finiscono entrambe con il ticket; le due peggiori seppelliscono entrambe l’istruzione in mezzo oppure la trascinano dopo i dati. È lo stesso fenomeno che Liu et al. hanno chiamato Lost in the Middle: il materiale ai bordi di un prompt viene usato in modo più affidabile del materiale al centro.⁴ Il Capitolo 16 prezza la window e il Capitolo 24 misura correttamente l’effetto su lunghezze maggiori, dove il centro collassa come descritto e il recupero proprio alla fine non ricompare. Qui la regola pratica emerge da sola: task in alto, dati in basso, nulla di importante in mezzo.

Ora sposta le stesse parole tra i turni. Il Capitolo 11 ha stabilito che il chat template non è una decorazione intorno al modello ma parte del modello: <|im_start|>system e <|im_start|>user sono token reali che il modello ha visto milioni di volte durante il fine-tuning, esattamente in quelle posizioni. Quindi dovrebbe contare da quale lato di quei marker finisce la tua istruzione, e infatti conta:

Spostare le regole e l’istruzione oltre il confine del template ha comprato 21,7 punti — 19 casi guadagnati, 6 persi, probabilità appaiata 0,0146 — senza cambiare un loro carattere. Questa è la risposta concreta a system prompt versus user prompt: non sono due modi di dire la stessa cosa. Sono due posizioni di token diverse in una struttura su cui il modello è stato addestrato, e la posizione system è dove appartengono le istruzioni che si applicano a tutta la conversazione.

Nota anche la terza riga. Ripetere l’istruzione dopo il ticket — un trucco ampiamente consigliato — ha ottenuto un punteggio inferiore rispetto a dichiararla una volta sola. Su questo modello, su questo task, dirlo due volte è stato peggio che dirlo una.

Stesso prompt, miglior posizionamento, sessanta casi. L’unica cosa che cambia è ciò che circonda il testo del ticket.

Diciotto punti di spread dalla punteggiatura. Ma guarda i due intervalli estremi: [73,9, 91,9] e [54,1, 77,3]. Si sovrappongono. Secondo la lettura grossolana — confronta le barre d’errore, e se si toccano non dire nulla — questa tabella non prova proprio niente.

La lettura grossolana qui è sbagliata, e capire perché vale più della tabella. Ogni variante è stata valutata sugli stessi sessanta ticket, quindi le due misurazioni non sono campioni indipendenti; sono appaiate. Gran parte della larghezza di ogni intervallo viene da una fonte di incertezza condivisa da entrambi i bracci: se questi sessanta ticket siano rappresentativi. E quella fonte si cancella quando li confronti tra loro. Fai invece la domanda appaiata e la risposta è netta: passare dalle virgolette doppie al tag XML ha trasformato 12 casi in giusti e 1 in sbagliato, probabilità appaiata 0,0034. Questa è una differenza reale.

E poi lo stesso test sgonfia il titolo. Il tag XML ha battuto l’etichetta semplice Ticket: di 8,3 punti, che è il numero che un post di blog metterebbe nel titolo. Appaiato: 6 guadagnati, 1 perso, probabilità 0,1250. Non stabilito. Sette casi sono ciò su cui poggia quel famoso miglioramento.

Quindi ci sono due domande con due strumenti diversi, e confonderle è il modo in cui i consigli sui prompt sbagliano in entrambe le direzioni allo stesso tempo:

Il risultato generale — che i modelli sono fortemente e imprevedibilmente sensibili a scelte di formattazione prive di contenuto semantico — non è nuovo. Sclar et al. hanno variato soltanto separatori, spaziatura e maiuscole/minuscole su decine di task e hanno trovato spread di accuratezza abbastanza ampi da invertire ranking di modelli pubblicati.⁵ La conseguenza pratica non è «usa tag XML». È che la formattazione è un hyperparameter, non costa nulla da esplorare, e qualsiasi confronto tra due modelli che fissa un formato sta confrontando i formati tanto quanto i modelli.

L’in-context learning — mostrare al modello esempi risolti nel prompt e farlo generalizzare da quelli senza alcun aggiornamento dei pesi — è la capacità che ha reso famoso GPT-3.⁶ La domanda pratica non è mai se funzioni. È quanti esempi valga la pena pagare.

Gli esempi entrano come veri turni precedenti, alternando user e assistant, perché questa è la struttura su cui il template è stato addestrato. Ogni k è stato eseguito con cinque diverse estrazioni casuali da un pool disgiunto di sedici ticket etichettati:

Due esempi hanno comprato sette punti. I successivi sei esempi non hanno comprato nulla di misurabile: 83,7, poi 81,7, poi 83,7, una sequenza che vaga dentro il proprio rumore. Sedici ne hanno comprati altri cinque e mezzo. La curva non è una salita liscia; è uno scalino, un plateau e uno scalino.

La colonna che conta di più è l’ultima. A k = 8, quali otto esempi ti è capitato di scegliere hanno spostato l’accuratezza di 10 punti: più dell’intero guadagno dal passare da due esempi a otto. E l’ultima riga è la versione più netta: a k = 16 il pool è esaurito, quindi tutte e cinque le run contengono esattamente gli stessi sedici esempi, differendo solo nell’ordine in cui appaiono. Solo l’ordine ha spostato l’accuratezza di 8,3 punti.

Questo è il risultato riportato da Lu et al. e sopravvive ovunque sia stato cercato: l’ordinamento degli esempi è un vero hyperparameter con effetti paragonabili al numero di esempi.⁷ Quindi il consiglio onesto sul few-shot prompting non è un numero. È:

Ora il folklore. Ognuna di queste è una singola frase anteposta a un system prompt altrimenti identico, sugli stessi sessanta casi.

Quattro delle cinque non hanno fatto nulla. Non «hanno fatto poco»; nulla che sessanta casi appaiati possano vedere. La persona esperta e la tangente hanno entrambe ottenuto un punteggio inferiore rispetto alla baseline intatta, e anche quei cali falliscono il test appaiato: sono rumore che punta verso il basso.

La terza riga è quella su cui soffermarsi. «Questo è molto importante per la mia carriera» ha prodotto esattamente la stessa accuratezza, 46 su 60, e dieci delle sessanta risposte sono cambiate, cinque in ciascuna direzione. La statistica riassuntiva era identica e il comportamento no. Se la tua valutazione è un singolo numero su un set piccolo, un cambiamento che riscrive un sesto dei tuoi output può sembrare un cambiamento che non ha fatto nulla, e lo manderai in produzione credendo che fosse gratis.

E poi la minaccia, che è l’unica frase ad aver spostato l’ago e ad averlo spostato 35 punti verso il basso, trasformando 24 casi da giusti a sbagliati. Non è un artefatto di arrotondamento; è un comportamento del modello diverso. La lezione non è «non minacciare mai un modello». È che il framing emotivo non è inerte. Sposta la distribuzione, a volte con forza, in una direzione che nessuno può prevedere leggendo la frase: ed è proprio per questo che va misurato invece che ragionato.

Una cautela che questo capitolo ti deve: queste cinque frasi sono state testate su un modello piccolo e un task. Alcune hanno supporto pubblicato altrove: «fai un respiro profondo» viene da un paper che ha cercato istruzioni ad alto punteggio invece di inventarle, che è un’affermazione diversa e migliore da quella circolata dopo.⁸ Ciò che si generalizza non sono le frasi. È che la lista sopravvissuta nei post di blog e la lista che sopravvive alla misurazione sono due liste diverse, e l’unico modo per sapere quale hai in mano è eseguire il bench.

Una regola che tutti ripetono — di’ ciò che vuoi, non ciò che non vuoi — con la solita assenza di un numero. Ecco il numero. Lo stesso requisito di formato, scritto in tre modi, con il modello che genera liberamente così da poter osservare la conformità:

Tre divieti hanno fatto peggio di una istruzione, e hanno fatto scrivere al modello cinque volte più testo: l’esatto opposto di tutti e tre contemporaneamente. Aggiungere di nuovo la frase positiva lo ha salvato portandolo al 68 %.

Il meccanismo non è misterioso quando ricordi il Capitolo 8. Il modello sceglie un next token da una distribuzione condizionata da tutto ciò che lo precede, e un divieto mette la cosa proibita dentro quel condizionamento. Non c’è un operatore per la negazione; c’è un contesto in cui ora compare una parola.

Il che è misurabile direttamente. Prendi il prompt baseline e aggiungi una riga: Do not use the shipping queue for software problems. Poi guarda soltanto i quarantacinque ticket che non sono ticket di spedizione:

Nominare una coda per escluderla ha fatto sì che il modello la scegliesse tre volte più spesso, ha quasi triplicato la massa di probabilità che le assegnava e ha costato 25 punti di accuratezza complessiva: 16 casi persi contro 1 guadagnato, probabilità appaiata 0,0003.

Non pensare a un elefante, misurato. La riscrittura è sempre la stessa: sostituisci il divieto con la regola positiva che lo rende inutile. Non «non usare shipping per problemi software», ma «usa shipping solo quando è coinvolto un pacco fisico».

Il Capitolo 12 ha costruito correttamente la chain of thought: prima come tecnica di prompting,⁹¹⁰ poi come qualcosa addestrato con ricompense verificabili, e si è chiuso con un avvertimento rimandato a questo capitolo: dire a un modello di pensare passo per passo smette di aiutare quando il modello ragiona da solo, e può fare danni. Ecco quell’avvertimento con una tabella sotto, su un task in cui è facile supporre che pensare di più debba essere meglio.

Entrambi i bracci vengono letti con lo stesso strumento nella stessa posizione. L’unica differenza è se una chain of thought scritta dal modello stesso si trovi prima nel contesto.

L’accuratezza è scesa e il costo è salito, e la regola di questo capitolo si applica al risultato di questo stesso capitolo: il calo è 7 casi guadagnati contro 10 persi, probabilità appaiata 0,629, quindi non è stabilito. Ciò che è stabilito è che ha prodotto novantotto token di output extra per chiamata e non ha comprato nulla di misurabile. L’incertezza è interamente sul lato del beneficio. Il conto è certo.

Una chain che fallisce è più istruttiva di una che funziona. Invitato a ragionare su «La tua integrazione Slack ha smesso di pubblicare messaggi dopo martedì», il modello ha scritto:

1. Check if the issue persists on Monday.
2. Verify if there are any updates or changes in your Slack setup that
   might affect message posting.
3. If no update has been made since Tuesday, check for any recent system
   restarts or downtime affecting Slack functionality.
4. If you have recently installed new software or updated your
   environment, ensure it's compatible with Slack version.
5. Contact Slack support for further assistance or troubleshooting steps.

È un consiglio di troubleshooting competente e non è il task. Quando gli è stato chiesto di pensare, il modello è scivolato nel genere a cui «pensa passo per passo a questo ticket di supporto» assomiglia di più nei suoi dati di training, e poi ha risposto a una domanda di classificazione con cinquecento caratteri di ragionamento non correlato nel proprio contesto. La chain of thought aiuta su problemi con stato intermedio che vale la pena calcolare: aritmetica, lookup multi-hop, soddisfazione di vincoli. Instradare una frase in uno di quattro bucket non ha stato intermedio. Non c’è nulla che la chain debba tenere, quindi tutto ciò che fa è aggiungere testo plausibile a cui la decisione finale deve poi sopravvivere.

Due corollari pratici. Primo, per un modello addestrato a ragionare — i modelli RLVR del Capitolo 12 — l’istruzione è peggio che ridondante: può sostituire la lunga chain che il modello avrebbe prodotto con una breve, a forma di prompt. E campionare più chain e votare, che è ciò che fa la self-consistency,¹¹ non può salvare un task in cui non c’è nulla su cui discordare: moltiplica il costo per il numero di campioni per risolvere pareggi che non esistono. Il Capitolo 12 ha misurato quel trade-off dove si applica. Secondo, nota quanto è costato lo scaffold di confronto. Forzare la risposta in una riga Final queue: ha fatto scendere il braccio senza ragionamento dal 76,7 % al 61,7 %. Quindici punti, pagati per rendere comparabili i due bracci. Anche la struttura che esiste per tua comodità non è gratis.

Un’ultima misurazione, perché è la domanda che tutti fanno dopo il primo risultato sorprendente. Sessanta prompt, decodifica greedy, eseguiti ripetutamente:

• La stessa chiamata ripetuta con tutto mantenuto fisso ha restituito probabilità bit-identiche. Deterministica.
• La stessa chiamata messa in batch con vicini diversi — batch size 1, 4, 12, 30 e 60 — ha restituito probabilità diverse fino a 0,0128. L’etichetta scelta non è mai cambiata, in 0 casi su 60.

L’etichetta è sopravvissuta perché aveva margine: sui sessanta casi, il gap più stretto tra le prime due code era 0,0459, tre volte e mezzo il drift. La stabilità non era una proprietà dell’algoritmo. Era un margine, e i margini finiscono. Il Capitolo 17 è dove si trova la ragione aritmetica e dove vengono smontate le manopole di sampling che allargano e restringono quei gap. Il motivo per piantarlo qui è che limita ciò che qualsiasi misurazione di prompt può significare: il bench misura un sistema riproducibile solo fino a una tolleranza, e una differenza di due punti tra varianti è dentro quella tolleranza in una giornata storta.

Tutto ciò che c’è sopra è un umano che sceglie una variante e una macchina che la valuta. Il passo successivo ovvio è lasciare che la macchina scelga anche le varianti.

APE fa esattamente questo: un modello propone istruzioni candidate, vengono valutate su esempi held-out, e le migliori sopravvivono.⁸ Le istruzioni che trova sono spesso cose che nessun umano scriverebbe, ed è proprio questo il punto: la ricerca è su ciò che fa punteggio, non su ciò che suona professionale.

DSPy va oltre ed è l’idea più utile per un prodotto.¹² Dichiari cosa prende e cosa restituisce ogni passaggio di una pipeline, e il framework lo compila in prompt, selezionando dimostrazioni e ottimizzando istruzioni contro la tua metrica. Cambi modello e ricompili invece di riscrivere. Il prompt smette di essere codice sorgente ritoccato a mano da qualcuno e diventa un artefatto generato contro una metrica, che è ciò che avrebbe dovuto essere fin dall’inizio.

Nessuno dei due elimina la necessità del bench. Entrambi lo rendono l’unica cosa di cui hai bisogno, perché un ottimizzatore senza metrica non ottimizza nulla.

Resta la disciplina. I prompt devono stare nel controllo versione, in file, accanto al codice che li invia: non in una riga di database che qualcuno ha modificato un martedì. Hanno bisogno di un identificatore di versione salvato accanto a ogni output che hanno prodotto, oppure il giorno in cui qualcosa regredisce non puoi scoprire che cosa sia cambiato. Hanno bisogno del bench in continuous integration, perché un prompt è l’unica parte del tuo sistema che un vendor può invalidare in silenzio distribuendo un nuovo modello. E hanno bisogno di casi: non cento casi ingegnosi, solo i venti noiosi che si sono rotti lo scorso trimestre, conservati per sempre. Il bench è il deliverable. Il prompt è un suo sottoprodotto.

Tutto in questo capitolo è stato misurato in accuratezza. Ognuna di quelle varianti ha anche un prezzo.

Il system prompt che ha comprato 21,7 punti viene inviato a ogni chiamata, per sempre. I due esempi che hanno comprato sette punti vengono inviati a ogni chiamata, per sempre. I sedici che ne hanno comprati dodici vengono inviati a ogni chiamata, per sempre, e sono circa dieci volte la lunghezza della domanda che l’utente ha effettivamente posto. La chain of thought che non ha comprato nulla ha prodotto novantotto token extra per richiesta, e i token di output sono quelli costosi.

Nulla di questo è visibile in una tabella di accuratezze, e tutto è visibile su una fattura.

Il Capitolo 16 riguarda l’unità in cui quelle decisioni sono davvero denominate. Il token come unità di fatturazione, la context window come budget invece che memoria, perché una conversazione di quaranta turni costa molto più di quaranta volte il primo turno, cosa paga e cosa non paga il prompt caching, e perché l’ordine del tuo prompt decide se la cache hit avviene o no: il che si rivela essere un secondo motivo, interamente economico, per mettere prima il materiale stabile e per ultimo quello variabile.

Il bench e ogni tabella sono stati prodotti con Qwen/Qwen2.5-0.5B-Instruct sotto decodifica greedy, quindi si riproducono esattamente. La documentazione Hugging Face sui chat template è il riferimento per ciò in cui si espandono realmente i marker del template del Capitolo 11, e per il fatto che un modello distribuito con il template sbagliato è un fallimento reale e ricorrente. Per gli effetti di posizione e formato su scala di produzione invece che di laboratorio, le citazioni sopra sono le fonti primarie; le guide di prompting dei vendor sono utili per i loro esempi e vanno lette sapendo che nessuna pubblica un intervallo.