Arquitetura de referência de bate-papo de ponta a ponta do OpenAI de linha de base

Azure OpenAI Service
Azure Machine Learning
Azure App Service
Azure Key Vault
Azure Monitor

Os aplicativos de bate-papo corporativo têm a capacidade de capacitar os funcionários por meio da interação conversacional. Isto é especialmente verdadeiro devido ao avanço contínuo de grandes modelos de linguagem, como os modelos GPT da OpenAI e os modelos LLaMA da Meta. Esses aplicativos de bate-papo consistem em uma interface de usuário para bate-papo, repositórios de dados contendo informações específicas do domínio pertinentes às consultas do usuário, grandes modelos de linguagem (LLMs) que raciocinam sobre os dados específicos do domínio para produzir uma resposta relevante e um orquestrador que supervisiona a interação entre esses componentes.

Este artigo fornece uma arquitetura de linha de base para criar e implantar aplicativos de chat corporativo que usam modelos de linguagem grandes do Azure OpenAI. A arquitetura emprega o fluxo de prompt do Azure Machine Learning (AML) para criar fluxos executáveis que orquestram o fluxo de trabalho de prompts de entrada para armazenamentos de dados para buscar dados de aterramento para os LLMs, juntamente com qualquer outra lógica Python necessária. O fluxo executável é implantado em um cluster de computação do Azure Machine Learning atrás de um ponto de extremidade online gerenciado.

A hospedagem da interface do usuário (UI) de chat personalizada segue as diretrizes do aplicativo Web de serviços de aplicativo de linha de base para implantar um aplicativo Web seguro, com redundância de zona e altamente disponível nos Serviços de Aplicativo do Azure. Nessa arquitetura, o Serviço de Aplicativo se comunica com os serviços PaaS do Azure por meio da integração de rede virtual em pontos de extremidade privados. Da mesma forma, o Serviço de Aplicativo da Interface do Usuário de chat se comunica com o ponto de extremidade online gerenciado para o fluxo em um ponto de extremidade privado e o acesso público ao espaço de trabalho do Azure Machine Learning está desabilitado.

Importante

O artigo não aborda os componentes ou as decisões de arquitetura do aplicativo Web de serviços de aplicativo de linha de base. Leia esse artigo para obter orientações arquitetônicas para hospedar a interface do usuário do bate-papo.

O espaço de trabalho do Machine Learning é configurado com isolamento de rede virtual gerenciado que requer que todas as conexões de saída sejam aprovadas. Com essa configuração, uma rede virtual gerenciada é criada, juntamente com pontos de extremidade privados gerenciados que permitem a conectividade com recursos privados, como o Armazenamento do Azure no local de trabalho, o Registro de Contêiner do Azure e o Azure OpenAI. Essas conexões privadas são usadas durante a criação e o teste de fluxo e por fluxos implantados na computação do Azure Machine Learning.

Gorjeta

GitHub logo Este artigo é apoiado por uma implementação de referência que mostra uma implementação de chat de linha de base de ponta a ponta no Azure. Essa implementação pode ser usada como base para o desenvolvimento de soluções personalizadas em seu primeiro passo para a produção.

Arquitetura

Diagram that shows a baseline end-to-end chat architecture with OpenAI.

Figura 1: Arquitetura de bate-papo de ponta a ponta da linha de base com OpenAI

Transfira um ficheiro do Visio desta arquitetura.

Componentes

Muitos dos componentes dessa arquitetura são os mesmos que os recursos no aplicativo Web de serviços de aplicativo de linha de base, pois a hospedagem da interface do usuário de chat nessa arquitetura segue a arquitetura do aplicativo Web do Serviço de Aplicativo de linha de base. Os componentes destacados nesta seção se concentram nos componentes usados para criar e orquestrar fluxos de bate-papo, serviços de dados e serviços que expõem os LLMs.

  • O Azure Machine Learning é um serviço de nuvem gerenciado usado para treinar, implantar e gerenciar modelos de aprendizado de máquina. Essa arquitetura usa vários outros recursos do Azure Machine Learning usados para desenvolver e implantar fluxos executáveis para aplicativos de IA alimentados por modelos de linguagem grande:
    • O fluxo de prompt do Azure Machine Learning é uma ferramenta de desenvolvimento que permite criar, avaliar e implantar fluxos que vinculam prompts do usuário, ações por meio de código Python e chamadas para LLMs. O fluxo de prompt é usado nessa arquitetura como a camada que orquestra fluxos entre o prompt, diferentes armazenamentos de dados e o LLM.
    • Os endpoints online gerenciados permitem implantar um fluxo para inferência em tempo real. Nessa arquitetura, eles são usados como um ponto de extremidade PaaS para a interface do usuário do chat invocar os fluxos de prompt hospedados pelo Azure Machine Learning.
  • O Armazenamento do Azure é usado para persistir os arquivos de origem do fluxo de prompt para o desenvolvimento do fluxo de prompt.
  • O Registro de Contêiner do Azure permite que você crie, armazene e gerencie imagens e artefatos de contêiner em um registro privado para todos os tipos de implantações de contêiner. Nessa arquitetura, os fluxos são empacotados como imagens de contêiner e armazenados no Registro de Contêiner do Azure.
  • O Azure OpenAI é um serviço totalmente gerenciado que fornece acesso à API REST aos modelos de linguagem grande do Azure OpenAI , incluindo o conjunto de modelos GPT-4, GPT-3.5-Turbo e Embeddings. Nessa arquitetura, além do acesso ao modelo, ele é usado para adicionar recursos corporativos comuns, como rede virtual e link privado, suporte a identidades gerenciadas e filtragem de conteúdo.
  • O Azure AI Search é um serviço de pesquisa na nuvem que suporta pesquisa de texto completo, pesquisa semântica, pesquisa vetorial e pesquisa híbrida. O Azure AI Search está incluído na arquitetura, pois é um serviço comum usado nos fluxos por trás de aplicativos de chat. O Azure AI Search pode ser usado para recuperar e indexar dados relevantes para consultas do usuário. O fluxo de prompt implementa o padrão RAG Retrieval Augmented Generation para extrair a consulta apropriada do prompt, consultar AI Search e usar os resultados como dados de base para o modelo OpenAI do Azure.

