Retrieval versus Representatie in Kennissystemen

De meeste moderne kennissystemen optimaliseren de terugwinning (retrieval), en dat is begrijpelijk. Zoeken is zichtbaar, eenvoudig te demonstreren en voelt magisch wanneer het werkt. Typ een vraag, krijg een antwoord.

Maar terugwinning is slechts de helft van het probleem. Dieperliggende vraag is:

Welke vorm heeft de kennis voordat er iets wordt geprobeerd om deze terug te winnen?

Dat is representatie — de structuur achter de kennis:

• notities
• pagina’s
• schema’s
• grafieken
• entiteiten
• relaties
• samenvattingen
• taxonomieën
• bronbegrenzingen
• canonieke versies

Terugwinning vraagt:

Kan ik iets relevants vinden?

Representatie vraagt:

Is de kennis zo georganiseerd dat het zinvol is?

Dit zijn niet hetzelfde probleem. Een RAG-systeem met slechte representatie wordt een snelle interface naar een rommelig archief. Het kan fragmenten terugwinnen, maar het kan een gebroken structuur niet repareren. Het kan documenten citeren, maar het kan niet beslissen welke canoniek is. Het kan context samenstellen, maar het kan niet garanderen dat de onderliggende kennis coherent is.

Daarom zijn systemen in de stijl van LLM Wiki interessant: ze verplaatsen de inspanning van de query-tijd naar de ingangstijd (ingest time). In plaats van alleen chunks terug te winnen wanneer een gebruiker een vraag stelt, proberen ze kennis vooraf te structureren in pagina’s, concepten, samenvattingen en links. Dit maakt RAG niet overbodig — het betekent dat terugwinning en representatie verschillende lagen zijn, en goede kennissystemen beide nodig hebben.

De kernverschil

Terugwinning gaat over toegang; representatie gaat over betekenis.

Een zwak systeem springt vaak direct naar terugwinning; een sterk systeem vraagt eerst:

1. Wat zijn de kernconcepten?
2. Wat is de canonieke bron?
3. Welke relaties zijn belangrijk?
4. Wat verandert over tijd?
5. Wat moet worden teruggewonnen?
6. Wat moet al gerepresenteerd zijn?

Dit is het verschil tussen zoeken over documenten en een echt kennissysteem.

Waarom terugwinning dominant werd

Terugwinning werd dominant omdat het goed aansluit bij de moderne AI-stack. Een typische RAG pipeline ziet er als volgt uit:

1. Documenten laden
2. Ze opsplitsen in chunks
3. Embeddings genereren
4. Vectoren opslaan
5. Relevante chunks terugwinnen
6. Optioneel herclassificeren (rerank)
7. Ze in een LLM-prompt plaatsen
8. Een antwoord genereren

Deze pipeline is praktisch: hij is relatief eenvoudig te bouwen, werkt met rommelige documenten, schaalt naar grote corpus, vermijdt het opnieuw trainen van modellen en geeft LLM’s toegang tot actuele informatie. Daarom werd RAG het standaardpatroon voor “AI over documenten”.

Maar er is een val:

RAG verbetert de toegang tot kennis. Het verbetert de kennis niet automatisch.

Als uw inhoud gedupliceerd, verouderd, contradictorisch, slecht opgesplitst of slecht benoemd is, zal terugwinning deze problemen naar boven halen — vaak met zelfvertrouwen.

Wat representatie betekent

Representatie is de manier waarop kennis wordt gevormd voordat terugwinning plaatsvindt. Het beantwoordt vragen zoals:

• Is deze kennis opgeslagen als documenten, notities, entiteiten of feiten?
• Zijn relaties expliciet of impliciet?
• Zijn er canonieke pagina’s?
• Zijn er samenvattingen?
• Zijn concepten gelinkt?
• Is het systeem georganiseerd op onderwerp, workflow, tijd of eigenaarschap?
• Kan een mens het onderhouden?
• Kan een machine erover redeneren?

