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

Os aplicativos de bate-papo corporativo têm a possibilidade de capacitar funcionários por meio da interação conversacional. Isso é especialmente verdadeiro por causa do avanço contínuo de modelos de linguagem grandes, como os modelos GPT da OpenAI e os modelos LLaMA da Meta. Esses aplicativos de bate-papo consistem em uma interface do usuário para bate-papo, repositórios de dados contendo informações específicas do domínio pertinentes às consultas do usuário, modelos de linguagem grandes (LLMs) 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 bate-papo corporativo que usam modelos de linguagem grande do Azure OpenAI. A arquitetura emprega o prompt flow do Azure Machine Learning (AML) para criar fluxos executáveis que orquestram o workflow a partir dos prompts de entrada para armazenamentos de dados para buscar dados de embasamento para os LLMs, com qualquer outra lógica Python necessária. O fluxo executável é implantado em um cluster de cálculo do Azure 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 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 do bate-papo se comunica com o ponto de extremidade online gerenciado para o fluxo em um ponto de extremidade privado e o acesso público ao Workspace do Azure 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 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.

Arquitetura

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

Baixe um Arquivo Visio dessa arquitetura.

Componentes

Muitos dos componentes dessa arquitetura são iguais aos recursos no aplicativo Web de serviços de aplicativos da linha de base, pois a hospedagem da interface do usuário de bate-papo nessa arquitetura segue a arquitetura do aplicativo Web do Serviço de Aplicativo da linha de base. Os componentes realçados nesta seção se concentram nos componentes usados para compilar 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 machine learning. Essa arquitetura usa diversos outros recursos do Azure Machine Learning usados para desenvolver e implantar fluxos executáveis para aplicativos de IA da plataforma dos modelos de linguagem grandes:
  • O prompt flow do Azure Machine Learning é uma ferramenta de desenvolvimento que permite compilar, avaliar e implantar fluxos que vinculam prompts de usuário, ações por meio do código Python e chamadas para LLMs. O prompt flow é usado nessa arquitetura como a camada que orquestra os fluxos entre o prompt, armazenamentos de dados diferentes e o LLM.
  • Os pontos de extremidade 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 de bate-papo para invocar os prompt flows hospedados pelo Azure Machine Learning.
• O Armazenamento do Azure é usado para manter os arquivos de origem do prompt flow para o desenvolvimento do prompt flow.
• O Registro de Contêiner do Azure permite criar, armazenar e gerenciar 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 dá acesso à API REST a modelos de linguagem grandes do Azure OpenAI, inclusive o conjunto de modelos GPT-4, GPT-3.5-Turbo e Incorporações. Nessa arquitetura, além do acesso ao modelo, ele é usado para adicionar recursos corporativos comuns, como rede virtual e link privado, suporte à identidade gerenciada e filtragem de conteúdo.
• A Pesquisa de IA do Azure é um serviço de pesquisa na nuvem que dá suporte à pesquisa de texto completo, à pesquisa semântica, à busca em vetores e à pesquisa híbrida. A Pesquisa de IA do Azure está incluída na arquitetura, pois é um serviço comum usado nos fluxos por trás dos aplicativos de bate-papo. A Pesquisa de IA do Azure pode ser usada para recuperar e indexar dados relevantes para consultas de usuário. O prompt flow implementa o padrão RAG Geração aumentada por recuperação para extrair a consulta indicada do prompt, consultar a Pesquisa de IA e usar os resultados como dados de embasamento para o modelo do Azure OpenAI.

Prompt flow do Azure Machine Learning

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

• O usuário insere um prompt em uma interface do 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
• (opcional) 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 embasamento relevantes e um eventual 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 em vários serviços do Azure. Nessa arquitetura, o prompt flow do Azure Machine Learning foi escolhido porque oferece uma experiência simplificada para compilar, testar e implantar fluxos orquestrados entre prompts, armazenamentos de dados de back end e LLMs.

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 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 de bate-papo
• 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 link privado
• Os recursos de rede são agrupados e isolados de maneira lógica uns dos outros por meio da segmentação de rede

Fluxos de rede

Figura 2: Fluxos de rede para a arquitetura de bate-papo de ponta a ponta da linha de base com OpenAI

Dois fluxos neste diagrama são abordados no aplicativo Web dos serviços de aplicativos da linha de base: 1. o fluxo de entrada do usuário final para a interface do usuário de bate-papo e 2. o fluxo de serviços do Serviço de Aplicativo para os serviços PaaS do Azure. Consulte esse artigo para obter detalhes sobre esses fluxos. Esta seção se concentra no fluxo do ponto de extremidade online do Azure Machine Learning. Isto detalha o fluxo da interface do usuário de bate-papo em execução 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 Azure 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 Azure Machine Learning

