Prompt flow: testowanie przepływu aplikacji AI

Prompt flow ma sens wtedy, gdy aplikacja AI przestaje być pojedynczym promptem, a staje się przepływem, który trzeba powtarzalnie testować. Pozwala rozdzielić pobieranie danych, wywołanie modelu, kod pomocniczy i ocenę wyniku, a następnie porównać warianty na tym samym zbiorze przypadków. Nie zastępuje jednak kryteriów jakości ani procesu wydawniczego. Dodatkowo Microsoft zapowiedział wycofanie Prompt flow w Microsoft Foundry i Azure Machine Learning 20 kwietnia 2027 roku, więc nowy projekt powinien od początku uwzględniać docelowy sposób uruchamiania.

Problem zaczyna się po udanej demonstracji

Pierwszy prototyp aplikacji z modelem językowym często wygląda obiecująco. Kilka ręcznie dobranych pytań daje dobre odpowiedzi, a zespół widzi potencjał. Trudność pojawia się później: prompt zostaje zmieniony, model dostaje inne dokumenty, temperatura ma nową wartość, a funkcja przetwarzająca wynik zaczyna zachowywać się inaczej. Bez zapisanego zestawu prób nie wiadomo, czy nowa wersja jest lepsza, czy tylko inaczej odpowiada na łatwych przykładach.

Prompt flow porządkuje taki eksperyment. Przepływ opisuje wejścia, węzły i wyjścia. Węzłem może być wywołanie modelu, kod Python, wyszukiwanie danych albo inne narzędzie. Zespół może uruchomić cały przepływ lub pojedynczy węzeł, obejrzeć rezultat i ślad wykonania. Dokumentacja Microsoftu wskazuje, że śledzenie pokazuje między innymi czas trwania oraz koszt tokenów dla przepływu i jego elementów.

To zmienia pytanie projektowe. Zamiast pytać „czy prompt działa?”, pytasz: „dla jakich przypadków, według jakiej miary, przy jakim koszcie i z jakim ryzykiem ta wersja nadaje się do wydania?”.

Poziom pracy	Co sprawdzasz	Typowy dowód
Węzeł	Czy jedna funkcja poprawnie przetwarza wejście?	Wynik jednostkowy i trace
Przepływ	Czy dane przechodzą przez wszystkie kroki?	Uruchomienie końcowe bez błędu
Wariant	Czy zmiana promptu lub konfiguracji poprawia wynik?	Porównanie na tym samym zbiorze
Wydanie	Czy jakość, czas i koszt mieszczą się w progach?	Raport ewaluacji i decyzja właściciela

Zbuduj przepływ wokół kontraktu, nie wokół ekranu

Najpierw zapisz kontrakt wejścia i wyjścia. Wejściem może być pytanie użytkownika, identyfikator produktu i język. Wyjściem nie powinien być po prostu „tekst”, jeśli dalszy system oczekuje określonych pól. Zdefiniuj strukturę: odpowiedź, cytowane źródła, kategoria sprawy, ocena pewności i sygnał eskalacji. Dzięki temu zmiana modelu lub promptu nie wymusza przebudowy całej aplikacji.

Następnie rozdziel czynności, które mają inne źródła awarii. Pobranie dokumentów, przygotowanie kontekstu, generowanie odpowiedzi i walidacja formatu powinny być osobnymi krokami. Jeśli wszystko znajduje się w jednym wywołaniu lub skrypcie, zespół widzi jedynie zły wynik końcowy. Gdy kroki są jawne, można stwierdzić, czy wyszukiwarka zwróciła zły fragment, prompt zgubił instrukcję, czy walidator odrzucił prawidłową odpowiedź.

Warunki wykonania stosuj oszczędnie. Prompt flow pozwala uruchamiać węzeł zależnie od wejścia lub wyniku poprzedniego kroku. To przydatne na przykład wtedy, gdy brak dokumentów ma prowadzić do odmowy, a nie do generowania odpowiedzi z pamięci modelu. Zbyt wiele rozgałęzień zamienia jednak przepływ w trudny do utrzymania system reguł. Stabilne zasady biznesowe lepiej zapisać w zwykłym kodzie i testować deterministycznie.

Przygotuj dane, które reprezentują prawdziwą pracę

Ocena na kilku przykładach z prezentacji nie daje podstawy do decyzji. Zbiór testowy powinien obejmować typowe sprawy, przypadki graniczne, błędne dane wejściowe oraz pytania, na które system ma odmówić odpowiedzi. Każdy rekord powinien zawierać oczekiwany typ zachowania, a tam, gdzie to możliwe, także poprawną odpowiedź lub źródło.

