Jak przygotować dane firmy do wdrożenia RAG lub LLM?

W projekcie RAG model językowy zwykle nie jest najtrudniejszą częścią. Znacznie więcej problemów powodują nieaktualne dokumenty, sprzeczne źródła, brak uprawnień i dane, których nikt wcześniej nie przygotowywał do automatycznego wykorzystania.

Nie trzeba porządkować całej firmy przed pierwszym wdrożeniem. Trzeba jednak dokładnie wiedzieć, jaki problem rozwiązujemy, z których danych system może korzystać i co powinien zrobić, gdy nie znajdzie wiarygodnej odpowiedzi.

Najpierw pytanie, później dane

Rozmowa o wdrożeniu RAG często zaczyna się od źródeł.

Mamy SharePoint. Kilka tysięcy plików PDF. Instrukcje na dysku sieciowym. Dane w ERP. Historię kontaktów w CRM. Czy możemy wrzucić to wszystko do AI?

Technicznie zwykle możemy. Nie oznacza to, że powinniśmy.

Jeżeli do systemu trafi cała firmowa dokumentacja bez określenia celu, model dostanie więcej informacji, ale niekoniecznie więcej wiedzy. Aktualne procedury wymieszają się z archiwalnymi. Instrukcje dla różnych działów zaczną ze sobą konkurować. Kilka systemów poda inne wersje tej samej informacji.

W efekcie powstaje asystent, który wie dużo, ale nie wiadomo, kiedy odpowiada poprawnie.

Dlatego pierwszy krok nie polega na podłączeniu bazy wektorowej. Polega na określeniu jednego procesu.

Nie:

Chcemy wykorzystać AI do firmowej wiedzy.

Raczej:

Pracownik serwisu zadaje pytania o aktualne instrukcje naprawy. System korzysta wyłącznie z zatwierdzonej dokumentacji technicznej, wskazuje źródło odpowiedzi i odmawia, jeżeli nie znajdzie wystarczających danych.

W takim zdaniu jest użytkownik, zadanie, zakres danych i oczekiwane zachowanie systemu. To już jest początek architektury.

Praktyczna rada: Zapisz swój use case jako jedno zdanie zaczynające się od "Użytkownik pyta o..." - jeśli nie potrafisz go sformułować, nie jesteś gotowy na wdrożenie.

Każdy przypadek użycia potrzebuje innych danych

Asystent odpowiadający na pytania o procedury wewnętrzne pracuje na innych źródłach niż system sprawdzający stan zamówienia.

Pierwszy korzysta z dokumentów, instrukcji i firmowej bazy wiedzy. Drugi powinien pobrać aktualne dane z ERP albo systemu zamówień. Próba rozwiązania obu problemów za pomocą tej samej bazy dokumentów szybko prowadzi do błędów.

Podobnie wygląda to w innych procesach:

System analizujący zapytania ofertowe potrzebuje treści wiadomości, danych klienta i zasad kwalifikacji leadów.
Asystent produktowy potrzebuje katalogu, parametrów, cen, dostępności i informacji o wariantach.
Agent marketingowy może korzystać z Google Ads, GA4, Search Console, danych sklepu i historii wcześniejszych decyzji - dokładnie tak działa nasz Ads Agent, który operuje na żywych danych klienta, nie na statycznych raportach.
System wspierający hodowlę nie szuka podobnych akapitów w dokumentach. Potrzebuje danych genealogicznych, obliczeń i relacji pomiędzy rekordami.

Nie istnieje jedna "baza wiedzy pod AI". Istnieją konkretne dane potrzebne do wykonania konkretnej pracy.

Firma zwykle ma więcej źródeł niż sądzi

Dane rzadko znajdują się w jednym miejscu.

Część wiedzy jest zapisana w dokumentach PDF i Word. Część w systemach transakcyjnych. Część w wiadomościach, notatkach, arkuszach i aplikacjach budowanych latami.

Przy pierwszej inwentaryzacji zazwyczaj pojawiają się:

dokumenty i prezentacje,
procedury i instrukcje,
system ERP (SAP, Comarch, enova),
CRM (Salesforce, HubSpot, Pipedrive),
bazy SQL i API,
katalogi produktowe,
strony internetowe i intranety,
systemy zgłoszeniowe,
arkusze kalkulacyjne,
e-maile i notatki ze spotkań,
aplikacje branżowe i własne systemy.

Na tym etapie nie trzeba importować ani indeksować danych. Trzeba ustalić:

kto jest właścicielem źródła,
jak można uzyskać do niego dostęp,
jak często dane się zmieniają,
czy źródło jest nadal używane,
kto może zobaczyć jego zawartość,
czy dane są potrzebne w pierwszej wersji systemu.

Celem jest mapa danych, nie migracja organizacji. W naszych audytach regularnie okazuje się, że duża część kluczowej dokumentacji leży w folderach SharePointa lub dyskach sieciowych, do których zespół praktycznie nie zagląda.

Jedna informacja, kilka wersji

Najtrudniejszy problem pojawia się, gdy zaczynamy porównywać źródła.

Cena produktu jest w ERP, w sklepie internetowym i w katalogu PDF. Procedura obsługi reklamacji ma trzy wersje. Parametry techniczne są inne w karcie produktu i w arkuszu od dostawcy.

Każdy z tych dokumentów wygląda wiarygodnie. Model językowy nie wie jednak, który ma pierwszeństwo. Jeżeli pobierze dwie sprzeczne informacje, może wybrać jedną, połączyć obie albo wygenerować odpowiedź, która nie odpowiada żadnemu źródłu. I zrobi to z pełnym przekonaniem.

Dlatego dla każdego istotnego typu informacji trzeba wskazać źródło prawdy.

Jeżeli stan magazynowy pochodzi z ERP - system nie szuka go w dokumentacji ani w kopii katalogu sprzed miesiąca. Jeżeli obowiązujący regulamin jest w systemie dokumentów - archiwalne wersje nie konkurują z nim podczas wyszukiwania.

W praktyce trzeba ustalić:

system nadrzędny dla każdego typu danych,
właściciela danych,
częstotliwość aktualizacji,
sposób rozwiązywania konfliktów,
zasady oznaczania wersji archiwalnych,
zachowanie systemu przy braku aktualnych danych.

Źródło prawdy nie oznacza jednego systemu dla całej firmy. ERP może być nadrzędny dla cen i dostępności, CRM dla historii kontaktów, a zatwierdzona baza dokumentów dla procedur. Ważne, żeby hierarchia była jawna i udokumentowana, zanim napiszesz pierwszą linijkę kodu.

Nie wszystko, co istnieje, powinno trafić do RAG

Przy audycie szybko pojawia się pokusa: skoro już mamy dostęp, zaindeksujmy wszystko.

To zwykle zły pomysł.

Duża liczba dokumentów nie poprawia automatycznie jakości odpowiedzi. Może za to zwiększyć liczbę duplikatów, sprzeczności i wyników pozornie powiązanych z pytaniem.

Przed włączeniem źródła do systemu sprawdź:

czy dokument nadal obowiązuje,
czy ma właściciela,
czy wiadomo, kiedy był ostatnio aktualizowany,
czy treść nie jest kopią innego dokumentu,
czy da się określić jego zakres,
czy użytkownik powinien mieć do niego dostęp,
czy dokument ma znaczenie dla wybranego use case'a.

W systemie produkcyjnym mniej dobrze opisanych źródeł bywa cenniejsze niż tysiące przypadkowych plików.

Bałagan w danych nie znika po podłączeniu modelu

Jeżeli dokumentacja jest nieaktualna, RAG nie sprawi, że stanie się aktualna. Jeżeli ten sam produkt występuje pod kilkoma identyfikatorami, model nie musi rozpoznać, że chodzi o jeden obiekt. Jeżeli stary regulamin nie został oznaczony jako archiwalny, zostanie pobrany na równi z obowiązującym.

Jeżeli dokumenty nie mają poprawnych metadanych i statusów, LLM nie wie, która wersja regulaminu obowiązuje. Może pobrać dokument archiwalny z takim samym przekonaniem jak aktualny. To nie wina modelu. To wina danych.

Przed wdrożeniem trzeba uporządkować przynajmniej dane objęte pierwszym use case'em:

usunąć lub oznaczyć duplikaty,
oddzielić aktywne dokumenty od archiwalnych,
ujednolicić identyfikatory (ten sam produkt = ten sam kod, bez wariacji),
sprawdzić kompletność kluczowych pól,
oznaczyć datę publikacji i obowiązywania,
wskazać właściciela dokumentu,
ustalić politykę dla rekordów niekompletnych - odrzucasz, uzupełniasz, czy oznaczasz flagą?

Nie chodzi o wielomiesięczny program "data governance" przed startem projektu. Chodzi o doprowadzenie konkretnego zakresu danych do stanu, w którym można go testować i rozwijać bez zgadywania.

Metadane są częścią odpowiedzi

Treść dokumentu to tylko jedna warstwa informacji. System często musi wiedzieć:

kiedy dokument powstał i czy nadal obowiązuje,
którego rynku dotyczy,
w jakim języku został napisany,
do jakiego działu należy,
kto go zatwierdził,
jaki ma poziom poufności,
z jakim produktem, klientem lub projektem jest związany.

Te informacje to metadane. Dzięki nim system może ograniczyć wyszukiwanie do aktualnej dokumentacji technicznej dla konkretnego rynku, zamiast przeszukiwać całą wiedzę firmy.

Metadane pomagają też rozwiązywać konflikty. Jeżeli dwa dokumenty zawierają inne odpowiedzi, system może preferować ten nowszy, zatwierdzony i przypisany do właściwego kraju. Przykład: dokument ze statusem "zatwierdzony" i datą aktualizacji 2026-07 wygrywa z wersją roboczą z 2025-01, nawet jeśli ta druga jest bardziej podobna semantycznie do pytania. Bez metadanych system widzi tylko podobieństwo tekstu - i nie ma podstaw do rozstrzygnięcia.

Uprawnienia muszą działać przed wygenerowaniem odpowiedzi

Asystent AI nie może omijać zasad dostępu obowiązujących w firmie. Jeżeli pracownik nie ma prawa otworzyć dokumentu w SharePoint, nie powinien otrzymać jego fragmentu w odpowiedzi wygenerowanej przez model.

Kontrola dostępu musi działać na etapie wyszukiwania (retrievalu). System najpierw określa, które dane użytkownik może zobaczyć, a dopiero później wybiera kontekst dla modelu.

W zależności od infrastruktury może to oznaczać integrację z:

firmowym systemem tożsamości,
Active Directory lub Entra ID,
rolami aplikacyjnymi,
uprawnieniami do konkretnych projektów,
listami dostępu przypisanymi do dokumentów.

Filtrowanie gotowej odpowiedzi jest za późne. Model nie powinien w ogóle otrzymać treści, do której użytkownik nie ma dostępu.

W przypadku danych osobowych, medycznych, finansowych lub regulowanych dochodzą wymagania dotyczące retencji, logowania i lokalizacji przetwarzania. Te zasady muszą być ustalone przed wyborem dostawcy modelu i infrastruktury - nie po.

RAG nie zawsze oznacza bazę wektorową

Najbardziej popularny wariant RAG opiera się na wyszukiwaniu semantycznym - dokumenty dzielone na fragmenty, zamieniane na wektory, porównywane z pytaniem użytkownika. To działa dobrze dla wielu dokumentów i pytań opisowych.

Ale nie dla każdego rodzaju informacji.

Jeżeli użytkownik pyta o fakturę FV/2026/001, numer seryjny albo konkretny kod produktu - dokładne wyszukiwanie jest ważniejsze niż podobieństwo semantyczne.

Jeżeli pyta o aktualny stan zamówienia - właściwą odpowiedzią może być zapytanie SQL albo wywołanie API, nie szukanie w dokumentach.

Jeżeli chce przeanalizować relacje pomiędzy obiektami - potrzebny może być graf, nie baza wektorowa.

Dlatego warstwa retrieval może łączyć kilka metod:

wyszukiwanie semantyczne (wektory),
wyszukiwanie pełnotekstowe (BM25),
filtrowanie po metadanych,
zapytania SQL do systemów transakcyjnych,
wywołania API w czasie rzeczywistym,
grafy i relacje,
dedykowane funkcje obliczeniowe.

Dobra architektura nie zmusza wszystkich danych do jednej bazy. Wybiera źródło i metodę na podstawie rodzaju pytania.

Wyszukiwanie hybrydowe: znaczenie i dokładność

W większych bazach wiedzy łączy się wyszukiwanie semantyczne z klasycznym wyszukiwaniem pełnotekstowym.

Wyszukiwanie semantyczne dobrze radzi sobie ze znaczeniem. Pytanie "Jak wygląda odpowiedzialność dostawcy za opóźnioną realizację?" może prowadzić do dokumentu, który używa sformułowania "przekroczenie terminu dostawy", mimo że słowa nie są identyczne.

Wyszukiwanie pełnotekstowe lepiej odnajduje:

kody produktów,
numery faktur i zamówień,
nazwy własne,
symbole części,
skróty branżowe,
dokładne sformułowania z umów.

Trzecią warstwą jest filtrowanie po metadanych - zawężenie zbioru zanim zacznie się właściwe wyszukiwanie. "Pokaż tylko dokumenty z działu Księgowości z ostatniego roku" - to drastycznie zwiększa precyzję i eliminuje nieistotne wyniki.

Połączenie tych trzech metod pozwala znaleźć treść podobną znaczeniowo, nie gubiąc przy tym precyzyjnych identyfikatorów.

Chunking - gdzie przeciąć dokument

Model nie powinien dostawać kilkusetstronicowego dokumentu za każdym razem, gdy użytkownik zada pytanie. Dokumenty są więc dzielone na mniejsze fragmenty - chunki.

Brzmi jak szczegół techniczny. W praktyce sposób podziału może całkowicie zmienić jakość odpowiedzi.

Fragment za mały - system znajdzie konkretne zdanie, ale straci warunki i wyjątki opisane akapit wcześniej. Fragment za duży - do modelu trafi masa niepotrzebnej treści, a właściwa informacja zniknie w środku.

Trzy główne podejścia:

Podział według struktury dokumentu - rozdziały, nagłówki, sekcje i akapity jako naturalne granice znaczenia. Sprawdza się w instrukcjach, regulaminach, dokumentacji technicznej i materiałach prawnych.

Podział na mniejsze fragmenty tekstu - krótsze fragmenty poprawiają precyzję przy prostych pytaniach, ale wymagają zachowania informacji o dokumencie nadrzędnym i sąsiednich sekcjach.

Fragmenty z nakładaniem (overlap) - część treści powtarza się między sąsiednimi fragmentami, żeby zdanie lub warunek nie zostały przecięte w złym miejscu. Ale nakładanie nie jest uniwersalną receptą - zwiększa rozmiar indeksu i może powodować zwracanie niemal identycznych wyników.

Najważniejsza zasada:

Nie dobieramy chunkingu na podstawie artykułu w internecie. Porównujemy kilka wariantów na pytaniach, które rzeczywiście będą zadawać użytkownicy.

Dokumentacja techniczna wymaga innej strategii niż e-maile od klientów, a katalog produktowy jeszcze innej. To jeden z obszarów, w których doświadczenie zespołu wdrożeniowego robi największą różnicę.

Wybór modelu embeddingów

Embedding zamienia tekst na reprezentację liczbową, dzięki której system może porównywać znaczenie pytania i dokumentu. Dzięki embeddingom pytanie o "opóźnienie dostawy" jest powiązane z dokumentem o "terminach realizacji zamówień".

Wybór modelu embeddingowego ma znaczenie, ale ogólny ranking nie powie, jak model poradzi sobie z polską dokumentacją techniczną, nazwami leków, zapisami prawnymi albo branżowymi skrótami.

Kryteria, które powinny kierować wyborem:

Język i domena - model zoptymalizowany głównie pod angielski tekst ogólny może gorzej radzić sobie z polską terminologią techniczną, prawną czy medyczną. Trzeba to sprawdzić na własnych danych - nie zakładaj, że model "rozumie" Twoją branżę, bo dobrze radzi sobie z angielskim benchmarkiem.

Jakość na Twoich danych - nie ufaj ogólnym benchmarkom. Przygotuj reprezentatywny zestaw pytań, które rzeczywiście zadaliby Twoi użytkownicy, i sprawdź ręcznie, który model znajduje najtrafniejsze fragmenty. W niewielkim pilotażu może to być kilkadziesiąt przypadków, w bardziej ryzykownym systemie - znacznie więcej. Test na własnych danych jest ważniejszy niż ranking dostawcy.

Koszt i wydajność - modele embeddingowe różnią się jakością, kosztem i szybkością. Większy model może wypadać lepiej w benchmarku, ale nie gwarantuje lepszych wyników na danych konkretnej firmy. Jeśli system ma obsługiwać setki zapytań na minutę, trzeba zbalansować jakość z przepustowością.

Prywatność i lokalizacja - czy dane firmowe mogą trafić do chmury publicznej? Czy wymogi RODO lub regulacje branżowe wymagają hostowania modelu lokalnie? To pytanie, które trzeba zadać na początku projektu, nie na końcu.

Stabilność i wersjonowanie - jeśli dostawca zmieni model bez uprzedzenia, Twoje embeddingi przestaną być spójne z nowo generowanymi. Wymiana modelu embeddingowego to reindeksacja całej bazy - nie trywialna operacja.

Większy model nie musi automatycznie działać lepiej. O jakości decyduje cały układ: dane, chunking, metadane, wyszukiwanie, reranking i rodzaj pytań.

Zjawisko "Lost in the Middle"

Nowe modele przyjmują coraz więcej tekstu w oknie kontekstowym. Łatwo uznać, że wystarczy przekazać im wszystkie znalezione dokumenty i pozwolić samodzielnie wybrać odpowiedź.

Nie działa to tak dobrze, jak sugeruje teoria.

Badania nad wykorzystaniem długiego kontekstu pokazały, że modele lepiej wykorzystują treść z początku i końca kontekstu, a gorzej radzą sobie z informacją ukrytą w środku. Jeśli dostarczysz 10 fragmentów, a właściwa odpowiedź jest w piątym - model ma tendencję do jej pomijania.

W praktyce lepiej przekazać modelowi kilka dobrze dobranych fragmentów niż kilkadziesiąt "na wszelki wypadek".

Pomagają w tym:

precyzyjne filtrowanie po metadanych,
lepszy retrieval (hybrydowy),
ograniczenie liczby wyników,
usuwanie duplikatów na wyjściu,
reranking - ponowna ocena znalezionych fragmentów i przesunięcie tych najbardziej związanych z pytaniem wyżej,
rozdzielenie złożonego pytania na kilka kroków.

Reranking nie naprawi złych danych ani źle zaprojektowanego wyszukiwania. Ale może istotnie poprawić wybór kontekstu przed przekazaniem go do modelu. Mniej fragmentów, lepiej dobranych - to klucz do trafnych odpowiedzi.

Dane muszą się aktualizować

Jednorazowy import dokumentów wystarcza do demonstracji. System produkcyjny potrzebuje synchronizacji.

Jeżeli zmienia się regulamin, oferta, dokumentacja albo dane produktowe - aktualizacja musi trafić do warstwy AI. Jeżeli źródło zostanie usunięte, jego fragmenty nie mogą bez końca pozostawać w indeksie.

Trzeba ustalić:

jak często dane będą odświeżane,
czy system pobiera pełny zbiór, czy tylko zmiany (delta sync),
co dzieje się po usunięciu dokumentu ze źródła,
jak obsługiwane są błędy synchronizacji,
która wersja dokumentu jest aktywna w danym momencie.

Częstotliwość zależy od procesu. Dokumentacja aktualizowana kilka razy w roku nie potrzebuje synchronizacji co minutę. Dane o dostępności produktów mogą wymagać odczytu bezpośrednio z systemu przy każdym pytaniu.

Wersjonowanie nie jest dodatkiem

Jeżeli system udzieli błędnej odpowiedzi, trzeba móc ustalić:

jakie pytanie otrzymał,
z których źródeł skorzystał,
jakie fragmenty pobrał,
która wersja dokumentu była aktywna,
jakiego modelu użył,
jakie reguły i prompty obowiązywały w danym momencie.

Bez tego zespół widzi tylko wynik, ale nie potrafi odtworzyć przyczyny.

Wersjonowanie danych, promptów, modeli i konfiguracji retrieval pozwala odróżnić przypadkowy błąd od regresji spowodowanej zmianą w systemie. To jedna z różnic pomiędzy demo RAG a systemem, który można utrzymywać w produkcji.

Zbuduj pytania testowe przed wdrożeniem

Nie warto czekać z testami do momentu, kiedy system jest gotowy. Już na początku projektu można zebrać pytania, które naprawdę zadają użytkownicy.

Powinny obejmować:

pytania typowe - chleb powszedni systemu,
pytania nieprecyzyjne - tak jak ludzie naprawdę pytają,
pytania wymagające połączenia kilku informacji,
pytania bez odpowiedzi w źródłach - system musi umieć odmówić,
pytania o dane archiwalne,
przypadki z ograniczonym dostępem,
pytania zawierające dokładne symbole, numery i identyfikatory.

Dla każdego pytania warto określić:

gdzie znajduje się prawidłowa odpowiedź,
jakie informacje muszą się pojawić w odpowiedzi,
czego system nie może dopowiedzieć od siebie,
kiedy powinien odmówić odpowiedzi,
jakie źródło powinien wskazać.

Dopiero na takim zbiorze można sensownie porównać chunking, embeddingi, wyszukiwanie i reranking. Ogólny benchmark dostawcy nie zastąpi testu na Twoich danych, Twoich pytaniach i Twoim use case'ie.

Minimalny audyt danych przed wdrożeniem

Przed rozpoczęciem budowy warto odpowiedzieć na kilka pytań:

Nie każda odpowiedź musi od razu brzmieć "tak". Audyt ma pokazać, gdzie są luki i czy da się bezpiecznie uruchomić pierwszą wersję na ograniczonym zakresie.

Case Study: BLUP-FLOCK - gdy klasyczny RAG nie wystarcza

BLUP-FLOCK to platforma ERP do zarządzania stadami hodowlanymi drobiu, zbudowana na Laravel 11, Vue.js 3, MS SQL i Redis, działająca na Kubernetes. System nie pracuje wyłącznie na dokumentach. Musi rekonstruować drzewa genealogiczne obejmujące pięć pokoleń, obliczać współczynniki inbredu i wspierać ranking kandydatów hodowlanych z wykorzystaniem algorytmu BLUP.

Standardowe wyszukiwanie podobnych fragmentów tekstu tu nie wystarcza.

Problem z danymi zaczyna się przy zbieraniu

W hodowli zarodowej drobiu każdy ptak jest identyfikowany indywidualnym pinem na skrzydle. Dane zbiera się ręcznymi skanerami - ale sam proces zależy od typu fermy.

Na fermie klatkowej jest stosunkowo prosto: waga jedzie między klatkami na lekkiej platformie z komputerem. Ptak jest w klatce, jajko łatwo zważyć i przypisać.

Na fermie ściółkowej kury chodzą swobodnie, a jajka znoszą w specjalnych domkach-zapadkach. Osoba wyciągająca kurę z domka musi jednocześnie zabrać jajko - nie ma miejsca na ważenie przy gnieździe. Projektowaliśmy wagę ręczną, ale pokonała nas grawitacja. Rozwiązanie okazało się prostsze: pracownica chodzi ze skanerem, a co około 20 metrów na ścianie wiszą wagi elektroniczne.

Efekt: dwukrotnie więcej ważonych jaj niż przy starej metodzie zbierania danych. Częściowo dzięki nowym narzędziom, a częściowo dzięki konsekwentniejszemu egzekwowaniu nowego procesu - sama technologia nie wystarcza bez zmiany sposobu pracy. Nadal nie ważymy wszystkich jaj - ale jak wyjaśnił nam konsultujący projekt profesor z uczelni rolniczej, w hodowli zarodowej nie waży się wszystkich jaj. Potrzebna jest odpowiednio dobrana, reprezentatywna próba.

Dlaczego to ma znaczenie dla RAG

Ten przykład pokazuje coś, o czym rzadko mówi się w artykułach o wdrożeniach AI: jakość danych w systemie jest ograniczona przez sposób ich fizycznego zbierania. Żaden model embeddingowy nie poprawi faktu, że część jaj nie została zważona, bo kura chodziła po ściółce zamiast siedzieć w klatce.