Representatie is geen versiering — het bepaalt welke operaties mogelijk zijn.

Vormen van representatie

Documenten

Documenten zijn de meest voorkomende representatie. Voorbeelden zijn:

• artikelen
• PDF’s
• handleidingen
• rapporten
• README-bestanden
• supportpagina’s
• blogberichten

Documenten zijn eenvoudig voor mensen om te schrijven, maar ze zijn vaak moeilijk voor machines te gebruiken omdat ze feiten, narratief, context, voorbeelden, meningen, verouderde secties en herhaalde uitleg in dezelfde container mengen. Documenten zijn goede containers, maar ze zijn niet altijd goede kennisstructuren.

Notities

Notities zijn flexibeler dan documenten. Ze kunnen:

• atoom zijn
• gelinkt zijn
• privé zijn
• onaf zijn
• conceptgericht zijn

Een notitiesysteem, zoals een PKM of tweede hersenen, kan evoluerende kennis beter representeren dan een gepolijste documentenrepository. Goede notities vangen denken in ontwikkeling op; slechte notities worden een ondoorzoekbare rommellade.

Wikis

Wikis representeren kennis als onderhouden pagina’s. Een goede wiki heeft:

• stabiele pagina’s
• duidelijke onderwerpen
• interne links
• eigenaarschap
• canonieke antwoorden
• updatepatronen

Een wiki is sterker dan een losse documentdump omdat hij kennis een thuis geeft. “Implementatiechecklist” woont op één plek. “Incidentresponse” woont op één plek. “RAG-architectuur” woont op één plek. Dat is belangrijk omdat terugwinning beter werkt wanneer kennis een stabiele structuur heeft.

Kennisgrafieken

Kennisgrafieken representeren kennis als entiteiten en relaties. In plaats van alleen tekst op te slaan, modelleren ze dingen zoals:

• Persoon werkt aan Project
• Model ondersteunt ContextLength
• Pagina is afhankelijk van Concept
• Service verbindt met Database
• Tool implementeert Protocol

Grafieken zijn krachtig omdat relaties expliciet worden, wat helpt bij traversing, afhankelijkheidsanalyse, entiteitsoplossing, afstammingslijnen, redeneren en aanbevelingen. Maar grafieken zijn duur in onderhoud en ze zijn geen toverij — een slechte grafiek is slechts gestructureerde verwarring.

Schema’s en ontologieën

Schema’s definiëren verwachte structuur; ontologieën gaan verder en definiëren types, relaties en beperkingen. Ze beantwoorden:

• Welke soorten dingen bestaan?
• Welke eigenschappen hebben ze?
• Hoe kunnen ze zich verhouden?
• Welke regels zijn van toepassing?

Dit is nuttig wanneer correctheid belangrijk is, zoals in medische kennis, juridische kennis, enterprise data-catalogi, producttaxonomieën en compliance-systemen. De trade-off is rigiditeit: hoe formeler de representatie, hoe duurder het is om te evolueren.

LLM-genererde representaties

Moderne systemen gebruiken steeds vaker LLM’s om representaties te creëren. Voorbeelden zijn:

• samenvattingen
• geëxtraheerde entiteiten
• onderwerppagina’s
• conceptkaarten
• synthetische FAQs
• documentoverzichten
• cross-links
• glossariumitems

Dit is waar systemen in de stijl van LLM Wiki zitten. Ze gebruiken het model niet alleen om queries te beantwoorden, maar ook om kennis vooraf te verwerken en te structureren voordat de query plaatsvindt. RAG zegt “win relevante chunks terug op query-tijd”; LLM Wiki zegt “compileer nuttige kennisstructuren op ingangstijd”. Beide patronen kunnen in dezelfde architectuur coëxisteren.

Wat terugwinning betekent

Terugwinning is het proces van het vinden van relevante informatie. Veelvoorkomende terugwinningsmethoden zijn:

• zoekopdrachten op trefwoord
• full-text zoekopdrachten
• vectorzoekopdrachten
• hybride zoekopdrachten
• metadatafiltering
• grafiektraversing
• herclassificatie (reranking)
• query-herformulering
• agentische zoekopdrachten

Terugwinning is niet één ding — het is een gelaagde stack van complementaire methoden.

Zoeken op trefwoord

Zoeken op trefwoord komt overeen met termen en is nog steeds nuttig omdat het voorspelbaar, debugbaar, snel en goed is voor exacte termen, IDs, foutberichten, namen en code. Zijn zwakte is semantische mismatch: als de gebruiker zoekt naar “hoe herhaalde antwoorden te stoppen” maar het document zegt “presence penalty”, kan trefwoordzoektocht het beste resultaat missen.

Vectorzoektocht

Vectorzoektocht wint terug op semantische similariteit. Het is nuttig wanneer:

• de formulering verschilt
• concepten vaag zijn
• gebruikers vragen in natuurlijke taal stellen
• documenten inconsistente terminologie gebruiken

De zwakte is precisie — vectorzoektocht kan dingen terugwinnen die gerelateerd lijken maar niet feitelijk correct zijn, wat vooral riskant is in technische systemen.

Hybride zoektocht

Hybride zoektocht combineert zoekopdrachten op trefwoord en vector, wat vaak beter is dan beide afzonderlijk. Trefwoordzoektocht vangt exacte matches; vectorzoektocht vangt conceptuele matches. Voor technische kennisbases is hybride terugwinning meestal een sterke standaard.

Herclassificatie (Reranking)

[Herclassificatie]({< ref “/rag/reranking/reranking-with-embedding-models/” >} “Herclassificatie met embedding-modellen”) neemt een initiële set teruggewonnen resultaten en sorteert ze opnieuw met behulp van een sterker model. Dit verbetert de kwaliteit omdat de eerste terugwinningsstap vaak breed is. Een typisch patroon wint 50 chunks terug, herclassificeert naar de top 5 of 10 en doorgeeft alleen de beste context aan de LLM. Herclassificatie is een van de meest praktische manieren om RAG-kwaliteit te verbeteren.

Agentische terugwinning

Agentische terugwinning maakt van zoeken een proces. In plaats van één query kan een agent:

1. Een initiële vraag stellen
2. Zoeken
3. Resultaten inspecteren
4. De query herformuleren
5. Opnieuw zoeken
6. Bronnen vergelijken
7. Een antwoord synthetiseren

Dit is dichter bij onderzoek dan bij zoeken. Het is nuttig voor complexe vragen, maar het is langzamer en moeilijker te controleren.

Terugwinning zonder representatie is fragiel

Een terugwinningsysteem kan alleen terugwinnen wat bestaat. Het kan niet betrouwbaar fixen:

• onduidelijke concepten
• gedupliceerde pagina’s
• inconsistente terminologie
• verouderde documentatie
• ontbrekend bron-eigenaarschap
• contradictorische uitspraken
• zwakke interne koppelingen
• slechte documentgrenzen

Dit is de meest voorkomende fout in RAG-projecten: teams bouwen een vectordatabase en verwachten dat het een kennissysteem wordt. Een vectordatabase is geen kennisarchitectuur — het is een toegangs laag.

Representatie zonder terugwinning is geïsoleerd

Het tegengestelde falen bestaat ook. Je kunt een prachtig gestructureerde kennisbase hebben die niemand kan vinden. Dit gebeurt met:

• overontworpen wikis
• diepe mapstructuren
• rigide taxonomieën
• slecht geïndexeerde documentatie
• private notitiesystemen zonder ontdekking
• grafieken zonder bruikbare interfaces

Representatie geeft kennis structuur; terugwinning geeft kennis bereik. Je hebt beide nodig.

De trade-off kaart

Snelheid vs coherentie

Terugwinning is snel te bouwen en representatie kost langer. Als je een prototype nodig hebt, wint terugwinning; als je op lange termijn vertrouwen nodig hebt, is representatie belangrijker.

