RAG testen: zo test je een AI-assistent die antwoordt uit je eigen documenten

RAG testen: zo test je een AI-assistent die antwoordt uit je eigen documenten

In het kort: Bij RAG testen controleer je een AI-assistent die eerst in je eigen documenten zoekt. Daarna schrijft hij een antwoord uit wat hij vond. De meeste fouten zitten in die zoekstap. Hij vindt een verkeerd of verouderd document, een half stuk tekst, of een document dat de gebruiker niet mag zien. Test het zoeken en het antwoord apart, en test opnieuw zodra je documenten veranderen.

Geeft een AI-assistent die uit je eigen documenten antwoordt een fout antwoord, dan krijgt het model de schuld. Meestal deed het model gewoon zijn werk. Het schreef een prima antwoord, alleen van de verkeerde pagina. Daarom begint RAG testen bij het deel dat de meeste teams overslaan: wat vond de assistent voordat hij antwoordde? Test je alleen de eindantwoorden, dan zie je dat er iets mis is, maar niet waar.

Wat is RAG, en waar gaat het mis?

RAG staat voor retrieval-augmented generation, vrij vertaald: antwoorden genereren op basis van opgezochte informatie. Lewis en anderen beschreven het idee in 2020. Een RAG-assistent werkt in twee stappen. Eerst zoekt hij in een verzameling documenten naar stukken tekst die bij de vraag passen. Daarna geeft hij die stukken aan een taalmodel, dat er het antwoord uit schrijft. Bedrijven gebruiken het voor intranetassistenten, klantenservicebots en hulp voor medewerkers bij beleid of productinformatie. In de zoekstap gaat het meeste mis. De assistent vindt het juiste document helemaal niet. Of hij vindt de versie van vorig jaar in plaats van die van dit jaar. Documenten worden vooraf in kleine stukjes geknipt, dus hij kan een half stuk vinden en de uitzondering in het volgende stukje missen. Hij kan een document vinden dat de gebruiker niet mag zien. Of hij vindt niets bruikbaars en antwoordt toch. Elk van die fouten kan een antwoord opleveren dat heel zeker klinkt.

Hoe test je de zoekstap?

Je test de zoekstap met een set echte vragen, en per vraag schrijf je op welk stuk tekst hij moet vinden. Daarna controleer je of dat stuk tussen de resultaten zit die de assistent gebruikt. Zo weet je of een fout antwoord begon met een foute zoekopdracht. Je ziet ook of een aanpassing aan de zoekinstellingen het beter of slechter maakte. De tabel zet de belangrijkste fouten op een rij, met hoe je ze test.

Fout Voorbeeld Zo test je het
Verkeerd of geen document. Een vraag over reiskosten vindt het vakantiebeleid. Leg per vraag het juiste stuk vast en controleer of het gevonden wordt.
Verouderde versie. De prijslijst van vorig jaar wordt gebruikt in plaats van de nieuwe. Zet oude en nieuwe versies in de testset en verwacht de nieuwste.
Half stuk tekst. De regel wordt gevonden, de uitzondering in het volgende stukje niet. Voeg vragen toe waarvan het antwoord van een uitzondering afhangt.
Toegangsrechten. Een medewerker krijgt antwoord uit een document voor managers. Stel dezelfde vragen als gebruikers met verschillende rollen.
Niets relevants. Een vraag over iets wat niet in de documenten staat. Verwacht een duidelijk “dat weet ik niet” en een route naar een mens.

Toegangsrechten verdienen extra aandacht. Houdt de zoekstap geen rekening met wie de vraag stelt, dan kan de assistent informatie lekken naar mensen die die nooit mogen zien. OWASP noemt dit risico onder vector and embedding weaknesses in zijn top 10 voor LLM-toepassingen. Test het met echte rollen, niet alleen met een beheerdersaccount.

Hoe test je het antwoord zelf?

Je test het antwoord door te controleren of elke bewering erin gedekt wordt door de stukken die de assistent vond. Een goed antwoord voegt niets toe wat niet in de bronnen staat. Toont het bronnen, dan moet elke bron bestaan en zeggen wat het antwoord beweert. Geven de gevonden stukken geen antwoord op de vraag, dan moet de assistent dat zeggen in plaats van het gat op te vullen. Stel elke vraag meer dan één keer, want de formulering verschilt per keer. Software met AI erin geeft niet altijd hetzelfde antwoord, dus een simpel goed of fout is niet genoeg. Daar weten we mee om te gaan, en zo beoordelen we ook elk antwoord.

