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.
Roland Bieleveldt
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Hoe zien kwaliteitsproblemen eruit in de praktijk? Twee scenario’s die het patroon laten zien.
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.
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.
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).