LLM Wiki di Karpathy: una base di conoscenza locale
Il LLM Wiki è un modello descritto da Andrej Karpathy nell'aprile 2026: invece di frugare nei tuoi documenti a ogni domanda, un modello redige e mantiene aggiornato un wiki in Markdown, che si arricchisce a ogni nuova fonte. Questa guida spiega il principio a partire dal suo post e dal suo gist, propone una configurazione locale con Ollama e un agente nel terminale, poi precisa ciò che questo modello non sostituisce in un RAG. Non contiene né test interni né un confronto quantitativo: ciò che viene detto del modello è attribuito alla sua fonte, mentre il resto è indicato come una nostra implementazione.
#LLM Wiki: il principio in due minuti
Il 2 aprile 2026, Andrej Karpathy descrive su X il modo in cui usa i modelli linguistici per creare basi di conoscenza personali. Due giorni dopo pubblica un gist intitolato «LLM Wiki», che presenta come un modello per costruire questo tipo di base con un LLM. I due testi sono brevi e si leggono in dieci minuti; i collegamenti sono riportati in fondo alla pagina.
Il gist parte da un'osservazione: la maggior parte degli usi che combinano LLM e documenti assomiglia a un RAG. Si depositano file, il sistema recupera estratti al momento della domanda, il modello redige una risposta. Karpathy riconosce che funziona, ma osserva che il modello riscopre la conoscenza a ogni domanda e che nulla si accumula. Una domanda che obbliga a incrociare cinque documenti richiede di recuperare e ricomporre gli stessi frammenti ogni volta.
LLM Wiki sposta il lavoro a monte. Quando arriva una nuova fonte, il modello non si limita a indicizzarla: la legge, ne estrae l'essenziale e la integra in un insieme di pagine Markdown collegate tra loro. Aggiorna le pagine esistenti, rivede le sintesi e annota i punti in cui la nuova fonte contraddice quanto era scritto. Il gist parla di un artefatto persistente che migliora nel tempo: i confronti incrociati sono già stati fatti quando arriva la domanda.
La ripartizione dei ruoli è netta nel testo. L'essere umano sceglie le fonti, esplora e pone le domande. Il modello fa tutto il resto: riassumere, collegare, classificare, tenere i registri. Karpathy dice di lavorare con l'agente aperto su un lato dello schermo e Obsidian sull'altro, e riassume l'installazione con un'immagine: Obsidian è l'IDE, l'LLM è il programmatore, il wiki è la base di codice.
#Tre livelli: fonti, wiki, convenzioni
I tuoi documenti, la tua IA: un RAG locale affidabile sui tuoi PDF, sulle tue note e sulle tue email — senza inviare nulla nel cloud.
- Spazio online a vita
- PDF + file
- Aggiornamenti a vita
Il gist descrive un'architettura a tre livelli. Nessuno richiede uno strumento particolare: sono cartelle e file di testo.
- Le fonti grezze
- La tua raccolta di documenti: articoli, lavori di ricerca, immagini, file di dati. Sono immutabili: il modello li legge e non li modifica mai. Sono loro, non il wiki, a fare fede.
- Il wiki
- Una cartella di file Markdown redatti dal modello: riepiloghi delle fonti, pagine delle entità, pagine dei concetti, confronti, sintesi d'insieme. Questo livello appartiene al modello, che crea le pagine, le aggiorna e mantiene i collegamenti. Tu leggi, lui scrive.
- Il file delle convenzioni
- Un documento che indica al modello come è strutturato il wiki, quali regole seguire e come procedere per ingerire una fonte, rispondere a una domanda o fare pulizia. Il gist cita CLAUDE.md per Claude Code e AGENTS.md per Codex. È questo file che trasforma un agente generalista in un manutentore disciplinato del wiki.
Due file particolari aiutano il modello, e te, a orientarsi. Il primo, index.md, è un catalogo: ogni pagina vi compare con un link e un riassunto di una riga, organizzata per categoria. Per rispondere a una domanda, il modello legge prima l'indice, poi apre le pagine utili. Il secondo, log.md, è un registro cronologico a cui si aggiungono soltanto nuove righe: importazioni, domande, passaggi di verifica.
Il gist suggerisce di iniziare ogni voce del registro con un prefisso regolare, così da poterlo filtrare con semplici strumenti Unix. L'esempio fornito ha questa forma:
#Tre operazioni: acquisire, interrogare, verificare
- Acquisire (ingest)
- Depositi una fonte nella cartella delle fonti grezze e chiedi al modello di elaborarla. Secondo il gist, legge la fonte, discute con te i punti chiave, scrive una pagina di riepilogo, aggiorna l'indice nonché le pagine delle entità e dei concetti interessati, poi aggiunge una voce al registro. Karpathy indica che una sola fonte può interessare da 10 a 15 pagine del wiki.
- Interrogare (query)
- Poni una domanda. Il modello cerca le pagine pertinenti, le legge e redige una risposta che cita le sue fonti. Il gist insiste su un punto: una buona risposta può essere archiviata nel wiki come nuova pagina, così le tue esplorazioni si accumulano invece di sparire nella cronologia di una discussione.
- Verificare (lint)
- Di tanto in tanto, chiedi al modello un controllo dello stato di salute del wiki: contraddizioni tra le pagine, affermazioni superate da fonti più recenti, pagine orfane senza link in entrata, concetti citati senza una pagina dedicata, rimandi mancanti.
Perché affidare questo lavoro a un modello? L'argomento del gist è semplice: ciò che uccide i wiki personali non è né la lettura né la riflessione, ma la tenuta dei registri. Aggiornare i rimandi, mantenere aggiornati i riepiloghi, rilevare le contraddizioni: il carico di manutenzione cresce più rapidamente del valore del wiki, e lo si abbandona. Un modello non si stanca e può modificare quindici file in una sola passata. Karpathy ricollega l'idea al Memex immaginato da Vannevar Bush nel 1945.
#Prerequisiti per un wiki gestito da un modello locale
Il gist non presuppone alcun fornitore specifico. Serve un agente capace di leggere e scrivere file, guidato da un modello. In locale, questo si traduce nei seguenti componenti.
- Ollama, aggiornato
- Serve il modello su http://localhost:11434. Il comando ollama launch usato più avanti esiste solo nelle versioni recenti. L'installazione è trattata nella nostra guida «Installare Ollama».
- Un agente con accesso ai file
- Un'interfaccia di conversazione non basta: serve uno strumento che apra, crei e modifichi file sul disco. L'esempio seguente utilizza OpenCode, un agente open source nel terminale citato nel gist, che legge un file AGENTS.md collocato nella radice della cartella.
- Un modello che sa chiamare strumenti
- La lettura e la scrittura dei file avvengono tramite chiamate agli strumenti. Scegli un modello che mostri la capacità tools nella libreria Ollama. La nostra guida «OpenCode + Ollama» ne elenca diversi, tra cui qwen3-coder:30b, devstral-small-2:24b e gpt-oss:20b.
- Memoria per il contesto
- Riferimenti in Q4_K_M per i soli pesi: circa 5 GB per 7 miliardi di parametri, 9 GB per 14 miliardi, 19 GB per 32 miliardi. La documentazione di Ollama richiede almeno 64 000 token di contesto per gli agenti, che si aggiungono a queste cifre.
- Git
- Il wiki non è altro che una cartella di file Markdown: il gist osserva che trasformarlo in un repository git fornisce la cronologia delle versioni senza aggiungere nulla.
- Obsidian (facoltativo)
- Per leggere il wiki, seguire i link e visualizzare il grafo delle pagine. Va bene qualsiasi editor Markdown; Obsidian non interviene nella redazione.
#Configurazione con Ollama, passo dopo passo
I comandi sono scritti per macOS e Linux; su Windows, la soluzione più semplice è usare WSL. La struttura delle cartelle e il file delle convenzioni sono esempi da adattare: il gist precisa che la struttura delle cartelle, le convenzioni e il formato delle pagine dipendono dal tuo ambito e dal tuo modello, e che tutto è facoltativo e modulare.
- 01Creare la cartella e il repositoryUna cartella per le fonti grezze, una cartella per le pagine, un indice, un registro, il tutto sotto git.
- 02Scrivere il file delle convenzioniUn AGENTS.md nella radice che descrive la struttura, le regole di scrittura e le tre procedure: acquisizione, interrogazione, verifica.
- 03Avviare il modello e l'agenteOllama serve un modello in grado di chiamare strumenti, con 64 000 token di contesto; OpenCode si apre nella cartella del wiki.
- 04Acquisire una prima fonteUn solo documento, elaborato sotto i tuoi occhi, riletto e poi registrato in git.
- 05Interrogare e organizzare le risposteLe domande si pongono al wiki; le sintesi utili diventano pagine.
- 06Verificare regolarmenteUn controllo che elenca le contraddizioni, le pagine orfane e i collegamenti interrotti.
#1. Creare la cartella e il repository
La cartella raw/ riceverà i tuoi documenti, la cartella wiki/ le pagine redatte dal modello. I nomi sono liberi, purché la separazione tra le due rimanga evidente.
#2. Scrivere il file delle convenzioni
È il componente più importante. Senza di esso, l'agente improvvisa una struttura diversa a ogni sessione. Crea un file AGENTS.md nella radice di ~/wiki, per esempio sulla base seguente:
Questo file è opera nostra, non di Karpathy: il gist descrive il ruolo del file delle convenzioni senza fornirne un modello e raccomanda di farlo evolvere insieme al modello man mano che scopri cosa funziona nel tuo ambito. Mantienilo breve. L'agente lo rilegge a ogni sessione e ogni riga occupa spazio nel contesto.
#3. Avviare il modello e l'agente
Scarica un modello in grado di chiamare gli strumenti, poi apri OpenCode nella cartella del wiki. Il comando ollama launch opencode avvia OpenCode con un modello fornito da Ollama, da scegliere nel selettore. L'installazione di OpenCode stessa è descritta nella nostra guida «OpenCode + Ollama».
Resta il contesto. Secondo la documentazione di Ollama, la finestra predefinita dipende dalla VRAM (4 000 token sotto i 24 GB, 32 000 tra 24 e 48 GB), mentre gli agenti ne richiedono almeno 64 000. La variabile OLLAMA_CONTEXT_LENGTH la imposta all'avvio del server; se Ollama è già in esecuzione come applicazione o come servizio, imposta il valore nei suoi parametri invece di avviare un secondo server.
Il comando ollama ps indica se il modello sta interamente sulla GPU. Se trabocca sulla CPU, ogni acquisizione diventa molto lenta: scegli un modello più piccolo prima di ridurre il contesto.
#4. Importare una prima fonte
Deposita un primo documento in raw/, preferibilmente in Markdown o come testo. Per le pagine web, il gist segnala l'estensione Obsidian Web Clipper, che converte un articolo in un file Markdown. Poi impartisci la consegna all'agente:
L'agente legge la fonte, propone i punti chiave, poi crea e modifica le pagine. Rileggi il risultato prima di andare oltre: la pagina di riepilogo, le pagine delle entità create, l'indice, il registro. Poi salva lo stato del wiki.
#5. Interrogare e archiviare le risposte
Dopo alcune fonti, poni le tue domande all'agente nella stessa cartella. Chiedigli esplicitamente di citare le sue pagine e le sue fonti e di dire cosa non contiene il wiki.
#6. Verificare regolarmente
Ogni qualche acquisizione, esegui un controllo. Chiedi un elenco dei problemi prima di qualsiasi correzione: mantieni il controllo su ciò che viene unito, rinominato o eliminato.
Il registro può essere consultato senza agente. Con il prefisso regolare delle voci, il comando fornito nel gist mostra le ultime operazioni (solo il percorso è adattato alla nostra struttura):
#LLM Wiki o RAG: ciò che il modello non sostituisce
Il gist contrappone il wiki al RAG per far capire l'idea. Non dice che uno sostituisca l'altro, e questa guida non lo dice neppure: i due approcci rispondono a situazioni diverse. Ecco cosa li distingue, senza numeri, perché non abbiamo misurazioni da presentare.
- Il momento del lavoro
- Un RAG lavora al momento della domanda: cerca degli estratti, poi il modello redige la risposta. Il wiki lavora al momento dell'acquisizione: la sintesi viene scritta una volta, poi riletta a ogni domanda.
- Ciò che viene conservato
- Un RAG conserva estratti e relativi vettori, illeggibili così come sono. Il wiki conserva pagine redatte che puoi leggere, correggere e sottoporre a versionamento.
- L'infrastructure
- Un RAG richiede un modello di embeddings, un database vettoriale e una strategia di suddivisione. Il wiki richiede una cartella e un agente. Secondo il gist, l'indice è sufficiente su scala moderata (nell'ordine di un centinaio di fonti e di qualche centinaio di pagine) ed evita di predisporre un'infrastruttura RAG basata sugli embeddings.
- La fedeltà alle fonti
- Un RAG restituisce al modello passaggi originali. Il wiki gli restituisce una riformulazione scritta da un modello, con il rischio di errore che ciò comporta.
- Il volume
- Un RAG è progettato per corpus di grandi dimensioni. Il wiki è limitato da ciò che il modello può leggere in una sola volta: l'indice, le pagine utili e la fonte devono rientrare nella finestra di contesto.
Oltre una scala moderata, il gist reintroduce la ricerca. Cita qmd, un motore di ricerca locale per file Markdown che combina BM25, ricerca vettoriale e riordinamento tramite LLM, utilizzabile dalla riga di comando o come server MCP. Un wiki di grandi dimensioni finisce quindi per basarsi sui componenti di un RAG, applicati a pagine già sintetizzate anziché ai documenti grezzi. I due approcci si combinano più di quanto si escludano.
In pratica, conserva un RAG classico quando il corpus è voluminoso o cambia continuamente (documentazione aziendale, ticket, contratti), quando la risposta deve riprodurre il passaggio esatto di un documento, oppure quando più persone con autorizzazioni diverse interrogano lo stesso database. LLM Wiki è più adatto a un argomento che si approfondisce per settimane: monitoraggio, ricerca, lettura di un libro, preparazione di un dossier. Sono usi che il gist stesso cita.
#Limiti da conoscere, soprattutto in locale
- Anche gli errori si accumulano
- Un errore di riepilogo scritto in una pagina verrà riletto, citato e propagato alle pagine successive. In un RAG, una risposta sbagliata scompare con la conversazione; in un wiki, rimane. Questo è il motivo per cui si rimanda sistematicamente alle fonti grezze e si rileggono le modifiche.
- Un modello locale ha meno margine di manovra
- L'acquisizione richiede di seguire istruzioni lunghe, leggere diversi file e modificarne una decina senza dimenticarne nessuno. In genere i modelli piccoli gestiscono peggio questo tipo di attività lunga rispetto ai modelli più grandi eseguiti dagli agenti citati nel gist. Valuta sulle tue fonti, iniziando in piccolo.
- La finestra di contesto pone un limite a tutto
- Una fonte molto lunga, un indice cresciuto e dieci pagine da rileggere non entrano sempre in 64 000 token. Suddividi le fonti voluminose per capitolo e mantieni le pagine brevi.
- L'ingestione richiede tempo
- Ogni fonte innesca una serie di letture e scritture. Su una macchina modesta, prevedi un'elaborazione fonte per fonte anziché quella di import d'un'intera biblioteca in una sera.
- La struttura si altera
- Senza regole rigide, l'agente crea duplicati (la stessa entità con due nomi) e pagine che nulla collega. Le regole di denominazione del file delle convenzioni e il passaggio di verifica servono a questo.
#Suggerimenti e risoluzione dei problemi
- L'agente salta alcuni passaggi dell'acquisizione
- Il contesto è probabilmente troppo breve: le istruzioni escono dalla finestra durante l'esecuzione. Controlla il valore di OLLAMA_CONTEXT_LENGTH, accorcia AGENTS.md o suddividi la fonte.
- L'agente descrive ciò che farebbe, senza scrivere nulla
- Il modello gestisce male le chiamate agli strumenti. Scegli un modello che mostri la capacità tools nella libreria Ollama.
- La stessa entità compare con due nomi
- Chiedi un passaggio di verifica mirato ai duplicati, convalida le fusioni una per una, poi aggiungi la regola di denominazione mancante al file delle convenzioni.
- L'indice diventa troppo lungo
- Dividilo per categoria, con un indice principale che rimanda a indici secondari, oppure aggiungi uno strumento di ricerca nei file Markdown, come qmd, citato dal gist.
- Le risposte ignorano le pagine esistenti
- L'indice non è stato aggiornato durante un'importazione. Fai ricostruire l'indice a partire dal contenuto della cartella wiki/, poi verifica il registro.
#Implementazioni pronte all'uso
Non sei obbligato a scrivere tutto a mano. Hermes Agent, l'agente open source di Nous Research, documenta una skill integrata chiamata llm-wiki, inserita nella categoria ricerca, che riprende questo modello. Se usi già questo agente con Ollama, è un punto di partenza più rapido; la pagina di documentazione, collegata qui sotto, ne descrive il funzionamento. Il principio resta lo stesso: leggi le convenzioni prima di affidargli le tue fonti.
#Fonti
Tutto ciò che viene detto del modello proviene dal post e dal gist di Andrej Karpathy. Le impostazioni di Ollama e OpenCode provengono dalla loro documentazione, già citata nella nostra guida «OpenCode + Ollama». Rileggi queste pagine prima di incollare un comando: questi strumenti evolvono rapidamente.
#Per approfondire
Il LLM Wiki si trova all'incrocio di diversi argomenti già trattati sul sito. Ognuna di queste guide copre ciò che questa lascia volutamente da parte.
- RAG locale: introduzione
- Embeddings, database vettoriale, suddivisione: il funzionamento del RAG classico, da conoscere per sapere quando resta la scelta giusta. https://quelllm.fr/guide/rag-local-introduction
- Obsidian + LLM locale
- Collegare un modello locale a un vault Obsidian con i plugin Copilot e Smart Connections, per conversare con note scritte da te. https://quelllm.fr/guide/obsidian-llm-local-ollama
- NotebookLM in locale
- Gli strumenti open source che riproducono i taccuini delle fonti e le risposte citate, senza wiki intermedio. https://quelllm.fr/guide/notebooklm-local-alternative
- Fine-tuning vs RAG
- Karpathy menziona nel suo post, come pista di esplorazione, l'affinamento di un modello sui dati del suo database. Questa guida aiuta a decidere se ne vale la pena. https://quelllm.fr/guide/fine-tuning-vs-rag-choisir
- OpenCode + Ollama
- L'installazione dell'agente usato qui, la configurazione del contesto e le autorizzazioni. https://quelllm.fr/guide/opencode-ollama-agent-terminal
Un feedback, un errore, una precisazione? Facci sapere, così la guida migliora per tutti.