Základní referenční architektura pro chat OpenAI

Podnikové chatovací aplikace můžou zaměstnancům umožnit konverzační interakci. To platí zejména z důvodu průběžného pokroku jazykových modelů, jako jsou modely GPT od OpenAI a modely LLaMA Meta. Tyto chatovací aplikace se skládají z uživatelského rozhraní chatu (UI), úložišť dat, která obsahují informace specifické pro doménu související s dotazy uživatele, jazykové modely, které zdůvodní data specifická pro doménu, aby vytvořily relevantní odpověď, a orchestrátor, který dohlíží na interakci mezi těmito komponentami.

Tento článek obsahuje základní architekturu pro sestavování a nasazování podnikových chatovacích aplikací, které používají jazykové modely azure OpenAI Service. Architektura využívá tok výzvy k vytvoření spustitelných toků. Tyto spustitelné toky orchestrují pracovní postup z příchozích výzev k ukládání dat, aby se načítá základní data pro jazykové modely a další požadovaná logika Pythonu. Spustitelný tok se nasadí do spravovaného online koncového bodu se spravovanými výpočetními prostředky.

Hostování vlastního uživatelského rozhraní chatu (UI) se řídí základními pokyny webových aplikací aplikačních služeb pro nasazení zabezpečené, zónově redundantní a vysoce dostupné webové aplikace ve službě Aplikace Azure Service. V této architektuře služba App Service komunikuje s řešením Azure Platforma jako služba (PaaS) prostřednictvím integrace virtuální sítě přes privátní koncové body. App Service chatového uživatelského rozhraní komunikuje se spravovaným online koncovým bodem pro tok přes privátní koncový bod. Veřejný přístup k Azure AI Studiu je zakázaný.

Centrum Azure AI Studio je nakonfigurované s izolací spravované virtuální sítě, která vyžaduje schválení všech odchozích připojení. Díky této konfiguraci se vytvoří spravovaná virtuální síť spolu se spravovanými privátními koncovými body, které umožňují připojení k privátním prostředkům, jako je azure Storage na pracovišti, Azure Container Registry a Azure OpenAI. Tato privátní připojení se používají při vytváření a testování toků a toky nasazené do výpočetních prostředků Machine Learning.

Centrum je prostředek Azure AI Studio nejvyšší úrovně, který poskytuje centrální způsob řízení zabezpečení, připojení a dalších problémů napříč několika projekty. Tato architektura vyžaduje pouze jeden projekt pro svou úlohu. Pokud máte další prostředí, která vyžadují různé toky výzvy s jinou logikou, potenciálně s využitím různých back-endových prostředků, jako jsou úložiště dat, můžete zvážit jejich implementaci v jiném projektu.

Architektura

Stáhněte si soubor aplikace Visio s touto architekturou.

Komponenty

Řada komponent této architektury je stejná jako základní komplexní architektura chatu Azure OpenAI. Následující seznam zvýrazňuje pouze změny základní architektury.

• Azure OpenAI se používá v základní i této základní architektuře. Azure OpenAI je plně spravovaná služba, která poskytuje rozhraní REST API přístup k jazykovým modelům Azure OpenAI, včetně sady modelů GPT-4, GPT-3.5-Turbo a vkládání. Základní architektura využívá podnikové funkce, jako jsou virtuální síť a privátní propojení , které základní architektura neimplementuje.
• Azure AI Studio je platforma, pomocí které můžete vytvářet, testovat a nasazovat řešení AI. AI Studio se v této architektuře používá k sestavení, testování a nasazení logiky orchestrace toku výzvy pro chatovací aplikaci. V této architektuře poskytuje Azure AI Studio spravovanou virtuální síť pro zabezpečení sítě. Další informace najdete v části Sítě, kde najdete další podrobnosti.
• Application Gateway je nástroj pro vyrovnávání zatížení vrstvy 7 (HTTP/S) a směrovač webového provozu. Používá směrování založené na cestě URL k distribuci příchozího provozu mezi zóny dostupnosti a šifrování přesměrování zátěže, aby se zlepšil výkon aplikace.
• Firewall webových aplikací (WAF) je cloudová nativní služba, která chrání webové aplikace před běžnými zneužitími, jako je injektáž SQL a skriptování mezi weby. Firewall webových aplikací poskytuje přehled o provozu do a z vaší webové aplikace a umožňuje monitorovat a zabezpečit aplikaci.
• Azure Key Vault je služba, která bezpečně ukládá a spravuje tajné kódy, šifrovací klíče a certifikáty. Centralizuje správu citlivých informací.
• Virtuální síť Azure je služba, která umožňuje vytvářet izolované a zabezpečené privátní virtuální sítě v Azure. Pro webovou aplikaci ve službě App Service potřebujete podsíť virtuální sítě, která bude používat privátní koncové body pro zabezpečenou síťovou komunikaci mezi prostředky.
• Private Link umožňuje klientům přistupovat ke službám Azure jako služby jako služby (PaaS) přímo z privátních virtuálních sítí bez použití přidělování veřejných IP adres.
• Azure DNS je hostitelská služba pro domény DNS, která poskytuje překlad názvů pomocí infrastruktury Microsoft Azure. Privátní DNS zóny poskytují způsob, jak mapovat plně kvalifikovaný název domény (FQDN) služby na IP adresu privátního koncového bodu.

Alternativy

Tato architektura má několik komponent, které by mohly obsluhovat jiné služby Azure, které by mohly lépe odpovídat vašim funkčním a nefunkčním požadavkům vaší úlohy. Tady je několik takových alternativ, o které byste měli vědět.

Pracovní prostory služby Azure Machine Learning (a prostředí portálu)

Tato architektura používá Azure AI Studio k vytváření, testování a nasazování toků výzvy. Případně můžete použít pracovní prostory Služby Azure Machine Learning, protože obě služby mají překrývající se funkce. I když je AI Studio dobrou volbou, pokud navrhujete řešení toku výzvy, existují některé funkce, pro které má Azure Machine Learning aktuálně lepší podporu. Další informace najdete v porovnání funkcí. Doporučujeme nekombinovat a spárovat Azure AI Studio a Azure Machine Learning. Pokud se vaše práce dá udělat úplně v AI Studiu, použijte AI Studio. Pokud stále potřebujete funkce z studio Azure Machine Learning, pokračujte v používání studio Azure Machine Learning.

Komponenty aplikační vrstvy

V Azure je k dispozici několik nabídek spravovaných aplikačních služeb, které můžou sloužit jako aplikační vrstva pro front-end uživatelského rozhraní chatu. Viz Volba výpočetní služby Azure pro všechny výpočetní prostředky a volba služby kontejneru Azure pro řešení kontejnerů. Například když byly pro rozhraní API pro uživatelské rozhraní chatu i hostiteli toku výzvy vybrány azure Web Apps a Web App for Containers, bylo možné dosáhnout podobných výsledků pomocí služby Azure Kubernetes Service (AKS) nebo Azure Container Apps. Zvolte aplikační platformu vaší úlohy na základě konkrétních funkčních a nefunkčních požadavků úlohy.

Hostování toku výzvy

Nasazení toků výzvy není omezené na výpočetní clustery Machine Learning a tato architektura ukazuje, že s alternativou ve službě Aplikace Azure Service. Toky jsou nakonec kontejnerizovaná aplikace, kterou je možné nasadit do jakékoli služby Azure, která je kompatibilní s kontejnery. Mezi tyto možnosti patří služby, jako je Azure Kubernetes Service (AKS), Azure Container Apps a Aplikace Azure Service. Zvolte službu kontejneru Azure na základě požadavků vaší vrstvy orchestrace.

