TL;DR
A RAG tutorial könnyű. A RAG production nehéz — de nem azért, amit gondolsz. Nem az algoritmus a nehéz, hanem az üzemeltetés: az indexelési pipeline karbantartása, az embedding modellek verzióváltása, a dokumentumfrissítési protokoll hiánya, a stale index csendes mérgezése, és a RAGAS metrikák production monitoringba való ültetése. Ez az öt buktató az, ami a legtöbb RAG projektet visszafogja az igazán production-ready állapottól.
Amikor a demo hazudik
Az első RAG demo mindig lenyűgöző. Betöltesz néhány PDF-et, generálsz embeddingeket, feltolod egy vektoros adatbázisba, és az LLM hirtelen pontosan válaszol a dokumentumaidra vonatkozó kérdésekre. A bemutató tökéletes.
Aztán három hónappal később, mikor a rendszer production-ban fut, elkezdesz furcsaságokat tapasztalni. A rendszer néha nem találja meg azt, amit biztosan indexelt. Egy dokumentumfrissítés után az előző verzió tartalma is visszajön. Az új embedding modellre való átállás után a keresési minőség regressziót mutat, de nem tudod pontosan hol. A support csapat jelzi, hogy bizonyos kérdéstípusoknál a rendszer „hallucinálja” az adatokat.
Nem egyedi eset. Ezek strukturális buktatók, amelyek szinte minden érett RAG implementációban megjelennek — csak a tutorial fázisban nem látszanak, mert ott a korpusz statikus, kicsi, és nincs valódi felhasználói nyomás a rendszeren.
1. buktató: Az indexelési pipeline nem pipeline, hanem szkript
A legtöbb RAG projekt azzal indul, hogy valaki ír egy Python szkriptet, ami betölti a dokumentumokat, darabolja, embeddinget generál, és feltöltik a vektoros adatbázisba. Egyszeri futtatásra tökéletes.
A probléma akkor kezdődik, mikor ez a szkript lesz a „pipeline.” Nincs idempotencia: ha kétszer futtatod, duplán indexeled a dokumentumokat. Nincs hibakezelés: ha egy dokumentum betöltése megakad a félúton, nem tudod, milyen állapotban van az index. Nincs audittrail: nem tudod visszanézni, mikor indexeltek be mit, melyik verzióból.
A production indexelési pipeline minimum követelményei: dokumentum-szintű hash alapú változáskövetés, idempotens betöltés (ugyanazt a dokumentumot kétszer betöltve ne duplikálódjon), hibakezelés részleges sikerrel (sikertelen dokumentumok naplózása, nem a teljes batch eldobása), és explicit törlési protokoll (ha egy dokumentumot kivesznek a forrásból, az index is frissüljön).
Ez nem glamorous munka. De enélkül az index fokozatosan korrupt lesz — és ezt nem egyből veszed észre.
2. buktató: A stale index csendes mérgezése
A stale index az egyik legsurfaceán láthatatlan probléma. A forrás dokumentumok frissülnek — a vállalati policy megváltozik, a termékleírás módosul, a jogszabály hatályát veszti —, de az index nem követi. Az LLM a régi, elavult chunkot hozza fel, és magabiztosan válaszol belőle.
A veszélyes az, hogy a válasz formailag tökéletes. Nincsen hallucináció abban a szokásos értelemben, hogy az LLM kitalált valamit. Korrektül idéz egy forrást — csak az a forrás már elavult. A felhasználó nem tudja megkülönböztetni a friss és az elavult választ.
A megoldás két részből áll. Az egyik a technikai: minden indexelt dokumentumhoz tárold el a betöltés dátumát és a forrás utolsó módosítási dátumát, és rendszeres audittal detektáld a delta-t. A másik a szervezeti: legyen explicit dokumentumgazda protokoll, ahol minden forrás dokumentumhoz hozzá van rendelve, ki felelős a frissítéséért, és milyen ciklusban kell az indexet szinkronizálni.
A tapasztalatom szerint a stale index problémát mindig a szervezeti fél oldja meg, nem a technikai. A frissítési pipeline elkészíthető egy hétvége alatt. A felelősségi mátrix kialakítása hónapokba kerülhet.
3. buktató: Az embedding modell verzióváltás koordinálatlan
Jön egy jobb embedding modell. Logikusnak tűnik frissíteni. Frissítesz — és a keresési minőség regressziót mutat bizonyos lekérdezéstípusoknál, annak ellenére, hogy az új modell benchmark-on jobb.
A probléma: az indexed az előző modell vektorterét tükrözi. Az új modell más vektortérben operál — a cosine similarity nem kompatibilis a két tér között. Ha csak a query-side-ot frissíted modellt, de az index marad, a keresés törik.
A teljes újraindexelés nyilvánvaló megoldás, de produkciós rendszernél ez leállást vagy kettős infrastruktúrát jelent. Az A/B tesztelés itt különösen fontos: az új embedding modellt párhuzamosan kell futtatni a régivel, mindkét indexre keresni, és a RAGAS metrikákon mérni a delta-t, mielőtt a régi indexet lenyomják.
Ami a legtöbb csapatot megakasztja: nincs előzetesen definiált rollback stratégia. Ha az új modell rosszabbul teljesít egy specifikus dokumentumtípuson, vissza kell-e állítani az egészet? Melyik index marad, ha az A/B teszt vegyes képet ad?
4. buktató: A chunk stratégia nem egy döntés, hanem egy folyamat
A dokumentumok darabolása (chunking) látszólag egyszeri döntés: fix méret, sliding window, vagy szemantikai határok. Az induláskor választasz egyet, és „kész.”
Produkciós tapasztalat alapján ez nem így működik. Különböző dokumentumtípusok eltérő chunkolási stratégiát igényelnek. Egy jogi szerződésnél a cikkelyek egységek — a fix méretű darabolás pont a lényeges határokat vágja át. Egy technikai dokumentációnál a fejezetek a természetes egységek. Egy chat-exportnál az idői szegmensek.
Ráadásul, ahogy a korpusz nő és a lekérdezési minták megváltoznak, a chunk stratégia szuboptimálissá válik. Azok a kérdéstípusok, amelyeket a felhasználók valójában feltesznek, nem mindig azok, amelyeket a tervezési fázisban feltételeztél.
A megoldás: tartsd fenn a nyers dokumentumok és a chunkolt verzió elkülönítését. Ha az indexelt reprezentáció mindig a forrásból regenerálható, a chunk stratégia bármikor megváltoztatható és újraindexelhető. Ha az eredeti dokumentum eltűnik és csak a vektoros index marad, bármilyen stratégiaváltás elveszett munkát jelent.
5. buktató: A RAGAS nem egy egyszeri kiértékelés
A RAGAS (Retrieval Augmented Generation Assessment Suite) metrikák — context precision, context recall, faithfulness, answer relevancy — kiválóak a RAG pipeline minőségének mérésére. A legtöbb csapat egyszeri kiértékelésként használja: a fejlesztés végén lefuttat egy tesztet, látja a számokat, és deployol.
A probléma: a minőség driftl. A korpusz frissül, a lekérdezési minták változnak, az LLM is frissülhet. Az egyszer jó RAGAS pontszám nem garancia arra, hogy hat hónappal később ugyanolyan jó lesz a rendszer.
A production RAGAS monitoringnak legalább három rétege kell legyen. Az offline kiértékelés — egy kuráló testquery-seten rendszeres futtatás, amelynek eredménye trendszerűen követhető. Az online proxymérés — olyan jelek gyűjtése, amelyek a valódi teljesítményt indirekt módon jelzik (pl. user feedback, visszakérdezési arány, a válaszban szereplő source-ok kattintási aránya). És a regressziós riasztás — ha a minőségi metrika egy meghatározott küszöb alá esik, az triggereljen figyelmet, nem csak az egyedi rossz válasz.
Ez szoftvermérnöki infrastruktúra, nem AI-tudomány. De anélkül a RAG rendszer elő soha nem tudja hozni, hogy mikor, miért, és mennyit romlott — és ezzel a javítás is vak lövészetre redukálódik.
A RAG demo egyszerű. A production RAG az a feladat, ahol az architektúrai gondolkodás, az üzemeltetési érettség és a szervezeti folyamatok összetalálkoznak. Az öt buktató nem technológiai újítással kerülhető el — hanem azzal, hogy időben megkérdezed: mi lesz három hónap múlva, ha ez a rendszer valódi terhelés alatt fut?
Kapcsolódó gondolatok
Varga Zoltán - LinkedIn Neural • Knowledge Systems Architect | Enterprise RAG architect PKM • AI Ecosystems | Neural Awareness • Consciousness & Leadership A production rendszer nem attól jó, hogy indul — hanem attól, hogy hat hónap múlva is jó.