Progettare una soluzione di inferenza RAG multi-tenant sicura
Retrieval-Augmented Generation (RAG) è un modello per la creazione di applicazioni che usano modelli di base per ragionare su informazioni proprietarie o altri dati non disponibili pubblicamente su Internet. In genere, un'applicazione client chiama a un livello di orchestrazione che recupera informazioni rilevanti da un archivio dati, ad esempio un database vettoriale. Il livello di orchestrazione passa tali dati come parte del contesto come dati di base al modello di base.
Una soluzione multi-tenant viene usata da più clienti. Ogni cliente, o tenant, è costituito da più utenti della stessa organizzazione, società o gruppo. Negli scenari multi-tenant è necessario assicurarsi che i tenant o gli utenti all'interno dei tenant siano in grado di incorporare solo i dati di base a cui sono autorizzati ad accedere.
Ci sono problemi multi-tenant oltre a garantire che gli utenti accevano solo le informazioni a cui sono autorizzati ad accedere. Tuttavia, questo articolo è incentrato su questo aspetto della multitenancy. Questo articolo inizia con una panoramica delle architetture RAG a singolo tenant. Illustra le sfide che possono verificarsi in multi-tenancy con RAG e alcuni approcci comuni da adottare. Vengono inoltre illustrate considerazioni e raccomandazioni per la multi-tenancy per migliorare la sicurezza.
Nota
Questo articolo descrive diverse funzionalità specifiche del servizio OpenAI di Azure, ad esempio la funzionalità OpenAI di Azure nei dati. Tuttavia, è possibile applicare la maggior parte dei principi descritti in questo articolo ai modelli di intelligenza artificiale fondamentali in qualsiasi piattaforma.
Architettura RAG a tenant singolo con un orchestratore
Flusso di lavoro
In questa architettura RAG a tenant singolo, un agente di orchestrazione recupera i dati del tenant proprietari pertinenti dagli archivi dati e li fornisce come dati di base al modello di base. I passaggi seguenti descrivono un flusso di lavoro di alto livello.
- Un utente invia una richiesta all'applicazione Web intelligente.
- Un fornitore di identità autentica il richiedente.
- L'applicazione intelligente chiama l'API di orchestrazione con la query dell'utente e il token di autorizzazione dell'utente.
- La logica di orchestrazione estrae la query dell'utente dalla richiesta e chiama l'archivio dati appropriato per recuperare i dati di base pertinenti per la query. I dati di base vengono aggiunti al prompt inviato al modello di base, ad esempio un modello esposto in Azure OpenAI, nel passaggio successivo.
- La logica di orchestrazione si connette all'API di inferenza del modello di base e invia il prompt che include i dati recuperati a terra. I risultati vengono restituiti all'applicazione intelligente.
Per altre informazioni, vedere Progettare e sviluppare una soluzione RAG.
Architettura RAG a tenant singolo con accesso diretto ai dati
Questa variante dell'architettura RAG a tenant singolo usa la funzionalità On Your Data di Azure OpenAI per l'integrazione diretta con archivi dati come Ricerca di intelligenza artificiale di Azure. In questa architettura non si ha un agente di orchestrazione personalizzato o l'agente di orchestrazione ha meno responsabilità. L'API OpenAI di Azure chiama nell'archivio dati per recuperare i dati di base e passa tali dati al modello linguistico. Questo metodo consente di controllare meno i dati di base da recuperare e la pertinenza dei dati.
Nota
Azure OpenAI è gestito da Microsoft. Si integra con l'archivio dati, ma il modello stesso non si integra con l'archivio dati. Il modello riceve i dati di base nello stesso modo come quando un orchestratore recupera i dati.
Flusso di lavoro
In questa architettura RAG, il servizio che fornisce il modello di base recupera i dati tenant proprietari appropriati dagli archivi dati e li usa come dati di base al modello di base. I passaggi seguenti descrivono un flusso di lavoro di alto livello. I passaggi in corsivo sono identici alla precedente architettura RAG a tenant singolo con un flusso di lavoro di orchestrazione.
- Un utente invia una richiesta all'applicazione Web intelligente.
- Un fornitore di identità autentica il richiedente.
- L'applicazione intelligente chiama Azure OpenAI con la query dell'utente.
- Azure OpenAI si connette agli archivi dati supportati, ad esempio Ricerca di intelligenza artificiale e Archiviazione BLOB di Azure, per recuperare i dati di base. I dati di base vengono usati come parte del contesto quando Azure OpenAI chiama il modello di linguaggio OpenAI. I risultati vengono restituiti all'applicazione intelligente.
Se si vuole usare questa architettura in una soluzione multi-tenant, il servizio che accede direttamente ai dati di base, ad esempio Azure OpenAI, deve supportare la logica multi-tenant richiesta dalla soluzione.
Multitenancy nell'architettura RAG
Nelle soluzioni multi-tenant i dati del tenant possono esistere in un archivio specifico del tenant o coesistere con altri tenant in un archivio multi-tenant. I dati possono anche trovarsi in un archivio condiviso tra tenant. Solo i dati a cui l'utente è autorizzato ad accedere devono essere usati come dati di base. L'utente dovrebbe visualizzare solo i dati comuni o di tutti i tenant, oppure i dati del proprio tenant filtrati per garantire che vedano solo i dati a cui sono autorizzati ad accedere.
Flusso di lavoro
I passaggi seguenti descrivono un flusso di lavoro di alto livello. I passaggi in corsivo sono identici all'architettura RAG a tenant singolo con un flusso di lavoro orchestrato da un agente.
- Un utente invia una richiesta all'applicazione Web intelligente.
- Un fornitore di identità autentica il richiedente.
- L'applicazione intelligente chiama l'API dell'agente di orchestrazione con la query dell'utente e il token di autorizzazione per l'utente.
- La logica di orchestrazione estrae la query dell'utente dalla richiesta e chiama gli archivi dati appropriati per recuperare i dati di base pertinenti e autorizzati dal tenant per la query. I dati di base vengono aggiunti alla richiesta inviata ad Azure OpenAI nel passaggio successivo. Sono inclusi alcuni o tutti i passaggi seguenti:
- La logica di orchestrazione recupera i dati di base dall'istanza appropriata dell'archivio dati specifico del tenant e potenzialmente applica regole di filtro della sicurezza per restituire solo i dati a cui l'utente è autorizzato ad accedere.
- La logica di orchestrazione recupera i dati di base del tenant appropriati dall'archivio dati multi-tenant e potenzialmente applica regole di filtro di sicurezza per restituire solo i dati a cui l'utente è autorizzato ad accedere.
- La logica di orchestrazione recupera i dati da un archivio dati condiviso tra tenant.
- La logica di orchestrazione si connette all'API di inferenza del modello di base e invia il prompt che include i dati recuperati a terra. I risultati vengono restituiti all'applicazione intelligente.
Considerazioni sulla progettazione per i dati multi-tenant in RAG
Quando si progetta la soluzione di inferenza RAG multi-tenant, prendere in considerazione le opzioni seguenti.
Scegliere un modello di isolamento dello store
I due approcci architetturali principali per l'archiviazione e i dati in scenari multi-tenant sono il modello store-per-tenant e gli archivi multi-tenant. Questi approcci si aggiungono agli archivi che contengono dati condivisi tra tenant. La soluzione multi-tenant può usare una combinazione di questi approcci.
Archivi di archiviazione per tenant
Nei negozi per singolo inquilino, ogni inquilino ha il proprio negozio. I vantaggi di questo approccio includono l'isolamento dei dati e delle prestazioni. I dati di ogni tenant vengono incapsulati nel proprio archivio. Nella maggior parte dei servizi dati, gli archivi isolati non sono soggetti al problema del vicino rumoroso di altri tenant. Questo approccio semplifica anche l'allocazione dei costi perché l'intero costo di una distribuzione del negozio può essere attribuito a un singolo locatario.
Questo approccio potrebbe presentare sfide come l'aumento della gestione e il sovraccarico operativo e i costi più elevati. Non è consigliabile usare questo approccio se si dispone di un numero elevato di tenant di piccole dimensioni, ad esempio negli scenari business-to-consumer. Questo approccio può anche raggiungere o superare i limiti del servizio .
Nel contesto di questo scenario di intelligenza artificiale, un archivio store per tenant significa che i dati di base necessari per portare la pertinenza nel contesto provengono da un archivio dati esistente o nuovo che contiene solo dati di base per il tenant. In questa topologia, l'istanza del database è il discriminatorio usato per ogni tenant.
Negozi multi-tenant
Negli archivi multi-tenant i dati di più tenant coesistono nello stesso archivio. I vantaggi di questo approccio includono il potenziale per l'ottimizzazione dei costi, la possibilità di gestire un numero maggiore di tenant rispetto al modello store-per-tenant e un sovraccarico di gestione inferiore a causa del numero inferiore di istanze dell'archivio.
Le sfide dell'uso di archivi condivisi includono la necessità di isolamento e gestione dei dati, il potenziale per il antipattern adiacente rumorosoe l'allocazione dei costi più complessa ai tenant. L'isolamento dei dati è il problema più importante quando si usa questo approccio. È necessario implementare approcci sicuri per garantire che i tenant possano accedere solo ai dati. La gestione dei dati può essere complessa anche se i tenant hanno cicli di vita dei dati diversi che richiedono operazioni come la compilazione di indici in pianificazioni diverse.
Alcune piattaforme dispongono di funzionalità che è possibile usare quando si implementa l'isolamento dei dati del tenant negli archivi condivisi. Azure Cosmos DB, ad esempio, supporta il partizionamento dei dati e il partizionamento orizzontale. In genere è consigliabile usare un identificatore del tenant come chiave di partizione per fornire un certo isolamento tra i tenant. Sql di Azure e Database di Azure per PostgreSQL - Il server flessibile supporta la sicurezza a livello di riga. Tuttavia, queste funzionalità non vengono in genere usate nelle soluzioni multi-tenant perché è necessario progettare la soluzione in base a queste funzionalità se si prevede di usarle nell'archivio multi-tenant.
Nel contesto di questo scenario di intelligenza artificiale, i dati di base per tutti i tenant si confondono nello stesso archivio dati. Pertanto, la query a tale archivio dati deve includere un discriminante di tenant per garantire che le risposte siano limitate ai soli dati rilevanti nel contesto del tenant.
Negozi condivisi
Le soluzioni multi-tenant spesso condividono i dati tra tenant. In un esempio di soluzione multi-tenant per il dominio sanitario, un database potrebbe archiviare informazioni mediche generali o informazioni non specifiche del tenant.
Nel contesto di questo scenario di intelligenza artificiale, l'archivio dati di base è generalmente accessibile e non richiede filtri basati su tenant specifici perché i dati sono rilevanti e autorizzati per tutti i tenant nel sistema.
Identità
Identity è un aspetto chiave delle soluzioni multitenant, incluse le soluzioni RAG multitenant. L'applicazione intelligente deve integrarsi con un provider di identità per autenticare l'identità dell'utente. La soluzione RAG multi-tenant richiede una directory di identità che archivia identità autorevoli o riferimenti alle identità. Questa identità deve attraversare la catena di richieste e consentire ai servizi downstream, ad esempio l'agente di orchestrazione o l'archivio dati stesso, di identificare l'utente.
È anche necessario un modo per mappare un utente a un locatario in modo da poter concedere l'accesso ai dati del locatario.
Definire il tenant e i requisiti di autorizzazione
Quando si compila una soluzione RAG multi-tenant, è necessario definire il tenant per la soluzione. I due modelli comuni tra cui scegliere sono modelli business-to-business e business-to-consumer. Il modello scelto consente di determinare quali altri fattori prendere in considerazione quando si compila la soluzione. Comprendere il numero di tenant è fondamentale per la scelta del modello di archivio dati. Un gran numero di inquilini potrebbe richiedere un modello con più inquilini per ogni negozio. Un numero inferiore di inquilini potrebbe consentire un modello store-per-tenant. Anche la quantità di dati per ogni tenant è importante. I tenant con grandi quantità di dati potrebbero impedire l'uso di archivi multi-tenant a causa di limitazioni di dimensioni nell'archivio dati.
Se si intende espandere un carico di lavoro esistente per supportare questo scenario di intelligenza artificiale, è possibile che sia già stata presa questa decisione. In generale, è possibile usare la topologia di archiviazione dei dati esistente per i dati di base se tale archivio dati può fornire una pertinenza sufficiente e soddisfare eventuali altri requisiti non funzionali. Tuttavia, se si ha intenzione di introdurre nuovi componenti, come ad esempio un magazzino di ricerca vettoriale dedicato come archivio di riferimento dedicato, è necessario comunque prendere questa decisione. Prendere in considerazione fattori come la strategia attuale della stampa di distribuzione, l'impatto del piano di controllo delle applicazioni e le differenze del ciclo di vita dei dati per singolo tenant, ad esempio situazioni con pagamento in base alle prestazioni.
Dopo aver definito il tenant per la soluzione, è necessario definire i requisiti di autorizzazione per i dati. Gli inquilini accedono solo ai dati del proprio inquilino, ma i requisiti di autorizzazione potrebbero essere più dettagliati. Ad esempio, in una soluzione sanitaria, potrebbero essere presenti regole come:
- Un paziente può accedere solo ai propri dati del paziente.
- Un professionista sanitario può accedere ai dati dei pazienti.
- Un utente finanziario può accedere solo ai dati correlati alle finanze.
- Un revisore clinico può visualizzare tutti i dati dei pazienti.
- Tutti gli utenti possono accedere alle conoscenze mediche di base in un archivio dati condiviso.
In un'applicazione RAG basata su documenti, è possibile limitare l'accesso degli utenti ai documenti in base a uno schema di assegnazione di tag o a livelli di riservatezza assegnati ai documenti.
Dopo aver definito il tenant e aver compreso chiaramente le regole di autorizzazione, usare tali informazioni come requisiti per la soluzione di archiviazione dati.
Filtro dei dati
Limitare l'accesso solo ai dati a cui gli utenti sono autorizzati è noto come filtro o limitazione della sicurezza. In uno scenario RAG multitenant, un utente potrebbe essere mappato ad un archivio specifico per il tenant. Ciò non significa che l'utente deve essere in grado di accedere a tutti i dati in tale archivio. Definisci il tuo tenant e i requisiti di autorizzazione. discute l'importanza di definire i requisiti di autorizzazione per i tuoi dati. È consigliabile usare queste regole di autorizzazione come base per il filtro.
È possibile usare funzionalità della piattaforma dati come la sicurezza a livello di riga per implementare il filtro. Oppure potrebbe essere necessaria logica, dati o metadati personalizzati. Queste funzionalità della piattaforma non vengono in genere usate nelle soluzioni multi-tenant perché è necessario progettare il sistema in base a queste funzionalità.
Incapsulare la logica dei dati multi-tenant
È consigliabile avere un'API davanti al meccanismo di archiviazione usato. L'API funge da gatekeeper che garantisce che gli utenti ottengano l'accesso solo alle informazioni a cui sono autorizzati ad accedere.
L'accesso degli utenti ai dati può essere limitato da:
- L'inquilino dell'utente.
- Funzionalità della piattaforma.
- Regole personalizzate di filtro o limitazione della sicurezza.
Il livello API deve:
- Indirizza la query a un archivio specifico del tenant in un modello store-per-tenant.
- Selezionare solo i dati dal tenant dell'utente negli archivi multi-tenant.
- Usare l'identità appropriata di un utente per supportare la logica di autorizzazione basata sulla piattaforma.
- Applicare la logica di taglio della sicurezza personalizzata.
- Archiviare i log di accesso delle informazioni di base a scopo di controllo.
Il codice che deve accedere ai dati del tenant non deve essere in grado di eseguire query direttamente negli archivi back-end. Tutte le richieste di dati devono essere propagate attraverso il livello API. Questo livello API offre un singolo punto di governance o sicurezza sopra i dati del locatario. Questo approccio impedisce al tenant e alla logica di autorizzazione dell'accesso ai dati utente di raggiungere altre aree dell'applicazione. Questa logica viene incapsulata nel livello API. Questo incapsulamento semplifica la convalida e il test della soluzione.
Sommario
Quando si progetta una soluzione di inferenza RAG multi-tenant, è necessario considerare come progettare la soluzione dati di base per i tenant. Comprendere il numero di tenant e la quantità di dati per tenant archiviati. Queste informazioni aiutano a progettare la soluzione di gestione dei dati. È consigliabile implementare un livello API che incapsula la logica di accesso ai dati, inclusa la logica multi-tenant e la logica di filtro.
Contributori
Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.
Autori principali:
- John Downs | Ingegnere Software Principale
- Daniel Scott-Raynsford | Sr. Partner Solution Architect, Data & AI
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.