RAG to nie wtyczka, którą się instaluje i zapomina

Co RAG robi inaczej niż zwykłe wklejanie dokumentów do promptu

Standardowy schemat wygląda tak: ktoś w firmie chce zadać pytanie na podstawie wewnętrznych procedur, więc kopiuje plik PDF do okna ChatGPT. To działa, dopóki ten plik nie zawiera danych osobowych klientów, warunków umów z kontrahentami albo informacji, które konkurencja chętnie by przeczytała. I tu pojawia się RAG jako coś rzekomo bezpieczniejszego.

W uproszczeniu: zamiast wysyłać całe dokumenty do zewnętrznego modelu, dzielisz je na fragmenty, zamieniasz na wektory (liczby opisujące znaczenie tekstu) i przechowujesz lokalnie albo we własnej infrastrukturze chmurowej. Kiedy pracownik zadaje pytanie, system najpierw szuka w tej lokalnej bazie wektorowej najbardziej pasujących fragmentów, a dopiero te fragmenty wysyła do modelu językowego razem z pytaniem. Model widzi tylko wycinek, nie całe archiwum.

To nie jest mała różnica. W klasycznym podejściu model procesuje wszystko. W RAG — procesuje selekcję. Pytasz o politykę urlopową, model dostaje trzy akapity z HR handbook, nie pełną bazę kadrową. Przynajmniej w teorii.

W praktyce sprawy się komplikują w kilku miejscach, które większość dostawców gotowych rozwiązań przemilcza albo chowa w dokumentacji technicznej.

Cztery miejsca, w których wiedza firmy może wypłynąć mimo RAG

Pierwsze i najczęstsze: baza wektorowa bez kontroli dostępu. Wektory to nie czytelny tekst, ale można je odkodować wystarczająco dokładnie, żeby odtworzyć oryginał. Jeśli wszystkie dokumenty firmy trafiają do jednej wspólnej bazy i każdy pracownik może pytać o wszystko, księgowa może przypadkowo wyciągnąć informacje o wynagrodzeniach zarządu, a handlowiec zobaczyć marże na kontraktach, których nie obsługuje. To nie jest scenariusz akademicki.

Drugie: logi zapytań. Każde pytanie zadane systemowi RAG gdzieś się zapisuje. Jeśli korzystasz z modelu przez API zewnętrznego dostawcy (OpenAI, Anthropic, Cohere — nieważne), te logi mogą być przechowywane przez dostawcę nawet 30 dni w celach diagnostycznych, chyba że wyraźnie wyłączysz tę opcję w ustawieniach konta i masz plan biznesowy, który na to pozwala. Standardowe plany konsumenckie tego nie gwarantują.

Trzecie: chunking bez kontekstu. Kiedy dzielisz dokumenty na fragmenty, łatwo przeciąć zdanie w połowie i stworzyć fragment, który wyrwany z kontekstu brzmi jak coś innego. Mniej groźne bezpieczeństwowo, za to źródło błędnych odpowiedzi systemu — a to ma swój koszt: pracownicy przestają ufać narzędziu albo, gorzej, ufają mu zbyt mocno.

Czwarte, i tu mam przeczucie oparte bardziej na obserwacjach niż twardych danych: hybrydy lokalne i chmurowe gdzie granica między nimi jest rozmyta. Znam kilka MŚP, które zaczęły RAG od lokalnego Ollamy i Chroma DB, a po trzech miesiącach, kiedy zdali sobie sprawę z kosztów utrzymania własnego serwera, przepięli część ruchu do chmury nie aktualizując polityki bezpieczeństwa. Audyt IT wykazał rozbieżność półtora roku później.

Jak to się robi, kiedy ktoś naprawdę uważa na szczegóły

Firma Wierzbicki Logistics z Gdańska (45 pracowników, spedycja drogowa) wdrożyła RAG wewnętrzny w pierwszym kwartale 2024 roku do obsługi zapytań o procedury celne, wzory dokumentów i historię reklamacji. Na papierze projekt zajął sześć tygodni. Faktycznie utknął na eksporcie danych z ich starego systemu WMS przez trzy tygodnie, bo format plików był inny niż zakładano, i w tym czasie połowa działu obsługi i tak pisała pytania do publicznego ChatGPT, bo nic jeszcze nie działało.

