RAG kiértékelése: retrieval metrikák, faithfulness, és hogyan derül ki, melyik fele hibázott

A legtöbb RAG-rendszer egy demó alapján kerül élesbe. Valaki feltesz öt kérdést, a válaszok jónak tűnnek, a csapat megy tovább. Aztán nő a korpusz, megváltozik a chunkolás, frissítik a modellt, és senki sem tudja megmondani, jobb lett-e a rendszer vagy rosszabb. A „jó ez?” kérdésre az őszinte válasz egy újraszámolható szám, RAG esetén pedig ehhez egynél több szám kell.

Az ok szerkezeti. A RAG-rendszer két, egymás után kötött rendszer: egy retriever, amely eldönti, mit lát a modell, és egy generátor, amely eldönti, mit mond róla. Mindkettő a maga módján hibázik, saját metrikákat igényel, és más munkával javítható. Ha csak a végső választ pontozod, egy rossz válasz azt mondja meg, hogy valami elromlott, de azt nem, hogy hol.

Ez a cikk azt mutatja meg, hogyan állítanék fel RAG-kiértékelést egy termékcsapatnak: a metrikákat és azt, hogy mindegyik valójában mit mér, a valódi kérdésekből épített golden setet, az emberekkel ellenőrzött LLM-bírót, a megnézésre érdemes eszközöket, a CI-ban futó evalokat, és egy rövid eljárást annak diagnosztizálására, hogy a retrieval vagy a generálás hibázott. Az LLM-es termékfunkciók evaljairól és magáról a RAG-pipeline-ról szóló írásaimra épül.

Két fél, hét szám

A RAGAS-tanulmány a RAG-kiértékelést három dimenzió mentén írja le: a retrieval képessége releváns és fókuszált passzusok megtalálására, a generátor képessége ezek hű felhasználására, és a kimenet minősége. A gyakorlatban a számokat aszerint osztom fel, milyen kérdésre felelnek. A retrieval metrikák azt kérdezik: odaért-e a megfelelő anyag a modellhez, jó sorrendben? A generálási metrikák azt: azzal, amit látott, helyesen viselkedett-e a modell?

A táblázat azokat a metrikákat sorolja fel, amelyeket valóban használok. A nevek eszközönként eltérnek, ezért azt írom le, mit mér mindegyik, nem azt, hogyan hívja egy könyvtár.

Vedd észre, hogy a context precision a retrievalhez tartozik, bár gyakran a generálási metrikák mellett szerepel. A lekért chunkokon számolják, ezért a rangsorolóról mond el valamit, nem a modell fogalmazásáról. A réteg oszlop pontossága teszi lehetővé a cikk későbbi diagnózisát.

Retrieval metrikák: recall@k, MRR és nDCG

A retrieval metrikák a keresés kiértékeléséből származnak, és kell hozzájuk valami, ami a generálási metrikákhoz nem: az, hogy tudjuk, mely chunkok relevánsak az egyes kérdésekhez.

• A recall@k azt kérdezi, hogy a releváns anyag benne van-e a top k-ban. Ez a legfontosabb retrieval szám, mert plafon. Ha a választ tartalmazó chunk nincs benne a modellnek átadott k chunk között, a modell nem tudja arra alapozni a válaszát, bármit is mond a prompt. A k-t ahhoz igazítsd, amennyit valójában a generátornak küldesz.
• Az MRR (mean reciprocal rank) az első releváns találat rangjának reciprokát átlagolja: 1 az első helyre, 0,5 a másodikra. Jutalmazza, ha egy jó chunk felülre kerül. Dokumentált korlátja, hogy csak az első releváns találat számít, a továbbiakat figyelmen kívül hagyja, ezért egyetlen helyes passzusú kérdéseknél használható, és félrevezet, ha a kérdés többet igényel.
• Az nDCG a fokozatos relevanciapontokat logaritmikus leértékeléssel összegzi a lejjebb lévő pozíciókra, majd elosztja az ideális sorrenddel, így az eredmény 0 és 1 közé esik. Akkor ez a megfelelő metrika, ha a relevancia nem bináris, például egy chunk teljesen megválaszolja a kérdést, egy másik csak említi a témát, és ha a sorrend számít, mert a kontextusablak vagy egy reranker határértéke megvágja a listát.

Együtt olvasom őket. Magas recall@k gyenge MRR-rel vagy nDCG-vel azt jelenti: a jó chunkot megtalálja, de eltemeti, amit általában egy reranker javít (a chunkolásról, a hibrid keresésről és a rerankingről lásd a pipeline-bejegyzést). Alacsony recall@k azt jelenti, hogy a jó chunkot sosem találja meg. Ez a chunkolás, az embeddingek, a query rewriting vagy az index problémája, és egy reranker sem javít meg olyan jelöltlistát, amely nem tartalmazza a választ.

