Il livello di conoscenza AI: 127 pagine, nessun database vettoriale, e cosa ho sbagliato

Andrej Karpathy ha pubblicato un gist nell'aprile 2026 descrivendo un pattern per costruire basi di conoscenza personali con i LLM. Ha ottenuto 99.000 bookmark in una settimana. Diverse implementazioni sono diventate open source nel giro di pochi giorni. graphify è stato rilasciato in 48 ore e ha raccolto altri 27.000. Il pattern ha avuto risonanza perché ha dato un nome a un problema familiare: la maggior parte degli agenti non ha memoria persistente tra le sessioni. Ogni conversazione riparte da zero. Si rispiegano il proprio settore, gli obiettivi, il tono, il contesto, e l'output risulta generico perché l'input non aveva nulla su cui lavorare.

Utilizzo un livello di conoscenza in webvise per ricerca e documentazione di progetto. Ecco cosa ho imparato.

Gli agenti dimenticano tra una sessione e l'altra.

Il flusso di lavoro AI standard è stateless. Si apre una chat, si spiega cosa serve, si riceve una risposta, si chiude. Alla sessione successiva, stessa spiegazione. Il contesto costruito nel frattempo è andato. La maggior parte delle persone compensa scrivendo prompt più lunghi, incollando documenti di background o caricando file all'inizio di ogni sessione. Funziona, ma non scala. Prima o poi la finestra di contesto si esaurisce, la qualità degrada e si passa più tempo a preparare il prompt che a svolgere il lavoro.

Il livello di conoscenza risolve il problema a livello infrastrutturale. Invece di riempire ogni prompt di contesto, si dà all'agente accesso a una base di conoscenza persistente e strutturata che legge prima di fare qualsiasi cosa. L'agente conosce già il settore, il tono, i progetti, la cronologia. Si salta la rispiegazione e si arriva direttamente al lavoro.

Tre livelli, nessun database vettoriale

L'architettura si compone di tre parti:

• Fonti grezze. Una cartella di documenti immutabili: articoli, appunti, trascrizioni, PDF, registrazioni di riunioni, ricerche. L'agente li legge ma non li modifica mai. Sono la fonte di verità.
• La wiki. Una directory di file markdown generati dall'LLM con riferimenti incrociati. Pagine di entità, pagine di concetti, sintesi, confronti, playbook. L'agente gestisce questo livello interamente: crea pagine, le aggiorna quando arrivano nuove fonti, mantiene i riferimenti incrociati e garantisce la coerenza. Si legge, l'agente scrive.
• Lo schema. Un documento di configurazione (CLAUDE.md, AGENTS.md o equivalente) che indica all'agente come è strutturata la wiki, quali convenzioni seguire e quali flussi di lavoro eseguire. È ciò che trasforma un LLM generico in un manutentore disciplinato della wiki.

La wiki è un artefatto compilato. L'agente non ri-deriva la conoscenza a ogni query. Compila una volta, incrocia i riferimenti e mantiene tutto aggiornato. Quando si aggiunge una nuova fonte, l'agente la integra nella wiki esistente, aggiornando ogni pagina pertinente. Quando si pone una domanda, l'agente legge pagine pre-compilate invece di cercare tra i documenti grezzi.

Perché questo supera RAG per la maggior parte dei casi d'uso

RAG ri-deriva le risposte al momento della query suddividendo i documenti in chunk e cercando frammenti rilevanti. L'approccio della wiki compilata salta tutto questo. Il benchmark di graphify ha misurato 71,5x meno token per query nel confronto pubblicato; i risultati dipendono dalle caratteristiche del corpus e dalla distribuzione delle query. Le misurazioni mostrano circa 1.000 token di contenuto del vault per query, rispetto ai 3.000 o più token che una tipica pipeline RAG inietta.

È disponibile un confronto tecnico completo tra RAG e recupero basato su indice. In sintesi: nei carichi di lavoro analizzati, l'approccio della wiki compilata ha superato RAG in termini di accuratezza, costo e complessità operativa. Nessun database vettoriale, nessun modello di embedding, nessuna strategia di chunking, nessun job di re-indicizzazione. Cinque comandi shell e un file di indice mantenuto.

