Il mio LLM Wiki: second brain con Claude e Obsidian

Da gennaio 2023 ho pubblicato quasi 200 articoli su ai-know.pro e cinque manuali tecnici su docs.ai-know.pro. È un volume che la memoria, da sola, non riesce più a tenere insieme. Quando il materiale cresce così serve una struttura esterna che faccia il lavoro di mappa, altrimenti diventa difficile sapere cosa c’è e cosa manca.

Da qui sono partito con due esigenze. La prima è di archivio, tenere traccia ordinata di cosa ho scritto, dove è stato pubblicato e con quali collegamenti tematici. La seconda, più ambiziosa, è di base di conoscenza. Ogni volta che preparo un corso ho bisogno di ritrovare in fretta il materiale che ho già scritto sul tema, organizzato per concetti più che per data. Cercare per data di pubblicazione o per categoria del blog non basta, perché un argomento spesso compare in più articoli scritti in tempi diversi, magari sotto angoli differenti, e ogni volta riparto a memoria. Volevo un sistema interrogabile per concetti e per collegamenti, dove la pagina su un tema mostra tutti i materiali che lo trattano, ciascuno con una breve nota di cosa contribuisce. Per preparare slide, esempi, esercitazioni, è esattamente quello che mi serve.

Su questa seconda esigenza qualcosa avevo già, NotebookLM in primis. Mi serviva però qualcosa di più strutturale, sotto il mio controllo, e che potessi modellare nel tempo.

L’occasione l’ha data Andrej Karpathy con un gist pubblicato il 4 aprile 2026.

Il pattern LLM Wiki di Karpathy

Il pattern si chiama LLM Wiki. La premessa di Karpathy è una distinzione fra come si usano oggi gli LLM per gestire i documenti e come si potrebbero usare. Il metodo diffuso è il RAG, retrieval-augmented generation, si carica una collezione di file e l’LLM recupera al volo i frammenti rilevanti per ogni domanda. Funziona, ma c’è un costo, l’LLM riscopre la conoscenza da zero a ogni interrogazione. Niente si accumula.

L’alternativa che Karpathy propone è un wiki strutturato e interconnesso che vive fra il lettore e i materiali grezzi. Il wiki è scritto e mantenuto dall’LLM, non da chi legge. Quando arriva una nuova fonte, l’LLM la integra nel wiki esistente, aggiorna le pagine pertinenti, segnala le contraddizioni con quanto già archiviato. La conoscenza viene compilata una volta e poi tenuta aggiornata, non riderivata ogni volta.

La descrizione che dà dell’architettura è «Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase». Obsidian non è la struttura, è l’interfaccia di lettura. La struttura è a tre layer, una directory raw/ con i materiali originali, una directory wiki/ con le pagine generate dall’LLM e un file di schema, tipicamente CLAUDE.md, che dice all’agente come operare sul vault.

È il file di schema il vero programma del sistema, definisce cosa diventa entità, come si nominano i file, quale stile devono avere le pagine, come gestire le affermazioni datate quando il mondo descritto cambia.

Il primo tentativo

Era da un po’ che meditavo di fare un test con Obsidian, la lettura del gist mi ha dato l’ultima spinta. Per cercare di fare in fretta ho iniziato a passare a Claude dei blocchi di articoli in ordine cronologico, una ventina alla volta. In poche sessioni il vault era popolato, il graph view di Obsidian mostrava una struttura visibile, le pagine concettuali principali esistevano e si linkavano fra loro.

Sembrava cosa fatta, poi ho visto due problemi.

Il primo era la presenza di orfani senza una ragione apparente. Nel graph view di Obsidian un orfano è un elemento isolato dagli altri, un nodo senza connessioni in entrata o in uscita. Qualche orfano ci sta, segna un debito di scrittura per pagine appena create che attendono di essere richiamate, ma io ne avevo molti e non tutti spiegabili così.

Il secondo era più sostanziale, gli articoli originali che si dovevano trovare nella sezione raw/ erano sostituiti da riassunti.

Cosa non funzionava

Le cause erano due, concorrenti.

La prima, nelle istruzioni che avevo dato a Claude avevo scritto una frase ambigua che in effetti poteva essere travisata. La seconda era tecnica, lavorando su blocchi di venti o trenta articoli per volta, la finestra di contesto era satura di materiali grezzi e di pagine wiki da scrivere. In quella condizione la sintesi non è solo un’interpretazione delle istruzioni, è una scelta naturale del modello per gestire il volume.

Le due cause si sommavano. La cartella raw/ conteneva sintesi invece di originali, mentre la cartella wiki/ conteneva pagine derivate da sintesi, cioè sintesi al quadrato. Il graph mostrava molti orfani perché in questo modo venivano perse le connessioni.

La ripartenza, un articolo alla volta

Sono ripartito da capo. Prima ho riscritto le istruzioni in CLAUDE.md, dicendo esplicitamente che i file in raw/ sono il testo originale in formato markdown, senza riformulazioni.

Poi ho ridotto il blocco di lavoro a un articolo per volta. Per ognuno l’agente recupera il contenuto direttamente dal blog. Per farlo uso wordpress-ai-know, un server MCP che ho sviluppato per connettere Claude al mio sito secondo le mie esigenze, qui usato in sola lettura. L’agente converte gli articoli in markdown, scarica le immagini, identifica le entità citate, aggiorna o crea le pagine wiki pertinenti, infine mi genera un breve report del lavoro fatto. Poi aspetta la conferma prima del prossimo.

La cartella raw/ ora contiene solo gli articoli originali con i loro link interni ed esterni preservati. Inoltre l’analisi individua tutte le possibili connessioni, portando a pagine wiki più ricche.

Anche Karpathy suggerisce di lavorare un elemento per volta «Personally I prefer to ingest sources one at a time and stay involved — I read the summaries, check the updates, and guide the LLM on what to emphasize». Nel primo tentativo avevo cercato la via veloce, ma se si cerca la qualità analizzare un articolo per volta è praticamente obbligatorio.

Cosa è cambiato

Ho appena completato l’inserimento di tutti gli articoli pubblicati, più i 5 manuali. Il grafo ha la forma di una rete vera, con cluster densi sui temi che ho trattato a fondo e nodi periferici sui temi marginali.

Gli orfani sono spariti, il rifacimento, con le nuove istruzioni e il lavoro a un articolo alla volta, ha eliminato il fenomeno.

Lavorando in questo modo Claude mi ha segnalato refusi visibili, link che non funzionano più, anomalie del testo originale. Come effetto secondario ho pulito il blog senza averlo programmato.

Cosa ne farò

L’uso che ho in mente è prima di tutto operativo. Per la preparazione di un corso, apro la pagina wiki del concetto e trovo tutti gli articoli che lo trattano, ciascuno con una breve nota di cosa contribuisce. Se devo costruire una sezione di slide su MCP, ho davanti l’elenco dei dieci-dodici articoli in cui ne ho parlato, organizzati per angolo di trattazione. Per gli esempi, gli esercizi, le citazioni di percorso, è il modo di lavorare che cercavo.

Oltre a questo, mi aspetto che il grafo aiuti la scrittura di articoli nuovi, mostrando connessioni fra temi che non avevo notato, e che apra la possibilità di ricognizioni periodiche per scoprire pattern non ancora notati nel corpus.

Per ora sono in ascolto. Il pattern LLM Wiki sta ricevendo molto interesse, basta scorrere i commenti al gist di Karpathy per vedere quante implementazioni stanno nascendo.

Naturalmente ho anche già inserito questo articolo.