Iterazione e debugging dei prompt

Un prompt engineering efficace non consiste nel trovare una formula magica: è un processo empirico e iterativo, più simile al debugging che alla scrittura. Si scrive un prompt, lo si esegue con input di test, si osservano i casi in cui fallisce, si formula un'ipotesi sul motivo del fallimento e si modifica il prompt per risolverlo. La sola intuizione non è affidabile: servono dati.

Molti sviluppatori commettono l'errore di testare il prompt su uno o due esempi preparati a mano, osservare buoni risultati e distribuirlo in produzione, per poi scoprire che il prompt fallisce nel 30% degli input reali. Un flusso di valutazione sistematico evita questo problema sottoponendo il prompt a esempi diversificati e rappresentativi prima della messa in produzione.

Prima di scrivere il prompt, crei un golden test set: una raccolta di 20-100 esempi rappresentativi di input abbinati all'output previsto o ai criteri di superamento. Questo set di test diventa il riferimento per valutare qualsiasi modifica al prompt.

Un buon set di test include: input tipici, casi limite (stringhe vuote, input molto lunghi, casi ambigui), input avversari progettati per mettere in difficoltà il prompt e input provenienti da diversi segmenti della popolazione di utenti. Più il set di test è diversificato, maggiore è la certezza che una modifica al prompt rappresenti un reale miglioramento anziché un overfitting sui pochi esempi inizialmente considerati.

Scrivere un semplice script di valutazione richiede un'ora e fa risparmiare giorni di debugging dei problemi in produzione. Lo script esegue il prompt su ogni caso di test, confronta l'output con il risultato previsto e comunica la percentuale di superamento. È quindi possibile iterare sul prompt e verificare immediatamente se le modifiche hanno migliorato il punteggio complessivo.

Quando il prompt fallisce nei casi di test, raggruppi gli errori per tipo per individuare gli schemi ricorrenti. Tra le modalità di errore più comuni ci sono:

• Errori di formato: il modello produce la risposta corretta, ma nel formato sbagliato
• Errori di ambiguità: il modello interpreta l'attività in modo diverso da quello previsto
• Errori nei casi limite: il modello funziona con gli input tipici, ma fallisce con quelli insoliti
• Errori di allucinazione: il modello produce con sicurezza contenuti fattuali errati
• Ignorare le istruzioni: il modello segue parzialmente le istruzioni, ma non rispetta vincoli specifici

Ogni tipo di errore richiede una correzione diversa. Gli errori di formato richiedono istruzioni di output più esplicite; gli errori di ambiguità richiedono una definizione più chiara dell'attività o esempi.

OpenAI Playground (platform.openai.com/playground) è lo strumento più rapido per iterare sui prompt senza scrivere codice. Consente di passare da un modello all'altro, regolare i parametri con i cursori, salvare le versioni dei prompt e confrontare gli output affiancati.

Utilizzi Playground nella fase di esplorazione dello sviluppo dei prompt: provi formulazioni diverse, testi interattivamente i casi limite e sviluppi un'intuizione su ciò che funziona. Quando avrà trovato un prompt promettente, passi al codice con un harness di valutazione per convalidarlo sistematicamente sull'intero set di test prima della messa in produzione.

I prompt sono codice. Devono essere gestiti con il controllo versione, revisionati e distribuiti con lo stesso rigore del codice dell'applicazione. L'approccio più semplice consiste nel salvare i template dei prompt come stringhe in un file di costanti del repository, così che le modifiche siano tracciate in git e richiedano una revisione del codice.

Gli approcci più avanzati includono il salvataggio dei prompt in un database dedicato alla gestione dei prompt (LangSmith, PromptLayer o una semplice tabella Supabase), l'assegnazione di tag alle versioni e l'esecuzione di test A/B tra versioni dei prompt in produzione. Questo è particolarmente importante quando più membri del team lavorano sugli stessi prompt o quando è necessario ripristinare una modifica che ha peggiorato la qualità in produzione.

Quando ha due versioni concorrenti di un prompt, le esegua entrambe sull’intero set di test e confronti i punteggi. Anche un miglioramento del 5% nell’accuratezza di un sistema in produzione che gestisce migliaia di richieste al giorno giustifica lo sforzo della valutazione. Non scelga mai un prompt basandosi su uno o due esempi verificati manualmente: esegua sempre il confronto sull’intero set di test.

