De stateless RAG-valkuil: waarom AI-architectuur die bij elke vraag opnieuw zoekt tekortschiet

By Mirko Peters · 2026-08-13

Welkom terug op de blog! Als je onze podcastgesprekken over enterprise-AI volgt, weet je dat we veel tijd besteden aan wat er achter de eerste hype van moderne productiviteitstools schuilt.

Automatically translated with AI from the original post. Read the English original

Welkom terug op de blog! Als je onze podcastgesprekken over enterprise-AI volgt, weet je dat we veel tijd besteden aan wat er achter de eerste hype van moderne productiviteitstools schuilt. In een standaarddemonstratie kunnen tools als Microsoft Copilot opvallend intelligent overkomen. Ze vinden een projectdocument, vatten een beleid samen, halen informatie uit SharePoint en verbinden stukjes bedrijfscontent tot een overtuigend antwoord. Maar achter die indrukwekkende gebruikerservaring schuilt een fundamentele architectuurbeperking: ophalen is geen geheugen. Copilot kan je organisatie doorzoeken, maar dat betekent niet dat het een blijvend begrip van je organisatie heeft opgebouwd. In deze post duiken we diep in de mechanismen van Retrieval-Augmented Generation om te begrijpen hoe chunking en stateless querylussen voorkomen dat AI opgebouwde context behoudt over interacties binnen de organisatie heen. Bekijk zeker ook de bijbehorende podcastaflevering, Your Copilot Has No Memory — Why RAG Fails and LLM Wiki Fixes It, voor een diepgaandere audiotoelichting van deze concepten.

Copilot onthoudt niet, het haalt op

Het gebruik van Copilot creëert een belangrijke illusie. Wanneer het informatie uit Microsoft 365 succesvol koppelt, lijkt het alsof het systeem iets over je organisatie heeft geleerd. Stel je later een vergelijkbare vraag, dan kan het systeem echter een ander resultaat geven, omdat het opnieuw een ophaalactie uitvoert in plaats van simpelweg het eerder opgebouwde begrip te herinneren. Dat onderscheid wordt cruciaal zodra organisaties verder gaan dan basale samenvattingen en van AI verwachten dat het echte beslissingen ondersteunt.

Als vrijwel identieke vragen tot inconsistente antwoorden kunnen leiden, afhankelijk van welke informatie er is opgehaald, worden gebruikers er snel terughoudend in om AI te gebruiken voor bedrijfskritisch werk. Het resultaat kan eerder een adoptieprobleem zijn dan louter een technisch probleem. Gebruikers willen voorspelbaarheid, en wanneer een assistent op maandag het ene antwoord geeft en op donderdag een tegenstrijdig antwoord op exact dezelfde prompt, brokkelt het vertrouwen snel af.

Wat Retrieval-Augmented Generation echt doet

RAG staat voor Retrieval-Augmented Generation. Vereenvoudigd gezegd worden bedrijfsdocumenten opgedeeld in chunks, worden die chunks weergegeven via embeddings, wordt de vraag van een gebruiker omgezet in een vergelijkbare representatie en zoekt het systeem naar semantisch relevante chunks. De best scorende informatiefragmenten worden vervolgens als context aan het taalmodel aangeleverd om het antwoord te genereren.

Deze architectuur is ontzettend nuttig. Ze stelt een groot taalmodel in staat om vragen te beantwoorden met informatie die nooit deel uitmaakte van de oorspronkelijke trainingsdata, en biedt een praktische manier om AI-antwoorden te baseren op bedrijfscontent. Maar ze brengt ook een belangrijke architecturale beperking met zich mee: het model krijgt fragmenten die voor de huidige vraag zijn geselecteerd, in plaats van een volledige, blijvende representatie van de kennis van de organisatie.

Het chunkingprobleem

Bedrijfskennis bestaat zelden uit losse alinea's. Een projectplan kan afhankelijkheden bevatten die verspreid liggen over tientallen pagina's. Een beleid kan naar een ander beleid verwijzen. Een technische architectuur kan afhangen van beslissingen die maanden eerder zijn vastgelegd in vergadernotities, Teams-gesprekken, SharePoint-pagina's en ontwerpdocumenten.

