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 policy-ról, kap egy idézetet a 2019-esből. Random kollégák egymás adatait látják. A latency 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 a production
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 vector search ott szinte nem is tud rosszul választani — minden chunk releváns, mert minden chunk amúgy is 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 vector search gyors, de zajos. A demo-n nem látszott, mert nem volt mit zavarnia. Production-ben 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 tenant lássa a B tenant adatait" hiba. Multi-tenant rendszereknél a leggyakoribb biztonsági lyuk. 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 filter a vector DB-ben kell, hogy fusson, query-szinten. Mert egyrészt ha véletlenül kihagyod a JS filtert, adatszivárgás. Másrészt ha a top-10 mind másik tenanté, ü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 chunking 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.