Baseline OpenAI End-to-End-Chat-Referenzarchitektur

Chatanwendungen für Unternehmen können Mitarbeiter*innen durch dialogorientierte Interaktionen unterstützen. Dies gilt insbesondere aufgrund der kontinuierlichen Weiterentwicklung von Sprachmodellen, wie den GPT-Modellen von OpenAI und den LLaMA-Modellen von Meta. Diese Chatanwendungen bestehen aus einer Chat-Benutzeroberfläche (UI), Datenrepositorys mit domänenspezifischen Informationen, die für die Anfragen der Benutzer*innen relevant sind, Sprachmodellen, die aus den domänenspezifischen Daten eine relevante Antwort erzeugen, und einem Orchestrator, der die Interaktion zwischen diesen Komponenten überwacht.

Dieser Artikel bietet eine Basisarchitektur für die Erstellung und Bereitstellung von Unternehmens-Chatanwendungen, die Azure OpenAI Service-Sprachmodelle verwenden. Die Architektur nutzt den Azure Machine Learning Prompt Flow, um ausführbare Flows zu erstellen. Diese ausführbaren Flows orchestrieren den Workflow von eingehenden Prompts bis hin zu Datenspeichern, um Basisdaten für die Sprachmodelle sowie andere erforderliche Python-Logik abzurufen. Der ausführbare Flow wird auf einem Machine Learning-Computecluster hinter einem verwalteten Onlineendpunkt bereitgestellt.

Das Hosting der benutzerdefinierten Chat-Benutzeroberfläche (UI) folgt den grundlegenden Richtlinien für die Webanwendung für App-Dienste für die Bereitstellung einer sicheren, zonenredundanten und hochverwendenden Webanwendung in Azure-App Services. In dieser Architektur kommuniziert App Service mit der Azure Platform as a Service (PaaS)-Lösung durch virtuelle Netzwerkintegration über private Endpunkte. Der Chat UI App Service kommuniziert mit dem verwalteten Onlineendpunkt für den Flow über einen privaten Endpunkt. Der öffentliche Zugang zum Machine Learning-Arbeitsbereich ist deaktiviert.

Der Machine Learning-Arbeitsbereich ist mit verwalteter virtueller Netzwerkisolation konfiguriert, für die alle ausgehenden Verbindungen genehmigt werden müssen. Mit dieser Konfiguration wird ein verwaltetes virtuelles Netzwerk erstellt, zusammen mit verwalteten privaten Endpunkten, die Konnektivität zu privaten Ressourcen ermöglichen, wie z. B. Azure Storage, Azure Container Registry und Azure OpenAI. Diese privaten Verbindungen werden bei der Erstellung und dem Testen von Flows sowie von Flows verwendet, die für Machine Learning Compute eingesetzt werden.

Aufbau

Laden Sie eine Visio-Datei dieser Architektur herunter.

Komponenten

Viele Komponenten dieser Architektur sind identisch mit der Basic-End-to-End-Chatarchitektur von Azure OpenAI. In der folgenden Liste werden nur die Änderungen an der grundlegenden Architektur hervorgehoben.

• Azure OpenAI wird sowohl in der Basis- als auch in dieser grundlegenden Architektur verwendet. Azure OpenAI ist ein vollständig verwalteter Dienst, der REST-API-Zugang zu den Sprachmodellen von Azure OpenAI bietet, einschließlich der Modelle GPT-4, GPT-3.5-Turbo und Einbettungen. Die grundlegende Architektur nutzt Unternehmensfeatures wie virtuelles Netzwerk und private Verbindungen, die von der Basis-Architektur nicht implementiert werden.
• Application Gateway ist ein Layer-7-Lastenausgleich (HTTP/S) und ein Web Traffic Manager. Es verwendet URL-pfadbasiertes Routing, um eingehenden Datenverkehr über Verfügbarkeitszonen zu verteilen, und die Verschlüsselung wird ausgelagert, um die Anwendungsleistung zu verbessern.
• Web Application Firewall (WAF) ist ein cloudnativer Dienst, der Web-Apps vor gängigen Exploits wie der Einschleusung von SQL-Befehlen und Cross-Site Scripting schützt. WAF bietet Einblick in den Datenverkehr zu und von Ihrer Webanwendung, sodass Sie Ihre Anwendung überwachen und schützen können.
• Azure Key Vault ist ein Dienst, der Geheimnisse, Verschlüsselungsschlüssel und Zertifikate sicher speichert und verwaltet. Die Verwaltung vertraulicher Informationen wird zentralisiert.
• Das virtuelle Azure-Netzwerk ist ein Dienst, mit dem Sie isolierte und sichere virtuelle Netzwerke in Azure erstellen können. Für eine Webanwendung auf App Service benötigen Sie ein Subnetz des virtuellen Netzwerks, um private Endpunkte für die netzwerksichere Kommunikation zwischen Ressourcen zu verwenden.
• Private Link ermöglicht Clients den Zugriff auf Azure PaaS (Platform-as-a-Service)-Dienste direkt aus privaten virtuellen Netzwerken aus, ohne öffentliche IP-Adressen zu verwenden.
• Azure DNS ist ein Hostingdienst für DNS-Domänen, der eine Namensauflösung mittels Microsoft Azure-Infrastruktur bietet. Private DNS-Zonen bieten eine Möglichkeit, den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) eines Diensts der IP-Adresse eines privaten Endpunkts zuzuordnen.

Überlegungen und Empfehlungen

Zuverlässigkeit

Zuverlässigkeit stellt sicher, dass Ihre Anwendung Ihre Verpflichtungen gegenüber den Kunden erfüllen kann. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Zuverlässigkeit.

Die grundlegende App Service-Webanwendungsarchitektur konzentriert sich auf zonale Redundanz für wichtige regionale Dienste. Verfügbarkeitszonen sind physisch getrennte Standorte in einer Region. Sie bieten Redundanz innerhalb einer Region für unterstützende Dienste, wenn zwei oder mehr Instanzen in dieser Region bereitgestellt werden. Wenn es in einer Zone zu einem Ausfall kommt, sind die anderen Zonen innerhalb der Region möglicherweise nicht betroffen. Die Architektur stellt außerdem genügend Instanzen von Azure-Diensten und die Konfiguration dieser Dienste sicher, die über Verfügbarkeitszonen verteilt werden können. Weitere Informationen finden Sie unter Baseline, wo Sie diese Anleitung nachlesen können.

