A Geração Aumentada de Recuperação (RAG) é 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ária é usada por vários clientes, onde cada cliente (locatário) consiste em vários usuários da mesma organização, empresa ou grupo. Em cenários multilocatário, você precisa garantir que os locatários, ou indivíduos dentro dos locatários, só possam incorporar dados de aterramento que eles 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 deveriam ver, este artigo se concentra nesse aspeto 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.
Nota
Este artigo discute alguns recursos específicos do Azure OpenAI, como o Azure OpenAI On Your Data. Dito isso, a maioria dos princípios discutidos neste documento se aplica à maioria dos modelos de IA fundamentais, independentemente de sua plataforma host.
Arquitetura RAG de locatário único com orquestrador
Figura 1. Arquitetura RAG de locatário único
Fluxo de Trabalho
Nessa arquitetura RAG de locatário único, um orquestrador tem a responsabilidade de buscar dados proprietários relevantes do locatário dos armazenamentos de dados e fornecê-los como dados de aterramento para o modelo fundamental. A seguir está 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 orchestrator 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 aterramento relevantes para a consulta. Os dados de aterramento são adicionados ao prompt que é enviado para o 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 devolvidos à aplicação 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 aos dados
Uma variante da arquitetura RAG de locatário único aproveita a capacidade do serviço Azure OpenAI de se integrar diretamente com armazenamentos de dados, como o Azure Search. Nessa arquitetura, ou você não tem seu próprio orquestrador, ou seu orquestrador tem menos responsabilidades. A API 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.
Nota
O serviço Azure OpenAI, gerido pela Microsoft, integra-se com o armazenamento de dados. O modelo em si não se integra com os 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 inquilino único com acesso direto a dados a partir do serviço Azure OpenAI
Fluxo de Trabalho
Nessa arquitetura RAG, o serviço que fornece o modelo fundamental tem a responsabilidade de buscar os dados proprietários apropriados do locatário dos armazenamentos de dados e usar esses dados como dados de aterramento para o modelo fundamental. A seguir está 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 Azure OpenAI com a consulta do usuário.
- O serviço Azure OpenAI liga-se a armazenamentos de dados suportados, como o Azure AI Search e o armazenamento de Blob do Azure para obter os dados de aterramento. Os dados de aterramento são usados como parte do contexto quando o serviço Azure OpenAI chama o modelo de linguagem OpenAI. Os resultados são devolvidos à aplicação 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ária exigida pela sua solução.
Multilocação na arquitetura RAG
Em soluções multilocatário, os dados do 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 uma loja que são compartilhados entre locatários. Somente os dados que o usuário está autorizado a ver devem ser usados como dados de aterramento. Os usuários só devem ver dados comuns (todos os locatário) 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
Fluxo de Trabalho
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 orchestrator 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 enviado ao Azure OpenAI na próxima etapa. Algumas ou todas as seguintes etapas 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 devolvidos à aplicação 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ário: lojas por locatário e multilocatário. Essas abordagens são adicionais aos armazenamentos que contêm dados compartilhados entre locatários. Esta secção aborda cada abordagem. Deve-se notar que sua solução multilocatária pode usar uma combinação dessas abordagens.
Loja por inquilino
Na loja por inquilino, 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 sua própria loja. Na maioria dos serviços de dados, as lojas isoladas 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, já que todo o custo de implantação de uma loja pode ser atribuído a um único locatário.
Os desafios dessa abordagem incluem potencialmente maior gerenciamento e despesas gerais de operação e custos mais altos. Essa abordagem não deve ser considerada quando há um grande número de pequenos locatários, 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 armazenamento por locatário significaria que os dados de aterramento necessários para trazer relevância para o 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árias
Em lojas multilocatário, vários dados de locatários coexistem no mesmo armazenamento. 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 loja.
Os desafios do uso de lojas compartilhadas 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 agendas diferentes.
Algumas plataformas têm recursos que você pode aproveitar ao implementar o isolamento de dados do locatário em lojas compartilhadas. 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 Azure SQL e o Postgres Flex oferecem suporte à segurança em nível de linha, embora esse recurso não seja comumente usado em soluções multilocatárias 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 para todos os locatários estão chegando no mesmo armazenamento de dados, de tal forma 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.
Lojas partilhadas
As soluções multilocatárias geralmente têm dados compartilhados entre locatários. Em um exemplo de solução multilocatária 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 do sistema.
Identidade
A identidade é um aspeto fundamental para soluções multilocatário, 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ária precisa de um diretório de identidade onde identidades autoritativas ou referências a identidades são armazenadas. Essa identidade precisa fluir através da 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 do 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 à escolha 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. Compreender 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, você pode já ter feito essa escolha. De um 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 atual de carimbo de implantação, o impacto do plano de controle do aplicativo e quaisquer diferenças no ciclo de vida dos 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 os dados. Embora os locatários acessem apenas os dados de seus locatários, seus requisitos de autorização podem ser mais granulares. Por exemplo, numa solução de cuidados de saúde pode ter regras como:
- Um doente só pode aceder aos seus próprios dados
- Um profissional de saúde pode aceder aos dados dos seus doentes
- Um utilizador financeiro só pode aceder a dados relacionados com finanças
- Um auditor clínico pode ver todos os dados dos doentes
- 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, convém restringir o acesso dos usuários a documentos com base em um esquema de marcação ou níveis de sensibilidade definidos 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 armazenamento 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. Estas regras de autorização devem ser utilizadas 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árias devido à necessidade de projetar seu sistema em torno desses recursos.
Encapsulando a lógica de dados multilocatários
É recomendável 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 só tenham acesso às informações às quais devem ter acesso.
Figura 4. Arquitetura RAG multilocatária com uma API encapsulando lógica de acesso a dados de locatário multilocatário
Como observado anteriormente neste artigo, o acesso do usuário aos dados pode ser limitado por:
- O locatário do usuário
- Funcionalidades de plataforma
- Regras personalizadas de filtragem/corte de segurança.
Esta camada deve ter as seguintes responsabilidades:
- Encaminhar a consulta para uma loja específica do locatário em um modelo de loja por locatário
- Selecionar apenas dados do locatário do usuário em repositórios multilocatários
- Usar a identidade apropriada para um usuário oferecer suporte à lógica de autorização habilitada para plataforma
- Impor lógica de filtragem de segurança personalizada
- Armazene logs de acesso de informações de aterramento para fins de auditoria
O código que precisa acessar os dados do locatário não deve ser capaz de consultar os repositórios de back-end diretamente. Todas as solicitações de dados devem fluir através dessa 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 evita que a lógica de autorização de acesso aos dados do locatário e do usuário sangre em diferentes áreas do aplicativo. Essa lógica é encapsulada na camada da 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. Estas informações ajudam-no a conceber a sua solução de arrendamento de dados. Recomendamos que você implemente uma camada de API que encapsula a lógica de acesso a dados, incluindo lógica multilocatária e lógica de filtragem.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
- John Downs - Brasil | Engenheiro de Software Principal
- Daniel Scott-Raynsford - Brasil | Arquiteto de Soluções de Parceiro Sênior, Dados e IA