Conceção de RAG multi-tenancy com Milvus: Melhores práticas para bases de conhecimento empresariais escaláveis

Introdução

Nos últimos anos, o Retrieval-Augmented Generation (RAG) surgiu como uma solução fiável para as grandes organizações melhorarem as suas aplicações baseadas em LLM, especialmente as que têm diversos utilizadores. À medida que essas aplicações crescem, a implementação de uma estrutura de aluguer múltiplo torna-se essencial. O multi-tenancy fornece acesso seguro e isolado aos dados para diferentes grupos de utilizadores, garantindo a confiança dos utilizadores, cumprindo as normas regulamentares e melhorando a eficiência operacional.

O Milvus é uma base de dados vetorial de código aberto criada para tratar dados vectoriais de elevada dimensão. É um componente de infraestrutura indispensável do RAG, que armazena e recupera informações contextuais de fontes externas para os LLM. O Milvus oferece estratégias flexíveis de multi-tenancy para várias necessidades, incluindo multi-tenancy ao nível da base de dados, ao nível da coleção e ao nível da partição.

Neste post, abordaremos:

• O que é multitenancy e por que é importante

• Estratégias de multilocação no Milvus

• Exemplo: Estratégia de multilocação para uma base de conhecimento empresarial alimentada por RAG

O que é Multi-Tenancy e porque é importante

Multi-tenancy é uma arquitetura em que vários clientes ou equipas, conhecidos como "inquilinos", partilham uma única instância de uma aplicação ou sistema. Os dados e as configurações de cada inquilino são isolados logicamente, garantindo a privacidade e a segurança, enquanto todos os inquilinos partilham a mesma infraestrutura subjacente.

Imagine uma plataforma SaaS que fornece soluções baseadas no conhecimento a várias empresas. Cada empresa é um inquilino.

• O inquilino A é uma organização de cuidados de saúde que armazena FAQs viradas para o paciente e documentos de conformidade.

• O inquilino B é uma empresa de tecnologia que gere fluxos de trabalho internos de resolução de problemas de TI.

• O inquilino C é uma empresa de retalho com FAQs de serviço ao cliente para devoluções de produtos.

Cada inquilino opera num ambiente completamente isolado, garantindo que nenhum dado do inquilino A entra no sistema do inquilino B ou vice-versa. Além disso, a atribuição de recursos, o desempenho das consultas e as decisões de escalonamento são específicos de cada locatário, garantindo um elevado desempenho, independentemente dos picos de carga de trabalho num locatário.

O multi-tenancy também funciona para sistemas que servem diferentes equipas dentro da mesma organização. Imagine uma grande empresa que utiliza uma base de conhecimentos alimentada por RAG para servir os seus departamentos internos, tais como RH, Jurídico e Marketing. Nesta configuração, cada departamento é um inquilino com dados e recursos isolados.

O multilocatário oferece vantagens significativas, incluindo eficiência de custos, escalabilidade e segurança de dados robusta. Ao partilhar uma única infraestrutura, os fornecedores de serviços podem reduzir os custos gerais e garantir um consumo de recursos mais eficaz. Esta abordagem também pode ser escalada sem esforço - a integração de novos inquilinos requer muito menos recursos do que a criação de instâncias separadas para cada um, como acontece com os modelos de inquilinato único. É importante salientar que o multilocatário mantém uma segurança de dados robusta, assegurando um isolamento rigoroso dos dados para cada locatário, com controlos de acesso e encriptação que protegem as informações sensíveis contra o acesso não autorizado. Além disso, as actualizações, os patches e as novas funcionalidades podem ser implementados em todos os inquilinos em simultâneo, simplificando a manutenção do sistema e reduzindo a carga sobre os administradores, ao mesmo tempo que garante que as normas de segurança e conformidade são consistentemente respeitadas.

Estratégias multi-inquilino em Milvus

Para compreender como o Milvus suporta o multi-tenancy, é importante olhar primeiro para a forma como organiza os dados do utilizador.

Como o Milvus organiza os dados do utilizador

O Milvus estrutura os dados em três camadas, indo do mais amplo ao mais granular: Base de dados, coleção e partição/chave de partição.

