Oltre la RAG: come LLM Wiki può trasformare la memoria d’impresa - Agenda Digitale

Le basi di conoscenza interne falliscono quasi sempre per la stessa ragione: nessuno ha tempo di mantenerle. Le suite enterprise come Microsoft 365 Copilot, costruito su Microsoft Graph, hanno reso più accessibile il patrimonio informativo già presente nei sistemi aziendali, ma non risolvono da sole il problema editoriale della memoria organizzativa: selezionare, collegare, aggiornare e rendere verificabile ciò che l’impresa sa.Il pattern “LLM Wiki” di Andrej Karpathy propone di affidare a un modello linguistico una parte di questa curatela continua. Non è uno standard industriale né una metodologia validata: è un’ipotesi operativa interessante da verificare in pratica.Indice degli argomenti

Il cimitero delle wiki aziendaliCosa risolve la ricerca enterprise, e cosa noIl pattern LLM Wiki di Karpathy: l’LLM come bibliotecarioPerché l’accumulo può contare più della RAGIl vincolo del costoLa governance va progettata prima della wikiI casi d’uso più promettenti della LLM WikiI rischi da tenere sotto controlloMigliorare la comprensione, non sostituirlaRiferimentiIl cimitero delle wiki aziendaliChiunque abbia lavorato in un’azienda di medie dimensioni conosce la scena. Si decide di mettere ordine nella conoscenza interna. Si sceglie uno strumento, si nomina un responsabile, si caricano i primi documenti con entusiasmo. Per qualche settimana le pagine crescono. Poi le priorità cambiano, e nessuno aggiorna più nulla. Sei mesi dopo la wiki contiene un cimitero di documenti che nessuno apre, perché nessuno si fida che siano attuali.Il problema è strutturale. Il valore di una base di conoscenza cresce con il numero di pagine, ma il costo di manutenzione cresce spesso più in fretta, perché ogni informazione nuova può rendere obsolete quelle vecchie, può richiedere nuovi collegamenti, può contraddire qualcosa scritto prima. Arriva il punto in cui tenere tutto coerente costa più del beneficio percepito, e a quel punto le persone smettono. Karpathy lo formula così: gli esseri umani abbandonano le wiki perché il peso della manutenzione cresce più velocemente del valore che ne ricavano (Karpathy, 2026).Aggiornare i riferimenti, tenere allineate le sintesi, annotare quando un dato nuovo smentisce un’affermazione vecchia, mantenere coerenti decine di pagine è lavoro ripetitivo che le persone competenti tendono a rimandare. Ed è anche un terreno in cui un modello LLM può essere utile, perché può rileggere, ricombinare e aggiornare molti file autonomamente. Può però farlo in modo affidabile solo se le fonti sono tracciate e se qualcuno resta responsabile della qualità finale.Cosa risolve la ricerca enterprise, e cosa noNegli ultimi anni le grandi suite hanno fatto passi avanti concreti. Microsoft 365 Copilot poggia su Microsoft Graph, che indicizza semanticamente dati e segnali dell’ambiente Microsoft 365 e consente al modello di rispondere tenendo conto dei contenuti pertinenti a cui l’utente è autorizzato ad accedere (Microsoft, 2026). Strumenti analoghi esistono in casa Google, con Gemini integrato in Workspace. Per un knowledge worker il guadagno si vede subito: fa una domanda e riceve una risposta sintetica con i riferimenti alle fonti.Funziona, ma ci sono dei limiti. La ricerca recupera i frammenti rilevanti nel momento della domanda e li sintetizza in una risposta. Tecnicamente si basa sul meccanismo RAG (retrieval augmented generation), che combina un modello generativo con una memoria esterna che viene consultata prima della risposta (Lewis et al., 2020). Però non accumula conoscenza: ogni query riparte quasi da zero. Karpathy propone invece di far leggere le fonti all’LLM, estrarne la conoscenza e integrarla progressivamente in una wiki strutturata, interconnessa e mantenuta nel tempo. In questo modo sintesi, contraddizioni, relazioni tra concetti e riferimenti non vengono ricostruiti ogni volta, ma diventano artefatti persistenti.La ricerca enterprise nasce per trovare, sintetizzare e contestualizzare informazioni presenti nei sistemi aziendali; non crea pagine dedicate alle entità ricorrenti, non traccia esplicitamente legami tra gli argomenti, non segnala quando due fonti si contraddicono. Manca il sistema di note interconnesse sul quale in definitiva si basano le wiki, dove il valore sta nei legami che attraversano le note e nelle idee che da quei legami emergono, più che nelle note prese separatamente.Microsoft Graph può aiutare a rispondere alla domanda “dove ho parlato di questo cliente?”, nel perimetro dei dati e dei permessi Microsoft 365. Diverso è costruire e tenere viva una pagina “cliente” che raccolga, colleghi e aggiorni nel tempo tutto ciò che l’azienda sa su di lui, mettendo in evidenza le tensioni tra informazioni di fonti diverse. La prima cosa è ricerca assistita; la seconda è memoria strutturata. Molte aziende oggi hanno strumenti sempre migliori per la prima e rischiano di scambiarli per la seconda.La differenza riguarda soprattutto la visibilità. Un conto è che un’informazione sia presente implicitamente nella memoria semantica di un sistema, raggiungibile solo se qualcuno formula la domanda giusta; un altro è che sia visibile e navigabile per una persona. Quando la conoscenza è esposta in un artefatto che si può sfogliare, la risposta a volte previene la domanda: vedendo la pagina si scopre ciò che non si sapeva di dover chiedere. Quando invece resta latente, recuperabile solo su interrogazione esplicita, la domanda potrebbe non nascere affatto, e l’informazione, pur essendoci, è come se non ci fosse.Il pattern LLM Wiki di Karpathy: l’LLM come bibliotecarioAndrej Karpathy, già responsabile dell’intelligenza artificiale in Tesla e tra i fondatori di OpenAI, ha pubblicato su GitHub nell’aprile del 2026 un documento breve intitolato LLM Wiki (Karpathy, 2026). LLM Wiki non è un software, non è uno standard, non è una ricerca peer-reviewed e non dimostra empiricamente che questo approccio sia superiore alle alternative. È un “idea file”, pensato per essere consegnato a un agente AI come Claude Code, Codex o strumenti simili, che poi lo adattano insieme alla persona e al dominio. Proprio per questo è interessante: non vende una piattaforma, descrive un pattern operativo.Invece di interrogare ogni volta i documenti grezzi, il modello costruisce e mantiene in modo incrementale una wiki persistente, cioè una raccolta strutturata e interconnessa di file di testo di tipo Markdown che si frappone tra la persona e le fonti originali. Quando arriva una fonte nuova, il modello la legge, ne estrae le informazioni chiave, le integra nelle pagine esistenti, rivede le sintesi dei temi, annota dove il dato nuovo contraddice un’affermazione precedente. La conoscenza viene compilata e tenuta aggiornata, invece di essere derivata di nuovo dalla ricerca a ogni interrogazione (Karpathy, 2026).La wiki è un artefatto che si compone nel tempo. I riferimenti incrociati sono già al loro posto, le contraddizioni già segnalate, la sintesi già allineata a tutto quello che si è letto, e l’insieme si arricchisce a ogni fonte aggiunta.L’architettura proposta da Karpathy è volutamente semplice e si articola su tre livelli. Le fonti grezze sono la collezione curata di documenti originali, articoli, verbali, dati: restano immutabili, il modello le legge senza toccarle, e costituiscono la fonte di verità. La wiki è la cartella di file Markdown generati dal modello, fatta di sintesi, pagine di entità, pagine di concetti, confronti, una panoramica generale: questo strato viene elaborato operativamente dal modello AI, ma deve restare sotto responsabilità umana. Lo schema, infine, è il documento di istruzioni che spiega al modello come è strutturata la wiki, quali sono le convenzioni e quali flussi seguire.Su questa architettura agiscono tre operazioni. L’ingestione (ingest) consiste nell’inserire nel sistema una fonte nuova e chiedere al modello di lavorarla: la legge, discute con noi i punti salienti, scrive una pagina di sintesi, aggiorna l’indice e le pagine collegate, registra nel log cosa è successo.L’interrogazione (query) consiste nel fare domande alla wiki: il modello AI cerca le pagine rilevanti, le legge e sintetizza una risposta con le citazioni, e le risposte migliori vengono archiviate a loro volta come nuove pagine. Il controllo periodico, che Karpathy chiama lint riprendendo un termine del mondo del software, consiste nel chiedere al modello di passare in rassegna la wiki per scovare contraddizioni, affermazioni ormai superate, pagine orfane senza collegamenti in entrata, concetti citati ma privi di una pagina propria, lacune da colmare con una ricerca, in una parola, farne la manutenzione.Uno strumento come Obsidian, con la sua visualizzazione a grafo di tutto il sistema di note, completa il sistema: gli dà un volto navigabile, perché trasforma la cartella di file generata dal modello in qualcosa che una persona può sfogliare ed esplorare facilmente, rendendo visibile ciò che altrimenti resterebbe una memoria latente.Figura 1 La visualizzazione a grafo di una LLM wiki attraverso ObsidianPerché l’accumulo può contare più della RAGLa differenza tra recuperare e accumulare è il punto decisivo. In un sistema RAG la qualità della risposta dipende dalla formulazione della domanda, dall’efficacia del retrieval e dalla sintesi fatta dal modello. In una wiki, invece, il lavoro intellettuale è già stato fatto: i collegamenti esistono, le sintesi sono pronte, le contraddizioni evidenziate. Al momento della domanda l’utente parte da una conoscenza già organizzata.Questo vantaggio, però, ha un limite di scala. Il metodo Karpathy dà il meglio su corpus contenuti e relativamente stabili, dove rileggere e ricompilare le pagine resta sostenibile. Quando i documenti diventano molto numerosi — decine o centinaia di migliaia, per giunta in continuo aggiornamento — far leggere e reintegrare ogni fonte al modello diventa lento e costoso, e una wiki mantenuta dal modello fatica a restare coerente. Su quei volumi un indice RAG resta l’unica via praticabile.Nel mezzo si lavora in modo ibrido, con il nucleo stabile di conoscenza in forma di wiki e i dati dinamici o massivi affidati al recupero.La memoria commerciale, le lezioni apprese sui progetti, il know-how che oggi vive nella testa di due o tre persone chiave possono spesso essere circoscritti a un dominio gestibile.Il vincolo del costoAffidare a un modello la manutenzione continua della conoscenza ha un costo in termini di token AI. Ogni ingestione, ogni controllo periodico che rilegge la wiki in cerca di incoerenze ha un prezzo. Il costo non dipende soltanto dal numero di documenti e dalla loro dimensione, ma anche dalla frequenza di aggiornamento e dal modello utilizzato.Il pattern stesso, però, suggerisce le leve di controllo. L’ingestione si può fare su fonti attentamente selezionate anziché in batch onnivori. Il controllo periodico non deve ripassare l’intera wiki ogni volta, ma può concentrarsi sulle pagine cambiate di recente. L’indice, quel file che cataloga tutte le pagine con una riga di descrizione ciascuna, permette al modello di leggere prima l’indice e poi solo le pagine pertinenti, evitando di trascinare nel contesto l’intero corpus. E il modello va calibrato in base al compito: le operazioni più semplici possono essere affidate a modelli meno costosi.Il costo in token va trattato come una voce di budget con un proprio indicatore di efficienza, da presidiare. Occorre chiedersi: “quanto ci costa tenere aggiornata una wiki critica e quanto vale per noi che lo sia?”. Finché quel rapporto regge, il progetto regge. Quando salta, conviene restringere il dominio, ridurre la frequenza dei controlli o spostare le attività di routine su modelli meno costosi.La governance va progettata prima della wikiPrima ancora di scegliere lo strumento, un’organizzazione deve decidere chi può alimentare la wiki, chi può leggerla, chi approva le pagine critiche e come si correggono gli errori. Una memoria aziendale assistita da LLM non è una chat privata: può diventare un deposito di decisioni, informazioni commerciali, valutazioni sui clienti, lezioni apprese e conoscenza tecnica. Per questo servono classificazione dei documenti, controllo degli accessi, tracciabilità delle modifiche, criteri di qualità e una procedura per correggere.Una wiki aziendale generata e aggiornata da un modello deve avere un proprietario, controlli proporzionati e criteri espliciti di affidabilità.I casi d’uso più promettenti della LLM WikiI contesti più adatti sono quelli in cui la mole documentale resta contenuta — orientativamente fino all’ordine di grandezza del migliaio di documenti — e in cui il valore sta soprattutto nella conoscenza da estrarre e collegare, non nella pura quantità di dati su cui cercare.La memoria delle decisioni, ad esempio. Verbali sparsi, thread di chat, ticket, allegati e mail di follow-up restano normalmente in silos separati. Trattati come fonti grezze, possono confluire in una pagina “stato dell’iniziativa” sempre aggiornata, con le azioni da fare, le questioni aperte, le contraddizioni emerse e le fonti verificabili.L’inserimento di nuove persone e il passaggio di consegne. Una parte enorme del tempo di onboarding se ne va a ricostruire un contesto che da qualche parte esiste già, solo che è frammentato e mai messo per iscritto. Una wiki tenuta viva dal modello accorcia quel tempo, perché il contesto è organizzato, collegato e interrogabile.La memoria di cliente e di progetto nelle funzioni commerciali, di delivery e di customer success. La posta in gioco è non perdere ciò che si è imparato su un cliente o su una commessa quando chi lo seguiva cambia ruolo o lascia l’azienda. Karpathy cita esplicitamente scenari di knowledge base alimentate da thread di chat, trascrizioni, documenti e chiamate (Karpathy, 2026).I rischi da tenere sotto controlloI rischi ci sono e vanno presidiati.Il primo è l’allucinazione e la deriva della conoscenza. Un modello che scrive il sapere “ufficiale” dell’azienda può introdurre errori che poi si propagano. La via d’uscita sta nella provenienza esplicita: ogni sintesi ad alto impatto deve poter essere ricondotta alle fonti che la giustificano, e le pagine critiche devono essere revisionate da una persona competente.Il secondo è l’obsolescenza silenziosa, quando una pagina non viene aggiornata dopo l’arrivo di nuove fonti contrastanti, ed è esattamente ciò che il controllo periodico serve a intercettare.Il terzo è la perdita di confidenzialità, cioè il caricamento di contenuti sensibili in strumenti privi di policy adeguate. Occorre verificare che le offerte business ed enterprise dei principali fornitori prevedano protezioni specifiche.Il quarto è l’eccesso di automazione, quando l’azienda lascia al modello la scrittura del sapere ufficiale senza revisione umana.I principi del GDPR su minimizzazione, limitazione della finalità, integrità, riservatezza e responsabilizzazione vanno applicati dall’inizio. In alcuni casi potrà servire anche una valutazione d’impatto, soprattutto se la wiki tratta dati personali o processi decisionali che incidono sulle persone.Migliorare la comprensione, non sostituirlaQuesti strumenti servono a migliorare la comprensione, non a sostituirla: resta il collo di bottiglia umano, ed è inevitabile che lo sia. Alla persona spettano la cura delle fonti, l’indirizzo dell’analisi, le domande giuste, la verifica delle conclusioni e la riflessione sul significato; al modello la manutenzione, non la responsabilità.Già nel 1945 Vannevar Bush immaginava il Memex, un archivio di conoscenza curato attivamente, con percorsi associativi in cui le connessioni valevano quanto i documenti stessi (Bush, 1945). Ciò che non sapeva risolvere era chi mantenesse tutti quei collegamenti: per ottant’anni la risposta è stata “una persona”, ed ecco perché le wiki aziendali sono spesso finite nel cimitero. Oggi quella manutenzione può essere eseguita da un modello AI, purché dentro un processo verificabile.Il consiglio operativo, per chi voglia provare, è di non partire in grande. Si scelga un solo dominio ad alto valore — onboarding, memoria delle decisioni o un portafoglio clienti — e per sei o otto settimane si attivi una wiki assistita dal modello con due metriche: tempo per recuperare una risposta affidabile, costo in token. Se il tempo diminuisce e il costo in token vale il vantaggio, si è costruito qualcosa che somiglia a una memoria organizzativa; altrimenti, si è solo aggiunto un altro strumento al cimitero.RiferimentiBush, V. (1945, July). As we may think. The Atlantic Monthly. https://www.w3.org/History/1945/vbush/vbush.shtmlKarpathy, A. (2026, April 4). LLM Wiki [GitHub Gist]. https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94fLewis, P., Perez, E., Piktus, A., Petroni, F., Karpukhin, V., Goyal, N., Kuttler, H., Lewis, M., Yih, W., Rocktaschel, T., Riedel, S., & Kiela, D. (2020). Retrieval-augmented generation for knowledge-intensive NLP tasks. Advances in Neural Information Processing Systems, 33. https://arxiv.org/abs/2005.11401Microsoft. (2026, 24 marzo). Architettura di Microsoft 365 Copilot. Microsoft Learn. https://learn.microsoft.com/it-it/microsoft-365/copilot/microsoft-365-copilot-architecture