RAG-utvärdering: Testa hämtning innan du justerar LLM

RAG-utvärdering bör börja med hämtning. Om den rätta bevisningen aldrig når modellen, gör promptjusteringar och modelluppgraderingar bara den felaktiga kontexten mer övertygande. Testa hämtning, generation och operationer som separata steg. Håll en liten, versionshanterad regressionsuppsättning som misslyckas när något steg blir sämre.

Läsarnivå: Medel. Denna guide förutsätter att du vet att hämtning-augmented generation, eller RAG, hittar dokument innan den ber en språkmodell att svara.

I denna guide

RAG-utvärdering har tre separata misslyckandeytor

En RAG-applikation är en pipeline. En poäng för det slutliga svaret döljer vilken komponent som behöver arbete.

Ordningen spelar roll. Hämtning är uppströms. En generator kan inte citera ett policydokument som aldrig kom in i sin kontext, och ett flytande svar bevisar inte att hämtaren fungerade.

Microsofts nuvarande RAG-evaluator-dokumentation gör samma separation i implementationsvillkor. Den tillhandahåller dokumenthämtningmått för rankad bevisning, och utvärderar sedan förankring, relevans och svarens fullständighet på svarsplanet. Dokumenthämtningsevalueringen inkluderar trohet, NDCG, XDCG, maximal relevans och saknade relevansbedömningar.

_Ett användbart RAG-poängkort håller hämtning, generation och operationella kontroller synliga som separata lager._

Varför en end-to-end-poäng ger svaga felsökningsbevis

Flera forskningsramverk når samma praktiska slutsats från olika riktningar.

RAGChecker utvärderar hämtarens och generatorns beteende separat. Dess författare jämförde åtta RAG-system över tio domäner. Deras mått inkluderar påståendets recall och kontextens precision för hämtning, plus kontextanvändning, brusets känslighet, hallucination och trohet för generation. I en 280-pars meta-utvärdering hade RAGCheckers övergripande bedömningspoäng en Spearman-korrelation på 0.609 med mänsklig preferens. De två mänskliga annotatorerna nådde 0.689. Automatisk utvärdering var användbar, men den tog inte bort den mänskliga klyftan.

Ragas föreslog referensfria mått för trohet, svarrelevans och kontextrelevans. I sina WikiEval-jämförelser var överensstämmelsen med mänskliga preferenser 0.95 för trohet, 0.78 för svarrelevans och 0.70 för kontextrelevans. Författarna fann att kontextrelevans var svårast att bedöma. Behandla dessa siffror som resultat från den studien, inte universella noggrannhetsgrader för varje domare, dataset eller domän.

Ett nyare ramverk, RAGe, lägger till komponentval och hårdvaru-telemetri. Det utvärderar pipeline-konfigurationer över chunking, inbäddning, hämtning, lagring och generation samtidigt som det beskär kombinationer som överskrider latens- eller VRAM-gränser. Artikeln använder Natural Questions, NewsQA och TriviaQA som standard och stöder anpassade CSV- eller JSON-dataset. Dess huvudsakliga bidrag är ett sätt att jämföra kvalitet med resursbegränsningar; det fastställer inte en konfiguration som vinner över domäner.

Tillsammans stöder dessa artiklar en diagnostisk metod. De bevisar inte att ett särskilt mått eller bibliotek är tillräckligt för produktion.

Bygg en testuppsättning innan du väljer mått

Börja med 40 till 60 frågor från den domän du betjänar. Det intervallet är en praktisk utgångspunkt snarare än en statistisk lag. Det är tillräckligt stort för att avslöja flera typer av misslyckanden och tillräckligt litet för att en människa ska kunna granska efter varje materiell förändring.

Inkludera minst fem frågeklasser:

Produktionsloggar kan föreslå frågor, men ta bort personuppgifter och hemligheter innan du lägger till exempel i en utvärderingsuppsättning. En nyligen praktiker-diskussion om produktion RAG-utvärdering betonar också fasta frågor, versionshanterade konfigurationer och separata hämtning- och generationskontroller. Den diskussionen är anekdotiska bevis om arbetsflödesproblem, inte bevis för att metoden fungerar i varje system.

