RAG metadatové filtry pro AI chatboty: Oddělení jazyka, verze a přístupu

AI chatbot může najít sémanticky velmi podobné pasáže textu, a přesto připravit špatnou odpověď: anglický návod místo českého, dokumentaci předchozí verze místo aktuální nebo interní poznámky pro hosta bez oprávnění. Rankování nemusí být nutně špatné. Špatný byl prostor pro vyhledávání.

RAG metadatové filtry řeší přesně tento problém. Před vyhledáváním nebo během něj vymezují, které dokumenty a částky (chunky) se vůbec mohou stát kontextem. Relevance následně odpovídá na otázku „Co věcně nejlépe odpovídá?“. Filtr ale nejprve odpovídá na otázku „Co smí a má být v této situaci vzato v úvahu?“.

Proč samotná podobnost není spolehlivým vymezením rozsahu

Vektorové a hybridní vyhledávání řadí obsah podle jazykové nebo sémantické blízkosti. Příručka pro produktovou verzi 4 může být otázce na verzi 5 mimořádně podobná. Ceník pro jiný trh může obsahovat stejné názvy produktů. A interní dokument podpory může poskytnout přesnější odpověď než veřejné FAQ, přestože by se ve veřejném chatu nikdy neměl objevit.

Retriever by proto měl rozlišovat dva typy podmínek:

• Pevné hranice jako tenant, role, stav publikace nebo povolená datová oblast. Při neznámé hodnotě musí vyhledávání zůstat uzavřené.
• Odborná kritéria výběru jako jazyk, produktová rodina, verze, region nebo období platnosti. Zvyšují přesnost a zabraňují rozporuplnému kontextu.

Aktuální přehled OWASP pro LLM aplikaci explicitně řadí rizika vektorů a embeddingů k hranicím důvěryhodnosti AI aplikace. Je to důležitá perspektiva: Kontrola autorizace před zahájením chatu nestačí, pokud následné vyhledávání podle podobnosti probíhá nad příliš širokým indexem.

Metadatové schéma, které funguje v praxi

Dobré filtry nezačínají dlouhým dotazem, ale několika kanonickými poli. Pro mnoho webových chatbotů postačí šest skupin:

• Jazyk a trh: např. locale a market s pevně definovanými hodnotami místo volného textu.
• Produkt a verze: stabilní ID produktu, rozsah verzí a volitelně platforma nebo tarif.
• Platnost: stav schválení, platnost od, platnost do a jednoznačná verze zdroje.
• Cílová skupina: veřejnost, zákazník, partner nebo interní tým – odděleně od samotné kontroly rolí.
• Přístupová oblast: tenant, skupina nebo principal, výhradně z ověřeného kontextu serveru.
• Původ: ID zdroje, URL, typ dokumentu a odpovědná oblast obsahu pro zpětnou sledovatelnost.

Metadata patří do úrovně, na které se vyhledává. Pokud se dokument rozděluje na částky (chunky), musí klíčová pole rozsahu (scope) spolehlivě skončit u každého částku. Jinak může být dokument správně klasifikován, zatímco jednotlivé výsledky vyhledávání tuto klasifikaci ztratí. Dokumentace OpenAI k File Search ukazuje například, jak využít atributy souborů pro metadatové filtry. Referenční příručka Amazon Bedrock dokumentuje porovnávací, seznamové a rozsahové operátory pro stejný základní koncept.

Nikdy nenechávejte autorizaci filtrů na jazykovém modelu

Model smí z otázky odvodit vodítka jako jazyk nebo vazbu na produkt. Nesmí však rozhodovat o tom, ke kterému tenantu osoba patří nebo jakou má roli. Tyto hodnoty musí pocházet relace (session), identitního systému a serverových obchodních pravidel. Ani řetězec filtru vygenerovaný modelem by neměl být neověřený předáván vyhledávací službě.

Robustní postup vypadá takto:

1. Server autentizuje požadavek a určí povolenou datovou oblast.
2. Deterministická pravidla nastaví pevná pole, jako je tenant, role a stav publikace.
3. Rozpoznané vlastnosti jako jazyk nebo produkt jsou validovány vůči povoleným hodnotám.
4. Retriever provede pouze typovanou, parametrizovanou strukturu filtru.
5. Aplikace znovu zkontroluje vrácené zdroje z hlediska očekávaného rozsahu.
6. Při chybějícím nebo rozporuplném kontextu se chatbot doptá nebo použije bezpečný fallback.

Dokumentace Microsoftu k bezpečnostním filtrům uvádí užitečné rozlišení: Principal ve filtru je nejprve pouhá hodnota. Autentizace a autorizace se musí spolehlivě odehrát mimo vyhledávací výraz. Pro zákaznické portály náš článek o oddělení veřejného a autentizovaného AI chatbota tuto hranici dále rozvádí.

Pre-filtering nebo post-filtering?

Umístění filtru ovlivňuje kvalitu a dobu běhu. Pre-filter omezuje kandidáty již během vektorového vyhledávání. Post-filter nejprve vyhledává šířeji a nepřípustné výsledky následně odstraní. Podle dokumentace Azure k vektorovým filtrům může post-filtering u selektivních filtrů a malého k přehlédnout vhodné výsledky; pre-filtering upřednostňuje výtěžnost (recall) v povolené dílčí množině, ale u velmi úzkých filtrů může způsobit vyšší výpočetní nároky.

Pro pevné hranice přístupu není vzor „nejprve hledat široce, pak skrývat“ vhodným základním přístupem. Autorizovaný rozsah by měl být vynucen uvnitř vyhledávacího dotazu. Pro čistě věcné filtry může tým porovnat a změřit varianty pre- a post-filteringu. Zde se nepočítá pouze průměrná doba odezvy, ale také to, jak často kvůli zvolenému pořadí chybí existující povolený výsledek.

Filtry nenahrazují rankování. Uvnitř povoleného korpusu mohou Hybrid Search a reranking i nadále prioritizovat ty nejlepší zdroje. Pořadí je tedy následující: určit rozsah (scope), načíst kandidáty, vyhodnotit relevanci, zkontrolovat zdroje, vygenerovat odpověď.

Čtyři typické případy filtrování

Jazyk s vědomým fallbackem

Pro český dotaz by mělo první načtení vybrat český, schválený obsah. Pokud neexistuje žádný výsledek, aplikace nesmí tichým způsobem smíchat více jazyků. Explicitní druhá cesta může přejít na schválený základní jazyk a tuto skutečnost v odpovědi přiznat. Locale QA pro vícejazyčné báze znalostí navíc zjišťuje, zda jsou varianty z hlediska obsahu skutečně rovnocenné.

Verze produktu a časová platnost

Zdroj by neměl působit jako aktuální jen proto, že byl naposledy prošel crawlerem. Rozhodující je věcná verze a schválení. Označte obsah stabilním ID produktu, rozsahem verze, valid_from, valid_until a stavem. Při překrývajících se schváleních musí pipeline nahlásit konflikt, místo aby vložila oba texty do stejného promptu. Jak spolu souvisí frekvence crawlera a údržba zdrojů, popisuje návod na udržování aktuálnosti báze znalostí AI chatbota.

Tenant a role

Při sdíleném indexu musí každé načtení obsahovat serverově určeného tenanta a platné principály. Chybějící ACL metadata znamenají „nenačitatelné“, nikoli „veřejné“. Po změně role nebo odebrání oprávnění musí test ukázat, že staré relace již nezískají dříve povolené částky (chunky).

Veřejná podpora a interní pracovní instrukce

Interní instrukce k eskalaci může věcně dokonale odpovídat zákaznické otázce. To z ní ale nedělá přípustný zdroj. Oddělte rozsah publikace a typ dokumentu; neschválený obsah standardně označte jako vyloučený. Veřejný bot by měl v případě pochybností přeít na kontakt nebo předání člověku (handoff), místo aby hádal interní detaily.

