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 promptflöde 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 en hanterad onlineslutpunkt med hanterad beräkning.

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 Service. 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 Azure AI Studio är inaktiverad.

Azure AI Studio-hubben ä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.

En hubb är den översta Azure AI Studio-resursen som ger ett centralt sätt att styra säkerhet, anslutning och andra problem i flera projekt. Den här arkitekturen kräver bara ett projekt för arbetsbelastningen. Om du har ytterligare funktioner som kräver olika promptflöden med olika logik, eventuellt med olika serverdelsresurser, till exempel datalager, kan du överväga att implementera dem i ett annat projekt.

Arkitektur

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

Komponenter

Många komponenter i den här arkitekturen är samma som den grundläggande chattarkitekturen för Azure OpenAI från slutpunkt till slutpunkt. I följande lista markeras endast ändringarna i den grundläggande arkitekturen.

• Azure OpenAI används i både den grundläggande och den här baslinjearkitekturen. 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. Baslinjearkitekturen drar nytta av företagsfunktioner som virtuellt nätverk och privat länk som den grundläggande arkitekturen inte implementerar.
• Azure AI Studio är en plattform som du kan använda för att skapa, testa och distribuera AI-lösningar. AI Studio används i den här arkitekturen för att skapa, testa och distribuera logiken för orkestrering av promptflöde för chattprogrammet. I den här arkitekturen tillhandahåller Azure AI Studio det hanterade virtuella nätverket för nätverkssäkerhet. Mer information finns i avsnittet om nätverk för mer information.
• Application Gateway är en layer 7-lastbalanserare (HTTP/S) och en webbtrafikrouter. Den använder URL-sökvägsbaserad routning för att distribuera inkommande trafik mellan tillgänglighetszoner och avlasta kryptering för att förbättra programmets prestanda.
• Web Application Firewall (WAF) är en molnbaserad tjänst som skyddar webbappar från vanliga kryphål som SQL-inmatning och skript för flera webbplatser. Brandväggen för webbprogram ger insyn i trafiken till och från ditt webbprogram, så att du kan övervaka och skydda ditt program.
• Azure Key Vault är en tjänst som lagrar och hanterar hemligheter, krypteringsnycklar och certifikat på ett säkert sätt. Det centraliserar hanteringen av känslig information.
• Virtuellt Azure-nätverk är en tjänst som gör att du kan skapa isolerade och säkra privata virtuella nätverk i Azure. För ett webbprogram i App Service behöver du ett undernät för virtuellt nätverk för att använda privata slutpunkter för nätverkssäker kommunikation mellan resurser.
• Private Link gör det möjligt för klienter att komma åt PaaS-tjänster (Plattform som en tjänst) direkt från privata virtuella nätverk utan att använda offentliga IP-adresser.
• Azure DNS är en värdtjänst för DNS-domäner som tillhandahåller namnmatchning med hjälp av Microsoft Azure-infrastrukturen. Privat DNS zoner är ett sätt att mappa en tjänsts fullständigt kvalificerade domännamn (FQDN) till en privat slutpunkts IP-adress.

Alternativ

Den här arkitekturen har flera komponenter som kan hanteras av andra Azure-tjänster som kan anpassas bättre till dina funktionella och icke-funktionella krav för din arbetsbelastning. Här är några sådana alternativ att vara medveten om.

Azure Machine Learning-arbetsytor (och portalupplevelser)

Den här arkitekturen använder Azure AI Studio för att skapa, testa och distribuera promptflöden. Du kan också använda Azure Machine Learning-arbetsytor eftersom båda tjänsterna har överlappande funktioner. Ai Studio är ett bra val om du utformar en lösning för snabbflöde, men det finns vissa funktioner som Azure Machine Learning för närvarande har bättre stöd för. Mer information finns i funktionsjämförelsen. Vi rekommenderar att du inte blandar och matchar Azure AI Studio och Azure Machine Learning. Om ditt arbete kan utföras helt i AI Studio använder du AI Studio. Om du fortfarande behöver funktioner från Azure Machine Learning-studio fortsätter du att använda Azure Machine Learning-studio.

