Progettazione di RAG multi-tenancy con Milvus: le migliori pratiche 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, soprattutto quelle con utenti diversi. Con la crescita di tali applicazioni, l'implementazione di un framework multi-tenancy diventa essenziale. La multi-tenancy fornisce un accesso sicuro e isolato ai dati per diversi gruppi di utenti, garantendo la fiducia degli utenti, il rispetto degli standard normativi e il miglioramento dell'efficienza operativa.

Milvus è un database vettoriale open-source costruito per gestire dati vettoriali ad alta dimensione. È un componente indispensabile dell'infrastruttura di RAG, che memorizza e recupera informazioni contestuali per gli LLM da fonti esterne. Milvus offre strategie flessibili di multi-tenancy per varie esigenze, tra cui multi-tenancy a livello di database, di collezione e di partizione.

In questo post tratteremo di:

• Cos'è la multi-tenancy e perché è importante

• Strategie di multi-tenancy in Milvus

• Esempio: Strategia di multi-tenancy per una Knowledge Base aziendale alimentata da RAG

Cos'è la multi-tenancy e perché è importante

Lamulti-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.

Immaginate una piattaforma SaaS che fornisce soluzioni basate sulla conoscenza a più aziende. Ogni azienda è un tenant.

• L'inquilino A è un'organizzazione sanitaria che archivia FAQ rivolte ai pazienti e documenti di conformità.

• L'inquilino B è un'azienda tecnologica che gestisce i flussi di lavoro interni per la risoluzione dei problemi IT.

• L'inquilino C è un'azienda di vendita al dettaglio con FAQ per il servizio clienti per la restituzione 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 scaling sono specifiche per ogni tenant, garantendo prestazioni elevate indipendentemente dai picchi di carico di lavoro di un tenant.

La multi-tenancy funziona anche per i sistemi che servono team diversi all'interno della stessa organizzazione. Immaginate una grande azienda che utilizza una base di conoscenza alimentata da RAG per servire i suoi dipartimenti interni, come HR, Legal e Marketing. In questa configurazione, ogni reparto è un tenant con dati e risorse isolate.

La multi-tenancy offre vantaggi significativi, tra cui l'efficienza dei costi, la scalabilità e la sicurezza dei dati. Condividendo un'unica infrastruttura, i fornitori di servizi possono ridurre i costi generali e garantire un consumo più efficace delle risorse. Inoltre, questo approccio è facilmente scalabile: l'inserimento di nuovi locatari richiede molte meno risorse rispetto alla creazione di istanze separate per ciascuno di essi, come avviene nei modelli single-tenancy. Inoltre, la multi-tenancy garantisce una solida sicurezza dei dati, assicurando un rigoroso isolamento dei dati per ciascun tenant, con controlli di accesso e crittografia che proteggono le informazioni sensibili da accessi non autorizzati. Inoltre, gli aggiornamenti, le patch e le nuove funzionalità possono essere distribuite simultaneamente su tutti i tenant, semplificando la manutenzione del sistema e riducendo l'onere per gli amministratori, garantendo al contempo il rispetto costante degli standard di sicurezza e conformità.

Strategie Multi-Tenancy in Milvus

Per capire come Milvus supporta la multi-tenancy, è importante prima vedere come organizza i dati degli utenti.

Come Milvus organizza i dati degli utenti

Milvus struttura i dati su tre livelli, da ampio a granulare: Database, Raccolta e Partizione/Chiave di partizione.

Figura - Come Milvus organizza i dati degli utenti .png

Figura: Come Milvus organizza i dati degli utenti

• Database: Funge da contenitore logico, simile a un database nei sistemi relazionali tradizionali.

• Raccolta: Paragonabile a una tabella di un database, una raccolta organizza i dati in gruppi gestibili.

• Partizione/chiave di partizione: All'interno di una raccolta, i dati possono essere ulteriormente segmentati da partizioni. Utilizzando una chiave di partizione, i dati con la stessa chiave vengono raggruppati insieme. Ad esempio, se si utilizza un ID utente come chiave di partizione, tutti i dati di un utente specifico saranno archiviati nello stesso segmento logico. In questo modo è facile recuperare i dati legati ai singoli utenti.

