RAG architektúra rétegek — 24 mintázat egy kognitív stackben

TL;DR — A RAG nem pipeline. Rétegzett kognitív architektúra.

A RAG (Retrieval-Augmented Generation) nem arról szól, hogy „jó embeddinget” és „jó indexet” választasz. A minőség ott dől el, ahogyan a rendszer a memóriát szervezi, az információt előhívja, a figyelmet allokálja és a bizonytalanságot kezeli. Ez nem pipeline-tervezés — ez kognitív architektúra-tervezés. 24 visszatérő mintázat, mindegyik egy konkrét hibamódot üt ki. Az LLM modell csak neonfény a kódban — az értelem illúzióját a rétegek adják.

„A rendszer nem ott gondolkodik, ahol a modell fut — hanem ott, ahol a rétegek találkoznak.”

Miért nem elég a jó embedding és a jó index?

Az elmúlt hónapokban a saját személyes és vállalati RAG projektemet iteratív körökben vittem — éles kérdésekkel, valós dokumentumokkal, valós hibákkal. A legfontosabb tanulság az lett, hogy a RAG nem pipeline, hanem rétegzett kognitív architektúra. Nem elég „jó embedding” és „jó index”, mert a minőség ott dől el, ahogyan a rendszer a memóriát szervezi, az információt előhívja, a figyelmet allokálja és a bizonytalanságot kezeli.

Ez a felismerés nem új. A kognitív architektúra tervezés klasszikus kérdései — amelyeket az ACT-R (Adaptive Control of Thought — Rational) és a SOAR rendszerek az 1980-as évektől feszegetnek — nagyon tisztán átfordíthatók RAG nyelvre. Nem a technológia új, hanem az alkalmazás kontextusa.

Négy alapkérdés:

Miből áll a hosszú távú memória? Hogyan reprezentálod a tudást, és hogyan keresel benne? Ez a korpusz, az indexek, a metadata, a hierarchia és a gráf kérdése.
Mi a munkamemória? Mennyi fér bele, és hogyan véded a zajtól? Ez a kontextusablak (context window), a kontextusépítés, a reranking és a kompresszió kérdése.
Hogyan választ a rendszer célokat és műveletsorokat? Mikor elég egy lépés, és mikor kell több? Ez a routing, a query rewriting, a fusion és a multihop kérdése.
Hol van a kontroll és a metakogníció? Hogyan ismeri fel a rendszer, hogy nem tud eleget? Mikor korrigál? Ez a Self-RAG, a Corrective RAG és az Active RAG jellegű visszacsatolások kérdése.

Az ACT-R rendszerben a deklaratív memória és a procedurális memória külön modulként működik, a figyelmi rendszer allokálja a kapacitást, és a metacognitive control szabályozza, mikor kell új információt keresni. A SOAR-ban a working memory, a long-term memory és a decision cycle pontosan azokat a funkciókat tölti be, amelyeket a RAG-ban az indexek, a kontextusablak és a routing végez. A párhuzam nem metafora — tervezési keretrendszer.

Miért kognitív párhuzam a RAG architektúra?

Kognitív architektúrát akkor építesz, amikor nem a választ optimalizálod, hanem az előhívás rendjét, a bizonyíték minőségét és a korrekció hurkait. A naiv RAG a baseline emlékezés. A rétegek a figyelem, a problémabontás és az önellenőrzés. Ebből lesz döntéstámogatás — nem narratívagyártás.

Kognitív funkció	RAG megfelelő	Hibamód, ha hiányzik
Hosszú távú memória	Korpusz + indexek + gráf	Rossz forrás, domain-keveredés
Munkamemória	Kontextusablak + reranking	Zaj, irreleváns kontextus
Figyelmi szelekció	Reranking + kompresszió	A modell a zajból következtet
Célválasztás	Routing + query rewriting	Rossz keresési stratégia
Problémabontás	Multihop + iteráció	Összetett kérdés egyetlen lépésben
Metakogníció	Self-RAG + Corrective RAG	Magabiztos tévedés
Végrehajtó kontroll	Governance + audit	Rossz információ rossz helyre kerül