Fluxo de prompt do Azure Machine Learning

O back-end para aplicativos de bate-papo corporativo geralmente segue um padrão semelhante ao seguinte fluxo:

  • O usuário insere um prompt em uma interface de usuário (UI) de bate-papo personalizada
  • Esse prompt é enviado para o back-end pelo código da interface
  • A intenção do usuário (pergunta ou diretiva) é extraída do prompt pelo back-end
  • (facultativo) O back-end determina o(s) armazenamento(s) de dados que contém dados relevantes para o prompt do usuário
  • O back-end consulta o(s) armazenamento(s) de dados relevante(s)
  • O back-end envia a intenção, os dados de aterramento relevantes e qualquer histórico fornecido no prompt para o LLM.
  • O back-end retorna o resultado para que ele possa ser exibido na interface do usuário

O back-end pode ser implementado em qualquer número de idiomas e implantado em vários serviços do Azure. Nessa arquitetura, o fluxo de prompt do Azure Machine Learning foi escolhido porque fornece uma experiência simplificada para criar, testar e implantar fluxos que orquestram entre prompts, armazenamentos de dados back-end e LLMs.

Rede

Juntamente com o acesso baseado em identidade, a segurança da rede está no centro da arquitetura de bate-papo de ponta a ponta de linha de base usando OpenAI. A partir de um alto nível, a arquitetura de rede garante o seguinte:

  • Um único ponto de entrada seguro para o tráfego da interface do usuário do chat
  • O tráfego de rede é filtrado
  • Os dados em trânsito são criptografados de ponta a ponta com TLS
  • A exfiltração de dados é minimizada mantendo o tráfego no Azure usando o Private Link
  • Os recursos de rede são logicamente agrupados e isolados uns dos outros através da segmentação de rede

Fluxos de rede

Diagram that shows a baseline end-to-end chat architecture with OpenAI with flow numbers.

Figura 2: Fluxos de rede para a arquitetura de chat de ponta a ponta da linha de base com OpenAI

Dois fluxos neste diagrama são abordados no aplicativo Web de serviços de aplicativo de linha de base: 1. o fluxo de entrada do usuário final para a interface do usuário do chat e 2. o fluxo de serviços de PaaS do Serviço de Aplicativo para o Azure. Consulte esse artigo para obter detalhes sobre esses fluxos. Esta seção se concentra no fluxo de ponto de extremidade online do Azure Machine Learning. O seguinte detalha o fluxo da interface do usuário de chat em execução no aplicativo Web do Serviço de Aplicativo de linha de base para o fluxo implantado na computação do Azure Machine Learning:

  1. A chamada da interface do usuário do chat hospedado do Serviço de Aplicativo é roteada por meio de um ponto de extremidade privado para o ponto de extremidade online do Aprendizado de Máquina do Azure.
  2. O ponto de extremidade online roteia a chamada para um servidor que executa o fluxo implantado. O ponto de extremidade online atua como um balanceador de carga e um roteador.
  3. As chamadas para os serviços PaaS do Azure exigidos pelo fluxo implantado são roteadas por meio de pontos de extremidade privados gerenciados.

Ingresso no Azure Machine Learning

Nessa arquitetura, o acesso público ao espaço de trabalho do Azure Machine Learning é desabilitado e o acesso pode ocorrer por meio de acesso privado, pois segue o ponto de extremidade privado para a configuração do espaço de trabalho do Azure Machine Learning. Na verdade, os pontos de extremidade privados são usados em toda essa arquitetura para complementar a segurança baseada em identidade. Por exemplo, permitindo que sua interface do usuário de chat hospedada no Serviço de Aplicativo se conecte a serviços PaaS não expostos à Internet pública, incluindo pontos de extremidade do Azure Machine Learning.

O acesso ao ponto de extremidade privado também é necessário para se conectar ao espaço de trabalho do Azure Machine Learning para criação de fluxo.

Diagram that shows a user connecting to an Azure Machine Learning workspace through a jump box to author a flow OpenAI with flow numbers.

Figura 3: Fluxos de rede para um autor de fluxo de prompt do Azure Machine Learning

O diagrama mostra um autor de fluxo de prompt conectando-se por meio do Azure Bastion a uma caixa de salto de máquina virtual. A partir dessa caixa de salto, o autor pode se conectar ao Espaço de Trabalho de Aprendizado de Máquina por meio de um ponto de extremidade privado na mesma rede que a caixa de salto. A conectividade com a rede virtual também pode ser realizada por meio de gateways ExpressRoute ou VPN e emparelhamento de rede virtual.

Fluir da rede virtual gerenciada do Azure Machine Learning para os serviços PaaS do Azure

É recomendável que o espaço de trabalho do Azure Machine Learning seja configurado para isolamento de rede virtual gerenciado com uma configuração que exija que todas as conexões de saída sejam aprovadas. Esta arquitetura segue essa recomendação. Existem dois tipos de regras de saída aprovadas. As regras de saída necessárias são para recursos necessários para que a solução funcione, como o Registro de Contêiner do Azure e o Armazenamento do Azure. As regras de saída definidas pelo usuário são para recursos personalizados, como o Azure OpenAI ou o Azure AI Search, que seu fluxo de trabalho vai usar. É sua responsabilidade configurar regras de saída definidas pelo usuário, enquanto as regras de saída necessárias são configuradas quando a rede virtual gerenciada é criada.

