Fabric i Copilot Studio: jak przygotować dane dla AI

Fundamentem AI w firmie jest możliwość ustalenia, skąd pochodzi odpowiedź, czy dane są aktualne i kto odpowiada za ich znaczenie. Microsoft Fabric może pomóc przygotować dane do analizy, a Copilot Studio zbudować agenta korzystającego z firmowej wiedzy i narzędzi. Żadna z tych platform nie zastąpi jednak uzgodnienia procesu, dostępu i kryteriów poprawności.

Jeżeli chcesz uruchomić asystenta dla pracowników, zacznij od jednej decyzji, którą ma wspierać. Przykładowo: sprawdzenie statusu realizacji zlecenia i wskazanie obowiązującej procedury opóźnienia. Taki zakres pozwala sprawdzić zarówno liczby, jak i dokumenty. Ogólne polecenie „połączmy wszystkie dane z AI” nie daje równie czytelnego sposobu odbioru.

Rozdziel trzy rodzaje potrzeb

Pierwsza potrzeba to odczyt wiedzy opisowej: zasad, instrukcji i procedur. Tu ważna jest właściwa wersja dokumentu oraz zakres jego obowiązywania. Druga to obliczenie wyniku na danych strukturalnych, na przykład liczby opóźnionych zleceń. Wymaga ono jednoznacznej definicji miary i kompletnych danych. Trzecia to wykonanie działania, takiego jak zmiana terminu lub wysłanie zgłoszenia.

Te potrzeby mogą występować w jednej rozmowie, ale mają różne warunki poprawności. Odpowiedź zawierająca link do procedury nie dowodzi, że agent poprawnie policzył opóźnienia. Z kolei poprawna liczba nie uprawnia go automatycznie do zmiany danych w systemie operacyjnym.

Przed projektem zapisz, które z tych zadań obejmuje pierwszy etap. Jeśli celem jest szybkie odnajdywanie procedur, pełna platforma analityczna może nie być potrzebna. Jeśli agent ma porównywać wyniki kilku systemów, przygotowanie wspólnego modelu danych staje się osobnym, istotnym zadaniem.

Rola Fabric i Copilot Studio

Microsoft Fabric łączy możliwości integracji, przetwarzania, przechowywania i analizy danych. OneLake stanowi wspólną warstwę przechowywania dla platformy, a poszczególne narzędzia obsługują różne zadania. Zakres przedstawia przegląd Microsoft Fabric.

Copilot Studio pozwala konfigurować agentów korzystających ze źródeł wiedzy. Obsługiwane źródła i sposób uwierzytelniania różnią się między innymi dla witryn, dokumentów, SharePoint i Dataverse. Aktualne zasady opisuje dokumentacja źródeł wiedzy Copilot Studio.

Połączenie tych obszarów wymaga świadomego projektu. Nie zakładaj, że umieszczenie tabeli w Fabric automatycznie udostępnia ją każdemu agentowi albo że wszystkie źródła dziedziczą identyczne uprawnienia. Wybierz wspierany sposób integracji dla konkretnego scenariusza, a potem sprawdź tożsamość, zakres danych i zachowanie po odebraniu dostępu.

Nie utożsamiaj też Copilot Studio z gotowymi funkcjami Copilot w aplikacjach Microsoft. Budowanie własnego agenta i korzystanie z asystenta analityka to różne zadania. W projekcie nazwij dokładnie komponenty, za które płacisz i które zespół będzie utrzymywać.

Zacznij od kontraktu na odpowiedź

Kontrakt nie musi być rozbudowanym dokumentem. To opis tego, co użytkownik może zapytać, z jakiego źródła pochodzi wynik i kiedy agent powinien odmówić odpowiedzi lub przekazać sprawę człowiekowi. Taki zapis pozwala ocenić projekt przed wyborem szczegółowej architektury.

Pytanie użytkownika	Potrzebne źródło	Warunek poprawnej odpowiedzi
Które zlecenia są opóźnione?	Dane o terminie i statusie	Uzgodniona definicja opóźnienia i czas aktualności
Co zrobić przy opóźnieniu?	Obowiązująca procedura	Właściwa wersja dla danej jednostki
Czy mogę zmienić termin?	Reguły procesu i uprawnienia	Rozpoznana rola oraz dozwolony zakres działania
Dlaczego wynik różni się od raportu?	Definicja miary i filtry	Możliwość odtworzenia obliczenia

Do każdego pytania dodaj przykład, w którym agent nie powinien zgadywać. Może brakować terminu zlecenia, procedura może mieć dwie sprzeczne wersje albo użytkownik nie mieć dostępu do oddziału. Poprawna odpowiedź w takich sytuacjach często polega na wyjaśnieniu ograniczenia.

To także moment, aby ustalić język komunikatu. „Nie znalazłem danych” może oznaczać brak rekordu, brak uprawnienia lub awarię integracji. Zespół powinien rozróżniać te przyczyny w diagnostyce, a użytkownik otrzymywać informację wystarczającą do kolejnego działania bez ujawniania niedostępnych danych.

Przygotuj dane do konkretnego zastosowania

Dla analizy zleceń potrzebujesz identyfikatora, statusu, dat i definicji zakończenia. Sprawdź, czy dwa systemy używają tego samego identyfikatora klienta. Jeśli nie, zaprojektuj mapowanie oraz obsługę przypadków niejednoznacznych. Model językowy nie powinien samodzielnie rozstrzygać, że podobne nazwy oznaczają tę samą firmę.

Zapisz zasady korekt. Jeżeli termin został zmieniony, analiza może dotyczyć terminu pierwotnego albo aktualnego. Oba wyniki mogą być poprawne, ale odpowiadają na inne pytania. Potrzebujesz historii zmian, gdy chcesz oceniać, czy przesuwanie terminów nie ukrywa opóźnień.

Określ także wymaganą aktualność. Dla planowania tygodnia wystarczy inny rytm niż dla informacji udzielanej klientowi podczas rozmowy. Nie zwiększaj częstotliwości przetwarzania bez potrzeby. Koszt szybszego zasilania ma uzasadnienie wtedy, gdy zmienia możliwość podjęcia decyzji w odpowiednim czasie.

Dokumenty przygotuj równie starannie. Każda procedura powinna mieć właściciela, wersję i zakres obowiązywania. Usuń lub wyraźnie oddziel materiały archiwalne. Agent korzystający z wielu podobnych instrukcji może znaleźć tekst pasujący językowo, ale nieobowiązujący w danej sytuacji.

Uprawnienia sprawdź z perspektywy odbiorcy

Nie kończ testu na koncie twórcy. Przygotuj role odpowiadające rzeczywistym użytkownikom: pracownik oddziału, kierownik regionu i osoba z centrali. Zadaj te same pytania i sprawdź, czy zakres odpowiedzi odpowiada uprawnieniom każdego z nich.

Przetestuj także odebranie dostępu. Pracownik, który zmienił rolę, nie powinien nadal otrzymywać informacji tylko dlatego, że wcześniejsza konfiguracja źródła była wygodna. Ustal, które elementy korzystają z tożsamości użytkownika, a które z połączenia technicznego. To rozróżnienie wpływa na projekt kontroli.

W przypadku działań zapisujących dane dodaj osobny odbiór. Sprawdź wymagane potwierdzenie, dozwolone wartości i sposób zapobiegania powtórzeniu tej samej operacji. Zapis w systemie powinien pozostawiać ślad pozwalający ustalić, kto zlecił zmianę i jaki był jej rezultat.

Syntetyczny przykład oceny agenta

Załóżmy zestaw 100 pytań kontrolnych przygotowanych przez właściciela procesu. Agent udziela 80 poprawnych odpowiedzi z właściwym źródłem, w 10 przypadkach prawidłowo wskazuje brak wystarczających danych, a w 10 podaje błędny wynik. To przykład modelowy, nie rezultat wdrożenia.

Nie można opisać go jako stuprocentowej skuteczności tylko dlatego, że agent odpowiedział na wszystkie pytania. Poprawne odpowiedzi stanowią 80% zestawu. Jeżeli oczekiwane zachowanie obejmuje również zasadną odmowę, 90 przypadków spełnia kryterium zadania. Nadal pozostaje 10 błędów wymagających osobnej analizy.

Podziel je według przyczyn: nieaktualne źródło, zła definicja, nieprawidłowy filtr, brak danych lub błędna interpretacja. Zmiana polecenia może pomóc w ostatnim przypadku, ale nie naprawi brakującej historii terminów. Taki podział chroni przed wielokrotnym poprawianiem instrukcji agenta, gdy problem leży w danych.

Oceń też wagę błędów. Pomyłka w kolejności neutralnej listy i ujawnienie danych innego klienta nie mogą otrzymać tej samej oceny. Dla zdarzeń krytycznych ustal warunek zatrzymania pilotażu oraz osobę decydującą o ponownym uruchomieniu po poprawce.

Jak zorganizować odbiór

Obszar	Próba	Dowód do zachowania
Dane liczbowe	Porównanie z ręcznie policzonym zestawem	Dane wejściowe, filtry i oczekiwany wynik
Wiedza opisowa	Pytanie o wersję i wyjątek w procedurze	Cytowane źródło oraz ocena właściciela
Dostęp	Ta sama rozmowa w różnych rolach	Zakres widocznych informacji
Awaria	Niedostępne źródło lub niepełne zasilanie	Komunikat dla użytkownika i zapis diagnostyczny
Działanie	Powtórzenie żądania po przerwaniu połączenia	Brak niezamierzonego podwójnego zapisu

Zachowuj wersję konfiguracji i datę próby. Po zmianie źródła, modelu lub instrukcji powtórz najważniejsze przypadki. Jednorazowy sukces nie gwarantuje, że odpowiedzi pozostaną poprawne po aktualizacji dokumentów albo dodaniu nowego oddziału.

Nie buduj zestawu kontrolnego wyłącznie z pytań zadanych przez twórcę. Zaproś osoby, które będą korzystać z rozwiązania, i zapisz ich naturalne sformułowania. Użytkownik może pytać o „zaległe sprawy”, podczas gdy model używa pojęcia „zlecenia po terminie”. Trzeba ustalić, czy te wyrażenia rzeczywiście oznaczają to samo.

Koszt licz dla całego procesu

Uwzględnij przygotowanie danych, utrzymanie integracji, zasoby platform, użycie agenta oraz czas kontroli wyników. Sam koszt odpowiedzi jest zbyt wąską miarą. Tani agent wymagający częstego poprawiania danych może być droższy w utrzymaniu niż prostsze rozwiązanie ograniczone do dobrze przygotowanego zakresu.

W pilotażu mierz czas do poprawnego zakończenia zadania. Jeżeli pracownik szybciej znajduje procedurę, ale później długo wyjaśnia sprzeczną odpowiedź, uwzględnij oba etapy. Zapisz też, czy rozwiązanie skróciło pracę, poprawiło dostępność wiedzy, czy umożliwiło zadanie wcześniej niewykonywane. To różne rodzaje wartości.

Nie przeliczaj każdej zaoszczędzonej minuty automatycznie na gotówkę. Uwolniony czas może zostać wykorzystany na lepszą obsługę, większą liczbę spraw albo ograniczenie nadgodzin. Efekt finansowy zależy od tego, co organizacja faktycznie zrobi z dodatkową możliwością pracy.

Wdrażaj etapami i zachowaj drogę powrotu

Pierwszy etap może obejmować odczyt informacji przez małą grupę użytkowników. Dopiero po sprawdzeniu jakości dodaj kolejne źródło albo możliwość działania. Dzięki temu łatwiej ustalić przyczynę błędu i ograniczyć zakres poprawki.

Przed uruchomieniem opisz sposób wyłączenia funkcji, kontakt do wsparcia i alternatywną ścieżkę wykonania zadania. Użytkownik powinien wiedzieć, jak sprawdzić zlecenie, gdy agent jest niedostępny. Plan awaryjny jest częścią normalnego projektu usługi, a nie dowodem braku zaufania do technologii.

Właściciel procesu powinien regularnie przeglądać pytania bez odpowiedzi, błędy i zmiany źródeł. Zespół techniczny odpowiada za działanie integracji, ale to biznes określa, czy wynik nadal odpowiada potrzebom. Bez takiego przeglądu nawet dobrze odebrany agent stopniowo rozmija się z rzeczywistym procesem.

Ustal granice pierwszej wersji

Dobrym ograniczeniem jest wskazanie jednego działu, jednego rodzaju zleceń i zamkniętej listy źródeł. Pytania spoza tego zakresu kieruj do dotychczasowej obsługi. Dzięki temu użytkownicy nie muszą zgadywać, czy agent potrafi odpowiedzieć na sprawę, której zespół jeszcze nie testował.

Zapisz te granice także w materiale dla użytkowników. Komunikat powinien wyjaśniać, jakie zadania rozwiązanie wspiera i gdzie szukać pomocy przy pozostałych. Rozszerzenie zakresu traktuj jak zmianę produktu: dodaj przypadki kontrolne, sprawdź dostęp i uzyskaj odbiór właściciela procesu. Samo podłączenie kolejnego źródła nie jest wystarczającym potwierdzeniem gotowości.

Co przygotować przed wyborem architektury

Zapisz jeden scenariusz, listę źródeł, wymagany czas aktualności i role użytkowników. Dodaj zestaw pytań z oczekiwanym wynikiem oraz osobę, która go zatwierdzi. Taki materiał pozwala rozmawiać o konkretnym rozwiązaniu zamiast o ogólnym potencjale AI.

Warstwę przechowywania danych rozwijam w artykule co to jest OneLake w Microsoft Fabric. Całość połącz z systemem wdrażania AI w firmie, w którym technologia ma właściciela, cel i sposób sprawdzenia efektu. Pierwszym sukcesem jest wiarygodna odpowiedź na ważne pytanie, którą użytkownik potrafi bezpiecznie wykorzystać w pracy.