Zapobieganie zatruciu danych w RAG: proweniencja źródeł, kwarantanna i testy reindeksacji

Chatbot na stronie internetowej może dostarczyć uprzejmą, przekonującą językowo i poprawnie wygenerowaną technicznie odpowiedź – a mimo to działać na skażonej bazie wiedzy. W przypadku zatrucia danych RAG (data poisoning) manipulacja nie dotyczy przede wszystkim sformułowania pojedynczego zapytania. Zamiast tego błędne, zmanipulowane lub niewystarczająco zweryfikowane treści trafiają do trwałego łańcucha danych: źródło, parser, fragment (chunk), metadane, embedding i wreszcie produkcyjny indeks wyszukiwania. Błąd utrzymuje się w ten sposób przez wiele sesji i może wpływać również na zwykłe pytania.

Skuteczna ochrona zaczyna się zatem na długo przed promptem. Zespoły muszą być w stanie odpowiedzieć na pytania dotyczące każdego elementu wiedzy: skąd pochodzi, kto jest za niego odpowiedzialny, jaka wersja została przetworzona, jakie transformacje miały miejsce i na podstawie jakiej weryfikacji został zatwierdzony do wyszukiwania? Proweniencja źródeł dostarcza tego śladu. Technicznie odseparowana kwarantanna może zapobiec natychmiastowemu udostępnieniu nieprzetestowanych zmian. Ukierunkowane testy reindeksacji sprawdzają następnie, czy oczyszczone treści rzeczywiście zastąpiły stare fragmenty.

Czym jest zatrucie danych w RAG – a czym nie jest

Klasyfikacja OWASP LLM04:2025 dotycząca Data and Model Poisoning opisuje manipulacje danymi treningowymi, fine-tuningowymi lub embeddingowymi jako zagrożenie dla integralności. Dla chatbota na stronie internetowej szczególnie namacalny jest ten ostatni wariant: dokument jest pobierany i dzielony na fragmenty; te fragmenty są przekształcane w embeddingi i zapisywane jako wektory w indeksie wyszukiwania. Jeśli ten dokument zostanie celowo lub przypadkowo zmanipulowany, może pojawić się przy odpowiednich pytaniach jako pozornie istotna podstawa.

Zagrożenia te należy rozróżniać, choć mogą się one nakładać: Prompt Injection próbuje w czasie rzeczywistym przemycić instrukcje lub dane w taki sposób, aby zmienić przewidziane zachowanie systemu; pośredni Prompt Injection (indirect prompt injection) może przy tym przedostać się do kontekstu również poprzez pobrane dokumenty. Z kolei zatrucie danych zmienia długotrwały zasób wiedzy lub jego pochodne. Uprawnienia dostępu rozwiązują jeszcze inny problem: określają, która osoba może zobaczyć dany dokument. Proweniencja i zatwierdzenie decydują o tym, czy ten dokument powinien trafić do indeksu jako wiarygodne źródło wiedzy. W solidnej architekturze wszystkie trzy ryzyka wymagają własnych mechanizmów kontroli i uzgodnionych punktów przejścia.

Powierzchnia ataku obejmuje cały łańcuch danych

Indeks RAG rzadko powstaje z pojedynczej, ręcznie zweryfikowanej kolekcji. Crawlery czytają strony www, konektory synchronizują foldery w chmurze, użytkownicy przesyłają pliki, a interfejsy importują dane o produktach. Do tego dochodzą parsery, OCR, czyszczenie tekstu, podział na fragmenty (chunking) i wzbogacanie metadanych. Każdy etap może przejąć błędne treści lub wyrwać pierwotnie poprawną wypowiedź z kontekstu.

Typowe przyczyny to przejęty system źródłowy, nowo zlinkowany dokument lustrzany, przypadkowo opublikowany plik roboczy, błędnie przypisany tenant lub aktualizacja parsera, która przypisuje wartości tabeli do niewłaściwych nagłówków. Porównanie kryptograficznego hasha treści z zaufaną wartością referencyjną pozwala wykryć odchylenia; zgodny hash nie dowodzi jednak prawdy, aktualności ani zatwierdzenia treści.