Dieser Abschnitt befasst sich mit der Zuverlässigkeit der Komponenten in dieser Architektur, die nicht in der App Service-Basislinie behandelt werden, einschließlich Machine Learning, Azure OpenAI und AI Search.

Zonalredundanz für Flowbereitstellungen

Unternehmensbereitstellungen erfordern in der Regel Zonenredundanz. Um Zonenredundanz in Azure zu erreichen, müssen Ressourcen Verfügbarkeitszonen unterstützen, und Sie müssen mindestens drei Instanzen der Ressource bereitstellen oder die Plattformunterstützung aktivieren, wenn die Instanzkontrolle nicht verfügbar ist. Derzeit bietet Machine Learning Compute keine Unterstützung für Verfügbarkeitszonen. Um die potenziellen Auswirkungen einer Katastrophe auf Rechenzentrumsebene auf Machine Learning-Komponenten abzumildern, müssen Cluster in verschiedenen Regionen eingerichtet und ein Load Balancer bereitgestellt werden, um die Aufrufe auf diese Cluster zu verteilen. Mit Hilfe von Integritätsprüfungen können Sie sicherstellen, dass Aufrufe nur an ordnungsgemäß funktionierende Cluster weitergeleitet werden.

Die Bereitstellung von Prompt Flows ist nicht auf Machine Learning-Computecluster beschränkt. Da es sich bei dem ausführbaren Flow um eine containerisierte Anwendung handelt, kann er für jeden Azure-Dienst bereitgestellt werden, der mit Containern kompatibel ist. Zu diesen Optionen gehören Dienste wie Azure Kubernetes Service (AKS), Azure Functions, Azure Container Apps und App Service. Jeder dieser Dienste unterstützt Verfügbarkeitszonen. Um eine Zonalredundanz für die Ausführung von Eingabeaufforderungen zu erzielen, ohne dass die Komplexität einer Bereitstellung mit mehreren Regionen hinzugefügt wird, sollten Sie Ihre Flows in einem dieser Dienste bereitstellen.

Das folgende Diagramm zeigt eine alternative Architektur, bei der Prompt Flows für App Service bereitgestellt werden. Der App-Dienst wird in dieser Architektur verwendet, da die Workload sie bereits für die Chat-UI verwendet und nicht von der Einführung einer neuen Technologie in die Workload profitieren würde. Workloadteams, die Erfahrung mit AKS haben, sollten die Bereitstellung in dieser Umgebung in Betracht ziehen, insbesondere, wenn AKS für andere Komponenten in der Workload verwendet wird.

Wichtige Bereiche in dieser Architektur sind in dem Diagramm nummeriert:

1. Die Flows werden nach wie vor im Machine Learning Prompt Flow verfasst, und die Architektur des Machine Learning-Netzwerks ist unverändert. Flow-Autoren stellen weiterhin eine Verbindung mit der Arbeitsbereicherstellung über einen privaten Endpunkt her, und die verwalteten privaten Endpunkte werden zum Herstellen einer Verbindung mit Azure-Diensten beim Testen von Flows verwendet.

2. Diese punktierte Linie zeigt an, dass containerisierte ausführbare Flows an die Container Registry übertragen werden. Im Diagramm nicht dargestellt sind die Pipelines, die die Flows containerisieren und an die Container Registry weiterleiten.

3. Es gibt eine weitere Web-App, die für denselben App Service-Plan bereitgestellt wird und die bereits die Chatbenutzeroberfläche hostet. Die neue Web-App hostet den containerisierten Prompt Flow, der auf demselben App Service-Plan angesiedelt ist, der bereits auf mindestens drei Instanzen ausgeführt wird, verteilt auf Verfügbarkeitszonen. Diese App Service-Instanzen stellen über einen privaten Endpunkt eine Verbindung zur Container Registry her, wenn sie das Containerimage für den Prompt Flow laden.

4. Der Aufforderungsflowcontainer muss eine Verbindung mit allen abhängigen Diensten herstellen, um die Ablaufausführung auszuführen. In dieser Architektur stellt der Prompt Flow Container eine Verbindung mit AI Search und Azure OpenAI her. PaaS-Dienste, die nur für das Machine Learning-verwaltete Subnetz für private Endpunkte bereitgestellt wurden, müssen jetzt auch im virtuellen Netzwerk verfügbar gemacht werden, damit eine Sichtverbindung über App Service hergestellt werden kann.

Azure OpenAI – Zuverlässigkeit

Azure OpenAI unterstützt derzeit keine Verfügbarkeitszonen. Um die potenziellen Auswirkungen einer Katastrophe auf Rechenzentrumsebene auf Modellbereitstellungen in Azure OpenAI zu verringern, müssen Sie Azure OpenAI in verschiedenen Regionen bereitstellen und einen Lastenausgleich bereitstellen, um Anrufe zwischen den Regionen zu verteilen. Mit Hilfe von Integritätsprüfungen können Sie sicherstellen, dass Aufrufe nur an ordnungsgemäß funktionierende Cluster weitergeleitet werden.

Um mehrere Instanzen effektiv zu unterstützen, empfehlen wir Ihnen, die Feinabstimmungsdateien auszulagern, z. B. auf ein georedundantes Speicherkonto. Dieser Ansatz minimiert den Status, der in Azure OpenAI für jede Region gespeichert wird. Für jede Instanz, die eine Modellimplementierung hosten soll, müssen die Dateien noch feinabgestimmt werden.

Es ist wichtig, den erforderlichen Durchsatz in Form von Token pro Minute (TPM) und Anfragen pro Minute (RPM) zu überwachen. Stellen Sie sicher, dass genügend TPM aus Ihrem Kontingent zugewiesen ist, um den Bedarf für Ihre Bereitstellungen zu decken und zu verhindern, dass Aufrufe an Ihre bereitgestellten Modelle gedrosselt werden. Ein Gateway wie Azure API Management kann vor Ihrem OpenAI-Dienst bzw. Ihren Diensten bereitgestellt und für Wiederholungsversuche bei vorübergehenden Fehlern und Drosselung konfiguriert werden. API Management kann auch als Trennschalter verwendet werden, um zu verhindern, dass der Dienst mit dem Aufruf überfordert wird und das Kontingent überschreitet.

AI Search – Zuverlässigkeit

