Baseline OpenAI End-to-End-Chat-Referenzarchitektur

Azure OpenAI Service
Azure Machine Learning
Azure App Service
Azure-Schlüsseltresor
Azure Monitor

Unternehmenschatanwendungen haben die Möglichkeit, Mitarbeiter durch Gesprächsinteraktionen zu unterstützen. Dies gilt insbesondere aufgrund der kontinuierlichen Weiterentwicklung großer Sprachmodelle wie gpT-Modelle von OpenAI und LLaMA-Modellen von Meta. Diese Chat-Anwendungen bestehen aus einer Benutzeroberfläche zum Chatten, Datenrepositorys mit domänenspezifischen Informationen, die für die Anfragen des Benutzers relevant sind, großen Sprachmodellen (LLMs), die über die domänenspezifischen Daten nachdenken, um eine relevante Antwort zu erzeugen, und einem Orchestrator, der die Interaktion zwischen diesen Komponenten überwacht.

Dieser Artikel enthält eine grundlegende Architektur zum Erstellen und Bereitstellen von Unternehmenschatanwendungen, die große Azure OpenAI-Sprachmodelle verwenden. Die Architektur nutzt den Prompt-Flow von Azure Machine Learning (AML), um ausführbare Flows zu erstellen, die den Workflow von eingehenden Prompts bis hin zu Datenspeichern orchestrieren, um Basisdaten für die LLMs abzurufen, zusammen mit jeder anderen erforderlichen Python-Logik. Der ausführbare Flow wird in einem Azure 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 der App Service über die Integration des virtuellen Netzwerks über private Endpunkte an Azure PaaS-Dienste. Ebenso kommuniziert der Chat-UI-App-Dienst mit dem verwalteten Online-Endpunkt für den Flow über einen privaten Endpunkt und der öffentliche Zugriff auf den Azure Machine Learning-Arbeitsbereich ist deaktiviert.

Wichtig

Der Artikel behandelt nicht die Komponenten oder Architekturentscheidungen der Basis-App-Services-Webanwendung. Bitte lesen Sie diesen Artikel zur Architekturanleitung für das Hosten der Chat-UI.

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 die Konnektivität mit privaten Ressourcen wie dem Arbeitsplatz Azure Storage, der Azure-Containerregistrierung und Azure OpenAI ermöglichen. Diese privaten Verbindungen werden während der Ablauferstellung und -tests und von Flows verwendet, die für Azure Machine Learning-Compute bereitgestellt werden.

Tipp

GitHub logo Dieser Artikel wird durch eine Referenzimplementierung unterstützt, die eine grundlegende End-to-End-Chatimplementierung in Azure zeigt. Diese Implementierung kann als Grundlage für die benutzerdefinierte Lösungsentwicklung bei Ihrem ersten Schritt zur Produktion verwendet werden.

Aufbau

Diagram that shows a baseline end-to-end chat architecture with OpenAI.

Abbildung 1: Grundliegende End-to-End-Chatarchitektur mit OpenAI

Laden Sie eine Visio-Datei dieser Architektur herunter.

Komponenten

Viele der Komponenten dieser Architektur sind identisch mit den Ressourcen in der Basisanwendung für App-Dienste, da das Hosten der Chat-UI in dieser Architektur die Architektur der basiswerten App Service-Webanwendung folgt. Die in diesem Abschnitt hervorgehobenen Komponenten konzentrieren sich auf die Komponenten, mit denen Chatflows erstellt und koordiniert werden, sowie Datendienste und die Dienste, die die LLMs verfügbar machen.

  • Azure Machine Learning ist ein verwalteter Clouddienst, der zum Trainieren, Bereitstellen und Verwalten von Modellen für maschinelles Lernen verwendet wird. Diese Architektur verwendet mehrere andere Features von Azure Machine Learning, die zum Entwickeln und Bereitstellen ausführbarer Flows für KI-Anwendungen verwendet werden, die von großen Sprachmodellen unterstützt werden:
    • Der Azure Machine Learning-Aufforderungsflow ist ein Entwicklungstool, mit dem Sie Flows erstellen, auswerten und bereitstellen können, die Benutzeraufforderungen, Aktionen über Python-Code und Aufrufe von LLMs verknüpfen. Der Aufforderungsflow wird in dieser Architektur verwendet, da die Ebene, die zwischen der Eingabeaufforderung, verschiedenen Datenspeichern und dem LLM koordiniert wird.
    • Mit verwalteten Onlineendpunkten können Sie einen Flow für Echtzeit-Inferenz bereitstellen. In dieser Architektur werden sie als PaaS-Endpunkt für die Chat-UI verwendet, um die von Azure Machine Learning gehosteten Aufforderungsflows aufzurufen.
  • Azure Storage wird verwendet, um die Quelldateien für den Aufforderungsflow für die Entwicklung von Aufforderungsfows beizubehalten.
  • Azure Container Registry ermöglicht die Erstellung, Speicherung und Verwaltung von Containerimages und -artefakten in einer privaten Registrierung für alle Arten von Containerbereitstellungen. In dieser Architektur werden Flows als Containerimages verpackt und in der Azure-Containerregistrierung gespeichert.
  • Azure OpenAI ist ein vollständig verwalteter Dienst, der REST-API-Zugriff auf die großen Sprachmodelle von Azure OpenAI bietet, einschließlich der Modelle GPT-4, GPT-3.5-Turbo und Embeddings. In dieser Architektur wird zusätzlich zum Modellzugriff auch verwendet, um allgemeine Unternehmensfeatures wie virtuelles Netzwerk und private Verknüpfung, Unterstützung für verwaltete Identitäten und Inhaltsfilterung hinzuzufügen.
  • Azure AI Search ist ein Cloudsuchdienst, der Vollextsuche, schematische Suche, Vektorsuche und Hybridsuche unterstützt. Azure AI Search ist in der Architektur enthalten, da es sich um einen gemeinsamen Dienst handelt, der in den Flows hinter Chatanwendungen verwendet wird. Azure AI Search kann zum Abrufen und Indizieren von Daten verwendet werden, die für Benutzerabfragen relevant sind. Der Aufforderungsflow implementiert das RAG-Muster Retrieval Augmented Generation, um die entsprechende Abfrage aus der Eingabeaufforderung zu extrahieren, KI-Suche abzufragen und die Ergebnisse als Erdungsdaten für das Azure OpenAI-Modell zu verwenden.

