A hallucinációs arány kevés: így mérd külön a RAG hibáit

A RAG-rendszer hibáját külön mérőszámokkal tudod megtalálni: vizsgáld meg, hogy a keresés előhozta-e a szükséges információt, a válasz állításai következnek-e az átadott kontextusból, a kérdésre felelnek-e, és lefedik-e az elvárt tartalmat. Egyetlen hallucinációs arányból nem derül ki, hogy a forrás hiányzott, a kereső hagyta ki, vagy a generáló modell használta rosszul.

A Microsoft Foundry RAG-értékelési dokumentációja külön választja a visszakeresés, a forráshűség, a válasz relevanciája és az elvárt válaszhoz mért teljesség értékelését. A hibakeresést ezért a forrásállománynál és a keresési eredménynél kezdd, majd az átadott kontextus alapján vizsgáld a kész választ.

Milyen adatokat ments el egy tesztesethez?

A minimális teszteset a felhasználói kérdést, a modellnek ténylegesen átadott kontextust, a változatlanul rögzített választ és az ellenőrzött elvárt választ köti ugyanahhoz a futáshoz. Ha egy későbbi értékelésben már egy másik keresés kontextusa szerepel, a forráshűségi eredmény nem mond semmit az eredeti válaszról.

• query: a felhasználó pontos kérdése, a feltételekkel és megszorításokkal együtt.
• context: azok a dokumentumrészletek, amelyeket a generáló modell valóban megkapott; őrizd meg a sorrendjüket és a dokumentumazonosítóikat.
• response: a rendszer teljes válasza, a hivatkozásokkal és az esetleges válaszmegtagadással együtt.
• ground truth: a függetlenül ellenőrzött elvárt válasz, külön jelölve a nélkülözhetetlen állításokat és az alapjául szolgáló dokumentumokat.

A kereső nyers találatait külön is érdemes tárolni. Így látszik, hogy a szükséges részletet a kereső sem találta meg, vagy megtalálta, de a rangsorolás, a szűrés vagy a kontextus összeállítása közben kiesett. A relevánsnak jelölt dokumentumazonosítók a keresési méréshez kellenek; a tudásbázis és a modell verziója pedig segít azonosítani, melyik változás érintette a tesztesetet.

Az elvárt válasz ne a vizsgált rendszer egy korábbi kimenetének másolata legyen. Ha a ground truth eleve kihagy egy fontos feltételt, a teljességi mérés sem fogja észrevenni annak hiányát. Több elfogadható megfogalmazás esetén a nélkülözhetetlen tényeket és feltételeket rögzítsd, ne egyetlen mondat pontos szavait követeld meg.

A keresésnél a lefedettséget és a bejutást válaszd szét

Először azt mérd, hogy az elvárt válaszhoz szükséges információ szerepel-e a visszakeresett részletek között. A Ragas Context Recall mutatója az elvárt válasz állításait veti össze a visszakeresett kontextussal; dokumentumazonosítók alapján is számolható lefedettség, ha előre megjelölted a releváns részleteket. A gyenge lefedettség azt jelzi, hogy a válaszhoz szükséges bizonyíték nem állt rendelkezésre a keresés eredményében.

A nyers találati lista és a végül átadott context mező külön ellenőrzést igényel. A megfelelő bekezdés lehet a találatok között, mégis kieshet, ha csak az előrébb rangsorolt részletek jutnak be a modell bemenetébe. Ilyenkor a rangsorolás, a részletek mérete, a szűrők vagy a kontextus összeállítása a vizsgálat tárgya. Ha a szükséges állítás a tudásbázisban sincs jelen, a forrásállományt kell javítani; a kereső nem tud előhozni egy hiányzó dokumentumot.

A találatok hasznosságát is nézd meg a lefedettség mellett. Sok, a kérdéshez lazán kapcsolódó részlet mellett a lényeges szakasz hátrébb szorulhat. A puszta találatszám ezért nem helyettesíti annak ellenőrzését, hogy a megfelelő információ végül bekerült-e a modellnek átadott kontextusba.

