La compressione ottica del contesto è il tentativo più concreto, finora, di aggirare il “tetto” dei token senza stravolgere l’architettura dei modelli. Per capirla bisogna partire proprio da come un LLM spezzetta il testo in unità minime – i famosi token – e da come DeepSeek prova a spenderli meglio.
Indice degli argomenti
Cosa sono i token e perché costano
Quando diciamo “token” stiamo parlando del modo in cui un modello linguistico spezzetta il testo in unità minime – parole, pezzetti di parola, punteggiatura – per poterlo leggere, ricordare e ragionare.
È il suo alfabeto operativo, un po’ come le nostre sillabe. Ogni input e ogni risposta costano token; più token, più costo e latenza. L’ostacolo vero è che per far entrare molti documenti in memoria (il famoso “contesto“) il conto può arrivare a esplodere.
La mossa laterale di DeepSeek: da token testuali a vision token
Fin qui, nulla di nuovo. La novità, molto interessante da un punto di vista tecnologico, è che DeepSeek ha fatto una mossa laterale: invece di rappresentare lunghi pezzi di testo come sequenze di token testuali, li impacchetta in immagini ad alta risoluzione e li fa leggere al modello come “vision tokens“. Il trucco non è tanto l’OCR classico che da immagine torna a testo: qui l’immagine diventa un mezzo di compressione. In pratica si va a mappare una pagina piena di parole su una “lastra” visiva 2D che il modello multimodale sa digerire con molte meno unità rispetto alla sequenza di token testuali equivalente.
Nei test pubblicati, con documenti standardizzati, questa compressione arriva intorno a un ordine di grandezza con una fedeltà di ricostruzione del testo che si aggira sul 96–97%: mille token di testo diventano grossomodo cento “vision token”, e quando serve si può riottenere il testo di partenza quasi senza perdite entro quel rapporto di 10×. Se si prova a spingere a 20×, l’accuratezza scende in modo sensibile, attorno al 60%. I numeri sono chiari nel paper e nel codice che è stato rilasciato.
perché funziona: ridondanza spaziale e densità informativa
Il meccanismo sembra funzionare perché il testo scritto su una pagina ha ridondanze enormi e una struttura spaziale che vale molto in termini di densità informativa: le forme delle parole, gli spazi, l’allineamento, i blocchi, tutto concorre a renderlo “comprimibile” se lo guardi come immagine.
La tokenizzazione testuale, al contrario, tratta ogni subword in fila indiana; una pagina da 1.000 token continua ad avere 1.000 unità da macinare. L’immagine, invece, condensa quel contenuto in un tensore 2D che il vision encoder può riassumere in poche decine o centinaia di embedding, cioè pochi “vision token”, con una perdita controllata. Alla fine è solo un cambio di rappresentazione e, soprattutto, non significa che i token spariscono: restano, ma diventano token “visivi” al posto di quelli “testuali” per una parte del flusso.
Onestamente, se qualcuno parlasse di “obsolescenza dei token” farebbe solo un’opera di marketing creativo. Credo sia più corretto dire che stiamo imparando a spendere meglio il budget di token usando il canale visivo come compressore del contesto.
Impatto pratico: più contesto, meno costi
Forse la vera domanda potrebbe essere: che impatto pratico ha questa idea? Il più tangibile è la gestione di contesti lunghi. Se posso imbustare grosse porzioni di storia della chat o interi documenti in immagini “dense” e farle leggere con 10× meno unità, a parità di budget entro più informazione in memoria, e il modello può rispondere facendo riferimento a molte più pagine.
In termini pratici: meno costo e meno timeout quando è necessario condividere contratti, policy, report tecnici, PDF pieni di tabelle. È questa la ragione per cui si sono accesi i riflettori della comunità tecnica: possiamo “allungare” di fatto la finestra di contesto senza cambiare architettura del modello, semplicemente cambiando come rappresentiamo l’input. Il team DeepSeek lo presenta proprio come “optical context compression” e ha rilasciato modelli e repo di sorgenti.
Limiti della compressione ottica del contesto tra accuracy e overhead
Qui però serve anche mantenere una certa onestà intellettuale.
Oltre il 10×: dove la compressione inizia a fare male
Primo: questi risultati sono misurati su benchmark di documenti, non su qualsiasi cosa si voglia “buttare dentro”. Funzionano molto bene su pagine piene di testo e layout noti; quando si va su codice, lingue miste, formule strane, o si devono preservare formattazioni non banali, il comportamento va testato con cura perché oltre il 10× gli errori crescono e le omissioni diventano più probabili.
Il mito del modello che “pensa per immagini”
Secondo: non c’è una prova che il modello “ragioni meglio” perché legge immagini invece di token testuali. Ragiona magari con più contesto disponibile, che è già un vantaggio enorme, ma il salto cognitivo del “pensare per immagini come noi” è una metafora, non un fatto dimostrato.
Sovraccarico del ramo visivo e compromesso costi-prestazioni
Terzo: si introduce un sovraccarico diverso – serve un encoder visivo e un passaggio di codifica/decodifica – quindi il guadagno reale è il bilancio tra meno token e più calcolo nel ramo visivo; dipende dall’hardware e da come si costruisce il flusso.
Use case reali: RAG, knowledge base e documenti lunghi
Che cosa cambia per chi costruisce soluzioni di Generative AI? Se si gestiscono knowledge base corpose, lunghi log di conversazioni o report di audit con mille riferimenti, questa tecnica può ridurre i costi e, soprattutto, sbloccare use case che prima avevano nella finestra di contesto un potenziale limite. Un esempio pratico potrebbe essere un RAG che, invece di spaccare un PDF in mille chunk testuali, passa al modello una serie di “fogli” compressi visivamente mantenendo layout e informazioni tipografiche utili. Meno frammentazione, più fedeltà al documento, più materiale in memoria con lo stesso budget.
Potrebbe essere verosimile che vedremo prodotti che combinano retrieval standard e rappresentazioni visive per capitoli interi, regolando il livello di compressione come un cursore qualità-prestazioni. Qui, infatti, chi sta studiando e testando la cosa sta convergendo su questa narrativa: 10× vicino al “quasi lossless” per i documenti, oltre si paga in accuratezza e si perde la convenienza di questa strada.
Oltre DeepSeek: futuro della compressione ottica del contesto nei modelli generativi
Forse vale la pena chiarire anche un ultimo aspetto. Se prendo dieci pagine e le ricodifico in immagini, è vero che i token scendono e posso stipare più roba. Ma non è una bacchetta magica: devo scegliere cosa comprimere, con che rapporto, e devo accettare che in alcuni casi un carattere fuori posto o un ritorno a capo sbagliato durante la decodifica potrebbe cambiare il significato di una tabella o di un paragrafo. Alla fine, credo che sia una tecnica interessante (e potente) per estendere il contesto a basso costo, non la fine della tokenizzazione come la conosciamo. Ho in testa un’ultima domanda: in quale direzione si potrebbe andare adesso?
Pipeline ibride tra contesto freddo e reasoning puntuale
Molto probabilmente verso delle pipeline ibride in cui il contesto “freddo” o di riferimento (ad esempio appendici, allegati, lunghi documenti in genere) viene compresso otticamente e tenuto a portata di mano, mentre ciò che serve per il ragionamento puntuale rimane in testo puro.
Servono benchmark, non tweet euforici
Se poi emergeranno evidenze che certi tipi di reasoning beneficiano davvero della rappresentazione visiva – ad esempio perché il modello sfrutta implicitamente layout, prossimità e segnali grafici – lo scopriremo con ulteriori test e benchmark ben fatti e non con tweet euforici.
Per ora mi sento di poter dire che la promessa è soprattutto economica e ingegneristica: meno token, più contesto, costi più bassi e nuove finestre per casi d’uso reali. E questo è già un cambiamento importante.
Ref: DeepSeek-OCR: Contexts Optical Compression https://www.arxiv.org/abs/2510.18234
Partecipa alla community