Grundlegende Referenzarchitektur für Azure AI Foundry-Chats

Azure OpenAI Service

Azure KI Services

Azure App Service

Azure Monitor

Unternehmenschatanwendungen können Mitarbeiter durch Unterhaltungsinteraktionen mit KI-Agents unterstützen. Diese Funktion ist dank der kontinuierlichen Weiterentwicklung von Sprachmodellen, wie z. B. gpT-Modellen von OpenAI und Orchestrierungs-SDKs wie Semantic Kernel, immer leistungsfähiger. Diese Chatanwendungen bestehen in der Regel aus den folgenden Komponenten:

Eine Chat-Benutzeroberfläche, die in eine größere Unternehmensanwendung integriert ist. Sie bietet Benutzern eine unterhaltungsspezifische Erfahrung zusammen mit anderen Geschäftsfunktionen.
Datenrepositorys, die domänenspezifische Informationen enthalten, die für Benutzerabfragen relevant sind.
Sprachmodelle, die über die domänenspezifischen Daten verfügen, um relevante Antworten zu erzeugen.
Ein Orchestrator oder Agent, der die Interaktionen zwischen Datenquellen, Sprachmodellen und dem Endbenutzer überwacht.

Dieser Artikel enthält eine grundlegende Architektur, mit der Sie Unternehmenschatanwendungen mithilfe von Azure AI Foundry und Azure OpenAI in Foundry Models erstellen und bereitstellen können. Diese Architektur verwendet einen einzelnen Agent, der im Azure AI Foundry Agent Service gehostet wird. Der Agent empfängt Benutzernachrichten und fragt dann Datenspeicher ab, um Bodeninformationen für das Sprachmodell abzurufen.

Die Chat-Benutzeroberfläche folgt den grundlegenden Azure App-Dienst-Webanwendungsanleitungen zum Bereitstellen einer sicheren, zonenredundanten und hochverwendten Webanwendung in App Service. In dieser Architektur kommuniziert App Service mit der Azure-Plattform as a Service (PaaS)-Lösung über die Integration des virtuellen Netzwerks über private Endpunkte. In der Chat-UI-Architektur kommuniziert App Service mit dem Agent über einen privaten Endpunkt. Der öffentliche Zugriff auf das Azure AI Foundry-Portal und -Agents ist deaktiviert.

Von Bedeutung

In diesem Artikel werden keine Komponenten oder Architekturentscheidungen aus der grundlegenden Webanwendungsarchitektur des App Service beschrieben. Lesen Sie diesen Artikel für Architekturanleitungen zum Hosten der Webanwendung, die Ihre Chat-UI enthält.

Diese Architektur verwendet das Standard-Agent-Setup des Foundry Agent Service , um Sicherheit, Compliance und Kontrolle auf Unternehmensniveau zu ermöglichen. In dieser Konfiguration bringen Sie Ihr eigenes Netzwerk für die Netzwerkisolation und Ihre eigenen Azure-Ressourcen zum Speichern des Chat- und Agentstatus. Die gesamte Kommunikation zwischen Anwendungskomponenten und Azure-Diensten erfolgt über private Endpunkte, wodurch sichergestellt wird, dass der Datenverkehr im virtuellen Netzwerk Ihrer Workload verbleibt. Ausgehender Datenverkehr von den Agents leitet strikt über die Azure-Firewall weiter, wodurch Ausgangsregeln erzwungen werden.

Tipp

Die Referenzimplementierung des Foundry Agent Service zeigt eine grundlegende End-to-End-Chatimplementierung in Azure. Sie dient als Grundlage für die Entwicklung von benutzerdefinierten Lösungen, während Sie zur Produktion wechseln.

Architektur

Laden Sie eine Visio-Datei dieser Architektur herunter.

Arbeitsablauf

Ein Anwendungsbenutzer interagiert mit einer Chat-UI. Die Anforderungen werden über das Azure-Anwendungsgateway weitergeleitet. Die Azure-Webanwendungsfirewall prüft diese Anforderungen, bevor sie an den Back-End-App-Dienst weitergeleitet werden.
Wenn die Webanwendung eine Benutzerabfrage oder -anweisung empfängt, ruft sie den zweckorientierten Agent auf. Die Webanwendung kommuniziert mit dem Agent über das Azure AI Agent SDK. Die Webanwendung ruft den Agent über einen privaten Endpunkt auf und authentifiziert sich mit seiner verwalteten Identität bei Azure AI Foundry.
Der Agent verarbeitet die Anforderung des Benutzers basierend auf den Anweisungen in der Systemaufforderung. Um die Absicht des Benutzers zu erfüllen, verwendet der Agent ein konfiguriertes Sprachmodell und verbundene Tools und Wissensspeicher.
Der Agent stellt über einen privaten Endpunkt eine Verbindung mit dem Wissensspeicher (Azure AI Search) im privaten Netzwerk bereit.
Anforderungen an externe Wissensspeicher oder Tools, z. B. Wikipedia oder Bing, durchlaufen die Azure-Firewall zur Überprüfung und Zur Durchsetzung von Richtlinien.
Der Agent stellt eine Verbindung mit seinem konfigurierten Sprachmodell her und übergibt den relevanten Kontext.
Bevor der Agent die Antwort auf die Benutzeroberfläche zurückgibt, speichert er die Anforderung, die generierte Antwort und eine Liste der konsultierten Wissensspeicher in einer dedizierten Speicherdatenbank . Diese Datenbank verwaltet den vollständigen Unterhaltungsverlauf, der kontextabhängige Interaktionen ermöglicht und Benutzern das Fortsetzen von Unterhaltungen mit dem Agent ermöglicht, ohne vorheriger Kontext zu verlieren.

Die Azure AI Foundry-APIs unterstützen die Entwicklung von Benutzeroberflächen, die mehrere gleichzeitige, kontextisolte Unterhaltungen verwalten.

Komponenten

Diese Architektur basiert auf der grundlegenden Referenzarchitektur für Azure AI Foundry-Chats. In dieser Architektur werden weitere Azure-Dienste eingeführt, um die Anforderungen des Unternehmens an Zuverlässigkeit, Sicherheit und Betriebssteuerung zu erfüllen. Jede der folgenden Komponenten spielt eine bestimmte Rolle in einer Produktions-Unternehmenschatlösung:

Der Foundry Agent Service stellt die Orchestrierungsebene für Chatinteraktionen bereit. Es hostt und verwaltet Agents, die die folgenden Aufgaben ausführen:
- Verarbeiten von Benutzeranforderungen
- Koordinieren von Anrufen an Tools und andere Agents
- Erzwingen der Inhaltssicherheit
- Integration in Unternehmensidentität, Netzwerk und Observability
Durch die Standard-Agent-Einrichtung wird die Netzwerkisolation sichergestellt und die Kontrolle über die Datenspeicherung bereitgestellt. Sie stellen dedizierte Azure-Ressourcen für den Agentstatus, den Chatverlauf und die Dateispeicherung zur Verfügung, die der Foundry Agent Service exklusiv verwaltet. Andere Anwendungskomponenten in der Workload sollten diese erforderlichen Ressourcen nicht verwenden.
- Azure Cosmos DB für NoSQL hostet die Speicherdatenbank dieser Workload, die in Ihrem Abonnement aufgerufen wird enterprise_memory. Diese Datenbank speichert den Betriebsstatus des Agents, einschließlich Chatthreads und Agentdefinitionen. Dieser Entwurf stellt sicher, dass der Chatverlauf und die Agentkonfiguration isoliert, auditierbar und gemäß den Anforderungen der Datengovernance verwaltet werden. Der Foundry Agent Service verwaltet die Datenbank, die zugehörigen Sammlungen und ihre Daten.
- Ein dediziertes Azure Storage-Konto speichert Dateien, die während Chatsitzungen hochgeladen wurden. Das Hosting dieses Kontos in Ihrem Abonnement bietet eine präzise Zugriffssteuerung, Überwachungsfunktionen und Compliance mit Datenaufbewahrungs- oder Aufbewahrungsrichtlinien. Der Foundry Agent Service verwaltet die Container und den Datenlebenszyklus innerhalb dieser Container.
- Eine dedizierte KI-Suchinstanz speichert einen durchsuchbaren, blockierten Index der hochgeladenen Dateien aus Unterhaltungen mit dem Agent. Außerdem werden statische Dateien gespeichert, die beim Erstellen des Agents als Wissensquellen hinzugefügt werden. Der Foundry Agent Service verwaltet den Index, das Schema und die Daten und verwendet eine eigene Blockierungsstrategie und Abfragelogik.
Das Anwendungsgateway dient als sicherer, skalierbarer Einstiegspunkt für den gesamten HTTP- und HTTPS-Datenverkehr an die Chat-UI. Es stellt transport Layer Security (TLS)-Beendigung und pfadbasiertes Routing bereit. Außerdem werden Anforderungen über Verfügbarkeitszonen verteilt, die hohe Verfügbarkeit und Leistung für die Webanwendungsebene unterstützen. Das Back-End ist der App-Dienst, der den Anwendungscode hostt.
- Die Azure-Webanwendungsfirewall ist in das Anwendungsgateway integriert, um die Chat-UI vor häufigen Sicherheitsrisiken und Angriffen im Web zu schützen. Sie prüft und filtert HTTP-Anforderungen, die eine Sicherheitsebene für öffentlich zugängliche Anwendungen bereitstellen.
- Azure Key Vault speichert und verwaltet die TLS-Zertifikate, die das Anwendungsgateway benötigt. Die zentralisierte Zertifikatverwaltung in Key Vault unterstützt automatisierte Drehung, Überwachung und Einhaltung von Sicherheitsstandards der Organisation. Für diese Architektur sind keine gespeicherten Schlüssel oder andere geheime Schlüssel erforderlich.
Azure Virtual Network bietet Netzwerkisolation für alle Komponenten. Wenn Sie Ressourcen in einem privaten virtuellen Netzwerk platzieren, steuern Sie den Ost-West- und Nord-Süd-Datenverkehr, erzwingen Segmentierung, halten Datenverkehr privat und ermöglichen die Überprüfung von Eingangs- und Ausgangsflüssen. Mit diesem Setup können Sie Sicherheits- und Complianceanforderungen erfüllen.
Azure Private Link verbindet alle PaaS-Dienste wie Azure Cosmos DB, Storage, AI Search und Foundry Agent Service über private Endpunkte mit dem virtuellen Netzwerk. Dieser Ansatz stellt sicher, dass der gesamte Datenverkehr auf dem Azure-Backbone verbleibt, wodurch die Gefährdung des öffentlichen Internets beseitigt und die Angriffsfläche reduziert wird.
Azure Firewall prüft und steuert den gesamten ausgehenden (Ausgehenden) Datenverkehr aus dem virtuellen Netzwerk. Er erzwingt vollqualifizierte Domänennamen (FQDN)-basierte Regeln, wodurch sichergestellt wird, dass nur genehmigte Ziele erreichbar sind. Diese Konfiguration trägt dazu bei, Datenexfiltration zu verhindern und die Anforderungen für die Netzwerksicherheit zu erfüllen.
Azure DNS stellt private DNS-Zonen (Domain Name System) bereit, die mit dem virtuellen Netzwerk verknüpft sind. Dieses Feature ermöglicht die Namensauflösung für private Endpunkte, wodurch sichergestellt wird, dass alle Dienst-zu-Dienst-Kommunikation private IP-Adressen verwendet und innerhalb der Netzwerkgrenze verbleibt.
Speicher hostt den Webanwendungscode als ZIP-Datei für die Bereitstellung in App Service. Diese Methode unterstützt sichere, automatisierte Bereitstellungsworkflows und trennt Anwendungsartefakte von Computeressourcen.