Ezekhez a metrikákhoz relevanciacímkék kellenek, és ez a drága rész. A Ragas dokumentációja a context recallnak ír egy azonosító-alapú és egy nem LLM-es változatát, amely a lekért chunkazonosítókat vagy szövegeket hasonlítja a referenciakontextusokhoz LLM-hívás nélkül. Ezek olcsók, determinisztikusak és tökéletesek CI-ba, ha a golden set eltárolja, mely chunkok relevánsak.

Generálási metrikák: faithfulness és válaszrelevancia

A generálási metrikák a választ aszerint ítélik meg, amit a modell látott. A központi a faithfulness. A Ragas definíciója szerint ez a válasz azon állításainak száma, amelyeket a lekért kontextus alátámaszt, osztva az összes állítás számával: a választ állításokra bontják, mindegyiket a kontextushoz mérik, és az arány a 0 és 1 közötti pontszám. Nem kell hozzá referenciaválasz, ezért olyan hasznos éles forgalmon.

A válaszrelevancia azt kérdezi, hogy a válasz egyáltalán a kérdéssel foglalkozik-e. Egy válasz lehet tökéletesen hű a kontextushoz, és mégis kikerülheti a kérdést, például egy dokumentumot foglal össze, amikor a felhasználó egy számot kért. A TruLens a megfelelőjét context relevance, groundedness és answer relevance hármasnak hívja, a Ragas response relevancynek, a DeepEval answer relevancynek. Ugyanaz az ötlet, más címkék.

Két tulajdonságot könnyű elnézni. Először: a faithfulness a lekért kontextussal való egyezést méri, nem az igazsággal. Ha a retrieval egy elavult szabályzatot hozott, egy tökéletesen faithful válasz téves. Másodszor: magas pontszámot úgy is lehet szerezni, hogy keveset mondunk: az a modell, amely elutasít vagy köntörfalaz, kevés állítást tesz, és kevés állítás mind alátámasztott lehet. A faithfulnesst mindig a válaszrelevancia és a golden válaszhoz mért helyességi ellenőrzés mellett olvasd.

A golden set felépítése valódi kérdésekből

Minden fentebbi egy golden setre épül: kérdésekre azokkal az elvárásokkal, amelyekhez pontozol. A dokumentumaidból generált szintetikus kérdések hasznos kezdőlépések, de a dokumentumok szókincsét használják, a valódi felhasználók pedig nem. A valódi kérdésekben van elgépelés, rövidítés, homályos megfogalmazás, termékkód és olyan kérdés, amelyre a korpusz nem tud válaszolni. Ezekből építeném a készletet.

1. Valódi kérdések mintavételezése. Vedd őket keresési naplókból, support jegyekből vagy chat-átiratokból. Előbb távolítsd el a személyes adatokat, és figyelj a jogalapra: lásd a GDPR-ról és az LLM API-król írt jegyzeteimet.
2. Rétegezz, ne csak mintavételezz. Legyenek benne a gyakori kérdések, a hosszú farok, a több dokumentumra kiterjedő kérdések, a pontos azonosítós kérdések, és olyanok, amelyekre „nem tudom” a helyes válasz, mert a korpuszban nincs válasz.
3. Rögzítsd, mit igényel a helyes válasz. Kérdésenként jegyezd fel a releváns chunkokat vagy dokumentumokat (a recall@k-hoz, az MRR-hez és az nDCG-hez), egy rövid referenciaválaszt, és ahol számít, a válaszban kötelezően szereplő tényeket.
4. Címkéztesd szakértővel, és mérd, hogy ketten egyetértenek-e. Ha két ember nem ért egyet abban, mi releváns, ezt egyetlen metrika sem oldja meg helyetted.
5. Verziózd, és tarts vissza egy részt. Kezeld a készletet kódként. Tarts meg egy szeletet, amelyre sosem hangolsz, hogy a javulás ne csak a megbámult példákra való túlillesztés legyen.
6. Táplálja az éles üzem. Minden lájkolás-visszavonás, eszkaláció vagy a reviewban talált rossz válasz új esetté válik a címkéjével együtt. Így marad a készlet reprezentatív, ahogy a termék változik.