Een deel van de controle kun je automatiseren, maar mensen blijven erbij betrokken. De collega’s die de documenten beheren, weten het best of een antwoord klopt. Laat hen elke ronde een steekproef beoordelen, vooral bij onderwerpen met echt risico, zoals prijzen, contracten of HR-regels. Documenten kunnen ook verborgen instructies bevatten die de assistent willen sturen. Dat is een beveiligingsonderwerp op zich, dus houd het op je lijst.

Wanneer test je opnieuw?

Test opnieuw zodra je documenten, toegangsrechten of zoekinstellingen veranderen, niet alleen als het model verandert. Dat is het grote verschil met andere AI-tests. Een nieuw beleid, een verwijderd productblad of aangepaste rechten op een map kunnen antwoorden van de ene op de andere dag veranderen. Misschien weet niemand bij IT er zelfs van. Behandel je vragenset daarom als een regressietest. Draai hem na elke import van documenten en voor elke release, en kijk naar zowel de zoekresultaten als de antwoorden.

Na livegang stellen echte gebruikers vragen die je set niet dekt. Blijf hun vragen en de antwoorden volgen, en voeg nieuwe gevallen toe aan de set. Zulk AI testen na livegang gaat in vijf stappen, van de vragen kiezen tot de uitkomsten rapporteren. Het hoort bij een bredere verschuiving in AI testen: AI testen is doorlopend werk.

Eén kanttekening: je kunt niet elke mogelijke vraag testen. Richt je op de onderwerpen waar een fout antwoord het meeste pijn doet. Een interne assistent voor kantoorvragen heeft een lichtere set nodig dan een assistent die klanten over hun contract informeert.

Wat betekent dit voor je team?

De documenten achter een RAG-assistent veranderen elke week, en de meeste zijn van mensen buiten IT. Elke wijziging kan ongemerkt een antwoord breken dat gisteren nog werkte. Testen is hier dus doorlopend werk, geen controle voor de lancering. Iemand moet de vragenset actueel houden, hem na elke wijziging draaien en de uitkomsten rapporteren, zodat documenteigenaren iets kunnen doen. In veel teams heeft niemand die taak.

Onze eigen tool VeritasAI is gebouwd voor dit soort doorlopend testen, en we gebruiken hem om AI testen als dienst te leveren. Hij blijft je AI-toepassing testen met echte vragen. Een operationeel dashboard laat zien welke vragen falen, en aan welke wet, regel of welk framework elke fout raakt. Je ziet de prompt, het antwoord en een prioriteitsscore. Een managementdashboard laat het totaalbeeld zien.

Een eerste stap voor deze week: kies de tien vragen die je assistent het vaakst krijgt. Schrijf per vraag op in welk document en welk stuk tekst het antwoord staat. Controleer daarna of de assistent dat stuk echt vindt.

Houd je documentassistent betrouwbaar, ook als de documenten veranderen.

Zo testen wij AIPraat met ons team

Veelgestelde vragen

Wat is het verschil tussen RAG testen en het model testen?

Bij het model testen kijk je hoe goed het antwoorden schrijft. Bij RAG testen controleer je ook wat de assistent in je documenten vond voordat hij antwoordde. Daar beginnen de meeste fouten.

Hoe test je toegangsrechten in een RAG-assistent?

Stel dezelfde vragen terwijl je bent ingelogd als gebruikers met verschillende rollen. Controleer dat elke gebruiker alleen antwoorden krijgt uit documenten die hij mag openen.

Hoe vaak test je een RAG-assistent opnieuw?

Na elke wijziging aan de documenten, toegangsrechten, zoekinstellingen of het model, en voor elke release. Na livegang blijf je echte vragen volgen.

Kun je RAG testen automatiseren?

Grotendeels. De vragenset, de controle op gevonden stukken en een deel van de beoordeling van antwoorden kun je automatiseren. Experts blijven een steekproef beoordelen, omdat zij weten wat echt klopt.