AI sorozat interjúkérdés 11: Hogyan hangoljuk a RAG-ot?

A RAG hangolása nem egyetlen lépés finomítása, hanem egy teljes lánc optimalizálásának folyamata. Az alábbiakban négy dimenzióban – adatindexelés, keresés, generálás, kiértékelés – adok szisztematikus hangolási stratégiákat, valamint gyakorlati tapasztalatokat, amelyeket interjún említhetsz.

1. Adatindexelési oldal hangolása (a „tudásbázis” minőségének javítása)

Ez a leggyakrabban figyelmen kívül hagyott, mégis leggyorsabban eredményt hozó terület.

Hangolási pont	Probléma jelensége	Konkrét lépés	Hatásmutató
Dokumentum elemzés	PDF-ben lévő táblázatok, folyamatábrák figyelmen kívül hagyása, vagy szöveg hibás kódolása, sorrendi hiba.	Használj jobb elemzőkönyvtárat (pl. `unstructured`, `pypdf` elrendezésmegőrző módja); táblázatok esetén `pandas`-szal kinyerni, majd Markdownná alakítani.	Visszahívási arány +5~15%
Szövegdarabolás mérete	Túl kicsi chunk esetén kontextusvesztés (pl. „az idei bevételnövekedés” – az „az” névmás elveszik); túl nagy chunk esetén sok a keresési zaj.	Kísérletezz különböző chunk méretekkel (256/512/768 token), átfedés legyen 10–20%; hosszú dokumentumoknál szemantikus határok (bekezdés/cím) szerint vágj, ne rögzített hosszban.	Találati arány / hűség
Metaadatok hozzáadása	Megtalálod a releváns részt, de nem tudod forráshoz vagy időponthoz kötni, esetleg domain szerint szűrni.	Adj metaadatokat minden chunkhoz: `forrás` (fájlnév/URL), `időbélyeg`, `oldalszám`, `dokumentumtípus`. Kereséskor szűrőket használj (pl. `doc_type == 'legal'`).	Szűrési pontosság
Beágyazási modell választása	Általános embedding gyengén teljesít vertikális területeken (egészségügy, kód, jog).	Használj domainre finomhangolt modelleket (BGE-large-zh, GTE-Qwen2-7B-instruct); vagy finomhangold saját embedding modelljedet (triplet loss segítségével).	Keresési MRR@10 +10~20%

2. Keresési oldal hangolása (a „lapozás” pontosabbá tétele)

A keresés határozza meg, hogy milyen „referenciaanyagot” kap az LLM.

Hangolási pont	Probléma jelensége	Konkrét lépés	Hatás
Hibrid keresés	Vektoros keresés nem talál pontos kifejezéseket (pl. termékkód: `ABC-123`), kulcsszavas keresés nem érti a szinonimákat.	Használj egyszerre vektoros (szemantikus) és BM25 (kulcsszó) keresést, súlyozott összeggel (pl. 0,7vektor + 0,3BM25) vagy rerank összeolvasztással.	Visszahívási arány +10~25%
Újrasorolás (Rerank)	A vektoros keresés első néhány eredménye nem feltétlenül a legrelevánsabb; a 10. lehet a legjobb.	Használj cross-encoder modellt (pl. `BGE-reranker-v2`, Cohere Rerank) a jelöltek (pl. első 20) újrapontozásához, majd vedd a top-K-t.	Találati arány jelentős javulása (főleg top-1)
Lekérdezés átírás	A felhasználói kérdés homályos vagy többfordulós beszélgetésben a névmások tisztázatlanok („Mennyibe kerül?”).	Használj LLM-t az eredeti kérdés kereséshez jobban illő formára alakítására (pl. „Mennyi az iPhone 15 ára?”); vagy egészítsd ki a beszélgetéstörténettel.	Visszahívási arány +5~15%
HyDE	A felhasználói kérdés túl rövid vagy elvont (pl. „Beszélj a fotoszintézisről”), a közvetlen keresés gyenge.	Először az LLM-mel generálj egy hipotetikus választ, majd ezzel a válasszal keress a dokumentumban.	Nyílt domainű kérdésekre alkalmas, de nem tényeken alapuló pontos kérdésekre.
Keresési szám Top-K beállítása	Túl kicsi K esetén kulcsfontosságú információ maradhat ki; túl nagy K növeli a tokenfogyasztást és a zajt.	Kísérletezz K=3/5/10 értékekkel, figyeld a visszahívási arány és a válasz hűségének egyensúlyát.	Hatékonyság és eredmény közötti kompromisszum

