Criar uma solução segura de inferência RAG multilocatário
O RAG (Retrieval-Augmented Generation) é um padrão para criar aplicativos que usam modelos de base para a análise de informações proprietárias ou outros dados que não estão disponíveis publicamente na internet. Em geral, um aplicativo cliente chama uma camada de orquestração que busca informações relevantes de um armazenamento de dados, como um banco de dados vetor. 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. Cada cliente ou locatário consiste em vários usuários da mesma organização, empresa ou grupo. Em cenários multilocatário, é preciso garantir que os locatários, ou os indivíduos nos locatários, só possam incorporar dados de base que eles estão autorizados a acessar.
Em cenários multilocatário, as preocupações vão além de garantir que os usuários acessem somente as informações que estão autorizados a acessar. No entanto, este artigo se concentra nesse aspecto de multilocação. Este artigo começa com uma visão geral das arquiteturas RAG de único locatário. Ele discute os desafios que você pode encontrar na multilocação com RAG e algumas abordagens comuns a serem adotadas. Ele também descreve considerações e recomendações de multilocação para melhorar a segurança.
Nota
Este artigo descreve vários recursos específicos do Serviço OpenAI do Azure, como o recurso Azure OpenAI On Your Data. No entanto, você pode aplicar a maioria dos princípios descritos neste artigo a modelos fundamentais de IA em qualquer plataforma.
Arquitetura RAG de locatário único com um orquestrador
Fluxo de trabalho
Nessa arquitetura RAG de locatário único, um orquestrador busca dados proprietários relevantes dos armazenamentos e os fornece como dados de base para o modelo base. As etapas a seguir descrevem 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 repositório de dados apropriado para buscar dados de referência relevantes para a consulta. Os dados de base são adicionados ao prompt enviado ao modelo base, como 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, consulte Design e desenvolva uma solução RAG.
Arquitetura RAG de locatário único com acesso direto a dados
Essa variante da arquitetura RAG de locatário único usa o recurso On Your Data do OpenAI do Azure para se integrar diretamente a repositórios de dados, como a Pesquisa de IA do Azure. Nesta arquitetura, você não tem seu próprio orquestrador ou seu orquestrador tem menos responsabilidades. A API do OpenAI do Azure chama o armazenamento de dados para buscar os dados de base e passa esses dados ao modelo de linguagem. Esse método fornece menos controle sobre quais dados de base buscar e sobre a relevância desses dados.
Nota
O Azure OpenAI é gerenciado pela Microsoft. Ele se integra ao armazenamento de dados, mas o próprio modelo não se integra ao armazenamento de dados. O modelo recebe os dados de base da mesma maneira que quando um orquestrador busca os dados.
Fluxo de trabalho
Nessa arquitetura RAG, o serviço que fornece o modelo fundamental busca os dados de locatário proprietários apropriados nos armazenamentos de dados e usa esses dados como dados de base para o modelo fundamental. As etapas a seguir descrevem um fluxo de trabalho de alto nível. As etapas em itálico são idênticas na arquitetura RAG de locatário único anterior que tem um fluxo de trabalho de orquestrador.
- Um usuário emite uma solicitação para o aplicativo Web inteligente.
- Um provedor de identidade autentica o solicitante.
- O aplicativo inteligente chama o Azure OpenAI com a consulta do usuário.
- O OpenAI do Azure conecta-se aos armazenamentos de dados compatíveis, como a Pesquisa de IA e o Armazenamento de Blobs do Azure, para buscar os dados de base. Os dados de base são usados como parte do contexto quando o Azure OpenAI chama o modelo de linguagem OpenAI. Os resultados são retornados ao aplicativo inteligente.
Se você quiser usar essa arquitetura em uma solução multilocação, o serviço que acessa diretamente os dados de aterramento, como o Azure OpenAI, deverá dar suporte à lógica de multilocação que sua solução requer.
Multilocação na arquitetura RAG
Em soluções multilocatário, os dados de locatário devem estar em um repositório específico do locatário ou coexistir com outros locatários em um repositório multilocatário. Os dados também podem estar em um repositório compartilhado entre locatários. Somente os dados que o usuário está autorizado a acessar devem ser usados como dados de base. O usuário deve ver apenas dados comuns ou de todos os locatários ou dados de seu locatário filtrados para ajudar a garantir que ele veja apenas os dados que está autorizado a acessar.
Fluxo de trabalho
As etapas a seguir descrevem um fluxo de trabalho de alto nível. As etapas em itálico são idênticas no fluxo de dados da arquitetura RAG de locatário único com um orquestrador.
- 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 aciona os repositórios de dados apropriados para buscar dados de base relevantes para a consulta e autorizados pelo locatário. Os dados de base são adicionados ao prompt que é enviado para o OpenAI do Azure na próxima etapa. Algumas ou todas as seguintes etapas estão incluídas:
- A lógica de orquestração busca dados de base da instância apropriada de armazenamento de dados específica do locatário e potencialmente aplica 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 base do inquilino apropriado do armazenamento de dados multi-inquilino e potencialmente aplica 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 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
Considere as opções a seguir ao criar sua solução de inferência RAG multilocatário.
Escolher um modelo de isolamento do repositório
As duas principais abordagens arquitetônicas de armazenamento e dados em cenários multilocatário são repositórios por locatário e repositórios multilocatário. Essas abordagens se somam aos repositórios que contêm dados compartilhados entre inquilinos. Sua solução multilocatário pode usar uma combinação dessas abordagens.
Repositórios por locatário
Em lojas por locatário, cada locatário tem sua própria loja. As vantagens dessa abordagem incluem o isolamento de dados e de 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 de ruído de outros locatários. Essa abordagem também simplifica a alocação de custos porque todo o custo de uma implantação de repositório pode ser atribuído a um único locatário.
Essa abordagem pode apresentar desafios como aumento do gerenciamento e sobrecarga operacional e custos mais altos. Você não deve usar essa abordagem se tiver muitos locatários pequenos, como em cenários B2C. Essa abordagem também pode atingir ou exceder os limites de serviço.
No contexto desse cenário de IA, um repositório de armazenamento por locatário significa que os dados de base necessários para trazer relevância ao contexto provêm de um repositório de dados existente ou novo que contém apenas dados de base para o locatário. Nessa topologia, a instância do banco de dados é o discriminador usado para cada locatário.
Repositórios multilocatário
Em repositórios multilocatário, dados de vários 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 repositório por locatário e a menor sobrecarga de gerenciamento devido ao menor número de instâncias do repositório.
Entre os desafios do uso de repositórios compartilhados estão a necessidade de isolamento e gerenciamento de dados, o potencial para o anti padrão de ruído e a alocação de custos mais complexa para os locatários. O isolamento de dados é a preocupação mais importante quando você usa essa abordagem. Você precisa implementar abordagens seguras para ajudar a garantir que os locatários só possam acessar seus dados. O gerenciamento de dados também pode ser desafiador se os locatários tiverem ciclos de vida de dados diferentes que exigem operações, como a criação de índices em agendas diferentes.
Algumas plataformas têm recursos que você pode usar 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 de dados. É comum usar um identificador de locatário como uma chave de partição para fornecer algum isolamento entre locatários. O SQL do Azure e o Banco de Dados do Azure para PostgreSQL – Servidor Flexível dão suporte à segurança em nível de linha. No entanto, esses recursos normalmente não são usados em soluções de multilocação, porque é necessário projetar a solução em torno desses recursos se você planeja utilizá-los em seu ambiente de multilocação.
No contexto desse cenário de IA, os dados de base para todos os locatários são combinados no mesmo repositório de dados. Portanto, sua consulta para esse armazenamento de dados deve incluir um discriminador de locatário para ajudar a garantir que as respostas sejam restritas para trazer de volta apenas dados relevantes dentro do contexto do locatário.
Lojas compartilhadas
As soluções multilocatário geralmente compartilham dados entre locatários. Em uma solução multilocatário de exemplo para o domínio de saúde, um banco de dados pode armazenar informações médicas gerais ou informações que não sejam específicas para o locatário.
No contexto deste cenário de IA, o repositório de dados base é geralmente acessível e não necessita de filtragem com base em usuários específicos, pois os dados são relevantes e autorizados para todos os usuários no sistema.
Identidade
Identidade é um aspecto fundamental das soluções multilocatário, incluindo soluções RAG multilocatário. O aplicativo inteligente deve se integrar a um provedor de identidade para autenticar a identidade do usuário. A solução RAG multilocatário precisa de um diretório de identidade que armazene identidades autoritativas ou referências a identidades. Essa identidade precisa fluir pela cadeia de solicitações e permitir que serviços downstream, como o orquestrador ou o próprio armazenamento de dados, identifiquem o usuário.
Você também precisa de uma maneira de mapear um usuário para um inquilino para que você possa conceder acesso aos dados desse inquilino.
Definir os requisitos de locatário e autorização
Ao criar uma solução RAG multilocatário, você deve definir o que é um locatário para a solução. Os dois modelos comuns a serem escolhidos são modelos de negócios para empresas e de negócios para consumidores. O modelo escolhido ajuda você a determinar quais outros fatores você deve considerar ao criar sua solução. Entender o número de locatários é fundamental para escolher o modelo de armazenamento de dados. Um grande número de locatários pode exigir um modelo que tenha vários locatários para cada loja. Um número menor de locatários pode permitir um modelo de loja por locatário. A quantidade de dados para cada locatário também é importante. Locatários que têm grandes quantidades de dados podem impedir que você use repositórios multilocatários devido a limitações de tamanho no armazenamento de dados.
Se você pretende expandir uma carga de trabalho existente para dar suporte a esse cenário de IA, talvez já tenha tomado essa decisão. De modo geral, você pode 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ê planeja introduzir novos componentes, como um repositório dedicado para pesquisa vetorial ou um repositório dedicado para fundamentação, ainda será necessário tomar essa decisão. Considere fatores como a estratégia atual de selo de implantação, o impacto do plano de controle de 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ê precisa definir seus requisitos de autorização para dados. Os locatários acessam apenas dados do próprio locatário, mas 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 pacientes.
- 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 confidencialidade atribuídos aos 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 de dados
Restringir o acesso somente aos dados que os usuários estão autorizados a acessar é conhecido como filtragem ou filtragem de segurança. Em um cenário RAG multilocatário, um usuário deve ser mapeado para um repositório específico do locatário. Isso não significa que o usuário deve ser capaz de acessar todos os dados nesse repositório. Definir os requisitos de locatário e autorização discute a importância de definir os requisitos de autorização para seus dados. Você deve usar essas regras de autorização como base para filtragem.
Você pode usar recursos de plataforma de dados, como segurança em nível de linha, para implementar a filtragem. Ou talvez seja necessário lógica personalizada, dados ou metadados. Esses recursos de plataforma normalmente não são usados em soluções multilocatários porque você precisa projetar seu sistema em torno desses recursos.
Encapsular a lógica de dados multilocatário
Recomendamos que você tenha uma API na frente do mecanismo de armazenamento que você usa. A API atua como um gatekeeper que ajuda a garantir que os usuários tenham acesso apenas às informações que estão autorizadas a acessar.
O acesso dos usuários aos dados pode ser limitado por:
- O locatário do usuário.
- Recursos da plataforma.
- Regras de filtragem ou filtragem de segurança personalizadas.
A camada de API deve:
- Encaminhe a consulta para um repositório específico do locatário em um modelo de repositório por locatário.
- Selecione apenas os dados do locatário do usuário em repositórios multilocatário.
- Utilize a identidade apropriada de um usuário para dar suporte à lógica de autorização da plataforma.
- Aplique a lógica personalizada de filtragem de segurança.
- Armazene registros de acesso das informações de base 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 pela camada de API. Essa camada de API fornece um único ponto de governança ou segurança sobre seus dados de locatário. Essa abordagem impede que a lógica de autorização de acesso a dados do locatário e do usuário atinja outras áreas do aplicativo. Essa lógica é encapsulada na camada de API. Esse encapsulamento facilita a validação e o teste da solução.
Resumo
Ao criar uma solução de inferência RAG multilocatário, você deve considerar como projetar a solução de dados de base 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 criar sua solução de locação de dados. Recomendamos que você implemente uma camada de API que encapsula a lógica de acesso a dados, incluindo lógica multilocatário e lógica de filtragem.
Colaboradores
A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.
Autores principais:
- John Downs | Engenheiro de Software Principal
- Daniel Scott-Raynsford | Arquiteto Sênior de Soluções de Parceiro, Dados & IA
Para ver perfis não públicos do LinkedIn, entre no LinkedIn.