I modelli di chat AI possono aumentare i costi attraverso un’inutile verbosità

I popolari modelli di chat AI sprecano enormi quantità di token pagati in discorsi inutili. I modelli interessati sanno effettivamente di stare facendo questo, ma non possono fermarsi.

I Large Reasoning Models (LRM) come ChatGPT-5 e Google Gemini addebitano di più per il ragionamento – che consiste nel risolvere un problema passo dopo passo, il che utilizza molto più potenza di calcolo rispetto alla semplice previsione della prossima parola. Il processo di ragionamento simulato richiede più tempo e costa di più per essere eseguito; di conseguenza, gli utenti finiscono per pagare per quel “tempo di pensiero extra”.

Tuttavia, se hai utilizzato recentemente un modello di linguaggio avanzato, potresti aver notato che la tua allocazione di token viene spesso spesa in discorsi inutili e ridondanti, piuttosto che concentrarsi sulla risoluzione dei problemi che stai ponendo al modello. Ciò può manifestarsi come eccessiva adulazione, risposte prolisse e/o ridondanti – o anche una sorta di “discorso inutile”, come se l’AI fosse stata colta di sorpresa e stesse cercando di uscire da una situazione imbarazzante.

Naturalmente, preferiremmo che i nostri LLM ammettessero la sconfitta, seguissero o offrissero percorsi alternativi, o richiedessero chiarimenti. Ma anche ottenere che un’AI di questo tipo ammetta di non conoscere una risposta è una sfida considerevole di per sé.

Nel frattempo, gli utenti con piani più bassi o gratuiti possono scoprire di aver bruciato i loro token a un ritmo veloce, indipendentemente da quanto fossero mirati o economici le loro query e interazioni, perché l’AI stessa ama parlare; e, in questo caso, parlare non è gratuito.

Insalata di parole

Riguardo al suddetto “discorso inutile”, una nuova collaborazione accademica offre una spiegazione e una soluzione, proponendo che gli LLM con capacità di ragionamento tendano a bruciare i token quando si bloccano in un ciclo di “insalata di parole” – uno stato di confusione in cui il processo di ragionamento si perde in vicoli ciechi ricorsivi – a spese dell’utente*.

I ricercatori dietro il nuovo articolo hanno scoperto che una parte significativa dei token elaborati in un tipico LLM consiste in ripetizioni e ridondanze – e che il modello stesso sembra capire di essere in difficoltà, anche se non è in grado di fermare il costoso ciclo.

L’articolo afferma:

‘Mostriamo che una parte significativa di questi token sono ripetizioni inutili – che chiamiamo “insalata di parole” – che esauriscono il budget di decodifica senza aggiungere valore. È interessante notare che gli LRM sono consapevoli quando sono intrappolati in questi cicli: gli stati nascosti dei token che seguono ogni blocco di ragionamento presentano modelli che ci consentono di rilevare il comportamento di “insalata di parole” in tempo reale attraverso un classificatore lineare a un solo strato.

‘Una volta rilevato, un semplice taglio seguito da un prompt di rigenerazione diretto produce notevoli risparmi di lunghezza con una perdita di qualità minima.’

La soluzione offerta dal nuovo lavoro è un intervento che può interrompere il processo di ragionamento errato di un LLM in modo rapido, senza la necessità di includere dati di training o di apportare danni che possono derivare da fine-tuning. Il framework, intitolato WordSaladChopper, è stato rilasciato pubblicamente su GitHub.

Sebbene il lavoro iniziale si concentri su DeepSeek e varianti come le voci della serie Qwen e Llama, l’articolo afferma che il comportamento indesiderato è probabilmente applicabile a un’ampia gamma di modelli di ragionamento simili (inclusi popolari offerte API-only come ChatGPT e Google Gemini).

Come nota l’articolo, precedenti offerte come Demystifying Long Chain-of-Thought Reasoning in LLMs e Small Models Struggle to Learn from Strong Reasoners utilizzano anch’esse il piccolo numero di modelli di ragionamento Chain-of-Thought (CoT) pubblicamente disponibili per stabilire un problema più ampio all’interno di questa classe di modelli^†:

‘[Gli LRM] tendono a sprecare un’enorme quantità di budget di decodifica, semplicemente ripetendosi alla lettera, con variazioni leggere, o impegnandosi in un’enumerazione infinita di casi fino a quando tutto il budget non è stato speso – noi chiamiamo questo comportamento Insalata di parole, un termine spesso usato per prendere in giro i portavoce pubblici per le loro risposte lunghe e piene di jargon che alla fine mancano di sostanza o di significato chiaro.

‘La colonna “Originale” nella tabella sottostante mostra che, quando rispondiamo a GPQA-Diamond, osserviamo che il 55%+ dei token generati dai modelli DeepSeek-R1-Distill sono contrassegnati come “token di insalata di parole”, che non aggiungono valore da un punto di vista semantico.’

La quota di token di output identificati come ridondanti semanticamente quando si risponde a GPQA-Diamond. WordSaladChopper riduce questo sovraccarico da oltre il 55% a meno del 6% in tutti i modelli DeepSeek-R1-Distill testati, affermano gli autori. Fonte

Gli autori notano che i tentativi di abbreviare i processi di ragionamento preservando la qualità delle risposte è diventata una sottocorrente forte nella letteratura di ricerca, in particolare lungo-corto (L2S); e osservano inoltre che, sebbene i loro obiettivi di progetto siano simili a quelli di alcune iniziative precedenti, il loro è il primo a offrire una soluzione ad hoc che non richiede intervento nel processo di training, editing del modello o altri possibili impatti sull’architettura di base di un LLM; e a questo proposito, ritengono che il loro approccio dovrebbe diventare ampiamente utilizzato tra i sistemi applicabili^†:

‘È nostro onesto parere che [WordSaladChopper] – o un componente simile – sia un must per tutte le applicazioni LRM con l’esperienza utente in mente ‘

L’articolo è intitolato WordSaladChopper: i modelli di ragionamento sprecano una grande quantità di budget di decodifica in ripetizioni inutili, consapevoli, e proviene da sei ricercatori dell’Università del Minnesota, dell’Università di Rice, del Stevens Institute of Technology e di Lambda, Inc.

Considerazioni precedenti

Per tenere traccia della tendenza degli LRM a ripetersi, gli autori hanno diviso l’output dei modelli in blocchi ovunque ci fossero interruzioni di riga doppie, quindi hanno verificato quanto ogni blocco fosse simile a quelli precedenti:

Stima della quota di blocchi di ragionamento contrassegnati come insalata di parole in due temperature di decodifica (τ = 0,0, 0,6). Il classificatore contrassegna un blocco come ‘insalata di parole’ quando assomiglia molto a una parte precedente dell’output del modello, suggerendo ripetizione piuttosto che progresso. I risultati mostrano che questo comportamento è diffuso tra set di dati e dimensioni di modello.

Se un blocco era troppo simile, veniva contrassegnato come “insalata di parole” (effettivamente una ripetizione inutile).

I ricercatori notano che, una volta che un modello entra nel modo “insalata di parole”, è molto improbabile che ne escano senza aiuto esterno, rimanendo invece nel costoso ciclo fino a quando il budget di decodifica dell’utente non sarà esaurito^††:

‘Inutile dire che ciò presenta un problema catastrofico per gli utenti, poiché una sezione di pensiero idealmente molto più breve è ora massimizzata con ripetizioni inutili. Quindi l’utente paga essenzialmente il costo massimo per una risposta (probabilmente) sbagliata, mentre sopporta la latenza end-to-end più lunga.’

Quota di blocchi di insalata di parole che appaiono prima e dopo il punto di taglio (ovvero il momento in cui l’output ripetitivo inizia a dominare). La maggior parte delle ripetizioni si verificano dopo questo punto, mostrando che una volta che un modello entra in un ciclo di insalata di parole, raramente si riprende senza intervento.

