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

Podnikové chatovací aplikace můžou zaměstnancům umožnit konverzační interakci. Tento bod je zvlášť pravdivý z důvodu průběžného pokroku jazykových modelů, jako jsou modely GPT OpenAI a modely Llama Meta. Tyto chatovací aplikace se skládají z těchto:

• Uživatelské rozhraní chatu
• Úložiště dat, která obsahují informace specifické pro doménu, které se týkají dotazů uživatele.
• Jazykové modely, které zdůvodní data specifická pro doménu, aby vytvořily relevantní odpověď.
• Orchestrátor, který dohlíží na interakce mezi komponentami.

Tento článek obsahuje základní architekturu, která vám pomůže sestavovat a nasazovat podnikové chatovací aplikace, které používají jazykové modely azure OpenAI Service. Architektura používá tok výzvy k vytvoření spustitelných toků. Tyto spustitelné toky orchestrují pracovní postup z příchozích výzev do úložišť 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, který používá spravované výpočetní prostředky.

Hostování vlastního uživatelského rozhraní chatu se řídí standardními webovými aplikacemi app services pokyny k nasazení zabezpečené, zónově redundantní a vysoce dostupné webové aplikace ve službě Azure App 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. V architektuře uživatelského rozhraní chatu služba App Service komunikuje se spravovaným online koncovým bodem pro tok přes privátní koncový bod. Veřejný přístup k portálu Azure AI Foundry je zakázaný.

Centrum Azure AI Foundry se konfiguruje pomocí izolace spravované virtuální sítě, která vyžaduje schválení pro všechna odchozí připojení. V této konfiguraci se vytvoří spravovaná virtuální síť a spravované privátní koncové body, které umožní 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ů toky nasazenými do výpočetních prostředků služby Azure Machine Learning.

Centrum je prostředek Azure AI Foundry 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 více zkušeností, které vyžadují různé toky výzvy, které používají jinou logiku a potenciálně různé back-endové prostředky, jako jsou úložiště dat, můžete zvážit implementaci těchto prostředí v jiném projektu.

Architektura

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

Komponenty

Mnoho komponent této architektury je stejné jako prostředky v základní komplexní architektuře chatu Azure OpenAI. Následující seznam uvádí rozdíly mezi základní architekturou a základní architekturou.

• Azure OpenAI se používá v obou architekturách. 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 používá podnikové funkce, jako jsou virtuální sítě a privátní propojení, že se základní architektura neimplementuje.

• azure AI Foundry je platforma, pomocí které můžete vytvářet, testovat a nasazovat řešení AI. Tato architektura používá portál Azure AI Foundry k sestavení, testování a nasazení logiky orchestrace toku výzvy pro chatovací aplikaci. V této architektuře poskytuje Azure AI Foundry spravovanou virtuální síť pro zabezpečení sítě. Další informace najdete v části sítě v tomto článku.

• azure 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í Azure je nativní cloudová služba, která pomáhá chránit 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. Tato viditelnost vám pomůže 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í.

• azure Virtual Network je služba, kterou můžete použít k vytváření izolovaných a bezpečnějších privátních virtuálních 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.

• Azure Private Link umožňuje klientům přistupovat ke službám Azure PaaS přímo z privátních virtuálních sítí bez použití 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 zahrnuje více komponent, které můžou obsluhovat jiné služby Azure, které můžou lépe odpovídat funkčním a nefunkčním požadavkům vaší úlohy.

Prostředí pracovních prostorů a portálů služby Machine Learning

Tato architektura používá portálu Azure AI Foundry k sestavení, testování a nasazení toků výzvy. Alternativně můžete použít pracovních prostorů služby Machine Learning. Obě služby mají funkce, které se překrývají. Portál je dobrou volbou pro návrh řešení toku výzvy, ale Machine Learning má v současné době lepší podporu některých funkcí. Další informace naleznete v tématu Podrobné porovnání funkcí. Doporučujeme nekombinovat a odpovídat portálu a nástroji Machine Learning Studio. Pokud můžete svoji práci provést úplně na portálu Azure AI Foundry, použijte portál. Pokud potřebujete funkce ze studia Machine Learning Studio, použijte místo toho studio.

Komponenty aplikační vrstvy

