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

Os aplicativos de chat corporativo podem capacitar os funcionários por meio da interação conversacional. Isso vale principalmente para o avanço contínuo de modelos de linguagem, como os modelos GPT do OpenAI e os modelos LLaMA da Meta. Esses aplicativos de chat consistem em uma interface do usuário (IU) para chat, repositórios de dados que contêm informações específicas do domínio pertinentes às consultas do usuário, modelos de linguagem que racionalizam dados específicos do domínio para produzir uma resposta relevante e um orquestrador que supervisiona a interação entre esses componentes.

Este artigo apresenta uma arquitetura de linha de base para compilar e implantar aplicativos de chat corporativo que usam modelos de linguagem do Serviço OpenAI do Azure. A arquitetura emprega o prompt flow do Azure Machine Learning para criar fluxos executáveis. Esses fluxos executáveis orquestram o fluxo de trabalho de prompts de entrada de armazenamentos de dados para buscar dados de embasamento para os modelos de linguagem, junto com outra lógica Python necessária. O fluxo executável é implantado em um cluster de cálculo do Machine Learning atrás de um ponto de extremidade online gerenciado.

A hospedagem da interface do usuário (UI) de bate-papo personalizada segue as diretrizes do aplicativo Web dos 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 a solução de PaaS (plataforma como serviço) do Azure por meio da integração de rede virtual em pontos de extremidade privados. O Serviço de Aplicativo da interface do usuário do chat se comunica com o ponto de extremidade online gerenciado do fluxo em um ponto de extremidade privado. O acesso público ao Workspace do Machine Learning está desabilitado.

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

Arquitetura

Baixe um Arquivo Visio dessa arquitetura.

Componentes

Muitos componentes dessa arquitetura são os mesmos que a arquitetura básica de chat de ponta a ponta do OpenAI do Azure. A lista a seguir destaca apenas as alterações na arquitetura básica.

• O Azure OpenAI é usado na arquitetura básica e nessa arquitetura de linha de base. O OpenAI do Azure é um serviço totalmente gerenciado que dá acesso à API REST a modelos de linguagem do OpenAI do Azure, inclusive o conjunto de modelos GPT-4, GPT-3.5-Turbo e Incorporações. A arquitetura de linha de base aproveita recursos empresariais, como rede virtual e link privado, que a arquitetura básica não implementa.
• O Gateway de Aplicativo é um balanceador de carga de camada 7 (HTTP/S) e um roteador de tráfego da Web. Ele usa o roteamento baseado em caminho de URL para distribuir o tráfego de entrada entre zonas de disponibilidade e descarrega a criptografia para melhorar o desempenho do aplicativo.
• O WAF (Firewall de Aplicativo Web) é um serviço nativo da nuvem que protege aplicativos Web contra explorações comuns, como injeção de SQL e scripts entre sites. O Firewall de Aplicativo Web fornece visibilidade sobre o tráfego proveniente e destinado ao seu aplicativo Web, permitindo que você monitore e proteja seu aplicativo.
• O Cofre de Chaves do Azure é um serviço que armazena e gerencia com segurança segredos, chaves de criptografia e certificados. Centraliza o gerenciamento de informações sensíveis.
• A rede virtual do Azure é um serviço que permite criar redes virtuais privadas isoladas e seguras no Azure. Para um aplicativo Web no Serviço de Aplicativo, você precisa de uma sub-rede de rede virtual para usar pontos de extremidade privados para comunicação segura de rede entre recursos.
• Private Link possibilita que os clientes acessem os serviços de PaaS (plataforma como serviço) do Azure diretamente de redes virtuais privadas sem usar o endereçamento IP público.
• Azure DNS é um serviço de hospedagem para domínios DNS que fornece a resolução de nomes usando a infraestrutura do Microsoft Azure. As zonas DNS privadas fornecem uma maneira de mapear o FQDN (nome de domínio totalmente qualificado) de um serviço para o endereço IP de um ponto de extremidade privado.

Recomendações e consideração

Confiabilidade

A confiabilidade garante que seu aplicativo possa cumprir os compromissos que você assume com seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para confiabilidade.

A arquitetura de aplicativo Web do Serviço de Aplicativo da linha 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. Elas oferecem redundância dentro de uma região para dar suporte a serviços quando duas ou mais instâncias são implantadas nelas. Quando uma zona apresenta tempo de inatividade, as outras zonas dentro da região podem não ser afetadas. A arquitetura também garante instâncias suficientes de serviços do Azure e configuração desses serviços para serem espalhadas por zonas de disponibilidade. Para obter mais informações, consulte a linha de base para revisar essas orientações.

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

Redundância zonal para implantações de fluxo

As implantações corporativas normalmente exigem redundância zonal. Para conseguir a redundância zonal no Azure, os recursos devem dar suporte a zonas de disponibilidade, e você deve implantar pelo menos três instâncias do recurso ou habilitar o suporte à plataforma quando o controle de instância não está disponível. Atualmente, a computação do Machine Learning não dá suporte para zonas de disponibilidade. Para atenuar o impacto potencial de uma catástrofe sobre o nível do datacenter em componentes do Machine Learning, é necessário estabelecer clusters em regiões variadas com a implantação de um load balancer para distribuir chamadas dentre esses clusters. Você pode usar verificações de integridade para ajudar a garantir que as chamadas só sejam encaminhadas a clusters que estejam funcionando corretamente.

A implantação de prompt flows não se limita aos clusters de cálculo do Machine Learning. O fluxo executável, sendo um aplicativo conteinerizado, pode ser implantado em qualquer serviço do Azure compatível com contêineres. Entre essas opções estão serviços como o Serviço do Azure Kubernetes (AKS), do Azure Functions, dos Aplicativos de Contêiner do Azure e do Serviço de Aplicativo do Azure. Todos esses serviços dão suporte a zonas de disponibilidade. Para obter redundância zonal para execução do prompt flow, sem a complexidade adicionada de uma implantação multirregião, você deve implantar os fluxos em um desses serviços.

O diagrama a seguir mostra uma arquitetura alternativa na qual os prompt flows são implantados no Serviço de Aplicativo. O Serviço de Aplicativo é usado nessa arquitetura porque a carga de trabalho já o usa na interface do usuário de bate-papo e não aproveitaria a introdução de uma nova tecnologia no workload. As equipes de workload com experiência com AKS devem levar em consideração a implantação nesse ambiente, especialmente se o AKS estiver sendo usado em outros componentes no workload.

O diagrama é numerado para áreas dignas de nota nesta arquitetura:

1. Os fluxos continuam sendo criados no prompt flow do Machine Learning, e a arquitetura de rede do Machine Learning permanece inalterada. Os autores de fluxo continuam se conectando à experiência de criação do workspace por meio de um ponto de extremidade privado e dos 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 conteinerizados são enviados por push para o Registro de Contêiner. Não são mostrados no diagrama os pipelines que conteinerizam os fluxos e os enviam por push para o Registro de Contêiner.

3. Existe outro Aplicativo Web implantado no mesmo Plano do Serviço de Aplicativo que já está hospedando a interface do usuário de chat. O novo Aplicativo Web hospeda o prompt flow conteinerizado, colocado no mesmo Plano do Serviço de Aplicativo já executado em pelo menos três instâncias, espalhadas por zonas de disponibilidade. Essas instâncias do Serviço de Aplicativo se conectam ao Registro de Contêiner por meio de um ponto de extremidade privado ao carregar a imagem do contêiner do prompt flow.

4. O contêiner do prompt flow precisa se conectar a todos os serviços dependentes para a execução do fluxo. Nessa arquitetura, o contêiner do prompt flow se conecta ao AI Search e ao OpenAI do Azure. Os serviços PaaS que só foram expostos à sub-rede do ponto de extremidade privado gerenciado por Machine Learning agora também precisam ser expostos na rede virtual de modo que a linha de visão possa ser estabelecida pelo Serviço de Aplicativo.

OpenAI do Azure – confiabilidade

No momento, o OpenAI do Azure não dá suporte a zonas de disponibilidade. Para mitigar o impacto potencial de uma catástrofe no nível do datacenter em implantações de modelo no OpenAI do Azure, é necessário implantar o OpenAI do Azure em regiões variadas, com a implantação de um load balancer para distribuir chamadas entre as regiões. Você pode usar verificações de integridade para ajudar a garantir que as chamadas só sejam encaminhadas a clusters que estejam funcionando corretamente.

Para dar suporte a várias instâncias de maneira eficaz, é recomendável externalizar arquivos de ajuste, como para uma conta de armazenamento com redundância geográfica. Essa abordagem minimiza o estado armazenado no OpenAI do Azure para cada região. Você ainda deve ajustar os arquivos de cada instância para hospedar a implantação de modelo.

É importante monitorar a taxa de transferência necessária em termos de tokens por minuto (TPM) e solicitações por minuto (RPM). Certifique-se de atribuir TPM suficiente a partir da sua cota para atender à demanda das suas implantações e impedir que as chamadas para seus modelos implantados sejam limitadas. Um gateway como o Gerenciamento de API do Azure pode ser implantado na frente dos serviços ou do Serviço OpenAI e pode ser configurado para repetição se houver erros transitórios e limitação. A API Management também pode ser usada como um disjuntor para evitar que o serviço fique sobrecarregado com chamadas, excedendo a cota.

AI Search: confiabilidade

Implante a AI Search com a camada de preços padrão ou superior em uma região que dê suporte a zonas de disponibilidade e implante três ou mais réplicas. As réplicas se espalham automaticamente de maneira uniforme por zonas de disponibilidade.

