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

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

Este artigo fornece uma arquitetura de linha de base para criar e implantar aplicativos de chat corporativo que usam modelos de linguagem do Serviço OpenAI do Azure. A arquitetura emprega fluxo de prompt para criar fluxos executáveis. Esses fluxos executáveis orquestram o fluxo de trabalho de prompts de entrada para armazenamentos de dados para buscar dados de aterramento para os modelos de linguagem, juntamente com outras lógicas Python necessárias. O fluxo executável é implantado em um ponto de extremidade online gerenciado com computação gerenciada.

A hospedagem da interface do usuário (UI) de chat personalizada segue as diretrizes do aplicativo Web de serviços de aplicativo de linha de base para implantar um aplicativo Web seguro, com redundância de zona e altamente disponível no Serviço de Aplicativo do Azure. Nessa arquitetura, o Serviço de Aplicativo se comunica com a plataforma Azure como uma solução de serviço (PaaS) por meio da integração de rede virtual em pontos de extremidade privados. O Serviço de Aplicativo da Interface do Usuário do chat se comunica com o ponto de extremidade online gerenciado para o fluxo em um ponto de extremidade privado. O acesso público ao 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, juntamente com pontos de extremidade privados gerenciados que permitem a conectividade com recursos privados, como o Armazenamento do Azure no local de trabalho, o Registro de Contêiner do Azure e o Azure OpenAI. Essas conexões privadas são usadas durante a criação e o teste de fluxo e por fluxos que são implantados na computação do Machine Learning.

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

Transfira um ficheiro do Visio desta arquitetura.

Componentes

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

• O Azure OpenAI é usado na arquitetura básica e nesta linha de base. O Azure OpenAI é um serviço totalmente gerenciado que fornece acesso à API REST aos modelos de linguagem do Azure OpenAI, incluindo o conjunto de modelos GPT-4, GPT-3.5-Turbo e incorporações. A arquitetura de linha de base aproveita os recursos corporativos, como rede virtual e link privado, que a arquitetura básica não implementa.
• O Azure AI Studio é uma plataforma que você pode usar para criar, testar e implantar soluções de IA. O AI Studio é usado nessa arquitetura para criar, testar e implantar a lógica de orquestração de fluxo de prompt 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 Application Gateway é um balanceador de carga de camada 7 (HTTP/S) e 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 Web Application Firewall (WAF) é um serviço nativo da nuvem que protege aplicativos Web contra explorações comuns, como injeção de SQL e scripts entre sites. O Web Application Firewall fornece visibilidade do tráfego de e para seu aplicativo Web, permitindo que você monitore e proteja seu aplicativo.
• O Azure Key Vault é um serviço que armazena e gerencia segredos, chaves de criptografia e certificados com segurança. Centraliza a gestão de informação sensível.
• A rede virtual do Azure é um serviço que permite criar redes virtuais privadas isoladas e seguras no Azure. Para um aplicativo Web no Serviço de Aplicativo, você precisa de uma sub-rede de rede virtual para usar pontos de extremidade privados para comunicação segura de rede entre recursos.
• O Private Link possibilita que os clientes acessem os serviços PaaS (plataforma como serviço) do Azure diretamente de redes virtuais privadas sem usar endereçamento IP público.
• O DNS do Azure é um serviço de hospedagem para domínios DNS que fornece resolução de nomes usando a infraestrutura do Microsoft Azure. As zonas DNS privadas fornecem uma maneira de mapear o FQDN (nome de domínio totalmente qualificado) de um serviço para o endereço IP de um ponto de extremidade privado.

Alternativas

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

Espaços de trabalho 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 espaços de trabalho do Azure Machine Learning, pois ambos os serviços têm recursos sobrepostos. Embora o AI Studio seja uma boa escolha se você estiver projetando 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 pode ser feito completamente no estúdio de IA, use o estúdio de IA. Se você ainda precisar de recursos do estúdio de Aprendizado de Máquina do Azure, continue a usar o estúdio de Aprendizado de Máquina do Azure.

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 front-end da interface do usuário do chat. Consulte Escolher um serviço de computação do Azure para todos os cálculos e Escolher um serviço de contêiner do Azure para soluções de contêiner. Por exemplo, enquanto os Aplicativos Web do Azure e o Aplicativo Web para Contêineres foram selecionados para a API da Interface do Usuário do Chat e o host de fluxo de Prompt, respectivamente, resultados semelhantes podem ser alcançados com o Serviço Kubernetes do Azure (AKS) ou os Aplicativos de Contêiner do Azure. Escolha a plataforma de aplicativo da sua carga de trabalho com base nos requisitos funcionais e não funcionais específicos da carga de trabalho.

Hospedagem de fluxo imediato

A implantação de fluxos de prompt não está limitada a clusters de computação do Aprendizado de Máquina, e essa arquitetura ilustra isso com uma alternativa no Serviço de Aplicativo do Azure. Os fluxos são, em última análise, um aplicativo conteinerizado que pode ser implantado em qualquer serviço do Azure que seja compatível com contêineres. Essas opções incluem serviços como o Serviço Kubernetes do Azure (AKS), os Aplicativos de Contêiner do Azure e o Serviço de Aplicativo do Azure. Escolha um serviço de contêiner do Azure com base nos requisitos da sua 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 mais adiante neste artigo.

Armazenamento de dados de aterramento

Embora essa arquitetura lidere com o Azure AI Search, sua escolha de armazenamento de dados para seus dados de aterramento é uma decisão arquitetônica específica para sua carga de trabalho. Muitas cargas de trabalho são, na verdade, poliglotas e têm fontes e tecnologias díspares para fundamentar dados. Essas plataformas de dados variam de armazenamentos de dados OLTP existentes, bancos de dados nativos da nuvem, como o Azure Cosmos DB, até soluções especializadas, como o Azure AI Search. Uma característica comum, mas não necessária, para tal armazenamento de dados é a pesquisa vetorial. Consulte Escolher um serviço do Azure para pesquisa vetorial para explorar opções neste espaço.

Considerações e recomendações

Fiabilidade

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

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

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

Redundância zonal para implantações de fluxo

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

Existem algumas alternativas aos clusters de computação do Aprendizado de Máquina, como o Serviço Kubernetes do Azure (AKS), o Azure Functions, os Aplicativos de Contêiner do Azure e o Serviço de Aplicativo do Azure. Cada um desses serviços suporta zonas de disponibilidade. Para obter redundância zonal para execução rápida de fluxo, sem a complexidade adicional de uma implantação de várias regiões, você deve implantar seus fluxos em um desses serviços.

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

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

1. Os fluxos ainda são criados em fluxo de prompt e a arquitetura de rede permanece inalterada. Os autores de fluxo ainda se conectam à experiência de criação no projeto 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 em contêineres são enviados por push para o Registro de Contêiner. Não são mostrados no diagrama os pipelines que conteinerizam os fluxos e enviam por push para o Registro de Contêiner. A computação na qual esses pipelines são executados deve ter linha de visão de rede para recursos como o registro de contêiner do Azure e o projeto AI Studio.

3. Há outro aplicativo Web implantado no mesmo plano de serviço de aplicativo que já está hospedando a interface do usuário do bate-papo. O novo aplicativo Web hospeda o fluxo de prompt em contêiner, colocalizado no mesmo plano de serviço de aplicativo que já é executado em um mínimo de três instâncias, distribuídas por zonas de disponibilidade. Essas instâncias do Serviço de Aplicativo se conectam ao Registro de Contêiner em um ponto de extremidade privado ao carregar a imagem do contêiner de fluxo de prompt.

4. O contêiner de fluxo de prompt precisa se conectar a todos os serviços dependentes para a execução do fluxo. Nessa arquitetura, o contêiner de fluxo de prompt se conecta à Pesquisa de IA e ao Azure OpenAI. Os serviços de PaaS que foram expostos apenas à sub-rede de ponto de extremidade privada gerenciada pelo Machine Learning agora também precisam ser expostos na rede virtual para que a linha de visão possa ser estabelecida a partir do Serviço de Aplicativo.

Azure OpenAI - fiabilidade

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

