Chatboty oparte na architekturze RAG miały być przełomem w dostępie do firmowej wiedzy – szybkie odpowiedzi na pytania pracowników, klientów czy partnerów, bez grzebania w dziesiątkach folderów i systemów. No i jak to zwykle bywa – rzeczywistość zweryfikowała te plany dość brutalnie. W Web Systems od lat projektujemy rozwiązania AI dla firm i widzimy ten sam schemat: obiecujące wdrożenie zamienia się w źródło frustracji, bo chatbot zaczyna opowiadać rzeczy, które nie mają pokrycia w dokumentach. Halucynacje w systemach RAG nie biorą się znikąd. To konsekwencja konkretnych błędów architektonicznych, które da się namierzyć i wyeliminować jeszcze zanim system trafi do użytkowników. Omawiamy sześć najczęstszych przyczyn, przez które chatbot na dokumentach firmy kłamie jak z nut – i pokazujemy, jak sobie z nimi radzić.
Brak kuracji bazy wiedzy – śmieciowe dane, śmieciowe odpowiedzi
Najczęstszy błąd, jaki widzimy przy wdrożeniach RAG? Podejście „wrzućmy wszystko i zobaczmy, co się stanie”. Firmy ładują do bazy wiedzy całą zawartość dysków sieciowych, sharepointa czy intranetu bez żadnej selekcji. Efekt bywa opłakany. Chatbot odpowiada na podstawie nieaktualnego regulaminu sprzed trzech lat albo cytuje roboczą wersję dokumentu, która nigdy nie została zatwierdzona. Każdy duplikat, każda przestarzała procedura, każdy skan bez poprawnego OCR – to gotowe źródło halucynacji.
Ale problem robi się naprawdę paskudny, gdy w bazie siedzą dokumenty wewnętrznie sprzeczne. Wyobraź sobie dwie wersje polityki urlopowej – jedną z 2021 roku, drugą aktualną. Model nie wie, która obowiązuje, więc może wybrać dowolną. Albo – co gorsza – połączyć informacje z obu. Użytkownik dostaje odpowiedź brzmiącą wiarygodnie, ale z błędnymi danymi. I tyle. Zaufanie do systemu leci na łeb po jednym takim incydencie, a odbudowanie go to kwestia miesięcy.
„Potrzebujesz najlepszego wyszukiwania semantycznego na bazie starannie wyselekcjonowanej bazy wiedzy, aby zapewnić, że pobierane informacje są istotne dla zapytania. Jeśli pobrane dane są nieistotne, generowana odpowiedź może być osadzona w kontekście, ale nie na temat lub po prostu błędna.”
Tip: Przed indeksowaniem zrób porządny audyt dokumentów. Wywal duplikaty i wersje robocze, zaktualizuj przestarzałe materiały, scal fragmentaryczne pliki w spójne całości. Przetestuj jakość OCR na skanach – jeśli tekst jest nieczytelny dla Ciebie, będzie bezużyteczny też dla modelu. Bazę wiedzy trzeba traktować jak produkt, który wymaga regularnej pielęgnacji. Jednorazowe załadowanie to za mało.
Źle dobrana strategia chunkingu dokumentów
Podział dokumentów na fragmenty – niby detal techniczny, a potrafi zdecydować o powodzeniu całego wdrożenia. Zbyt duże chunki? Model dostaje nadmiar informacji i gubi to, co ważne, w szumie pobocznych danych. Zbyt małe? Wyrywasz zdania z kontekstu i pozbawiasz je sensu. Znalezienie właściwej granulacji wymaga zrozumienia struktury dokumentów i tego, jak ludzie faktycznie zadają pytania.
Częsty problem to ignorowanie naturalnej struktury dokumentu podczas podziału. Testowałem to wielokrotnie – tabele rozbijane na pojedyncze wiersze tracą sens, listy kroków procedury rozdzielone między fragmenty stają się bezużyteczne, a nagłówki oderwane od treści wprowadzają model w błąd. Algorytm chunkujący musi respektować granice semantyczne tekstu. Mechaniczne liczenie tokenów czy znaków to za mało.
Różne typy dokumentów wymagają odmiennych podejść do podziału. Oto najczęściej stosowane strategie i sytuacje, w których sprawdzają się najlepiej:
- Chunking po nagłówkach – idealny dla dokumentacji technicznej i instrukcji, gdzie sekcje stanowią samodzielne jednostki informacji
- Chunking z nakładką (overlap) – sprawdza się przy tekstach narracyjnych, gdzie kontekst przechodzi płynnie między akapitami
- Chunking semantyczny – najlepszy dla złożonych dokumentów prawnych i umów, gdzie powiązane klauzule mogą znajdować się w różnych miejscach
- Chunking rekursywny – uniwersalny wybór, gdy baza zawiera mieszankę formatów i typów treści
- Chunking tabelaryczny – niezbędny przy dokumentach finansowych, raportach i zestawieniach, gdzie dane tabelaryczne muszą zachować strukturę
W naszych projektach testujemy kilka strategii na reprezentatywnej próbce dokumentów, zanim podejmiemy finalną decyzję. Koszt takich eksperymentów? Minimalny w porównaniu z ryzykiem wdrożenia systemu, który regularnie halucynuje przez źle podzielone źródła.
Słaby mechanizm wyszukiwania semantycznego
Możesz mieć perfekcyjnie przygotowaną bazę wiedzy, ale jeśli mechanizm wyszukiwania nie potrafi znaleźć właściwych fragmentów – no to po co to wszystko? Proste wyszukiwanie wektorowe oparte wyłącznie na similarity search to punkt wyjścia. Nie rozwiązanie produkcyjne. Bez rerankerów, filtrów metadanych i mechanizmów hybrydowych system zbyt często zwraca fragmenty pozornie podobne semantycznie, ale merytorycznie nietrafione.
Hybrid search – połączenie wyszukiwania wektorowego z klasycznym keyword search – znacząco poprawia trafność wyników. Sprawdziłem to na wielu projektach. Embeddingi dobrze radzą sobie z parafrazami i synonimami, ale zawodzą przy specjalistycznej terminologii, numerach dokumentów czy nazwach produktów. I tu wchodzi wyszukiwanie słów kluczowych, które doskonale uzupełnia tę lukę. Pomijanie tego podejścia to jeden z częstszych błędów, który obserwujemy nawet w dojrzałych organizacjach technologicznych.
Konfiguracja parametru top-k oraz progów similarity score wymaga sporej rozwagi. Zbyt wysoka wartość top-k zalewa model nieistotnymi fragmentami, rozmywa kontekst i zwiększa ryzyko halucynacji. Zbyt niska? Brakuje informacji do pełnej odpowiedzi, a model uzupełnia luki wiedzą własną. Bo tak już działa – nie lubi mówić „nie wiem”. W praktyce optymalne wartości różnią się w zależności od domeny i typu pytań. Uniwersalny default rzadko sprawdza się w produkcji.
Reranker jako druga warstwa oceny wyników potrafi dramatycznie poprawić jakość retrievalu. Pierwszy etap wyszukiwania zwraca kandydatów szybko, ale niedokładnie. Reranker analizuje ich głębiej w kontekście zapytania i ustala właściwą kolejność. Ta dwuetapowa architektura zwiększa precyzję bez poświęcania szybkości działania, co w środowisku produkcyjnym ma ogromne znaczenie.
Brak ewaluacji i metryk jakości odpowiedzi
Wdrożenie chatbota RAG bez systemu mierzenia jakości odpowiedzi to jak jazda samochodem z zaślepionymi zegarami. Nie wiesz, jak szybko jedziesz, ile masz paliwa, ani czy silnik się przegrzewa. W Web Systems traktujemy ewaluację jako integralną część architektury, nie opcjonalny bajer. Metryki takie jak groundedness, faithfulness i relevance pozwalają obiektywnie ocenić, czy system działa poprawnie – zamiast polegać na wrażeniach kilku osób, które „poklikały i wygląda ok”.
Nowoczesne platformy ewaluacyjne oferują całe zestawy metryk do oceny generowanego tekstu. Coherence mierzy spójność logiczną odpowiedzi, fluency ocenia naturalność języka, groundedness weryfikuje oparcie na źródłach, a instruction_following sprawdza zgodność z poleceniami systemowymi. Każda z tych metryk ujawnia inny aspekt potencjalnych problemów i wskazuje, co konkretnie poprawić. Bez nich iteracyjna poprawa systemu opiera się na domysłach. Nie na danych.
Podejście RAG Ops zakłada ciągły cykl pomiaru, analizy i optymalizacji – analogiczny do DevOps, ale skoncentrowany na jakości generowanych odpowiedzi. Po każdej zmianie konfiguracji, aktualizacji bazy wiedzy czy modyfikacji promptu odpalasz zestaw testów i porównujesz wyniki z poprzednimi. Taka dyscyplina pozwala systematycznie poprawiać jakość zamiast zmieniać na ślepo i trzymać kciuki.
Tip: Zbuduj zestaw co najmniej 50 pytań testowych z oczekiwanymi odpowiedziami, pokrywający typowe scenariusze użycia. Uruchamiaj go automatycznie po każdej zmianie w systemie. I dodaj pytania podchwytliwe, na które poprawną odpowiedzią jest odmowa – to najlepszy sposób na wyłapanie halucynacji, zanim dotrą do użytkowników końcowych.
Nieprzemyślany prompt i brak instrukcji grounding dla modelu
Model językowy bez jasnej instrukcji „odpowiadaj wyłącznie na podstawie dostarczonego kontekstu” zachowuje się jak rozmowny gość na imprezie, który nie lubi przyznawać się do niewiedzy. Gdy pobrany kontekst nie zawiera odpowiedzi na pytanie, model sięga po wiedzę ogólną i generuje odpowiedź brzmiącą pewnie, ale niepowiązaną z dokumentami firmy. Użytkownik nie jest w stanie odróżnić takiej halucynacji od prawidłowej odpowiedzi. I właśnie dlatego jest tak niebezpieczna.
Mechanizm odmowy odpowiedzi – to element, którego brakuje w większości wdrożeń. System powinien umieć powiedzieć „nie znalazłem wystarczających informacji w dostępnych dokumentach” zamiast zmyślać. Zaprojektowanie takiego zachowania wymaga precyzyjnych instrukcji w system prompcie, określających progi pewności i scenariusze eskalacji. Generyczny szablon „odpowiadaj na podstawie kontekstu” nie wystarczy. Prompt musi uwzględniać specyfikę domeny, terminologię branżową i typowe pułapki.
Różnica między promptem dostosowanym do konkretnej dziedziny a generycznym szablonem bywa kolosalna. W projektach dla kancelarii prawnych dodajemy instrukcje dotyczące precyzji cytowania przepisów, w systemach medycznych – zasady ostrożności przy interpretacji wyników. Każda domena ma własne reguły, których złamanie podważa wiarygodność całego rozwiązania. Fine-tuning promptu pod specyfikę firmy to inwestycja, która zwraca się szybko – w postaci odpowiedzi, na których użytkownicy mogą polegać.
System prompt pełni też rolę arbitra w sytuacjach niejednoznacznych. Gdy pobrane fragmenty zawierają pozornie sprzeczne informacje, dobrze zaprojektowany prompt instruuje model, jak rozstrzygać takie konflikty. Czy priorytet ma nowszy dokument? Dokument wyższego poziomu zatwierdzenia? A może system powinien przedstawić obie wersje i poprosić użytkownika o doprecyzowanie pytania? To trzeba zaprojektować z góry.
Ignorowanie utrzymania systemu po wdrożeniu
Dokumenty firmowe żyją własnym życiem. Regulaminy się zmieniają, procedury ewoluują, powstają nowe produkty, stare wychodzą z oferty. Chatbot RAG, którego baza wiedzy nie jest regularnie aktualizowana, zaczyna podawać nieaktualne informacje już po kilku tygodniach od uruchomienia. Nie chodzi o to, czy się zestarzeje – chodzi o to, kiedy. Bez zautomatyzowanego pipeline’u aktualizacji system staje się coraz mniej wiarygodny z każdym dniem.
Równie ważny jest monitoring zapytań użytkowników. Bo bez analizy tego, o co ludzie faktycznie pytają, nie wiesz, gdzie chatbot się wykłada. Może regularnie nie radzi sobie z pytaniami o konkretny produkt, bo dokumentacja tego produktu jest dziurawa. Może użytkownicy formułują pytania w sposób, którego system nie rozumie. Feedback loop między użytkownikami a zespołem utrzymującym RAG – to fundament długoterminowej jakości. Bez tego lecisz na ślepo.
Koszty utrzymania systemu RAG bywają niedoszacowane na etapie planowania. Reindeksowanie dokumentów po aktualizacji, regeneracja embeddingów przy zmianie modelu, wersjonowanie bazy wiedzy, monitoring wydajności i jakości – to wszystko wymaga zasobów i procesów. W naszych wdrożeniach zawsze projektujemy architekturę oprogramowania z myślą o operacjach po uruchomieniu. Bo system, którego nikt nie utrzymuje, degraduje się szybciej niż powstał.
Praktyka pokazuje jedno – firmy, które traktują RAG jako projekt z datą zakończenia zamiast jako produkt wymagający ciągłej opieki, tracą zainwestowane środki w ciągu kwartału. Wersjonowanie bazy wiedzy pozwala cofnąć zmiany, gdy nowa partia dokumentów obniży jakość odpowiedzi, a automatyczne alerty informują o spadku metryk zanim użytkownicy zaczną narzekać.
FAQ
Czy chatbot RAG może całkowicie wyeliminować halucynacje?
Nie. Żaden system oparty na modelach językowych nie gwarantuje stuprocentowej dokładności. Można jednak zminimalizować ryzyko halucynacji do poziomu akceptowalnego w środowisku biznesowym. Trzeba podejść do tego wielowarstwowo – staranna kuracja bazy wiedzy, precyzyjny prompt z instrukcjami grounding, mechanizm odmowy odpowiedzi przy niskiej pewności i ciągła ewaluacja jakości. Każda z tych warstw redukuje prawdopodobieństwo błędu, a ich kombinacja daje system, któremu użytkownicy mogą ufać na co dzień. I jeszcze jedno – chatbot powinien transparentnie komunikować stopień pewności swoich odpowiedzi. Żadnego udawania, że wie wszystko.
Ile dokumentów potrzeba, żeby RAG miał sens w firmie?
Liczba dokumentów ma mniejsze znaczenie niż ich jakość i pokrycie tematyczne. Widzieliśmy skuteczne wdrożenia oparte na dwudziestu starannie przygotowanych dokumentach, które odpowiadały na 80% pytań użytkowników. Serio – dwadzieścia. Minimalny viable knowledge base powinien pokrywać najczęstsze scenariusze zapytań w danej organizacji. Lepiej zacząć od wąskiego, dobrze pokrytego obszaru i stopniowo rozszerzać zakres niż od razu indeksować tysiące plików bez kontroli jakości. Takie iteracyjne podejście pozwala szybko dostarczyć wartość i budować zaufanie, zamiast ryzykować rozczarowanie na starcie.
Podsumowanie
Każdy z opisanych sześciu błędów to świadoma lub nieświadoma decyzja projektowa. Nie losowy wypadek. Brak kuracji danych, nieprzemyślany chunking, słabe wyszukiwanie, brak ewaluacji, generyczny prompt i zaniedbane utrzymanie – to elementy architektury, które można zaprojektować poprawnie od początku lub naprawić w istniejącym systemie. RAG to nie jest rozwiązanie typu plug-and-play, które wystarczy podłączyć do dokumentów i zapomnieć. Wymaga przemyślanej architektury, systematycznego testowania i ciągłej opieki operacyjnej.
W Web Systems podchodzimy do wdrożeń chatbotów RAG jak do każdego projektu inżynierskiego – z planem, metrykami i jasno zdefiniowanymi kryteriami sukcesu. Jeśli planujesz uruchomienie chatbota na dokumentach firmy albo Twój obecny system generuje odpowiedzi, którym użytkownicy nie ufają, skontaktuj się z nami. Pomożemy zaprojektować architekturę RAG odporną na halucynacje lub przeprowadzimy audyt istniejącego rozwiązania i wskażemy konkretne miejsca do poprawy.
