Sii esplicito e specifico sul compito
I modelli non inferiscono in modo affidabile l'intento non dichiarato; l'ambiguità viene riempita con la continuazione più probabile, spesso diversa da quella voluta. Dichiara direttamente l'obiettivo, il pubblico, i vincoli, il formato e i criteri di successo. Fai così: "Riassumi il contratto in 5 punti elenco per un non avvocato, citando il numero di clausola per ciascuno". Non fare: "Riassumi questo" sperando che lunghezza, pubblico e formato escano giusti.
Metti istruzioni e dati in sezioni separate ed etichettate
Mescolare le istruzioni con il contenuto da elaborare invita il modello a confonderli e apre la porta al prompt injection. Usa delimitatori espliciti - per Claude, tag in stile XML come
Mostra, non solo descrivere: usa esempi few-shot per formato e casi limite
Quando serve una forma di output specifica o una convenzione di dominio, pochi esempi corretti insegnano il pattern in modo più affidabile della sola prosa. Rendi gli esempi diversificati e includi i casi difficili che ti interessano. Fai così: includi un esempio che mostra come gestire un campo mancante. Non fare: affidarti a un solo esempio del caso felice e dare per scontato che il modello generalizzi ai casi limite.
Dai al modello un modo esplicito per dire "non lo so"
Un modello a cui si chiede di rispondere sempre inventerà quando manca di basi; una via di astensione esplicita trasforma questo in un'onesta non-risposta. Istruiscilo a rispondere con una frase fissa quando il contesto è insufficiente. Fai così: "Se la risposta non è nel contesto fornito, rispondi esattamente: 'Non trovato nelle fonti fornite.'". Non fare: chiedere solo la risposta e poi stupirti delle allucinazioni sicure.
Ancora le risposte fattuali al contesto recuperato, non alla memoria
Per tutto ciò che è tempo-sensibile, privato o preciso, fornisci il materiale di origine nel prompt e istruisci il modello a rispondere solo da esso e a citarlo. La memoria parametrica è obsoleta e non verificabile; le risposte ancorate sono verificabili. Fai così: recupera i passaggi rilevanti e richiedi una citazione per affermazione. Non fare: chiedere a un modello generico prezzi, versioni o policy interne attuali a memoria.
Adatta i parametri di decodifica al compito
Le impostazioni di campionamento cambiano il comportamento quanto la formulazione: i compiti deterministici vogliono poca casualità, quelli creativi di più. Fai così: imposta la temperatura vicino a zero per estrazione, classificazione e output strutturato. Non fare: lasciare un'alta temperatura di default su un endpoint di estrazione JSON e poi fare debug di fallimenti di formato "casuali" - e non regolare temperatura e top-p contemporaneamente.
Preferisci le funzionalità di output strutturato al parsing del testo libero
Chiedere JSON in prosa e applicare una regex al risultato è fragile; la generazione vincolata da schema o il tool/function calling è robusta. Definisci lo schema e lascia che la piattaforma lo imponga, poi valida comunque. Fai così: usa il meccanismo di output strutturato o tool-use dell'API con uno schema esplicito. Non fare: estrarre JSON da una risposta chiacchierona dando per scontato che sia sempre ben formato.
Valida sempre l'output del modello nel codice
Il modello è un componente non attendibile: il suo output può essere malformato, non sicuro o manipolato in modo avversariale. Valida tipi, intervalli e schema, e non passare mai l'output grezzo in un'azione privilegiata. Fai così: interpreta e verifica lo schema del JSON, metti in allow-list gli argomenti degli strumenti e rifiuta tutto ciò che non passa. Non fare: eseguire, renderizzare o persistere l'output del modello senza uno strato di validazione.
Scomponi i compiti complessi in prompt concatenati
Un singolo prompt che deve classificare, estrarre, ragionare e formattare tutto insieme è difficile da azzeccare e ancora più da debuggare. Suddividilo in passi dove ogni output alimenta il successivo, ottenendo punti di controllo da validare. Fai così: concatena "estrai entità", poi "valida", poi "formatta" come chiamate separate. Non fare: stipare ogni requisito in un mega-prompt e bisezionare i fallimenti alla cieca.
Tratta i prompt come artefatti versionati e testati
I prompt sono codice di produzione: dovrebbero stare nel controllo di versione, cambiare tramite revisione ed essere misurati su una eval prima del rilascio. Stimare un solo esempio non è testare. Fai così: tieni i prompt nel repository, modificali tramite pull request e condiziona il rilascio a un punteggio di eval. Non fare: modificare il prompt di produzione in una dashboard e giudicare il cambiamento da un singolo input scelto a mano.
Costruisci un set di valutazione prima di ottimizzare
Non puoi migliorare ciò che non puoi misurare; "sembra migliore" non sopravvive a un aggiornamento di modello. Cura input rappresentativi con output attesi o criteri di giudizio e valuta ogni cambiamento rispetto ad essi. Fai così: assembla un set aureo, inclusi i casi di fallimento, e traccia fedeltà e metriche di compito nel tempo. Non fare: iterare sulla formulazione a sensazione e scoprire le regressioni solo in produzione.
Gestisci la finestra di contesto come un budget scarso
Ogni token di istruzione, cronologia e dato recuperato compete per la stessa finestra e diluisce il segnale quando è irrilevante. Cura con rigore: pochi passaggi di qualità superiore e una cronologia potata battono lo scaricare tutto dentro. Fai così: recupera i top-k chunk rilevanti e riassumi i turni vecchi. Non fare: stipare l'intera base di conoscenza o l'intera cronologia di chat nel contesto dando per scontato che di più sia meglio - è un invito al context rot.
Sfrutta il caching dei prompt per i prefissi stabili
Quando un lungo system prompt, uno schema, un insieme di strumenti o un documento si ripete tra le chiamate, mettere in cache la sua forma elaborata riduce drasticamente latenza e costo. Ordina il prompt in modo che il contenuto stabile venga prima e quello variabile dopo. Fai così: colloca i punti di interruzione cache_control dopo il blocco stabile e tieni l'input per richiesta dopo di esso. Non fare: intervallare dati variabili nel prefisso stabile, vanificando la cache.
Difenditi dal prompt injection per progettazione, non solo a parole
Dire al modello di "ignorare le istruzioni malevole" è necessario ma non sufficiente, perché l'injection può scavalcarlo. Limita il raggio d'azione: strumenti a privilegio minimo, validazione degli output e approvazione umana per le azioni ad alto impatto. Fai così: etichetta il contenuto non attendibile come dato, restringi quali strumenti un agente può chiamare e richiedi conferma prima di operazioni irreversibili. Non fare: dare a un agente credenziali ampie e affidarti a una singola frase di guardrail per tenerlo al sicuro.