Ragionamento nascosto nei token riempitivo: cosa mostra davvero lo studio sui punti nei prompt

Uno studio osserva calcoli intermedi nei token riempitivo di alcuni LLM. Il risultato riguarda la monitorabilità interna, non una scorciatoia per leggere ogni ragionamento del modello.

Scritto da Daniel Vedovato · Revisionato il 21 luglio 2026

Fonte primaria

Articolo preparato con assistenza AI, verificato e revisionato da Daniel Vedovato.

Un output vuoto può comunque contenere lavoro del modello

Se un modello risponde correttamente dopo una lunga sequenza di punti, spazi o token privi di significato per il lettore, la prima reazione è pensare che non ci sia nulla da osservare. Il paper Reading Between the Dots, depositato su arXiv il 3 luglio 2026, mostra un caso più interessante: in alcuni modelli open weight, quei token riempitivo possono accompagnare una computazione interna strutturata anche quando il testo visibile non espone alcun passaggio di ragionamento.

Il risultato riguarda DeepSeek V3 e Kimi K2 su quattro famiglie di compiti: recupero di fatti, composizione numerica parallela, manipolazione di stringhe e calcolo nel contesto. Non è uno studio che dimostra di poter leggere la mente di qualunque LLM. È una prova sperimentale che, in un insieme delimitato di modelli e task, la traccia interna può restare analizzabile perfino quando la catena di pensiero non compare nell’output.

Che cosa hanno misurato gli autori

Gli autori osservano tre segnali. Primo, l’attenzione collega la domanda, la regione di token riempitivo e la risposta finale. Secondo, le letture con logit lens mostrano l’emergere di fatti recuperati e poi di valori composti negli strati finali. Terzo, il trapianto della KV cache nelle posizioni riempitivo può scambiare causalmente l’output tra esempi.

La parte più utile del lavoro è una pipeline non supervisionata che usa solo hidden state e recupera valori intermedi con accuratezza dichiarata tra 80% e 95%, secondo un giudice LLM, senza etichette di ground truth né addestramento aggiuntivo. Questo sposta la discussione da “il ragionamento non è stampato” a “quale parte della computazione resta misurabile nel tracciato completo del modello”.

Una cautela essenziale: accuratezza del decoder, validità del giudice e generalizzazione fuori dai task studiati restano da verificare. I risultati non autorizzano a usare un’attivazione interna come prova definitiva dell’intenzione o della sicurezza di un modello.

Perché il chain-of-thought visibile non basta come controllo

Molti sistemi trattano la spiegazione testuale del modello come un audit log. È utile, ma non è affidabile come unica sorgente. Una spiegazione può essere abbreviata, generata dopo la decisione, omessa per ragioni di prodotto o diversa dalla computazione che ha portato alla risposta. Il paper esamina proprio un limite estremo: la superficie testuale può non rivelare il contenuto del calcolo.

Per chi costruisce agenti, la lezione è operativa. Un controllo serio deve separare almeno tre livelli:

Nei prodotti reali la seconda riga resta la più utile. Log immutabili, conferme umane prima di azioni irreversibili, test avversariali e limitazione dei permessi danno garanzie più immediate della meccanistic interpretability. La terza riga può diventare una verifica aggiuntiva per modelli critici, non un sostituto dei controlli di esercizio.

Dove questa ricerca può essere utile

La prima applicazione plausibile è la ricerca sulla monitorabilità. Se una tecnica trova valori intermedi senza sapere in anticipo quali valori cercare, può aiutare a individuare rappresentazioni inattese o percorsi di calcolo anomali. Potrebbe anche servire a confrontare versioni di un modello quando un cambiamento di comportamento non emerge da benchmark sintetici.

Un secondo uso è il debugging. In un task ben definito, confrontare hidden state di esempi corretti e falliti può suggerire dove il recupero di un fatto o la composizione di un valore devia. È più vicino al lavoro di diagnostica che a una dashboard pronta per un SOC: richiede accesso ai pesi, strumenti di analisi e ipotesi verificabili.

Cosa non afferma il paper

Non afferma che tutti i token apparentemente vuoti contengano ragionamento utile. Non dimostra che il metodo funzioni su modelli proprietari, agenti con tool, testi lunghi o problemi aperti. Non stabilisce nemmeno che un tracciato leggibile sia automaticamente sicuro: un modello può avere una computazione interpretabile e continuare a produrre una decisione sbagliata o dannosa.

È inoltre importante non trasformare il lavoro in una promessa di sorveglianza totale. Misurare internal state introduce costi, complessità e nuove domande: quale dato viene conservato, chi può ispezionarlo, come si evita di scambiare correlazione per causa? Le tecniche descritte includono una verifica causale tramite KV-cache transplant, ma ogni nuova applicazione richiederebbe lo stesso livello di rigore.

Come valutarlo in pratica

Chi vuole riprodurre o estendere il risultato dovrebbe iniziare da task con risposta verificabile e dataset separato. Servono una baseline che osservi solo l’output, metriche chiare per il decoder e un controllo causale, non soltanto visualizzazioni persuasive. La domanda da porre non è “riesco a vedere qualcosa nelle attivazioni?”, ma “questa osservazione predice o modifica in modo affidabile un comportamento misurabile?”.

Per sistemi che agiscono su infrastrutture, codice o dati, il vantaggio immediato resta un altro: progettare l’agente affinché ogni azione importante lasci tracce esterne verificabili. La ricerca sui token riempitivo amplia l’orizzonte della monitorabilità, ma non elimina la necessità di audit trail, policy e rollback.

Verdetto

Lo studio è interessante perché indebolisce un’assunzione diffusa: se non vediamo la catena di pensiero, non possiamo osservare il processo. Nei casi studiati, parte del processo emerge da stati interni e può essere decodificata. È un risultato promettente per interpretabilità e sicurezza, da leggere con precisione sui suoi confini sperimentali. Il passo successivo non è dichiarare risolto l’audit degli LLM, ma verificare se il metodo mantiene valore quando il modello, il task e il contesto diventano più realistici.