Entwerfen einer sicheren Multitenant-RAG-Inferencing-Lösung

Retrieval-Augmented Generation (RAG) ist ein Muster zum Erstellen von Anwendungen, die grundlegende Modelle verwenden, um über proprietäre Informationen oder andere Daten zu grü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 im Rahmen des Kontexts als Referenzdaten an das grundlegende Modell.

Eine Mehrinstanzenlösung wird von mehreren Kunden verwendet. Jeder Kunde oder Mandant besteht aus mehreren Benutzern aus derselben Organisation, einem Unternehmen oder einer Gruppe. In Szenarien mit mehreren Mandanten müssen Sie sicherstellen, dass Mandanten oder Einzelpersonen innerhalb von Mandanten nur Grundlagendaten einbinden können, zu deren Zugriff sie autorisiert sind.

Es gibt Bedenken zur Mehrinstanzenfähigkeit, die darüber hinausgehen, sicherzustellen, dass Benutzende nur auf die Informationen zugreifen, für die sie die entsprechende Berechtigung haben. Dieser Artikel konzentriert sich jedoch auf diesen Aspekt der Mehrinstanzenfähigkeit. Dieser Artikel beginnt mit einer Übersicht über RAG-Architekturen mit einem einzelnen Mandanten. Er erörtert potenzielle Herausforderungen bezüglich der Mehrinstanzenfähigkeit mit RAG sowie einige gängige Ansätze zum Umgang damit. Außerdem werden Überlegungen zur Mehrmandantenfähigkeit und Empfehlungen für eine verbesserte Sicherheit beschrieben.

Anmerkung

In diesem Artikel werden verschiedene Features beschrieben, die für Azure OpenAI-Dienst spezifisch sind, z. B. das Azure OpenAI On Your Data-Feature. Sie können jedoch die meisten in diesem Artikel beschriebenen Prinzipien auf grundlegende KI-Modelle auf jeder Plattform anwenden.

Einzelmandanten-RAG-Architektur mit einem Orchestrator

Im Diagramm verbindet sich ein Benutzer mit einer intelligenten Anwendung. Die intelligente Anwendung verbindet sich mit einem Identitätsanbieter. Die intelligente Anwendung stellt dann eine Verbindung mit einem Orchestrator bereit. Der Orchestrator stellt eine Verbindung mit Datenbanken und Vektorspeichern bereit. Der Orchestrator stellt dann eine Verbindung mit dem grundlegenden Modell her.

Arbeitsablauf

In dieser Single-Tenant-RAG-Architektur ruft ein Orchestrator relevante proprietäre Mandantendaten aus den Datenspeichern ab und stellt sie als Grundlagendaten für das grundlegende Modell bereit. Die folgenden Schritte beschreiben einen allgemeinen Workflow.

1. Ein Benutzer gibt eine Anforderung an die intelligente Webanwendung aus.
2. Ein Identitätsanbieter authentifiziert den Anforderer.
3. Die intelligente Anwendung ruft die Orchestrator-API mit der Abfrage des Benutzers und dem Autorisierungstoken für den Benutzer auf.
4. Die Orchestrierungslogik extrahiert die Abfrage des Benutzers aus der Anforderung und ruft den entsprechenden Datenspeicher auf, um relevante Erdungsdaten für die Abfrage abzurufen. Im nächsten Schritt werden die Grundlagendaten dem Prompt hinzugefügt, der an das Basismodell gesendet wird, z. B. an ein in Azure OpenAI zur Verfügung gestelltes Modell.
5. 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 finden Sie unter Entwerfen und Entwickeln einer RAG-Lösung.

Single-Tenant RAG-Architektur mit direktem Datenzugriff

Diese Variante der Single-Tenant RAG-Architektur verwendet die On Your Data Feature von Azure OpenAI, um direkt in Datenspeicher wie Azure AI Search zu integrieren. In dieser Architektur haben Sie entweder keinen eigenen Orchestrator, oder Ihr Orchestrator hat weniger Verantwortlichkeiten. Die Azure OpenAI-API ruft den Datenspeicher auf, um die Erdungsdaten abzurufen und diese Daten an das Sprachmodell zu übergeben. Diese Methode bietet Ihnen weniger Kontrolle darüber, welche Erdungsdaten abgerufen werden sollen, und die Relevanz dieser Daten.

Anmerkung