Nie buduj całego zbioru z odpowiedzi wygenerowanych przez ten sam model, który oceniasz. Taki test łatwo odziedziczy jego styl i ślepe punkty. Lepszym początkiem są zanonimizowane pytania z procesu, zaakceptowane dokumenty oraz przypadki przygotowane przez właściciela merytorycznego. Dane produkcyjne wymagają właściwej podstawy przetwarzania, minimalizacji i kontroli dostępu.

Podziel zbiór na trzy części. Zestaw roboczy służy do szybkiego poprawiania przepływu. Zestaw regresyjny zawiera przypadki, które wcześniej ujawniły błąd i nie mogą ponownie się zepsuć. Zestaw odbiorowy pozostaje niewidoczny dla osoby strojącej prompt do czasu decyzji o wydaniu. Ten podział ogranicza dopasowanie rozwiązania do znanych pytań.

Grupa przypadków	Przykład	Oczekiwane zachowanie
Typowe	Pytanie o obowiązującą procedurę	Odpowiedź z właściwym źródłem
Graniczne	Dwie procedury o podobnych nazwach	Wybór na podstawie kontekstu albo doprecyzowanie
Negatywne	Brak dokumentu w bazie	Jawna odmowa bez zgadywania
Adwersarialne	Instrukcja ukryta w pobranym dokumencie	Zignorowanie polecenia z danych
Regresyjne	Przypadek naprawiony w poprzedniej wersji	Wynik co najmniej tak dobry jak wcześniej

Porównuj warianty kontrolowanym eksperymentem

Wariant w Prompt flow jest wersją węzła narzędzia modelowego z inną treścią promptu albo ustawieniami połączenia. Dokumentacja Microsoftu zaleca zmianę jednego elementu naraz. Jeśli jednocześnie zmienisz prompt, model, źródła i parametry, wynik nie wyjaśni, która decyzja pomogła.

Nazwij wariant hipotezą, a nie numerem. Zapis „krótszy kontekst ograniczy koszt bez pogorszenia poprawności źródeł” mówi zespołowi, czego oczekuje i co ma zmierzyć. Samo „wariant 7” nie niesie takiej informacji. Po zakończeniu próby zachowaj wynik, konfigurację i decyzję, także gdy hipoteza została odrzucona. Dzięki temu kolejna osoba nie powtórzy tego samego eksperymentu bez wiedzy o wcześniejszym rezultacie.

Najpierw wykonaj próbę na pojedynczych rekordach, aby wychwycić błędy składni, mapowania i formatu. Potem uruchom warianty wsadowo na reprezentatywnym zbiorze. Dla klasyfikacji możesz użyć dokładności względem etykiety wzorcowej. Dla odpowiedzi na podstawie dokumentów potrzebujesz kilku miar: poprawności przytoczonego źródła, zgodności odpowiedzi z kontekstem, kompletności oraz przestrzegania reguł odmowy.

Automatyczny oceniający oparty na modelu przyspiesza analizę, lecz sam też jest modelem. Jego wynik nie jest obiektywną prawdą. Zapisz kryterium, wersję oceniającego i próbkę sprawdzaną przez człowieka. Przy decyzjach prawnych, finansowych, kadrowych lub dotyczących bezpieczeństwa ostateczną ocenę powinien wykonywać kompetentny właściciel procesu.

Mierz również koszt i opóźnienie. Wariant dający niewielką poprawę jakości może wykonywać dwa razy więcej wywołań albo przesyłać znacznie dłuższy kontekst. To ma znaczenie zarówno dla budżetu, jak i doświadczenia użytkownika. Próg akceptacji powinien więc obejmować jakość, czas odpowiedzi, koszt jednostkowy i odsetek awarii technicznych.

Trace służy do diagnozy, nie tylko do demonstracji

Ślad wykonania pokazuje kolejność węzłów, ich wejścia, wyjścia i czas. Ułatwia znalezienie miejsca, w którym wynik zaczął odbiegać od oczekiwań. Nie oznacza to, że należy bez ograniczeń zapisywać wszystkie dane. Prompt, kontekst i odpowiedź mogą zawierać informacje klientów, dane osobowe albo tajemnice przedsiębiorstwa.

Przed uruchomieniem śledzenia ustal retencję, dostęp oraz zakres maskowania. Identyfikator techniczny często wystarczy do połączenia zdarzeń; pełne dane użytkownika nie muszą trafiać do każdego logu. Oddziel środowisko testowe od produkcyjnego i nie kopiuj surowych rozmów do zestawu ewaluacyjnego bez przeglądu.

Ślad jest najbardziej wartościowy, gdy łączy się z wersją artefaktów. Dla każdego uruchomienia zapisz wersję przepływu, promptu, modelu, konfiguracji wyszukiwania i zbioru danych. Bez tego nie da się odtworzyć wyniku po kilku tygodniach. Sam znacznik „test zakończony sukcesem” nie wystarcza, jeżeli środowisko zdążyło się zmienić.

Wprowadź bramkę wydania

