Referensarkitektur för openAI från slutpunkt till slutpunkt

Företagschattprogram kan hjälpa anställda genom konversationsinteraktion. Detta gäller särskilt på grund av den kontinuerliga utvecklingen av språkmodeller, till exempel OpenAI:s GPT-modeller och Metas LLaMA-modeller. Dessa chattprogram består av ett användargränssnitt (UI), datalagringsplatser som innehåller domänspecifik information som är relevant för användarens frågor, språkmodeller som resonerar över domänspecifika data för att skapa ett relevant svar och en dirigerator som övervakar interaktionen mellan dessa komponenter.

Den här artikeln innehåller en baslinjearkitektur för att skapa och distribuera företagschattprogram som använder språkmodeller för Azure OpenAI-tjänsten. Arkitekturen använder Azure Machine Learning-promptflödet för att skapa körbara flöden. Dessa körbara flöden samordnar arbetsflödet från inkommande uppmaningar till datalager för att hämta grunddata för språkmodellerna, tillsammans med annan nödvändig Python-logik. Det körbara flödet distribueras till ett Machine Learning-beräkningskluster bakom en hanterad onlineslutpunkt.

Värdskapet för användargränssnittet för anpassad chatt följer riktlinjerna för webbprogram för apptjänster för baslinje för distribution av ett säkert, zonredundant och högtillgängligt webbprogram i Azure App Services. I den arkitekturen kommunicerar App Service med Lösningen Azure Platform as a Service (PaaS) via integrering av virtuella nätverk via privata slutpunkter. Chattgränssnittets App Service kommunicerar med den hanterade onlineslutpunkten för flödet över en privat slutpunkt. Offentlig åtkomst till Machine Learning-arbetsytan är inaktiverad.

Machine Learning-arbetsytan är konfigurerad med hanterad isolering av virtuella nätverk som kräver att alla utgående anslutningar godkänns. Med den här konfigurationen skapas ett hanterat virtuellt nätverk tillsammans med hanterade privata slutpunkter som möjliggör anslutning till privata resurser, till exempel azure storage på arbetsplatsen, Azure Container Registry och Azure OpenAI. Dessa privata anslutningar används under flödesredigering och testning samt av flöden som distribueras till Machine Learning-beräkning.

Arkitektur

Ladda ned en Visio-fil med den här arkitekturen.

Komponenter

Många av komponenterna i den här arkitekturen är desamma som resurserna i apptjänstens baslinjearkitektur för webbprogram eftersom den metod som du använder för att vara värd för chattgränssnittet är densamma i båda arkitekturerna. Komponenterna som är markerade i det här avsnittet fokuserar på de komponenter som används för att skapa och samordna chattflöden, datatjänster och de tjänster som exponerar språkmodellerna.

• Machine Learning är en hanterad molntjänst som du kan använda för att träna, distribuera och hantera maskininlärningsmodeller. Den här arkitekturen använder flera andra funktioner i Machine Learning som används för att utveckla och distribuera körbara flöden för AI-program som drivs av språkmodeller:

  • Machine Learning Prompt Flow är ett utvecklingsverktyg som du kan använda för att skapa, utvärdera och distribuera flöden som länkar användarfrågor, åtgärder via Python-kod och anrop till språkinlärningsmodeller. Promptflöde används i den här arkitekturen som det lager som orkestrerar flöden mellan prompten, olika datalager och språkmodellen.

  • Med hanterade onlineslutpunkter kan du distribuera ett flöde för slutsatsdragning i realtid. I den här arkitekturen används de som en PaaS-slutpunkt för chattgränssnittet för att anropa de promptflöden som hanteras av Machine Learning.

• Lagring används för att spara källfilerna för promptflöde för utveckling av promptflöden.

• Med Container Registry kan du skapa, lagra och hantera containeravbildningar och artefakter i ett privat register för alla typer av containerdistributioner. I den här arkitekturen paketeras flöden som containeravbildningar och lagras i Container Registry.

• Azure OpenAI är en fullständigt hanterad tjänst som ger REST API-åtkomst till Azure OpenAI:s språkmodeller, inklusive GPT-4, GPT-3.5-Turbo och inbäddning av modeller. I den här arkitekturen används den förutom modellåtkomst för att lägga till vanliga företagsfunktioner som virtuellt nätverk och privat länk, stöd för hanterad identitet och innehållsfiltrering.

• Azure AI Search är en molnsökningstjänst som stöder fulltextsökning, semantisk sökning, vektorsökning och hybridsökning. AI Search ingår i arkitekturen eftersom det är en vanlig tjänst som används i flödena bakom chattprogram. AI Search kan användas för att hämta och indexeras data som är relevanta för användarfrågor. Promptflödet implementerar mönstret RAG Retrieval Augmented Generation för att extrahera lämplig fråga från prompten, fråga AI Search och använda resultaten som grunddata för Azure OpenAI-modellen.

Machine Learning-promptflöde

Serverdelen för företagschattprogram följer vanligtvis ett mönster som liknar följande flöde:

• Användaren anger en uppmaning i ett anpassat chattanvändargränssnitt (UI).
• Uppmaningen skickas till serverdelen av gränssnittskoden.
• Användar avsikten, antingen fråga eller direktiv, extraheras från prompten av serverdelen.
• Alternativt avgör serverdelen de datalager som innehåller data som är relevanta för användarens uppmaning
• Serverdelen frågar relevanta datalager.
• Serverdelen skickar avsikten, relevanta grunddata och all historik som anges i uppmaningen till språkmodellen.
• Serverdelen returnerar resultatet så att det kan visas i användargränssnittet.