Stellen Sie AI Search mit Standardpreisebene oder höher in einer Region bereit, die Verfügbarkeitszonen unterstützt, und stellen Sie drei oder mehr Replikate bereit. Die Replikate werden automatisch gleichmäßig über Verfügbarkeitszonen verteilt.

Beachten Sie die folgenden Anleitungen zum Ermitteln der geeigneten Anzahl von Replikaten und Partitionen:

• AI Search überwachen.

• Verwenden Sie Überwachungsmetriken und -protokolle sowie Leistungsanalysen, um die angemessene Anzahl von Replikaten zu bestimmen, um abfragebasierte Drosselungen und Partitionen sowie indexbasierte Drosselungen zu vermeiden.

Machine Learning – Zuverlässigkeit

Wenn Sie die Bereitstellung auf Computeclustern hinter dem von Machine Learning verwalteten Onlineendpunkt vornehmen, beachten Sie die folgenden Hinweise zur Skalierung:

• Skalieren Sie Ihre Onlineendpunkte automatisch, um sicherzustellen, dass genügend Kapazität vorhanden ist, um die Nachfrage zu befriedigen. Wenn die Nutzungssignale aufgrund von Lastspitzen nicht rechtzeitig erfolgen, sollten Sie eine Überbereitstellung in Betracht ziehen, um eine Beeinträchtigung der Zuverlässigkeit durch zu wenige verfügbare Instanzen zu vermeiden.

• Erwägen Sie das Erstellen von Skalierungsregeln basierend auf Bereitstellungsmetriken wie CPU-Auslastungs- und Endpunktmetriken wie z. B. Anforderungslatenz.

• Nicht weniger als drei Instanzen sollten für eine aktive Produktionsbereitstellung bereitgestellt werden.

• Vermeiden Sie Bereitstellungen für nicht verwendete Instanzen. Stellen Sie stattdessen für eine neue Bereitstellung bereit und verschieben Sie den Datenverkehr nach der Bereitstellung, um Datenverkehr zu empfangen.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Sicherheit.

Diese Architektur erweitert die Sicherheitsposition, die in der Basic-End-to-End-Chatarchitektur mit Azure OpenAI implementiert wird. Die Architektur implementiert einen Netzwerksicherheitsperimeter sowie den in der Basis-Architektur implementierten Identitätsperimeter. Aus Netzwerksicht sollte nur die Chatbenutzeroberfläche über das Application Gateway vom Internet aus zugänglich sein. Aus Identitätsperspektive sollte die Chat-UI Anforderungen authentifizieren und autorisieren. Verwaltete Identitäten werden nach Möglichkeit verwendet, um Anwendungen bei Azure-Diensten zu authentifizieren.

Zusammen mit Netzwerküberlegungen beschreibt dieser Abschnitt Sicherheitsaspekte für die Schlüsselrotation und die Feinabstimmung des Azure OpenAI-Modells.

Netzwerk

Neben dem identitätsbasierten Zugang steht Netzwerksicherheit im Zentrum der grundlegenden End-to-End-Chatarchitektur, die OpenAI verwendet. Auf hoher Ebene stellt die Netzarchitektur Folgendes sicher:

• Nur ein einziger, sicherer Eingangspunkt für den Chat-UI-Datenverkehr.
• Der Netzwerkverkehr wird gefiltert.
• Die Daten werden während der Übertragung mit Transport Layer Security (TLS) durchgängig verschlüsselt.
• Die Datenexfiltration wird durch die Verwendung von Private Link minimiert, um den Datenverkehr in Azure zu halten.
• Netzwerkressourcen werden logisch gruppiert und durch Netzwerksegmentierung voneinander isoliert.

Netzwerkflows

Zwei Flows in diesem Diagramm werden in der grundlegenden App Service-Webanwendungsarchitektur behandelt: Der eingehende Flow vom Endbenutzer/der Endbenutzerin zur Chatbenutzeroberfläche (1) und der Flow von App Service zu Azure PaaS-Diensten (2). Dieser Abschnitt befasst sich mit dem Machine Learning-Onlineendpunktflow. Der folgende Flow reicht von der Chatbenutzeroberfläche, die in der grundlegenden App Service-Webanwendung ausgeführt wird, bis zum Flow, der für Machine Learning Compute bereitgestellt wird:

1. Der Aufruf von der vom App Service gehosteten Chatbenutzeroberfläche wird über einen privaten Endpunkt an den Machine Learning-Onlineendpunkt weitergeleitet.
2. Der Onlineendpunkt leitet den Anruf an einen Server weiter, auf dem der bereitgestellte Fluss ausgeführt wird. Der Onlineendpunkt fungiert sowohl als Load Balancer als auch als Router.
3. Aufrufe an Azure PaaS-Dienste, die vom bereitgestellten Flow benötigt werden, werden über verwaltete private Endpunkte weitergeleitet.

Eingang zu Machine Learning

In dieser Architektur ist der öffentliche Zugriff auf den Machine Learning-Arbeitsbereich deaktiviert. Benutzer*innen können über einen privaten Zugang auf den Arbeitsbereich zugreifen, da die Architektur der Konfiguration privater Endpunkt für Machine Learning-Arbeitsbereich folgt. Tatsächlich werden private Endpunkte in dieser Architektur verwendet, um die identitätsbasierte Sicherheit zu ergänzen. Beispielsweise kann Ihre von App Service gehostete Chatbenutzeroberfläche eine Verbindung zu PaaS-Diensten herstellen, die dem öffentlichen Internet nicht zugänglich sind, einschließlich Machine Learning-Endpunkten.

Ein Zugriff auf private Endpunkte ist auch erforderlich, um eine Verbindung mit dem Machine Learning-Arbeitsbereich für die Flowerstellung herzustellen.

Das Diagramm zeigt einen Aufforderungsflowautor, der eine Verbindung über Azure Bastion mit einem virtuellen Computer-Jumpbox herstellt. Von dieser Jumpbox aus kann der Autor eine Verbindung zum Machine Learning-Arbeitsbereich über einen privaten Endpunkt in demselben Netzwerk wie die Jumpbox herstellen. Die Konnektivität zum virtuellen Netzwerk könnte auch über ExpressRoute- oder VPN-Gateways und virtuelles Netzwerk-Peering erfolgen.

Flow vom Machine Learning-verwalteten virtuellen Netzwerk zu Azure PaaS-Diensten

Wir empfehlen Ihnen, den Machine Learning-Arbeitsbereich für eine Isolierung des verwalteten virtuellen Netzwerks zu konfigurieren, für die alle ausgehenden Verbindungen genehmigt werden müssen. Diese Architektur folgt dieser Empfehlung. Es gibt zwei Arten genehmigter ausgehender Regeln. Erforderliche Ausgangsregeln beziehen sich auf Ressourcen, die für das Funktionieren der Lösung erforderlich sind, z. B. Container Registry und Storage. Benutzerdefinierte Ausgangsregeln beziehen sich auf benutzerdefinierte Ressourcen, wie Azure OpenAI oder AI Search, die Ihr Workflow verwenden wird. Sie müssen benutzerdefinierte Ausgangsregeln konfigurieren. Die erforderlichen Ausgangsregeln werden bei der Erstellung des verwalteten virtuellen Netzwerks konfiguriert.

Bei den Ausgangsregeln kann es sich um private Endpunkte, Diensttags oder vollständig qualifizierte Domänennamen (FQDNs) für externe öffentliche Endpunkte handeln. In dieser Architektur ist die Konnektivität zu Azure-Diensten wie Container Registry, Storage, Azure Key Vault, Azure OpenAI und AI Search über einen privaten Link verbunden. Auch wenn dies in dieser Architektur nicht der Fall ist, sind einige häufige Vorgänge, die möglicherweise die Konfiguration einer FQDN-Ausgangsregel erfordern, das Herunterladen eines Pip-Pakets, das Klonen eines GitHub-Repositorys oder das Herunterladen von Basis-Containerimages aus externen Repositorys.

Segmentierung und Sicherheit des virtuellen Netzwerks

Das Netzwerk in dieser Architektur umfasst getrennte Subnetze für folgende Zwecke:

• Application Gateway
• Integrationskomponenten des App-Diensts
• Private Endpunkte
• Azure Bastion
• Jumpbox-VM
• Training – nicht für Modellschulungen in dieser Architektur verwendet
• Bewertung

Jedes Subnetz verfügt über eine Netzwerksicherheitsgruppe (NSG), die den ein- und ausgehenden Datenverkehr für diese Subnetze auf das erforderliche Maß beschränkt. Die folgende Tabelle zeigt eine vereinfachte Darstellung der NSG-Regeln, die die Baseline zu jedem Subnetz hinzufügt. Die Tabelle enthält den Namen und die Funktion der Regel.

Sämtlicher anderer Datenverkehr wird explizit verweigert.

Berücksichtigen Sie die folgenden Punkte, wenn Sie die Segmentierung und Sicherheit virtueller Netzwerke implementieren.

• Aktivieren Sie DDoS Protection für das virtuelle Netzwerk mit einem Subnetz, das Teil eines Application Gateway mit einer öffentlichen IP-Adresse ist.

• Fügen Sie nach Möglichkeit jedem Subnetz eine NSG hinzu. Verwenden Sie die strengsten Regeln, die die volle Funktionalität der Lösung ermöglichen.

• Verwenden Sie Anwendungssicherheitsgruppen, um NSGs zu gruppieren. Die Gruppierung von NSGs erleichtert die Erstellung von Regeln für komplexe Umgebungen.

Schlüsselrotation

In dieser Architektur gibt es zwei Dienste, die eine schlüsselbasierte Authentifizierung verwenden: Azure OpenAI und der verwaltete Machine Learning-Onlineendpunkt. Da Sie für diese Dienste eine schlüsselbasierte Authentifizierung verwenden, ist Folgendes wichtig:

• Speichern Sie den Schlüssel in einem sicheren Speicher, z. B. Key Vault, für den On-Demand-Zugriff von autorisierten Clients, wie z. B. der Azure Web App, die den Prompt Flow Container hostet.

• Implementieren Sie eine Schlüsseldrehungsstrategie. Wenn Sie die Schlüssel manuell rotieren, erstellen Sie eine Richtlinie für den Schlüsselablauf, und verwenden Sie Azure Policy, um zu überwachen, ob der Schlüssel rotiert wurde.

OpenAI-Modell-Feinabstimmung

Bei der Feinabstimmung von OpenAI-Modellen in Ihrer Implementierung sollten Sie die folgenden Hinweise beachten:

• Wenn Sie Trainingsdaten zur Feinabstimmung hochladen, sollten Sie die Verwendung von kundenseitig verwalteten Schlüsseln für die Verschlüsselung dieser Daten in Betracht ziehen.

• Wenn Sie Trainingsdaten in einem Speicher wie Azure Blob Storage speichern, sollten Sie die Verwendung eines kundenseitig verwalteten Schlüssels für die Datenverschlüsselung, einer verwalteten Identität zur Kontrolle des Datenzugriffs und eines privaten Endpunkts für die Verbindung zu den Daten in Betracht ziehen.

Governance durch Richtlinie

Um die Übereinstimmung mit der Sicherheit sicherzustellen, sollten Sie die Verwendung von Azure Policy und Netzwerkrichtlinien in Erwägung ziehen, damit die Bereitstellungen den Anforderungen der Workload entsprechen. Der Einsatz einer Plattformautomatisierung durch Richtlinien reduziert die Belastung durch manuelle Validierungsschritte und gewährleistet Governance, auch wenn Pipelines umgangen werden. Beachten Sie die folgenden Sicherheitsrichtlinien:

• Deaktivieren Sie den Zugriff auf Schlüssel oder andere lokale Authentifizierungen in Diensten wie Azure KI Services und Key Vault.
• Fordern Sie eine spezifische Konfiguration von Netzzugriffsregeln oder NSGs.
• Fordern Sie eine Verschlüsselung, z. B. die Verwendung von kundenseitig verwalteten Schlüsseln.

Rollenzuweisungen für Azure Machine Learning-Arbeitsbereiche für Azure Key Vault