Alternativen

Diese Architektur umfasst mehrere Komponenten, die Sie je nach den funktionalen und nichtfunktionellen Anforderungen Ihrer Workload durch andere Azure-Dienste oder -Ansätze ersetzen können. Berücksichtigen Sie die folgenden Alternativen und Kompromisse.

Chat-Orchestrierung

Aktueller Ansatz: Diese Architektur verwendet den Foundry Agent Service , um Chatflüsse zu koordinieren, einschließlich des Abrufens von Bodendaten aus Wissensspeichern und aufrufen von Azure OpenAI-Modellen. Der Foundry Agent Service bietet codelose, nicht unbestimmte Orchestrierung. Er behandelt Chatanfragen, Threadverwaltung, Toolaufrufe, Inhaltssicherheit und Integration mit Identität, Netzwerk und Observierbarkeit. Sie stellt eine systemeigene Speicherdatenbanklösung bereit.

Alternativer Ansatz: Sie können die Orchestrierungsebene selbst hosten, indem Sie Frameworks wie semantischen Kernel oder LangChain verwenden. Verwenden Sie diese Frameworks, um deterministische, codegesteuerte Chatflüsse und benutzerdefinierte Orchestrierungslogik zu implementieren.

Berücksichtigen Sie diese Alternative, wenn Ihre Workload die folgenden Funktionen erfordert:

Feinkörnige, deterministische Kontrolle über die Orchestrierungssequenz, Werkzeugaufrufe oder Prompt Engineering
Integration in benutzerdefinierte Geschäftslogik oder externe Systeme, die der Foundry Agent Service nicht nativ unterstützt
Erweitertes Clientanforderungsrouting für Experimentier- oder sichere Bereitstellungsmethoden
Eine benutzerdefinierte Speicherdatenbanklösung, die sich von der systemeigenen Foundry Agent Service-Lösung unterscheidet

Die selbst gehostete Orchestrierung erhöht die betriebliche Komplexität und erfordert, dass Sie Compute, Skalierung und Sicherheit verwalten.

Komponenten der Anwendungsebene

Aktueller Ansatz: Die Front-End-Website der Chat-UI wird auf dem Web-Apps-Feature von App Service gehostet, das eine verwaltete, skalierbare Plattform für Webanwendungen bereitstellt. Web-Apps werden systemintern in Azure-Netzwerk- und Sicherheitsfeatures integriert.

Alternativer Ansatz: Sie können andere von Azure verwaltete Computeplattformen wie Azure-Container-Apps oder Azure Kubernetes Service (AKS) verwenden, um die Anwendungsebene zu hosten.

Erwägen Sie diese Alternative, wenn Ihre Workload eine der folgenden Bedingungen erfüllt:

Eine andere Computeplattform unterstützt besser bestimmte Anwendungsfälle, und die Verlagerung von Diensten auf dieser Plattform kann die Kosteneffizienz verbessern und Vorgänge vereinfachen.
Für Ihre Anwendung sind anspruchsvollere Skalierung, Orchestrierung oder benutzerdefinierte Netzwerke erforderlich.

Der App-Dienst bleibt die bevorzugte Option für die Einfachheit beim Hosten von Webanwendungen und deren APIs.

Speichern von Bodendaten (Wissensspeicher)

Aktueller Ansatz: Diese Architektur verwendet DIE KI-Suche als primären Datenspeicher für Das Erdungswissen. Es verwendet KI-Suchvektorsuch- und semantische Rangfolgefunktionen.

Alternativer Ansatz: Sie können andere Datenplattformen für die Grundlagen von Wissen verwenden, z. B. Azure Cosmos DB, Azure SQL-Datenbank oder andere OLTP-Datenspeicher (Online Transaction Processing). Ihre Datenplattform hängt von Ihren vorhandenen Datenbestands-, Daten-Aktualitätsanforderungen und Abfrageanforderungen ab.

Erwägen Sie diese Alternative, wenn Ihre Workload eine der folgenden Bedingungen erfüllt:

Sie verwalten bereits Ihr Grundwissen in einer vorhandenen Transaktions- oder Betriebsdatenbank.
Sie benötigen eine Mehrmodell- oder SDK-Unterstützung, die in der KI-Suche nicht verfügbar ist.
Sie müssen in spezialisierte Datenquellen oder Ältere Systeme integriert werden.

Die Vektorsuche ist üblich für die Generierung von Abruferweiterungen, aber nicht immer erforderlich. Weitere Informationen finden Sie unter Auswählen eines Azure-Diensts für die Vektorsuche. Bevor Sie einen Datenspeicher auswählen, bewerten Sie die Datenzugriffsmuster, Latenz und Skalierbarkeitsanforderungen Ihrer Workload.

Vordefinierter Agent oder dynamisch erstellte Agent

Aktueller Ansatz: Die Referenzimplementierung verwendet einen statisch definierten Agent, der als Microservice in Azure AI Foundry bereitgestellt wird. Die Logik und Datenquellen des Agents werden bei der Bereitstellung konfiguriert und bleiben bis zur nächsten Anwendungsfreigabe unverändert. Dieser Ansatz funktioniert gut, wenn Agentverhalten und Datenquellen über DevOps-Prozesse stabil und gesteuert werden.

Alternativer Ansatz: Sie können Agents zur Laufzeit dynamisch erstellen oder ändern, indem Sie das Azure AI Agent SDK verwenden. Mit diesem Ansatz kann die Anwendung Agents bei Bedarf instanziieren, Systemaufforderungen anpassen oder Verbindungen basierend auf Benutzerkontext oder Geschäftslogik neu konfigurieren.

Erwägen Sie dynamische Agents, wenn Ihre Workload die folgenden Funktionen erfordert:

Personalisiertes Agent-Verhalten oder Datenquellen für jeden Benutzer oder jede Sitzung
Häufige oder programmgesteuerte Änderungen an der Agentkonfiguration
Kurzlebige, kontextspezifische Agentunterstützung für erweiterte Benutzeroberflächen

Dynamisches Agentenmanagement erhöht Flexibilität, führt aber auch die Last des Lebenszyklusmanagements ein. Stellen Sie sicher, dass Sie über geeignete Steuerelemente für die Agenterstellung, -änderung und -bereinigung verfügen.

Wählen Sie den Agent-Ansatz aus, der den Anforderungen ihrer Workload an die Benutzerfreundlichkeit entspricht.

Überlegungen

Diese Überlegungen bilden die Säulen des Azure Well-Architected Framework, einer Reihe von Leitprinzipien, die Sie zur Verbesserung der Qualität eines Workloads verwenden können. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Wenden Sie diese Architektur und die AI-Workloads in Azure-Entwurfsanleitungen während der Entwurfsphase Ihrer Workload an.

Zuverlässigkeit

Zuverlässigkeit trägt dazu bei, dass Ihre Anwendung die Verpflichtungen erfüllen kann, die Sie für Ihre Kunden vornehmen. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Zuverlässigkeit.

Die grundlegende App Service-Webanwendungsarchitektur konzentriert sich auf die Zonenredundanz für wichtige regionale Dienste. Verfügbarkeitszonen sind physisch getrennte Standorte innerhalb einer Region, die Redundanz bieten, wenn Sie zwei oder mehr Instanzen auf diese Weise bereitstellen. Wenn eine Zone Ausfallzeiten erlebt, bleiben andere in der Region möglicherweise nicht betroffen. Die Architektur verteilt auch Instanzen und Konfigurationen von Azure-Diensten über Verfügbarkeitszonen hinweg. Weitere Informationen finden Sie unter Baseline hochverwendbarte zonenredundante Webanwendung.

