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 fluxo de prompt 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 ponto de extremidade online gerenciado com computação gerenciada.

A hospedagem da interface do usuário (interface do usuário) de chat personalizada segue as diretrizes de 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 no Serviço 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 Azure AI Studio está desabilitado.

O hub do Azure AI Studio é 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.

Um hub é o recurso de nível superior do Azure AI Studio que fornece uma maneira central de controlar a segurança, a conectividade e outras preocupações em vários projetos. Essa arquitetura requer apenas um projeto para sua carga de trabalho. Se você tiver experiências adicionais que exijam fluxos de prompt diferentes com lógica diferente, potencialmente usando recursos de back-end diferentes, como armazenamentos de dados, considere implementá-los em um projeto diferente.

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 os recursos corporativos, como rede virtual e link privado, que a arquitetura básica não implementa.
• O Estúdio de IA do Azure é uma plataforma que você pode usar para criar, testar e implantar soluções de IA. O Estúdio de IA é usado nessa arquitetura para criar, testar e implantar a lógica de orquestração do prompt flow para o aplicativo de chat. Nessa arquitetura, o Azure AI Studio fornece a rede virtual gerenciada para segurança de rede. Para obter mais informações, consulte a seção de rede para obter mais detalhes.
• 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.

Alternativas

Essa arquitetura tem vários componentes que podem ser atendidos por outros serviços do Azure que podem se alinhar melhor aos requisitos funcionais e não funcionais de sua carga de trabalho. Aqui estão algumas dessas alternativas a serem observadas.

Workspaces do Azure Machine Learning (e experiências de portal)

Essa arquitetura usa o Azure AI Studio para criar, testar e implantar fluxos de prompt. Como alternativa, você pode usar workspaces do Azure Machine Learning, pois ambos os serviços têm recursos sobrepostos. Embora o AI Studio seja uma boa opção se você estiver criando uma solução de fluxo de prompt, há alguns recursos para os quais o Azure Machine Learning atualmente tem melhor suporte. Para obter mais informações, consulte a comparação de recursos. Recomendamos que você não misture e combine o Azure AI Studio e o Azure Machine Learning. Se o seu trabalho puder ser feito completamente no AI Studio, use o AI Studio. Se você ainda precisar de recursos do Azure Machine Learning Studio, continue a usar o Azure Machine Learning Studio.

Componentes da camada de aplicativo

Há várias ofertas de serviços de aplicativos gerenciados disponíveis no Azure que podem servir como uma camada de aplicativo para o front-end da interface do usuário de chat. Consulte Escolher um serviço de computação do Azure para toda a computação e Escolher um serviço de contêiner do Azure para soluções de contêiner. Por exemplo, embora os Aplicativos Web do Azure e o Aplicativo Web para Contêineres tenham sido selecionados para a API da interface do usuário de chat e o host de fluxo de prompt, respectivamente, resultados semelhantes podem ser obtidos com o AKS (Serviço de Kubernetes do Azure) ou os Aplicativos de Contêiner do Azure. Escolha a plataforma de aplicativos da sua carga de trabalho com base nos requisitos funcionais e não funcionais específicos da carga de trabalho.

Hospedagem de fluxo de prompt

A implantação de fluxos de prompt não se limita a clusters de computação do Machine Learning e essa arquitetura ilustra isso com uma alternativa no Serviço de Aplicativo do Azure. Em última análise, os fluxos são um aplicativo em contêiner que pode ser implantado em qualquer serviço do Azure compatível com contêineres. Essas opções incluem serviços como AKS (Serviço de Kubernetes do Azure), Aplicativos de Contêiner do Azure e Serviço de Aplicativo do Azure. Escolha um serviço de contêiner do Azure com base nos requisitos da camada de orquestração.

Um exemplo de por que hospedar a hospedagem de fluxo de prompt em uma computação alternativa é uma consideração é discutido posteriormente neste artigo.

Armazenamento de dados de aterramento

