Temperatura e Top-p: Perché l'AI a Volte è Creativa e a Volte No

Temperatura 0 non è deterministico. Temperatura alta non rende il codice migliore. E i modelli più avanzati — o1, o3, GPT-5, Claude con thinking — non ti lasciano nemmeno toccarla.

Se hai mai messo temperature: 0 in una chiamata API pensando "così ottengo sempre la stessa risposta", o alzato la temperatura sperando in codice più creativo, questo articolo è per te. Perché il parametro più usato nelle API dei LLM è anche il più frainteso.

Il Termometro dell'AI

Quando un LLM genera testo, ad ogni step produce un punteggio per ciascun token nel suo vocabolario — circa 128.000 valori chiamati logit. Questi punteggi grezzi vengono poi convertiti in probabilità tramite la funzione softmax.

La temperatura interviene prima della softmax. Divide tutti i logit per un valore T:

probabilità(token_i) = e^(logit_i / T) / somma(e^(logit_j / T))

L'analogia più onesta? Pensa a un equalizzatore audio. I logit sono il segnale grezzo. La temperatura è la manopola del contrasto. Girarla verso il basso rende il segnale più netto — un picco domina, tutto il resto sparisce. Girarla verso l'alto appiattisce tutto — il rumore di fondo sale allo stesso livello del segnale.

Vediamolo con numeri reali. Prendiamo tre token con logit 2.0, 1.0, 0.5:

Temperatura	Token A (logit 2.0)	Token B (logit 1.0)	Token C (logit 0.5)	Effetto
0.01	~100%	~0%	~0%	Greedy: vince sempre A
0.5	84.4%	11.4%	4.2%	Quasi deterministico
1.0	62.9%	23.1%	14.0%	Distribuzione "naturale"
2.0	48.1%	29.2%	22.7%	Più piatta: anche C ha una chance

A temperatura 0.01, il modello è una catena di montaggio: sceglie sempre il token più probabile. A temperatura 2.0, è una jam session: anche token con punteggi bassi possono emergere.

I range variano per provider:

Provider	Range	Default
OpenAI	0 - 2	1.0
Anthropic	0 - 1	1.0
Google	0 - 2	1.0

Anthropic limita il massimo a 1 — una scelta di design che dice molto sulla loro filosofia: per Claude, la distribuzione "naturale" è già il massimo di casualità che dovresti volere.

Top-p: Il Nucleo Adattivo

La temperatura agisce su tutti i token nel vocabolario. Ma nella maggior parte dei casi, il 99% dei token ha probabilità trascurabile. Perché sprecare campionamento su token che non avranno mai senso?

Top-p (o nucleus sampling) prende un approccio diverso. Invece di modificare le probabilità, taglia la coda: ordina i token dal più al meno probabile e ne seleziona solo quelli necessari a raggiungere una probabilità cumulativa pari a p.

L'idea viene dal paper "The Curious Case of Neural Text Degeneration" di Holtzman et al. (2019), pubblicato a ICLR 2020. L'intuizione chiave: il numero di token "ragionevoli" cambia ad ogni step di generazione.

Pensa a un buffet. Se il modello sta completando import numpy as, c'è praticamente un solo piatto sul tavolo: np. Il nucleo è minuscolo — un token, probabilità 99.9%. Ma se sta scrivendo l'inizio di un commento dopo # TODO:, i piatti ragionevoli sono decine. Il nucleo si espande da solo.

Questo è il vantaggio chiave di top-p: è adattivo. Nucleo piccolo quando il modello è sicuro, grande quando è incerto. Non devi fare niente — si regola da solo in base al contesto.

Top-k: Il Cugino Meno Flessibile

Esiste anche top-k, che seleziona semplicemente i K token con probabilità più alta, indipendentemente dalla distribuzione. Con top_k=50, il modello considera sempre 50 token — che il contesto sia ambiguo o cristallino.

Il problema è evidente: se il modello è sicuro al 99.5% su un token, perché considerarne altri 49? E se la distribuzione è piatta su 200 token ragionevoli, perché limitarsi a 50?

Top-k è un taglio fisso. Top-p è un taglio intelligente. Per questo top-p ha di fatto sostituito top-k nella maggior parte delle API moderne.

Temperatura + Top-p: Usane Uno Solo

Questo è il consiglio che tutti i provider danno e quasi nessuno segue.

OpenAI, nella documentazione ufficiale:

"We generally recommend altering temperature or top_p but not both."

Anthropic è ancora più diretta:

"You usually only need to use temperature."

Con i modelli Claude recenti, se provi a specificare entrambi i parametri nella stessa chiamata API, ricevi un errore. Non un warning — un errore.