Azure OpenAI wird von Microsoft verwaltet. Sie ist in den Datenspeicher integriert, aber das Modell selbst lässt sich nicht in den Datenspeicher integrieren. Das Modell empfängt Erdungsdaten auf die gleiche Weise wie beim Abrufen der Daten durch einen Orchestrator.

Im Diagramm verbindet sich ein Benutzer zu einer intelligenten Anwendung. Die intelligente Anwendung verbindet sich mit einem Identitätsanbieter. Die intelligente Anwendung stellt dann eine Verbindung mit Azure OpenAI bereit. Azure OpenAI stellt eine Verbindung mit unterstützten Datenspeichern wie Azure AI Search und Azure Blob Storage bereit. Die KI-Suche übergibt dann die Daten als Teil des Kontexts an das Sprachmodell.

Arbeitsablauf

In dieser RAG-Architektur ruft der Dienst, der das Grundlagenmodell bereitstellt, die entsprechenden proprietären Mandantendaten aus den Datenspeichern ab und verwendet diese Daten als Basisdaten für das Grundlagenmodell. Die folgenden Schritte beschreiben einen allgemeinen Workflow. Die Schritte in Kursivdruck sind identisch mit denen der vorherigen Einzelmandanten-RAG-Architektur mit einem Orchestratorworkflow.

1. Ein Benutzer stellt eine Anforderung an die intelligente Webanwendung aus.
2. Ein Identitätsanbieter authentifiziert den Anforderer.
3. Die intelligente Anwendung ruft Azure OpenAI mit der Abfrage des Benutzers auf.
4. Azure OpenAI stellt eine Verbindung mit unterstützten Datenspeichern wie AI Search und Azure Blob Storage her, um die Erdungsdaten abzurufen. Die Erdungsdaten werden als Teil des Kontexts verwendet, wenn Azure OpenAI das OpenAI-Sprachmodell aufruft. Die Ergebnisse werden an die intelligente Anwendung zurückgegeben.

Wenn Sie diese Architektur in einer Mehrinstanzenlösung verwenden möchten, muss der Dienst, der direkt auf die Erdungsdaten wie Azure OpenAI zugreift, die mehrinstanzenfähige Logik unterstützen, die Ihre Lösung erfordert.

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. Die Daten befinden sich außerdem möglicherweise in einem Speicher, der mandantenübergreifend freigegeben wird. Es sollten nur Daten als Grundlage verwendet werden, auf die der Benutzer zugreifen darf. Der Benutzer sollte nur gemeinsame oder sämtliche Mandantendaten oder Daten von ihrem Mandanten sehen, die gefiltert werden, um sicherzustellen, dass ihnen nur die Daten angezeigt werden, auf die sie zugriffberechtigt sind.

Im Diagramm verbindet sich ein Benutzer mit einer intelligenten Anwendung. Die intelligente Anwendung verbindet sich mit einem Identitätsanbieter. Die intelligente Anwendung stellt dann eine Verbindung mit einem Orchestrator bereit. Der Orchestrator stellt eine Verbindung mit einer Datenbank mit einem einzelnen Mandanten, einer mehrinstanzenfähigen Datenbank oder einer gemeinsam genutzten Datenbank her. Der Orchestrator stellt dann eine Verbindung mit dem grundlegenden Modell her.

Arbeitsablauf

Die folgenden Schritte beschreiben einen allgemeinen Workflow. Die Schritte in Kursivdruck sind identisch mit denen des Workflows der Einzelmandanten-RAG-Architektur mit einem Orchestrator.

1. Ein Benutzer stellt eine Anforderung an die intelligente Webanwendung aus.
2. Ein Identitätsanbieter authentifiziert den Anforderer.
3. Die intelligente Anwendung ruft die Orchestrator-API mit der Abfrage des Benutzers und dem Autorisierungstoken für den Benutzer auf.
4. 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 Erdungsdaten werden der Eingabeaufforderung hinzugefügt, die im nächsten Schritt an Azure OpenAI gesendet wird. Einige oder alle der folgenden Schritte sind enthalten:
   1. Die Orchestrierungslogik ruft die Basisdaten aus der entsprechenden mandantenspezifischen Datenbankinstanz ab und wendet möglicherweise Sicherheitsfilter an, um nur die Daten bereitzustellen, auf die der Benutzer zugreifen darf.
   2. Die Orchestrierungslogik ruft die Erdungsdaten des entsprechenden Mandanten aus dem mehrinstanzenfähigen Datenspeicher ab und wendet potenziell Sicherheitsfilterregeln an, um nur die Daten zurückzugeben, auf die der Benutzer zugreifen darf.
   3. Die Orchestrierungslogik ruft Daten aus einem Datenspeicher ab, der für mehrere Mandanten gemeinsam genutzt wird.
