End-to-end architectuur voor openAI-chatbasislijn

Bedrijfschattoepassingen hebben de mogelijkheid om werknemers via gespreksinteractie in staat te stellen. Dit geldt vooral vanwege de continue vooruitgang van grote taalmodellen, zoals GPT-modellen van OpenAI en LLaMA-modellen van Meta. Deze chattoepassingen bestaan uit een gebruikersinterface voor chatten, gegevensopslagplaatsen met domeinspecifieke informatie die relevant is voor de query's van de gebruiker, grote taalmodellen (LLM's) die reden geven voor de domeinspecifieke gegevens om een relevant antwoord te produceren en een orchestrator die toezicht houdt op de interactie tussen deze onderdelen.

Dit artikel bevat een basisarchitectuur voor het bouwen en implementeren van bedrijfschattoepassingen die gebruikmaken van grote taalmodellen van Azure OpenAI. De architectuur maakt gebruik van een AML-promptstroom (Azure Machine Learning) om uitvoerbare stromen te maken waarmee de werkstroom wordt ingedeeld vanuit binnenkomende prompts naar gegevensarchieven om grondgegevens voor de LLM's op te halen, samen met eventuele andere Python-logica die nodig is. De uitvoerbare stroom wordt geïmplementeerd in een Azure Machine Learning-rekencluster achter een beheerd online-eindpunt.

De hosting van de aangepaste gebruikersinterface voor chats (UI) volgt de richtlijnen voor de webtoepassing basislijn voor app-services voor het implementeren van een beveiligde, zone-redundante en maximaal beschikbare webtoepassing op Azure-app Services. In die architectuur communiceert de App Service met Azure PaaS-services via integratie van virtuele netwerken via privé-eindpunten. Op dezelfde manier communiceert de chat-UI App Service met het beheerde online-eindpunt voor de stroom via een privé-eindpunt en wordt openbare toegang tot de Azure Machine Learning-werkruimte uitgeschakeld.

De Machine Learning-werkruimte is geconfigureerd met isolatie van beheerde virtuele netwerken waarvoor alle uitgaande verbindingen moeten worden goedgekeurd. Met deze configuratie wordt een beheerd virtueel netwerk gemaakt, samen met beheerde privé-eindpunten die connectiviteit met privébronnen mogelijk maken, zoals de werkplek Azure Storage, Azure Container Registry en Azure OpenAI. Deze privéverbindingen worden gebruikt tijdens het ontwerpen en testen van stromen en door stromen die zijn geïmplementeerd in Azure Machine Learning Compute.

Architectuur

Afbeelding 1: End-to-end-chatarchitectuur basislijn met OpenAI

Een Visio-bestand van deze architectuur downloaden.

Onderdelen

Veel van de onderdelen van deze architectuur zijn hetzelfde als de resources in de webtoepassing basislijn-app-services, omdat de chatgebruikersinterface die in deze architectuur wordt gehost, de architectuur van de App Service-webtoepassing volgens de basislijn volgt. De onderdelen die in deze sectie zijn gemarkeerd, richten zich op de onderdelen die worden gebruikt voor het bouwen en organiseren van chatstromen, en gegevensservices en de services die de LLM's beschikbaar maken.

• Azure Machine Learning is een beheerde cloudservice die wordt gebruikt voor het trainen, implementeren en beheren van machine learning-modellen. Deze architectuur maakt gebruik van verschillende andere functies van Azure Machine Learning die worden gebruikt voor het ontwikkelen en implementeren van uitvoerbare stromen voor AI-toepassingen die worden mogelijk gemaakt door grote taalmodellen:
  • Azure Machine Learning-promptstroom is een ontwikkelhulpprogramma waarmee u stromen kunt bouwen, evalueren en implementeren waarmee gebruikersprompts, acties via Python-code en aanroepen naar LLM's worden gekoppeld. Promptstroom wordt in deze architectuur gebruikt als de laag die stromen organiseert tussen de prompt, verschillende gegevensarchieven en de LLM.
  • Met beheerde online-eindpunten kunt u een stroom implementeren voor realtime deductie. In deze architectuur worden ze gebruikt als PaaS-eindpunt voor de chatgebruikersinterface om de promptstromen aan te roepen die worden gehost door Azure Machine Learning.
• Azure Storage wordt gebruikt om de bronbestanden van de promptstroom te behouden voor het ontwikkelen van promptstromen.
• Met Azure Container Registry kunt u containerinstallatiekopieën en artefacten bouwen, opslaan en beheren in een privéregister voor alle typen containerimplementaties. In deze architectuur worden stromen verpakt als containerinstallatiekopieën en opgeslagen in Azure Container Registry.
• Azure OpenAI is een volledig beheerde service die REST API-toegang biedt tot de grote taalmodellen van Azure OpenAI, waaronder de GPT-4, GPT-3.5-Turbo en Embeddings set modellen. In deze architectuur wordt naast modeltoegang ook algemene bedrijfsfuncties toegevoegd, zoals virtueel netwerk en private link, ondersteuning voor beheerde identiteiten en het filteren van inhoud.
• Azure AI Search is een cloudzoekservice die ondersteuning biedt voor zoeken in volledige tekst, semantische zoekopdrachten, vectorzoekopdrachten en hybride zoekopdrachten. Azure AI Search is opgenomen in de architectuur omdat het een algemene service is die wordt gebruikt in de stromen achter chattoepassingen. Azure AI Search kan worden gebruikt om gegevens op te halen en te indexeren die relevant zijn voor gebruikersquery's. De promptstroom implementeert het RAG-patroon Augmented Generation ophalen om de juiste query uit de prompt te extraheren, AI Search op te vragen en de resultaten te gebruiken als grondgegevens voor het Azure OpenAI-model.

Azure Machine Learning-promptstroom

De back-end voor bedrijfschattoepassingen volgt doorgaans een patroon dat vergelijkbaar is met de volgende stroom:

• De gebruiker voert een prompt in in een aangepaste gebruikersinterface voor chats (UI)
• Deze prompt wordt door de interfacecode naar de back-end verzonden
• De intentie van de gebruiker (vraag of instructie) wordt geëxtraheerd uit de prompt door de back-end
• (optioneel) De back-end bepaalt de gegevensarchieven die gegevens bevatten die relevant zijn voor de gebruikersprompt
• De back-end voert een query uit op de relevante gegevensopslag(en)
• De back-end verzendt de intentie, de relevante grondgegevens en eventuele geschiedenis in de prompt naar de LLM.
• De back-end retourneert het resultaat zodat het kan worden weergegeven op de gebruikersinterface

De back-end kan worden geïmplementeerd in een willekeurig aantal talen en geïmplementeerd in verschillende Azure-services. In deze architectuur is de Azure Machine Learning-promptstroom gekozen omdat deze een gestroomlijnde ervaring biedt voor het bouwen, testen en implementeren van stromen die worden ingedeeld tussen prompts, back-endgegevensarchieven en LLM's.

Netwerken

Samen met op identiteit gebaseerde toegang vormt netwerkbeveiliging de kern van de end-to-end-chatarchitectuur van de basislijn met behulp van OpenAI. Op hoog niveau zorgt de netwerkarchitectuur voor het volgende:

• Eén beveiligd toegangspunt voor chatgebruikersinterfaceverkeer
• Netwerkverkeer wordt gefilterd
• Gegevens die onderweg zijn, worden end-to-end versleuteld met TLS
• Gegevensexfiltratie wordt geminimaliseerd door verkeer in Azure te houden met behulp van Private Link
• Netwerkbronnen worden logisch gegroepeerd en geïsoleerd van elkaar via netwerksegmentatie

Netwerkstromen

Afbeelding 2: Netwerkstromen voor de end-to-end-chatarchitectuur van de basislijn met OpenAI

Twee stromen in dit diagram worden behandeld in de webtoepassing basislijn-app-services: 1. de binnenkomende stroom van de eindgebruiker naar de chatgebruikersinterface en 2. de App Service-stroom naar Azure PaaS-services. Zie dit artikel voor meer informatie over deze stromen. Deze sectie is gericht op de online-eindpuntstroom van Azure Machine Learning. Hieronder vindt u informatie over de stroom van de chatgebruikersinterface die wordt uitgevoerd in de App Service-webtoepassing basislijn naar de stroom die is geïmplementeerd in Azure Machine Learning Compute:

1. De oproep vanuit de gehoste chatgebruikersinterface van App Service wordt gerouteerd via een privé-eindpunt naar het online-eindpunt van Azure Machine Learning.
2. Het online-eindpunt stuurt de aanroep naar een server waarop de geïmplementeerde stroom wordt uitgevoerd. Het online-eindpunt fungeert als zowel een load balancer als een router.
3. Aanroepen naar Azure PaaS-services die zijn vereist voor de geïmplementeerde stroom, worden gerouteerd via beheerde privé-eindpunten.

Inkomend verkeer naar Azure Machine Learning

In deze architectuur is openbare toegang tot de Azure Machine Learning-werkruimte uitgeschakeld en kan de toegang worden uitgevoerd via privétoegang, omdat deze het privé-eindpunt volgt voor de configuratie van de Azure Machine Learning-werkruimte . In feite worden privé-eindpunten in deze architectuur gebruikt om de beveiliging op basis van identiteiten aan te vullen. Als u bijvoorbeeld uw chatgebruikersinterface die wordt gehost in App Service toestaat om verbinding te maken met PaaS-services die niet beschikbaar zijn voor het openbare internet, met inbegrip van Azure Machine Learning-eindpunten.

Privé-eindpunttoegang is ook vereist voor het maken van verbinding met de Azure Machine Learning-werkruimte voor het ontwerpen van stromen.

Afbeelding 3: Netwerkstromen voor de auteur van een Azure Machine Learning-promptstroom

In het diagram ziet u een promptstroomauteur die via Azure Bastion verbinding maakt met een jumpbox van een virtuele machine. Vanuit die jumpbox kan de auteur verbinding maken met de Machine Learning-werkruimte via een privé-eindpunt in hetzelfde netwerk als de jumpbox. Verbinding maken iviteit van het virtuele netwerk kan ook worden gerealiseerd via ExpressRoute- of VPN-gateways en peering van virtuele netwerken.

Stroom van het door Azure Machine Learning beheerde virtuele netwerk naar Azure PaaS-services

Het wordt aanbevolen om de Azure Machine Learning-werkruimte te configureren voor isolatie van beheerde virtuele netwerken met een configuratie waarvoor alle uitgaande verbindingen moeten worden goedgekeurd. Deze architectuur volgt die aanbeveling. Er zijn twee typen goedgekeurde uitgaande regels. Vereiste uitgaande regels zijn voor resources die nodig zijn om de oplossing te laten werken, zoals Azure Container Registry en Azure Storage. Door de gebruiker gedefinieerde uitgaande regels zijn voor aangepaste resources, zoals Azure OpenAI of Azure AI Search, die uw werkstroom gaat gebruiken. Het is uw verantwoordelijkheid om door de gebruiker gedefinieerde uitgaande regels te configureren, terwijl de vereiste uitgaande regels worden geconfigureerd wanneer het beheerde virtuele netwerk wordt gemaakt.

De uitgaande regels kunnen privé-eindpunten, servicetags of FQDN's zijn voor externe openbare eindpunten. In deze architectuur zijn connectiviteit met Azure-services zoals Azure Container Registry, Azure Storage, Azure Key Vault, Azure OpenAI-service en Azure AI Search verbonden via private link. Hoewel deze architectuur zich niet in deze architectuur bevindt, worden sommige veelvoorkomende bewerkingen waarvoor het configureren van een uitgaande FQDN-regel vereist, een pip-pakket gedownload, een GitHub-opslagplaats klonen, basiscontainerinstallatiekopieën downloaden uit externe opslagplaatsen.

