Azure AI Foundry: jak zaplanować projekt AI

Azure AI Foundry, obecnie rozwijane pod nazwą Microsoft Foundry, nie zastępuje projektu AI gotową platformą „wszystko w jednym”. Porządkuje modele, agentów, narzędzia, ocenę i kontrolę dostępu, ale nadal wymaga decyzji o danych, mierniku jakości oraz granicach działania. Pierwszy projekt powinien używać najmniejszego zestawu usług potrzebnych do sprawdzenia jednej hipotezy biznesowej. Zacznij od jednego projektu Foundry, jednego wdrożenia modelu, kontrolowanego źródła danych, zestawu testowego i telemetrii. Kolejne składniki dodawaj dopiero wtedy, gdy konkretny wymóg uzasadnia ich koszt i odpowiedzialność operacyjną.

Ten poradnik prowadzi przez decyzje pierwszego projektu. Jeśli najpierw chcesz ocenić samą platformę i jej granice, przeczytaj przegląd Microsoft Foundry; do testowania przepływu aplikacji służy z kolei osobna analiza Prompt flow. Rozdzielenie tych pytań pomaga uniknąć wyboru narzędzia przed ustaleniem zadania.

Azure AI Foundry ma dziś nazwę Microsoft Foundry

Aktualna dokumentacja Microsoft opisuje Microsoft Foundry jako platformę łączącą agentów, modele i narzędzia we wspólnym modelu zarządzania. Starsze materiały, nazwy ścieżek oraz istniejące wdrożenia mogą nadal używać określenia Azure AI Foundry albo Foundry classic. Przy planowaniu projektu trzeba więc sprawdzić, którego modelu zasobów dotyczy instrukcja.

Microsoft kieruje nowe inwestycje do projektów Foundry w nowym portalu. Nowszy model opiera się na zasobie Foundry i projektach, wspólnym punkcie końcowym oraz ujednoliconym zarządzaniu rolami, siecią i zasadami. Projekty oparte na dawnych hubach nadal są dostępne w portalu classic. To rozróżnienie ma znaczenie dla SDK, endpointów, ról oraz migracji.

Zmiana nazwy nie powinna skłaniać do bezrefleksyjnej migracji. Najpierw zinwentaryzuj zasoby i zależności: wdrożenia modeli, połączenia, indeksy, tożsamości, filtry treści, Application Insights, sieci prywatne i kod korzystający z konkretnych pakietów. Dopiero potem oceń korzyść z ujednoliconego modelu.

Potrzeba	Minimalny element	Czego nie dodawać na starcie
sprawdzenie jakości odpowiedzi	projekt, model i zestaw testowy	wielu agentów i rozbudowanej pamięci
odpowiedzi na dokumentach	kontrolowane źródło i retrieval	wszystkich repozytoriów firmy
wykonanie jednej czynności	agent z jednym wąskim narzędziem	ogólnego dostępu do API
pomiar działania	ewaluacja, ślady i metryki	pełnego stosu analitycznego bez odbiorcy
środowisko regulowane	tożsamość, RBAC, sieć i polityki	publicznych endpointów „na chwilę”

Projekt zaczyna się od decyzji, nie od katalogu modeli

Katalog modeli ułatwia porównanie dostawców, ale model nie definiuje sukcesu. Właściciel biznesowy powinien najpierw opisać decyzję albo zadanie, które ma się poprawić. Dla asystenta serwisowego może to być przygotowanie roboczej odpowiedzi na podstawie zatwierdzonej instrukcji. Miernikiem nie będzie wtedy ogólna „inteligencja”, lecz zgodność ze źródłem, kompletność wymaganych pól, czas odpowiedzi i liczba eskalacji.

W pierwszym tygodniu przygotuj 30–100 reprezentatywnych przypadków, zależnie od zróżnicowania procesu. Powinny obejmować typowe pytania, brak danych, konflikt źródeł, treści niedozwolone oraz sytuacje wymagające człowieka. To nie jest zbiór treningowy. To kontrakt akceptacyjny, na którym porównasz modele, prompty i kolejne wersje aplikacji.

Nie wybieraj modelu wyłącznie na podstawie publicznego rankingu. Sprawdź jakość na własnym zadaniu, dostępność w wymaganym regionie, opóźnienie, limit przepustowości, sposób rozliczenia i warunki dotyczące danych. Mały model może wystarczyć do klasyfikacji, podczas gdy trudne wydobycie informacji wymaga innego rozwiązania. Jedna aplikacja może korzystać z kilku modeli, ale dopiero po wykazaniu, że routing poprawia wynik.

Minimalna architektura ma pięć odpowiedzialności

Pierwsza odpowiedzialność to interfejs aplikacji. Przyjmuje żądanie, uwierzytelnia użytkownika i nadaje identyfikator operacji. Druga to warstwa danych, która dostarcza tylko informacje dopuszczone dla tej osoby i tego zadania. Trzecia to model lub agent wykonujący ograniczoną pracę. Czwarta to warstwa narzędzi, która sprawdza parametry i uprawnienia niezależnie od tekstu wygenerowanego przez model. Piąta to obserwowalność: ślady, metryki, ewaluacja i alarmy.