Azure poskytuje několik spravovaných aplikačních služeb, které můžou sloužit jako aplikační vrstva front-endu uživatelského rozhraní chatu. Mezi tyto služby patří výpočetní možnosti a řešení kontejnerů. Tato architektura například používá Web Apps a Web App for Containers pro rozhraní API chatu a hostitele toku výzvy. Podobné výsledky můžete dosáhnout pomocí služby Azure Kubernetes Service (AKS) nebo Azure Container Apps. Zvolte aplikační platformu pro vaši úlohu na základě konkrétních funkčních a nefunkčních požadavků.

Hostování toku výzvy

Nasazení toků výzvy není omezené na výpočetní clustery Machine Learning. Tato architektura ukazuje tento bod pomocí alternativního řešení ve službě App Service. Toky jsou nakonec kontejnerizovaná aplikace, která se dá nasadit do jakékoli služby Azure, která je kompatibilní s kontejnery. Mezi tyto možnosti patří služby, jako jsou AKS, Container Apps a App Service. zvolte službu kontejneru Azure na základě požadavků vaší vrstvy orchestrace.

Příklad, proč můžete zvážit nasazení hostování toku výzvy na alternativní výpočetní prostředky, je popsáno dále v tomto článku.

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

Tato architektura vede pomocí služby AI Search, ale volba úložiště dat pro podkladová data je rozhodnutí o architektuře, které je specifické pro vaši úlohu. Mnoho úloh používá několik jazyků a má různorodé zdroje a technologie pro zemnění dat. Mezi tyto datové platformy patří existující úložiště dat pro online zpracování transakcí, nativní cloudové databáze, jako je Azure Cosmos DB, a specializovaná řešení, jako je AI Search. Vektorové vyhledávání je pro tento typ úložiště dat běžnou charakteristikou, ale nevyžaduje se. Další informace najdete v tématu Volba služby Azure pro vektorové vyhledávání.

Úvahy

Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které můžete použít ke zlepšení kvality úlohy. Další informace naleznete v tématu Well-Architected Framework.

Tuto architekturu a pokyny k návrhu použijte v úlohách AI v Azure během procesu návrhu pro vaši konkrétní úlohu.

Spolehlivost

Spolehlivost pomáhá zajistit, aby vaše aplikace splňovala závazky, které jste pro své zákazníky udělali. 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 mezi nimi nasazeny dvě nebo více instancí. Pokud dojde k výpadku v jedné zóně, ostatní zóny v této oblasti můžou být nedotknuty. Architektura také pomáhá zajistit, aby se dostatek instancí a konfigurací služeb Azure rozprostřely mezi zóny dostupnosti. Další informace naleznete v tématu standardní hodnoty vysoce dostupné zónově redundantní webové aplikace.

Tato část se zabývá spolehlivostí z pohledu komponent v této architektuře, které nejsou vyřešené v základní architektuře 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ón dostupnostia pokud není k dispozici řízení instancí, musíte nasadit aspoň tři instance prostředku nebo povolit podporu platformy. Výpočetní prostředí Machine Learning nepodporuje zóny dostupnosti. Pokud chcete zmírnit potenciální dopady katastrofy na úrovni datacentra na komponenty Machine Learning, musíte vytvořit clustery v různých oblastech a nasadit nástroj pro vyrovnávání zatížení, který bude distribuovat 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ě.

Alternativy výpočetních clusterů Machine Learning zahrnují AKS, Azure Functions, Container Apps a App 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ůžete své toky nasadit do jedné z těchto služeb.

Následující diagram znázorňuje alternativní architekturu, ve které se do služby App Service nasadí toky výzvy. Tato architektura používá službu App Service, protože úloha ji už používá pro uživatelské rozhraní chatu a nemá 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 používají AKS pro jiné součásti úlohy.

Následující tok dat odpovídá předchozímu diagramu:

1. Toky se vytváří v toku výzvy a síťová architektura se nezmění. Autoři toku se připojují k prostředí pro vytváření v projektu Azure AI Foundry 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. Diagram nezobrazuje kanály, které kontejnerizují toky a nasdílí 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 Azure AI Foundry.