Příkladem toho, proč hostování toku výzvy k hostování na alternativním výpočetním prostředí je potřeba zvážit dále v tomto článku.

Uzemnění úložiště dat

I když tato architektura vede službou Azure AI Search, vaše volba úložiště dat pro základní data je rozhodnutí o architektuře specifické pro vaši úlohu. Mnoho úloh je ve skutečnosti polyglot a má různorodé zdroje a technologie pro zemnění dat. Tyto datové platformy se liší od existujících úložišť dat OLTP, cloudových nativních databází, jako je Azure Cosmos DB, prostřednictvím specializovaných řešení, jako je Azure AI Search. Běžným, ale nikoli povinným, charakteristickým znakem takového úložiště dat je vektorové vyhledávání. Možnosti v tomto prostoru můžete prozkoumat v části Volba služby Azure pro vektorové vyhledávání .

Důležité informace a doporučení

Spolehlivost

Spolehlivost zajišťuje, že vaše aplikace může splňovat závazky, které uděláte pro vaše zákazníky. Další informace najdete v kontrolním seznamu pro kontrolu návrhu pro spolehlivost.

Základní architektura webových aplikací služby App Service se zaměřuje na zónovou redundanci klíčových regionálních služeb. Zóny dostupnosti jsou fyzicky oddělená umístění v rámci oblasti. Poskytují redundanci v rámci oblasti pro podpůrné služby, když jsou v nich nasazeny dvě nebo více instancí. Pokud dojde k výpadku jedné zóny, ostatní zóny v této oblasti můžou být stále nedotknuty. Architektura také zajišťuje dostatek instancí služeb Azure a konfigurace těchto služeb, které se mají rozložit mezi zóny dostupnosti. Další informace najdete ve směrném plánu a projděte si uvedené pokyny.

Tato část se zabývá spolehlivostí z pohledu komponent v této architektuře, které nejsou vyřešené ve standardních hodnotách služby App Service, včetně Machine Learning, Azure OpenAI a AI Search.

Zónová redundance pro nasazení toků

Podniková nasazení obvykle vyžadují zónovou redundanci. Pokud chcete dosáhnout zónové redundance v Azure, prostředky musí podporovat zóny dostupnosti a musíte nasadit aspoň tři instance prostředku nebo povolit podporu platformy, pokud není řízení instancí dostupné. Výpočetní prostředí Machine Learning v současné době nenabízí podporu zón dostupnosti. Pokud chcete zmírnit potenciální dopad katastrofy na úrovni datacentra na komponenty strojového učení, je nutné vytvořit clustery v různých oblastech a nasadit nástroj pro vyrovnávání zatížení pro distribuci volání mezi tyto clustery. Pomocí kontrol stavu můžete zajistit, aby volání byla směrována pouze do clusterů, které fungují správně.

Existují některé alternativy k výpočetním clusterům Machine Learning, jako je Azure Kubernetes Service (AKS), Azure Functions, Azure Container Apps a Aplikace Azure Service. Každá z těchto služeb podporuje zóny dostupnosti. Pokud chcete dosáhnout zónové redundance pro provádění toku výzvy bez větší složitosti nasazení ve více oblastech, měli byste své toky nasadit do jedné z těchto služeb.

Následující diagram znázorňuje alternativní architekturu, ve které jsou do služby App Service nasazené toky výzvy. Služba App Service se používá v této architektuře, protože úloha ji už používá pro uživatelské rozhraní chatu a neměla by prospěch z zavedení nové technologie do úlohy. Týmy úloh, které mají zkušenosti s AKS, by měly zvážit nasazení v daném prostředí, zejména pokud se AKS používá pro jiné komponenty v úloze.

Diagram je číslovaný pro oblasti v této architektuře:

1. Toky jsou stále vytvořené v toku výzvy a síťová architektura se nezmění. Autoři toku se stále připojují k prostředí pro vytváření v projektu AI Studio prostřednictvím privátního koncového bodu a spravované privátní koncové body se používají k připojení ke službám Azure při testování toků.

2. Tato tečkovaná čára označuje, že kontejnerizované spustitelné toky se odsílají do služby Container Registry. V diagramu se nezobrazují kanály, které kontejnerizují toky a nasdílejí je do služby Container Registry. Výpočetní prostředky, ve kterých se tyto kanály spouštějí, musí mít přehled o síti pro prostředky, jako je registr kontejnerů Azure a projekt AI Studio.

3. Do stejného plánu služby App Service, který už hostuje uživatelské rozhraní chatu, je nasazená jiná webová aplikace. Nová webová aplikace hostuje kontejnerizovaný tok výzvy, který je společně přidělený do stejného plánu služby App Service, který už běží minimálně tři instance, rozložené mezi zóny dostupnosti. Tyto instance služby App Service se při načítání image kontejneru toku výzvy připojují ke službě Container Registry přes privátní koncový bod.

4. Kontejner toku výzvy se musí připojit ke všem závislým službám pro spuštění toku. V této architektuře se kontejner toku výzvy připojí ke službě AI Search a Azure OpenAI. Služby PaaS, které byly vystaveny pouze podsíti privátního koncového bodu spravované službou Machine Learning, je teď potřeba zpřístupnit také ve virtuální síti, aby bylo možné z App Service navázat dohled.

Azure OpenAI – Spolehlivost

Azure OpenAI v současné době nepodporuje zóny dostupnosti. Pokud chcete zmírnit potenciální dopad katastrofy na úrovni datacentra na nasazení modelu v Azure OpenAI, je potřeba nasadit Azure OpenAI do různých oblastí spolu s nasazením nástroje pro vyrovnávání zatížení za účelem distribuce volání mezi oblasti. Pomocí kontrol stavu můžete zajistit, aby volání byla směrována pouze do clusterů, které fungují správně.

Pokud chcete efektivně podporovat více instancí, doporučujeme externě vyladit soubory, jako je například geograficky redundantní účet úložiště. Tento přístup minimalizuje stav uložený v Azure OpenAI pro každou oblast. Pro každou instanci musíte dál vyladit soubory pro hostování nasazení modelu.

Je důležité monitorovat požadovanou propustnost z hlediska tokenů za minutu (TPM) a požadavků za minutu (RPM). Ujistěte se, že dostatek čipu TPM přiřazeného z vaší kvóty pro splnění poptávky po nasazeních a zabrání omezování volání nasazených modelů. Bránu, jako je Azure API Management, je možné nasadit před službu Nebo služby Azure OpenAI a je možné ji nakonfigurovat pro opakování, pokud dojde k přechodným chybám a omezování. Api Management se dá použít také jako jistič , aby se služba nemohla zahltit voláním a překročila kvótu. Další informace o přidání brány kvůli obavám o spolehlivost najdete v tématu Přístup k Azure OpenAI a dalším jazykovým modelům prostřednictvím brány.

Vyhledávání AI – spolehlivost

Nasaďte službu AI Search s cenovou úrovní Standard nebo vyšší v oblasti, která podporuje zóny dostupnosti, a nasaďte tři nebo více replik. Repliky se automaticky rozprostírají rovnoměrně mezi zóny dostupnosti.

Při určování vhodného počtu replik a oddílů zvažte následující doprovodné materiály:

• Monitorování vyhledávání AI

• Pomocí monitorování metrik a protokolů a analýzy výkonu určete odpovídající počet replik, abyste se vyhnuli omezování na základě dotazů a oddílů a vyhnuli se omezování na základě indexu.

Azure AI Studio – spolehlivost

Pokud nasadíte do výpočetních clusterů za spravovaným online koncovým bodem služby Machine Learning, zvažte následující doprovodné materiály týkající se škálování:

• Automaticky škálujte své online koncové body , abyste zajistili, že je k dispozici dostatek kapacity pro splnění poptávky. Pokud signály využití nejsou dostatečně včasné kvůli nárůstu využití, zvažte nadměrné zřízení, abyste zabránili dopadu na spolehlivost z příliš málo dostupných instancí.

• Zvažte vytvoření pravidel škálování na základě metrik nasazení, jako je zatížení procesoru a metriky koncových bodů, jako je latence požadavků.

• Pro aktivní produkční nasazení by se neměly nasazovat méně než tři instance.

• Vyhněte se nasazení instancím v použití. Místo toho se nasadí do nového nasazení a přesun provozu po nasazení bude připravený přijímat provoz.

Spravované online koncové body fungují jako nástroj pro vyrovnávání zatížení a směrovač pro spravované výpočetní prostředky spuštěné za nimi. Můžete nakonfigurovat procento provozu, které by se mělo směrovat do každého nasazení, pokud se procento přidá až na 100 %. Můžete také nasadit spravovaný online koncový bod s 0% provozem směrovaným na jakékoli nasazení. Pokud jako v zadané referenční implementaci používáte infrastrukturu jako kód (IaC) k nasazení prostředků, včetně spravovaných online koncových bodů, je potřeba se obávat spolehlivosti. Pokud máte provoz nakonfigurovaný tak, aby směroval na nasazení (vytvořený prostřednictvím rozhraní příkazového řádku nebo Azure AI Studia) a provedli jste následné nasazení IaC, které zahrnuje spravovaný online koncový bod, i když neaktualizuje spravovaný online koncový bod žádným způsobem, přenosy koncových bodů se vrátí ke směrování 0% provozu. To znamená, že nasazené toky výzvy už nebudou dostupné, dokud neupravíte provoz zpět na požadované místo.

Návrh více oblastí

Tato architektura není vytvořená jako regionální razítko v architektuře s více oblastmi. Poskytuje vysokou dostupnost v rámci jedné oblasti kvůli úplnému využití zón dostupnosti, ale nemá některé klíčové komponenty, které by to skutečně připravilo na řešení s více oblastmi. Tady jsou některé komponenty nebo aspekty, které v této architektuře chybí:

• Globální příchozí přenos dat a směrování
• Strategie správy DNS
• Strategie replikace dat (nebo izolace)
• Označení aktivní-aktivní, aktivní-pasivní nebo aktivní-studená
• Strategie převzetí služeb při selhání a navrácení služeb po obnovení pro dosažení rto a cíle bodu obnovení vaší úlohy
• Rozhodnutí ohledně dostupnosti oblastí pro prostředí pro vývojáře v prostředku centra Azure Studio

Pokud požadavky vaší úlohy vyžadují strategii pro více oblastí, musíte investovat do dalšího návrhu komponent a provozních procesů nad rámec toho, co je v této architektuře prezentováno. Navrhujete podporu vyrovnávání zatížení nebo převzetí služeb při selhání v následujících vrstvách:

• Uzemnění dat
• Hosting modelu
• Vrstva orchestrace (tok výzvy v této architektuře)
• Uživatelské rozhraní s klientským rozhraním

Kromě toho budete potřebovat udržovat kontinuitu podnikových procesů v pozorovatelnosti, prostředí portálu a zodpovědné obavy ohledně umělé inteligence, jako je bezpečnost obsahu.

Zabezpečení

Zabezpečení poskytuje záruky proti záměrným útokům a zneužití cenných dat a systémů. Další informace najdete v kontrolním seznamu pro kontrolu návrhu zabezpečení.

Tato architektura rozšiřuje nároky na zabezpečení implementované v kompletním chatu Basic s architekturou Azure OpenAI. I když základní architektura používá spravované identity přiřazené systémem a přiřazení rolí přiřazených systémem, tato architektura používá identity přiřazené uživatelem s ručně vytvořenými přiřazeními rolí.

Architektura implementuje hraniční síť spolu s hraniční sítí implementovanou v základní architektuře. Z hlediska sítě je jediná věc, která by měla být přístupná z internetu, je uživatelské rozhraní chatu přes Application Gateway. Z hlediska identity by mělo uživatelské rozhraní chatu ověřovat a autorizovat žádosti. Spravované identity se používají, pokud je to možné, k ověřování aplikací ve službách Azure.

Tato část popisuje také aspekty zabezpečení pro obměnu klíčů a jemné ladění modelu Azure OpenAI.

Správa identit a přístupu

Při používání spravovaných identit přiřazených uživatelem zvažte následující doprovodné materiály:

• Pokud je to možné, vytvořte samostatné spravované identity pro následující prostředky Azure AI Studio a Machine Learning:
  • Centrum AI Studio
  • Projekty AI Studio pro vytváření a správu toků
  • Online koncové body v nasazené toku, pokud je tok nasazený do spravovaného online koncového bodu
• Implementace řízení přístupu identit pro uživatelské rozhraní chatu pomocí Id Microsoft Entra

Vytvořte samostatné projekty a online koncové body pro různé toky výzev, které chcete izolovat od ostatních z hlediska oprávnění. Vytvořte samostatnou spravovanou identitu pro každý projekt a spravovaný online koncový bod. Dejte autorům toku výzvy přístup jenom k projektům, které vyžadují.

Když nasadíte uživatele do projektů Azure AI Studio, abyste mohli provádět funkce, jako jsou toky vytváření, musíte přiřazovat role s nejnižšími oprávněními prostředky, které vyžadují.

Role přístupu na základě role ve službě Machine Learning

Stejně jako v základní architektuře systém automaticky vytvoří přiřazení rolí pro spravované identity přiřazené systémem. Protože systém neví, jaké funkce centra a projektů můžete použít, vytvoří přiřazení rolí podporu všech potenciálních funkcí. Automaticky vytvořená přiřazení rolí můžou na základě vašeho případu použití přecházet nad oprávněními zřizování. Příkladem je role Přispěvatel přiřazená k centru registru kontejneru, kde pravděpodobně vyžaduje přístup čtenáře pouze k řídicí rovině. Pokud potřebujete omezit oprávnění dále pro cíle s nejnižšími oprávněními, musíte použít identity přiřazené uživatelem. Tato přiřazení rolí vytvoříte a budete udržovat sami.

Vzhledem k zatížení údržby při správě všech požadovaných přiřazení tato architektura upřednostňuje efektivitu provozu oproti absolutním přiřazením rolí s nejnižšími oprávněními. Všimněte si, že musíte provést všechna přiřazení uvedená v tabulce.

