RAG-metaadatszűrők AI-chatbotokhoz: nyelv, verzió és hozzáférés elkülönítése

Egy AI-chatbot képes szemantikailag rendkívül hasonló szövegrészleteket találni, mégis rossz választ előkészíteni: az angol nyelvű útmutatót a magyar helyett, az előző verzió dokumentációját a legújabb helyett, vagy egy belső megjegyzést egy jogosulatlan vendég számára. A rangsorolás ilyenkor nem feltétlenül rossz. A keresési tartomány volt téves.

A RAG-metaadatszűrők pontosan ezt a problémát oldják meg. A keresés előtt vagy alatt korlátozzák, hogy mely dokumentumok és chunkok jöhetnek egyáltalán számításba kontextusként. A relevanciára vonatkozó kérdésre – „Mi illik a legjobban a tartalomhoz?” – csak ezután válaszolunk. A szűrő először arra válaszol: „Mit szabad és mit kell figyelembe venni ebben a helyzetben?”.

Miért nem megbízható hatókör a hasonlóság önmagában?

A vektoros és hibrid keresés nyelvi vagy szemantikai közelség alapján rendezi a tartalmakat. Egy termék 4-es verziójának kézikönyve különösen hasonlíthat egy 5-ös verzióra vonatkozó kérdésre. Egy másik piacra szánt árlista tartalmazhatja ugyanazokat a termékneveket. Egy belső támogatási dokumentum pedig precízebb választ adhat, mint a nyilvános GYIK, annak ellenére, hogy egy nyilvános chatben soha nem jelenhetne meg.

Ezért a keresőnek (retriever) kétféle feltételt kell elkülönítenie egymástól:

• Kemény határok: például bérlő (tenant), szerepkör, publikálási státusz vagy engedélyezett adatkör. Ismeretlen érték esetén a keresésnek zárva kell maradnia.
• Szakmai kiválasztási kritériumok: például nyelv, termékcsalád, verzió, régió vagy érvényességi időszak. Ezek növelik a pontosságot, és megakadályozzák az ellentmondásos kontextus kialakulását.

A legújabb OWASP LLM-alkalmazási áttekintés a vektoros és embedding kockázatokat kifejezetten az AI-alkalmazások bizalmi határához sorolja. Ez egy fontos perspektíva: a chat előtti hitelesítés-ellenőrzés nem elegendő, ha a rákövetkező hasonlósági keresés mégis túl széles indexen fut.

Egy metaadatséma, amely megállja a helyét a mindennapokban

A jó szűrők nem egy hosszú lekérdezéssel, hanem néhány kanonikus mezővel kezdődnek. Sok weboldali chatbot esetében hat csoport elegendő:

• Nyelv és piac: például locale és market, szabad szöveg helyett rögzített értékekkel.
• Termék és verzió: stabil termék-ID, verziótartomány és tetszőlegesen platform vagy díjcsomag.
• Érvényesség: jóváhagyási státusz, érvényesség kezdete, érvényesség vége és egyértelmű forrásverzió.
• Célcsoport: nyilvános, ügyfél, partner vagy belső csapat – elkülönítve a tényleges szerepkör-ellenőrzéstől.
• Hozzáférési kör: bérlő, csoport vagy principal, kizárólag ellenőrzött szerverkontextusból.
• Eredet: forrás-ID, URL, dokumentumtípus és felelős tartalomterület a nyomon követhetőség érdekében.

A metaadatoknak azon a szinten kell lenniük, ahol a keresés történik. Ha egy dokumentumot chunkokra bontunk, a döntő hatókör-mezőknek megbízhatóan minden egyes chunkra rá kell kerülniük. Ellenkező esetben előfordulhat, hogy egy dokumentum besorolása helyes, miközben az egyes keresési találatok elveszítik ezt a besorolást. Az OpenAI File Search dokumentációja például bemutatja, hogyan használhatók a fájlattribútumok a metaadatszűréshez. Az Amazon Bedrock referencia összehasonlító, lista- és tartományoperátorokat dokumentál ugyanehhez az alapgondolathoz.

Soha ne hagyja, hogy a nyelvi modell engedélyezze a szűrőket

A modell leveheti a kérdésből az olyan utalásokat, mint a nyelv vagy a termékre való hivatkozás. Azonban nem döntheti el, hogy egy személy melyik bérlőhöz tartozik, vagy milyen szerepkörrel rendelkezik. Ezeknek az értékeknek a munkamenetből (session), az identitáskezelő rendszerből és a szerveroldali üzleti szabályokból kell származniuk. A modell által generált szűrőkarakterláncot sem szabad ellenőrzés nélkül továbbítani a keresési szolgáltatásnak.

Egy robusztus folyamat a következőképpen néz ki:

1. A szerver hitelesíti a kérést, és meghatározza az engedélyezett adatkört.
2. A determinisztikus szabályok beállítják a kemény mezőket, mint a bérlő, a szerepkör és a publikálási státusz.
3. A felismerött jellemzőket (pl. nyelv vagy termék) ellenőrzik az engedélyezett értékekkel szemben.
4. A kereső (retriever) csak egy típusos, paraméterezett szűrőstruktúrát hajt végre.
5. Az alkalmazás újra ellenőrzi a visszakapott forrásokat a várt hatókör szempontjából.
6. Hiányzó vagy ellentmondásos kontextus esetén a chatbot visszakérdez, vagy biztonságos tartalékválaszt (fallback) ad.

A Microsoft Security Filters dokumentációja hasznos különbségtételt tesz: a szűrőben lévő principal kezdetben csak egy érték. A hitelesítésnek és az autorizációnak a keresési kifejezésen kívül, megbízhatóan kell megtörténnie. Ügyfélportálok esetében a nyilvános és a hitelesített AI-chatbotok szétválasztásáról szóló cikkünk részletesebben is tárgyalja ezt a határt.

Előszűrés (Pre-filter) vagy utószűrés (Post-filter)?

A szűrő elhelyezkedése befolyásolja a minőséget és a futási időt. Az előszűrő már a vektoros keresés során korlátozza a jelölteket. Az utószűrő először szélesebb körben keres, majd utólag eltávolítja a nem megengedett találatokat. Az Azure vektorszűrőkről szóló dokumentációja szerint az utószűrés szelektív szűrők és kis k érték esetén figyelmen kívül hagyhat megfelelő eredményeket; az előszűrés a felidézést (recall) részesíti előnyben az engedélyezett részállományban, de nagyon szűk szűrők esetén nagyobb számítási kapacitást igényelhet.

A kemény hozzáférési határok esetében az „először keresünk széles körben, majd elrejtjük” nem megfelelő alapminta. Az engedélyezett hatókört a keresési kérésen belül kell kényszeríteni. A tisztán szakmai szűrők esetében a csapat lemérheti az elő- és utószűrési változatokat. Ennek során nemcsak az átlagos válaszidő számít, hanem az is, hogy milyen gyakran hiányzik egy meglévő, engedélyezett találat a kiválasztott sorrend miatt.

A szűrők nem helyettesítik a rangsorolást. Az engedélyezett korpuszon belül a Hibrid keresés és a Reranking továbbra is priorizálhatja a legjobb forrásokat. A sorrend tehát a következő: hatókör meghatározása, jelöltek lekérése, relevancia értékelése, források ellenőrzése, válasz generálása.

Négy tipikus szűrési eset

Nyelv tudatos tartalékútvonallal (fallback)

Egy magyar nyelvű kérdésnél az első lekérdezésnek magyar, jóváhagyott tartalmakat kell választania. Ha nincs találat, az alkalmazás nem keverhet elhallgatva több nyelvet. Egy explicit második útvonal visszaléphet egy jóváhagyott alapértelmezett nyelvre, és ezt a körülményt jelezheti a válaszban. A többnyelvű tudásbázisokhoz készült Locale-QA emellett azt is ellenőrzi, hogy a nyelvi változatok tartalmilag valóban egyenértékűek-e.

Termékverzió és időbeli érvényesség

Egy forrás nem tűnhet naprakésznek pusztán azért, mert legutóbb azt indexelték be. A döntő tényező a szakmai verzió és a jóváhagyás. Jelölje meg a tartalmakat stabil termék-ID-vel, verziótartománnyal, valid_from, valid_until adatokkal és státusszal. Átfedésben lévő jóváhagyások esetén a csővezetéknek (pipeline) konfliktust kell jelentenie ahelyett, hogy mindkét szöveget ugyanabba a promptba helyezné. A crawl-gyakoriság és a forráskarbantartás kölcsönhatását az AI-chatbot tudásbázis frissítéséről szóló útmutató írja le.

Bérlő (tenant) és szerepkör

Közös index esetén minden lekérdezésnek tartalmaznia kell a szerveroldalon meghatározott bérlőt és az érvényes principalokat. A hiányzó ACL-metaadatok „nem lekérdezhetőt” jelentenek, nem pedig „nyilvánosat”. A szerepkör megváltoztatása vagy a jogosultság visszavonása után egy tesztnek kell igazolnia, hogy a régi munkamenetek már nem kapnak korábban engedélyezett chunkokat.

Nyilvános támogatás és belső munkautasítás

Egy belső eszkalációs utasítás szakmailag tökéletesen illeszkedhet egy ügyfélkérdéshez. Ez azonban nem teszi elfogadható forrássá. Válasza külön a publikálási hatókört és a dokumentumtípust; a nem jóváhagyott tartalmakat alapértelmezés szerint jelölje kizártnak. Kétség esetén egy nyilvános botnak inkább egy kapcsolatfelvételi vagy átadási (handoff) útvonalra kell váltania ahelyett, hogy belső részleteket próbálna kitalálni.