Nessa arquitetura, o acesso público ao Azure Workspace do Machine Learning é desabilitado, e o acesso pode ocorrer por meio do acesso privado, pois segue o ponto de extremidade privado para a configuração do Workspace 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 a interface do usuário de bate-papo hospedada no Serviço de Aplicativo se conecte 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.

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

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 dessa jump box, 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 Azure Machine Learning para serviços PaaS do Azure

Recomenda-se que o Workspace 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 os 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 a Pesquisa de IA do Azure, que o workflow vai usar. É sua responsabilidade configurar regras de saída definidas pelo usuário, e 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 para pontos de extremidade públicos externos. Nesta arquitetura, a conectividade com os serviços do Azure, como o Registro de Contêiner do Azure, o Armazenamento do Azure, o Cofre de Chaves do Azure, o Serviço OpenAI do Azure e a Pesquisa de IA do Azure, são conectadas 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 o seguinte:

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

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 IP público.
• Adicione um NSG a cada sub-rede sempre que possível. Você deve usar as regras mais rígidas que habilitam a funcionalidade da solução completa.
• Use grupos de segurança do aplicativo. Os grupos de segurança do aplicativo permitem agrupar NSGs, facilitando a criação de regras para ambientes complexos.

Filtragem de conteúdo e monitoramento de abuso

O Serviço OpenAI do Azure inclui um sistema de filtragem de conteúdo que usa um conjunto de modelos de classificação para detectar e impedir categorias específicas de conteúdo potencialmente prejudicial em prompts de entrada e conclusões de saída. Entre as categorias desse conteúdo potencialmente prejudicial estão ódio, sexual, automutilação, violência, palavrões e jailbreak (conteúdo projetado para ignorar as restrições de um LLM). Você pode configurar o rigor do que deseja filtrar o conteúdo para cada categoria, com opções sendo baixa, média ou alta. Essa arquitetura de referência adota uma abordagem rigorosa. Você deve ajustar as configurações de acordo com as necessidades.

Além da filtragem de conteúdo, o Serviço OpenAI do Azure implementa recursos do monitoramento de abuso. O monitoramento de abuso é uma operação assíncrona projetada para detectar e mitigar instâncias de conteúdo recorrente e/ou comportamentos que sugerem o uso do serviço de uma maneira que possa 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 os dados forem altamente confidenciais ou se houver políticas internas ou regulamentos legais aplicáveis que impeçam o processamento de dados para detecção de abuso.

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 ainda 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. Consulte a linha de base para examinar 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 Azure Machine Learning, o Azure OpenAI e a Pesquisa de IA do Azure.

Redundância zonal para implantações de fluxo

As implantações corporativas normalmente 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 está disponível. Atualmente, a computação do Azure Machine Learning não dá suporte para zonas de disponibilidade. Para mitigar o impacto potencial de uma catástrofe sobre o nível do datacenter em componentes da AML, é necessário estabelecer clusters em regiões variadas com a implantação de um load balancer para distribuir chamadas dentre esses clusters. Você usaria verificações de integridade para ajudar a garantir que as chamadas só fossem encaminhadas para clusters que estejam funcionando corretamente.

A implantação de prompt flows não se limita aos clusters de cálculo do Azure 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 (ACA) 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.

Esta é uma arquitetura alternativa na qual os prompt flows 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 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.

Figura 4: Arquitetura de bate-papo de ponta a ponta alternativa com OpenAI implantando prompt flows nos Serviços de Aplicativo do Azure

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

1. Os fluxos continuam sendo criados no prompt flow do Azure Machine Learning, e a arquitetura de rede do Azure 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 do Azure (ACR). Não mostrados no diagrama são os pipelines que conteinerizam os fluxos e os enviam por push para o ACR.
3. Existe outro Aplicativo Web implantado no mesmo Plano do Serviço de Aplicativo que já está hospedando a interface do usuário de bate-papo. O novo Aplicativo Web hospeda o prompt flow conteinerizado, colocalizado 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 ACR 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, isso aconteceria para a Pesquisa de IA do Azure e o Serviço OpenAI do Azure. Os serviços PaaS que só foram expostos à sub-rede do ponto de extremidade privado gerenciado por AML agora também precisam ser expostos na rede virtual, de maneira que a linha de visão possa ser estabelecida pelo Serviço de Aplicativo.

Azure OpenAI – confiabilidade

