Nell'aprile 2026, Andrej Karpathy ha pubblicato un GitHub Gist. In esso descrive un metodo. Lo chiama LLM Wiki.
Quattro team hanno costruito la stessa cosa dopo di lui. Cognition ha costruito DeepWiki. Factory ha costruito AutoWiki. LangChain ha rilasciato OpenWiki. Garry Tan ha rilasciato GBrain.
Il metodo è lo stesso in tutti e quattro i sistemi. Un LLM legge i tuoi documenti sorgente una volta. Scrive le informazioni in pagine markdown. Mantiene le pagine aggiornate quando le sorgenti cambiano. L'agente legge queste pagine. L'agente non rilegge i documenti sorgente per ogni domanda.
Le persone chiamano questi sistemi agent wiki. Questo articolo ti spiega cosa sono. Ti dice cosa ha costruito ogni team. Ti dice i limiti del metodo. E ti dice anche una differenza importante che molti non notano.
L'idea: compilare all'ingestione, non alla query
Il metodo solito per dare a un modello un grande insieme di documenti è il recupero (retrieval). Metti i documenti in un database. Dividi i documenti in parti. Crei embedding per le parti. Per ogni domanda, il sistema trova le parti correlate.
Questo metodo funziona. Ha anche un problema. Il sistema non conserva i risultati. Costruisce ogni risposta dalle parti grezze da capo. La decima risposta non è migliore della prima. Paghi il costo del lavoro dieci volte.
Un agent wiki sposta questo costo. Il modello fa il lavoro una volta, quando legge la sorgente. Scrive i risultati in pagine. Le pagine restano.
Il modello esegue questi passaggi quando arriva una nuova sorgente. Legge la sorgente. Modifica le pagine correlate. Corregge i riassunti. Segna le informazioni che sono in disaccordo con le pagine.
Entrambi i metodi sono corretti. Differiscono in due modi. La prima differenza è quando paghi il costo. La seconda differenza è cosa rimane dopo la domanda.
Ogni sistema ha gli stessi tre strati.
Lo strato 1 sono i documenti sorgente. Sono i tuoi articoli, documenti e repository. Il modello li legge. Il modello non li modifica.
Lo strato 2 è il wiki. Il wiki è in markdown. Il modello scrive tutto il wiki. Il wiki contiene riassunti, pagine per ogni argomento e collegamenti tra le pagine.
Lo strato 3 è il file schema. Questo file dice al modello la struttura del wiki. Dice anche quali compiti eseguire. Il file solito è CLAUDE.md o AGENTS.md. Questo file rende il modello un corretto manutentore del wiki.
Il sistema esegue tre operazioni.
Ingestione: il modello legge una nuova sorgente. Poi il modello scrive i dati in ogni pagina correlata.
Query: fai una domanda al wiki. Puoi scrivere una buona risposta nel wiki come nuova pagina.
Lint: il modello esamina il wiki. Trova informazioni in disaccordo. Trova informazioni troppo vecchie. Trova pagine senza collegamenti.
Perché funziona:
I wiki umani diventano incorretti con il tempo. La causa è specifica. La parte difficile non è leggere le sorgenti. La parte difficile non è avere le idee. La parte difficile è la manutenzione.
La manutenzione ha questi compiti. Devi correggere i collegamenti tra le pagine. Devi mantenere i riassunti corretti. Devi confrontare ogni nuovo documento con le pagine esistenti.
Questo lavoro non si ferma. Il lavoro non dà ricompense. Un team impegnato interrompe questo lavoro per primo. Poi il wiki diventa incorretto. Poi le persone non lo usano.
Un modello fa questo lavoro senza problemi. Il modello non si annoia. Il modello non dimentica un collegamento. Il modello può modificare quindici file in una sola operazione.
L'idea è vecchia. Vannevar Bush descrisse il Memex nel 1945. Il Memex è un archivio personale di documenti con collegamenti tra di loro. Bush non aveva una risposta per la manutenzione. Il modello è la risposta.
Da dove viene il nome
Leggi il gist di Karpathy direttamente. È più accurato dei riassunti.
Scrive questo sul metodo usuale: "l'LLM sta riscoprendo la conoscenza da zero per ogni domanda. Non c'è accumulo."
Il suo metodo è compilare l'informazione, non recuperarla. Poi "la conoscenza viene compilata una volta e poi mantenuta aggiornata, non ridefinita a ogni query." Il risultato è "un artefatto persistente e cumulativo."
Non scrivi tu il wiki. Scrive: "Non scrivi mai (o raramente) il wiki da solo, l'LLM scrive e mantiene tutto." Usa l'agente e Obsidian insieme. Scrive: "Obsidian è l'IDE; l'LLM è il programmatore; il wiki è il codebase."
Il gist dà un limite per la dimensione. Molti riassunti non includono questo limite. Il metodo senza embedding "funziona sorprendentemente bene a scala media (~100 sorgenti, ~centinaia di pagine) e evita la necessità di infrastruttura RAG basata su embedding."
Per più sorgenti, il gist ti dice di aggiungere la ricerca. Dà qmd come esempio. Il gist descrive qmd come "un motore di ricerca locale per file markdown con ricerca ibrida BM25/vettoriale e ri-ranking LLM."
Quindi la regola riguarda la dimensione. La regola non riguarda la sostituzione. Non usare infrastruttura di recupero quando l'insieme di sorgenti è piccolo. Aggiungi il recupero quando l'insieme di sorgenti diventa grande.
Cosa hanno effettivamente costruito i laboratori
Qui il modello smette di essere un'idea e diventa ingegneria, e le differenze tra le implementazioni sono la parte utile.
Cognition: DeepWiki, il wiki come utilità pubblica
Cognition ha applicato il metodo ai repository pubblici su GitHub. Sostituisci github.com con deepwiki.com nell'URL di un repository pubblico. Ottieni quindi un wiki per quel codebase. Il wiki ha un riassunto dell'architettura, un indice dei file, un grafo delle dipendenze e una ricerca. Il wiki ha collegamenti alla sorgente (Cognition).
Più di 50.000 dei più grandi repository pubblici hanno un wiki. L'elenco include MCP e LangChain.
Il secondo punto è più importante. Il wiki non è il prodotto. Il wiki è infrastruttura di recupero per l'agente. Devin usa il wiki per trovare il codice correlato in un codebase. DeepWiki è quindi lo strato compilato sotto la ricerca del codice in Devin (Devin Docs).
Factory: AutoWiki, documentazione come artefatto di build
Factory ha applicato il metodo all'integrazione continua. Factory scrive che la documentazione deve essere un artefatto di build, non un progetto separato. La documentazione viene dalla sorgente. Ha la struttura del codebase. Cambia quando il repository cambia (Factory).
Il metodo per creare il wiki ha due passaggi. Il Passaggio 1 è una scansione strutturale. Legge il file README, i manifest dei pacchetti, la configurazione CI e i punti di ingresso. Il Passaggio 2 è una scansione semantica. Legge le route, gli endpoint API, le classi dei servizi, gli schemi del database e i feature flag.
Factory divide il lavoro tra agenti specializzati. Ogni agente ottiene una parte del repository. Ogni agente ottiene contesto sufficiente per scrivere una buona pagina. Questo metodo previene un problema noto: un singolo agente scrive documentazione scarsa per un repository grande.
Factory mantiene il wiki corretto con infrastruttura, non con disciplina. Il comando /wiki ricrea il wiki. Il comando /install-wiki scrive un workflow CI. Questo workflow ricrea il wiki a ogni push sul branch predefinito. Per GitHub, il wiki va nella scheda wiki del repository (Factory Docs).
LangChain: OpenWiki, e il salto dal codice a tutto
LangChain ha rilasciato OpenWiki come software open-source. OpenWiki è uno strumento CLI. Scrive e mantiene la documentazione dell'agente per un codebase. LangChain ha poi rilasciato OpenWiki Brains, che ha due modalità. Code Brain è la prima modalità, per un repository. Personal Brain è la seconda modalità, per le tue sorgenti (LangChain).
Personal Brain è il cambiamento importante. Legge dati da Gmail, Notion, repository git, X, Hacker News e ricerca web. Scrive tutti questi dati in un unico wiki markdown locale. L'agente legge questo wiki. Il metodo è passato dalla documentazione di un repository alla documentazione del tuo lavoro.
Ogni team ha preso la stessa decisione riguardo all'output. L'output non è testo per una persona da leggere. L'output è markdown strutturato per il contesto LLM. Ha titoli, collegamenti tra pagine e riassunti. La struttura permette a un agente di trovare rapidamente le informazioni correlate. Il lettore del wiki è un modello.
GBrain: la versione open-source a scala personale
GBrain applica il metodo a un archivio di conoscenza personale, non a un codebase. GBrain usa markdown in un repository git. Ha un file schema. Crea automaticamente un grafo di collegamenti tra argomenti.
GBrain mostra che il metodo necessita di pochissima infrastruttura. Non ha database vettoriale. Non ha servizio. Ha file. Un modello mantiene i file. Una persona può leggere i file.
La matrice tecnica
I quattro sistemi hanno la stessa struttura. Usano markdown in git. Usano un file schema. Compilano all'ingestione. Ricreano il wiki quando le sorgenti cambiano. Scrivono le pagine per essere lette da un agente. Quattro team hanno risolto quattro problemi diversi e hanno creato la stessa struttura. Questo accordo è una buona prova che la struttura è corretta.
I sistemi differiscono nella manutenzione. Factory fa la manutenzione in CI. Gli altri tre sistemi fanno la manutenzione quando una persona esegue un comando. I loro wiki sono quindi corretti solo quanto l'ultimo comando.
Dove si ferma
Limite 1: dimensione. Karpathy dà questo limite. Il metodo senza embedding è corretto per circa 100 sorgenti. Per più pagine, devi aggiungere un motore di ricerca. Il gist ti dice di usare insieme la ricerca BM25 e la ricerca vettoriale.
Limite 2: accuratezza. Il modello compila le informazioni all'ingestione. Un riassunto precoce può rimuovere un dettaglio dalla sorgente. Ogni risposta successiva contiene questo errore. Il recupero dalle parti grezze non ha questo problema. Scambi il costo del lavoro ripetuto con il rischio di perdita di dati.
Limite 3: informazioni vecchie. Una pagina è corretta solo quanto l'ultimo aggiornamento. Questo è il motivo per cui il metodo di Factory è importante. Un wiki incorretto è peggio di nessun wiki. L'informazione incorretta ha il formato dell'informazione corretta.
Limite 4: costo. Paghi token per creare pagine. Puoi creare pagine che nessuno legge. Paghi anche token per fare lint di pagine che non sono cambiate.
Un wiki non è memoria
C'è una differenza che devi conoscere. Le parole in questo campo non sono ancora precise.
Molte persone chiamano questi sistemi memoria. LangChain chiama OpenWiki un livello di memoria wiki per agenti AI. Altre persone dicono che un wiki dà memoria a un agente. La parola memoria ha qui due significati diversi.
Il primo significato è conoscenza di un insieme di documenti. Un wiki fa questo. Compila i dati nei tuoi documenti, nel tuo repository o nella tua Gmail. Ti dice cosa contengono i documenti.
Il secondo significato è memoria di un utente. Sono dati diversi. Include le preferenze di una persona. Include le decisioni di una persona. Include i metodi che un team ha scartato. Include il risultato quando un agente ha provato un metodo in un'applicazione diversa.
La memoria di un utente ha una struttura diversa. È legata a una persona, non a un insieme di documenti. Viene dall'interazione, non dall'ingestione. Deve anche fare questi compiti per ogni utente: correggere informazioni in disaccordo, rimuovere informazioni troppo vecchie, mantenere la fonte di ogni elemento e cancellare dati su richiesta.
Un wiki fa correttamente il primo compito. Un wiki non fa il secondo compito. Il tuo wiki di Gmail dice all'agente cosa c'è nella tua Gmail. Non dice all'agente che hai cambiato una decisione in una conversazione di martedì. Non dice all'agente che un metodo è già fallito per te.
Un livello di memoria fa il secondo compito. Mem0 è un esempio. Mantiene ogni memoria con un user_id. La memoria si sposta quindi con la persona tra sessioni, applicazioni e agenti. Modifica un fatto quando il fatto cambia. Non aggiunge un nuovo record ogni volta.
I due sistemi non sono alternativi. Usali entrambi. L'errore non è non usare un wiki. L'errore è pensare che un wiki ti dia la memoria di un utente.
Riassunto
L'idea negli agent wiki è corretta. Compila la conoscenza una volta. Poi mantienila corretta. Non ricostruirla per ogni domanda. La manutenzione ha fermato i wiki umani, e un modello fa la manutenzione a costo zero. Quattro team hanno costruito la stessa struttura in pochi mesi. Questa è una forte evidenza.
Fai queste tre cose. Compila i tuoi documenti in pagine quando l'insieme di documenti è stabile e lo leggi frequentemente. Aggiungi il recupero quando l'insieme di documenti diventa grande, come ti dice il gist. Tieni la differenza tra conoscenza di un insieme di documenti e memoria di un utente. Un wiki ti dà la prima. Un wiki non ti dà la seconda.
In Context #17
Questo blog fa parte di In Context, una serie di blog di @mem0ai che copre la memoria degli agenti AI e l'ingegneria del contesto.
Mem0 è un livello di memoria intelligente e open-source progettato per LLM e agenti AI per fornire interazioni a lungo termine, personalizzate e consapevoli del contesto tra sessioni.
- Ottieni la tua chiave API gratuita qui: app.mem0.ai
- o ospita mem0 da solo dal nostro repository open source su GitHub
Riferimenti
- Andrej Karpathy, LLM Wiki (GitHub Gist, Aprile 2026)
- qmd: ricerca ibrida locale BM25/vettoriale per markdown
- Cognition, DeepWiki: documentazione AI per qualsiasi repo
- Devin Docs, DeepWiki
- Factory, Presentazione di AutoWiki
- Factory Documentation, Panoramica di AutoWiki
- langchain-ai/openwiki (GitHub)
- LangChain, Wiki Memory
- garrytan/gbrain (GitHub)
- Vannevar Bush, As We May Think (The Atlantic, 1945)
- Mem0