L'evoluzione è avvenuta in tre fasi: RAG one-shot dal 2020 al 2023, RAG agentivo con recupero multi-hop dal 2023 al 2024, e context engineering dal 2025 in poi, dove l'agente costruisce il proprio contesto da più fonti. Il livello di conoscenza è l'infrastruttura per questa terza fase. La maggior parte dei team sta ancora costruendo per la prima.

Cosa ho imparato gestendone uno

La wiki interna conta attualmente 127 pagine strutturate in sette categorie: persone, aziende, concetti, playbook, raccolte, sintesi e strumenti. Ogni pagina segue un template standard con frontmatter YAML, riferimenti incrociati tramite wikilink di Obsidian e attribuzione delle fonti. L'agente esegue sei operazioni definite: ingest, aggiornamento conversazionale, query, lint, arricchimento e riorganizzazione.

• Il file di schema è l'elemento centrale. Tutto il resto ne deriva. Uno schema ben scritto produce una wiki disciplinata con convenzioni coerenti. Uno schema vago produce allucinazioni e proliferazione di contenuti. La versione attuale è di circa 200 righe e copre struttura delle directory, formato delle pagine, tutte e sei le operazioni, convenzioni di denominazione e gestione delle contraddizioni. Ci sono volute diverse iterazioni per perfezionarlo.
• La deduplicazione preventiva evita la proliferazione di pagine. La regola: prima di creare qualsiasi nuova pagina, cercare nella wiki esistente contenuti sovrapposti. Se una pagina esistente copre il 60% o più dello stesso terreno, si arricchisce quella pagina invece di crearne una nuova. Senza questa regola, la wiki si riempie di pagine ridondanti che frammentano la conoscenza in pezzi inutilizzabili.
• Le query si accumulano nella base di conoscenza. Quando si pone una buona domanda e si ottiene una risposta utile, quella risposta viene archiviata come nuova pagina wiki. La volta successiva che qualcuno pone una domanda correlata, l'agente ha già una sintesi pre-compilata da cui attingere. È l'effetto compounding che migliora il sistema nel tempo, non solo lo fa crescere.
• La qualità dell'ingest dipende interamente dalla disciplina. Caricare un articolo grezzo e dire 'indicizzalo' produce un riassunto superficiale. Analizzare la fonte con l'agente, discutere i punti chiave e indicare cosa enfatizzare produce pagine che restano utili man mano che la wiki cresce. Il flusso di lavoro è rigoroso: pulire il file grezzo, discutere i takeaway principali, attendere l'approvazione, poi estrarre completamente.
• Il file di indice è il sistema di recupero. L'indice radice è di 22 righe. Ogni sottodirectory ha il proprio indice con l'elenco di ogni pagina e una descrizione in una riga. L'agente legge l'indice radice in circa 400 token, identifica la sottodirectory corretta, legge quell'indice, poi recupera le pagine specifiche necessarie. La maggior parte delle query si conclude con tre letture e circa 1.000 token di contenuto del vault.

Lo schema è il file più importante che scriverà

Karpathy lo chiama schema. In webvise si chiama CLAUDE.md. Alcuni framework lo suddividono in un Knowledge Base Layer e una Brand Foundation. Il nome è secondario. Il fatto operativo è che questo singolo file controlla il comportamento dell'agente in ogni sessione.

Uno schema efficace definisce:

• Struttura delle directory. Dove vanno le fonti grezze, dove vanno le pagine wiki, come sono organizzate nelle categorie.
• Formato delle pagine. Campi del frontmatter, struttura delle sezioni, regole di attribuzione delle fonti, convenzioni di riferimento incrociato.
• Operazioni. Flussi di lavoro passo per passo per indicizzare le fonti, rispondere alle query, eseguire controlli di qualità e mantenere la wiki nel tempo.
• Controlli di qualità. Cosa rende una pagina completa. Quando segnalare incertezza. Come gestire fonti in conflitto. La regola che ogni affermazione deve poter essere ricondotta a una fonte.

Senza queste indicazioni, l'agente improvvisa. Crea pagine in posizioni casuali, usa formati incoerenti, duplica contenuti tra le pagine e si discosta dalle convenzioni a ogni sessione. Lo schema previene questa deriva. Va trattato come codice di produzione: ogni modifica è deliberata e testata con un ingest reale.