Gli autori raccontano la loro sorpresa quando scoprirono che gli LRM con capacità di ragionamento mostravano segni di essere consapevoli del loro stato di “insalata di parole”. Tuttavia, è questa consapevolezza, e il modo in cui entra nello stato di ragionamento probabile del modello, che consente un sistema di intervento:

‘La leggerezza di questo classificatore lineare apre la porta a una rilevazione in tempo reale, dove possiamo intervenire efficacemente con operazioni diverse per affrontare modelli intrappolati in cicli di insalata di parole.’

Metodo

Per rilevare la presenza di insalata di parole durante l’inferenza, gli autori hanno addestrato un semplice classificatore lineare che funziona sullo stato nascosto di ogni token a nuova riga.

Ogni blocco che si verificava dopo che il modello era entrato in un ciclo di ripetizione veniva trattato come insalata di parole, con questo taglio (chiamato punto di taglio) utilizzato per etichettare i dati di training. Sono stati generati 1000 tracce di ragionamento utilizzando il benchmark S1, e ogni traccia è stata divisa in blocchi separati da una nuova riga.

Schema concettuale per WordSaladChopper. Durante la generazione, lo stato nascosto in ogni token a nuova riga viene analizzato per rilevare segmenti ripetitivi. Una volta che due blocchi di insalata di parole vengono contrassegnati in sequenza, la generazione viene interrotta. Un prompt di rigenerazione fisso viene quindi aggiunto, consentendo al modello di continuare e completare la risposta senza superare il budget.

Se un blocco era troppo simile a uno precedente, veniva etichettato come insalata di parole. Una volta identificata la prima ripetizione sostenuta, tutti i blocchi successivi venivano etichettati come insalata di parole per riflettere la persistenza di questi cicli.

Il classificatore è stato implementato come un singolo strato completamente connesso e addestrato sugli stati nascosti dei token di chiusura del blocco finale del blocco del trasformatore. Un classificatore separato è stato addestrato per ogni modello, utilizzando questi dati, e non è stato eseguito alcun fine-tuning durante la valutazione.

Dati e test

L’addestramento e l’inferenza hanno utilizzato quattro GPU NVIDIA A100 (80G VRAM), sotto l’ottimizzatore Adam, con un tasso di apprendimento di 1×10^-2, per 50 epoche.

I set di dati di valutazione sono stati ‘Matematica della scuola elementare’ 8000, noto anche come GSM8K; MATH-500; GPQA-DIAMOND; e AIME25 (2025).

I modelli testati sono stati DeepSeek-R1-Distill-Qwen-1.5B; DeepSeek-R1-Distill-Qwen-7B; e DeepSeek-R1-Distill-Llama-8B, tutti sotto licenza MIT.

Le metriche utilizzate sono state Precisione e AUROC.

Precisione e AUROC del classificatore di insalata di parole su Qwen-7B in quattro benchmark e due temperature di decodifica. I punteggi alti confermano che l’inizio della ripetizione può essere rilevato in modo affidabile dallo stato nascosto del token di nuova riga.

Tra i risultati rappresentati qui, gli autori commentano:

‘[La tabella dei risultati sopra] mostra che il classificatore lineare è estremamente preciso nel rilevare i blocchi di insalata di parole; tuttavia [la tabella dei risultati sotto] dimostra che il prompt di rigenerazione aiuta a recuperare la precisione del compito persa a causa della semplice interruzione.’

Precisione di Qwen-7B in ogni benchmark a τ = 0,6, confrontando le prestazioni prima dell’insalata di parole (Originale), dopo la interruzione (Tagliato) e dopo l’applicazione della rigenerazione (Rigenerato). I guadagni dalla rigenerazione sono modesti ma costanti, recuperando le prestazioni pre-ciclo nella maggior parte dei casi.

Nella tabella dei risultati sotto possiamo vedere che WordSaladChopper ha migliorato o preservato la precisione mentre riduceva notevolmente la lunghezza dell’output del modello, fino al 57%:

Quando WordSaladChopper viene utilizzato con la decodifica avida (τ = 0), riduce la lunghezza dell’output del modello, a volte di più della metà, mentre mantiene la precisione uguale o leggermente migliore, una prestazione che rimane costante tra diversi modelli e compiti (AIME25 è omesso a causa dei risultati prevedibilmente instabili in questo setting).

I guadagni più grandi si sono verificati nelle risposte più lunghe, in particolare su GPQA-Diamond, dove quasi la metà del testo è stata rimossa senza danneggiare le prestazioni. Sotto possiamo vedere risultati simili quando è stata aggiunta casualità durante la generazione:

A temperatura più alta (τ = 0,6), WordSaladChopper continua a ridurre gli output del 10-30%, con precisione che rimane stabile o leggermente migliorata in tutti i modelli e benchmark (i risultati di AIME25 sono stati mediati per ridurre la varianza).

Qui la precisione è rimasta stabile, con output più brevi raggiunti. In generale, il sistema ha continuato a funzionare anche quando le risposte del modello sono diventate più ripetitive; e gli autori notano che, poiché il classificatore controlla solo un token per frase, funziona estremamente veloce, anche quando utilizzato durante la generazione live.

L’articolo osserva che ulteriori strategie in future ricerche lungo queste linee potrebbero trarre vantaggio dall’assegnazione al modello di un piccolo budget di rigenerazione dopo l’intervento; applicazione continua di un sistema di tipo WordSaladChopper su rigenerazioni; e forzando un token “fine del pensiero” sul modello, per esigere la sua migliore risposta attuale.

Infine, i ricercatori commentano la qualità dell’attuale stato dell’arte nella valutazione dei modelli di ragionamento, con un tono critico^†:

‘È nostra onesta opinione che molti metodi di ragionamento efficienti appaiano efficaci in parte perché le attuali valutazioni dei modelli di ragionamento hanno molto spazio per il miglioramento.

‘Se svilupperemo suite di valutazione più complete in futuro – cosa che sicuramente faremo – ci aspettiamo di vedere molti metodi di ragionamento efficienti fallire, o comportarsi molto diversamente rispetto ai loro modelli LRM standard.’

Conclusione

A scala raggiunta da sistemi leader come ChatGPT, anche piccoli spostamenti nel consumo di risorse degli utenti possono avere importanti implicazioni per l’infrastruttura, la logistica e i costi. Ciò rende l’efficienza una priorità condivisa sia per i fornitori che per l’intera comunità di ricerca.

Se implementato, il nuovo e leggero sistema proposto nell’articolo (che deve essere addestrato su ogni nuova architettura di modello) potrebbe prevenire la bruciatura inutile di token – che può dare all’utente l’impressione che il fornitore stia “spremando” la loro allocazione in modo prodigo o ingannevole. In realtà, il fornitore trae vantaggio fornendo output utili piuttosto che ridondanti, che costa lo stesso, in termini di calcolo, come un’insalata di parole.

* Sebbene non lo faremo qui, ciò si estende anche ai modelli ospitati localmente, che possono essere aziendali oltre che hobbistici, e in cui le perdite di elettricità e di produttività dell’insalata di parole possono essere un fattore degno di nota.

^† Come al solito, ogni enfasi è degli autori, e non mia. Dove applicabile, le loro citazioni inline sono state convertite in collegamenti ipertestuali da me.

^†† Qui dobbiamo riconoscere che framework e API possono assegnare un “sotto-budget” alle query, in modo che una query non sia necessariamente in grado di bruciare l’intera allocazione giornaliera di token – ma ciò non è una pratica comune, né comunemente discussa tra i fornitori di sola API.

^††† Non sono generalmente disposto ad adottare l’uso degli autori di ‘LRM’, poiché non è attualmente un’abbreviazione mainstream, quindi userò altre terminologie in questo articolo, se necessario.

Pubblicato per la prima volta giovedì 6 novembre 2025