> Kérdésgenerálás blokkokból, hard negatívok, válaszolhatósági címkék, német és magyar lefedettség, kontamináció és emberi ellenőrzések.
>
> Web page: https://balazscsorba.com/hu/blog/synthetic-test-data-rag-evals · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/synthetic-test-data-rag-evals.md) · [Deutsch](https://balazscsorba.com/de/blog/synthetic-test-data-rag-evals.md)
> Author: Balázs Csorba · Published: 2026-10-17 · Keywords: synthetic test data RAG, RAG evaluation dataset, question generation from chunks, hard negatives retrieval evaluation, answerability filter, RAG test set generation, synthetic QA pairs, RAG eval data contamination, multilingual RAG evaluation German Hungarian, retrieval metrics recall ndcg, LLM judge human spot check, unanswerable questions RAG

[Blog](https://balazscsorba.com/hu/blog)/Retrieval és keresés

# Szintetikus tesztadatok generálása a RAG-értékeléshez

Kérdésgenerálás blokkokból, hard negatívok, válaszolhatósági címkék, német és magyar lefedettség, kontamináció és emberi ellenőrzések.

[Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. október 17.·10 perc olvasás

-   RAG
-   Evaluation
-   Synthetic data
-   Retrieval
-   Testing

![Hatlépcsős pipeline dokumentumblokkokból kérdéssé, kifejtett lekérdezzé, alapozott válasszal, groundedness szűrővel és arany kontextussal, elágazó hard negatívokkal.](https://balazscsorba.com/images/blog/synthetic-test-data-rag-evals/cover.webp?v=faf8a453de)

## A lényeg röviden

-   A saját blokkokból, a termelési chunkolással generálj; a kérdés, a válasz és az arany kontextus minden rekordban együtt marad.
-   A hard negatívok és a megválaszolhatatlan tételek miatt tud egyáltalán megbukni a készlet.
-   A németet és a magyart nyelvenként generáld, ne egy angol kérdéslista fordításával fedd le.
-   Védekezz a kontamináció ellen: tartsd privátnak a készletet, dokumentumokat vonj ki, ne blokkokat, és nézd a n-gram átfedést az arany blokkal.
-   Értékeld tovább a generátort: 30-50 stratifikált emberi címke, a modell vagy a prompt minden módosítása után újra.

Ezen az oldalon

1.  [Miért fogynak el a kézzel címkézett készletek](https://balazscsorba.com/#why-hand-labeled)
2.  [A generálási pipeline](https://balazscsorba.com/#generation-pipeline)
3.  [Mely kérdéstípusok érik meg a generálást](https://balazscsorba.com/#question-shapes)
4.  [Hard negatívok: tesztek, amelyek bukhatnak](https://balazscsorba.com/#hard-negatives)
5.  [Válaszolhatósági címkék](https://balazscsorba.com/#answerability-labels)
6.  [Német és magyar lefedettség](https://balazscsorba.com/#multilingual-coverage)
7.  [A készlet kontaminációmentesen tartása](https://balazscsorba.com/#contamination)
8.  [Emberi ellenőrzések, amelyek skálázhatók](https://balazscsorba.com/#human-spot-checks)
9.  [Mit kell mérniük a számoknak](https://balazscsorba.com/#metrics)
10.  [Ismételhető feladattá tétele](https://balazscsorba.com/#repeatable-job)
11.  [Források](https://balazscsorba.com/#sources)

Cikk meghallgatása

0:000:00

Minden RAG-csapat ugyanabba a falba ütközik: a kód gyorsan kikerül a termékbe, az értékelési adathalmaz nem. Kérdést, választ és arany kontextust kézzel címkézni hetekbe telik, és mire a készlet elkészült, a tudásbázis már tovább is lépett. A Red Hat 2026 februári írása a szokásos állapotot írja le: a csapatok embeddingeket, retrievert, chunkolást és promptokat hangolnak, miközben továbbra is kézi ellenőrzésekre, kis kézzel címkézett adathalmazokra vagy általános LLM-as-a-judge értékekre támaszkodnak, és a rendszer látszólag működik, amíg meg nem érkezik a valós forgalom.

A szintetikus tesztadat az, amiben az iparág megállapodott: kérdéseket, válaszokat és arany kontextusokat generálni a saját blokkokból, kiszűrni, amit a generátor elrontott, és megtartani egy kis emberi mintát, amely magát a generátort értékeli. Ez a bejegyzés végigjárja az utat: a pipeline-t, a megérő kérdéstípusokat, a hard negatívokat, a válaszolhatósági címkéket, a német és magyar lefedettséget, a kontaminációt, az ellenőrzéseket és azokat a metrikákat, amelyekből CI-gate lesz, nem pedig irányítótábla.

## Miért fogynak el a kézzel címkézett készletek

A RAG-értékelés unalomig ismert okból nehezebb, mint egy modell önmagában mért értékelése: egyszerre bukik két komponens. Arany kontextus hiányában nem lehet eldönteni, hogy a retriever hozta rosszul a dokumentumokat, vagy a generátor hallucinált helyes kontextus mellett, a hibakeresés pedig találgatássá válik. A szintetikus tripletek pontosan ezt oldják meg: mert a kérdés egy adott blokkból épült, tudjuk, melyik blokknak kell nyernie, így a lekérdezés és a generálás külön értékelhető, nem egy elmosódott összpontszámon vitatkozunk.

A Red Hat felsorolja a statikus, kézzel készült készletek további hibáit: drágák és lassan állnak elő, ritkán hordoznak arany kontextust, a dokumentumok változásával azonnal elavulnak, és a generikus kérdések épp azokat a doménspecifikus hibákat hagyják ki, amelyek számítanak. Van egy fenntartás is. Rahmani és kollégái a CIKM 2025ön mutatták meg, hogy az LLM-generált tesztgyűjteményeken számolt értékelési eredmények abszolút teljesítménynél torzítottak, míg a rendszerek relatív összehasonlítása jóval jobban áll. A szintetikus számot trendvonalaként olvasd, nem jegyként.

## A generálási pipeline

Minden komoly generátor ugyanazt a formát követi. A Red Hat nyílt forráskódú SDG Hubja hatlépcsős RAG-evaluation flow-t szállít: téma kinyerés az értékelés horgonyaként, kérdésgenerálás egy dokumentumvázlat vezérlésével, a kérdések fejlesztése valós felhasználói lekérdezésekké, szigorúan a forrásban alapozott válaszgenerálás, a gyenge párokat eltávolító groundedness szűrő, és a kontextuskinyerés, amely izolálja a válaszhoz szükséges minimális blokkot. A bemeneti szerződés szándékos: egy oszlop a dokumentumnak, amelynek a termelési chunkolási stratégiával kell egyeznie, és egy rövid, szándékszintű vázlatforma, mert a jó vázlat az, ami megakadályozza, hogy a modell sablonpótló kérdéseket írjon.

A szűrő lépés nem opcionális: a gyenge kérdés-válasz párok a metrikákba jutnak, ha itt senki nem távolítja el őket.

A Ragas ugyanezt az eredményt más irányból építi meg. A dokumentumokat knowledge graphggé alakítja egy document splitterrel, entity- és kifejezéskinyerőkkel és relationship builderekkel, majd szenáriókat választ, azaz csúcsokat, lekérdezési hosszt, stílust és személyiséget, mielőtt egy synthesizer megírná a kérdést és a referencia választ. Az alapértelmezett lekérdezés-eloszlás 0,5 single-hop specific, 0,25 multi-hop abstract és 0,25 multi-hop specific. A DeepEval Synthesizere az egyenes utat választja: goldene-eket generál dokumentumokból vagy kontextusokból, nehezebb formákra fejleszti őket, és adathalmazként menti, amelyre pytest-et futtathatunk.

```
from ragas.testset import TestsetGenerator
from ragas.testset.synthesizers import default_query_distribution

generator = TestsetGenerator(llm=generator_llm, embedding_model=generator_embeddings)
dist = default_query_distribution(generator_llm)
# [(SingleHopSpecific, 0.5), (MultiHopAbstract, 0.25), (MultiHopSpecific, 0.25)]
testset = generator.generate(testset_size=100, query_distribution=dist)

df = testset.to_pandas()
# columns you actually need downstream: query, reference_contexts, reference
df.to_json("evals/rag-set-v1.jsonl", orient="records", lines=True)
```

## Mely kérdéstípusok érik meg a generálást

Ne csak egyfajta kérdést generálj. Egy kizárólag mi-ez típusú tételekből álló készlet gond nélkül átmegy, miközben soha nem jelennek meg azok a hibák, amelyek a termékben csapódnak le: a két dokumentumon átívelő összehasonlítás, a kulcsszót nem megosztó parafrázis és az a kérdés, amelyet a korpusz egyszerűen nem tud megválaszolni. A Ragas két tengelyen oszt, single-hop az egyik, multi-hop a másik oldalon, specific és abstract mentén, a szenáriói pedig lekérdezési hosszt, stílust és személyiséget adnak hozzá, hogy a megfogalmazások ne egyetlen hangnemben érkezzenek.

Típus

Elvárás a lekérdezéssel szemben

Referenciacímke

Single-hop, specific

Egy blokk tartalmazza a választ

arany kontextus + válasz

Single-hop, abstract

Egy blokk, átfogalmazott érveléssel

arany kontextus + rubrika

Multi-hop

Két vagy több blokk, entitással összekötve

rendezett arany kontextusok

Megválaszolhatatlan

A korpusz egyik része sem fedi le

válaszolhatóság nem, elvárt elzárkózás

Hard negatív próba

Az arany blokk hasonmások között van

arany kontextus + decoy azonosítók

A nehézség a második tengely, és mérhető. Az NVIDIA szintetikus adatokra épülő pipeline-ja embedding modellt használ judge-ként a kérdések nehézségére: a generált kérdéseket a kontextusdokumentumokhoz való koszinusz hasonlóság szerint szűri, az alacsonyabb küszöb pedig nehezebb készletet ad. Az FiQA benchmarken az NVIDIA csapata a kézzel címkézett lekérdezésekhez kalibrálta ezt a szűrőt, és 4,57 százalékos átlagos eltérést mért a Recall@5-nél a 70. percentilis küszöbön, 5,65 százalékost a 75. percentilisen, 0,91-es korrelációval az összehasonlított embedding modellek között. Ez a mércé: a szintetikus készleted ugyanabba a sorba rendezze két retrievert, mint egy kézzel címkézett.

## Hard negatívok: tesztek, amelyek bukhatnak

Egy kérdés plusz arany blokk csak azt bizonyítja, hogy a jó blokk megtalálható. A hard negatívok azt bizonyítják, hogy a rossz blokkot elutasítják, és ez az oka annak, hogy egy szintetikus készlet egyáltalán bukhat. Az NVIDIA definíciója szerint a hard negatívok olyan dokumentumok, amelyek embeddingje közel van a kérdéshez, de a szövegük nem tartalmazza a választ: a szomszédos árlista, a szabályzat előző verziója, ugyanaz a cikk a másik nyelven. A véletlenszerű negatívok erre használhatatlanok, mert egy modern embedding térben a kérdés és a relevánsatlan dokumentum távolsága már amúgy is nagy.

Képzési párokhoz az NVIDIA három kiválasztási stratégiát dokumentál, és mindhárom érvényes az eval adatokra is: top-K kiválasztás a kérdéshez való koszinusz hasonlóság szerint, küszöb-alapú kiválasztás, amely csak minimum és maximum hasonlósági sávba eső negatívokat fogad el, és pozitív-tudatos bányászat, amely a negatív hasonlóságot a pozitív hasonlóság százalékában korlátozza. A NV-Retriever cikkben végzett ablatáció ezt a korlátot a pozitív érték 95 százalékában állítja be a hamis negatívok kiszűrésére. Evalnél ugyanez azt jelenti: válaszd ki azokat a decoyokat, amelyeket a retriever a legnagyobb valószínűséggel téveszt az arany blokkal össze, és tárold az azonosítóikat a címke mellett, hogy egy hiba konkrét tévesztésre mutasson, nem egy homályos értékcsökkenésre.

```
import numpy as np

def hard_negatives(question, chunks, gold_idx, k=4, cap=0.95):
    """Decoys the retriever ranks near the gold chunk, capped below the gold score."""
    q = embed(question)
    sims = np.array([cosine(q, c.embedding) for c in chunks])
    gold = sims[gold_idx]
    order = np.argsort(-sims)
    picked = [i for i in order if i != gold_idx and sims[i] <= cap * gold]
    return picked[:k]  # store chunk ids as hard_negatives on the record
```

## Válaszolhatósági címkék

A megválaszolhatatlan tételek választják el a keresési tesztet az elzárkózási teszttől. A SQuAD 2.0 szabvánnyá tette a mintát azzal, hogy több mint 50 000, crowdworkerek által szándékosan úgy megírt kérdést adott hozzá, amely hasonlított a megválaszolhatókra: egy erős neurális rendszer, amely a SQuAD 1.1-en 86 százalék F1-et ért el, a SQuAD 2.0-n 66 százalékra esett, mert el kellett döntenie azt is, mikor nem támasztja alá a bekezdés a választ. Egy RAG-eval készletnek ugyanez a keverék kell, a kérdések dokumentált arányával, ahol a helyes viselkedés az, hogy közöljük: a korpusz nem fedi le a témát.

Az NVIDIA válaszolhatósági szűrője jó sablon magához a címkéhez. Az emberi annotátorok A-t adtak egy generált lekérdezésre, ha a blokk teljesen megválaszolta, B-t, ha kulcsinformáció hiányzott, C-t, ha a lekérdezés releváns volt, de a kontextus nem válaszolta meg, és D-t, ha a lekérdezés nem volt releváns a kontextushoz; a nem önálló lekérdezéseket egyáltalán nem értékelték. Ezzel a rubrikával egy Llama-3.1-70b-Instruct judge 94 százalékos precisiont és 90 százalékos recallt ért el. Négy fokozat itt jobb, mint egy booleai, mert a részben megválaszolható valós termelési eset, és éppen az, amely magabiztos, félig helyes válaszokat ad.

**A blokkból megválaszolható, nem a modell emlékezetéből**

A modell, amelytől egy blokkhoz kérdést kérnek, örömmel ír olyat, amelyet a pretrainingből meg tud válaszolni, a blokk csak díszítésként. Ezért a groundedness szűrő külön pipeline-lépés: a választ csak az arany kontextus támaszthatja alá, és a válaszolhatósági címkét a blokkot a judge elé téve kell eldönteni, nem a modell saját tudásával szemben. Tartsd expliciten a megválaszolhatatlanok arányát a konfigurációban, és a negatívok és elzárkózások nélküli készletet hibásnak tekintd: ami nem tud megbukni, az nem mér semmit.

## Német és magyar lefedettség

Ha a termék németül és magyarul válaszol, németül és magyarul generálj. Egy angol kérdéskészlet lefordítása angol szószerkezetet ad német szavakkal, és az nem az, amit az emberek gépelnek; ráadásul elrejti azokat a keresési problémákat, amelyek nyelvenként jellemzők: a német összetett szavakat, amelyek máshogy válnak el, mint a lekérdezés, a magyar agglutinációt, amely több ragozást fűz egy tőhöz, és azt az esetet, amikor egy magyar kérdésnek egy német dokumentumot kell eltalálnia. Minden tételt jelölj a lekérdezés és a dokumentum nyelvével, és a cross-lingual szeletet külön értékeld.

A nyilvános többnyelvű benchmarkok ellenőrzésre valók, nem helyettesítésre. Az MMTEB, az MTEB ICLR 2025-ön elfogadott közösségi bővítése több mint 500 minőségellenőrzött feladatot fed le több mint 250 nyelven, és azt is megmutatja, mennyit számít a feladatválasztás: a retrieval feladatokat hard negatívok mintavételezésével optimalizálják, kisebb split-eket építve, amelyek megőrzik a modell rangsorát. A MTEB nemzeti bővítései németül és több más nyelven is léteznek, és segítenek az embedding modell választásakor; magyarul főként a saját generált készletedre támaszkodsz, ezért is érdemes azt becsületesen tartani. A lekérdezési oldala ennek a [német és magyar többnyelvű RAG](https://balazscsorba.com/hu/blog/multilingual-rag-german-hungarian) bejegyzésben van.

## A készlet kontaminációmentesen tartása

A kontamináció kétszer harap. Az első harapás a nyilvános benchmarkoké: ha az eval tételei egy modell tanítási adataiban szerepelnek, a szám kitalált. A klasszikus detektor az n-gram átfedés, a módszer, amellyel a GPT-3 cikk megjelölte azokat az értékelési készletekben, ahol több mint 13 token egyezik a tanítóadatokkal, és az EMNLP 2025-ös Infini-gram mini tanulmány 83 terabájnyi internetes szövegen végzett pontos n-gram keresést, és súlyosan kontaminált alapbenchmarkokat talált, akár 74,2 százalékot GSM8K-nál. Egy 2025-ös áttekintés a védelmet adatfrissítésbe, adatátírásba és megelőzésbe rendezi, a detektálási módszereket pedig white-box, gray-box és black-box kategóriákba.

A második harapás privát: a saját generált készleted szivárog abba a rendszerbe, amelyet mérsz. Három szabály lefedi. Ne hangolj promptot vagy chunkolási szabályt az eval készleten, és utána ne arról a készletről számolj be számot, vagyis a hangoláshoz egész dokumentumokat vonj ki, nem blokkokat, és az eval tételeket tartsd távol attól a indexétől, amely a promptkísérleteket szolgálja. Nézd meg az átfedést az egyes generált kérdések és azok arany blokkja között, mert a blokk szövegéről átmásolt kérdés jobbá teszi a keresőt a valósnál. És generálj újra, amikor a korpusz lényegesen megváltozik, corpus hash-et tárolva minden tételen, hogy a régi szám visszakövethető maradjon.

## Emberi ellenőrzések, amelyek skálázhatók

Az ellenőrzésekkel értékeled a generátort, és a olcsó változat működik. Az emberi címkékhez igazított judge gyakorlati útmutatója azt javasolja, 30-50 címkézett példával kezdj, a címkéket tartsd binárisan vagy kevés osztályban egy 1-től 10-ig tartó skála helyett, és a judge-t accuracy-vel, precisionnel, recall-lal és Cohen Kappa értékkel mérd. A saját kipróbált példájukban az első judge prompt csak a címkék 67 százalékában értett egyet a szakértőkkel, és prompt- és modelliteráció kellett, amíg a judge használható lett. Tervezd bele ezt az iterációt, ne tekintsd véglegesnek az első judge promptot.

Stratifikáltan mintázz, ne véletlenszerűen: fedd le minden nyelvet, minden címkeformát és a megválaszolhatatlan szeletet, és minden generátormodelld vagy promptja módosítása után ellenőrizd újra. Van egy konkrét torzítás is, amire vigyázni kell. Panickssery, Bowman és Feng megmutatta, hogy az LLM-értékelők felismerik és preferálják a saját generációikat, és a finomhangolási kísérletek lineáris korrelációt adnak az önfelismerési képesség és a self-preference bias erőssége között. Gyakorlatilag: soha ne értékeld a kérdéseket és válaszokat azzal a modellcsaláddal, amely megírta őket, és a judge egyezését mért számként frissítsd, nem feltételezett tulajdonságként.

## Mit kell mérniük a számoknak

Arany kontextusok birtokában a metrika lista rövid, és minden tétel megnevez egy réteget, ez a készlet építésének lényege. A lekérdezés a Recall@k-t, az MRR-t és az nDCG-t kapja, plusz a context precisiont és recallt, ha a válaszszakaszokat is ismerjük, nem csak a blokkazonosítókat. A generálás a faithfulnesst, azaz hogy a választ alátámasztja-e a lekérdezett kontextus, az answer relevancet és a megválaszolhatatlan tételek felett számolt abstention accuracyt kapja. Egy olyan számot, amelyet nem lehet a két réteg egyikéhez sem rendelni, irányítótáblának hívunk, nem diagnózisnak; a szélesebb taxonómia a [RAG értékeléséről szóló bejegyzésben](https://balazscsorba.com/hu/blog/rag-evaluation-metrics) van.

Metrika

Réteg

Amit a szintetikus készlettől igényel

Recall@k, MRR, nDCG@10

Lekérdezés

arany kontextus-azonosító kérdésenként

Context precision és recall

Lekérdezés

arany szakaszok, nem csak azonosítók

Faithfulness

Generálás

válasz plusz lekérdezett kontextus

Answer relevance

Generálás

kérdés plusz referencia válasz

Abstention accuracy

Generálás

megválaszolhatatlan tételek címkéi

Két szokás tartja becsületesen a számokat. A relatív összehasonlítást, a konfiguráció A és B ugyanazon a készleten, jelentsd elsődleges eredményként, mert a CIKM 2025-ös elemzés azt találta, hogy a szintetikus gyűjtemények abszolút teljesítménye a törékeny szám. És tartsd meg tartósan egy kis emberi címkézett szeletet: ez az a kalibrációs súly, amely megmutatja, hogy a szintetikus készlet eltávolodott-e attól, amit a felhasználók valóban kérdeznek, és egyben a judge regressziós készlete is.

## Ismételhető feladattá tétele

A szintetikus adat csak akkor térül meg, ha unalmas: ugyanaz a pipeline, ugyanazok a promptok és ugyanazok a szűrők, amelyek akkor futnak, amikor a korpusz elég nagyot változott. Minden tétel kapjon corpus hash-t, generátor-modell-azonosítót és prompt-verziót, így egy nem reprodukálható szám visszavezethető a változásra, amely okozta. Az alábbi hurk a teljes gyakorlat: generálás, szűrés, stratifikált minta kézi ellenőrzése, az értékelés lefuttatása, összehasonlítás a korábbi alapvonallal, és csak akkor újragenerálás, amikor az adatok elmozdultak.

A visszanyíl az, amit a csapatok kihagynak, és éppen ez tartja érvényesnek az alapvonalat, miután a tudásbázis megváltozott.

```
{
  "id": "hu-0042",
  "corpus_hash": "8f3c1a9",
  "generator": "<model id>",
  "prompt_version": "qgen-v4",
  "query_lang": "hu",
  "doc_lang": "de",
  "question": "<generated question>",
  "answer": "<answer grounded in the gold context>",
  "gold_context": "chunk-118",
  "hard_negatives": ["chunk-117", "chunk-203"],
  "answerability": "answerable",
  "checked_by": "human"
}
```

Ez az utolsó nyíl az, amit a csapatok kihagynak. Egy szintetikus készletnek lejárati dátuma van, amely a tudásbázishoz kötődik, és az a drift-érv, amely a termelési dokumentumokra igaz, a tesztadatokra ugyanúgy igaz: a statikus készletek szinte azonnal elavulnak. A CI-ben a relatív számokra építs kaput, egy Recall@5- vagy faithfulness-csökkenésre az előző futáshoz képest, és csak akkor buktasd a buildet, ha az emberi minta megerősíti, hogy ténylegesen változott valami. A körülöttük lévő összekötés, küszöbök és CI-huzalozás a témája a [termékfunkciókhoz készített LLM-evalök](https://balazscsorba.com/hu/blog/llm-evals-for-product-features) bejegyzésnek, és a [Ragas](https://balazscsorba.com/hu/tools/ragas), a DeepEval és a Red Hat SDG Hub-ja a három generátor, amelyhez először nyúlok.

## Források

1.  [Red Hat Developers: Synthetic data for RAG evaluation (Feb 23, 2026)](https://developers.redhat.com/articles/2026/02/23/synthetic-data-rag-evaluation-why-your-rag-system-needs-better-testing)
2.  [Ragas docs: Testset Generation for RAG](https://docs.ragas.io/en/stable/getstarted/rag_testset_generation/)
3.  [Ragas docs: Testset generation concepts (query types, scenarios)](https://docs.ragas.io/en/stable/concepts/test_data_generation/rag/)
4.  [NVIDIA Technical Blog: Evaluating and Enhancing RAG Pipeline Performance Using Synthetic Data (Apr 7, 2025)](https://developer.nvidia.com/blog/evaluating-and-enhancing-rag-pipeline-performance-using-synthetic-data/)
5.  [DeepEval docs: Datasets and the Synthesizer](https://deepeval.com/docs/evaluation-datasets)
6.  [Rajpurkar, Jia, Liang: Know What You Don't Know: Unanswerable Questions for SQuAD (ACL 2018)](https://arxiv.org/abs/1806.03822)
7.  [Rahmani et al.: Towards Understanding Bias in Synthetic Data for Evaluation (CIKM 2025)](https://arxiv.org/abs/2506.10301)
8.  [Cheng et al.: A Survey on Data Contamination for Large Language Models (2025)](https://arxiv.org/abs/2502.14425)
9.  [Xu et al.: Infini-gram mini: Exact n-gram Search at the Internet Scale (EMNLP 2025)](https://aclanthology.org/2025.emnlp-main.1268/)
10.  [Panickssery, Bowman, Feng: LLM Evaluators Recognize and Favor Their Own Generations](https://arxiv.org/abs/2404.13076)
11.  [Enevoldsen et al.: MMTEB, Massive Multilingual Text Embedding Benchmark (ICLR 2025)](https://arxiv.org/abs/2502.13595)
12.  [Evidently AI: How to align an LLM judge with human labels (Nov 14, 2025)](https://www.evidentlyai.com/blog/how-to-align-llm-judge-with-human-labels)

## Gyakori kérdések

Milyen nagynak kell lennie egy szintetikus RAG-eval készletnek?

Kicsiben kezdj, és addig növelsd, amíg a mért szám nem ugrál többé. A Ragas quickstart 10 tételt generál, hogy bebizonyítsa a pipeline működik; a használható készlet nagyobb, de a jó méret az, amelynél az új kérdések már nem változtatják meg két retriever összehasonlítását. A lefedettség a nyelvek, kérdéstípusok és címkeformák mentén fontosabb, mint a darabszám.

A szintetikus adat teljesen helyettesítheti a kézi címkézést?

Nem. A szintetikus tesztgyűjteményekről szóló kutatás azt mutatja, hogy az LLM-generált adatokon mért abszolút teljesítmény torzított, míg a rendszerek relatív összehasonlítása jóval stabilabb. A szintetikus készlettel konfigurációkat hasonlíts össze, és tarts meg egy kis emberi címkézett szeletet kalibrációként, ezen méred a generátor judge-ját is.

Ugyanaz a modell generálja és értékelje az adatot?

Inkább ne. Az LLM-értékelők felismerik és preferálják a saját generációikat, a kísérletek pedig lineáris korrelációt mutatnak az önfelismerés és a self-preference bias erőssége között. Generálj egy modellcsaláddal, értékelj egy másikkal, és a judge egyezését mérd emberi címkékhez, ne feltételezd.

Elég egy angol tesztkészletet németre és magyarra fordítani?

Az jó kiindulópont, de fordított szöveget tesztel, nem azt, amit a felhasználók gépelnek. Generáld a kérdéseket nyelvenként ugyanazokból a blokkokból, jelöld meg a lekérdezés és a dokumentum nyelvét, és a cross-lingual szeletet külön értékeld, mert ott a szóösszetételek és a ragok megváltoztatják a keresés viselkedését.

Mikor kell újragenerálni az eval készletet?

Amikor az tudásbázis lényegesen megváltozott, amikor a prompt vagy a generátor modell módosult, vagy amikor a tételekhez tárolt corpus hash már nem egyezik. A statikus tesztkészletek gyorsan elavulnak: versionáld a készletet a corpus mellett, és az újragenerálást új alapvonalnak kezeld, amit összehasonlítás előtt mintavétellel ellenőrizni kell.

Í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

-   [Embedding-modell választása 2026-ban: ranglisták, költségek és összehasonlító teszt a saját adatokon](https://balazscsorba.com/hu/blog/embedding-model-selection-2026)
-   [Kontextuális visszakeresés és késleltetett chunkolás: a RAG-chunkok visszakapják a kontextusukat](https://balazscsorba.com/hu/blog/contextual-retrieval-late-chunking)
-   [Hozzáférés-kezelés RAG-hoz: jogosultságtudatos visszakeresés dokumentumszivárgás nélkül](https://balazscsorba.com/hu/blog/rag-access-control-permissions)
-   [RAG termékkatalógusra: PIM-adatokból megbízható válaszok](https://balazscsorba.com/hu/blog/rag-product-catalog-pim-data)

## Pont erre van szükséged?

Írj a projektedről vagy a pozícióról – szívesen hallok felőled.

[Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)