17 – Quanto conviene far “ragionare” più a lungo un modello?

Un assistente impiega due secondi e sbaglia. Gli concediamo più tempo: controlla un passaggio, trova l’errore e risponde bene. Sarebbe comodo trasformare questa scena in una regola: più elaborazione, più qualità. Ma il tempo aggiuntivo può anche produrre ripetizioni, nuove ipotesi infondate o una revisione che guasta una risposta corretta.

La domanda di questo episodio è quindi operativa: quanto conviene aumentare il budget di elaborazione dello stesso modello sugli stessi problemi? Per rispondere servono tre misure distinte: qualità verificata, tempo percepito e costo complessivo. “Ragionare” resta una descrizione del comportamento del sistema: il testo prodotto non ci offre accesso diretto e fedele a tutti i suoi processi interni.

In breve

• Il test-time compute è il calcolo impiegato per una richiesta dopo l’addestramento.
• Lo si può aumentare allungando una generazione, esplorando più candidati o verificando le risposte.
• Un limite più alto consente più lavoro: non dimostra che quel lavoro sia utile o venga effettivamente svolto.
• Il confronto deve mantenere fisso l’insieme dei problemi e contare anche errori, timeout e risposte incomplete.
• La scelta utile è il budget che raggiunge gli obiettivi di qualità entro i vincoli di tempo e spesa.

Dove finisce il calcolo aggiuntivo

Nel percorso sequenziale, il sistema produce più passi intermedi prima della risposta finale. Questi possono contribuire ai calcoli successivi, perché entrano nel contesto della generazione. In una ricerca parallela, invece, produce più candidati e li combina o ne seleziona uno. Una terza possibilità investe in verifica: eseguire test, controllare vincoli o confrontare una soluzione con una fonte.

Sono interventi diversi. Cinque risposte concorrenti possono consumare più risorse senza quintuplicare la latenza, se l’infrastruttura le esegue insieme; cinque revisioni in sequenza fanno attendere anche i passaggi precedenti. E un verificatore aggiunge un proprio costo e propri errori. Dire soltanto “abbiamo usato più token” nasconde queste differenze.

Aumentare il budget di inferenza non modifica automaticamente i pesi del modello. Inoltre budget massimo e consumo effettivo vanno registrati separatamente: un modello può fermarsi presto, oppure esaurire il limite senza consegnare una risposta finale. Un parametro commerciale chiamato “alto” non rappresenta una quantità di calcolo confrontabile fra servizi diversi.

Un risultato positivo, con il suo perimetro

Il lavoro s1: Simple test-time scaling, versione del 31 gennaio 2025, presenta il budget forcing: gli autori controllano la durata della generazione intermedia, terminandola oppure prolungandola quando il modello sta per fermarsi. Su AIME24 riportano un aumento dal 50% al 57% con s1-32B.

È un risultato su un modello addestrato e una procedura specifici, non una legge valida per qualsiasi chat. Sette punti percentuali su problemi di competizione non descrivono il beneficio atteso sulla classificazione di documenti o sulla ricerca di una data. Il repository del progetto permette di studiare implementazione e valutazione; riprodurle richiede risorse che il nostro laboratorio aritmetico qui sotto non utilizza.

Quando continuare smette di aiutare

Lo studio Do NOT Think That Much for 2+3=?, ICML 2025, analizza soluzioni ripetute che aggiungono poco ad accuratezza e diversità. Qui il problema è l’efficienza: si può spendere molto per confermare ciò che era già disponibile.

Un’altra situazione è il peggioramento. In Inverse Scaling in Test-Time Compute, 22 luglio 2025, i ricercatori costruiscono compiti in cui una maggiore lunghezza di ragionamento riduce la prestazione. Fra gli esempi ci sono domande di conteggio con dettagli distraenti. Sono casi di valutazione deliberatamente costruiti: dimostrano che il miglioramento automatico non è garantito, non che aumentare il budget sia sempre sbagliato.

Dal punto di vista applicativo distinguerei quindi almeno tre esiti: miglioramento, qualità invariata con costo maggiore, regressione. La media può nasconderli: alcune risposte sbagliate vengono corrette mentre altre, inizialmente giuste, diventano errate. Guardare le transizioni problema per problema aiuta a decidere dove allocare il lavoro.

