Thema: Hoe geef je AI de juiste informatie?

Iedereen die AI werkelijk inzet in een organisatie, stuit op hetzelfde punt. Het AI-model kan een overtuigend advies schrijven over fiscale regelingen. Het ontleedt juridische concepten en formuleert marktanalyses alsof het de materie beheerst. Maar vraag het naar de interne richtlijn die je kantoor vorige maand heeft bijgewerkt, en het antwoord klopt niet. Vraag het naar de wetswijziging van afgelopen kwartaal, en het geeft de oude versie. Open maandag een nieuw gesprek, en het is alles vergeten waar je vrijdag mee bezig was.

Het model heeft een enorme kennisbasis uit de training. Het mist de kennis die jouw organisatie uniek maakt, de actualiteit die elke week verschuift, en de context van wie je bent en waar je mee bezig bent. De oplossing zit niet in een krachtiger model. Die zit in hoe je het model voorziet van de juiste informatie op het juiste moment. Vier routes zijn daarvoor beschikbaar. Samen vormen ze de kennislaag rond het model.

Wat het model mist

Een AI-model ontstaat uit een trainingsfase. De AI-modellen waar organisaties vandaag mee werken zijn foundation models: brede basismodellen die tekst, beeld en meer verwerken. Tijdens die fase verwerkt zo’n model miljarden pagina’s tekst: boeken, artikelen, websites, codebases. Uit die tekst leert het patronen, feiten en verbanden. Op een gegeven moment stopt de training. Vanaf dat moment is de kennis bevroren.

Dat levert een model op met een breed inzetbare kennisbasis. Het kan vragen beantwoorden over geschiedenis, wetenschap, taal, recht, strategie. Maar drie typen informatie ontbreken structureel.

Actuele informatie

Alles wat is gepubliceerd, gewijzigd of ingetrokken na de training bestaat niet voor het model. De wetswijziging van vorige maand, het nieuwsbericht van gisteren, de koersbeweging van vanmorgen. Het model genereert een antwoord op basis van hoe de wereld eruitzag op het moment dat de training werd afgesloten. Zonder waarschuwing, zonder disclaimer.

Organisatiekennis

De interne richtlijnen van een accountantskantoor, de procesafspraken van een ziekenhuis, de klantdossiers van een adviesbureau. Die informatie staat niet op het publieke internet en is nooit in de training verwerkt. Het model kan er niet naar verwijzen, hoe relevant die kennis ook is voor het antwoord.

Persoonlijke context

Het model slaat niets op tussen sessies. Het registreert niet wie je bent, waar je eerder over hebt gesproken, welke toon je voorkeur heeft, of hoe ver het project gevorderd is. Elke sessie begint als een schone lei.

Het onzichtbare probleem

Het verraderlijke is dat je het niet ziet. Een antwoord op basis van verouderde informatie is net zo vlot geformuleerd als een antwoord op basis van actuele informatie. Een antwoord dat de organisatiecontext mist, klinkt even overtuigend als een antwoord dat die context wél heeft. Het model plaatst geen vlag bij wat het niet heeft.

Dat maakt dit een ander soort risico dan een systeem dat vastloopt of een foutmelding geeft. Een spreadsheet die niet opent, is zichtbaar kapot. Een AI-antwoord dat de verkeerde richtlijn citeert, ziet er precies zo uit als een antwoord dat de juiste citeert. De enige manier om het verschil te zien, is weten welke informatie het model wel en niet heeft ontvangen. Dat is de reden waarom de vier routes die hierna volgen niet alleen gaan over betere antwoorden, maar over controleerbare antwoorden.

Twee soorten kennis

Er zijn twee fundamenteel verschillende manieren waarop een AI-model aan kennis komt.

Trainingstijd versus contexttijd

De eerste is trainingstijd: de kennis die het model heeft opgebouwd tijdens de training. Die kennis zit verankerd in de parameters van het model zelf. Het model herkent dat water bij honderd graden kookt, niet omdat het een thermometer heeft gezien, maar omdat het dit patroon duizenden keren is tegengekomen in tekst. Trainingskennis is breed, stabiel en permanent. Maar bevroren op het moment dat de training stopt.

De tweede is contexttijd: de informatie die het model op het moment van de vraag meekrijgt. De prompt, de meegeleverde documenten, de instructies van het systeem, de gespreksgeschiedenis. Alles wat in het context window staat, is contextkennis. Die kennis is tijdelijk: het model verwerkt de informatie bij deze ene vraag en laat ze daarna los. Maar die kennis is wel actueel en specifiek.

Het verschil is vergelijkbaar met wat een adviseur tijdens de opleiding heeft geleerd en het dossier dat die adviseur voor de afspraak heeft doorgenomen. De opleiding levert het fundament: brede kennis, denkpatronen, vakjargon. Het dossier maakt het advies relevant voor deze klant, op dit moment, met deze vraag. Een adviseur die alleen op de opleiding vaart, geeft generiek advies. Een adviseur die ook het dossier heeft gelezen, geeft advies dat past bij de situatie. Een goed AI-systeem heeft beide nodig.

Die tweede route is waar het voor organisaties interessant wordt: hoe voorzie je het model van de juiste informatie op het juiste moment? Vier routes zijn daarvoor beschikbaar. Elk lost een ander deel van het informatieprobleem op.

Vier routes naar de juiste informatie

RAG

RAG, Retrieval-Augmented Generation, koppelt een interne kennisbron aan het AI-model. Bij elke vraag doorzoekt het systeem die kennisbron, haalt de relevante passages op en geeft ze mee aan het model als context. Het model genereert vervolgens een antwoord op basis van de vraag én de opgehaalde informatie.

RAG lost het organisatiekennisprobleem op. De interne richtlijnen en procesbeschrijvingen die het model niet heeft uit de training, worden beschikbaar gemaakt op het moment dat iemand ernaar vraagt. Het model verandert niet. Wat verandert, is de informatie die het ontvangt.

De kracht zit in de combinatie van automatisering en specificiteit: het systeem zoekt zelf de juiste passages en geeft alleen de relevante informatie mee. Dat schaalt op een manier die handmatig kopiëren niet kan. Maar RAG is een ontwerpkeuze die onderhoud vraagt. Welke bronnen je koppelt, hoe je ze bijhoudt en of je de resultaten evalueert, bepaalt of het systeem betrouwbare of misleidende antwoorden oplevert.

→ Lees meer: RAG: organisatiekennis koppelen (5.2)

Search en browse

Web search geeft het model de mogelijkheid om actuele informatie op te halen van het internet op het moment van de vraag. Het model genereert zoekopdrachten, leest de resultaten en verwerkt ze tot een antwoord met bronvermeldingen.

Search lost het actualiteitsprobleem op. Recente wetgeving, lopende marktontwikkelingen en andere informatie die na de training is verschenen, worden bereikbaar. Browse gaat een stap verder: het model opent volledige webpagina’s en leest ze door. Deep research combineert tientallen zoekopdrachten tot een gestructureerd rapport.

De belofte is aantrekkelijk: het model zoekt, leest en vat samen. Maar search is een keten van beslissingen, van zoekopdracht tot bronkwaliteit, en elke schakel kan falen. Bronvermeldingen zijn er om het antwoord te controleren. Wie ze negeert, neemt een risico.

→ Lees meer: Search en browse: actuele informatie ophalen (5.3)

Context windows

Het context window is de totale hoeveelheid informatie die een model tegelijk kan verwerken. Hoe groter het venster, hoe meer documenten, instructies en gespreksgeschiedenis het model in één keer kan meenemen.

De schaal van moderne context windows is indrukwekkend. Gangbare modellen verwerken honderdduizenden tot miljoenen tokens tegelijk. Dat is het equivalent van meerdere boeken. Die schaal maakt toepassingen mogelijk die voorheen ondenkbaar waren: een heel dossier analyseren in één opdracht, meerdere bronnen tegelijk vergelijken, een uitgebreid gesprek voeren zonder dat eerdere beurten verloren gaan.

Maar hier zit het inzicht dat veel mensen verrast. Een groter context window is niet automatisch beter. Hoe meer informatie het model tegelijk verwerkt, hoe dunner de aandacht wordt verdeeld. Informatie in het midden van een lange context krijgt minder gewicht. De kwaliteit daalt naarmate het venster voller raakt. De kwaliteit van het antwoord hangt af van hoe goed je selecteert wat je meegeeft.

→ Lees meer: Context windows: hoeveel informatie past er? (5.4)

Geheugen

Een AI-model slaat niets op tussen sessies. De toon die vorige week was afgestemd, het project dat stap voor stap was opgebouwd, de voorkeuren die eerder zijn besproken: bij het volgende gesprek is alles weg.

Geheugen is geen eigenschap van het model. Het is een functie van de applicatie eromheen. Het platform observeert gesprekken, slaat kernfeiten op en voegt die bij een nieuw gesprek toe aan de context. Het model wordt herinnerd. Het onthoudt niet zelf. Wat de applicatie opslaat, is een samenvatting. De nuances van hoe een redenering tot stand kwam, de specifieke formulering die na drie iteraties precies goed was, overleven die samenvatting doorgaans niet.

Voor individuele gebruikers bouwt dat continuïteit op over sessies heen. Voor organisaties speelt een grotere vraag: hoe zorg je dat een AI-systeem de context heeft die een heel team nodig heeft? Dat is organisatiegeheugen, een ontwerpvraagstuk dat raakt aan privacy, eigenaarschap en de manier waarop een organisatie met informatie omgaat.

→ Lees meer: Geheugen: AI dat onthoudt (5.5)

Welke route past

Vier routes, vier problemen. De keuze hangt af van welke informatie het model mist.

Mist het model interne, organisatiespecifieke kennis die regelmatig verandert? Dan is RAG de route. Mist het actuele, publiek beschikbare informatie? Dan is search de eerste stap. Moet het grote hoeveelheden informatie tegelijk verwerken? Dan is het context window de bepalende factor. Mist het de continuïteit over sessies heen? Dan lost geheugen dat op.

In de praktijk zijn de routes complementair. Een AI-systeem dat interne beleidsdocumenten koppelt via RAG, actuele marktinformatie ophaalt via search, die informatie gericht in het context window plaatst en de gebruikersvoorkeuren bewaart via geheugen: dat is geen theoretisch construct. Dat is hoe de krachtigste AI-systemen werken.

Wij kiezen er bewust voor om deze vier routes als gescheiden concepten te behandelen. In de praktijk worden ze vaak in één adem genoemd of door elkaar gehaald. Maar elke route lost een ander probleem op, stelt andere eisen aan de organisatie en heeft andere kwaliteitsfactoren. Wie dat onderscheid scherp heeft, stelt betere vragen aan een technisch team en neemt betere beslissingen over de inrichting van AI-systemen.

Voorbeelden

Hier zit een patroon dat steeds terugkomt: zodra een organisatie AI inzet voor werk dat leunt op eigen kennis, actuele informatie of lopende projecten, ontstaat de behoefte aan meerdere routes tegelijk.

Neem een middelgroot accountantskantoor met vijftig medewerkers. Het kantoor zet een AI-systeem in om medewerkers te ondersteunen bij advieswerk.

Een junior accountant stelt het systeem een vraag over de fiscale behandeling van een specifieke constructie. Het antwoord moet verwijzen naar de interne richtlijn die het kantoor twee maanden geleden heeft bijgewerkt. Die richtlijn staat nergens op het publieke internet. Het systeem doorzoekt via RAG de interne kennisbron, haalt de relevante passages op en genereert een antwoord dat verwijst naar de juiste richtlijn. Zonder die koppeling had het model geantwoord op basis van algemene kennis. Correct in grote lijnen, maar zonder de specifieke uitzonderingsregel die het kantoor hanteert.

Dezelfde accountant wil controleren of er recente wijzigingen zijn in de betreffende belastingwetgeving. Het systeem activeert web search, doorzoekt de publicaties van de Belastingdienst en vindt dat de regeling drie maanden geleden is herzien. Het levert de samenvatting op met bronvermeldingen. De accountant controleert de bron, bevestigt dat de informatie klopt en past het advies aan. Zonder search had het model geantwoord op basis van de wetgeving ten tijde van de training, mogelijk een verouderde versie.

De partner van het kantoor wil vervolgens een sectoranalyse laten maken. Die analyse vereist de jaarrekening van de klant, drie brancherapporten en de notulen van het laatste overleg. Samen meer dan honderdduizend tokens. Het context window maakt het mogelijk om al die documenten tegelijk te verwerken. Maar het systeem laadt niet alles in. Het selecteert de relevante secties en plaatst die gericht in de context. Dat levert een scherper resultaat op dan het hele archief in één keer meesturen.

En maandag opent de accountant een nieuw gesprek. Het systeem herkent haar voorkeur voor korte, gestructureerde antwoorden. Het heeft opgeslagen op welk dossier ze werkt en past de toon aan. Het geheugen bewaart de context uit eerdere sessies. Ze begint waar ze vrijdag is gebleven, zonder iets te hoeven herhalen.

Vier informatiebehoeften. Vier routes. Eén systeem dat ze combineert.

Veelgestelde vragen

Wat is het verschil tussen kennis in het model en kennis die je meegeeft?

Een AI-model heeft twee bronnen van kennis. De eerste is trainingskennis: alles wat het model heeft geleerd uit miljarden pagina’s tekst tijdens de trainingsfase. Die kennis is breed en stabiel, maar bevroren op het moment dat de training stopt. De tweede is contextkennis: de informatie die het model op het moment van de vraag meekrijgt via de prompt, meegeleverde documenten en gespreksgeschiedenis. Contextkennis is tijdelijk maar actueel. Het verschil is vergelijkbaar met wat een specialist uit de opleiding meeneemt en het dossier dat voor een specifieke afspraak is klaargezet. De opleiding is het fundament. Het dossier maakt het advies relevant voor deze situatie. Zonder contextkennis geeft het model generieke antwoorden die soms verouderd of incompleet zijn. Met de juiste contextkennis worden die antwoorden specifiek, actueel en bruikbaar voor de eigen organisatie.

Moet ik al deze oplossingen tegelijk gebruiken?

Niet per se. Welke route je nodig hebt, hangt af van welk informatieprobleem je oplost. Een organisatie die het AI-systeem alleen inzet voor vragen over interne richtlijnen, heeft RAG nodig maar misschien geen web search. Een consultant die het model gebruikt voor actueel marktonderzoek, heeft search nodig maar misschien geen RAG. Geheugen wordt relevant zodra iemand structureel met het systeem werkt en de opstarttijd bij elk gesprek merkbaar wordt. De routes zijn modulair: je kiest wat je nodig hebt en combineert waar dat waarde toevoegt. De krachtigste AI-systemen combineren meerdere routes, maar de meeste organisaties beginnen met de route die het grootste verschil maakt voor hun dagelijkse werk. Dat levert het snelst zichtbaar resultaat op en geeft inzicht in welke volgende stap zinvol is.

