Een RAG-proef slaagt niet omdat een paar antwoorden tijdens de presentatie goed klinken. Je wilt weten of de toepassing de benodigde informatie vindt, de voorwaarden correct uitlegt en grenzen bewaart wanneer een antwoord ontbreekt of toegang niet is toegestaan. Dat zijn verschillende vragen waarvoor je afzonderlijk bewijs nodig hebt. Een gemiddelde tevredenheidsscore kan belangrijke fouten verbergen.
Deze gids beschrijft hoe je een beperkte maar bruikbare evaluatie voorbereidt. De vragen en beoordelingsvoorbeelden zijn illustratief. De methode levert geen universeel kwaliteitspercentage of certificering op; zij helpt je een concrete bronverzameling en taak gericht onderzoeken en verbeteren.
Leg eerst vast welke taak je beoordeelt
Omschrijf wie de gebruiker is, welke informatie hij nodig heeft en welke vervolgstap een antwoord ondersteunt. Een interne assistent die een handleiding helpt vinden vraagt andere criteria dan een voorziening die meerdere beleidsstukken samenvat. Zonder die taakgrens wordt iedere mooie demonstratie een mogelijk succes, ook wanneer de uitkomst weinig zegt over het werk waarvoor de toepassing wordt gebouwd.
Beschrijf ook wat de eerste versie niet hoort te doen. Een proef met productinformatie hoeft geen persoonlijke klantdossiers te beoordelen. Een antwoord over een bekende productserie hoeft onbekende varianten niet af te dekken. Gebruik de grenzen als onderdeel van de beoordeling. Een juiste verwijzing of gerichte verduidelijkingsvraag kan voor zo'n geval de gewenste uitkomst zijn.
Verzamel vragen uit echt werk zonder onnodige persoonsgegevens
Vraag medewerkers welke vragen regelmatig terugkomen en welke uitzonderingen tot twijfel leiden. Maak van die situaties neutrale toetsgevallen met voldoende context om de inhoud te beoordelen. Vervang namen en andere niet-noodzakelijke details door fictieve waarden. Het doel is representativiteit van de taak, niet een zo groot mogelijke verzameling volledige gesprekken.
Bewaar bij ieder geval waarom het belangrijk is. Een veelgestelde eenvoudige vraag kan relevant zijn voor efficiëntie; een zeldzame uitzondering kan belangrijk zijn vanwege de gevolgen van een verkeerd antwoord. Beide verdienen een plaats, maar hoeven niet met hetzelfde gewicht te worden besproken. Maak die afweging zichtbaar in plaats van een willekeurig gemiddelde als objectief besluit te presenteren.
Schrijf verwachte ondersteuning en open punten op
Leg per vraag vast welke bronpassage een inhoudelijk beoordelaar verwacht. Noteer de relevante versie, voorwaarden en informatie die de gebruiker nog moet aanleveren. Vermijd een toets die alleen controleert of de gegenereerde zin op een voorbereid modelantwoord lijkt. Andere woorden kunnen dezelfde betekenis hebben, terwijl een bijna identieke zin toch een beslissende uitzondering mist.
Bij een vraag over een onderhoudstermijn kan de verwachte ondersteuning een specifieke productbijlage zijn. Bij een vraag zonder productvariant kan juist een vervolgvraag nodig zijn. Schrijf beide verwachtingen vóór de proef op. Dat vermindert de neiging een opvallend antwoord achteraf als passend te verklaren zonder dezelfde maatstaf op minder fraaie uitkomsten toe te passen.
Verbind de testresultaten aan expliciete opleverafspraken en een besluit over de eerste ingebruikname: Maatwerksoftware accepteren: beoordeel complete taken en afgesproken grenzen.
Beoordeel terugvinden los van formuleren
Controleer eerst of de zoekstap de vereiste bron met voldoende context aanlevert. Noteer ontbrekende passages, verkeerde versies en onbruikbaar opgesplitste tabellen. Beoordeel daarna of het antwoord de relevante claims correct weergeeft. Zo ontstaat een diagnose waarmee een ontwikkelaar gericht kan verbeteren in plaats van alleen het algemene signaal dat de AI niet goed werkt.
Een fictief serviceteam krijgt een verkeerd interval te zien. In het eerste geval is de juiste bijlage nooit gevonden; in het tweede geval is die wel gevonden maar negeert het antwoord een voorwaarde. Beide vragen een andere aanpassing. Als je alleen het eindantwoord als fout registreert, raak je het onderscheid kwijt dat het onderzoek juist praktisch bruikbaar maakt.
| Waarneming | Onderzoek apart | Mogelijke vervolgstap |
|---|---|---|
| Benodigde passage ontbreekt | Bronselectie en retrieval | Bron toevoegen of zoekontwerp aanpassen |
| Juiste passage, verkeerde claim | Voorwaarden en antwoordgedrag | Uitleg of controlegrens verbeteren |
| Verkeerde gebruiker ziet informatie | Rechten en hergebruik | Selectie en intrekking onderzoeken |
| Tegenstrijdige bronnen | Inhoudelijke geldigheid | Eigenaar laat conflict beoordelen |
Voeg negatieve en onduidelijke gevallen toe
Neem vragen op waarop de bronverzameling geen antwoord bevat. Test een verkeerde aanname, een tegenstrijdige bron en een vraag die eerst verduidelijking nodig heeft. Een toepassing die op al deze gevallen toch een stellig antwoord maakt, kan in een gewone demonstratie indrukwekkend lijken maar past niet vanzelf bij verantwoord dagelijks gebruik.
Voeg ook materiaal toe met een misleidende instructie in de bron. De proef beoordeelt dan of de toepassing broninhoud als informatie behandelt en de afgesproken taakgrens blijft bewaken. Zo'n beperkte proef dekt niet alle aanvallen. Zij maakt wel zichtbaar welke specifieke grens is onderzocht en welke uitkomsten nog aanvullend beveiligingsonderzoek of een ander ontwerp vragen.
Test rechten met herkenbare rolwisselingen
Gebruik dezelfde inhoudelijke vraag onder verschillende toegangsrechten. Een medewerker met toegang tot een productbijlage kan andere ondersteuning krijgen dan een externe gebruiker. Controleer niet alleen de antwoordtekst, maar ook citaten, bronlabels en links. Neem een situatie op waarin toegang na een eerdere vraag wordt ingetrokken en stel dezelfde vraag opnieuw.
Leg vast welke uitkomst per rol wordt verwacht en welke context de proef gebruikt. Anders kan een geslaagde test per ongeluk berusten op een gedeeld beheerdersaccount of op bronnen die voor iedereen openstaan. Voor betrouwbare beoordeling moet het testgeval dezelfde informatiegrens vertegenwoordigen als het beoogde gebruik, met bekende beperkingen duidelijk genoteerd.
Kalibreer beoordelaars vóór je cijfers samenvoegt
Laat twee beoordelaars eerst enkele dezelfde uitkomsten bespreken. Wat is voldoende bronondersteuning? Wanneer is een antwoord onvolledig maar nog bruikbaar? Wanneer moet een verkeerde versie als beslissende fout worden gezien? Dit gesprek maakt duidelijk of de beoordelingslabels dezelfde betekenis hebben. Een cijfer met veel decimalen helpt weinig wanneer de onderliggende criteria verschillend worden toegepast.
Bewaar voorbeelden bij de beoordelingsregels. Een kleine rubric met geslaagd, onvolledig, onjuist en onzeker kan voldoende zijn voor een eerste afgebakende proef. Voeg een reden toe in gewone taal. Daardoor blijft achteraf te begrijpen waarom een uitkomst is beoordeeld en welke concrete wijziging mogelijk nodig is. Onzekerheid mag een geldige uitkomst blijven.
Vergelijk versies met dezelfde basis
Leg de bronversies, zoekinstellingen, antwoordinstructies en relevante technische configuratie vast. Verander bij een gerichte vergelijking bij voorkeur één hoofdonderdeel. Als bronnen, model en beoordelingscriteria tegelijk veranderen, kun je moeilijk vaststellen wat een verbetering veroorzaakt. Houd ook rekening met variatie tussen uitvoeringen wanneer de toepassing niet iedere keer exact hetzelfde antwoord oplevert.
Bespreek niet alleen hoeveel gevallen beter zijn, maar welke achteruitgaan. Een verbetering in veel eenvoudige vragen kan onvoldoende zijn wanneer een belangrijke uitzondering slechter wordt behandeld. Leg vast wie dat accepteert, welke aanvullende maatregelen nodig zijn en wanneer een versie niet verder wordt uitgerold. Een proefresultaat hoort tot een projectbesluit te leiden, niet alleen tot een dashboard.
Maak de toetsset onderdeel van beheer
Bewaar de vragen, verwachte ondersteuning en beoordeling op een plek waar de verantwoordelijke ze kan onderhouden. Voeg echte nieuwe foutsoorten toe nadat ze inhoudelijk zijn onderzocht. Verwijder verouderde vragen niet zonder reden; soms horen ze als historisch geval bewaard te blijven om te verklaren waarom de toepassing eerder anders reageerde.
Spreek af welke veranderingen een herbeoordeling vragen. Een nieuwe documentcategorie, andere rechtenkoppeling of gewijzigde passageverdeling kan belangrijker zijn dan een klein schermdetail. Laat de overdracht daarom een oefening bevatten waarin een bron verandert en de relevante gevallen opnieuw worden geprobeerd. Zo wordt evaluatie een praktische routine in plaats van een eenmalige goedkeuring rond de eerste demonstratie.
Van uitleg naar een concrete projectkeuze
Leg je aannames, open vragen en oplevercriteria vast in de bijbehorende tool. Gebruik de dienstengidsen om uitvoering en afbakening te bespreken.
Open de voorbereidingstool ↗Vragen over dit onderwerp
Is één totaalscore voldoende voor een besluit?
Meestal niet. Een totaalscore kan verschillen tussen zoeken, bronondersteuning, rechten en gebruikerservaring verbergen. Gebruik een samenvatting om overzicht te houden, maar bewaar de relevante foutsoorten, voorbeelden en gevolgen voor de afgesproken taak.
Moet iedere vraag iedere keer hetzelfde antwoord geven?
Niet noodzakelijk dezelfde woorden, maar de inhoudelijke grenzen en noodzakelijke ondersteuning moeten passen. Onderzoek relevante variatie met herhaalde gevallen wanneer dat voor de toepassing belangrijk is. Een geldig parafraseverschil is iets anders dan een wisselende voorwaarde of bronversie.
Wanneer kunnen we de proef uitbreiden?
Wanneer de afgesproken taak, bekende fouten en beheerroutes voldoende zijn beoordeeld door de verantwoordelijken. Leg open beperkingen vast en voeg bronnen of gebruikers gericht toe. Een geslaagde kleine proef bewijst niet automatisch de werking van een veel bredere verzameling.
Verder met een aansluitende vraag
RAG zoekt de verkeerde passage: onderzoek retrieval vóór je het antwoord herschrijft
Onderzoek zoekkwaliteit met verwachte passages, productversies, tekststructuur, filters en een gecontroleerde vergelijking.
RAG & bedrijfskennisToegangsrechten in RAG: wie mag welke bedrijfskennis terugvinden?
Werk gebruikers, organisaties, bronrechten, caches en intrekking uit voordat je interne kennis via AI beschikbaar maakt.
Maatwerksoftware & portalenMaatwerksoftware accepteren: beoordeel complete taken en afgesproken grenzen
Bereid softwareacceptatie voor met representatieve gebruikers, invoer, uitzonderingen, toegang, herstel, bewijs en een besluit over openstaande punten.
Bronnen en technische achtergrond
- NIST: AI Risk Management Framework ↗
Kader voor het organiseren van AI-risicobeheer, geen productcertificering.
- OWASP GenAI: Prompt Injection ↗
Risico van misleidende instructies in invoer en bronnen.
- OWASP: Authorization Cheat Sheet ↗
Principes voor toegangscontrole; de uitgewerkte proefgevallen zijn illustratief.