Para oferecer suporte a várias instâncias de forma eficaz, recomendamos que você externalize arquivos de ajuste fino, como para uma conta de armazenamento com redundância geográfica. Essa abordagem minimiza o estado armazenado no Azure OpenAI para cada região. Você ainda deve ajustar os arquivos de cada instância para hospedar a implantação do modelo.

É importante monitorar a taxa de transferência necessária em termos de tokens por minuto (TPM) e solicitações por minuto (RPM). Certifique-se de que TPM suficiente atribuído a partir de sua cota para atender à demanda de suas implantações e evitar que as chamadas para seus modelos implantados sejam limitadas. Um gateway, como o Gerenciamento de API do Azure, pode ser implantado na frente do seu serviço ou serviços do Azure OpenAI e pode ser configurado para nova tentativa se houver erros transitórios e limitação. O Gerenciamento de API também pode ser usado como um disjuntor para evitar que o serviço fique sobrecarregado com chamadas, excedendo sua cota. Para saber mais sobre como adicionar um gateway por questões de confiabilidade, consulte Acessar o Azure OpenAI e outros modelos de linguagem por meio de um gateway.

AI Search - fiabilidade

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

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

• Monitore a pesquisa de IA.

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

Azure AI Studio - fiabilidade

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

• Dimensione automaticamente seus endpoints on-line para garantir que haja capacidade suficiente para atender à demanda. Se os sinais de uso não forem oportunos o suficiente devido ao uso de intermitência, considere o provisionamento excessivo para evitar um impacto na confiabilidade de poucas instâncias disponíveis.

• Considere a criação de regras de dimensionamento com base em métricas de implantação, como carga da CPU, e métricas de ponto final, como latência de solicitação.

• Pelo menos três instâncias devem ser implantadas para uma implantação de produção ativa.

• Evite implantações em instâncias em uso. Em vez disso, implante em uma nova implantação e transfira o tráfego depois que a implantação estiver pronta para receber tráfego.

Os endpoints online gerenciados atuam como um balanceador de carga e roteador para a computação gerenciada executada 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 até 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 infraestrutura como código (IaC) para implantar seus recursos, incluindo seus pontos de extremidade online gerenciados, há uma preocupação de confiabilidade. Se você tiver o tráfego configurado para rotear para implantações (criado por meio da CLI ou do Azure AI Studio) e executar uma implantação 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 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 você deseja.

Design multi-região

Esta arquitetura não foi construída para ser um selo regional em uma arquitetura multirregião. Ele fornece alta disponibilidade dentro de uma única região devido ao seu uso completo de zonas de disponibilidade, mas carece de alguns componentes-chave para torná-lo realmente pronto para uma solução de várias regiões. 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 sua carga de trabalho
• Decisões sobre a disponibilidade da região para experiências de desenvolvedor no recurso Azure Studio Hub

Se os requisitos da sua carga de trabalho exigem uma estratégia de várias regiões, você precisa investir em esforços adicionais de design em torno de componentes e processos operacionais além do que é apresentado nessa arquitetura. Você projeta para suportar balanceamento de carga ou failover nas seguintes camadas:

• Dados de aterramento
• Alojamento do 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 termos de observabilidade, experiências de portal e preocupações responsáveis de IA, como segurança de conteúdo.

Segurança

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

Essa arquitetura amplia a pegada de segurança implementada no bate-papo básico de ponta a ponta com a arquitetura OpenAI do Azure. Enquanto a arquitetura básica usa identidades gerenciadas atribuídas pelo sistema e atribuições de função atribuídas ao 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. Do ponto de vista da rede, a única coisa que deve ser acessível a partir da Internet é a interface do usuário do bate-papo via Application Gateway. Do ponto de vista da identidade, a interface do usuário do chat deve autenticar e autorizar solicitações. As identidades gerenciadas são usadas, sempre que possível, para autenticar aplicativos nos serviços do Azure.

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

Gestão de identidades e acessos

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:
  • AI Studio Hub
  • 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 de acesso de identidade para a interface do usuário do chat usando o Microsoft Entra ID

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

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

Funções de acesso baseadas em função do Aprendizado de Máquina