Serverdelen kan implementeras på valfritt antal språk och distribueras till olika Azure-tjänster. Den här arkitekturen använder Machine Learning-snabbflöde eftersom det ger en smidig upplevelse att skapa, testa och distribuera flöden som samordnar mellan prompter, serverdelsdatalager och språkmodeller.

Prompt flow runtimes

Machine Learning kan vara direkt värd för två typer av promptflödeskörningar.

• Automatisk körning: Ett serverlöst beräkningsalternativ som hanterar livscykeln och prestandaegenskaperna för beräkningen och tillåter flödesdriven anpassning av miljön.

• Körning av beräkningsinstanser: Ett alltid på-beräkningsalternativ där arbetsbelastningsteamet måste välja prestandaegenskaperna. Den här körningen ger mer anpassning och kontroll över miljön.

Prompt-flöden kan också hanteras externt till Machine Learning-beräkning på värdcontainervärdplattformar. Den här arkitekturen använder App Service för att demonstrera extern värd.

Nätverk

Tillsammans med identitetsbaserad åtkomst är nätverkssäkerhet kärnan i den grundläggande chattarkitekturen från slutpunkt till slutpunkt som använder OpenAI. Från en hög nivå säkerställer nätverksarkitekturen att:

• Endast en enda säker startpunkt för chattgränssnittstrafik.
• Nätverkstrafik filtreras.
• Data under överföring krypteras från slutpunkt till slutpunkt med TLS (Transport Layer Security).
• Dataexfiltrering minimeras genom att använda Private Link för att behålla trafiken i Azure.
• Nätverksresurser grupperas logiskt och isoleras från varandra via nätverkssegmentering.

Nätverksflöden

Två flöden i det här diagrammet beskrivs i apptjänstarkitekturens baslinje: Inkommande flöde från slutanvändaren till chattgränssnittet (1) och flödet från App Service till Azure PaaS-tjänster (2). Det här avsnittet fokuserar på Machine Learnings onlineslutpunktsflöde. Följande flöde går från chattgränssnittet som körs i apptjänstens baslinjewebbprogram till flödet som distribueras till Machine Learning-beräkning:

1. Samtalet från det App Service-värdbaserade chattgränssnittet dirigeras via en privat slutpunkt till Machine Learning-slutpunkten online.
2. Onlineslutpunkten dirigerar anropet till en server som kör det distribuerade flödet. Onlineslutpunkten fungerar både som lastbalanserare och router.
3. Anrop till Azure PaaS-tjänster som krävs av det distribuerade flödet dirigeras via hanterade privata slutpunkter.

Ingress till Machine Learning

I den här arkitekturen inaktiveras offentlig åtkomst till Machine Learning-arbetsytan. Användare kan komma åt arbetsytan via privat åtkomst eftersom arkitekturen följer den privata slutpunkten för konfigurationen av Machine Learning-arbetsytan . I själva verket används privata slutpunkter i hela den här arkitekturen för att komplettera identitetsbaserad säkerhet. Ditt App Service-värdbaserade chattgränssnitt kan till exempel ansluta till PaaS-tjänster som inte exponeras för det offentliga Internet, inklusive Machine Learning-slutpunkter.

Privat slutpunktsåtkomst krävs också för att ansluta till Machine Learning-arbetsytan för flödesredigering.

Diagrammet visar en promptflödesförfattare som ansluter via Azure Bastion till en hoppruta för virtuella datorer. Från den hopprutan kan författaren ansluta till Machine Learning-arbetsytan via en privat slutpunkt i samma nätverk som hopprutan. Anslut ivity to the virtual network could also be accomplished through ExpressRoute or VPN gateways and virtual network peering.

Flöda från det Maskininlärningshanterade virtuella nätverket till Azure PaaS-tjänster

Vi rekommenderar att du konfigurerar Machine Learning-arbetsytan för hanterad virtuell nätverksisolering som kräver att alla utgående anslutningar godkänns. Den här arkitekturen följer den rekommendationen. Det finns två typer av godkända regler för utgående trafik. De utgående regler som krävs är till resurser som krävs för att lösningen ska fungera, till exempel Container Registry och Storage. Användardefinierade regler för utgående trafik är anpassade resurser, till exempel Azure OpenAI eller AI Search, som arbetsflödet kommer att använda. Du måste konfigurera användardefinierade regler för utgående trafik. Obligatoriska regler för utgående trafik konfigureras när det hanterade virtuella nätverket skapas.

Utgående regler kan vara privata slutpunkter, tjänsttaggar eller fullständigt kvalificerade domännamn (FQDN) för externa offentliga slutpunkter. I den här arkitekturen ansluts anslutningar till Azure-tjänster som Container Registry, Storage, Azure Key Vault, Azure OpenAI och AI Search via privat länk. Även om det inte finns i den här arkitekturen hämtar vissa vanliga åtgärder som kan kräva att du konfigurerar en utgående FQDN-regel ett pip-paket, klonar en GitHub-lagringsplats eller laddar ned bascontaineravbildningar från externa lagringsplatser.

Segmentering och säkerhet för virtuella nätverk

Nätverket i den här arkitekturen har separata undernät i följande syften:

• Application Gateway
• Integreringskomponenter för App Service
• Privata slutpunkter
• Azure Bastion
• Virtuell jump box-dator
• Utbildning – används inte för modellträning i den här arkitekturen
• Resultat

Varje undernät har en nätverkssäkerhetsgrupp (NSG) som begränsar både inkommande och utgående trafik för dessa undernät till precis vad som krävs. I följande tabell visas en förenklad vy över de NSG-regler som baslinjen lägger till i varje undernät. Tabellen innehåller regelnamnet och funktionen.