Die verwaltete Identität des Azure Machine Learning-Arbeitsbereichs erfordert Rollenzuweisungen sowohl für die Steuerungsebene (Mitwirkender) als auch für Datenebenen (Key Vault-Administrator). Dies bedeutet, dass diese Identität Lese- und Schreibzugriff auf alle Secrets, Schlüssel und Zertifikate hat, die im Azure Key Vault gespeichert sind. Wenn Ihre Workload über andere Dienste als Azure Machine Learning verfügt, die Zugriff auf Geheimnisse, Schlüssel oder Zertifikate in Key Vault erfordern, ist Ihr Workload- oder Sicherheitsteam möglicherweise gegenüber der verwalteten Identität des Azure Machine Learning-Arbeitsbereichs skeptisch, die Zugriff auf diese Artefakte hat. In diesem Fall sollten Sie eine Key Vault-Instanz speziell für den Azure Machine Learning-Arbeitsbereich und andere Azure Key Vault-Instanzen bereitstellen, die für andere Teile Ihrer Workload geeignet sind.

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Kostenoptimierung.

Verwenden Sie den Azure-Preisrechner, um ein Preisbeispiel für dieses Szenario anzuzeigen. Sie müssen das Beispiel an Ihre Bedürfnisse anpassen, da dieses Beispiel nur die in der Architektur enthaltenen Komponenten enthält. Die teuersten Komponenten in diesem Szenario sind die Chatbenutzeroberfläche, Prompt Flow Compute und AI Search. Optimieren Sie diese Ressourcen, um möglichst viel Kosten zu sparen.

Compute

Der Machine Learning Prompt Flow unterstützt mehrere Optionen zum Hosten der ausführbaren Flows. Zu den Optionen gehören verwaltete Onlineendpunkte in Machine Learning, AKS, App Service und Azure Kubernetes Service. Jede dieser Optionen verfügt über ein eigenes Abrechnungsmodell. Die Wahl der Computemethode hat Auswirkungen auf die Gesamtkosten der Lösung.

Azure OpenAI

Azure OpenAI ist ein verbrauchsbasierter Dienst, und wie bei jedem verbrauchsbasierten Dienst ist die Steuerung der Nachfrage nach Angebot die primäre Kostenkontrolle. Um dies speziell in Azure OpenAI zu erreichen, müssen Sie eine Kombination von Ansätzen verwenden:

• Steuern von Clients. Kundenanfragen sind die Hauptkostenquelle in einem Verbrauchsmodell, daher ist die Kontrolle des Kundenverhaltens entscheidend. Alle Clients sollten:

  • Vorab genehmigt sein. Vermeiden Sie die Bereitstellung des Diensts auf eine Weise, die kostenlosen Zugriff unterstützt. Beschränken Sie den Zugang sowohl durch Netzwerk- als auch durch Identitätskontrollen, wie z. B. Schlüssel oder rollenbasierte Zugriffssteuerung (RBAC).

  • Seien Sie selbstbeherrscht. Clients müssen die von den API-Aufrufen angebotenen Einschränkungen für Tokenbegrenzungen verwenden, z. B. max_tokens und max_completions.

  • Verwenden Sie die Batchverarbeitung, wo sie praktisch ist. Überprüfen Sie Clients, um sicherzustellen, dass sie entsprechende Batchaufforderungen ausführen.

  • Optimieren Sie die Eingabe- und Antwortlänge der Eingabeaufforderung. Längere Eingabeaufforderungen verbrauchen mehr Token, erhöhen die Kosten, aber Aufforderungen, die ausreichenden Kontext fehlen, helfen den Modellen nicht, gute Ergebnisse zu erzielen. Erstellen Sie präzise Eingabeaufforderungen, die genügend Kontext bereitstellen, damit das Modell eine nützliche Antwort generieren kann. Stellen Sie außerdem sicher, dass Sie den Grenzwert der Antwortlänge optimieren.

• Die Nutzung des Azure OpenAI-Playgrounds sollte bei Bedarf und in Vorproduktionsinstanzen erfolgen, sodass für diese Aktivitäten keine Produktionskosten anfallen.

• Wählen Sie das richtige KI-Modell aus. Die Modellauswahl spielt auch eine große Rolle bei den Gesamtkosten von Azure OpenAI. Alle Modelle haben Stärken und Schwächen und sind individuell bepreist. Verwenden Sie das richtige Modell für den jeweiligen Anwendungsfall, um sicherzustellen, dass Sie nicht zu viel Geld für ein teureres Modell ausgeben, wenn ein günstigeres Modell akzeptable Ergebnisse liefert. In dieser Chatreferenzimplementierung wurde GPT 3.5-Turbo über GPT-4 ausgewählt, um eine Größenordnung der Modellbereitstellungskosten zu sparen und dabei ausreichende Ergebnisse zu erzielen.

• Informieren Sie sich über Abrechnungsunterbrechungen. Die Feinabstimmung wird pro Stunde berechnet. Um die größtmögliche Effizienz zu erreichen, sollten Sie möglichst viel der verfügbaren Zeit pro Stunde nutzen, um die Feinabstimmungsergebnisse zu verbessern, und gleichzeitig vermeiden, einfach in den nächsten Abrechnungszeitraum zu gelangen. Auch sind die Kosten für 100 Bilder aus der Bildgenerierung gleich hoch wie die Kosten für ein Bild. Maximieren Sie die Preisunterbrechungspunkte zu Ihrem Vorteil.

• Machen Sie sich die Abrechnungsmodelle bewusst. Azure OpenAI ist über das Angebot bereitgestellter Durchsatz auch in einem verpflichtungsbasierten Abrechnungsmodell verfügbar. Wenn Sie vorhersehbare Nutzungsmuster haben, sollten Sie den Wechsel zu diesem Vorkaufsabrechnungsmodell in Betracht ziehen, wenn es bei Ihrem Nutzungsvolumen kostengünstiger ist.

• Legegn Sie Bereitstellungsgrenzen fest. Stellen Sie sicher, dass alle Bereitstellungskontingente nur den Modellen zugewiesen werden, die voraussichtlich Teil der Workload sein werden, und zwar auf Modellbasis. Der Durchsatz für bereits bereitgestellte Modelle ist nicht auf dieses bereitgestellte Kontingent beschränkt, solange das dynamische Kontingent aktiviert ist. Die Kontingente stehen nicht in direktem Zusammenhang mit den Kosten, und diese Kosten können variieren.

• Überwachen Sie die Pay-as-you-go-Nutzung. Wenn Sie nach dem Pay-as-you-go-Prinzip bezahlen, überwachen Sie die Nutzung von TPM und RPM. Verwenden Sie diese Informationen, um architektonische Designentscheidungen zu treffen, z. B. welche Modelle verwendet werden sollen, und um die Promptgrößen zu optimieren.