Como na arquitetura básica, o sistema cria automaticamente atribuições de função para as identidades gerenciadas atribuídas ao sistema. Como o sistema não sabe quais recursos do hub e projetos você pode usar, ele cria atribuições de função que suportam todos os recursos potenciais. As atribuições de função criadas automaticamente podem sobrepor os privilégios de provisionamento com base no seu caso de uso. Um exemplo é a função 'Colaborador' atribuída ao hub para o registro de contêiner, onde provavelmente só requer acesso 'Leitor' ao plano 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ê mesmo criará e manterá essas atribuições de função.

Devido à carga de manutenção do gerenciamento de todas as atribuições necessárias, essa arquitetura favorece a excelência operacional em detrimento das atribuições de função de privilégios mínimos absolutos. Observe que você tem que fazer todas as atribuições listadas na tabela.

Identidade gerida	Âmbito	Atribuições de funções
Identidade gerenciada pelo hub	Contribuinte	Grupo de Recursos
Identidade gerenciada pelo hub	Hub	Azure AI Administrator
Identidade gerenciada pelo hub	Container Registry	Contribuinte
Identidade gerenciada pelo hub	Key Vault	Contribuinte
Identidade gerenciada pelo hub	Key Vault	Administrador
Identidade gerenciada pelo hub	Conta de Armazenamento	Leitor
Identidade gerenciada pelo hub	Conta de Armazenamento	Contribuidor de Conta de Armazenamento
Identidade gerenciada pelo hub	Conta de Armazenamento	Contribuidor de Dados de Blobs de Armazenamento
Identidade gerenciada pelo hub	Conta de Armazenamento	Contribuidor com Privilégios aos Dados dos Ficheiros de Armazenamento
Identidade gerenciada pelo hub	Conta de Armazenamento	Contribuidor de Dados de Tabela de Armazenamento
Identidade gerenciada pelo projeto	Project	Azure AI Administrator
Identidade gerenciada pelo projeto	Container Registry	Contribuinte
Identidade gerenciada pelo projeto	Key Vault	Contribuinte
Identidade gerenciada pelo projeto	Key Vault	Administrador
Identidade gerenciada pelo projeto	Conta de Armazenamento	Leitor
Identidade gerenciada pelo projeto	Conta de Armazenamento	Contribuidor de Conta de Armazenamento
Identidade gerenciada pelo projeto	Conta de Armazenamento	Contribuidor de Dados de Blobs de Armazenamento
Identidade gerenciada pelo projeto	Conta de Armazenamento	Contribuidor com Privilégios aos Dados dos Ficheiros de Armazenamento
Identidade gerenciada pelo projeto	Conta de Armazenamento	Contribuidor de Dados de Tabela de Armazenamento
Identidade gerenciada de endpoint online	Project	Segredos de conexão do espaço de trabalho do Azure Machine Learning
Identidade gerenciada de endpoint online	Project	Gravador de métricas do AzureML
Identidade gerenciada de endpoint online	Container Registry	ACRPull
Identidade gerenciada de endpoint online	Azure OpenAI	Utilizador OpenAI dos Serviços Cognitivos
Identidade gerenciada de endpoint online	Conta de Armazenamento	Contribuidor de Dados de Blobs de Armazenamento
Identidade gerenciada de endpoint online	Conta de Armazenamento	Leitor de Dados de Blobs de Armazenamento
Serviço de Aplicativo (quando o fluxo de prompt é implantado no Serviço de Aplicativo)	Azure OpenAI	Utilizador OpenAI dos Serviços Cognitivos
Usuário do Portal (desenvolvimento de fluxo de prompt)	Azure OpenAI	Utilizador OpenAI dos Serviços Cognitivos
Usuário do Portal (desenvolvimento de fluxo de prompt)	Conta de Armazenamento	Contribuidor de Dados de Blob de Armazenamento (use acesso condicional)
Usuário do Portal (desenvolvimento de fluxo de prompt)	Conta de Armazenamento	Contribuidor com Privilégios aos Dados dos Ficheiros 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 acessar um subconjunto dos projetos, considere usar condições de atribuição de função, para serviços do Azure que oferecem suporte a eles, para fornecer acesso de privilégios mínimos aos recursos. Por exemplo, os blobs no Armazenamento do Azure suportam 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 as condições de acesso à 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 do hub e do projeto. Um efeito colateral de que o hub tem acesso de 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 do Azure AI Studio autogerenciado. 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 Cofre da Chave e assim por diante. Um grupo de recursos para conter todo o resto na sua carga de trabalho.

