Så bygger du tillförlitlig RAG: sju felpunkter och ramverk för utvärdering

Retrieval-Augmented Generation (RAG) är avgörande för modern AI-arkitektur, och fungerar som en viktig ram för att bygga kontextmedvetna agenter.

Men att gå från en grundläggande prototyp till ett produktionsklart system innebär att man måste navigera betydande hinder i datahämtning, kontextkonsolidering och svarssyntes.

Den här artikeln ger en djupdykning i sju typiska RAG-felpunkter och utvärderingsmetriker med praktiska kodexempel.

RAG-sammanbrottets anatomi – 7 felpunkter (FP)

Enligt forskarna Barnett med flera stöter system för Retrieval Augmented Generation (RAG) på sju specifika felpunkter (FP) i pipelinen.

Nedan visas dessa faser:

Figur A. Indexerings- och frågeprocesser som krävs för att skapa ett RAG-system. Indexeringsprocessen görs under utvecklingstiden och frågorna under körningstiden. Felpunkter som identifierats i den här studien visas i röda rutor (källa)

Låt oss gå igenom varje FP i pipelineordning, från övre vänstra till nedre högra hörnet enligt Figur A.

FP1. Saknat innehåll

Saknat innehåll inträffar när systemet får en fråga som inte kan besvaras eftersom den relevanta informationen inte finns i den tillgängliga vektordatabasen från början.

Felet uppstår när en LLM ger ett trovärdigt men felaktigt svar i stället för att ange att den inte vet.

FP2. Missade topprankade dokument

Detta är en situation där ett korrekt dokument finns i vektordatabasen, men hämtningskomponenten misslyckas med att rangordna det tillräckligt högt för att inkludera det i topp-k-dokument som matas till en LLM som kontext.

Följden blir att den korrekta informationen aldrig når LLM.

FP3. Inte i kontext (konsolideringsstrategibegränsningar)

Detta är en situation där ett korrekt dokument finns och hämtas från vektordatabasen, men utesluts under konsolideringsprocessen.

Detta inträffar när för många dokument returneras och systemet måste filtrera bort dem för att passa inom en LLM:s kontextfönster, tokenbegränsningar eller hastighetsbegränsningar.

FP4. Informationen extraheras inte

Detta är en situation där en LLM misslyckas med att identifiera den korrekta informationen i kontexten, även om den korrekta informationen fanns i vektordatabasen och framgångsrikt hämtades/konsoliderades.

Detta inträffar när kontexten är för brusig eller innehåller motsägelsefull information som förvirrar LLM.

FP5. Fel format

Detta är en situation där lagring, hämtning, konsolidering och LLM-tolkning hanteras framgångsrikt, men LLM misslyckas med att följa specifika formateringsanvisningar som tillhandahålls i prompten, såsom en tabell, en punktlista eller ett JSON-schema.

FP6. Fel detaljnivå

En LLM producerar ett svar, men det är antingen för allmänt eller för komplext i förhållande till användarens behov.

Till exempel genererar en LLM enkla svar på en användarfråga med ett komplext yrkesmässigt mål.

FP7. Ofullständiga svar

Detta är en situation där en LLM genererar en utdata som inte nödvändigtvis är felaktig, men saknar viktiga delar av information som var tillgänglig i kontexten.

Till exempel när en användare ställer en komplex fråga som “Vilka är de viktigaste punkterna i dokument A, B och C?”, besvarar LLM endast en eller två av källorna.

Hur FP påverkar RAG-pipelineprestanda

Var och en av dessa FP påverkar prestandan för RAG-pipeliner:

Dataintegritet och tillförlitlighetsfel

När information saknas eller är felaktig är systemet inte längre en tillförlitlig källa till information. De främsta felpunkterna är:

• FP1 (Saknat innehåll): Svaret finns inte i dokumentet från början.
• FP4 (Informationen extraheras inte): LLM väljer att ignorera det korrekta svaret i dokumentet.
• FP7 (Ofullständig): LLM ger halvsanningar och utelämnar viktiga delar.

Hämtning och effektivitetsflaskhalsar

RAG-pipelinen kan vara ineffektiv när den missar viktig information i hämtnings- och konsolideringsstadierna. De främsta felpunkterna är:

• FP2 (Missade topprankade): Inbäddningsmodellen misslyckas med att välja topp-k-inbäddningar.
• FP3 (Konsolideringsstrategi): Skriptet för att trimma dokument för att passa LLM:s gränser utelämnar de viktigaste delarna.

