Kompleksowa architektura referencyjna czatu openAI wg planu bazowego

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 następujących elementów:

• Interfejs użytkownika czatu.
• Repozytoria danych zawierające informacje specyficzne dla domeny, które są istotne dla zapytań użytkownika.
• Modele językowe, które powodują, że dane specyficzne dla domeny generują odpowiednią odpowiedź.
• Orkiestrator, który nadzoruje interakcje między składnikami.

Ten artykuł zawiera architekturę bazową ułatwiającą tworzenie i wdrażanie aplikacji do czatów dla przedsiębiorstw korzystających z modeli językowych usługi Azure OpenAI Service. Architektura używa przepływu monitów do tworzenia przepływów wykonywalnych. Te przepływy wykonywalne organizuje przepływ pracy z przychodzących monitów do magazynów danych w celu pobrania danych uziemienia dla modeli językowych i innej wymaganej logiki języka Python. Przepływ wykonywalny jest wdrażany w zarządzanym punkcie końcowym online korzystającym z zarządzanych zasobów obliczeniowych.

Hosting niestandardowego interfejsu użytkownika czatu jest zgodny z podstawowej aplikacji internetowej usług app services wskazówki dotyczące wdrażania bezpiecznej, strefowo nadmiarowej i wysokiej dostępności aplikacji internetowej w usłudze Azure App 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. W architekturze interfejsu użytkownika czatu usługa App Service komunikuje się z zarządzanym punktem końcowym online dla przepływu przez prywatny punkt końcowy. Publiczny dostęp do portalu usługi Azure AI Foundry jest wyłączony.

Centrum Azure AI Foundry jest konfigurowane przy użyciu zarządzanej izolacji sieci wirtualnej, które wymagają zatwierdzenia dla wszystkich połączeń wychodzących. W tej konfiguracji tworzona jest zarządzana sieć wirtualna, a zarządzane prywatne punkty końcowe są ustanawiane w celu umożliwienia łączności z zasobami prywatnymi, takimi jak miejsce pracy Azure Storage, Azure Container Registry i Azure OpenAI. Te połączenia prywatne są używane podczas tworzenia przepływu i testowania przez przepływy wdrożone w obliczeniach usługi Azure Machine Learning.

Centrum to zasób najwyższego poziomu usługi Azure AI Foundry, 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 więcej środowisk wymagających różnych przepływów monitów korzystających z różnych logiki i potencjalnie różnych zasobów zaplecza, takich jak magazyny danych, możesz rozważyć zaimplementowanie tych środowisk w innym projekcie.

Architektura

Pobierz plik programu Visio z tą architekturą.

Składniki

Wiele składników tej architektury jest takich samych jak zasoby w podstawowej architektury czatu openAI platformy Azure openAI. Na poniższej liście przedstawiono różnice między podstawową architekturą a architekturą punktu odniesienia.

• usługi Azure OpenAI jest używana w obu architekturach. 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 GPT-4, GPT-3.5-Turbo i osadzania zestawu modeli. Architektura bazowa używa funkcji przedsiębiorstwa, takich jak sieci wirtualnych i linków prywatnych,, że podstawowa architektura nie implementuje.

• azure AI Foundry to platforma, której można użyć do tworzenia, testowania i wdrażania rozwiązań sztucznej inteligencji. Ta architektura używa portalu Azure AI Foundry do kompilowania, testowania i wdrażania logiki orkiestracji przepływu monitów dla aplikacji czatu. W tej architekturze usługa Azure AI Foundry udostępnia zarządzaną sieć wirtualną na potrzeby zabezpieczeń sieci. Aby uzyskać więcej informacji, zobacz sekcję sieci w tym artykule.

• usługa Azure 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.

• usługa Azure Web Application Firewall to usługa natywna dla chmury, która pomaga chronić aplikacje internetowe przed typowymi programami wykorzystującymi luki w zabezpieczeniach, 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. Ta widoczność ułatwia 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.

• azure Virtual Network to usługa, której można użyć do tworzenia izolowanych i bezpieczniejszych 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.

• azure Private Link umożliwia klientom dostęp do usług Azure PaaS bezpośrednio z prywatnych sieci wirtualnych bez korzystania z publicznych adresów 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 obejmuje wiele składników, które mogą być obsługiwane przez inne usługi platformy Azure, które mogą lepiej dopasować się do funkcjonalnych i niefunkcjonalnych wymagań obciążenia.

Obszary robocze i środowiska portalu usługi Machine Learning

Ta architektura używa portalu Azure AI Foundry do kompilowania, testowania i wdrażania przepływów monitów. Alternatywnie można użyć obszarów roboczych usługi Machine Learning. Obie usługi mają funkcje, które nakładają się na siebie. Portal jest dobrym wyborem do projektowania rozwiązania przepływu monitów, ale usługa Machine Learning ma obecnie lepszą obsługę niektórych funkcji. Aby uzyskać więcej informacji, zobacz Szczegółowe porównanie funkcji. Zalecamy, aby nie mieszać i dopasowywać portalu i programu Machine Learning Studio. Jeśli możesz wykonać pracę całkowicie w portalu usługi Azure AI Foundry, użyj portalu. Jeśli potrzebujesz funkcji z usługi Machine Learning Studio, użyj programu Studio.

