LLMs e o Azure OpenAI no padrão de Geração Aumentada de Obtenção (RAG) (pré-visualização)

Importante

Esta é uma funcionalidade de pré-visualização. Estas informações estão relacionadas com uma funcionalidade de pré-lançamento que pode ser substancialmente modificada antes de ser lançado. A Microsoft não concede garantias, expressas ou implícitas, em relação à informação aqui apresentada.

Este artigo oferece um exemplo ilustrativo da utilização de LLMs (Large Language Models) e do Azure OpenAI no contexto do padrão de Geração Aumentada de Obtenção (RAG). Especificamente, explora como pode aplicar estas tecnologias dentro das Zonas de Destino Soberanas, considerando verificadores de integridade importantes.

Cenário

Um cenário comum é a utilização de LLMs para interagir em conversações utilizando os seus próprios dados através do padrão de Geração Aumentada de Obtenção (RAG). Este padrão permite-lhe utilizar as capacidades de raciocínio dos LLMs para gerar respostas com base nos seus dados específicos, sem ajustes do modelo. Facilita a integração perfeita de LLMs nas suas soluções ou processos empresariais existentes.

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

A Microsoft Cloud for Sovereignty fornece uma arquitetura de referência que ilustra uma arquitetura típica de Geração Aumentada de Obtenção (RAG) dentro de uma Zona de Pouso Soberana (SLZ). Fornece uma descrição geral das opções tecnológicas de implementação comuns e recomendadas, terminologia, princípios tecnológicos, ambientes de configuração comuns e composição dos serviços aplicáveis.

Transfira um PDF imprimível deste diagrama de arquitetura de referência.

As principais fases/fluxo de dados são as seguintes:

Zonas de destino de aplicação

Na hierarquia do grupo de gestão, estes serviços são colocados numa subscrição de um grupo de gestão não confidencial.

Origens de dados e pipelines de transformação

As origens de dados e os pipelines de transformação existem frequentemente numa organização para as operações de linha de negócio. Quando integra as aplicações de LLM, como as implementações RAG, com dados existentes, as aplicações LLM tornam-se em novas cargas de trabalho.

Para assegurar o controlo do fluxo de dados, a arquitetura de referência recomenda zonas de destino de dados alinhadas com o domínio de dados para as origens de dados e coloca os pipelines de transformação de dados perto dessas origens para criar os produtos de dados que são utilizados pelas aplicações de LLM. Esta abordagem assegura a gestão precisa dos dados aprovisionados para a solução baseada em LLM, que é alojada separadamente.

Os componentes de transformação de dados fazem uso de diferentes tecnologias e serviços para transformar dados em um formato que pode ser pesquisado e usado por um aplicativo baseado 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 serviços de IA do Azure ou Azure OpenAI, para transformar os dados a serem colocados em um banco de dados de pesquisa vetorial ou semântica.

Ao utilizar os serviços de IA, o peering de rede disponibiliza-os sempre (através do hub ou diretamente) através dos seus pontos finais privados. Por motivos de governação, segurança e conformidade, os componentes de transformação de dados têm autoridade para determinar que dados e em que formato são fornecidos a uma base de dados de pesquisa para a carga de trabalho de LLM.

Os componentes de transformação de dados podem utilizar vários tipos de origens de dados para oferecer dados com o resultado ideal às bases de dados de pesquisa de que as cargas de trabalho de LLM dependem. Estas origens de dados podem ser bases de dados SQL, data lakes ou até mesmo máquinas virtuais que alojam soluções de dados personalizadas, consoante o ambiente do cliente.

As origens de dados não devem estar acessíveis diretamente pela aplicação Orchestrator, mas, em vez disso, estes recursos só devem estar disponíveis dentro dos limites privados da rede virtual. Isto impõe a integração direta da Rede Virtual do Microsoft Azure (por exemplo, como é o caso de VMs), serviços de Private Link ou pontos finais de serviço de Rede Virtual (apenas se o Private Link ou a integração direta da Rede Virtual não estiver disponível).

Componentes relacionados com IA e LLM

Os componentes relacionados com IA e LLM devem ser alojados como cargas de trabalho na sua própria subscrição no âmbito do grupo de gestão Corp ou Online (consoante o acesso público seja necessário ou não). Estes componentes são:

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

Uma aplicação Orchestrator atua como front-end com uma interface baseada em API ou UX e orquestra os diferentes passos necessários para criar experiências baseadas em RAG. Muitas vezes, é uma aplicação Web ou uma API Web. Estes passos normalmente incluem:

• solicitar dados de mecanismos de pesquisa semântica para a fundamentação de pedidos
• solicitar dados de origens de dados para a fundamentação de pedidos
• encadear corretamente diferentes pedidos à LLM

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

Num ambiente online, o ponto final da aplicação Orchestrator deve ser o único fornecida através de um ponto final público protegido por uma Firewall de Aplicações Web e por serviços de proteção contra DDoS. Se alojado num ambiente Corp, sem pontos finais públicos, o Orchestrator será alojado num serviço diretamente integrado na Rede Virtual, como Máquinas Virtuais ou Conjuntos de Dimensionamento de VMs, ou utilizará serviços que oferecem suporte a pontos finais de serviço de Private Link ou Rede Virtual, como é o caso dos Serviços de Aplicações do Azure.