Segmentatie en beveiliging van virtuele netwerken

Het netwerk in deze architectuur heeft afzonderlijke subnetten voor het volgende:

• Application Gateway
• App Service-integratieonderdelen
• Privé-eindpunten
• Azure Bastion
• Jump box virtual machine
• Training: niet gebruikt voor modeltraining in deze architectuur
• Scoren

Elk subnet heeft een netwerkbeveiligingsgroep die zowel inkomend als uitgaand verkeer voor deze subnetten beperkt tot alleen wat vereist is. In de volgende tabel ziet u een vereenvoudigde weergave van de NSG-regels die de basislijn toevoegt aan elk subnet. De tabel geeft de regelnaam en -functie.

Al het andere verkeer wordt expliciet geweigerd.

Houd rekening met de volgende punten bij het implementeren van segmentatie en beveiliging van virtuele netwerken.

• Schakel DDoS-beveiliging in voor het virtuele netwerk met een subnet dat deel uitmaakt van een toepassingsgateway met een openbaar IP-adres.
• Voeg waar mogelijk een NSG toe aan elk subnet. U moet de strengste regels gebruiken die volledige oplossingsfunctionaliteit mogelijk maken.
• Gebruik toepassingsbeveiligingsgroepen. Met toepassingsbeveiligingsgroepen kunt u NSG's groeperen, waardoor het maken van regels eenvoudiger is voor complexe omgevingen.

Inhoud filteren en misbruik bewaken

De Azure OpenAI-service bevat een inhoudsfiltersysteem dat gebruikmaakt van een ensemble classificatiemodellen om specifieke categorieën van mogelijk schadelijke inhoud te detecteren en te voorkomen in zowel invoerprompts als uitvoervoltooien. Categorieën voor deze mogelijk schadelijke inhoud zijn haat, seksueel, zelfbeschadiging, geweld, grof taalgebruik en jailbreak (inhoud die is ontworpen om de beperkingen van een LLM te omzeilen). U kunt de strengheid van wat u wilt filteren voor elke categorie configureren, met opties die laag, gemiddeld of hoog zijn. Deze referentiearchitectuur hanteert een strikte benadering. U moet de instellingen aanpassen aan uw vereisten.

Naast het filteren van inhoud implementeert de Azure OpenAI-service misbruikcontrolefuncties. Misbruikbewaking is een asynchrone bewerking die is ontworpen om exemplaren van terugkerende inhoud en/of gedragingen te detecteren en te beperken die het gebruik van de service voorstellen op een manier die de Azure OpenAI-gedragscode kan schenden. U kunt een uitzondering aanvragen voor misbruikbewaking en menselijke beoordeling , bijvoorbeeld als uw gegevens zeer gevoelig zijn of als er interne beleidsregels of toepasselijke wettelijke voorschriften zijn die de verwerking van gegevens voor misbruikdetectie voorkomen.

Betrouwbaarheid

De architectuur van de App Service-webtoepassing basislijn is gericht op zonegebonden redundantie voor belangrijke regionale services. Beschikbaarheidszones zijn fysiek gescheiden locaties binnen een regio. Ze bieden redundantie binnen een regio voor ondersteunende services wanneer er twee of meer exemplaren in de regio's worden geïmplementeerd. Wanneer de ene zone downtime ondervindt, kunnen de andere zones in de regio nog steeds niet worden beïnvloed. De architectuur zorgt er ook voor dat voldoende exemplaren van Azure-services en -configuratie van deze services worden verdeeld over beschikbaarheidszones. Raadpleeg de basislijn om deze richtlijnen te bekijken.

In deze sectie wordt de betrouwbaarheid behandeld vanuit het perspectief van de onderdelen in deze architectuur die niet worden behandeld in de App Service-basislijn, waaronder Azure Machine Learning, Azure OpenAI en Azure AI Search.

Zonegebonden redundantie voor stroomimplementaties

Voor bedrijfsimplementaties is doorgaans ten minste zonegebonden redundantie vereist. Om dit in Azure te bereiken, moeten resources beschikbaarheidszones ondersteunen en moet u ten minste de exemplaren van de resource implementeren of de platformondersteuning inschakelen wanneer exemplaarbeheer niet beschikbaar is. Momenteel biedt Azure Machine Learning Compute geen ondersteuning voor beschikbaarheidszones. Om de mogelijke impact van een ramp op datacenterniveau op AML-onderdelen te beperken, moet u clusters in verschillende regio's opzetten, samen met het implementeren van een load balancer om aanroepen tussen deze clusters te verdelen. U gebruikt statuscontroles om ervoor te zorgen dat aanroepen alleen worden gerouteerd naar clusters die goed werken.

Het implementeren van promptstromen is niet beperkt tot Azure Machine Learning-rekenclusters. De uitvoerbare stroom, een containertoepassing, kan worden geïmplementeerd in elke Azure-service die compatibel is met containers. Deze opties omvatten services zoals Azure Kubernetes Service (AKS), Azure Functions, Azure Container Apps (ACA) en Azure-app Service. Elk van deze services biedt ondersteuning voor beschikbaarheidszones. Als u zonegebonden redundantie wilt bereiken voor het uitvoeren van promptstromen, zonder de extra complexiteit van een implementatie met meerdere regio's, moet u uw stromen implementeren in een van deze services.

Hier volgt een alternatieve architectuur waarin promptstromen worden geïmplementeerd in Azure-app Service. App Service wordt in deze architectuur gebruikt omdat de workload deze al gebruikt voor de chatgebruikersinterface en geen voordeel zou hebben van het introduceren van een nieuwe technologie in de workload. Workloadteams die ervaring hebben met AKS, moeten overwegen om in die omgeving te implementeren, met name als AKS wordt gebruikt voor andere onderdelen in de workload.

Afbeelding 4: Alternatieve end-to-end-chatarchitectuur met OpenAI-implementatiepromptstromen voor Azure-app Services

