TL;DR
Az 1 millió tokenes context windowk nem teszik feleslegessé a RAG-ot — csak megváltoztatják a döntési teret. A long context előnye az egyszerűség és a teljes dokumentum-kohézió. A RAG előnye a cost, a latency, a frissíthetőség és a pontosság kontrollálhatósága. A választás nem technológiai dogma kérdése, hanem négy változó függvénye: a korpusz mérete, a frissítési ciklus, a lekérdezés típusa, és a válaszminőségre vonatkozó elvárás. Legtöbbször a két megközelítés nem egymást kizáró, hanem egymást kiegészítő.
Egy régi vita újjáéledt
2024 elején, amikor a Gemini 1.5 Pro 1 millió tokenes context windowt mutatott be, rengeteg kommentátor deklarálta a RAG halálát. A logika csábítóan egyszerű volt: ha az egész dokumentumgyűjteményt betöltheted a promptba, minek az indexelés, a chunk-stratégia, a vektoros keresés bonyolultsága?
A vita nem új. Ugyanez zajlott le, amikor a GPT-4 Turbo 128k tokenre bővítette a kontextust. Akkor is sokan temették a RAG-ot — és akkor is korán jöttek a temetők.
Most, 2026-ban a helyzet összetettebb, mint az egyszerű „melyik a jobb” kérdés megengedi. Nem azért, mert a long context nem valódi fejlődés — az. Hanem azért, mert a fejlődés más feltételeken múlik, mint amit a headline benchmark-ok mutatnak.
A lost-in-the-middle probléma nem tűnt el
Nelson et al. 2023-as munkája, majd az azóta megjelent replikációk konzisztensen mutatnak egy strukturális problémát a long-context modelleknél: az információ visszanyerési teljesítménye a context ablak elején és végén a legerősebb, a közepén szisztematikusan esik. Ezt hívják „lost in the middle” jelenségnek.
Ha 800 000 tokennyi dokumentumba ágyadod el a releváns részletet a 400 000. tokennél, a modell valószínűbb, hogy elmulasztja, mint ha explicit RAG-gal a kontextus elejére húzod. Ez nem modellhiba az egyszerű értelemben — hanem az attention mechanizmus természetes korlátja, amely az előtér-háttér dinamikát skaláris pozícióba kódolja.
A RAG ezzel szemben garantálja, hogy csak a kiválasztott, releváns chunkök kerülnek a promptba — és azok a kontextus elejére kerülnek. Ez nem egyszerűen olcsóbb: pontosabb is.
A négy döntési változó
A döntéshez négy kérdést érdemes végigjárni:
1. Mekkora a korpusz, és változik-e?
Ha a tudásbázis statikus és belefér 50-100k tokenbe, a long context komolyan versenyképes. Nincs indexelési pipeline, nincs frissítési protokoll, nincs retrieval-hibaszint. Egyszerűen beletöltöd a dokumentumokat és kész.
Ha a korpusz nagy (100k token felett), vagy rendszeresen frissül — napi adatbetöltés, dinamikusan változó dokumentáció, valós idejű adatforrások —, a long context problémássá válik. Nemcsak a cost miatt, hanem azért is, mert minden lekérdezéskor újra fel kell tölteni az egész kontextust. A RAG indexe egyszer épül fel, aztán csak a delta frissül.
2. Milyen a lekérdezés típusa?
Vannak kérdések, ahol az egész dokumentum összefüggése számít: egy szerződés teljes értelmezése, egy könyv narratív elemzése, egy hosszú kutatási anyag szintézise. Ezeknél a long context természetes előny — az összefüggések a dokumentum egészén átívelnek, és a chunkolás pont ezeket a kapcsolatokat tördelné szét.
Vannak ezzel szemben faktikus lekérdezések, ahol egyetlen, pontosan meghatározott részlet kell: egy termékadat, egy jogszabályi hivatkozás, egy konfiguráció. Ezeknél a RAG a természetes eszköz — az indexelés és a keresés pont erre van optimalizálva.
3. Mekkora a cost és latency érzékenység?
1 millió token inputként való feldolgozása drága. Egy egyszerű számítás: ha a korpusz 500 oldalas (kb. 350-400k token), és naponta 1000 lekérdezés fut, az napi 350-400 millió token input processzálást jelent. Ez más nagyságrend, mint egy RAG rendszer, ahol lekérdezésenként átlagosan 2-5k token kerül a promptba.
A latency szintén más: egy long-context modell a teljes ablak betöltésekor lassabb, különösen az első válasz tokenjéig eltelt idő (time to first token) növekszik a kontextus méretével.
4. Szükséges-e a válasz auditálhatósága?
Ez a vállalati kontextusban döntő szempont. A RAG rendszerek — amennyiben megfelelően vannak implementálva — visszakövethetővé teszik, hogy melyik chunkből jött az adott állítás. Ez source attribution, és compliance, jogi, vagy belső auditálási szempontból értéke van.
A long-context modell szintetizál — de a szintézis forrása kevésbé átlátható. Nehezebb megmondani, hogy egy adott válasz a dokumentum melyik részéből következik.
A hibrid megközelítés: amikor mindkettő kell
A legérettebb production implementációk ma már nem választanak — hanem kombinálnak. Egy tipikus architektúra: a RAG-rendszer előszűri a releváns chunkokat (top-20 vagy top-50 jelölt), majd ezeket egy közepes méretű, de gyors long-context modellnek adja át szintézisre. Ez az úgynevezett RAG-then-read vagy retrieve-and-synthesize pattern.
Ez az architektúra megőrzi a RAG keresési pontosságát és cost-hatékonyságát, miközben a long context modell a beillesztett szövegen belüli kohéziót és szintézist végzi el. A két megközelítés komplementer, nem rivális.
Mikor döntsek tisztán long context mellett?
Három szituáció van, ahol én ma long-context-first megközelítést javaslok, RAG nélkül:
Egyrészt, ahol a teljes dokumentum összefüggése elválaszthatatlan a kérdéstől — például hosszú jogi szerződések, ahol egy kifejezés értelmezése az egész dokumentum kontextusától függ. Másrészt, ahol a korpusz kicsi és statikus, és az egyszerűség versenyelőny. Harmadrészt, ahol prototipizálás folyik, és az indexelési pipeline komplexitása felesleges overhead a korai validációs fázisban.
Minden más esetben, ahol a rendszer production-érettséget kell elérjen, a RAG — vagy legalább a RAG-then-read hibrid — jelenleg erősebb alapokat ad. Nem azért, mert az embedding-keresés magasabb rendű technológia, hanem azért, mert a kontroll, a frissíthetőség és a cost-profil összességében jobb üzleti döntést alkot.
A long context window nem a RAG vége. Inkább egy új eszköz a toolboxban, amelyik jó esetben a RAG-gal együtt teszi a rendszert jobbá.
Kapcsolódó gondolatok
Varga Zoltán - LinkedIn Neural • Knowledge Systems Architect | Enterprise RAG architect PKM • AI Ecosystems | Neural Awareness • Consciousness & Leadership The best architecture is the one that fits the problem, not the trend.