LLM Wiki: de nieuwe AI-kennisarchitectuur begrijpen

Een LLM Wiki verzamelt je bronnen tot een blijvende, onderling gelinkte kennisbank tijdens de ingestie en beantwoordt vervolgens vanuit die basis in plaats van telkens opnieuw ruwe fragmenten op te halen. Zo stapelt kennis zich op naarmate je bronnen toevoegt, in plaats van bij elke vraag opnieuw vanaf nul te worden opgebouwd.

Ik neem je mee door waar het idee van de LLM Wiki vandaan komt, hoe het zich verhoudt tot Retrieval-Augmented Generation (RAG), en of het echt een verschuiving betekent in hoe AI-systemen kennis beheren.

De oorsprong van het LLM Wiki-concept

Het idee van de LLM Wiki kreeg vorm in 2026, voorgesteld door Andrej Karpathy en opgepakt door een paar open-sourceprojecten die er iets van maakten dat je daadwerkelijk kunt draaien.

Het idee is simpel. AI-systemen in 2026 besteden een groot deel van hun tijd aan het opnieuw lezen van dezelfde documenten. Je uploadt een PDF, het model haalt fragmenten op, beantwoordt een vraag en gaat verder. Volgende week upload je nog een PDF over hetzelfde onderwerp, en het model doet precies hetzelfde. Er blijft niets hangen.

De grootste verschuiving is dat ophalen en compileren verschillende taken zijn.

Bijvoorbeeld:

• Retrieval-first-systemen zoeken op het moment van de vraag relevante tekstfragmenten en geven die aan het model als context. Het model werkt met wat de retriever heeft opgehaald.
• Compilation-first-systemen lezen elke bron één keer bij ingestie, halen eruit wat ertoe doet en schrijven dat in een gestructureerde kennisbank. Het model beantwoordt vervolgens vanuit die basis.

Een LLM Wiki valt in de tweede categorie. Wanneer je een nieuwe bron toevoegt, leest het model die, werkt bestaande pagina's bij, maakt waar nodig nieuwe aan en markeert tegenstrijdigheden met wat al is vastgelegd. De kennisbank groeit met elke bron die je toevoegt, en het model krijgt elke keer een betere basis om uit te antwoorden.

Dit is de eerste concrete breuk met het retrieval-first-paradigma dat domineert sinds RAG de standaard werd. RAG behandelt elke query als een nieuwe opzoekactie in ruwe documenten. Een LLM Wiki ziet ingestie als het moment waarop het werk gebeurt, en de vraagfase als het lezen uit een basis die al doordacht is.

Wat is een LLM Wiki?

Een LLM Wiki is een blijvende, door AI onderhouden kennisbank die voortdurend informatie uit brondocumenten samenbrengt tot gestructureerde, onderling verbonden pagina's.

Drie zaken onderscheiden het van een map met bestanden of een vectorstore.

• Blijvend: Pagina's worden één keer aangemaakt en bijgewerkt zodra nieuwe bronnen binnenkomen. Er hoeft op het moment van de vraag niets opnieuw te worden afgeleid, omdat de synthese al is opgeschreven.
• Continu bijgewerkt: Elke ingeslikte bron triggert bewerkingen in de hele wiki, bijvoorbeeld nieuwe pagina's voor nieuwe entiteiten, revisies van bestaande samenvattingen, notities waar nieuwe data oudere beweringen tegenspreekt.
• Dubbel publiek: Pagina's zijn leesbaar voor mensen en tegelijk voldoende gestructureerd voor AI-agents om over te redeneren. Markdown, kruisverwijzingen en een consistente lay-out doen dubbel werk.

De kernzet is dat de wiki de primaire kennislayer wordt. Oorspronkelijke documenten blijven in ruwe opslag als audittrail, maar niemand bevraagt die rechtstreeks. Chatsystemen, agents en onderzoeksassistenten lezen de wiki, omdat daar de gecompileerde, kruisverwijzende versie van de kennis staat.

De LLM Wiki-architectuur