Azure Machine Learning-Aufforderungsflow

Das Back-End für Unternehmenschatanwendungen folgt im Allgemeinen einem Muster, das dem folgenden Flow ähnelt:

  • Der Benutzer gibt eine Eingabeaufforderung in eine benutzerdefinierte Chat-Benutzeroberfläche (UI) ein.
  • Diese Eingabeaufforderung wird vom Schnittstellencode an das Back-End gesendet.
  • Die Benutzerabsicht (Frage oder Direktive) wird aus der Eingabeaufforderung vom Back-End extrahiert.
  • (optional) Das Back-End bestimmt die Datenspeicher, die Daten enthalten, die für die Benutzeraufforderung relevant sind.
  • Das Back-End fragt die relevanten Datenspeicher ab.
  • Das Back-End sendet die Absicht, die relevanten Erdungsdaten und alle verlaufsrelevanten Daten, die in der Eingabeaufforderung an die LLM bereitgestellt werden.
  • Das Back-End gibt das Ergebnis zurück, sodass es auf der Benutzeroberfläche angezeigt werden kann.

Das Back-End kann in einer beliebigen Anzahl von Sprachen implementiert und für verschiedene Azure-Dienste bereitgestellt werden. In dieser Architektur wurde der Azure Machine Learning-Eingabeaufforderungsflow ausgewählt, da er eine optimierte Erfahrung zum Erstellen, Testen und Bereitstellen von Flüssen bietet, die zwischen Eingabeaufforderungen, Back-End-Datenspeichern und LLMs koordiniert werden.

Netzwerk

Neben dem identitätsbasierten Zugriff steht die Netzwerksicherheit im Kern der grundlegenden End-to-End-Chatarchitektur unter Verwendung von OpenAI. Auf hoher Ebene stellt die Netzwerkarchitektur Folgendes sicher:

  • Ein einziger sicherer Einstiegspunkt für den Chat-UI-Datenverkehr
  • Netzwerkdatenverkehr wird gefiltert.
  • Daten während der Übertragung werden End-to-End mit TLS verschlüsselt.
  • Die Datenexfiltration wird minimiert, indem der Datenverkehr mithilfe von Private Link in Azure beibehalten wird
  • Netzwerkressourcen werden logisch gruppiert und durch Netzwerksegmentierung voneinander isoliert.

Netzwerkflows

Diagram that shows a baseline end-to-end chat architecture with OpenAI with flow numbers.

Abbildung 2: Netzwerkflows für die grundliegende End-to-End-Chatarchitektur mit OpenAI

Zwei Flows in diesem Diagramm werden in der Basisanwendung für App-Dienste behandelt: 1. der eingehende FLow vom Endbenutzer zur Chat-UI und 2. Der Flow von App Service zu Azure-PaaS-Diensten. Ausführliche Informationen zu diesen Flows finden Sie in diesem Artikel. Dieser Abschnitt konzentriert sich auf den Onlineendpunktfluss von Azure Machine Learning. Im Folgenden wird der Flow von der Chat-Benutzeroberfläche, die in der basiswerten App Service-Webanwendung ausgeführt wird, zum Flow beschrieben, der für Azure Machine Learning bereitgestellt wird:

  1. Der Anruf von der gehosteten Chat-Benutzeroberfläche des App-Diensts wird über einen privaten Endpunkt an den Azure 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 Azure Machine Learning

In dieser Architektur ist der öffentliche Zugriff auf den Azure Machine Learning-Arbeitsbereich deaktiviert, und der Zugriff kann über den privaten Zugriff erfolgen, wie er dem privaten Endpunkt für die Azure Machine Learning-Arbeitsbereichskonfiguration folgt. Tatsächlich werden private Endpunkte in dieser Architektur verwendet, um die identitätsbasierte Sicherheit zu ergänzen. So können Sie beispielsweise zulassen, dass Ihre in App Service gehostete Chat-Benutzeroberfläche eine Verbindung mit PaaS-Diensten herstellen kann, die nicht mit dem öffentlichen Internet verfügbar gemacht werden, einschließlich Azure Machine Learning-Endpunkten.

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

