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 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 le considerazioni e le raccomandazioni sulla multitenancy per migliorare la sicurezza.

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.

1. Un utente invia una richiesta all'applicazione Web intelligente.
2. Un fornitore di identità autentica il richiedente.
3. L'applicazione intelligente chiama l'API di orchestrazione con la query dell'utente e il token di autorizzazione dell'utente.
4. 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 a un modello distribuito nel passaggio successivo.
5. La logica di orchestrazione chiama l'API di inferenza del modello distribuito e invia il prompt che include i dati di terra recuperati. I risultati vengono restituiti all'applicazione intelligente.

Per altre informazioni, vedere Progettare e sviluppare una soluzione RAG.

Architettura RAG a tenant singolo con la ricerca di file dell'API Risposte

Questa variante dell'architettura RAG a tenant singolo usa lo strumento di ricerca file dell'API Risposte con un modello Foundry distribuito per recuperare i dati di base da archivi vettoriali come Azure AI Search.

In questa architettura non si ha un agente di orchestrazione personalizzato o l'agente di orchestrazione ha meno responsabilità. Lo strumento di ricerca file dell'API Risposte recupera il contenuto pertinente dagli archivi vettoriali configurati e lo aggiunge al contesto del modello. Questo metodo offre un controllo minore su indicizzazione, recupero dei dati, instradamento del tenant e applicazione dell'autorizzazione rispetto al recupero controllato dall'applicazione, come una query diretta di Azure AI Search.

Flusso di lavoro

In questa architettura RAG lo strumento di ricerca dei file dell'API Risposte recupera i dati del tenant pertinenti dagli archivi vettoriali configurati e li aggiunge al contesto del modello. I passaggi seguenti descrivono un flusso di lavoro di alto livello. I passaggi in corsivo sono identici a quelli della precedente architettura RAG single-tenant con workflow dell'orchestratore.

1. Un utente invia una richiesta all'applicazione Web intelligente.
2. Un fornitore di identità autentica il richiedente.
3. L'applicazione intelligente deriva il contesto del tenant e le regole di autorizzazione dalla richiesta autenticata. Configura lo strumento di ricerca dei file dell'API Responses con archivi vettoriali autorizzati e filtri per attributi di file.
4. L'applicazione intelligente invoca la Responses API con la query dell'utente. Lo strumento di ricerca file recupera i dati di base autorizzati, lo aggiunge al contesto del modello e restituisce la risposta del modello all'applicazione intelligente.

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.

1. Un utente invia una richiesta all'applicazione Web intelligente.
2. Un fornitore di identità autentica il richiedente.
3. L'applicazione intelligente chiama l'API dell'agente di orchestrazione con la query dell'utente e il token di autorizzazione per l'utente.
4. 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 a un modello Foundry distribuito nel passaggio successivo. Sono inclusi alcuni o tutti i passaggi seguenti:
   1. 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.
   2. 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.
   3. La logica di orchestrazione recupera i dati da un archivio dati condiviso tra tenant.
5. 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 sono contenuti nel proprio archivio. Nella maggior parte dei servizi dati, gli archivi isolati non sono soggetti al problema del vicino rumoroso di altri clienti. 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 noisy neighbor antipattern e 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. Azure SQL e Database di Azure per PostgreSQL supportano 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, ogni richiesta di recupero deve includere un discriminare tenant e qualsiasi filtro di autorizzazione a livello di utente. Applica questi filtri prima di passare i dati di grounding al modello.

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, i filtri di sicurezza Azure AI Search o la logica personalizzata, i dati o i metadati per implementare il filtro. Applicare il filtro a ogni richiesta di recupero, indipendentemente dal fatto che l'applicazione recuperi i dati di base prima di chiamare un modello o un agente recupera i dati durante il ciclo di esecuzione. Queste funzionalità della piattaforma richiedono una progettazione di sistema che mantiene il contesto di autorizzazione del tenant e dell'utente.

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.
• Seleziona solo i dati dal tenant dell'utente nei negozi multi-tenant.
• Usare l'identità appropriata di un utente per supportare la logica di autorizzazione basata sulla piattaforma.
• Applicare la logica personalizzata di limitazione della visibilità per sicurezza.
• 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 multitenant, è necessario considerare come architettare la soluzione di dati di riferimento 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 | Principal Software Engineer, Azure Patterns & Pratiche
• Daniel Scott-Raynsford | Sr. Partner Solution Architect, Data & AI

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggio successivo

Risorse correlate

• Architettura di soluzioni SaaS e multitenant
• Architettura di riferimento della chat di Microsoft Foundry di base
• Accedi ai modelli di Foundry e ad altri modelli linguistici tramite un gateway