Prompt Flow: The Complete Guide

Cześć, tu Alex z DEV STORIES DOT EU. Prompt Flow: Kompletny przewodnik, odcinek 1 z 14. Większość bibliotek AI próbuje abstrahować złożoność, ukrywając twoje prompty głęboko w funkcjach typu wrapper. Ale kiedy wchodzisz na produkcję, to właśnie te prompty są tym, co musisz kontrolować. To jest główna filozofia Prompt Flow. Najpierw wyjaśnijmy pewne powszechne nieporozumienie. Prompt Flow to nie framework taki jak LangChain. LangChain to framework programistyczny, który dostarcza gotowe chainy i agenty, które często enkapsulują ukryte pod spodem prompty. Prompt Flow to zestaw narzędzi zaprojektowanych do eksperymentowania i ewaluacji. Powstał, ponieważ tradycyjna zasada enkapsulacji w inżynierii oprogramowania staje się wręcz obciążeniem, gdy budujesz aplikacje oparte na dużych modelach językowych. W standardowym programowaniu ukrywasz złożoną logikę za czystym interfejsem funkcji. Nie musisz wiedzieć, jak funkcja działa pod spodem, interesuje cię tylko to, co zwraca. Ale prompty są bardzo zmienne. Nie są statyczną logiką. Jeśli zmienisz wersję modelu na inną, prompt, który wczoraj działał idealnie, dzisiaj może zawieść. Jeśli używasz nieprzejrzystej zewnętrznej biblioteki do podsumowywania dokumentów, a bazowy prompt jest zablokowany wewnątrz tej biblioteki, nie możesz naprawić słabego podsumowania. Jesteś całkowicie zależny od maintainerów biblioteki. Prompt Flow odwraca ten wzorzec projektowy, wystawiając prompty na zewnątrz. Traktuje je jako pełnoprawne zasoby programistyczne. Musisz je stale przeglądać, tunować i wersjonować. Zamiast czarnej skrzynki dostajesz przejrzysty toolchain, w którym kontrolujesz dokładny tekst i zmienne trafiające do modelu językowego. I to jest ta najważniejsza część. Ponieważ prompty są zmienne, budowanie aplikacji AI wymaga fundamentalnie nowego sposobu pracy. W standardowym oprogramowaniu piszesz unit testy. Robisz asercję, że konkretny input daje konkretny output. Modele językowe są probabilistyczne, co oznacza, że nie dają deterministycznych odpowiedzi. Nie możesz napisać prostej asercji, żeby sprawdzić, czy wygenerowany mail jest uprzejmy, albo czy podsumowanie jest trafne. Zamiast tego musisz przyjąć workflow oparty na ewaluacji. Musisz przepuścić swój prompt przez setki różnych przykładów i zmierzyć metryki takie jak trafność czy dokładność formatowania. Prompt Flow jest zbudowany bezpośrednio wokół tego workflow. Integruje tunowanie promptów z masową ewaluacją. Kiedy zmienisz pojedyncze słowo w swoim prompcie, narzędzia pomogą ci statystycznie ocenić, czy ta zmiana poprawiła twój success rate na całym datassecie, czy go pogorszyła. Ostatnim filarem tej filozofii jest optymalizacja pod kątem widoczności. Aplikacje AI to rzadko tylko jedno wywołanie API. To złożone grafy wykonania. Możesz wziąć pytanie użytkownika, odpytać wektorową bazę danych, sformatować pobrane dane, wstrzyknąć je do promptu, a następnie wywołać model. Kiedy ostateczna odpowiedź jest błędna, musisz dokładnie wiedzieć, gdzie ten chain się przerwał. Prompt Flow sprawia, że ten graf wykonania staje się widoczny. Możesz zbadać każdy node, żeby zobaczyć dokładne inputy i outputy na tym konkretnym etapie procesu, co sprawia, że debugowanie jest proste. Najważniejszy wniosek jest taki, że prompty to żywe, niestabilne zmienne, które wymagają ciągłej obserwacji, a nie statyczny kod, który możesz napisać raz i gdzieś ukryć. Jeśli uważasz te odcinki za pomocne i chcesz wesprzeć nasz podcast, możesz wyszukać DevStoriesEU na Patreonie. To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Prompt Flow: Kompletny przewodnik, odcinek 2 z 14. Zanim napiszesz choć jedną linijkę kodu, musisz przestać myśleć o aplikacjach LLM jak o monolitycznych skryptach. Jeśli spróbujesz pisać je liniowo, śledzenie zależności i debugowanie stanu pomiędzy wieloma zewnętrznymi serwisami szybko stanie się niemożliwe do opanowania. Strukturalnym rozwiązaniem tego problemu jest postrzeganie aplikacji jako grafu niezależnych wywołań funkcji – koncepcji znanej w Prompt Flow jako Flows i architektura DAG. Flow to po prostu wykonywalny workflow. W swojej istocie aplikacja LLM to zorkiestrowana sekwencja zewnętrznych wywołań, sklejonych ze sobą logiką. Możesz odpytać wyszukiwarkę, wykonać zapytanie do bazy danych, uruchomić skrypt w Pythonie, żeby sformatować pobrane dane, a na koniec wysłać prompt do LLM-a. Prompt Flow modeluje tę sekwencję jako skierowany graf acykliczny, czyli DAG. W tym grafie każdy pojedynczy krok twojej aplikacji to node, a połączenia między tymi nodami reprezentują flow danych. Jest on skierowany, ponieważ dane idą do przodu, od jednej funkcji do drugiej, i jest acykliczny, ponieważ ścieżka danych się nie zapętla. Weźmy pod uwagę prostą aplikację, która odpowiada na pytania na podstawie wewnętrznych danych firmy. Użytkownik zadaje pytanie, które stanowi twój początkowy input. Ten input trafia do pierwszego noda, czyli funkcji w Pythonie, która wykonuje zapytanie do bazy danych. Baza danych zwraca blok tekstu. Ten tekst, razem z oryginalnym pytaniem użytkownika, trafia do kolejnego noda, który wykonuje właściwe wywołanie do LLM-a. LLM generuje odpowiedź, która staje się końcowym outputem całego grafu. Dzięki takiej strukturze aplikacji, każda funkcja jest ściśle odizolowana. Wiesz dokładnie, co weszło do wywołania bazy danych i co z niego wyszło, zanim LLM w ogóle został uruchomiony. Budując te workflowy, deweloperzy często spotykają się z dwoma terminami i zastanawiają się, który z nich jest lepszy: Flex flow czy DAG flow. Tu zaczyna się robić ciekawie. Oba osiągają dokładnie ten sam rezultat. Oferują po prostu inny developer experience. Flex flow to podejście code-first. Zamykasz swoją logikę w standardowej funkcji lub klasie w Pythonie, oznaczasz ją jako entry point i piszesz czysty kod. Prompt Flow po prostu to uruchamia. Z kolei DAG flow definiuje routing za pomocą pliku YAML. Jawnie wymieniając funkcje jako nody i łącząc ich inputy i outputy w YAML-u, pozwalasz platformie wyrenderować wizualną reprezentację twojej aplikacji. DAG flows są bardzo UI-friendly, co ułatwia szybką inspekcję architektury na pierwszy rzut oka. Jeśli wybierzesz podejście DAG flow, będziesz pracować z trzema konkretnymi typami flow. Pierwszy to Standard flow. To twój pipeline ogólnego przeznaczenia, w którym łączysz narzędzia, kod w Pythonie i modele, żeby budować typowe aplikacje. Drugi to Chat flow. Bazuje on bezpośrednio na Standard flow, ale jest specjalnie skrojony pod aplikacje konwersacyjne. Dodaje natywne wsparcie dla zarządzania historią czatu i automatycznie konfiguruje niezbędne inputy i outputy czatu. Trzeci typ to Evaluation flow. Nie używasz tego flow do obsługi użytkowników końcowych. Zamiast tego, uruchamiasz Evaluation flow na outputach twoich Standard lub Chat flows. Działa on jako mechanizm testowy do obliczania metryk, takich jak dokładność faktograficzna czy trafność, na podstawie danych wygenerowanych przez twój główny flow. Niezależnie od tego, czy zdefiniujesz swoją logikę w czystym Pythonie, czy połączysz ją wizualnie za pomocą YAML-a, twoja aplikacja LLM to ostatecznie tylko pipeline routujący tekst między zewnętrznymi systemami. Opanuj graf, a będziesz kontrolować aplikację. To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Prompt Flow: Kompletny przewodnik, odcinek 3 z 14. Zaprojektowałeś idealny workflow dla swojej aplikacji AI, ale sam projekt nie przetwarza danych. Potrzebujesz komponentów, które faktycznie wykonują pracę, takich jak pobieranie URL-i, formatowanie stringów i wywoływanie API. Jeśli flowy to projekt twojej aplikacji, toolsy są jej cegłami. Dzisiaj przyjrzymy się toolsom. W Prompt Flow toolsy to podstawowe, wykonywalne elementy składowe każdego flow. Każdy node w twoim grafie to tool. Kiedy twój flow działa, po prostu przekazuje dane z jednego toola do drugiego. Chociaż platformę można rozszerzać, są trzy wbudowane toolsy, których będziesz używać w niemal każdym projekcie: Python tool, Prompt tool i LLM tool. Przejdźmy przez praktyczny scenariusz, żeby zobaczyć, jak to wszystko do siebie pasuje. Chcesz stworzyć aplikację, która pobiera stronę internetową, formatuje surowy tekst i generuje podsumowanie. Najpierw musisz pobrać zawartość strony. Używasz do tego Python toola. Ten tool pozwala ci pisać własne skrypty w Pythonie i działa jako twój pomost do świata zewnętrznego. Piszesz krótki skrypt, który przyjmuje URL jako input, robi request HTTP i zwraca surowy tekst strony. Python tool obsługuje wykonanie i przekazuje ten surowy tekst dalej jako output. Następnie musisz przygotować instrukcje dla modelu językowego. Używasz Prompt toola. Ten tool przyjmuje tekstowe inputy, takie jak surowy tekst z twojego Python toola oraz system prompt definiujący personę AI, i formatuje je w jeden, czysty string. To jest kluczowa część. Prompt tool nie wywołuje modelu AI. On wyłącznie przygotowuje i formatuje tekst. Wydzielenie tego kroku sprawia, że twój flow jest znacznie łatwiejszy do czytania i testowania, zwłaszcza gdy masz do czynienia ze złożonymi, wieloczęściowymi promptami. Na koniec wysyłasz ten przygotowany string do modelu, używając LLM toola. Ten tool obsługuje właściwe połączenie z endpointem Large Language Model. Przekazujesz mu sformatowany string z twojego Prompt toola, konfigurujesz parametry modelu, takie jak temperature, a on zwraca wygenerowane podsumowanie. LLM tool odwala czarną robotę związaną z formatowaniem payloadu API i interakcją z providerem. Chociaż te trzy pokrywają większość podstawowych use case'ów, to nie są twoje jedyne opcje. Prompt Flow wspiera partnerskie toolsy dostarczane przez firmy zewnętrzne. Częstym przykładem jest Vector DB Lookup tool, który przeszukuje wektorowe bazy danych w poszukiwaniu podobnego tekstu na podstawie embeddingów. Możesz też instalować customowe paczki albo budować własne toolsy do bardzo specyficznych integracji. Niezależnie od ich pochodzenia, wszystkie działają na dokładnie tej samej zasadzie: przyjmują inputy, wykonują określoną funkcję i zwracają output. Najważniejsza rzecz, o której musisz pamiętać, to ścisłe trzymanie się separation of concerns. Nie pisz kodu w Pythonie do formatowania promptów i nie używaj LLM toola do konkatenacji stringów. Używanie odpowiedniego wbudowanego toola do jego konkretnego celu sprawia, że twoje grafy są czyste i łatwe do debugowania. Dzięki, że wpadłeś. Mam nadzieję, że dowiedziałeś się czegoś nowego.