3. Jiná webová aplikace se nasadí do stejného plánu služby App Service, který hostuje uživatelské rozhraní chatu. Nová webová aplikace hostuje kontejnerizovaný tok výzvy, který je společně přidělený do stejného plánu služby App Service. Tento plán služby už běží minimálně tři instance, které jsou 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é jsou vystavené pouze podsíti privátního koncového bodu spravované službou Machine Learning, teď také potřebují vystavení ve virtuální síti, aby bylo možné z app Service navázat dohled.

Spolehlivost v Azure OpenAI

Azure OpenAI nepodporuje zóny dostupnosti. Pokud chcete zmírnit potenciální dopady katastrofy na úrovni datového centra na nasazení modelu v Azure OpenAI, musíte nasadit Azure OpenAI do různých oblastí a nasadit nástroj pro vyrovnávání zatížení pro distribuci 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 geograficky redundantní účet úložiště. Tento přístup minimalizuje stav uložený v Azure OpenAI pro každou oblast. Abyste mohli hostovat nasazení modelu, musíte soubory vyladit pro každou instanci.

Je důležité monitorovat požadovanou propustnost z hlediska tokenů za minutu (TPM) a požadavků za minutu (RPM). Přiřaďte z kvóty dostatečný čip TPM, abyste splnili poptávku po nasazeních a zabránili omezování volání nasazených modelů. Bránu, jako je Azure API Management, můžete nasadit před službu Nebo služby Azure OpenAI a nakonfigurovat ji pro opakování, pokud dojde k přechodným chybám a omezování. Službu API Management můžete použít také jako jistič , abyste zabránili zahlcení služby voláními a překročení kvóty. Další informace najdete v tématu Použití brány před několika nasazeními nebo instancemi Azure OpenAI.

Spolehlivost ve vyhledávání AI

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.

K určení odpovídajícího počtu replik a oddílů použijte následující doprovodné materiály:

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

• K určení vhodného počtu replik použijte metriky monitorování a protokoly a analýzu výkonu. Tento přístup vám pomůže vyhnout se omezování na základě dotazů a oddílů a omezování na základě indexu.

Spolehlivost ve službě Azure AI Foundry

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 ke š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 kvůli nárůstu využití dostatečně včasné, zvažte nadměrné zřízení. Tento přístup pomáhá zlepšit spolehlivost tím, že zajišťuje, aby byly k dispozici dostatek instancí.

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

• Nasaďte méně než tři instance pro aktivní produkční nasazení.

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

Spravované online koncové body slouží jako nástroj pro vyrovnávání zatížení a směrovač pro spravované výpočetní prostředky, které za nimi běží. Můžete nakonfigurovat procento provozu, které by se mělo směrovat do každého nasazení, pokud procento sečte až 100%. Můžete také nasadit spravovaný online koncový bod s 0% provozem směrovaným do jakéhokoli nasazení.

Pokud k nasazení prostředků používáte infrastrukturu jako kód (IaC), včetně spravovaných online koncových bodů, existuje problém se spolehlivostí. Tento problém je zvýrazněný v poskytnuté referenční implementaci. Pokud máte provoz nakonfigurovaný tak, aby směroval na nasazení vytvořená prostřednictvím rozhraní příkazového řádku nebo portálu Azure AI Foundry, a provedete následné nasazení IaC, které zahrnuje spravovaný online koncový bod, i když neaktualizuje spravovaný online koncový bod žádným způsobem, provoz koncového bodu se vrátí ke směrování 0% provozu. V podstatě tento scénář znamená, že nasazené toky výzvy nejsou dostupné, dokud neupravíte provoz zpět na požadované místo.

Návrh více oblastí

Tato architektura neslouží jako regionální razítko v architektuře s více oblastmi. Poskytuje vysokou dostupnost v rámci jedné oblasti, protože zcela využívá zóny dostupnosti, ale nemá některé klíčové komponenty, aby byl tento návrh připravený pro řešení s více oblastmi. Tato architektura nezahrnuje následující komponenty a aspekty:

• Globální příchozí přenos dat a směrování
• Strategie správy DNS
• Strategie replikace nebo izolace dat
• 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í cíle doby obnovení a cíle bodu obnovení vaší úlohy
• Důležité informace o dostupnosti oblastí pro prostředí pro vývojáře v prostředku centra Azure AI Foundry

Pokud vaše úloha vyžaduje strategii více oblastí, musíte kromě návrhu uvedeného v této architektuře investovat do návrhu komponent a operačního procesu. Váš návrh musí podporovat 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, což je tok výzvy v této architektuře
• Uživatelské rozhraní s klientským rozhraním

