Padrão de arquitetura Azure para cargas de trabalho de IA

Este diagrama mostra os componentes-chave da carga de trabalho inteligente da aplicação a incluir no seu design.

Considerações de design

Ao desenhar a sua arquitetura inteligente de carga de trabalho de aplicação, considere as seguintes características de design para tomar decisões informadas sobre o design e as interações dos componentes.

Duração e estado

A API de Inteligência, orquestração, inferência e camadas de conhecimento são todos serviços duradouros que funcionam durante toda a vida útil da sua carga de trabalho. Invista em disponibilidade, monitorização e excelência operacional para cada serviço.

Cada camada evolui a um ritmo diferente, por isso precisas de uma coordenação deliberada de implementação. A API de Inteligência evolui lentamente para se manter estável e manter a compatibilidade retroativa. A orquestração e as camadas de agentes evoluem mais rapidamente à medida que adicionas novas capacidades. A camada de inferência é atualizada quando implementas novos modelos. A camada de conhecimento evolui continuamente à medida que os dados mudam.

Componentes sem estado podem ser alocados ou desalocados a pedido, enquanto os componentes com estado gerem dados que persistem entre interações.

As camadas da API de Inteligência, orquestração e inferência são "stateless", o que facilita a sua escalabilidade ao adicionar mais instâncias. A camada de orquestração pode manter um estado efémero durante a execução, mas não persiste para além do tratamento dos pedidos. O estado efémero reduz a complexidade operacional, mas limita as opções de recuperação de falhas, por isso projete cuidadosamente para retentativas e idempotência.

Os dados das sessões de gestão de conversas podem durar de minutos a dias. Sessões mais longas permitem conversas mais ricas, mas custam mais e aumentam o risco de privacidade. A camada de conhecimento armazena dados em índices e bases de dados que evoluem à medida que adiciona, atualiza ou remove informação.

Troca. As decisões de gestão ao longo da vida e do estado impactam diretamente o custo, a fiabilidade e o desempenho. Componentes de longa duração e com estado requerem maior investimento em escalabilidade e resiliência, enquanto componentes sem estado e efémeros são mais económicos, mas podem introduzir latência devido a arranques a frio ou recuperação externa de estado.

Alcance e dependências

A Intelligence API é o único endpoint publicamente exposto na arquitetura, tudo o resto permanece interno. Pode implementá-lo em várias regiões para manter os utilizadores próximos de um endpoint e melhorar a resiliência.

A camada de orquestração situa-se no centro, opera dentro da sua rede e coordena tudo, como o estado da conversa, chamadas de modelo, recuperação de conhecimento e invocação de ferramentas. As falhas aqui bloqueiam todo o sistema; por essa razão, deve tornar o sistema altamente disponível.

A camada de inferência corre internamente sem dependências externas. Implementa-o perto do orquestrador para manter a latência baixa.

As camadas de conhecimento e ferramentas são internas, mas podem depender de sistemas externos. Estas dependências externas podem introduzir atrasos ou problemas de disponibilidade que afetam a qualidade da resposta.

Troca. A implementação multirregional melhora o desempenho e a resiliência, mas aumenta os custos. A implementação numa única região é mais económica, mas pode resultar numa maior latência para utilizadores distantes da região.

Escalabilidade e disponibilidade

A tua aplicação inteligente tem dois padrões de escalabilidade. Camadas sem estado como a API, orquestração e inferência escalam adicionando mais instâncias. Camadas de dados, como a gestão de conversas e a gestão do conhecimento, escalam ao espalhar dados por vários repositórios através de mecanismos como réplicas de leitura, particionamento e fragmentação.

A API de Inteligência escala para gerir mais pedidos. Implemente-o em várias zonas ou regiões para melhor disponibilidade e para manter os utilizadores próximos de um endpoint.

Orquestração e computação de agentes estão no centro do teu sistema, por isso falhas aqui bloqueiam tudo. Adicione mais instâncias, use balanceamento de carga e tenha o failover pronto para que o sistema continue a correr quando as instâncias individuais falharem.

A camada de inferência escala com base no que os teus modelos precisam. Adicione mais instâncias com GPUs à medida que a procura cresce. Use infraestrutura como código (IaC) para recriar rapidamente os ambientes durante a recuperação.

