Preguntas de entrevista para Ingeniero de Machine Learning

Respuesta modelo

Mantengo un servicio de puntuación de fraude que atiende alrededor de 3.200 peticiones por segundo en hora punta y unos 240 millones de predicciones al mes. Corre sobre Kubernetes en AWS EKS, con el modelo exportado a ONNX y servido con Triton, y responde con una latencia p99 de 38 ms dentro de un presupuesto acordado con producto de 50 ms. Se reentrena cada semana con un pipeline de Airflow que valida el candidato contra el modelo vivo sobre un conjunto de referencia y bloquea la promoción si empeora en cualquiera de las tres métricas de control. Del servicio respondemos tres personas en guardia rotatoria cada cinco semanas, con un procedimiento de reversión documentado que devuelve la versión anterior en menos de cuatro minutos. Lo que más me costó no fue el modelo, sino garantizar que las variables que se calculan en línea coincidieran exactamente con las de entrenamiento; eso lo resolvimos con un feature store.

Respuesta modelo

Trabajo con tres capas de señales. La primera es la deriva de las entradas: calculo el índice de estabilidad de la población por variable y salto una alerta cuando el PSI supera 0,2, además de vigilar el porcentaje de nulos y de categorías nunca vistas, que suele ser el primer síntoma de un cambio de esquema aguas arriba. La segunda es la distribución de la salida: comparo con divergencia de Jensen-Shannon la distribución de puntuaciones de la última hora contra una ventana de referencia, porque un modelo puede recibir datos aparentemente normales y desplazar sus predicciones. La tercera, la que decide, es la métrica de negocio con etiqueta retardada; en mi caso la confirmación de fraude tarda entre tres y quince días, así que mantengo una ventana móvil y acepto que la señal definitiva llega tarde. Las dos primeras capas sirven para investigar, la tercera para actuar. Con este esquema el tiempo medio de detección de una degradación silenciosa bajó de tres semanas a veinticinco minutos.

Respuesta modelo

Primero traduzco los tres puntos de AUC a dinero y la latencia a conversión, porque sin esas dos cifras la discusión es de opiniones. En un caso parecido, tres puntos de AUC en el modelo de fraude equivalían a unos 40.000 € anuales de pérdida evitada, mientras que pasar de 38 ms a 115 ms nos sacaba del presupuesto de latencia de la pasarela de pago y, según la prueba que hicimos en sombra, costaba en torno a un 0,4 % de conversión, bastante más que el ahorro. Con esos números sobre la mesa la decisión ya no la tomo yo solo. Antes de descartarlo intento recuperar el margen por el lado de la ingeniería: exportación a ONNX, cuantización a INT8, batching dinámico o destilación a un modelo más pequeño; en aquel caso la cuantización nos devolvió el modelo a 52 ms con solo medio punto de AUC de pérdida y lo desplegamos. Si no hubiera funcionado, habría propuesto usarlo únicamente en el segmento de operaciones de importe alto, donde el presupuesto de latencia es más laxo y el valor por acierto es mucho mayor.

Respuesta modelo

Intento que no exista un momento de traspaso, sino una interfaz estable. En el equipo donde mejor funcionó, ciencia de datos entregaba tres cosas: el modelo registrado en MLflow con sus dependencias fijadas, las definiciones de variables en el feature store y un conjunto de referencia con el rendimiento esperado. A partir de ahí, una plantilla que construí con Terraform, Helm y GitHub Actions empaquetaba el modelo, ejecutaba pruebas de contrato sobre el esquema de entrada y salida, lanzaba una prueba de carga contra el presupuesto de latencia y lo publicaba primero en sombra, recibiendo tráfico real sin devolver respuesta, durante una semana. Si las distribuciones coincidían, pasaba a canario con el 5 % del tráfico y luego al total. Con ese circuito la puesta en producción bajó de doce jornadas de ingeniería por modelo a una y media, y lo importante es que ciencia de datos podía desplegar sin depender de mi calendario. Mi trabajo pasó a ser mantener la plantilla y revisar los casos raros.

Respuesta modelo

Es la diferencia entre las variables con las que se entrenó el modelo y las que realmente recibe en producción, y en mi experiencia es la causa número uno de que un modelo excelente en validación decepcione al desplegarse. Se produce por tres vías: código duplicado, cuando la transformación se escribe una vez en el cuaderno y otra en el servicio y divergen; datos, cuando en entrenamiento se usan valores consolidados que en el momento de la inferencia todavía no existen; y tiempo, cuando la ventana de agregación se calcula con información posterior al evento. Lo resolví con un feature store, en mi caso Feast con Redis para el servicio en línea y BigQuery para el histórico: una única definición de variable que sirve a los dos mundos y recuperación puntual en el tiempo para el conjunto de entrenamiento. Antes de eso perdíamos de media siete puntos de precisión al pasar a producción y nadie sabía exactamente por qué; después la diferencia entre validación y producción se quedó por debajo de un punto.