Potřebujete také udržovat kontinuitu podnikových procesů v pozorovatelnosti, prostředích portálu a zodpovědné umělé inteligenci, 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 základní referenční architektuře openAI pro kompletní chat. 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 a ručně vytvořené přiřazení rolí.

Tato architektura kromě hraniční sítě, kterou implementuje základní architektura, implementuje hraniční síť zabezpečení sítě. Z hlediska sítě by mělo být přes Application Gateway přístupné jenom uživatelské rozhraní chatu z internetu. Z hlediska identity by mělo uživatelské rozhraní chatu ověřovat a autorizovat žádosti. Spravované identity používejte, pokud je to možné k ověřování aplikací ve službách Azure.

Tato část popisuje aspekty sítí a zabezpečení pro obměnu klíčů a vyladění modelu Azure OpenAI.

Správa identit a přístupu

Pokud používáte spravované identity přiřazené 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 Foundry a Machine Learning:

  • Centrum Azure AI Foundry
  • Projekty Azure AI Foundry 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

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

Když připojíte uživatele k projektům Azure AI Foundry, aby mohli provádět funkce, jako jsou toky vytváření, přiřaďte pro prostředky, které potřebují, role s nejnižšími oprávněními.

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í, které funkce centra a projektů můžete použít, vytvoří přiřazení rolí, která podporují všechny potenciální funkce. Automaticky vytvořená přiřazení rolí můžou na základě vašeho případu použití překřazovat oprávnění. Jedním z příkladů je, že systém přiřadí roli Přispěvatel do centra pro registr kontejneru, ale centrum pravděpodobně vyžaduje přístup čtenáře pouze k řídicí rovině. Pokud potřebujete omezit oprávnění 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 udržujete 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. Musíte provést všechna zadání 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 Azure AI Foundry sdílí prostředky Azure, jako jsou účty úložiště a Container Registry, napříč projekty. 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ě Storage podporují podmínky přiřazení role. Pokud uživatel vyžaduje přístup k podmnožině projektů, použijte podmínky přístupu role k omezení oprávnění ke kontejnerům objektů blob, které tyto projekty používají místo přiřazování oprávnění pro jednotlivé kontejnery. 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 vyžaduje Contributor přístup ke skupině prostředků centra, aby mohl vytvářet a spravovat prostředky centra a projektu. Contributor přístup také dává řídicí rovině centra přístup k libovolnému prostředku, který je ve skupině prostředků. Vytvořte všechny prostředky Azure, které přímo nesouvisí s centrem a jejími projekty v samostatné skupině prostředků. Doporučujeme vytvořit minimálně dvě skupiny prostředků pro tým úloh, který používá samoobslužné centrum Azure AI Foundry. Jedna skupina prostředků obsahuje centrum, své projekty a všechny jeho přímé závislosti, jako je registr kontejnerů Azure a key Vault. Druhá skupina prostředků obsahuje všechno ostatní ve vaší úloze.

Doporučujeme minimalizovat využití prostředků Azure potřebných pro provoz centra 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 samostatnou instanci služby Key Vault od instance, která je přidružená k centru. K ukládání tajných kódů centra a tajných kódů projektu by měl používat trezor klíčů centra.

Ujistěte se, že pro každý samostatný projekt přiřazení rolí pro jeho závislosti neposkytuje přístup k prostředkům, které uživatel portálu a spravovaná online spravovaná identita koncového bodu nevyžaduje. 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 způsob, jak omezit autory toků ani spravované online identity spravované koncovým bodem, které mají toto přiřazení role ke konkrétním nasazením modelu v Azure OpenAI. V těchto scénářích doporučujeme nasadit služby, jako je Azure OpenAI a AI Search, pro každý projekt a nenasazovat prostředky do těchto služeb, ke kterým autoři toku nebo spravované identity spravované online koncové body nemají mít přístup. Například nasaďte modely pouze do instance Azure OpenAI, ke které projekt vyžaduje přístup. Nasaďte indexy pouze do instance služby AI Search, ke které by měl mít projekt přístup.

Sítě

Kromě přístupu založeného 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í:

• Pro přenosy uživatelského rozhraní chatu existuje pouze jeden zabezpečený vstupní bod.
• Síťový provoz se filtruje.
• Přenášená data jsou zašifrovaná tak, že končí zabezpečením transportní vrstvy.
• 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ě

Příchozí tok od koncového uživatele do uživatelského rozhraní chatu a tok ze služby App Service do služeb Azure PaaS jsou popsány v základní architektuře webové aplikace App Service. Tato část se zaměřuje na tok online koncového bodu služby Machine Learning. Jde z uživatelského rozhraní chatu, které běží v základní webové aplikaci App Service, do toku, který je nasazený 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 slouží jako nástroj pro vyrovnávání zatížení i směrovač.
3. Volání služeb Azure PaaS, které nasazený tok vyžaduje, 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 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.

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

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. Autor se může také připojit k virtuální síti prostřednictvím bran Azure ExpressRoute nebo bran VPN a partnerského vztahu virtuálních sítí.

Tok z virtuální sítě spravované službou Azure AI Foundry do služeb Azure PaaS

Doporučujeme nakonfigurovat centrum Azure AI Foundry pro spravovanou izolaci virtuální sítě, což 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 určená pro prostředky, které řešení vyžaduje, jako je Container Registry a Storage. pravidla odchozích přenosů definovaná uživatelem jsou určená pro vlastní prostředky, které váš pracovní postup používá, například Azure OpenAI nebo AI Search. Musíte nakonfigurovat pravidla odchozích přenosů definovaná uživatelem. Požadovaná pravidla odchozích přenosů 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 je trvalá.

Odchozí pravidla můžou být privátní koncové body, značky služeb nebo plně kvalifikované názvy domén pro externí veřejné koncové body. V této architektuře se připojení ke službám Azure vytváří prostřednictvím služby Private Link. Tato architektura nezahrnuje některé běžné operace, které můžou vyžadovat, abyste nakonfigurovali odchozí pravidlo plně kvalifikovaného názvu domény, stáhli balíček pip, naklonovali úložiště GitHub nebo stáhli základní image kontejneru z externích úložišť.

Instance služby Azure Firewall spravovaná Microsoftem implementuje ovládací prvek odchozího plně kvalifikovaného názvu domény a nasazuje se do spravované sítě Azure AI Foundry. Pokud potřebujete řídit pouze odchozí provoz HTTP (port 80) nebo HTTPS (port 443), zvolte cenovou úroveň Basic. Pokud odchozí provoz vyžaduje vlastní protokoly nebo porty, zvolte cenovou úroveň Standard. Tato architektura používá cenovou úroveň Basic, protože jediným odchozím provozem je koncový bod HTTPS na portu 443.

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če jump boxu
• Vyhodnocování
• Trénovací a bodovací podsítě

  Poznámka:

  Podsítě trénování a bodování jsou navržené tak, abyste mohli k trénování a odvozování použít vlastní výpočetní prostředky. Tato architektura ale používá spravované výpočetní prostředky a neprovádí žádné trénování.

Každá podsíť má skupinu zabezpečení sítě (NSG), která omezuje příchozí i odchozí provoz těchto podsítí jenom na to, co vyžadují. 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í provoz	Odchozí provoz
snet-appGateway	Povoleny pro IP adresy uživatelů uživatelského rozhraní chatu, jako je 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 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	Viz Práce s přístupem k NSG aSlužby Azure Bastion .	Viz Práce s přístupem k NSG aSlužby Azure Bastion .
snet-jumpbox	Povolte příchozí protokol remote desktopu a protokol Secure Shell z podsítě hostitele Azure Bastion.	Povolte přístup 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 azure 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 do každé podsítě NSG. 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ě zjednodušuje vytváření pravidel pro složitá prostředí.

Obměna klíčů

V této architektuře používá online koncový bod spravované službou Machine Learning ověřování na základě klíčů, takže 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 webová aplikace Azure, která je hostitelem kontejneru 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í, použijte klíče spravované zákazníkem k šifrování dat.

• Pokud ukládáte trénovací data do úložiště, jako je Azure Blob Storage, použijte klíč spravovaný zákazníkem pro šifrování dat, spravovanou identitu k řízení přístupu k datům a privátní koncový bod 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 platformy prostřednictvím zásad snižuje zátěž ručních kroků ověřování a pomáhá zajistit zásady správného řízení, i když 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 Foundry pro Key Vault