Maakt een groot context window de andere routes overbodig?

Die gedachte klinkt logisch: als het venster groot genoeg is, stop je alles erin en het model selecteert zelf wat relevant is. In de praktijk werkt dat niet. Hoe meer informatie het model tegelijk verwerkt, hoe dunner de aandacht wordt verdeeld. Relevante details raken ondergesneeuwd. Informatie in het midden van een lange context krijgt minder gewicht dan informatie aan het begin of einde. Onderzoekers hebben dat patroon bij elk getest model gevonden, zonder uitzondering. Een groter context window maakt het mogelijk om meer informatie te verwerken, maar het vervangt niet de noodzaak om te selecteren wat het model ontvangt. RAG selecteert relevante passages uit een grote kennisbron. Search lost een ander probleem op: actuele informatie die niet in de kennisbron staat. Geheugen biedt continuïteit over sessies heen, een functie die het context window per definitie niet levert, want dat is leeg bij elk nieuw gesprek.

Waar begin ik als organisatie?

Begin bij de vraag: welke informatie mist het model het vaakst bij de taken waarvoor je het inzet? Als medewerkers steeds opnieuw dezelfde interne documenten kopiëren naar het chatvenster, is dat een signaal voor RAG. Als antwoorden regelmatig verouderde informatie bevatten, is search de eerste stap. Als medewerkers bij elk nieuw gesprek dezelfde context opnieuw uitleggen, helpt geheugen. De fout die de meeste organisaties maken, is alles tegelijk willen implementeren zonder helder te hebben welk probleem het grootst is. Begin bij de route die het duidelijkste knelpunt oplost. Test het met een klein team, evalueer de resultaten en bouw van daaruit verder. De volgorde wordt bepaald door het dagelijks werk, niet door de technologie.

Hoe weet ik of het model zijn trainingskennis gebruikt of de informatie die ik heb meegegeven?

Dat is lastig te zien aan het antwoord zelf. Het model maakt geen onderscheid tussen wat het uit de training kent en wat het uit de context heeft ontvangen. Het combineert beide bronnen tot één antwoord, zonder markering van waar elk onderdeel vandaan komt. In de praktijk zijn er twee signalen. Het eerste is bronvermelding: als het systeem bronnen citeert (bij search of RAG), kun je controleren of het antwoord daarop is gebaseerd. Het tweede is specificiteit: een antwoord dat verwijst naar interne termen, recente datums of organisatiespecifieke details, leunt waarschijnlijk op contextkennis. Een antwoord dat algemeen en tijdloos klinkt, leunt waarschijnlijk op trainingskennis. Zekerheid geeft geen van beide signalen. Wie het verschil moet weten, moet het antwoord controleren tegen de bron. Dat is geen beperking van het model, het is een eigenschap van hoe het werkt.

Verder lezen

Wie wil begrijpen hoe het Aiscendo Ringenmodel de opbouw van AI-systemen zichtbaar maakt en hoe de kennislaag daarin past, leest verder bij Van model naar systeem (cluster 3).

Wie wil weten hoe je de hele informatieomgeving rond een AI-model ontwerpt, als kader voor de vier routes die hier zijn geïntroduceerd, vindt dat bij Context engineering: van goede prompt naar slim systeem (cluster 4.4).

Wie wil begrijpen hoe RAG, search, context windows en geheugen in de praktijk werken, vindt de verdieping in de vier clusters van deze pillar: RAG: organisatiekennis koppelen (5.2), Search en browse: actuele informatie ophalen (5.3), Context windows: hoeveel informatie past er? (5.4) en Geheugen: AI dat onthoudt (5.5).

Een medewerker typt een vraag in het AI-systeem van het kantoor: wat is de huidige procedure voor btw-verlegging bij dienstverlening buiten de EU? Het antwoord verschijnt binnen seconden. Helder, gestructureerd, overtuigend. En fout. Het model heeft de vraag beantwoord op basis van algemene kennis uit de training. De interne richtlijn van het kantoor, drie maanden geleden bijgewerkt met een specifieke uitzondering, heeft het nooit verwerkt.

Dit is het punt waarop veel organisaties vastlopen. Het AI-model (ook wel foundation model genoemd) kan helder formuleren, complexe vragen ontleden en overtuigende antwoorden genereren. Maar het heeft geen toegang tot de kennis die jouw organisatie uniek maakt: de richtlijnen, de procesbeschrijvingen, de klantafspraken, het beleid. RAG, Retrieval-Augmented Generation, pakt precies dat probleem aan. Het koppelt een kennisbron aan het model, zodat bij elke vraag relevante informatie kan worden opgehaald. Niet door het model te veranderen, maar door het te voorzien van de juiste context op het juiste moment.

De blinde vlek

Elk AI-model heeft een brede kennisbasis. De training omvat miljarden pagina’s tekst van het publieke internet: boeken, artikelen, websites, codebases. Dat maakt het model breed inzetbaar voor algemene vragen. Maar de kennis die een organisatie uniek maakt, staat niet op het internet. Interne richtlijnen, procesafspraken, klantdossiers, beleidsdocumenten. Die informatie bestaat alleen binnen de muren van de organisatie. Het model heeft er geen toegang toe en kan er niet naar verwijzen.

Neem een middelgroot accountantskantoor. Duizenden adviesdocumenten, procesbeschrijvingen en interne richtlijnen die nergens in de training van het model voorkomen. Verspreid over SharePoint, een kennisbank en lokale mappen. Elke keer dat een medewerker een vakinhoudelijke vraag stelt, mist het model de informatie die het antwoord zou moeten sturen.

Handmatig kopiëren

De eerste reflex is het document kopiëren naar het chatvenster. Plak de richtlijn erbij en het model kan ermee werken. Dat werkt bij twee pagina’s. Niet bij tweehonderd. En al helemaal niet als twintig medewerkers dagelijks vragen stellen over tientallen onderwerpen, verspreid over honderden documenten. Handmatig kopiëren schaalt niet.

Fine-tuning

De tweede gedachte is het model opnieuw trainen met de eigen data via fine-tuning. Fine-tuning past het model zelf aan. Het kan domeinspecifieke kennis, vakjargon en redeneerpatronen aanleren. Een AI-model dat via fine-tuning is getraind op medische literatuur, wordt beter in medisch redeneren. Dat werkt voor kennis die stabiel is: vakterminologie, domeinexpertise, een vaste schrijfstijl.

Maar organisatiekennis is per definitie dynamisch. Richtlijnen worden bijgewerkt, procedures wijzigen, klantafspraken veranderen. Een intern beleidsdocument dat volgende maand wordt aangepast, vereist bij fine-tuning een nieuwe trainingsronde. Elke ronde vraagt gespecialiseerde engineers, rekenkracht en tijd. Voor de grote technologiebedrijven die hun eigen modellen trainen, is dat haalbaar. Voor de meeste organisaties is het dat niet. En zelfs als het zou kunnen, blijft het probleem: tegen de tijd dat de trainingsronde is afgerond, kan de informatie alweer zijn veranderd.

De derde weg

In het Aiscendo Ringenmodel, het denkraam dat wij gebruiken om de opbouw van AI-systemen te beschrijven, is dit Ring 2: Weten. De ring die het model toegang geeft tot kennis die het uit zichzelf niet heeft.

RAG kiest een andere route. In plaats van het model te vullen met kennis of handmatig documenten mee te geven, automatiseert RAG het ophalen van relevante informatie uit de eigen bronnen van de organisatie. Bij elke vraag doorzoekt het systeem een externe kennisbron, haalt de relevante passages op en geeft die mee aan het model als context. Het model genereert vervolgens een antwoord op basis van de vraag én de opgehaalde informatie. Retrieval-Augmented Generation: ophalen, verrijken, genereren. De naam beschrijft exact wat er gebeurt.

Het model zelf verandert niet. Wat verandert, is de informatie die het ontvangt. Vergelijk het met een adviseur die bij elke klantvraag eerst het archief raadpleegt voordat die antwoord geeft. De adviseur hoeft niet alles uit het hoofd te kennen. Die hoeft alleen te weten waar de relevante informatie staat. RAG doet hetzelfde voor een AI-model: het koppelt een zoeksysteem dat bij elke vraag de juiste documenten ophaalt en meelevert.

Terug naar het accountantskantoor. Een medewerker stelt een vraag, het systeem doorzoekt de interne richtlijnen, haalt de relevante passages op en het model genereert een antwoord op basis van die passages. De medewerker krijgt een antwoord dat verwijst naar de juiste interne bronnen, zonder dat iemand handmatig heeft gezocht. Wie wil begrijpen hoe dat ophaalproces technisch werkt, van vraag tot antwoord, leest verder bij Wat is RAG en hoe werkt het? (5.2a).

Wanneer RAG het verschil maakt

RAG is een oplossing voor een specifiek type probleem. Wie herkent welk type kennis het betreft, kan de juiste oplossing kiezen.

RAG is op zijn sterkst wanneer de kennis intern is en regelmatig verandert. Interne richtlijnen, procesbeschrijvingen, HR-beleid, productdocumentatie, klantafspraken: informatie die niet publiek beschikbaar is en die voortdurend wordt bijgewerkt. Dit type kennis leent zich niet voor fine-tuning, want de informatie is te veranderlijk. Het leent zich niet voor handmatig kopiëren, want het volume is te groot. RAG lost precies dat probleem op: het houdt de kennisbron doorzoekbaar en actueel, zonder het model aan te passen.

Maar niet elk informatieprobleem is een RAG-probleem. De keuze hangt af van het type kennis.

Search

Wanneer de informatie juist extern en actueel moet zijn, denk aan nieuwsberichten, marktdata of wetenschappelijke publicaties, is search de betere route. Search haalt informatie op van het internet op het moment van de vraag. RAG haalt informatie op uit een eigen, beheerde kennisbron. Het verschil is de bron: search zoekt buiten de organisatie, RAG zoekt binnen.

→ Lees meer: Search en browse: actuele informatie ophalen (5.3).

Grote context windows

Bij een kleine, overzichtelijke set documenten die zelden verandert, kan een groot context window volstaan. Laad de documenten in het gesprek en het model verwerkt ze direct. Maar die aanpak kent grenzen. Naarmate de hoeveelheid informatie groeit, verwatert de aandacht van het model. Onderzoekers noemen dat verschijnsel context rot: de nauwkeurigheid daalt als er te veel in het context window zit, omdat relevante details ondergesneeuwd raken. Zelfs met context windows van honderdduizenden tokens blijft selectie noodzakelijk bij grote kennisbronnen. RAG is die selectie.

Fine-tuning

Fine-tuning is het juiste gereedschap voor stabiele domeinkennis die zelden verandert. Voor actuele, organisatiespecifieke kennis is RAG de betere keuze. De twee vullen elkaar aan: fine-tuning maakt het model deskundiger in een domein, RAG voorziet het van de specifieke informatie die het per vraag nodig heeft.

Wat RAG van een organisatie vraagt

Hier zit een misvatting die hardnekkig is. RAG klinkt als iets dat je aanschaft en installeert. Een product dat je aanzet, een schakelaar die je omzet. Dat beeld klopt niet, en het leidt tot teleurstelling bij organisaties die verwachten dat het systeem na installatie vanzelf goede antwoorden oplevert.

RAG is een ontwerpkeuze. Het is de beslissing om een kennisbron te koppelen aan een AI-model, met alles wat daarbij hoort. Wij positioneren RAG bewust zo: als een architectuurkeuze die onderhoud en eigenaarschap vraagt. De technologie maakt het mogelijk. De organisatie bepaalt of het werkt.

Neem het accountantskantoor. De beslissing om RAG in te zetten is de eerste stap. Daarna volgen de vragen die het verschil maken tussen een systeem dat betrouwbare antwoorden levert en een systeem dat overtuigende onzin produceert.

Drie organisatievragen

De eerste: welke kennis koppel je? Niet alle documenten zijn geschikt. Verouderde versies, concepten, interne memo’s zonder vaste status. Meer bronnen koppelen voelt als meer houvast, maar het tegenovergestelde is waar. Een kennisbron met vijfhonderd goed onderhouden documenten presteert beter dan een kennisbron met vijfduizend ongesorteerde bestanden. De keuze wat je opneemt is minstens zo belangrijk als de technologie die het ophalen mogelijk maakt.

De tweede: wie beheert de bronnen? RAG levert actuele antwoorden alleen als de bronnen actueel zijn. Dat vraagt om een eigenaar: iemand die verantwoordelijk is voor het toevoegen, bijwerken en verwijderen van documenten in de kennisbron. Zonder dat eigenaarschap verwatert de kwaliteit geleidelijk, zonder dat iemand het merkt. Tot een medewerker een antwoord krijgt dat gebaseerd is op een richtlijn van twee jaar geleden.

De derde: hoe evalueer je het resultaat? Een RAG-systeem genereert antwoorden die er professioneel uitzien. Dat zegt niets over de juistheid. Systematische evaluatie, met echte vragen, verwachte antwoorden en periodieke controles, is een voorwaarde. Wie wil weten welke factoren bepalen of een RAG-systeem daadwerkelijk goede resultaten oplevert, leest verder bij Wat bepaalt of RAG werkt? (5.2b).

Een kantoor dat deze drie vragen serieus neemt, bereikt het punt waarop medewerkers sneller en consistenter antwoorden krijgen dan via handmatig zoeken. Niet omdat het model krachtiger is geworden. Omdat het de juiste informatie ontvangt.

Voorbeelden

Hoe kan RAG er in de praktijk uitzien? Drie scenario’s die het principe concreet maken.

Medische kliniek

Neem een middelgrote huisartsenpraktijk met vijftien artsen. De protocollen, medicatierichtlijnen en verwijsafspraken staan digitaal, verspreid over een kennisbank en gedeelde mappen. Een assistent typt een vraag in het AI-systeem: welke verwijsprocedure geldt voor een patiënt met aanhoudende schouderklachten? Het systeem doorzoekt de kennisbron, haalt het relevante protocol op en genereert een antwoord met de juiste specialist, de juiste wachttijdindicatie en de administratieve stappen. De assistent had dit handmatig kunnen opzoeken. Het verschil: in plaats van tien minuten bladeren door mappen duurt het vijftien seconden. Vermenigvuldig dat met honderd vragen per week en het effect wordt zichtbaar.