A kész válasz három eltérő kérdésre kapjon pontot

Forráshűség: a response minden ellenőrizhető állítása alátámasztható-e a ténylegesen átadott context mezővel? A Google Cloud Vertex AI groundedness-kódmintája külön kontextust és modellválaszt ad az értékelőnek, amely pontszámot, bizonyosságot és magyarázatot ad vissza. Az indoklást az egyedi teszteset mellett őrizd meg, mert az átlagpontszám önmagában nem mutatja meg az alá nem támasztott állítást.

Relevancia: a válasz a query által feltett kérdéssel foglalkozik-e? Egy állítás pontosan következhet a forrásból, mégis mellékszálra terelheti a választ. Több feltételt tartalmazó kérdésnél külön jelöld, melyik feltételre reagált a rendszer. Ehhez a kérdést és a választ kell összevetni; a jó forráshűség önmagában nem jelent jó relevanciát.

Teljesség: a válasz tartalmazza-e a ground truth nélkülözhetetlen elemeit? Egy rövid válasz lehet forráshű, miközben kihagyja a döntést meghatározó kivételt vagy feltételt. A hiányt az elvárt állításokhoz mérd, ne a szöveg hosszához. Ha a kihagyott információ szerepelt az átadott kontextusban, a hiba a válasz előállításánál jelentkezett.

A forráshűség a rendelkezésre bocsátott kontextushoz viszonyít. Téves vagy elavult dokumentum alapján a válasz lehet forráshű, miközben eltér az ellenőrzött elvárt választól. Az ilyen eltérésnél a dokumentum állapotát is vizsgáld meg, mielőtt a generáló modellt módosítod.

A hibafa megmutatja a javítandó lépést

Gyenge válasznál a feldolgozás sorrendjében haladj. Egy teszteset több hibát is kaphat: a hiányos keresés mellett a modell alá nem támasztott állítást is tehet.

1. Megvan a szükséges információ az ellenőrzött tudásbázisban? Ha nincs, tartalmi hiányt jelölj, és a forrást javítsd.
2. Megjelent a szükséges részlet a kereső találatai között és a modellnek átadott kontextusban? Ha egyikben sem, a visszakeresést; ha csak a végső kontextusból hiányzik, a rangsorolást vagy a kontextus összeállítását vizsgáld.
3. Tesz a válasz olyan állítást, amelyet az átadott kontextus nem támaszt alá? Ezt forráshűségi hibaként jelöld akkor is, ha a keresés szintén hibázott.
4. A válasz a kérdésre felel, és tartalmazza az elvárt lényeges elemeket? A mellékszál relevanciahiba, a rendelkezésre álló bizonyíték ellenére kihagyott elem teljességi hiba.

Feltételezett tesztesetként képzelj el egy visszatérítési szabályzatot, amely bizonylatot ír elő. Ha a keresés csak a visszatérítés lehetőségét hozza vissza, a feltétel már a kontextusból hiányzik. Ha a bizonylat szerepel a kontextusban, de a válasz elhagyja, a teljesség sérül. Ha a válasz azt állítja, hogy bizonylat nélkül is jár visszatérítés, miközben a kontextus az ellenkezőjét írja, forráshűségi hiba is keletkezik.

Az átlag mellé tartsd meg az egyedi besorolást

Minden tesztesetnél tárold külön a keresési, forráshűségi, relevancia- és teljességi eredményt, valamint a hibát kiváltó részletet. Két futás hasonló átlaga mögött eltérő problémák állhatnak: az egyikben hiányoznak a szükséges találatok, a másikban megvannak, de a válasz nem használja fel őket. A javítandó lépést az esetenkénti mérés mutatja meg.

Modell- vagy tudásbáziscsere után ugyanazokhoz a kérdésekhez az új találatokat, az átadott kontextust és az új választ is rögzítsd. Így külön látható, hogy a változás a rendelkezésre álló bizonyítékot, annak kiválasztását vagy a válasz megfogalmazását érintette.