Användarupplevelse och formateringsfel

Även om utdatan är korrekt, kan en utdata med dålig läsbarhet eller i fel format försämra användarupplevelsen. De främsta felpunkterna är:

• FP5 (Fel format): LLM misslyckas med att följa det specifika utdataformatet som JSON.
• FP6 (Fel detaljnivå): LLM genererar en omfattande utdata för en enkel ja/nej-fråga, eller vice versa (för kort svar på en komplicerad fråga).

Utvärderingsstacken: Ramverk för att mildra FP

Utvärderingsmetriker är utformade för att systematiskt mildra dessa FP.

Den här delen undersöker viktiga RAG-utvärderingsmått med praktiska användningsfall.

Viktiga RAG-utvärderingsmått:

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – Enhetstestet före distribution

DeepEval beräknar en viktad poäng baserat på kriterierna.

En LLM som domare (t.ex. GPT-4o) utvärderar varje kriterium mot en LLM:s utdata:

DeepEval använder G-eval, ett ramverk för tankekedjor (CoT) som använder flera steg för att utvärdera utdatan:

1. Definiera ett kriterium för att mäta (t.ex. “sammanhängande resonemang”, “flyt” eller “relevans”).
2. Generera utvärderingssteg (med en utvärderings-LLM).
3. Följ utvärderingsstegen och analysera indata och LLM:s utdata.
4. Beräkna en väntad viktad summa av poängen för varje kriterium.

Vanligt scenario i praktiken

• Situation: En teknisk dokumentationsassistent (bot) för en komplex programvaruprodukt verkar fungera varje gång utvecklingsteamet uppdaterar kodbasen.
• Problem: Inga kvantitativa bevis för att boten fortfarande kan besvara användarfrågan (Du “tror” bara att det fungerar…).
• Lösning: Integrera en PyTest-funktion som regressionstestsvit för CI/CD i GitHub Actions där DeepEval kör G-Eval och andra metriker över ett testfall:

• Väntade resultat: Om någon av metrikernas poäng sjunker under tröskeln (0,85) utlöser PyTest AssertionError – vilket omedelbart får CI-bygget att misslyckas och förhindrar att den tysta regressionen når produktion.

Utvecklarnotis – Testfallet för DeepEval
En uppsättning LLMTestCase-objekt definierar testfallet som DeepEval kör.

I praktiken bör detta testfall innehålla de viktigaste användarfrågorna och etiketterade utdata med den hämtade kontexten.

Dessa kan hämtas från en JSON- eller CSV-fil.

RAGAS – optimerar sökandet efter nålen i höstacken

Retrieval Augmented Generation Assessment (Ragas) syftar till att utvärdera RAG utan mänskligt annoterade datamängder genom att generera syntetiska testuppsättningar.

Sedan beräknar den de viktigaste måtten:

Figur B. RAGAS-utvärderingstriaden som kopplar fråga, kontext och svar genom precision, täckningsgrad, källtrohet och relevansmetriker (Skapad av Kuriko IWAI)

De viktigaste måtten delas in i tre grupper:

• Hämtningspipeline (svart heldragen linje, Figur B): Kontextprecision, kontextens täckningsgrad.
• Genereringspipeline (svart prickad linje, Figur B): Källtrohet, svarrelevans.
• Referensdata (röd ruta, Figur B): Svarens semantiska likhet, svarens korrekthet.

Vanligt scenario i praktiken

• Situation: RAG-systemet för juridiska kontrakt saknar viktiga klausuler. Du är osäker på om problemet är i sökningen (hämtningskomponenten) eller läsningen (generatorn).
• Problem: Ingen kunskap om optimalt topp-k (antalet hämtade chunkar).
• Lösning: Använd RAGAS för att skapa en syntetisk testuppsättning med 100 par frågor och bevis. Kör sedan RAG-pipelinen mot testuppsättningen för att beräkna kontextens täckningsgrad och kontextprecision:
• Väntat resultat: Beroende på metrikresultaten kan åtgärdsplanen vara följande:

Tabell 1. RAGAS-diagnostisk åtgärdsplan – Mappning av poäng till systemjusteringar.

TruLens – Återkopplingscirkelns specialist

