DeepEval eller Ragas: CI-test og produksjonsmåling

Velg DeepEval når faste evalueringssaker skal kunne stoppe en endring i CI. DeepEvals CI-dokumentasjon viser hvordan assert_test brukes med pytest og kjøres med deepeval test run. Velg Ragas når hovedbehovet er å skille mellom svikt i gjenfinning, rangering og svar i en RAG-løsning.

Produksjonsmåling avgjøres ikke av metrikken alene: svar og hentet kontekst må samles inn, knyttes sammen og velges ut for evaluering. Ragas-dokumentasjonen for Context Precision skiller mellom vurdering mot et forventet svar og Context Utilization, som vurderer konteksten mot det genererte svaret. Det skillet bestemmer hvilke data en måling trenger, og hva skåren faktisk sier.

Bruk de samme sakene i begge rammeverk

En sammenligning begynner med én lagret rad per spørsmål: spørsmålet, de hentede tekstutdragene i faktisk rekkefølge, modellens svar og et forventet svar. Følgende lille datasett er et oppdiktet eksempel fra en abonnementstjeneste. Det viser ingen målte resultater eller vilkår hos en virkelig leverandør.

«Hvor avsluttes prøveperioden?» Hentet kontekst: først «Prøveperioden avsluttes i kontoinnstillingene», deretter «Faktura sendes månedlig». Både modellens svar og forventet svar er «I kontoinnstillingene».
«Hvilken støtte følger Basis?» Hentet kontekst: først «Basis omfatter e-poststøtte», deretter «Telefonstøtte følger Pluss». Modellens svar er «Telefonstøtte»; forventet svar er «E-poststøtte».
Gjenta det første spørsmålet og svaret, men legg utdraget om faktura først. Bare rekkefølgen på den hentede konteksten endres.

I DeepEval legges feltene i en LLMTestCase som input, retrieval_context, actual_output og expected_output. I Ragas tilsvarer de user_input, retrieved_contexts, response og reference. Lagre også versjonen av RAG-løsningen og dommermodellen sammen med radene; hvis svar eller utdrag hentes på nytt under sammenligningen, er det ikke lenger samme grunnlag som vurderes.

De to endringene i eksemplet isolerer ulike feil. Basis-raden har et svar som strider mot hentet kontekst, mens den siste raden beholder riktig svar og flytter et irrelevant utdrag foran det relevante. Dermed kan man undersøke svarets forankring og kontekstens rangering hver for seg, uten å hevde at de oppdiktede radene vil få en bestemt numerisk skår.

Hvilke metrikker svarer på samme spørsmål?

Faithfulness vurderer om påstandene i svaret har støtte i den hentede konteksten. Context precision vurderer om relevante utdrag kommer tidlig i den ordnede listen. Et svar kan derfor være godt forankret selv om rangeringen er svak, og et høyt rangert utdrag kan fortsatt ende i et svar som bruker opplysningene feil.

DeepEvals spesifikasjon for ContextualPrecisionMetric krever input, actual_output, expected_output og retrieval_context. Den bruker forventet svar til å bedømme hvilke utdrag som er relevante, før rekkefølgen får betydning for skåren. Ragas’ ContextPrecision kan bruke samme type fasitsvar, mens ContextUtilization bruker det genererte svaret når fasit mangler.

Den siste varianten gjør det mulig å vurdere kontekst uten et ferdig fasitsvar, men endrer spørsmålet som stilles til dommeren. Hvis modellen gir et overbevisende, feilaktig svar, kan utdrag som passer dette svaret fremstå som nyttige. I en fast testmengde er det derfor mer opplysende å beholde forventet svar; for løpende svar uten fasit kan ContextUtilization brukes med denne begrensningen i mente.

En reproduserbar minimumskonfigurasjon kan bruke den samme dommermodellen, for eksempel gpt-4o-mini, i begge rammeverk og en foreløpig beståttgrense på 0,8. DeepEval får model og threshold på de valgte metrikkene; i Ragas får metrikkene modellen via llm_factory, mens testkoden sammenligner returnert skår med 0,8. Lik modell og lik tallgrense gjør oppsettet sammenlignbart, men gjør ikke skårene utbyttbare: vurderingsinstruksjoner og beregning varierer mellom metrikkene.