Undernät	Inkommande	Utgående
snet-appGateway	Traktamenten för våra chattanvändargränssnittsanvändares käll-IP-adresser (till exempel offentligt Internet) plus nödvändiga objekt för tjänsten.	Åtkomst till den privata Slutpunkten för App Service, plus nödvändiga objekt för tjänsten.
snet-PrivateEndpoints	Tillåt endast trafik från det virtuella nätverket.	Tillåt endast trafik till det virtuella nätverket.
snet-AppService	Tillåt endast trafik från det virtuella nätverket.	Tillåt åtkomst till de privata slutpunkterna och Azure Monitor.
AzureBastionSubnet	Se vägledning för att arbeta med NSG-åtkomst och Azure Bastion.	Se vägledning för att arbeta med NSG-åtkomst och Azure Bastion.
snet-jumpbox	Tillåt inkommande RDP och SSH från Azure Bastion-värdundernätet.	Tillåt åtkomst till de privata slutpunkterna
snet-agents	Tillåt endast trafik från det virtuella nätverket.	Tillåt endast trafik till det virtuella nätverket.
snet-training	Tillåt endast trafik från det virtuella nätverket.	Tillåt endast trafik till det virtuella nätverket.
snet-scoring	Tillåt endast trafik från det virtuella nätverket.	Tillåt endast trafik till det virtuella nätverket.

All annan trafik nekas uttryckligen.

Tänk på följande när du implementerar segmentering och säkerhet för virtuella nätverk.

• Aktivera DDoS-skydd för det virtuella nätverket med ett undernät som ingår i en programgateway med en offentlig IP-adress.

• Lägg till en NSG i varje undernät där det är möjligt. Använd de striktaste reglerna som aktiverar fullständiga lösningsfunktioner.

• Använd programsäkerhetsgrupper för att gruppera NSG:er. Gruppering av NSG:er gör det enklare att skapa regler för komplexa miljöer.

Övervakning av innehållsfiltrering och missbruk

Azure OpenAI innehåller ett system för innehållsfiltrering som använder en uppsättning klassificeringsmodeller för att identifiera och förhindra specifika kategorier av potentiellt skadligt innehåll i både indataprompter och slutföranden av utdata. Kategorier för detta potentiellt skadliga innehåll omfattar hat, sexuell, självskada, våld, svordomar och jailbreak (innehåll som är utformat för att kringgå begränsningarna i en språkmodell). Du kan konfigurera striktheten för det du vill filtrera innehållet för varje kategori, med alternativ som låg, medel eller hög. Den här referensarkitekturen använder en strikt metod. Justera inställningarna enligt dina krav.

Utöver innehållsfiltrering implementerar Azure OpenAI funktioner för övervakning av missbruk. Övervakning av missbruk är en asynkron åtgärd som är utformad för att identifiera och minimera instanser av återkommande innehåll eller beteenden som tyder på användning av tjänsten på ett sätt som kan bryta mot Azure OpenAI-uppförandekoden. Du kan begära undantag från övervakning av missbruk och mänsklig granskning om dina data är mycket känsliga eller om det finns interna principer eller tillämpliga juridiska föreskrifter som förhindrar bearbetning av data för identifiering av missbruk.

Tillförlitlighet

App Service-baslinjearkitekturen för webbprogram fokuserar på zonredundans för viktiga regionala tjänster. Tillgänglighetszoner är fysiskt separata platser i en region. De tillhandahåller redundans i en region för stödtjänster när två eller flera instanser distribueras i dem. När en zon drabbas av stilleståndstid kan de andra zonerna i regionen fortfarande inte påverkas. Arkitekturen säkerställer också att tillräckligt många instanser av Azure-tjänster och konfiguration av dessa tjänster sprids över tillgänglighetszoner. Mer information finns i baslinjen för att granska den vägledningen.

Det här avsnittet tar upp tillförlitlighet utifrån de komponenter i den här arkitekturen som inte behandlas i App Service-baslinjen, inklusive Machine Learning, Azure OpenAI och AI Search.

Zonredundans för flödesdistributioner

Företagsdistributioner kräver vanligtvis zonredundans. För att uppnå zonredundans i Azure måste resurser ha stöd för tillgänglighetszoner och du måste distribuera minst tre instanser av resursen eller aktivera plattformsstöd när instanskontroll inte är tillgänglig. Machine Learning-beräkning erbjuder för närvarande inte stöd för tillgänglighetszoner. För att minska den potentiella effekten av en katastrof på datacenternivå på Machine Learning-komponenter är det nödvändigt att upprätta kluster i olika regioner tillsammans med att distribuera en lastbalanserare för att distribuera anrop mellan dessa kluster. Du kan använda hälsokontroller för att säkerställa att anrop endast dirigeras till kluster som fungerar korrekt.

Distribution av promptflöden är inte begränsat till Machine Learning-beräkningskluster. Det körbara flödet, som är ett containerbaserat program, kan distribueras till alla Azure-tjänster som är kompatibla med containrar. De här alternativen omfattar tjänster som Azure Kubernetes Service (AKS), Azure Functions, Azure Container Apps och App Service. Var och en av dessa tjänster stöder tillgänglighetszoner. Om du vill uppnå zonredundans för körning av promptflöde, utan den extra komplexiteten i en distribution i flera regioner, bör du distribuera dina flöden till en av dessa tjänster.

Följande diagram visar en alternativ arkitektur där promptflöden distribueras till App Service. App Service används i den här arkitekturen eftersom arbetsbelastningen redan använder den för chattgränssnittet och inte skulle ha nytta av att introducera en ny teknik i arbetsbelastningen. Arbetsbelastningsteam som har erfarenhet av AKS bör överväga att distribuera i den miljön, särskilt om AKS används för andra komponenter i arbetsbelastningen.

