Microsoft Foundry: platforma aplikacji i agentów AI

Czy działający pokaz modelu AI oznacza, że możesz udostępnić go pracownikom? Pomiędzy odpowiedzią na jedno pytanie a utrzymywaną aplikacją pozostają dane, uprawnienia, testy, integracje i koszt obsługi. Microsoft Foundry pomaga budować aplikacje oraz agentów AI, ale wymaga zaprojektowania całego cyklu ich pracy. Dostęp do modelu jest jednym z elementów rozwiązania.

Jeśli chcesz przygotowywać odpowiedzi na zapytania ofertowe, określ najpierw granicę zadania. Aplikacja może wyszukiwać zatwierdzone materiały i tworzyć szkic, podczas gdy handlowiec sprawdza warunki oraz zatwierdza wysłanie. Dopiero dla takiego zakresu dobieraj model, narzędzia i sposób uruchomienia.

Jedną z decyzji jest sposób udostępnienia samego modelu. Porównanie wdrożenia modelu jako usługi z innymi wariantami opisuje MaaS w Microsoft Foundry; nie rozstrzyga ono jeszcze, czy cała aplikacja jest gotowa do użytku.

Co zmieniło się od Azure AI Foundry

Aktualna nazwa platformy to Microsoft Foundry; wcześniej funkcjonowały Azure AI Studio i Azure AI Foundry. Microsoft rozdziela też nowe projekty Foundry od starszych projektów opartych na hubach, dostępnych w portalu classic. Zmiany nazw i modelu zasobów opisuje aktualny przegląd Foundry.

Ma to praktyczne znaczenie przy porównywaniu ofert i instrukcji. Materiał pokazujący hub, połączenia i dawny interfejs może dotyczyć utrzymywanego rozwiązania, ale nie przedstawiać zalecanego początku nowego projektu. Poproś wykonawcę o wskazanie konkretnego wariantu, używanych funkcji oraz ich statusu dostępności.

Foundry łączy modele, agentów, narzędzia oraz możliwości oceny i obserwacji działania. Nie wszystkie funkcje mają ten sam status wydania. Oznaczenie preview trzeba sprawdzić na poziomie elementu potrzebnego w twoim projekcie, zamiast przyjmować, że cała platforma ma jednolite warunki.

Model, aplikacja i agent mają różne role

Model generuje wynik na podstawie wejścia. Aplikacja dodaje sposób użycia: przyjęcie pytania, przygotowanie kontekstu, pokazanie odpowiedzi i obsługę błędów. Agent może dodatkowo korzystać z narzędzi, wybierając działania w ramach zaprojektowanego zakresu. Te poziomy wymagają osobnego sprawdzenia.

Nie każde zadanie potrzebuje agenta. Jeśli pracownik przekazuje krótki tekst i oczekuje uporządkowanego streszczenia, prostszy przebieg może wystarczyć. Dodawanie samodzielnego doboru narzędzi ma sens wtedy, gdy rozwiązuje rozpoznaną potrzebę, a firma potrafi kontrolować wynik.

Element rozwiązania	Pytanie właściciela procesu	Dowód potrzebny przed uruchomieniem
Model	Czy radzi sobie z naszym typem zadania?	Ocena reprezentatywnych przykładów
Źródła wiedzy	Czy odpowiedź opiera się na aktualnych materiałach?	Sprawdzenie źródła i wersji
Narzędzia	Jakie czynności system może wykonać?	Próba dozwolonych i zabronionych działań
Interfejs	Czy użytkownik rozumie wynik i ograniczenia?	Samodzielne wykonanie zadania
Utrzymanie	Kto reaguje na błędy i zmiany?	Właściciel, procedura i zastępstwo

Jak wybrać sposób budowy

Foundry Agent Service obejmuje między innymi agentów konfigurowanych przez instrukcje, model i narzędzia oraz hosted agents uruchamiających własny kod. Dostępna jest także ścieżka wykorzystania API z rozwiązania działającego poza tym środowiskiem. Różnice przedstawia dokumentacja Agent Service.

Wybór powinien wynikać z potrzebnej kontroli i kompetencji utrzymania. Konfiguracja deklaratywna może ograniczyć ilość własnego kodu, ale nadal wymaga testów instrukcji, narzędzi i dostępu. Własny kod daje więcej swobody, lecz oznacza odpowiedzialność za jego jakość oraz aktualizacje zależności.

Poproś o pokazanie zmiany wymagania: na przykład dodania nowego rodzaju zapytania ofertowego. Sprawdź, co trzeba zmienić, jak zostanie to przetestowane i jak zespół wróci do wcześniejszej wersji po problemie. Taka próba mówi o utrzymaniu więcej niż porównanie liczby funkcji na slajdzie.

Nie uzależniaj całego rozwiązania od konta jednej osoby. Właściciel projektu powinien wiedzieć, kto zarządza konfiguracją, kto zatwierdza wdrożenie i kto ma dostęp do danych diagnostycznych. Zastępstwo musi obejmować także informacje potrzebne do zrozumienia błędu.

Porównaj modele na własnych przypadkach

Zacznij od zestawu zadań, a dopiero później od katalogu modeli. Dla odpowiedzi ofertowych wybierz pytania o zakres usługi, wyłączenia odpowiedzialności, terminy i warunki wymagające dodatkowej decyzji. Uwzględnij materiały po polsku, jeśli w tym języku pracuje zespół.

Nie oceniaj wyłącznie stylu. Krótsza odpowiedź z poprawnym wskazaniem braku danych może być bardziej użyteczna niż płynny tekst dopowiadający warunki handlowe. Ustal osobno wymagania dotyczące poprawności, kompletności, czasu oczekiwania i kosztu.

Przykład do próby	Co powinien zrobić system	Co oznacza błąd
Pytanie z odpowiedzią w aktualnym materiale	Przygotować zgodny szkic	Zmiana warunku lub pominięcie wyjątku
Brak potrzebnej informacji	Wskazać brak i ścieżkę wyjaśnienia	Wymyślenie ceny albo terminu
Sprzeczne wersje dokumentu	Ujawnić problem lub zastosować zatwierdzoną regułę	Przypadkowe wybranie starej wersji
Żądanie poza zakresem roli	Odmówić niedozwolonego działania	Użycie uprawnień szerszych niż potrzeba
Nieudane wywołanie narzędzia	Podać rzeczywisty stan	Potwierdzenie czynności, której nie wykonano

Zachowaj część przykładów do niezależnego odbioru. Jeśli cały zestaw służy dopracowaniu instrukcji, końcowy wynik pokaże przede wszystkim dopasowanie do znanych przypadków. Nowy typ dokumentu lub nietypowe pytanie może ujawnić inne problemy.

Zadbaj o kontekst i źródła

Przygotowanie odpowiedzi z firmowych materiałów wymaga wyboru źródeł, sposobu wyszukiwania oraz zasad aktualizacji. Nie zaczynaj od przekazania całego archiwum. Wybierz mały, zatwierdzony zakres i sprawdź, czy system potrafi odnaleźć fragment potrzebny do odpowiedzi.

Jeżeli dokument zawiera nieaktualne cenniki albo sprzeczne instrukcje, samo zwiększenie możliwości modelu może nie rozwiązać problemu. Potrzebujesz właściciela treści i reguły rozstrzygania wersji. Zapisz, kiedy wycofany dokument przestaje być źródłem odpowiedzi oraz kto sprawdza skuteczność tej zmiany.

Dostęp do źródła i poprawność odpowiedzi odbieraj osobno. Handlowiec może mieć prawo otworzyć dokument, ale aplikacja nadal może źle odczytać warunek. Odwrotnie, poprawny tekst nie usprawiedliwia wykorzystania danych, których użytkownik nie powinien widzieć.

Przy narzędziach wykonujących działania zacznij od najmniejszego potrzebnego zakresu. Utworzenie szkicu oferty różni się od wysłania go klientowi, a wysłanie od zatwierdzenia rabatu. W projekcie wskaż, które czynności wymagają decyzji człowieka i jak zapisujesz jej zakres.

Jak oceniać jakość w Foundry

Foundry udostępnia ocenę modeli i agentów, w tym pracę z przygotowanymi zestawami danych. Dostępne podejścia oraz wymagania przedstawia instrukcja ewaluacji w portalu. Wybierz miary odpowiadające zadaniu; wysoka ocena jednego aspektu nie dowodzi poprawności całego procesu.

Automatyczne oceny mogą pomagać w porównywaniu wariantów, ale próbkę wyników powinien przejrzeć człowiek znający firmowe reguły. Jeżeli oceniający model nie ma poprawnej odpowiedzi odniesienia lub nie rozumie wyjątku w umowie, jego wynik również może być mylący.

W syntetycznym odbiorze na 50 pytaniach otrzymujesz 44 poprawne odpowiedzi, 4 uzasadnione odmowy i 2 błędne odpowiedzi. To nie oznacza po prostu 96% skuteczności. Rozdziel odpowiedzi, odmowy i błędy oraz sprawdź ich konsekwencje. Jedna zmyślona gwarancja w ofercie może zatrzymać wdrożenie mimo dobrego wyniku pozostałych prób. To przykład kryteriów odbioru, nie rezultat projektu autora.

Dodaj test wieloetapowej rozmowy. Użytkownik może zmienić zakres pytania, poprawić kwotę albo odwołać wcześniejszą decyzję. Sprawdź, czy system uwzględnia aktualne ustalenie i nie wykonuje czynności na podstawie nieaktualnego kontekstu.

Policz koszt zakończonej sprawy