Hva skjer når testen kjøres i CI?

DeepEval har den korteste veien fra lagret evalueringssak til en test som kan feile et bygg. Hver rad kan bli en parameterisert pytest-test som oppretter en LLMTestCase og kaller assert_test med de valgte metrikkene. Når en skår faller under sin grense, feiler testen; den faste mengden kan dermed kjøres ved hver relevant kodeendring.

Ragas kan brukes i samme CI-kjede, men sammenligningen mot terskel og feilkoden må legges i testkoden rundt skårene. Det er en liten, konkret forskjell for et team som allerede har pytest, og en viktig forskjell hvis flere feilede rader skal vises tydelig i en pullforespørsel. For agenter med verktøykall eller samtaler over flere turer må evalueringssakene også inneholde handlingene som skal vurderes; spørsmål-og-svar-radene ovenfor dekker bare en enkelt RAG-respons.

Hva kreves for løpende produksjonsmåling?

Produksjonsdata trenger sporing før de kan skåres meningsfullt. DeepEvals veiledning for RAG-sporing beskriver utvalg av spor og asynkron evaluering gjennom Confident AI. Plattformkoblingen er et eget ledd ved siden av de lokale CI-testene; veiledningen opplyser også at inndata og utdata fanges ordrett som standard, slik at personopplysninger må maskeres før eksport.

Med Ragas må sporene hentes fra en tilkoblet løsning eller et eget datalager. I Ragas-eksemplet med Phoenix kommer sporene fra Phoenix, Ragas beregner evalueringsskårene, og resultatene sendes tilbake som merknader på sporene. Det viser en mulig arbeidsdeling, ikke en innebygd produksjonsplattform som følger av å installere Ragas alene.

Uansett rammeverk må hvert målt svar kobles til spørsmålet og den konteksten som faktisk ble hentet. Utvalget bør dekke viktige spørsmålstyper og nye versjoner, ellers kan en samlet gjennomsnittsskår skjule at én sjelden, men viktig type svar er blitt dårligere. Saker uten fasit kan vurderes med metrikker som ikke krever reference eller expected_output; skårer som bygger på fasit, må vente til et slikt svar finnes.

Hva koster full kjøring sammenlignet med utvalg?

LLM-baserte dommere kan gjøre flere modellkall for én rad. Kostnaden bør derfor beregnes fra faktisk tokenbruk per ferdig evaluert rad, summert over metrikkene som skal kjøres, og deles i input- og outputtokener. Samme dommermodell gir ikke nødvendigvis samme forbruk i DeepEval og Ragas, fordi instruksjoner, antall vurderingstrinn og lengden på hentede utdrag kan variere.

Anta som rent regneeksempel at alle valgte metrikker samlet bruker 1 500 inputtokener og 300 outputtokener per rad, og at perioden gir 1 000 produksjonssvar. Full kjøring bruker da omtrent 1,5 millioner inputtokener og 0,3 millioner outputtokener. Et utvalg på 10 prosent, altså 100 svar, bruker omtrent 0,15 millioner inputtokener og 0,03 millioner outputtokener dersom radene i utvalget har samme gjennomsnittlige tokenbruk.

La P inn og P ut være leverandørens pris per million henholdsvis input- og outputtokener, målt i samme valuta. Dommerdelen av full kjøring blir da 1,5 × P inn + 0,3 × P ut; for utvalget blir den 0,15 × P inn + 0,03 × P ut. I dette betingede regnestykket faller den variable dommerbruken med 90 prosent, mens sjansen for å fange sjeldne feil også blir lavere. Nye forsøk etter feil, andre metrikker og eventuell bruk av embeddings må regnes i tillegg.

Hvilket valg passer behovet?

DeepEval passer best når en fast evalueringsmengde skal håndheves som en pytest-port for RAG, agenter eller andre LLM-applikasjoner. Ragas passer godt når analysen av RAG-svar og hentet kontekst står i sentrum, og teamet kan koble skårene til sin egen CI- og sporingsflyt. Har løsningen begge behov, kan de samme lagrede sakene brukes i begge rammeverk, mens terskler fastsettes separat ut fra hvilke feil hver metrikk faktisk fanger.

Les også: