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

Azure OpenAI Service

Serviços de IA do Azure

Serviço de Aplicações do Azure

Azure Monitor

Os aplicativos de bate-papo corporativos podem capacitar os funcionários por meio de interações conversacionais com agentes de IA. Essa capacidade é cada vez mais poderosa graças aos avanços contínuos em modelos de linguagem, como os modelos GPT da OpenAI e SDKs de orquestração como o Semantic Kernel. Esses aplicativos de bate-papo geralmente consistem nos seguintes componentes:

Uma interface de usuário (UI) de bate-papo integrada a um aplicativo corporativo maior. Ele fornece aos usuários uma experiência de conversação ao lado de outras funções de negócios.
Repositórios de dados que contêm informações específicas do domínio que são pertinentes às consultas do usuário.
Modelos de linguagem que raciocinam sobre 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 Fundição. Essa arquitetura usa um único agente hospedado no Azure AI Foundry Agent Service. O agente recebe mensagens do usuário e, em seguida, consulta armazenamentos de dados para recuperar informações de aterramento para o modelo de linguagem.

A interface do usuário do chat segue as diretrizes básicas do aplicativo Web do Serviço de Aplicativo do Azure 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 e aos agentes do Azure AI Foundry está desabilitado.

Importante

Este artigo não descreve componentes ou decisões de arquitetura da arquitetura de aplicativo Web do Serviço de Aplicativo de linha de base. Leia esse artigo para obter orientações arquitetônicas sobre como hospedar o aplicativo Web que contém sua interface do usuário de bate-papo.

Essa arquitetura usa a configuração do agente padrão do Foundry Agent Service para permitir segurança, conformidade e 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 componentes de aplicativo e serviços do Azure ocorre por meio de pontos de extremidade privados, o que garante que o tráfego de dados permaneça na rede virtual da sua carga de trabalho. O tráfego de saída dos agentes encaminha estritamente através do Firewall do Azure, que impõe regras de saída.

Sugestão

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

Arquitetura

Descarregue um ficheiro Visio desta arquitetura.

Fluxo de trabalho

Um usuário do aplicativo interage com uma interface do usuário de bate-papo. As solicitações são roteadas por meio do Gateway de Aplicativo do Azure. O Firewall de Aplicativo Web do Azure inspeciona essas solicitações antes de encaminhá-las para o Serviço de Aplicativo back-end.
Quando o aplicativo Web recebe uma consulta ou instrução de usuário, ele invoca o agente criado para finalidade. O aplicativo Web se comunica com o agente por meio do SDK do Azure AI Agent. O aplicativo Web chama o agente por meio de um ponto de extremidade privado e se autentica no 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 cumprir a intenção do usuário, o agente usa um modelo de linguagem configurado e ferramentas conectadas e armazenamentos 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 armazenamentos de conhecimento externos ou ferramentas, como a Wikipedia ou o Bing, atravessam o Firewall do Azure para inspeção e aplicação de políticas de saída.
O agente se conecta ao seu modelo de linguagem configurado e passa o contexto relevante.
Antes de retornar a resposta à interface do usuário, o agente persiste a solicitação, a resposta gerada e uma lista de armazenamentos de conhecimento consultados em um banco de dados de memória dedicado. Esse banco de dados mantém o histórico completo de conversas, o que permite interações sensíveis ao 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 de usuário que gerenciam várias conversas simultâneas e isoladas do 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 uma função específica em uma solução de chat empresarial de produção:

O Foundry Agent Service fornece a camada de orquestração para interações de bate-papo. Ele hospeda e gerencia agentes que executam as seguintes tarefas:
- Processar solicitações de usuários
- Coordenar chamadas para ferramentas e outros agentes
- Reforçar a segurança do conteúdo
- Integre com a identidade corporativa, a rede e a observabilidade
A configuração padrão do agente garante o isolamento da rede e fornece controle sobre o armazenamento de dados. Você fornece recursos dedicados do Azure para o estado do agente, histórico de bate-papo e armazenamento de arquivos, que o Foundry Agent Service gerencia exclusivamente. Outros componentes de 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, chamado enterprise_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 bate-papo e a configuração do agente sejam isolados, auditáveis e gerenciados de acordo com os requisitos de governança de dados. O Foundry Agent Service gerencia o banco de dados, suas coleções e seus dados.
- Uma conta dedicada do Armazenamento do Azure armazena arquivos carregados durante 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 Foundry Agent Service gerencia os contêineres e o ciclo de vida dos dados dentro desses contêineres.
- Uma instância dedicada do AI Search armazena um índice pesquisável e fragmentado 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 Foundry Agent Service gerencia o índice, o esquema e os dados e usa sua própria estratégia de fragmentação e lógica de consulta.
O Application Gateway serve como o ponto de entrada seguro e escalá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 oferece 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 Azure Web Application Firewall integra-se com o Application Gateway para proteger a interface do usuário do chat contra vulnerabilidades e ataques comuns da Web. Ele inspeciona e filtra solicitações HTTP, o 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 Application Gateway. O gerenciamento centralizado de certificados no Key Vault oferece suporte à rotação, auditoria e conformidade automatizadas com os padrões de segurança organizacionais. Essa arquitetura não requer chaves armazenadas ou outros segredos.
A Rede Virtual do Azure fornece isolamento de rede para todos os componentes. Ao colocar recursos em uma rede virtual privada, você 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 dos fluxos de entrada e saída. Essa configuração ajuda você a atender aos requisitos de segurança e conformidade.
O Azure Private Link conecta todos os serviços PaaS, como o Azure Cosmos DB, o Storage, o AI Search e o Foundry Agent Service, à 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 nome de domínio totalmente qualificado (FQDN), o que garante que apenas destinos aprovados sejam acessíveis. Essa configuração ajuda a evitar a exfiltração de dados e atende aos requisitos de segurança da rede.
O DNS do Azure fornece zonas privadas do Sistema de Nomes de Domínio (DNS) ligadas à 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 da 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 oferece suporte a fluxos de trabalho de implantação seguros e automatizados e separa artefatos de aplicativos 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 sua carga de trabalho. Considere as seguintes alternativas e compensações.

Orquestração de bate-papo

Abordagem atual: Essa arquitetura usa o Foundry Agent Service para orquestrar fluxos de bate-papo, incluindo a busca de dados de aterramento de armazenamentos de conhecimento e a invocação de modelos OpenAI do Azure. O Foundry Agent Service fornece orquestração sem código e não determinística. Ele lida com solicitações de bate-papo, 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 auto-hospedar a camada de orquestração usando estruturas como Semantic Kernel ou LangChain. Use essas estruturas para implementar fluxos de bate-papo determinísticos e orientados por código e lógica de orquestração personalizada.

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

Controle refinado e determinístico sobre a sequência de orquestração, invocação de ferramentas ou engenharia imediata
Integração com lógica de negócios personalizada ou sistemas externos que o Foundry Agent Service não suporta nativamente
Roteamento avançado de solicitações de clientes para experimentação ou práticas de implantação seguras
Uma solução de banco de dados de memória personalizada que difere da solução nativa do Foundry Agent Service

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

Componentes da camada de aplicativo

Abordagem atual: O site front-end da interface do usuário de bate-papo é hospedado no recurso Aplicativos Web do Serviço de Aplicativo, que fornece uma plataforma gerenciada e escalável para aplicativos Web. As Aplicações Web integram-se nativamente com as funcionalidades de rede e segurança do Azure.

Abordagem alternativa: Você pode usar outras plataformas de computação gerenciadas pelo Azure, como Aplicativos de Contêiner do Azure ou o Serviço Kubernetes do Azure (AKS), 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 suporta melhor certos casos de uso, e colocar 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 preferida por sua simplicidade na hospedagem de aplicativos Web e suas APIs.

Armazenamento de dados de aterramento (conhecimento)

Abordagem atual: Essa arquitetura usa o AI Search como o principal armazenamento de dados para fundamentar o conhecimento. Ele usa recursos de pesquisa vetorial e classificação semântica da AI Search.

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 de seu conjunto de dados existente, requisitos de atualização de dados e 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 base em um banco de dados transacional ou operacional existente
Você precisa de suporte a vários modelos ou SDK não disponível na Pesquisa de IA
Você precisa integrar com fontes de dados especializadas ou sistemas legados

