Slik bygger du pålitelig RAG: sju feilpunkter og evalueringsrammeverk i dybden

Retrieval-Augmented Generation (RAG) er kritisk for moderne AI-arkitektur, og fungerer som et essensielt rammeverk for å bygge kontekstbevisste agenter.

Men å gå fra en enkel prototype til et produksjonsklart system innebærer å overvinne betydelige hindringer i datahenting, kontekst-konsolidering og respons-syntese.

Denne artikkelen gir en grundig gjennomgang av syv typiske RAG-feilpunkter og evalueringssystemer med praktiske kodeeksempler.

RAG-feilpunkters anatomi – 7 feilpunkter (FPs)

Ifølge forskerne Barnett og kolleger møter Retrieval Augmented Generation (RAG) systemer syv spesifikke feilpunkter (FPs) gjennom hele pipelineen.

Bildet under viser disse stadiene:

Figur A. Indeksering og spørringsprosesser som kreves for å lage et RAG-system. Indekseringsprosessen gjøres under utviklingen, og spørringer ved kjøring. Feilpunkter identifisert i denne studien er vist i røde bokser (kilde)

La oss gå gjennom hvert feilpunkt i pipeline-rekkefølge, fra øverst til venstre mot nederst til høyre, som vist i Figur A.

FP1. Manglende innhold

Manglende innhold skjer når systemet får et spørsmål som ikke kan besvares fordi den relevante informasjonen ikke er til stede i den tilgjengelige vektorlagringen fra begynnelsen av.

Feil skjer når en LLM gir en tilsynelatende plausibel, men feil respons i stedet for å si at den ikke vet.

FP2. Gikk glipp av topp-rangerte dokumenter

Dette er en situasjon hvor et korrekt dokument eksisterer i vektorlagringen, men henteren mislykkes i å rangere det høyt nok til å inkludere det i topp-k dokumenter som gis til en LLM som kontekst.

Dermed når den korrekte informasjonen aldri frem til LLM.

FP3. Ikke i kontekst (konsolideringsstrategi-begrensninger)

Dette er en situasjon hvor et korrekt dokument eksisterer og hentes fra vektorlagringen, men ekskluderes under konsolideringsprosessen.

Dette skjer når for mange dokumenter returneres og systemet må filtrere dem ned for å passe innenfor en LLMs kontekstvindu, token-begrensninger eller grenser for forespørselsfrekvens.

FP4. Ikke ekstrahert

Dette er en situasjon hvor en LLM mislykkes i å identifisere den korrekte informasjonen i konteksten, selv om den korrekte informasjonen var i vektorlagringen og ble suksessfullt hentet/konsolidert.

Dette skjer når konteksten er for støyende eller inneholder motsigende informasjon som forvirrer LLM.

FP5. Feil format

Dette er en situasjon hvor lagring, henting, konsolidering og LLM-tolkning håndteres suksessfullt, men LLM mislykkes i å følge spesifikke formateringsinstruksjoner gitt i prompten, som en tabell, en punktliste eller et JSON-skjema.

FP6. Feil detaljnivå

En LLM produserer riktignok et svar, men det er enten for generelt eller for komplekst i forhold til brukerens behov.

For eksempel genererer en LLM enkle svar på en brukers spørsmål med et komplekst profesjonelt mål.

FP7. Ufullstendige svar

Dette er en situasjon hvor en LLM genererer et resultat som ikke nødvendigvis er feil, men mangler nøkkelinformasjon som var tilgjengelig i konteksten.

For eksempel stiller en bruker et komplekst spørsmål som “Hva er hovedpunktene i dokument A, B og C?”, men LLM behandler bare én eller to av kildene.

Hvordan FPs kompromitterer RAG-pipeline-ytelse

Hver av disse FPs påvirker ytelsen til RAG-pipelines:

Data-integritet og tillitsfeil

Når informasjon mangler eller er feil, er systemet ikke lenger en pålitelig kilde til informasjon. Primære FPs inkluderer:

• FP1 (Manglende innhold): Svaret er ikke i dokumentet fra begynnelsen av.
• FP4 (Ikke ekstrahert): LLM bestemmer seg for å ignorere det korrekte svaret i dokumentet.
• FP7 (Ufullstendig): LLM gir halvsannheter, mangler viktige deler.

Flaskehalser i henting og effektivitet

RAG-pipelineen kan være ineffektiv når den mangler nøkkelinformasjon i hentings- og konsolideringsstadiene. Primære FPs inkluderer:

• FP2 (Gikk glipp av topp-rangerte): Embeddingsmodellen mislykkes i å velge topp-k-embeddings.
• FP3 (Konsolideringsstrategi): Skriptet for å trimme dokumenter for å passe innenfor LLMs begrensninger dropper de viktigste delene.

Brukeropplevelse og formateringsfeil

Selv et korrekt resultat kan svekke brukeropplevelsen hvis det er vanskelig å lese eller har feil format. Primære FPs inkluderer:

• FP5 (Feil format): LLM mislykkes i å følge det spesifikke utdataformatet, som JSON.
• FP6 (Feil detaljnivå): LLM genererer en lang utdata for et enkelt ja/nei-spørsmål, eller omvendt (for kort svar til et komplisert spørsmål).

Evalueringssystemet: Rammeverk for å mildne FPs

Evalueringssystemer er designet for å systematisk mildne disse FPs.

Denne delen utforsker større evalueringssystemer med praktiske bruksområder.

Større RAG-evalueringssystemer:

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – Enhetstesten før utrulling

DeepEval beregner en vektet score basert på kriteriene.

En LLM som dommer (f.eks. GPT-4o) vurderer hvert kriterium mot en LLMs utdata:

DeepEval utnytter G-eval, et chain-of-thought (CoT)-rammeverk som tar en flertrinns-tilnærming til å evaluere utdataen:

1. Definer et kriterium å måle (f.eks. “sammenheng”, “flyt” eller “relevans”).
2. Generer evalueringssteg (ved å bruke en vurderings-LLM).
3. Følg evalueringstrinnene og analyser inndata og LLMs utdata.
4. Beregn en forventet vektet sum av hvert kriteriums score.

Vanlig scenario i praksis

• Situasjon: En teknisk dokumentasjonsassistent (bot) for et komplekst programvareprodukt ser ut til å fungere hver gang ingeniørteamet oppdaterer kodebasen.
• Problem: Ingen kvantitative bevis for at boten fortsatt kan besvare brukerens spørsmål (Du bare “tror” det fungerer…).
• Løsning: Integrer en PyTest-funksjon som en CI/CD-regresjonstest i GitHub Actions hvor DeepEval kjører G-Eval og andre metrikker på et testtilfelle:

• Forventet resultat: Hvis scoren for noen av metrikkene faller under terskelen (0,85), utløser PyTest AssertionError – CI-bygget feiler umiddelbart, slik at en ubemerket regresjon ikke når produksjonsmiljøet.

Utviklermerknad – Testtilfelle for DeepEval
En samling LLMTestCase-objekter definerer testtilfellet som DeepEval kjører.

I praksis bør dette testtilfellet inneholde de viktigste brukerspørsmålene og merkte utdata med hentet kontekst.

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

RAGAS – Optimalisering av nålen i høystakken

Retrieval Augmented Generation Assessment (Ragas) har som mål å evaluere RAG uten et datasett annotert av mennesker ved å generere syntetiske testsett.

Deretter beregner den flaggskipsmetrikker:

Figur B. RAGAS-evalueringstriaden som kobler Spørsmål, Kontekst og Svar gjennom Presisjon, Recall, Kildetrohet og Relevans-metrikker (Laget av Kuriko IWAI)

Flaggskipsmetrikkerne er kategorisert i tre grupper:

• Hentingspipeline (svart, solid linje, Figur B): Kontekstpresisjon, kontekstrecall.
• Genereringspipeline (svart, stiplet linje, Figur B): Kildetrohet, svarrelevans.
• Referansefasit (rød boks, Figur B): Svarsemantisk likhet, svarkorrekthet.

Vanlig scenario i praksis

• Situasjon: RAG-systemet for juridiske kontrakter mangler nøkkelklausuler. Du er usikker på om problemet er i Søk (Henter) eller Lese (Generator).
• Problem: Ingen idé om den optimale topp-k (antall hentede deler).
• Løsning: Bruk RAGAS til å lage et syntetisk testsett med 100 par spørsmål og bevis. Deretter kjør RAG-pipelineen mot testsettet for å beregne kontekstrecall og kontekstpresisjon:
• Forventet resultat: Avhengig av metrikkresultatene, kan handlingsplanen være følgende:

Tabell 1. RAGAS-diagnostisk handlingsplan – Mapping av metrikker til systemjusteringer.

TruLens – Tilbakekoblingsfunksjonsspesialisten

