Klienci pytają nas o to coraz częściej: “Czy moglibyśmy mieć asystenta, który zna nasze dokumenty i odpowiada pracownikom oraz klientom na pytania o oferty, procedury i umowy?”. I tak zwykle zaczyna się rozmowa o chatbocie RAG. My, czyli Web Systems, software house z Łodzi działający od 2006 roku, patrzymy na to bez złudzeń. To nie zabawka na pokaz. To pełnoprawny projekt integracyjny, z architekturą, bezpieczeństwem i utrzymaniem. W tym artykule pokażę, jak działa chatbot na dokumentach firmy, na czym polega technologia RAG i jak naprawdę ograniczać halucynacje sztucznej inteligencji.
Spis treści
Czym jest chatbot na dokumentach firmy i dlaczego RAG zmienia zasady gry
Standardowy model językowy odpowiada na podstawie ogólnej wiedzy, którą wchłonął podczas treningu. Tylko że on nie zna Twojej oferty, cennika, regulaminu reklamacji ani wewnętrznej procedury onboardingu. Skąd miałby? Zapytany o szczegóły, zaczyna zgadywać. I tu rodzą się kosztowne pomyłki. Chatbot zbudowany na wewnętrznej bazie wiedzy firmy działa inaczej: opiera odpowiedzi na realnych plikach, a nie na wyobrażeniu modelu o tym, jak Twoja firma mogłaby funkcjonować.
Skrót RAG oznacza Retrieval-Augmented Generation, czyli generację wzbogaconą o wyszukiwanie. Pomysł jest banalnie prosty. Model najpierw przeszukuje dokumenty, znajduje pasujące fragmenty, a dopiero potem formułuje odpowiedź na ich podstawie. I dzięki temu sztuczna inteligencja przestaje być wyrocznią opowiadającą z pamięci. Staje się asystentem, który czyta źródło, zanim cokolwiek powie. To zmiana logiki działania od podstaw.
Intencja naszych klientów zwykle jest jasna: ograniczyć domysły AI i przykuć odpowiedzi do konkretnych procedur, ofert, umów i dokumentacji technicznej. Nikt nie chce efektownego gadżetu, który czasem trafi, a czasem zmyśli paragraf umowy. Firmy oczekują narzędzia przewidywalnego, które zdejmie część telefonów z działu obsługi i skróci czas wyszukiwania informacji przez pracowników. No i tyle. Tak naprawdę o to chodzi.
My, jako wykonawca, traktujemy taki system jak projekt inżynierski. Wymaga przemyślanego potoku przetwarzania danych, doboru bazy wektorowej, integracji z istniejącymi systemami B2B i kontroli dostępu. Demo sklecone w weekend potrafi zrobić wrażenie na prezentacji. Ale wdrożenie produkcyjne, które obsługuje setki dokumentów i wielu użytkowników, rządzi się zupełnie innymi prawami. Tę różnicę widać dopiero wtedy, gdy chatbot zaczyna pracować na prawdziwych danych i realnym ruchu. Wcześniej nikt jej nie czuje.
Jak technicznie działa RAG – od dokumentu do odpowiedzi
Wszystko zaczyna się od ingestu, czyli wczytania dokumentów do systemu. Pliki PDF, DOCX, arkusze czy rekordy z bazy danych trafiają do potoku, gdzie zostają sparsowane i oczyszczone z elementów zakłócających, takich jak stopki, nagłówki czy powtarzające się tabele. Potem dzielimy treść na mniejsze fragmenty, zwane chunkami. I sposób tego podziału ma kolosalne znaczenie. Zbyt duże fragmenty rozmywają sens, zbyt małe gubią kontekst. Trzeba trafić w sam środek.
Każdy fragment przekształcamy w embedding, czyli wektor liczb reprezentujący znaczenie tekstu. Te wektory lądują w bazie wektorowej, która umożliwia błyskawiczne porównywanie podobieństwa semantycznego. Gdy użytkownik zadaje pytanie, system zamienia je również w wektor i wyszukuje fragmenty leżące najbliżej w przestrzeni znaczeń. To wyszukiwanie semantyczne różni się od klasycznego dopasowania słów. Liczy się sens zapytania, a nie identyczne brzmienie.
Na etapie generacji wybrane fragmenty trafiają do modelu językowego jako kontekst. LLM dostaje instrukcję, żeby odpowiadał wyłącznie na podstawie dostarczonego materiału, i to nazywamy groundingiem. Dzięki temu zakotwiczeniu odpowiedzi w realnym tekście model minimalizuje sprzeczności i przestaje improwizować. Jakość tego kroku zależy wprost od trafności wcześniejszego wyszukiwania. Śmieci na wejściu, śmieci na wyjściu.
Przepływ danych w uproszczeniu wygląda następująco:
- Dokument źródłowy (PDF, DOCX, baza danych) trafia do systemu i zostaje sparsowany.
- Chunking dzieli treść na spójne znaczeniowo fragmenty.
- Embedding zamienia każdy fragment na wektor i zapisuje go w bazie wektorowej.
- Wyszukiwanie dobiera fragmenty najbardziej pasujące do pytania użytkownika.
- Odpowiedź powstaje na podstawie pobranego kontekstu, z zachowaniem groundingu.
Najważniejszy w tym wszystkim jest retrieval. To dobre wyszukiwanie semantyczne na starannie wykuratorowanej bazie wiedzy decyduje o tym, czy model dostanie właściwy materiał. Nietrafiony kontekst prowadzi do odpowiedzi poprawnej formalnie, ale kompletnie obok tematu. Mówiąc wprost, model potrafi pięknie odpowiedzieć na pytanie, którego nikt nie zadał, jeśli podsuniemy mu nie te fragmenty. Dlatego inwestycję w retrieval traktujemy jako serce całego systemu. Tu się wygrywa albo przegrywa.
Skąd biorą się halucynacje AI i jak RAG je ogranicza
Halucynacja to sytuacja, w której model wymyśla dane nieobecne w dokumentach albo miesza ze sobą fakty z różnych źródeł. Wychodzi odpowiedź brzmiąca wiarygodnie, a nieprawdziwa. Nieistniejący zapis umowy, błędna stawka, zmyślony termin gwarancji. W biznesie takie pomyłki potrafią słono kosztować, bo użytkownik ufa asystentowi i działa na podstawie jego słów.
Samo wpięcie RAG niczego jednak nie załatwia automatycznie. Halucynacje wracają, gdy chunking zrobiono po łebkach, retrieval zwraca nieistotne fragmenty, dane w bazie są nieaktualne albo prompt jest tak szeroki, że pozwala modelowi puścić wodze fantazji. Technologia ogranicza ryzyko, ale go nie znosi. Liczy się staranność każdego etapu potoku, a nie sam fakt, że w architekturze siedzi modny skrót.
Mechanizmów ograniczania jest kilka i działają najlepiej razem. Grounding wymusza opieranie się wyłącznie na pobranym kontekście. Precyzyjna instrukcja w stylu “odpowiadaj tylko na podstawie dostarczonych fragmentów, a jeśli ich brak, powiedz, że nie wiesz” odbiera modelowi przyzwolenie na zgadywanie. Do tego podawanie źródeł przy każdej odpowiedzi buduje zaufanie i pozwala zweryfikować.
I to właśnie cytowanie źródeł uważam za jedno z najskuteczniejszych zabezpieczeń, jakie znam.
- Tip: wymuszaj podawanie nazwy dokumentu i fragmentu przy każdej odpowiedzi. Użytkownik może wtedy jednym kliknięciem sprawdzić, skąd pochodzi informacja, a sam model rzadziej improwizuje, wiedząc, że musi wskazać konkretne źródło.
Takie podejście zmienia relację człowieka z asystentem. Zamiast ślepo ufać wygenerowanemu zdaniu, pracownik widzi przypis prowadzący do oryginalnego paragrafu. Coś mu nie pasuje? Weryfikacja zajmuje sekundy. Prosty mechanizm, a w praktyce drastycznie podnosi wiarygodność całego rozwiązania i ułatwia wyłapywanie ewentualnych błędów retrievalu, zanim trafią do klienta końcowego.
Najczęstsze błędy projektowe i ryzyka wdrożeniowe
Błąd numer jeden, który widujemy najczęściej, to wrzucanie surowych dokumentów do systemu bez żadnego przygotowania. Skany pełne szumu, tabele zlepione w jeden ciąg znaków, zero strategii dzielenia na fragmenty. Retrieval pracuje wtedy na chaosie. Efekt łatwo przewidzieć: chatbot zwraca przypadkowe urywki, a zespół zachodzi w głowę, dlaczego “ta cała sztuczna inteligencja” nie działa. Problem nie siedzi w modelu. Siedzi w jakości danych wejściowych.
Grzech drugi to brak ewaluacji. Zespół “czuje”, że system odpowiada sensownie, zamiast mierzyć trafność retrievalu i groundedness, czyli stopień zakotwiczenia odpowiedzi w źródłach. Bez metryk nie da się powiedzieć, czy kolejna zmiana w chunkingu coś poprawiła, czy zepsuła. Wdrożenie produkcyjne bez pomiaru to strojenie silnika po omacku. Prosta droga do regresji, której nikt nie zauważy, dopóki nie zadzwoni zły klient.
Osobny temat to bezpieczeństwo. Dokumenty firmowe zawierają dane wrażliwe, więc kontrola dostępu nie jest dodatkiem, tylko wymogiem. Chatbot musi respektować uprawnienia. Handlowiec nie powinien przez asystenta dotrzeć do dokumentów kadrowych. Tu kluczowa jest izolacja danych poszczególnych klientów oraz pewność, że fragmenty z bazy wektorowej nie wyciekną do niepowołanych odbiorców. Tę warstwę projektujemy od pierwszego dnia, a nie doklejamy na końcu na taśmę klejącą.
Nie wolno też przymykać oka na koszty utrzymania. Baza wiedzy się starzeje, więc potrzebny jest proces aktualizacji dokumentów i ponownego indeksowania. Rosnąca liczba plików podnosi wymagania wobec bazy wektorowej, a każde zapytanie do modelu generuje koszt inferencji. Przy dużym ruchu rachunek potrafi nieźle zaskoczyć, jeśli nikt go wcześniej nie oszacował.
Dla nas, w Web Systems, wdrożenie sprowadza się do realnych decyzji architektonicznych. Dobieramy bazę wektorową pod skalę, ważymy model on-premise kontra API w zależności od wrażliwości danych i budżetu, a potem spinamy całość z istniejącymi systemami B2B – CRM, ERP czy repozytoriami dokumentów. Te wybory przesądzają o koszcie, bezpieczeństwie i przyszłej skalowalności rozwiązania. Dlatego podejmujemy je świadomie, a nie na czuja.
Jak zbudować wiarygodny chatbot RAG – praktyczne wskazówki
Fundamentem dobrego systemu jest kuracja źródeł. Zanim cokolwiek trafi do bazy, dokumenty trzeba oczyścić, ustrukturyzować i sparsować z uwzględnieniem ich układu. Inaczej traktujemy regulamin, inaczej tabelę cen. Dopiero na tak przygotowanym materiale ma sens przemyślany chunking, dobór modelu embeddingów odpowiedniego dla języka polskiego oraz ponowne formułowanie zapytania użytkownika, żeby lepiej pasowało do treści w bazie.
Równie ważny jest pomiar jakości. Podejście, które nazywamy RAG Ops, opiera się na metrykach takich jak groundedness, fluency i trafność odpowiedzi. Mierzymy, iterujemy, poprawiamy konfigurację wyszukiwarki, strategię chunkingu i sposób przeformułowania pytań. Taka praca oparta na danych pozwala stopniowo wspinać się ku wysokiej jakości generacji, zamiast zgadywać, czy zmiana w ogóle coś dała.
Praktyczne wskazówki, które stosujemy przy budowie:
- Kuracja i parsowanie – usuń szum, zachowaj strukturę, dopasuj parsowanie do typu dokumentu.
- Przemyślany chunking – dobierz rozmiar fragmentu do charakteru treści, testuj różne warianty.
- Dobry model embeddingów – wybierz taki, który dobrze rozumie język i domenę klienta.
- Przeformułowanie zapytania – oczyść i doprecyzuj pytanie użytkownika przed wyszukiwaniem.
- Pomiar i iteracja – traktuj metryki jako kompas, a nie jednorazowy raport.
Architektura to fundament całości. Rozdzielamy warstwy ingestu, retrievalu, generacji i interfejsu użytkownika, pilnując pojedynczego źródła prawdy dla danych oraz testowalności każdego komponentu z osobna. Taka separacja odpowiedzialności sprawia, że system łatwiej się utrzymuje, skaluje i rozwija, a zmiana w jednej warstwie nie wywraca pozostałych do góry nogami. To te same zasady inżynierskie, które od lat stosujemy w tworzeniu dedykowanego oprogramowania, aplikacjach webowych i systemach B2B. Nic nowego, po prostu działają.
Tip: zacznij od dobrze zdefiniowanego MVP na wąskim zbiorze dokumentów. Zmierz wyniki na realnych pytaniach, popraw słabe punkty, a dopiero potem rozszerzaj zakres bazy wiedzy. Próba objęcia od razu wszystkiego kończy się projektem, którego nikt nie potrafi zmierzyć ani ujarzmić.
FAQ – najczęstsze pytania o chatboty RAG na dokumentach firmy
Czy RAG całkowicie eliminuje halucynacje?
Nie, ale skutecznie je ogranicza, o ile retrieval i grounding zostały dobrze zaprojektowane i są regularnie mierzone. RAG zakotwicza odpowiedzi w realnych dokumentach, dzięki czemu model rzadziej zmyśla. Pełna eliminacja nie istnieje. Za to przy starannym chunkingu, trafnym wyszukiwaniu, wymuszonym cytowaniu źródeł i stałej ewaluacji ryzyko spada do poziomu akceptowalnego biznesowo. Klucz tkwi w inżynierii i utrzymaniu, nie w samej obecności technologii.
Czy moje dane są bezpieczne?
To zależy od przyjętej architektury, a bezpieczeństwo da się zaprojektować od podstaw. Stosujemy kontrolę dostępu opartą na uprawnieniach, izolację danych poszczególnych klientów oraz mechanizmy gwarantujące, że fragmenty z bazy nie trafią do niepowołanych odbiorców. Dla wrażliwych zastosowań możliwe są wdrożenia bliżej infrastruktury klienta, w tym modele on-premise, które ograniczają wysyłanie danych na zewnątrz. Bezpieczeństwo traktujemy jako wymóg projektowy, nie opcję.
Czy chatbot zintegruje się z naszymi systemami?
Tak, i to integracja jest jednym z głównych powodów, dla których takie projekty w ogóle mają sens. Łączymy chatbota przez API z dokumentami, bazami danych i narzędziami B2B, które już działają w firmie – od CRM, przez ERP, po wewnętrzne repozytoria plików. Dzięki temu asystent odpowiada na aktualnych danych, a nie na statycznej kopii sprzed miesięcy. Zakres integracji ustalamy na podstawie realnych systemów i procesów po stronie klienta.
Podsumowanie i kontakt
RAG to sposób na to, żeby chatbot opierał odpowiedzi na realnych dokumentach firmy, zamiast zgadywać na podstawie ogólnej wiedzy modelu. Najpierw wyszukuje właściwe fragmenty, potem formułuje odpowiedź zakotwiczoną w źródłach. Pozornie prosta zmiana logiki. A jednak diametralnie podnosi wiarygodność asystenta i robi z niego narzędzie nadające się do pracy z umowami, ofertami i procedurami.
Sukces takiego wdrożenia stoi na kilku filarach: jakości retrievalu, konsekwentnym groundingu, pomiarze jakości w duchu RAG Ops, bezpieczeństwie danych i przemyślanej architekturze z rozdzielonymi warstwami. Halucynacji nie usuwa magia ani modny skrót na slajdzie, tylko inżynieria i rzetelne utrzymanie. Chatbot, który dziś odpowiada bezbłędnie, jutro zacznie się mylić, jeśli nikt nie zadba o aktualizację bazy i monitoring metryk. Tak to po prostu działa.
Planujesz chatbota na dokumentach firmy, budowę MVP, integrację przez API albo szerszą automatyzację AI w swoich procesach? Pogadajmy o szczegółach. My, czyli Web Systems, od 2006 roku projektujemy aplikacje webowe i mobilne, systemy B2B, integracje oraz aplikacje AI dla biznesu. Chętnie podpowiemy, jak zbudować rozwiązanie wiarygodne, bezpieczne i gotowe na skalę. Skontaktuj się z naszym zespołem, a wspólnie zaplanujemy rozsądny, techniczny pierwszy krok.
