Analityka agentowa w praktyce: Slackbot, warstwa semantyczna oraz wybór między zakupem a samodzielnym tworzeniem.
Analityka oparta na agentach w firmie technologicznej: Slackbot, który rozmawia z danymi, warstwa semantyczna wymagająca skalowania, decyzja o zakupie Omni oraz powód, dla którego przyjęcie tej technologii miało największe znaczenie.
Źródła: My Experience Building Agentic Analytics at a Tech Company (And Shipping It to Stakeholders)
Analityka oparta na agentach jest wszędzie w prezentacjach dostawców: rozmowa z danymi, BI wykorzystujące sztuczną inteligencję, warstwy semantyczne, analityka typu self-service wersja druga. Prawie każdy produkt analityczny usiłuje wdrożyć sztuczną inteligencję we wszystkich aspektach. Opinie na temat tego, dokąd to zmierza, są powszechne, ale historie o budowie takich rozwiązań w rzeczywistych firmach są rzadkie, podobnie jak szczere odpowiedzi na trudniejsze pytanie: czy przetrwały one w obliczu rzeczywistych użytkowników i ich oczekiwań?
Poniżej znajduje się jeden z takich opisów, skomponowany na podstawie pracy naukowca danych w średniej wielkości firmie oferującej usługi subskrypcyjne, rozpoczętej pod koniec 2025 roku. Opisuje on pierwszego Slackbota do komunikacji z danymi stworzonego od zera, wdrożenie go wśród rzeczywistych użytkowników, wyzwania związane z skalowaniem warstwy semantycznej i jej infrastruktury, a także decyzję o samodzielnym stworzeniu rozwiązania lub zakupie gotowego narzędzia BI po tym, jak zespół zaczął szukać odpowiedniego rozwiązania dla dużych firm. Od tamtej pory ta sama osoba przeniosła się do branży konsultingowej, a niemal każda firma, z którą się spotkała, próbuje rozwiązać te problemy, co wskazuje na rzeczywiste możliwości dla naukowców danych.
Decyzja, która była ważna przed pojawieniem się sztucznej inteligencji
Na początku 2025 roku wydarzyło się coś, co w tamtym czasie wydawało się niezwiązane z sztuczną inteligencją. Kierownik działu danych dostrzegł potrzebę stworzenia pierwszego modelu informacyjnego firmy i zatrudniono do tego doświadczonego konsultanta ds. inżynierii danych, przy czym na każdym etapie brali udział dwaj naukowcy danych.
Model informacyjny to warstwa, która określa, jak są strukturyzowane dane, jak powiązane są tabele oraz, co najważniejsze, co oznaczają poszczególne metryki. Można go traktować jako wspólny język, którego wszyscy w firmie powinni używać podczas omawiania danych.
Aspekt techniczny jest dość prosty. Trudniejsze jest doprowadzenie wszystkich do porozumienia co do tego języka. Zadaj pytanie, co stanowi aktywnego użytkownika – każdy zespoł odpowie inaczej. Dział marketingu ma swoją definicję, dział produktu inną, a dział finansów jeszcze inną, przy czym każdy jest przekonany, że to jego definicja jest prawidłowa. Osiągnięcie zgodności zajęło dużo czasu i było uciążliwe, jednak ta praca stała się podstawą wszystkiego, co zostało później stworzone. Bez modelu informacyjnego umieszczenie modelu semantycznego nad danymi niemal na pewno przyniosłoby więcej szkody niż pożytku.
Tworzenie wglądów na żądanie
Podczas gdy model informacyjny był tworzony, ten sam naukowiec danych przechodził osobistą przemianę. Analiza rynku pracy pokazała, że coraz więcej firm szuka specjalistów od sztucznej inteligencji, co skłoniło go do samodzielnego nauczenia się automatyzacji części codziennej pracy: narzędzi do czyszczenia danych, procesów analitycznych eksploracyjnych oraz powiązań pomiędzy sztuczną inteligencją, danymi a ich kontekstem.
To, co zaczęło się jako ćwiczenie zwiększające produktywność, rozwinęło się w coś większego – element szerszej tendencji ku analityce opartej na agentach (termin jeszcze wtedy nie używany), w której tradycyjna analiza już nie wystarczała. Jednym z najważniejszych projektów wynikających z tego było Slackbot.
Ideą było stworzenie produktu danych, który stanowiłby pośrednik pomiędzy panelami analitycznymi a naukowcami danych, przydatnego do odpowiadania na pytania, które powinny być łatwe do zadać, ale nie wymagają tworzenia nowego panelu ani modyfikacji istniejącego. Nie każde pytanie zasługuje na ticket w Jira.
Nikt o to nie prosił. Nie trzeba było czekać na zgodę ani zielone światło. Większość z tego została stworzona samodzielnie jako prototyp wraz z diagramem projektu systemu i krótką demonstracją dla zespołu. Decydującym krokiem było przedstawienie go jako czegoś już stworzonego, a nie jako wniosku o zatwierdzenie rozpoczęcia pracy. Dzięki temu zespół nie miał praktycznie żadnego ryzyka, a twórca miał szansę pokazać prace o rzeczywistej wartości, co wystarczyło, by uzyskać potrzebne wsparcie.
Wprowadzanie w użycie i nauka, jak ludzie proszą
Pierwszymi użytkownikami był pojedynczy zespół – dział marketingu. Było to celowe: kontrolowane wprowadzanie w użycie zamiast ogólnokorporacyjnego rozpoczęcia, w którym rzeczy mogłyby się zepsuć w sposób trudny do opanowania.
Oczekiwany efekt to było jedynie bezpieczniejsze wdrożenie. W rzeczywistości ujawniło to wiele na temat tego, jak osoby niebędące analitykami formułują pytania. Specjaliści od marketingu formułują pytania w kontekście problemu biznesowego, a nie w oparciu o tabele czy definicje metryk, więc system musiał dokonywać tłumaczenia pomiędzy tymi dwoma podejściami. Analitycy z kolei często dają się oszukać własnym nawykom w tym względzie.
Od samego początku było jasne, że to produkt oparty na danych, a nie tylko narzędzie, więc dokumentacja, marketing wewnętrzny oraz proces wdrożenia wymagały uwagi, ponieważ to one decydują o tym, czy ludzie faktycznie korzystają z tego, co zostało stworzone. Pierwsze kilka miesięcy upłynęło głównie na testowaniu, i to w dużym stopniu.
Co nastąpiło dalej
Rezultatem było MVP, więc podjęto decyzję dotyczącą tego, czy produkt zasługuje na dalsze inwestycje oraz jakie będą wymagania wobec następnej wersji. Budowa systemu wokół danych nie była najtrudniejszą częścią. Gdy pojawiło się pytanie, co sprawi, że będzie on bardziej przydatny, rozmowa zwróciła się ku zakresowi danych, do których mógłby dotrzeć bot, co oznaczało konieczność rozwijania warstwy semantycznej.
Następnie zespół zadał sobie szereg pytań. Pierwsza warstwa semantyczna znajdowała się w postaci plików YAML za Slackbotem, więc jak miała się rozwijać? Jak kilka osób mogłoby nad nią pracować? Czy wszyscy zgadzali się co do definicji?
Te pytania pojawiły się w odpowiednim momencie, ponieważ już rozważano nowe narzędzie BI, gdyż to istniejące nie wydawało się już wystarczająco nowoczesne. Dyskusja przeniosła się od ulepszenia Slackbotu do kwestii, czy potrzebna jest odpowiednia warstwa semantyczna oraz czy powinna być dostępna wraz z narzędziem BI, czy też jako odrębne rozwiązanie.
Wiele korporacyjnych produktów BI, takich jak Looker czy Omni, zawiera warstwę semantyczną. Dla tego zespołu istniało jedno wymaganie: jeśli narzędzie BI miało mieć warstwę semantyczną, nie mogła ona być zamknięta i musiała być przenośna do innych narzędzi. Dlatego tak ważne było ogłoszenie z września 2025 roku o Open Semantic Interchange, które obiecywało uniwersalny standard dla warstw semantycznych.
Budować czy kupować, i dlaczego to ma mniejsze znaczenie, niż się wydaje
Firma ostatecznie dokonała zakupu. Wybrano Omni, które przypominało połączenie Tableau, Looker oraz niektórych funkcji arkuszy kalkulacyjnych. W listopadzie i grudniu 2025 roku przeanalizowano kilka narzędzi, a Omni zostało wdrożone na początku 2026 roku.
To może brzmieć antyklimatycznie: historia o botie Slack stworzonym od zera kończy się zakupem gotowego rozwiązania. Ważnym punktem, który umyka wielu naukowcom danych, jest to, że te umiejętności nadal są przydatne, gdy firma dokonuje zakupu. Tworzenie tego bota dało cenne lekcje, które bezpośrednio posłużyły do integracji Omni: praktyki projektowania zapytań, metody oceny, MCP oraz dogłębne zrozumienie funkcji warstwy semantycznej.
Inżynieria kontekstu to dobry przykład. Oznacza to kontrolowanie informacji, które model widzi podczas przetwarzania zapytania: jakie tabele, jakie definicje metryk, jakie zasady biznesowe. Ponieważ całość została stworzona od zera, twórca wiedział, co umieścić przed modelem, a co ważniejsze, co pominąć. Ta wiedza pochodzi z tworzenia, a nie z czytania dokumentacji.
Umiejętności te pojawiają się również podczas rozmów kwalifikacyjnych. Od kiedy zaczęłem pracować w branży konsultingowej, spotkałem wiele firm, które woleją rozwijać rozwiązania we własnym zakresie, głównie dlatego, że chcą rozwiązania dostosowanego indywidualnie. Dlatego pytanie, czy warto się tego nauczyć, jest błędne. Naucz się tego niezależnie od decyzji firmy, ponieważ przygotowuje to na każde wyzwanie w dowolnym środowisku danych.
Gdzie narzędzie zakupione okazało się niewystarczające
Omni to solidny produkt młodej firmy, która rozwija się szybko i przyniosła wiele korzyści. Najczęściej występującym problemem był MCP.
Znaczna część pracowników firmy nadal korzysta z Google Sheets i Excel, a to się w najbliższym czasie nie zmieni. Celem było połączenie tych danych również przy użyciu tego samego modelu semantycznego co we wszystkim innym, aby liczba w arkuszu kogoś oznaczała dokładnie to samo, co gdzie indziej. Zrobienie tego za pomocą MCP byłoby idealne, ale nie było to możliwe.
Zespół chciał mieć większy wpływ na etap pomiędzy modelem semantycznym a tym, co go wykorzystuje: co jest zwracane oraz jakie narzędzia mogą się z nim łączyć. Samodzielna warstwa semantyczna w połączeniu z resztą rozwiązań opracowanymi wewnętrznie umożliwiłaby pełną kontrolę nad API. To jest kompromis, który dla wielu firm będzie decydujący. Tam, gdzie ważna jest elastyczność i pełna kontrola, sam zakup może nie wystarczyć. Tam, gdzie kluczowe są szybkość i solidne rozwiązanie gotowe do użycia, produkt taki jak Omni daje ogromne możliwości.
Adopcja decyduje o wszystkim
To temat, który zasługuje na osobny artykuł. Najbardziej zaawansowany system na świecie nie ma żadnej wartości, jeśli ludzie nie włączą go do swojego procesu pracy i mu nie zaufają, a właśnie w tym aspekcie wielu naukowców danych zawodzi. W małym zespole znalezienie na to czasu było prawdziwym wyzwaniem, ale adopcję traktowano poważnie. Inwestycje obejmowały:
- seria filmów edukacyjnych umożliwiająca szybkie wprowadzenie do pracy,
- kilka prezentacji dla całej firmy,
- specjalistyczne warsztaty online dla kluczowych zespołów, takich jak dział finansowy.
Każdy, kto wdraża narzędzie AI wewnątrz organizacji, powinien traktować jego przyjęcie jak wprowadzenie nowego produktu. Oznacza to działania marketingowe, szkolenia oraz wsparcie ze strony liderów w każdym zespole, którzy wierzą w jego wartość. W przeciwnym razie miesiące ciężkiej pracy kończą się kolejnym narzędziem, którego nikt nie używa. Praca ta jest nużąca i nie jest widoczna na panelu kontrolnym, a mimo to jest powodem, dla którego całe to zaangażowanie ma znaczenie dla kariery.
Wpływ na karierę
Slackbot, jego wdrożenie oraz rola przewodnia w przejściu na analitykę opartą na agentach przyniosły konkretny rezultat: siłę negocjacyjną. To doświadczenie umożliwiło złożenie wniosku o awans, który został przyznany.
Spór nie dotyczył głównie Slackbota. Chodziło o kreatywność i pozostawanie na czele danej dziedziny, a następnie wykorzystanie tego, by stworzyć coś, co poprawi sytuację firmy – w tym przypadku wiedzę opartą na potrzebach rynku. Najważniejszym aspektem było to, co nie wymagało żadnego wyjaśniania: nikt o to nie prosił, a nikt nie musiał kierować pracą. Menedżer interpretuje to jako wyższy stopień doświadczenia.
Człowiek, który potrafi budować takie systemy, rozumie dane, a jednocześnie zna specyfikę biznesu – to rzadka kombinacja, o której firmy doskonale wiedzą. To również tłumaczy późniejszy przechód w stronę działalności konsultingowej, ponieważ popyt na naukowców danych, którzy myślą o sztucznej inteligencji na poziomie systemowym, a nie tylko poprzez ad-hoc rozmowy, szybko rośnie.
Wniosek
Analityka oparta na agentach już się realizuje i nie jest wydarzeniem przyszłym. Firmy eksperymentują, wdrażają ją i sprawdzają, co działa. Naukowcy danych powinni w tym uczestniczyć. Niezależnie od tego, czy firma buduje, czy kupuje, te umiejętności są przydatne wszędzie: zwiększają wartość w obecnej roli, wzmacniają szanse na awans i pomagają wyróżnić się podczas rozmów kwalifikacyjnych.
Wszystko zaczęło się od prototypu stworzonego na boku, diagramu projektu systemu oraz szybkiej prezentacji dla zespołu. Czekanie, aż ktoś poprosi o taką pracę, to błąd. Lepszą drogą jest przejęcie kontroli nad własnym rozwojem.
Literatura pokrewna
- Praktyczne notatki: Budowanie systemu detekcji oszustw gotowego do użycia — Szczegółowy przewodnik po Praktycznych notatkach: Budowanie systemu detekcji oszustw gotowego do użycia: umowy, sprawdzenia oraz gotowe fragmenty kodu dla zespołów wdrażających ten model.
- Stack webowy dla startupów w erze agentów AI: Next.js, MUI i Firebase — Które narzędzia sprawdzają się przy pisaniu kodu przez agenty: Next.js, MUI, Firebase, Vercel, PostHog oraz minimalne ustawienie agenta, wraz z uzasadnieniem wyboru każdego z nich.