LLM Wiki, RAG o Graphify: come dare conoscenza agli agenti
Wiki compilata, retrieval e knowledge graph risolvono problemi diversi
Una LLM Wiki è una base di conoscenza compilata in pagine leggibili, collegate e pensate per essere navigate da un agente. RAG recupera frammenti rilevanti da un corpus indicizzato a ogni domanda. Graphify rappresenta un terzo filone: trasforma codice, documenti e media in un knowledge graph interrogabile. La scelta dipende da dimensione, volatilità, bisogno di sintesi e relazioni tra le fonti.
Risposta breve
Una LLM Wiki serve a trasformare conoscenza grezza in pagine strutturate che un agente può leggere, seguire e riusare. RAG serve a recuperare frammenti aggiornati da molti documenti. Graphify serve quando le relazioni tra elementi contano quanto i testi: codice, schema SQL, infrastruttura, docs e decisioni collegate in un grafo.
- LLM Wiki: migliore per corpus piccoli o medi che devono essere sintetizzati, organizzati e riletti spesso.
- RAG: migliore per knowledge base grandi, dinamiche, multi-sorgente o filtrate per permessi.
- Graphify: interessante quando vuoi interrogare connessioni tra file, moduli, schemi, documenti e concetti.
Confronto rapido
| Criterio | LLM Wiki | RAG o Graphify |
|---|---|---|
| Forma della conoscenza | Pagine sintetiche, collegate e leggibili come una wiki costruita per agenti | RAG usa frammenti recuperati al momento; Graphify usa nodi e relazioni interrogabili |
| Domande migliori | Sintesi, onboarding, ragionamento multi-hop, orientamento e decisioni tra fonti | RAG: lookup e fonti aggiornate. Graphify: connessioni, dipendenze, percorsi e impatto |
| Aggiornamento | Va ricompilata o aggiornata quando cambia il corpus, ma offre struttura più stabile | RAG si aggiorna reindicizzando fonti; Graphify aggiorna estrazioni, graph.json e report |
| Governance | Semplice se il corpus è pubblico, personale o condiviso da tutto il team | RAG è più adatto a permessi e tenancy; Graphify è più adatto a conoscenza tecnica versionata |
| Rischio principale | Può diventare una bella sintesi vecchia se non esiste un ciclo di aggiornamento | RAG può recuperare contesto sbagliato; Graphify può inferire relazioni ambigue o rumorose |
Scenari pratici
Il costo qui è soprattutto manutenzione del contesto: una LLM Wiki costa compilazione e cura, un sistema RAG costa pipeline e debugging del retrieval, un grafo costa estrazione di relazioni e aggiornamento della struttura.
Corpus di paper o documenti da sintetizzare
20-50 fonti scelte · Pagine collegate e claim verificabili
Scelta
LLM Wiki
Quando conviene
Vuoi una mappa stabile che colleghi concetti, evidenze e contraddizioni
Qui il pattern LLM Wiki è forte: compila la conoscenza in una struttura che l'agente può rileggere e attraversare.
Knowledge base aziendale viva
Drive, ticket, documenti, wiki interne · Risposte con fonti e permessi
Scelta
RAG
Quando conviene
Le fonti cambiano, sono molte e non devono essere viste da tutti allo stesso modo
Quando entrano permessi, aggiornamenti frequenti e molte fonti, retrieval governato batte una wiki manuale.
Codebase con schema, infra e docs
Codice, SQL, Terraform, Markdown · Knowledge graph, report e query
Scelta
Graphify
Quando conviene
Le relazioni tra componenti sono più importanti di una semplice lista di pagine
Un grafo aiuta domande di impatto: cosa collega auth al database, quali moduli dipendono da un servizio, dove vive una decisione.
Agent coding su un repo
AGENTS.md, skill, wiki e grafo · Task più coerenti e meno ricerca cieca
Scelta
Ibrido
Quando conviene
Istruzioni sempre valide più wiki o grafo, con retrieval solo per aree molto grandi
Dopo CLAUDE.md o AGENTS.md e le skill, scegli come rendere interrogabile la conoscenza: pagina, retrieval o grafo.
Cosa significa LLM Wiki
Una LLM Wiki è una base di conoscenza compilata per essere letta da un modello o da un agente: non una cartella casuale di documenti, ma pagine sintetiche, titoli espliciti, collegamenti, note di contesto e percorsi di lettura. Nel gist di Karpathy, l'idea è trattare la conoscenza come un artefatto vivo: il modello legge fonti, scrive o aggiorna pagine wiki, accumula note nel tempo e poi usa quella wiki come memoria navigabile. La differenza rispetto al retrieval puro è proprio questa: non solo recuperare pezzi, ma costruire una rappresentazione persistente che cresce e migliora.
- Compila conoscenza: trasforma fonti grezze in pagine sintetiche, linkate e riusabili.
- Accumula nel tempo: una nuova fonte può aggiornare pagine esistenti invece di restare un chunk isolato.
- Aiuta il ragionamento multi-hop: l'agente può seguire collegamenti tra concetti, decisioni e prove.
- Richiede manutenzione: se la wiki non viene aggiornata o verificata, diventa una memoria elegante ma vecchia.
La teoria di Karpathy in pratica
Il punto teorico è che molta conoscenza utile non è solo da cercare, ma da organizzare. Un sistema RAG classico prende la domanda, cerca frammenti simili e li passa al modello. Una LLM Wiki aggiunge un passaggio di compilazione: il modello costruisce una struttura intermedia che può essere letta anche in sessioni successive. Per un agente, questa struttura può diventare una memoria esterna più maneggevole di una lista di chunk.
- Prima fase: ingestione di fonti, file o note grezze.
- Seconda fase: generazione o aggiornamento di pagine wiki con titoli e link interni.
- Terza fase: uso della wiki come contesto navigabile per rispondere, decidere o pianificare.
- Trade-off: più lavoro di compilazione rispetto a RAG, ma contesto più leggibile quando il dominio va capito nel tempo.
Cosa significa RAG
RAG, retrieval augmented generation, è un'architettura in cui l'applicazione cerca documenti o frammenti rilevanti in una base indicizzata e li passa al modello come contesto prima della risposta. A differenza di una wiki compilata, il sistema non prova necessariamente a costruire una mappa leggibile del corpus: recupera ciò che sembra pertinente alla domanda del momento.
- È forte su lookup, FAQ, documenti aggiornati e grandi archivi.
- Permette di filtrare per permessi, tenant, data, fonte o collezione.
- Richiede attenzione a chunking, ranking, citazioni, latenza e osservabilità.
- Non risolve da solo sintesi, ragionamento multi-hop e contraddizioni tra fonti.
Dove entra Graphify
Graphify è un esempio di filone graph-based: invece di trattare la conoscenza come pagine o chunk, estrae nodi e relazioni da codice, documenti, schemi SQL, infrastruttura, PDF, immagini e video. Il risultato non è solo una wiki, ma un grafo interrogabile con report, percorsi e connessioni. Questo è interessante per agenti di coding, perché molte domande non sono testuali: sono domande di dipendenza, impatto e collegamento.
- È utile quando vuoi chiedere cosa collega due moduli o quali file sono centrali.
- Può produrre un report leggibile e un graph.json interrogabile senza rileggere tutto ogni volta.
- Può convivere con AGENTS.md e skill: le istruzioni dicono quando consultare il grafo.
- Non sostituisce RAG se il problema principale è autorizzare utenti diversi su documenti diversi.
llms.txt e wiki generate non sono la stessa cosa
llms.txt è una porta di ingresso: dice agli agenti quali risorse pubbliche leggere e può puntare a versioni Markdown pulite. Una LLM Wiki è più ambiziosa: rielabora il corpus in pagine collegate. Code Wiki e DeepWiki stanno in questo spazio per i repository: generano documentazione, diagrammi, link alle fonti e chat contestuale per capire codebase complesse.
- llms.txt: mappa curata di URL e risorse leggibili da LLM.
- LLM Wiki: corpus riorganizzato in pagine e collegamenti.
- Code Wiki e DeepWiki: wiki generate per repository, onboarding e domande sul codice.
- Graphify: grafo interrogabile, più orientato a connessioni e impatto tra elementi.
La decisione pratica
La decisione non è ideologica. Parti da una LLM Wiki se la conoscenza va capita, sintetizzata e navigata come una mappa. Parti da RAG se serve recuperare fonti aggiornate, grandi o protette. Valuta Graphify se le domande migliori sono relazionali: quali componenti sono connessi, quali file cambiano insieme, quali concetti attraversano codice e documenti.
- Scegli LLM Wiki per sintesi, memoria personale, onboarding e knowledge base curate.
- Scegli RAG per archivi vivi, documenti numerosi, permessi e risposte con fonti aggiornate.
- Scegli Graphify per codebase e sistemi dove le relazioni sono il valore principale.
- Combina i pattern quando serve: wiki per orientamento, RAG per lookup, grafo per dipendenze.
Come scegliere il pattern giusto
La scelta migliore dipende dal tipo di conoscenza che vuoi rendere disponibile. Le istruzioni di progetto dicono all'agente come comportarsi sempre. Gli strumenti gli permettono di agire. Le procedure riusabili guidano workflow ripetuti. LLM Wiki, RAG e Graphify servono invece a rendere consultabile il sapere che l'agente non deve inventare.
- Se il problema è comportamento costante, lavora sulle istruzioni di progetto.
- Se il problema è usare strumenti o sistemi esterni, lavora su MCP o CLI.
- Se il problema è ripetere una procedura, crea una skill.
- Se il problema è capire conoscenza estesa, scegli tra wiki, retrieval e grafo.
Domande frequenti
Che cos'è una LLM Wiki?
È una base di conoscenza compilata in pagine leggibili, collegate e pensate per essere navigate da un modello o da un agente. Serve a trasformare documenti grezzi in contesto strutturato.
LLM Wiki sostituisce RAG?
No. LLM Wiki è forte quando vuoi sintesi e struttura. RAG è più adatto quando devi recuperare documenti aggiornati, numerosi o filtrati per permessi.
Graphify è una alternativa a RAG?
È una alternativa solo per alcuni problemi. Graphify punta a costruire un knowledge graph interrogabile, utile quando contano relazioni e dipendenze. RAG resta migliore per grandi archivi documentali dinamici.
llms.txt basta per una LLM Wiki?
No. llms.txt è una mappa di risorse, utile per dire agli agenti cosa leggere. Una LLM Wiki riorganizza il contenuto in pagine e collegamenti pensati per ragionare sul corpus.
Come capisco se sto esagerando con RAG?
Se il corpus entra in poche pagine curate, cambia raramente e non ha permessi complessi, probabilmente stai aggiungendo retrieval prima di aver sistemato la struttura della conoscenza.