Il motivo è logico: temperatura e top-p agiscono entrambi sulla distribuzione di probabilità. Combinarli crea interazioni non intuitive. Una temperatura bassa con un top-p alto, o viceversa, produce comportamenti difficili da prevedere e ancora più difficili da debuggare.

La regola pratica: usa temperatura come parametro principale. Ricorri a top-p solo se hai bisogno specificamente del suo comportamento adattivo. Non usarli mai insieme.

Il Cheat Sheet: Cosa Usare per Cosa

Dopo anni di community consensus e test empirici, questi sono i valori che funzionano:

Use Case	Temperatura	Top-p	Perché
Code generation	0.2	0.1	Precisione sintattica, meno allucinazioni
Code comments / docs	0.3	0.2	Leggera varietà nel linguaggio naturale
Chatbot conversazionale	0.5	0.5	Bilanciamento coerenza/naturalezza
Exploratory coding	0.6	0.7	Più soluzioni alternative
Creative writing	0.7	0.8	Massima varietà lessicale

Il consensus della community dev: 0.3 è lo sweet spot per il codice. Abbastanza basso da evitare allucinazioni, abbastanza alto da non produrre output identici ad ogni chiamata.

In una chiamata API, la configurazione tipica per un coding assistant:

response = client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=4096,
    temperature=0.3,
    messages=[{"role": "user", "content": prompt}]
)

const response = await openai.chat.completions.create({
  model: "gpt-4.1",
  temperature: 0.2,
  messages: [{ role: "user", content: prompt }],
});

Niente top-p. Niente top-k. Solo temperatura. Semplice.

Mito 1: Temperatura 0 È Deterministica

Questo è probabilmente il malinteso più diffuso. Metti temperature: 0, ti aspetti output identici per lo stesso input, e... a volte li ottieni, a volte no.

Anche OpenAI lo dice esplicitamente nella documentazione: "Determinism is not guaranteed."

Le cause sono almeno cinque, tutte legate all'implementazione hardware e software:

Aritmetica floating-point. Le GPU fanno calcoli in virgola mobile. L'ordine in cui sommano i numeri può variare tra una esecuzione e l'altra, e con numeri molto vicini (come capita spesso con logit quasi identici) il risultato cambia.

Parallelismo GPU. I moderni transformer distribuiscono i calcoli su migliaia di core. L'ordine di completamento non è deterministico — e l'ordine influenza il risultato finale per via dell'aritmetica floating-point.

Batch processing. Il tuo prompt potrebbe essere raggruppato con quelli di altri utenti per efficienza. La composizione del batch influenza i calcoli interni.

Routing Mixture-of-Experts. Modelli come GPT-4 e Mixtral usano architetture MoE dove diversi "esperti" gestiscono diversi token. Il routing può variare tra le esecuzioni.

Multi-server. La tua richiesta potrebbe finire su server diversi con GPU diverse, ciascuna con le sue peculiarità hardware.

Temperatura 0 rende l'output molto più consistente. Ma deterministico al 100%? No. Se hai bisogno di riproducibilità perfetta, devi salvare gli output — non fidarti del parametro.

Mito 2: Temperatura Alta Genera Codice Creativo

L'intuizione sembra logica: più temperatura, più variazione, più creatività nel codice. In pratica, è il contrario.

Quando alzi la temperatura per la generazione di codice, non ottieni soluzioni alternative brillanti. Ottieni token improbabili che si infilano dove non dovrebbero: nomi di variabili che non esistono nello scope, chiamate a metodi API inventati, parentesi che si chiudono nel posto sbagliato.

Il codice ha una grammatica rigida. A differenza del linguaggio naturale, dove un sinonimo inaspettato può arricchire il testo, nel codice un token "creativo" è quasi sempre un token sbagliato. array.mappa() non è la versione creativa di array.map() — è un bug.

Per ottenere soluzioni di codice diverse, la strategia efficace è cambiare il prompt, non la temperatura. Chiedi esplicitamente un approccio funzionale, un pattern diverso, un'ottimizzazione specifica. Il modello esplorerà lo spazio delle soluzioni nel modo giusto — attraverso la comprensione del contesto, non attraverso il dado truccato del sampling.

Mito 3: Temperatura e Top-p Vanno Usati Insieme

Ne abbiamo già parlato sopra, ma vale la pena ribadire perché è un errore incredibilmente comune nel codice di produzione.

Scorrendo repository pubblici su GitHub, si trovano migliaia di chiamate API con parametri tipo temperature=0.7, top_p=0.9. Gli sviluppatori li impostano entrambi "per sicurezza", come chi mette sia la cintura sia le bretelle.

