Kompleksowa architektura referencyjna czatu openAI wg planu bazowego

Azure OpenAI Service
Azure Machine Learning
Azure App Service
Azure Key Vault
Azure Monitor

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 monitu usługi Azure Machine Learning w celu utworzenia 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 uziemowych dla modeli językowych, a także innych wymaganych logiki języka Python. Przepływ wykonywalny jest wdrażany w klastrze obliczeniowym usługi Machine Learning za zarządzanym punktem końcowym online.

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ługach aplikacja systemu Azure. 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. Publiczny dostęp do obszaru roboczego usługi Machine Learning 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.

Obszar roboczy usługi Machine Learning jest skonfigurowany z izolacją zarządzanej 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.

Napiwek

Logo usługi GitHub.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

Diagram przedstawiający kompleksową architekturę czatu odniesienia przy użyciu interfejsu OpenAI.

Pobierz plik programu Visio z tą architekturą.

Składniki

Wiele składników tej architektury jest takich samych jak zasoby w podstawowej architekturze aplikacji internetowej usługi App Service, ponieważ metoda używana do hostowania interfejsu użytkownika czatu jest taka sama w obu architekturach. Składniki wyróżnione w tej sekcji koncentrują się na składnikach używanych do tworzenia i organizowania przepływów czatów, usług danych i usług, które uwidaczniają modele językowe.

  • Machine Learning to zarządzana usługa w chmurze, której można używać do trenowania, wdrażania i zarządzania modelami uczenia maszynowego. Ta architektura korzysta z kilku innych funkcji uczenia maszynowego, które są używane do tworzenia i wdrażania przepływów wykonywalnych dla aplikacji sztucznej inteligencji, które są obsługiwane przez modele językowe:

    • Przepływ monitów uczenia maszynowego to narzędzie programistyczne, za pomocą którego można tworzyć, oceniać i wdrażać przepływy łączące monity użytkownika, akcje za pomocą kodu języka Python oraz wywołania modeli uczenia języka. Przepływ monitów jest używany w tej architekturze jako warstwa, która organizuje przepływy między monitem, różnymi magazynami danych i modelem językowym.

    • Zarządzane punkty końcowe online umożliwiają wdrażanie przepływu na potrzeby wnioskowania w czasie rzeczywistym. W tej architekturze są one używane jako punkt końcowy PaaS dla interfejsu użytkownika czatu w celu wywołania przepływów monitów hostowanych przez usługę Machine Learning.

  • Magazyn służy do utrwalania plików źródłowych przepływu monitów na potrzeby tworzenia monitów dotyczących przepływu.

  • Usługa Container Registry umożliwia tworzenie i przechowywanie obrazów kontenerów oraz artefaktów oraz zarządzanie nimi w prywatnym rejestrze dla wszystkich typów wdrożeń kontenerów. W tej architekturze przepływy są pakowane jako obrazy kontenerów i przechowywane w usłudze Container Registry.

  • 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. W tej architekturze oprócz dostępu do modelu jest ona używana do dodawania typowych funkcji przedsiębiorstwa, takich jak sieć wirtualna i link prywatny, obsługa tożsamości zarządzanej i filtrowanie zawartości.

  • Azure AI Search to usługa wyszukiwania w chmurze, która obsługuje wyszukiwanie pełnotekstowe, wyszukiwanie semantyczne, wyszukiwanie wektorowe i wyszukiwanie hybrydowe. Wyszukiwanie sztucznej inteligencji jest uwzględniane w architekturze, ponieważ jest to powszechna usługa używana w przepływach za aplikacjami do czatu. Wyszukiwanie sztucznej inteligencji może służyć do pobierania i indeksowania danych, które są istotne dla zapytań użytkowników. Przepływ monitu implementuje wzorzec generowania rozszerzonego pobierania RAG w celu wyodrębnienia odpowiedniego zapytania z monitu, zapytania dotyczącego wyszukiwania AI i użycia wyników jako danych uziemionych dla modelu usługi Azure OpenAI.

Przepływ monitów uczenia maszynowego

Zaplecze dla aplikacji do czatów dla przedsiębiorstw zwykle jest zgodne ze wzorcem podobnym do następującego przepływu:

  • Użytkownik wprowadza monit w niestandardowym interfejsie użytkownika czatu.
  • Ten monit jest wysyłany do zaplecza za pomocą kodu interfejsu.
  • Intencja użytkownika , pytanie lub dyrektywa, jest wyodrębniany z monitu przez zaplecze.
  • Opcjonalnie zaplecze określa magazyny danych, które przechowują dane istotne dla monitu użytkownika
  • Zaplecze wysyła zapytanie do odpowiednich magazynów danych.
  • Zaplecze wysyła intencję, odpowiednie dane uziemienia i dowolną historię podaną w wierszu polecenia do modelu językowego.
  • Zaplecze zwraca wynik, aby można było go wyświetlić w interfejsie użytkownika.