As regras de saída podem ser pontos de extremidade privados, tags de serviço ou FQDNs para pontos de extremidade públicos externos. Nessa arquitetura, a conectividade com serviços do Azure, como o Registro de Contêiner do Azure, o Armazenamento do Azure, o Cofre da Chave do Azure, o serviço Azure OpenAI e a Pesquisa do Azure AI são conectados por meio de link privado. Embora não estejam nessa arquitetura, algumas operações comuns que podem exigir a configuração de uma regra de saída FQDN são o download de um pacote pip, a clonagem de um repositório GitHub, o download de imagens de contêiner base de repositórios externos.

Segmentação e segurança de redes virtuais

A rede nesta arquitetura tem sub-redes separadas para o seguinte:

  • Gateway de Aplicação
  • Componentes de integração do Serviço de Aplicativo
  • Pontos finais privados
  • Azure Bastion
  • Máquina virtual de caixa de salto
  • Treinamento - não usado para treinamento de modelo nesta arquitetura
  • Classificação

Cada sub-rede tem um grupo de segurança de rede que limita o tráfego de entrada e saída dessas sub-redes apenas ao que é necessário. A tabela a seguir mostra uma exibição simplificada das regras NSG que a linha de base adiciona a cada sub-rede. A tabela fornece o nome e a função da regra.

Sub-rede Interna De Saída
snet-appGateway Permissões para nossos usuários de interface do usuário de bate-papo IPs de origem (como internet pública), além de itens necessários para o serviço Acesso ao ponto de extremidade privado do Serviço de Aplicativo do Azure, além dos itens necessários para o serviço.
snet-PrivateEndpoints Permita apenas o tráfego da rede virtual. Permita apenas tráfego para a rede virtual.
snet-AppService Permita apenas o tráfego da rede virtual. Permita o acesso aos pontos de extremidade privados e ao Azure Monitor.
AzureBastionSubnet Consulte as orientações sobre como trabalhar com o acesso NSG e o Azure Bastion Consulte as orientações sobre como trabalhar com o acesso NSG e o Azure Bastion
snet-jumpbox Permita RDP e SSH de entrada da sub-rede Bastion Host. Permitir o acesso aos pontos finais privados
Agentes SNET Permita apenas o tráfego da rede virtual. Permita apenas tráfego para a rede virtual.
SNET-Formação Permita apenas o tráfego da rede virtual. Permita apenas tráfego para a rede virtual.
pontuação líquida Permita apenas o tráfego da rede virtual. Permita apenas tráfego para a rede virtual.

Todo o outro tráfego é explicitamente negado.

Considere os seguintes pontos ao implementar a segmentação e a segurança da rede virtual.

  • Habilite a proteção contra DDoS para a rede virtual com uma sub-rede que faça parte de um gateway de aplicativo com um IP público.
  • Adicione um NSG a cada sub-rede sempre que possível. Você deve usar as regras mais rígidas que permitem a funcionalidade completa da solução.
  • Use grupos de segurança de aplicativos. Os grupos de segurança de aplicativos permitem agrupar NSGs, facilitando a criação de regras para ambientes complexos.

Filtragem de conteúdo e monitoramento de abuso

O serviço Azure OpenAI inclui um sistema de filtragem de conteúdo que usa um conjunto de modelos de classificação para detetar e prevenir categorias específicas de conteúdo potencialmente prejudicial em prompts de entrada e conclusão de saída. As categorias para este conteúdo potencialmente prejudicial incluem ódio, sexo, automutilação, violência, palavrões e jailbreak (conteúdo projetado para contornar as restrições de um LLM). Você pode configurar o rigor do que deseja filtrar o conteúdo para cada categoria, com opções baixas, médias ou altas. Esta arquitetura de referência adota uma abordagem rigorosa. Você deve ajustar as configurações de acordo com suas necessidades.

Além da filtragem de conteúdo, o serviço Azure OpenAI implementa recursos de monitoramento de abuso. O monitoramento de abuso é uma operação assíncrona projetada para detetar e mitigar instâncias de conteúdo recorrente e/ou comportamentos que sugerem o uso do serviço de uma maneira que pode violar o código de conduta do Azure OpenAI. Você pode solicitar uma isenção de monitoramento de abuso e revisão humana, por exemplo, se seus dados forem altamente confidenciais ou se houver políticas internas ou regulamentações legais aplicáveis que impeçam o processamento de dados para deteção de abuso.

Fiabilidade

A arquitetura de aplicativo Web do Serviço de Aplicativo de base se concentra na redundância zonal para os principais serviços regionais. As zonas de disponibilidade são locais fisicamente separados dentro de uma região. Eles fornecem redundância dentro de uma região para serviços de suporte quando duas ou mais instâncias são implantadas em todas elas. Quando uma zona sofre tempo de inatividade, as outras zonas dentro da região ainda podem não ser afetadas. A arquitetura também garante instâncias suficientes dos serviços do Azure e a configuração desses serviços para serem espalhadas pelas zonas de disponibilidade. Consulte a linha de base para rever essas orientações.

Esta seção aborda a confiabilidade da perspetiva dos componentes nessa arquitetura não abordados na linha de base do Serviço de Aplicativo, incluindo o Azure Machine Learning, o Azure OpenAI e o Azure AI Search.

Redundância zonal para implantações de fluxo

As implantações corporativas geralmente exigem pelo menos redundância zonal. Para conseguir isso no Azure, os recursos devem dar suporte a zonas de disponibilidade e você deve implantar pelo menos as instâncias do recurso ou habilitar o suporte à plataforma quando o controle de instância não estiver disponível. Atualmente, a computação do Azure Machine Learning não oferece suporte para zonas de disponibilidade. Para mitigar o impacto potencial de uma catástrofe no nível do datacenter nos componentes AML, é necessário estabelecer clusters em várias regiões, juntamente com a implantação de um balanceador de carga para distribuir chamadas entre esses clusters. Você usaria verificações de integridade para ajudar a garantir que as chamadas sejam roteadas apenas para clusters que estejam funcionando corretamente.

