Entwurf von Multi-Tenancy-RAG mit Milvus: Best Practices für skalierbare Enterprise-Wissensdatenbanken
Einführung
In den letzten Jahren hat sich Retrieval-Augmented Generation (RAG) als vertrauenswürdige Lösung für große Organisationen etabliert, um ihre LLM-gestützten Anwendungen zu verbessern, insbesondere solche mit vielfältigen Nutzern. Wenn solche Anwendungen wachsen, wird die Implementierung eines Multi-Tenancy-Frameworks unerlässlich. Multi-Tenancy bietet sicheren, isolierten Zugriff auf Daten für verschiedene Nutzergruppen, stärkt das Vertrauen der Nutzer, erfüllt regulatorische Standards und verbessert die betriebliche Effizienz.
Milvus ist eine Open-Source-Vektordatenbank, die für die Verarbeitung hochdimensionaler Vektordaten entwickelt wurde. Sie ist ein unverzichtbarer Infrastrukturbaustein von RAG und speichert sowie ruft kontextbezogene Informationen für LLMs aus externen Quellen ab. Milvus bietet flexible Multi-Tenancy-Strategien für verschiedene Anforderungen, einschließlich Multi-Tenancy auf Datenbankebene, Collection-Ebene und Partitionsebene.
In diesem Beitrag behandeln wir:
Was Multi-Tenancy ist und warum sie wichtig ist
Multi-Tenancy-Strategien in Milvus
Beispiel: Multi-Tenancy-Strategie für eine RAG-gestützte Unternehmenswissensdatenbank
Was Multi-Tenancy ist und warum sie wichtig ist
Multi-Tenancy ist eine Architektur, bei der mehrere Kunden oder Teams, sogenannte "Tenants," eine einzelne Instanz einer Anwendung oder eines Systems gemeinsam nutzen. Die Daten und Konfigurationen jedes Tenants sind logisch isoliert, wodurch Datenschutz und Sicherheit gewährleistet werden, während alle Tenants dieselbe zugrunde liegende Infrastruktur gemeinsam nutzen.
Stellen Sie sich eine SaaS-Plattform vor, die wissensbasierte Lösungen für mehrere Unternehmen bereitstellt. Jedes Unternehmen ist ein Tenant.
Tenant A ist eine Gesundheitsorganisation, die patientenorientierte FAQs und Compliance-Dokumente speichert.
Tenant B ist ein Technologieunternehmen, das interne IT-Fehlerbehebungs-Workflows verwaltet.
Tenant C ist ein Einzelhandelsunternehmen mit Kundenservice-FAQs für Produktrückgaben.
Jeder Tenant arbeitet in einer vollständig isolierten Umgebung, wodurch sichergestellt wird, dass keine Daten von Tenant A in das System von Tenant B gelangen oder umgekehrt. Darüber hinaus sind Ressourcenzuweisung, Abfrageleistung und Skalierungsentscheidungen tenant-spezifisch, wodurch unabhängig von Lastspitzen bei einem Tenant eine hohe Leistung gewährleistet wird.
Multi-Tenancy funktioniert auch für Systeme, die verschiedene Teams innerhalb derselben Organisation bedienen. Stellen Sie sich ein großes Unternehmen vor, das eine RAG-gestützte Wissensdatenbank nutzt, um seine internen Abteilungen wie HR, Legal und Marketing zu unterstützen. Jede Abteilung ist ein Tenant mit isolierten Daten und Ressourcen in dieser Konfiguration.
Multi-Tenancy bietet erhebliche Vorteile, darunter Kosteneffizienz, Skalierbarkeit und robuste Datensicherheit. Durch die gemeinsame Nutzung einer einzigen Infrastruktur können Dienstanbieter Gemeinkosten senken und eine effektivere Ressourcennutzung sicherstellen. Dieser Ansatz skaliert zudem mühelos – das Onboarding neuer Tenants erfordert deutlich weniger Ressourcen als das Erstellen separater Instanzen für jeden einzelnen, wie es bei Single-Tenancy-Modellen der Fall ist. Wichtig ist, dass Multi-Tenancy eine robuste Datensicherheit aufrechterhält, indem sie eine strikte Datenisolierung für jeden Tenant sicherstellt, wobei Zugriffskontrollen und Verschlüsselung sensible Informationen vor unbefugtem Zugriff schützen. Darüber hinaus können Updates, Patches und neue Funktionen gleichzeitig für alle Tenants bereitgestellt werden, was die Systemwartung vereinfacht und den Aufwand für Administratoren reduziert, während gleichzeitig sichergestellt wird, dass Sicherheits- und Compliance-Standards konsequent eingehalten werden.
Multi-Tenancy-Strategien in Milvus
Um zu verstehen, wie Milvus Multi-Tenancy unterstützt, ist es wichtig, zunächst zu betrachten, wie es Nutzerdaten organisiert.
Wie Milvus Nutzerdaten organisiert
Milvus strukturiert Daten über drei Ebenen hinweg, von allgemein bis granular: Datenbank, Collection und Partition/Partition Key.
Abbildung- Wie Milvus Benutzerdaten organisiert .png
Abbildung: Wie Milvus Benutzerdaten organisiert
Datenbank: Diese fungiert als logischer Container, ähnlich einer Datenbank in traditionellen relationalen Systemen.
Collection: Vergleichbar mit einer Tabelle innerhalb einer Datenbank organisiert eine Collection Daten in verwaltbare Gruppen.
Partition/Partition Key: Innerhalb einer Collection können Daten durch Partitionen weiter segmentiert werden. Mithilfe eines Partition Key werden Daten mit demselben Schlüssel zusammen gruppiert. Wenn Sie beispielsweise eine Benutzer-ID als Partition Key verwenden, werden alle Daten für einen bestimmten Benutzer im selben logischen Segment gespeichert. Dadurch ist es unkompliziert, Daten abzurufen, die einzelnen Benutzern zugeordnet sind.
Wenn Sie sich von Datenbank zu Collection zu Partition Key bewegen, wird die Granularität der Datenorganisation zunehmend feiner.
Um eine stärkere Datensicherheit und eine ordnungsgemäße Zugriffskontrolle zu gewährleisten, bietet Milvus außerdem robuste Role-Based Access Control (RBAC), mit der Administratoren spezifische Berechtigungen für jeden Benutzer definieren können. Nur autorisierte Benutzer können auf bestimmte Daten zugreifen.
Milvus unterstützt mehrere Strategien zur Implementierung von Multi-Tenancy und bietet Flexibilität basierend auf den Anforderungen Ihrer Anwendung: Multi-Tenancy auf Datenbankebene, Collection-Ebene und Partitionsebene.
Multi-Tenancy auf Datenbankebene
Beim Ansatz der Multi-Tenancy auf Datenbankebene wird jedem Tenant eine eigene Datenbank innerhalb desselben Milvus-Clusters zugewiesen. Diese Strategie bietet eine starke Datenisolierung und gewährleistet optimale Suchleistung. Sie kann jedoch zu ineffizienter Ressourcennutzung führen, wenn bestimmte Tenants inaktiv bleiben.
Multi-Tenancy auf Collection-Ebene
Hier, bei der Multi-Tenancy auf Collection-Ebene, können wir Daten für Tenants auf zwei Arten organisieren.
Eine Collection für alle Tenants: Alle Tenants teilen sich eine einzelne Collection, wobei tenant-spezifische Felder zum Filtern verwendet werden. Obwohl dieser Ansatz einfach zu implementieren ist, kann er mit zunehmender Anzahl von Tenants auf Leistungsengpässe stoßen.
Eine Collection pro Tenant: Jeder Tenant kann eine dedizierte Collection haben, was Isolierung und Leistung verbessert, aber mehr Ressourcen erfordert. Diese Einrichtung kann auf Skalierbarkeitsbeschränkungen stoßen, wenn die Anzahl der Tenants die Collection-Kapazität von Milvus überschreitet.
Multi-Tenancy auf Partitionsebene
Multi-Tenancy auf Partitionsebene konzentriert sich darauf, Tenants innerhalb einer einzelnen Collection zu organisieren. Hier haben wir ebenfalls zwei Möglichkeiten, Tenant-Daten zu organisieren.
Eine Partition pro Tenant: Tenants teilen sich eine Collection, aber ihre Daten werden in separaten Partitionen gespeichert. Wir können Daten isolieren, indem wir jedem Tenant eine dedizierte Partition zuweisen und so Isolierung und Suchleistung ausbalancieren. Dieser Ansatz ist jedoch durch das maximale Partitionslimit von Milvus eingeschränkt.
Partition-Key-basierte Multi-Tenancy: Dies ist eine skalierbarere Option, bei der eine einzelne Collection Partition Keys verwendet, um Tenants zu unterscheiden. Diese Methode vereinfacht das Ressourcenmanagement und unterstützt eine höhere Skalierbarkeit, unterstützt jedoch keine Massendaten-Einfügungen.
Die folgende Tabelle fasst die wichtigsten Unterschiede zwischen den zentralen Multi-Tenancy-Ansätzen zusammen.
| Granularität | Datenbankebene | Sammlungsebene | Partitionsschlüssel-Ebene |
|---|---|---|---|
| Max. unterstützte Mandanten | ~1,000 | ~10,000 | ~10,000,000 |
| Flexibilität der Datenorganisation | Hoch: Benutzer können mehrere Sammlungen mit benutzerdefinierten Schemata definieren. | Mittel: Benutzer sind auf eine Sammlung mit einem benutzerdefinierten Schema beschränkt. | Niedrig: Alle Benutzer teilen sich eine Sammlung, was ein einheitliches Schema erfordert. |
| Kosten pro Benutzer | Hoch | Mittel | Niedrig |
| Physische Ressourcenisolation | Ja | Ja | Nein |
| RBAC | Ja | Ja | Nein |
| Suchleistung | Stark | Mittel | Stark |
Beispiel: Multi-Tenancy-Strategie für eine RAG-gestützte Unternehmenswissensdatenbank
Beim Entwurf der Multi-Tenancy-Strategie für ein RAG-System ist es wichtig, Ihren Ansatz an den spezifischen Anforderungen Ihres Unternehmens und Ihrer Mandanten auszurichten. Milvus bietet verschiedene Multi-Tenancy-Strategien, und die Wahl der richtigen hängt von der Anzahl der Mandanten, ihren Anforderungen und dem benötigten Grad der Datenisolation ab. Hier ist ein praktischer Leitfaden für diese Entscheidungen, am Beispiel einer RAG-gestützten Unternehmenswissensdatenbank.
Verständnis der Mandantenstruktur vor der Wahl einer Multi-Tenancy-Strategie
Eine RAG-gestützte Unternehmenswissensdatenbank bedient häufig eine kleine Anzahl von Mandanten. Diese Mandanten sind in der Regel unabhängige Geschäftseinheiten wie IT, Vertrieb, Rechtsabteilung und Marketing, die jeweils eigenständige Wissensdatenbankdienste benötigen. Beispielsweise verwaltet die Personalabteilung sensible Mitarbeiterinformationen wie Onboarding-Leitfäden und Richtlinien zu Zusatzleistungen, die vertraulich sein und nur HR-Mitarbeitern zugänglich sein sollten.
In diesem Fall sollte jede Geschäftseinheit als separater Mandant behandelt werden, und eine Multi-Tenancy-Strategie auf Datenbankebene ist oft am besten geeignet. Durch die Zuweisung dedizierter Datenbanken an jeden Mandanten können Organisationen eine starke logische Isolation erreichen, was die Verwaltung vereinfacht und die Sicherheit erhöht. Diese Einrichtung bietet Mandanten erhebliche Flexibilität – sie können benutzerdefinierte Datenmodelle innerhalb von Sammlungen definieren, so viele Sammlungen wie nötig erstellen und die Zugriffskontrolle für ihre Sammlungen unabhängig verwalten.
Erhöhung der Sicherheit durch physische Ressourcenisolation
In Situationen, in denen Datensicherheit eine hohe Priorität hat, reicht eine logische Isolation auf Datenbankebene möglicherweise nicht aus. Beispielsweise könnten einige Geschäftseinheiten kritische oder hochsensible Daten verarbeiten, die stärkere Garantien gegen Beeinträchtigungen durch andere Mandanten erfordern. In solchen Fällen können wir zusätzlich zu einer Multi-Tenancy-Struktur auf Datenbankebene einen Ansatz zur physischen Isolation implementieren.
Milvus ermöglicht es uns, logische Komponenten wie Datenbanken und Collections physischen Ressourcen zuzuordnen. Diese Methode stellt sicher, dass die Aktivitäten anderer Mandanten kritische Operationen nicht beeinträchtigen. Sehen wir uns an, wie dieser Ansatz in der Praxis funktioniert.
Figure- How Milvus manages physical resources.png
Abbildung: Wie Milvus physische Ressourcen verwaltet
Wie im obigen Diagramm dargestellt, gibt es in Milvus drei Ebenen des Ressourcenmanagements: Query Node, Resource Group und Database.
Query Node: Die Komponente, die Abfrageaufgaben verarbeitet. Sie läuft auf einer physischen Maschine oder in einem Container (z. B. einem Pod in Kubernetes).
Resource Group: Eine Sammlung von Query Nodes, die als Brücke zwischen logischen Komponenten (Datenbanken und Collections) und physischen Ressourcen fungiert. Sie können einer einzelnen Resource Group eine oder mehrere Datenbanken oder Collections zuweisen.
Im oben dargestellten Beispiel gibt es drei logische Databases: X, Y und Z.
Database X: Enthält Collection A.
Database Y: Enthält Collections B und C.
Database Z: Enthält Collections D und E.
Angenommen, Database X enthält eine kritische Wissensdatenbank, die nicht durch die Last von Database Y oder Database Z beeinträchtigt werden soll. Um Datenisolierung sicherzustellen:
Database X wird einer eigenen Resource Group zugewiesen, um zu garantieren, dass ihre kritische Wissensdatenbank nicht durch Workloads anderer Datenbanken beeinträchtigt wird.
Collection E wird ebenfalls einer separaten Resource Group innerhalb ihrer übergeordneten Datenbank (Z) zugewiesen. Dies bietet Isolierung auf Collection-Ebene für bestimmte kritische Daten innerhalb einer gemeinsam genutzten Datenbank.
Währenddessen teilen sich die übrigen Collections in Databases Y und Z die physischen Ressourcen von Resource Group 2.
Durch die sorgfältige Zuordnung logischer Komponenten zu physischen Ressourcen können Unternehmen eine flexible, skalierbare und sichere Multi-Tenancy-Architektur erreichen, die auf ihre spezifischen Geschäftsanforderungen zugeschnitten ist.
Entwerfen von Zugriff auf Endbenutzerebene
Nachdem wir die Best Practices für die Auswahl einer Multi-Tenancy-Strategie für ein Enterprise-RAG kennengelernt haben, wollen wir untersuchen, wie der Zugriff auf Benutzerebene in solchen Systemen gestaltet wird.
In diesen Systemen interagieren Endbenutzer in der Regel über LLMs im schreibgeschützten Modus mit der Wissensdatenbank. Unternehmen müssen jedoch weiterhin solche von Benutzern generierten Q&A-Daten nachverfolgen und sie bestimmten Benutzern zuordnen, etwa um die Genauigkeit der Wissensdatenbank zu verbessern oder personalisierte Dienste anzubieten.
Nehmen wir den intelligenten Beratungsservice-Schalter eines Krankenhauses als Beispiel. Patienten könnten Fragen stellen wie: „Gibt es heute noch verfügbare Termine bei dem Facharzt?“ oder „Ist eine bestimmte Vorbereitung für meine bevorstehende Operation erforderlich?“ Obwohl diese Fragen die Wissensdatenbank nicht direkt beeinflussen, ist es für das Krankenhaus wichtig, solche Interaktionen nachzuverfolgen, um die Dienste zu verbessern. Diese Q&A-Paare werden normalerweise in einer separaten Datenbank gespeichert (es muss nicht unbedingt eine Vektordatenbank sein), die dem Protokollieren von Interaktionen gewidmet ist.
Figure- The multi-tenancy architecture for an enterprise RAG knowledge base .png
Abbildung: Die Multi-Tenancy-Architektur für eine Enterprise-RAG-Wissensdatenbank
Das obige Diagramm zeigt die Multi-Tenancy-Architektur eines Enterprise-RAG-Systems.
System Administrators überwachen das RAG-System, verwalten die Ressourcenzuweisung, weisen Datenbanken zu, ordnen sie Resource Groups zu und stellen Skalierbarkeit sicher. Sie kümmern sich um die physische Infrastruktur, wie im Diagramm dargestellt, in dem jede Resource Group (z. B. Resource Group 1, 2 und 3) physischen Servern (Query Nodes) zugeordnet ist.
Mandanten (Datenbankbesitzer und Entwickler) verwalten die Wissensdatenbank und iterieren sie auf Grundlage der nutzergenerierten Q&A-Daten, wie im Diagramm dargestellt. Verschiedene Datenbanken (Datenbank X, Y, Z) enthalten Sammlungen mit unterschiedlichen Inhalten der Wissensdatenbank (Sammlung A, B usw.).
Endnutzer interagieren mit dem System schreibgeschützt über das LLM. Während sie Abfragen an das System stellen, werden ihre Fragen in der separaten Q&A-Datensatztabelle (einer separaten Datenbank) protokolliert und speisen kontinuierlich wertvolle Daten zurück in das System.
Dieses Design stellt sicher, dass jede Prozessebene – von der Nutzerinteraktion bis zur Systemadministration – nahtlos zusammenarbeitet und der Organisation dabei hilft, eine robuste und sich kontinuierlich verbessernde Wissensdatenbank aufzubauen.
Zusammenfassung
In diesem Blog haben wir untersucht, wie Multi-Tenancy-Frameworks eine entscheidende Rolle für die Skalierbarkeit, Sicherheit und Leistung von RAG-gestützten Wissensdatenbanken spielen. Durch die Isolierung von Daten und Ressourcen für verschiedene Mandanten können Unternehmen Datenschutz, regulatorische Compliance und eine optimierte Ressourcenzuweisung über eine gemeinsame Infrastruktur hinweg sicherstellen. Milvus ermöglicht es Unternehmen mit seinen flexiblen Multi-Tenancy-Strategien, je nach ihren spezifischen Anforderungen die passende Ebene der Datenisolierung zu wählen – von der Datenbankebene bis zur Partitionsebene. Die Wahl des richtigen Multi-Tenancy-Ansatzes stellt sicher, dass Unternehmen Mandanten maßgeschneiderte Services bereitstellen können, selbst wenn sie mit vielfältigen Daten und Workloads umgehen.
Durch die Befolgung der hier beschriebenen Best Practices können Organisationen Multi-Tenancy-RAG-Systeme effektiv entwerfen und verwalten, die nicht nur überlegene Nutzererlebnisse bieten, sondern auch mühelos skalieren, wenn die geschäftlichen Anforderungen wachsen. Die Architektur von Milvus stellt sicher, dass Unternehmen ein hohes Maß an Isolation, Sicherheit und Leistung aufrechterhalten können, was es zu einer entscheidenden Komponente beim Aufbau unternehmensgerechter, RAG-gestützter Wissensdatenbanken macht.
Bleiben Sie dran für weitere Einblicke in Multi-Tenancy-RAG
In diesem Blog haben wir besprochen, wie die Multi-Tenancy-Strategien von Milvus darauf ausgelegt sind, Mandanten zu verwalten, jedoch nicht die Endnutzer innerhalb dieser Mandanten. Interaktionen von Endnutzern finden in der Regel auf der Anwendungsebene statt, während die Vektordatenbank selbst sich dieser Nutzer nicht bewusst ist.
Sie fragen sich vielleicht: Wenn ich präzisere Antworten auf Grundlage des Abfrageverlaufs jedes Endnutzers bereitstellen möchte, muss Milvus dann nicht einen personalisierten Q&A-Kontext für jeden Nutzer verwalten?
Das ist eine ausgezeichnete Frage, und die Antwort hängt wirklich vom Anwendungsfall ab. Beispielsweise sind bei einem On-Demand-Beratungsservice die Abfragen zufällig, und der Hauptfokus liegt auf der Qualität der Wissensdatenbank statt auf der Nachverfolgung des historischen Kontexts eines Nutzers.
In anderen Fällen müssen RAG-Systeme jedoch kontextbewusst sein. Wenn dies erforderlich ist, muss Milvus mit der Anwendungsebene zusammenarbeiten, um ein personalisiertes Gedächtnis für den Kontext jedes Nutzers zu pflegen. Dieses Design ist besonders wichtig für Anwendungen mit sehr vielen Endnutzern, die wir in meinem nächsten Beitrag genauer untersuchen werden. Bleiben Sie dran für weitere Einblicke!
Weiterlesen
Selecting the Right ETL Tools for Unstructured Data to Prepare for AI
Learn the right ETL tools for unstructured data to power AI. Explore key challenges, tool comparisons, and integrations with Milvus for vector search.
AI Integration in Video Surveillance Tools: Transforming the Industry with Vector Databases
Discover how AI and vector databases are revolutionizing video surveillance with real-time analysis, faster threat detection, and intelligent search capabilities for enhanced security.
Zilliz Cloud BYOC Upgrades: Bring Enterprise-Grade Security, Networking Isolation, and More
Discover how Zilliz Cloud BYOC brings enterprise-grade security, networking isolation, and infrastructure automation to vector database deployments in AWS