L'evoluzione dei sistemi di memoria per l'AI: da RAG a LLM Wiki
Un large language model non ricorda nulla tra una sessione e l'altra. Per risolvere questo problema siamo passati attraverso tre generazioni di sistemi di memoria completamente diversi: RAG, Agentic File Search e LLM Wiki. Ti spiego cosa ha funzionato, cosa no, e dove siamo arrivati.
Un large language model non ricorda. Ogni volta che apri una nuova conversazione, il modello repart da zero: nessuna memoria di quello che hai discusso ieri, nessuna conoscenza accumulata nel tempo. È come parlare con qualcuno che soffre di amnesia totale a ogni riavvio.
Questo problema fondamentale, quello della statelessness dei modelli, ha spinto la comunità AI a costruire sistemi di memoria esterna. E in soli tre anni siamo passati da soluzioni molto tecniche e fragili a qualcosa di sorprendentemente elegante. Vale la pena ripercorrere questo percorso, perché capire dove siamo arrivati aiuta a capire perché l'approccio attuale funziona.
Il problema della memoria esterna
Prima di entrare nelle soluzioni, è utile chiarire il problema. Un LLM riceve in input del testo (il contesto), lo elabora, e produce output. Tutto quello che "sa" per quella sessione è nel contesto. Quando la sessione finisce, tutto scompare.
Per costruire sistemi che abbiano memoria persistente, dobbiamo costruire fuori dal modello un sistema di storage e recupero. Come lo costruiamo determina cosa il modello è capace di fare. La qualità dell'architettura di memoria è, in molti casi, più importante della qualità del modello stesso.
Prima generazione: RAG (2022)
Il RAG, che sta per Retrieval-Augmented Generation, è nato intorno al 2022 ed è ancora oggi molto diffuso. Funziona così.
Prendi i tuoi documenti (PDF, TXT, pagine web, qualsiasi formato testuale), li spezzi in blocchi di testo (i "chunk"), e converti ogni blocco in un vettore numerico usando un modello specifico chiamato embedding model. Ogni vettore è essenzialmente una lista di numeri che rappresenta il significato del testo in uno spazio matematico ad alta dimensione. Tutti questi vettori finiscono in un database vettoriale.
Quando arriva una domanda, la domanda stessa viene convertita nello stesso tipo di vettore. Il sistema cerca nel database i vettori più "vicini" a quello della domanda (quindi i testi con il significato più simile), recupera i blocchi di testo originali corrispondenti, li unisce alla domanda originale, e manda il tutto al modello come contesto. Il modello risponde basandosi su quel contesto.
NotebookLM di Google funziona esattamente così: carichi documenti, li trasforma in vettori, e poi puoi fare domande sui contenuti.
Il problema del RAG è che funziona bene per domande dirette ma inizia a scricchiolare su quesiti complessi. I chunk perdono contesto: taglia un paragrafo a metà e il significato cambia. Le cross-reference tra documenti diversi diventano invisibili al sistema. E soprattutto, il sistema non impara nel tempo: ogni query riparte da zero, non c'è accumulo di conoscenza.
Seconda generazione: Agentic File Search
Con l'arrivo degli agenti AI capaci di usare tool, è emerso un approccio completamente diverso.
L'idea è semplice: invece di costruire un database vettoriale, usi il file system del tuo computer come base di conoscenza. Cartelle, sottocartelle, file markdown. L'agente AI, invece di fare una ricerca vettoriale, naviga il file system come farebbe un essere umano: apre una cartella, legge i titoli dei file, decide quali aprire, legge i contenuti, segue i riferimenti verso altri file.
Questo approccio è quello che usano tutti i coding agent moderni (Claude Code, OpenCode e simili): la memoria dell'agente è fatta di file markdown in cartelle strutturate, e l'agente decide autonomamente cosa leggere in base a quello che sta cercando.
I vantaggi sono sostanziali rispetto al RAG. Non serve nessun database vettoriale da mantenere. La struttura gerarchica delle cartelle diventa essa stessa parte del ragionamento del modello. Si possono lanciare agenti in parallelo che esplorano la knowledge base simultaneamente. E si possono seguire i riferimenti tra documenti in modo naturale, cosa che il RAG non riesce a fare.
Il limite è che ogni query ricostruisce la conoscenza da zero: l'agente deve esplorare ogni volta il file system, leggere i documenti rilevanti, sintetizzare. Funziona bene, ma ha un costo in termini di token (e quindi di tempo e denaro) che scala con la dimensione della base di conoscenza.
Terza generazione: LLM Wiki
Ed eccoci al punto più interessante. Andrej Karpathy, in un post su X che ha fatto molto discutere, ha descritto un approccio che risolve i limiti delle due generazioni precedenti.
L'intuizione è questa: invece di fare derivare la conoscenza ogni volta (RAG) o di esplorare file grezzi ogni volta (Agentic File Search), perché non compilare la conoscenza una volta sola in una wiki strutturata, e poi mantenerla aggiornata in modo incrementale?
Una wiki non è un'idea nuova. Wikipedia è una wiki. Le wiki aziendali sono ovunque. Il problema delle wiki tradizionali è sempre stato lo stesso: funzionano benissimo quando sono piccole, diventano impossibili da mantenere quando crescono. Aggiornare 30 file coerentemente, fare pulizia dei link rotti, tenere traccia di cosa è cambiato: sono lavori noiosi che gli esseri umani tendono ad abbandonare.
Ma un LLM non si annoia. Puoi chiedergli di aggiornare 30 file e 20 riferimenti in una singola passata, e lo fa senza dimenticare nulla. Questo cambia completamente l'equazione.
L'architettura si articola su tre livelli.
Il primo livello sono i dati grezzi: articoli, paper, PDF, immagini, tutto quello che raccoglie nel tempo nella cartella raw/. È la fonte di verità, non modificata.
Il secondo livello è la wiki vera e propria: file markdown strutturati che l'LLM genera e aggiorna in modo incrementale. Ogni documento ha backlink verso gli altri documenti correlati, c'è un file index.md che funge da indice generale, e un file log.md che tiene traccia di tutte le modifiche fatte nel tempo.
Il terzo livello è lo schema: un file di istruzioni (di solito CLAUDE.md o simile) che dice all'agente come comportarsi, quali convenzioni seguire, come strutturare le cartelle.
Le tre operazioni fondamentali sono: ingest (aggiungere nuova conoscenza alla wiki a partire dai documenti grezzi), query (fare domande all'agente che naviga la wiki per rispondere), e linting (manutenzione periodica per trovare inconsistenze, link rotti, informazioni obsolete).
Il risultato è una base di conoscenza che cresce nel tempo, è leggibile sia da un umano che da un LLM, e non richiede embedding o database vettoriali. Funziona tutto su file locali.
Perché questo approccio vince
La cosa che mi ha convinto di questo approccio è il concetto di "conoscenza compilata". Con il RAG, ogni domanda deve attraversare l'intero pipeline di retrieval. Con l'Agentic File Search, ogni domanda richiede una navigazione dei file grezzi. Con la LLM Wiki, la conoscenza è già organizzata, già sintetizzata, già collegata: l'agente fa meno lavoro per rispondere meglio.
C'è anche un vantaggio che sottovalutavo all'inizio: la trasparenza. Puoi aprire Obsidian, navigare il grafo dei documenti, capire esattamente come il modello ha organizzato la conoscenza. Non è una black box come il database vettoriale.
Karpathy stesso ha detto che una parte crescente del suo utilizzo degli LLM non è nella manipolazione di codice, ma nella manipolazione di conoscenza salvata come markdown. Questo mi sembra il segnale più chiaro di dove stiamo andando.
Nel prossimo post mostro nel dettaglio come costruire questa wiki da zero, con Obsidian e le istruzioni di Karpathy.