Per le metriche di qualità soggettive, in cui non esiste un’unica risposta corretta, come tono, utilità o creatività, può usare LLM-as-judge: chieda a un modello potente, come GPT-4o, di valutare quale delle due risposte soddisfa meglio i criteri di qualità. In questo modo la valutazione può andare oltre ciò che è possibile gestire con la revisione umana.

Per impostazione predefinita, gli output degli LLM non sono deterministici. Impostare temperature=0 rende gli output quasi deterministici (selezionando il token più probabile a ogni passaggio), una caratteristica essenziale per il debug perché consente di eseguire due volte lo stesso prompt e ottenere lo stesso output. Durante il debug, imposti sempre temperature su 0, così potrà determinare se una modifica al prompt ha causato il cambiamento dell’output o se si tratta semplicemente di una variazione casuale.

Dopo aver corretto il prompt, riattivi un certo livello di temperature in produzione se il caso d’uso beneficia della varietà, ad esempio nella scrittura creativa o nel brainstorming. Mantenga invece temperature a 0 per le attività di estrazione strutturata e classificazione, in cui desidera output coerenti e ripetibili.

Se il prompt produce fatti allucinati, aggiunga vincoli che rendano più difficile l’allucinazione. Tra le tecniche efficaci per contrastare le allucinazioni vi sono:

• Citare le fonti: «Risponda esclusivamente sulla base del contesto fornito. Se la risposta non è presente nel contesto, dica “Non lo so”.»
• Quantificare il livello di certezza: «Valuti la propria sicurezza su una scala da 1 a 5. Se è inferiore a 3, non risponda.»
• Passaggio di verifica: «Prima di rispondere, verifichi che ogni fatto che intende utilizzare sia presente nel documento fornito.»

Nessuna tecnica elimina completamente le allucinazioni, ma combinare il retrieval (RAG) con vincoli rigorosi nel prompt le riduce drasticamente nelle applicazioni ad alta intensità di conoscenza.

La ricerca ha dimostrato che gli LLM prestano maggiore attenzione alle istruzioni all’inizio e alla fine di un prompt rispetto a quelle collocate al centro. Questo fenomeno è chiamato problema del lost in the middle. Se ha un prompt lungo con istruzioni importanti sepolte nel mezzo e circondate dal contesto, il modello potrebbe non seguirle in modo affidabile.

Buona pratica: inserisca le istruzioni più importanti, come la definizione dell’attività e i vincoli critici, proprio all’inizio del system prompt e ribadisca i vincoli fondamentali alla fine. Per i documenti lunghi inseriti come contesto, collochi la domanda dell’utente dopo il documento anziché prima, poiché il modello attribuisce maggiore peso ai contenuti più recenti.

Il ciclo di sviluppo di un prompt comprende tre fasi:

• Sperimentazione: utilizzi il Playground per fare liberamente degli esperimenti. Si concentri sulla comprensione di ciò che funziona a livello concettuale, non sull’ottenimento di un output perfetto.
• Valutazione: crei un set di test e un harness di valutazione. Esegua i prompt candidati sull’intero set di test e misuri i tassi di superamento. Iteri finché non raggiunge la soglia di qualità.
• Produzione: sottoponga il prompt finale al controllo versione, aggiunga il monitoraggio per seguire le metriche di qualità in produzione e configuri avvisi per il peggioramento della qualità. Preveda iterazioni future quando cambiano le versioni del modello.

Saltare la fase di valutazione è la causa più comune delle regressioni nella qualità dei prompt in produzione. Il tempo investito in un set di test adeguato si ripaga ampiamente.

In questa lezione ha imparato che: il prompt engineering richiede un set di test di riferimento e un harness di valutazione per misurare i miglioramenti in modo affidabile, le modalità di errore devono essere categorizzate per individuare la correzione appropriata per ciascun tipo e temperature 0 è essenziale per il debug, mentre il versionamento dei prompt e il monitoraggio in produzione completano il ciclo della qualità. Ora vedremo come gli LLM elaborano il testo tramite i token e perché il numero di token è importante per i costi e il contesto.