Leve em consideração as seguintes diretrizes para determinar o número indicado de réplicas e partições:

• Monitore o AI Search.

• Use métricas e logs de monitoramento e análise de desempenho para determinar o número indicado de réplicas para evitar a limitação baseada em consulta e partições e para evitar a limitação baseada em índice.

Machine Learning: confiabilidade

Se você implantar em clusters de cálculo por trás do ponto de extremidade online gerenciado do Machine Learning, leve em consideração as seguintes diretrizes sobre dimensionamento:

• Escale automaticamente os pontos de extremidade online para garantir que a capacidade suficiente esteja disponível para atender à demanda. Se os sinais de uso não forem em tempo hábil o suficiente por causa do uso da intermitência, leve em consideração o superprovisionamento para evitar o impacto na confiabilidade de poucas instâncias disponíveis.

• Leve em consideração a criação das regras de dimensionamento com base em métrica de implantação, como carga de CPU, e métrica do ponto de extremidade, 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 esteja pronta para receber tráfego.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para obter mais informações, consulte Lista de verificação de revisão de design para segurança.

Essa arquitetura estende o volume de segurança implementado no chat básico de ponta a ponta com a arquitetura do OpenAI do Azure. Enquanto a arquitetura básica usa identidades gerenciadas atribuídas pelo sistema e atribuições de função atribuídas pelo sistema, essa arquitetura usa identidades atribuídas pelo usuário com atribuições de função criadas manualmente.

A arquitetura implementa um perímetro de segurança de rede, juntamente com o perímetro de identidade implementado na arquitetura básica. De um ponto de vista da rede, a única coisa que deve ser acessível pela Internet é a interface do usuário de chat por meio do Gateway de Aplicativo. De um ponto de vista da identidade, a interface do usuário de bate-papo deve autenticar e autorizar solicitações. As identidades gerenciadas são usadas, sempre que possível, para autenticar aplicativos nos serviços do Azure.

Juntamente com as considerações de rede, esta seção descreve as considerações de segurança para rotação de chaves e ajuste fino do modelo do OpenAI do Azure.

Gerenciamento de identidade e de acesso

Ao usar identidades gerenciadas atribuídas pelo usuário, considere as seguintes orientações:

• Crie identidades gerenciadas à parte para os seguintes recursos de Machine Learning, quando aplicável:
  • Espaços de trabalho para criação e gerenciamento de fluxo
  • Instâncias de computação para testar fluxos
  • Pontos de extremidade online no fluxo implantado se o fluxo for implantado em um ponto de extremidade online gerenciado
• Implementar controles identity-access para a interface do usuário de chat usando o Microsoft Entra ID

Funções de acesso baseadas em função do Machine Learning

Existem cinco funções padrão que você pode usar para gerenciar o acesso ao Workspace do Azure Machine Learning: Cientista de Dados do AzureML, Operador de Computação do AzureML, Leitor, Colaborador e Proprietário. Com essas funções padrão, existem um Leitor de Segredos de conexão do Workspace do Azure Machine Learning e um Usuário do Registro do AzureML que podem conceder acesso aos recursos do workspace, como os segredos do workspace e o registro.

Como a arquitetura usa identidades gerenciadas atribuídas pelo usuário, você é responsável por criar as atribuições de função apropriadas. Essa arquitetura segue o princípio de privilégio mínimo, só atribuindo funções às identidades anteriores onde elas são necessárias. Considere as seguintes atribuições de função.

Identidade gerenciada	Escopo	Atribuições de função
Identidade gerenciada pelo workspace	Grupo de recursos	Colaborador
Identidade gerenciada pelo workspace	Conta de armazenamento do workspace	Colaborador de Dados do Storage Blob
Identidade gerenciada pelo workspace	Conta de armazenamento do workspace	Colaborador Privilegiado de Dados de Arquivo de Armazenamento
Identidade gerenciada pelo workspace	Cofre de chaves do workspace	Administrador do Key Vault
Identidade gerenciada pelo workspace	Registro de Contêiner do workspace	AcrPush
Identidade gerenciada por ponto de extremidade online	OpenAI do Azure	Usuário do OpenAI de Serviços Cognitivos
Identidade gerenciada por ponto de extremidade online	Registro de Contêiner do workspace	AcrPull
Identidade gerenciada por ponto de extremidade online	Conta de armazenamento do workspace	Leitor de Dados do Blob de Armazenamento
Identidade gerenciada por ponto de extremidade online	Workspace do Machine Learning	Leitor de segredos da conexão do AzureML Workspace
Identidade gerenciada pela instância de computação	Registro de Contêiner do workspace	AcrPull
Identidade gerenciada pela instância de computação	Conta de armazenamento do workspace	Leitor de Dados do Blob de Armazenamento

Rede

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