De architectuur is eerder een pijplijn in drie stappen. Bronnen komen binnen, het model compileert ze tot wikipagina's en AI-toepassingen lezen van die pagina's. 

LLM Wiki-architectuur

Ik loop alle fasen met je door.

Bron documenten

Alles wat tekstgebaseerd is, kan worden ingeslikt. Bijvoorbeeld:

• Documentatie en PDF's
• Persoonlijke notities en notulen/transcripten van vergaderingen
• Coderepositories
• Webinhoud, geknipt uit artikelen of gescrapet van sites

Ruwe bronnen worden in onveranderlijke opslag geplaatst. Eenmaal ingeslikt leest het model eruit, maar het wijzigt ze nooit, wat je een duidelijke audittrail geeft van elke wikibewering terug naar de bron.

Kenniscompilatie

De wiki wordt in deze stap gecreëerd. Wanneer een nieuwe bron binnenkomt, voert het model een set bewerkingen uit:

• Concepten extraheren: Entiteiten, onderwerpen, definities en beweringen worden uit de brontekst gehaald.
• Bestaande pagina's bijwerken: Als een entiteit of concept al een pagina heeft, herziet het model die met de nieuwe informatie en markeert het tegenstrijdigheden.
• Nieuwe pagina's aanmaken: Alles wat niet past op een bestaande pagina krijgt een eigen pagina.
• Gerelateerde onderwerpen linken: Kruisverwijzingen worden in beide richtingen toegevoegd zodat pagina's verbonden blijven terwijl de wiki groeit.

Eén ingeslikte bron kan in deze ronde 10 tot 15 pagina's "bijwerken". Dat is het punt: het werk om nieuw materiaal te verbinden met bestaande kennis gebeurt één keer, bij ingestie, niet bij elke query zoals met RAG.

AI-toepassingen

De wiki is ontworpen om door meer dan één soort gebruiker gelezen te worden. Bijvoorbeeld:

• Chatsystemen die vragen beantwoorden op basis van de gecompileerde kennis in plaats van ruwe documenten.
• Onderzoeksassistenten die kruisverwijzingen volgen om een beeld van een onderwerp op te bouwen.
• Softwareagents die de wiki gebruiken als duurzame herinnering bij langlopende taken.
• Enterprise-kennis systemen die de wiki ontsluiten naar interne tools, dashboards, of MCP-servers.

De wiki staat in het midden. Bronnen komen aan de ene kant binnen, toepassingen lezen ervan aan de andere, en de compilatielaag houdt beide uiteinden in sync.

LLM Wiki vs traditionele RAG

Het belangrijkste verschil tussen traditionele RAG en een LLM Wiki is wanneer het werk gebeurt.

Traditionele RAG

RAG haalt documentfragmenten op op het moment van de vraag. Je stelt een vraag, een embedding-zoekopdracht haalt de top-k meest relevante fragmenten uit een vectorstore en die fragmenten worden samen met je vraag aan de context van het model toegevoegd. Het model genereert een antwoord vanuit die tijdelijke context en vergeet alles zodra de reactie klaar is.

De context is wegwerpbaar. 

De fragmenten die je laatste vraag beantwoordden, verdwijnen uit de context zodra het model klaar is met antwoorden. Als je morgen een verwante vraag stelt, draait de retriever opnieuw, haalt opnieuw fragmenten op en het model synthetiseert opnieuw. Er wordt niets opgebouwd tussen queries.

LLM Wiki

Een LLM Wiki compileert informatie tijdens ingestie. Wanneer je een bron toevoegt, leest het model die één keer, schrijft wat ertoe doet in gestructureerde pagina's, werkt kruisverwijzingen bij en slaat het resultaat op als duurzame markdown. De vraagfase wordt dan een kwestie van lezen uit de gecompileerde basis in plaats van opnieuw te synthetiseren uit ruwe fragmenten.

De kennis is persistent en evolueert. 

Elke nieuwe bron triggert bewerkingen in de hele wiki, zodat tegenstrijdigheden worden gemarkeerd, oudere samenvattingen worden herzien en de verbindingen tussen onderwerpen in de loop van de tijd dichter worden.

Afwegingen

Geen van beide benaderingen is universeel beter. Ze optimaliseren voor verschillende dingen.

Hier zijn een paar punten om in gedachten te houden:

• Actualiteit: RAG heeft hier een voordeel omdat het op het vraagmoment direct uit brondocumenten leest. Als je de onderliggende documenten bijwerkt, ziet de volgende query de wijziging meteen. Een LLM Wiki moet bronnen opnieuw inlezen om zijn pagina's bij te werken, dus er zit vertraging tussen ruwe waarheid en gecompileerde kennis.
• Nauwkeurigheid: Een LLM Wiki wint wanneer vragen synthese over veel bronnen vereisen, omdat de synthese al is gedaan en herzien. RAG kan verbindingen missen wanneer de relevante fragmenten meer stukken omvatten dan in het contextvenster passen, omdat het nooit het volledige plaatje in één keer ziet.
• Onderhoud: RAG vereist vrijwel geen onderhoud zodra de vectorstore is opgezet, omdat indexeren mechanisch is. Een LLM Wiki heeft actief onderhoud nodig, bijvoorbeeld lint-passes om verouderde beweringen te vinden, tegenstrijdigheidscontroles en af en toe reviews om verweesde pagina's te snoeien. De afruil is dat een onderhouden wiki rijker wordt in de tijd, terwijl een RAG-index vlak blijft.
• Schaalbaarheid: RAG schaalt voorspelbaar met het aantal documenten omdat ophalen een zoekprobleem is. Een LLM Wiki schaalt met het vermogen van het model om de gecompileerde kennis coherent te houden naarmate die groeit. Boven een bepaalde grootte hebben wiki's eigen indexbestanden, zoektools of embedding-lagen nodig om navigeerbaar te blijven.

Hier is een overzicht naast elkaar:

LLM Wiki versus RAG

RAG en LLM Wiki's zijn in de praktijk ook complementair. Sommige implementaties draaien RAG over de wiki zelf zodra die groter wordt dan wat een indexbestand aankan.

Waarom AI-agents baat hebben bij een LLM Wiki

AI-agents lijden meer dan chatsystemen onder het geen-geheugen-probleem. Eén gesprek kan herophalen tolereren, maar agents kunnen uren of dagen draaien en dezelfde feiten opnieuw ontdekken over tientallen taken. Een LLM Wiki geeft ze een plek om op te slaan wat ze leren, zodat ze het niet opnieuw hoeven te leren.

Hier zijn een paar gebieden waar blijvende kennis de meeste potentie heeft:

• Softwareontwikkeling: Een codeagent die wekenlang aan een codebase werkt, bouwt kennis op over modules, conventies, eerdere bugs en ontwerpbeslissingen. Zonder wiki wordt die context elke sessie opnieuw opgebouwd. Met wiki leest de agent de gecompileerde pagina's en pakt hij de draad op waar de vorige sessie eindigde.
• Langlopend onderzoek: Een agent die een onderwerp volgt over honderden papers kan niet alles in context houden. Een wiki geeft een plek om samenvattingen te archiveren en het evoluerende beeld te herzien zonder de hele corpus opnieuw te lezen.
• Enterprise-assistenten: Assistenten binnen een bedrijf krijgen elke dag dezelfde vragen van verschillende medewerkers. Met een wiki kan de assistent antwoorden vanuit gecompileerde interne kennis in plaats van bij elke aanvraag dezelfde set pagina's te doorzoeken.
• Organisatief geheugen: Teams verliezen context wanneer mensen vertrekken of vergaderingen eindigen. Een door transcripten, tickets en documenten gevoede LLM Wiki houdt die context verbonden.

Als het goed geïmplementeerd is, zie je dat een LLM Wiki op drie fronten rendeert:

1. Minder herhaalde zoekacties: Een agent die leest van een gecompileerde pagina hoeft niet dezelfde webzoekopdracht of vectorquery te draaien die hij gisteren draaide.
2. Rijkere context: Wikipagina's bevatten al gesynthetiseerde informatie, dus de agent start elke taak met een dichtere, beter verbonden basis dan ruwe fragmenten zouden bieden.
3. Cumulatief leren: Elke sessie draagt bij aan de wiki en de volgende sessie profiteert van wat de vorige heeft uitgezocht. Zo krijg je een agent die in de tijd daadwerkelijk beter wordt in zijn werk, in plaats van bij elke prompt te resetten.

Een LLM Wiki bouwen

De workflow voor het bouwen van een wiki is een lus. Bronnen gaan erin, pagina's worden geschreven en herschreven, en het geheel verfijnt zichzelf naarmate de corpus groeit.

LLM Wiki-bouwlus

• Documenten inladen. De eerste stap is bronnen in ruwe opslag krijgen. Documenten worden één keer gelezen en onveranderlijk bewaard, zodat elke vervolgclaim terug te voeren is naar een specifieke bron. Ingestie kan één bestand zijn, een batch of een stream vanuit een map die het model bewaakt.
• Entiteiten en concepten identificeren. Voor elke nieuwe bron extraheert het model wat ertoe doet: benoemde entiteiten, kernconcepten, beweringen, definities, relaties. Dit is het moment waarop ongestructureerde tekst iets wordt dat de wiki kan archiveren. De extractieronde checkt ook de bestaande wiki om te zien wat al is gedekt en wat nieuw is.
• Pagina's genereren of bijwerken. Nieuwe entiteiten krijgen nieuwe pagina's. Bestaande pagina's worden herzien met de nieuwe informatie. Als de nieuwe bron een bestaande bewering tegenspreekt, markeert het model dat op de pagina in plaats van te overschrijven. Eén ingeslikte bron wijzigt vaak 10 tot 15 pagina's, omdat bronnen meestal over meer dan één ding gaan.
• Links onderhouden. Kruisverwijzingen worden in beide richtingen toegevoegd, zodat pagina's verbonden blijven. Als een nieuwe pagina over RAG vector databases noemt, en er al een pagina vector databases bestaat, dan worden beide pagina's gelinkt.
• Kennis continu verfijnen. Periodieke lint-passes vangen problemen op die zich in de tijd ophopen. Bijvoorbeeld tegenstrijdigheden tussen pagina's, verouderde beweringen die door nieuwere bronnen zijn achterhaald, verweesde pagina's waar niemand naar linkt, en belangrijke concepten die terloops worden genoemd maar geen eigen pagina hebben. Deze stap houdt de wiki gezond bij het opschalen.

De details hangen af van je stack, maar de vorm is hetzelfde over implementaties heen. Ingesteren, extraheren, schrijven, linken, verfijnen — en dan lussen.

Veelvoorkomende kenmerken van LLM Wiki-systemen

De meeste LLM Wiki-implementaties hebben dezelfde set functies. De details verschillen, maar de bouwstenen worden gedeeld tussen projecten.

Automatische kenniscompilatie

De wiki schrijft zichzelf. Wanneer een bron wordt ingeslikt, extraheert het model wat ertoe doet en archiveert dat op pagina's zonder menselijke tussenkomst. Handmatig onderhoud nekken traditionele wiki's, omdat mensen het beu worden om kruisverwijzingen en samenvattingen bij te werken. Modellen niet, en dit is de functie die het hele patroon laat werken.

Gelinkte pagina's

Elke pagina is verbonden met gerelateerde pagina's via kruisverwijzingen. Wanneer een pagina over transformers attention mechanisms noemt, linken beide pagina's naar elkaar. Het resultaat is een navigeerbare graaf die je kunt doorlopen door verwijzingen te volgen — zo vind je verbindingen waarvan je niet wist dat ze bestonden.

Bronvermelding

Elke bewering op elke pagina is terug te voeren naar een specifieke bron. De ruwe documenten blijven onveranderlijk, zodat je altijd kunt verifiëren waar de informatie vandaan kwam. Dit is om twee redenen belangrijk: het geeft je een audittrail wanneer je nauwkeurigheid wilt controleren, en het laat het model beweringen netjes intrekken wanneer een bron wordt verwijderd.

Kennisgrafen

De gelinkte structuur van de wiki is op zichzelf een kennisgraaf. Knooppunten zijn pagina's, randen zijn kruisverwijzingen, en de vorm van de graaf vertelt je waar de corpus werkelijk over gaat. Hub-pagina's verschijnen automatisch rond belangrijke concepten, verweesde pagina's signaleren hiaten en dichte clusters tonen de gebieden die de wiki het best kent.

Blijvend geheugen

De wiki is beschikbaar over sessies heen. Chatcontext verdwijnt wanneer het gesprek eindigt, maar wikipagina's staan als markdown op schijf. Dit is wat een chatmodel verandert in iets dat kennis kan meenemen over dagen, projecten en agentruns heen.

Continue updates

Nieuwe bronnen leiden tot revisies van bestaande pagina's, niet alleen toevoegingen. Als een paper van vorige maand in tegenspraak is met wat zes maanden geleden is geschreven, markeert de wiki dat en werkt de getroffen pagina's bij. De kennisbank komt in de tijd dichter bij correct, in plaats van verouderde beweringen op te stapelen.

Deze functies staan niet op zichzelf. Dit betekent dat een wiki zonder bronvermelding niet te vertrouwen is. Evenzo veroudert een wiki zonder continue updates, en een wiki zonder gelinkte pagina's is slechts een map met samenvattingen. De waarde komt voort uit het feit dat ze allemaal samenwerken.

Toepassingen van LLM Wiki's in de echte wereld

Het patroon dat ik tot nu toe heb besproken is algemeen, dus ik ga nu in op enkele praktijktoepassingen waar een LLM Wiki nuttig kan zijn, zelfs nuttiger dan RAG.

Onderzoeksliteratuur

Iedereen die een onderwerp volgt over tientallen of honderden papers loopt tegen hetzelfde probleem aan: de papers stapelen zich sneller op dan je ze kunt verwerken. Een LLM Wiki leest elke paper zodra die binnenkomt, extraheert de beweringen, archiveert ze onder de relevante concepten en markeert tegenstrijdigheden met wat al is gelezen. Het resultaat is een doorlopende synthese die up-to-date is met het veld, in plaats van een map met PDF's die je nooit zult lezen.

Engineeringdocumentatie

Codebases hebben documentatieschuld die meestal elke sprint groeit. Typisch worden ontwerpbeslissingen genomen in Slack-threads en leven architectuurnotities in iemands Notion. De eigenlijke code is de enige bron die gegarandeerd actueel is. Een wiki gevoed door de codebase, comments, pull requests en interne docs kan een beeld van het systeem compileren dat verbonden is met de code. Engineers kunnen vragen stellen aan de wiki in plaats van aan de persoon die de module drie jaar geleden schreef.

Enterprise-kennisbanken

Bedrijven verzamelen kennis in tickets, vergadertranscripten, productspecificaties en interne wiki's. Een LLM Wiki kan uit al deze bronnen inslikken en één kennislayer compileren die actueel blijft. Medewerkers kunnen het één keer bevragen in plaats van vier verschillende tools te doorzoeken.

Persoonlijk kennisbeheer

Notitieapps hebben het opslagprobleem opgelost maar niet het syntheseprobleem. Je hebt nog steeds honderden notities, artikelen en highlights, en je zult de meeste niet meer terugzien. Een wiki gevoed door je Obsidian-kluis kan de stapel notities omzetten in een gecompileerd kennislichaam dat je daadwerkelijk kunt bevragen. 

AI-agentgeheugen

Agents die uren of dagen draaien, hebben een plek nodig om op te slaan wat ze leren. De wiki geeft ze duurzaam geheugen dat over sessies heen kan worden gebruikt — wat werkte, wat niet, welke bestanden ze al hebben gelezen, welke paden ze al hebben geprobeerd. Dit is vooral nuttig voor agents die bovenop Claude Code of vergelijkbare tools zijn gebouwd, waar aan dezelfde codebase over veel sessies wordt gewerkt en de context van eerdere runs de huidige run efficiënt maakt.