B2B-dienstverlener

Neem een adviesbureau met tachtig medewerkers. Honderden klantdossiers, brancheanalyses en interne methodedocumenten. Een consultant bereidt een pitch voor en vraagt het AI-systeem: welke projecten hebben we eerder gedaan in de logistieke sector en wat waren de resultaten? Het systeem haalt relevante casebeschrijvingen en resultaatcijfers op uit de interne kennisbank. De consultant krijgt een overzicht dat anders een middag zoekwerk had gekost. Het resultaat is niet alleen sneller. Het is vollediger, want het systeem doorzoekt alle dossiers, niet alleen de dossiers die de consultant toevallig zelf heeft bijgehouden.

Zelfstandig professional

Neem een zelfstandige belastingadviseur die een eigen kennisbron heeft opgebouwd: tientallen adviesdocumenten, klantnotities en samenvattingen van regelgeving. Bij een complexe klantvraag over de fiscale behandeling van een specifieke constructie doorzoekt het AI-systeem haar archief en haalt de relevante passages op. Het antwoord combineert informatie uit drie documenten die ze zelf heeft geschreven. Zonder RAG had ze die documenten handmatig moeten doorlezen en vergelijken. Met RAG functioneert haar archief als een doorzoekbare kennisassistent die permanent beschikbaar is.

Veelgestelde vragen

Wat is het verschil tussen RAG en fine-tuning?

Fine-tuning en RAG versterken een AI-model op verschillende manieren. Fine-tuning past het model zelf aan: het kan domeinspecifieke kennis, vakjargon en een bepaalde schrijfstijl aanleren. Een model dat via fine-tuning is getraind op juridische teksten, herkent juridische concepten en formuleert als een jurist. Dat werkt voor kennis en vaardigheden die stabiel zijn. RAG laat het model intact en verandert alleen de informatie die het model ontvangt. Bij elke vraag haalt het systeem relevante passages op uit een externe kennisbron en geeft die mee als context. Dat werkt voor kennis die verandert: de huidige richtlijn, het actuele beleid, de laatste versie van het protocol. Een richtlijn die volgende maand wordt aangepast, wil je niet in het model trainen. Die wil je ophalen op het moment dat iemand ernaar vraagt. In de praktijk vullen RAG en fine-tuning elkaar aan. Fine-tuning maakt het model deskundiger in een domein. RAG voorziet het van de actuele, organisatiespecifieke informatie die het nodig heeft om bruikbare antwoorden te genereren.

Maakt een groot context window RAG niet overbodig?

Die gedachte klinkt logisch: als het venster groot genoeg is om alle documenten in één keer te verwerken, waarom dan nog selectief ophalen? Twee redenen. De eerste: een groter venster lost het selectieprobleem niet op. Hoe meer informatie het model tegelijk verwerkt, hoe dunner de aandacht wordt verdeeld. Relevante details raken ondergesneeuwd door irrelevante informatie. Onderzoekers noemen dat effect context rot. RAG lost dat op door alleen de passages op te halen die voor deze specifieke vraag relevant zijn. De tweede: organisatiekennis verandert voortdurend. Richtlijnen worden bijgewerkt, procedures wijzigen, regelgeving evolueert. Je wilt dat het antwoord de huidige versie van het document weerspiegelt, niet een kopie die ooit in het venster is geladen. RAG koppelt de antwoorden aan een levende kennisbron die wordt onderhouden. Dat probleem verdwijnt niet met grotere vensters.

Is RAG een product dat ik kan kopen?

Er bestaan platforms en tools die RAG-functionaliteit aanbieden, maar de implementatie is in de praktijk een ontwerpkeuze. Welke bronnen koppel je? Hoe worden documenten opgeknipt in doorzoekbare passages? Wie houdt de bronnen actueel? Hoe evalueer je of de antwoorden kloppen? Die vragen zijn organisatorisch. Een RAG-implementatie die goed is ontworpen, levert betrouwbare antwoorden op basis van actuele bronnen. Een implementatie die wordt behandeld als een product dat je installeert en vergeet, levert binnen enkele maanden antwoorden op basis van verouderde of tegenstrijdige informatie. Het verschil zit in het onderhoud, de evaluatie en het eigenaarschap dat eromheen is georganiseerd.

Heb ik technische kennis nodig om over RAG te beslissen?

Voor de beslissing niet. Je hebt inhoudelijke kennis nodig: welke informatie is waardevol genoeg om te ontsluiten, welke bronnen zijn betrouwbaar, hoe vaak veranderen ze? De strategische vragen die bepalen of RAG zinvol is voor een organisatie zijn dezelfde vragen die een directeur of MT-lid stelt over elk informatievraagstuk. Wat wel technische expertise vraagt, is de implementatie: het opzetten van de kennisbron, het configureren van het ophaalproces, het testen en verbeteren van de resultaten. De opdrachtgever hoeft dat niet zelf te kunnen. De opdrachtgever moet de juiste vragen kunnen stellen. Na het lezen van deze pagina en de twee verdiepingspagina’s in dit cluster zijn die vragen helder.

Wat verandert RAG aan het dagelijks werk?

Het zichtbaarste effect is dat medewerkers antwoorden krijgen op basis van de eigen bronnen van de organisatie, zonder die bronnen zelf te hoeven opzoeken. Dat klinkt als een efficiëntiewinst, en dat is het ook. Maar er verandert meer. Kennis die voorheen in de hoofden van ervaren medewerkers zat of verspreid was over mappen en systemen, wordt doorzoekbaar en beschikbaar voor iedereen. Een nieuwe medewerker kan binnen de eerste week vragen stellen die voorheen maanden inwerktijd vergden. Een consultant die een pitch voorbereidt, heeft toegang tot alle eerdere projecten, niet alleen de projecten die ze persoonlijk heeft bijgehouden. Het organisatiegeheugen wordt gedeeld. Dat verandert niet alleen hoe snel mensen werken, maar ook hoe gelijkmatig de kwaliteit is over het team heen.

Verder lezen

Wie wil begrijpen hoe het RAG-proces technisch werkt, hoe een vraag wordt omgezet naar een zoekrepresentatie, hoe de kennisbron wordt doorzocht en hoe het model op basis daarvan een antwoord genereert, leest verder bij Wat is RAG en hoe werkt het? (5.2a).

Wie wil weten welke factoren bepalen of een RAG-systeem daadwerkelijk goede resultaten oplevert en welke fouten het vaakst worden gemaakt, leest verder bij Wat bepaalt of RAG werkt? (5.2b).

Wie wil zien hoe RAG past in het bredere kader van contextbeheer en het ontwerpen van de informatieomgeving rond een AI-model, vindt dat bij Context engineering: van goede prompt naar slim systeem (4.4).

Een accountant vraagt een AI-model naar de actuele btw-regeling voor grensoverschrijdende diensten. Het antwoord is helder, gestructureerd, en fout. De regeling die het model beschrijft, is vorig jaar vervangen. Het model mist die informatie.

Dat is geen bug. Dat is hoe elk AI-model werkt. Alles wat het ooit heeft geleerd, stamt uit tekst die op een bepaald moment is verzameld en bevroren. Nieuwe wetgeving, recente publicaties, lopende ontwikkelingen: voor het model bestaan ze niet.

De oplossing klinkt logisch: geef het model de mogelijkheid om te zoeken. Dat is precies wat web search doet. Maar hoe dat zoeken werkt, en waarom het fundamenteel anders is dan zelf googelen, bepaalt hoeveel je van het resultaat kunt vertrouwen.

Wat het model mist

Een AI-model ontstaat uit een trainingsfase. Tijdens die fase verwerkt het model enorme hoeveelheden tekst, en uit die tekst leert het patronen, feiten en verbanden. Op een gegeven moment stopt de training en is het model klaar. Vanaf dat moment is de kennis van het model bevroren. Alles wat daarna is gepubliceerd, gewijzigd of ingetrokken, bestaat niet voor het model.

Voor vragen over stabiele kennis is dat geen probleem. Wiskundige principes veranderen niet. Historische feiten verschuiven niet. Taalregels blijven grotendeels gelijk. Maar voor vragen over de actualiteit mist het model elke informatie die na de training is verschenen. Recente regelgeving, lopende nieuwsontwikkelingen, de huidige marktpositie van een concurrent: het model genereert een antwoord op basis van hoe de wereld eruitzag op het moment dat de training werd afgesloten.

Het verraderlijke is dat het antwoord er niet anders uitziet. Een verouderd antwoord is net zo vlot geformuleerd als een actueel antwoord. Het model geeft geen waarschuwing. Het plaatst geen disclaimer. Het levert gewoon een antwoord dat klinkt alsof het klopt. Dat is het actualiteitsprobleem. En het is precies het probleem dat web search oplost.

Net als RAG is web search onderdeel van Ring 2 (Weten) in het Aiscendo Ringenmodel, de stapsgewijze opbouw van AI-model naar compleet AI-systeem. Ring 2 voorziet het model van kennis die het uit zichzelf niet heeft. Waar RAG interne organisatiekennis koppelt, haalt search actuele informatie van het web.

Zoeken zonder te googelen

Web search voor AI-modellen werkt anders dan een Google-zoekopdracht. Als je zelf iets zoekt, typ je een zoekopdracht, krijg je een aantal links, scan je titels, kies je de meest relevante pagina, lees je die door, en trek je zelf een conclusie. Het model doet iets anders.

Wanneer een AI-model search inzet, genereert het zelf één of meerdere zoekopdrachten op basis van de gestelde vraag. Het stuurt die naar een zoekmachine, ontvangt de resultaten, leest de relevante inhoud door, en verwerkt alles tot een samenhangend antwoord. De gebruiker ziet geen lijst met zoekresultaten. Die ziet het eindantwoord, voorzien van bronvermeldingen.

Het is alsof je een onderzoeksassistent naar de bibliotheek stuurt. De assistent bepaalt welke boeken worden gepakt, welke passages worden gelezen, en hoe de samenvatting eruitziet. Het resultaat kan uitstekend zijn. Maar welke boeken zijn overgeslagen, welke passages zijn genegeerd, welke bron als betrouwbaar is aangemerkt: dat ziet de opdrachtgever niet.

Grounding

Grounding, in het Nederlands verankering, is het principe dat modeloutput wordt gekoppeld aan verifieerbare bronnen. Een model dat search gebruikt met grounding voegt bij elke bewering een bronvermelding toe. Die bronvermeldingen zijn geen decoratie. Ze maken het mogelijk om het antwoord te controleren. Niet omdat het model altijd gelijk heeft, maar juist omdat het dat niet altijd heeft.

De grote AI-platforms bieden search met grounding als standaardfunctie. Het model zoekt, verwerkt de resultaten, en levert het antwoord op met verwijzingen naar de originele bronnen. Dat vermindert het risico op hallucinaties, onjuiste informatie die het model presenteert als feit, aanzienlijk. Maar het elimineert dat risico niet. Want de kwaliteit van het antwoord hangt af van een reeks beslissingen die het model zelf maakt, en elke beslissing in die reeks kan misgaan.

De zoekfunctie

Voordat de vier schakels in beeld komen, is er een fundament dat de reikwijdte van elk zoekresultaat bepaalt: de zoekmachine die het AI-model onder de motorkap gebruikt. En dat is niet vanzelfsprekend Google.

Elk AI-platform is gekoppeld aan een eigen zoekprovider. Het ene model doorzoekt een andere index dan het andere. Dat betekent dat dezelfde vraag aan twee verschillende AI-modellen tot verschillende bronnen kan leiden, omdat de onderliggende zoekmachines elk hun eigen index van het web onderhouden. De zoekproviders zijn niet altijd openbaar gedocumenteerd, en de samenwerkingen verschuiven.

Dit is de eerste en meest fundamentele kwaliteitsfactor bij search. Het AI-model zoekt niet zomaar het hele internet af. Het doorzoekt de index die de gekoppelde zoekmachine heeft opgebouwd. Wat niet in die index zit, vindt het model niet, hoe goed de volgende stappen ook verlopen.

Vier schakels

Bovenop die basis bepalen vier vervolgstappen de kwaliteit van het antwoord. Ook die zijn grotendeels onzichtbaar voor de gebruiker.

1. De zoekopdracht. Het model vertaalt de vraag naar een zoekterm. Als die vertaling te breed is, komen er irrelevante resultaten terug. Te smal, en het model mist relevante informatie. De gebruiker ziet die zoekterm meestal niet.

2. De selectie. Uit de zoekresultaten selecteert het model welke bronnen het doorleest. Het maakt daarin niet altijd dezelfde keuze die een mens zou maken. Een hoog gerankte pagina hoeft niet de meest betrouwbare te zijn.

3. De interpretatie. Het model leest de bronnen en verwerkt ze tot een antwoord. Het kan informatie uit context halen, nuances missen, of geruchten niet onderscheiden van geverifieerde feiten. De makers van deze systemen benoemen dat zelf als een bekende beperking.

4. De bron zelf. Het model zoekt op het web van nu. Maar het web van nu bevat ook verouderde pagina’s, incorrecte informatie en onbetrouwbare bronnen.

Elke schakel afzonderlijk is doorgaans betrouwbaar. De keten als geheel, van zoekprovider tot bronkwaliteit, is niet waterdicht. Wie search-output behandelt als feit zonder de bronnen te controleren, neemt een risico. Wie de bronvermeldingen checkt, en dat kost vaak niet meer dan een paar klikken, heeft een krachtig hulpmiddel in handen.

Van zoeken naar onderzoeken

Web search beantwoordt een concrete vraag. Maar sommige vraagstukken vragen meer dan één zoekopdracht.

Een manager die een concurrentieanalyse nodig heeft, kan niet volstaan met één zoekresultaat. Dat vereist informatie over meerdere partijen, uit meerdere bronnen, geordend naar relevantie. Wat nodig is, gaat verder dan zoeken. Het vereist onderzoek: meerdere bronnen raadplegen, informatie vergelijken, en een gestructureerde analyse opleveren.

Browse

Browse gaat een stap verder dan search. In plaats van alleen zoekresultaten te verwerken, opent het AI-model volledige webpagina’s en leest ze door. Het kan navigeren naar verdiepende bronnen, tabellen en afbeeldingen interpreteren, en informatie uit meerdere pagina’s combineren tot een samenvatting. Het verschil met search is vergelijkbaar met het verschil tussen de samenvatting op de achterflap van een boek lezen en het boek zelf openslaan.

Deep research

