Cos’è il prompt engineering

Il prompt engineering è la pratica di progettare e affinare gli input testuali (i prompt) forniti a un foundation model per ottenere output più accurati, pertinenti e coerenti, senza modificare i pesi del modello. È l’approccio più rapido ed economico per adattare un modello a un compito: non richiede training né infrastruttura dedicata, a differenza del fine-tuning. Su AWS i foundation model si consumano tipicamente tramite Amazon Bedrock, che espone modelli di più provider dietro un’unica API; il prompt engineering è quindi trasversale al modello scelto e resta valido anche cambiando modello.

Un prompt efficace è chiaro, specifico e contestualizzato. Dare istruzioni precise, delimitare il testo di input, indicare il formato di output desiderato e assegnare un ruolo al modello (“agisci come…”) sono leve che riducono ambiguità e hallucination.

System prompt e user prompt

Molti foundation model distinguono due tipi di messaggio. Il system prompt definisce comportamento, persona, tono, vincoli e regole generali validi per l’intera conversazione (es. “Sei un assistente che risponde solo in italiano e in modo conciso”). Lo user prompt contiene la richiesta puntuale del momento. Separare le istruzioni persistenti (system) dalla domanda specifica (user) rende il comportamento più stabile e prevedibile, ed è il punto giusto dove inserire guardrail testuali contro derive di tono o tentativi di prompt injection.

Zero-shot e few-shot

La tecnica zero-shot consiste nel chiedere al modello di svolgere un compito senza fornire esempi: ci si affida alla conoscenza acquisita in fase di pre-training. Funziona bene per compiti comuni e ben descritti.

La tecnica few-shot (in-context learning) inserisce nel prompt alcuni esempi di coppie input→output desiderati prima della richiesta reale. Gli esempi guidano il modello su formato, stile e criterio di risposta, migliorando l’accuratezza su compiti specifici o dal formato rigido. Il caso limite con un solo esempio è il one-shot. Punto chiave: il few-shot non riaddestra il modello, i pesi restano invariati; l’apprendimento avviene solo dentro la finestra di contesto e vale per quella singola invocazione.

Altra tecnica concettuale è il chain-of-thought, che invita il modello a esplicitare i passaggi di ragionamento, utile per problemi logici o multi-step. Aumentare il numero di esempi può migliorare la qualità ma consuma più token di contesto, quindi più costo e latenza.

Parametri di inferenza

Oltre al testo del prompt, l’output dipende dai parametri di inferenza impostati alla chiamata:

  • Temperature: regola la casualità. Valori bassi rendono l’output più deterministico e focalizzato; valori alti aumentano varietà e creatività (ma anche il rischio di risposte incoerenti).
  • Top-p (nucleus sampling): restringe la scelta ai token più probabili la cui probabilità cumulativa raggiunge la soglia p. Valori bassi restringono, valori alti allargano il ventaglio.
  • Top-k: limita la scelta ai k token più probabili a ogni passo di generazione.
  • Max tokens (lunghezza massima): limita la lunghezza dell’output; se troppo basso, la risposta viene troncata.
  • Stop sequences: stringhe che, se generate, interrompono la produzione dell’output.

Temperature, top-p e top-k governano la stessa dimensione — quanta libertà ha il modello nella scelta del token — ma non allungano né accorciano la risposta: la lunghezza è governata da max tokens. Per output fattuali e riproducibili si usano valori bassi; per brainstorming e testi creativi valori più alti.

Trappole tipiche d’esame

  • Adattare un modello a un compito senza costi di training → soluzione: prompt engineering (zero/few-shot), non fine-tuning; il fine-tuning modifica i pesi ed è più costoso e lento.
  • Few-shot descritto come “il modello impara o si riaddestra” → soluzione: falso; i pesi non cambiano, l’in-context learning vale solo per quella singola chiamata.
  • Risposte troppo creative o incoerenti → soluzione: abbassa temperature (ed eventualmente top-p), non ridurre max tokens, che controlla la lunghezza e non la casualità.
  • Output tagliato a metà frase → soluzione: aumenta max tokens; il troncamento dipende dal limite di lunghezza, non dalla temperature.
  • Regole di comportamento valide per tutta la conversazione → soluzione: mettile nel system prompt, invece di ripeterle in ogni user prompt.
  • Compito comune e ben definito che non richiede esempi → soluzione: lo zero-shot è sufficiente; aggiungere few-shot aumenta solo token e costo senza beneficio reale.