Design von Multi-Tenancy RAG mit Milvus: Best Practices für skalierbare Enterprise Knowledge Bases

Einführung

In den letzten Jahren hat sich Retrieval-Augmented Generation (RAG) als zuverlässige Lösung für große Organisationen herauskristallisiert, um ihre LLM-gestützten Anwendungen zu verbessern, insbesondere solche mit verschiedenen Benutzern. Da solche Anwendungen wachsen, wird die Implementierung eines Multi-Tenancy-Frameworks unerlässlich. Multi-Tenancy bietet einen sicheren, isolierten Zugriff auf Daten für verschiedene Benutzergruppen und gewährleistet so das Vertrauen der Benutzer, die Einhaltung gesetzlicher Vorschriften und die Verbesserung der betrieblichen Effizienz.

Milvus ist eine Open-Source-Vektordatenbank, die für die Verarbeitung hochdimensionaler Vektordaten entwickelt wurde. Sie ist eine unverzichtbare Infrastrukturkomponente von RAG, die kontextbezogene Informationen für LLMs aus externen Quellen speichert und abruft. Milvus bietet flexible Multi-Tenancy-Strategien für verschiedene Anforderungen, einschließlich Multi-Tenancy auf Datenbank-, Sammel- und Partitionsebene.

In diesem Beitrag werden wir Folgendes behandeln:

• Was ist Multi-Tenancy und warum ist es wichtig?

• Multi-Tenancy-Strategien in Milvus

• Beispiel: Multi-Tenancy-Strategie für eine RAG-gestützte Unternehmens-Wissensdatenbank

Was ist Multi-Tenancy und warum ist sie wichtig?

Multi-Tenancy ist eine Architektur, bei der mehrere Kunden oder Teams, sogenannte "Tenants", eine einzige Instanz einer Anwendung oder eines Systems gemeinsam nutzen. Die Daten und Konfigurationen der einzelnen Mandanten sind logisch isoliert, um Datenschutz und Sicherheit zu gewährleisten, während alle Mandanten dieselbe zugrunde liegende Infrastruktur nutzen.

Stellen Sie sich eine SaaS-Plattform vor, die wissensbasierte Lösungen für mehrere Unternehmen bereitstellt. Jedes Unternehmen ist ein Mieter.

• Mieter A ist eine Organisation des Gesundheitswesens, die patientenbezogene FAQs und Compliance-Dokumente speichert.

• Mieter B ist ein Technologieunternehmen, das interne IT-Fehlerbehebungsabläufe verwaltet.

• Mieter C ist ein Einzelhandelsunternehmen, das FAQs für Produktrücksendungen verwaltet.

Jeder Tenant arbeitet in einer vollständig isolierten Umgebung, um sicherzustellen, dass keine Daten von Tenant A in das System von Tenant B gelangen oder umgekehrt. Darüber hinaus sind Entscheidungen zur Ressourcenzuweisung, Abfrageleistung und Skalierung mandantenspezifisch, so dass eine hohe Leistung unabhängig von Arbeitslastspitzen in einem Mandanten gewährleistet ist.

Multi-Tenant funktioniert auch für Systeme, die verschiedene Teams innerhalb desselben Unternehmens bedienen. Stellen Sie sich ein großes Unternehmen vor, das eine RAG-gestützte Wissensdatenbank für seine internen Abteilungen wie Personalabteilung, Rechtsabteilung und Marketing einsetzt. Jede Abteilung ist in dieser Konstellation ein Tenant mit isolierten Daten und Ressourcen.

Multi-Tenancy bietet erhebliche Vorteile, darunter Kosteneffizienz, Skalierbarkeit und robuste Datensicherheit. Durch die gemeinsame Nutzung einer einzigen Infrastruktur können Dienstanbieter ihre Gemeinkosten senken und eine effektivere Ressourcennutzung gewährleisten. Dieser Ansatz lässt sich außerdem mühelos skalieren - für das Einbinden neuer Mandanten werden weitaus weniger Ressourcen benötigt als für die Erstellung separater Instanzen für jeden einzelnen Mandanten, wie es bei Modellen mit Einzelmandanten der Fall ist. Wichtig ist, dass die Mandantenfähigkeit die Datensicherheit aufrechterhält, indem sie eine strikte Datenisolierung für jeden Mandanten gewährleistet, wobei Zugriffskontrollen und Verschlüsselung sensible Informationen vor unbefugtem Zugriff schützen. Darüber hinaus können Aktualisierungen, Patches und neue Funktionen auf allen Mandanten gleichzeitig bereitgestellt werden, was die Systemwartung vereinfacht und die Belastung der Administratoren verringert, während gleichzeitig sichergestellt wird, dass die Sicherheits- und Compliance-Standards konsequent eingehalten werden.

