Concevoir un RAG multi-locataire avec Milvus : bonnes pratiques pour des bases de connaissances d’entreprise évolutives
Introduction
Au cours des deux dernières années, la génération augmentée par récupération (RAG) s’est imposée comme une solution fiable pour les grandes organisations souhaitant améliorer leurs applications alimentées par des LLM, en particulier celles destinées à des utilisateurs diversifiés. À mesure que ces applications se développent, la mise en œuvre d’un cadre multi-tenant devient essentielle. Le multi-tenancy fournit un accès sécurisé et isolé aux données pour différents groupes d’utilisateurs, garantissant 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 vectorielle open source conçue pour gérer des données vectorielles de haute dimension. Il s’agit d’un composant d’infrastructure indispensable de la RAG, qui stocke et récupère des informations contextuelles pour les LLM à partir de sources externes. Milvus propose des stratégies de multi-tenancy flexibles pour divers besoins, notamment le multi-tenancy au niveau de la base de données, au niveau de la collection et au niveau de la partition.
Dans cet article, nous aborderons :
Qu’est-ce que le multi-tenancy et pourquoi est-il important
Stratégies de multi-tenancy dans Milvus
Exemple : stratégie de multi-tenancy pour une base de connaissances d’entreprise alimentée par la RAG
Qu’est-ce que le multi-tenancy et pourquoi est-il important
Le multi-tenancy est une architecture dans laquelle plusieurs clients ou équipes, appelés « tenants, » partagent une seule instance d’une application ou d’un système. Les données et les configurations de chaque tenant sont logiquement isolées, garantissant la confidentialité et la sécurité, tandis que tous les tenants 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 tenant.
Le tenant A est un organisme de santé qui stocke des FAQ destinées aux patients et des documents de conformité.
Le tenant B est une entreprise technologique qui gère des workflows internes de dépannage informatique.
Le tenant C est une entreprise de vente au détail disposant de FAQ de service client pour les retours de produits.
Chaque tenant fonctionne dans un environnement totalement isolé, garantissant qu’aucune donnée du tenant A ne fuite vers le système du tenant B, ni inversement. De plus, l’allocation des ressources, les performances des requêtes et les décisions de mise à l’échelle sont propres à chaque tenant, garantissant des performances élevées indépendamment des pics de charge de travail chez un tenant.
Le multi-tenancy fonctionne également pour les systèmes desservant différentes équipes au sein d’une même organisation. Imaginez une grande entreprise utilisant une base de connaissances alimentée par la RAG pour servir ses départements internes, tels que les RH, le juridique et le marketing. Dans cette configuration, chaque département est un tenant avec des données et des ressources isolées.
Le multi-tenancy offre des avantages significatifs, notamment l’efficacité des coûts, la scalabilité et une sécurité robuste des données. En partageant une infrastructure unique, les fournisseurs de services peuvent réduire les frais généraux et assurer une consommation des ressources plus efficace. Cette approche se met également à l’échelle sans effort : l’intégration de nouveaux tenants nécessite beaucoup moins de ressources que la création d’instances distinctes pour chacun d’eux, comme dans les modèles à tenant unique. Il est important de noter que le multi-tenancy maintient une sécurité robuste des données en garantissant une isolation stricte des données pour chaque tenant, avec des contrôles d’accès et le chiffrement protégeant les informations sensibles contre tout accès non autorisé. En outre, les mises à jour, correctifs et nouvelles fonctionnalités peuvent être déployés simultanément pour tous les tenants, simplifiant la maintenance du système et réduisant la charge pesant sur les administrateurs, tout en garantissant que les normes de sécurité et de conformité sont systématiquement respectées.
Stratégies de multi-tenancy dans Milvus
Pour comprendre comment Milvus prend en charge le multi-tenancy, il est important d’examiner d’abord la manière dont il organise les données des utilisateurs.
Comment Milvus organise les données des utilisateurs
Milvus structure les données sur trois couches, en allant du plus général au 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 : Elle agit comme un conteneur logique, similaire à une base de données dans les systèmes relationnels traditionnels.
Collection : Comparable à une table au sein d’une base de données, une collection organise les données en groupes gérables.
Partition/Clé de partition : Au sein d’une collection, les données peuvent être davantage segmentées par Partitions. En utilisant une Clé de partition, les données ayant la même clé sont regroupées. Par exemple, si vous utilisez un ID utilisateur comme Clé de partition, toutes les données d’un utilisateur spécifique seront stockées dans le même segment logique. Cela permet de récupérer facilement les données liées à des utilisateurs individuels.
À mesure que vous passez de Base de données à Collection puis à Clé de partition, la granularité de l’organisation des données devient progressivement plus fine.
Pour garantir une sécurité des données renforcée et un contrôle d’accès approprié, Milvus fournit également un robuste contrôle d’accès basé sur les rôles (RBAC), permettant 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 pour mettre en œuvre la multi-tenance, offrant une flexibilité selon 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-tenance 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 fournit une forte isolation des données et garantit des performances de recherche optimales. Cependant, elle peut entraîner une utilisation inefficace des ressources si certains locataires restent inactifs.
Multi-tenance au niveau de la collection
Ici, dans la multi-tenance au niveau de la collection, nous pouvons organiser les données des locataires de deux façons.
Une collection pour tous les locataires : Tous les locataires partagent une seule collection, avec des champs propres à chaque locataire utilisés pour le filtrage. Bien que simple à mettre en œuvre, cette approche peut rencontrer des goulots d’étranglement en matière de performances à mesure que le nombre de locataires augmente.
Une collection par locataire : Chaque locataire peut disposer d’une collection dédiée, améliorant l’isolation et les performances, mais nécessitant davantage de ressources. Cette configuration peut rencontrer des limites d’évolutivité si le nombre de locataires dépasse la capacité de collections de Milvus.
Multi-tenance au niveau de la partition
La multi-tenance au niveau de la partition se concentre sur l’organisation des locataires au sein d’une seule collection. 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 séparées. Nous pouvons isoler les données en attribuant à chaque locataire une partition dédiée, équilibrant isolation et performances de recherche. Cependant, cette approche est limitée par la limite maximale de partitions de Milvus.
Multi-tenance basée sur la clé de partition : Il s’agit d’une option plus évolutive dans laquelle une seule collection utilise des clés de partition pour distinguer les locataires. Cette méthode simplifie la gestion des ressources et prend en charge 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 principales approches de multi-tenance.
| Granularité | Niveau base de données | Niveau collection | Niveau clé de partition |
|---|---|---|---|
| Nombre maximal de tenants 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 | Forte | Moyenne | Forte |
Exemple : stratégie de multi-tenance pour une base de connaissances d’entreprise alimentée par RAG
Lors de la conception de la stratégie de multi-tenance pour un système RAG, il est essentiel d’aligner votre approche sur les besoins spécifiques de votre entreprise et de vos tenants. Milvus propose diverses stratégies de multi-tenance, et le choix de la bonne dépend du nombre de tenants, de leurs exigences et du niveau d’isolation des données nécessaire. Voici un guide pratique pour prendre ces décisions, en prenant comme exemple une base de connaissances d’entreprise alimentée par RAG.
Comprendre la structure des tenants avant de choisir une stratégie de multi-tenance
Une base de connaissances d’entreprise alimentée par RAG dessert souvent un petit nombre de tenants. Ces tenants sont généralement des unités opérationnelles indépendantes comme l’IT, les ventes, le juridique et le marketing, chacune nécessitant des services de base de connaissances distincts. Par exemple, le département RH gère des informations sensibles sur les employés, comme les guides d’intégration et les politiques d’avantages sociaux, qui doivent rester confidentielles et accessibles uniquement au personnel RH.
Dans ce cas, chaque unité opérationnelle doit être traitée comme un tenant distinct, et une stratégie de multi-tenance au niveau base de données est souvent la plus adaptée. En attribuant des bases de données dédiées à chaque tenant, les organisations peuvent obtenir une forte isolation logique, simplifiant la gestion et renforçant la sécurité. Cette configuration offre aux tenants une flexibilité importante : 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 des ressources physiques
Dans les situations où la sécurité des données est fortement priorisée, l’isolation logique au niveau de la base de données peut ne pas suffire. Par exemple, certaines unités opérationnelles peuvent traiter des données critiques ou hautement sensibles, nécessitant des garanties plus fortes contre les interférences d’autres tenants. Dans ce cas, nous pouvons mettre en œuvre une approche d’isolation physique par-dessus une structure de multi-tenance au niveau base de données.
Milvus nous permet de mapper des composants logiques, tels que les bases de données et les collections, à des ressources physiques. Cette méthode garantit que les activités des autres locataires n’impactent pas les opérations critiques. Voyons comment cette approche fonctionne en pratique.
Figure- How Milvus manages physical resources.png
Figure : Comment Milvus gère les ressources physiques
Comme le montre le diagramme ci-dessus, il existe trois couches de gestion des ressources dans Milvus : Query Node, Resource Group et Database.
Query Node : 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).
Resource Group : Un ensemble de Query Nodes qui sert de passerelle 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 Resource Group.
Dans l’exemple présenté dans le diagramme ci-dessus, il existe trois Databases logiques : X, Y et Z.
Database X : Contient Collection A.
Database Y : Contient Collections B et C.
Database Z : Contient Collections D et E.
Supposons que Database X contienne une base de connaissances critique que nous ne voulons pas voir affectée par la charge provenant de Database Y ou de Database Z. Pour garantir l’isolation des données :
Database X se voit attribuer son propre Resource Group afin de garantir que sa base de connaissances critique ne soit pas affectée par les charges de travail provenant d’autres bases de données.
Collection E est également allouée à un Resource Group distinct au sein de sa base de données parente (Z). Cela fournit une isolation au niveau de la collection pour des données critiques spécifiques au sein d’une base de données partagée.
Pendant ce temps, les collections restantes dans Databases Y et Z partagent les ressources physiques de Resource Group 2.
En mappant soigneusement les composants logiques aux ressources physiques, les organisations peuvent obtenir une architecture multi-locataire flexible, évolutive et sécurisée, adaptée à leurs besoins métier spécifiques.
Concevoir un accès au niveau de l’utilisateur final
Maintenant que nous avons appris les bonnes pratiques pour choisir une stratégie multi-locataire pour un RAG d’entreprise, voyons comment concevoir un accès au niveau 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 via des LLM. Cependant, les organisations doivent toujours suivre ces données de questions-réponses générées par les utilisateurs et les associer à 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 comptoir de consultation intelligent d’un hôpital. Les patients peuvent poser des questions comme : « Y a-t-il des rendez-vous disponibles avec le spécialiste aujourd’hui ? » ou « Une préparation spécifique est-elle 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 n’est pas nécessaire que ce soit une base de données vectorielle) dédiée à la journalisation des interactions.
Figure- The multi-tenancy architecture for an enterprise RAG knowledge base .png
Figure : L’architecture multi-locataire d’une base de connaissances RAG d’entreprise
Le diagramme ci-dessus montre l’architecture multi-locataire d’un système RAG d’entreprise.
System Administrators supervisent le système RAG, gèrent l’allocation des ressources, attribuent les bases de données, les mappent à des groupes de ressources et garantissent l’évolutivité. Ils gèrent l’infrastructure physique, comme le montre le diagramme, où chaque groupe de ressources (par exemple, Resource Group 1, 2 et 3) est mappé à des serveurs physiques (query nodes).
Locataires (propriétaires de bases de données et développeurs) gèrent la base de connaissances, en l’itérant sur la base des données de Q/R générées par les utilisateurs, comme le montre le diagramme. Différentes bases de données (Base de données X, Y, Z) contiennent des collections avec différents contenus de base de connaissances (Collection A, B, etc.).
Utilisateurs finaux interagissent avec le système en lecture seule via le LLM. Lorsqu’ils interrogent le système, leurs questions sont enregistrées dans la table d’enregistrement Q/R séparée (une base de données distincte), réinjectant en continu des données précieuses dans le système.
Cette conception garantit que chaque couche de processus — de l’interaction utilisateur à l’administration du système — fonctionne de manière fluide, aidant l’organisation à construire une base de connaissances robuste et en amélioration continue.
Résumé
Dans ce blog, nous avons exploré comment les cadres de multi-location jouent un rôle essentiel dans la scalabilité, la sécurité et les performances 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 une allocation optimisée 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 base de données au niveau partition — en fonction de leurs besoins spécifiques. Choisir la bonne approche de multi-location garantit que les entreprises peuvent fournir des services adaptés 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 organisations peuvent concevoir et gérer efficacement des systèmes RAG multi-locataires qui offrent non seulement des expériences utilisateur supérieures, mais évoluent également sans effort à mesure que les besoins de l’entreprise augmentent. 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 pour construire des bases de connaissances de niveau entreprise alimentées par RAG.
Restez à l’écoute pour plus d’informations sur le RAG multi-locataires
Dans ce blog, nous avons expliqué comment les stratégies de multi-location 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 applicative, tandis que la base de données vectorielle elle-même reste inconsciente de ces utilisateurs.
Vous vous demandez peut-être : Si je veux fournir des réponses plus précises en fonction de l’historique des requêtes de chaque utilisateur final, Milvus n’a-t-il pas besoin de maintenir un contexte de Q/R 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 principal porte sur la qualité de la base de connaissances plutôt que sur le suivi du contexte historique d’un utilisateur.
Cependant, dans d’autres cas, les systèmes RAG doivent être conscients du contexte. Lorsque cela est nécessaire, Milvus doit collaborer avec la couche applicative pour maintenir une mémoire personnalisée du contexte de chaque utilisateur. Cette conception est particulièrement importante pour les applications comptant un très grand nombre d’utilisateurs finaux, que nous explorerons plus en détail dans mon prochain article. Restez à l’écoute pour plus d’informations !
Continuer à lire
Why Teams Are Migrating from Weaviate to Zilliz Cloud — and How to Do It Seamlessly
Explore how Milvus scales for large datasets and complex queries with advanced features, and discover how to migrate from Weaviate to Zilliz Cloud.
AI Agents Are Quietly Transforming E-Commerce — Here’s How
Discover how AI agents transform e-commerce with autonomous decision-making, enhanced product discovery, and vector search capabilities for today's retailers.
VidTok: Rethinking Video Processing with Compact Tokenization
VidTok tokenizes videos to reduce redundancy while preserving spatial and temporal details for efficient processing.