La generazione di recupero aumentata (RAG) è un modello per la creazione di applicazioni in cui i modelli fondamentali vengono usati per ragionare su informazioni proprietarie o altre informazioni 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, in cui ogni cliente (tenant) è costituito da più utenti della stessa organizzazione, società o gruppo. Negli scenari multi-tenant è necessario assicurarsi che i tenant o i singoli utenti all'interno dei tenant siano in grado di incorporare solo i dati di base che sono autorizzati a visualizzare.
Anche se esistono problemi multi-tenant oltre a garantire che gli utenti accevano solo le informazioni che dovrebbero visualizzare, questo articolo è incentrato su questo aspetto della multi-tenancy. L'articolo inizia con una panoramica delle architetture RAG a tenant singolo, illustra le sfide relative alla multi-tenancy con RAG e alcuni approcci comuni da seguire e conclude con considerazioni e raccomandazioni sicure sulla multi-tenancy.
Nota
Questo articolo illustra alcune funzionalità specifiche di Azure OpenAI, ad esempio Azure OpenAI sui dati. Detto questo, la maggior parte dei principi illustrati in questo documento si applica alla maggior parte dei modelli di intelligenza artificiale di base, indipendentemente dalla piattaforma host.
Architettura RAG a tenant singolo con orchestrazione
Figura 1. Architettura RAG a tenant singolo
Workflow
In questa architettura RAG a tenant singolo, un agente di orchestrazione ha la responsabilità di recuperare i dati del tenant proprietari pertinenti dagli archivi dati e di fornirgli come dati di base al modello di base. Di seguito è riportato un flusso di lavoro generale:
- Un utente invia una richiesta all'applicazione Web intelligente.
- Un provider 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 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 di terra recuperati. I risultati vengono restituiti all'applicazione intelligente.
Per altre informazioni sui dettagli di RAG, vedere Progettazione e sviluppo di una soluzione RAG.
Architettura RAG a tenant singolo con accesso diretto ai dati
Una variante dell'architettura RAG a tenant singolo sfrutta la capacità del servizio Azure OpenAI di integrarsi direttamente con gli archivi dati, ad esempio Ricerca 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 ha la responsabilità di chiamare nell'archivio dati per recuperare i dati di base e passare tali dati al modello linguistico. A sua volta, si ha meno controllo sui dati di base da recuperare e sulla pertinenza di tali dati.
Nota
Il servizio Azure OpenAI, gestito da Microsoft, si integra con l'archivio dati. Il modello stesso non si integra con gli archivi dati. Il modello riceve i dati di base esattamente come se i dati vengono recuperati da un agente di orchestrazione.
Figura 2. Architettura RAG a tenant singolo con accesso diretto ai dati dal servizio Azure OpenAI
Workflow
In questa architettura RAG, il servizio che fornisce il modello di base ha la responsabilità di recuperare i dati del tenant proprietari appropriati dagli archivi dati e di usare tali dati come dati di base per il modello di base. Di seguito è riportato un flusso di lavoro di alto livello (i passaggi in corsivo sono identici all'architettura RAG a tenant singolo con flusso di lavoro dell'agente di orchestrazione):
- Un utente invia una richiesta all'applicazione Web intelligente.
- Un provider di identità autentica il richiedente.
- L'applicazione intelligente chiama quindi il servizio Azure OpenAI con la query dell'utente.
- Il servizio OpenAI di Azure si connette agli archivi dati supportati, ad esempio Ricerca di intelligenza artificiale di Azure e Archiviazione BLOB di Azure, per recuperare i dati di base. I dati di base vengono usati come parte del contesto quando il servizio OpenAI di Azure chiama il modello di linguaggio OpenAI. I risultati vengono restituiti all'applicazione intelligente.
Per considerare questa architettura in una soluzione multi-tenant, il servizio, ad esempio Azure OpenAI, che accede direttamente ai dati di base deve supportare la logica multi-tenant richiesta dalla soluzione.
Multi-tenancy 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. Potrebbero essere presenti anche dati in un archivio condiviso tra tenant. Solo i dati che l'utente è autorizzato a visualizzare devono essere usati come dati di base. Gli utenti devono visualizzare solo i dati comuni (tutti i tenant) o i dati del tenant con regole di filtro applicate per assicurarsi che visualizzino solo i dati che sono autorizzati a visualizzare.
Figura 3: Architettura RAG - con più tenant dell'archivio dati
Workflow
Questo flusso di lavoro è identico a quello dell'architettura RAG a tenant singolo con agente di orchestrazione , ad eccezione del passaggio 4.
- Un utente invia una richiesta all'applicazione Web intelligente.
- Un provider 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 al prompt inviato ad Azure OpenAI nel passaggio successivo. Sono necessari alcuni o tutti i passaggi seguenti:
- La logica di orchestrazione recupera i dati di base dall'istanza appropriata dell'archivio dati specifico del tenant, applicando potenzialmente regole di filtro di 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, applicando potenzialmente 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 di terra recuperati. I risultati vengono restituiti all'applicazione intelligente.
Considerazioni sulla progettazione per i dati multi-tenant in RAG
Scelta dei modelli di isolamento dello store
Esistono due approcci architetturali principali per l'archiviazione e i dati in scenari multi-tenant: store per tenant e archivi multi-tenant. Questi approcci si aggiungono agli archivi che contengono dati condivisi tra tenant. Questa sezione illustra ogni approccio. Si noti che la soluzione multi-tenant può usare una combinazione di questi approcci.
Store per tenant
In store-per-tenant, come suggerisce il nome, ogni tenant ha un proprio archivio. 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 dell'archivio può essere attribuito a un singolo tenant.
Le sfide di questo approccio includono potenzialmente un maggiore sovraccarico di gestione e operazioni e costi più elevati. Questo approccio non deve essere considerato quando è presente un numero elevato di tenant di piccole dimensioni, ad esempio scenari business-to-consumer. Questo approccio potrebbe anche essere eseguito in base alle limitazioni del servizio.
Nel contesto di questo scenario di intelligenza artificiale, un archivio 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.
Archivi 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 più elevato di tenant rispetto al modello store-per-tenant e un sovraccarico di gestione inferiore a causa del minor numero di istanze dell'archivio.
Le sfide legate all'uso di archivi condivisi includono la necessità di garantire l'isolamento dei dati, la gestione dei dati, il potenziale antipattern adiacente rumoroso e la difficoltà di allocazione dei costi ai tenant. Garantire l'isolamento dei dati è l'aspetto più importante di questo approccio. L'utente ha la responsabilità di implementare l'approccio di sicurezza per garantire che i tenant siano in grado di accedere solo ai dati. La gestione dei dati può anche essere una sfida se i tenant hanno cicli di vita dei dati diversi che possono richiedere operazioni come la compilazione di indici in pianificazioni diverse.
Alcune piattaforme hanno funzionalità che è possibile sfruttare quando si implementa l'isolamento dei dati del tenant negli archivi condivisi. Azure Cosmos DB, ad esempio, offre supporto nativo per il partizionamento e il partizionamento orizzontale ed è comune usare un identificatore del tenant come chiave di partizione per fornire un certo livello di isolamento tra i tenant. Azure SQL e Postgres Flex supportano la sicurezza a livello di riga, anche se questa funzionalità non viene comunemente usata 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, ciò significa che i dati di base per tutti i tenant vengono visualizzati nello stesso archivio dati, in modo che la query su tale archivio dati contenga un discriminante tenant per garantire che le risposte siano limitate a riportare solo i dati pertinenti nel contesto del tenant.
Archivi condivisi
Le soluzioni multi-tenant hanno spesso dati condivisi tra tenant. In un esempio di soluzione multi-tenant per il dominio sanitario, potrebbe essere presente un database che archivia informazioni mediche generali o informazioni non specifiche del tenant.
Nel contesto di questo scenario di intelligenza artificiale, si tratta di un archivio dati di base generalmente accessibile che non richiede in modo specifico il filtro in base a qualsiasi tenant perché i dati sono rilevanti e autorizzati per tutti i tenant nel sistema.
Identità
L'identità è un aspetto fondamentale delle soluzioni multi-tenant, tra cui RAG multi-tenant sicuro. L'applicazione intelligente deve integrarsi con un provider di identità (IdP) per autenticare l'identità dell'utente. La soluzione RAG multi-tenant richiede una directory di identità in cui vengono archiviate identità autorevoli o riferimenti alle identità. Questa identità deve fluire attraverso la catena di richieste, consentendo ai servizi downstream, ad esempio l'agente di orchestrazione o persino l'archivio dati stesso per identificare l'utente.
È anche necessario un mezzo per eseguire il mapping di un utente a un tenant in modo da poter concedere l'accesso ai dati del tenant.
Definire i requisiti di autorizzazione e tenant
Quando si compila una soluzione RAG multi-tenant, è necessario definire il tenant per la soluzione. I due modelli comuni tra cui scegliere sono business-to-business (B2B) e business-to-consumer (B2C). Questa determinazione consente di informare l'utente delle aree da considerare quando si progetta la soluzione. Comprendere il numero di tenant è fondamentale per decidere il modello di archivio dati. Un numero elevato di tenant può richiedere un modello con più tenant per ogni archivio, mentre un numero inferiore potrebbe consentire un archivio per ogni modello di tenant. Anche la quantità di dati per tenant è importante. Se i tenant hanno grandi quantità di dati che potrebbero impedire l'uso di archivi multi-tenant a causa di limitazioni di dimensioni nell'archivio dati.
Nei carichi di lavoro esistenti che vengono espansi per supportare questo scenario di intelligenza artificiale, è possibile che sia già stata effettuata questa scelta. In generale, sarà 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 introducono nuovi componenti, ad esempio un archivio di ricerca vettoriale dedicato come archivio a terra dedicato, sarà necessario prendere questa decisione, considerando fattori come la strategia corrente del timbro di distribuzione, l'impatto del piano di controllo dell'applicazione e eventuali differenze del ciclo di vita dei dati per tenant ,ad esempio situazioni di pagamento in base alle prestazioni.
Dopo aver definito il tenant per la soluzione, è necessario definire i requisiti di autorizzazione per i dati. Anche se i tenant accederanno solo ai dati dal tenant, i requisiti di autorizzazione potrebbero essere più granulari. Ad esempio, in una soluzione sanitaria potrebbero essere presenti regole come:
- Un paziente può accedere solo ai propri dati dei pazienti
- 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 impostati nei 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.
Filtri
Il filtro, noto anche come taglio della sicurezza, si riferisce all'esposizione solo dei dati agli utenti autorizzati a visualizzare. In uno scenario RAG multi-tenant, un utente può essere mappato a un archivio specifico del tenant. Ciò non significa che l'utente deve essere in grado di accedere a tutti i dati in tale archivio. In Definire i requisiti di tenant e autorizzazione è stata illustrata l'importanza di definire i requisiti di autorizzazione per i dati. Queste regole di autorizzazione devono essere usate come base per il filtro.
I filtri possono essere eseguiti usando funzionalità della piattaforma dati, ad esempio la sicurezza a livello di riga o la logica personalizzata, i dati o i metadati. Anche in questo caso, queste funzionalità della piattaforma non vengono comunemente usate nelle soluzioni multi-tenant a causa della necessità di progettare il sistema in base a queste funzionalità.
Incapsulamento della logica dei dati multi-tenant
È consigliabile avere un'API davanti a qualsiasi meccanismo di archiviazione in uso. L'API funge da gatekeeper, imponendo che gli utenti ottengano l'accesso solo alle informazioni a cui devono accedere.
Figura 4. Architettura RAG multi-tenant con un'API che incapsula la logica di accesso ai dati tenant multi-tenant
Come indicato in precedenza in questo articolo, l'accesso utente ai dati può essere limitato da:
- Tenant dell'utente
- Funzionalità della piattaforma
- Regole di filtro/taglio di sicurezza personalizzate.
Questo livello deve avere le responsabilità seguenti:
- Indirizzare la query a un archivio specifico del tenant in un modello store-per-tenant
- Selezionare solo i dati dal tenant dell'utente in archivi multi-tenant
- Usare l'identità appropriata per un utente per supportare la logica di autorizzazione abilitata per la 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 direttamente query negli archivi back-end. Tutte le richieste di dati devono essere propagate attraverso questo livello API. Questo livello API fornisce un singolo punto di governance o livello di sicurezza sopra i dati del tenant. Questo approccio impedisce al tenant e alla logica di autorizzazione dell'accesso ai dati utente di sanguinare in aree diverse dell'applicazione. Questa logica viene incapsulata nel livello API. Questo incapsulamento semplifica la convalida e il test della soluzione.
Riepilogo
Quando si progetta una soluzione di inferenza RAG multi-tenant, è necessario tenere conto di come progettare la soluzione dati di base per i tenant. Informazioni sul numero di tenant e sulla quantità di dati per tenant archiviati. Queste informazioni consentono di progettare la soluzione di tenancy dei dati. È consigliabile implementare un livello API che incapsula la logica di accesso ai dati, inclusa sia la logica multi-tenant che la logica di filtro.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
- John Downs | Principal Software Engineer
- Daniel Scott-Raynsford | Sr. Partner Solution Architect, Data & AI