Il prompt engineering non è trovare parole segrete: significa definire obiettivo, contesto, esempi, vincoli e criteri con cui valutare l’output.
Il prompt engineering è stato raccontato prima come una nuova professione miracolosa e poi come una moda destinata a sparire. La realtà è meno spettacolare: progettare bene le istruzioni continua a essere utile, ma non consiste nel trovare frasi magiche che “sbloccano” il modello.
Il prompt engineering è il lavoro di trasformare un obiettivo in un compito leggibile dal sistema, fornendo il contesto necessario, chiarendo i vincoli e specificando come riconoscere un buon risultato.
“Scrivi qualcosa sul marketing” lascia moltissime decisioni al modello. “Confronta tre strategie di acquisizione per una PMI B2B italiana, indicando costo, tempi e rischi” definisce invece un risultato verificabile.
Più il compito è ambiguo, più l’output dipende dalle assunzioni del modello. Essere specifici non significa scrivere prompt lunghissimi: significa eliminare l’ambiguità che conta.
Quando il compito dipende da dati aziendali, documenti, informazioni recenti o regole interne, il contesto deve essere fornito direttamente o recuperato tramite strumenti.
Le linee guida OpenAI sul prompting indicano proprio il contesto rilevante come una delle leve principali per migliorare l’output. In molti casi un buon sistema RAG o l’accesso a un file vale più di cento aggettivi nel prompt.
Il few-shot prompting consiste nel fornire alcuni esempi di input e output corretti. Il modello ricava il pattern e prova ad applicarlo ai nuovi casi.
È particolarmente utile per classificazioni, formati editoriali e trasformazioni ripetitive. Gli esempi dovrebbero rappresentare una gamma abbastanza varia dei casi reali, non soltanto quello più semplice.
Specificare lunghezza, tono, struttura, campi obbligatori o formato dell’output aiuta il sistema a capire cosa deve produrre. Quando l’output deve essere elaborato da software, è spesso meglio usare formati strutturati invece di affidarsi a testo libero.
Per compiti complessi conviene anche definire il workflow: quali fonti consultare, quali controlli eseguire e quali condizioni richiedono una verifica umana.
Con gli agenti e gli strumenti, una parte delle istruzioni vive nelle configurazioni di sistema, nelle policy, nelle funzioni disponibili e nei dati recuperati. Il prompt dell’utente è soltanto uno dei livelli.
Questo è importante perché ridimensiona l’idea del “prompt perfetto”. Un’applicazione robusta dipende da architettura, strumenti, controlli ed eval, non soltanto da come è formulata una frase.
Se un prompt deve essere usato cento o mille volte, giudicarlo da due esempi riusciti non basta. Serve un set di casi realistici e criteri per misurare qualità, errori e regressioni.
Le guide moderne di ottimizzazione dei modelli mettono infatti le eval prima o insieme al prompt engineering. Prima definisci cosa significa “funziona”, poi modifichi istruzioni ed esempi e misuri se il risultato migliora davvero.
Se il problema è la mancanza di dati aggiornati, serve retrieval. Se il modello deve eseguire azioni, servono strumenti. Se occorre un comportamento estremamente coerente su moltissimi esempi, può avere senso valutare forme di fine tuning o altri metodi di ottimizzazione.
Un prompt non può compensare una fonte dati sbagliata o un compito definito male.
I modelli diventano più capaci e tollerano istruzioni meno rigide, ma questo non elimina la necessità di chiarezza. Anzi, quando un sistema può fare più cose, diventa ancora più importante decidere quale risultato vogliamo e quali errori non possiamo accettare.
Il prompt engineering quindi non è una collezione di incantesimi. È una forma pratica di progettazione: obiettivo, contesto, esempi, vincoli e verifica.
Usare un modello per studiare funziona meglio quando il prompt trasforma l’AI in uno strumento di verifica attiva, non in una scorciatoia che produce soltanto riassunti. Un buon schema può chiedere di spiegare un concetto a un livello preciso, proporre un esempio, fare una domanda alla volta e correggere la risposta prima di proseguire.
Per esempio: “Spiegami [argomento] come a uno studente che conosce già [prerequisiti]. Poi fammi cinque domande, una alla volta. Dopo ogni risposta indicami cosa è corretto, cosa manca e quale concetto devo ripassare.” Qui obiettivo, livello iniziale, formato e criterio di feedback sono espliciti.
Lo stesso principio vale per schemi e quiz: è più utile chiedere al modello di individuare relazioni, prerequisiti e punti deboli che delegargli l’intero lavoro cognitivo. Il prompt migliore, nello studio, non elimina lo sforzo: lo organizza.
Nei prompt per le lingue il contesto più importante è il livello reale dell’utente. “Parla con me in inglese” lascia troppe decisioni al modello; “simula una conversazione di livello B1, una domanda alla volta, correggendo solo gli errori che cambiano il significato” definisce invece difficoltà, ritmo e tipo di feedback.
Si può applicare la stessa struttura al vocabolario: chiedere parole legate a un contesto concreto, una frase d’esempio e poi un piccolo esercizio di recupero. Per la grammatica conviene specificare la regola da allenare e chiedere esempi contrastivi, cioè frasi corrette e frasi con errori da riconoscere.
Il vantaggio non sta nel creare un “tutor perfetto”, ma nel rendere l’interazione adattiva: conversazione, correzione e difficoltà possono cambiare in base alle risposte dell’utente.
Per la scrittura, formule come “scrivi un articolo perfetto” servono poco. Un prompt più affidabile specifica chi leggerà il testo, che cosa deve ottenere, quali informazioni sono disponibili e quali vincoli non devono essere violati. Se esiste già una bozza, spesso è meglio chiederne una trasformazione invece di generare tutto da zero.
Una struttura riutilizzabile è: “Riscrivi il testo seguente per [pubblico]. L’obiettivo è [scopo]. Mantieni invariati [fatti/tesi/dati], elimina ripetizioni, usa un tono [tono] e restituisci il risultato in [formato].”
Separare contenuto e stile riduce anche le allucinazioni: prima si può chiedere una scaletta basata sulle fonti disponibili, poi verificare i punti e soltanto alla fine lavorare su tono, ritmo e forma.
Nel lavoro quotidiano i prompt più utili non sono quelli che promettono di “aumentare la produttività”, ma quelli che trasformano input disordinati in un output operativo. Un elenco di attività può diventare un piano solo se il modello conosce priorità, scadenze, dipendenze e tempo disponibile.
Per esempio: “Ordina queste attività per impatto e urgenza. Ho quattro ore disponibili, la consegna X dipende da Y e non posso spostare Z. Proponi un piano, indica cosa rimandare e segnala le assunzioni che stai facendo.”
Chiedere esplicitamente le assunzioni è importante: impedisce che l’AI trasformi informazioni mancanti in certezze invisibili e rende il risultato più facile da controllare.
Per ottenere una buona email non basta chiedere un tono “professionale”. Il modello deve sapere chi scrive, chi riceve, quale rapporto esiste tra le parti, che cosa si vuole ottenere e quanto deve essere diretto il messaggio.
Una richiesta più utile può essere: “Riscrivi questa email per un cliente con cui lavoro già. Voglio ottenere una risposta entro venerdì senza sembrare aggressivo. Massimo 120 parole, apertura breve, richiesta esplicita e chiusura cordiale. Non aggiungere informazioni che non sono nel testo.”
Quando si risponde a un messaggio ricevuto, conviene fornire anche il testo originale: il contesto conversazionale riduce il rischio di ripetere domande già risolte o usare un tono incoerente con lo scambio.
Quando il compito è prendere una decisione, chiedere semplicemente “cosa dovrei fare?” spinge il modello a riempire i vuoti con assunzioni. È più utile chiedergli di separare fatti, ipotesi, criteri e scenari.
Un prompt robusto può essere: “Analizza questa decisione. Elenca i criteri che sto usando, indicami quali informazioni mancano, costruisci tre scenari plausibili e mostra per ciascuno vantaggi, rischi e condizioni che potrebbero farmi cambiare scelta. Non scegliere al posto mio.”
Questa impostazione sfrutta bene il modello come strumento di esplorazione: fa emergere alternative e contraddizioni senza trasformare una previsione probabilistica in autorità decisionale.