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 azure Machine Learning 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 výpočetního clusteru Machine Learning za spravovaným online koncovým bodem.

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 Services. 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 pracovnímu prostoru Machine Learning je zakázaný.

Pracovní prostor Machine Learning 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.

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í architektuře webové aplikace App Service, protože metoda, kterou používáte k hostování uživatelského rozhraní chatu, je v obou architekturách stejná. Komponenty zvýrazněné v této části se zaměřují na komponenty používané k vytváření a orchestraci toků chatu, datových služeb a služeb, které zpřístupňují jazykové modely.

• Machine Learning je spravovaná cloudová služba, kterou můžete použít k trénování, nasazování a správě modelů strojového učení. Tato architektura používá několik dalších funkcí strojového učení, které se používají k vývoji a nasazování spustitelných toků pro aplikace AI, které využívají jazykové modely:

  • Tok výzvy služby Machine Learning je vývojový nástroj, který můžete použít k sestavení, vyhodnocení a nasazení toků, které propojují výzvy uživatelů, akce prostřednictvím kódu Pythonu a volání modelů jazykového učení. Tok výzvy se v této architektuře používá jako vrstva, která orchestruje toky mezi výzvou, různými úložišti dat a jazykový model.

  • Spravované online koncové body umožňují nasadit tok pro odvozování v reálném čase. V této architektuře se používají jako koncový bod PaaS pro uživatelské rozhraní chatu k vyvolání toků výzvy hostovaných službou Machine Learning.

• Úložiště slouží k zachování zdrojových souborů toku výzvy pro vývoj toků.

• Container Registry umožňuje vytvářet, ukládat a spravovat image kontejnerů a artefakty v privátním registru pro všechny typy nasazení kontejnerů. V této architektuře jsou toky zabalené jako image kontejnerů a uložené ve službě Container Registry.

• 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í. V této architektuře se kromě přístupu k modelům používá k přidání běžných podnikových funkcí, jako jsou virtuální síť a privátní propojení, podpora spravované identity a filtrování obsahu.

• Azure AI Search je cloudová vyhledávací služba, která podporuje fulltextové vyhledávání, sémantické vyhledávání, vektorové vyhledávání a hybridní vyhledávání. Funkce AI Search je součástí architektury, protože se jedná o běžnou službu používanou v tocích za chatovacími aplikacemi. Vyhledávání AI se dá použít k načtení a indexování dat, která jsou relevantní pro dotazy uživatelů. Tok výzvy implementuje model rozšířené generace načítání RAG, který extrahuje příslušný dotaz z výzvy, dotazování vyhledávání AI a použije výsledky jako podkladová data pro model Azure OpenAI.

Tok výzvy služby Machine Learning

Back-end pro podnikové chatovací aplikace obecně používá podobný vzor jako v následujícím toku:

• Uživatel zadá výzvu do uživatelského rozhraní vlastního chatu.
• Tato výzva se odešle do back-endu kódem rozhraní.
• Záměr uživatele( dotaz nebo direktiva) se extrahuje z výzvy back-endem.
• Volitelně back-end určuje úložiště dat, která obsahují data relevantní pro výzvu uživatele.
• Back-end se dotazuje na příslušná úložiště dat.
• Back-end odešle záměr, relevantní podkladová data a veškerou historii uvedenou v výzvě k jazykovému modelu.
• Back-end vrátí výsledek, aby se mohl zobrazit v uživatelském rozhraní.

Back-end je možné implementovat v libovolném počtu jazyků a nasadit je do různých služeb Azure. Tato architektura používá tok výzvy machine learningu, protože poskytuje zjednodušené prostředí pro sestavování, testování a nasazování toků, které orchestrují mezi výzvami, back-endovými úložišti dat a jazykovými modely.

Moduly runtime toku výzvy

Machine Learning může přímo hostovat dva typy modulů runtime toku výzvy.

• Automatický modul runtime: Bezserverová výpočetní možnost, která spravuje životní cyklus a charakteristiky výkonu výpočetních prostředků a umožňuje přizpůsobení prostředí řízené tokem.

• Modul runtime výpočetních instancí: Možnost always-on compute, ve které tým úloh musí vybrat charakteristiky výkonu. Tento modul runtime nabízí větší přizpůsobení a kontrolu nad prostředím.

Toky výzvy se dají hostovat také externě ve výpočetních prostředcích Machine Learning na hostitelských hostitelských platformách kontejnerů. Tato architektura používá službu App Service k předvedení externího hostování.

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 z virtuální sítě spravované službou Machine Learning do služeb Azure PaaS

Doporučujeme nakonfigurovat pracovní prostor Machine Learning 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ě.

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énování – nepoužívá se pro trénování modelů v této architektuře.
• 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í.

Monitorování filtrování obsahu a zneužití

Azure OpenAI obsahuje systém filtrování obsahu, který používá soubor klasifikačních modelů k detekci a zabránění určitým kategoriím potenciálně škodlivého obsahu ve vstupních výzev i dokončení výstupu. Kategorie pro tento potenciálně škodlivý obsah zahrnují nenávist, sexuální, sebepoškozování, násilí, vulgární výrazy a jailbreak (obsah navržený tak, aby obešel omezení jazykového modelu). Můžete nakonfigurovat striktnost toho, co chcete filtrovat obsah pro každou kategorii, přičemž možnosti jsou nízké, střední nebo vysoké. Tato referenční architektura přijímá striktní přístup. Upravte nastavení podle svých požadavků.