Spravovaná identita	Obor	Přiřazení rolí
Spravovaná identita centra	Přispěvatel	Skupina prostředků
Spravovaná identita centra	Centrum	Správce Azure AI
Spravovaná identita centra	Container Registry	Přispěvatel
Spravovaná identita centra	Key Vault	Přispěvatel
Spravovaná identita centra	Key Vault	Správce
Spravovaná identita centra	Účet úložiště	Čtenář
Spravovaná identita centra	Účet úložiště	Přispěvatel účtu úložiště
Spravovaná identita centra	Účet úložiště	Přispěvatel dat objektů blob úložiště
Spravovaná identita centra	Účet úložiště	Přispěvatel dat souboru úložiště s privilegovaným přístupem
Spravovaná identita centra	Účet úložiště	Přispěvatel dat v tabulce úložiště
Spravovaná identita projektu	Projekt	Správce Azure AI
Spravovaná identita projektu	Container Registry	Přispěvatel
Spravovaná identita projektu	Key Vault	Přispěvatel
Spravovaná identita projektu	Key Vault	Správce
Spravovaná identita projektu	Účet úložiště	Čtenář
Spravovaná identita projektu	Účet úložiště	Přispěvatel účtu úložiště
Spravovaná identita projektu	Účet úložiště	Přispěvatel dat objektů blob úložiště
Spravovaná identita projektu	Účet úložiště	Přispěvatel dat souboru úložiště s privilegovaným přístupem
Spravovaná identita projektu	Účet úložiště	Přispěvatel dat v tabulce úložiště
Spravovaná identita online koncového bodu	Projekt	Tajné kódy připojení pracovního prostoru Azure Machine Learning
Spravovaná identita online koncového bodu	Projekt	Zapisovač metrik AzureML
Spravovaná identita online koncového bodu	Container Registry	ACRPull
Spravovaná identita online koncového bodu	Azure OpenAI	Uživatel Cognitive Services OpenAI
Spravovaná identita online koncového bodu	Účet úložiště	Přispěvatel dat objektů blob úložiště
Spravovaná identita online koncového bodu	Účet úložiště	Čtenář dat v objektech blob služby Storage
App Service (při nasazení toku výzvy do app Service)	Azure OpenAI	Uživatel Cognitive Services OpenAI
Uživatel portálu (výzva k vývoji toku)	Azure OpenAI	Uživatel Cognitive Services OpenAI
Uživatel portálu (výzva k vývoji toku)	Účet úložiště	Přispěvatel dat objektů blob služby Storage (použití podmíněného přístupu)
Uživatel portálu (výzva k vývoji toku)	Účet úložiště	Přispěvatel dat souboru úložiště s privilegovaným přístupem

Je důležité si uvědomit, že centrum AI Studio má prostředky Azure, které jsou sdílené napříč projekty, jako je účet úložiště a Container Registry. Pokud máte uživatele, kteří potřebují přístup jenom k podmnožině projektů, zvažte použití podmínek přiřazení rolí pro služby Azure, které je podporují, a poskytněte tak přístup k prostředkům s nejnižšími oprávněními. Například objekty blob ve službě Azure Storage podporují podmínky přiřazení rolí. Pro uživatele, který vyžaduje přístup k podmnožině projektů, místo přiřazování oprávnění pro jednotlivé kontejnery použijte podmínky přístupu role k omezení oprávnění na kontejnery objektů blob používané těmito projekty. Každý projekt má jedinečný identifikátor GUID, který slouží jako předpona pro názvy kontejnerů objektů blob použitých v daném projektu. Tento identifikátor GUID lze použít jako součást podmínek přiřazení role.

Centrum musí mít Contributor přístup ke skupině prostředků centra, aby bylo možné vytvořit a spravovat prostředky centra a projektu. Vedlejší účinek, který má centrum přístup k řídicí rovině ke všem prostředkům také ve skupině prostředků. Všechny prostředky Azure, které přímo nesouvisí s centrem a jejími projekty, by se měly vytvářet v samostatné skupině prostředků. Doporučujeme vytvořit minimálně dvě skupiny prostředků pro tým úloh pomocí samoobslužného centra Azure AI Studio Hub. Jedna skupina prostředků, která bude obsahovat centrum, jeho projekty a všechny jeho přímé závislosti, jako je registr kontejnerů Azure, Key Vault atd. Jedna skupina prostředků, která bude obsahovat všechno ostatní ve vaší úloze.

Doporučujeme minimalizovat používání prostředků Azure potřebných pro operaci centra (Container Registry, Účet úložiště, Key Vault, Application Insights) jinými komponentami ve vašich úlohách. Pokud například potřebujete ukládat tajné kódy jako součást úlohy, měli byste vytvořit samostatný trezor klíčů kromě trezoru klíčů přidruženého k centru. Služba Key Vault centra by měla používat pouze k ukládání tajných kódů centra a projektu.

Zajistěte, aby pro každý samostatný projekt přiřazení rolí pro jeho závislosti neposkytovala přístup k prostředkům, které uživatel portálu a spravovaná online spravovaná identita koncového bodu nevyžadují. Například Cognitive Services OpenAI User přiřazení role k Azure OpenAI uděluje přístup ke všem nasazením pro daný prostředek. Neexistuje žádný způsob, jak omezit autory toků nebo spravované online identity spravovaných koncovým bodem s přístupem k přiřazení rolí ke konkrétním nasazením modelu v Azure OpenAI. V takových scénářích je v našich doprovodných materiálech nasazení služeb, jako jsou Azure OpenAI a Azure AI Search, na základě jednotlivých projektů a nenasazování prostředků do služeb, ke kterým by autoři toku nebo spravované identity spravované online koncové body neměli mít přístup. Například nasaďte modely pouze do instance Azure OpenAI projektu, ke které projekt vyžaduje přístup. Nasaďte indexy pouze do instance Azure AI Search projektu, ke které by měl mít projekt přístup.

Sítě

Spolu s přístupem založeným na identitě je zabezpečení sítě jádrem základní komplexní architektury chatu, která používá OpenAI. Z vysoké úrovně zajišťuje síťová architektura následující:

• Pouze jeden zabezpečený vstupní bod pro přenosy uživatelského rozhraní chatu.
• Síťový provoz se filtruje.
• Přenášená data jsou zašifrovaná kompletní pomocí protokolu TLS (Transport Layer Security).
• Exfiltrace dat se minimalizuje pomocí služby Private Link, která udržuje provoz v Azure.
• Síťové prostředky jsou logicky seskupené a izolované od sebe prostřednictvím segmentace sítě.

Toky sítě

Dva toky v tomto diagramu jsou popsané v základní architektuře webové aplikace App Service: příchozí tok od koncového uživatele do uživatelského rozhraní chatu (1) a tok ze služby App Service do služeb Azure PaaS (2). Tato část se zaměřuje na tok online koncového bodu služby Machine Learning. Následující tok pochází z uživatelského rozhraní chatu, které běží v základní webové aplikaci App Service, do toku nasazeného do služby Machine Learning compute:

1. Volání z uživatelského rozhraní chatu hostovaného službou App Service se směruje přes privátní koncový bod do online koncového bodu služby Machine Learning.
2. Online koncový bod směruje volání na server, na kterém běží nasazený tok. Online koncový bod funguje jako nástroj pro vyrovnávání zatížení i směrovač.
3. Volání služeb Azure PaaS vyžadovaných nasazeným tokem se směrují přes spravované privátní koncové body.

Příchozí přenos dat do služby Machine Learning

V této architektuře je veřejný přístup k pracovnímu prostoru Machine Learning zakázaný. Uživatelé mají přístup k pracovnímu prostoru prostřednictvím privátního přístupu, protože architektura se řídí privátním koncovým bodem konfigurace pracovního prostoru Machine Learning. Privátní koncové body se ve skutečnosti používají v celé této architektuře k doplnění zabezpečení založeného na identitách. Například vaše uživatelské rozhraní chatu hostované službou App Service se může připojit ke službám PaaS, které nejsou vystavené veřejnému internetu, včetně koncových bodů služby Machine Learning.