Komponenter på programnivå

Det finns flera erbjudanden för hanterade programtjänster i Azure som kan fungera som programnivå för klientdelen för chattgränssnittet. Se Välj en Azure-beräkningstjänst för all beräkning och Välj en Azure-containertjänst för containerlösningar. Till exempel, medan Azure Web Apps och Web App for Containers valdes för både API:et för chattgränssnittet respektive promptflödesvärden, kan liknande resultat uppnås med Azure Kubernetes Service (AKS) eller Azure Container Apps. Välj din arbetsbelastnings programplattform baserat på arbetsbelastningens specifika funktionella och icke-funktionella krav.

Prompt flow hosting

Distribution av promptflöden är inte begränsat till Machine Learning-beräkningskluster, och den här arkitekturen visar det med ett alternativ i Azure App Service. Flöden är i slutändan ett containerbaserat program som kan distribueras till alla Azure-tjänster som är kompatibla med containrar. Dessa alternativ omfattar tjänster som Azure Kubernetes Service (AKS), Azure Container Apps och Azure App Service. Välj en Azure-containertjänst baserat på orkestreringsskiktets krav.

Ett exempel på varför värdtjänster för promptflöde på en alternativ beräkning är ett övervägande beskrivs senare i den här artikeln.

Datalager för jordning

Även om den här arkitekturen leder med Azure AI Search är ditt val av datalager för dina grunddata ett arkitekturbeslut som är specifikt för din arbetsbelastning. Många arbetsbelastningar är i själva verket flerspråkiga och har olika källor och tekniker för grunddata. Dessa dataplattformar sträcker sig från befintliga OLTP-datalager, molnbaserade databaser som Azure Cosmos DB, via specialiserade lösningar som Azure AI Search. En vanlig, men inte obligatorisk, egenskap för ett sådant datalager är vektorsökning. Se Välj en Azure-tjänst för vektorsökning för att utforska alternativ i det här utrymmet.

Överväganden och rekommendationer

Tillförlitlighet

Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden du gör gentemot dina kunder. Mer information finns i Checklista för designgranskning för 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.

Det finns några alternativ till Machine Learning-beräkningskluster som Azure Kubernetes Service (AKS), Azure Functions, Azure Container Apps och Azure 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 skapas fortfarande i promptflödet och nätverksarkitekturen är oförändrad. Flödesförfattare ansluter fortfarande till redigeringsupplevelsen i AI Studio-projektet 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. Den beräkning där dessa pipelines körs måste ha nätverkslinje för resurser som Azure-containerregistret och AI Studio-projektet.

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 är samlokaliserat i 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 som tilldelats 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 Azure 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. Mer information om hur du lägger till en gateway för tillförlitlighetsproblem finns i Åtkomst till Azure OpenAI och andra språkmodeller via en gateway.

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.

Azure AI Studio – tillförlitlighet

Om du distribuerar till beräkningskluster bakom den Maskininlärningshanterade 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.

Hanterade onlineslutpunkter fungerar som en lastbalanserare och router för den hanterade beräkning som körs bakom dem. Du kan konfigurera procentandelen trafik som ska dirigeras till varje distribution, så länge procentandelarna är upp till 100 %. Du kan också distribuera en hanterad onlineslutpunkt med 0 % trafik som dirigeras till valfri distribution. Om du, precis som i den angivna referensimplementeringen, använder infrastruktur som kod (IaC) för att distribuera dina resurser, inklusive dina hanterade onlineslutpunkter, finns det ett tillförlitlighetsproblem. Om du har trafik konfigurerad för att dirigera till distributioner (skapas via CLI eller Azure AI Studio) och du utför en efterföljande IaC-distribution som innehåller den hanterade onlineslutpunkten, även om den inte uppdaterar den hanterade onlineslutpunkten på något sätt, återgår slutpunktstrafiken till routning med 0 % trafik. I praktiken innebär det att dina distribuerade promptflöden inte längre kan nås förrän du justerar trafiken tillbaka till den där du vill ha den.