A RAG és a kognitív architektúra kapcsolata tehát nem költői hasonlat, hanem tervezési kontextus. A kontextusablak a munkamemória. A retrieval és reranking a figyelmi rendszer. A többlépéses keresés a problémamegoldó műveletsor. A metakognitív rétegek a hibadetektálás és korrekció mechanizmusai.

És van még egy vállalati, nagyon fontos komponens, ami a kognitív architektúrákban is implicit, csak itt keményen explicit: a governance (szabályozási és ellenőrzési keretrendszer). Jogosultság, adatvédelem, audit és mérhetőség nélkül a rendszer nem „okos” lesz, hanem kiszámíthatatlan — mert ugyanannak a kérdésnek más a helyes válasza szerepkör és idő szerint, és a legdrágább hiba sokszor nem a tévedés, hanem a rossz információ rossz helyre kerülése.

I. Memória és hozzáférés — a korpusz rétegei

Az első réteg a rendszer „emlékezete”. Ezen áll vagy bukik minden további kognitív funkció: ha a memória rossz, a figyelem és a kontroll hiába kiváló. A kognitív tudományban ez a deklaratív memória (declarative memory) — a tények, dokumentumok, szabályok, amelyek a rendszer „tudásbázisát” alkotják.

1. Naiv RAG — a baseline emlékezés

Ez a minimálisan működő megoldás. A kérdésből készül egy „jelentéslenyomat” (embedding), a rendszer visszakeres néhány relevánsan tűnő szövegrészt, majd ezek alapján generál választ. Értéke nem a kifinomultságában van, hanem abban, hogy diagnosztikai eszköz: megmutatja, hogy a korpuszod, a chunkolásod (szövegdarabolásod) és az alap relevancia mennyire életképes.

Vállalati példa. Belső IT helpdesk asszisztens, amely a VPN beállításokról, jelszó reset folyamatokról és alap jogosultságokról a wiki alapján válaszol — és már ettől is csökken a ticket-terhelés.

Hibamód. Ha a naiv RAG nem működik, nem az architektúra a hibás — a korpusz, az indexelés vagy a chunkolás az. Ez az a réteg, ahol a problémát először kell diagnosztizálni.

2. Hibrid RAG — dense + sparse keresés

Itt a rendszer nem csak „jelentés alapján” (dense, szemantikus) keres, hanem „pontos egyezésekre” (sparse, kulcsszavas) is. A kettő kombinációja azért fontos, mert a vállalati tudás tele van azonosítókkal, hibakódokkal, termékkódokkal, nevekkel, verziókkal. Ez a réteg akkor ment meg, amikor a szemantika szép — csak épp rossz dokumentumra vezet.

Vállalati példa. Incidensnél valaki beírja, hogy „invalid_grant 401”, és a rendszer a hibakód miatt a pontos runbookot (üzemeltetési útmutatót) találja meg, nem egy általános „SSO problémák” oldalt.

Hibamód. A tisztán szemantikus keresés a „hasonló jelentésű” dokumentumot hozza — nem a pontosat. A sparse réteg nélkül a rendszer a hibakódot „értelmezi”, ahelyett hogy megkeresné.

3. Multi-index RAG — domainek szétválasztása

Nem egyetlen közös indexben keresel mindent, hanem több tudástérben: külön HR policy, külön legal, külön ops, külön sales. Ez azért lényeges, mert a relevancia legnagyobb része sokszor már ott eldől, hogy „melyik polchoz” nyúlsz — és csak utána az, hogy azon a polcon belül mit találsz.

Vállalati példa. Ugyanaz a szó — „felmondás” — a legal indexben szerződési feltétel, a HR indexben munkaviszony megszüntetés. A rossz index választása a leggyakoribb félreválasz-ok.