TruLens fokuserer på de interne mekanismene i RAG-prosessen i stedet for bare den endelige utdataen ved å bruke tilbakekoblingsfunksjoner.

Det bruker også en LLM-basert score som reflekterer hvor godt svaret tilfredsstiller spørsmålets intensjon, ved å bruke en 4-punkts Likert-skala (0-3), noe som gjør det særlig godt egnet for å rangere kvaliteten på forskjellige søkeresultater.

Vanlig scenario i praksis

• Situasjon: En medisinsk rådgiver-bot svarer på en brukers spørsmål korrekt, men legger til en pro-tip som ikke er i den verifiserte PDF-basen.
• Problem: Tilleggstipset kan være nyttig, men er ikke støttet av disse kildene.
• Løsning: Bruk TruLens til å implementere en tilbakekoblingsfunksjon som kontrollerer støtte i kildene med en terskel som score > 0.8.

• Forventet resultat: Når LLM genererer en respons som inneholder informasjon som ikke er til stede i de hentede delene, flagger TruLens posten i dashbordet ditt.

Arize Phoenix – Feilkartet

Arize Phoenix er et verktøy med åpen kildekode for observerbarhet og evaluering for å evaluere LLM-utdata, inkludert komplekse RAG-systemer.

Bygget på OpenTelemetry av Arize AI, fokuserer det på observerbarhet ved å behandle LLM-evaluering som en undergruppe av MLOps.

I sammenheng med RAG-evaluering, utmerker Phoenix seg i embedding-analyse, ved å bruke Uniform Manifold Approximation and Projection (UMAP) til å redusere høydimensjonale vektor-embeddings til 2D/3D-rom.

Denne embedding-analysen avslører matematisk om de feilede spørsmålene er semantisk gruppert sammen, noe som indikerer et hull i vektor-databasen.

Vanlig scenario i praksis

• Situasjon: En kundesupport-bot fungerer godt for refusjoner, men gir meningsløse svar på garanti-krav.
• Problem: Data-hull i vektor-databasen (Kan ikke finnes i loggene).
• Løsning: Bruk Arize Phoenix til å generere en Umap-embedding-visualisering (UEV), et 3D-kart for vektor-databasen – for å legge brukerspørsmål over dokument-deler.
• Forventet resultat: Du ser visuelt en klynge av brukerspørsmål i den mørke sonen uten dokumenter, noe som viser at noen dokumenter ble glemt da data skulle lastes opp til vektorlagringen.

Braintrust – Prompt-regresjonssikkerhetsnettet

Braintrust er designet for hyppige iterasjonssykluser ved å bruke kryss-modell-sammenligning.

Vanlig scenario i praksis

• Situasjon: Et ingeniørteam oppgraderer prompt fra “Svar på spørsmålet” (Sak A) til en mer kompleks 500-ords system-instruksjon (Sak B).
• Problem: Forbedring av prompten for Sak B kan utilsiktet ødelegge Sak A.
• Løsning: Bruk Braintrust til å lage et gull-datasett med et sett av N perfekte eksempler (f.eks. N = 50). La Braintrust kjøre side-om-side (SxS) sammenligning hver gang teamet oppdaterer ett enkelt ord i prompten:

• Forventet resultat: En forskjellsrapport viser nøyaktig hvilke av alle N = 50 referansetilfellene som ble bedre eller dårligere.

Oppsummering

Med riktige evalueringsrammeverk kan RAG være et konkurransedyktig verktøy for å gi en LLM kontekst som er mest relevant for brukerens spørsmål.

Implementeringsstrategi: Mapping av metrikker til feilpunkter

Selv om det ikke finnes en løsning som passer alle, viser Tabell 2 hvilke evalueringssystemer som bør brukes for hver FP vi dekket i denne artikkelen:

Tabell 2. Feilpunkt-mildningsmatrisen – Hvilket verktøy løser hvilket FP?

DeepEval og RAGAS kan utnytte sine metrikker for kildetrohet til å måle data-integritetsfeil (FP1, FP4, FP7).

TruLens utnytter sin kontekstpresisjon og recall til å måle kontekst-relevans til utdataen – og effektivt vurderer FP2.

Arize Phoenix gir en visuell sporingsprosess for hentingen, og gjør det enkelt å se om dokumentet som ble hentet ble tapt under konsolideringen (FP3).

Ved UX-feil lager DeepEval tilpassede metrikker til å vurdere UX-feil, mens Braintrust utmerker seg i sammenligning med datasett med referansefasit.