Come costruirne uno in 20 minuti

Non servono 17 file, un grafo di competenze sui contenuti o una pipeline di embedding personalizzata. Bastano quattro elementi:

• Un vault Obsidian con due cartelle. `raw/` per i documenti sorgente e `wiki/` per le pagine generate dall'agente. Aprirlo in Obsidian per la vista grafo e la navigazione.
• Un file di schema. Partire dal gist di Karpathy. Personalizzare la struttura delle directory e il formato delle pagine per il proprio dominio. Mantenerlo sotto le 200 righe per iniziare.
• Un agente LLM con accesso ai file. Claude Code, OpenAI Codex, o qualsiasi agente in grado di leggere e scrivere file markdown. Puntarlo al vault. Leggerà lo schema all'avvio.
• La prima fonte. Inserire un articolo, un insieme di appunti o un documento in `raw/`. Chiedere all'agente di indicizzarlo. Osservarlo creare pagine wiki, costruire riferimenti incrociati e aggiornare l'indice.

Questo è l'intero ciclo. Il sistema migliora ogni giorno perché ogni fonte aggiunta e ogni domanda posta arricchisce la wiki. Il primo ingest richiede 10 minuti di attenzione attiva. Al ventesimo, l'agente conosce il dominio abbastanza bene da estrarre e incrociare i riferimenti con una guida minima.

Strumenti opzionali per la crescita: qmd di Tobi Lutke per ricerca ibrida locale con BM25 e recupero vettoriale una volta superato il limite delle 300 pagine. L'estensione Obsidian Web Clipper per inserire rapidamente articoli web nella cartella raw. Dataview per eseguire query sul frontmatter delle pagine. Git per la cronologia delle versioni. Nessuno di questi è necessario per iniziare.

Cosa non conta

La maggior parte della complessità associata ai sistemi di conoscenza AI è overhead per problemi che non si hanno ancora. Un database vettoriale per 200 documenti, un modello di embedding personalizzato quando un indice mantenuto gestisce il recupero, una pipeline di re-indicizzazione quando aggiungere un documento significa scrivere un file, una strategia di chunking quando la pagina è l'unità. Niente di tutto ciò è necessario alla scala in cui opera la maggior parte delle aziende.

Il pattern funziona perché il markdown è semplice e i LLM sono bravi a leggerlo e scriverlo. Il costo infrastrutturale è zero. Il costo di manutenzione è basso perché l'LLM gestisce gli aggiornamenti dell'indice; una revisione umana periodica rimane consigliata per garantire l'accuratezza. Il vero costo è la disciplina nel mantenere lo schema onesto e l'alta qualità dell'ingest. È un problema umano, non tecnologico.

Casi d'uso aziendali

La stessa architettura funziona a scala aziendale. Al posto degli appunti personali si usano documentazione clienti, playbook di vendita, guide di onboarding e procedure operative interne. Al posto dell'agente di una singola persona si ha l'agente di ogni membro del team che legge da una base di conoscenza condivisa.

Il pattern è identico: le fonti grezze entrano, l'agente compila pagine strutturate, i riferimenti incrociati si costruiscono automaticamente, gli esseri umani validano. La differenza è che un livello di conoscenza condiviso rende i nuovi membri del team produttivi da subito. Il loro agente conosce già la storia dei clienti, le convenzioni interne e il contesto del progetto. Nessuna rampa di sei settimane. Nessuna conoscenza tribale rimasta nella testa di qualcuno.

Karpathy la chiama LLM wiki. Eric Osiu la chiama cervello condiviso. Cody Schneider la chiama data warehouse. Il nome continua a cambiare. Il pattern no: gli agenti hanno bisogno di conoscenza compilata e strutturata per svolgere un lavoro utile. Senza contesto persistente, i prompt operano senza la conoscenza istituzionale di cui hanno bisogno.

webvise costruisce livelli di conoscenza per le aziende che vogliono che i propri agenti AI sappiano davvero di cosa stanno parlando. Se si trascorre più tempo a spiegare il contesto agli strumenti che a ricavarne valore, questo è il problema che viene risolto. Contatti.