RAG w praktyce: jak połączyć LLM z firmową bazą wiedzy bez chaosu

Po co łączyć LLM z firmową bazą wiedzy i czym w praktyce jest RAG

Dlaczego LLM sam z siebie „nie zna” Twojej firmy

Model językowy (LLM) uczy się na ogromnych publicznych danych: stronach WWW, książkach, forach. Dzięki temu świetnie mówi po polsku, rozumie kontekst, umie streszczać, tłumaczyć, generować treści. Nie zna jednak Twoich regulaminów, procedur, umów z klientami ani wewnętrznych skrótów. Nawet jeśli w treningu trafiły się jakieś publiczne wzmianki o Twojej firmie, są przestarzałe, fragmentaryczne i niemożliwe do zaktualizowania.

LLM bez dostępu do firmowej bazy wiedzy zachowuje się więc jak bardzo inteligentny nowy pracownik: ma ogólną wiedzę o świecie, ale nie zna realiów organizacji. Bez kontekstu będzie zgadywać. To właśnie w tym miejscu pojawiają się halucynacje – odpowiedzi brzmiące pewnie, ale całkowicie błędne z punktu widzenia wewnętrznych procedur.

RAG jako most między LLM a Twoimi dokumentami

Retrieval Augmented Generation (RAG) to podejście, w którym LLM nie jest „przeuczany” na firmowych danych, lecz dostaje do promptu aktualne fragmenty dokumentów wyszukane w dedykowanej bazie wiedzy. Model nie musi „pamiętać” Twoich regulaminów – ma je podane w kontekście przy każdym pytaniu użytkownika.

To podejście ma kilka kluczowych skutków biznesowych:

• możesz aktualizować wiedzę po prostu zmieniając dokumenty, bez trenowania modelu;
• ta sama architektura obsłuży wiele obszarów: HR, IT, sprzedaż, compliance;
• łatwiej kontrolować, z czego dokładnie model korzysta (źródła, wersje dokumentów);
• możesz dość precyzyjnie ograniczyć dostęp do poufnych treści (uprawnienia, segmentacja).

W praktyce RAG to dodatkowa warstwa między użytkownikiem a bazą wiedzy: inteligentny „tłumacz” firmowych dokumentów na zrozumiałe, spójne odpowiedzi językiem naturalnym.

Główne korzyści z RAG dla organizacji

Łączenie LLM z bazą wiedzy w modelu RAG daje kilka bardzo konkretnych efektów:

• Jedno źródło prawdy w rozmowie – pracownik nie musi wiedzieć, czy szukać w SharePoincie, Confluence, na dysku sieciowym czy w intranecie. Zadaje pytanie, a system RAG „wyciąga” właściwe fragmenty z różnych miejsc.
• Mniej pytań do ekspertów – specjaliści HR, prawnik, admin systemu nie odpowiadają w kółko na te same pytania. Ich wiedza „materializuje się” w dobrze przygotowanych dokumentach, które RAG potrafi wyjaśnić językiem użytkownika.
• Szybszy onboarding – nowy pracownik zamiast „tu masz 20 linków do dokumentów, poczytaj” dostaje asystenta, który tłumaczy procedury na konkretne kroki.
• Lepszy support wewnętrzny i zewnętrzny – helpdesk IT, dział obsługi klienta, infolinia korzystają z jednego, aktualnego źródła wiedzy, a nie z prywatnych notatek i maili sprzed kilku lat.

Efekt uboczny: jeśli proces jest zaprojektowany sensownie, wdrożenie RAG wymusza porządek w dokumentach. To często pierwszy realny impuls, żeby naprawdę uporządkować wiedzę w firmie.

Typowe problemy bez RAG i jak czuje to użytkownik

Bez RAG i bez porządku w bazie wiedzy użytkownicy żyją w informacyjnym chaosie. Kilka zjawisk, które widać od razu:

• Halucynacje LLM – asystent AI wymyśla własne odpowiedzi, miesza ogólną wiedzę z domysłami. Np. „wymyśla” procedurę urlopową, bo zna ogólne przepisy KP, ale nie zna Twojego systemu benefitów.
• Sprzeczne wersje dokumentów – w obiegu są trzy różne regulaminy premiowe, w intranecie jeden, w mailu od szefa drugi, w Teamsach trzeci. Nikt nie wie, który jest aktualny.
• Ręczne przeklejanie informacji – pracownicy kopią w kilku systemach, wyciągają fragmenty tekstu i sami „składają” odpowiedź dla klienta czy współpracownika.

Jak czuje to użytkownik? Przykład z działu HR: Marta chce sprawdzić, ile dni urlopu przysługuje osobie pracującej na 3/4 etatu od kwietnia i czy może podzielić urlop na trzy części. W złym systemie:

• musi pamiętać, w którym systemie jest regulamin,
• trafi na trzy wersje dokumentu,
• AI albo odpowie ogólnikowo, albo zacznie halucynować,
• na koniec i tak pisze do HR.

W dobrym RAG Marta pisze w czacie: „Pracuję 3/4 etatu od kwietnia. Ile mam dni urlopu i czy mogę go wziąć w trzech częściach w roku?”. System:

• znajduje aktualny regulamin,
• wyciąga fragment o urlopach cząstkowych i limitach podziału,
• przelicza to na konkretne dni i scenariusz Marty,
• odpowiada jasno, z linkiem do dokumentu źródłowego.

Różnica w doświadczeniu użytkownika jest ogromna. To jest poziom, do którego trzeba mierzyć wdrożenie RAG.

Jak działa RAG od kuchni – prosty model mentalny dla nietechnicznych

Trzy etapy: zasilenie bazy, wyszukiwanie, generowanie

RAG można spokojnie zrozumieć bez znajomości niższego poziomu technicznego. Wystarczy prosty obraz trzech etapów:

1. Zasilenie bazy (ingest) – dokumenty z różnych źródeł (PDF, Word, Confluence, bilety z Jiry) są pobierane, czyszczone, dzielone na mniejsze fragmenty (chunkowanie) i zamieniane na wektory (embeddingi), a następnie trafiają do specjalnej bazy wektorowej.
2. Wyszukiwanie (retrieval) – gdy użytkownik zadaje pytanie, system również zamienia je na wektor i szuka w bazie fragmentów dokumentów najbardziej podobnych znaczeniowo do pytania.
3. Generowanie odpowiedzi (generation) – wybrane fragmenty wraz z pytaniem użytkownika są pakowane w prompt i wysyłane do LLM, który generuje końcową odpowiedź, cytując lub streszczając treści z dokumentów.

Tak naprawdę LLM jest tu „ostatnią milą”, ostatnim etapem: dostaje już przefiltrowane, istotne fragmenty wiedzy, a jego zadaniem jest połączenie ich w spójną wypowiedź. Kluczem jest jakość etapu ingest i retrieval – jeśli do LLM trafią złe lub nieaktualne fragmenty, odpowiedź będzie równie słaba.

Wektorowe wyszukiwanie vs. klasyczny full-text

Różnica między RAG a tradycyjnym wyszukiwaniem w intranecie polega na tym, jak system rozumie podobieństwo zapytań do treści dokumentów.

• Full-text – porównuje głównie ciągi znaków. Żeby znaleźć „urlop wypoczynkowy”, dokument musi zawierać te słowa lub bliskie formy. Synonimy, parafrazy, inne języki to problem.
• Wektorowe wyszukiwanie – każde zdanie, akapit czy cały dokument jest zamieniany na punkt w wielowymiarowej przestrzeni liczb. Zapytanie użytkownika również. System wyszukuje te punkty, które są najbliżej siebie w sensie semantycznym, a nie tylko leksykalnym.

Efekt: pytanie „Jak długo mogę być na L4 bez utraty wynagrodzenia?” znajdzie fragmenty o „wynagrodzeniu chorobowym”, „świadczeniach ZUS”, „zwolnieniu lekarskim”, nawet jeśli użytkownik nie użył słowa „chorobowe”. To właśnie sprawia, że RAG może dawać trafne odpowiedzi na „ludzkie” pytania, a nie tylko na słowa kluczowe.

Granica między RAG a samym LLM

W pewnym momencie musi zadziałać sam model językowy. Granica przebiega w momencie, kiedy mamy już:

• pytanie użytkownika,
• zestaw wybranych fragmentów dokumentów (kontekst),
• instrukcję (prompt) mówiącą, jak model ma z tych danych skorzystać.

Od tego miejsca LLM:

• łączy informacje z różnych fragmentów,
• uzupełnia brakujące „kleje językowe” (spójniki, wyjaśnienia),
• czasem dokonuje prostych wyliczeń lub wnioskowania,
• formatuje odpowiedź tak, by była czytelna.

Ważna zasada: LLM nie powinien „wymyślać” niczego poza tym, co jest zawarte w dokumentach lub wprost wynika z reguł. To kwestia odpowiednio zaprojektowanego promptu: „Odpowiadaj wyłącznie na podstawie dostarczonych dokumentów. Jeśli brakuje danych, napisz wprost, że nie możesz jednoznacznie odpowiedzieć.”

Wpływ decyzji biznesowych na skuteczność techniczną

Dla jakości RAG równie ważne, jak dobór modeli, są decyzje typowo organizacyjne:

• Jakie dokumenty w ogóle trafiają do systemu – jeśli baza wiedzy zawiera śmieci, duplikaty i sprzeczne wersje, żaden algorytm tego nie naprawi.
• Kto jest właścicielem treści – bez odpowiedzialności za aktualność dokumentów RAG będzie powielał stare lub błędne informacje.
• Jak wygląda cykl życia dokumentu – czy ma datę ważności, wersjonowanie, proces przeglądu?

Technologia liczy się oczywiście, ale to porządek organizacyjny decyduje, czy RAG stanie się realną pomocą, czy tylko ładnym interfejsem do starych błędów.

Warstwa RAG jako bufor między ludźmi a dokumentami

Najprostszy mentalny schemat: pracownicy nie „idą” już bezpośrednio do SharePointa czy Confluence, tylko rozmawiają z asystentem. Asystent:

• wie, gdzie szukać dokumentów,
• rozumie uprawnienia użytkownika,
• transformuje język naturalny na zapytania do bazy wektorowej,
• wyciąga właściwe fragmenty i tłumaczy je na ludzki język.

RAG nie zastępuje źródeł. Dodaje warstwę, która sprawia, że dostęp do wiedzy jest wygodny, spójny i zrozumiały nawet dla osoby, która jest pierwszy dzień w firmie.

Przypadki użycia RAG w firmie – kiedy ma to sens, a kiedy lepiej odpuścić

Obszary, gdzie RAG przynosi szybkie efekty

Nie każdy proces nadaje się tak samo dobrze na start. RAG szczególnie sprawdza się tam, gdzie:

• jest dużo tekstowych dokumentów,
• pytania są powtarzalne,
• błąd nie niesie natychmiastowej katastrofy prawnej.

Typowe „wdzięczne” obszary:

• FAQ dla klientów – warunki umów, tabela opłat, proces reklamacji, terminy dostaw. Asystent może podać klientowi odpowiedź opartą wprost na regulaminach, zamiast liczyć na pamięć konsultanta.
• Helpdesk IT – reset haseł, dostęp do systemów, instrukcje konfiguracji VPN czy poczty. Zamiast 10 stron rozproszonych tutoriali – jedno miejsce, w którym RAG zestawia wyciągi z instrukcji.
• HR: regulaminy, benefity, procesy – urlopy, praca zdalna, rozliczanie delegacji, program poleceń pracowniczych. Idealne pole do eksperymentu, bo pytania są częste, a odpowiedzi są oparte na spisanych regulacjach.
• Wsparcie sprzedaży – parametry produktów, różnice między wariantami ofert, wymagane dokumenty. Handlowiec może „rozmawiać” z bazą wiedzy zamiast szukać informacji w slajdach.
• Compliance i polityki wewnętrzne – polityka bezpieczeństwa, RODO, zasady przetwarzania danych. RAG może szybko podać fragmenty dokumentów dotyczące konkretnej sytuacji.

Sygnały, że organizacja jest gotowa na RAG

Zanim zaczniesz, sprawdź kilka warunków brzegowych. Pozytywne sygnały:

• istnieje jakakolwiek spójniejsza baza wiedzy (nawet nieidealna) – np. dział HR faktycznie trzyma regulaminy w jednym miejscu,
• widzisz masę powtarzalnych pytań (do HR, IT, działu prawnego, obsługi klienta),
• jest gotowość do uporządkowania treści – ktoś deklaruje się, że będzie właścicielem dokumentów,
• IT rozumie, jak podłączyć systemy źródłowe i jak zadbać o bezpieczeństwo danych,
• istnieje konkretny proces, który chcesz przyspieszyć lub odciążyć, a nie tylko „chcemy mieć AI”.

Jeśli przynajmniej część z tego jest spełniona, sensowny pilotaż RAG ma duże szanse powodzenia.

Kiedy RAG może zrobić więcej szkody niż pożytku

Są jednak sytuacje, w których lepiej się wstrzymać lub mocno ograniczyć zakres:

• Totalny bałagan w dokumentach – regulaminy „w załącznikach do maili”, brak wersjonowania, brak informacji, co jest aktualne. RAG tylko przyspieszy rozprzestrzenianie nieporządku.

Procesy wysokiego ryzyka – gdzie trzeba hamulca bezpieczeństwa

Są obszary, gdzie RAG powinien być tylko pomocą dla eksperta, a nie samodzielnym „decydentem”:

• Decyzje kredytowe, underwriting, scoring ryzyka – RAG może zebrać informacje, wyjaśnić zapisy w umowie, ale decyzja powinna zostać po stronie człowieka lub twardego silnika reguł.
• Interpretacje prawne „na styk” – jeśli sprawa może trafić do sądu, asystent RAG może wskazać paragrafy, komentarze, orzecznictwo, ale nie powinien wydawać ostatecznej oceny.
• Bezpieczeństwo i operacje krytyczne – zmiany w konfiguracji systemów produkcyjnych, reguły firewalli, procedury awaryjne. RAG jako podpowiedź, nie jako silnik, który wydaje polecenia automatycznie.

W takich miejscach rola RAG jest jasno pomocnicza: przygotowuje kontekst, podpowiada dokumenty, generuje draft, ale nie ma „ostatniego słowa”.

Jak nie używać RAG – typowe antywzorce

Przy projektach RAG powtarzają się te same błędy. Dobrze je mieć na radarze:

• „Zasilmy wszystko na wszelki wypadek” – ładowanie całego SharePointa bez selekcji. Efekt: szum, sprzeczne wersje, więcej frustracji niż pożytku.
• Brak kontroli wersji – system nie wie, który regulamin jest aktualny. Użytkownik dostaje odpowiedź na podstawie starego PDF-a.
• Brak trybu „nie wiem” – model zawsze coś odpowiada. Zaufanie do narzędzia spada po pierwszej ewidentnej bzdurze.
• Zero monitoringu – brak logów pytań, brak mechanizmu zgłaszania błędów, brak właściciela, który reaguje.

RAG, który nie ma granic i opiekuna, szybko zamienia się w kreatywną, ale niebezpieczną zabawkę.

Przygotowanie bazy wiedzy pod RAG – porządek zanim wejdzie AI

Inwentaryzacja: co w ogóle mamy i gdzie to leży

Zanim pojawi się jakiekolwiek API, trzeba wiedzieć, z czego RAG ma korzystać. Podstawowy przegląd:

• lista głównych systemów: SharePoint, Confluence, dyski sieciowe, CRM, ticketing,
• typy dokumentów: regulaminy, instrukcje, procedury, szablony, Q&A,
• miejsca „shadow knowledge”: Excela „pani Kasi”, prywatne dyski, notatniki zespołów.

Dobrze działa proste ćwiczenie warsztatowe z kluczowymi działami: „Gdzie dziś szukasz odpowiedzi na pytania pracowników/klientów?”. Lista źródeł, która powstaje, zwykle otwiera oczy.

Minimalne standardy dokumentów, zanim trafią do RAG

Nie trzeba robić totalnego re-engineeringu bazy wiedzy. Wystarczą minimalne standardy, żeby RAG miał z czym pracować:

• Jeden dokument = jeden temat – zamiast „Regulamin + procedury + FAQ w jednym PDF-ie”. Łatwiej potem sensownie chunkować.
• Wyraźny tytuł i data – najlepiej w treści, nie tylko w nazwie pliku. LLM widzi to, co jest w środku.
• Właściciel merytoryczny – nazwa roli/zespołu, nie osoby („HR Operations”, „Compliance”).
• Wersja i status – np. „v3.2, obowiązuje od 2024-01-01”. To potem może trafić do promptu jako filtr.

Nawet jeśli na początku obejmie to tylko część dokumentów (np. HR + Helpdesk), już daje ogromną różnicę.

Sprzątanie treści: co wyrzucić, co zarchiwizować, co zostawić

Nie wszystko powinno wejść do indeksu RAG. Szybka trzystopniowa klasyfikacja przy przeglądzie:

• Do użycia – aktualne, potrzebne, w miarę spójne dokumenty. Trafiają do indeksu.
• Do archiwum – historii nie kasujemy, ale odcinamy z wyszukiwania produkcyjnego. Można przechowywać w osobnej „warstwie historycznej”.
• Do kosza – duplikaty, wersje robocze, prywatne notatki sprzed lat, które już dawno nie obowiązują.

Jeśli zespół nie jest w stanie sam tego ocenić, dobrym trikiem jest ustawienie „daty przydatności” – jeśli nikt nie otworzył dokumentu od dwóch lat i nie dotyczy to regulacji prawnych, najczęściej można go bezpiecznie wyłączyć z indeksowania.

Metadane – mały wysiłek, duża dźwignia

RAG oparty wyłącznie na pełnym tekście zadziała, ale dopiero metadane pozwalają go ucywilizować. Przy wprowadzaniu dokumentów opłaca się zadbać przynajmniej o:

• typ dokumentu – regulamin, procedura, instrukcja, szablon, FAQ,
• obszar biznesowy – HR, IT, sprzedaż, finansy, prawo,
• kraj/jurysdykcja – przy firmach wielonarodowych to krytyczne,
• jeden jasny tag odpowiedzialności – kto zatwierdza zmiany.

Te pola można potem wykorzystać w warstwie retrieval (np. „szukaj tylko w dokumentach HR dla Polski”) lub w samym promptcie.

Uprawnienia i klasyfikacja informacji

RAG nie może obchodzić polityki dostępu. Inaczej prędzej czy później wyciągnie poufną treść osobie, która nie powinna jej widzieć. Przygotowując bazę:

• upewnij się, że system źródłowy ma sensowny model uprawnień (grupy, role, działy),
• przy zasilaniu bazy wektorowej przenoś informację o tym, kto może dany dokument widzieć,
• rozważ prostą klasyfikację: publiczne dla wszystkich, dostępne dla wybranych działów, poufne (w ogóle nie indeksowane).

Technicznie to „tylko” filtr, ale organizacyjnie wymaga decyzji: które zbiory wiedzy w ogóle biorą udział w projekcie RAG.

Cykle życia treści – bez tego RAG zestarzeje się po pół roku

Nawet najlepiej zindeksowana baza wiedzy zgnije, jeśli nikt o nią nie dba. Minimum procesowe:

• przeglądy okresowe – np. raz na kwartał listy dokumentów „do sprawdzenia” przez właścicieli,
• oznaczanie dokumentów wygasających – np. procedury COVID, tymczasowe promocje,
• łatwy kanał zgłaszania błędów – przy samym asystencie przycisk „Odpowiedź jest błędna / nieaktualna”.

Strumień takich zgłoszeń to cenne dane: które obszary wymagają doprecyzowania lub przebudowy dokumentów.

Projektowanie architektury RAG – od prostego POC do stabilnego rozwiązania

Pierwszy etap: POC na jednym obszarze biznesowym

Najbezpieczniej zacząć od małego, kontrolowanego wycinka. Typowy zestaw startowy:

• jeden obszar (np. HR lub Helpdesk IT),
• kilkadziesiąt–kilkaset kluczowych dokumentów,
• kilkanaście osób testowych z tego działu i z „klientów” działu (np. menedżerowie, pracownicy),
• jeden kanał interakcji – najprostszy: aplikacja webowa z polem na pytanie.

Na tym etapie celem nie jest pełna automatyzacja, tylko odpowiedź na pytanie: „Czy z naszej konkretnej bazy wiedzy da się wyciągnąć sensowne odpowiedzi?”.

Minimalna architektura techniczna POC

Nawet prosty POC ma kilka podstawowych klocków:

• moduł ingest – skrypt lub mała usługa, która ściąga dokumenty, czyści je, chunkuje i zapisuje w bazie wektorowej,
• baza wektorowa – komercyjna (np. Azure AI Search) lub open-source (np. Qdrant, Weaviate),
• LLM z API – np. model hostowany w chmurze lub on-prem w zależności od polityki danych,
• prosty backend – który obsługuje zapytania użytkownika, odpytuje bazę wektorową, buduje prompt i woła LLM,
• interfejs użytkownika – webowy chat, Teams/Slack bot albo wtyczka w intranecie.

Oprócz tego warto od razu włączyć logowanie: pytanie, użyte dokumenty, odpowiedź, flaga „użytkownik zadowolony/niezadowolony”. To podstawa do iteracji.

Od POC do pilotażu – co musi się zmienić

Gdy POC pokaże, że odpowiedzi są sensowne, w kolejnym kroku trzeba przejść z „zabawy w piaskownicy” na narzędzie rzeczywiście używane. Dodatkowe elementy, które zwykle pojawiają się na tym etapie:

• integracja z SSO – użytkownik loguje się swoim kontem firmowym, a system zna jego rolę i dział,
• wdrożenie polityk uprawnień – filtrowanie dokumentów na etapie retrieval,
• monitoring wydajności – czas odpowiedzi, obciążenie, koszty zapytań do LLM,
• panel administracyjny – podgląd logów, zarządzanie źródłami, ręczne reindeksowanie.

Pilot to też moment, w którym warto zdefiniować KPI: skrócenie czasu odpowiedzi, zmniejszenie liczby ticketów, satysfakcja użytkowników.

Architektura produkcyjna – na co zwrócić uwagę

Przy wyjściu na całą organizację dochodzi kilka tematów „inżynieryjnych”:

• skalowanie – więcej użytkowników = więcej zapytań. Trzeba ustawić autoskalowanie backendu i bazy wektorowej, zadbać o limitowanie ruchu.
• separacja środowisk – dev/test/prod, żeby zmiany w ingest lub promptach nie psuły działania użytkownikom,
• bezpieczeństwo – szyfrowanie danych, audyt zapytań, zgodność z wewnętrznymi wytycznymi bezpieczeństwa i regulacjami (np. RODO),
• backup i disaster recovery – kopie bazy wektorowej, skrypty do odtworzenia indeksu z oryginalnych źródeł.

Na tym etapie RAG staje się normalną aplikacją korporacyjną, a nie „projektem innowacyjnym”. To wymaga włączenia standardowych procesów IT.

Wersjonowanie promptów i reguł

Prompt to nowy rodzaj „kodu biznesowego”. Zmiana jednego zdania potrafi radykalnie zmienić zachowanie systemu. Warto szybko wprowadzić:

• repozytorium promptów (np. w Git),
• opis kontekstu: do jakiego scenariusza jest dany prompt,
• procedurę testowania zmian – np. zbiór stałych pytań regression test.

Przy bardziej złożonych systemach stosuje się osobne prompty dla różnych ról: inny dla HR, inny dla IT, inny dla klienta końcowego. Architektura musi to uwzględniać.

Kluczowe elementy techniczne w praktyce: chunkowanie, embeddingi, wyszukiwanie

Chunkowanie – jak pociąć dokument, żeby nie zabić sensu

LLM nie widzi całych dokumentów, tylko fragmenty. To, jak je potniesz, ma ogromny wpływ na jakość odpowiedzi. Kilka praktycznych zasad:

• unikać zbyt małych kawałków – pojedyncze zdania tracą kontekst, szczególnie w regulaminach i procedurach,
• wspierać się strukturą dokumentu – nagłówki, sekcje, podrozdziały to naturalne granice chunków,
• dopuszczać lekkie nakładanie fragmentów – np. ostatni akapit chunku A powtarza się jako pierwszy w chunku B, żeby zachować spójność.

W praktyce sprawdza się chunk o wielkości od kilkuset do kilku tysięcy znaków, ale trzeba to przetestować na własnych dokumentach. Regulaminy wymagają innych ustawień niż instrukcje krok po kroku.

Różne strategie chunkowania dla różnych typów treści

Zamiast jednego algorytmu warto rozróżnić typy dokumentów:

• procedury i instrukcje – chunk per krok lub sekcja („Zgłaszanie urlopu”, „Rozliczanie delegacji”),
• FAQ – chunk „pytanie + odpowiedź” jako całość,
• regulaminy prawne – chunk per artykuł/paragraf lub sekcja tematyczna,
• prezentacje – chunk per slajd lub grupę slajdów o tej samej tematyce.

Często opłaca się dodać do każdego chunku „nagłówek syntetyczny” generowany przez LLM: jedno zdanie opisujące, czego dotyczy fragment. To zwiększa trafność wyszukiwania.

Embeddingi – jak wybrać model i co tak naprawdę znaczą

Embedding to zamiana tekstu na wektor liczb. Kluczowe decyzje:

Dobór modelu embeddingów do scenariusza biznesowego

Przy wyborze modelu embeddingów lepiej zacząć od pytania „do czego używamy RAG?”, niż od tabelki z benchmarkami. Inne wymagania ma asystent do regulaminów HR, inne – do dokumentacji API.

• Język – jeżeli większość treści i pytań jest po polsku, szukaj modeli dobrze radzących sobie z PL (multilingual lub dedykowane). Mieszanka PL/EN też jest do ogarnięcia, ale warto to przetestować.
• Rodzaj treści – do kontraktów i regulaminów przyda się model „rozumiejący” długie zdania i prawnicze konstrukcje, do ticketów helpdesku i e‑maili wystarczą lżejsze modele.
• Budżet i miejsce uruchomienia – embeddingi w chmurze są wygodne, ale kosztują i wysyłają tekst na zewnątrz. Lokalne/open‑source dają większą kontrolę, ale wymagają zasobów i utrzymania.

Dobrą praktyką jest przygotowanie małego zbioru testowego: kilkadziesiąt realnych pytań z firmy + oczekiwane dokumenty. Na tym porównasz 2–3 modele i wybierzesz ten, który faktycznie trafia najlepiej, a nie tylko „wygrał benchmark na Wikipedii”.

Parametry embeddingów, które realnie mają znaczenie

Większość opisów modeli zasypuje technikaliami. W praktyce dla zespołu wdrożeniowego przydają się trzy parametry:

• długość kontekstu – ile tokenów tekstu model potrafi „zjeść” naraz. Jeżeli chunkujesz na 2–3 tys. znaków, większość modeli będzie OK, ale przy długich paragrafach prawnych limit bywa barierą,
• wymiar wektora – 384, 768, 1024, 3072 itd. Większy wymiar = potencjalnie dokładniejsze odwzorowanie, ale też większa baza (więcej RAM/dysku) i minimalnie wolniejsze wyszukiwanie,
• koszt przeliczenia – ważne przy dużych migracjach. Licz koszt jednorazowego zindeksowania wszystkich dokumentów + koszt bieżącego dowożenia nowych treści.

Jeżeli zespół nie ma dużego doświadczenia z embeddingami, rozsądny start to model średniej wielkości, dobrze udokumentowany i łatwy do podmiany. Architektura ingestu powinna zakładać, że kiedyś przeindeksujesz wszystko innym modelem.

Wersjonowanie embeddingów i reindeksacja

Modele embeddingów się zmieniają. Dostawcy wypuszczają nowe wersje, pojawiają się lepsze modele open‑source. Jeżeli system ma żyć więcej niż rok, trzeba założyć „zmianę silnika w locie”.

• zapisuj w bazie wersję modelu, którym pocięto i zembedowano dany dokument,
• utrzymuj pipeline reindeksacji – proces, który może w tle przeliczyć całą bazę innym modelem bez blokowania użytkowników,
• testuj nowy model na tym samym zbiorze pytań, na którym wybierałeś pierwszy – wtedy porównanie jest uczciwe.