Een puur RAG-proTOTYPE kan snel worden gebouwd, maar een betrouwbaar kennissysteem vereist curatie.

Flexibiliteit vs consistentie

Losse documenten zijn flexibel; gestructureerde kennis is consistent. Flexibiliteit helpt wanneer:

• het domein snel verandert
• kennis onvolledig is
• gebruikers verkennen
• het systeem persoonlijk is

Consistentie helpt wanneer:

• meerdere mensen erop vertrouwen
• antwoorden vertrouwd moeten worden
• workflows er afhankelijk van zijn
• AI-systemen het consumeren

Hoe meer mensen of agents afhankelijk zijn van kennis, hoe belangrijker representatie is.

Recall vs precisie

Terugwinningsystemen optimaliseren vaak eerst recall, wat betekent dat ze alles vinden wat mogelijk relevant is. Maar goede antwoorden vereisen precisie, wat betekent dat ze het beste bewijs vinden in plaats van slechts gerelateerd bewijs. Representatie verbetert precisie door concepten en grenzen duidelijker te maken — een goed gestructureerde pagina is nauwkeuriger terug te winnen dan een willekeurige paragraaf die begraven zit in een lang document.

Kosten op ingangstijd vs kosten op query-tijd

RAG duwt werk meestal naar query-tijd. Op query-tijd doet het systeem:

• de query herschrijven
• chunks terugwinnen
• resultaten herclassificeren
• context samenstellen
• het model vragen om te redeneren over fragmenten

Systemen in de stijl van LLM Wiki duwen meer werk naar de ingangstijd. Op ingangstijd doet het systeem:

• bronnen lezen
• concepten extraheren
• samenvattingen schrijven
• pagina’s creëren
• gerelateerde ideeën linken
• structuur onderhouden

Geen van deze is universeel beter — ze optimaliseren verschillende kosten.

Waarom LLM Wiki bestaat

LLM Wiki bestaat omdat terugwinning alleen vaak werk herhaalt. In een normaal RAG-systeem kan elke query het model dwingen om ruwe fragmenten opnieuw te interpreteren:

1. Chunks over een onderwerp terugwinnen
2. De LLM vragen om het concept af te leiden
3. Een antwoord genereren
4. De synthese vergeten
5. Volgende keer herhalen

LLM Wiki zegt:

Stop met het zelfde samenvatten af te leiden. Compileer het.

In plaats van alleen ruwe documenten op te slaan, creëert het gestructureerde pagina’s die kennis samenvatten en verbinden, wat coherentie, hergebruik, token-efficiëntie, menselijke leesbaarheid en langetermijnonderhoud kan verbeteren. Maar het heeft een kosten: het systeem moet de wiki onderhouden, en als de wiki verkeerd, verouderd of gehaluceerd is, wordt de structuur gevaarlijk.

RAG-halucinaties vs slechte representatie

Mensen verwijten vaak de LLM wanneer een RAG-systeem een slecht antwoord geeft, en soms is dat correct. Maar veel failures zijn eigenlijk terugwinning- of representatiefailures.

Foutpatroon 1. Correct document, verkeerde chunk

Het antwoord bestaat, maar chunking splitst het slecht. Het model ontvangt:

• de helft van een paragraaf
• ontbrekende context
• een tabel zonder uitleg
• een definitie zonder beperkingen

De LLM vult die gaten, wat er uitziet als halucinaties, maar het diepere probleem is gebroken representatie.

Foutpatroon 2. Gerelateerde chunk, verkeerd antwoord

Vectorzoektocht wint iets terug dat semantisch vergelijkbaar is maar operationeel verkeerd. De query gaat over productie-implementatie; de teruggewonnen chunk bespreekt lokale ontwikkeling. De termen overlappen maar de betekenis verschilt, dus het model antwoordt met lokale setup-instructies voor een productievraagstuk. Dit is terugwinningsimprecisie.

