Sådan bygges en pålidelig RAG: En dybdeundersøgelse af 7 fejlpoints og evalueringssystemer

Retrieval-Augmented Generation (RAG) er kritisk for moderne AI-arkitektur, da det fungerer som en essentiel ramme for opbygning af kontekstbevidste agenter.

Men at gå fra en grundlæggende prototype til en produktionsklar system indebærer navigation af betydelige hindringer i datahenting, kontekstkonsolidering og respons-syntese.

Denne artikel giver en dybdeundersøgelse af syv typiske RAG-fejlpoints og evalueringssystemer med praktiske kodningseksempler.

RAG-fejlpoints-anatomi – 7 fejlpoints (FPs)

Ifølge forskerne Barnett et al., Retrieval Augmented Generation (RAG) systemer møder syv specifikke fejlpoints (FPs) i hele pipeline’en.

Den nedenstående diagram illustrerer disse faser:

Figur A. Indekserings- og forespørgselsprocesser nødvendige for opbygning af et RAG-system. Indekseringsprocessen udføres under udviklingstiden, og forespørgsler under køretiden. Fejlpoints identificeret i denne studie er vist i røde bokse (kilde)

Lad os udforske hver FP ordnet efter pipeline-sekvensen, følger progressionen fra top-venstre til bunden-højre vist i Figur A.

FP1. Manglende indhold

Manglende indhold sker, når systemet bedes om at besvare et spørgsmål, som ikke kan besvares, fordi den relevante information ikke er til stede i den tilgængelige vektorlager fra starten.

Fejlen opstår, når en LLM leverer en plausibel lydende, men forkert respons i stedet for at sige det ved ikke.

FP2. Missede top-rangerede dokumenter

Dette er en situation, hvor et korrekt dokument findes i vektorlageret, men retrieveren ikke kan rangere det højt nok til at inkludere det i top-k-dokumenter, der føres til en LLM som kontekst.

Som følge heraf når den korrekte information aldrig LLM.

FP3. Ikke i kontekst (konsolideringsstrategi-begrænsninger)

Dette er en situation, hvor et korrekt dokument findes og hentes fra vektorlageret, men udelukkes under konsolideringsprocessen.

Dette sker, når der returneres for mange dokumenter, og systemet må filtrere dem ned for at passe inden for en LLM’s kontekstvindue, token-grænser eller rate-grænser.

FP4. Ikke udtrukket

Dette er en situation, hvor en LLM ikke kan identificere den korrekte information i konteksten, selvom den korrekte information var i vektorlageret og blev succesfuldt hentet/konsolideret.

Dette sker, når konteksten er for støjende eller indeholder modsætningsfuld information, der forvirrer LLM.

FP5. Forkert format

Dette er en situation, hvor lagring, henting, konsolidering og LLM-fortolkning håndteres succesfuldt, men LLM ikke følger specifikke formateringsinstruktioner i prompten, såsom en tabel, en punktopstilling eller en JSON-skema.

FP6. Forkert specifikation

En LLM’s output er teknisk set til stede, men enten for generel eller for kompleks i forhold til brugerens behov.

For eksempel genererer en LLM simple svar på en brugerforespørgsel med et komplekst professionelt mål.

FP7. Ufuldstændige svar

Dette er en situation, hvor en LLM genererer en output, der ikke er forkert, men mangler nøgledele af information, der var tilgængelige i konteksten.

For eksempel, når en bruger stiller et komplekst spørgsmål som “Hvad er de vigtigste punkter i dokument A, B og C?”, besvarer LLM kun en eller to af kilderne.

Hvordan FPs kompromitterer RAG-pipeline-performance

Hver af disse FPs påvirker performance af RAG-pipelines:

Data-integritet og tillid-fejl

Når manglende eller forkert information er til stede, er systemet ikke længere en pålidelig kilde til information. Primære FPs inkluderer:

• FP1 (Manglende indhold): Svaret er ikke i dokumentet fra starten.
• FP4 (Ikke udtrukket): LLM beslutter at ignorere det korrekte svar i dokumentet.
• FP7 (Ufuldstændig): LLM giver halvsandheder, mangler vigtige dele.

Henting og effektivitetsbottlenecks

RAG-pipeline’en kan være ineffektiv, når den mangler vigtig information i hentings- og konsolideringsfaserne. Primære FPs inkluderer:

• FP2 (Missede top-rangerede): Embedding-modellen fejler at vælge top-k-embeddings.
• FP3 (Konsolideringsstrategi): Skriptet til at trimme dokumenter til at passe LLM-grænserne dropper de vigtigste dele.

Brugeroplevelse og formateringsfejl

Selvom korrekt, kan en output med dårlig læselighed eller i forkert format kompromittere brugeroplevelsen. Primære FPs inkluderer:

• FP5 (Forkert format): LLM fejler at følge det specifikke output-format som JSON.
• FP6 (Forkert specifikation): LLM genererer en længere output til et simpelt ja/nej-spørgsmål eller omvendt (for kort svar til et komplekst spørgsmål).

