Hoe een Betrouwbaar RAG te Bouwen: Een Diepe Duik in 7 Foutpunten en Evaluatiekaders

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

Maar het verplaatsen van een basisprototype naar een productieready-systeem houdt in dat er significante hindernissen moeten worden overwonnen in gegevensopslag, contextconsolidatie en responsynthese.

Dit artikel biedt een diepe duik in zeven typische RAG-foutpunten en de evaluatiemetrics met praktische codevoorbeelden.

De Anatomie van RAG-Breakdown – 7 Foutpunten (FP’s)

Volgens onderzoekers Barnett et al., Retrieval Augmented Generation (RAG) systemen ondervinden zeven specifieke Foutpunten (FP’s) in de pijplijn.

Het onderstaande diagram illustreert deze fasen:

Figuur A. Indexeren en Query-processen vereist voor het maken van een RAG-systeem. Het indexeren gebeurt tijdens de ontwikkeling en queries tijdens de runtime. Foutpunten geïdentificeerd in deze studie worden weergegeven in rode dozen (bron)

Laten we elk FP onderzoeken, gerangschikt naar de pijplijnsequentie, volgend op de bovenlinkse naar benedenrechter progressie zoals weergegeven 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 te zeggen het weet het niet.

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 lawaaierig is of tegenstrijdige informatie bevat die de LLM verwarrend vindt.

FP5. Verkeerde Formaat

Dit is een situatie waarin de opslag, ophaling, consolidatie en LLM-interpreting met succes worden afgehandeld, maar de LLM faalt om specifieke formaat instructies 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 ontbreekt aan belangrijke stukken informatie die beschikbaar waren 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 ontbrekende of onjuiste informatie aanwezig 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, ontbreekt aan belangrijke stukken.

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 (Verkeerde 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 (te korte 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”, “fluency” of “relevantie”).
2. Genereer evaluatiestappen (met behulp van een evaluator LLM).
3. Volg de evaluatiestap en analyseert de invoer en de output van de LLM.
4. Berekent een verwachte gewogen som van de score van elk criterium.

Algemene Scenario in de Praktijk

• 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 Action 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 vlaggenschipmetrics:

Figuur B. De RAGAS-evaluatietriade-diagram dat vraag, context en antwoord verbindt via precisie-, recall-, geloofwaardigheids- en relevantiemetrics (Gemaakt door Kuriko IWAI)

De vlaggenschipmetrics zijn onderverdeeld in drie groepen:

• Ophalingspijplijn (zwarte, solide lijn, Figuur B): Contextprecisie, contextrecall.
• Generatiepijplijn (zwarte, onderbroken lijn, Figuur B): Geloofwaardigheid, antwoordrelevantie.
• Grondwaarheid (rode doos, Figuur B): Antwoordsemantische gelijkenis, antwoordcorrectheid.

Algemene Scenario in de Praktijk

• Situatie: Het RAG-systeem voor juridische contracten ontbreekt aan 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. Vervolgens voer de RAG-pijplijn uit op de testset om contextrecall en contextprecisie te berekenen:
• Verwachte 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.

Algemene Scenario in de Praktijk

• Situatie: Een medisch adviseur-bot beantwoordt een gebruikersvraag correct, maar voegt een pro-tip toe die niet in de gecontroleerde PDF-basis zit.
• Probleem: De toegevoegde pro-tip kan nuttig zijn, maar niet gefundeerd.
• 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 observabiliteit- en evaluatie-instrument om LLM-outputs te evalueren, inclusief complexe RAG-systemen.

Gebouwd op OpenTelemetry door Arize AI, richt het zich op observabiliteit 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.

Algemene Scenario in de Praktijk

• Situatie: Een klantenservice-bot werkt goed voor restituties, maar geeft nonsensuele antwoorden op garantieclaims.
• Probleem: Gegevensgat in de vector-database (Kan niet in logs vinden).
• 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: Ziet visueel een cluster van gebruikersvragen die in de donkere zone landen waar geen documenten bestaan, wat aangeeft dat sommige documenten vergeten zijn om te uploaden naar de vectoropslag.

Braintrust – De Prompt-Regressie-Veiligheidsnet

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

Algemene Scenario in de Praktijk

• Situatie: Een engineersteam upgradet een prompt van “Beantwoord de vraag” (Geval A) naar een meer complexe 500-woord-systeeminstructie (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:

• Verwachte resultaat: Een verschilrapport dat exact aangeeft welke gevallen beter/worse werden voor elk van de gouden dataset (N = 50).

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 geloofwaardigheidsmetrics gebruiken om gegevensintegriteitsfouten te meten (FP1, FP4, FP7).

TruLens gebruikt zijn contextprecisie / recall om de contextrelevantie voor de output te meten – effectief FP2 beoordelen.

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 grondwaarheidsdatasetvergelijking.