LLMs e o OpenAI do Azure no padrão RAG (Geração Aumentada de Recuperação) (versão preliminar)

Importante

Este é um recurso em versão preliminar. Estas informações estão relacionadas a um recurso de pré-lançamento que pode ser substancialmente modificado antes de ser lançado. A Microsoft não oferece garantias, expressas ou implícitas, das informações aqui fornecidas.

Este artigo oferece um exemplo ilustrativo do uso de LLMs (Modelos de Linguagem Grande) e o OpenAI do Azure no contexto do padrão RAG (Geração Aumentada de Recuperação). Mais especificamente, ele explora como você pode aplicar essas tecnologias dentro das zonas de destino soberanas, ao mesmo tempo em que leva em consideração proteções importantes.

Cenário

Um cenário comum é usar LLMs para participar de conversas usando seus próprios dados por meio do padrão RAG (Geração Aumentada de Recuperação). Esse padrão permite a você usar as habilidades racionais de LLMs para gerar respostas com base em dados específicos, sem exigir o ajuste fino do modelo. Ele facilita a integração perfeita de LLMs a processos empresariais ou soluções existentes.

Cloud for Sovereignty – Arquitetura de referência de IA e LLM

O Microsoft Cloud for Sovereignty oferece uma arquitetura de referência que ilustra uma arquitetura típica de RAG (Geração Aumentada de Recuperação) dentro de uma SLZ (Zona de Destino Soberana). Ele fornece uma visão geral das opções de tecnologia de implementação comuns e recomendadas, terminologia, princípios de tecnologia, ambientes de configuração comuns e composição dos serviços aplicáveis.

Baixe um PDF para impressão deste diagrama de arquitetura de referência.

Os principais estágios/fluxo de dados são os seguintes:

Zonas de destino do aplicativo

Na hierarquia do grupo de gerenciamento, esses serviços são colocados em uma assinatura em um grupo de gerenciamento não confidencial.

Fontes de dados e pipelines de transformação

Fontes de dados e pipelines de transformação geralmente existem dentro de uma organização para operações de linha de negócios. Ao integrar aplicativos LLM, como implementações de RAG, a dados existentes, eles se tornam novas cargas de trabalho.

Para garantir o controle do fluxo de dados, a arquitetura de referência recomenda o domínio dos dados alinhados às zonas de destino dos dados para as fontes de dados e coloca os pipelines da transformação de dados próximos dessas fontes para criar produtos de dados usados pelos aplicativos de LLM. Essa abordagem garante o gerenciamento preciso dos dados provisionados para a solução baseada em LLM, que é hospedada separadamente.

Os componentes de transformação de dados fazem uso de diferentes tecnologias e serviços para transformar dados em um formato que possa ser pesquisado e usado por uma aplicação baseada em LLM por meio de pesquisa semântica ou vetorial para fins de aterramento. Esses pipelines podem funcionar por conta própria ou podem usar serviços de IA, como os serviços de IA do Azure ou o OpenAI para transformar os dados para serem colocados em uma pesquisa vetorial ou banco de dados de pesquisa semântica.

Ao usar serviços de IA, o emparelhamento de rede sempre os disponibiliza (por meio do hub ou diretamente) por meio dos pontos de extremidade privados. Por motivos de governança, segurança e conformidade, os componentes de transformação de dados têm autoridade para determinar quais dados e em qual formato são fornecidos a um banco de dados de pesquisa para a carga de trabalho de LLM.

Os componentes de transformação de dados podem usar vários tipos de fontes de dados para oferecer dados com o resultado ideal para os bancos de dados de pesquisa dos quais as cargas de trabalho de LLM dependem. Essas fontes de dados podem ser bancos de dados SQL, data lakes ou até mesmo máquinas virtuais que hospedam soluções de dados personalizadas, dependendo do ambiente do cliente.

As fontes de dados não devem ser acessíveis diretamente pelo aplicativo Orchestrator, mas, esses recursos devem estar disponíveis somente nos limites privados da rede virtual. Isso impõe a integração direta de Rede Virtual do Microsoft Azure (por exemplo, como é o caso de VMs), serviços de Link Privado ou pontos de extremidade de serviço de rede virtual (somente se a integração de Link Privado ou Rede Virtual direta não estiver disponível).

Componentes relacionados a IA e LLM

Os componentes relacionados a IA e LLM devem ser hospedados como cargas de trabalho em sua própria assinatura no grupo de gerenciamento Corp ou Online (dependendo se o acesso público é necessário ou não). Essas componentes são:

O Serviço OpenAI do Azure encapsula as operações de LLMs, como GPT, e inserções de texto, como Ada, tornando-as acessíveis por meio de APIs padrão fornecidas pelo OpenAI para o aplicativo Orquestrador.

Um aplicativo Orquestrador atua como o front-end com uma interface baseada em API ou UX e orquestra as diferentes etapas necessárias para criar experiências baseadas em RAG. Muitas vezes, é um aplicativo Web ou uma API Web. Essas etapas normalmente incluem:

• extração de dados de mecanismos de pesquisa semântica para aterramento de prompts
• extração de dados de fontes de dados para aterramento de prompts
• encadeamento correto de diferentes solicitações para o LLM

O aplicativo Orquestrador mantém o histórico das solicitações enviadas e das respostas recebidas para garantir que o Serviço OpenAI do Azure seja fundamentado com base nas interações anteriores. Por exemplo, em uma experiência semelhante a um chat, como o ChatGPT ou o Bing Chat, o aplicativo Orquestrador mantém ou armazena em cache o histórico da sessão de conversa, de maneira que ele seja levado em consideração no fluxo de conversa pelo back-end do serviço de LLM.

Em um ambiente Online, o ponto de extremidade do aplicativo Orquestrador deve ser o único fornecido por meio de um ponto de extremidade público protegido por um Firewall do Aplicativo Web e serviços de proteção contra DDoS. Se hospedado em um ambiente Corp, sem pontos de extremidade públicos, o Orquestrador será hospedado em um serviço diretamente integrado à Rede Virtual, como Máquinas Virtuais ou Conjuntos de Dimensionamento de VM, ou usará serviços que ofereçam suporte a pontos de extremidade de serviço de Link Privado ou de Rede Virtual, como é o caso dos Serviços de Aplicativo do Azure.

Os Serviços de Pesquisa fornecem dados de várias fontes de dados em um formato otimizado para uso eficiente para aterramento de prompts de serviços de LLM. A Microsoft propõe uma combinação de vetorização e pesquisa semântica para obter os melhores resultados para o aterramento de prompts com base em serviços de pesquisa, com suporte da Pesquisa de IA do Azure. O uso da classificação semântica melhora de forma mensurável a relevância da pesquisa usando a compreensão de linguagem para classificar os resultados da pesquisa. Isso melhora a experiência do usuário dos aplicativos de RAG, pois o aterramento de prompts se torna mais preciso por meio de melhores resultados de pesquisa do serviço de pesquisa antes de enviar uma solicitação ao LLM.

Uma combinação de serviços de IA pode ser usada para criar experiências personalizadas para os usuários finais por meio do Orquestrador ou para otimizar os processos de ingestão de dados. Imagine usar um serviço de reconhecimento de formulários, como a Inteligência de Documento da IA do Azure, para extrair informações estruturadas de formulários e processar e resumir as entradas do usuário com eficiência. Esse serviço pode colaborar com um LLM para resumir as principais descobertas dessas entradas de formulário reconhecidas. Outro cenário envolve o uso de um serviço de reconhecimento de documentos para converter documentos em vários formatos, como PDFs ou documentos do Word em texto. Posteriormente, um serviço de inserção de texto de LLM pode vetorizar esse texto reconhecido para análise posterior.

Os serviços de Link Privado são implantados para todos os componentes, de modo que todos os serviços sejam acessíveis somente no ambiente privado. A única exceção pode ser o aplicativo Orquestrador, que, se estiver hospedado em uma zona de destino Online, pode ser oferecido publicamente por trás de um Firewall de Aplicativo Web ou de serviços comparáveis.

Componentes da infraestrutura

Os componentes da infraestrutura podem ser hospedados como parte da carga de trabalho ou centralmente em uma assinatura de hub ou de identidade.

O componente central de infraestrutura de uma implementação de Zona de Destino Soberana é o Hub de Conectividade da Plataforma, que é uma rede virtual fornecida por cada implantação de Zona de Destino Soberana. Ele é colocado na assinatura de conectividade dentro do grupo de gerenciamento da plataforma.

Os componentes de rede compartilhados são colocados na rede virtual do hub. Entre esses componentes normalmente estão:

• Circuitos do ExpressRoute ou Gateways de VPN para conectividade com a rede corporativa de uma empresa, agência ou organização.

• Os firewalls podem ser implementados usando aparelhos ou uma combinação das ofertas do Firewall do Azure, incluindo o Firewall do Aplicativo Web. Essas soluções permitem a inspeção, a filtragem e o roteamento de tráfego.

• Componentes de Proteção contra DDoS para proteger cargas de trabalho contra ataques de negação de serviço distribuído.