A implantação de fluxos de prompt não está limitada aos clusters de computação do Azure Machine Learning. O fluxo executável, sendo um aplicativo em contêineres, pode ser implantado em qualquer serviço do Azure que seja compatível com contêineres. Essas opções incluem serviços como o Serviço Kubernetes do Azure (AKS), o Azure Functions, os Aplicativos de Contêiner do Azure (ACA) e o Serviço de Aplicativo do Azure. Cada um desses serviços suporta zonas de disponibilidade. Para obter redundância zonal para execução rápida de fluxo, sem a complexidade adicional de uma implantação de várias regiões, você deve implantar seus fluxos em um desses serviços.

A seguir está uma arquitetura alternativa onde os fluxos de prompt são implantados no Serviço de Aplicativo do Azure. O Serviço de Aplicativo é usado nessa arquitetura porque a carga de trabalho já o usa para a interface do usuário do chat e não se beneficiaria da introdução de uma nova tecnologia na carga de trabalho. As equipes de carga de trabalho que têm experiência com o AKS devem considerar a implantação nesse ambiente, especialmente se o AKS estiver sendo usado para outros componentes na carga de trabalho.

Diagram that shows a baseline end-to-end chat architecture with OpenAI with prompt flow deployed to Azure App Service.

Figura 4: Arquitetura de chat alternativa de ponta a ponta com OpenAI implantando fluxos de prompt nos Serviços de Aplicativo do Azure

O diagrama é numerado para áreas que são notáveis nesta arquitetura:

  1. Os fluxos ainda são criados no fluxo de prompt do Azure Machine Learning e a arquitetura de rede do Azure Machine Learning permanece inalterada. Os autores de fluxo ainda se conectam à experiência de criação do espaço de trabalho por meio de um ponto de extremidade privado e os pontos de extremidade privados gerenciados são usados para se conectar aos serviços do Azure ao testar fluxos.
  2. Essa linha pontilhada indica que os fluxos executáveis em contêineres são enviados por push para o Registro de Contêiner do Azure (ACR). Não são mostrados no diagrama os pipelines que conteinerizam os fluxos e empurram para o ACR.
  3. Há outro Aplicativo Web implantado no mesmo plano do Serviço de Aplicativo que já está hospedando a interface do usuário do chat. O novo Aplicativo Web hospeda o fluxo de prompt em contêiner, colocalizado no mesmo plano do Serviço de Aplicativo que já é executado em um mínimo de três instâncias, distribuídas por zonas de disponibilidade. Essas instâncias do Serviço de Aplicativo se conectam ao ACR por meio de um ponto de extremidade privado ao carregar a imagem do contêiner de fluxo de prompt.
  4. O contêiner de fluxo de prompt precisa se conectar a todos os serviços dependentes para a execução do fluxo. Nesta arquitetura, isso seria para o Azure AI Search e o serviço Azure OpenAI. Os serviços PaaS que foram expostos apenas à sub-rede de ponto de extremidade privada gerenciada pela AML agora também precisam ser expostos na rede virtual para que a linha de visão possa ser estabelecida a partir do Serviço de Aplicativo.

Azure OpenAI - fiabilidade

Atualmente, o Azure OpenAI não oferece suporte a zonas de disponibilidade. Para mitigar o impacto potencial de uma catástrofe no nível do datacenter nas implantações de modelo no Azure OpenAI, é necessário implantar o Azure OpenAI em várias regiões, juntamente com a implantação de um balanceador de carga para distribuir chamadas entre as regiões. Você usaria verificações de integridade para ajudar a garantir que as chamadas sejam roteadas apenas para clusters que estejam funcionando corretamente.

Para dar suporte a várias instâncias de forma eficaz, recomendamos que você externalize arquivos de ajuste fino, como para uma conta de Armazenamento do Azure com redundância geográfica. Isso minimizará o estado armazenado no serviço Azure OpenAI por região. O ajuste fino ainda precisará ser feito por instância para hospedar a implantação do modelo.

É importante monitorar a taxa de transferência necessária em termos de Tokens por Minuto (TPM) e Solicitações por Minuto (RPM) para garantir que você tenha atribuído TPM suficiente de sua cota para atender à demanda de suas implantações e evitar que as chamadas para seus modelos implantados sejam limitadas. Um gateway como o Azure API Management (APIM) pode ser implantado na frente do(s) seu(s) serviço(s) OpenAI e pode ser configurado para nova tentativa no caso de erros transitórios e limitação. O APIM também pode ser usado como um disjuntor para evitar que o serviço fique sobrecarregado com chamadas, excedendo sua cota.

Azure AI Search - fiabilidade

Implante o Azure AI Search com a camada de preço padrão ou superior em uma região que ofereça suporte a zonas de disponibilidade e implante três ou mais réplicas. As réplicas distribuem-se automaticamente uniformemente pelas zonas de disponibilidade.

Considere as seguintes orientações para determinar o número apropriado de réplicas e partições:

  • Siga as orientações para monitorar a Pesquisa de IA do Azure.
  • Use métricas e logs de monitoramento e análise de desempenho para determinar o número apropriado de réplicas para evitar a limitação baseada em consulta e partições para evitar a limitação baseada em índice.

Azure Machine Learning - fiabilidade

Se você implantar em clusters de computação por trás do ponto de extremidade online gerenciado do Azure Machine Learning, considere as seguintes orientações sobre dimensionamento:

  • Siga as orientações para dimensionar automaticamente seus endpoints on-line para garantir que haja capacidade suficiente disponível para atender à demanda. Se os sinais de uso não forem oportunos o suficiente devido ao uso de intermitência, considere o provisionamento excessivo para evitar o impacto na confiabilidade de poucas instâncias disponíveis.
  • Considere a criação de regras de dimensionamento com base em métricas de implantação, como carga da CPU, e métricas de ponto final, como latência de solicitação.
  • Pelo menos três instâncias devem ser implantadas para uma implantação de produção ativa.
  • Evite implantações em instâncias em uso. Em vez disso, implante em uma nova implantação e transfira o tráfego depois que a implantação estiver pronta para receber tráfego.

