Creazione di flussi di lavoro RAG sicuri con partizionamento dei dati a livello di chunk
I database vettoriali sono diventati un pilastro per alimentare applicazioni basate sull’IA, in particolare la RAG (retrieval augmented generation), consentendo ricerche di similarità rapide ed efficienti su enormi set di dati ad alta dimensionalità. Un partizionamento efficace diventa cruciale man mano che questi database scalano per ospitare miliardi di vettori. Organizzando i dati in segmenti logici, il partizionamento migliora le prestazioni delle query, supporta la scalabilità e garantisce una gestione sicura dei dati tramite isolamento per tenant in ambienti multiutente.
I database vettoriali moderni, come Milvus e Zilliz Cloud (il Milvus gestito), hanno introdotto funzionalità avanzate di partizionamento per soddisfare le esigenze delle applicazioni aziendali. Tuttavia, con l’aumentare del numero di partizioni, cresce anche la complessità della loro gestione efficace. Le aziende ora cercano soluzioni incentrate prima di tutto sulla privacy che possano scalare il partizionamento integrandosi al contempo senza soluzione di continuità con i flussi di lavoro di IA.
In un recente South Bay Unstructured Data Meetup ospitato da Zilliz, Rob Quiros, CEO e cofondatore di Caber Systems, ha condiviso un approccio innovativo al partizionamento dei database vettoriali utilizzando policy di accesso per utente e per chunk. Ha spiegato in dettaglio come l’integrazione di permessi e autorizzazione nelle partizioni possa proteggere i dati a livello di chunk, affrontando le preoccupazioni relative alla privacy. Questo blog riepilogherà le sue intuizioni ed esplorerà come Caber Systems sfrutta il database vettoriale Milvus per ottenere una gestione dei dati solida e incentrata sulla privacy. Per maggiori dettagli, guarda il replay completo del suo intervento su YouTube.
Sfide nel controllo degli accessi per i database vettoriali
I database vettoriali moderni, come Milvus, supportano efficacemente la multi-tenancy, consentendo archiviazione e gestione separate per set di dati di clienti distinti. Questa capacità garantisce che i dati di un tenant siano isolati e inaccessibili agli altri, formando una base solida per una gestione dei dati sicura e organizzata. Tuttavia, sebbene questa separazione soddisfi bene l’isolamento complessivo dei dati, l’implementazione di controlli di accesso granulari specifici per utente all’interno di questi set di dati è più impegnativa. Ciò è dovuto alla diversità delle modalità di controllo degli accessi richieste dalle aziende.
Alcune di esse sono:
Role-Based Access Control (RBAC) - Assegna permessi in base a ruoli predefiniti, ma fatica con requisiti complessi e dinamici.
Attribute-Based Access Control (ABAC) - Utilizza attributi come ruoli utente, sensibilità dei dati o posizione geografica, ma richiede un sistema robusto di gestione delle policy.
Relationship-Based Access Control (ReBAC) - Fornisce accesso in base alle relazioni tra reparti o team, aggiungendo complessità ai meccanismi di applicazione.
Inoltre, fornire e gestire tali controlli di accesso può diventare un incubo amministrativo. Dall’assegnazione dei permessi alla gestione delle richieste di accesso o delle controversie, anche il carico operativo può sopraffare i team di supporto. La figura seguente di Permit.io presenta un esempio di controllo ReBAC. Illustra un processo complicato per accedere a uno specifico chunk di dati valido solo durante la sessione in corso.
Figura: Un esempio di controllo ReBAC
Figura: Un esempio di controllo ReBAC
Il ruolo degli agenti nell’accesso ai dati
Nei sistemi RAG, gli agenti che agiscono per conto degli utenti interrogano i database vettoriali e recuperano informazioni. Sebbene migliorino l’efficienza automatizzando il compito, pongono una significativa sfida di sicurezza. Gli agenti operano come proxy per le azioni degli utenti, il che significa che ereditano le autorizzazioni degli utenti durante l’accesso ai dati. Questo meccanismo, tuttavia, è vulnerabile agli attacchi:
Spoofing degli agenti: Attori malevoli possono impersonare gli agenti, sfruttando le credenziali degli utenti per accedere a dati sensibili.
Fuga di dati: Se la sessione di un agente viene compromessa, potrebbe concedere accesso non autorizzato a vaste quantità di dati.
Figura: Problemi di sicurezza con Agentic RAG
Figura: Problemi di sicurezza con Agentic RAG
Per mitigare questi rischi, le organizzazioni devono adottare misure rigorose:
Autenticazione: Autenticazione forte degli agenti per verificare le identità e prevenire lo spoofing.
Gestione delle sessioni: Limitare le sessioni degli agenti a durate predefinite, come dimostrato da Reback.
Registrazione e monitoraggio: Tracce di audit complete per monitorare l’attività degli agenti e rilevare anomalie.
Sebbene adottare queste misure possa aiutare ad affrontare gli attacchi, implementarle tutte diventa molto noioso.
Duplicazione dei dati - Una sfida significativa per le imprese
La duplicazione dei dati è un problema persistente negli ambienti aziendali. I documenti spesso subiscono molteplici iterazioni tramite copia-incolla, condivisione di file o versionamento, portando a chunk ridondanti archiviati nei database vettoriali. Questa duplicazione aumenta il sovraccarico di archiviazione e deteriora la generalizzabilità degli LLM. Rob menziona la sua precedente esperienza con la deduplicazione dei dati presso Riverbed, dove hanno riscontrato che il 90-95% dei dati era costituito da duplicati, che dovevano essere eliminati.
Figura: La duplicazione dei dati è una grande sfida nell’impostazione delle autorizzazioni
Figura: La duplicazione dei dati è una grande sfida nell’impostazione delle autorizzazioni
Una complicazione importante sorge quando i metadati, comprese le autorizzazioni, vengono copiati direttamente dai documenti ai chunk nei database vettoriali. Se esistono chunk duplicati in documenti diversi con autorizzazioni variabili, i metadati possono essere sovrascritti, causando conflitti o controlli di accesso impropri. Pertanto, risolvere le autorizzazioni a livello di chunk è fondamentale per garantire la sicurezza dei dati e la conformità.
Di seguito è riportato un esempio della dichiarazione Apple 10-Q, in cui si può vedere che il boilerplate di entrambi i documenti è comune e che le differenze tra le versioni sono minime. Pertanto, qui l’obiettivo è identificare e tracciare le origini dei chunk di dati e le relative autorizzazioni associate, in modo che le regole di accesso corrette possano essere applicate in modo coerente.
Figura: Esempio di documenti simili dai filing 10Q di Apple
Proteggere i dati a livello di chunk
Per affrontare questi problemi, Caber ha proposto una soluzione per proteggere i dati a livello di chunk. Lo fa esaminando i documenti ingeriti nel database vettoriale e costruendo un indice laterale per mappare le relazioni tra i chunk e le loro fonti. Questo grafo di lineage fornisce visibilità sull’origine di ciascun chunk e sulle autorizzazioni associate, consentendo l’assegnazione deterministica delle autorizzazioni.
Figura- L’approccio di Caber per proteggere i dati a livello di chunk
Figura: L’approccio di Caber per proteggere i dati a livello di chunk (Fonte)
Esempio di grafico di lineage con i filing 10Q di Apple
Continuando con l’esempio di Apple, il grafico qui sotto contiene chunk di dati provenienti da più versioni dei filing 10-Q di Apple. I nodi rossi nel grafico rappresentano i chunk di dati comuni a tutti i documenti. Utilizzando una policy, vengono determinate le autorizzazioni per ciascuno di questi chunk. Queste autorizzazioni vengono poi esaminate mentre i dati vengono recuperati dal database vettoriale per garantire che gli utenti abbiano l’autorizzazione appropriata per accedere a questi chunk.
Figura: Mappatura dinamica del lineage di ciascun chunk per le autorizzazioni con Caber
Esempio di demo RAG con i filing 10Q di Apple
Inizialmente, i dati vengono archiviati nel database vettoriale come Milvus senza metadati relativi alle autorizzazioni. Quando i dati escono da RAG, l’integrazione di Caber nel workflow tramite un SDK consente il filtraggio e la redazione di questi dati a livello granulare prima che possano essere passati all’LLM. Ad esempio, la figura mostra l’autorizzazione di accesso per due utenti diversi: Amy, CFO dell’azienda, è autorizzata ad accedere a tutti i chunk di dati dei rendiconti 10Q del 2023 e 2024. Al contrario, Bob, un altro utente, è stato limitato nello stesso accesso e riceve una risposta generica.
Figura: Esempio RAG che dimostra accessi diversi per due utenti
Integrazione di Caber con i workflow LLM e le sue funzionalità
Figura: Caber si integra con i workflow LLM
Caber può essere integrato con i workflow LLM utilizzando un SDK, consentendo una gestione fluida del controllo degli accessi. Tramite connettori di identità, il sistema recupera le informazioni di autenticazione dell’utente, mentre altri connettori aiutano a costruire un indice dei chunk di dati insieme alle autorizzazioni associate. Ad esempio, quando un utente interagisce con il sistema, l’agente passa il prompt al database vettoriale. La risposta RAG viene quindi inviata agli LLM, che forniscono la risposta finale. Durante questo processo, i dati vengono tracciati in base al loro flusso e tutte le connessioni saranno attribuite all’utente specifico.
Qui, l’utilizzo di Milvus come database vettoriale aiuta a supportare il partizionamento dinamico e la multi-tenancy, rendendolo ideale per applicazioni focalizzate sulla privacy che richiedono controllo degli accessi per singolo chunk. Con funzionalità come l’indicizzazione HNSW, garantisce query ad alta velocità su miliardi di vettori.
Responsabilità e auditabilità
La tracciabilità fornita da Caber offre capacità critiche di responsabilità e audit. In particolare in scenari complessi che coinvolgono l’Agentic AI, in cui gli LLM agiscono autonomamente per conto degli utenti, poiché le azioni sono piuttosto imprevedibili c’è un’elevata probabilità che qualcosa vada storto (ad es.: fuga di dati sensibili). Qui, la conoscenza di come i dati si sono mossi attraverso varie chiamate API e a oggetti è essenziale per scoprire in quale esatto passaggio il sistema ha fallito.
Figura: Responsabilità e auditabilità
Osservabilità dettagliata del flusso applicativo
Caber consente inoltre l’analisi e il debugging degli strumenti applicativi attraverso un’osservabilità dettagliata del flusso applicativo. La capacità di tracciare quando e da quali servizi i dati dell’utente sono stati consultati consente alle organizzazioni di identificare meglio colli di bottiglia, inefficienze e rischi di sicurezza all’interno delle pipeline di dati dell’applicazione.
Figura: Osservabilità del flusso applicativo
Requisiti di conformità dei dati alla policy
Le informazioni ottenute da quanto sopra possono essere reinserite negli LLM per migliorare le policy di sicurezza e colmare le lacune in modo proattivo. Il framework supporta il controllo degli accessi, l’auditabilità, la remediation e l’analisi, garantendo la conformità e migliorando la resilienza del sistema.
Data Compliance Requirements to Policy.png
Requisiti di conformità dei dati in policy (Fonte)
Conclusione
Man mano che i casi d’uso delle applicazioni LLM crescono, sempre più aziende si affidano a RAG per svolgere le proprie attività. Pertanto, proteggere e gestire l’accesso ai dati a un livello granulare diventa molto importante. Soluzioni come Caber, combinate con le capacità avanzate di partizionamento e ricerca di Milvus, forniscono il framework ideale per affrontare sfide come la duplicazione dei dati e l’impostazione del controllo degli accessi per un uso sicuro dei dati.
Risorse pertinenti
Continua a leggere
Announcing VDBBench 1.0: Open-Source VectorDB Benchmarking with Your Real-World Production Workloads
Discover VDBBench 1.0, an open-source tool for benchmarking vector databases with real-world production data, streaming ingestion, and concurrent workloads.
Democratizing AI: Making Vector Search Powerful and Affordable
Zilliz democratizes AI vector search with Milvus 2.6 and Zilliz Cloud for powerful, affordable scalability, cutting costs in infrastructure, operations, and development.
What Exactly Are AI Agents? Why OpenAI and LangChain Are Fighting Over Their Definition?
AI agents are software programs powered by AI that can perceive their environment, make decisions, and take actions to achieve a goal—often autonomously.