Mehrmandanten-Strategien in Milvus

Um zu verstehen, wie Milvus Multi-Tenancy unterstützt, ist es wichtig, sich zunächst anzusehen, wie es die Benutzerdaten organisiert.

Wie Milvus die Benutzerdaten organisiert

Milvus strukturiert die Daten auf drei Ebenen, die sich von breit bis granular erstrecken: Datenbank, Sammlung und Partition/Partitionsschlüssel.

Abbildung - Wie Milvus die Benutzerdaten organisiert .png

Abbildung: Wie Milvus die Benutzerdaten organisiert

• Datenbank: Sie fungiert als logischer Container, ähnlich wie eine Datenbank in traditionellen relationalen Systemen.

• Sammlung: Vergleichbar mit einer Tabelle in einer Datenbank, organisiert eine Sammlung die Daten in verwaltbaren Gruppen.

• Partition/Partitionsschlüssel: Innerhalb einer Sammlung können die Daten durch Partitionen weiter segmentiert werden. Mit einem Partitionsschlüssel werden Daten mit demselben Schlüssel gruppiert. Wenn Sie beispielsweise eine Benutzer-ID als Partitionsschlüssel verwenden, werden alle Daten für einen bestimmten Benutzer in demselben logischen Segment gespeichert. Auf diese Weise ist es einfach, Daten abzurufen, die an einzelne Benutzer gebunden sind.

Wenn Sie von der Datenbank zur Sammlung und zum Partitionsschlüssel übergehen, wird die Granularität der Datenorganisation immer feiner.

Um eine stärkere Datensicherheit und eine angemessene Zugriffskontrolle zu gewährleisten, bietet Milvus auch eine robuste rollenbasierte Zugriffskontrolle (RBAC), die es Administratoren ermöglicht, für jeden Benutzer spezifische Berechtigungen zu definieren. Nur autorisierte Benutzer können auf bestimmte Daten zugreifen.

Milvus unterstützt mehrere Strategien für die Implementierung von Mandantenfähigkeit und bietet damit Flexibilität je nach den Anforderungen Ihrer Anwendung: Mandantenfähigkeit auf Datenbankebene, Sammlungsebene und Partitionsebene.

Multi-Tenancy auf Datenbank-Ebene

Bei der Mandantenfähigkeit auf Datenbankebene wird jedem Mandanten eine eigene Datenbank innerhalb desselben Milvus-Clusters zugewiesen. Diese Strategie bietet eine starke Datenisolierung und gewährleistet eine optimale Suchleistung. Sie kann jedoch zu einer ineffizienten Ressourcennutzung führen, wenn bestimmte Tenants inaktiv bleiben.

Multi-Tenancy auf Sammlungsebene

Bei der Multi-Mandantenschaft auf Sammlungsebene können wir die Daten für die Mandanten auf zwei Arten organisieren.

• Eine Sammlung für alle Mieter: Alle Mieter teilen sich eine einzige Sammlung, wobei mieterspezifische Felder zur Filterung verwendet werden. Dieser Ansatz ist zwar einfach zu implementieren, kann aber mit zunehmender Anzahl von Mietern zu Leistungsengpässen führen.

• Eine Sammlung pro Mandant: Jeder Mandant kann eine eigene Sammlung haben, was die Isolierung und Leistung verbessert, aber mehr Ressourcen erfordert. Bei dieser Konfiguration kann es zu Einschränkungen bei der Skalierbarkeit kommen, wenn die Anzahl der Mandanten die Sammlungskapazität von Milvus übersteigt.

Multi-Mandantenschaft auf Partitionsebene

Multi-Tenancy auf Partitionsebene konzentriert sich auf die Organisation von Mandanten innerhalb einer einzigen Sammlung. Auch hier gibt es zwei Möglichkeiten, Mieterdaten zu organisieren.