Składniki warstwy aplikacji

Platforma Azure udostępnia kilka zarządzanych usług aplikacji, które mogą służyć jako warstwa aplikacji dla frontonu interfejsu użytkownika czatu. Te usługi obejmują opcje obliczeniowe i rozwiązania kontenerów . Na przykład ta architektura korzysta z usług Web Apps i Web App for Containers dla interfejsu API interfejsu użytkownika czatu i hosta przepływu monitów odpowiednio. Podobne wyniki można osiągnąć przy użyciu usługi Azure Kubernetes Service (AKS) lub usługi Azure Container Apps. Wybierz platformę aplikacji dla obciążenia na podstawie określonych wymagań funkcjonalnych i niefunkcjonalnych.

Hosting przepływu monitów

Wdrażanie przepływów monitów nie jest ograniczone do klastrów obliczeniowych usługi Machine Learning. Ta architektura ilustruje ten punkt przy użyciu alternatywnego rozwiązania w usłudze App Service. Przepływy są ostatecznie konteneryzowaną aplikacją, którą można wdrożyć w dowolnej usłudze platformy Azure zgodnej z kontenerami. Te opcje obejmują usługi, takie jak AKS, Container Apps i App Service. Wybierz usługę kontenera platformy Azure na podstawie wymagań warstwy aranżacji.

Przykład, dlaczego można rozważyć wdrożenie hostingu przepływu monitów na alternatywnym środowisku obliczeniowym, omówiono w dalszej części tego artykułu.

Magazyn danych uziemienia

Ta architektura prowadzi przez wyszukiwanie sztucznej inteligencji, ale wybór magazynu danych dla danych uziemieniowych jest decyzją architektury specyficzną dla obciążenia. Wiele obciążeń używa kilku języków i ma różne źródła i technologie na potrzeby uziemienia danych. Te platformy danych obejmują istniejące magazyny danych przetwarzania transakcji online, natywne dla chmury bazy danych, takie jak Azure Cosmos DB, i wyspecjalizowane rozwiązania, takie jak wyszukiwanie sztucznej inteligencji. Wyszukiwanie wektorowe jest wspólną cechą tego typu magazynu danych, ale nie jest wymagane. Aby uzyskać więcej informacji, zobacz Wybieranie usługi platformy Azure na potrzeby wyszukiwania wektorów.

Zagadnienia dotyczące

Te zagadnienia implementują filary platformy Azure Well-Architected Framework, która jest zestawem wytycznych, których można użyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Well-Architected Framework.

Zastosuj tę architekturę i wskazówki dotyczące projektowania w obciążeniach sztucznej inteligencji na platformie Azure podczas procesu projektowania dla określonego obciążenia.

Niezawodność

Niezawodność pomaga zapewnić, ż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 między nimi wdrożono co najmniej dwa wystąpienia. W przypadku przestoju w jednej strefie inne strefy w regionie mogą nie mieć wpływu. Architektura pomaga również zagwarantować, że wystarczająco dużo wystąpień i konfiguracji usług platformy Azure są rozmieszczone w różnych strefach dostępności. Aby uzyskać więcej informacji, zobacz Punkt odniesienia aplikacji internetowej o wysokiej dostępności strefowo nadmiarowej.

Ta sekcja dotyczy niezawodności z perspektywy składników tej architektury, które nie zostały uwzględnione w architekturze punktu odniesienia usługi App Service, w tym usługi Machine Learning, Azure OpenAI i wyszukiwania sztucznej inteligencji.

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. Obliczenia usługi Machine Learning nie obsługują stref dostępności. Aby wyeliminować potencjalne skutki katastrofy na poziomie centrum danych w składnikach usługi Machine Learning, należy ustanowić klastry w różnych regionach i wdrożyć moduł 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.

Alternatywą dla klastrów obliczeniowych usługi Machine Learning są usługi AKS, Azure Functions, Container Apps i App 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, możesz 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. Ta architektura korzysta z usługi App Service, ponieważ obciążenie korzysta już z niego dla interfejsu użytkownika czatu i nie korzysta 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 używają usługi AKS dla innych składników obciążenia.

Poniższy przepływ danych odpowiada poprzedniemu diagramowi:

1. Przepływy są tworzone w przepływie monitów, a architektura sieci pozostaje niezmieniona. Autorzy usługi Flow łączą się ze środowiskiem tworzenia w projekcie usługi Azure AI Foundry za pośrednictwem prywatnego punktu końcowego, a zarządzane prywatne punkty końcowe są używane do nawiązywania połączenia z usługami platformy Azure podczas testowania przepływów.

2. Ten kropkowany wiersz wskazuje, że konteneryzowane przepływy wykonywalne są wypychane do usługi Container Registry. Diagram nie pokazuje 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 usługi Azure AI Foundry.

3. Inna aplikacja internetowa jest wdrażana w tym samym planie usługi App Service, który hostuje interfejs użytkownika czatu. Nowa aplikacja internetowa hostuje konteneryzowany przepływ monitów, który jest kolokowany w tym samym planie usługi App Service. Ten plan usługi działa już co najmniej trzy wystąpienia rozłożone w różnych strefach 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.

