Conception de RAG multi-tenant avec Milvus : Meilleures pratiques pour des bases de connaissances d'entreprise évolutives

Introduction

Au cours des deux dernières années, la génération améliorée par récupération (RAG) est apparue comme une solution fiable pour les grandes organisations afin d'améliorer leurs applications alimentées par LLM, en particulier celles qui ont des utilisateurs divers. Au fur et à mesure que ces applications se développent, la mise en œuvre d'un cadre multi-tenant devient essentielle. La multi-location offre un accès sécurisé et isolé aux données pour différents groupes d'utilisateurs, garantissant ainsi la confiance des utilisateurs, le respect des normes réglementaires et l'amélioration de l'efficacité opérationnelle.

Milvus est une base de données vectorielles open-source conçue pour traiter des données vectorielles de haute dimension. Il s'agit d'un élément d'infrastructure indispensable de RAG, qui stocke et récupère des informations contextuelles pour les MLD à partir de sources externes. Milvus offre des stratégies flexibles de multi-tenance pour divers besoins, y compris la multi-tenance au niveau de la base de données, au niveau de la collection et au niveau de la partition.

Dans ce billet, nous aborderons les points suivants :

• Qu'est-ce que la multi-location et pourquoi est-elle importante ?

• Stratégies de multi-tenance dans Milvus

• Exemple : Stratégie de multi-tenance pour une base de connaissances d'entreprise alimentée par RAG

Qu'est-ce que le multi-tenant et pourquoi est-il important ?

Lamulti-location est une architecture dans laquelle plusieurs clients ou équipes, appelés "locataires", partagent une instance unique d'une application ou d'un système. Les données et les configurations de chaque locataire sont logiquement isolées, ce qui garantit la confidentialité et la sécurité, tandis que tous les locataires partagent la même infrastructure sous-jacente.

Imaginez une plateforme SaaS qui fournit des solutions basées sur la connaissance à plusieurs entreprises. Chaque entreprise est un locataire.

• Le locataire A est une organisation de soins de santé qui stocke des FAQ et des documents de conformité destinés aux patients.

• Le locataire B est une entreprise technologique qui gère les flux de travail internes de dépannage informatique.

• Le locataire C est une entreprise de vente au détail qui gère les FAQ du service clientèle pour les retours de produits.

Chaque locataire opère dans un environnement complètement isolé, ce qui garantit qu'aucune donnée du locataire A ne s'infiltre dans le système du locataire B ou vice versa. En outre, l'allocation des ressources, les performances des requêtes et les décisions de mise à l'échelle sont spécifiques à chaque locataire, ce qui garantit des performances élevées indépendamment des pics de charge de travail d'un locataire.

La multilocation fonctionne également pour les systèmes qui desservent différentes équipes au sein d'une même organisation. Imaginez une grande entreprise qui utilise une base de connaissances alimentée par RAG pour servir ses services internes, tels que les ressources humaines, le service juridique et le service marketing. Dans cette configuration, chaque département est un locataire avec des données et des ressources isolées.

La multi-location offre des avantages significatifs, notamment en termes de rentabilité, d'évolutivité et de sécurité des données. En partageant une infrastructure unique, les fournisseurs de services peuvent réduire les frais généraux et garantir une utilisation plus efficace des ressources. Cette approche est également évolutive : l'intégration de nouveaux locataires nécessite beaucoup moins de ressources que la création d'instances distinctes pour chacun d'entre eux, comme c'est le cas avec les modèles à locataire unique. Il est important de noter que la multi-location maintient une sécurité des données solide en garantissant une isolation stricte des données pour chaque locataire, avec des contrôles d'accès et un cryptage qui protègent les informations sensibles d'un accès non autorisé. En outre, les mises à jour, les correctifs et les nouvelles fonctionnalités peuvent être déployés simultanément dans tous les locataires, ce qui simplifie la maintenance du système et réduit la charge des administrateurs tout en garantissant le respect constant des normes de sécurité et de conformité.

Stratégies multi-locataires dans Milvus

Pour comprendre comment Milvus prend en charge la multi-location, il est important d'examiner tout d'abord la manière dont il organise les données utilisateur.

Comment Milvus organise les données utilisateur

Milvus structure les données sur trois couches, de la plus large à la plus granulaire : Base de données, Collection et Partition/Clé de partition.

Figure - Comment Milvus organise les données utilisateur .png

Figure : Comment Milvus organise les données utilisateur

• Base de données: Il s'agit d'un conteneur logique, similaire à une base de données dans les systèmes relationnels traditionnels.