Nota

A mesma orientação de escalabilidade do Serviço de Aplicativo da arquitetura de linha de base se aplica se você implantar seu fluxo no Serviço de Aplicativo do Azure.

Segurança

Essa arquitetura implementa um perímetro de segurança de rede e de identidade. Do ponto de vista da rede, a única coisa que deve ser acessível a partir da internet é a interface do usuário do bate-papo por meio do App Gateway. Do ponto de vista da identidade, a interface do usuário do chat deve autenticar e autorizar solicitações. As identidades gerenciadas são usadas, sempre que possível, para autenticar aplicativos nos serviços do Azure.

A segurança da rede foi discutida na seção de rede. Esta seção discute o gerenciamento de identidade e acesso e considerações de segurança para rotação de chaves e ajuste fino do modelo do Azure OpenAI.

Gestão de identidades e acessos

As diretrizes a seguir estendem as diretrizes de gerenciamento de identidade e acesso na linha de base do Serviço de Aplicativo:

  • Crie identidades gerenciadas separadas para os seguintes recursos de AML, quando aplicável:
    • Espaço de trabalho - usado durante a criação e o gerenciamento de fluxo
    • Instância de computação - usada ao testar fluxos
    • Ponto de extremidade online - usado pelo fluxo implantado se implantado em um ponto de extremidade online gerenciado
  • Implementar controles de acesso de identidade para a interface do usuário do chat usando o ID do Microsoft Entra

Funções do RBAC do Azure Machine Learning

Há cinco funções padrão que você pode usar para gerenciar o acesso ao seu espaço de trabalho do Azure Machine Learning: Cientista de Dados do AzureML, Operador de Computação do AzureML, Leitor, Colaborador e Proprietário. Junto com essas funções padrão, há um Leitor de Segredos de Conexão do Espaço de Trabalho AzureML e um Usuário do Registro do AzureML que concedem acesso a recursos do espaço de trabalho, como os segredos do espaço de trabalho e o Registro.

Essa arquitetura segue o princípio de menor privilégio, atribuindo funções apenas às identidades acima onde elas são necessárias. A seguir estão as atribuições de função.

Identidade gerida Âmbito Atribuições de funções
Identidade gerenciada do espaço de trabalho Grupo de recursos Contribuidor
Identidade gerenciada do espaço de trabalho Conta de armazenamento do espaço de trabalho Contribuidor de Dados de Blobs de Armazenamento
Identidade gerenciada do espaço de trabalho Conta de armazenamento do espaço de trabalho Contribuidor com Privilégios aos Dados dos Ficheiros de Armazenamento
Identidade gerenciada do espaço de trabalho Cofre da chave do espaço de trabalho Administrador do Cofre de Chaves
Identidade gerenciada do espaço de trabalho Registro de contêiner de espaço de trabalho ACRPush
Identidade gerenciada de endpoint online Registro de contêiner de espaço de trabalho AcrPull
Identidade gerenciada de endpoint online Conta de armazenamento do espaço de trabalho Leitor de Dados de Blobs de Armazenamento
Identidade gerenciada de endpoint online Espaço de trabalho de Aprendizado de Máquina Leitor de segredos de conexão do espaço de trabalho AzureML
Identidade gerenciada da instância de computação Registro de contêiner de espaço de trabalho ACRPull
Identidade gerenciada da instância de computação Conta de armazenamento do espaço de trabalho Leitor de Dados de Blobs de Armazenamento

Rotação de chaves

Há dois serviços nessa arquitetura que usam a autenticação baseada em chave: o Azure OpenAI e o ponto de extremidade online gerenciado do Azure Machine Learning. Como você está usando a autenticação baseada em chave para esses serviços, é importante:

  • Armazene a chave em um repositório seguro como o Azure Key Vault para acesso sob demanda de clientes autorizados (como o Aplicativo Web do Azure que hospeda o contêiner de fluxo de prompt).
  • Implementar uma estratégia de rotação de chaves. Se você girar manualmente as chaves, deverá criar uma política de expiração de chave e usar a política do Azure para monitorar se a chave foi girada.

Ajuste fino do modelo OpenAI

Se você estiver ajustando modelos OpenAI em sua implementação, considere as seguintes orientações:

  • Se você estiver carregando dados de treinamento para ajuste fino, considere usar chaves gerenciadas pelo cliente para criptografar esses dados.
  • Se você estiver armazenando dados de treinamento em um armazenamento como o Armazenamento de Blobs do Azure, considere usar uma chave gerenciada pelo cliente para criptografia de dados, use uma identidade gerenciada para controlar o acesso aos dados e um ponto de extremidade privado para se conectar aos dados.

Eficiência de desempenho

Eficiência de desempenho é a capacidade da sua carga de trabalho para dimensionar para satisfazer as exigências que os utilizadores lhe colocam de forma eficiente. Para obter mais informações, consulte Visão geral do pilar de eficiência de desempenho.

Esta seção discute a eficiência de desempenho da perspetiva do Azure Search, Azure OpenAI e Azure Machine Learning.

Azure Search - eficiência de desempenho

Siga as orientações para analisar o desempenho no Azure AI Search.

Azure OpenAI - eficiência de desempenho

  • Determine se seu aplicativo requer taxa de transferência provisionada ou usará o modelo de hospedagem compartilhada (consumo). A taxa de transferência provisionada oferece capacidade de processamento reservada para suas implantações de modelo OpenAI, fornecendo desempenho e taxa de transferência previsíveis para seus modelos. Este modelo de faturamento é diferente do modelo de hospedagem compartilhada (consumo), que é o melhor esforço e pode estar sujeito a vizinhos barulhentos ou outros estressores na plataforma.
  • Para taxa de transferência provisionada, você deve monitorar a utilização gerenciada por provisionamento