Respuesta modelo

Empiezo por medirlo en la unidad que entiende el negocio: euros por cada mil predicciones, con la factura repartida por modelo mediante etiquetas de recurso en la nube. Sin ese desglose no se puede priorizar. Después trabajo en cuatro palancas por orden de rentabilidad: primero, la elección de hardware, porque un porcentaje muy alto de los modelos tabulares que veo en GPU rinden igual y más barato en CPU; segundo, la optimización del propio modelo, con exportación a ONNX, cuantización y, si hace falta, destilación; tercero, el patrón de servicio, con batching dinámico, caché de predicciones para entradas repetidas y paso a inferencia por lotes de todo lo que no necesite respuesta inmediata; y cuarto, el escalado, ajustando el autoescalado a la utilización real y no a un número fijo de réplicas heredado. En mi último equipo esas cuatro palancas juntas bajaron el coste de 0,42 € a 0,11 € por cada mil peticiones, con la mayor parte del ahorro en las dos primeras. También revisé cuántas predicciones se calculaban y nunca se consumían: eliminamos un 18 % del volumen simplemente dejando de puntuar usuarios inactivos.

Respuesta modelo

En mi caso son muy concretas porque trabajaba con scoring crediticio, que el Reglamento (UE) 2024/1689 clasifica como sistema de alto riesgo. En la práctica eso se traduce en cinco cosas que afectan a la arquitectura y no solo al papeleo: gestión de riesgos documentada a lo largo del ciclo de vida; gobierno de los datos de entrenamiento, con trazabilidad de origen y análisis de sesgos; registro automático de eventos, en nuestro caso las inferencias conservadas de forma inmutable durante veinticuatro meses con la versión exacta de modelo y de variables; documentación técnica y ficha por modelo; y supervisión humana efectiva, que en nuestro flujo significaba que ninguna denegación se ejecutaba de forma automática sin posibilidad de revisión. Lo implementé con DVC y MLflow para el versionado, SHAP integrado en la propia respuesta del servicio para poder explicar cualquier decisión concreta, y un registro de auditoría aparte del sistema de observabilidad. En España la supervisión corresponde a la AESIA, y conviene no mezclar este marco con el RGPD, que sigue aplicándose en paralelo y responde a otra lógica.

Respuesta modelo

Porque el problema que me interesa empieza donde termina el cuaderno. He hecho las dos cosas y disfruto más con la parte de sistema: pensar en el presupuesto de latencia, en qué pasa cuando el tráfico se multiplica por cinco un día de rebajas, en cómo se revierte un despliegue sin que el usuario lo note y en cómo consigo que otros equipos publiquen modelos sin pasar por mí. Me gusta además que el resultado sea verificable: un modelo que sirve tantas peticiones a tanta latencia y a tanto coste es un hecho comprobable, no una interpretación. Respeto mucho el trabajo de inferencia estadística y de diseño de experimentos, y sigo colaborando estrechamente con quienes lo hacen, pero mi criterio y mi formación están del lado de la ingeniería de software y de la infraestructura, y es ahí donde aporto más valor a un equipo.

Antes de tocar nada, mido dónde se va el tiempo: instrumento el servicio y separo red, deserialización, cálculo de variables, inferencia y posprocesado. En la mitad de los casos que he visto la inferencia no era el cuello de botella, sino la consulta síncrona a una base de datos para recuperar variables. Con el perfil delante voy por orden de coste y beneficio: primero elimino trabajo innecesario, precalculando variables en el feature store en línea y cacheando lo que se repite; después optimizo el modelo, exportándolo a ONNX o compilándolo con TensorRT y cuantizando a INT8, lo que en modelos tabulares y en redes pequeñas suele dar entre tres y cinco veces de mejora con pérdida despreciable; luego reviso el patrón de servicio, con batching dinámico si el volumen lo permite y paralelismo adecuado al número de núcleos; y solo al final considero cambiar de modelo por uno más pequeño o destilado, porque es lo que más discusión de producto genera. En paralelo compruebo lo básico: que no haya una llamada bloqueante en el hilo de la petición, que la conexión sea persistente y que el arranque en frío de los contenedores no esté contaminando el percentil 99.

