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

Os aplicativos de bate-papo corporativos podem capacitar os funcionários por meio da interação conversacional. Isto é especialmente verdadeiro devido ao avanço contínuo de modelos de linguagem, como os modelos GPT da OpenAI e os modelos LLaMA da Meta. Esses aplicativos de bate-papo consistem em uma interface do usuário (UI) de bate-papo, repositórios de dados que contêm informações específicas do domínio pertinentes às consultas do usuário, modelos de linguagem 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 do Serviço OpenAI do Azure. A arquitetura emprega o fluxo de prompt do Azure Machine Learning para criar fluxos executáveis. Esses fluxos executáveis orquestram o fluxo de trabalho de prompts de entrada para armazenamentos de dados para buscar dados de aterramento para os modelos de linguagem, juntamente com outras lógicas Python necessárias. O fluxo executável é implantado em um cluster de computação de Aprendizado de Máquina 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 a plataforma Azure como uma solução de serviço (PaaS) 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 para o fluxo em um ponto de extremidade privado. O acesso público ao espaço de trabalho do Aprendizado de Máquina está desabilitado.

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 que são implantados na computação do Machine Learning.

Arquitetura

Transfira um ficheiro do Visio desta arquitetura.

Componentes

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

• O Azure OpenAI é usado na arquitetura básica e nesta linha de base. O Azure OpenAI é um serviço totalmente gerenciado que fornece acesso à API REST aos modelos de linguagem do Azure OpenAI, incluindo o conjunto de modelos GPT-4, GPT-3.5-Turbo e incorporações. A arquitetura de linha de base aproveita os recursos corporativos, como rede virtual e link privado, que a arquitetura básica não implementa.
• O Application Gateway é um balanceador de carga de camada 7 (HTTP/S) e um gerenciador 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 Web Application Firewall (WAF) é um serviço nativo da nuvem que protege aplicativos Web contra explorações comuns, como injeção de SQL e scripts entre sites. O WAF fornece visibilidade sobre o tráfego de e para seu aplicativo Web, permitindo que você monitore e proteja seu aplicativo.
• O Azure Key Vault é um serviço que armazena e gerencia segredos, chaves de criptografia e certificados com segurança. Centraliza a gestão de informação sensível.
• 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.
• O Private Link possibilita que os clientes acessem os serviços PaaS (plataforma como serviço) do Azure diretamente de redes virtuais privadas sem usar endereçamento IP público.
• O DNS do Azure é um serviço de hospedagem para domínios DNS que fornece 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.

Considerações e recomendações

Fiabilidade

A confiabilidade garante que seu aplicativo possa atender aos 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 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. Para obter mais informações, consulte a linha de base para revisar essas diretrizes.

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 Machine Learning, Azure OpenAI e AI Search.

Redundância zonal para implantações de fluxo

As implantações corporativas geralmente exigem redundância zonal. Para obter 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 estiver disponível. Atualmente, a computação do 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 do Machine Learning, é 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ê pode usar 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 se limita aos clusters de computação do Machine Learning. O fluxo executável, sendo um aplicativo em contêiner, 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 e o Serviço de Aplicativo. 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.

O diagrama a seguir mostra uma arquitetura alternativa onde os fluxos de prompt são implantados no Serviço de Aplicativo. 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.

O diagrama é numerado para áreas notáveis nesta arquitetura:

1. Os fluxos ainda são criados no fluxo de prompt do Machine Learning e a arquitetura de rede do 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. Não são mostrados no diagrama os pipelines que conteinerizam os fluxos e enviam por push para o Registro de Contêiner.

3. Há outro aplicativo Web implantado no mesmo plano do Serviço de Aplicativo que já está hospedando a interface do usuário do bate-papo. O novo aplicativo Web hospeda o fluxo de prompt em contêiner, localizado 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 Registro de Contêiner em 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. Nessa arquitetura, o contêiner de fluxo de prompt se conecta à Pesquisa de IA e ao Azure OpenAI. Os serviços de PaaS que foram expostos apenas à sub-rede de ponto de extremidade privada gerenciada pelo Machine Learning 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ê pode usar verificações de integridade para ajudar a garantir que as chamadas sejam roteadas apenas para clusters que estejam funcionando corretamente.