A pesquisa vetorial é 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 pesquisa vetorial. Antes de escolher um armazenamento de dados, avalie os padrões de acesso a dados, a latência e as necessidades de escalabilidade da sua carga de trabalho.

Agente predefinido ou agente criado dinamicamente

Abordagem atual: A implementação de referência usa um agente definido estaticamente que é implantado como um microsserviço no Azure AI Foundry. A lógica e as fontes de dados do agente 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 controlados por meio de processos de DevOps.

Abordagem alternativa: Você pode criar ou modificar agentes dinamicamente em tempo de execução usando o SDK do Azure AI Agent. Essa abordagem permite que o aplicativo instancie agentes sob demanda, ajuste 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 efêmero a agentes específicos 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. Certifique-se de ter controles apropriados para criação, modificação e limpeza de agentes.

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

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que você pode usar para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte 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 sua carga de trabalho.

Fiabilidade

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

A arquitetura de aplicativo Web do Serviço de Aplicativo 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 que fornecem redundância quando você implanta duas ou mais instâncias nelas. Se uma zona sofrer tempo de inatividade, outras na região podem permanecer inalteradas. A arquitetura também distribui instâncias e configurações dos serviços do Azure entre zonas de disponibilidade. Para obter mais informações, consulte Baseline highly available zone-redundant application.

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

Redundância de zona na camada de orquestração

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

Nessa arquitetura, o Azure AI Foundry hospeda o recurso Foundry Agent Service. A confiabilidade do agente depende da disponibilidade das dependências do Foundry Agent Service, que são o Azure Cosmos DB, o Armazenamento e a Pesquisa de IA. O Foundry Agent Service gerencia os dados dentro desses serviços, mas você configura sua confiabilidade 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 síncrona de dados em várias zonas, o que reduz o risco de perda de dados ou tempo de inatividade devido a uma falha de zona única.

Considere também a distribuição global para mitigar interrupções regionais no Azure Cosmos DB.
Use o armazenamento com redundância de zona (ZRS) para sua conta de armazenamento. Para maior resiliência, use o armazenamento com redundância de zona geográfica (GZRS), que combina redundância zonal e regional.
Configure sua instância do AI Search 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 armazenamentos de conhecimento externos, certifique-se de que essas dependências atendam aos seus requisitos de disponibilidade e redundância. Qualquer dependência de zona única ou não redundante pode minar a confiabilidade geral da camada de orquestração.

O portal AI Foundry, suas APIs de plano de dados e o recurso Foundry Agent Service não fornecem controles diretos para redundância de zona.

Fiabilidade no alojamento do modelo Azure AI Foundry

O Azure AI Foundry fornece modelos como hospedagem de serviço (MaaS) com várias opções de implantação. Essas opções oferecem suporte principalmente ao gerenciamento de cotas e taxa de transferência, em vez da alta disponibilidade tradicional dentro de uma região. As implantações de modelo padrão operam em uma única região e não oferecem suporte a zonas de disponibilidade. Para obter disponibilidade de vários datacenters, você deve usar uma implantação de modelo global ou 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 o spillover para lidar com 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 rigorosos, use implantações globais para máxima resiliência.

O Azure AI Foundry não oferece suporte a mecanismos avançados de balanceamento de carga ou failover, como roteamento round-robin ou circuit breaking, para implantações de modelo. Se você precisar de redundância granular e controle de failover dentro de uma região, hospede sua lógica de acesso ao 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 roteamento personalizado, verificações de integridade e estratégias de failover. Mas também aumenta a complexidade operacional e transfere a responsabilidade pela confiabilidade desse componente para sua equipe.

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

Confiabilidade na busca de IA para conhecimento empresarial

Implante a Pesquisa de IA usando o nível de preço padrão ou superior em uma região que ofereça suporte a zonas de disponibilidade. Configure pelo menos três réplicas para garantir que o serviço distribua instâncias em zonas de disponibilidade separadas. Essa configuração fornece resiliência a falhas no nível da zona e suporta 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 integrados. Rastreie a latência, a limitação e o uso de recursos da consulta.
Use métricas e logs de monitoramento e análise de desempenho para determinar o número apropriado de réplicas. Essa abordagem ajuda a evitar a limitação de alto volume de consultas, partições insuficientes ou limitações de índice.
Garanta a confiabilidade da indexação, evitando interrupções de indexação periódica ou erros de indexação. Considere a indexação em um índice offline e a troca do índice ativo para o índice reconstruído depois de validar a integridade dos dados.