5. 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

Berücksichtigen Sie die folgenden Optionen, wenn Sie Ihre multitenant-RAG-Inferencing-Lösung entwerfen.

Auswählen eines Speicherisolationsmodells

Die beiden wichtigsten Architekturansätze für Speicher und Daten in Szenarien mit mehreren Mandanten sind mandantenspezifische Speicher und mehrinstanzenfähige Speicher. Diese Ansätze ergänzen Speicher, die mandantenübergreifend freigegebene Daten enthalten. Ihre Multitenantlösung kann eine Kombination dieser Ansätze verwenden.

Mandantenspezifische Speicher

In mandantenspezifischen Speichern 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 Noisy Neighbor-Problem anderer Mandanten. Dieser Ansatz vereinfacht auch die Kostenzuordnung, da die gesamten Kosten einer Speicherbereitstellung einem einzelnen Mandanten zugeordnet werden können.

Dieser Ansatz kann Herausforderungen wie erhöhtes Management und Betriebsaufwand und höhere Kosten darstellen. Sie sollten diesen Ansatz nicht verwenden, wenn Sie über eine große Anzahl kleiner Mandanten verfügen, z. B. in Geschäfts-zu-Verbraucher-Szenarien. Dieser Ansatz kann auch Dienstgrenzwerte erreichen oder überschreiten.

Im Kontext dieses KI-Szenarios bedeutet ein mandantenspezifischer Speicher, dass die erforderlichen Basisdaten, um Relevanz in den Kontext zu bringen, von einem bestehenden oder neuen Datenspeicher stammen, der nur Basisdaten für den Mandanten enthält. In dieser Topologie ist die Datenbankinstanz der Diskriminator, der für jeden Mandanten verwendet wird.

Mehrinstanzenfähige Speicher

In mehrinstanzenfähigen Speichern sind die Daten mehrerer Mandanten im selben Speicher vorhanden. Die Vorteile dieses Ansatzes umfassen das Potenzial für die Kostenoptimierung, die Möglichkeit, eine höhere Anzahl von Mandanten zu behandeln als das Store-pro-Mandant-Modell und einen geringeren Verwaltungsaufwand aufgrund der geringeren Anzahl von Store-Instanzen.

Zu den Herausforderungen bei der Verwendung gemeinsam genutzter Speicher gehören die Notwendigkeit der Datenisolation und -verwaltung, das potenzielle Noisy Neighbor-Antimuster und die komplexere Kostenzuordnung für Mandanten. Die Datenisolation ist das wichtigste Anliegen, wenn Sie diesen Ansatz verwenden. Sie müssen sichere Ansätze implementieren, um sicherzustellen, dass Mandanten nur auf ihre Daten zugreifen können. Die Datenverwaltung kann auch schwierig sein, wenn Mandanten unterschiedliche Datenlebenszyklen aufweisen, die Vorgänge erfordern, z. B. das Erstellen von Indizes in verschiedenen Zeitplänen.

Einige Plattformen bieten Funktionen, die Sie nutzen können, wenn Sie die Isolation von Mandantendaten in gemeinsamen Speichern implementieren. Azure Cosmos DB verfügt beispielsweise über systemeigene Unterstützung für die Datenpartitionierung und -sharding. Es ist typisch, einen Mandantenbezeichner als Partitionsschlüssel zu verwenden, um eine gewisse Isolation zwischen Mandanten bereitzustellen. Azure SQL und Azure-Datenbank für PostgreSQL – Flexible Server unterstützen Sicherheit auf Zeilenebene. Diese Features werden jedoch in der Regel nicht in mehrinstanzenfähigen Lösungen verwendet, weil die Lösung entsprechend entwickelt werden muss, um sie in einem mehrinstanzenfähigen Speicher zu nutzen.

