LLMs und Azure OpenAI im Retrieval Augmented Generation (RAG)-Muster (Vorschau)

Wichtig

Dies ist eine Vorschauversion. Diese Informationen beziehen sich auf eine Vorabversionsfunktion, die vor ihrer Veröffentlichung möglicherweise erheblich geändert wird. Microsoft übernimmt hinsichtlich der hier bereitgestellten Informationen keine Gewährleistungen, seien sie ausdrücklich oder konkludent.

Dieser Artikel bietet ein anschauliches Beispiel für die Verwendung von Large Language Models (LLMs) und Azure OpenAI im Kontext des Retrieval Augmented Generation (RAG)-Musters. Insbesondere wird untersucht, wie diese Technologien in souveränen Zielzonen angewendet werden können, wobei auch wichtige Leitlinien berücksichtigt werden.

Szenario

Ein gängiges Szenario ist die Verwendung von LLMs, um über das Retrieval Augmented Generation (RAG)-Muster Unterhaltungen zu führen, bei denen Ihre eigenen Daten verwendet werden. Mit diesem Muster können Sie die Denkfähigkeiten von LLMs nutzen und Antworten auf der Grundlage Ihrer spezifischen Daten generieren, ohne das Modell fein abstimmen zu müssen. Es erleichtert die nahtlose Integration von LLMs in Ihre bestehenden Geschäftsprozesse oder Lösungen.

Cloud for Sovereignty – KI- und LLM-Referenzarchitektur

Microsoft Cloud for Sovereignty bietet eine Referenzarchitektur, die eine typische Retrieval Augmented Generation (RAG)-Architektur innerhalb einer souveränen Landezone (SLZ) veranschaulicht. Es bietet einen Überblick über gängige und empfohlene Implementierungstechnologien, Terminologie, Technologieprinzipien, gängige Konfigurationsumgebungen und die Zusammenstellung anwendbarer Dienste.

Laden Sie eine druckbare PDF-Datei dieses Referenzarchitekturdiagramms herunter.

Dies sind wichtigsten Phasen/Dataflows:

Anwendungszielzonen

In der Verwaltungsgruppenhierarchie werden diese Dienste in einem Abonnement innerhalb einer nicht vertraulichen Verwaltungsgruppe platziert.

Datenquellen und Transformations-Pipelines

Innerhalb einer Organisation sind für Branchenabläufe häufig Datenquellen und Transformations-Pipelines vorhanden. Bei der Integration von LLM-Anwendungen, wie etwa RAG-Implementierungen, in vorhandene Daten werden diese zu neuen Workloads.

Um die Datenflusskontrolle zu gewährleisten, empfiehlt die Referenzarchitektur an Datendomänen ausgerichtete Datenzielzonen für Datenquellen und platziert Datentransformations-Pipelines in der Nähe dieser Quellen, um Datenprodukte zu erstellen, die von LLM-Anwendungen verwendet werden. Dieser Ansatz gewährleistet eine präzise Verwaltung der Daten, die der separat gehosteten LLM-basierten Lösung bereitgestellt werden.

Datentransformationskomponenten nutzen verschiedene Technologien und Dienste, um Daten in ein Format zu transformieren, das von einer LLM-basierten Anwendung mittels semantischer oder Vektorsuche durchsucht und zu Grundlagezwecken verwendet werden kann. Diese Pipelines können eigenständig arbeiten oder KI-Dienste wie Azure-KI-Dienste oder Azure OpenAI verwenden, um die Daten für die Eingabe in eine Vektorsuch- oder semantische Suchdatenbank zu transformieren.

Wenn Sie KI-Dienste verwenden, werden diese durch Netzwerk-Peering immer über ihre privaten Endpunkte verfügbar gemacht (über den Hub oder direkt). Aus Governance-, Sicherheits- und Compliance-Gründen sind die Datentransformationskomponenten befugt, zu bestimmen, welche Daten und in welchem Format einer Suchdatenbank für den LLM-Workload bereitgestellt werden.

Datentransformationskomponenten können verschiedene Arten von Datenquellen nutzen, um den Suchdatenbanken, auf die LLM-Workloads angewiesen sind, Daten mit optimalen Ergebnissen anzubieten. Diese Datenquellen können je nach Kundenumgebung SQL-Datenbanken, Data Lakes oder sogar virtuelle Computer sein, die benutzerdefinierte Datenlösungen hosten.

Auf Datenquellen sollte nicht direkt über die Orchestrator-App zugegriffen werden können. Stattdessen sollten diese Ressourcen nur innerhalb der privaten Grenzen des virtuellen Netzwerks verfügbar sein. Dies erfordert eine direkte Integration von Microsoft Azure Virtual Network (also wie es bei VMs der Fall ist), Private Link-Dienste oder Endpunkte für Virtual Network-Dienste (nur wenn Private Link oder die direkte Virtual Network-Integration nicht verfügbar ist).

KI- und LLM-bezogene Komponenten

KI- und LLM-bezogene Komponenten sollten als Workloads in einem eigenen Abonnement unter der Verwaltungsgruppe Corp oder Online gehostet werden (je nachdem, ob öffentlicher Zugriff erforderlich ist oder nicht). Zu diesen Komponenten gehören:

Der Azure OpenAI Dienst kapselt die Vorgänge von LLMs wie GPT und Text Embeddings wie Ada und macht sie über von Azure OpenAI bereitgestellte Standard-APIs für die Orchestrator-App zugänglich.

Eine Orchestrator-App fungiert als Front-End mit einer API oder UX-basierten Schnittstelle und orchestriert die verschiedenen Schritte, die zum Erstellen RAG-basierter Erlebnisse erforderlich sind. Oft handelt es sich dabei um eine Webanwendung oder eine Web-API. Dies sind die typischen Schritte:

• Abrufen von Daten aus semantischen Suchmaschinen zum sofortigen Grounding
• Abrufen von Daten aus Datenquellen zum sofortigen Grounding
• korrektes Verketten verschiedener Anfragen an das LLM

Die Orchestrator-App verwaltet den Verlauf der gesendeten Anfragen und empfangenen Antworten, um sicherzustellen, dass der Dienst Azure OpenAI basierend auf vorherigen Interaktionen geerdet wird. Beispielsweise verwaltet oder speichert die Orchestrator-App den Verlauf der Unterhaltungssitzung in einer Chat-ähnlichen Umgebung wie ChatGPT oder Bing Chat, sodass er vom LLM-Dienst-Backend im Unterhaltungsfluss berücksichtigt wird.

In einer Online-Umgebung sollte die Orchestrator-App-Endpunkt der einzige sein, der über einen öffentlichen Endpunkt bereitgestellt wird, der durch eine Web Application Firewall und DDoS-Schutzdienste geschützt ist. Beim Hosting in einer Corp-Umgebung ohne öffentliche Endpunkte: Der Orchestrator wird entweder in einem Dienst gehostet, der direkt in das virtuelle Netzwerk integriert ist, z. B. virtuelle Computer oder VM-Skalierungssätze, oder es werden Dienste verwendet, die Private Link- oder virtuelle Netzwerkdienstendpunkte unterstützen, wie dies bei Azure App Services der Fall ist.

Suchdienste bietet Daten aus verschiedenen Datenquellen in einem für die effiziente Nutzung optimierten Format zur schnellen Bereitstellung von LLM-Diensten. Um die besten Ergebnisse für ein sofortiges Grounding auf Basis von Suchdiensten zu erzielen, die durch Azure AI Search unterstützt werden, schlägt Microsoft eine Kombination aus Vektorisierung und semantischer Suche vor. Die Verwendung der semantischen Bewertung verbessert die Suchrelevanz messbar, indem sie das Sprachverständnis zur Bewertung der Suchergebnisse nutzt. Dadurch wird das Benutzererlebnis von RAG-Anwendungen verbessert, da das sofortige Grounding durch bessere Suchergebnisse des Suchdienstes vor dem Senden einer Anfrage an das LLM genauer wird.

Eine Kombination von KI-Diensten kann verwendet werden, um über den Orchestrator individuelle Erlebnisse für Endbenutzer zu schaffen oder Datenaufnahmeprozesse zu optimieren. Stellen Sie sich vor, Sie verwenden einen Formularerkennungsdienst wie Azure AI-Dokumentinformationen, um strukturierte Informationen aus Formularen zu extrahieren und Benutzereingaben effizient zu verarbeiten und zusammenzufassen. Dieser Dienst kann dann mit einem LLM zusammenarbeiten, um die wichtigsten Erkenntnisse aus diesen erkannten Formulareingaben zusammenzufassen. Ein anderes Szenario besteht darin, einen Dokumenterkennungsdienst zu verwenden, um Dokumente in verschiedenen Formaten wie PDFs oder Word-Dokumenten in Text umzuwandeln. Anschließend kann ein LLM-Texteinbettungsdienst diesen erkannten Text zur weiteren Analyse vektorisieren.

Für alle Komponenten werden private verknüpfen-Dienste bereitgestellt, sodass auf alle Dienste nur innerhalb des privaten Umgebung zugegriffen werden kann. Die einzige Ausnahme könnte die Orchestrator-App sein, die, wenn sie in einer Online Zielzone gehostet wird, öffentlich hinter einer Web Application Firewall oder vergleichbaren Diensten angeboten werden könnte.

Infrastrukturkomponenten

Infrastrukturkomponenten können entweder als Teil des Workloads oder zentral in einem Hub oder Identitätsabonnement gehostet werden.

Die zentrale Infrastrukturkomponente der Implementierung einer souveränen Zielzone ist der Platform Connectivity Hub, ein virtuelles Netzwerk, das von jeder Bereitstellung einer souveränen Zielzone bereitgestellt wird. Sie wird im Konnektivitätsabonnement innerhalb der Verwaltungsgruppe Plattform platziert.

Gemeinsam genutzte Netzwerkkomponenten werden im virtuellen Hub-Netzwerk platziert. Zu diesen Komponenten gehören in der Regel:

• ExpressRoute-Schaltungen oder VPN-Gateways für die Verbindung mit dem Unternehmensnetzwerk eines Unternehmens, einer Agentur oder einer Organisation.

• Firewalls können mithilfe von Appliances oder einer Kombination von Azure-Firewall-Angeboten, einschließlich Web Application Firewall, implementiert werden. Diese Lösungen ermöglichen die Überprüfung, die Filterung und das Routing des Datenverkehrs.

• DDoS-Schutz Komponenten zum Schutz von Workloads vor Distributed-Denial-of-Service-Angriffen.

• Private DNS-Zonen für alle Arten von Diensten, die in der gesamten virtuellen Rechenzentrumslandschaft verwendet werden, implementiert mit Landing Zones.

• Virtual Network Peering zum Verbinden virtueller Netzwerke verschiedener Workloads wie Datenquellen, Transformation und LLM-Komponenten über das Hub-Netzwerk.

• Richtlinien steuern bei Bedarf den Verkehrsfluss durch die Firewalls des Hubs.

Überlegungen

Das Referenzarchitekturdiagramm zeigt eine repräsentative Beispielarchitektur mit den typischen Komponenten eines LLM RAG-basierten Workloads im Kontext einer souveränen Zielzone. Dabei sind mehrere Aspekte zu berücksichtigen, die in den vorherigen Abschnitten nicht behandelt wurden.

Ausrichtung an den Prinzipien des Well-Architected Framework und des Cloud Adoption Framework

In den vorherigen Abschnitten wurden einige Ausrichtungsaspekte im Zusammenhang mit dem Well-Architected Framework (WAF) und dem Cloud Adoption Framework (CAF) kurz erwähnt. Es ist wichtig zu beachten, dass alle Architekturentscheidungen vollständig auf die Kernprinzipien von CAF- und Azure-Zielzonen, CAF Cloud-Scale Analytics und WAF, einschließlich der WAF-Perspektive in Azure OpenAI, abgestimmt sein sollten.

Überlegungen zum Infrastrukturdesign im Zusammenhang mit Leitlinien

Während der Umgang mit Leitlinien in Zielzonenumgebungen ein Standardverfahren ist, müssen für LLM- und KI-Workloads in mehreren Bereichen andere Überlegungen angestellt werden. Am besten folgen Sie beim Entwerfen und Definieren der Infrastruktur für das Workload-Abonnement der Azure Security Baseline-Konformität und den Standards der Sovereignty Baseline Policy-Initiative.

Folgende Überlegungen, die für LLM RAG-basierte Anwendungen aus diesen Standards hervorgehoben werden sollten, sind am wichtigsten:

Datenresidenz und Regionsauswahl

Die Souveränität stellt strenge Anforderungen an den Datenspeicherort und kann daher die Bereitstellung auf bestimmte Azure-Regionen in einer SLZ beschränken. Die Auswahl einer Region für LLM-Workloads wird durch die Verfügbarkeit der erforderlichen Dienste eingeschränkt:

• Überprüfen Sie aus Gründen der Datenresidenz und/oder Nähe, ob Azure OpenAI und Azure AI Search beide in der Zielregion verfügbar sind, in der Sie Ihre Daten und Ihren Workload hosten. Darüber hinaus sind diese Dienste aus Leistungssicht für das Anwendungserlebnis des Endbenutzers wichtig.

• Zweitens ist bei Betrachtung von Azure OpenAI die Verfügbarkeit der jeweiligen LLM-Modelle wichtig, da nicht alle Modelle in allen Regionen gleichermaßen verfügbar sind.

• Wenn Datenquellen oder andere kognitive Dienste in Ihrer angegebenen Zielregion nicht verfügbar sind, können Sie diese möglicherweise in einer anderen Region finden und entsprechend Ihren Anforderungen an die Datenaufbewahrung betreiben. Aus Leistungsgründen müssen sich der Azure OpenAI-Dienst und Azure AI Search in derselben Region wie die Orchestrator-App befinden.

Netzwerk

Öffentliche Endpunkte sind in Corp-Umgebungen nicht erlaubt. Daher müssen alle Dienste in einem virtuellen Netzwerk gekapselt werden. Je nach Dienst werden möglicherweise direkte Kapselungsfunktionen wie VMs oder AKS-Cluster, Private Link oder Virtual Network-Dienstendpunkte geboten. VNET-Dienstendpunkte sollten nach Möglichkeit durch Private Link ersetzt werden.

Zusätzlich zur Kapselung muss der öffentliche Zugriff für alle Dienste deaktiviert werden. Schließlich sollte die Richtliniendurchsetzung mithilfe von Azure Policy aktiviert werden, sodass der öffentliche Zugriff nie versehentlich für Dienste aktiviert werden kann, für die keine entsprechenden Verweigerungsrichtlinien erstellt werden können. Die Defense-in-Depth-Strategie besteht darin, die entsprechenden Überwachungsfunktionen für alle Dienste zu aktivieren.

Verschlüsselung ruhender und in der Übertragung befindlicher Daten

Die meisten Dienste in Azure unterstützen sowohl die Verschlüsselung während der Übertragung als auch im Ruhezustand. Aktivieren Sie die Verschlüsselung im Ruhezustand und während der Übertragung über alle Dienste hinweg, sofern verfügbar. Aktivieren Sie die neuste TLS-Version, derzeit TLS 1.2, für die Verschlüsselung während der Übertragung.

Verwaltete Identitäten

Verwenden Sie verwaltete Identitäten für alle Dienste und die Kommunikation zwischen Diensten, um die Verwaltung von Geheimnissen für Anmeldeinformationen zu vermeiden.

Schlüsselrotation im Key Vault

Wenn Sicherheitsressourcen wie Zertifikate erforderlich sind, aktivieren Sie die Schlüsselrotation für diese Geheimnisse in Key Vault, um die Konformität aufrechtzuerhalten.

Netzwerk- und Anwendungssicherheitsgruppen

In einer souveränen, sicheren Umgebung wird die Verwendung von Network Security Groups (NSG) und Application Security Groups (ASG) erzwungen. Fehlende Sicherheitsgruppen führen zu nicht konformen Bereitstellungen. Die üblichen SSL-Ports sind für die meisten Dienste nützlich, auf die LLM/RAG-Workloads angewiesen sind, da sie auf HTTPS basieren. Für die Datenerfassung aus den Quellen in die Such- und Vektordatenbanken werden bestimmte Ports benötigt. Öffentliche Endpunkte sind in Corp-Zielzonen nicht erlaubt. Daher müssen alle Dienste in Zielzonen nur im virtuellen Netzwerk zugänglich sein, was die Verwendung von Private Link- oder Virtual Network-Dienstendpunkten für PaaS-Dienste erfordert.

Weitere Leitlinien zu Sicherheit und Souveränität

Die wichtigsten und offensichtlichsten Leitlinien für Ihre Infrastruktur und Ihr Anwendungsdesign, die in früheren Abschnitten behandelt wurden, können auch außerhalb von souveränen Zielzonen oder Azure-Zielzonen wiederverwendet werden. Andere globale Richtlinien sind an zentral verwaltete Ressourcen wie Log Analytics-Arbeitsbereiche oder Microsoft Sentinel-Bereitstellungen in Zielzonen im Unternehmensmaßstab gebunden. Beim Entwurf Ihrer Infrastruktur und Ihrer Anwendung müssen Sie diese zentral verwalteten Ressourcen unbedingt berücksichtigen. Andernfalls kann es nach der Bereitstellung zu zusätzlichem Aufwand und Zeitaufwand kommen. Glücklicherweise kann das Feature zur Richtlinienkonformität von Azure nicht konforme Ressourcen nach der Bereitstellung identifizieren. Darüber hinaus bieten sowohl souveräne Zielzonen als auch Azure-Zielzonen DeployIfNotExists-Richtlinien für zahlreiche Ressourcen, was den Prozess weiter vereinfacht.

Einige Beispiele für solche Leitlinien sind:

• Aktivierung der Anmeldung in zentral verwalteten Log Analytics-Arbeitsbereichen.

• Integration in Azure Security Center oder Microsoft Defender for Cloud.

• Integration in Security Information & Event Management (SIEM)-Suiten wie Microsoft Sentinel.

• Integration in zentral verwaltete Firewalls, Web Application Firewalls oder DDoS-Schutz.

Dies sind nur einige Leitlinien, die Sie nach Ihrer ersten Bereitstellung möglicherweise als Anforderungen identifizieren. Es wird empfohlen, Ihre Bereitstellungen in einer Testzielzone zu testen und die Einhaltung dieser Leitlinien iterativ in Ihre Infrastruktur und Anwendungscodebasis zu integrieren. Wenn dies nicht ganz möglich ist, können viele dieser Leitlinien nach der Bereitstellung mit DeployIfNotExists-Richtlinien berücksichtigt werden.

Dieses Szenario bereitstellen

Um die Vorteile von Large Language Models (LLMs) und Azure OpenAI basierend auf dem Retrieval Augmented Generation (RAG)-Muster innerhalb von souveränen Landungszonen zu nutzen, sollten Sie zunächst eine souveräne Landungszone (SLZ) bereitstellen und konfigurieren und Sovereignty Baseline-Richtlinieninitiativen anwenden. Eine detaillierte Übersicht über ein SLZ und alle seine Funktionen finden Sie in der Dokumentation zur souveränen Zielzone auf GitHub.

SLZ stellt eine Umgebung bereit, die Leitlinien durch Richtlinien und Richtliniensätze, Sicherheitsdurchsetzung und eine konsistente Basisinfrastruktur für die Bereitstellung von Workloads und Anwendungen bietet. SLZ basiert auf Azure Landing Zones und erweitert es um Leitplanken und Sicherheitskontrollen, die speziell auf Souveränitätsanforderungen zugeschnitten sind.

Um Kunden dabei zu helfen, die Wertschöpfungszeit zu verkürzen und sie gleichzeitig bei der Erfüllung ihrer Compliance-Ziele zu unterstützen, enthält Microsoft Cloud for Sovereignty gebrauchsfertige Workload-Vorlagen, die konsistent bereitgestellt und auf wiederholbare Weise betrieben werden können. Die Workload-Vorlagen sind auf Sovereignty Baseline-Richtlinieninitiativen, Cloud for Sovereignty Policy Portfolio und Standardrichtlinien für die Azure Landing Zone ausgerichtet.

Informationen Assistent Agent-Vorlage

Die Informationsvorlage Assistent Agent bietet Organisationen eine Ausgangsbasis zeigen zum Aufbau ihrer eigenen benutzerdefinierten generativen KI-Fähigkeit, um die Leistungsfähigkeit von Azure OpenAI auf Organisationsbenutzer und ihre Domänendaten auszudehnen, ohne das Modell zu optimieren. Er kann in der Cloud for Sovereignty eingesetzt werden und ist auf die Referenzarchitektur und die Anleitungen in diesem Artikel abgestimmt. Informationen: Die Vorlage Assistent Agent ist mit dem Verwaltungsgruppenbereich Sovereign Landing Zone Online unter Verwendung der Bereitstellungskonfiguration Sicherer Modus kompatibel. Die Unterstützung für den Unternehmensverwaltungsgruppenbereich ist in Kürze verfügbar.

Die Vorlage Agent ist eine Kombination aus Code, Dokumentation und Schulungsressourcen, die Kunden und Partnern kostenlos zur Verfügung gestellt wird und die Wertschöpfungszeit verkürzen kann.

Weitere Informationen zum Bereitstellen und Konfigurieren der Information Assistent finden Sie in der Informationsvorlage Assistent Agent Dokumentation auf GitHub. Anwendungsfälle, die Sie mit dieser Agent-Vorlage erreichen können, finden Sie unter Informationen Assistent Video.