Hoeveel documenten heb je nodig voordat RAG zin heeft?

Er is geen vast minimumaantal documenten waarbij RAG ineens zinvol wordt. De echte vraag is of het goedkoper, sneller en betrouwbaarder is om documenten gewoon direct te openen, te doorzoeken of in de context van een taalmodel te plaatsen, dan om een retrieval-pipeline te bouwen en te onderhouden. Bij een handvol relatief korte documenten wint eenvoud vaak.

Als vijf documenten samen probleemloos in het bruikbare contextvenster van een model passen en de inhoud nauwelijks verandert, kan het bijvoorbeeld efficiënter zijn om ze rechtstreeks mee te geven. RAG wordt interessanter zodra de hoeveelheid informatie niet meer praktisch in één prompt past, documenten regelmatig veranderen, meerdere gebruikers dezelfde kennisbank moeten doorzoeken of antwoorden controleerbaar naar specifieke bronnen moeten verwijzen.

Het aantal documenten zegt minder dan je denkt

Documentaantallen zijn een slechte maat voor de omvang van een RAG-systeem. Eén technisch handboek van honderden pagina's kan meer retrieval vereisen dan honderd korte FAQ-documenten. Omgekeerd kunnen tientallen vrijwel identieke documenten zo veel overlap bevatten dat een zoekindex nauwelijks extra informatiewaarde oplevert.

Belangrijker is de totale hoeveelheid relevante tekst. Daarbij telt niet alleen wat technisch in het maximale contextvenster van een model past. Een contextvenster volledig vullen met documenten is zelden ideaal. Er moet ruimte overblijven voor de systeemprompt, de vraag van de gebruiker, eerdere conversatie en het uiteindelijke antwoord.

Bovendien wordt een groot contextvenster niet automatisch een goede zoekmachine. Naarmate meer tekst tegelijk wordt aangeboden, moet het model zelf bepalen welke passages relevant zijn. Retrieval probeert dat probleem vóór de generatie op te lossen: eerst worden de meest relevante delen geselecteerd, daarna krijgt het taalmodel alleen die passages.

Daarom kan RAG al bij relatief weinig grote documenten logisch zijn, terwijl honderden kleine documenten soms nog prima met eenvoudigere zoektechnieken kunnen worden afgehandeld.

Wanneer gewoon plakken beter werkt

Voor kleine, stabiele documentverzamelingen is een RAG-pipeline vaak onnodige infrastructuur. Stel dat een medewerker incidenteel vragen stelt over enkele beleidsdocumenten, handleidingen of contracttemplates. Als die documenten samen ruim binnen de praktische contextlimiet vallen, kun je ze rechtstreeks aan het model meegeven.

Dat heeft voordelen. Je hebt geen vectorindex nodig, hoeft geen embeddings te genereren en hoeft niet te bepalen hoe documenten in chunks worden verdeeld. Ook voorkom je retrieval-fouten waarbij juist de relevante passage niet wordt opgehaald.

Een bruikbare vuistregel is daarom: als alle relevante informatie voor een typische vraag eenvoudig tegelijk kan worden meegestuurd en de documenten weinig veranderen, begin dan niet automatisch met RAG. Voor een corpus van enkele korte documenten is handmatig selecteren of een eenvoudige full-textzoekfunctie vaak voldoende. Zelfs bij enkele tientallen documenten kan dat nog gelden als gebruikers maar af en toe zoeken en gemakkelijk kunnen bepalen welk document relevant is.

RAG wordt interessant wanneer contextselectie nodig wordt

Het omslagpunt ontstaat meestal wanneer je niet meer alle potentiële bronnen tegelijk wilt of kunt meesturen. Vanaf dat moment moet ergens worden bepaald welke informatie relevant is voor de vraag.

Dat is precies wat de retrieval-stap doet. Documenten worden vooraf geïndexeerd en bij een vraag worden relevante passages gezocht. Alleen die passages gaan naar het taalmodel.

Een praktische drempel is bereikt wanneer de totale documentverzameling structureel groter is dan de hoeveelheid tekst die je redelijkerwijs per vraag in het contextvenster wilt stoppen. Dat kan bij tien zeer lange documenten al gebeuren, maar bij honderden korte records nog steeds niet. Kijk daarom liever naar corpusomvang dan naar bestandenaantallen. Zodra je bij vrijwel iedere vraag eerst handmatig moet bedenken welke documenten moeten worden meegestuurd, begint retrieval operationele waarde te krijgen.

Veranderende informatie maakt RAG eerder aantrekkelijk

Documentgrootte is niet de enige factor. De veranderingssnelheid van de informatie kan minstens zo belangrijk zijn.

Een verzameling van twintig documenten die iedere week wordt aangepast, kan een betere RAG-kandidaat zijn dan een archief van tweehonderd documenten dat vrijwel nooit verandert. Bij een goed ingerichte pipeline kunnen gewijzigde documenten opnieuw worden verwerkt en geïndexeerd, zodat volgende zoekopdrachten de actuele versie gebruiken.