Para oferecer suporte a várias instâncias de forma eficaz, recomendamos que você externalize arquivos de ajuste fino, como para uma conta de armazenamento com redundância geográfica. Essa abordagem minimiza o estado armazenado no Azure OpenAI para cada região. Você ainda deve ajustar os arquivos de cada 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). Certifique-se de que TPM suficiente atribuído a partir 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 Gerenciamento de API do Azure pode ser implantado na frente do seu serviço ou serviços OpenAI e pode ser configurado para nova tentativa se houver erros transitórios e limitação. O Gerenciamento de API também pode ser usado como um disjuntor para evitar que o serviço fique sobrecarregado com chamadas, excedendo sua cota.

AI Search - fiabilidade

Implante a Pesquisa de IA com o nível 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:

• Monitore a pesquisa de IA.

• 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 e partições baseadas em consulta e a limitação baseada em índice.

Machine Learning - fiabilidade

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

• Dimensione automaticamente seus endpoints on-line para garantir que haja capacidade suficiente 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 um 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.

Segurança

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

Essa arquitetura amplia a pegada de segurança implementada no bate-papo básico de ponta a ponta com a arquitetura OpenAI do Azure. A arquitetura implementa um perímetro de segurança de rede, juntamente com o perímetro de identidade implementado na arquitetura básica. 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 via Application 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.

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

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 que usa OpenAI. A partir de um alto nível, a arquitetura de rede garante que:

• Apenas 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 Transport Layer Security (TLS).
• A exfiltração de dados é minimizada usando o Private Link para manter o tráfego no Azure.
• Os recursos de rede são logicamente agrupados e isolados uns dos outros através da segmentação de rede.

Fluxos de rede

Dois fluxos neste diagrama são abordados na arquitetura de aplicativo 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 PaaS do Azure (2). Esta seção se concentra no fluxo de pontos finais online do Machine Learning. O fluxo a seguir vai da interface do usuário do chat que é executada no aplicativo Web do Serviço de Aplicativo de linha de base para o fluxo implantado na computação do Aprendizado de Máquina:

1. A chamada da interface do usuário do chat hospedado pelo Serviço de Aplicativo é roteada por meio de um ponto de extremidade privado para o ponto de extremidade online do Aprendizado de Máquina.
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 Machine Learning

Nessa arquitetura, o acesso público ao espaço de trabalho do Aprendizado de Máquina está 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 espaço de trabalho do Aprendizado de Máquina. Na verdade, os pontos de extremidade privados são usados em toda essa arquitetura para complementar a segurança baseada em identidade. Por exemplo, sua interface do usuário de chat hospedada pelo Serviço de Aplicativo pode se conectar a serviços PaaS que não estão expostos à Internet pública, incluindo pontos de extremidade de Aprendizado de Máquina.

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

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 do 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 pelo Machine Learning para os serviços PaaS do Azure

Recomendamos que você configure o espaço de trabalho do Aprendizado de Máquina para isolamento de rede virtual gerenciado 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 Registro e Armazenamento de Contêiner. As regras de saída definidas pelo usuário são para recursos personalizados, como o Azure OpenAI ou o AI Search, que seu fluxo de trabalho 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. Nessa arquitetura, a conectividade com serviços do Azure, como Registro de Contêiner, Armazenamento, Cofre da Chave do Azure, Azure OpenAI e AI Search 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 ou 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 os seguintes fins:

• 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 NSG (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 da regra e a função.

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 endereço IP público.

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

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

Rotação de chaves

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

• Armazene a chave em um repositório seguro, como o Cofre da Chave, 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, crie uma política de expiração de chave e use a Política do Azure para monitorar se a chave foi girada.

Ajuste fino do modelo OpenAI

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

• Se você carregar dados de treinamento para ajuste fino, considere usar chaves gerenciadas pelo cliente para criptografar esses dados.

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

Governação através de políticas

Para ajudar a garantir o alinhamento com a segurança, considere usar a Política do Azure 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:

• Desative o acesso de chave ou outra autenticação local em serviços como os serviços de IA do Azure e o Cofre de Chaves.
• Exigem configuração específica de regras de acesso à rede ou NSGs.
• Exigir criptografia, como o uso de chaves gerenciadas pelo cliente.

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

A identidade gerenciada do espaço de trabalho do Azure Machine Learning requer atribuições de função de plano de controle (Colaborador) e plano de dados (Administrador do Cofre de Chaves). 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. Se sua carga de trabalho tiver serviços diferentes do Azure Machine Learning que exijam acesso a segredos, chaves ou certificados no Cofre de Chaves, sua carga de trabalho ou equipe de segurança pode não se sentir confortável com a identidade gerenciada do espaço de trabalho do Azure Machine Learning tendo acesso a esses artefatos. Nesse caso, considere implantar uma instância do Cofre da Chave especificamente para o espaço de trabalho do Azure Machine Learning e outras instâncias do Cofre da Chave do Azure, conforme apropriado para outras partes da sua carga de trabalho.

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 Lista de verificação de revisão de design para 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ê precisa 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 interface do usuário do bate-papo e a computação de fluxo de prompt e a pesquisa de IA. Otimize esses recursos para economizar o máximo de custos.

Computação

O fluxo de prompt do Machine Learning suporta 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 Kubernetes 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 Azure OpenAI especificamente, você precisa usar uma combinação de abordagens:

• Controlar clientes. As solicitações do cliente são a principal fonte de custo em um modelo de consumo, portanto, 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 por meio de controles de rede e identidade, como chaves ou controle de acesso baseado em função (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. Use o modelo correto para o caso de uso para 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ê deseja usar 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 imagens é o mesmo que o custo para uma imagem. Maximize os pontos de quebra de preço a seu favor.

• Entenda os modelos de faturamento. O Azure OpenAI também está disponível em um modelo de cobrança baseado em compromisso por meio da oferta de taxa de transferência provisionada. Depois de ter padrões de utilização previsíveis, considere mudar para este modelo de faturação de pré-compra se for mais económico no seu volume de utilização.

• Defina 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 estiver habilitada. A cota não é mapeada diretamente para os custos e esse custo pode variar.

• Monitorize a utilização pré-paga. Se você usa preços pré-pagos, monitore o uso de TPM e RPM. Use essas informações para informar decisões de projeto de arquitetura, 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 uso gerenciado por provisionamento para garantir que você não esteja subutilizando a taxa de transferência provisionada que você comprou.

• Gestão 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.

Excelência operacional

A excelência operacional abrange os processos operacionais 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 - tempos de execução de fluxo de prompt integrados

Como na arquitetura básica, essa arquitetura usa o Tempo de Execução Automático para minimizar a carga operacional. O tempo de execução 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 de fluxo de prompt ao arquivo e flow.dag.yaml à configuração do requirements.txt aplicativo em execução. Isso torna essa escolha de baixa manutenção, efêmera e orientada a aplicativos. O uso do Compute Instance Runtime ou da computação externalizada, como nesta arquitetura, requer um ciclo de vida da computação gerenciado pela equipe de carga de trabalho e deve ser selecionado quando os requisitos de carga de trabalho excederem os recursos de configuração da opção de tempo de execução automático.

Monitorização

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, estão configurados para capturar todos os logs. Os diagnósticos do Machine Learning são configurados 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 está 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 de Machine Learning e Azure OpenAI
• Alertas de Aplicativos Web do Azure

Operações de modelo de linguagem

A implantação de soluções de chat baseadas no Azure OpenAI, como essa arquitetura, deve seguir as orientações do GenAIOps com fluxo de prompt com o Azure DevOps e com o GitHub. Além disso, deve considerar as práticas recomendadas para integração contínua e entrega contínua (CI/CD) e arquiteturas protegidas pela rede. As orientações a seguir abordam a implementação de fluxos e sua infraestrutura associada com base nas recomendações do GenAIOps. 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 Machine Learning oferece uma experiência de criação baseada em navegador no estúdio de Aprendizado de Máquina ou por meio de uma extensão de código do Visual Studio. Ambas as opções armazenam o código de fluxo como arquivos. Quando você usa o estúdio de Aprendizado de Máquina, os arquivos são armazenados em uma conta de armazenamento. Quando você trabalha no Microsoft Visual Studio 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, use a extensão Microsoft Visual Studio Code e o fluxo de prompt SDK/CLI para desenvolvimento. Os autores de fluxo de prompt podem criar e testar seus fluxos do Microsoft Visual Studio Code e integrar os arquivos armazenados localmente com o sistema de controle de origem online 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

Teste os fluxos usados em um aplicativo de bate-papo assim como você testa outros artefatos de software. É desafiador especificar e afirmar uma única resposta "certa" para saídas de modelo de linguagem, mas você pode usar um modelo de linguagem próprio para avaliar as respostas. Considere a implementação das seguintes avaliações automatizadas dos fluxos do seu modelo linguístico:

• Precisão da classificação: Avalia se o modelo de linguagem 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 modelo de linguagem estejam corretas, se não puderem ser validadas em relação ao contexto dado, essas 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 modelos de linguagem para gerar qualquer um dos dados em seu conjunto de dados dourado.

Fluxo de implantação

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 o Microsoft Visual Studio 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:

   1. 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 de Aprendizado de Máquina quando alterações são detetadas
   1. 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 Machine Learning para um ponto de extremidade online do 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 dos modelos de linguagem implantados 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

Orientação de implementação

Você pode usar pontos de extremidade de Aprendizado de Máquina para implantar 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 azuis/verdes 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 de Aprendizado de Máquina isolado da rede, use um agente auto-hospedado para implantar artefatos em seus recursos do Azure.

• O registro do modelo de Aprendizado de Máquina só deve 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 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.

• Quando você desenvolve e implanta 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

Quando você implanta 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.

• Espaço de trabalho de Aprendizado de Máquina
• Conta de armazenamento para o espaço de trabalho do Aprendizado de Máquina
• Container Registry
• Pesquisa AI
• 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. 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 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 de Aprendizado de Máquina 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 de Aprendizado de Máquina é 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 Machine Learning são atualizadas quando um fluxo é implantado ou excluído.

• O cofre de chaves 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.

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 Lista de verificação de revisão de projeto para eficiência de desempenho.

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

Azure Search - eficiência de desempenho

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

Azure OpenAI - eficiência de desempenho

• Determine se seu aplicativo requer taxa de transferência provisionada ou o modelo de hospedagem compartilhada ou consumo. A taxa de transferência provisionada garante capacidade de processamento reservada para suas implantações de modelo OpenAI, o que fornece desempenho e taxa de transferência previsíveis para seus modelos. Esse modelo de faturamento é diferente do modelo de hospedagem compartilhada, ou de consumo. O modelo de consumo é o melhor esforço e pode estar sujeito a vizinhos barulhentos ou outros fatores de estresse na plataforma.

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

Machine Learning - eficiência de desempenho

Se você implantar em pontos de extremidade online do Aprendizado de Máquina:

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

• Escolha a SKU de máquina virtual apropriada para o ponto de extremidade online para atender às suas metas de desempenho. Teste 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.

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óximo passo

Recursos relacionados

• Azure OpenAI
• Modelos de linguagem do Azure OpenAI
• Fluxo de prompt do Machine Learning
• Isolamento de rede virtual gerenciado pelo espaço de trabalho
• Configurar um ponto de extremidade privado para um espaço de trabalho de Aprendizado de Máquina
• Filtragem de conteúdos