Progettare RAG multi-tenant con Milvus: best practice per basi di conoscenza aziendali scalabili
Introduzione
Negli ultimi due anni, la Retrieval-Augmented Generation (RAG) è emersa come una soluzione affidabile per le grandi organizzazioni per migliorare le loro applicazioni basate su LLM, specialmente quelle con utenti diversificati. Man mano che tali applicazioni crescono, l’implementazione di un framework multi-tenant diventa essenziale. La multi-tenancy fornisce un accesso sicuro e isolato ai dati per diversi gruppi di utenti, garantendo la fiducia degli utenti, soddisfacendo gli standard normativi e migliorando l’efficienza operativa.
Milvus è un database vettoriale open-source progettato per gestire dati vettoriali ad alta dimensionalità. È un componente infrastrutturale indispensabile della RAG, che archivia e recupera informazioni contestuali per gli LLM da fonti esterne. Milvus offre strategie flessibili di multi-tenancy per varie esigenze, inclusa la multi-tenancy a livello di database, a livello di collection e a livello di partition.
In questo post, tratteremo:
Cos’è la Multi-Tenancy e perché è importante
Strategie di Multi-Tenancy in Milvus
Esempio: strategia di Multi-Tenancy per una base di conoscenza aziendale basata su RAG
Cos’è la Multi-Tenancy e perché è importante
La multi-tenancy è un’architettura in cui più clienti o team, noti come "tenant," condividono una singola istanza di un’applicazione o di un sistema. I dati e le configurazioni di ciascun tenant sono logicamente isolati, garantendo privacy e sicurezza, mentre tutti i tenant condividono la stessa infrastruttura sottostante.
Immagina una piattaforma SaaS che fornisce soluzioni basate sulla conoscenza a più aziende. Ogni azienda è un tenant.
Il Tenant A è un’organizzazione sanitaria che archivia FAQ rivolte ai pazienti e documenti di conformità.
Il Tenant B è un’azienda tecnologica che gestisce flussi di lavoro interni per la risoluzione dei problemi IT.
Il Tenant C è un’attività retail con FAQ del servizio clienti per i resi dei prodotti.
Ogni tenant opera in un ambiente completamente isolato, garantendo che nessun dato del Tenant A trapeli nel sistema del Tenant B o viceversa. Inoltre, l’allocazione delle risorse, le prestazioni delle query e le decisioni di scalabilità sono specifiche per tenant, garantendo prestazioni elevate indipendentemente dai picchi di carico di lavoro in un tenant.
La multi-tenancy funziona anche per sistemi che servono diversi team all’interno della stessa organizzazione. Immagina una grande azienda che utilizza una base di conoscenza basata su RAG per servire i propri dipartimenti interni, come HR, Legale e Marketing. Ogni dipartimento è un tenant con dati e risorse isolati in questa configurazione.
La multi-tenancy offre vantaggi significativi, tra cui efficienza dei costi, scalabilità e robusta sicurezza dei dati. Condividendo una singola infrastruttura, i fornitori di servizi possono ridurre i costi generali e garantire un consumo delle risorse più efficace. Questo approccio scala anche senza sforzo: l’onboarding di nuovi tenant richiede molte meno risorse rispetto alla creazione di istanze separate per ciascuno, come nei modelli single-tenant. È importante sottolineare che la multi-tenancy mantiene una robusta sicurezza dei dati garantendo un rigoroso isolamento dei dati per ciascun tenant, con controlli di accesso e crittografia che proteggono le informazioni sensibili da accessi non autorizzati. Inoltre, aggiornamenti, patch e nuove funzionalità possono essere distribuiti simultaneamente a tutti i tenant, semplificando la manutenzione del sistema e riducendo il carico sugli amministratori, garantendo al contempo che gli standard di sicurezza e conformità siano costantemente rispettati.
Strategie di Multi-Tenancy in Milvus
Per capire come Milvus supporta la multi-tenancy, è importante innanzitutto esaminare come organizza i dati degli utenti.
Come Milvus organizza i dati degli utenti
Milvus struttura i dati su tre livelli, passando dal generale al granulare: Database, Collection e Partition/Partition Key.
Figura- Come Milvus organizza i dati degli utenti .png
Figura: Come Milvus organizza i dati degli utenti
Database: Funziona come un contenitore logico, simile a un database nei tradizionali sistemi relazionali.
Collection: Paragonabile a una tabella all'interno di un database, una collection organizza i dati in gruppi gestibili.
Partition/Partition Key: All'interno di una collection, i dati possono essere ulteriormente segmentati tramite Partition. Utilizzando una Partition Key, i dati con la stessa chiave vengono raggruppati insieme. Ad esempio, se usi un ID utente come Partition Key, tutti i dati di uno specifico utente verranno archiviati nello stesso segmento logico. Questo rende semplice recuperare i dati associati ai singoli utenti.
Man mano che si passa da Database a Collection a Partition Key, la granularità dell'organizzazione dei dati diventa progressivamente più fine.
Per garantire una maggiore sicurezza dei dati e un adeguato controllo degli accessi, Milvus fornisce anche un solido Role-Based Access Control (RBAC), consentendo agli amministratori di definire autorizzazioni specifiche per ciascun utente. Solo gli utenti autorizzati possono accedere a determinati dati.
Milvus supporta multiple strategie per implementare la multi-tenancy, offrendo flessibilità in base alle esigenze della tua applicazione: multi-tenancy a livello di database, a livello di collection e a livello di partition.
Multi-Tenancy a livello di database
Con l'approccio di multi-tenancy a livello di database, a ogni tenant viene assegnato il proprio database all'interno dello stesso cluster Milvus. Questa strategia offre un forte isolamento dei dati e garantisce prestazioni di ricerca ottimali. Tuttavia, può portare a un utilizzo inefficiente delle risorse se alcuni tenant rimangono inattivi.
Multi-Tenancy a livello di collection
Qui, nella multi-tenancy a livello di collection, possiamo organizzare i dati dei tenant in due modi.
Una collection per tutti i tenant: Tutti i tenant condividono un'unica collection, con campi specifici del tenant utilizzati per il filtraggio. Sebbene semplice da implementare, questo approccio può incontrare colli di bottiglia prestazionali man mano che il numero di tenant aumenta.
Una collection per tenant: Ogni tenant può avere una collection dedicata, migliorando isolamento e prestazioni ma richiedendo più risorse. Questa configurazione può incontrare limiti di scalabilità se il numero di tenant supera la capacità di collection di Milvus.
Multi-Tenancy a livello di partition
La multi-tenancy a livello di partition si concentra sull'organizzazione dei tenant all'interno di una singola collection. Anche qui abbiamo due modi per organizzare i dati dei tenant.
Una partition per tenant: I tenant condividono una collection, ma i loro dati vengono archiviati in partition separate. Possiamo isolare i dati assegnando a ciascun tenant una partition dedicata, bilanciando isolamento e prestazioni di ricerca. Tuttavia, questo approccio è vincolato dal limite massimo di partition di Milvus.
Multi-Tenancy basata su partition key: Questa è un'opzione più scalabile in cui una singola collection utilizza partition key per distinguere i tenant. Questo metodo semplifica la gestione delle risorse e supporta una maggiore scalabilità, ma non supporta inserimenti massivi di dati.
La tabella seguente riassume le principali differenze tra i principali approcci di multi-tenancy.
| Granularità | Livello database | Livello collection | Livello chiave di partizione |
|---|---|---|---|
| Tenant massimi supportati | ~1.000 | ~10.000 | ~10.000.000 |
| Flessibilità di organizzazione dei dati | Alta: gli utenti possono definire più collection con schemi personalizzati. | Media: gli utenti sono limitati a una sola collection con uno schema personalizzato. | Bassa: tutti gli utenti condividono una collection, richiedendo uno schema coerente. |
| Costo per utente | Alto | Medio | Basso |
| Isolamento delle risorse fisiche | Sì | Sì | No |
| RBAC | Sì | Sì | No |
| Prestazioni di ricerca | Elevate | Medie | Elevate |
Esempio: strategia multi-tenancy per una knowledge base aziendale basata su RAG
Quando si progetta la strategia multi-tenancy per un sistema RAG, è essenziale allineare l'approccio alle esigenze specifiche della propria azienda e dei propri tenant. Milvus offre varie strategie multi-tenancy e la scelta di quella giusta dipende dal numero di tenant, dai loro requisiti e dal livello di isolamento dei dati necessario. Ecco una guida pratica per prendere queste decisioni, prendendo come esempio una knowledge base aziendale basata su RAG.
Comprendere la struttura dei tenant prima di scegliere una strategia multi-tenancy
Una knowledge base aziendale basata su RAG serve spesso un numero ridotto di tenant. Questi tenant sono solitamente unità di business indipendenti come IT, Vendite, Legale e Marketing, ciascuna delle quali richiede servizi di knowledge base distinti. Ad esempio, il Dipartimento HR gestisce informazioni sensibili sui dipendenti, come guide di onboarding e policy sui benefit, che dovrebbero essere riservate e accessibili solo al personale HR.
In questo caso, ogni unità di business dovrebbe essere trattata come un tenant separato e una strategia multi-tenancy a livello database è spesso la più adatta. Assegnando database dedicati a ciascun tenant, le organizzazioni possono ottenere un forte isolamento logico, semplificando la gestione e migliorando la sicurezza. Questa configurazione offre ai tenant una flessibilità significativa: possono definire modelli di dati personalizzati all'interno delle collection, creare tutte le collection necessarie e gestire in modo indipendente il controllo degli accessi per le proprie collection.
Migliorare la sicurezza con l'isolamento delle risorse fisiche
In situazioni in cui la sicurezza dei dati è una priorità elevata, l'isolamento logico a livello di database potrebbe non essere sufficiente. Ad esempio, alcune unità di business potrebbero gestire dati critici o altamente sensibili, richiedendo garanzie più forti contro interferenze da parte di altri tenant. In questi casi, possiamo implementare un approccio di isolamento fisico sopra una struttura multi-tenancy a livello database.
Milvus ci consente di mappare componenti logici, come database e collection, a risorse fisiche. Questo metodo garantisce che le attività di altri tenant non influiscano sulle operazioni critiche. Esploriamo come funziona questo approccio nella pratica.
Figure- How Milvus manages physical resources.png
Figura: Come Milvus gestisce le risorse fisiche
Come mostrato nel diagramma sopra, in Milvus ci sono tre livelli di gestione delle risorse: Query Node, Resource Group e Database.
Query Node: Il componente che elabora le attività di query. Viene eseguito su una macchina fisica o su un container (ad esempio, un pod in Kubernetes).
Resource Group: Una raccolta di Query Node che funge da ponte tra componenti logici (database e collection) e risorse fisiche. Puoi allocare uno o più database o collection a un singolo Resource Group.
Nell’esempio mostrato nel diagramma sopra, ci sono tre Database logici: X, Y e Z.
Database X: Contiene Collection A.
Database Y: Contiene Collections B e C.
Database Z: Contiene Collections D ed E.
Supponiamo che Database X contenga una knowledge base critica che non vogliamo sia influenzata dal carico di Database Y o Database Z. Per garantire l’isolamento dei dati:
Database X viene assegnato al proprio Resource Group per garantire che la sua knowledge base critica non sia influenzata dai carichi di lavoro di altri database.
Collection E viene inoltre allocata a un Resource Group separato all’interno del suo database padre (Z). Ciò fornisce isolamento a livello di collection per dati critici specifici all’interno di un database condiviso.
Nel frattempo, le collection rimanenti in Databases Y e Z condividono le risorse fisiche di Resource Group 2.
Mappando attentamente i componenti logici alle risorse fisiche, le organizzazioni possono ottenere un’architettura multi-tenancy flessibile, scalabile e sicura, adattata alle loro specifiche esigenze aziendali.
Progettare l’accesso a livello di utente finale
Ora che abbiamo appreso le best practice per scegliere una strategia multi-tenancy per un RAG aziendale, esploriamo come progettare l’accesso a livello utente in tali sistemi.
In questi sistemi, gli utenti finali di solito interagiscono con la knowledge base in modalità di sola lettura tramite LLM. Tuttavia, le organizzazioni devono comunque tracciare tali dati di domande e risposte generati dagli utenti e collegarli a utenti specifici per vari scopi, come migliorare l’accuratezza della knowledge base o offrire servizi personalizzati.
Prendiamo come esempio lo sportello di consulenza intelligente di un ospedale. I pazienti potrebbero porre domande come: “Ci sono appuntamenti disponibili con lo specialista oggi?” oppure "È necessaria una preparazione specifica per il mio prossimo intervento chirurgico?" Sebbene queste domande non influiscano direttamente sulla knowledge base, è importante per l’ospedale tracciare tali interazioni per migliorare i servizi. Queste coppie di domande e risposte vengono solitamente archiviate in un database separato (non deve necessariamente essere un database vettoriale) dedicato alla registrazione delle interazioni.
Figure- The multi-tenancy architecture for an enterprise RAG knowledge base .png
Figura: L’architettura multi-tenancy per una knowledge base RAG aziendale
Il diagramma sopra mostra l’architettura multi-tenancy di un sistema RAG aziendale.
System Administrators supervisionano il sistema RAG, gestiscono l’allocazione delle risorse, assegnano i database, li mappano ai resource group e garantiscono la scalabilità. Gestiscono l’infrastruttura fisica, come mostrato nel diagramma, dove ogni resource group (ad esempio, Resource Group 1, 2 e 3) è mappato a server fisici (query node).
Tenant (proprietari e sviluppatori di database) gestiscono la knowledge base, iterando su di essa in base ai dati Q&A generati dagli utenti, come mostrato nel diagramma. Database diversi (Database X, Y, Z) contengono raccolte con contenuti di knowledge base diversi (Collection A, B, ecc.).
Utenti finali interagiscono con il sistema in modalità di sola lettura tramite l’LLM. Man mano che interrogano il sistema, le loro domande vengono registrate nella tabella separata dei record Q&A (un database separato), continuando ad alimentare il sistema con dati preziosi.
Questo design garantisce che ogni livello di processo, dall’interazione con l’utente all’amministrazione del sistema, funzioni senza soluzione di continuità, aiutando l’organizzazione a costruire una knowledge base solida e in continuo miglioramento.
Riepilogo
In questo blog, abbiamo esplorato come i framework di multi-tenancy svolgano un ruolo critico nella scalabilità, sicurezza e performance delle knowledge base basate su RAG. Isolando dati e risorse per tenant diversi, le aziende possono garantire privacy, conformità normativa e allocazione ottimizzata delle risorse su un’infrastruttura condivisa. Milvus, con le sue strategie flessibili di multi-tenancy, consente alle aziende di scegliere il giusto livello di isolamento dei dati, dal livello database al livello partizione, a seconda delle loro esigenze specifiche. Scegliere il giusto approccio alla multi-tenancy assicura che le aziende possano fornire servizi su misura ai tenant, anche quando gestiscono dati e carichi di lavoro diversi.
Seguendo le best practice delineate qui, le organizzazioni possono progettare e gestire efficacemente sistemi RAG multi-tenant che non solo offrono esperienze utente superiori, ma scalano anche senza sforzo con la crescita delle esigenze aziendali. L’architettura di Milvus garantisce che le imprese possano mantenere elevati livelli di isolamento, sicurezza e performance, rendendolo un componente cruciale nella creazione di knowledge base di livello enterprise basate su RAG.
Restate sintonizzati per ulteriori approfondimenti sul RAG multi-tenant
In questo blog, abbiamo discusso di come le strategie di multi-tenancy di Milvus siano progettate per gestire i tenant, ma non gli utenti finali all’interno di tali tenant. Le interazioni degli utenti finali avvengono solitamente a livello applicativo, mentre il database vettoriale stesso rimane inconsapevole di tali utenti.
Potreste chiedervi: Se voglio fornire risposte più precise in base alla cronologia delle query di ciascun utente finale, Milvus non deve mantenere un contesto Q&A personalizzato per ciascun utente?
È un’ottima domanda, e la risposta dipende davvero dal caso d’uso. Ad esempio, in un servizio di consulenza on-demand, le query sono casuali e l’attenzione principale è rivolta alla qualità della knowledge base piuttosto che al mantenimento del contesto storico di un utente.
Tuttavia, in altri casi, i sistemi RAG devono essere consapevoli del contesto. Quando ciò è necessario, Milvus deve collaborare con il livello applicativo per mantenere una memoria personalizzata del contesto di ciascun utente. Questo design è particolarmente importante per le applicazioni con un numero massiccio di utenti finali, che esploreremo più in dettaglio nel mio prossimo post. Restate sintonizzati per ulteriori approfondimenti!
Continua a leggere
Zilliz Cloud Just Landed in Claude Code
The Zilliz Cloud Plugin brings the full power of Zilliz Cloud directly into your Claude Code terminal as natural-language conversations.
How Zilliz Saw the Future of Vector Databases—and Built for Production
An inside look at how Zilliz built vector databases for real-world use, focusing on scalability, stability, and running them reliably at scale.
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.