Azure Machine Learning - eficiência de desempenho

Se estiver implantando em pontos de extremidade online do Azure Machine Learning:

  • Siga as orientações sobre como dimensionar automaticamente um endpoint on-line para ficar alinhado com a demanda, sem excesso de provisionamento, especialmente em períodos de baixo uso.
  • Escolha a SKU de máquina virtual apropriada para o ponto de extremidade online para atender às suas metas de desempenho. Você deseja testar o desempenho de uma contagem de instâncias mais baixa e de SKUs maiores versus uma contagem de instâncias maior e SKUs menores para encontrar uma configuração ideal.

Otimização de custos

A otimização de custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Visão geral do pilar de otimização de custos.

Para ver um exemplo de definição de preço para este cenário, utilize a calculadora de preços do Azure. Você precisará personalizar o exemplo para corresponder ao seu uso, pois este exemplo inclui apenas os componentes incluídos na arquitetura. Os componentes mais caros no cenário são a computação de fluxo de prompt de interface do usuário de chat & e a Pesquisa de IA do Azure, portanto, procure a otimização em torno desses recursos para economizar o máximo de custos.

Computação

O fluxo de prompt do Azure Machine Learning dá suporte a várias opções para hospedar os fluxos executáveis. As opções incluem pontos de extremidade online gerenciados no Azure Machine Learning, no Serviço Kubernetes do Azure, no Serviço de Aplicativo do Azure e no Serviço de Contêiner do Azure. Cada uma destas opções tem o seu próprio modelo de faturação. A escolha da computação afeta o custo geral da solução.

Azure OpenAI

O Azure OpenAI é um serviço baseado no consumo e, como acontece com qualquer serviço baseado no consumo, controlar a procura em relação à oferta é o principal controlo de custos. Para fazer isso no serviço OpenAI do Azure especificamente, você precisa empregar uma combinação de abordagens:

  • Controlar clientes. As solicitações do cliente são a principal fonte de custo em um modelo de consumo, pois controlar o comportamento do cliente é fundamental. Todos os clientes devem:
    • Ser aprovado. Evite expor o serviço de tal forma que suporte o acesso gratuito para todos. Limite o acesso através de controles de rede e identidade (chave ou RBAC).
    • Seja autocontrolado. Exija que os clientes usem as restrições de limitação de token oferecidas pelas chamadas de API, como max_tokens e max_completions.
    • Use lotes, quando possível. Analise os clientes para garantir que eles estejam enviando prompts em lote adequadamente.
    • Otimize a entrada imediata e o comprimento da resposta. Prompts mais longos consomem mais tokens, aumentando o custo, mas prompts que estão faltando contexto suficiente não ajudam os modelos a produzir bons resultados. Crie prompts concisos que forneçam contexto suficiente para permitir que o modelo gere uma resposta útil. Da mesma forma, certifique-se de otimizar o limite do comprimento da resposta.
  • O uso do playground do Azure OpenAI deve ser conforme necessário e em instâncias de pré-produção, para que essas atividades não incorram em custos de produção.
  • Selecione o modelo de IA certo. A seleção de modelos também desempenha um grande papel no custo geral do Azure OpenAI. Todos os modelos têm pontos fortes e fracos e têm preços individuais. Usar o modelo correto para o caso de uso pode garantir que você não está gastando demais em um modelo mais caro quando um modelo mais barato produz resultados aceitáveis. Nesta implementação de referência de chat, o GPT 3.5-turbo foi escolhido em vez do GPT-4 para economizar cerca de uma ordem de magnitude dos custos de implantação do modelo enquanto alcançava resultados suficientes.
  • Entenda os pontos de interrupção de faturamento - O ajuste fino é cobrado por hora. Para ser o mais eficiente, você vai querer utilizar o máximo desse tempo disponível por hora para melhorar os resultados de ajuste fino, evitando apenas escorregar para o próximo período de faturamento. Da mesma forma, o custo para 100 imagens da geração de imagem é o mesmo que o custo para 1 imagem. Maximize os pontos de quebra de preço a seu favor.
  • Compreender os modelos de faturação - O Azure OpenAI também está disponível num modelo de faturação baseado em compromisso através da oferta de taxa de transferência provisionada. Depois de ter padrões de uso previsíveis, avalie a mudança para esse modelo de faturamento de pré-compra se ele calcular ser mais econômico em seu volume de uso.
  • Definir limites de provisionamento - Certifique-se de que toda a cota de provisionamento seja alocada apenas para modelos que devem fazer parte da carga de trabalho, por modelo. A taxa de transferência para modelos já implantados não está limitada a essa cota provisionada enquanto a cota dinâmica está habilitada. Observe que a cota não é mapeada diretamente para os custos e o custo pode variar.
  • Monitore o uso de pagamento conforme o uso - Se estiver usando o pagamento conforme o uso, monitore o uso de Tokens por Minuto (TPM) e Solicitações por Minuto (RPM). Use essas informações para informar decisões de projeto de arquitetura, como quais modelos usar, bem como otimizar tamanhos de prompt.
  • Monitorar o uso da taxa de transferência provisionada - Se estiver usando a taxa de transferência provisionada, monitore a utilização gerenciada por provisionamento para garantir que você não esteja subutilizando a taxa de transferência provisionada adquirida.
  • Gerenciamento de custos - Siga as orientações sobre como usar recursos de gerenciamento de custos com o OpenAI para monitorar custos, definir orçamentos para gerenciar custos e criar alertas para notificar as partes interessadas sobre riscos ou anomalias.

Operações de modelo de linguagem grande (LLMOps)