Traditionele RAG splitst die bronnen op in kleinere eenheden en bepaalt welke fragmenten relevant lijken voor de huidige vraag. Het model ziet dus geselecteerde stukken, en begrijpt niet noodzakelijkerwijs het volledige document met alle onderlinge relaties. Voor eenvoudige informatieopvraging kan dat uitstekend werken. Bij vragen die over relaties, historische context, afhankelijkheden, opgebouwde beslissingen of redeneren over veel bronnen gaan, worden de beperkingen veel zichtbaarder.

De stateless RAG-valkuil

Een conventionele retrieval-workflow heeft geen ingebouwd concept van iets dat al is uitgezocht. Er komt een vraag binnen, informatie wordt opgehaald, een antwoord wordt gegenereerd, en daarna begint het proces opnieuw voor de volgende retrieval-bewerking. Precies hier wordt de stateloosheid van RAG een grote hindernis.

Kennis die tijdens één interactie wordt ontdekt, wordt niet automatisch duurzame organisatiekennis die beschikbaar is voor elke volgende interactie. Voor enterprise AI is dit een enorm verschil. Organisaties hebben niet alleen betere zoekfunctionaliteit nodig. Ze hebben steeds vaker systemen nodig die een gestructureerd begrip kunnen bijhouden van projecten, processen, beleid, technologieën, mensen, beslissingen, afhankelijkheden en de relaties die die met elkaar verbinden.

Kennis zoeken versus kennis samenstellen

Dit leidt tot het centrale architectuuridee dat we verkennen in onze nieuwste audioserie: in plaats van organisatiekennis bij elke vraag opnieuw te reconstrueren, wat als AI die kennis vooraf samenstelt? Een LLM Wiki vertegenwoordigt die verandering in denken.

In plaats van elk zakelijk document te behandelen als nog een verzameling fragmenten die wacht op retrieval, kan kunstmatige intelligentie informatie synthetiseren tot gestructureerde kennisartefacten die weergeven wat de organisatie op dit moment begrijpt. De belangrijkste verandering is niet simpelweg een andere gebruikersinterface. Het gaat om een verschuiving van reconstructie op querymoment naar persistente kennissynthese.

Waarom een LLM Wiki het model verandert

Stel je duizenden documenten voor die dezelfde productlijn, klant, project, beleid of architectuur beschrijven. Traditionele RAG wacht op een vraag en probeert vervolgens de fragmenten te vinden die die vraag het meest waarschijnlijk beantwoorden. Een LLM Wiki-aanpak zet die gefragmenteerde bronnen juist voortdurend om in samenhangende kennispagina's.

Relaties, beslissingen, definities, afhankelijkheden, historische context en ondersteunende bronnen kunnen onderdeel worden van een bijgehouden kennisrepresentatie. Copilot of een andere AI-agent kan dan ophalen uit een laag met gesynthetiseerd organisatiebegrip, in plaats van dat begrip telkens opnieuw uit ruwe documenten te moeten reconstrueren.

Van documentrepository naar kennislaag

Dit verandert de rol van systemen zoals SharePoint. SharePoint kan blijven dienen als de autoritatieve bron voor documenten, pagina's, beleid, presentaties, vergaderartefacten en samenwerkingsinhoud. Maar ruwe bedrijfscontent vormt niet automatisch bruikbare organisatiekennis.

Een door AI gegenereerde kennislaag kan bovenop die brontoepassingen komen te liggen en verspreide informatie omzetten in iets dat meer lijkt op een organisatiekaart: projecten gekoppeld aan beslissingen, beleid gekoppeld aan processen, systemen gekoppeld aan eigenaren en concepten gekoppeld aan het bewijs dat ze ondersteunt. Het doel is niet om brondocumenten te elimineren. Het doel is om de relaties die erin verborgen zitten expliciet te maken.

Waarom betere prompts de architectuur niet oplossen