Os Serviços de Pesquisa fornecem dados de várias fontes de dados em um formato otimizado para uso eficiente para o aterramento imediato de serviços LLM. A Microsoft propõe uma combinação de vetorização e pesquisa semântica para obter os melhores resultados de fundamentação de pedidos com base em serviços de pesquisa, suportados pela Pesquisa de IA do Azure. A utilização da classificação semântica melhora de forma mensurável a relevância da pesquisa ao utilizar a compreensão de linguagem para classificar os resultados da pesquisa. Isso melhora a experiência do utilizador das aplicações RAG, à medida que o pedido de fundamentação se torna mais preciso através de melhores resultados de pesquisa do serviço de pesquisa antes de enviar um pedido ao LLM.

Pode ser utilizada uma combinação de serviços de IA para criar experiências personalizadas para utilizadores finais através do Orchestrator ou para otimizar processos de ingestão de dados. Imagine utilizar um serviço de reconhecimento de formulários, como o Inteligência de documentos de IA do Azure para extrair informações estruturadas de formulários e processar e resumir eficientemente as entradas dos utilizadores. Este serviço pode, em seguida, colaborar com um LLM para resumir as principais conclusões dessas entradas de formulário reconhecidas. Outro cenário envolve a utilização de um serviço de reconhecimento de documentos para converter documentos em vários formatos, tais como PDFs ou documentos do Word, em texto. Subsequentemente, um serviço de incorporação de texto de LLM pode vetorizar este 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 só sejam acessíveis dentro do ambiente privado. A única exceção pode ser a aplicação Orchestrator, que, se estiver alojada numa zona de destino Online, pode ser disponibilizada publicamente atrás de uma Firewall de Aplicações Web ou de serviços comparáveis.

Componentes da infraestrutura

Os componentes da infraestrutura podem ser alojados como parte da carga de trabalho ou centralmente num hub ou numa subscrição de identidade.

O componente central da infraestrutura de uma implementação da Zona de Pouso Soberana é o Hub de Conectividade da Plataforma, que é uma rede virtual fornecida por cada implementação de Zona de Pouso Soberana. É colocada na subscrição de conectividade no grupo de gestão da plataforma.

Os componentes de rede compartilhada são colocados na rede virtual do hub. Estes componentes normalmente incluem:

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

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

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

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

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

• As políticas controlam o fluxo de tráfego através dos firewalls do hub onde necessário.

Considerações

O diagrama da arquitetura de referência mostra uma arquitetura de exemplo representativa envolvendo os componentes típicos de uma carga de trabalho baseada em RAG de LLM no contexto de uma Zona de Pouso Soberana. Há várias considerações a ter em mente, que não foram abordadas nas secções anteriores.

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

Nas secções anteriores, alguns aspetos de alinhamento relacionados com o Well-Architected Framework (WAF) e o Cloud Adoption Framework (CAF) foram brevemente mencionados. É importante notar que todas as decisões arquitetónicas devem estar totalmente alinhadas com os princípios fundamentais de CAF e Zonas de Destino do Azure, análise de escala de cloud do CAF e WAF, incluindo a perspetiva do WAF sobre o Azure OpenAI.

Considerações de projeto de infraestrutura relacionadas com verificadores de integridade

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

As principais considerações a serem realçadas para aplicações baseadas em RAG de LLM destes padrões são:

Residência dos dados e seleção da região

A soberania impõe requisitos estritos sobre a residência dos dados e, portanto, pode restringir implementações para regiões específicas do Azure numa SLZ. A seleção de uma região para cargas de trabalho de LLM está limitada pela disponibilidade dos serviços necessários:

• Verifique se o Azure OpenAI e a Pesquisa de IA do Azure estão disponíveis na região de destino onde aloja os dados e a carga de trabalho por razões de residência e/ou proximidade dos dados. Além disso, estes serviços são importantes, do ponto de vista do desempenho, para a experiência da aplicação pelo utilizador final.

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

• Se as origens de dados ou outros serviços cognitivos não estiverem disponíveis na sua região de destino designada, poderá conseguir encontrá-los e utilizá-los noutra região em alinhamento com os seus requisitos de residência dos dados. No entanto, o serviço do Azure OpenAI e a Pesquisa de IA do Azure têm de estar na mesma região que a aplicação Orchestrator por razões de desempenho.

Rede

Os pontos finais públicos não são permitidos em ambientes Corp . Como tal, todos os serviços têm de estar encapsulados numa Rede Virtual. Dependendo do serviço, podem ser oferecidas capacidades de encapsulamento direto, como VMs ou clusters de AKS, o Private Link ou pontos finais de serviço de Rede Virtual. Os pontos finais do serviço de Rede Virtual devem ser substituídos pelo Private Link sempre que possível.

Além do encapsulamento, o acesso público tem de ser desativado para todos os serviços. Por fim, a imposição de políticas utilizando o Azure Policy deve ser ativada de modo a que o acesso público nunca possa ser ativado acidentalmente para serviços em que não seja possível criar políticas de negação correspondentes. A estratégia de defesa aprofundada é ativar as capacidades de auditoria correspondentes para todos os serviços.