A implantação de soluções de chat baseadas no Azure OpenAI, como essa arquitetura, deve seguir as orientações do LLMOps com fluxo imediato com o Azure DevOps e o GitHub. Além disso, deve considerar as práticas recomendadas para arquiteturas de CI/CD e protegidas por rede. As orientações a seguir abordam a implementação de fluxos e sua infraestrutura associada com base nas recomendações LLMOps. Esta orientação de implantação não inclui os elementos de aplicativo front-end, que não são alterados na arquitetura de aplicativo Web com redundância de zona altamente disponível da Linha de Base.

Desenvolvimento

O fluxo de prompt do Azure Machine Learning oferece uma experiência de criação baseada em navegador no estúdio do Azure Machine Learning ou por meio de uma extensão VS Code. Ambas as opções armazenam o código de fluxo como arquivos. Ao usar o estúdio do Azure Machine Learning, os arquivos são armazenados em uma Conta de Armazenamento do Azure. Ao trabalhar no VS Code, os arquivos são armazenados em seu sistema de arquivos local.

A fim de seguir as melhores práticas para o desenvolvimento colaborativo, os arquivos de origem devem ser mantidos em um repositório de código-fonte on-line, como o GitHub. Essa abordagem facilita o rastreamento de todas as alterações de código, a colaboração entre os autores de fluxo e a integração com fluxos de implantação que testam e validam todas as alterações de código.

Para desenvolvimento empresarial, você deve usar a extensão VS Code e o prompt flow SDK/CLI para desenvolvimento. Os autores de fluxo imediato podem criar e testar seus fluxos a partir do VS Code e integrar os arquivos armazenados localmente com o sistema de controle de origem on-line e pipelines. Embora a experiência baseada em navegador seja adequada para desenvolvimento exploratório, com algum trabalho, ela pode ser integrada ao sistema de controle do código-fonte. A pasta de fluxo pode ser baixada da página de fluxo no Files painel, descompactada e enviada para o sistema de controle do código-fonte.

Avaliação

Você deve testar os fluxos usados em um aplicativo de bate-papo assim como testa outros artefatos de software. É desafiador especificar e afirmar uma única resposta "certa" para saídas LLM, mas você pode usar um LLM em si para avaliar respostas. Considere a implementação das seguintes avaliações automatizadas de seus fluxos de LLM:

  • Precisão de classificação: Avalia se o LLM dá uma pontuação "correta" ou "incorreta" e agrega os resultados para produzir uma nota de precisão.
  • Coerência: Avalia quão bem as frases na resposta prevista de um modelo são escritas e como elas se conectam coerentemente umas com as outras.
  • Fluência: Avalia a resposta prevista do modelo quanto à sua precisão gramatical e linguística.
  • Fundamentação em relação ao contexto: avalia o quão bem as respostas previstas do modelo são baseadas no contexto pré-configurado. Mesmo que as respostas do LLM estejam corretas, se não puderem ser validadas em relação ao contexto dado, tais respostas não serão fundamentadas.
  • Relevância: Avalia o quão bem as respostas previstas do modelo se alinham com a pergunta feita.

Considere as seguintes orientações ao implementar avaliações automatizadas:

  • Produza pontuações de avaliações e meça-as em relação a um limiar de sucesso predefinido. Use essas pontuações para relatar aprovação/reprovação no teste em seus pipelines.
  • Alguns desses testes exigem entradas de dados pré-configuradas de perguntas, contexto e verdade básica.
  • Inclua pares de perguntas e respostas suficientes para garantir que os resultados dos testes sejam confiáveis, com pelo menos 100 a 150 pares recomendados. Esses pares pergunta-resposta são chamados de "conjunto de dados dourado". Uma população maior pode ser necessária, dependendo do tamanho e do domínio do seu conjunto de dados.
  • Evite usar LLMs para gerar qualquer um dos dados em seu conjunto de dados dourado.

Fluxo de implantação

Diagram that shows the deployment flow for a prompt flow.

Figura 5: Implantação do fluxo de prompt

  1. O engenheiro de prompt/cientista de dados abre uma ramificação de recurso onde eles trabalham na tarefa ou recurso específico. O engenheiro de prompt/cientista de dados itera no fluxo usando o fluxo de prompt para VS Code, confirmando periodicamente as alterações e enviando essas alterações para a ramificação do recurso.

  2. Quando o desenvolvimento local e a experimentação são concluídos, o engenheiro/cientista de dados pronto abre uma solicitação pull da ramificação Recurso para a ramificação Principal. A solicitação pull (PR) aciona um pipeline de RP. Esse pipeline executa verificações de qualidade rápidas que devem incluir:

    • Execução de fluxos de experimentação
    • Execução de testes de unidade configurados
    • Compilação da base de código
    • Análise de código estático
  3. O pipeline pode conter uma etapa que requer que pelo menos um membro da equipe aprove manualmente o PR antes da fusão. O aprovador não pode ser o committer e eles têm experiência em fluxo rápido e familiaridade com os requisitos do projeto. Se o PR não for aprovado, a mesclagem será bloqueada. Se o PR for aprovado, ou não houver nenhuma etapa de aprovação, a ramificação do recurso será mesclada na ramificação principal.

  4. A mesclagem para Main aciona o processo de compilação e liberação para o ambiente de desenvolvimento. Especificamente:

    a. O pipeline de CI é acionado a partir da mesclagem para Main. O pipeline de CI executa todas as etapas feitas no pipeline de RP e as seguintes etapas:

    • Fluxo de experimentação
    • Fluxo de avaliação
    • Registra os fluxos no Registro do Azure Machine Learning quando alterações são detetadas

    b. O pipeline de CD é acionado após a conclusão do pipeline de CI. Esse fluxo executa as seguintes etapas:

    • Implanta o fluxo do Registro do Azure Machine Learning em um ponto de extremidade online do Azure Machine Learning
    • Executa testes de integração direcionados ao ponto de extremidade online
    • Executa testes de fumaça que visam o ponto de extremidade on-line
  5. Um processo de aprovação é incorporado ao processo de promoção de lançamento – após a aprovação, os processos CI & CD descritos nas etapas 4.a. & 4.b. são repetidos, visando o ambiente de teste. As etapas a. e b. são as mesmas, exceto que os testes de aceitação do usuário são executados após os testes de fumaça no ambiente de teste.

  6. Os processos CI & CD descritos nas etapas 4.a. & 4.b. são executados para promover a liberação para o ambiente de produção depois que o ambiente de teste é verificado e aprovado.

  7. Após o lançamento em um ambiente ao vivo, as tarefas operacionais de monitoramento de métricas de desempenho e avaliação do LLM implantado ocorrem. Isso inclui, mas não está limitado a:

    • Deteção de desvios de dados
    • Observar a infraestrutura
    • Gestão de custos
    • Comunicar o desempenho do modelo às partes interessadas

