La prima versione di un prompt è una bozza. Spesso ti dà qualcosa di vicino a quello che vuoi, e la distanza tra vicino e giusto si colma iterando: cambiare il prompt di proposito, eseguirlo di nuovo sullo stesso input e controllare se la modifica ha aiutato. Fatto senza cura, iterare diventa riformulare a caso finché un output fortunato sembra andare bene. Fatto come un piccolo esperimento, ti dà un prompt che funziona sui prossimi cento input, non solo su quello che hai provato.
Il metodo ha cinque passaggi: definisci com'è un buon risultato, tieni input di test fissi, cambia una cosa alla volta, confronta gli output e capisci quando fermarti.
Definisci com'è una buona risposta
Prima di modificare qualsiasi cosa, scrivi cosa deve fare l'output, sotto forma di controlli a cui puoi rispondere sì o no. "Un buon messaggio di commit" non si può controllare. Questi sì:
- La riga dell'oggetto è sotto i 50 caratteri.
- Segue il formato Conventional Commits (
fix:,feat:e così via). - Il corpo spiega perché serviva la modifica, non quello che il diff mostra già.
- Cita il numero della issue quando c'è.
I criteri fanno due lavori. Ti dicono cosa aggiungere al prompt, perché ognuno spesso è un'istruzione mancante. E ti impediscono di giudicare gli output da quanto suonano bene, che è il modo più facile di accettare una risposta sicura ma sbagliata.
Tieni un piccolo insieme di input di test
Scegli da tre a dieci input e tienili fissi mentre lavori. Includi casi tipici, un paio di casi scomodi (un campo vuoto, un input molto lungo, una lingua che il prompt non si aspettava) e ogni input che in passato ha fallito. Un prompt messo a punto su un solo esempio tende ad adattarsi a quell'esempio e a fallire sul successivo.
Scrivi il prompt come un template con uno spazio per l'input, così ogni versione gira esattamente sullo stesso materiale.
Cambia una cosa alla volta
Quando cambi insieme ruolo, formato ed esempi e l'output migliora, non sai quale modifica l'ha ottenuto, e potresti tenerti due modifiche inutili. Cambia una cosa, eseguila, confronta. Le schede qui sotto sono tre versioni dello stesso prompt, ognuna con una sola modifica rispetto alla precedente.
- if len(password) > 8:
+ if len(password) >= 8:
return True
Aggiorna la validazione della lunghezza della password
Questo commit aggiorna la logica di validazione delle password cambiando l'operatore di confronto da > a >=. Di conseguenza, le password lunghe esattamente 8 caratteri saranno ora considerate valide. Questa modifica migliora la precisione della validazione e offre un'esperienza migliore agli utenti che creano un account.
La versione 1 non rispetta i criteri 2 e 3: l'oggetto non ha un prefisso di tipo e il corpo racconta di nuovo il diff con più parole. La versione 2 aggiunge i requisiti di formato e rispetta i criteri 1 e 2, ma il suo corpo descrive ancora il diff. La modifica successiva più ovvia sarebbe un'altra istruzione ("spiega perché"), ma il modello non può spiegare un motivo che non gli è mai stato dato. La versione 3 aggiunge invece il contesto mancante, e il corpo e il riferimento alla issue arrivano senza doverli chiedere. È la lezione più comune dell'iterare: quando un'istruzione non sistema un output, al prompt di solito mancano informazioni, non enfasi.
Confronta gli output uno accanto all'altro
Esegui ogni versione su ogni input di test, e ognuna più di una volta, perché i modelli di chat campionano le parole e due esecuzioni dello stesso prompt differiscono. Metti gli output uno accanto all'altro e controllali rispetto ai tuoi criteri, non rispetto al ricordo dell'ultima esecuzione.
Per i criteri precisi, una seconda chiamata al modello può fare una prima passata di valutazione. Incolla gli output in un prompt di valutazione con i criteri scritti per esteso:
| Criterio | Output A | Output B |
|---|---|---|
| 1. Oggetto sotto i 50 caratteri | Promosso: l'oggetto è di 48 caratteri | Promosso: stesso oggetto, 48 caratteri |
| 2. Conventional Commits | Promosso: inizia con "fix:" | Promosso: inizia con "fix:" |
| 3. Il corpo spiega perché | Bocciato: "Cambia il controllo della lunghezza da > a >=" ripete il diff | Promosso: "chi seguiva le istruzioni non riusciva a registrarsi" |
| 4. Cita la issue | Bocciato: nessun numero di issue | Promosso: "Fixes #412" |
Tratta un modello valutatore come un assistente, non come un arbitro. Zheng et al. 2023, "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena", hanno documentato bias nei modelli usati come giudici, tra cui la preferenza per le risposte più lunghe e per la risposta in una certa posizione. Mantieni i criteri verificabili, chiedi prove citate, inverti l'ordine di A e B quando ne confronti due e leggi di persona un campione degli output. Controlli come il conteggio dei caratteri sono più affidabili come riga di codice che come giudizio di un modello.
Correggi il prompt, non la conversazione
In una chat viene la tentazione di correggere la risposta con messaggi successivi: "più breve", "no, cita la issue", "usa l'altro formato". Così ottieni un buon output e lasci il prompt scadente com'era. Quando una correzione funziona, spostala nel prompt ed esegui il prompt da zero. La prossima volta che ti serve il risultato, incolli un messaggio invece di ripeterne cinque.
Conserva le vecchie versioni con una nota di una riga su cosa è cambiato e cosa ha sistemato. Basta un file di testo. Quando una modifica successiva peggiora le cose, puoi tornare indietro invece di cercare di ricordare cosa diceva prima il prompt.
Fare un confronto nel codice
Quando un prompt gira tramite un'API, un breve script può produrre la vista affiancata per ogni versione e ogni input di test. Questo usa l'SDK Python di OpenAI e scrive un file markdown che puoi leggere dall'inizio alla fine.
from openai import OpenAI
client = OpenAI()
MODEL = "your-model-id" # e.g. from your provider's model list
# each prompt file contains {input} where the test diff goes
PROMPTS = {
"v2": open("prompts/commit_v2.txt").read(),
"v3": open("prompts/commit_v3.txt").read(),
}
TESTS = [open(f"tests/diff_{i}.txt").read() for i in range(1, 6)]
with open("results.md", "w") as out:
for i, test in enumerate(TESTS, 1):
out.write(f"## Test {i}\n\n")
for name, template in PROMPTS.items():
for run in (1, 2):
response = client.chat.completions.create(
model=MODEL,
messages=[{"role": "user", "content": template.replace("{input}", test)}],
)
out.write(f"### {name}, run {run}\n\n{response.choices[0].message.content}\n\n")
Quando fermarsi
Fermati quando ogni criterio è rispettato su ogni input di test per un paio di esecuzioni. Aggiungere altro dopo quel punto aggiunge soprattutto lunghezza, e ogni istruzione in più è un'altra cosa che può entrare in conflitto con le altre.
Fermati anche quando le modifiche iniziano a scambiarsi i fallimenti: una modifica sistema il test 2 e rompe il 4, la successiva fa il contrario. Questo schema significa che al prompt si chiede qualcosa che una singola istruzione non riesce a fissare. Le vie d'uscita abituali sono mostrare il formato con un paio di esempi (few-shot prompting), dividere il lavoro in passaggi con il prompt chaining o spostare le parti deterministiche, come contare i caratteri o controllare un formato, in un codice che verifichi l'output. Se sei a corto di idee, il meta prompting può aiutare: dai a un modello il prompt, l'input e l'output scadente, e chiedigli quale parte del prompt l'ha causato con più probabilità.
Domande frequenti
Come miglioro un prompt che dà risposte scadenti?
Guarda la risposta scadente e dai un nome a cosa non va: formato sbagliato, fatto mancante, pubblico sbagliato, troppo lunga. Poi trova cosa il prompt non ha detto e che l'avrebbe evitato, aggiungi quella sola cosa ed esegui la nuova versione sullo stesso input. Le risposte scadenti nascono più spesso da contesto mancante o da un'istruzione di formato mancante che dalla formulazione.
Quanti input di test mi servono per testare un prompt?
Per un prompt che riuserai, da tre a dieci di solito bastano: qualche caso tipico, uno o due casi limite (molto brevi, molto lunghi, insoliti) e un input che in passato è andato male. Tienili fissi mentre iteri, così un cambiamento nell'output dipende dal prompt e non da un input diverso.
Perché ottengo una risposta diversa quando eseguo di nuovo lo stesso prompt?
I modelli di chat campionano ogni parola da una distribuzione di probabilità, quindi gli output variano tra un'esecuzione e l'altra. Quando confronti due versioni di un prompt, esegui ciascuna più di una volta sugli stessi input. Una differenza che compare in ogni esecuzione probabilmente è reale; una che compare in una sola può essere un caso. Tramite un'API puoi anche abbassare la temperatura per ridurre la variazione.
Posso usare l'IA per valutare gli output del mio prompt?
Sì, per criteri che puoi enunciare con precisione, come "il corpo spiega perché serviva la modifica" o "cita il numero della issue". Dai al valutatore i tuoi criteri esatti e chiedi promosso o bocciato per ogni criterio, con una citazione come prova. I modelli valutatori hanno bias noti, tra cui preferire le risposte più lunghe e preferire una posizione rispetto all'altra, quindi leggi di persona qualche output e inverti l'ordine quando ne confronti due.
Quando devo smettere di migliorare un prompt?
Fermati quando ogni criterio è rispettato su ogni input di test per un paio di esecuzioni, oppure quando ogni nuova modifica sistema un caso e ne rompe un altro. A quel punto il problema di solito non è il prompt: il compito potrebbe aver bisogno di esempi, di essere diviso in passaggi o di un controllo nel codice.