Pro připojení k pracovnímu prostoru Machine Learning pro vytváření toků se vyžaduje také přístup k privátnímu koncovému bodu.

Diagram znázorňuje autora toku výzvy, který se připojuje přes Azure Bastion k jump boxu virtuálního počítače. Z tohoto jump boxu se autor může připojit k pracovnímu prostoru Machine Learning prostřednictvím privátního koncového bodu ve stejné síti jako jump box. Připojení k virtuální síti je také možné provést prostřednictvím bran ExpressRoute nebo bran VPN a partnerského vztahu virtuálních sítí.

Tok ze spravované virtuální sítě Azure AI Studio do služeb Azure PaaS

Doporučujeme nakonfigurovat centrum Azure AI Studio pro izolaci spravované virtuální sítě, které vyžaduje schválení všech odchozích připojení. Tato architektura se řídí tímto doporučením. Existují dva typy schválených pravidel odchozích přenosů. Požadovaná pravidla odchozích přenosů jsou pro prostředky potřebné pro fungování řešení, jako je Container Registry a Storage. Pravidla odchozích přenosů definovaná uživatelem se vztahují na vlastní prostředky, jako je Azure OpenAI nebo AI Search, které bude váš pracovní postup používat. Musíte nakonfigurovat pravidla odchozích přenosů definovaná uživatelem. Požadovaná odchozí pravidla se konfigurují při vytvoření spravované virtuální sítě. Spravovaná virtuální síť se nasadí na vyžádání při prvním použití a od tého dne zůstane trvalá.

Odchozí pravidla můžou být privátní koncové body, značky služeb nebo plně kvalifikované názvy domén (FQDN) pro externí veřejné koncové body. V této architektuře se připojení ke službám Azure, jako je Container Registry, Storage, Azure Key Vault, Azure OpenAI a AI Search, připojí prostřednictvím privátního propojení. I když ne v této architektuře, některé běžné operace, které můžou vyžadovat konfiguraci odchozího pravidla plně kvalifikovaného názvu domény, stahují balíček pip, klonují úložiště GitHub nebo stahují image základního kontejneru z externích úložišť.

Segmentace a zabezpečení virtuální sítě

Síť v této architektuře má samostatné podsítě pro následující účely:

• Application Gateway

• Integrační komponenty služby App Service

• Privátní koncové body

• Azure Bastion

• Virtuální počítač jump boxu

• Trénovací a bodovací podsítě – obě tyto podsítě slouží k používání vlastních výpočetních prostředků souvisejících s trénováním a odvozováním. V této architektuře neprovádíme trénování a používáme spravované výpočetní prostředky.

• Vyhodnocování

Každá podsíť má skupinu zabezpečení sítě (NSG), která omezuje příchozí i odchozí provoz pro tyto podsítě jenom na to, co je potřeba. Následující tabulka ukazuje zjednodušené zobrazení pravidel NSG, která směrný plán přidá do každé podsítě. Tabulka obsahuje název pravidla a funkci.

Podsíť	Příchozí	Odchozí
snet-appGateway	Příspěvky pro zdrojové IP adresy uživatelů chatovacího uživatelského rozhraní (například veřejný internet) a požadované položky pro službu.	Přístup k privátnímu koncovému bodu služby App Service a k požadovaným položkám pro službu.
snet-PrivateEndpoints	Povolte pouze provoz z virtuální sítě.	Povolte pouze provoz do virtuální sítě.
snet-AppService	Povolte pouze provoz z virtuální sítě.	Povolte přístup k privátním koncovým bodům a Azure Monitoru.
AzureBastionSubnet	Přečtěte si pokyny k práci s přístupem k NSG a službě Azure Bastion.	Přečtěte si pokyny k práci s přístupem k NSG a službě Azure Bastion.
snet-jumpbox	Povolte příchozí protokol RDP (Remote Desktop Protocol) a SSH z podsítě hostitele služby Azure Bastion.	Povolení přístupu k privátním koncovým bodům
snet-agents	Povolte pouze provoz z virtuální sítě.	Povolte pouze provoz do virtuální sítě.
snet-training	Povolte pouze provoz z virtuální sítě.	Povolte pouze provoz do virtuální sítě.
bodování sítě	Povolte pouze provoz z virtuální sítě.	Povolte pouze provoz do virtuální sítě.

Veškerý ostatní provoz je explicitně odepřen.

Při implementaci segmentace a zabezpečení virtuální sítě zvažte následující body.

• Povolte službu DDoS Protection pro virtuální síť s podsítí, která je součástí aplikační brány s veřejnou IP adresou.

• Pokud je to možné, přidejte skupinu zabezpečení sítě do každé podsítě. Použijte nejskutežnější pravidla, která umožňují plnou funkčnost řešení.

• Skupiny zabezpečení aplikace slouží k seskupení skupin zabezpečení sítě. Seskupení skupin zabezpečení sítě usnadňuje vytváření pravidel pro složitá prostředí.

Obměna klíčů

V této architektuře je jedna služba, která používá ověřování založené na klíčích: koncový bod spravovaný online službou Machine Learning. Vzhledem k tomu, že pro tuto službu používáte ověřování založené na klíčích, je důležité:

• Uložte klíč do zabezpečeného úložiště, jako je Key Vault, pro přístup na vyžádání od autorizovaných klientů, jako je například Azure Web App hostující kontejner toku výzvy.

• Implementujte strategii obměně klíčů. Pokud klíče ručně otočíte, vytvořte zásadu vypršení platnosti klíče a pomocí služby Azure Policy sledujte, jestli se klíč otočil.

Vyladění modelu OpenAI

Pokud v implementaci doladíte modely OpenAI, zvažte následující doprovodné materiály:

• Pokud nahrajete trénovací data pro vyladění, zvažte použití klíčů spravovaných zákazníkem pro šifrování dat.

• Pokud ukládáte trénovací data do úložiště, jako je Azure Blob Storage, zvažte použití klíče spravovaného zákazníkem pro šifrování dat, spravované identity k řízení přístupu k datům a privátního koncového bodu pro připojení k datům.

Zásady správného řízení prostřednictvím zásad

Pokud chcete zajistit soulad se zabezpečením, zvažte použití Zásad Azure a zásad sítě, aby nasazení odpovídala požadavkům úlohy. Použití automatizace platforem prostřednictvím zásad snižuje zátěž ručních kroků ověřování a zajišťuje zásady správného řízení i v případě, že jsou kanály vynechány. Zvažte následující zásady zabezpečení:

• Zakažte klíč nebo jiný místní přístup k ověřování ve službách, jako jsou služby Azure AI a Key Vault.
• Vyžaduje specifickou konfiguraci pravidel síťového přístupu nebo skupin zabezpečení sítě.
• Vyžadovat šifrování, například použití klíčů spravovaných zákazníkem.

Přiřazení rolí Azure AI Studio pro Azure Key Vault

Spravovaná identita Azure AI Studio vyžaduje přiřazení rolí řídicí roviny (Přispěvatel) i roviny dat (správce služby Key Vault). To znamená, že tato identita má přístup ke čtení a zápisu ke všem tajným kódům, klíčům a certifikátům uloženým v trezoru klíčů Azure. Pokud má vaše úloha jiné služby než Azure AI Studio, které vyžadují přístup k tajným kódům, klíčům nebo certifikátům ve službě Key Vault, nemusí být váš tým úloh nebo zabezpečení obeznámen s spravovanou identitou centra Azure AI Studio, která má k těmto artefaktům přístup. V takovém případě zvažte nasazení instance služby Key Vault speciálně pro centrum Azure AI Studio a další instance služby Azure Key Vault podle potřeby pro jiné části vaší úlohy.