Het diagram is genummerd voor gebieden die opmerkelijk zijn in deze architectuur:

1. Stromen worden nog steeds geschreven in de Azure Machine Learning-promptstroom en de Azure Machine Learning-netwerkarchitectuur is ongewijzigd. Stroomauteurs maken nog steeds verbinding met de ontwerpervaring van de werkruimte via een privé-eindpunt en de beheerde privé-eindpunten worden gebruikt om verbinding te maken met Azure-services bij het testen van stromen.
2. Deze stippellijn geeft aan dat in containers geplaatste uitvoerbare stromen worden gepusht naar Azure Container Registry (ACR). Niet weergegeven in het diagram zijn de pijplijnen die de stromen containeriseren en naar ACR pushen.
3. Er is nog een web-app geïmplementeerd in hetzelfde App Service-plan dat al als host fungeert voor de chatgebruikersinterface. De nieuwe web-app fungeert als host voor de stroom met containerprompts, die zich op hetzelfde App Service-plan bevindt dat al ten minste drie exemplaren wordt uitgevoerd, verspreid over beschikbaarheidszones. Deze App Service-exemplaren maken via een privé-eindpunt verbinding met ACR bij het laden van de containerinstallatiekopieën van de promptstroom.
4. De promptstroomcontainer moet verbinding maken met alle afhankelijke services voor stroomuitvoering. In deze architectuur is dat voor de Azure AI Search- en Azure OpenAI-service. PaaS-services die alleen beschikbaar zijn gemaakt voor het subnet van het beheerde privé-eindpunt van AML, moeten nu ook worden weergegeven in het virtuele netwerk, zodat er vanuit App Service een lijn van zicht tot stand kan worden gebracht.

Azure OpenAI - betrouwbaarheid

Azure OpenAI biedt momenteel geen ondersteuning voor beschikbaarheidszones. Om de mogelijke impact van een ramp op datacenterniveau op modelimplementaties in Azure OpenAI te beperken, moet u Azure OpenAI implementeren in verschillende regio's, samen met het implementeren van een load balancer om aanroepen tussen de regio's te distribueren. U gebruikt statuscontroles om ervoor te zorgen dat aanroepen alleen worden gerouteerd naar clusters die goed werken.

Als u meerdere exemplaren effectief wilt ondersteunen, raden we u aan om fine-tuningbestanden, zoals een geografisch redundant Azure Storage-account, te externaliseren. Dit minimaliseert de status die is opgeslagen in de Azure OpenAI-service per regio. Het afstemmen moet nog steeds per exemplaar worden uitgevoerd om de modelimplementatie te hosten.

Het is belangrijk om de vereiste doorvoer te bewaken in termen van tokens per minuut (TPM) en aanvragen per minuut (RPM) om ervoor te zorgen dat u voldoende TPM hebt toegewezen aan uw quotum om te voldoen aan de vraag naar uw implementaties en te voorkomen dat aanroepen naar uw geïmplementeerde modellen worden beperkt. Een gateway zoals Azure API Management (APIM) kan worden geïmplementeerd vóór uw OpenAI-service(s) en kan worden geconfigureerd voor opnieuw proberen in het geval van tijdelijke fouten en beperking. APIM kan ook worden gebruikt als circuitonderbreker om te voorkomen dat de service wordt overweldigd door aanroepen, waardoor het quotum wordt overschreden.

Azure AI Search - betrouwbaarheid

Implementeer Azure AI Search met de prijscategorie Standard of hoger in een regio die beschikbaarheidszones ondersteunt en drie of meer replica's implementeert. De replica's worden automatisch gelijkmatig verdeeld over beschikbaarheidszones.

Houd rekening met de volgende richtlijnen voor het bepalen van het juiste aantal replica's en partities:

• Volg de richtlijnen voor het bewaken van Azure AI Search.
• Gebruik bewakingsgegevens en logboeken en prestatieanalyse om het juiste aantal replica's te bepalen om op query's gebaseerde beperking en partities te voorkomen om indexgebaseerde beperking te voorkomen.

Azure Machine Learning - betrouwbaarheid

Als u implementeert op rekenclusters achter het beheerde online-eindpunt van Azure Machine Learning, moet u rekening houden met de volgende richtlijnen met betrekking tot schalen:

• Volg de richtlijnen voor het automatisch schalen van uw online-eindpunten om ervoor te zorgen dat er voldoende capaciteit beschikbaar is om aan de vraag te voldoen. Als gebruikssignalen niet tijdig genoeg zijn vanwege burstgebruik, kunt u overwegen om te voorkomen dat de betrouwbaarheidsimpact te weinig exemplaren beschikbaar zijn.
• Overweeg schaalregels te maken op basis van metrische gegevens over de implementatie, zoals cpu-belasting en metrische gegevens over eindpunten , zoals latentie van aanvragen.
• Er moeten niet minder dan drie exemplaren worden geïmplementeerd voor een actieve productie-implementatie.
• Vermijd implementaties tegen in gebruiksexemplaren. Implementeer in plaats daarvan naar een nieuwe implementatie en verschuif het verkeer nadat de implementatie gereed is voor het ontvangen van verkeer.

Beveiliging

Deze architectuur implementeert zowel een netwerk als een perimeter voor identiteitsbeveiliging. Vanuit het oogpunt van een netwerk is de chatgebruikersinterface via de App Gateway het enige dat toegankelijk moet zijn via internet. Vanuit identiteitsperspectief moet de chatgebruikersinterface aanvragen verifiëren en autoriseren. Beheerde identiteiten worden waar mogelijk gebruikt om toepassingen te verifiëren bij Azure-services.

Netwerkbeveiliging is besproken in de sectie Netwerken. In deze sectie worden identiteits- en toegangsbeheer en beveiligingsoverwegingen besproken voor sleutelrotatie en het afstemmen van het Azure OpenAI-model.

Identiteits- en toegangsbeheer

