Design de aplicativo para cargas de trabalho de IA no Azure
Há muitas opções a considerar 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 é aprendizado de máquina tradicional, generativo, determinístico ou uma combinação de tipos de IA, ajudam você a restringir 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
Fontes de catálogo. Explore repositórios como o Hugging Face Model Hub, o TensorFlow Hub e o catálogo de modelos do portal Azure AI Foundry para encontrar modelos pré-treinados. Estas plataformas fornecem um extenso catálogo de modelos para várias tarefas.
Licenciamento. Verifique se os termos de licenciamento do modelo se ajustam à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. Observe a arquitetura, os dados de treinamento, o desempenho e o licenciamento do modelo para determinar se ele está ajustado para sua tarefa ou domínio.
Para obter orientação sobre como escolher uma plataforma de hospedagem, consulte Considerações para a plataforma de hospedagem e inferência de modelo.
Este artigo descreve áreas de design comuns e fatores a serem considerados ao tomar decisões sobre tecnologia e abordagem.
Recomendações
A tabela a seguir resume as recomendações fornecidas neste artigo.
| Recomendação | Description |
|---|---|
| Priorize soluções prontas para uso. | Sempre que possível, use soluções de plataforma como serviço (PaaS) para lidar com funções de carga de trabalho. Use modelos pré-construídos e pré-treinados sempre que possível para minimizar a carga operacional e de desenvolvimento para sua carga de trabalho e equipes de operações. |
| Funções abstratas e capacidades longe do cliente. | Mantenha o cliente o mais fino 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 os seus modelos. | Assim como acontece com os armazenamentos de dados, use uma camada de API para atuar como um gateway para solicitações ao modelo. Algumas soluções de PaaS, como o Azure OpenAI Service e o Azure Machine Learning, usam SDKs para essa finalidade. Muitas ferramentas, como fluxo de prompt, contêm suporte nativo para propagar APIs para o serviço. |
| Projete componentes para que possam ser 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 de sua carga de trabalho. |
Contentorizar 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 contentorizados:
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 a implantação e o dimensionamento independentes e facilita atualizações e manutenções 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 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. Serviços que fornecem suporte à infraestrutura, como bancos de dados e camadas de cache, também podem se beneficiar da conteinerização. A conteinerização desses serviços ajuda a manter a consistência da versão e facilita o dimensionamento e o gerenciamento mais fáceis desses componentes.
Colocalizar componentes de IA com outros componentes de carga de trabalho
Há várias boas razões para colocalizar os seus componentes de IA com outros componentes de carga de trabalho, mas há concessões associadas ao fazê-lo. Você pode optar por colocalizar componentes pelos seguintes motivos:
Sensibilidade à latência. Coloque componentes de IA com outros serviços, como hospedagem de API, quando a baixa latência é importante. Por exemplo, se você precisar de inferência em tempo real para melhorar a experiência do usuário, colocar modelos de IA perto da API pode 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, colocar esses 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, colocá-los pode otimizar o uso de recursos. Por exemplo, um modelo que requer computação significativa pode compartilhar recursos com um serviço que tem demandas menores ao mesmo tempo.
Compensação. Há compensações a considerar quando você decide se deseja colocalizar componentes. Você pode perder a capacidade de implantar ou dimensionar componentes de forma independente. Você também pode aumentar o risco de mau funcionamento ao aumentar o potencial raio de explosão dos incidentes.
Avaliar 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, seriam difíceis de gerenciar em cargas de trabalho complexas. Recomendamos que você crie um orquestrador em seu projeto se sua carga de trabalho tiver alguma 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. As decisões, como rotear resultados para modelos diferentes, precisam ser tomadas dinamicamente com base nas saídas do modelo.
Dimensionamento e gerenciamento de recursos. Você precisa gerenciar a alocação de recursos para aplicativos de alto volume usando o dimensionamento de modelo baseado na demanda.
Gestão do 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 encaminha 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 generativas, considere adotar uma abordagem baseada em agente, às vezes chamada de agente, ao seu design para adicionar extensibilidade à sua orquestração. Os agentes fornecem funcionalidade ligada 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 grupo de agentes, ou os agentes podem registrar recursos com o orquestrador. Ambas as abordagens permitem que o orquestrador determine dinamicamente como dividir e rotear a consulta entre os agentes.
As abordagens agentic são ideais quando você tem uma superfície de interface do usuário comum que tem vários recursos em evolução que podem ser conectados à experiência para adicionar mais habilidades e dados de aterramento ao 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 dividir 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.
Usar uma abordagem agentic funciona melhor com um padrão de orquestração em vez de um padrão de coreografia.
Para obter mais informações, consulte Considerações para a plataforma de orquestração.
Avaliar o uso de gateways de API
Gateways de API como o Gerenciamento de API do Azure abstraem funcionalidades 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:
Vários microsserviços. Os gateways ajudam os utilizadores a gerir vários pontos de extremidade de modelos de Inteligência Artificial quando precisam implementar políticas consistentes, como limitação de taxa e autenticação.
Gestão do tráfego. Os gateways ajudam você a gerenciar aplicativos de alto tráfego de forma eficiente, 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 aplicativos de IA
Vários padrões de design comuns foram estabelecidos na indústria para aplicações de IA. Você pode usá-los para simplificar seu design e implementação. Esses padrões de design incluem:
Modelo de agrupamento. Este 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 de forma independente aumenta a escalabilidade e a capacidade de manutenção. Ele permite que as equipes trabalhem em diferentes partes do aplicativo simultaneamente.
Arquitetura orientada a eventos. O uso de eventos para acionar ações permite componentes dissociados e processamento em tempo real para tornar o sistema mais responsivo e adaptável à mudança de dados.
Padrão RAG e estratégias de fragmentação
O padrão Retrieval-Augmented Generation (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. Consulte o Design e desenvolva uma solução RAG série de artigos 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 da recuperação para reduzir os tempos de resposta fornecendo dados pré-computados. É adequado para cenários de alta demanda onde 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 fragmentação bem definida é fundamental para otimizar a eficiência de desempenho da sua carga de trabalho. Comece com as orientações fornecidas na série Design e desenvolva uma solução RAG. Aqui estão algumas recomendações adicionais a considerar:
Implemente uma estratégia de fragmentação dinâmica que ajuste os tamanhos dos blocos com base no tipo de dados, na complexidade da consulta e nos requisitos do usuário. Isso pode melhorar a eficiência da recuperação e a preservação do contexto.
Incorpore loops de feedback para refinar estratégias de fragmentação com base em dados de desempenho.
Preserve a linhagem de dados para partes mantendo metadados e identificadores exclusivos que se vinculam à fonte de aterramento. A documentação clara da linhagem ajuda a garantir que os usuários entendam a origem dos dados, suas transformações e como eles contribuem para a saída.
Quando usar padrões de design
Considere o uso desses 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 os componentes.
Requisitos de escalabilidade. Se a demanda em seu aplicativo flutuar, um padrão como microsserviços permitirá que componentes individuais sejam dimensionados independentemente para acomodar cargas variáveis sem afetar o desempenho geral do sistema.
Aplicações orientadas por dados. Se o seu aplicativo exigir um extenso tratamento de dados, uma arquitetura orientada a eventos pode fornecer capacidade de resposta em tempo real e processamento de dados eficiente.
Nota
Aplicativos menores ou POCs normalmente não se beneficiam desses padrões de design. Estas aplicações devem ser concebidas para a simplicidade. Da mesma forma, se você tiver restrições de recursos (orçamento, tempo ou número de funcionários), usar um design simples que possa ser refatorado posteriormente é uma abordagem melhor do que adotar um padrão de design complexo.
Escolha as estruturas e bibliotecas certas
A escolha de estruturas e bibliotecas está intimamente interligada com o design de aplicativos. Eles afetam o desempenho, a escalabilidade e a capacidade de manutenção. No entanto, os requisitos de design podem limitar suas escolhas de estrutura. Por exemplo, o uso do SDK do Kernel Semântico geralmente incentiva um design baseado em microsserviços onde cada agente ou função é encapsulado dentro de seu próprio serviço. Considere estes fatores ao escolher estruturas e bibliotecas:
Requisitos de aplicação. 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 recursos assíncronos.
A integração precisa. O projeto pode exigir integrações específicas com outros sistemas ou serviços. Se uma estrutura não suportar os 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 escolhas da estrutura. Um design que depende de uma estrutura menos familiar pode levar a um aumento do tempo de desenvolvimento e da complexidade, portanto, você pode querer usar uma ferramenta mais familiar.
Projetar 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 quando normalmente projeta aplicativos. Você deve usar um provedor de identidade, como o Microsoft Entra ID, para gerenciar essas áreas tanto quanto possível. No entanto, muitas aplicações de IA têm desafios únicos que requerem uma consideração especial. Às vezes, é desafiador ou mesmo impossível persistir listas de controle de acesso (ACLs) através do sistema sem um novo desenvolvimento.
Consulte Guia para projetar uma solução segura de inferência RAG multilocatário para saber como adicionar metadados de filtragem de segurança a documentos e partes. Essa filtragem pode ser baseada em grupos de segurança ou construções organizacionais semelhantes.
Considerar 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 da inferência do modelo / tempos limite. As aplicações de IA geralmente exigem respostas em tempo real ou quase em tempo real. Projetar para baixa latência é crucial. Isso envolve a otimização da arquitetura do modelo, pipelines de processamento de dados e 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 na taxa de transferência de tokens ou solicitações. Muitos serviços de IA impõem limites ao número de tokens ou à taxa de transferência de solicitações, particularmente com modelos baseados em nuvem. Projetar para essas limitações requer gerenciamento cuidadoso de tamanhos de entrada, loteamento de solicitações quando necessário e, potencialmente, implementação de mecanismos de limitação de taxa ou filas para gerenciar as expectativas dos usuários e evitar interrupções de serviço.
Cenários de custo e estorno. Projetar para transparência de custos envolve a implementação de recursos de rastreamento e relatório de uso que facilitam modelos de chargeback. Esses recursos permitem que as organizações aloquem custos com precisão entre os departamentos. O gerenciamento de estorno normalmente é tratado por um gateway de API, como de Gerenciamento de API do Azure.