• Eine Partition pro Mieter: Die Mieter teilen sich eine Sammlung, aber ihre Daten werden in separaten Partitionen gespeichert. Wir können Daten isolieren, indem wir jedem Tenant eine eigene Partition zuweisen und so ein Gleichgewicht zwischen Isolierung und Suchleistung herstellen. Dieser Ansatz wird jedoch durch die maximale Partitionsgrenze von Milvus eingeschränkt.

• Partition-Schlüssel-basierte Mandantenfähigkeit: Hierbei handelt es sich um eine skalierbarere Option, bei der eine einzige Sammlung Partitionsschlüssel zur Unterscheidung von Mandanten verwendet. Diese Methode vereinfacht die Ressourcenverwaltung und ermöglicht eine höhere Skalierbarkeit, unterstützt jedoch keine Massendateneinfügungen.

Die nachstehende Tabelle fasst die wichtigsten Unterschiede zwischen den wichtigsten Multi-Tenancy-Ansätzen zusammen.

Granularität	Datenbankebene	Sammlungsebene	Partition Schlüssel-Ebene
Max. unterstützte Mieter	~1,000	~10,000	~10,000,000
Flexibilität bei der Datenorganisation	Hoch: Benutzer können mehrere Sammlungen mit benutzerdefinierten Schemata definieren.	Mittel: Benutzer sind auf eine Sammlung mit einem benutzerdefinierten Schema beschränkt.	Gering: Alle Benutzer teilen sich eine Sammlung, was ein einheitliches Schema erfordert.
Kosten pro Benutzer	Hoch	Mittel	Niedrig
Physische Ressourcenisolierung	Ja	Ja	Nein
RBAC	Ja	Ja	Nein
Suchleistung	Stark	Mittel	Stark

Beispiel: Multi-Tenancy-Strategie für eine RAG-gestützte Wissensdatenbank im Unternehmen

Beim Entwurf der Multi-Tenancy-Strategie für ein RAG-System ist es wichtig, den Ansatz auf die spezifischen Bedürfnisse Ihres Unternehmens und Ihrer Mandanten abzustimmen. Milvus bietet verschiedene Multi-Tenancy-Strategien an, und die Wahl der richtigen Strategie hängt von der Anzahl der Mandanten, ihren Anforderungen und dem erforderlichen Grad der Datenisolierung ab. Im Folgenden finden Sie einen praktischen Leitfaden für diese Entscheidungen am Beispiel einer RAG-gestützten Wissensdatenbank für Unternehmen.

Verständnis der Mandantenstruktur vor der Entscheidung für eine Multi-Tenancy-Strategie

Eine RAG-gestützte Wissensdatenbank für Unternehmen dient oft einer kleinen Anzahl von Mietern. Bei diesen Mandanten handelt es sich in der Regel um unabhängige Geschäftseinheiten wie IT, Vertrieb, Rechtsabteilung und Marketing, die jeweils unterschiedliche Wissensdatenbankdienste benötigen. Die Personalabteilung verwaltet beispielsweise sensible Mitarbeiterinformationen wie Einführungsleitfäden und Richtlinien für Sozialleistungen, die vertraulich und nur für Mitarbeiter der Personalabteilung zugänglich sein sollten.

In diesem Fall sollte jede Geschäftseinheit als separater Tenant behandelt werden, und eine Multi-Tenancy-Strategie auf Datenbankebene ist oft die beste Lösung. Durch die Zuweisung dedizierter Datenbanken an jeden Mandanten können Unternehmen eine starke logische Isolierung erreichen, was die Verwaltung vereinfacht und die Sicherheit erhöht. Dieses Setup bietet Tenants eine hohe Flexibilität: Sie können benutzerdefinierte Datenmodelle innerhalb von Sammlungen definieren, beliebig viele Sammlungen erstellen und die Zugriffskontrolle für ihre Sammlungen unabhängig verwalten.

Höhere Sicherheit durch physische Ressourcenisolierung

In Situationen, in denen die Datensicherheit einen hohen Stellenwert hat, reicht die logische Isolierung auf Datenbankebene möglicherweise nicht aus. Beispielsweise können einige Geschäftseinheiten kritische oder hochsensible Daten verarbeiten, die stärkere Garantien gegen Störungen durch andere Tenants erfordern. In solchen Fällen können wir einen physischen Isolationsansatz auf einer Multi-Tenancy-Struktur auf Datenbankebene implementieren.