Diagrammet är numrerat för viktiga områden i den här arkitekturen:

1. Flöden har fortfarande skapats i Machine Learning-promptflödet och Machine Learning-nätverksarkitekturen är oförändrad. Flödesförfattare ansluter fortfarande till arbetsytans redigeringsupplevelse via en privat slutpunkt, och de hanterade privata slutpunkterna används för att ansluta till Azure-tjänster vid testning av flöden.

2. Den här streckade linjen anger att containerbaserade körbara flöden skickas till Container Registry. Visas inte i diagrammet är pipelines som containeriserar flödena och push-överför till Container Registry.

3. Det finns en annan webbapp som distribueras till samma App Service-plan som redan är värd för chattgränssnittet. Den nya webbappen är värd för det containerbaserade promptflödet, som samlokaliserats på samma App Service-plan som redan körs på minst tre instanser, spridda över tillgänglighetszoner. Dessa App Service-instanser ansluter till Container Registry via en privat slutpunkt när du läser in containeravbildningen för promptflöde.

4. Containern för promptflöde måste ansluta till alla beroende tjänster för flödeskörning. I den här arkitekturen ansluter containern för promptflöde till AI Search och Azure OpenAI. PaaS-tjänster som endast exponerades för det hanterade privata slutpunktsundernätet för Machine Learning måste nu också exponeras i det virtuella nätverket så att siktlinjen kan upprättas från App Service.

Azure OpenAI – tillförlitlighet

Azure OpenAI stöder för närvarande inte tillgänglighetszoner. För att minska den potentiella effekten av en katastrof på datacenternivå på modelldistributioner i Azure OpenAI är det nödvändigt att distribuera Azure OpenAI till olika regioner tillsammans med att distribuera en lastbalanserare för att distribuera anrop mellan regionerna. Du kan använda hälsokontroller för att säkerställa att anrop endast dirigeras till kluster som fungerar korrekt.

För att stödja flera instanser effektivt rekommenderar vi att du externaliserar finjusteringsfiler, till exempel till ett geo-redundant lagringskonto. Den här metoden minimerar det tillstånd som lagras i Azure OpenAI för varje region. Du måste fortfarande finjustera filer för varje instans som värd för modelldistributionen.

Det är viktigt att övervaka det dataflöde som krävs när det gäller token per minut (TPM) och begäranden per minut (RPM). Se till att tillräckligt med TPM u tilldelat från din kvot för att uppfylla efterfrågan på dina distributioner och förhindra att anrop till dina distribuerade modeller begränsas. En gateway som Azure API Management kan distribueras framför din OpenAI-tjänst eller dina tjänster och kan konfigureras för återförsök om det finns tillfälliga fel och begränsningar. API Management kan också användas som kretsbrytare för att förhindra att tjänsten överbelastas med anrop och överskrider kvoten.

AI Search – tillförlitlighet

Distribuera AI Search med prisnivån Standard eller högre i en region som stöder tillgänglighetszoner och distribuera tre eller fler repliker. Replikerna sprids automatiskt jämnt över tillgänglighetszoner.

Överväg följande vägledning för att fastställa lämpligt antal repliker och partitioner:

• Övervaka AI-sökning.

• Använd övervakningsmått, loggar och prestandaanalys för att fastställa lämpligt antal repliker för att undvika frågebaserad begränsning och partitioner och för att undvika indexbaserad begränsning.

Maskininlärning – tillförlitlighet

Om du distribuerar till beräkningskluster bakom den Machine Learning-hanterade onlineslutpunkten bör du överväga följande vägledning om skalning:

• Skala dina onlineslutpunkter automatiskt för att säkerställa att det finns tillräckligt med kapacitet för att möta efterfrågan. Om användningssignaler inte är tillräckligt lägliga på grund av burst-användning bör du överväga överetablering för att förhindra att för få instanser blir tillgängliga.

• Överväg att skapa skalningsregler baserat på distributionsmått som CPU-belastning och slutpunktsmått , till exempel svarstid för begäranden.

• Inte mindre än tre instanser ska distribueras för en aktiv produktionsdistribution.

• Undvik distributioner mot instanser som används. Distribuera i stället till en ny distribution och flytta trafik över när distributionen är redo att ta emot trafik.

Säkerhet

Den här arkitekturen implementerar både ett nätverk och en identitetssäkerhetsperimeter. Från ett nätverksperspektiv är det enda som ska vara tillgängligt från Internet chattgränssnittet via Application Gateway. Från ett identitetsperspektiv bör chattgränssnittet autentisera och auktorisera begäranden. Hanterade identiteter används där det är möjligt för att autentisera program till Azure-tjänster.

I det här avsnittet beskrivs identitets- och åtkomsthantering och säkerhetsöverväganden för nyckelrotation och finjustering av Azure OpenAI-modellen.

Identitets- och åtkomsthantering

Följande vägledning utökar vägledningen för identitets- och åtkomsthantering i App Service-baslinjen:

• Skapa separata hanterade identiteter för följande Machine Learning-resurser, om tillämpligt:
  • Arbetsytor för flödesredigering och hantering
  • Beräkningsinstanser för att testa flöden
  • Onlineslutpunkter i det distribuerade flödet om flödet distribueras till en hanterad onlineslutpunkt
• Implementera identitetsåtkomstkontroller för chattgränssnittet med hjälp av Microsoft Entra-ID

Rollbaserade åtkomstroller för Maskininlärning

