LLM Wiki - Samengestelde kennis die RAG niet kan vervangen

De uitgangspunt is eenvoudig: gecompileerde kennis is herbruikbaarder dan opgeroepen fragmenten. RAG (Retrieval-Augmented Generation) is het standaardantwoord geworden op een eenvoudige vraag – hoe geef ik een LLM (Large Language Model) toegang tot externe kennis?

En de gebruikelijke architectuur is inmiddels bekend. Neem documenten, splits ze in fragmenten, voeg embedding toe aan de fragmenten, sla ze op in een vectordatabase, roep relevante stukken op bij de query en voer ze naar het model. Dat patroon is nuttig, maar het wordt ook overgebruikt. RAG is zeer goed in toegang, maar niet automatisch goed in structuur. Het kan relevante fragmenten vinden, maar creëert geen stabiel begrip van een domein; het kan context ophalen, maar bepaalt niet wat de canonieke uitleg is; en het kan antwoorden geven op basis van documenten, maar onderhoudt geen levende kennisbank.

LLM Wiki is niet slechts een ander retrievalpatroon, maar een compleet andere manier om na te denken over kennisarchitectuur. In plaats van het model te vragen om elke keer opnieuw een synthese te maken van ruwe fragmenten wanneer er een vraag wordt gesteld, gebruikt een LLM Wiki het model eerder in de pipeline, voert synthese uit tijdens het binnenhalen (ingest time) en slaat het resultaat op als gestructureerde, leesbare, gekoppelde kennis.

Een goede samenvatting is deze:

• RAG haalt kennis op op het moment van de query.
• LLM Wiki compileert kennis op het moment van binnenhalen.

Dat onderscheid verandert kosten, latentie, kwaliteit, onderhoud, governance en faalmodi – en het is de centrale reden waarom LLM Wiki zijn eigen architectuurcategorie verdient.

RAG optimaliseert ophalen, niet representatie

RAG is krachtig omdat het een taalmodel in staat stelt informatie te gebruiken buiten zijn trainingsdata, wat het nuttig maakt voor:

• bedrijfsdocumentatie
• producthandleidingen
• technische ondersteuning
• interne zoekopdrachten
• onderzoeksassistenten
• beleidsoverzicht
• codeldocumentatie
• chatbots voor kennisbanken

Maar RAG heeft een structurele zwakte: het behandelt kennis vaak als een hoop op te halen fragmenten in plaats van een gestructureerd model van een domein.

Een typisch RAG-systeem werkt als volgt:

1. Verzamel documenten.
2. Splits ze in fragmenten.
3. Maak embeddings.
4. Sla de fragmenten op in een vectordatabase.
5. Haal vergelijkbare fragmenten op voor elke query.
6. Vraag de LLM om te antwoorden met behulp van die fragmenten.

Dit werkt goed voor veel vragen, maar het creëert ook herhaald werk van interpretatie voor complexe vragen. Elke keer als een gebruiker iets conceptueel rijk vraagt, moet het systeem:

• fragmenten ophalen
• beslissen welke fragmenten belangrijk zijn
• relaties afleiden
• tegenstrijdigheden oplossen
• een tijdelijke uitleg bouwen
• een antwoord produceren

Dan verdwijnt die synthese en begint de volgende query opnieuw van bij nul. Dit is prima wanneer vragen eenvoudig zijn, maar het wordt verspilling wanneer dezelfde concepten keer op keer opnieuw worden opgebouwd uit ruwe fragmenten.

De meest voorkomende RAG-fout is de aanname dat beter ophalen gelijk staat aan betere kennis. Soms klopt dat, maar vaak niet, omdat ophalen en representatie verschillende problemen oplossen. Ophalen beantwoordt welke stukken tekst relevant zijn; representatie beantwoordt hoe kennis in de eerste plaats gestructureerd moet zijn. Een RAG-systeem kan vijf accurate fragmenten over een onderwerp ophalen en toch falen omdat:

• de fragmenten verouderd zijn
• de documenten elkaar tegenspreken
• het belangrijke concept over pagina’s is verspreid
• de bron inconsistent terminologie gebruikt
• het antwoord synthese vereist, niet opzoeken
• er geen canonieke pagina is

RAG is een toegangslaag, geen kennismodel op zich, en een LLM Wiki bestaat precies omdat sommige kennis gerespecteerd moet worden voordat het wordt opgehaald.

Wat is een LLM Wiki?