Im Kontext dieses KI-Szenarios werden die Grundlagendaten für alle Mandanten im selben Datenspeicher zusammengeführt. Daher muss Ihre Abfrage an diesen Datenspeicher einen Mandantendiskriminator enthalten, um sicherzustellen, dass Antworten darauf beschränkt sind, nur relevante Daten im Kontext des Mandanten zurückzugeben.

Gemeinsam genutzte Geschäfte

Mehrinstanzenfähige Lösungen geben Daten häufig mandantenübergreifend frei. In einer Beispiellösung mit mehreren Mandanten kann eine Datenbank allgemeine medizinische Informationen oder Informationen speichern, die für den Mandanten nicht spezifisch sind.

Im Kontext dieses KI-Szenarios ist der zentrale Datenspeicher allgemein zugänglich und braucht keine Filterung basierend auf bestimmten Mandanten, da die Daten für alle Mandanten im System relevant und autorisiert sind.

Identität

Identity ist ein wichtiger Aspekt von Multitenant-Lösungen, einschließlich multitenanter RAG-Lösungen. Die intelligente Anwendung sollte in einen Identitätsanbieter integriert werden, um die Identität des Benutzers zu authentifizieren. Die multiinstanzenfähige RAG-Lösung benötigt ein Identitätsverzeichnis, das autoritative Identitäten oder Verweise auf Identitäten speichert. Diese Identität muss durch die Anforderungskette fließen und es nachgeschalteten Diensten, wie dem Orchestrator oder dem Datenspeicher selbst, ermöglichen, den Benutzer zu identifizieren.

Außerdem benötigen Sie eine Möglichkeit, einen Benutzer einem Mandanten zuzuordnen, damit Sie Zugriff auf diese Mandantendaten gewähren können.

Definieren Sie Ihre Mandanten- und Autorisierungsanforderungen

Wenn Sie eine RAG-Lösung mit mehreren Mandanten erstellen, müssen Sie definieren, was ein Mandant für Ihre Lösungist. Die beiden gängigen Modelle, aus denen Sie wählen können, sind Business-to-Business- und Business-to-Consumer-Modelle.The two common models to choose from are business-to-business and business-to-consumer models. Das von Ihnen ausgewählte Modell hilft Ihnen dabei, zu bestimmen, welche anderen Faktoren Sie beim Erstellen Ihrer Lösung berücksichtigen sollten. Die Mandantenanzahl zu kennen, ist bei der Wahl des Datenspeichermodells von entscheidender Bedeutung. Viele Mieter könnten ein Modell benötigen, das mehrere Mieter pro Geschäft hat. Eine kleinere Anzahl von Mietern könnte ein Modell mit einem Geschäft pro Mieter ermöglichen. Die Datenmenge für jeden Mandanten ist ebenfalls wichtig. Mandanten mit großen Datenmengen können die Verwendung von mehrinstanzenfähigen Speichern aufgrund von Größenbeschränkungen des Datenspeichers verhindern.

Wenn Sie beabsichtigen, eine vorhandene Workload zu erweitern, 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 nichtfunktionellen Anforderungen erfüllt. Wenn Sie jedoch beabsichtigen, neue Komponenten einzuführen, z. B. einen dedizierten Vektorsuchspeicher als dedizierter Erdungsspeicher, müssen Sie diese Entscheidung dennoch treffen. Berücksichtigen Sie Faktoren wie Ihre aktuelle Bereitstellungsstempelstrategie, Auswirkungen auf Ihre Anwendungssteuerungsebene und etwaige Unterschiede im mandantenspezifischen Datenlebenszyklus, z. B. im Hinblick auf leistungsabhängige Zahlung.

Nachdem Sie definiert haben, was ein Mandant für Ihre Lösung ist, müssen Sie Ihre Autorisierungsanforderungen für Daten definieren. Mandanten haben nur intern Zugriff auf Daten, Ihre Autorisierungsanforderungen sind jedoch möglicherweise differenzierter. In einer Gesundheitslösung können Sie z. B. Regeln haben 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 die Daten aller Patienten sehen.
• Alle Benutzer können auf grundlegende medizinische Kenntnisse in einem freigegebenen Datenspeicher zugreifen.

In einer dokumentbasierten RAG-Anwendung sollten Sie den Zugriff der Benutzer auf Dokumente basierend auf einem Taggingschema oder vertraulichkeitsstufen einschränken, die den Dokumenten zugewiesen sind.

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.

Datenfilterung