Det finns fem standardroller som du kan använda för att hantera åtkomst till din Machine Learning-arbetsyta: AzureML Dataforskare, AzureML Compute Operator, Reader, Contributor och Owner. Tillsammans med dessa standardroller finns det en AzureML Learning-arbetsyta Anslut ion Secrets Reader och en AzureML-registeranvändare som kan ge åtkomst till arbetsyteresurser som arbetsytehemligheter och register.

Den här arkitekturen följer principen om lägsta behörighet genom att endast tilldela roller till de föregående identiteterna där de krävs. Överväg följande rolltilldelningar.

Hanterad identitet	Omfattning	Rolltilldelningar
Hanterad identitet för arbetsyta	Resursgrupp	Deltagare
Hanterad identitet för arbetsyta	Lagringskonto för arbetsyta	Storage Blob datadeltagare
Hanterad identitet för arbetsyta	Lagringskonto för arbetsyta	Priviligierad medhjälpare för lagringsfildata
Hanterad identitet för arbetsyta	Nyckelvalv för arbetsyta	Key Vault-administratör
Hanterad identitet för arbetsyta	Containerregister för arbetsyta	AcrPush
Hanterad identitet för onlineslutpunkt	Containerregister för arbetsyta	AcrPull
Hanterad identitet för onlineslutpunkt	Lagringskonto för arbetsyta	Läsare av lagringsblobdata
Hanterad identitet för onlineslutpunkt	Machine Learning-arbetsyta	AzureML Workspace Anslut ion Secrets Reader
Hanterad identitet för beräkningsinstans	Containerregister för arbetsyta	AcrPull
Hanterad identitet för beräkningsinstans	Lagringskonto för arbetsyta	Läsare av lagringsblobdata

Nyckelrotation

Det finns två tjänster i den här arkitekturen som använder nyckelbaserad autentisering: Azure OpenAI och den Machine Learning-hanterade onlineslutpunkten. Eftersom du använder nyckelbaserad autentisering för dessa tjänster är det viktigt att:

• Lagra nyckeln i ett säkert arkiv, till exempel Key Vault, för åtkomst på begäran från auktoriserade klienter, till exempel Azure Web App som är värd för containern för promptflöde.

• Implementera en nyckelroteringsstrategi. Om du roterar nycklarna manuellt skapar du en nyckel förfalloprincip och använder Azure Policy för att övervaka om nyckeln har roterats.

Finjustering av OpenAI-modell

Om du finjusterar OpenAI-modeller i implementeringen bör du överväga följande vägledning:

• Om du laddar upp träningsdata för finjustering kan du överväga att använda kundhanterade nycklar för att kryptera dessa data.

• Om du lagrar träningsdata i ett lager, till exempel Azure Blob Storage, bör du överväga att använda en kundhanterad nyckel för datakryptering, en hanterad identitet för att styra åtkomsten till data och en privat slutpunkt för att ansluta till data.

Styrning via princip

Överväg att använda Azure Policy och nätverksprincip för att säkerställa att säkerheten överensstämmer med kraven för arbetsbelastningen. Användningen av plattformsautomatisering via princip minskar belastningen för manuella valideringssteg och säkerställer styrning även om pipelines kringgås. Överväg följande säkerhetsprinciper:

• Inaktivera nyckelåtkomst eller annan lokal autentiseringsåtkomst i tjänster som Azure AI-tjänster och Key Vault.
• Kräv specifik konfiguration av regler för nätverksåtkomst eller NSG:er.
• Kräv kryptering, till exempel användning av kundhanterade nycklar.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Checklista för designgranskning för kostnadsoptimering.

Om du vill se ett prisexempel för det här scenariot använder du Priskalkylatorn för Azure. Du måste anpassa exemplet så att det matchar din användning eftersom det här exemplet endast innehåller de komponenter som ingår i arkitekturen. De dyraste komponenterna i scenariot är chattgränssnittet och promptflödesberäkningen och AI Search. Optimera dessa resurser för att spara mest kostnad.

Compute

Machine Learning-promptflödet har stöd för flera alternativ för att vara värd för körbara flöden. Alternativen omfattar hanterade onlineslutpunkter i Machine Learning, AKS, App Service och Azure Container Service. Vart och ett av dessa alternativ har en egen faktureringsmodell. Valet av beräkning påverkar den totala kostnaden för lösningen.

Azure OpenAI

Azure OpenAI är en förbrukningsbaserad tjänst, och precis som med alla förbrukningsbaserade tjänster är det den primära kostnadskontrollen att kontrollera efterfrågan mot tillgång. För att göra det specifikt i Azure OpenAI måste du använda en kombination av metoder:

• Kontrollera klienter. Klientbegäranden är den primära kostnadskällan i en förbrukningsmodell, så det är viktigt att kontrollera klientbeteendet. Alla klienter bör:

  • Godkänns. Undvik att exponera tjänsten på ett sådant sätt att den stöder kostnadsfri åtkomst för alla. Begränsa åtkomsten både via nätverks- och identitetskontroller, till exempel nycklar eller rollbaserad åtkomstkontroll (RBAC).

  • Var självkontrollerad. Kräv att klienter använder de tokenbegränsningsbegränsningar som erbjuds av API-anropen, till exempel max_tokens och max_completions.

  • Använd batchbearbetning, där det är praktiskt. Granska klienterna för att se till att de är rätt batchbearbetningsprompter.

  • Optimera promptens indata och svarslängd. Längre uppmaningar förbrukar fler token, vilket ökar kostnaden, men uppmaningar som saknar tillräcklig kontext hjälper inte modellerna att ge bra resultat. Skapa koncisa frågor som ger tillräckligt med kontext för att modellen ska kunna generera ett användbart svar. På samma sätt ser du till att du optimerar gränsen för svarslängden.

