Przez lata schemat wyglądał tak samo: użytkownik biznesowy ma pytanie o dane, idzie do analityka, analityk buduje widok, filtr albo cały raport. Potem pytanie zmienia się o jeden wymiar i cykl zaczyna się od nowa. Znam tę dynamikę z wielu wdrożeń i szczerze mówiąc, to problem komunikacji między światem raportów a światem codziennych decyzji. Fabric Data Agent jest odpowiedzią Microsoft na tę lukę. Podchodzę do nowych narzędzi z rezerwą, bo większość z nich wymaga przekonywania użytkowników do zmiany nawyków. Tu jest inaczej. Użytkownicy zadają pytania tak samo, jak robili to dotąd. Tylko nie do człowieka, ale do systemu, który zna dane organizacji.
Czym jest Fabric Data Agent
To wyspecjalizowany asystent AI osadzony w systemie Microsoft Fabric, działający w tandemie z Power BI. Zakres ma wąski i konkretny: analizuje ustrukturyzowane dane biznesowe w odpowiedzi na pytania w naturalnym języku. Nie jest to ogólny model do pisania e-maili ani streszczania dokumentów. Agent ma dostęp do Twoich danych i to na ich podstawie buduje odpowiedzi. Baza wiedzy, z której korzysta, to tabele, relacje i miary zdefiniowane w Twojej organizacji.
Technicznie: gdy użytkownik zadaje pytanie, agent bierze pod uwagę swoje instrukcje początkowe, ewentualne przykłady zapytań i rozumowanie modelu językowego. Na tej podstawie generuje zapytanie DAX lub SQL, wysyła je do źródła danych, a wynik zwraca w przystępnej formie – najczęściej jako tabela. Rozmówca nie musi interesować się przebiegiem tego łańcucha działań, dla niego to po prostu odpowiedź.
Dostęp do agenta jest kontrolowany przez Entra ID. Dla dużych organizacji to warunek konieczny. Nie ma tu mowy o niekontrolowanym przepływie danych do zewnętrznego modelu.
Kiedy Fabric Data Agent ma sens
Nie odpowiem "zawsze" ani "dla każdego".
- Agent wnosi wartość, gdy dane są już w Microsoft Fabric - albo gdy ich przeniesienie tam jest planowane w najbliższym czasie. Może wtedy działać jako centralny punkt dostępu do wielu źródeł naraz: modeli semantycznych Power BI, tabel Lakehouse, danych operacyjnych. Pojedynczy raport pokazuje to, co analityk zaprojektował. Agent odpowiada na pytania, których nikt nie przewidział i robi to na podstawie tych samych relacji i miar, które już istnieją w modelu.
- Agent ma też sens tam, gdzie użytkownicy nie posługują się DAX ani SQL, a poza zespołem BI to praktycznie wszyscy. Handlowiec sprawdzający historię zamówień przed spotkaniem, kierownik logistyki szukający produktów z niskim stanem magazynowym, finansista weryfikujący marżę na konkretnym portfelu - każde z tych pytań można zadać wprost, bez pośrednika.
Warto też wziąć pod uwagę Teams. Jeśli organizacja go używa, a większość dużych firm w Polsce już tak, agent jest dostępny bez otwierania Fabric, bez dodatkowego logowania, z telefonu. Cała baza danych przez jedno okno czatu.
Kto skorzysta ze wsparcia Fabric Data Agent i co zyska
Widzę cztery grupy beneficjentów wdrożenia Fabric Data Agent:
- Handlowcy, kierownicy operacyjni, menedżerowie produktu - osoby bez kompetencji analitycznych zyskują bezpośredni dostęp do danych, o które wcześniej musieli prosić kogoś innego. Pytają tak, jak myślą: „jakie produkty schodzą najgorzej w tym miesiącu?" albo „który klient nie złożył zamówienia od ponad 30 dni?". Dostają tabelę.
- Zespoły BI odczuwają mniej doraźnych zapytań. To, co wcześniej lądowało jako ticket - „czy możesz mi wyciągnąć sprzedaż dla X w podziale na Y" - użytkownicy zaczynają obsługiwać sami. Czas analityków można wtedy przeznaczyć na budowanie raportów o wysokiej wartości analitycznej, zamiast odpowiadać na zapytania ad-hoc.
- Zarządzający zyskują możliwość weryfikacji danych operacyjnych bez angażowania pośredników. Pytanie rano przed spotkaniem zarządu, odpowiedź w dwie minuty przez Teams na telefonie - to inny poziom dostępu do informacji niż czekanie na przygotowane zestawienie.
- IT i administratorzy mają pełną kontrolę nad tym, do czego agent ma dostęp. Zarządzanie uprawnieniami odbywa się przez Entra ID i role zdefiniowane w Fabric. Interfejs czatu nie zmienia reguł bezpieczeństwa, które już istnieją w modelu.
Jak wygląda rozmowa z danymi w praktyce
Pracując z wygenerowanym przeze mnie modelem danych, skonfigurowałem agenta na przykładzie środowiska sprzedażowego: tabele klientów, zamówień, linii zamówień, produktów i magazynu - ze zdefiniowanymi relacjami.
Pierwsze pytanie: trzy ostatnie zamówienia konkretnego klienta. Agent zwrócił poprawne numery. Pytanie było jednak zbyt ogólne, więc doprecyzowałem je na dalszym etapie rozmowy - pokaż zawartość każdego zamówienia osobno, z datą, produktem, ilością i łączną wartością. Agent rozdzielił zapytanie na trzy osobne wywołania bazy danych i zwrócił trzy osobne tabele. Poprosiłem go jeszcze o sumę wartości każdego zamówienia poza tabelą, razem z datą i jego numerem. Uzyskałem akceptowalny format informacji, o które zapytałem.
Postanowiłem sprawdzić, jak poradzi sobie ze zmianą wątku: jak ten klient plasuje się względem pozostałych pod kątem wartości zamówień? Agent zwrócił zestawienie, ale z imionami i nazwiskami wszystkich klientów na liście - informacją, której nie chcę eksponować w udostępnianym widoku. Poprosiłem o zastąpienie danymi customer ID i rozszerzenie zestawienia do pełnej listy, z zaznaczeniem pozycji klienta, o którego pytałem. Dostałem dokładnie to.
Zmiana tematu w środku rozmowy nie wymagała zaczynania od nowa w większości przypadków. Agent zapamiętał wypracowany format tabeli. „Zrób to samo dla całego stycznia, ale nie rób rankingu klientów" - przyniosło to odpowiedź w strukturze, którą wcześniej zaakceptowałem.
Agent uczy się preferencji w toku rozmowy i utrzymuje kontekst. To akurat robi wyraźną różnicę w codziennym użyciu.
Złożone pytania i stan magazynowy
Drugie podejście: jedno złożone pytanie zamiast serii krótkich. Podaj sprzedaż konkretnego produktu w wybranym miesiącu - łączną ilość, wartość, zestawienie dat i ilości, zestawienie ilości per klient bez danych osobowych i aktualny stan magazynowy.
Agent podzielił to na cztery oddzielne zapytania i zwrócił kompletny obraz. Produkt sprzedał się w dziesięciu sztukach, na magazynie zostały cztery. Przy przewidywanym tempie sprzedaży to sygnał do jego uzupełnienia. Zadałem pytanie o inne produkty z niskim stanem magazynowym - i mam listę siedmiu pozycji do zamówienia, bez przekopywania raportów.
Takie pytania - szybkie, operacyjne, przekrojowe - to środowisko naturalne agenta. Raport ma stałą strukturę. Agent odpowiada na to, co akurat potrzebuje wiedzieć decydent, w tej chwili.
Obsługa błędnych lub nieprecyzyjnych pytań
Przykład z praktyki. Użytkownik pyta o produkt o nazwie „Bear Daisy" – w bazie istnieje wyłącznie „Deer Daisy". Żaden system oparty na dopasowaniu jeden do jednego tego nie znajdzie. Użytkownik dostaje informację, że produkt nie istnieje, i idzie dalej z błędnym przekonaniem.
Agent skonfigurowany z odpowiednią procedurą obsługi niedokładnych zapytań: rozkłada domniemaną nazwę na osobne wyrazy, przeszukuje kolumny nazw i kolekcji w tabeli produktów, zwraca wszystkie możliwe dopasowania. Użytkownik sam wybiera, o który produkt chodzi. W tym przypadku: agent zwrócił wszystkie produkty z kolekcji „Bear" i produkt z częściową nazwą „Daisy" - okazało się, że użytkownik po prostu nie pamiętał, jakie to było zwierzę. Pytanie trafiło, mimo że było błędne.
Ten mechanizm wymaga skonfigurowania, ponieważ nie działa domyślnie. I właśnie to ilustruje, czym jest praca z agentem od strony technicznej - to budowanie warstwy instrukcji i procedur wyjątkowych, które robią z niego coś użytecznego w prawdziwych scenariuszach.
Instrukcje decydują o jakości
Fabric Data Agent działa na podstawie instrukcji początkowych. Ich jakość bezpośrednio przekłada się na jakość odpowiedzi. W konfiguracji, którą buduję dla klientów, te instrukcje obejmują zazwyczaj kilka obszarów:
- opis roli agenta i zakresu jego kompetencji - żeby przy każdym pytaniu wiedział, czym jest i czego dotyczy,
- zasady komunikacji - preferowany format odpowiedzi (tabele), waluta, język, poziom szczegółowości,
- opis struktury bazy danych - szczególnie ważny przy źródłach takich jak Lakehouse, gdzie relacje nie są zdefiniowane tak jak w modelu semantycznym,
- procedury obsługi wyjątków - co zrobić z pytaniem, którego agent nie rozumie lub które dotyczy nieistniejących danych.
Instrukcje powinny rosnąć iteracyjnie, wraz z praktyką użytkowników. Jeśli dwa razy z rzędu użytkownik prosi o ukrycie danych osobowych klientów - to sygnał, żeby tę regułę wpisać do domyślnych instrukcji, a nie czekać na trzeci raz. Agent poprawia się nie przez aktualizacje modelu, ale przez rozbudowę swojej konfiguracji.
Kilka rzeczy technicznych, które mają znaczenie przy przygotowaniu danych: nazwy tabel i kolumn powinny być czytelne, nie systemowe. „CustomerID" działa. „CustID_v2_final" nie. Jeśli model semantyczny Power BI zawiera miary, warto dodać do nich opisy – Power BI Desktop ma wbudowaną opcję generowania opisów miar przez model językowy. Agent korzysta z tych opisów, zamiast generować interpretację na żywo.
Logi zapytań jako narzędzie do rozbudowy raportów
Jeden aspekt, który szczególnie cenię: każde zapytanie DAX lub SQL wygenerowane przez agenta jest widoczne w logu razem z opisem jego logiki. To nie tylko narzędzie diagnostyczne.
Jeśli użytkownicy cyklicznie zadają agentowi to samo pytanie – np. o udział procentowy sprzedaży produktów w danym miesiącu – mam gotowy kod DAX, który mogę przenieść do raportu Power BI jako miarę lub wizualizację. Agent nie tylko odpowiada na bieżące pytania, wskazuje też, czego brakuje w istniejących raportach.
To moim zdaniem właściwy sposób myślenia o tych dwóch narzędziach: agent na etapie eksploracji i codziennych pytań operacyjnych, raport jako docelowa forma regularnych analiz. Jedno bez drugiego ma mniejszy sens.
Czego Fabric Data Agent nie zrobi
Wizualizacji. Agent nie rysuje wykresów, nie buduje macierzy, nie tworzy pulpitów. Gdy użytkownik poprosi o wykres, agent zaproponuje przeniesienie pytania do raportu i wygeneruje kod DAX do wykorzystania. Jest tak zaprojektowany i - uczciwie - słusznie. Próba wymuszenia wizualizacji przez model językowy kończy się zwykle kiepską pracą z Pythonem. Lepiej zostawić każdemu narzędziu to, w czym jest dobre.
Fabric Data Agent sprawdza się w eksploracji: szybkich, nieregularnych, operacyjnych pytaniach o dane. Raport Power BI sprawdza się w prezentacji: cyklicznych, ustandaryzowanych, wizualnych analizach. Dla decydenta, który potrzebuje i dashboardu na spotkanie, i odpowiedzi na pytanie godzinę przed nim – to razem ma sens.
FAQ o Fabric Data Agent
Czy Fabric Data Agent wymaga przebudowy istniejącej infrastruktury danych?
Nie, jeśli dane są już w Microsoft Fabric. Agent łączy się z istniejącymi modelami semantycznymi Power BI i tabelami Lakehouse – bez migracji ani przebudowy modeli. Warto natomiast zadbać o jakość metadanych: czytelne nazwy tabel i kolumn oraz opisy miar wyraźnie poprawiają precyzję odpowiedzi i skracają czas konfiguracji.
Jak kontrolować, jakie dane są dostępne dla Fabric Data Agent i dla poszczególnych użytkowników?
Dostęp jest zarządzany przez Microsoft Entra ID i role zdefiniowane w Fabric. Konfigurator agenta wskazuje, do których tabel i źródeł danych ma on dostęp. Użytkownicy widzą wyłącznie dane, do których mają uprawnienia zgodnie z rolami w modelu semantycznym lub w Lakehouse. Interfejs czatu nie otwiera tu żadnego bocznego wejścia.
Ile czasu zajmuje wdrożenie i konfiguracja agenta Fabric Data w środowisku produkcyjnym?
Zależy od jakości danych wejściowych. Jeśli model semantyczny Power BI jest dobrze zbudowany, ma sensowne nazewnictwo i miary z opisami - pierwsze działające środowisko można skonfigurować w ciągu jednego dnia. Iteracyjne dopracowanie instrukcji, testowanie z użytkownikami i obsługa przypadków brzegowych to kolejny etap, który realizujemy razem z klientem w toku pilotażu.
