Aplikacje do czatów dla przedsiębiorstw mogą umożliwiać pracownikom interakcję konwersacyjną. Jest to szczególnie istotne ze względu na ciągły postęp modeli językowych, takich jak modele GPT openAI i modele LLaMA meta. Te aplikacje do czatu składają się z interfejsu użytkownika czatu, repozytoriów danych zawierających informacje specyficzne dla domeny istotne dla zapytań użytkownika, modeli językowych, które są przyczyną danych specyficznych dla domeny w celu wygenerowania odpowiedniej odpowiedzi, oraz orkiestratora, który nadzoruje interakcję między tymi składnikami.
Ten artykuł zawiera architekturę bazową służącą do tworzenia i wdrażania aplikacji do czatów dla przedsiębiorstw korzystających z modeli językowych usługi Azure OpenAI Service. Architektura wykorzystuje przepływ monitów, aby utworzyć przepływy wykonywalne. Te przepływy wykonywalne organizuje przepływ pracy z przychodzących monitów do magazynów danych w celu pobrania danych uziemowych dla modeli językowych, a także innych wymaganych logiki języka Python. Przepływ wykonywalny jest wdrażany w zarządzanym punkcie końcowym online z zarządzanymi obliczeniami.
Hosting niestandardowego interfejsu użytkownika czatu jest zgodny ze wskazówkami dotyczącymi podstawowej aplikacji internetowej usług App Services dotyczącymi wdrażania bezpiecznej, strefowo nadmiarowej i wysokiej dostępności aplikacji internetowej w usłudze aplikacja systemu Azure Service. W tej architekturze usługa App Service komunikuje się z rozwiązaniem platformy Azure jako usługa (PaaS) za pośrednictwem integracji sieci wirtualnej za pośrednictwem prywatnych punktów końcowych. Usługa App Service interfejsu użytkownika czatu komunikuje się z zarządzanym punktem końcowym online dla przepływu za pośrednictwem prywatnego punktu końcowego. Dostęp publiczny do usługi Azure AI Studio jest wyłączony.
Ważne
W tym artykule nie omówiono składników ani decyzji dotyczących architektury z podstawowej aplikacji internetowej usługi App Service. Przeczytaj ten artykuł, aby uzyskać wskazówki dotyczące architektury dotyczące hostowania interfejsu użytkownika czatu.
Centrum azure AI Studio jest skonfigurowane z zarządzaną izolacją sieci wirtualnej, która wymaga zatwierdzenia wszystkich połączeń wychodzących. Dzięki tej konfiguracji tworzona jest zarządzana sieć wirtualna wraz z zarządzanymi prywatnymi punktami końcowymi, które umożliwiają łączność z zasobami prywatnymi, takimi jak miejsce pracy Azure Storage, Azure Container Registry i Azure OpenAI. Te połączenia prywatne są używane podczas tworzenia i testowania przepływu oraz przepływów wdrożonych w obliczeniach usługi Machine Learning.
Centrum to zasób usługi Azure AI Studio najwyższego poziomu, który zapewnia centralny sposób zarządzania zabezpieczeniami, łącznością i innymi problemami w wielu projektach. Ta architektura wymaga tylko jednego projektu dla obciążenia. Jeśli masz dodatkowe środowiska wymagające różnych przepływów monitów z inną logiką, potencjalnie przy użyciu różnych zasobów zaplecza, takich jak magazyny danych, możesz rozważyć zaimplementowanie tych w innym projekcie.
Napiwek
Ten artykuł jest wspierany przez implementację referencyjną, która prezentuje kompleksową implementację czatu na platformie Azure według planu bazowego. Możesz użyć tej implementacji jako podstawy do tworzenia niestandardowych rozwiązań w pierwszym kroku w kierunku produkcji.
Architektura
Pobierz plik programu Visio z tą architekturą.
Składniki
Wiele składników tej architektury jest takich samych jak podstawowa kompleksowa architektura czatu w usłudze Azure OpenAI. Poniższa lista zawiera tylko zmiany w podstawowej architekturze.
- Usługa Azure OpenAI jest używana zarówno w architekturze podstawowej, jak i w tej architekturze bazowej. Azure OpenAI to w pełni zarządzana usługa, która zapewnia dostęp interfejsu API REST do modeli językowych usługi Azure OpenAI, w tym zestawu modeli GPT-4, GPT-3.5-Turbo i osadzania zestawu modeli. Architektura bazowa korzysta z funkcji przedsiębiorstwa, takich jak sieć wirtualna i link prywatny, których podstawowa architektura nie implementuje.
- Azure AI Studio to platforma, za pomocą której można tworzyć, testować i wdrażać rozwiązania sztucznej inteligencji. Program AI Studio jest używany w tej architekturze do kompilowania, testowania i wdrażania logiki orkiestracji przepływu monitów dla aplikacji czatu. W tej architekturze usługa Azure AI Studio zapewnia zarządzaną sieć wirtualną na potrzeby zabezpieczeń sieci. Aby uzyskać więcej informacji, zobacz sekcję dotyczącą sieci, aby uzyskać więcej informacji.
- Usługa Application Gateway to moduł równoważenia obciążenia warstwy 7 (HTTP/S) i router ruchu internetowego. Używa routingu opartego na ścieżkach URL w celu dystrybucji ruchu przychodzącego między strefami dostępności i odciąża szyfrowanie w celu zwiększenia wydajności aplikacji.
- Zapora aplikacji internetowej (WAF) to natywna dla chmury usługa, która chroni aplikacje internetowe przed typowymi programami wykorzystującymi luki, takie jak wstrzyknięcie kodu SQL i wykonywanie skryptów między witrynami. Zapora aplikacji internetowej zapewnia wgląd w ruch do i z aplikacji internetowej, umożliwiając monitorowanie i zabezpieczanie aplikacji.
- Azure Key Vault to usługa, która bezpiecznie przechowuje wpisy tajne, klucze szyfrowania i certyfikaty oraz zarządza nimi. Centralizuje zarządzanie poufnymi informacjami.
- Sieć wirtualna platformy Azure to usługa, która umożliwia tworzenie izolowanych i bezpiecznych prywatnych sieci wirtualnych na platformie Azure. W przypadku aplikacji internetowej w usłudze App Service potrzebna jest podsieć sieci wirtualnej do korzystania z prywatnych punktów końcowych na potrzeby bezpiecznej komunikacji między zasobami.
- Usługa Private Link umożliwia klientom uzyskiwanie dostępu do usług Platformy jako usługi (PaaS) platformy Azure bezpośrednio z prywatnych sieci wirtualnych bez korzystania z publicznego adresowania IP.
- Azure DNS to usługa hostingu dla domen DNS, która zapewnia rozpoznawanie nazw przy użyciu infrastruktury platformy Microsoft Azure. Prywatna strefa DNS strefy umożliwiają mapowanie w pełni kwalifikowanej nazwy domeny (FQDN) usługi na adres IP prywatnego punktu końcowego.
Alternatywy
Ta architektura ma wiele składników, które mogą być obsługiwane przez inne usługi platformy Azure, które mogą lepiej dopasować się do wymagań funkcjonalnych i niefunkcjonalnych obciążenia. Oto kilka takich alternatyw, o których należy pamiętać.
Obszary robocze usługi Azure Machine Learning (i środowiska portalu)
Ta architektura używa programu Azure AI Studio do kompilowania, testowania i wdrażania przepływów monitów. Alternatywnie można użyć obszarów roboczych usługi Azure Machine Learning, ponieważ obie usługi mają nakładające się funkcje. Chociaż usługa AI Studio jest dobrym wyborem, jeśli projektujesz rozwiązanie przepływu monitów, istnieją pewne funkcje, dla których obecnie usługa Azure Machine Learning ma lepszą obsługę. Aby uzyskać więcej informacji, zobacz porównanie funkcji. Zalecamy, aby nie mieszać i dopasowywać usług Azure AI Studio i Azure Machine Learning. Jeśli możesz wykonać pracę całkowicie w programie AI Studio, użyj programu AI Studio. Jeśli nadal potrzebujesz funkcji z usługi Azure Machine Learning Studio, kontynuuj korzystanie z usługi Azure Machine Learning Studio.
Składniki warstwy aplikacji
Istnieje kilka ofert usług zarządzanych aplikacji dostępnych na platformie Azure, które mogą służyć jako warstwa aplikacji dla frontonu interfejsu użytkownika czatu. Zobacz Wybieranie usługi obliczeniowej platformy Azure dla wszystkich obliczeń i Wybieranie usługi kontenera platformy Azure dla rozwiązań kontenerów. Na przykład podczas wybierania usługi Azure Web Apps i Web App for Containers dla interfejsu API czatu i hosta przepływu monitu można uzyskać podobne wyniki za pomocą usługi Azure Kubernetes Service (AKS) lub usługi Azure Container Apps. Wybierz platformę aplikacji obciążenia na podstawie specyficznych wymagań funkcjonalnych i niefunkcjonalnych obciążenia.
Hosting przepływu monitów
Wdrażanie przepływów monitów nie jest ograniczone do klastrów obliczeniowych usługi Machine Learning, a ta architektura ilustruje tę alternatywę w usłudze aplikacja systemu Azure Service. Przepływy są ostatecznie konteneryzowaną aplikacją można wdrożyć w dowolnej usłudze platformy Azure zgodnej z kontenerami. Te opcje obejmują usługi, takie jak Azure Kubernetes Service (AKS), Azure Container Apps i aplikacja systemu Azure Service. Wybierz usługę kontenera platformy Azure na podstawie wymagań warstwy aranżacji.
Przykładem tego, dlaczego hosting przepływu monitów hostowania alternatywnych zasobów obliczeniowych jest omówiony w dalszej części tego artykułu.
Magazyn danych uziemienia
Chociaż ta architektura prowadzi do usługi Azure AI Search, wybór magazynu danych dla danych uziemieniowych jest decyzją architektury specyficzną dla obciążenia. Wiele obciążeń jest w rzeczywistości wielolotem i ma różne źródła i technologie na potrzeby uziemienia danych. Te platformy danych wahają się od istniejących magazynów danych OLTP, natywnych baz danych w chmurze, takich jak Usługa Azure Cosmos DB, za pośrednictwem wyspecjalizowanych rozwiązań, takich jak usługa Azure AI Search. Typową, ale nie wymaganą cechą takiego magazynu danych jest wyszukiwanie wektorów. Zobacz Wybieranie usługi platformy Azure pod kątem wyszukiwania wektorów, aby eksplorować opcje w tym obszarze.
Zagadnienia i zalecenia
Niezawodność
Niezawodność zapewnia, że aplikacja może spełnić zobowiązania podjęte przez klientów. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca niezawodności.
Podstawowa architektura aplikacji internetowej usługi App Service koncentruje się na nadmiarowości strefowej dla kluczowych usług regionalnych. Strefy dostępności są fizycznie oddzielone lokalizacjami w obrębie regionu. Zapewniają one nadmiarowość w regionie na potrzeby obsługi usług, gdy w nich wdrożono co najmniej dwa wystąpienia. W przypadku przestoju w jednej strefie inne strefy w regionie mogą nadal nie mieć wpływu. Architektura zapewnia również wystarczającą liczbę wystąpień usług platformy Azure i konfigurację tych usług do rozpowszechniania w różnych strefach dostępności. Aby uzyskać więcej informacji, zobacz punkt odniesienia , aby przejrzeć te wskazówki.
Ta sekcja dotyczy niezawodności z perspektywy składników tej architektury, które nie są uwzględnione w punkcie odniesienia usługi App Service, w tym usługi Machine Learning, Azure OpenAI i AI Search.
Nadmiarowość strefowa dla wdrożeń przepływu
Wdrożenia w przedsiębiorstwie zwykle wymagają nadmiarowości strefowej. Aby uzyskać nadmiarowość strefowa na platformie Azure, zasoby muszą obsługiwać strefy dostępności i należy wdrożyć co najmniej trzy wystąpienia zasobu lub włączyć obsługę platformy, gdy kontrola wystąpienia nie jest dostępna. Obecnie środowisko obliczeniowe usługi Machine Learning nie oferuje obsługi stref dostępności. Aby wyeliminować potencjalny wpływ katastrofy na poziomie centrum danych w składnikach usługi Machine Learning, należy ustanowić klastry w różnych regionach wraz z wdrożeniem modułu równoważenia obciążenia w celu dystrybucji wywołań między tymi klastrami. Możesz użyć kontroli kondycji, aby upewnić się, że wywołania są kierowane tylko do klastrów, które działają prawidłowo.
Istnieją pewne alternatywy dla klastrów obliczeniowych usługi Machine Learning, takich jak Azure Kubernetes Service (AKS), Azure Functions, Azure Container Apps i aplikacja systemu Azure Service. Każda z tych usług obsługuje strefy dostępności. Aby uzyskać nadmiarowość strefową na potrzeby wykonywania przepływu monitów, bez dodatkowej złożoności wdrożenia w wielu regionach należy wdrożyć przepływy w jednej z tych usług.
Na poniższym diagramie przedstawiono alternatywną architekturę, w której przepływy monitów są wdrażane w usłudze App Service. Usługa App Service jest używana w tej architekturze, ponieważ obciążenie korzysta już z niego dla interfejsu użytkownika czatu i nie skorzystałoby z wprowadzenia nowej technologii do obciążenia. Zespoły obciążeń, które mają doświadczenie z usługą AKS, powinny rozważyć wdrożenie w tym środowisku, zwłaszcza jeśli usługa AKS jest używana dla innych składników obciążenia.
Diagram jest numerowany dla istotnych obszarów w tej architekturze:
Przepływy są nadal tworzone w przepływie monitów, a architektura sieci pozostaje niezmieniona. Autorzy usługi Flow nadal łączą się ze środowiskiem tworzenia w projekcie AI Studio za pośrednictwem prywatnego punktu końcowego, a zarządzane prywatne punkty końcowe są używane do łączenia się z usługami platformy Azure podczas testowania przepływów.
Ten kropkowany wiersz wskazuje, że konteneryzowane przepływy wykonywalne są wypychane do usługi Container Registry. Na diagramie nie pokazano potoków, które konteneryzują przepływy i wypychają do usługi Container Registry. Obliczenia, w których działają te potoki, muszą mieć dostęp do zasobów sieciowych, takich jak rejestr kontenerów platformy Azure i projekt AI Studio.
W tym samym planie usługi App Service wdrożono inną aplikację internetową, która już hostuje interfejs użytkownika czatu. Nowa aplikacja internetowa hostuje konteneryzowany przepływ monitów, colocated w tym samym planie usługi App Service, który działa już co najmniej trzy wystąpienia, rozłożone na strefy dostępności. Te wystąpienia usługi App Service łączą się z usługą Container Registry za pośrednictwem prywatnego punktu końcowego podczas ładowania obrazu kontenera przepływu monitu.
Kontener przepływu monitów musi nawiązać połączenie ze wszystkimi usługami zależnym na potrzeby wykonywania przepływu. W tej architekturze kontener przepływu monitów łączy się z usługą AI Search i Azure OpenAI. Usługi PaaS, które zostały uwidocznione tylko w podsieci prywatnego punktu końcowego usługi Machine Learning, muszą być teraz widoczne w sieci wirtualnej, aby można było ustanowić linię wzroku z usługi App Service.
Azure OpenAI — niezawodność
Usługa Azure OpenAI obecnie nie obsługuje stref dostępności. Aby zminimalizować potencjalny wpływ katastrofy na poziomie centrum danych na wdrożenia modelu w usłudze Azure OpenAI, należy wdrożyć usługę Azure OpenAI w różnych regionach wraz z wdrożeniem modułu równoważenia obciążenia w celu dystrybucji wywołań między regionami. Możesz użyć kontroli kondycji, aby upewnić się, że wywołania są kierowane tylko do klastrów, które działają prawidłowo.
Aby efektywnie obsługiwać wiele wystąpień, zalecamy zewnętrzne dostosowywanie plików, takich jak konto magazynu geograficznie nadmiarowego. Takie podejście minimalizuje stan przechowywany w usłudze Azure OpenAI dla każdego regionu. Nadal musisz dostroić pliki dla każdego wystąpienia w celu hostowania wdrożenia modelu.
Ważne jest, aby monitorować wymaganą przepływność pod względem tokenów na minutę (TPM) i żądań na minutę (RPM). Upewnij się, że wystarczająca liczba modułów TPM przypisanych z limitu przydziału w celu zaspokojenia zapotrzebowania na wdrożenia oraz zapobieganie ograniczaniu wywołań wdrożonych modeli. Bramę, taką jak Azure API Management, można wdrożyć przed usługą Azure OpenAI lub usługami i można skonfigurować pod kątem ponawiania próby, jeśli występują przejściowe błędy i ograniczanie przepustowości. Usługa API Management może być również używana jako wyłącznik , aby zapobiec przeciążeniu usługi wywołaniem, przekroczeniu limitu przydziału. Aby dowiedzieć się więcej na temat dodawania bramy pod kątem niezawodności, zobacz Access Azure OpenAI and other language models through a gateway (Uzyskiwanie dostępu do interfejsu Azure OpenAI i innych modeli językowych za pośrednictwem bramy).
Wyszukiwanie sztucznej inteligencji — niezawodność
Wdróż wyszukiwanie sztucznej inteligencji przy użyciu warstwy cenowej Standardowa lub nowszej w regionie obsługującym strefy dostępności i wdróż co najmniej trzy repliki. Repliki są automatycznie rozłożone równomiernie w różnych strefach dostępności.
Rozważ następujące wskazówki dotyczące określania odpowiedniej liczby replik i partycji:
Monitorowanie wyszukiwania sztucznej inteligencji.
Użyj metryk monitorowania i dzienników i analizy wydajności, aby określić odpowiednią liczbę replik, aby uniknąć ograniczania i partycji opartych na zapytaniach oraz unikać ograniczania opartego na indeksie.
Azure AI Studio — niezawodność
Jeśli wdrażasz w klastrach obliczeniowych za zarządzanym punktem końcowym online usługi Machine Learning, rozważ następujące wskazówki dotyczące skalowania:
Automatyczne skalowanie punktów końcowych online w celu zapewnienia, że wystarczająca pojemność jest dostępna do spełnienia wymagań. Jeśli sygnały użycia nie są wystarczająco czasochłonne ze względu na użycie serii, rozważ nadmierną aprowizowanie, aby zapobiec wpływowi na niezawodność zbyt małej liczby dostępnych wystąpień.
Rozważ utworzenie reguł skalowania na podstawie metryk wdrożenia, takich jak obciążenie procesora CPU i metryki punktu końcowego, takie jak opóźnienie żądania.
W przypadku aktywnego wdrożenia produkcyjnego należy wdrożyć nie mniej niż trzy wystąpienia.
Unikaj wdrożeń względem wystąpień w użyciu. Zamiast tego należy wdrożyć w nowym wdrożeniu i przenieść ruch po zakończeniu wdrażania, aby odbierać ruch.
Zarządzane punkty końcowe online działają jako moduł równoważenia obciążenia i router dla zarządzanych zasobów obliczeniowych uruchomionych za nimi. Możesz skonfigurować procent ruchu, który powinien być kierowany do każdego wdrożenia, o ile wartości procentowe sumuje się do 100%. Możesz również wdrożyć zarządzany punkt końcowy online z 0% ruchem kierowanym do dowolnego wdrożenia. Jeśli, podobnie jak w podanej implementacji referencyjnej, używasz infrastruktury jako kodu (IaC) do wdrażania zasobów, w tym zarządzanych punktów końcowych online, istnieje problem z niezawodnością. Jeśli ruch jest skonfigurowany do kierowania do wdrożeń (utworzonych za pośrednictwem interfejsu wiersza polecenia lub usługi Azure AI Studio) i wykonujesz kolejne wdrożenie IaC obejmujące zarządzany punkt końcowy online, nawet jeśli nie zaktualizuje zarządzanego punktu końcowego online w jakikolwiek sposób, ruch punktu końcowego zostanie przywrócony do routingu 0% ruchu. W rzeczywistości oznacza to, że wdrożone przepływy monitów nie będą już osiągalne, dopóki nie dostosujesz ruchu z powrotem do miejsca, w którym chcesz.
Uwaga
Te same wskazówki dotyczące skalowalności usługi App Service z architektury bazowej mają zastosowanie w przypadku wdrażania przepływu w usłudze App Service.
Projekt obejmujący wiele regionów
Ta architektura nie jest zbudowana jako sygnatura regionalna w architekturze obejmującej wiele regionów. Zapewnia wysoką dostępność w jednym regionie ze względu na pełne użycie stref dostępności, ale brakuje niektórych kluczowych składników, aby było to naprawdę gotowe dla rozwiązania z wieloma regionami. Poniżej przedstawiono niektóre składniki lub zagadnienia, których brakuje w tej architekturze:
- Globalny ruch przychodzący i routing
- Strategia zarządzania systemem DNS
- Strategia replikacji danych (lub izolacji)
- Oznaczenie aktywne-aktywne, aktywne-pasywne lub aktywne-zimne
- Strategia przejścia w tryb failover i powrotu po awarii w celu osiągnięcia celu czasu odzyskiwania i celu punktu odzyskiwania obciążenia
- Decyzje dotyczące dostępności regionów dla środowisk deweloperskich w zasobie usługi Azure Studio Hub
Jeśli wymagania dotyczące obciążenia wymagają strategii obejmującej wiele regionów, należy zainwestować w dodatkowe działania projektowe dotyczące składników i procesów operacyjnych na podstawie tego, co przedstawiono w tej architekturze. Zaprojektowano obsługę równoważenia obciążenia lub trybu failover w następujących warstwach:
- Dane uziemienia
- Hosting modelu
- Warstwa aranżacji (przepływ monitu w tej architekturze)
- Interfejs użytkownika dostępny dla klienta
Ponadto będziesz potrzebować zachowania ciągłości działania w zakresie obserwowaności, środowisk portalu i odpowiedzialnych problemów ze sztuczną inteligencją, takich jak bezpieczeństwo zawartości.
Zabezpieczenia
Zabezpieczenia zapewniają ochronę przed celowymi atakami i nadużyciami cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca zabezpieczeń.
Ta architektura rozszerza ślad zabezpieczeń wdrożony w ramach kompleksowego czatu podstawowego przy użyciu architektury azure OpenAI. Chociaż podstawowa architektura korzysta z tożsamości zarządzanych przypisanych przez system i przypisań ról przypisanych przez system, ta architektura używa tożsamości przypisanych przez użytkownika z ręcznie utworzonymi przypisaniami ról.
Architektura implementuje obwód zabezpieczeń sieci wraz z obwodem tożsamości zaimplementowanym w podstawowej architekturze. Z punktu widzenia sieci jedyną rzeczą, która powinna być dostępna z Internetu, jest interfejs użytkownika czatu za pośrednictwem usługi Application Gateway. Z perspektywy tożsamości interfejs użytkownika czatu powinien uwierzytelniać i autoryzować żądania. Tożsamości zarządzane są używane w miarę możliwości do uwierzytelniania aplikacji w usługach platformy Azure.
Oprócz zagadnień dotyczących sieci w tej sekcji opisano zagadnienia dotyczące zabezpieczeń dotyczące rotacji kluczy i dostrajania modelu Azure OpenAI.
Zarządzanie tożsamościami i dostępem
W przypadku korzystania z tożsamości zarządzanych przypisanych przez użytkownika należy wziąć pod uwagę następujące wskazówki:
- Utwórz oddzielne tożsamości zarządzane dla następujących zasobów usługi Azure AI Studio i usługi Machine Learning, jeśli ma to zastosowanie:
- Centrum AI Studio
- Projekty programu AI Studio do tworzenia przepływów i zarządzania nimi
- Punkty końcowe online w wdrożonym przepływie, jeśli przepływ jest wdrożony w zarządzanym punkcie końcowym online
- Implementowanie mechanizmów kontroli dostępu do tożsamości dla interfejsu użytkownika czatu przy użyciu identyfikatora Entra firmy Microsoft
Utwórz oddzielne projekty i punkty końcowe online dla różnych przepływów monitów, które mają być odizolowane od innych osób z perspektywy uprawnień. Utwórz oddzielną tożsamość zarządzaną dla każdego projektu i zarządzany punkt końcowy online. Nadaj autorom przepływów monitów dostęp tylko do projektów, których potrzebują.
Po dołączeniu użytkowników do projektów usługi Azure AI Studio w celu wykonywania funkcji, takich jak przepływy tworzenia, należy przypisania ról z najmniejszymi uprawnieniami do zasobów, których potrzebują.
Role dostępu oparte na rolach usługi Machine Learning
Podobnie jak w podstawowej architekturze system automatycznie tworzy przypisania ról dla tożsamości zarządzanych przypisanych przez system. Ponieważ system nie wie, jakie funkcje centrum i projektów mogą być używane, tworzy przypisania ról obsługujące wszystkie potencjalne funkcje. Automatycznie utworzone przypisania ról mogą obejmować uprawnienia aprowizacji na podstawie twojego przypadku użycia. Przykładem jest rola "Współautor" przypisana do centrum rejestru kontenerów, gdzie prawdopodobnie wymaga dostępu "Czytelnik" do płaszczyzny sterowania. Jeśli musisz dodatkowo ograniczyć uprawnienia dla celów najniższych uprawnień, musisz użyć tożsamości przypisanych przez użytkownika. Samodzielnie utworzysz i zachowasz te przypisania ról.
Ze względu na obciążenie konserwacją zarządzania wszystkimi wymaganymi przydziałami ta architektura sprzyja doskonałości operacyjnej w przypadku bezwzględnych przypisań ról najniższych uprawnień. Należy pamiętać, że należy wykonać wszystkie przypisania wymienione w tabeli.
Tożsamość zarządzana | Scope | Przypisania ról |
---|---|---|
Tożsamość zarządzana centrum | Współautor | Grupa zasobów |
Tożsamość zarządzana centrum | Piasta | Administrator sztucznej inteligencji platformy Azure |
Tożsamość zarządzana centrum | Container Registry | Współautor |
Tożsamość zarządzana centrum | Key Vault | Współautor |
Tożsamość zarządzana centrum | Key Vault | Administrator |
Tożsamość zarządzana centrum | Konto magazynu | Czytelnik |
Tożsamość zarządzana centrum | Konto magazynu | Współautor konta magazynu |
Tożsamość zarządzana centrum | Konto magazynu | Współautor danych w usłudze Blob Storage |
Tożsamość zarządzana centrum | Konto magazynu | Uprzywilejowany współautor danych plików magazynu |
Tożsamość zarządzana centrum | Konto magazynu | Współautor tabeli danych usługi Storage |
Tożsamość zarządzana projektu | Project | Administrator sztucznej inteligencji platformy Azure |
Tożsamość zarządzana projektu | Container Registry | Współautor |
Tożsamość zarządzana projektu | Key Vault | Współautor |
Tożsamość zarządzana projektu | Key Vault | Administrator |
Tożsamość zarządzana projektu | Konto magazynu | Czytelnik |
Tożsamość zarządzana projektu | Konto magazynu | Współautor konta magazynu |
Tożsamość zarządzana projektu | Konto magazynu | Współautor danych w usłudze Blob Storage |
Tożsamość zarządzana projektu | Konto magazynu | Uprzywilejowany współautor danych plików magazynu |
Tożsamość zarządzana projektu | Konto magazynu | Współautor tabeli danych usługi Storage |
Tożsamość zarządzana punktu końcowego w trybie online | Project | Wpisy tajne połączenia obszaru roboczego usługi Azure Machine Learning |
Tożsamość zarządzana punktu końcowego w trybie online | Project | Moduł zapisywania metryk usługi AzureML |
Tożsamość zarządzana punktu końcowego w trybie online | Container Registry | ACRPull |
Tożsamość zarządzana punktu końcowego w trybie online | Azure OpenAI | Użytkownik OpenAI usług Cognitive Services |
Tożsamość zarządzana punktu końcowego w trybie online | Konto magazynu | Współautor danych w usłudze Blob Storage |
Tożsamość zarządzana punktu końcowego w trybie online | Konto magazynu | Czytelnik danych obiektu BLOB usługi Storage |
App Service (po wdrożeniu przepływu monitu w usłudze App Service) | Azure OpenAI | Użytkownik OpenAI usług Cognitive Services |
Użytkownik portalu (tworzenie przepływu monitów) | Azure OpenAI | Użytkownik OpenAI usług Cognitive Services |
Użytkownik portalu (tworzenie przepływu monitów) | Konto magazynu | Współautor danych obiektu blob usługi Storage (użyj dostępu warunkowego) |
Użytkownik portalu (tworzenie przepływu monitów) | Konto magazynu | Uprzywilejowany współautor danych plików magazynu |
Ważne jest, aby zrozumieć, że centrum AI Studio ma zasoby platformy Azure współużytkowane przez projekty, takie jak konto magazynu i rejestr kontenerów. Jeśli masz użytkowników, którzy potrzebują tylko dostępu do podzestawu projektów, rozważ użycie warunków przypisania ról dla usług platformy Azure, które je obsługują, aby zapewnić najniższy dostęp do zasobów. Na przykład obiekty blob w usłudze Azure Storage obsługują warunki przypisywania ról. W przypadku użytkownika, który wymaga dostępu do podzbioru projektów, zamiast przypisywać uprawnienia dla poszczególnych kontenerów, użyj warunków dostępu roli, aby ograniczyć uprawnienia do kontenerów obiektów blob używanych przez te projekty. Każdy projekt ma unikatowy identyfikator GUID, który służy jako prefiks nazw kontenerów obiektów blob używanych w tym projekcie. Ten identyfikator GUID może być używany jako część warunków przypisania roli.
Centrum musi mieć Contributor
dostęp do grupy zasobów centrum w celu umożliwienia jej tworzenia i zarządzania zasobami centrum i projektu. Efekt uboczny tego centrum ma dostęp płaszczyzny sterowania do dowolnego zasobu również w grupie zasobów. Wszystkie zasoby platformy Azure, które nie są bezpośrednio powiązane z centrum, a jego projekty powinny być tworzone w oddzielnej grupie zasobów. Zalecamy utworzenie co najmniej dwóch grup zasobów dla zespołu ds. obciążeń przy użyciu samoobsługowego centrum usługi Azure AI Studio Hub. Jedna grupa zasobów zawierająca centrum, jego projekty i wszystkie jego bezpośrednie zależności, takie jak rejestr kontenerów platformy Azure, usługa Key Vault itd. Jedna grupa zasobów zawierająca wszystkie inne elementy obciążenia.
Zalecamy zminimalizowanie użycia zasobów platformy Azure potrzebnych do operacji centrum (container registry, konta magazynu, usługi Key Vault, usługi Application Insights) przez inne składniki w obciążeniach. Jeśli na przykład konieczne jest przechowywanie wpisów tajnych w ramach obciążenia, należy utworzyć oddzielną usługę Key Vault poza magazynem kluczy skojarzonym z centrum. Magazyn kluczy koncentratora powinien być używany tylko przez centrum do przechowywania wpisów tajnych centrum i projektu.
Upewnij się, że dla każdego odrębnego projektu przypisania ról dla jego zależności nie zapewniają dostępu do zasobów, których użytkownik portalu i zarządzana tożsamość zarządzana punktu końcowego online nie są wymagane. Na przykład Cognitive Services OpenAI User
przypisanie roli do usługi Azure OpenAI udziela dostępu do wszystkich wdrożeń dla tego zasobu. Nie ma możliwości ograniczenia autorów przepływów ani zarządzanych tożsamości zarządzanych punktów końcowych online z dostępem do przypisań ról do określonych wdrożeń modelu w usłudze Azure OpenAI. W takich scenariuszach nasze wskazówki dotyczą wdrażania usług, takich jak Azure OpenAI i Azure AI Search na podstawie poszczególnych projektów, i nie wdrażają zasobów w tych usługach, do których autorzy przepływów ani zarządzane tożsamości zarządzane przez punkt końcowy online nie powinny mieć dostępu. Na przykład wdróż modele tylko w wystąpieniu usługi Azure OpenAI projektu, do którego projekt wymaga dostępu. Wdrażaj indeksy tylko w wystąpieniu usługi Azure AI Search projektu, do którego projekt powinien mieć dostęp.
Sieć
Oprócz dostępu opartego na tożsamościach zabezpieczenia sieci są podstawą kompleksowej architektury czatu bazowego, która korzysta z interfejsu OpenAI. Na wysokim poziomie architektura sieci zapewnia następujące elementy:
- Tylko jeden, bezpieczny punkt wejścia dla ruchu interfejsu użytkownika czatu.
- Ruch sieciowy jest filtrowany.
- Dane przesyłane są szyfrowane kompleksowo przy użyciu protokołu Transport Layer Security (TLS).
- Eksfiltracja danych jest zminimalizowana przy użyciu usługi Private Link w celu utrzymania ruchu na platformie Azure.
- Zasoby sieciowe są logicznie grupowane i odizolowane od siebie za pośrednictwem segmentacji sieci.
Przepływy sieciowe
Dwa przepływy na tym diagramie zostały omówione w podstawowej architekturze aplikacji internetowej usługi App Service: przepływ przychodzący od użytkownika końcowego do interfejsu użytkownika czatu (1) i przepływ z usługi App Service do usług Azure PaaS (2). Ta sekcja koncentruje się na przepływie punktów końcowych online usługi Machine Learning. Poniższy przepływ przechodzi z interfejsu użytkownika czatu, który działa w podstawowej aplikacji internetowej usługi App Service do przepływu wdrożonego w środowisku obliczeniowym usługi Machine Learning:
- Wywołanie z interfejsu użytkownika czatu hostowanego w usłudze App Service jest kierowane przez prywatny punkt końcowy do punktu końcowego online usługi Machine Learning.
- Punkt końcowy online kieruje wywołanie do serwera z uruchomionym wdrożonym przepływem. Punkt końcowy online działa zarówno jako moduł równoważenia obciążenia, jak i router.
- Wywołania usług PaaS platformy Azure wymaganych przez wdrożony przepływ są kierowane za pośrednictwem zarządzanych prywatnych punktów końcowych.
Ruch przychodzący do uczenia maszynowego
W tej architekturze publiczny dostęp do obszaru roboczego usługi Machine Learning jest wyłączony. Użytkownicy mogą uzyskiwać dostęp do obszaru roboczego za pośrednictwem dostępu prywatnego, ponieważ architektura jest zgodna z prywatnym punktem końcowym konfiguracji obszaru roboczego usługi Machine Learning. W rzeczywistości prywatne punkty końcowe są używane w całej tej architekturze w celu uzupełnienia zabezpieczeń opartych na tożsamościach. Na przykład interfejs użytkownika czatu hostowanego w usłudze App Service może łączyć się z usługami PaaS, które nie są widoczne dla publicznego Internetu, w tym z punktami końcowymi usługi Machine Learning.
Dostęp do prywatnego punktu końcowego jest również wymagany do nawiązywania połączenia z obszarem roboczym usługi Machine Learning na potrzeby tworzenia przepływu.
Na diagramie przedstawiono autor przepływu monitów łączący się za pośrednictwem usługi Azure Bastion z serwerem przesiadkowym maszyny wirtualnej. Z tego serwera przesiadkowego autor może nawiązać połączenie z obszarem roboczym usługi Machine Learning za pośrednictwem prywatnego punktu końcowego w tej samej sieci co serwer przesiadkowy. Łączność z siecią wirtualną można również wykonać za pośrednictwem bram usługi ExpressRoute lub sieci VPN oraz komunikacji równorzędnej sieci wirtualnych.
Przepływ z zarządzanej sieci wirtualnej usługi Azure AI Studio do usług PaaS platformy Azure
Zalecamy skonfigurowanie centrum Azure AI Studio dla izolacji zarządzanej sieci wirtualnej, która wymaga zatwierdzenia wszystkich połączeń wychodzących. Ta architektura jest zgodna z tym zaleceniem. Istnieją dwa typy zatwierdzonych reguł ruchu wychodzącego. Wymagane reguły ruchu wychodzącego to zasoby wymagane do działania rozwiązania, takie jak usługa Container Registry i Storage. Reguły ruchu wychodzącego zdefiniowane przez użytkownika to zasoby niestandardowe, takie jak Azure OpenAI lub AI Search, które będą używane przez przepływ pracy. Należy skonfigurować reguły ruchu wychodzącego zdefiniowane przez użytkownika. Wymagane reguły ruchu wychodzącego są konfigurowane podczas tworzenia zarządzanej sieci wirtualnej. Zarządzana sieć wirtualna jest wdrażana na żądanie podczas pierwszego korzystania z niej i jest utrwalana od tego momentu.
Reguły ruchu wychodzącego mogą być prywatnymi punktami końcowymi, tagami usługi lub w pełni kwalifikowanymi nazwami domen (FQDN) dla zewnętrznych publicznych punktów końcowych. W tej architekturze łączność z usługami platformy Azure, takimi jak Container Registry, Storage, Azure Key Vault, Azure OpenAI i AI Search, są połączone za pośrednictwem łącza prywatnego. Chociaż nie w tej architekturze niektóre typowe operacje, które mogą wymagać skonfigurowania reguły ruchu wychodzącego FQDN, pobierają pakiet, klonują repozytorium GitHub lub pobierają podstawowe obrazy kontenerów z repozytoriów zewnętrznych.
Segmentacja i zabezpieczenia sieci wirtualnej
Sieć w tej architekturze ma oddzielne podsieci w następujących celach:
Application Gateway
Składniki integracji usługi App Service
Prywatne punkty końcowe
Azure Bastion
Maszyna wirtualna przesiadkowa
Podsieci trenowania i oceniania — obie te elementy umożliwiają korzystanie z własnych zasobów obliczeniowych związanych z trenowaniem i wnioskowaniem. W tej architekturze nie przeprowadzamy trenowania i korzystamy z zarządzanych obliczeń.
Scoring (Ocenianie)
Każda podsieć ma sieciową grupę zabezpieczeń, która ogranicza zarówno ruch przychodzący, jak i wychodzący dla tych podsieci do wymaganych elementów. W poniższej tabeli przedstawiono uproszczony widok reguł sieciowej grupy zabezpieczeń, które punkt odniesienia dodaje do każdej podsieci. Tabela zawiera nazwę reguły i funkcję.
Podsieć | Przychodzący | Wychodzący |
---|---|---|
snet-appGateway | Dodatki dla naszych użytkowników interfejsu użytkownika czatu źródłowe adresy IP (takie jak publiczny Internet) oraz wymagane elementy dla usługi. | Dostęp do prywatnego punktu końcowego usługi App Service oraz wymagane elementy dla usługi. |
snet-PrivateEndpoints | Zezwalaj tylko na ruch z sieci wirtualnej. | Zezwalaj tylko na ruch do sieci wirtualnej. |
snet-AppService | Zezwalaj tylko na ruch z sieci wirtualnej. | Zezwalaj na dostęp do prywatnych punktów końcowych i usługi Azure Monitor. |
AzureBastionSubnet | Zobacz wskazówki dotyczące pracy z dostępem sieciowej grupy zabezpieczeń i usługą Azure Bastion. | Zobacz wskazówki dotyczące pracy z dostępem sieciowej grupy zabezpieczeń i usługą Azure Bastion. |
snet-jumpbox | Zezwalaj na przychodzące protokoły RDP (Remote Desktop Protocol) i SSH z podsieci hosta usługi Azure Bastion. | Zezwalaj na dostęp do prywatnych punktów końcowych |
snet-agents | Zezwalaj tylko na ruch z sieci wirtualnej. | Zezwalaj tylko na ruch do sieci wirtualnej. |
snet-training | Zezwalaj tylko na ruch z sieci wirtualnej. | Zezwalaj tylko na ruch do sieci wirtualnej. |
snet-scoring | Zezwalaj tylko na ruch z sieci wirtualnej. | Zezwalaj tylko na ruch do sieci wirtualnej. |
Cały inny ruch jest jawnie odrzucany.
Podczas implementowania segmentacji i zabezpieczeń sieci wirtualnej należy wziąć pod uwagę następujące kwestie.
Włącz ochronę przed atakami DDoS dla sieci wirtualnej przy użyciu podsieci będącej częścią bramy aplikacji z publicznym adresem IP.
W miarę możliwości dodaj sieciową grupę zabezpieczeń do każdej podsieci. Użyj najostrzejszych reguł, które umożliwiają korzystanie z pełnej funkcjonalności rozwiązania.
Grup zabezpieczeń aplikacji należy używać do grupowania sieciowych grup zabezpieczeń. Grupowanie sieciowych grup zabezpieczeń ułatwia tworzenie reguł w złożonych środowiskach.
Wymiana kluczy
W tej architekturze istnieje jedna usługa, która korzysta z uwierzytelniania opartego na kluczach: zarządzanego przez usługę Machine Learning punktu końcowego online. Ponieważ używasz uwierzytelniania opartego na kluczach dla tej usługi, ważne jest:
Przechowuj klucz w bezpiecznym magazynie, takim jak usługa Key Vault, na potrzeby dostępu na żądanie od autoryzowanych klientów, takich jak aplikacja internetowa platformy Azure hostująca kontener przepływu monitów.
Zaimplementuj strategię rotacji kluczy. Jeśli ręcznie obrócisz klucze, utwórz zasady wygasania kluczy i użyj usługi Azure Policy, aby monitorować, czy klucz został obracany.
Dostrajanie modelu OpenAI
Jeśli w implementacji dostosujesz modele OpenAI, weź pod uwagę następujące wskazówki:
Jeśli przekażesz dane szkoleniowe na potrzeby precyzyjnego dostrajania, rozważ użycie kluczy zarządzanych przez klienta do szyfrowania tych danych.
Jeśli przechowujesz dane szkoleniowe w magazynie, takim jak Usługa Azure Blob Storage, rozważ użycie klucza zarządzanego przez klienta na potrzeby szyfrowania danych, tożsamości zarządzanej w celu kontrolowania dostępu do danych oraz prywatnego punktu końcowego w celu nawiązania połączenia z danymi.
Ład za pomocą zasad
Aby zapewnić zgodność z zabezpieczeniami, rozważ użycie usługi Azure Policy i zasad sieciowych, aby wdrożenia były zgodne z wymaganiami obciążenia. Korzystanie z automatyzacji platformy za pomocą zasad zmniejsza obciążenie ręcznych kroków walidacji i zapewnia ład, nawet jeśli potoki są pomijane. Rozważ następujące zasady zabezpieczeń:
- Wyłącz klucz lub inny dostęp do uwierzytelniania lokalnego w usługach, takich jak usługi Azure AI i Key Vault.
- Wymagaj określonej konfiguracji reguł dostępu do sieci lub sieciowych grup zabezpieczeń.
- Wymagaj szyfrowania, takiego jak użycie kluczy zarządzanych przez klienta.
Przypisania ról usługi Azure AI Studio dla usługi Azure Key Vault
Tożsamość zarządzana usługi Azure AI Studio wymaga przypisań ról płaszczyzny sterowania (Współautor) i płaszczyzny danych (Administrator usługi Key Vault). Oznacza to, że ta tożsamość ma dostęp do odczytu i zapisu do wszystkich wpisów tajnych, kluczy i certyfikatów przechowywanych w magazynie kluczy platformy Azure. Jeśli obciążenie ma usługi inne niż Azure AI Studio, które wymagają dostępu do wpisów tajnych, kluczy lub certyfikatów w usłudze Key Vault, obciążenie lub zespół ds. zabezpieczeń mogą nie być wygodne z tożsamością zarządzaną centrum Azure AI Studio, która ma dostęp do tych artefaktów. W takim przypadku rozważ wdrożenie wystąpienia usługi Key Vault specjalnie dla centrum Azure AI Studio i innych wystąpień usługi Azure Key Vault odpowiednio do innych części obciążenia.
Optymalizacja kosztów
Optymalizacja kosztów dotyczy sposobów zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu dotycząca optymalizacji kosztów.
Aby wyświetlić przykład cen dla tego scenariusza, użyj kalkulatora cen platformy Azure. Musisz dostosować przykład, aby był zgodny z użyciem, ponieważ w tym przykładzie uwzględniono tylko składniki zawarte w architekturze. Najdroższe składniki w scenariuszu to ochrona przed atakami DDoS i zapora wdrożona w ramach zarządzanego punktu końcowego online. Inne istotne koszty to interfejs użytkownika czatu i przetwarzanie przepływów monitów oraz wyszukiwanie sztucznej inteligencji. Zoptymalizuj te zasoby, aby zaoszczędzić najwięcej kosztów.
Compute
Przepływ monitów obsługuje wiele opcji hostowania przepływów wykonywalnych. Opcje obejmują zarządzane punkty końcowe online w usłudze Machine Learning, AKS, App Service i Azure Kubernetes Service. Każda z tych opcji ma własny model rozliczeń. Wybór zasobów obliczeniowych wpływa na całkowity koszt rozwiązania.
Azure OpenAI
Azure OpenAI to usługa oparta na użyciu, a podobnie jak w przypadku dowolnej usługi opartej na użyciu, kontrolowanie zapotrzebowania na podaż jest podstawową kontrolą kosztów. Aby to zrobić w usłudze Azure OpenAI, należy użyć kombinacji podejść:
Kontrolowanie klientów. Żądania klientów są podstawowym źródłem kosztów w modelu zużycia, dlatego kontrolowanie zachowania klienta ma kluczowe znaczenie. Wszyscy klienci powinni:
Należy zatwierdzić. Unikaj uwidaczniania usługi w taki sposób, że obsługuje dostęp bezpłatny dla wszystkich. Ogranicz dostęp zarówno za pośrednictwem kontroli sieci, jak i tożsamości, takich jak klucze lub kontrola dostępu oparta na rolach (RBAC).
Być samokontrolowane. Wymagaj od klientów używania ograniczeń ograniczania tokenów oferowanych przez wywołania interfejsu API, takich jak max_tokens i max_completions.
Używaj przetwarzania wsadowego, gdzie jest to praktyczne. Przejrzyj klientów, aby upewnić się, że są odpowiednio wsadowe monity.
Zoptymalizuj długość monitu i odpowiedzi. Dłuższe monity zużywają więcej tokenów, zwiększając koszt, ale monity, które nie mają wystarczającego kontekstu, nie pomagają modelom uzyskać dobre wyniki. Utwórz zwięzłe monity, które zapewniają wystarczającą ilość kontekstu, aby umożliwić modelowi generowanie przydatnej odpowiedzi. Podobnie upewnij się, że zoptymalizujesz limit długości odpowiedzi.
Użycie środowiska zabaw usługi Azure OpenAI powinno być w razie potrzeby i w wystąpieniach przedprodukcyjnych, aby te działania nie ponosiły kosztów produkcji.
Wybierz odpowiedni model AI. Wybór modelu odgrywa również dużą rolę w ogólnym koszcie usługi Azure OpenAI. Wszystkie modele mają mocne i słabe strony i są indywidualnie wyceniane. Użyj prawidłowego modelu dla przypadku użycia, aby upewnić się, że nie są nadmiernie obciążane model, gdy tańszy model daje akceptowalne wyniki. W tej implementacji referencyjnej rozmowy GPT 3.5-turbo został wybrany przez GPT-4, aby zaoszczędzić na wielkości kosztów wdrażania modelu przy jednoczesnym uzyskaniu wystarczających wyników.
Omówienie punktów przerwania rozliczeń. Dostrajanie jest naliczane za godzinę. Aby być najbardziej wydajnym, chcesz użyć jak największej ilości czasu dostępnego na godzinę, aby poprawić wyniki dostrajania, unikając po prostu poślizgu do następnego okresu rozliczeniowego. Podobnie koszt 100 obrazów z generowania obrazu jest taki sam jak koszt jednego obrazu. Maksymalizuj punkty przerwania cen na twoją korzyść.
Omówienie modeli rozliczeniowych. Usługa Azure OpenAI jest również dostępna w modelu rozliczeń opartym na zobowiązaniach za pośrednictwem oferty aprowizowanej przepływności . Po przewidywalnych wzorcach użycia rozważ przejście do tego modelu rozliczeń przed zakupem, jeśli jest bardziej opłacalne na woluminie użycia.
Ustaw limity aprowizacji. Upewnij się, że wszystkie przydziały aprowizacji są przydzielane tylko do modeli, które mają być częścią obciążenia, na podstawie modelu. Przepływność do już wdrożonych modeli nie jest ograniczona do tego aprowizowanego limitu przydziału, gdy przydział dynamiczny jest włączony. Limit przydziału nie jest bezpośrednio mapowy na koszty i może się różnić.
Monitorowanie użycia płatności zgodnie z rzeczywistym użyciem. Jeśli używasz cennika z płatnością zgodnie z rzeczywistym użyciem, monitoruj użycie modułu TPM i rpm. Te informacje służą do informowania o decyzjach projektowych dotyczących architektury, takich jak modele do użycia i optymalizowanie rozmiarów monitów.
Monitorowanie aprowizowanego użycia przepływności. Jeśli używasz aprowizowanej przepływności, monitoruj użycie zarządzane przez aprowizację, aby upewnić się, że nie korzystasz z zakupionej aprowizowanej przepływności.
Zarządzanie kosztami. Postępuj zgodnie ze wskazówkami dotyczącymi korzystania z funkcji zarządzania kosztami w usłudze OpenAI , aby monitorować koszty, ustawiać budżety na zarządzanie kosztami i tworzyć alerty w celu powiadamiania uczestników projektu o ryzyku lub anomaliach.
Doskonałość operacyjna
Doskonałość operacyjna obejmuje procesy operacyjne, które wdrażają aplikację i działają w środowisku produkcyjnym. Aby uzyskać więcej informacji, zobacz Lista kontrolna projektu dotycząca doskonałości operacyjnej.
Wbudowane środowiska uruchomieniowe przepływu monitów
Podobnie jak w podstawowej architekturze, ta architektura używa automatycznego środowiska uruchomieniowego , aby zminimalizować obciążenie operacyjne. Automatyczne środowisko uruchomieniowe to opcja obliczeniowa bezserwerowa w usłudze Machine Learning, która upraszcza zarządzanie obliczeniami i deleguje większość konfiguracji przepływu monitów do pliku i flow.dag.yaml
konfiguracji uruchomionej requirements.txt
aplikacji. Dzięki temu wybór jest niski, efemeryczny i oparty na aplikacjach. Użycie środowiska uruchomieniowego wystąpienia obliczeniowego lub zasobów obliczeniowych zewnętrznych, takich jak w tej architekturze, wymaga bardziej zarządzanego przez zespół cyklu życia obliczeń i należy wybrać, gdy wymagania dotyczące obciążenia przekraczają możliwości konfiguracji opcji automatycznego środowiska uruchomieniowego.
Monitorowanie
Podobnie jak w przypadku podstawowej architektury, diagnostyka jest skonfigurowana dla wszystkich usług. Wszystkie usługi, ale usługa App Service jest skonfigurowana do przechwytywania wszystkich dzienników. Usługa App Service jest skonfigurowana do przechwytywania dzienników AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs i AppServicePlatformLogs. W środowisku produkcyjnym wszystkie dzienniki są prawdopodobnie nadmierne. Dostrajanie strumieni dzienników do potrzeb operacyjnych. W przypadku tej architektury dzienniki usługi Azure Machine Learning używane przez projekt usługi Azure AI Studio obejmują: AmlComputeClusterEvent, AmlDataSetEvent, AmlEnvironmentEvent i AmlModelsEvent.
Oceń tworzenie alertów niestandardowych dla zasobów w tej architekturze, takich jak te znajdujące się w alertach punktu odniesienia usługi Azure Monitor. Na przykład:
- Alerty usługi Container Registry
- Alerty usługi Machine Learning i Azure OpenAI
- Alerty usługi Azure Web Apps
Pamiętaj, aby śledzić użycie tokenów względem wdrożeń modelu usługi Azure OpenAI. W tej architekturze przepływ monitu śledzi użycie tokenów za pośrednictwem integracji z usługą aplikacja systemu Azure Insights.
Operacje modelu językowego
Wdrożenie rozwiązań do czatów opartych na usłudze Azure OpenAI, takich jak ta architektura, powinno postępować zgodnie ze wskazówkami w temacie GenAIOps z przepływem monitów za pomocą usługi Azure DevOps i usługi GitHub. Ponadto należy rozważyć najlepsze rozwiązania dotyczące ciągłej integracji i ciągłego dostarczania (CI/CD) i architektur zabezpieczonych siecią. Poniższe wskazówki dotyczą implementacji przepływów i skojarzonej infrastruktury na podstawie zaleceń dotyczących metody GenAIOps. Te wskazówki dotyczące wdrażania nie obejmują elementów aplikacji frontonu, które nie są niezmienione w architekturze aplikacji internetowej o wysokiej dostępności punktu odniesienia.
Opracowywanie zawartości
Przepływ monitów oferuje zarówno środowisko tworzenia oparte na przeglądarce w programie Azure AI Studio, jak i za pośrednictwem rozszerzenia programu Visual Studio Code. Obie opcje przechowują kod przepływu jako pliki. W przypadku korzystania z programu Azure AI Studio pliki są przechowywane na koncie usługi Storage. Podczas pracy w programie Microsoft Visual Studio Code pliki są przechowywane w lokalnym systemie plików.
Aby stosować najlepsze rozwiązania w zakresie wspólnego programowania, pliki źródłowe powinny być przechowywane w repozytorium kodu źródłowego online, takim jak GitHub. Takie podejście ułatwia śledzenie wszystkich zmian kodu, współpracę między autorami przepływu a integracją z przepływami wdrażania, które testują i weryfikują wszystkie zmiany kodu.
W przypadku programowania w przedsiębiorstwie użyj rozszerzenia Microsoft Visual Studio Code i zestawu SDK przepływu monitów/interfejsu wiersza polecenia do programowania. Autorzy przepływów monitów mogą kompilować i testować swoje przepływy z programu Microsoft Visual Studio Code i integrować lokalnie przechowywane pliki z systemem kontroli źródła online i potokami. Chociaż środowisko oparte na przeglądarce jest dobrze dostosowane do programowania eksploracyjnego, z pewnymi pracami można go zintegrować z systemem kontroli źródła. Folder przepływu można pobrać ze strony przepływu w Files
panelu, rozpakować i wypchnąć do systemu kontroli źródła.
Ocena
Przetestuj przepływy używane w aplikacji czatu tak samo jak inne artefakty oprogramowania. Trudno jest określić i potwierdzić pojedynczą "właściwą" odpowiedź dla danych wyjściowych modelu językowego, ale możesz użyć samego modelu językowego do oceny odpowiedzi. Rozważ zaimplementowanie następujących zautomatyzowanych ocen przepływów modelu językowego:
Dokładność klasyfikacji: ocenia, czy model językowy daje "poprawny" lub "niepoprawny" wynik i agreguje wyniki w celu uzyskania oceny dokładności.
Spójność: ocenia, jak dobrze są napisane zdania w przewidywanej odpowiedzi modelu i jak spójnie łączą się ze sobą.
Płynność: ocenia przewidywaną odpowiedź modelu na jego dokładność gramatyczną i językową.
Uziemienie w kontekście: ocenia, jak dobrze przewidywane odpowiedzi modelu są oparte na wstępnie skonfigurowanym kontekście. Nawet jeśli odpowiedzi modelu językowego są poprawne, jeśli nie można ich zweryfikować względem danego kontekstu, takie odpowiedzi nie są uziemione.
Istotność: ocenia, jak dobrze przewidywane odpowiedzi modelu są zgodne z pytaniem zadawanym.
Podczas implementowania automatycznych ocen należy wziąć pod uwagę następujące wskazówki:
Generowanie wyników na podstawie ocen i mierzenie ich względem wstępnie zdefiniowanego progu sukcesu. Użyj tych wyników, aby zgłosić przebieg testu/niepowodzenie w potokach.
Niektóre z tych testów wymagają wstępnie skonfigurowanych danych wejściowych pytań, kontekstu i podstawy prawdy.
Uwzględnij wystarczającą liczbę par odpowiedzi na pytania, aby upewnić się, że wyniki testów są wiarygodne, a zalecane jest co najmniej 100–150 par. Te pary odpowiedzi na pytania są określane jako "złoty zestaw danych". Większa populacja może być wymagana w zależności od rozmiaru i domeny zestawu danych.
Unikaj używania modeli językowych, aby wygenerować dowolne dane w złotym zestawie danych.
Przepływ wdrażania
Inżynier/analityk danych monitu otwiera gałąź funkcji, w której pracują nad konkretnym zadaniem lub funkcją. Inżynier monitu/analityk danych iteruje przepływ przy użyciu przepływu monitu dla programu Microsoft Visual Studio Code, okresowo zatwierdzając zmiany i wypychając te zmiany do gałęzi funkcji.
Po zakończeniu lokalnego programowania i eksperymentowania monit inżynier/analityk danych otwiera żądanie ściągnięcia z gałęzi Feature do gałęzi Main. Żądanie ściągnięcia wyzwala potok żądania ściągnięcia. Ten potok przeprowadza szybkie kontrole jakości, które powinny obejmować:
- Wykonywanie przepływów eksperymentowania
- Wykonywanie skonfigurowanych testów jednostkowych
- Kompilacja bazy kodu
- Analiza kodu statycznego
Potok może zawierać krok, który wymaga ręcznego zatwierdzenia żądania ściągnięcia przez co najmniej jednego członka zespołu przed scaleniem. Osoba zatwierdzająca nie może być osoba zatwierdzająca, a oni mush mają wiedzę dotyczącą przepływu monitu i znajomość wymagań projektu. Jeśli żądanie ściągnięcia nie zostanie zatwierdzone, scalanie zostanie zablokowane. Jeśli żądanie ściągnięcia zostało zatwierdzone lub nie ma kroku zatwierdzania, gałąź funkcji zostanie scalona z gałęzią Main.
Scalanie z main wyzwala proces kompilacji i wydania dla środowiska deweloperskiego. Szczególnie:
- Potok ciągłej integracji jest wyzwalany z scalania do głównego. Potok ciągłej integracji wykonuje wszystkie kroki wykonywane w potoku żądania ściągnięcia i następujące kroki:
- Przepływ eksperymentowania
- Przepływ oceny
- Rejestruje przepływy w rejestrze usługi Machine Learning po wykryciu zmian
- Potok ciągłego wdrażania jest wyzwalany po zakończeniu potoku ciągłej integracji. Ten przepływ wykonuje następujące kroki:
- Wdraża przepływ z rejestru usługi Machine Learning w punkcie końcowym online usługi Machine Learning
- Uruchamia testy integracji przeznaczone dla punktu końcowego online
- Uruchamia testy weryfikacyjne kompilacji przeznaczone dla punktu końcowego online
Proces zatwierdzania jest wbudowany w proces podwyższania poziomu wydania — po zatwierdzeniu procesy ciągłej integracji i ciągłego wdrażania opisane w krokach 4.a. & 4.b. są powtarzane, przeznaczone dla środowiska testowego. Kroki a. i b. są takie same, z wyjątkiem tego, że testy akceptacyjnych użytkowników są uruchamiane po testach weryfikacyjnych kompilacji w środowisku testowym.
Procesy ciągłej integracji i ciągłego wdrażania opisane w krokach 4.a. & 4.b. są uruchamiane w celu podwyższenia poziomu wydania do środowiska produkcyjnego po zweryfikowaniu i zatwierdzeniu środowiska testowego.
Po wydaniu do środowiska na żywo mają miejsce zadania operacyjne monitorowania metryk wydajności i oceny wdrożonych modeli językowych. Obejmuje to, ale nie jest ograniczone do:
- Wykrywanie dryfu danych
- Obserwowanie infrastruktury
- Zarządzanie kosztami
- Komunikacja wydajności modelu z uczestnikami projektu
Wskazówki dotyczące wdrażania
Za pomocą punktów końcowych usługi Machine Learning można wdrażać modele w sposób, który zapewnia elastyczność podczas wydawania do środowiska produkcyjnego. Rozważ następujące strategie, aby zapewnić najlepszą wydajność i jakość modelu:
Wdrożenia niebieskie/zielone: dzięki tej strategii można bezpiecznie wdrożyć nową wersję usługi internetowej w ograniczonej grupie użytkowników lub żądań przed skierowaniem całego ruchu do nowego wdrożenia.
Testowanie A/B: Nie tylko wdrożenia niebieskie/zielone są skuteczne w celu bezpiecznego wprowadzania zmian, można ich również użyć do wdrożenia nowego zachowania, które umożliwia podzbiorowi użytkowników ocenę wpływu zmiany.
Uwzględnij linting plików języka Python, które są częścią przepływu monitu w potokach. Linting sprawdza zgodność ze standardami stylów, błędami, złożonością kodu, nieużywanymi importami i nazewnictwem zmiennych.
Podczas wdrażania przepływu w obszarze roboczym usługi Machine Learning izolowanego przez sieć użyj własnego agenta, aby wdrożyć artefakty w zasobach platformy Azure.
Rejestr modeli uczenia maszynowego powinien być aktualizowany tylko wtedy, gdy istnieją zmiany w modelu.
Modele językowe, przepływy i interfejs użytkownika klienta powinny być luźno powiązane. Aktualizacje przepływów i interfejsu użytkownika klienta mogą być dostępne bez wpływu na model i odwrotnie.
Podczas opracowywania i wdrażania wielu przepływów każdy przepływ powinien mieć własny cykl życia, co pozwala na luźno powiązane środowisko podczas promowania przepływów z eksperymentowania do środowiska produkcyjnego.
Infrastruktura
Podczas wdrażania podstawowych składników czatu kompleksowego usługi Azure OpenAI niektóre z aprowizowania usług są podstawowe i trwałe w architekturze, natomiast inne składniki są bardziej efemeryczne, ich istnienie związane z wdrożeniem. Ponadto, gdy zarządzana sieć wirtualna jest podstawowa, jest ona automatycznie aprowizowana podczas tworzenia wystąpienia obliczeniowego, co prowadzi do pewnych zagadnień.
Podstawowe składniki
Niektóre składniki tej architektury istnieją z cyklem życia, który wykracza poza pojedynczy przepływ monitów lub dowolne wdrożenie modelu. Te zasoby są zwykle wdrażane raz w ramach podstawowego wdrożenia przez zespół ds. obciążeń i są przechowywane niezależnie od nowych, usuniętych lub zaktualizowanych przepływów monitów lub wdrożeń modelu.
- Obszar roboczy usługi Machine Learning
- Konto magazynu dla obszaru roboczego usługi Machine Learning
- Container Registry
- Wyszukiwanie sztucznej inteligencji
- Azure OpenAI
- Azure Application Insights
- Azure Bastion
- Maszyna wirtualna platformy Azure dla serwera przesiadkowego
Składniki efemeryczne
Niektóre zasoby platformy Azure są ściślej powiązane z projektem określonych przepływów monitów. Takie podejście umożliwia powiązanie tych zasobów z cyklem życia składnika i stanie się efemeryczne w tej architekturze. Zasoby platformy Azure mają wpływ na rozwój obciążenia, na przykład po dodaniu lub usunięciu przepływów lub wprowadzeniu nowych modeli. Te zasoby zostaną ponownie utworzone i usunięte wcześniejsze wystąpienia. Niektóre z tych zasobów są bezpośrednimi zasobami platformy Azure, a niektóre są objawami płaszczyzny danych w ramach ich usługi zawierającej.
Model w rejestrze modeli uczenia maszynowego powinien zostać zaktualizowany, jeśli został zmieniony, w ramach potoku ciągłego wdrażania.
Obraz kontenera powinien zostać zaktualizowany w rejestrze kontenerów w ramach potoku ciągłego wdrażania.
Punkt końcowy usługi Machine Learning jest tworzony po wdrożeniu przepływu monitu, jeśli wdrożenie odwołuje się do punktu końcowego, który nie istnieje. Ten punkt końcowy musi zostać zaktualizowany, aby wyłączyć dostęp publiczny.
Wdrożenia punktu końcowego usługi Machine Learning są aktualizowane po wdrożeniu lub usunięciu przepływu.
Magazyn kluczy dla interfejsu użytkownika klienta musi zostać zaktualizowany przy użyciu klucza do punktu końcowego po utworzeniu nowego punktu końcowego.
Zarządzana sieć wirtualna na żądanie
Zarządzana sieć wirtualna jest automatycznie aprowizowana podczas pierwszego tworzenia wystąpienia obliczeniowego. Jeśli używasz infrastruktury jako kodu do wdrożenia centrum i nie masz zasobów obliczeniowych usługi AI Studio w aplikacji Bicep, zarządzana sieć wirtualna nie zostanie wdrożona i podczas nawiązywania połączenia z usługą Azure AI Studio zostanie wyświetlony błąd. Należy wykonać jednorazową akcję, aby ręcznie aprowizować zarządzaną sieć wirtualną po wdrożeniu IaC.
Organizacja zasobów
Jeśli masz scenariusz, w którym centrum jest centralnie własnością zespołu innego niż zespół roboczy, możesz zdecydować się na wdrożenie projektów w osobnych grupach zasobów. Jeśli używasz infrastruktury jako kodu, możesz to zrobić, ustawiając inną grupę zasobów w Bicep. Jeśli używasz portalu, możesz ustawić defaultWorkspaceResourceGroup
właściwość w obszarze workspaceHubConfig
na grupę zasobów, którą chcesz utworzyć.
Efektywność wydajności
Efektywność wydajności to możliwość skalowania obciążenia w celu zaspokojenia zapotrzebowania użytkowników w wydajny sposób. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu pod kątem wydajności.
W tej sekcji opisano wydajność z perspektywy usług Azure Search, Azure OpenAI i Machine Learning.
Azure Search — wydajność
Postępuj zgodnie ze wskazówkami, aby analizować wydajność w wyszukiwaniu sztucznej inteligencji.
Azure OpenAI — wydajność
Określ, czy aplikacja wymaga aprowizowanej przepływności , czy udostępnionego hostingu, czy użycia modelu. Aprowizowana przepływność zapewnia pojemność zarezerwowaną przetwarzania dla wdrożeń modelu OpenAI, co zapewnia przewidywalną wydajność i przepływność modeli. Ten model rozliczeń różni się od modelu hostingu współużytkowanego lub użycia. Model zużycia jest najlepszym wysiłkiem i może podlegać hałaśliwym sąsiadom lub innym elementom stresu na platformie.
Monitorowanie użycia zarządzanego przez aprowizację pod kątem aprowizowanej przepływności.
Uczenie maszynowe — wydajność
W przypadku wdrażania w punktach końcowych online usługi Machine Learning:
Postępuj zgodnie ze wskazówkami dotyczącymi automatycznego skalowania punktu końcowego online. Należy to zrobić, aby zachować ścisłe dopasowanie do zapotrzebowania bez nadmiernej aprowizacji, zwłaszcza w okresach niskiego użycia.
Wybierz odpowiednią jednostkę SKU maszyny wirtualnej dla punktu końcowego online, aby spełnić cele dotyczące wydajności. Przetestuj wydajność zarówno mniejszej liczby wystąpień, jak i większych jednostek SKU w porównaniu z większą liczbą wystąpień i mniejszymi jednostkami SKU, aby znaleźć optymalną konfigurację.
Wdrażanie tego scenariusza
Aby wdrożyć i uruchomić implementację referencyjną, wykonaj kroki opisane w kompleksowej implementacji referencyjnej odniesienia interfejsu OpenAI.
Współautorzy
Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.
- Rob Bagby | Wzorce i praktyki — Microsoft
- Freddy Ayala | Architekt rozwiązań w chmurze — Microsoft
- Prabal Deb | Starszy inżynier oprogramowania — Microsoft
- Raouf Aliouat | Inżynier oprogramowania II — Microsoft
- Ritesh Modi | Główny inżynier oprogramowania — Microsoft
- Ryan Pfalz | Starszy architekt rozwiązań — Microsoft
Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.