Aplikacje AI native w Microsoft Azure

Aplikacja AI native nie jest zwykłą aplikacją z dopisanym wywołaniem modelu. Jej wynik zależy od modelu, kontekstu, wyszukiwania, narzędzi i reguł procesu, a każda z tych warstw może zawieść inaczej. Dobra architektura rozdziela te odpowiedzialności, mierzy je osobno i ogranicza skutki błędu. Na Azure oznacza to świadomy dobór hostingu aplikacji, modeli w Microsoft Foundry, warstwy danych i retrieval, integracji z narzędziami oraz obserwowalności opartej na ewaluacji, logach i trace’ach.

Co oznacza AI native w praktyce

W tradycyjnej aplikacji większość zachowania jest deterministyczna: ten sam kod i dane powinny dać przewidywalny wynik. Model generatywny wprowadza probabilistyczność. Zmiana modelu, promptu, kolejności wiadomości lub kontekstu może zmienić odpowiedź bez zmiany kontraktu API. Dlatego model powinien być traktowany jako komponent, a nie jako cała architektura.

Aplikacja AI native projektuje przepływ wokół tej niepewności. Ma jawny kontrakt wejścia i wyjścia, kontroluje źródła kontekstu, sprawdza wywołania narzędzi, potrafi odmówić odpowiedzi i mierzy jakość. Wykorzystuje zdolności modelu tam, gdzie potrzebne jest rozumienie języka lub planowanie, a reguły biznesowe, autoryzację i operacje krytyczne pozostawia deterministycznym usługom.

Warstwa	Odpowiedzialność	Przykładowa technologia Azure	Główne ryzyko
interfejs i API	sesja, walidacja, streaming, uwierzytelnienie	App Service, Container Apps lub AKS	brak limitów i mieszanie stanu użytkowników
orkiestracja	prompt, stan, kolejność kroków, polityki	kod aplikacji, Microsoft Agent Framework, Foundry Agent Service	niekontrolowana pętla i koszt
model	generacja, klasyfikacja, planowanie	Foundry Models	zmienność, limity, opóźnienie
dane i retrieval	źródła, indeks, uprawnienia, cytowania	Azure AI Search, bazy i magazyny danych	zły lub niedozwolony kontekst
narzędzia	odczyt i zmiany w systemach	Functions, Logic Apps, własne API	działanie bez walidacji lub idempotencji
obserwowalność	trace, metryki, ocena jakości i kosztu	Foundry Observability, Azure Monitor, Application Insights	utrata danych wrażliwych w telemetrii

Zacznij od kontraktu produktu

Zanim wybierzesz model, opisz decyzję lub pracę użytkownika, którą aplikacja ma poprawić. Zdefiniuj dopuszczalny błąd, opóźnienie, koszt jednostkowy oraz sytuacje wymagające człowieka. Dla asystenta serwisowego kontrakt może wymagać odpowiedzi z cytatem z aktualnej instrukcji, zakazu zgadywania brakujących parametrów i eskalacji spraw bezpieczeństwa.

Ustal osobno wymagania funkcjonalne i niefunkcjonalne. Do drugiej grupy należą rezydencja danych, dostępność, limit kosztu, przepustowość, retencja oraz możliwość audytu. Azure Well-Architected Framework pomaga ocenić kompromisy między niezawodnością, bezpieczeństwem, kosztem, doskonałością operacyjną i wydajnością. AI nie unieważnia tych filarów; dodaje nowe zmienne do każdego z nich.

Model wybieraj na podstawie testu zadania

Największy model nie zawsze jest najlepszym elementem systemu. Zadania klasyfikacji, ekstrakcji i prostego formatowania mogą działać taniej i szybciej na mniejszym modelu lub gotowej usłudze. Model z większą zdolnością rozumowania może być potrzebny do planowania wieloetapowego, ale zwiększa koszt i opóźnienie.

Zbuduj zestaw ewaluacyjny z rzeczywistych klas przypadków: typowych, brzegowych, sprzecznych, niedostatecznie opisanych i wrogich. Porównaj kandydatów przy tym samym promptcie i kontekście. Mierz wynik domenowy, a nie tylko ogólną płynność. Dla ekstrakcji liczy się poprawność pól; dla asystenta wsparcia trafność diagnozy, ugruntowanie i poprawna eskalacja.

Warstwa dostępu do modelu powinna ograniczać wpływ zmiany dostawcy lub wersji na resztę aplikacji. Przechowuj konfigurację wdrożenia poza kodem biznesowym, wersjonuj prompt i schemat odpowiedzi, obsługuj limity oraz błędy przejściowe. Retry wymaga ostrożności: powtórzenie generacji kosztuje i może ponownie uruchomić narzędzie, jeżeli granice nie są rozdzielone.

Retrieval jest osobnym systemem jakości

Model nie zna automatycznie bieżących danych firmy. RAG dostarcza mu fragmenty znalezione w indeksie. Microsoft Foundry opisuje RAG jako połączenie wyszukiwania z modelami językowymi, a Azure AI Search jako rekomendowany magazyn indeksu dla scenariuszy retrieval.

