Microsoft Azure AI Services: jak wybrać usługę

Wybór usługi AI powinien zacząć się od rodzaju wyniku, danych i ryzyka, a nie od pytania „który model jest najlepszy”. Gotowe Foundry Tools dobrze pasują do rozpoznawania mowy, dokumentów, języka lub obrazów. Microsoft Foundry jest właściwą warstwą dla aplikacji generatywnych, modeli, agentów, ewaluacji i obserwowalności. Azure Machine Learning pozostaje wyborem dla niestandardowego uczenia maszynowego. Architekt powinien najpierw opisać kontrakt zadania i ograniczenia danych, a potem wybrać najprostszą zarządzaną usługę, która ten kontrakt spełnia.

Azure AI Services, Foundry Tools i Microsoft Foundry

Nazwa Azure AI Services nadal występuje w materiałach i architekturach, ale bieżąca dokumentacja grupuje gotowe zdolności jako Foundry Tools. Są to zarządzane API i modele dla takich obszarów jak Speech, Translator, Language, Vision, Document Intelligence, Content Understanding oraz Azure AI Search.

Microsoft Foundry jest szerszą platformą do budowy aplikacji AI. Obejmuje katalog i wdrażanie modeli, pracę nad promptami i agentami, połączenia z danymi, ewaluację, tracing oraz monitoring. Nie jest zamiennikiem każdej wyspecjalizowanej usługi. Aplikacja może używać Foundry do orkiestracji modelu generatywnego, Document Intelligence do ekstrakcji pól i Azure AI Search do retrieval.

Potrzeba	Pierwszy kandydat	Dlaczego	Kiedy szukać dalej
transkrypcja i synteza mowy	Speech	gotowe API dla mowy	nietypowy język, urządzenie brzegowe lub specjalne wymagania
ekstrakcja danych z dokumentów	Document Intelligence lub Content Understanding	struktura, OCR i modele dokumentowe	własny model, gdy standardowe możliwości nie osiągają progu jakości
klasyfikacja tekstu i encje	Language	zarządzane funkcje językowe	model generatywny, gdy zadanie wymaga otwartego rozumowania
odpowiedzi na wiedzy firmy	model w Foundry + Azure AI Search	generacja połączona z kontrolowanym retrieval	agentic retrieval dla pytań wieloetapowych
niestandardowa predykcja	Azure Machine Learning	własne dane, trening i MLOps	gotowe API, jeśli wystarcza i obniża koszt utrzymania

Przewodnik wyboru technologii AI zaleca zaczynać od gotowych modeli i usług, jeżeli pokrywają wymaganie. Własny model daje większą kontrolę, ale przenosi na zespół przygotowanie danych, trening, wdrażanie, monitoring i cykl aktualizacji.

Opisz kontrakt zadania przed usługą

Kontrakt zadania powinien zawierać wejście, oczekiwane wyjście, kryterium jakości, dopuszczalne opóźnienie, wolumen, klasy danych i zachowanie przy niepewności. „Analiza faktur” jest zbyt szeroka. Precyzyjny kontrakt brzmi: plik PDF lub zdjęcie, język polski, zwrot numeru faktury, daty, NIP i pozycji w ustalonym schemacie JSON; pole o niskiej pewności trafia do weryfikacji człowieka; dokument nie może opuścić zatwierdzonego regionu.

To rozróżnienie pokazuje, że aplikacja nie potrzebuje „AI do dokumentów”, lecz mierzalnego komponentu w procesie. Można przygotować reprezentatywny zbiór testowy, zmierzyć kompletność i poprawność pól, a następnie porównać gotowy model z rozwiązaniem niestandardowym.

Wymiar	Pytanie projektowe	Przykładowy warunek akceptacji
jakość	jak mierzony jest poprawny wynik?	osobna dokładność dla pól krytycznych i pozostałych
niepewność	co dzieje się z wynikiem wątpliwym?	przekazanie do człowieka zamiast automatycznej decyzji
opóźnienie	ile może trwać odpowiedź?	tryb synchroniczny dla interakcji, batch dla archiwum
dane	gdzie mogą być przetwarzane i przechowywane?	zatwierdzony region, prywatny dostęp, retencja logów
skala	jaki jest profil ruchu?	średnia, pik, rozmiar dokumentu i limit transakcji
koszt	co tworzy jednostkę kosztu?	strona, transakcja, token, godzina obliczeń lub indeks

Kiedy wybrać gotowe Foundry Tools

Gotowa usługa jest dobrym wyborem, gdy zadanie ma wyraźną strukturę i stabilny typ wyniku. Speech zwraca transkrypcję, Translator tłumaczenie, a Document Intelligence pola i układ dokumentu. Zespół korzysta z API, nie buduje całego procesu uczenia.