• Collection: Comparable à une table dans une base de données, une collection organise les données en groupes faciles à gérer.

• Partition/clé de partition: Au sein d'une collection, les données peuvent être segmentées par des partitions. En utilisant une clé de partition, les données ayant la même clé sont regroupées. Par exemple, si vous utilisez un identifiant d'utilisateur comme clé de partition, toutes les données relatives à un utilisateur spécifique seront stockées dans le même segment logique. Il est ainsi plus facile d'extraire les données liées à des utilisateurs individuels.

En passant de la base de données à la collection et à la clé de partition, la granularité de l'organisation des données devient de plus en plus fine.

Pour garantir une plus grande sécurité des données et un contrôle d'accès approprié, Milvus fournit également un contrôle d'accès basé sur les rôles (RBAC) robuste, qui permet aux administrateurs de définir des autorisations spécifiques pour chaque utilisateur. Seuls les utilisateurs autorisés peuvent accéder à certaines données.

Milvus prend en charge plusieurs stratégies de mise en œuvre de la multi-tenance, offrant une flexibilité basée sur les besoins de votre application : multi-tenance au niveau de la base de données, au niveau de la collection et au niveau de la partition.

Multi-tenance au niveau de la base de données

Avec l'approche de multi-location au niveau de la base de données, chaque locataire se voit attribuer sa propre base de données au sein du même cluster Milvus. Cette stratégie permet une forte isolation des données et garantit des performances de recherche optimales. Toutefois, elle peut conduire à une utilisation inefficace des ressources si certains locataires restent inactifs.

Multi-tenance au niveau de la collection

Ici, dans la multi-location au niveau de la collection, nous pouvons organiser les données pour les locataires de deux manières.

• Une collection pour tous les locataires: Tous les locataires partagent une seule collection, avec des champs spécifiques au locataire utilisés pour le filtrage. Bien que simple à mettre en œuvre, cette approche peut entraîner des goulets d'étranglement au niveau des performances lorsque le nombre de locataires augmente.

• Une collection par locataire: Chaque locataire peut disposer d'une collection dédiée, ce qui améliore l'isolement et les performances, mais nécessite davantage de ressources. Cette configuration peut se heurter à des limites d'évolutivité si le nombre de locataires dépasse la capacité de collecte de Milvus.

Multi-tenance au niveau des partitions

La multilocation au niveau des partitions se concentre sur l'organisation des locataires au sein d'une collection unique. Ici, nous avons également deux façons d'organiser les données des locataires.

• Une partition par locataire: Les locataires partagent une collection, mais leurs données sont stockées dans des partitions distinctes. Nous pouvons isoler les données en attribuant à chaque locataire une partition dédiée, ce qui permet d'équilibrer l'isolation et les performances de recherche. Toutefois, cette approche est limitée par la limite maximale de partition de Milvus.

• Multi-locations basées sur les clés de partition: Il s'agit d'une option plus évolutive dans laquelle une collection unique utilise des clés de partition pour distinguer les locataires. Cette méthode simplifie la gestion des ressources et permet une plus grande évolutivité, mais ne prend pas en charge les insertions de données en masse.

Le tableau ci-dessous résume les principales différences entre les approches clés de multi-location.

Granularité	Niveau base de données	Niveau de la collection	Niveau des clés de partition
Nombre maximal de locataires pris en charge	~1,000	~10,000	~10,000,000
Flexibilité de l'organisation des données	Élevée : les utilisateurs peuvent définir plusieurs collections avec des schémas personnalisés.	Moyenne : Les utilisateurs sont limités à une seule collection avec un schéma personnalisé.	Faible : Tous les utilisateurs partagent une collection, ce qui nécessite un schéma cohérent.
Coût par utilisateur	Élevé	Moyen	Faible
Isolation des ressources physiques	Oui	Oui	Non
RBAC	Oui	Oui	Non
Performance de recherche	Fortes	Moyenne	Fortes

Exemple : Stratégie multi-locataires pour une base de connaissances d'entreprise alimentée par RAG

Lors de la conception de la stratégie multi-locataires pour un système RAG, il est essentiel d'aligner votre approche sur les besoins spécifiques de votre entreprise et de vos locataires. Milvus propose différentes stratégies multi-locataires et le choix de la bonne stratégie dépend du nombre de locataires, de leurs exigences et du niveau d'isolation des données nécessaire. Voici un guide pratique pour prendre ces décisions, en prenant pour exemple une base de connaissances d'entreprise alimentée par RAG.

Comprendre la structure des locataires avant de choisir une stratégie de multi-occupation