Optimalizace nákladů

Optimalizace nákladů se zabývá způsoby, jak snížit zbytečné výdaje a zlepšit efektivitu provozu. Další informace najdete v kontrolním seznamu pro kontrolu návrhu pro optimalizaci nákladů.

Pokud chcete zobrazit příklad cen pro tento scénář, použijte cenovou kalkulačku Azure. Příklad je potřeba přizpůsobit tak, aby odpovídal vašemu využití, protože tento příklad zahrnuje pouze komponenty zahrnuté v architektuře. Nejnákladnější komponenty ve scénáři jsou DDoS Protection a brána firewall nasazená jako součást spravovaného online koncového bodu. Další velmi vhodné náklady jsou uživatelské rozhraní chatu a výzvy k výpočtu výpočetních prostředků a vyhledávání AI. Optimalizujte tyto prostředky, abyste ušetřili nejvíce nákladů.

Compute

Tok výzvy podporuje více možností pro hostování spustitelných toků. Mezi možnosti patří spravované online koncové body ve službě Machine Learning, AKS, App Service a Azure Kubernetes Service. Každá z těchto možností má svůj vlastní model fakturace. Volba výpočetních prostředků ovlivňuje celkové náklady na řešení.

Azure OpenAI

Azure OpenAI je služba založená na spotřebě a stejně jako u jakékoli služby založené na spotřebě je řízení poptávky před nabídkou primární kontrolou nákladů. Pokud to chcete udělat konkrétně v Azure OpenAI, musíte použít kombinaci přístupů:

• Řídí klienty. Požadavky klientů jsou primárním zdrojem nákladů v modelu spotřeby, takže řízení chování klienta je důležité. Všichni klienti by měli:

  • Musí být schválen. Vyhněte se zveřejnění služby takovým způsobem, který podporuje bezplatný přístup pro všechny. Omezte přístup prostřednictvím řízení sítě i identit, jako jsou klíče nebo řízení přístupu na základě role (RBAC).

  • Buďte sebeovládaní. Vyžadovat, aby klienti používali omezení omezující tokeny nabízená voláními rozhraní API, jako jsou max_tokens a max_completions.

  • Používejte dávkování, kde je to praktické. Zkontrolujte klienty a ujistěte se, že se správně dávkovají výzvy.

  • Optimalizujte délku zadávání výzvy a odpovědi. Delší výzvy spotřebovávají více tokenů, zvyšují náklady, ale výzvy, které chybí dostatečný kontext, nepomůžou modelům přinést dobré výsledky. Vytvořte stručné výzvy, které poskytují dostatečný kontext, aby model mohl vygenerovat užitečnou odpověď. Stejně tak se ujistěte, že optimalizujete limit délky odpovědi.

• Využití dětského hřiště Azure OpenAI by mělo být podle potřeby a v předprodukčních instancích, aby tyto aktivity nevybíraly provozní náklady.

• Vyberte správný model AI. Výběr modelu hraje také velkou roli v celkových nákladech na Azure OpenAI. Všechny modely mají silné a slabé stránky a jsou individuálně ceněny. Pro případ použití použijte správný model, abyste měli jistotu, že u dražšího modelu nepřespínáte, pokud levnější model přinese přijatelné výsledky. V této referenční implementaci chatu byla gpT 3.5-turbo zvolena přes GPT-4, aby se ušetřilo o řádové velikosti nákladů na nasazení modelu při dosažení dostatečných výsledků.

• Vysvětlení zarážek fakturace Jemné ladění se účtuje za hodinu. Chcete-li být nejúčinnější, chcete použít tolik času, kolik času je k dispozici za hodinu, abyste zlepšili výsledky vyladění a vyhnuli se pouhému proklouznutí do dalšího fakturačního období. Stejně tak jsou náklady na 100 obrázků z generování imagí stejné jako náklady na jednu image. Maximalizujte body cenové přestávky na vaši výhodu.

• Vysvětlení fakturačních modelů Azure OpenAI je také k dispozici v modelu fakturace založeném na závazku prostřednictvím nabídky zřízené propustnosti . Jakmile budete mít předvídatelné vzory využití, zvažte přechod na tento předprodejní model fakturace, pokud je nákladově efektivnější ve vašem objemu využití.

• Nastavte limity zřizování. Ujistěte se, že je všechna kvóta zřizování přidělená pouze modelům, u které se očekává, že budou součástí úlohy na základě jednotlivých modelů. Propustnost pro již nasazené modely není omezena na tuto zřízenou kvótu, pokud je povolená dynamická kvóta. Kvóta se nemapuje přímo na náklady a náklady se můžou lišit.

• Monitorujte využití průběžných plateb. Pokud používáte ceny průběžných plateb, monitorujte využití čipu TPM a RPM. Tyto informace slouží k informování rozhodnutí o návrhu architektury, jako jsou modely, které se mají použít, a optimalizaci velikostí výzev.

• Monitorujte využití zřízené propustnosti. Pokud používáte zřízenou propustnost, monitorujte využití spravované zřizováním a ujistěte se, že nevyužíváte zřízenou propustnost, kterou jste zakoupili.

• Správa nákladů. Postupujte podle pokynů k používání funkcí správy nákladů s OpenAI k monitorování nákladů, nastavení rozpočtů pro správu nákladů a vytváření upozornění, která budou informovat zúčastněné strany o rizicích nebo anomáliích.

Provozní dokonalost

Efektivita provozu zahrnuje provozní procesy, které nasazují aplikaci a udržují ji spuštěnou v produkčním prostředí. Další informace najdete v kontrolním seznamu pro kontrolu návrhu pro efektivitu provozu.

Integrované moduly runtime toku výzvy

Stejně jako v základní architektuře používá tato architektura automatické běhové prostředí k minimalizaci provozní zátěže. Automatický modul runtime je bezserverová výpočetní možnost ve službě Machine Learning, která zjednodušuje správu výpočetních prostředků a deleguje většinu konfigurace toku výzvy na spuštěný soubor a flow.dag.yaml konfiguraci aplikacerequirements.txt. To dělá tuto volbu s nízkou údržbou, dočasným a aplikacím řízeným. Použití modulu runtime výpočetní instance nebo externalizovaného výpočetního prostředí, jako je například v této architektuře, vyžaduje více životního cyklu výpočetních prostředků spravovaných týmem a mělo by být vybráno, když požadavky na úlohy překračují možnosti konfigurace možnosti automatického modulu runtime.

Sledování

Podobně jako v základní architektuře se diagnostika konfiguruje pro všechny služby. Všechny služby, ale App Service jsou nakonfigurované tak, aby zaznamenávaly všechny protokoly. Služba App Service je nakonfigurovaná tak, aby zachytila protokoly AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs a AppServicePlatformLogs. V produkčním prostředí jsou všechny protokoly pravděpodobně nadměrné. Vylaďte streamy protokolů podle svých provozních potřeb. Pro tuto architekturu zahrnují protokoly Azure Machine Learning používané projektem Azure AI Studio, které jsou zajímavé: AmlComputeClusterEvent, AmlDataSetEvent, AmlEnvironmentEvent a AmlModelsEvent.

Vyhodnoťte vytváření vlastních upozornění pro prostředky v této architektuře, jako jsou ty, které se nacházejí ve standardních upozorněních služby Azure Monitor. Příklad:

• Upozornění služby Container Registry
• Upozornění služby Machine Learning a Azure OpenAI
• Upozornění Azure Web Apps

Nezapomeňte sledovat využití tokenů pro nasazení modelu Azure OpenAI. V této architektuře tok výzvy sleduje využití tokenů prostřednictvím integrace s Aplikace Azure lication Insights.

Operace jazykového modelu

Nasazení chatových řešení založených na Azure OpenAI, jako je tato architektura, by mělo postupovat podle pokynů v GenAIOps s rychlým tokem s Azure DevOps a GitHubem. Kromě toho musí zvážit osvědčené postupy pro kontinuální integraci a průběžné doručování (CI/CD) a architektury zabezpečené sítí. Následující doprovodné materiály se zabývají implementací toků a jejich přidruženou infrastrukturou na základě doporučení GenAIOps. Tyto pokyny k nasazení nezahrnují prvky front-endové aplikace, které se nezměnily v architektuře zónově redundantních webových aplikací standardních hodnot.

Vývoj

Tok výzvy nabízí prostředí pro vytváření obsahu založené na prohlížeči v Azure AI Studiu nebo prostřednictvím rozšíření Visual Studio Code. Obě možnosti ukládají kód toku jako soubory. Když používáte Azure AI Studio, soubory se ukládají do účtu úložiště. Při práci v nástroji Microsoft Visual Studio Code se soubory ukládají do místního systému souborů.

Aby bylo možné dodržovat osvědčené postupy pro spolupráci při vývoji, měly by se zdrojové soubory udržovat v online úložišti zdrojového kódu, jako je GitHub. Tento přístup usnadňuje sledování všech změn kódu, spolupráci mezi autory toku a integraci s toky nasazení, které testují a ověřují všechny změny kódu.

Pro podnikový vývoj použijte rozšíření Microsoft Visual Studio Code a sadu SDK nebo rozhraní příkazového řádku pro vývoj. Autoři toků můžou vytvářet a testovat toky z Microsoft Visual Studio Code a integrovat místně uložené soubory se systémem a kanály online správy zdrojového kódu. I když je prostředí založené na prohlížeči vhodné pro průzkumný vývoj, s určitou prací je možné ho integrovat se systémem správy zdrojového kódu. Složku toku je možné stáhnout ze stránky toku na panelu Files , rozbalit a odeslat do systému správy zdrojového kódu.

Hodnocení

Otestujte toky používané v chatovací aplikaci stejně jako testovat další artefakty softwaru. Zadání a uplatnění jediné "správné" odpovědi pro výstupy jazykového modelu je náročné, ale k vyhodnocení odpovědí můžete použít samotný jazykový model. Zvažte implementaci následujících automatizovaných vyhodnocení toků jazykového modelu:

• Přesnost klasifikace: Vyhodnotí, jestli jazykový model poskytuje "správné" nebo "nesprávné" skóre a agreguje výsledky tak, aby vznikly známky přesnosti.

• Soudržnost: Vyhodnocuje, jak dobře se věty v předpovídané odpovědi modelu zapisují a jak jsou vzájemně koherentně propojeny.

• Plynulost: Vyhodnotí predikovanou odpověď modelu pro gramatickou a jazykovou přesnost.

• Zemnění kontextu: Vyhodnotí, jak dobře jsou předpovězené odpovědi modelu založené na předkonfigurovaném kontextu. I když jsou odpovědi jazykového modelu správné, pokud je nelze ověřit v daném kontextu, nejsou takové odpovědi uzemněné.

• Relevance: Vyhodnotí, jak dobře predikované odpovědi modelu odpovídají položené otázce.

Při implementaci automatizovaných vyhodnocení zvažte následující pokyny:

• Vytvoří skóre z vyhodnocení a změří je proti předdefinované prahové hodnotě úspěchu. Pomocí těchto skóre můžete v kanálech hlásit úspěšné nebo neúspěšné testování.

• Některé z těchto testů vyžadují předkonfigurované datové vstupy otázek, kontextu a základní pravdy.

• Zahrňte dostatek dvojic odpovědí na otázky, abyste zajistili, že výsledky testů jsou spolehlivé a doporučuje se alespoň 100 až 150 dvojic. Tyto páry odpovědí na otázky se označují jako "zlatá datová sada". V závislosti na velikosti a doméně vaší datové sady se může vyžadovat větší počet obyvatel.

• Nepoužívejte jazykové modely k vygenerování jakýchkoli dat ve zlaté datové sadě.

Tok nasazení

1. Pracovník výzvy nebo datový vědec otevře větev funkce, ve které pracuje na konkrétním úkolu nebo funkci. Prompt engineer/data scientist iteruje tok pomocí toku výzvy pro Microsoft Visual Studio Code, pravidelně potvrdí změny a nasdílí tyto změny do větve funkcí.

2. Po dokončení místního vývoje a experimentování otevře technik výzvy nebo datový vědec žádost o přijetí změn z větve Feature do hlavní větve. Žádost o přijetí změn aktivuje kanál žádosti o přijetí změn. Tento kanál spouští rychlé kontroly kvality, které by měly zahrnovat:

   • Provádění toků experimentování
   • Provádění nakonfigurovaných testů jednotek
   • Kompilace základu kódu
   • Statická analýza kódu

3. Kanál může obsahovat krok, který před sloučením vyžaduje alespoň jednoho člena týmu, aby žádost o přijetí změn schválil ručně. Schvalovatel nemůže být potvrzením a oni mush mají zkušenosti s tokem a znalost požadavků na projekt. Pokud žádost o přijetí změn není schválená, sloučení se zablokuje. Pokud je žádost o přijetí změn schválená nebo neexistuje žádný krok schválení, větev funkce se sloučí do hlavní větve.

4. Sloučení do Main aktivuje proces sestavení a vydání pro vývojové prostředí. Konkrétně:

   1. Kanál CI se aktivuje z hromadné korespondence do main. Kanál CI provádí všechny kroky provedené v kanálu žádosti o přijetí změn a následující kroky:
   • Tok experimentování
   • Tok vyhodnocení
   • Zaregistruje toky v registru služby Machine Learning při zjištění změn.
   1. Kanál CD se aktivuje po dokončení kanálu CI. Tento tok provádí následující kroky:
   • Nasadí tok z registru Machine Learning do online koncového bodu Machine Learning.
   • Spustí integrační testy, které cílí na online koncový bod.
   • Spustí orientační testy, které cílí na online koncový bod.

5. Proces schválení je integrovaný do procesu povýšení vydané verze – po schválení, procesy CI &CD popsané v krocích 4.a. & 4.b. se opakují a cílí na testovací prostředí. Kroky a. a b. jsou stejné, s výjimkou toho, že akceptační testy uživatelů se spustí po orientačních testech v testovacím prostředí.

6. Procesy CI &CD popsané v krocích 4.a. &4.b. po ověření a schválení testovacího prostředí se spustí pro zvýšení úrovně vydané verze do produkčního prostředí.

7. Po vydání do živého prostředí probíhají provozní úlohy monitorování metrik výkonu a vyhodnocení nasazených jazykových modelů. To zahrnuje, ale není omezené na:

   • Zjišťování odchylek dat
   • Sledování infrastruktury
   • Správa nákladů
   • Komunikace výkonu modelu zúčastněným stranám

Pokyny pro nasazení