In diesem Abschnitt wird die Zuverlässigkeit für Komponenten behandelt, die nicht in der Basisarchitektur des App Service behandelt werden, insbesondere azure AI Foundry und AI Search.

Zonenredundanz in Der Orchestrierungsebene

Unternehmensbereitstellungen erfordern in der Regel Zonalredundanz, um das Risiko von Dienstunterbrechungen durch Fehler auf Zonenebene zu minimieren. In Azure bedeutet Zonenredundanz die Verwendung von Ressourcen, die Verfügbarkeitszonen unterstützen und mindestens drei Instanzen bereitstellen oder Redundanz auf Plattformebene aktivieren, bei denen die direkte Instanzsteuerung nicht verfügbar ist.

In dieser Architektur hosten Azure AI Foundry die Foundry Agent Service-Funktion. Die Zuverlässigkeit des Agents hängt von der Verfügbarkeit der Foundry Agent Service-Abhängigkeiten ab, die Azure Cosmos DB, Storage und AI Search sind. Der Foundry Agent Service verwaltet die Daten innerhalb dieser Dienste, aber Sie konfigurieren ihre Zuverlässigkeit in Ihrem Abonnement.

Befolgen Sie die folgenden Empfehlungen, um zonenbedingte Redundanz für die Orchestrierungsebene zu erzielen:

Aktivieren Sie Zonenredundanz in Ihrem Azure Cosmos DB für NoSQL-Konto . Diese Konfiguration stellt die synchrone Datenreplikation über mehrere Zonen hinweg sicher, wodurch das Risiko von Datenverlusten oder Ausfallzeiten durch einen Ausfall einer einzelnen Zone reduziert wird.

Ziehen Sie auch die globale Verteilung in Betracht, um regionale Ausfälle innerhalb von Azure Cosmos DB zu mindern.
Verwenden Sie den zonenredundanten Speicher (ZRS) für Ihr Speicherkonto. Verwenden Sie für eine höhere Resilienz geozonenredundanten Speicher (GZRS), der zonal und regionale Redundanz kombiniert.
Konfigurieren Sie Ihre KI-Suchinstanz mit mindestens drei Replikaten. Diese Konfiguration stellt sicher, dass der Dienst Replikate über eindeutige Zonen in Ihrer Region verteilt.

Wenn Ihr Agent in andere workloadspezifische Abhängigkeiten integriert ist, z. B. benutzerdefinierte Toolverbindungen oder externe Wissensspeicher, stellen Sie sicher, dass diese Abhängigkeiten Ihre Verfügbarkeits- und Redundanzanforderungen erfüllen. Jede einzelzonen- oder nichtredunde Abhängigkeit kann die Gesamtsicherheit der Orchestrierungsebene beeinträchtigen.

Das AI Foundry-Portal, seine Datenebenen-APIs und die Foundry Agent Service-Funktion bieten keine direkten Steuerelemente für Zonenredundanz.

Zuverlässigkeit im Azure AI Foundry-Modellhosting

Azure AI Foundry stellt Modelle als Dienst (MaaS) bereit, die mit mehreren Bereitstellungsoptionen gehostet werden. Diese Optionen unterstützen in erster Linie die Kontingent- und Durchsatzverwaltung und nicht die herkömmliche hohe Verfügbarkeit innerhalb einer Region. Standardmodellbereitstellungen werden in einer einzelnen Region ausgeführt und unterstützen keine Verfügbarkeitszonen. Um die Verfügbarkeit von Rechenzentren mit mehreren Rechenzentren zu erreichen, müssen Sie entweder eine globale oder eine Datenzonenmodellbereitstellung verwenden.

Stellen Sie für Unternehmenschatszenarien sowohl ein bereitgestelltes Datenzonen - als auch ein Datenzonenstandardmodell bereit. Konfigurieren Sie den Überlauf , um übermäßigen Datenverkehr oder Fehler zu behandeln. Wenn Ihre Workload keine geringe Latenz oder strenge geografische Datenbewahrung und -verarbeitung erfordert, verwenden Sie globale Bereitstellungen für maximale Resilienz.

Azure AI Foundry unterstützt keine erweiterten Lastenausgleichs- oder Failovermechanismen, z. B. Roundrobin-Routing oder Schaltkreisbruch, für Modellbereitstellungen. Wenn Sie eine präzise Redundanz und Failoversteuerung innerhalb einer Region benötigen, hosten Sie Die Modellzugriffslogik außerhalb des verwalteten Diensts. Sie können beispielsweise ein benutzerdefiniertes Gateway mithilfe von Azure API Management erstellen. Mit diesem Ansatz können Sie benutzerdefinierte Routing-, Integritätsprüfungen und Failoverstrategien implementieren. Sie erhöht aber auch die Betriebskomplexität und verschiebt die Verantwortung für die Zuverlässigkeit dieser Komponente in Ihr Team.

Sie können Gateway-Fronted-Modelle auch als benutzerdefinierte API-basierte Tools oder Wissensspeicher für Ihren Agent verfügbar machen. Weitere Informationen finden Sie unter Verwenden eines vor mehreren Azure OpenAI-Bereitstellungen oder -Instanzen hinzugefügten Gateways.

Zuverlässigkeit in der KI-Suche nach Unternehmenskenntnissen

Stellen Sie die KI-Suche mithilfe des Standard-Preisniveaus oder höher in einer Region bereit, die Verfügbarkeitszonen unterstützt. Konfigurieren Sie mindestens drei Replikate, um sicherzustellen, dass der Dienst Instanzen über separate Verfügbarkeitszonen verteilt. Diese Konfiguration bietet Resilienz für Fehler auf Zonenebene und unterstützt hohe Verfügbarkeit für Suchvorgänge.

Verwenden Sie die folgenden Methoden, um die optimale Anzahl von Replikaten und Partitionen für Ihre Workload zu ermitteln:

Überwachen Sie die KI-Suche mithilfe integrierter Metriken und Protokolle. Nachverfolgen der Abfragelatenz, Drosselung und Ressourcennutzung.
Verwenden Sie Überwachungsmetriken und Protokolle und Leistungsanalysen, um die entsprechende Anzahl von Replikaten zu ermitteln. Dieser Ansatz hilft Ihnen, die Drosselung von hohem Abfragevolume, unzureichenden Partitionen oder Indexeinschränkungen zu vermeiden.
Stellen Sie die Indizierungssicherheit sicher, indem Sie Unterbrechungen von regelmäßigen Indizierungs- oder Indizierungsfehlern vermeiden. Erwägen Sie die Indizierung in einen Offlineindex, und tauschen Sie sie aus Ihrem Liveindex in Ihren neu erstellten Index, nachdem Sie die Datenintegrität überprüft haben.

Zuverlässigkeit in Azure Firewall

Azure Firewall ist ein kritischer Ausgangspunkt in dieser Architektur, stellt jedoch einen einzelnen Fehlerpunkt für den gesamten ausgehenden Datenverkehr dar. Um dieses Risiko zu verringern, stellen Sie Azure Firewall in allen Verfügbarkeitszonen in Ihrer Region bereit. Diese Konfiguration trägt dazu bei, ausgehende Verbindungen aufrechtzuerhalten, wenn eine Zone nicht verfügbar ist.

Wenn Ihre Workload ein hohes Volumen gleichzeitiger ausgehender Verbindungen erfordert, konfigurieren Sie die Azure Firewall mit mehreren öffentlichen IP-Adressen. Dieser Ansatz verteilt SNAT-Verbindungen (Source Network Address Translation) über mehrere IP-Adresspräfixe, wodurch das Risiko einer SNAT-Portausschöpfung reduziert wird. Die SNAT-Erschöpfung kann zu unterbrechungs- oder totalem Verlust der ausgehenden Konnektivität für Agents und andere Workloadkomponenten führen, was zu Ausfallzeiten von Features oder zu leistungseinbußen führt.

Überwachen sie die SNAT-Portnutzung und den Firewallstatus. Wenn Sie Verbindungsfehler oder Durchsatzprobleme beobachten, überprüfen Sie Firewallmetriken und Protokolle, um SNAT-Erschöpfung oder andere Engpässe zu identifizieren und zu beheben.

Isolieren von Abhängigkeiten des Foundry Agent Service von ähnlichen Workloadkomponenten

Um die Zuverlässigkeit zu maximieren und den Strahlradius von Fehlern zu minimieren, isolieren Sie die Abhängigkeiten des Foundry Agent Service streng von anderen Workloadkomponenten, die dieselben Azure-Dienste verwenden. Geben Sie insbesondere keine AI Search-, Azure Cosmos DB- oder Speicherressourcen zwischen dem Agentdienst und anderen Anwendungskomponenten gemeinsam. Stellen Sie stattdessen dedizierte Instanzen für die erforderlichen Abhängigkeiten des Agentdiensts bereit.

Diese Trennung bietet zwei wichtige Vorteile:

Sie enthält Fehler oder Leistungsbeeinträchtigungen für ein einzelnes Workloadsegment, wodurch kaskadierende Auswirkungen auf nicht verwandte Anwendungsfeatures verhindert werden.
Sie können gezielte betriebliche Prozesse wie Sicherung, Wiederherstellung und Failover anwenden. Diese Prozesse werden auf die spezifischen Verfügbarkeits- und Wiederherstellungsanforderungen des Workloadflusses abgestimmt, der diese Ressourcen verwendet.

