Waarom evaluatie belangrijk is voor RAG

Een RAG-systeem kan goed lijken te werken omdat het vloeiende, aannemelijk klinkende antwoorden geeft. Maar zonder metingen weet je niet of het systeem daadwerkelijk de juiste chunks ophaalt of betrouwbare antwoorden genereert. Teams die evaluatie overslaan, besteden vaak maanden aan het aanpassen van chunkstrategieën en promptindelingen op basis van intuïtie, om vervolgens te ontdekken dat ze de resultaten hebben verslechterd. Grondige evaluatie verandert RAG-ontwikkeling van giswerk in engineering.

RAG heeft twee afzonderlijke fasen die onafhankelijk van elkaar kunnen mislukken: ophalen en genereren. Het ophalen mislukt wanneer de relevante chunks niet in de top-K-resultaten staan — de LLM kan geen goed antwoord genereren als de juiste informatie nooit is opgehaald. Het genereren mislukt wanneer de juiste chunks wel zijn opgehaald, maar de LLM ze negeert, verkeerd leest of verzonnen informatie toevoegt. Je hebt afzonderlijke metrieken nodig voor elke fase om vast te stellen welk onderdeel het probleem veroorzaakt.

Als je alleen de kwaliteit van het uiteindelijke antwoord meet, blijft verborgen waar fouten vandaan komen. Stel dat je systeem in 30% van de gevallen verkeerde antwoorden geeft. Komt dat doordat het ophalen de juiste chunks mist, of doordat de LLM goede chunks negeert? Als je alleen het uiteindelijke foutpercentage kent, weet je niet welk onderdeel je moet repareren. Voorzie beide fasen afzonderlijk van instrumentatie: meet de kwaliteit van het ophalen met gouden datasets en de kwaliteit van het genereren met scores voor getrouwheid.

Voor evaluatie heb je een gouden dataset nodig: een verzameling vraag-antwoordparen waarvan je het juiste antwoord kent en idealiter ook weet uit welk document en welke chunk het antwoord afkomstig is. Verzamel voor een minimaal bruikbare evaluatieset 50-100 vragen die representatief zijn voor echte query's van gebruikers. Beantwoord ze met de hand of door de brondocumenten te lezen. Neem verschillende vraagtypen op: feitelijke opzoekvragen, vergelijkingen, redeneringen over meerdere stappen en vragen buiten het domein die het systeem moet weigeren te beantwoorden.

100 vragen handmatig maken is tijdrovend. Versnel dit met een LLM voor gegevensgeneratie: geef elk documentfragment aan GPT-4o en vraag het om 3 tot 5 verschillende vragen te genereren waarvan de antwoorden in dat fragment te vinden zijn, plus de verwachte antwoordtekst. Controleer handmatig een steekproef om kwaliteitsproblemen op te sporen. Deze aanpak schaalt snel naar duizenden vragen, maar kan randgevallen missen die alleen echte gebruikers zouden aansnijden.

Trefferpercentage@K is het aandeel vragen waarvoor ten minste één relevant fragment voorkomt in de bovenste K-resultaten van de retrieval. Dit is de eenvoudigste en meest intuïtieve retrievalmetriek. Een trefferpercentage@5 van 85% betekent dat voor 85 van de 100 vragen het relevante fragment bij de vijf beste resultaten stond. Houd het trefferpercentage afzonderlijk bij voor verschillende documenttypen, querylengtes en onderwerpcategorieën om te ontdekken waar uw retriever de meeste moeite mee heeft.

Getrouwheid meet of het gegenereerde antwoord alleen informatie bevat die in de opgehaalde context kan worden geverifieerd. Een ongetrouw antwoord voegt feiten toe die niet door de context worden ondersteund — dat is hallucinatie. Meet de getrouwheid door een beoordelende LLM (of menselijke beoordelaar) elke zin in het antwoord te laten controleren aan de hand van de context en beweringen te markeren die niet door de opgehaalde fragmenten worden ondersteund. Een getrouwheidsscore van 95% of hoger is het doel voor productiesystemen.

Relevantie van het antwoord meet of het gegenereerde antwoord daadwerkelijk ingaat op de vraag van de gebruiker. Een zeer getrouw antwoord kan toch de kern missen door een verwante maar andere vraag te beantwoorden. Meet relevantie afzonderlijk van getrouwheid. Gebruik een beoordelende LLM om met een schaal van 1 tot 5 te beoordelen of het antwoord rechtstreeks ingaat op wat er is gevraagd. Een lage relevantie van het antwoord wijst vaak op een probleem met de structuur van de prompt of op opgehaalde context die het antwoord niet daadwerkelijk bevat.

Evaluatie is het waardevolst wanneer u metrieken in de loop van de tijd bijhoudt terwijl u wijzigingen aanbrengt. Sla evaluatieresultaten op in een database of spreadsheet met tijdstempels en versielabels (bijv. chunk_size=500, embed=3-small, k=5). Wanneer u een nieuwe strategie voor het opdelen in fragmenten of een nieuw inbeddingsmodel uitprobeert, voert u dezelfde evaluatie uit en vergelijkt u de resultaten. Zo voorkomt u regressie — u kunt de getrouwheid verbeteren, maar per ongeluk het trefferpercentage verlagen. Voer altijd de volledige evaluatie uit voordat u wijzigingen naar productie samenvoegt.

Naast specifieke metrieken vereist evaluatie een verandering van mindset: behandel RAG als een machineleersysteem met meetbare prestaties, niet als een chatbot die u subjectief beoordeelt door ermee te chatten. Definieer vooraf succescriteria (bijv. trefferpercentage@5 > 85%, getrouwheid > 95%). Stel een testset samen die bevroren blijft en nooit wordt gebruikt voor ontwikkelbeslissingen. Reserveer een afzonderlijke ontwikkelset voor iteratie. Deze discipline onderscheidt teams die betrouwbare RAG opleveren van teams die indrukwekkende demo's opleveren die in productie falen.

Een belangrijke discipline in machine learning die ook geldt voor RAG-evaluatie is de train-dev-test-splitsing. Uw testset moet volledig bevroren zijn — gebruik deze nooit om ontwikkelbeslissingen te nemen. Gebruik een afzonderlijke ontwikkelset om te experimenteren met strategieën voor het opdelen in fragmenten, promptwijzigingen en inbeddingsmodellen. Voer de testset alleen uit wanneer u denkt dat een wijziging klaar is voor productie. Deze scheiding voorkomt dat u uw RAG-pijplijn overfit op de testset en zorgt ervoor dat uw uiteindelijke gerapporteerde metrieken echte generalisatie weerspiegelen.

In deze les hebt u geleerd: de twee onafhankelijke foutmodi van retrieval en generatie, waarvoor afzonderlijke metrieken nodig zijn, hoe u een gouden dataset opbouwt met vraag-antwoord-fragmentdrieluiken voor objectieve evaluatie, het trefferpercentage als belangrijkste retrievalmetriek en getrouwheid en relevantie van het antwoord als de belangrijkste generatiemetrieken, en het belang van metrieken in de loop van de tijd bijhouden om regressies te voorkomen. Hierna implementeren we specifieke retrievalmetrieken, waaronder MRR en NDCG.