Jedno z najczęstszych zdań, które słyszymy na wstępnym warsztacie z klientem: „Mamy tysiące dokumentów, bazy danych, historię zgłoszeń serwisowych, e-maile od klientów — dane na pewno mamy." Technicznie to prawda. Gdy jednak pytamy, jak wygląda jeden reprezentatywny rekord i skąd dokładnie pochodzi, zaczynają wychodzić szczegóły: pliki przechowywane w trzech różnych wersjach SharePointa, rekordy zduplikowane z wzajemnie sprzecznymi wartościami, dokumenty zeskanowane jako obrazy bez OCR, arkusze Excel z sensownymi nazwami kolumn tylko dla osoby, która je stworzyła w 2018 roku.
Gotowość danych jest — według wielu badań — kluczowym czynnikiem różnicującym między projektami AI, które osiągnęły mierzalną wartość, a tymi, które skończyły jako porzucone piloty. Ten artykuł nie jest o tym, jakie modele wdrożyć. Jest o tym, co trzeba zrobić zanim w ogóle dotrzemy do modeli.
Dlaczego "mamy dane" ≠ "dane są gotowe"
Gotowość danych dla AI ma inną definicję niż "dane gdzieś są zapisane". Model — czy chodzi o pipeline RAG, czy fine-tuning — potrzebuje danych w konkretnym stanie:
- Maszynowo czytelne: tekst wyekstrahowany z PDF, obrazów i tabel w ustrukturyzowanej formie
- Spójne: te same encje nazwane tak samo (klient "ACME sp. z o.o." vs. "Acme PL" vs. "ACME Poland" to dla modelu trzy różne encje)
- Relewantne i czyste: bez duplikatów, bez przestarzałych wersji, bez wewnętrznego "szumu" (rekordy testowe, dane sandbox, dokumenty draft)
- Właściwie zaadnotowane lub ustrukturyzowane: model musi wiedzieć, co dane reprezentują, a nie tylko widzieć surowy tekst
- Dostępne i zarządzalne: jasna własność, wersja, data ważności, prawa dostępu
Cisco AI Readiness Index raportuje, że jedynie ~34 % firm ocenia swoją gotowość danych jako wystarczającą do wdrożenia AI. Z naszego doświadczenia terenowego ta liczba brzmi optymistycznie — większość projektów spędza pierwszą trzecią część całego zaangażowania właśnie na przygotowaniu danych, nie na modelach.
Faza 1: Inwentaryzacja — co właściwie mamy
Przed jakąkolwiek decyzją techniczną konieczne jest zmapowanie istniejących źródeł danych. W praktyce oznacza to odpowiedzi na następujące pytania:
Gdzie dane fizycznie się znajdują?
- Bazy danych (PostgreSQL, MySQL, MSSQL, Oracle)
- Dyski współdzielone i systemy dokumentowe (SharePoint, Google Drive, NAS)
- Systemy ERP / MES / SCADA (SAP, Infor, Siemens WinCC, Ignition)
- E-maile i narzędzia komunikacyjne
- Dokumentacja papierowa zeskanowana jako obrazy
- Logi maszyn i dane sensoryczne (MQTT, OPC-UA, przemysłowe bazy danych jak InfluxDB)
Każde źródło ma inny format, inną częstotliwość aktualizacji, inny stopień ustrukturyzowania i inne prawa dostępu. Lista wszystkich źródeł to pierwszy artefakt projektu data pipeline.
Jaka jest jakość?
Dla każdego źródła szacujemy:
- Procentową kompletność kluczowych pól (ile rekordów ma wypełnione wszystkie obowiązkowe pola?)
- Spójność formatu (czy daty są zawsze w tym samym formacie? Czy kategorie pochodzą ze stałego słownika czy z wolnego tekstu?)
- Duplikację (czy istnieją rekordy reprezentujące tę samą encję więcej niż raz?)
- Aktualność (kiedy rekord był ostatnio weryfikowany? Czy istnieją przestarzałe wersje?)
Ten audyt nie musi być idealny — celem jest identyfikacja krytycznych problemów, które zablokowałyby projekt, a nie osiągnięcie stuprocentowej czystości przed uruchomieniem.
Kto jest właścicielem danych?
Dla każdego źródła: kto odpowiada za treść? Kto ma uprawnienia do zmiany dostępu? Kto potrafi wyjaśnić, co rekord oznacza? Bez jasno określonej własności danych projekt AI może utknąć w międzydziałowych sporach o to, kto zatwierdzi, że jego baza może być użyta do treningu lub retrieval.
Faza 2: Ekstrakcja i normalizacja
Gdy znamy źródła, następuje praca techniczna: pobranie danych do jednolitej postaci, z którą pipeline może pracować.
Ekstrakcja ze źródeł ustrukturyzowanych
Z relacyjnych baz danych i systemów ERP ekstrakcja jest stosunkowo prosta — zapytania SQL, wywołania API, eksport CSV. Kluczowe jest zdefiniowanie:
- 1.Które tabele / pola są relewantne dla danego use-case'u (nie ekstrahować całego ERP)
- 2.Jaka jest częstotliwość aktualizacji (batch raz dziennie lub streaming zmian przez CDC — Change Data Capture)
- 3.Jak mapują się techniczne nazwy pól na zrozumiałe dla człowieka (kolumna
ord_stat_cd→ "status zamówienia")
Ekstrakcja ze źródeł nieustrukturyzowanych
Dokumenty, e-maile, rysunki techniczne i zeskanowane formularze są trudniejsze. Niezbędne kroki:
- OCR dla zeskanowanych dokumentów: narzędzia takie jak Tesseract, Azure AI Document Intelligence lub Google Document AI potrafią wyekstrahować tekst z obrazów i PDF. Jakość wyjścia OCR bezpośrednio wpływa na jakość odpowiedzi modelu.
- Chunking: długie dokumenty należy podzielić na mniejsze segmenty przed wektoryzacją. Naiwny chunking co 512 tokenów z cięciem w środku zdania to częste źródło problemów w jakości pipeline RAG. Lepsze jest dzielenie według logicznych jednostek (akapity, sekcje, tabele).
- Ekstrakcja metadanych: każdy chunk musi nieść metadane — skąd pochodzi, data powstania, aktualność, autor, ewentualnie kategoria. Te metadane służą do filtrowania przy retrieval i do wyświetlania źródła w odpowiedzi.
Normalizacja encji
Ta sama firma w trzech różnych zapisach to dla modelu wektorowego trzy różne encje z podobnym embeddingiem, ale przy fuzzy wyszukiwaniu lub filtrowaniu to problem. Entity resolution — ujednolicenie różnych zapisów tej samej encji — to praca, którą wykonuje się niekiedy ręcznie (słowniki klientów), niekiedy półautomatycznie (fuzzy matching na nazwy firm) i niekiedy za pomocą LLM (gdy rekordy są w języku naturalnym).
Faza 3: Czyszczenie i walidacja jakości
Czyszczenie danych to iteracyjny proces. Nie można zrobić go raz i na zawsze — pojawiają się nowe dane, zmieniają się formaty, ujawniają nowe wzorce błędów.
Konkretne kroki, które widzimy w praktyce
- Usuwanie duplikatów: identyfikacja rekordów reprezentujących tę samą informację pod różnymi identyfikatorami
- Korekta błędów formatowych: daty w różnych formatach, wartości liczbowe z jednostką zapisaną w tym samym polu, numery telefonów z różnymi formatami prefiksów
- Obsługa brakujących wartości: uzupełnienie tam, gdzie to możliwe, jawne oznaczenie tam, gdzie brakuje, decyzja o wykluczeniu gdy rekord bez obowiązkowego pola jest bezużyteczny
- Filtrowanie nieistotnych danych: rekordy testowe, środowiska sandbox, notatki wewnętrzne, dokumenty oznaczone jako "draft" lub "archiwum"
- Weryfikacja aktualności: dla baz wiedzy i pipeline RAG stara informacja bywa gorsza niż brak informacji. Cenniki sprzed dwóch lat, karty techniczne wycofanych produktów — muszą mieć albo jawną datę w metadanych, albo zostać wykluczone.
Czyszczenie na potrzeby przygotowania datasetu do fine-tuningu ma dodatkowo specjalną warstwę: każdy przykład treningowy musi mieć właściwą formę pary wejście–wyjście, wyjście musi być poprawne (nie "nasz best-effort szacunek"), a dataset musi równomiernie pokrywać główne tematy domeny. Luki w datasecie przekładają się na martwe punkty modelu.
Faza 4: Struktura i prawa dostępu
Jednym z najczęściej niedocenianych aspektów przygotowania danych jest kto może widzieć co. W środowisku enterprise istnieją warstwy praw dostępu:
- Umowy handlowe i ceny, które może widzieć tylko dział sprzedaży
- Rekordy HR, które może widzieć tylko dział HR
- Dokumentacja techniczna dostępna wewnętrznie, ale nie do przekazania klientom
- Dokumentacja regulacyjna, która musi być audytowalna i nie może być zmieniana bez śladu
Gdy wdrożycie system RAG mający dostęp do całej bazy wiedzy bez uwzględnienia tych praw, a pracownik działu sprzedaży zapyta o koszty produkcji (które może widzieć tylko dyrektor produkcji) — system odpowie. To nie jest funkcja, to incydent bezpieczeństwa.
Właściwe rozwiązanie: prawa dostępu muszą zostać przeniesione również do bazy wektorowej. Każdy dokument lub chunk musi mieć metadane o tym, kto może uzyskać do niego dostęp. Przy retrieval filtruje się nie tylko według relewancji, ale też według tego, czy wywołujący użytkownik ma dostęp. To nietrywalna architektura, ale przy wdrożeniu w sektorach regulowanych (RODO, tajemnica handlowa) jest obowiązkowa.
Faza 5: Pipeline i aktualność
Data pipeline dla AI nie jest jednorazową akcją — to ciągły proces. Dane firmowe zmieniają się każdego dnia. Nowe zamówienia, nowe dokumenty, zmienione ceny, zaktualizowane karty techniczne.
Typy architektur pipeline
- Batch pipeline (raz dziennie / tygodniowo): ekstrakcja, czyszczenie i re-indeksowanie bazy wiedzy w regularnych odstępach. Odpowiednie dla większości dokumentowych systemów RAG — tolerancja na 24-godzinną "stale-ness" jest w większości use-case'ów akceptowalna.
- Streaming / near-real-time: zmiany w systemie źródłowym propagowane do bazy wektorowej w ciągu minut. Niezbędne dla use-case'ów, gdzie dane szybko się dezaktualizują (systemy ticketingowe, live inwentarz, sygnały handlowe). Wymaga architektury CDC (Change Data Capture).
- Human-in-the-loop weryfikacja: dla wrażliwych danych (protokoły medyczne, dokumenty prawne, instrukcje bezpieczeństwa) każda zmiana w bazie wiedzy przechodzi przez ludzkie zatwierdzenie zanim pojawi się w indeksie retrieval.
Wybór architektury zależy od częstotliwości zmian w danych źródłowych oraz od tolerancji use-case'u na dezaktualizację. Dla większości B2B firmowych use-case'ów wystarczy batch pipeline — prostszy w utrzymaniu, tańszy, wystarczająco aktualny.
Monitoring jakości danych
Pipeline musi mieć alerting na anomalie danych: nagły spadek liczby dokumentów (możliwe usunięcie repozytorium źródłowego), wzrost udziału pustych pól (zmiana formatu w systemie źródłowym), duplikaty powyżej progu (awaria deduplikacji). Bez monitoringu problemy z danymi wychodzą na jaw dopiero gdy model zaczyna dawać złe odpowiedzi — i nie zawsze jest trywialnie proste prześledzenie przyczyny z powrotem do źródła.
Faza 6: Governance i dokumentacja
To jest część, którą zespoły techniczne robią niechętnie, ale bez której projekt AI rozpadnie się przy skalowaniu.
Co musi być udokumentowane
- Data dictionary: dla każdego źródła danych i każdego relewantnego pola — czym jest, w jakim formacie, kto jest właścicielem, kiedy było ostatnio weryfikowane
- Lineage: skąd dane przyszły, przez jakie transformacje przeszły, gdzie teraz są — zdolność prześledzenia konkretnego wyjścia modelu z powrotem do konkretnego dokumentu źródłowego
- Change log bazy wiedzy: każda zmiana w indeksie retrieval musi być zapisana — co dodano, co zmieniono, co usunięto i kiedy
- Prawa dostępu i ich historia: dla zgodności z RODO i przy audycie potrzebna jest historia tego, kto miał dostęp do czego i kiedy
Te wymagania nie są specyficzne dla AI — to standardy data governance, które dojrzałe firmy stosują dla każdego krytycznego systemu. AI jedynie je uwydatnia, ponieważ wyjścia modelu są bezpośrednio widoczne i wpływają na decyzje.
Typowe pułapki, które widzimy w praktyce
Zanim przejdziemy do podsumowania, kilka wzorców, które się powtarzają:
- "Damy mu cały SharePoint": wolumen nie jest problemem, relewancja tak. Model indeksujący 50 000 dokumentów, w tym prezentacje z 2015 roku, pliki testowe i protokoły z wewnętrznych spotkań, będzie miał niższą precyzję retrieval niż model indeksujący 2 000 starannie wybranych i czystych dokumentów. Mniej i lepiej jest prawie zawsze lepsze niż więcej i niskiej jakości.
- "Rozwiążemy to później": jakości danych w projektach AI nie naprawia się "później". Jeśli wpuścicie do produkcji system RAG z niskiej jakości danymi, użytkownicy przestaną mu ufać szybko — a zaufanie jest znacznie trudniejsze do odzyskania niż do zbudowania.
- "Nasze dane są wrażliwe, ale nam to nie przeszkadza": RODO i ustawa o tajemnicy przedsiębiorstwa mają zastosowanie również do systemów AI. Jeśli wasza baza wiedzy zawiera dane osobowe, umowy z NDA lub poufne informacje handlowe, musicie mieć prawnie spójną podstawę ich przetwarzania także w pipeline AI.
- "Fine-tunujemy na tym, co mamy": jak opisaliśmy w artykule o przygotowaniu datasetu do fine-tuningu, niewystarczający wolumen lub słabe pokrycie domeny w danych treningowych wyprodukuje model, który z przekonaniem odpowiada źle — co jest gorsze niż model, który powie "nie wiem". Dostateczność danych jest warunkiem koniecznym fine-tuningu, nie życzliwym założeniem.
Praktyczne kroki na start
Jeśli chcecie zacząć, a nie gubić się w teorii:
- 1.Wybierzcie jeden use-case, nie "całą firmę". Jeden konkretny problem (odpowiedzi na techniczne pytania klientów, wyszukiwanie w dokumentacji serwisowej, generowanie ofert z katalogu) ma ograniczony zakres danych.
- 2.Zmapujcie źródła danych dla tego use-case'u — gdzie są, jaki format, kto jest właścicielem, jaka aktualność.
- 3.Zróbcie audyt danych na próbce — weźcie 100 losowych rekordów i ręcznie oceńcie jakość. Większość problemów będzie widoczna.
- 4.Zdefiniujcie minimalną jakość dla wdrożenia produkcyjnego — nie "perfekcyjna", ale "wystarczająco dobra dla danego use-case'u".
- 5.Zaprojektujcie pipeline — batch lub streaming, prawa dostępu, monitoring.
- 6.Iterujcie: pierwszy indeks będzie niedoskonały. Oceńcie jakość odpowiedzi RAG, zidentyfikujcie najczęstsze przyczyny złych odpowiedzi, poprawcie dane lub pipeline, powtórzcie.
Najczęstsze pytania
Ile danych potrzebujemy do systemu RAG?
Dla działającego systemu RAG nie istnieje dolny limit liczby dokumentów — nawet 50 dobrze przygotowanych dokumentów może dawać doskonałe wyniki, jeśli pokrywają relewantny zakres domeny. Ważniejsze od ilości jest pokrycie: jeśli użytkownicy zadają pytania, na które w bazie wiedzy nie ma odpowiedzi, model albo to przyzna (dobrze skonfigurowany guardrail), albo odpowiedź wymyśli (zły stan). Zinwentaryzujcie pytania, na które system musi umieć odpowiedzieć, i zweryfikujcie, czy są odpowiadalne z dostępnych danych.
Czy możemy używać danych wewnętrznych do fine-tuningu bez ryzyk prawnych?
Zależy od charakteru danych. Wewnętrzne instrukcje techniczne, dokumenty SOP i zapisy historyczne bez danych osobowych są typowo w porządku — należą do firmy i nie zawierają PII. Rekordy z danymi klientów, umowy lub dane osobowe pracowników wymagają podstawy prawnej zgodnie z RODO (zgoda, uzasadniony interes, wykonanie umowy) również dla przetwarzania w pipeline AI. Zalecamy konsultację z DPO zanim przystąpicie do budowania datasetu treningowego z regulowanych danych.
Jak długo trwa przygotowanie danych?
W praktyce widzimy rozpiętość od dwóch tygodni (jedno dobrze zdefiniowane źródło, dobra dokumentacja wewnętrzna, skłonni właściciele danych) do sześciu miesięcy (dane rozproszone w trzech różnych systemach, nieistniejący data governance, wewnętrzne przeszkody polityczne przy dostępie). Przeciętny projekt spędza 30–40 % całkowitego czasu na przygotowaniu danych. Jeśli klient twierdzi, że da radę w tydzień, to albo bardzo mały scope, albo niedoszacowanie skali problemu.
Potrzebujemy data engineera czy poradzi sobie developer AI?
Dla prostszych use-case'ów (dokumenty PDF, prosty eksport SharePoint) developer AI poradzi sobie z podstawową ekstrakcją i chunkingiem. Dla bardziej złożonych scenariuszy — streaming pipeline z systemów ERP, architektura CDC, normalizacja encji z wielu źródeł, lineage zgodny z RODO — potrzebny jest doświadczony data engineer. Niedocenianie tej roli to jedna z najczęstszych przyczyn opóźnień projektów AI.
Czy dane muszą być po polsku, czy działa też angielski?
Dla systemu RAG nad dokumentami firmowymi język dokumentów jest nadrzędny — modele embeddingowe używane są wielojęzycznie (modele jak BGE-M3 pokrywają 100+ języków w tym polski), retrieval działa dobrze w obu językach. Dla fine-tuningu język danych treningowych jest krytyczny — jeśli chcecie model odpowiadający profesjonalną polszczyzną z firmową terminologią, przykłady treningowe muszą być w języku polskim z tą terminologią.
*Jeśli zajmujecie się przygotowaniem danych firmowych do projektu AI i chcecie uniknąć zbędnych błędów, chętnie przeprowadzimy z wami audyt danych i zaproponujemy architekturę pipeline dostosowaną do waszego use-case'u. Skontaktujcie się z nami w sprawie bezpłatnej konsultacji.*