Wenn Ihre Chat-UI-Anwendung beispielsweise den Transaktionsstatus in Azure Cosmos DB speichern muss, stellen Sie ein separates Azure Cosmos DB-Konto und eine separate Datenbank für diesen Zweck bereit, anstatt das Konto oder die Datenbank wiederzuverwenden, das der Foundry Agent Service verwaltet. Selbst wenn kosten- oder betriebliche Einfachheit die Ressourcenfreigabe motiviert, überwiegt das Risiko eines Zuverlässigkeitsereignisses, das sich auf nicht verwandte Workloadfeatures auswirkt, die potenziellen Einsparungen in den meisten Unternehmensszenarien.

Von Bedeutung

Wenn Sie workloadspezifische Daten aus Kosten- oder Betriebsgründen mit den Abhängigkeiten des Agents verknüpfen, interagieren Sie niemals direkt mit den vom System verwalteten Daten wie Sammlungen, Containern oder Indizes, die der Foundry Agent Service erstellt. Diese internen Implementierungsdetails sind nicht dokumentiert und können ohne vorherige Ankündigung geändert werden. Der direkte Zugriff kann den Agentdienst unterbrechen oder zu Datenverlust führen. Verwenden Sie immer die Datenebenen-APIs des Foundry Agent Service für die Datenmanipulation, und behandeln Sie die zugrunde liegenden Daten als undurchsichtig und nur monitorgeschützt.

Entwurf für mehrere Regionen

Diese Architektur verwendet Verfügbarkeitszonen für hohe Verfügbarkeit innerhalb einer einzelnen Azure-Region. Es ist keine Lösung mit mehreren Regionen. Es fehlen die folgenden kritischen Elemente, die für regionale Resilienz und Notfallwiederherstellung (DR) erforderlich sind:

Globales Eingangs- und Datenverkehrsrouting
DNS-Verwaltung für Failover
Datenreplikations- oder Isolationsstrategien in allen Regionen
Eine aktiv-aktive, aktiv-passive oder aktiv-kalte Bezeichnung
Regionale Failover- und Failbackprozesse zur Erfüllung der Ziele für wiederherstellungszeit (Recovery Time Objectives, RTOs) und Wiederherstellungspunkte (Recovery Point Objectives, RPOs)
Berücksichtigen der Verfügbarkeit von Regionen für Entwickleroberflächen, einschließlich des Azure AI Foundry-Portals und datenebenen-APIs

Wenn Ihre Workload Geschäftskontinuität erfordert, wenn ein regionaler Ausfall auftritt, müssen Sie zusätzliche Komponenten und betriebliche Prozesse über diese Architektur hinaus entwerfen und implementieren. Insbesondere müssen Sie den Lastenausgleich und failover auf jeder Architekturebene behandeln, einschließlich der folgenden Bereiche:

Erdungsdaten (Wissensspeicher)
Modellhosting- und Ableitungsendpunkte
Die Orchestrierungs- oder Agentebene
Benutzerorientierter UI-Datenverkehr und DNS-Einstiegspunkte

Sie müssen auch sicherstellen, dass Observability, Monitoring und Inhaltssicherheitskontrollen in allen Regionen betriebsbereit und konsistent bleiben.

Diese Basisarchitektur verfügt nicht über multiregionale Funktionen, sodass regionale Ausfälle wahrscheinlich zu einem Dienstverlust innerhalb Ihrer Workload führen.

Notfallwiederherstellung

Chatarchitekturen enthalten zustandsbehaftete Komponenten, sodass die DR-Planung unerlässlich ist. Diese Workloads erfordern in der Regel einen Speicher für aktive oder angehaltene Chatsitzungen. Sie benötigen außerdem Speicher für zusätzliche Daten, z. B. Dokumente oder Bilder, die Chatthreads hinzugefügt werden. Die Agent-Orchestrierungsebene kann auch den Status beibehalten, der für Unterhaltungsflüsse spezifisch ist. In dieser Architektur verwendet der Foundry Agent Service Azure Cosmos DB, Storage und AI Search, um den Betriebs- und Transaktionsstatus beizubehalten. Der Lebenszyklus und die Kopplung dieses Zustands über Komponenten hinweg bestimmen Ihre DR-Strategie und Wiederherstellungsvorgänge.

Stellen Sie für den Foundry Agent Service sicher, dass Sie alle Abhängigkeiten zu einem konsistenten Zeitpunkt wiederherstellen können. Dieser Ansatz trägt dazu bei, die Transaktionsintegrität über die drei externen Abhängigkeiten hinweg aufrechtzuerhalten.

Die folgenden Empfehlungen adressieren DR für jeden Dienst:

Azure Cosmos DB: Aktivieren Sie die fortlaufende Sicherung für die enterprise_memory Datenbank. Dieses Setup bietet Point-in-Time Restore (PITR) mit einem siebentägigen RPO, das Agentdefinitionen und Chatthreads enthält. Testen Sie ihren Wiederherstellungsvorgang regelmäßig, um sicherzustellen, dass er Ihren RTO erfüllt und dass die wiederhergestellten Daten für den Agentdienst verfügbar bleiben. Stellen Sie immer dasselbe Konto und dieselbe Datenbank wieder her.
KI-Suche: DIE KI-Suche verfügt nicht über integrierte Wiederherstellungsfunktionen und unterstützt keine direkte Indexmanipulation. Wenn Datenverlust oder Beschädigung auftritt, müssen Sie sich an den Microsoft-Support wenden, um Unterstützung bei der Indexwiederherstellung zu erhalten. Diese Einschränkung kann sich erheblich auf Ihre RTO auswirken. Wenn Ihre Chat-UI Dateiuploads nicht unterstützt und Sie keine Agents haben, die statische Dateien als Wissen verwenden, benötigen Sie möglicherweise keinen DR-Plan für die KI-Suche.

Bewahren Sie eine separate, regelmäßig aktualisierte Quelle der Wahrheit für Ihr Unternehmenserkenntnisse auf. Diese Übung stellt sicher, dass Sie Indizes bei Bedarf neu erstellen können.
Lagerung: Wenn Sie über ein georedundantes Speicherkonto verfügen, verwenden Sie das vom Kunden verwaltete Failover für Blobcontainer, die der Foundry Agent Service verwendet. Mit diesem Setup können Sie ein Failover während eines regionalen Ausfalls initiieren. Wenn Sie nur zonenredundanten Speicher verwenden, wenden Sie sich an den Microsoft-Support, um Daten wiederherzustellen. Dieser Vorgang kann Ihre RTO erweitern. Wie bei der KI-Suche benötigen Sie möglicherweise keinen DR-Plan für Blobcontainer, wenn Ihre Chat-UI Dateiuploads nicht unterstützt und Sie keine Agents haben, die statische Dateien als Wissen verwenden.
Transaktionskonsistenz: Wenn der Zustandsspeicher in Ihrer Workload auf Azure AI-Agent-IDs wie Thread-IDs oder Agent-IDs verweist, koordinieren Sie die Wiederherstellung über alle relevanten Datenspeicher hinweg. Das Wiederherstellen einer Teilmenge von Abhängigkeiten kann zu verwaisten oder inkonsistenten Daten führen. Entwerfen Sie Ihre DR-Prozesse, um die referenzielle Integrität zwischen Ihrer Workload und dem Status des Agentdiensts aufrechtzuerhalten.
Agentdefinitionen und -konfiguration: Definieren Sie Agents als Code. Store-Agentdefinitionen, Verbindungen, Systemaufforderungen und Parameter in der Quellcodeverwaltung. Mit dieser Methode können Sie Agents aus einer bekannten guten Konfiguration erneut bereitstellen, wenn Sie die Orchestrierungsebene verlieren. Vermeiden Sie nicht nachverfolgte Änderungen an der Agentkonfiguration über das AI Foundry-Portal oder Datenebenen-APIs. Durch diesen Ansatz wird sichergestellt, dass Ihre bereitgestellten Agents reproduzierbar bleiben.

Bevor Sie zur Produktion wechseln, erstellen Sie ein Wiederherstellungs-Runbook, das Fehler sowohl im anwendungseigenen Zustand als auch im Agent-besitzigen Zustand behandelt.

Sicherheit

Sicherheit bietet Sicherheitsmaßnahmen gegen bewusste Angriffe und den Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Sicherheit.

Diese Architektur erweitert die Sicherheitsbasis, die in der grundlegenden Referenzarchitektur für Azure AI Foundry-Chats eingerichtet wurde. Der Hauptunterschied ist das Hinzufügen eines Netzwerksicherheitsperimeters neben dem Identitätsperimeter aus der grundlegenden Architektur. Aus Netzwerksicht ist Das Anwendungsgateway die einzige ressource, die über das Internet verfügbar gemacht wird. Die Chat-UI-Anwendung wird benutzern zur Verfügung gestellt. Aus Identitätsperspektive sollte die Chat-UI Anforderungen authentifizieren und autorisieren. Verwenden Sie verwaltete Identitäten, wenn möglich, um Anwendungen bei Azure-Diensten zu authentifizieren.

In diesem Abschnitt werden Netzwerk- und Sicherheitsaspekte für die Schlüsseldrehung und die Feinabstimmung des Azure OpenAI-Modells beschrieben.

Identitäts- und Zugriffsverwaltung

Diese Architektur verwendet in erster Linie vom System zugewiesene verwaltete Identitäten für die Dienst-zu-Dienst-Authentifizierung. Sie können auch vom Benutzer zugewiesene verwaltete Identitäten verwenden. Wenden Sie in beiden Fällen die folgenden Prinzipien an:

Isolieren Sie Identitäten nach Ressource und Funktion. Stellen Sie unterschiedliche verwaltete Identitäten für die folgenden Komponenten bereit:
- Das Azure AI Foundry-Konto
- Jedes Azure AI Foundry-Projekt
- Die Webanwendung
- Beliebiger benutzerdefinierter Orchestrator- oder Integrationscode
Weisen Sie einer Azure-Ressource nur eine Identität zu, wenn diese Ressource sich als Client bei einem anderen Azure-Dienst authentifizieren muss.
Verwenden Sie "Fit-for-purpose identity"-Typen. Verwenden Sie nach Möglichkeit Arbeitsauslastungsidentitäten für Anwendungen und Automatisierung, und verwenden Sie Agent-Identitäten für KI-Agents.

Zugriff auf Azure AI Foundry-Portalmitarbeiter

Wenn Sie Mitarbeiter in Azure AI Foundry-Projekte integrieren, weisen Sie die mindestberechtigungen zu, die für ihre Rolle erforderlich sind. Verwenden Sie Microsoft Entra-ID-Gruppen und rollenbasierte Zugriffssteuerung (RBAC), um die Trennung von Aufgaben zu erzwingen. Unterscheiden Sie beispielsweise Agententwickler von Datenwissenschaftlern, die Feinabstimmungsaufgaben ausführen. Beachten Sie jedoch die Einschränkungen und Risiken.

Das Azure AI Foundry-Portal führt viele Aktionen aus, indem die Identität des Diensts anstelle der Identität des Mitarbeiters verwendet wird. Daher können Mitarbeiter, die eingeschränkte RBAC-Rollen haben, Einblicke in vertrauliche Daten haben, z. B. Chatthreads, Agentdefinitionen und Konfiguration. Dieses KI Foundry-Portaldesign kann versehentlich Ihre gewünschten Zugriffsbeschränkungen umgehen und mehr Informationen als beabsichtigt verfügbar machen.

Um das Risiko eines nicht autorisierten Zugriffs zu verringern, beschränken Sie die Portalnutzung in Produktionsumgebungen auf Mitarbeiter, die über einen klaren betrieblichen Bedarf verfügen. Deaktivieren oder blockieren Sie für die meisten Mitarbeiter den Zugriff auf das Azure AI Foundry-Portal in der Produktion. Verwenden Sie stattdessen automatisierte Bereitstellungspipelinen und -infrastruktur als Code (IaC), um die Agent- und Projektkonfiguration zu verwalten.

Behandeln Sie das Erstellen neuer Projekte in einem Azure AI Foundry-Konto als privilegierte Aktion. Projekte, die über das Portal erstellt wurden, erben nicht automatisch Ihre etablierten Netzwerksicherheitskontrollen, z. B. private Endpunkte oder Netzwerksicherheitsgruppen (NSGs). Und neue Agents in diesen Projekten umgehen Ihren beabsichtigten Sicherheitsperimeter. Erzwingen Sie die Projekterstellung ausschließlich über Ihre kontrollierten, auditierbaren IaC-Prozesse.

Azure AI Foundry-Projektrollenzuweisungen und -verbindungen

Um den Foundry Agent Service im Standardmodus zu verwenden, muss das Projekt über Administratorberechtigungen für die Abhängigkeiten des Foundry Agent Service verfügen. Insbesondere muss die verwaltete Identität des Projekts über erhöhte Rollenzuweisungen für das Speicherkonto, die KI-Suche und das Azure Cosmos DB-Konto verfügen. Diese Berechtigungen bieten nahezu vollständigen Zugriff auf diese Ressourcen, einschließlich der Möglichkeit, Daten zu lesen, zu schreiben, zu ändern oder zu löschen. Um den Zugriff auf die geringsten Rechte aufrechtzuerhalten, isolieren Sie Ihre Arbeitsauslastungsressourcen von den Abhängigkeiten des Foundry Agent Service.

Alle Agents innerhalb eines einzelnen KI Foundry-Projekts verwenden dieselbe verwaltete Identität. Wenn Ihre Workload mehrere Agents verwendet, die Zugriff auf verschiedene Ressourcengruppen erfordern, müssen Sie mit dem Prinzip der geringsten Berechtigungen ein separates Azure AI Foundry-Projekt für jedes unterschiedliche Agent-Zugriffsmuster erstellen. Diese Trennung ermöglicht es Ihnen, nur die mindestens erforderlichen Berechtigungen der verwalteten Identität jedes Projekts zuzuweisen, wodurch das Risiko eines übermäßigen oder unbeabsichtigten Zugriffs reduziert wird.

Wenn Sie Verbindungen zu externen Ressourcen aus Azure AI Foundry herstellen, verwenden Sie die microsoft Entra ID-basierte Authentifizierung, falls verfügbar. Bei diesem Ansatz wird die Notwendigkeit beseitigt, vorfreigaben geheime Schlüssel beizubehalten. Beschränken Sie jede Verbindung so, dass nur das besitzereigene Projekt sie verwenden kann. Wenn mehrere Projekte Zugriff auf dieselbe Ressource benötigen, erstellen Sie in jedem Projekt eine separate Verbindung, anstatt eine einzelne Verbindung für alle Projekte freizulegen. Diese Vorgehensweise erzwingt strenge Zugriffsgrenzen und verhindert, dass zukünftige Projekte den Zugriff erben, den sie nicht benötigen.

Vermeiden Sie das Erstellen von Verbindungen auf Azure AI Foundry-Kontoebene. Diese Verbindungen gelten für alle aktuellen und zukünftigen Projekte im Konto. Sie können versehentlich breiten Zugriff auf Ressourcen gewähren, die geringsten Berechtigungsprinzipien verletzen und das Risiko einer nicht autorisierten Datenexposition erhöhen. Bevorzugen Sie nur Verbindungen auf Projektebene.

Vernetzung

Zusätzlich zum identitätsbasierten Zugriff erfordert diese Architektur die Netzwerkvertraulichkeit.

Das Netzwerkdesign umfasst die folgenden Sicherheitsvorkehrungen:

Ein einzelner, sicherer Einstiegspunkt für den gesamten Chat-UI-Datenverkehr, der die Angriffsfläche minimiert
Gefilterter Ausgehender und ausgehender Netzwerkdatenverkehr mithilfe einer Kombination aus NSGs, einer Webanwendungsfirewall, benutzerdefinierten Routen (UDRs) und Azure Firewall-Regeln
End-to-End-Verschlüsselung von Daten während der Übertragung mithilfe von TLS
Netzwerkdatenschutz mithilfe von privatem Link für alle Azure PaaS-Dienstverbindungen
Logische Segmentierung und Isolierung von Netzwerkressourcen mit dedizierten Subnetzen für jede Hauptkomponentengruppierung zur Unterstützung granularer Sicherheitsrichtlinien

Netzwerkflows

Die grundlegende App Service-Webanwendungsarchitektur beschreibt den eingehenden Fluss vom Benutzer zur Chat-UI und den Fluss von App Service zu Azure PaaS-Diensten. Dieser Abschnitt konzentriert sich auf Agentinteraktionen.

Wenn die Chat-UI mit dem in Azure AI Foundry bereitgestellten Agent kommuniziert, treten die folgenden Netzwerkflüsse auf:

Die vom App Service gehostete Chat-UI initiiert HTTPS-Anforderungen über einen privaten Endpunkt an den Azure AI Foundry-Datenebenen-API-Endpunkt.
Wenn der Agent auf Azure PaaS-Dienste wie Dienstabhängigkeiten, benutzerdefinierte Wissensspeicher oder benutzerdefinierte Tools zugreift, sendet er HTTPS-Anforderungen aus dem delegierten Subnetz an die privaten Endpunkte dieser Dienste.
Wenn der Agent auf Ressourcen außerhalb des virtuellen Netzwerks zugreift, einschließlich internetbasierter APIs oder externer Dienste, wird er gezwungen, diese HTTPS-Anforderungen vom delegierten Subnetz über die Azure-Firewall weiterzuleiten.

Private Endpunkte dienen als kritische Sicherheitskontrolle in dieser Architektur, indem sie die identitätsbasierte Sicherheit ergänzen.

Ingress zu Azure AI Foundry

Diese Architektur deaktiviert den öffentlichen Zugriff auf die Azure AI Foundry-Datenebene, indem nur Datenverkehr über einen privaten Link für Azure AI Foundry zugelassen wird. Sie können auf einen Großteil des Azure AI Foundry-Portals über die Portalwebsite zugreifen, aber alle Funktionen auf Projektebene erfordern Netzwerkzugriff. Das Portal basiert auf den Datenebenen-APIs Ihres KI Foundry-Kontos, die nur über private Endpunkte erreichbar sind. Entwickler und Datenwissenschaftler müssen daher über ein Sprungfeld, ein virtuelles Peer-Netzwerk oder eine ExpressRoute- oder Standort-zu-Standort-VPN-Verbindung auf das Portal zugreifen.

Alle programmgesteuerten Interaktionen mit der Agentdatenebene, z. B. aus der Webanwendung oder aus externem Orchestrierungscode beim Aufrufen von Modellferencing, müssen auch diese privaten Endpunkte verwenden. Private Endpunkte werden auf Kontoebene und nicht auf Projektebene definiert. Daher teilen alle Projekte innerhalb des Kontos denselben Satz von Endpunkten. Sie können den Netzwerkzugriff nicht auf Projektebene segmenten, und alle Projekte teilen die gleiche Netzwerkexposition.

Um diese Konfiguration zu unterstützen, richten Sie DNS für die folgenden Azure AI Foundry-FQDN-API-Endpunkte ein:

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

