Preguntas de entrevista Data scientist

El aprendizaje supervisado utiliza datos etiquetados para entrenar un modelo que prediga una salida a partir de características de entrada. Lo uso cuando tengo una variable objetivo clara y suficientes ejemplos etiquetados: predicción de churn, estimación de precios, clasificación de imágenes. El aprendizaje no supervisado encuentra estructuras en los datos sin etiquetas. Lo uso cuando quiero descubrir patrones que no he definido de antemano: segmentación de clientes con k-means, modelado de temas con LDA, o detección de anomalías cuando no tengo ejemplos etiquetados de fraude. En la práctica, muchos proyectos combinan ambos: uso clustering no supervisado para identificar segmentos de clientes y luego construyo un clasificador supervisado para asignar nuevos clientes a esos segmentos en tiempo real. La decisión siempre parte de la pregunta de negocio y los datos disponibles.

Empiezo con análisis exploratorio de datos antes de tocar ningún código de modelado. Compruebo la estructura y el esquema, luego examino las tasas de valores faltantes por columna y decido si imputarlos, eliminarlos o marcarlos. Analizo las distribuciones de características numéricas: asimetría, valores atípicos y si la escala varía mucho entre columnas. Para características categóricas verifico la cardinalidad y si alguna categoría aparece solo en el conjunto de prueba. También examino pronto la distribución de la variable objetivo: el desequilibrio de clases en un problema de clasificación cambia casi todas las decisiones posteriores. Cruzo las características clave con el objetivo para construir una intuición del señal disponible antes de escribir una sola línea de sklearn. Documento los hallazgos a medida que avanzo.

El sobreajuste ocurre cuando un modelo aprende los datos de entrenamiento tan bien que captura el ruido en lugar del patrón subyacente, y el rendimiento se degrada con datos nuevos. Lo detecto comparando las métricas de entrenamiento y validación lado a lado: una gran brecha entre una precisión de entrenamiento del 97% y una de validación del 81% es una señal clara. Para prevenirlo, uso validación cruzada en lugar de una única división train-test, lo que da una estimación más fiable de la generalización. Para modelos basados en árboles ajusto la profundidad máxima y el número mínimo de muestras por hoja, y uso parada anticipada en gradient boosting. Para redes neuronales aplico dropout y monitoreo la pérdida de validación. La regularización L1 o L2 ayuda con modelos lineales. También controlo el número de características: añadir características ruidosas empeora el sobreajuste.

Construí un modelo de predicción de churn para un producto de suscripción y tuve que presentar los resultados al equipo directivo de marketing y customer success. El modelo usaba un clasificador gradient boosting con unas 40 características, lo que sabía que no significaría nada para ellos. Eliminé por completo los detalles técnicos de las diapositivas. Me centré en tres cosas: qué predice el modelo, qué nivel de confianza debemos tener en él según la precisión y el recall en datos de prueba, y sobre todo qué significaba para sus decisiones. Presenté los cinco principales factores de riesgo de churn en lenguaje claro: los clientes que no habían iniciado sesión en 21 días y no habían usado la función de informes tenían 4,2 veces más probabilidades de abandonar en 30 días. El equipo vio inmediatamente qué segmentos priorizar. Las preguntas fueron sobre estrategia, no metodología.

Construí un modelo de propensión para predecir qué usuarios del nivel gratuito pasarían a un plan de pago en 60 días. Tras entrenar con seis meses de datos, el AUC en el conjunto de validación era 0,71, lo que parecía razonable. Pero cuando realizamos una prueba en vivo durante cuatro semanas, la precisión fue mucho menor de lo esperado: estábamos marcando demasiados falsos positivos. Hice un análisis post-mortem y encontré dos problemas. Primero, los datos de entrenamiento tenían un problema de fuga de etiqueta: una de las características incluía un clic en un aviso de actualización dentro de la aplicación que ocurría justo antes de la conversión, lo que significaba que el modelo había aprendido de una señal no disponible en el momento de la predicción. Segundo, el desequilibrio de clases era más severo en la población real. Reconstruí el modelo eliminando la característica con fuga y reequilibrando con SMOTE. El AUC en vivo mejoró a 0,79 y la precisión en el decil superior pasó del 31% al 58%.

Después de construir un modelo de detección de fraude en tiempo real en Python, trabajé con dos ingenieros de backend para llevarlo a producción. El primer reto fue que había construido el modelo en un entorno Jupyter y el pipeline de ingeniería de características no era reproducible fuera de él. Pasé dos días refactorizando el código de preprocesamiento en un módulo Python limpio con pruebas unitarias para que ingeniería pudiera integrarlo con confianza. Acordamos un contrato de API: el modelo recibiría un payload JSON y devolvería una puntuación entre 0 y 1 con un tiempo de respuesta inferior a 50 ms. Containerice el modelo con Docker y usamos un despliegue en shadow para enrutar el 10% del tráfico real al nuevo modelo. Monitoreamos la distribución de predicciones y la latencia durante dos semanas antes de migrar completamente. El periodo shadow detectó un caso extremo donde un campo faltante causaba una predicción nula.

Empiezo preguntando cuál es el coste de cada tipo de error en el contexto de negocio, porque la exactitud por sí sola casi nunca cuenta toda la historia. Para la detección de fraude, un falso negativo (fraude no detectado) es mucho más costoso que un falso positivo, así que doy mucho peso al recall. Para un modelo de puntuación de leads donde la capacidad de ventas es limitada, la precisión importa más: quiero que los leads que llamamos sean de alta calidad. Cuando las clases están desequilibradas, la exactitud es especialmente engañosa. Uso la curva AUC-ROC para comparar modelos de forma independiente al umbral, y la curva precisión-recall cuando la clase positiva es rara. Para el umbral operativo final examino la puntuación F-beta y elijo un beta que refleje el compromiso de negocio. También controlo la calibración: un modelo que dice "70% de probabilidad" debería acertar aproximadamente el 70% de las veces.

La ingeniería de características es a menudo donde se crea el mayor valor, y la trato como un proceso continuo en lugar de un paso único. Empiezo con el conocimiento del dominio: ¿qué cree un experto humano que predice el resultado? Eso me da un conjunto de partida rápido. Luego examino las características brutas y creo derivadas: ratios, medias móviles en diferentes ventanas temporales, tiempo transcurrido desde el último evento, y términos de interacción entre características que la lógica de negocio sugiere que podrían actuar juntas. Para datos de texto uso TF-IDF o embeddings según si la tarea necesita similitud semántica. Valido cada característica midiendo su importancia en un modelo base y ejecutando pruebas de permutación para confirmar que añade señal. También compruebo la multicolinealidad: las características altamente correlacionadas pueden desestabilizar algunos modelos.

La brecha entre un notebook funcional y un modelo de producción fiable es significativa y vale la pena planificarla desde el principio. Empiezo escribiendo el pipeline de características como Python limpio y testeable en lugar de celdas de notebook, para que el mismo código de preprocesamiento se ejecute de forma idéntica en el entrenamiento y en la inferencia. Esto previene el skew entrenamiento-servicio, una de las fuentes más comunes de degradación silenciosa del modelo. Versiono el artefacto del modelo y el pipeline de características juntos con MLflow o una herramienta similar. Defino los requisitos de monitoreo antes del lanzamiento: quiero rastrear las distribuciones de características de entrada, las distribuciones de puntuaciones de salida, y el rendimiento real versus predicho en datos de retroalimentación etiquetados. Configuro umbrales de alerta para la deriva de datos con pruebas estadísticas como el test de Kolmogorov-Smirnov.