Prima del confronto: fissare il protocollo

Scegliamo prima un insieme di problemi rappresentativo, con risposte o criteri di valutazione indipendenti dal modello. Manteniamo costanti versione, prompt, documenti, strumenti disponibili e impostazioni di campionamento; variamo una sola politica di budget. Se cambiamo anche il modello, stiamo valutando un altro intervento.

Definiamo in anticipo tre livelli, per esempio breve, medio e lungo, e conserviamo per ogni richiesta identificativo del problema, budget richiesto, token effettivi, risposta finale, durata e spesa. Il tempo va misurato dall’invio alla consegna, distinguendo eventuali code e strumenti. Il costo deve includere candidati scartati, verificatori e tentativi falliti. Non basta contare le parole visibili.

In una prova reale ripeterei ciascun problema più volte per livello, alternando l’ordine delle esecuzioni per ridurre l’effetto del carico. Riporterei distribuzioni e incertezza, oltre a media e percentili. Un insieme piccolo serve a collaudare il metodo; per stimare la qualità di un servizio servono più casi e una composizione simile all’uso previsto.

Esempio svolto: quattro problemi, tre budget

Quanto segue è interamente ipotetico. Non abbiamo eseguito un LLM: costruiamo risposte e consumi per mostrare il confronto. Il peggioramento al budget lungo è inserito appositamente, non osservato. Le risposte attese sono controllabili senza un modello:

• P1: sommare gli interi da 1 a 5. Risposta: 15.
• P2: risolvere 2x + 1 = 7. Risposta: 3.
• P3: trovare il cammino minimo da S a T con archi S→A di peso 2, A→T di peso 6 e S→T di peso 9. Risposta: 8.
• P4: trovare x sapendo che x/6 = 7. Risposta: 42.

Dal breve al medio, P2 e P3 vengono corretti senza perdere successi: si passa da 2/4 a 4/4. Dal medio al lungo, nessun errore residuo viene risolto e P1 diventa sbagliato: 3/4. L’accuratezza è rispettivamente 50%, 100% e 75%. Queste percentuali descrivono soltanto la tabella costruita; non stimano le capacità di un modello.

Assegniamo al budget breve 100, 120, 140 e 160 token di elaborazione e risposta; al medio tre volte quei valori, al lungo nove volte. Per semplicità ipotizziamo 0,01 secondi per token, senza altri ritardi. Fissiamo 200 token di input per problema e tariffe inventate di 1 euro per milione di token di input e 2 euro per milione di token generati. Non sono prezzi di un fornitore.

Per il livello medio il conto è: 800 token di input più 1.560 generati, dunque (800 × 1 + 1.560 × 2) / 1.000.000 = 0,00392 euro. Il costo per risposta corretta è spesa totale divisa per successi: circa 0,00092; 0,00098; 0,00339 euro ai tre livelli. Il denominatore deve includere soltanto i successi verificati, ma il numeratore include tutte le richieste.

Il breve costa meno per successo, ma lascia irrisolta metà dei casi. Se il requisito fosse almeno 90% su questa tabella, soltanto il medio lo soddisferebbe. Se fosse necessario rispondere entro due secondi per ogni caso, il medio non sarebbe utilizzabile con i tempi ipotizzati. La convenienza dipende anche dal requisito: la metrica economica da sola non decide.

Una piccola prova verificabile

Il seguente Python usa solo la libreria standard ed è stato eseguito per verificare i conti. Analizza i dati inventati appena descritti, non chiama modelli né misura latenza reale. L’ultima colonna esprime il costo per successo moltiplicato per mille, per renderlo leggibile: è un cambio di unità, non una previsione su mille richieste reali.