Evalueringssættet: Rammer til at mindske FPs

Evalueringssættet er designet til at systematisk mindske disse FPs.

Denne sektion udforsker større evalueringssætt med praktiske brugs eksempler.

Større RAG-evalueringssætt:

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – Enhedstest før deployment

DeepEval beregner en vægtet score baseret på kriterierne.

En LLM-som-dommer (f.eks. GPT-4o) evaluerer hver kriterie imod en LLM’s output:

DeepEval udnytter G-eval, en kæde af tanker (CoT)-ramme, der tager en multi-trin-tilgang til at evaluere output:

1. Definér et kriterie til at måle (f.eks. “kohærens”, “flydende” eller “relevans”).
2. Generér evaluerings-trin (ved hjælp af en evaluator LLM).
3. Følg evalueringstrinet og analyserer input og LLM’s output.
4. Beregner en forventet vægtet sum af scoren for hvert kriterie.

Almindelig scenario i praksis

• Situation: En teknisk dokumentationsassistent (bot) for et komplekst softwareprodukt synes at fungere hver gang ingeniørteamet opdaterer kodebasen.
• Problem: Ingen kvantitativ bevis for, om bot’en kan besvare brugerforespørgslen (Du tror bare, det fungerer…).
• Løsning: Integrér en PyTest-funktion som CI/CD-regresstest-suite i Github Action, hvor DeepEval kører G-Eval og andre metrics over en test-sag:

• Forventede resultater: Hvis nogen af metrics-scoren falder under grænsen (0,85), rejser PyTest en AssertionError – og standsede straks bygningen af CI, og forhindrer, at den stille regression når produktion.

Fordele

• En række metrics (50+) inklusive specialiserede bias- og giftighedschecks er tilgængelige.
• Integrerer sammen med eksisterende CI/CD-pipelines.
• Ingen reference nødvendig. Vurderer en output baseret udelukkende på prompt og kontekst.

Ulemper

• Kvaliteten af evaluering afhænger stærkt af dommer-LLM’s kapaciteter.
• Computermæssigt dyrt, når dommer-LLM er en højendesk model.

Udvikler note – Test-sagen for DeepEval
En samling LLMTestCase-objekter definerer test-sagen, som DeepEval kører.

I praksis bør denne test-sag indeholde de vigtigste brugerforespørgsler og labelede outputs med den hentede kontekst.

Disse kan hentes fra en JSON- eller CSV-fil.

RAGAS – Nålen i en høstak-optimizer

Retrieval Augmented Generation Assessment (Ragas) har til formål at evaluere RAG uden menneske-annoterede dataset ved at generere syntetiske test-sæt.

Derefter beregner det flagship-metrics:

Figur B. RAGAS-evalueringstriaden, der forbinder Spørgsmål, Kontekst og Svar gennem Præcision, Recall, Troværdighed og Relevans-metrics (Oprettet af Kuriko IWAI)

Flagship-metrics er inddelt i tre grupper:

• Hentings-pipeline (sort, solid linje, Figur B): Kontekstpræcision, kontekst-recall.
• Genererings-pipeline (sort, stregelinje, Figur B): Troværdighed, svar-relevans.
• Ground truth (rød boks, Figur B): Svar-semantisk lignende, svar-korrekt.

Almindelig scenario i praksis

• Situation: RAG-systemet for juridiske kontrakter mangler nøgleklausuler. Du er usikker, om problemet er i Søgning (Retriever) eller Læsning (Generator).
• Problem: Ingen idé om, hvilken optimal top-k (antal hentede chunks).
• Løsning: Brug RAGAS til at oprette et syntetisk test-sæt med 100 par spørgsmål og bevis. Derefter kør RAG-pipeline’en mod test-sættet for at beregne kontekst-recall og kontekst-præcision:
• Forventede resultater: Afhængigt af metric-resultaterne kan handlingsplanen være følgende:

Tabel 1. RAGAS-diagnostisk handlingsplan – Mapping af scores til system-justeringer.

Fordele

• Udmærket til et tidligt projekt uden grund-sandheds-datasets (Som vi så i kode-eksemplet, kan RAGAS oprette et syntetisk test-sæt).

Ulemper

• Det syntetiske test-sæt kan misse nuancerede faktuelle fejl.
• Kræver en robust extractor-model til at bryde ned svar i enkeltstående krav (Jeg brugte gpt-4o i eksemplet).

TruLens – Feedback-loop-specialisten

TruLens fokuserer på de interne mekanismer i RAG-processen i stedet for kun den endelige output ved at bruge feedback-funktioner.

Det bruger også en LLM-baseret score, der reflekterer, hvor godt svaret tilfredsstiller spørgsmålets hensigt, ved hjælp af en 4-punkts Likert-skala (0-3), hvilket gør det overlegen til at rangere kvaliteten af forskellige søgeresultater.

Almindelig scenario i praksis