Zaplecze można zaimplementować w dowolnej liczbie języków i wdrożyć w różnych usługach platformy Azure. Ta architektura korzysta z przepływu monitów usługi Machine Learning, ponieważ zapewnia usprawnione środowisko do tworzenia, testowania i wdrażania przepływów, które organizują się między monitami, magazynami danych zaplecza i modelami językowymi.

Monituj środowiska uruchomieniowe przepływu

Usługa Machine Learning może bezpośrednio hostować dwa typy środowisk uruchomieniowych przepływu monitów.

  • Automatyczne środowisko uruchomieniowe: opcja obliczeniowa bezserwerowa, która zarządza charakterystyką cyklu życia i wydajności obliczeń oraz umożliwia dostosowanie sterowane przepływem środowiska.

  • Środowisko uruchomieniowe wystąpienia obliczeniowego: zawsze włączona opcja obliczeniowa, w której zespół obciążenia musi wybrać charakterystykę wydajności. To środowisko uruchomieniowe oferuje większą kontrolę nad środowiskiem i dostosowywaniem.

Przepływy monitów mogą być również hostowane poza obliczeniami usługi Machine Learning na platformach hostów kontenerów hostów. Ta architektura używa usługi App Service do zademonstrowania hostingu zewnętrznego.

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

Diagram przedstawiający kompleksową architekturę czatu podstawowego z interfejsem OpenAI z numerami przepływów.

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:

  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 z uruchomionym wdrożonym przepływem. Punkt końcowy online działa zarówno jako moduł równoważenia obciążenia, jak i router.
  3. 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.

Diagram przedstawiający użytkownika łączącego się z obszarem roboczym usługi Machine Learning za pośrednictwem pola przesiadkowego w celu utworzenia przepływu OpenAI z numerami 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 sieci wirtualnej zarządzanej przez usługę Machine Learning do usług PaaS platformy Azure

Zalecamy skonfigurowanie obszaru roboczego usługi Machine Learning pod kątem 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.

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
  • Trenowanie — nie jest używane do trenowania modelu w tej architekturze
  • 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.

Filtrowanie zawartości i monitorowanie nadużyć

Usługa Azure OpenAI zawiera system filtrowania zawartości, który używa zestawu modeli klasyfikacji do wykrywania i zapobiegania określonym kategoriom potencjalnie szkodliwej zawartości w monitach wejściowych i uzupełnianiu danych wyjściowych. Kategorie potencjalnie szkodliwej zawartości obejmują nienawiść, seksualną, samookaleczenia, przemoc, wulgaryzmy i jailbreak (zawartość przeznaczona do obejścia ograniczeń modelu językowego). Można skonfigurować ścisłość tego, co chcesz filtrować zawartość dla każdej kategorii, z opcjami niskimi, średnimi lub wysokimi. Ta architektura referencyjna przyjmuje rygorystyczne podejście. Dostosuj ustawienia zgodnie z wymaganiami.

Oprócz filtrowania zawartości usługa Azure OpenAI implementuje funkcje monitorowania nadużyć. Monitorowanie nadużyć to operacja asynchroniczna przeznaczona do wykrywania i eliminowania wystąpień cyklicznej zawartości lub zachowań, które sugerują korzystanie z usługi w sposób, który może naruszać kodeks postępowania usługi Azure OpenAI. Możesz zażądać wykluczenia monitorowania nadużyć i przeglądu przez człowieka, jeśli dane są wysoce wrażliwe lub czy istnieją wewnętrzne zasady lub obowiązujące przepisy prawne, które uniemożliwiają przetwarzanie danych w celu wykrycia nadużyć.

Niezawodność

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.

Wdrażanie przepływów monitów nie jest ograniczone do klastrów obliczeniowych usługi Machine Learning. Przepływ wykonywalny, będący 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 Functions, Azure 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 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 przedstawiający kompleksową architekturę czatu podstawowego z interfejsem OpenAI z przepływem monitu wdrożonym w usłudze App Service.

Diagram jest numerowany dla istotnych obszarów w tej architekturze:

  1. Przepływy są nadal tworzone w przepływie monitów usługi Machine Learning, a architektura sieci usługi Machine Learning pozostaje niezmieniona. Autorzy usługi Flow nadal łączą się ze środowiskiem tworzenia obszaru roboczego 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.

  2. 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.

  3. 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 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 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 Usługa Azure API Management, można wdrożyć przed usługą 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.

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.

Uczenie maszynowe — niezawodność

W przypadku wdrażania w klastrach obliczeniowych za zarządzanym przez usługę Machine Learning punktem końcowym online należy wziąć pod uwagę 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.

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.

Zabezpieczenia

Ta architektura implementuje zarówno sieć, jak i obwód zabezpieczeń tożsamości. 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.