A gestão de conversas escala com o número de utilizadores em simultâneo. Use cópias e backups para manter os dados das sessões disponíveis.

A camada de conhecimento escala com base na quantidade de dados que tens e com que frequência são consultados. Use indexação eficiente e ajuste de bases de dados para manter as respostas rápidas. Configure cópias em vários locais para disponibilidade.

Troca. Componentes sem estado podem escalar rapidamente, mas podem introduzir latência de arranque a frio. Os componentes de dados proporcionam durabilidade, mas requerem mais planeamento para escalabilidade. Equilibre estes fatores com base na carga esperada e nos requisitos do negócio.

Segurança e IA responsável

Cada camada na sua aplicação inteligente acarreta riscos diferentes e necessita dos seus próprios controlos. As ferramentas podem desencadear ações do mundo real, o conhecimento molda o que a sua IA sabe, e a inferência produz resultados que os utilizadores veem. Restrinja o acesso em todas as camadas, monitoriza o que está a acontecer e certifica-te de que consegues explicar como as decisões são tomadas.

A camada de ferramentas tem o maior risco porque as ações podem ter consequências reais que são potencialmente irreversíveis. Para operações de alto risco, adicione passos de aprovação humana. Use autenticação rigorosa, acesso com privilégios mínimos e aplicação da privacidade de dados para evitar ações não autorizadas e exposição a PII. Avalie todas as ferramentas antes de as integrar para que a governação ultrapasse o limite da sua carga de trabalho.

A camada de conhecimento necessita de dados de alta qualidade e imparciais para produzir resultados fiáveis. Mantenha o acesso aos dados seguro com autenticação adequada, autorização e conformidade com os requisitos de residência de dados. O acesso apenas de leitura e o isolamento de rede evitam corrupção. Registe quais as fontes que foram recolhidas para cada resposta através de registos de auditoria; este processo permite-lhe explicar decisões e investigar questões mais tarde.

A camada de inferência deve ser acessível apenas aos papéis de operações e à identidade da camada de orquestração. Monitorize as saídas através de um serviço de validação que verifica toxicidade e outros problemas de segurança. Validar modelos antes da implementação para detetar viés e manter os mecanismos de rollback prontos caso surjam problemas em produção.

Este diagrama mostra os componentes-chave do treino e da afinação da carga de trabalho a incluir no seu design.

Considerações de design

Ao desenhar a sua arquitetura de carga de trabalho de treino e ajuste fino, considere as seguintes características de design para tomar decisões informadas sobre o design e as interações dos componentes.

Duração e estado

Componentes persistentes a longo prazo permitem a análise histórica e o re-treino do modelo com base em dados passados. Armazenamento de agregação de dados, armazenamento de funcionalidades e registo de modelos são repositórios persistentes e de longo prazo que crescem com novas importações, funcionalidades e versões de modelos.

Componentes efémeros permitem eficiência de custos, mas exigem um tratamento cuidadoso de falhas e reinicializações. A plataforma de processamento de dados e a plataforma de treinamento têm uma configuração de infraestrutura de longa duração, mas os seus recursos computacionais são efêmeros, criados e escalados sob demanda para trabalhos de pipeline e treinamento.

A camada de inferência é sem estado e efémera. Implemente-o sob demanda para processamento em lote ocasional ou como um ambiente de execução prolongada para pipelines frequentes. O design sem estado permite escalabilidade horizontal e recuperação simples de falhas.

Troca. Componentes persistentes a longo prazo proporcionam durabilidade e contexto histórico, mas requerem custos contínuos de manutenção e armazenamento. Componentes efémeros e sem estado são mais económicos e escaláveis, mas requerem uma gestão robusta de falhas e podem introduzir latência em arranques a frio.

Alcance e dependências

Mantenha os seus armazenamentos, processamento, treino e inferência na mesma região para minimizar latência e custos. Só distribua quando os requisitos de residência de dados o exigirem. A maioria dos componentes é apenas interna, o que reduz a sua superfície de ataque, mas requer acesso seguro para programadores e operadores.

Pode distribuir fontes de dados por diferentes ambientes e geografias. São a tua principal dependência para importar dados necessários para treino, ajuste fino ou aterramento.

O armazenamento de agregação de dados é a principal dependência da plataforma de processamento de dados, desacoplando-a das fontes de dados.

