Projetar uma solução segura de inferência RAG multilocatária
Retrieval-Augmented Generation (RAG) é um padrão para a criação de aplicativos que usam modelos de base para raciocinar sobre informações proprietárias ou outros dados 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 base, para o modelo fundamental.
Uma solução multilocatária é 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 multicliente, é necessário garantir que os inquilinos, ou indivíduos dentro dos inquilinos, só possam incorporar dados de referência que eles estão autorizados a acessar.
Há preocupações multilocatárias além de garantir que os usuários acessem apenas as informações que estão autorizados a acessar. No entanto, este artigo se concentra nesse aspeto da multilocação. Este artigo começa com uma visão geral das arquiteturas RAG de locatário único. Ele discute os desafios que você pode encontrar na multilocação com a RAG e algumas abordagens comuns a serem tomadas. Ele também descreve considerações e recomendações de multilocação para melhorar a segurança.
Observação
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 de IA fundamentais em qualquer plataforma.
Arquitetura RAG de inquilino único com um orquestrador
Fluxo de trabalho
Nesta arquitetura RAG de inquilino único, um orquestrador busca dados proprietários relevantes do inquilino dos armazenamentos de dados e os fornece como dados de sustentação para o modelo de 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.
- A aplicação inteligente chama a API do orquestrador com a consulta do utilizador e o token de autorização para o utilizador.
- 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 fundamentais são adicionados ao prompt enviado ao modelo fundamental, como um modelo exposto no Azure OpenAI, na etapa seguinte.
- A lógica de orquestração se conecta à API de inferência do modelo de base e envia o prompt que inclui os dados de aterramento recuperados. Os resultados são devolvidos à aplicação inteligente.
Para obter mais informações, consulte Projetar e desenvolver uma solução RAG.
Arquitetura RAG de locatário único com acesso direto aos dados
Esta variante da arquitetura RAG de inquilino único utiliza a funcionalidade On Your Data do Azure OpenAI para se integrar diretamente com armazenamentos de dados como o Azure AI Search. Nessa arquitetura, ou você não tem seu próprio orquestrador, ou seu orquestrador tem menos responsabilidades. A API OpenAI do Azure acede ao armazenamento de dados para obter os dados fundamentais e passa esses dados para o modelo de linguagem. Este método oferece menos controlo sobre quais dados de referência obter e a relevância desses dados.
Observação
O Azure OpenAI é gerenciado pela Microsoft. Ele se integra com o armazenamento de dados, mas o modelo em si não se integra com o armazenamento de dados. O modelo recebe dados de base da mesma forma que quando um orquestrador busca os dados.
Fluxo de trabalho
Nessa arquitetura RAG, o serviço que fornece o modelo de base busca os dados proprietários apropriados do inquilino nos armazenamentos de dados e usa esses dados como dados de base para o modelo de base. As etapas a seguir descrevem um fluxo de trabalho de alto nível. As etapas em itálico são idênticas à arquitetura RAG anterior de locatário único que tem um fluxo de trabalho do 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 Azure OpenAI liga-se a armazenamentos de dados suportados, como Pesquisa de IA e Armazenamento de Blobs do Azure, para obter os dados de base. Os dados de base são usados como parte do contexto quando o Azure OpenAI chama o modelo de linguagem da OpenAI. Os resultados são devolvidos à aplicação inteligente.
Se pretender usar esta arquitetura numa solução multitenant, o serviço que acede diretamente aos dados de base, como o Azure OpenAI, deve suportar a lógica multitenant requerida pela sua solução.
Multilocação na arquitetura RAG
Em soluções multi-inquilinos, os dados do inquilino podem ser armazenados em um repositório específico do inquilino ou coexistir com outros inquilinos em um repositório multi-inquilinos. Os dados também podem estar em uma loja compartilhada entre locatários. Apenas os dados que o utilizador está autorizado a acessar devem ser usados como dados de base. O utilizador deve ver apenas dados comuns, de todos os inquilinos, ou dados filtrados dos seus inquilinos que ajudam 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 à arquitetura RAG de locatário único com um fluxo de trabalho com 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 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 utilizador da solicitação e invoca os repositórios de dados apropriados para obter dados base relevantes autorizados pelo inquilino para a consulta. Os dados de aterramento são adicionados ao prompt enviado ao Azure OpenAI na próxima etapa. Algumas ou todas as etapas a seguir estão incluídas:
- A lógica de orquestração recolhe dados de base da instância de armazenamento de dados específica do inquilino adequada e potencialmente aplica regras de filtragem de segurança para retornar apenas os dados aos quais o utilizador está autorizado a aceder.
- A lógica de orquestração obtém os dados base do inquilino apropriado do armazenamento de dados multilocatário e potencialmente aplica regras de filtragem de segurança para retornar apenas os dados que o utilizador 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 de base 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
Considere as seguintes opções ao conceber a sua solução de inferência RAG multilocatário.
Escolha um modelo de isolamento de loja
As duas principais abordagens arquitetónicas para armazenamento e dados em cenários multilocatários são armazenamento por locatário e armazenamento multilocatário. Essas abordagens são adicionais aos armazenamentos que contêm dados compartilhados entre locatários. Sua solução multilocatária pode usar uma combinação dessas abordagens.
Loja por inquilino
Nas lojas de loja por inquilino, cada inquilino tem a 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 porque todo o custo de implantação de uma loja pode ser atribuído a um único locatário.
Esta abordagem pode apresentar desafios, tais como o aumento das despesas gerais de gestão e operacionais e custos mais elevados. Você não deve usar essa abordagem se tiver um grande número de pequenos locatários, como em cenários de empresa para consumidor. Esta abordagem também pode atingir ou exceder os limites de serviço .
No contexto deste cenário de IA, um armazenamento específico por locatário significa que os dados de referência necessários para trazer relevância ao contexto vêm de um armazenamento de dados existente ou novo que contém apenas dados de referência para o locatário. Nessa topologia, a instância do banco de dados é o discriminador usado para cada locatário.
Lojas multilocatárias
Nas lojas multicliente, os dados de vários locatários coexistem na mesma store. 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 isolamento e gerenciamento de dados, o potencial para o antipadrão de vizinho barulhento e 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 um desafio se os locatários tiverem ciclos de vida de dados diferentes que exijam 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 do 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 oferecem suporte à segurança em nível de linha. No entanto, esses recursos normalmente não são usados em soluções multilocatárias porque você precisa projetar sua solução em torno desses recursos se planeja usá-los em sua loja multilocatário.
No contexto deste cenário de IA, os dados básicos para todos os utilizadores são reunidos no mesmo armazém de dados. Portanto, sua consulta a 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 partilhadas
As soluções multilocatárias geralmente compartilham dados entre locatários. Em um exemplo de solução multilocatária para o domínio de saúde, um banco de dados pode armazenar informações médicas gerais ou informações que não são específicas do locatário.
No contexto deste cenário de IA, o repositório de dados de base é geralmente acessível e não requer filtragem com base em inquilinos específicos, pois os dados são relevantes e autorizados para todos os inquilinos do sistema.
Identidade
Identidade é um aspeto fundamental das soluções multilocatárias, 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ária precisa de um diretório de identidade que armazene identidades autoritativas ou referências a identidades. Essa identidade precisa fluir através da 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 possa conceder acesso a esses dados do inquilino.
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 os modelos business-to-business e business-to-consumer. O modelo escolhido ajuda a determinar quais outros fatores devem ser considerados ao criar sua solução. Compreender 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 inquilino também é importante. Os 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 um 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 pretende introduzir novos componentes, como um armazenamento de pesquisa vetorial dedicado ou um armazenamento de referência dedicado, ainda assim é necessário tomar essa decisão. Considere 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ê precisa definir seus requisitos de autorização para dados. Os inquilinos acessam apenas os dados do seu inquilino, mas os teus requisitos de autorização podem ser mais granulares. Por exemplo, numa solução de cuidados de saúde, poderá ter regras como:
- Um paciente só pode acessar seus próprios dados de paciente.
- Um profissional de saúde pode aceder aos dados dos seus pacientes.
- Um utilizador de finanças só pode aceder a dados relacionados com finanças.
- Um auditor clínico pode ver todos os dados dos pacientes.
- Todos os usuários podem acessar conhecimentos médicos básicos 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 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 apenas aos dados que os usuários estão autorizados a acessar é conhecido como filtragem ou filtragem de segurança. Num cenário RAG multilocatário, um utilizador pode ser mapeado para um armazém específico do locatário. Isso não significa que o utilizador deva ser capaz de aceder a todos os dados nesse repositório. Defina seus requisitos de locatário e autorização discute a importância de definir requisitos de autorização para seus dados. Você deve usar essas regras de autorização como base para a filtragem.
Você pode usar recursos de plataforma de dados, como segurança em nível de linha, para implementar a filtragem. Ou você pode precisar de lógica, dados ou metadados personalizados. Esses recursos de plataforma não são normalmente usados em soluções multilocatárias porque você precisa projetar seu sistema em torno desses recursos.
Encapsular lógica de dados multilocatários
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 autorizados a acessar.
O acesso dos utilizadores aos dados pode ser limitado por:
- O locatário do usuário.
- Recursos da plataforma.
- Regras personalizadas de filtragem ou de limitação de segurança.
A camada API deve:
- Encaminhe a consulta para uma loja específica para o inquilino, num modelo de loja por inquilino.
- Selecione apenas dados do locatário do usuário em repositórios multilocatário.
- Utilize a identidade apropriada para um utilizador para dar suporte à lógica de autorização ativada pela plataforma.
- Aplique a lógica de filtragem de segurança personalizada.
- Armazene registos de acesso de informações de fundamentação para auditoria.
O código que precisa acessar os dados do locatário não deve ser capaz de consultar os repositórios back-end diretamente. Todas as solicitações de dados devem fluir através da camada de API. Essa camada de API fornece um único ponto de governança ou segurança sobre os dados do locatário. Essa abordagem impede que a lógica de autorização de acesso aos dados do locatário e do usuário alcance outras á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, deve-se considerar como arquitetar a solução de dados de base para os 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
A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.
Principais autores:
- John Downs | Engenheiro de Software Principal
- Daniel Scott-Raynsford | Arquiteto de Soluções de Parceiro Senior, Dados & IA
Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.