Arquitetura de referência de chat do Azure AI Foundry de linha de base

Serviço OpenAI do Azure

Serviços de IA do Azure

Serviço de aplicativo do Azure

Azure Monitor

Os aplicativos de chat corporativo podem capacitar os funcionários por meio de interações de conversa com agentes de IA. Essa funcionalidade é cada vez mais poderosa graças aos avanços contínuos em modelos de linguagem, como modelos gpt da OpenAI e SDKs de orquestração, como Kernel Semântico. Esses aplicativos de chat normalmente consistem nos seguintes componentes:

Uma interface do usuário (interface do usuário) de chat integrada a um aplicativo empresarial maior. Ele fornece aos usuários uma experiência de conversa ao lado de outras funções de negócios.
Repositórios de dados que contêm informações específicas do domínio pertinentes às consultas de usuário.
Modelos de linguagem que explicam os dados específicos do domínio para produzir respostas relevantes.
Um orquestrador ou agente que supervisiona as interações entre fontes de dados, modelos de linguagem e o usuário final.

Este artigo fornece uma arquitetura de linha de base para ajudá-lo a criar e implantar aplicativos de chat corporativo usando o Azure AI Foundry e o Azure OpenAI em Modelos de Fundimento. Essa arquitetura usa um único agente hospedado no Serviço do Azure AI Foundry Agent. O agente recebe mensagens do usuário e consulta armazenamentos de dados para recuperar informações de aterramento para o modelo de idioma.

A interface do usuário de chat segue as diretrizes do aplicativo Web do serviço de aplicativo do Azure de linha de base sobre como implantar um aplicativo Web seguro, com redundância de zona e altamente disponível no Serviço de Aplicativo. Nessa arquitetura, o Serviço de Aplicativo se comunica com a solução paaS (plataforma como serviço) do Azure por meio da integração de rede virtual em pontos de extremidade privados. Na arquitetura da interface do usuário do chat, o Serviço de Aplicativo se comunica com o agente por meio de um ponto de extremidade privado. O acesso público ao portal do Azure AI Foundry e aos agentes está desabilitado.

Importante

Este artigo não descreve os componentes ou as decisões de arquitetura da arquitetura do aplicativo Web do Serviço de Aplicativo de linha de base. Leia esse artigo para obter diretrizes de arquitetura sobre como hospedar o aplicativo Web que contém a interface do usuário do chat.

Essa arquitetura usa a configuração do agente padrão do Serviço do Foundry Agent para habilitar a segurança, a conformidade e o controle de nível empresarial. Nessa configuração, você traz sua própria rede para isolamento de rede e seus próprios recursos do Azure para armazenar o chat e o estado do agente. Toda a comunicação entre os componentes do aplicativo e os serviços do Azure ocorre em pontos de extremidade privados, o que garante que o tráfego de dados permaneça dentro da rede virtual da carga de trabalho. O tráfego de saída dos agentes roteia estritamente por meio do Firewall do Azure, que impõe regras de saída.

Dica

A implementação de referência do Serviço do Foundry Agent mostra uma implementação de chat de ponta a ponta de linha de base no Azure. Ele serve como uma base para desenvolver soluções personalizadas à medida que você avança em direção à produção.

Arquitetura

Baixe um arquivo do Visio dessa arquitetura.

Fluxo de Trabalho

Um usuário do aplicativo interage com uma interface do usuário de chat. As solicitações são roteada por meio do Gateway de Aplicativo do Azure. O Firewall do Aplicativo Web do Azure inspeciona essas solicitações antes de encaminhá-las para o Serviço de Aplicativo de back-end.
Quando o aplicativo Web recebe uma consulta ou instrução de usuário, ele invoca o agente criado com finalidade. O aplicativo Web se comunica com o agente por meio do SDK do Agente de IA do Azure. O aplicativo Web chama o agente por um ponto de extremidade privado e se autentica na Azure AI Foundry usando sua identidade gerenciada.
O agente processa a solicitação do usuário com base nas instruções em seu prompt do sistema. Para atender à intenção do usuário, o agente usa um modelo de linguagem configurado e ferramentas conectadas e repositórios de conhecimento.
O agente se conecta ao repositório de conhecimento (Azure AI Search) na rede privada por meio de um ponto de extremidade privado.
Solicitações para repositórios de conhecimento externos ou ferramentas, como Wikipédia ou Bing, atravessam o Firewall do Azure para inspeção e imposição de política de saída.
O agente se conecta ao modelo de linguagem configurado e passa o contexto relevante.
Antes que o agente retorne a resposta à interface do usuário, ele persiste a solicitação, a resposta gerada e uma lista de repositórios de conhecimento consultados em um banco de dados de memória dedicado. Esse banco de dados mantém o histórico completo da conversa, que permite interações com reconhecimento de contexto e permite que os usuários retomem conversas com o agente sem perder o contexto anterior.

As APIs do Azure AI Foundry dão suporte ao desenvolvimento de experiências do usuário que gerenciam várias conversas simultâneas e isoladas de contexto.

Componentes

Essa arquitetura se baseia na arquitetura básica de referência de chat do Azure AI Foundry. Essa arquitetura apresenta mais serviços do Azure para atender aos requisitos corporativos de confiabilidade, segurança e controle operacional. Cada um dos seguintes componentes desempenha um papel específico em uma solução de chat empresarial de produção:

O Serviço do Foundry Agent fornece a camada de orquestração para interações de chat. Ele hospeda e gerencia agentes que fazem as seguintes tarefas:
- Processar solicitações de usuário
- Coordenar chamadas para ferramentas e outros agentes
- Impor a segurança do conteúdo
- Integrar-se à identidade corporativa, à rede e à observabilidade
A configuração do agente padrão garante o isolamento de rede e fornece controle sobre o armazenamento de dados. Você fornece recursos dedicados do Azure para o estado do agente, o histórico de chat e o armazenamento de arquivos, que o Serviço do Foundry Agent gerencia exclusivamente. Outros componentes do aplicativo na carga de trabalho não devem usar esses recursos necessários.
- O Azure Cosmos DB para NoSQL hospeda o banco de dados de memória dessa carga de trabalho, chamadoenterprise_memory, em sua assinatura. Esse banco de dados armazena o estado operacional do agente, incluindo threads de chat e definições de agente. Esse design garante que o histórico de chat e a configuração do agente sejam isolados, auditáveis e gerenciados de acordo com os requisitos de governança de dados. O Serviço do Foundry Agent gerencia o banco de dados, suas coleções e seus dados.
- Uma conta dedicada do Armazenamento do Azure armazena arquivos carregados durante as sessões de chat. Hospedar essa conta em sua assinatura fornece controle de acesso granular, recursos de auditoria e conformidade com políticas de residência ou retenção de dados. O Serviço do Foundry Agent gerencia os contêineres e o ciclo de vida dos dados dentro desses contêineres.
- Uma instância dedicada da Pesquisa de IA armazena um índice em partes pesquisável de arquivos carregados de conversas com o agente. Ele também armazena arquivos estáticos que são adicionados como fontes de conhecimento quando o agente é criado. O Serviço do Foundry Agent gerencia o índice, o esquema e os dados e usa sua própria estratégia de agrupamento e lógica de consulta.
O Gateway de Aplicativo serve como o ponto de entrada seguro e escalonável para todo o tráfego HTTP e HTTPS para a interface do usuário do chat. Ele fornece terminação TLS (Transport Layer Security) e roteamento baseado em caminho. Ele também distribui solicitações entre zonas de disponibilidade, o que dá suporte a alta disponibilidade e desempenho para a camada de aplicativo Web. Seu back-end é o Serviço de Aplicativo que hospeda o código do aplicativo.
- O Firewall do Aplicativo Web do Azure se integra ao Gateway de Aplicativo para proteger a interface do usuário do chat contra vulnerabilidades e ataques comuns da Web. Ele inspeciona e filtra solicitações HTTP, que fornece uma camada de segurança para aplicativos voltados para o público.
- O Azure Key Vault armazena e gerencia com segurança os certificados TLS exigidos pelo Gateway de Aplicativo. O gerenciamento centralizado de certificados no Key Vault dá suporte à rotação automatizada, à auditoria e à conformidade com os padrões de segurança organizacional. Essa arquitetura não requer chaves armazenadas ou outros segredos.
A Rede Virtual do Azure fornece isolamento de rede para todos os componentes. Quando você coloca recursos em uma rede virtual privada, controla o tráfego leste-oeste e norte-sul, impõe a segmentação, mantém o tráfego privado e habilita a inspeção de fluxos de entrada e saída. Essa configuração ajuda você a atender aos requisitos de segurança e conformidade.
O Link Privado do Azure conecta todos os serviços de PaaS, como O Azure Cosmos DB, Armazenamento, Pesquisa de IA e Serviço do Foundry Agent, à rede virtual por meio de pontos de extremidade privados. Essa abordagem garante que todo o tráfego de dados permaneça no backbone do Azure, o que elimina a exposição à Internet pública e reduz a superfície de ataque.
O Firewall do Azure inspeciona e controla todo o tráfego de saída (saída) da rede virtual. Ele impõe regras baseadas em FQDN (nome de domínio totalmente qualificado), o que garante que apenas destinos aprovados sejam acessíveis. Essa configuração ajuda a impedir a exfiltração de dados e atender aos requisitos de segurança de rede.
O DNS do Azure fornece zonas DNS (Sistema de Nomes de Domínio) privadas vinculadas à rede virtual. Esse recurso permite a resolução de nomes para pontos de extremidade privados, o que garante que toda a comunicação serviço a serviço use endereços IP privados e permaneça dentro do limite de rede.
O armazenamento hospeda o código do aplicativo Web como um arquivo ZIP para implantação no Serviço de Aplicativo. Esse método dá suporte a fluxos de trabalho de implantação automatizados e seguros e separa artefatos de aplicativo de recursos de computação.

Alternativas

Essa arquitetura inclui vários componentes que você pode substituir por outros serviços ou abordagens do Azure, dependendo dos requisitos funcionais e não funcionais da carga de trabalho. Considere as alternativas e as compensações a seguir.

Orquestração de chat

Abordagem atual: Essa arquitetura usa o Serviço do Foundry Agent para orquestrar fluxos de chat, incluindo a busca de dados de aterramento de repositórios de conhecimento e a invocação de modelos do Azure OpenAI. O Serviço do Foundry Agent fornece orquestração não determinística e sem código. Ele lida com solicitações de chat, gerenciamento de threads, invocação de ferramentas, segurança de conteúdo e integração com identidade, rede e observabilidade. Ele fornece uma solução de banco de dados de memória nativa.

Abordagem alternativa: Você pode hospedar automaticamente a camada de orquestração usando estruturas como Kernel Semântico ou LangChain. Use essas estruturas para implementar fluxos de chat determinísticos controlados por código e lógica de orquestração personalizada.

Considere essa alternativa se a carga de trabalho exigir os seguintes recursos:

Controle determinístico refinado sobre a sequência de orquestração, invocação de ferramenta ou engenharia de prompt
Integração com a lógica de negócios personalizada ou sistemas externos que o Foundry Agent Service não dá suporte nativo
Roteamento avançado de solicitação de cliente para experimentação ou práticas de implantação segura
Uma solução de banco de dados de memória personalizada que difere da solução nativa do Serviço do Foundry Agent

A orquestração auto-hospedada aumenta a complexidade operacional e exige que você gerencie a computação, o dimensionamento e a segurança.

Componentes da camada de aplicativo

Abordagem atual: O site front-end da interface do usuário de chat é hospedado no recurso Aplicativos Web do Serviço de Aplicativo, que fornece uma plataforma gerenciada e escalonável para aplicativos Web. Os Aplicativos Web se integram nativamente aos recursos de segurança e rede do Azure.

Abordagem alternativa: Você pode usar outras plataformas de computação gerenciadas pelo Azure, como Aplicativos de Contêiner do Azure ou AKS (Serviço de Kubernetes do Azure), para hospedar a camada de aplicativo.

Considere essa alternativa se sua carga de trabalho atender a qualquer uma das seguintes condições:

Outra plataforma de computação dá melhor suporte a determinados casos de uso e a colocação de serviços nessa plataforma pode melhorar a eficiência de custos e simplificar as operações
Seu aplicativo requer dimensionamento, orquestração ou rede personalizada mais sofisticados

O Serviço de Aplicativo continua sendo a opção preferencial para sua simplicidade na hospedagem de aplicativos Web e suas APIs.

Armazenamento de dados de aterramento (conhecimento)

Abordagem atual: Essa arquitetura usa a Pesquisa de IA como o repositório de dados primário para basear o conhecimento. Ele usa a pesquisa de vetor de Pesquisa de IA e os recursos de classificação semântica.

Abordagem alternativa: Você pode usar outras plataformas de dados para fundamentar o conhecimento, como o Azure Cosmos DB, o Banco de Dados SQL do Azure ou outros armazenamentos de dados OLTP (processamento de transações online). Sua plataforma de dados depende do seu patrimônio de dados existente, dos requisitos de atualização de dados e dos requisitos de consulta.

Considere essa alternativa se sua carga de trabalho atender a qualquer uma das seguintes condições:

Você já gerencia seu conhecimento de aterramento em um banco de dados transacional ou operacional existente
Você precisa de suporte a vários modelos ou SDK não disponíveis na Pesquisa de IA
Você precisa se integrar a fontes de dados especializadas ou sistemas herdados

A pesquisa de vetor é comum para geração aumentada por recuperação, mas nem sempre é necessária. Para obter mais informações, consulte Escolher um serviço do Azure para busca em vetores. Antes de escolher um armazenamento de dados, avalie os padrões de acesso a dados, a latência e as necessidades de escalabilidade da carga de trabalho.

Agente predefinido ou agente criado dinamicamente

Abordagem atual: A implementação de referência usa um agente definido estaticamente implantado como um microsserviço no Azure AI Foundry. A lógica do agente e as fontes de dados são configuradas na implantação e permanecem inalteradas até a próxima versão do aplicativo. Essa abordagem funciona bem quando o comportamento do agente e as fontes de dados são estáveis e controladas por meio de processos de DevOps.

Abordagem alternativa: Você pode criar ou modificar agentes dinamicamente em runtime usando o SDK do Agente de IA do Azure. Essa abordagem permite que o aplicativo instancie agentes sob demanda, ajuste os prompts do sistema ou reconfigure conexões com base no contexto do usuário ou na lógica de negócios.

Considere agentes dinâmicos se sua carga de trabalho exigir os seguintes recursos:

Comportamento personalizado do agente ou fontes de dados para cada usuário ou sessão
Alterações frequentes ou programáticas na configuração do agente
Suporte de agente efêmero específico do contexto para experiências avançadas do usuário

O gerenciamento dinâmico de agentes aumenta a flexibilidade, mas também introduz a carga do gerenciamento do ciclo de vida. Verifique se você tem controles apropriados para criação, modificação e limpeza do agente.