A leggyakoribb megvalósítási hibák

• Szabad szöveges takszonómia: Az olyan értékek, mint a hu, HU és hu-HU akaratlanul három csoportot alkotnak.
• Alapértelmezetten nyitott (Default-open): A szerepkör, státusz vagy bérlő nélküli chunkok minden keresési tartományba bejutnak.
• Helytelen boole-i logika: A bérlő és a nyelv közötti OR gyakorlatilag feloldja a kemény határt.
• Dokumentum-chunk eltolódás (drift): Újraindexeléskor az új metaadatok nem továbbítódnak az összes chunkra.
• Csak pozitív tesztelés: A csapat ellenőrzi, hogy egy engedélyezett dokumentum megjelenik-e, de azt nem, hogy egy hasonlóan hangzó, tiltott dokumentum biztosan hiányzik-e.
• Üres találatok modellproblémaként kezelése: A szűk szűrő nem ad találatot, az alkalmazás pedig hagyja, hogy a modell források nélkül válaszoljon tovább.

Szűrő QA: Nem csak a találatokat, a határokat is tesztelni kell

Egy használható tesztkészlet minden várható válaszhoz tartalmaz legalább egy közeli ellen-jelöltet: rossz nyelv, régi verzió, lejárt jóváhagyás, másik bérlő vagy belső célcsoport. Így a teszt megmutatja, hogy a szűrő valóban elválaszt-e, és nem csak véletlenül helyezi a megfelelő találatot a tetejére.

A fontos mutatók közé tartozik a hatókör-sértési arány, a felidézés (recall) az engedélyezett részállományban, az üres lekérdezések aránya, az ismeretlen metaadat-értékek száma, a szűrő latenciája a 95. percentilisnél, valamint a fallbackek és a tisztázó kérdések aránya. Korlátozott tartalmak esetén a tolerált hatókör-sértési aránynak nullának kell lennie. A NIST AI RMF Core azt javasolja, hogy az AI-rendszereket a használat előtt és a működés során rendszeresen teszteljék, és dokumentálják a biztonsági, megbízhatósági és kontextusbéli határokat.

Ennek érdekében ne naplózzon felesleges tartalmakat vagy teljes felhasználói kérdéseket. Leggyakrabban elegendő a szűrőverzió, az absztrakt hatókör, a jelöltek száma, a kiválasztott forrás-ID-k, az elutasítás oka és az utólagos ellenőrzés eredménye. Így a hibakeresés lehetséges marad anélkül, hogy egy második adatszivárgást építene ki a megfigyelhetőségi (observability) rendszerben.

Gyakorlati ellenőrzőlista a bevezetés előtt

1. Dokumentálja a kanonikus metaadatmezőket, adattípusokat, engedélyezett értékeket és a tulajdonosokat.
2. Válassza el a kemény hozzáférési határokat a szakmai kiválasztási mezőktől.
3. A hiányzó, biztonsági szempontból releváns értékeket következetesen kezelje nem engedélyezettként.
4. A szűrőket ellenőrzött szerverkontextusból építse fel, és paraméterezze a bemeneteket.
5. A metaadatokat az Ingestion és Chunking után mintavételezéssel olvassa vissza.
6. Tesztelje a pozitív, negatív, határ- és visszavonási eseteket a valódi indexszel szemben.
7. Mérje meg az elő-/utószűrési viselkedést realisztikus k értékkel és szelektív hatókörökkel.
8. Az üres eredményeket irányítsa tisztázó kérdéshez, biztonságos fallbackhez vagy emberi átadáshoz (Human Handoff).
9. Verziózza a szűrőmódosításokat, és a keresési regressziós tesztekkel együtt vezesse be azokat.

A RAG-metaadatszűrők tehát többek a keresés kényelmi funkciójánál. Összekötő kapcsot jelentenek a tartalommodell, az identitás, a naprakészség és a lekérdezési minőség között. Aki a hatókört először determinisztikusan rögzíti, kisebb, tisztább és ellenőrizhetőbb alapot ad a rangsorolásnak és a nyelvi modellnek a munkához.

Következő lépés: Válasszon ki egy valós támogatási kérdést, és építsen hozzá öt majdnem illeszkedő ellenforrást rossz nyelvből, verzióból és jogosultsági körből. A szűrő csak akkor kerüljön az éles chatfolyamatba, ha egyik sem lépi át az engedélyezett lekérdezési hatókört.

Források

• OpenAI: File Search és Metadata Filtering
• Microsoft: Szűrők a vektoros lekérdezésekben
• Microsoft: Security Filter Pattern
• Amazon Bedrock: RetrievalFilter API
• NIST: AI Risk Management Framework Core
• OWASP: GenAI LLM Top 10 2026