Passando da Database a Raccolta a Chiave di partizione, la granularità dell'organizzazione dei dati diventa progressivamente più fine.

Per garantire una maggiore sicurezza dei dati e un adeguato controllo degli accessi, Milvus offre anche un solido controllo degli accessi basato sui ruoli (RBAC), che consente agli amministratori di definire autorizzazioni specifiche per ogni utente. Solo gli utenti autorizzati possono accedere a determinati dati.

Milvus supporta diverse strategie per l'implementazione della multi-tenancy, offrendo flessibilità in base alle esigenze della vostra applicazione: multi-tenancy a livello di database, a livello di collezione e a livello di partizione.

Multi-tenancy a livello di database

Con l'approccio 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 collezione

In questo caso, con la multi-tenancy a livello di collezione, possiamo organizzare i dati per i tenant in due modi.

• Una collezione per tutti i tenant: Tutti gli affittuari condividono un'unica collezione, con campi specifici per gli affittuari usati per il filtraggio. Sebbene sia semplice da implementare, questo approccio può incontrare dei colli di bottiglia nelle prestazioni all'aumentare del numero di inquilini.

• Una raccolta per tenant: Ogni tenant può avere una raccolta dedicata, migliorando l'isolamento e le prestazioni, ma richiedendo più risorse. Questa configurazione può incontrare limiti di scalabilità se il numero di tenant supera la capacità di raccolta di Milvus.

Multi-tenancy a livello di partizione

Il Partition-Level Multi-Tenancy si concentra sull'organizzazione dei tenant all'interno di una singola collezione. Anche in questo caso esistono due modi per organizzare i dati dei tenant.

• Una partizione per inquilino: I tenant condividono una collezione, ma i loro dati sono archiviati in partizioni separate. È possibile isolare i dati assegnando a ogni tenant una partizione dedicata, bilanciando isolamento e prestazioni di ricerca. Tuttavia, questo approccio è limitato dal limite massimo di partizioni di Milvus.

• Multi-tenancy basato su chiavi di partizione: Si tratta di un'opzione più scalabile in cui una singola collezione utilizza chiavi di partizione per distinguere i tenant. Questo metodo semplifica la gestione delle risorse e supporta una maggiore scalabilità, ma non supporta gli inserimenti di dati in massa.

La tabella seguente riassume le differenze principali tra i principali approcci multi-tenancy.

Granularità	A livello di database	Livello di raccolta	Livello chiave di partizione
Inquilini massimi supportati	~1,000	~10,000	~10,000,000
Flessibilità dell'organizzazione dei dati	Alta: gli utenti possono definire collezioni multiple con schemi personalizzati.	Media: Gli utenti sono limitati a una sola raccolta con uno schema personalizzato.	Bassa: tutti gli utenti condividono una raccolta, che richiede uno schema coerente.
Costo per utente	Alto	medio	Basso
Isolamento fisico delle risorse	Sì	Sì	No
RBAC	Sì	Sì	No
Prestazioni di ricerca	Forte	Medio	Forte

Esempio: Strategia multi-tenancy per una Knowledge Base aziendale alimentata da RAG

Quando si progetta la strategia multi-tenancy per un sistema RAG, è essenziale allineare l'approccio alle esigenze specifiche dell'azienda e dei tenant. Milvus offre diverse 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 alimentata da RAG.

Capire la struttura dei tenant prima di scegliere una strategia multi-tenancy

Una knowledge base aziendale alimentata da RAG spesso serve un numero ridotto di tenant. Questi tenant sono di solito unità aziendali indipendenti come IT, Vendite, Legale e Marketing, ognuna delle quali richiede servizi di knowledge base distinti. Ad esempio, il reparto Risorse Umane gestisce informazioni sensibili sui dipendenti, come le guide all'ingresso e le politiche di benefit, che devono essere riservate e accessibili solo al personale delle Risorse Umane.

