Criando fluxos de trabalho RAG seguros com particionamento de dados em nível de chunk
Bancos de dados vetoriais tornaram-se um pilar para impulsionar aplicações orientadas por IA, particularmente RAG (geração aumentada por recuperação), permitindo buscas por similaridade rápidas e eficientes em conjuntos de dados massivos de alta dimensionalidade. O particionamento eficaz torna-se crucial à medida que esses bancos de dados escalam para acomodar bilhões de vetores. Ao organizar dados em segmentos lógicos, o particionamento melhora o desempenho das consultas, oferece suporte à escalabilidade e garante o gerenciamento seguro de dados por meio de isolamento por locatário em ambientes multiusuário.
Bancos de dados vetoriais modernos, como Milvus e Zilliz Cloud (o Milvus gerenciado), introduziram recursos avançados de particionamento para atender às demandas de aplicações empresariais. No entanto, à medida que o número de partições cresce, também aumenta a complexidade de gerenciá-las de forma eficaz. As empresas agora buscam soluções que priorizem a privacidade e possam escalar o particionamento enquanto se integram perfeitamente aos fluxos de trabalho de IA.
Em um recente South Bay Unstructured Data Meetup organizado pela Zilliz, Rob Quiros, CEO e cofundador da Caber Systems, compartilhou uma abordagem inovadora para particionar bancos de dados vetoriais usando políticas de acesso por usuário e por bloco. Ele detalhou como a integração de permissões e autorização às partições pode proteger os dados no nível do bloco, abordando preocupações com privacidade. Este blog irá recapitular seus insights e explorar como a Caber Systems aproveita o banco de dados vetorial Milvus para alcançar um gerenciamento de dados robusto e centrado em privacidade. Para mais detalhes, assista ao replay completo de sua palestra no YouTube.
Desafios no controle de acesso para bancos de dados vetoriais
Bancos de dados vetoriais modernos, como Milvus, oferecem suporte eficaz a multi-tenancy, permitindo armazenamento e gerenciamento separados para conjuntos de dados distintos de clientes. Esse recurso garante que os dados de um locatário sejam isolados e inacessíveis a outros, formando uma base robusta para um gerenciamento de dados seguro e organizado. No entanto, embora essa separação atenda bem ao isolamento geral de dados, implementar controles de acesso granulares específicos por usuário dentro desses conjuntos de dados é mais desafiador. Isso se deve à diversidade de modos de controle de acesso que as empresas exigem.
Alguns deles são:
Controle de Acesso Baseado em Função (RBAC) - Atribui permissões com base em funções predefinidas, mas enfrenta dificuldades com requisitos complexos e dinâmicos.
Controle de Acesso Baseado em Atributos (ABAC) - Usa atributos como funções de usuário, sensibilidade dos dados ou localização geográfica, mas exige um sistema robusto de gerenciamento de políticas.
Controle de Acesso Baseado em Relacionamentos (ReBAC) - Fornece acesso com base em relacionamentos entre departamentos ou equipes, adicionando complexidade aos mecanismos de aplicação.
Além disso, fornecer e gerenciar tais controles de acesso pode se tornar um pesadelo administrativo. Desde atribuir permissões até lidar com solicitações ou disputas de acesso, a sobrecarga operacional também pode sobrecarregar as equipes de suporte. A figura abaixo da Permit.io apresenta um exemplo de controle ReBAC. Ela ilustra um processo complicado para acessar um bloco específico de dados válido apenas durante a sessão em andamento.
Figura: Um exemplo de controle ReBAC
Figura: Um exemplo de controle ReBAC
O Papel dos Agentes no Acesso a Dados
Em sistemas RAG, os agentes que atuam em nome dos usuários consultam bancos de dados vetoriais e recuperam informações. Embora melhorem a eficiência ao automatizar a tarefa, eles representam um desafio significativo de segurança. Os agentes operam como proxies para as ações dos usuários, o que significa que herdam as permissões dos usuários durante o acesso aos dados. Esse mecanismo, no entanto, é vulnerável a ataques:
Falsificação de Agentes: Agentes mal-intencionados podem se passar por agentes, explorando credenciais de usuários para acessar dados confidenciais.
Vazamento de Dados: Se a sessão de um agente for comprometida, ela poderá conceder acesso não autorizado a grandes volumes de dados.
Figura: Problemas de segurança com Agentic RAG
Figura: Problemas de segurança com Agentic RAG
Para mitigar esses riscos, as organizações devem adotar medidas rigorosas:
Autenticação: Autenticação forte de agentes para verificar identidades e evitar falsificação.
Gerenciamento de Sessão: Restringir as sessões dos agentes a durações predefinidas, como demonstrado pelo Reback.
Registro e Monitoramento: Trilhas de auditoria abrangentes para rastrear a atividade dos agentes e detectar anomalias.
Embora a adoção dessas medidas possa ajudar a enfrentar os ataques, implementar tudo isso se torna muito trabalhoso.
Duplicação de Dados - Um Desafio Significativo para Empresas
A duplicação de dados é um problema persistente em ambientes corporativos. Documentos frequentemente passam por várias iterações por meio de copiar e colar, compartilhamento de arquivos ou versionamento, levando a chunks redundantes armazenados em bancos de dados vetoriais. Essa duplicação aumenta a sobrecarga de armazenamento e deteriora a generalização dos LLMs. Rob menciona sua experiência anterior com deduplicação de dados na Riverbed, onde encontraram 90-95% dos dados como duplicados, que precisaram ser eliminados.
Figura: A duplicação de dados é um grande desafio na definição de permissões
Figura: A duplicação de dados é um grande desafio na definição de permissões
Uma grande complicação surge quando metadados, incluindo permissões, são copiados diretamente de documentos para chunks em bancos de dados vetoriais. Se chunks duplicados existirem em diferentes documentos com permissões variadas, os metadados podem ser sobrescritos, causando conflitos ou controles de acesso inadequados. Portanto, resolver permissões no nível do chunk é crucial para garantir a segurança dos dados e a conformidade.
Abaixo está um exemplo do relatório 10-Q da Apple, no qual é possível ver que o texto-padrão de ambos os documentos é comum e que as diferenças entre as versões são mínimas. Portanto, aqui, o objetivo é identificar e rastrear as origens dos chunks de dados e suas permissões associadas para que as regras de acesso corretas possam ser aplicadas de forma consistente.
Figura: Exemplo de documentos semelhantes dos registros 10Q da Apple
Protegendo Dados no Nível do Chunk
Para abordar esses problemas, a Caber propôs uma solução para proteger dados no nível do chunk. Ela faz isso analisando os documentos ingeridos no banco de dados vetorial e construindo um índice paralelo para mapear as relações entre chunks e suas fontes. Esse grafo de linhagem fornece visibilidade sobre a origem de cada chunk e suas permissões associadas, permitindo a atribuição determinística de permissões.
Figura- A abordagem da Caber para proteger dados no nível do chunk
Figura: A abordagem da Caber para proteger dados no nível do chunk (Fonte)
Exemplo de Grafo de Linhagem com Arquivamentos 10Q da Apple
Continuando o exemplo da Apple, o grafo abaixo contém chunks de dados de múltiplas versões dos arquivamentos 10-Q da Apple. Os nós vermelhos no grafo representam os chunks de dados comuns entre todos os documentos. Usando uma política, as permissões para cada um desses chunks são determinadas. Essas permissões são então verificadas enquanto os dados estão sendo recuperados do banco de dados vetorial para garantir que os usuários tenham a autorização adequada para acessar esses chunks.
Figura: Mapeamento dinâmico da linhagem de cada chunk para permissões com Caber
Exemplo de Demo RAG com Arquivamentos 10Q da Apple
Inicialmente, os dados são armazenados no banco de dados vetorial como Milvus sem metadados de permissões. Quando os dados saem do RAG, a integração do Caber ao fluxo de trabalho por meio de um SDK permite a filtragem e a redação desses dados em um nível granular antes que possam ser passados para o LLM. Por exemplo, a figura demonstra a autorização de acesso para dois usuários diferentes - Amy, CFO da empresa, está autorizada a acessar todos os chunks de dados das demonstrações 10Q de 2023 e 2024. Em contraste, Bob, outro usuário, foi restrito ao mesmo acesso e recebe uma resposta genérica.
Figura: Exemplo de RAG demonstrando acesso variado para dois usuários
Integração do Caber com Fluxos de Trabalho de LLM e Suas Capacidades
Figura: Caber integra-se a fluxos de trabalho de LLM
O Caber pode ser integrado a fluxos de trabalho de LLM usando um SDK, permitindo o gerenciamento contínuo do controle de acesso. Por meio de conectores de identidade, o sistema recupera informações de autenticação do usuário, enquanto outros conectores ajudam a criar um índice de chunks de dados junto com suas permissões associadas. Por exemplo, quando um usuário interage com o sistema, o agente passa o prompt para o banco de dados vetorial. A resposta do RAG é então enviada aos LLMs, que fornecem a resposta final. Durante esse processo, os dados são rastreados com base em seu fluxo e todas as conexões serão atribuídas ao usuário específico.
Aqui, usar Milvus como banco de dados vetorial ajuda a suportar particionamento dinâmico e multilocação, tornando-o ideal para aplicações focadas em privacidade que exigem controle de acesso por chunk. Com recursos como indexação HNSW, ele garante consultas de alta velocidade em bilhões de vetores.
Responsabilidade e Auditabilidade
A rastreabilidade que o Caber fornece oferece capacidades críticas de responsabilidade e auditoria. Particularmente em cenários complexos envolvendo IA Agêntica, onde LLMs agem autonomamente em nome dos usuários, como as ações são bastante imprevisíveis, há uma alta chance de algo dar errado (por ex.: vazamento de dados sensíveis). Aqui, o conhecimento de como os dados se moveram por várias chamadas de API e de objetos é essencial para descobrir em qual etapa exata o sistema falhou.
Figura: Responsabilidade e Auditabilidade
Observabilidade Detalhada do Fluxo da Aplicação
O Caber também permite análise e depuração das ferramentas da aplicação por meio da observabilidade detalhada do fluxo da aplicação. A capacidade de rastrear quando e por quais serviços os dados do usuário foram acessados permite que as organizações identifiquem melhor gargalos, ineficiências e riscos de segurança dentro dos pipelines de dados da aplicação.
Figura: Observabilidade do Fluxo da Aplicação
Requisitos de Conformidade de Dados com a Política
Os insights obtidos acima podem ser realimentados nos LLMs para melhorar as políticas de segurança e abordar lacunas de forma proativa. O framework oferece suporte a controle de acesso, auditabilidade, remediação e análise, garantindo conformidade e aumentando a resiliência do sistema.
Data Compliance Requirements to Policy.png
Requisitos de Conformidade de Dados para Política (Fonte)
Conclusão
À medida que os casos de uso de aplicações de LLM crescem, mais empresas dependem de RAG para realizar suas tarefas. Portanto, proteger e gerenciar o acesso aos dados em um nível granular torna-se muito importante. Soluções como Caber, combinadas com os recursos avançados de particionamento e busca do Milvus, fornecem o framework ideal para enfrentar desafios como duplicação de dados e definição do controle de acesso para o uso seguro dos dados.
Recursos Relevantes
Continue lendo
Zilliz Cloud Just Landed in Claude Code
The Zilliz Cloud Plugin brings the full power of Zilliz Cloud directly into your Claude Code terminal as natural-language conversations.
How Zilliz Saw the Future of Vector Databases—and Built for Production
An inside look at how Zilliz built vector databases for real-world use, focusing on scalability, stability, and running them reliably at scale.
Vector Databases vs. Document Databases
Use a vector database for similarity search and AI-powered applications; use a document database for flexible schema and JSON-like data storage.