De volgende richtlijnen breiden de richtlijnen voor identiteits- en toegangsbeheer uit in de App Service-basislijn:

• Maak, indien van toepassing, afzonderlijke beheerde identiteiten voor de volgende AML-resources:
  • Werkruimte: gebruikt tijdens het ontwerpen en beheren van stromen
  • Rekenproces- gebruikt bij het testen van stromen
  • Online-eindpunt: gebruikt door de geïmplementeerde stroom als deze wordt geïmplementeerd op een beheerd online-eindpunt
• Besturingselementen voor identiteitstoegang voor de chatgebruikersinterface implementeren met behulp van Microsoft Entra ID

Azure Machine Learning RBAC-rollen

Er zijn vijf standaardrollen die u kunt gebruiken om de toegang tot uw Azure Machine Learning-werkruimte te beheren: AzureML Datawetenschapper, AzureML Compute Operator, Lezer, Inzender en Eigenaar. Naast deze standaardrollen is er een AzureML-werkruimte Verbinding maken ion Secrets Reader en een AzureML Registry-gebruiker die toegang verleent tot werkruimtebronnen, zoals de werkruimtegeheimen en het register.

Deze architectuur volgt het principe van minimale bevoegdheden door alleen rollen toe te wijzen aan de bovenstaande identiteiten waar ze vereist zijn. Hier volgen de roltoewijzingen.

Sleutelroulatie

Er zijn twee services in deze architectuur die gebruikmaken van verificatie op basis van sleutels: Azure OpenAI en het beheerde online-eindpunt van Azure Machine Learning. Omdat u gebruikmaakt van verificatie op basis van sleutels voor deze services, is het belangrijk om:

• Sla de sleutel op in een beveiligd archief, zoals Azure Key Vault voor toegang op aanvraag vanaf geautoriseerde clients (zoals de Azure-web-app die als host fungeert voor de promptstroomcontainer).
• Implementeer een strategie voor sleutelrotatie. Als u de sleutels handmatig roteert, moet u een verloopbeleid voor sleutels maken en Azure Policy gebruiken om te controleren of de sleutel is gedraaid.

OpenAI-model verfijnen

Als u OpenAI-modellen in uw implementatie wilt afstemmen, kunt u de volgende richtlijnen overwegen:

• Als u trainingsgegevens uploadt voor het afstemmen, kunt u overwegen om door de klant beheerde sleutels te gebruiken voor het versleutelen van die gegevens.
• Als u trainingsgegevens opslaat in een archief zoals Azure Blob Storage, kunt u overwegen om een door de klant beheerde sleutel voor gegevensversleuteling te gebruiken, een beheerde identiteit te gebruiken om de toegang tot de gegevens te beheren en een privé-eindpunt om verbinding te maken met de gegevens.

Prestatie-efficiëntie

Prestatie-efficiëntie is de mogelijkheid om op efficiënte wijze uw werkbelasting te schalen om te voldoen aan de vereisten die gebruikers eraan stellen. Zie Overzicht van de pijler prestatie-efficiëntie voor meer informatie.

In deze sectie wordt de prestatie-efficiëntie besproken vanuit het perspectief van Azure Search, Azure OpenAI en Azure Machine Learning.

Azure Search- prestatie-efficiëntie

Volg de richtlijnen voor het analyseren van prestaties in Azure AI Search.

Azure OpenAI - prestatie-efficiëntie

• Bepaal of voor uw toepassing een ingerichte doorvoer is vereist of dat het model voor gedeelde hosting (verbruik) wordt gebruikt. Ingerichte doorvoer biedt gereserveerde verwerkingscapaciteit voor uw OpenAI-modelimplementaties, met voorspelbare prestaties en doorvoer voor uw modellen. Dit factureringsmodel is in tegenstelling tot het model voor gedeelde hosting (verbruik), wat best effort is en mogelijk onderhevig is aan lawaaierige buren of andere stressors op het platform.
• Voor ingerichte doorvoer moet u het door de inrichting beheerde gebruik bewaken

Azure Machine Learning- prestatie-efficiëntie

Als u implementeert op online-eindpunten van Azure Machine Learning:

• Volg de richtlijnen voor het automatisch schalen van een online-eindpunt om nauw afgestemd te blijven op de vraag, zonder overmatige overprovisioning, met name in perioden met weinig gebruik.
• Kies de juiste virtuele-machine-SKU voor het online-eindpunt om te voldoen aan uw prestatiedoelen. U wilt de prestaties van zowel het lagere aantal exemplaren als grotere SKU's versus het grotere aantal exemplaren en kleinere SKU's testen om een optimale configuratie te vinden.

Kostenoptimalisatie

Kostenoptimalisatie gaat over manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie Overzicht van de pijler kostenoptimalisatie voor meer informatie.

Als u een prijsvoorbeeld voor dit scenario wilt zien, gebruikt u de Azure-prijscalculator. U moet het voorbeeld aanpassen aan uw gebruik, omdat dit voorbeeld alleen de onderdelen bevat die zijn opgenomen in de architectuur. De duurste onderdelen in het scenario zijn de rekenkracht van de chatinterface en promptstroom en Azure AI Search, dus zoek naar optimalisatie rond deze resources om de meeste kosten te besparen.

Compute

Azure Machine Learning-promptstroom ondersteunt meerdere opties voor het hosten van de uitvoerbare stromen. De opties omvatten beheerde online-eindpunten in Azure Machine Learning, Azure Kubernetes Service, Azure-app Service en Azure Container Service. Elk van deze opties heeft een eigen factureringsmodel. De keuze van rekenkracht is van invloed op de totale kosten van de oplossing.

Azure OpenAI

Azure OpenAI is een service op basis van verbruik en net als bij elke service op basis van verbruik is het beheren van de vraag op basis van aanbod de primaire kostenregeling. Hiervoor moet u specifiek een combinatie van benaderingen gebruiken in de Azure OpenAI-service:

• Clients beheren. Clientaanvragen zijn de primaire bron van kosten in een verbruiksmodel, omdat het beheren van het clientgedrag essentieel is. Alle clients moeten:
  • Goedgekeurd worden. Vermijd het blootstellen van de service op een dergelijke manier die ondersteuning biedt voor gratis toegang. Beperk de toegang via netwerk- en identiteitsbeheer (sleutel of RBAC).
  • Wees zelfgestuurd. Vereisen dat clients de beperkingen voor tokenbeperking gebruiken die worden aangeboden door de API-aanroepen, zoals max_tokens en max_completions.
  • Gebruik batchverwerking, waar praktisch. Controleer de clients om ervoor te zorgen dat ze op de juiste wijze batchprompts hebben.
  • Optimaliseer de invoer- en antwoordlengte van de prompt. Langere prompts verbruiken meer tokens, waardoor de kosten hoger worden, maar prompts die onvoldoende context missen, helpen de modellen niet om goede resultaten te behalen. Maak beknopte prompts die voldoende context bieden om het model in staat te stellen een nuttig antwoord te genereren. Zorg er ook voor dat u de limiet van de antwoordlengte optimaliseert.
• Het gebruik van Azure OpenAI-speeltuinen moet zo nodig zijn en op preproductie-exemplaren, zodat deze activiteiten geen productiekosten in rekening worden gebracht.
• Selecteer het juiste AI-model. Modelselectie speelt ook een grote rol in de totale kosten van Azure OpenAI. Alle modellen hebben sterke en zwakke punten en zijn individueel geprijsd. Als u het juiste model voor de use-case gebruikt, kunt u ervoor zorgen dat u niet overspend bent op een duurder model wanneer een goedkoper model acceptabele resultaten oplevert. In deze chatverwijzingsimplementatie is GPT 3.5-turbo gekozen boven GPT-4 om te besparen op een orde van grootte van de implementatiekosten van het model, terwijl er voldoende resultaten worden behaald.
• Meer informatie over factureringsonderbrekingspunten : afstemmen wordt per uur in rekening gebracht. Als u het meest efficiënt wilt zijn, wilt u zoveel mogelijk tijd per uur gebruiken om de resultaten van de afstemming te verbeteren terwijl u de volgende factureringsperiode vermijdt. Op dezelfde manier zijn de kosten voor 100 installatiekopieën van het genereren van installatiekopieën gelijk aan de kosten voor 1 installatiekopieën. Maximaliseer de prijsonderbrekingspunten naar uw voordeel.
• Meer informatie over factureringsmodellen : Azure OpenAI is ook beschikbaar in een factureringsmodel op basis van toezeggingen via het ingerichte doorvoeraanbod . Zodra u voorspelbare gebruikspatronen hebt, evalueert u hoe u overschakelt naar dit vooraf gekochte factureringsmodel als het wordt berekend om rendabeler te zijn op uw gebruiksvolume.
• Inrichtingslimieten instellen: zorg ervoor dat alle inrichtingsquota alleen worden toegewezen aan modellen die naar verwachting deel uitmaken van de workload, per model. Doorvoer naar al geïmplementeerde modellen is niet beperkt tot dit ingerichte quotum terwijl dynamisch quotum is ingeschakeld. Het quotum kan niet rechtstreeks worden toegewezen aan kosten en kosten kunnen variëren.
• Het gebruik van betalen per gebruik bewaken: als u betalen per gebruik gebruikt, controleert u het gebruik van tokens per minuut (TPM) en aanvragen per minuut (RPM). Gebruik deze informatie om beslissingen over architectuurontwerpen te informeren, zoals welke modellen moeten worden gebruikt, en om promptgrootten te optimaliseren.
• Het gebruik van ingerichte doorvoer bewaken: als u ingerichte doorvoer gebruikt, controleert u het door de inrichting beheerde gebruik om ervoor te zorgen dat u de ingerichte doorvoer die u hebt aangeschaft niet onderbenut.
• Kostenbeheer : volg de richtlijnen voor het gebruik van functies voor kostenbeheer met OpenAI om kosten te bewaken, budgetten in te stellen om kosten te beheren en waarschuwingen te maken om belanghebbenden op de hoogte te stellen van risico's of afwijkingen.

Bewerkingen van grote taalmodellen (LLMOps)

Implementatie voor chatoplossingen op basis van Azure OpenAI, zoals deze architectuur, moet de richtlijnen in LLMOps volgen met een promptstroom met Azure DevOps en GitHub. Daarnaast moet er rekening worden gehouden met aanbevolen procedures voor CI/CD- en netwerkbeveiligingsarchitecturen. De volgende richtlijnen hebben betrekking op de implementatie van stromen en de bijbehorende infrastructuur op basis van de LLMOps-aanbevelingen. Deze implementatierichtlijnen bevatten niet de front-endtoepassingselementen, die ongewijzigd zijn in de architectuur van de maximaal beschikbare zone-redundante webtoepassing basislijn.

Ontwikkeling

Azure Machine Learning-promptstroom biedt zowel een browsergebaseerde ontwerpervaring in Azure Machine Learning-studio als via een VS Code-extensie. Beide opties slaan de stroomcode op als bestanden. Wanneer u Azure Machine Learning-studio gebruikt, worden de bestanden opgeslagen in een Azure Storage-account. Wanneer u in VS Code werkt, worden de bestanden opgeslagen in uw lokale bestandssysteem.

Als u de aanbevolen procedures voor samenwerking wilt volgen, moeten de bronbestanden worden onderhouden in een onlineopslagplaats voor broncode, zoals GitHub. Deze aanpak vereenvoudigt het bijhouden van alle codewijzigingen, samenwerking tussen stroomauteurs en integratie met implementatiestromen die alle codewijzigingen testen en valideren.