Hibamód. Egyetlen „vegyes” index domain-keveredést okoz. A rendszer nem tudja, melyik polcról válaszol — és a felhasználó sem.

II. Figyelem és zajcsökkentés — a kontextus karbantartása

A második réteg a rendszer „figyelmi rendszere”. Nem az a kérdés, mit talál — hanem mit enged be a modell kontextusablakába. A kognitív tudományban ez a szelektív figyelem (selective attention) és a munkamemória-kezelés: a véges kapacitás szándékos allokálása.

4. Query routing — a helyes útvonal kiválasztása

A rendszer először eldönti, hogy dokumentumot kell keresni, adatot kell lekérni, vagy egyáltalán nem kell külső forrás. Ez azért lényeges, mert a „mindig retrieve” sokszor zajt ad, a „soha nem retrieve” pedig hallucinációt.

Vállalati példa. „Hány nap szabadságom maradt?” — nem dokumentum, hanem HR rendszer lekérdezés. „Mi a szabadság kiadásának szabálya?” — policy, tehát RAG.

Hibamód. Routing nélkül a rendszer a szabadság-policyt keresi, amikor egyetlen adatbázis-lekérdezés kell — vagy fordítva, adatot próbál generálni, amikor szabályt kellene keresnie.

5. Query rewriting — a kérdés átfogalmazása

A felhasználó által írt kérdés gyakran túl rövid, túl homályos, vagy rossz szavakat használ. A rewriting átfogalmazza keresésre alkalmasabb formára — kulcskifejezéseket ad hozzá, pontosít. Ez azért lényeges, mert a jó retrieval sokszor nem „okosabb index”, hanem „jobb kérdés”.

Vállalati példa. „Nem megy a belépés” átíródik olyan keresésekre, mint „SSO token expired”, „password reset loop”, „account locked” — és ettől hirtelen releváns lesz a találat.

Hibamód. A felhasználó nyelvén írt kérdés és a dokumentum nyelve között szemantikai rés van. Rewriting nélkül a rendszer nem azt találja, amit a felhasználó keres — hanem azt, ami a kérdés szövegéhez leginkább hasonlít.

6. Multi-query — több nézőpont, több keresés

Nem egy átírt kérdést csinálsz, hanem többet, több nézőpontból. Azért lényeges, mert egyetlen kérdés egyetlen perspektívából keres — és a releváns dokumentum sokszor más szókinccsel, más szögből írja le a választ.

Vállalati példa. „Miért csökken a retention?” (ügyfélmegtartás) külön querykkel megy support ticketekre, NPS kommentekre, release note-okra — és ezek együtt adják ki a képet.

Hibamód. Egyetlen query egyetlen találati listát ad. Ha a válasz több szilóban él, soha nem találod meg egyszerre.

7. RAG fusion — találati listák egyesítése

Ha több keresésből több találati lista jön, a fusion (összefésülés) ezeket egyesíti úgy, hogy ne csak a legerősebb listára támaszkodj. Azért lényeges, mert a „legjobb válaszhoz” gyakran több közepesen jó találat összeolvadása kell.

Vállalati példa. Tenderanyag, belső architektúra dokumentáció és kockázati log külön találati listái összeérnek — és ettől lesz a válasz „teljes”.

Hibamód. Fusion nélkül a rendszer a legerősebb lista top találataira hagyatkozik. A közepes erősségű, de kritikusan fontos találatok kiesnek.

8. Reranking — a relevancia újraértékelése

A retrieval első köre durva szűrés — sok találatot hoz, nem mind releváns. A reranker egy második modell, amely a kérdés és a találatok közötti tényleges relevancia alapján újrarendezi a sorrendet. A top-k találatból tényleges bizonyíték lesz.

Vállalati példa. HR home office policy keresésnél a reranking felülre teszi a kivételeket és a jóváhagyási láncot, nem a bevezető narratívát.

