End-to-end architectuur voor openAI-chatbasislijn

Bedrijfschattoepassingen kunnen werknemers in staat stellen via gespreksinteractie. Dit geldt vooral vanwege de continue vooruitgang van taalmodellen, zoals GPT-modellen van OpenAI en LLaMA-modellen van Meta. Deze chattoepassingen bestaan uit een gebruikersinterface (UI), gegevensopslagplaatsen die domeinspecifieke informatie bevatten die relevant is voor de query's van de gebruiker, taalmodellen die redeneren voor de domeinspecifieke gegevens om een relevant antwoord te produceren en een orchestrator die de interactie tussen deze onderdelen overziet.

Dit artikel bevat een basisarchitectuur voor het bouwen en implementeren van bedrijfschattoepassingen die gebruikmaken van taalmodellen van Azure OpenAI Service. De architectuur maakt gebruik van een promptstroom om uitvoerbare stromen te maken. Deze uitvoerbare stromen organiseren de werkstroom van binnenkomende prompts naar gegevensarchieven om grondgegevens voor de taalmodellen op te halen, samen met andere vereiste Python-logica. De uitvoerbare stroom wordt geïmplementeerd op een beheerd online-eindpunt met beheerde compute.

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 Service. In die architectuur communiceert App Service met de PaaS-oplossing (Platform as a Service) van Azure via integratie van virtuele netwerken via privé-eindpunten. De chat-UI App Service communiceert met het beheerde online-eindpunt voor de stroom via een privé-eindpunt. Openbare toegang tot de Azure AI Foundry-portal is uitgeschakeld.

De Azure AI Foundry-hub is geconfigureerd met beheerde isolatie van 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 op Machine Learning-rekenkracht.

Een hub is de Azure AI Foundry-resource op het hoogste niveau, die een centrale manier biedt om beveiliging, connectiviteit en andere problemen in meerdere projecten te beheren. Voor deze architectuur is slechts één project vereist voor de workload. Als u aanvullende ervaringen hebt waarvoor verschillende promptstromen met verschillende logica zijn vereist, kunt u overwegen om verschillende back-endbronnen zoals gegevensarchieven te gebruiken. U kunt overwegen deze in een ander project te implementeren.

Architectuur

Een Visio-bestand van deze architectuur downloaden.

Onderdelen

Veel onderdelen van deze architectuur zijn hetzelfde als de end-to-end-chatarchitectuur van Azure OpenAI. In de volgende lijst worden alleen de wijzigingen in de basisarchitectuur gemarkeerd.

• Azure OpenAI wordt gebruikt in zowel de basis- als deze basislijnarchitectuur. Azure OpenAI is een volledig beheerde service die REST API-toegang biedt tot de taalmodellen van Azure OpenAI, waaronder de GPT-4, GPT-3.5-Turbo en insluitsets van modellen. De basislijnarchitectuur maakt gebruik van bedrijfsfuncties zoals virtueel netwerk en private link die niet door de basisarchitectuur worden geïmplementeerd.
• Azure AI Foundry- is een platform dat u kunt gebruiken om AI-oplossingen te bouwen, testen en implementeren. De Azure AI Foundry-portal wordt in deze architectuur gebruikt voor het bouwen, testen en implementeren van de logica voor promptstroomindeling voor de chattoepassing. In deze architectuur biedt Azure AI Foundry het beheerde virtuele netwerk voor netwerkbeveiliging. Zie de sectie netwerken voor meer informatie.
• Application Gateway is een load balancer van laag 7 (HTTP/S) en webverkeerrouter. Het maakt gebruik van op URL-pad gebaseerde routering om binnenkomend verkeer over beschikbaarheidszones te distribueren en versleuteling te offloads om de prestaties van toepassingen te verbeteren.
• Web Application Firewall (WAF) is een cloudeigen service die web-apps beschermt tegen veelvoorkomende aanvallen, zoals SQL-injectie en cross-site scripting. Web Application Firewall biedt inzicht in het verkeer van en naar uw webtoepassing, zodat u uw toepassing kunt bewaken en beveiligen.
• Azure Key Vault is een service waarmee geheimen, versleutelingssleutels en certificaten veilig worden opgeslagen en beheerd. Het centraliseert het beheer van gevoelige informatie.
• Virtueel Azure-netwerk is een service waarmee u geïsoleerde en beveiligde virtuele privénetwerken in Azure kunt maken. Voor een webtoepassing in App Service hebt u een subnet van een virtueel netwerk nodig om privé-eindpunten te gebruiken voor netwerkbeveiliging tussen resources.
• Met Private Link kunnen clients rechtstreeks vanuit particuliere virtuele netwerken toegang krijgen tot PaaS-services (Platform as a Service) zonder openbare IP-adressen te gebruiken.
• Azure DNS is een hostingservice voor DNS-domeinen die naamomzetting biedt met behulp van de Microsoft Azure-infrastructuur. Privé-DNS zones bieden een manier om de FQDN (Fully Qualified Domain Name) van een service toe te wijzen aan het IP-adres van een privé-eindpunt.

Alternatieven

Deze architectuur heeft meerdere onderdelen die kunnen worden bediend door andere Azure-services die beter aansluiten op uw functionele en niet-functionele vereisten van uw workload. Hier volgen enkele alternatieven om rekening mee te houden.

Azure Machine Learning-werkruimten (en portalervaringen)

Deze architectuur maakt gebruik van Azure AI Foundry Portal om promptstromen te bouwen, testen en implementeren. U kunt ook Azure Machine Learning-werkruimten gebruiken, omdat beide services overlappende functies hebben. Hoewel Azure AI Foundry Portal een goede keuze is als u een oplossing voor promptstromen ontwerpt, zijn er enkele functies waarvoor Azure Machine Learning momenteel betere ondersteuning biedt. Zie de functievergelijking voor meer informatie. We raden u aan om Azure AI Foundry Portal en Azure Machine Learning Studio niet te combineren. Als uw werk volledig kan worden uitgevoerd in de Azure AI Foundry-portal, gebruikt u de Azure AI Foundry-portal. Als u nog steeds functies van Azure Machine Learning-studio nodig hebt, kunt u Azure Machine Learning-studio blijven gebruiken.