• Situation: En medicinsk rådgiver-bot besvarer en brugers spørgsmål korrekt, men tilføjer en pro-tip, der ikke er i den godkendte PDF-base.
• Problem: Tilføjelsen af pro-tip kan være nyttig, men ikke grundet.
• Løsning: Brug TruLens til at implementere en grundet feedback-funktion med en grænseværdi som score > 0,8.

• Forventede resultater: Når LLM genererer en output, der indeholder information, der ikke er til stede i de hentede chunks, flagger TruLens posten i din dashboard.

Fordele

• Visualiserer tanke-kæden for at identificere præcis, hvor agenten gik af sporet.
• Indbygget support til grundlæggelse for at fange hallucinationer i realtid.

Ulemper

• Læringskurve for at definere brugerdefinerede feedback-funktioner.
• Dashboard kan føles tungt for simple scripts.

Arize Phoenix – Den stille fejl-kort

Arize Phoenix er et open-source-observabilitets- og evalueringsværktøj til at evaluere LLM-outputs, herunder komplekse RAG-systemer.

Bygget på OpenTelemetry af Arize AI, fokuserer det på observabilitet ved at behandle LLM-evaluering som en undermængde af MLOps.

I konteksten af RAG-evaluering udmærker Phoenix sig ved embedding-analyse, ved hjælp af Uniform Manifold Approximation and Projection (UMAP) til at reducere høj-dimensionelle vektor-embeddings til 2D/3D-rum.

Denne embedding-analyse afslører matematisk, om de fejlede forespørgsler er semantisk grupperet sammen, hvilket indikerer en lukke i vektor-databasen.

Almindelig scenario i praksis

• Situation: En kunde-support-bot fungerer godt for refunderinger, men giver nonsens-svar til garantikrav.
• Problem: Data-hul i vektor-databasen (Kan ikke findes i logfiler).
• Løsning: Brug Arize Phoenix til at generere en Umap-Embedding-Visualisering (UEV), et 3D-kort for vektor-databasen – til at overlappe brugerforespørgsler på dokument-chunks.
• Forventede resultater: Visuelt se en klump af brugerforespørgsler, der lander i den mørke zone, hvor der ikke er nogen dokumenter, hvilket fortæller, at nogle dokumenter er glemt at uploade til vektor-lageret.

Fordele

• OpenTelemetry-naturlig; integrerer med eksisterende enterprise-overvågnings-stacks.
• Det bedste værktøj til at visualisere blindspots i vektor-lageret.

Ulemper

• Mindre fokuseret på scoring, mere på overvågning.
• Kan være overkill for små-skala-applikationer eller single-agent-værktøjer.

Braintrust – Prompt-regres-sikkerhedsnet

Braintrust er designet til højfrekvens-iteration-cykler ved at bruge cross-model-sammenligning.

Almindelig scenario i praksis

• Situation: Et ingeniør-team opgraderer prompt fra “Besvar spørgsmålet” (Sag A) til en mere kompleks 500-ord-system-instruktion (Sag B).
• Problem: Forbedring af prompt for Sag B kan utilsigtet ødelægge Sag A.
• Løsning: Brug Braintrust til at oprette en guldbase med et sæt af N perfekte eksempler (f.eks. N = 50). Lad Braintrust køre side-om-side (SxS)-sammenligning hver gang teamet opdaterer en enkelt ord i prompt:

• Forventede resultater: En forskelsrapport, der viser præcis, hvilke sager blev bedre/værre for hver af de guldbaser (N = 50).

Fordele

• Ekstremt hurtig til at teste før deployment.
• Godt UI for ikke-tekniske interessenter til at gennemgå og bedømme output.

Ulemper

• Proprietær/SaaS-fokuseret (selvom de har open-source-komponenter).
• Færre indbyggede dybde-tekniske metrics i forhold til DeepEval eller Ragas.

Afslutning

Når håndteret med passende evalueringssætt, kan RAG være et konkurrencedygtigt værktøj til at give en LLM kontekst, der er mest relevant for brugerforespørgslen.

Implementeringsstrategi: Mapping af metrics til fejlpoints

Selvom der ikke er en løsning, der passer til alle, viser Tabel 2, hvilke evalueringssætt der skal anvendes for hver FP, der er behandlet i denne artikel:

Tabel 2. Fejlpoint-mindsknings-matrix – Hvilet værktøj løser hvilket FP?

DeepEval og RAGAS kan udnytte deres troværdigheds-metrics til at måle data-integritets-fejl (FP1, FP4, FP7).

TruLens udnytter sin kontekst-præcision / recall til at måle kontekst-relevansen til output – effektivt vurderer FP2.

Arize Phoenix giver en visuel sporingsfunktion for hentings-processen, hvilket gør det let at se, om det hentede dokument blev tabt under konsolideringen (FP3).

Til UX-fejl kan DeepEval oprette brugerdefinerede metrics til at vurderer UX-fejl, mens Braintrust udmærker sig ved grund-sandhed-dataset-sammenligning.