Een LLM Wiki is een kennissysteem waarbij een taalmodel helpt bij het transformeren van bronmateriaal naar gestructureerde, wiki-achtige kennis. In plaats van alleen ruwe documenten op te slaan en later fragmenten op te halen, creëert het systeem afgeleide kennisartefacten zoals:

• topicpagina’s
• samenvattingen
• glossaria
• conceptpagina’s
• entiteitspagina’s
• kruislinks
• vergelijkingen
• notities over tegenstrijdigheden
• bronverwijzingen
• beslissingenregistraties
• uitleg

De output is meestal menselijk leesbaar en, in veel implementaties, opgeslagen als gewone Markdown, wat belangrijk is omdat Markdown het systeem:

• inspecteerbaar maakt
• draagbaar
• bewerkbaar
• versiebeheerbaar
• makkelijk te diffen
• compatibel met statische sites en PKM-tools (Personal Knowledge Management)

Het idee is niet dat de LLM magisch alles weet, maar dat de LLM helpt bij het onderhouden van een gestructureerde laag boven het bronmateriaal, als een structurerende assistent in plaats van de uiteindelijke autoriteit.

Het kernidee

Het kernidee van LLM Wiki is kennissynthese op het moment van binnenhalen. In een RAG-systeem gebeurt synthese meestal wanneer een gebruiker een vraag stelt; in een LLM Wiki gebeurt synthese eerder, tijdens het binnenhalen, voordat er een vraag is gesteld.

Een vereenvoudigde pipeline ziet er als volgt uit:

bronnen
  -> binnenhalen
  -> samenvatten
  -> structureren
  -> koppelen
  -> onderhouden
  -> query of browsen

Het systeem wacht niet tot het moment van de query om te begrijpen wat de kennis betekent – het creëert van tevoren een herbruikbare structuur, wat LLM Wiki dichter bij een gecompileerde kennisbank maakt dan bij een zoekpipeline.

Een praktisch voorbeeld

Stel je voor dat je 60 artikelen hebt over lokale LLM-hosting. Een RAG-systeem zou ze misschien splitsen in fragmenten en relevante secties ophalen wanneer je vraagt naar de verschillen tussen Ollama, vLLM, llama.cpp en SGLang, en dan laten dat de LLM een antwoord assembleert uit die opgehaalde fragmenten.

Een LLM Wiki-systeem doet iets anders. Op het moment van binnenhalen creëert het gestructureerde pagina’s:

• ollama.md
• vllm.md
• llama-cpp.md
• sglang.md
• local-llm-hosting-overview.md
• inference-backends-comparison.md
• gpu-memory-and-context-length.md

En dan koppelt het ze. Wanneer je later een vraag stelt, begint het systeem niet vanaf ruwe fragmenten, maar vanaf een gestructureerde kenniswaag die al was geassembleerd voordat de vraag aankwam – en voor conceptuele en vergelijkende vragen is dat verschil in kwaliteit significant.

Hoe LLM Wiki werkt

Er is geen enkele officiële implementatie, maar de meeste LLM Wiki-systemen volgen dezelfde conceptuele fasen.

Bronverzameling

Het systeem begint met bronmateriaal – blogberichten, PDF’s, Markdown-notities, technische documentatie, transcripties, papers, vergadernotulen, bookmarks, codecommentaren en README-bestanden – die als een aparte laag behouden moeten worden, onderscheiden van de gegenereerde wiki. Dit is belangrijk omdat gegenereerde wiki-pagina’s afgeleide kennis zijn, geen oorspronkelijke waarheid, en een serieuze LLM Wiki altijd links terug naar bronnen moet onderhouden zodat elke gegenereerde pagina de basisvraag kan beantwoorden: waar komt deze claim vandaan?

Binnenhalen en extraheren

Tijdens het binnenhalen leest het systeem bronmateriaal en extraheert nuttige kennis. Het kan identificeren:

• hoofdonderwerpen
• entiteiten en tools
• definities
• claims
• beslissingen
• voorbeelden
• tegenstrijdigheden tussen bronnen
• open vragen
• terugkerende concepten

In deze fase begint LLM Wiki te verschillen van gewoon RAG: terwijl RAG documenten meestal chunkt voor retrieval, probeert LLM Wiki het materiaal conceptueel te begrijpen en te herschappen in plaats van het alleen zoekbaar te maken.

Samenvatten

Het systeem creëert samenvattingen, maar nuttige samenvattingen zijn niet alleen kortere versies van tekst – ze moeten de structuur van het argument behouden. Een zwakke samenvatting zegt “dit document bespreekt tools voor lokale LLM-hosting.” Een nuttige samenvatting zegt “dit document vergelijkt tools voor lokale LLM-hosting op basis van complexiteit van implementatie, GPU-gebruik, API-compatibiliteit en productiebereidheid, waarbij Ollama wordt gepositioneerd als makkelijk voor lokaal gebruik, vLLM als sterker voor serverworkloads, en llama.cpp als flexibel voor gekwantificeerde modellen.”

Voor technische kennis moet een samenvatting vastleggen:

• welk probleem het oplost
• welke aannames het maakt
• welke afwegingen het bevat
• welke afhankelijkheden het heeft
• wat nog onzeker is

Hier zijn LLMs echt nuttig, omdat ze goed zijn in het comprimeren van rommelige proza naar gestructureerde uitleg.

Structureren

Samenvattingen alleen zijn niet genoeg – het systeem moet ook beslissen waar kennis thuishoort, wat de representatielaag is. Veelvoorkomende structuren omvatten:

• topicpagina’s
• conceptpagina’s
• indexpagina’s
• vergelijkingpagina’s
• glossariumitems
• how-to-pagina’s
• architectuurnotities
• beslissingenregistraties
• kaarten van gerelateerde pagina’s

Een hoop samenvattingen is geen wiki; een wiki heeft paginagrenzen, links en terugkerende structuur nodig, en een goede LLM Wiki wordt niet gemeten aan het aantal pagina’s, maar aan of pagina’s daadwerkelijk herbruikbaar worden.

Koppelen

Links definiëren de vorm van het kennissysteem. In een normaal documentenarchief zijn relaties vaak impliciet; in een LLM Wiki moeten ze expliciet worden. Nuttige linktypes omvatten:

• concept naar concept
• artikel naar samenvatting
• tool naar vergelijking
• probleem naar oplossing
• architectuur naar implementatie
• bron naar afgeleide pagina
• glossariusterms naar gedetailleerde pagina

Dit is een van de belangrijkste verschillen tussen LLM Wiki en basis samenvatting: samenvattingen reduceren tekst, maar links bouwen een kennisgraaf.

Review en correctie

Deze fase is alleen optioneel in proefsysteem; in serieuze systemen is menselijke review essentieel. Het reviewproces moet controleren:

• of samenvattingen trouw zijn
• of links nuttig zijn
• of claims gebaseerd zijn op bronnen
• of pagina’s gedupliceerd zijn
• of concepten op de verkeerde plaats staan
• of verouderde informatie is gemarkeerd
• of gegenereerde pagina’s zekerheid overdrijven

LLM Wiki kan menselijk inspanning verminderen, maar het mag nooit menselijke verantwoordelijkheid wegnemen.

LLM Wiki vs RAG

Het scherpste onderscheid tussen LLM Wiki en RAG is timing.

Synthese op query-moment

In RAG haalt het systeem informatie op wanneer een gebruiker een vraag stelt.

query
  -> haal fragmenten op
  -> assembleer context
  -> genereer antwoord

Dit is flexibel en werkt goed wanneer:

• het corpus groot is
• informatie vaak verandert
• vragen onvoorspelbaar zijn
• je brede dekking nodig hebt
• je niet alles kunt cureren

Maar het kan minder coherent zijn voor conceptuele vragen, omdat het model elke keer opnieuw moet synthetiseren vanuit fragmenten, wat kan leiden tot inconsistente antwoorden bij vergelijkbare queries.

Synthese op binnenhalingsmoment

In LLM Wiki voert het systeem synthese uit voordat de vraag aankomt.

bronnen
  -> samenvatten
  -> structureren
  -> koppelen
  -> later query of browsen

Dit is minder flexibel maar wel coherent, en het werkt goed wanneer:

• het corpus beheersbaar is
• het domein stabiel is
• concepten terugkomen
• menselijke leesbaarheid belangrijk is
• je herbruikbare synthese wilt
• je een onderhouden kenniswaag wilt

De belangrijkste verschillen

Aanvullend, niet wederzijds exclusief

Het debat mag niet worden geformuleerd als “LLM Wiki of RAG” – dat is de verkeerde vraag. LLM Wiki vervangt RAG niet in de meeste productiesystemen; beide hebben duidelijke en complementaire rollen. Een goed ontworpen systeem kan er als volgt uitzien:

ruwe documenten
  -> bronopslag
  -> LLM Wiki synthese
  -> gereviewde kennispagina's
  -> zoekindex
  -> RAG over bron en synthese
  -> antwoord met citaten

In die architectuur verbetert LLM Wiki de representatielaag en verbetert RAG de toegangslaag. Gebruik RAG voor het ophalen over grote en veranderende corpora, gebruik LLM Wiki voor gecompileerde synthese over stabiele en gecuratede kennis, en gebruik beide samen wanneer je tegelijkertijd schaal en coherentie nodig hebt.

LLM Wiki vs aangrenzende systemen

LLM Wiki vs samenvatting

Een zwakke LLM Wiki is slechts een map met gegenereerde samenvattingen, en dat is niet genoeg. Samenvatting comprimeert inhoud; LLM Wiki structureert het. Een echte LLM Wiki heeft stabiele pagina’s nodig, links, concepten, indexes, brontracking, revisiegeschiedenis, onderhoudsworkflows en conflictdetectie – het wiki-deel is net zo belangrijk als het LLM-deel.

LLM Wiki vs kennisgraaf

Een kennisgraaf representeert entiteiten en relaties expliciet, terwijl een LLM Wiki een zachtere, document-gerichte graaf creëert via Markdown-pagina’s en links. Een volwassen systeem kan beide gebruiken: de wiki biedt menselijk leesbare uitleg en de kennisgraaf biedt nauwkeurig gestructureerde, machine-querybare relaties.

LLM Wiki vs agent geheugen

LLM Wiki verschilt ook van AI geheugen. Geheugen slaat context op die toekomstig gedrag beïnvloedt, terwijl een LLM Wiki gestructureerde kennis opslaat die door zowel mensen als systemen kan worden gelezen, doorzocht, gereviewd en gekoppeld.

Geheugen kan onthouden:

• de gebruiker voorkeur geeft aan Go-voorbeelden
• het project ORMs vermijdt
• de agent gisteren een commando probeerde
• een bug-onderzoek mislukte

Een LLM Wiki kan opslaan:

• welke Go database-toegangspatronen bestaan
• hoe sqlc vergeleken met GORM
• waarom outbox-patronen belangrijk zijn
• hoe RAG verschilt van geheugensystemen

Geheugen is behaviorale context; LLM Wiki is gerespecteerde kennis – en het mengen van de twee leidt tot systemen die moeilijk te inspecteren, te auditen of te onderhouden zijn.

Wanneer LLM Wiki goed werkt

LLM Wiki werkt het beste voor stabiele domeinen, persoonlijk onderzoek, gecuratede corpora, technische documentatie en situaties waarin herhaalde synthese over hetzelfde materiaal verspilling is.

Stabiele domeinen

LLM Wiki werkt het beste wanneer het domein niet elke uur verandert. Goede voorbeelden zijn:

• technische concepten
• onderzoeksnotities
• leermateriaal
• architectuurpatronen
• boeknotities
• modelvergelijkingen
• interne engineeringprincipes
• gecuratede documentatie
• persoonlijke kennisbanken

Als kennis stabiel genoeg is om te samenvatten zonder binnen dagen verouderd te raken, kan LLM Wiki blijvende waarde leveren die compliceert naarmate de wiki groeit.

Onderzoekssynthese

Onderzoekssynthese is een van de sterkste use cases, omdat onderzoekers vaak veel bronnen lezen en herhaaldelijk dezelfde meta-vragen stellen:

• Wat zijn de hoofdideeën?
• Welke bronnen komen overeen?
• Welke bronnen conflicteren?
• Welke concepten komen terug?
• Wat is de huidige staat van het onderwerp?
• Wat moet ik als volgende lezen?

LLM Wiki helpt dat onderzoeksmateriaal om te zetten in herbruikbare structuur – topicpagina’s, vergelijkingpagina’s, notities over tegenstrijdigheden en gerelateerde links – zodat de onderzoeker niet elke keer opnieuw dezelfde mentale kaart hoeft te bouwen wanneer hij terugkomt bij een domein. Het is vooral nuttig bij het werken met papers, technische artikelen, transcripties, documentatie, notities en experimentlogboeken.

Persoonlijke kennissystemen

LLM Wiki past natuurlijk bij PKM en het bredere spectrum van kennissystemen en second brain workflows omdat een persoonlijk kennissysteem al bevat:

• notities
• links
• onafgeronde ideeën
• samenvattingen
• referenties
• topicmappen

Een LLM kan helpen bij het onderhouden van de structuur door:

• lange notities samenvatten
• links voor te stellen
• topicpagina’s te creëren
• dubbele concepten te detecteren
• glossariusterms te extraheren
• indexpagina’s te genereren
• hiaten te identificeren

