Compartilhar via


Design de aplicativo para cargas de trabalho de IA no Azure

Há muitas opções a serem consideradas quando você cria um aplicativo que tem funções de IA. Seus requisitos funcionais e não funcionais exclusivos, como se o caso de uso é o aprendizado de máquina tradicional, generativo, determinístico ou uma combinação de tipos de IA, ajudam a restringir as decisões de alto nível sobre seu design. Você considerará essas opções à medida que passar de áreas de design de alto nível para áreas de design de nível inferior.

Conforme discutido no artigo Introdução, criar seu próprio modelo ou usar um modelo predefinido é uma das primeiras decisões importantes a tomar. Ao usar um modelo predefinido, considere estes pontos:

  • Fontes do Catálogo. Explore repositórios como o hub de modelos do Hugging Face, o TensorFlow Hub e o catálogo de modelos do portal Azure AI Foundry para encontrar modelos pré-treinados. Essas plataformas fornecem um amplo catálogo de modelos para várias tarefas.

  • Licenciamento. Certifique-se de que os termos de licenciamento do modelo atendam às suas metas de segurança, conformidade e aplicativo, especialmente se você planeja distribuir o aplicativo ou integrá-lo a outros serviços.

  • Componentes-chave. Examine a arquitetura do modelo, os dados de treinamento, o desempenho e o licenciamento para determinar se ele está ajustado para sua tarefa ou domínio.

Para obter diretrizes sobre como escolher uma plataforma de hospedagem, consulte Considerações sobre a plataforma de hospedagem e inferência de modelos.

Este artigo descreve áreas de design comuns e fatores a serem considerados quando você toma decisões sobre tecnologia e abordagem.

Recomendações

A tabela a seguir resume as recomendações fornecidas neste artigo.

Recomendação Descrição
Priorize soluções prontas. Sempre que possível, use soluções de PaaS (plataforma como serviço) para lidar com funções de carga de trabalho. Utilize modelos pré-construídos e pré-treinados sempre que possível para minimizar a carga operacional e de desenvolvimento para suas equipes de tarefas e operações.
Funções e capacidades abstratas longe do cliente. Mantenha o cliente o mais enxuto possível projetando serviços de back-end para lidar com preocupações transversais, como limitação de taxa e operações de failover.
Bloqueie o acesso aos armazenamentos de dados. O código no sistema de IA não deve acessar diretamente seus armazenamentos de dados. Encaminhe todas as solicitações de dados por meio de uma camada de API. As APIs devem ser criadas especificamente para a tarefa necessária.
Isole seus modelos. Assim como acontece com os armazenamentos de dados, use uma camada de API para atuar como um gateway para solicitações para o modelo. Algumas soluções de PaaS, como o Azure OpenAI Service e o Azure Machine Learning, usam SDKs para essa finalidade. Muitas ferramentas, como o prompt flow, contêm suporte nativo para integrar APIs ao serviço.
Projete componentes para serem implantados de forma independente. Modelos de IA, pipelines de dados, componentes front-end e microsserviços como pré-processamento de dados, extração de recursos e inferência devem ser implantados de forma independente para otimizar a flexibilidade, a escalabilidade e a operabilidade da carga de trabalho.

Contenerizar componentes

Para garantir que seus componentes implantáveis de forma independente sejam totalmente independentes e para simplificar suas implantações, considere a conteinerização como parte de sua estratégia de design. Os seguintes componentes devem ser conteinerizados:

  • Microsserviços. Microsserviços individuais que lidam com funções específicas do aplicativo, como processamento de dados, inferência de modelo e autenticação de usuário, devem ser conteinerizados. Essa abordagem permite implantação e dimensionamento independentes e facilita atualizações e manutenção mais eficientes.

  • Modelos de IA. Conteinerize modelos de IA para garantir que todas as dependências, bibliotecas e configurações sejam agrupadas. Essa abordagem isola o ambiente de modelo do sistema host para evitar conflitos de versão e ajudar a garantir um comportamento consistente em diferentes ambientes de implantação.

  • Pipelines de processamento de dados. Todas as tarefas de processamento de dados que precedem ou seguem a inferência do modelo, como limpeza de dados, transformação e extração de recursos, devem ser conteinerizadas. Essa abordagem aumenta a reprodutibilidade e simplifica o gerenciamento de dependências.

  • Serviços de infraestrutura. Os serviços que fornecem suporte à infraestrutura, como bancos de dados e camadas de cache, também podem se beneficiar da contêinerização. Containerizar esses serviços ajuda a manter a consistência de versões e facilita o dimensionamento e o gerenciamento desses componentes.