Prompt engineering kan verbeteren hoe een LLM opgehaalde context interpreteert, maar het kan niet garanderen dat de juiste context überhaupt is opgehaald. Als de retrieval-laag onvolledige fragmenten teruggeeft, een belangrijke afhankelijkheid mist of een verouderd document naar voren haalt, redeneert zelfs een uitstekend model over een onvolledige informatieset.

Daarom kan het verbeteren van alleen het model niet elk enterprise AI-probleem oplossen. De kwaliteit en structuur van de kennis die aan het model wordt aangeleverd, blijven fundamenteel. Geen enkele hoeveelheid promptwizardry kan een onderliggende architectuur repareren die leunt op vluchtige zoekresultaten in plaats van gestructureerd, persistent geheugen.

Het governance-probleem wordt groter

Aan deze architectuur hangt ook een serieuze waarschuwing. Als de SharePoint-omgeving van een organisatie verouderd beleid, dubbele documentatie, verlaten processen, tegenstrijdige instructies of documenten zonder duidelijke eigenaar bevat, kan een LLM Wiki die slechte informatie net zo efficiënt synthetiseren als goede informatie.

Het gevaar is dat gesynthetiseerde kennis veel schoner en gezagsvoller kan lijken dan de onderliggende content verdient. AI maakt traditioneel informatiebeheer daarom juist belangrijker, niet minder belangrijk. Contбаза-eigenaarschap, levenscyclusbeheer, versiebeheer, bewaring, archiveringsprocessen, autoritatieve bronnen, metadata en duidelijk gedefinieerde systemen van record worden fundamentele onderdelen van AI-architectuur.

AI-gereedheid begint bij de kwaliteit van content

Organisaties benaderen Copilot-gereedheid vaak als een project rond licenties, beveiliging, uitrol of training. Die onderdelen zijn belangrijk, maar de onderliggende kennisomgeving is minstens zo belangrijk. Als niemand weet welk document het huidige proces beschrijft, kan de AI die organisatorische onduidelijkheid niet zomaar oplossen.

Als drie afdelingen elk een andere versie van een beleid bijhouden, heeft de AI drie versies van de waarheid geërfd. Als verouderde documentatie onbeperkt doorzoekbaar blijft, blijft het potentieel bronmateriaal voor antwoorden. Enterprise AI legt daarmee kennismanagementschuld bloot die organisaties tot nu toe konden negeren.

Waarom vertrouwen bepaalt of Copilot wordt gebruikt

De technische gevolgen worden snel zakelijke gevolgen. Gebruikers accepteren misschien af en toe een inconsistentie wanneer AI wordt gebruikt om een e-mail op te stellen of een vergadering samen te vatten. Ze worden veel minder tolerant wanneer AI wordt verwacht om beleid uit te leggen, klantbeslissingen te ondersteunen, projectstatus te interpreteren, compliance-informatie te geven of operationele processen te begeleiden.

Zodra gebruikers inconsistente antwoorden op belangrijke vragen krijgen, keren ze vaak terug naar vertrouwde menselijke experts en bestaande handmatige processen. Dit is een belangrijke reden waarom het gebruik van Copilot kan afvlakken, zelfs na een schijnbaar geslaagde uitrol. Vertrouwen wordt daarom een architectuurvereiste en niet alleen een adoptiemaatstaf.

Conclusie

Kortom: Retrieval-Augmented Generation heeft enterprise AI een krachtige manier gegeven om externe documenten te gebruiken, maar door de stateless querylussen en de beperkingen van chunking schiet het vaak tekort als echt organisatiegeheugen. Zonder persistente kennisverwerking blijven systemen zoals Copilot worstelen met consistentie, diepe contextuele verbanden en vertrouwen binnen de organisatie. De overstap van losse documentrepositories naar een gestructureerde, verwerkte kennislaag, zoals de opkomende LLM Wiki-aanpak, is de sleutel om het gat tussen indrukwekkende demo's en betrouwbare zakelijke tools te dichten. Wil je dit onderwerp verder verkennen en onze volledige analyse over het herstellen van het geheugen van enterprise AI horen? Luister dan naar de volledige aflevering op Your Copilot Has No Memory — Why RAG Fails and LLM Wiki Fixes It.