Encriptação em repouso e em trânsito

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

Identidades geridas

Utilize identidades geridas para todos os serviços e comunicação serviço a serviço para evitar a gestão de segredos para credenciais.

Rotação de chaves no Key Vault

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

Grupos de Segurança de Redes e Aplicações

Num ambiente soberano e seguro, a utilização de Grupos de Segurança de Rede (NSG) e Grupos de Segurança de Aplicações (ASG) é imposto. A falta de grupos de segurança leva a implementações não conformes. As portas de SSL habituais 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. São necessárias portas específicas para a ingestão de dados das origens para as bases de dados vetoriais e de pesquisa. Os IPs públicos não são permitidos em zonas de destino Corp. Todos os serviços têm de estar acessíveis apenas na Rede Virtual, o que requer a utilização de pontos finais de serviço do Private Link ou de Rede Virtual para serviços PaaS.

Mais verificadores de integridade de segurança e soberania

Os verificadores de integridade mais importantes e óbvios abordados nas secções anteriores para a sua conceção de infraestrutura e aplicações são reutilizáveis mesmo fora das Zonas de Destino Soberanas ou do Azure. Outras políticas globais estão associadas a recursos geridos centralmente, como as áreas de trabalho do Log Analytics ou implementações do Microsoft Sentinel em zonas de destino de escala empresarial. Durante o processo de estruturação da infraestrutura e da aplicação, é crucial ter em conta estes recursos geridos centralmente. Não o fazer pode resultar em esforço e tempo adicionais após a implementação. Felizmente, a funcionalidade de conformidade com políticas do Azure pode identificar recursos não conformes após a implementação. Além disso, as Zonas de Destino Soberanas e do Azure fornecem políticas DeployIfNotExists para vários recursos, simplificando ainda mais o processo.

Seguem-se alguns exemplos dos verificadores de integridade referidos:

• Ativação do início de sessão em Áreas de Trabalho do Log Analytics geridas centralmente.

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

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

• Integração com firewalls geridas centralmente, Firewalls de Aplicações Web ou proteção contra DDoS.

Estes são apenas alguns dos verificadores de integridade que poderá identificar como requisitos após a implementação inicial. Recomendamos que teste as suas implementações numa zona de destino de teste e integre iterativamente um cumprimento desses verificadores de integridade na sua infraestrutura e base de código da aplicação. Se isso não for totalmente possível, muitos desses verificadores de integridade podem ser abordados após a implementação com políticas DeployIfNotExists .

Implemente este cenário

Para tirar partido dos Large Language Models (LLMs) e do Azure OpenAI com base no padrão de Geração Aumentada de Obtenção (RAG) dentro de Zonas de Destino Soberanas, primeiro tem de implementar e configurar uma Zona de Pouso Soberana (SLZ) e aplicar iniciativas de políticas da Linha de Base de Soberania. Para uma descrição geral detalhada de uma SLZ e de todas as respetivas capacidades, consulte a documentação da Zona de Pouso Soberana no GitHub.

A SLZ fornece um ambiente que oferece verificadores de integridade através de políticas e conjuntos de políticas, imposição de segurança e infraestrutura de linha de base consistente para implementar cargas de trabalho e aplicações. A SLZ baseia-se nas Zonas de Destino do Azure e alarga-as com verificadores de integridade e controlos de segurança específicos para os requisitos de soberania.

Para ajudar a acelerar o tempo de obtenção de valor para os clientes e, ao mesmo tempo, ajudá-los a cumprir os seus objetivos de conformidade, o Microsoft Cloud for Sovereignty inclui modelos de carga de trabalho prontos a utilizar que podem ser implementados de forma consistente e utilizados de maneira repetível. Os modelos de carga de trabalho estão alinhados com a Iniciativas de política de Linha de Base de Soberania, o Portefólio de políticas do Cloud for Sovereignty e as Políticas predefinidas da Zona de Destino do Azure.

Modelo de agente de Assistente de informações

O modelo de agente do Information Assistente fornece um ponto de partida para as organizações criarem seu próprio recurso de IA generativa personalizada para estender o poder do Azure OpenAI aos usuários organizacionais e seus dados de domínio sem ajustar o modelo. Pode implementá-lo no Cloud for Sovereignty e alinhá-lo com a arquitetura de referência e as orientações fornecidas neste artigo. O modelo de agente de Assistente de informações é compatível com o escopo do grupo de gerenciamento Sovereign Landing Zone Online usando a configuração de implantação de modo seguro. O apoio ao âmbito do grupo de gestão Corp está disponível em breve.

O modelo de agente é uma combinação de código, documentação e recursos educacionais fornecidos gratuitamente aos clientes e parceiros que podem ajudar a acelerar o tempo de valorização.

Para obter mais informações sobre como implantar e configurar o Information Assistente, consulte a documentação do modelo de agente do Information Assistente no GitHub. Para casos de uso que você pode obter com esse modelo de agente, consulte Informações Assistente vídeo.