Un pattern per costruire knowledge base personali e aziendali con gli LLM — adattato al contesto italiano (PMI, freelancer, studi professionali, consulenti).
Adattamento italiano del pattern LLM Wiki di Andrej Karpathy (4 aprile 2026). Tutti i meriti del concetto originale vanno a lui. Questo repo aggiunge esempi, casi d'uso italiani e una versione operativa testata su un sistema di produzione (giovanniliguori.it, 21+ automazioni Claude in esercizio dal marzo 2026).
Mantenuto da Giovanni Liguori — AI Automation Architect. Licenza: MIT. Copia, modifica, condividi. Se ti è utile, lasciamene una nota.
Questo è un idea file. Non è una libreria, non è un tool, non è un boilerplate. È una pagina pensata per essere copiata e incollata dentro il tuo agente LLM (Claude Cowork, Codex, OpenCode, n8n + Claude API, qualunque cosa tu usi). Comunica un pattern. L'agente lo istanzia con te in base al tuo dominio.
Versione minimal di partenza disponibile in examples/CLAUDE.md.
- Clona il repo:
git clone https://github.com/giovanniliguori/llm-wiki-italia.git cd llm-wiki-italia - Crea la tua cartella di lavoro (può essere ovunque):
mkdir my-wiki && cd my-wiki mkdir raw wiki
- Copia lo scheletro CLAUDE.md:
cp /path/to/llm-wiki-italia/examples/CLAUDE.md ./CLAUDE.md
- Apri il tuo agente LLM nella cartella. Punta alla cartella
raw/per le fonti, alla cartellawiki/per le pagine generate. - Adatta il
CLAUDE.mdal tuo dominio (cambia esempi, convenzioni, workflow). - Inizia a buttare fonti dentro
raw/e a chiedere all'agente di processarle.
Da qui in poi, il CLAUDE.md evolve con te.
Il modo standard di usare gli LLM con i documenti si chiama RAG: carichi un mucchio di file, l'LLM al momento della query recupera i pezzi rilevanti, genera la risposta. Funziona, ma l'LLM riscopre la conoscenza da zero ogni volta. Niente si accumula. Fai una domanda che richiede di sintetizzare cinque documenti e l'LLM deve trovare e rimettere insieme i frammenti rilevanti ogni singola volta. NotebookLM, ChatGPT con upload, la maggior parte dei sistemi RAG funzionano così.
L'idea qui è diversa. Invece di recuperare a freddo dai documenti grezzi a ogni query, l'LLM costruisce e mantiene incrementalmente una wiki persistente — una collezione strutturata di file markdown collegati tra loro che vive tra te e le fonti grezze. Quando aggiungi una fonte nuova, l'LLM non si limita a indicizzarla per uso futuro. La legge, estrae le informazioni chiave, le integra nella wiki esistente — aggiorna le pagine delle entità, rivede i riassunti dei topic, segnala dove il dato nuovo contraddice claim vecchi, rafforza o sfida la sintesi che si sta evolvendo. La conoscenza viene compilata una volta e poi tenuta corrente, non riderivata a ogni query.
Questa è la differenza chiave: la wiki è un artefatto persistente che compone interesse. Le cross-reference ci sono già. Le contraddizioni sono già state segnalate. La sintesi riflette già tutto quello che hai letto. La wiki diventa più ricca con ogni fonte aggiunta e ogni domanda fatta.
Tu (quasi) non scrivi mai la wiki — l'LLM scrive e mantiene tutto. Tu sei in carico di sourcing, esplorazione e domande giuste. L'LLM fa tutto il lavoro sporco — riassumere, fare le cross-reference, archiviare, contabilizzare, quello che serve perché una knowledge base sia davvero utile nel tempo.
In pratica: agente LLM aperto da una parte, editor markdown (Obsidian, VSCode, NotePlan) dall'altra. L'LLM modifica in base alla conversazione, tu sfogli i risultati in tempo reale — segui i link, controlli il graph view se ce l'hai, rileggi le pagine aggiornate.
Si applica a tantissimi contesti.
- Studio commercialista o consulente fiscale. Circolari Agenzia Entrate, normativa, casi clienti, sentenze. Una wiki che cresce con ogni nuova circolare e mantiene aggiornati i riferimenti incrociati su detrazioni, esenzioni, scadenze. L'alternativa è chiedere a ChatGPT a freddo ogni volta e sperare che non sbagli.
- Studio legale piccolo. Sentenze, dottrina, fascicoli clienti (con anonimizzazione dove serve), contratti tipo. La wiki diventa il sapere dello studio, indipendente da chi va e chi viene.
- Agenzia di marketing / SEO consultant. Audit clienti, brief, performance log, competitor monitoring, normativa GDPR/AI Act. Ogni nuovo audit alimenta il sapere che usi sul prossimo cliente.
- Freelancer consulente B2B. Note delle call, follow-up, pitch fatti, oggezioni ricevute, casi di studio reali. La wiki è la tua memoria operativa. Quando un prospect ti chiede "hai già fatto qualcosa di simile?", ce l'hai pronto.
- Personal knowledge. Obiettivi, salute, psicologia, self-improvement — note di lettura, podcast, articoli, riflessioni. Costruire un quadro strutturato di te stesso nel tempo.
- PMI / team interno. Wiki interna mantenuta dall'LLM, alimentata da thread Slack, trascrizioni meeting, documenti di progetto, call clienti. Eventualmente con human in the loop che approva. La wiki resta corrente perché l'LLM fa la manutenzione che nessuno in azienda vuole fare.
- Ricerca / due diligence / studio di un dominio nuovo. Andare in profondità su un topic per settimane o mesi — paper, articoli, report, costruendo incrementalmente una sintesi con tesi che evolve.
Funziona ovunque tu stia accumulando sapere nel tempo e voglia che resti organizzato invece di scattered.
Tre layer.
Sources grezze — la tua collezione curata di documenti sorgente. Articoli, paper, immagini, file dati. Sono immutabili — l'LLM li legge ma non li modifica mai. È la tua source of truth.
La wiki — una directory di file markdown generati dall'LLM. Riassunti, pagine entità, pagine concetti, comparazioni, una panoramica, una sintesi. L'LLM possiede questo layer interamente. Crea pagine, le aggiorna quando arrivano fonti nuove, mantiene cross-reference, tiene tutto coerente. Tu leggi; l'LLM scrive.
Lo schema — un documento (es. CLAUDE.md per Claude Cowork/Code o AGENTS.md per Codex) che dice all'LLM com'è strutturata la wiki, quali sono le convenzioni, quali workflow seguire quando ingerisce fonti, risponde a domande, mantiene la wiki. Questo è il file di configurazione chiave — è quello che trasforma l'LLM da chatbot generico a manutentore disciplinato della wiki. Tu e l'LLM lo co-evolvete nel tempo.
Il punto più importante è lo schema. È un singolo file markdown. Tutto il resto — Obsidian, plugin, qmd, graph view, dataview, marp — è cosmetico, opzionale, può essere aggiunto dopo se ti serve. Lo schema è ciò che fa la differenza.
Vedi examples/CLAUDE.md per uno scheletro pronto da clonare.
Ingest. Lasci una fonte nuova nella collezione grezza e dici all'LLM di processarla. Esempio di flusso: l'LLM legge la fonte, discute con te i punti chiave, scrive una pagina riassunto nella wiki, aggiorna l'index, aggiorna le pagine di entità e concetti rilevanti, appende un'entry al log. Una singola fonte può toccare 10-15 pagine wiki. Personalmente preferisco ingerire una fonte alla volta restando coinvolto — leggo i riassunti, controllo gli aggiornamenti, guido l'LLM su cosa enfatizzare. Ma puoi anche fare batch ingest di molte fonti con meno supervisione.
Query. Fai domande alla wiki. L'LLM cerca le pagine rilevanti, le legge, sintetizza una risposta con citazioni. Le risposte possono prendere forme diverse a seconda della domanda — una pagina markdown, una tabella di confronto, un deck (Marp), un grafico (matplotlib), un canvas. Insight chiave: le buone risposte possono essere archiviate dentro la wiki come pagine nuove. Una comparazione che hai chiesto, un'analisi, una connessione che hai scoperto — sono valore e non devono finire dispersi nella chat history.
Lint. Periodicamente, chiedi all'LLM di fare un health check sulla wiki. Cerca: contraddizioni tra pagine, claim obsoleti che fonti più recenti hanno superato, pagine orfane senza link in entrata, concetti importanti citati ma senza pagina dedicata, cross-reference mancanti, gap di dati che potrebbero essere riempiti con una ricerca. L'LLM è bravo a suggerire domande nuove da investigare e fonti nuove da cercare.
Due file speciali aiutano l'LLM (e te) a navigare la wiki mentre cresce.
index.md è orientato al contenuto. È un catalogo di tutto quello che c'è nella wiki — ogni pagina con un link, un riassunto in una riga, e opzionalmente metadati come data o numero di fonti. Organizzato per categoria. L'LLM lo aggiorna a ogni ingest. Quando risponde a una query, l'LLM legge prima l'index per trovare le pagine rilevanti, poi entra nei dettagli. Funziona sorprendentemente bene a scala moderata (~100 fonti, ~centinaia di pagine) e ti evita di dover montare un'infrastruttura RAG con embeddings.
log.md è cronologico. È un record append-only di cosa è successo e quando — ingest, query, lint pass. Se ogni entry inizia con un prefisso consistente (es. ## [2026-04-27] ingest | Titolo Articolo), il log diventa parsabile con tool unix banali — grep "^## \[" log.md | tail -5 ti dà le ultime 5 entry.
A un certo punto potresti voler costruire piccoli tool che aiutano l'LLM a operare sulla wiki più efficientemente.
- qmd — motore di ricerca locale per file markdown con BM25/vettoriale ibrido e re-ranking LLM, on-device. Ha CLI e MCP server.
- Obsidian Web Clipper — estensione browser che converte articoli web in markdown.
- Obsidian — graph view per vedere la forma della wiki, plugin Dataview per query, plugin Marp per slide.
- git — la wiki è un repo di file markdown. Hai history, branching, collaborazione gratis.
- Lo schema è il 90% del valore. Il resto è cosmetico. Cambiare editor (Obsidian → VSCode → di nuovo Obsidian) non rompe la wiki se lo schema è solido.
- Atomic notes > monoliti. I file >500 righe diventano fardelli. Spezzali. Regola operativa: se un file fa scrollare 2 schermate, è già troppo grande.
- Routing table esplicita. In testa allo schema, una tabella "se chiedi X leggi Y". Costa 10 minuti, fa risparmiare token su ogni sessione nuova.
- Glossario separato. Acronimi e termini interni in un file dedicato. Le sessioni nuove dell'LLM perdono il contesto su sigle proprietarie.
- Decision log. Un
CHANGELOG.mdappend-only. Riprendere il lavoro a settimane di distanza diventa banale. - Idempotency. Ogni operazione automatizzata deve essere safe-to-rerun. La wiki cresce solo per add, mai per overwrite implicito.
- GDPR. Se la wiki contiene dati di clienti, fai una DPIA semplificata prima. L'LLM può aiutarti, ma la responsabilità del titolare resta tua.
La parte tediosa di mantenere una knowledge base non è la lettura o il pensiero — è la contabilità. Aggiornare cross-reference, tenere i riassunti correnti, segnalare quando un dato nuovo contraddice un claim vecchio, mantenere la coerenza su decine di pagine. Gli umani abbandonano le wiki perché il costo di manutenzione cresce più velocemente del valore. Gli LLM non si annoiano, non dimenticano di aggiornare una cross-reference, e possono toccare 15 file in un singolo passaggio. La wiki resta mantenuta perché il costo di manutenzione è prossimo a zero.
Il lavoro umano: curare le fonti, dirigere l'analisi, fare buone domande, pensare a cosa significa il quadro complessivo. Il lavoro dell'LLM: tutto il resto.
L'idea è imparentata in spirito al Memex di Vannevar Bush (1945). La visione di Bush era privata, attivamente curata, con le connessioni tra documenti tanto preziose quanto i documenti stessi. Il pezzo che Bush non poteva risolvere era chi fa la manutenzione. L'LLM si occupa di quello.
Questo pattern lo opero da circa un anno su giovanniliguori.it — un sistema con 21+ automazioni Claude, ~30 task scheduled (Cowork locale + Routines cloud), un signals bus markdown per la comunicazione cross-task, e un knowledge base che oggi pesa ~300 file .md.
I learning in produzione sono raccolti nei tip pratici sopra. Non è un metodo. È un'osservazione di ciò che ha funzionato.
PR e issue benvenuti. Vedi CONTRIBUTING.md.
Cose particolarmente utili:
- Casi d'uso aggiuntivi per categorie professionali italiane (notai, architetti, ingegneri, medici, ecc.)
- Esempi
CLAUDE.mdper domini specifici - Traduzioni o adattamenti per altre lingue (vedi
localization/se esiste)
Questo documento è intenzionalmente astratto. Descrive l'idea, non un'implementazione specifica. La struttura esatta delle directory, le convenzioni dello schema, i formati delle pagine, il tooling — tutto dipende dal tuo dominio. Tutto quello che è citato sopra è opzionale e modulare — prendi quello che ti serve, ignora il resto.
Il modo giusto di usare questo documento è condividerlo con il tuo agente LLM e lavorare insieme per istanziare una versione che si adatta al tuo bisogno. L'unico compito di questo documento è comunicare il pattern. Il tuo LLM può capire il resto.
E se ti accorgi di avere passato due settimane sul setup senza aver ingerito una singola fonte reale, smetti di settare e inizia a usare. Lo stack non è il pattern.
Versione inglese: per ora vai all'originale di Karpathy. Discussione: Issues.