Onderdelen van de toepassingslaag

Er zijn verschillende services voor beheerde toepassingen beschikbaar in Azure die kunnen fungeren als een toepassingslaag voor de front-end van de chatgebruikersinterface. Zie Kies een Azure-rekenservice voor alle berekeningen en kies een Azure-containerservice voor containeroplossingen. Terwijl Azure Web Apps en Web App for Containers bijvoorbeeld zijn geselecteerd voor respectievelijk de CHAT-API en de promptstroomhost, kunnen vergelijkbare resultaten worden bereikt met Azure Kubernetes Service (AKS) of Azure Container Apps. Kies het toepassingsplatform van uw workload op basis van de specifieke functionele en niet-functionele vereisten van de workload.

Promptstroomhosting

Het implementeren van promptstromen is niet beperkt tot Machine Learning-rekenclusters. Deze architectuur illustreert dat met een alternatief in Azure-app Service. Stromen zijn uiteindelijk een containertoepassing die kan worden geïmplementeerd in elke Azure-service die compatibel is met containers. Deze opties omvatten services zoals Azure Kubernetes Service (AKS), Azure Container Apps en Azure-app Service. Kies een Azure-containerservice op basis van de vereisten van uw indelingslaag.

Een voorbeeld van waarom hostingpromptstroom hosten op een alternatieve berekening is een overweging verderop in dit artikel.

Grounding-gegevensarchief

Hoewel deze architectuur leidt met Azure AI Search, is uw keuze voor het gegevensarchief voor uw grondgegevens een architectuurbeslissing die specifiek is voor uw workload. Veel workloads zijn in feite polyglot en hebben verschillende bronnen en technologieën voor het gronden van gegevens. Deze gegevensplatforms variëren van bestaande OLTP-gegevensarchieven, cloudeigen databases zoals Azure Cosmos DB, via gespecialiseerde oplossingen zoals Azure AI Search. Een veelvoorkomende, maar niet vereiste, kenmerk voor een dergelijk gegevensarchief is vectorzoekopdrachten. Zie Kies een Azure-service voor vectorzoekopdrachten om opties in deze ruimte te verkennen.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Frameworkvoor meer informatie.

Deze architectuur wordt het beste door het ontwerpproces voor uw specifieke situatie genomen wanneer de ontwerpinspanningen worden gecombineerd met de ontwerprichtlijnen in de AI-workloads van Azure Well-Architected Framework in Azure principes en aanbevelingen.

Betrouwbaarheid

Betrouwbaarheid zorgt ervoor dat uw toepassing kan voldoen aan de toezeggingen die u aan uw klanten hebt gedaan. Zie de controlelijst ontwerpbeoordeling voor betrouwbaarheid voor meer informatie.

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. Zie de basislijn om deze richtlijnen te bekijken voor meer informatie.

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

Zonegebonden redundantie voor stroomimplementaties

Voor bedrijfsimplementaties is meestal zonegebonden redundantie vereist. Om zonegebonden redundantie in Azure te bereiken, moeten resources beschikbaarheidszones ondersteunen en moet u ten minste drie exemplaren van de resource implementeren of de platformondersteuning inschakelen wanneer exemplaarbeheer niet beschikbaar is. Op dit moment biedt Machine Learning-rekenkracht geen ondersteuning voor beschikbaarheidszones. Om de mogelijke impact van een ramp op datacenterniveau op Machine Learning-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 kunt statuscontroles gebruiken om ervoor te zorgen dat aanroepen alleen worden gerouteerd naar clusters die goed werken.

Er zijn enkele alternatieven voor Machine Learning-rekenclusters, zoals Azure Kubernetes Service (AKS), Azure Functions, Azure Container Apps en Azure-app Service. Elk van deze services ondersteunt 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.

In het volgende diagram ziet u een alternatieve architectuur waarin promptstromen worden geïmplementeerd in 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.

Het diagram is genummerd voor belangrijke gebieden in deze architectuur:

1. Stromen worden nog steeds geschreven in de promptstroom en de netwerkarchitectuur is ongewijzigd. Stroomauteurs maken nog steeds verbinding met de ontwerpervaring in het Azure AI Foundry-project 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 gecontaineriseerde uitvoerbare stromen naar Container Registry worden gepusht. Niet weergegeven in het diagram zijn de pijplijnen die de stromen in een container plaatsen en naar Container Registry pushen. De berekening waarop deze pijplijnen worden uitgevoerd, moet een netwerklijn hebben voor resources zoals het Azure-containerregister en het Azure AI Foundry-project.

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 een containerprompt, die is geplaatst op hetzelfde App Service-plan dat al ten minste drie exemplaren wordt uitgevoerd, verspreid over beschikbaarheidszones. Deze App Service-exemplaren maken via een privé-eindpunt verbinding met Container Registry 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 maakt de promptstroomcontainer verbinding met AI Search en Azure OpenAI. PaaS-services die alleen beschikbaar zijn gemaakt voor het subnet van het door Machine Learning beheerde privé-eindpunten, 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 kunt statuscontroles gebruiken 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 bestanden te verfijnen, zoals een geografisch redundant opslagaccount. Deze benadering minimaliseert de status die voor elke regio is opgeslagen in Azure OpenAI. U moet bestanden voor elk exemplaar nog steeds verfijnen 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). Zorg ervoor dat er voldoende TPM is 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 kan worden geïmplementeerd vóór uw Azure OpenAI-service of -services en kan worden geconfigureerd voor opnieuw proberen als er tijdelijke fouten en beperking zijn. API Management kan ook worden gebruikt als circuitonderbreker om te voorkomen dat de service wordt overweldigd door aanroepen, waardoor het quotum wordt overschreden. Zie Access Azure OpenAI en andere taalmodellen via een gateway voor meer informatie over het toevoegen van een gateway voor betrouwbaarheidsproblemen.