• Überwachen Sie die Nutzung des bereitgestellten Durchsatzes. Wenn Sie bereitgestellten Durchsatz verwenden, überwachen Sie die Nutzung des bereitgestellten Durchsatzes, um sicherzustellen, dass Sie den bereitgestellten Durchsatz, den Sie erworben haben, nicht zu wenig nutzen.

• Kostenverwaltung: Befolgen Sie die Anleitungen unter Verwendung von Kostenverwaltungsfeatures mit OpenAI, um die Kosten zu überwachen, Budgets zur Kostenverwaltung festzulegen und Warnmeldungen zu erstellen, um die Beteiligten über Risiken oder Anomalien zu informieren.

Optimaler Betrieb

Die Säule „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 Erstellen einer Checkliste zur Überprüfung des optimalen Betriebs.

Machine Learning – integrierte Prompt Flow-Laufzeiten

Wie in der Basis-Architektur verwendet diese Architektur Automatic Runtime, um den Betriebsaufwand zu minimieren. Automatic Runtime ist eine Option für serverloses Computing innerhalb von Machine Learning, die die Compute-Verwaltung vereinfacht und den Großteil der prompt Flow-Konfiguration an die Datei requirements.txt und die flow.dag.yaml-Konfiguration der laufenden Anwendung delegiert. Dies macht diese Auswahl wartungsarm, kurzlebig und anwendungsorientiert. Für die Verwendung der Computeinstanz-Laufzeit oder des externen Compute wie in dieser Architektur ist ein stärker vom Workload-Team verwalteter Compute-Lebenszyklus erforderlich. Dieser sollte ausgewählt werden, wenn die Workloadanforderungen die Konfigurationsmöglichkeiten der automatischen Laufzeitoption überschreiten.

Überwachung

Wie bei der Basis-Architektur sind die Diagnosefunktionen für alle Dienste konfiguriert. Alle Dienste außer Machine Learning und App Service sind so konfiguriert, dass sie alle Protokolle erfassen. Die Machine Learning-Diagnosefunktionen sind so konfiguriert, dass sie die Audit-Protokolle erfassen, d. h. alle Ressourcenprotokolle, die Nutzerinteraktionen mit Daten oder den Einstellungen des Diensts aufzeichnen. App Service ist so konfiguriert, dass AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs und AppServicePlatformLogs erfasst werden.

Evaluieren Sie die Erstellung benutzerdefinierter Alarme für die Ressourcen in dieser Architektur, wie sie in den Azure Monitor-Basisalarmen zu finden sind. Zum Beispiel:

• Container Registry-Warnungen
• Machine Learning- und Azure OpenAI-Warnungen
• Azure Web Apps-Warnungen

Sprachmodellvorgänge

Die Bereitstellung für Azure OpenAI-basierte Chatlösungen wie diese Architektur sollte den Anleitungen in GenAIOps mit Prompt Flow mit Azure DevOps und GitHub folgen. Darüber hinaus müssen bewährte Verfahren für kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) sowie netzwerkgesicherte Architekturen berücksichtigt werden. Die folgende Anleitung befasst sich mit der Implementierung von Flows und der zugehörigen Infrastruktur basierend auf den GenAIOps-Empfehlungen. Dieser Bereitstellungsleitfaden enthält nicht die Front-End-Anwendungselemente, die unverändert in der hochverwendeten zonenredundanten Webanwendungsarchitektur Baseline vorhanden sind.

Entwicklung

Machine Learning Prompt Flow bietet sowohl eine browserbasierte Authoringerfahrung in Machine Learning Studio als auch über eine Visual Studio Code-Erweiterung. Beide Optionen speichern den Flowcode als Dateien. Wenn Sie Machine Learning Studio verwenden, werden die Dateien in einem Speicherkonto gespeichert. Wenn Sie in Microsoft Visual Studio Code arbeiten, werden die Dateien in Ihrem lokalen Dateisystem gespeichert.

Um bewährte Methoden für die gemeinsame Entwicklung zu befolgen, sollten die Quelldateien in einem Onlinequellcode-Repository wie GitHub Standard enthalten sein. Dieser Ansatz erleichtert die Nachverfolgung aller Codeänderungen, die Zusammenarbeit zwischen Flowautoren und die Integration mit Bereitstellungsflows , die alle Codeänderungen testen und überprüfen.

Für die Unternehmensentwicklung sollten Sie die Microsoft Visual Studio Code-Erweiterung und das Prompt Flow SDK/CLI für die Entwicklung verwenden. Prompt-Flow-Autoren können ihre Flüsse aus Microsoft Visual Studio Code erstellen und testen und die lokal gespeicherten Dateien in das Online-Quellcodeverwaltungssystem und Pipelines integrieren. Während die browserbasierte Erfahrung gut für die explorative Entwicklung geeignet ist, kann sie mit einigen Arbeiten in das Quellcodeverwaltungssystem integriert werden. Der Flowordner kann von der Flowseite im Files Bereich heruntergeladen, entzippt und an das Quellcodeverwaltungssystem übertragen werden.

Auswertung

Testen Sie die in einer Chatanwendung verwendeten Flows genauso wie andere Softwareartefakte. Es ist schwierig, eine einzige „richtige“ Antwort für die Ausgaben eines Sprachmodells festzulegen und durchzusetzen, aber Sie können ein Sprachmodell selbst zur Bewertung der Antworten verwenden. Erwägen Sie die Implementierung der folgenden automatisierten Auswertungen Ihrer Sprachmodellflows:

• Klassifizierungsgenauigkeit: Bewertet, ob das Sprachmodell einen „richtigen“ oder „falschen“ Score abgibt, und fasst die Ergebnisse zusammen, um eine Genauigkeitsbewertung zu erstellen.

• Kohärenz: Bewertet, wie gut die Sätze in der vorhergesagten Antwort eines Modells geschrieben werden und wie sie sich kohärent miteinander verbinden.

• Fluency: Bewertet die vorhergesagte Antwort des Modells auf seine grammatikalische und sprachliche Genauigkeit.

• Fundiertheit gegenüber Kontext: Bewertet, wie gut die vorhergesagten Antworten des Modells auf dem vorkonfigurierten Kontext basieren. Selbst wenn die Antworten des Sprachmodells korrekt sind, sind sie nicht fundiert, wenn sie nicht anhand des gegebenen Kontexts validiert werden können.

