Van egy nagyon ismerős sztori. Egy csapat épít egy RAG demo-t — a vállalati ügyfél-info chatbot mondjuk. Bedobálnak 10-15 PDF-et, vector DB-be töltik, kérdeznek, kapnak választ. Bemutatják a vezetőségnek. Tetszik. Megkapják a zöld jelzést.
Aztán élesítik. Nem 10 dokumentummal, hanem 10 000-rel. És minden szétesik.
A válaszok hirtelen rossz dokumentumokra hivatkoznak. A felhasználó megkérdez valamit a 2024-es szabályzatról, kap egy idézetet a 2019-esből. Random kollégák egymás adatait látják. A válaszidő 8 másodpercre nő. A számla a vártnál háromszor nagyobb.
És a csapat zavarba jön. „De a demo-n működött…"
A demo nem az éles rendszer
Ezt szoktam elmagyarázni: a RAG egy nagyon furcsa technológia, mert a demo verzió valóban egyszerű. Egy LangChain quickstart, fél óra, működik. Ezért nagyon megtévesztő. Mindenki azt hiszi, hogy ami működik 10 dokumentumon, az működni fog 10 000-en. Nem.
Ami a demo-n működik, az 10 jól megválogatott PDF, ami szinte garantáltan tartalmazza a választ. A vektoros keresés ott szinte nem is tud rosszul választani — minden chunk releváns, hiszen mindegyik az adott témáról szól.
10 000 dokumentumon más a játék. A te kérdésedhez a top 5 között lesz igazi releváns chunk, és lesz négy olyan, ami csak hasonlít rá szemantikailag. A modell mindkettőből „választ". Aztán hivatkozik. Aztán hallucinál.
És ez nem azért van, mert a vector DB rossz. Hanem mert a vektoros keresés gyors, de zajos. A demo-n nem látszott, mert nem volt mit megzavarnia. Éles rendszerben látszik, mert van.
Az első 3 dolog, ami baj lesz
Nem akarok itt RAG-tutorialba menni — a részleteket leírtuk a tudástári anyagban. De van három dolog, ami garantáltan elő fog jönni, és amit mindig korán érdemes átgondolni.
A chunking. Hogyan vágod fel a dokumentumokat darabokra. A legtöbb csapat fix karakterszámmal vág, mert ez van a quickstartban. Ez félbevágja a mondatokat, a táblázatokat, a kódblokkokat. A modell később nem érti, miről szól a chunk, mert hiányzik az eleje vagy a vége. Szemantikus határokon vágj — bekezdés, fejezet, header. Nem nehéz, csak fegyelem kell hozzá.
Az „A bérlő (tenant) látja B bérlő adatait" hiba. Multi-tenant rendszereknek a leggyakoribb biztonsági lyuka. A naiv megoldás: lekérdezed a top 10 chunkot, aztán JavaScripttel kiszűröd, ami nem a felhasználóé. Soha ne csináld így. A szűrésnek a vector DB-ben, query-szinten kell futnia. Egyrészt ha véletlenül kihagyod a JS-szűrőt, azonnal adatszivárgás. Másrészt ha a top 10 mind másik bérlőé, üres választ kapsz, és nem tudod, miért.
A „nincs erre infó" engedélye. Ha a system promptodban nem írod le explicit, hogy „ha a forrás nem tartalmazza a választ, mondd ki, hogy nincs benne" — akkor a modell mindig fog választ adni. Még akkor is, ha a chunkokban nincs benne. Mert az alap-személyisége az, hogy segítőkész asszisztens, és a segítőkész asszisztens válaszol. Ha te nem mondod meg neki, hogy szabad nem válaszolni, soha nem fog.
A mérés
Ezt látom a legritkábban beépítve. A csapat felépíti a RAG-et, élesíti, és soha nem méri. „Működik" — amíg egy ügyfél nem panaszkodik. Akkor pánik, troubleshooting, és senki nem érti, miért romlott el, mert nincs baseline. Mihez képest romlott?
A megoldás: 20–50 kézzel írt kérdés–várt-válasz pár, lefuttatva a rendszeren minden héten vagy minden változtatás után. Ha az új chunkolási stratégia 0,84-ről 0,71-re viszi a Recall@5-öt, azonnal látod, és visszacsinálod. Nem 3 hét múlva, egy panaszból.
Ez nem rocket science. Egy pár órás munka az induláskor, és onnantól pár perc minden release-nél. Cserébe nem vakon megy a rendszer.
A kettős mérce
És itt van az, ami miatt szerintem sok RAG-projekt szétesik: a csapat kétféle mércével mér.
A demo-t mérik azzal, hogy szubjektíve „jónak tűnik-e a válasz". A production-t sehogy. De a vezetőség elvárása ugyanaz, mintha mérnék: 95% pontos válasz, mindig.
És így a csapat olyan rendszert futtat éles ügyfélen, amiről nem tudja megmondani, hogy a múlt héten 60%-ban volt-e helyes vagy 90%-ban. Csak akkor tudja meg, ha valaki rákérdez. És akkor már késő.
A jó RAG-rendszer nem trükkös. Csak fegyelmezett. Minden réteget mérsz, minden változtatást ellenőrzöl, minden hibát logolsz. Ezt a fegyelmet sokkal könnyebb beleépíteni az elején, mint utólag. Az elején 2 nap. Utólag 2 hónap.
És az utolsó 2-5% mindig human-in-the-loop. Ezt fogadd el. Aki azt ígéri, hogy 100%-ban autonóm RAG-rendszer lesz, az vagy nem értette meg, vagy hazudik.
Ha mélyebbre mennél: a teljes architektúrát — chunking, hybrid search, re-ranking, query rewriting, eval suite, production gotchák, latency budget — a tudástári RAG a gyakorlatban anyagban dolgoztuk ki, TypeScript kódpéldákkal.