Cześć, tu Alex z DEV STORIES DOT EU. Prompt Flow: Kompletny przewodnik, odcinek 4 z 14. Nic nie rujnuje produkcyjnego deployu szybciej niż klucz API przypadkowo zacommitowany do kontroli wersji. Nawet jeśli unikniesz tej katastrofy, żonglowanie credentialsami między lokalnym środowiskiem deweloperskim a chmurą często prowadzi do zagmatwanych plików konfiguracyjnych i luk w zabezpieczeniach. Zarządzanie secretami za pomocą connections rozwiązuje ten problem, całkowicie izolując wrażliwe dane od logiki twojego flow. Connection w Prompt Flow to dedykowany zasób, który przechowuje endpointy i credentials wymagane do interakcji z zewnętrznymi usługami. Jeśli twój flow musi wywołać zewnętrzny model językowy, przeszukać sieć za pomocą zewnętrznej usługi lub odpytać zdalną bazę danych, potrzebuje autoryzacji. Zamiast wpisywać klucze API bezpośrednio do skryptów w Pythonie lub plików konfiguracyjnych, tworzysz connection. Twój flow odwołuje się potem do tego connection po jego nazwie. Używając connections, oddzielasz swoje secrety od logiki wykonania. Twój kod wie tylko, że wymaga connection o nazwie, na przykład, main_language_model. Nie zna samego klucza API. Przyjrzyjmy się, jak to działa podczas przenoszenia projektu z twojego laptopa do chmury. Kiedy dewelopujesz lokalnie, twoje connections są przechowywane na lokalnym dysku. Aby zachować bezpieczeństwo, Prompt Flow szyfruje secrety za pomocą lokalnego klucza szyfrującego. Możesz budować i testować swój flow przy użyciu tego lokalnego setupu, bez zostawiania kluczy jako plaintext w twoim katalogu roboczym. Kiedy będziesz gotowy, aby zdeployować ten flow do Azure AI, środowisko się zmienia, ale twój kod nie. W Azure AI, connections są bezpiecznie trzymane w Azure Key Vault. Secrety są przechowywane i zarządzane w infrastrukturze Key Vault, chronione przez restrykcyjne polityki dostępu. To jest najważniejsza część. Ponieważ twój flow odwołuje się do connection tylko po jego nazwie, przejście ze środowiska lokalnego do chmury wymaga zero zmian w logice twojego flow. Po prostu upewniasz się, że connection o identycznej nazwie istnieje w twoim workspace'ie na Azure. Kiedy flow uruchamia się w chmurze, prosi o main_language_model. System płynnie przechwytuje to żądanie i dostarcza credentials z Key Vaulta zamiast tych lokalnych, zaszyfrowanych. Twój kod pozostaje czysty i environment-agnostic. Prompt Flow dzieli te connections na dwa główne typy. Pierwszy to silnie typowane connections. Są to wbudowane szablony dla powszechnie używanych usług, takich jak Azure OpenAI. Zapewniają one predefiniowane pola dla URL endpointu, klucza API i typu API. System dokładnie wie, jak obsłużyć te pola, co sprawia, że standardowa konfiguracja tooli jest prosta. Drugi typ to custom connection. Kiedy musisz zintegrować wewnętrzne API firmy lub usługę third-party, która nie ma wbudowanego szablonu, używasz custom connection. Działa to jak elastyczny słownik, w którym definiujesz własne pary klucz-wartość. Możesz jawnie oznaczyć konkretne klucze jako secrety. Po oznaczeniu, te customowe secrety otrzymują dokładnie takie samo lokalne szyfrowanie i ochronę Key Vault, jak wbudowane connections. Największą wartością connections jest to, że działają jak ścisła warstwa abstrakcji dla uwierzytelniania, zapewniając, że twój flow pozostaje całkowicie przenośny, a twoje secrety bezpieczne w każdym środowisku uruchomieniowym. To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Prompt Flow: Kompletny przewodnik, odcinek 5 z 14. Przestań chować prompty swojego modelu językowego w ogromnych pythonowych stringach. Kiedy hardkodujesz prompty w logice aplikacji, śledzenie zmian, uruchamianie testów standalone i współpraca z prompt engineerami stają się absolutnym koszmarem. Rozwiązaniem jest specyfikacja Prompty. Prompty to standardowy format zarządzania promptami. Przenosi twój prompt z kodu do pojedynczego, wersjonowanego pliku markdown z rozszerzeniem .prompty. Plik jest podzielony na dwie odrębne sekcje. Na samej górze masz YAML front matter. Na dole masz prompt template w formacie Jinja. Trzy myślniki oddzielają je od siebie. Blok YAML pełni funkcję centrum sterowania. Możesz zdefiniować podstawowe metadane, takie jak nazwa, opis i autor. Co ważniejsze, zawiera on konfigurację modelu. Określasz typ API, na przykład chat lub completion. Definiujesz szczegóły konfiguracji, na przykład wskazując na deployment GPT-3.5 w Azure OpenAI. Właśnie tutaj ustalasz też parametry modelu. Jeśli konkretny prompt wymaga parametru temperature na poziomie 0.7 i limitu max tokens równego tysiąc, deklarujesz to w YAML-u. To wiąże ustawienia uruchomieniowe bezpośrednio z tekstem prompta, dając pewność, że prompt zachowa się spójnie, niezależnie od tego, gdzie zostanie użyty. Sekcja YAML definiuje również inputs i przykładowe dane. Jeśli twój prompt oczekuje dynamicznej zmiennej, wymieniasz ją tutaj i podajesz przykładowe wartości. Dzięki temu plik staje się całkowicie samowystarczalny. Każdy, kto go otworzy, dokładnie wie, jakich danych oczekuje, bez konieczności robienia reverse engineeringu kodu twojej aplikacji. Pod sekcją YAML i trzema myślnikami znajduje się właściwy prompt template. Ta sekcja wykorzystuje składnię Jinja2 do dynamicznego wstrzykiwania zdefiniowanych wyżej inputs. Ponieważ współczesne modele językowe korzystają z interfejsów chatowych, template obsługuje przypisywanie ról. Definiujesz role za pomocą prostego formatu tekstowego, oddzielając instrukcje systemowe od user inputs. Wyobraź sobie minimalistyczny scenariusz chatu, w którym chcesz, aby prompt witał użytkownika po imieniu. Na samej górze swojego pliku .prompty piszesz YAML front matter. Definiujesz sekcję modelu, ustawiając typ API na chat i kierując konfigurację na deployment GPT-3.5. Następnie dodajesz sekcję inputs deklarującą zmienną o nazwie first name. Dodajesz również blok sample, w którym first name jest ustawione na Jane. Wpisujesz trzy myślniki, aby zakończyć YAML front matter. Teraz budujesz template. Wpisujesz słowo system, po którym dajesz dwukropek, a potem przekazujesz modelowi podstawowe instrukcje, na przykład mówiąc mu, żeby był pomocnym asystentem. Poniżej wpisujesz słowo user, a po nim dwukropek. Na koniec piszesz powitanie, umieszczając zmienną first name w podwójnych nawiasach klamrowych, żeby silnik Jinja wiedział, gdzie wstrzyknąć tekst. Masz teraz kompletny zasób wielokrotnego użytku. Traktowanie promptów jako samowystarczalnych plików, a nie luźnych stringów w kodzie, to pierwszy krok w kierunku rygorystycznego prompt engineeringu, ponieważ wymusza to jasny kontrakt między aplikacją dostarczającą dane a modelem językowym generującym odpowiedź. Dzięki za spędzenie ze mną tych kilku minut. Do usłyszenia następnym razem, trzymaj się.