Voor enterprise-ontwikkeling moet u de VS Code-extensie en de promptstroom-SDK/CLI gebruiken voor ontwikkeling. Auteurs van promptstromen kunnen hun stromen bouwen en testen vanuit VS Code en de lokaal opgeslagen bestanden integreren met het onlinebronbeheersysteem en pijplijnen. Hoewel de browsergebaseerde ervaring geschikt is voor verkennende ontwikkeling, kan deze met wat werk worden geïntegreerd met het broncodebeheersysteem. De stroommap kan worden gedownload van de stroompagina in het Files deelvenster, uitgepakt en naar het broncodebeheersysteem gepusht.

Beoordeling

U moet de stromen testen die in een chattoepassing worden gebruikt, net zoals u andere softwareartefacten test. Het is lastig om één 'juiste' antwoord voor LLM-uitvoer op te geven en te bevestigen, maar u kunt een LLM zelf gebruiken om reacties te evalueren. Overweeg de volgende geautomatiseerde evaluaties van uw LLM-stromen te implementeren:

• Classificatienauwkeurigheid: evalueert of de LLM een 'juiste' of 'onjuiste' score geeft en voegt de resultaten samen om een nauwkeurigheidsclassificatie te produceren.
• Samenhang: evalueert hoe goed de zinnen in het voorspelde antwoord van een model zijn geschreven en hoe ze coherent met elkaar verbinden.
• Fluency: Evalueert het voorspelde antwoord van het model voor de grammaticale en taalkundige nauwkeurigheid.
• Geaardheid tegen context: evalueert hoe goed de voorspelde antwoorden van het model zijn gebaseerd op vooraf geconfigureerde context. Zelfs als de antwoorden van LLM juist zijn, als ze niet kunnen worden gevalideerd op basis van de opgegeven context, worden dergelijke antwoorden niet geaard.
• Relevantie: evalueert hoe goed de voorspelde antwoorden van het model overeenkomen met de gestelde vraag.

Houd rekening met de volgende richtlijnen bij het implementeren van geautomatiseerde evaluaties:

• Produceer scores van evaluaties en meet deze op basis van een vooraf gedefinieerde drempelwaarde voor geslaagde resultaten. Gebruik deze scores om testpass/fail in uw pijplijnen te rapporteren.
• Sommige van deze tests vereisen vooraf geconfigureerde gegevensinvoer van vragen, context en grondwaar.
• Neem voldoende vraag-antwoordparen op om ervoor te zorgen dat de resultaten van de tests betrouwbaar zijn, waarbij ten minste 100-150 paren worden aanbevolen. Deze vraag-antwoordparen worden uw 'gouden gegevensset' genoemd. Mogelijk is een grotere populatie vereist, afhankelijk van de grootte en het domein van uw gegevensset.
• Vermijd het gebruik van LLM's om een van de gegevens in uw gouden gegevensset te genereren.

Implementatiestroom

Afbeelding 5: Implementatie van promptstroom

1. De prompt engineer/data scientist opent een functiebranch waar ze aan de specifieke taak of functie werken. De prompt engineer/data scientist doorloopt de stroom met behulp van promptstroom voor VS Code, voert regelmatig wijzigingen door en pusht deze wijzigingen naar de functievertakking.

2. Zodra lokale ontwikkeling en experimenten zijn voltooid, opent de prompt engineer/data scientist een pull-aanvraag van de functiebranch naar de hoofdbranch. Met de pull-aanvraag (PR) wordt een PULL-pijplijn geactiveerd. Met deze pijplijn worden snelle kwaliteitscontroles uitgevoerd die het volgende moeten bevatten:

   • Uitvoering van experimentenstromen
   • Uitvoering van geconfigureerde eenheidstests
   • Compilatie van de codebasis
   • Analyse van statische code

3. De pijplijn kan een stap bevatten waarvoor ten minste één teamlid de pull-aanvraag handmatig moet goedkeuren voordat de pull-aanvraag wordt samengevoegd. De fiatteur kan niet de committer zijn en ze hebben prompt flow-expertise en bekendheid met de projectvereisten. Als de pull-aanvraag niet is goedgekeurd, wordt de samenvoeging geblokkeerd. Als de pull-aanvraag is goedgekeurd of er geen goedkeuringsstap is, wordt de functiebranch samengevoegd met de hoofdbranch.

4. De samenvoeging naar Main activeert het build- en releaseproces voor de ontwikkelomgeving. Specifiek:

   a. De CI-pijplijn wordt geactiveerd van de samenvoegbewerking naar Main. De CI-pijplijn voert alle stappen uit die in de pull-pijplijn worden uitgevoerd en de volgende stappen:

   • Experimentenstroom
   • Evaluatiestroom
   • Registreert de stromen in het Azure Machine Learning-register wanneer wijzigingen worden gedetecteerd

   b. De CD-pijplijn wordt geactiveerd na de voltooiing van de CI-pijplijn. Deze stroom voert de volgende stappen uit:

   • Hiermee wordt de stroom van het Azure Machine Learning-register geïmplementeerd naar een online-eindpunt van Azure Machine Learning
   • Voert integratietests uit die gericht zijn op het online-eindpunt
   • Voert betrouwbaarheidstests uit die gericht zijn op het online-eindpunt

5. Een goedkeuringsproces is ingebouwd in het proces voor releasepromotie: bij goedkeuring worden de CI & CD-processen beschreven in stap 4.a. & 4.b. worden herhaald, gericht op de testomgeving. Stappen a. en b. zijn hetzelfde, behalve dat gebruikersacceptatietests worden uitgevoerd na de betrouwbaarheidstests in de testomgeving.

6. De CI & CD-processen die worden beschreven in stap 4.a. & 4.b. worden uitgevoerd om de release naar de productieomgeving te promoten nadat de testomgeving is geverifieerd en goedgekeurd.

7. Na de release in een liveomgeving vinden de operationele taken van het bewaken van metrische prestatiegegevens en het evalueren van de geïmplementeerde LLM plaats. Dit omvat, maar is niet beperkt tot:

   • Gegevensdrift detecteren
   • De infrastructuur observeren
   • Kosten beheren
   • De prestaties van het model doorgeven aan belanghebbenden

