Preguntas de entrevista Ingeniero de Machine Learning

El ciclo de vida empieza mucho antes de cualquier modelado. Comienzo trabajando con los stakeholders para enmarcar el problema correctamente: ¿qué decisión apoya el modelo, qué significa un buen rendimiento para el negocio y qué datos están disponibles con qué calidad? Una vez enmarcado el problema, construyo primero una línea base simple, porque un modelo lineal bien ajustado frecuentemente supera a una implementación deficiente de red neuronal. Para producción, diseño la infraestructura de servicio en paralelo con el modelo. Configuro la monitorización desde el primer día: detección de deriva de datos, seguimiento de la distribución de predicciones y latencia. También planifico el reentrenamiento y defino los criterios de activación de antemano. Lo más importante que he aprendido es que el modelo normalmente no es el cuello de botella: la calidad de los datos, la ingeniería de características y la fiabilidad del servicio importan más.

Trato la ingeniería de características como conocimiento del dominio codificado en código. Las mejores características generalmente provienen de entender el problema y los datos en profundidad. Mi primer paso siempre es hablar con expertos del dominio y entender qué señales creen que importan, luego probar si esas señales tienen valor predictivo. Soy riguroso en la prevención de fugas de datos, lo que significa definir un límite temporal estricto al trabajar con datos de series temporales. Uso transformaciones estables en producción. Prefiero menos características bien entendidas porque son más fáciles de depurar cuando algo falla en producción. Documento cada característica con su fuente, transformación y limitaciones conocidas.

Las métricas offline solas no son suficientes. Uso una evaluación de múltiples etapas: métricas offline en el conjunto de prueba retenido a través de subgrupos relevantes para detectar impacto desigual, luego un despliegue en sombra para verificar que la infraestructura de servicio funciona y la latencia es aceptable, y finalmente una prueba A/B o un despliegue gradual comenzando con un pequeño porcentaje de tráfico monitorizando la métrica de negocio. Configuro activadores de rollback automáticos. Un modelo está listo para producción cuando confío tanto en la monitorización como en el modelo.

Construí un modelo de predicción de churn que funcionó bien offline pero experimentó una caída significativa en precisión en el primer mes tras el lanzamiento. La causa raíz fue un cambio de distribución: un cambio en el producto había alterado el comportamiento de los usuarios de una manera que hacía que los datos históricos de entrenamiento fueran menos representativos. El modelo no tenía un activador de reentrenamiento, así que se degradaba silenciosamente. La solución fue agregar monitorización de deriva de datos al pipeline de características, implementar reentrenamiento semanal automático activado por la detección de deriva, y configurar alertas de distribución de predicciones. También introduje una tarjeta de modelo con declaraciones explícitas sobre las condiciones de validación. La lección fue que un modelo es un componente en un sistema cambiante y necesita la misma inversión operacional que cualquier otro servicio de producción.

Estaba presentando los resultados de la evaluación de un modelo de precios a un equipo directivo. El modelo tenía mejor rendimiento en nuestra métrica principal pero peor rendimiento en una métrica de equidad para un segmento de clientes específico. Reestructuré la presentación en torno a una sola pregunta: "¿debemos desplegar este modelo?" Mostré el trade-off visualmente y enmarcé el hallazgo de equidad como un riesgo de negocio además de una preocupación ética, lo que transformó la conversación de una discusión técnica en una decisión sobre los valores de la empresa. Acordamos retrasar el despliegue hasta investigar el problema de equidad. La reunión fue mejor porque la traté como una reunión de decisión, no una presentación.

Heredé un sistema de recomendación que llevaba 18 meses en producción, sin reentrenar desde hacía seis meses, con una tasa de clics en descenso constante. En lugar de reentrenar inmediatamente, investigué primero: dos características importantes habían derivado significativamente por una expansión del catálogo, y el modelo sobre-recomendaba un conjunto reducido de artículos populares. Reconstruí el pipeline de características, añadí un regularizador de diversidad al objetivo de entrenamiento, y configuré una suite de evaluación offline que medía tanto relevancia como diversidad. Tras el reentrenamiento y la prueba A/B, la tasa de clics mejoró un 14% y el engagement en la larga cola mejoró un 23%.

Mi enfoque depende del grado de desequilibrio y del coste de negocio de los diferentes tipos de error. Para un desequilibrio leve, suelo empezar ajustando el umbral de decisión en lugar de remuestrear. Para un desequilibrio más severo, uso pesos de clase en la función de pérdida. Si ninguna funciona bien, pruebo el sobremuestreo de la clase minoritaria con SMOTE o el submuestreo de la mayoritaria. Siempre evalúo con métricas significativas bajo desequilibrio: F1, AUC precisión-recall o el coeficiente de correlación de Matthews en lugar de la exactitud. También verifico si el desequilibrio en los datos de entrenamiento refleja la prevalencia real en producción.

Monitorizó tres cosas: calidad de datos, comportamiento del modelo e impacto de negocio. La monitorización de calidad de datos detecta violaciones de esquema, picos de valores nulos y deriva de distribución de características. La monitorización del comportamiento del modelo rastrea distribuciones de predicciones y puntuaciones de confianza. La monitorización del impacto de negocio vincula las salidas del modelo con los resultados que está diseñado para generar. Uso pruebas estadísticas para la detección de deriva en lugar de umbrales fijos donde sea posible. El mayor error de monitorización es vigilar entradas y salidas pero no la relación entre ellas.

Empiezo con el modelo más simple que podría funcionar, luego agrego complejidad solo cuando los datos y el problema lo justifican. Para datos tabulares con características bien diseñadas, los árboles de gradiente potenciado generalmente son difíciles de superar. Para datos no estructurados como texto o imágenes, las arquitecturas de transformer o CNN preentrenadas son casi siempre el punto de partida correcto. Para problemas de recomendación y ranking, pienso primero en las restricciones de servicio: un modelo complejo que no puede servir en menos de 50 milisegundos no es viable independientemente del rendimiento offline. La peor decisión es elegir una arquitectura porque es nueva, no porque encaje con el problema.