Częsty wzorzec: w produkcji trzymasz jedną aktywną wersję embeddingów, a nową budujesz w osobnym indeksie. Po testach i porównaniu jakości przepinasz ruch na nowy indeks, stary trzymasz jeszcze chwilę „na wszelki wypadek” i dopiero potem kasujesz.

Wyszukiwanie wektorowe w praktyce – nie tylko „najbliższe sąsiady”

Najprostszy scenariusz: bierzemy embedding pytania, szukamy najbliższych wektorów (top‑k) w bazie, gotowe. W realnej firmie przydają się jednak dodatkowe mechanizmy.

• Filtrowanie po metadanych – kraj, dział, typ dokumentu, data obowiązywania. Bez tego asystent HR dla Polski będzie wyciągał regulaminy z innego rynku.
• Re-ranking – najpierw wyniki według podobieństwa wektorowego, potem drobna korekta na bazie innych kryteriów (np. świeżości dokumentu, typu, ważności).
• Wsparcie BM25 / full‑text – w niektórych przypadkach zwykłe wyszukiwanie tekstowe lepiej łapie rzadkie skróty, numery formularzy, symbole umów.

Praktyczny kompromis to tzw. hybrid search: łączysz score z wyszukiwania semantycznego (embedding) i słownikowego (BM25), np. prostą formułą lub re‑rankerem. Dzięki temu użytkownik, który wpisze „wniosek ZUS Z‑3” dostanie właściwy formularz, a nie losowy dokument o zbliżonej tematyce.

Dobór liczby wyników i progi podobieństwa

Liczy się nie tylko jak szukasz, ale też ile wyników podajesz LLM‑owi i przy jakim „score” przestajesz ufać wyszukiwaniu.

• top‑k – najczęściej 5–20 wyników. Im więcej, tym większa szansa, że wśród nich jest coś trafnego, ale rośnie też szum i koszt promptu.
• próg podobieństwa – jeżeli wszystkie wyniki są „daleko” od pytania, lepiej uczciwie przyznać: „nie znalazłem nic sensownego w bazie” niż generować halucynacje.

Ustawienie tych parametrów w ciemno rzadko działa. Najprostszy sposób: logować score każdego dopasowania i ręcznie obejrzeć próbkę pytań/odpowiedzi. Po kilkudziesięciu przykładach widać, przy jakim progu zaczyna się „śmietnik”.

Kontekst do promptu – jak podawać fragmenty dokumentów LLM‑owi

Sama selekcja chunków to dopiero połowa drogi. Druga to sposób, w jaki wstrzykniesz je do promptu. Kilka praktyk, które poprawiają jakość odpowiedzi:

• jasne oznaczenie źródeł – każdy fragment z podpisem typu „[Źródło: Regulamin benefitów, sekcja 3.2]”. Model łatwiej odwołuje się do konkretnych dokumentów, a ty możesz to później pokazać użytkownikowi.
• instrukcja priorytetu – w system message jasno napisz, że model ma opierać się wyłącznie na podanych źródłach i nie dopowiadać z pamięci, gdy ma wątpliwości.
• limit długości kontekstu – nie pakuj wszystkiego jak leci. Przekroczenie kontekstu modelu kończy się ucinaniem fragmentów w losowych miejscach.

Dobry wzorzec promptu obejmuje: krótką rolę („Jesteś asystentem HR…”), instrukcję korzystania ze źródeł, wstrzyknięte chunki i dopiero poniżej pytanie użytkownika. W logach warto przechowywać pełny prompt, żeby móc później „rozebrać” dziwne odpowiedzi.

Strategie redukcji kontekstu przy dużych dokumentach

Przy bardzo obszernych regulaminach lub umowach nawet 20 chunków może nie wystarczyć. Wtedy proste „weź top‑k i włóż do promptu” zaczyna się sypać. Pomagają dwustopniowe strategie:

• coarse‑to‑fine – najpierw wyszukiwanie po krótszych, „meta” embeddingach sekcji (np. nagłówki + streszczenia), potem dogłębne szukanie tylko w wybranych sekcjach,
• query expansion – LLM najpierw przekształca pytanie użytkownika na 2–3 bardziej techniczne zapytania (np. z dodanymi słowami „okres wypowiedzenia”, „umowa na czas określony”), które lepiej trafiają w treść dokumentów.

Taki dodatkowy krok wydłuża czas odpowiedzi o ułamki sekundy, ale bywa różnicą między „nie znam odpowiedzi” a konkretną, poprawną informacją.

Obsługa wielu źródeł i typów danych

W firmach zwykle nie ma jednej, pięknej bazy wiedzy. Jest SharePoint, Jira, Confluence, dyski sieciowe, czasem CRM i system ticketowy. RAG musi to poskładać w jeden spójny widok.

• normalizacja metadanych – różne systemy mają różne pola (owner, project, team). Trzeba zaprojektować wspólny „słownik”: dział, kraj, język, status dokumentu, poziom poufności.
• jeden poziom abstrakcji w bazie wektorowej – każdy chunk dostaje ten sam zestaw pól meta, niezależnie od źródła. Dzięki temu reguły filtrowania i uprawnień są proste.
• rozwiązanie duplikatów – te same treści potrafią żyć w pięciu miejscach. Lepiej jasno wybrać „kanoniczne” źródło niż liczyć, że model sobie poradzi.

Przykład z praktyki: polityka pracy zdalnej była w HR na SharePoint, w intranecie i w prezentacji z all‑hands. Po wdrożeniu RAG w każdej odpowiedzi wracały trzy wersje zasad. Ratunkiem było oznaczenie jednej wersji jako obowiązującej i wyłączenie pozostałych ze źródeł indeksowania.

Monitorowanie jakości odpowiedzi oparte na retrieval

Typowe wskaźniki używane przy klasycznych chatbotach (liczba rozmów, średnia długość, CSAT) nie wystarczą. W RAG dochodzi kluczowa warstwa: retrieval.