Foutpatroon 3. Conflicterende bronnen

Twee documenten komen niet overeen — één oud, één nieuw. Het terugwinningsysteem retourneert beide, en de LLM mergeert ze tot een zelfverzekerd maar ongeldig antwoord. Dit is niet alleen een terugwinningsprobleem maar een representatieprobleem, omdat de kennisbase geen canonieke staat heeft.

Foutpatroon 4. Geen conceptmodel

Het systeem heeft veel documenten maar geen model van het domein. Het weet niet dat:

• “agent geheugen” verschilt van “RAG”
• “wiki” verschilt van “PKM”
• “embedding zoektocht” verschilt van “full-text zoektocht”
• “implementatie” verschilt van “hosting”

Zonder conceptuele representatie wordt terugwinning vaag matching.

Foutpatroon 5. Gegenerateerde structuur wordt valse autoriteit

LLM Wiki-systemen hebben hun eigen foutpatroon. Als een LLM een schone pagina genereert uit slechte bronnen, kan het resultaat autoritatiever lijken dan het oorspronkelijke materiaal. Dit is gevaarlijk: een gepolijste halucinaties is erger dan een rommelig bron-document. Elke gegenereerde representatie heeft nodig:

• bronlinks
• review
• updateregels
• confidentiemarkers
• eigenaarschap

Ontwerpimplicaties

Optimaliseer terugwinning wanneer de corpus groot en dynamisch is

Terugwinning moet de prioriteit zijn wanneer:

• de corpus enorm is
• documenten vaak veranderen
• gebruikers veel onvoorspelbare vragen stellen
• u brede dekking nodig heeft
• perfecte structuur onrealistisch is

Voorbeelden: supportkennisbases, enterprise documentzoektocht, onderzoeksassistenten, interne chat over veel bestanden, juridische discovery en klantenservicebots. In deze gevallen moet u investeren in sterke terugwinning:

• hybride zoektocht
• metadatafilters
• herclassificatie
• query-herformulering
• broncitatie
• evaluatiesets

Optimaliseer representatie wanneer coherentie belangrijk is

Representatie moet de prioriteit zijn wanneer:

• kennis vertrouwd moet worden
• antwoorden consistent moeten zijn
• concepten vaak worden hergebruikt
• het domein een duidelijke structuur heeft
• meerdere systemen er afhankelijk van zijn

Voorbeelden: architectuurkennis, productdocumentatie, compliance-regels, API-referenties, operationele runbooks, gecureerde onderzoekscollecties en technische blogclusters. In deze gevallen moet u investeren in:

• canonieke pagina’s
• glossariusterms
• diagrammen
• interne links
• eigenaarschap
• versiebeheer
• reviewfrequentie

Optimaliseer beide wanneer AI-systemen afhankelijk zijn van kennis

Als een AI-agent afhankelijk is van de kennis, is terugwinning alleen meestal niet genoeg. Agents hebben nodig:

• stabiele context
• duidelijke taakregels
• duurzaam geheugen
• gestructureerde referenties
• bronbegrenzingen
• updategedrag

Voor agentische systemen wordt representatie onderdeel van systeemontwerp. Een codeeragent heeft niet alleen nodig om “sommige docs” terug te winnen — het moet weten:

• projectconventies
• architectuurbeslissingen
• commandopatronen
• verboden afhankelijkheden
• testworkflow
• implementatieregels

Een deel daarvan hoort bij RAG, een deel bij geheugen en een deel bij gestructureerde projectdocumentatie.

Praktisch besliskader

Als het probleem informatie vinden is

Optimaliseer terugwinning. Voorbeelden:

• “Vind relevante pagina’s.”
• “Beantwoord vragen over documenten.”
• “Zoek door veel PDF’s.”
• “Locatie vergelijkbare supporttickets.”

Gebruik:

• full-text zoektocht
• vectorzoektocht
• hybride terugwinning
• herclassificatie
• metadatafiltering

Als het probleem kennis coherent maken is