No momento, o Azure OpenAI 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 Azure OpenAI, é necessário implantar o Azure OpenAI em regiões variadas, com a implantação de um load balancer para distribuir chamadas entre as regiões. Você usaria verificações de integridade para ajudar a garantir que as chamadas só fossem encaminhadas para clusters que estejam funcionando corretamente.

Para dar suporte a várias instâncias de maneira eficaz, é recomendável externalizar arquivos de ajuste fino, como para uma conta de Armazenamento do Azure com redundância geográfica. Isso vai minimizar o estado armazenado no Serviço OpenAI do Azure por região. O ajuste fino ainda vai precisar ser feito por 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) para garantir que você tenha atribuído TPM suficiente da cota para atender à demanda das implantações e impedir que as chamadas para os modelos implantados sejam limitadas. Um gateway como o Gerenciamento de API do Azure (APIM) pode ser implantado na frente do(s) serviço(s) OpenAI e pode ser configurado para repetição 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 a cota.

Pesquisa de IA do Azure – confiabilidade

Implante a Pesquisa de IA do Azure 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:

• Siga as diretrizes 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 indicado de réplicas para evitar a limitação baseada em consulta e partições a fim de evitar a limitação baseada em índice.

Azure Machine Learning – confiabilidade

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

• Siga as diretrizes para escala automática dos pontos de extremidade online a fim de 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 sobre a 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

Essa arquitetura implementa uma rede e um perímetro de segurança da identidade. De um ponto de vista da rede, a única coisa que deve ser acessível pela Internet é a interface do usuário de bate-papo 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.

A segurança de rede foi abordada na seção de rede. Esta seção aborda o gerenciamento de identidade e acesso, além de considerações sobre segurança para rodízio de chaves e ajuste fino do modelo do Azure OpenAI.

Gerenciamento de identidade e de acesso

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

• Crie identidades gerenciadas à parte para os seguintes recursos de AML, quando aplicável:
  • Workspace – usado durante a criação e o gerenciamento de fluxo
  • Instância da computação – usada durante o teste de fluxos
  • Ponto de extremidade online – usado pelo fluxo implantado se implantado em um ponto de extremidade online gerenciado
• Implementar controles identity-access para a interface do usuário de bate-papo usando o Microsoft Entra ID

Funções RBAC do Azure 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 AzureML Workspace e um Usuário do Registro do AzureML que concedem acesso aos recursos do workspace, como os segredos do workspace e o Registro.

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

Alteração de chaves

Existem dois serviços nessa arquitetura que usam autenticação baseada em chave: o Azure OpenAI e o ponto de extremidade online gerenciado pelo Azure 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 Cofre de Chaves do Azure 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 fino do modelo OpenAI

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

• Se você estiver carregando dados de treinamento para ajuste fino, leve em consideração o uso de chaves gerenciadas pelo cliente na criptografia desses dados.
• Se você estiver armazenando 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.

Eficiência de desempenho

A eficiência do desempenho é a capacidade de dimensionar sua carga de trabalho para atender às demandas colocadas por usuários de maneira eficiente. Para saber mais, confira Visão geral do pilar de eficiência de desempenho.

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

Azure Search – eficiência de desempenho

Siga as diretrizes para analisar o desempenho na Pesquisa de IA do Azure.

Azure OpenAI – eficiência de desempenho

• Determine se o aplicativo exige uma taxa de transferência provisionada ou vai usar o modelo de hospedagem compartilhada (consumo). A taxa de transferência provisionada oferece capacidade de processamento reservada para as implantações de modelo OpenAI, oferecendo desempenho e taxa de transferência previsíveis para os modelos. Esse modelo de cobrança é diferente do modelo de hospedagem compartilhada (consumo), que é a melhor iniciativa e pode estar sujeito a vizinhos barulhentos ou outros elementos de estresse na plataforma.
• Para taxa de transferência provisionada, você deve monitorar a utilização gerenciada pelo provisionamento

Azure Machine Learning – eficiência de desempenho

Em caso de implantação em pontos de extremidade online do Azure Machine Learning:

• Siga as diretrizes para escala automática de um ponto de extremidade online a fim de manter o alinhamento com a demanda, sem superprovisionamento, especialmente em períodos de pouco uso.
• Escolha a SKU de máquina virtual indicada para o ponto de extremidade online para atender às metas de desempenho. Convém testar 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.

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, confira Visão geral do pilar de otimização de custo.

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 incluídos na arquitetura. Como os componentes mais caros no cenário são a computação do prompt flow e da interface do usuário de bate-papo, além da Pesquisa de IA do Azure, procure otimizar esses recursos para economizar ao máximo.

Computação

