Cos'è il prompt engineering (e quanto serve ancora oggi)

Il prompt engineering è la pratica di scrivere e strutturare le istruzioni date a un modello linguistico per ottenere un risultato affidabile e ripetibile. Non è la ricerca della frase magica: è definire con precisione il compito, il contesto necessario, il formato dell'output e i criteri per giudicarlo corretto.

La parola "engineering" trae in inganno. Non c'è niente di particolarmente tecnico nello scrivere un buon prompt: le competenze che servono sono saper descrivere un processo e saper riconoscere un output sbagliato. Chi conosce bene il proprio mestiere scrive prompt migliori di chi conosce bene l'informatica.

C'è però una domanda onesta da farsi: quanto serve ancora, oggi che i modelli interpretano bene anche richieste scritte male? La risposta breve è che per l'uso occasionale conta molto meno di due anni fa, mentre in produzione conta ancora parecchio — e questa guida spiega perché.

Che cosa comprende davvero

Un prompt utile non è una frase: è una struttura. Quasi sempre contiene questi elementi, esplicitamente o meno.

Il salto di qualità più grande, nella pratica, arriva da due cose banali: specificare il formato dell'output e dare due o tre esempi di risposta corretta. Sono anche le due che vengono saltate più spesso.

Perché oggi conta meno di prima (per l'uso quotidiano)

Fino a un paio d'anni fa servivano accorgimenti che oggi sono in gran parte superati: formule per ottenere ragionamenti passo passo, giri di parole per evitare rifiuti, strutture rigide per avere output ordinati.

I modelli recenti gestiscono molto di questo da soli. Chiedere in modo normale funziona quasi sempre, e alcune tecniche diffuse anni fa oggi sono inutili o controproducenti: irrigidiscono la risposta senza migliorarla.

Resta vero, invece, tutto ciò che riguarda la chiarezza: un compito definito male resta un problema anche per il modello migliore.

Dove invece fa ancora una differenza misurabile

Il punto che cambia tutto è la differenza fra usare l'AI e metterla in produzione.

La differenza è che in conversazione correggi al volo: se la risposta non va, riformuli. In un processo automatico nessuno riformula, e lo stesso difetto si ripete su ogni esecuzione.

Prompt engineering e context engineering

È la distinzione più utile da avere chiara, e quella che sposta di più i risultati nei sistemi reali.

• Il prompt engineering riguarda le istruzioni: cosa chiedi e come.
• Il context engineering riguarda le informazioni: quali dati metti a disposizione, come li selezioni, quanto ne metti.

In un sistema che risponde su documenti aziendali, un prompt scritto benissimo su documenti sbagliati produce risposte sbagliate con grande eleganza. La leva vera è recuperare il pezzo giusto di informazione, che è un problema di selezione, non di formulazione: è il tema del RAG.

Vale anche l'opposto di quello che si pensa: più contesto non è meglio. Riempire la finestra di materiale poco pertinente peggiora le risposte e alza i costi, perché tutto quel testo si paga — vedi cosa sono i token.

Come si valuta un prompt (l'unico modo che conta)

Non si valuta leggendo l'output e dicendo "sì, mi sembra buono". Si valuta così:

1. Raccogli un campione di casi veri, almeno cinquanta, compresi quelli difficili e strani. Non esempi inventati.
2. Definisci cosa vuol dire corretto, prima di guardare le risposte. Se non riesci a scriverlo, il compito non è chiaro nemmeno a te.
3. Esegui e conta: quante volte è corretto, quante volte è sbagliato, quante volte è ambiguo.
4. Cambia una cosa sola e riesegui sullo stesso campione. Due modifiche insieme e non saprai quale ha funzionato.
5. Riverifica quando cambi modello: un prompt è tarato su un modello preciso.

Questo è anche il motivo per cui il "prompt perfetto" non esiste: è sempre la combinazione di un compito, un modello e un tipo di dati. Cambiane uno e il lavoro va rifatto in parte. Per la pratica quotidiana vedi come iniziare con il prompt engineering e la raccolta di prompt per l'azienda.

Le tecniche che reggono ancora alla prova

Sfrondando quello che è invecchiato, restano poche cose che continuano a fare differenza misurabile.

Dare esempi dell'output voluto. È la leva singola più efficace, e va usata bene: due o tre esempi diversi fra loro, che coprano anche un caso limite. Tre esempi tutti uguali insegnano al modello a gestire un caso solo.

Fissare il formato in modo verificabile. Non "rispondi in modo ordinato", ma la struttura esatta: quali campi, in che ordine, cosa mettere quando un dato manca. Se l'output deve essere letto da un altro programma, questa non è una preferenza estetica: è un requisito.

Prevedere l'uscita di sicurezza. Una riga che autorizza il modello a dire che l'informazione non c'è. Senza, il modello riempie il vuoto, ed è così che nascono la maggior parte delle risposte inventate.

Separare istruzioni e dati. Tenere distinto "cosa devi fare" da "su cosa lo fai" riduce gli equivoci e rende molto più facile cambiare una cosa sola quando qualcosa non va.

Chiedere un solo compito per volta. Un prompt che chiede di estrarre, valutare e riassumere insieme fa tutte e tre le cose peggio di tre passaggi separati.

Quanto costa un prompt scritto male

C'è un aspetto economico che si nota solo quando il volume cresce. Ogni esecuzione paga tutto quello che le mandi: istruzioni, esempi, contesto. Un prompt di sistema lungo il doppio del necessario, moltiplicato per decine di migliaia di chiamate, diventa una voce di costo reale.

Il conto ha tre componenti che si sommano:

• Il testo delle istruzioni, che rispedisci identico a ogni singola chiamata
• Il contesto che alleghi, spesso molto più grande di quanto servirebbe
• Le riesecuzioni, perché quando l'output è sbagliato qualcuno rilancia — e paghi due volte

La conseguenza pratica è che la qualità del prompt e il costo del sistema sono lo stesso problema visto da due lati: un prompt più preciso costa meno, perché riduce contesto inutile e tentativi ripetuti.

Esempi pratici

Agenzia immobiliare, 6 persone. Le descrizioni degli immobili venivano generate con richieste diverse ogni volta, e il risultato era disomogeneo: alcune schede con i metri quadri all'inizio, altre no, lunghezze variabili. Il lavoro utile non è stato trovare parole migliori, ma fissare il formato: ordine dei dati, lunghezza massima, cosa non scrivere mai (promesse su rendimenti, riferimenti al vicinato). Da lì la revisione umana è passata da riscrittura a controllo.

Studio legale, pratiche ricorrenti. Il sistema doveva estrarre da un contratto scadenze e clausole di recesso. Il prompt iniziale era ragionevole ma su un campione di cinquanta contratti sbagliava in modo ricorrente su quelli con più allegati. La correzione non è stata riscrivere la richiesta: è stata cambiare cosa veniva dato in pasto al modello, passando dall'intero fascicolo alle sole sezioni pertinenti. Problema di contesto, non di prompt.

Errori da evitare

• Cercare la formula magica. Le liste di "prompt segreti" sono quasi sempre tarate su modelli vecchi.
• Valutare su tre esempi scelti bene. Serve un campione che contenga anche i casi antipatici.
• Cambiare più cose insieme. Si perde la capacità di capire cosa ha funzionato.
• Riempire il contesto. Più materiale non vuol dire risposte migliori: spesso è il contrario.
• Non prevedere il "non lo so". Un sistema che deve sempre rispondere, prima o poi inventa — vedi come evitare le allucinazioni.
• Dare per buono un prompt dopo un cambio di modello. Va riverificato sullo stesso campione.

Come applicarlo in azienda

Per una PMI il prompt engineering non è un ruolo da assumere: è una pratica da mettere dove i processi si ripetono.

Tre mosse concrete, in ordine:

1. Individua i compiti ripetitivi dove oggi qualcuno scrive ogni volta una richiesta diversa a mano. Sono quelli che guadagnano di più da una struttura fissa.
2. Scrivi un prompt condiviso per ciascuno, con formato dell'output e criteri di correttezza. Mettilo dove tutti lo trovano, non nelle chat personali.
3. Misura su casi veri e riverifica quando cambi strumento o modello.

Quando questi compiti diventano automatici e nessuno rilegge più ogni output, il prompt smette di essere un testo e diventa un componente di sistema: da lì in poi vale come un pezzo di software, e va versionato e testato come tale. È il passaggio che porta agli agenti AI e all'automazione dei processi.

Conclusione

Il prompt engineering è meno esotico e più utile di come viene raccontato: è descrivere bene un compito e verificarlo su casi veri. Per l'uso quotidiano oggi basta la chiarezza; in produzione serve metodo, perché lì la stessa istruzione gira migliaia di volte senza che nessuno la corregga.

E quando i risultati non arrivano, prima di riscrivere per la decima volta la richiesta conviene guardare altrove: quasi sempre il problema è quali informazioni sta vedendo il modello, non come gliele hai chieste.

Vuoi capire quali processi della tua azienda possono essere automatizzati con l'AI? Giallo Studio può aiutarti a trasformare il problema in un workflow reale.

Schema consigliato: Article + FAQPage + BreadcrumbList