Radar · 27/07/2026 · ricerca

TAKC: quando il RAG classico non basta sui task analitici lunghi

AWS documenta il Task-aware Knowledge Compression (TAKC), un approccio che pre-comprime intere basi documentali in rappresentazioni specifiche per ogni tipo di analisi, con cache a più livelli di fedeltà e routing automatico delle query. Il post include un’implementazione open-source.

Se hai provato a far analizzare a un assistente centinaia di documenti per un task complesso (riassumere i fattori di rischio in 200 relazioni trimestrali, trovare contraddizioni fra 50 contratti), hai visto dove il RAG classico si rompe. Recupera frammenti rilevanti per ogni singola domanda, ma perde i collegamenti fra documenti o riempie la finestra di contesto oltre il leggibile. Come raccontavamo il 23 luglio, quando a leggere è un agente la qualità del retrieval si sposta dal singolo documento all’insieme.

TAKC sposta il lavoro a monte. Invece di recuperare al volo per ogni query, comprime l’intera base per il tipo di task, tiene pronte le versioni compresse in cache a più livelli e instrada ogni domanda al livello giusto. La lettura pesante avviene una volta, le query successive viaggiano sulle rappresentazioni preparate.

È il prossimo passo pratico dopo RAG, con codice aperto e blueprint testato, non un’idea da paper. Il fatto che AWS lo documenti con un repo distribuibile lo rende provabile.

Nel dettaglio

Il RAG tradizionale funziona così: prendi una domanda, la trasformi in un vettore, cerchi nel database i frammenti di documento più simili, li incolli nel prompt e lasci che il modello risponda. Per “trova il paragrafo che menziona la clausola 4.2” va benissimo. Ma quando il task è analitico e copre decine o centinaia di documenti, due cose si rompono.

La prima: il retrieval tira dentro troppo materiale o troppo poco. Troppo, e superi la finestra di contesto del modello. Troppo poco, e perdi i collegamenti fra documenti che servono a costruire la risposta.

La seconda: ogni query ripete lo stesso lavoro. Se cento analisti fanno domande simili sugli stessi documenti, il sistema recupera e rilegge ogni volta da zero.

TAKC cambia il punto in cui il lavoro viene fatto. Pre-processa l’intera base documentale per tipi di task specifici, comprime i documenti in rappresentazioni orientate al compito, le memorizza in cache a livelli di fedeltà crescenti (dalla sintesi all’estrazione dettagliata) e instrada ogni query al livello appropriato.

Pensa a un analista che legge tutto una volta, prepara schede riassuntive per tema e tiene sia le schede che gli originali a portata di mano. Quando arriva una domanda, decide se la sintesi basta o serve il documento intero. Il lavoro di lettura pesante si fa una volta, non per ogni query.

Il post di AWS descrive l’architettura completa, i livelli di cache e il routing, e fornisce un’implementazione open-source distribuibile sulla propria infrastruttura.

I limiti. Il post viene da AWS, che ha interesse a promuovere soluzioni che girano sui suoi servizi. L’implementazione aperta aiuta, ma non abbiamo benchmark indipendenti che confrontino TAKC con RAG tradizionale su task identici. La pre-compressione ha un costo upfront: richiede di conoscere i tipi di task in anticipo e consuma compute prima che la prima query venga fatta. Se i tuoi task sono imprevedibili o cambiano spesso, l’investimento iniziale potrebbe non ripagare. E la compressione introdurrà sempre qualche perdita di informazione: quanto conta dipende dal tuo caso concreto.

Per chi costruisce sistemi su corpus grandi, vale la pena leggere il post e provare il repo. Per chi fa RAG su scale piccole (qualche decina di documenti), il problema che TAKC risolve ancora non si pone. Il playbook su come far leggere documenti lunghi senza tagli silenziosi resta il punto di partenza pratico per chi ci lavora oggi.

Scrivi per cercare fra corso, playbook, skill, paper…