Ma qui non è ridondanza — è interferenza. La temperatura modifica la forma della distribuzione. Top-p taglia la distribuzione modificata. Il risultato combinato è una distribuzione che non corrisponde né all'intenzione della temperatura né a quella di top-p. Se alzi la temperatura per ottenere più varietà ma top-p taglia i token meno probabili, i due parametri si annullano parzialmente.

Scegli un approccio. Uno solo.

Mito 4: I Reasoning Models Si Usano Come Gli Altri

I reasoning model puri — o1, o3 di OpenAI — non supportano il parametro temperatura. Claude con extended thinking lo accetta, ma deve essere fissato a 1.0: qualsiasi altro valore genera errore. GPT-5, che è un modello general-purpose con ragionamento integrato, nella sua modalità di default non permette di modificarlo. Gemini 2.5 Pro e Flash con thinking seguono la stessa logica.

Non è una limitazione tecnica. È una scelta di design.

I reasoning models funzionano attraverso catene di ragionamento multi-step interne. Il modello genera decine o centinaia di token di "pensiero" prima di produrre la risposta. Ogni step di ragionamento deve essere coerente con i precedenti.

Se l'utente potesse impostare temperature: 0, tutti i percorsi di ragionamento collasserebbero in uno solo — quello più probabile token per token. Ma il percorso localmente più probabile ad ogni step non è necessariamente quello che porta alla risposta globalmente migliore. È come navigare con il GPS sempre seguendo la strada più dritta: a volte la deviazione di 2 km ti fa risparmiare 20 minuti.

Se invece potesse impostare una temperatura alta, i singoli step di ragionamento diventerebbero rumorosi, e l'intera catena logica andrebbe a pezzi.

La temperatura nei reasoning models è calibrata internamente durante il training. Il modello sa quando essere "esplorativo" (all'inizio del ragionamento, quando sta valutando gli approcci) e quando essere "preciso" (nei passaggi finali, quando sta convergendo sulla risposta). Questa calibrazione è parte dell'architettura — non è un parametro che ha senso esporre all'utente.

Il Futuro: AdapT e Min-p

L'idea che la temperatura debba essere un singolo valore fisso per l'intera generazione è già vecchia. Due approcci stanno emergendo per superarla.

AdapT: Temperatura Dinamica per Token

Presentato ad AAAI 2024, AdapT assegna una temperatura diversa ad ogni token durante la generazione. Token "challenging" — quelli dove il modello è incerto — ricevono temperatura più alta per esplorare più opzioni. Token "confident" — quelli dove il modello sa cosa fare — ricevono temperatura più bassa per non introdurre rumore.

Il risultato: +13.6% su HumanEval pass@15 (misurato con CodeGeeX-13B) rispetto alla temperatura fissa. Per un benchmark di code generation, è un salto significativo. E il bello è che non richiede modifiche al modello — è una tecnica di inference-time che si applica sopra qualsiasi LLM.

Min-p: La Nuova Frontiera del Sampling

Min-p è un approccio ancora più elegante. Invece di un taglio fisso (top-k) o cumulativo (top-p), introduce una soglia dinamica che scala con la confidenza del modello.

Funziona così: se il token più probabile ha probabilità 0.9, min-p con soglia 0.1 tiene solo i token con probabilità almeno 0.09 (10% del massimo). Se il token più probabile ha probabilità 0.3, la soglia scende a 0.03 — permettendo più token nel nucleo.

È adattivo come top-p, ma con un meccanismo più pulito e prevedibile. Già integrato in HuggingFace Transformers e vLLM, e presentato come oral paper a ICLR 2025 — il che dice molto sulla direzione della ricerca.

Cosa Significa per Chi Sviluppa

La temperatura non è un parametro da copiare da Stack Overflow e dimenticare. È il punto dove il tuo codice incontra la stocasticità del modello, e vale la pena capire cosa succede.

Per le API in produzione: temperatura 0.2-0.3 per il codice, 0.5 per le conversazioni. Non combinare con top-p. Testa con lo stesso prompt almeno 5-10 volte per verificare la consistenza dell'output.

Per i reasoning models: non toccare la temperatura. Se il provider non espone il parametro, è intenzionale. Se lo espone e lo ignora, è perché la calibrazione interna funziona meglio di qualsiasi valore tu possa scegliere.

Per chi fa self-hosting: guarda min-p. Se usi vLLM o HuggingFace, è già disponibile e potrebbe darvi output migliori di qualsiasi combinazione temperatura/top-p.

Per il debug: se lo stesso prompt produce output diversi con temperature: 0, non è un bug del tuo codice. È la natura del sistema. Progetta di conseguenza — log degli output, retry con validazione, fallback.

Il parametro più semplice delle API LLM è in realtà una finestra su come funziona il sampling neurale. E come per molte cose nell'AI: la realtà è più sfumata, più interessante e più utile della semplificazione.

Fonti: