top of page

Twój projekt AI jest tylko tak dobry, jak dane, na których jest zbudowany

  • Zdjęcie autora: Monika Kotus
    Monika Kotus
  • 4 dni temu
  • 6 minut(y) czytania

W większości projektów AI, które teraz prowadzę, najtrudniejsza część to dane – to, czy są dokładne, aktualne i czy zespół może im naprawdę zaufać. Modele, integracje i same narzędzia stały się rutyną. To dane decydują, czy projekt działa, czy się rozpada.

Gartner przewiduje, że do 2026 roku organizacje porzucą 60% projektów AI, których dane nie są gotowe, by je udźwignąć.* To zgadza się z tym, co widzę w swojej pracy.

Chcę więc opowiedzieć, jak pracuję z danymi – jak je zbieram, sprawdzam i decyduję, co jest wystarczająco dobre – bo tu idzie większość realnego wysiłku.


Co właściwie robię w projektach

Duża część mojej pracy projektowej sprowadza się teraz do jednego: zbierania danych i przygotowywania ich tak, by mogły zasilić projekt AI klienta.

Część tych danych pochodzi od klienta. Część ze źródeł publicznych. Wiele z nich już istnieje wewnątrz organizacji i po prostu nigdy nie zostało użytych – stare archiwa projektów, raporty, analizy i notatki leżące w folderach, których nikt nie otwiera. Wyciągamy z tego użyteczne fragmenty, zbieramy w jednym miejscu i budujemy bazę wiedzy projektu: zestaw, który odzwierciedla tę konkretną organizację albo zespół badawczy, tak by AI pracowało na ich rzeczywistości.

W praktyce często buduję to jako Projekt w Claude. Gdy baza wiedzy jest mała, model pracuje na całości bezpośrednio. Gdy się rozrasta, Claude przechodzi na wyszukiwanie, czyli RAG, i dla każdego pytania wyciąga najbardziej trafne fragmenty, zamiast trzymać wszystko naraz.

W niektórych projektach używam też NotebookLM – kolejnego narzędzia typu RAG. Pracuje wyłącznie na źródłach, które wgrasz, i odpowiada z cytowaniami wskazującymi wprost na nie, a przy tym obsługuje naprawdę dużą bazę dokumentów – nowsze wersje przyjmują do 300 źródeł w jednym notatniku. Jego prawdziwą siłą jest szybkość: przeszukiwanie dużego zbioru materiału i szybkie zebranie tego, co z niego wynika. Pełny Projekt w Claude buduję, gdy praca wymaga głębszego rozumowania nad materiałem, a po NotebookLM sięgam, gdy projekt potrzebuje szybkiego, szerokiego przeszukania wielu źródeł.

Przygotowanie danych pod tę bazę wiedzy to samo w sobie spora część pracy – czyszczenie, przekształcanie, sprawdzanie. Dużą część tego przetwarzania robię w Claude Code, który dobrze nadaje się do pracy bezpośrednio na plikach z danymi.

I tu pytanie o dane staje się nieuniknione. RAG wyszukuje z tego, co mu dasz. Jeśli dane u podstawy są błędne, nieaktualne albo sprzeczne, AI przepuszcza to dalej – płynnie i z pełną pewnością siebie. Jakość pisania nie mówi nic o jakości źródła.


Dwa razy, gdy dane wejściowe omal nie wykoleiły projektu

Dwa przykłady z prawdziwych projektów.

Przegląd literatury. Pracowałam z zespołem badawczym, budując na bazie referencji – prace, autorzy, linki. Przyjęłam założenie, którego już nie przyjmuję: że skoro baza została przekazana, jest poprawna. Część pozycji miała błędnych autorów albo linki, które nie istniały. Model, pracując na tych referencjach, zaczął tworzyć cytowania, które się nie broniły. Referencje, które dostał, były błędne, więc jego wynik też był błędny.

Gdy błędy wyszły na jaw, wróciliśmy i odbudowaliśmy bazę porządnie. Użyłam do tego Claude Code, żeby przeszukał i zweryfikował w sieci, czy każda praca faktycznie istnieje, potwierdził prawdziwych autorów i poprawił cytowania na podstawie wiarygodnych źródeł. Nie mieliśmy samych PDF-ów, więc Claude Code dodatkowo dociągnął potrzebne informacje z odpowiednich miejsc. To była powolna, uważna praca – i zamieniła niepewną bazę w taką, której mogliśmy zaufać.

Wniosek jest prosty: zweryfikuj bazę, zanim na niej zbudujesz. Cross-check to jest właśnie ta praca, a pominięcie go tylko przesuwa problem dalej.

Analiza biznesowa. Dla startupu szykującego się do wejścia na rynek budowałam analizę biznesową z różnych danych, część z nich zebrana przez narzędzia deep research. Jedno źródło zniekształciło wszystko: rozporządzenie sprzed mniej więcej dziesięciu lat, bez żadnego oznaczenia, że jest nieaktualne. Deep research wziął je i potraktował jako aktualne, a model wyciągnął je jako jeden z głównych wniosków analizy.

To jedno przeterminowane źródło siedziało dokładnie u fundamentu pracy. Budżet, zasoby, kluczowe założenia projektu – wszystko było kształtowane na nim. Wyłapałam to, bo nie zgadzało się z niczym innym, co miałam, i wykluczyłam je. Gdyby zostało, cała analiza biznesowa opierałaby się na fakcie, który przestał być prawdziwy dekadę temu.

Dwa różne projekty, jedna przyczyna źródłowa: dane wejściowe nie były tym, czym się wydawały.


Dlaczego jakość danych to jest ta praca

Spędziłam kilka miesięcy na pełnoetatowym programie data science i najbardziej przydatne, co z niego wyniosłam, to sposób pracy z danymi, zanim się im zaufa.

Duża część tej pracy jest mało efektowna i idzie na nią większość czasu projektu. Oto na co zwracam uwagę.

Eksploracja danych, zanim się na nich oprę. Zanim projekt naprawdę ruszy, sama przechodzę przez dane, żeby zobaczyć, co w nich rzeczywiście jest. Realny obraz często różni się od tego, co ludzie zakładają. Sam ten krok potrafi zamknąć projekt w dwa dni zamiast po sześciu miesiącach – i to jest dobry wynik, gdy dane nie udźwigną celu.

Szukanie luk. Dane, które wyglądają na kompletne, często takie nie są. Pracuję dużo z badaczami, uczelniami i zespołami grantowymi i regularnie odkrywam, że czegoś, czego projekt potrzebuje, po prostu nie ma w materiale, który dostałam. Gdy zauważam lukę, wracam do zespołu i pytam wprost – i zwykle właśnie wtedy ludziom zaczyna się przypominać. Wiele z tego, na czym projekt się opiera, nigdy nie zostało nigdzie zapisane. Siedzi w głowach ludzi i staje się użytecznymi danymi dopiero, gdy ktoś zada właściwe pytanie.

Wyłapywanie duplikatów. Ta sama rzecz pojawia się w różnych systemach pod różnymi identyfikatorami. Dokument zapisany jako „raport", „raport finalny" i „raport finalny 2" zostaje odczytany jako trzy osobne źródła. Uporządkowanie tego zmienia to, co AI myśli, że wie.

Sprawdzanie świeżości i pochodzenia. Stare dane muszą być oznaczone jako stare. Gdy nie są, zachowują się jak aktualne i robią realną szkodę – tak jak w tamtej analizie biznesowej. Wiedza o tym, kiedy zbiór danych powstał i skąd pochodzi, jest tak samo ważna jak to, co zawiera.