Zonder retrieval ontstaat al snel een praktisch probleem: welke documentversie stuur je naar het model en hoe zorg je dat iedere gebruiker steeds dezelfde actuele informatie krijgt? RAG lost dat niet automatisch op — je moet nog steeds versiebeheer, synchronisatie en indexering regelen. Maar zodra die processen toch noodzakelijk worden, kan een centrale retrievallaag aantrekkelijker worden dan telkens losse bestanden in prompts verwerken.

Meerdere gebruikers veranderen de rekensom

Voor één medewerker die af en toe informatie zoekt, mag een proces relatief handmatig zijn. Voor tientallen medewerkers die dezelfde documentcollectie doorzoeken, wordt dat snel onpraktisch.

Een centrale RAG-laag maakt het mogelijk om dezelfde geïndexeerde kennisbron vanuit meerdere applicaties of gebruikerssessies te raadplegen. Je kunt bovendien toegangsrechten, logging en bronverwijzingen op één plek organiseren.

Ook hier is het aantal documenten niet doorslaggevend. Tien belangrijke procedures die dagelijks door veel medewerkers worden geraadpleegd kunnen meer aanleiding geven voor een centrale retrieval-oplossing dan duizend archiefdocumenten waar bijna nooit iemand naar zoekt. Gebruikfrequentie hoort daarom bij dezelfde afweging als corpusomvang.

Bronvermelding en audit kunnen op zichzelf reden genoeg zijn

RAG wordt vaak gezien als techniek om grote hoeveelheden tekst beheersbaar te maken, maar retrieval heeft nog een andere functie: het antwoord koppelen aan concrete bronnen.

Voor toepassingen waarin gebruikers moeten kunnen controleren waar een antwoord vandaan komt, wil je idealiter vastleggen welke passages zijn opgehaald. Het systeem kan vervolgens bronverwijzingen naar documenten, pagina's of secties tonen. Dat is vooral relevant wanneer antwoorden gevolgen hebben voor bedrijfsprocessen of wanneer achteraf moet kunnen worden onderzocht waarom een antwoord is gegeven.

Ook een klein corpus kan daardoor RAG rechtvaardigen. Als vijf interne richtlijnen intensief worden bevraagd en ieder antwoord aantoonbaar naar de onderliggende passage moet verwijzen, kan retrieval nuttiger zijn dan simpelweg alle vijf documenten in een prompt zetten — hetzelfde principe achter RAG zonder hallucinatie.

RAG heeft zelf onderhoudskosten

Een RAG-systeem is geen eenmalige indexeeractie. Documenten moeten worden ingelezen, opgeschoond, opgedeeld en opnieuw geïndexeerd wanneer ze veranderen.

Ook de chunking-strategie vraagt aandacht. Te grote chunks leveren veel irrelevante context op. Te kleine chunks kunnen informatie uit elkaar trekken die inhoudelijk bij elkaar hoort. Tabellen, koppen, voetnoten en documentstructuren kunnen bovendien speciale verwerking vereisen.

Daar komt monitoring bij. Je moet kunnen zien of de retrieval daadwerkelijk de juiste passages vindt. Een antwoord kan immers fout zijn terwijl het taalmodel perfect functioneert, simpelweg omdat de zoeklaag de verkeerde context heeft aangeleverd. Die overhead is precies waarom RAG bij een kleine, statische documentcollectie vaak niet de beste eerste stap is.

Praktische vuistregels

Een absolute grens zoals "vanaf twintig documenten heb je RAG nodig" bestaat niet. Wel kun je enkele praktische beslisregels gebruiken.

Als een corpus uit ongeveer één tot vijf korte, stabiele documenten bestaat en incidenteel wordt geraadpleegd, is RAG meestal moeilijk te rechtvaardigen. Directe context, handmatige selectie of traditionele zoekfunctionaliteit is eenvoudiger. Bij tientallen documenten moet je vooral naar lengte en gebruik kijken: tien omvangrijke handleidingen kunnen retrieval al noodzakelijk maken, terwijl vijftig korte pagina's nog probleemloos zonder vectorzoekmachine te beheren kunnen zijn.

Een nuttiger technische grens is het contextbudget. Zodra het relevante corpus structureel groter is dan wat je per vraag verantwoord aan het model wilt aanbieden, is retrieval het onderzoeken waard. Hetzelfde geldt zodra gebruikers regelmatig eerst documenten moeten zoeken voordat zij hun vraag aan het model kunnen stellen. Bij vaak veranderende content, veel gelijktijdige gebruikers of een harde eis voor bronvermelding kan RAG bovendien al bij een relatief kleine collectie rendabel zijn.

Conclusie

Je hebt geen minimaal aantal documenten nodig voordat RAG zin heeft. Bij een handvol korte, stabiele documenten is rechtstreeks zoeken of de volledige tekst aan een model meegeven meestal eenvoudiger. RAG wordt vooral interessant wanneer de informatie te groot wordt voor praktische directe context, regelmatig verandert, door meerdere gebruikers moet worden geraadpleegd of controleerbare bronverwijzingen vereist. De juiste drempel wordt daarom bepaald door omvang, documentstructuur, veranderingssnelheid en gebruikspatroon — niet door het aantal bestanden alleen.