• Relevanz: Bewertet, wie gut die vorhergesagten Antworten des Modells mit der gestellten Frage übereinstimmen.

Beachten Sie beim Implementieren automatisierter Auswertungen die folgenden Anleitungen:

• Erstellen Sie Bewertungen aus Auswertungen, und messen Sie sie anhand eines vordefinierten Erfolgsschwellenwerts. Verwenden Sie diese Bewertungen, um Testdurchlauf/Fehler in Ihren Pipelines zu melden.

• Einige dieser Tests erfordern vorkonfigurierte Dateneingaben von Fragen, Kontext und Grundwahrung.

• Fügen Sie genügend Frage-Antwort-Paare ein, um sicherzustellen, dass die Ergebnisse der Tests zuverlässig sind, wobei mindestens 100-150 Paare empfohlen werden. Diese Frage-Antwort-Paare werden als Ihr "goldener Datensatz" bezeichnet. Abhängig von der Größe und Domäne Ihres Datensatzes ist möglicherweise eine größere Population erforderlich.

• Vermeiden Sie die Verwendung von Sprachmodellen zur Generierung der Daten in Ihrem goldenen Datensatz.

Bereitstellungsflow

1. Der Aufforderungstechniker/Data-Wissenschaftler öffnet eine Featurebranch, in der sie an der spezifischen Aufgabe oder Funktion arbeiten. Der Prompt-Ingenieur/Datenwissenschaftler iteriert den Flow mithilfe des Prompt Flows für Microsoft Visual Studio Code, schreibt regelmäßig Änderungen fest und überträgt diese Änderungen an den Feature-Zweig.

2. Sobald die lokale Entwicklung und Experimente abgeschlossen sind, öffnet der Aufforderungstechniker/Data-Wissenschaftler eine Pull-Anforderung von der Feature-Verzweigung bis zur Hauptverzweigung. Der Pull Request (PR) löst eine PR-Pipeline aus. Diese Pipeline führt schnelle Qualitätsprüfungen durch, die Folgendes umfassen sollten:

   • Ausführung von Experimentierabläufen
   • Ausführung von konfigurierten Komponententests
   • Kompilierung der Codebasis
   • Analyse des statischen Codes

3. Die Pipeline kann einen Schritt enthalten, der mindestens ein Teammitglied benötigt, um die PR vor dem Zusammenführen manuell zu genehmigen. Der Genehmigende kann nicht der Commiter sein, und sie verfügen über ein promptes Flow-Know-how und vertraut mit den Projektanforderungen. Wenn die PR nicht genehmigt wird, wird die Zusammenführung blockiert. Wenn die PR genehmigt wurde oder kein Genehmigungsschritt vorhanden ist, wird die Featurebranch mit der Main-Verzweigung zusammengeführt.

4. Die Zusammenführung mit Main löst den Build- und Veröffentlichungsprozess für die Entwicklungsumgebung aus. Speziell:

   1. Die CI-Pipeline wird von der Zusammenführung zu Main ausgelöst. Die CI-Pipeline führt alle Schritte aus, die in der PR-Pipeline ausgeführt werden, und die folgenden Schritte:
   • Experimentierflow
   • Auswertungsflow
   • Registriert die Flows in der Machine Learning-Registrierung, wenn Änderungen erkannt werden
   1. Die CD-Pipeline wird nach Abschluss der CI-Pipeline ausgelöst. Dieser Flow führt die folgenden Schritte aus:
   • Stellt den Flow von der Machine Learning-Registrierung zu einem Machine Learning-Onlineendpunkt bereit
   • Führt Integrationstests aus, die auf den Onlineendpunkt abzielen
   • Führt Rauchtests aus, die auf den Onlineendpunkt abzielen

5. Ein Genehmigungsprozess ist in den Freigabeförderungsprozess integriert – nach Genehmigung werden die in den Schritten 4.a beschriebenen CI & CD-Prozesse verarbeitet. & 4.b. werden wiederholt und zielen auf die Testumgebung ab. Schritte a. und b. sind identisch, mit der Ausnahme, dass Benutzerakzeptanztests nach den Rauchtests in der Testumgebung ausgeführt werden.

6. Die in den Schritten 4.a beschriebenen CI- und CD-Prozesse. & 4.b. werden ausgeführt, um die Freigabe in die Produktionsumgebung zu fördern, nachdem die Testumgebung überprüft und genehmigt wurde.

7. Nach der Freigabe in eine Liveumgebung erfolgen die operativen Aufgaben der Überwachung von Leistungsmetriken und der Evaluierung der bereitgestellten Sprachmodelle. Dies umfasst u. a.:

   • Erkennen von Datendrifts
   • Beobachten der Infrastruktur
   • Kostenverwaltung
   • Kommunikation der Leistung des Modells an Projektbeteiligte

Hinweise zur Bereitstellung

Sie können Machine Learning-Endpunkte verwenden, um Modelle auf eine Weise bereitzustellen, die Flexibilität bei der Freigabe für die Produktion ermöglicht. Berücksichtigen Sie die folgenden Strategien, um die beste Modellleistung und -qualität sicherzustellen:

• Blaue/grüne Bereitstellungen: Mit dieser Strategie können Sie Ihre neue Version des Webdiensts sicher für eine begrenzte Gruppe von Benutzern oder Anforderungen bereitstellen, bevor Sie den gesamten Datenverkehr an die neue Bereitstellung weiterleiten.

• A/B-Tests: Blau/Grün-Bereitstellungen sind nicht nur effektiv für die sichere Einführung von Änderungen, sie können auch für die Einführung neuer Verhaltensweisen verwendet werden, die es einer Teilgruppe von Benutzer*innen ermöglichen, die Auswirkungen der Änderung zu bewerten.

• Schließen Sie das Linting von Python-Dateien ein, die Teil des Aufforderungsflows in Ihre Pipelines sind. Linting überprüft die Einhaltung von Stilstandards, Fehlern, Codekomplexität, nicht verwendeten Importen und Variablenbenennung.

• Wenn Sie Ihren Flow im netzwerkisolierten Machine Learning-Arbeitsbereich bereitstellen, verwenden Sie einen selbst gehosteten Agenten, um Artefakte auf Ihren Azure Ressourcen bereitzustellen.

• Die Machine Learning-Modellregistrierung sollte nur aktualisiert werden, wenn es Änderungen am Modell gibt.