Cześć, tu Alex z DEV STORIES DOT EU. Prompt Flow: Kompletny przewodnik, odcinek 6 z 14. Tworzysz starannie dostrojony prompt template na produkcję, ale gdy chcesz go przetestować z tańszym modelem lub dostosować temperaturę dla konkretnego edge case'a, łapiesz się na tym, że ręcznie edytujesz plik źródłowy. Statyczny szablon bywa uciążliwy, gdy twoje środowisko lub logika muszą zmieniać się w locie. I właśnie ten problem ma wyeliminować Dynamic Prompty Execution. Asset Prompty zazwyczaj definiuje ustawienia modelu, takie jak deployment name, połączenie API i parametry, w swoim bloku nagłówka. Jednak hardcodowanie tych wartości ogranicza to, jak możesz używać tego pliku w różnych środowiskach. Dynamic execution pozwala ci traktować plik Prompty jako elastyczną warstwę bazową, nadpisując jego konfigurację bezpośrednio w Pythonie lub z command line'a podczas runtime'u. Aby uruchomić plik Prompty w Pythonie, używasz funkcji load prompty z core'owej biblioteki Prompt Flow. Przekazujesz do tej funkcji ścieżkę do pliku, a ona zwraca obiekt typu callable w pamięci. Aby go wykonać, po prostu wywołujesz ten obiekt, przekazując zmienne prompta jako standardowe keyword arguments. Biblioteka ogarnia kompilację i API call, zwracając ostateczny output tekstowy. To jest dokładnie ten moment, w którym dynamic execution udowadnia swoją wartość. Możesz przechwycić execution, aby nadpisać ustawienia modelu bez dotykania pliku źródłowego. Załóżmy, że masz plik Prompty skonfigurowany pod standardowy deployment Azure OpenAI, ale dla konkretnego batch joba musisz wskazać mu inny endpoint Azure i podbić temperaturę, aby uzyskać bardziej zróżnicowane odpowiedzi. Zamiast duplikować plik, definiujesz w kodzie Pythona słownik zawierający twoje nowe ustawienia. Dodajesz do tego słownika swój alternatywny endpoint i nową wartość temperatury. Następnie, gdy wywołujesz załadowany obiekt Prompty, przekazujesz ten słownik do keyword argumentu model, obok standardowych inputów prompta. Runtime Prompt Flow scala twój słownik z bazową konfiguracją pliku. Twoje dynamiczne override'y mają pierwszeństwo, prompt wykonuje się z nowymi ustawieniami, a oryginalny plik pozostaje całkowicie niezmieniony. Pozwala ci to na podmianę kluczy API, zmianę max tokens lub programowe przekierowanie model target w oparciu o stan twojej aplikacji. Czasami nie chcesz pisać skryptu w Pythonie tylko po to, by sprawdzić, czy prompt daje dobry wynik. W celu szybkiej walidacji, możesz przetestować plik Prompty bezpośrednio z terminala. Używasz komendy pf flow test, podając ścieżkę do pliku za pomocą flagi source. Możesz dorzucić flagę inputs, aby przekazać swoje zmienne prosto do komendy jako pary key-value. Command line interface wykonuje Prompty i wypisuje odpowiedź modelu bezpośrednio na standard output. Daje ci to natychmiastowy feedback loop podczas developmentu, bez pisania kodu wrappera. Prawdziwa wartość assetu Prompty nie polega na blokowaniu konfiguracji, ale na izolowaniu tekstu prompta od execution environment. Dzięki dynamicznemu wstrzykiwaniu override'ów modelu podczas runtime'u, pojedynczy plik może bezproblemowo obsłużyć twój lokalny testowy sandbox, zautomatyzowane pipeline'y i produkcyjne endpointy. To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Prompt Flow: Kompletny przewodnik, odcinek 7 z 14. Może ci się wydawać, że korzystanie ze specjalistycznego frameworka dla modeli LLM oznacza naukę skomplikowanego interfejsu wizualnego lub utrzymywanie ogromnych plików konfiguracyjnych. Ale jeśli wiesz już, jak napisać skrypt w Pythonie, wiesz wystarczająco dużo, aby zbudować w pełni monitorowaną aplikację. Flex Flows oparte na funkcjach całkowicie rozwiązują ten problem. Podczas standardowego developmentu w Prompt Flow tworzysz skierowany graf acykliczny. Ta struktura jest bardzo skuteczna w przypadku ścisłych, wieloetapowych pipeline'ów, ale czasami developerzy chcą pisać czysty kod w Pythonie bez dostosowywania się do wizualnego systemu node'ów. Flex flows pozwalają ci dokładnie na to. Zamykasz logikę swojej aplikacji LLM w standardowych funkcjach w Pythonie, a platforma zajmuje się trackingiem i orkiestracją w tle. Spójrzmy na podejście oparte na funkcjach. Zaczynasz od napisania zwykłej funkcji w Pythonie. Nadajesz jej opisową nazwę, na przykład chat, i definiujesz jej inputy, na przykład przyjmując pytanie jako parametr typu string. Wewnątrz tej funkcji piszesz swoją logikę dokładnie tak, jak robisz to zazwyczaj. Możesz załadować plik Prompty, aby pobrać swój system message, zainicjować klienta modelu językowego, przekazać pytanie do modelu, a następnie zwrócić odpowiedź tekstową jako string. Na tym etapie masz po prostu standardowy skrypt w Pythonie. Działa lokalnie, jest łatwy do testowania i nie wymaga znajomości żadnego specjalnego frameworka. Aby zamienić ten czysty skrypt w Pythonie w trackowalny komponent Prompt Flow, importujesz dekorator trace z pakietu promptflow tracing. Umieszczasz ten dekorator bezpośrednio nad swoją funkcją chat. Kiedy uruchamiasz swój kod, ten dekorator mówi systemowi, aby po cichu monitorował jego wykonanie. Automatycznie rejestruje on inputy przekazane do funkcji, zwrócony output tekstowy, dokładny czas wykonania i wszelkie wewnętrzne błędy. Jeśli dodasz dekorator trace do innych funkcji pomocniczych w swoim skrypcie, system zbuduje kompletne drzewo wywołań. Zyskujesz pełną obserwowalność wizualnego flow, w tym możliwość podglądu trace'a wykonania w lokalnym interfejsie użytkownika, bez zmieniania struktury swojej logiki. Teraz tooling musi wiedzieć, że ta konkretna funkcja jest entry pointem twojej aplikacji. Robisz to, tworząc jeden, bardzo krótki plik konfiguracyjny o nazwie flow.flex.yaml w tym samym katalogu co twój kod. Ten plik nie definiuje skomplikowanego grafu routingu. Potrzebuje tylko jednej kluczowej informacji, czyli mapowania entry. Wpisujesz słowo entry, a po nim nazwę twojego modułu w Pythonie, dwukropek i nazwę twojej funkcji. Jeśli twój plik nazywa się app.py, a twoja funkcja to chat, twoja wartość entry to po prostu app dwukropek chat. Kiedy testujesz lub uruchamiasz ten flow za pomocą narzędzia command line Prompt Flow lub rozszerzenia do VS Code, system odczytuje ten plik yaml. Wyszukuje funkcję chat w twoim module app, wstrzykuje dostarczone inputy, uruchamia twój czysty kod w Pythonie i zbiera trace'y wygenerowane przez dekorator. Prawdziwą siłą flex flows opartych na funkcjach jest to, że eliminują one bariery między prototypowaniem skryptu a deployem aplikacji na produkcję; twoja czysta logika w Pythonie pozostaje całkowicie pod twoją kontrolą, podczas gdy jeden dekorator i dwulinijkowy plik konfiguracyjny odblokowują obserwowalność klasy enterprise. To wszystko w tym odcinku. Dzięki za wysłuchanie i twórzcie dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Prompt Flow: Kompletny przewodnik, odcinek 8 z 14. Robisz deploy nowej aplikacji z modelem językowym, ale za każdym razem, gdy użytkownik wysyła wiadomość, samo nawiązanie połączenia z bazą danych i załadowanie credentials klienta zajmuje cenne sekundy. Gdy twoja aplikacja musi utrzymać persistent connection lub zapamiętać historię konwersacji, standalone skrypt zawodzi, ponieważ przy każdym uruchomieniu startuje całkowicie od zera. Odpowiedzią na ten problem są Flex Flows: programowanie oparte na klasach. Kiedy budujesz skalowalne aplikacje, state management staje się priorytetem. Jeśli twój flow korzysta z zewnętrznego zasobu, takiego jak klient Azure OpenAI, inicjalizacja tego klienta wymaga odczytania sekretów, weryfikacji endpointów i alokacji pamięci. Jeśli wrzucisz tę logikę w podstawową sekwencję wykonawczą, płacisz ten wysoki koszt startowy za każdym razem, gdy przychodzi request. Użycie klasy w Pythonie jako entry pointu dla twojego Flex Flow pozwala ci całkowicie oddzielić logikę inicjalizacji od logiki wykonania. Flow oparty na klasach wykorzystuje dwie standardowe metody w Pythonie do zarządzania tym cyklem życia. Pierwsza to konstruktor, czyli metoda init. To twoja faza setupu. Prompt Flow uruchamia tę metodę dokładnie raz, gdy flow jest po raz pierwszy ładowany do pamięci. To tutaj wykonujesz całą najcięższą pracę. Druga to metoda call. To twoja faza wykonania, która odpala się za każdym razem, gdy flow jest triggerowany przez request użytkownika. Wyobraź sobie klasę chat flow. Definiujesz metodę init tak, aby przyjmowała obiekt połączenia Azure OpenAI i string z system promptem. Wewnątrz metody init tworzysz klienta Azure OpenAI i zapisujesz go jako property w samej instancji klasy. Klient jest teraz gotowy i czeka. Następnie definiujesz metodę call. Ta metoda przyjmuje nowe pytanie użytkownika i listę poprzednich wiadomości reprezentujących historię czatu. Ponieważ klient jest już w pełni zainicjalizowany, metoda call natychmiast formatuje prompt, wysyła historię czatu do modelu językowego i zwraca odpowiedź. Wykonanie jest szybkie, ponieważ kosztowny setup klienta został całkowicie pominięty. Aby to zadziałało, Prompt Flow musi wiedzieć, jak zinstancjonować twoją klasę. Konfigurujesz to, tworząc plik YAML dla swojego flow. Entry point w tym pliku konfiguracyjnym używa określonego formatu: podajesz nazwę modułu w Pythonie, a po dwukropku nazwę twojej klasy. I to jest najważniejsza część. Twoja konfiguracja YAML nie tylko wskazuje na klasę, ale też definiuje parametry wymagane przez metodę init. Jeśli konstruktor twojej klasy wymaga połączenia z Azure i nazwy modelu, deklarujesz te inputy w pliku YAML w dedykowanej sekcji init. Kiedy silnik Prompt Flow startuje, czyta plik YAML, wstrzykuje te skonfigurowane parametry do konstruktora twojej klasy, a następnie utrzymuje ten zinstancjonowany obiekt w pamięci, aby obsługiwał przychodzące wywołania. Lokalne testowanie flow opartego na klasach jest niezwykle proste, ponieważ opiera się na standardowym zachowaniu Pythona. Nie potrzebujesz skomplikowanego test harness. Po prostu piszesz standardowy skrypt w Pythonie, importujesz swoją klasę, tworzysz instancję, przekazując do konstruktora mockowane połączenia lub lokalne credentials, a następnie wywołujesz obiekt bezpośrednio, przekazując mu testową wiadomość. Możesz niezależnie debugować logikę setupu i logikę wykonania. Główny wniosek jest taki, że flow oparte na klasach dają ci strukturę architektoniczną, która oddziela ciężką pracę związaną z inicjalizacją od powtarzalnej pracy związanej z wykonaniem, utrzymując twój state jako persistent i zapewniając szybkie odpowiedzi. Jeśli uważasz te odcinki za pomocne i chcesz wesprzeć podcast, możesz wyszukać DevStoriesEU na Patreonie. To wszystko w tym odcinku. Dzięki za wysłuchanie i twórz dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Prompt Flow: Kompletny przewodnik, odcinek 9 z 14. Czasami wpatrywanie się w ścianę kodu nie wystarczy, żeby zrozumieć złożoną aplikację. Kiedy prompty, skrypty i wywołania API oddziałują na siebie na dziesiątki sposobów, musisz fizycznie zobaczyć dane przepływające między nimi, żeby zidentyfikować wąskie gardła. DAG flows to odpowiedź dla zespołów, które chcą mieć pełną przejrzystość architektury. DAG to skrót od Directed Acyclic Graph. W Prompt Flow, DAG flow to metoda budowania aplikacji AI poprzez łączenie różnych narzędzi w formie node'ów. Zamiast pisać jeden wielki skrypt, definiujesz strukturę swojej aplikacji w pliku o nazwie flow kropka dag kropka yaml. Ten plik działa jak główny blueprint. Deklaruje on początkowe inputy, poszczególne kroki i końcowe outputy twojej aplikacji. Każdy krok w DAG flow nazywany jest node'em. Node reprezentuje konkretne narzędzie wykonujące pojedyncze zadanie. Możesz mieć node, który uruchamia snippet w Pythonie, inny node, który formatuje prompt, i trzeci node, który wywołuje Large Language Model. Plik YAML opisuje, jak te node'y są ze sobą powiązane przez zależności inputów i outputów. To właśnie mapowanie zależności sprawia, że ten flow działa. Nie mówisz systemowi ręcznie, w jakiej kolejności ma wykonywać kroki. Zamiast tego określasz, że node B wymaga outputu z node'a A. Ponieważ node B nie może wystartować, dopóki node A nie skończy, kolejność wykonywania tworzy się naturalnie. Jeśli dodasz node C, który zależy tylko od początkowego inputu użytkownika, Prompt Flow rozpozna, że nie musi czekać na node A ani B. Automatycznie uruchomi node C równolegle. Silnik czyta plik yaml, rozwiązuje graf i zajmuje się orkiestracją. Ręczne pisanie i utrzymywanie tego pliku yaml może stać się trudne w miarę rozrostu twojej aplikacji. Dlatego większość developerów używa rozszerzenia Prompt flow do VS Code. To rozszerzenie czyta twój plik flow kropka dag kropka yaml i renderuje wizualny interfejs drag-and-drop. Możesz zobaczyć swoją aplikację jako dosłowną mapę połączonych bloków. Weźmy pod uwagę konkretny scenariusz. Budujesz aplikację do czytania raportów finansowych i pisania krótkich podsumowań biznesowych. W edytorze wizualnym tworzysz node typu Python tool i nazywasz go Extract Text. Obok niego dodajesz node typu LLM tool o nazwie Summarize. Zamiast pisać kod do zarządzania stanem między tymi dwiema operacjami, używasz interfejsu. Klikasz output port w node'zie Extract Text i przeciągasz linię do input portu w node'zie Summarize. Właśnie wizualnie połączyłeś ścieżkę danych. Rozszerzenie natychmiast aktualizuje pod spodem plik yaml, żeby zapisać to połączenie. Dostajesz szybkość i przejrzystość wizualnego buildera low-code, ale nadal generujesz plik konfiguracyjny w plain text, który możesz śledzić w systemie kontroli wersji. To wizualne podejście wymusza dyscyplinę architektoniczną. Graf jest acykliczny, co oznacza, że dane mogą płynąć tylko do przodu. Nie ma nieskończonych pętli. Dane wchodzą, przechodzą przez twoją sekwencję narzędzi i wychodzą. Ten ścisły, kierunkowy flow sprawia, że debugowanie jest proste. Jeśli końcowe podsumowanie wygląda źle, możesz otworzyć wizualny graf, kliknąć połączenie między node'ami ekstrakcji i podsumowania, i sprawdzić dokładny string tekstu, który został przesłany przez to połączenie. Wiesz dokładnie, skąd przyszły dane i dokąd poszły. Prawdziwą zaletą DAG flow jest to, że diagram architektury twojego systemu i twoja wykonywalna aplikacja to dokładnie to samo. To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Prompt Flow: Kompletny przewodnik, odcinek 10 z 14. Kiedy model językowy zwraca zhalucynowaną, śmieciową odpowiedź, skąd wiesz, czy to sam model zawiódł, czy twoja logika formatowania promptu miała buga? Możesz rozsypać printy po całej aplikacji, ale staje się to niemożliwe do utrzymania, gdy twoja aplikacja rośnie. Tracing interakcji z LLM rozwiązuje ten problem, rejestrując dokładny kontekst każdego wykonania. Tracing zmienia aplikację LLM typu black-box w transparentną, łatwą do debugowania sekwencję zdarzeń. Rejestruje dokładnie, jakie dane wchodzą do funkcji, co z niej wychodzi i ile czasu zajmuje jej wykonanie. W tym ekosystemie robisz to za pomocą paczki promptflow-tracing. Generowane przez nią dane opierają się na specyfikacji OpenTelemetry, co oznacza, że twoje rekordy z wykonania są zgodne z branżowym standardem dla observability. Aby zarejestrować bazowe interakcje z modelem, używasz funkcji o nazwie start trace. Jeśli wywołasz tę funkcję na samym początku swojego skryptu w Pythonie, Prompt Flow automatycznie zinstrumentalizuje obsługiwanych klientów modelu. Na przykład, jeśli używasz standardowej paczki OpenAI dla Pythona, w ogóle nie musisz modyfikować swoich wywołań API. Tracer dyskretnie przechwytuje interakcję, logując system message, prompt użytkownika, konkretne parametry modelu i końcowy response string. Przechwycenie wywołania API to tylko połowa sukcesu. Logika prowadząca do tego wywołania to zazwyczaj miejsce, w którym kryją się bugi. Aby śledzić własną logikę aplikacji, dodajesz dekorator trace do swoich customowych funkcji. Weźmy na przykład funkcję o nazwie math to code. Funkcja ta przyjmuje od użytkownika opis problemu matematycznego, pobiera niezbędny kontekst, buduje prompt i na koniec prosi GPT-4 o kod w Pythonie. Umieszczając dekorator trace bezpośrednio nad definicją funkcji math to code, mówisz Prompt Flow, żeby rejestrował każde wykonanie tego konkretnego bloku logiki. Zaloguje on wejściowy string użytkownika, końcowy zwrócony kod oraz latency całej operacji. Ponieważ na samej górze pliku uruchomiłeś też start trace, system rozumie relację między twoim kodem a wywołaniem modelu. Buduje on hierarchiczny rekord. Twoja funkcja math to code staje się parent spanem, a wewnętrzne wywołanie OpenAI staje się child spanem zagnieżdżonym w środku. Tę hierarchię możesz przeglądać używając lokalnego Trace UI. Kiedy uruchamiasz skrypt z włączonym tracingiem, Prompt Flow startuje lokalny serwer, który możesz otworzyć w przeglądarce. Ten interfejs daje ci wizualną oś czasu flow twojej aplikacji. Możesz kliknąć parent span math to code, aby zweryfikować argumenty, które otrzymał. Następnie możesz wybrać child span OpenAI, aby sprawdzić dokładny, surowy prompt string, który został pomyślnie wysłany do modelu przez sieć. Jeśli twoja logika budowania kontekstu pominęła jakąś zmienną, natychmiast zobaczysz puste miejsce w surowym prompcie. Prawdziwa siła tracingu to nie tylko zbieranie logów z wykonania, ale ostateczne udowodnienie, co dokładnie wydarzyło się na granicy między kodem twojej aplikacji a zewnętrznym modelem. To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Prompt Flow: Kompletny przewodnik, odcinek 11 z 14. Właśnie spędziłeś trzy miesiące na budowaniu złożonej aplikacji w LangChain. Logika w większości działa, ale gdy agent czasami wpada w złą pętlę lub gubi kontekst, znalezienie dokładnego miejsca, w którym się wyłożył, to koszmar, a przepisanie całości tylko po to, by uzyskać lepsze logi, w ogóle nie wchodzi w grę. Zaawansowany tracing dla LangChain i AutoGen to sposób na bezpośrednie rozwiązanie tego problemu. Budując z użyciem frameworków do orkiestracji, zyskujesz szybkość dzięki abstrakcji. Framework ukrywa zawiłe detale sekwencjonowania promptów, tool execution i parsowania. Ale abstrakcja z natury tworzy czarną skrzynkę. Gdy twój agent zwraca mylącą odpowiedź, musisz zobaczyć jego wewnętrzny chain of thought. Musisz znać dokładny sub-prompt, który wygenerował, surowy response z API, który otrzymał, i wiedzieć, który konkretnie tool call zakończył się błędem. Prompt Flow zawiera samodzielną funkcję tracingu zaprojektowaną dokładnie w tym celu. Nie wymaga od ciebie używania Prompt Flow do samej logiki czy egzekucji. Zostawiasz swój obecny kod w LangChain lub AutoGen dokładnie tak, jak jest. Po prostu podpinasz system trackingu Prompt Flow do swojej zewnętrznej aplikacji. Pomyśl o swoim obecnym skrypcie w Pythonie, który uruchamia agenta LangChain. Aby uzyskać pełną widoczność, w ogóle nie ruszasz definicji swoich chainów. Po prostu idziesz na samą górę swojego głównego pliku wykonywalnego. Importujesz funkcję setupu trace'ów z modułu Prompt Flow i wywołujesz ją raz, zanim twój agent zacznie pracę. Ta jedna komenda to cała integracja. Kiedy wywołujesz tę funkcję, instrumentuje ona twoje środowisko. Ponieważ tracing w Prompt Flow jest oparty na standardach OpenTelemetry, wie, jak nasłuchiwać konkretnych eventów triggerowanych przez te popularne frameworki. Gdy twoja aplikacja LangChain działa, instrumentacja automatycznie przechwytuje pod spodem API calls. Rejestruje inputy, czas egzekucji, outputy i zużycie tokenów dla każdego kroku. Działa to równie płynnie w przypadku AutoGen. Setupy multi-agentowe w AutoGen są powszechnie znane z tego, że trudno je debugować, ponieważ wielu agentów autonomicznie przesyła między sobą wiadomości. Trackowanie, kto przekazał jaki kontekst komu, zazwyczaj oznacza przekopywanie się przez ogromne ściany tekstu w terminalu. Dzięki zainicjalizowaniu trace'a na samej górze skryptu AutoGen, każda pojedyncza wymiana wiadomości jest automatycznie przechwytywana i ustrukturyzowana. Kiedy twój skrypt skończy się wykonywać, otwierasz lokalne Trace UI w Prompt Flow. Zamiast scrollować przez printy w konsoli, dostajesz wizualny timeline. Widzisz przejrzyste drzewo egzekucji. Klikasz na run agenta najwyższego poziomu, rozwijasz node'a i widzisz sekwencję zagnieżdżonych LLM calls i tool executions. Jeśli agent miał halucynację w kroku czwartym, możesz kliknąć bezpośrednio w krok czwarty, aby przeczytać dokładny, niesformatowany tekst, który został wysłany do modelu. Zyskujesz pełną widoczność w nieprzejrzystym frameworku bez konieczności migrowania ani jednej linijki swojej właściwej logiki biznesowej. Prawdziwą zaletą jest tutaj swoboda architektoniczna; możesz orkiestrować swoją aplikację używając frameworka, który najlepiej pasuje twojemu zespołowi, jednocześnie trzymając debugowanie i observability scentralizowane w jednym, czystym, wizualnym interfejsie. Jak zawsze, dzięki za słuchanie. Do zobaczenia w kolejnym odcinku.

