AI w projekcie analitycznym. Nie jako cel, ale jako skrót.
Piotr Bratek przyszedł na scenę w Katowicach z jedną tezą: zamiast gonić za kolejną wielką implementacją AI, warto się zatrzymać, cofnąć o krok i zapytać — gdzie tak naprawdę tracimy czas?
To uczciwe pytanie. I rzadkie.
Branża analityczna od dwóch lat jest bombardowana komunikatami, że AI nie przynosi zwrotu z inwestycji. Że miliony idą w projekty, które nie wychodzą poza fazę pilota. Piotr nie ignoruje tego problemu — wychodzi od niego. I proponuje coś odwrotnego do tego, co zwykle słyszymy na konferencjach: zacznij od małego. Przetestuj. Sprawdź. Dopiero potem skaluj.
Na spotkaniu Qlik Meet the Experts w Katowicach pokazał sześć asystentów AI. Żaden z nich nie był rewolucją. Każdy rozwiązywał konkretny, codzienny problem.
Asystent #1 — konwencja nazewnictwa
Brzmi banalnie. Ale każdy, kto pracował z tabelami SAP o 200 kolumnach, wie, co to znaczy ręczne przepisywanie nazw według snake_case. Piotr zbudował prostego asystenta w Google Gemini — kontekst, instrukcja, przykład. Wklejasz kolumny, dostajesz skrypt gotowy do wklejenia w aplikację. Czas budowy: 3 minuty. Czas oszczędzony przy każdej dużej migracji: trudno liczyć.
Ważny detal: dorzucił przykład do instrukcji. Sama precyzyjna instrukcja nie gwarantuje sukcesu — model potrzebuje wzorca, nie tylko opisu.
Asystent #2 — wywiad projektowy
To jest ten punkt, w którym zrobiło się ciekawie.
Aplikacje analityczne często powstają bez dokumentacji. Ktoś z biznesu przychodzi z pomysłem, deweloper robi, po tygodniu jest pierwsza modyfikacja, po miesiącu — architektura podhalańska. Piotr zna to zjawisko z imienia.
Jego odpowiedź: asystent w Perplexity, który przeprowadza wywiad z użytkownikiem biznesowym. Nie zbiera ogólników — ma instrukcję, żeby drążyć, doprecyzowywać, wyciągać scenariusze użycia. Efektem jest ustrukturyzowana dokumentacja w formacie Markdown: cel biznesowy, KPI, użytkownicy, trzy typowe scenariusze, historia pomysłu.
Jedno wklejenie do Google Docs i mamy czytelny, pokolorowany dokument. Nie żart — jedna komenda „wklej jako Markdown” i gotowe.
Dlaczego Perplexity, a nie Gemini? Bo Gemini Gems działają jak klasyczne RAG — model nie wychodzi poza nadany kontekst. Perplexity może zarówno bazować na dokumentach klienta, jak i sięgać na zewnątrz. To dla Piotra kluczowa różnica: „Mówię mu, analizujemy nasze KPI — ale mogę jednocześnie zapytać, jakie nowe metody zarządzania finansami pojawiły się ostatnio na rynku.”
Asystent #3 — baza wiedzy o wdrożeniu
Gdy masz 10 aplikacji, wiesz co masz. Gdy masz 500 — już niekoniecznie.
Trzeci asystent to Perplexity podłączony do Google Drive z folderem dokumentacji projektowej. Każda aplikacja ma swój plik z wywiadu (#2). Asystent przeszukuje całość i odpowiada na pytania zarządcze: „Przygotowujemy wdrożenie ESG — czy mamy już jakieś elementy modelu danych, z których możemy skorzystać?” Albo: „Który dyrektor był do tej pory najbardziej zaangażowany w projekty analityczne?”
Drobny szczegół o tokenach: Perplexity ma okno kontekstowe od 30 do 200 tysięcy tokenów. Dokument z wywiadu to ok. 2,5 tys. tokenów. Przy 80 projektach zaczyna brakować miejsca. Google Gemini ma okno od 1 do 2 milionów — to jego faktyczna przewaga, jeśli baza wiedzy jest duża.
Asystent #4 — baza wiedzy ze szkoleń
Szkolenia wewnętrzne mają jeden problem: wiedza z nich ulatuje po dwóch miesiącach. Piotr rozwiązał to przez transkrypcje. Nagrywa wszystkie sesje szkoleniowe (Teams, cokolwiek), zbiera pliki, czyści je w Qlik — kompresuje, usuwa strukturę czasową, anonimizuje — i wrzuca do NotebookLM.
Dlaczego czyści w Qlik zamiast oddać surowe pliki? Bo okno kontekstowe ma swoją pojemność, a surowy plik transkrypcji z 8 godzin spotkania to spory chunk. Lepsza kontrola nad tym, co wchodzi, niż zaufanie, że model sam zdecyduje co jest ważne.
W NotebookLM szkolony może potem zadać pytanie: „Przypomnij mi, czym różni się wymiar od miary” — i dostaje odpowiedź w dokładnie takim języku, w jakim temat był omawiany na jego szkoleniu. Nie z podręcznika. Ze spotkania.
Asystent #5 — katalog miar
Master Items to jeden z tych tematów w Qlik, które łatwo odpuścić — aż do momentu, gdy masz 30 nazw dla tej samej formuły i nikt nie wie, która jest właściwa.
Piotr zbudował asystenta w NotebookLM opartego o katalog miar: nazwa, formuła, obszar biznesowy, aplikacja. Można zapytać: „Czy mamy już miary sprzedażowe, które prowadzą do tych samych danych?” Albo: „Jakie miary związane z obsługą klienta mamy gotowe do ponownego użycia?” Model grupuje, wskazuje identyfikatory, mówi gdzie dana miara już istnieje.
Bonus: NotebookLM generuje mind mapy, quizy i podcasty z tego samego źródła. Podcast o miarach to może lekka przesada — ale podcast z analizy rynku, którą właśnie zakończyłeś? Jak najbardziej.
Asystent #6 — monitoring i audyt
Ostatni, pokazany skrótowo: asystent podłączony do dokumentacji aplikacji monitorujących Qlik. Zamiast uczyć się na pamięć kilkunastu narzędzi — pytasz: „Gdzie mogę sprawdzić zużycie RAM per obiekt?” i dostajesz odpowiedź z kontekstem.
Co z tego wynika?
Żaden z tych asystentów nie jest wielkim projektem AI. Każdy zajął — według Piotra — od 3 minut do kilku dni iteracji. Ale każdy eliminuje konkretną nieefektywność. Przepisywanie nazw kolumn. Brak dokumentacji. Zapomniana wiedza ze szkoleń. Duplikowanie miar, które już istnieją.
Jest w tym pewna logika, którą warto zapamiętać: AI nie musi być transformacją. Może być po prostu skrótem. Małym, sprawdzalnym, przydatnym tu i teraz.
A jak coś nie działa — cofa się krok, upraszcza i sprawdza od nowa. To chyba jedyne podejście, które ma sens.
Piotr Bratek, DataMiners — prezentacja z Qlik Meet the Experts, Katowice, marzec 2026.
Poprzednie wydania: Ioana Teodora Halip o Qlik Answers 2.0 | Luca Tamburrano o architekturze AI w analityce
#Qlik #AI #BusinessIntelligence #Analytics #DataGovernance #QlikMeetTheExperts