Colocar componentes de IA com outros componentes de carga de trabalho

Há vários bons motivos para colocar seus componentes de IA junto com outros componentes de tarefas, mas há desvantagens associadas a isso. Você pode optar por colocar componentes por estes motivos:

  • Sensibilidade de latência. Coloque componentes de IA com outros serviços, como hospedagem de API, quando a baixa latência for importante. Por exemplo, se você precisar de inferência em tempo real para aprimorar a experiência do usuário, colocar modelos de IA próximos à API poderá minimizar o tempo necessário para recuperar resultados.

  • Proximidade de dados. Quando os modelos de IA exigem acesso frequente a conjuntos de dados específicos, como um índice de pesquisa, a colocação desses componentes pode melhorar o desempenho e reduzir a sobrecarga de transferência de dados para acelerar o processamento e a inferência.

  • Utilização de recursos. Se componentes específicos tiverem necessidades de recursos complementares, como CPU e memória, a colocação deles poderá otimizar o uso de recursos. Por exemplo, um modelo que requer computação significativa pode compartilhar recursos com um serviço que tem demandas mais baixas ao mesmo tempo.

Desvantagens. Há desvantagens a serem consideradas quando você decide se deseja colocar componentes. Você pode perder a capacidade de implantar ou dimensionar componentes de forma independente. Você também pode aumentar o risco de mau funcionamento aumentando o raio potencial de explosão de incidentes.

Avalie o uso de orquestradores em soluções de IA generativa

Um orquestrador gerencia um fluxo de trabalho coordenando a comunicação entre os diferentes componentes da solução de IA que, de outra forma, seria difícil de gerenciar em cargas de trabalho complexas. Recomendamos que você crie um orquestrador em seu design se sua carga de trabalho tiver qualquer uma das seguintes características:

  • Fluxos de Trabalho Complexos. O fluxo de trabalho envolve várias etapas, como pré-processamento, encadeamento de modelos ou pós-processamento.

  • Lógica condicional Decisões, como roteamento de resultados para modelos diferentes, precisam ser tomadas dinamicamente com base em saídas de modelo.

  • Dimensionamento e gerenciamento de recursos. Você precisa gerenciar a alocação de recursos para aplicativos de alto volume usando o dimensionamento de modelos com base na demanda.

  • Gerenciamento de estado. Você precisa gerenciar o estado e a memória das interações do usuário.

  • Recuperação de dados. Você precisa ser capaz de recuperar dados de aumento do índice.

Considerações sobre o uso de vários modelos

Quando sua carga de trabalho usa vários modelos, um orquestrador é essencial. O orquestrador roteia dados e solicitações para o modelo apropriado com base no caso de uso. Planeje o fluxo de dados entre modelos, garantindo que as saídas de um modelo possam servir como entradas para outro. O planejamento pode envolver processos de transformação ou enriquecimento de dados.

Orquestração e agentes

Para cargas de trabalho de IA generativa, considere adotar uma abordagem baseada em agente, às vezes chamada de agentic, em seu design para adicionar extensibilidade à sua orquestração. Os agentes fornecem funcionalidade associada ao contexto. Eles compartilham muitas características com microsserviços e executam tarefas em conjunto com um orquestrador. O orquestrador pode anunciar tarefas para um pool de agentes ou os agentes podem registrar recursos com o orquestrador. Ambas as abordagens permitem que o orquestrador determine dinamicamente como dividir e direcionar a consulta entre os agentes.

As abordagens de agentic são ideais quando você tem uma plataforma de interface do usuário comum com vários recursos em evolução que podem ser implementados na experiência para adicionar mais habilidades e fundamentar dados no fluxo ao longo do tempo.

Para cargas de trabalho complexas que têm muitos agentes, é mais eficiente permitir que os agentes colaborem dinamicamente em vez de usar um orquestrador para interromper tarefas e atribuí-las.

A comunicação entre o orquestrador e os agentes deve seguir um padrão de fila de tópicos, em que os agentes são assinantes de um tópico e o orquestrador envia tarefas por meio de uma fila.

