Betrouwbare RAG bouwen: zeven foutpunten en evaluatiekaders nader bekeken

Retrieval-Augmented Generation (RAG) is cruciaal voor moderne AI-architectuur, waar het fungeert als een essentieel kader voor het bouwen van contextbewuste agenten.

Maar de overstap van een eenvoudig prototype naar een productierijp systeem houdt in dat er significante hindernissen moeten worden overwonnen bij het ophalen van gegevens, het samenstellen van de context en het formuleren van antwoorden.

Dit artikel biedt een grondige analyse van zeven typische RAG-foutpunten en de evaluatiemetrics met praktische codevoorbeelden.

De anatomie van RAG-fouten – 7 foutpunten (FP’s)

Volgens de onderzoekers Barnett en collega’s ondervinden Retrieval Augmented Generation (RAG)-systemen zeven specifieke Foutpunten (FP’s) in de pijplijn.

Het onderstaande diagram illustreert deze fasen:

Figuur A. Indexerings- en queryprocessen die nodig zijn om een RAG-systeem te maken. Indexering vindt plaats tijdens de ontwikkeling en queries tijdens de uitvoering. De in dit onderzoek vastgestelde foutpunten staan in rode kaders (bron)

We behandelen elk FP in de volgorde van de pijplijn, van linksboven naar rechtsonder zoals te zien is in Figuur A.

FP1. Ontbrekende Inhoud

Ontbrekende inhoud gebeurt wanneer het systeem een vraag krijgt die niet kan worden beantwoord omdat de relevante informatie niet aanwezig is in de beschikbare vectoropslag.

De fout treedt op wanneer een LLM een plausibele maar onjuiste reactie geeft in plaats van aan te geven dat het dat niet weet.

FP2. Gemiste Top-Ranked Documenten

Dit is een situatie waarin een correct document aanwezig is in de vectoropslag, maar de retriever faalt om het hoog genoeg te ranken om het op te nemen in de top-k-documenten die worden doorgegeven aan een LLM als context.

Als gevolg hiervan bereikt de juiste informatie nooit de LLM.

FP3. Niet in Context (Consolidatie-Strategiebeperkingen)

Dit is een situatie waarin een correct document aanwezig is en wordt opgehaald uit de vectoropslag, maar wordt uitgesloten tijdens het consolidatieproces.

Dit gebeurt wanneer te veel documenten worden geretourneerd en het systeem ze moet filteren om binnen het contextvenster van een LLM, tokenlimieten of ratelimieten te passen.

FP4. Niet Geëxtraheerd

Dit is een situatie waarin een LLM faalt om de juiste informatie te identificeren in de context, zelfs als de juiste informatie in de vectoropslag aanwezig was en met succes werd opgehaald en geconsolideerd.

Dit gebeurt wanneer de context te veel ruis bevat of tegenstrijdige informatie bevat die de LLM verwarrend vindt.

FP5. Verkeerd formaat

Dit is een situatie waarin de opslag, ophaling, consolidatie en interpretatie door de LLM met succes worden afgehandeld, maar de LLM faalt om specifieke opmaakinstructies te volgen die in de prompt worden gegeven, zoals een tabel, een opsomming of een JSON-schema.

FP6. Onjuiste Specificiteit

De output van een LLM is technisch aanwezig, maar te algemeen of te complex in vergelijking met de behoeften van de gebruiker.

Bijvoorbeeld, een LLM genereert eenvoudige antwoorden op een gebruikersvraag met een complex professioneel doel.

FP7. Onvolledige Antwoorden

Dit is een situatie waarin een LLM een output genereert die niet noodzakelijkerwijs onjuist is, maar waarin belangrijke informatie ontbreekt die beschikbaar was in de context.

Bijvoorbeeld, wanneer een gebruiker een complexe vraag stelt zoals “Wat zijn de belangrijkste punten in documenten A, B en C?”, beantwoordt de LLM slechts één of twee van de bronnen.

Hoe FP’s de RAG-Pijplijnprestaties Aantasten

Elk van deze FP’s heeft invloed op de prestaties van RAG-pijplijnen:

Gegevensintegriteit- en Vertrouwensfouten

Wanneer informatie ontbreekt of onjuist is, is het systeem niet langer een betrouwbare bron van informatie. Primaire FP’s omvatten:

• FP1 (Ontbrekende Inhoud): Het antwoord is niet in de documenten aanwezig.
• FP4 (Niet Geëxtraheerd): De LLM besluit om het juiste antwoord in de documenten te negeren.
• FP7 (Onvolledig): De LLM geeft halve waarheden en laat belangrijke informatie weg.

Ophaling- en Efficiëntiebottlenecks

De RAG-pijplijn kan inefficiënt zijn wanneer deze belangrijke informatie mist in de ophaling- en consolidatiefasen. Primaire FP’s omvatten:

• FP2 (Gemiste Top-Ranked): Het embedding-model faalt om top-k-embeddingen te selecteren.
• FP3 (Consolidatie-Strategie): Het script om documenten te trimmen om binnen de LLM-limieten te passen, laat de belangrijkste delen vallen.

Gebruikerservaring- en Formaatfouten

Hoewel correct, kan een output met slechte leesbaarheid of in een verkeerd formaat de gebruikerservaring aantasten. Primaire FP’s omvatten:

• FP5 (Verkeerd formaat): De LLM faalt om het specifieke uitvoerformaat te volgen, zoals JSON.
• FP6 (Onjuiste Specificiteit): De LLM genereert een uitgebreide output voor een eenvoudige ja/nee-vraag, of vice versa (een te kort antwoord voor een complexe vraag).

De Evaluatiestack: Kaders om FP’s te Mitigeren

Evaluatiemetrics zijn ontworpen om deze FP’s systematisch te mitigeren.

Deze sectie verkent belangrijke evaluatiemetrics met praktische use-cases.

Belangrijke RAG-Evaluatiemetrics:

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – De Eenheidstest voorafgaand aan Implementatie

DeepEval berekent een gewogen score op basis van de criteria.

Een LLM-als-rechter (bijv. GPT-4o) evalueert elk criterium tegen de output van een LLM:

DeepEval maakt gebruik van G-eval, een keten-van-gedachten (CoT)-kader dat een multi-stapbenadering gebruikt om de output te evalueren:

1. Definieer een criterium om te meten (bijv. “coherentie”, “vloeiendheid” of “relevantie”).
2. Genereer evaluatiestappen (met behulp van een evaluator LLM).
3. Volg de evaluatiestappen en analyseer de invoer en de output van de LLM.
4. Bereken een verwachte gewogen som van de score van elk criterium.

Veelvoorkomend praktijkscenario

• Situatie: Een technische documentatie-assistent (bot) voor een complex softwareproduct lijkt elke keer te werken wanneer het engineersteam de codebase bijwerkt.
• Probleem: Geen kwantitatief bewijs of de bot nog steeds de gebruikersvraag kan beantwoorden (Je denkt alleen dat het werkt…).
• Oplossing: Integreer een PyTest-functie als CI/CD-regressietest in GitHub Actions waar DeepEval G-Eval en andere metrics uitvoert over een testgeval:

• Verwachte resultaten: Als de score van een van de metrics onder de drempel (0,85) daalt, geeft PyTest een AssertionError – waardoor de CI-bouw onmiddellijk mislukt en de stille regressie niet in productie komt.

Ontwikkelaarsopmerking – Het Testgeval voor DeepEval
Een set LLMTestCase-objecten definieert het testgeval dat DeepEval uitvoert.

In de praktijk moet dit testgeval de meest belangrijke gebruikersvragen en gelabelde outputs met de opgehaalde context bevatten.

Deze kunnen worden opgehaald uit een JSON- of CSV-bestand.

RAGAS – De Naald in een Hooiberg-Optimaliseerder

Retrieval Augmented Generation Assessment (Ragas) is ontworpen om RAG te evalueren zonder een door mensen geannoteerde dataset door het genereren van synthetische testsets.

Vervolgens berekent het de belangrijkste metrics:

Figuur B. Diagram van de RAGAS-evaluatiedriehoek, dat vraag, context en antwoord verbindt via precisie, recall, brongetrouwheid en relevantie (gemaakt door Kuriko IWAI)

De belangrijkste metrics zijn onderverdeeld in drie groepen:

• Ophalingspijplijn (zwarte doorgetrokken lijn, Figuur B): Contextprecisie, contextrecall.
• Generatiepijplijn (zwarte stippellijn, Figuur B): Brongetrouwheid, antwoordrelevantie.
• Referentiegegevens (rood kader, Figuur B): Antwoordsemantische gelijkenis, antwoordcorrectheid.

Veelvoorkomend praktijkscenario

• Situatie: Het RAG-systeem voor juridische contracten mist belangrijke clausules. Je weet niet of het probleem in de Zoekfunctie (Retriever) of de Leesfunctie (Generator) zit.
• Probleem: Geen idee over het optimale top-k (aantal opgehaalde chunks).
• Oplossing: Gebruik RAGAS om een synthetische testset te maken met 100 paren van vragen en bewijs. Voer vervolgens de RAG-pijplijn uit op de testset om contextrecall en contextprecisie te berekenen:
• Verwacht resultaat: Afhankelijk van de metrische resultaten kan het actieplan het volgende zijn:

Tabel 1. RAGAS Diagnose-Actieplan – Toewijzing van Scores aan Systeemaanpassingen.