Czujność na tendencyjność danych. Dane niosą wzorce tego, jak zostały zebrane. Model uczy się wszystkich tych wzorców, także tych, których nikt nie zamierzał. Jeśli dane przechylają się w jakąś stronę, wynik przechyla się razem z nimi.

Sprawdzanie źródeł między sobą. Dla bazy wiedzy zasilającej RAG pytanie brzmi, czy dokumenty są ze sobą spójne i nadal aktualne. Gdy dwa źródła mówią co innego, AI za każdym razem odpowiada inaczej, bo nie ma jednej wersji prawdy, na której mogłoby się oprzeć.

Praca z mniejszą, lepszą jakościowo próbką. Praca z danymi tak naprawdę nigdy się nie kończy. A zebranie ich większej ilości nie zawsze oznacza lepszy wynik. RAG też ma swoje ograniczenia i często warto pracować z mniejszą, lepszą jakościowo próbką danych.

Przez to wszystko przewija się gotowość do powiedzenia, że dane się nie nadają. Wykluczenie słabego źródła albo wstrzymanie projektu, bo nie ma fundamentu, jest częścią dobrego wykonywania tej pracy.


Precyzja znaczy teraz więcej

Jest drugi powód, dla którego jakość danych przesunęła się do centrum mojej pracy.

Najnowsze modele – w moim przypadku Claude Opus 4.7 – podążają za szczegółowymi instrukcjami znacznie dokładniej niż modele jeszcze rok temu. Przy dużej, dobrze zbudowanej bazie wiedzy AI trzyma się logiki projektu w sposób, w jaki wcześniej nie potrafiło.

To nakłada nową wagę na precyzję. Gdy model dokładnie podąża za instrukcjami, błąd w instrukcji albo w danych szybko i wyraźnie wychodzi w wyniku. Instrukcje, które piszę, muszą być dokładne, a dane pod nimi – czyste. Jest mniej miejsca na „mniej więcej dobrze" niż kiedyś.


Prawdziwe problemy wychodzą dopiero przy testowaniu

Nawet przy starannym przygotowaniu nie wyłapie się wszystkiego z góry.

Zwykle dopiero przy testowaniu pojawiają się prawdziwe problemy. Coś zostało dodane, czego być nie powinno. Czegoś brakuje. Czasem do bazy wiedzy wkradła się tendencyjność i zmienia sposób, w jaki model odpowiada. Dlatego zawsze jest pętla weryfikacji: człowiek patrzy na wynik i pyta, czy jest dobry, czy coś jest nie tak. Ta pętla jest tym, dzięki czemu projekt staje się lepszy.


Przejdźcie przez kluczowe dokumenty razem

Jeszcze jedna praktyka, którą zawsze polecam – firmom i badaczom tak samo.

Baza wiedzy bywa za duża, by przejrzeć ją w całości. Ale kluczowe dokumenty warto przeczytać uważnie – razem z klientem albo badaczem. AI może źle odczytać albo lekko inaczej zinterpretować centralny dokument, a to małe przesunięcie potrafi zmienić znaczenie całego projektu. Wyłapanie tego u fundamentu oszczędza dużo poprawiania później.


Ta sama zasada, wszędzie

Dla firmy bazą wiedzy może być ustrukturyzowana wiedza wewnętrzna jednego działu, używana do wiarygodnego tworzenia nowych materiałów. Dla badacza może to być dorobek dowodowy stojący za publikacją albo baza wiedzy pod wniosek grantowy.

Zasada trzyma się w każdym przypadku: AI na wierzchu jest zawsze tylko tak dobre, jak dane pod spodem.

Zbieranie i czyszczenie danych to praca ciągła. Dla każdej organizacji i każdego badacza, którym poważnie zależy na dobrej pracy z AI, to właśnie ten stały wysiłek nad danymi przynosi wyniki.


Jeśli budujesz coś z AI i chcesz, żeby fundament danych naprawdę się trzymał – chętnie porozmawiam.

 
 
bottom of page