De mens blijft de editor, wat de juiste relatie is tussen menselijk oordeel en machine-assistentie.

Technische blogging

Een technische blog kan LLM Wiki-ideeën intern gebruiken, zelfs zonder een volledig geautomatiseerd systeem te bouwen. Een goed gestructureerde site kan bevatten:

• pijlerpagina’s
• clusterindexpagina’s
• topic samenvattingen
• gerelateerde artikelmappen
• glossariumpagina’s
• vergelijkingpagina’s
• canonieke uitleg

Dit is niet alleen SEO, maar kennisrepresentatie: een goed gestructureerde technische blog wordt waardevoller wanneer artikelen worden verbonden tot een duurzame kennisstructuur die zowel mensen als AI-systemen kunnen navigeren.

Kennisbanken voor kleine teams

LLM Wiki kan goed werken voor kleine teams met gecuratede kennis, inclusief engineeringbeslissingen, productarchitectuur, onboardingsnotities, ondersteuningsplaybooks, interne standaarden, postmortems en runbooks. De sleutelvoorwaarde is governance: iemand moet de gegenereerde structuur reviewen en onderhouden, omdat zonder duidelijke eigendom de wiki vervalt in ruis, ongeacht hoe goed deze oorspronkelijk is gegenereerd.

Wanneer LLM Wiki een slechte match is

Zeer dynamische data

LLM Wiki is zwakker wanneer informatie constant verandert. Live voorraad, prijsfeeds, incidentstatus, financiële marktdata, snel veranderende supporttickets en realtime logs zijn allemaal beter bediend door retrieval of directe API-toegang. Het compileren van snel bewegende data naar statische samenvattingen is contraproductief, tenzij je een sterk vernieuwingsproces hebt dat de gecompileerde laag synchroniseert met de realiteit.

Grote, onbeheerde corpora

LLM Wiki schaal niet automatisch naar miljoenen documenten. Op grote schaal strekken de moeilijke problemen zich ver uit tot generatie en omvatten:

• toegangscontrole
• datalijnage
• eigendom
• deduplicatie
• indexering
• tracking van versheid
• evaluatie
• governance

Een eenvoudige Markdown-wiki is niet uitgerust om die behoeften aan te pakken, en op enterprise-schaal kan LLM Wiki één laag worden binnen een grotere kennisarchitectuur in plaats van het hele systeem.

Bronnen van lage kwaliteit

LLM Wiki kan slechte bronnen niet betrouwbaar repareren. Als het bronmateriaal tegenstrijdig, verouderd, van lage kwaliteit, gedupliceerd, onvolledig of slecht gebundeld is, kunnen gegenereerde pagina’s er gepolijst uitzien, maar verkeerd zijn. Dit is gevaarlijk precies omdat een schone gegenereerde pagina valse zekerheid creëert – de opmaak signaleert kwaliteit, zelfs wanneer de onderliggende inhoud dit niet rechtvaardigt.

Geen reviewproces

LLM Wiki zonder review is riskant omdat gegenereerde structuur autoriteit creëert. Een slecht antwoord in RAG kan één query beïnvloeden, maar een slechte gegenereerde wiki-pagina kan veel toekomstige queries, lezers en agents beïnvloeden die eruit ophalen. Het model kan overgeneraliseren, uitzonderingen missen, structuur verzinnen, incompatibele ideeën samenvoegen, onzekerheid verbergen, misleidende links creëren of verouderd materiaal samenvatten alsof het actueel is – dus voor elke kennis die daadwerkelijk belangrijk is, is menselijke review niet optioneel.

Beperkingen en faalmodi

De belangrijkste risico’s van het bouwen van een LLM Wiki zijn verouderde samenvattingen, hallucinatiesynthese die in de kennisbank is gebakken, zwakke brontracking, onderhoudskosten en valse zekerheid in gegenereerde structuur.

Onderhoudsdrijf

Kennisdrijf treedt op wanneer gegenereerde pagina’s niet meer overeenkomen met de onderliggende bronnen. Dit kan gebeuren omdat:

• bronnen zijn veranderd
• nieuwe bronnen zijn toegevoegd
• oude pagina’s niet zijn vernieuwd
• samenvattingen handmatig zijn bewerkt
• links verouderd zijn
• modeloutput in de loop van de tijd is veranderd

Drijf is het centrale operationele risico van LLM Wiki, en een goed systeem heeft expliciete vernieuwings- en validatieworkflows nodig om dit te vangen voordat het zich verspreidt.