De meest uitgebreide variant is deep research: een modus waarin het AI-model autonoom vijf tot dertig minuten het web doorzoekt. Het formuleert tientallen zoekopdrachten, leest honderden bronnen, en levert een gestructureerd rapport op met bronvermeldingen bij elke bewering. Het resultaat komt in de buurt van wat een onderzoeksanalist in een ochtend zou produceren.

Dat is indrukwekkend. Het is ook niet foutloos. Dezelfde foutbronnen die gelden voor een enkele zoekopdracht gelden ook voor deep research. Met een extra overweging: hoe meer bronnen het model verwerkt, hoe lastiger het wordt om elke bron individueel te controleren. De bronvermeldingen zijn er. Maar de investering in verificatie groeit mee met de omvang van het rapport.

Twee problemen, twee routes

Hier zit een onderscheid dat de moeite waard is om scherp te krijgen. Search en RAG lossen fundamenteel verschillende problemen op.

Search lost het actualiteitsprobleem op: het model mist recente, publiek beschikbare informatie en haalt die op van het web. RAG lost het organisatiekennisprobleem op: het model mist interne, organisatiespecifieke kennis en koppelt die via een interne kennisbron. Search werkt met het open web en levert actuele informatie uit bronnen die je niet vooraf hebt geselecteerd. RAG werkt met een kennisbron die de organisatie zelf beheert en onderhoudt.

Wie actuele marktinformatie nodig heeft, gebruikt search. Wie wil dat het AI-model antwoorden geeft op basis van interne beleidsdocumenten, heeft RAG nodig. Wie beide nodig heeft, combineert ze. Het zijn complementaire routes voor twee verschillende soorten informatie.

Een bewuste keuze

Wij kiezen er bewust voor om search en RAG als gescheiden concepten te behandelen. In de praktijk worden ze vaak in één adem genoemd of door elkaar gehaald. Maar de beslissing welk informatieprobleem je oplost, bepaalt welke route je kiest. Wie dat onderscheid scherp heeft, stelt betere vragen aan een technisch team.

Voorbeelden

Het patroon is steeds hetzelfde: zodra de informatie die het model nodig heeft actueler is dan de trainingsdata, maakt search het verschil.

Medische kliniek

Een arts wil weten of er recente wijzigingen zijn in de behandelrichtlijn voor een specifieke aandoening. Het AI-model doorzoekt via web search de publicaties van de beroepsvereniging en vindt dat de richtlijn drie maanden geleden is herzien. Het voegt de relevante passages toe aan het antwoord, met bronvermeldingen. De arts controleert de bron, bevestigt dat de informatie klopt, en past het behandelplan aan. Zonder search had het model geantwoord op basis van de richtlijn die gold ten tijde van de training, mogelijk een verouderde versie. Met search heeft de arts actuele informatie én een bron om het te verifiëren.

B2B-dienstverlener

Een accountantskantoor gebruikt een AI-assistent om klanten te adviseren over fiscale regelingen. De belastingwetgeving verandert jaarlijks. Het model doorzoekt via search de meest recente publicaties van de Belastingdienst en relevante vakmedia. Het levert een samenvatting op met verwijzingen naar de officiële bronnen. De accountant hoeft niet zelf zes verschillende websites te doorzoeken, maar controleert wél de bronnen voordat die de klant bereiken. De kracht zit in de tijdsbesparing bij het vinden van de juiste informatie. De accountant verifieert, het model zoekt.

Zelfstandige professional

Een zelfstandige consultant bereidt een voorstel voor bij een potentiële klant. Via deep research laat ze het AI-model een concurrentieanalyse maken: wie zijn de belangrijkste spelers in de sector van de klant, welke ontwikkelingen spelen er, welke uitdagingen worden in de vakmedia benoemd. Het model levert een rapport op met tientallen bronvermeldingen. Het kost haar een half uur om de bronnen te controleren en het rapport bij te schaven. Zonder deep research had dat onderzoek een hele werkdag gekost.

Veelgestelde vragen

Wat is het verschil tussen search en RAG?

Search haalt publieke, actuele informatie op van het open web. RAG haalt interne organisatiekennis op uit een kennisbron die de organisatie zelf beheert. Search lost het actualiteitsprobleem op: het model mist recente informatie die na de training is verschenen. RAG lost het organisatiekennisprobleem op: het model mist kennis over jouw processen, beleid en documenten. Een arts die de nieuwste behandelrichtlijn nodig heeft, gebruikt search. Een medewerker die een antwoord zoekt op basis van het interne kwaliteitshandboek, heeft RAG nodig. De twee routes vullen elkaar aan en worden in de praktijk vaak gecombineerd in hetzelfde AI-systeem.

Kan AI ook foute informatie ophalen bij het zoeken?

Ja. Search vermindert het risico op onjuiste antwoorden, maar elimineert het niet. Het model kan zoekopdrachten genereren die de vraag niet precies dekken, bronnen selecteren die onbetrouwbaar zijn, of informatie verkeerd interpreteren. Het model kan geruchten niet altijd onderscheiden van geverifieerde feiten. Daarom leveren AI-systemen bij search bronvermeldingen mee. Die zijn er om het antwoord te controleren, niet om het gezag van het antwoord te vergroten. De vuistregel: hoe belangrijker de beslissing die op het antwoord rust, hoe belangrijker het is om de bronnen te checken.

Beslist het model zelf wanneer het zoekt?

Meestal wel. Bij vragen over actuele informatie, zoals recente gebeurtenissen, huidige regelgeving of lopende ontwikkelingen, activeert het model search automatisch. Bij vragen over stabiele kennis uit de training doet het dat niet. Die beslissing is doorgaans juist. Maar niet altijd. Sommige platforms bieden de optie om search handmatig in of uit te schakelen. Het helpt om er bewust mee om te gaan: als je een vraag stelt waarvan je vermoedt dat het antwoord recent is veranderd, maak dat dan expliciet in je prompt. “Zoek de meest recente versie” is een zin die het verschil kan maken.

Wat is het verschil tussen search en deep research?

Search beantwoordt een concrete vraag op basis van een of enkele zoekresultaten. Deep research gaat verder: het model zoekt autonoom gedurende meerdere minuten, raadpleegt tientallen tot honderden bronnen, en levert een gestructureerd rapport op met bronvermeldingen bij elke bewering. Het verschil is vergelijkbaar met het verschil tussen een snelle zoekopdracht en een ochtend in een vakbibliotheek. Deep research levert meer diepgang, maar vraagt ook meer tijd en meer investering in verificatie. Wie een enkel feit nodig heeft, gebruikt search. Wie een analyse, vergelijking of rapport nodig heeft, gebruikt deep research.

Verder lezen

Wie wil begrijpen hoe AI-systemen interne organisatiekennis koppelen via de andere route voor het informatieprobleem, leest verder bij RAG: organisatiekennis koppelen (cluster 5.2).

Wie wil weten hoe search technisch wordt aangestuurd via tools en function calling, vindt dat bij Tools en function calling (cluster 7.2).

Wie wil begrijpen waarom AI-modellen soms overtuigend én onjuist zijn, ook wanneer ze zoeken, leest verder bij Wat is een hallucinatie? (cluster 1.4b).

Een directeur stuurt een AI-model het complete jaarverslag, drie sectoranalyses en de notulen van de laatste kwartaalvergadering. De opdracht: schrijf een samenvatting voor de raad van bestuur. Het model heeft alles ontvangen. Alles staat in de context. En toch mist het antwoord een cruciale passage uit pagina 47.

Het probleem zit niet in het model. Het zit in hoe het model omgaat met grote hoeveelheden informatie tegelijk. Elk AI-model heeft een vast venster waarbinnen het informatie verwerkt: het context window. Dat venster is groter dan ooit. Maar het heeft grenzen. En die grenzen werken anders dan de meeste mensen verwachten.

Alles wat het model kan zien

Het context window (in het Nederlands ook wel contextvenster genoemd) is de totale hoeveelheid informatie die een AI-model in één keer kan verwerken. Alles wat binnen dat venster valt, wordt tegelijk meegenomen: de instructie, de meegeleverde documenten, de gespreksgeschiedenis, de systeeminstructies en het antwoord dat het model genereert. Wat buiten het venster valt, bestaat niet voor het model.

Het model verwerkt de hele context opnieuw bij elke beurt in een gesprek. Er is geen korte- of langetermijngeheugen zoals bij mensen. Er is alleen het venster: wat erin zit, telt mee. Wat er niet in zit, is onzichtbaar. Die eigenschap maakt het context window tot een van de meest bepalende factoren voor de kwaliteit van AI-output.

In het Aiscendo Ringenmodel, dat beschrijft hoe elke laag rond een AI-model het systeem krachtiger maakt, is het context window de technische begrenzing van Ring 2 (Weten): alle kennis die het model meekrijgt, via RAG, search, documenten of gespreksgeschiedenis, moet binnen dit venster passen.

De omvang van dat venster verschilt per model en groeit snel. Gangbare modellen werken met context windows in de orde van honderdduizenden tokens, en de ruimste gaan naar een miljoen of meer. Die grens verschuift voortdurend omhoog. Maar de omvang alleen vertelt niet het hele verhaal.

Gedeeld budget

Een detail dat in de praktijk ertoe doet: invoer en uitvoer delen hetzelfde context window. De instructie, de documenten en de gespreksgeschiedenis vullen het venster van de ene kant. Het antwoord dat het model genereert, vult het van de andere kant. Wie een lang document meestuurt, houdt minder ruimte over voor het antwoord. Wie een uitgebreid antwoord verwacht, moet minder context meegeven.

Stel je een whiteboard voor in een vergaderruimte. Alles wat erop geschreven staat, is zichtbaar voor iedereen in de ruimte. Maar het whiteboard heeft een vast formaat. Hoe meer achtergrond je opschrijft, hoe minder ruimte er overblijft voor de conclusies. Het context window werkt op dezelfde manier: invoer en uitvoer concurreren om dezelfde ruimte.

Tellen in tokens

De omvang van het context window wordt uitgedrukt in tokens. Dat is de eenheid waarmee een AI-model tekst verwerkt. Tokens zijn niet hetzelfde als woorden.

Tokens

Een model leest geen woorden zoals een mens dat doet. Het splitst tekst op in stukken die het kan herkennen: tokens. Korte, veelgebruikte woorden zijn meestal één token. Langere woorden en samenstellingen worden opgesplitst in meerdere stukken. Het woord “belastingaangifte” is voor een mens één woord, maar voor een model twee of drie tokens. Spaties tellen vaak mee. Leestekens zijn aparte tokens.

De vuistregel voor Engelstalige tekst: honderd woorden zijn ruwweg 130 tokens. Voor Nederlandstalige tekst ligt dat hoger, omdat Nederlandse samenstellingen langer zijn en de meeste modellen zijn geoptimaliseerd voor Engels. Een Nederlandse tekst van duizend woorden bevat al gauw 1.400 tot 1.600 tokens.

Het schaalbegrip

Om te voelen hoe groot een context window is, helpt het om tokens te vertalen naar documenten die je kent. Een korte e-mail bevat 100 tot 300 tokens. Een zakelijk rapport van tien pagina’s zit rond de 5.000 tokens. Een boek van 300 pagina’s bevat ruwweg 100.000 tokens.

Een model met een context window van 200.000 tokens kan dus twee boeken tegelijk verwerken, of tientallen rapporten met alle bijlagen, of een complete codebase van een middelgroot softwareproject. Die schaal maakt toepassingen mogelijk die voorheen ondenkbaar waren: een heel dossier analyseren in één opdracht, meerdere bronnen tegelijk vergelijken, een uitgebreid gesprek voeren zonder dat eerdere beurten verloren gaan.

Die schaal is indrukwekkend. Maar schaal alleen is niet waar het verhaal eindigt.

Waar de aandacht verdwijnt

Hier zit het inzicht dat veel mensen verrast. Een AI-model verwerkt alle informatie in het context window, maar het verwerkt niet alles met dezelfde nauwkeurigheid.

Het lost-in-the-middle-effect

Onderzoek heeft een consistent patroon blootgelegd. Informatie aan het begin van de context en aan het einde krijgt meer gewicht dan informatie die in het midden staat. Dit verschijnsel heet het lost-in-the-middle-effect. Het patroon volgt een U-vormige curve: hoge nauwkeurigheid voor de eerste en laatste stukken informatie, lagere nauwkeurigheid voor alles wat daartussen staat.

De impact is niet subtiel. In experimenten daalde de nauwkeurigheid met meer dan 30 procent wanneer het relevante antwoord in het midden van twintig documenten stond, vergeleken met een positie aan het begin of het einde. Dat verschil is groot genoeg om in de praktijk het verschil te maken tussen een correct en een fout antwoord.

Het fenomeen doet denken aan hoe mensen een lange vergadering ervaren. De opening en de afsluiting beklijven. Wat halverwege is gezegd, verdwijnt naar de achtergrond. Bij AI-modellen is de oorzaak architecturaal, maar het resultaat is vergelijkbaar: informatie in het midden van de context krijgt minder aandacht.

Context rot

Er is een tweede patroon. Naarmate het context window voller raakt, neemt de algehele nauwkeurigheid af. Dit effect wordt context rot genoemd. Het model verwerkt de informatie nog wel, maar de aandacht wordt dunner verdeeld over meer tokens. Relevante details raken ondergesneeuwd. Het antwoord wordt breder en tegelijk minder precies.

Een studie die achttien gangbare modellen testte, vond dit effect bij elk model, zonder uitzondering. Het trad niet pas op bij de maximale capaciteit. Al ruim vóór de limiet begon de kwaliteit af te nemen. Een context window van een miljoen tokens dat tot de helft is gevuld, presteert al meetbaar minder dan bij lagere vulling.

Dat is een cruciaal inzicht voor wie nadenkt over de inzet van AI met grote hoeveelheden informatie. Het context window is geen emmer die je vult tot de rand. Het is eerder een leeslamp: hoe breder je het licht spreidt, hoe diffuser het wordt. Gericht licht op de juiste plek levert meer op dan alle lampen aan in de hele bibliotheek.

De kunst van selectie

Lost-in-the-middle en context rot leiden samen tot een conclusie die de intuïtie op zijn kop zet. De reflex bij de meeste organisaties is: geef het model zoveel mogelijk informatie, dan maakt het de beste keuze. Dat blijkt niet te kloppen. En dat verandert niet naarmate context windows groter worden. Een venster van een miljoen tokens heeft dezelfde kwetsbaarheden als een venster van tweehonderdduizend, alleen op grotere schaal.