Design för flera regioner

Den här arkitekturen är inte byggd för att vara en regional stämpel i en arkitektur med flera regioner. Det ger hög tillgänglighet inom en enda region på grund av dess fullständiga användning av tillgänglighetszoner, men saknar vissa viktiga komponenter för att göra detta verkligt redo för en lösning för flera regioner. Det här är några komponenter eller överväganden som saknas i den här arkitekturen:

• Global ingress och routning
• DNS-hanteringsstrategi
• Strategi för datareplikering (eller isolering)
• En aktiv-aktiv, aktiv-passiv eller aktiv-kall beteckning
• En redundans- och återställningsstrategi för att uppnå din arbetsbelastnings RTO och RPO
• Beslut om regiontillgänglighet för utvecklarupplevelser i Azure Studio Hub-resursen

Om arbetsbelastningens krav kräver en strategi för flera regioner måste du investera i ytterligare designarbete kring komponenter och driftsprocesser utöver det som presenteras i den här arkitekturen. Du utformar för att stödja belastningsutjämning eller redundans vid följande lager:

• Jordningsdata
• Modellhosting
• Orkestreringslager (promptflöde i den här arkitekturen)
• Klientanslutet användargränssnitt

Dessutom behöver du upprätthålla affärskontinuitet i observerbarhet, portalupplevelser och ansvarsfulla AI-frågor som innehållssäkerhet.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Checklista för designgranskning för säkerhet.

Den här arkitekturen utökar säkerhetsavtrycket som implementeras i den grundläggande chatten från slutpunkt till slutpunkt med Azure OpenAI-arkitekturen. Medan den grundläggande arkitekturen använder systemtilldelade hanterade identiteter och systemtilldelade rolltilldelningar, använder den här arkitekturen användartilldelade identiteter med manuellt skapade rolltilldelningar.

Arkitekturen implementerar en nätverkssäkerhetsperimeter, tillsammans med identitetsperimetern som implementeras i den grundläggande arkitekturen. 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.

Tillsammans med nätverksöverväganden beskriver det här avsnittet säkerhetsöverväganden för nyckelrotation och finjustering av Azure OpenAI-modellen.

Identitets- och åtkomsthantering

När du använder användartilldelade hanterade identiteter bör du överväga följande vägledning:

• Skapa separata hanterade identiteter för följande Azure AI Studio- och Machine Learning-resurser, om tillämpligt:
  • AI Studio Hub
  • AI Studio-projekt för flödesredigering och hantering
  • 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

Skapa separata projekt och onlineslutpunkter för olika promptflöden som du vill isolera från andra ur ett behörighetsperspektiv. Skapa en separat hanterad identitet för varje projekt och hanterad onlineslutpunkt. Ge frågeflödesförfattare åtkomst till endast de projekt de behöver.

När du registrerar användare i Azure AI Studio-projekt för att utföra funktioner som redigeringsflöden måste du göra rolltilldelningar med minsta möjliga behörighet de resurser de behöver.

Rollbaserade åtkomstroller för Maskininlärning

Precis som i den grundläggande arkitekturen skapar systemet automatiskt rolltilldelningar för de systemtilldelade hanterade identiteterna. Eftersom systemet inte vet vilka funktioner i hubben och projekten du kan använda skapas rolltilldelningar som stöder alla potentiella funktioner. De automatiskt skapade rolltilldelningarna kan överskrida etableringsprivilegier baserat på ditt användningsfall. Ett exempel är rollen Deltagare som tilldelats till hubben för containerregistret, där det troligen bara kräver "Läsare"-åtkomst till kontrollplanet. Om du behöver begränsa behörigheterna ytterligare för minsta möjliga behörighetsmål måste du använda användartilldelade identiteter. Du skapar och underhåller dessa rolltilldelningar själv.