AI Search - betrouwbaarheid

Implementeer AI Search met de prijscategorie Standard of hoger in een regio die beschikbaarheidszones ondersteunt en implementeer drie of meer replica's. 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:

• AI Search bewaken.

• Gebruik bewakingsgegevens en logboeken en prestatieanalyse om het juiste aantal replica's te bepalen om op query's gebaseerde beperking en partities te voorkomen en om beperking op basis van indexen te voorkomen.

Azure AI Foundry - betrouwbaarheid

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

• Schaal uw online-eindpunten automatisch op 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 er te weinig exemplaren beschikbaar zijn als gevolg van overprovisioning.

• 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.

Beheerde online-eindpunten fungeren als een load balancer en router voor de beheerde berekening die achter hen wordt uitgevoerd. U kunt het percentage verkeer configureren dat naar elke implementatie moet worden gerouteerd, zolang de percentages maximaal 100% bedragen. U kunt ook een beheerd online-eindpunt implementeren met 0% verkeer dat naar elke implementatie wordt gerouteerd. Als u, zoals in de opgegeven referentie-implementatie, infrastructuur als code (IaC) gebruikt om uw resources te implementeren, inclusief uw beheerde online-eindpunten, is er een probleem met de betrouwbaarheid. Als u verkeer hebt geconfigureerd om te routeren naar implementaties (gemaakt via CLI of de Azure AI Foundry-portal) en u een volgende IaC-implementatie uitvoert die het beheerde online-eindpunt bevat, zelfs als het beheerde online-eindpunt op geen enkele manier wordt bijgewerkt, wordt het eindpuntverkeer teruggezet naar het routeren van 0% verkeer. Dit betekent dat uw geïmplementeerde promptstromen niet meer bereikbaar zijn totdat u het verkeer weer naar de gewenste locatie aanpast.

Ontwerp voor meerdere regio's

Deze architectuur is niet gebouwd als een regionale stempel in een architectuur met meerdere regio's. Het biedt hoge beschikbaarheid binnen één regio vanwege het volledige gebruik van beschikbaarheidszones, maar mist enkele belangrijke onderdelen om dit echt gereed te maken voor een oplossing voor meerdere regio's. Dit zijn enkele onderdelen of overwegingen die ontbreken in deze architectuur:

• Globaal inkomend verkeer en routering
• STRATEGIE voor DNS-beheer
• Strategie voor gegevensreplicatie (of isolatie)
• Een actief-actief,actief-passief- of actief-koude aanduiding
• Een failover- en failbackstrategie om de RTO en RPO van uw workload te bereiken
• Beslissingen over beschikbaarheid van regio's voor ontwikkelaarservaringen in de Azure Studio Hub-resource

Als de vereisten van uw workload een strategie voor meerdere regio's vereisen, moet u investeren in aanvullende ontwerpinspanningen rond onderdelen en operationele processen bovenop wat in deze architectuur wordt gepresenteerd. U ontwerpt om taakverdeling of failover op de volgende lagen te ondersteunen:

• Grondgegevens
• Modelhosting
• Indelingslaag (promptstroom in deze architectuur)
• Clientgerichte gebruikersinterface

Daarnaast moet u bedrijfscontinuïteit behouden in waarneembaarheid, portalervaringen en verantwoorde AI-problemen, zoals inhoudsveiligheid.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie de controlelijst ontwerpbeoordeling voor beveiliging voor meer informatie.

Deze architectuur breidt de beveiligingsvoetafdruk uit die is geïmplementeerd in de end-to-end-chat van Basic met de Azure OpenAI-architectuur. Hoewel de basisarchitectuur gebruikmaakt van door het systeem toegewezen beheerde identiteiten en door het systeem toegewezen roltoewijzingen, maakt deze architectuur gebruik van door de gebruiker toegewezen identiteiten met handmatig gemaakte roltoewijzingen.

De architectuur implementeert een netwerkbeveiligingsperimeter, samen met de identiteitsperimeter die is geïmplementeerd in de basisarchitectuur. Vanuit een netwerkperspectief is de chatinterface via Application 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.

Naast netwerkoverwegingen worden in deze sectie beveiligingsoverwegingen beschreven voor sleutelrotatie en het afstemmen van het Azure OpenAI-model.

Identiteits- en toegangsbeheer

Houd rekening met de volgende richtlijnen bij het gebruik van door de gebruiker toegewezen beheerde identiteiten:

• Maak, indien van toepassing, afzonderlijke beheerde identiteiten voor de volgende Azure AI Foundry- en Machine Learning-resources:
  • Azure AI Foundry Hub
  • Azure AI Foundry-projecten voor het ontwerpen en beheren van stromen
  • Online-eindpunten in de geïmplementeerde stroom als de stroom wordt geïmplementeerd op een beheerd online-eindpunt
• Besturingselementen voor identiteitstoegang voor de chatinterface implementeren met behulp van Microsoft Entra ID

Maak afzonderlijke projecten en online-eindpunten voor verschillende promptstromen die u wilt isoleren van anderen vanuit het perspectief van machtigingen. Maak een afzonderlijke beheerde identiteit voor elk project en een beheerd online-eindpunt. Geef auteurs van promptstromen alleen toegang tot de projecten die ze nodig hebben.

Wanneer u gebruikers onboardt voor Azure AI Foundry-projecten om functies zoals het ontwerpen van stromen uit te voeren, moet u roltoewijzingen met minimale bevoegdheden maken voor de resources die ze nodig hebben.