Spara bedömningar mot stabila dokument-ID:n tillsammans med eventuell kopierad text. Chunk-gränser ändras när du justerar en splitter. Ett kanoniskt käll-ID låter samma test överleva den förändringen.

{ "query_id": "refund-window-01", "query": "Hur länge har en kund på sig att returnera en oöppnad vara?", "relevant_document_ids": ["returns-policy-v4"], "required_claims": ["Oöppnade varor kan returneras inom 30 dagar."], "must_abstain": false, "allowed_roles": ["customer", "support"], "as_of": "2026-07-01" }

För ett obesvarligt fall, sätt `relevant_document_ids` till en tom lista och `must_abstain` till `true`. För ett begränsat fall, kör samma fråga under två roller. Den auktoriserade användaren bör hämta dokumentet; den obehöriga användaren bör inte få veta innehållet i det dokumentet.

Team som bygger sin egen korpus och applikationslager bör versionshantera innehållskontraktet tillsammans med testuppsättningen. Samma regel gäller för anpassade datorsystem byggda med Next.js och AI: en schema- eller innehållsförändring kan ändra hämtning utan att röra prompten.

Steg 1: utvärdera hämtning utan att generera ett svar

Kör varje fråga genom hämtaren och spara de rankade resultat-ID:erna, poängen, tidsstämplarna och åtkomstbesluten. Anropa inte språkmodellen ännu.

Välj mått som matchar bevisform

Använd hit rate@k när ett korrekt dokument är tillräckligt. Det frågar om minst en relevant källa visas i de första `k` resultaten.

Använd recall@k när svaret kräver flera källor. Det mäter hur många kända relevanta dokument som dök upp i de första `k`.

Använd precision@k när irrelevant kontext är kostsamt eller distraherande. Hög recall med låg precision kan översvämma generatorn med brus.

Använd MRR när det första relevanta resultatet är viktigast. Använd NDCG när flera graderade resultat bör visas i en användbar ordning. Microsoft dokumenterar NDCG och relaterade rankade hämtningmått i sin evaluator, medan RAGChecker använder påståendets recall och kontextens precision för att koppla hämtad bevisning till de påståenden som ett svar behöver.

Samla inte in varje mått som standard. Välj ett täckningsmått och ett ranknings- eller brusmått. Lägg till ett mått endast när det ändrar ett beslut.

Klassificera missar innan du ändrar modellen

Hämtningens misslyckanden faller vanligtvis in i en liten uppsättning:

Varje misslyckande har en annan ägare. Att återinbädda kan inte reparera ett saknat dokument. En större språkmodell kan inte reparera ett behörighetsfilter. En omrankare kan hjälpa när bevisningen är närvarande men dåligt ordnad.

För verktygsanslutna applikationer, bevara hämtningens begäran, filter, resultat-ID:n och verktygsresponsen i spåret. Det passar det bredare kontrollmönster som beskrivs i MCP-utvecklararbetsflöden: inspektera kontraktet, tillståndsövergången och den slutliga prosa.

Steg 2: utvärdera generation över fast bevisning

När hämtningen når sin tröskel, frysa de hämtade kontexterna och spela upp dem mot generatorn. Detta isolerar prompt- eller modelländringar från indexändringar.

Mät fyra beteenden:

Ett referenssvar kan hjälpa med fullständighet. Det är mindre användbart som den enda sanningskällan eftersom flera formuleringar kan vara korrekta. Spara nödvändiga påståenden och stödjande dokument-ID:n när det är möjligt.

Kör ett andra generationstest med avsiktligt ofullständig kontext. Ett pålitligt system bör avslöja osäkerhet snarare än att fylla luckor från modellens minne. Detta är viktigt när korpusen innehåller privata, föränderliga eller domänspecifika fakta.

Valet av modell påverkar fortfarande svarskvalitet, latens och kostnad, men det kommer efter hämtningens bevis. Om samma fasta kontext misslyckas över generatorer, jämför modell- och API-avvägningar. Om kontexten i sig är fel, är det slöseri med rörelse att byta generator.

Lägg till säkerhets- och konfliktfall i hämtningens uppsättning

Vanliga relevanstester missar motstridiga eller konfliktbevis.

