Hur man bygger tillförlitlig RAG: En djupdykning i 7 felpunkter och utvärderingsramverk

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 dataåtervinning, 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 forskare Barnett et al., Retrieval Augmented Generation (RAG) system stöter på sju specifika felpunkter (FP) i pipelineen.

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 undersöka varje FP i pipeline-ordning, följande den övre vänstra till nedre högra progressionen som visas i Figur A.

FP1. Saknad 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.

Feltillfället inträffar 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 återställaren 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.

I följd med detta når den korrekta informationen aldrig 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. Inte uttagen

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 bullrig eller innehåller motsägelsefull information som förvirrar LLM.

FP5. Fel format

Detta är en situation där lagring, återvinning, 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 specifikation

En LLM:s utdata är tekniskt sett närvarande, men antingen för allmän eller för komplex 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 saknad eller felaktig information är närvarande är systemet inte längre en tillförlitlig källa till information. Primära FP inkluderar:

• FP1 (Saknad innehåll): Svaret finns inte i dokumentet från början.
• FP4 (Inte uttagen): LLM väljer att ignorera det korrekta svaret i dokumentet.
• FP7 (Ofullständig): LLM ger halvsanningar, saknar viktiga delar.

Återvinning och effektivitetsflaskhalsar

RAG-pipelinen kan vara ineffektiv när den missar viktig information i återvinnings- och konsolideringsstadierna. Primära FP inkluderar:

• 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 släpper den viktigaste delen.

Användarupplevelse och formateringsfel

Även om utdatan är korrekt, kan en utdata med dålig läsbarhet eller i fel format kompromettera användarupplevelsen. Primära FP inkluderar:

• FP5 (Fel format): LLM misslyckas med att följa det specifika utdataformatet som JSON.
• FP6 (Fel specifikation): LLM genererar en omfattande utdata för ett enkelt ja/nej-svar, 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 stora RAG-utvärderingsmetriker med praktiska användningsfall.

Stora RAG-utvärderingsmetriker:

• 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 kedja av tankar (CoT)-ramverk som tar en flerstegsapproach för att utvärdera utdatan:

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

Vanligt scenario i praktiken

• Situation: En teknisk dokumentationsassistent (bot) för ett komplext 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 CI/CD-regressionsuite i Github Action 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) höjer PyTest AssertionError – vilket omedelbart misslyckar CI-bygget 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 – Nålen i höstacken-optimera

RAGAS syftar till att utvärdera RAG utan mänskligt annoterad dataset genom att generera syntetiska testuppsättningar.

Sedan beräknar den flaggskeppsmetrikerna:

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

Flaggskeppsmetriken delas in i tre grupper:

• Återvinningpipeline (svart, fast linje, Figur B): Kontextprecision, kontextåterkallande.
• Genereringspipeline (svart, prickad linje, Figur B): Trohet, svarrelevans.
• Grundfakta (röd ruta, Figur B): Svarssemantisk likhet, svarkorrekthet.

Vanligt scenario i praktiken

• Situation: RAG-systemet för juridiska kontrakt saknar viktiga klausuler. Du är osäker på om problemet är i Sök (Återställare) eller Läs (Generator).
• Problem: Inga idéer om den optimala 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. Sedan kör RAG-pipelinen mot testuppsättningen för att beräkna kontextåterkallande 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 en pro-tip som inte finns i den granskade PDF-basen.
• Problem: Tilläggspro-tippen kan vara användbar, men inte grundad.
• Lösning: Använd TruLens för att implementera en grundad återkopplingsfunktion med en tröskel som poäng > 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 – Den tysta felkarten

Arize Phoenix är ett öppen källkods- och utvärderingsverktyg för att utvärdera LLM-utdata, inklusive komplexa RAG-system.

Byggt på OpenTelemetry av Arize AI, fokuserar det på övervakning 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 en kluster av användarfrågor som landar i den mörka zonen där inga dokument finns, vilket indikerar att vissa dokument har glömts bort att laddas upp till vektordatabasen.

Braintrust – Promptregressions säkerhetsnät

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 500-ords systeminstruktion (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 gyllene dataset med ett antal N perfekta exempel (t.ex. N = 50). Låt Braintrust köra sida vid sida (SxS) jämförelse varje gång teamet uppdaterar ett enda ord i prompten:

• Väntat resultat: En skillnadsrapport som visar exakt vilka fall som blev bättre/sämre för var och en av de gyllene dataset (N = 50).

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 trohetsmetriker för att mäta dataintegritetsfel (FP1, FP4, FP7).

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

Arize Phoenix tillhandahåller en visuell spårning av återvinningsprocessen, 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 grundfakta-datasetjämförelse.