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

Podnikové chatovací aplikace umožňují zaměstnancům prostřednictvím konverzační interakce. To platí zejména z důvodu průběžného pokroku velkých jazykových modelů, jako jsou modely GPT OpenAI a modely LLaMA meta. Tyto chatovací aplikace se skládají z uživatelského rozhraní pro chatování, úložiště dat obsahující informace specifické pro doménu, které se týkají dotazů uživatele, velkých jazykových modelů (LLM), 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 poskytuje základní architekturu pro sestavování a nasazování podnikových chatovacích aplikací, které používají velké jazykové modely Azure OpenAI. Architektura využívá tok výzvy Azure Machine Učení (AML) k vytvoření spustitelných toků, které orchestrují pracovní postup z příchozích výzev do úložišť dat, aby se načítá základní data pro LLM spolu s jakoukoli jinou požadovanou logikou Pythonu. Spustitelný tok se nasadí do počítače Azure Učení výpočetního clusteru 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 se službami Azure PaaS prostřednictvím integrace virtuální sítě přes privátní koncové body. Stejně tak služba App Service chatového uživatelského rozhraní komunikuje se spravovaným online koncovým bodem pro tok přes privátní koncový bod a veřejný přístup k pracovnímu prostoru Azure Machine Učení je zakázaný.

Pracovní prostor Učení počítače 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 služby Azure Machine Učení compute.

Architektura

Obrázek 1: Základní komplexní architektura chatu s OpenAI

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

Komponenty

Mnoho komponent této architektury je stejné jako prostředky ve webové aplikaci služby App Services podle směrného plánu, protože hostování uživatelského rozhraní chatu v této architektuře se řídí základní architekturou webové aplikace App Service. Komponenty zvýrazněné v této části se zaměřují na komponenty používané k vytváření a orchestraci toků chatu a datových služeb a služeb, které zpřístupňují LLM.

• Azure Machine Učení je spravovaná cloudová služba, která se používá k trénování, nasazování a správě modelů strojového učení. Tato architektura používá několik dalších funkcí služby Azure Machine Učení sloužících k vývoji a nasazování spustitelných toků pro aplikace AI využívajících velké jazykové modely:
  • Azure Machine Učení tok výzvy je vývojový nástroj, který umožňuje vytvářet, vyhodnocovat a nasazovat toky, které propojují výzvy uživatelů, akce prostřednictvím kódu Pythonu a volání LLM. 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 LLM.
  • 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 Azure Machine Učení.
• Azure Storage slouží k zachování zdrojových souborů toku výzvy pro vývoj toků.
• Azure 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ě Azure Container Registry.
• Azure OpenAI je plně spravovaná služba, která poskytuje přístup rozhraní REST API k velkým 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í. Azure AI Search je součástí architektury, protože se jedná o běžnou službu používanou v tocích za chatovacími aplikacemi. Azure AI Search se dá použít k načtení a indexování dat, která jsou relevantní pro dotazy uživatelů. Tok výzvy implementuje model RAG Retrieval Rozšířená generace k extrahování příslušného dotazu z výzvy, dotazování vyhledávání AI a použití výsledků jako podkladových dat pro model Azure OpenAI.

Tok výzvy ke službě Azure Machine Učení

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 (otázka nebo direktiva) se extrahuje z výzvy back-endem.
• (volitelné) Back-end určuje úložiště dat obsahující data, která jsou 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 LLM.
• Back-end vrátí výsledek tak, 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. V této architektuře se pro Azure Machine Učení tok výzvy vybral, protože nabízí 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 LLM.

Sítě

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

• Jeden zabezpečený vstupní bod pro přenosy v uživatelském rozhraní chatu
• Síťový provoz se filtruje.
• Přenášená data se šifrují kompletním šifrováním tls.
• Exfiltrace dat je minimalizovaná díky zachování provozu v Azure pomocí služby Private Link.
• Síťové prostředky jsou logicky seskupené a izolované od sebe prostřednictvím segmentace sítě.

Toky sítě

