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

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 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.

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.

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 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 van.

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.

{
  "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 bejegyzésnek, és a 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)
2. Ragas docs: Testset Generation for RAG
3. Ragas docs: Testset generation concepts (query types, scenarios)
4. NVIDIA Technical Blog: Evaluating and Enhancing RAG Pipeline Performance Using Synthetic Data (Apr 7, 2025)
5. DeepEval docs: Datasets and the Synthesizer
6. Rajpurkar, Jia, Liang: Know What You Don't Know: Unanswerable Questions for SQuAD (ACL 2018)
7. Rahmani et al.: Towards Understanding Bias in Synthetic Data for Evaluation (CIKM 2025)
8. Cheng et al.: A Survey on Data Contamination for Large Language Models (2025)
9. Xu et al.: Infini-gram mini: Exact n-gram Search at the Internet Scale (EMNLP 2025)
10. Panickssery, Bowman, Feng: LLM Evaluators Recognize and Favor Their Own Generations
11. Enevoldsen et al.: MMTEB, Massive Multilingual Text Embedding Benchmark (ICLR 2025)
12. Evidently AI: How to align an LLM judge with human labels (Nov 14, 2025)