A RG (Geração Aumentada por Recuperação) é um padrão para a criação de aplicativos em que modelos fundamentais são usados para raciocinar sobre informações proprietárias ou outras informações que não estão disponíveis publicamente na Internet. Geralmente, um aplicativo cliente chama uma camada de orquestração que busca informações relevantes de um armazenamento de dados, como um banco de dados vetorial. A camada de orquestração passa esses dados como parte do contexto como dados de aterramento para o modelo fundamental.
Uma solução multilocatário é usada por vários clientes, em que cada cliente (locatário) consiste em vários usuários da mesma organização, empresa ou grupo. Em cenários multilocatários, você precisa garantir que os locatários, ou indivíduos dentro de locatários, só possam incorporar dados de aterramento que estão autorizados a ver.
Embora existam preocupações multilocatárias além de garantir que os usuários acessem apenas as informações que devem ver, este artigo se concentra nesse aspecto da multilocação. O artigo começa com uma visão geral das arquiteturas RAG de locatário único, discute os desafios relacionados à multilocação com RAG e algumas abordagens comuns a serem seguidas e conclui com considerações e recomendações de multilocação segura.
Observação
Este artigo discute alguns recursos específicos do OpenAI do Azure, como o OpenAI do Azure em seus dados. Dito isso, a maioria dos princípios discutidos neste documento se aplica à maioria dos modelos fundamentais de IA, independentemente de sua plataforma de hospedagem.
Arquitetura RAG de locatário único com orquestrador
Figura 1. Arquitetura RAG de locatário único
Workflow
Nessa arquitetura RAG de locatário único, um orquestrador tem a responsabilidade de buscar dados de locatário proprietários relevantes dos armazenamentos de dados e fornecê-los como dados de base para o modelo fundamental. Veja a seguir um fluxo de trabalho de alto nível:
- Um usuário emite uma solicitação para o aplicativo Web inteligente.
- Um provedor de identidade autentica o solicitante.
- O aplicativo inteligente chama a API do orquestrador com a consulta do usuário e o token de autorização para o usuário.
- A lógica de orquestração extrai a consulta do usuário da solicitação e chama o armazenamento de dados apropriado para buscar dados de base relevantes para a consulta. Os dados de aterramento são adicionados ao prompt enviado ao modelo fundamental, por exemplo, um modelo exposto no Azure OpenAI, na próxima etapa.
- A lógica de orquestração se conecta à API de inferência do modelo fundamental e envia o prompt que inclui os dados de aterramento recuperados. Os resultados são retornados ao aplicativo inteligente.
Para obter mais informações sobre os detalhes do RAG, consulte Projetando e desenvolvendo uma solução RAG.
Arquitetura RAG de locatário único com acesso direto a dados
Uma variante da arquitetura RAG de locatário único aproveita a capacidade do serviço OpenAI do Azure de se integrar diretamente a armazenamentos de dados, como o Azure Search. Nessa arquitetura, você não tem seu próprio orquestrador ou seu orquestrador tem menos responsabilidades. A API do OpenAI do Azure tem a responsabilidade de chamar o armazenamento de dados para buscar os dados de aterramento e passar esses dados para o modelo de linguagem. Você, por sua vez, tem menos controle sobre quais dados de base buscar e a relevância desses dados.
Observação
O serviço OpenAI do Azure, gerenciado pela Microsoft, se integra ao armazenamento de dados. O modelo em si não se integra aos armazenamentos de dados. O modelo recebe dados de aterramento exatamente da mesma maneira que recebe se os dados forem buscados por um orquestrador.
Figura 2. Arquitetura RAG de locatário único com acesso direto a dados do serviço OpenAI do Azure
Workflow
Nessa arquitetura RAG, o serviço que fornece o modelo fundamental tem a responsabilidade de buscar os dados de locatário proprietários apropriados dos armazenamentos de dados e usar esses dados como dados de base para o modelo fundamental. Veja a seguir um fluxo de trabalho de alto nível (as etapas em itálico são idênticas à arquitetura RAG de locatário único com fluxo de trabalho do orquestrador):
- Um usuário emite uma solicitação para o aplicativo Web inteligente.
- Um provedor de identidade autentica o solicitante.
- Em seguida, o aplicativo inteligente chama o serviço OpenAI do Azure com a consulta do usuário.
- O serviço OpenAI do Azure se conecta a armazenamentos de dados com suporte, como Azure AI Search e Armazenamento de Blobs do Azure, para buscar os dados de aterramento. Os dados de aterramento são usados como parte do contexto quando o serviço OpenAI do Azure chama o modelo de linguagem OpenAI. Os resultados são retornados ao aplicativo inteligente.
Para considerar essa arquitetura em uma solução multilocatário, o serviço, como o Azure OpenAI, que está acessando diretamente os dados de aterramento deve dar suporte à lógica multilocatário exigida por sua solução.
Multilocação na arquitetura RAG
Em soluções multilocatário, os dados de locatário podem existir em um repositório específico do locatário ou coexistir com outros locatários em um repositório multilocatário. Também pode haver dados em um repositório que são compartilhados entre locatários. Somente os dados que o usuário está autorizado a ver devem ser usados como dados de base. Os usuários devem ver apenas dados comuns (todos os locatários) ou dados de seu locatário com regras de filtragem aplicadas para garantir que eles vejam apenas os dados que estão autorizados a ver.
Figura 3: Arquitetura RAG - com vários locatários de armazenamento de dados
Workflow
Esse fluxo de trabalho é o mesmo que na arquitetura RAG de locatário único com orquestrador , exceto a etapa 4.
- Um usuário emite uma solicitação para o aplicativo Web inteligente.
- Um provedor de identidade autentica o solicitante.
- O aplicativo inteligente chama a API do orquestrador com a consulta do usuário e o token de autorização para o usuário.
- A lógica de orquestração extrai a consulta do usuário da solicitação e chama os armazenamentos de dados apropriados para buscar dados de aterramento relevantes autorizados pelo locatário para a consulta. Os dados de aterramento são adicionados ao prompt que é enviado ao OpenAI do Azure na próxima etapa. Algumas ou todas as etapas a seguir estão envolvidas:
- A lógica de orquestração busca dados de aterramento da instância de armazenamento de dados específica do locatário apropriada, potencialmente aplicando regras de filtragem de segurança para retornar apenas os dados que o usuário está autorizado a acessar.
- A lógica de orquestração busca os dados de aterramento do locatário apropriado do armazenamento de dados multilocatário, potencialmente aplicando regras de filtragem de segurança para retornar apenas os dados que o usuário está autorizado a acessar.
- A lógica de orquestração busca dados de um armazenamento de dados que é compartilhado entre locatários.
- A lógica de orquestração se conecta à API de inferência do modelo fundamental e envia o prompt que inclui os dados de aterramento recuperados. Os resultados são retornados ao aplicativo inteligente.
Considerações de design para dados multilocatários no RAG
Escolhendo modelos de isolamento de loja
Há duas abordagens arquitetônicas principais para armazenamento e dados em cenários multilocatários: repositórios por locatário e multilocatários. Essas abordagens são adicionais aos repositórios que contêm dados compartilhados entre locatários. Esta seção aborda cada abordagem. Deve-se observar que sua solução multilocatário pode usar uma combinação dessas abordagens.
Loja por locatário
Na loja por locatário, como o nome sugere, cada locatário tem sua própria loja. As vantagens dessa abordagem incluem isolamento de dados e desempenho. Os dados de cada locatário são encapsulados em seu próprio repositório. Na maioria dos serviços de dados, os repositórios isolados não são suscetíveis ao problema do vizinho barulhento de outros locatários. Essa abordagem também simplifica a alocação de custos, pois todo o custo de uma implantação de loja pode ser atribuído a um único locatário.
Os desafios dessa abordagem incluem potencialmente maior sobrecarga de gerenciamento e operação e custo mais alto. Essa abordagem não deve ser considerada quando há um grande número de locatários pequenos, como cenários de empresa para consumidor. Essa abordagem também pode esbarrar nas limitações do serviço.
No contexto desse cenário de IA, um repositório por locatário significaria que os dados de aterramento necessários para trazer relevância ao contexto viriam de um armazenamento de dados existente ou novo que contém apenas dados de aterramento para o locatário. Nessa topologia, a instância do banco de dados é o discriminador usado por locatário.
Lojas multilocatários
Em repositórios multilocatários, vários dados de locatários coexistem no mesmo repositório. As vantagens dessa abordagem incluem o potencial de otimização de custos, a capacidade de lidar com um número maior de locatários do que o modelo de loja por locatário e menor sobrecarga de gerenciamento devido ao menor número de instâncias de armazenamento.
Os desafios do uso de repositórios compartilhados incluem a necessidade de garantir o isolamento de dados, o gerenciamento de dados, o potencial de antipadrão de vizinhos barulhentos e a dificuldade de alocar custos aos locatários. Garantir o isolamento de dados é a preocupação mais importante com essa abordagem. Você tem a responsabilidade de implementar a abordagem de segurança para garantir que os locatários só possam acessar seus dados. O gerenciamento de dados também pode ser um desafio se os locatários tiverem ciclos de vida de dados diferentes que podem exigir operações como a criação de índices em agendamentos diferentes.
Algumas plataformas têm recursos que você pode aproveitar ao implementar o isolamento de dados de locatário em repositórios compartilhados. Por exemplo, o Azure Cosmos DB tem suporte nativo para particionamento e fragmentação, e é comum usar um identificador de locatário como uma chave de partição para fornecer algum nível de isolamento entre locatários. O SQL do Azure e o Postgres Flex dão suporte à segurança em nível de linha, embora esse recurso não seja comumente usado em soluções multilocatário porque você precisa projetar sua solução em torno desses recursos se planeja usá-los em seu repositório multilocatário.
No contexto desse cenário de IA, isso significaria que os dados de aterramento de todos os locatários estão misturados no mesmo armazenamento de dados, de modo que sua consulta a esse armazenamento de dados deve conter um discriminador de locatário para garantir que as respostas sejam restritas para trazer de volta apenas dados relevantes dentro do contexto do locatário.
Repositórios compartilhados
As soluções multilocatário geralmente têm dados compartilhados entre locatários. Em um exemplo de solução multilocatário para o domínio de saúde, pode haver um banco de dados que armazena informações médicas gerais ou informações que não são específicas do locatário.
No contexto desse cenário de IA, esse seria um armazenamento de dados de aterramento geralmente acessível que não precisa especificamente de filtragem com base em nenhum locatário, pois os dados são relevantes e autorizados para todos os locatários no sistema.
Identidade
A identidade é um aspecto fundamental para soluções multilocatários, incluindo RAG multilocatário seguro. O aplicativo inteligente deve se integrar a um provedor de identidade (IdP) para autenticar a identidade do usuário. A solução RAG multilocatário precisa de um diretório de identidade em que identidades autoritativas ou referências a identidades são armazenadas. Essa identidade precisa fluir pela cadeia de solicitações, permitindo que serviços downstream, como o orquestrador ou até mesmo o próprio armazenamento de dados, identifiquem o usuário.
Você também precisa de um meio de mapear um usuário para um locatário para que possa conceder acesso a esses dados de locatário.
Defina seus requisitos de locatário e autorização
Ao criar uma solução RAG multilocatário, você deve definir o que é um locatário para sua solução. Os dois modelos comuns para escolher são business-to-business (B2B) e business-to-consumer (B2C). Essa determinação ajuda a informá-lo sobre as áreas que você deve considerar ao arquitetar sua solução. Entender o número de locatários é fundamental para decidir o modelo de armazenamento de dados. Um grande número de locatários pode exigir um modelo com vários locatários por loja, enquanto um número menor pode permitir um modelo de loja por locatário. A quantidade de dados por locatário também é importante. Se os locatários tiverem grandes quantidades de dados, isso pode impedir que você use repositórios multilocatários devido a limitações de tamanho no armazenamento de dados.
Em cargas de trabalho existentes que estão sendo expandidas para dar suporte a esse cenário de IA, talvez você já tenha feito essa escolha. De modo geral, você poderá usar sua topologia de armazenamento de dados existente para os dados de aterramento se esse armazenamento de dados puder fornecer relevância suficiente e atender a quaisquer outros requisitos não funcionais. No entanto, se você estiver introduzindo novos componentes, como um repositório de pesquisa vetorial dedicado como um repositório de aterramento dedicado, precisará tomar essa decisão, considerando fatores como sua estratégia de carimbo de implantação atual, o impacto do plano de controle do aplicativo e quaisquer diferenças no ciclo de vida de dados por locatário (como situações de pagamento por desempenho).
Depois de definir o que é um locatário para sua solução, você deve definir seus requisitos de autorização para dados. Embora os locatários acessem apenas dados de seu locatário, seus requisitos de autorização podem ser mais granulares. Por exemplo, em uma solução de saúde, você pode ter regras como:
- Um paciente só pode acessar seus próprios dados de paciente
- Um profissional de saúde pode acessar os dados de seus pacientes
- Um usuário financeiro pode acessar apenas dados relacionados a finanças
- Um auditor clínico pode ver todos os dados dos pacientes
- Todos os usuários podem acessar o conhecimento médico básico em um armazenamento de dados compartilhado
Em um aplicativo RAG baseado em documento, talvez você queira restringir o acesso dos usuários a documentos com base em um esquema de marcação ou níveis de sensibilidade configurados em documentos.
Depois de ter uma definição do que é um locatário e ter uma compreensão clara das regras de autorização, use essas informações como requisitos para sua solução de armazenamento de dados.
Filtragem
A filtragem, também conhecida como filtragem de segurança, refere-se à exposição apenas dos dados aos usuários que eles estão autorizados a ver. Em um cenário RAG multilocatário, um usuário pode ser mapeado para um repositório específico do locatário. Isso não significa que o usuário deva ser capaz de acessar todos os dados nesse armazenamento. Em Definir seus requisitos de locatário e autorização, discutimos a importância de definir os requisitos de autorização para seus dados. Essas regras de autorização devem ser usadas como base para a filtragem.
A filtragem pode ser realizada usando recursos de plataforma de dados, como segurança em nível de linha, ou pode exigir lógica, dados ou metadados personalizados. Novamente, esses recursos de plataforma não são comumente usados em soluções multilocatários devido à necessidade de projetar seu sistema em torno desses recursos.
Encapsulando a lógica de dados multilocatários
Recomenda-se ter uma API na frente de qualquer mecanismo de armazenamento que você esteja usando. A API atua como um gatekeeper, impondo que os usuários tenham acesso apenas às informações às quais devem ter acesso.
Figura 4. Arquitetura RAG multilocatário com uma API encapsulando a lógica de acesso a dados do locatário multilocatário
Conforme observado anteriormente neste artigo, o acesso do usuário aos dados pode ser limitado por:
- O locatário do usuário
- Recursos da plataforma
- Regras de filtragem/corte de segurança personalizadas.
Essa camada deve ter as seguintes responsabilidades:
- Rotear a consulta para um repositório específico do locatário em um modelo de repositório por locatário
- Selecione apenas dados do locatário do usuário em repositórios multilocatários
- Use a identidade apropriada para um usuário para dar suporte à lógica de autorização habilitada para plataforma
- Impor lógica de filtragem de segurança personalizada
- Armazene registros de acesso de informações de aterramento para fins de auditoria
O código que precisa acessar dados de locatário não deve ser capaz de consultar os repositórios de back-end diretamente. Todas as solicitações de dados devem fluir por essa camada de API. Essa camada de API fornece um único ponto de governança ou camada de segurança sobre os dados do locatário. Essa abordagem impede que a lógica de autorização de acesso a dados do locatário e do usuário se espalhe para diferentes áreas do aplicativo. Essa lógica é encapsulada na camada de API. Esse encapsulamento torna a solução mais fácil de validar e testar.
Resumo
Ao projetar uma solução de inferência RAG multilocatário, você deve levar em conta como arquitetar a solução de dados de aterramento para seus locatários. Entenda o número de locatários e a quantidade de dados por locatário que você armazena. Essas informações ajudam você a projetar sua solução de locação de dados. Recomendamos que você implemente uma camada de API que encapsule a lógica de acesso a dados, incluindo a lógica multilocatário e de filtragem.
Colaboradores
Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.
- John Downs | Engenheiro de software principal
- Daniel Scott-Raynsford | Arquiteto de Soluções de Parceiro Sênior, Dados e IA