Diagram that shows a user connecting to an Azure Machine Learning workspace through a jump box to author a flow OpenAI with flow numbers.

Abbildung 3: Netzwerkflows für einen Azure Machine Learning-Aufforderungsflowautor

Das Diagramm zeigt einen Aufforderungsflowautor, der eine Verbindung über Azure Bastion mit einem virtuellen Computer-Jumpbox herstellt. Über diese Jumpbox kann der Autor über einen privaten Endpunkt im selben Netzwerk wie das Sprungfeld eine Verbindung mit dem Machine Learning Workspace herstellen. Die Konnektivität zum virtuellen Netzwerk könnte auch über ExpressRoute- oder VPN-Gateways und virtuelles Netzwerk-Peering erfolgen.

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

Es wird empfohlen, dass der Azure Machine Learning-Arbeitsbereich für die verwaltete virtuelle Netzwerkisolation mit einer Konfiguration konfiguriert ist, für die alle ausgehenden Verbindungen genehmigt werden müssen. Diese Architektur folgt dieser Empfehlung. Es gibt zwei Arten genehmigter ausgehender Regeln. Erforderliche ausgehende Regeln sind Ressourcen, die für die Lösung erforderlich sind, z. B. Azure Container Registry und Azure Storage. Benutzerdefinierte ausgehende Regeln sind benutzerdefinierte Ressourcen, z. B. Azure OpenAI oder Azure AI Search, die Ihr Workflow verwenden wird. Es liegt in Ihrer Verantwortung, benutzerdefinierte ausgehende Regeln zu konfigurieren, während erforderliche ausgehende Regeln konfiguriert werden, wenn das verwaltete virtuelle Netzwerk erstellt wird.

Die ausgehenden Regeln können private Endpunkte, Diensttags oder FQDNs für externe öffentliche Endpunkte sein. In dieser Architektur werden die Konnektivität zu Azure-Diensten wie Azure Container Registry, Azure Storage, Azure Key Vault, Azure OpenAI-Dienst und Azure AI Search über einen privaten Link verbunden. Obwohl dies nicht in dieser Architektur der Fall ist, laden einige gängige Vorgänge, die möglicherweise das Konfigurieren einer ausgehenden FQDN-Regel erfordern, ein Pip-Paket herunter, das Klonen eines GitHub-Repositorys, das Herunterladen von Basiscontainerimages aus externen Repositorys.

Segmentierung und Sicherheit des virtuellen Netzwerks

Das Netzwerk in dieser Architektur verfügt über separate Subnetze für Folgendes:

  • 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, die den eingehenden und ausgehenden Datenverkehr für diese Subnetze auf das erforderliche Limit beschränkt. Die folgende Tabelle zeigt eine vereinfachte Ansicht der NSG-Regeln, die die Baseline jedem Subnetz hinzufügt. Die Tabelle enthält den Regelnamen und die Funktion.

Subnet Eingehend Ausgehend
snet-AppGateway Zertifikate für unsere Chat-UI-Benutzerquellen-IPs (z. B. öffentliches Internet) sowie erforderliche Elemente für den Dienst Zugriff auf den privaten Azure-App Service-Endpunkt sowie erforderliche Elemente für den Dienst.
snet-PrivateEndpoints Nur Datenverkehr aus dem virtuellen Netzwerk wird zugelassen. Nur Datenverkehr zum virtuellen Netzwerk wird zugelassen.
snet-AppService Nur Datenverkehr aus dem virtuellen Netzwerk wird zugelassen. Zugriff auf die privaten Endpunkte und Azure Monitor zulassen.
AzureBastionSubnet Weitere Informationen finden Sie in den Anleitungen zum Arbeiten mit NSG-Zugriff und Azure Bastion. Weitere Informationen finden Sie in den Anleitungen zum Arbeiten mit NSG-Zugriff und Azure Bastion.
snet-jumpbox Lassen Sie eingehende RDP- und SSH-Verbindungen aus dem Azure Bastion Host-Subnetz zu. Zulassen des Zugriffs zu den privaten Endpunkten
snet-agents Nur Datenverkehr aus dem virtuellen Netzwerk wird zugelassen. Nur Datenverkehr zum virtuellen Netzwerk wird zugelassen.
snet-training Nur Datenverkehr aus dem virtuellen Netzwerk wird zugelassen. Nur Datenverkehr zum virtuellen Netzwerk wird zugelassen.
snet-scoring Nur Datenverkehr aus dem virtuellen Netzwerk wird zugelassen. Nur Datenverkehr zum virtuellen Netzwerk wird zugelassen.

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 sollte für das virtuelle Netzwerk mit einem Subnetz, das Teil einer Application Gateway-Instanz mit einer öffentlichen IP-Adresse ist.
  • Fügen Sie nach Möglichkeit jedem Subnetz eine NSG hinzu. Sie sollten die strengsten Regeln verwenden, die eine vollständige Lösungsfunktionalität ermöglichen.
  • Verwenden Sie Anwendungssicherheitsgruppen. Mit Anwendungssicherheitsgruppen können Sie NSGs gruppieren und so die Regelerstellung für komplexe Umgebungen vereinfachen.

Überwachung von Inhaltsfiltern und Missbrauch

Der Azure OpenAI-Dienst enthält ein Inhaltsfiltersystem, das ein Ensemble von Klassifizierungsmodellen verwendet, um bestimmte Kategorien potenziell schädlicher Inhalte sowohl in Eingabeaufforderungen als auch in Ausgabeabschlüssen zu erkennen und zu verhindern. Zu den Kategorien für diesen potenziell schädlichen Inhalt gehören Hass, Sex, Selbstverletzung, Gewalt, Obszönität und Jailbreak (Inhalte, die die Einschränkungen eines LLM umgehen sollen). Sie können die Strenge des Inhalts konfigurieren, den Sie für jede Kategorie filtern möchten, wobei Optionen niedrig, mittel oder hoch sind. Diese Referenzarchitektur verfolgt einen strengen Ansatz. Sie sollten die Einstellungen entsprechend Ihren Anforderungen anpassen.

Zusätzlich zur Inhaltsfilterung implementiert der Azure OpenAI-Dienst Missbrauchsüberwachungsfeatures. Bei der Missbrauchsüberwachung handelt es sich um einen asynchronen Vorgang, der darauf ausgelegt ist, wiederkehrende Inhalte und/oder Verhaltensweisen zu erkennen und zu entschärfen, die auf eine Nutzung des Diensts in einer Weise hindeuten, die möglicherweise gegen den Azure OpenAI-Verhaltenskodex verstößt. Sie können beispielsweise eine Ausnahme der Missbrauchsüberwachung und der menschlichen Überprüfung anfordern, wenn Ihre Daten streng vertraulich sind oder interne Richtlinien oder anwendbare gesetzliche Vorschriften vorhanden sind, die die Verarbeitung von Daten zur Erkennung von Missbrauch verhindern.

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 Ausfallzeiten 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. Bitte lesen Sie den Basisplan, um diese Anleitungen zu überprüfen.

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

Zonalredundanz für Flowbereitstellungen

Unternehmensbereitstellungen erfordern in der Regel mindestens Zonalredundanz. Um dies in Azure zu erreichen, müssen Ressourcen Verfügbarkeitszonen unterstützen, und Sie müssen mindestens die Instanzen der Ressource bereitstellen oder die Plattformunterstützung aktivieren, wenn das Instanzsteuerelement nicht verfügbar ist. Derzeit bietet Azure Machine Learning Compute keine Unterstützung für Verfügbarkeitszonen. Um die potenziellen Auswirkungen einer Katastrophe auf Datencenterebene auf AML-Komponenten zu mindern, ist es erforderlich, Cluster in verschiedenen Regionen zusammen mit der Bereitstellung eines Lastenausgleichs zur Verteilung von Anrufen unter diesen Clustern einzurichten. Sie würden Integritätsprüfungen verwenden, um sicherzustellen, dass Anrufe nur an Cluster weitergeleitet werden, die ordnungsgemäß funktionieren.

Die Bereitstellung von Aufforderungsflows ist nicht auf Azure Machine Learning-Computecluster beschränkt. Der ausführbare Flow, der eine containerisierte Anwendung ist, kann 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 (ACA) und Azure-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.

Es folgt eine alternative Architektur, in der Aufforderungsflows für Azure-App Dienst 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.

Diagram that shows a baseline end-to-end chat architecture with OpenAI with prompt flow deployed to Azure App Service.

Abbildung 4: Alternative End-to-End-Chatarchitektur mit OpenAI- Bereitstellung von Aufforderungsflows in Azure-App Services

Das Diagramm ist für Bereiche nummeriert, die in dieser Architektur bemerkenswert sind:

  1. Flows werden weiterhin im Azure Machine Learning-Aufforderungsflow erstellt, und die Azure Machine Learning-Netzwerkarchitektur ist unverändert. Ablaufautoren 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 gepunktete Linie gibt an, dass containerisierte ausführbare Flows an die Azure Container Registry (ACR) übertragen werden. Nicht im Diagramm dargestellt sind die Pipelines, die die Flows containerisieren und an ACR übertragen.
  3. Es gibt eine andere Web App, die für denselben App Service-Plan bereitgestellt wird und bereits die Chat-Benutzeroberfläche hostet. Die neue Web App hostet den containerisierten Aufforderungsflow, der im selben App Service-Plan, der bereits mit mindestens drei Instanzen ausgeführt wird, verteilt auf Verfügbarkeitszonen. Diese App Service-Instanzen stellen beim Laden des Containerimages für den Aufforderungsflow eine Verbindung mit ACR über einen privaten Endpunkt her.
  4. Der Aufforderungsflowcontainer muss eine Verbindung mit allen abhängigen Diensten herstellen, um die Ablaufausführung auszuführen. In dieser Architektur wäre Azure AI Search und Azure OpenAI-Dienst. PaaS-Dienste, die nur für das AML verwaltete Subnetz für private Endpunkte verfügbar gemacht wurden, müssen jetzt auch im virtuellen Netzwerk verfügbar gemacht werden, damit die Sichtzeile ü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. Sie würden Integritätsprüfungen verwenden, um sicherzustellen, dass Anrufe nur an Cluster weitergeleitet werden, die ordnungsgemäß funktionieren.

Um mehrere Instanzen effektiv zu unterstützen, empfiehlt es sich, Feinabstimmungsdateien zu externalisieren, z. B. in ein georedundantes Azure Storage-Konto. Dadurch wird der im Azure OpenAI-Dienst pro Region gespeicherte Zustand minimiert. Feinabstimmungen müssen weiterhin pro Instanz durchgeführt werden, um die Modelloptimierung zu hosten.

Es ist wichtig, den erforderlichen Durchsatz in Bezug auf Token pro Minute (TPM) und Anforderungen pro Minute (RPM) zu überwachen, um sicherzustellen, dass Sie genügend TPM aus Ihrem Kontingent zugewiesen haben, um die Nachfrage nach Ihren Bereitstellungen zu erfüllen und zu verhindern, dass Aufrufe ihrer bereitgestellten Modelle gedrosselt werden. Ein Gateway wie Azure API Management (APIM) kann vor Ihren OpenAI-Diensten bereitgestellt werden und kann für wiederholungsversuche konfiguriert werden, wenn vorübergehende Fehler und Drosselung auftreten. APIM kann auch als Trennschalter verwendet werden, um zu verhindern, dass der Dienst mit dem Aufruf überfordert wird und das Kontingent überschreitet.

Azure AI Search – Zuverlässigkeit

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

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

  • Befolgen Sie die Anleitungen zum Überwachen von Azure AI Search.
  • Verwenden Sie Überwachungsmetriken und Protokolle und Leistungsanalysen, um die entsprechende Anzahl von Replikaten zu ermitteln, um abfragebasierte Drosselung und Partitionen zu vermeiden, um eine indexbasierte Drosselung zu vermeiden.

Azure Machine Learning - Zuverlässigkeit

Wenn Sie für Computecluster hinter dem vom Azure Machine Learning verwalteten Onlineendpunkt bereitstellen, sollten Sie die folgenden Anleitungen zur Skalierung in Betracht ziehen:

  • Befolgen Sie die Anweisungen, um Ihre Onlineendpunkte automatisch zu skalieren, um sicherzustellen, dass genügend Kapazität verfügbar ist, um die Nachfrage zu erfüllen. Wenn Nutzungssignale aufgrund der Burst-Nutzung nicht rechtzeitig genug sind, sollten Sie die Überbereitstellung in Betracht ziehen, um zu verhindern, dass Zuverlässigkeitsauswirkungen von zu wenigen Instanzen verfügbar sind.
  • Erwägen Sie das Erstellen von Skalierungsregeln basierend auf Bereitstellungsmetriken wieCPU-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.

Hinweis

Derselbe Skalierbarkeitsleitfaden für App Service von der Basisarchitektur gilt, wenn Sie Ihren Flow für Azure-App Service bereitstellen.

Sicherheit

Diese Architektur implementiert sowohl ein Netzwerk als auch einen Identitätssicherheitsperimeter. Aus Netzwerksicht sollte das Einzige, was über das Internet zugänglich sein sollte, die Chat-Benutzeroberfläche über das App Gateway 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.

Die Netzwerksicherheit wurde im Abschnitt "Netzwerk" erläutert. In diesem Abschnitt werden Identitäts- und Zugriffsverwaltung sowie Sicherheitsüberlegungen für die Schlüsselrotation und die Feinabstimmung des Azure OpenAI-Modells erläutert.

Identitäts- und Zugriffsverwaltung

Der folgende Leitfaden erweitert den Leitfaden zur Identitäts- und Zugriffsverwaltung in der App Service-Basislinie:

  • Erstellen Sie separate verwaltete Identitäten für die folgenden AML-Ressourcen, sofern zutreffend:
    • Arbeitsbereich – wird während der Ablauferstellung und -verwaltung verwendet
    • Computeinstanz – wird beim Testen von Flows verwendet
    • Onlineendpunkt – wird vom bereitgestellten Flow verwendet, wenn er auf einem verwalteten Onlineendpunkt bereitgestellt wird
  • Implementieren von Identitätszugriffssteuerelementen für die Chat-Benutzeroberfläche mithilfe der Microsoft Entra-ID

Azure: Machine Learning RBAC Rollen

Es gibt fünf Standardrollen, mit denen Sie den Zugriff auf Ihren Azure Machine Learning-Arbeitsbereich verwalten können: AzureML Data Scientist, AzureML Compute Operator, Reader, Contributor und Owner. Neben diesen Standardrollen gibt es einen AzureML Workspace Connection Secrets Reader und einen AzureML Registry User, die Zugriff auf Workspace-Ressourcen wie Workspace-Geheimnisse und Registry gewähren.

Diese Architektur folgt dem Prinzip der geringsten Berechtigung, indem nur Rollen zu den oben genannten Identitäten zugewiesen werden, bei denen sie erforderlich sind. Im Folgenden sind die Rollenzuweisungen aufgeführt.

Verwaltete Identität Umfang Rollenzuweisungen
Vom Arbeitsbereich verwaltete Identität Resource group Mitwirkender
Vom Arbeitsbereich verwaltete Identität Arbeitsbereichs-Speicherkonto Mitwirkender an Speicherblobdaten
Vom Arbeitsbereich verwaltete Identität Arbeitsbereichs-Speicherkonto Privilegierter Mitwirkender für Speicherdateidaten
Vom Arbeitsbereich verwaltete Identität Arbeitsbereich-Key Vault Key Vault-Administrator
Vom Arbeitsbereich verwaltete Identität Arbeitsbereich-Containerregistrierung ACRPush
Verwaltete Identität des Onlineendpunkts Arbeitsbereich-Containerregistrierung AcrPull
Verwaltete Identität des Onlineendpunkts Arbeitsbereichs-Speicherkonto Leser von Speicherblobdaten
Verwaltete Identität des Onlineendpunkts Machine Learning-Arbeitsbereich AzureML Workspace Connection Secrets Reader
Verwaltete Identität einer Compute-Instanz Arbeitsbereich-Containerregistrierung ACRPull
Verwaltete Identität einer Compute-Instanz Arbeitsbereichs-Speicherkonto Leser von Speicherblobdaten

Schlüsselrotation

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

  • Speichern Sie den Schlüssel in einem sicheren Speicher wie Azure Key Vault für den On-Demand-Zugriff von autorisierten Clients (z. B. der Azure Web App, der den Aufforderungsflowcontainer hostet).
  • Implementieren Sie eine Schlüsseldrehungsstrategie. Wenn Sie die Schlüssel manuell drehen, sollten Sie eine Schlüsselablaufrichtlinie erstellen und Azure-Richtlinie verwenden, um zu überwachen, ob der Schlüssel gedreht wurde.

OpenAI-Modell Feinabstimmung

Wenn Sie openAI-Modelle in Ihrer Implementierung optimieren, sollten Sie die folgenden Anleitungen beachten:

  • Wenn Sie Trainingsdaten zur Feinabstimmung hochladen, sollten Sie für die Verschlüsselung dieser Daten vom Kunden verwaltete Schlüssel verwenden.
  • Wenn Sie Trainingsdaten in einem Speicher wie Azure Blob Storage speichern, sollten Sie einen vom Kunden verwalteten Schlüssel für die Datenverschlüsselung verwenden, eine verwaltete Identität verwenden, um den Zugriff auf die Daten zu steuern, und einen privaten Endpunkt, um eine Verbindung mit den Daten herzustellen.

Effiziente Leistung

Leistungseffizienz ist die Fähigkeit Ihrer Workload, auf effiziente Weise eine den Anforderungen der Benutzer entsprechende Skalierung auszuführen. Weitere Informationen finden Sie unter Übersicht über die Säule „Leistungseffizienz“.

In diesem Abschnitt werden die Leistungseffizienz aus der Sicht von Azure Search, Azure OpenAI und Azure Machine Learning erläutert.

Azure Search – Leistungseffizienz

Befolgen Sie die Anleitungen zum Analysieren der Leistung in Azure AI Search.

Azure OpenAI – Leistungseffizienz

  • Ermitteln Sie, ob ihre Anwendung einen bereitgestellten Durchsatz erfordert oder ob das Modell für gemeinsames Hosting (Verbrauch) verwendet wird. Der bereitgestellte Durchsatz bietet reservierte Verarbeitungskapazität für Ihre OpenAI-Modellbereitstellungen und sorgt so für vorhersehbare Leistung und Durchsatz für Ihre Modelle. Dieses Abrechnungsmodell unterscheidet sich vom Modell für gemeinsames Hosting (Verbrauchsmodell), das am besten geeignet ist und möglicherweise lauten Nachbarn oder anderen Stressoren auf der Plattform ausgesetzt ist.
  • Für den bereitgestellten Durchsatz sollten Sie die bereitstellungsverwaltete Auslastung überwachen

Azure Machine Learning - Leistungseffizienz

Bei der Bereitstellung auf Azure Machine Learning-Onlineendpunkten:

  • Befolgen Sie die Anleitungen zum Automatischen Skalieren eines Onlineendpunkts, um eng mit der Nachfrage in Einklang zu bleiben, ohne übermäßige Überlastung, insbesondere in Zeiträumen mit geringer Nutzung, zu gewährleisten.
  • Wählen Sie die entsprechende SKU des virtuellen Computers für den Onlineendpunkt aus, um Ihre Leistungsziele zu erfüllen. Sie möchten die Leistung der Anzahl niedrigerer Instanzen und größerer SKUs im Vergleich zur Anzahl größerer Instanzen und kleinerer SKUs testen, um eine optimale Konfiguration zu finden.

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 Übersicht über die Säule „Kostenoptimierung“.