Diretrizes de implantação

Os Pontos de Extremidade do Azure Machine Learning permitem que você implante modelos de uma forma que permita flexibilidade ao liberar para produção. Considere as seguintes estratégias para garantir o melhor desempenho e qualidade do modelo:

  • Implantações azuis/verdes: com essa estratégia, você pode implantar com segurança sua nova versão do serviço Web para um grupo limitado de usuários ou solicitações antes de direcionar todo o tráfego para a nova implantação.
  • Testes A/B: As implantações Azul/Verde não só são eficazes para implementar alterações com segurança, mas também podem ser usadas para implantar um novo comportamento que permite que um subconjunto de usuários avalie o impacto da alteração.
  • Inclua linting de arquivos Python que fazem parte do fluxo de prompt em seus pipelines. Linting verifica a conformidade com padrões de estilo, erros, complexidade de código, importações não utilizadas e nomenclatura variável.
  • Ao implantar seu fluxo no espaço de trabalho do Azure Machine Learning isolado em rede, use um agente auto-hospedado para implantar artefatos em seus recursos do Azure.
  • O registro do modelo do Azure Machine Learning só deve ser atualizado quando houver alterações no modelo.
  • O LLM, os fluxos e a interface do usuário do cliente devem ser acoplados de forma flexível. As atualizações dos fluxos e da interface do usuário do cliente podem e devem ser feitas sem afetar o modelo e vice-versa.
  • Ao desenvolver e implantar vários fluxos, cada fluxo deve ter seu próprio ciclo de vida, o que permite uma experiência de acoplamento flexível ao promover fluxos da experimentação à produção.

Infraestrutura

Ao implantar os componentes de chat de ponta a ponta do Azure OpenAI de linha de base, alguns dos serviços provisionados são fundamentais e permanentes dentro da arquitetura, enquanto outros componentes são de natureza mais efêmera, sua existência vinculada a uma implantação.

Componentes fundamentais

Alguns componentes nessa arquitetura existem com um ciclo de vida que se estende além de qualquer fluxo de prompt individual ou qualquer implantação de modelo. Esses recursos geralmente são implantados uma vez como parte da implantação fundamental pela equipe de carga de trabalho e mantidos além de novos, removidos ou atualizações para os fluxos de prompt ou implantações de modelo.

  • Área de trabalho do Azure Machine Learning
  • Conta de Armazenamento do Azure para o espaço de trabalho do Azure Machine Learning
  • Registo de Contentores do Azure
  • Azure AI Search
  • Azure OpenAI
  • Azure Application Insights
  • Azure Bastion
  • Máquina Virtual do Azure para a caixa de salto

Componentes efêmeros

Alguns recursos do Azure são mais estreitamente acoplados ao design de fluxos de prompt específicos, permitindo que esses recursos sejam vinculados ao ciclo de vida do componente e se tornem efêmeros nessa arquitetura. Eles são afetados quando a carga de trabalho evolui, como quando os fluxos são adicionados ou removidos ou quando novos modelos são introduzidos. Esses recursos são recriados e as instâncias anteriores removidas. Alguns desses recursos são recursos diretos do Azure e alguns são manifestações do plano de dados dentro de seu serviço de contenção.

  • O modelo no registro do modelo do Azure Machine Learning deve ser atualizado, se alterado, como parte do pipeline de CD.
  • A imagem do contêiner deve ser atualizada no registro do contêiner como parte do pipeline do CD.
  • Um ponto de extremidade do Azure Machine Learning é criado quando um fluxo de prompt é implantado se a implantação fizer referência a um ponto de extremidade que não existe. Esse ponto de extremidade precisa ser atualizado para desativar o acesso público.
  • As implantações do ponto de extremidade do Azure Machine Learning são atualizadas quando um fluxo é implantado ou excluído.
  • O Cofre da Chave para a interface do usuário do cliente deve ser atualizado com a chave para o ponto de extremidade quando um novo ponto de extremidade é criado.

Monitorização

Os diagnósticos são configurados para todos os serviços. Todos os serviços, exceto o Azure Machine Learning e o Serviço de Aplicativo do Azure, são configurados para capturar todos os logs. O diagnóstico do Azure Machine Learning é configurado para capturar os logs de auditoria, que são todos os logs de recursos que registram as interações do cliente com dados ou as configurações do serviço. O Serviço de Aplicativo do Azure está configurado para capturar AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs e AppServicePlatformLogs.

Implementar este cenário

Para implantar e executar a implementação de referência, siga as etapas na implementação de referência de linha de base de ponta a ponta do OpenAI.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

  • Rob Bagby - Brasil | Padrões e práticas - Microsoft
  • Freddy Ayala - Brasil | Arquiteto de Soluções na Nuvem - Microsoft
  • Prabal Deb - Brasil | Engenheiro de Software Sênior - Microsoft
  • Raouf Aliouat - Brasil | Engenheiro de Software II - Microsoft
  • Ritesh Modi - Brasil | Engenheiro de Software Principal - Microsoft
  • Ryan Pfalz - Brasil | Arquiteto de Soluções Sênior - Microsoft

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos

Leia mais sobre o Azure OpenAI