• Azure OpenAI Playground-användning bör vara vid behov och på förproduktionsinstanser, så att dessa aktiviteter inte medför produktionskostnader.

• Välj rätt AI-modell. Modellval spelar också en stor roll i den totala kostnaden för Azure OpenAI. Alla modeller har styrkor och svagheter och prissätts individuellt. Använd rätt modell för användningsfallet för att se till att du inte överskrider en dyrare modell när en billigare modell ger godtagbara resultat. I den här chattreferensimplementeringen valdes GPT 3.5-turbo över GPT-4 för att spara ungefär en storleksordning på modelldistributionskostnader samtidigt som tillräckliga resultat uppnåddes.

• Förstå brytpunkter för fakturering. Finjustering debiteras per timme. För att vara den mest effektiva vill du använda så mycket av den tillgängliga tiden per timme för att förbättra finjusteringsresultatet samtidigt som du undviker att bara glida in i nästa faktureringsperiod. På samma sätt är kostnaden för 100 bilder från bildgenereringen samma som kostnaden för en bild. Maximera prisbrytpunkterna till din fördel.

• Förstå faktureringsmodeller. Azure OpenAI är också tillgängligt i en åtagandebaserad faktureringsmodell via det etablerade dataflödeserbjudandet . När du har förutsägbara användningsmönster kan du överväga att byta till den här förköpsfaktureringsmodellen om den är mer kostnadseffektiv på din användningsvolym.

• Ange etableringsgränser. Se till att all etableringskvot endast allokeras till modeller som förväntas ingå i arbetsbelastningen per modell. Dataflödet till redan distribuerade modeller är inte begränsat till den här etablerade kvoten medan dynamisk kvot är aktiverad. Kvoten mappas inte direkt till kostnader och den kostnaden kan variera.

• Övervaka användning med betala per användning. Om du använder betala per användning-priser övervakar du användningen av TPM och RPM. Använd den informationen för att informera arkitekturdesignbeslut som vilka modeller som ska användas och optimera promptstorlekar.

• Övervaka etablerad dataflödesanvändning. Om du använder etablerat dataflöde övervakar du etableringshanterad användning för att säkerställa att du inte underanvänder det etablerade dataflödet som du har köpt.

• Kostnadshantering. Följ vägledningen om hur du använder funktioner för kostnadshantering med OpenAI för att övervaka kostnader, ange budgetar för att hantera kostnader och skapa aviseringar för att meddela intressenter om risker eller avvikelser.

Driftsäkerhet

Driftskvalitet beskriver de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i Checklista för designgranskning för Operational Excellence.

Machine Learning – inbyggda körningskörningar för promptflöden

För att minimera driftbelastningen är automatisk körning ett serverlöst beräkningsalternativ i Machine Learning som förenklar beräkningshanteringen och delegerar det mesta av konfigurationen av promptflöde till det program som kör programmets requirements.txt fil och flow.dag.yaml konfiguration. Detta gör det här valet lågt underhåll, tillfälliga och programdrivna. Om du använder Compute Instance Runtime eller externaliserad beräkning, till exempel i den här arkitekturen, krävs en mer teamhanterad livscykel för arbetsbelastningen och bör väljas när arbetsbelastningskraven överskrider konfigurationsfunktionerna för alternativet automatisk körning.

Övervakning

Diagnostik konfigureras för alla tjänster. Alla tjänster utom Machine Learning och App Service är konfigurerade för att samla in alla loggar. Machine Learning-diagnostiken är konfigurerad för att avbilda granskningsloggarna som är alla resursloggar som registrerar kundinteraktioner med data eller inställningarna för tjänsten. App Service har konfigurerats för att samla in AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs och AppServicePlatformLogs.

Utvärdera att skapa anpassade aviseringar för resurserna i den här arkitekturen, till exempel de som finns i Azure Monitor-baslinjeaviseringar. Till exempel:

• Container Registry-aviseringar
• Machine Learning- och Azure OpenAI-aviseringar
• Azure Web Apps-aviseringar

Språkmodellåtgärder

Distribution för Azure OpenAI-baserade chattlösningar som den här arkitekturen bör följa riktlinjerna i LLMOps med promptflöde med Azure DevOps och GitHub. Dessutom måste den överväga metodtips för kontinuerlig integrering och kontinuerlig leverans (CI/CD) och nätverksskyddade arkitekturer. Följande vägledning tar upp implementeringen av flöden och deras associerade infrastruktur baserat på LLMOps-rekommendationerna. Den här distributionsvägledningen innehåller inte klientdelsappelementen, som inte är oförändrade från i arkitekturen För zonredundant webbprogram med hög tillgänglighet.

Utveckling

Machine Learning Prompt Flow erbjuder både en webbläsarbaserad redigeringsupplevelse i Machine Learning Studio eller via ett Visual Studio Code-tillägg. Båda alternativen lagrar flödeskoden som filer. När du använder Machine Learning Studio lagras filerna i ett lagringskonto. När du arbetar i VS Code lagras filerna i ditt lokala filsystem.

För att kunna följa metodtipsen för samarbetsutveckling bör källfilerna underhållas på en lagringsplats för källkod online, till exempel GitHub. Den här metoden underlättar spårning av alla kodändringar, samarbete mellan flödesförfattare och integrering med distributionsflöden som testar och validerar alla kodändringar.