Hibamód. Reranking nélkül a modell a legelső találat alapján generál — ami nem feltétlenül a legrelevánsabb, csak a leginkább hasonló az embedding-térben.

9. Kontextus-kompresszió — a munkamemória védelme

Nem a teljes chunkot adod a modellnek, hanem kivágod belőle a kérdéshez releváns mondatokat. Azért lényeges, mert a kontextusablak szűk figyelmi csatorna, és a zajból a modell nagyon könnyen rossz következtetést rak össze.

Vállalati példa. Auditnál egy kontrollleírásból csak a konkrét lépések kellenek — a többi „körítés” félrevisz, a kompresszió ezt levágja.

Hibamód. Teljes chunkokkal töltött kontextusablak = figyelmi túlterhelés. A modell nem a releváns mondatokra fókuszál, hanem a legutolsó vagy leghangosabb információra — a recency bias (az utolsó benyomásra való hajlam) és a zaj itt okozza a legtöbb rejtett hibát.

III. Célválasztás és problémabontás — az intelligens keresés

A harmadik réteg a rendszer „végrehajtó funkciója” — a kognitív tudományban az executive function (végrehajtó funkció). Nem azt kérdezi, „mit találtam”, hanem azt, hogy „hogyan keressek, hány lépésben, milyen sorrendben”. Az egyszerű kérdésekre egyetlen keresés elég. Az összetett kérdések több lépést, több forrást, több stratégiát igényelnek.

10. Citáció-orientált RAG — a visszaellenőrizhetőség

A rendszer úgy dolgozik, hogy a fontos állítások mögé konkrét forrásrészlet és hivatkozás kerül. Azért lényeges, mert vállalati környezetben a válasz akkor ér valamit, ha visszaellenőrizhető és vitaképes.

Vállalati példa. Legal asszisztens felmondási feltételt mond, és mellé odaírja a szerződés pontját és a releváns bekezdést.

Hibamód. Citáció nélkül a rendszer „kijelent” — és a felhasználó nem tudja, honnan származik az állítás. A bizalom erodálódik, a rendszer elveszíti a hitelességét.

11. Multihop RAG — többlépéses keresés

A kérdést részlépésekre bontja, és több forrásból külön-külön retrieve-ol (keres), majd összerakja a választ. Azért lényeges, mert sok üzleti kérdés valójában több kérdés egy mondatban.

Vállalati példa. „Mely beszállítóknál volt SLA-sértés és mekkora kötbért fizettünk?” — külön keres SLA incidens logban és pénzügyi kifizetésekben, majd összeilleszti a választ.

Hibamód. Egyetlen keresés az összetett kérdésre egyetlen forrásból próbálja kiszolgálni — és vagy az SLA-adatot, vagy a pénzügyi adatot hozza, soha mindkettőt.

12. Iteratív RAG — keresés-írás-korrekció ciklus

A rendszer nem egyszer keres és ír, hanem ciklusban dolgozik: keres, ír, ellenőriz, újra keres, finomít. Azért lényeges, mert a hiányzó részletek sokszor csak válasz közben derülnek ki.

Vállalati példa. Incidens riport készül, a modell írja a narratívát, majd rájön, hogy hiányzik a rollback időpont — visszakeres, és csak utána fejezi be.

Hibamód. Egykörös RAG a válasz elején betöltött kontextusra van bezárva. Ha a válasz írása közben derül ki, hogy valami hiányzik, nincs lehetőség korrigálni.

IV. Keresési stratégiák — a szemantikai tér kitágítása

Ez a réteg arról szól, hogyan tágítható ki a keresés hatóköre, hogyan lehet a korpusz rejtett tudását felszínre hozni. A kognitív analógia: az asszociatív gondolkodás és a kreatív problémamegoldás — amikor a rendszer nem a kézenfekvő úton keres, hanem kerülő utakat próbál.