Embora essa arquitetura seja iniciada com o Azure AI Search, sua escolha de armazenamento de dados para seus dados de aterramento é uma decisão de arquitetura específica para sua carga de trabalho. Muitas cargas de trabalho são, de fato, poliglotas e têm fontes e tecnologias diferentes para fundamentar dados. Essas plataformas de dados variam de armazenamentos de dados OLTP existentes, bancos de dados nativos de nuvem, como o Azure Cosmos DB, por meio de soluções especializadas, como o Azure AI Search. Uma característica comum, mas não obrigatória, para esse armazenamento de dados é a pesquisa vetorial. Consulte Escolher um serviço do Azure para pesquisa de vetor para explorar as opções neste espaço.

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.

Há algumas alternativas para clusters de computação do Machine Learning, como AKS (Serviço de Kubernetes do Azure), Azure Functions, Aplicativos de Contêiner do Azure e 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 ainda são criados no fluxo de prompt e a arquitetura de rede permanece inalterada. Os autores de fluxo ainda se conectam à experiência de criação no projeto do AI Studio 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 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. A computação na qual esses pipelines são executados deve ter uma linha de visão de rede para recursos como o registro de contêiner do Azure e o projeto do AI Studio.

3. Há 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 fluxo de prompt em contêineres, colocado no mesmo plano de serviço de aplicativo que já é executado em um mínimo de três instâncias, distribuídas entre 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 do serviço ou serviços do Azure OpenAI e pode ser configurado para nova tentativa 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. Para saber mais sobre como adicionar um gateway para questões de confiabilidade, consulte Acessar o Azure OpenAI e outros modelos de linguagem por meio de um gateway.

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.

Azure AI Studio – confiabilidade

Se você implantar em clusters de computação por trás do ponto de extremidade online gerenciado do Machine Learning, considere 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.

Os pontos de extremidade online gerenciados atuam como um balanceador de carga e roteador para a computação gerenciada em execução por trás deles. Você pode configurar a porcentagem de tráfego que deve ser roteada para cada implantação, desde que as porcentagens somem 100%. Você também pode implantar um ponto de extremidade online gerenciado com 0% de tráfego sendo roteado para qualquer implantação. Se, como na implementação de referência fornecida, você estiver usando a IaC (infraestrutura como código) para implantar seus recursos, incluindo seus pontos de extremidade online gerenciados, haverá uma preocupação de confiabilidade. Se você tiver o tráfego configurado para rotear para implantações (criadas por meio da CLI ou do Azure AI Studio) e executar uma implantação de IaC subsequente que inclua o ponto de extremidade online gerenciado, mesmo que ele não atualize o ponto de extremidade online gerenciado de forma alguma, o tráfego do ponto de extremidade será revertido para o roteamento de 0% de tráfego. Efetivamente, isso significa que seus fluxos de prompt implantados não estarão mais acessíveis até que você ajuste o tráfego de volta para onde deseja.

Design de várias regiões

Essa arquitetura não foi criada para ser um selo regional em uma arquitetura multirregional. Ele fornece alta disponibilidade em uma única região devido ao uso completo de zonas de disponibilidade, mas carece de alguns componentes-chave para torná-lo realmente pronto para uma solução multirregional. Estes são alguns componentes ou considerações que estão faltando nesta arquitetura:

• Entrada e roteamento globais
• Estratégia de gerenciamento de DNS
• Estratégia de replicação (ou isolamento) de dados
• Uma designação ativo-ativo, ativo-passivo ou ativo-frio
• Uma estratégia de failover e failback para alcançar o RTO e o RPO da carga de trabalho
• Decisões sobre a disponibilidade de região para experiências de desenvolvedor no recurso Hub do Azure Studio

Se os requisitos da carga de trabalho exigirem uma estratégia multirregional, você precisará investir em esforços adicionais de design em torno de componentes e processos operacionais além do que é apresentado nessa arquitetura. Você projeta para dar suporte ao balanceamento de carga ou failover nas seguintes camadas:

• Dados de fundamentação
• Hospedagem de modelo
• Camada de orquestração (fluxo de prompt nesta arquitetura)
• Interface do usuário voltada para o cliente

Além disso, você precisará manter a continuidade dos negócios em observabilidade, experiências de portal e preocupações de IA responsável, como segurança de conteúdo.

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 separadas para os seguintes recursos do Azure AI Studio e do Machine Learning, quando aplicável:
  • Hub do Estúdio de IA
  • Projetos do AI Studio para criação e gerenciamento de fluxo
  • 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

Crie projetos separados e pontos de extremidade online para diferentes fluxos de prompt que você deseja isolar de outros de uma perspectiva de permissões. Crie uma identidade gerenciada separada para cada projeto e ponto de extremidade online gerenciado. Conceda aos autores de fluxo imediato acesso apenas aos projetos necessários.

Ao integrar usuários a projetos do Azure AI Studio para executar funções como fluxos de criação, você precisa fazer com que as atribuições de função com privilégios mínimos sejam os recursos necessários.

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

Como na arquitetura básica, o sistema cria automaticamente atribuições de função para as identidades gerenciadas atribuídas pelo sistema. Como o sistema não sabe quais recursos do hub e dos projetos você pode usar, ele cria atribuições de função que dão suporte a todos os recursos potenciais. As atribuições de função criadas automaticamente podem provisionar privilégios com base em seu caso de uso. Um exemplo é a função 'Colaborador' atribuída ao hub para o registro de contêiner, em que provavelmente requer apenas acesso de 'Leitor' ao painel de controle. Se você precisar limitar ainda mais as permissões para metas de privilégios mínimos, deverá usar identidades atribuídas pelo usuário. Você criará e manterá essas atribuições de função por conta própria.

Devido à carga de manutenção de gerenciar todas as atribuições necessárias, essa arquitetura favorece a excelência operacional em vez de atribuições de função de privilégio mínimo absoluto. Observe que você deve fazer todas as atribuições listadas na tabela.

Identidade gerenciada	Escopo	Atribuições de função
Identidade gerenciada do hub	Colaborador	Grupo de recursos
Identidade gerenciada do hub	Hub	Administrador de IA do Azure
Identidade gerenciada do hub	Registro de Contêiner	Colaborador
Identidade gerenciada do hub	Key Vault	Colaborador
Identidade gerenciada do hub	Key Vault	Administrador
Identidade gerenciada do hub	Conta de Armazenamento	Leitor
Identidade gerenciada do hub	Conta de Armazenamento	Colaborador da Conta de Armazenamento
Identidade gerenciada do hub	Conta de Armazenamento	Colaborador de Dados do Storage Blob
Identidade gerenciada do hub	Conta de Armazenamento	Colaborador Privilegiado de Dados de Arquivo de Armazenamento
Identidade gerenciada do hub	Conta de Armazenamento	Colaborador de dados da tabela de armazenamento
Identidade gerenciada do projeto	Project	Administrador de IA do Azure
Identidade gerenciada do projeto	Registro de Contêiner	Colaborador
Identidade gerenciada do projeto	Key Vault	Colaborador
Identidade gerenciada do projeto	Key Vault	Administrador
Identidade gerenciada do projeto	Conta de Armazenamento	Leitor
Identidade gerenciada do projeto	Conta de Armazenamento	Colaborador da Conta de Armazenamento
Identidade gerenciada do projeto	Conta de Armazenamento	Colaborador de Dados do Storage Blob
Identidade gerenciada do projeto	Conta de Armazenamento	Colaborador Privilegiado de Dados de Arquivo de Armazenamento
Identidade gerenciada do projeto	Conta de Armazenamento	Colaborador de dados da tabela de armazenamento
Identidade gerenciada por ponto de extremidade online	Project	Segredos de conexão do workspace do Azure Machine Learning
Identidade gerenciada por ponto de extremidade online	Project	Gravador de Métricas do AzureML
Identidade gerenciada por ponto de extremidade online	Registro de Contêiner	ACRPull
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	Conta de Armazenamento	Colaborador de Dados do Storage Blob
Identidade gerenciada por ponto de extremidade online	Conta de Armazenamento	Leitor de Dados do Blob de Armazenamento
Serviço de Aplicativo (quando o fluxo de prompt é implantado no Serviço de Aplicativo)	OpenAI do Azure	Usuário do OpenAI de Serviços Cognitivos
Usuário do Portal (desenvolvimento de fluxo de prompt)	OpenAI do Azure	Usuário do OpenAI de Serviços Cognitivos
Usuário do Portal (desenvolvimento de fluxo de prompt)	Conta de Armazenamento	Colaborador de Dados do Blob de Armazenamento (usar acesso condicional)
Usuário do Portal (desenvolvimento de fluxo de prompt)	Conta de Armazenamento	Colaborador Privilegiado de Dados de Arquivo de Armazenamento