In questo caso, ogni unità aziendale deve essere trattata come un tenant separato e una strategia multi-tenancy a livello di 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 notevole flessibilità: possono definire modelli di dati personalizzati all'interno delle collezioni, creare tutte le collezioni necessarie e gestire in modo indipendente il controllo degli accessi alle proprie collezioni.

Migliorare la sicurezza con l'isolamento fisico delle risorse

In situazioni in cui la sicurezza dei dati è altamente prioritaria, l'isolamento logico a livello di database potrebbe non essere sufficiente. Ad esempio, alcune unità aziendali potrebbero gestire dati critici o altamente sensibili, richiedendo maggiori garanzie contro le interferenze di altri tenant. In questi casi, possiamo implementare un approccio di isolamento fisico in cima a una struttura multi-tenancy a livello di database.

Milvus ci permette di mappare componenti logici, come database e collezioni, su risorse fisiche. Questo metodo garantisce che le attività degli altri tenant non abbiano un impatto sulle operazioni critiche. Vediamo come funziona questo approccio nella pratica.

Figura - Come Milvus gestisce le risorse fisiche.png

Figura: Come Milvus gestisce le risorse fisiche

Come mostrato nel diagramma precedente, in Milvus ci sono tre livelli di gestione delle risorse: Query Node, Resource Group e Database.

• Nodo di interrogazione: Il componente che elabora le attività di interrogazione. Viene eseguito su una macchina fisica o su un container (ad esempio, un pod in Kubernetes).

• Gruppo di risorse: Un insieme di Query Node che fa da ponte tra i componenti logici (database e collezioni) e le risorse fisiche. È possibile allocare uno o più database o raccolte a un singolo Gruppo di risorse.

Nell'esempio mostrato nel diagramma precedente, ci sono tre database logici: X, Y e Z.

• Database X: contiene la raccolta A.

• Database Y: contiene le raccolte B e C.

• Database Z: contiene le raccolte D ed E.

Supponiamo che il Database X contenga una base di conoscenza critica che non vogliamo sia influenzata dal carico del Database Y o del Database Z. Per garantire l'isolamento dei dati:

• Aldatabase X viene assegnato un proprio gruppo di risorse per garantire che la sua base di conoscenza critica non sia influenzata dai carichi di lavoro di altri database.

• Anche laraccolta E è assegnata a un gruppo di risorse separato all'interno del database padre(Z). In questo modo si ottiene l'isolamento a livello di collezione per specifici dati critici all'interno di un database condiviso.

Nel frattempo, le restanti collezioni nei database Y e Z condividono le risorse fisiche del gruppo di risorse 2.

Grazie a un'attenta mappatura dei componenti logici sulle risorse fisiche, le organizzazioni possono ottenere un'architettura multi-tenancy flessibile, scalabile e sicura, adatta alle loro specifiche esigenze aziendali.

Progettazione dell'accesso a livello di utente finale

Dopo aver appreso le migliori pratiche per la scelta di una strategia multi-tenancy per una RAG aziendale, analizziamo come progettare l'accesso a livello utente in questi sistemi.

In questi sistemi, gli utenti finali di solito interagiscono con la base di conoscenza in modalità di sola lettura attraverso gli LLM. Tuttavia, le organizzazioni hanno ancora bisogno di tenere traccia dei dati Q&A generati dagli utenti e di collegarli a utenti specifici per vari scopi, come migliorare l'accuratezza della base di conoscenza o offrire servizi personalizzati.

Prendiamo ad esempio il banco di consultazione intelligente di un ospedale. I pazienti potrebbero porre domande come: "Ci sono appuntamenti disponibili con lo specialista oggi?" o "È necessaria una preparazione specifica per il mio prossimo intervento?". Anche se queste domande non hanno un impatto diretto sulla base di conoscenza, è importante per l'ospedale tenere traccia di queste interazioni per migliorare i servizi. Queste coppie di domande e risposte vengono solitamente archiviate in un database separato (non necessariamente un database vettoriale) dedicato alla registrazione delle interazioni.