• Haja um único ponto de entrada seguro para o tráfego da interface do usuário de chat.
• O tráfego de rede seja filtrado.
• Os dados em trânsito sejam criptografados de ponta a ponta com o protocolo TLS.
• A exfiltração de dados seja minimizada usando um link privado para manter o tráfego no Azure.
• Os recursos de rede sejam agrupados e isolados de maneira lógica uns dos outros por meio da segmentação de rede.

Fluxos de rede

Dois fluxos neste diagrama são abordados na arquitetura de aplicativos Web do Serviço de Aplicativo de linha de base: o fluxo de entrada do usuário final para a interface do usuário de chat (1) e o fluxo do Serviço de Aplicativo para os serviços de PaaS do Azure (2). Esta seção se concentra no fluxo do ponto de extremidade online do Machine Learning. O fluxo a seguir vai da interface do usuário de chat executada no aplicativo Web do Serviço de Aplicativo da 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 é encaminhada por meio de um ponto de extremidade privado para o ponto de extremidade online do Machine Learning.
2. O ponto de extremidade online encaminha a chamada para um servidor que está executando o fluxo implantado. O ponto de extremidade online funciona como um load balancer e um roteador.
3. As chamadas para os serviços PaaS do Azure exigidas pelo fluxo implantado são encaminhadas por meio dos pontos de extremidade privados gerenciados.

Entrada no Machine Learning

Nessa arquitetura, o acesso público ao workspace do Machine Learning é desabilitado. Os usuários podem acessar o espaço de trabalho por meio de acesso privado porque a arquitetura segue o ponto de extremidade privado para a configuração do workspace do 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, a interface do usuário de chat do Serviço de Aplicativo pode se conectar a serviços PaaS não expostos à Internet pública, inclusive pontos de extremidade do Azure Machine Learning.

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

O diagrama mostra um autor de prompt flow se conectando por meio do Azure Bastion a uma jump box de máquina virtual. A partir desse jumpbox, o autor pode se conectar ao workspace do Machine Learning por meio de um ponto de extremidade privado na mesma rede da jump box. A conectividade com a rede virtual também pode ser realizada por meio de ExpressRoute ou gateways de VPN e emparelhamento de rede virtual.

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

Recomendamos que você configure o workspace do Machine Learning para isolamento de rede virtual gerenciado que exige 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 os recursos necessários para que a solução funcione, como o Registro de Contêiner e o Armazenamento. As regras de saída definidas pelo usuário são para recursos personalizados, como o OpenAI do Azure ou o AI Search, que o workflow vai usar. Você deve configurar regras de saída definidas pelo usuário. 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, marcas de serviço ou FQDNs (nomes de domínio totalmente qualificados) para pontos de extremidade públicos externos. Nesta arquitetura, a conectividade com os serviços do Azure, como o Registro de Contêiner, o Armazenamento, o Azure Key Vault, o Serviço OpenAI do Azure e o AI Search, é feita por meio do link privado. Embora não esteja 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 das imagens de contêiner base de repositórios externos.

Segmentação e segurança de redes virtuais

A rede nessa arquitetura tem sub-redes à parte para as seguintes finalidades:

• Gateway de Aplicativo
• Componentes de integração do Serviço de Aplicativo
• Pontos de extremidade privados
• Azure Bastion
• Máquina virtual jump box
• Treinamento – não usado para treinamento de modelo na arquitetura
• Pontuação

Cada sub-rede tem um grupo de segurança de rede (NSG) 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 adicionadas pela linha de base a cada sub-rede. A tabela informa o nome da regra e a função.