Obrázek 2: Toky sítě pro základní komplexní architekturu chatu s OpenAI

Dva toky v tomto diagramu jsou popsané ve webové aplikaci služby App Services podle směrného plánu: 1. příchozí tok od koncového uživatele do uživatelského rozhraní chatu a 2. tok služeb App Service do Azure PaaS. Podrobnosti o těchto tocích najdete v tomto článku. Tato část se zaměřuje na tok online koncového bodu služby Azure Machine Učení. Následující podrobnosti o toku z chatovacího uživatelského rozhraní spuštěného v základní webové aplikaci App Service do toku nasazeného do služby Azure Machine Učení 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 Učení online koncového bodu Azure Machine.
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 Azure Machine Učení

V této architektuře je veřejný přístup k pracovnímu prostoru Azure Machine Učení zakázaný a přístup může probíhat prostřednictvím privátního přístupu, protože se řídí privátním koncovým bodem konfigurace pracovního prostoru Azure Machine Učení. 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 povolením připojení uživatelského rozhraní chatu hostovaného ve službě App Service ke službám PaaS, které nejsou přístupné veřejnému internetu, včetně koncových bodů azure Machine Učení.

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

Obrázek 3: Toky sítě pro počítač Azure Učení autora toku výzvy

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 toho jump boxu se autor může připojit k pracovnímu prostoru Učení počítač prostřednictvím privátního koncového bodu ve stejné síti jako jump box. Připojení ivitu pro virtuální síť je také možné provést prostřednictvím bran ExpressRoute nebo bran VPN a partnerského vztahu virtuálních sítí.

Tok ze spravované virtuální sítě Azure Machine Učení do služeb Azure PaaS

Doporučuje se, aby byl pracovní prostor Azure Machine Učení nakonfigurovaný pro izolaci spravované virtuální sítě s konfigurací, 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 Azure Container Registry a Azure Storage. Pravidla odchozích přenosů definovaná uživatelem se vztahují na vlastní prostředky, jako je Azure OpenAI nebo Azure AI Search, které bude váš pracovní postup používat. Je vaší zodpovědností nakonfigurovat pravidla odchozích přenosů definovaná uživatelem, zatímco požadovaná pravidla odchozích přenosů 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 pro externí veřejné koncové body. V této architektuře se připojení ke službám Azure, jako je Azure Container Registry, Azure Storage, Azure Key Vault, služba Azure OpenAI a Azure 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 a 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í:

• 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ě, 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 poskytuje název a funkci pravidla.

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 ochranu před útoky DDoS 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ě. Měli byste použít nejtužší pravidla, která umožňují plnou funkčnost řešení.
• Používejte skupiny zabezpečení aplikací. Skupiny zabezpečení aplikací umožňují seskupit skupiny zabezpečení sítě, což usnadňuje vytváření pravidel pro složitá prostředí.

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

Služba 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í LLM). 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. Nastavení byste měli upravit podle svých požadavků.

Kromě filtrování obsahu služba Azure OpenAI implementuje 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. Můžete požádat o výjimku monitorování zneužití a kontroly lidí , například 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 pro detekci zneužití.

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. Projděte si směrný plán 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ě služby Azure Machine Učení, Azure OpenAI a Azure AI Search.

Zónová redundance pro nasazení toků

Podniková nasazení obvykle vyžadují alespoň zónovou redundanci. Aby toho bylo možné dosáhnout v Azure, prostředky musí podporovat zóny dostupnosti a musíte nasadit alespoň instance prostředku nebo povolit podporu platformy, pokud není řízení instancí dostupné. Azure Machine Učení Compute v současné době nenabízí podporu zón dostupnosti. Pokud chcete zmírnit potenciální dopad katastrofy na úrovni datacentra na komponenty AML, je nutné vytvořit clustery v různých oblastech spolu s nasazením nástroje pro vyrovnávání zatížení pro distribuci volání mezi tyto clustery. Kontroly stavu byste použili k zajištění toho, 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 Azure Machine Učení. 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 (ACA) a Aplikace Azure Service. Každá z těchto služeb podporuje zóny dostupnosti. Pokud chcete dosáhnout zónové redundance pro provádění toku výzvy bez větší složitosti nasazení ve více oblastech, měli byste své toky nasadit do jedné z těchto služeb.