Escolha a abordagem do agente que se alinha aos requisitos de experiência do usuário da carga de trabalho.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, um conjunto de princípios orientadores que você pode usar para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Aplique essa arquitetura e as cargas de trabalho de IA nas diretrizes de design do Azure durante a fase de design da carga de trabalho.

Fiabilidade

A confiabilidade ajuda a garantir que seu aplicativo possa cumprir os compromissos que você faz aos seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para confiabilidade.

A arquitetura do aplicativo Web do Serviço de Aplicativo de linha de base concentra-se na redundância zonal para os principais serviços regionais. As zonas de disponibilidade são locais fisicamente separados em uma região que fornecem redundância quando você implanta duas ou mais instâncias entre elas. Se uma zona tiver tempo de inatividade, outras na região poderão permanecer inalteradas. A arquitetura também distribui instâncias e configurações de serviços do Azure entre zonas de disponibilidade. Para obter mais informações, consulte o aplicativo Web com redundância de zona altamente disponível na linha de base.

Esta seção aborda a confiabilidade de componentes não abordados na arquitetura de linha de base do Serviço de Aplicativo, especificamente o Azure AI Foundry e a AI Search.

Redundância de zona em sua camada de orquestração

As implantações empresariais geralmente exigem redundância zonal para minimizar o risco de interrupção do serviço de falhas no nível da zona. No Azure, redundância zonal significa usar recursos que dão suporte a zonas de disponibilidade e implantação de pelo menos três instâncias ou habilitar redundância no nível da plataforma em que o controle de instância direta não está disponível.

Nessa arquitetura, o Azure AI Foundry hospeda a funcionalidade do Serviço do Agente do Foundry. A confiabilidade do agente depende da disponibilidade das dependências do Serviço do Foundry Agent, que são o Azure Cosmos DB, o Armazenamento e a Pesquisa de IA. O Serviço do Foundry Agent gerencia os dados dentro desses serviços, mas você configura a confiabilidade deles em sua assinatura.

Para obter redundância zonal para a camada de orquestração, siga estas recomendações:

Habilite a redundância de zona em sua conta do Azure Cosmos DB para NoSQL . Essa configuração garante a replicação de dados síncrona em várias zonas, o que reduz o risco de perda de dados ou tempo de inatividade de uma falha de zona única.

Considere também a distribuição global para mitigar interrupções regionais no Azure Cosmos DB.
Use o ZRS (armazenamento com redundância de zona) para sua conta de Armazenamento. Para maior resiliência, use o GZRS (armazenamento com redundância de zona geográfica), que combina redundância zonal e regional.
Configure sua instância de Pesquisa de IA com pelo menos três réplicas. Essa configuração garante que o serviço distribua réplicas entre zonas exclusivas em sua região.

Se o agente se integrar a outras dependências específicas da carga de trabalho, como conexões de ferramentas personalizadas ou repositórios de conhecimento externos, verifique se essas dependências atendem aos seus requisitos de disponibilidade e redundância. Qualquer dependência de zona única ou não alternativa pode prejudicar a confiabilidade geral da camada de orquestração.

O portal do AI Foundry, suas APIs do plano de dados e a funcionalidade do Serviço do Agente de Fundimento não fornecem controles diretos para redundância de zona.

Confiabilidade na hospedagem do modelo do Azure AI Foundry

O Azure AI Foundry fornece modelos como uma hospedagem de serviço (MaaS) com várias opções de implantação. Essas opções dão suporte principalmente ao gerenciamento de cotas e taxa de transferência, em vez da alta disponibilidade tradicional em uma região. As implantações de modelo padrão operam em uma única região e não dão suporte a zonas de disponibilidade. Para obter disponibilidade de vários datacenters, você deve usar uma implantação global ou de modelo de zona de dados.

Para cenários de chat corporativo, implante um modelo padrão de zona de dados provisionado e de zona de dados . Configure a substituição para lidar com o excesso de tráfego ou falhas. Se sua carga de trabalho não exigir baixa latência ou residência e processamento de dados geográficos estritos, use implantações globais para máxima resiliência.

O Azure AI Foundry não dá suporte a mecanismos avançados de failover ou balanceamento de carga, como roteamento round robin ou quebra de circuito, para implantações de modelo. Se você precisar de redundância granular e controle de failover em uma região, hospede sua lógica de acesso de modelo fora do serviço gerenciado. Por exemplo, você pode criar um gateway personalizado usando o Gerenciamento de API do Azure. Essa abordagem permite implementar estratégias personalizadas de roteamento, verificações de integridade e failover. Mas também aumenta a complexidade operacional e desloca a responsabilidade pela confiabilidade desse componente para sua equipe.

Você também pode expor modelos frontais de gateway como ferramentas personalizadas baseadas em API ou repositórios de conhecimento para seu agente. Para mais informações, consulte Usar um gateway na frente de várias implantações ou instâncias do OpenAI do Azure.

Confiabilidade na Pesquisa de IA para conhecimento corporativo

Implante a Pesquisa de IA usando o tipo de preço Standard ou superior em uma região que dá suporte a zonas de disponibilidade. Configure pelo menos três réplicas para garantir que o serviço distribua instâncias entre zonas de disponibilidade separadas. Essa configuração fornece resiliência a falhas no nível de zona e dá suporte à alta disponibilidade para operações de pesquisa.

Para determinar o número ideal de réplicas e partições para sua carga de trabalho, use os seguintes métodos:

Monitore a Pesquisa de IA usando métricas e logs internos. Acompanhe a latência de consulta, a limitação e o uso de recursos.
Use métricas de monitoramento, logs e análise de desempenho para determinar o número apropriado de réplicas. Essa abordagem ajuda você a evitar a limitação de alto volume de consulta, partições insuficientes ou limitações de índice.
Certifique-se de indexar a confiabilidade evitando interrupções de erros periódicos de indexação ou indexação. Considere indexar em um índice offline e trocar do índice dinâmico para o índice recriado depois de validar a integridade dos dados.

Confiabilidade no Firewall do Azure

O Firewall do Azure é um ponto de controle de saída crítico nessa arquitetura, mas representa um único ponto de falha para todo o tráfego de saída. Para reduzir esse risco, implante o Firewall do Azure em todas as zonas de disponibilidade em sua região. Essa configuração ajuda a manter a conectividade de saída se uma zona ficar indisponível.

Se sua carga de trabalho exigir um alto volume de conexões de saída simultâneas, configure o Firewall do Azure com vários endereços IP públicos. Essa abordagem distribui conexões SNAT (Conversão de Endereços de Rede de Origem) em vários prefixos de endereço IP, o que reduz o risco de esgotamento da porta SNAT. O esgotamento de SNAT pode causar perda intermitente ou total de conectividade de saída para agentes e outros componentes de carga de trabalho, o que pode resultar em tempo de inatividade do recurso ou desempenho degradado.

Monitore o uso da porta SNAT e a integridade do firewall. Se você observar falhas de conexão ou problemas de taxa de transferência, examine as métricas e os logs do firewall para identificar e solucionar o esgotamento de SNAT ou outros gargalos.

Isolar dependências do Serviço do Foundry Agent de componentes de carga de trabalho semelhantes

Para maximizar a confiabilidade e minimizar o raio de explosão de falhas, isole estritamente as dependências do Serviço do Agente de Fundimento de outros componentes de carga de trabalho que usam os mesmos serviços do Azure. Especificamente, não compartilhe a Pesquisa de IA, o Azure Cosmos DB ou os recursos de Armazenamento entre o serviço do agente e outros componentes do aplicativo. Em vez disso, provisione instâncias dedicadas para as dependências necessárias do serviço de agente.

Essa separação oferece dois benefícios principais:

Ele contém falhas ou degradação de desempenho para um único segmento de carga de trabalho, o que impede impactos em cascata entre recursos de aplicativo não relacionados.
Ele permite que você aplique processos operacionais direcionados, como backup, restauração e failover. Esses processos são ajustados para os requisitos específicos de disponibilidade e recuperação do fluxo de carga de trabalho que usa esses recursos.

Por exemplo, se o aplicativo de interface do usuário de chat precisar armazenar o estado transacional no Azure Cosmos DB, provisione uma conta e um banco de dados separados do Azure Cosmos DB para essa finalidade, em vez de reutilização da conta ou do banco de dados gerenciado pelo Foundry Agent Service. Mesmo que o custo ou a simplicidade operacional motivam o compartilhamento de recursos, o risco de um evento de confiabilidade que afeta recursos de carga de trabalho não relacionados supera a economia potencial na maioria dos cenários corporativos.

Importante

Se você coloca dados específicos da carga de trabalho com as dependências do agente por motivos operacionais ou de custo, nunca interaja diretamente com os dados gerenciados pelo sistema, como coleções, contêineres ou índices, que o Foundry Agent Service cria. Esses detalhes de implementação interna não estão documentados e estão sujeitos a alterações sem aviso prévio. O acesso direto pode interromper o serviço do agente ou resultar em perda de dados. Sempre use as APIs do plano de dados do Serviço do Foundry Agent para manipulação de dados e trate os dados subjacentes como opacos e somente monitores.

Design de várias regiões

Essa arquitetura usa zonas de disponibilidade para alta disponibilidade em uma única região do Azure. Não é uma solução de várias regiões. Ele não tem os seguintes elementos críticos necessários para resiliência regional e recuperação de desastre (DR):

Entrada global e roteamento de tráfego
Gerenciamento de DNS para failover
Estratégias de replicação ou isolamento de dados entre regiões
Uma designação ativo-ativo, ativo-passivo ou ativo-frio
Processos regionais de failover e failback para atender aos RTOs (objetivos de tempo de recuperação) e aos RPOs (objetivos de ponto de recuperação)
Consideração da disponibilidade da região para experiências de desenvolvedor, incluindo o portal do Azure AI Foundry e as APIs do plano de dados

Se sua carga de trabalho exigir continuidade dos negócios se ocorrer uma interrupção regional, você deverá projetar e implementar componentes extras e processos operacionais além dessa arquitetura. Especificamente, você precisa lidar com o balanceamento de carga e o failover em cada camada arquitetônica, incluindo as seguintes áreas:

Aterramento de dados (repositórios de conhecimento)
Pontos de extremidade de hospedagem e inferência de modelo
A camada de orquestração ou agente
Tráfego de interface do usuário voltado para o usuário e pontos de entrada DNS

Você também deve garantir que os controles de observabilidade, monitoramento e segurança de conteúdo permaneçam operacionais e consistentes entre regiões.

Essa arquitetura de linha de base não tem recursos de várias regiões, portanto, as interrupções regionais provavelmente resultarão em perda de serviço em sua carga de trabalho.

Recuperação de desastre

As arquiteturas de chat contêm componentes com estado, portanto, o planejamento de DR é essencial. Essas cargas de trabalho normalmente exigem um repositório de memória para sessões de chat ativas ou pausadas. Eles também exigem armazenamento para dados complementares, como documentos ou imagens, adicionados aos threads de chat. A camada de orquestração do agente também pode manter o estado específico dos fluxos de conversa. Nessa arquitetura, o Serviço do Foundry Agent usa o Azure Cosmos DB, o Armazenamento e a Pesquisa de IA para manter o estado operacional e transacional. O ciclo de vida e o acoplamento desse estado entre componentes determinam suas operações de recuperação e estratégia de RECUPERAÇÃO.

Para o Serviço do Foundry Agent, verifique se você pode recuperar todas as dependências para um ponto consistente no tempo. Essa abordagem ajuda a manter a integridade transacional entre as três dependências externas.

As seguintes recomendações abordam a DR para cada serviço:

Azure Cosmos DB: Habilite o backup contínuo para o enterprise_memory banco de dados. Essa configuração fornece PITR (restauração pontual) com um RPO de sete dias, que inclui definições de agente e threads de chat. Teste o processo de restauração regularmente para confirmar se ele atende ao RTO e se os dados restaurados permanecem disponíveis para o serviço do agente. Sempre restaure para a mesma conta e banco de dados.
Pesquisa de IA: A Pesquisa de IA não tem funcionalidades de restauração interna e não dá suporte à manipulação direta de índice. Se ocorrer perda de dados ou corrupção, entre em contato com o suporte da Microsoft para obter assistência com a restauração do índice. Essa limitação pode afetar significativamente o RTO. Se a interface do usuário do chat não der suporte a uploads de arquivos e você não tiver agentes que usam arquivos estáticos como conhecimento, talvez você não precise de um plano de recuperação de desastre para a Pesquisa de IA.

Mantenha uma fonte de verdade separada e atualizada regularmente para seu conhecimento de base da empresa. Essa prática garante que você possa recompilar índices quando necessário.
Armazenamento: Se você tiver uma conta de armazenamento com redundância geográfica, use o failover gerenciado pelo cliente para contêineres de blob que o Foundry Agent Service usa. Essa configuração permite que você inicie o failover durante uma interrupção regional. Se você usar apenas o armazenamento com redundância de zona, entre em contato com o suporte da Microsoft para restaurar dados. Esse processo pode estender seu RTO. Assim como acontece com a Pesquisa de IA, se a interface do usuário do chat não der suporte a uploads de arquivos e você não tiver agentes que usam arquivos estáticos como conhecimento, talvez você não precise de um plano de dr para contêineres de blob.
Consistência transacional: Se o repositório de estado em sua carga de trabalho fizer referência a identificadores de agente de IA do Azure, como IDs de thread ou IDs de agente, coordene a recuperação em todos os armazenamentos de dados relevantes. Restaurar apenas um subconjunto de dependências pode resultar em dados órfãos ou inconsistentes. Projete seus processos de recuperação de desastre para manter a integridade referencial entre sua carga de trabalho e o estado do serviço de agente.
Definições e configuração do agente: Defina agentes como código. Armazenar definições de agente, conexões, prompts do sistema e parâmetros no controle do código-fonte. Essa prática permite reimplantar agentes de uma boa configuração conhecida se você perder a camada de orquestração. Evite fazer alterações não rastreadas na configuração do agente por meio do portal do AI Foundry ou das APIs do plano de dados. Essa abordagem garante que os agentes implantados permaneçam reproduzíveis.

Antes de migrar para a produção, crie um runbook de recuperação que resolva falhas no estado de propriedade do aplicativo e no estado de propriedade do agente.

Segurança

A segurança fornece garantias contra ataques deliberados e o uso indevido 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 estende a base de segurança estabelecida na arquitetura básica de referência de chat do Azure AI Foundry. A principal diferença é a adição de um perímetro de segurança de rede junto com o perímetro de identidade da arquitetura básica. Do ponto de vista da rede, o Gateway de Aplicativo é o único recurso exposto pela Internet. Ele disponibiliza o aplicativo de interface do usuário de chat para os usuários. De um ponto de vista da identidade, a interface do usuário de bate-papo deve autenticar e autorizar solicitações. Use identidades gerenciadas quando possível para autenticar aplicativos nos serviços do Azure.

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

Gerenciamento de identidade e acesso

Essa arquitetura usa principalmente identidades gerenciadas atribuídas pelo sistema para autenticação serviço a serviço. Você também pode usar identidades gerenciadas atribuídas pelo usuário. Em ambos os casos, aplique os seguintes princípios:

Isolar identidades por recurso e função. Provisione identidades gerenciadas distintas para os seguintes componentes:
- A conta do Azure AI Foundry
- Cada projeto do Azure AI Foundry
- O aplicativo Web
- Qualquer orquestrador personalizado ou código de integração
Atribua uma identidade a um recurso do Azure somente se esse recurso precisar se autenticar como um cliente para outro serviço do Azure.
Use tipos de identidade adequados para fins. Sempre que possível, use identidades de carga de trabalho para aplicativos e automação e use identidades de agente para agentes de IA.

Acesso de funcionários do portal do Azure AI Foundry

Ao integrar funcionários a projetos do Azure AI Foundry, atribua as permissões mínimas necessárias para a função. Use os grupos de ID do Microsoft Entra e o RBAC (controle de acesso baseado em função) para impor a separação de tarefas. Por exemplo, distingue os desenvolvedores de agente de cientistas de dados que lidam com tarefas de ajuste fino. No entanto, esteja ciente das limitações e dos riscos.

O portal do Azure AI Foundry executa muitas ações usando a identidade do serviço em vez da identidade do funcionário. Como resultado, os funcionários que têm funções RBAC limitadas podem ter visibilidade de dados confidenciais, como threads de chat, definições de agente e configuração. Esse design do portal do AI Foundry pode ignorar inadvertidamente as restrições de acesso desejadas e expor mais informações do que o esperado.

Para atenuar o risco de acesso não autorizado, restrinja o uso do portal em ambientes de produção a funcionários que tenham uma necessidade operacional clara. Para a maioria dos funcionários, desabilite ou bloqueie o acesso ao portal do Azure AI Foundry em produção. Em vez disso, use pipelines de implantação automatizados e iac (infraestrutura como código) para gerenciar a configuração do agente e do projeto.

Trate a criação de novos projetos em uma conta do Azure AI Foundry como uma ação privilegiada. Os projetos criados por meio do portal não herdam automaticamente seus controles de segurança de rede estabelecidos, como pontos de extremidade privados ou NSGs (grupos de segurança de rede). E novos agentes nesses projetos ignoram o perímetro de segurança pretendido. Imponha a criação de projetos exclusivamente por meio de seus processos de IaC controlados e auditáveis.

Atribuições e conexões de função de projeto do Azure AI Foundry

Para usar o Serviço do Foundry Agent no modo Standard, o projeto deve ter permissões administrativas nas dependências do Serviço do Foundry Agent. Especificamente, a identidade gerenciada do projeto deve ter atribuições de função elevadas na conta de Armazenamento, na Pesquisa de IA e na conta do Azure Cosmos DB. Essas permissões fornecem acesso quase completo a esses recursos, incluindo a capacidade de ler, gravar, modificar ou excluir dados. Para manter o acesso de privilégios mínimos, isole seus recursos de carga de trabalho das dependências do Serviço do Agente de Fundiário.

Todos os agentes em um único projeto de AI Foundry compartilham a mesma identidade gerenciada. Se a carga de trabalho usar vários agentes que exigem acesso a diferentes conjuntos de recursos, o princípio do privilégio mínimo exigirá que você crie um projeto separado do Azure AI Foundry para cada padrão de acesso de agente distinto. Essa separação permite atribuir apenas as permissões mínimas necessárias à identidade gerenciada de cada projeto, o que reduz o risco de acesso excessivo ou não intencional.

Quando você estabelecer conexões com recursos externos de dentro do Azure AI Foundry, use a autenticação baseada em ID do Microsoft Entra, se disponível. Essa abordagem elimina a necessidade de manter segredos pré-compartilhados. Escopo de cada conexão para que somente o projeto proprietário possa usá-la. Se vários projetos exigirem acesso ao mesmo recurso, crie uma conexão separada em cada projeto em vez de compartilhar uma única conexão entre projetos. Essa prática impõe limites de acesso estritos e impede que projetos futuros herdem o acesso que eles não exigem.

Evite criar conexões no nível da conta do Azure AI Foundry. Essas conexões se aplicam a todos os projetos atuais e futuros na conta. Eles podem conceder inadvertidamente amplo acesso aos recursos, violar princípios de privilégio mínimo e aumentar o risco de exposição de dados não autorizados. Prefira apenas conexões no nível do projeto.

Rede

Além do acesso baseado em identidade, essa arquitetura requer confidencialidade de rede.

O design de rede inclui as seguintes proteções:

Um único ponto de entrada seguro para todo o tráfego de interface do usuário de chat, o que minimiza a superfície de ataque
Tráfego de rede de entrada e saída filtrado usando uma combinação de NSGs, um firewall de aplicativo Web, UDRs (rotas definidas pelo usuário) e regras de Firewall do Azure
Criptografia de ponta a ponta de dados em trânsito usando TLS
Privacidade de rede usando o Link Privado para todas as conexões de serviço de PaaS do Azure
Segmentação lógica e isolamento de recursos de rede, com sub-redes dedicadas para cada agrupamento de componentes principal para dar suporte a políticas de segurança granulares

Fluxos de rede

A arquitetura do aplicativo Web do Serviço de Aplicativo de linha de base descreve o fluxo de entrada do usuário para a interface do usuário do chat e o fluxo do Serviço de Aplicativo para os serviços de PaaS do Azure. Esta seção se concentra nas interações do agente.

Quando a interface do usuário de chat se comunica com o agente implantado no Azure AI Foundry, ocorrem os seguintes fluxos de rede:

A interface do usuário de chat hospedada no Serviço de Aplicativo inicia solicitações HTTPS por meio de um ponto de extremidade privado para o ponto de extremidade da API do plano de dados do Azure AI Foundry.
Quando o agente acessa os serviços de PaaS do Azure, como dependências de serviço, repositórios de conhecimento personalizados ou ferramentas personalizadas, ele envia solicitações HTTPS da sub-rede delegada para os pontos de extremidade privados desses serviços.
Quando o agente acessa recursos fora da rede virtual, incluindo APIs baseadas na Internet ou serviços externos, ele é forçado a rotear essas solicitações HTTPS da sub-rede delegada por meio do Firewall do Azure.

Os pontos de extremidade privados servem como um controle de segurança crítico nessa arquitetura, complementando a segurança baseada em identidade.

Entrada para o Azure AI Foundry

Essa arquitetura desabilita o acesso público ao plano de dados do Azure AI Foundry permitindo apenas o tráfego por meio de um link privado para o Azure AI Foundry. Você pode acessar grande parte do portal do Azure AI Foundry por meio do site do portal, mas todas as funcionalidades no nível do projeto exigem acesso à rede. O portal depende das APIs do plano de dados da sua conta do AI Foundry, que só podem ser acessadas por meio de pontos de extremidade privados. Como resultado, desenvolvedores e cientistas de dados devem acessar o portal por meio de uma jump box, uma rede virtual emparelhada ou uma conexão VPN site a site ou ExpressRoute.

Todas as interações programáticas com o plano de dados do agente, como do aplicativo Web ou do código de orquestração externa ao invocar a inferência de modelo, também devem usar esses pontos de extremidade privados. Os pontos de extremidade privados são definidos no nível da conta, não no nível do projeto. Portanto, todos os projetos na conta compartilham o mesmo conjunto de pontos de extremidade. Você não pode segmentar o acesso à rede no nível do projeto e todos os projetos compartilham a mesma exposição de rede.

Para dar suporte a essa configuração, configure o DNS para os seguintes pontos de extremidade da API FQDN do Azure AI Foundry:

privatelink.services.ai.azure.com
privatelink.openai.azure.com
privatelink.cognitiveservices.azure.com

O diagrama a seguir mostra como um desenvolvedor de IA se conecta por meio do Azure Bastion a uma caixa de salto de máquina virtual (VM). Nesse jump box, o autor pode acessar o projeto no portal do Azure AI Foundry por meio de um ponto de extremidade privado na mesma rede.

Controlar o tráfego da sub-rede do agente do Azure AI Foundry

Essa arquitetura roteia todo o tráfego de rede de saída (saída) da funcionalidade do Serviço do Foundry Agent por meio de uma sub-rede delegada em sua rede virtual. Essa sub-rede serve como o único ponto de saída para as três dependências de serviço necessárias do agente e quaisquer fontes de conhecimento externas ou conexões de ferramenta que o agente usa. Esse design ajuda a reduzir as tentativas de exfiltração de dados de dentro da lógica de orquestração.

Ao forçar esse caminho de saída, você obtém controle total sobre o tráfego de saída. Você pode aplicar regras NSG granulares, roteamento personalizado e controle DNS a todo o tráfego de agente que sai do serviço.

O serviço de agente usa a configuração DNS da rede virtual para resolver registros de ponto de extremidade privado e FQDNs externos necessários. Essa configuração garante que as solicitações do agente gerem logs DNS, que dão suporte à auditoria e à solução de problemas.

O NSG anexado à sub-rede de saída do agente bloqueia todo o tráfego de entrada porque nenhuma entrada legítima deve ocorrer. As regras de NSG de saída permitem o acesso apenas a sub-redes de ponto de extremidade privado dentro da rede virtual e à porta TCP (Protocolo de Controle de Transmissão) 443 para tráfego associado à Internet. O NSG nega todo o outro tráfego.

Para restringir ainda mais o tráfego de Internet, essa arquitetura aplica uma UDR à sub-rede, que direciona todo o tráfego HTTPS por meio do Firewall do Azure. O firewall controla quais FQDNs o agente pode acessar por meio de conexões HTTPS. Por exemplo, se o agente precisar acessar apenas o Aterramento com APIs públicas do Bing, configure o Firewall do Azure para permitir o tráfego api.bing.microsoft.com na porta 443 dessa sub-rede. Todos os outros destinos de saída são negados.

Segmentação e segurança de redes virtuais

Essa arquitetura segmenta a rede virtual atribuindo cada grupo de componentes principal à sua própria sub-rede. Cada sub-rede tem um NSG dedicado que limita o tráfego de entrada e saída apenas ao que o componente requer.

A tabela a seguir resume a configuração do NSG e do firewall para cada sub-rede.

Nome de uso ou sub-rede	Tráfego de entrada (NSG)	Tráfego de saída (NSG)	UDR para firewall	Regras de saída do firewall
Pontos de extremidade privados `snet-privateEndpoints`	Rede virtual	Nenhum tráfego permitido	Sim	Nenhum tráfego permitido
Portal de Aplicações `snet-appGateway`	Endereços IP de origem do usuário da interface do usuário de chat, como a Internet pública e fontes necessárias para o serviço	Sub-rede de ponto de extremidade privado e itens necessários para o serviço	Não	-
Serviço de Aplicativo `snet-appServicePlan`	Nenhum tráfego permitido	Pontos de extremidade privados e Azure Monitor	Sim	Para o Azure Monitor
Serviço de Agente da Fábrica `snet-agentsEgress`	Nenhum tráfego permitido	Pontos de extremidade privados e a Internet	Sim	Somente FQDNs públicos que você permite que seus agentes usem
Jump box VMs `snet-jumpBoxes`	Sub-rede do Azure Bastion	Pontos de extremidade privados e a Internet	Sim	Conforme necessário para a VM
Agente de compilação `snet-buildAgents`	Sub-rede do Azure Bastion	Pontos de extremidade privados e a Internet	Sim	Conforme necessário para a VM
Azure Bastion `AzureBastionSubnet`	Consulte o acesso ao NSG e o Azure Bastion	Consulte o acesso ao NSG e o Azure Bastion	Não	-
Azure Firewall `AzureFirewallSubnet` `AzureFirewallManagementSubnet`	Nenhum NSG	Nenhum NSG	Não	-

Esse design nega explicitamente todos os outros tráfegos, por meio de regras NSG ou por padrão no Firewall do Azure.

Ao implementar a segmentação e a segurança de rede nesta arquitetura, siga estas recomendações:

Implante um plano de Proteção contra DDoS do Azure no endereço IP público do Gateway de Aplicativo para mitigar ataques volumetricos.
Anexe um NSG a cada sub-rede compatível com ele. Aplique as regras mais rigorosas possíveis sem interromper a funcionalidade necessária.
Aplique o túnel forçado a todas as sub-redes com suporte para que o firewall de saída possa inspecionar todo o tráfego de saída. Use o túnel forçado mesmo em sub-redes em que você não espera saída. Esse método adiciona uma medida de defesa detalhada que protege contra uso indevido intencional ou acidental da sub-rede.

Governança por meio da política

Para se alinhar à linha de base de segurança da carga de trabalho, use o Azure Policy e as políticas de rede para garantir que todos os recursos de carga de trabalho atendam aos seus requisitos. A automação de plataforma por meio da política reduz o risco de descompasso de configuração de segurança e ajuda a reduzir as atividades de validação manual.

Considere implementar os seguintes tipos de políticas de segurança para fortalecer sua arquitetura:

Desabilite métodos de autenticação locais ou baseados em chave em serviços como serviços de IA do Azure e Key Vault.
Exigir configuração explícita de regras de acesso à rede, pontos de extremidade privados e NSGs.
Exigir criptografia, como chaves gerenciadas pelo cliente.
Restrinja a criação de recursos, como limitar regiões ou tipos de recursos.

Otimização de custos

A Otimização de Custos concentra-se em maneiras 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.

Essa estimativa de preços do Azure fornece um exemplo de preços para essa arquitetura. Este exemplo inclui apenas os componentes nessa arquitetura, portanto, personalize-o para corresponder ao seu uso. Os componentes mais caros no cenário são o Azure Cosmos DB, a Pesquisa de IA e a Proteção contra DDoS. Outros custos notáveis incluem a computação da interface do usuário de chat e o Gateway de Aplicativo. Otimize esses recursos para reduzir custos.

Serviço de Agente da Fábrica

Ao usar a implantação padrão, você deve provisionar e gerenciar as dependências do serviço em sua própria assinatura do Azure.

As recomendações a seguir explicam como otimizar os custos desses serviços necessários:

O Serviço do Agente do Foundry gerencia a alocação de RU (unidade de solicitação) no Azure Cosmos DB. Para reduzir os custos de longo prazo, compre a capacidade reservada para o Azure Cosmos DB. Alinhe as reservas com a duração e o volume de uso esperados. Tenha em mente que a capacidade reservada requer compromisso inicial e não tem flexibilidade se os padrões de uso da carga de trabalho mudarem significativamente.
Se o cenário de chat não exigir uploads de arquivo, exclua esse recurso em seu aplicativo. Nesse caso, aplique as seguintes alterações de configuração:
- Use uma camada LRS (armazenamento com redundância local) para a conta de Armazenamento.
- Configure a Pesquisa de IA com uma única réplica em vez das três réplicas recomendadas.
Exclua regularmente agentes não utilizados e seus threads associados usando o SDK ou AS APIs REST. Agentes e threads obsoletos continuam consumindo armazenamento e podem aumentar os custos no Azure Cosmos DB, armazenamento e Pesquisa de IA.
Desabilite recursos de recursos dependentes que sua carga de trabalho não exige, como os seguintes recursos:
- O classificador semântico na Pesquisa de IA
- Os recursos de gravação de gateway e várias regiões no Azure Cosmos DB
Para evitar encargos de largura de banda entre regiões, implante o Azure Cosmos DB, o Armazenamento e o AI Search na mesma região do Azure que o Foundry Agent Service.
Evite colocar dados específicos da carga de trabalho nos mesmos recursos do Azure Cosmos DB ou da Pesquisa de IA que o Foundry Agent Service usa. Em alguns casos, você pode compartilhar esses recursos para reduzir a capacidade não utilizada em RUs ou unidades de pesquisa, o que reduz o custo. Considere apenas o compartilhamento de recursos após uma avaliação completa de risco para trocas de confiabilidade, segurança e desempenho.

