> Hogyan értékeld ki a RAG-rendszered: recall at k, MRR, nDCG vs. faithfulness és válaszrelevancia, golden set valódi kérdésekből, kalibrált LLM-bíró, evalok a CI-ban. > > Web page: https://balazscsorba.com/hu/blog/rag-evaluation-metrics · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/rag-evaluation-metrics.md) · [Deutsch](https://balazscsorba.com/de/blog/rag-evaluation-metrics.md) > Author: Balázs Csorba · Published: 2026-10-02 · Keywords: RAG evaluation, how to evaluate RAG, RAG evaluation metrics, recall@k MRR nDCG, faithfulness vs answer relevance, golden dataset for RAG, LLM as a judge calibration, Ragas vs DeepEval vs TruLens, RAG evals in CI, retrieval vs generation failure [Blog](https://balazscsorba.com/hu/blog)/RAG és keresés # RAG kiértékelése: retrieval metrikák, faithfulness, és hogyan derül ki, melyik fele hibázott Hogyan értékeld ki a RAG-rendszered: recall at k, MRR, nDCG vs. faithfulness és válaszrelevancia, golden set valódi kérdésekből, kalibrált LLM-bíró, evalok a CI-ban. [Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. október 2.·12 perc olvasás - RAG evaluation - Retrieval metrics - LLM-as-judge - Golden set - Ragas ![Ábra: egy RAG-választ két oldalon pontoznak, retrieval metrikákkal, mint a recall at k, az MRR és az nDCG, valamint generálási metrikákkal, mint a faithfulness és a válaszrelevancia, amelyek egy diagnózisba futnak.](https://balazscsorba.com/images/blog/rag-evaluation-metrics/cover.webp?v=5cf36c4462) ## A lényeg röviden - A RAG-rendszernek két fele van, és másképp hibáznak, ezért külön pontozd őket: a retrievalt recall@k, MRR és nDCG metrikával, a generálást faithfulness és válaszrelevancia metrikával. - A recall@k a plafon. Ha a szükséges chunk nincs a top k-ban, semmilyen prompt vagy modell nem tud megalapozott választ adni, ezért rossz válasznál először a retrievalt nézd meg. - A valódi felhasználói kérdésekből épített golden set jobb a szintetikus kérdéseknél. Kezdd kicsiben, rögzítsd, mit igényel a helyes válasz, és minden éles hibával bővítsd. - Az LLM-bíró mérőeszköz, nem alapigazság. Kalibráld mintán emberi címkék ellen, jelents véletlenre korrigált egyezést, és ellenőrizd újra, ha a bírómodell megváltozik. - Az olcsó retrieval-ellenőrzéseket minden pull requestnél futtasd, az LLM-mel pontozott csomagot ütemezve vagy az index, a prompt vagy a modell változásakor, és az alapvonalhoz képesti visszaesésre kapuzz. Ezen az oldalon 1. [Két fél, hét szám](https://balazscsorba.com/#two-halves) 2. [Retrieval metrikák: recall@k, MRR és nDCG](https://balazscsorba.com/#retrieval-metrics) 3. [Generálási metrikák: faithfulness és válaszrelevancia](https://balazscsorba.com/#generation-metrics) 4. [A golden set felépítése valódi kérdésekből](https://balazscsorba.com/#golden-set) 5. [Diagnózis: a retrieval vagy a generálás hibázott?](https://balazscsorba.com/#diagnosis) 6. [LLM-bíró: kalibráld emberek ellen](https://balazscsorba.com/#llm-judge) 7. [Eszközök: Ragas, DeepEval, TruLens és Phoenix](https://balazscsorba.com/#tools) 8. [Evalok futtatása CI-ban](https://balazscsorba.com/#ci) 9. [Mit tennék először](https://balazscsorba.com/#first-steps) 10. [Források](https://balazscsorba.com/#sources) 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](https://balazscsorba.com/hu/blog/llm-evals-for-product-features) és magáról a [RAG-pipeline-ról](https://balazscsorba.com/hu/blog/rag-pipeline-chunking-hybrid-search-reranking) szóló írásaimra épül. ## Két fél, hét szám A [RAGAS-tanulmány](https://arxiv.org/abs/2309.15217) 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. Metrika Réteg A kérdés, amelyre felel Kell címke? recall@k Retrieval Ott van-e a releváns anyag valahol a top k-ban? Releváns chunkok kérdésenként MRR Retrieval Milyen előkelő az első releváns találat? A rangja reciprokának átlaga. Releváns chunkok kérdésenként nDCG Retrieval Jó sorrendben van-e az egész rangsor, fokozatos relevanciával és a lejjebb lévők leértékelésével? Fokozatos relevancia Context precision Retrieval (rangsor) A modellnek adott kontextusban a releváns chunkok a nem relevánsak előtt állnak-e? A Ragasban opcionális referenciaválasz Context recall Retrieval A referenciaválasz minden állítását alátámasztja-e a lekért kontextus? Referenciaválasz Faithfulness Generálás A válasz minden állítását alátámasztja-e a lekért kontextus? Nem Válaszrelevancia Generálás Megválaszolja-e a válasz a feltett kérdést? Nem 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](https://balazscsorba.com/hu/blog/rag-pipeline-chunking-hybrid-search-reranking)). 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 faithful nem azonos a helyessel** A faithfulness csak azt mondja meg, hogy a válasz egyezik a chunkokkal. Hogy a chunkok a megfelelők voltak-e, az retrieval-kérdés, és hogy a végső válasz egyezik-e a golden válasszal, az különálló helyességi pontszám. Mind a hármat követem, mert a kombinációk mutatnak az okra. ## 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](https://balazscsorba.com/hu/blog/gdpr-llm-api-eu-data-residency) í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. A sorrend számít: minden kérdés feltételezi, hogy a fölötte lévők átmentek. A meglepetések többsége az első kettőnél van. 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](https://balazscsorba.com/hu/blog/rag-2026-hybrid-agentic-long-context). ## 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](https://arxiv.org/abs/2306.05685) 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](https://balazscsorba.com/hu/blog/llm-cost-latency-prompt-caching-routing) í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: Eszköz Mi ez RAG-metrikák és munkafolyamat Ragas A RAGAS-tanulmányból származó metrikakeretrendszer Context precision, context recall, noise sensitivity, response relevancy, faithfulness; LLM-alapú és nem LLM-es változatok; egyéni metrikák támogatottak DeepEval Tesztszerű kiértékelő keretrendszer Contextual relevancy, precision és recall a retrievernek; answer relevancy és faithfulness a generátornak; natív pytest-integráció a deepeval test run paranccsal CI/CD-hez TruLens Nyílt forrású kiértékelés és nyomkövetés, OpenTelemetry-natív, a Snowflake gondozza A context relevance, groundedness és answer relevance RAG-triád; működik a LangChainnel, a LlamaIndexszel és a LangGraphfal Arize Phoenix Nyílt forrású AI-megfigyelhetőség és -kiértékelés OpenTelemetry és OpenInference alapon Nyomkövetés, kiértékelések LLM-es, kódos vagy emberi címkékkel, datasetek és kísérletek a változások azonos bemeneteken való összehasonlításához; az Arize AX a menedzselt opció 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](https://balazscsorba.com/hu/blog/llm-evals-for-product-features) 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)](https://arxiv.org/abs/2309.15217) 2. [Zheng et al.: Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (arXiv 2306.05685)](https://arxiv.org/abs/2306.05685) 3. [Ragas documentation: available metrics](https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/) 4. [Ragas documentation: faithfulness](https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/faithfulness/) 5. [Ragas documentation: context precision](https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/context_precision/) 6. [Ragas documentation: context recall](https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/context_recall/) 7. [DeepEval documentation: metrics introduction](https://deepeval.com/docs/metrics-introduction) 8. [TruLens](https://www.trulens.org/) 9. [Arize Phoenix documentation](https://arize.com/docs/phoenix) 10. [Wikipedia: Discounted cumulative gain](https://en.wikipedia.org/wiki/Discounted_cumulative_gain) 11. [Wikipedia: Mean reciprocal rank](https://en.wikipedia.org/wiki/Mean_reciprocal_rank) 12. [Wikipedia: Cohen's kappa](https://en.wikipedia.org/wiki/Cohen%27s_kappa) ## Gyakori kérdések Hogyan értékeljek ki egy RAG-rendszert? Értékeld ki külön a retrievalt és a generálást ugyanazon a valódi kérdésekből álló golden seten. A retrievalnél azt mérd, hogy a megfelelő chunkok megtalálhatók voltak-e és milyen előkelő helyen (recall@k, MRR, nDCG). A generálásnál azt, hogy a választ alátámasztja-e a lekért kontextus (faithfulness), és hogy megválaszolja-e a kérdést (válaszrelevancia). A két pontszámcsoportból kiderül, melyik fele hibázott. Mi a különbség a recall@k, az MRR és az nDCG között? A recall@k azt kérdezi, hogy a releváns anyag megjelenik-e valahol a top k találatban. Az MRR az első releváns találat rangjának reciprokából vett átlag, ezért csak az első találat számít. Az nDCG a teljes rangsort pontozza fokozatos relevanciával, a lejjebb lévő találatokat leértékeli, és 0 és 1 közé normalizált. Mi a faithfulness a RAG-kiértékelésben? A faithfulness azt méri, hogy a generált válasz állításait alátámasztja-e a lekért kontextus. A Ragasban ez az alátámasztott állítások száma osztva a válasz összes állításának számával, 0 és 1 közötti érték. Egy faithful válasz is lehet téves, ha a retrieval rossz kontextust hozott vissza. Megbízhatok egy LLM-ben bíróként? Részben. 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, de dokumentálta a pozíció-, a hosszúság- és az önpreferencia-torzítást is. Kezeld a bírót műszerként: címkézz kézzel egy mintát, mérd az egyezést, és kalibrálj újra, ha a bírómodell vagy a rubrika változik. Melyik RAG-kiértékelő eszközt használjam: Ragas, DeepEval, TruLens vagy Phoenix? A metrikáknál átfedik egymást, a munkafolyamatban különböznek. A Ragas metrikakeretrendszer, a DeepEval pytest-szerű tesztekre és egy CI-parancsra épül, a TruLens a RAG-triád köré szerveződik nyomkövetéssel, az Arize Phoenix pedig az OpenTelemetry-alapú nyomkövetést kiértékelésekkel, datasetekkel és kísérletekkel kapcsolja össze. Én aszerint választanék, hol szeretném, hogy az evalok éljenek, nem a metrikanevek alapján. Honnan tudom, hogy a retrieval vagy a generálás okozott egy rossz választ? Nézd meg az adott kérdéshez lekért chunkokat. Ha a szükséges tény sosem volt a korpuszban, tartalmi hiányról van szó. Ha a korpuszban volt, de nem a top k-ban, a retrieval hibázott. Ha a kontextusban volt, de a válasz figyelmen kívül hagyja vagy ellentmond neki, a generálás hibázott, ami alacsony faithfulnessként vagy alacsony válaszrelevanciaként jelenik meg. Írta: Csorba Balázs Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket. [AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about) ## További cikkek - [LLM-hallucinációk csökkentése éles rendszerben: grounding, hivatkozások és a nemet mondás tudománya](https://balazscsorba.com/hu/blog/llm-hallucination-grounding-citations) - [pgvector vagy vektoradatbázis? Így válassz vektortárolót 2026-ban](https://balazscsorba.com/hu/blog/pgvector-vs-vector-databases) - [GraphRAG és knowledge-graph RAG: mikor veri a gráf a vektoros keresést](https://balazscsorba.com/hu/blog/graphrag-knowledge-graph-rag) - [Szemantikus termékkeresés B2B webshopokban: cikkszámok, hibrid keresés és amit mérned kell](https://balazscsorba.com/hu/blog/semantic-product-search-b2b) ## Pont erre van szükséged? Írj a projektedről vagy a pozícióról – szívesen hallok felőled. [Beszélgetés kérése](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)