W kalkulacji uwzględnij wywołania modeli, korzystanie z narzędzi, wyszukiwanie, przechowywanie oraz działanie aplikacji. Dokładny sposób rozliczenia zależy od wybranych usług i konfiguracji. Nie wyceniaj całego projektu jedynie ceną pojedynczego wywołania modelu.

Najbardziej użyteczna miara dla właściciela procesu to koszt sprawy zakończonej wynikiem spełniającym wymagania. Dwie tańsze odpowiedzi wymagające długiej poprawki mogą kosztować firmę więcej niż jedna droższa, którą można szybko sprawdzić.

W umownym porównaniu wariant A kosztuje 1 PLN za przygotowanie szkicu i wymaga 8 minut kontroli, a wariant B kosztuje 2 PLN i wymaga 3 minut. Przy przyjętej do obliczenia wartości pracy 60 PLN za godzinę otrzymujesz odpowiednio 9 PLN i 5 PLN łącznego kosztu. To syntetyczny model, nie cennik Foundry. Różnica zależy od rzeczywiście zmierzonego czasu i porównywalnej jakości.

Sprawdź też nieudane próby, ponowienia i zadania porzucone. Jeśli płacisz za kilka podejść, zanim powstanie użyteczna odpowiedź, powinny wejść do oceny. Osobno zapisz koszt budowy i utrzymania, którego nie ma w rachunku pojedynczej sprawy.

Warto także ustalić, które sprawy kierujesz do aplikacji. Proste pytanie o publicznie dostępny opis usługi może wymagać innego przebiegu niż negocjacja obejmująca dane kilku klientów. Zbyt szeroki zakres utrudnia zarówno ocenę jakości, jak i wyjaśnienie kosztów. W pilotażu grupuj zadania według ich trudności oraz skutków błędu.

Dla każdej grupy zapisz akceptowalny czas kontroli. Jeśli aplikacja przygotowuje tekst szybciej, ale handlowiec dłużej szuka podstaw odpowiedzi, korzyść może być pozorna. Poproś użytkowników o zanotowanie czasu od rozpoczęcia zadania do zatwierdzenia wyniku, a nie tylko czasu oczekiwania na wygenerowany tekst.

Jak ocenić ochronę treści

Filtry i mechanizmy ochrony są częścią platformy, lecz nie potwierdzają prawdziwości każdej odpowiedzi. Tekst zgodny z regułami dotyczącymi szkodliwych treści nadal może zawierać niewłaściwy termin realizacji. Utrzymuj osobne próby dla ochrony, zgodności z uprawnieniami oraz poprawności biznesowej.

Przygotuj również dokument testowy zawierający polecenie sprzeczne z zadaniem aplikacji. Sprawdź, czy system traktuje je jako treść źródłową, zamiast wykonywać zawarte w nim instrukcje. Taki test powinien odbywać się na sztucznych danych i w kontrolowanym środowisku. Wynik zapisz wraz z wersją konfiguracji, aby można go było powtórzyć po zmianie modelu lub sposobu wyszukiwania.

Co przygotować przed produkcją

Uruchomienie dla większej grupy wymaga planu zgłoszeń, obserwacji i zmian. Nie wystarczy przechowywanie logów: ktoś musi umieć z nich wyjaśnić, czy problem dotyczy modelu, źródła, narzędzia czy uprawnień.

Obszar	Ustalenie operacyjne	Próba odbiorowa
Wersja	Znany model, instrukcje i konfiguracja narzędzi	Odtworzenie wyniku dla wskazanej wersji
Zmiana	Test przed udostępnieniem użytkownikom	Porównanie starego i nowego wariantu
Błąd	Właściciel i sposób zgłoszenia	Przekazanie niepoprawnej odpowiedzi do analizy
Awaria	Czytelny komunikat i droga zastępcza	Kontynuacja sprawy bez aplikacji
Dostęp	Role i termin przeglądu	Próba użytkownikiem z ograniczonym zakresem
Koszt	Odbiorca sygnału i reguła reakcji	Wyjaśnienie nagłego wzrostu użycia

W pilotażu przećwicz także wycofanie dostępu do dokumentu i zmianę narzędzia. Zespół powinien potwierdzić, że poprawka zadziałała w rzeczywistym przebiegu. Samo zapisanie konfiguracji w portalu nie zamyka zgłoszenia.

Rozwijaj rozwiązanie dopiero po określeniu, które elementy pilotażu przechodzą do stałego utrzymania. Materiały testowe, dostęp wykonawcy i eksperymentalne integracje wymagają świadomej decyzji. Właściciel biznesowy powinien otrzymać listę znanych ograniczeń wraz ze sposobem ich obsługi.

Kolejny krok to przygotowanie środowiska Azure dla AI. Foundry ma wspierać konkretny system pracy firmy, dlatego na pierwszy warsztat przynieś dziesięć rzeczywistych zadań, zatwierdzone źródła i opis czynności wymagających decyzji człowieka. Na tej podstawie ustal zakres pierwszej próby.