Prototypowanie, śledzenie, ocena, testy typu red team: proces pracy agenta AI w Microsoft Foundry
Wybór modelu, instrukcje, ugruntowanie, śledzenie, ocena partii oraz zautomatyzowane testy typu red team dla agenta AI w Microsoft Foundry, a następnie przejście do SDK.
Źródła: Build, Evaluate, and Red-Team an AI Agent Before You Write Code
Wyprowadzenie od agenta AI kilku dobrych odpowiedzi zajmuje zaledwie kilka minut. Podjęcie decyzji o jego publikacji trwa znacznie dłużej, ponieważ zespół musi najpierw sprawdzić, czy wybrany model jest warte jego kosztu, czy agent korzysta z odpowiednich danych, jakie narzędzia wykorzystuje, jak oceniane są jego odpowiedzi oraz jak radzi sobie z osobą aktywnie próbującą go pokonać.
Microsoft Foundry gromadzi dużą część tego procesu w jednym przestrzeni roboczej przeglądarki, obejmującej porównanie modeli, instrukcje, narzędzia i wiedzę, śledzenie, ocenę, generowane dane testowe oraz zautomatyzowane testy typu red teaming. Jego prawdziwa wartość nie polega na tym, że kod może być odkładany w nieskończoność. Pozwala on na podjęcie kosztownych decyzji projektowych, gdy zmiana projektu jest jeszcze tania, zanim kod produkcyjny stanie się trudny do modyfikacji.
Następna część opisuje drogę jednego agenta od pustego projektu do prototypu opartego na danych – prototyp ten jest analizowany, oceniany i testowany, a następnie wskazuje moment, w którym praca przechodzi z portalu do SDK. Środowiskiem jest Microsoft Build retail-agent w ramach nowego doświadczenia Foundry, hostowanego w regionie Sweden Central. Portal służy jako narzędzie do szybkiej iteracji, a ścieżka prowadząca do wersji produkcyjnej pozostaje w obrębie tego samego projektu Foundry, dzięki czemu nic nie musi być budowane od zera.
Zacznij od czegoś, co już działa
Czysty projekt Foundry to przestrzeń robocza zawierająca agenty, modele, narzędzia, wiedzę, mechanizmy oceny oraz funkcje umożliwiające monitorowanie. Dokładne kroki konfiguracji, ustawienia domyślne oraz dostępne funkcje różnią się w zależności od regionu i zmieniają się z czasem, dlatego sam portal powinien być traktowany jako ostateczne źródło informacji na temat możliwości danego projektu.
Gdy agent zostanie utworzony, to właśnie w tym interfejsie rozpoczyna się faktyczna praca. Tam ustawia się model i instrukcje, dołącza narzędzia lub wiedzę, a wyniki są testowane w oknie czatu. To również tutaj prototyp po raz pierwszy pokazuje, jak słaby jest. Gdy zadasz szerokie pytanie dotyczące produktu ledwo skonfigurowanemu agentowi, odpowiedź jest zazwyczaj banalna. Może brzmieć pewnie, mimo że nie wie nic o katalogu, zasadach ani kontekście biznesowym. Zachowaj tę odpowiedź jako punkt odniesienia, ponieważ każda późniejsza zmiana powinna być oceniana w jej porównaniu.
Wybór modelu na podstawie dowodów
Mocny model domyślny niekoniecznie jest tym właściwym do użycia w produkcji. Niektóre zadania wymagają głębokiego rozumowania, podczas gdy inne cenią szybkość lub niską cenę, dlatego wybór powinien wynikać z oceny, a nie z intuicji. Foundry oferuje kilka narzędzi do filtrowania katalogu:
- Tabela rankingowa, która klasyfikuje modele pod względem jakości, bezpieczeństwa, wydajności oraz parametrów związanych z kosztami.
- Wykresy kompromisów, które przedstawiają dwie cechy na jednym wykresie, np. jakość w stosunku do ceny.
- Widok obok siebie, który redukuje listę modeli do tych najbardziej odpowiednich dla danego obciążenia.
- Router modeli, który przypisuje każdą prośbę odpowiedniemu modelowi zgodnie z zasadą równowagi między kosztem a jakością, dzięki czemu jeden model nie musi odpowiadać na wszystko.
Samych wyników testów benchmark nie wystarcza jako dowodu. Lepszym rozwiązaniem jest przeprowadzenie tego samego obciążenia na każdym z kandydatów. Router sprawdza się wtedy, gdy prośby znacznie różnią się pod względem trudności. Obecnie dostępne są tryby Zrównoważony, Koszt i Jakość, a nowsze wersje automatycznie przechodzą na inny odpowiedni model, jeśli ten wybrany przestanie działać.
Kolejnym krokiem jest wysłanie tych samych instrukcji do każdego ustawienia kandydata i porównanie jakości odpowiedzi, opóźnienia oraz kosztów. Testy wykluczają nieodpowiednie opcje, a twoja praca decyduje o zwycięzcy. Microsoft Learn opisuje zarówno proces testowania, jak i narzędzie do ich realizacji w swojej dokumentacji Foundry.
Instrukcje to najtańszy narzędzie
Zmiana modeli nie zawsze jest właściwym pierwszym krokiem. Niejasne instrukcje mogą przekształcić drogi model w zwykłego chatbota. Narzędzie Prompt Optimizer w Foundry przepisuje i przebudowuje instrukcje, wyjaśnia powody zmian w poszczególnych częściach oraz umożliwia kilka prób przed faktyczną aplikacją zmian. Dzięki temu instrukcje stają się wersjonowanym wprowadzeniem dla zespołu inżynieryjnego, zamiast luźnym akapitem przepisywanym aż do uzyskania lepszej odpowiedzi.
Piękna przepisana wersja niewiele dowodzi. Lepsza metoda polega na porównaniu jednego zestawu danych do oceny zarówno ze starym, jak i nowym wariantem. Każda persona, układ odpowiedzi, zachowanie awaryjne lub ograniczenia dotyczące zapytań poza tematem, których agent powinien przestrzegać, musi znaleźć się zarówno w jego instrukcjach, jak i w kryteriach oceny jego wyników.
Odpowiedzi powiązane z zatwierdzonymi danymi
Instrukcje określają, jak agent ma się zachowywać, natomiast wiedza decyduje o tym, na co jest on w stanie odpowiedzieć. W prostszych przypadkach dołączanie plików i udostępnianie ich za pomocą narzędzi wyszukiwania umożliwia, by odpowiedzi odwoływały się do materiałów źródłowych.
W większych strukturach korporacyjnych można wykorzystać Foundry IQ – wspólną warstwę wiedzy opartą na wielu źródłach. Baza wiedzy może łączyć się z Azure Blob Storage, SharePoint, OneLake, istniejącymi indeksami wyszukiwania oraz publicznym treścią internetową, a systemy wyszukiwania planują zapytania, wybierają źródła, przeszukują je i zwracają powiązane, uzasadnione wyniki.
Jedno ostrzeżenie dotyczy kontroli dostępu. Uprawnienia na poziomie dokumentu są uwzględniane tylko w przypadku źródeł i konfiguracji, które je obsługują, dlatego nikt nie powinien określać bazy wiedzy jako rozumiejącej uprawnienia, zanim uprawnienia źródła oraz mechanizm identyfikacji zostaną faktycznie skonfigurowane.
Aby zobaczyć efekt, zadaj jedno pytanie dwa razy – przed i po uruchomieniu procesu. Pierwsza odpowiedź ujawnia ogólną wiedzę modelu, a druga powinna pokazać różnicę spowodowaną Twoimi danymi.
Włącz śledzenie wcześnie
Obserwowalność jest najbardziej przydatna, gdy agent nadal zawodzi. Śledzenie w Foundry follows konwencjami OpenTelemetry i łączy się z Azure Monitor Application Insights, rejestrując ścieżkę agenta lub aplikacji, dzięki czemu po fakcie można przeanalizować wywołania modelu, użycie narzędzi, dane wejściowe, wyjściowe oraz czasy ich przetwarzania.
Trzy warstwy korzystają z tego wspólnego obrazu operacyjnego, z których każda odpowiada na swoje pytanie:
- Śledzenie pokazuje, co wydarzyło się podczas konkretnej rundy.
- Ocena informuje, czy zachowanie spełniło określone standardy.
- Monitoring pokazuje, jak zmieniają się wyniki w czasie.
Pamiętaj, że usługa Application Insights telemetry ma cenę zależną od objętości i czasu przechowywania danych. Przygotuj budżet na funkcje monitoringu jako element architektury produkcyjnej, a nie jako darmowy bonus do debugowania.
Mierz zachowanie, a nie domysły
Testy praktyczne są przydatne do eksploracji, ale nie mogą potwierdzić, czy wprowadzona zmiana poprawiła funkcjonowanie agenta. Foundry zawiera gotowe narzędzia oceny w kilku aspektach zachowania: jakości, ryzyka i bezpieczeństwa oraz specyficzne dla agenta wskaźniki, takie jak to, czy zadanie zostało wykonane, czy zakończone, czy intencja została zrozumiana oraz jak dobrze wykorzystano dostępne narzędzia.
Customowi ewaluatorzy zazwyczaj przybierają jedną z dwóch form. Te oparte na rubrykach lub instrukcjach wykorzystują model jako sędziego w przypadku kryteriów subiektywnych lub zależnych od kontekstu. Ewaluatory deterministyczne to proste funkcje dla kryteriów, które można bezpośrednio obliczyć. Stopień przyjazności odpowiedzi może wymagać użycia rubryki, natomiast limit długości nigdy. Ewaluacja sama w sobie dodaje kosztów i zakłóceń, więc gdy funkcja może dokonać oceny w sposób niezawodny, dodatkowe wywołanie modelu to marnowanie pieniędzy.
Zbiory danych sprawiają, że iteracje są precyzyjne
Jedna instrukcja pokazuje, że dana funkcja działa, ale zbiór danych ujawnia wzorce. Foundry potrafi ocenić plik JSONL lub CSV przygotowany przez użytkownika, istniejące już ślady działania lub syntetyczne dane testowe. Dane syntetyczne są przydatne przed uruchomieniem oraz wtedy, gdy ruch online jest zbyt niewielki, by objąć interesujące przypadki krawędziowe.
W rezultacie powstaje pętla, którą można powtarzać:
- Ustal zestaw testowy reprezentatywny, aby pozostał niezmienny.
- Zastosuj na nim obecną wersję agenta.
- Zmień dokładnie jedną zmienną – czy to model, instrukcje, ustawienia narzędzia, czy też inne elementy.
- Ocenić ponownie na tym samym zestawie.
- Porównać wyniki, czasy reakcji oraz zużycie zasobów.
- Przyjąć lub odrzucić tę zmianę.
Tutaj praca przestaje przypominać drobne modyfikacje promptów i zaczyna przypominać testy regresji w oprogramowaniu.
Red teaming wykrywa to, co umyka normalnym metodom oceny
Zwykłe kontrole jakości sprawdzają, czy agent dobrze wykonywa swoje zadanie. Red teaming bada to, co robi system, gdy ktoś celowo podaje mu wrogie dane wejściowe. Agent AI Red Teaming znajdujący się w Foundry łączy projekt o otwartym kodzie źródłowym PyRIT z mechanizmami oceny ryzyka i bezpieczeństwa w Foundry. Testuje obsługiwane modele i agenty za pomocą metod ataku zaprojektowanych tak, by obejść standardowe zabezpieczenia, oraz podaje wskaźnik skuteczności ataku (ASR).
Do obsługiwanych metod należą transformacje takie jak Flip i Tense, a także metody jailbreak oraz inne podstępne techniki; obecne scenariusze ryzyka obejmują szkodliwy treść, wyciek danych poufnych, zabronione działania oraz pośrednią iniekcję poleceń. Ćwiczenie przynosi efekty, gdy jego wyniki skłaniają do kolejnej rundy prac inżynieryjnych, a nie gdy kończy się jedynie jako zrzut ekranu w celach raportowych. Traktuj je jako cykl:
- Zrób skan w miejscu, które nie jest środowiskiem produkcyjnym.
- Zbadaj, która kategoria ryzyka i jaka metoda ataku przeszły przez zabezpieczenia.
- Napraw przyczynę, czy to błąd w instrukcjach, ograniczenie narzędzia, kontrola treści lub uprawnienia.
- Zrób skan ponownie.
- Obserwuj, czy wskaźnik skuteczności ataków spada.
Monitoruj całą flotę
Gdy agenci są już w użyciu, pytanie przestaje dotyczyć tego, czy dany polecenie zadziałało, a staje się to, jak system zachowuje się na przestrzeni tygodni. Widoki monitoringu i operacyjne pokazują dane dotyczące całego obciążenia systemu, takie jak liczba połączeń, użycie tokenów, błędy oraz wskaźniki związane z kosztami, z możliwością przejścia do szczegółów poszczególnych agentów i modeli, gdzie to jest dostępne.
Rozważanie kwestii mikrosług jest tu przydatne, ale tylko w pewnych granicach. Agenta można traktować jako jednostkę zachowań posiadającą własną wersję, składającą się z instrukcji, narzędzi, wiedzy, polityki modelowej oraz wyników, które można zaobserwować. Nie każdy agent musi stać się oddzielną usługą wdrożoną osobno. Chodzi o wyznaczenie granic, aby jeden agent mógł być edytowany, oceniany i awansowany bez konieczności przepisywania całej otaczającej go struktury.
Pętla pod portalem
W praktyce cykl ten obejmuje etapy budowania, pomiaru, optymalizacji, zarządzania oraz powrót do początku, gdy dowody wskazują, że agent nie jest gotowy. Postępy są dokonywane wtedy, gdy ślady działania i wyniki oceny przekraczają wcześniej ustalone kryteria, a nie dlatego, że demo wyglądało dobrze. Ekraniki produktu się zmieniają, ale rutyna pozostaje niezmienna: prototypowanie, śledzenie, ocena, wzmocnienie bezpieczeństwa, monitorowanie i powtórzenie procesu.
Jedna uwaga na razie: Microsoft planuje wycofać Foundry Workflows 1 grudnia 2026 roku i kieruje nowe rozwiązania do frameworku Microsoft Agent. Nowy projekt nie powinien być budowany na bazie rozwiązań, które zostaną usunięte.
Od prototypu w przeglądarce do kodu produkcyjnego
Portal powinien skrócić drogę do stworzenia kodu, a nie zastąpić go. Potrzeby takie jak niestandardowa orkiestracja, CI/CD, głębsza integracja czy kod agenta hostowanego wymagają użycia Foundry SDK oraz jego narzędzi, dostępnych obecnie dla Pythona, C#, JavaScriptu i Java. Pod względem architektonicznym zasoby i punkty końcowe projektu pozostają centralne. Portal, SDK oraz narzędzia to po prostu różne wejścia do jednego projektu Foundry i jego zasobów, więc wyobraźmy sobie jeden projekt z jednolitym punktem końcowym, bez oddzielnej platformy prototypowej i platformy produkcyjnej. Szybki start z SDK na Microsoft Learn to miejsce, gdzie rozpoczyna się ta transformacja.
Kolejne eksperymenty
Następnie omówimy dwa tematy. Pierwszym jest orkiestracja wielu agentów, w której niezależnie testowalne agenty, z wyraźnie określonymi zasadami działania oraz punktem odniesienia do oceny, są łączone za pomocą nowoczesnego frameworku orkiestracyjnego, a nie pakowane w jeden ogromny prompt. Drugim tematem jest personalizacja modeli, którą warto rozważyć dopiero wtedy, gdy metody promptowania, ugruntowania, kierowania i projektowania narzędzi okazały się niewystarczające. Obie te kwestie należą do dziedziny oceny opisanej tutaj.
Uwaga końcowa
Pierwsza praktyczna odpowiedź agenta rozpoczyna proces, ale go nie kończy. Kandydat na wersję finalną wymaga dowodów z kilku obszarów: wyboru modelu, który sprawdził się w porównaniu obciążeń, mechanizmów wpływających na zmianę odpowiedzi w sposób widoczny, wywołań narzędzi, które można zaobserwować, powtarzalnej oceny oraz wskaźnika ryzyka typu red team, który powinien maleć z upływem czasu. Portal umożliwia szybki cykl pracy, natomiast projekt i SDK przenoszą tę pracę do rzeczywistej inżynierii produkcyjnej. Buduj szybko, wdrażaj narzędzia diagnostyczne od samego początku, testuj każdą zmianę na tym samym obciążeniu, sprawdzaj swój własny system przed osobami z zewnątrz i przejdź na kod, gdy przeglądarka będzie już dobrze radzić sobie z danymi zadaniami.
Literatura pokrewna
- Praktyczne notatki: Claude Code Agent Teams: Praktyczny przewodnik po budowie zespołu — Szczegółowy opis Praktycznych notatek: Claude Code Agent Teams: Praktyczny przewodnik po budowie zespołu, w tym informacje o umowach, sprawdzaniach oraz miejscach na kod dostępnych dla zespołów stosujących ten model.
- Samoleczący zespół wielu agentów w LangGraph: architekt, tester, debugger — Stwórz maszynę stanową w LangGraph w Pythonie, w której architekt, programista, środowisko testowe pytest, debugger oraz recenzent współpracują ze sobą w pętli, aż testy się udają.