13. Active RAG — bizonytalanságérzékeny keresés

A generálás közben a bizonytalanság jeleinél újra keres — tipikusan ott, ahol „tippelni” kezdene. Azért lényeges, mert így nem a válasz elején betöltött kontextusra vagy bezárva, hanem ott kérsz bizonyítékot, ahol valóban kockázat keletkezik.

Vállalati példa. Pénzügyi összefoglalóban egy szám vagy dátum körül bizonytalan — ezért visszanyúl a forráshoz, mielőtt kimondja.

Hibamód. A passzív rendszer akkor is magabiztosan állít, amikor nem kellene. Az aktív keresés éppen a „tippelés” pillanatát azonosítja — és ott új bizonyítékot kér.

14. Self-RAG — metakognitív döntések

A rendszer metakognitív döntéseket hoz: kell-e retrieval, elég-e a bizonyíték, jó-e a kontextus — és ehhez igazítja a lépéseit. Azért lényeges, mert ez csökkenti a magabiztos tévedést, és optimalizálja a költséget is. A metakogníció (a gondolkodásról való gondolkodás) a rendszer szintjére emelkedik.

Vállalati példa. „Magyarázd el az EBITDA-t” esetén nem retrieve-ol, mert közismert fogalom. „Mi a cégünknél a költségelszámolás szabálya?” esetén igen, mert belső igazság kell.

Hibamód. Metakogníció nélkül a rendszer mindig keres (drága és zajos) vagy soha nem keres (hallucináció). A Self-RAG az „érdemes-e keresni” kérdést teszi fel magának.

15. Corrective RAG — hibadetektálás és korrekció

Van egy réteg, amely felismeri, ha a retrieval félrement — és ilyenkor korrigál. Újra keres, másik indexet választ, vagy kérdez. Azért lényeges, mert retrieval hiba mindig lesz — a kérdés az, észreveszed-e.

Vállalati példa. Support bot rossz termékverzióhoz hoz cikket, a corrective réteg kiszúrja a verziószám-eltérést, és újra keres a verzió címke alapján.

Hibamód. Korrekció nélkül a rendszer a rossz találatból generál. A felhasználó rossz választ kap, és nem tudja, miért — mert a rendszer sem tudta.

16. HyDE — hipotetikus dokumentum-alapú keresés

A HyDE (Hypothetical Document Embeddings) egy meglepő stratégia: a rendszer előbb legenerál egy „hipotetikus ideális dokumentumot”, és ezzel keres a korpuszban. Azért lényeges, mert gyenge, laikus vagy túl rövid kérdéseknél is adhat egy jobb „iránytűt” a keresésnek.

Vállalati példa. Új belső fogalom, kevés dokumentáció — a HyDE mégis megtalálja a kapcsolódó prezentációkat és meeting-jegyzeteket, mert az idealizált dokumentum szemantikailag közelebb áll a célhoz, mint a felhasználó rövid kérdése.

Hibamód. A hipotetikus dokumentum félrevezetheti a keresést, ha a generált „ideális válasz” maga is hallucinált. Ez a technika tehát nem mindenre jó — de specifikus esetekben drámaian javít.

V. Struktúra és tudásreprezentáció — a memória architektúrája

Az ötödik réteg már nem az egyes keresésekről szól, hanem arról, hogyan szervezed a tudás egészét. A kognitív analógia: a szemantikus hálózat (semantic network) és a fogalmi hierarchia — a tudás nem lapos lista, hanem szervezett rendszer, amelyben az absztrakciós szintek, a kapcsolatok és a nézőpontok egymásra épülnek.

17. Hierarchikus RAG — többszintű absztrakció

A tudás nem egyetlen chunk-szinten él, hanem több absztrakciós szinten: mondat, bekezdés, fejezet, dokumentum-összefoglaló. Azért lényeges, mert hosszú anyagoknál kell a globális kép és a lokális bizonyíték egyszerre.