Cześć, tu Alex z DEV STORIES DOT EU. Prompt Flow: Kompletny przewodnik, odcinek 12 z 14. Twój prompt zadziałał idealnie na testowym pytaniu, ale co się stanie, gdy odpalisz go na dziesięciu tysiącach prawdziwych zapytań od użytkowników? Zazwyczaj się wywala. Ręczne testowanie promptu na dwóch przykładach jest proste, ale udowodnienie, że działa na setkach edge case'ów, wymaga czegoś bardziej solidnego. I tu do gry wchodzi Scaling Up: Batch Runs with Data. Batch run bierze twój pojedynczy flow i wykonuje go na dużym zbiorze danych. To przenosi cię od budowania logiki do jej weryfikacji w dużej skali. Zamiast wpisywać inputy w interfejsie użytkownika, odpalasz ten proces z poziomu wiersza poleceń. Główne polecenie to pf run create. Odpalając je, instruujesz Prompt Flow, żeby postawił nową instancję runa, odczytał konkretny katalog z flow i nakarmił go plikiem zawierającym wszystkie twoje rekordy testowe. Silnik przetwarza te rekordy, wykonując cały graf flow niezależnie dla każdej pojedynczej linijki w twoim zbiorze danych. Wymagany format danych dla tego pliku wejściowego to JSONL. JSONL to skrót od JSON Lines. Jeśli jesteś przyzwyczajony do standardowego JSON-a, pewnie spodziewasz się jednej wielkiej tablicy owijającej wszystkie twoje obiekty. JSONL pozbywa się tablicy. Każda pojedyncza linijka w pliku tekstowym to osobny, poprawny, samodzielny obiekt JSON, reprezentujący dokładnie jeden test case. Ten format jest bardzo popularny w machine learningu i data pipeline'ach, ponieważ jest lekki i łatwo się go streamuje. Silnik może go czytać linijka po linijce, bez ładowania całego ogromnego pliku do pamięci za jednym zamachem. Weźmy na warsztat flow do klasyfikacji stron internetowych. Twój flow ma za zadanie przyjąć adres internetowy, zeskrapować content i użyć modelu językowego do jego kategoryzacji. Graf flow oczekuje jednego konkretnego inputu typu string o nazwie url. Chcesz przetestować tę logikę na stu różnych stronach, żeby zobaczyć, jak radzi sobie z edge case'ami. Budujesz swój plik JSONL. Każda linijka zawiera obiekt JSON z kluczem, nazwijmy go web link, przechowującym adres docelowy. Aby wystartować batch run, wpisujesz pf run create. Określasz swój katalog z flow za pomocą flagi flow, i wskazujesz plik JSONL używając flagi data. Ale od razu pojawia się strukturalne niedopasowanie. Logika twojego flow twardo wymaga inputu o nazwie url, podczas gdy twój plik z danymi dostarcza pole o nazwie web link. Jeśli odpalisz to polecenie w tym momencie, po prostu się wywali. Silnik nie zgaduje, które pola danych należą do których inputów we flow. Rozwiązujesz ten problem używając flagi column mapping. Ta flaga mówi silnikowi dokładnie, jak połączyć klucze w twoim pliku JSONL z konkretnymi node'ami wejściowymi twojego flow. W argumentach wiersza poleceń wpisujesz nazwę inputu flow, znak równości, a następnie referencję do kolumny z danymi. Prompt Flow używa specyficznej składni bindowania dla tych referencji. Wpisujesz znak dolara, potem słowo data, kropkę, a na końcu nazwę kolumny z twojego pliku. W scenariuszu klasyfikacji stron, mapujesz to wpisując: url równa się znak dolara data kropka web link. Ta jawna instrukcja binduje pole z danymi z wymaganiem twojego flow. Silnik wyciągnie teraz string web link z pierwszej linijki twojego pliku JSONL i wstrzyknie go do inputu url w twoim flow. Następnie powtórzy dokładnie ten sam proces dla drugiej linijki, trzeciej i tak dalej, aż przetworzy cały plik. W ten sposób możesz zmapować wiele inputów. Jeśli twój flow oczekuje url i user id, po prostu dodajesz kolejną instrukcję mapowania do tego samego polecenia. Oddzielenie danych testowych od inputów flow za pomocą jawnego column mappingu oznacza, że nigdy nie musisz zmieniać swojego głównego kodu tylko po to, żeby odpalić nowy dataset. Dzięki za spędzenie ze mną tych kilku minut. Do usłyszenia następnym razem, trzymaj się.

