Design de aplicativo para cargas de trabalho de IA no Azure
Há muitas opções disponíveis para você considerar ao planejar a criação de um aplicativo com funções de IA. Seus requisitos funcionais e não funcionais exclusivos ajudam a restringir decisões de alto nível sobre seu design, como se o caso de uso é aprendizado de máquina tradicional, generativo, determinístico ou uma combinação de tipos de IA. À medida que você passa de áreas de design de alto nível para áreas de design de nível inferior, há várias opções a considerar ao longo do caminho.
Conforme discutido no artigo Introdução , escolher se deseja construir seu próprio modelo ou usar um modelo pré-construído é uma das primeiras decisões importantes a serem tomadas. Ao escolher um modelo pré-construído, considere estes pontos:
Fontes de catálogo. Explore repositórios como o Hugging Face Model Hub, o TensorFlow Hub ou o catálogo de modelos do Azure AI Studio para encontrar modelos pré-treinados. Essas plataformas fornecem um extenso catálogo de modelos em 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 sobre a plataforma de hospedagem de modelo.
Este artigo explora muitas áreas de design comuns e fatores a serem considerados ao tomar decisões importantes sobre tecnologia e abordagem.
Recomendações
Aqui está o resumo das 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 tocar diretamente em 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 específica necessária. |
| Isole os seus modelos. | Como 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 o PromptFlow, 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 frontend 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: Os microsserviços individuais que lidam com funções específicas do aplicativo, como processamento de dados, inferência de modelo ou autenticação de usuário, devem ser conteinerizados. Essa abordagem permite a implantação e o dimensionamento independentes, facilitando 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, evitando conflitos de versão e garantindo um comportamento consistente em diferentes ambientes de implantação.
Pipelines de processamento de dados: quaisquer 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 ou camadas de cache, também podem se beneficiar da conteinerização. Essa abordagem 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 seus componentes de IA com outros componentes de carga de trabalho, mas há compensações em fazer isso. Os motivos pelos quais você pode colocalizar são:
Sensibilidade à latência: colocalize componentes de IA com outros serviços, como hospedagem de API, quando a baixa latência é importante. Por exemplo, se a inferência em tempo real for necessária 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 processamento e inferência mais rápidos.
Utilização de recursos: Se determinados componentes 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 com a colocação de componentes que devem ser consideradas. 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 de explosão potencial de incidentes.
Avaliar o uso de orquestradores em soluções de IA generativa
Um orquestrador gerencia o 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 precisam ser tomadas dinamicamente com base nas saídas do modelo, como o roteamento de resultados para modelos diferentes.
Dimensionamento e gerenciamento de recursos: você precisa gerenciar a alocação de recursos para aplicativos de alto volume usando o dimensionamento de modelo 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, usar um orquestrador é essencial. O orquestrador é responsável por rotear 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 referem-se à funcionalidade ligada ao contexto, compartilhando muitas características de estilo de microsserviço que 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 decida dinamicamente como dividir e rotear a consulta entre os agentes.
As abordagens de agente são ideais quando você tem uma superfície de interface do usuário comum com vários recursos em evolução que podem ser conectados a essa experiência para adicionar mais habilidades e dados de aterramento ao fluxo ao longo do tempo.
Para cargas de trabalho complexas com 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
Os gateways de API, como o Gerenciamento de API do Azure, abstraem funções longe das APIs que separam 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: eles ajudam você a gerenciar vários pontos de extremidade de modelo de IA e você precisa aplicar políticas consistentes, como limitação de taxa e autenticação.
Gerenciamento de tráfego: eles ajudam você a gerenciar aplicativos de alto tráfego de forma eficiente, gerenciando solicitações, armazenando respostas em cache e distribuindo cargas.
Segurança: Eles fornecem controle de acesso centralizado, registro em log e proteção contra ameaças para as APIs por trás do gateway.
Aproveite os padrões de design de aplicativos de IA
Existem vários padrões de design comuns que foram estabelecidos na indústria para aplicações de IA que você pode usar para simplificar seu design e implementação. Esses padrões de design incluem:
Agrupamento de modelos: Este padrão de projeto 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: separar componentes em serviços implantáveis de forma independente aumenta a escalabilidade e a capacidade de manutenção, permitindo que as equipes trabalhem em diferentes partes do aplicativo simultaneamente.
Arquitetura orientada a eventos: A utilização de eventos para acionar ações permite componentes dissociados e processamento em tempo real, tornando 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, permitindo que o modelo acesse fontes de conhecimento externas para melhorar o contexto e a precisão. Consulte a série Projetando e desenvolvendo 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, garantindo 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): Este método envolve o armazenamento em cache dos resultados da recuperação, reduzindo os tempos de resposta ao servir dados pré-computados. É adequado para cenários de alta demanda em que dados consistentes podem ser armazenados, mas podem não refletir as informações mais atuais, levando a possíveis problemas de relevância.
Ao usar 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 Projetando e desenvolvendo uma solução RAG. Outras recomendações a considerar são:
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. Uma documentação clara de 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 a uma das condições:
Fluxos de trabalho complexos: ao lidar com 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, o uso de um padrão como microsserviços permite que componentes individuais sejam dimensionados de forma independente, acomodando cargas variáveis sem afetar o desempenho geral do sistema.
Aplicativos orientados por dados: se 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
Aplicações menores ou POCs normalmente não se beneficiarão da adoção de um desses padrões de design e devem ser construídos com um design simplista. Da mesma forma, se você tiver restrições de recursos (orçamento, tempo ou número de funcionários), usar um design simplista que pode 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, afetando não apenas a arquitetura, mas também o desempenho, a escalabilidade e a capacidade de manutenção. Por outro lado, os requisitos de design podem limitar as escolhas de estrutura, criando uma interação dinâmica entre os dois. Por exemplo, o uso do SDK do Kernel Semântico (SK) geralmente incentiva um design baseado em microsserviços em que cada agente ou funcionalidade é encapsulado em seu próprio serviço. Os fatores a considerar ao escolher estruturas e bibliotecas são:
Requisitos do aplicativo: Os requisitos específicos 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, uma estrutura com recursos assíncronos pode ser necessária.
Necessidades de integração: 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, pode ser necessário reconsiderar o design ou selecionar 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, levando a uma seleção de 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 forma que 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, existem desafios únicos para muitas aplicações de IA que precisam de consideração especial. Listas de controle de acesso (ACLs) persistentes através do sistema às vezes é desafiador ou até mesmo impossível sem introduzir novos desenvolvimentos.
Analise as orientações encontradas na solução RAG multilocatária segura 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.
Considere os requisitos não funcionais
Você pode ter requisitos não funcionais para sua carga de trabalho que são desafiadores devido a fatores inerentes às tecnologias de IA. Os requisitos não funcionais comuns e seus desafios incluem:
Latência de inferência/tempos limite de modelos: os aplicativos de IA geralmente exigem respostas em tempo real ou quase em tempo real. Projetar para baixa latência é crucial, o que 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 de taxa de transferência de token ou solicitação: muitos serviços de IA impõem limites ao número de tokens ou à taxa de transferência de solicitações, particularmente ao usar modelos baseados em nuvem. O projeto para essas limitações requer um gerenciamento cuidadoso dos tamanhos de entrada, solicitações em lote quando necessário e, potencialmente, a implementação de mecanismos de limitação de taxa ou enfileiramento para gerenciar as expectativas dos usuários e evitar interrupções do 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, permitindo que as organizações aloquem custos com precisão entre departamentos. O gerenciamento de estorno normalmente é tratado por um gateway de API, como o Gerenciamento de API do Azure.