Das folgende Diagramm zeigt, wie ein KI-Entwickler eine Verbindung über Azure Bastion mit einem Virtuellen Computer (VM)-Sprungfeld herstellt. Über dieses Sprungfeld kann der Autor über einen privaten Endpunkt im selben Netzwerk auf das Projekt im Azure AI Foundry-Portal zugreifen.

Steuern des Datenverkehrs aus dem Subnetz des Azure AI Foundry-Agents

Diese Architektur leitet den gesamten ausgehenden (Ausgehenden) Netzwerkdatenverkehr von der Foundry Agent Service-Funktion über ein delegiertes Subnetz in Ihrem virtuellen Netzwerk weiter. Dieses Subnetz dient als einziger Ausgangspunkt für die erforderlichen drei Dienstabhängigkeiten des Agents und alle externen Wissensquellen oder Toolverbindungen, die der Agent verwendet. Dieses Design trägt dazu bei, Datenexfiltrationsversuche innerhalb der Orchestrierungslogik zu reduzieren.

Indem Sie diesen Ausgangspfad erzwingen, erhalten Sie volle Kontrolle über ausgehenden Datenverkehr. Sie können präzise NSG-Regeln, benutzerdefiniertes Routing und DNS-Steuerelement auf den gesamten Agentdatenverkehr anwenden, der den Dienst verlässt.

Der Agentdienst verwendet die DNS-Konfiguration des virtuellen Netzwerks, um private Endpunkteinträge und erforderliche externe FQDNs aufzulösen. Mit diesem Setup wird sichergestellt, dass die Anforderungen des Agents DNS-Protokolle generieren, die Überwachung und Problembehandlung unterstützen.

Die an den Agentausgangssubnetz angefügte NSG blockiert den gesamten eingehenden Datenverkehr, da kein legitimer Eingang erfolgen sollte. Ausgehende NSG-Regeln ermöglichen nur den Zugriff auf private Endpunktsubnetze innerhalb des virtuellen Netzwerks und den TCP-Port 443 (Transmission Control Protocol) für internetgebundenen Datenverkehr. Die NSG verweigert allen anderen Datenverkehr.

Um den Internetdatenverkehr weiter einzuschränken, wendet diese Architektur ein UDR auf das Subnetz an, das den gesamten HTTPS-Datenverkehr über die Azure Firewall leitet. Die Firewall steuert, welche FQDNs der Agent über HTTPS-Verbindungen erreichen kann. Wenn der Agent z. B. nur auf das Grounding mit öffentlichen Bing-APIs zugreifen muss, konfigurieren Sie Azure Firewall so, dass Datenverkehr auf api.bing.microsoft.com Port 443 von diesem Subnetz aus zulässt. Alle anderen ausgehenden Ziele werden verweigert.

Segmentierung und Sicherheit des virtuellen Netzwerks

Diese Architektur segmentiert das virtuelle Netzwerk, indem jede Hauptkomponentengruppe ihrem eigenen Subnetz zugewiesen wird. Jedes Subnetz verfügt über einen dedizierten NSG, der den eingehenden und ausgehenden Datenverkehr auf das beschränkt, was die Komponente erfordert.

In der folgenden Tabelle sind die NSG- und Firewallkonfigurationen für jedes Subnetz zusammengefasst.

Verwendungs- oder Subnetzname	Eingehender Datenverkehr (NSG)	Ausgehender Datenverkehr (NSG)	UDR zu Firewall	Firewallausgangsregeln
Private Endpunkte `snet-privateEndpoints`	Virtuelles Netzwerk	Kein Datenverkehr zulässig	Ja	Kein Datenverkehr zulässig
Anwendungs-Gateway `snet-appGateway`	IP-Adressen der Chat-UI-Benutzerquelle, z. B. das öffentliche Internet und erforderliche Quellen für den Dienst	Subnetz des privaten Endpunkts und erforderliche Elemente für den Dienst	Nein	-
App-Dienst `snet-appServicePlan`	Kein Datenverkehr zulässig	Private Endpunkte und Azure Monitor	Ja	Zu Azure Monitor
Gießerei-Agentendienst `snet-agentsEgress`	Kein Datenverkehr zulässig	Private Endpunkte und das Internet	Ja	Nur öffentliche FQDNs, die Ihren Agents die Verwendung gestatten
VMs für Sprungboxen `snet-jumpBoxes`	Azure Bastion-Subnetz	Private Endpunkte und das Internet	Ja	Nach Bedarf durch den virtuellen Computer
Build-Agents `snet-buildAgents`	Azure Bastion-Subnetz	Private Endpunkte und das Internet	Ja	Nach Bedarf durch den virtuellen Computer
Azure Bastion `AzureBastionSubnet`	Siehe NSG-Zugriff und Azure Bastion	Siehe NSG-Zugriff und Azure Bastion	Nein	-
Azure Firewall `AzureFirewallSubnet` `AzureFirewallManagementSubnet`	Keine NSG	Keine NSG	Nein	-

Dieser Entwurf verweigert explizit den gesamten anderen Datenverkehr, entweder über NSG-Regeln oder standardmäßig in Azure Firewall.

Wenn Sie die Netzwerksegmentierung und Sicherheit in dieser Architektur implementieren, befolgen Sie die folgenden Empfehlungen:

Stellen Sie einen Azure DDoS Protection-Plan auf der öffentlichen IP-Adresse des Anwendungsgateways bereit, um volumetrische Angriffe zu mindern.
Fügen Sie eine NSG an jedes Subnetz an, das es unterstützt. Wenden Sie die strengsten Regeln an, die möglich sind, ohne die erforderliche Funktionalität zu unterbrechen.
Wenden Sie die erzwungene Tunnelung auf alle unterstützten Subnetze an, damit Ihre Ausgangsfirewall den gesamten ausgehenden Datenverkehr überprüfen kann. Verwenden Sie erzwungene Tunneling auch in Subnetzen, in denen Sie keinen Ausgang erwarten. Diese Methode fügt eine detaillierte Verteidigungsmaßnahme hinzu, die vor absichtlichem oder versehentlichem Missbrauch des Subnetzes schützt.

Governance durch Richtlinie

Verwenden Sie Azure-Richtlinien und Netzwerkrichtlinien, um die Sicherheitsgrundsätze Ihrer Workload anzupassen, um sicherzustellen, dass alle Workloadressourcen Ihren Anforderungen entsprechen. Die Plattformautomatisierung durch Richtlinien reduziert das Risiko einer Sicherheitskonfigurationsabweichung und reduziert manuelle Überprüfungsaktivitäten.

Erwägen Sie die Implementierung der folgenden Arten von Sicherheitsrichtlinien, um Ihre Architektur zu stärken:

Deaktivieren Sie schlüsselbasierte oder andere lokale Authentifizierungsmethoden in Diensten wie Azure AI-Diensten und Key Vault.
Erfordert eine explizite Konfiguration von Netzwerkzugriffsregeln, privaten Endpunkten und NSGs.
Erfordert Verschlüsselung, z. B. vom Kunden verwaltete Schlüssel.
Einschränken der Ressourcenerstellung, z. B. Einschränken von Regionen oder Ressourcentypen.

Kostenoptimierung

Die Kostenoptimierung konzentriert sich auf Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Kostenoptimierung.

Diese Azure-Preisschätzung bietet ein Preisbeispiel für diese Architektur. Dieses Beispiel enthält nur die Komponenten in dieser Architektur. Passen Sie sie daher an Ihre Verwendung an. Die teuersten Komponenten im Szenario sind Azure Cosmos DB, AI Search und DDoS Protection. Weitere wichtige Kosten sind die Berechnung der Chat-UI und das Anwendungsgateway. Optimieren Sie diese Ressourcen, um Kosten zu senken.

Gießerei-Agentendienst

Wenn Sie die Standardbereitstellung verwenden, müssen Sie die Abhängigkeiten des Diensts in Ihrem eigenen Azure-Abonnement bereitstellen und verwalten.

Die folgenden Empfehlungen erläutern, wie Die Kosten für diese erforderlichen Dienste optimiert werden:

Der Foundry Agent Service verwaltet die Anforderungseinheitszuordnung (RU) für Azure Cosmos DB. Um langfristige Kosten zu reduzieren, kaufen Sie reservierte Kapazität für Azure Cosmos DB. Richten Sie Reservierungen mit der erwarteten Nutzungsdauer und dem Erwarteten Volumen aus. Denken Sie daran, dass reservierte Kapazität vorausgeht und keine Flexibilität erfordert, wenn sich die Nutzungsmuster Ihrer Workload erheblich ändern.
Wenn Ihr Chatszenario keine Dateiuploads erfordert, schließen Sie dieses Feature in Ihrer Anwendung aus. Wenden Sie in diesem Fall die folgenden Konfigurationsänderungen an:
- Verwenden Sie eine lokal redundante Speicherebene (LRS) für das Speicherkonto.
- Konfigurieren Sie die KI-Suche mit einem einzelnen Replikat anstelle der empfohlenen drei Replikate.
Löschen Sie regelmäßig nicht verwendete Agents und die zugehörigen Threads mithilfe der SDK- oder REST-APIs. Veraltete Agents und Threads verbrauchen weiterhin Speicher und können die Kosten für Azure Cosmos DB, Storage und AI Search erhöhen.
Deaktivieren Sie Features für abhängige Ressourcen, die Ihre Workload nicht benötigt, z. B. die folgenden Features:
- Der semantische Rangierer in der KI-Suche
- Die Gateway- und Multiregion-Schreibfunktionen in Azure Cosmos DB
Um regionsübergreifende Bandbreitengebühren zu vermeiden, stellen Sie Azure Cosmos DB, Storage und AI Search in derselben Azure-Region wie foundry Agent Service bereit.
Vermeiden Sie das Colocating workloadspezifischer Daten in den gleichen Azure Cosmos DB- oder AI Search-Ressourcen, die der Foundry Agent Service verwendet. In einigen Fällen können Sie diese Ressourcen freigeben, um nicht verwendete Kapazität in RUs oder Sucheinheiten zu reduzieren, wodurch die Kosten reduziert werden. Berücksichtigen Sie die Ressourcenfreigabe nur nach einer gründlichen Risikobewertung für Zuverlässigkeit, Sicherheit und Leistungsabwärmung.

