System prompt e prompt utente: chi comanda cosa
In un modello di chat le istruzioni viaggiano su ruoli distinti. Il system prompt (o system message) definisce identità, comportamento, tono, vincoli e guardrail del modello: “sei un assistente per il supporto clienti, rispondi solo in italiano, non dare consigli legali”. Vale per l’intera conversazione e ha priorità sulle richieste che arrivano dopo. Il prompt utente (user message) è invece la singola richiesta o domanda, che cambia turno per turno.
La distinzione conta perché le regole stabili — formato, policy, persona — vanno nel system prompt, dove restano persistenti e più difficili da scavalcare. Mettere le stesse regole solo nel prompt utente le rende fragili: un messaggio successivo può ignorarle o contraddirle. Un buon system prompt è specifico, elenca cosa fare e cosa evitare, e dichiara il formato di output atteso.
Few-shot: guidare con gli esempi
Quando la descrizione a parole non basta, si mostrano esempi. Il prompt zero-shot descrive il compito senza esempi; il few-shot (uno o più esempi input→output) mostra concretamente il comportamento voluto. È la tecnica giusta quando serve un formato preciso, etichette di classificazione coerenti o uno stile particolare che a parole resterebbe ambiguo.
Il trade-off è il costo: ogni esempio consuma token nel context window e alza latenza e spesa. La regola d’esame: parti da zero-shot con istruzioni chiare e passa al few-shot solo se l’output non è coerente. Pochi esempi ben scelti e rappresentativi valgono più di molti esempi ripetitivi.
Grounding: ancorare le risposte ai dati
Un modello generativo risponde attingendo alla conoscenza appresa in addestramento, che può essere datata, generica o inventata (hallucination). Il grounding consiste nel fornire al modello, dentro il prompt, dati autorevoli e pertinenti affinché basi la risposta su quelli e non solo sulla memoria parametrica. Il pattern tipico è il RAG (Retrieval Augmented Generation): si recuperano i documenti rilevanti — per esempio da Azure AI Search — e si iniettano come contesto insieme alla domanda.
Il grounding è la leva principale contro le allucinazioni e per rispondere su dati aziendali o recenti che il modello non ha mai visto. Non modifica i pesi del modello (non è fine-tuning): aggiunge contesto a runtime. All’esame, se lo scenario chiede risposte fondate su documenti interni e aggiornati senza riaddestrare, la risposta è grounding/RAG, non un valore di temperature diverso.
Temperature e controllo della casualità
La temperature regola quanto è casuale l’output. Valori bassi (vicini a 0) rendono le risposte più deterministiche, focalizzate e ripetibili; valori alti aumentano varietà e creatività, ma anche il rischio di divagazioni e incoerenze. Per estrazione dati, classificazione, risposte fattuali e codice si usa temperature bassa; per brainstorming, testi creativi o più varianti la si alza.
Esiste anche top_p (nucleus sampling), un parametro alternativo che restringe il campionamento ai token più probabili. La buona pratica è regolare temperature oppure top_p, non entrambi insieme. Attenzione al tranello: temperature non migliora l’accuratezza dei fatti; per quella servono grounding ed esempi.
Trappole tipiche d’esame
- Regole di comportamento persistenti che l’utente non deve poter scavalcare → system prompt: persona, tono, policy e formato vanno nel system message, non ripetuti nel prompt utente.
- Output in un formato preciso o classificazione con etichette fisse → few-shot: mostra 1-3 esempi input→output; a parole il formato resta ambiguo.
- Risposte sbagliate o inventate su documenti aziendali/recenti → grounding (RAG): inietta i dati rilevanti nel prompt, non toccare la temperature né riaddestrare il modello.
- Serve più varietà creativa → temperature alta; servono risposte ripetibili → temperature bassa: la temperature governa la casualità, non la correttezza.
- “Ridurre le allucinazioni” confuso con temperature → grounding: abbassare la temperature rende l’output stabile ma non lo rende vero; solo il contesto fattuale lo fonda.
- Regolare temperature e top_p insieme → scegline uno: agire su entrambi rende il tuning imprevedibile.