Fiabilidade na 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 grande 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 (Source Network Address Translation) entre vários prefixos de endereços IP, o que reduz o risco de esgotamento da porta SNAT. A exaustão do SNAT pode causar perda intermitente ou total da conectividade de saída para agentes e outros componentes da 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, revise as métricas e os logs do firewall para identificar e resolver o esgotamento do SNAT ou outros gargalos.

Isolar dependências do Foundry Agent Service 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 Foundry Agent Service de outros componentes de carga de trabalho que usam os mesmos serviços do Azure. Especificamente, não compartilhe recursos do AI Search, do Azure Cosmos DB ou do 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.

Esta separação proporciona dois benefícios fundamentais:

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

Por exemplo, se seu 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 reutilizar a conta ou o banco de dados gerenciado pelo Foundry Agent Service. Mesmo que o custo ou a simplicidade operacional motivem o compartilhamento de recursos, o risco de um evento de confiabilidade afetar recursos de carga de trabalho não relacionados supera a economia potencial na maioria dos cenários corporativos.

Importante

Se você colocalizar 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, criados pelo Foundry Agent Service. Esses detalhes internos da implementação 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 Foundry Agent Service para manipulação de dados e trate os dados subjacentes como opacos e somente monitor.

Conceção multirregional

Essa arquitetura usa zonas de disponibilidade para alta disponibilidade em uma única região do Azure. Não é uma solução multirregional. Faltam os seguintes elementos críticos necessários para a resiliência regional e a recuperação de desastres (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 (Recovery Time Objetives, objetivos de tempo de recuperação) e RPOs (Recovery Point Objetives, 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 APIs de plano de dados

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

Dados de aterramento (armazenamentos de conhecimento)
Hospedagem de modelo e pontos de extremidade de inferência
A camada de orquestração ou agente
Tráfego da 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 em todas as regiões.

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

Recuperação após desastre

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

Para o Foundry Agent Service, certifique-se de que você possa recuperar todas as dependências para um point-in-time consistente. Essa abordagem ajuda a manter a integridade transacional nas 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 restauração point-in-time (PITR) com um RPO de sete dias, que inclui definições de agente e threads de bate-papo. Teste seu 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 AI: O AI Search não possui recursos de restauração integrados e não suporta manipulação direta de índice. Se ocorrer perda ou corrupção de dados, você deve entrar em contato com o suporte da Microsoft para obter assistência com a restauração do índice. Essa limitação pode afetar significativamente seu RTO. Se sua interface do usuário de bate-papo não suportar uploads de arquivos e você não tiver agentes que usam arquivos estáticos como conhecimento, talvez não precise de um plano de DR para a Pesquisa de IA.

Mantenha uma fonte de verdade separada e regularmente atualizada para o conhecimento de base da sua empresa. Essa prática garante que você possa reconstruir í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 usados pelo Foundry Agent Service. Essa configuração permite que você inicie o failover durante uma interrupção regional. Se utilizar apenas armazenamento com redundância de zona, contacte o suporte da Microsoft para restaurar dados. Esse processo pode estender seu RTO. Assim como no AI Search, se sua interface do usuário de bate-papo não suportar uploads de arquivos e você não tiver agentes que usem arquivos estáticos como conhecimento, talvez não precise de um plano de DR para contêineres de blob.
Consistência transacional: Se o armazenamento 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 DR para manter a integridade referencial entre sua carga de trabalho e o estado do serviço do agente.
Definições e configuração do agente: Defina agentes como código. Armazene definições de agentes, conexões, prompts do sistema e parâmetros no controle do código-fonte. Essa prática permite reimplantar agentes a partir de uma configuração em boas condições se 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 seus agentes implantados permaneçam reproduzíveis.

Antes de passar 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 ao lado do perímetro de identidade da arquitetura básica. Do ponto de vista da rede, o Application Gateway é o único recurso exposto na Internet. Ele torna o aplicativo de interface do usuário de bate-papo disponível para os usuários. Do ponto de vista da identidade, a interface do usuário do chat deve autenticar e autorizar solicitações. Use identidades gerenciadas quando possível para autenticar aplicativos nos serviços do Azure.

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

Gestão de identidades e acessos

Essa arquitetura usa principalmente identidades gerenciadas atribuídas ao sistema para autenticação de serviço a serviço. Você também pode usar identidades gerenciadas atribuídas pelo usuário. Em ambos os casos, aplicar 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
- A aplicação 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 à finalidade. 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 sua função. Use grupos de ID do Microsoft Entra e controle de acesso baseado em função (RBAC) para impor a separação de tarefas. Por exemplo, distinga os desenvolvedores de agentes dos cientistas de dados que lidam com tarefas de ajuste fino. No entanto, esteja ciente das limitações e 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. Este design de portal AI Foundry pode inadvertidamente ignorar suas restrições de acesso desejadas e expor mais informações do que o pretendido.

Para reduzir o risco de acesso não autorizado, restrinja o uso do portal em ambientes de produção aos funcionários que têm uma clara necessidade operacional. Para a maioria dos funcionários, desative ou bloqueie o acesso ao portal do Azure AI Foundry em produção. Em vez disso, use pipelines de implantação automatizados e infraestrutura como código (IaC) 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 através do portal não herdam automaticamente os controlos de segurança de rede estabelecidos, tais como terminais privados ou grupos de segurança de rede (NSGs). E novos agentes nesses projetos ignoram o perímetro de segurança pretendido. Imponha a criação de projetos exclusivamente através de seus processos IaC controlados e auditáveis.

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

Para usar o Foundry Agent Service no modo Padrão, o projeto deve ter permissões administrativas nas dependências do Foundry Agent Service. 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 total a esses recursos, incluindo a capacidade de ler, gravar, modificar ou excluir dados. Para manter o acesso com privilégios mínimos, isole os recursos da carga de trabalho das dependências do Foundry Agent Service.

Todos os agentes dentro de um único projeto AI Foundry compartilham a mesma identidade gerenciada. Se sua carga de trabalho usa vários agentes que exigem acesso a diferentes conjuntos de recursos, o princípio de menor privilégio exige 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.

Ao 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. Defina o escopo de cada conexão para que apenas 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 rígidos e impede que projetos futuros herdem 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, inadvertidamente, conceder amplo acesso aos recursos, violar os princípios de privilégios mínimos e aumentar o risco de exposição não autorizada de dados. Prefira apenas conexões no nível do projeto.

Ligação em rede

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

A conceção da rede inclui as seguintes salvaguardas:

Um ponto de entrada único e seguro para todo o tráfego da interface do usuário do chat, 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, rotas definidas pelo usuário (UDRs) e regras do 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 PaaS do Azure
Segmentação lógica e isolamento de recursos de rede, com sub-redes dedicadas para cada agrupamento de componentes principais para suportar políticas de segurança granulares

Fluxos de rede

A arquitetura do aplicativo Web do Serviço de Aplicativo 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 PaaS do Azure. Esta seção se concentra nas interações do agente.

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

A interface do usuário do chat hospedado pelo 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 serviços PaaS do Azure, como dependências de serviço, armazenamentos 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.

Ingresso no 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ão acessíveis apenas por meio de endpoints privados. Como resultado, os desenvolvedores e cientistas de dados devem acessar o portal por meio de uma caixa de salto, uma rede virtual emparelhada ou uma conexão ExpressRoute ou VPN site a site.

Todas as interações programáticas com o plano de dados do agente, como do aplicativo Web ou do código de orquestração externo ao invocar a inferência do 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 dentro da conta compartilham o mesmo conjunto de pontos de extremidade. Não é possível 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). A partir dessa caixa de salto, 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) do recurso Foundry Agent Service 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 ferramentas que o agente usa. Esse design ajuda a reduzir as tentativas de exfiltração de dados dentro da lógica de orquestração.

