Delen via

Referentiearchitectuur voor Azure AI Foundry-chatbasislijn

Azure OpenAI Service
Azure AI-services
Azure App Service
Azure Monitor

Bedrijfschattoepassingen kunnen werknemers in staat stellen via gesprekken met AI-agents. Deze mogelijkheid is steeds krachtiger dankzij voortdurende ontwikkelingen in taalmodellen, zoals GPT-modellen van OpenAI en indelings-SDK's zoals Semantic Kernel. Deze chattoepassingen bestaan doorgaans uit de volgende onderdelen:

  • Een gebruikersinterface voor chatten die is geïntegreerd in een grotere bedrijfstoepassing. Het biedt gebruikers een gesprekservaring naast andere bedrijfsfuncties.

  • Gegevensopslagplaatsen die domeinspecifieke informatie bevatten die relevant is voor gebruikersquery's.

  • Taalmodellen die reden geven voor de domeinspecifieke gegevens om relevante antwoorden te produceren.

  • Een orchestrator of agent die toezicht houdt op de interacties tussen gegevensbronnen, taalmodellen en de eindgebruiker.

Dit artikel bevat een basisarchitectuur om u te helpen bij het bouwen en implementeren van bedrijfschattoepassingen met behulp van Azure AI Foundry en Azure OpenAI in Foundry-modellen. Deze architectuur maakt gebruik van één agent die wordt gehost in Azure AI Foundry Agent Service. De agent ontvangt gebruikersberichten en voert vervolgens query's uit op gegevensarchieven om grondinformatie voor het taalmodel op te halen.

De chatgebruikersinterface volgt de basislijn voor azure App Service-webtoepassingsrichtlijnen voor het implementeren van een beveiligde, zone-redundante en maximaal beschikbare webtoepassing in App Service. In deze architectuur communiceert App Service met de PaaS-oplossing (Platform as a Service) van Azure via integratie van virtuele netwerken via privé-eindpunten. In de architectuur van de chatgebruikersinterface communiceert App Service met de agent via een privé-eindpunt. Openbare toegang tot de Azure AI Foundry-portal en agents zijn uitgeschakeld.

Belangrijk

In dit artikel worden geen onderdelen of architectuurbeslissingen beschreven op basis van de architectuur van de App Service-webtoepassing volgens de basislijn. Lees dit artikel voor richtlijnen voor architectuur over het hosten van de webtoepassing die uw chatgebruikersinterface bevat.

Deze architectuur maakt gebruik van de standaardagentinstallatie van Foundry Agent Service om beveiliging, naleving en controle op bedrijfsniveau mogelijk te maken. In deze configuratie brengt u uw eigen netwerk mee voor netwerkisolatie en uw eigen Azure-resources om chat- en agentstatus op te slaan. Alle communicatie tussen toepassingsonderdelen en Azure-services vindt plaats via privé-eindpunten, waardoor gegevensverkeer binnen het virtuele netwerk van uw workload blijft. Uitgaand verkeer van de agents wordt strikt gerouteerd via Azure Firewall, waardoor uitgaand verkeer wordt afgedwongen.

Aanbeveling

De referentie-implementatie van de Foundry Agent-service toont een end-to-end-chat-implementatie op Azure. Het fungeert als basis voor het ontwikkelen van aangepaste oplossingen terwijl u naar productie gaat.

Architectuur

Diagram met een end-to-end-chatarchitectuur volgens de basislijn die gebruikmaakt van Azure AI Foundry.

Een Visio-bestand van deze architectuur downloaden.

Werkproces

  1. Een toepassingsgebruiker communiceert met een chatgebruikersinterface. De aanvragen worden doorgestuurd via Azure Application Gateway. Azure Web Application Firewall inspecteert deze aanvragen voordat deze worden doorgestuurd naar de back-end-App Service.

  2. Wanneer de webtoepassing een gebruikersquery of instructie ontvangt, wordt de speciaal gebouwde agent aangeroepen. De webtoepassing communiceert met de agent via de Azure AI Agent SDK. De webtoepassing roept de agent aan via een privé-eindpunt en verifieert azure AI Foundry met behulp van de beheerde identiteit.

  3. De agent verwerkt de aanvraag van de gebruiker op basis van de instructies in de systeemprompt. Om te voldoen aan de intentie van de gebruiker, gebruikt de agent een geconfigureerd taalmodel en verbonden hulpprogramma's en kennisarchieven.

  4. De agent maakt verbinding met het kennisarchief (Azure AI Search) in het privénetwerk via een privé-eindpunt.

  5. Aanvragen voor externe kennisarchieven of hulpprogramma's, zoals Wikipedia of Bing, gaan via Azure Firewall voor inspectie en afdwinging van uitgaand beleid.

  6. De agent maakt verbinding met het geconfigureerde taalmodel en geeft relevante context door.

  7. Voordat de agent het antwoord op de gebruikersinterface retourneert, blijft de aanvraag, het gegenereerde antwoord en een lijst met geraadpleegde kennisarchieven in een toegewezen geheugendatabase . Deze database onderhoudt de volledige gespreksgeschiedenis, waardoor contextbewuste interacties mogelijk zijn en gebruikers gesprekken met de agent kunnen hervatten zonder voorafgaande context te verliezen.

    De Azure AI Foundry-API's ondersteunen de ontwikkeling van gebruikerservaringen die meerdere gelijktijdige, context-geïsoleerde gesprekken beheren.

Onderdeel

Deze architectuur bouwt voort op de basisarchitectuur van de Azure AI Foundry-chat. Deze architectuur introduceert meer Azure-services om te voldoen aan bedrijfsvereisten voor betrouwbaarheid, beveiliging en operationele controle. Elk van de volgende onderdelen speelt een specifieke rol in een chatoplossing voor een productiebedrijf:

  • Foundry Agent Service biedt de indelingslaag voor chatinteracties. Het host en beheert agents die de volgende taken uitvoeren:

    • Gebruikersaanvragen verwerken
    • Oproepen naar hulpprogramma's en andere agents coördineren
    • Inhoudsveiligheid afdwingen
    • Integreren met bedrijfsidentiteit, netwerken en waarneembaarheid

    De standaardagentinstallatie zorgt voor netwerkisolatie en biedt controle over gegevensopslag. U levert toegewezen Azure-resources voor agentstatus, chatgeschiedenis en bestandsopslag, die de Foundry Agent-service exclusief beheert. Andere toepassingsonderdelen in de workload mogen deze vereiste resources niet gebruiken.

    • Azure Cosmos DB for NoSQL fungeert als host voor de geheugendatabase van deze workload, genaamd enterprise_memory, binnen uw abonnement. In deze database wordt de operationele status van de agent opgeslagen, inclusief chatthreads en agentdefinities. Dit ontwerp zorgt ervoor dat de chatgeschiedenis en agentconfiguratie geïsoleerd, controleerbaar en beheerd worden volgens de vereisten voor gegevensbeheer. Foundry Agent Service beheert de database, de verzamelingen en de bijbehorende gegevens.

    • In een toegewezen Azure Storage-account worden bestanden opgeslagen die tijdens chatsessies zijn geüpload. Het hosten van dit account in uw abonnement biedt gedetailleerde toegangsbeheer, controlemogelijkheden en naleving van beleid voor gegevenslocatie of retentie. Foundry Agent Service beheert de containers en de levenscyclus van gegevens binnen deze containers.

    • In een toegewezen AI Search-exemplaar wordt een doorzoekbare, gesegmenteerde index van geüploade bestanden opgeslagen uit gesprekken met de agent. Ook worden statische bestanden opgeslagen die worden toegevoegd als kennisbronnen wanneer de agent wordt gemaakt. Foundry Agent Service beheert de index, het schema en de gegevens en maakt gebruik van een eigen segmenteringsstrategie en querylogica.

  • Application Gateway fungeert als het beveiligde, schaalbare toegangspunt voor alle HTTP- en HTTPS-verkeer naar de chatgebruikersinterface. Het biedt tls-beëindiging (Transport Layer Security) en routering op basis van paden. Het distribueert ook aanvragen over beschikbaarheidszones, die ondersteuning bieden voor hoge beschikbaarheid en prestaties voor de webtoepassingslaag. De back-end is de App Service die als host fungeert voor de toepassingscode.

    • Azure Web Application Firewall kan worden geïntegreerd met Application Gateway om de chatgebruikersinterface te beschermen tegen veelvoorkomende beveiligingsproblemen en aanvallen op internet. Het inspecteert en filtert HTTP-aanvragen, die een beveiligingslaag biedt voor openbare toepassingen.

    • Azure Key Vault slaat de TLS-certificaten die application gateway nodig heeft veilig op en beheert deze. Gecentraliseerd certificaatbeheer in Key Vault ondersteunt geautomatiseerde rotatie, controle en naleving van de beveiligingsstandaarden van de organisatie. Voor deze architectuur zijn geen opgeslagen sleutels of andere geheimen vereist.

  • Azure Virtual Network biedt netwerkisolatie voor alle onderdelen. Wanneer u resources in een particulier virtueel netwerk plaatst, beheert u het verkeer oost-west en noord-zuid, dwingt u segmentering af, houdt u verkeer privé en schakelt u inspectie van inkomend en uitgaand verkeer in. Met deze installatie kunt u voldoen aan de beveiligings- en nalevingsvereisten.

  • Azure Private Link verbindt alle PaaS-services, zoals Azure Cosmos DB, Storage, AI Search en Foundry Agent Service, met het virtuele netwerk via privé-eindpunten. Deze aanpak zorgt ervoor dat al het gegevensverkeer zich op de Azure-backbone bevindt, waardoor blootstelling aan het openbare internet wordt geëlimineerd en het kwetsbaarheid voor aanvallen wordt verminderd.

  • Azure Firewall inspecteert en beheert al het uitgaande (uitgaande) verkeer van het virtuele netwerk. Hiermee worden FQDN-regels (Fully Qualified Domain Name) afgedwongen, waardoor alleen goedgekeurde bestemmingen bereikbaar zijn. Deze configuratie helpt exfiltratie van gegevens te voorkomen en te voldoen aan de vereisten voor netwerkbeveiliging.

  • Azure DNS biedt privé-DNS-zones (Domain Name System) die zijn gekoppeld aan het virtuele netwerk. Deze functie maakt naamomzetting mogelijk voor privé-eindpunten, waardoor alle service-naar-service-communicatie privé-IP-adressen gebruikt en binnen de netwerkgrens blijft.

  • Opslag fungeert als host voor de code van de webtoepassing als een ZIP-bestand voor implementatie in App Service. Deze methode ondersteunt beveiligde, geautomatiseerde implementatiewerkstromen en scheidt toepassingsartefacten van rekenresources.