Agentenwissen und -tools

Der Foundry-Agent-Dienst führt Agentlogik auf unbestimmte Weise aus. Er kann jeden verbundenen Wissensspeicher, jedes Tool oder einen anderen Agent für jede Anforderung aufrufen, auch wenn diese Ressource für die Benutzerabfrage nicht relevant ist. Dieses Verhalten kann zu unnötigen Aufrufen externer APIs oder Datenquellen führen, die Kosten für jede Transaktion erhöhen und unvorhersehbare Nutzungsmuster einführen, die die Budgetprognose erschweren.

Um Kosten zu steuern und vorhersagbares Verhalten aufrechtzuerhalten, wenden Sie die folgenden Strategien an:

Verbinden Sie nur die Wissensspeicher, Tools oder Agents, die wahrscheinlich mit den meisten Agentaufrufen verwendet werden. Vermeiden Sie das Verbinden von Ressourcen, die selten benötigt werden oder für jeden Anruf hohe Kosten verursachen, es sei denn, sie sind unerlässlich.
Entwerfen Und verfeinern Sie die Systemaufforderung sorgfältig, um den Agent anzuweisen, unnötige oder redundante externe Anrufe zu minimieren. Die Systemaufforderung sollte den Agent so leiten, dass nur die relevantesten Verbindungen für jede Anforderung verwendet werden.
Verwenden Sie die Azure AI Foundry-Telemetrie, um zu überwachen, auf welche externen APIs, Wissensspeicher oder Tools der Agent zugreift, wie häufig darauf zugegriffen wird, und welche Kosten anfallen. Überprüfen Sie diese Telemetrie regelmäßig, um unerwartete Nutzungsmuster oder Kostenspitzen zu identifizieren und Ihre Systemaufforderung nach Bedarf anzupassen.
Beachten Sie, dass ein unbestimmter Aufruf die Kostenprognose schwierig machen kann, insbesondere bei der Integration mit getakteten APIs. Wenn Sie vorhersehbare Kosten benötigen, sollten Sie den Orchestrator selbst hosten, indem Sie deterministischen Code verwenden.

Azure OpenAI-Modelle

Modellbereitstellungen in Azure AI Foundry verwenden den MaaS-Ansatz. Die Kosten hängen in erster Linie von der Nutzungs- oder Vorbereitstellungszuordnung ab.

Um die Verbrauchsmodellkosten in dieser Architektur zu steuern, verwenden Sie eine Kombination der folgenden Ansätze:

Steuern von Clients. Clientanforderungen fördern die meisten Kosten in einem Verbrauchsmodell, sodass die Steuerung des Agentverhaltens von entscheidender Bedeutung ist.

Um die unnötige Nutzung zu reduzieren, führen Sie die folgenden Aktionen aus:
- Genehmigen sie alle Modellkunden. Stellen Sie Modelle nicht auf eine Weise zur Verfügung, die uneingeschränkten Zugriff zulässt.
- Erzwingen Sie Einschränkungen für Tokenbeschränkungen, z max_tokens . B. durch max_completions Agentlogik. Dieses Steuerelement ist nur in selbst gehosteter Orchestrierung verfügbar. Der Foundry Agent-Dienst unterstützt diese Funktionalität nicht.
- Optimieren Sie die Eingabe- und Antwortlänge der Eingabeaufforderung. Längere Aufforderungen verbrauchen mehr Token, was die Kosten erhöht. Fordert auf, dass kein ausreichender Kontext zur Verringerung der Modelleffizienz vorhanden ist. Erstellen Sie präzise Eingabeaufforderungen, die genügend Kontext bereitstellen, damit das Modell eine nützliche Antwort generieren kann. Stellen Sie sicher, dass Sie den Grenzwert der Antwortlänge optimieren.
  
  Diese Steuerungsebene ist nur in selbst gehosteter Orchestrierung verfügbar. Der Foundry Agent Service bietet nicht genügend Konfiguration, um diese Funktionalität zu unterstützen.
Wählen Sie das richtige Modell für den Agent aus. Wählen Sie das am wenigsten teure Modell aus, das den Anforderungen Ihres Agenten entspricht. Vermeiden Sie höhere Kostenmodelle, es sei denn, sie sind unerlässlich. Beispielsweise verwendet die Referenzimplementierung GPT-4o anstelle eines teureren Modells und erzielt ausreichende Ergebnisse.
Überwachen und Verwalten der Nutzung. Verwenden Sie Microsoft Cost Management und Modell telemetrie, um die Tokennutzung nachzuverfolgen, Budgets festzulegen und Warnungen für Anomalien zu erstellen. Überprüfen Sie die Verwendungsmuster regelmäßig, und passen Sie Kontingente oder den Clientzugriff nach Bedarf an. Weitere Informationen finden Sie unter "Planen und Verwalten von Kosten für Azure AI Foundry".
Verwenden Sie den richtigen Bereitstellungstyp. Verwenden Sie pay-as-you-go Preise für unvorhersehbare Workloads, und wechseln Sie zum bereitgestellten Durchsatz, wenn die Nutzung stabil und vorhersehbar ist. Kombinieren Sie beide Optionen, wenn Sie einen zuverlässigen Basisplan einrichten.
Schränken Sie die Nutzung des Playgrounds ein. Um ungeplante Produktionskosten zu vermeiden, beschränken Sie die Verwendung des Azure AI Foundry-Playgrounds nur auf Vorproduktionsumgebungen.
Planen Sie die Feinabstimmung und die Bildgenerierung sorgfältig. Diese Features weisen unterschiedliche Abrechnungsmodelle auf. Sie werden pro Stunde oder pro Batch abgerechnet. Planen Sie die Nutzung, um die Abrechnungsintervalle auszurichten und Abfälle zu vermeiden.

Netzwerksicherheitsressourcen

Für diese Architektur ist Azure Firewall als Ausgangspunkt erforderlich. Verwenden Sie zum Optimieren der Kosten die Standardebene der Azure Firewall, es sei denn, die restlichen Workloadkomponenten erfordern erweiterte Features. Höhere Ebenen fügen Kosten hinzu, verwenden Sie sie also nur, wenn Sie deren Funktionen benötigen.

Wenn Ihre Organisation Azure-Landezonen verwendet, sollten Sie die Verwendung von freigegebenen Firewall- und verteilten DDoS-Ressourcen (Denial of Service) in Betracht ziehen, um Kosten zu verzögern oder zu reduzieren. Workloads mit ähnlichen Sicherheits- und Leistungsanforderungen können von gemeinsam genutzten Ressourcen profitieren. Stellen Sie sicher, dass freigegebene Ressourcen keine Sicherheits- oder Betriebsrisiken darstellen. Diese Architektur, die in einer Azure-Zielzone bereitgestellt wird, verwendet gemeinsam genutzte Ressourcen.

Operative Exzellenz

„Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie unter Checkliste für die Designüberprüfung zur betrieblichen Exzellenz.

Der folgende Leitfaden zur betrieblichen Exzellenz enthält nicht die Front-End-Anwendungselemente, die mit der grundlegenden hoch verfügbaren, zonenredundanten Webanwendungsarchitektur identisch bleiben.

Wenn Sie Ihre Experimentier-, Test- und Produktionsumgebungen planen, richten Sie unterschiedliche und isolierte KI Foundry-Ressourcen ein, einschließlich Abhängigkeiten.

Agent-Compute

Microsoft verwaltet die serverlose Computeplattform für AZURE AI-Agent-REST-APIs und die Orchestrierungsimplementierungslogik vollständig. Eine selbst gehostete Orchestrierung bietet mehr Kontrolle über Laufzeiteigenschaften und Kapazität, aber Sie müssen die Day-2-Vorgänge für diese Plattform direkt verwalten. Bewerten Sie die Einschränkungen und Verantwortlichkeiten Ihres Ansatzes, um zu verstehen, welche Täglich-2-Vorgänge Sie implementieren müssen, um Ihre Orchestrierungsebene zu unterstützen.

In beiden Ansätzen müssen Sie den Zustandsspeicher verwalten, z. B. Chatverlauf und Agentkonfiguration für Haltbarkeit, Sicherung und Wiederherstellung.

Überwachung

Ähnlich wie bei der grundlegenden Architektur sind Diagnosedaten aller Dienste so konfiguriert, dass sie an den Log Analytics-Arbeitsbereich Ihrer Workload gesendet werden. Alle Dienste außer App Service erfassen alle Protokolle. In der Produktion müssen Sie möglicherweise nicht alle Protokolle erfassen. Die Chat-UI-Anwendung erfordert AppServiceHTTPLogsbeispielsweise möglicherweise nur , , AppServiceConsoleLogs, , AppServiceAppLogs, , AppServicePlatformLogsund AppServiceAuthenticationLogs. Optimieren Sie Protokolldatenströme auf Ihre betrieblichen Anforderungen.

Bewerten Sie benutzerdefinierte Warnungen, z. B. benutzerdefinierte Warnungen in den Azure Monitor-Basiswarnungen, für die Ressourcen in dieser Architektur. Berücksichtigen Sie die folgenden Warnungen:

Überwachen Sie die Verwendung von Token für Ihre Modellbereitstellungen. In dieser Architektur verfolgt Azure AI Foundry die Tokennutzung durch die Integration in Application Insights.

Ihre Sprungfelder und Build-Agent-VMs befinden sich an einem hochgradig privilegierten Standort, der diesen virtuellen Computern eine Netzwerklinie für die Datenebene aller Komponenten in Ihrer Architektur bereitstellt. Stellen Sie sicher, dass diese virtuellen Computer genügend Protokolle ausgeben, um zu verstehen, wann sie verwendet werden, wer sie verwendet und welche Aktionen ausgeführt werden.

Agent-Versionsverwaltung und Lebenszyklus

Behandeln Sie jeden Agent als eigenständige bereitstellungsfähige Einheit innerhalb Ihrer Chat-Workload, es sei denn, Sie entwerfen Ihre Anwendung speziell so, dass Agents zur Laufzeit dynamisch erstellt und gelöscht werden. Diese Agents verfügen über Lebenszyklusverwaltungsanforderungen wie andere Microservices in Ihrer Workload.

Um Dienstunterbrechungen zu verhindern, stellen Sie die sichere und kontrollierte Agentbereitstellung sicher, indem Sie die folgenden Ansätze implementieren:

Definieren Sie Agents als Code. Speichern Sie immer Agentdefinitionen, Verbindungen, Systemaufforderungen und Konfigurationsparameter in der Quellcodeverwaltung. Diese Praxis sorgt für Rückverfolgbarkeit und Reproduzierbarkeit. Vermeiden Sie nicht nachverfolgte Änderungen über das Azure AI Foundry-Portal.
Automatisieren Sie die Agentbereitstellung. Verwenden Sie die Pipelines für kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) Ihrer Workload. Verwenden Sie das Azure AI Agent SDK zum Erstellen, Testen und Bereitstellen von Agentänderungen von Ihren mit dem Netzwerk verbundenen Build-Agents.

Bevorzugen Sie Agentpipelinen, die Sie unabhängig für kleine, inkrementelle Änderungen bereitstellen können. Stellen Sie jedoch sicher, dass die Pipelines genügend Flexibilität bieten, um sie zusammen mit Ihrem Anwendungscode bereitzustellen, wenn Sie koordinierte Updates benötigen. Um diese Methode zu unterstützen, koppeln Sie Ihren Chat-UI-Code und Ihre Chat-Agents lose, sodass Änderungen an einer Komponente keine gleichzeitigen Änderungen an der anderen erfordern.
Testen Sie vor der Produktion. Überprüfen Des Agentverhaltens, Aufforderungen und Verbindungen in Vorproduktionsumgebungen. Verwenden Sie eine Kombination aus automatisierten und manuellen Tests, um Regressionen, Sicherheitsprobleme und unbeabsichtigte Änderungen des Agentverhaltens abzufangen.

Agents, die im Foundry Agent Service definiert sind, verhalten sich nicht deterministisch, sodass Sie bestimmen müssen, wie Sie Ihr gewünschtes Qualitätsniveau messen und verwalten können. Erstellen und ausführen Sie eine Testsuite, die nach idealen Antworten auf realistische Benutzerfragen und Szenarien sucht.
Versions- und Nachverfolgen von Agents. Weisen Sie jedem Agent eindeutige Versionsbezeichner zu. Verwalten Sie Datensätze, welche Agentversionen aktiv sind, sowie deren Abhängigkeiten wie Modelle, Datenquellen und Tools. Bevorzugen Sie die Bereitstellung neuer Agentversionen zusammen mit vorhandenen Versionen, um progressives Rollout, Rollback und kontrollierte Migration von Benutzern oder Sitzungen zu ermöglichen.
Planen sie einen Failback. Azure AI Foundry bietet keine integrierte Unterstützung für blaugrüne oder canarybasierte Bereitstellungen von Agents. Wenn Sie diese Bereitstellungsmuster benötigen, implementieren Sie vor der Agent-API eine Routingebene, z. B. ein API-Gateway oder einen benutzerdefinierten Router. Mit dieser Routingebene können Sie den Datenverkehr inkrementell zwischen Agentversionen verschieben, die Auswirkungen überwachen und bei Bedarf eine vollständige Umstellung durchführen.
Entfernen des Koordinaten-Agents. Wenn Sie Agents entfernen, koordinieren Sie den Prozess mit den Anforderungen für die Zustandsverwaltung und die Benutzerfreundlichkeit Ihrer Anwendung. Behandeln Sie aktive Chatsitzungen entsprechend. Abhängig von den funktionalen Anforderungen Ihrer Workload können Sie Sitzungen migrieren, Benutzer an die alte Agentversion anheften oder benutzer zum Starten neuer Sitzungen auffordern.

Leistungseffizienz

Die Leistungseffizienz bezieht sich auf die Fähigkeit Ihrer Workload, die Anforderungen der Benutzer effizient zu erfüllen. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Leistungseffizienz.

In diesem Abschnitt werden die Leistungseffizienz für KI-Suche, Modellbereitstellungen und Azure AI Foundry behandelt.

Leistungseffizienz in der KI-Suche

Im Foundry Agent Service steuern Sie nicht die spezifischen Abfragen, die an Ihre Indizes gesendet werden, da Agents codelos sind. Um die Leistung zu optimieren, konzentrieren Sie sich auf das, was Sie im Index steuern können. Beobachten Sie, wie Ihr Agent den Index in der Regel abfragt, und wenden Sie Anleitungen an, um die Leistung in der KI-Suche zu analysieren und zu optimieren.

Wenn die Indexserveroptimierung allein nicht alle Engpässe behebt, sollten Sie die folgenden Optionen in Betracht ziehen:

Ersetzen Sie die direkte Verbindung mit der KI-Suche durch eine Verbindung mit einer API, die Sie besitzen. Diese API kann Code implementieren, der für die Abrufmuster Ihres Agents optimiert ist.
Entwerfen Sie die Orchestrierungsebene neu, um die selbst gehostete Alternative zu verwenden, damit Sie Abfragen in Ihrem eigenen Orchestratorcode definieren und optimieren können.

Leistungseffizienz in Modellbereitstellungen

Ermitteln Sie, ob Ihre Anwendung einen bereitgestellten Durchsatz benötigt oder das freigegebene Modell (Verbrauchsmodell) verwenden kann. Der bereitgestellte Durchsatz bietet reservierte Kapazität und vorhersehbare Latenz, was für Produktionsworkloads mit strengen Zielen auf Dienstebene wichtig ist. Das Verbrauchsmodell bietet Best-Effort-Service und kann unter lauten Nachbareffekten leiden.
Überwachen Sie die bereitstellungsverwaltete Nutzung , um eine Über- oder Unterbereitstellung zu vermeiden.
Wählen Sie ein Unterhaltungsmodell aus, das Ihre Anforderungen an die Ableitungslatenz erfüllt.
Stellen Sie Modelle in derselben Datenregion wie Ihre Agents bereit, um die Netzwerklatenz zu minimieren.

Leistung des Azure AI-Agents

Azure AI-Agents werden auf einem serverlosen Compute-Back-End ausgeführt, das keine benutzerdefinierte Leistungsoptimierung unterstützt. Sie können die Leistung jedoch weiterhin über den Agententwurf verbessern:

Minimieren Sie die Anzahl der Wissensspeicher und Tools, die mit Ihrem Chat-Agent verbunden sind. Jede zusätzliche Verbindung erhöht möglicherweise die Gesamtlaufzeit für einen Agent-Aufruf, da der Agent möglicherweise alle konfigurierten Ressourcen für jede Anforderung aufruft.
Verwenden Sie Azure Monitor und Application Insights, um Agent-Aufrufzeiten, Tool- und Wissensspeicherlatenzen und Fehlerraten nachzuverfolgen. Überprüfen Sie diese Telemetrie regelmäßig, um langsame Kenntnisse oder Toolverbindungen zu identifizieren.
Designsystem fordert den Agent auf, Verbindungen effizient zu verwenden. Weisen Sie beispielsweise den Agent an, externe Wissensspeicher nur bei Bedarf abzufragen oder redundante Toolaufrufe zu vermeiden.
Überwachen Sie auf Dienstgrenzwerte oder Kontingente, die sich auf die Leistung während der Spitzenauslastung auswirken können. Achten Sie auf Drosselungsindikatoren wie HTTP 429- oder 503-Antworten, auch wenn serverlose Compute-Skalierungen automatisch skaliert werden.

Bereitstellen dieses Szenarios

Um diese Referenzimplementierung bereitzustellen und auszuführen, befolgen Sie das Bereitstellungshandbuch in der Basisreferenzimplementierung des Foundry Agent Service-Chats.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautoren:

Rob Bagby | Prinzipalinhaltsentwickler – Azure Patterns & Practices
Chad Kittel | Principal Software Engineer – Azure Patterns & Practices

Andere Mitwirkende:

Raouf Aliouat | Senior Software Engineer
Freddy Ayala | Cloud-Lösungsarchitekt
Prabal Deb | Hauptsoftwareingenieur
Ritesh Modi | Hauptsoftwareingenieur
Ryan Pfalz | Senior Technical Program Manager

Um nicht-öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächster Schritt

Geplante Azure AI Foundry-Chatarchitektur in einer Azure-Zielzone

Eine Azure Well-Architected Framework-Perspektive auf AI-Workloads in Azure
Azure OpenAI
Azure OpenAI-Modelle
Inhaltsfilterung