Filtre metadát RAG pre AI chatbotov: Oddelenie jazyka, verzie a prístupu

AI chatbot môže nájsť sémanticky veľmi podobné pasáže textu, no napriek tomu pripraviť nesprávnu odpoveď: anglický návod namiesto slovenského, dokumentáciu k predchádzajúcej verzii namiesto aktuálnej alebo interné pokyny pre hosta bez oprávnenia. Ranking v takom prípade nemusí byť zlý. Zlý bol vyhľadávací priestor.

Filtre metadát v RAG riešia presne tento problém. Pred vyhľadávaním alebo počas neho obmedzujú, ktoré dokumenty a fragmenty (chunks) uopšte prichádzajú do úvahy ako kontext. Relevancia potom odpovedá na otázku „Čo sa najlepšie hodí po obsahovej stránke?“. Filter však najprv odpovedá na otázku „Čo sa v tejto situácii smie a má zohľadniť?“.

Prečo samotná podobnosť nie je spoľahlivým rozsahom

Vektorové a hybridné vyhľadávanie zoradzuje obsah podľa jazykovej alebo sémantickej blízkosti. Príručka pre verziu produktu 4 môže byť mimoriadne podobná otázke k verzii 5. Cenník pre iný trh môže obsahovať rovnaké názvy produktov. A interný dokument podpory môže poskytnúť presnejšiu odpoveď než verejne dostupné FAQ, hoci by sa vo verejnom chate nikdy nemal objaviť.

Retriever by preto mal rozlišovať dva typy podmienok:

• Pevné hranice (hard boundaries) ako tenant, rola, stav publikovania alebo povolený dátový rozsah. Pri neznámej hodnote musí vyhľadávanie zostať zatvorené.
• Odborné kritériá výberu ako jazyk, produktová rodina, verzia, región alebo obdobie platnosti. Zvyšujú presnosť a zabraňujú rozporuplnému kontextu.
Subor

Aktuálny prehľad OWASP pre aplikácie LLM výslovne priraďuje riziká vektorov a embeddingov do hranice dôveryhodnosti AI aplikácie. Je to dôležitá perspektíva: Kontrola autorizácie pred chatom nestačí, ak následné vyhľadávanie podľa podobnosti napriek tomu prebieha nad príliš širokým indexom.

Schéma metadát, ktorá funguje v každodennej praxi

Dobré filtre nezačínajú dlhým dopytom, ale niekoľkými kanonickými poľami. Pre mnohých webových chatbotov postačuje šesť skupín:

• Jazyk a trh: napríklad locale a market s pevne definovanými hodnotami namiesto voľného textu.
• Produkt a verzia: stabilné ID produktu, rozsah verzií a voliteľne platforma alebo tarif.
• Platnosť: stav schválenia, platnosť od, platnosť do a jednoznačná verzia zdroja.
• Cieľová skupina: verejnosť, zákazník, partner alebo interný tím – oddelene od samotnej kontroly rolí.
• Oblasť prístupu: tenant, skupina alebo principal, výhradne z overeného serverového kontextu.
• Pôvod: ID zdroja, URL, typ dokumentu a zodpovedná oblasť obsahu pre spätnú sledovateľnosť.

Metadáta patria na úroveň, na ktorej sa vyhľadáva. Ak sa dokument rozdelí na fragmenty (chunks), kľúčové polia rozsahu sa musia spoľahlivo preniesť na každý fragment. V opačnom prípade môže byť dokument správne klasifikovaný, zatiaľ čo jednotlivé výsledky vyhľadávania toto zaradenie stratia. Dokumentácia OpenAI k File Search napríklad ukazuje, ako sa atribúty súborov používajú na filtrovanie metadát. Referencia pre Amazon Bedrock dokumentuje porovnávacie, zoznamové a rozsahové operátory pre rovnakú základnú myšlienku.

Filtre nikdy nenechajte autorizovať jazykovým modelom

Model môže z otázky odvodiť indície ako jazyk alebo súvislosť s produktom. Nesmie však rozhodovať o tom, ku ktorému tenantovi osoba patrí alebo akú má rolu. Tieto hodnoty musia pochádzať z relácie (session), identitného systému a serverových obchodných pravidiel. Ani reťazec filtra vygenerovaný modelom by sa nemal nekontrolovane odovzdávať vyhľadávacej službe.

Robustný postup vyzerá takto:

1. Server autentifikuje požiadavku a určí povolený dátový rozsah.
2. Deterministické pravidlá nastavia pevné polia ako tenant, rola a stav publikovania.
3. Rozpoznané vlastnosti ako jazyk alebo produkt sa validujú voči povoleným hodnotám.
4. Retriever vykoná iba typovanú, parametrizovanú štruktúru filtra.
5. Aplikácia znova skontroluje vrátené zdroje z hľadiska očakávaného rozsahu.
6. Pri chýbajúcom alebo rozporuplnom kontexte sa chatbot dopytuje alebo použije bezpečný fallback.

Dokumentácia Microsoftu k bezpečnostným filtrom uvádza užitočné rozlíšenie: Principal vo filtri je najprv len hodnota. Autentifikácia a autorizácia musia prebiehať spoľahlivo mimo výrazu vyhľadávania. Pre zákaznícke portály náš článok o oddelení verejného a autentifikovaného AI chatbota túto hranicu ďalej rozvíja.

Pre-filtering alebo post-filtering?

Umiestnenie filtra ovplyvňuje kvalitu aj čas odozvy. Pre-filtering obmedzuje kandidátov už počas vektorového vyhľadávania. Post-filtering najprv vyhľadáva širšie a následne odstraňuje nepovolené výsledky. Podľa dokumentácie Azure k vektorovým filtrom môže post-filtering pri selektívnych filtroch a malom k prehliadnuť vhodné výsledky; pre-filtering uprednostňuje návratnosť (recall) v povolenej časti dát, no pri veľmi úzkych filtroch môže vyžadovať vyšší výpočtový výkon.

Pre pevné prístupové hranice nie je vzor „najprv hľadať široko, potom skrývať“ vhodným základným prístupom. Autorizovaný rozsah by mal byť vynútený priamo vo vyhľadávacom dopyte. Pri čisto odborných filtroch môže tím merať varianty pre- a post-filteringu. Záleží pritom nie len na priemernej dobe odozvy, ale aj na tom, ako často existujúci, povolený výsledok kvôli zvolenému poradiu chýba.

Filtre nenahrádzajú ranking. V rámci povoleného korpusu môžu Hybrid Search a Reranking naďalej uprednostňovať tie najlepšie zdroje. Poradie je teda nasledovné: určiť rozsah, získať kandidátov, vyhodnotiť relevanciu, skontrolovať zdroje, vygenerovať odpoveď.

Štyri typické prípady filtrovania

Jazyk s premysleným fallbackom

Pre slovenskú otázku by sa pri prvom načítaní mali vybrať slovenské, schválené materiály. Ak neexistuje žiadny výsledok, aplikácia nesmie ticho miešať viaceré jazyky. Explicitná druhá cesta sa môže vrátiť k schválenému základnému jazyku a túto skutočnosť v odpovedi priznať. Locale-QA pre viacjazyčné bázy znalostí navyše skontroluje, či sú varianty po obsahovej stránke naozaj rovnocenné.

Verzia produktu a časová platnosť

Zdroj by nemal pôsobiť ako aktuálny len preto, že bol naposledy prejdený crawlerom. Rozhodujúca je odborná verzia a schválenie. Označte obsah stabilným ID produktu, rozsahom verzií, valid_from, valid_until a stavom. Pri prekrývajúcich sa schváleniach musí pipeline nahlásiť konflikt namiesto toho, aby vložila oba texty do rovnakého promptu. Ako spolu súvisia kadencia crawlera a údržba zdrojov, popisuje sprievodca pre udržiavanie aktuálnosti bázy znalostí AI chatbota.

Tenant a rola

Pri spoločnom indexe musí každé vyhľadávanie obsahovať tenanta určeného na strane servera a platné principály. Chýbajúce ACL metadáta znamenajú „nevyhľadateľné“, nie „verejné“. Po zmene role alebo odobratí oprávnenia musí test ukázať, že staré relácie už nedostanú žiadne skôr povolené fragmenty.

Verejná podpora a interné pracovné pokyny

Interný eskalačný pokyn môže odborne dokonale sedieť na zákaznícku otázku. To z neho však nerobí povolený zdroj. Oddeľte rozsah publikovania a typ dokumentu; neschválený obsah štandardne označte ako vylúčený. Verejný bot by sa mal v prípade pochybností prepnúť na kontaktovanie alebo odovzdanie človeku (handoff) namiesto hádania interných detailov.