Une base de connaissances d'entreprise alimentée par RAG sert souvent un petit nombre de locataires. Ces locataires sont généralement des unités commerciales indépendantes telles que l'informatique, les ventes, le service juridique et le marketing, qui ont chacune besoin de services de base de connaissances distincts. Par exemple, le département des ressources humaines gère des informations sensibles sur les employés, telles que les guides d'intégration et les politiques d'avantages sociaux, qui devraient être confidentielles et accessibles uniquement au personnel des ressources humaines.

Dans ce cas, chaque unité commerciale doit être traitée comme un locataire distinct et une stratégie de multi-location au niveau de la base de données est souvent la plus appropriée. En attribuant des bases de données dédiées à chaque locataire, les organisations peuvent obtenir une forte isolation logique, simplifier la gestion et renforcer la sécurité. Cette configuration offre aux locataires une grande flexibilité : ils peuvent définir des modèles de données personnalisés au sein des collections, créer autant de collections que nécessaire et gérer indépendamment le contrôle d'accès à leurs collections.

Renforcer la sécurité grâce à l'isolation physique des ressources

Dans les situations où la sécurité des données est une priorité absolue, l'isolation logique au niveau de la base de données peut s'avérer insuffisante. Par exemple, certaines unités commerciales peuvent traiter des données critiques ou très sensibles, ce qui nécessite des garanties plus solides contre les interférences d'autres locataires. Dans ce cas, nous pouvons mettre en œuvre une approche d'isolation physique au-dessus d'une structure de multi-location au niveau de la base de données.

Milvus nous permet de mapper des composants logiques, tels que des bases de données et des collections, à des ressources physiques. Cette méthode garantit que les activités des autres locataires n'ont pas d'impact sur les opérations critiques. Voyons comment cette approche fonctionne dans la pratique.

Figure- Comment Milvus gère les ressources physiques.png

Figure- Comment Milvus gère les ressources physiques.png Comment Milvus gère les ressources physiques

Comme le montre le diagramme ci-dessus, il existe trois niveaux de gestion des ressources dans Milvus : Le nœud de requête, le groupe de ressources et la base de données.

• Nœud de requête: Le composant qui traite les tâches de requête. Il s'exécute sur une machine physique ou un conteneur (par exemple, un pod dans Kubernetes).

• Groupe de ressources: Une collection de nœuds de requête qui agit comme un pont entre les composants logiques (bases de données et collections) et les ressources physiques. Vous pouvez allouer une ou plusieurs bases de données ou collections à un seul groupe de ressources.

Dans l'exemple illustré dans le diagramme ci-dessus, il existe trois bases de données logiques : X, Y et Z.

• Base de données X: contient la collection A.

• Base de données Y: contient les collections B et C.

• Base de données Z: contient les collections D et E.

Supposons que la base de données X contienne une base de connaissances critique que nous ne voulons pas voir affectée par la charge de la base de données Y ou de la base de données Z. Pour garantir l'isolation des données, la base de données X se voit attribuer son propre groupe de ressources :

• Labase dedonnées X se voit attribuer son propre groupe de ressources afin de garantir que sa base de connaissances critique n'est pas affectée par les charges de travail des autres bases de données.

• Lacollection E est également affectée à un groupe de ressources distinct au sein de sa base de données mère(Z). Cela permet d'isoler au niveau de la collection des données critiques spécifiques au sein d'une base de données partagée.

Pendant ce temps, les autres collections des bases de données Y et Z partagent les ressources physiques du groupe de ressources 2.

En mappant soigneusement les composants logiques aux ressources physiques, les entreprises peuvent mettre en place une architecture multi-tenant flexible, évolutive et sécurisée, adaptée à leurs besoins spécifiques.

Conception de l'accès au niveau de l'utilisateur final

Maintenant que nous avons appris les meilleures pratiques pour choisir une stratégie multi-tenant pour un RAG d'entreprise, voyons comment concevoir l'accès au niveau de l'utilisateur dans de tels systèmes.

Dans ces systèmes, les utilisateurs finaux interagissent généralement avec la base de connaissances en mode lecture seule par le biais de LLM. Cependant, les organisations ont toujours besoin de suivre ces données de questions-réponses générées par les utilisateurs et de les relier à des utilisateurs spécifiques à diverses fins, telles que l'amélioration de la précision de la base de connaissances ou l'offre de services personnalisés.