Separaría la generación de candidatos del reordenado. La primera fase la resolvería con recuperación por vecinos aproximados sobre un índice vectorial actualizado por lotes cada hora, que devuelve unos quinientos candidatos en pocos milisegundos; la segunda con un modelo de reordenado ligero que puntúa esos candidatos en línea. Las variables de usuario y de artículo vivirían en un feature store en línea sobre Redis, con materialización en flujo desde Kafka para las de comportamiento reciente y por lotes para las estables. El servicio de inferencia iría en Kubernetes con Triton, batching dinámico, autoescalado horizontal por utilización y no por número de peticiones, y un mínimo de réplicas calientes para no pagar arranques en frío en los picos. Delante pondría una caché de respuestas para usuarios recurrentes con poca actividad, que en mi experiencia absorbe entre el 20 % y el 30 % del tráfico. Para las garantías: presupuesto de latencia repartido por etapa, límite de tiempo por llamada con una alternativa de respaldo —una lista de popularidad precalculada— si el reordenado no responde a tiempo, y despliegue canario con métricas de negocio en tiempo real. Todo instrumentado con Prometheus y trazas distribuidas con OpenTelemetry.

Con cuatro cosas versionadas y atadas entre sí. El código, en Git con la etiqueta exacta del despliegue. Los datos, con DVC o con instantáneas inmutables de las particiones utilizadas, nunca con una consulta que diga «últimos doce meses», porque eso no es reproducible por definición. El entorno, con una imagen de contenedor cuyas dependencias estén fijadas hasta la versión concreta, incluidas las bibliotecas de sistema y las de GPU, que son las que más rompen. Y los parámetros junto con las semillas aleatorias, registrados en MLflow en la misma ejecución que produce el artefacto. Con eso, cualquier modelo del registro debe poder rastrearse hasta la confirmación de código, el conjunto de datos y la imagen que lo generaron. En la práctica añado una prueba periódica que reentrena un modelo antiguo y compara métricas: si el resultado no coincide dentro de una tolerancia, algo se ha roto en la cadena y prefiero descubrirlo en una ejecución programada que durante una auditoría.

El despliegue en sombra envía tráfico real al modelo nuevo pero descarta su respuesta: el usuario nunca la ve. Sirve para validar la infraestructura, la latencia bajo carga real y la coincidencia de distribuciones de entrada, y es mi primer paso siempre, porque tiene riesgo cero. El canario expone al modelo nuevo a una fracción pequeña del tráfico real, entre el 1 % y el 5 %, y sí afecta a esos usuarios; sirve para detectar problemas que solo aparecen cuando la predicción tiene consecuencias, y va acompañado de reversión automática si alguna métrica de guardia se sale de rango. La prueba A/B es un experimento con potencia estadística calculada de antemano para medir el efecto sobre una métrica de negocio; requiere aleatorización correcta y un plazo suficiente, y es la única que responde a la pregunta de si el modelo nuevo genera más valor. Los uso encadenados: sombra durante una semana, canario durante dos o tres días y prueba A/B durante el tiempo que exija el tamaño muestral. Ese último cálculo lo hago con el equipo de ciencia de datos, que es quien tiene el criterio estadístico; mi responsabilidad es que la asignación sea estable, que no haya contaminación entre grupos y que la infraestructura permita cortar en cualquier momento.

Empiezo por el motivo del reinicio: reviso el estado del pod y, si aparece un código 137, es memoria agotada y el sistema lo ha terminado. Después miro los registros del contenedor anterior, que son los que contienen la pista real y que se pierden si solo se consultan los actuales. Las causas que me he encontrado con más frecuencia son tres: límite de memoria demasiado ajustado para el tamaño del modelo más el búfer de las peticiones concurrentes, que se manifiesta solo bajo carga; sonda de vitalidad con un plazo más corto que el arranque real del servicio, de modo que el sistema mata el contenedor mientras carga los pesos, para lo que existe la sonda de arranque; y en GPU, memoria de vídeo insuficiente cuando varios procesos comparten tarjeta. Reproduzco el problema con una prueba de carga en preproducción, observo la curva de memoria y ajusto peticiones y límites con margen sobre el pico real, no sobre la media. Si el consumo crece de forma sostenida sin estabilizarse, entonces es una fuga y la busco con un perfilador de memoria, normalmente en el preprocesado o en una caché sin cota.

