// data & ai · giornale tecnico MILANO ● LIVE 00:00:00

RAG era sempre stato un workaround temporaneo. Cosa viene dopo

Un’analisi provocatoria: il RAG è un layer di traduzione ad alta latenza, non un vero sistema di memoria. Il prossimo passo potrebbe essere la persistenza dello stato neurale latente.

Questa analisi di Anubhab Banerjee parte da un’osservazione scomoda su come funzionano i sistemi RAG. Dentro la pipeline, un modello produce hidden state ad alta dimensionalità; questi vengono compressi in una stringa di testo, ri-codificati da una rete diversa in un altro spazio vettoriale, memorizzati, poi recuperati e infine ricostruiti in hidden state da un terzo modello. La catena completa — Hidden State, Generate Text, Embed Text, Store Vector, Retrieve Vector, Append Text, Recompute Hidden State — ha sette stadi, ma solo due sono neural-native. Gli altri cinque esistono soltanto perché oggi non sappiamo persistere lo stato neurale stesso. Non è una critica agli ingegneri: con le primitive disponibili, il RAG era la soluzione giusta. Ma è un translation layer, non un sistema di memoria.

Non basta un context window più grande

L’obiezione ovvia è usare un context window da due milioni di token e metterci dentro tutto. Ma i context grandi risolvono la capacità, non la portabilità né la persistenza. Quando un agente passa un task a un altro, o un edge device si sposta tra cluster, l’unità di trasferimento non può essere un prompt da due milioni di token: il costo di banda è punitivo e il ricevente deve comunque rifare un prefill completo per ricostruire lo stato di ragionamento del mittente. È il problema originale, travestito da context più ampio.

Il vincolo della latenza

L’articolo mostra un budget di latenza illustrativo per una singola chiamata RAG: generazione, embedding, I/O di rete, vector search, reranking, ricostruzione del prompt e decoding sommano circa 135 ms di operazioni bloccanti e sequenziali. In un chatbot sono invisibili; in un loop di controllo robotico, un sistema di feedback aptico o un handover tra base station wireless, quei 135 ms sono l’intero budget, speso in plumbing prima che il modello dica qualcosa. Il trasferimento diretto GPU-to-GPU di uno stato latente non rende più veloce ogni passo: li rimuove dalla pipeline.

Perché è difficile

Non significa che “persistere il latent state” sia facile: le rappresentazioni latenti sono model-specific e spesso instabili tra architetture, quindi l’interoperabilità è la vera sfida di ricerca. Servono compatibilità architetturale, precisione allineata, scaling di layer normalization e residui, e allineamento dei positional/rotary embedding. Direzioni come Inductive Latent Context Persistence (ILCP) provano ad affrontare questi problemi, ma oggi funzionano solo sotto stretta compatibilità architetturale, tipicamente modelli identici ai due estremi.

  • Il RAG non sparirà: resterà dove eccelle, come layer di interoperabilità tra macchine con architetture diverse o verso gli umani.
  • La previsione misurata: la memoria testuale diventerà interoperability layer, non il meccanismo primario di memoria degli agenti.
  • Come le fasi precedenti (file, DB relazionali, indici, embedding), ogni “ponte temporaneo” smette di essere l’interfaccia principale.

Fonte: RAG Was Always a Temporary Workaround. What is Next? — https://towardsdatascience.com/rag-was-always-a-temporary-workaround-what-is-next/

Condividi X Facebook LinkedIn WhatsApp Email

// scritto da

Fernando

Hai qualcosa da aggiungere? Unisciti alla discussione.

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Altri dell'autore

dalla stessa firma