Vállalati példa. Több száz oldalas tendernél először fejezetszintű összefoglalót hoz, majd lemegy a konkrét követelménypontra.

Hibamód. Egyetlen absztrakciós szinten való keresés vagy túl általános választ ad (ha túl magas szinten keres), vagy elvész a részletekben (ha túl alacsonyan).

18. Összefoglaló fa (summary tree) — a korpusz szerkezeti térképe

A korpuszból „összefoglalók fáját” építed, és a retrieval hol a levelekből (konkrét szövegrészek), hol belső csomópontokból (összefoglalók) hoz tartalmat. Azért lényeges, mert a „mi a lényeg” kérdés gyakran szerkezeti kérdés, nem mondat-kérdés.

Vállalati példa. Vezetői briefhez nem egy bekezdés kell, hanem több dokumentum összeálló „főrendszere” — amit a fa csomópontjai jól adnak.

Hibamód. Összefoglaló fa nélkül a vezetői kérdés („Mi a helyzet a Q3 projektekkel?”) konkrét mondatokat hoz, ahelyett hogy az áttekintő szintű csomópontokból építené a választ.

19. GraphRAG — entitások és kapcsolatok hálója

A tudást entitások és kapcsolatok hálójaként kezeled, és a retrieval részben gráfbejárás (graph traversal), részben fókuszált kivonatolás. Azért lényeges, mert sok vállalati kérdés kapcsolati jellegű: ki kivel, mi minek a következménye — és ezt sima szövegközelségből nehéz stabilan visszahozni.

A tudásgráf (knowledge graph) a vállalati tudásmenedzsment egyik legígéretesebb formája, mert nemcsak a „mi van benne” kérdésre válaszol, hanem a „mi mivel függ össze” kérdésre is.

Vállalati példa. „Miért csúszik a projekt?” esetén meeting-jegyzőkönyv, Jira-függőség, döntési log és kockázati lista együtt adja ki az oksági láncot.

Hibamód. Vektoros keresés önmagában nem talál oksági kapcsolatokat. „A projekt csúszik, mert X személy ki volt vonva Y feladatról, mert Z döntés született” — ezt csak gráf tárja fel.

VI. Kontextus és adaptáció — a rendszer időérzékelése

A hatodik réteg arról szól, hogyan kezeli a rendszer az időt, a felhasználói kontextust és a többféle adatforrást. A kognitív analógia: az epizodikus memória (episodic memory) és a kontextus-függő felidézés — az agy nem minden helyzetben ugyanazt hívja elő, hanem a helyzet, az idő és a személy függvényében szelektál.

20. Adat-augmentált RAG — nem csak dokumentum, adat is

A rendszer nem csak dokumentumokat keres, hanem adatot is lekér: CRM, ERP, ticket-rendszer, adatbázis, kalkuláció. Azért lényeges, mert sok kérdés nem „tudás”, hanem „aktuális állapot”.

Vállalati példa. „Melyik ügyféllel mi a következő lépés?” — nem wiki, hanem CRM pipeline és legutóbbi email-kivonat együtt.

Hibamód. Ha a rendszer csak dokumentumokból válaszol, az „aktuális állapot” típusú kérdésekre elavult vagy irreleváns választ ad.

21. Memória-orientált RAG — rövid és hosszú táv integrációja

Külön kezeled a beszélgetési rövid távú memóriát (session context), a felhasználói profilt (user context) és a hosszú távú dokumentumtudást (corpus) — és szabályozod, melyik mikor számít. Azért lényeges, mert a jó válasz sokszor a stabil tudás és a pillanatnyi helyzet találkozása, és ezt a rendszer könnyen összemossa.

Vállalati példa. Ugyanaz a policy eltérhet ország, üzletág vagy szerepkör szerint — a profil és a session kontextus nélkül rossz szabályt adsz.