Distingo cuatro niveles. Pruebas de software convencionales sobre las funciones de transformación de datos, con casos límite: nulos, categorías nuevas, fechas fuera de rango, cadenas vacías. Pruebas de datos ejecutadas en cada lote, con Great Expectations o equivalente, que verifican esquema, rangos, unicidad de claves, porcentaje de nulos y volumen esperado; si un lote no las supera, no entra en el entrenamiento. Pruebas de modelo, que en mi caso son de tres tipos: rendimiento mínimo sobre un conjunto de referencia congelado, comportamiento esperado ante perturbaciones dirigidas —si aumento los ingresos declarados, la probabilidad de impago no debería subir— y ausencia de degradación frente al modelo en producción. Y pruebas de integración del servicio: contrato del esquema de entrada y salida, latencia bajo carga sintética y coincidencia entre la predicción del artefacto entrenado y la que devuelve el servicio desplegado para un conjunto de casos fijos, que es la prueba que atrapa los desfases de preprocesado. Todas se ejecutan en la integración continua y las tres últimas bloquean la promoción.

Primero fijo los requisitos que determinan todo lo demás: peticiones concurrentes esperadas, longitud de entrada y de salida, latencia aceptable para el primer token y si hace falta respuesta en flujo. Con eso dimensiono. Para el servicio usaría vLLM, que gestiona el lote continuo y la memoria de atención paginada, con el modelo cuantizado —AWQ o GPTQ— para reducir memoria de vídeo, y mediría dos cosas por separado: tiempo hasta el primer token y tokens por segundo por usuario, porque son las que percibe la persona. El dimensionado lo hago con una prueba de carga real, no con la ficha del fabricante. En paralelo monto la evaluación, que es la parte que más se descuida: un conjunto de casos propios con respuestas de referencia, revisión humana de una muestra y métricas que se ejecuten en cada cambio de modelo, de indicaciones o de parámetros. Y el análisis económico honesto, comparando el coste por cada mil consultas de la infraestructura propia, incluida la GPU parada en horas valle, contra la tarifa de la API externa; en mi último caso salía a cuenta a partir de cierto volumen, pero el argumento decisivo fue que los datos de los clientes no salían de nuestra infraestructura, lo que simplificaba mucho el análisis de RGPD.

Lo decido con una sola pregunta: ¿la predicción depende de información que solo existe en el momento de la petición? Si la respuesta es no, va por lotes. Un modelo de propensión a la baja que se consulta en una campaña semanal no necesita servicio en línea: se calcula de madrugada para toda la base, se guarda en una tabla o en una caché y se consulta en microsegundos, con un coste que suele ser un orden de magnitud menor y una operación mucho más sencilla. La inferencia en tiempo real la reservo para lo que depende del contexto inmediato: detección de fraude sobre la transacción en curso, recomendación que reacciona a los clics de la sesión, precios dinámicos. También existe el caso intermedio, que resuelvo precalculando la parte pesada por lotes y dejando en línea solo el reordenado ligero con las variables de sesión. Mi criterio general es empezar por lotes y pasar a tiempo real únicamente cuando haya una necesidad demostrada, porque cada servicio en línea añade guardias, coste y superficie de fallo.

Primero contengo y luego investigo. Miro si el cambio coincide con un despliegue reciente del modelo o de cualquier servicio aguas arriba; si hay un candidato claro, revierto de inmediato, porque una reversión de cuatro minutos siempre es más barata que dos horas de diagnóstico con el sistema tomando decisiones malas. Si no hay despliegue reciente, compruebo la distribución de las variables de entrada de la última hora contra la referencia: en el incidente real que viví, una variable había pasado a llegar nula en el 90 % de los casos porque el equipo de datos había renombrado un campo en el origen, y el modelo interpretaba ese nulo como perfil de riesgo. Mientras investigo, aviso al responsable de negocio con una estimación del impacto en operaciones afectadas, porque esa decisión —seguir sirviendo, revertir o pasar a revisión manual— no es solo técnica. Cerrado el incidente, escribo el análisis posterior sin culpables y, sobre todo, añado la salvaguarda que faltaba: en aquel caso, un contrato de datos con validación de esquema que impide publicar un lote fuera de especificación, y una alerta por porcentaje de nulos que habría avisado seis horas antes.

