Jak przygotować dane firmowe pod AI i RAG

Firmy, które wdrożyły firmowego asystenta AI zbyt szybko, często raportują ten sam problem: model odpowiada nieprecyzyjnie albo cytuje nieaktualne procedury sprzed dwóch lat. Przyczyną rzadko jest zły model. Przyczyną jest nieuporządkowana baza danych wejściowych. Zanim wybrany LLM dostanie dostęp do wiedzy firmowej, ta wiedza musi zostać odpowiednio oczyszczona, podzielona i zindeksowana. To praca przed wdrożeniem, nie po nim.

RAG działa na prostej zasadzie: gdy użytkownik zadaje pytanie, system wyszukuje fragmenty Waszej wiedzy, które pasują semantycznie, a potem podaje je modelowi jako kontekst do sformułowania odpowiedzi. Model nie wymyśla treści — odpowiada wyłącznie na podstawie tego, co znajdzie w indeksie.

Konsekwencja jest bezpośrednia: jeśli w indeksie jest sprzeczna informacja (np. dwa warianty tej samej procedury, z których jeden jest nieaktualny), model może zacytować każdą z nich zależnie od tego, który fragment trafi wyżej w rankingu. Jeśli dokument jest zeskanowanym PDF-em bez warstwy tekstowej, model go w ogóle nie zobaczy. Jeśli tabele z cenami są w arkuszach Excela nieprzetłumaczonych na tekst, asystent nie będzie w stanie podać wartości z tych tabel.

Dobre przygotowanie danych rozwiązuje te problemy zanim w ogóle uruchomisz model. To inwestycja jednorazowa z długim horyzontem: zaindeksowana, czysta baza wiedzy działa przez lata z regularnymi aktualizacjami.

Przed czyszczeniem trzeba wiedzieć, co masz. Typowy audyt danych pod AI odpowiada na pięć pytań:

1. Jakie formaty? DOCX, PDF, arkusze Excel/Sheets, strony w Confluence/Notion, e-maile, zapisy rozmów z CRM, baza FAQ. Każdy format wymaga innego parsera.
2. Jaka aktualność? Dokumenty starsze niż 12-18 miesięcy wymagają weryfikacji. Nieaktualne procedury w indeksie to źródło błędnych odpowiedzi.
3. Jaki zasięg dostępu? Niektóre dokumenty są poufne (umowy, dane HR). Nie powinny trafiać do indeksu dostępnego wszystkim użytkownikom — lub muszą być indeksowane w oddzielnej kolekcji z kontrolą dostępu.
4. Czy są duplikaty? Ten sam regulamin w pięciu wersjach, z których trzy są nieaktualne, to nie jest baza wiedzy — to szum.
5. Czy są dane osobowe? Dokumenty zawierające PII wymagają albo anonimizacji przed indeksowaniem, albo hostingu wyłącznie lokalnego z odpowiednią podstawą prawną RODO.

Wynikiem audytu jest lista źródeł z oceną: indeksuj / indeksuj po czyszczeniu / wyklucz / indeksuj w oddzielnej kolekcji z ACL.

Silnik RAG potrzebuje czystego tekstu. Nie pliku PDF, nie obrazu — tekstu. Parsowanie to przekształcenie każdego formatu źródłowego w płaski lub hierarchiczny tekst z metadanymi.

Typowe wyzwania:

• Skany PDF bez OCR — bez warstwy tekstowej to obrazy. Wymagają OCR przed indeksowaniem. Jakość OCR bezpośrednio wpływa na jakość wyszukiwania.
• PDF z wielokolumnowym układem — naiwny parser czyta kolumny poziomo zamiast pionowo, produkując nieczytelne ciągi słów. Potrzebny parser układu (layout-aware).
• Tabele w PDF lub Word — większość parserów traci strukturę tabel. Tabele z danymi liczbowymi (ceny, parametry techniczne, harmonogramy) wymagają osobnej ścieżki ekstrakcji do Markdown lub JSON.
• Arkusze Excel — każdy arkusz i zakres danych to osobny fragment. Kontekst nagłówków kolumn musi zostać zachowany, inaczej wartości tracą znaczenie.
• Strony Confluence/Notion przez API — zwykle zwracają HTML lub JSON z bogatą strukturą. Trzeba zachować nagłówki H2/H3 jako sygnały hierarchii przy chunkingu.

Na wyjściu każdy dokument staje się zbiorem akapitów lub sekcji z metadanymi: tytuł dokumentu, data, dział, kategoria, format źródłowy.

Chunking to jeden z najważniejszych kroków, który ma największy wpływ na trafność wyszukiwania. Zła strategia chunkingu potrafi zepsuć wdrożenie z doskonałymi dokumentami.