Ao forçar esse caminho de saída, você ganha 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 privados e FQDNs externos necessários. Essa configuração garante que as solicitações do agente gerem logs DNS, que suportam 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 NSG de saída permitem o acesso apenas a sub-redes de ponto de extremidade privadas dentro da rede virtual e à porta TCP (Transmission Control Protocol) 443 para tráfego ligado à Internet. O NSG nega qualquer outro tráfego.

Para restringir ainda mais o tráfego da Internet, esta arquitetura aplica um UDR à sub-rede, que direciona todo o tráfego HTTPS através da Firewall do Azure. O firewall controla quais FQDNs o agente pode alcançar por meio de conexões HTTPS. Por exemplo, se o agente só precisar acessar o Aterramento com APIs públicas do Bing, configure o Firewall do Azure para permitir o tráfego na api.bing.microsoft.com 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 principais à 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 exige.

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
Terminais privados `snet-privateEndpoints`	Rede virtual	Não é permitido trânsito	Sim	Não é permitido trânsito
Portal de Aplicações `snet-appGateway`	Endereços IP de origem do usuário da interface do usuário do bate-papo, como a Internet pública, e fontes necessárias para o serviço	Sub-rede de ponto de extremidade privada e itens necessários para o serviço	Não	-
Serviço de Aplicações `snet-appServicePlan`	Não é permitido trânsito	Pontos de extremidade privados e Azure Monitor	Sim	Para o Azure Monitor
Serviço de Agente de Fundição `snet-agentsEgress`	Não é permitido trânsito	Pontos finais privados e a Internet	Sim	Somente FQDNs públicos que você permite que seus agentes usem
VMs de caixa de salto `snet-jumpBoxes`	Sub-rede do Azure Bastion	Pontos finais privados e a Internet	Sim	Conforme necessário para a VM
Agentes de construção `snet-buildAgents`	Sub-rede do Azure Bastion	Pontos finais privados e a Internet	Sim	Conforme necessário para a VM
Azure Bastion `AzureBastionSubnet`	Veja o acesso ao NSG e o Azure Bastion	Veja o acesso ao NSG e o Azure Bastion	Não	-
Azure Firewall `AzureFirewallSubnet` `AzureFirewallManagementSubnet`	Sem NSG	Sem NSG	Não	-