Conhecimento e ferramentas do agente

O Serviço do Foundry Agent executa a lógica do agente de maneira não determinística. Ele pode invocar qualquer repositório de conhecimento conectado, ferramenta ou outro agente para cada solicitação, mesmo que esse recurso não seja relevante para a consulta do usuário. Esse comportamento pode resultar em chamadas desnecessárias a APIs externas ou fontes de dados, aumentar custos para cada transação e introduzir padrões de uso imprevisíveis que complicam a previsão do orçamento.

Para controlar os custos e manter um comportamento previsível, aplique as seguintes estratégias:

Conecte apenas os repositórios de conhecimento, ferramentas ou agentes que provavelmente serão usados com a maioria das invocações de agente. Evite conectar recursos que raramente são necessários ou que incorram em custos altos para cada chamada, a menos que sejam essenciais.
Projete e refinar cuidadosamente o prompt do sistema para instruir o agente a minimizar chamadas externas desnecessárias ou redundantes. O prompt do sistema deve orientar o agente a usar apenas as conexões mais relevantes para cada solicitação.
Use a telemetria da Azure AI Foundry para monitorar quais APIs externas, repositórios de conhecimento ou ferramentas acessam o agente, com que frequência ele os acessa e os custos associados. Examine regularmente essa telemetria para identificar padrões de uso inesperados ou picos de custo e ajuste o prompt do sistema conforme necessário.
Lembre-se de que a invocação não determinística pode dificultar a previsão de custos, especialmente ao integrar com APIs limitadas. Se você precisar de custos previsíveis, considere a auto-hospedagem do orquestrador usando código determinístico.

Modelos do OpenAI do Azure

Implantações de modelo no Azure AI Foundry usam a abordagem maaS. Os custos dependem principalmente do uso ou da alocação pré-provisionada.

Para controlar os custos do modelo de consumo nessa arquitetura, use uma combinação das seguintes abordagens:

Controlar clientes. As solicitações do cliente geram a maioria dos custos em um modelo de consumo, portanto, controlar o comportamento do agente é crucial.

Para reduzir o uso desnecessário, execute as seguintes ações:
- Aprovar todos os consumidores de modelo. Não exponha modelos de uma maneira que permita acesso irrestrito.
- Impor restrições de limitação de token, como max_tokens e max_completions por meio da lógica do agente. Esse controle só está disponível na orquestração auto-hospedada. O Serviço do Foundry Agent não dá suporte a essa funcionalidade.
- Otimize a entrada do prompt e o comprimento da resposta. Prompts mais longos consomem mais tokens, o que aumenta o custo. Prompts que não têm contexto suficiente reduzem a eficácia do modelo. Crie prompts concisos que deem contexto suficiente para permitir que o modelo gere uma resposta útil. Certifique-se de otimizar o limite do comprimento da resposta.
  
  Esse nível de controle só está disponível na orquestração auto-hospedada. O Serviço do Foundry Agent não fornece configuração suficiente para dar suporte a essa funcionalidade.
Escolha o modelo certo para o agente. Selecione o modelo mais barato que atenda aos requisitos do agente. Evite usar modelos de custo mais alto, a menos que eles sejam essenciais. Por exemplo, a implementação de referência usa GPT-4o em vez de um modelo mais caro e obtém resultados suficientes.
Monitorar e gerenciar o uso. Use o Gerenciamento de Custos da Microsoft e a telemetria de modelo para acompanhar o uso de token, definir orçamentos e criar alertas para anomalias. Examine regularmente os padrões de uso e ajuste as cotas ou o acesso ao cliente conforme necessário. Para obter mais informações, consulte Planejar e gerenciar custos para o Azure AI Foundry.
Use o tipo de implantação correto. Use o preço pago conforme o uso para cargas de trabalho imprevisíveis e mude para a taxa de transferência provisionada quando o uso for estável e previsível. Combine ambas as opções ao estabelecer uma linha de base confiável.
Restringir o uso do playground. Para evitar custos de produção não planejados, restrinja o uso do playground do Azure AI Foundry apenas para ambientes de pré-produção.
Planeje o ajuste fino e a geração de imagem com cuidado. Esses recursos têm modelos de cobrança diferentes. Eles são cobrados por hora ou por lote. Agende o uso para se alinhar aos intervalos de cobrança e evitar desperdícios.

Recursos de segurança de rede

Essa arquitetura requer o Firewall do Azure como um ponto de controle de saída. Para otimizar os custos, use a camada Básica do Firewall do Azure, a menos que o restante dos componentes da carga de trabalho exija recursos avançados. Camadas mais altas adicionam custo, portanto, use-as somente se você precisar de suas funcionalidades.

Se sua organização usar zonas de destino do Azure, considere usar recursos de DDoS (firewall compartilhado e negação de serviço distribuído) para adiar ou reduzir custos. Cargas de trabalho que têm requisitos de desempenho e segurança semelhantes podem se beneficiar de recursos compartilhados. Verifique se os recursos compartilhados não introduzem riscos operacionais ou de segurança. Essa arquitetura, implantada em uma zona de destino do Azure, usa recursos compartilhados.

Excelência operacional

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

As diretrizes de excelência operacional a seguir não incluem os elementos de aplicativo front-end, que permanecem os mesmos que a arquitetura de aplicativo Web com redundância de zona altamente disponível.

Ao planejar seus ambientes de experimentação, teste e produção, estabeleça recursos distintos e isolados da AI Foundry, incluindo dependências.

Computação do agente

A Microsoft gerencia totalmente a plataforma de computação sem servidor para APIs REST do Agente de IA do Azure e a lógica de implementação de orquestração. Uma orquestração auto-hospedada fornece mais controle sobre as características de runtime e a capacidade, mas você deve gerenciar diretamente as operações do dia 2 para essa plataforma. Avalie as restrições e as responsabilidades de sua abordagem para entender quais operações do dia 2 você deve implementar para dar suporte à camada de orquestração.

Em ambas as abordagens, você deve gerenciar o armazenamento de estado, como histórico de chat e configuração de agente para durabilidade, backup e recuperação.

Monitorização

Semelhante à arquitetura básica, os dados de diagnóstico de todos os serviços são configurados para serem enviados para o workspace do Log Analytics da carga de trabalho. Todos os serviços, exceto o Serviço de Aplicativo, capturam todos os logs. Em produção, talvez você não precise capturar todos os logs. Por exemplo, o aplicativo de interface do usuário de chat pode exigir AppServiceHTTPLogsapenas , AppServiceConsoleLogs, , AppServiceAppLogse AppServicePlatformLogsAppServiceAuthenticationLogs. Ajuste os fluxos de log de acordo com suas necessidades operacionais.