Alternatieven

Deze architectuur bevat meerdere onderdelen die u kunt vervangen door andere Azure-services of -benaderingen, afhankelijk van de functionele en niet-functionele vereisten van uw workload. Houd rekening met de volgende alternatieven en compromissen.

Chatindeling

Huidige aanpak: Deze architectuur maakt gebruik van Foundry Agent Service voor het organiseren van chatstromen, waaronder het ophalen van grondgegevens uit kennisarchieven en het aanroepen van Azure OpenAI-modellen. Foundry Agent Service biedt codeloze, niet-deterministische indeling. Het verwerkt chataanvragen, threadbeheer, aanroepen van hulpprogramma's, veiligheid van inhoud en integratie met identiteit, netwerken en waarneembaarheid. Het biedt een systeemeigen oplossing voor geheugendatabases.

Alternatieve aanpak: U kunt de indelingslaag zelf hosten met behulp van frameworks zoals Semantic Kernel of LangChain. Gebruik deze frameworks om deterministische, codegestuurde chatstromen en aangepaste indelingslogica te implementeren.

Overweeg dit alternatief als uw workload de volgende mogelijkheden vereist:

  • Fijnmazige, deterministische controle over de indelingsreeks, het aanroepen van hulpprogramma's of prompt-engineering

  • Integratie met aangepaste bedrijfslogica of externe systemen die Foundry Agent Service niet systeemeigen ondersteunt

  • Geavanceerde routering van clientaanvragen voor experimenten of veilige implementatieprocedures

  • Een aangepaste oplossing voor geheugendatabases die verschilt van de systeemeigen Foundry Agent Service-oplossing

Zelf-hostende indeling verhoogt de operationele complexiteit en vereist dat u rekenkracht, schaalaanpassing en beveiliging beheert.

Onderdelen van de toepassingslaag

Huidige aanpak: De front-endwebsite van de chatgebruikersinterface wordt gehost op de functie Web Apps van App Service, die een beheerd, schaalbaar platform biedt voor webtoepassingen. Web Apps kan systeemeigen worden geïntegreerd met Azure-netwerk- en beveiligingsfuncties.

Alternatieve aanpak: U kunt andere door Azure beheerde rekenplatforms, zoals Azure Container Apps of Azure Kubernetes Service (AKS), gebruiken om de toepassingslaag te hosten.

Overweeg dit alternatief als uw workload voldoet aan een van de volgende voorwaarden:

  • Een ander rekenplatform biedt betere ondersteuning voor bepaalde gebruiksvoorbeelden en het toewijzen van services op dat platform kan de kostenefficiëntie verbeteren en bewerkingen vereenvoudigen

  • Uw toepassing vereist geavanceerdere schaalaanpassing, indeling of aangepaste netwerken

App Service blijft de voorkeursoptie voor de eenvoud bij het hosten van webtoepassingen en hun API's.

Grondgegevensopslag (kennis)

Huidige aanpak: Deze architectuur maakt gebruik van AI Search als het primaire gegevensarchief voor kennis van de grond. Het maakt gebruik van ai Search Vector Search en semantische classificatiemogelijkheden.

Alternatieve aanpak: U kunt andere gegevensplatforms gebruiken voor grondkennis, zoals Azure Cosmos DB, Azure SQL Database of andere OLTP-gegevensarchieven (Online Transaction Processing). Uw gegevensplatform is afhankelijk van uw bestaande gegevensdomein, vereisten voor het vernieuwen van gegevens en queryvereisten.

Overweeg dit alternatief als uw workload voldoet aan een van de volgende voorwaarden:

  • U beheert al uw grondkennis in een bestaande transactionele of operationele database

  • U hebt ondersteuning voor meerdere modellen of SDK's nodig die niet beschikbaar zijn in AI Search

  • U moet integreren met gespecialiseerde gegevensbronnen of verouderde systemen

Vectorzoekopdrachten zijn gebruikelijk voor het ophalen van uitgebreide generatie, maar niet altijd vereist. Zie Een Azure-service kiezen voor vectorzoekopdrachten voor meer informatie. Voordat u een gegevensarchief kiest, evalueert u de gegevenstoegangspatronen, latentie en schaalbaarheidsbehoeften van uw workload.

Vooraf gedefinieerde agent of dynamisch gemaakte agent

Huidige aanpak: De referentie-implementatie maakt gebruik van een statisch gedefinieerde agent die wordt geïmplementeerd als een microservice in Azure AI Foundry. De logica en gegevensbronnen van de agent worden tijdens de implementatie geconfigureerd en blijven ongewijzigd tot de volgende toepassingsrelease. Deze aanpak werkt goed wanneer agentgedrag en gegevensbronnen stabiel en beheerd zijn via DevOps-processen.

Alternatieve aanpak: U kunt tijdens runtime agents dynamisch maken of wijzigen met behulp van de Azure AI Agent SDK. Met deze methode kan de toepassing agents op aanvraag instantiëren, systeemprompts aanpassen of verbindingen opnieuw configureren op basis van gebruikerscontext of bedrijfslogica.

Overweeg dynamische agents als uw workload de volgende mogelijkheden vereist:

  • Gepersonaliseerde agentgedrag of gegevensbronnen voor elke gebruiker of sessie

  • Frequente of programmatische wijzigingen in agentconfiguratie

  • Tijdelijke, contextspecifieke agentondersteuning voor geavanceerde gebruikerservaringen

Dynamisch agentbeheer verhoogt de flexibiliteit, maar introduceert ook de last van levenscyclusbeheer. Zorg ervoor dat u over de juiste besturingselementen beschikt voor het maken, wijzigen en opschonen van agents.

Kies de agentbenadering die overeenkomt met de gebruikerservaringsvereisten van uw workload.

Overwegingen

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