Foundry może obsłużyć kilka z tych obszarów, ale nie usuwa potrzeby ich rozdzielenia. Tożsamość użytkownika nie powinna znikać po wejściu do aplikacji. Jeśli agent pobiera dokument lub wywołuje narzędzie, warstwa wykonawcza musi znać zakres dostępu. Sam prompt „pokazuj tylko uprawnione dane” nie stanowi mechanizmu autoryzacji.

Warstwa	Pytanie kontrolne	Dowód gotowości
wejście	kto i po co uruchamia zadanie?	uwierzytelnienie i identyfikator żądania
dane	które rekordy wolno wykorzystać?	filtr uprawnień oraz rejestr źródeł
model	czy jakość wystarcza do zadania?	wynik na wersjonowanym zestawie testowym
narzędzia	jakie skutki agent może wywołać?	lista operacji, walidacja i limity
monitoring	jak wykryjesz pogorszenie?	ślady, progi, alarm i właściciel

Dane i retrieval wymagają osobnego projektu

Połączenie modelu z dokumentami nie naprawia ich jakości. Przed indeksowaniem usuń duplikaty, wskaż właściciela, datę obowiązywania i zakres dostępu. Dokument bez statusu może być archiwalną instrukcją, której model użyje z takim samym przekonaniem jak aktualnej. Metadane są więc częścią logiki biznesowej, a nie dodatkiem technicznym.

Wyszukiwanie powinno zwracać fragment, źródło i identyfikator wersji. Aplikacja musi umieć odmówić odpowiedzi, gdy nie ma wystarczającego dowodu. Oceniaj retrieval osobno od generowania: najpierw sprawdź, czy właściwy dokument znalazł się w wynikach, a dopiero potem czy model poprawnie go wykorzystał. Bez tego zespół może zmieniać prompt, gdy prawdziwym problemem jest indeks albo filtr dostępu.

Nie podłączaj na początku całego SharePointa, jeziora danych i skrzynek pocztowych. Wybierz jedną kolekcję o znanym właścicielu i jednorodnych zasadach dostępu. Dzięki temu można wyjaśnić błąd i zmierzyć pokrycie. Rozszerzenie źródeł bez takiej kontroli zwiększa pozorną wiedzę aplikacji, ale obniża możliwość udowodnienia poprawności.

Ocena jest bramką wdrożeniową

Dokumentacja obserwowalności Microsoft Foundry rozdziela ewaluację, monitoring i tracing. Ewaluatory mogą mierzyć jakość, bezpieczeństwo, ugruntowanie, trafność oraz zachowanie agentów, w tym poprawność użycia narzędzi i ukończenie zadania. Monitoring pokazuje działanie produkcyjne, a ślady pomagają odtworzyć przepływ wywołań.

Automatyczna ocena nie zastępuje kryterium biznesowego. Wskaźnik płynności nie odpowie, czy wycena jest zgodna z polityką firmy. Zbuduj więc dwa poziomy bramki. Pierwszy obejmuje miary platformowe i bezpieczeństwo. Drugi zawiera reguły dziedzinowe, na przykład obecność wymaganych pól, zgodność kwoty z tabelą albo prawidłową eskalację.

Microsoft opisuje ocenę całych rozmów, pojedynczych tur, modeli, zbiorów danych i istniejących śladów. Dla pilotażu przydatne są kontrolowane, symulowane scenariusze. Po uruchomieniu dodaj próbkę rzeczywistych interakcji, poddaną zasadom prywatności i retencji. Nie porównuj wyników z różnych zestawów bez wersjonowania danych.

Przykład syntetyczny: zestaw 80 spraw obejmuje 50 typowych, 10 bez potrzebnego dokumentu, 10 z konfliktem źródeł i 10 prób wywołania niedozwolonej czynności. Bramka wymaga poprawnego źródła w odpowiedziach typowych, odmowy lub eskalacji przy braku dowodu oraz zera wykonanych operacji niedozwolonych. Liczby ilustrują projekt testu; nie są wynikiem wdrożenia klienta.

Ślady mogą zawierać dane klientów

Dokumentacja obsługi danych śledzenia wskazuje, że ślady mogą obejmować wejścia użytkownika, odpowiedzi modeli, wywołania narzędzi, kroki pośrednie, opóźnienia, tokeny i błędy. Dane są przechowywane w połączonym Azure Monitor Application Insights. Śledzenie jest domyślnie wyłączone i zaczyna działać po świadomym połączeniu zasobu.

To oznacza, że observability ma własny model zagrożeń. Przed włączeniem ustal, które treści wolno logować, kto ma rolę czytającą, jak długo dane są przechowywane i jak obsłużyć żądanie usunięcia. Maskuj sekrety i dane, których nie potrzebujesz do diagnozy. Nie kopiuj pełnych dokumentów do śladu tylko dlatego, że biblioteka potrafi to zrobić.

Alert musi prowadzić do działania. Dla błędów technicznych właścicielem może być zespół platformowy. Dla spadku jakości potrzebny jest właściciel produktu i ekspert dziedzinowy. Dla naruszenia zasad dostępu procedura powinna natychmiast wyłączyć narzędzie lub wdrożenie. Dashboard bez osób i progów jest tylko archiwum.