É importante entender que o hub do AI Studio tem recursos do Azure que são compartilhados entre projetos, como uma Conta de Armazenamento e um Registro de Contêiner. Se você tiver usuários que só precisam de acesso a um subconjunto dos projetos, considere usar condições de atribuição de função, para serviços do Azure que dão suporte a eles, para fornecer acesso com privilégios mínimos aos recursos. Por exemplo, blobs no Armazenamento do Azure dão suporte a condições de atribuição de função. Para um usuário que requer acesso a um subconjunto dos projetos, em vez de atribuir permissões por contêiner, use condições de acesso de função para limitar as permissões aos contêineres de blob usados por esses projetos. Cada projeto tem um GUID exclusivo que serve como um prefixo para os nomes dos contêineres de blob usados nesse projeto. Esse GUID pode ser usado como parte das condições de atribuição de função.

O hub tem um requisito para ter Contributor acesso ao grupo de recursos do hub para permitir que ele crie e gerencie recursos de hub e projeto. Um efeito colateral é que o hub tem acesso ao plano de controle a qualquer recurso também no grupo de recursos. Todos os recursos do Azure não diretamente relacionados ao hub e seus projetos devem ser criados em um grupo de recursos separado. Recomendamos que você crie, no mínimo, dois grupos de recursos para uma equipe de carga de trabalho usando um Hub autogerenciado do Azure AI Studio. Um grupo de recursos para conter o hub, seus projetos e todas as suas dependências diretas, como o registro de contêiner do Azure, o Key Vault e assim por diante. Um grupo de recursos para conter todo o resto em sua carga de trabalho.

Recomendamos que você minimize o uso de recursos do Azure necessários para a operação do hub (Registro de Contêiner, Conta de Armazenamento, Key Vault, Application Insights) por outros componentes em suas cargas de trabalho. Por exemplo, se você precisar armazenar segredos como parte de sua carga de trabalho, deverá criar um Key Vault separado do Key Vault associado ao hub. O Key Vault do hub só deve ser usado pelo hub para armazenar segredos do hub e do projeto.

Certifique-se de que, para cada projeto distinto, as atribuições de função para suas dependências não forneçam acesso aos recursos que o usuário do portal e a identidade gerenciada gerenciada do ponto de extremidade online gerenciado não exigem. Por exemplo, a atribuição de Cognitive Services OpenAI User função ao Azure OpenAI concede acesso a todas as implantações desse recurso. Não há como restringir autores de fluxo ou identidades gerenciadas de ponto de extremidade online gerenciado com esse acesso de atribuição de função a implantações de modelo específicas no Azure OpenAI. Para cenários como esse, nossas diretrizes são implantar serviços como o Azure OpenAI e o Azure AI Search por projeto e não implantar recursos nesses serviços aos quais os autores de fluxo ou identidades gerenciadas de ponto de extremidade online gerenciado não devem ter acesso. Por exemplo, implante apenas modelos na instância do OpenAI do Azure do projeto à qual o projeto requer acesso. Implante apenas índices na instância do Azure AI Search do projeto à qual o projeto deve ter acesso.

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 Azure AI Studio para os serviços de PaaS do Azure