Implementatierichtlijnen

Met Azure Machine Learning-eindpunten kunt u modellen implementeren op een manier die flexibiliteit biedt bij het vrijgeven van productie. Houd rekening met de volgende strategieën om de beste modelprestaties en -kwaliteit te garanderen:

• Blauw/groen implementaties: Met deze strategie kunt u uw nieuwe versie van de webservice veilig implementeren voor een beperkte groep gebruikers of aanvragen voordat u al het verkeer naar de nieuwe implementatie omleidt.
• A/B-testen: Niet alleen zijn blauw/groene implementaties effectief voor het veilig implementeren van wijzigingen, ze kunnen ook worden gebruikt om nieuw gedrag te implementeren waarmee een subset van gebruikers de impact van de wijziging kan evalueren.
• Voeg linting toe aan Python-bestanden die deel uitmaken van de promptstroom in uw pijplijnen. Linting controleert op naleving van stijlstandaarden, fouten, codecomplexiteit, ongebruikte importbewerkingen en naamgeving van variabelen.
• Wanneer u uw stroom implementeert in de netwerkisolatie van de Azure Machine Learning-werkruimte, gebruikt u een zelf-hostende agent om artefacten in uw Azure-resources te implementeren.
• Het Azure Machine Learning-modelregister mag alleen worden bijgewerkt wanneer er wijzigingen in het model zijn.
• De LLM, de stromen en de clientgebruikersinterface moeten losjes worden gekoppeld. Updates voor de stromen en de gebruikersinterface van de client kunnen en moeten kunnen worden uitgevoerd zonder dat dit van invloed is op het model en omgekeerd.
• Bij het ontwikkelen en implementeren van meerdere stromen moet elke stroom een eigen levenscyclus hebben, wat een losjes gekoppelde ervaring mogelijk maakt bij het bevorderen van stromen van experimenten naar productie.

Infrastructuur

Wanneer u de end-to-end-chatonderdelen van Azure OpenAI volgens de basislijn implementeert, zijn sommige van de services die zijn ingericht, fundamenteel en permanent binnen de architectuur, terwijl andere onderdelen kortstondig van aard zijn, zijn hun bestaan gekoppeld aan een implementatie.

Basisonderdelen

Sommige onderdelen in deze architectuur bestaan met een levenscyclus die verder gaat dan elke afzonderlijke promptstroom of een modelimplementatie. Deze resources worden doorgaans eenmaal geïmplementeerd als onderdeel van de basisimplementatie door het workloadteam en worden afgezien van nieuwe, verwijderde of updates voor de promptstromen of modelimplementaties onderhouden.

• Azure Machine Learning-werkruimte
• Azure Storage-account voor de Azure Machine Learning-werkruimte
• Azure Container Registry
• Azure AI Search
• Azure OpenAI
• Azure Application Insights
• Azure Bastion
• Virtuele Azure-machine voor de jumpbox

Kortstondige onderdelen

Sommige Azure-resources zijn nauwer gekoppeld aan het ontwerp van specifieke promptstromen, zodat deze resources afhankelijk zijn van de levenscyclus van het onderdeel en kortstondig worden in deze architectuur. Deze worden beïnvloed wanneer de workload zich ontwikkelt, zoals wanneer stromen worden toegevoegd of verwijderd of wanneer nieuwe modellen worden geïntroduceerd. Deze resources worden opnieuw gemaakt en eerdere exemplaren verwijderd. Sommige van deze resources zijn directe Azure-resources en sommige zijn manifestaties van het gegevensvlak binnen de bijbehorende service.

• Het model in het Azure Machine Learning-modelregister moet worden bijgewerkt, indien gewijzigd, als onderdeel van de CD-pijplijn.
• De containerinstallatiekopieën moeten worden bijgewerkt in het containerregister als onderdeel van de CD-pijplijn.
• Er wordt een Azure Machine Learning-eindpunt gemaakt wanneer een promptstroom wordt geïmplementeerd als de implementatie verwijst naar een eindpunt dat niet bestaat. Dit eindpunt moet worden bijgewerkt om openbare toegang uit te schakelen.
• De implementaties van het Azure Machine Learning-eindpunt worden bijgewerkt wanneer een stroom wordt geïmplementeerd of verwijderd.
• De Key Vault voor de clientgebruikersinterface moet worden bijgewerkt met de sleutel naar het eindpunt wanneer er een nieuw eindpunt wordt gemaakt.

Controleren

Diagnostische gegevens worden geconfigureerd voor alle services. Alle services, maar Azure Machine Learning en Azure-app Service zijn geconfigureerd om alle logboeken vast te leggen. De diagnostische gegevens van Azure Machine Learning zijn geconfigureerd voor het vastleggen van de auditlogboeken die alle resourcelogboeken zijn waarmee interacties van klanten met gegevens of de instellingen van de service worden vastgelegd. Azure-app Service is geconfigureerd voor het vastleggen van AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs en AppServicePlatformLogs.

Dit scenario implementeren

Volg de stappen in de end-to-end referentie-implementatie van OpenAI om de referentie-implementatie te implementeren en uit te voeren.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

• Rob Bagby | Patronen en procedures - Microsoft
• Freddy Ayala | Cloud Solution Architect - Microsoft
• Prabal Deb | Senior Software Engineer - Microsoft
• Raouf Almouat | Software Engineer II - Microsoft
• Ritesh Modi | Principal Software Engineer - Microsoft
• Ryan Pfalz | Senior oplossingsarchitect - Microsoft

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

Meer informatie over Azure OpenAI

Verwante resources

• Azure OpenAI
• Grote taalmodellen van Azure OpenAI
• Azure Machine Learning-promptstroom
• Isolatie van beheerde virtuele netwerken in werkruimte
• Een privé-eindpunt configureren voor een Azure Machine Learning werkruimte
• Inhoud filteren