Sztuczna inteligencja w analityce biznesowej nie zaczyna się od promptów, modeli predykcyjnych ani efektownych dashboardów. Zaczyna się od danych. Jeżeli dane są rozproszone, niespójne, źle opisane albo niezrozumiałe dla użytkowników biznesowych, Copilot będzie udzielał nieprecyzyjnych odpowiedzi, a modele predykcyjne będą generowały wyniki, którym trudno zaufać.
Microsoft Fabric odpowiada na ten problem, łącząc w jednej platformie obszary takie jak integracja danych, inżynieria danych, hurtownia danych, data science, analityka czasu rzeczywistego i raportowanie. Wspólnym fundamentem jest OneLake, czyli centralna warstwa przechowywania danych, z której mogą korzystać różne doświadczenia Fabric i Power BI.
Dla firm rozważających wdrożenie Microsoft Fabric kluczowe pytanie brzmi więc nie: „Czy możemy używać AI?”, ale: czy nasze dane są przygotowane tak, aby AI mogła z nich korzystać bezpiecznie, spójnie i zgodnie z logiką biznesową?
AI w Fabric: dwa główne scenariusze
W praktyce warto rozróżnić dwa typy zastosowań AI w analityce biznesowej.
Pierwszy to Copilot i konwersacyjna analiza danych. Użytkownik zadaje pytanie językiem naturalnym, na przykład: „Który kanał sprzedaży miał najwyższą marżę w ostatnim kwartale?” albo „Dlaczego spadła sprzedaż w regionie południowym?”. Copilot może pomagać w analizie, tworzeniu raportów, pracy z modelem semantycznym czy generowaniu zapytań, ale jakość jego odpowiedzi zależy od jakości danych, nazw, metryk, relacji i opisów w modelu. Microsoft wprost podkreśla, że nieprzygotowany model semantyczny może prowadzić do niskiej jakości lub mylących odpowiedzi Copilota.
Drugi scenariusz to modele predykcyjne, czyli prognozowanie sprzedaży, przewidywanie churnu, scoring klientów, analiza ryzyka, rekomendacje produktowe czy wykrywanie anomalii. W Fabric można budować procesy data science obejmujące eksplorację danych, czyszczenie, przygotowanie, trenowanie modeli, scoring i udostępnianie wyników w raportach BI.
Oba scenariusze wymagają podobnego fundamentu: uporządkowanych, dobrze opisanych, kontrolowanych i aktualnych danych.
Dlaczego „surowe dane” nie wystarczą?
Wiele organizacji zaczyna od prostego założenia: skoro mamy dane w CRM, ERP, Excelach, systemie sprzedażowym czy e-commerce, to wystarczy je podłączyć do narzędzia AI. W rzeczywistości to najkrótsza droga do chaosu.
Surowe dane zwykle zawierają duplikaty, braki, różne formaty dat, niespójne nazwy klientów, niejednolite waluty, błędne kategorie produktów, ręcznie dopisywane komentarze i pola techniczne niezrozumiałe dla użytkownika biznesowego. Człowiek często potrafi domyślić się, że „Przychód netto”, „Net Sales” i „Sprzedaż bez VAT” oznaczają podobną kategorię. Model AI może jednak potraktować je jako różne pojęcia, o ile nie zostanie mu dostarczony uporządkowany kontekst.
Dlatego przygotowanie danych pod Copilota i modele predykcyjne powinno obejmować nie tylko techniczne załadowanie tabel, ale też zbudowanie warstwy znaczeniowej: definicji, relacji, miar, opisów, reguł jakości i odpowiedzialności za dane.
Architektura medallion: od danych surowych do danych gotowych na AI
Jednym z praktycznych podejść w Microsoft Fabric jest organizacja danych w architekturze medallion: bronze, silver i gold. Warstwa bronze przechowuje dane surowe, silver zawiera dane oczyszczone i wzbogacone, a gold dane biznesowo przygotowane do analityki, raportowania i dalszego wykorzystania.
W kontekście AI ta architektura ma ogromne znaczenie.
Bronze to miejsce na dane źródłowe w możliwie niezmienionej postaci. Dzięki temu organizacja zachowuje historię i może wrócić do pierwotnego zapisu, jeśli pojawią się wątpliwości.
Silver to warstwa porządkowania. Tutaj warto usuwać duplikaty, standaryzować formaty, ujednolicać słowniki, poprawiać typy danych, łączyć dane z różnych systemów i oznaczać rekordy problematyczne.
Gold to warstwa biznesowa. To właśnie ona powinna być podstawą dla raportów Power BI, Copilota, modeli semantycznych i wielu modeli predykcyjnych. Dane w tej warstwie powinny być zrozumiałe nie tylko dla zespołu IT, ale również dla sprzedaży, finansów, marketingu, HR czy zarządu.
Dla Copilota szczególnie ważna jest warstwa gold, ponieważ to na jej podstawie użytkownik biznesowy będzie zadawał pytania. Dla modeli predykcyjnych równie ważna jest warstwa silver, ponieważ to tam powstają cechy, historia i zestawy treningowe.
Model semantyczny: język biznesu dla Copilota
Jednym z najczęstszych błędów przy wdrażaniu AI w analityce jest pomijanie modelu semantycznego. Tymczasem w Power BI i Microsoft Fabric model semantyczny pełni rolę tłumacza między technicznymi tabelami a językiem biznesowym. Microsoft opisuje go jako logiczny opis domeny analitycznej, obejmujący metryki, przyjazną terminologię biznesową i strukturę umożliwiającą głębszą analizę.
Dobrze przygotowany model semantyczny powinien odpowiadać na pytania:
- Co dokładnie oznacza „sprzedaż”? Czy jest to sprzedaż brutto, netto, z rabatami, po korektach, po zwrotach?
- Jak liczona jest marża?
- Która data jest właściwa dla analizy: data zamówienia, data faktury, data wysyłki czy data płatności?
- Czy klient aktywny to taki, który kupił w ostatnich 30, 90 czy 180 dniach?
- Które miary są oficjalne, a które pomocnicze?
- Dla użytkownika są to pytania biznesowe. Dla Copilota są to elementy kontekstu, bez których łatwo o błędną interpretację.
- Jak przygotować model pod Copilota?
Przygotowanie danych pod Copilota nie polega wyłącznie na tym, że „włączymy Copilot w Power BI”. To proces modelowania i dokumentowania danych.
Po pierwsze, trzeba zadbać o czytelne nazwy tabel, kolumn i miar. Nazwy techniczne typu fct_sales_hdr, cust_id, rev_net_adj mogą być zrozumiałe dla twórców hurtowni, ale nie są dobrym językiem dla użytkownika biznesowego ani dla AI. Lepsze będą nazwy typu „Sprzedaż”, „Klient”, „Przychód netto po rabatach”, „Region sprzedaży”.
Po drugie, należy tworzyć opisy kolumn i miar. Copilot nie powinien zgadywać, czym różni się „wartość zamówienia” od „wartości faktury”. Opisy pomagają osadzić odpowiedzi w kontekście biznesowym.
Po trzecie, trzeba ograniczać niejednoznaczność. Jeżeli w modelu istnieją trzy podobne miary sprzedaży, użytkownik powinien wiedzieć, która jest oficjalna. W przeciwnym razie Copilot może wybrać metrykę, która formalnie istnieje w modelu, ale nie odpowiada intencji pytania.
Po czwarte, warto korzystać z funkcji przygotowania danych pod AI w Power BI, takich jak AI data schemas, verified answers czy AI instructions. Microsoft wskazuje te mechanizmy jako sposób na zmniejszenie niejednoznaczności i poprawę jakości odpowiedzi Copilota.
Dane pod modele predykcyjne: czego potrzebuje machine learning?
Modele predykcyjne mają inne wymagania niż Copilot. Copilot potrzebuje przede wszystkim dobrze opisanego kontekstu i modelu semantycznego. Machine learning potrzebuje dodatkowo historii, cech, zmiennej celu i stabilnego procesu aktualizacji danych.
Przykład: jeśli firma chce przewidywać odejście klienta, musi najpierw zdefiniować, czym jest churn. Czy chodzi o brak zakupu przez 90 dni? Rezygnację z umowy? Brak odnowienia subskrypcji? Spadek wartości zamówień poniżej określonego progu?
Następnie trzeba przygotować dane historyczne: transakcje, kontakt z obsługą klienta, reklamacje, aktywność w aplikacji, historię płatności, segment klienta, kampanie marketingowe czy rabaty. Dopiero na tej podstawie można zbudować zestaw treningowy.
W Fabric obszar Data Science wspiera proces obejmujący eksplorację, przygotowanie i czyszczenie danych, eksperymentowanie, modelowanie, scoring oraz przekazywanie predykcji do raportów BI.
Najważniejsze zasady przygotowania danych pod predykcję
Pierwsza zasada: nie wolno mieszać przyszłości z przeszłością. Model predykcyjny powinien uczyć się tylko na informacjach, które były dostępne w momencie podejmowania decyzji. Jeżeli do danych treningowych przypadkiem trafi informacja znana dopiero po fakcie, model będzie wyglądał świetnie w testach, ale zawiedzie w realnym użyciu.
Druga zasada: potrzebna jest odpowiednia granularność danych. Inaczej przygotowuje się dane dla prognozy miesięcznej sprzedaży, inaczej dla predykcji odejścia klienta, a jeszcze inaczej dla rekomendacji kolejnego produktu. Zbyt ogólne dane mogą ukrywać istotne wzorce, a zbyt szczegółowe mogą generować szum.
Trzecia zasada: cechy muszą mieć sens biznesowy. Liczba zakupów w ostatnich 30 dniach, średnia wartość koszyka, liczba reklamacji, opóźnienia w płatnościach, częstotliwość logowania czy czas od ostatniej transakcji mogą być dużo bardziej wartościowe niż surowa tabela transakcji.
Czwarta zasada: trzeba monitorować jakość danych w czasie. Model, który działał dobrze pół roku temu, może tracić skuteczność, jeśli zmieniły się ceny, zachowania klientów, kampanie marketingowe, sezonowość albo proces sprzedaży.
Dataflows Gen2, lakehouse, warehouse i notebooks: co wybrać?
Microsoft Fabric daje kilka ścieżek przygotowania danych. Dataflows Gen2 sprawdzają się tam, gdzie zespół chce wizualnie pobierać, przekształcać i ładować dane, korzystając z doświadczenia zbliżonego do Power Query. Microsoft opisuje Dataflows Gen2 jako technologię samoobsługowego przygotowania danych, a dokumentacja wskazuje również integrację z Copilotem w Fabric, pozwalającą wspierać tworzenie transformacji językiem naturalnym.
Lakehouse będzie naturalnym wyborem dla organizacji, które chcą łączyć elastyczność data lake z uporządkowaną analityką. Warehouse sprawdzi się tam, gdzie dominuje model hurtowniany, SQL i klasyczna analityka relacyjna. Notebooks są dobrym narzędziem dla zespołów data science i data engineering, które potrzebują większej kontroli nad kodem, eksperymentami i przygotowaniem cech.
Nie chodzi więc o wybór jednego narzędzia dla wszystkich. Chodzi o zaprojektowanie procesu, w którym dane trafiają do właściwej warstwy, są transformowane we właściwym miejscu, a użytkownik końcowy korzysta z wersji danych, która jest gotowa do analizy.
Direct Lake i wydajność analityki AI
W scenariuszach Power BI ważną rolę może odegrać Direct Lake. To tryb, w którym model semantyczny może korzystać z danych w OneLake bez klasycznego importowania pełnej kopii danych do modelu. Microsoft wskazuje Direct Lake jako szczególnie przydatny dla dużych lakehouse’ów, warehouse’ów i źródeł Fabric opartych o tabele Delta, zwłaszcza gdy pełne kopiowanie danych do modelu importowanego byłoby niepraktyczne.
Z perspektywy AI ma to znaczenie praktyczne: organizacja może budować bardziej aktualne i skalowalne modele analityczne, a jednocześnie utrzymywać centralny porządek danych w OneLake. Nie zwalnia to jednak z obowiązku modelowania. Szybszy dostęp do danych nie oznacza automatycznie lepszych odpowiedzi Copilota ani lepszych predykcji.
Governance: AI musi wiedzieć, do czego ma dostęp
Przygotowanie danych pod AI to także bezpieczeństwo. Copilot i agenci danych nie powinni być traktowani jak narzędzia działające „obok” systemu uprawnień. Microsoft podkreśla, że Copilot w Fabric wymaga odpowiednich ustawień administracyjnych, dostępności regionalnej i zarządzania dostępem użytkowników.
W praktyce oznacza to konieczność uporządkowania ról, workspace’ów, dostępu do modeli semantycznych, danych źródłowych, raportów i obszarów roboczych. Jeżeli użytkownik nie powinien widzieć marż, wynagrodzeń, danych osobowych albo szczegółów klientów strategicznych, mechanizmy bezpieczeństwa muszą być zaprojektowane przed udostępnieniem AI szerzej w organizacji.
Warto również oznaczać oficjalne zbiory danych, certyfikować modele, wyznaczać właścicieli danych i prowadzić dokumentację definicji biznesowych. Bez tego AI może przyspieszyć nie tylko analizę, ale również rozprzestrzenianie błędnych interpretacji.
Fabric Data Agent: kolejny krok w rozmowie z danymi
Oprócz Copilota coraz ważniejszym elementem ekosystemu Fabric są data agents. Fabric data agent pozwala tworzyć konwersacyjne doświadczenia AI, które odpowiadają na pytania dotyczące danych przechowywanych między innymi w lakehouse, warehouse, modelach semantycznych Power BI, bazach KQL, ontologiach czy Microsoft Graph.
Dla firm oznacza to przesunięcie z klasycznego modelu „otwórz raport i znajdź odpowiedź” w stronę modelu „zadaj pytanie i otrzymaj odpowiedź osadzoną w danych organizacji”. Ale tutaj również obowiązuje ta sama zasada: agent będzie tak dobry, jak dobre są dane, definicje, uprawnienia i źródła, które mu udostępnimy.
Praktyczna checklista: czy dane są gotowe na Copilota i predykcję?
Przed uruchomieniem AI w analityce warto przejść przez kilka pytań kontrolnych.
Czy mamy zdefiniowane oficjalne źródła danych dla kluczowych obszarów biznesu?
Czy dane są uporządkowane w warstwach, na przykład bronze, silver i gold?
Czy istnieje model semantyczny opisany językiem biznesowym?
Czy najważniejsze miary mają jednoznaczne definicje?
Czy kolumny, tabele i relacje mają zrozumiałe nazwy?
Czy użytkownicy wiedzą, które raporty i modele są oficjalne?
Czy dane historyczne są wystarczające do trenowania modeli predykcyjnych?
Czy mamy jasno zdefiniowaną zmienną celu dla predykcji?
Czy kontrolujemy jakość danych, braki, duplikaty i anomalie?
Czy obowiązują właściwe uprawnienia, RLS/OLS i zasady dostępu?
Czy AI była testowana na realnych pytaniach użytkowników biznesowych?
Jeżeli odpowiedź na większość tych pytań brzmi „nie”, wdrożenie Copilota lub modeli predykcyjnych może przynieść rozczarowanie. Nie dlatego, że technologia nie działa, ale dlatego, że organizacja nie przygotowała dla niej właściwego gruntu.
Jak zacząć wdrożenie AI w Microsoft Fabric?
Najlepiej zacząć od jednego konkretnego procesu biznesowego. Może to być analiza sprzedaży, rentowności klientów, rotacji pracowników, stanów magazynowych, reklamacji albo skuteczności kampanii marketingowych.
Pierwszym krokiem powinien być audyt danych: skąd pochodzą, kto za nie odpowiada, jakie mają problemy jakościowe i które definicje są sporne.
Drugim krokiem jest przygotowanie warstw danych, najlepiej z rozdzieleniem danych surowych, oczyszczonych i biznesowo gotowych.
Trzecim krokiem jest budowa modelu semantycznego, który będzie zrozumiały dla użytkowników i przyjazny dla AI.
Czwartym krokiem jest pilotaż Copilota na ograniczonej grupie użytkowników i zestawie sprawdzonych pytań.
Piątym krokiem może być pierwszy model predykcyjny, na przykład prognoza sprzedaży, predykcja churnu albo scoring klientów.
Dopiero później warto skalować rozwiązanie na kolejne obszary organizacji.
Podsumowanie
Microsoft Fabric daje firmom bardzo mocny fundament pod nowoczesną analitykę biznesową wspieraną przez AI. Łączy dane, integrację, modelowanie, raportowanie, data science i mechanizmy Copilota w jednym ekosystemie. Jednak sama platforma nie rozwiązuje automatycznie problemu jakości, znaczenia i odpowiedzialności za dane.
Copilot potrzebuje dobrze przygotowanego modelu semantycznego, zrozumiałych nazw, opisów, miar i reguł biznesowych. Modele predykcyjne potrzebują historii, stabilnych cech, poprawnie zdefiniowanej zmiennej celu i kontroli jakości danych. Oba scenariusze potrzebują governance, bezpieczeństwa i jasnego właścicielstwa danych.
Dlatego najważniejsza zasada brzmi: AI w analityce biznesowej nie zaczyna się od algorytmu. Zaczyna się od uporządkowanych danych.
Firmy, które potraktują Microsoft Fabric nie tylko jako narzędzie raportowe, ale jako kompleksową platformę do zarządzania cyklem życia danych, będą mogły wykorzystać AI znacznie skuteczniej – nie jako efektowny dodatek, lecz jako realne wsparcie decyzji biznesowych.