Mi a RAG, egy mondatban?
Az elnevezés egy 2020-as kutatásból származik. A szerzők így definiálták: olyan modell , amely a betanított („parametrikus") tudást és egy külső, kereshető memóriát kapcsol össze a válasz előállításához.
A gyakorlatban ez három lépés, minden egyes kérdésnél:
1. A kérdésedből keresés lesz
A rendszer megkeresi, mely dokumentumrészletek
relevánsak. (Ez a "retrieval".)
2. A találatok bekerülnek a promptba
Nem az egész dokumentum - néhány kiválasztott
részlet, a kérdés mellé.
3. A modell ebből válaszol
A saját tudása MELLETT ott van előtte a te
szöveged is. (Ez az "augmented generation".)
A kulcs a harmadik lépés utáni pillanat: a modell elfelejti. A súlyai nem változtak. A következő kérdésnél újra kell keresni, és a részletek újra bekerülnek. Erről a különbségről szól részletesen a fine-tuning, a RAG és a promptolás című írás, a keresés matematikájáról pedig az embedding és a vektoros keresés témájú poszt.
Egy fogalmi pontosítás, ami sokakat megzavar: az eredeti 2020-as RAG betanítási recept volt — a keresőt és a szöveggenerálót együtt hangolták. A ma RAG-nek nevezett dolog jellemzően nem tartalmaz betanítást: kész embedding modell, kész nyelvi modell, közéjük egy keresőréteg.
Amit a RAG nem old meg
Ez a cikk gerince, mert itt bukik el a legtöbb projekt.
| Mit változtat? | Mikor kell? | Mi az ára? | |
|---|---|---|---|
| RAG | semmit a modellen; a promptba tesz bekérdezett szöveget | ha tényt kell tudnia, ami változik, vagy ami nálad van | keresőréteg, és minden kérdésnél többlet bemeneti token |
| Fine-tuning | a modell súlyait | ha viselkedést, formátumot, hangnemet kell megtanulnia | betanítás, és minden új tény újabb betanítás |
| Hosszú kontextusablak | semmit; az egész anyagot beteszed | ha a teljes anyag elfér, és nem változik naponta | minden kérdésnél a teljes anyag ára tokenben |
A leggyakoribb hiba, hogy valaki a második oszlopot akarja, és az elsőt építi meg — vagy fordítva. Arról, hogy mikor éri meg mégis a középső oszlop, a fine-tuning megtérülése című írás szól méréssel.
És van rá mérés. Egy 2023-as vizsgálat három hétmilliárd paraméteres modellen tesztelte, mi történik, ha teljesen új tudást kell megtanulni. A feladat 910 kérdés volt olyan eseményekről, amiket egyik modell sem láthatott a betanításnál:
| Modell | Alapállapot | + finomhangolás | + RAG |
|---|---|---|---|
| Modell A | 48,1% | 50,4% | 87,5% |
| Modell B | 35,3% | 21,9% | 58,5% |
| Modell C | 45,6% | 51,1% | 87,6% |
Két dolog olvasható ki belőle. Az egyik, hogy a RAG nagyságrenddel többet segít — az első modellnél 39,4 százalékpontot, miközben a finomhangolás 2,3-at. A másik a második sor: ott a finomhangolás 13,4 ponttal rontott. Nem „kevesebbet segített" — ártott.
Van egy harmadik, még kellemetlenebb részlet ugyanebből a mérésből: egy másik feladaton a finomhangolt modell RAG-gel (65,9%) rosszabb volt, mint a sima alapmodell RAG-gel (68,1%). A szerzők összegzése: az alapmodellt használni generátorként következetesen jobb volt, mint csak finomhangolni.
(Preprint, három hétmilliárd paraméteres modell — a mai nagy modellekre a pontos számok nem vihetők át. Az irány igen.)
Mennyit javít a hallucináción?
Erre nincs egyetlen szám, és aki mond egyet, az valószínűleg nem mérte. Ami van: feladatspecifikus mérések, egymással össze nem vethető definíciókkal. Ez önmagában fontos információ.
A legjobb közülük egy lektorált vizsgálat, ami 202 gondosan összeállított kérdéssel tesztelt három dedikált, professzionális jogi kutatóeszközt — tehát nem házi barkácsolást, hanem drága, célra épített RAG-termékeket.
Először a definíció, mert ez a hasznos rész. A vizsgálat szerint egy válasz akkor hallucinált, ha vagy tárgyi tévedés, vagy rosszul megalapozott — vagyis hivatkozik egy létező forrásra, ami nem támasztja alá, amit állít.
Ez a második eset az, amit a RAG látszólag megold (van hivatkozás!), valójában nem.
| Eszköz | Pontos válasz | Hallucinált | Hiányos |
|---|---|---|---|
| A | 65% | 17% | 18% |
| B | 41% | 33% | 25% |
| C | 19% | 17% | 62% |
(A három érték a vizsgálat saját kategóriái; a sorok kerekítés miatt nem mindenhol adnak ki pontosan százat.)
A szerzők következtetése: bár a RAG láthatóan javít, a hallucináció problémája jelentős szinten fennmarad.
És egy csavar, amit a legtöbb összefoglaló elront: a C eszköz 17%-os hallucináció s rátája mellé oda kell írni a 62%-os hiányossági rátát — a kérdések közel kétharmadára nem adott érdemi választ. A három szám a hiányossági ráta nélkül nem összehasonlítható. Arról, hogy egyáltalán miért talál ki dolgokat egy modell, a hallucináció okai című írás szól.
Az ellentmondó bizonyíték: a RAG nem tesz biztonságosabbá
Ezt a részt sokan kihagyják, pedig a legmeglepőbb lelet a témában.
Egy 2025-ös, lektorált vizsgálat 11 modellt tesztelt 5 592 ártalmas kérdéssel, 16 kockázati kategóriában. A kérdés az volt: biztonságosabb lesz-e egy modell attól, hogy csak a bekérdezett dokumentumokból dolgozik?
| Mérés | Érték |
|---|---|
| Egy nyolcmilliárd paraméteres modell nem biztonságos válaszai RAG nélkül | 0,3% |
| Ugyanaz RAG-gel | 9,2% |
| A bekérdezett dokumentumok, amik maguk is ártalmas anyagot tartalmaztak | 5,3% |
| A nem biztonságos kimenetekből az, ami BIZTONSÁGOS dokumentumból jött | 81,8% |
Harmincszoros romlás — és a romlás négyötöde nem attól van, hogy rossz dokumentumot talált a rendszer.
A szerzők magyarázata: a biztonsági finomhangolás arra tanítja a modellt, hogy bizonyos irányokat ne dolgozzon fel. Amikor viszont releváns kontextust kap, a témát nem érzékeli kockázatosnak, és feldolgozza.
Két további megállapítás ugyaninnen: a modellek a saját belső tudásukat is hozzáteszik a bekérdezett dokumentumokhoz, akkor is, ha az utasítás ezt tiltja; és a hosszabb kontextus növeli a sebezhetőséget. Plusz egy üzemeltetési következmény: a RAG nélküli környezetben működő biztonsági tesztek átvitel után nem működtek — vagyis a meglévő tesztelésed nem méri a RAG-rendszeredet.
Hét pont, ahol elromlik
Egy 2024-es tapasztalati jelentés — három valós bevezetésből, köztük egy 4 017 dokumentumos, 1 000 kérdéses orvosi rendszerből — hibataxonómiát állított fel. Érdemes megtanulni, mert a RAG-hibák mind ide sorolhatók:
| # | Hibapont | Mi történik |
|---|---|---|
| 1 | Hiányzó tartalom | A válasz nincs benne a dokumentumokban, a rendszer mégis generál |
| 2 | Nem került a találatok közé | Benne van, de nem jut be a legjobb néhány közé |
| 3 | Kiesett a kontextusból | Bekerült a találatok közé, de az összefűzés kidobta |
| 4 | Nem szedte ki | Ott van előtte, de a modell nem használja — zaj vagy ellentmondás miatt |
| 5 | Rossz formátum | Figyelmen kívül hagyja a formátum-utasítást |
| 6 | Rossz részletesség | Túl általános vagy túl konkrét válasz |
| 7 | Hiányos | Kihagy olyat, ami benne volt a kontextusban |
Az első hibapont a legfontosabb, mert az egyetlen, ami semmilyen technikával nem javítható. Ha a dokumentumaid nem tartalmazzák a választ, akkor nincs az a chunkolás, keresés vagy modell, ami előhozza.
És a jelentés legfontosabb mondata, amit minden megrendelőnek tudnia kellene:
„Egy RAG-rendszer érvényesítése csak üzem közben lehetséges."
Vagyis: nem tudod fejlesztés közben megmondani, jó lesz-e. Nem azért, mert rossz a fejlesztő, hanem mert a rendszer viselkedése a valódi kérdésektől és a valódi dokumentumoktól függ. A RAG nem projekt, hanem üzemeltetés. A mérés módjáról a RAG-rendszer ellenőrzése című írás szól részletesen.
Mikor NE építs RAG-et?
Öt eset, mindegyik elsődleges forrásból vagy mérésből:
1. Ha az egész anyag elfér a kontextusablakban. Erre van a legkonkrétabb gyártói küszöb, és szokatlanul őszinte, mert a saját bonyolultabb megoldásuk ellen szól:
„Ha a tudásbázis od kisebb, mint 200 000 token (nagyjából 500 oldal anyag), egyszerűen beteheted az egészet a promptba, RAG nélkül."
(Az 500 oldal angol szövegre értendő. Magyarra a tokenarány rosszabb, tehát a küszöb lényegesen kevesebb oldalnál van — erről a token és a context window című írás ad támpontot.)
2. Ha a kérdések nem tényalapúak. Stílus, formátum, hangnem: az fine-tuning, nem RAG.
3. Ha nincs, aki karbantartsa. Lásd fentebb: az érvényesítés csak üzem közben lehetséges — és az elavult tudásbázis mérhetően rosszabb az üresnél, ahogy a tudásbázis frissen tartása témájú poszt megmutatja.
4. Ha a dokumentumaid nem tartalmazzák a választ. Az első hibapont nem javítható.
5. Ha biztonsági intézkedésnek szánnád. A mérés szerint fordítva sül el.
Ehhez jön egy hasznos szám arról, mennyivel jobb egyáltalán a RAG a puszta hosszú kontextusnál. Egy 2024-es vizsgálat kilenc adathalmazon hasonlította össze a kettőt, és azt találta, hogy a kérdések 63%-ánál a két megoldás pontosan ugyanazt a választ adta, 70%-ánál pedig a pontszámkülönbség tíz alatt maradt.
(2024 közepi modellekkel mérve. A 63%-os egyezés gondolata átvihető, a konkrét százalékok nem.)
A költség, ahol nem gondolnád
[Saját számítás] Vegyünk egy tízezer dokumentumos tudásbázist, dokumentumonként öt oldallal — nagyjából 25 millió token, 512 tokenes darabokra vágva, 25% átfedéssel 65 ezer chunk.
A nyers vektorok mérete:
65 000 chunk × 1 536 dimenzió × 4 bájt = 0,40 GB
A keresőindex ehhez képest elhanyagolható: ugyanerre a méretre nagyjából 10 MB. Metaadattal és nyers szöveggel együtt reálisan 1 GB körül vagyunk.
Egy gigabájt. Ennyi. A tárolás havi díja a szolgáltatóknál tized dollárokban mérhető.
És itt jön a lényeg: a belépő csomagok havi minimumdíja 16 és 250 dollár között mozog. Vagyis a fogyasztásod nagyságrendekkel a minimum alatt lesz. A valódi költséged nem a fogyasztás, hanem a minimumdíj — és ez a legtöbb kalkulációból kimarad.
A beágyazás egyszeri költsége ugyanilyen meglepő: a 25 millió token beágyazása kevesebb, mint egy dollár.
A pénz a válaszadásnál van. Ugyanaz a havi tízezer kérdés — a modell választásától függően — nagyjából 26 és 635 dollár között kerül. Huszonnégyszeres különbség, ugyanazért a munkáért.
Három következtetés ebből:
- A tárolás és a beágyazás gyakorlatilag ingyen van. Aki ezen spórol, rossz helyen keresi.
- A modellválasztás a valódi költségtétel. Itt van a huszonnégyszeres szorzó.
- A minimumdíjak miatt a kis tudásbázis aránytalanul drága. Egy ezer dokumentumos rendszer nagyjából ugyanannyiba kerül havonta, mint egy tízezres.
A how-to
1. ELŐBB KÉRDEZD MEG: TÉNY VAGY VISELKEDÉS?
Tény -> RAG. Stílus, formátum, hangnem ->
fine-tuning. Ez a döntés, nem a technológia.
2. MÉRD MEG, MEKKORA AZ ANYAG
200 ezer token alatt tedd be egyben, és kész.
RAG csak fölötte.
3. KEZDD HÚSZ VALÓDI KÉRDÉSSEL
Írd le, mit fognak kérdezni, ÉS mi a jó válasz.
Enélkül nincs mihez mérni.
4. NÉZD MEG, BENNE VAN-E EGYÁLTALÁN A VÁLASZ
A leggyakoribb hiba az, hogy nincs. Ezt kézzel
ellenőrzöd, nem szoftverrel.
5. ELŐBB A KERESÉST MÉRD, NE A VÁLASZT
Ha a jó részlet nem kerül be a találatok közé,
a modell nem tud mit kezdeni vele.
6. TERVEZZ ÜZEMELTETÉST, NE PROJEKTET
Az érvényesítés csak üzem közben lehetséges.
Legyen gazdája és havi ellenőrzése.
7. A JOGOSULTSÁGOT AZ ELSŐ NAPON OLDD MEG
Ki mit láthat. Utólag beépíteni sokkal drágább,
és néhány rendszerben egyáltalán nem megy.
8. SZÁMOLJ A MINIMUMDÍJJAL, NE A FOGYASZTÁSSAL
A tárolás fillér. A havi minimum nem az.
A hetedik pont az, amit a legtöbben későn vesznek észre. Ha a chatbot azt is visszaadja, amit a kérdező nem láthatna, az nem hiba, hanem adatvédelmi incidens — és a jogosultságkezelés több rendszerben utólag nem kapcsolható be.
Tipikus félreértések
- „A RAG megtanítja a modellnek a dokumentumaimat." Nem. A modell súlyai nem változnak. A dokumentum a kérdés pillanatában, a promptban jut el hozzá, és a válasz után nincs többé ott.
- „Ha van hivatkozás, akkor igaz." A hivatkozott mérés definíciója szerint a hallucináció egyik fele pont az, hogy létező forrásra hivatkozik, ami nem támasztja alá az állítást.
- „A RAG-gel biztonságosabb lesz a rendszer." Egy 11 modelles mérésben harmincszorosára nőtt a nem biztonságos válaszok aránya, és a romlás négyötöde biztonságos dokumentumokból jött.
- „Előre le lehet tesztelni." A tapasztalati jelentés szerint az érvényesítés csak üzem közben lehetséges.
- „Kis tudásbázisnál olcsóbb." A tárolás igen, de a havi minimumdíjak miatt egy ezer dokumentumos rendszer nagyjából ugyanannyi, mint egy tízezres.
- „Elég a jobb modell." A hét hibapontból három a keresésnél és a darabolásnál keletkezik — oda a modell nem lát be.
Amit érdemes elvinni
A RAG a leghatékonyabb módja annak, hogy egy modell a te tényeidből válaszoljon: a mérés szerint új tudásnál nagyságrenddel többet ad, mint a finomhangolás, ami időnként még ront is.
De három dolgot érdemes reálisan látni. Nem tanítás — a modell nem lesz okosabb, csak jobban informált, kérdésenként. Nem old meg mindent — a hallucináció professzionális termékeknél is 17–33% között maradt, és a biztonságot mérhetően rontja. És nem projekt, hanem üzemeltetés — az érvényesítése csak működés közben lehetséges.
A legjobb első lépés ezért nem technológiai: írj le húsz valódi kérdést, és nézd meg kézzel, hogy a dokumentumaid tartalmazzák-e rájuk a választ. Ha nem, a RAG nem fog segíteni — és ezt egy délelőtt alatt megtudod, nem három hónap alatt.
A dokumentumok előkészítéséről a chunking című írás szól, a tárolásról pedig a vector database témájú bevezető.