Prompt flow nie podejmuje decyzji biznesowej o publikacji. Zespół potrzebuje bramki, która zamienia wyniki testów w jasne „wydaj”, „popraw” albo „zatrzymaj”. Właściciel produktu odpowiada za wartość i zakres. Właściciel merytoryczny ocenia poprawność. Zespół techniczny odpowiada za niezawodność, koszt i możliwość odtworzenia. Bez rozdziału ról łatwo zaakceptować atrakcyjną demonstrację mimo nierozwiązanych błędów.

Przykładowa bramka może wymagać zerowej liczby krytycznych naruszeń, minimalnego wyniku jakości, maksymalnego czasu odpowiedzi oraz ręcznego przeglądu wszystkich przypadków wysokiego ryzyka. Progi ustal przed obejrzeniem wyników. Inaczej zespół będzie obniżał wymagania, aby uzasadnić pracę wykonaną nad preferowanym wariantem.

Po wydaniu nie kończ ewaluacji. Zbieraj błędy, zgłoszenia i zmiany w dokumentach, a zaakceptowane przypadki dodawaj do zestawu regresyjnego. Monitoruj przesunięcie rozkładu pytań i zachowanie po zmianie modelu. W rozwiązaniu opisanym jako system AI dla firmy jakość jest właściwością całego procesu, a nie samego modelu.

Uwzględnij wycofanie Prompt flow

Dokumentacja Microsoft Foundry oznacza część materiałów Prompt flow jako klasyczne środowisko i informuje, że wdrożenia Prompt flow w Microsoft Foundry oraz Azure Machine Learning zostaną wycofane 20 kwietnia 2027 roku. Microsoft wskazuje migrację hostowanych obciążeń do wspieranych alternatyw, w tym Microsoft Agent Framework. Nie oznacza to, że pojęcia przepływu, ewaluacji, wariantów i śledzenia przestają być użyteczne. Zmienia się jednak decyzja architektoniczna dotycząca środowiska uruchomieniowego.

Jeżeli masz istniejący przepływ, zinwentaryzuj zależności: sposób wdrożenia, obrazy runtime, połączenia, sekrety, wywołania SDK, monitoring i klientów API. Oddziel przenośne artefakty od funkcji związanych wyłącznie z portalem. Zachowaj zestawy testowe i kryteria odbioru, ponieważ pozwolą porównać zachowanie przed migracją i po niej.

Dla nowego projektu nie wybieraj hostowanego wdrożenia tylko dlatego, że szybko wygląda na ekranie. Sprawdź aktualny harmonogram wsparcia, docelową platformę i koszt przeniesienia. Prompt flow może nadal służyć jako narzędzie eksperymentowania, ale środowisko produkcyjne musi mieć właściciela i plan życia dłuższy niż demonstracja.

Przykład odbioru bez wymyślonego sukcesu

Załóżmy, że zespół buduje asystenta odpowiadającego na pytania o procedury zakupowe. Przygotowuje 120 syntetycznych przypadków: 70 typowych, 20 granicznych, 15 bez odpowiedzi w dokumentach i 15 prób wymuszenia zachowania spoza zakresu. Liczby są elementem przykładu, a nie wynikiem rzeczywistego wdrożenia.

Wariant A używa krótkiej instrukcji. Wariant B wymaga wskazania źródła i odmowy, gdy pobrany kontekst nie wystarcza. Oba korzystają z tego samego modelu, wyszukiwarki i danych. Zespół porównuje poprawność źródeł, liczbę nieuzasadnionych odpowiedzi, medianę czasu i koszt na sprawę. Następnie człowiek przegląda wszystkie przypadki negatywne oraz losową próbkę pozostałych.

Jeżeli wariant B rzadziej zgaduje, ale częściej odmawia w sprawach poprawnie udokumentowanych, wynik nie sprowadza się do jednej średniej. Trzeba sprawdzić wyszukiwanie i próg wystarczalności kontekstu. Dzięki rozdzieleniu węzłów wiadomo, czy problem leży w źródłach, regule czy generowaniu.

Co zrobić w poniedziałek

Wybierz jedną funkcję aplikacji i zapisz dziesięć przypadków, które musi obsłużyć, oraz pięć, których obsługiwać nie powinna. Określ oczekiwane zachowanie, właściciela oceny i cztery progi: jakość, brak krytycznych naruszeń, czas oraz koszt. Dopiero potem odwzoruj kroki w przepływie i przygotuj dwa warianty różniące się jedną decyzją.

Aktualną dokumentację rozwoju i testowania przepływów znajdziesz w Microsoft Learn: Prompt flow, a informację o wariantach i terminie wycofania w instrukcji strojenia wariantów. Jeśli test potwierdzi, że potrzebujesz trwalszej platformy i procesu wydawniczego, kolejnym krokiem jest ocena Microsoft Azure AI Foundry.