Pipeline danych obejmuje pobranie dokumentu, oczyszczenie, podział, metadane, embedding, indeksowanie i aktualizację. Każdy etap wymaga właściciela oraz testu. Zbyt duże fragmenty dostarczają dużo szumu; zbyt małe gubią kontekst. Metadane powinny zawierać źródło, wersję, datę, klasyfikację i informacje potrzebne do filtrowania uprawnień.

Metryka	Co sprawdza	Typowa przyczyna słabego wyniku	Możliwa reakcja
recall właściwego fragmentu	czy dowód znalazł się w wynikach	zły chunking, embedding lub filtr	poprawić pipeline i zestaw zapytań
trafność rankingu	czy najlepsze wyniki są na górze	ogólne zapytanie lub słabe metadane	hybrid search, semantic ranker, filtrowanie
ugruntowanie odpowiedzi	czy tezy wynikają z kontekstu	prompt dopuszcza zgadywanie	jawna odmowa i kontrola cytatów
kompletność cytowań	czy twierdzenia mają referencje	utrata identyfikatorów źródeł	przenosić referencje przez cały pipeline
świeżość	czy indeks odzwierciedla źródło	brak procesu aktualizacji	zdarzenia, harmonogram i monitoring opóźnień

Klasyczny RAG ma przewidywalny przepływ: zapytanie, retrieval, złożenie kontekstu, generacja. Dla pytań wymagających kilku źródeł można rozważyć agentic RAG, w którym agent wybiera narzędzia i iteruje. Ta elastyczność ma cenę. Trzeba ograniczyć liczbę kroków, czas, budżet oraz zakres źródeł. Prosty problem nie potrzebuje pętli rozumowania.

Narzędzia oddziel od generacji

Model może zasugerować wywołanie funkcji, ale system powinien potraktować tę sugestię jak niezaufane wejście. Warstwa orkiestracji waliduje nazwę narzędzia, schemat parametrów, uprawnienia użytkownika i reguły biznesowe. Narzędzie wykonuje jedną dobrze określoną czynność i zwraca ustrukturyzowany wynik.

Odczyt stanu i zmiana stanu mają inne ryzyko. Wyszukanie statusu zamówienia może być automatyczne. Anulowanie zamówienia wymaga ponownego sprawdzenia tożsamości, aktualnego stanu i często potwierdzenia użytkownika. Operacja powinna być idempotentna albo korzystać z klucza idempotencji, aby retry nie wykonał jej dwa razy.

Nie przekazuj modelowi szerokiego tokenu technicznego, gdy można użyć tożsamości użytkownika albo usługi o ograniczonej roli. Zasada najmniejszych uprawnień obowiązuje również agentów. Rejestr audytowy powinien pokazywać, kto zainicjował czynność, co model zaproponował, co system zatwierdził i jaki był wynik, bez niepotrzebnego zapisywania danych wrażliwych.

Ewaluacja, tracing i monitoring muszą działać razem

Log HTTP pokaże błąd endpointu, ale nie wyjaśni, dlaczego odpowiedź była niepoprawna. Aplikacja AI potrzebuje śladu obejmującego wywołania modelu, retrieval, narzędzia, czasy i zużycie. Microsoft Foundry Observability łączy trzy funkcje: ewaluację jakości i bezpieczeństwa, monitoring produkcji oraz tracing oparty na OpenTelemetry i zintegrowany z Application Insights.

Nie zbieraj jednak wszystkiego bez refleksji. Trace może zawierać prompty, wejścia użytkowników, wyniki modelu i parametry narzędzi. Ustal redakcję, retencję, dostęp i region. Czasami bezpieczniej jest przechować identyfikator oraz metryki, a pełną treść tylko dla kontrolowanej próbki.

Zestaw obserwowalności powinien łączyć cztery grupy sygnałów:

1. metryki techniczne: opóźnienie, błędy, throttling, dostępność;
2. metryki wykorzystania: tokeny, wywołania narzędzi, długość pętli, cache hit;
3. metryki jakości: ugruntowanie, trafność, poprawność zadania, odmowa;
4. metryki biznesowe: zakończenie sprawy, eskalacja, korekta przez człowieka.

Średnia może ukryć problem. Analizuj wyniki według typu zadania, języka, źródła danych, wersji modelu i promptu. Alert kosztowy bez korelacji z ruchem nie powie, czy wzrost wynika z sukcesu produktu, pętli agenta czy ataku.

Przykład: asystent dla działu utrzymania

Firma buduje asystenta, który pomaga technikom diagnozować maszyny. Źródłami są instrukcje, historia zgłoszeń i dane z systemu części. Użytkownik opisuje objaw, a aplikacja ma zaproponować bezpieczne kroki oraz wskazać dokumentację.