To nie znaczy, że integracja jest automatycznie prosta. Trzeba sprawdzić obsługiwane języki, regiony, limity, rozmiary wejścia, tryb synchroniczny lub asynchroniczny oraz model rozliczeń. Bieżąca dokumentacja zaznacza, że poziomy cenowe różnią się liczbą transakcji na sekundę i dostępnymi funkcjami. Dostępność regionalna oraz językowa jest określana osobno dla usług.

Bezpieczeństwo również wymaga decyzji. Foundry Tools obsługują warstwy uwierzytelniania, w tym Microsoft Entra ID, klucze i sieci wirtualne. W rozwiązaniu produkcyjnym preferuj zarządzane tożsamości i role o minimalnych uprawnieniach zamiast kluczy zapisanych w konfiguracji aplikacji. Ustal, czy endpoint ma być publiczny, ograniczony regułami, czy dostępny prywatnie.

Kiedy potrzebujesz Microsoft Foundry

Microsoft Foundry jest właściwy, gdy rozwiązanie opiera się na modelu generatywnym, wymaga porównania modeli, retrieval, agentów albo spójnego procesu ewaluacji. Architekt wybiera model według jakości w zadaniu, opóźnienia, limitów, ceny, regionu i warunków wdrożenia. Ranking publiczny nie zastępuje testu na danych organizacji.

W aplikacji odpowiadającej na procedury firmy sam model nie ma aktualnej wiedzy o dokumentach. Wzorzec RAG łączy wyszukiwanie z generacją. Dokumentacja RAG w Microsoft Foundry wskazuje Azure AI Search jako rekomendowany magazyn indeksu dla tych scenariuszy. Indeks może łączyć wyszukiwanie tekstowe i wektorowe, a aplikacja przekazuje modelowi dobrany kontekst.

Dla prostego pytania do jednego indeksu klasyczny pipeline bywa wystarczający. Agentic retrieval dodaje planowanie wielu zapytań, równoległe przeszukiwanie i zwrot ustrukturyzowanych danych z referencjami. To większa elastyczność, ale też dodatkowe wywołania modelu, opóźnienie i trudniejsza diagnostyka. Nie należy wprowadzać agenta tylko dlatego, że funkcja jest dostępna.

Dane wyznaczają granice architektury

Zrób inwentaryzację przepływu danych: co użytkownik wysyła, co trafia do modelu, jakie fragmenty dokumentów dołączasz do promptu, co zapisujesz w historii, logach i trace’ach oraz kto ma do tego dostęp. Klasyfikacja danych musi objąć również treść generowaną i pośrednie wyniki narzędzi.

Wymagania rezydencji sprawdzaj dla konkretnej usługi, regionu i typu wdrożenia. Nie zakładaj, że dostępność Azure w kraju oznacza dostępność każdego modelu i każdej funkcji. Zweryfikuj także politykę przetwarzania danych w dokumentacji produktu i u własnego zespołu prawnego lub bezpieczeństwa.

Tracing jest szczególnie wrażliwy. Dokumentacja obsługi danych śledzenia wyjaśnia, że trace może zawierać wejścia użytkownika, prompty, wejścia i wyjścia modelu, wywołania narzędzi oraz metadane. Dane trafiają do połączonego systemu telemetrycznego, takiego jak Application Insights. Redakcja lub wyłączenie treści w telemetrii może być ważniejsze niż pełna wygoda debugowania.

Ewaluacja jest częścią projektu, nie odbioru

Model generatywny może zwracać płynny, lecz niepoprawny tekst. Dlatego kryterium „odpowiedź wygląda dobrze” nie nadaje się do produkcji. Przygotuj zbiór przypadków obejmujący typowe pytania, sytuacje brzegowe, brak danych, konflikty źródeł i próby wymuszenia niepożądanego działania.

Microsoft Foundry Observability łączy ewaluację, monitoring i tracing. Wbudowane ewaluatory obejmują między innymi trafność, ugruntowanie, bezpieczeństwo oraz metryki agentów, takie jak poprawność wywołań narzędzi. Potrzebne są też metryki domenowe. W procesie fakturowym najważniejsza może być bezbłędność numeru rachunku, a nie ogólna płynność odpowiedzi.

Ustal bramkę jakości w CI/CD. Zmiana modelu, promptu, chunkingu lub indeksu powinna uruchamiać ten sam zestaw testów. Produkcja dodaje inne sygnały: opóźnienie, błędy, zużycie tokenów, koszt jednostkowy, odsetek eskalacji do człowieka i jakość ocenioną na próbce rzeczywistych interakcji.

Przykład: obsługa zapytań o umowy

