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

Retrieval-Augmented Generation (RAG) er afgørende 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 et produktionsklart system indebærer navigation af betydelige hindringer i datahenting, kontekstkonsolidering og svarsyntese.

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

RAG-fejlernes anatomi – 7 fejlpunkter (FP)

Ifølge forskerne Barnett et al., Retrieval Augmented Generation (RAG) systemer møder syv specifikke fejlpunkter (FP) i 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 udviklingstid, og forespørgsler under køretid. Fejlpunkter identificeret i denne undersøgelse er vist i røde bokse (kilde)

Lad os undersøge hver FP ordnet efter pipeline-sekvensen, følger progressionen fra øverste venstre til nederste højre 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 et plausibelt, men forkert svar 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 henteren 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 (konsolideringsstrategiens begrænsninger)

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

Dette sker, når der returneres for mange dokumenter, og systemet må filtrere dem ned for at være inden for en LLM’s kontekstvindue, tokenbegrænsninger eller ratebegrænsninger.

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 hentet/konsolideret.

Dette sker, når konteksten er for støjfuld eller indeholder modstridende information, der forvirrer LLM.

FP5. Forkert format

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

FP6. Forkert specifikation

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

For eksempel genererer en LLM simple svar på en brugerspørgsmål med et komplekst professionelt formål.

FP7. Ufuldstændige svar

Dette er en situation, hvor en LLM genererer en output, der ikke er forkert, men mangler nøgleinformationer, 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 RAG-pipelines performance:

Dataintegritet og tillidsfejl

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 vælger at ignorere det korrekte svar i dokumentet.
• FP7 (Ufuldstændig): LLM giver halvsandheder, mangler vigtige dele.

Henting og effektivitetsflaskehals

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

• FP2 (Missede top-rangerede): Embedding-modellen kan ikke vælge top-k-embeddings.
• FP3 (Konsolideringsstrategi): Skriptet til at trimme dokumenter for at være inden for LLM’s begrænsninger 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 kan ikke følge det specifikke outputformat som JSON.
• FP6 (Forkert specifikation): LLM genererer en længere output for et simpelt ja/nej-spørgsmål, eller omvendt (for kort svar til et komplekst spørgsmål).

Evalueringssystemet: Rammer til at mindske FPs

Evalueringssystemer er designet til at systematisk mindske disse FPs.

Denne sektion undersøger de vigtigste evalueringssystemer med praktiske brugs eksempler.

De vigtigste RAG-evalueringssystemer:

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – Enheden test 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-trins tilgang til at evaluere output:

1. Definer et kriterie til at måle (f.eks. “kohærens,” “flydende” eller “relevans”).
2. Generer 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 hver kriteries score.

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 brugerens spørgsmål (Du tror bare, det fungerer…).
• Løsning: Integrer en PyTest-funktion som CI/CD-regressionsuite i Github Action, hvor DeepEval kører G-Eval og andre metrikker over en test case:

• Forventet resultat: Hvis nogen af metrikkerne falder under thresholden (0,85), rejser PyTest en AssertionError – og fejler straks CI-bygningen, og forhindrer, at den stille regression når produktion.

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

I praksis bør denne testcase indeholde de vigtigste brugerspørgsmål og mærkede outputs med den hentede kontekst.

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

RAGAS – Den skarpeste i høst

RAGAS fokuserer på at evaluere RAG uden menneske-annoterede dataset ved at generere syntetiske test sæt.

Derefter beregner den flagship-metrikker:

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

Flagship-metrikkerne er inddelt i tre grupper:

• Hentingspipeline (sort, solid linje, Figur B): Kontekstpræcision, kontekstgenkald.
• Generationspipeline (sort, stribet linje, Figur B): Troværdighed, svarrelevans.
• Ground truth (rød boks, Figur B): Svarsemantisk lignende, svarkorrekthed.

Almindelig scenario i praksis

• Situation: RAG-systemet for juridiske kontrakter mangler vigtige klausuler. Du er usikker, om problemet er i Søgning (Henter) eller Læsning (Generator).
• Problem: Ingen idé om det optimale top-k (antal hentede stykker).
• Løsning: Brug RAGAS til at oprette en syntetisk test sæt med 100 par spørgsmål og bevis. Derefter kør RAG-pipeline mod test sættet for at beregne kontekstgenkald og kontekstpræcision:
• Forventet resultat: Afhængigt af metrikresultaterne kan handlingsplanen være følgende:

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

TruLens – Feedback-funktionsspecialisten

TruLens fokuserer på de interne mekanismer i RAG-processen snarere end kun på den endelige output ved hjælp af feedback-funktioner.

Det bruger også en LLM-baseret score, der reflekterer, hvor godt svaret tilfredsstiller spørgsmålets formål, 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 grundlagt.
• Løsning: Brug TruLens til at implementere en grundlagt feedback-funktion med en threshold som score > 0,8.

• Forventet resultater: Når LLM genererer et svar, der indeholder information, der ikke er til stede i den hentede kontekst, flagger TruLens posten i din dashboard.

Arize Phoenix – Den stille fejlkort

Arize Phoenix er et open-source overvågnings- og evalueringssystem til at evaluere LLM-outputs, herunder komplekse RAG-systemer.

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

I sammenhæng med RAG-evaluering udmærker Phoenix sig ved embedding-analyse, ved hjælp af Uniform Manifold Approximation and Projection (UMAP) til at reducere højdimensionale 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 kundesupport-bot fungerer godt for refunderinger, men giver meningsløse svar på garantikrav.
• Problem: Datahul i vektor-databasen (Kan ikke findes i logfiler).
• Løsning: Brug Arize Phoenix til at generere en Umap-embedding-visualisering (UEV), en 3D-kort for vektor-databasen – for at lagre brugerforespørgsler på dokumentstykker.
• Forventet resultater: Visuelt se en klump af brugerforespørgsler, der lander i den mørke zone, hvor der ikke findes nogen dokumenter, hvilket fortæller, at nogle dokumenter er glemt at uploade til vektor-lageret.

Braintrust – Prompt-regressions sikkerhedsnet

Braintrust er designet til højfrekvens-iteration-cykler ved hjælp af cross-model-sammenligning.

Almindelig scenario i praksis

• Situation: Et ingeniørteam opgraderer prompt fra “Besvar spørgsmålet” (Sag A) til en mere kompleks 500-ords 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 gulddataset 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 et enkelt ord i prompt:

• Forventet resultat: En forskelsrapport, der viser præcis, hvilke tilfælde blev bedre/værre for hver af de gulddata (N = 50).

Afslutning

Når håndteret med passende evalueringssystemer, kan RAG være et konkurrencedygtigt værktøj til at give en LLM kontekst, der er mest relevant for brugerens spørgsmål.

Implementeringsstrategi: Mapping af metrikker til fejlpunkter

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

Tabel 2. Fejlpunkt-mitigeringsmatrix – Hvilket værktøj løser hvilket FP?

DeepEval og RAGAS kan udnytte deres troværdigheds-metrikker til at måle dataintegritetsfejl (FP1, FP4, FP7).

TruLens udnytter sin kontekstpræcision / genkald til at måle kontekst-relevans til output – effektivt vurderer FP2.

Arize Phoenix giver en visuel sporingsproces, der gør det let at se, om dokumentet, der blev hentet, blev tabt under konsolidering (FP3).

For brugeroplevelsesfejl, DeepEval opretter brugerdefinerede metrikker til at vurderer brugeroplevelsesfejl, mens Braintrust udmærker sig ved grund-sandhedsdataset-sammenligning.