No empiezo negociando el plazo, sino aclarando qué significa producción en este caso. Si el modelo se consume una vez por semana en una campaña, una inferencia por lotes con un pipeline de Airflow es perfectamente viable en dos semanas; si hace falta un servicio en línea con guardias y monitorización, no lo es y prefiero decirlo el primer día con el desglose de tareas delante. Después reviso el cuaderno buscando los tres puntos que siempre generan problemas: transformaciones que usan información posterior al evento, dependencia de ficheros locales y variables que en producción no existen en el momento de la inferencia. Con eso propongo una entrega por fases: en dos semanas, el modelo empaquetado, con dependencias fijadas, pruebas mínimas y ejecución por lotes en preproducción; en las siguientes, el servicio en línea, la monitorización y el reentrenamiento. En mi experiencia esta conversación funciona mucho mejor si va acompañada de una alternativa concreta y de una fecha creíble para lo demás, en lugar de un no.

Expongo el riesgo en términos de consecuencias, no de metodología. Tres meses de datos en un negocio con estacionalidad significan que el modelo no ha visto nunca una campaña de rebajas ni un cierre de trimestre, y que la primera vez que ocurra no sabremos si su comportamiento es correcto. Dicho eso, no bloqueo: propongo el camino que reduce el riesgo sin perder la fecha, que suele ser desplegar en sombra desde mañana mismo, con lo que empezamos a acumular evidencia real sin exponer a ningún usuario, y abrir un canario del 5 % con reversión automática en cuanto tengamos unos días de datos comparados. Si aun así la decisión es desplegar al completo, la acepto, la dejo por escrito con los riesgos identificados y refuerzo la monitorización y el procedimiento de reversión para esa semana. Mi trabajo es que la organización decida con la información correcta, no imponer mi criterio; lo que no haría nunca es callarme el riesgo y luego decir que ya lo advertí.

Por la atribución, porque sin saber qué modelo y qué entorno consumen cada euro cualquier recorte es a ciegas. Etiqueto los recursos por modelo, equipo y entorno y suelo encontrar lo mismo: una parte importante del gasto no está en producción sino en entornos de experimentación con GPU encendidas fuera de horario y en clústeres de entrenamiento que nadie apagó. Ese es el primer recorte y no afecta al rendimiento en absoluto. Después voy a producción con las palancas técnicas: revisar qué modelos están en GPU sin necesitarla, cuantizar y compilar los que sí, ajustar el autoescalado a la utilización real y activar batching donde el patrón de tráfico lo permita. La tercera vía, y la que más ahorro dio en mi caso, fue dejar de calcular lo que nadie consumía: el 18 % de las predicciones diarias correspondía a usuarios inactivos que ninguna campaña iba a contactar. Presento el resultado como coste por cada mil inferencias y por modelo, que es la cifra que permite a negocio decidir si un modelo caro compensa, y me comprometo a mantener ese panel, porque el ahorro se revierte solo en dos trimestres si nadie lo vigila.

Lo comunico el mismo día, con evidencia y sin dramatizar. Preparo la demostración concreta —qué variable se calcula con información posterior al evento y cuál es el rendimiento en una validación temporal correcta— y cuantifico el impacto real en decisiones tomadas durante ese año, porque esa es la pregunta que hará dirección. Después propongo un plan con opciones y plazos: retirar el modelo y volver a la regla anterior si el rendimiento honesto es peor que ella, o mantenerlo con expectativas corregidas mientras se reconstruye, que suele ser lo razonable si aun así aporta valor. Evito por completo el tono de acusación: quien construyó ese modelo probablemente cometió un error frecuente y difícil de ver, y lo que interesa es que la organización aprenda. La parte que considero más importante es la última: añadir a la integración continua una comprobación de validación temporal y una revisión de la genealogía de cada variable, para que el siguiente caso lo detecte una prueba automática y no una persona un año después.

En las dos primeras semanas no toco nada: hago inventario. Para cada modelo intento averiguar seis datos —quién lo consume, con qué volumen, desde qué versión, con qué datos se entrenó, cómo se despliega y qué pasa si se cae— y los escribo en una ficha de una página. Ese inventario casi siempre revela lo mismo: uno o dos modelos críticos, varios que apenas se usan y alguno que nadie consume desde hace meses y que se puede apagar, lo que además libera presupuesto. Con el mapa hecho priorizo por riesgo: al modelo más crítico le pongo primero monitorización y procedimiento de reversión, aunque sea rudimentario, porque no saber si funciona es peor que no poder reentrenarlo. Después ataco la reproducibilidad de ese mismo modelo, que suele ser la tarea más ingrata: reconstruir el entorno, fijar dependencias y conseguir reentrenarlo obteniendo un resultado equivalente. Solo cuando el más crítico está bajo control paso al siguiente. Y comparto el inventario con negocio, porque suele ser la primera vez que alguien les enseña qué modelos sostienen sus procesos.