4. 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 są widoczne tylko w podsieci prywatnego punktu końcowego zarządzanego przez usługę Machine Learning, wymagają teraz również ujawnienia w sieci wirtualnej w celu ustanowienia zasięgu wzroku z usługi App Service.

Niezawodność w usłudze Azure OpenAI

Usługa Azure OpenAI nie obsługuje stref dostępności. Aby wyeliminować potencjalne skutki katastrofy na poziomie centrum danych we wdrożeniach modeli w usłudze Azure OpenAI, należy wdrożyć usługę Azure OpenAI w różnych regionach i wdrożyć moduł 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. Aby hostować wdrożenie modelu, należy dostosować pliki dla każdego wystąpienia.

Ważne jest, aby monitorować wymaganą przepływność pod względem tokenów na minutę (TPM) i żądań na minutę (RPM). Przypisz wystarczającą ilość modułu TPM z limitu przydziału, aby zaspokoić zapotrzebowanie na wdrożenia i zapobiec ograniczaniu wywołań wdrożonych modeli. Bramę, na przykład usługę Azure API Management, można wdrożyć przed usługą Azure OpenAI i skonfigurować ją pod kątem ponawiania próby w przypadku wystąpienia przejściowych błędów i ograniczania przepustowości. Możesz również użyć usługi API Management jako wyłącznika , aby zapobiec przeciążeniu usługi wywołaniami i przekroczeniu limitu przydziału. Aby uzyskać więcej informacji, zobacz Używanie bramy przed wieloma wdrożeniami lub wystąpieniami usługi Azure OpenAI.

Niezawodność w wyszukiwaniu sztucznej inteligencji

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.

Skorzystaj z poniższych wskazówek, aby określić odpowiednią liczbę replik i partycji:

• Monitorowanie wyszukiwania sztucznej inteligencji.

• Użyj metryk monitorowania i dzienników oraz analizy wydajności, aby określić odpowiednią liczbę replik. Takie podejście pomaga uniknąć ograniczania przepływności opartej na zapytaniach i partycji oraz ograniczania opartego na indeksie.

Niezawodność w narzędziu Azure AI Foundry

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. Takie podejście pomaga zwiększyć niezawodność, zapewniając dostępność wystarczającej liczby wystąpień.

• Utwórz reguły skalowania na podstawie metryk wdrażania , takich jak obciążenie procesora CPU i metryki punktu końcowego , takie jak opóźnienie żądań.

• Wdróż nie mniej niż trzy wystąpienia dla aktywnego wdrożenia produkcyjnego.

• Unikaj wdrożeń względem wystąpień w użyciu. Wdróż w nowym wdrożeniu i przenieś ruch po tym, jak inne wdrożenie będzie gotowe do odbierania ruchu.

Zarządzane punkty końcowe online pełnią rolę modułu równoważenia obciążenia i routera dla zarządzanych zasobów obliczeniowych uruchamianych za nimi. Można skonfigurować procent ruchu, który powinien być kierowany do każdego wdrożenia, o ile wartość procentowa sumuje się do 100%. Można również wdrożyć zarządzany punkt końcowy online z 0% ruchu kierowanego do dowolnego wdrożenia.

Jeśli 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ą. Ten problem został wyróżniony w podanej implementacji referencyjnej. Jeśli ruch jest skonfigurowany do kierowania do wdrożeń utworzonych za pośrednictwem interfejsu wiersza polecenia lub portalu usługi Azure AI Foundry, a następnie 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 ten scenariusz oznacza, że wdrożone przepływy monitów nie będą osiągalne, dopóki nie dostosujesz ruchu z powrotem do odpowiedniego miejsca.

Projekt z wieloma regionami

Ta architektura nie służy jako sygnatura regionalna w architekturze z wieloma regionami. Zapewnia wysoką dostępność w jednym regionie, ponieważ całkowicie używa stref dostępności, ale brakuje niektórych kluczowych składników, aby ten projekt był gotowy do użycia w wielu regionach. Ta architektura nie obejmuje następujących składników i zagadnień:

• 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 obciążenia i celu punktu odzyskiwania
• Zagadnienia dotyczące dostępności regionów dla środowisk deweloperskich w zasobie usługi Azure AI Foundry Hub

Jeśli obciążenie wymaga strategii obejmującej wiele regionów, musisz zainwestować w projekt składników i procesów operacyjnych oprócz projektu przedstawionego w tej architekturze. Projekt musi obsługiwać równoważenie obciążenia lub tryb failover w następujących warstwach:

• Dane uziemienia
• Hosting modelu
• Warstwa orkiestracji, która jest przepływem monitów w tej architekturze
• Interfejs użytkownika dostępny dla klienta

Należy również zachować ciągłość działalności biznesowej w zakresie obserwacji, środowisk portalu i odpowiedzialnej sztucznej inteligencji, takich jak bezpieczeństwo zawartości.

Zabezpieczenia

Zabezpieczenia zapewniają ochronę przed celowymi atakami i nieprawidłowym użyciem 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 podstawową architekturę referencyjną czatu OpenAI w warstwie Podstawowa. 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 i ręcznie utworzonych przypisań ról.