De kwaliteit van AI-output hangt niet af van hoeveel je meegeeft, maar van hoe goed je selecteert wat je meegeeft. Een AI-systeem dat bij elke klantvraag het hele archief in het context window laadt, presteert slechter dan een systeem dat alleen de drie meest relevante documenten ophaalt. Wie de juiste vijf pagina’s selecteert, krijgt een beter antwoord dan wie een heel handboek meestuurt.

Van volume naar precisie

Een groter context window is waardevol in specifieke situaties. Het analyseren van een lang document in zijn geheel. Het vergelijken van meerdere bronnen tegelijk. Het voeren van een uitgebreid gesprek zonder dat eerdere beurten worden afgekapt. In die gevallen maakt het verschil tussen een taak die lukt en een taak die niet past.

Maar voor de meeste professionele toepassingen verschuift de vraag van “past alles erin?” naar “wat hoort erin?” Dat is precies de reden waarom context engineering een eigen discipline is geworden: het bewust ontwerpen van de informatie die het model bij elke stap ontvangt. De bouwstenen en technieken uit de promptingclusters helpen je om die informatie te structureren. Context engineering gaat een stap verder: het bepaalt welke informatie het model überhaupt te zien krijgt.

Hier raakt het context window aan een andere oplossing uit deze pillar. RAG (Retrieval-Augmented Generation) is gebouwd op dit principe: in plaats van alles in het context window te laden, doorzoekt het systeem een externe kennisbron en haalt alleen de relevante passages op. Het model krijgt niet alles te zien. Het krijgt het juiste te zien.

Voorbeelden

Medische kliniek

Een middelgrote kliniek bouwt een AI-toepassing die artsen ondersteunt bij het analyseren van patiëntdossiers. Een gemiddeld dossier bevat correspondentie, laboratoriumuitslagen, verslagen van specialisten en medicatiehistorie. Bij complexe patiënten loopt zo’n dossier op tot 80.000 tokens. De arts stelt een vraag en het systeem haalt het dossier op. Met een context window van 200.000 tokens past het dossier ruim. Maar wanneer het systeem ook de relevante behandelrichtlijnen en het vaste instructieblok van de kliniek meelaadt, raakt het venster voller dan verwacht. De kliniek ontdekt dat het systeem het best presteert wanneer het niet het hele dossier meestuurt, maar alleen de meest relevante secties selecteert en die aan het begin van de context plaatst.

B2B-dienstverlener

Een accountantskantoor gebruikt een AI-systeem dat conceptadviezen opstelt op basis van jaarrekeningen en brancherichtlijnen. De accountant uploadt de jaarrekening van een klant en verwacht dat het systeem de juiste richtlijnen erbij haalt. Dat doet het ook, maar soms mist het model een relevante passage uit het midden van een lang richtlijnendocument. De oplossing blijkt niet het vergroten van het context window, maar het verbeteren van de selectie: alleen de secties ophalen die betrekking hebben op de branche van deze klant, en die bovenaan de context plaatsen. Het verschil in kwaliteit is direct merkbaar.

Zelfstandige professional

Een zelfstandige adviseur voert regelmatig lange gesprekken met een AI-model over strategische vraagstukken. Na twintig beurten merkt ze dat het model eerdere afspraken uit het gesprek niet meer consequent opvolgt. De informatie staat er nog, maar is in het midden van een steeds langer groeiend context window beland. Het model geeft er minder gewicht aan. De adviseur leert om bij een lang gesprek de kernafspraken samen te vatten en opnieuw aan te bieden, zodat ze weer vooraan in de context staan. Het effect is merkbaar: het model volgt de afspraken weer op.

Veelgestelde vragen

Is het context window hetzelfde als het geheugen van een AI-model?

Binnen één gesprek functioneert het context window als werkgeheugen: alles wat erin staat, wordt meegenomen in het antwoord. Maar zodra het gesprek wordt afgesloten, is het context window leeg. Het model bewaart niets uit vorige sessies. Wat voelt als geheugen bij platforms die informatie over gesprekken heen bewaren, is een functie van de applicatie, niet van het model zelf. De applicatie slaat een samenvatting op en voegt die toe bij een nieuw gesprek. Dat is een ander mechanisme dan het context window. Het verschil is praktisch relevant: een samenvatting vangt de grote lijn, maar details en specifieke formuleringen uit eerdere gesprekken gaan verloren.

Wat gebeurt er als het context window vol raakt?

Het model kan niet meer informatie verwerken dan er in het context window past. Bij de meeste systemen worden de oudste delen van het gesprek afgekapt of samengevat om ruimte te maken voor nieuwe informatie. Dat gebeurt onzichtbaar: er verschijnt geen foutmelding, maar het model reageert ineens alsof het eerdere afspraken niet meer meeneemt. In de praktijk is dit een van de meest voorkomende redenen waarom AI-output in lange gesprekken achteruitgaat. Niet omdat het model slechter wordt, maar omdat relevante informatie buiten het venster is gevallen. De oplossing is niet per se een groter context window, maar bewuster omgaan met wat je erin stopt: de belangrijkste instructies herhalen, tussentijds samenvatten, en irrelevante gespreksgeschiedenis niet laten opstapelen.

Is een groter context window altijd beter?

Nee. Een groter context window betekent dat het model meer informatie tegelijk kán verwerken, maar niet dat het al die informatie even nauwkeurig verwerkt. Het lost-in-the-middle-effect en context rot zorgen ervoor dat de kwaliteit daalt naarmate het venster voller raakt. Voor veel toepassingen levert een kleiner, gericht gevuld context window betere resultaten dan een groot venster dat tot de rand is gevuld. De afweging is niet “hoeveel past erin?” maar “welke informatie levert het beste resultaat?” Dat is de reden waarom technieken als RAG en context engineering bestaan: ze vullen het context window gericht, in plaats van het te overladen.

Merk ik het als het context window bijna vol is?

Niet direct. De meeste AI-platforms geven geen waarschuwing wanneer het context window zijn limiet nadert. Wat je merkt, zijn de gevolgen: het model volgt instructies niet meer op, herhaalt zichzelf, of geeft antwoorden die minder aansluiten bij wat je eerder hebt besproken. Die signalen wijzen erop dat het venster vol raakt en dat eerdere informatie minder gewicht krijgt of is afgekapt. Bij lange gesprekken of opdrachten met veel bijgevoegde documenten is het verstandig om bewust ruimte te houden. Dat kan door een nieuw gesprek te starten met een samenvatting van de voortgang, of door alleen de documenten mee te geven die voor de actuele vraag relevant zijn.

Verder lezen

Wie wil begrijpen hoe je bewust ontwerpt welke informatie het model ontvangt en hoe dat de kwaliteit van AI-output stuurt, leest verder bij Context engineering: van goede prompt naar slim systeem (cluster 4.4).

Wie wil weten hoe organisaties hun eigen kennisbronnen koppelen aan AI-systemen zodat het model bij elke vraag automatisch de juiste documenten ontvangt, vindt dat bij RAG: organisatiekennis koppelen (cluster 5.2).

Iedereen die langer dan een week met een AI-chatbot werkt, maakt hetzelfde mee. Je opent een nieuw gesprek, stelt een vraag, en het model reageert alsof jullie nooit eerder hebben gesproken. De toon die vorige week was afgestemd, het project dat stap voor stap was opgebouwd, de voorkeuren die je dacht te hebben vastgelegd: verdwenen. Alles weg.

Dat is geen fout en het wordt niet opgelost in de volgende versie. Vergeten is de standaardinstelling: een AI-model slaat niets op tussen sessies, en elk gesprek begint als een volledig schone lei. Dat roept een vraag op die steeds vaker op directietafels belandt: hoe bouw je iets structureels op met een systeem dat bij elk gesprek opnieuw begint? Het antwoord is geheugen. Niet geheugen zoals mensen dat kennen, maar geheugen als ontwerpkeuze: een laag die de applicatie om het model heen bouwt, zodat informatie bewaard blijft die het model zelf niet bewaart.

Elke sessie begint op nul

Een AI-model bouwt geen beeld op van wie het tegenover zich heeft. Het houdt niet bij wat er eerder is besproken. Zodra een sessie eindigt, is alles weg. Het model keert terug naar exact dezelfde uitgangspositie als waarmee het begon.

Dat komt door hoe het model werkt. Een AI-model genereert antwoorden op basis van de informatie die het op dat moment meekrijgt: de prompt, de gespreksgeschiedenis van die sessie, en eventuele aanvullende instructies. Het model zelf heeft geen plek om herinneringen te bewaren en geen mechanisme om ervaringen te accumuleren.

Wanneer dat merkbaar wordt

Voor een enkele vraag maakt dat niet uit. Maar zodra iemand structureel met een AI-model werkt, wordt het vergeetprobleem tastbaar. Een adviseur die wekelijks klantanalyses maakt, begint elke sessie opnieuw: in welke branche zit de klant, welke analysestijl heeft de voorkeur, hoe moet het rapport worden opgebouwd. Een manager die een strategisch plan iteratief ontwikkelt, verliest bij elk nieuw gesprek de opgebouwde nuance. De continuïteit die bij menselijke samenwerking vanzelfsprekend is, ontbreekt.

Binnen het gesprek lijkt het anders

Binnen één gesprek lijkt het wél alsof het model informatie vasthoudt. Je verwijst naar iets van drie beurten geleden, en het model pakt de draad op. Dat voelt als geheugen.

Sessiegeheugen

Wat er werkelijk gebeurt: bij elke beurt stuurt de applicatie de volledige gespreksgeschiedenis mee. Alles wat de gebruiker heeft gezegd en alles wat het model heeft geantwoord, van de eerste zin tot de laatste. Het model leest die hele geschiedenis opnieuw en genereert op basis daarvan het volgende antwoord.

Dit is sessiegeheugen. Het valt samen met het context window: het venster van informatie dat het model tegelijk kan verwerken. Zolang het gesprek in dat venster past, werkt het feilloos.

De grens van het venster

Maar dat venster heeft een limiet. Bij lange gesprekken valt op een gegeven moment de oudste informatie weg. Het is alsof de eerste pagina’s uit een notitieboekje worden gescheurd terwijl er verder wordt geschreven. Een afspraak uit de derde beurt kan in de dertigste beurt onzichtbaar zijn geworden. De informatie is niet “vergeten” in de menselijke zin. Ze is uit het venster geschoven en daarmee onbereikbaar.

Sessiegeheugen is tijdelijk en begrensd. Het eindigt zodra het gesprek wordt afgesloten. De details over hoe het context window werkt en wat de omvang ervan betekent, staan op de pagina over context windows (cluster 5.4). Hier telt het kernpunt: wat er binnen het gesprek als geheugen voelt, is in werkelijkheid herlezing.

Het model wordt herinnerd

Langetermijngeheugen werkt fundamenteel anders dan sessiegeheugen. Het is geen eigenschap van het model, maar een functie van de applicatie eromheen.

De geheugenlaag

Alle grote AI-platforms bieden een geheugenfeature. De aanpak verschilt, maar het principe is overal hetzelfde. De applicatie (het platform, de chatinterface) observeert gesprekken en slaat kernfeiten op: wie de gebruiker is, welke toon de voorkeur heeft, aan welk project wordt gewerkt, welke beslissingen eerder zijn genomen. Bij een nieuw gesprek voegt de applicatie die opgeslagen informatie toe aan de context die het model meekrijgt. Het model leest die informatie alsof het onderdeel is van de instructie.

Het resultaat voelt als geheugen: de toon is aangepast, de projectcontext is meegenomen, het gesprek gaat verder waar het vorige ophield. Maar het mechanisme is wezenlijk anders dan het lijkt. De applicatie heeft het model herinnerd. Het model heeft niet zelf onthouden.

Samenvatting versus herinnering

Dat onderscheid klinkt als een detail, maar het bepaalt wat je kunt verwachten. Wat de applicatie opslaat, is een samenvatting. Geen volledig transcript van elk gesprek, geen exacte reconstructie van hoe een redenering tot stand kwam. De samenvatting vangt de grote lijn: deze persoon werkt aan een reorganisatieplan, schrijft het liefst in korte zinnen, en wil geen opsommingen in rapporten.

De nuances zijn doorgaans weg. De specifieke formulering die na drie iteraties precies goed was. Het argument dat na lang wikken en wegen de doorslag gaf. De sfeer waarin een gevoelig punt werd aangekaart. Die details overleven de samenvatting niet.

Het verschil is vergelijkbaar met het verschil tussen een vergaderverslag en een eigen herinnering. Een verslag vangt de conclusies en de actiepunten. Een herinnering bevat ook het moment waarop het inzicht viel, de aarzeling die eraan voorafging, hoe de stemming in de ruimte verschoof. Geheugenfeatures leveren verslagen, geen herinneringen. Dat maakt ze bruikbaar voor continuïteit op hoofdlijnen, en onbetrouwbaar voor precisiewerk dat leunt op exacte eerdere details.

Context die je zelf inricht

Automatisch geheugen werkt reactief: het systeem pikt informatie op uit gesprekken en slaat die op. De meeste platforms bieden ook een actieve route. Je kunt context vooraf ontwerpen, zonder te wachten tot het systeem die zelf ontdekt.

De vormen variëren. Vaste instructies die bij elk gesprek worden meegestuurd: welke taal, welke toon, welke conventies gelden. Projectomgevingen waarin je instructies, stijlgidsen en klantprofielen klaarzet, zodat elk gesprek binnen dat project dezelfde basis heeft. Voorgebouwde assistenten, elk geconfigureerd voor één specifieke taak met eigen instructies en kennisbestanden. Doorzoekbare gespreksgeschiedenis waarmee het systeem context uit eerdere sessies kan ophalen. Al die functies bouwen context om het model heen. Het model zelf verandert niet. Wat verandert, is wat het meekrijgt. Het Aiscendo Ringenmodel, dat wij hebben ontwikkeld om de opbouw van AI-systemen zichtbaar te maken, draait om precies dit punt: de kwaliteit wordt bepaald door de lagen die je om het model heen bouwt.

Geheugen voor een organisatie

Persoonlijk geheugen, de variant die de meeste mensen kennen, werkt tussen één gebruiker en één model. Maar voor organisaties speelt een grotere vraag. Hoe zorg je dat een AI-systeem de kennis, de context en de afspraken heeft die een heel team nodig heeft?

Organisatiegeheugen