Následuje alternativní architektura, kde se do služby Aplikace Azure Service nasadí 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.

Obrázek 4: Alternativní komplexní architektura chatu s nasazením toků výzvy OpenAI do Aplikace Azure Services

Diagram je očíslován pro oblasti, které jsou v této architektuře důležité:

1. Toky jsou stále vytvořené ve službě Azure Machine Učení tok výzvy a architektura sítě Azure Machine Učení se nezmě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 při testování toků používají k připojení ke službám Azure.
2. Tato tečkovaná čára označuje, že kontejnerizované spustitelné toky se odesílají do služby Azure Container Registry (ACR). V diagramu se nezobrazují kanály, které kontejnerizují toky a odesílají je do ACR.
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é mezi zóny dostupnosti. Tyto instance služby App Service se při načítání image kontejneru toku výzvy připojují k ACR 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, která by byla služba Azure AI Search a Azure OpenAI. Služby PaaS, které byly vystaveny pouze podsíti privátního koncového bodu spravované službou AML, 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. Kontroly stavu byste použili k zajištění toho, 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 Azure Storage. Tím se minimalizuje stav uložený ve službě Azure OpenAI pro každou oblast. Aby bylo možné hostovat nasazení modelu, bude potřeba provést jemné ladění na instanci.

Je důležité monitorovat požadovanou propustnost z hlediska tokenů za minutu (TPM) a požadavků za minutu (RPM), abyste zajistili, že jste z kvóty přiřadili dostatek čipu 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 (APIM), je možné nasadit před vaše služby OpenAI a je možné ji nakonfigurovat pro opakování v případě přechodných chyb a omezování. APIM se dá použít také jako jistič , aby se zabránilo zahlcení služby voláním a překročení kvóty.

Azure AI Search – spolehlivost

Nasaďte službu Azure AI Search s cenovou úrovní Standard nebo vyšší v oblasti, která podporuje zóny dostupnosti a nasazuje 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:

• Postupujte podle pokynů k monitorování služby Azure AI Search.
• Pomocí metrik monitorování 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ů, abyste se vyhnuli omezování založenému na indexech.

Azure Machine Učení – spolehlivost

Pokud nasadíte do výpočetních clusterů za koncovým bodem Azure Machine Učení spravovaným online koncovým bodem, zvažte následující pokyny týkající se škálování:

• Postupujte podle pokynů k automatickému škálování online koncových bodů , abyste měli jistotu, ž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í, aby se zabránilo 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 App 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.

Zabezpečení sítě bylo popsáno v části Sítě. Tato část popisuje správu identit a přístupu a aspekty 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 AML:
  • Pracovní prostor – používá se při vytváření a správě toku.
  • Výpočetní instance – používá se při testování toků.
  • Online koncový bod – používaný nasazeným tokem, pokud je nasazený do spravovaného online koncového bodu
• Implementace řízení přístupu identit pro uživatelské rozhraní chatu pomocí Id Microsoft Entra

Role RBAC pro Azure Machine Učení

Ke správě přístupu k pracovnímu prostoru Učení Azure Machine Učení můžete použít pět výchozích rolí: AzureML Datoví vědci, operátor výpočetní služby AzureML, čtenář, přispěvatel a vlastník. Spolu s těmito výchozími rolemi je k dispozici i azureML Workspace Připojení ion Secrets Reader a uživatel registru AzureML, který uděluje 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žších oprávnění tím, že přiřadíte role pouze výše uvedeným identitám, kde se vyžadují. Následuje přiřazení rolí.

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 azure machine Učení spravovaný online koncový bod. 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 Azure Key Vault pro přístup na vyžádání od autorizovaných klientů (jako je azure Web App hostující kontejner toku výzvy).
• Implementujte strategii obměně klíčů. Pokud klíče ručně otočíte, měli byste vytvořit zásadu vypršení platnosti klíče a pomocí zásad Azure monitorovat, jestli se klíč otočil.