Pas deze architectuur en de AI-workloads toe op azure-ontwerprichtlijnen tijdens de ontwerpfase van uw workload.

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 die redundantie bieden wanneer u er twee of meer exemplaren in implementeert. Als de ene zone downtime ondervindt, blijven andere in de regio mogelijk niet beïnvloed. De architectuur distribueert ook exemplaren en configuraties van Azure-services in beschikbaarheidszones. Zie Maximaal beschikbare zone-redundante webtoepassing basislijnvoor meer informatie.

In deze sectie wordt de betrouwbaarheid voor onderdelen behandeld die niet worden behandeld in de App Service-basislijnarchitectuur, met name Azure AI Foundry en AI Search.

Zoneredundantie in de indelingslaag

Bedrijfsimplementaties vereisen meestal zonegebonden redundantie om het risico op serviceonderbreking van storingen op zoneniveau te minimaliseren. In Azure betekent zonegebonden redundantie het gebruik van resources die ondersteuning bieden voor beschikbaarheidszones en het implementeren van ten minste drie exemplaren, of het inschakelen van redundantie op platformniveau waarbij direct exemplaarbeheer niet beschikbaar is.

In deze architectuur host Azure AI Foundry de functie Foundry Agent Service. De betrouwbaarheid van de agent is afhankelijk van de beschikbaarheid van de Afhankelijkheden van de Foundry Agent-service, die Azure Cosmos DB, Storage en AI Search zijn. Foundry Agent Service beheert de gegevens binnen deze services, maar u configureert hun betrouwbaarheid in uw abonnement.

Volg deze aanbevelingen om zonegebonden redundantie te bereiken voor de indelingslaag:

Als uw agent is geïntegreerd met andere workloadspecifieke afhankelijkheden, zoals aangepaste hulpprogrammaverbindingen of externe kennisarchieven, moet u ervoor zorgen dat deze afhankelijkheden voldoen aan uw beschikbaarheids- en redundantievereisten. Elke afhankelijkheid met één zone of niet-redundant kan de algehele betrouwbaarheid van de indelingslaag ondermijnen.

De AI Foundry-portal, de BIJBEHORENDE API's voor het gegevensvlak en de foundry-agentservice bieden geen directe besturingselementen voor zoneredundantie.

Betrouwbaarheid in Azure AI Foundry-modelhosting

Azure AI Foundry biedt hosting van modellen als een dienst (MaaS) met verschillende implementatieopties. Deze opties ondersteunen voornamelijk quota- en doorvoerbeheer, in plaats van traditionele hoge beschikbaarheid binnen een regio. Standaardmodelimplementaties werken in één regio en bieden geen ondersteuning voor beschikbaarheidszones. Als u beschikbaarheid met meerdere datacenters wilt bereiken, moet u een implementatie van een globaal model of een gegevenszone gebruiken.

Implementeer voor bedrijfschatscenario's zowel een ingerichte gegevenszone als een standaardmodel voor de gegevenszone . Configureer overloop om overtollig verkeer of fouten af te handelen. Als uw workload geen lage latentie of strikte geografische gegevenslocatie en -verwerking vereist, gebruikt u globale implementaties voor maximale tolerantie.

Azure AI Foundry biedt geen ondersteuning voor geavanceerde mechanismen voor taakverdeling of failover, zoals round robin-routering of circuitonderbreking, voor modelimplementaties. Als u gedetailleerde redundantie en failoverbeheer binnen een regio nodig hebt, host u de logica voor modeltoegang buiten de beheerde service. U kunt bijvoorbeeld een aangepaste gateway bouwen met behulp van Azure API Management. Met deze aanpak kunt u aangepaste routerings-, statuscontroles en failoverstrategieën implementeren. Maar het verhoogt ook de operationele complexiteit en verschuift de verantwoordelijkheid voor de betrouwbaarheid van dat onderdeel naar uw team.

U kunt gatewaymodellen ook beschikbaar maken als aangepaste API-hulpprogramma's of kennisarchieven voor uw agent. Zie Een gateway gebruiken voor meerdere Azure OpenAI-implementaties of -exemplaren voor meer informatie.

Betrouwbaarheid in AI Search voor bedrijfskennis

AI Search implementeren met behulp van de prijscategorie Standard of hoger in een regio die beschikbaarheidszones ondersteunt. Configureer ten minste drie replica's om ervoor te zorgen dat de service exemplaren over afzonderlijke beschikbaarheidszones distribueert. Deze configuratie biedt tolerantie voor fouten op zoneniveau en biedt ondersteuning voor hoge beschikbaarheid voor zoekbewerkingen.

Gebruik de volgende methoden om het optimale aantal replica's en partities voor uw workload te bepalen:

  • AI Search bewaken met behulp van ingebouwde metrische gegevens en logboeken. Querylatentie, bandbreedtebeperking en resourcegebruik bijhouden.

  • Gebruik bewakingsgegevens en logboeken en prestatieanalyse om het juiste aantal replica's te bepalen. Deze aanpak helpt u bij het voorkomen van beperking van hoog queryvolume, onvoldoende partities of indexbeperkingen.

  • Zorg ervoor dat de betrouwbaarheid wordt geïndexeerd door onderbrekingen van periodieke indexerings- of indexeringsfouten te voorkomen. Overweeg om te indexeren in een offline-index en om te wisselen van uw live-index naar uw herbouwde index nadat u de gegevensintegriteit hebt gevalideerd.

Betrouwbaarheid in Azure Firewall

Azure Firewall is een kritiek controlepunt voor uitgaand verkeer in deze architectuur, maar vertegenwoordigt één storingspunt voor al het uitgaande verkeer. Als u dit risico wilt beperken, implementeert u Azure Firewall in alle beschikbaarheidszones in uw regio. Deze configuratie helpt uitgaande connectiviteit te behouden als een zone niet meer beschikbaar is.

Als uw workload een groot aantal gelijktijdige uitgaande verbindingen vereist, configureert u Azure Firewall met meerdere openbare IP-adressen. Met deze methode worden SNAT-verbindingen (Source Network Address Translation) verdeeld over meerdere IP-adresvoorvoegsels, waardoor het risico op uitputting van de SNAT-poort wordt verminderd. SNAT-uitputting kan leiden tot onregelmatig of totaal verlies van uitgaande connectiviteit voor agents en andere workloadonderdelen, wat kan leiden tot downtime van functies of verminderde prestaties.

Controleer het SNAT-poortgebruik en de firewallstatus. Als u verbindingsfouten of doorvoerproblemen ziet, bekijkt u metrische gegevens en logboeken van de firewall om SNAT-uitputting of andere knelpunten te identificeren en op te lossen.

De afhankelijkheden van de Foundry Agent-service isoleren van vergelijkbare workloadonderdelen

Om de betrouwbaarheid te maximaliseren en de straalstraal van fouten te minimaliseren, moet u de Foundry Agent Service-afhankelijkheden strikt isoleren van andere workloadonderdelen die gebruikmaken van dezelfde Azure-services. Deel met name geen AI Search-, Azure Cosmos DB- of Storage-resources tussen de agentservice en andere toepassingsonderdelen. Richt in plaats daarvan toegewezen exemplaren in voor de vereiste afhankelijkheden van de agentservice.

Deze scheiding biedt twee belangrijke voordelen:

  • Het bevat fouten of prestatievermindering tot één workloadsegment, waardoor trapsgewijze gevolgen voor niet-gerelateerde toepassingsfuncties worden voorkomen.

  • Hiermee kunt u gerichte operationele processen toepassen, zoals back-up, herstel en failover. Deze processen zijn afgestemd op de specifieke beschikbaarheids- en herstelvereisten van de workloadstroom die gebruikmaakt van deze resources.

Als uw chat-UI-toepassing bijvoorbeeld transactionele status moet opslaan in Azure Cosmos DB, richt u hiervoor een afzonderlijk Azure Cosmos DB-account en -database in, in plaats van het account of de database te hergebruiken die de Foundry Agent Service beheert. Zelfs als kosten of operationele eenvoud het delen van resources motiveren, is het risico van een betrouwbaarheidsgebeurtenis die van invloed is op niet-gerelateerde workloadfuncties op tegen de mogelijke besparingen in de meeste bedrijfsscenario's.

Belangrijk