Sub-rede	Entrada	Saída
snet-appGateway	Permissões para os usuários de interface do usuário de bate-papo criar IPs (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, além dos itens necessários para o serviço.
snet-PrivateEndpoints	Só permitir tráfego da rede virtual.	Só permitir tráfego para a rede virtual.
snet-AppService	Só permitir tráfego da rede virtual.	Permitir acesso aos pontos de extremidade privados e ao Azure Monitor.
AzureBastionSubnet	Consulte orientações em Como trabalhar com acesso NSG e o Azure Bastion.	Consulte orientações em Como trabalhar com acesso NSG e o Azure Bastion.
snet-jumpbox	Permitir conexões de protocolo RDP de entrada da sub-rede do host do Azure Bastion.	Permitir acesso aos pontos de extremidade privados
snet-agents	Só permitir tráfego da rede virtual.	Só permitir tráfego para a rede virtual.
snet-training	Só permitir tráfego da rede virtual.	Só permitir tráfego para a rede virtual.
snet-scoring	Só permitir tráfego da rede virtual.	Só permitir tráfego para a rede virtual.

Todo outro tráfego é explicitamente negado.

Leve em consideração os pontos a seguir 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 endereço IP público.

• Adicione um NSG a cada sub-rede sempre que possível. Use as regras mais rígidas que habilitam a funcionalidade da solução completa.

• Use grupos de segurança de aplicativos para agrupar NSGs. O agrupamento de NSGs facilita a criação de regras para ambientes complexos.

Alteração de chaves

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

• Armazenar a chave em um repositório seguro como o Key Vault para acesso sob demanda de clientes autorizados, como o Aplicativo Web do Azure que hospeda o contêiner do prompt flow.

• Implementar uma estratégia de rodízio de chaves. Se fizer um rodízio manual das chaves, você deverá criar uma política de expiração de chave e usar a política do Azure para monitorar se houve rodízio da chave.

Ajuste do modelo OpenAI

Se você ajustar modelos OpenAI na implementação, leve em consideração as seguintes diretrizes:

• Se você fizer upload de dados de treinamento para ajuste, leve em consideração o uso de chaves gerenciadas pelo cliente na criptografia desses dados.

• Se você armazenar dados de treinamento em um repositório como o Armazenamento de Blobs do Azure, leve em consideração o uso de uma chave gerenciada pelo cliente na criptografia de dados, use uma identidade gerenciada para controlar o acesso aos dados e um ponto de extremidade privado para se conectar aos dados.

Governança por meio da política

Para ajudar a garantir o alinhamento com a segurança, considere usar a Azure Policy e a política de rede para que as implantações se alinhem aos requisitos da carga de trabalho. O uso da automação da plataforma por meio de políticas reduz a carga das etapas manuais de validação e garante a governança mesmo que os pipelines sejam ignorados. Considere as seguintes políticas de segurança:

• Desabilite a chave ou outro acesso de autenticação local em serviços como os serviços de IA do Azure e o Key Vault.
• Exija uma configuração específica de regras de acesso à rede ou NSGs.
• Exija criptografia, como o uso de chaves gerenciadas pelo cliente.

Atribuições de função do workspace do Azure Machine Learning para o Azure Key Vault

A identidade gerenciada do workspace do Azure Machine Learning requer atribuições de função do plano de controle (Colaborador) e do plano de dados (Administrador do Key Vault). Isso significa que essa identidade tem acesso de leitura e gravação a todos os segredos, chaves e certificados armazenados no cofre de chaves do Azure Key. Se sua carga de trabalho tiver serviços diferentes do Azure Machine Learning que exijam acesso a segredos, chaves ou certificados do Key Vault, sua carga de trabalho ou equipe de segurança poderá não se sentir confortável com o fato de a identidade gerenciada do workspace do Azure Machine Learning ter acesso a esses artefatos. Nesse caso, considere implantar uma instância do Key Vault especificamente para o workspace do Azure Machine Learning e outras instâncias do Azure Key Vault, conforme apropriado para outras partes da carga de trabalho.

Otimização de custo

A otimização de custos é a análise de maneiras de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de design para otimização de custos.

Para ver um exemplo de preços para esse cenário, use a Calculadora de preços do Azure. Você vai precisar personalizar o exemplo de acordo com o uso, pois esse exemplo só inclui os componentes adicionados à arquitetura. Os componentes mais caros no cenário são a interface do usuário de chat e computação do prompt flow e o AI Search. Otimize esses recursos para economizar o máximo de custos.

Computação

O prompt flow do 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 Machine Learning, AKS, Serviço de Aplicativo e Serviço de Kubernetes do Azure. Cada uma dessas opções tem o próprio modelo de faturamento. A escolha da computação afeta o custo geral da solução.

OpenAI do Azure

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

• Controlar clientes. As solicitações de cliente são a principal fonte de custo em um modelo de consumo. Portanto, controlar o comportamento do cliente é algo crítico. Todos os clientes devem:

  • Ser aprovados. Evitar expor o serviço de maneira que dê suporte ao acesso gratuito para todos. Limite o acesso por meio de controles de rede e de identidade, como chaves ou RBAC (controle de acesso baseado em função).

  • Ser autocontrolados. Exija que os clientes usem as restrições de limitação de token oferecidas pelas chamadas à API, como max_tokens e max_completions.

  • Usar processamento em lote, quando isso for prático. Analise os clientes para garantir que eles estejam enviando os prompts em lote da maneira indicada.

  • Otimize a entrada do prompt e o comprimento da resposta. Prompts mais longos consomem mais tokens, o que aumenta o custo, mas prompts que não tenham contexto suficiente não ajudam os modelos a produzir bons resultados. Crie prompts concisos que deem contexto suficiente para permitir que o modelo gere uma resposta útil. Da mesma forma, não se esqueça de otimizar o limite do comprimento da resposta.

• O uso do playground do OpenAI do Azure 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 modelo também desempenha um papel importante no custo geral do OpenAI do Azure. Todos os modelos têm pontos fortes e fracos e preços individuais. Use o modelo correto para o caso de uso para garantir que você não esteja gastando demais em um modelo mais caro quando um modelo mais barato produz resultados aceitáveis. Nesta implementação de referência de bate-papo, o GPT 3.5-turbo foi escolhido em vez do GPT-4 para economizar aproximadamente uma ordem de grandeza dos custos de implantação de modelo, ao mesmo tempo em que atinge resultados suficientes.

• Entenda os pontos de interrupção do faturamento. O ajuste é cobrado por hora. Para ser mais eficiente, convém usar o máximo desse tempo disponível por hora para melhorar os resultados de ajuste, evitando quedas no próximo período de faturamento. Da mesma forma, o custo para 100 imagens da geração de imagens é o mesmo que o custo para uma imagem. Maximize os pontos de interrupção do preço em seu favor.

• Entenda o modelo de cobrança. O OpenAI do Azure também está disponível em um modelo de cobrança baseado em compromisso por meio da oferta da taxa de transferência provisionada. Depois que você tiver padrões de uso previsíveis, considere a mudança para esse modelo de cobrança de pré-compra se ele for mais econômico para seu volume de uso.

• Defina limites de provisionamento. Verifique se toda a cota de provisionamento está alocada exclusivamente 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. A cota não é mapeada diretamente para os custos, que podem variar.

• Monitore o pagamento conforme o uso. Se você usar pagamento conforme o uso, monitore o uso do TPM e do RPM. Use essas informações para informar decisões de design arquitetônico, como quais modelos usar e otimizar tamanhos de prompt.

• Monitore o uso da taxa de transferência provisionada. Se você usar a taxa de transferência provisionada, monitore o o uso gerenciado por provisionamento para garantir que você não esteja subutilizando a taxa de transferência provisionada que comprou.

• 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 a fim de notificar as partes interessadas sobre riscos ou anomalias.

Excelência operacional

A excelência operacional abrange os processos de operações que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, consulte Lista de verificação de revisão de design para Excelência Operacional.

Machine Learning: runtimes do prompt flow interno

Assim como na arquitetura básica, essa arquitetura usa o Runtime automático para minimizar a carga operacional. O runtime automático é uma opção de computação sem servidor no Machine Learning que simplifica o gerenciamento de computação e delega a maior parte da configuração do prompt flow ao arquivo requirements.txt e à configuração flow.dag.yaml do aplicativo em execução. Isso torna essa escolha de baixa manutenção, efêmera e controlada por aplicativos. O uso de Runtime de instância de computação ou de computação externalizada, como nessa arquitetura, requer um ciclo de vida da computação gerenciado pela equipe de mais carga de trabalho e deve ser selecionado quando os requisitos de carga de trabalho excedem os recursos de configuração da opção de tempo de execução automático.

Monitoramento

Assim como na arquitetura básica, os diagnósticos são configurados para todos os serviços. Todos os serviços, exceto o Machine Learning e o Serviço de Aplicativo, são configurados para capturar todos os logs. O diagnóstico do Machine Learning é configurado para capturar os logs de auditoria, que são todos os logs de recursos que registram as interações do usuário com os dados ou as configurações do serviço. O Serviço de Aplicativo é configurado para capturar AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs e AppServicePlatformLogs.

Avalie a criação de alertas personalizados para os recursos nessa arquitetura, como os encontrados nos alertas de linha de base do Azure Monitor. Por exemplo:

• Alertas do Registro de Contêiner
• Alertas do Machine Learning e OpenAI do Azure
• Alertas de Aplicativos Web do Azure

Operações de modelo de linguagem

A implantação de soluções de chat baseadas em OpenAI do Azure, como essa arquitetura, deve seguir as diretrizes em GenAIOps com prompt flow com o Azure DevOps e com o GitHub. Além disso, ela deve considerar as práticas recomendadas para integração contínua e entrega contínua (CI/CD) e arquiteturas seguras de rede. As diretrizes a seguir abordam a implementação de fluxos e a infraestrutura associada com base nas recomendações de GenAIOps. Esta diretriz de implantação não inclui os elementos do aplicativo front-end, que permanecem inalterados em relação à arquitetura do aplicativo Web com redundância de zona altamente disponível da linha de base.

Desenvolvimento

O prompt flow do Azure Machine Learning oferece uma experiência de criação baseada em navegador no estúdio do Machine Learning ou por meio de uma extensão do Visual Studio Code. Ambas as opções armazenam o código de fluxo como arquivos. Durante o uso do estúdio do Machine Learning, os arquivos são armazenados em uma conta de armazenamento. Durante o trabalho no Microsoft Visual Studio Code, os arquivos são armazenados no seu sistema de arquivos local.

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

Para desenvolvimento corporativo, use a extensão do Microsoft Visual Studio Code e o SDK/CLI do prompt flow no desenvolvimento. Os autores do prompt flow podem compilar e testar os fluxos a partir do Microsoft Visual Studio Code e integrar os arquivos armazenados localmente ao sistema de controle de origem online e aos pipelines. Embora a experiência baseada em navegador seja bem indicada para o 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 na página de fluxo no Files painel, descompactada e enviada para o sistema de controle do código-fonte.

Avaliação

Teste 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 do modelo de linguagem, mas você pode usar um modelo de linguagem para avaliar as respostas. Leve em consideração a implementação das seguintes avaliações automatizadas dos seus fluxos de modelo de linguagem:

• Precisão da classificação: avalia se o modelo de linguagem atribui uma pontuação "correta" ou "incorreta" e agrega os resultados para produzir uma nota de precisão.

• Coerência: avalia a qualidade das frases escritas na resposta prevista de um modelo e como elas se conectam coerentemente umas às outras.

• Fluência: avalia a resposta prevista do modelo quanto às precisões gramatical e linguística.

• Embasamento em relação ao contexto: avalia a qualidade das respostas previstas do modelo baseadas em contexto pré-configurado. Mesmo que as respostas do modelo de linguagem estejam corretas, se elas não puderem ser validadas em relação ao contexto dado, essas respostas não serão embasadas.

• Relevância: avalia a qualidade das respostas previstas do modelo alinhadas com a pergunta feita.

Leve em consideração as seguintes diretrizes ao implementar avaliações automatizadas:

• Produza pontuações a partir de avaliações e as avalie em relação a um limite de sucesso predefinido. Use essas pontuações para relatar aprovação/reprovação no teste nos pipelines.

• Alguns desses testes exigem entradas de dados pré-configuradas de perguntas, contexto e verdade embasada.

• Inclua pares de perguntas e respostas suficientes para garantir que os resultados dos testes sejam confiáveis, com pelo menos 100-150 pares recomendados. Esses pares de perguntas e respostas são chamados de "conjunto de dados dourado". Uma população maior pode ser necessária, dependendo do tamanho e do domínio do conjunto de dados.

• Evite usar modelos de linguagem para gerar qualquer um dos dados no conjunto de dados dourado.

Fluxo de implantação

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

2. Depois que o desenvolvimento local e a experimentação forem concluídos, o engenheiro/cientista de dados de prompt vai abrir uma solicitação pull da ramificação de recurso para a ramificação principal. A solicitação pull (PR) dispara um pipeline PR. Esse pipeline executa verificações de qualidade rápidas que devem incluir:

   • Execução dos 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 exija que pelo menos um membro da equipe aprove manualmente o PR antes da mesclagem. O aprovador não pode ser o confirmador, e eles devem ter experiência no prompt flow e familiaridade com os requisitos do projeto. Se o PR não for aprovado, a fusão será bloqueada. Se o PR for aprovado ou não houver nenhuma etapa de aprovação, a ramificação do recurso vai ser mesclada na ramificação principal.

4. A mesclagem com principal dispara o processo de compilação e liberação para o ambiente de desenvolvimento. Especificamente:

   1. O pipeline CI é disparado da mesclagem para o principal. O pipeline de CI realiza todas as etapas feitas no pipeline PR e as seguintes etapas:
   • Fluxo de experimentação
   • Fluxo de avaliação
   • Registra os fluxos no Registro do Machine Learning quando as alterações são detectadas
   1. O pipeline CD será disparado depois da conclusão do pipeline CD. Este fluxo realiza as seguintes etapas:
   • Implanta o fluxo do Registro do Machine Learning para um ponto de extremidade online do Machine Learning
   • Executa testes de integração direcionados para o ponto de extremidade online
   • Executa smoke tests direcionados para o ponto de extremidade online

5. Um processo de aprovação é incorporado ao processo de promoção de lançamento – mediante a aprovação, os processos CI e CD descritos em etapas 4.a. e 4.b. são repetidos, visando o ambiente de teste. As etapas a. e b. são iguais, exceto pelos testes de aceitação do usuário serem executados após os smoke tests no ambiente de teste.

6. Os processos CD de CI & descritos nas etapas 4.a. e 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. Depois do lançamento em um ambiente ativo, as tarefas operacionais de monitoramento de métricas de desempenho e avaliação dos modelos de linguagem implantados acontecem. Isso inclui, embora não esteja limitado a:

   • Detecção do descompasso de dados
   • Observação da infraestrutura
   • Gerenciando os custos
   • Comunicação do desempenho do modelo para partes interessadas

Diretrizes de implantação

Você pode usar pontos de extremidade do Machine Learning para implantar modelos de modo a permitir flexibilidade na liberação para produção. Leve em consideração as seguintes estratégias para garantir os melhores desempenho e qualidade do modelo:

• Implantações azuis/verdes: com essa estratégia, você pode implantar com segurança a nova versão do serviço Web em um grupo limitado de usuários ou solicitações antes de direcionar todo o tráfego para a nova implantação.

• Teste A/B: as implantações azuis/verdes são eficazes para implantar alterações com segurança e podem ser usadas para implantar um novo comportamento que permita que um subconjunto de usuários avalie o impacto da alteração.

• Inclua Lint de arquivos Python que façam parte do prompt flow nos pipelines. O Lint verifica a conformidade com padrões de estilo, erros, complexidade de código, importações não utilizadas e nomenclatura de variáveis.

• Ao implantar o fluxo no workspace do Machine Learning isolado pela rede, use um agente auto-hospedado para implantar artefatos nos recursos do Azure.

• O registro do modelo do Machine Learning só deverá ser atualizado quando houver alterações no modelo.

• Os modelos de linguagem, os fluxos e a interface do usuário do cliente devem ser acoplados mais livremente. As atualizações feitas nos fluxos e na 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 o próprio ciclo de vida, o que possibilita uma experiência acoplada mais livremente durante a promoção dos fluxos da experimentação à produção.

Infraestrutura

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

Componentes fundamentais

Alguns componentes nessa arquitetura existem com um ciclo de vida que vai além de qualquer prompt flow individual ou qualquer implantação de modelo. Esses recursos costumam ser implantados uma vez como parte da implantação fundamental pela equipe da carga de trabalho e mantidos além de novos, removidos ou atualizações para os prompt flows ou as implantações de modelo.

• Workspace do Machine Learning
• Conta de armazenamento para o workspace do Machine Learning
• Registro de Contêiner
• AI Search
• OpenAI do Azure
• Azure Application Insights
• Azure Bastion
• Máquina Virtual do Azure para a jump box

Componentes efêmeros

Alguns recursos do Azure estão mais fortemente acoplados ao design de prompt flows específicos. Essa abordagem permite que esses recursos sejam vinculados ao ciclo de vida do componente e se tornem efêmeros nessa arquitetura. Os recursos do Azure 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 são removidas. Alguns desses recursos são recursos do Azure diretos e alguns são manifestações do plano de dados dentro do serviço de contenção.

• O modelo no registro do modelo do Machine Learning deve ser atualizado, se alterado, como parte do pipeline CD.

• A imagem do contêiner deve ser atualizada no registro de contêiner como parte do pipeline CD.

• Um ponto de extremidade do Machine Learning será criado quando um prompt flow for 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 Machine Learning são atualizadas quando um fluxo é implantado ou excluído.

• O cofre de chaves da interface do usuário do cliente deve ser atualizado com a chave do ponto de extremidade quando um novo ponto de extremidade é criado.

Eficiência de desempenho

A eficiência do desempenho é a capacidade de dimensionar a carga de trabalho para atender às demandas exigidas pelos usuários de maneira eficiente. Para obter mais informações, consulte Lista de verificação de revisão de design para eficiência de desempenho.

Esta seção descreve a eficiência de desempenho do ponto de vista da Pesquisa do Azure, do OpenAI do Azure e do Machine Learning.

Azure Search – eficiência de desempenho

Siga as diretrizes para analisar o desempenho no AI Search.

OpenAI do Azure – eficiência de desempenho

• Determine se o aplicativo requer uma taxa de transferência provisionada ou o modelo de consumo ou de hospedagem compartilhada. A taxa de transferência provisionada garante capacidade de processamento reservada para as implantações de modelo OpenAI, que oferecem desempenho e taxa de transferência previsíveis para os modelos. Esse modelo de faturamento é diferente do modelo de hospedagem compartilhada ou de consumo. O modelo de consumo é a melhor tentativa e pode estar sujeito a ruídos ou outros fatores de estresse na plataforma.

• Monitore a utilização gerenciada por provisionamento para uma taxa de transferência provisionada.

Machine Learning: eficiência de desempenho

Se você implantar nos pontos de extremidade online do Machine Learning:

• Siga as orientações sobre como escalar automaticamente um ponto de extremidade online. Faça isso para permanecer alinhado com a demanda sem superprovisionamento, especialmente em períodos de baixa utilização.

• Escolha a SKU de máquina virtual indicada para o ponto de extremidade online para atender às metas de desempenho. Teste o desempenho de uma contagem de instâncias inferior e SKUs maiores em comparação com uma contagem de instâncias maior e SKUs menores para encontrar uma configuração ideal.

Implantar este cenário

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

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

• Rob Bagby | Padrões e práticas – Microsoft
• Freddy Ayala | Arquiteto de soluções em nuvem – Microsoft
• Prabal Deb | Engenheiro de software sênior – Microsoft
• Raouf Aliouat | Engenheiro de software II – Microsoft
• Ritesh Modi | Engenheiro de software líder – Microsoft
• Ryan Pfalz | Arquiteto de soluções sênior – Microsoft

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

Próxima etapa

Recursos relacionados

• OpenAI do Azure
• Modelos de linguagem do OpenAI do Azure
• Prompt flow do Machine Learning
• Isolamento de rede virtual gerenciado por workspace
• Configurar um ponto de extremidade privado para um workspace do Machine Learning
• Filtragem de conteúdo