En artikel från juli 2026 om polymorf sybil-förgiftning i RAG testade grupper av lexikalt olika avsnitt som stödde samma angriparvalda svar. Under artikelns tvångsexponeringsupplägg producerade polymorfa avsnitt en 22.8% kapningsgrad jämfört med 4.0% för upprepade monomorfa avsnitt. Token-överlapp filtrering fångade alla monomorfa kluster och inga av de polymorfa klustren.

Resultatet mäter inte hur ofta denna attack lyckas i produktion. Författarna fastställde den hämtade blandningen till sex attackavsnitt, två guldavsnitt och två fyllmedel för att isolera läsarens beteende. De rapporterar också begränsningar kring en attackklass, dataset-kontaminationsrisk, en 500-frågeablation och LLM-baserad verifiering.

Den användbara utvärderingslektionen är smalare: klassificera mer än "korrekt" och "angriparmål." Artikeln spårar fyra resultat:

Lägg till konfliktfall i din egen uppsättning. Inkludera duplicerade påståenden med olika formuleringar, en gammal källa som motsäger den aktuella policyn och en lägre tillitskälla som står i konflikt med en auktoritativ. Registrera om systemet svarar, avstår eller driver.

Kalibrera LLM-domare innan du litar på deras poäng

LLM-domare gör regressionsprovning billigare, särskilt för förankring och påståendets täckning. De förblir programvarudependens med prompts, modellversioner, parserbeteende och kända blinda fläckar.

Använd fyra kontroller:

Ragas och RAGChecker-studierna visar båda varför kalibrering är viktig. Överensstämmelse varierar beroende på dimension, och automatiserade korrelationer förblir under mänsklig överensstämmelse. En numerisk poäng bör utlösa inspektion, inte avsluta den.

Nuvarande öppen källkodsutgåvor visar också aktivt arbete kring utvärderare. DeepEval 4.1.3, släppt den 12 juli 2026, lade till deterministiska kontroller för agentloopar och verktygsbehörigheter samtidigt som den fixade Ragas-integration. TruLens 2.9.0, släppt den 23 juli, lade till domarensemble, A/B-kriterietester, poängfördelningsanalys och gulduppsättningsgenerering. Utgivningsaktivitet är bevis på underhållen ingenjörsarbete, inte bevis för att något av biblioteken är rätt val för din stack.

Ett minimalt RAG-regressionsarbetsflöde

Använd samma sekvens för varje materiell pipelineändring:

En kompakt resultatpost kan se ut så här:

{ "run_id": "rag-2026-07-26-b", "test_set": "support-v7", "corpus_snapshot": "2026-07-25T22:00:00Z", "retrieval": { "recall_at_5": 0.91, "ndcg_at_5": 0.84, "unauthorized_hits": 0 }, "generation": { "grounded_pass_rate": 0.94, "complete_pass_rate": 0.87, "abstention_pass_rate": 0.90 }, "operations": { "p95_ms": 1380, "cost_per_query_usd": 0.0042 } }

Dessa siffror är illustrativa. Sätt trösklar utifrån din risk, baslinje och felkostnad. En medicinsk kunskapsassistent och en produkt-sökhjälpare bör inte dela samma utgivningsport.

Bestäm åtgärden utifrån det misslyckade lagret

Denna tabell är punkten för RAG-utvärdering: en misslyckad poäng bör identifiera nästa experiment. Om den inte kan, är måttet för långt ifrån den komponent du behöver ändra.

Vad bevisningen stöder

Artiklarna mätte specifika system och dataset. RAGChecker fann att modulära mått kan korrelera med mänskliga preferenser och avslöja hämtar-generator-avvägningar. Ragas fann att domarens överenskommelse varierade över trohet, svarrelevans och kontextrelevans. RAGe demonstrerade en ram som kombinerar kvalitetsmått med latens- och minnesbegränsningar. Förgiftningens benchmark visade att en begränsad attackuppsättning producerade distinkta kapnings-, avhållande- och driftmönster.

Bevisningen fastställer inte universella trösklar, en universellt bästa utvärderare eller produktionens attackprevalens. Min praktiska tolkning är att separera stegen, hålla en mänskligt kalibrerad skiva och kräva att varje mått pekar på en ingenjörsåtgärd.

Påståendekontroller

Källor