För företagsutveckling använder du VS Code-tillägget och SDK/CLI för promptflöde för utveckling. Frågeflödesförfattare kan skapa och testa sina flöden från VS Code och integrera de lokalt lagrade filerna med online-källkontrollsystemet och pipelines. Även om den webbläsarbaserade upplevelsen lämpar sig väl för undersökande utveckling, kan den med lite arbete integreras med källkontrollsystemet. Flödesmappen kan laddas ned från flödessidan i panelen Files , packas upp och push-överföras till källkontrollsystemet.

Utvärdering

Testa de flöden som används i ett chattprogram precis som du testar andra programvaruartefakter. Det är svårt att ange och hävda ett enda "rätt" svar för språkmodellutdata, men du kan använda en språkmodell för att utvärdera svar. Överväg att implementera följande automatiserade utvärderingar av dina språkmodellflöden:

• Klassificeringsnoggrannhet: Utvärderar om språkmodellen ger en "korrekt" eller "felaktig" poäng och aggregerar utfallet för att ge ett noggrannhetsbetyg.

• Koherens: Utvärderar hur väl meningarna i en modells förutsagda svar skrivs och hur de på ett sammanhängande sätt ansluter till varandra.

• Fluency(Fluency): Utvärderar modellens förutsagda svar för dess grammatiska och språkliga noggrannhet.

• Grund för kontext: Utvärderar hur väl modellens förutsagda svar baseras på förkonfigurerad kontext. Även om språkmodellsvaren är korrekta, om de inte kan verifieras mot den angivna kontexten, baseras inte sådana svar.

• Relevans: Utvärderar hur väl modellens förutsagda svar överensstämmer med den fråga som ställs.

Tänk på följande när du implementerar automatiserade utvärderingar:

• Skapa poäng från utvärderingar och mät dem mot ett fördefinierat tröskelvärde för lyckade resultat. Använd dessa poäng för att rapportera testpass/fel i dina pipelines.

• Vissa av dessa tester kräver förkonfigurerade dataindata för frågor, kontext och grundsanning.

• Inkludera tillräckligt många par med frågesvar för att säkerställa att testresultaten är tillförlitliga, med minst 100–150 par som rekommenderas. Dessa frågesvarspar kallas för din "gyllene datauppsättning". En större population kan krävas beroende på datamängdens storlek och domän.

• Undvik att använda språkmodeller för att generera någon av data i din gyllene datauppsättning.

Distributionsflöde

1. Frågeteknikern/dataexperten öppnar en funktionsgren där de arbetar med den specifika uppgiften eller funktionen. Frågeteknikern/dataexperten itererar flödet med hjälp av promptflöde för VS Code, genomför regelbundet ändringar och push-överför dessa ändringar till funktionsgrenen.

2. När den lokala utvecklingen och experimenteringen har slutförts öppnar frågeteknikern/dataexperten en pull-begäran från funktionsgrenen till main-grenen. Pull-begäran (PR) utlöser en PR-pipeline. Den här pipelinen kör snabba kvalitetskontroller som bör omfatta:

   • Körning av experimenteringsflöden
   • Körning av konfigurerade enhetstester
   • Kompilering av kodbasen
   • Analys av statisk kod

3. Pipelinen kan innehålla ett steg som kräver att minst en teammedlem godkänner pr manuellt innan den slås samman. Godkännaren kan inte vara åtagandet och de har snabb flödesexpertis och kunskaper om projektkraven. Om pr inte godkänns blockeras sammanfogningen. Om pr-begäran godkänns, eller om det inte finns något godkännandesteg, sammanfogas funktionsgrenen till main-grenen.

4. Kopplingen till Main utlöser bygg- och lanseringsprocessen för utvecklingsmiljön. Specifikt:

   a. CI-pipelinen utlöses från sammanfogningen till Main. CI-pipelinen utför alla steg som utförs i PR-pipelinen och följande steg:

   • Experimenteringsflöde
   • Utvärderingsflöde
   • Registrerar flödena i Machine Learning Registry när ändringar identifieras

   b. CD-pipelinen utlöses när CI-pipelinen har slutförts. Det här flödet utför följande steg:

   • Distribuerar flödet från Machine Learning-registret till en Machine Learning-slutpunkt online
   • Kör integreringstester som riktar sig mot onlineslutpunkten
   • Kör röktester som riktar sig mot onlineslutpunkten

5. En godkännandeprocess är inbyggd i lanseringsprocessen – vid godkännande beskrivs CI & CD-processerna i steg 4.a. & 4.b. upprepas och riktar in sig på testmiljön. Steg a. och b. är desamma, förutom att användargodkännandetester körs efter röktesterna i testmiljön.

6. Ci- och CD-processerna som beskrivs i steg 4.a. &4.b. körs för att flytta upp versionen till produktionsmiljön när testmiljön har verifierats och godkänts.

7. När de har släppts i en livemiljö utförs de operativa uppgifterna för att övervaka prestandamått och utvärdera de distribuerade språkmodellerna. Detta inkluderar men är inte begränsat till:

   • Identifiera dataavvikelser
   • Observera infrastrukturen
   • Hantera kostnader
   • Kommunicera modellens prestanda till intressenter

Riktlinjer för distribution

Du kan använda Machine Learning-slutpunkter för att distribuera modeller på ett sätt som möjliggör flexibilitet när du släpper till produktion. Överväg följande strategier för att säkerställa bästa modellprestanda och kvalitet:

• Blå/gröna distributioner: Med den här strategin kan du distribuera din nya version av webbtjänsten på ett säkert sätt till en begränsad grupp användare eller begäranden innan du dirigerar all trafik till den nya distributionen.

• A/B-testning: Inte bara är blå/gröna distributioner effektiva för att distribuera ändringar på ett säkert sätt, de kan också användas för att distribuera nya beteenden som gör att en delmängd användare kan utvärdera effekten av ändringen.