Firma chce przyspieszyć odpowiadanie na pytania o umowy dostawców. Dokumenty mają różne formaty, a odpowiedź musi wskazywać źródło. Proces nie powinien zaczynać się od agenta wykonującego działania.

Pierwsza warstwa używa Document Intelligence lub Content Understanding do odczytu struktury. Oczyszczone fragmenty wraz z metadanymi trafiają do Azure AI Search. Model wdrożony w Foundry generuje odpowiedź wyłącznie na podstawie zwróconego kontekstu i dołącza referencje. Aplikacja odmawia rozstrzygnięcia, gdy retrieval nie dostarczył wystarczających dowodów. Człowiek zatwierdza odpowiedzi dotyczące wypowiedzenia lub kar.

Zespół testuje oddzielnie ekstrakcję, retrieval i generację. To ważne, bo zła odpowiedź może wynikać z błędnego OCR, złego podziału dokumentu, braku właściwego fragmentu albo zachowania modelu. Jeden ogólny wskaźnik nie pokaże miejsca awarii.

Dopiero gdy pytania wymagają porównania kilku repozytoriów lub dynamicznego doboru źródeł, warto ocenić agentic retrieval. Uprawnienia do dokumentów muszą być egzekwowane podczas wyszukiwania, a nie tylko w interfejsie. Model nie może zobaczyć fragmentu, do którego użytkownik nie ma dostępu.

Zaprojektuj możliwość zmiany decyzji

Rynek modeli i nazwy produktów zmieniają się szybciej niż procesy biznesowe. Oddziel kontrakt aplikacji od konkretnego wdrożenia modelu. Konfiguracja powinna wskazywać endpoint, wersję, limity, timeout i politykę fallbacku, a kod domenowy powinien operować na stabilnym schemacie wejścia i wyjścia. Nie oznacza to abstrakcji obsługującej każdy model. Chodzi o kontrolowane miejsce zmiany i test regresji.

Wersjonuj także prompt, zestaw ewaluacyjny, ustawienia retrieval i schemat odpowiedzi. Zapis wyniku ewaluacji musi pozwalać odtworzyć, z jaką konfiguracją go uzyskano. Gdy usługa lub model zostaje wycofany, zespół może wtedy porównać następcę na tych samych przypadkach, zamiast zaczynać ocenę od opinii użytkowników po wdrożeniu.

Przed zmianą produkcyjną uruchom test porównawczy i wdrożenie canary dla małej części ruchu. Monitoruj nie tylko błędy techniczne, lecz również odmowy, eskalacje oraz korekty użytkowników. Możliwość szybkiego powrotu do poprzedniej konfiguracji jest elementem architektury, a nie procedurą dopisywaną po pierwszym incydencie.

Ograniczenia i koszty wyboru

Gotowe API ogranicza swobodę, a własny model zwiększa koszt kompetencji i utrzymania. RAG nie gwarantuje prawdziwości: błędny indeks lub nietrafne wyszukiwanie nadal dostarczą zły kontekst. Agent może wybrać niewłaściwe narzędzie. Filtry bezpieczeństwa ograniczają ryzyko, ale nie zastępują autoryzacji i kontroli procesu.

Koszt aplikacji generatywnej to nie tylko tokeny odpowiedzi. Dochodzą embeddingi, indeks, przechowywanie, wywołania narzędzi, tracing, ewaluacja oraz hosting aplikacji. Optymalizuj po pomiarach: krótszy kontekst, cache, mniejszy model dla prostych kroków i przetwarzanie batch mogą pomóc, ale każdą zmianę trzeba ponownie ocenić jakościowo.

Jeżeli organizacja nie ma właściciela danych, kryteriów jakości i procesu reagowania na błędy, sama platforma nie stworzy bezpiecznego produktu. Taki projekt warto połączyć z szerszym systemem transformacji AI, który porządkuje decyzje, odpowiedzialność i utrzymanie.

Test wyboru i następny krok

Weź 30–50 reprezentatywnych przypadków z jednego procesu. To zbiór roboczy, nie obietnica statystycznej reprezentatywności. Zapisz oczekiwany wynik i pola krytyczne. Porównaj najprostszą gotową usługę z jednym alternatywnym podejściem, mierząc jakość, opóźnienie, koszt jednostkowy i liczbę przypadków wymagających człowieka. Sprawdź scenariusz braku odpowiedzi i dane niedozwolone.

Jeśli wybór prowadzi do rozwiązania generatywnego, następnym krokiem jest zaprojektowanie całego przepływu: modelu, danych, retrieval, narzędzi, ewaluacji i telemetrii. Ten proces opisuje przewodnik jak budować aplikacje AI native w Azure. Wynikiem powinien być kontrakt architektoniczny i raport z testu, a nie lista usług wybranych na podstawie prezentacji.