Prompt che funzionano su più modelli: come scriverli

Un prompt scritto e tarato su un modello raramente rende allo stesso modo su un altro. Di solito produce comunque qualcosa di sensato — i modelli recenti sono tutti capaci — ma il formato si sposta, alcuni vincoli vengono ignorati e la qualità sui casi difficili cambia in modo non prevedibile.

Il problema è pratico, non teorico: i cataloghi si muovono in fretta, i prezzi cambiano, un modello può essere ritirato o superato da uno più economico. Se il lavoro fatto sui prompt è legato a un solo fornitore, ogni cambio diventa un progetto di migrazione.

La soluzione non è scrivere prompt generici e vaghi, che funzionano male dappertutto. È separare ciò che descrive il compito — portabile per definizione — da ciò che è taratura su un modello specifico.

Cosa cambia davvero da un modello all'altro

Non tutto si comporta diversamente. Conviene sapere dove aspettarsi sorprese.

La riga più insidiosa è tono e verbosità: i modelli hanno inclinazioni diverse su quanto dilungarsi e quanto premettere. Un prompt che non dice nulla in proposito ottiene risultati diversi ovunque, e la differenza si nota solo quando qualcuno confronta gli output.

Le cinque regole che rendono un prompt portabile

1. Descrivi il compito, non il comportamento del modello. "Estrai le date di scadenza e restituiscile in ordine cronologico" viaggia ovunque. Un'istruzione costruita per aggirare un difetto noto di un modello preciso, no.
2. Fissa il formato in modo verificabile. Campi, ordine, cosa scrivere quando un dato manca. Se l'output deve essere letto da un altro sistema, dichiara la struttura invece di sperare che venga ordinata.
3. Dai esempi, non aggettivi. "Rispondi in modo professionale" significa cose diverse per modelli diversi. Due esempi di risposta corretta valgono più di cinque righe di descrizione.
4. Separa istruzioni e dati. Tenere distinto "cosa devi fare" da "su cosa lo fai" riduce gli equivoci e rende semplice cambiare una cosa sola.
5. Prevedi sempre l'uscita di sicurezza. Una riga che autorizza a dire che l'informazione non c'è. È la difesa più efficace contro le risposte inventate, e funziona su tutti i modelli — vedi come evitare le allucinazioni.

La struttura a due strati

Il modo più pratico di organizzarsi, quando usi o prevedi di usare più di un modello.

La regola pratica: se una riga del prompt smetterebbe di avere senso su un altro modello, appartiene allo strato specifico. Tutto il resto sta nel nucleo. Così quando cambi modello riscrivi il dieci per cento, non tutto.

Mantenere invece due prompt completamente separati sembra più semplice all'inizio e diventa un problema alla prima modifica del processo, perché ogni cambiamento va fatto due volte — e una delle due prima o poi viene dimenticata.

Come si verifica il passaggio da un modello all'altro

Il confronto va fatto con metodo, altrimenti resta una sensazione.

• Usa lo stesso campione di casi reali, almeno cinquanta, compresi quelli difficili
• Usa lo stesso criterio di correttezza, scritto prima di guardare i risultati
• Esegui su entrambi i modelli senza ritoccare il prompt fra un'esecuzione e l'altra
• Conta gli esiti: corretti, sbagliati, ambigui. Non leggere due risposte e decidere
• Guarda dove sbagliano in modo diverso: è lì che serve lo strato specifico
• Ripeti la prova quando esce una versione nuova: anche un aggiornamento minore può spostare i risultati

Il risultato tipico è che i due modelli se la cavano allo stesso modo sui casi normali e divergono su quelli strani. È esattamente l'informazione che serve: dice quanto lavoro costa il passaggio, prima di doverlo fare di fretta.

Le tre differenze che rompono più spesso un passaggio

Quando un prompt smette di funzionare su un altro modello, nella pratica la causa è quasi sempre una di queste tre.

La forma dell'output. È il caso più frequente e il più fastidioso, perché il contenuto è giusto ma il sistema a valle si rompe: una parola in più, una premessa di cortesia, una struttura leggermente diversa. Si previene dichiarando la struttura invece di descriverla a parole.

