Finalmente ho trovato il tempo di leggere il gist di Karpathy su LLM Wiki (sì, in ritardo sul treno dell'hype XD).
E onestamente, l'intera idea si riduce a qualcosa di piuttosto semplice: "RAG aggiornabile".
1. Il problema
Quando gli LLM lavorano con i documenti, nulla si accumula. Ogni query — il modello recupera chunk, sintetizza da zero, dimentica. La conoscenza non viene mai compilata. E secondo me, ciò che conta ancora di più: quasi nessuna informazione utile viene estratta dai dialoghi stessi.
La RAG aiuta parzialmente (in senso lato — una cartella di file .md è anch'essa una RAG), ma la pipeline standard (che tutti usano) non ha aggiornamenti integrati, distillazione o auto-pulizia. La conoscenza finisce nell'indice una volta e poi resta lì, inattiva. Quel divario è esattamente ciò che LLM Wiki colma.
L'inversione di Karpathy: tra le fonti grezze e te si trova un wiki in markdown che l'agente scrive e aggiorna incrementalmente. Compila una volta, mantieni aggiornato.
2. Architettura: 3 livelli
- raw/ — fonti, immutabili. L'agente non scrive qui.
- wiki/ — il cuore del sistema; pagine markdown (entità, concetti) che l'LLM scrive e collega tra loro. Essenzialmente, conoscenza a forma di grafo.
- CLAUDE.md — solo il manuale su come eseguire LLM Wiki. Contiene: formato pagina, convenzioni per i collegamenti, flusso di importazione, regole di lint. La cosa che trasforma Claude da chatbot a manutentore disciplinato del wiki.
Abbastanza per centinaia di pagine con zero ottimizzazione aggiuntiva:
3. Operazioni
Tre operazioni — viene subito voglia di disegnarle come funzioni API:
- Ingest -> add(source: file | list[file]). Inserisci una fonte -> l'agente legge -> discute con te -> scrive un riepilogo -> aggiorna l'indice -> modifica le pagine delle entità correlate -> aggiunge al log. Una fonte tocca 10-15 pagine.
- Query -> search(prompt: str). L'op più importante. Risponde alla tua domanda + (LA PARTE CHIAVE) archivia automaticamente la sintesi nel wiki come nuove pagine. L'esplorazione si accumula invece di morire nella cronologia della chat. Sotto il cofano, è essenzialmente add(source=dialogue).
- Lint -> lint(). Nessun argomento. Periodicamente esamina il wiki: contraddizioni, pagine orfane, fatti obsoleti, riferimenti incrociati mancanti. Attivazione — ogni N messaggi utente, o un contatore di righe modificate. Facile da collegare a /schedule.
Mi ricorda molto Claude Dreaming — penso che Dreaming sia parzialmente ispirato a questo schema (anche se il suo set di funzioni è leggermente diverso).
4. Indicizzazione
Due file speciali rendono il wiki navigabile:
- index.md — stato attuale. Catalogo di ogni pagina con una riga di descrizione. L'agente lo legge per primo su ogni query — è il contesto minimo "cosa c'è in questo wiki".
- log.md — registro di tutti gli eventi, in formato libero. Timeline append-only. Se le righe seguono una forma coerente (es.
## [AAAA-MM-GG] ingest | titolo), il log si filtra facilmente con gli strumenti unix standard — utile per audit.
index.md può scalare ulteriormente (indice vettoriale, BM25, GraphDB, ...) — ne parlerò in un post separato.
5. Punti chiave
Ecco come lo inquadrerei: non è una scelta tra RAG e LLM Wiki — sono due punti sullo stesso asse di "memoria che si accumula".
La RAG non deve essere per forza un database vettoriale — una cartella di file markdown è anch'essa una RAG.
Quindi si può riformulare LLM Wiki come una RAG con tre cose aggiunte sopra:
- Un livello di riassunto.
- Scrittura (quasi) libera della struttura a quel livello di riassunto.
- Audit strutturale periodico + auto-miglioramento (CRON).