Organisatiegeheugen is een ontwerpvraagstuk: welke informatie moet een AI-systeem meekrijgen om effectief te functioneren binnen een organisatie? Huisstijlregels, procedurebeschrijvingen, klantprofielen, besluitgeschiedenis, projectcontext. Die informatie zit doorgaans verspreid over tientallen systemen: documenten, e-mails, projecttools, hoofden van medewerkers. Een AI-systeem dat daar geen toegang toe heeft, geeft generieke antwoorden. Een systeem dat die informatie wél meekrijgt, functioneert als een collega die de organisatie kent.

De technische invulling verschilt. Sommige organisaties gebruiken RAG (retrieval-augmented generation: het ophalen en meesturen van relevante documenten bij elke vraag) om interne kennis doorzoekbaar te maken voor het AI-systeem. Andere bouwen gestructureerde geheugenlagen die beslissingen en context per team of per project bijhouden. De aanpak hangt af van de omvang, de gevoeligheid van de informatie, en de manier waarop het AI-systeem wordt ingezet.

Privacy als ontwerpkeuze

Organisatiegeheugen raakt direct aan privacy en datagovernance. Welke informatie mag een AI-systeem opslaan, en wie heeft er toegang toe? Wat gebeurt er als een medewerker vertrekt, en in hoeverre is het geheugen inzichtelijk genoeg om te corrigeren?

Die vragen zijn niet alleen technisch. Ze raken aan vertrouwen, aan compliance, en aan de verwachtingen van medewerkers en klanten. Een organisatie die geheugen inricht voor haar AI-systemen, neemt een beslissing die raakt aan hoe de organisatie met informatie omgaat. Dat is een vraag voor de directietafel.

Voorbeelden

Hier zit een onderscheid dat in de praktijk het verschil maakt tussen een AI-systeem dat aanvoelt als een los hulpmiddel en een systeem dat aanvoelt als een collega die meedenkt.

B2B-dienstverlener

Een accountantskantoor gebruikt een AI-systeem voor het opstellen van adviesrapporten. Zonder ingerichte context begint elke sessie blanco: de medewerker specificeert opnieuw in welke sector de klant opereert, welke rapportstructuur het kantoor hanteert, en welke toon past bij het type advies. Het kantoor richt een projectomgeving in met de huisstijlgids, rapportsjablonen en branche-informatie per klant. Vanaf dat moment heeft het systeem die context bij elk gesprek. De medewerker begint waar het vorige gesprek ophield. Het verschil: twintig minuten opstarttijd per sessie worden twee minuten. Over een werkweek is dat het verschil tussen een hulpmiddel dat moeite kost en een hulpmiddel dat moeite bespaart.

Zelfstandige professional

Een zelfstandige marketingadviseur werkt dagelijks met een AI-model voor contentcreatie en klantcommunicatie. De eerste weken herhaalt ze bij elk gesprek haar schrijfstijl, haar doelgroepomschrijving en de merken waarvoor ze werkt. Elke sessie voelt als een eerste kennismaking. Na het activeren van een geheugenfeature verandert dat geleidelijk. Het systeem accumuleert context over weken: de toon, de stijl, de klantkennis bouwen zich op. Na een maand hoeft ze alleen nog de opdracht te geven. Het effect gaat verder dan tijdsbesparing: de output wordt beter omdat het model steeds scherper is afgestemd op haar manier van werken.

Veelgestelde vragen

Wat is het verschil tussen geheugen en het context window?

Het context window is wat het model binnen één sessie kan verwerken. Het bevat de volledige gespreksgeschiedenis, zolang die past. Zodra de sessie eindigt, is het context window leeg. Geheugen is de laag die de applicatie eromheen bouwt: informatie die over sessies heen wordt opgeslagen en bij een nieuw gesprek aan de context wordt toegevoegd. Het context window is tijdelijk en automatisch. Geheugen is persistent en ontworpen. De twee vullen elkaar aan: het context window bepaalt hoeveel informatie het model tegelijk kan verwerken, het geheugen bepaalt welke informatie over sessies heen beschikbaar blijft.

Hoe bepaal ik welke informatie een AI-systeem moet onthouden voor mijn organisatie?

Begin bij de vraag: welke context moet een medewerker nu elke keer opnieuw geven voordat het AI-systeem bruikbare output levert? Dat is de informatie die in het geheugen thuishoort. Huisstijl, procedurebeschrijvingen, klantprofielen, projectcontext. Vermijd de neiging om alles op te slaan. Hoe meer irrelevante informatie in het geheugen zit, hoe groter de kans dat het systeem verkeerde context oppikt en minder gerichte antwoorden geeft. Geheugen ontwerpen is kiezen wat ertoe doet. Dat is vergelijkbaar met het samenstellen van een goed dossier: de waarde zit in selectie, in de juiste informatie op het juiste moment.

Kan ik erop vertrouwen dat het geheugen klopt?

Beperkt. Geheugenfeatures slaan samenvattingen op, en samenvattingen missen nuances. Een systeem dat onthoudt dat je “de voorkeur hebt voor een zakelijke toon” kan die voorkeur verkeerd toepassen in een context waar een andere toon passender is. Een systeem dat onthoudt dat “het project in fase twee zit” merkt niet vanzelf op wanneer fase twee is afgerond. Geheugen is een startpunt, geen betrouwbare bron. Controleer periodiek wat er is opgeslagen, corrigeer wat niet klopt, en behandel het geheugen als een hulpmiddel dat bijsturing nodig heeft. Die houding voorkomt dat je blind vaart op informatie die verouderd of onvolledig is.

Wat gebeurt er met mijn data als AI het onthoudt, en is dat veilig?

Dat hangt af van het platform en de instellingen. Bij sommige platforms is het geheugen leesbaar en bewerkbaar: je kunt precies zien wat er is opgeslagen en het aanpassen of verwijderen. Bij andere is de opslag ondoorzichtig en heb je beperkt zicht op wat het systeem heeft vastgelegd. In Europa gelden aanvullende regels rond geautomatiseerde profilering, die van invloed kunnen zijn op hoe geheugenfeatures worden aangeboden. De kernvraag voor een organisatie is: waar wordt het geheugen opgeslagen, wie heeft er toegang toe, en is het inzichtelijk genoeg om fouten te corrigeren? Die vragen verdienen hetzelfde niveau van zorgvuldigheid als elke andere beslissing over dataopslag en privacy.

Verder lezen

Wie wil begrijpen hoe je systematisch nadenkt over welke context een AI-systeem meekrijgt en hoe je die context ontwerpt, leest verder bij Context engineering (cluster 4.4).

Wie wil begrijpen hoe het context window technisch werkt en waarom de omvang ervan ertoe doet, leest verder bij Context windows: hoeveel informatie past er? (cluster 5.4).

Wie terug wil naar hoe geheugen op gespreksniveau werkt en hoe je lange gesprekken effectief beheert, vindt dat bij Multi-turn prompting en geheugen (cluster 4.3e).

Wie wil weten hoe geheugen een rol speelt bij AI-systemen die zelfstandig taken uitvoeren over langere periodes, leest verder bij Agents: AI dat zelfstandig handelt (cluster 8.3).

Een medewerker typt een vraag in het AI-systeem van de organisatie: hoe gaan we om met btw-verlegging bij dienstverlening buiten de EU? Het antwoord verschijnt binnen enkele seconden. Het verwijst naar de juiste interne richtlijn. Het noemt de voorwaarden die van toepassing zijn. Het antwoord is specifiek voor deze organisatie, gebaseerd op documenten die nergens op het publieke internet staan.

En toch heeft het model dat dit antwoord genereerde, geen enkel van die documenten ooit verwerkt tijdens de training. De richtlijn stond op de interne SharePoint. Het model is getraind op het publieke internet. Hoe kan het antwoord dan kloppen?

Het mechanisme dat dit mogelijk maakt heet Retrieval-Augmented Generation, afgekort tot RAG.

De ontbrekende schakel

Een AI-model genereert antwoorden op basis van patronen uit de training. Die training omvat miljarden documenten van het publieke internet: webpagina’s, boeken, artikelen, codebases. Dat maakt het model breed inzetbaar voor algemene vragen. Maar zodra iemand vraagt “wat is ons retourbeleid voor zakelijke klanten?” of “welke afspraken staan er in het contract met leverancier X?”, stopt het. Die informatie zat niet in de training.

Er zijn twee voor de hand liggende oplossingen, en geen van beide schaalt. De eerste: kopieer de relevante documenten handmatig naar het chatvenster. Dat werkt bij twee pagina’s. Niet bij tweeduizend. De tweede: train het model opnieuw met je eigen data via fine-tuning. Dat is duur, tijdrovend, en het resultaat is verouderd zodra er een nieuw document bijkomt.

RAG kiest een derde weg. Het model wordt niet aangepast. De informatie wordt automatisch opgehaald op het moment dat de vraag wordt gesteld, en meegegeven als context. Het model verwerkt die context en genereert een antwoord dat is gebaseerd op de eigen documenten van de organisatie. Retrieval-Augmented Generation: ophalen, verrijken, genereren. De naam beschrijft exact wat er gebeurt.

Van vraag tot antwoord

Hoe werkt dat concreet? Neem een middelgroot accountantskantoor. Tweehonderd medewerkers, duizenden adviesdocumenten, richtlijnen, procesbeschrijvingen en klantdossiers. Verspreid over SharePoint, een kennisbank en lokale mappen. Een nieuwe medewerker wil weten: “Hoe gaan we om met btw-verlegging bij dienstverlening buiten de EU?”

Het antwoord staat ergens in de interne richtlijnen. Maar waar precies? En in welk document? RAG lost dat op in vijf stappen.

De vraag vertalen

De vraag van de medewerker wordt omgezet naar een reeks getallen, een zogenoemde embedding. Die getallen vatten de betekenis van de vraag samen in een vorm die een computer kan vergelijken met andere teksten.

Dat klinkt abstract. Maar het principe is intuïtief. Stel je een ruimte voor met honderden dimensies, waarin elke tekst een punt inneemt. Teksten die over hetzelfde onderwerp gaan, liggen in die ruimte dicht bij elkaar. Teksten over iets totaal anders liggen ver uit elkaar. “Btw-verlegging bij buitenlandse dienstverlening” ligt dicht bij “fiscale behandeling van grensoverschrijdende services”. En ver van “kantoorbenodigdheden bestellen”.

Die ruimte, de zogenoemde vectorruimte, is de sleutel tot het hele RAG-proces. Het maakt het mogelijk om te zoeken op betekenis in plaats van op exacte woorden.

De kennisbron doorzoeken

De embedding van de vraag wordt vergeleken met de embeddings van alle passages in de kennisbron. Die passages liggen opgeslagen in een vector database: een database die is geoptimaliseerd voor het zoeken op betekenisovereenkomst.

Een gewone database zoekt op exacte trefwoorden. Zoek op “btw-verlegging” en je vindt alleen documenten waar precies die term in staat. Een vector database werkt anders. Die vergelijkt de betekenis van de zoekvraag met de betekenis van elke opgeslagen passage. Het document dat dezelfde fiscale regel beschrijft maar de term “omzetbelasting bij cross-border transacties” gebruikt, wordt ook gevonden. Dat is het verschil dat ertoe doet: zoeken op wat je bedoelt, niet op wat je typt.

De beste passages ophalen

De vector database retourneert de passages die het dichtst bij de vraag liggen in de vectorruimte. Meestal zijn dat drie tot tien passages, afhankelijk van hoe het systeem is ingericht. In het voorbeeld van het accountantskantoor: twee passages uit de interne btw-richtlijn, één passage uit een recente update over Europese regelgeving, en een fragment uit een eerdere adviesmemo over een vergelijkbare situatie.

Context meegeven

Die opgehaalde passages worden samengevoegd met de oorspronkelijke vraag en als context meegegeven aan het AI-model. Het model ontvangt nu de vraag én de relevante informatie uit de eigen kennisbron.

Vergelijk het met het verschil tussen een vraag stellen aan een collega die net is aangenomen, en dezelfde vraag stellen aan die collega nadat je haar het relevante dossier hebt gegeven. De persoon is dezelfde. Het verschil zit in de informatie die ze tot haar beschikking heeft.

Het antwoord genereren

Het model verwerkt de vraag en de opgehaalde passages, en genereert een antwoord. Dat antwoord is gebaseerd op de passages. Als de passages de juiste informatie bevatten, is het antwoord relevant en specifiek. Als de passages niet relevant zijn, is het antwoord dat ook niet.

De medewerker van het accountantskantoor krijgt een antwoord dat verwijst naar de interne richtlijn, de recente regelgevingsupdate en de eerdere adviesmemo. Het antwoord bevat de informatie die in die bronnen staat, geformuleerd als een samenhangend geheel. Het model heeft betere informatie gekregen. De capaciteiten zijn identiek gebleven.

Hoe documenten een kennisbron worden

Er is een stap die plaatsvindt voordat het RAG-proces kan draaien: de documenten moeten worden voorbereid. Dat is minder vanzelfsprekend dan het klinkt.

Een heel document, een richtlijn van dertig pagina’s of een procesbeschrijving van vijftien pagina’s, is te groot om als geheel op te halen en mee te geven aan het model. Het context window raakt vol en de relevantie verwatert. Maar een enkele zin is te klein: er zit te weinig context in om een bruikbaar antwoord op te baseren. De oplossing is chunking: het opknippen van documenten in passages van de juiste omvang. Elke passage, elke chunk, is groot genoeg om een samenhangend stuk informatie te bevatten en klein genoeg om gericht op te halen. Van elke chunk wordt een embedding gemaakt en opgeslagen in de vector database. Het resultaat is een doorzoekbare versie van de hele kennisbron, waarin elke passage bereikbaar is op basis van betekenis.

De juiste granulariteit

Hoe documenten worden opgeknipt, bepaalt de kwaliteit van het hele systeem. Chunks die te groot zijn, bevatten te veel irrelevante informatie naast de relevante passage. Het model moet dan zelf uitzoeken wat ertoe doet, en dat gaat niet altijd goed. Chunks die te klein zijn, missen de context die het antwoord begrijpelijk maakt. Een passage die luidt “de grens is 25.000 euro” is waardeloos zonder de context die vertelt welke grens, voor welke situatie en onder welke voorwaarden.

Het vinden van de juiste granulariteit is een ontwerpkeuze, niet een instelling die je één keer aanzet. Bij het accountantskantoor uit het voorbeeld werden de richtlijnen opgeknipt per onderwerp en per situatie, niet per pagina. Elke chunk bevat een afgeronde uitleg van één fiscale regel, inclusief de toepassingsvoorwaarden. Die keuze kostte tijd om goed te maken. Maar het verschil in de kwaliteit van de antwoorden was direct merkbaar.

Wat RAG niet verandert