Mekkora legyen? Néhány tucat jól címkézett kérdéssel kezdeném, és onnan bővíteném; egy kicsi, tiszta készlet, amelyben megbízol, jobb egy nagynál, amelyet senki sem ellenőrzött. Az elején nem statisztikai erő a cél, hanem hogy a regresszió még aznap látható legyen, amikor megjelenik. Ahogy nő a készlet, rétegenként jelents, mert az átlag elrejti az egyik kérdéstípus összeomlását.

Diagnózis: a retrieval vagy a generálás hibázott?

Ha rossz választ jelentenek, állj ellen a kísértésnek, hogy a promptot szerkeszd. Járd végig a láncot alulról, az adott kérdéshez eltárolt retrieval-eredményekkel, és állj meg az első kérdésnél, amelyre „nem” a válasz.

Az ágak különböző munkához vezetnek. A tartalmi hiány szerkesztői vagy ingestion-probléma: a dokumentum hiányzik, elavult, vagy sosem parsolták rendesen. A retrieval hibát a chunkolásban, az embeddingekben, a hibrid keresésben, a query rewritingban vagy a rerankingben javítják. A nem faithful válasz generálási probléma: szigorítsd az utasítást, hogy csak a kontextusból válaszoljon, csökkentsd a találgatásra csábító irreleváns kontextust, vagy válts modellt. A mellétrafált válasz általában a prompt hibája, vagy álcázott retrieval-probléma, amikor a kontextus témába vág, de nem a kérdésre.

Az utolsó doboz is számít. Ha minden metrika átmegy, és a válasz mégis téves, előbb a golden címkére, a referenciaválaszra vagy magára a bíróra gyanakodj, nem a rendszerre. Ügynökös felépítéseknél, ahol a modell dönti el, mit kér le, és többször is lekérhet, ugyanez a logika érvényes lekérési lépésenként; lásd RAG 2026-ban: hibrid, ügynökös és hosszú kontextus.

LLM-bíró: kalibráld emberek ellen

A faithfulnesst, a válaszrelevanciát és a legtöbb kontextusmetrikát egy LLM pontozza. A Ragas megjegyzi, hogy az LLM-alapú metrikái egy vagy több LLM-hívást használhatnak a pontszámhoz. Ezzel a bíró a mérési összeállításod része, a műszert pedig kalibrálni kell.

A bizonyítékok biztatók, de nem feltétel nélküliek. Az MT-Bench-tanulmány szerint egy erős bíró, mint a GPT-4, több mint 80 százalékos egyezést ért el az emberi preferenciákkal, ugyanannyit, mint az emberek egymás között. Ugyanez a tanulmány megnevezi a pozíciótorzítást, a hosszúságtorzítást és az önpreferencia-torzítást, és megjegyzi a korlátozott következtetési képességet. Ezek az eredmények chatválaszok páros preferenciájáról szólnak; nem vihetők át automatikusan a te területedre, rubrikádra vagy bírómodelledre.

1. Címkézz kézzel egy mintát. Végy néhány tucat esetet, amely jó, rossz és határeset kimeneteket is felölel, és pontoztasd egy emberrel ugyanazzal a rubrikával, amelyet a bíró kap.
2. Mérj a véletlenen túli egyezést. A százalékos egyezés hízeleg, ha egy címke dominál. A Cohen-féle kappa korrigál a véletlen egyezésre (a kappa a megfigyelt és a várt egyezés különbsége osztva eggyel mínusz a várt egyezéssel), és −1 és 1 között mozog. Rá is vonatkozik egy figyelmeztetés: az érték függ az előfordulási aránytól és a torzítástól, ezért nincs univerzális küszöb. Nézd a tévesztési mátrixot, ne csak a számot.
3. Rögzítsd a bíró bemeneteit. Használj szűk rubrikát, bináris vagy kis skálájú címkéket, és az indoklást kérd a pontszám előtt. Rögzítsd a bírómodell pontos verzióját, mert egy csendes frissítés elmozdítja a trendvonalad.
4. Kezeld az ismert torzításokat. Páros összehasonlításnál randomizáld a válaszok sorrendjét, ha lehet, ne ugyanaz a modell generáljon és bíráljon, és nézd meg, korrelálnak-e a pontszámok a válasz hosszával.
5. Változáskor kalibrálj újra. Új bírómodell, új rubrika, új terület: ismételd meg az összehasonlítást. Tartsd meg a címkézett mintát állandó kalibrációs készletként.

A bírói hívások minden futásnál tokenekbe kerülnek, ezért az LLM-költségről, késleltetésről és prompt cachingről írt taktikák az eval-csomagodra is érvényesek. Kisebb bírómodell akkor és csak akkor elfogadható, ha a kalibráció ezt megengedi.