Podstawowe zasady:

• Rozmiar fragmentu 256-512 tokenów dla większości zastosowań. Zbyt krótkie fragmenty (50 tokenów) tracą kontekst. Zbyt długie (2000 tokenów) wypełniają okno kontekstowe modelu jednym dokumentem, nie dając miejsca na inne.
• Nakładka (overlap) 10-20% między sąsiednimi fragmentami zachowuje ciągłość semantyczną przy granicy podziału. Bez nakładki zdanie „kontynuując poprzedni punkt" traci swój poprzedni punkt.
• Respektuj granice semantyczne — dziel przy nagłówkach H2/H3, akapitach, pozycjach listy. Podział w środku zdania zawsze daje gorszy wynik niż podział przy nagłówku.
• Każdy fragment niesie metadane — tytuł dokumentu, nagłówek sekcji, data, kategoria. W wyszukiwaniu hybrydowym filtry po metadanych pozwalają zawęzić wyniki do konkretnego działu lub daty.

Specjalny przypadek: dokumenty proceduralne krok po kroku. Tu optymalny chunk to jeden krok z pełnym kontekstem procedury w metadanych. Jeden krok bez kontekstu, który mówi że to krok 3 z 7 procedury reklamacyjnej, jest bezużyteczny w izolacji.

Każdy fragment musi zostać zamieniany na embedding — wektor liczb reprezentujący znaczenie tekstu. Ten wektor trafia do bazy wektorowej i stanowi podstawę wyszukiwania semantycznego.

Kluczowe decyzje na tym etapie:

Wybór modelu embeddingów. Używamy BGE-M3 uruchamianego lokalnie przez Ollama. Obsługuje język polski bez tłumaczenia, produkuje 1024-wymiarowe wektory i działa na CPU serwera firmowego. Żadna treść nie opuszcza infrastruktury podczas indeksowania. Przy treściach publicznych bez danych wrażliwych akceptowalne są też chmurowe modele embeddingów, o ile PII zostało wcześniej zamaskowane.

Indeksowanie przyrostowe. Pierwsze indeksowanie całej bazy może trwać od minut do godzin w zależności od wolumenu. Każda aktualizacja dokumentu powinna triggerować reindesowanie tylko zmienionych fragmentów — nie całego korpusu.

Wersjonowanie. Zmiana modelu embeddingów wymaga pełnego reindesowania całej bazy. To ważne przy planowaniu: wybierz model na dłużej, bo migracja ma realny koszt.

Przygotowanie danych pod AI to jednocześnie ćwiczenie z ochrony danych. Każdy etap pipeline'u jest potencjalnym punktem wycieku.

Obowiązki przy danych osobowych:

• Podstawa prawna dla przetwarzania danych w celach AI musi istnieć zanim dane trafią do indeksu. Zgoda lub uzasadniony interes dla danego zastosowania.
• Minimalizacja — indeksuj tylko dane niezbędne do celu asystenta. Pełna baza CRM z historią klientów nie powinna trafiać do asystenta odpowiadającego na pytania o procedury wewnętrzne.
• Maskowanie PII — przed wysłaniem fragmentów do zewnętrznego modelu generatywnego przez nasz router LLM automatycznie wykrywamy i maskujemy dane osobowe: imiona, numery telefonów, PESEL, adresy e-mail.
• Data residency i self-hosting — przy danych objętych tajemnicą zawodową (prawo, medycyna, finanse) lub wrażliwych danych kadrowych cały pipeline (embeddingi, baza wektorowa, model generatywny) powinien działać lokalnie.
• Prawo do usunięcia — gdy RODO wymaga usunięcia danych osoby, jej dokumenty muszą zniknąć z indeksu. Pipeline powinien obsługiwać selektywne usuwanie fragmentów z bazy wektorowej.

Dla projektów HR, oceny pracowniczej lub finansowych, jako obszarów wysokiego ryzyka według AI Act, wymagana jest DPIA (ocena skutków dla ochrony danych) przed wdrożeniem. Szczegóły w artykule AI Act i RODO 2026.

Przygotowanie danych to nie jednorazowy projekt. Baza wiedzy żyje: dokumenty się zmieniają, procesy ewoluują, nowe produkty wchodzą do oferty.

Dobre praktyki utrzymania:

• Wersjonowanie dokumentów z datą ważności. Każdy chunk nosi metadane z datą dokumentu. System może depriorytetyzować fragmenty starsze niż X miesięcy lub wymagać ręcznego potwierdzenia aktualności.
• Pipeline automatycznego reindesowania. Zmiana pliku w repozytorium wiedzy (Confluence, SharePoint) triggeruje automatyczne przeliczenie dotkniętych fragmentów. Nie raz w miesiącu — przy każdej zmianie.
• Monitoring jakości odpowiedzi. Jeśli asystent zaczyna odpowiadać „nie wiem" częściej niż zwykle, to sygnał że baza wymaga aktualizacji — nie że model się popsuł.
• Luki tematyczne. Narzędzia observability śledzą pytania, na które RAG nie znalazł fragmentu. To lista tematów do uzupełnienia w bazie wiedzy.

Cykl: indeksuj → zbieraj pytania bez odpowiedzi → uzupełniaj bazę → reindesuj. Po kilku iteracjach asystent pokrywa zdecydowaną większość rzeczywistych pytań od użytkowników.

Czas i koszt zależą przede wszystkim od stanu danych wejściowych. Czyste, ustrukturyzowane dokumenty (Word, Confluence, dobrze sformatowane PDF) skracają projekt kilkukrotnie w porównaniu z bazami pełnymi skanów i arkuszy bez porządku.

Koszty infrastruktury przy lokalnym hostingu to głównie serwer i czas wdrożenia. Chmurowe embeddingi to kilka centów za milion tokenów. Oceń własny projekt w kalkulatorze ROI lub skorzystaj z oceny gotowości AI, która oceni między innymi stan Waszej bazy wiedzy.

Pełną wycenę projektu przygotowujemy po audycie danych. Napisz przez formularz kontaktowy.

Ten sandbox uruchamia ten sam pipeline co nasze wdrożenia: wklej fragment swojej bazy wiedzy, a model odpowie wyłącznie na podstawie podanego tekstu. PII maskowane przed modelem, zero retencji.

Zacznij od audytu: wypisz wszystkie systemy, w których mieszka wiedza firmowa (SharePoint, Confluence, e-maile, CRM, shared drive), oceń aktualność i format każdego zbioru. Wybierz jeden obszar tematyczny z relatywnie czystymi danymi, na przykład FAQ obsługi klienta albo procedury onboardingu pracowników, i zrób pilot na tym wycinku. Lepiej uruchomić asystenta na 200 dobrych dokumentach niż na 2000 chaotycznych. Więcej o podejściu etapowym w artykule od czego zacząć wdrożenie AI.

Nie. Przy lokalnym modelu embeddingów (np. BGE-M3 przez Ollama) i lokalnej bazie wektorowej (Qdrant on-prem) cały pipeline indeksowania działa w Waszej infrastrukturze. Do zewnętrznego modelu generatywnego trafia jedynie treść zapytania i kilka wybranych fragmentów kontekstu, po automatycznym maskowaniu PII. Wrażliwe dane kadrowe, prawnicze i finansowe możemy obsłużyć przez self-hosting całego modelu generatywnego.

Nie usuwaj ich od razu, jeśli nie jesteś pewien, które wersje są aktualne. Zamiast tego oznacz je datą i depriorytetyzuj w rankingu przez metadane: fragmenty starsze niż 18 miesięcy dostają niższy wynik przy remisach, a asystent może informować użytkownika, że dokument pochodzi ze starszej wersji procedury. Systematyczne porządkowanie bazy wiedzy to projekt sam w sobie, który zwraca się wielokrotnie, bo poprawia nie tylko AI, ale i wyszukiwanie dla pracowników.

Zależy od tego, jak często zmienia się baza wiedzy. Przy aktywnie aktualizowanych procedurach optymalny jest pipeline przyrostowy triggerowany zmianą dokumentu (webhook z Confluence lub SharePoint do silnika indeksowania). Przy stabilniejszych bazach wystarczy regularne skanowanie cotygodniowe lub comiesięczne z automatycznym wykrywaniem zmian przez sumę kontrolną pliku. Brak aktualizacji indeksu przy zmieniających się dokumentach to najczęstsza przyczyna pogorszenia jakości asystenta po kilku miesiącach działania.

Tak, w każdym scenariuszu. Nawet gotowe platformy RAG (SaaS) wymagają, żeby dokumenty były czytelne maszynowo, aktualne i logicznie podzielone. Różnica polega na tym, że gotowe narzędzia SaaS oferują własny interfejs do uploadowania i zarządzania dokumentami, ale jakość chunkingu i struktury danych nadal zależy od Ciebie. Przy danych wrażliwych lub dużym wolumenie, własna infrastruktura daje pełną kontrolę nad tym, co i gdzie jest przetwarzane. Porównanie podejść w artykule własny asystent AI czy gotowy.