Spravovaná identita Azure AI Foundry vyžaduje přiřazení rolí řídicí roviny (Contributor) i roviny dat (Key Vault Administrator). Tato přiřazení poskytují této identitě přístup pro čtení a zápis ke všem tajným klíčům, klíčům a certifikátům uloženým ve službě Azure Key Vault. Pokud vaše úloha používá jiné služby než Azure AI Foundry, které vyžadují přístup k tajným kódům, klíčům nebo certifikátům ve službě Key Vault, může váš tým zabezpečení nebo úlohy preferovat, aby spravovaná identita centra Azure AI Foundry k těmto artefaktům neměla přístup. V tomto scénáři zvažte nasazení instance služby Key Vault speciálně pro centrum Azure AI Foundry a další instance služby Key Vault podle potřeby pro jiné části vaší úlohy.

Optimalizace nákladů

Optimalizace nákladů se zaměřuje na 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 obsahuje jenom komponenty, které tato architektura používá. Nejnákladnější komponenty ve scénáři jsou DDoS Protection a brána firewall, která je nasazená jako součást spravovaného online koncového bodu. Mezi další velmi vhodné náklady patří uživatelské rozhraní chatu, výpočetní prostředí toku výzvy a vyhledávání AI. Optimalizujte tyto prostředky, abyste snížili náklady.

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 a App Service. Každá z těchto možností má svůj vlastní model fakturace. Vámi zvolené výpočetní prostředky ovlivňují celkové náklady na řešení.

Azure OpenAI

Azure OpenAI je služba založená na spotřebě, takže odpovídající poptávka s nabídkou představuje primární způsob řízení nákladů. Pokud to chcete udělat 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 zásadní. Všichni klienti by měli:

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

  • Buďte sami řízeni. Vyžadovat, aby klienti používali omezení omezující tokeny, která volání rozhraní API poskytují, například max_tokens a max_completions.

  • Dávkování používejte, pokud je to praktické. Zkontrolujte klienty a ujistěte se, že se správně zobrazí dávkové výzvy.

  • Optimalizujte délku zadávání výzvy a odpovědi. Delší výzvy spotřebovávají více tokenů, což zvyšuje náklady. Výzvy, které nemají dostatečný kontext, nepomáhají modelům vytvářet dobré výsledky. Vytvořte stručné výzvy, které poskytují dostatečný kontext, aby model mohl vygenerovat užitečnou odpověď. Ujistěte se, že optimalizujete limit délky odpovědi.

• Dětské hřiště Azure OpenAI používejte pouze podle potřeby. Na předprodukčních instancích byste měli použít pouze dětské hřiště, aby tyto aktivity neúčtovaly produkční náklady.

• Zvolte správný model AI. Model, který zvolíte, ovlivňuje celkové náklady na Azure OpenAI. Všechny modely mají silné a slabé stránky a jsou individuálně ceněny. Použijte správný model pro případ použití, abyste zabránili nadměrnému překročení nákladnějšího modelu, když levnější model produkuje přijatelné výsledky. Tato referenční implementace chatu využívá gpT 3.5-turbo místo GPT-4 k úsporě 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. Pokud chcete dosáhnout maximální efektivity, využijte tolik z této hodiny ke zlepšení výsledků vyladění, než dosáhnete další fakturační hodiny. Podobně 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 model fakturace před nákupem, pokud je nákladově efektivnější ve vašem objemu využití.

• Nastavte limity zřizování. Přidělte všechny kvóty zřizování 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 tyto 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ého zřizováním, abyste zajistili, že nevyužíváte zřízenou propustnost, kterou jste zakoupili.

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

Efektivita provozu

Efektivita provozu se zabývá provozními 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 requirements.txt konfiguraci aplikaceflow.dag.yaml. Tato volba je nízká údržba, dočasná a aplikace řízená aplikací. Tato architektura používá modul runtime výpočetní instance nebo externalizované výpočetní prostředky, které vyžadují, aby tým úloh spravovali životní cyklus výpočetních prostředků. Modul runtime výpočetní instance byste měli použít v případě, že 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 kromě služby App Service jsou nakonfigurované tak, aby zaznamenávaly všechny protokoly. Služba App Service je nakonfigurovaná tak, aby zachytila AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogsa 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 používá projekt Azure AI Foundry protokoly AmlComputeClusterEvent, AmlDataSetEvent, AmlEnvironmentEventa AmlModelsEvent Machine Learning.

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

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

