Sfoglia altri articoli simili con le etichette:
Anthropic, nel documento di accompagnamento al rilascio di Claude 4.7 a inizio 2026, riporta che il delta di accuratezza tra un prompt scritto bene e un prompt scritto male, sullo stesso modello e sullo stesso task, oscilla tra 18 e 41 punti percentuali. OpenAI, nei materiali tecnici di GPT-5, riferisce numeri simili. Google DeepMind, sul technical report di Gemini 3, conferma la stessa scala.
Tradotto: lo stesso identico modello, sullo stesso identico compito, può sbagliare quattro volte su dieci o due volte su dieci, solo a seconda di come lo interroghi.
Per chi ha smesso di considerare il prompt engineering una moda, è il dato che chiude il dibattito. Per chi ancora pensa che basti scrivere bene, è il momento di aggiornarsi.
Il prompt non è una domanda, è un contratto
Il primo errore che vedo ancora nelle aziende italiane è considerare il prompt come una query di Google. Si scrive una frase secca, si attende una risposta, si commenta che “ChatGPT non capisce”. Il modello, in realtà, capisce benissimo. Sta solo rispondendo a una richiesta sotto-specificata.
Un prompt operativo è composto da quattro elementi: contesto (chi sei, per chi scrivi, su quale settore), compito (cosa devi produrre, in che forma), esempi (se possibile, due o tre input-output di riferimento), vincoli (lunghezza, registro, cose da non fare). Quando i quattro elementi sono chiari, l’output cambia in modo netto. Quando manca anche solo uno, la qualità precipita.
Lo dico da quando insegnavo allo IED di Milano, e oggi lo ripeto nelle sessioni di formazione che la community AIPIA organizza per i professionisti che si certificano via EDC: il prompt è un contratto. Più è preciso, meno spazio lasci all’interpretazione.
Chain-of-thought: quando, perché e come
Il chain-of-thought (CoT) è la tecnica di forzare il modello a esplicitare i passaggi di ragionamento prima di produrre la risposta finale. Wei e altri, in un paper del 2022 che è ancora la fonte canonica, dimostrarono che sui task aritmetici l’accuratezza di GPT-3 saliva del 50% chiedendo semplicemente “Pensa passo passo prima di rispondere”.
Nel 2026 i modelli reasoning di nuova generazione (o3, Claude 4.7 Extended Thinking, Gemini 3 Deep Think) hanno il CoT integrato. Non serve più chiedergli di “pensare passo passo”, lo fanno di default in un thinking layer invisibile all’utente. Ma sui modelli standard (Claude 4.7 Sonnet senza extended thinking, GPT-5 senza modalità deep reasoning) la tecnica resta efficacissima.
Quando ho lavorato sul brief di una campagna ADV per un cliente del lusso, ho testato lo stesso prompt creativo su Claude 4.7 Sonnet con e senza CoT. Versione secca: tre idee plausibili ma generiche. Versione con CoT esplicito (“prima analizza i tre archetipi del brand, poi confrontali con i trend visivi della categoria, poi proponi tre concept coerenti”): tre idee più strutturate, due usabili senza ritocchi.
Il CoT non si attiva su tutto. Per task creativi puri (titolo accattivante, headline) può rendere l’output più meccanico. Per task analitici (sintesi di un report, valutazione di tre opzioni, debugging logico) è quasi sempre vincente.
Few-shot: l’arma più sottovalutata
Il few-shot prompting consiste nel fornire al modello 2-5 esempi di input-output corretti, prima di chiedergli di processare un nuovo input. Sembra banale, è la tecnica più potente disponibile a chi non può fine-tunare un modello.
Esempio reale. Un cliente B2B mi ha chiesto di automatizzare la classificazione di 4.000 ticket di customer support in cinque categorie. Versione zero-shot (“Classifica questo ticket in una delle cinque categorie: A, B, C, D, E”): accuratezza del 71%. Versione few-shot, con tre esempi per categoria forniti nel prompt: accuratezza del 94%. Stesso modello, stesso costo per token, performance da SaaS verticale a costo zero di setup.
Il punto è che il few-shot funziona perché il modello inferisce il pattern dai pochi esempi e lo applica. È inferenza statistica, non logica. Per questo serve scegliere gli esempi con cura: devono essere rappresentativi della distribuzione reale dei dati, non i casi facili.
System prompt: il livello che separa amatori da professionisti
Il system prompt è l’istruzione di alto livello che precede tutte le conversazioni in un’applicazione costruita su API. Su ChatGPT consumer si vede solo se si lavora con i Custom GPT (dove diventa “Instructions”). Su Claude.ai compare nei Projects. Su Gemini lo si gestisce nei Gems. Per chi sviluppa su API, è il primo blocco di ogni chiamata.
Un system prompt scritto bene definisce: ruolo del modello, regole di output, gestione delle eccezioni, tono di voce, cose da non fare mai. Pochi paragrafi, scelti con precisione.
L’errore tipico è il system prompt-papiro. Tremila parole, contraddizioni interne, regole impossibili da rispettare. Il modello, nel dubbio, ne ignora un pezzo. L’altro estremo è il system prompt-slogan: “Sei un assistente utile e gentile”. Inutile.
La soglia di qualità si misura su un esercizio: se prendi il system prompt e lo dai a un junior umano come istruzione operativa, capisce cosa deve fare? Se sì, è buono. Se no, va riscritto.
Errori comuni che continuo a vedere
Tre errori ricorrono in quasi ogni azienda che inizia a strutturare un uso serio dei modelli.
Il primo è confondere il prompt con il modello. “Claude non funziona per questo task” è quasi sempre la versione errata di “il mio prompt su Claude non funziona”. Lo stesso prompt rifattorizzato fa miracoli. Conviene sempre testare almeno due varianti del prompt prima di concludere che il modello è inadeguato.
Il secondo è non gestire la temperatura. Per output deterministici (classificazione, estrazione dati, formattazione) la temperatura va abbassata a 0 o 0.2. Per output creativi (testi pubblicitari, brainstorming) si alza a 0.7 o 0.9. È un parametro banale, lo cambia il 5% delle persone che usano i modelli professionalmente.
Il terzo è ignorare l’ordine delle istruzioni. I modelli pesano le istruzioni iniziali e finali più di quelle centrali. Le regole critiche vanno in apertura o in chiusura. Mai sepolte a metà di un blocco lungo.
Quando il prompt è il problema, quando lo è il modello
La domanda finale, in ogni progetto, è capire se a parità di prompt cambierebbe il risultato con un modello diverso, o se a parità di modello cambierebbe con un prompt diverso. La risposta determina dove investire.
Regola pratica. Se sullo stesso prompt due modelli di pari classe (GPT-5 e Claude 4.7, Gemini 3 e Claude 4.7) producono output sostanzialmente equivalenti, il modello non è il problema. Se invece il delta è grande, conviene cambiare modello. Se sullo stesso modello tre varianti di prompt producono tre risultati molto diversi, il prompt è il problema. Va sistemato lì.
Il prompt engineering, lo dico anche nelle Academy AIPIA, non è una skill esoterica. È metodo. Si impara facendo, si migliora misurando, si automatizza scrivendo prompt library riutilizzabili. Le aziende italiane che lo stanno trattando come una competenza interna stanno costruendo un vantaggio competitivo che, tra diciotto mesi, sarà difficile colmare.