Figura - L'architettura multi-tenancy per una base di conoscenza RAG aziendale .png

Figura: L'architettura multi-tenancy per una base di conoscenza RAG aziendale

Il diagramma precedente mostra l'architettura multi-tenancy di un sistema RAG aziendale.

• Gli amministratori di sistema supervisionano il sistema RAG, gestiscono l'allocazione delle risorse, assegnano i database, li mappano ai gruppi di risorse e assicurano la scalabilità. Gestiscono l'infrastruttura fisica, come mostrato nel diagramma, dove ogni gruppo di risorse (ad esempio, i gruppi di risorse 1, 2 e 3) è mappato su server fisici (nodi di interrogazione).

• Gli affittuari (proprietari di database e sviluppatori) gestiscono la base di conoscenza, iterandola sulla base dei dati Q&A generati dagli utenti, come mostrato nel diagramma. I diversi database (Database X, Y, Z) contengono collezioni con diversi contenuti della base di conoscenza (Collezione A, B, ecc.).

• Gli utenti finali interagiscono con il sistema in sola lettura attraverso il LLM. Quando interrogano il sistema, le loro domande vengono registrate nella tabella dei record Q&A (un database separato), alimentando continuamente il sistema con dati preziosi.

Questo progetto garantisce che ogni livello del processo, dall'interazione con l'utente all'amministrazione del sistema, funzioni senza problemi, aiutando l'organizzazione a costruire una base di conoscenze solida e in continuo miglioramento.

Sintesi

In questo blog abbiamo analizzato come i framework multi-tenancy svolgano un ruolo fondamentale per la scalabilità, la sicurezza e le prestazioni delle basi di conoscenza alimentate da RAG. Isolando i dati e le risorse per i diversi tenancy, le aziende possono garantire la privacy, la conformità alle normative e l'allocazione ottimizzata delle risorse in 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 di database a quello di partizione, in base alle loro esigenze specifiche. La scelta del giusto approccio multi-tenancy garantisce alle aziende di fornire servizi su misura ai tenant, anche quando si tratta di dati e carichi di lavoro diversi.

Seguendo le best practice qui descritte, le aziende possono progettare e gestire efficacemente sistemi RAG multi-tenancy che non solo offrono un'esperienza utente di qualità superiore, ma anche scalano senza problemi in base all'aumento delle esigenze aziendali. L'architettura di Milvus garantisce alle aziende alti livelli di isolamento, sicurezza e prestazioni, rendendola un componente cruciale nella costruzione di basi di conoscenza di livello aziendale alimentate da RAG.

Restate sintonizzati per ulteriori approfondimenti su RAG Multi-Tenancy

In questo blog abbiamo discusso di come le strategie multi-tenancy di Milvus siano progettate per gestire i tenant, ma non gli utenti finali all'interno di questi tenant. Le interazioni con gli utenti finali avvengono di solito a livello di applicazione, mentre il database vettoriale stesso rimane all'oscuro di questi utenti.

Vi starete chiedendo: Se voglio fornire risposte più precise in base alla cronologia delle query di ogni utente finale, Milvus non deve mantenere un contesto Q&A personalizzato per ogni utente?

È una bella domanda e la risposta dipende dal caso d'uso. Ad esempio, in un servizio di consultazione on-demand, le richieste sono casuali e l'attenzione principale è rivolta alla qualità della base di conoscenze piuttosto che alla conservazione del contesto storico dell'utente.

In altri casi, invece, i sistemi RAG devono essere consapevoli del contesto. Quando ciò è richiesto, Milvus deve collaborare con il livello applicativo per mantenere una memoria personalizzata del contesto di ciascun utente. Questa progettazione è particolarmente importante per le applicazioni con un numero elevato di utenti finali, che analizzeremo in dettaglio nel prossimo post. Restate sintonizzati per ulteriori approfondimenti!