Nezapomeňte monitorovat 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 Application 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 využitím toku výzvy a azure DevOps a GenAIOps s rychlým tokem aGitHubu. Musí také 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 od standardní architektury zónově redundantních webových aplikací s vysokou dostupností.

Vývoj

Tok výzvy poskytuje prostředí pro vytváření na základě prohlížeče na portálu Azure AI Foundry nebo prostřednictvím rozšíření Visual Studio Code. Obě tyto možnosti ukládají kód toku jako soubory. Při použití portálu se soubory ukládají do účtu úložiště. Při práci ve VS Code se soubory ukládají do místního systému souborů.

Pokud chcete postupovat podle osvědčených postupů pro spolupráci při vývoji, udržujte zdrojové soubory v online úložišti zdrojového kódu, jako je GitHub. Tento přístup pomáhá sledovat změny kódu, spolupracovat mezi autory toku a integrovat se toky nasazení, které testují a ověřují všechny změny kódu.

V případě podnikového vývoje použijte rozšíření VS Code a příkazového řádku sdk nebo rozhraní příkazové ho řádku pro vývoj. Autoři toku výzvy můžou vytvářet a testovat své toky z VS Code a integrovat místně uložené soubory se systémem a kanály online správy zdrojového kódu. Prostředí založené na prohlížeči je navržené pro průzkumný vývoj, ale můžete ho integrovat se systémem správy zdrojového kódu. Složku toku si můžete stáhnout ze stránky toku na panelu Files, rozbalit složku a odeslat ji do systému správy zdrojového kódu.

Hodnocení

Otestujte toky, které chatovací aplikace používá, pomocí stejných metod, které používáte k testování jiných softwarových artefaktů. 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 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.

• koherence vyhodnocuje, jak dobře se věty v předpovídané odpovědi modelu zapisují a jak jsou vzájemně koherentně propojeny.

• Fluency posuzuje predikovanou odpověď modelu pro gramatickou a jazykovou přesnost.

• groundedness against context vyhodnocuje, jak dobře jsou predikované odpovědi modelu založeny na předkonfigurovaném kontextu. I když jsou odpovědi jazykového modelu správné, pokud je nelze ověřit v daném kontextu, odpovědi nejsou 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í doprovodné materiály:

• Vytvoří skóre z vyhodnocení a změří je proti předdefinované prahové hodnotě úspěchu. Pomocí těchto skóre můžete hlásit, jestli testy projdou nebo selžou v kanálech.

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

• Zahrňte dostatek dvojic otázek a odpovědí, které vám pomůžou zajistit spolehlivost výsledků testů. Doporučujeme zahrnout alespoň 100-150 dvojic. Tyto otázky a odpovědi se také označují jako vaše zlaté datové sady. V závislosti na velikosti a doméně datové sady může být vyžadován větší počet dvojic.

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

Tok nasazení

Následující tok dat odpovídá předchozímu diagramu:

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 or data scientist iteruje tok pomocí toku výzvy pro VS Code a 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 pracovník výzvy nebo datový vědec žádost o přijetí změn (PR) z větve funkcí 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 musí mít odborné znalosti a znalost požadavků projektu. Pokud žádost o přijetí změn není schválená, sloučení se zablokuje. Pokud je žádost o přijetí změn schválena nebo pokud neexistuje žádný krok schválení, větev funkce se sloučí do hlavní větve.

4. Sloučení do hlavní větve aktivuje proces sestavení a vydání pro vývojové prostředí.

   a. Kanál CI se aktivuje ze sloučení do hlavní větve. Kanál CI provede všechny kroky v kanálu žádosti o přijetí změn a následující kroky:

   • Tok experimentování
   • Tok vyhodnocení
   • Registrace toku v registru Machine Learning při zjištění změn

   b. Kanál CI se dokončí a pak aktivuje kanál CD. 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í verze. Po schválení se procesy CI/CD opakují a cílí na testovací prostředí. Kroky a. a b. jsou stejné, s tím rozdílem, že akceptační testy uživatelů se spouštějí po orientačních testech v testovacím prostředí.

