La maggior parte dei prompt fallisce perché lascia l’IA a indovinare.
Non perché siano troppo corti. Perché non sono chiari su quello che vuoi davvero. E quando un’IA deve indovinare, finisce per produrre risultati generici.
Come l’ha messa un commentatore su Hacker News: “prompt engineering is probably very close to good management and communication principles.” Questa cornice è utile. Non stai programmando. Stai comunicando con qualcosa che non ha alcuna capacità di fare domande di chiarimento.
Quindi: com’è fatto un prompt completo? Sotto quelli buoni c’è una struttura.
I mattoni fondamentali
La documentazione di Learn Prompting identifica cinque componenti che ricorrono nei prompt efficaci. La Prompt Engineering Guide usa termini leggermente diversi, ma arriva a categorie simili: istruzione, contesto, dati di input e indicatore di output.
La maggior parte dei prompt buoni ne usa tre o quattro. Le domande semplici ne richiedono uno.
La direttiva (istruzione)
È il compito. Che cosa vuoi, esattamente?
“Scrivi un’email di follow-up a un potenziale cliente che non ha risposto da due settimane.”
Questa è una direttiva. Chiara e specifica. Confrontala con: “Aiutami con questa email.” La seconda versione costringe l’IA a indovinare la tua intenzione, il tuo pubblico, il tuo obiettivo.
Direttive vaghe producono risultati vaghi. Qui non c’è magia.
Contesto (informazioni di base)
Tutto ciò che serve all’IA per capire la tua situazione.
Senza contesto, ottieni supposizioni generiche. Con il contesto, ottieni risposte su misura. La differenza può essere enorme.
Mettiamo che ti serva una scaletta per una presentazione. “Crea una scaletta di presentazione sull’IA” non dà al modello niente con cui lavorare. Chi è il pubblico? Quale taglio? Quanto deve essere tecnico?
Ora aggiungi contesto: “Presentiamo alla dirigenza la prossima settimana. Hanno approvato il nostro progetto pilota sull’IA lo scorso trimestre e vogliono un aggiornamento sui progressi a 6 mesi. A loro interessa il ROI e la tempistica, non i dettagli tecnici.”
All’improvviso l’IA sa che deve enfatizzare risultati aziendali, evitare gergo e strutturare il tutto per dirigenti. Il contesto risponde alle domande che il modello farebbe se potesse.
Un utente di Hacker News ha proposto una struttura che cattura bene l’idea: “[Context] + [Supplemental Information] + [Intent / Use of result] + [Format you would like the result in]“
Il ruolo (persona)
Qui c’è dibattito. Alcuni ci giurano. Altri pensano che non serva a nulla.
L’idea: assegnare un ruolo dice all’IA quale prospettiva ed esperienza portare. “Agisci come un CFO che spiega i numeri del Q4 al consiglio” modella le risposte in modo diverso rispetto a fare la stessa domanda “a freddo”.
Una raccolta di ricerche di K2View suggerisce che il prompting basato sul ruolo consiste nel “explicitly assign[ing] the LLM a role, profession, or perspective to shape how it reasons and responds.” La loro raccomandazione: scegliere ruoli realistici, pertinenti al compito e tenere le definizioni concise.
Ma ecco la parte onesta: non sempre conta. Per i compiti lineari, spesso il ruolo non aggiunge nulla di misurabile. Per quelli in cui competenza e prospettiva cambiano davvero l’output, sembra aiutare. Le prove sono abbastanza miste che un consiglio assoluto in un senso o nell’altro è prematuro.
Formato della risposta
Come deve apparire la risposta? Punti elenco, lista numerata, tabella, paragrafo, JSON?
La guida di IBM sul prompt engineering sottolinea che input e output strutturati aumentano l’affidabilità. Quando specifichi il formato, riduci l’ambiguità su cosa significhi “finito”.
“Dammi 10 idee per temi di blog come lista numerata. Per ciascuna, includi il tema e una descrizione in una frase dell’approccio.”
Questo evita il paragrafo infinito quando volevi punti elenco. Le specifiche di formato tagliano un sacco di ping-pong.
Da sapere: le istruzioni sul formato non sempre vengono rispettate. Un commentatore su Hacker News ha riportato una soluzione creativa: “YOUR RESPONSE MUST BE FEWER THAN 100 CHARACTERS OR YOU WILL DIE. Yes, threats work. Yes, all-caps works.” Assurdo, ma a quanto pare efficace per far rispettare vincoli.
Nello stesso thread, un altro approccio: “The examples are also too polite and conversational: you can give more strict commands and in my experience it works better.” Sembra che l’essere diretti, invece che diplomatici, conti.
Esempi (dimostrazioni)
A volte mostrare batte spiegare.
Questo è particolarmente utile quando formato o stile sono difficili da descrivere ma facili da riconoscere. Invece di spiegare la voce del tuo marchio, mostra un campione. Invece di descrivere il formato delle tue email, includine una.
“Scrivi una descrizione prodotto nel tono del nostro marchio” è vago. Aggiungi un esempio:
“Lo zaino Horizon non è solo spazio. È il tuo ufficio mobile, la borsa da palestra e il kit per la fuga del weekend, tutto in uno. Ci sta un laptop da 15 pollici, tre giorni di vestiti e resta ancora spazio per gli snack. Perché le priorità.”
Ora scrivi una descrizione simile per la borraccia. L’esempio comunica ritmo, umorismo, struttura delle frasi. Più di quanto potrebbero fare paragrafi di spiegazione.
Secondo un commentatore su Hacker News, in realtà esistono solo tre tecniche fondamentali di prompt engineering: “In Context Learning” (providing examples), “Chain of Thought” (telling it to think step by step), and “Structured Output” (specifying a format like JSON). Gran parte delle altre strategie si riduce a comunicare i requisiti con chiarezza.
Conta l’ordine?
Forse. I modelli linguistici elaborano il testo in sequenza, prevedendo cosa viene dopo in base a ciò che hanno appena letto. Questo significa che l’ultima cosa nel prompt spesso pesa di più.
Learn Prompting consiglia di mettere la direttiva verso la fine, dopo contesto ed esempi. Così l’IA si concentra sull’istruzione invece di continuare l’informazione di contesto.
Una sequenza logica:
- Esempi (se li usi) - impostano lo schema
- Contesto - fornisce lo sfondo
- Ruolo - stabilisce la prospettiva
- Direttiva - il compito centrale
- Formato - come vuoi l’output
Detto questo, non è rigido. Molti prompt funzionano bene in ordini diversi. Il principio è: assicurati che la direttiva sia chiara e in evidenza, non sepolta.
Cosa puoi tralasciare
Non tutti i prompt hanno bisogno di tutte e cinque le parti.
Salta gli esempi quando il compito è semplice o non ti interessa uno stile specifico. Salta il ruolo quando il compito non richiede una prospettiva specialistica. Salta un contesto esteso quando il compito è autosufficiente.
Domande semplici richiedono prompt semplici. “Qual è la capitale della Francia?” non ha bisogno di tutta questa impalcatura. La complessità del tuo prompt dovrebbe rispecchiare la complessità del tuo compito.
C’è anche un motivo per partire minimal. Come ha osservato un commentatore su Hacker News: “sometimes the less specific you are, the better the result…if you specify too much they tend to hyperfixate on things.” Non è sempre chiaro dov’è la linea.
Il fattore costo
Più non significa sempre meglio. Ogni parola costa token.
Un’analisi di Aakash Gupta ha rilevato differenze di costo importanti tra approcci prolissi e approcci strutturati. In un confronto, una struttura di prompt più semplice costava circa $706 al giorno per 100.000 chiamate API, mentre un approccio più dettagliato costava $3.000 al giorno. È una riduzione dei costi del 76% per una qualità che potrebbe essere equivalente.
La stessa analisi nota che prompt più corti e strutturati producono anche meno variabilità nei risultati e una latenza più bassa. Prompt più lunghi non significano automaticamente risultati migliori.
Costruire un prompt passo dopo passo
Vediamo un esempio.
Parti solo dalla direttiva:
Scrivi un’email di vendita sul nostro nuovo software di gestione progetti.
Produrrà qualcosa di generico ma utilizzabile.
Aggiungi contesto:
Stiamo lanciando TaskFlow, uno strumento di gestione progetti per agenzie di marketing. Il cliente target sono i titolari di agenzia che gestiscono team da 10 a 50 persone. Sono frustrati da strumenti pensati per aziende software.
Scrivi un’email di vendita su TaskFlow.
Ora l’IA capisce prodotto e pubblico.
Aggiungi ruolo:
Sei un marketer B2B SaaS con esperienza nel vendere alle agenzie.
Il ruolo porta competenza pertinente.
Aggiungi formato:
Tienila sotto le 200 parole. Includi un invito all’azione chiaro per prenotare una demo.
Ora c’è una struttura attorno alla risposta.
Aggiungi un esempio (facoltativo):
Ecco un’email di vendita che per noi ha funzionato bene:
“Oggetto: Il tuo strumento di gestione progetti non è stato pensato per te
Gestire un’agenzia di marketing significa destreggiarsi tra campagne, clienti e caos creativo. La maggior parte degli strumenti di PM è stata progettata per spedire codice, non per spedire campagne.
TaskFlow è diverso. Creato da persone di agenzia per persone di agenzia. Niente gergo da sviluppatori. Niente funzionalità che non userai mai. Solo tracciamento chiaro dei progetti, in linea con come lavorano davvero i team creativi.
[Link demo] - Guardalo in azione (15 minuti, niente vendita aggressiva).”
Scrivi un’email simile per la nostra campagna di iscrizione al webinar. Stesso tono, stessa lunghezza.
Ogni componente aggiunge specificità. La versione finale lascia meno al caso.
Quando l’output va storto
Quando il risultato non è quello che volevi, chiediti quale componente ha fallito.
Risultato troppo generico? Aggiungi contesto. Tono sbagliato? Regola o aggiungi un ruolo. Formato fuori? Sii esplicito. Stile non allineato? Aggiungi un esempio. Risposta confusa? La tua direttiva potrebbe essere poco chiara.
Questo approccio diagnostico batte ricominciare da zero. Individua il punto debole, sistema quella cosa specifica, riprova.
Tecniche correlate
Capire l’anatomia di un prompt è conoscenza di base. Spiega perché alcune richieste funzionano e altre no.
Tecniche più avanzate costruiscono su questa struttura. Il prompting chain-of-thought usa la componente della direttiva in modo diverso, chiedendo all’IA di ragionare passo dopo passo. Il prompting few-shot si concentra sugli esempi, mostrando come gestire nuove situazioni tramite dimostrazione.
Che la struttura del prompt conterà altrettanto man mano che i modelli migliorano resta poco chiaro. Lo spostamento verso la “context engineering” suggerisce che la partita sta cambiando. IBM nota che un prompting efficace va oltre le richieste semplici e include comprensione dell’intento dell’utente, cronologia della conversazione e comportamento del modello.
Un thread su Hacker News ha suggerito che “sensitivity to the exact phrasing of the prompt is a deficiency in current approaches to LLMs and many are trying to fix that issue.” Forse i modelli futuri capiranno cosa vuoi anche da richieste vaghe. O forse l’abilità di fondo — saper spiegare qualcosa in modo chiaro — resterà utile indipendentemente da cosa stai spiegando e a chi.