Pomocí koncových bodů služby Machine Learning můžete nasazovat modely způsobem, který umožňuje flexibilitu při uvolnění do produkčního prostředí. Zvažte následující strategie, abyste zajistili nejlepší výkon a kvalitu modelu:

• Modrá/zelená nasazení: Pomocí této strategie můžete bezpečně nasadit novou verzi webové služby do omezené skupiny uživatelů nebo požadavků, než přesměrujete veškerý provoz na nové nasazení.

• Testování A/B: Nejen že jsou modrá/zelená nasazení efektivní pro bezpečné zavádění změn, je možné je také použít k nasazení nového chování, které umožňuje podmnožině uživatelů vyhodnotit dopad změny.

• Do kanálů zahrňte lintování souborů Pythonu, které jsou součástí toku výzvy. Linting kontroluje dodržování standardů stylu, chyb, složitosti kódu, nepoužívaných importů a pojmenování proměnných.

• Když tok nasadíte do pracovního prostoru Machine Learning v izolované síti, nasaďte artefakty do prostředků Azure pomocí agenta v místním prostředí.

• Registr modelů služby Machine Learning by se měl aktualizovat pouze v případě, že dojde ke změnám modelu.

• Jazykové modely, toky a uživatelské rozhraní klienta by měly být volně svázané. Aktualizace toků a uživatelského rozhraní klienta můžou a měly by být schopné provádět bez ovlivnění modelu a naopak.

• Při vývoji a nasazování více toků by měl mít každý tok svůj vlastní životní cyklus, který umožňuje volně propojený zážitek při podpoře toků z experimentování do produkčního prostředí.

Infrastruktura

Když nasadíte základní komplexní součásti chatu Azure OpenAI, některé zřízené služby jsou v architektuře základní a trvalé, zatímco jiné komponenty jsou v podstatě dočasné, jejich existence je svázaná s nasazením. I když je spravovaná virtuální síť základní, automaticky se zřídí při vytváření výpočetní instance, která vede k určitým aspektům.

Základní komponenty

Některé komponenty v této architektuře existují s životním cyklem, který přesahuje jakýkoli jednotlivý tok výzvy nebo jakékoli nasazení modelu. Tyto prostředky se obvykle nasazují jednou jako součást základního nasazení týmem úloh a udržují se kromě nových, odebraných nebo aktualizací výzev nebo nasazení modelu.

• Pracovní prostor Machine Learning
• Účet úložiště pro pracovní prostor Machine Learning
• Container Registry
• Vyhledávání AI
• Azure OpenAI
• Azure Application Insights
• Azure Bastion
• Virtuální počítač Azure pro jump box

Dočasné komponenty

Některé prostředky Azure jsou úzce svázané s návrhem konkrétních toků výzvy. Tento přístup umožňuje, aby tyto prostředky byly vázány na životní cyklus komponenty a staly se dočasným v této architektuře. Prostředky Azure jsou ovlivněny při vývoji úloh, například při přidání nebo odebrání toků nebo při zavedení nových modelů. Tyto prostředky se znovu vytvoří a odeberou předchozí instance. Některé z těchto prostředků jsou přímé prostředky Azure a některé jsou projevy roviny dat v rámci jejich služby.

• Model v registru modelů služby Machine Learning by se měl aktualizovat, pokud se změní v rámci kanálu CD.

• Image kontejneru by se měla aktualizovat v registru kontejneru jako součást kanálu CD.

• Koncový bod služby Machine Learning se vytvoří, když se nasadí tok výzvy, pokud nasazení odkazuje na koncový bod, který neexistuje. Tento koncový bod je potřeba aktualizovat, aby se vypnul veřejný přístup.

• Nasazení koncového bodu Machine Learning se aktualizují při nasazení nebo odstranění toku.

• Trezor klíčů pro uživatelské rozhraní klienta musí být při vytvoření nového koncového bodu aktualizován klíčem na koncový bod.

Spravovaná virtuální síť na vyžádání

Spravovaná virtuální síť se automaticky zřídí při prvním vytvoření výpočetní instance. Pokud k nasazení centra používáte infrastrukturu jako kód a nemáte v Bicep výpočetní prostředky AI Studia, spravovaná virtuální síť se nenasadí a při připojování k Azure AI Studiu se zobrazí chyba. Po nasazení IaC budete muset provést jednorázovou akci, která po nasazení IaC ručně zřídí spravovanou virtuální síť .

Organizace prostředků

Pokud máte scénář, ve kterém centrum centrálně vlastní jiný tým než tým úloh, můžete se rozhodnout nasadit projekty do samostatných skupin prostředků. Pokud jako kód používáte infrastrukturu, můžete toho dosáhnout nastavením jiné skupiny prostředků v Bicep. Pokud používáte portál, můžete vlastnost nastavit defaultWorkspaceResourceGroup na workspaceHubConfig skupinu prostředků, kterou chcete vytvořit.

Efektivita výkonu

Efektivita výkonu je schopnost úlohy škálovat se tak, aby efektivním způsobem splňovala požadavky, které na ni kladou uživatelé. Další informace najdete v kontrolním seznamu pro kontrolu návrhu týkajícího se efektivity výkonu.

Tato část popisuje efektivitu výkonu z pohledu služby Azure Search, Azure OpenAI a Machine Learning.

Azure Search – efektivita výkonu

Při analýze výkonu ve službě AI Search postupujte podle pokynů.

Azure OpenAI – Efektivita výkonu

• Určete, jestli vaše aplikace vyžaduje zřízenou propustnost , nebo model sdíleného hostování nebo spotřeby. Zřízená propustnost zajišťuje rezervovanou kapacitu zpracování pro nasazení modelu OpenAI, která poskytuje předvídatelný výkon a propustnost vašich modelů. Tento fakturační model se liší od modelu sdíleného hostování nebo spotřeby. Model spotřeby je nejvhodnější a může být vystaven hlučným sousedům nebo jiným stresorům na platformě.

• Monitorujte využití spravovaného zřizováním pro zřízenou propustnost.

Machine Learning – efektivita výkonu

Pokud nasadíte do online koncových bodů služby Machine Learning:

• Postupujte podle pokynů k automatickému škálování online koncového bodu. Chcete-li zůstat v úzkém souladu s poptávkou bez nadměrného zřízení, zejména v obdobích s nízkým využitím.

• Zvolte odpovídající skladovou položku virtuálního počítače pro online koncový bod, aby splňovala vaše výkonnostní cíle. Otestujte výkon nižšího počtu instancí i větších skladových položek oproti většímu počtu instancí a menších skladových položek, abyste našli optimální konfiguraci.

Nasazení tohoto scénáře

Pokud chcete nasadit a spustit referenční implementaci, postupujte podle kroků v komplexní referenční implementaci OpenAI podle směrného plánu.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

• Rob Bagby | Vzory a postupy – Microsoft
• Freddy Ayala | Architekt cloudových řešení – Microsoft
• Prabal Deb | Vedoucí softwarový inženýr – Microsoft
• Raouf Aliouat | Softwarový inženýr II – Microsoft
• Ritesh Modi | Hlavní softwarový inženýr – Microsoft
• Ryan Pfalz | Vedoucí architekt řešení – Microsoft

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další krok

Související prostředky

• Azure OpenAI
• Jazykové modely Azure OpenAI
• Vyzvání toku v Azure AI Studiu
• Izolace virtuální sítě spravovaná pracovním prostorem
• Konfigurace privátního koncového bodu pro pracovní prostor Machine Learning
• Filtrování obsahu