Hibamód. A rendszer „elfelejtette”, kivel beszél. A válasz technikailag helyes, de a felhasználó kontextusában értelmetlen.

22. Temporális RAG — az idő mint dimenzió

Időérzékenyen retrieve-olsz: verziókat, érvényességi dátumokat, frissességet, az „akkor” és a „most” szétválasztását kezeled. Azért lényeges, mert a vállalatoknál a leggyakoribb hiba a régi szabály jelenidejű igazságként való visszaadása.

Vállalati példa. „Mi az utazási policy?” kérdésnél a rendszer a legutóbbi, érvényes verziót hozza — nem a tavalyi PDF-et.

Hibamód. Temporalitás nélkül a rendszer nem különbözteti meg a „valamikor érvényes” és a „most érvényes” információt. A felhasználó 2024-es szabály alapján dönt 2025-ben — és nem tudja, hogy elavult információt kapott.

23. Multimodális RAG — szövegen túli bizonyítékok

Nem csak szöveg, hanem kép, diagram, táblázat, PDF-ábra, esetleg hang is lehet a bizonyíték. Azért lényeges, mert rengeteg „valódi információ” vizuális vagy strukturált, és puszta szöveggé alakítva torzul.

Vállalati példa. Gyártásban egy hibafotó alapján visszakeres hasonló eseteket és a hozzájuk tartozó javítási lépéseket.

Hibamód. Ha a rendszer csak szöveget keres, a vizuális bizonyítékok — alkatrész-fotók, folyamatábrák, dashboard-screenshotok — láthatatlanok maradnak.

VII. Governance — a rendszer immunrendszere

Az utolsó réteg a vállalati RAG rendszer „immunrendszere”. Ez nem opcionális kiegészítés — ez a réteg különbözteti meg a hobbiprojektet a production rendszertől. A kognitív architektúrákban ez a végrehajtó kontroll (executive control) és az impulzusgátlás: mit ne mondj ki, kinek ne mutasd meg, mikor állj meg.

24. Biztonsági és governance RAG

Jogosultság, adatvédelem, naplózás, audit, prompt injection (rosszindulatú bemenet) védelem, forrás-hitelesítés — mindez egy integrált rétegben. Azért lényeges, mert vállalatban a legdrágább hiba sokszor nem a tévedés, hanem az információ rossz helyre kerülése.

Vállalati példa. Ugyanarra a kérdésre két ember kétféle választ kap, mert más dokumentumokhoz van joguk — és ezt a rendszer nem utólag „eltakarja”, hanem eleve így retrieve-ol. A jogosultság nem filter a válaszon, hanem szűrő a keresésben.

Hibamód. Governance nélkül:

Pénzügyi adatokat kaphat valaki, akinek nincs hozzáférése
Az audit nem mutatja, ki mit kérdezett és milyen forrásból kapott választ
A prompt injection átjut a védelmen, és a rendszer belső dokumentumokat fed fel
A rendszer „okos” — de kiszámíthatatlan és ellenőrizhetetlen

Ez a réteg az enterprise RAG rendszerben nem a „nice to have” — hanem a license to operate (működési engedély). Nélküle a rendszert nem szabad éles környezetbe engedni.

Hogyan kombináld a 24 mintázatot a gyakorlatban?

A 24 mintázat nem „RAG fajták”, amelyek közül választasz. Ezek kombinálható kognitív képességek, amelyek mindegyike egy tipikus hibamódot kezel: rossz forrás, zaj, több lépés, idő és verzió, magabiztos tévedés, hozzáférési kockázat.

A fejlesztés logikája nem finomhangolás, hanem kognitív funkciók hozzáadása:

Először: Hozzáférés és relevancia — hibrid keresés és több index, hogy a jó tudástérből hozz, és ne keverd a domaineket
Utána: Figyelem és zajcsökkentés — reranking és kompresszió, hogy a top-k jelöltből tényleges bizonyíték legyen
Aztán: Problémabontás és több lépés — routing, rewriting, fusion, multihop, hogy a rendszer ne egyetlen lépésben próbáljon összetett kérdéseket megoldani
Végül: Kontroll és önkorrekció — amikor a rendszer tudja, mikor kell újra keresni, mikor kell megállni, mikor kell citációval lezárni

Az enterprise AI nem ott bukik el, ahol a modellek, hanem ott, ahol a memória és a governance találkozik. A RAG egy külső idegrendszer, amelynek tudnia kell, mit enged be a munkamemóriába, mikor kér új bizonyítékot, és kinek mutathatja meg. A jövő nem a „nagyobb modell”, hanem a jobban tervezett kognitív stack.

Kulcsgondolatok

A RAG nem pipeline — rétegzett kognitív architektúra, amelyben a memória, a figyelem, a végrehajtás és a metakogníció külön funkcióként jelenik meg
A 24 mintázat nem egymást kizáró „típusok”, hanem kombinálható képességek, amelyeket a hibamódok szerint választasz
A kognitív architektúra-párhuzam (ACT-R, SOAR) nem metafora — tervezési keretrendszer, amely évtizedek kutatási tapasztalatát hozza a RAG-tervezésbe
A governance nem opcionális — ez a réteg különbözteti meg a hobbiprojektet a production rendszertől
A modell nem a rendszer — a rétegek a rendszer. A modell csak neonfény. A stack a tudat.

GYIK

Mi a RAG, és miért nem elég önmagában az LLM?

A RAG (Retrieval-Augmented Generation — visszakeresés-kiegészített generálás) azt jelenti, hogy a nyelvi modell válasz előtt releváns dokumentumokat keres egy tudásbázisban. Önmagában az LLM „emlékezetből” válaszol — ami azt jelenti, hogy a tanítási adatokon túl semmit nem tud, és hajlamos a hallucinációra (nem létező tények meggyőző előadására).

Melyik mintázattal kell kezdeni?

Mindig a naiv RAG-gal (1. mintázat). Ez a diagnosztikai eszköz — megmutatja, hogy a korpuszod, a chunkolásod és az alap keresés működik-e. Ha ez nem megy, semmi nem fog menni felette.

Kell mind a 24 mintázat?

Nem. A mintázatokat a hibamódok szerint választod. Ha a rendszered nem küzd temporális hibákkal (régi vs. aktuális szabály), a temporális RAG-ot nem kell beépítened. De ha az audit-szükséglet erős, a governance réteg nem opcionális.

Mi a különbség a Self-RAG és a Corrective RAG között?

A Self-RAG előre dönt: „kell-e egyáltalán keresnem?” — metakognitív szinten értékeli a szükségletet. A Corrective RAG utólag detektálja: „a keresés rossz eredményt hozott” — és újra keres, korrigál. Előbbi proaktív, utóbbi reaktív. Mindkettő kell.

Hogyan kezdjek vállalati RAG-ot építeni?

Naiv RAG → hibrid keresés → routing → reranking → citáció → governance. Ebben a sorrendben. Minden lépésnél mérd a hibaarányt — és a következő réteg az legyen, amelyik a leggyakoribb hibamódot üti ki.

Kapcsolódó gondolatok

Hogyan PROMPTolj (haladóknak) — A prompt nem kérés — valóságkalibrálás. A RAG rétegei is promptokkal működnek.
A rendszerszintű gondolkodás kora — A RAG kognitív stackje rendszergondolkodást igényel — nem komponens-optimalizálást.
A menedzsment mátrix hibái — A szervezet idegrendszere és a RAG idegrendszere ugyanazokkal a hibákkal küzd.

Varga Zoltán - LinkedIn Neural • Knowledge Systems Architect | Enterprise RAG architect PKM • AI Ecosystems | Neural Awareness • Consciousness & Leadership The model is neon. The stack is the mind. Build the layers — or hallucinate.