Nejčastější chyby při implementaci

• Taxonomie s volným textem: Hodnoty jako cs, CS a cs-CZ nechtěně tvoří tři různé skupiny.
• Default-open: Částky (chunky) bez role, stavu nebo tenanta se dostanou do každého vyhledávacího prostoru.
• Špatná boolean logika: OR mezi tenantem a jazykem v praxi ruší pevnou hranici.
• Drift mezi dokumentem a částkem: Při reindexaci se nová metadata nepřenesou na všechny částky (chunky).
• Pouze pozitivní testy: Tým zjišťuje, zda se povolený dokument zobrazí, ale už ne to, zda podobně znějící zakázaný dokument spolehlivě chybí.
• Prázdné výsledky považované za problém modelu: Úzký filtr nic nevrátí a aplikace nechá model odpovídat dále bez zdrojů.

Filter QA: Testování nejen výsledků, ale i hranic

Použitelná testovací sada obsahuje pro každou očekávanou odpověď alespoň jednoho blízkého protikandidáta: špatný jazyk, starou verzi, prošlé schválení, jiného tenanta nebo interní cílovou skupinu. Test tak ukáže, zda filtr skutečně odděluje a neusazuje správný výsledek na horní pozici pouze náhodou.

Důležitými ukazateli jsou míra porušení rozsahu (scope violation rate), výtěžnost (recall) v povolené dílčí množině, podíl prázdných načtení, počet neznámých hodnot metadat, latence filtru na 95. percentilu a podíl fallbacků a doplňujících dotazů. Pro omezený obsah musí být tolerovaná míra porušení rozsahu nulová. Rámec NIST AI RMF Core doporučuje testovat systémy AI před nasazením a pravidelně v provozu a dokumentovat hranice bezpečnosti, spolehlivosti a kontextu.

Nezaznamenávejte k tomu účelu žádný zbytečný obsah ani kompletní otázky uživatelů. Většinou postačí verze filtru, abstraktní rozsah (scope), počet kandidátů, vybrané ID zdrojů, důvod zamítnutí a výsledek post-checku. Hledání chyb tak zůstane možné, aniž by se vytvářel druhý únik dat v systému observability.

Praktický kontrolní seznam před spuštěním

1. Dokumentovat kanonická metadatová pole, datové typy, povolené hodnoty a vlastníky.
2. Oddělit pevné hranice přístupu od věcných polí výběru.
3. Chybějící bezpečnostně relevantní hodnoty důsledně zpracovávat jako nepovolené.
4. Sestavovat filtry z ověřeného kontextu serveru a parametrizovat vstupy.
5. Po ingestování a chunkingu náhodně kontrolovat zpětné čtení metadat.
6. Testovat pozitivní, negativní, hraniční a odvolací případy proti reálnému indexu.
7. Měřit chování pre-/post-filtering s realistickým k a selektivními rozsahy (scopes).
8. Prázdné výsledky směrovat do doplňujícího dotazu, bezpečného fallbacku nebo předání člověku.
9. Verzovat změny filtrů a nasazovat je společně s regresními testy vyhledávání (retrievalu).

RAG metadatové filtry jsou tak více než jen komfortní funkcí vyhledávání. Jsou propojením mezi modelováním obsahu, identitou, aktuálností a kvalitou vyhledávání. Kdo nejprve deterministicky stanoví rozsah (scope), dává rankování a jazykovému modelu menší, čistší a ověřitelný pracovní základ.

Další krok: Vyberte reálnou otázku podpory a vytvořte k ní pět téměř odpovídajících protizdrojů ze špatného jazyka, verze a oprávnění. Teprve když žádný z nich nepřekročí povolený rozsah vyhledávání (retrieval scope), měl by filtr přejít do produkčního toku chatu.

Zdroje

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