Milvus ermöglicht es uns, logische Komponenten wie Datenbanken und Sammlungen auf physische Ressourcen abzubilden. Diese Methode stellt sicher, dass die Aktivitäten anderer Mandanten keine Auswirkungen auf kritische Vorgänge haben. Sehen wir uns an, wie dieser Ansatz in der Praxis funktioniert.

Abbildung - Wie Milvus physische Ressourcen verwaltet.png

Abbildung: Wie Milvus physische Ressourcen verwaltet

Wie im obigen Diagramm dargestellt, gibt es in Milvus drei Ebenen der Ressourcenverwaltung: Abfrageknoten, Ressourcengruppe und Datenbank.

• Abfrageknoten: Die Komponente, die Abfrageaufgaben verarbeitet. Sie läuft auf einer physischen Maschine oder einem Container (z. B. einem Pod in Kubernetes).

• Ressourcengruppe: Eine Sammlung von Abfrageknoten, die als Brücke zwischen logischen Komponenten (Datenbanken und Sammlungen) und physischen Ressourcen dient. Sie können einer einzelnen Ressourcengruppe eine oder mehrere Datenbanken oder Sammlungen zuweisen.

In dem im obigen Diagramm dargestellten Beispiel gibt es drei logische Datenbanken: X, Y, und Z.

• Datenbank X: Enthält Sammlung A.

• Datenbank Y: Enthält die Sammlungen B und C.

• Datenbank Z: Enthält die Sammlungen D und E.

Nehmen wir an, Datenbank X enthält eine kritische Wissensdatenbank, die nicht durch die Last von Datenbank Y oder Datenbank Z beeinträchtigt werden soll:

• Datenbank X wird eine eigene Ressourcengruppe zugewiesen, um zu gewährleisten, dass ihre kritische Wissensbasis nicht durch die Arbeitslasten anderer Datenbanken beeinträchtigt wird.

• DieSammlung E wird ebenfalls einer eigenen Ressourcengruppe innerhalb ihrer übergeordneten Datenbank(Z) zugewiesen. Dadurch wird eine Isolierung auf der Ebene der Sammlung für bestimmte kritische Daten innerhalb einer gemeinsam genutzten Datenbank erreicht.

Die übrigen Sammlungen in den Datenbanken Y und Z teilen sich die physischen Ressourcen der Ressourcengruppe 2.

Durch die sorgfältige Zuordnung von logischen Komponenten zu physischen Ressourcen können Unternehmen eine flexible, skalierbare und sichere mandantenfähige Architektur erreichen, die auf ihre spezifischen Geschäftsanforderungen zugeschnitten ist.

Gestaltung des Zugriffs auf Endbenutzer-Ebene

Nachdem wir nun die Best Practices für die Auswahl einer Multi-Tenancy-Strategie für eine Unternehmens-RAG kennengelernt haben, wollen wir nun untersuchen, wie der Zugriff auf Benutzerebene in solchen Systemen gestaltet werden kann.

In diesen Systemen interagieren die Endbenutzer in der Regel mit der Wissensdatenbank in einem Nur-Lese-Modus über LLMs. Dennoch müssen Unternehmen die von den Nutzern generierten Q&A-Daten verfolgen und sie mit bestimmten Nutzern verknüpfen, um beispielsweise die Genauigkeit der Wissensdatenbank zu verbessern oder personalisierte Dienste anzubieten.

Nehmen wir als Beispiel den intelligenten Beratungsdienst eines Krankenhauses. Patienten könnten Fragen stellen wie "Gibt es heute noch freie Termine beim Facharzt?" oder "Sind spezielle Vorbereitungen für meine bevorstehende Operation erforderlich?". Diese Fragen wirken sich zwar nicht direkt auf die Wissensdatenbank aus, doch ist es für das Krankenhaus wichtig, solche Interaktionen zu verfolgen, um die Dienstleistungen zu verbessern. Diese Frage-Antwort-Paare werden in der Regel in einer separaten Datenbank (es muss nicht unbedingt eine Vektordatenbank sein) gespeichert, die für die Protokollierung von Interaktionen bestimmt ist.

Abbildung: Die mandantenfähige Architektur für eine unternehmensweite RAG-Wissensdatenbank .png

Abbildung: Die Multi-Tenancy-Architektur für eine RAG-Wissensdatenbank im Unternehmen

Das obige Diagramm zeigt die Multi-Tenancy-Architektur eines Unternehmens-RAG-Systems.