Proweniencja jako weryfikowalny zestaw danych

Do każdego dokumentu i każdego wygenerowanego z niego fragmentu powinien być dołączony rekord proweniencji. W praktyce przydatne są co najmniej: stabilne ID źródła, kanoniczny URL pochodzenia, odpowiedzialny właściciel (owner), czas pobrania, wersja dokumentu, hash treści, status zatwierdzenia, klasa zaufania, wersja parsera, wersja chunkingu, model embeddingowy i generacja indeksu. W przypadku ręcznego przesyłania dochodzą rola osoby przesyłającej i zweryfikowana licencja. W systemach zsynchronizowanych ważne jest również, przez który uwierzytelniony konektor plik dotarł.

W dokumencie NIST AI 600-1 Generative AI Profile proweniencja treści (content provenance), identyfikowalna dokumentacja oraz testy i ewaluacje są traktowane jako kluczowe elementy zarządzania ryzykiem generatywnej AI. W przełożeniu na systemy RAG oznacza to: liczy się nie tylko aktualny indeks. Identyfikowalna relacja między rewizją źródła, przebiegiem przetwarzania a opublikowaną generacją indeksu jest również częścią dokumentacji operacyjnej.

Kwarantanna rozdziela pobieranie i publikację

Kluczowym elementem architektury jest konsekwentne rozdzielenie: nowe lub zmienione treści nie stają się od razu dostępne do wyszukiwania. Trafiają najpierw do strefy pobierania (ingestion zone). Tam potok danych (pipeline) waliduje pochodzenie, typ pliku, rozmiar, podpis lub oczekiwany hash, dozwolonego tenanta, kompletność metadanych i zakres zmian. Dopiero potem tekst i fragmenty są generowane w nieprodukcyjnej generacji indeksu.

Zasady powinny opierać się na analizie ryzyka. Zmiana na uwierzytelnionej, wewnętrznie nadzorowanej stronie FAQ może zostać zatwierdzona po automatycznych testach. Z kolei nowa domena, niezwykle obszerna zmiana tekstu, nieznany właściciel pliku lub źródło bez osoby odpowiedzialnej wywołują kwarantannę i weryfikację przez człowieka. Jeśli brakuje obowiązkowej informacji, obowiązuje zasada „fail closed”: stara, potwierdzona generacja pozostaje aktywna; nowy stan nie jest cicho publikowany.

Zatwierdzenie jako niezmienna generacja indeksu

Po weryfikacji indeks produkcyjny nie jest nadpisywany krok po kroku. Lepszym rozwiązaniem jest nowa, wersjonowana generacja z manifestem: oczekiwane dokumenty, oczekiwane fragmenty, hashe źródeł, wersje transformacji i znaczniki czasu. Dopiero gdy testy zakończą się sukcesem, alias lub konfiguracja routingu przełącza się atomowo na tę generację. Poprzednia generacja pozostaje dostępna do wycofania zmian (rollback) przez określony, zdefiniowany czas.

Procedura ta przypomina kontrolowaną migrację. Nasz artykuł o zmianie modelu embeddingowego w RAG pokazuje, dlaczego równe generacje indeksu i testy porównawcze są przydatne również przy zmianach technicznych. W przypadku podejrzenia zatrucia danych dochodzi dodatkowo kwestia bezpieczeństwa: którą rewizję źródła i które wygenerowane fragmenty należy zablokować?

Fikcyjny scenariusz przykładowy: błędny termin zwrotu trafia do bota wsparcia

Załóżmy, że sprzedawca prowadzi chatbota do pytań o produkty i usługi. Baza wiedzy synchronizuje co noc oficjalne centrum pomocy i kilka zatwierdzonych portali producentów. Po zmianie linku konektor podąża jednak za przekierowaniem na niezatwierdzoną stronę lustrzaną. Tam w wiarygodnie wyglądającym pliku PDF podano termin zwrotu wynoszący 90 zamiast 30 dni. Plik zostaje podzielony na fragmenty; kilka sekcji trafia do indeksu z wysokim podobieństwem semantycznym.