Ta architektura implementuje obwód zabezpieczeń sieci oprócz obwodu tożsamości implementowania podstawowej architektury. Z perspektywy sieci tylko interfejs użytkownika czatu powinien być dostępny z Internetu za pośrednictwem usługi Application Gateway. Z perspektywy tożsamości interfejs użytkownika czatu powinien uwierzytelniać i autoryzować żądania. Użyj tożsamości zarządzanych, jeśli to możliwe, aby uwierzytelnić aplikacje w usługach platformy Azure.

W tej sekcji opisano zagadnienia dotyczące sieci i zabezpieczeń dotyczące rotacji kluczy i dostrajania modelu usługi 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 Foundry i Machine Learning, jeśli ma to zastosowanie:

  • Centrum usługi Azure AI Foundry
  • Projekty usługi Azure AI Foundry na potrzeby 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

Jeśli chcesz odizolować uprawnienia dla przepływów monitów, utwórz oddzielne projekty i punkty końcowe online dla różnych przepływów monitów. 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 Foundry w celu wykonywania funkcji, takich jak przepływy tworzenia, przypisz role z najmniejszymi uprawnieniami dla potrzebnych zasobów.

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, które funkcje centrum i projektów można użyć, tworzy przypisania ról, które obsługują wszystkie potencjalne funkcje. Automatycznie utworzone przypisania ról mogą zastępować uprawnienia aprowizacji na podstawie twojego przypadku użycia. Jednym z przykładów jest to, że system przypisuje rolę Współautor do centrum rejestru kontenerów, ale centrum prawdopodobnie wymaga tylko dostępu czytelnika do płaszczyzny sterowania. Jeśli musisz ograniczyć uprawnienia dla celów z najmniejszymi uprawnieniami, 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ń. Musisz 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 Azure AI Foundry udostępnia zasoby platformy Azure, takie jak konta magazynu i rejestr kontenerów, między projektami. 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 Storage obsługują warunki przypisywania ról. Jeśli użytkownik wymaga dostępu do podzestawu projektów, użyj warunków dostępu do ról, aby ograniczyć uprawnienia do kontenerów obiektów blob używanych przez te projekty zamiast przypisywać uprawnienia dla poszczególnych kontenerów. 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 wymaga Contributor dostępu do grupy zasobów centrum, aby można było tworzyć zasoby centrum i projektu oraz zarządzać nimi. Contributor dostęp zapewnia również dostęp płaszczyzny kontroli piasty do dowolnego zasobu, który znajduje się w grupie zasobów. Utwórz wszystkie zasoby platformy Azure, które nie są bezpośrednio powiązane z centrum i jego projektami w oddzielnej grupie zasobów. Zalecamy utworzenie co najmniej dwóch grup zasobów dla zespołu roboczego, który korzysta z własnego centrum azure AI Foundry. Jedna grupa zasobów zawiera centrum, jego projekty i wszystkie jego bezpośrednie zależności, takie jak rejestr kontenerów platformy Azure i usługa Key Vault. Druga grupa zasobów zawiera wszystkie inne elementy obciążenia.

Zalecamy zminimalizowanie użycia zasobów platformy Azure potrzebnych do działania centrum 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ć oddzielne wystąpienie usługi Key Vault od tego, który jest skojarzony z koncentratorem. Tylko centrum powinno używać magazynu kluczy koncentratora 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, które mają to przypisanie roli do określonych wdrożeń modelu w usłudze Azure OpenAI. W tych scenariuszach zalecamy wdrażanie usług, takich jak Azure OpenAI i AI Search dla każdego projektu, 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óż tylko modele w wystąpieniu usługi Azure OpenAI, do którego projekt wymaga dostępu. Wdrażaj indeksy tylko w wystąpieniu wyszukiwania sztucznej inteligencji, 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:

• Istnieje tylko jeden bezpieczny punkt wejścia dla ruchu interfejsu użytkownika czatu.
• Ruch sieciowy jest filtrowany.
• Dane przesyłane są szyfrowane na końcu za pomocą usługi Transport Layer Security.
• 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

Przepływ przychodzący od użytkownika końcowego do interfejsu użytkownika czatu i przepływ z usługi App Service do usług Azure PaaS opisano w architekturze aplikacji internetowej usługi App Service odniesienia. Ta sekcja koncentruje się na przepływie punktów końcowych online usługi Machine Learning. Przechodzi on 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:

1. 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.
2. Punkt końcowy online kieruje wywołanie do serwera, na który jest uruchamiany wdrożony przepływ. Punkt końcowy online służy zarówno jako moduł równoważenia obciążenia, jak i router.
3. Wywołania usług PaaS platformy Azure, których wymaga 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. 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ązania połączenia z obszarem roboczym usługi Machine Learning na potrzeby tworzenia przepływu.

Na diagramie przedstawiono autora przepływu monitów, który łączy 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. Autor może również nawiązać połączenie z siecią wirtualną za pośrednictwem usługi Azure ExpressRoute lub bram sieci VPN oraz komunikacji równorzędnej sieci wirtualnych.

Przepływ z zarządzanej sieci wirtualnej usługi Azure AI Foundry do usług PaaS platformy Azure

Zalecamy skonfigurowanie centrum Azure AI Foundry dla izolacji zarządzanej sieci wirtualnej, co 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 są przeznaczone dla zasobów wymaganych przez rozwiązanie, takich jak Usługa Container Registry i Magazyn. reguły ruchu wychodzącego zdefiniowane przez użytkownika są przeznaczone dla zasobów niestandardowych używanych przez przepływ pracy, takich jak Azure OpenAI lub AI Search. 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 po pierwszym użyciu i jest trwała od tego momentu.

Reguły ruchu wychodzącego mogą być prywatnymi punktami końcowymi, tagami usługi lub nazwami FQDN dla zewnętrznych publicznych punktów końcowych. W tej architekturze łączność z usługami platformy Azure jest ustanawiana za pośrednictwem usługi Private Link. Ta architektura nie obejmuje niektórych typowych operacji, które mogą wymagać skonfigurowania reguły ruchu wychodzącego nazwy FQDN, pobrania pakietu, sklonowania repozytorium GitHub lub pobrania podstawowych obrazów kontenerów z repozytoriów zewnętrznych.

Wystąpienie usługi Azure Firewall zarządzane przez firmę Microsoft implementuje kontrolkę FQDN ruchu wychodzącego i jest wdrażane w sieci zarządzanej usługi Azure AI Foundry. Wybierz warstwę cenową Podstawowa, jeśli chcesz kontrolować tylko ruch wychodzący HTTP (port 80) lub HTTPS (port 443). Jeśli ruch wychodzący wymaga niestandardowych protokołów lub portów, wybierz warstwę cenową Standardowa. Ta architektura używa warstwy cenowej Podstawowa, ponieważ jedynym ruchem wychodzącym jest ruch wychodzący do punktów końcowych HTTPS na porcie 443.

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
• Maszyny wirtualne z serwerem przesiadkowym
• Scoring (Ocenianie)
• Podsieci trenowania i oceniania

  Uwaga

  Podsieci trenowania i oceniania są zaprojektowane tak, aby można było używać własnych zasobów obliczeniowych do trenowania i wnioskowania. Jednak ta architektura korzysta z zarządzanych zasobów obliczeniowych i nie wykonuje żadnych szkoleń.

Każda podsieć ma sieciową grupę zabezpieczeń, która ogranicza zarówno ruch przychodzący, jak i wychodzący dla tych podsieci tylko do tego, czego wymagają. 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ć	Ruch przychodzący	Ruch wychodzący
snet-appGateway	Limity dla źródłowych adresów IP użytkowników interfejsu użytkownika czatu, takich jak publiczny Internet, i wymagane elementy dla usługi.	Dostęp do prywatnego punktu końcowego usługi App Service i wymaganych elementów 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 Praca z dostępem sieciowej grupy zabezpieczeń i usługą Azure Bastion.	Zobacz Praca z dostępem sieciowej grupy zabezpieczeń i usługą Azure Bastion.
snet-jumpbox	Zezwalaj na przychodzące protokoły Remote Desktop Protocol i Secure Shell Protocol 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 usługi Azure DDoS Protection dla sieci wirtualnej z podsiecią, która jest częścią bramy aplikacji z publicznym adresem IP.

• Dodaj sieciową grupę zabezpieczeń do każdej podsieci, jeśli jest to możliwe. 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ń upraszcza tworzenie reguł dla złożonych środowisk.

Wymiana kluczy

W tej architekturze punkt końcowy zarządzany przez usługę Machine Learning online używa uwierzytelniania opartego na kluczach, dlatego ważne jest:

• Przechowuj klucz w bezpiecznym magazynie, takim jak Usługa Key Vault, w celu uzyskania dostępu na żądanie od autoryzowanych klientów, takich jak aplikacja internetowa platformy Azure, która hostuje 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 dostosujesz modele OpenAI w implementacji, rozważ następujące wskazówki:

• Jeśli przekażesz dane szkoleniowe na potrzeby dostrajania, użyj kluczy zarządzanych przez klienta w celu zaszyfrowania tych danych.

• Jeśli przechowujesz dane szkoleniowe w magazynie, takim jak Usługa Azure Blob Storage, użyj klucza zarządzanego przez klienta do 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 pomaga zapewnić ł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 Foundry dla usługi Key Vault

Tożsamość zarządzana usługi Azure AI Foundry wymaga przypisań ról płaszczyzny sterowania (Contributor) i płaszczyzny danych (Key Vault Administrator). Te przypisania zapewniają tej tożsamości dostęp do odczytu i zapisu do wszystkich wpisów tajnych, kluczy i certyfikatów przechowywanych w usłudze Azure Key Vault. Jeśli obciążenie korzysta z usług innych niż Usługa Azure AI Foundry, które wymagają dostępu do wpisów tajnych, kluczy lub certyfikatów w usłudze Key Vault, twój zespół ds. obciążeń lub zabezpieczeń może preferować, że tożsamość zarządzana centrum Azure AI Foundry nie ma dostępu do tych artefaktów. W tym scenariuszu rozważ wdrożenie wystąpienia usługi Key Vault specjalnie dla centrum usługi Azure AI Foundry i innych wystąpień usługi Key Vault odpowiednio do innych części obciążenia.

Optymalizacja kosztów

