De eenvoudigste RAG-demonstratie begint met een vraag waarvan het antwoord duidelijk in een document te vinden is. De retriever zoekt de relevante passage op, het model zet deze om in een gebruiksvriendelijk antwoord, en het resultaat ziet er overtuigend uit.
Tijdens de ontwikkeling vind ik een andere vraag nuttiger: wat gebeurt er als de kennisbank het antwoord niet bevat? In dat geval wordt duidelijk of de applicatie het verschil begrijpt tussen het vinden van iets vergelijkbaars en het vinden van voldoende bewijs.
Een passage in de buurt kan nog steeds een verkeerd bewijs zijn
Stel dat een winkel een algemeen retourbeleid hanteert, maar geen informatie geeft over de vraag of een bepaald op bestelling gemaakt artikel kan worden geretourneerd. Een zoekmachine kan het algemene beleid vinden met een hoge gelijkenisscore. De tekst is relevant voor het onderwerp, maar ondersteunt niet noodzakelijkerwijs het specifieke antwoord.
Daarom beschouw ik de positie in de zoekresultaten niet als een vrijbrief om te antwoorden. De gebruiker moet nagaan wat er in de vraag wordt gevraagd, welke feiten de bron daadwerkelijk aantoont en wat er nog onbekend is.
In het oorspronkelijke RAG-artikel van Lewis en collega’s wordt beschreven hoe het genereren van informatie wordt gecombineerd met het ophalen van externe herinneringen. Bij een implementatie voor eindgebruikers moeten nog steeds productspecifieke beslissingen worden genomen over wanneer dat opgehaalde materiaal voldoende is.
Stel een evaluatieset samen voordat je de pijplijn optimaliseert
Ik begin met een kleine verzameling representatieve vragen en geef het verwachte gedrag een label. Het label is meer dan alleen een aanbevolen zin. Het geeft ook aan of het systeem moet antwoorden, een verduidelijkende vraag moet stellen of de kwestie aan een medewerker moet doorgeven.
Bij een zaak waarop een reactie mogelijk is, noteer ik de bronnen waarop de beweringen zijn gebaseerd en de beweringen die zijn goedgekeurd. Bij een zaak waarop geen reactie mogelijk is, noteer ik wat er ontbreekt. Dit onderscheid helpt beoordelaars om het eens te worden over de redenen waarom een reactie wordt goedgekeurd of afgewezen.
- Een vraag waarop in één bron een direct antwoord te vinden is.
- Een vraag waarin een synoniem wordt gebruikt in plaats van de oorspronkelijke bewoording.
- Een vraag over een product dat niet in de catalogus staat.
- Een vraag waarvoor een uitzondering op het beleid nodig is, die in de documenten niet wordt vastgelegd.
- Een vraag met een dubbelzinnige verwijzing, zoals ‘de grotere’.
- Een vraag die alleen wordt onderbouwd door een verouderd document.
Ik gebruik moeilijke maar aannemelijke bewoordingen. Kunstmatige onzin is gemakkelijk te verwerpen en zegt weinig over realistische, ongefundeerde vragen.
Maak een onderscheid tussen opzoekfouten en antwoordfouten
Als de juiste bron nooit is opgehaald, is het onwaarschijnlijk dat het aanpassen van de vraag het onderliggende probleem zal verhelpen. Als de bron wel is opgehaald, maar het antwoord een voorwaarde verzonnen heeft, werkt de ophaalfase mogelijk wel correct.
Daarom bekijk ik de selectie van kandidaten, de rangschikking, de toereikendheid van het bewijs en de uiteindelijke generatie afzonderlijk. Eén enkel algemeen nauwkeurigheidscijfer kan een systeem verbergen dat weliswaar goed resultaten oplevert, maar het bewijs daarvoor vaak overschat.
Drempelwaarden moeten worden afgestemd op de daadwerkelijke verdeling van het corpus en de zoekopdrachten. Een gelijkenisscore is geen universeel betrouwbaarheidspercentage. De juiste beslissingsgrens kan ook verschillen tussen een algemene beschrijvende vraag en een verzoek over een prijs of garantie.
Maak onzekerheid nuttig voor de klant
Een goed antwoord verklaart de ontbrekende informatie en geeft aan wat de volgende stap is. Als onduidelijk is om welke productvariant het gaat, vraag dan naar de variant. Als het beleid ontbreekt, stuur de vraag dan door naar iemand die over de relevante achtergrondinformatie beschikt.
Ik vermijd vage uitspraken zoals „Daar kan ik u niet bij helpen“ wanneer het systeem precies kan aangeven wat er nodig is. Het doel is om de klantervaring intact te houden en tegelijkertijd te weigeren een feit te verzinnen.
Tijdens de evaluatie houd ik ‘niet-ondersteunde’ antwoorden apart bij van ‘onnodige onthoudingen’. Het terugdringen van het ene door elk antwoord als ‘niet-nuttig’ te bestempelen, is geen zinvolle verbetering. Het systeem moet een antwoord geven wanneer er voldoende bewijs is en herkennen wanneer dat niet het geval is.
Een negatieve testset geeft die grens een concrete invulling. Het zet de uitspraak „de assistent moet voorzichtig zijn” om in voorbeelden die het engineeringteam kan uitvoeren na elke relevante zoekopdracht of wijziging in de prompt.
Bijgewerkt op 25 september 2026.