• Die Sprachmodelle, die Flows und die Client-Benutzeroberfläche sollten lose gekoppelt sein. Aktualisierungen der Flows und der Client-UI können und sollten ohne Auswirkungen auf das Modell vorgenommen werden können und umgekehrt.

• Wenn Sie mehrere Flows entwickeln und bereitstellen, sollte jeder Flow seinen eigenen Lebenszyklus haben, was eine lose Kopplung bei der Übertragung von Flows von der Erprobung zur Produktion ermöglicht.

Infrastruktur

Wenn Sie die grundlegenden Azure OpenAI End-to-End-Chatkomponenten bereitstellen, sind einige der bereitgestellten Dienste grundlegend und dauerhaft in der Architektur, während andere Komponenten eher kurzlebiger Natur sind und ihre Existenz an eine Bereitstellung gebunden ist.

Grundlegende Komponenten

Einige Komponenten in dieser Architektur sind mit einem Lebenszyklus vorhanden, der über jeden einzelnen Aufforderungsflow oder eine Modellbereitstellung hinausgeht. Diese Ressourcen werden in der Regel einmal im Rahmen der grundlegenden Bereitstellung durch das Workloadteam bereitgestellt und abgesehen von neuen, entfernten oder Aktualisierungen der Aufforderungsflows oder Modellbereitstellungen verwaltet.

• Machine Learning-Arbeitsbereich
• Speicherkonto für den Machine Learning-Arbeitsbereich
• Container Registry
• KI-Suche
• Azure OpenAI
• Azure Application Insights
• Azure Bastion
• Azure Virtual Machine für die Jumpbox

Kurzlebige Komponenten

Einige Azure-Ressourcen sind enger an die Gestaltung bestimmter Prompt Flows gekoppelt. Mit diesem Ansatz können diese Ressourcen an den Lebenszyklus der Komponente gebunden und in dieser Architektur kurzlebig werden. Azure-Ressourcen sind betroffen, wenn sich die Workload ändert, z. B. wenn Flows hinzugefügt oder entfernt werden oder wenn neue Modelle eingeführt werden. Diese Ressourcen werden neu erstellt und vorherige Instanzen entfernt. Einige dieser Ressourcen sind direkte Azure-Ressourcen und einige sind Datenebenen-Manifestationen innerhalb ihres enthaltenden Diensts.

• Das Modell in der Machine Learning-Modellregistrierung sollte im Rahmen der CD-Pipeline aktualisiert werden, wenn es geändert wird.

• Das Containerimage sollte im Rahmen der CD-Pipeline in der Container Registry aktualisiert werden.

• Ein Machine Learning-Endpunkt wird bei der Bereitstellung eines Prompt Flows erstellt, wenn die Bereitstellung auf einen Endpunkt verweist, der nicht vorhanden ist. Dieser Endpunkt muss aktualisiert werden, um den öffentlichen Zugriff zu deaktivieren.

• Die Bereitstellungen des Machine Learning-Endpunkts werden aktualisiert, wenn ein Flow bereitgestellt oder gelöscht wird.

• Der Key Vault für die Client-UI muss mit dem Schlüssel zum Endpunkt aktualisiert werden, wenn ein neuer Endpunkt erstellt wird.

Effiziente Leistung

Leistungseffizienz ist die Fähigkeit Ihrer Workload, eine effiziente Skalierung entsprechend den Anforderungen der Benutzer auszuführen. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Leistungseffizienz.

Dieser Abschnitt beschreibt die Leistungseffizienz aus der Perspektive von Azure Search, Azure OpenAI und Machine Learning.

Azure Search – Leistungseffizienz

Folgen Sie der Anleitung zur Analyse der Leistung in AI Search.

Azure OpenAI – Leistungseffizienz

• Bestimmen Sie, ob Ihre Anwendung bereitgestellten Durchsatz oder das Shared-Hosting- oder Verbrauchsmodell benötigt. Der bereitgestellte Durchsatz gewährleistet reservierte Verarbeitungskapazitäten für Ihre OpenAI-Modellimplementierungen, was eine vorhersehbare Leistung und einen vorhersehbaren Durchsatz für Ihre Modelle ermöglicht. Dieses Abrechnungsmodell unterscheidet sich vom Shared-Hosting- oder Verbrauchsmodell. Beim Verbrauchsmodell handelt es sich um ein Best-Effort-Modell, das möglicherweise durch den Noisy-Neighbor-Effekt oder andere Stressfaktoren auf der Plattform beeinträchtigt wird.

• Überwachen Sie die durch Bereitstellung verwaltete Nutzung für den bereitgestellten Durchsatz.

Machine Learning – Leistungseffizienz

Wenn Sie auf Onlineendpunkten für Machine Learning bereitstellen:

• Befolgen Sie die Anleitung zur Autoskalierung eines Onlineendpunkts. Auf diese Weise können Sie sich eng an der Nachfrage orientieren, ohne dass es zu einer Überbereitstellung kommt, insbesondere in Zeiten geringer Nutzung.

• Wählen Sie die entsprechende SKU des virtuellen Computers für den Onlineendpunkt aus, um Ihre Leistungsziele zu erfüllen. Testen Sie die Leistung einer geringeren Instanzanzahl und größerer SKUs im Vergleich zu einer größeren Instanzanzahl und kleineren SKUs, um eine optimale Konfiguration zu finden.

Bereitstellen dieses Szenarios

Führen Sie zum Bereitstellen und Ausführen der Referenzimplementierung die Schritte in der End-to-End-Referenzimplementierung von OpenAI aus.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

• Rob Bagby | Patterns & Practices – Microsoft
• Freddy Ayala | Cloud Solution Architect - Microsoft
• Prabal Deb | Senior Software Engineer - Microsoft
• Raouf Aliouat | Software Engineer II - Microsoft
• Ritesh Modi | Principal Software Engineer - Microsoft
• Ryan Pfalz | Senior Solution Architect - Microsoft

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächster Schritt

Zugehörige Ressourcen

• Azure OpenAI
• Azure OpenAI-Sprachmodelle
• Machine Learning Prompt Flow
• Isolation verwalteter virtueller Netzwerke auf Arbeitsbereichsebene
• Konfigurieren eines privaten Endpunkts für einen Machine Learning-Arbeitsbereich
• Inhaltsfilterung