Bezpieczeństwo zaczyna się od projektu zasobów

Foundry zapewnia integrację z Microsoft Entra, kontrolę dostępu opartą na rolach, izolację sieciową, filtry treści i Azure Policy. Nie włączaj wszystkich członków zespołu jako właścicieli zasobu. Oddziel role tworzenia projektu, wdrażania modelu, korzystania z endpointu, czytania telemetrii i zarządzania połączeniami.

Środowiska deweloperskie, testowe i produkcyjne powinny mieć oddzielne zasoby oraz tożsamości. Sekrety przechowuj w przeznaczonym do tego magazynie i stosuj tożsamości zarządzane, gdy są obsługiwane. Ruch sieciowy ogranicz do potrzebnych usług. Wyjątek wprowadzony podczas demonstracji ma właściciela i datę wygaśnięcia.

Agentowi nadaj mniej praw niż aplikacji, jeżeli tylko architektura to umożliwia. Narzędzie powinno wykonać walidację biznesową i techniczną przed zmianą systemu. Dla działań finansowych, prawnych albo wpływających na klienta dodaj zatwierdzenie człowieka przed skutkiem, nie po nim.

Koszt to więcej niż tokeny

Budżet obejmuje wywołania modeli, embeddingi, indeksy, przechowywanie, sieć, telemetrię i pracę zespołu. Ewaluacje oraz automatyczne testy również zużywają modele. Dokumentacja Foundry zaznacza, że niektóre ewaluacje są rozliczane według użycia. Ustaw budżet i alarmy przed szerokim testem, a nie po pierwszej fakturze.

Mierz koszt na poprawnie zakończone zadanie. Tańszy model, który częściej wymaga ponowienia albo interwencji człowieka, może być droższy w procesie. Rejestruj także opóźnienie, liczbę wywołań narzędzi, rozmiar pobranego kontekstu i czas kontroli. Dopiero ten zestaw pozwala porównać warianty.

W pilotażu ogranicz maksymalną liczbę kroków i rozmiar kontekstu. Ustal limity przepustowości oraz dzienny próg kosztu. Gdy projekt przejdzie bramkę jakości, skaluj stopniowo i obserwuj, czy wzrost ruchu nie zmienia czasu odpowiedzi albo liczby błędów.

Plan pierwszych czterech etapów

W etapie pierwszym opisz zadanie, właściciela, użytkowników, dane i miarę sukcesu. Utwórz kartę ryzyka oraz zestaw testowy. W etapie drugim skonfiguruj projekt, tożsamości, minimalny model i jedno źródło danych. Zbuduj wersję bez działań zapisujących, aby sprawdzić jakość odpowiedzi.

W etapie trzecim dodaj ewaluację, ślady z kontrolowaną zawartością i testy regresji. Porównaj co najmniej dwa warianty na tym samym zbiorze. W etapie czwartym włącz jedno wąskie narzędzie, walidację parametrów i zatwierdzenie dla skutku wysokiego ryzyka. Uruchom ograniczoną grupę użytkowników z jasną procedurą zgłaszania błędów.

Każdy etap kończy się decyzją: rozwijać, poprawić dane, zmienić model albo zatrzymać projekt. Nie zakładaj, że każda próba musi trafić na produkcję. Wartość pilotażu polega również na szybkim wykazaniu, że jakość danych albo ekonomika zadania nie uzasadnia dalszej inwestycji.

Co zrobić w poniedziałek

Zapisz jedno zdanie: „użytkownik podejmuje decyzję X na podstawie danych Y, a aplikacja ma poprawić miarę Z”. Wybierz 30 rzeczywistych, zanonimizowanych przykładów i opisz oczekiwany wynik. Następnie narysuj pięć warstw minimalnej architektury oraz przypisz właściciela każdej z nich. Dopiero wtedy utwórz zasób i porównaj modele.

Jeśli projekt wymaga najpierw uporządkowania procesów i odpowiedzialności, umieść go w szerszym planie budowy systemu firmy. Jeżeli potrzebujesz gotowych funkcji rozpoznawania dokumentów, języka, mowy lub obrazu zamiast platformy do modeli i agentów, kolejnym krokiem jest przegląd Microsoft Azure AI Services. Minimalny projekt Foundry ma udowodnić jedną wartość i jedną kontrolę. Rozbudowana platforma bez takiego dowodu tylko przenosi niejasność do chmury.

Gdy agent ma odpowiadać na podstawie wielu zatwierdzonych dokumentów, sprawdź Foundry IQ i jego bazę wiedzy. To węższa decyzja o źródłach, uprawnieniach i jakości pobierania informacji niż wybór całej platformy Foundry.

Jeśli przed utworzeniem wdrożenia chcesz rozróżnić własne modele Microsoftu do tekstu, kodu, obrazu i mowy, przeczytaj przewodnik po rodzinie MAI. Porównuje on także kanały dostępu i status preview, które trzeba sprawdzić dla wybranego regionu.