Optymalizacja kosztów koncentruje się na sposobach 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 używane przez tę architekturę. 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 obejmują interfejs użytkownika czatu, obliczenia przepływu monitów i wyszukiwanie sztucznej inteligencji. Zoptymalizuj te zasoby, aby zmniejszyć koszty.

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 i App Service. Każda z tych opcji ma własny model rozliczeń. Wybrane zasoby obliczeniowe wpływają na całkowity koszt rozwiązania.

Azure OpenAI

Azure OpenAI to usługa oparta na użyciu, więc dopasowanie zapotrzebowania z podażą jest podstawowym sposobem kontrolowania kosztów. Aby to zrobić w usłudze Azure OpenAI, należy użyć kombinacji metod:

• 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 sposób, który obsługuje dostęp bezpłatny dla wszystkich. Ograniczanie dostępu za pośrednictwem mechanizmów kontroli sieci i tożsamości, takich jak klucze lub kontrola dostępu oparta na rolach.

  • Być samokontrolowane. Wymagaj od klientów używania ograniczeń ograniczania tokenów, które zapewniają wywołania interfejsu API, takich jak max_tokens i max_completions.

  • Używaj przetwarzania wsadowego, gdy jest to praktyczne. Przejrzyj klientów, aby upewnić się, że odpowiednio wsadowe monity.

  • Zoptymalizuj długość monitu i odpowiedzi. Dłuższe monity zużywają więcej tokenów, co zwiększa koszt. 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. Upewnij się, że zoptymalizowano limit długości odpowiedzi.

• Korzystanie z platformy Azure OpenAI plac zabaw tylko w razie potrzeby. Należy używać tylko środowiska zabaw w wystąpieniach przedprodukcyjnych, aby te działania nie ponosiły kosztów produkcji.

• Wybierz odpowiedni model sztucznej inteligencji. Wybrany model ma wpływ na całkowity koszt 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 zapobiec nadmiernemu wypłaceniu kosztów w modelu, gdy tańszy model generuje akceptowalne wyniki. Ta implementacja referencyjna czatu używa GPT 3.5-turbo zamiast GPT-4, aby zaoszczędzić koszty wdrażania modelu przy jednoczesnym uzyskaniu wystarczających wyników.

• Omówienie punktów przerwania rozliczeń. Opłata za godzinę jest naliczana za dostrajanie. Aby uzyskać maksymalną wydajność, użyj aż tej godziny, aby poprawić wyniki dostrajania przed osiągnięciem następnej godziny rozliczeniowej. 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 w woluminie użycia.

• Ustaw limity aprowizacji. Przydziel wszystkie przydziały aprowizacji 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, a te koszty mogą 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 umożliwiają informowanie 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życia zarządzanego 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 za pomocą OpenAI w celu monitorowania kosztów, ustawiania budżetów i tworzenia alertów 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 w celu zminimalizowania obciążenia operacyjnego. 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 requirements.txt konfiguracji uruchomionej flow.dag.yaml aplikacji. Ten wybór to niska konserwacja, tymczasowa i oparta na aplikacjach. Ta architektura korzysta ze środowiska uruchomieniowego wystąpienia obliczeniowego lub z zewnątrz zasobów obliczeniowych, co wymaga, aby zespół ds. obciążeń zarządzał cyklem życia obliczeń. Należy użyć środowiska uruchomieniowego wystąpienia obliczeniowego, 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 z wyjątkiem usługi App Service są skonfigurowane do przechwytywania wszystkich dzienników. Usługa App Service jest skonfigurowana do przechwytywania AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogsi AppServicePlatformLogs. W środowisku produkcyjnym wszystkie dzienniki są prawdopodobnie nadmierne. Dostrajanie strumieni dzienników do potrzeb operacyjnych. W przypadku tej architektury projekt usługi Azure AI Foundry używa dzienników usługi AmlComputeClusterEvent, AmlDataSetEvent, AmlEnvironmentEventi AmlModelsEvent Machine Learning.

Oceń tworzenie alertów niestandardowych, takich jak te znalezione w alertach punktu odniesienia usługi Azure Monitor, dla zasobów w tej architekturze. Na przykład:

• Alerty usługi Container Registry
• Alerty usługi Machine Learning i Azure OpenAI
• alerty usługi Web Apps

Pamiętaj, aby monitorować użycie tokenów względem wdrożeń modelu usługi Azure OpenAI. W tej architekturze przepływ monitu śledzi użycie tokenu dzięki integracji z usługą Application 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 GenAIOps z przepływem monitów i przepływem usługi Azure DevOps oraz GenAIOps z przepływem monitów i usługą 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 porównaniu z podstawową architekturą aplikacji internetowej o wysokiej dostępności strefowo nadmiarowej.

Opracowywanie zawartości

Przepływ monitu zapewnia zarówno środowisko tworzenia oparte na przeglądarce w portalu usługi Azure AI Foundry, jak i za pośrednictwem rozszerzenia programu Visual Studio Code . Obie te opcje przechowują kod przepływu jako pliki. W przypadku korzystania z portalu pliki są przechowywane na koncie magazynu. Podczas pracy w programie VS Code pliki są przechowywane w lokalnym systemie plików.