Eszközök: Ragas, DeepEval, TruLens és Phoenix

Mindezt megírhatod magad pár száz sorban, és a determinisztikus retrieval metrikáknál gyakran én is ezt teszem. Az LLM-mel pontozott metrikáknál és a nyomkövetésnél a bevett eszközök valódi időt spórolnak. Ezt mondja a saját dokumentációjuk, 2026. október 2-án ellenőrizve:

Gyakorlati tanácsom: aszerint válassz, hol éljenek az evalok. Ha tesztként akarod őket a repóban, a DeepEval vagy egy vékony Ragas-wrapper illik. Ha az éles nyomokat akarod nézni és pontszámokat csatolni hozzájuk, a TruLens vagy a Phoenix. Bármit választasz, a golden setet és a címkéket tartsd a saját repódban, egyszerű formátumban, hogy az eszközváltás egy délutánba kerüljön, ne egy negyedévbe. És ne feledd: az azonos nevű metrikákat eszközönként másképp számolhatják, ezért sosem hasonlíts össze pontszámokat eszközök között.

Evalok futtatása CI-ban

Az eval, amelyet senki sem futtat, dokumentáció. A cél az, hogy a chunkolás, az embeddingmodell, a prompt vagy a generátor módosítása ne mergelődhessen számok nélkül. Két szintet használok, mert a költségprofilok eltérőek.

• Minden pull requestnél: csak retrieval. Futtasd a recall@k, MRR és nDCG metrikát egy rögzített indexpillanatképen vagy fixture-ön. Lehetnek determinisztikusak, LLM-hívás nélkül, így gyorsak, ingyenesek és stabilak.
• Ütemezve vagy releváns változáskor: az LLM-mel pontozott csomag. Futtasd a faithfulnesst, a válaszrelevanciát és a helyességet, ha az index, a prompt, a modell vagy a bíró változik, egyébként éjszakánként. A DeepEval dokumentációja egy tesztparancsot ír le evalok CI/CD-pipeline-ban való futtatására.
• Regresszióra kapuzz, ne egy varázsszámra. Hasonlíts rétegenként az utolsó elfogadott alapvonalhoz, és bukjon a build a zajon túli visszaesésnél, amelyet a csomag többszöri futtatásával mértél.
• Fogd meg a zajt. Rögzítsd a bíró és a generátor verzióját, állítsd alacsonyra a hőmérsékletet, cache-eld a bírói hívásokat változatlan bemenetnél, és tárold minden futás pontszámait és a lekért chunkazonosítókat, hogy a hiba újrafuttatás nélkül diagnosztizálható legyen.
• Zárd be a kört. Egy hibázó éles eset ugyanabban a pull requestben lesz a golden set egy sora, amelyik kijavítja.

Hogy ez hogyan illeszkedik az LLM-funkciók tesztelésének tágabb gyakorlatába, az online monitorozással és az emberi reviewval együtt, azt lásd az LLM-es termékfunkciók evaljairól szóló írásban.

Mit tennék először

1. Naplózd minden kéréshez a query-t, a lekért chunkazonosítókat pontszámokkal és a végső választ.
2. Gyűjts 30–50 valódi kérdést a rétegeid mentén, és címkézd a releváns chunkokat és egy rövid referenciaválaszt.
3. Számold ki még ma a recall@k, MRR és nDCG értékeket. A retrievalt javítsd, mielőtt a promptot megérinted.
4. Add hozzá a faithfulnesst és a válaszrelevanciát LLM-bíróval, és kalibráld kézzel címkézett mintán kappával.
5. Az olcsó metrikákat kösd a pull requestekhez, a pontozott csomagot egy éjszakai jobhoz.
6. Add hozzá minden éles hibát a golden sethez, a döntési láncból kapott diagnózisával együtt.

Ehhez semmi sem igényel platformot. Egy címkézett készlet kell, néhány őszinte szám, és az a szokás, hogy minden rossz válasznál megkérdezed, melyik fele hibázott.

Források

1. Es et al.: RAGAS, Automated Evaluation of Retrieval Augmented Generation (arXiv 2309.15217)
2. Zheng et al.: Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (arXiv 2306.05685)
3. Ragas documentation: available metrics
4. Ragas documentation: faithfulness
5. Ragas documentation: context precision
6. Ragas documentation: context recall
7. DeepEval documentation: metrics introduction
8. TruLens
9. Arize Phoenix documentation
10. Wikipedia: Discounted cumulative gain
11. Wikipedia: Mean reciprocal rank
12. Wikipedia: Cohen's kappa