Figura- Como o Milvus organiza os dados do utilizador .png

Figura: Como o Milvus organiza os dados do utilizador

• Base de dados: Funciona como um contentor lógico, semelhante a uma base de dados nos sistemas relacionais tradicionais.

• Coleção: Comparável a uma tabela numa base de dados, uma coleção organiza os dados em grupos geríveis.

• Partição/chave de partição: Dentro de uma coleção, os dados podem ser ainda mais segmentados por Partições. Utilizando uma Chave de partição, os dados com a mesma chave são agrupados. Por exemplo, se utilizar um ID de utilizador como chave de partição, todos os dados de um utilizador específico serão armazenados no mesmo segmento lógico. Isto torna simples a recuperação de dados associados a utilizadores individuais.

À medida que passa da Base de dados para a Coleção e para a Chave de partição, a granularidade da organização dos dados torna-se progressivamente mais fina.

Para garantir uma maior segurança dos dados e um controlo de acesso adequado, o Milvus também fornece um Controlo de Acesso Baseado em Funções (RBAC) robusto, permitindo aos administradores definir permissões específicas para cada utilizador. Apenas os utilizadores autorizados podem aceder a determinados dados.

Milvus suporta múltiplas estratégias para implementar multi-tenancy, oferecendo flexibilidade baseada nas necessidades da sua aplicação: multi-tenancy ao nível da base de dados, ao nível da coleção e ao nível da partição.

Multitenancy ao nível da base de dados

Com a abordagem de multi-tenancy ao nível da base de dados, a cada inquilino é atribuída a sua própria base de dados dentro do mesmo cluster Milvus. Esta estratégia fornece um forte isolamento de dados e garante um desempenho de pesquisa ótimo. No entanto, pode levar a uma utilização ineficiente dos recursos se alguns inquilinos permanecerem inactivos.

Multitenancy ao nível da coleção

Aqui, no multilocatário ao nível da coleção, podemos organizar os dados para os locatários de duas formas.

• 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 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. Esta configuração pode enfrentar limitações de escalabilidade se o número de inquilinos exceder a capacidade de recolha do Milvus.

Multi-Tenancy a nível de partição

O Multi-Tenancy ao nível da partição centra-se na organização dos inquilinos dentro de uma única coleção. Aqui, também temos duas maneiras de organizar os dados do locatário.

• 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 o isolamento e o desempenho da pesquisa. No entanto, esta abordagem é restringida pelo limite máximo de partições do Milvus.

• Multitenancy baseado em chave de partição: Esta é uma opção mais escalável em que uma única coleção utiliza chaves de partição para distinguir os inquilinos. Este método simplifica a gestão de recursos e suporta uma maior escalabilidade, mas não suporta 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 base de dados	Nível de coleção	Nível de chave de partição
Máximo de inquilinos suportados	~1,000	~10,000	~10,000,000
Flexibilidade de organização de dados	Alta: Os utilizadores podem definir várias colecções com esquemas personalizados.	Média: Os utilizadores estão limitados a uma coleção com um esquema personalizado.	Baixa: Todos os utilizadores partilham uma coleção, o que exige um esquema consistente.
Custo por utilizador	Alto	Médio	Baixo
Isolamento de recursos físicos	Sim	Sim	Não
RBAC	Sim	Sim	Não
Desempenho da pesquisa	Forte	Médio	Forte

Exemplo: Estratégia multi-tenancy para uma base de dados de conhecimento empresarial com tecnologia RAG

Ao conceber a estratégia multi-tenancy para um sistema RAG, é essencial alinhar a sua abordagem com as necessidades específicas da sua empresa e dos seus inquilinos. A Milvus oferece várias estratégias multi-tenancy, e a escolha da mais adequada depende do número de utilizadores, dos seus requisitos e do nível de isolamento de dados necessário. Aqui está um guia prático para tomar estas decisões, tomando como exemplo uma base de conhecimentos empresarial alimentada por RAG.

Compreender a estrutura dos inquilinos antes de escolher uma estratégia para vários inquilinos

Uma base de conhecimentos empresarial alimentada por RAG serve frequentemente um pequeno número de inquilinos. Esses locatários são geralmente unidades de negócios independentes, como TI, Vendas, Jurídico e Marketing, cada uma exigindo serviços de base de conhecimento distintos. Por exemplo, o departamento de RH gere informações sensíveis dos 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.

Neste caso, cada unidade de negócio deve ser tratada como um inquilino separado e uma estratégia de multi-tenancy ao nível da base de dados é frequentemente a mais adequada. Ao atribuir bases de dados dedicadas a cada locatário, as organizações podem obter um forte isolamento lógico, simplificando a gestão e melhorando a segurança. Esta configuração proporciona aos locatários uma flexibilidade significativa - podem definir modelos de dados personalizados nas colecções, criar tantas colecções quantas as necessárias e gerir de forma independente o controlo de acesso às suas colecções.

Melhorar a segurança com isolamento físico de recursos

Em situações em que a segurança dos dados é altamente prioritária, o isolamento lógico no nível do banco de dados pode não ser suficiente. Por exemplo, algumas unidades de negócios podem lidar com dados críticos ou altamente sensíveis, exigindo garantias mais fortes contra a interferência de outros locatários. Nestes casos, podemos implementar uma abordagem de isolamento físico em cima de uma estrutura multi-tenancy ao nível da base de dados.

O Milvus permite-nos mapear componentes lógicos, tais como bases de dados e colecções, para recursos físicos. Este método garante que as actividades de outros inquilinos não têm impacto nas operações críticas. Vamos explorar como esta abordagem funciona na prática.

Figura - Como o Milvus gere os recursos físicos.png

Figura: Como Milvus gere os recursos físicos

Como se pode ver no diagrama acima, existem três camadas de gestão de recursos em Milvus: Query Node (nó de consulta), Resource Group (grupo de recursos) e Database (base de dados).

• Nó de consulta: O componente que processa as tarefas de consulta. Ele é executado em uma máquina física ou contêiner (por exemplo, um pod no Kubernetes).

• Grupo de recursos: Uma coleção de nós de consulta 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 Grupo de Recursos.

No exemplo apresentado no diagrama acima, existem três bases de dados lógicas: X, Y e Z.

• Base de dados X: contém a coleção A.

• Base de dados Y: contém as colecções B e C.

• Base de dados Z: Contém as colecções D e E.

Digamos que a Base de Dados X contém uma base de conhecimentos crítica que não queremos que seja afetada pela carga da Base de Dados Y ou da Base de Dados Z. Para garantir o isolamento dos dados:

• À base dedados X é atribuído o seu próprio grupo de recursos para garantir que a sua base de conhecimentos crítica não é afetada pelas cargas de trabalho de outras bases de dados.

• A coleção E também é atribuída a um grupo de recursos separado na sua base de dados principal(Z). Isto proporciona isolamento ao nível da coleção para dados críticos específicos dentro de uma base de dados partilhada.

Entretanto, as restantes colecções das bases de dados Y e Z partilham os recursos físicos do Grupo de Recursos 2.

Ao mapear cuidadosamente os componentes lógicos para os recursos físicos, as organizações podem obter uma arquitetura multi-tenancy flexível, escalável e segura, adaptada às suas necessidades comerciais específicas.

Conceber o acesso ao nível do utilizador final

Agora que aprendemos as melhores práticas para escolher uma estratégia de multilocação para um RAG empresarial, vamos explorar como conceber o acesso ao nível do utilizador nesses sistemas.

Nestes sistemas, os utilizadores finais interagem normalmente com a base de conhecimentos em modo só de leitura através de LLMs. No entanto, as organizações continuam a necessitar de controlar esses dados de P&R gerados pelos utilizadores e associá-los a utilizadores específicos para vários fins, tais como melhorar a precisão da base de conhecimentos ou oferecer serviços personalizados.

Tomemos como exemplo o balcão do serviço de consulta inteligente de um hospital. Os pacientes podem fazer perguntas como: "Há alguma consulta disponível com o especialista hoje?" ou "É necessária alguma preparação específica para a minha próxima cirurgia?" Embora estas perguntas não tenham um impacto direto na base de conhecimentos, é importante que o hospital acompanhe estas interações para melhorar os serviços. Estes pares de perguntas e respostas são normalmente armazenados numa base de dados separada (não tem necessariamente de ser uma base de dados vetorial) dedicada ao registo de interações.

Figura - A arquitetura multi-tenancy para uma base de conhecimentos RAG empresarial .png

Figura: A arquitetura multi-tenancy para uma base de conhecimentos RAG empresarial

O diagrama acima mostra a arquitetura multi-tenancy de um sistema RAG empresarial.

• Os administradores de sistemas supervisionam o sistema RAG, gerem a atribuição de recursos, atribuem bases de dados, mapeiam-nas para grupos de recursos e asseguram a escalabilidade. Tratam da infraestrutura física, como se mostra no diagrama, onde cada grupo de recursos (por exemplo, Grupo de Recursos 1, 2 e 3) é mapeado para servidores físicos (nós de consulta).

• Os inquilinos (proprietários e programadores de bases de dados) gerem a base de conhecimentos, iterando-a com base nos dados de perguntas e respostas gerados pelos utilizadores, como se mostra no diagrama. Diferentes bases de dados (base de dados X, Y, Z) contêm colecções com diferentes conteúdos da base de conhecimentos (coleção A, B, etc.).

• Os utilizadores finais interagem com o sistema de uma forma só de leitura através do LLM. À medida que consultam o sistema, as suas perguntas são registadas na tabela de registo de P&R (uma base de dados separada), alimentando continuamente o sistema com dados valiosos.

Esta conceção assegura que cada camada do processo - desde a interação com o utilizador até à administração do sistema - funciona sem problemas, ajudando a organização a construir uma base de conhecimentos robusta e em constante melhoria.

Resumo

Neste blogue, explorámos a forma como as estruturas multi-tenancy desempenham um papel fundamental na escalabilidade, segurança e desempenho das bases de dados de conhecimento alimentadas por RAG. Ao isolar dados e recursos para diferentes inquilinos, as empresas podem garantir a privacidade, a conformidade regulamentar e a alocação optimizada de recursos numa infraestrutura partilhada. O Milvus, com suas estratégias flexíveis de multilocação, permite que as empresas escolham o nível certo de isolamento de dados - do nível de banco de dados ao nível de partição - dependendo de suas necessidades específicas. A escolha da abordagem multi-tenancy correta garante que as empresas podem fornecer serviços personalizados aos inquilinos, mesmo quando lidam com dados e cargas de trabalho diferentes.

Seguindo as práticas recomendadas aqui descritas, as organizações podem conceber e gerir eficazmente sistemas RAG multi-tenancy que não só proporcionam experiências de utilizador superiores, como também podem ser escalados sem esforço à medida que as necessidades da empresa 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 criação de bases de conhecimento de nível empresarial, alimentadas por RAG.

Fique atento a mais informações sobre o RAG multilocatário

Neste blogue, discutimos como as estratégias de multilocação da Milvus foram concebidas para gerir os inquilinos, mas não os utilizadores finais dentro desses inquilinos. As interações com o utilizador final ocorrem normalmente na camada da aplicação, enquanto a própria base de dados vetorial não tem conhecimento desses utilizadores.

Poderá estar a perguntar-se: Se eu quiser fornecer respostas mais precisas com base no histórico de consultas de cada utilizador final, o Milvus não precisa de manter um contexto de P&R personalizado para cada utilizador?

Essa é uma ótima pergunta, e a resposta realmente depende do caso de uso. Por exemplo, num serviço de consulta a pedido, as consultas são aleatórias e o principal objetivo é a qualidade da base de conhecimentos e não o acompanhamento do contexto histórico de um utilizador.

No entanto, noutros casos, os sistemas RAG devem ser sensíveis ao contexto. Quando isto é necessário, o Milvus tem de colaborar com a camada de aplicação para manter uma memória personalizada do contexto de cada utilizador. Este design é especialmente importante para aplicações com utilizadores finais massivos, que iremos explorar em maior detalhe no meu próximo post. Fique atento para mais informações!