Prenons l'exemple du service de consultation intelligent d'un hôpital. Les patients peuvent poser des questions telles que : "Y a-t-il des rendez-vous disponibles avec le spécialiste aujourd'hui ?" ou "Y a-t-il une préparation spécifique nécessaire pour mon opération à venir ?". Bien que ces questions n'aient pas d'impact direct sur la base de connaissances, il est important pour l'hôpital de suivre ces interactions afin d'améliorer les services. Ces paires de questions-réponses sont généralement stockées dans une base de données distincte (il ne s'agit pas nécessairement d'une base de données vectorielle) dédiée à l'enregistrement des interactions.

Figure- L'architecture multi-tenant pour une base de connaissances RAG d'entreprise .png

Figure : L'architecture multi-tenant pour une base de connaissances RAG d'entreprise

Le diagramme ci-dessus illustre l'architecture multi-tenant d'un système RAG d'entreprise.

• Les administrateurs système supervisent le système RAG, gèrent l'allocation des ressources, affectent les bases de données, les mettent en correspondance avec les groupes de ressources et garantissent l'évolutivité. Ils s'occupent de l'infrastructure physique, comme le montre le diagramme, où chaque groupe de ressources (par exemple, les groupes de ressources 1, 2 et 3) est associé à des serveurs physiques (nœuds d'interrogation).

• Les locataires (propriétaires et développeurs de bases de données) gèrent la base de connaissances, en la modifiant sur la base des questions-réponses générées par les utilisateurs, comme le montre le diagramme. Différentes bases de données (bases de données X, Y, Z) contiennent des collections dont le contenu de la base de connaissances est différent (collection A, B, etc.).

• Les utilisateurs finaux interagissent avec le système en lecture seule par l'intermédiaire du LLM. Lorsqu'ils interrogent le système, leurs questions sont enregistrées dans la table d'enregistrement des questions et réponses (une base de données distincte), ce qui permet d'alimenter en permanence le système en données précieuses.

Cette conception garantit que chaque couche de processus - de l'interaction avec l'utilisateur à l'administration du système - fonctionne de manière transparente, aidant ainsi l'organisation à construire une base de connaissances solide et en constante amélioration.

Résumé

Dans ce blog, nous avons exploré comment les cadres multi-tenants jouent un rôle essentiel dans l'évolutivité, la sécurité et la performance des bases de connaissances alimentées par RAG. En isolant les données et les ressources pour différents locataires, les entreprises peuvent garantir la confidentialité, la conformité réglementaire et l'optimisation de l'allocation des ressources sur une infrastructure partagée. Milvus, avec ses stratégies flexibles de multi-location, permet aux entreprises de choisir le bon niveau d'isolation des données, du niveau de la base de données au niveau de la partition, en fonction de leurs besoins spécifiques. Le choix d'une approche multi-tenant appropriée garantit que les entreprises peuvent fournir des services sur mesure aux locataires, même lorsqu'elles traitent des données et des charges de travail diverses.

En suivant les meilleures pratiques décrites ici, les entreprises peuvent concevoir et gérer efficacement des systèmes RAG multi-tenant qui non seulement offrent des expériences utilisateur supérieures, mais aussi s'adaptent sans effort à la croissance des besoins de l'entreprise. L'architecture de Milvus garantit que les entreprises peuvent maintenir des niveaux élevés d'isolation, de sécurité et de performance, ce qui en fait un composant essentiel dans la création de bases de connaissances RAG de qualité professionnelle.

Restez à l'écoute pour en savoir plus sur RAG Multi-Tenancy

Dans ce blog, nous avons discuté de la manière dont les stratégies multi-tenant de Milvus sont conçues pour gérer les locataires, mais pas les utilisateurs finaux au sein de ces locataires. Les interactions des utilisateurs finaux se produisent généralement au niveau de la couche d'application, tandis que la base de données vectorielle elle-même ignore l'existence de ces utilisateurs.

Vous vous posez peut-être des questions : Si je souhaite fournir des réponses plus précises en fonction de l'historique des requêtes de chaque utilisateur final, Milvus ne doit-il pas maintenir un contexte de questions-réponses personnalisé pour chaque utilisateur ?

C'est une excellente question, et la réponse dépend vraiment du cas d'utilisation. Par exemple, dans un service de consultation à la demande, les requêtes sont aléatoires et l'accent est mis sur la qualité de la base de connaissances plutôt que sur le suivi du contexte historique de l'utilisateur.

Toutefois, dans d'autres cas, les systèmes RAG doivent tenir compte du contexte. Dans ce cas, Milvus doit collaborer avec la couche d'application pour conserver une mémoire personnalisée du contexte de chaque utilisateur. Cette conception est particulièrement importante pour les applications avec un grand nombre d'utilisateurs finaux, que nous explorerons plus en détail dans mon prochain article. Restez à l'écoute pour en savoir plus !