LLM Wiki: come usare Obsidian e Claude Code per costruire una knowledge base AI
Un vault Obsidian come memoria professionale mantenuta da Claude Code. Il metodo di Karpathy per chi lavora con molti documenti.
C'è una frase di Andrej Karpathy che sta girando tra chi lavora con AI, Obsidian, Claude Code e sistemi di knowledge management:
"Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."
La frase descrive un sistema preciso: raccogliamo fonti, appunti, link, trascrizioni, note di libri, idee, documenti, e lasciamo a un modello linguistico il lavoro ripetitivo — leggere, sintetizzare, creare pagine, aggiungere link, aggiornare indici, trovare doppioni, segnalare contraddizioni.
L'utente resta il curatore.
Il modello fa manutenzione.
Questa è l'idea dietro la LLM Wiki di Karpathy. La tesi che sviluppo in questo numero è che per chi lavora con molti documenti — avvocati, consulenti, formatori, ricercatori — questo sistema risolve un problema concreto: la conoscenza accumulata non diventa mai memoria operativa, e ogni ricerca riparte da zero o comunque è affidata alla nostra labile memoria.
Il problema dei second brain
Negli ultimi anni abbiamo provato un po' tutti a costruire un secondo cervello.
Notion, Obsidian, Evernote, Google Drive, cartelle ordinate, bookmark, app per leggere articoli, note vocali, evidenziatori, PDF salvati "per dopo".
All'inizio il sistema funziona.
Poi cresce.
Entrano nuovi documenti, nuove call, nuovi articoli, nuove idee, nuovi clienti, nuove newsletter da leggere, nuovi materiali da riusare. Dopo qualche mese abbiamo informazioni utili sparse in 20 posti diversi.
Il problema pratico arriva quando dobbiamo usarle.
Cerchiamo una nota, apriamo 4 file, troviamo un articolo salvato 6 mesi prima, ricordiamo vagamente che c'era un passaggio utile, perdiamo 30 minuti e alla fine riscriviamo quasi tutto da zero.
Questo capita spesso anche nei lavori professionali.
Un parere richiama un documento scritto l'anno prima. Una lezione riprende una slide già preparata. Un articolo nasce da 3 appunti presi in momenti diversi. Una proposta commerciale dipende da call, email, note cliente e materiali interni.
La conoscenza c'è.
Manca il lavoro di manutenzione.
Che cos'è una LLM Wiki
Una LLM Wiki è una knowledge base mantenuta da un modello linguistico.
L'utente raccoglie le fonti. L'LLM legge, sintetizza, collega e aggiorna la wiki.
La fonte entra nel sistema. Il modello la analizza, crea una pagina dedicata, individua concetti, persone, strumenti, metodi, collega le nuove pagine a quelle già esistenti e scrive un log di ciò che ha fatto.
Il sistema cresce in modo progressivo.
Ogni nuova fonte aggiunge qualcosa alla wiki. Se una pagina esiste già, viene aggiornata. Se manca una pagina su un concetto, viene creata. Se 2 fonti dicono cose diverse, la contraddizione viene segnalata.
Questa logica è utile per chi lavora con contenuti, consulenza, formazione, ricerca o compliance.
Penso, ad esempio, a una knowledge base AI su AI Act, GDPR, Data Act, NIS2, DORA, eIDAS 2.
Ogni fonte nuova non resta parcheggiata in una cartella. Entra in una rete di pagine che l'AI mantiene nel tempo.
LLM Wiki e RAG
Qui entra il tema RAG.
La RAG classica funziona così: prendiamo documenti, li dividiamo in pezzi, li trasformiamo in embedding, li salviamo in un database vettoriale e, quando facciamo una domanda, il sistema recupera i passaggi più vicini alla richiesta.
È una tecnica potente. Ha senso quando abbiamo molti documenti e vogliamo interrogare un archivio.
La LLM Wiki lavora in un altro punto del processo.
Nella RAG classica il recupero avviene soprattutto quando facciamo la domanda.
Nella LLM Wiki una parte del lavoro avviene quando inseriamo la fonte.
Il modello legge il materiale, lo trasforma in pagine Markdown, aggiorna gli indici, crea link e conserva un log.
Per questo possiamo considerarla una forma di file-based RAG.
La conoscenza esterna viene usata dal modello, ma non passa necessariamente da chunk, embedding e vector database. Passa da file leggibili, pagine ordinate, link interni e istruzioni operative.
Sul piano tecnico è una soluzione più semplice di una RAG con vector database. Per un professionista o un piccolo team che inizia, può essere quella giusta — perché si vede tutto.
Le fonti sono file. Le sintesi sono file. Gli errori si correggono. I link si leggono. I log restano nel vault.
Perché usare Obsidian
Obsidian funziona bene in questo modello per un motivo molto pratico: usa file Markdown locali.
Questo significa che una nota Obsidian è un file di testo.
Claude Code può entrare nella cartella del vault Obsidian, leggere i file, scriverne di nuovi, modificare pagine, creare link interni, aggiornare indici e produrre log.
Il vault diventa un ambiente di lavoro leggibile anche dall'AI.
La struttura minima può essere questa:
llm-wiki/
sources/
inbox/
wiki/
logs/
templates/
outputs/
CLAUDE.md
Dentro sources mettiamo le fonti grezze.
Dentro inbox mettiamo appunti rapidi, link da leggere, note provvisorie.
Dentro wiki mettiamo le pagine create e aggiornate dal modello.
Dentro logs mettiamo i registri delle operazioni.
Dentro templates mettiamo modelli di pagina.
Dentro outputs mettiamo report, bozze e materiali temporanei.
Il file CLAUDE.md contiene le regole.
Sources, inbox, wiki
La cartella sources deve restare pulita.
Qui finiscono articoli, trascrizioni, note da libri, report, paper, PDF convertiti in testo, materiali normativi, documenti di ricerca.
Una regola: i file in sources non si modificano.
Sono le fonti originarie. Se il modello sbaglia una sintesi, possiamo tornare al testo di partenza.
La cartella inbox è più libera.
Qui entrano note rapide, idee, link, appunti di call, domande, spunti per articoli, pezzi da verificare.
La cartella wiki contiene la conoscenza lavorata.
Può avere sottocartelle come queste:
wiki/
concepts/
people/
tools/
methods/
regulations/
institutions/
maps/
indexes/
source-summaries/
Per un vault dedicato a diritto e tecnologie, potremmo avere pagine come:
wiki/concepts/
AI Act.md
GPAI.md
High-risk AI system.md
File-based RAG.md
LLM Wiki.md
wiki/tools/
Obsidian.md
Claude Code.md
NotebookLM.md
wiki/regulations/
Regulation EU 2024-1689.md
Regulation EU 2023-2854.md
Regulation EU 2024-1183.md
La differenza tra sources e wiki è importante.
La fonte resta stabile.
La wiki cambia.
CLAUDE.md
Il file CLAUDE.md è la parte più delicata.
Contiene le istruzioni permanenti per Claude Code. Senza questo file, l'agente tenderà a improvvisare. Con istruzioni scritte bene, lavora in modo più coerente.
Un CLAUDE.md per una LLM Wiki dovrebbe dire almeno 8 cose:
# LLM Wiki
## Scopo
Questo vault Obsidian contiene una LLM Wiki.
L'utente raccoglie fonti e appunti.
Claude Code mantiene la wiki.
## Struttura
- /sources: fonti grezze. Non modificarle.
- /inbox: note provvisorie.
- /wiki: pagine elaborate.
- /logs: log delle operazioni.
- /outputs: report e bozze.
- /templates: template.
## Regole sulle fonti
- Non modificare i file in /sources.
- Cita sempre le fonti usate.
- Se una fonte contraddice una pagina wiki, segnala la contraddizione.
## Regole sulla wiki
- Aggiorna pagine esistenti prima di crearne di nuove.
- Evita pagine quasi duplicate.
- Usa wiki-link Obsidian nel formato [[Nome pagina]].
- Ogni pagina deve avere frontmatter YAML.
- Ogni pagina deve avere una sezione "Fonti".
## Frontmatter standard
---
type:
status:
created:
updated:
tags:
sources:
related:
confidence:
---
## Tipi di pagina
- concept
- person
- tool
- method
- regulation
- institution
- source-summary
- map
- index
- contradiction
## Log
Dopo ogni operazione, crea un file in /logs con:
- richiesta iniziale;
- fonti lette;
- pagine create;
- pagine aggiornate;
- dubbi;
- prossime azioni.
## Stile
Scrivi in modo chiaro, sintetico e controllabile.
Distingui sempre tra fonte, sintesi e inferenza.
Questo file va rivisto dopo qualche sessione.
Se l'agente crea troppe pagine, aggiungiamo una regola.
Se usa titoli incoerenti, aggiungiamo una convenzione di naming.
Se dimentica le fonti, rendiamo obbligatoria la sezione "Fonti".
Il metodo cresce correggendo le regole, non solo i singoli output.
I 3 workflow principali
Il sistema si può usare con 3 workflow ricorrenti.
Il primo è ingest-url.
Trovo una fonte interessante, la salvo e chiedo all'agente di inserirla nella wiki.
Prompt:
Ingerisci questa fonte nella LLM Wiki:
Percorso: /sources/ai/2026-05-01 - Articolo LLM Wiki.md
Istruzioni:
1. Leggi la fonte.
2. Crea una pagina di sintesi in /wiki/source-summaries.
3. Identifica concetti, persone, strumenti e metodi.
4. Crea o aggiorna le pagine rilevanti in /wiki.
5. Aggiorna gli indici.
6. Aggiungi wiki-link.
7. Scrivi un log in /logs.
8. Segnala dubbi, contraddizioni o pagine da rivedere.
Il secondo è process-inbox.
Serve a svuotare gli appunti provvisori.
Prompt:
Processa la cartella /inbox.
Istruzioni:
1. Leggi tutti i file.
2. Classifica ogni nota come idea, task, fonte, concetto, domanda o appunto di progetto.
3. Crea o aggiorna pagine wiki quando serve.
4. Estrai eventuali task.
5. Proponi quali file archiviare.
6. Non cancellare nulla senza conferma.
7. Scrivi un report in /outputs.
Il terzo è lint-wiki.
Serve a controllare la qualità della wiki.
Prompt:
Esegui un controllo della wiki.
Cerca:
1. link rotti;
2. pagine orfane;
3. pagine duplicate;
4. concetti citati più volte ma senza pagina;
5. contraddizioni tra pagine;
6. indici non aggiornati;
7. pagine troppo lunghe;
8. pagine troppo brevi;
9. fonti mancanti.
Scrivi il report in /outputs/wiki-lint-report-YYYY-MM-DD.md.
Questo terzo workflow è sottovalutato.
Una knowledge base cresce male se nessuno la controlla. L'AI può produrre ordine apparente. La manutenzione periodica riduce doppioni, link deboli e pagine senza fonti.
Un esempio per The Sunday Prompt
Questo metodo sarebbe molto utile per una newsletter.
Pensiamo a un vault dedicato a The Sunday Prompt.
Dentro sources potrei salvare articoli su Claude, ChatGPT, Gemini, NotebookLM, prompt engineering, context engineering, agenti, RAG, AI coding, Obsidian, workflow professionali.
Dentro wiki/concepts potrei avere pagine su:
- Prompt engineering
- Context engineering
- RAG
- File-based RAG
- Claude Code
- LLM Wiki
- Obsidian
- AI agents
- Chain of thought
- Prompt chaining
Dentro wiki/tools potrei avere schede su:
- ChatGPT
- Claude
- Claude Code
- Obsidian
- NotebookLM
- Gemini
- Perplexity
- n8n
Dentro inbox potrei inserire spunti veloci:
- numero su Claude Code e Obsidian
- confronto RAG classica e LLM Wiki
- prompt per creare una wiki legale
- esempio per studi professionali
Poi potrei chiedere:
Preparami una scaletta per un numero di The Sunday Prompt sulla LLM Wiki.
Usa:
- le fonti in /sources;
- le pagine in /wiki/concepts;
- i precedenti numeri della newsletter, se presenti nel vault.
Output:
- titolo;
- apertura;
- struttura;
- esempi pratici;
- chiusura;
- 3 possibili post LinkedIn.
Il risultato dipenderebbe dalla mia knowledge base, non solo dalla conoscenza generale del modello.
Questo è il vantaggio.
La newsletter avrebbe memoria.
Un esempio per uno studio professionale
Lo stesso metodo può funzionare in uno studio legale o in una società di consulenza.
Creiamo un vault su AI governance.
Dentro sources inseriamo:
- Regolamento AI Act;
- linee guida della Commissione;
- materiali dell'AI Office;
- articoli su GPAI;
- documenti su FRIA;
- note su DPIA;
- materiali su standard armonizzati;
- appunti da webinar;
- paper su risk management.
Dentro wiki creiamo pagine su:
- AI Act
- sistema AI ad alto rischio
- provider
- deployer
- GPAI
- human oversight
- risk management system
- data governance
- conformity assessment
- FRIA
- DPIA
Quando arriva una nuova fonte, Claude Code aggiorna le pagine interessate.
Quando devo preparare una lezione, chiedo alla wiki una scaletta.
Quando devo scrivere una checklist, chiedo di usare solo le pagine con fonti verificate.
Quando devo preparare una call con un cliente, chiedo una sintesi dei punti aperti.
Qui la differenza pratica si vede.
L'AI non produce solo un testo. Mantiene materiale che può essere riusato.
Il rischio dell'ordine apparente
Una LLM Wiki può sembrare precisa anche quando contiene errori.
Una pagina ben formattata può avere una sintesi debole.
Un link può sembrare sensato e reggere poco.
Una pagina concettuale può mischiare fonte, interpretazione e ipotesi.
Per questo servono regole chiare.
Ogni pagina importante dovrebbe avere:
- Definizione
- Sintesi
- Fonti
- Collegamenti
- Dubbi
- Da verificare
Nel lavoro professionale aggiungerei anche:
- Base normativa
- Interpretazione
- Implicazioni operative
- Rischi
- Note per il cliente
La sezione "Da verificare" è utile.
Obbliga il sistema a non chiudere troppo presto il ragionamento. Se una fonte è parziale, se manca un riferimento, se una pagina contiene un'inferenza dell'agente, deve restare scritto.
La manutenzione epistemica
C'è un controllo che userei almeno una volta al mese.
Lo chiamerei audit epistemico della wiki.
Prompt:
Esegui un audit epistemico della wiki.
Istruzioni:
1. Cerca pagine troppo assertive.
2. Cerca tesi ripetute senza fonti sufficienti.
3. Cerca fonti che contraddicono pagine esistenti.
4. Cerca pagine che confondono fonte e interpretazione.
5. Segnala concetti che richiedono una verifica esterna.
6. Suggerisci quali pagine aggiornare.
7. Scrivi un report in /outputs/epistemic-audit-YYYY-MM-DD.md.
Questo controllo è utile nei temi regolatori.
Su AI Act, privacy, cybersecurity o identità digitale, una sintesi elegante può essere pericolosa se non separa bene norma, interpretazione, prassi e opinione.
La wiki deve restare leggibile, ma anche controllabile.
Come iniziare
Partire in piccolo.
Un nuovo vault Obsidian.
Poche cartelle:
sources/
inbox/
wiki/
logs/
outputs/
templates/
CLAUDE.md
Poi 5 fonti.
Non 50.
Una fonte alla volta.
Dopo ogni ingestione, controllo le pagine create. Correggo titoli, fonti, link, categorie. Aggiorno CLAUDE.md se vedo errori ricorrenti.
Dopo una settimana, lancio lint-wiki.
Dopo 1 mese, faccio un audit più serio.
Prima va costruita una procedura ripetibile. Il sistema si espande da lì.
Il cambio di abitudine
Il prompt engineering sta cambiando.
La prima fase era scrivere prompt migliori.
Poi sono arrivati prompt chaining, ruoli, esempi, formati di output, context engineering.
Ora il tema diventa l'ambiente in cui il modello lavora.
Il prompt engineering è utile. Quando la base di conoscenza cresce nel tempo, serve anche un sistema che la conservi tra una sessione e l'altra, la aggiorni quando arriva una fonte nuova, e tenga traccia di ciò che è stato fatto.
La LLM Wiki copre questo pezzo. Richiede ordine: ogni fonte aggiorna le pagine esistenti, ogni sessione lascia un log, ogni contraddizione viene segnalata. Il risultato è che ogni ricerca, ogni articolo, ogni lezione e ogni consulenza non riparte da zero.
Prompt della settimana
Questo prompt avvia una nuova LLM Wiki con Claude Code su un tema specifico. Utile la prima sessione, prima di configurare il CLAUDE.md a mano.
Voglio costruire una LLM Wiki su [TEMA] in questo vault Obsidian.
Struttura:
- /sources: fonti grezze. Non modificarle.
- /inbox: note e appunti provvisori.
- /wiki: pagine elaborate per concetti, strumenti, persone, metodi.
- /logs: log delle operazioni.
- /outputs: report e materiali temporanei.
Istruzioni:
1. Crea la struttura di cartelle.
2. Crea un CLAUDE.md con: scopo, struttura, regole sulle fonti, regole sulla wiki, frontmatter standard, tipi di pagina, formato del log.
3. Crea /wiki/index.md vuoto.
4. Scrivi un log iniziale in /logs con: data, tema del vault, struttura creata, prime istruzioni.
Tema: [inserire dominio — es. "AI Act e regolamentazione AI", "privacy e GDPR", "prompt engineering professionale"]
Dopo le prime sessioni di ingestione, rivedi il CLAUDE.md in base agli errori ricorrenti che vedi. Il prompt di avvio è un punto di partenza; il file di regole si raffina con l'uso.
Takeaway
Tre cose operative da portarsi a casa:
- Inizia con 5 fonti, struttura minima,
CLAUDE.mdscritto bene. Controlla le pagine create dopo ogni ingestione prima di aggiungerne altre. - Lancia
lint-wikidopo la prima settimana: individua link rotti, pagine orfane e doppioni prima che il sistema cresca male. - Aggiorna il
CLAUDE.mdogni volta che l'agente fa qualcosa di sbagliato in modo sistematico. La correzione va sulla regola, non sul singolo output.
Se stai già usando Obsidian con Claude Code — o hai provato qualcosa di simile — dimmi com'è andata.
Happy prompting
Tag