C'è un problema fondamentale con l'intelligenza artificiale che usi ogni giorno: non ricorda niente. Ogni volta che apri una nuova conversazione con ChatGPT, Claude o Gemini, tutto il contesto accumulato nella sessione precedente—le decisioni prese, i dati condivisi, le conclusioni raggiunte—viene cancellato. Riparti da zero. Sempre.
Questo non è un bug. È un limite architetturale dei Large Language Models. Un LLM non "impara" dalle tue conversazioni. Non aggiorna i suoi parametri quando gli parli. Elabora il testo che gli metti davanti in quel momento—il cosiddetto context window—e produce una risposta. Finita la sessione, tutto evapora.
Per anni, la risposta standard a questo problema è stata il RAG (Retrieval-Augmented Generation)—un sistema che recupera documenti rilevanti e li inserisce nel prompt. Ha funzionato, ha risolto problemi reali, ma oggi mostra tutti i suoi limiti. Il mercato si è evoluto, e con esso sono emersi due approcci più sofisticati: l'Agentic File Search e la LLM Wiki, un pattern reso celebre da Andrej Karpathy che sta ridefinendo il concetto stesso di "memoria" per l'intelligenza artificiale.
In questo articolo analizziamo tutti e tre i metodi in profondità: come funzionano, dove eccellono, dove falliscono e—soprattutto—perché il RAG non è più sufficiente. Alla fine, una guida pratica per costruire la tua LLM Wiki personale con Obsidian.
RAG: Retrieval-Augmented Generation
Il RAG è stato il primo metodo ampiamente adottato per dare memoria esterna a un'intelligenza artificiale. Il concetto è intuitivo: invece di aspettarsi che il modello "sappia tutto," gli dai accesso a una libreria esterna da consultare al momento del bisogno. Un esempio perfetto e di uso quotidiano di un sistema RAG è NotebookLM di Google, che ti permette di caricare i tuoi documenti e farli leggere e riassumere all'intelligenza artificiale.
Come funziona
Un sistema RAG opera in due fasi distinte. La prima è una fase di preparazione offline: i documenti della knowledge base vengono spezzati in frammenti (chunk) di 256-1024 token ciascuno, ogni chunk viene convertito in un vettore numerico (embedding) che ne cattura il significato semantico, e questi vettori vengono salvati in un database vettoriale come Pinecone, Weaviate o Qdrant. In pratica, i tuoi documenti diventano una mappa matematica del significato.
La seconda fase è l'interrogazione in tempo reale: quando l'utente fa una domanda, il sistema converte anche la domanda in un vettore, cerca i chunk più semanticamente simili nel database, li recupera e li inserisce nel prompt insieme alla domanda originale. Il modello genera la risposta basandosi sia sulla sua conoscenza interna che sui documenti recuperati.
Punti di forza
• Aggiornamento in tempo reale. Puoi aggiornare la knowledge base senza riaddestrare il modello. Aggiungi un documento, viene indicizzato, ed è immediatamente disponibile per le query.
• Riduzione delle allucinazioni. Le risposte sono ancorate a documenti reali, non generate "dal nulla." Questo rende il RAG particolarmente affidabile per contesti dove la precisione è critica.
• Privacy dei dati. I tuoi documenti restano nella tua infrastruttura. Solo i chunk rilevanti vengono inviati al modello al momento della query.
• Costo contenuto. Rispetto al fine-tuning, implementare un RAG è significativamente più economico e veloce.
Punti di debolezza
• Dipendenza dalla qualità del retrieval. Se il sistema recupera i chunk sbagliati, il modello produrrà risposte sbagliate—con la falsa sicurezza di chi cita fonti. Il RAG può essere confidentemente errato.
• Nessuna comprensione strutturale. Il RAG tratta ogni chunk come un'unità indipendente. Non capisce le relazioni tra i documenti, non costruisce una mappa concettuale, non identifica contraddizioni tra fonti diverse.
• Limite del context window. C'è un limite fisico a quanti chunk puoi inserire nel prompt. Per knowledge base molto grandi, informazioni potenzialmente rilevanti vengono sistematicamente escluse.
• Nessuna memoria tra sessioni. Un sistema RAG non "impara" dalle interazioni precedenti. Ogni query è indipendente—il sistema non ricorda cosa hai chiesto ieri o quali conclusioni hai raggiunto.
Il RAG ha rappresentato un salto in avanti enorme quando è stato introdotto. Ma oggi, con l'evoluzione dei modelli e delle esigenze, i suoi limiti strutturali sono diventati evidenti. È un sistema che cerca informazioni ma non le comprende—e questa differenza, in contesti complessi, si sente.
Agentic File Search: il RAG che ragiona
L'Agentic File Search rappresenta l'evoluzione naturale del RAG. Se il RAG classico segue un flusso lineare e meccanico (query, retrieval, risposta), l'Agentic File Search introduce qualcosa di fondamentalmente diverso: un loop di ragionamento attivo in cui l'agente decide autonomamente come, cosa e quando cercare.
Come funziona
La differenza fondamentale è l'introduzione del pattern ReAct (Reason + Act). L'agente analizza la domanda e decide quale informazione serve; se la domanda è complessa, la scompone in sotto-domande. Poi sceglie quale strumento utilizzare—potrebbe essere un file search, una query SQL a un database, una chiamata API o una ricerca web. Non è vincolato a un singolo tipo di fonte.
A questo punto esamina i risultati ottenuti. Se sono insufficienti, contraddittori o incompleti, riformula la ricerca e riesegue. Può fare più passaggi (multi-hop) fino a ottenere una risposta soddisfacente. Solo quando ha raccolto abbastanza contesto, genera la risposta finale.
In pratica, prodotti come la File Search di OpenAI nell'Assistants API incarnano questo approccio: carichi i tuoi file, OpenAI gestisce chunking, embedding, indicizzazione e re-ranking, e il modello decide autonomamente quando e come consultare quei file durante la conversazione. È essenzialmente "RAG as a Service" con un layer di intelligenza in più.
Punti di forza
• Ragionamento multi-step. Può rispondere a domande complesse che richiedono informazioni da fonti diverse, cross-referenziando i risultati automaticamente.
• Auto-correzione. Se il primo tentativo di ricerca non produce risultati utili, l'agente riformula la query e riprova—un comportamento impossibile nel RAG classico.
• Multi-sorgente. Non è limitato a un singolo database vettoriale. Può combinare file search, web search, database SQL e API in un'unica pipeline di ricerca.
• Setup semplificato. Nelle implementazioni managed, non devi gestire database vettoriali, pipeline di embedding o logica di retrieval. Carichi i file e l'AI fa il resto.
Punti di debolezza
• Costo computazionale. Ogni loop di ragionamento consuma token. Una query complessa può richiedere 3-5 passaggi di retrieval, moltiplicando il costo rispetto a un RAG single-pass.
• Latenza. Il ragionamento iterativo richiede tempo. Per applicazioni che necessitano di risposte in millisecondi, l'Agentic File Search può essere troppo lento.
• Vendor lock-in. Le implementazioni managed ti legano all'ecosistema del provider. I tuoi file sono nei loro server, indicizzati con i loro sistemi.
• Nessuna memoria persistente. Come il RAG, anche l'Agentic File Search non costruisce una comprensione cumulativa. Ogni sessione riparte da zero.
L'Agentic File Search risolve il problema più grande del RAG—la ricerca passiva e lineare—ma ne eredita il limite più profondo: non costruisce conoscenza nel tempo. È un ricercatore brillante che ogni sera dimentica tutto quello che ha scoperto durante il giorno.
LLM Wiki: la conoscenza che si accumula
Ed eccoci al terzo approccio—quello che cambia le regole del gioco. La LLM Wiki parte da un'intuizione resa celebre da Andrej Karpathy, ex direttore AI di Tesla e co-fondatore di OpenAI: invece di cercare informazioni ogni volta che servono (retrieval), perché non compilarle una volta sola in una base di conoscenza strutturata che cresce nel tempo?
Il concetto è questo: tratti la tua knowledge base come un codebase, l'LLM come un programmatore che la mantiene, e uno strumento come Obsidian come il tuo IDE. Il risultato è un "secondo cervello" che non cerca informazioni—le possiede, le organizza e le collega automaticamente.
Come funziona
L'architettura della LLM Wiki si basa su tre livelli. Il primo è il livello Raw (le fonti): una cartella dove salvi i materiali grezzi—articoli, PDF, appunti, trascrizioni, pagine web. Questi file sono immutabili e rappresentano il tuo archivio di fonti primarie.
Il secondo è il livello Wiki (la conoscenza compilata), il cuore del sistema. L'LLM processa i file grezzi e li "compila" in note strutturate con frontmatter YAML (titolo, tag, fonti, data di aggiornamento), riassunti, collegamenti interni (wikilink) e indici tematici. Ogni nuova fonte aggiunta arricchisce e aggiorna le note esistenti, creando una rete di conoscenza che si espande organicamente.
Il terzo è il livello Query (le risposte). Quando fai una domanda, l'LLM non cerca in un database vettoriale—naviga il wiki che ha costruito lui stesso. Parte dall'indice, segue i link alle note rilevanti, sintetizza le informazioni e produce risposte contestualizzate e cross-referenziate. La differenza con il RAG è sostanziale: il modello non sta "cercando" informazioni frammentate, sta consultando una struttura di conoscenza che ha costruito e che comprende.
Punti di forza
• Conoscenza che si accumula. A differenza del RAG e dell'Agentic File Search, la LLM Wiki impara nel tempo. Ogni nuova fonte viene integrata con le note esistenti, creando connessioni che prima non esistevano. Il sistema diventa più intelligente più lo usi.
• Comprensione strutturale. Il wiki non è una collezione di chunk isolati—è una rete di concetti collegati. L'LLM può identificare contraddizioni tra fonti, lacune nella conoscenza, e relazioni non ovvie tra argomenti diversi.
• Future-proof. Tutto è basato su file Markdown in locale. Non sei legato a nessun provider, nessun database proprietario, nessun abbonamento. Se domani un servizio cloud chiude, i tuoi file restano esattamente dove sono.
• Zero costo infrastrutturale. Non servono database vettoriali, server di embedding o pipeline di indicizzazione. Servono solo file di testo e un LLM.
Punti di debolezza
• Setup iniziale impegnativo. Configurare il sistema—la struttura delle cartelle, il file di istruzioni, le regole di formattazione—richiede tempo e competenza tecnica iniziale.
• Non è real-time. A differenza del RAG, che può indicizzare un documento in secondi, la LLM Wiki richiede un processo di "compilazione" che impiega più tempo. Non è adatta per scenari dove i dati cambiano ogni minuto.
• Dipendenza dalla qualità delle istruzioni. Il wiki è buono quanto le istruzioni che dai all'LLM. Se il file di configurazione è scritto male, il wiki sarà disorganizzato e poco utile.
• Scalabilità limitata. Per knowledge base con milioni di documenti, la LLM Wiki non è praticabile. È pensata per knowledge base personali o di team—centinaia o migliaia di documenti, non milioni.
La LLM Wiki rappresenta un cambio di paradigma: non cerchi informazioni—le possiedi. Ogni giorno che passa, il sistema accumula conoscenza, identifica pattern e produce risposte sempre più precise. È la differenza tra consultare un'enciclopedia e avere un esperto del tuo dominio che studia costantemente per te.
Confronto diretto: quale metodo scegliere
I tre approcci non sono in competizione diretta—rispondono a esigenze diverse. La scelta dipende dal contesto, dal volume di dati e dal tipo di intelligenza che ti serve.
Sul piano del setup e della complessità, il RAG richiede infrastruttura dedicata (database vettoriale, pipeline di embedding, logica di retrieval custom). L'Agentic File Search, nelle versioni managed come quella di OpenAI, è il più semplice da avviare: carichi i file e funziona. La LLM Wiki richiede una configurazione iniziale più articolata ma poi diventa un sistema autosufficiente che si mantiene da solo.
Per quanto riguarda la memoria persistente, questa è la discriminante più importante. Solo la LLM Wiki offre vera memoria che si accumula nel tempo. RAG e Agentic File Search ripartono da zero a ogni sessione—possono accedere ai tuoi documenti, ma non "ricordano" le ricerche precedenti né le conclusioni raggiunte.
Sul fronte dei costi, il RAG ha costi infrastrutturali ricorrenti per l'hosting del database vettoriale. L'Agentic File Search ha costi per token potenzialmente elevati a causa del reasoning multi-step. La LLM Wiki ha un costo vicino allo zero—file Markdown in locale e il costo dell'LLM che utilizzi per la manutenzione.
Infine, la scalabilità. Il RAG scala a milioni di documenti senza problemi. L'Agentic File Search gestisce bene migliaia di file. La LLM Wiki è ottimale per centinaia o poche migliaia di documenti—è pensata per profondità di comprensione, non per volume.
In sintesi: se hai un database aziendale enorme con dati che cambiano frequentemente, il RAG resta la scelta giusta. Se hai bisogno di un assistente che ragiona su documenti complessi senza voler gestire infrastruttura, l'Agentic File Search è la via più rapida. Ma se vuoi costruire un "secondo cervello" che diventa più intelligente nel tempo e che ti dà un vantaggio competitivo reale nella gestione della conoscenza, la LLM Wiki è il futuro.
Guida pratica: come creare la tua LLM Wiki con Obsidian
Ora che conosci la teoria, passiamo alla pratica. L'approccio che segue è basato sul gist ufficiale di Andrej Karpathy e adattato per un utilizzo immediato con Obsidian. Puoi avere un sistema funzionante in meno di 30 minuti.
Step 1: Installa Obsidian e crea il vault
Scarica Obsidian (gratuito) e crea un nuovo vault. Un vault non è altro che una cartella sul tuo computer dove vivranno tutti i tuoi file Markdown. Niente cloud, niente abbonamenti—tutto in locale, sotto il tuo controllo.
Step 2: Crea la struttura delle cartelle
All'interno del vault, crea questa struttura di cartelle:
/il-tuo-vault/
CLAUDE.md
raw/
wiki/
concepts/
topics/
index.md
outputs/
assets/
La cartella raw/ è dove salvi le fonti grezze (articoli, PDF, appunti)—non vanno mai modificate. wiki/ è dove l'LLM scrive e mantiene le note strutturate. outputs/ è dove l'LLM salva le risposte alle tue domande. E assets/ raccoglie immagini e file allegati.
Step 3: Scrivi il file CLAUDE.md
Questo è il cuore del sistema. Il file CLAUDE.md è il "manuale di istruzioni" che dice all'LLM come comportarsi. Deve definire il ruolo dell'agente ("Sei un Knowledge Base Engineer, il tuo compito è mantenere un wiki strutturato"), le regole per le cartelle (quali sono read-only, quali sono di scrittura), gli standard di formattazione (frontmatter YAML obbligatorio con titolo, tag, fonti e data), e i comandi operativi per gestire l'ingestione di nuove fonti e la manutenzione del wiki.
Step 4: Collega l'LLM
Per far funzionare il sistema hai diverse opzioni. La più potente è Claude Code da terminale: apri il terminale nella cartella del vault e lancia l'agente, che leggerà il CLAUDE.md e opererà direttamente sui tuoi file. In alternativa, plugin Obsidian come Smart Connections o Copilot permettono di integrare un LLM direttamente nell'interfaccia senza mai uscire dall'app. Per chi vuole massima privacy, è possibile far girare un modello locale come Llama o Mistral usando Ollama.
Step 5: Inizia a popolare il wiki
Salva un articolo o un PDF nella cartella raw/ e chiedi all'LLM di processarlo. L'agente leggerà il contenuto, estrarrà i concetti chiave, creerà o aggiornerà le note nel wiki, aggiungerà i link interni e aggiornerà l'indice. La conoscenza è ora parte permanente del tuo sistema—e da domani, ogni nuova fonte aggiunta si integrerà con quello che c'è già, creando connessioni che nessun sistema RAG potrebbe generare.
Tips & Tricks per sfruttare al massimo la LLM Wiki
Dopo aver configurato la base, ecco come trasformare la tua LLM Wiki da "utile" a "indispensabile."
Il primo consiglio è usare il plugin Dataview. Una volta che i tuoi file hanno frontmatter YAML coerente, Dataview ti permette di creare dashboard dinamiche dentro Obsidian—visualizzare tutte le note per tag, per data, per fonte. È come avere un database SQL dentro il tuo wiki.
Secondo: installa l'Obsidian Web Clipper. L'estensione browser ufficiale di Obsidian ti permette di salvare qualsiasi pagina web direttamente nella cartella raw/ del tuo vault con un click, convertendo automaticamente l'HTML in Markdown strutturato.
Terzo: sfrutta la Graph View. Obsidian ha una vista a grafo integrata che visualizza tutte le connessioni tra le tue note. Più il wiki cresce, più il grafo diventa denso e rivela cluster tematici e connessioni non ovvie tra argomenti che pensavi fossero completamente scollegati.
Quarto: fai "lint" regolarmente. Chiedi periodicamente all'LLM di controllare la salute del wiki—trovare note orfane, link rotti, contraddizioni tra fonti e lacune nella copertura tematica. È manutenzione preventiva che tiene il sistema pulito e affidabile.
Quinto: parti piccolo. Non cercare di costruire l'intero sistema in un giorno. Inizia con 5-10 fonti, lascia che il wiki prenda forma organicamente, poi scala gradualmente. La tentazione di importare tutto subito è forte, ma il risultato sarà un wiki caotico. La qualità della struttura conta più del volume.
Infine: tratta il raw/ come sacro. Mai modificare i file nella cartella raw/. Sono le tue fonti primarie, il tuo archivio immutabile. Se scopri un errore in una fonte, aggiungi una nota correttiva nel wiki—non toccare l'originale.
La LLM Wiki non è uno strumento che impari a usare in un giorno. È un sistema che cresce con te. Dopo un mese di utilizzo costante, avrai una knowledge base che nessun sistema RAG potrà mai replicare—perché contiene non solo informazioni, ma le connessioni tra quelle informazioni, curate e verificate nel tempo.
Conclusione
Il problema della memoria nell'intelligenza artificiale è uno dei temi più importanti—e meno discussi—dell'intero settore. Mentre il mercato si concentra su modelli sempre più potenti, la vera differenza tra chi usa l'AI in modo superficiale e chi la usa in modo strategico sta nella gestione della conoscenza.
Il RAG ha fatto il suo tempo come standard dominante. Resta valido per applicazioni enterprise su larga scala, ma i suoi limiti strutturali—assenza di memoria persistente, comprensione frammentata, dipendenza dal retrieval—lo rendono inadeguato per chi ha bisogno di un'intelligenza che evolve nel tempo. L'Agentic File Search è un passo avanti significativo nel ragionamento, ma eredita lo stesso limite fondamentale: non accumula conoscenza.
La LLM Wiki, come proposta da Karpathy e dalla community che si sta formando attorno a questo pattern, rappresenta un cambio di paradigma. Non cerchi informazioni—le possiedi, organizzate in un sistema che diventa più intelligente ogni giorno. Per imprenditori, marketer, ricercatori e sviluppatori, è un vantaggio competitivo concreto: mentre gli altri ricominciano da zero a ogni conversazione, tu hai un secondo cervello che accumula, collega e sintetizza.
Il futuro non appartiene a chi ha il modello più potente. Appartiene a chi ha la memoria più strutturata.
Fonti: Andrej Karpathy - LLM Wiki Pattern (2025-2026), OpenAI Documentation (2025-2026), Databricks Technical Blog (2025), NVIDIA Developer Blog (2025), Towards Data Science (2025), Obsidian.md Documentation.
Vuoi una strategia ottimizzata per il tuo brand?