TruLens fokuserar på RAG-processens interna mekanismer snarare än bara den slutliga utdatan genom att använda återkopplingsfunktioner.

Det använder också en LLM-baserad poäng som reflekterar hur väl svaret tillfredsställer frågans avsikt, med en 4-punkts Likert-skala (0-3), vilket gör det överlägset för att rangordna kvaliteten på olika sökresultat.

Vanligt scenario i praktiken

• Situation: En medicinsk rådgivare-bot svarar på en användarfråga korrekt men lägger till ett extratips som inte finns i den granskade PDF-basen.
• Problem: Extratipset kan vara användbart men saknar stöd i källmaterialet.
• Lösning: Använd TruLens för att implementera en återkopplingsfunktion för att mäta förankring i källmaterialet med en tröskel som score > 0.8.

• Väntade resultat: När LLM genererar ett svar som innehåller information som inte finns i de hämtade chunkarna flaggar TruLens posten i din instrumentpanel.

Arize Phoenix – kartan över tysta fel

Arize Phoenix är ett verktyg med öppen källkod för observerbarhet och utvärdering för att utvärdera LLM-utdata, inklusive komplexa RAG-system.

Byggt på OpenTelemetry av Arize AI, fokuserar det på observerbarhet genom att behandla LLM-utvärdering som en undermängd av MLOps.

I RAG-utvärderingens sammanhang utmärker sig Phoenix i inbäddningsanalys, med Uniform Manifold Approximation and Projection (UMAP) för att minska högdimensionella vektorinbäddningar till 2D/3D-utrymme.

Denna inbäddningsanalys avslöjar matematiskt om de misslyckade frågorna är semantiskt grupperade tillsammans, vilket indikerar ett gap i vektordatabasen.

Vanligt scenario i praktiken

• Situation: En kundsupport-bot fungerar bra för återbetalningar, men ger nonsenssvar på garantikrav.
• Problem: Datahål i vektordatabasen (Kan inte hittas i loggar).
• Lösning: Använd Arize Phoenix för att generera en Umap-inbäddningsvisualisering (UEV), en 3D-karta för vektordatabasen – för att överlagra användarfrågor på dokumentchunkar.
• Väntade resultat: Visuellt se ett kluster av användarfrågor som landar i den mörka zonen där inga dokument finns, vilket indikerar att man har glömt att ladda upp vissa dokument till vektordatabasen.

Braintrust – säkerhetsnätet mot promptregressioner

Braintrust är utformat för högfrekventa itereringscykler med modelljämförelse.

Vanligt scenario i praktiken

• Situation: Ett utvecklingsteam uppgraderar prompten från “Svara på frågan” (Fall A) till en mer komplex systeminstruktion på 500 ord (Fall B).
• Problem: Att förbättra prompten för Fall B kan oavsiktligt bryta Fall A.
• Lösning: Använd Braintrust för att skapa en referensdatamängd med ett antal N perfekta exempel (t.ex. N = 50). Låt Braintrust köra en jämförelse sida vid sida (SxS) varje gång teamet uppdaterar ett enda ord i prompten:

• Väntat resultat: En skillnadsrapport som visar exakt vilka fall i referensdatamängden (N = 50) som blev bättre eller sämre.

Sammanfattning

När RAG hanteras med lämpliga utvärderingsramverk kan det vara ett konkurrenskraftigt verktyg för att tillhandahålla LLM-kontext som är mest relevant för användarfrågan.

Implementeringsstrategi: Mappning av metriker till felpunkter

Även om det inte finns någon universallösning visar Tabell 2 vilka utvärderingsmetriker som ska tillämpas för var och en av FP som behandlats i den här artikeln:

Tabell 2. Felpunktsbegränsningsmatrisen – Vilket verktyg löser vilken FP?

DeepEval och RAGAS kan utnyttja sina källtrohetsmetriker för att mäta dataintegritetsfel (FP1, FP4, FP7).

TruLens utnyttjar sin kontextprecision / täckningsgrad för att mäta kontextrelevansen för utdatan – vilket effektivt utvärderar FP2.

Arize Phoenix tillhandahåller en visuell spårning av hämtningsprocessen, vilket gör det lätt att se om det hämtade dokumentet gick förlorat under konsolideringen (FP3).

För UX-fel skapar DeepEval anpassade metriker för att utvärdera UX-fel, medan Braintrust utmärker sig i jämförelser mot referensdatamängder.