Najčastejšie chyby pri implementácii

• Taxonómia s voľným textom: Hodnoty ako sk, SK a sk-SK neúmyselne vytvoria tri rôzne skupiny.
• Default-open (predvolene otvorené): Fragmenty bez role, stavu alebo tenanta sa dostanú do každého vyhľadávacieho priestoru.
• Nesprávna boolovská logika: Použitie OR medzi tenantom a jazykom prakticky zruší pevnú hranicu.
• Odchýlka dokumentu a fragmentov (Document-Chunk Drift): Pri opätovnom indexovaní sa nové metadáta neprenesú na všetky fragmenty.
• Iba pozitívne testy: Tím testuje, či sa zobrazí povolený dokument, ale už netestuje, či bezpečne chýba podobne znejúci zakázaný dokument.
• Prázdne výsledky považované za problém modelu: Úzky filter nevráti nič a aplikácia nechá model odpovedať ďalej bez zdrojov.

QA filtrov: Testujte nielen výsledky, ale aj hranice

Použiteľná testovacia sada obsahuje pre každú očakávanú odpoveď aspoň jedného blízkeho protikandidáta: nesprávny jazyk, stará verzia, exspirované schválenie, iný tenant alebo interná cieľová skupina. Test tak ukáže, či filter skutočne oddeľuje a nie len náhodou umiestnil správny výsledok na prvé miesto.

Dôležité metriky sú miera porušenia rozsahu (scope violation rate), recall v povolenej časti, podiel prázdnych vyhľadávaní, počet neznámych hodnôt metadát, latencia filtrovania na 95. percentile a podiel fallbackov či dopytov na spresnenie. Pre obmedzený obsah musí byť tolerovaná miera porušenia rozsahu nulová. Framework NIST AI RMF Core odporúča testovať systémy AI pred nasadením aj pravidelne v prevádzke a dokumentovať bezpečnostné, spoľahlivostné a kontextové hranice.

Ešte upozornenie: Neprotokolujte zbytočný obsah ani úplné otázky používateľov. Väčšinou postačuje verzia filtra, abstraktný rozsah, počet kandidátov, vybrané ID zdrojov, dôvod zamietnutia a výsledok následnej kontroly (post-check). Takto zostane diagnostika chýb možná bez toho, aby ste si vytvorili druhý únik dát v systéme observability.

Praktický kontrolný zoznam pred spustením

1. Zdokuementujte kanonické polia metadát, dátové typy, povolené hodnoty a vlastnákov.
2. Oddeľte pevné prístupové hranice od odborných výberových polí.
3. Chýbajúce bezpečnostné hodnoty dôsledne spracovávajte ako nepovolené.
4. Sostavujte filtre z overeného serverového kontextu a parametrizujte vstupy.
5. Po spracovaní (ingestion) a fragmentácii (chunking) náhodne skontrolujte metadáta spätným čítaním.
6. Testujte pozitívne, negatívne, hraničné a revokačné prípady voči reálnemu indexu.
7. Merať správanie pre-/post-filtering s realistickým k a selektívnymi rozsahmi.
8. Prázdne výsledky smerujte na dopyt o spresnenie, bezpečný fallback alebo odovzdanie človeku.
9. Verziujte zmeny filtrov a nasadzujte ich spolu s regresnými testami vyhľadávania.

Filtre metadát v RAG sú teda viac než len komfortnou funkciou vyhľadávania. Sú prepojením medzi obsahovým modelom, identitou, aktuálnosťou a kvalitou vyhľadávania. Kto najprv deterministicky určí rozsah, dáva rankingu a jazykovému modelu menší, čistejší a overiteľný základ pre prácu.

Ďalší krok: Vyberte reálnu otázku podpory a vytvorte k nej päť takmer hodiacich sa protizdrojov z nesprávneho jazyka, verzie a oprávnenia. Až keď ani jeden z nich neprekročí povolený rozsah vyhľadávania, mal by filter prejsť do produkčného chatu.

Zdroje

• OpenAI: File Search a Metadata Filtering
• Microsoft: Filtre vo vektorových dopytoch
• Microsoft: Security Filter Pattern
• Amazon Bedrock: RetrievalFilter API
• NIST: AI Risk Management Framework Core
• OWASP: GenAI LLM Top 10 2026