from statistics import mean
# Dati INVENTATI: nessuna chiamata a un modello.
gold = [15, 3, 8, 42]
answers = [
    [15, 2, 7, 42],
    [15, 3, 8, 42],
    [14, 3, 8, 42],
]
base_tokens = [100, 120, 140, 160]
for name, factor, pred in zip(
    ['breve', 'medio', 'lungo'], [1, 3, 9], answers
):
    tokens = [factor * t for t in base_tokens]
    # Tempo ipotetico: 0,01 secondi per token.
    seconds = [0.01 * t for t in tokens]
    correct = sum(a == b for a, b in zip(pred, gold))
    # Prezzi inventati: input 1, output 2 EUR/milione.
    # Input fisso: 200 token per problema.
    cost = (4 * 200 + 2 * sum(tokens)) / 1_000_000
    print(name, correct, f'{mean(seconds):.1f}s',
          f'{cost:.5f} EUR',
          f'{1000 * cost / correct:.3f} EUR/1000 ok')
    assert len(pred) == len(gold) == len(tokens)
assert sum(a == b for a, b in zip(answers[0], gold)) == 2
assert sum(a == b for a, b in zip(answers[1], gold)) == 4
assert sum(a == b for a, b in zip(answers[2], gold)) == 3

Si ottengono 0,920; 0,980; 3,387 euro per mille successi equivalenti. Cambia una risposta o un consumo e osserva come cambia il rapporto. Se nessuna risposta fosse corretta, il costo per successo non sarebbe finito: un analizzatore destinato a dati reali dovrebbe gestire esplicitamente quel caso.

Il testo dei passaggi non è una scansione del pensiero

In Reasoning Models Don’t Always Say What They Think, maggio 2025, i ricercatori inseriscono suggerimenti nei prompt e studiano se il modello ne dichiara l’influenza. Nei contesti esaminati, il testo dei passaggi spesso non rivela l’uso del suggerimento. Una spiegazione può quindi essere utile da controllare senza rappresentare fedelmente tutte le cause della risposta.

Per il nostro confronto separiamo tre domande: la conclusione è corretta? I passaggi dichiarati sono validi? La descrizione spiega fedelmente il processo che ha causato l’esito? La prima può essere verificata con le risposte attese; la seconda richiede controlli dei passaggi; la terza richiede esperimenti ulteriori. Né lunghezza né tono sicuro risolvono queste verifiche.

Una decisione utile, oltre il budget unico

Una possibile politica è partire con un budget contenuto e aumentarlo solo per classi di problemi che, nei test, traggono beneficio dalla revisione. Il criterio di escalation va validato: la frase “non sono sicuro” non è una misura affidabile della difficoltà. Un test fallito, un vincolo violato o un controllo documentale mancante possono offrire segnali operativi più concreti.

Anche questa politica va provata su problemi nuovi: scegliere a posteriori il budget migliore conoscendo la risposta attesa produce un vantaggio irrealistico. Conviene separare casi usati per progettare la regola e casi usati per valutarla, includendo costo dell’escalation e tempo totale. Per un compito privo di informazioni essenziali, più generazione può non colmare il vuoto: può servire recuperare una fonte o chiedere il dato mancante.

Una checklist pratica

• Ho confrontato gli stessi problemi con la stessa versione del modello?
• Registro consumo effettivo, timeout, latenza e costo di tutti i tentativi?
• Quanti errori vengono corretti e quante risposte corrette peggiorano?
• Il guadagno supera l’incertezza e rispetta i vincoli del servizio?
• La politica di escalation è stata verificata su casi nuovi?

Il budget migliore compra verifiche e soluzioni utili entro i limiti del servizio. Va scelto misurando gli esiti, non contando quanto a lungo il modello parla.

DALLA MIA BIBLIOTECA

• Sebastian Raschka — Sviluppare Large Language Model. Costruire da zero LLM su misura. Per comprendere generazione e componenti di un modello; gli studi specifici sul budget di inferenza sono citati sopra.

Per approfondire

• Muennighoff e colleghi — s1, arXiv v1, 31 gennaio 2025; codice e materiali originali.
• Xingyu Chen e colleghi — Do NOT Think That Much for 2+3=?, ICML 2025.
• Gema e colleghi — Inverse Scaling in Test-Time Compute, 22 luglio 2025.
• Yanda Chen e colleghi — Reasoning Models Don’t Always Say What They Think, 8 maggio 2025.
• Nella collana: 01, benchmark e misure; 09, latenza e costo; 16, accelerare il decode.

← Torna al percorso Dentro l’IA