Företagschattprogram har möjlighet att ge anställda möjlighet att interagera med konversationer. Detta gäller särskilt på grund av den kontinuerliga utvecklingen av stora språkmodeller som OpenAI:s GPT-modeller och Metas LLaMA-modeller. Dessa chattprogram består av ett användargränssnitt för chatt, datalagringsplatser som innehåller domänspecifik information som är relevant för användarens frågor, stora språkmodeller (LLM: er) som resonerar över domänspecifika data för att skapa ett relevant svar och en orkestrerare 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 stora språkmodeller i Azure OpenAI. Arkitekturen använder AML-promptflödet (Azure Machine Learning) för att skapa körbara flöden som samordnar arbetsflödet från inkommande uppmaningar till datalager för att hämta jordningsdata för de virtuella datorerna, tillsammans med annan Python-logik som krävs. Det körbara flödet distribueras till ett Azure Machine Learning-beräkningskluster bakom en hanterad onlineslutpunkt.
Värdskapet för användargränssnittet för anpassad chatt följer riktlinjerna för webbprogram för apptjänster för baslinje för distribution av ett säkert, zonredundant och högtillgängligt webbprogram i Azure App Services. I den arkitekturen kommunicerar App Service med Azure PaaS-tjänster via integrering av virtuella nätverk via privata slutpunkter. På samma sätt kommunicerar chattgränssnittets App Service med den hanterade onlineslutpunkten för flödet över en privat slutpunkt och offentlig åtkomst till Azure Machine Learning-arbetsytan är inaktiverad.
Viktigt!
Artikeln beskriver inte komponenterna eller arkitekturbesluten från baslinjeappens webbprogram för apptjänster. Läs den artikeln om arkitekturvägledning för att vara värd för chattgränssnittet.
Machine Learning-arbetsytan är konfigurerad med hanterad isolering av virtuella nätverk som kräver att alla utgående anslutningar godkänns. Med den här konfigurationen skapas ett hanterat virtuellt nätverk, tillsammans med hanterade privata slutpunkter som möjliggör anslutning till privata resurser som Azure Storage på arbetsplatsen, Azure Container Registry och Azure OpenAI. Dessa privata anslutningar används under flödesredigering och testning och av flöden som distribueras till Azure Machine Learning-beräkning.
Dricks
Den här artikeln backas upp av en referensimplementering som visar en implementering av chatt från slutpunkt till slutpunkt i Azure. Den här implementeringen kan användas som grund för utveckling av anpassade lösningar i ditt första steg mot produktion.
Arkitektur
Bild 1: Grundläggande chattarkitektur från slutpunkt till slutpunkt med OpenAI
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 webbprogrammet för baslinjeapptjänster, eftersom chattgränssnittet i den här arkitekturen följer baslinjen för App Service-webbappens arkitektur. De komponenter som är markerade i det här avsnittet fokuserar på de komponenter som används för att skapa och orkestrera chattflöden samt datatjänster och de tjänster som exponerar de virtuella datorerna.
- Azure Machine Learning är en hanterad molntjänst som används för att träna, distribuera och hantera maskininlärningsmodeller. Den här arkitekturen använder flera andra funktioner i Azure Machine Learning som används för att utveckla och distribuera körbara flöden för AI-program som drivs av stora språkmodeller:
- Azure Machine Learning prompt flow är ett utvecklingsverktyg som gör att du kan skapa, utvärdera och distribuera flöden som länkar användarfrågor, åtgärder via Python-kod och anrop till LLM:er. Prompt-flödet används i den här arkitekturen som det lager som samordnar flöden mellan prompten, olika datalager och LLM.
- Med hanterade onlineslutpunkter kan du distribuera ett flöde för slutsatsdragning i realtid. I den här arkitekturen används de som PaaS-slutpunkt för chattgränssnittet för att anropa de promptflöden som hanteras av Azure Machine Learning.
- Azure Storage används för att spara källfilerna för promptflöde för utveckling av promptflöden.
- Med Azure Container Registry kan du skapa, lagra och hantera containeravbildningar och artefakter i ett privat register för alla typer av containerdistributioner. I den här arkitekturen paketeras flöden som containeravbildningar och lagras i Azure Container Registry.
- Azure OpenAI är en fullständigt hanterad tjänst som ger REST API-åtkomst till Azure OpenAI:s stora språkmodeller, inklusive gpt-4, GPT-3.5-Turbo och inbäddningsuppsättningar med modeller. I den här arkitekturen används den förutom modellåtkomst för att lägga till vanliga företagsfunktioner som virtuellt nätverk och privat länk, stöd för hanterad identitet och innehållsfiltrering.
- Azure AI Search är en molnsökningstjänst som stöder fulltextsökning, semantisk sökning, vektorsökning och hybridsökning. Azure AI Search ingår i arkitekturen eftersom det är en vanlig tjänst som används i flödena bakom chattprogram. Azure AI Search kan användas för att hämta och indexisera data som är relevanta för användarfrågor. Promptflödet implementerar RAG-mönstret Hämtningsförhöjd generation för att extrahera lämplig fråga från prompten, fråga AI Search och använda resultaten som grunddata för Azure OpenAI-modellen.
Azure Machine Learning-promptflöde
Serverdelen för företagschattprogram följer vanligtvis ett mönster som liknar följande flöde:
- Användaren anger en uppmaning i ett anpassat chattanvändargränssnitt (UI)
- Uppmaningen skickas till serverdelen av gränssnittskoden
- Användar avsikten (fråga eller direktiv) extraheras från uppmaningen av serverdelen
- (valfritt) Serverdelen avgör vilka datalager som innehåller data som är relevanta för användarprompten
- Serverdelen frågar relevanta datalager
- Serverdelen skickar avsikten, relevanta grunddata och all historik som anges i uppmaningen till LLM.
- Serverdelen returnerar resultatet till så att det kan visas i användargränssnittet
Serverdelen kan implementeras på valfritt antal språk och distribueras till olika Azure-tjänster. I den här arkitekturen valdes Azure Machine Learning-promptflödet eftersom det ger en smidig upplevelse att skapa, testa och distribuera flöden som samordnar mellan prompter, serverdelsdatalager och LLM:er.
Nätverk
Tillsammans med identitetsbaserad åtkomst är nätverkssäkerhet kärnan i baslinjens chattarkitektur från slutpunkt till slutpunkt med hjälp av OpenAI. Från en hög nivå säkerställer nätverksarkitekturen följande:
- En enda säker startpunkt för chattgränssnittstrafik
- Nätverkstrafik filtreras
- Data under överföring krypteras från slutpunkt till slutpunkt med TLS
- Dataexfiltrering minimeras genom att hålla trafiken i Azure med hjälp av Private Link
- Nätverksresurser grupperas logiskt och isoleras från varandra via nätverkssegmentering
Nätverksflöden
Bild 2: Nätverksflöden för baslinjens chattarkitektur från slutpunkt till slutpunkt med OpenAI
Två flöden i det här diagrammet beskrivs i webbprogrammet för baslinjeapptjänster: 1. inkommande flödet från slutanvändaren till chattgränssnittet och 2. Flödet för App Service-till Azure PaaS-tjänster. Mer information om dessa flöden finns i artikeln. Det här avsnittet fokuserar på Azure Machine Learnings onlineslutpunktsflöde. Följande information om flödet från chattgränssnittet som körs i apptjänstens baslinjewebbapp till flödet som distribueras till Azure Machine Learning-beräkning:
- Samtalet från apptjänstens värdbaserade chattgränssnitt dirigeras via en privat slutpunkt till Azure Machine Learning-slutpunkten online.
- Onlineslutpunkten dirigerar anropet till en server som kör det distribuerade flödet. Onlineslutpunkten fungerar som både en lastbalanserare och en router.
- Anrop till Azure PaaS-tjänster som krävs av det distribuerade flödet dirigeras via hanterade privata slutpunkter.
Ingress till Azure Machine Learning
I den här arkitekturen inaktiveras offentlig åtkomst till Azure Machine Learning-arbetsytan och åtkomst kan ske via privat åtkomst eftersom den följer den privata slutpunkten för konfigurationen av Azure Machine Learning-arbetsytan . I själva verket används privata slutpunkter i hela den här arkitekturen för att komplettera identitetsbaserad säkerhet. Till exempel genom att låta chattgränssnittet i App Service ansluta till PaaS-tjänster som inte exponeras för det offentliga Internet, inklusive Azure Machine Learning-slutpunkter.
Privat slutpunktsåtkomst krävs också för att ansluta till Azure Machine Learning-arbetsytan för flödesredigering.
Bild 3: Nätverksflöden för en Azure Machine Learning-flödesförfattare
Diagrammet visar en promptflödesförfattare som ansluter via Azure Bastion till en hoppruta för virtuella datorer. Från den hopprutan kan författaren ansluta till Machine Learning-arbetsytan via en privat slutpunkt i samma nätverk som hopprutan. Anslut ivity to the virtual network could also be accomplished through ExpressRoute or VPN gateways and virtual network peering.
Flöde från det hanterade virtuella Azure Machine Learning-nätverket till Azure PaaS-tjänster
Vi rekommenderar att Azure Machine Learning-arbetsytan konfigureras för hanterad virtuell nätverksisolering med en konfiguration 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. Nödvändiga regler för utgående trafik gäller för resurser som krävs för att lösningen ska fungera, till exempel Azure Container Registry och Azure Storage. Användardefinierade regler för utgående trafik gäller anpassade resurser, till exempel Azure OpenAI eller Azure AI Search, som arbetsflödet ska använda. Det är ditt ansvar att konfigurera användardefinierade regler för utgående trafik, medan nödvändiga regler för utgående trafik konfigureras när det hanterade virtuella nätverket skapas.
Utgående regler kan vara privata slutpunkter, tjänsttaggar eller FQDN för externa offentliga slutpunkter. I den här arkitekturen ansluts anslutningar till Azure-tjänster som Azure Container Registry, Azure Storage, Azure Key Vault, Azure OpenAI-tjänsten och Azure 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 konfiguration av en utgående FQDN-regel ett pip-paket, klonar en GitHub-lagringsplats och 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 för följande:
- Application Gateway
- Integreringskomponenter för App Service
- Privata slutpunkter
- Azure Bastion
- Virtuell jump box-dator
- Utbildning – används inte för modellträning i den här arkitekturen
- Resultat
Varje undernät har en nätverkssäkerhetsgrupp 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 NSG-reglerna som baslinjen lägger till i varje undernät. Tabellen ger 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 Azure App Service plus nödvändiga objekt för tjänsten. |
| snet-PrivateEndpoints | Tillåt endast trafik från det virtuella nätverket. | Tillåt endast trafik till det virtuella nätverket. |
| snet-AppService | Tillåt endast trafik från det virtuella nätverket. | Tillåt åtkomst till de privata slutpunkterna och Azure Monitor. |
| AzureBastionSubnet | Se vägledning för att arbeta med NSG-åtkomst och Azure Bastion | Se vägledning för att arbeta med NSG-åtkomst och Azure Bastion |
| snet-jumpbox | Tillåt inkommande RDP och SSH från Bastion Host-undernätet. | Tillåt åtkomst till de privata slutpunkterna |
| snet-agents | Tillåt endast trafik från det virtuella nätverket. | Tillåt endast trafik till det virtuella nätverket. |
| snet-training | Tillåt endast trafik från det virtuella nätverket. | Tillåt endast trafik till det virtuella nätverket. |
| snet-scoring | Tillåt endast trafik från det virtuella nätverket. | Tillåt endast trafik till det virtuella nätverket. |
All annan trafik nekas uttryckligen.
Tänk på följande när du implementerar segmentering och säkerhet för virtuella nätverk.
- Aktivera DDoS-skydd för det virtuella nätverket med ett undernät som ingår i en programgateway med en offentlig IP-adress.
- Lägg till en NSG i varje undernät där det är möjligt. Du bör använda de striktaste reglerna som aktiverar fullständiga lösningsfunktioner.
- Använd programsäkerhetsgrupper. Med programsäkerhetsgrupper kan du gruppera NSG:er, vilket gör det enklare att skapa regler för komplexa miljöer.
Övervakning av innehållsfiltrering och missbruk
Azure OpenAI-tjänsten innehåller ett system för innehållsfiltrering som använder en uppsättning klassificeringsmodeller för att identifiera och förhindra specifika kategorier av potentiellt skadligt innehåll i både indataprompter och slutförda utdata. Kategorier för detta potentiellt skadliga innehåll inkluderar hat, sexuell, självskada, våld, svordomar och jailbreak (innehåll som är utformat för att kringgå begränsningarna i en LLM). Du kan konfigurera striktheten för det du vill filtrera innehållet för varje kategori, med alternativ som låg, medel eller hög. Den här referensarkitekturen använder en strikt metod. Du bör justera inställningarna enligt dina krav.
Förutom innehållsfiltrering implementerar Azure OpenAI-tjänsten funktioner för övervakning av missbruk. Övervakning av missbruk är en asynkron åtgärd som är utformad för att identifiera och minimera instanser av återkommande innehåll och/eller beteenden som tyder på användning av tjänsten på ett sätt som kan bryta mot Azure OpenAI-uppförandekoden. Du kan begära undantag från övervakning av missbruk och mänsklig granskning , till exempel om dina data är mycket känsliga eller om det finns interna principer eller tillämpliga juridiska föreskrifter som förhindrar bearbetning av data för identifiering av missbruk.
Tillförlitlighet
App Service-baslinjearkitekturen för webbprogram fokuserar på zonredundans för viktiga regionala tjänster. Tillgänglighetszoner är fysiskt separata platser i en region. De tillhandahåller redundans i en region för stödtjänster när två eller flera instanser distribueras i dem. När en zon drabbas av stilleståndstid kan de andra zonerna i regionen fortfarande inte påverkas. Arkitekturen säkerställer också att tillräckligt många instanser av Azure-tjänster och konfiguration av dessa tjänster sprids över tillgänglighetszoner. Se 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 Azure Machine Learning, Azure OpenAI och Azure AI Search.
Zonredundans för flödesdistributioner
Företagsdistributioner kräver vanligtvis minst zonindelad redundans. För att uppnå detta i Azure måste resurser ha stöd för tillgänglighetszoner och du måste distribuera minst resursens instanser eller aktivera plattformsstödet när instanskontroll inte är tillgänglig. För närvarande erbjuder Inte Azure Machine Learning-beräkning stöd för tillgänglighetszoner. För att minska den potentiella effekten av en katastrof på datacenternivå på AML-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 använder hälsokontroller för att säkerställa att anrop endast dirigeras till kluster som fungerar korrekt.
Distribution av promptflöden är inte begränsat till Azure Machine Learning-beräkningskluster. Det körbara flödet, som är ett containerbaserat program, kan distribueras till alla Azure-tjänster som är kompatibla med containrar. De här alternativen omfattar tjänster som Azure Kubernetes Service (AKS), Azure Functions, Azure Container Apps (ACA) 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 är en alternativ arkitektur där promptflöden distribueras till Azure 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.
Bild 4: Alternativ chattarkitektur från slutpunkt till slutpunkt med OpenAI som distribuerar promptflöden till Azure App Services
Diagrammet är numrerat för områden som är anmärkningsvärda i den här arkitekturen:
- Flöden skapas fortfarande i Azure Machine Learning-promptflödet och Azure Machine Learning-nätverksarkitekturen är oförändrad. Flödesförfattare ansluter fortfarande till arbetsytans redigeringsupplevelse via en privat slutpunkt och de hanterade privata slutpunkterna används för att ansluta till Azure-tjänster vid testning av flöden.
- Den här streckade linjen anger att containerbaserade körbara flöden skickas till Azure Container Registry (ACR). Visas inte i diagrammet är pipelines som containeriserar flödena och push-överför till ACR.
- 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 ACR 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 gäller det Azure AI Search och Azure OpenAI-tjänsten. PaaS-tjänster som endast exponerades för det AML-hanterade privata slutpunktsundernätet 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 använder 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 Azure Storage-konto. Detta minimerar tillståndet som lagras i Azure OpenAI-tjänsten per region. Finjustering måste fortfarande göras per instans för att vara 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) för att säkerställa att du har tilldelat tillräckligt med TPM 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 (APIM) kan distribueras framför dina OpenAI-tjänster och kan konfigureras för omförsök vid tillfälliga fel och begränsning. APIM kan också användas som kretsbrytare för att förhindra att tjänsten överbelastas med anrop och överskrider kvoten.
Azure AI Search – tillförlitlighet
Distribuera Azure AI Search med prisnivån Standard eller senare 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:
- Följ vägledningen för att övervaka Azure AI Search.
- 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 för att undvika indexbaserad begränsning.
Azure Machine Learning – tillförlitlighet
Om du distribuerar till beräkningskluster bakom den Azure Machine Learning-hanterade onlineslutpunkten bör du överväga följande vägledning om skalning:
- Följ riktlinjerna för att autoskala dina onlineslutpunkter 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 tillförlitligheten påverkas av att för få instanser är 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.
Kommentar
Samma vägledning om skalbarhet för App Service från baslinjearkitekturen gäller om du distribuerar ditt flöde till Azure App Service.
Säkerhet
Den här arkitekturen implementerar både ett nätverk och en identitetssäkerhetsperimeter. Från ett nätverksperspektiv är det enda som ska vara tillgängligt från Internet chattgränssnittet via App 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.
Nätverkssäkerhet diskuterades i avsnittet nätverk. I det här avsnittet beskrivs identitets- och åtkomsthantering samt säkerhetsöverväganden för nyckelrotation och finjustering av Azure OpenAI-modellen.
Identitets- och åtkomsthantering
Följande vägledning utökar vägledningen för identitets- och åtkomsthantering i App Service-baslinjen:
- Skapa separata hanterade identiteter för följande AML-resurser, om tillämpligt:
- Arbetsyta – används under flödesredigering och hantering
- Beräkningsinstans – används vid testning av flöden
- Onlineslutpunkt – används av det distribuerade flödet om det distribueras till en hanterad onlineslutpunkt
- Implementera identitetsåtkomstkontroller för chattgränssnittet med hjälp av Microsoft Entra-ID
RBAC-roller för Azure Machine Learning
Det finns fem standardroller som du kan använda för att hantera åtkomsten till din Azure Machine Learning-arbetsyta: AzureML Dataforskare, AzureML Compute Operator, Reader, Contributor och Owner. Tillsammans med dessa standardroller finns det en AzureML-arbetsyta Anslut ion Secrets Reader och en AzureML-registeranvändare som ger åtkomst till arbetsyteresurser som arbetsytehemligheter och register.
Den här arkitekturen följer principen om minsta behörighet genom att endast tilldela roller till ovanstående identiteter där de krävs. Följande är rolltilldelningarna.
| Hanterad identitet | Omfattning | Rolltilldelningar |
|---|---|---|
| Hanterad identitet för arbetsyta | Resursgrupp | Deltagare |
| Hanterad identitet för arbetsyta | Lagringskonto för arbetsyta | Storage Blob datadeltagare |
| Hanterad identitet för arbetsyta | Lagringskonto för arbetsyta | Priviligierad medhjälpare för lagringsfildata |
| Hanterad identitet för arbetsyta | Nyckelvalv för arbetsyta | Key Vault-administratör |
| Hanterad identitet för arbetsyta | Containerregister för arbetsyta | ACRPush |
| Hanterad identitet för onlineslutpunkt | Containerregister för arbetsyta | AcrPull |
| Hanterad identitet för onlineslutpunkt | Lagringskonto för arbetsyta | Läsare av lagringsblobdata |
| Hanterad identitet för onlineslutpunkt | Machine Learning-arbetsyta | AzureML Workspace Anslut ion Secrets Reader |
| Hanterad identitet för beräkningsinstans | Containerregister för arbetsyta | ACRPull |
| Hanterad identitet för beräkningsinstans | Lagringskonto för arbetsyta | Läsare av lagringsblobdata |
Nyckelrotation
Det finns två tjänster i den här arkitekturen som använder nyckelbaserad autentisering: Azure OpenAI och den Azure Machine Learning-hanterade onlineslutpunkten. Eftersom du använder nyckelbaserad autentisering för dessa tjänster är det viktigt att:
- Lagra nyckeln i ett säkert lager som Azure 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 bör du skapa en nyckel förfalloprincip och använda Azure-principen för att övervaka om nyckeln har roterats.
Finjustering av OpenAI-modell
Om du finjusterar OpenAI-modeller i implementeringen bör du överväga följande vägledning:
- Om du laddar upp träningsdata för finjustering kan du överväga att använda kundhanterade nycklar för att kryptera dessa data.
- Om du lagrar träningsdata i ett lager, till exempel Azure Blob Storage, bör du överväga att använda en kundhanterad nyckel för datakryptering, använda en hanterad identitet för att kontrollera åtkomsten till data och en privat slutpunkt för att ansluta till data.
Prestandaeffektivitet
Prestandaeffektivitet handlar om att effektivt skala arbetsbelastningen baserat på användarnas behov. Mer information finns i Översikt över grundpelare för prestandaeffektivitet.
I det här avsnittet beskrivs prestandaeffektivitet ur azure search-, Azure OpenAI- och Azure Machine Learning-perspektiv.
Azure Search – prestandaeffektivitet
Följ vägledningen för att analysera prestanda i Azure AI Search.
Azure OpenAI – prestandaeffektivitet
- Avgör om ditt program kräver etablerat dataflöde eller använder modellen för delad värd (förbrukning). Etablerat dataflöde erbjuder 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 (förbrukning), vilket är bäst och kan utsättas för bullriga grannar eller andra stressfaktorer på plattformen.
- För etablerat dataflöde bör du övervaka etableringshanterad användning
Azure Machine Learning – prestandaeffektivitet
Om du distribuerar till Azure Machine Learning-slutpunkter online:
- Följ riktlinjerna för hur du autoskalar en onlineslutpunkt 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. Du vill 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.
Kostnadsoptimering
Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.
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 bara innehåller de komponenter som ingår i arkitekturen. De dyraste komponenterna i scenariot är chattgränssnittet och beräkningen av promptflöde och Azure AI Search, så se till att optimera kring dessa resurser för att spara mest kostnad.
Compute
Azure Machine Learning-promptflödet har stöd för flera alternativ för att vara värd för körbara flöden. Alternativen omfattar hanterade onlineslutpunkter i Azure Machine Learning, Azure Kubernetes Service, Azure App Service och Azure Container Service. Vart och ett av dessa alternativ har en egen faktureringsmodell. Valet av beräkning påverkar lösningens totala kostnad.
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-tjänsten måste du använda en kombination av metoder:
- Kontrollera klienter. Klientbegäranden är den primära kostnadskällan i en förbrukningsmodell, eftersom 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 (nyckel eller 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 bör du optimera gränsen för svarslängden.
- Azure OpenAI Playground-användning bör vara nödvändig 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. Om du använder rätt modell för användningsfallet kan du 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 tiden som är tillgänglig 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 1 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 utvärderar du växlingen till den här förköpsfaktureringsmodellen om den beräknas vara 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. Observera att kvoten inte mappas direkt till kostnader och att kostnaden kan variera.
- Övervaka användningsbaserad användning – Om du använder betala per användning övervakar du användningen av token per minut (TPM) och begäranden per minut (RPM). Använd den informationen för att informera arkitekturdesignbeslut, till exempel vilka modeller som ska användas, samt optimera promptstorlekar.
- Övervaka användning av etablerat dataflöde – Om du använder etablerat dataflöde övervakar du etableringshanterad användning för att säkerställa att du inte underutnyttjar 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.
Stora språkmodellåtgärder (LLMOps)
Distribution för Azure OpenAI-baserade chattlösningar som den här arkitekturen bör följa riktlinjerna i LLMOps med promptflöde med Azure DevOps och GitHub. Dessutom måste den överväga metodtips för CI/CD och nätverksskyddade arkitekturer. Följande vägledning tar upp implementeringen av flöden och deras associerade infrastruktur baserat på LLMOps-rekommendationerna. Den här distributionsvägledningen innehåller inte klientdelsappelementen, som inte är oförändrade från i arkitekturen För zonredundant webbprogram med hög tillgänglighet.
Utveckling
Azure Machine Learning-promptflödet erbjuder både en webbläsarbaserad redigeringsupplevelse i Azure Machine Learning-studio eller via ett VS Code-tillägg. Båda alternativen lagrar flödeskoden som filer. När du använder Azure Machine Learning-studio lagras filerna i ett Azure Storage-konto. När du arbetar i VS Code lagras filerna i ditt lokala filsystem.
För att kunna följa metodtipsen för samarbetsutveckling bör källfilerna underhållas på en lagringsplats för källkod online, till exempel GitHub. Den här metoden underlättar spårning av alla kodändringar, samarbete mellan flödesförfattare och integrering med distributionsflöden som testar och validerar alla kodändringar.
För företagsutveckling bör du använda VS Code-tillägget och SDK/CLI för promptflöde för utveckling. Frågeflödesförfattare kan skapa och testa sina flöden från VS Code och integrera de lokalt lagrade filerna med online-källkontrollsystemet och pipelines. Även om den webbläsarbaserade upplevelsen lämpar sig väl för undersökande utveckling, kan den med lite arbete integreras med källkontrollsystemet. Flödesmappen kan laddas ned från flödessidan i panelen Files , packas upp och push-överföras till källkontrollsystemet.
Utvärdering
Du bör 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 LLM-utdata, men du kan använda en LLM själv för att utvärdera svar. Överväg att implementera följande automatiserade utvärderingar av dina LLM-flöden:
- Klassificeringsnoggrannhet: Utvärderar om LLM ger en "korrekt" eller "felaktig" poäng och aggregerar utfallen för att skapa 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.
- Groundedness Against Context: Utvärderar hur väl modellens förutsagda svar baseras på förkonfigurerad kontext. Även om LLM:s svar ä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 LLM:er för att generera någon av data i din gyllene datauppsättning.
Distributionsflöde
Bild 5: Distribution av promptflöde
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ödet för VS Code, utför regelbundet ändringar och push-överför ändringarna till funktionsgrenen.
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
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.
Kopplingen till Main utlöser bygg- och lanseringsprocessen för utvecklingsmiljön. Specifikt:
a. CI-pipelinen utlöses från sammanfogningen till Main. CI-pipelinen utför alla steg som utförs i PR-pipelinen och följande steg:
- Experimenteringsflöde
- Utvärderingsflöde
- Registrerar flödena i Azure Machine Learning Registry när ändringar identifieras
b. CD-pipelinen utlöses när CI-pipelinen har slutförts. Det här flödet utför följande steg:
- Distribuerar flödet från Azure Machine Learning Registry till en Azure 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 – 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.
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.
När den har släppts i en livemiljö utförs de operativa uppgifterna för att övervaka prestandamått och utvärdera den distribuerade LLM:en. Detta inkluderar men är inte begränsat till:
- Identifiera dataavvikelser
- Observera infrastrukturen
- Hantera kostnader
- Kommunicera modellens prestanda till intressenter
Distributionsvägledning
Med Azure Machine Learning-slutpunkter kan du distribuera modeller på ett sätt som ger 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: Blå/gröna distributioner är inte bara 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 Azure Machine Learning-arbetsytan använder du en lokalt installerad agent för att distribuera artefakter till dina Azure-resurser.
- Azure Machine Learning-modellregistret bör bara uppdateras när det finns ändringar i modellen.
- LLM, flödena och klientgränssnittet bör vara löst kopplade. Uppdateringar till flöden och klientgränssnittet kan och bör kunna göras utan att påverka modellen och vice versa.
- När du utvecklar och distribuerar flera flöden bör varje flöde ha en egen livscykel, vilket ger en löst kopplad upplevelse när du främjar flöden från experimentering till produktion.
Infrastruktur
När du distribuerar grundläggande Azure OpenAI-chattkomponenter från slutpunkt till slutpunkt är vissa av de tjänster som tillhandahålls grundläggande och permanenta i arkitekturen, medan andra komponenter är mer tillfälliga, och deras existens är kopplad till en distribution.
Grundläggande komponenter
Vissa komponenter i den här arkitekturen finns med en livscykel som sträcker sig bortom varje enskilt promptflöde eller någon modelldistribution. Dessa resurser distribueras vanligtvis en gång som en del av den grundläggande distributionen av arbetsbelastningsteamet och underhålls förutom nya, borttagna eller uppdateringar av promptflödena eller modelldistributionerna.
- Azure Machine Learning-arbetsyta
- Azure Storage-konto för Azure Machine Learning-arbetsytan
- Azure Container Registry
- Azure 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, vilket gör att dessa resurser kan bindas till komponentens livscykel och bli tillfälliga i den här arkitekturen. De 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 Azure 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 Azure 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.
- Azure 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.
Övervakning
Diagnostik konfigureras för alla tjänster. Alla tjänster utom Azure Machine Learning och Azure App Service är konfigurerade för att samla in alla loggar. Azure Machine Learning-diagnostiken är konfigurerad för att avbilda granskningsloggarna som alla är resursloggar som registrerar kundinteraktioner med data eller tjänstens inställningar. Azure App Service har konfigurerats för att samla in AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs och AppServicePlatformLogs.
Distribuera det här scenariot
För att 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.