Cześć, tu Alex z DEV STORIES DOT EU. Prompt Flow: Kompletny przewodnik, odcinek 13 z 14. Nie możesz napisać standardowego testu jednostkowego z asercją, że odpowiedź dużego modelu językowego jest równa konkretnemu stringowi. Jeśli output zmienia się za każdym razem, jak matematycznie udowodnisz, że twoja aplikacja faktycznie działa, zanim zrobisz deploy? Odpowiedzią jest paradygmat ewaluacji. W tradycyjnej inżynierii oprogramowania testy jednostkowe są deterministyczne. Przekazujesz konkretny input do funkcji i oczekujesz dokładnego outputu. Duże modele językowe są stochastyczne. Są z natury nieprzewidywalne. Poproś model o sklasyfikowanie strony internetowej, a może on zwrócić słowo sport, może powiedzieć, że kategoria to sport, albo po prostu da ci powiązaną emotikonę. Standardowa asercja w teście nie przejdzie w dwóch z tych trzech przypadków, mimo że model w gruncie rzeczy podał poprawną odpowiedź. Aby udowodnić gotowość do release'u, musisz wyjść poza testy jednostkowe i przyjąć ewaluację statystyczną. W Prompt Flow zajmuje się tym Evaluation Flow. Evaluation flow to po prostu zwykły flow, ale zamiast generować tekst dla użytkownika końcowego, jego jedynym zadaniem jest ocena outputu innego flow. Bierze predykcje wygenerowane przez twoją główną aplikację, porównuje je ze znanym zestawem poprawnych odpowiedzi i zwraca obliczone metryki. Przejdźmy do konkretów. Załóżmy, że właśnie zakończyłeś batch run dla flow klasyfikacji stron internetowych. Przetworzył sto adresów stron i dla każdego z nich zwrócił przewidywaną kategorię. Teraz musisz dokładnie wiedzieć, jak trafne są te predykcje. Bierzesz outputy z tego bazowego runu i przekazujesz je do nowego, dedykowanego evaluation flow, zaprojektowanego do obliczania dokładności klasyfikacji. Odpalasz to z linii komend za pomocą polecenia run create. Wskazujesz swój evaluation flow, ale zamiast po prostu podawać mu statyczny plik z nowymi inputami, przekazujesz mu referencję do poprzedniego batch runu. Evaluation flow potrzebuje dwóch informacji, aby wykonać swoje zadanie. Potrzebuje predykcji modelu i tak zwanego ground truth, czyli historycznie poprawnej odpowiedzi. Dostarczasz mapowanie danych, które łączy te kropki. Mówisz systemowi, żeby zmapował input predykcji z evaluation flow na output kategorii z twojego bazowego runu. Następnie mapujesz input ground truth na kolumnę z rzeczywistą, prawdziwą etykietą, znajdującą się w twoim oryginalnym testowym datasecie. I to jest ta najważniejsza część. Evaluation flow wykonuje się wiersz po wierszu, przechodząc przez całą historię poprzedniego runu. Dla każdego wiersza sprawdza predykcję twojego głównego flow i porównuje ją z ground truth. Przypisuje wynik dla tej konkretnej interakcji. W naszym scenariuszu klasyfikacji może to być po prostu jedynka za dopasowanie i zero za pudło. Inne evaluation flows mogą wykorzystywać model językowy do oceny jakości podsumowania w skali od jeden do pięć. Gdy flow zakończy ocenianie każdego pojedynczego wiersza, agreguje te indywidualne wyniki w końcową, ogólną metrykę. Nie dostajesz tylko ogromnego loga jedynek i zer. Dostajesz konkretną, główną liczbę, na przykład całkowitą dokładność na poziomie dziewięćdziesięciu dwóch procent. Możesz następnie przejrzeć te zagregowane metryki, aby zdecydować, czy obecna wersja twojej aplikacji jest gotowa na produkcję. Nie musisz już zgadywać, czy zmiana w prompcie poprawiła twój system; masz statystyczny dowód na to, o ile lepiej lub gorzej radzi on sobie na całym twoim datasecie. Dzięki za odsłuch. Do usłyszenia następnym razem!