Kiedy system ruszył, zrobili jedną rzecz, której sporo firm nie robi: podzielili bazę wektorową na przestrzenie według ról. Dokumenty handlowe dostępne tylko dla handlowców i zarządu. Procedury operacyjne dla wszystkich. Dane finansowe klientów wyłącznie dla kierownika rozliczeń. Każde zapytanie jest logowane lokalnie z identyfikatorem użytkownika, ale logi nie trafiają do zewnętrznego API. Model językowy dostają fragmenty tekstu, nie metadane z nazwiskami klientów.

Nie twierdzę, że to wzorcowe rozwiązanie dla każdego. Wierzbicki działa na infrastrukturze Hetzner z własnym serwerem do embeddingów i modelem do inferencji hostowanym lokalnie (LLaMA 3 8B, w momencie wdrożenia). Koszt startowy był wyższy niż SaaS, czas odpowiedzi systemu jest wolniejszy niż GPT-4o, a onboarding nowych pracowników wymaga osobnego szkolenia. Zysk jest taki, że żaden fragment ich dokumentacji handlowej nie dotknął serwera poza Europą.

Dla porównania: firma tej samej wielkości, która wybierze gotowe rozwiązanie SaaS zintegrowane z GPT-4, zapłaci mniej na starcie i dostanie lepszą jakość odpowiedzi, ale oddaje kontrolę nad logami i musi ufać umowie powierzenia danych z dostawcą. To nie jest zły wybór — pod warunkiem że ta umowa istnieje, jest przeczytana i zgodna z RODO. W mojej ocenie mniej niż połowa firm, które korzystają z takich narzędzi, ma komplet dokumentacji prawnej w porządku. To bardziej nieporządek niż złośliwość, ale konsekwencje w razie wycieku są takie same.

Minimalna lista rzeczy do sprawdzenia, zanim uruchomisz RAG produkcyjnie

Piszę to jako lista, bo tu naprawdę jest sens wypunktować — nie z przyzwyczajenia do schematów.

Kto ma dostęp do bazy wektorowej i na jakim poziomie? Jeśli odpowiedź brzmi 'wszyscy przez jeden klucz API', to masz problem z granulacją uprawnień zanim jeszcze zaczniecie.

Gdzie są przechowywane logi zapytań i jak długo? Zapytaj dostawcę wprost. Jeśli nie dają pisemnej odpowiedzi w dokumentacji lub umowie, traktuj to jak brak odpowiedzi.

Czy umowa powierzenia danych osobowych z dostawcą modelu językowego i dostawcą bazy wektorowej jest podpisana? To dwie osobne umowy, nie jedna.

Jak wyglądają fragmenty, które faktycznie trafiają do modelu? Poproś dewelopera o przykładowe logi z retrieval step. Jeśli w tym fragmencie jest PESEL, numer konta albo imię konkretnego klienta, chunking jest źle zaprojektowany.

Wróćmy jeszcze do jednej kwestii, którą pominąłem wcześniej: modele embeddingowe. Żeby stworzyć bazę wektorową, musisz najpierw przetworzyć dokumenty przez model embeddingowy. Jeśli używasz OpenAI Embeddings API, twoje dokumenty przechodzą przez ich serwery w tym kroku — jeszcze zanim ktokolwiek zada pierwsze pytanie. Wiele firm nie zdaje sobie z tego sprawy, bo skupia się na bezpieczeństwie inferencji, nie indeksowania.

Alternatywą są lokalne modele embeddingowe (nomic-embed, mxbai-embed, bge-m3). Są wolniejsze i lekko gorsze jakościowo, ale dokument nigdy nie opuszcza twojej infrastruktury. Dla materiałów wrażliwych — ofert, umów, danych kadrowych — ta kompromis wydaje mi się rozsądny.

Ostatnia rzecz, drobna i łatwa do przeoczenia: upewnij się, że pracownicy wiedzą, co system wie, a czego nie wie. RAG odpowie pewnie nawet jeśli odpowiedni fragment nie istnieje w bazie — model językowy nie powie 'nie mam danych', tylko skleci coś z tego, co dostał. Systemy bez explicitnego komunikatu o niskiej trafności retrieval uczą pracowników złych nawyków szybciej, niż się spodziewasz.