Recomendamos que você configure o hub do Azure AI Studio 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. A rede virtual gerenciada é implantada sob demanda quando você a usa pela primeira vez e é persistente a partir de então.

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

• Sub-redes de treinamento e pontuação - ambas são para trazer sua própria computação relacionada ao treinamento e à inferência. Nessa arquitetura, não estamos fazendo treinamento e estamos usando computação gerenciada.

• 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

Há um serviço nessa arquitetura que usa autenticação baseada em chave: o ponto de extremidade online gerenciado do Machine Learning. Como você usa a autenticação baseada em chave para esse serviço, é 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 você girar manualmente as chaves, crie uma política de expiração de chave e use o Azure Policy para monitorar se a chave foi girada.

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 Azure AI Studio para o Azure Key Vault

A identidade gerenciada do Azure AI Studio 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 AI Studio que exijam acesso a segredos, chaves ou certificados no Key Vault, sua carga de trabalho ou equipe de segurança poderá não se sentir confortável com a identidade gerenciada do hub do Azure AI Studio tendo acesso a esses artefatos. Nesse caso, considere implantar uma instância do Key Vault especificamente para o hub do Azure AI Studio 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 Proteção contra DDoS e o firewall implantado como parte do ponto de extremidade online gerenciado. Outros custos notáveis são a interface do usuário de 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 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.

Runtimes de prompt flow internos

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 Serviço de Aplicativo, são configurados para capturar todos os logs. O Serviço de Aplicativo é configurado para capturar AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs e AppServicePlatformLogs. Na produção, todos os logs provavelmente são excessivos. Ajuste os fluxos de log de acordo com suas necessidades operacionais. Para essa arquitetura, os logs do Azure Machine Learning usados pelo projeto do Azure AI Studio que são de interesse incluem: AmlComputeClusterEvent, AmlDataSetEvent, AmlEnvironmentEvent e AmlModelsEvent.

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

Certifique-se de acompanhar o uso de tokens em relação às implantações do modelo OpenAI do Azure. Nessa arquitetura, o fluxo de prompt rastreia o uso do token por meio de sua integração com o Azure Application Insights.

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 fluxo de prompt oferece uma experiência de criação baseada em navegador no Azure AI Studio ou por meio de uma extensão do Visual Studio Code. Ambas as opções armazenam o código de fluxo como arquivos. Quando você usa o Azure AI Studio, 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. Além disso, embora a rede virtual gerenciada seja fundamental, ela é provisionada automaticamente quando você cria uma instância de computação, o que leva a algumas considerações.

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.

Rede virtual gerenciada sob demanda

A rede virtual gerenciada é provisionada automaticamente quando você cria uma instância de computação pela primeira vez. Se você estiver usando a infraestrutura como código para implantar seu hub e não tiver recursos de computação do AI Studio no Bicep, a rede virtual gerenciada não será implantada e você receberá um erro ao se conectar ao Azure AI Studio. Você precisará executar uma ação única para provisionar manualmente a rede virtual gerenciada após a implantação da IaC.

Organização do recurso

Se você tiver um cenário em que o hub pertence centralmente a uma equipe diferente da equipe de carga de trabalho, poderá optar por implantar projetos em grupos de recursos separados. Se você estiver usando infrastrastructure como código, poderá fazer isso definindo um grupo de recursos diferente no Bicep. Se você estiver usando o portal, poderá definir a defaultWorkspaceResourceGroup propriedade no workspaceHubConfig grupo de recursos que deseja que seus projetos sejam criados.

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
• Fluxo de prompt no Azure AI Studio
• Isolamento de rede virtual gerenciado por workspace
• Configurar um ponto de extremidade privado para um workspace do Machine Learning
• Filtragem de conteúdo