Hvorfor evaluering er vigtig i RAG

Et RAG-system kan virke, som om det fungerer, fordi det returnerer flydende svar, der lyder plausible. Men uden målinger ved du ikke, om det faktisk henter de rigtige chunks eller genererer troværdige svar. Teams, der springer evalueringen over, bruger ofte måneder på at justere chunking-strategier og promptformater ud fra mavefornemmelsen, blot for at opdage, at de har gjort tingene værre. Grundig evaluering er det, der forvandler RAG-udvikling fra gætteri til softwareudvikling.

RAG har to forskellige trin, der kan fejle uafhængigt af hinanden: hentning og generering. Hentningen fejler, når de relevante chunks ikke rangeres blandt de K øverste resultater — LLM'en kan ikke generere et godt svar, hvis de rigtige oplysninger aldrig blev hentet. Genereringen fejler, når de korrekte chunks blev hentet, men LLM'en ignorerede eller fejllæste dem eller tilføjede hallucinerede oplysninger. Du har brug for separate målinger for hvert trin for at finde ud af, hvilken komponent der skaber problemet.

Hvis du kun måler kvaliteten af det endelige svar, skjuler du, hvor fejlene kommer fra. Antag, at dit system giver forkerte svar 30 % af tiden. Skyldes det, at hentningen mangler de rigtige chunks, eller at LLM'en ignorerer gode chunks? Hvis du kun kender den endelige fejlrate, ved du ikke, hvilken komponent du skal rette. Instrumentér begge trin separat: mål kvaliteten af hentningen med gyldne datasæt og kvaliteten af genereringen med troværdighedsscorer.

Evaluering kræver et gyldent datasæt: et sæt af spørgsmål-svar-par, hvor du kender det korrekte svar og helst også, hvilket dokument og hvilken chunk svaret stammer fra. Til et minimalt evalueringssæt, der kan bruges i praksis, skal du indsamle 50-100 spørgsmål, som er repræsentative for rigtige brugerforespørgsler. Besvar dem i hånden eller ved at læse kildedokumenterne. Medtag forskellige spørgsmålstyper: faktuelle opslag, sammenligninger, flertrinsræsonnement og spørgsmål uden for domænet, som systemet bør afvise at besvare.

Det er tidskrævende at oprette 100 spørgsmål manuelt. Du kan gøre det hurtigere med en LLM til datagenerering: giv hvert dokumentstykke til GPT-4o, og bed den generere 3-5 forskellige spørgsmål, hvis svar kan findes i det pågældende stykke, samt den forventede svartekst. Gennemgå et udvalg manuelt for at opdage kvalitetsproblemer. Denne fremgangsmåde kan hurtigt skaleres til tusindvis af spørgsmål, men den kan overse særlige tilfælde, som kun rigtige brugere ville spørge om.

Træfrate@K er andelen af spørgsmål, hvor mindst ét relevant tekststykke optræder blandt de øverste K resultater fra hentningen. Det er det enkleste og mest intuitive mål for hentning. En træfrate@5 på 85 % betyder, at det relevante tekststykke var blandt de 5 øverste resultater for 85 ud af 100 spørgsmål. Følg træfraten separat for forskellige dokumenttyper, forespørgselslængder og emnekategorier for at finde ud af, hvor din hentningskomponent har de største problemer.

Troskab måler, om det genererede svar kun indeholder oplysninger, der kan verificeres i den hentede kontekst. Et utro svar tilføjer fakta, som konteksten ikke understøtter – det er en hallucination. Mål troskab ved at få en bedømmende LLM (eller en menneskelig evaluator) til at kontrollere hver sætning i svaret op imod konteksten og markere påstande, der ikke understøttes af de hentede tekststykker. Et troskabsmål på mindst 95 % er målet for produktionssystemer.

Svarrelevans måler, om det genererede svar faktisk besvarer brugerens spørgsmål. Et meget troværdigt svar kan stadig ramme ved siden af ved at besvare et beslægtet, men andet spørgsmål. Mål relevans separat fra troskab. Brug en bedømmende LLM til at vurdere, om svaret direkte besvarer det, der blev spurgt om, på en skala fra 1 til 5. Lav svarrelevans tyder ofte på et problem med promptens struktur eller på, at den hentede kontekst faktisk ikke indeholder svaret.

Evaluering er mest værdifuld, når du følger mål over tid, efterhånden som du foretager ændringer. Gem evalueringsresultater i en database eller et regneark med tidsstempler og versionsetiketter (f.eks. chunk_size=500, embed=3-small, k=5). Når du prøver en ny strategi for opdeling i tekststykker eller en ny indlejringsmodel, skal du køre den samme evaluering og sammenligne resultaterne. Det forhindrer tilbagegang – du kan f.eks. forbedre troskaben, men ved et uheld reducere træfraten. Kør altid den fulde evaluering, før du integrerer ændringer i produktionen.

Ud over specifikke mål kræver evaluering en ændret indstilling: Betragt RAG som et maskinlæringssystem med målbar ydeevne, ikke som en chatbot, du vurderer subjektivt ved at chatte med den. Fastlæg succeskriterier på forhånd (f.eks. træfrate@5 > 85 %, troskab > 95 %). Opret et testsæt, der forbliver fastlåst og aldrig bruges til beslutninger om udviklingen. Reserver et separat udviklingssæt til iterationer. Denne disciplin adskiller teams, der leverer pålidelig RAG, fra teams, der leverer imponerende demonstrationer, som fejler i produktionen.

En vigtig disciplin inden for maskinlæring, som også gælder for evaluering af RAG, er opdelingen i trænings-, udviklings- og testsæt. Dit testsæt skal være helt fastlåst – brug det aldrig til at træffe beslutninger om udviklingen. Brug et separat udviklingssæt til at eksperimentere med strategier for opdeling i tekststykker, promptændringer og indlejringsmodeller. Kør kun testsættet, når du mener, at en ændring er klar til produktion. Denne adskillelse forhindrer overtilpasning af din RAG-pipeline til testsættet og sikrer, at dine endelige rapporterede mål afspejler ægte generalisering.

I denne lektion lærte du om: de to uafhængige fejltilstande for hentning og generering, som kræver separate mål, hvordan du opbygger et guldstandarddatasæt med tre tupler bestående af spørgsmål, svar og tekststykke til objektiv evaluering, træfrate som det centrale mål for hentning samt troskab og svarrelevans som de centrale mål for generering, og betydningen af at følge mål over tid for at forhindre tilbagegang. Dernæst implementerer vi specifikke mål for hentning, herunder MRR og NDCG.