Sådan bygger du pålidelig RAG: syv fejlpunkter og evalueringsrammer

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 kræver, at man overvinder betydelige hindringer i datahenting, kontekstkonsolidering og svarsyntese.

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

RAG-fejlenes anatomi – 7 fejlpunkter (FP)

Ifølge forskerne Barnett og kolleger møder Retrieval Augmented Generation (RAG)-systemer syv specifikke fejlpunkter (FP) i pipeline’en.

Det 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 gennemgå hvert fejlpunkt i pipeline-rækkefølge fra øverst til venstre til nederst til 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 det tilgængelige vektorlager fra starten.

Fejlen opstår, når en LLM leverer et plausibelt, men forkert svar i stedet for at sige at den ikke ved det.

FP2. Det korrekte dokument når ikke topplaceringerne

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 et JSON-skema.

FP6. Forkert detaljeringsgrad

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å et brugerspørgsmål med et komplekst professionelt formål.

FP7. Ufuldstændige svar

Dette er en situation, hvor en LLM genererer et output, der ikke nødvendigvis 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 information mangler eller er forkert, 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 og udelader vigtige oplysninger.

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

Selv hvis indholdet er korrekt, kan et 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 detaljeringsgrad): LLM genererer et langt 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

Evalueringsmetrikker er designet til systematisk at mindske disse FPs.

Denne sektion undersøger de vigtigste evalueringsmetrikker med praktiske anvendelseseksempler.

De vigtigste RAG-evalueringsmetrikker:

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – Enhedstesten før idriftsættelse

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

En LLM som dommer (f.eks. GPT-4o) evaluerer en LLM’s output ud fra hvert kriterium:

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

1. Definer et kriterium til at måle (f.eks. “kohærens,” “sproglig flydende form” eller “relevans”).
2. Generer evalueringstrin (ved hjælp af en evaluator LLM).
3. Følg evalueringstrinene og analyser input og LLM’s output.
4. Beregn en forventet vægtet sum af scoren for hvert kriterium.

Almindeligt scenario i praksis

• Situation: En teknisk dokumentationsassistent (bot) for et komplekst softwareprodukt synes at fungere hver gang ingeniørteamet opdaterer kodebasen.
• Problem: Intet kvantitativt bevis for, om botten stadig kan besvare brugerens spørgsmål (Du tror bare, det fungerer…).
• Løsning: Integrer en PyTest-funktion som CI/CD-regressionsuite i GitHub Actions, hvor DeepEval kører G-Eval og andre metrikker over en test case:

• Forventet resultat: Hvis scoren for en af metrikkerne falder under tærsklen (0,85), rejser PyTest en AssertionError – hvilket straks får CI-bygget til at fejle 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 – optimerer søgningen efter nålen i høstakken

Retrieval Augmented Generation Assessment (Ragas) fokuserer på at evaluere RAG uden datasæt annoteret af mennesker ved at generere syntetiske testsæt.

Derefter beregner den centrale metrikker:

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

De centrale metrikker er inddelt i tre grupper:

• Hentingspipeline (sort, fuldt optrukket linje, Figur B): Kontekstpræcision, kontekstens dækning.
• Generationspipeline (sort, stiplet linje, Figur B): Kildetrofasthed, svarrelevans.
• Ground truth (rød boks, Figur B): Svarenes semantiske lighed, svarkorrekthed.

Almindeligt 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 et syntetisk testsæt med 100 par spørgsmål og bevis. Kør derefter RAG-pipelinen på testsættet for at beregne kontekstens dækning 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 – Specialisten i feedbacksløjfer

TruLens fokuserer på de interne mekanismer i RAG-processen snarere end kun på det 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 overlegent til at rangere kvaliteten af forskellige søgeresultater.

Almindeligt scenario i praksis

• Situation: En medicinsk rådgiver-bot besvarer en brugers spørgsmål korrekt, men tilføjer et ekstra tip, der ikke er i den godkendte PDF-base.
• Problem: Det ekstra tip kan være nyttigt, men det er ikke underbygget af kildematerialet.
• Løsning: Brug TruLens til at implementere en feedbackfunktion, der vurderer belæg i kildematerialet, med en tærskel som score > 0.8.

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

Arize Phoenix – Kortet over skjulte fejl

Arize Phoenix er et open-source værktøj til observerbarhed og evaluering 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 et hul i vektordatabasen.

Almindeligt 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), et 3D-kort for vektor-databasen – for at lægge brugerforespørgsler oven på dokumentudsnittene.
• Forventede 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.

Almindeligt scenario i praksis

• Situation: Et ingeniørteam opgraderer prompt fra “Besvar spørgsmålet” (Sag A) til en mere kompleks systeminstruktion på 500 ord (Sag B).
• Problem: Forbedring af prompt for Sag B kan utilsigtet ødelægge Sag A.
• Løsning: Brug Braintrust til at oprette et referencedatasæt 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 præcist viser, hvilke tilfælde i referencedatasættet (N = 50) der blev bedre eller værre.

Afslutning

Med passende evalueringsrammer 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 evalueringsmetrikker 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 metrikker for kildetrofasthed til at måle dataintegritetsfejl (FP1, FP4, FP7).

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

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

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