På grund av underhållsbördan för att hantera alla nödvändiga tilldelningar gynnar den här arkitekturen driftskvalitet framför absoluta tilldelningar av minst privilegierade roller. Observera att du måste göra alla tilldelningar som anges i tabellen.

Hanterad identitet	Omfattning	Rolltilldelningar
Hubbhanterad identitet	Deltagare	Resursgrupp
Hubbhanterad identitet	Hubb	Azure AI-administratör
Hubbhanterad identitet	Container Registry	Deltagare
Hubbhanterad identitet	Key Vault	Deltagare
Hubbhanterad identitet	Key Vault	Administratör
Hubbhanterad identitet	Lagringskonto	Läsare
Hubbhanterad identitet	Lagringskonto	Lagringskontodeltagare
Hubbhanterad identitet	Lagringskonto	Storage blobb data-deltagare
Hubbhanterad identitet	Lagringskonto	Priviligierad medhjälpare för lagringsfildata
Hubbhanterad identitet	Lagringskonto	Datadeltagare för lagringstabell
Projekthanterad identitet	Projekt	Azure AI-administratör
Projekthanterad identitet	Container Registry	Deltagare
Projekthanterad identitet	Key Vault	Deltagare
Projekthanterad identitet	Key Vault	Administratör
Projekthanterad identitet	Lagringskonto	Läsare
Projekthanterad identitet	Lagringskonto	Lagringskontodeltagare
Projekthanterad identitet	Lagringskonto	Storage blobb data-deltagare
Projekthanterad identitet	Lagringskonto	Priviligierad medhjälpare för lagringsfildata
Projekthanterad identitet	Lagringskonto	Datadeltagare för lagringstabell
Hanterad identitet för onlineslutpunkt	Projekt	Anslutningshemligheter för Azure Machine Learning-arbetsyta
Hanterad identitet för onlineslutpunkt	Projekt	AzureML Metrics Writer
Hanterad identitet för onlineslutpunkt	Container Registry	ACRPull
Hanterad identitet för onlineslutpunkt	Azure OpenAI	Cognitive Services OpenAI-användare
Hanterad identitet för onlineslutpunkt	Lagringskonto	Storage blobb data-deltagare
Hanterad identitet för onlineslutpunkt	Lagringskonto	Läsare av lagringsblobdata
App Service (när promptflöde distribueras till App Service)	Azure OpenAI	Cognitive Services OpenAI-användare
Portalanvändare (utveckling av promptflöde)	Azure OpenAI	Cognitive Services OpenAI-användare
Portalanvändare (utveckling av promptflöde)	Lagringskonto	Storage Blob Data-deltagare (använd villkorsstyrd åtkomst)
Portalanvändare (utveckling av promptflöde)	Lagringskonto	Priviligierad medhjälpare för lagringsfildata

Det är viktigt att förstå att AI Studio-hubben har Azure-resurser som delas mellan projekt, till exempel ett lagringskonto och containerregister. Om du har användare som bara behöver åtkomst till en delmängd av projekten bör du överväga att använda rolltilldelningsvillkor för Azure-tjänster som stöder dem för att ge åtkomst till resurser med minst behörighet. Till exempel stöder blobar i Azure Storage rolltilldelningsvillkor. För en användare som kräver åtkomst till en delmängd av projekten använder du rollåtkomstvillkor i stället för att tilldela behörigheter per container för att begränsa behörigheterna till de blobcontainrar som används av dessa projekt. Varje projekt har ett unikt GUID som fungerar som ett prefix för namnen på de blobcontainrar som används i projektet. Detta GUID kan användas som en del av rolltilldelningsvillkoren.