Huidige LLM Wiki-implementaties

Het LLM Wiki-landschap is in 2026 vroeg. Het meeste wat bestaat is open source en gebouwd door individuen of kleine teams. Het is ver verwijderd van waar RAG nu staat.

Karpathy's originele gist is waar veel bouwers begonnen. Het beschrijft het patroon voldoende gedetailleerd zodat iedereen met een LLM-agent zijn eigen versie kan bouwen door het document te plakken in Claude Code of een vergelijkbare tool. De meeste huidige wiki's beginnen als persoonlijke projecten bovenop een gedeeld idee.

Open-source-initiatieven zijn waar het idee wordt uitgewerkt. Projecten zoals llm-wiki.net publiceren hun code onder permissieve licenties zodat anderen kunnen forken, uitbreiden of aanpassen aan hun eigen workflows. Het voordeel is dat je precies kunt zien wat de wiki doet en het kunt wijzigen wanneer je behoeften niet overeenkomen met de standaard.

Local-first-benaderingen draaien volledig op je eigen machine. Bronnen worden op schijf opgeslagen, de wiki is een map met markdown-bestanden en het model leest en schrijft via een lokale agent. Obsidian is de meest voorkomende front-end omdat het al is gebouwd voor markdown en kruisverwijzingen. Dit geeft je de meeste controle, aangezien de bronnen je machine niet verlaten en je elke pagina die het model schrijft kunt inspecteren.

Gehoste implementaties beginnen te verschijnen maar zijn minder gebruikelijk. Het patroon past minder goed bij het SaaS-model dan RAG, omdat de wiki van jou hoort te zijn — jouw bronnen, jouw pagina's, jouw keuzes over wat je archiveert. Gehoste varianten werken het best voor teamwiki's, waar de waarde van gedeelde kennis opweegt tegen de kosten van het hosten van bronnen op andermans infrastructuur.

Maar per juli 2026 is geen van deze af. Er wordt nog veel uitgezocht, en de meeste projecten die vandaag bestaan zijn nog prototypes.

Voordelen en beperkingen

Het LLM Wiki-patroon heeft sterke punten en kosten. Beide zijn het kennen waard voordat je besluit er één te bouwen.

Voordelen

• Blijvende kennis: De wiki blijft beschikbaar na het einde van elke afzonderlijke sessie. Wat het model vorige maand heeft uitgezocht, staat vandaag nog op de pagina, en nieuw werk bouwt daarop voort in plaats van opnieuw te beginnen.
• Herbruikbare synthese: Het werk van bronnen verbinden gebeurt één keer, bij ingestie. Elke query daarna leest uit het gecompileerde resultaat in plaats van opnieuw te synthetiseren uit ruwe tekst. Dit bespaart compute en levert betere antwoorden op, omdat het model het denkwerk al heeft gedaan.
• Minder herhaalde retrievals: Een wiki die al een pagina over een onderwerp heeft, hoeft niet telkens de ruwe corpus te doorzoeken wanneer het onderwerp terugkomt. Dit is belangrijk voor agents die uren draaien en anders steeds dezelfde zoekacties zouden uitvoeren.
• Gestructureerde organisatie: Pagina's en kruisverwijzingen geven je iets dat je kunt browsen en waarover je kunt redeneren, zeker vergeleken met een map vol PDF's.

Beperkingen

• Informatie actueel houden: De wiki moet opnieuw worden ingeslikt wanneer bronnen veranderen. Als een document wordt bijgewerkt en je draait ingestie niet opnieuw, blijft de wiki naar de oude versie verwijzen. RAG heeft dit probleem niet, omdat het live bronnen leest op het moment van de vraag.
• Verificatie-uitdagingen: Elke bewering op een wikipagina is door een model geschreven. Bronvermelding helpt, maar je moet er nog steeds op vertrouwen dat het model de bron correct heeft samengevat.
• Onderhoud: Tegenstrijdigheidscontroles en heringestie zijn niet gratis. Een wiki die niet wordt onderhouden, veroudert, en onderhoud kost tijd en compute, ook als het model het werk doet.
• Mogelijke kennisdrift: Elke ingestie is een kans voor het model om kleine fouten te introduceren. Over honderden ingesties kunnen die zich opstapelen. Een pagina die startte als accuraat kan na genoeg revisies subtiel onjuist worden.

