Filtrowanie metadanych RAG w chatbotach AI: rozdzielanie języka, wersji i dostępu

Chatbot AI może znaleźć fragmenty tekstu bardzo podobne semantycznie, a mimo to przygotować błędną odpowiedź: angielską instrukcję zamiast polskiej, dokumentację poprzedniej wersji zamiast aktualnej lub wewnętrzne wskazówki dla gościa bez odpowiednich uprawnień. Ranking wcale nie musi być w takim przypadku zły. Po prostu obszar wyszukiwania był nieprawidłowy.

Filtry metadanych RAG rozwiązują dokładnie ten problem. Ograniczają one — przed wyszukiwaniem lub w jego trakcie — które dokumenty i fragmenty (chunki) w ogóle mogą trafić do kontekstu. Istotność odpowiada następnie na pytanie „Co najlepiej pasuje pod względem treści?”. Jednak filtr najpierw odpowiada na pytanie „Co wolno i należy wziąć pod uwagę w danej sytuacji?”.

Dlaczego samo podobieństwo nie jest niezawodnym zakresem

Wyszukiwanie wektorowe i hybrydowe porządkuje treści według bliskości językowej lub semantycznej. Podręcznik dla wersji produktu 4 może być bardzo podobny do pytania o wersję 5. Cennik dla innego rynku może zawierać te same nazwy produktów. A wewnętrzny dokument pomocy technicznej może dać dokładniejszą odpowiedź niż publiczne FAQ, mimo że nigdy nie powinien pojawić się w publicznym czacie.

Dlatego retriever powinien rozróżniać dwa rodzaje warunków:

• Sztywne granice, takie jak najemca (tenant), rola, status publikacji lub dozwolony obszar danych. W przypadku nieznanej wartości wyszukiwanie musi pozostać zamknięte.
• Merytoryczne kryteria wyboru, takie jak język, rodzina produktów, wersja, region lub okres ważności. Zwiększają one precyzję i zapobiegają sprzecznym kontekstom.

Aktualny przegląd OWASP dla aplikacji LLM jednoznacznie przypisuje ryzyka związane z wektorami i embeddingami do granicy zaufania (trust boundary) aplikacji AI. To ważna perspektywa: weryfikacja uprawnień (auth) przed czatem nie wystarczy, jeśli późniejsze wyszukiwanie według podobieństwa i tak korzysta z zbyt szerokiego indeksu.

Schemat metadanych, który sprawdza się na co dzień

Dobre filtry nie zaczynają się od długiego zapytania, lecz od kilku kanonicznych pól. W przypadku wielu chatbotów na stronach internetowych wystarczy sześć grup:

• Język i rynek: np. locale i market, ze ściśle zdefiniowanymi wartościami zamiast wolnego tekstu.
• Produkt i wersja: stabilny identyfikator produktu, zakres wersji oraz opcjonalnie platforma lub plan.
• Ważność: status zatwierdzenia, ważność od, ważność do oraz jednoznaczna wersja źródłowa.
• Grupa docelowa: publiczna, klient, partner lub zespół wewnętrzny — oddzielnie od właściwej weryfikacji ról.
• Obszar dostępu: najemca (tenant), grupa lub podmiot (principal), wyłącznie z zweryfikowanego kontekstu serwera.
• Pochodzenie: ID źródła, URL, typ dokumentu i odpowiedzialny obszar treści w celu zapewnienia klarowności.

Metadane należą do poziomu, na którym odbywa się wyszukiwanie. Jeśli dokument jest dzielony na chunki, kluczowe pola zakresu muszą niezawodnie trafić do każdego z nich. W przeciwnym razie dokument może być poprawnie sklasyfikowany, podczas gdy poszczególne wyniki wyszukiwania stracą tę klasyfikację. Dokumentacja OpenAI dotycząca File Search pokazuje na przykład, jak wykorzystywać atrybuty plików do filtrowania metadanych. Dokumentacja Amazon Bedrock opisuje operatory porównania, list i zakresów dla tej samej koncepcji.

Nigdy nie pozwalaj modelowi językowemu na autoryzację filtrów

Model może na podstawie pytania wnioskować o języku czy nawiązaniu do produktu. Nie może jednak decydować, do jakiego najemcy należy dana osoba ani jakie ma role. Wartości te muszą pochodzić z sesji, systemu tożsamości oraz reguł biznesowych po stronie serwera. Wygenerowany przez model ciąg znaków filtra również nie powinien być przekazywany do usługi wyszukiwania bez weryfikacji.

Solidny proces wygląda następująco:

1. Serwer uwierzytelnia zapytanie i określa dozwolony obszar danych.
2. Deterministyczne reguły ustawiają sztywne pola, takie jak najemca, rola i status publikacji.
3. Wykryte cechy, takie jak język lub produkt, są walidowane pod kątem dozwolonych wartości.
4. Retriever wykonuje wyłącznie typowaną, sparametryzowaną strukturę filtra.
5. Aplikacja ponownie sprawdza zwrócone źródła pod kątem oczekiwanego zakresu.
6. W przypadku braku lub sprzeczności kontekstu chatbot dopytuje użytkownika lub generuje bezpieczną odpowiedź zapasową (fallback).

Dokumentacja Microsoft dotycząca Security Filters wprowadza pomocne rozróżnienie: podmiot (principal) w filtrze to na początku tylko wartość. Uwierzytelnianie i autoryzacja muszą odbywać się niezawodnie poza wyrażeniem wyszukiwania. W przypadku portali klienckich nasz artykuł o rozdzielaniu publicznego i uwierzytelnionego chatbota AI pogłębia temat tej granicy.

Pre-filtering czy post-filtering?

Pozycja filtra wpływa na jakość i czas wykonania. Pre-filtering ogranicza kandydatów już podczas wyszukiwania wektorowego. Post-filtering wyszukuje najpierw szerzej, a następnie usuwa niedozwolone wyniki. Według dokumentacji Azure dotyczącej filtrów wektorowych, post-filtering przy selektywnych filtrach i małym k może przeoczyć pasujące wyniki; pre-filtering przekłada się na lepszy poziom przywołania (recall) w dozwolonym zbiorze, ale przy bardzo wąskich filtrach może wymagać większych nakładów obliczeniowych.

W przypadku sztywnych granic dostępu wzorzec „szukaj szeroko, potem ukrywaj” nie jest odpowiedni. Uprawniony zakres powinien być wymuszony w ramach samego zapytania wyszukiwania. Przy filtrach czysto merytorycznych zespół może zmierzyć warianty pre- i post-filtering. Liczy się przy tym nie tylko średni czas odpowiedzi, ale także to, jak często z powodu wybranej kolejności brakuje istniejącego, dozwolonego trafienia.

Filtry nie zastępują rankingu. W obrębie dozwolonego korpusu Hybrid Search i Reranking nadal mogą nadawać priorytet najlepszym źródłom. Kolejność brzmi zatem: ustal zakres, pobierz kandydatów, oceń istotność, zweryfikuj źródła, wygeneruj odpowiedź.

Cztery typowe przypadki filtrowania

Język z przemyślanym mechanizmem zapasowym

W przypadku pytania w języku polskim pierwsze wyszukiwanie powinno wybrać zatwierdzone treści w tym języku. Jeśli brak wyników, aplikacja nie powinna po cichu mieszać kilku języków. Jawna druga ścieżka może skorzystać z zatwierdzonego języka bazowego i zaznaczyć ten fakt w odpowiedzi. Locale-QA dla wielojęzycznych baz wiedzy dodatkowo sprawdza, czy warianty są naprawdę równoważne pod względem treści.

Wersja produktu i ważność czasowa

Źródło nie powinno wydawać się aktualne tylko dlatego, że zostało niedawno zindeksowane. Decydujące są merytoryczna wersja i zatwierdzenie. Oznaczaj treści za pomocą stabilnego ID produktu, zakresu wersji, valid_from, valid_until oraz statusu. W przypadku nakładających się uprawnień proces (pipeline) musi zgłosić konflikt, zamiast umieszczać oba teksty w tym samym prompcie. O tym, jak współpracują ze sobą częstotliwość indeksowania i utrzymanie źródeł, przeczytasz w przewodniku po utrzymaniu aktualności bazy wiedzy chatbota AI.

Najemca i rola

W przypadku wspólnego indeksu każde zapytanie musi zawierać najemcę i prawidłowe podmioty (principals) określone po stronie serwera. Brak metadanych ACL oznacza „brak możliwości pobrania”, a nie „treść publiczną”. Po zmianie roli lub cofnięciu uprawnień test musi wykazać, że stare sesje nie otrzymują już wcześniej dozwolonych fragmentów.

Publiczny support a wewnętrzna instrukcja robocza

Wewnętrzna instrukcja eskalacji może idealnie pasować do pytania klienta. Nie czyni jej to jednak dozwolonym źródłem. Oddziel zakres publikacji od typu dokumentu; domyślnie oznaczaj niezatwierdzone treści jako wykluczone. Publiczny bot w razie wątpliwości powinien przełączyć się na ścieżkę kontaktu lub przekazania do człowieka (handoff), zamiast zgadywać wewnętrzne szczegóły.