Verwenden Sie den Azure-Preisrechner, um ein Preisbeispiel für dieses Szenario anzuzeigen. Sie müssen das Beispiel an Ihre Verwendung anpassen, da in diesem Beispiel nur die in der Architektur enthaltenen Komponenten enthalten sind. Die teuersten Komponenten im Szenario sind die Berechnung des Chat-UI- &und Aufforderungsflows und Azure AI Search. Suchen Sie daher nach Optimierungen für diese Ressourcen, um die meisten Kosten zu sparen.

Compute

Der Azure Machine Learning-Aufforderungsflow unterstützt mehrere Optionen zum Hosten der ausführbaren Flows. Zu den Optionen gehören verwaltete Onlineendpunkte in Azure Machine Learning, Azure Kubernetes Service, Azure-App Service und Azure Container Service. Jede dieser Optionen verfügt über ein eigenes Abrechnungsmodell. Die Wahl der Berechnung wirkt sich auf die Gesamtkosten der Lösung aus.

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. Dazu müssen Sie im Azure OpenAI-Dienst speziell eine Kombination von Ansätzen verwenden:

  • Steuern von Clients. Clientanforderungen sind die primäre Kostenquelle in einem Verbrauchsmodell, z. B. die Steuerung des Clientverhaltens ist wichtig. Alle Clients sollten:
    • Vorab genehmigt sein. Vermeiden Sie die Bereitstellung des Diensts auf eine Weise, die kostenlosen Zugriff unterstützt. Beschränken Sie den Zugriff sowohl durch Netzwerk- als auch durch Identitätskontrollen (Schlüssel oder 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 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. Wenn Sie das richtige Modell für den Anwendungsfall verwenden, können Sie sicherstellen, dass Sie nicht für ein teureres Modell ausstehen, wenn ein kostengü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.
  • Grundlegendes zu Abrechnungsunterbrechungen – Feinabstimmung wird pro Stunde berechnet. Um die effizienteste zu sein, sollten Sie so viel von der verfügbaren Zeit pro Stunde nutzen, um die Feinabstimmungsergebnisse zu verbessern, ohne einfach in den nächsten Abrechnungszeitraum zu rutschen. Die Kosten für 100 Bilder aus der Bildgenerierung entsprechen ebenfalls den Kosten für 1 Bild. Maximieren Sie die Preisunterbrechungspunkte zu Ihrem Vorteil.
  • Verstehen von Abrechnungsmodellen – Azure OpenAI ist auch über das bereitgestellte Durchsatzangebot in einem verpflichtungsbasierten Abrechnungsmodell verfügbar. Sobald Sie vorhersagbare Nutzungsmuster haben, bewerten Sie den Wechsel zu diesem Vorkaufsabrechnungsmodell, wenn es berechnet, dass es bei Ihrem Nutzungsvolumen kostengünstiger ist.
  • Festlegen von Bereitstellungsgrenzwerten – Stellen Sie sicher, dass alle Bereitstellungskontingente nur Modellen zugeordnet werden, die voraussichtlich Teil der Arbeitsauslastung sind, auf Modellbasis. Der Durchsatz für bereits bereitgestellte Modelle ist nicht auf dieses bereitgestellte Kontingent beschränkt, während das dynamische Kontingent aktiviert ist. Beachten Sie, dass sich das Kontingent nicht direkt auf die Kosten auswirkt und die Kosten variieren können.
  • Überwachen Sie die Nutzung von Pay-as-you-go – Wenn Sie pay-as-you-go verwenden, überwachen Sie die Nutzung von Token pro Minute (TPM) und Anforderungen pro Minute (RPM). Nutzen Sie diese Informationen, um architektonische Entwurfsentscheidungen zu treffen, z. B. welche Modelle verwendet werden sollen, und um die Aufforderungsgrößen zu optimieren.
  • Überwachen Sie die bereitgestellte Durchsatznutzung– Wenn Sie den bereitgestellten Durchsatz verwenden, überwachen Sie die bereitstellungsverwaltete Nutzung, um sicherzustellen, dass Sie den bereitgestellten Durchsatz, den Sie erworben haben, nicht unterlasten.
  • Kostenmanagement – Befolgen Sie die Anleitungen zur Verwendung von Kostenverwaltungsfeatures mit OpenAI, um Kosten zu überwachen, Budgets für die Kostenverwaltung festzulegen und Warnungen zu erstellen, um die Beteiligten über Risiken oder Anomalien zu informieren.

Vorgänge mit großen Sprachmodellen (LLMOps)

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

Entwicklung

Der Azure Machine Learning-Aufforderungsflow bietet sowohl eine browserbasierte Erstellungserfahrung im Azure Machine Learning Studio als auch über eine VS Code-Erweiterung. Beide Optionen speichern den Flowcode als Dateien. Bei Verwendung von Azure Machine Learning Studio werden die Dateien in einem Azure Storage-Konto gespeichert. Beim Arbeiten in VS Code 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 VS Code-Erweiterung und das Prompt Flow SDK/CLI für die Entwicklung verwenden. Aufforderungsflowautoren können ihre Flüsse aus VS 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

Sie sollten die in einer Chatanwendung verwendeten Flows genau so testen, wie Sie andere Softwareartefakte testen. Es ist schwierig, eine einzelne "richtige" Antwort für LLM-Ausgaben anzugeben und zu bestätigen, aber Sie können eine LLM selbst verwenden, um Antworten auszuwerten. Erwägen Sie die Implementierung der folgenden automatisierten Auswertungen Ihrer LLM-Flows:

  • Klassifizierungsgenauigkeit: Bewertet, ob die LLM eine "richtige" oder "falsche" Bewertung erhält, und aggregiert die Ergebnisse, um eine Genauigkeitsstufe zu erzielen.
  • 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.
  • Bodenständigkeit gegen den Kontext: Wertet aus, wie gut die vorhergesagten Antworten des Modells auf vorkonfigurierten Kontext basieren. Selbst wenn die Antworten von LLM korrekt sind, wenn sie nicht anhand des angegebenen Kontexts überprüft werden können, werden solche Antworten nicht geerdet.
  • 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 LLMs zum Generieren von Daten in Ihrem goldenen Datensatz.

Bereitstellungsflow

Diagram that shows the deployment flow for a prompt flow.

Abbildung 5: Bereitstellung des Aufforderungsflows

  1. Der Aufforderungstechniker/Data-Wissenschaftler öffnet eine Featurebranch, in der sie an der spezifischen Aufgabe oder Funktion arbeiten. Der Aufforderungstechniker/Data-Wissenschaftler durchläuft den Flow mithilfe des Aufforderungsflows für VS-Code, verpflichtet regelmäßig Änderungen und verschiebt diese Änderungen an die Featurebranch.

  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 Wissen mit Eingabeufforderungsflows und sind 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:

    a. 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 Azure Machine Learning-Registrierung, wenn Änderungen erkannt werden

    b. Die CD-Pipeline wird nach Abschluss der CI-Pipeline ausgelöst. Dieser Flow führt die folgenden Schritte aus:

    • Stellt den Flow aus der Azure Machine Learning-Registrierung auf einem Azure 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 & 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 Veröffentlichung in einer Liveumgebung werden die operativen Aufgaben der Überwachung von Leistungsmetriken und die Auswertung der bereitgestellten LLM durchgeführt. Dies umfasst u. a.:

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

Leitfaden zur Bereitstellung

Mit Azure Machine Learning-Endpunkten können Sie Modelle auf eine Weise bereitstellen, die flexibilität bei der Veröffentlichung in der 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: Nicht nur Blue/Green-Bereitstellungen sind effektiv für das sichere Rollout von Änderungen, sie können auch verwendet werden, um ein neues Verhalten bereitzustellen, das es einer Teilmenge von Benutzern ermöglicht, 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.
  • Verwenden Sie beim Bereitstellen Ihres Flows im netzwerkisolierenden Azure Machine Learning-Arbeitsbereich einen selbst gehosteten Agent, um Artefakte für Ihre Azure-Ressourcen bereitzustellen.
  • Die Azure Machine Learning-Modellregistrierung sollte nur aktualisiert werden, wenn Änderungen am Modell vorgenommen werden.
  • Die LLM, die Flows und die Client-UI 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.
  • Bei der Entwicklung und Bereitstellung mehrerer Flows sollte jeder Flow über einen eigenen Lebenszyklus verfügen, der eine lose gekoppelte Erfahrung ermöglicht, wenn es um die Förderung von Experimenten zur Produktion geht.

Infrastruktur

Bei der Bereitstellung der geplanten End-to-End-Chat-Komponenten von Azure OpenAI sind einige der bereitgestellten Dienste in der Architektur grundsätzlich und dauerhaft, während andere Komponenten in der Natur ephemer sind, 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.

  • Azure Machine Learning-Arbeitsbereich
  • Azure Storage-Konto für den Azure Machine Learning-Arbeitsbereich
  • Azure Container Registry
  • Azure KI Cognitive Search
  • Azure OpenAI
  • Azure Application Insights
  • Azure Bastion
  • Azure Virtual Machine für die Jumpbox

Kurzlebige Komponenten

Einige Azure-Ressourcen sind enger mit dem Entwurf bestimmter Aufforderungsflows gekoppelt, sodass diese Ressourcen an den Lebenszyklus der Komponente gebunden und in dieser Architektur kurzlebig werden. Sie sind betroffen, wenn sich die Workload weiterentwickelt, 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 Azure 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 Containerregistrierung aktualisiert werden.
  • Ein Azure Machine Learning-Endpunkt wird erstellt, wenn ein Aufforderungsflow bereitgestellt wird, 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 Azure 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.

Überwachung

Die Diagnosen sind für alle Dienste konfiguriert. Alle Dienste, aber Azure Machine Learning und Azure-App Dienst sind so konfiguriert, dass alle Protokolle erfasst werden. Die Azure Machine Learning-Diagnose ist so konfiguriert, dass die Überwachungsprotokolle erfasst werden, die alle Ressourcenprotokolle sind, die Kundeninteraktionen mit Daten oder den Einstellungen des Diensts aufzeichnen. Azure-App Dienst ist für die Erfassung von AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs und AppServicePlatformLogs konfiguriert.

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:

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

Nächste Schritte

Weitere Informationen zu Azure OpenAI.