Hubben har ett krav på Contributor åtkomst till hubbresursgruppen så att den kan skapa och hantera hubb- och projektresurser. En bieffekt av att hubben har kontrollplansåtkomst till alla resurser även i resursgruppen. Alla Azure-resurser som inte är direkt relaterade till hubben och dess projekt bör skapas i en separat resursgrupp. Vi rekommenderar att du skapar minst två resursgrupper för ett arbetsbelastningsteam med hjälp av en självhanterad Azure AI Studio Hub. En resursgrupp som ska innehålla hubben, dess projekt och alla dess direkta beroenden som Azure-containerregistret, Key Vault och så vidare. En resursgrupp som ska innehålla allt annat i din arbetsbelastning.

Vi rekommenderar att du minimerar användningen av Azure-resurser som behövs för hubbens åtgärd (Container Registry, Storage Account, Key Vault, Application Insights) av andra komponenter i dina arbetsbelastningar. Om du till exempel behöver lagra hemligheter som en del av din arbetsbelastning bör du skapa ett separat nyckelvalv förutom det nyckelvalv som är associerat med hubben. Hubbens Key Vault ska endast användas av hubben för att lagra hubb- och projekthemligheter.

Se till att rolltilldelningarna för dess beroenden för varje enskilt projekt inte ger åtkomst till resurser som portalanvändaren och hanterade onlineslutpunktshanterade identiteter inte kräver. Rolltilldelningen Cognitive Services OpenAI User till Azure OpenAI ger till exempel åtkomst till alla distributioner för resursen. Det finns inget sätt att begränsa flödesförfattare eller hanterade onlineslutpunktshanterade identiteter med den rolltilldelningsåtkomsten till specifika modelldistributioner i Azure OpenAI. I scenarier som detta är vår vägledning att distribuera tjänster som Azure OpenAI och Azure AI Search per projekt och inte distribuera resurser till de tjänster som flödesförfattare eller hanterade onlineslutpunktshanterade identiteter inte ska ha åtkomst till. Du kan till exempel bara distribuera modeller till projektets Azure OpenAI-instans som projektet kräver åtkomst till. Distribuera endast index till projektets Azure AI Search-instans som projektet ska ha åtkomst till.

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. Anslutningen till det virtuella nätverket kan också utföras via ExpressRoute eller VPN-gatewayer och peering för virtuella nätverk.

Flöde från det hanterade virtuella Azure AI Studio-nätverket till Azure PaaS-tjänster

Vi rekommenderar att du konfigurerar Azure AI Studio-hubben 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. Det hanterade virtuella nätverket distribueras på begäran när du först använder det och är beständigt från och med då.

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

• Undernät för träning och bedömning – båda dessa är till för att ta med din egen beräkning relaterad till träning och slutsatsdragning. I den här arkitekturen tränar vi inte och använder hanterad beräkning.

• 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 i Arbeta med NSG-åtkomst och Azure Bastion.	Se vägledning i Arbeta med NSG-åtkomst och Azure Bastion.
snet-jumpbox	Tillåt inkommande RDP (Remote Desktop Protocol) 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 Protection 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.

Nyckelrotation

Det finns en tjänst i den här arkitekturen som använder nyckelbaserad autentisering: den Maskininlärningshanterade onlineslutpunkten. Eftersom du använder nyckelbaserad autentisering för den här tjänsten ä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 roterades.

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.

Rolltilldelningar i Azure AI Studio för Azure Key Vault

Den hanterade Azure AI Studio-identiteten kräver rolltilldelningar för både kontrollplan (deltagare) och dataplan (Key Vault-administratör). Det innebär att den här identiteten har läs- och skrivåtkomst till alla hemligheter, nycklar och certifikat som lagras i Azure-nyckelvalvet. Om din arbetsbelastning har andra tjänster än Azure AI Studio som kräver åtkomst till hemligheter, nycklar eller certifikat i Key Vault kanske arbetsbelastningen eller säkerhetsteamet inte är bekväma med att azure AI Studio Hub-hanterade identiteten har åtkomst till dessa artefakter. I det här fallet bör du överväga att distribuera en Key Vault-instans specifikt för Azure AI Studio-hubben och andra Azure Key Vault-instanser efter behov för andra delar av din arbetsbelastning.

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 DDoS Protection och brandväggen som distribueras som en del av den hanterade onlineslutpunkten. Andra viktiga kostnader är chattgränssnittet och beräkningen av snabbflöde och AI-sökning. Optimera dessa resurser för att spara mest kostnad.