Aby postępować zgodnie z najlepszymi rozwiązaniami dotyczącymi wspólnego programowania, zachowaj pliki źródłowe w repozytorium kodu źródłowego online, takiego jak GitHub. Takie podejście pomaga śledzić zmiany kodu, współpracować między autorami przepływu i integrować się z przepływami wdrażania , które testują i weryfikują wszystkie zmiany kodu.

W przypadku programowania w przedsiębiorstwie użyj rozszerzenia programu VS Code oraz zestawu SDK/interfejsu wiersza polecenia monitu do programowania. Autorzy przepływów monitów mogą kompilować i testować swoje przepływy z programu VS Code i integrować lokalnie przechowywane pliki z systemem kontroli źródła online i potokami. Środowisko oparte na przeglądarce jest przeznaczone do opracowywania eksploracyjnego, ale można pracować nad integracją go z systemem kontroli źródła. Folder flow można pobrać ze strony przepływu w panelu Files, rozpakuj folder i wypchnij go do systemu kontroli źródła.

Ocena

Przetestuj przepływy używane przez aplikację czatu przy użyciu tych samych metod, które są używane do testowania innych artefaktów oprogramowania. Trudno jest określić i potwierdzić pojedynczą poprawną odpowiedź dla danych wyjściowych modelu językowego, ale możesz użyć 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 prawidłowy lub niepoprawny wynik i agreguje wyniki w celu uzyskania oceny dokładności.

• spójność ocenia, jak dobrze są pisane zdania w przewidywanej odpowiedzi modelu i jak spójnie łączą się ze sobą.

• fluency ocenia przewidywaną odpowiedź modelu na jego dokładność gramatyczną i językową.

• Groundedness względem kontekstu 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ć w danym kontekście, odpowiedzi nie są uziemione.

• Trafność 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ć, czy testy kończą się powodzeniem, czy niepowodzeniem 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 pytań i odpowiedzi, aby zapewnić niezawodność wyników testów. Zalecamy uwzględnienie co najmniej 100-150 par. Te pytania i odpowiedzi są również nazywane złotym zestawem danych. W zależności od rozmiaru i domeny zestawu danych może być wymagana większa liczba par.

• Unikaj używania modeli językowych, aby wygenerować dowolne dane w złotym zestawie danych.

Przepływ wdrażania

Poniższy przepływ danych odpowiada poprzedniemu diagramowi:

1. Inżynier monitu lub analityk danych otwiera gałąź funkcji, w której pracują nad określonym zadaniem lub funkcją. Inżynier monitu lub analityk danych iteruje przepływ przy użyciu przepływu monitu dla programu VS Code i okresowo zatwierdza zmiany i wypycha te zmiany do gałęzi funkcji.

2. Po zakończeniu programowania lokalnego i eksperymentowania inżynier lub analityk danych otwiera żądanie ściągnięcia z gałęzi funkcji do głównej gałęzi. Żą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.
   • Statyczna analiza kodu.

3. 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 i musi mieć wiedzę na temat przepływu monitów 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ą główną.

4. Scalanie z gałęzią główną wyzwala proces kompilacji i wydania dla środowiska deweloperskiego.

   a. Potok ciągłej integracji jest wyzwalany z scalania do gałęzi głównej. Potok ciągłej integracji wykonuje wszystkie kroki w potoku żądania ściągnięcia i następujące kroki:

   • Przepływ eksperymentowania
   • Przepływ oceny
   • Rejestracja usługi Flow w rejestrze usługi Machine Learning po wykryciu zmian

   b. Potok ciągłej integracji zostanie ukończony, a następnie wyzwoli potok ciągłego wdrażania. 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

5. Proces zatwierdzania jest wbudowany w proces podwyższania poziomu wersji. Po zatwierdzeniu procesy ciągłej integracji/ciągłego wdrażania powtarzają się i są 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.

6. Procesy ciągłej integracji/ciągłego wdrażania są uruchamiane w celu podwyższenia poziomu wydania do środowiska produkcyjnego po zweryfikowaniu i zatwierdzeniu środowiska testowego.

7. Po wydaniu do środowiska na żywo wykonywane są zadania operacyjne monitorowania metryk wydajności i oceny wdrożonych modeli językowych. Do zadań mogą należeć:

   • Wykrywanie dryfu danych.
   • Obserwacja 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 ich do środowiska produkcyjnego. Rozważ następujące strategie, aby zapewnić wysoką wydajność i jakość modelu:

• Użyj wdrożeń niebiesko-zielonych, aby 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.

• Użyj testowania A/B, aby wdrożyć nowe zachowanie. Testowanie A/B umożliwia podzbiorowi użytkowników ocenę skutków 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.

• Użyj własnego agenta, aby wdrożyć artefakty w zasobach platformy Azure podczas wdrażania przepływu w obszarze roboczym usługi Machine Learning odizolowanym od sieci.

• Zaktualizuj rejestr modeli usługi Machine Learning tylko wtedy, gdy istnieją zmiany w modelu.

• Upewnij się, że modele językowe, przepływy i interfejs użytkownika klienta są luźno powiązane. Należy mieć możliwość zaktualizowania przepływów i interfejsu użytkownika klienta 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. Takie podejście ułatwia swobodne łączenie przepływów podczas promowania ich od 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 ramach architektury. Cykle życia innych składników są powiązane z wdrożeniem. Zarządzana sieć wirtualna jest podstawowa i jest automatycznie aprowizowana podczas tworzenia wystąpienia obliczeniowego, dlatego należy wziąć pod uwagę następujące składniki.