• Zonas DNS privadas para todos os tipos de serviços usados em todo o cenário de data center virtual implementado com zonas de destino.

• Emparelhamento de rede virtual para conectar redes virtuais de várias cargas de trabalho, como fontes de dados, transformação e componentes de LLM por meio da rede do hub.

• As políticas controlam o fluxo de tráfego pelos firewalls do hub, quando necessário.

Considerações

O diagrama de arquitetura de referência mostra um exemplo de arquitetura representativo envolvendo os componentes típicos de uma carga de trabalho de LLM baseada em RAG no contexto de uma zona de destino soberana. Existem diversas considerações a serem observadas que não foram abordadas em seções anteriores.

Alinhamento com princípios do Well-Architected Framework e do Cloud Adoption Framework

Nas seções anteriores, alguns aspectos de alinhamento relacionados ao Well-Architected Framework (WAF) e ao Cloud Adoption Framework (CAF) foram brevemente mencionados. É importante observar que todas as decisões de arquitetura devem estar totalmente alinhadas com os princípios fundamentais do CAF e das zonas de destino do Azure, da análise em escala de nuvem do CAF e do WAF, incluindo a perspectiva do WAF no OpenAI do Azure.

Considerações de design de infraestrutura relacionadas a proteções

Embora lidar com proteções seja um procedimento padrão em ambientes de zona de destino, outras considerações devem ser feitas em várias áreas para cargas de trabalho de LLM e de IA. É melhor seguir a Conformidade da Linha de Base de Segurança do Azure e os padrões da iniciativa de política de Linha de Base de Soberania ao projetar e definir a infraestrutura para a assinatura da carga de trabalho.

As principais considerações a serem realçadas para aplicativos de LLM baseados em RAG desses padrões são:

Residência de dados e seleção de região

A soberania impõe exigências rigorosas sobre a residência de dados e, por isso, pode restringir implantações em regiões do Azure específicas em uma SLZ. A seleção de uma região para cargas de trabalho de LLM é limitada pela disponibilidade dos serviços necessários:

• Verifique se o OpenAI do Azure e a Pesquisa de IA do Azure estão disponíveis na região de destino onde você hospeda seus dados e na carga de trabalho por motivos de residência de dados e/ou proximidade. Além disso, esses serviços são importantes, de uma perspectiva de desempenho, para a experiência do aplicativo pelo usuário final.

• Em segundo lugar, ao analisar o OpenAI do Azure, a disponibilidade dos respectivos modelos de LLM é importante, uma vez que nem todos os modelos estão igualmente disponíveis em todas as regiões.

• Se as fontes de dados ou outros serviços cognitivos não estiverem disponíveis na sua região de destino designada, você poderá encontrá-las e operá-las em outra região em alinhamento com seus requisitos de residência de dados. No entanto, o serviço OpenAI do Azure e a Pesquisa de IA do Azure devem estar na mesma região que o aplicativo Orquestrador por motivos de desempenho.

Rede

Pontos de extremidade públicos não são permitidos em ambientes Corp. Portanto, todos os serviços devem ser encapsulados em uma Rede Virtual. Dependendo do serviço, ele pode oferecer recursos de encapsulamento direto, como VMs ou clusters do AKS, pontos de extremidade de serviço de Link Privado ou de Rede Virtual. Os pontos de extremidade do serviço de rede virtual devem ser substituídos por Link Privado sempre que possível.

Além do encapsulamento, o acesso público deve ser desabilitado para todos os serviços. Por fim, a imposição da política usando o Azure Policy deve ser habilitada, de maneira que o acesso público jamais possa ser habilitado acidentalmente para serviços nos quais políticas de negação correspondentes não possam ser compiladas. A estratégia de defesa profunda é habilitar os recursos de auditoria correspondentes para todos os serviços.

Criptografia em repouso e em trânsito

A maioria dos serviços no Azure oferece suporte a recursos de criptografia em trânsito e em repouso. Habilite a criptografia em repouso e em trânsito em todos os serviços, quando disponível. Habilite a versão do TLS mais recente, atualmente TLS 1.2, para a criptografia em trânsito.

Identidades gerenciadas

Use identidades gerenciadas para todos os serviços e para a comunicação entre serviços para evitar o gerenciamento de segredos para credenciais.

Rotação de chaves no Key Vault

Sempre que ativos de segurança, como certificados, forem necessários, habilite a rotação de chaves desses segredos no Key Vault para manter a conformidade.

Grupos de segurança de redes e de aplicativos