Interfejs działa jako aplikacja webowa z tożsamością Microsoft Entra. Orkiestrator klasyfikuje zamiar, usuwa z wejścia zbędne dane i wysyła zapytanie do Azure AI Search. Indeks przechowuje fragmenty instrukcji z wersją modelu maszyny, datą i poziomem dostępu. Model otrzymuje tylko wyniki pasujące do maszyny oraz uprawnień technika. Odpowiedź zawiera cytowania i jawnie oddziela fakty ze źródła od hipotezy diagnostycznej.

Narzędzie odczytuje stan części, ale nie może samo złożyć zamówienia. Gdy technik chce wykonać operację, aplikacja pokazuje parametry, wymaga potwierdzenia i wywołuje deterministyczne API z idempotencją. Pytania dotyczące bezpieczeństwa pracy zawsze kierują do zatwierdzonej instrukcji lub człowieka.

Zespół mierzy retrieval na zestawie pytań przypisanych do właściwych fragmentów, generację na poprawności i ugruntowaniu, a cały proces na liczbie spraw rozwiązanych bez błędnej porady. Trace pozwala ustalić, czy problem powstał w indeksie, promptcie, modelu czy narzędziu. Taka separacja skraca diagnozę i umożliwia wymianę pojedynczej warstwy.

Bezpieczeństwo i odporność projektuj na awarie

Prompt injection może znaleźć się w pytaniu użytkownika albo w pobranym dokumencie. Traktuj zawartość źródeł jako dane, a nie instrukcję. Ogranicz narzędzia, waliduj wyjście i testuj próby wydobycia sekretów lub zmiany reguł. Content Safety może wspierać ochronę treści, lecz nie zastępuje autoryzacji, izolacji danych i kontroli operacji.

Zaprojektuj degradację. Gdy model jest niedostępny, aplikacja może zaoferować zwykłe wyszukiwanie. Gdy retrieval nie zwraca dowodów, powinna odmówić odpowiedzi zamiast generować z pamięci modelu. Gdy narzędzie nie odpowiada, nie wolno przedstawiać czynności jako wykonanej. Circuit breaker, timeout i ograniczona liczba retry są równie ważne jak w innych systemach rozproszonych.

Wieloregionowość modelu i danych może być ograniczona dostępnością usług oraz zasadami rezydencji. Określ RTO i RPO przed wyborem topologii. Koszt złożonego failoveru powinien wynikać z krytyczności procesu, a nie z ambicji diagramu.

Koszt kontroluj na poziomie pojedynczego zadania

Budżet miesięczny jest wskaźnikiem spóźnionym. Aplikacja powinna rejestrować koszt lub jego przybliżenie dla żądania, użytkownika, funkcji i wersji. W skład kosztu wchodzą tokeny, retrieval, embeddingi, narzędzia, hosting, telemetria i ewaluacje.

Ustal maksymalną długość kontekstu, liczbę kroków agenta i liczbę wyników retrieval. Stosuj mniejszy model do routingu lub ekstrakcji, jeśli test potwierdza jakość. Cache może ograniczać powtarzalne wywołania, ale potrzebuje klucza uwzględniającego wersję danych i uprawnienia. Oszczędność, która zwraca nieaktualny albo cudzy wynik, jest błędem bezpieczeństwa.

Ograniczenia do zaakceptowania

Nie każda funkcja powinna być agentem. Przewidywalny workflow jest łatwiejszy do testowania i audytu. RAG nie rozwiązuje problemu złych dokumentów. Ewaluator oparty na modelu też jest probabilistyczny i powinien być kalibrowany na ocenach ludzi. Tracing pomaga diagnozować, ale zwiększa zakres przetwarzanych danych.

Architektura może być technicznie poprawna i nadal nie mieć właściciela produktu, procesu korekty wiedzy albo zespołu reagującego na alerty. Produkcja wymaga modelu operacyjnego oraz decyzji o odpowiedzialności. Jeżeli aplikacja ma zmienić sposób pracy wielu działów, warto osadzić ją w systemie transformacji AI, zamiast traktować jako odizolowany eksperyment.

Test architektury i następny krok

Przeprowadź test na jednym przepływie od końca do końca. Użyj przypadków poprawnych, niepełnych, sprzecznych i wrogich. Dla każdego sprawdź: jaki kontekst pobrano, co zobaczył model, jakie narzędzie zaproponował, co zostało wykonane, ile trwało żądanie, jaki był koszt i czy trace pozwala odtworzyć decyzję bez ujawniania nadmiarowych danych.

Następnie wyłącz po kolei retrieval, model i narzędzie. System powinien zachować się zgodnie z kontraktem: odmówić, zdegradować funkcję lub eskalować, a nie udawać sukces. Dopiero po takim teście skaluj zakres. Zespół .NET może przełożyć te warstwy na konkretny stos, korzystając z przewodnika tworzenia aplikacji AI w .NET. Wynikiem przeglądu powinny być mierzalne bramki jakości, właściciele warstw i lista kontrolowanych trybów awarii.