Gehallucineerde synthese

RAG kan hallucineren op het moment van het antwoord, maar LLM Wiki kan hallucineren op het moment van binnenhalen, wat subtieler en gevaarlijker is. Als een gegenereerde wiki-pagina een verkeerde synthese bevat, kunnen toekomstige gebruikers die pagina als grondwaarheid behandelen, en toekomstige AI-systemen kunnen het ophalen en de fout verder versterken. Gegenereerde structuur heeft provenance nodig, en elke belangrijke claim moet teruglinken naar zijn oorspronkelijke bronnen, zodat de hallucinatie kan worden gevangen tijdens de review in plaats van stil te worden ingebed in de kennisbank.

Over-structureren

Emaal je een LLM hebt die pagina’s goedkoop kan creëren, is het verleidelijk om er te veel te maken. Je kunt eindigen met:

• lege taxonomie
• dubbele concepten
• oppervlakkige pagina’s
• zinloze links
• gegenereerd rommel
• valse volledigheid

Een nuttige wiki wordt niet gemeten aan het aantal pagina’s, maar aan of pagina’s daadwerkelijk worden hergebruikt, gekoppeld en bijgewerkt in de loop van de tijd.

Onhelder eigendom

Het model kan de pagina niet bezitten. Een serieus systeem heeft duidelijke eigendomsregels nodig die dekken:

• wie reviewt pagina’s
• wie keurt updates goed
• wie verwijdert verouderde pagina’s
• wie lost tegenstrijdigheden op
• wie beslist over canonieke structuur

Zonder die helderheid wordt LLM Wiki een andere verlaten kennisbank – goed bedoeld, goed gegenereerd en stil genegeerd.

Architectuurpatronen

Patroon 1. Persoonlijke LLM Wiki

Het persoonlijke patroon is de eenvoudigste en meest praktische versie, het beste geschikt voor individuen.