• hit rate – w ilu procentach zapytań system znajduje jakiekolwiek sensowne chunki (powyżej ustalonego progu podobieństwa),
• źródła używane w odpowiedziach – czy system opiera się na aktualnych, „kanonicznych” dokumentach, czy na starych wersjach i załącznikach z maili,
• analityka „brak odpowiedzi” – pytania, na które model uczciwie odpowiada „nie mam informacji”. To często lista braków w bazie wiedzy.

Raz na jakiś czas opłaca się przeprowadzić ręwną ocenę na próbce logów: analityk lub właściciel procesu sprawdza losowe rozmowy, ocenia trafność retrieval i treści odpowiedzi. Taki audyt bywa bardziej wartościowy niż kolejne dziesiąte miejsca po przecinku w metrykach.

Zarządzanie kosztami – gdzie naprawdę „ucieka budżet”

Koszty RAG to nie tylko zapytania do LLM. Przy większej skali potrafią zaskoczyć też inne elementy:

• częsta reindeksacja – jeżeli ingest chodzi codziennie na całą flotę dokumentów, a nie tylko na zmiany, rachunek za embeddingi szybko rośnie,
• nadmiernie duże chunki – dłuższe fragmenty = droższe zapytania do LLM (więcej tokenów w kontekście),
• zbyt wysoki top‑k – pakowanie do promptu 30 chunków „bo czemu nie” też swoje kosztuje.

Prosty zestaw kontroli: limity długości odpowiedzi, maksymalna liczba chunków w promptach, sensowny harmonogram ingestu przyrostowego, a do tego dashboard z estymacją kosztu per dział/źródło. Pozwala to szybko wyłapać np. jedną integrację, która codziennie przepuszcza przez embeddingi cały archiwalny katalog.

Bezpieczeństwo promptów i ochrona przed wyciekiem informacji

RAG w firmie nie działa w próżni. Użytkownicy potrafią pytać o wszystko, a modele – kreatywnie wykorzystywać kontekst. W efekcie przy nieostrożnym zaprojektowaniu promptu można ułatwić wyciek danych.

• jasne ograniczenia w system prompt – np. zakaz generowania haseł, kluczy API, instrukcji obchodzenia uprawnień czy porad dotyczących „hakowania” systemów.
• maskowanie wrażliwych danych w logach – numery PESEL, NIP, dane kart płatniczych. Część można wykryć prostymi regexami, część – modelem NER.
• policy enforcement – prosty filtr na wejściu, który blokuje lub oznacza zapytania naruszające polityki bezpieczeństwa (np. prośby o listę pensji, dane konkretnego pracownika).

W połączeniu z audytem logów i integracją z systemami SIEM taki asystent staje się bezpiecznym narzędziem wewnętrznym, a nie nowym wektorem ataku.

Iteracyjne doskonalenie RAG – pętla uczenia z użytkownikami

Najlepsze wdrożenia RAG nie kończą się na „go‑live”. Działają w pętli:

1. zbieranie pytań i feedbacku (flagi „trafione/nie trafione”, raporty o błędach),
2. analiza, czy problem był w retrieval (złe chunki, brak dokumentu), w promptowaniu, czy w bazie wiedzy,
3. konkretna akcja: poprawa chunkowania, dopisanie brakującej sekcji w regulaminie, korekta promptu, zmiana filtrów,
4. powtórne testy na historycznych pytaniach.

Dobry znak: po kilku miesiącach w logach coraz częściej pojawiają się pytania, których wcześniej w ogóle nie było. To znaczy, że użytkownicy poczuli, że asystent faktycznie im pomaga i próbują przerzucić na niego kolejne kawałki codziennej pracy.

Najczęściej zadawane pytania (FAQ)

Co to jest RAG i czym różni się od „zwykłego” użycia ChatGPT w firmie?

RAG (Retrieval Augmented Generation) to sposób pracy z LLM, w którym model dostaje do promptu aktualne fragmenty firmowych dokumentów wyszukane z bazy wiedzy. Nie „uczy się” ich na stałe, tylko ma je pod ręką przy każdym pytaniu użytkownika.

Kluczowa różnica: zwykły ChatGPT odpowiada na bazie ogólnej wiedzy z internetu i swojej „pamięci” treningowej. W RAG odpowiedź powstaje głównie na bazie Twoich dokumentów – regulaminów, procedur, umów – dołączonych jako kontekst. Dzięki temu:

• model zna realia Twojej firmy, a nie tylko przepisy ogólne,
• łatwo aktualizujesz wiedzę, zmieniając dokument, a nie trenując model,
• masz kontrolę, z jakich źródeł odpowiedź została złożona.

Dlaczego LLM bez RAG halucynuje na tematy firmowe?

Model językowy nie ma dostępu do Twojego intranetu, SharePointa czy dysku sieciowego. Zna jedynie ogólne wzorce z publicznych danych. Jeśli pytasz o szczegółowe procedury, regulaminy, benefity czy konkretne umowy, będzie po prostu zgadywał na podstawie ogólnej wiedzy.

Efekt w praktyce: model potrafi poprawnie wyjaśnić Kodeks pracy, ale „wymyśla” zasady Twojego systemu premiowego albo urlopów, bo nigdy ich nie widział. RAG ogranicza to zjawisko, bo zamiast zgadywania model dostaje dokładne fragmenty Twoich dokumentów i ma wyraźną instrukcję, by trzymać się tylko tego kontekstu.

Jak RAG łączy LLM z firmową bazą wiedzy od strony działania?

Proces można uprościć do trzech kroków:

• Zasilenie bazy – dokumenty z różnych źródeł są pobierane, czyszczone, dzielone na mniejsze kawałki i zamieniane na wektory w bazie wektorowej.
• Wyszukiwanie – pytanie użytkownika też jest zamieniane na wektor, a system szuka fragmentów treści najbardziej podobnych znaczeniowo (nie tylko po słowach kluczowych).
• Generowanie – znalezione fragmenty trafiają razem z pytaniem do LLM, który buduje z nich spójną, ludzką odpowiedź.

LLM jest tu „ostatnią milą”: nie szuka w dokumentach, tylko składa odpowiedź z tego, co zostało mu wcześniej dobrane.

Jakie realne korzyści biznesowe daje wdrożenie RAG w organizacji?

Najbardziej odczuwalne efekty to:

• Jedno miejsce do zadawania pytań – pracownicy nie błądzą po SharePoincie, Confluence i dyskach sieciowych, tylko piszą pytanie w jednym czacie.
• Mniej powtarzalnych pytań do ekspertów – HR, prawnicy, IT nie odpowiadają 50 razy na to samo, bo wiedza jest dobrze opisana w dokumentach i podana przez RAG w prostym języku.
• Szybszy onboarding – nowy pracownik nie dostaje paczki linków, tylko asystenta, który tłumaczy regulaminy na konkretne kroki.
• Spójny support – helpdesk i obsługa klienta korzystają z jednego, aktualnego źródła prawdy, zamiast z prywatnych notatek.

Dodatkowy efekt: wdrożenie RAG zwykle wymusza uporządkowanie dokumentów i wersji regulaminów.

Czym różni się wyszukiwanie wektorowe w RAG od zwykłego full-text w intranecie?

Klasyczne wyszukiwanie full-text działa po słowach kluczowych. Jeśli w pytaniu nie użyjesz dokładnie tych samych słów, co w dokumencie, wyniki często będą słabe lub losowe. System patrzy głównie na ciągi znaków.

Wyszukiwanie wektorowe reprezentuje treści jako punkty w wielowymiarowej przestrzeni. Zapytań i dokumentów nie porównuje się po słowach, tylko po znaczeniu. Przykład: pytanie „Jak długo mogę być na L4 bez utraty wynagrodzenia?” znajdzie fragmenty o „wynagrodzeniu chorobowym” i „świadczeniach ZUS”, nawet jeśli nigdzie nie ma skrótu „L4”. Dzięki temu RAG radzi sobie z naturalnym, potocznym językiem użytkownika.

Czy do wdrożenia RAG muszę trenować własny model AI?

Nie. W podejściu RAG zazwyczaj korzystasz z gotowego modelu LLM (np. przez API), a cała „firmowa wiedza” jest trzymana poza nim – w bazie dokumentów i bazie wektorowej. Model dostaje tę wiedzę w promptach na bieżąco.

Trening własnego modelu ma sens tylko w specyficznych przypadkach (np. bardzo duża skala, silnie specjalistyczna domena, wymagania regulacyjne). W większości organizacji większy zwrot z inwestycji da:

• uporządkowanie dokumentów,
• dobre zasilenie i aktualizację bazy,
• sensowne zaprojektowanie uprawnień i kontekstu w RAG.

Jak zacząć wdrożenie RAG w firmie w praktyce?

Dobry start to mały, konkretny obszar, np. odpowiedzi na pytania o urlopy, benefity albo wewnętrzne procedury IT. Praktyczna mini-checklista:

• Wybierz jeden proces z dużą liczbą powtarzalnych pytań.
• Zbierz i uporządkuj aktualne dokumenty (jedna wersja prawdy).
• Skonfiguruj pipeline „ingest” – wczytanie, czyszczenie, podział na fragmenty.
• Podłącz LLM z jasnym promptem: odpowiadaj tylko na podstawie dostarczonych dokumentów.
• Przetestuj na realnych pytaniach pracowników, dopracuj źródła i podział fragmentów.

W kolejnym kroku możesz rozszerzać RAG na kolejne działy i typy dokumentów, zachowując tę samą architekturę.

Kluczowe Wnioski

• LLM bez dostępu do firmowej bazy wiedzy działa jak nowy, inteligentny pracownik: zna ogólne zasady i język, ale nie zna regulaminów, procedur ani realiów konkretnej organizacji, przez co łatwo generuje halucynacje.
• RAG tworzy „most” między LLM a dokumentami firmy: zamiast trenować model na wewnętrznych danych, dostarcza mu przy każdym pytaniu odpowiednie fragmenty aktualnych dokumentów, które stają się kontekstem do odpowiedzi.
• Architektura RAG daje wymierne korzyści biznesowe: jedno źródło prawdy dla użytkownika, mniejszą liczbę powtarzalnych pytań do ekspertów, szybszy onboarding i spójniejszy support wewnętrzny oraz zewnętrzny.
• Dobrze wdrożony RAG wymusza porządek w dokumentach: trzeba ustalić aktualne wersje, zintegrować różne źródła (SharePoint, Confluence, dyski, systemy ticketowe) i jasno opisać procedury, co samo w sobie poprawia zarządzanie wiedzą.
• Doświadczenie użytkownika zmienia się diametralnie: zamiast szukać regulaminu w kilku systemach i weryfikować trzy wersje dokumentu, użytkownik zadaje pytanie w języku naturalnym i dostaje konkretną odpowiedź z odwołaniem do źródła.
• RAG opiera się na trzech kluczowych etapach: przygotowaniu bazy (ingest, czyszczenie, chunkowanie, embeddingi), wyszukiwaniu wektorowym (retrieval) oraz generowaniu odpowiedzi przez LLM na podstawie znalezionych fragmentów.
• Jakość RAG zależy głównie od etapu ingest i retrieval: jeśli do modelu trafią nieaktualne lub źle dobrane fragmenty, nawet najlepszy LLM wygeneruje mylące odpowiedzi, dlatego kluczowa jest dobra selekcja i aktualizacja treści.