Optimaliseer representatie. Voorbeelden:

• “Creëer een canonieke uitleg.”
• “Los gedupliceerde pagina’s op.”
• “Definieer het domeinmodel.”
• “Bouw een stabiele kennisbase.”

Gebruik:

• wikipagina’s
• conceptkaarten
• taxonomieën
• kennisgrafieken
• samenvattingen
• schema’s

Als het probleem herhaalde synthese is

Gebruik samengestelde representatie. Voorbeelden:

• “We beantwoorden dezelfde conceptuele vragen herhaaldelijk.”
• “Het systeem herhaalt constant dezelfde bronnen.”
• “We hebben een stabiele syntheselaag nodig.”

Gebruik:

• LLM Wiki
• gecureerde samenvattingen
• onderwerppagina’s
• door mensen gereviewde gegenereerde pagina’s

Als het probleem adaptieve continuïteit is

Gebruik geheugen. Voorbeelden:

• “De agent moet gebruikersvoorkeuren onthouden.”
• “De codeeragent moet projectconventies onthouden.”
• “De assistent moet werk voortzetten across sessies.”

Gebruik:

• agent geheugen
• voorkeursopslag
• episodisch geheugen
• semantisch geheugen
• projectgeheugen

Hoe dit van toepassing is op een technische blog

Een technische blog kan meer zijn dan een reeks posts — het kan een gerepresenteerd kennissysteem worden. Artikelen zijn documenten, categorieën zijn zwakke taxonomie, interne links zijn grafiek randen, pillarpagina’s zijn canonieke samenvattingen, seriepagina’s zijn gecureerde paden en zoektocht is terugwinning. Als je alleen geïsoleerde posts publiceert, moet terugwinning harder werken. Als je sterke representatie bouwt, wordt terugwinning makkelijker.

Dat betekent:

• duidelijke cluster grenzen
• stabiele slugs
• canonieke pagina’s
• vergelijkingpagina’s
• glossariumstijl uitleggen
• interne links
• gestructureerde metadata

Daarom is site-architectuur belangrijk — niet alleen voor SEO, maar omdat het kennisrepresentatie is. De Knowledge Management cluster op deze site is zelf een voorbeeld van representatie-first publicatie.

Hoe dit van toepassing is op RAG

RAG-kwaliteit hangt sterk af van representatie. Een goed gestructureerde broncorpus verbetert:

• chunk kwaliteit
• terugwinningsnauwkeurigheid
• citatiekwaliteit
• antwoordconsistentie
• evaluatiehelderheid

Voordat u een complexe RAG-pipeline bouwt, vraag:

1. Zijn de bronnen actueel?
2. Zijn duplicaten verwijderd?
3. Zijn belangrijke concepten duidelijk benoemd?
4. Zijn pagina’s correct gescopt?
5. Zijn tabellen en codeblokken terug te winnen?
6. Zijn canonieke antwoorden duidelijk?
7. Zijn documentgrenzen zinvol?

Als het antwoord nee is, zullen betere embeddings alleen zo veel helpen.

Hoe dit van toepassing is op LLM Wiki

LLM Wiki is een representatie-first patroon. Het is nuttig wanneer:

• de corpus klein of middelgroot is
• kennis stabiel genoeg is om samen te vatten
• herhaalde synthese duur is
• mensen baat hebben bij leesbare pagina’s
• u structuur wilt voor terugwinning

Het is minder nuttig wanneer:

• de corpus massief is
• inhoud constant verandert
• versheid belangrijker is dan coherentie
• governance zwak is
• gegenereerde samenvattingen niet gereviewd kunnen worden

LLM Wiki is geen vervanging voor RAG maar een andere laag, en een sterk systeem kan beide gebruiken:

1. LLM Wiki creëert gestructureerde samenvattingen.
2. RAG wint terug van ruwe bronnen en wikipagina’s.
3. Menselijke review houdt de representatie betrouwbaar.

Voorgestelde architectuurpatronen