notities en bronnen
  -> LLM-gestuurde samenvattingen
  -> Markdown-pagina's
  -> handmatige review
  -> [Obsidian](https://www.glukhov.org/nl/knowledge-management/tools/obsidian-for-personal-knowledge-management/ "Using Obsidian for Personal Knowledge Management") of statische site

Het werkt goed voor onderzoekers, schrijvers, engineers, technische bloggers, studenten en consultants, waarbij de waarde komt van het verminderen van herhaalde synthese en het makkelijker maken van persoonlijke kennis om te navigeren zonder teamcoördinatie of governance-infrastructuur te vereisen.

Patroon 2. Team LLM Wiki

Het teampatroon is het beste voor kleine groepen en heeft meer governance nodig dan de persoonlijke versie.

teamdocs
  -> ingest workflow
  -> gegenereerde conceptpagina's
  -> review queue
  -> gepubliceerde wiki
  -> zoek- of RAG-laag

De review queue is hier kritiek, omdat gegenereerde kennis nooit direct gepubliceerd mag worden in een teambron van waarheid zonder een menselijk controlepunt – zelfs een lichtgewicht reviewproces vangt de meest gevaarlijke hallucinaties voordat ze institutionele kennis worden.

Patroon 3. LLM Wiki plus RAG

Dit is vaak de meest gebalanceerde architectuur, waarbij je zowel ruwe bronaccesso als gecompileerde synthese krijgt.

ruwe bronnen
  -> LLM Wiki-pagina's
  -> gereviewde kennisbank
  -> zoekindex
  -> RAG over ruwe en gecompileerde kennis
  -> geciteerd antwoord

Het RAG-systeem kan ophalen uit oorspronkelijke documenten, gegenereerde samenvattingen, topicpagina’s, vergelijkingpagina’s en glossariumitems, wat de retrievalkwaliteit significant sterker maakt dan alleen opereren op ruwe documenten.

Patroon 4. LLM Wiki als sitearchitectuur

Voor een technische website kunnen LLM Wiki-ideeën de inhoudstructuur leiden, zelfs zonder automatisering.

artikelen
  -> pijlerpagina's
  -> topicmappen
  -> vergelijkingen
  -> interne links
  -> zoek- en AI-toegang

Dit verandert een blog in een kennissysteem waar artikelen niet alleen posts zijn, maar knooppunten in een gestructureerde kaart – een significant verschil voor zowel de lezerservaring als machine-leesbare vindbaarheid.

LLM Wiki ontwerpprincipes

Houd ruwe bronnen gescheiden

Verlies de oorspronkelijke bron nooit. Gegenereerde pagina’s mogen bronnen documenten niet vervangen, maar erboven staan – de bronaanlaag biedt bewijs, de wikilaag biedt interpretatie, en het verliezen van het origineel betekent het verliezen van het vermogen om de interpretatie die daaruit is afgeleid te verifiëren, uit te dagen of bij te werken.

Gebruik Markdown waar mogelijk

Markdown is saai en uitstekend. Het is draagbaar, leesbaar, diffbaar, versiebeheerbaar, makkelijk te bewerken, vriendelijk voor statische sites en vriendelijk voor PKM-tools. Saai formaten overleven langer dan slimme platforms, wat betekent dat een op Markdown gebaseerde LLM Wiki die vandaag is gebouwd, nog lang bruikbaar zal zijn nadat welke proprietair database je ook hebt gekozen, meerdere brekende migraties heeft ondergaan. Voor syntaxreferentie, zie de Markdown Cheatsheet en de gids voor Markdown Code Blocks, die vooral relevant zijn bij het structureren van wiki-pagina’s die technische inhoud bevatten.

Track provenance

Elke gegenereerde pagina moet kunnen beantwoorden:

• Welke bronnen hebben dit gecreëerd?
• Wanneer is het gegenereerd?
• Wanneer is het gereviewd?
• Wat is veranderd?
• Wie heeft het goedgekeurd?

Zonder provenance stort vertrouwen in de loop van de tijd in wanneer pagina’s verder drijven van hun oorsprong. Een praktische paginameta kan er als volgt uitzien:

titel
samenvatting
status
bronnen
laatst_gereviewd
gerelateerde_paginas
concepten
open_vragen

Voeg voor technische inhoud toe:

van_toepassing_op
versie
voorbeelden
afwegingen
faalmodi

Voeg voor onderzoekscontent toe:

claims
bewijs
tegenstrijdigheden
zekerheid

Geef de voorkeur aan minder, betere pagina’s

Genereer geen pagina voor elk klein idee. Geef de voorkeur aan sterke conceptpagina’s, nuttige vergelijkingpagina’s, topicindexes, canonieke samenvattingen en glossariumitems die hun plaats verdienen. Een kleine nuttige wiki met twintig goed onderhouden pagina’s verslaat een grote gegenereerde rommel met tweehonderd pagina’s die niemand leest of bijwerkt.

Maak links zinvol

Links moeten relaties uitleggen in plaats van pagina’s willekeurig met elkaar te verbinden. Nuttige linktypes omvatten:

• gerelateerd concept
• hangt af van
• contrasteert met
• voorbeeld van
• bron voor
• uitgebreid op
• implementatie van

Willekeurige links creëren ruis en ondermijnen het vertrouwen van de lezer in de structuur.

Markeer onzekerheid

LLM Wiki-pagina’s mogen niet doen alsof alle kennis even zeker is. Nuttige statusmarkeringen omvatten:

• bevestigd
• waarschijnlijk
• betwist
• verouderd
• heeft review nodig
• bronconflict
• gegenereerde samenvatting

Deze markeringen beschermen lezers tegen valse zekerheid en geven onderhouders een duidelijk signaal over welke pagina’s aandacht nodig hebben.

Hoe een LLM Wiki te evalueren

Vraag niet alleen of de gegenereerde pagina’s indrukwekkend zijn – vraag of ze het kenniswerk verbeteren. Nuttige evaluatievragen omvatten:

• Kunnen gebruikers concepten sneller vinden?
• Worden herhaalde vragen beter beantwoord?
• Zijn bronlinks behouden?
• Zijn tegenstrijdigheden makkelijker te zien?
• Worden pagina’s hergebruikt?
• Zijn samenvattingen accuraat?
• Wordt verouderde content gedetecteerd?
• Vermindert de wiki herhaalde synthese?
• Helpt het mensen schrijven of beslissen?
• Verbeter het de RAG-antwoordkwaliteit?

Als het antwoord op de meeste van deze nee is, is de wiki decoratie, ongeacht hoeveel pagina’s het bevat.

LLM Wiki en kennisbeheer

LLM Wiki behoort tot kennisbeheer omdat het fundamenteel gaat over representatie, niet primair over modelhosting, vectorzoektocht of agentuitvoering. Het beantwoordt een andere vraag: hoe moet kennis worden gestructureerd zodat mensen en AI-systemen het kunnen hergebruiken? Dat plaatst het in de kennisarchitectuurlaag, die natuurlijk verbindt met PKM, wikis, RAG, agentgeheugen, kennisgrafieken, technische publicatie en onderzoekssynthese.

Een schone lagenmodel ziet er als volgt uit:

• Menselijk denken - PKM, exploreer en ontwikkel ideeën
• Gedeelde kennis - Wiki, onderhoud canonieke pagina’s
• Gecompileerde kennis - LLM Wiki, genereer gestructureerde synthese
• Machine-toegang - RAG, haal context op op query-moment
• Agentcontinuïteit - Geheugen, persisteer gedrag en voorkeuren

LLM Wiki bezet de gecompileerde kennislage, en die positie is wat het nuttig maakt – het is de laag die een hoop documenten omzet in iets dat zowel mensen als machines kunnen navigeren en redeneren over.

Mijn mening

LLM Wiki is belangrijk, maar de hype is iets verkeerd – het is geen RAG-killer, maar een herinnering dat kennisrepresentatie belangrijk is. De industrie heeft jaren besteed aan het optimaliseren van retrievalpipelines, en dat werk was noodzakelijk, maar veel systemen halen nog steeds op uit slecht gestructureerde kennis. Betere embeddings en betere rerankers helpen, maar ze kunnen niet volledig compenseren voor een zwakke kennislage.

LLM Wiki duwt het gesprek terug naar structuur door betere vragen te stellen:

• Wat zijn de kernconcepten?
• Wat is canoniek?
• Hoe verbinden ideeën zich?
• Wat moet één keer worden samengevat?
• Wat moet vers worden opgehaald?
• Wat moet door mensen worden gereviewd?

Dat is het juiste gesprek, en de toekomst is niet alleen betere vectorzoektocht, maar gelaagde kennissystemen waar representatie, retrieval en geheugen elk een duidelijke en goed begrepen rol spelen.

Conclusie

LLM Wiki is een architectuurpatroon voor gecompileerde kennis dat taalmodellen gebruikt om te helpen bij het transformeren van bronmateriaal naar gestructureerde, gekoppelde, herbruikbare kennis voordat vragen worden gesteld. De kernworkflow is:

samenvatten
  -> structureren
  -> koppelen
  -> reviewen
  -> hergebruiken

In vergelijking met RAG is het belangrijkste verschil timing: RAG voert synthese uit op het query-moment, terwijl LLM Wiki synthese uitvoert op het binnenhalingsmoment, wat het waardevol maakt voor stabiele domeinen, onderzoekssynthese, persoonlijke kennisbanken, technische blogs en gecuratede teamkennis.

Maar het heeft echte beperkingen. Het kan drijven wanneer bronnen veranderen, hallucineren wanneer modeloutput verkeerd is, valse zekerheid creëren wanneer review afwezig is, en in ruis vervallen wanneer eigendom onduidelijk is. Slecht gebruikt, wordt het een andere verlaten wiki. Goed gebruikt, wordt het de representatielaag tussen ruwe documenten en AI-systemen – geen vervanging voor RAG, maar de ontbrekende laag die retrieval de moeite waard maakt.

Bronnen en verdere lees

• AWS - What Is Retrieval Augmented Generation? - AWS fundamenteel overzicht van hoe RAG-pipelines worden geconstrueerd en wanneer ze geschikt zijn.
• IBM - Retrieval Augmented Generation - IBM-overzicht van RAG-architectuur, inclusief grounding, reductie van hallucinaties en enterprise-use cases.
• Google Cloud - Retrieval Augmented Generation - Google Cloud-perspectief op RAG-use cases, systeemontwerp en integratie met vectorzoektocht.
• Atlan - LLM Wiki vs RAG Knowledge Base - Praktische vergelijking van LLM Wiki en RAG-aanpakken vanuit een datacatalog-perspectief.
• Ranjan Kumar - LLM Wiki, Synthesis Time, RAG, and Agentic Memory - Diepgaand bespreking van het timingonderscheid tussen syntheseaanpakken en hoe ze passen in agentic-architecturen.
• Dev.to - RAG vs Agent Memory vs LLM Wiki - Praktische vergelijking van alle drie de kennispatternen met implementatienotities.
• Starmorph - Karpathy LLM Wiki Knowledge Base Guide - Gids geïnspireerd door Andrej Karpathy’s framing van LLM Wiki als een gecompileerd kennissysteem.
• MindStudio - LLM Wiki vs RAG Knowledge Base - MindStudio-perspectief op het kiezen tussen LLM Wiki en RAG voor AI-assistentkennis.