Je zou na het voorgaande kunnen denken dat RAG het model verbetert. Dat is een begrijpelijke gedachte. Maar het klopt niet.

RAG verandert het model niet. Het model heeft dezelfde training, dezelfde capaciteiten, dezelfde beperkingen als zonder RAG. Wat verandert, is de informatie die het model ontvangt op het moment dat het een antwoord genereert. RAG verandert de context, niet het model.

Fine-tuning versus RAG

Dat onderscheid wordt helder in de vergelijking met fine-tuning. Fine-tuning past het model zelf aan. Het model wordt verder getraind op eigen data, zodat het domeinspecifieke kennis, vakjargon of een bepaalde schrijfstijl overneemt. Het resultaat: het model is permanent veranderd. Dat werkt voor kennis en vaardigheden die stabiel zijn: medische terminologie, juridische redeneerpatronen, een vaste huisstijl.

RAG levert kennis aan bij elke vraag opnieuw. De relevante passages worden vers opgehaald. Verandert het brondocument? Dan verandert het antwoord mee. Komt er een nieuw document bij? Dan is dat direct beschikbaar zonder dat het model opnieuw getraind hoeft te worden.

Fine-tuning werkt voor stabiele domeinkennis. RAG werkt voor kennis die verandert. In de praktijk vullen ze elkaar aan: fine-tuning maakt het model deskundiger in een domein, RAG voorziet het van de actuele informatie die het per vraag nodig heeft.

Voorbeelden

Hoe werkt het RAG-mechanisme in andere contexten? Twee scenario’s.

Medische kliniek

Neem een huisartsenpraktijk met zes huisartsen die het eigen medicatieprotocol, de NHG-richtlijnen en het lokale formularium aan een RAG-systeem koppelt. Een arts wil tijdens een consult weten of twee medicijnen samen voorgeschreven kunnen worden. Het systeem haalt de relevante passages op uit het formularium en het interactieprotocol, en genereert een antwoord dat specifiek verwijst naar de richtlijnen van deze praktijk. De arts krijgt geen generiek antwoord van het internet, maar een antwoord dat is gebaseerd op de bronnen waar de praktijk zelf mee werkt. De arts neemt de eindbeslissing. Het systeem levert de informatie aan die die beslissing ondersteunt.

Zelfstandig professional

Neem een zelfstandige organisatieadviseur die in tien jaar honderden adviesdocumenten, projectverslagen en methodiekbeschrijvingen heeft opgebouwd en dat archief aan een RAG-systeem koppelt. Bij het voorbereiden van een nieuwe offerte vraagt ze: “Welke aanpak heb ik eerder gebruikt bij vergelijkbare verandertrajecten in de financiële sector?” Het systeem doorzoekt haar eigen archief op betekenis, haalt relevante passages op uit drie eerdere projectverslagen, en presenteert de kern van haar eigen werkwijze. Geen generiek advies, maar haar eigen ervaring, teruggehaald op het moment dat ze die nodig heeft.

Veelgestelde vragen

Wat is het verschil tussen RAG en zoeken via een zoekmachine?

Een zoekmachine geeft je een lijst met links naar documenten. Je moet zelf doorklikken, lezen en de relevante informatie eruit halen. RAG doet iets anders: het haalt de relevante passages op, geeft ze mee aan een AI-model, en het model genereert een samenhangend antwoord op basis van die passages. Je krijgt een antwoord, geen zoekresultaten. Er is ook een dieper verschil. Een traditionele zoekmachine zoekt op trefwoorden: staat het woord in het document, ja of nee. RAG zoekt op betekenis. De vraag “btw bij buitenlandse klanten” vindt ook een passage die spreekt over “omzetbelasting bij grensoverschrijdende dienstverlening”, omdat de betekenis overeenkomt. Dat maakt RAG effectief voor kennisbronnen waarin dezelfde concepten op verschillende manieren worden beschreven.

Moet ik als organisatie vectors en embeddings technisch begrijpen om RAG te gebruiken?

Voor het dagelijks gebruik niet. Voor het stellen van de juiste vragen wel. Het dagelijks gebruik van een RAG-systeem vraagt geen technische kennis, net zoals je geen motorkennis nodig hebt om auto te rijden. Maar wie beslist over de aanschaf en inrichting van een RAG-systeem, heeft baat bij het begrijpen van de principes. Waarom haalt het systeem soms de verkeerde passages op? Omdat de embeddings de betekenis niet goed vastleggen, of omdat de chunks te groot of te klein zijn. Waarom geeft het systeem soms irrelevante antwoorden? Omdat de vector database niet de juiste passages als beste match teruggeeft. Met die basiskennis stel je scherpere vragen aan het technische team dat het systeem bouwt en onderhoudt. Het verschil tussen “het werkt niet goed” en “de retrieval-kwaliteit is onvoldoende, controleer de chunkgrootte” is het verschil tussen een signaal en een richting.

Wat gebeurt er als de kennisbron het antwoord niet bevat?

Dan zijn er twee scenario’s, en het verschil ertussen is belangrijk. Een goed ingericht RAG-systeem herkent dat de opgehaalde passages niet relevant genoeg zijn en meldt dat het geen antwoord kan vinden in de beschikbare bronnen. Een minder goed ingericht systeem genereert alsnog een antwoord, maar dan gebaseerd op de algemene trainingskennis van het model in plaats van op de kennisbron. Dat laatste is een risico, want de gebruiker merkt het verschil niet altijd op. Het antwoord klinkt even zelfverzekerd, maar is niet meer gebaseerd op de organisatiedocumenten. Hoe een systeem met deze situatie omgaat, is een ontwerpkeuze. Het herkennen van onvoldoende relevantie en het transparant melden ervan is een teken van een goed ontworpen RAG-systeem.

Is RAG niet een tijdelijke oplossing tot modellen groot genoeg zijn om alles in de context te verwerken?

Die gedachte mist twee punten. Ten eerste: zelfs met een onbeperkt context window heb je een mechanisme nodig dat selecteert welke informatie relevant is voor een specifieke vraag. Een context window vullen met alle documenten van een organisatie levert geen betere antwoorden op, omdat de aandacht van het model verwatert naarmate er meer informatie in zit. Selectie blijft noodzakelijk, ongeacht de grootte van het venster. Ten tweede: organisatiekennis verandert voortdurend. Richtlijnen worden bijgewerkt, klantafspraken wijzigen, regelgeving evolueert. Je wilt dat het antwoord de huidige versie van het document weerspiegelt, niet de versie die in de training zat. RAG lost een permanent probleem op: de kloof tussen de algemene kennis in het model en de specifieke, actuele kennis die een organisatie nodig heeft. Dat probleem verdwijnt niet met grotere context windows.

Verder lezen

Wie wil weten welke factoren bepalen of een RAG-systeem daadwerkelijk goede resultaten oplevert en welke fouten het vaakst worden gemaakt, leest verder bij Wat bepaalt of RAG werkt? (5.2b).

Wie wil begrijpen wanneer RAG de juiste keuze is voor een organisatie en hoe het zich verhoudt tot alternatieven als search en grote context windows, leest verder bij RAG: organisatiekennis koppelen (5.2).

Wie wil zien hoe RAG past in het bredere kader van contextbeheer en het ontwerpen van de informatieomgeving rond een AI-model, vindt dat bij Context engineering: van goede prompt naar slim systeem (4.4).

Een nieuwe medewerker van een accountantskantoor typt een vraag in het AI-systeem: wat is het huidige maximum voor representatiekosten? Het antwoord verschijnt binnen enkele seconden. Het is helder geformuleerd, verwijst naar een intern beleidsdocument en noemt een specifiek bedrag. Alles ziet er professioneel uit.

Het bedrag klopt niet. Het is anderhalf jaar geleden verhoogd. Het document waar het systeem naar verwijst, staat nog in de kennisbron. Nooit verwijderd, nooit gemarkeerd als verouderd. Het systeem haalde het op met dezelfde zekerheid als de actuele versie.

Het systeem in dit voorbeeld gebruikt RAG: het haalt bij elke vraag relevante passages op uit de eigen documenten van de organisatie en geeft die mee aan het AI-model, dat op basis daarvan een antwoord genereert. Wie wil begrijpen hoe dat proces van vraag tot antwoord precies verloopt, leest Wat is RAG en hoe werkt het? (5.2a). Deze pagina gaat over de vraag die daarna komt: werkt het ook? En het antwoord is: dat hangt af van beslissingen die lang vóór het eerste antwoord zijn genomen.

Waarom de eerste versie tegenvalt

Neem een middelgroot accountantskantoor dat RAG heeft ingezet voor duizenden interne richtlijnen, procesbeschrijvingen en adviesdocumenten. Het mechanisme draaide: vragen kwamen binnen, passages werden opgehaald, antwoorden werden gegenereerd. In de demonstratie zag alles er overtuigend uit.

Binnen de eerste weken werden drie patronen zichtbaar. Medewerkers die vragen stelden over fiscale regels kregen passages uit zowel de huidige richtlijn als een oudere versie die nooit was verwijderd. Vragen over het onboardingproces van nieuwe klanten leverden fragmenten op uit drie afdelingen met iets verschillende procedures. En een vraag over de declaratieregels voor een specifieke situatie leverde een generieke passage op over declaraties in het algemeen, zonder de specifieke voorwaarden.

Het model genereerde elke keer een helder, overtuigend antwoord. De antwoorden lazen goed. Een deel was fout. De informatie die het model ontving was onvolledig, verouderd of te generiek. En het model had geen manier om dat te herkennen.

De eerste reactie van het kantoor was voorspelbaar: meer bronnen aansluiten. Als het systeem niet genoeg informatie had, moest het meer te lezen krijgen. Nog meer richtlijnen, nog meer handleidingen, nog meer verslagen. De gedachte erachter voelt logisch. Hoe meer informatie beschikbaar is, hoe beter het antwoord. Gooi alles erin, dan haalt het AI-model er wel uit wat het beste past.

Het tegenovergestelde gebeurde. Meer documenten betekende meer verouderde versies die het systeem kon ophalen. Meer afdelingen betekende meer tegenstrijdige procedures die in één antwoord werden samengevoegd. Meer bestandstypen betekende meer ruis tussen de relevante passages. De antwoorden werden niet beter. Ze werden onvoorspelbaarder.

Dat is het inzicht dat deze pagina draagt. RAG-kwaliteit zit niet in de hoeveelheid informatie die je het systeem geeft. Ze zit in drie factoren die bepalen of de juiste informatie op het juiste moment bij het model terechtkomt.

Drie factoren die het verschil maken

De kwaliteit van een RAG-systeem hangt af van drie lagen, elk met hun eigen invloed op het eindresultaat. Als één laag zwak is, maakt het niet uit hoe sterk de andere twee zijn: het antwoord wordt er niet beter van. Het sterkste model ter wereld genereert een slecht antwoord als het de verkeerde informatie te lezen krijgt.

Retrieval-kwaliteit

De eerste laag: haalt het systeem de juiste passages op?

Een vector database vergelijkt de betekenis van een vraag met de betekenis van elke opgeslagen passage en retourneert de passages die het dichtst bij de vraag liggen. Maar “dichtst bij in betekenis” is niet hetzelfde als “meest relevant voor deze specifieke vraag.” Een passage over btw-regels in het algemeen kan dichter bij een vraag over btw-verlegging liggen dan de specifieke paragraaf die de uitzonderingen beschrijft. De algemene passage scoort hoger. De specifieke paragraaf, die het antwoord daadwerkelijk bevat, belandt lager in de rangschikking of wordt helemaal niet opgehaald.

Twee begrippen maken dit meetbaar.

Precision is het aandeel relevante passages in wat het systeem ophaalt. Als het systeem vijf passages retourneert en slechts twee bevatten bruikbare informatie, is precision laag. Het model ontvangt drie passages die niets toevoegen of, erger, afleiden van het juiste antwoord.

Recall is het aandeel van alle relevante informatie dat daadwerkelijk is gevonden. Als de kennisbron vier passages bevat die relevant zijn voor een vraag en het systeem vindt er maar één, is recall laag. Het model mist informatie die deel had moeten uitmaken van het antwoord.

De twee trekken in tegengestelde richtingen. Een systeem dat twintig passages ophaalt, vindt waarschijnlijk alles wat relevant is (hoge recall), maar het merendeel is irrelevant (lage precision). Een systeem dat slechts één passage ophaalt, heeft hoge precision als het de juiste pakt, maar mist relevante informatie uit andere bronnen (lage recall). De juiste balans vinden is een ontwerpkeuze.

Bij het accountantskantoor haalde de eerste versie zeven passages op per vraag. Gemiddeld waren twee of drie relevant. Na het terugbrengen van het aantal passages en het toevoegen van een herrangschikkingsstap die recente documenten voorrang gaf, steeg het aandeel relevante passages van ruwweg 30 naar meer dan 70 procent. De kwaliteit van de antwoorden verbeterde navenant.

Chunk-kwaliteit

De tweede laag: hoe zijn de documenten opgeknipt?

RAG werkt met passages, niet met volledige documenten. Een richtlijn van dertig pagina’s wordt opgesplitst in kleinere stukken, chunks, die elk apart doorzoekbaar zijn. Hoe die splitsing wordt gemaakt, bepaalt wat het systeem kan vinden.

Het accountantskantoor gebruikte aanvankelijk een standaardaanpak: elk document werd gesplitst in passages van ongeveer gelijke lengte, rond de vijfhonderd woorden. Overzichtelijk, systematisch, snel in te richten. Het probleem werd snel zichtbaar. Een vraag over btw-verlegging bij buitenlandse klanten vereiste zowel de algemene regel (die in één chunk zat) als de uitzonderingen voor specifieke landen (die in de volgende chunk waren terechtgekomen). Het systeem haalde de eerste chunk op maar niet de tweede. Het antwoord vermeldde de algemene regel correct en miste de uitzondering die van toepassing was. Technisch niet fout. Praktisch misleidend.

Na het herindelen van de richtlijnen op onderwerp, één chunk per fiscale regel inclusief alle relevante voorwaarden en uitzonderingen, werd de retrieval preciezer. Elke chunk bevatte een afgerond, zelfstandig stuk kennis. De chunks varieerden in lengte, van tweehonderd tot achthonderd woorden, afhankelijk van de complexiteit van de regel. Die variatie was een verbetering.

Metadata maakt chunks nog effectiever. Een chunk zonder metadata is niet meer dan een los stuk tekst. Een chunk mét metadata, zoals de afdeling die eigenaar is, de datum van de laatste update en het documenttype, kan worden gefilterd en gerangschikt. Het systeem kan worden ingesteld om recente documenten voorrang te geven boven oude, specifieke richtlijnen boven generieke samenvattingen, en gezaghebbende beleidsstukken boven informele notities.