Die Zugriffsbeschränkung ausschließlich für Daten, zu deren Zugriff Benutzende autorisiert sind, wird als Filterung oder Sicherheitskürzung bezeichnet. 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. Unter Definieren der Mandanten- und Autorisierungsanforderungen wird die Wichtigkeit der Definition von Autorisierungsanforderungen für Ihre Daten behandelt. Sie sollten diese Autorisierungsregeln als Grundlage für die Filterung verwenden.

Sie können Funktionen der Datenplattform wie Sicherheit auf Zeilenebene verwenden, um Filter zu implementieren. Oder Sie benötigen möglicherweise benutzerdefinierte Logik, Daten oder Metadaten. Diese Plattformfeatures werden in der Regel nicht in Multitenantlösungen verwendet, da Sie Ihr System für diese Features entwerfen müssen.

Kapseln von mehrinstanzenfähiger Datenlogik

Es wird empfohlen, dass Sie über eine API vor dem verwendeten Speichermechanismus verfügen. Die API fungiert wie ein Gatekeeper, der sicherstellt, dass Benutzer nur Zugriff auf Informationen erhalten, die sie für den Zugriff autorisiert haben.

Im Diagramm stellt ein Benutzer eine Verbindung zu einer intelligenten Anwendung her. Die intelligente Anwendung verbindet sich mit einem Identitätsanbieter. Die intelligente Anwendung stellt dann eine Verbindung mit einem Orchestrator bereit. Der Orchestrator stellt eine Verbindung mit einer API-Ebene bereit. Die API-Ebene stellt eine Verbindung mit Datenbanken und Vektorspeichern bereit. Der Orchestrator stellt dann eine Verbindung mit dem grundlegenden Modell her.

Der Zugriff der Benutzer auf Daten kann durch Folgendes eingeschränkt werden:

• Der Mandant der benutzenden Person
• Plattformfunktionen.
• Benutzerdefinierte Regeln für Sicherheitsfilterung oder -kürzung

Die API-Ebene sollte:

• Weiterleiten der Abfrage an einen mandantenspezifischen Speicher in einem mandantenspezifischen Modell
• Ausschließliches Auswählen von Daten aus dem Benutzermandanten in mehrinstanzenfähigen Speichern
• Verwenden Sie die entsprechende Identität für einen Benutzer, um plattformfähige Autorisierungslogik zu unterstützen.
• Erzwingen von benutzerdefinierter Sicherheitskürzungslogik
• Speichern von Zugriffsprotokollen mit Grundlageninformationen für Überwachungszwecke

Code, der auf Mandantendaten zugreifen muss, sollte nicht in der Lage sein, die Back-End-Speicher direkt abzufragen. Alle Anforderungen für Daten sollten über die API-Ebene fließen. Diese API-Ebene stellt einen zentralen Punkt für die Governance bzw. Sicherheit Ihrer Mandantendaten bereit. Dieser Ansatz verhindert, dass die Autorisierungslogik für Mandanten- und Benutzerdatenzugriff andere Bereiche der Anwendung erreicht. Diese Logik wird in der API-Ebene gekapselt. Diese Kapselung erleichtert die Überprüfung und Prüfung der Lösung.

Zusammenfassung

Wenn Sie eine mehrinstanzenfähige RAG-Rückschlusslösung entwickeln, müssen Sie in Betracht ziehen, wie Sie die Grundlagendatenlösung für Ihre Mandanten entwerfen. Verstehen Sie die Anzahl der Mandanten und die Menge der Daten pro Mandant, die Sie speichern. Diese Informationen helfen Ihnen beim Entwickeln Ihrer Lösung für Datenmandanten. Es wird empfohlen, eine API-Ebene zu implementieren, die die Datenzugriffslogik kapselt, einschließlich multitenanter Logik und Filterlogik.

Beitragende

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

Hauptautoren:

• John Downs | Leitender Softwareentwickler
• Daniel Scott-Raynsford | Sr. Partner Solution Architect, Data & AI

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

Nächster Schritt

Entwerfen und Entwickeln einer RAG-Lösung

Verwandte Ressourcen

• SaaS- und Multitenant-Lösungsarchitektur
• Grundlegende OpenAI End-to-End-Chat-Referenzarchitektur
• End-to-End-Baseline-Chatreferenzarchitektur für OpenAI
• Zugreifen auf Azure OpenAI und andere Sprachmodelle über ein Gateway