Databricks Machine Learning Professional — Preguntas de práctica y simulacro de examen

Model serving consciente de la regulación: 1) Requisitos del RGPD: minimización de datos: el modelo destinado a la UE solo puede entrenarse con features que no contengan identificadores personales. Limitación de la finalidad: las features se usan solo para el fin declarado. Derecho al olvido: el modelo no debe memorizar datos individuales. 2) Categorías de features: PII: nombre, email, teléfono, dirección, IP. Cuasi-identificadores: edad + código postal + género (la combinación puede identificar). Agregadas: monto promedio de transacción (últimos 30 días). De comportamiento: cantidad de inicios de sesión (no identifica a personas concretas). 3) Por qué dos versiones registradas: la frontera de compliance son los propios datos de entrenamiento, así que necesitas dos artefactos entrenados distintos —uno con el conjunto de features conforme al RGPD y otro con todas las features— registrados uno al lado del otro en el Model Registry, donde cada versión lleva su propio lineage, su stage y su rastro de auditoría. 4) Enrutamiento de solicitudes: una capa de enrutamiento delante del endpoint de serving inspecciona el header de región de la solicitud y dirige las solicitudes de la UE a la versión conforme y las de EE. UU. a la versión con todas las features. Databricks Model Serving permite servir varios modelos y varias versiones de un modelo al mismo tiempo, y te deja consultar un modelo servido concreto detrás de un endpoint, por lo que enrutar cada solicitud a una versión registrada específica es un patrón soportado. 5) Pruebas: versión conforme: verifica que no haya features de PII en su firma de entrada. Versión con todas las features: verifica que todas las features estén disponibles. Enrutamiento: verifica que un header de región de la UE siempre resuelva a la versión conforme. 6) Documentación de compliance: las model cards de cada versión registrada documentan qué features se usan. El lineage del Model Registry rastrea el origen de los datos de entrenamiento de cada versión. Los logs de acceso registran qué versión sirvió cada solicitud.

Respuestas enriquecidas en model serving: 1) Básica: {'prediction': 1}. 2) Con confianza: {'prediction': 1, 'confidence': 0.92}. 3) Con explicación: {'prediction': 1, 'confidence': 0.92, 'top_features': [{'name': 'credit_score', 'impact': 0.15}, {'name': 'debt_ratio', 'impact': -0.08}]}. 4) Con metadatos: agrega model_version, timestamp, request_id. 5) Patrones de implementación: predict de pyfunc → devuelve un DataFrame. Cada columna pasa a formar parte de la respuesta. Estructuras complejas: serialízalas como string JSON en una columna. 6) Compromisos de rendimiento: solo predicción: ~10ms. Predicción + confianza: ~10ms (las probabilidades ya están calculadas). Predicción + SHAP: ~50-200ms (el cálculo de SHAP agrega overhead). Optimización: calcula SHAP solo cuando se solicite (flag opcional en la petición). 7) Integración con el cliente: REST API: respuesta JSON con todos los campos. SDK: parseada en objetos tipados. Dashboard: mostrar la predicción + un medidor de confianza + un gráfico de cascada de features.