Projektowanie aplikacji dla obciążeń sztucznej inteligencji na platformie Azure
Istnieje wiele opcji do rozważenia podczas tworzenia aplikacji z funkcjami sztucznej inteligencji. Unikatowe wymagania funkcjonalne i niefunkcjonalne, takie jak to, czy przypadek użycia dotyczy tradycyjnego uczenia maszynowego, generatywnego, deterministycznego czy kombinacji typów sztucznej inteligencji, pomagają zawęzić decyzje wysokiego poziomu dotyczące projektu. Te opcje należy wziąć pod uwagę podczas przechodzenia z obszarów projektowych wysokiego poziomu do obszarów projektowych niższego poziomu.
Jak opisano w artykule Wprowadzenie, jednym z pierwszych ważnych decyzji, które należy podjąć, jest to, czy utworzyć własny model, czy użyć modelu wstępnie przygotowanego. W przypadku korzystania ze wstępnie utworzonego modelu należy wziąć pod uwagę następujące kwestie:
Źródła wykazu. Zapoznaj się z repozytoriami, takimi jak Hugging Face Model Hub, TensorFlow Hub i wykaz modeli portalu Azure AI Foundry, aby znaleźć wstępnie wytrenowane modele. Te platformy udostępniają obszerny wykaz modeli dla różnych zadań.
Licencjonowanie. Upewnij się, że postanowienia licencyjne modelu pasują do celów dotyczących zabezpieczeń, zgodności i aplikacji, zwłaszcza jeśli planujesz dystrybucję aplikacji lub integrujesz ją z innymi usługami.
Kluczowe składniki. Zapoznaj się z architekturą modelu, danymi treningowym, wydajnością i licencjonowaniem, aby określić, czy jest on dostosowany do danego zadania lub domeny.
Aby uzyskać wskazówki dotyczące wybierania platformy hostingu, zobacz Considerations for the model hosting and inferencing platform.
W tym artykule opisano typowe obszary projektowe i czynniki, które należy wziąć pod uwagę podczas podejmowania decyzji dotyczących technologii i podejścia.
Zalecenia
Poniższa tabela zawiera podsumowanie zaleceń przedstawionych w tym artykule.
| Zalecenie | opis |
|---|---|
| Określanie priorytetów rozwiązań poza półki. | Za każdym razem, gdy jest to praktyczne, użyj rozwiązań platformy jako usługi (PaaS), aby obsługiwać funkcje obciążeń. Używaj wstępnie utworzonych i wstępnie wytrenowanych modeli, jeśli to możliwe, aby zminimalizować obciążenie operacyjne i programistyczne dla zespołów roboczych i operacyjnych. |
| Funkcje abstrakcyjne i możliwości z dala od klienta. | Należy zachować jak najcieńszy klient, projektując usługi zaplecza, aby obsługiwać problemy przekrojowe, takie jak ograniczanie szybkości i operacje failover. |
| Blokuj dostęp do magazynów danych. | Kod w systemie sztucznej inteligencji nie powinien uzyskiwać bezpośredniego dostępu do magazynów danych. Kierowanie wszystkich żądań danych za pośrednictwem warstwy interfejsu API. Interfejsy API powinny być tworzone specjalnie dla wymaganego zadania. |
| Izolowanie modeli. | Podobnie jak w przypadku magazynów danych, użyj warstwy interfejsu API do działania jako bramy dla żądań do modelu. Niektóre rozwiązania PaaS, takie jak Azure OpenAI Service i Azure Machine Learning, używają w tym celu zestawów SDK. Wiele narzędzi, takich jak przepływ monitów, zawiera natywną obsługę propagacji interfejsów API do usługi. |
| Projektowanie składników do niezależnego wdrażania. | Modele sztucznej inteligencji, potoki danych, składniki frontonu i mikrousługi, takie jak wstępne przetwarzanie danych, wyodrębnianie funkcji i wnioskowanie, powinny być wdrażane niezależnie, aby zoptymalizować elastyczność, skalowalność i możliwości działania obciążenia. |
Konteneryzowanie składników
Aby upewnić się, że niezależnie wdrażane składniki są w pełni samodzielne i usprawnić wdrożenia, rozważ konteneryzację w ramach strategii projektowania. Następujące składniki powinny być konteneryzowane:
mikrousługi. Poszczególne mikrousługi obsługujące określone funkcje aplikacji, takie jak przetwarzanie danych, wnioskowanie modelu i uwierzytelnianie użytkowników, powinny być konteneryzowane. Takie podejście umożliwia niezależne wdrażanie i skalowanie oraz ułatwia wydajniejsze aktualizacje i konserwację.
modele sztucznej inteligencji. Konteneryzowanie modeli sztucznej inteligencji w celu zapewnienia, że wszystkie zależności, biblioteki i konfiguracje są połączone razem. Takie podejście izoluje środowisko modelu od systemu hosta, aby zapobiec konfliktom wersji i zapewnić spójne zachowanie w różnych środowiskach wdrażania.
przepływy przetwarzania danych. Wszystkie zadania przetwarzania danych poprzedzające lub zgodne z wnioskowaniem modelu, takie jak czyszczenie danych, przekształcanie i wyodrębnianie funkcji, powinny być konteneryzowane. Takie podejście zwiększa powtarzalność i upraszcza zarządzanie zależnościami.
usługi infrastruktury . Usługi, które zapewniają obsługę infrastruktury, takie jak bazy danych i warstwy buforowania, mogą również korzystać z konteneryzacji. Konteneryzowanie tych usług pomaga zachować spójność wersji i ułatwia skalowanie tych składników i zarządzanie nimi.
Kolokowanie składników sztucznej inteligencji z innymi składnikami obciążenia
Istnieje kilka dobrych powodów, aby umieścić składniki sztucznej inteligencji wspólnie z innymi składnikami obciążenia, ale istnieją związane z tym kompromisy do rozważenia. Z następujących powodów możesz wybrać kolokację składników:
czułość opóźnienia. Umieszczanie składników sztucznej inteligencji wraz z innymi usługami, takimi jak hosting interfejsu API, gdy ważne jest niskie opóźnienie. Jeśli na przykład potrzebujesz wnioskowania w czasie rzeczywistym w celu ulepszenia środowiska użytkownika, umieszczenie modeli sztucznej inteligencji w pobliżu interfejsu API może zminimalizować czas potrzebny na pobranie wyników.
Bliskość danych. Gdy modele sztucznej inteligencji wymagają częstego dostępu do określonych zestawów danych, takich jak indeks wyszukiwania, przeniesienie tych składników może zwiększyć wydajność i zmniejszyć nakład pracy związany z transferem danych w celu przyspieszenia przetwarzania i wnioskowania.
użycie zasobów. Jeśli określone składniki mają komplementarne potrzeby dotyczące zasobów, takie jak CPU i pamięć, ich współlokacja może zoptymalizować użycie zasobów. Na przykład model, który wymaga znacznego obliczenia, może współdzielić zasoby z usługą, która jednocześnie ma mniejsze wymagania.
kompromis do rozważenia. Istnieją kompromisy do rozważenia, które należy wziąć pod uwagę podczas decydowania, czy komponenty mają być współlokalizowane. Możesz utracić możliwość niezależnego wdrażania lub skalowania składników. Możesz również zwiększyć ryzyko awarii, zwiększając potencjalny zakres oddziaływania zdarzeń.
Ocena użycia orkiestratorów w rozwiązaniach generacyjnych sztucznej inteligencji
Orkiestrator zarządza przepływem pracy, koordynując komunikację między różnymi składnikami rozwiązania sztucznej inteligencji, które w przeciwnym razie byłyby trudne do zarządzania w złożonych obciążeniach. Zalecamy utworzenie orkiestratora w projekcie, jeśli obciążenie ma dowolną z następujących cech:
złożone przepływy pracy. Przepływ pracy obejmuje wiele kroków, takich jak przetwarzanie wstępne, łączenie modeli lub postprocesowanie.
Logika warunkowa. Decyzje, takie jak kierowanie wyników do różnych modeli, muszą być podejmowane dynamicznie na podstawie danych wyjściowych modelu.
skalowanie i zarządzanie zasobami. Należy zarządzać alokacją zasobów dla aplikacji o dużej ilości przy użyciu skalowania modelu opartego na zapotrzebowaniu.
zarządzanie stanem. Musisz zarządzać stanem i pamięcią interakcji użytkownika.
Odzyskiwanie danych. Musisz mieć możliwość pobierania danych rozszerzonych z indeksu.
Zagadnienia dotyczące korzystania z wielu modeli
Gdy obciążenie korzysta z wielu modeli, narzędzie do orkiestracji jest niezbędne. Orkiestrator kieruje dane i żądania do odpowiedniego modelu na podstawie przypadku użycia. Zaplanuj przepływ danych między modelami, zapewniając, że dane wyjściowe z jednego modelu mogą służyć jako dane wejściowe dla innego. Planowanie może obejmować transformację danych lub procesy wzbogacania.
Orkiestracja i agenci
W przypadku obciążeń generowania sztucznej inteligencji rozważ użycie opartego na agencie, czasami nazywanego agentem, podejścia do projektu w celu dodania rozszerzalności do aranżacji. Agenci zapewniają funkcjonalność zależną od kontekstu. Mają one wiele cech mikrousług i wykonują zadania w połączeniu z orkiestratorem. Orkiestrator może ogłaszać zadania do puli agentów, lub agenci mogą rejestrować możliwości u orkiestratora. Obie metody umożliwiają orkiestratorowi dynamiczne określenie sposobu podziału i kierowania zapytania między agentami.
Podejścia agentowe są idealne, gdy masz wspólną warstwę interfejsu użytkownika, która ma wiele rozwijających się funkcji, które można włączyć do doświadczenia, aby z czasem dodać więcej umiejętności i zintegrować dane z przepływem.
W przypadku złożonych obciążeń, które mają wielu agentów, wydajniejsze jest umożliwienie agentom dynamicznej współpracy zamiast używania orkiestratora do dzielenia zadań i przypisywania ich.
Komunikacja między koordynatorem a agentami powinna być zgodna ze wzorcem kolejki tematu, w którym agenci są subskrybentami tematu, a orkiestrator wysyła zadania za pośrednictwem kolejki.
Użycie podejścia agentowego działa najlepiej ze wzorcem aranżacji, a nie wzorcem choreografii.
Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące platformy aranżacji.
Ocena użycia bram interfejsu API
Bramki API, takie jak Azure API Management, abstrahują funkcje od samych API, co oddziela zależności między usługą żądającą a interfejsem API. Bramy interfejsu API zapewniają następujące korzyści dla obciążeń sztucznej inteligencji:
wiele mikrousług. Bramy ułatwiają zarządzanie wieloma punktami końcowymi modelu sztucznej inteligencji, gdy trzeba wymusić spójne zasady, takie jak ograniczanie szybkości i uwierzytelnianie.
zarządzanie ruchem. Bramy ułatwiają efektywne zarządzanie aplikacjami o dużym natężeniu ruchu dzięki zarządzaniu żądaniami, buforowaniem odpowiedzi i dystrybucją obciążeń.
Security. Bramy zapewniają scentralizowaną kontrolę dostępu, rejestrowanie i ochronę przed zagrożeniami dla interfejsów API za bramą.
Korzystanie ze wzorców projektowych aplikacji sztucznej inteligencji
W branży wprowadzono kilka typowych wzorców projektowych dla aplikacji sztucznej inteligencji. Można ich użyć, aby uprościć projektowanie i implementację. Te wzorce projektowe obejmują:
Łączenie modeli. Ten wzorzec projektu obejmuje łączenie przewidywań z wielu modeli w celu zwiększenia dokładności i niezawodności dzięki łagodzeniu słabych stron poszczególnych modeli.
Architektura mikrousług. Rozdzielenie składników na niezależnie wdrażane usługi zwiększa skalowalność i łatwość konserwacji. Umożliwia zespołom pracę nad różnymi częściami aplikacji jednocześnie.
architektura oparta na zdarzeniach . Używanie zdarzeń do wyzwalania akcji umożliwia oddzielenie składników i przetwarzania w czasie rzeczywistym, aby system był bardziej dynamiczny i dostosowywany do zmieniających się danych.
Wzorce RAG i strategie fragmentowania
Wzorzec generacji Retrieval-Augmented (RAG) łączy modele generowania z systemami pobierania, co umożliwia modelowi uzyskiwanie dostępu do zewnętrznych źródeł wiedzy w celu uzyskania lepszego kontekstu i dokładności. Zapoznaj się z serią artykułów "Projektowanie i opracowywanie rozwiązania RAG", aby uzyskać szczegółowe wskazówki dotyczące tego wzorca. Istnieją dwa podejścia RAG:
dokładnie na czas. Takie podejście pobiera istotne informacje dynamicznie w momencie żądania, aby zapewnić, że najnowsze dane są zawsze używane. Jest to korzystne w scenariuszach wymagających kontekstu w czasie rzeczywistym, ale może to spowodować opóźnienie.
wstępnie obliczone (keszowane). Ta metoda obejmuje buforowanie wyników pobierania w celu zmniejszenia czasów odpowiedzi przez obsługę wstępnie obliczonych danych. Jest odpowiednia dla scenariuszy wysokiego zapotrzebowania, w których można przechowywać spójne dane. Dane mogą nie odzwierciedlać najnowszych informacji, co może prowadzić do problemów związanych z istotnością.
W przypadku korzystania ze wzorca RAG dobrze zdefiniowana strategia fragmentowania ma kluczowe znaczenie dla optymalizacji wydajności obciążenia. Zacznij od wskazówek dostępnych w serii Projektowanie i rozwój rozwiązania RAG. Poniżej przedstawiono kilka dodatkowych zaleceń, które należy wziąć pod uwagę:
Zaimplementuj dynamiczną strategię fragmentowania, która dostosowuje rozmiary fragmentów na podstawie typu danych, złożoności zapytań i wymagań użytkownika. Może to zwiększyć wydajność pobierania i zachowywanie kontekstu.
Uwzględnij pętle opinii w celu uściślinia strategii fragmentowania na podstawie danych wydajności.
Zachowaj pochodzenie danych dla fragmentów, zachowując metadane i unikatowe identyfikatory, które łączą się z źródłem uziemienia. Jasna dokumentacja pochodzenia pomaga zapewnić użytkownikom zrozumienie źródła danych, przekształceń danych oraz ich wkładu w dane wyjściowe.
Kiedy należy używać wzorców projektowych
Rozważ użycie tych wzorców projektowych, gdy przypadek użycia spełnia opisany warunek:
złożone przepływy pracy. Jeśli masz złożone przepływy pracy lub interakcje między wieloma modelami sztucznej inteligencji, wzorce, takie jak RAG lub mikrousługi, mogą pomóc w zarządzaniu złożonością i zapewnić wyraźną komunikację między składnikami.
wymagania dotyczące skalowalności. Jeśli zapotrzebowanie na aplikację ulega zmianie, wzorzec, taki jak mikrousługi, umożliwia niezależne skalowanie poszczególnych składników w celu uwzględnienia różnych obciążeń bez wpływu na ogólną wydajność systemu.
aplikacje oparte na danych. Jeśli aplikacja wymaga rozbudowanej obsługi danych, architektura sterowana zdarzeniami może zapewnić czas odpowiedzi w czasie rzeczywistym i wydajne przetwarzanie danych.
Uwaga
Mniejsze aplikacje lub weryfikacje koncepcji zwykle nie korzystają z tych wzorców projektowych. Te aplikacje powinny być zaprojektowane dla uproszczenia. Podobnie, jeśli masz ograniczenia zasobów (budżet, czas lub zatrudnienie), używając prostego projektu, który można refaktoryzować później, jest lepszym podejściem niż przyjęcie złożonego wzorca projektowego.
Wybieranie odpowiednich struktur i bibliotek
Wybór struktur i bibliotek jest ściśle powiązany z projektowaniem aplikacji. Wpływają one na wydajność, skalowalność i łatwość konserwacji. Jednak wymagania projektowe mogą ograniczać możliwości wyboru platformy. Na przykład użycie zestawu SDK jądra semantycznego często zachęca do projektowania opartego na mikrousługach, w którym każdy agent lub funkcja jest hermetyzowana w ramach własnej usługi. Podczas wybierania struktur i bibliotek należy wziąć pod uwagę następujące czynniki:
Wymagania dotyczące aplikacji. Wymagania aplikacji, takie jak przetwarzanie w czasie rzeczywistym lub przetwarzanie wsadowe, mogą ograniczać wybór platformy. Jeśli na przykład aplikacja wymaga małych opóźnień, może być konieczne użycie struktury, która ma możliwości asynchroniczne.
Integracja wymaga. Projekt może wymagać określonych integracji z innymi systemami lub usługami. Jeśli platforma nie obsługuje niezbędnych protokołów lub formatów danych, może być konieczne ponowne rozważenie projektu lub wybranie innej platformy.
Doświadczenie zespołu. Zestaw umiejętności zespołu deweloperów może ograniczyć wybór struktury. Projekt, który opiera się na mniej znanej strukturze, może prowadzić do zwiększenia czasu programowania i złożoności, więc warto użyć bardziej znanego narzędzia.
Projektowanie strategii tożsamości, autoryzacji i dostępu
Ogólnie rzecz biorąc, należy podejść do tożsamości, autoryzacji i dostępu w taki sam sposób, jak w przypadku normalnego projektowania aplikacji. Aby zarządzać tymi obszarami, jak najwięcej, należy użyć dostawcy tożsamości, takiego jak Microsoft Entra ID. Jednak wiele aplikacji sztucznej inteligencji ma unikatowe wyzwania, które wymagają szczególnej uwagi. Czasami jest to trudne, a nawet niemożliwe do utrwalania list kontroli dostępu (ACL) za pośrednictwem systemu bez nowego programowania.
Zobacz Guide to design a secure multitenant RAG inferencing solution to learn how to add security-trimming metadata to documents and chunks (Przewodnik po projektowaniu bezpiecznego wielodostępnego rozwiązania wnioskowania RAG), aby dowiedzieć się, jak dodawać metadane przycinania zabezpieczeń do dokumentów i fragmentów. To przycinanie może być oparte na grupach zabezpieczeń lub podobnych konstrukcjach organizacyjnych.
Weź pod uwagę wymagania niefunkcjonalne
Obciążenie może mieć niefunkcjonalne wymagania, które stanowią wyzwania ze względu na czynniki związane z technologiami sztucznej inteligencji. Poniżej przedstawiono niektóre typowe wymagania niefunkcjonalne i ich wyzwania:
Opóźnienie w wnioskowaniu przez model i przekroczenia limitu czasu. Aplikacje sztucznej inteligencji często wymagają odpowiedzi w czasie rzeczywistym lub niemal w czasie rzeczywistym. Projektowanie pod kątem małych opóźnień ma kluczowe znaczenie. Obejmuje ona optymalizację architektury modelu, potoków przetwarzania danych i zasobów sprzętowych. Zaimplementowanie strategii buforowania i zapewnienie wydajnego ładowania modelu jest również niezbędne, aby uniknąć przekroczenia limitu czasu i zapewnić terminowe odpowiedzi.
ograniczenia przepływności tokenu lub żądania. Wiele usług sztucznej inteligencji nakłada limity na liczbę tokenów lub przepływność żądań, szczególnie w przypadku modeli opartych na chmurze. Projektowanie pod kątem tych ograniczeń wymaga starannego zarządzania rozmiarami danych wejściowych, przetwarzania wsadowego żądań w razie potrzeby oraz potencjalnie implementowania mechanizmów ograniczania szybkości lub kolejkowania w celu zarządzania oczekiwaniami użytkowników i zapobiegania przerwom w działaniu usług.
scenariusze kosztów i refakturacji. Projektowanie pod kątem przejrzystości kosztów obejmuje implementowanie funkcji śledzenia użycia i raportowania, które ułatwiają modele obciążeń zwrotnych. Te funkcje umożliwiają organizacjom dokładne przydzielanie kosztów między działami. Zarządzanie obciążeniami zwrotnymi jest zwykle obsługiwane przez bramę interfejsu API, na przykład Azure API Management.