Als u werkbelastingspecifieke gegevens om kosten of operationele redenen koppelt aan de afhankelijkheden van de agent, communiceert u nooit rechtstreeks met de door het systeem beheerde gegevens, zoals verzamelingen, containers of indexen, die de Foundry Agent-service maakt. Deze interne implementatiedetails zijn niet-gedocumenteerd en kunnen zonder kennisgeving worden gewijzigd. Directe toegang kan de agentservice verbreken of leiden tot gegevensverlies. Gebruik altijd de gegevensvlak-API's van Foundry Agent Service voor gegevensbewerking en behandel de onderliggende gegevens als ondoorzichtig en alleen-bewaken.

Ontwerp voor meerdere regio's

Deze architectuur maakt gebruik van beschikbaarheidszones voor hoge beschikbaarheid binnen één Azure-regio. Het is geen oplossing voor meerdere regio's. Het ontbreekt aan de volgende essentiële elementen die vereist zijn voor regionale tolerantie en herstel na noodgevallen (DR):

  • Wereldwijde routering van inkomend verkeer en verkeer
  • DNS-beheer voor failover
  • Strategieën voor gegevensreplicatie of isolatie tussen regio's
  • Een actief-actief,actief-passief- of actief-koude aanduiding
  • Regionale failover- en failbackprocessen om te voldoen aan de beoogde hersteltijd (RPO's) en beoogde herstelpunten
  • Overweging van beschikbaarheid van regio's voor ontwikkelaarservaringen, waaronder de Azure AI Foundry-portal en API's voor gegevensvlak

Als uw workload bedrijfscontinuïteit vereist als er een regionale storing optreedt, moet u extra onderdelen en operationele processen ontwerpen en implementeren buiten deze architectuur. In het bijzonder moet u taakverdeling en failover op elke architectuurlaag aanpakken, met inbegrip van de volgende gebieden:

  • Grondgegevens (kennisarchieven)
  • Modelhosting- en deductie-eindpunten
  • De indelings- of agentlaag
  • Gebruikersgericht UI-verkeer en DNS-toegangspunten

U moet er ook voor zorgen dat waarneembaarheid, bewaking en veiligheidsmaatregelen voor inhoud operationeel en consistent blijven in alle regio's.

Deze basislijnarchitectuur heeft geen mogelijkheden voor meerdere regio's, dus regionale storingen leiden waarschijnlijk tot verlies van service binnen uw workload.

Herstel na een ramp

Chatarchitecturen bevatten stateful onderdelen, dus dr-planning is essentieel. Voor deze workloads is doorgaans een geheugenopslag vereist voor actieve of onderbroken chatsessies. Ze vereisen ook opslag voor aanvullende gegevens, zoals documenten of afbeeldingen, die zijn toegevoegd aan chatthreads. De indelingslaag van de agent kan ook de status behouden die specifiek is voor gespreksstromen. In deze architectuur maakt Foundry Agent Service gebruik van Azure Cosmos DB, Storage en AI Search om de operationele en transactionele status te behouden. De levenscyclus en koppeling van deze status tussen onderdelen bepalen uw DR-strategie en herstelbewerkingen.

Voor Foundry Agent Service moet u ervoor zorgen dat u alle afhankelijkheden naar een consistent tijdstip kunt herstellen. Deze aanpak helpt bij het handhaven van transactionele integriteit in de drie externe afhankelijkheden.

De volgende aanbevelingen zijn bedoeld voor herstel na noodgevallen voor elke service:

  • Azure Cosmos DB: Schakel continue back-up in voor de enterprise_memory database. Deze installatie biedt herstel naar een bepaald tijdstip (PITR) met een RPO van zeven dagen, waaronder agentdefinities en chatthreads. Test uw herstelproces regelmatig om te bevestigen dat het voldoet aan uw RTO en dat de herstelde gegevens beschikbaar blijven voor de agentservice. Herstel altijd naar hetzelfde account en dezelfde database.

  • AI Search: AI Search beschikt niet over ingebouwde herstelmogelijkheden en biedt geen ondersteuning voor directe indexmanipulatie. Als er gegevensverlies of beschadigingen optreden, moet u contact opnemen met Microsoft-ondersteuning voor hulp bij het herstellen van indexen. Deze beperking kan aanzienlijk van invloed zijn op uw RTO. Als uw chatgebruikersinterface geen ondersteuning biedt voor het uploaden van bestanden en u geen agents hebt die statische bestanden gebruiken als kennis, hebt u mogelijk geen NOOD-plan voor AI Search nodig.

    Behoud een afzonderlijke, regelmatig bijgewerkte bron van waarheid voor uw zakelijke grondkennis. Deze procedure zorgt ervoor dat u indexen zo nodig opnieuw kunt opbouwen.

  • Opslag: Als u een geografisch redundant opslagaccount hebt, gebruikt u door de klant beheerde failover voor blobcontainers die Foundry Agent Service gebruikt. Met deze installatie kunt u failover initiëren tijdens een regionale storing. Als u alleen zone-redundante opslag gebruikt, neemt u contact op met Microsoft Ondersteuning om gegevens te herstellen. Dit proces kan uw RTO uitbreiden. Net als bij AI Search hebt u, als uw chatgebruikersinterface geen ondersteuning biedt voor het uploaden van bestanden en u geen agents hebt die statische bestanden als kennis gebruiken, hebt u mogelijk geen DR-plan nodig voor blobcontainers.

  • Transactionele consistentie: Als de statusopslag in uw workload verwijst naar Azure AI-agent-id's, zoals thread-id's of agent-id's, coördineert u het herstel in alle relevante gegevensarchieven. Als u alleen een subset van afhankelijkheden herstelt, kan dit leiden tot zwevende of inconsistente gegevens. Ontwerp uw DR-processen om referentiële integriteit tussen uw workload en de status van de agentservice te behouden.

  • Agentdefinities en -configuratie: Agents definiëren als code. Sla agentdefinities, verbindingen, systeemprompts en parameters op in broncodebeheer. Met deze procedure kunt u agents opnieuw implementeren vanuit een bekende goede configuratie als u de indelingslaag kwijtraakt. Vermijd het aanbrengen van niet-bijgehouden wijzigingen in agentconfiguratie via de AI Foundry-portal of gegevensvlak-API's. Deze aanpak zorgt ervoor dat uw geïmplementeerde agents reproduceerbaar blijven.

Voordat u naar productie gaat, bouwt u een herstelrunbook waarmee fouten in zowel de status van de toepassing als de status agent worden opgelost.

Veiligheid

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 beveiligingsbasis uit die is ingesteld in de basisarchitectuur voor Chat-naslaginformatie over Azure AI Foundry. Het belangrijkste verschil is het toevoegen van een netwerkbeveiligingsperimeter naast de identiteitsperimeter uit de basisarchitectuur. Vanuit het oogpunt van een netwerk is Application Gateway de enige internetresource. Hiermee wordt de gebruikersinterfacetoepassing voor chat beschikbaar voor gebruikers. Vanuit identiteitsperspectief moet de chatgebruikersinterface aanvragen verifiëren en autoriseren. Gebruik indien mogelijk beheerde identiteiten om toepassingen te verifiëren bij Azure-services.

In deze sectie worden netwerk- en beveiligingsoverwegingen beschreven voor sleutelrotatie en het afstemmen van het Azure OpenAI-model.

Identiteits- en toegangsbeheer

Deze architectuur maakt voornamelijk gebruik van door het systeem toegewezen beheerde identiteiten voor service-naar-service-verificatie. U kunt ook door de gebruiker toegewezen beheerde identiteiten gebruiken. In beide gevallen past u de volgende principes toe:

  • Identiteiten isoleren per resource en functie. Richt afzonderlijke beheerde identiteiten in voor de volgende onderdelen:

    • Het Azure AI Foundry-account
    • Elk Azure AI Foundry-project
    • De webtoepassing
    • Aangepaste orchestrator- of integratiecode

  • Wijs een identiteit alleen toe aan een Azure-resource als die resource moet worden geverifieerd als een client aan een andere Azure-service.

  • Gebruik identiteitstypen die geschikt zijn voor doeleinden. Gebruik waar mogelijk workloadidentiteiten voor toepassingen en automatisering en gebruik agentidentiteiten voor AI-agents.

Toegang van werknemers in azure AI Foundry Portal

Wanneer u werknemers onboardt voor Azure AI Foundry-projecten, wijst u de minimale machtigingen toe die zijn vereist voor hun rol. Gebruik Microsoft Entra ID-groepen en op rollen gebaseerd toegangsbeheer (RBAC) om scheiding van taken af te dwingen. Maak bijvoorbeeld onderscheid tussen agentontwikkelaars en gegevenswetenschappers die taken verfijnen. Houd echter rekening met de beperkingen en risico's.

De Azure AI Foundry-portal voert veel acties uit met behulp van de identiteit van de service in plaats van de identiteit van de werknemer. Hierdoor hebben werknemers met beperkte RBAC-rollen mogelijk inzicht in gevoelige gegevens, zoals chatthreads, agentdefinities en configuratie. Dit ontwerp van de AI Foundry-portal kan per ongeluk uw gewenste toegangsbeperkingen omzeilen en meer informatie beschikbaar maken dan bedoeld is.

Als u het risico van onbevoegde toegang wilt beperken, beperkt u het gebruik van de portal in productieomgevingen tot werknemers die een duidelijke operationele behoefte hebben. Voor de meeste werknemers schakelt u de toegang tot de Azure AI Foundry-portal uit of blokkeert u deze in productie. Gebruik in plaats daarvan geautomatiseerde implementatiepijplijnen en infrastructuur als code (IaC) om agent- en projectconfiguratie te beheren.

Behandelt het maken van nieuwe projecten in een Azure AI Foundry-account als een bevoorrechte actie. Projecten die zijn gemaakt via de portal nemen niet automatisch uw bestaande netwerkbeveiligingsbeheer over, zoals privé-eindpunten of netwerkbeveiligingsgroepen (NSG's). En nieuwe agents in deze projecten omzeilen uw beoogde beveiligingsperimeter. Dwing het maken van projecten uitsluitend af via uw gecontroleerde, controleerbare IaC-processen.

Azure AI Foundry-projectroltoewijzingen en -verbindingen

Als u Foundry Agent Service in de standaardmodus wilt gebruiken, moet het project beheerdersmachtigingen hebben voor de Afhankelijkheden van de Foundry Agent-service. In het bijzonder moet de beheerde identiteit van het project verhoogde roltoewijzingen hebben voor het opslagaccount, AI Search en het Azure Cosmos DB-account. Deze machtigingen bieden bijna volledige toegang tot deze resources, waaronder de mogelijkheid om gegevens te lezen, schrijven, wijzigen of verwijderen. Als u de toegang tot minimale bevoegdheden wilt handhaven, moet u uw workloadresources isoleren van de afhankelijkheden van de Foundry Agent-service.

Alle agents binnen één AI Foundry-project delen dezelfde beheerde identiteit. Als uw workload gebruikmaakt van meerdere agents die toegang tot verschillende sets resources vereisen, moet u voor elk afzonderlijk toegangspatroon voor agents een afzonderlijk Azure AI Foundry-project maken. Met deze scheiding kunt u alleen de minimaal vereiste machtigingen toewijzen aan de beheerde identiteit van elk project, waardoor het risico op overmatige of onbedoelde toegang wordt beperkt.

Wanneer u verbindingen tot stand brengt met externe resources vanuit Azure AI Foundry, gebruikt u verificatie op basis van Microsoft Entra ID, indien beschikbaar. Deze aanpak elimineert de noodzaak om vooraf gedeelde geheimen te onderhouden. Beperk elke verbinding zodat alleen het eigendomsproject dit kan gebruiken. Als voor meerdere projecten toegang tot dezelfde resource is vereist, maakt u een afzonderlijke verbinding in elk project in plaats van één verbinding tussen projecten te delen. Deze procedure dwingt strikte toegangsgrenzen af en voorkomt dat toekomstige projecten de toegang overnemen die ze niet nodig hebben.

Vermijd het maken van verbindingen op azure AI Foundry-accountniveau. Deze verbindingen zijn van toepassing op alle huidige en toekomstige projecten in het account. Ze kunnen per ongeluk brede toegang verlenen tot resources, de beginselen van minimale bevoegdheden schenden en het risico verhogen dat onbevoegde gegevens worden blootgesteld. Geef alleen de voorkeur aan verbindingen op projectniveau.

Netwerken

Naast toegang op basis van identiteit vereist deze architectuur netwerkgeheim.

Het netwerkontwerp omvat de volgende beveiligingsmaatregelen:

  • Eén beveiligd toegangspunt voor alle chatgebruikersinterfaceverkeer, waardoor het kwetsbaarheid voor aanvallen wordt geminimaliseerd

  • Gefilterd inkomend en uitgaand netwerkverkeer met behulp van een combinatie van NSG's, een webtoepassingsfirewall, door de gebruiker gedefinieerde routes (UDR's) en Azure Firewall-regels

  • End-to-end-versleuteling van gegevens die onderweg zijn met behulp van TLS

  • Netwerkprivacy met behulp van Private Link voor alle Azure PaaS-serviceverbindingen

  • Logische segmentatie en isolatie van netwerkresources, met toegewezen subnetten voor elke hoofdonderdeelgroepering ter ondersteuning van gedetailleerd beveiligingsbeleid

Netwerkstromen

Diagram met twee netwerkstromen van de architectuur van de App Service-webtoepassing basislijn en de netwerkstroom Foundry Agent Service.

De architectuur van de App Service-webtoepassing basislijn bevat een overzicht van de binnenkomende stroom van de gebruiker naar de chatgebruikersinterface en de stroom van App Service naar Azure PaaS-services. Deze sectie is gericht op agentinteracties.

Wanneer de chatgebruikersinterface communiceert met de agent die is geïmplementeerd in Azure AI Foundry, vinden de volgende netwerkstromen plaats:

  1. De door App Service gehoste chatinterface initieert HTTPS-aanvragen via een privé-eindpunt naar het Azure AI Foundry-gegevensvlak-API-eindpunt.

  2. Wanneer de agent toegang heeft tot Azure PaaS-services, zoals serviceafhankelijkheden, aangepaste kennisarchieven of aangepaste hulpprogramma's, verzendt deze HTTPS-aanvragen van het gedelegeerde subnet naar de privé-eindpunten van deze services.

  3. Wanneer de agent toegang heeft tot resources buiten het virtuele netwerk, inclusief op internet gebaseerde API's of externe services, wordt deze HTTPS-aanvragen geforceerd gerouteerd vanuit het gedelegeerde subnet via Azure Firewall.

Privé-eindpunten fungeren als een kritiek beveiligingsbeheer in deze architectuur door beveiliging op basis van identiteit aan te vullen.

Inkomend verkeer naar Azure AI Foundry

Met deze architectuur wordt openbare toegang tot het gegevensvlak Azure AI Foundry uitgeschakeld door alleen verkeer toe te staan via een privékoppeling voor Azure AI Foundry. U hebt toegang tot veel van de Azure AI Foundry-portal via de portalwebsite, maar voor alle functionaliteit op projectniveau is netwerktoegang vereist. De portal is afhankelijk van de gegevensvlak-API's van uw AI Foundry-account, die alleen bereikbaar zijn via privé-eindpunten. Hierdoor moeten ontwikkelaars en gegevenswetenschappers toegang krijgen tot de portal via een jumpbox, een virtueel peernetwerk of een ExpressRoute- of site-naar-site-VPN-verbinding.

Alle programmatische interacties met het gegevensvlak van de agent, zoals van de webtoepassing of van externe indelingscode bij het aanroepen van modeldeductie, moeten deze privé-eindpunten ook gebruiken. Privé-eindpunten worden gedefinieerd op accountniveau, niet op projectniveau. Daarom delen alle projecten binnen het account dezelfde set eindpunten. U kunt geen netwerktoegang segmenteren op projectniveau en alle projecten delen dezelfde netwerkblootstelling.

Ter ondersteuning van deze configuratie stelt u DNS in voor de volgende Azure AI Foundry FQDN API-eindpunten:

  • privatelink.services.ai.azure.com
  • privatelink.openai.azure.com
  • privatelink.cognitiveservices.azure.com

In het volgende diagram ziet u hoe een AI-ontwikkelaar via Azure Bastion verbinding maakt met een jumpbox van een virtuele machine (VM). Vanuit die jumpbox heeft de auteur toegang tot het project in de Azure AI Foundry-portal via een privé-eindpunt in hetzelfde netwerk.

Een diagram dat laat zien hoe een gebruiker verbinding maakt met een jumpbox-VM via Azure Bastion.

Verkeer beheren vanuit het subnet van de Azure AI Foundry-agent

Met deze architectuur wordt al het uitgaande (uitgaande) netwerkverkeer van de Foundry Agent-service gerouteerd via een gedelegeerd subnet binnen uw virtuele netwerk. Dit subnet fungeert als het enige uitgangspunt voor de vereiste drie serviceafhankelijkheden van de agent en eventuele externe kennisbronnen of hulpprogrammaverbindingen die de agent gebruikt. Dit ontwerp helpt bij het verminderen van gegevensexfiltratiepogingen vanuit de indelingslogica.

Door dit uitgaand pad af te dwingen, krijgt u volledige controle over uitgaand verkeer. U kunt gedetailleerde NSG-regels, aangepaste routering en DNS-beheer toepassen op alle agentverkeer dat de service verlaat.

De agentservice maakt gebruik van de DNS-configuratie van het virtuele netwerk om privé-eindpuntrecords en vereiste externe FQDN's op te lossen. Deze installatie zorgt ervoor dat de aanvragen van de agent DNS-logboeken genereren, die ondersteuning bieden voor controle en probleemoplossing.

De NSG die is gekoppeld aan het uitgaande subnet van de agent blokkeert al het binnenkomende verkeer, omdat er geen legitiem inkomend verkeer moet plaatsvinden. Uitgaande NSG-regels staan alleen toegang toe tot subnetten van privé-eindpunten binnen het virtuele netwerk en tcp-poort (Transmission Control Protocol) 443 voor internetverkeer. De NSG weigert al het andere verkeer.

Om internetverkeer verder te beperken, past deze architectuur een UDR toe op het subnet, waarmee al het HTTPS-verkeer via Azure Firewall wordt omgeleid. De firewall bepaalt welke FQDN's de agent kan bereiken via HTTPS-verbindingen. Als de agent bijvoorbeeld alleen toegang nodig heeft tot grounding met openbare Bing-API's, configureert u Azure Firewall om verkeer naar poort 443 vanaf dit subnet toe te api.bing.microsoft.com staan. Alle andere uitgaande bestemmingen worden geweigerd.

Segmentatie en beveiliging van virtuele netwerken

Deze architectuur segmenteert het virtuele netwerk door elke hoofdonderdeelgroep toe te wijzen aan een eigen subnet. Elk subnet heeft een toegewezen NSG die het binnenkomende en uitgaande verkeer beperkt tot alleen wat het onderdeel nodig heeft.

De volgende tabel bevat een overzicht van de NSG- en firewallconfiguratie voor elk subnet.

Gebruiks- of subnetnaam Inkomend verkeer (NSG) Uitgaand verkeer (NSG) UDR naar firewall Regels voor uitgaand verkeer van firewall
Privé-eindpunten
snet-privateEndpoints		 Virtueel netwerk Geen verkeer toegestaan Ja Geen verkeer toegestaan
Application Gateway
snet-appGateway		 IP-adressen van gebruikersinterface voor chatgebruikersinterface, zoals het openbare internet, en vereiste bronnen voor de service Subnet van privé-eindpunt en vereiste items voor de service Nee. -
App-dienst
snet-appServicePlan		 Geen verkeer toegestaan Privé-eindpunten en Azure Monitor Ja Naar Azure Monitor
Foundry Agentendienst
snet-agentsEgress		 Geen verkeer toegestaan Privé-eindpunten en internet Ja Alleen openbare FQDN's die uw agents mogen gebruiken
Jump box-VM's
snet-jumpBoxes		 Azure Bastionsubnet Privé-eindpunten en internet Ja Indien nodig door de VIRTUELE machine
Agents bouwen
snet-buildAgents		 Azure Bastionsubnet Privé-eindpunten en internet Ja Indien nodig door de VIRTUELE machine
Azure Bastion
AzureBastionSubnet		 NSG-toegang en Azure Bastion bekijken NSG-toegang en Azure Bastion bekijken Nee. -
Azure Firewall
AzureFirewallSubnet
AzureFirewallManagementSubnet		 Geen NSG Geen NSG Nee. -

Dit ontwerp weigert expliciet al het andere verkeer, via NSG-regels of standaard in Azure Firewall.

Wanneer u netwerksegmentatie en -beveiliging in deze architectuur implementeert, volgt u deze aanbevelingen:

  • Implementeer een Azure DDoS Protection-plan op het openbare IP-adres van Application Gateway om volumetrische aanvallen te beperken.

  • Koppel een NSG aan elk subnet dat dit ondersteunt. Pas de striktste regels toe zonder de vereiste functionaliteit te verstoren.

  • Geforceerde tunneling toepassen op alle ondersteunde subnetten, zodat uw uitgaande firewall al het uitgaande verkeer kan inspecteren. Gebruik geforceerde tunneling zelfs op subnetten waarvoor u geen uitgaand verkeer verwacht. Met deze methode wordt een diepgaande verdedigingsmaatregel toegevoegd die beschermt tegen opzettelijk of onopzettelijke misbruik van het subnet.

Governance via beleid

Als u wilt in overeenstemming zijn met de beveiligingsbasislijn van uw workload, gebruikt u Azure Policy en netwerkbeleid om ervoor te zorgen dat alle workloadresources aan uw vereisten voldoen. Platformautomatisering via beleid vermindert het risico op beveiligingsconfiguratiedrift en helpt bij het verminderen van handmatige validatieactiviteiten.

Overweeg het implementeren van de volgende typen beveiligingsbeleid om uw architectuur te versterken:

  • Schakel sleutelgebaseerde of andere lokale verificatiemethoden uit in services zoals Azure AI-services en Key Vault.

  • Expliciete configuratie van netwerktoegangsregels, privé-eindpunten en NSG's vereisen.

  • Versleuteling vereisen, zoals door de klant beheerde sleutels.

  • Het maken van resources beperken, zoals het beperken van regio's of resourcetypen.

Kostenoptimalisatie

Kostenoptimalisatie richt zich op manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie de controlelijst ontwerpbeoordeling voor Kostenoptimalisatie voor meer informatie.

Deze prijsschatting van Azure biedt een voorbeeld van prijzen voor deze architectuur. Dit voorbeeld bevat alleen de onderdelen in deze architectuur, dus pas deze aan zodat deze overeenkomt met uw gebruik. De duurste onderdelen in het scenario zijn Azure Cosmos DB, AI Search en DDoS Protection. Andere belangrijke kosten zijn de rekenkracht van de chatgebruikersinterface en Application Gateway. Optimaliseer deze resources om de kosten te verlagen.

Foundry Agentendienst

Wanneer u de standaardimplementatie gebruikt, moet u de afhankelijkheden van de service inrichten en beheren in uw eigen Azure-abonnement.

In de volgende aanbevelingen wordt uitgelegd hoe u de kosten voor deze vereiste services kunt optimaliseren:

  • Foundry Agent Service beheert de toewijzing van de aanvraageenheid (RU) in Azure Cosmos DB. Koop gereserveerde capaciteit voor Azure Cosmos DB om de kosten op lange termijn te verlagen. Reserveringen afstemmen op de verwachte gebruiksduur en het verwachte volume. Houd er rekening mee dat gereserveerde capaciteit vooraf toezegging vereist en dat er geen flexibiliteit is als de gebruikspatronen van uw workload aanzienlijk veranderen.

  • Als voor uw chatscenario geen bestandsuploads nodig zijn, sluit u deze functie uit in uw toepassing. Pas in dat geval de volgende configuratiewijzigingen toe:

    • Gebruik een lokaal redundante opslaglaag (LRS) voor het opslagaccount.
    • Configureer AI Search met één replica in plaats van de aanbevolen drie replica's.

  • Verwijder regelmatig ongebruikte agents en de bijbehorende threads met behulp van de SDK of REST API's. Verouderde agents en threads blijven opslag gebruiken en kunnen de kosten verhogen voor Azure Cosmos DB, Storage en AI Search.

  • Schakel functies uit voor afhankelijke resources die uw workload niet nodig heeft, zoals de volgende functies:

    • De semantische ranker in AI Search
    • De schrijfmogelijkheden voor gateways en meerdere regio's in Azure Cosmos DB

  • Als u kosten voor bandbreedte tussen regio's wilt voorkomen, implementeert u Azure Cosmos DB, Storage en AI Search in dezelfde Azure-regio als Foundry Agent Service.

  • Vermijd colocatie van workloadspecifieke gegevens in dezelfde Azure Cosmos DB- of AI Search-resources die door Foundry Agent Service worden gebruikt. In sommige gevallen kunt u deze resources delen om ongebruikte capaciteit in RU's of zoekeenheden te verminderen, waardoor de kosten worden verlaagd. Overweeg alleen het delen van resources na een grondige risicoanalyse voor betrouwbaarheid, beveiliging en prestatieproblemen.

Kennis en hulpprogramma's van agents

Foundry Agent Service voert agentlogica op een niet-deterministische manier uit. Er kan voor elke aanvraag een verbonden kennisarchief, hulpprogramma of andere agent worden aangeroepen, zelfs als die resource niet relevant is voor de gebruikersquery. Dit gedrag kan leiden tot onnodige aanroepen naar externe API's of gegevensbronnen, verhoogt de kosten voor elke transactie en introduceert onvoorspelbare gebruikspatronen die budgetprognoses bemoeilijken.

Als u kosten wilt beheren en voorspelbaar gedrag wilt behouden, past u de volgende strategieën toe:

  • Verbind alleen de kennisarchieven, hulpprogramma's of agents die waarschijnlijk worden gebruikt met de meeste aanroepen van agents. Vermijd het verbinden van resources die zelden nodig zijn of die hoge kosten in rekening brengen voor elke aanroep, tenzij ze essentieel zijn.

  • Ontwerp en verfijn de systeemprompt zorgvuldig om de agent te instrueren om onnodige of redundante externe aanroepen te minimaliseren. De systeemprompt moet de agent begeleiden om alleen de meest relevante verbindingen voor elke aanvraag te gebruiken.

  • Gebruik Telemetrie van Azure AI Foundry om te controleren welke externe API's, kennisarchieven of hulpprogramma's de agent opent, hoe vaak deze worden geopend en de bijbehorende kosten. Bekijk deze telemetrie regelmatig om onverwachte gebruikspatronen of kostenpieken te identificeren en pas uw systeemprompt indien nodig aan.

  • Houd er rekening mee dat niet-deterministische aanroep kostenprognoses moeilijk kan maken, met name wanneer u integreert met api's met datalimiet. Als u voorspelbare kosten nodig hebt, kunt u overwegen de orchestrator zelf te hosten met behulp van deterministische code.

Azure OpenAI-modellen

Modelimplementaties in Azure AI Foundry maken gebruik van de MaaS-benadering. De kosten zijn voornamelijk afhankelijk van het gebruik of vooraf ingerichte toewijzing.

Als u de kosten van het verbruiksmodel in deze architectuur wilt beheren, gebruikt u een combinatie van de volgende benaderingen:

  • Clients beheren. Clientaanvragen stimuleren de meeste kosten in een verbruiksmodel, dus het beheer van agentgedrag is cruciaal.

    Voer de volgende acties uit om onnodig gebruik te verminderen:

    • Alle modelgebruikers goedkeuren. Maak geen modellen beschikbaar op een manier die onbeperkte toegang toestaat.

    • Beperkingen voor tokenbeperking afdwingen, zoals max_tokens en max_completions via agentlogica. Dit besturingselement is alleen beschikbaar in zelf-hostende indeling. Foundry Agent Service biedt geen ondersteuning voor deze functionaliteit.

    • Optimaliseer de invoer- en antwoordlengte van de prompt. Langere prompts verbruiken meer tokens, waardoor de kosten toenemen. Prompts die onvoldoende context hebben, verminderen de effectiviteit van het model. Maak beknopte prompts die voldoende context bieden om het model in staat te stellen een nuttig antwoord te genereren. Zorg ervoor dat u de limiet van de antwoordlengte optimaliseert.

      Dit besturingselementniveau is alleen beschikbaar in zelf-hostende indeling. Foundry Agent Service biedt onvoldoende configuratie om deze functionaliteit te ondersteunen.

  • Kies het juiste model voor de agent. Selecteer het goedkoopste model dat voldoet aan de vereisten van uw agent. Vermijd het gebruik van modellen met hogere kosten, tenzij ze essentieel zijn. De referentie-implementatie maakt bijvoorbeeld gebruik van GPT-4o in plaats van een duurder model en levert voldoende resultaten op.

  • Gebruik bewaken en beheren. Gebruik Microsoft Cost Management en modeltelemetrie om tokengebruik bij te houden, budgetten in te stellen en waarschuwingen te maken voor afwijkingen. Controleer regelmatig gebruikspatronen en pas zo nodig quota of clienttoegang aan. Zie Kosten voor Azure AI Foundry plannen en beheren voor meer informatie.

  • Gebruik het juiste implementatietype. Gebruik prijzen voor betalen per gebruik voor onvoorspelbare workloads en schakel over naar ingerichte doorvoer wanneer het gebruik stabiel en voorspelbaar is. Combineer beide opties wanneer u een betrouwbare basislijn tot stand brengt.

  • Beperk het gebruik van speeltuinen. Als u ongeplande productiekosten wilt voorkomen, beperkt u het gebruik van de Azure AI Foundry-speeltuin tot alleen preproductieomgevingen.

  • Plan het nauwkeurig afstemmen en genereren van afbeeldingen zorgvuldig. Deze functies hebben verschillende factureringsmodellen. Ze worden per uur of per batch gefactureerd. Plan het gebruik om af te stemmen op factureringsintervallen en afval te voorkomen.

Netwerkbeveiligingsbronnen

Voor deze architectuur is Azure Firewall vereist als uitgaand besturingspunt. Als u de kosten wilt optimaliseren, gebruikt u de Basic-laag van Azure Firewall, tenzij voor de rest van uw workloadonderdelen geavanceerde functies zijn vereist. Hogere lagen voegen kosten toe, dus gebruik ze alleen als u hun mogelijkheden nodig hebt.

Als uw organisatie Azure-landingszones gebruikt, kunt u overwegen om gedeelde firewall- en DDoS-resources (Gedistribueerde Denial of Service) te gebruiken om de kosten uit te stellen of te verlagen. Workloads met vergelijkbare beveiligings- en prestatievereisten kunnen profiteren van gedeelde resources. Zorg ervoor dat gedeelde resources geen beveiligings- of operationele risico's veroorzaken. Deze architectuur, geïmplementeerd in een Azure-landingszone, maakt gebruik van gedeelde resources.

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.

De volgende richtlijnen voor operationele uitmuntendheid bevatten niet de front-endtoepassingselementen, die hetzelfde blijven als de maximaal beschikbare zone-redundante webtoepassingsarchitectuur van de basislijn.

Bij het plannen van uw experimenten, testen en productieomgevingen moet u afzonderlijke en geïsoleerde AI Foundry-resources instellen, inclusief afhankelijkheden.

Rekenkracht van agent

Microsoft beheert het serverloze rekenplatform voor REST API's van Azure AI Agent en de implementatielogica van de orchestration volledig. Een zelf-hostende indeling biedt meer controle over runtime-kenmerken en -capaciteit, maar u moet de dagelijkse 2-bewerkingen voor dat platform rechtstreeks beheren. Evalueer de beperkingen en verantwoordelijkheden van uw benadering om te begrijpen welke dag-2-bewerkingen u moet implementeren om uw indelingslaag te ondersteunen.

In beide benaderingen moet u statusopslag beheren, zoals chatgeschiedenis en agentconfiguratie voor duurzaamheid, back-up en herstel.

Controle

Net als bij de basisarchitectuur zijn diagnostische gegevens van alle services geconfigureerd voor verzending naar de Log Analytics-werkruimte van uw workload. Alle services behalve App Service leggen alle logboeken vast. In productie hoeft u mogelijk niet alle logboeken vast te leggen. De chat-UI-toepassing kan bijvoorbeeld alleen vereisen AppServiceHTTPLogs, AppServiceConsoleLogs, , AppServiceAppLogs, AppServicePlatformLogsen AppServiceAuthenticationLogs. Stem logboekstromen af op uw operationele behoeften.

Evalueer aangepaste waarschuwingen, zoals aangepaste waarschuwingen in de Basislijnwaarschuwingen van Azure Monitor, voor de resources in deze architectuur. Houd rekening met de volgende waarschuwingen:

Bewaak het gebruik van tokens op basis van uw modelimplementaties. In deze architectuur houdt Azure AI Foundry het tokengebruik bij via de integratie met Application Insights.

Uw jumpboxen en buildagent-VM's bevinden zich op een locatie met hoge bevoegdheden, die deze VM's een netwerklijn biedt waarmee u het gegevensvlak van alle onderdelen in uw architectuur kunt bekijken. Zorg ervoor dat deze VM's voldoende logboeken verzenden om te begrijpen wanneer ze worden gebruikt, wie ze gebruikt en welke acties ze uitvoeren.

Versiebeheer van agents en levenscyclus

Behandel elke agent als een onafhankelijk implementeerbare eenheid binnen uw chatworkload, tenzij u specifiek uw toepassing ontwerpt om agents tijdens runtime dynamisch te maken en te verwijderen. Deze agents hebben vereisten voor levenscyclusbeheer die vergelijkbaar zijn met andere microservices in uw workload.

Om serviceonderbrekingen te voorkomen, zorgt u voor een veilige en gecontroleerde agentimplementatie door de volgende methoden te implementeren:

  • Agents definiëren als code. Sla altijd agentdefinities, verbindingen, systeemprompts en configuratieparameters op in broncodebeheer. Deze praktijk zorgt voor traceerbaarheid en reproduceerbaarheid. Vermijd niet-bijgehouden wijzigingen via de Azure AI Foundry-portal.

  • Agentimplementatie automatiseren. Gebruik de pijplijnen voor continue integratie en continue implementatie (CI/CD) van uw workload. Gebruik de Azure AI Agent SDK om agentwijzigingen te bouwen, testen en implementeren vanuit uw buildagents die zijn verbonden met het netwerk.

    Geef de voorkeur aan agentpijplijnen die u onafhankelijk kunt implementeren voor kleine, incrementele wijzigingen. Zorg er echter voor dat de pijplijnen voldoende flexibiliteit bieden om ze naast uw toepassingscode te implementeren wanneer u gecoördineerde updates nodig hebt. Als u deze methode wilt ondersteunen, koppelt u losjes uw chat-UI-code en uw chatagents, zodat wijzigingen in het ene onderdeel geen gelijktijdige wijzigingen in het andere onderdeel vereisen.

  • Test vóór productie. Valideer agentgedrag, prompts en verbindingen in preproductieomgevingen. Gebruik een combinatie van geautomatiseerde en handmatige tests om regressies, beveiligingsproblemen en onbedoelde wijzigingen in agentgedrag te ondervangen.

    Agents die zijn gedefinieerd in Foundry Agent Service gedragen zich niet-deterministisch, dus u moet bepalen hoe u het gewenste kwaliteitsniveau kunt meten en onderhouden. Maak en voer een testpakket uit waarmee wordt gecontroleerd op ideale antwoorden op realistische gebruikersvragen en -scenario's.

  • Versie en traceer agents. Wijs duidelijke versie-id's toe aan elke agent. Houd records bij van welke agentversies actief zijn, samen met hun afhankelijkheden, zoals modellen, gegevensbronnen en hulpprogramma's. Geef de voorkeur aan het implementeren van nieuwe agentversies naast bestaande versies om progressieve implementatie, rollback en gecontroleerde migratie van gebruikers of sessies mogelijk te maken.

  • Plan een failback. Azure AI Foundry biedt geen ingebouwde ondersteuning voor blauwgroene of kanaire implementaties van agents. Als u deze implementatiepatronen nodig hebt, implementeert u een routeringslaag, zoals een API-gateway of aangepaste router, vóór de agent-API. Met deze routeringslaag kunt u verkeer incrementeel verplaatsen tussen agentversies, de impact bewaken en een volledige switch-over uitvoeren wanneer u klaar bent.

  • Coördinaat agent verwijderen. Wanneer u agents verwijdert, coördineert u het proces met de vereisten voor statusbeheer en gebruikerservaring van uw toepassing. Afhandelen van actieve chatsessies op de juiste manier. Afhankelijk van de functionele vereisten van uw workload kunt u sessies migreren, gebruikers vastmaken aan de oude agentversie of gebruikers verplichten om nieuwe sessies te starten.

Prestatie-efficiëntie

Prestatie-efficiëntie verwijst naar de mogelijkheid van uw workload om efficiënt te voldoen aan de behoeften van de gebruiker. Zie de controlelijst ontwerpbeoordeling voor prestatie-efficiëntie voor meer informatie.

In deze sectie wordt de prestatie-efficiëntie voor AI Search, modelimplementaties en Azure AI Foundry besproken.

In Foundry Agent Service beheert u niet de specifieke query's die naar uw indexen worden verzonden, omdat agents codeloos zijn. Als u de prestaties wilt optimaliseren, moet u zich richten op wat u in de index kunt beheren. Bekijk hoe uw agent doorgaans query's op de index opvraagt en richtlijnen toepast voor het analyseren en optimaliseren van prestaties in AI Search.

Als alleen indexserverafstemming niet alle knelpunten oplost, kunt u de volgende opties overwegen:

  • Vervang de directe verbinding met AI Search door een verbinding met een API die u bezit. Deze API kan code implementeren die is geoptimaliseerd voor de ophaalpatronen van uw agent.

  • Ontwerp de indelingslaag opnieuw om het zelf-hostende alternatief te gebruiken, zodat u query's in uw eigen orchestratorcode kunt definiëren en optimaliseren.

Prestatie-efficiëntie in modelimplementaties

  • Bepaal of uw toepassing ingerichte doorvoer nodig heeft of het gedeelde model (verbruik) kan gebruiken. Ingerichte doorvoer biedt gereserveerde capaciteit en voorspelbare latentie, wat belangrijk is voor productieworkloads met strikte serviceniveaudoelstellingen. Het verbruiksmodel biedt de best effort-service en kan last hebben van lawaaierige bureneffecten.

  • Bewaak het door de inrichting beheerde gebruik om overprovisioning of onderbebouwing te voorkomen.

  • Kies een gespreksmodel dat voldoet aan uw latentievereisten voor deductie.

  • Implementeer modellen in dezelfde gegevensregio als uw agents om de netwerklatentie te minimaliseren.

Prestaties van Azure AI-agent

Azure AI-agents worden uitgevoerd op een serverloze compute-back-end die geen ondersteuning biedt voor het afstemmen van aangepaste prestaties. U kunt de prestaties echter nog steeds verbeteren via het ontwerp van de agent:

  • Minimaliseer het aantal kennisarchieven en hulpprogramma's die zijn verbonden met uw chatagent. Elke extra verbinding verhoogt mogelijk de totale runtime voor een agentaanroep, omdat de agent mogelijk alle geconfigureerde resources voor elke aanvraag aanroept.

  • Gebruik Azure Monitor en Application Insights om aanroeptijden, hulpprogramma's en kennisarchieflatenties en foutpercentages van agents bij te houden. Bekijk deze telemetrie regelmatig om trage kennis- of hulpprogrammaverbindingen te identificeren.

  • Ontwerp systeemprompts die de agent helpen om verbindingen efficiënt te gebruiken. Geef de agent bijvoorbeeld de opdracht om alleen query's uit te voeren op externe kennisarchieven wanneer dat nodig is of om redundante aanroepen van hulpprogramma's te voorkomen.

  • Controleren op servicelimieten of quota die van invloed kunnen zijn op de prestaties tijdens piekgebruik. Let op beperkingsindicatoren zoals HTTP 429- of 503-antwoorden, ook al wordt serverloze rekenkracht automatisch geschaald.

Dit scenario implementeren

Als u deze referentie-implementatie wilt implementeren en uitvoeren, volgt u de implementatiehandleiding in de referentieimplementatie voor de Foundry Agent Service-chat.

Bijdragers

Microsoft onderhoudt dit artikel. De volgende inzenders hebben dit artikel geschreven.

Hoofdauteurs:

  • Rob Bagby | Principal Content Developer - Azure Patterns & Practices
  • Chad Kittel | Principal Software Engineer - Azure Patterns & Practices

Andere Inzenders:

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

Volgende stap