Cześć, tu Alex z DEV STORIES DOT EU. Prompt Flow: Kompletny przewodnik, odcinek 14 z 14. Zbudowałeś, zrobiłeś tracing i ewaluację swojego flow modelu językowego, i działa ono idealnie. Ale teraz siedzi po prostu w twoim środowisku deweloperskim, całkowicie odizolowane od prawdziwych użytkowników. Wyciągnięcie go z IDE i przekształcenie w stabilną, dostępną usługę to dokładnie to, czym zajmiemy się dzisiaj, przenosząc nasze flow na produkcję. W stanie spoczynku, prompt flow to po prostu folder. Zawiera plik konfiguracyjny YAML oraz twoje skrypty w Pythonie lub szablony Jinja. Żeby ten folder robił cokolwiek w prawdziwym świecie, potrzebujesz runtime'u, który załaduje te pliki i będzie nasłuchiwał przychodzących requestów HTTP. Podczas developmentu prawdopodobnie korzystałeś z wbudowanego serwera lokalnego. Uruchamiasz proste polecenie, a ono stawia lokalny endpoint do testowania inputów i outputów. To spoko do weryfikacji logiki, ale nie jest zaprojektowane do obsługi współbieżnego ruchu na produkcji, wydajnego zarządzania pamięcią czy przetrwania awarii systemu. Żeby wejść na produkcję, potrzebujesz konteneryzacji. Prompt Flow jest zbudowany tak, aby integrować się bezpośrednio z Dockerem. Zamiast pisać własny serwer webowy od zera, używasz narzędzi Prompt Flow, żeby wyeksportować swoje flow jako kontener Dockera. Kiedy odpalasz proces eksportu, system generuje Dockerfile. Ten plik definiuje obraz bazowy, kopiuje do niego katalog z twoim flow, instaluje dokładnie te zależności Pythona, które są wymienione w pliku requirements, i stawia gotowy na produkcję serwer webowy, żeby serwować to flow jako REST API. I to jest ta najważniejsza część. Kiedy twoje flow znajdzie się w kontenerze Dockera, przestaje być specjalnym eksperymentem machine learningowym, a staje się standardowym artefaktem. Możesz je traktować jak każdy inny mikroserwis. Weźmy konkretny scenariusz. Masz zwalidowane flow czatu dla supportu. Budujesz obraz Dockera i robisz push do swojego prywatnego container registry. Następnie robisz deploy tego obrazu na klaster Kubernetes. Piszesz standardową konfigurację deploymentu, mówiąc Kubernetesowi, żeby podniósł trzy repliki kontenera z twoim flow, i stawiasz przed nimi load balancer. Teraz twoja aplikacja frontendowa wysyła standardowe requesty HTTP do load balancera, który rozdziela ruch między twoje kontenery. Jeśli twoje flow zostanie zalane requestami od użytkowników, Kubernetes po prostu zeskaluje w górę więcej instancji twojego flow. Jeśli nie chcesz zarządzać klastrem Kubernetes, ten sam obraz Dockera zadziała idealnie na zarządzanych usługach platformowych. Możesz zrobić jego deploy bezpośrednio do Azure App Service lub u dowolnego innego dostawcy chmurowego, który hostuje kontenery. Dla twojego flow nie ma znaczenia, gdzie jest uruchamiane, o ile ma container runtime. Istnieje jeszcze jeden alternatywny wzorzec deploymentu. Jeśli nie budujesz serwisu webowego, możesz dystrybuować flow jako aplikację wykonywalną. To pakuje flow i jego zależności runtime'owe do samodzielnego pliku wykonywalnego. To przydatne, jeśli musisz uruchomić logikę bezpośrednio na maszynie klienckiej lub urządzeniu edge, całkowicie omijając potrzebę instalacji Pythona czy stawiania serwera. Przeniesienie prompt flow na produkcję nie wymaga własnościowego hostingu ani specjalistycznej infrastruktury do machine learningu. Dzięki eksportowi do Dockera, twoje flow modeli językowych płynnie integrują się z dokładnie tymi samymi pipeline'ami continuous delivery i orkiestratorami kontenerów, których już używasz do swoich tradycyjnych serwisów backendowych. Jeśli chcesz pójść o krok dalej, zachęcam cię do przeczytania oficjalnej dokumentacji Prompt Flow, spróbowania samodzielnego zrobienia deployu kontenera, albo odwiedzenia DEV STORIES DOT EU, żeby zasugerować tematy, które chcesz zobaczyć w przyszłych seriach. Chciałbym poświęcić chwilę, żeby podziękować ci za słuchanie — to bardzo nam pomaga. Miłego!