Última revisión: mayo de 2026
Una referencia escaneable de patrones arquitectónicos que evalúa el examen DP-100. Lee de arriba a abajo o salta a una sección.
Necesita una plataforma centralizada y colaborativa para todo el ciclo de vida del aprendizaje automático, desde la preparación de datos hasta la implementación y el monitoreo.
Espacio de trabajo de Azure Machine Learning.
Por qué: Es el servicio fundamental que integra todos los componentes requeridos: computación, almacenes de datos (datastores), entornos, seguimiento de experimentos, registro de modelos y puntos de conexión (endpoints).
Requiere que todo el tráfico del espacio de trabajo de ML, incluido el de recursos dependientes como Storage y ACR, permanezca en la red privada de Azure y no esté expuesto a la internet pública.
Configure el espacio de trabajo de Azure ML con una red virtual administrada y utilice puntos de conexión privados para el espacio de trabajo y todos sus recursos dependientes (Storage, Key Vault, ACR).
Por qué: Los puntos de conexión privados proporcionan conectividad segura y privada a los servicios de Azure, asegurando que el tráfico no atraviese la internet pública. Una VNet administrada simplifica esta configuración para la computación de ML.
La solución de ML debe cumplir con estrictas reglas de residencia de datos, asegurando que todos los datos y la computación permanezcan dentro de una región geográfica específica (por ejemplo, Unión Europea).
Cree el espacio de trabajo de Azure ML, todas las cuentas de almacenamiento asociadas y los recursos de computación en una región dentro de la geografía requerida. Utilice el aislamiento de red para prevenir la exfiltración de datos.
Por qué: Los recursos de Azure están vinculados a la región en la que se crean. Esto garantiza el cumplimiento de la ubicación física de los datos. El aislamiento de red (VNet administrada) evita que los datos se procesen fuera de este límite.
Aplicar estándares organizacionales en todos los espacios de trabajo de ML, como requerir etiquetas de asignación de costos, restringir tamaños de VM o exigir el envío de registros de diagnóstico.
Utilice Azure Policy para aplicar y hacer cumplir reglas para la creación y configuración de recursos.
Por qué: Azure Policy proporciona una gobernanza centralizada y escalable. Impide la creación de recursos no conformes, asegurando estándares consistentes sin supervisión manual.
Acceder a datos en Azure Storage desde un espacio de trabajo de ML sin almacenar credenciales (claves de cuenta, tokens SAS) en código o configuración.
Cree la conexión del almacén de datos (datastore) utilizando autenticación basada en identidad. Otorgue a la identidad administrada del espacio de trabajo (o a la identidad del usuario/computación) el rol RBAC apropiado (por ejemplo, Storage Blob Data Reader) en la cuenta de almacenamiento.
Por qué: Este es un patrón sin credenciales y de confianza cero que utiliza Azure AD para la autenticación, mejorando la seguridad y simplificando la gestión de credenciales.
Múltiples equipos trabajan en proyectos con diferentes niveles de seguridad (por ejemplo, PII vs. datos anonimizados). Es necesario proporcionar aislamiento de recursos.
Cree espacios de trabajo de Azure ML separados para cada límite de seguridad. Un espacio de trabajo para proyectos con PII debe tener un aislamiento de red más estricto que uno para proyectos no sensibles.
Por qué: El espacio de trabajo es el límite principal de seguridad y aislamiento. Segregar por nivel de seguridad es una mejor práctica para prevenir la fuga de datos y aplicar controles apropiados.
Es necesario separar las actividades de desarrollo/experimentación del entrenamiento y despliegue de modelos de grado de producción para prevenir interferencias y asegurar la estabilidad.
Utilice espacios de trabajo de Azure ML separados para entornos de desarrollo y producción.
Por qué: Esto aísla los recursos, datos y modelos de producción del trabajo experimental, proporcionando estabilidad y una gobernanza clara para los pipelines de MLOps de producción.
Aprovisionar computación para trabajos de entrenamiento de ML que se ejecutan intermitentemente, con alta prioridad en minimizar el costo.
Utilice un clúster de computación de Azure ML con máquinas virtuales de baja prioridad, un recuento mínimo de nodos de 0 y autoescalado configurado.
Por qué: Las máquinas virtuales de baja prioridad (low-priority VMs) proporcionan ahorros de costos significativos para cargas de trabajo interrumpibles. Un mínimo de 0 nodos asegura que no paga nada cuando el clúster está inactivo.
Es necesario aprovisionar computación tanto para el desarrollo interactivo de notebooks por científicos de datos individuales como para ejecutar trabajos de entrenamiento más grandes y desatendidos.
Aprovisione instancias de computación (Compute Instances) para desarrollo interactivo (una por usuario). Aprovisione clústeres de computación (Compute Clusters) para trabajos de entrenamiento por lotes.
Por qué: Las instancias de computación son máquinas virtuales persistentes de un solo usuario optimizadas para trabajo interactivo. Los clústeres de computación son recursos de varios nodos con autoescalado optimizados para trabajos por lotes.
Asegurar que las ejecuciones de entrenamiento de ML sean reproducibles capturando todas las dependencias de software, incluidas las versiones específicas de paquetes Python.
Defina un entorno de Azure ML utilizando un archivo YAML de entorno conda o un Dockerfile. Registre y versione este entorno para usarlo en trabajos de entrenamiento.
Por qué: Los entornos son especificaciones versionadas y reutilizables de un tiempo de ejecución. Esto desacopla el entorno de la computación, asegurando que cualquier ejecución con esa versión del entorno sea idéntica.
La lógica de ingeniería de características debe ser consistente entre el entrenamiento y la inferencia, y las características deben ser reutilizables en múltiples modelos y equipos.
Utilice Azure ML Managed Feature Store para definir, computar y servir características.
Por qué: Un feature store asegura la consistencia (previniendo el sesgo entre entrenamiento y servicio), habilita el descubrimiento y la reutilización de características, y proporciona almacenamiento tanto fuera de línea (para entrenamiento) como en línea (para inferencia de baja latencia).
Rastrear sistemáticamente todos los experimentos de ML, incluyendo versiones de código, hiperparámetros, métricas y artefactos del modelo, para comparación y reproducibilidad.
Utilice MLflow, que está integrado nativamente en Azure ML. Habilite el registro automático (autologging) o use comandos `mlflow.log_*` explícitos en el script de entrenamiento.
Por qué: MLflow proporciona un framework de código abierto estandarizado para el seguimiento de experimentos. Azure ML actúa como un servidor de seguimiento MLflow administrado, proporcionando una interfaz de usuario para comparar ejecuciones.
Entrenar un modelo de clasificación en un conjunto de datos con un desequilibrio de clases severo (por ejemplo, detección de fraude), lo que lleva a un rendimiento deficiente en la clase minoritaria.
Aplique técnicas como SMOTE (Synthetic Minority Over-sampling Technique) a los datos de entrenamiento. Evalúe el modelo utilizando métricas insensibles al desequilibrio, como Precision-Recall AUC o F1-score.
Por qué: Simplemente usar la precisión es engañoso. SMOTE crea muestras sintéticas de la clase minoritaria para ayudar al modelo a aprender, y PR-AUC/F1-score mide correctamente el rendimiento en la clase positiva.
Es necesario encontrar hiperparámetros óptimos para un modelo con un tiempo de entrenamiento prolongado y un presupuesto de computación limitado.
Utilice un trabajo de barrido (sweep job) con muestreo bayesiano y una política de terminación temprana (por ejemplo, Bandit o Median Stopping).
Por qué: El muestreo bayesiano explora inteligentemente el espacio de búsqueda, centrándose en regiones prometedoras. La terminación temprana detiene las ejecuciones de bajo rendimiento antes, ahorrando tiempo y costo de computación significativos.
Construir un modelo de pronóstico de series de tiempo utilizando AutoML.
Configure el trabajo de AutoML con `task='forecasting'`, especifique el `time_column_name` y establezca el `forecast_horizon`.
Por qué: Especificar la tarea como "forecasting" (pronóstico) permite a AutoML aplicar técnicas específicas de series de tiempo como la generación de características de retraso, la detección de estacionalidad y la validación cruzada sensible al tiempo.
Entrenar un modelo de aprendizaje profundo grande en múltiples GPU en varios nodos de computación para reducir el tiempo de entrenamiento.
Utilice un clúster de computación con nodos habilitados para GPU. En el trabajo de comando, configure la propiedad `distribution` (por ejemplo, `type: "PyTorch"`, `process_count_per_instance: <# GPUs>`).
Por qué: Azure ML simplifica el entrenamiento distribuido gestionando la configuración y comunicación de los nodos. La configuración de `distribution` le dice a Azure ML cómo lanzar los procesos de entrenamiento distribuido.
Automatizar un flujo de trabajo de ML de varios pasos (por ejemplo, preparación de datos, entrenamiento, evaluación) que se pueda reutilizar con diferentes parámetros.
Defina un pipeline de Azure ML utilizando componentes para cada paso. Utilice las entradas del pipeline para parametrizar el flujo de trabajo.
Por qué: Los pipelines basados en componentes promueven la modularidad y la reutilización. También soportan el almacenamiento en caché automático de pasos (reutilización), lo que ahorra tiempo al no volver a ejecutar pasos cuyas entradas no han cambiado.
Un modelo funciona muy bien en el conjunto de entrenamiento pero mal en el conjunto de validación, indicado por una curva de pérdida de entrenamiento y validación divergente.
Esta es una señal clásica de sobreajuste (overfitting). Mitíguelo aplicando regularización (por ejemplo, dropout, L2), utilizando aumento de datos, implementando la parada temprana o reduciendo la complejidad del modelo.
Por qué: La brecha entre el rendimiento de entrenamiento y validación muestra que el modelo ha memorizado los datos de entrenamiento en lugar de generalizar. Las técnicas de regularización penalizan la complejidad para mejorar la generalización.
Un trabajo de entrenamiento de larga duración en máquinas virtuales de baja prioridad (spot VMs) corre el riesgo de ser expropiado y perder el progreso.
Implemente puntos de control (checkpointing) dentro del script de entrenamiento para guardar periódicamente el modelo y el estado del optimizador en el directorio `./outputs`.
Por qué: El directorio `./outputs` es automáticamente persistido por Azure ML. Guardar puntos de control permite reanudar el trabajo desde el último estado guardado en caso de expropiación, preservando el progreso y ahorrando costos.
Una organización tiene una política que solo ciertos algoritmos de ML pueden usarse en producción. Es necesario hacer cumplir esto durante las ejecuciones de AutoML.
En la configuración de AutoML, utilice el parámetro `blocked_models` para excluir explícitamente algoritmos no aprobados del espacio de búsqueda.
Por qué: Esto proporciona una forma directa y aplicable de alinear AutoML con las políticas de gobernanza, evitando la selección de modelos no conformes.
Desplegar un modelo para predicciones en tiempo real y de baja latencia (<100ms) con alta disponibilidad.
Despliegue el modelo en un punto de conexión en línea administrado (Managed Online Endpoint) de Azure ML.
Por qué: Los puntos de conexión en línea administrados son un servicio completamente gestionado optimizado para inferencia en tiempo real, proporcionando autoescalado, balanceo de carga, despliegues azul-verde y monitoreo integrado.
Puntuar un gran volumen de datos (millones de registros) de forma asíncrona, priorizando la eficiencia de costos.
Despliegue el modelo en un punto de conexión por lotes (Batch Endpoint) de Azure ML.
Por qué: Los puntos de conexión por lotes están diseñados para la puntuación asíncrona y de alto rendimiento de grandes conjuntos de datos. Pueden usar clústeres de computación escalables que se reducen a cero cuando están inactivos, optimizando los costos.
Desplegar una nueva versión de modelo minimizando el riesgo. Es necesario desviar gradualmente el tráfico a la nueva versión y permitir una fácil reversión.
Utilice un único punto de conexión en línea administrado con dos despliegues (por ejemplo, "azul" para el modelo antiguo, "verde" para el nuevo). Utilice la división de tráfico para controlar el porcentaje de solicitudes que van a cada despliegue.
Por qué: Este patrón de despliegue azul-verde permite despliegues seguros y sin tiempo de inactividad. Puede validar el nuevo modelo en una pequeña porción del tráfico en vivo antes de comprometerse a un cambio completo.
Empaquetar un modelo con sus dependencias y artefactos de manera estandarizada e independiente del framework para su despliegue.
Utilice el formato de modelo MLflow. Al registrar el modelo, incluya el archivo conda.yaml o requirements.txt y cualquier artefacto de código necesario.
Por qué: MLflow proporciona una convención estándar de empaquetado de modelos que Azure ML entiende de forma nativa. Esto simplifica el despliegue, ya que Azure ML puede construir automáticamente el entorno requerido.
Un modelo desplegado tiene alta latencia porque carga archivos auxiliares grandes (por ejemplo, un featurizer grande) en cada solicitud de predicción.
Mueva la lógica de carga de archivos de la función `run()` a la función `init()` en el script de puntuación.
Por qué: La función `init()` se ejecuta solo una vez cuando el contenedor se inicia. Cargar los activos aquí los hace globalmente disponibles para todas las llamadas a `run()`, evitando cargas redundantes en cada solicitud.
Un punto de conexión en tiempo real experimenta tráfico variable (picos altos, valles bajos). Es necesario mantener el rendimiento de manera rentable.
Configure el autoescalado en el despliegue del punto de conexión en línea administrado. Establezca un número mínimo y máximo de instancias y defina una regla de escalado basada en la utilización de CPU o la latencia de la solicitud.
Por qué: El autoescalado ajusta automáticamente el número de instancias de computación para igualar la carga de tráfico, asegurando el rendimiento durante los picos y ahorrando costos durante los períodos de calma.
Un despliegue de modelo requiere bibliotecas de sistema específicas, versiones personalizadas de CUDA o un servidor de inferencia personalizado no presente en las imágenes predeterminadas de Azure ML.
Cree un Dockerfile personalizado que extienda una imagen base de inferencia de Azure ML, agregue las dependencias requeridas, constrúyalo y súbalo a Azure Container Registry. Referencie esta imagen en el entorno de despliegue.
Por qué: Extender una imagen base proporciona control total sobre el entorno de ejecución, manteniendo la compatibilidad con la infraestructura de servicio de Azure ML.
Automatizar el ciclo de vida de ML de extremo a extremo, incluyendo reentrenamiento, evaluación y despliegue, activado por cambios en el código o los datos.
Utilice Azure DevOps o GitHub Actions integrados con la CLI v2 de Azure ML para crear un pipeline de CI/CD. El pipeline debe incluir una puerta de calidad que compare el nuevo modelo con una línea base antes de desplegarlo.
Por qué: Este patrón de MLOps automatiza el flujo de trabajo de ML, asegurando consistencia, calidad e iteración rápida. La puerta de calidad previene regresiones en el rendimiento del modelo.
El rendimiento de un modelo en producción se está degradando debido a cambios en la distribución de los datos de entrada. El modelo necesita ser reentrenado automáticamente cuando se detecta una deriva significativa.
Configure un monitor de deriva de datos de Azure ML en el punto de conexión. Establezca una alerta que active una Azure Logic App o Azure Function, la cual a su vez iniciará el pipeline de reentrenamiento.
Por qué: Esto crea un sistema MLOps de ciclo cerrado que mantiene automáticamente la relevancia del modelo en respuesta a los patrones de datos cambiantes, sin intervención manual.
Se descubre que una versión de modelo recién desplegada es defectuosa en producción. Es necesario revertir rápidamente a la versión estable anterior.
Si utiliza un despliegue azul-verde, desvíe el 100% del tráfico de vuelta al despliegue estable. Alternativamente, actualice el punto de conexión para redesplegar la versión anterior del modelo desde el registro de modelos.
Por qué: El desvío de tráfico proporciona una reversión instantánea. Redesplegar una versión desde el registro también es una forma rápida y confiable de restaurar un estado conocido y bueno.
Es necesario monitorear tanto la salud operativa (latencia, errores) como la calidad predictiva (deriva de datos, precisión) de un modelo desplegado.
Habilite la integración de Application Insights en el punto de conexión para métricas operativas. Configure la recopilación de datos y el monitoreo de deriva de datos de Azure ML para métricas de calidad del modelo.
Por qué: Este enfoque de dos frentes proporciona una vista completa de la salud del modelo. App Insights rastrea el rendimiento del sistema, mientras que la recopilación de datos/monitoreo de deriva rastrea el rendimiento predictivo del modelo.
El punto de conexión del modelo está fallando debido a datos de entrada mal formados o inesperados de los clientes.
Implemente la lógica de validación de entrada dentro de la función `run()` del script de puntuación. Verifique tipos de datos, rangos y estructuras, y devuelva un error significativo (por ejemplo, HTTP 400) para solicitudes inválidas.
Por qué: La validación del lado del servidor protege el modelo de fallas y proporciona retroalimentación clara e inmediata a los consumidores de la API, haciendo el servicio más robusto.
Es necesario comprender por qué un modelo complejo de "caja negra" está haciendo ciertas predicciones, para depuración, cumplimiento o confianza de las partes interesadas.
Utilice el panel de IA Responsable en Azure ML para generar explicaciones del modelo. Utilice SHAP para explicaciones locales (predicción individual) e importancia de características global para el comportamiento general del modelo.
Por qué: Los valores SHAP proporcionan una forma robusta e independiente del modelo para atribuir el impacto de cada característica en una predicción específica, lo cual es crucial para escenarios regulatorios y de depuración.
Un modelo utilizado para decisiones como la aprobación de préstamos debe ser justo y no discriminar a grupos demográficos protegidos.
Utilice la evaluación de equidad del panel de IA Responsable para analizar métricas de equidad (por ejemplo, paridad demográfica, probabilidades igualadas) en características sensibles. Aplique técnicas de mitigación como ajustes de umbral de post-procesamiento si se encuentran disparidades.
Por qué: La evaluación de equidad proporciona evidencia cuantitativa del comportamiento de un modelo entre grupos. Las técnicas de mitigación ayudan a corregir sesgos para asegurar resultados equitativos.
Un LLM necesita responder preguntas basadas en documentos específicos y privados de la empresa sin alucinar hechos.
Implemente un patrón de Generación Aumentada por Recuperación (RAG). Utilice Azure AI Search para crear un índice vectorial de los documentos. En el momento de la consulta, recupere fragmentos de documentos relevantes y páselos al LLM como contexto en el prompt.
Por qué: RAG fundamenta la respuesta del LLM en información fáctica y actualizada, reduciendo significativamente las alucinaciones y permitiéndole utilizar conocimientos no presentes en sus datos de entrenamiento originales.
Un LLM debe seguir consistentemente pautas específicas, tono y formatos de salida (por ejemplo, generar JSON).
Utilice ingeniería de prompts de sistema detallada. Proporcione una persona clara, reglas y restricciones explícitas, y ejemplos "few-shot" de pares entrada/salida deseados.
Por qué: Un prompt de sistema bien elaborado es la forma más directa y efectiva de dirigir el comportamiento de un LLM sin el costo y la complejidad del ajuste fino (fine-tuning).
Es necesario medir la calidad de una aplicación LLM basada en RAG.
Utilice métricas de evaluación específicas para RAG, como Groundedness (¿la respuesta está respaldada por el contexto?) y Relevancia (¿la respuesta aborda la pregunta del usuario?).
Por qué: Las métricas estándar de PNL como ROUGE son insuficientes. Groundedness y Relevancia miden directamente los desafíos centrales de RAG: prevenir alucinaciones y proporcionar respuestas útiles.
Una aplicación LLM es demasiado lenta o cara para su uso en producción.
Implemente un enrutador para usar modelos más pequeños y económicos (por ejemplo, GPT-3.5-Turbo) para tareas simples. Habilite el almacenamiento en caché de respuestas para consultas repetidas. Optimice la longitud del prompt.
Por qué: Usar el modelo del tamaño adecuado para la tarea es la medida de ahorro de costos más efectiva. El almacenamiento en caché elimina las llamadas redundantes a la API, reduciendo directamente el costo y la latencia.
Una aplicación LLM procesa datos sensibles que no deben salir de la red corporativa ni utilizarse para el entrenamiento del modelo.
Despliegue el servicio Azure OpenAI con un punto de conexión privado. Configure el recurso para que no registre datos de prompt/completion.
Por qué: Los puntos de conexión privados aseguran el aislamiento de la red. La opción de no registro proporciona una capa adicional de privacidad de datos, cumpliendo con estrictos requisitos de cumplimiento.
Un flujo de prompts desarrollado en Azure AI Studio necesita ser desplegado como un punto de conexión de producción altamente disponible y escalable.
Despliegue el flujo de prompts como un punto de conexión en línea administrado (Managed Online Endpoint) de Azure ML.
Por qué: Esto proporciona un camino fluido desde el desarrollo hasta la producción, aprovechando la misma infraestructura robusta (autoescalado, balanceo de carga, monitoreo) utilizada para los modelos de ML tradicionales.
Una aplicación de IA generativa orientada al usuario debe protegerse de generar o procesar contenido dañino, ofensivo o inseguro.
Utilice tanto los filtros de contenido incorporados de Azure OpenAI como el servicio Azure AI Content Safety para una moderación en profundidad de prompts y completions.
Por qué: La seguridad por capas es crítica. Los filtros incorporados proporcionan una base, mientras que el servicio dedicado Content Safety ofrece un control más granular y capacidades multimodales.
Un chatbot de IA conversacional necesita mantener el contexto a través de múltiples interacciones del usuario.
Los LLM son sin estado. La aplicación debe gestionar el historial de la conversación (por ejemplo, en una sesión o base de datos) e incluir partes relevantes del historial en cada nuevo prompt al LLM.
Por qué: Proporcionar explícitamente el contexto en cada llamada a la API es la única forma en que un LLM sin estado puede "recordar" la conversación.
Es necesario probar sistemáticamente diferentes prompts para encontrar el que ofrece el mejor rendimiento del LLM.
Utilice variantes de flujo de prompts (prompt flow Variants). Defina múltiples versiones de prompts para un nodo y ejecute una prueba masiva contra un conjunto de datos de evaluación para comparar las métricas de rendimiento.
Por qué: Las variantes proporcionan un enfoque estructurado y basado en datos para la ingeniería de prompts, yendo más allá de la prueba y error manual hacia la optimización sistemática.
Es necesario monitorear una aplicación LLM en producción tanto para la salud operativa como para la calidad de la respuesta.
Combine Application Insights para telemetría operativa (latencia, tasas de error, uso de tokens) con trabajos de evaluación por lotes periódicos utilizando un flujo de evaluación para determinar la calidad de la respuesta (groundedness, relevancia).
Por qué: El monitoreo de LLM requiere el seguimiento tanto del rendimiento del sistema como de la calidad del contenido generado. Esta combinación proporciona una visión holística de la salud de la aplicación.