Następnego rana bot przy pytaniach o zwroty obiecuje błędny termin. Model językowy nie został przeprogramowany, a użytkownicy nie wprowadzili żadnej szkodliwej instrukcji. Wyszukiwanie dostarczyło po prostu błędnej podstawy. Monitoring podnosi alarm, ponieważ nowa domena po raz pierwszy pojawia się jako źródło odpowiedzi, a test Golden Set dla terminu zwrotu odbiega od oczekiwanego dowodu.

Kontrolowana kwarantanna i ponowne uruchomienie

1. Zespół zatrzymuje tylko dotknięte źródło pobierania i zamraża aktualną generację indeksu dla dalszych zmian.
2. Podejrzane ID dokumentu, wszystkie wygenerowane z niego ID fragmentów oraz ich trafienia w odpowiedziach są rejestrowane w incydencie.
3. Domena lustrzana zostaje zablokowana, a jej fragmenty przeniesione do kwarantanny. Na pytania o termin zwrotu bot tymczasowo dostarcza bezpieczną informację odsyłającą do wsparcia technicznego lub potwierdzonej strony z regulaminem.
4. Alias zostaje przywrócony do ostatniej udokumentowanej czystej generacji indeksu. Inne, nietknięte obszary wiedzy pozostają przy tym dostępne.
5. Konektor zostaje ograniczony do źródła kanonicznego. Następnie potok danych buduje nową generację z potwierdzonego manifestu.
6. Dopiero po testach reindeksacji i zatwierdzeniu merytorycznym ta generacja trafia na produkcję.

Ta kolejność ogranicza szkody bez pochopnego wyłączania całego chatbota. Kluczowe jest połączenie danych o pochodzeniu i pochodnych: bez przypisania dokumentu do fragmentów nie byłoby jasne, które wektory należy usunąć.

Testy reindeksacji muszą wykazać więcej niż tylko pomyślny przebieg potoku danych

Zielony status zadania dowodzi jedynie, że proces zakończył się technicznie. Nie dowodzi ani tego, że stare fragmenty zniknęły, ani że właściwe źródła wygrywają przy realistycznych pytaniach. Solidny pakiet testowy sprawdza zatem stan, wyszukiwanie i zachowanie odpowiedzi.

1. Weryfikacja manifestu i usunięć

Porównaj nową generację z zatwierdzonym manifestem. Każda oczekiwana wersja dokumentu musi być obecna; zablokowane ID dokumentów i fragmentów nie mogą występować. Szczególnie ważne są znaczniki usunięcia („tombstones”) dla usuniętych lub zastąpionych treści. W przeciwnym razie zwykłe dołączanie nowych embeddingów sprawi, że stare, zatrute trafienia nadal pozostaną w indeksie.

2. Testy wyszukiwania z oczekiwanymi źródłami

W przypadku krytycznych pytań oczekiwany tekst odpowiedzi nie wystarczy. Zdefiniuj dodatkowo dozwolone i zakazane ID źródeł, minimalną liczbę trafień oraz warunki wykluczenia. Termin zwrotu musi pochodzić np. z kanonicznego regulaminu; umieszczona w kwarantannie domena lustrzana nie może pojawić się ani w czołowych trafieniach, ani w kontekście modelu. Jak strukturyzować takie zestawy testowe, wyjaśnia artykuł dotyczący jakości odpowiedzi z wykorzystaniem Golden Set i testów RAG.

3. Testy negatywne i testy manipulacji

W odizolowanym środowisku testowym zespoły mogą wprowadzić jednoznacznie oznaczone, niezatwierdzone źródło testowe. Potok danych musi utrzymać je w kwarantannie; wyszukiwanie zbliżone do produkcyjnego nie może go pobrać. Dodatkowo testowane są nietypowe zmiany domen, brakujący właściciele, ekstremalne różnice w treści i sprzeczne daty. Raport NIST AI 100-2 dotyczący Adversarial Machine Learning klasyfikuje Poisoning jako kategorię ataku w swojej taksonomii i podkreśla, że przeciwdziałania oraz ich ograniczenia muszą być rozpatrywane systematycznie.