A plataforma de processamento de dados acede ao armazenamento de funcionalidades para armazenar funcionalidades computadas, e a plataforma de treino acede-as durante o treino. O componente de inferência também pode necessitar de acesso apenas de leitura, dependendo do tipo de modelo e dos requisitos específicos.

A plataforma de treino depende do armazenamento de funcionalidades e dos dados agregados gerados a partir do processamento. Escreve modelos treinados no registo de modelos, que se torna a dependência para a inferência.

O registo de modelos é único porque necessita tanto de acesso interno (para treino para escrever modelos) como de acesso externo (para aplicações de IA implementarem modelos em ambientes de inferência). Utilize modelos de implantação push para minimizar o alcance externo de componentes sensíveis.

Escalabilidade e disponibilidade

Os seus componentes de treino precisam de crescer com os seus dados e manter-se disponíveis quando necessário. Armazenamentos de dados como Data Aggregation Store, Feature Store e Model Registry escalam através de particionamento, replicação e indexação eficiente à medida que mais dados, funcionalidades e modelos são adicionados ao longo do tempo. Mantenha estes componentes altamente disponíveis com estratégias de redundância, estratégias de cópias de segurança e estratégias de failover para que os seus dados e modelos estejam acessíveis sempre que a plataforma de treino ou de inferência os necessitar.

Plataformas computacionais como o Data Processing and Training escalam de forma diferente. Adicionam mais recursos conforme necessário à medida que os seus processos de processamento e treinamento precisem deles. Utilizar IaC para automatizar a recriação do ambiente durante a recuperação de desastres e adicionar mais recursos de computação, como nós de GPU, à medida que a procura aumenta.

A tua camada de inferência normalmente trata do processamento em lote neste contexto, por isso otimiza-a para o throughput em vez de baixa latência. Pode escalar horizontalmente com recursos computacionais menos dispendiosos, pois está a processar grandes volumes de dados sem necessidade de resposta em tempo real.

Segurança e IA responsável

Abordar a segurança e a IA responsável em todos os níveis. Use a defesa em profundidade com controlos de acesso, encriptação e auditoria. Siga o princípio do privilégio mínimo de forma consistente: o ETL obtém acesso apenas de leitura às fontes, o treinamento escreve apenas no registo do modelo, e a inferência tem acesso apenas de leitura. Mapeie os seus fluxos de dados para manter os dados regulados nas regiões obrigatórias e acompanhe quem acedeu a quê, quando e porquê.

As fontes de dados são o seu ponto de controlo mais importante para a prevenção de preconceitos. Certifique-se de que os dados importados representam todos os tipos de disciplina de forma justa. Se os dados não conseguirem sair da sua região, executa o teu pipeline ETL lá para manter a conformidade.

O armazenamento de agregação de dados e o armazenamento de características detêm informações sensíveis. Controlar quem pode aceder a quais subconjuntos de dados e seguir as regras de residência de dados durante todo o ciclo de vida. Acompanhe a linhagem de dados para cada atributo calculado. É a sua base para a explicabilidade e permite-lhe rastrear previsões do modelo até aos dados de origem.

A plataforma de processamento de dados é onde previne ativamente o viés. Restringa as ligações de saída a armazenamentos e serviços de dados aprovados. É aqui que validas a qualidade dos dados, filtras palavrões, ofuscas informações sensíveis e equilibras a distribuição dos teus dados ao reduzir grupos sobre-representados ou aumentar grupos sub-representados.

A plataforma de treino precisa de isolamento para se manter separada da produção. Regista cada treino executado usando frameworks como o MLFlow, capturando que dados foram usados, que hiperparâmetros experimentaste e quais foram os resultados. Faça verificações de viés, justiça e explicabilidade sempre que possível para detetar problemas antes da implementação.

O registo modelo é o seu portão de governação. Use princípios de serviço e publique somas de verificação para validar modelos. Anexe metadados sobre dados de treino, avaliações e linhagem a cada modelo para maior transparência. Limitar a implementação da produção através de revisões de segurança e IA responsável.

A camada de inferência deve apenas executar modelos aprovados. Mantenha-o isolado no seu ambiente analítico e monitorize todas as saídas para viés, toxicidade e outros padrões prejudiciais.