Veelvoorkomende misvattingen over LLM Wiki's

Hoewel LLM Wiki een nieuw concept is, bestaan er al enkele misvattingen over. Dit is waar ze de plank misslaan.

Een LLM Wiki vervangt RAG

Nee. Ze lossen verschillende problemen op. RAG is voor snelle lookup tegen een corpus dat vaak verandert. Een LLM Wiki is bedoeld om in de tijd een kennislichaam op te bouwen. Veel echte systemen gebruiken beide — RAG voor actualiteit tegen ruwe bronnen, een wiki voor gecompileerde synthese daarbovenop.

Het is gewoon weer een vectordatabank

Vectordatabanken indexeren tekst voor retrieval. Een LLM Wiki schrijft tekst die door een model is gelezen, begrepen en herordend. Een vectordatabank geeft je de fragmenten terug die je erin stopte. Een wiki geeft je pagina's terug die vóór de ingestie niet bestonden. De output is volledig anders.

De kennisbank hoeft nooit te worden bijgewerkt

Niet waar. Bronnen veranderen, nieuwe bronnen komen binnen en het model maakt fouten die moeten worden opgevangen. Een wiki die niet wordt onderhouden, veroudert net als elke documentatie. Het verschil is dat het model het meeste onderhoud doet, niet dat onderhoud verdwijnt.

Het is alleen nuttig voor AI-agents

Agents zijn de duidelijkste usecase omdat ze lang draaien en het meest profiteren van duurzaam geheugen, maar mensen hebben ook baat bij wiki's. Denk aan een onderzoeker die een onderwerp volgt of een engineer die aan een codebase werkt. Of eigenlijk iedereen die een persoonlijke kennisbank opbouwt, krijgt dezelfde cumulatieve synthese. 

Worden LLM Wiki's een nieuwe AI-architectuur?

Het is te vroeg om te zeggen, maar het waarschijnlijke pad is duidelijk: blijvende kennis zal retrieval-first-systemen niet vervangen, maar ernaast bestaan, waarbij RAG live lookups afhandelt en wiki's gecompileerde, langlopende context. De grotere open vragen gaan over validatie en schaal — niemand heeft volledig opgelost hoe je model fouten opvangt die in wikipagina's zijn geschreven, en niemand heeft het patroon al getest op zeer grote wiki's. MCP lijkt een natuurlijke fit om wiki's aan agents bloot te stellen, al ligt enterprise-adoptie verder weg gezien de extra vertrouwenseisen.

Het patroon is nog niet gevestigd. Of het doorzet hangt ervan af of de onderhouds- en validatieproblemen worden opgelost. Meer vragen hierover worden beantwoord in de veelgestelde vragen hieronder.

Conclusie

De LLM Wiki is een van de interessantere ideeën die tot nu toe in 2026 zijn opgedoken, omdat het verandert wat een AI-systeem doet wanneer je het een bron geeft. In plaats van dezelfde documenten bij elke query te lezen, leest het model ze één keer en archiveert ze in een kennisbank die alleen maar beter wordt met de tijd.

Het concept is nog in opkomst en de huidige implementaties zijn vroeg, maar het idee is veelbelovend en wijst op iets groters in het algemeen. AI-systemen verschuiven van wegwerpcontext naar blijvende kennis, en LLM Wiki's zijn een van de eerste serieuze pogingen naar hoe dat er in de praktijk daadwerkelijk uitziet.

Als je bij wil blijven met de nieuwe ontwikkelingen maar het verwarrend vindt, schrijf je dan in voor onze AI Fundamentals-track. Je leert de vaktaal en kunt AI effectief inzetten voor je werk.