Patroon 1. Terugwinning eerst

Gebruik wanneer snelheid belangrijk is.

documenten
  -> chunks
  -> embeddings
  -> terugwinning
  -> LLM antwoord

Goed voor:

• prototypes
• brede zoektocht
• grote corpus
• vroege experimenten

Zwakte: coherentie hangt af van bronkwaliteit.

Patroon 2. Representatie eerst

Gebruik wanneer vertrouwen belangrijk is.

bronnen
  -> gecureerde pagina's
  -> interne links
  -> onderhouden kennisbase
  -> zoektocht of RAG

Goed voor:

• documentatie
• technische kennis
• langetermijninhoud
• teamkennis

Zwakte: vereist onderhoud.

Patroon 3. Samengestelde kennis

Gebruik wanneer herhaalde synthese belangrijk is.

ruwe bronnen
  -> LLM extractie
  -> gegenereerde samenvattingen
  -> onderwerppagina's
  -> gereviewde kennisbase
  -> terugwinning

Goed voor:

• LLM Wiki systemen
• onderzoekscollecties
• persoonlijke kennisbases
• stabiele domeinen

Zwakte: gegenereerde structuur moet worden geaudited.

Patroon 4. Hybride kennisarchitectuur

Gebruik wanneer je serieuze systemen bouwt.

ruwe documenten
  -> gestructureerde kennislaag
  -> zoekindex
  -> terugwinning en herclassificatie
  -> AI antwoord
  -> feedback en onderhoud

Goed voor:

• productie RAG
• interne kennissystemen
• AI-assistenten
• technische publicatiesystemen

Zwakte: meer bewegende delen.

Evaluatievragen

Om terugwinning te evalueren, vraag:

• Vond het systeem de juiste bron?
• Rangschikte het de juiste bron hoog?
• Won het genoeg context terug?
• Vermijde het irrelevante context?
• Citeerde het antwoord de correcte bron?

Om representatie te evalueren, vraag:

• Is de kennis duidelijk gestructureerd?
• Is er een canonieke pagina?
• Zijn concepten consistent benoemd?
• Zijn relaties expliciet?
• Wordt de inhoud onderhouden?
• Kunnen zowel mensen als machines het gebruiken?

Evalueer een kennissysteem niet alleen op antwoordkwaliteit — een goed antwoord kan een slechte structuur verbergen.

De meningsvolle regel

Als uw systeem af en toe faalt, verbeter dan de terugwinning. Als het herhaaldelijk faalt in hetzelfde conceptuele gebied, verbeter dan de representatie.

Slechte terugwinning mist de juiste informatie. Slechte representatie betekent dat de juiste informatie niet echt bestaat in een bruikbare vorm.

Conclusie

Terugwinning en representatie lossen verschillende problemen op: terugwinning geeft toegang, representatie geeft structuur. RAG is krachtig omdat het externe kennis beschikbaar maakt voor LLM’s op query-tijd, maar RAG maakt kennis niet automatisch coherent, canoniek of onderhouden. Daarom zijn wikis, PKM-systemen, kennisgrafieken en systemen in de stijl van LLM Wiki nog steeds belangrijk.

De toekomst is niet terugwinning vs representatie maar gelaagde kennissystemen:

• representatie voor structuur
• terugwinning voor toegang
• geheugen voor continuïteit
• redeneren voor synthese

Als je een serieus kennissysteem bouwt, begin dan niet met de vectordatabase. Begin met de vorm van de kennis, en beslis daarna hoe het moet worden teruggewonnen.

Bronnen en verder lezen

• Google Cloud — Retrieval Augmented Generation
• AWS — What Is Retrieval Augmented Generation?
• IBM — Retrieval Augmented Generation
• IBM — Knowledge Management
• Atlan — LLM Wiki vs RAG Knowledge Base
• Dev.to — RAG vs Agent Memory vs LLM Wiki
• Starmorph — Karpathy LLM Wiki Knowledge Base Guide