De kennis is er. Ze staat in rapporten, handleidingen, beleidsdocumenten, contracten, verslagen van vergaderingen en in tientallen mappen op de netwerkschijf. En toch kost het een nieuwe medewerker drie uur om het antwoord te vinden op een vraag die een ervaren collega in dertig seconden beantwoordt, simpelweg omdat die collega weet waar ze moet zoeken. Dat kennismonopolie is kwetsbaar. Mensen vertrekken, worden ziek, zijn druk of onbereikbaar. En intussen is de organisatie afhankelijk van wie toevallig precies de juiste map op zijn scherm heeft staan.
Precies dit probleem lost een kennisbank-agent op basis van RAG op. Maar wat is RAG eigenlijk?
Wat doet een gewone AI met een vraag?
Een groot taalmodel, zoals de AI achter ChatGPT of vergelijkbare tools, is getraind op een enorme hoeveelheid tekst van het publieke internet. Dat maakt het indrukwekkend veelzijdig. Maar die training heeft een harde grens: er zit een datum op, en de AI heeft nooit toegang gehad tot jouw interne documenten, contracten of procedures.
Vraag je zo'n model naar iets wat buiten die trainingsdata valt, bijvoorbeeld een specifieke cao-bepaling, de meest recente versie van een intern bouwprotocol of de voorwaarden in een leverancierscontract, dan doet het iets dat "hallucineren" wordt genoemd. Het model weet het antwoord niet, maar gedraagt zich alsof het dat wel doet. Het formuleert een plausibel klinkend antwoord dat technisch nergens op slaat. Niet omdat het slecht is, maar omdat dit nu eenmaal is hoe een taalmodel werkt: het voorspelt welke woorden logisch op elkaar volgen, op basis van statistiek en niet op basis van feitelijke verificatie.
Voor een willekeurige schrijfopdracht is dat acceptabel. Voor een medewerker die een beleidsregel opzoekt, een jurist die een contractclausule controleert of een inkoper die leveranciersafspraken wil raadplegen, absoluut niet.
Wat RAG anders doet
RAG staat voor Retrieval-Augmented Generation: ophalen, dan pas genereren. In plaats van het taalmodel meteen op een vraag te laten antwoorden, wordt er eerst gezocht in een eigen documentbase. De meest relevante tekstfragmenten worden opgehaald en samen met de vraag aan het model meegegeven. Pas dan formuleert het een antwoord, en het baseert zich daarbij uitsluitend op die opgehaalde fragmenten.
Denk aan het verschil tussen een bibliothecaris die eerst de relevante pagina opzoekt voordat zij antwoord geeft, en iemand die puur op geheugen antwoordt. De eerste kan haar bronnen aanwijzen. De tweede verzint soms iets dat aanvoelt als een herinnering, maar dat de plank volledig misslaat. RAG is die bibliothecaris: het zoekt eerst, en genereert daarna.
Concreet: een medewerker vraagt aan de kennisbank-agent "Wat zijn de regels rondom opzegtermijnen in ons standaard leverancierscontract?" Een gewone AI geeft een generiek juridisch antwoord op basis van algemene contractenrecht. Een RAG-systeem haalt de exacte clausule op uit het bewuste contract, toont de relevante passage en formuleert op basis daarvan een antwoord, inclusief vermelding welk document het betrof.
Hoe vector search werkt (simpel uitgelegd)
Klassiek zoeken werkt op trefwoorden: je zoekt het woord "opzegtermijn" en de zoekmachine vindt alleen documenten die dat exacte woord bevatten. Staat er "beëindigingsperiode" of "contractduur bij annulering"? Dan wordt het document niet gevonden, ook al heeft het precies de informatie die je zoekt.
Vector search denkt in betekenis in plaats van in letters. Elk document, of preciezer elk fragment van een document, wordt omgezet in een lange reeks getallen die de betekenis van die tekst vastlegt. Dat heet een embedding. Stukken tekst met een vergelijkbare betekenis krijgen embeddings die dicht bij elkaar liggen in een wiskundige ruimte. Als een medewerker een vraag stelt, wordt die vraag op dezelfde manier omgezet, en zoekt het systeem de fragmenten op waarvan de betekenis het dichtst aansluit bij die van de vraag.
Het resultaat is een zoekmachine die begrijpt dat "wanneer kunnen wij het contract beëindigen" en "opzegtermijn leverancier" naar hetzelfde verwijzen, ook als die woorden letterlijk niet voorkomen in het document waar het antwoord staat. Voor grote documentbases, waarvan de tekst niet uniform is opgesteld, is dit een fundamentele verbetering ten opzichte van traditioneel zoeken.
Wanneer is RAG zinvol voor jouw organisatie?
RAG ontwikkelt zijn kracht pas boven een bepaalde schaal. Als het gaat om duizenden documenten die continu groeien, ongestructureerd zijn, en waarbij je niet vooraf kunt bepalen welke stukken relevant zijn voor een specifieke vraag, dan is RAG de aangewezen aanpak.
Concrete situaties waarin RAG evident meerwaarde biedt: een bouworganisatie met tienduizenden technische specificaties, veiligheidsinstructies, gemeentelijke bestemmingsplannen en aanbestedingsdocumenten; een gemeente met honderden beleidsnota's, raadsbesluiten en uitvoeringsplannen; een juridische afdeling met omvangrijke contractportefeuilles; een zorginstelling met een grote bibliotheek aan richtlijnen, protocollen en dossiers.
Een sterk signaal dat RAG zinvol is, zijn vragen als: "Waar staat ook alweer de uitzondering op de garantieregeling?", "Wat zegt ons arbobeleid precies over thuiswerken bij zwangerschap?", of "In welk van onze 47 raamwerkcontracten staat een prijsherzieningsclausule?" Dat zijn vragen waarbij een medewerker anders uren kwijt is aan handmatig zoeken, en waarbij het antwoord feitelijk ergens in de documenten staat, maar de toegang tot die kennis de bottleneck is.
Wanneer is RAG overdreven?
Het is eerlijk om te zeggen: RAG is niet voor iedereen de juiste keuze, en het is niet goedkoop. Wie twintig of dertig overzichtelijke documenten heeft die zelden veranderen, doet er beter aan om een eenvoudigere aanpak te gebruiken: de volledige context direct meesturen aan het taalmodel, zonder tussenliggende zoekstap.
Bij kleine documentbases doet RAG namelijk iets onverwachts: de retrieval-stap mist soms het meest relevante fragment, juist omdat de tekst niet altijd zo gestructureerd is dat de semantisch meest vergelijkbare passage ook de meest informatieve is. Een medewerker die vraagt naar de marge op type B-opdrachten krijgt dan mogelijk algemene tekst over marges terug in plaats van het juiste document. Eenvoudiger aanpakken zijn dan nauwkeuriger, goedkoper en makkelijker te onderhouden.
De vuistregel: bij een paar honderd documenten of minder, beginnen met een eenvoudigere aanpak. RAG rechtvaardigt zijn complexiteit pas wanneer de schaal dat vereist: duizenden documenten die continu groeien en niet meer in één contextvenster passen.
Wat bronfragmenten betekenen voor vertrouwen en compliance
Een bijkomend voordeel van RAG dat in de praktijk doorslaggevend blijkt voor organisaties met compliance-eisen: het systeem toont zijn bronnen. Bij elk antwoord kunnen de exacte fragmenten worden weergegeven waarop het antwoord is gebaseerd, inclusief documentnaam, paginanummer en de letterlijke tekst.
Dat is een kwalitatieve sprong ten opzichte van een gewoon taalmodel, dat simpelweg niet kan aangeven waar zijn antwoord vandaan komt, omdat het antwoord opgebouwd is uit statistische patronen en niet uit herleidbare bronnen. Voor organisaties in de bouw, overheid, zorg of financiën, waar besluiten aantoonbaar onderbouwd moeten worden, is dat een fundamenteel verschil.
Neem het voorbeeld van een inkoopmanager die wil weten of een leverancierscontract een escalatieprocedure bevat. Met een RAG-systeem krijgt hij niet alleen "ja, dat staat er" als antwoord, maar ook de exacte clausule uit het exacte document, zodat hij zelf kan beoordelen of de interpretatie klopt. Dat is het verschil tussen een AI die adviseert en een AI die bronvermelding levert, en in professionele omgevingen is dat laatste de enige acceptabele standaard.
Tegelijkertijd is eerlijkheid op zijn plaats: RAG vermindert hallucinaties sterk, maar elimineert ze niet volledig. Als de retrieval-stap een irrelevant fragment ophaalt, bouwt het model daar alsnog op verder. De kwaliteit van een RAG-systeem hangt voor een groot deel af van hoe goed de documenten zijn geïndexeerd, hoe slim de fragmenten zijn afgebakend, en hoe zorgvuldig het systeem is opgezet. RAG is een solide architectuur, geen magische oplossing die slechte bronkwaliteit compenseert.
Bouwend Nederland: van document naar inzicht
Een concreet voorbeeld van RAG in de praktijk is de kennisbank-tool die NewWorks ontwikkelde voor Bouwend Nederland. De organisatie werkt met grote hoeveelheden documentatie: partijplannen, beleidsstukken, rapporten en memo's. De informatie stond er bijna altijd in, maar vinden ging langzaam, zeker wanneer meerdere documenten tegelijk op dezelfde vragen vergeleken moesten worden.
NewWorks ontwikkelde een tool die die documenten indexeert in een vector database en bevraagbaar maakt in natuurlijke taal. Het bijzondere zit hem in de zogenoemde uitvraagmatrix: een tabelvorm waarbij elke rij een onderwerp is (arbeidsmarkt, stikstof, woningbouw) en elke kolom een focuspunt (standpunt, concrete maatregel, onderbouwing). Zo kunnen tientallen documenten tegelijk worden uitgevraagd, gestructureerd en herhaalbaar, met bronfragmenten als bewijs bij elke uitkomst.
Het resultaat: wat voorheen uren handmatig samenvatten kostte, wordt in minuten een vergelijkbaar overzicht dat direct bruikbaar is voor besluitvorming, zonder dat de analist het contact met de bronnen verliest.
NewWorks bouwt kennisbank-agents op basis van RAG voor Nederlandse organisaties die hun documentkennis willen ontsluiten. In de kennisbank-agent track begeleidt NewWorks organisaties van eerste verkenning tot een werkend systeem: van indexering en vectorisering van de bestaande documentbase tot een agent die medewerkers direct, controleerbaar en met bronvermelding van antwoord voorziet. De Bouwend Nederland case illustreert hoe deze aanpak er in de praktijk uitziet: van groot documentarchief naar gestructureerde beslislaag in één tool.
Benieuwd hoe dit voor jou werkt?
Plan een kennismaking