4. Porównanie przed i po zmianie

Wykonaj te same pytania dla ostatniej czystej oraz nowej generacji. Porównaj źródła trafień, kolejność (ranking), dowody w odpowiedziach, wskaźnik braku odpowiedzi (no-answer rate) i ocenę merytoryczną. Mały udział wersji Canary może dostarczyć dodatkowych sygnałów produkcyjnych, o ile użytkownicy nie uzyskają dostępu do nieprzetestowanych źródeł. Przełączenie produkcyjne następuje dopiero po spełnieniu określonych progów bezpieczeństwa i jakości.

Monitoring: wczesne wykrywanie nieprawidłowości

Monitoruj nie tylko oceny odpowiedzi. Miarodajne są nowe lub rzadkie domeny źródłowe, udział nieprzetestowanych źródeł w strumieniu pobierania, nietypowe rozmiary dokumentów, duże różnice w haszach lub tekście, wysoka liczba nowych fragmentów od jednego właściciela, zmiany czołowych źródeł w Golden Set oraz odpowiedzi bez potwierdzonego dowodu. Metryki powinny odwoływać się do ID proweniencji, a nie do niepotrzebnie zapisywanych pełnych pytań użytkowników.

Aktualność również pozostaje istotna. Stary, dawno zastąpiony regulamin nie jest celowo zatruty, ale może wywołać ten sam efekt. Artykuł dotyczący aktualności baz wiedzy i QA crawlera uzupełnia mechanizmy kontroli bezpieczeństwa o kadencję, odpowiedzialność i ścieżki usuwania.

Lista kontrolna bezpiecznego pobierania danych w RAG

• Czy każde źródło posiada stabilne ID, kanoniczne pochodzenie, osobę odpowiedzialną i klasę zaufania?
• Czy hash, wersja dokumentu, parser, chunking i model embeddingowy są rejestrowane razem?
• Czy nowe lub mocno zmienione źródła pozostają poza wyszukiwaniem produkcyjnym do czasu weryfikacji?
• Czy nowe domeny, brak podpisów lub nieprawdopodobne zmiany treści prowadzą do kwarantanny?
• Czy zatwierdzone indeksy są publikowane jako wersjonowane generacje z aliasem umożliwiającym wycofanie zmian?
• Czy reindeksacja udowadnialnie usuwa zastąpione fragmenty, zamiast tylko dołączać nowe dane?
• Czy zestaw Golden Set sprawdza zarówno odpowiedzi, jak i oczekiwane oraz zakazane źródła?
• Czy istnieje bezpieczny fallback dla tematów, których źródła zostały zablokowane podczas incydentu?
• Czy role dotyczące pobierania, zatwierdzania merytorycznego, obsługi incydentów i ponownej publikacji są rozdzielone i nazwane?
• Czy po każdym incydencie dokumentuje się, która kontrola zawiodła i jaki test regresyjny został dodany?

Podsumowanie

Zatrucia danych w RAG nie da się naprawić za pomocą pojedynczej reguły w prompcie. Ochrona wynika z weryfikowalnego łańcucha dostaw wiedzy: dokumentowania pochodzenia, sprawdzania zmian w kwarantannie, wersjonowania indeksów, bezpiecznego usuwania starych pochodnych i testowania wyszukiwania z oczekiwanymi źródłami. Zacznij od klas dokumentów o najwyższym ryzyku i małego zestawu Golden Set. Już to połączenie uwidacznia, które źródło wspiera odpowiedź – i umożliwia ukierunkowane wycofanie zmian, zanim błędny stan wiedzy stanie się trwałym stanem normalnym.

Źródła

• OWASP GenAI Security Project: LLM04:2025 Data and Model Poisoning
• NIST AI 600-1: Artificial Intelligence Risk Management Framework – Generative Artificial Intelligence Profile
• NIST AI 100-2: Adversarial Machine Learning – Taxonomy and Terminology of Attacks and Mitigations