6. Procesy CI/CD se spustí, aby po ověření a schválení testovacího prostředí podporovaly vydání do produkčního prostředí.

7. Po vydání do živého prostředí dojde k provozním úlohám monitorování metrik výkonu a vyhodnocení nasazených jazykových modelů. Mezi tyto úkoly patří:

   • Detekce posunu dat
   • Pozorování infrastruktury.
   • Správa nákladů.
   • Komunikace výkonu modelu se zúčastněnými stranami

Pokyny pro nasazení

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

• Pomocí modrých zelených nasazení můžete bezpečně nasadit novou verzi webové služby omezené skupině uživatelů nebo požadavků, než nasměrujete veškerý provoz do nového nasazení.

• K nasazení nového chování použijte testování A/B. Testování A/B umožňuje podmnožině uživatelů vyhodnotit účinky 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.

• Při nasazování toku do pracovního prostoru Machine Learning v izolované síti použijte agenta v místním prostředí k nasazení artefaktů do prostředků Azure.

• Registr modelů Machine Learning aktualizujte pouze v případech, kdy dojde ke změnám modelu.

• Ujistěte se, že jazykové modely, toky a uživatelské rozhraní klienta jsou volně svázané. Měli byste být schopni aktualizovat toky a uživatelské rozhraní klienta, aniž by to ovlivnilo model a naopak.

• Při vývoji a nasazení několika toků by měl mít každý tok svůj vlastní životní cyklus. Tento přístup pomáhá volně spojit toky, když je propagujete 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é. Životní cyklus ostatních komponent jsou svázané s nasazením. Spravovaná virtuální síť je základní a při vytváření výpočetní instance se automaticky zřídí, takže je potřeba zvážit následující komponenty.

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 nasazení modelu. Tyto prostředky se obvykle nasazují jednou jako součást základního nasazení týmem úloh. Tým úloh pak tyto prostředky udržuje odděleně od vytváření, odebírání nebo aktualizace toků výzvy nebo nasazení modelu. Mezi tyto komponenty patří:

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

Dočasné komponenty

Některé prostředky Azure jsou úzce propojené 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ými 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 předchozí instance z nich se odeberou. Některé z těchto prostředků jsou 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 v rámci kanálu CD změní.

• 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žijete IaC a nemáte v Bicep výpočetní prostředky Azure AI Foundry, spravovaná virtuální síť se nenasadí a při připojení k portálu Azure AI Foundry se zobrazí chyba. Po nasazení IaC je potřeba ručně zřídit 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 používáte IaC, můžete projekty nasadit do samostatných skupin prostředků nastavením jiné skupiny prostředků v Bicep. Pokud používáte portál, můžete vlastnost defaultWorkspaceResourceGroup v části workspaceHubConfig nastavit na skupinu prostředků, ve které chcete vytvářet projekty.

Efektivita výkonu

Efektivita výkonu odkazuje na schopnost vaší úlohy efektivně škálovat tak, aby splňovala požadavky 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 AI Search, Azure OpenAI a Machine Learning.

Efektivita výkonu ve vyhledávání AI

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

Efektivita výkonu v Azure OpenAI

• Určete, jestli vaše aplikace vyžaduje zřízenou propustnost , nebo model sdíleného hostování nebo spotřeby. Zřízená propustnost pomáhá zajistit rezervovanou kapacitu zpracování pro nasazení modelu OpenAI. Rezervovaná kapacita 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 problémům na platformě.

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

Efektivita výkonu ve službě Machine Learning

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. Automatické škálování pomáhá úzce sladit 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. Pokud chcete najít optimální konfiguraci, otestujte výkon nižších 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.

Nasazení tohoto scénáře

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

Přispěvatelé

Microsoft udržuje tento článek. Tento článek napsali následující přispěvatelé.

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

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

Další krok

směrný plán Azure OpenAI v cílové zóně Azure

Související prostředky

• Perspektiva architektury Well-Architected na úlohy AI v Azure
• Azure OpenAI
• Jazykové modely Azure OpenAI
• tok výzvy na portálu Azure AI Foundry
• Izolace virtuální sítě spravovaná pracovním prostorem
• Konfigurace privátního koncového bodu pro pracovní prostor Machine Learning
• Filtrování obsahu