Op rollen gebaseerd toegangsrollen voor Machine Learning

Net als in de basisarchitectuur maakt het systeem automatisch roltoewijzingen voor de door het systeem toegewezen beheerde identiteiten. Omdat het systeem niet weet welke functies van de hub en projecten u kunt gebruiken, maakt het roltoewijzingen ondersteuning voor alle mogelijke functies. De automatisch gemaakte roltoewijzingen kunnen de inrichtingsbevoegdheden overschrijven op basis van uw use-case. Een voorbeeld is de rol Inzender die is toegewezen aan de hub voor het containerregister, waarbij alleen lezertoegang tot het besturingsvlak vereist is. Als u machtigingen verder moet beperken voor doelen met minimale bevoegdheden, moet u door de gebruiker toegewezen identiteiten gebruiken. U maakt en onderhoudt deze roltoewijzingen zelf.

Vanwege de onderhoudslast van het beheren van alle vereiste toewijzingen, geeft deze architectuur de voorkeur aan operationele uitmuntendheid ten opzichte van toewijzingen van absolute minimale bevoegdheden. Houd er rekening mee dat u alle toewijzingen in de tabel moet maken.

Beheerde identiteit	Bereik	Roltoewijzingen
Door hub beheerde identiteit	Inzender	Resourcegroep
Door hub beheerde identiteit	Hub	Azure AI-beheerder
Door hub beheerde identiteit	Container Registry	Inzender
Door hub beheerde identiteit	Key Vault	Inzender
Door hub beheerde identiteit	Key Vault	Beheerder
Door hub beheerde identiteit	Opslagaccount	Lezer
Door hub beheerde identiteit	Opslagaccount	Inzender voor opslagaccounts
Door hub beheerde identiteit	Opslagaccount	Inzender voor opslagblobgegevens
Door hub beheerde identiteit	Opslagaccount	Inzender met bevoegdheid voor opslagbestandsgegevens
Door hub beheerde identiteit	Opslagaccount	Inzender van opslagtabelgegevens
Beheerde identiteit van project	Project	Azure AI-beheerder
Beheerde identiteit van project	Container Registry	Inzender
Beheerde identiteit van project	Key Vault	Inzender
Beheerde identiteit van project	Key Vault	Beheerder
Beheerde identiteit van project	Opslagaccount	Lezer
Beheerde identiteit van project	Opslagaccount	Inzender voor opslagaccounts
Beheerde identiteit van project	Opslagaccount	Inzender voor opslagblobgegevens
Beheerde identiteit van project	Opslagaccount	Inzender met bevoegdheid voor opslagbestandsgegevens
Beheerde identiteit van project	Opslagaccount	Inzender van opslagtabelgegevens
Beheerde identiteit voor online-eindpunt	Project	Verbindingsgeheimen voor Azure Machine Learning-werkruimte
Beheerde identiteit voor online-eindpunt	Project	AzureML Metrics Writer
Beheerde identiteit voor online-eindpunt	Container Registry	ACRPull
Beheerde identiteit voor online-eindpunt	Azure OpenAI	Cognitive Services OpenAI-gebruiker
Beheerde identiteit voor online-eindpunt	Opslagaccount	Inzender voor opslagblobgegevens
Beheerde identiteit voor online-eindpunt	Opslagaccount	Lezer voor opslagblobgegevens
App Service (wanneer de promptstroom wordt geïmplementeerd in App Service)	Azure OpenAI	Cognitive Services OpenAI-gebruiker
Portalgebruiker (ontwikkeling van promptstroom)	Azure OpenAI	Cognitive Services OpenAI-gebruiker
Portalgebruiker (ontwikkeling van promptstroom)	Opslagaccount	Inzender voor opslagblobgegevens (voorwaardelijke toegang gebruiken)
Portalgebruiker (ontwikkeling van promptstroom)	Opslagaccount	Inzender met bevoegdheid voor opslagbestandsgegevens

Het is belangrijk om te begrijpen dat de Azure AI Foundry-hub Azure-resources bevat die worden gedeeld in projecten, zoals een opslagaccount en Container Registry. Als u gebruikers hebt die alleen toegang nodig hebben tot een subset van de projecten, kunt u overwegen om roltoewijzingsvoorwaarden te gebruiken voor Azure-services die deze ondersteunen, om toegang tot resources met minimale bevoegdheden te bieden. Blobs in Azure Storage bieden bijvoorbeeld ondersteuning voor roltoewijzingsvoorwaarden. Gebruik voor een gebruiker die toegang nodig heeft tot een subset van de projecten, in plaats van machtigingen per container toe te wijzen, roltoegangsvoorwaarden om machtigingen te beperken tot de blobcontainers die door deze projecten worden gebruikt. Elk project heeft een unieke GUID die fungeert als voorvoegsel voor de namen van de blobcontainers die in dat project worden gebruikt. Deze GUID kan worden gebruikt als onderdeel van de voorwaarden voor roltoewijzing.

De hub heeft een vereiste om toegang te hebben Contributor tot de hubresourcegroep om het mogelijk te maken en beheerde hub- en projectresources te maken. Een neveneffect hiervan is dat de hub besturingsvlaktoegang heeft tot alle resources die ook in de resourcegroep aanwezig zijn. Alle Azure-resources die niet rechtstreeks zijn gerelateerd aan de hub en de bijbehorende projecten, moeten worden gemaakt in een afzonderlijke resourcegroep. U wordt aangeraden minimaal twee resourcegroepen voor een workloadteam te maken met behulp van een zelfbeheerde Azure AI Foundry-hub. Eén resourcegroep die de hub, de bijbehorende projecten en alle directe afhankelijkheden bevat, zoals het Azure-containerregister, Key Vault, enzovoort. Eén resourcegroep die alle andere resources in uw workload bevat.

