Projetando RAG Multi-Tenant com Milvus: Melhores Práticas para Bases de Conhecimento Empresariais Escaláveis
Introdução
Nos últimos anos, Retrieval-Augmented Generation (RAG) surgiu como uma solução confiável para grandes organizações aprimorarem suas aplicações com tecnologia de LLM, especialmente aquelas com usuários diversos. À medida que essas aplicações crescem, implementar uma estrutura de multilocação torna-se essencial. Multilocação fornece acesso seguro e isolado aos dados para diferentes grupos de usuários, garantindo a confiança do usuário, atendendo a padrões regulatórios e melhorando a eficiência operacional.
Milvus é um banco de dados vetorial de código aberto criado para lidar com dados vetoriais de alta dimensionalidade. Ele é um componente de infraestrutura indispensável do RAG, armazenando e recuperando informações contextuais para LLMs a partir de fontes externas. Milvus oferece estratégias flexíveis de multilocação para diversas necessidades, incluindo multilocação em nível de banco de dados, em nível de coleção e em nível de partição.
Neste post, abordaremos:
O que é Multilocação e Por que Ela Importa
Estratégias de Multilocação no Milvus
Exemplo: Estratégia de Multilocação para uma Base de Conhecimento Empresarial com Tecnologia RAG
O que é Multilocação e Por que Ela Importa
Multilocação é uma arquitetura em que vários clientes ou equipes, conhecidos como "locatários," compartilham uma única instância de uma aplicação ou sistema. Os dados e as configurações de cada locatário são logicamente isolados, garantindo privacidade e segurança, enquanto todos os locatários compartilham a mesma infraestrutura subjacente.
Imagine uma plataforma SaaS que fornece soluções baseadas em conhecimento para várias empresas. Cada empresa é um locatário.
O Locatário A é uma organização de saúde que armazena FAQs voltadas para pacientes e documentos de conformidade.
O Locatário B é uma empresa de tecnologia que gerencia fluxos de trabalho internos de solução de problemas de TI.
O Locatário C é uma empresa de varejo com FAQs de atendimento ao cliente para devoluções de produtos.
Cada locatário opera em um ambiente completamente isolado, garantindo que nenhum dado do Locatário A vaze para o sistema do Locatário B ou vice-versa. Além disso, a alocação de recursos, o desempenho de consultas e as decisões de escalabilidade são específicos de cada locatário, garantindo alto desempenho independentemente de picos de carga de trabalho em um locatário.
A multilocação também funciona para sistemas que atendem diferentes equipes dentro da mesma organização. Imagine uma grande empresa usando uma base de conhecimento com tecnologia RAG para atender seus departamentos internos, como RH, Jurídico e Marketing. Cada departamento é um locatário com dados e recursos isolados nessa configuração.
A multilocação oferece benefícios significativos, incluindo eficiência de custos, escalabilidade e segurança robusta dos dados. Ao compartilhar uma única infraestrutura, os provedores de serviços podem reduzir custos gerais e garantir um consumo de recursos mais eficaz. Essa abordagem também escala sem esforço — integrar novos locatários exige muito menos recursos do que criar instâncias separadas para cada um, como nos modelos de locação única. É importante destacar que a multilocação mantém uma segurança robusta dos dados ao garantir isolamento rigoroso dos dados para cada locatário, com controles de acesso e criptografia protegendo informações confidenciais contra acesso não autorizado. Além disso, atualizações, patches e novos recursos podem ser implantados simultaneamente em todos os locatários, simplificando a manutenção do sistema e reduzindo a carga sobre os administradores, ao mesmo tempo em que garante que os padrões de segurança e conformidade sejam consistentemente mantidos.
Estratégias de Multilocação no Milvus
Para entender como o Milvus oferece suporte à multilocação, é importante primeiro observar como ele organiza os dados dos usuários.
Como o Milvus Organiza os Dados dos Usuários
O Milvus estrutura os dados em três camadas, movendo-se do amplo ao granular: Banco de dados, Coleção e Partição/Chave de partição.
Figure- How Milvus organizes user data .png
Figura: Como o Milvus organiza os dados do usuário
Banco de dados: Atua como um contêiner lógico, semelhante a um banco de dados em sistemas relacionais tradicionais.
Coleção: Comparável a uma tabela dentro de um banco de dados, uma coleção organiza os dados em grupos gerenciáveis.
Partição/Chave de partição: Dentro de uma coleção, os dados podem ser segmentados ainda mais por Partições. Usando uma Chave de partição, os dados com a mesma chave são agrupados. Por exemplo, se você usar um ID de usuário como a Chave de partição, todos os dados de um usuário específico serão armazenados no mesmo segmento lógico. Isso torna simples recuperar dados vinculados a usuários individuais.
À medida que você passa de Banco de dados para Coleção e para Chave de partição, a granularidade da organização dos dados torna-se progressivamente mais fina.
Para garantir maior segurança dos dados e controle de acesso adequado, o Milvus também fornece um robusto Controle de Acesso Baseado em Funções (RBAC), permitindo que administradores definam permissões específicas para cada usuário. Somente usuários autorizados podem acessar determinados dados.
O Milvus oferece suporte a várias estratégias para implementar multilocação, oferecendo flexibilidade com base nas necessidades da sua aplicação: multilocação em nível de banco de dados, em nível de coleção e em nível de partição.
Multilocação em Nível de Banco de Dados
Com a abordagem de multilocação em nível de banco de dados, cada locatário recebe seu próprio banco de dados dentro do mesmo cluster Milvus. Essa estratégia fornece forte isolamento de dados e garante desempenho ideal de busca. No entanto, pode levar à utilização ineficiente de recursos se determinados locatários permanecerem inativos.
Multilocação em Nível de Coleção
Aqui, na multilocação em nível de coleção, podemos organizar os dados dos locatários de duas maneiras.
Uma Coleção para Todos os Locatários: Todos os locatários compartilham uma única coleção, com campos específicos do locatário usados para filtragem. Embora seja simples de implementar, essa abordagem pode encontrar gargalos de desempenho à medida que o número de locatários aumenta.
Uma Coleção por Locatário: Cada locatário pode ter uma coleção dedicada, melhorando o isolamento e o desempenho, mas exigindo mais recursos. Essa configuração pode enfrentar limitações de escalabilidade se o número de locatários exceder a capacidade de coleções do Milvus.
Multilocação em Nível de Partição
A Multilocação em Nível de Partição concentra-se em organizar locatários dentro de uma única coleção. Aqui, também temos duas maneiras de organizar os dados dos locatários.
Uma Partição por Locatário: Os locatários compartilham uma coleção, mas seus dados são armazenados em partições separadas. Podemos isolar os dados atribuindo a cada locatário uma partição dedicada, equilibrando isolamento e desempenho de busca. No entanto, essa abordagem é limitada pelo limite máximo de partições do Milvus.
Multilocação Baseada em Chave de Partição: Esta é uma opção mais escalável, na qual uma única coleção usa chaves de partição para distinguir locatários. Esse método simplifica o gerenciamento de recursos e oferece suporte a maior escalabilidade, mas não oferece suporte a inserções de dados em massa.
A tabela abaixo resume as principais diferenças entre as principais abordagens de multilocação.
| Granularidade | Nível de banco de dados | Nível de coleção | Nível de chave de partição |
|---|---|---|---|
| Máx. de locatários suportados | ~1.000 | ~10.000 | ~10.000.000 |
| Flexibilidade de organização dos dados | Alta: Os usuários podem definir várias coleções com esquemas personalizados. | Média: Os usuários são limitados a uma coleção com um esquema personalizado. | Baixa: Todos os usuários compartilham uma coleção, exigindo um esquema consistente. |
| Custo por usuário | Alto | Médio | Baixo |
| Isolamento de recursos físicos | Sim | Sim | Não |
| RBAC | Sim | Sim | Não |
| Desempenho de busca | Forte | Médio | Forte |
Exemplo: Estratégia de multilocação para uma base de conhecimento empresarial com tecnologia RAG
Ao projetar a estratégia de multilocação para um sistema RAG, é essencial alinhar sua abordagem às necessidades específicas da sua empresa e dos seus locatários. O Milvus oferece várias estratégias de multilocação, e escolher a correta depende do número de locatários, de seus requisitos e do nível de isolamento de dados necessário. Aqui está um guia prático para tomar essas decisões, usando como exemplo uma base de conhecimento empresarial com tecnologia RAG.
Entendendo a estrutura dos locatários antes de escolher uma estratégia de multilocação
Uma base de conhecimento empresarial com tecnologia RAG geralmente atende a um pequeno número de locatários. Esses locatários geralmente são unidades de negócio independentes, como TI, Vendas, Jurídico e Marketing, cada uma exigindo serviços distintos de base de conhecimento. Por exemplo, o Departamento de RH gerencia informações confidenciais de funcionários, como guias de integração e políticas de benefícios, que devem ser confidenciais e acessíveis apenas ao pessoal de RH.
Nesse caso, cada unidade de negócio deve ser tratada como um locatário separado, e uma estratégia de multilocação em nível de banco de dados costuma ser a mais adequada. Ao atribuir bancos de dados dedicados a cada locatário, as organizações podem alcançar um forte isolamento lógico, simplificando a gestão e aumentando a segurança. Essa configuração oferece aos locatários flexibilidade significativa — eles podem definir modelos de dados personalizados dentro de coleções, criar quantas coleções forem necessárias e gerenciar de forma independente o controle de acesso às suas coleções.
Aprimorando a segurança com isolamento de recursos físicos
Em situações em que a segurança dos dados é altamente priorizada, o isolamento lógico no nível do banco de dados pode não ser suficiente. Por exemplo, algumas unidades de negócio podem lidar com dados críticos ou altamente confidenciais, exigindo garantias mais fortes contra interferência de outros locatários. Nesses casos, podemos implementar uma abordagem de isolamento físico sobre uma estrutura de multilocação em nível de banco de dados.
O Milvus nos permite mapear componentes lógicos, como bancos de dados e coleções, para recursos físicos. Esse método garante que as atividades de outros tenants não afetem operações críticas. Vamos explorar como essa abordagem funciona na prática.
Figure- How Milvus manages physical resources.png
Figura: Como o Milvus gerencia recursos físicos
Como mostrado no diagrama acima, há três camadas de gerenciamento de recursos no Milvus: Query Node, Resource Group e Database.
Query Node: O componente que processa tarefas de consulta. Ele é executado em uma máquina física ou contêiner (por exemplo, um pod no Kubernetes).
Resource Group: Uma coleção de Query Nodes que atua como uma ponte entre componentes lógicos (bancos de dados e coleções) e recursos físicos. Você pode alocar um ou mais bancos de dados ou coleções a um único Resource Group.
No exemplo mostrado no diagrama acima, há três Databases lógicos: X, Y e Z.
Database X: Contém a Collection A.
Database Y: Contém as Collections B e C.
Database Z: Contém as Collections D e E.
Digamos que o Database X contenha uma base de conhecimento crítica que não queremos que seja afetada pela carga do Database Y ou do Database Z. Para garantir o isolamento dos dados:
O Database X recebe seu próprio Resource Group para garantir que sua base de conhecimento crítica não seja afetada por cargas de trabalho de outros bancos de dados.
A Collection E também é alocada a um Resource Group separado dentro de seu banco de dados pai (Z). Isso proporciona isolamento no nível da coleção para dados críticos específicos dentro de um banco de dados compartilhado.
Enquanto isso, as coleções restantes nos Databases Y e Z compartilham os recursos físicos do Resource Group 2.
Ao mapear cuidadosamente componentes lógicos para recursos físicos, as organizações podem alcançar uma arquitetura multi-tenant flexível, escalável e segura, adaptada às suas necessidades de negócios específicas.
Projetando acesso no nível do usuário final
Agora que aprendemos as melhores práticas para escolher uma estratégia multi-tenant para um RAG empresarial, vamos explorar como projetar o acesso no nível do usuário em tais sistemas.
Nesses sistemas, os usuários finais geralmente interagem com a base de conhecimento em modo somente leitura por meio de LLMs. No entanto, as organizações ainda precisam rastrear esses dados de perguntas e respostas gerados pelos usuários e vinculá-los a usuários específicos para diversos fins, como melhorar a precisão da base de conhecimento ou oferecer serviços personalizados.
Tomemos como exemplo o balcão de atendimento de consulta inteligente de um hospital. Os pacientes podem fazer perguntas como: “Há algum horário disponível com o especialista hoje?” ou "É necessária alguma preparação específica para minha próxima cirurgia?" Embora essas perguntas não afetem diretamente a base de conhecimento, é importante que o hospital rastreie essas interações para melhorar os serviços. Esses pares de perguntas e respostas geralmente são armazenados em um banco de dados separado (não precisa necessariamente ser um banco de dados vetorial) dedicado ao registro de interações.
Figure- The multi-tenancy architecture for an enterprise RAG knowledge base .png
Figura: A arquitetura multi-tenant para uma base de conhecimento RAG empresarial
O diagrama acima mostra a arquitetura multi-tenant de um sistema RAG empresarial.
System Administrators supervisionam o sistema RAG, gerenciam a alocação de recursos, atribuem bancos de dados, mapeiam-nos para grupos de recursos e garantem a escalabilidade. Eles cuidam da infraestrutura física, como mostrado no diagrama, onde cada grupo de recursos (por exemplo, Resource Group 1, 2 e 3) é mapeado para servidores físicos (query nodes).
Locatários (proprietários e desenvolvedores de bancos de dados) gerenciam a base de conhecimento, iterando sobre ela com base nos dados de perguntas e respostas gerados pelos usuários, conforme mostrado no diagrama. Diferentes bancos de dados (Banco de Dados X, Y, Z) contêm coleções com diferentes conteúdos da base de conhecimento (Coleção A, B, etc.).
Usuários finais interagem com o sistema de forma somente leitura por meio do LLM. À medida que consultam o sistema, suas perguntas são registradas na tabela separada de registros de perguntas e respostas (um banco de dados separado), alimentando continuamente o sistema com dados valiosos.
Esse design garante que cada camada de processo — da interação do usuário à administração do sistema — funcione perfeitamente, ajudando a organização a construir uma base de conhecimento robusta e em melhoria contínua.
Resumo
Neste blog, exploramos como frameworks de multi-tenancy desempenham um papel crítico na escalabilidade, segurança e desempenho de bases de conhecimento impulsionadas por RAG. Ao isolar dados e recursos para diferentes locatários, as empresas podem garantir privacidade, conformidade regulatória e alocação otimizada de recursos em uma infraestrutura compartilhada. Milvus, com suas estratégias flexíveis de multi-tenancy, permite que as empresas escolham o nível certo de isolamento de dados — do nível do banco de dados ao nível da partição — dependendo de suas necessidades específicas. Escolher a abordagem certa de multi-tenancy garante que as empresas possam fornecer serviços personalizados aos locatários, mesmo ao lidar com dados e cargas de trabalho diversos.
Seguindo as melhores práticas descritas aqui, as organizações podem projetar e gerenciar efetivamente sistemas RAG multi-tenant que não apenas oferecem experiências superiores aos usuários, mas também escalam sem esforço à medida que as necessidades de negócios crescem. A arquitetura do Milvus garante que as empresas possam manter altos níveis de isolamento, segurança e desempenho, tornando-o um componente crucial na construção de bases de conhecimento de nível empresarial impulsionadas por RAG.
Fique atento para mais insights sobre RAG multi-tenant
Neste blog, discutimos como as estratégias de multi-tenancy do Milvus são projetadas para gerenciar locatários, mas não usuários finais dentro desses locatários. As interações dos usuários finais geralmente acontecem na camada da aplicação, enquanto o próprio banco de dados vetorial permanece inconsciente desses usuários.
Você pode estar se perguntando: Se eu quiser fornecer respostas mais precisas com base no histórico de consultas de cada usuário final, o Milvus não precisa manter um contexto personalizado de perguntas e respostas para cada usuário?
Essa é uma ótima pergunta, e a resposta realmente depende do caso de uso. Por exemplo, em um serviço de consultoria sob demanda, as consultas são aleatórias, e o foco principal está na qualidade da base de conhecimento, e não em acompanhar o contexto histórico de um usuário.
No entanto, em outros casos, os sistemas RAG devem ser sensíveis ao contexto. Quando isso é necessário, o Milvus precisa colaborar com a camada da aplicação para manter uma memória personalizada do contexto de cada usuário. Esse design é especialmente importante para aplicações com um grande número de usuários finais, o que exploraremos em mais detalhes no meu próximo post. Fique atento para mais insights!
Continue lendo
Vector Lakebase: End the AI Data Silo
Learn how Vector Lakebase unifies vector search, data lakes, and AI data operations so teams can serve RAG and agents without copy-and-sync pipelines.
How to Build an Enterprise-Ready RAG Pipeline on AWS with Bedrock, Zilliz Cloud, and LangChain
Build production-ready enterprise RAG with AWS Bedrock, Nova models, Zilliz Cloud, and LangChain. Complete tutorial with deployable code.
How to Build RAG with Milvus, QwQ-32B and Ollama
Hands-on tutorial on how to create a streamlined, powerful RAG pipeline that balances efficiency, accuracy, and scalability using the QwQ-32B and Milvus.