Bronkwaliteit

De derde laag: hoe goed zijn de bronnen zelf?

RAG maakt bronnen toegankelijk. Het maakt ze niet beter. Vergelijk het met een archivaris die elk document terugvindt dat je vraagt, maar niet beoordeelt of de informatie erin nog geldig is. De archivaris doet precies waarvoor die is aangesteld. Het probleem zit in het archief.

Het accountantskantoor ontdekte dat hun SharePoint meerdere versies van hetzelfde declaratiebeleid bevatte. De oudste was uit 2019, de meest recente uit 2024. De limieten waren tussentijds twee keer aangepast. Het RAG-systeem behandelde alle versies als even geldig. Bij een vraag over de huidige declaratielimieten haalde het systeem soms de versie uit 2019 op. Het antwoord was overtuigend geformuleerd en verwees naar een bestaand intern document. Het bedrag week veertig procent af van de werkelijkheid.

Verouderde documenten zijn één probleem. Tegenstrijdige documenten zijn een ander. Wanneer twee afdelingen hetzelfde proces anders beschrijven, haalt het systeem passages op uit beide en genereert het een antwoord dat twee onverenigbare procedures samenvoegt tot één geheel. Het model heeft toegang tot de tekst, niet tot de organisatiecontext erachter. Het kan niet vaststellen welke versie gezaghebbend is.

De kennisbron onderhouden is geen IT-klus. Het is een kwaliteitsbeslissing. Verouderde documenten verwijderen, tegenstrijdigheden oplossen, per document vastleggen wie verantwoordelijk is voor de inhoud: dat zijn de acties die een bruikbaar RAG-systeem onderscheiden van een systeem dat overtuigend verkeerde antwoorden geeft.

Soms loont het om een stap verder te gaan: documenten verbeteren vóórdat ze aan het RAG-systeem worden gekoppeld. Een procesbeschrijving die in 2018 is geschreven voor een ander publiek, met onduidelijke koppen en verouderde verwijzingen, levert als RAG-bron zwakke chunks op. Diezelfde procesbeschrijving herschrijven in heldere secties met duidelijke afbakening per onderwerp, actuele informatie en consistente terminologie levert betere chunks op, betere retrieval en betere antwoorden. Die investering betaalt zich dubbel terug: het RAG-systeem presteert beter, én de documenten zijn ook voor medewerkers die ze direct lezen bruikbaarder geworden.

Wat er in de praktijk misgaat

De drie kwaliteitslagen verklaren waarom RAG tegenvalt. Maar zelfs organisaties die de juiste bronnen selecteren en zorgvuldig opknippen, struikelen over fouten die pas na de lancering zichtbaar worden.

De meest voorkomende: geen onderhoud en geen evaluatie. De twee treden vaak samen op. De kennisbron wordt ingericht bij de lancering en daarna raakt niemand die meer aan. Nieuwe documentversies worden geüpload zonder de oude te verwijderen. Tegelijk controleert niemand structureel of de antwoorden correct zijn. Na zes maanden trekt het systeem uit een groeiend archief van actuele en verouderde informatie, en geen mens die het merkt. Want een goed geformuleerd fout antwoord ziet er precies zo uit als een goed geformuleerd correct antwoord.

Een andere fout is subtieler: verwachten dat RAG de beperkingen van het model compenseert. RAG verandert welke informatie het model ontvangt. Het verandert niet wat het model met die informatie kan doen. Een model dat moeite heeft met genuanceerd redeneren, blijft daar moeite mee houden, ook met perfecte retrieval. RAG lost het kennisprobleem op. Het capaciteitsprobleem niet.

Hoe weet je of het werkt?

Een overtuigend fout antwoord voelt precies hetzelfde als een overtuigend correct antwoord. Je merkt het verschil niet door het systeem te gebruiken en te kijken of het goed aanvoelt. De enige betrouwbare methode is systematisch testen.

De gouden set

Het principe: stel een set samen van vragen die gebruikers daadwerkelijk stellen. Schrijf voor elke vraag het verwachte antwoord op basis van de actuele versies van de relevante brondocumenten. Voer de vragen door het systeem. Vergelijk de gegenereerde antwoorden met de verwachte antwoorden.

Die set, soms een gouden set genoemd, is de basislijn. Ze laat niet alleen zien of het systeem werkt, maar ook waar het faalt. Zijn de antwoorden fout omdat verkeerde passages werden opgehaald? Dan zit het probleem in de retrieval of de chunking. Werden de juiste passages opgehaald maar klopt het antwoord toch niet? Dan zit het probleem in hoe het model de context verwerkt. Dat onderscheid is belangrijk, want de oplossing is anders.

Testen, repareren, opnieuw testen

Het accountantskantoor stelde vijftig vragen samen uit daadwerkelijke medewerkervragen van het afgelopen jaar. Per vraag schreven ze het verwachte antwoord op basis van de actuele documenten. De eerste testronde onthulde dat ruwweg een derde van de antwoorden putte uit verouderde bronnen. Die bevinding leidde tot een opschoning van de kennisbron: oude versies werden verwijderd, actuele versies werden voorzien van metadata. De tweede testronde liet een duidelijke verbetering zien. De resterende fouten zaten vooral in gevallen waar de chunking te grof was, waar de relevante informatie verdeeld was over twee passages en slechts één werd opgehaald. Na het aanpassen van de chunking voor die documenten bevestigde een derde testronde dat het systeem de kwaliteitsdrempel haalde die het kantoor had gesteld.

Dat proces is geen eenmalige exercitie. Elke keer dat de kennisbron wezenlijk verandert, moet de gouden set opnieuw worden doorlopen. Elke keer dat de chunkingstrategie wordt aangepast, laat de test zien of de aanpassing hielp of schaadde. De discipline van systematisch testen maakt het verschil tussen een RAG-systeem dat werkt en een systeem dat lijkt te werken.

Een cyclus, geen installatie

RAG is een ontwerpcyclus. Bronnen selecteren. Documenten voorbereiden en opknippen. Indexeren in de vector database. Testen met echte vragen. De resultaten evalueren. Bijsturen waar de resultaten tekortschieten. Opnieuw beginnen.

Elke stap bevat beslissingen die de volgende stap beïnvloeden. Verkeerde bronnen koppelen vervuilt alles wat erna komt. Slecht opgesneden documenten maken goede informatie moeilijk vindbaar. Evaluatie overslaan betekent dat problemen zich onzichtbaar opstapelen tot ze op het verkeerde moment aan de oppervlakte komen.

De organisaties die het meeste waarde halen uit RAG behandelen het zoals ze elk kwaliteitskritisch proces behandelen: met doorlopende aandacht, duidelijke verantwoordelijkheden en regelmatige reviewcycli. De technologie is de enabler. De kwaliteit komt niet uit het model. Ze komt uit de beslissingen die eromheen worden genomen.

Voorbeelden

Hoe zien kwaliteitsproblemen eruit in de praktijk? Twee scenario’s die het patroon laten zien.

Medische kliniek

Neem een huisartsenpraktijk met zes huisartsen die het medicatieprotocol, de NHG-richtlijnen en het lokale formularium aan een RAG-systeem koppelt. Een arts vraagt of twee medicijnen samen voorgeschreven kunnen worden bij een oudere patiënt. Het systeem haalt de algemene interactierichtlijn op, die vermeldt dat de combinatie mogelijk is met monitoring. Het mist het praktijkspecifieke protocol dat een strengere doseringseis toevoegt voor patiënten boven de 75.

De oorzaak zit in de chunking: het leeftijdsspecifieke protocol maakt deel uit van een grote chunk die ook de pediatrische dosering omvat. De retrieval scoort de hele chunk als matig relevant in plaats van hoog relevant voor de specifieke leeftijdsgroep. Na het herindelen van de protocollen per patiëntcategorie en het toevoegen van leeftijdsgroep-metadata haalt het systeem consequent de leeftijdsspecifieke richtlijnen als eerste op. De arts neemt nog steeds de klinische eindbeslissing, maar de informatie die die beslissing ondersteunt is nu volledig.

Zelfstandig professional

Neem een zelfstandige organisatieadviseur die tien jaar aan projectverslagen, adviesdocumenten en methodiekbeschrijvingen heeft gekoppeld aan een RAG-systeem. Bij het voorbereiden van een offerte voor een klant in de financiële sector vraagt ze: welke aanpak heb ik eerder gebruikt bij vergelijkbare verandertrajecten in de financiële sector? Het systeem retourneert passages uit vijf eerdere projecten, waaronder twee uit de zorgsector die vergelijkbare veranderprocessen beschrijven maar in een totaal andere regelgevingscontext.

Het probleem is het ontbreken van sectormetadata. Het systeem haalt op basis van betekenisovereenkomst op, en “organisatorisch verandertraject” in de zorg en in de financiële sector lijkt semantisch op elkaar. Na het toevoegen van sectortags aan elk projectverslag en het filteren van retrieval op sector worden de resultaten scherp gericht. De adviseur ontvangt haar eigen methodiek voor trajecten in de financiële sector, niet een mix van aanpakken uit ongerelateerde domeinen.

Veelgestelde vragen

Hoe weet ik of een fout antwoord aan het model ligt of aan de retrieval?

Dat is te achterhalen door de stappen uit elkaar te trekken. De meeste RAG-systemen bieden de mogelijkheid om te zien welke passages zijn opgehaald voor een specifieke vraag. Bekijk die passages. Als de opgehaalde passages niet relevant zijn, of verouderd of tegenstrijdig, dan ligt het probleem bij de retrieval of de bronkwaliteit. Het model deed zijn werk correct op basis van wat het ontving, maar wat het ontving deugde niet. Als de passages wél relevant en actueel zijn maar het antwoord toch niet klopt, zit het probleem in hoe het model de context verwerkt. Dat kan wijzen op een te complex samenspel van passages, op onduidelijke formuleringen in de brondocumenten, of op een beperking van het model zelf. Het onderscheid is belangrijk, want de oplossing is fundamenteel anders. Een retrieval-probleem los je op door de chunking, metadata of bronkwaliteit aan te passen. Een generatieprobleem vraagt om een ander model, een aangepaste prompt, of beter geformuleerde brondocumenten.

Hoe vaak moet de kennisbron worden bijgewerkt?

Niet op een vast schema, maar op het ritme van de organisatie. De vraag is niet “hoe vaak” maar “wanneer verandert er iets dat ertoe doet?” Een organisatie waar beleidsdocumenten maandelijks worden bijgewerkt, heeft een ander onderhoudsritme nodig dan een organisatie waar richtlijnen eens per jaar veranderen. De vuistregel: elke keer dat een brondocument wordt gewijzigd, moet de oude versie in de kennisbron worden vervangen door de nieuwe. Dat klinkt vanzelfsprekend, maar in de praktijk gebeurt het zelden automatisch. Nieuwe versies worden toegevoegd, oude versies blijven staan. Na een half jaar bevat de kennisbron een mix van actuele en verouderde informatie, en het systeem kan het verschil niet zien. De oplossing is niet een kalender maar een proces: koppel het bijwerken van de kennisbron aan het documentbeheerproces dat de organisatie al heeft. Wanneer een richtlijn wordt gepubliceerd, wordt de kennisbron bijgewerkt. Wanneer een document wordt ingetrokken, wordt het verwijderd. Dat vereist dat iemand verantwoordelijk is voor de koppeling tussen het documentbeheer en de RAG-kennisbron.

Werkt RAG ook met rommelige of ongestructureerde documenten?

RAG kan technisch elke tekst verwerken, ongeacht de kwaliteit. Maar de kwaliteit van de output weerspiegelt de kwaliteit van de input. Rommelige documenten, denk aan inconsistente opmaak, onduidelijke koppen, tekst die over meerdere onderwerpen springt zonder duidelijke scheiding, leiden tot rommelige chunks. En rommelige chunks leiden tot onvoorspelbare retrieval. Het systeem haalt passages op die gedeeltelijk relevant zijn, of die twee onderwerpen mengen, of die context missen doordat de scheiding op de verkeerde plek viel. Het resultaat: antwoorden die half kloppen of die informatie uit twee contexten onbedoeld samenvoegen. RAG is in dat opzicht een vergrootglas voor de kwaliteit van je documentatie. Organisaties die starten met RAG, ontdekken vaak dat hun documentatie minder gestructureerd is dan ze dachten. Dat is op zichzelf al een waardevolle bevinding. Wie de bronnen eerst opschoont en herstructureert voordat ze aan het systeem worden gekoppeld, begint met een voorsprong die in elk antwoord doorwerkt.

Moet ik technische kennis hebben om te evalueren of mijn RAG-systeem goed werkt?

Voor het samenstellen en beoordelen van een gouden set niet. Je hebt inhoudelijke kennis nodig. Wie de brondocumenten kent en weet welke antwoorden correct zijn, kan beoordelen of het systeem de juiste informatie ophaalt en de juiste antwoorden genereert. De vragen in de gouden set komen van de mensen die het systeem dagelijks gebruiken. De verwachte antwoorden worden opgesteld door de inhoudelijk deskundigen die de brondocumenten beheren. De vergelijking tussen verwacht en gegenereerd antwoord is een inhoudelijke toets, geen technische. Wat wél technische kennis vraagt, is het diagnosticeren en oplossen van de problemen die de evaluatie aan het licht brengt. Wanneer de retrieval verkeerde passages ophaalt, moet iemand met technische expertise de chunkingstrategie, de embeddingkwaliteit of de herrangschikking aanpassen. De evaluatie zelf is het gesprek tussen de inhoudelijk deskundige en het technische team: de eerste beoordeelt of de antwoorden kloppen, de tweede weet waar de knoppen zitten om de kwaliteit te verbeteren.

Verder lezen

Wie wil begrijpen hoe het RAG-proces technisch werkt, hoe een vraag wordt omgezet naar een embedding, hoe de vector database de best passende passages vindt, en hoe het model op basis daarvan een antwoord genereert, leest verder bij Wat is RAG en hoe werkt het? (5.2a).

Wie wil weten wanneer RAG de juiste keuze is voor een organisatie en hoe het zich verhoudt tot alternatieven als search en grote context windows, leest verder bij RAG: organisatiekennis koppelen (5.2).

Wie meer wil begrijpen over het systematisch evalueren van AI-output, bij RAG en bij elk ander AI-systeem dat betrouwbare resultaten moet leveren, vindt dat bij Evaluatie van AI-output (9.1).