Retrieval-Augmented Generation (RAG) ist ein Muster zum Erstellen von Anwendungen, bei denen grundlagenbasierte Modelle verwendet werden, um proprietäre Informationen oder andere Informationen zu begründen, die nicht öffentlich im Internet verfügbar sind. Im Allgemeinen ruft eine Clientanwendung eine Orchestrierungsebene auf, die relevante Informationen aus einem Datenspeicher abruft, z. B. eine Vektordatenbank. Die Orchestrierungsebene übergibt diese Daten als Teil des Kontexts als Erdungsdaten an das grundlegende Modell.
Eine mehrinstanzenfähige Lösung wird von mehreren Kunden verwendet, wobei jeder Kunde (Mandant) aus mehreren Benutzern aus derselben Organisation, einem Unternehmen oder einer Gruppe besteht. In mehrinstanzenfähigen Szenarien müssen Sie sicherstellen, dass Mandanten oder Einzelpersonen innerhalb von Mandanten nur Erdungsdaten integrieren können, die sie sehen dürfen.
Obwohl es mehrinstanzenfähige Bedenken gibt, die darüber hinausgehen, dass Benutzer nur auf die Informationen zugreifen, die sie sehen sollen, konzentriert sich dieser Artikel auf diesen Aspekt der Mehrinstanzenfähigkeit. Der Artikel beginnt mit einer Übersicht über single tenant RAG-Architekturen, erörtert die Herausforderungen hinsichtlich der Multitenantanz mit RAG und einige gängige Ansätze und schließt mit überlegungen und Empfehlungen für sichere Mandanten ab.
Hinweis
In diesem Artikel werden einige azure OpenAI-spezifische Features wie Azure OpenAI On Your Data erläutert. Das heißt, die meisten in diesem Dokument erörterten Prinzipien gelten für die meisten grundlegenden KI-Modelle, unabhängig von ihrer Hostplattform.
Single Tenant RAG-Architektur mit Orchestrator
Abbildung 1. Single-Tenant RAG-Architektur
Workflow
In dieser MANDANTEN-RAG-Architektur hat ein Orchestrator die Verantwortung, relevante proprietäre Mandantendaten aus den Datenspeichern abzurufen und als Grundlage für das Basismodell bereitzustellen. Nachfolgend sehen Sie einen allgemeinen Workflow:
- Ein Benutzer gibt eine Anforderung an die intelligente Webanwendung aus.
- Ein Identitätsanbieter authentifiziert den Anforderer.
- Die intelligente Anwendung ruft die Orchestrator-API mit der Benutzerabfrage und dem Autorisierungstoken für den Benutzer auf.
- Die Orchestrierungslogik extrahiert die Abfrage des Benutzers aus der Anforderung und ruft den entsprechenden Datenspeicher auf, um relevante Erdungsdaten für die Abfrage abzurufen. Die Erdungsdaten werden der Eingabeaufforderung hinzugefügt, die an das grundlegende Modell gesendet wird, z. B. ein Modell, das in Azure OpenAI verfügbar gemacht wird, im nächsten Schritt.
- Die Orchestrierungslogik stellt eine Verbindung mit der Inferencing-API des Basismodells her und sendet die Eingabeaufforderung, die die abgerufenen Erdungsdaten enthält. Die Ergebnisse werden an die intelligente Anwendung zurückgegeben.
Weitere Informationen zu den Details von RAG finden Sie unter Entwerfen und Entwickeln einer RAG-Lösung.
Single Tenant RAG-Architektur mit direktem Datenzugriff
Eine Variante der RAG-Architektur eines einzelnen Mandanten nutzt die Möglichkeit des Azure OpenAI-Diensts, direkt in Datenspeicher wie Azure Search zu integrieren. In dieser Architektur haben Sie entweder keinen eigenen Orchestrator, oder Ihr Orchestrator hat weniger Verantwortlichkeiten. Die Azure OpenAI-API hat die Verantwortung, den Datenspeicher aufzurufen, um die Erdungsdaten abzurufen und diese Daten an das Sprachmodell zu übergeben. Sie haben wiederum weniger Kontrolle darüber, welche Erdungsdaten abgerufen werden sollen, und die Relevanz dieser Daten.
Hinweis
Der von Microsoft verwaltete Azure OpenAI-Dienst ist in den Datenspeicher integriert. Das Modell selbst lässt sich nicht in die Datenspeicher integrieren. Das Modell empfängt Erdungsdaten genau so, wie es der Fall ist, wenn die Daten von einem Orchestrator abgerufen werden.
Abbildung 2. Single-Tenant RAG-Architektur mit direktem Datenzugriff vom Azure OpenAI-Dienst
Workflow
In dieser RAG-Architektur hat der Dienst, der das Basismodell bereitstellt, die Verantwortung, die entsprechenden proprietären Mandantendaten aus den Datenspeichern abzurufen und diese Daten als Erdungsdaten in das Basismodell zu verwenden. Im Folgenden finden Sie einen allgemeinen Workflow (kursiv formatierte Schritte sind identisch mit der Single-Tenant RAG-Architektur mit Orchestratorworkflow):
- Ein Benutzer gibt eine Anforderung an die intelligente Webanwendung aus.
- Ein Identitätsanbieter authentifiziert den Anforderer.
- Die intelligente Anwendung ruft dann den Azure OpenAI-Dienst mit der Benutzerabfrage auf.
- Der Azure OpenAI-Dienst stellt eine Verbindung mit unterstützten Datenspeichern wie Azure AI Search und Azure Blob Storage her, um die Erdungsdaten abzurufen. Die Erdungsdaten werden als Teil des Kontexts verwendet, wenn der Azure OpenAI-Dienst das OpenAI-Sprachmodell aufruft. Die Ergebnisse werden an die intelligente Anwendung zurückgegeben.
Um diese Architektur in einer Mehrinstanzenlösung zu berücksichtigen, muss der Dienst, z. B. Azure OpenAI, die direkt auf die Erdungsdaten zugreift, die von Ihrer Lösung erforderliche mehrinstanzenfähige Logik unterstützen.
Mehrinstanzenfähigkeit in RAG-Architektur
Bei mehrinstanzenfähigen Lösungen können Mandantendaten in einem mandantenspezifischen Speicher vorhanden sein oder mit anderen Mandanten in einem mehrinstanzenfähigen Speicher koexistieren. Es können auch Daten in einem Speicher vorhanden sein, der über Mandanten hinweg freigegeben wird. Es sollten nur Daten verwendet werden, die der Benutzer sehen darf, als Erdungsdaten. Die Benutzer sollten nur allgemeine (alle Mandanten)-Daten oder -Daten von ihrem Mandanten mit Filterregeln sehen, um sicherzustellen, dass sie nur Daten sehen, die sie anzeigen dürfen.
Abbildung 3: RAG-Architektur – mit mehreren Datenspeichermandanten
Workflow
Dieser Workflow ist mit Ausnahme von Schritt 4 identisch mit der Rag-Architektur eines einzelnen Mandanten mit Orchestrator .
- Ein Benutzer gibt eine Anforderung an die intelligente Webanwendung aus.
- Ein Identitätsanbieter authentifiziert den Anforderer.
- Die intelligente Anwendung ruft die Orchestrator-API mit der Benutzerabfrage und dem Autorisierungstoken für den Benutzer auf.
- Die Orchestrierungslogik extrahiert die Abfrage des Benutzers aus der Anforderung und ruft die entsprechenden Datenspeicher auf, um mandantenautorisierte, relevante Erdungsdaten für die Abfrage abzurufen. Die grundlegenden Daten werden dem Prompt hinzugefügt, der im nächsten Schritt an Azure OpenAI gesendet wird. Einige oder alle der folgenden Schritte sind beteiligt:
- Die Orchestrierungslogik ruft das Erding von Daten aus der entsprechenden mandantenspezifischen Datenspeicherinstanz ab, wobei möglicherweise Sicherheitsfilterregeln angewendet werden, um nur die Daten zurückzugeben, auf die der Benutzer zugreifen darf.
- Die Orchestrierungslogik ruft die Bodenungsdaten des entsprechenden Mandanten aus dem mehrinstanzenfähigen Datenspeicher ab, wobei möglicherweise Sicherheitsfilterregeln angewendet werden, um nur die Daten zurückzugeben, auf die der Benutzer zugreifen darf.
- Die Orchestrierungslogik ruft Daten aus einem Datenspeicher ab, der über Mandanten hinweg freigegeben wird.
- Die Orchestrierungslogik stellt eine Verbindung mit der Inferencing-API des Basismodells her und sendet die Eingabeaufforderung, die die abgerufenen Erdungsdaten enthält. Die Ergebnisse werden an die intelligente Anwendung zurückgegeben.
Entwurfsüberlegungen für Mehrinstanzendaten in RAG
Auswählen von Speicherisolationsmodellen
Es gibt zwei hauptarchitektonische Ansätze für die Speicherung und Daten in Multitenant-Szenarien: Speicher-pro-Mandant- und Mehrinstanzenspeicher. Diese Ansätze sind zusätzlich zu Speichern, die Daten enthalten, die über Mandanten hinweg freigegeben werden. Dieser Abschnitt berührt jeden Ansatz. Beachten Sie, dass Ihre Multitenantlösung eine Kombination dieser Ansätze verwenden kann.
Store pro Mandant
Wie der Name schon sagt, verfügt jeder Mandant über einen eigenen Speicher. Die Vorteile dieses Ansatzes umfassen sowohl Daten- als auch Leistungsisolation. Die Daten jedes Mandanten werden in einem eigenen Speicher gekapselt. In den meisten Datendiensten sind die isolierten Speicher nicht anfällig für das laute Nachbarproblem anderer Mandanten. Dieser Ansatz vereinfacht auch die Kostenzuordnung, da die gesamten Kosten einer Store-Bereitstellung einem einzelnen Mandanten zugeordnet werden können.
Die Herausforderungen dieses Ansatzes umfassen möglicherweise höhere Verwaltungs- und Betriebskosten und höhere Kosten. Dieser Ansatz sollte nicht berücksichtigt werden, wenn es eine große Anzahl kleiner Mandanten gibt, z. B. Geschäfts-zu-Verbraucher-Szenarien. Dieser Ansatz könnte auch gegen die Dienstbeschränkungen ausgeführt werden.
Im Kontext dieses KI-Szenarios würde ein Speicher pro Mandant bedeuten, dass die für die Berücksichtigung der Relevanz erforderlichen Daten aus einem vorhandenen oder neuen Datenspeicher stammen, der nur Erdungsdaten für den Mandanten enthält. In dieser Topologie ist die Datenbankinstanz der Diskriminator, der pro Mandant verwendet wird.
Mehrinstanzenspeicher
In Mehrinstanzenspeichern sind mehrere Mandantendaten im selben Speicher koexistieren. Die Vorteile dieses Ansatzes umfassen das Potenzial für die Kostenoptimierung, die Möglichkeit, eine höhere Anzahl von Mandanten zu behandeln als das Modell für den Store pro Mandant und einen geringeren Verwaltungsaufwand aufgrund der geringeren Anzahl von Speicherinstanzen.
Zu den Herausforderungen bei der Verwendung freigegebener Speicher gehören die Notwendigkeit, die Datenisolation, die Datenverwaltung, das Potenzial für laute Nachbarn antipattern und Schwierigkeiten bei der Zuweisung von Kosten für Mandanten sicherzustellen. Die Sicherstellung der Datenisolation ist das wichtigste Anliegen bei diesem Ansatz. Sie haben die Verantwortung, den Sicherheitsansatz zu implementieren, um sicherzustellen, dass Mandanten nur auf ihre Daten zugreifen können. Die Datenverwaltung kann auch eine Herausforderung darstellen, wenn Mandanten unterschiedliche Datenzyklen aufweisen, die Vorgänge erfordern können, z. B. das Erstellen von Indizes in verschiedenen Zeitplänen.
Einige Plattformen verfügen über Features, die Sie nutzen können, wenn Sie die Mandantendatenisolation in freigegebenen Speicher implementieren. Azure Cosmos DB verfügt beispielsweise über systemeigene Unterstützung für Partitionierung und Sharding, und es ist üblich, einen Mandantenbezeichner als Partitionsschlüssel zu verwenden, um eine gewisse Isolationsebene zwischen Mandanten bereitzustellen. Azure SQL und Postgres Flex unterstützen die Sicherheit auf Zeilenebene, obwohl dieses Feature nicht häufig in Multitenant-Lösungen verwendet wird, da Sie Ihre Lösung für diese Features entwerfen müssen, wenn Sie diese in Ihrem mehrinstanzenbasierten Speicher verwenden möchten.
Im Kontext dieses KI-Szenarios würde dies bedeuten, dass das Bodenieren von Daten für alle Mandanten im selben Datenspeicher erfolgt, sodass Ihre Abfrage an diesen Datenspeicher einen Mandantendiskriminator enthalten muss, um sicherzustellen, dass Antworten nur relevante Daten im Kontext des Mandanten zurückzugeben sind.
Freigegebene Speicher
Multitenant-Lösungen verfügen häufig über Daten, die über Mandanten hinweg freigegeben werden. In einer Beispiellösung mit mehreren Mandanten für die Gesundheitsdomäne kann es eine Datenbank geben, in der allgemeine medizinische Informationen oder Informationen gespeichert werden, die nicht mandantenspezifisch sind.
Im Kontext dieses KI-Szenarios wäre dies ein allgemein zugänglicher Bodendatenspeicher, der keine speziellen Filter basierend auf einem Mandanten benötigt, da die Daten relevant und für alle Mandanten im System autorisiert sind.
Identität
Die Identität ist ein wichtiger Aspekt für Multitenant-Lösungen , einschließlich sicherer multitenanter RAG. Die intelligente Anwendung sollte in einen Identitätsanbieter (IdP) integriert werden, um die Identität des Benutzers zu authentifizieren. Die mehrinstanzenfähige RAG-Lösung benötigt ein Identitätsverzeichnis , in dem autoritative Identitäten oder Verweise auf Identitäten gespeichert werden. Diese Identität muss über die Anforderungskette fließen, sodass nachgeschaltete Dienste wie der Orchestrator oder sogar der Datenspeicher selbst den Benutzer identifizieren können.
Sie benötigen auch eine Möglichkeit zum Zuordnen eines Benutzers zu einem Mandanten , damit Sie Zugriff auf diese Mandantendaten gewähren können.
Definieren der Mandanten- und Autorisierungsanforderungen
Beim Erstellen einer mehrinstanzenfähigen RAG-Lösung müssen Sie definieren, was ein Mandant für Ihre Lösung ist. Die beiden gängigen Modelle sind Business-to-Business (B2B) und Business-to-Consumer (B2C). Diese Bestimmung hilft Ihnen, Sie über Bereiche zu informieren, die Sie berücksichtigen sollten, wenn Sie Ihre Lösung entwerfen. Das Verständnis der Anzahl der Mandanten ist für die Entscheidung des Datenspeichermodells von entscheidender Bedeutung. Eine große Anzahl von Mandanten erfordert möglicherweise ein Modell mit mehreren Mandanten pro Speicher, während eine kleinere Zahl einen Speicher pro Mandantenmodell zulassen kann. Die Menge der Daten pro Mandant ist ebenfalls wichtig. Wenn Mandanten über große Datenmengen verfügen, die sie möglicherweise daran hindern, mehrinstanzenfähige Speicher aufgrund von Größenbeschränkungen für den Datenspeicher zu verwenden.
In vorhandenen Workloads, die erweitert werden, um dieses KI-Szenario zu unterstützen, haben Sie diese Entscheidung möglicherweise bereits getroffen. Im Allgemeinen können Sie Ihre vorhandene Datenspeichertopologie für die Erdungsdaten verwenden, wenn dieser Datenspeicher ausreichend Relevanz bieten kann und alle anderen nicht funktionalen Anforderungen erfüllt. Wenn Sie jedoch neue Komponenten wie einen dedizierten Vektorsuchspeicher als dedizierten Erdungsspeicher einführen, müssen Sie diese Entscheidung treffen, wenn Sie Faktoren wie Ihre aktuelle Bereitstellungsstempelstrategie, die Auswirkungen der Anwendungssteuerungsebene und alle Unterschiede im Lebenszyklus pro Mandant (z. B. Pay-for-Performance-Situationen) berücksichtigen.
Nachdem Sie definiert haben, was ein Mandant für Ihre Lösung ist, müssen Sie dann Ihre Autorisierungsanforderungen für Daten definieren. Mandanten greifen zwar nur von ihrem Mandanten auf Daten zu, Ihre Autorisierungsanforderungen sind jedoch möglicherweise präziser. In einer Gesundheitslösung können Sie z. B. Regeln wie:
- Ein Patient kann nur auf seine eigenen Patientendaten zugreifen
- Ein Gesundheitsfachmann kann auf die Daten ihrer Patienten zugreifen
- Ein Finanzbenutzer kann nur auf finanzbezogene Daten zugreifen.
- Ein klinischer Auditor kann alle Patientendaten sehen
- Alle Benutzer können auf basismedizinische Kenntnisse in einem freigegebenen Datenspeicher zugreifen.
In einer dokumentbasierten RAG-Anwendung sollten Sie den Zugriff von Benutzern auf Dokumente basierend auf einem Taggingschema oder vertraulichkeitsstufen einschränken, das auf Dokumenten festgelegt ist.
Nachdem Sie über eine Definition verfügen, was ein Mandant ist und über ein klares Verständnis der Autorisierungsregeln verfügt, verwenden Sie diese Informationen als Anforderungen für Ihre Datenspeicherlösung.
Filterung
Die Filterung, auch als Sicherheitskürzung bezeichnet, bezieht sich auf das Verfügbarmachen nur der Daten für Benutzer, die sie sehen dürfen. In einem mehrinstanzenfähigen RAG-Szenario kann ein Benutzer einem mandantenspezifischen Speicher zugeordnet werden. Das bedeutet nicht, dass der Benutzer auf alle Daten in diesem Speicher zugreifen kann. In "Definieren Ihrer Mandanten- und Autorisierungsanforderungen" haben wir die Bedeutung der Definition der Autorisierungsanforderungen für Ihre Daten erörtert. Diese Autorisierungsregeln sollten als Grundlage für die Filterung verwendet werden.
Das Filtern kann mithilfe von Datenplattformfunktionen wie Sicherheit auf Zeilenebene erreicht werden, oder es kann benutzerdefinierte Logik, Daten oder Metadaten erfordern. Auch hier werden diese Plattformfeatures aufgrund der Notwendigkeit, Ihr System um diese Features herum zu entwerfen, nicht häufig in Multitenant-Lösungen verwendet.
Kapselung von mehrinstanzenfähiger Datenlogik
Es wird empfohlen, eine API vor dem verwendeten Speichermechanismus zu haben. Die API fungiert als Gatekeeper und erzwingt, dass Benutzer nur Zugriff auf die Informationen erhalten, auf die sie Zugriff erhalten sollten.
Abbildung 4. Mehrinstanzenfähige RAG-Architektur mit einer API zur Kapselung von mehrinstanzenfähigen Mandantendatenzugriffslogik
Wie weiter oben in diesem Artikel erwähnt, kann der Benutzerzugriff auf Daten durch Folgendes eingeschränkt werden:
- Der Mandant des Benutzers
- Plattformfeatures
- Benutzerdefinierte Regeln zum Filtern/Kürzen von Sicherheit.
Diese Ebene sollte die folgenden Verantwortlichkeiten haben:
- Weiterleiten der Abfrage an einen mandantenspezifischen Speicher in einem Mandantenmodell
- Wählen Sie nur Daten aus dem Mandanten des Benutzers in mehrinstanzenfähigen Speicher aus.
- Verwenden der entsprechenden Identität für einen Benutzer, um plattformfähige Autorisierungslogik zu unterstützen
- Erzwingen benutzerdefinierter Sicherheitskürzungslogik
- Speichern von Zugriffsprotokollen mit Erdungsinformationen für Überwachungszwecke
Code, der auf Mandantendaten zugreifen muss, sollte die Back-End-Speicher nicht direkt abfragen können. Alle Anforderungen für Daten sollten über diese API-Ebene fließen. Diese API-Ebene stellt einen einzelnen Governance- oder Sicherheitsebene über Ihren Mandantendaten bereit. Dieser Ansatz verhindert, dass die Autorisierungslogik für Mandanten- und Benutzerdatenzugriff in verschiedene Bereiche der Anwendung einblutet. Diese Logik wird in der API-Ebene gekapselt. Diese Kapselung erleichtert die Überprüfung und Prüfung der Lösung.
Zusammenfassung
Beim Entwerfen einer multitenanten RAG-Inferencing-Lösung müssen Sie berücksichtigen, wie Sie die Erdungsdatenlösung für Ihre Mandanten entwerfen. Verschaffen Sie sich ein Verständnis der Anzahl der Mandanten und der Menge der daten pro Mandant, die Sie speichern. Diese Informationen helfen Ihnen beim Entwerfen Ihrer Daten-Mandantenlösung. Es wird empfohlen, eine API-Ebene zu implementieren, die die Datenzugriffslogik kapselt, einschließlich Multitenant- und Filterlogik.
Beitragende
Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:
- John Downs | Principal Software Engineer
- Daniel Scott-Raynsford | Sr. Partner Solution Architect, Data & AI