Najczęstsze błędy we wdrożeniu

• Taksonomia w postaci wolnego tekstu: wartości takie jak pl, PL i pl-PL tworzą niepotrzebnie trzy osobne grupy.
• Domyślnie otwarty dostęp (default-open): chunki bez roli, statusu lub najemcy trafiają do każdej przestrzeni wyszukiwania.
• Błędna logika boolowska: użycie OR między najemcą a językiem w praktyce znosi sztywną granicę dostępu.
• Rozbieżność między dokumentem a chunkami (drift): podczas ponownego indeksowania nowe metadane nie są przekazywane do wszystkich chunków.
• Tylko pozytywne testy: zespół sprawdza, czy dozwolony dokument się pojawia, ale nie weryfikuje, czy podobnie brzmiący, niedozwolony dokument jest skutecznie blokowany.
• Brak wyników traktowany jako problem modelu: zbyt wąski filtr nie zwraca niczego, a aplikacja pozwala modelowi odpowiadać dalej bez źródeł.

Testowanie filtrów (QA): Sprawdzaj granice, nie tylko trafienia

Użyteczny zestaw testowy zawiera dla każdej oczekiwanej odpowiedzi przynajmniej jednego bliskiego kontrkandydata: złe narzecze/język, stara wersja, wygasłe zatwierdzenie, inny najemca lub wewnętrzna grupa docelowa. Dzięki temu test pokazuje, czy filtr naprawdę separuje dane, czy tylko przypadkowo umieszcza właściwy wynik na górze.

Kluczowe wskaźniki to: wskaźnik naruszeń zakresu (scope violation rate), poziom przywołania w dozwolonym zbiorze, udział pustych wyszukiwań, liczba nieznanych wartości metadanych, opóźnienie filtrowania na 95. percentylu oraz udział odpowiedzi zapasowych i pytań doprecyzowujących. W przypadku treści chronionych tolerowany wskaźnik naruszeń zakresu musi wynosić zero. Standard NIST AI RMF Core zaleca testowanie systemów AI przed wdrożeniem i regularnie w trakcie eksploatacji oraz dokumentowanie granic bezpieczeństwa, niezawodności i kontekstu.

Nie rejestruj w logach zbędnych treści ani pełnych pytań użytkowników. Zazwyczaj wystarczą: wersja filtra, abstrakcyjny zakres, liczba kandydatów, wybrane ID źródeł, powód odrzucenia i wynik weryfikacji post-check. Pozwala to na diagnozowanie błędów bez tworzenia kolejnego wycieku danych w systemie monitorowania (observability).

Praktyczna lista kontrolna przed wdrożeniem

1. Zdokumentuj kanoniczne pola metadanych, typy danych, dozwolone wartości i właścicieli.
2. Oddziel sztywne granice dostępu od merytorycznych pól wyboru.
3. Brakujące wartości istotne dla bezpieczeństwa traktuj bezwzględnie jako niedozwolone.
4. Buduj filtry ze zweryfikowanego kontekstu serwera i parametryzuj dane wejściowe.
5. Sprawdzaj wyrywkowo metadane po przetworzeniu (ingestion) i podziale na chunki.
6. Testuj przypadki pozytywne, negatywne, graniczne oraz cofnięcia uprawnień na prawdziwym indeksie.
7. Mierz zachowanie pre- i post-filtering z realistycznym k oraz selektywnymi zakresami.
8. Kieruj puste wyniki do pytania doprecyzowującego, bezpiecznego fallbacku lub przekazania do człowieka.
9. Wersjonuj zmiany filtrów i wdrażaj je razem z testami regresyjnymi wyszukiwania.

Filtry metadanych RAG to coś więcej niż udogodnienie w wyszukiwarce. Stanowią pomost między modelem treści, tożsamością, aktualnością a jakością wyszukiwania. Ten, kto najpierw deterministycznie ustala zakres, daje rankingowi i modelowi językowemu mniejszą, czystszą i łatwiejszą do weryfikacji podstawę do pracy.

Kolejny krok: Wybierz jedno realne pytanie z działu wsparcia i przygotuj pięć prawie pasujących źródeł z nieprawidłowego języka, wersji lub poziomu uprawnień. Dopiero gdy żadne z nich nie przekroczy dozwolonego zakresu wyszukiwania, filtr powinien trafić do produkcyjnego czatu.

Źródła

• OpenAI: File Search i Metadata Filtering
• Microsoft: Filtry w zapytaniach wektorowych
• Microsoft: Security Filter Pattern
• Amazon Bedrock: API RetrievalFilter
• NIST: AI Risk Management Framework Core
• OWASP: GenAI LLM Top 10 2026