TruLens – De Feedback-Lus-Specialist

TruLens richt zich op de interne mechanismen van het RAG-proces in plaats van alleen de eindoutput door het gebruik van feedbackfuncties.

Het gebruikt ook een LLM-gebaseerde score die weerspiegelt hoe goed de reactie voldoet aan de intentie van de vraag, met behulp van een 4-punts Likert-schaal (0-3), waardoor het superieur is voor het rangschikken van de kwaliteit van verschillende zoekresultaten.

Veelvoorkomend praktijkscenario

• Situatie: Een medisch adviseur-bot beantwoordt een gebruikersvraag correct, maar voegt een extra tip toe die niet in de gecontroleerde PDF-basis zit.
• Probleem: De extra tip kan nuttig zijn, maar is niet onderbouwd door het bronmateriaal.
• Oplossing: Gebruik TruLens om een gefundeerdheidsfeedbackfunctie te implementeren met een drempel zoals score > 0.8.

• Verwachte resultaten: Wanneer de LLM een reactie genereert die informatie bevat die niet in de opgehaalde chunks zit, markeert TruLens het record in uw dashboard.

Arize Phoenix – De Stille Foutkaart

Arize Phoenix is een open-source instrument voor waarneembaarheid en evaluatie om LLM-outputs te evalueren, inclusief complexe RAG-systemen.

Gebouwd op OpenTelemetry door Arize AI, richt het zich op waarneembaarheid door LLM-evaluatie te behandelen als een subset van MLOps.

In de context van RAG-evaluatie, excelleert Phoenix in embeddinganalyse, met behulp van Uniform Manifold Approximation and Projection (UMAP) om hoogdimensionale vector-embeddingen te reduceren tot 2D/3D-ruimte.

Deze embeddinganalyse onthult mathematisch of de mislukte queries semantisch gegroepeerd zijn, wat aangeeft dat er een gat in de vector-database zit.

Veelvoorkomend praktijkscenario

• Situatie: Een klantenservice-bot werkt goed voor restituties, maar geeft onzinnige antwoorden op garantieclaims.
• Probleem: Een gegevenshiaat in de vectordatabase dat niet in de logs terug te vinden is.
• Oplossing: Gebruik Arize Phoenix om een Umap-Embedding-Visualisatie (UEV) te maken, een 3D-kaart voor de vector-database – om gebruikersvragen op de documentchunks te projecteren.
• Verwachte resultaten: Een zichtbaar cluster van gebruikersvragen die in de donkere zone landen waar geen documenten bestaan, wat aangeeft dat men is vergeten sommige documenten te uploaden naar de vectoropslag.

Braintrust – het vangnet tegen promptregressies

Braintrust is ontworpen voor hoge-frequentie-iteratiecycli door het gebruik van cross-model-vergelijking.

Veelvoorkomend praktijkscenario

• Situatie: Een engineersteam upgradet een prompt van “Beantwoord de vraag” (Geval A) naar een complexere systeeminstructie van 500 woorden (Geval B).
• Probleem: Het verbeteren van de prompt voor Geval B kan per ongeluk Geval A breken.
• Oplossing: Gebruik Braintrust om een gouden dataset te maken met een set van N perfecte voorbeelden (bijv. N = 50). Laat Braintrust een zij-aan-zij-vergelijking (SxS) uitvoeren elke keer dat het team een enkel woord in de prompt bijwerkt:

• Verwacht resultaat: Een verschilrapport dat exact aangeeft welke gevallen uit de referentiedataset (N = 50) beter of slechter werden.

Samenvatting

Wanneer RAG wordt afgehandeld met de juiste evaluatiekaders, kan het een concurrerend instrument zijn om een LLM-context te bieden die het meest relevant is voor de gebruikersvraag.

Implementatiestrategie: Toewijzing van Metrics aan Foutpunten

Hoewel er geen universele oplossing is, toont Tabel 2 welke evaluatiemetrics moeten worden toegepast voor elk FP dat in dit artikel wordt behandeld:

Tabel 2. De Foutpunt-Mitigatiematrix – Welk Instrument Lost Welk FP op?

DeepEval en RAGAS kunnen hun brongetrouwheidsmetrics gebruiken om gegevensintegriteitsfouten te meten (FP1, FP4, FP7).

TruLens gebruikt zijn contextprecisie / recall om de contextrelevantie voor de output te meten en beoordeelt daarmee FP2.

Arize Phoenix biedt een visuele trace van het ophalingsproces, waardoor het gemakkelijk is om te zien of het opgehaalde document verloren is gegaan tijdens de consolidatie (FP3).

Voor UX-fouten creëert DeepEval aangepaste metrics om UX-fouten te beoordelen, terwijl Braintrust uitblinkt in vergelijkingen met referentiedatasets.