Avalie alertas personalizados, como alertas personalizados nos alertas de linha de base do Azure Monitor, para os recursos nessa arquitetura. Considere os seguintes alertas:

Monitore o uso de tokens em relação às implantações de modelo. Nessa arquitetura, o Azure AI Foundry acompanha o uso de token por meio de sua integração com o Application Insights.

Suas caixas de salto e VMs do agente de build residem em um local altamente privilegiado, que fornece a essas VMs uma linha de visão de rede para o plano de dados de todos os componentes em sua arquitetura. Verifique se essas VMs emitem logs suficientes para entender quando são usadas, quem as usa e quais ações elas executam.

Controle de versão do agente e ciclo de vida

Trate cada agente como uma unidade implantável independentemente em sua carga de trabalho de chat, a menos que você projete especificamente seu aplicativo para criar e excluir agentes dinamicamente em runtime. Esses agentes têm requisitos de gerenciamento de ciclo de vida semelhantes a outros microsserviços em sua carga de trabalho.

Para evitar interrupções de serviço, verifique a implantação segura e controlada do agente implementando as seguintes abordagens:

Defina agentes como código. Sempre armazene definições de agente, conexões, prompts do sistema e parâmetros de configuração no controle do código-fonte. Essa prática garante a rastreabilidade e a reprodutibilidade. Evite alterações não rastreadas por meio do portal do Azure AI Foundry.
Automatizar a implantação do agente. Use os pipelines de CI/CD (integração contínua e implantação contínua) da carga de trabalho. Use o SDK do Agente de IA do Azure para criar, testar e implantar alterações de agente de seus agentes de build conectados à rede.

Prefira pipelines de agente que você possa implantar independentemente para pequenas alterações incrementais. Mas certifique-se de que os pipelines forneçam flexibilidade suficiente para implantá-los junto com o código do aplicativo quando você precisar de atualizações coordenadas. Para dar suporte a esse método, acople vagamente o código da interface do usuário do chat e seus agentes de chat para que as alterações em um componente não exijam alterações simultâneas na outra.
Teste antes da produção. Valide o comportamento do agente, os prompts e as conexões em ambientes de pré-produção. Use uma combinação de testes automatizados e manuais para capturar regressões, problemas de segurança e alterações não intencionais no comportamento do agente.

Os agentes definidos no Serviço do Foundry Agent se comportam de forma não determinística, portanto, você deve determinar como medir e manter o nível de qualidade desejado. Crie e execute um conjunto de testes que verifica as respostas ideais para perguntas e cenários realistas do usuário.
Controle e controle de agentes de versão. Atribua identificadores de versão claros a cada agente. Mantenha registros de quais versões do agente estão ativas, juntamente com suas dependências, como modelos, fontes de dados e ferramentas. Prefira implantar novas versões de agente junto com as existentes para habilitar a distribuição progressiva, a reversão e a migração controlada de usuários ou sessões.
Planeje o failback. O Azure AI Foundry não fornece suporte interno para implantações de agentes azul-verde ou canário. Se você precisar desses padrões de implantação, implemente uma camada de roteamento, como um gateway de API ou um roteador personalizado, na frente da API do agente. Essa camada de roteamento permite que você alterne o tráfego incrementalmente entre as versões do agente, monitore o impacto e execute uma substituição completa quando estiver pronto.
Remoção do agente de coordenadas. Ao remover agentes, coordene o processo com os requisitos de gerenciamento de estado e experiência do usuário do aplicativo. Manipule as sessões de chat ativas adequadamente. Dependendo dos requisitos funcionais da carga de trabalho, você pode migrar sessões, fixar usuários na versão antiga do agente ou exigir que os usuários iniciem novas sessões.

Eficiência de desempenho

A Eficiência de Desempenho refere-se à capacidade da carga de trabalho de dimensionar para atender às demandas do usuário com eficiência. Para obter mais informações, consulte Lista de verificação de revisão de design para eficiência de desempenho.

Esta seção aborda a eficiência de desempenho da Pesquisa de IA, das implantações de modelo e do Azure AI Foundry.

Eficiência de desempenho na pesquisa de IA

No Serviço do Foundry Agent, você não controla as consultas específicas enviadas aos índices porque os agentes não têm código. Para otimizar o desempenho, concentre-se no que você pode controlar no índice. Observe como seu agente normalmente consulta o índice e aplica diretrizes para analisar e otimizar o desempenho na Pesquisa de IA.

Se o ajuste do servidor de índice sozinho não resolver todos os gargalos, considere as seguintes opções:

Substitua a conexão direta com a Pesquisa de IA por uma conexão com uma API que você possui. Essa API pode implementar o código otimizado para os padrões de recuperação do agente.
Reprojete a camada de orquestração para usar a alternativa auto-hospedada para que você possa definir e otimizar consultas em seu próprio código de orquestrador.

Eficiência de desempenho em implantações de modelo

Determine se seu aplicativo precisa de taxa de transferência provisionada ou se pode usar o modelo compartilhado (consumo). A taxa de transferência provisionada fornece capacidade reservada e latência previsível, o que é importante para cargas de trabalho de produção que têm objetivos estritos de nível de serviço. O modelo de consumo fornece um serviço de melhor esforço e pode sofrer efeitos barulhentos de vizinhos.
Monitore o uso gerenciado por provisionamento para evitar o excesso de provisionamento ou subprovisionamento.
Escolha um modelo de conversa que atenda aos requisitos de latência de inferência.
Implante modelos na mesma região de dados que seus agentes para minimizar a latência de rede.

Desempenho do agente de IA do Azure

Os agentes de IA do Azure são executados em um back-end de computação sem servidor que não dá suporte ao ajuste de desempenho personalizado. No entanto, você ainda pode melhorar o desempenho por meio do design do agente:

Minimize o número de repositórios de conhecimento e ferramentas conectadas ao seu agente de chat. Cada conexão extra potencialmente aumenta o runtime total de uma chamada de agente porque o agente pode invocar todos os recursos configurados para cada solicitação.
Use o Azure Monitor e o Application Insights para acompanhar os tempos de invocação do agente, as latências da ferramenta e do repositório de conhecimento e as taxas de erro. Examine regularmente essa telemetria para identificar o conhecimento lento ou as conexões de ferramentas.
Solicitações do sistema de design que orientam o agente a usar conexões com eficiência. Por exemplo, instrua o agente a consultar repositórios de conhecimento externos somente quando necessário ou para evitar invocações de ferramenta redundantes.
Monitore os limites de serviço ou as cotas que podem afetar o desempenho durante o pico de uso. Observe indicadores de limitação, como respostas HTTP 429 ou 503, embora a computação sem servidor seja dimensionada automaticamente.

Implantar este cenário

Para implantar e executar essa implementação de referência, siga o guia de implantação na implementação de referência de linha de base de chat do Serviço do Agente do Foundry.

Contribuidores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autores principais:

Rob Bagby | Principal Desenvolvedor de Conteúdo – Padrões e Práticas do Azure
Chad Kittel | Engenheiro de Software Principal – Padrões e Práticas do Azure

Outros colaboradores:

Raouf Aliouat | Engenheiro de Software Sênior
Freddy Ayala | Arquiteto de Soluções na Nuvem
Prabal Deb | Engenheiro de Software Principal
Ritesh Modi | Engenheiro de software líder
Ryan Pfalz | Gerente sênior de programas técnicos

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

Próxima etapa

Arquitetura de chat do Azure AI Foundry de linha de base em uma zona de destino do Azure

Uma perspectiva do Azure Well-Architected Framework sobre cargas de trabalho de IA no Azure
Azure OpenAI
Modelos do OpenAI do Azure
Filtragem de conteúdo