Podstawowe składniki

Niektóre składniki tej architektury istnieją z cyklem życia, który wykracza poza pojedynczy przepływ monitu lub wdrożenie modelu. Te zasoby są zwykle wdrażane jednorazowo w ramach podstawowego wdrożenia przez zespół ds. obciążeń. Następnie zespół ds. obciążeń utrzymuje te zasoby oddzielnie od tworzenia, usuwania lub aktualizowania przepływów monitów lub wdrożeń modelu. Te składniki obejmują:

• Obszar roboczy usługi Machine Learning.
• Konto magazynu dla obszaru roboczego usługi Machine Learning.
• Container Registry.
• Wyszukiwanie sztucznej inteligencji.
• Azure OpenAI.
• Application Insights.
• Azure Bastion.
• Maszyna wirtualna platformy Azure dla serwera przesiadkowego.

Składniki tymczasowe

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ę tymczasowe 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 są tworzone ponownie, a poprzednie wystąpienia zostaną usunięte. Niektóre z tych zasobów to zasoby platformy Azure, a niektóre są objawami płaszczyzny danych w ramach ich zawierającej usługę.

• Model w rejestrze modeli usługi Machine Learning powinien zostać zaktualizowany, jeśli zmieni się 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 usługi IaC do wdrażania centrum i nie masz zasobów obliczeniowych usługi Azure AI Foundry w aplikacji Bicep, zarządzana sieć wirtualna nie zostanie wdrożona i wystąpi błąd podczas nawiązywania połączenia z portalem usługi Azure AI Foundry. Należy 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 usługi IaC, możesz wdrażać projekty w osobnych grupach zasobów, ustawiając inną grupę zasobów w aplikacji Bicep. Jeśli używasz portalu, możesz ustawić właściwość defaultWorkspaceResourceGroup w obszarze workspaceHubConfig na grupę zasobów, w której chcesz utworzyć projekty.

Wydajność

Wydajność odnosi się do możliwości skalowania obciążenia w celu efektywnego zaspokojenia wymagań użytkowników. Aby uzyskać więcej informacji, zobacz Lista kontrolna przeglądu projektu pod kątem wydajności.

W tej sekcji opisano wydajność z perspektywy wyszukiwania sztucznej inteligencji, usługi Azure OpenAI i uczenia maszynowego.

Wydajność wyszukiwania sztucznej inteligencji

Postępuj zgodnie ze wskazówkami, aby analizować wydajność w wyszukiwaniu sztucznej inteligencji.

Wydajność w usłudze Azure OpenAI

• Określ, czy aplikacja wymaga aprowizowanej przepływności , czy udostępnionego hostingu, czy użycia modelu. Aprowizowana przepływność pomaga zapewnić pojemność przetwarzania zarezerwowanego dla wdrożeń modelu OpenAI. Pojemność zarezerwowana zapewnia przewidywalną wydajność i przepływność dla modeli. Ten model rozliczeń różni się od modelu hostingu współużytkowanego lub użycia. Model zużycia jest najlepszy i może podlegać hałaśliwym sąsiadom lub innym problemom na platformie.

• Monitorowanie użycia zarządzanego przez aprowizację pod kątem aprowizowanej przepływności.

Wydajność w uczeniu maszynowym

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. Skalowanie automatyczne pomaga w ścisłej zgodności z zapotrzebowaniem bez nadmiernej aprowizacji, szczególnie w okresach niskiego użycia.

• Wybierz odpowiednią jednostkę SKU maszyny wirtualnej dla punktu końcowego online, aby spełnić cele dotyczące wydajności. Aby znaleźć optymalną konfigurację, przetestuj wydajność zarówno niższych liczby wystąpień, jak i większych jednostek SKU w porównaniu z większą liczbą wystąpień i mniejszymi jednostkami SKU.

Wdrażanie tego scenariusza

Aby wdrożyć i uruchomić tę implementację referencyjną, wykonaj kroki opisane w kompleksowej implementacji referencyjnej odniesienia openAI.

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

• Raouf Aliouat | Inżynier oprogramowania II — Microsoft
• Freddy Ayala | Architekt rozwiązań w chmurze — Microsoft
• Rob Bagby | Wzorce i praktyki — Microsoft
• Prabal Deb | Starszy inżynier oprogramowania — Microsoft
• Ritesh Modi | Główny inżynier oprogramowania — Microsoft
• Ryan Pfalz | Starszy architekt rozwiązań — Microsoft

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następny krok

punkt odniesienia usługi Azure OpenAI w strefie docelowej platformy Azure

Powiązane zasoby

• Perspektywa Well-Architected Framework na obciążenia sztucznej inteligencji na platformie Azure
• Azure OpenAI
• Modele językowe usługi Azure OpenAI
• przepływ monitu w portalu usługi Azure AI Foundry
• Izolacja zarządzanej sieci wirtualnej w obszarze roboczym
• Konfigurowanie prywatnego punktu końcowego dla obszaru roboczego usługi Machine Learning
• Filtrowanie zawartości