• Inkludera lintning av Python-filer som ingår i promptflödet i dina pipelines. Linting söker efter efterlevnad av formatstandarder, fel, kodkomplexitet, oanvänd import och variabelnamngivning.

• När du distribuerar flödet till den nätverksisolerade Machine Learning-arbetsytan använder du en lokalt installerad agent för att distribuera artefakter till dina Azure-resurser.

• Machine Learning-modellregistret bör bara uppdateras när det finns ändringar i modellen.

• Språkmodellerna, flödena och klientgränssnittet bör vara löst kopplade. Uppdateringar till flöden och klientgränssnittet kan och bör kunna göras utan att påverka modellen och vice versa.

• När du utvecklar och distribuerar flera flöden bör varje flöde ha en egen livscykel, vilket ger en löst kopplad upplevelse när du främjar flöden från experimentering till produktion.

Infrastruktur

När du distribuerar grundläggande Azure OpenAI-chattkomponenter från slutpunkt till slutpunkt är vissa av de tjänster som tillhandahålls grundläggande och permanenta i arkitekturen, medan andra komponenter är mer tillfälliga, deras existens är kopplad till en distribution.

Grundläggande komponenter

Vissa komponenter i den här arkitekturen finns med en livscykel som sträcker sig bortom varje enskilt promptflöde eller någon modelldistribution. Dessa resurser distribueras vanligtvis en gång som en del av den grundläggande distributionen av arbetsbelastningsteamet och underhålls förutom nya, borttagna eller uppdateringar av promptflödena eller modelldistributionerna.

• Machine Learning-arbetsyta
• Lagringskonto för Machine Learning-arbetsytan
• Container Registry
• AI-sökning
• Azure OpenAI
• Azure Application Insights
• Azure Bastion
• Azure Virtual Machine för jump-rutan

Tillfälliga komponenter

Vissa Azure-resurser är mer nära kopplade till utformningen av specifika promptflöden. Med den här metoden kan dessa resurser bindas till komponentens livscykel och bli tillfälliga i den här arkitekturen. Azure-resurser påverkas när arbetsbelastningen utvecklas, till exempel när flöden läggs till eller tas bort eller när nya modeller introduceras. Dessa resurser återskapas och tidigare instanser tas bort. Vissa av dessa resurser är direkta Azure-resurser och vissa är dataplansmanifestationer i deras innehållande tjänst.

• Modellen i Machine Learning-modellregistret bör uppdateras, om den ändras, som en del av CD-pipelinen.

• Containeravbildningen bör uppdateras i containerregistret som en del av CD-pipelinen.

• En Machine Learning-slutpunkt skapas när ett promptflöde distribueras om distributionen refererar till en slutpunkt som inte finns. Slutpunkten måste uppdateras för att inaktivera offentlig åtkomst.

• Machine Learning-slutpunktens distributioner uppdateras när ett flöde distribueras eller tas bort.

• Nyckelvalvet för klientgränssnittet måste uppdateras med nyckeln till slutpunkten när en ny slutpunkt skapas.

Prestandaeffektivitet

Prestandaeffektivitet är arbetsbelastningens förmåga att effektivt skala för att uppfylla användarnas krav. Mer information finns i Checklista för designgranskning för prestandaeffektivitet.

I det här avsnittet beskrivs prestandaeffektivitet ur Azure Search-, Azure OpenAI- och Machine Learning-perspektiv.

Azure Search – prestandaeffektivitet

Följ vägledningen för att analysera prestanda i AI Search.

Azure OpenAI – prestandaeffektivitet

• Avgör om ditt program kräver etablerat dataflöde eller den delade värdmodellen eller förbrukningsmodellen. Etablerat dataflöde säkerställer reserverad bearbetningskapacitet för dina OpenAI-modelldistributioner, vilket ger förutsägbar prestanda och dataflöde för dina modeller. Den här faktureringsmodellen skiljer sig från modellen för delad värd eller förbrukning. Förbrukningsmodellen är bäst och kan utsättas för bullriga grannar eller andra stressfaktorer på plattformen.

• Övervaka etableringshanterad användning för etablerat dataflöde.

Maskininlärning – prestandaeffektivitet

Om du distribuerar till Machine Learning-slutpunkter online:

• Följ vägledningen om hur du autoskalar en onlineslutpunkt. Gör detta för att hålla dig nära efterfrågan utan överdriven överetablering, särskilt under perioder med låg användning.

• Välj lämplig SKU för virtuella datorer för onlineslutpunkten för att uppfylla dina prestandamål. Testa prestanda för både lägre instansantal och större SKU:er jämfört med större instansantal och mindre SKU:er för att hitta en optimal konfiguration.

Distribuera det här scenariot

Om du vill distribuera och köra referensimplementeringen följer du stegen i referensimplementeringen för OpenAI-referensen från slutpunkt till slutpunkt.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

• Rob Bagby | Mönster och metoder – Microsoft
• Freddy Ayala | Molnlösningsarkitekt – Microsoft
• Prabal Deb | Senior Software Engineer – Microsoft
• Raouf Aliouat | Programvarutekniker II – Microsoft
• Ritesh Modi | Huvudprogramtekniker – Microsoft
• Ryan Pfalz | Senior Solution Architect – Microsoft

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Gå vidare

Relaterade resurser

• Azure OpenAI
• Azure OpenAI-språkmodeller
• Machine Learning-promptflöde
• Arbetsytehanterad virtuell nätverksisolering
• Konfigurera en privat slutpunkt för en Machine Learning-arbetsyta
• Innehållsfiltrering