Il problema del RAG: ogni query parte da zero

Da quando i RAG (Retrieval-Augmented Generation) sono diventati il pattern standard per dare contesto agli LLM, ci siamo abituati a un compromesso silenzioso: ogni domanda è un viaggio nel buio, in cui il sistema cerca chunk di documenti, li infila nel prompt e spera per il meglio.

Funziona. A volte. Ma c'è un difetto strutturale: la conoscenza non si accumula mai. Ogni query è amnesica. Ogni risposta è una nuova ricostruzione da zero.

Karpathy entra in scena

Il 18 aprile 2026 Andrej Karpathy pubblica un gist su GitHub intitolato llm-wiki.md. Nessun annuncio fancy. Nessun paper. Solo un file markdown e un'idea che, in due settimane, ha generato circa una dozzina di implementazioni open-source.

L'idea è semplice. Quasi banale. Per questo è geniale.

Il pattern LLM Wiki in tre righe

Non chiedere al modello di cercare ogni volta. Chiedigli di compilare la conoscenza una volta sola, in pagine wiki strutturate e interconnesse. Poi fai girare le query su quell'artefatto.

In pratica:

  1. Ingest — l'LLM legge le fonti (documenti, paper, codice, ticket).
  2. Synth — invece di chunk-are e indicizzare embeddings, l'LLM scrive un

set di pagine markdown interlinkate. Una vera wiki.

  1. Query — le risposte arrivano dalla wiki compilata, che ora vive direttamente

nel context window.

Perché funziona

Gli LLM moderni sono eccellenti a sintetizzare. Pessimi (o meglio, sottoutilizzati) quando ridotti a motori di lookup. Il RAG tradizionale li tratta come bibliotecari. LLM Wiki li tratta come autori.

Quando arriva nuova informazione, il sistema non la deposita in un vector store: riscrive la pagina pertinente, collega le nuove idee a quelle esistenti, aggiorna i riferimenti. Come farebbe un essere umano con un buon notebook.

I numeri che fanno girare la testa

Secondo le prime analisi indipendenti, su knowledge base di piccola/media dimensione LLM Wiki riduce l'uso di token fino al 95% rispetto al caricamento ingenuo dei documenti. E la complessità di sistema crolla: niente più embedding store, niente re-ranker, niente chunking strategy da bilanciare a mano.

Quando ha senso (e quando no)

Sì, considera LLM Wiki se:

codebase interna).

No, resta su RAG se:

essere più auditabile).

Il punto

Non è "RAG è morto". È "abbiamo usato male gli LLM per due anni". Karpathy ci ha ricordato che, se hai a disposizione un sintetizzatore eccellente, forse vale la pena chiedergli di organizzare la conoscenza una volta sola, invece di costringerlo a riassemblarla a ogni query.

E questo, in un'industria che ha costruito stack interi su ChromaDB e LangChain, è abbastanza per cambiare le carte in tavola.

Da provare

llm-wiki — scegli quella più vicina al tuo stack.

di Mehul Gupta.

Probabilmente non sostituirà tutto. Ma se hai un caso d'uso in cui la conoscenza deve accumularsi, è il momento di smettere di fare retrieval e iniziare a scrivere.