Última revisão: maio de 2026
Uma referência rápida dos padrões arquiteturais que o exame DP-100 avalia. Leia de cima a baixo ou pule para uma seção.
Necessidade de uma plataforma centralizada e colaborativa para todo o ciclo de vida do machine learning, desde a preparação de dados até a implantação e monitoramento.
Workspace do Azure Machine Learning.
Por quê: É o serviço fundamental que integra todos os componentes necessários: computação, datastores, ambientes, rastreamento de experimentos, registro de modelos e endpoints.
Exigir que todo o tráfego do workspace de ML, incluindo para recursos dependentes como Storage e ACR, permaneça na rede privada do Azure e não seja exposto à internet pública.
Configurar o workspace do Azure ML com uma rede virtual gerenciada e usar private endpoints para o workspace e todos os seus recursos dependentes (Storage, Key Vault, ACR).
Por quê: Private endpoints fornecem conectividade segura e privada aos serviços do Azure, garantindo que o tráfego não passe pela internet pública. Uma VNet gerenciada simplifica essa configuração para a computação de ML.
A solução de ML deve cumprir regras estritas de residência de dados, garantindo que todos os dados e a computação permaneçam dentro de uma região geográfica específica (por exemplo, União Europeia).
Criar o workspace do Azure ML, todas as contas de armazenamento associadas e recursos de computação em uma região dentro da geografia exigida. Usar isolamento de rede para prevenir a exfiltração de dados.
Por quê: Os recursos do Azure estão vinculados à região em que são criados. Isso garante a conformidade com a localização física dos dados. O isolamento de rede (VNet gerenciada) impede que os dados sejam processados fora desse limite.
Aplicar padrões organizacionais em todos os workspaces de ML, como exigir tags de alocação de custos, restringir tamanhos de VM ou obrigar o envio de logs de diagnóstico.
Usar o Azure Policy para aplicar e fazer cumprir regras para a criação e configuração de recursos.
Por quê: O Azure Policy oferece governança escalável e centralizada. Ele impede a criação de recursos não compatíveis, garantindo padrões consistentes sem supervisão manual.
Acessar dados no Azure Storage a partir de um workspace de ML sem armazenar credenciais (chaves de conta, tokens SAS) em código ou configuração.
Criar a conexão do datastore usando autenticação baseada em identidade. Conceder à identidade gerenciada do workspace (ou à identidade do usuário/computação) a função RBAC apropriada (por exemplo, Storage Blob Data Reader) na conta de armazenamento.
Por quê: Este é um padrão sem credenciais, de confiança zero, que usa o Azure AD para autenticação, melhorando a segurança e simplificando o gerenciamento de credenciais.
Várias equipes trabalham em projetos com diferentes níveis de segurança (por exemplo, PII vs. dados anonimizados). É necessário fornecer isolamento de recursos.
Criar workspaces separados do Azure ML para cada limite de segurança. Um workspace para projetos de PII deve ter um isolamento de rede mais rigoroso do que um para projetos não sensíveis.
Por quê: O workspace é o limite primário de segurança e isolamento. Segregar por nível de segurança é uma prática recomendada para evitar vazamento de dados e aplicar controles apropriados.
Necessidade de separar as atividades de desenvolvimento/experimentação do treinamento e implantação de modelos de nível de produção para prevenir interferências e garantir estabilidade.
Usar workspaces separados do Azure ML para ambientes de desenvolvimento e produção.
Por quê: Isso isola recursos, dados e modelos de produção do trabalho experimental, proporcionando estabilidade e governança clara para pipelines de MLOps de produção.
Provisionar computação para trabalhos de treinamento de ML que são executados intermitentemente, com alta prioridade na minimização de custos.
Usar um cluster de computação do Azure ML com VMs de baixa prioridade, uma contagem mínima de nós de 0 e auto-scaling configurado.
Por quê: VMs de baixa prioridade oferecem economias de custo significativas para cargas de trabalho interrompíveis. Um mínimo de 0 nós garante que você não pague nada quando o cluster está ocioso.
Necessidade de provisionar computação tanto para desenvolvimento interativo de notebooks por cientistas de dados individuais quanto para executar trabalhos de treinamento maiores e não supervisionados.
Provisionar Compute Instances para desenvolvimento interativo (uma por usuário). Provisionar Compute Clusters para trabalhos de treinamento em lote.
Por quê: Compute Instances são VMs persistentes de usuário único otimizadas para trabalho interativo. Compute Clusters são recursos multi-nós com auto-scaling otimizados para trabalhos em lote.
Garantir que as execuções de treinamento de ML sejam reproduzíveis, capturando todas as dependências de software, incluindo versões específicas de pacotes Python.
Definir um Ambiente do Azure ML usando um arquivo YAML de ambiente conda ou um Dockerfile. Registrar e versionar este ambiente para uso em trabalhos de treinamento.
Por quê: Os Ambientes são especificações versionadas e reutilizáveis de um tempo de execução. Isso desacopla o ambiente da computação, garantindo que qualquer execução com essa versão de ambiente seja idêntica.
A lógica de engenharia de features precisa ser consistente entre treinamento e inferência, e as features devem ser reutilizáveis em múltiplos modelos e equipes.
Usar o Azure ML Managed Feature Store para definir, computar e servir features.
Por quê: Um feature store garante consistência (prevenindo o skew de treinamento-serviço), possibilita a descoberta e reutilização de features, e oferece armazenamento offline (para treinamento) e online (para inferência de baixa latência).
Rastrear sistematicamente todos os experimentos de ML, incluindo versões de código, hiperparâmetros, métricas e artefatos de modelo, para comparação e reprodutibilidade.
Usar MLflow, que é nativamente integrado ao Azure ML. Habilitar o autologging ou usar comandos explícitos `mlflow.log_*` no script de treinamento.
Por quê: MLflow fornece um framework padronizado e de código aberto para rastreamento de experimentos. O Azure ML atua como um servidor de rastreamento MLflow gerenciado, fornecendo uma UI para comparar execuções.
Treinar um modelo de classificação em um conjunto de dados com um desequilíbrio severo de classes (por exemplo, detecção de fraude), levando a um desempenho fraco na classe minoritária.
Aplicar técnicas como SMOTE (Synthetic Minority Over-sampling Technique) aos dados de treinamento. Avaliar o modelo usando métricas insensíveis ao desequilíbrio, como Precision-Recall AUC ou F1-score.
Por quê: Simplesmente usar a acurácia é enganoso. SMOTE cria amostras sintéticas da classe minoritária para ajudar o modelo a aprender, e o PR-AUC/F1-score mede corretamente o desempenho na classe positiva.
É necessário encontrar hiperparâmetros ótimos para um modelo com um longo tempo de treinamento e um orçamento de computação limitado.
Usar um sweep job com amostragem Bayesiana e uma política de término antecipado (por exemplo, Bandit ou Median Stopping).
Por quê: A amostragem Bayesiana explora inteligentemente o espaço de busca, focando em regiões promissoras. O término antecipado interrompe execuções de baixo desempenho mais cedo, economizando tempo e custo significativos de computação.
Construir um modelo de previsão de séries temporais usando AutoML.
Configurar o job de AutoML com `task='forecasting'`, especificar o `time_column_name` e definir o `forecast_horizon`.
Por quê: Especificar a tarefa como "forecasting" permite que o AutoML aplique técnicas específicas de séries temporais, como geração de features de lag, detecção de sazonalidade e validação cruzada sensível ao tempo.
Treinar um grande modelo de deep learning em múltiplas GPUs em múltiplos nós de computação para reduzir o tempo de treinamento.
Usar um cluster de computação com nós habilitados para GPU. No job de comando, configurar a propriedade `distribution` (por exemplo, `type: "PyTorch"`, `process_count_per_instance: <# GPUs>`).
Por quê: O Azure ML simplifica o treinamento distribuído ao gerenciar a configuração e comunicação dos nós. A configuração `distribution` informa ao Azure ML como iniciar os processos de treinamento distribuído.
Automatizar um fluxo de trabalho de ML de várias etapas (por exemplo, preparação de dados, treinamento, avaliação) que pode ser reutilizado com diferentes parâmetros.
Definir um pipeline do Azure ML usando componentes para cada etapa. Usar inputs do pipeline para parametrizar o fluxo de trabalho.
Por quê: Pipelines baseados em componentes promovem modularidade e reutilização. Eles também suportam o cache automático de etapas (reutilização), o que economiza tempo ao não reexecutar etapas cujos inputs não foram alterados.
Um modelo tem um desempenho muito bom no conjunto de treinamento, mas um desempenho fraco no conjunto de validação, indicado por uma curva de perda de treinamento e validação divergente.
Este é um sinal clássico de overfitting. Mitigar aplicando regularização (por exemplo, dropout, L2), usando aumento de dados, implementando early stopping ou reduzindo a complexidade do modelo.
Por quê: A diferença entre o desempenho no treinamento e na validação mostra que o modelo memorizou os dados de treinamento em vez de generalizar. As técnicas de regularização penalizam a complexidade para melhorar a generalização.
Um trabalho de treinamento de longa duração em VMs de baixa prioridade (spot) corre o risco de ser preemptado e perder o progresso.
Implementar checkpointing dentro do script de treinamento para salvar periodicamente o modelo e o estado do otimizador no diretório `./outputs`.
Por quê: O diretório `./outputs` é automaticamente persistido pelo Azure ML. Salvar checkpoints permite que o job seja retomado do último estado salvo após a preempção, preservando o progresso e economizando custos.
Uma organização tem uma política que apenas certos algoritmos de ML podem ser usados em produção. É necessário aplicar isso durante as execuções do AutoML.
Na configuração do AutoML, usar o parâmetro `blocked_models` para excluir explicitamente algoritmos não aprovados do espaço de busca.
Por quê: Isso fornece uma maneira direta e aplicável de alinhar o AutoML com as políticas de governança, prevenindo a seleção de modelos não conformes.
Implantar um modelo para previsões em tempo real, de baixa latência (<100ms) com alta disponibilidade.
Implantar o modelo em um Azure ML Managed Online Endpoint.
Por quê: Managed online endpoints são um serviço totalmente gerenciado otimizado para inferência em tempo real, fornecendo auto-scaling, balanceamento de carga, implantações blue-green e monitoramento integrado.
Pontuar um grande volume de dados (milhões de registros) de forma assíncrona, com a eficiência de custo sendo uma prioridade.
Implantar o modelo em um Azure ML Batch Endpoint.
Por quê: Batch endpoints são projetados para pontuação assíncrona de grandes conjuntos de dados com alta taxa de transferência. Eles podem usar clusters de computação escaláveis que desligam para zero quando ociosos, otimizando custos.
Implantar uma nova versão do modelo minimizando o risco. É necessário mudar gradualmente o tráfego para a nova versão e permitir fácil reversão.
Usar um único managed online endpoint com duas implantações (por exemplo, "blue" para o modelo antigo, "green" para o novo). Usar divisão de tráfego para controlar a porcentagem de requisições indo para cada implantação.
Por quê: Este padrão de implantação blue-green permite implantações seguras e sem tempo de inatividade. Você pode validar o novo modelo em uma pequena parte do tráfego ao vivo antes de se comprometer com uma mudança completa.
Empacotar um modelo com suas dependências e artefatos de forma padronizada e agnóstica a frameworks para implantação.
Usar o formato de modelo MLflow. Ao registrar o modelo, incluir o arquivo conda.yaml ou requirements.txt e quaisquer artefatos de código necessários.
Por quê: MLflow oferece uma convenção padrão de empacotamento de modelos que o Azure ML compreende nativamente. Isso simplifica a implantação, pois o Azure ML pode construir automaticamente o ambiente necessário.
Um modelo implantado apresenta alta latência porque carrega arquivos auxiliares grandes (por exemplo, um featurizer grande) em cada requisição de previsão.
Mover a lógica de carregamento de arquivos da função `run()` para a função `init()` no script de pontuação.
Por quê: A função `init()` é executada apenas uma vez quando o container inicia. Carregar ativos aqui os torna globalmente disponíveis para todas as chamadas `run()`, evitando carregamentos redundantes em cada requisição.
Um endpoint em tempo real experimenta tráfego variável (picos altos, vales baixos). É necessário manter o desempenho de forma econômica.
Configurar auto-scaling na implantação do managed online endpoint. Definir um número mínimo e máximo de instâncias e uma regra de escalabilidade baseada na utilização da CPU ou latência da requisição.
Por quê: O auto-scaling ajusta automaticamente o número de instâncias de computação para corresponder à carga de tráfego, garantindo desempenho durante os picos e economizando custos durante as quedas.
Uma implantação de modelo requer bibliotecas de sistema específicas, versões customizadas do CUDA ou um servidor de inferência customizado não presente nas imagens padrão do Azure ML.
Criar um Dockerfile customizado que estenda uma imagem base de inferência do Azure ML, adicionar as dependências necessárias, construir e enviá-lo para o Azure Container Registry. Referenciar esta imagem no ambiente de implantação.
Por quê: Estender uma imagem base oferece controle total sobre o ambiente de execução, mantendo a compatibilidade com a infraestrutura de serviço do Azure ML.
Automatizar o ciclo de vida de ML de ponta a ponta, incluindo retreinamento, avaliação e implantação, acionado por mudanças de código ou dados.
Usar Azure DevOps ou GitHub Actions integrado com o Azure ML CLI v2 para criar um pipeline de CI/CD. O pipeline deve incluir um quality gate que compare o novo modelo com uma linha de base antes da implantação.
Por quê: Este padrão MLOps automatiza o fluxo de trabalho de ML, garantindo consistência, qualidade e iteração rápida. O quality gate previne regressões de desempenho do modelo.
O desempenho de um modelo em produção está degradando devido a mudanças na distribuição dos dados de entrada. O modelo precisa ser retreinado automaticamente quando um drift significativo é detectado.
Configurar um monitor de data drift do Azure ML no endpoint. Configurar um alerta que acione um Azure Logic App ou Azure Function, que por sua vez inicia o pipeline de retreinamento.
Por quê: Isso cria um sistema MLOps de ciclo fechado que mantém automaticamente a relevância do modelo em resposta a padrões de dados em mudança, sem intervenção manual.
Uma nova versão de modelo implantada é encontrada como defeituosa em produção. É necessário reverter rapidamente para a versão estável anterior.
Se estiver usando uma implantação blue-green, redirecione 100% do tráfego de volta para a implantação estável. Alternativamente, atualize o endpoint para reimplantar a versão anterior do modelo do registro de modelos.
Por quê: A mudança de tráfego proporciona um rollback instantâneo. Reimplantar uma versão do registro também é uma maneira rápida e confiável de restaurar um estado conhecido e funcional.
É necessário monitorar tanto a saúde operacional (latência, erros) quanto a qualidade preditiva (data drift, acurácia) de um modelo implantado.
Habilitar a integração do Application Insights no endpoint para métricas operacionais. Configurar a coleta de dados e o monitoramento de data drift do Azure ML para métricas de qualidade do modelo.
Por quê: Esta abordagem de duas frentes fornece uma visão completa da saúde do modelo. O App Insights rastreia o desempenho do sistema, enquanto a coleta de dados/monitoramento de drift rastreia o desempenho preditivo do modelo.
O endpoint do modelo está falhando devido a dados de entrada malformados ou inesperados dos clientes.
Implementar lógica de validação de entrada dentro da função `run()` do script de pontuação. Verificar tipos de dados, intervalos e estruturas, e retornar um erro significativo (por exemplo, HTTP 400) para requisições inválidas.
Por quê: A validação no lado do servidor protege o modelo de falhas e fornece feedback claro e imediato aos consumidores da API, tornando o serviço mais robusto.
É necessário entender por que um modelo complexo de "caixa preta" está fazendo certas previsões, para depuração, conformidade ou confiança das partes interessadas.
Usar o dashboard de IA Responsável no Azure ML para gerar explicações do modelo. Usar SHAP para explicações locais (predição individual) e importância global de features para o comportamento geral do modelo.
Por quê: Valores SHAP fornecem uma maneira robusta e agnóstica ao modelo de atribuir o impacto de cada feature em uma previsão específica, o que é crucial para cenários regulatórios e de depuração.
Um modelo usado para decisões como aprovação de empréstimos deve ser justo e não discriminar grupos demográficos protegidos.
Usar a avaliação de justiça do dashboard de IA Responsável para analisar métricas de justiça (por exemplo, paridade demográfica, odds igualadas) em features sensíveis. Aplicar técnicas de mitigação como ajustes de threshold de pós-processamento se forem encontradas disparidades.
Por quê: A avaliação de justiça fornece evidências quantitativas do comportamento de um modelo entre grupos. As técnicas de mitigação ajudam a corrigir vieses para garantir resultados equitativos.
Um LLM precisa responder a perguntas com base em documentos específicos e privados da empresa sem alucinar fatos.
Implementar um padrão de Geração Aumentada por Recuperação (RAG). Usar o Azure AI Search para criar um índice de vetores dos documentos. No momento da consulta, recuperar trechos de documentos relevantes e passá-los ao LLM como contexto no prompt.
Por quê: RAG fundamenta a resposta do LLM em informações factuais e atualizadas, reduzindo significativamente as alucinações e permitindo que ele utilize conhecimento não presente em seus dados de treinamento originais.
Um LLM deve seguir consistentemente diretrizes, tom e formatos de saída específicos (por exemplo, gerar JSON).
Usar engenharia de prompt de sistema detalhada. Fornecer uma persona clara, regras e restrições explícitas, e exemplos few-shot de pares de entrada/saída desejados.
Por quê: Um prompt de sistema bem elaborado é a maneira mais direta e eficaz de guiar o comportamento de um LLM sem o custo e a complexidade do fine-tuning.
É necessário medir a qualidade de uma aplicação LLM baseada em RAG.
Usar métricas de avaliação específicas para RAG, como Groundedness (a resposta é suportada pelo contexto?) e Relevance (a resposta aborda a pergunta do usuário?).
Por quê: Métricas NLP padrão como ROUGE são insuficientes. Groundedness e Relevance medem diretamente os desafios centrais do RAG: prevenir a alucinação e fornecer respostas úteis.
Uma aplicação LLM é muito lenta ou cara para uso em produção.
Implementar um roteador para usar modelos menores e mais baratos (por exemplo, GPT-3.5-Turbo) para tarefas simples. Habilitar o cache de respostas para consultas repetidas. Otimizar o comprimento do prompt.
Por quê: Usar o modelo de tamanho adequado para a tarefa é a medida mais eficaz de economia de custos. O cache elimina chamadas de API redundantes, reduzindo diretamente o custo e a latência.
Uma aplicação LLM processa dados sensíveis que não devem sair da rede corporativa ou ser usados para treinamento de modelos.
Implantar o serviço Azure OpenAI com um private endpoint. Configurar o recurso para não registrar dados de prompt/completion.
Por quê: Private endpoints garantem isolamento de rede. A opção de não registrar fornece uma camada adicional de privacidade de dados, atendendo a requisitos de conformidade rigorosos.
Um prompt flow desenvolvido no Azure AI Studio precisa ser implantado como um endpoint de produção altamente disponível e escalável.
Implantar o prompt flow como um Azure ML Managed Online Endpoint.
Por quê: Isso oferece um caminho contínuo do desenvolvimento para a produção, aproveitando a mesma infraestrutura robusta (auto-scaling, balanceamento de carga, monitoramento) usada para modelos de ML tradicionais.
Uma aplicação de IA generativa voltada para o usuário deve ser protegida contra a geração ou processamento de conteúdo prejudicial, ofensivo ou inseguro.
Usar tanto os filtros de conteúdo incorporados do Azure OpenAI quanto o serviço Azure AI Content Safety para moderação de defesa em profundidade de prompts e completions.
Por quê: A segurança em camadas é fundamental. Os filtros incorporados fornecem uma linha de base, enquanto o serviço dedicado Content Safety oferece controle mais granular e capacidades multi-modais.
Um chatbot de IA conversacional precisa manter o contexto em múltiplas interações do usuário.
LLMs são stateless. A aplicação deve gerenciar o histórico da conversa (por exemplo, em uma sessão ou banco de dados) e incluir partes relevantes do histórico em cada novo prompt para o LLM.
Por quê: Fornecer contexto explicitamente em cada chamada de API é a única maneira para um LLM stateless "lembrar" da conversa.
É necessário testar sistematicamente diferentes prompts para encontrar aquele que proporciona o melhor desempenho do LLM.
Usar Variants de prompt flow. Definir múltiplas versões de prompt para um nó e executar um teste em massa contra um conjunto de dados de avaliação para comparar métricas de desempenho.
Por quê: Variants oferecem uma abordagem estruturada e baseada em dados para a engenharia de prompts, indo além do método de tentativa e erro manual para uma otimização sistemática.
É necessário monitorar uma aplicação LLM em produção tanto para a saúde operacional quanto para a qualidade da resposta.
Combinar Application Insights para telemetria operacional (latência, taxas de erro, uso de tokens) com jobs de avaliação em lote periódicos usando um flow de avaliação para aferir a qualidade da resposta (groundedness, relevância).
Por quê: O monitoramento de LLM requer o rastreamento tanto do desempenho do sistema quanto da qualidade do conteúdo gerado. Essa combinação fornece uma visão holística da saúde da aplicação.