Potrzebna była architektura łącząca dane strukturalne, relacje genealogiczne, własny mechanizm retrieval, deterministyczne obliczenia, warstwę wyjaśnialności i audytowalność wyników. Model językowy jest w takim systemie jednym z elementów - nie zastępuje zapytań do bazy, algorytmu BLUP ani reguł odpowiedzialnych za poprawność obliczeń.

Po uporządkowaniu procesu zbierania danych i sposobu ich udostępniania jakość wyników poprawiła się bez zmiany modelu. Problemem nie był LLM, lecz sposób przygotowania i udostępnienia danych.

To ważna lekcja: czasami przygotowanie danych oznacza oczyszczenie dokumentów i metadanych. Innym razem oznacza zaprojektowanie procesu fizycznego zbierania danych na fermie ściółkowej.

Zobacz pełne case study systemu BLUP-FLOCK →

CommercePilot: dane produktowe jako szczególny przypadek

Jeśli Twoim use case'em jest asystent zakupowy, chatbot produktowy albo agent AI operujący na katalogu e-commerce - dane produktowe muszą być tak samo czyste jak dokumentacja techniczna w przemyśle.

Rzadko są.

CommercePilot skanuje sklep internetowy i sprawdza kompletność oraz spójność danych produktowych - automatyzuje część tego audytu dla publicznie dostępnych danych katalogowych e-commerce.

Typowe problemy, które wykrywa:

Brak identyfikatorów produktowych (EAN/GTIN) - brak EAN utrudnia jednoznaczną identyfikację produktu, łączenie ofert i wykorzystanie danych przez platformy zakupowe oraz systemy agentowe. To nie tylko kwestia SEO - to kwestia gotowości na agentic commerce.

Niekompletne opisy i brakujące parametry - jeśli karta produktu nie ma wymiarów, materiału czy wagi, model nie wygeneruje sensownej odpowiedzi na pytanie klienta. Garbage in, garbage out.

Niespójna kategoryzacja - ten sam produkt przypisany do trzech kategorii to sygnał, że dane nie mają jednego źródła prawdy.

Brak danych strukturalnych - brak poprawnych danych strukturalnych Schema.org, najczęściej wdrażanych w JSON-LD, utrudnia maszynom jednoznaczne rozpoznanie produktu, ceny, dostępności i parametrów. Nie blokuje całkowicie wykorzystania katalogu, ale zwiększa zależność od mniej pewnego parsowania strony.

Jeśli planujesz wdrożenie AI w e-commerce, audyt danych produktowych to jeden z pierwszych kroków. CommercePilot automatyzuje go dla warstwy sklepowej i daje jasny obraz tego, co trzeba naprawić po stronie katalogu.

Sprawdź swój sklep w CommercePilot →

Model można zmienić. Problemy z danymi zostają

Modele będą się zmieniać. Firma może przejść z jednego dostawcy na drugiego, użyć tańszego modelu do prostych zadań albo mocniejszego do analiz wymagających głębszego reasoningu.

Model jest jednym z bardziej wymiennych elementów architektury. Jego zmiana wymaga testów, dostosowania promptów i sprawdzenia jakości - ale zwykle jest prostsza niż naprawa źródeł danych, uprawnień i integracji rozwijanych latami.

Znacznie trudniej naprawić:

brak źródła prawdy,
niejasne uprawnienia,
sprzeczne dokumenty,
brak wersjonowania,
integrację z systemem, którego nikt nie utrzymuje,
proces, który nigdy nie został jednoznacznie opisany.

Dlatego przygotowanie danych nie jest pracą wykonywaną "przed właściwym AI". Jest częścią właściwego wdrożenia.

Planujesz wdrożenie RAG lub systemu LLM?

Zaczynamy od procesu, danych i źródeł prawdy. Dopiero później dobieramy retrieval, model i resztę architektury.

Projektujemy systemy RAG, pipeline'y danych i agentów AI zintegrowanych z rzeczywistymi dokumentami, bazami danych, ERP, CRM i narzędziami operacyjnymi firmy.

Zobacz, jak budujemy produkcyjne systemy AI i integracje LLM →