W tej sekcji opisano zagadnienia dotyczące zarządzania tożsamościami i dostępem oraz zabezpieczeń dotyczące rotacji kluczy i dostrajania modelu Azure OpenAI.

Zarządzanie tożsamościami i dostępem

Poniższe wskazówki rozszerzają wskazówki dotyczące zarządzania tożsamościami i dostępem w punkcie odniesienia usługi App Service:

  • Utwórz oddzielne tożsamości zarządzane dla następujących zasobów usługi Machine Learning, jeśli ma to zastosowanie:
    • Obszary robocze do tworzenia przepływów i zarządzania nimi
    • Wystąpienia obliczeniowe do testowania przepływów
    • 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

Role dostępu oparte na rolach usługi Machine Learning

Istnieje pięć domyślnych ról, których można użyć do zarządzania dostępem do obszaru roboczego usługi Machine Learning: AzureML badacze dancyh, Operator obliczeniowy AzureML, Czytelnik, Współautor i Właściciel. Oprócz tych ról domyślnych istnieje czytelnik wpisów tajnych połączenia obszaru roboczego usługi AzureML Learning i użytkownik rejestru AzureML, który może udzielić dostępu do zasobów obszaru roboczego, takich jak wpisy tajne i rejestr obszaru roboczego.

Ta architektura jest zgodna z zasadą najniższych uprawnień, przypisując role tylko do poprzednich tożsamości, w których są wymagane. Rozważ następujące przypisania ról.

Tożsamość zarządzana Scope Przypisania ról
Tożsamość zarządzana obszaru roboczego Grupa zasobów Współautor
Tożsamość zarządzana obszaru roboczego Konto magazynu obszaru roboczego Współautor danych w usłudze Blob Storage
Tożsamość zarządzana obszaru roboczego Konto magazynu obszaru roboczego Uprzywilejowany współautor danych plików magazynu
Tożsamość zarządzana obszaru roboczego Magazyn kluczy obszaru roboczego Key Vault Administrator
Tożsamość zarządzana obszaru roboczego Rejestr kontenerów obszaru roboczego AcrPush
Tożsamość zarządzana punktu końcowego w trybie online Rejestr kontenerów obszaru roboczego AcrPull
Tożsamość zarządzana punktu końcowego w trybie online Konto magazynu obszaru roboczego Czytelnik danych obiektu BLOB usługi Storage
Tożsamość zarządzana punktu końcowego w trybie online Obszar roboczy usługi Machine Learning Czytelnik wpisów tajnych połączenia obszaru roboczego usługi AzureML
Tożsamość zarządzana wystąpienia obliczeniowego Rejestr kontenerów obszaru roboczego AcrPull
Tożsamość zarządzana wystąpienia obliczeniowego Konto magazynu obszaru roboczego Czytelnik danych obiektu BLOB usługi Storage

Wymiana kluczy

W tej architekturze istnieją dwie usługi korzystające z uwierzytelniania opartego na kluczach: Azure OpenAI i zarządzany przez usługę Machine Learning punkt końcowy online. Ponieważ używasz uwierzytelniania opartego na kluczach dla tych usług, 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ł obrócony.

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.

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 tym scenariuszu 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 usługi Machine Learning 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 przedstawia 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.

Machine Learning — wbudowane środowiska uruchomieniowe przepływu monitów

Aby zminimalizować obciążenie operacyjne, automatyczne środowisko uruchomieniowe jest opcją obliczeniową bezserwerową 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

Diagnostyka jest skonfigurowana dla wszystkich usług. Wszystkie usługi, ale usługi Machine Learning i App Service są skonfigurowane do przechwytywania wszystkich dzienników. Diagnostyka usługi Machine Learning jest skonfigurowana do przechwytywania dzienników inspekcji, które są wszystkimi dziennikami zasobów rejestrujących interakcje klientów z danymi lub ustawieniami usługi. Usługa App Service jest skonfigurowana do przechwytywania dzienników AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs i AppServicePlatformLogs.

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:

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 LLMOps z przepływem monitów za pomocą usług Azure DevOps i 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 metodyki LLMOps. 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 uczenia maszynowego oferuje zarówno środowisko tworzenia oparte na przeglądarce w usłudze Machine Learning Studio, jak i za pośrednictwem rozszerzenia programu Visual Studio Code. Obie opcje przechowują kod przepływu jako pliki. W przypadku korzystania z usługi Machine Learning Studio pliki są przechowywane na koncie magazynu. 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

Diagram przedstawiający przepływ wdrażania dla przepływu monitu.

  1. 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.

  2. 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
  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, 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.

  4. Scalanie z main wyzwala proces kompilacji i wydania dla środowiska deweloperskiego. Szczególnie:

    1. 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
    1. 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
  5. 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.

  6. 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.

  7. 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.

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.

Efektywność wydajności

Wydajność to możliwość wydajnego skalowania obciążenia w celu spełnienia wymagań, które są na nim nakładane przez 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 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.

Następny krok