Esse design nega explicitamente todo o outro tráfego, seja por meio de regras NSG ou por padrão no Firewall do Azure.

Ao implementar segmentação de rede e segurança nessa 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 volumétricos.
Anexe um NSG a cada sub-rede que o suporte. Aplique as regras mais rigorosas possíveis sem interromper a funcionalidade necessária.
Aplique o túnel forçado a todas as sub-redes suportadas para que o firewall de saída possa inspecionar todo o tráfego de saída. Use tunelamento forçado mesmo em sub-redes onde você não espera saída. Esse método adiciona uma medida de defesa profunda que protege contra o uso indevido intencional ou acidental da sub-rede.

Governação através de políticas

Para alinhar com a linha de base de segurança da sua carga de trabalho, use a Política do Azure e as políticas de rede para garantir que todos os recursos da carga de trabalho atendam às suas necessidades. A automação da plataforma por meio de políticas reduz o risco de desvio de configuração de segurança e ajuda a reduzir as atividades de validação manual.

Considere a implementação dos seguintes tipos de políticas de segurança para fortalecer sua arquitetura:

Desative os métodos de autenticação baseados em chave ou outros métodos de autenticação local em serviços como os serviços de IA do Azure e o Cofre de Chaves.
Exigem configuração explícita de regras de acesso à rede, pontos de extremidade privados e NSGs.
Exija 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 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.

Esta estimativa de preços do Azure fornece um exemplo de preço para esta arquitetura. Este exemplo inclui apenas os componentes dessa 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 do chat e o Application Gateway. Otimize esses recursos para reduzir custos.

Serviço de Agente de Fundição

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 para esses serviços necessários:

O Foundry Agent Service gerencia a alocação de unidade de solicitação (RU) no Azure Cosmos DB. Para reduzir os custos de longo prazo, adquira capacidade reservada para o Azure Cosmos DB. Alinhe as reservas com a duração e o volume de utilização esperados. Lembre-se de que a capacidade reservada requer compromisso inicial e falta flexibilidade se os padrões de uso da sua carga de trabalho mudarem significativamente.
Se o seu cenário de chat não exigir o upload de arquivos, exclua esse recurso do seu aplicativo. Nesse caso, aplique as seguintes alterações de configuração:
- Use um nível de armazenamento com redundância local (LRS) 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 as APIs SDK ou REST. Agentes e threads obsoletos continuam a consumir armazenamento e podem aumentar os custos no Azure Cosmos DB, Armazenamento e AI Search.
Desative recursos dependentes que sua carga de trabalho não exige, como os seguintes recursos:
- O classificador semântico na Pesquisa de IA
- O gateway e os recursos de gravação de várias regiões no Azure Cosmos DB
Para evitar cobranças de largura de banda entre regiões, implante o Azure Cosmos DB, o Armazenamento e a Pesquisa de IA 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 AI Search 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 o compartilhamento de recursos somente após uma avaliação de risco completa para compromissos de confiabilidade, segurança e desempenho.

Conhecimento e ferramentas do agente

O Foundry Agent Service executa a lógica do agente de maneira não determinística. Ele pode invocar qualquer armazenamento de conhecimento, ferramenta ou outro agente conectado 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 para APIs ou fontes de dados externas, aumentar os custos de cada transação e introduzir padrões de uso imprevisíveis que complicam a previsão de orçamento.

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

Conecte apenas os armazenamentos de conhecimento, ferramentas ou agentes que provavelmente serão usados com a maioria das invocações de agentes. Evite conectar recursos que raramente são necessários ou que incorrem em altos custos para cada chamada, a menos que sejam essenciais.
Projete e refine 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 do Azure AI Foundry para monitorar quais APIs externas, armazenamentos de conhecimento ou ferramentas o agente acessa, com que frequência ele os acessa e os custos associados. Revise 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 Azure OpenAI

As 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 dos clientes 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:
- Aprove todos os consumidores do modelo. Não exponha modelos de uma forma que permita acesso irrestrito.
- Imponha restrições de limitação de token, como max_tokens e max_completions através da lógica do agente. Esse controle só está disponível em orquestração auto-hospedada. O Foundry Agent Service não suporta essa funcionalidade.
- Otimize a entrada imediata 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 forneçam 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 em orquestração auto-hospedada. O Foundry Agent Service não fornece configuração suficiente para suportar essa funcionalidade.
Escolha o modelo certo para o agente. Selecione o modelo mais barato que atenda aos requisitos do seu agente. Evite usar modelos de custo mais alto, a menos que sejam essenciais. Por exemplo, a implementação de referência usa GPT-4o em vez de um modelo mais caro e alcança resultados suficientes.
Monitore e gerencie o uso. Use o Microsoft Cost Management e a telemetria de modelo para controlar o uso de tokens, definir orçamentos e criar alertas para anomalias. Analise regularmente os padrões de uso e ajuste as cotas ou o acesso do 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 preços pré-pagos para cargas de trabalho imprevisíveis e mude para 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.
Restrinja o uso do playground. Para evitar custos de produção não planejados, restrinja o uso do playground do Azure AI Foundry apenas a ambientes de pré-produção.
Planeje o ajuste fino e a geração de imagens cuidadosamente. Estas funcionalidades têm diferentes modelos de faturação. Eles são cobrados por hora ou por lote. Programe o uso para alinhar com os intervalos de faturamento 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 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. Níveis mais altos adicionam custo, portanto, use-os apenas se precisar de seus recursos.

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

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.

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

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

Cálculo do agente

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

Em ambas as abordagens, você deve gerenciar o armazenamento de estado, como o histórico de bate-papo e a configuração do 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 espaço de trabalho do Log Analytics da sua carga de trabalho. Todos os serviços, exceto o Serviço de Aplicativo, capturam todos os logs. Na produção, talvez não seja necessário capturar todos os logs. Por exemplo, o aplicativo de interface do usuário de chat pode exigir AppServiceHTTPLogsapenas , AppServiceConsoleLogs, AppServiceAppLogs, AppServicePlatformLogs, e AppServiceAuthenticationLogs. Ajuste os fluxos de log às 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 do modelo. Nessa arquitetura, o Azure AI Foundry rastreia o uso de token por meio de sua integração com o Application Insights.

Suas caixas de salto e VMs de agente de compilação 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. Certifique-se de que essas VMs emitam logs suficientes para entender quando são usadas, quem as usa e quais ações elas executam.

