AI Builder: kiedy użyć modeli w Power Platform

AI Builder ma sens wtedy, gdy model wspiera konkretną decyzję w procesie Power Platform i można sprawdzić jakość jego wyniku. Samo dodanie rozpoznawania dokumentu, predykcji albo promptu nie usprawnia pracy. Potrzebne są dane wejściowe, próg akceptacji, obsługa wyjątków i osoba odpowiedzialna za rezultat.

Microsoft opisuje AI Builder jako funkcję Power Platform pozwalającą używać modeli AI w Power Apps i Power Automate. Dostępne są modele gotowe oraz modele dostosowywane do danych organizacji. Część funkcji może pozostawać w wersji zapoznawczej lub różnić się dostępnością regionalną, dlatego status trzeba potwierdzić przed projektem produkcyjnym. Przegląd AI Builder w Microsoft Learn.

Zacznij od decyzji, nie od rodzaju modelu

Opisz pojedynczy moment procesu. Przykładem może być odczyt numeru faktury, zaklasyfikowanie zgłoszenia albo skierowanie dokumentu do właściwej osoby. Ustal, co pracownik robi obecnie, jaki błąd jest kosztowny i jaki wynik modelu będzie użyteczny.

AI Builder udostępnia między innymi modele i prompty używane w aplikacjach oraz przepływach. Dokumentacja obejmuje tworzenie modeli, modele wstępnie zbudowane, zarządzanie oraz używanie wyników w Power Apps i Power Automate. Nie oznacza to, że każdy rodzaj danych pasuje do każdego modelu. Dokumentacja AI Builder.

Pytanie przed budową	Dlaczego jest potrzebne
Jaka decyzja korzysta z wyniku?	Oddziela ciekawy eksperyment od procesu
Jak wygląda poprawna odpowiedź?	Umożliwia przygotowanie testu
Co dzieje się przy niepewności?	Zapobiega automatyzacji błędnej decyzji
Kto może zobaczyć dane?	Wyznacza dostęp i sposób przechowywania
Kto poprawia działanie modelu?	Zapewnia utrzymanie po wdrożeniu

Jeżeli zespół nie potrafi uzgodnić poprawnej odpowiedzi, model nie rozwiąże sporu. Najpierw trzeba uporządkować regułę biznesową albo dopuścić świadomą decyzję człowieka.

Dobierz prosty zakres pilotażu

Wybierz jeden typ dokumentu, jedną kategorię zgłoszeń lub jeden etap aplikacji. Nie mieszaj na początku kilku języków, wielu spółek i odmiennych formularzy. Ograniczony zakres pozwala ustalić, czy błąd wynika z danych, konfiguracji modelu czy dalszej części przepływu.

Przygotuj próbkę podobną do danych produkcyjnych. Powinna zawierać zwykłe przypadki, słabe skany, brakujące pola i wartości graniczne. Dane użyte do oceny oddziel od materiału służącego do przygotowania modelu. W przeciwnym razie wynik testu może opisywać zapamiętane przykłady zamiast nowych dokumentów.

Nie wysyłaj do pilota informacji, których zespół nie ma prawa przetwarzać w wybranym środowisku. Ustal klasyfikację danych, role oraz okres przechowywania wyników. Łatwość zbudowania przepływu nie zmienia odpowiedzialności firmy za dane.

Zaprojektuj obsługę wyniku i wyjątku

Wynik modelu powinien prowadzić do jednej z jasno opisanych ścieżek. Odpowiedź o wysokiej pewności może przejść dalej, przypadek niepewny może trafić do weryfikacji, a błąd techniczny powinien zostać zapisany i zgłoszony. Wartości progowe ustala się na podstawie testów i kosztu pomyłki, a nie wygodnej okrągłej liczby.

Wynik próby	Dalsze działanie	Kontrola
Poprawny i zgodny z regułą	Kontynuacja procesu	Zapis wyniku i wersji rozwiązania
Niepewny	Kolejka do sprawdzenia	Uzasadnienie i decyzja pracownika
Błędny biznesowo	Zatrzymanie automatyzacji	Analiza przyczyny i próbki
Błąd techniczny	Ponowienie lub obsługa ręczna	Alert bez duplikowania operacji

