Hvordan bygge pålitelige RAG: En dybdeundersøkelse av 7 feilpunkter og evalueringssystemer

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

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

Denne artikkelen gir en dybdeundersøkelse av syv typiske RAG-feilpunkter og evalueringssystemer med praktiske kodeeksempler.

RAG-feilpunkters anatomi – 7 feilpunkter (FPs)

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

Bildet under viser disse stadiene:

Figur A. Indexering og spørringsprosesser som kreves for å lage et RAG-system. Indexeringsprosessen gjøres på utviklingstid, og spørringer på kjøretid. Feilpunkter identifisert i denne studien er vist i røde bokser (kilde)

La oss utforske hver feilpunkt i henhold til pipeline-sekvensen, etter topp-venstre til bunnen-høyre fremgangen som vist i Figur A.

FP1. Manglende innhold

Manglende innhold skjer når systemet blir bedt om en 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 plausibel lydende, men feil respons i stedet for å si det vet ikke.

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 matet til en LLM som kontekst.

Som følge når den korrekte informasjonen aldri når 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å filtere dem ned for å passe innenfor en LLMs kontekstvindu, token-begrensninger eller ratelimiter.

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 en JSON-skjema.

FP6. Feil spesifisitet

En LLMs utdata er teknisk til stede, men enten for generell eller for kompleks 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 en utdata som ikke er nødvendigvis feil, men mangler nøkkelinformasjon som var tilgjengelig i konteksten.

For eksempel når en bruker spør et komplekst spørsmål som “Hva er hovedpunktene i dokument A, B og C?”, og LLM bare behandler ett 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 manglende eller feil informasjon er til stede, 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.

Henting og effisiensflaskehalser

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 om korrekt, kan en utdata med dårlig lesbarhet eller i feil format kompromittere brukeropplevelsen. Primære FPs inkluderer:

• FP5 (Feil format): LLM mislykkes i å følge det spesifikke utdataformatet som JSON.
• FP6 (Feil spesifisitet): 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 – Enheten-testen før deploy

DeepEval beregner en vektet score basert på kriteriene.

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

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

1. Definer et kriterium å måle (f.eks. “kohesjon”, “flyt” eller “relevans”).
2. Generer evalueringssteg (ved å bruke en vurderings-LLM).
3. Følg evalueringsteg og analyserer inndata og LLMs utdata.
4. Beregner en forventet vektet sum av hver 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 kvantitativ bevis på at boten kan fortsatt besvare brukerens spørsmål (Du bare “tror” det fungerer…).
• Løsning: Integrier en PyTest-funksjon som en CI/CD-regresjonstest i Github Action hvor DeepEval kjører G-Eval og andre metrikker over en testtilfelle:

• Forventet resultat: Hvis noen av metrikkens score faller under terskelen (0,85), vil PyTest-heisen AssertionError – og umiddelbart feiler CI-bygget, og forhindrer den stille tilbakeslaget fra å nå produksjon.

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 – Nålen i høystakken-optimizeren

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

Deretter beregner den flaggskipsmetrikker:

Figur B. RAGAS-evalueringstriaden som kobler Spørsmål, Kontekst og Svar gjennom Presisjon, Recall, Trofasthet 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): Trofasthet, svarrelevans.
• Grundvann (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 overlegen 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: Tilleggs-pro-tipen kan være nyttig, men ikke grunnlagt.
• Løsning: Bruk TruLens til å implementere en grunnlagt tilbakekoblingsfunksjon 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 – Den stille feil-kartet

Arize Phoenix er et åpen kilde-observasjon- og evalueringstool for å evaluere LLM-utdata, inkludert komplekse RAG-systemer.

Bygget på OpenTelemetry av Arize AI, fokuserer det på observasjon 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), en 3D-kart for vektor-databasen – for å legge brukerspørsmål over dokument-deler.
• Forventet resultat: Visuelt se en kluster av brukerspørsmål som lander i den mørke sonen hvor ingen dokumenter eksisterer, og indikerer at noen dokumenter er glemte å laste opp til vektor-lagringen.

Braintrust – Prompt-regresjonssikkerhetsnettet

Braintrust er designet for høyfrekvens-iterasjons-sykluser 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 som viser nøyaktig hvilke saker som ble bedre/dårligere for hver av de gylne datasettene (N = 50).

Oppsummering

Når håndtert med riktige evalueringssystemer, kan RAG være et konkurranse-dyktig 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 trofasthetsmetrikker til å måle data-integritetsfeil (FP1, FP4, FP7).

TruLens utnytter sin kontekst-presisjon / tilbakekobling 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).

For UX-feil, DeepEval lager tilpassede metrikker til å vurderer UX-feil, mens Braintrust utmerker seg i grunnvanns-datasett-sammenligning.