O uso de uma abordagem agêntica funciona melhor com um padrão de orquestração do que com um padrão de coreografia.

Para obter mais informações, consulte Considerações sobre a plataforma de orquestração.

Avaliar o uso de gateways de API

Gateways de API como Gerenciamento de API do Azure separam funções das APIs, o que desacopla as dependências entre o serviço solicitante e a API. Os gateways de API fornecem os seguintes benefícios para cargas de trabalho de IA:

  • Múltiplos microsserviços. Os gateways ajudam você a gerenciar múltiplos pontos de extremidade de modelos de IA quando você precisa impor políticas consistentes, como limitação de taxa de requisições e autenticação.

  • Gerenciamento de tráfego. Os gateways ajudam você a gerenciar aplicativos de alto tráfego com eficiência gerenciando solicitações, armazenando respostas em cache e distribuindo cargas.

  • segurança. Os gateways fornecem controle de acesso centralizado, registro em log e proteção contra ameaças para as APIs por trás do gateway.

Usar padrões de design de aplicativo de IA

Vários padrões de design comuns foram estabelecidos no setor para aplicativos de IA. Você pode usá-los para simplificar o design e a implementação. Esses padrões de design incluem:

  • Combinação de modelos. Esse padrão de design envolve a combinação de previsões de vários modelos para melhorar a precisão e a robustez, mitigando as fraquezas de modelos individuais.

  • Arquitetura de microsserviços. A separação de componentes em serviços implantáveis independentemente melhora a escalabilidade e a manutenção. Ele permite que as equipes trabalhem em diferentes partes do aplicativo simultaneamente.

  • Arquitetura orientada a eventos. O uso de eventos para disparar ações permite componentes desacoplados e processamento em tempo real para tornar o sistema mais responsivo e adaptável à alteração de dados.

Padrão RAG e estratégias de agrupamento

O padrão de geração de Retrieval-Augmented (RAG) combina modelos generativos com sistemas de recuperação, o que permite que o modelo acesse fontes de conhecimento externas para melhorar o contexto e a precisão. Veja a série de artigos Projetar e desenvolver uma solução RAG para obter orientações detalhadas sobre esse padrão. Existem duas abordagens RAG:

  • Just-in-time. Essa abordagem recupera informações relevantes dinamicamente no momento de uma solicitação para garantir que os dados mais recentes sejam sempre usados. É benéfico em cenários que exigem contexto em tempo real, mas pode introduzir latência.

  • Pré-calculado (armazenado em cache). Esse método envolve o armazenamento em cache dos resultados de recuperação para reduzir os tempos de resposta ao servir dados pré-computados. É adequado para cenários de alta demanda em que dados consistentes podem ser armazenados. Os dados podem não refletir as informações mais atuais, o que pode levar a problemas de relevância.

Quando você usa um padrão RAG, uma estratégia de agrupamento bem definida é essencial para otimizar a eficiência de desempenho da carga de trabalho. Comece com as diretrizes de fornecidas no design para desenvolver uma solução RAG da série. Aqui estão algumas recomendações adicionais a serem consideradas:

  • Implemente uma estratégia de agrupamento dinâmico que ajuste o tamanho dos blocos com base no tipo de dados, na complexidade da consulta e nos requisitos do usuário. Isso pode melhorar a eficiência de recuperação e a preservação do contexto.

  • Incorpore loops de feedback para refinar estratégias de agrupamento com base em dados de desempenho.

  • Preserve a linhagem de dados para blocos mantendo metadados e identificadores exclusivos que vinculam de volta à fonte de aterramento A documentação de linhagem clara ajuda a garantir que os usuários entendam a origem dos dados, suas transformações e como ela contribui para a saída.

Quando usar padrões de design

Considere usar esses padrões de design quando seu caso de uso atender à condição descrita:

  • Fluxos de trabalho complexos. Quando você tem fluxos de trabalho complexos ou interações entre vários modelos de IA, padrões como RAG ou microsserviços podem ajudar a gerenciar a complexidade e garantir uma comunicação clara entre componentes.

  • Requisitos de escalabilidade. Se a demanda em seu aplicativo flutuar, um padrão como microsserviços permite que componentes individuais sejam dimensionados independentemente para acomodar cargas variadas sem afetar o desempenho geral do sistema.

  • aplicativos controlados por dados. Se o aplicativo exigir um tratamento extensivo de dados, uma arquitetura controlada por eventos poderá fornecer capacidade de resposta em tempo real e processamento eficiente de dados.