Vyladění modelu OpenAI

Pokud ve své implementaci dolaďujete modely OpenAI, zvažte následující doprovodné materiály:

• Pokud nahráváte 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, použití spravované identity k řízení přístupu k datům a privátního koncového bodu pro připojení k datům.

Efektivita výkonu

Efektivita výkonu je schopnost úlohy škálovat se tak, aby efektivním způsobem splňovala požadavky, které na ni kladou uživatelé. Další informace najdete v tématu Přehled pilíře efektivity výkonu.

Tato část popisuje efektivitu výkonu z pohledu služby Azure Search, Azure OpenAI a azure machine Učení.

Azure Search – efektivita výkonu

Postupujte podle pokynů k analýze výkonu ve službě Azure AI Search.

Azure OpenAI – Efektivita výkonu

• Určete, jestli vaše aplikace vyžaduje zřízenou propustnost , nebo bude používat model sdíleného hostování (consumption). Zřízená propustnost nabízí rezervovanou kapacitu zpracování pro nasazení modelu OpenAI a poskytuje předvídatelný výkon a propustnost vašich modelů. Tento fakturační model je na rozdíl od modelu sdíleného hostování (consumption), který je nejvhodnější a může být vystaven hlučným sousedům nebo jiným stresorům na platformě.
• Pro zřízenou propustnost byste měli monitorovat využití spravované zřizováním.

Azure Machine Učení – efektivita výkonu

Pokud se nasazuje do azure Machine Učení online koncových bodů:

• Postupujte podle pokynů k automatickému škálování online koncového bodu , abyste zůstali v souladu s poptávkou bez nadměrného zřizování, 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. Chcete otestovat 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.

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 tématu Přehled pilíře optimalizace nákladů.

Pokud chcete zobrazit příklad cen pro tento scénář, použijte cenovou kalkulačku Azure. Budete muset přizpůsobit příklad tak, aby odpovídal vašemu využití, protože tento příklad obsahuje jenom komponenty zahrnuté v architektuře. Nejnákladnější komponenty ve scénáři jsou výpočetní prostředí chatu a výpočetní prostředí Azure AI Search a Azure AI Search. Proto se podívejte na optimalizaci těchto prostředků, abyste ušetřili největší náklady.

Compute

Azure Machine Učení tok výzvy podporuje několik možností pro hostování spustitelných toků. Mezi možnosti patří spravované online koncové body ve službě Azure Machine Učení, Azure Kubernetes Service, Aplikace Azure Service a Azure Container 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 ve službě 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, jako je například ří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 (klíče nebo řízení přístupu na základě role).
  • 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 u předprodukčních instancí, takže tyto aktivity neúčtují 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. Použitím správného modelu pro případ použití se můžete ujistit, ž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. Abyste mohli být nejúčinnější, budete chtít využít tolik času, kolik času je k dispozici za hodinu, abyste zlepšili výsledky jemného ladění a vyhnuli se tak pouhému vyklouznutí do dalšího fakturačníhoobdobího Stejně tak jsou náklady na 100 obrázků z generování imagí stejné jako náklady na 1 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í, vyhodnoťte přechod na tento předprodejní model fakturace, pokud se počítá tak, že bude nákladově efektivnější ve vašem objemu využití.
• Nastavte limity zřizování – Zajistěte, aby byla všechna kvóta zřizování přidělená pouze modelům, u které se očekává, že budou součástí úlohy, a to na základě jednotlivých modelů. Propustnost pro již nasazené modely nejsou omezena na tuto zřízenou kvótu, pokud je povolená dynamická kvóta. Všimněte si, že kvóta se nemapuje přímo na náklady a náklady se mohou lišit.
• Monitorování využití průběžných plateb – Pokud používáte průběžné platby, monitorujte využití tokenů za minutu (TPM) a žádosti za minutu (RPM). Tyto informace slouží k informování rozhodnutí o návrhu architektury, jako jsou modely, které se mají použít, a také k optimalizaci velikostí výzev.
• Monitorování 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ů pomocí OpenAI ke sledová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.