Compute

Prompt flow 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 Kubernetes 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 omfattar 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.

Inbyggda promptflödeskörningar

Precis som i den grundläggande arkitekturen använder den här arkitekturen Automatisk körning för att minimera driftbelastningen. Den automatiska körningen är ett serverlöst beräkningsalternativ i Machine Learning som förenklar beräkningshanteringen och delegerar större delen av konfigurationen av promptflöde till filen och flow.dag.yaml konfigurationen för det requirements.txt program som körs. 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

Precis som i den grundläggande arkitekturen konfigureras diagnostik för alla tjänster. Alla tjänster utom App Service är konfigurerade för att samla in alla loggar. App Service har konfigurerats för att samla in AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs och AppServicePlatformLogs. I produktion är alla loggar sannolikt överdrivna. Justera loggströmmar efter dina driftbehov. För den här arkitekturen är de Azure Machine Learning-loggar som används av Azure AI Studio-projektet av intresse: AmlComputeClusterEvent, AmlDataSetEvent, AmlEnvironmentEvent och AmlModelsEvent.

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

Se till att spåra användningen av token mot dina Azure OpenAI-modelldistributioner. I den här arkitekturen spårar Prompt-flödet tokenanvändningen genom integreringen med Azure Application Insights.

Språkmodellåtgärder

Distribution för Azure OpenAI-baserade chattlösningar som den här arkitekturen bör följa riktlinjerna i GenAIOps med promptflöde med Azure DevOps och med 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å GenAIOps-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

Prompt flow erbjuder både en webbläsarbaserad redigeringsupplevelse i Azure AI Studio eller via ett Visual Studio Code-tillägg. Båda alternativen lagrar flödeskoden som filer. När du använder Azure AI Studio lagras filerna i ett lagringskonto. När du arbetar i Microsoft Visual Studio 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 Tillägget Microsoft Visual Studio Code och SDK/CLI för promptflöde för utveckling. Frågeflödesförfattare kan skapa och testa sina flöden från Microsoft Visual Studio Code och integrera de lokalt lagrade filerna med källkontrollsystemet online 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 i flödet med hjälp av promptflöde för Microsoft Visual Studio Code, utfö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:

   1. 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
   1. 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 av 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. Även om det hanterade virtuella nätverket är grundläggande etableras det automatiskt när du skapar en beräkningsinstans som leder till vissa överväganden.

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.

Hanterat virtuellt nätverk på begäran

Det hanterade virtuella nätverket etableras automatiskt när du först skapar en beräkningsinstans. Om du använder infrastruktur som kod för att distribuera din hubb och du inte har AI Studio-beräkningsresurser i Bicep distribueras inte det hanterade virtuella nätverket och du får ett felmeddelande när du ansluter till Azure AI Studio. Du måste utföra en engångsåtgärd för att manuellt etablera det hanterade virtuella nätverket efter IaC-distributionen.

Resursorganisering

Om du har ett scenario där hubben ägs centralt av ett annat team än arbetsbelastningsteamet kan du välja att distribuera projekt till separata resursgrupper. Om du använder infrastrastructure som kod kan du göra det genom att ange en annan resursgrupp i Bicep. Om du använder portalen kan du ange defaultWorkspaceResourceGroup egenskapen under workspaceHubConfig till den resursgrupp som du vill att dina projekt ska skapas.

Prestandaeffektivitet

Prestandaeffektivitet handlar om att effektivt skala arbetsbelastningen baserat på användarnas behov. 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
• Fråga efter flöde i Azure AI Studio
• Arbetsytehanterad virtuell nätverksisolering
• Konfigurera en privat slutpunkt för en Machine Learning-arbetsyta
• Innehållsfiltrering