Observação

Aplicativos menores ou POCs normalmente não se beneficiam desses padrões de design. Esses aplicativos devem ser projetados para simplificar. Da mesma forma, se você tiver restrições de recursos (orçamento, tempo ou efetivo), usar um projeto simples que possa ser refatorado posteriormente é uma abordagem melhor do que adotar um padrão de projeto complexo.

Escolha as estruturas e bibliotecas certas

A escolha de estruturas e bibliotecas está intimamente entrelaçada com o design do aplicativo. Elas afetam o desempenho, a escalabilidade e a manutenção. No entanto, os requisitos de design podem limitar suas opções de estrutura. Por exemplo, o uso do SDK de Kernel Semântico geralmente incentiva um design baseado em microsserviços em que cada agente ou função é encapsulada em seu próprio serviço. Considere esses fatores ao escolher estruturas e bibliotecas:

  • Requisitos do aplicativo. Os requisitos do aplicativo, como processamento em tempo real ou processamento em lote, podem limitar a escolha da estrutura. Por exemplo, se o aplicativo exigir baixa latência, talvez seja necessário usar uma estrutura que tenha funcionalidades assíncronas.

  • Necessidades de integração. O design pode exigir integrações específicas com outros sistemas ou serviços. Se uma estrutura não der suporte aos protocolos ou formatos de dados necessários, talvez seja necessário reconsiderar o design ou escolher uma estrutura diferente.

  • Experiência da equipe. O conjunto de habilidades da equipe de desenvolvimento pode limitar as opções de estrutura. Um design que depende de uma estrutura menos familiar pode levar a um aumento do tempo de desenvolvimento e da complexidade, portanto, talvez você queira usar uma ferramenta mais familiar.

Projete uma estratégia para identidades, autorização e acesso

De um modo geral, você deve abordar a identidade, a autorização e o acesso da mesma maneira que faria ao projetar aplicativos normalmente. Você deve usar um provedor de identidade, como o Microsoft Entra ID, para gerenciar essas áreas o máximo possível. No entanto, muitos aplicativos de IA têm desafios exclusivos que exigem uma consideração especial. Às vezes, é desafiador ou até mesmo impossível persistir as ACLs (listas de controle de acesso) por meio do sistema sem novo desenvolvimento.

Consulte Guia para criar uma solução de inferência RAG multilocatário segura para saber como adicionar metadados de corte de segurança a documentos e partes. Esse corte pode ser baseado em grupos de segurança ou construções organizacionais semelhantes.

Considere os requisitos não funcionais

Sua carga de trabalho pode ter requisitos não funcionais que representam desafios devido a fatores inerentes às tecnologias de IA. A seguir estão alguns requisitos não funcionais comuns e seus desafios:

  • Latência de inferência de modelo / tempos limite. Os aplicativos de IA geralmente exigem respostas em tempo real ou quase em tempo real. Projetar para baixa latência é crucial. Ele envolve otimizar a arquitetura do modelo, os pipelines de processamento de dados e os recursos de hardware. A implementação de estratégias de cache e a garantia de carregamento eficiente do modelo também são essenciais para evitar tempos limite e fornecer respostas oportunas.

  • Limitações de taxa de transferência de token ou solicitações. Muitos serviços de IA impõem limites ao número de tokens ou à taxa de transferência de solicitações, especialmente com modelos baseados em nuvem. Projetar para essas limitações requer gerenciamento cuidadoso dos tamanhos de entradas, organização de solicitações em lotes quando necessário e potencialmente a implementação de mecanismos de controle de taxa ou enfileiramento para gerenciar as expectativas do usuário e evitar interrupções de serviço.

  • Cenários de custo e de estorno. Projetar para transparência de custos envolve implementar recursos de rastreamento e relatórios de uso que facilitam modelos de estorno. Esses recursos permitem que as organizações aloquem os custos com precisão entre departamentos. O gerenciamento de estorno normalmente é tratado por um gateway de API, como Gerenciamento de API do Azure.

Próxima etapa