Operace s velkými jazykovými modely (LLMOps)

Nasazení chatových řešení založených na Azure OpenAI, jako je tato architektura, by mělo postupovat podle pokynů v LLMOps s tokem výzvy s Azure DevOps a GitHubem. Kromě toho musí zvážit osvědčené postupy pro architektury CI/CD a 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 azure machine Učení nabízí prostředí pro vytváření obsahu založené na prohlížeči v studio Azure Machine Learning nebo prostřednictvím rozšíření VS Code. Obě možnosti ukládají kód toku jako soubory. Při použití studio Azure Machine Learning se soubory ukládají do účtu úložiště Azure. Při práci ve VS 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.

V případě podnikového vývoje byste měli použít rozšíření VS Code a sadu SDK nebo rozhraní příkazového řádku 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. 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í

Toky použité v chatovací aplikaci byste měli otestovat stejně jako testovat jiné softwarové artefakty. Zadání a uplatnění jediné "správné" odpovědi pro výstupy LLM je náročné, ale k vyhodnocení odpovědí můžete použít samotný LLM. Zvažte implementaci následujících automatizovaných vyhodnocení toků LLM:

• Přesnost klasifikace: Vyhodnotí, jestli LLM poskytne "správné" nebo "nesprávné" skóre a agreguje výsledky tak, aby vytvořily známku 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.
• Groundedness Against Context: Vyhodnocuje, jak dobře jsou predikované odpovědi modelu založeny na předkonfigurovaném kontextu. I když jsou odpovědi LLM správné, pokud 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 LLM k vygenerování jakýchkoli dat ve zlaté datové sadě.

Tok nasazení

Obrázek 5: Nasazení toku výzvy

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 VS 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ě:

   a. 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 ve službě Azure Machine Učení Registry při zjištění změn.

   b. Kanál CD se aktivuje po dokončení kanálu CI. Tento tok provádí následující kroky:

   • Nasadí tok ze služby Azure Machine Učení Registry do Učení online koncového bodu Azure Machine.
   • 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ého LLM. 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 k nasazení

Koncové body služby Azure Machine Učení umožňují 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: Nasazení modrá/zelená jsou efektivní nejen pro bezpečné zavádění změn, ale také je možné je 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.
• Při nasazování toku do pracovního prostoru Azure machine izolovaného v síti Učení použijte k nasazení artefaktů do prostředků Azure agenta v místním prostředí.
• Registr modelů služby Azure Machine Učení by se měl aktualizovat pouze v případě, že dojde ke změnám modelu.
• LLM, toky a uživatelské rozhraní klienta by měly být volně svázány. Aktualizace tokům a uživatelskému rozhraní klienta může a mělo by být možné provést 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

Při nasazování základních komponent chatu Azure OpenAI jsou některé zřízené služby v rámci architektury 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 služby Azure Machine Learning
• Účet azure Storage pro pracovní prostor Azure Machine Učení
• Azure Container Registry
• Azure AI Vyhledávač
• 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 propojené s návrhem konkrétních toků výzvy, což 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. Jsou ovlivněné 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 se 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ů azure Machine Učení 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 Učení Azure Machine 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 azure machine Učení se aktualizují při nasazení nebo odstranění toku.
• Key Vault pro uživatelské rozhraní klienta musí být při vytvoření nového koncového bodu aktualizován klíčem na koncový bod.

Sledování

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

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ší kroky

Další informace o Azure OpenAI

Související prostředky

• Azure OpenAI
• Velké jazykové modely Azure OpenAI
• Tok výzvy ke službě Azure Machine Učení
• Izolace virtuální sítě spravovaná pracovním prostorem
• Konfigurace privátního koncového bodu pro pracovní prostor služby Azure Machine Learning
• Filtrování obsahu