Recomendamos que você minimize o uso dos recursos do Azure necessários para a operação do hub (Registro de Contêiner, Conta de Armazenamento, Cofre de Chaves, 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 Cofre de Chaves separado do Cofre de Chaves associado ao hub. O Cofre da Chave 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 a recursos que o usuário do portal e a identidade gerenciada gerenciada do ponto de extremidade online 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 este, nossa orientação é implantar serviços como o Azure OpenAI e o Azure AI Search por projeto e não implantar recursos para os serviços aos quais os autores de fluxo ou identidades gerenciadas de ponto de extremidade online gerenciadas não deveriam ter acesso. Por exemplo, implante apenas modelos na instância do Azure OpenAI 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

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

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

Fluxos de rede

Dois fluxos neste diagrama são abordados na arquitetura de aplicativo Web do Serviço de Aplicativo de linha de base: o fluxo de entrada do usuário final para a interface do usuário de chat (1) e o fluxo do Serviço de Aplicativo para os serviços PaaS do Azure (2). Esta seção se concentra no fluxo de pontos finais online do Machine Learning. O fluxo a seguir vai da interface do usuário do chat que é executada no aplicativo Web do Serviço de Aplicativo de linha de base para o fluxo implantado na computação do Aprendizado de Máquina:

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

Ingresso no Machine Learning

Nessa arquitetura, o acesso público ao espaço de trabalho do Aprendizado de Máquina está desabilitado. Os usuários podem acessar o espaço de trabalho por meio de acesso privado porque a arquitetura segue o ponto de extremidade privado para a configuração do espaço de trabalho do Aprendizado de Máquina. Na verdade, os pontos de extremidade privados são usados em toda essa arquitetura para complementar a segurança baseada em identidade. Por exemplo, sua interface do usuário de chat hospedada pelo Serviço de Aplicativo pode se conectar a serviços PaaS que não estão expostos à Internet pública, incluindo pontos de extremidade de Aprendizado de Máquina.

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

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

Fluir da rede virtual gerenciada do Azure AI Studio para os serviços PaaS do Azure

Recomendamos que você configure o hub do Azure AI Studio para isolamento de rede virtual gerenciado que exija que todas as conexões de saída sejam aprovadas. Esta arquitetura segue essa recomendação. Existem dois tipos de regras de saída aprovadas. As regras de saída necessárias são para recursos necessários para que a solução funcione, como Registro e Armazenamento de Contêiner. As regras de saída definidas pelo usuário são para recursos personalizados, como o Azure OpenAI ou o AI Search, que seu fluxo de trabalho vai usar. Você deve configurar regras de saída definidas pelo usuário. As regras de saída necessárias são configuradas quando a rede virtual gerenciada é criada. 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. Nessa arquitetura, a conectividade com serviços do Azure, como Registro de Contêiner, Armazenamento, Cofre da Chave do Azure, Azure OpenAI e AI Search são conectados por meio de link privado. Embora não estejam nessa arquitetura, algumas operações comuns que podem exigir a configuração de uma regra de saída FQDN são o download de um pacote pip, a clonagem de um repositório GitHub ou o download de imagens de contêiner base de repositórios externos.

Segmentação e segurança de redes virtuais

A rede nesta arquitetura tem sub-redes separadas para os seguintes fins:

• Gateway de Aplicação

• Componentes de integração do Serviço de Aplicativo

• Pontos finais privados

• Azure Bastion

• Máquina virtual de caixa de salto

• 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.

• Classificação

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

Sub-rede	Interna	De Saída
snet-appGateway	Permissões para nossos usuários de interface do usuário de bate-papo originam 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	Permita apenas o tráfego da rede virtual.	Permita apenas tráfego para a rede virtual.
snet-AppService	Permita apenas o tráfego da rede virtual.	Permita o acesso aos pontos de extremidade privados e ao Azure Monitor.
AzureBastionSubnet	Consulte as orientações em Trabalhar com acesso NSG e Azure Bastion.	Consulte as orientações em Trabalhar com acesso NSG e Azure Bastion.
snet-jumpbox	Permita o protocolo RDP (Remote Desktop Protocol) de entrada e o SSH da sub-rede de host do Azure Bastion.	Permitir o acesso aos pontos finais privados
Agentes SNET	Permita apenas o tráfego da rede virtual.	Permita apenas tráfego para a rede virtual.
SNET-Formação	Permita apenas o tráfego da rede virtual.	Permita apenas tráfego para a rede virtual.
pontuação líquida	Permita apenas o tráfego da rede virtual.	Permita apenas tráfego para a rede virtual.

Todo o outro tráfego é explicitamente negado.

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

• Habilite a Proteção contra DDoS para a rede virtual com uma sub-rede que faça parte de um gateway de aplicativo com um endereço IP público.

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

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

Rotação de chaves

Há um serviço nessa arquitetura que usa autenticação baseada em chave: o ponto de extremidade online gerenciado pelo Machine Learning. Como você usa a autenticação baseada em chave para esse serviço, é importante:

• Armazene a chave em um repositório seguro, como o Cofre da Chave, para acesso sob demanda de clientes autorizados, como o Aplicativo Web do Azure que hospeda o contêiner de fluxo de prompt.

• Implementar uma estratégia de rotação de chaves. Se você girar manualmente as chaves, crie uma política de expiração de chave e use a Política do Azure para monitorar se a chave foi girada.

Ajuste fino do modelo OpenAI

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

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

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

Governação através de políticas

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

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

Atribuições de função do Azure AI Studio para o Azure Key Vault

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

Otimização de custos

A otimização de custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de design para otimização de custos.

Para ver um exemplo de definição de preço para este cenário, utilize a calculadora de preços do Azure. Você precisa personalizar o exemplo para corresponder ao seu uso, pois este exemplo inclui apenas os componentes incluídos na arquitetura. Os componentes mais caros no cenário são a Proteção contra DDoS e o firewall implantado como parte do endpoint online gerenciado. Outros custos notáveis são a interface do usuário do bate-papo e computação de fluxo de prompt e AI Search. Otimize esses recursos para economizar o máximo de custos.

Computação

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

Azure OpenAI

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

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

  • Ser aprovado. Evite expor o serviço de tal forma que suporte o acesso gratuito para todos. Limite o acesso por meio de controles de rede e identidade, como chaves ou controle de acesso baseado em função (RBAC).

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

  • Use lotes, quando possível. Analise os clientes para garantir que eles estejam enviando prompts em lote adequadamente.

  • Otimize a entrada imediata e o comprimento da resposta. Prompts mais longos consomem mais tokens, aumentando o custo, mas prompts que estão faltando contexto suficiente não ajudam os modelos a produzir bons resultados. Crie prompts concisos que forneçam contexto suficiente para permitir que o modelo gere uma resposta útil. Da mesma forma, certifique-se de otimizar o limite do comprimento da resposta.

• O uso do playground do Azure OpenAI deve ser conforme necessário e em instâncias de pré-produção, para que essas atividades não incorram em custos de produção.

• Selecione o modelo de IA certo. A seleção de modelos também desempenha um grande papel no custo geral do Azure OpenAI. Todos os modelos têm pontos fortes e fracos e têm preços individuais. Use o modelo correto para o caso de uso para garantir que você não está gastando demais em um modelo mais caro quando um modelo mais barato produz resultados aceitáveis. Nesta implementação de referência de chat, o GPT 3.5-turbo foi escolhido em vez do GPT-4 para economizar cerca de uma ordem de magnitude dos custos de implantação do modelo enquanto alcançava resultados suficientes.

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

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

• Defina limites de provisionamento. Certifique-se de que toda a cota de provisionamento seja alocada apenas para modelos que devem fazer parte da carga de trabalho, por modelo. A taxa de transferência para modelos já implantados não está limitada a essa cota provisionada enquanto a cota dinâmica estiver habilitada. A cota não é mapeada diretamente para os custos e esse custo pode variar.

• Monitorize a utilização pré-paga. Se você usa preços pré-pagos, monitore o uso de TPM e RPM. Use essas informações para informar decisões de projeto de arquitetura, como quais modelos usar, e otimizar tamanhos de prompt.

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

• Gestão de custos. Siga as orientações sobre como usar recursos de gerenciamento de custos com o OpenAI para monitorar custos, definir orçamentos para gerenciar custos e criar alertas para notificar as partes interessadas sobre riscos ou anomalias.

Excelência operacional

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

Tempos de execução de fluxo de prompt integrados

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

Monitorização

Como na arquitetura básica, os diagnósticos são configurados para todos os serviços. Todos os serviços, exceto o Serviço de Aplicativo, estão configurados para capturar todos os logs. O Serviço de Aplicativo está configurado para capturar AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs, e AppServicePlatformLogs. Na produção, todos os logs são provavelmente excessivos. Ajuste os fluxos de log às suas necessidades operacionais. Para essa arquitetura, os logs do Azure Machine Learning usados pelo projeto 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 de Machine Learning e Azure OpenAI
• Alertas de Aplicativos Web do Azure

Certifique-se de acompanhar o uso de tokens em suas implantações de modelo do Azure OpenAI. 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 no Azure OpenAI, como essa arquitetura, deve seguir as orientações do GenAIOps com fluxo de prompt com o Azure DevOps e com o GitHub. Além disso, deve considerar as práticas recomendadas para integração contínua e entrega contínua (CI/CD) e arquiteturas protegidas pela rede. As orientações a seguir abordam a implementação de fluxos e sua infraestrutura associada com base nas recomendações do GenAIOps. Esta orientação de implantação não inclui os elementos de aplicativo front-end, que não são alterados na arquitetura de aplicativo Web com redundância de zona altamente disponível da Linha de Base.

Desenvolvimento

O fluxo de prompt oferece uma experiência de criação baseada em navegador no Azure AI Studio ou por meio de uma extensão de código do Visual Studio. Ambas as opções armazenam o código de fluxo como arquivos. Quando você usa o Azure AI Studio, os arquivos são armazenados em uma conta de armazenamento. Quando você trabalha no Microsoft Visual Studio Code, os arquivos são armazenados em seu sistema de arquivos local.

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

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

Avaliação

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

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

• Coerência: Avalia quão bem as frases na resposta prevista de um modelo são escritas e como elas se conectam coerentemente umas com as outras.

• Fluência: Avalia a resposta prevista do modelo quanto à sua precisão gramatical e linguística.

• Fundamentação em relação ao contexto: avalia o quão bem as respostas previstas do modelo são baseadas no contexto pré-configurado. Mesmo que as respostas do modelo de linguagem estejam corretas, se não puderem ser validadas em relação ao contexto dado, essas respostas não serão fundamentadas.

• Relevância: Avalia o quão bem as respostas previstas do modelo se alinham com a pergunta feita.

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

• Produza pontuações de avaliações e meça-as em relação a um limiar de sucesso predefinido. Use essas pontuações para relatar aprovação/reprovação no teste em seus pipelines.

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

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

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

Fluxo de implantação

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

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

   • Execução de fluxos de experimentação
   • Execução de testes de unidade configurados
   • Compilação da base de código
   • Análise de código estático

3. O pipeline pode conter uma etapa que requer que pelo menos um membro da equipe aprove manualmente o PR antes da fusão. O aprovador não pode ser o committer e eles têm experiência em fluxo rápido e familiaridade com os requisitos do projeto. Se o PR não for aprovado, a mesclagem será bloqueada. Se o PR for aprovado, ou não houver nenhuma etapa de aprovação, a ramificação do recurso será mesclada na ramificação principal.

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

   1. O pipeline de CI é acionado a partir da mesclagem para Main. O pipeline de CI executa todas as etapas feitas no pipeline de RP e as seguintes etapas:
   • Fluxo de experimentação
   • Fluxo de avaliação
   • Registra os fluxos no Registro de Aprendizado de Máquina quando alterações são detetadas
   1. O pipeline de CD é acionado após a conclusão do pipeline de CI. Esse fluxo executa as seguintes etapas:
   • Implanta o fluxo do registro do Machine Learning para um ponto de extremidade online do Machine Learning
   • Executa testes de integração direcionados ao ponto de extremidade online
   • Executa testes de fumaça que visam o ponto de extremidade on-line

5. Um processo de aprovação é incorporado ao processo de promoção de lançamento – após a aprovação, os processos CI & CD descritos nas etapas 4.a. & 4.b. são repetidos, visando o ambiente de teste. As etapas a. e b. são as mesmas, exceto que os testes de aceitação do usuário são executados após os testes de fumaça no ambiente de teste.

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

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

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

Orientação de implementação

Você pode usar pontos de extremidade de Aprendizado de Máquina para implantar modelos de uma forma que permita flexibilidade ao liberar para produção. Considere as seguintes estratégias para garantir o melhor desempenho e qualidade do modelo:

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

• Testes A/B: as implantações azuis/verdes não só são eficazes para implementar alterações com segurança, mas também podem ser usadas para implantar um novo comportamento que permite que um subconjunto de usuários avalie o impacto da alteração.

• Inclua linting de arquivos Python que fazem parte do fluxo de prompt em seus pipelines. Linting verifica a conformidade com padrões de estilo, erros, complexidade de código, importações não utilizadas e nomenclatura variável.

• Ao implantar seu fluxo no espaço de trabalho de Aprendizado de Máquina isolado da rede, use um agente auto-hospedado para implantar artefatos em seus recursos do Azure.

• O registro do modelo de Aprendizado de Máquina só deve ser atualizado quando houver alterações no modelo.

• Os modelos de linguagem, os fluxos e a interface do usuário do cliente devem ser acoplados de forma flexível. As atualizações dos fluxos e da interface do usuário do cliente podem e devem ser feitas sem afetar o modelo e vice-versa.

• Quando você desenvolve e implanta vários fluxos, cada fluxo deve ter seu próprio ciclo de vida, o que permite uma experiência de acoplamento flexível ao promover fluxos da experimentação à produção.

Infraestrutura

Quando você implanta os componentes de chat de ponta a ponta do Azure OpenAI de linha de base, alguns dos serviços provisionados são fundamentais e permanentes dentro da arquitetura, enquanto outros componentes são de natureza mais efêmera, sua existência vinculada a uma implantação. 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 se estende além de qualquer fluxo de prompt individual ou qualquer implantação de modelo. Esses recursos geralmente são implantados uma vez como parte da implantação fundamental pela equipe de carga de trabalho e mantidos além de novos, removidos ou atualizações para os fluxos de prompt ou implantações de modelo.

• Espaço de trabalho de Aprendizado de Máquina
• Conta de armazenamento para o espaço de trabalho do Aprendizado de Máquina
• Container Registry
• Pesquisa AI
• Azure OpenAI
• Azure Application Insights
• Azure Bastion
• Máquina Virtual do Azure para a caixa de salto

Componentes efêmeros

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

• O modelo no registro do modelo de Aprendizado de Máquina deve ser atualizado, se alterado, como parte do pipeline de CD.

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

• Um ponto de extremidade de Aprendizado de Máquina é criado quando um fluxo de prompt é implantado se a implantação fizer referência a um ponto de extremidade que não existe. Esse ponto de extremidade precisa ser atualizado para desativar o acesso público.

• As implantações do ponto de extremidade do Machine Learning são atualizadas quando um fluxo é implantado ou excluído.

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

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 do IaC.

Organização de recursos

Se você tiver um cenário em que o hub é de propriedade central de uma equipe diferente da equipe de carga de trabalho, você pode 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 sob o workspaceHubConfig para o grupo de recursos que você gostaria que seus projetos fossem criados.

Eficiência de desempenho

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

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

Azure Search - eficiência de desempenho

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

Azure OpenAI - eficiência de desempenho

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

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

Machine Learning - eficiência de desempenho

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

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

• Escolha a SKU de máquina virtual apropriada para o ponto de extremidade online para atender às suas metas de desempenho. Teste o desempenho de uma contagem de instâncias mais baixa e de SKUs maiores versus uma contagem de instâncias maior e SKUs menores para encontrar uma configuração ideal.

Implementar este cenário

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

Contribuidores

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

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

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

Próximo passo

Recursos relacionados

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