Företagschattprogram kan hjälpa anställda genom konversationsinteraktion. Den här punkten 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 chattanvä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.
- En orkestrerare som övervakar interaktionerna mellan komponenter.
Den här artikeln innehåller en baslinjearkitektur som hjälper dig att skapa och distribuera företagschattprogram som använder Azure OpenAI Service-språkmodeller. 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 och annan nödvändig Python-logik. Det körbara flödet distribueras till en hanterad onlineslutpunkt som använder hanterad beräkning.
Värdskapet för det anpassade chattgränssnittet följer baslinjeappens webbprogram för apptjänster vägledning för hur du distribuerar 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. I chattgränssnittsarkitekturen kommunicerar App Service med den hanterade onlineslutpunkten för flödet över en privat slutpunkt. Offentlig åtkomst till Azure AI Foundry-portalen är inaktiverad.
Viktigt!
Den här artikeln beskriver inte komponenterna eller arkitekturbesluten från apptjänstwebbappens baslinje. Läs den artikeln för arkitekturvägledning om hur du är värd för chattgränssnittet.
Azure AI Foundry-hubben konfigureras med hjälp av hanterad virtuell nätverksisolering som kräver godkännande för alla utgående anslutningar. I den här konfigurationen skapas ett hanterat virtuellt nätverk och hanterade privata slutpunkter upprättas för att möjliggöra anslutning till privata resurser, till exempel azure storage på arbetsplatsen, Azure Container Registry och Azure OpenAI. Dessa privata anslutningar används vid flödesredigering och testning av flöden som distribueras till Azure Machine Learning-beräkning.
En hubb är den översta Azure AI Foundry-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 fler funktioner som kräver olika promptflöden som använder olika logik och potentiellt olika serverdelsresurser, till exempel datalager, kan du överväga att implementera dessa funktioner i ett annat projekt.
Dricks
Den här referensimplementeringen visar en implementering av chatt från slutpunkt till slutpunkt i Azure. Du kan använda den här implementeringen som grund för utveckling av anpassade lösningar i ditt första steg mot produktion.
Arkitektur
Ladda ned en Visio-fil med den här arkitekturen.
Komponenter
Många av komponenterna i den här arkitekturen är samma som resurserna i den grundläggande Azure OpenAI-chattarkitekturen från slutpunkt till slutpunkt. I följande lista visas skillnaderna mellan den grundläggande arkitekturen och baslinjearkitekturen.
Azure OpenAI- används i båda arkitekturerna. Azure OpenAI är en fullständigt hanterad tjänst som ger REST API-åtkomst till Azure OpenAI-språkmodeller, inklusive GPT-4, GPT-3.5-Turbo och inbäddningsuppsättningar med modeller. Baslinjearkitekturen använder företagsfunktioner som virtuella nätverk och privata länkar som den grundläggande arkitekturen inte implementerar.
Azure AI Foundry är en plattform som du kan använda för att skapa, testa och distribuera AI-lösningar. Den här arkitekturen använder Azure AI Foundry-portalen 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 Foundry hanterade virtuella nätverk för nätverkssäkerhet. Mer information finns i avsnittet nätverk i den här artikeln.
Azure 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.
Azure Web Application Firewall är en molnbaserad tjänst som hjälper till att skydda webbappar från vanliga kryphål som SQL-inmatning och skript mellan webbplatser. Brandväggen för webbprogram ger insyn i trafiken till och från ditt webbprogram. Den här synligheten hjälper dig att ö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.
Azure Virtual Network är en tjänst som du kan använda för att skapa isolerade och säkrare 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.
Azure Private Link- ger klienter åtkomst till Azure PaaS-tjänster 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-infrastruktur. 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 innehåller flera komponenter som kan hanteras av andra Azure-tjänster som bättre kan anpassas till de funktionella och icke-funktionella kraven för din arbetsbelastning.
Machine Learning-arbetsytor och portalupplevelser
Den här arkitekturen använder Azure AI Foundry-portalen för att skapa, testa och distribuera promptflöden. Du kan också använda Machine Learning-arbetsytor. Båda tjänsterna har funktioner som överlappar varandra. Portalen är ett bra val för att utforma en snabbflödeslösning, men Machine Learning har för närvarande bättre stöd för vissa funktioner. Mer information finns i Detaljerad funktionsjämförelse. Vi rekommenderar att du inte blandar och matchar portalen och Machine Learning Studio. Om ditt arbete kan utföras helt i Azure AI Foundry-portalen använder du portalen. Om du behöver funktioner från Machine Learning Studio använder du studion i stället.
Komponenter på programnivå
Azure tillhandahåller flera hanterade programtjänster som kan fungera som programnivå för chattgränssnittets klientdel. Dessa tjänster omfattar beräkningsalternativ och containerlösningar. Den här arkitekturen använder till exempel Web Apps och Web App for Containers för chattgränssnitts-API:et respektive promptflödesvärden. Du kan uppnå liknande resultat med hjälp av Azure Kubernetes Service (AKS) eller Azure Container Apps. Välj programplattformen för din arbetsbelastning baserat på dess specifika funktionella och icke-funktionella krav.
Prompt flow hosting
Distribution av promptflöden är inte begränsat till Machine Learning-beräkningskluster. Den här arkitekturen illustrerar den här punkten med hjälp av en alternativ lösning i 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 AKS, Container Apps och App Service. Välj en Azure-containertjänst baserat på kraven i orkestreringsskiktet.
Ett exempel på varför du kan överväga att distribuera prompt flow hosting på en alternativ beräkning beskrivs senare i den här artikeln.
Datalager för jordning
Den här arkitekturen leder med AI Search, men ditt val av datalager för dina grunddata är ett arkitektoniskt beslut som är specifikt för din arbetsbelastning. Många arbetsbelastningar använder flera språk och har olika källor och tekniker för jordning av data. Dessa dataplattformar omfattar befintliga datalager för onlinetransaktionsbearbetning, molnbaserade databaser som Azure Cosmos DB och specialiserade lösningar som AI Search. Vektorsökning är en vanlig egenskap för den här typen av datalager, men det krävs inte. Mer information finns i Välj en Azure-tjänst för vektorsökning.
Överväganden
Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som du kan använda för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Well-Architected Framework.
Använd den här arkitekturen och designvägledningen i AI-arbetsbelastningar i Azure under designprocessen för din specifika arbetsbelastning.
Tillförlitlighet
Tillförlitlighet hjälper till att säkerställa att ditt program kan uppfylla de åtaganden som 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 mellan dem. När stilleståndstiden inträffar i en zon kan de andra zonerna i regionen inte påverkas. Arkitekturen hjälper också till att säkerställa att tillräckligt många instanser och konfigurationer av Azure-tjänster är spridda över tillgänglighetszoner. Mer information finns i Med hög tillgänglighet zonredundant webbapp.
Det här avsnittet tar upp tillförlitlighet utifrån de komponenter i den här arkitekturen som inte behandlas i App Service-baslinjearkitekturen, 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 resurserna 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 stöder inte tillgänglighetszoner. För att minimera de potentiella effekterna av en katastrof på datacenternivå på Machine Learning-komponenter måste du upprätta kluster i olika regioner och 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.
Alternativ till Machine Learning-beräkningskluster är AKS, Azure Functions, 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 med flera regioner kan du distribuera dina flöden till någon av dessa tjänster.
Följande diagram visar en alternativ arkitektur där promptflöden distribueras till App Service. Den här arkitekturen använder App Service eftersom arbetsbelastningen redan använder den för chattgränssnittet och inte drar nytta av att införa en ny teknik i arbetsbelastningen. Arbetsbelastningsteam som har erfarenhet av AKS bör överväga att distribuera i den miljön, särskilt om de använder AKS för andra komponenter i arbetsbelastningen.
Följande dataflöde motsvarar föregående diagram:
Flöden skapas i promptflödet och nätverksarkitekturen är oförändrad. Flödesförfattare ansluter till redigeringsupplevelsen i Azure AI Foundry-projektet via en privat slutpunkt, och de hanterade privata slutpunkterna används för att ansluta till Azure-tjänster när du testar flöden.
Den här streckade linjen anger att containerbaserade körbara flöden skickas till Container Registry. Diagrammet visar inte de 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 Azure AI Foundry-projektet.
En annan webbapp distribueras till samma App Service-plan som ä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. Den här tjänstplanen körs redan på minst tre instanser som är 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.
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 exponeras för det hanterade privata slutpunktsundernätet för Machine Learning behöver nu också exponering i det virtuella nätverket för att upprätta en siktlinje från App Service.
Tillförlitlighet i Azure OpenAI
Azure OpenAI stöder inte tillgänglighetszoner. För att minimera de potentiella effekterna av en katastrof på datacenternivå på modelldistributioner i Azure OpenAI måste du distribuera Azure OpenAI till olika regioner och 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 geografiskt redundant lagringskonto. Den här metoden minimerar det tillstånd som lagras i Azure OpenAI för varje region. Du måste 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). Tilldela tillräckligt med TPM från din kvot för att möta efterfrågan på dina distributioner och förhindra att anrop till dina distribuerade modeller begränsas. Du kan distribuera en gateway som Azure API Management framför din Azure OpenAI-tjänst eller dina tjänster och konfigurera den för återförsök om tillfälliga fel och begränsningar inträffar. Du kan också använda API Management som en kretsbrytare för att förhindra att tjänsten överbelastas med anrop och överskrider kvoten. Mer information finns i Använda en gateway framför flera Azure OpenAI-distributioner eller instanser.
Tillförlitlighet i AI Search
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.
Använd följande vägledning för att fastställa lämpligt antal repliker och partitioner:
Använd övervakningsmått, loggar och prestandaanalys för att fastställa lämpligt antal repliker. Den här metoden hjälper dig att undvika frågebaserad begränsning och partitioner och indexbaserad begränsning.
Tillförlitlighet i Azure AI Foundry
Om du distribuerar till beräkningskluster bakom den Maskininlärningshanterade onlineslutpunkten bör du överväga följande skalningsvägledning:
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. Den här metoden hjälper till att förbättra tillförlitligheten genom att se till att tillräckligt många instanser är tillgängliga.
Skapa skalningsregler baserat på distributionsmått som CPU-belastning och slutpunktsmått som svarstid för begäranden.
Distribuera inte mindre än tre instanser för en aktiv produktionsdistribution.
Undvik distributioner mot instanser som används. Distribuera till en ny distribution i stället och flytta över trafiken när den andra 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 procentandelen uppgår till 100%. Du kan också distribuera en hanterad onlineslutpunkt med 0% trafik som dirigeras till valfri distribution.
Om du använder infrastruktur som kod (IaC) för att distribuera dina resurser, inklusive dina hanterade onlineslutpunkter, finns det ett tillförlitlighetsproblem. Denna oro lyfts fram i den tillhandahållna referensimplementeringen. Om du har trafik konfigurerad för att dirigera till distributioner som har skapats via CLI eller Azure AI Foundry-portalen 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 0% trafik. I själva verket innebär det här scenariot att dina distribuerade promptflöden inte kan nås förrän du justerar trafiken tillbaka till den där du vill ha den.
Kommentar
Samma vägledning om skalbarhet för App Service från baslinjearkitekturen gäller om du distribuerar ditt flöde till App Service.
Design för flera regioner
Den här arkitekturen fungerar inte som en regional stämpel i en arkitektur med flera regioner. Den ger hög tillgänglighet inom en enda region eftersom den använder tillgänglighetszoner helt, men den saknar några viktiga komponenter för att göra den här designen redo för en lösning med flera regioner. Den här arkitekturen innehåller inte följande komponenter och överväganden:
- Global ingress och routning
- En DNS-hanteringsstrategi
- En strategi för datareplikering eller isolering
- En aktiv-aktiv, aktiv-passiv eller aktiv-kall beteckning
- En redundans- och återställningsstrategi för att uppnå arbetsbelastningens mål för återställningstid och återställningspunkt
- Överväganden om regiontillgänglighet för utvecklarupplevelser i Azure AI Foundry Hub-resursen
Om din arbetsbelastning kräver en strategi för flera regioner måste du investera i komponent- och driftprocessdesign utöver den design som presenteras i den här arkitekturen. Din design måste ha stöd för belastningsutjämning eller redundans vid följande lager:
- Jordningsdata
- Modellhosting
- Orkestreringslager, vilket är promptflödet i den här arkitekturen
- Klientanslutet användargränssnitt
Du måste också upprätthålla affärskontinuitet i observerbarhet, portalupplevelser och ansvarsfull AI, till exempel 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 Referensarkitektur för grundläggande OpenAI-chatt från slutpunkt till slutpunkt. Den grundläggande arkitekturen använder systemtilldelade hanterade identiteter och systemtilldelade rolltilldelningar. Den här arkitekturen använder användartilldelade identiteter och manuellt skapade rolltilldelningar.
Den här arkitekturen implementerar en nätverkssäkerhetsperimeter utöver den identitetsperimeter som den grundläggande arkitekturen implementerar. Från ett nätverksperspektiv ska endast chattgränssnittet vara tillgängligt från Internet via Application Gateway. Från ett identitetsperspektiv bör chattgränssnittet autentisera och auktorisera begäranden. Använd hanterade identiteter när det är möjligt för att autentisera program till Azure-tjänster.
I det här avsnittet beskrivs nätverks- och 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 Foundry- och Machine Learning-resurser, i tillämpliga fall:
- Azure AI Foundry Hub
- Azure AI Foundry-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
Om du vill isolera behörigheter för promptflöden skapar du separata projekt och onlineslutpunkter för olika promptflöden. Skapa en separat hanterad identitet för varje projekt och hanterad onlineslutpunkt. Ge frågeflödesförfattare åtkomst till endast de projekt som de behöver.
När du registrerar användare i Azure AI Foundry-projekt för att utföra funktioner som redigeringsflöden tilldelar du roller med minst behörighet för de resurser som 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 överetablera privilegier baserat på ditt användningsfall. Ett exempel är när systemet tilldelar rollen Deltagare till hubben för containerregistret, men hubben kräver sannolikt bara läsaråtkomst till kontrollplanet. Om du behöver begränsa behörigheter för lägsta 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. 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 Azure AI Foundry-hubben delar Azure-resurser, till exempel lagringskonton och Container Registry, mellan olika projekt. 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 Lagring rolltilldelningsvillkor. Om en användare behöver åtkomst till en delmängd av projekten använder du villkor för rollåtkomst för att begränsa behörigheter till de blobcontainrar som dessa projekt använder i stället för att tilldela behörigheter per container. 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 kräver Contributor åtkomst till hubbresursgruppen så att den kan skapa och hantera hubb- och projektresurser.
Contributor åtkomst ger även hubbkontrollplanet åtkomst till alla resurser som finns i resursgruppen. Skapa alla Azure-resurser som inte är direkt relaterade till hubben och dess projekt i en separat resursgrupp. Vi rekommenderar att du skapar minst två resursgrupper för ett arbetsbelastningsteam som använder en självhanterad Azure AI Foundry-hubb. En resursgrupp innehåller hubben, dess projekt och alla dess direkta beroenden, till exempel Azure-containerregistret och Key Vault. Den andra resursgruppen innehåller allt annat i din arbetsbelastning.
Vi rekommenderar att du minimerar användningen av Azure-resurser som behövs för hubbens drift av andra komponenter i dina arbetsbelastningar. Om du till exempel behöver lagra hemligheter som en del av din arbetsbelastning bör du skapa en separat Key Vault-instans från den som är associerad med hubben. Endast hubben ska använda hubbens nyckelvalv 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 den hanterade onlineslutpunktshanterade identiteten 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 som har rolltilldelningen till specifika modelldistributioner i Azure OpenAI. I dessa scenarier rekommenderar vi att du distribuerar tjänster som Azure OpenAI och AI Search för varje projekt och inte distribuerar 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 Den Azure OpenAI-instans som projektet kräver åtkomst till. Distribuera endast index till AI Search-instansen som projektet ska ha åtkomst till.
Nätverk
Utöver 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:
- Det finns bara en enda säker startpunkt för chattgränssnittstrafik.
- Nätverkstrafik filtreras.
- Data under överföring krypteras från slutpunkt till slutpunkt med 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
Inkommande flöde från slutanvändaren till chattgränssnittet och flödet från App Service till Azure PaaS-tjänster beskrivs i baslinje för App Service-webbprogramarkitekturen. Det här avsnittet fokuserar på Machine Learnings onlineslutpunktsflöde. Det går från chattgränssnittet som körs i apptjänstens baslinjewebbprogram till flödet som distribueras till Machine Learning-beräkning:
- Samtalet från det App Service-värdbaserade chattgränssnittet dirigeras via en privat slutpunkt till Machine Learning-slutpunkten online.
- Onlineslutpunkten dirigerar anropet till en server som kör det distribuerade flödet. Onlineslutpunkten fungerar både som lastbalanserare och router.
- Anrop till Azure PaaS-tjänster som krävs för 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 . Privata slutpunkter används 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 snabbflödesförfattare som ansluter via Azure Bastion till en virtuell dator (VM). Från den hopprutan kan författaren ansluta till Machine Learning-arbetsytan via en privat slutpunkt i samma nätverk som hopprutan. Författaren kan också ansluta till det virtuella nätverket via Azure ExpressRoute eller VPN-gatewayer och peering för virtuella nätverk.
Flöde från det hanterade virtuella Azure AI Foundry-nätverket till Azure PaaS-tjänster
Vi rekommenderar att du konfigurerar Azure AI Foundry Hub för hanterad virtuell nätverksisolering, vilket kräver godkännande av alla utgående anslutningar. Den här arkitekturen följer den rekommendationen. Det finns två typer av godkända regler för utgående trafik. Obligatoriska regler för utgående trafik är för resurser som lösningen kräver, till exempel Container Registry och Storage. användardefinierade regler för utgående trafik är för anpassade resurser som arbetsflödet använder, till exempel Azure OpenAI eller AI Search. Du måste konfigurera användardefinierade regler för utgående trafik. De regler för utgående trafik som krävs 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 FQDN för externa offentliga slutpunkter. I den här arkitekturen upprättas anslutningen till Azure-tjänster via Private Link. Den här arkitekturen innehåller inte några vanliga åtgärder som kan kräva att du konfigurerar en regel för utgående FQDN, laddar ned ett pip-paket, klonar en GitHub-lagringsplats eller laddar ned bascontaineravbildningar från externa lagringsplatser.
En Azure Firewall-instans som hanteras av Microsoft implementerar den utgående FQDN-kontrollen och distribueras till ett Azure AI Foundry-hanterat nätverk. Välj prisnivån Basic om du bara behöver styra utgående HTTP-trafik (port 80) eller HTTPS (port 443). Om din utgående trafik kräver anpassade protokoll eller portar väljer du prisnivån Standard. Den här arkitekturen använder prisnivån Basic eftersom den enda utgående trafiken är till HTTPS-slutpunkter på port 443.
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
- Virtuella jump box-datorer
- Resultat
- Undernät för träning och bedömning
Kommentar
Undernät för träning och bedömning är utformade så att du kan använda dina egna beräkningsresurser för träning och slutsatsdragning. Den här arkitekturen använder dock hanterad beräkning och tränar inte.
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 endast vad de behöver. 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 trafik | Utgående trafik |
|---|---|---|
| snet-appGateway | Traktamenten för ip-adresser för chattanvändargränssnittets användarkälla, till exempel offentligt Internet, och nödvändiga objekt för tjänsten. | Åtkomst till den privata App Service-slutpunkten och 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 Arbeta med NSG-åtkomst och Azure Bastion. | Se Arbeta med NSG-åtkomst och Azure Bastion. |
| snet-jumpbox | Tillåt inkommande Protokoll för fjärrskrivbord och Secure Shell Protocol 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 Azure DDoS Protection- för det virtuella nätverket med ett undernät som ingår i en programgateway som har en offentlig IP-adress.
Lägg till en NSG- i varje undernät nä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 förenklar skapande av regler för komplexa miljöer.
Nyckelrotation
I den här arkitekturen använder den Maskininlärningshanterade onlineslutpunkten nyckelbaserad autentisering, så det är 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-webbappen 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 använder du kundhanterade nycklar för att kryptera dessa data.
Om du lagrar träningsdata i ett lager, till exempel Azure Blob Storage, använder du 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ätverksprinciper så att distributionerna överensstämmer med kraven för arbetsbelastningen för att säkerställa att säkerheten överensstämmer med säkerheten. Användningen av plattformsautomatisering via princip minskar belastningen för manuella valideringssteg och hjälper till att säkerställa 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 för Azure AI Foundry för Key Vault
Den hanterade Azure AI Foundry-identiteten kräver rolltilldelningar för både kontrollplanet (Contributor) och dataplanet (Key Vault Administrator). Dessa tilldelningar ger den här identiteten läs- och skrivåtkomst till alla hemligheter, nycklar och certifikat som lagras i Azure Key Vault. Om din arbetsbelastning använder andra tjänster än Azure AI Foundry som kräver åtkomst till hemligheter, nycklar eller certifikat i Key Vault kanske arbetsbelastningen eller säkerhetsteamet föredrar att den hanterade Identiteten för Azure AI Foundry Hub inte har åtkomst till dessa artefakter. I det här scenariot bör du överväga att distribuera en Key Vault-instans specifikt för Azure AI Foundry Hub och andra Key Vault-instanser efter behov för andra delar av din arbetsbelastning.
Kostnadsoptimering
Kostnadsoptimering fokuserar 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 används i den här arkitekturen. De dyraste komponenterna i scenariot är DDoS Protection och brandväggen som distribueras som en del av den hanterade onlineslutpunkten. Andra anmärkningsvärda kostnader är chattgränssnittet, beräkning av promptflöde och AI-sökning. Optimera resurserna för att minska kostnaderna.
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 och App Service. Vart och ett av dessa alternativ har en egen faktureringsmodell. Den beräkning som du väljer påverkar den totala kostnaden för lösningen.
Azure OpenAI
Azure OpenAI är en förbrukningsbaserad tjänst, så att matcha efterfrågan med tillgång är det primära sättet att kontrollera kostnaderna. För att göra det 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ätt som stöder kostnadsfri åtkomst. Begränsa åtkomsten via nätverks- och identitetskontroller, till exempel nycklar eller rollbaserad åtkomstkontroll.
Var självkontrollerad. Kräv att klienter använder de tokenbegränsningsbegränsningar som API-anrop tillhandahåller, till exempel max_tokens och max_completions.
Använd batchbearbetning när det är praktiskt. Granska klienterna för att se till att de har rätt batch-prompter.
Optimera promptens indata och svarslängd. Längre frågor förbrukar fler token, vilket ökar kostnaden. 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. Se till att du optimerar gränsen för svarslängden.
Använd endast Azure OpenAI Playground efter behov. Du bör bara använda lekplatsen på förproduktionsinstanser så att dessa aktiviteter inte medför produktionskostnader.
Välj rätt AI-modell. Den modell som du väljer påverkar 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 förhindra överförbrukning på en dyrare modell när en billigare modell ger godkända resultat. Den här chattreferensimplementeringen använder GPT 3.5-turbo i stället för GPT-4 för att spara kostnader för modelldistribution samtidigt som tillräckliga resultat uppnås.
Förstå brytpunkter för fakturering. Finjustering debiteras per timme. För maximal effektivitet använder du så mycket av den timmen för att förbättra finjusteringsresultatet innan du når nästa faktureringstimme. 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 faktureringsmodellen före köp om den är mer kostnadseffektiv på din användningsvolym.
Ange etableringsgränser. Allokera endast all etableringskvot 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 dessa kostnader 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 arkitekturens designbeslut, till exempel 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.
Hantera kostnader. Följ vägledningen om med hjälp av kostnadshanteringsfunktioner med OpenAI- för att övervaka kostnader, ange budgetar och skapa aviseringar för att meddela intressenter om risker eller avvikelser.
Operational Excellence
Operational Excellence 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 requirements.txt konfigurationen för det flow.dag.yaml program som körs. Det här valet är lågt underhåll, tillfälligt och programdrivet. Den här arkitekturen använder körning av beräkningsinstanser eller externaliserad beräkning, vilket kräver att arbetsbelastningsteamet hanterar beräkningens livscykel. Du bör använda en körning av beräkningsinstanser när dina arbetsbelastningskrav ö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, AppServiceAppLogsoch AppServicePlatformLogs. I produktion är alla loggar sannolikt överdrivna. Justera loggströmmar efter dina driftbehov. För den här arkitekturen använder Azure AI Foundry-projektet loggarna AmlComputeClusterEvent, AmlDataSetEvent, AmlEnvironmentEventoch AmlModelsEvent Machine Learning.
Utvärdera att skapa anpassade aviseringar, till exempel de som finns i Azure Monitor-baslinjeaviseringar, för resurserna i den här arkitekturen. Till exempel:
Se till att övervaka användningen av token mot dina Azure OpenAI-modelldistributioner. I den här arkitekturen spårar promptflöde tokenanvändning genom integreringen med 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 och Azure DevOps och GenAIOps med promptflöde 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å GenAIOps-rekommendationerna. Den här distributionsvägledningen omfattar inte klientdelsprogramelementen, som inte är oförändrade från baslinje med hög tillgänglighet zonredundant webbprogramarkitektur.
Utveckling
Prompt flow tillhandahåller både en webbläsarbaserad redigeringsupplevelse i Azure AI Foundry-portalen eller via ett Visual Studio Code-tillägg. Båda dessa alternativ lagrar flödeskoden som filer. När du använder portalen lagras filerna i ett lagringskonto. När du arbetar i VS Code lagras filerna i ditt lokala filsystem.
Om du vill följa bästa praxis för samarbetsutvecklingbehåller du källfilerna på en lagringsplats för källkod online som GitHub. Den här metoden hjälper till att spåra kodändringar, samarbeta mellan flödesförfattare och integrera med distributionsflöden som testar och validerar alla kodändringar.
För företagsutveckling använder du VS Code-tillägget och prompt flow SDK/CLI- 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. Den webbläsarbaserade upplevelsen är utformad för undersökande utveckling, men du kan arbeta med att integrera den med källkontrollsystemet. Du kan ladda ned flödesmappen från flödessidan i panelen Files, packa upp mappen och push-överföra den till källkontrollsystemet.
Utvärdering
Testa de flöden som chattprogrammet använder med samma metoder som du använder för att testa andra programvaruartefakter. Det är svårt att ange och kontrollera ett enda korrekt 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 utfallen för att ge ett noggrannhetsbetyg.
Koherens utvärderar hur väl meningarna i en modells förutsagda svar skrivs och hur de samverkar med varandra.
Fluency utvärderar modellens förutsagda svar på dess grammatiska och språkliga noggrannhet.
Groundedness mot 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, är svaren inte jordade.
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 om testerna godkänns eller misslyckas 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ågor och svar för att säkerställa att testresultaten är tillförlitliga. Vi rekommenderar att du inkluderar minst 100–150 par. Dessa frågor och svar kallas även för din gyllene datauppsättning. Ett större antal par 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
Följande dataflöde motsvarar föregående diagram:
Frågeteknikern eller dataexperten öppnar en funktionsgren där de arbetar med en specifik uppgift eller funktion. Frågeteknikern eller dataexperten itererar flödet med hjälp av promptflöde för VS Code och genomför regelbundet ändringar och push-överför ändringarna till funktionsgrenen.
När den lokala utvecklingen och experimenteringen har slutförts öppnar frågeteknikern eller dataexperten en pull-begäran (PR) från funktionsgrenen till huvudgrenen. 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.
- Statisk kodanalys.
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 den som bestämmer, och de måste ha snabb flödesexpertis och kunskap om projektets krav. 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 huvudgrenen.
Sammanfogningen till huvudgrenen utlöser bygg- och lanseringsprocessen för utvecklingsmiljön.
a. CI-pipelinen utlöses från sammanfogningen till huvudgrenen. CI-pipelinen utför alla steg i PR-pipelinen och följande steg:
- Experimenteringsflöde
- Utvärderingsflöde
- Flödesregistrering i Machine Learning-registret när ändringar identifieras
b. CI-pipelinen slutförs och utlöser sedan CD-pipelinen. 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
En godkännandeprocess är inbyggd i lanseringsprocessen. Efter godkännandet upprepas CI/CD-processerna för testmiljön. Steg a. och b. är desamma, förutom att användargodkännandetester körs efter röktesterna i testmiljön.
CI/CD-processerna körs för att höja upp versionen till produktionsmiljön när testmiljön har verifierats och godkänts.
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. Dessa uppgifter omfattar:
- Identifiering av dataavvikelser.
- Infrastrukturobservation.
- Kostnadshantering.
- Kommunikation av 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 ger flexibilitet när du släpper dem till produktion. Överväg följande strategier för att säkerställa hög modellprestanda och kvalitet:
Använd blågröna distributioner för att på ett säkert sätt distribuera den nya versionen av webbtjänsten till en begränsad grupp användare eller begäranden innan du dirigerar all trafik till den nya distributionen.
Använd A/B-testning för att distribuera nytt beteende. Med A/B-testning kan en delmängd användare utvärdera effekterna 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.
Använd en lokalt installerad agent för att distribuera artefakter till dina Azure-resurser när du distribuerar flödet till den nätverksisolerade Machine Learning-arbetsytan.
Uppdatera endast Machine Learning-modellregistret när det finns ändringar i modellen.
Kontrollera att språkmodellerna, flödena och klientgränssnittet är löst kopplade. Du bör kunna uppdatera flödena och klientgränssnittet 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. Den här metoden hjälper till att hålla flödena löst kopplade när du befordrar dem från experimentering till produktion.
Infrastruktur
När du distribuerar grundläggande Azure OpenAI-chattkomponenter från slutpunkt till slutpunkt är vissa av de etablerade tjänsterna grundläggande och permanenta i arkitekturen. Livscykeln för andra komponenter är knutna till en distribution. Det hanterade virtuella nätverket är grundläggande och etableras automatiskt när du skapar en beräkningsinstans, så du måste överväga följande komponenter.
Grundläggande komponenter
Vissa komponenter i den här arkitekturen finns med en livscykel som sträcker sig bortom alla enskilda promptflöden eller modelldistributioner. Dessa resurser distribueras vanligtvis en gång som en del av den grundläggande distributionen av arbetsbelastningsteamet. Arbetsbelastningsteamet underhåller sedan dessa resurser separat från att skapa, ta bort eller uppdatera promptflödena eller modelldistributionerna. Dessa komponenter omfattar:
- Machine Learning-arbetsytan.
- Lagringskontot för Machine Learning-arbetsytan.
- Container Registry.
- AI-sökning.
- Azure OpenAI.
- Application Insights.
- Azure Bastion.
- Den virtuella Azure-datorn för hopprutan.
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 av dem tas bort. Vissa av dessa resurser är 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 IaC för att distribuera din hubb och du inte har Azure AI Foundry-beräkningsresurser i Bicep distribueras inte det hanterade virtuella nätverket och du får ett fel när du ansluter till Azure AI Foundry-portalen. Du måste etablera det hanterade virtuella nätverket manuellt 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 IaC kan du distribuera projekt för att separera resursgrupper genom att ange en annan resursgrupp i Bicep. Om du använder portalen kan du ange egenskapen defaultWorkspaceResourceGroup under workspaceHubConfig till resursgruppen där du vill skapa dina projekt.
Prestandaeffektivitet
Prestandaeffektivitet syftar på arbetsbelastningens förmåga att skala för att effektivt uppfylla användarnas krav. Mer information finns i Checklista för designgranskning för prestandaeffektivitet.
I det här avsnittet beskrivs prestandaeffektivitet ur AI Search-, Azure OpenAI- och Machine Learning-perspektiv.
Prestandaeffektivitet i AI-sökning
Följ vägledningen för att analysera prestanda i AI Search.
Prestandaeffektivitet i Azure OpenAI
Avgör om ditt program kräver etablerat dataflöde eller den delade värdmodellen eller förbrukningsmodellen. Etablerat dataflöde hjälper till att säkerställa reserverad bearbetningskapacitet för dina OpenAI-modelldistributioner. Reserverad kapacitet 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 bli utsatt för störningar i grannen eller andra problem på plattformen.
Övervaka etableringshanterad användning för etablerat dataflöde.
Prestandaeffektivitet i Maskininlärning
Om du distribuerar till Machine Learning-slutpunkter online:
Följ vägledningen om hur du autoskalar en onlineslutpunkt. Autoskalning hjälper dig att nära anpassa dig till efterfrågan utan överetablering, särskilt under perioder med låg användning.
Välj lämplig VM SKU för onlineslutpunkten för att uppfylla dina prestandamål. För att hitta en optimal konfiguration testar du prestanda för både lägre instansantal och större SKU:er jämfört med större instansantal och mindre SKU:er.
Distribuera det här scenariot
Om du vill distribuera och köra den här referensimplementeringen följer du stegen i referensimplementeringen OpenAI från slutpunkt till slutpunkt.
Deltagare
Microsoft ansvarar för denna artikel. Följande deltagare skrev den här artikeln.
- Raouf Aliouat | Programvarutekniker II – Microsoft
- Freddy Ayala | Molnlösningsarkitekt – Microsoft
- Rob Bagby | Mönster och metoder – Microsoft
- Prabal Deb | Senior Software Engineer – Microsoft
- Ritesh Modi | Huvudprogramtekniker – Microsoft
- Ryan Pfalz | Senior Solution Architect – Microsoft
Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.
Gå vidare
Azure OpenAI-baslinje i en Azure-landningszon