Jeżeli przepływ zapisuje dane lub wysyła wiadomość, zaprojektuj ochronę przed powtórzeniem działania. Ponowne uruchomienie po awarii nie powinno tworzyć drugiego rekordu ani wysyłać klientowi tej samej informacji kilka razy.

Odbierz jakość na liczbach

Zapisz liczbę wszystkich przypadków, poprawnych wyników, spraw przekazanych człowiekowi i błędnych automatycznych decyzji. Sama średnia trafność może ukryć problem ważnej kategorii. Osobno oceń dokumenty o słabej jakości i przypadki o największym skutku finansowym.

Przykład syntetyczny: w próbie 100 dokumentów model poprawnie obsłużył 78, skierował 17 do człowieka i błędnie zaakceptował 5. Automatyzacja wynosi 78%, ale łączny udział poprawnie zakończonych lub bezpiecznie przekazanych spraw to 95%. Ocena zależy od tego, czy pięć błędów jest dopuszczalne. To ilustracja sposobu liczenia, nie wynik wdrożenia autora.

Zmierz czas całego procesu: przygotowanie danych, działanie modelu, poprawki i obsługę wyjątków. Jeżeli automatyczny odczyt oszczędza minutę, ale weryfikacja niepewnych przypadków zajmuje dwie dodatkowe minuty, efekt zależy od ich udziału.

Przykład odbioru odczytu faktury

Załóżmy, że AI Builder ma odczytywać numer faktury, dostawcę, datę i kwotę. W modelowym teście użyj dokumentów o różnym układzie, korekt, skanów słabej jakości i faktury bez numeru. Nie oceniaj samego faktu, że model zwrócił cztery pola. Sprawdź każde pole względem oryginału i zdecyduj, przy jakiej niepewności dokument ma trafić do człowieka.

Wynik	Działanie procesu
Wszystkie pola poprawne, dostawca zgodny z kartoteką	Przygotować rekord do zatwierdzenia
Kwota lub data niepewna	Pokazać oryginał i poprosić o korektę
Brak numeru albo konflikt dostawcy	Wstrzymać zapis i skierować do wyjaśnienia

To przykładowa procedura, nie zmierzona skuteczność produktu. Microsoft opisuje trenowanie i publikowanie modelu przetwarzania dokumentów, a zasady licencjonowania AI Builder rozróżniają budowanie/testowanie od zużycia kredytów przy uruchomieniu. W kosztorysie uwzględnij aktualne zasady AI Builder i Copilot Credits, wolumen stron oraz czas ręcznej korekty.

Utrzymanie jest częścią rozwiązania

Wyznacz osobę obserwującą jakość i zmiany procesu. Nowy wzór dokumentu, inny język albo zmiana kategorii może pogorszyć wynik bez awarii technicznej. Monitoring powinien obejmować jakość danych wejściowych, udział wyjątków i błędy dalszego przepływu.

Zachowaj wersję aplikacji, przepływu i modelu używaną dla każdego wyniku. Gdy jakość spadnie, zespół powinien móc ustalić, czy przyczyną była zmiana danych, reguły procesu czy konfiguracji. Nie poprawiaj rozwiązania bez powtórzenia tego samego zestawu prób, ponieważ usunięcie jednego błędu może pogorszyć inną kategorię.

Przygotuj też procedurę ręczną na czas niedostępności usługi. Powinna wskazywać kolejkę spraw, osobę podejmującą decyzję i sposób późniejszego uzupełnienia danych. Po wznowieniu automatyzacji trzeba rozpoznać sprawy już wykonane ręcznie, aby nie uruchomić ich ponownie.

Raz w miesiącu przejrzyj próbkę zaakceptowanych wyników, a nie tylko zgłoszone pomyłki.

Przed publikacją potwierdź status użytych funkcji, dostępność w regionie oraz potrzebną pojemność i licencje. Nie utrwalaj w dokumentacji projektu samej nazwy produktu. Zapisz konkretny model, środowisko, właściciela i datę sprawdzenia warunków.

Pierwszy krok to wybranie jednej decyzji, przygotowanie zestawu testowego i zapisanie sposobu obsługi pomyłki. Dzięki temu AI Builder staje się elementem systemu pracy z AI, a nie samotną demonstracją. Jeśli rozwiązanie ma objąć szerszą automatyzację, przeczytaj również o Centrum Doskonałości dla Power Platform.