Het is raadzaam om het gebruik van Azure-resources die nodig zijn voor de bewerking van de hub te minimaliseren (Container Registry, Storage-account, Key Vault, Application Insights) door andere onderdelen in uw workloads. Als u bijvoorbeeld geheimen wilt opslaan als onderdeel van uw workload, moet u een afzonderlijke Sleutelkluis maken, afgezien van de sleutelkluis die aan de hub is gekoppeld. De hub Key Vault mag alleen worden gebruikt door de hub om hub- en projectgeheimen op te slaan.

Zorg ervoor dat voor elk afzonderlijk project de roltoewijzingen voor de bijbehorende afhankelijkheden geen toegang bieden tot resources die de portalgebruiker en beheerde beheerde online-eindpuntidentiteit niet nodig hebben. De Cognitive Services OpenAI User roltoewijzing aan Azure OpenAI verleent bijvoorbeeld toegang tot alle implementaties voor die resource. Er is geen manier om stroomauteurs of beheerde beheerde online-eindpunten te beperken met die roltoewijzingstoegang tot specifieke modelimplementaties in Azure OpenAI. Voor dergelijke scenario's is het onze richtlijnen om services zoals Azure OpenAI en Azure AI Search per project te implementeren en geen resources te implementeren voor die services die auteurs of beheerde beheerde online-eindpuntidentiteiten niet mogen hebben. Implementeer bijvoorbeeld alleen modellen in het Azure OpenAI-exemplaar van het project waartoe het project toegang nodig heeft. Implementeer alleen indexen in het Azure AI Search-exemplaar van het project waartoe het project toegang moet hebben.

Netwerken

Samen met op identiteit gebaseerde toegang vormt netwerkbeveiliging de kern van de end-to-end-chatarchitectuur van de basislijn die gebruikmaakt van OpenAI. Op hoog niveau zorgt de netwerkarchitectuur ervoor dat:

• Slechts één beveiligd toegangspunt voor chatgebruikersinterfaceverkeer.
• Netwerkverkeer wordt gefilterd.
• Gegevens die onderweg zijn, worden end-to-end versleuteld met TLS (Transport Layer Security).
• Gegevensexfiltratie worden geminimaliseerd door Private Link te gebruiken om verkeer in Azure te houden.
• Netwerkbronnen worden logisch gegroepeerd en geïsoleerd van elkaar via netwerksegmentatie.

Netwerkstromen

Twee stromen in dit diagram worden behandeld in de architectuur van de App Service-webtoepassing basislijn: de binnenkomende stroom van de eindgebruiker naar de chatgebruikersinterface (1) en de stroom van App Service naar Azure PaaS-services (2). Deze sectie is gericht op de online-eindpuntstroom van Machine Learning. De volgende stroom gaat van de chatgebruikersinterface die wordt uitgevoerd in de App Service-webtoepassing basislijn naar de stroom die is geïmplementeerd voor Machine Learning-rekenkracht:

1. De oproep vanuit de door App Service gehoste chatgebruikersinterface wordt gerouteerd via een privé-eindpunt naar het online-eindpunt van 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 Machine Learning

In deze architectuur is openbare toegang tot de Machine Learning-werkruimte uitgeschakeld. Gebruikers hebben toegang tot de werkruimte via privétoegang, omdat de architectuur het privé-eindpunt volgt voor de configuratie van de Machine Learning-werkruimte . In feite worden privé-eindpunten in deze architectuur gebruikt om de beveiliging op basis van identiteiten aan te vullen. Uw door App Service gehoste chatinterface kan bijvoorbeeld verbinding maken met PaaS-services die niet beschikbaar zijn voor het openbare internet, inclusief Machine Learning-eindpunten.

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

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. Connectiviteit met het virtuele netwerk kan ook worden bereikt via ExpressRoute- of VPN-gateways en peering van virtuele netwerken.

Stroom van het beheerde virtuele netwerk van Azure AI Foundry naar Azure PaaS-services

U wordt aangeraden de Azure AI Foundry-hub te configureren voor beheerde isolatie van virtuele netwerken 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 Container Registry en Storage. Door de gebruiker gedefinieerde uitgaande regels zijn voor aangepaste resources, zoals Azure OpenAI of AI Search, die uw werkstroom gaat gebruiken. U moet door de gebruiker gedefinieerde uitgaande regels configureren. Vereiste uitgaande regels worden geconfigureerd wanneer het beheerde virtuele netwerk wordt gemaakt. Het beheerde virtuele netwerk wordt op aanvraag geïmplementeerd wanneer u het voor het eerst gebruikt en vanaf dat moment persistent is.

De uitgaande regels kunnen privé-eindpunten, servicetags of FQDN's (Fully Qualified Domain Names) zijn voor externe openbare eindpunten. In deze architectuur zijn connectiviteit met Azure-services zoals Container Registry, Storage, Azure Key Vault, Azure OpenAI en AI Search verbonden via een privékoppeling. Hoewel dit niet in deze architectuur gebeurt, worden enkele veelvoorkomende bewerkingen waarvoor het configureren van een uitgaande FQDN-regel vereist, een pip-pakket gedownload, een GitHub-opslagplaats klonen of basiscontainerinstallatiekopieën downloaden uit externe opslagplaatsen.

Het uitgaande FQDN-besturingselement wordt geïmplementeerd door een door Microsoft beheerde Azure Firewall die is geïmplementeerd in het beheerde netwerk van Azure AI Foundry. Kies de prijscategorie Basic als u alleen HTTP-verkeer (poort 80) of HTTPS (poort 443) wilt beheren. Als voor uitgaand verkeer aangepaste protocollen of poorten zijn vereist, selecteert u de prijscategorie Standard. In deze architectuur wordt de prijscategorie Basic gebruikt omdat het enige uitgaand verkeer naar HTTPS-eindpunten op poort 443 is.

Segmentatie en beveiliging van virtuele netwerken