La gestione dell'incertezza. Davanti a un caso ambiguo, un modello chiede chiarimenti, un altro sceglie l'interpretazione più probabile, un terzo segnala il dubbio nella risposta. Sono tre comportamenti ragionevoli e incompatibili fra loro: va deciso tu quale vuoi, e scriverlo.

La lunghezza. A parità di istruzioni alcuni modelli tendono a dilungarsi, altri a sintetizzare. Se la lunghezza conta — una descrizione prodotto, un messaggio a un cliente — va indicata in modo misurabile, non con aggettivi.

C'è un effetto collaterale utile: correggere questi tre punti migliora anche il modello di partenza. Sono difetti che c'erano già, resi visibili dal confronto. È uno dei motivi per cui provare un prompt su un secondo modello conviene anche quando non hai nessuna intenzione di cambiare — lo stesso principio del confronto fra Claude, GPT e Gemini.

Esempi pratici

Azienda di servizi, classificazione delle mail in arrivo. Il prompt era stato messo a punto su un modello e funzionava bene. Provandolo su un modello più economico, la classificazione restava corretta ma l'output cambiava forma: a volte una parola sola, a volte una frase di spiegazione. Il sistema a valle si aspettava una parola sola e andava in errore. La correzione è stata dichiarare il formato esatto e aggiungere due esempi: da quel momento entrambi i modelli producevano la stessa forma, e il passaggio a quello più economico è diventato possibile.

Studio tecnico, estrazione dati da capitolati. Passando di modello, la qualità restava simile nella media ma peggiorava sui documenti con tabelle. Separando istruzioni e dati e aggiungendo un esempio di documento con tabella, il divario si è chiuso quasi del tutto. Il lavoro utile è stato sul nucleo comune, e ha migliorato anche il modello di partenza.

Errori da evitare

• Scrivere prompt vaghi per renderli portabili. Funzionano male dappertutto: la portabilità nasce dalla precisione sul compito, non dalla genericità.
• Copiare formule pensate per un modello specifico. Sono la parte che si rompe per prima.
• Non dichiarare il formato. È la causa più comune di rotture quando si cambia modello.
• Confrontare su esempi diversi. Senza campione condiviso il confronto non dice niente.
• Dare per buono un prompt dopo un aggiornamento di versione. Anche una versione minore può cambiare le inclinazioni.
• Legare il processo a funzioni proprietarie senza sapere quanto costerebbe sostituirle.

Come applicarlo in azienda

Per una PMI questo si traduce in tre abitudini, tutte a costo quasi zero.

1. Tieni i prompt fuori dalle chat personali. In un posto condiviso, con scritto a cosa servono e come si verifica che funzionino.
2. Segna quale parte è specifica del modello. Bastano due righe di commento: quando cambierai, saprai cosa toccare.
3. Conserva il campione di prova. È l'unico strumento che rende una migrazione una verifica di mezza giornata invece di un salto nel buio.

Questa è anche la premessa che rende praticabile l'uso di modelli diversi per compiti diversi: il modello leggero per lo smistamento, quello più capace dove serve davvero. Senza prompt portabili quella strategia costa troppo per essere mantenuta. E quando i prompt entrano in processi che girano da soli, diventano componenti di sistema a tutti gli effetti — il passaggio verso gli agenti AI.

Conclusione

Un prompt portabile non è un prompt generico: è un prompt preciso sul compito e neutro sul fornitore. Descrivi cosa deve uscire, mostralo con esempi, dichiara il formato, prevedi il "non lo so" — e tieni da parte, in un blocco separato, le poche righe che parlano a un modello specifico.

Il vantaggio non si vede il primo giorno. Si vede quando il prezzo cambia, esce un modello migliore o il tuo viene ritirato: allora la differenza è fra mezza giornata di verifica e settimane di rifacimento. Per decidere quando conviene muoversi, vedi quando cambiare modello AI.

Se vuoi passare dai test con ChatGPT a un sistema AI integrato nei processi aziendali, Giallo Studio progetta agenti e automazioni su misura.

Schema consigliato: Article + FAQPage + BreadcrumbList