3. Generálási oldal hangolása (az LLM hatékony használata)

Hiába pontos a keresés, ha a prompt rossz vagy a modell gyenge.

Hangolási pont	Probléma jelensége	Konkrét lépés	Hatás
Prompt tervezés	Az LLM figyelmen kívül hagyja a keresett tartalmat, vagy kitalál dolgokat.	Egyértelmű utasítás: „Csak a megadott referenciaanyagok alapján válaszolj. Ha az anyag nem elég vagy nem releváns, válaszold azt, hogy ‘Nincs elég információ’.” Adj few-shot példákat a forráshivatkozás bemutatására.	Hűség +20~40%
Kontextus tömörítés	A keresett tartalom túl hosszú (meghaladja a modell kontextusablakát), vagy nagy része zaj.	Használj `LLMLingua` vagy `szelektív kontextus` tömörítést, tartsd meg a legrelevánsabb mondatokat, mielőtt az LLM-nek adnád.	Csökkenti az információvesztés kockázatát
LLM modell frissítése	A kisebb modell (7B) nem képes komplex érvelésre, vagy nem emlékszik hosszú kontextusra.	Válts erősebb modellre (GPT-4o, Claude 3.5 Sonnet, Qwen2.5-72B).	Az érvelési pontosság jelentős javulása
Streamelés és hivatkozás	A felhasználó nem tudja ellenőrizni a válasz megbízhatóságát.	A generálás során az LLM adjon ki `[idézet:1]` formátumú hivatkozásokat, amelyek a keresett dokumentum sorszámára utalnak. A backend csatolja az eredeti linket.	Felhasználói bizalom + hibakereshetőség
Elutasítás kalibrálása	A modell találgat, amikor nem kellene, vagy nem válaszol, amikor pedig kellene.	Állíts be egy hasonlósági küszöböt: ha a legjobb chunk koszinusz hasonlósága a kérdéssel 0,7 alatt van, jelezd az LLM-nek, hogy „az anyag nem releváns”.	Csökkenti a hallucinációs arányt

4. Kiértékelés és iteráció (tudd, hova kell hangolni)

Mérés nélkül nincs optimalizálás.

Hangolási pont	Lépés	Mutató
Kiértékelési készlet létrehozása	Készíts 100–300 valós felhasználói kérdést + standard választ + a helyes keresett dokumentum azonosítóit.	Fedjen le különböző nehézségi szinteket és szándékokat.
Automatizált kiértékelés	Használj RAGAS (hűség, válasz relevanciája, kontextus visszahívása) vagy TruLens eszközt.	Három alapmutató: hűség, válasz relevanciája, kontextus visszahívási aránya.
Emberi kiértékelés	Hetente végy 20 rossz esetet, elemezd a hibatípust (keresési hiba / generálási hiba / hiányzó tudásbázis).	Fejlesztési prioritások rangsorolása.
A/B tesztelés	Éles környezetben kosárba tesztek különböző keresési stratégiákat (pl. BM25 vs. hibrid keresés).	Online mutatók: felhasználói elégedettség, válasz nélküli arány.

5. Interjún említhető „gyakorlati tapasztalatok” (pluszpont)

„Az általam vezetett RAG projektben kezdetben a találati arány csak 67% volt. Három dolgot tettem:
1. A darabolást rögzített 1024 helyett dinamikus szemantikus vágásra változtattam (cím + bekezdés szerint), ezzel a találati arány 74%-ra nőtt;
2. Hibrid keresést (vektor + BM25) és egy kis rerank modellt adtam hozzá, ezzel a találati arány 83%-ra emelkedett;
3. Optimalizáltam a promptot és kötelezővé tettem a [Nem található információ] használatát, ezzel a hallucinációs arány 22%-ról 5% alá csökkent.

Emellett létrehoztunk egy folyamatos kiértékelési csővezetéket: minden változtatás előtt lefuttattuk a RAGAS pontszámot 200 kérdésen, biztosítva, hogy ne legyen visszalépés.”

Végösszegzés: egy teljes RAG hangolási útiterv

Adat réteg ─→ Dokumentumtisztítás, darabolás optimalizálása, metaadatok bővítése, domain-specifikus embedding
Keresési réteg ─→ Hibrid keresés, rerank, lekérdezés átírás, HyDE, Top-K hangolás
Generálási réteg ─→ Prompt erősítés, utasítások, tömörítés, hivatkozás, elutasítási küszöb
Kiadási réteg ─→ Kiértékelési készlet, RAGAS, emberi elemzés, A/B tesztelés