Kromě filtrování obsahu implementuje Azure OpenAI funkce monitorování zneužití. Monitorování zneužití je asynchronní operace navržená tak, aby detekovala a zmírňovala výskyty opakovaného obsahu nebo chování, které navrhují použití služby způsobem, který může narušit pravidla chování Azure OpenAI. Pokud jsou vaše data vysoce citlivá nebo pokud existují interní zásady nebo platné právní předpisy, které brání zpracování dat za účely detekce zneužití, můžete požádat o výjimku z monitorování zneužití a kontrolu lidí .

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

Nasazení toků výzvy není omezené na výpočetní clustery Machine Learning. Spustitelný tok, který je kontejnerizovanou aplikací, 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 Functions, Azure 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ě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 Machine Learning a síťová architektura Machine Learning se nemění. Autoři toku se stále připojují k prostředí pro vytváření pracovních prostorů 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.

3. Do stejného plánu služby App Service je nasazená jiná webová aplikace, která už 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, který už běží minimálně tři instance, rozložené napříč zónami 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 splňuje poptávku vašich nasazení, a zajistěte, aby se zabránilo omezování volání nasazených modelů. Bránu, jako je Azure API Management, je možné nasadit před službu OpenAI nebo služby 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.

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.

Machine Learning – spolehlivost

Pokud nasadíte do výpočetních clusterů za online koncovým bodem spravovaným službou 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.

Zabezpečení

Tato architektura implementuje síť i hraniční síť zabezpečení identit. 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 aspekty správy identit a přístupu a zabezpečení pro obměnu klíčů a vyladění modelu Azure OpenAI.

Správa identit a přístupu

Následující doprovodné materiály rozšiřují pokyny pro správu identit a přístupu v směrném plánu služby App Service:

• Pokud je to možné, vytvořte samostatné spravované identity pro následující prostředky služby Machine Learning:
  • Pracovní prostory pro vytváření a správu toků
  • Výpočetní instance pro testování 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

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

Existuje pět výchozích rolí, které můžete použít ke správě přístupu k pracovnímu prostoru Machine Learning: AzureML Datoví vědci, operátor výpočetních prostředků AzureML, čtenář, přispěvatel a vlastník. Kromě těchto výchozích rolí je k dispozici čtečka tajných kódů připojení pracovního prostoru AzureML Learning a uživatel registru AzureML, který může udělit přístup k prostředkům pracovního prostoru, jako jsou tajné kódy pracovního prostoru a registr.

Tato architektura se řídí principem nejnižšího oprávnění tím, že přiřazuje role pouze předchozím identitám, kde jsou povinné. Zvažte následující přiřazení rolí.

Spravovaná identita	Obor	Přiřazení rolí
Spravovaná identita pracovního prostoru	Skupina prostředků	Přispěvatel
Spravovaná identita pracovního prostoru	Účet úložiště pracovního prostoru	Přispěvatel dat objektů blob úložiště
Spravovaná identita pracovního prostoru	Účet úložiště pracovního prostoru	Přispěvatel dat souboru úložiště s privilegovaným přístupem
Spravovaná identita pracovního prostoru	Key Vault pracovního prostoru	Správce služby Key Vault
Spravovaná identita pracovního prostoru	Container Registry pracovního prostoru	AcrPush
Spravovaná identita online koncového bodu	Container Registry pracovního prostoru	AcrPull
Spravovaná identita online koncového bodu	Účet úložiště pracovního prostoru	Čtenář dat v objektech blob služby Storage
Spravovaná identita online koncového bodu	Pracovní prostor Machine Learning	Čtečka tajných kódů připojení pracovního prostoru AzureML
Spravovaná identita výpočetní instance	Container Registry pracovního prostoru	AcrPull
Spravovaná identita výpočetní instance	Účet úložiště pracovního prostoru	Čtenář dat v objektech blob služby Storage

Obměna klíčů

V této architektuře jsou dvě služby, které používají ověřování založené na klíčích: Azure OpenAI a online koncový bod spravované službou Machine Learning. Vzhledem k tomu, že pro tyto služby 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 monitorujte, 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.

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 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 machine Learning 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 popisuje 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.

Machine Learning – integrované moduly runtime toku výzvy

Aby se minimalizovala provozní zátěž, je automatický modul runtime bezserverovou 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í

Diagnostika se konfiguruje pro všechny služby. Všechny služby, ale Machine Learning a App Service jsou nakonfigurované tak, aby zaznamenávaly všechny protokoly. Diagnostika machine learningu je nakonfigurovaná tak, aby zaznamenávala protokoly auditu, které jsou všechny protokoly prostředků, které zaznamenávají interakce zákazníků s daty nebo nastavením služby. Služba App Service je nakonfigurovaná tak, aby zachytila protokoly AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs a AppServicePlatformLogs.

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

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 LLMOps s využitím toku výzvy 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í LLMOps. 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 machine Learning nabízí prostředí pro vytváření obsahu založené na prohlížeči v nástroji Machine Learning Studio nebo prostřednictvím rozšíření Visual Studio Code. Obě možnosti ukládají kód toku jako soubory. Při použití nástroje Machine Learning Studio se soubory 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.

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.

Efektivita výkonu

Efektivita výkonu je schopnost vaší úlohy efektivně škálovat tak, aby splňovala požadavky, které na ni můžou uživatelé umístit. 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
• Tok výzvy služby Machine Learning
• Izolace virtuální sítě spravovaná pracovním prostorem
• Konfigurace privátního koncového bodu pro pracovní prostor Machine Learning
• Filtrování obsahu