Hoe je de kwaliteit van lokale RAG-opvragingen meet en recall, precisie en citatiedekking interpreteert
De kwaliteit van lokale RAG is meetbaar wanneer gelabeld bewijsmateriaal, retrievalmetrics en controles op citaten op claimniveau afzonderlijk worden geëvalueerd op een representatieve queryset.
Een vloeiend antwoord kan een gemiste bron verbergen, terwijl een sterke retriever correcte passages kan aanleveren aan een generator die er slecht naar verwijst. Begin met queries waarvan de relevante chunks bekend zijn en beoordeel vervolgens de top-k-lijst voordat je antwoorden genereert. Citatendekking hoort bij de antwoordlaag en mag niet worden gebruikt als vervanging voor recall van retrieval.
Maak ground truth voordat je een metric berekent
Identificeer voor elke testquery alle acceptabele bewijschunks of ten minste een verdedigbare beoordelingspool. Neem directe opzoekvragen, synthesevragen, gevallen met actualiteit, afkortingen, talen en bevoegdheidsgrenzen op. Splits vragen die voor tuning worden gebruikt van een achtergehouden testset.
Een praktisch overzicht van RAG-evaluatie raadt aan retriever- en generatorcomponenten afzonderlijk te evalueren, omdat end-to-end-scores de oorzaak van een fout niet kunnen lokaliseren.
Ground truth kan in een grote bibliotheek onvolledig zijn. Verzamel resultaten van meerdere retrievers, beoordeel de unie en markeer onzekere gevallen in plaats van elke niet-beoordeelde chunk irrelevant te noemen. Zwakke labels leveren nauwkeurig ogende maar misleidende metrics op.
Recall en precision beantwoorden verschillende retrievalvragen
Recall@k is het aantal relevante chunks dat in de top k is opgehaald, gedeeld door het totale aantal bekende relevante chunks. Precision@k is het aantal relevante chunks in de top k, gedeeld door k. Een hogere k verbetert de recall doorgaans, maar laat ook meer ruis toe. Lees de twee metrics daarom samen.
De klassieke definities van precision en recall beschrijven deze afweging in information retrieval. Ze houden geen rekening met de rangpositie. Voeg daarom MRR of nDCG toe wanneer vroeg bewijs belangrijk is.
Een query met één relevante passage heeft een Recall@5 van 1,0 als die passage ergens in vijf resultaten voorkomt, maar de Precision@5 is slechts 0,2. Dat kan acceptabel zijn voor een reranker, maar te veel ruis opleveren voor een generator met een kleine context. De metricdoelen hangen af van het beschikbare downstream-bewijsbudget.
Citatendekking toetst claims, geen links
Splits het gegenereerde antwoord op in controleerbare claims. Citatendekking is het aantal ondersteunde claims gedeeld door het aantal claims waarvoor bewijs nodig is. Citaatcorrectheid vraagt of elke geciteerde passage de bijbehorende claim daadwerkelijk ondersteunt. Een antwoord kan veel links bevatten en toch een slechte dekking hebben.
Recent onderzoek naar citaatbewuste retrieval evalueert querydekking en de verifieerbaarheid van atomische claims, omdat één geaggregeerde relevantiescore geen niet-ondersteunde fragmenten in een antwoord kan blootleggen.
Citatendekking verliest haar betekenis wanneer claims niet consistent worden gesegmenteerd of wanneer algemene kennis en brongebonden claims zonder beleid worden vermengd. Ook kan ze niet bewijzen dat het antwoord volledig is. Meer citaten betekenen niet automatisch een betere onderbouwing.
Gebruik een beslisregel die diagnostische scheiding behoudt
Voer retrieval eerst uit en sla gerangschikte chunk-ID's, scores en versies op. Bereken Recall@k, Precision@k, MRR of nDCG, genereer vervolgens antwoorden uit de bevroren resultaten en beoordeel faithfulness, antwoordrelevantie, citatendekking en citaatcorrectheid.
Een gecontroleerde set RAG-evaluatiemetrics rapporteert contextual precision, contextual recall, faithfulness en antwoordrelevantie samen. Dit illustreert waarom geen enkele score volstaat.
Laat een release alleen doorgaan wanneer de recall van retrieval de ondergrens haalt, precision binnen het contextbudget blijft en elke inhoudelijk belangrijke claim in het antwoord wordt ondersteund of expliciet van een voorbehoud wordt voorzien. Als recall tekortschiet, verbeter dan de indexering of retrieval. Als citaten tekortschieten terwijl het juiste bewijs aanwezig is, verbeter dan de generatie en attributie.
Pas één release gate toe op retrieval en citaten
Bouw minstens 50 representatieve queries voor een klein huishoudelijk systeem en breid dit uit naar 100–200 naarmate het aantal documenttypen en talen groeit. Beoordeel top-5- en top-10-bewijs, bevries de resultatenset en controleer daarna de gegenereerde claims. Rapporteer macro-gemiddelden plus de slechtst presterende querysegmenten.
Bewaar de test naast de inhoud over RAG-formaatevaluatie, zodat bronnen met veel tabellen en verhalende bronnen worden vertegenwoordigd in plaats van samen gemiddeld. Versiebeheer elke chunk-ID en elk relevantieoordeel.
Gebruik initiële ondergrenzen, zoals een Recall@5 van 0,85 en een citaatcorrectheid van 0,95, alleen als lokale startwaarden en niet als universele standaarden. Verscherp ze op basis van het risico. Ruil nooit correcte bevoegdheden of niet-ondersteunde claims met grote impact in voor een hogere geaggregeerde score.
Aanbevolen producten
Tech & AI HUB
Meer om te lezen
Waarom wordt computation in smart homes belangrijker naarmate het aantal sensoren toeneemt bij dezelfde bemonsteringsfrequentie?
Houd de berekeningen per sensor en tussen sensoren bij naarmate het aantal apparaten toeneemt, identificeer niet-lineaire fusiekosten en benchmark de functiepijplijn voordat automatiseringen vertraging...
Waarom worden de kosten van RAG-evaluatie belangrijker naarmate de documentbibliotheek groeit bij hetzelfde aantal zoekopdrachten?
Begrijp waarom groei van het corpus de evaluatie-inspanning voor RAG verhoogt zonder meer gebruikersvragen, en hoe gestratificeerde tests de kosten aan het risico koppelen.
Waarom wordt de overhead van agenttools belangrijker naarmate het aantal workflowstappen toeneemt bij dezelfde modelgrootte?
Breng in kaart hoe seriële wachttijden, contextgroei, herpogingen en betrouwbaarheid zich opstapelen over agentstappen heen, en meet vervolgens de uitvoeringsoverhead afzonderlijk van de modelinferentie.