Em um ambiente soberano e seguro, o uso de NSG (Grupos de Segurança de Rede) e ASG (Grupos de Segurança de Aplicativos) é aplicado. A ausência de grupos de segurança leva a implantações que não estão em conformidade. As portas SSL de costume são úteis para a maioria dos serviços dos quais as cargas de trabalho de LLM/RAG dependem, pois são baseadas em HTTPS. Portas específicas são necessárias para a ingestão de dados das fontes para os bancos de dados de pesquisa e vetoriais. Os IPs públicos não são permitidos em zonas de destino Corp. Todos os serviços só devem ser acessíveis na Rede Virtual, o que requer o uso de pontos de extremidade de serviço de rede virtual ou Rede Virtual para serviços PaaS.

Mais proteções de segurança e soberania

As proteções mais importantes e óbvias abordadas nas seções anteriores para o design da infraestrutura e do aplicativo são reutilizáveis mesmo fora das zonas de destino soberana ou do Azure. Outras políticas globais estão vinculadas a recursos gerenciados centralmente, como espaços de trabalho do Log Analytics ou implantações do Microsoft Sentinel em zonas de destino de escala empresarial. Durante o processo de design da infraestrutura e do aplicativo, é essencial levar em consideração esses recursos gerenciados centralmente. Deixar de fazer isso pode resultar em esforço e tempo adicionais após a implantação. Felizmente, o recurso de conformidade de políticas do Azure pode identificar recursos não estejam em conformidade após a implantação. Além disso, as zonas de destino soberana e do Azure fornecem políticas DeployIfNotExists para vários recursos, simplificando ainda mais o processo.

Alguns exemplos dessas proteções são:

• Ativação do registro em log no workspace do Log Analytics gerenciado centralmente.

• Integração com a Central de Segurança do Azure ou com o Microsoft Defender para Nuvem.

• Integração com conjuntos de SIEM (gerenciamento de eventos e informações de segurança), como o Microsoft Sentinel.

• Integração com firewalls gerenciados centralmente, firewalls de aplicativos Web ou proteção contra DDoS.

Essas são apenas algumas proteções que você pode identificar como requisitos após a implantação inicial. É recomendável testar as implantações em uma zona de destino de teste e integrar iterativamente um processamento dessas proteções à infraestrutura e à base de código do aplicativo. Se isso não for totalmente possível, muitas desses proteções poderão ser resolvidas após a implantação com políticas DeployIfNotExists .

Implantar este cenário

Para usufruir Grandes Modelos de Linguagem (LLMs) e o OpenAI do Azure com base no padrão Geração Aumentada de Recuperação (RAG) dentro das Zonas de Destino Soberanas, você precisa primeiro implantar e configurar uma Zona de Destino Soberana (SLZ) e aplicar iniciativas da política de Linha de Base Soberana. Para obter uma visão geral detalhada de uma SLZ e todos os seus recursos, consulte a Documentação da Zona de Destino Soberana no GitHub.

A SLZ fornece um ambiente que oferece proteções por meio de políticas e conjuntos de políticas, aplicação de segurança e infraestrutura de linha de base consistente para a implantação de cargas de trabalho e aplicativos. A SLZ é baseada em Zonas de Destino do Azure e estende isso com proteções e controles de segurança específicos para requisitos de soberania.

Para ajudar a acelerar o tempo de obtenção de valor dos clientes e, ao mesmo tempo, ajudá-los a cumprir seus objetivos de conformidade, o Microsoft Cloud for Sovereignty inclui modelos de carga de trabalho prontos para uso que podem ser implantados de forma consistente e operados de maneira repetível. Os modelos de carga de trabalho estão alinhados com as iniciativas da política de Linha de Base de Soberania, o portfólio de políticas Cloud for Sovereignty e as políticas padrão da Zona de destino do Azure.

Acelerador do Assistente de Informações

O Assistente de Informações é um acelerador de soluções que oferece um ponto de partida para organizações compilarem a própria capacidade de IA generativa personalizada para estender o poder do OpenAI do Azure a usuários organizacionais e os dados de domínio privado. Você pode implantá-lo dentro do Cloud for Sovereignty e alinhá-lo com a arquitetura de referência e as diretrizes apresentadas neste artigo. É recomendável implantar o acelerador dentro da zona de destino Corp para cargas de trabalho internas e seguir as diretrizes para proteger implantações na zona de destino Online para acesso público.

O acelerador é uma combinação de código, documentação e recursos educacionais fornecidos gratuitamente para clientes e parceiros que podem ajudar a acelerar o tempo de retorno.

Para obter mais informações sobre como implantar e configurar o acelerador do Assistente de Informações, consulte a documentação do Assistente de Informações no GitHub. Para casos de uso que você possa atingir com esse acelerador, consulte Vídeo do Assistente de Informações.