Het netwerk in deze architectuur heeft voor de volgende doeleinden afzonderlijke subnetten:

• Application Gateway
• App Service-integratieonderdelen
• Privé-eindpunten
• Azure Bastion
• Jump box virtual machine
• Trainings- en scoresubnetten: beide zijn bedoeld voor bring your own compute met betrekking tot training en deductie. In deze architectuur voeren we geen training uit en gebruiken we beheerde berekeningen.
• Scoren

Elk subnet heeft een netwerkbeveiligingsgroep (NSG) die zowel inkomend als uitgaand verkeer voor deze subnetten beperkt tot alleen wat er nodig is. In de volgende tabel ziet u een vereenvoudigde weergave van de NSG-regels die de basislijn toevoegt aan elk subnet. De tabel bevat de naam en functie van de regel.

Subnet	Inkomend	Uitgaand
snet-appGateway	Vergoedingen voor onze chatgebruikersinterfacegebruikersbron-IP's (zoals openbaar internet), plus vereiste items voor de service.	Toegang tot het privé-eindpunt van App Service, plus vereiste items voor de service.
snet-PrivateEndpoints	Alleen verkeer van het virtuele netwerk toestaan.	Alleen verkeer naar het virtuele netwerk toestaan.
snet-AppService	Alleen verkeer van het virtuele netwerk toestaan.	Toegang tot de privé-eindpunten en Azure Monitor toestaan.
AzureBastionSubnet	Zie de richtlijnen voor het werken met NSG-toegang en Azure Bastion.	Zie de richtlijnen voor het werken met NSG-toegang en Azure Bastion.
snet-jumpbox	Sta inkomend Remote Desktop Protocol (RDP) en SSH toe vanuit het Subnet van de Azure Bastion-host.	Toegang tot de privé-eindpunten toestaan
snet-agents	Alleen verkeer van het virtuele netwerk toestaan.	Alleen verkeer naar het virtuele netwerk toestaan.
snet-training	Alleen verkeer van het virtuele netwerk toestaan.	Alleen verkeer naar het virtuele netwerk toestaan.
snet-scoring	Alleen verkeer van het virtuele netwerk toestaan.	Alleen verkeer naar het virtuele netwerk toestaan.

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 Protection 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. Gebruik de striktste regels die volledige oplossingsfunctionaliteit mogelijk maken.

• Gebruik toepassingsbeveiligingsgroepen om NSG's te groeperen. Het groeperen van NSG's maakt het maken van regels eenvoudiger voor complexe omgevingen.

Sleutelroulatie

Er is één service in deze architectuur die gebruikmaakt van verificatie op basis van sleutels: het door Machine Learning beheerde online-eindpunt. Omdat u verificatie op basis van sleutels voor deze service gebruikt, is het belangrijk om:

• Sla de sleutel op in een beveiligd archief, zoals Key Vault, voor toegang op aanvraag van geautoriseerde clients, zoals de Azure-web-app die als host fungeert voor de promptstroomcontainer.

• Implementeer een strategie voor sleutelrotatie. Als u de sleutels handmatig draait, maakt u een verloopbeleid voor sleutels en gebruikt u Azure Policy om te controleren of de sleutel is gedraaid.

OpenAI-model verfijnen

Als u OpenAI-modellen in uw implementatie nauwkeurig afstemt, 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 te gebruiken voor gegevensversleuteling, een beheerde identiteit om de toegang tot de gegevens te beheren en een privé-eindpunt om verbinding te maken met de gegevens.

Governance via beleid

Om de afstemming met beveiliging te waarborgen, kunt u overwegen Azure Policy en netwerkbeleid te gebruiken, zodat implementaties zijn afgestemd op de vereisten van de workload. Het gebruik van platformautomatisering via beleid vermindert de last van handmatige validatiestappen en zorgt voor governance, zelfs als pijplijnen worden overgeslagen. Houd rekening met het volgende beveiligingsbeleid:

• Schakel toegang tot sleutel of andere lokale verificatie uit in services zoals Azure AI-services en Key Vault.
• Specifieke configuratie van netwerktoegangsregels of NSG's vereisen.
• Versleuteling vereisen, zoals het gebruik van door de klant beheerde sleutels.

Azure AI Foundry-roltoewijzingen voor Azure Key Vault

Voor de beheerde identiteit van Azure AI Foundry zijn roltoewijzingen voor zowel het besturingsvlak (Inzender) als het gegevensvlak (Key Vault-beheerder) vereist. Dit betekent dat deze identiteit lees- en schrijftoegang heeft tot alle geheimen, sleutels en certificaten die zijn opgeslagen in de Azure-sleutelkluis. Als uw workload andere services heeft dan Azure AI Foundry waarvoor toegang tot geheimen, sleutels of certificaten in Key Vault is vereist, is uw workload of beveiligingsteam mogelijk niet vertrouwd met de beheerde identiteit van azure AI Foundry Hub die toegang heeft tot deze artefacten. In dit geval kunt u overwegen om een Key Vault-exemplaar specifiek te implementeren voor de Azure AI Foundry-hub en andere Azure Key Vault-exemplaren die geschikt zijn voor andere onderdelen van uw workload.

Kostenoptimalisatie

Kostenoptimalisatie gaat over manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie de controlelijst ontwerpbeoordeling voor 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 DDoS Protection en de firewall die wordt geïmplementeerd als onderdeel van het beheerde online-eindpunt. Andere belangrijke kosten zijn de chatgebruikersinterface en promptstroom berekenen en AI Search. Optimaliseer deze resources om de meeste kosten te besparen.

Compute

Promptstroom ondersteunt meerdere opties voor het hosten van de uitvoerbare stromen. De opties omvatten beheerde online-eindpunten in Machine Learning, AKS, App Service en Azure Kubernetes 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 in Azure OpenAI een combinatie van benaderingen gebruiken:

• Clients beheren. Clientaanvragen zijn de primaire bron van kosten in een verbruiksmodel, dus het beheren van het clientgedrag is essentieel. 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, zoals sleutels of op rollen gebaseerd toegangsbeheer (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 en on-productie-exemplaren zijn, zodat deze activiteiten geen productiekosten maken.

• 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. Gebruik het juiste model voor de use-case om ervoor te 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.

• Inzicht in onderbrekingspunten voor facturering. Voor het afstemmen worden kosten per uur in rekening gebracht. Als u het meest efficiënt wilt zijn, wilt u zoveel mogelijk tijd per uur gebruiken om de resultaten te verbeteren terwijl u de volgende factureringsperiode vermijdt. Op dezelfde manier zijn de kosten voor 100 installatiekopieën van het genereren van installatiekopieën hetzelfde als de kosten voor één 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 . Nadat u voorspelbare gebruikspatronen hebt, kunt u overwegen om over te schakelen naar dit vooraf gekochte factureringsmodel als dit rendabeler is op uw gebruiksvolume.

• Stel inrichtingslimieten in. Zorg ervoor dat alle inrichtingsquota alleen per model worden toegewezen aan modellen die naar verwachting deel uitmaken van de workload. Doorvoer naar al geïmplementeerde modellen is niet beperkt tot dit ingerichte quotum terwijl dynamisch quotum is ingeschakeld. Quota worden niet rechtstreeks toegewezen aan kosten en die kosten kunnen variëren.

• Bewaak het gebruik van betalen per gebruik. Als u prijzen voor betalen per gebruik gebruikt, controleert u het gebruik van TPM en RPM. Gebruik deze informatie om beslissingen over architectuurontwerpen te informeren, zoals welke modellen moeten worden gebruikt en om de grootte van prompts te optimaliseren.

• Bewaak het ingerichte doorvoergebruik. 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 onderbroken.

• 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.

Operationele uitmuntendheid

Operational Excellence behandelt de operationele processen die een toepassing implementeren en deze in productie houden. Zie de controlelijst ontwerpbeoordeling voor Operational Excellence voor meer informatie.

Ingebouwde promptstroomruntimes

Net als in de basisarchitectuur maakt deze architectuur gebruik van de Automatic Runtime om de operationele belasting te minimaliseren. De automatische runtime is een serverloze berekeningsoptie in Machine Learning die het rekenbeheer vereenvoudigt en de meeste configuratie van de promptstroom delegeert naar het bestand en requirements.txt de configuratie van flow.dag.yaml de actieve toepassing. Dit maakt deze keuze laag onderhoud, kortstondig en toepassingsgestuurd. Voor het gebruik van Compute Instance Runtime of extern rekenproces, zoals in deze architectuur, is een meer door het team beheerde levenscyclus van de berekening vereist en moet worden geselecteerd wanneer de workloadvereisten de configuratiemogelijkheden van de optie voor automatische runtime overschrijden.

Controleren

Net als in de basisarchitectuur worden diagnostische gegevens geconfigureerd voor alle services. Alle services, maar App Service zijn geconfigureerd om alle logboeken vast te leggen. App Service is geconfigureerd voor het vastleggen van AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs en AppServicePlatformLogs. In productie zijn alle logboeken waarschijnlijk overmatig. Stem logboekstromen af op uw operationele behoeften. Voor deze architectuur zijn de Azure Machine Learning-logboeken die worden gebruikt door het Azure AI Foundry-project dat van belang is: AmlComputeClusterEvent, AmlDataSetEvent, AmlEnvironmentEvent en AmlModelsEvent.

Evalueer het bouwen van aangepaste waarschuwingen voor de resources in deze architectuur, zoals waarschuwingen in de Basislijnwaarschuwingen van Azure Monitor. Voorbeeld:

• Container Registry-waarschuwingen
• Machine Learning- en Azure OpenAI-waarschuwingen
• Waarschuwingen voor Azure Web Apps

Zorg ervoor dat u het gebruik van tokens bijhoudt voor uw Azure OpenAI-modelimplementaties. In deze architectuur houdt de promptstroom het tokengebruik bij via de integratie met Azure-toepassing Insights.

Bewerkingen van taalmodel

Implementatie voor chatoplossingen op basis van Azure OpenAI, zoals deze architectuur, moet de richtlijnen in GenAIOps volgen met een promptstroom met Azure DevOps en GitHub. Daarnaast moet het aanbevolen procedures overwegen voor continue integratie en continue levering (CI/CD) en door het netwerk beveiligde architecturen. De volgende richtlijnen hebben betrekking op de implementatie van stromen en de bijbehorende infrastructuur op basis van de Aanbevelingen van GenAIOps. Deze implementatierichtlijnen bevatten niet de front-endtoepassingselementen, die ongewijzigd zijn in de architectuur van de maximaal beschikbare zone-redundante webtoepassing basislijn.

Ontwikkeling

Promptstroom biedt zowel een browsergebaseerde ontwerpervaring in de Azure AI Foundry-portal of via een Visual Studio Code-extensie. Beide opties slaan de stroomcode op als bestanden. Wanneer u de Azure AI Foundry-portal gebruikt, worden de bestanden opgeslagen in een opslagaccount. Wanneer u in Microsoft Visual Studio 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 bedrijfsontwikkeling gebruikt u de Microsoft Visual Studio Code-extensie en de promptstroom-SDK/CLI voor ontwikkeling. Auteurs van promptstromen kunnen hun stromen bouwen en testen vanuit Microsoft Visual Studio Code en de lokaal opgeslagen bestanden integreren met het online broncodebeheersysteem 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

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

• Classificatienauwkeurigheid: evalueert of het taalmodel een 'juiste' of 'onjuiste' score geeft en voegt de resultaten samen om een nauwkeurigheidsscore 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 ten opzichte van context: evalueert hoe goed de voorspelde antwoorden van het model zijn gebaseerd op vooraf geconfigureerde context. Zelfs als de antwoorden van het taalmodel 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 taalmodellen om een van de gegevens in uw gouden gegevensset te genereren.

Implementatiestroom

1. De prompt engineer/data scientist opent een functiebranch waar ze aan de specifieke taak of functie werken. De prompt engineer/data scientist itereert de stroom met behulp van promptstroom voor Microsoft Visual Studio Code, periodiek wijzigingen doorvoeren en deze wijzigingen naar de functievertakking pushen.

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.
   • Statische codeanalyse.

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:

   een. 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 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 Machine Learning-register geïmplementeerd naar een online-eindpunt voor 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 releasepromotieproces: na goedkeuring worden de CI & CD-processen beschreven in stappen 4.a en 4.b herhaald, gericht op de testomgeving. Stappen een en b hetzelfde zijn, behalve dat gebruikersacceptatietests worden uitgevoerd na de betrouwbaarheidstests in de testomgeving.

6. De CI & CD-processen die worden beschreven in stappen 4.a en 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 taalmodellen plaats. Dit omvat, maar is niet beperkt tot:

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

Implementatierichtlijnen

U kunt Machine Learning-eindpunten gebruiken om modellen te implementeren op een manier die flexibiliteit mogelijk maakt 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-tests: 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 machine learning-werkruimte met netwerkisolatie, gebruikt u een zelf-hostende agent om artefacten in uw Azure-resources te implementeren.

• Het register van het Machine Learning-model moet alleen worden bijgewerkt wanneer er wijzigingen in het model zijn.

• De taalmodellen, de stromen en de gebruikersinterface van de client 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.

• Wanneer u meerdere stromen ontwikkelt en implementeert, 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 implementeert, zijn sommige services die zijn ingericht, fundamenteel en permanent binnen de architectuur, terwijl andere onderdelen kortstondig zijn, wat hun bestaan is gekoppeld aan een implementatie. Hoewel het beheerde virtuele netwerk fundamenteel is, wordt het automatisch ingericht wanneer u een rekenproces maakt dat leidt tot enkele overwegingen.

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.

• Werkruimte voor Machine Learning
• Opslagaccount voor de Machine Learning-werkruimte
• Container Registry
• 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. Met deze benadering kunnen deze resources worden gebonden aan de levenscyclus van het onderdeel en kortstondig worden in deze architectuur. Azure-resources 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 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 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 Machine Learning-eindpunt worden bijgewerkt wanneer een stroom wordt geïmplementeerd of verwijderd.

• De sleutelkluis voor de clientgebruikersinterface moet worden bijgewerkt met de sleutel naar het eindpunt wanneer er een nieuw eindpunt wordt gemaakt.

Beheerd virtueel netwerk op aanvraag

Het beheerde virtuele netwerk wordt automatisch ingericht wanneer u voor het eerst een rekenproces maakt. Als u infrastructuur als code gebruikt om uw hub te implementeren en u geen Azure AI Foundry-rekenresources in Bicep hebt, wordt het beheerde virtuele netwerk niet geïmplementeerd en krijgt u een foutmelding wanneer u verbinding maakt met de Azure AI Foundry-portal. U moet een eenmalige actie uitvoeren om het beheerde virtuele netwerk handmatig in te richten na uw IaC-implementatie.

Organisatie van resources

Als u een scenario hebt waarin de hub centraal eigendom is van een ander team dan het workloadteam, kunt u ervoor kiezen projecten te implementeren om resourcegroepen te scheiden. Als u infrastructuur als code gebruikt, kunt u dit doen door een andere resourcegroep in te stellen in Bicep. Als u de portal gebruikt, kunt u de defaultWorkspaceResourceGroup eigenschap onder de workspaceHubConfig resourcegroep instellen die u wilt maken voor uw projecten.

Prestatie-efficiëntie

Prestatie-efficiëntie is de mogelijkheid van uw workload om op een efficiënte manier te voldoen aan de eisen die gebruikers eraan stellen. Zie de controlelijst ontwerpbeoordeling voor prestatie-efficiëntie voor meer informatie.

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

Azure Search- prestatie-efficiëntie

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

Azure OpenAI - prestatie-efficiëntie

• Bepaal of voor uw toepassing een ingerichte doorvoer of het gedeelde hosting- of verbruiksmodel is vereist. Ingerichte doorvoer zorgt voor gereserveerde verwerkingscapaciteit voor uw OpenAI-modelimplementaties, die voorspelbare prestaties en doorvoer voor uw modellen biedt. Dit factureringsmodel is in tegenstelling tot het model voor gedeelde hosting of verbruik. Het verbruiksmodel is best effort en kan onderhevig zijn aan lawaaierige buren of andere stressors op het platform.

• Bewaak het door de inrichting beheerde gebruik voor ingerichte doorvoer.

Machine Learning: prestatie-efficiëntie

Als u implementeert op online-eindpunten van Machine Learning:

• Volg de richtlijnen voor het automatisch schalen van een online-eindpunt. Doe dit 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. Test de prestaties van zowel het lagere aantal exemplaren als grotere SKU's versus het grotere aantal exemplaren en kleinere SKU's om een optimale configuratie te vinden.

Dit scenario implementeren

Als u de referentie-implementatie wilt implementeren en uitvoeren, volgt u de stappen in de end-to-end referentie-implementatie van de OpenAI-referentielijn.

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 stap

Verwante resources

• Een Well-Architected Framework-perspectief op AI-workloads in Azure
• Azure OpenAI
• Azure OpenAI-taalmodellen
• promptstroom in azure AI Foundry Portal
• Isolatie van beheerde virtuele netwerken in werkruimte
• Een privé-eindpunt configureren voor een Machine Learning-werkruimte
• Inhoud filteren