• Systemadministratoren beaufsichtigen das RAG-System, verwalten die Ressourcenzuweisung, weisen Datenbanken zu, ordnen sie Ressourcengruppen zu und stellen die Skalierbarkeit sicher. Sie verwalten die physische Infrastruktur, wie im Diagramm dargestellt, wo jede Ressourcengruppe (z.B. Ressourcengruppe 1, 2 und 3) physischen Servern (Abfrageknoten) zugeordnet ist.

• Die Tenants (Datenbankbesitzer und -entwickler) verwalten die Wissensdatenbank und bearbeiten sie auf der Grundlage der von den Benutzern erstellten Q&A-Daten, wie im Diagramm dargestellt. Verschiedene Datenbanken (Datenbank X, Y, Z) enthalten Sammlungen mit unterschiedlichen Inhalten der Wissensdatenbank (Sammlung A, B, usw.).

• Die Endbenutzer interagieren mit dem System auf rein lesende Weise über das LLM. Wenn sie das System abfragen, werden ihre Fragen in der separaten Q&A-Datentabelle (einer separaten Datenbank) protokolliert, wodurch kontinuierlich wertvolle Daten in das System zurückfließen.

Dieses Design stellt sicher, dass jede Prozessebene - von der Benutzerinteraktion bis zur Systemverwaltung - nahtlos funktioniert und dem Unternehmen hilft, eine robuste und sich ständig verbessernde Wissensbasis 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 den Datenschutz, die Einhaltung von Vorschriften und eine optimierte Ressourcenzuweisung in einer gemeinsam genutzten Infrastruktur sicherstellen. Milvus mit seinen flexiblen Multi-Tenancy-Strategien ermöglicht es Unternehmen, den richtigen Grad der Datenisolierung zu wählen - von der Datenbankebene bis zur Partitionsebene - je nach ihren spezifischen Anforderungen. Die Wahl des richtigen Multi-Tenancy-Ansatzes stellt sicher, dass Unternehmen ihren Mietern maßgeschneiderte Dienste anbieten können, selbst wenn sie mit unterschiedlichen Daten und Workloads zu tun haben.

Wenn Unternehmen die hier beschriebenen Best Practices befolgen, können sie effektiv mandantenfähige RAG-Systeme entwerfen und verwalten, die nicht nur ein hervorragendes Benutzererlebnis bieten, sondern auch mühelos skalierbar sind, wenn die Geschäftsanforderungen wachsen. Die Architektur von Milvus stellt sicher, dass Unternehmen ein hohes Maß an Isolierung, Sicherheit und Leistung aufrechterhalten können, was sie zu einer entscheidenden Komponente beim Aufbau von RAG-gestützten Wissensdatenbanken auf Unternehmensebene macht.

Bleiben Sie dran für weitere Einblicke in Multi-Tenancy RAG

In diesem Blog haben wir erörtert, wie die Multi-Tenancy-Strategien von Milvus für die Verwaltung von Mandanten, aber nicht für die Verwaltung von Endbenutzern innerhalb dieser Mandanten konzipiert sind. Die Interaktionen der Endbenutzer finden in der Regel auf der Anwendungsebene statt, während die Vektordatenbank selbst nichts von diesen Benutzern weiß.

Sie fragen sich das vielleicht: Wenn ich präzisere Antworten auf der Grundlage der Abfragehistorie eines jeden Endbenutzers geben möchte, muss Milvus dann nicht einen personalisierten Q&A-Kontext für jeden Benutzer pflegen?

Das ist eine gute Frage, und die Antwort hängt wirklich vom Anwendungsfall ab. Bei einem On-Demand-Beratungsdienst zum Beispiel sind die Anfragen zufällig und das Hauptaugenmerk liegt auf der Qualität der Wissensdatenbank und nicht darauf, den historischen Kontext eines Benutzers zu verfolgen.

In anderen Fällen müssen RAG-Systeme jedoch kontextabhängig sein. Wenn dies erforderlich ist, muss Milvus mit der Anwendungsschicht zusammenarbeiten, um ein personalisiertes Gedächtnis für den Kontext jedes Benutzers zu erhalten. Dieses Design ist besonders wichtig für Anwendungen mit einer großen Anzahl von Endbenutzern, auf die wir in meinem nächsten Beitrag näher eingehen werden. Bleiben Sie dran für weitere Einblicke!