Controle de versão e ciclo de vida do agente

Trate cada agente como uma unidade implantável de forma independente dentro de sua carga de trabalho de chat, a menos que você projete especificamente seu aplicativo para criar e excluir agentes dinamicamente em tempo de execução. 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, garanta 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. Esta prática garante rastreabilidade e reprodutibilidade. Evite alterações não controladas através do portal do Azure AI Foundry.
Automatize a implantação do agente. Use os pipelines de integração contínua e implantação contínua (CI/CD) da sua carga de trabalho. Use o SDK do Azure AI Agent para criar, testar e implantar alterações de agente de seus agentes de compilação conectados à rede.

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

Os agentes definidos no Foundry Agent Service 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.
Agentes de versão e rastreamento. 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 ao lado das existentes para permitir 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 azul-verde ou canárias de agentes. Se você precisar desses padrões de implantação, implemente uma camada de roteamento, como um gateway de API ou roteador personalizado, na frente da API do agente. Essa camada de roteamento permite que você mude o tráfego incrementalmente entre as versões do agente, monitore o impacto e execute uma alternância completa quando estiver pronto.
Coordenar a remoção do agente. Ao remover agentes, coordene o processo com os requisitos de gerenciamento de estado e experiência do usuário do aplicativo. Lide com sessões de chat ativas adequadamente. Dependendo dos requisitos funcionais da sua carga de trabalho, você pode migrar sessões, fixar usuários para a 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 sua carga de trabalho de escalar para atender às demandas dos usuários 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 aborda a eficiência de desempenho para AI Search, implantações de modelo e Azure AI Foundry.

Eficiência de desempenho na pesquisa de IA

No Foundry Agent Service, você não controla as consultas específicas enviadas aos seus í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 aplique orientações para analisar e otimizar o desempenho no AI Search.

Se o ajuste do servidor de indexação por si só não resolver todos os gargalos, considere as seguintes opções:

Substitua a conexão direta com o AI Search por uma conexão com uma API de sua propriedade. Essa API pode implementar código otimizado para os padrões de recuperação do seu agente.
Redesenhe 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 orchestrator.

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

Determine se seu aplicativo precisa de taxa de transferência provisionada ou 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 com objetivos estritos de nível de serviço. O modelo de consumo fornece o melhor serviço de esforço e pode sofrer efeitos de vizinhança barulhentos.
Monitore o uso gerenciado por provisionamento para evitar o provisionamento excessivo ou insuficiente.
Escolha um modelo de conversação que atenda aos seus requisitos de latência de inferência.
Implante modelos na mesma região de dados que seus agentes para minimizar a latência da 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 oferece 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 armazenamentos de conhecimento e ferramentas conectadas ao seu agente de chat. Cada conexão extra aumenta potencialmente o tempo de execução 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 controlar os tempos de invocação do agente, as latências da ferramenta e do armazenamento de conhecimento e as taxas de erro. Revise regularmente essa telemetria para identificar conexões lentas de conhecimento ou ferramentas.
Projete prompts do sistema que orientam o agente a usar conexões de forma eficiente. Por exemplo, instrua o agente a consultar armazenamentos de conhecimento externos somente quando necessário ou para evitar invocações de ferramentas redundantes.
Monitore limites de serviço ou cotas que possam afetar o desempenho durante o pico de uso. Preste atenção aos indicadores de limitação, como respostas HTTP 429 ou 503, mesmo que a computação sem servidor seja dimensionada automaticamente.

Implementar 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 do chat do Foundry Agent Service.

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Principais autores:

Rob Bagby | Desenvolvedor de Conteúdo Principal - Azure Patterns & Practices
Chad Kittel | Engenheiro Principal de Software - Azure Patterns & Practices

Outros contribuidores:

Raouf Aliouat - Brasil | Engenheiro de Software Sênior
Freddy Ayala | Arquiteto de Soluções em Nuvem
Prabal Deb | Engenheiro de Software Principal
Ritesh Modi | Engenheiro de Software Principal
Ryan Pfalz | Gestor de Programa Técnico Sénior

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Próximo passo

Linha de base Arquitetura de chat do Azure AI Foundry em uma zona de aterrissagem do Azure

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