O prompt flow do Aprendizado de Máquina do Azure dá suporte a várias opções para hospedar os fluxos executáveis. Entre as opções estão pontos de extremidade online gerenciados no Aprendizado de Máquina do Azure, no Serviço de Kubernetes do Azure, no Serviço de Aplicativo do Azure e no Serviço de Contêiner 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 Azure OpenAI é 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 Serviço OpenAI do Azure especificamente, você precisa empregar uma combinação de abordagens:

• Controlar clientes. As solicitações de cliente são a principal fonte de custo em um modelo de consumo, pois 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. Limitar o acesso por meio de controles de rede e de identidade (chave ou RBAC).
  • 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 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 modelo também desempenha um papel importante no custo geral do Azure OpenAI. Todos os modelos têm pontos fortes e fracos e preços individuais. O uso do modelo correto para o caso de uso pode 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.
• Compreenda os pontos de interrupção da cobrança – O ajuste fino é cobrado por hora. Para ser mais eficiente, convém utilizar o máximo desse tempo disponível por hora para melhorar os resultados de ajuste fino, ao mesmo tempo em que evita apenas cair 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.
• Compreender os modelos de cobrança – O Azure OpenAI 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, avalie a mudança para esse modelo de cobrança de pré-compra caso o cálculo dele seja mais econômico no volume de uso.
• Definir 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 e o custo pode variar.
• Monitore o uso do pagamento conforme o uso – Se você 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 design arquitetônico, como quais modelos usar, bem como otimizar tamanhos de prompt.
• Monitorar o uso da taxa de transferência provisionada – Se você estiver usando a taxa de transferência provisionada, monitore a utilização gerenciada pelo provisionamento para garantir que não esteja subutilizando a taxa de transferência provisionada que comprou.
• Gerenciamento de custos – Siga as diretrizes 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.

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

A implantação de soluções de bate-papo baseadas em OpenAI do Azure, como essa arquitetura, deve seguir as diretrizes em LLMOps com prompt flow com o Azure DevOps e o GitHub. Além disso, ela deve levar em consideração as melhores práticas para CI/CD e arquiteturas protegidas por rede. As diretrizes a seguir abordam a implementação de fluxos e a infraestrutura associada com base nas recomendações de LLMOps. 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 Azure Machine Learning ou por meio de uma extensão do VS Code. Ambas as opções armazenam o código de fluxo como arquivos. Durante o uso do estúdio do Azure Machine Learning, os arquivos são armazenados em uma Conta de Armazenamento do Azure. Durante o trabalho no VS Code, os arquivos são armazenados no 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, você deve usar a extensão do VS Code e o SDK/CLI do prompt flow no desenvolvimento. Os autores do prompt flow podem compilar e testar os fluxos a partir do VS 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

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 de LLM, mas você pode usar um LLM por conta própria para avaliar as respostas. Leve em consideração a implementação das seguintes avaliações automatizadas dos fluxos de LLM:

• Precisão da classificação: avalia se o LLM 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 LLM 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 LLMs para gerar qualquer um dos dados no conjunto de dados dourado.

Fluxo de implantação

Figura 5: Implantação do prompt flow

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 VS 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:

   a. 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 Azure Machine Learning quando as alterações são detectadas

   b. O pipeline CD será disparado depois da conclusão do pipeline CD. Este fluxo realiza as seguintes etapas:

   • Implanta o fluxo do Registro do Azure Machine Learning para um ponto de extremidade online do Azure 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 do LLM implantado 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

Os pontos de extremidade do Azure Machine Learning permitem a você implantar modelos de maneira a permitir flexibilidade ao liberar 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 não apenas são eficazes para implantar alterações com segurança, mas também 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 Azure Machine Learning isolado pela rede, use um agente auto-hospedado para implantar artefatos nos recursos do Azure.
• O registro do modelo do Azure Machine Learning só deverá ser atualizado quando houver alterações no modelo.
• O LLM, 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 Azure OpenAI 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 Azure Machine Learning
• Conta de Armazenamento do Azure para o Workspace do Azure Machine Learning
• Registro de Contêiner do Azure
• IA do Azure 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 são mais acoplados ao design de prompt flows específicos, permitindo que esses recursos estejam 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 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 Azure 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 Azure 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 Azure 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.

Monitoramento

O diagnóstico é configurado 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 Aprendizado de Máquina do Azure é configurado para capturar os logs de auditoria, que são todos os logs de recursos que registram as interações do cliente com os dados ou as configurações do serviço. O Serviço de Aplicativo do Azure é configurado para capturar AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs e AppServicePlatformLogs.

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óximas etapas

Leia mais sobre o Azure OpenAI

Recursos relacionados

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