Entrevista de Ingeniería de Datos: ¿Cómo Diseñar un Pipeline de Features de ML sin Training-Serving Skew?

La Pregunta y Cuándo Aplica

Diseña un pipeline de features de ML para la puntuación de fraude en tiempo real. El conjunto de entrenamiento abarca los 12 meses anteriores y el sistema online maneja aproximadamente 5,000 predicciones por segundo. Cada predicción necesita alrededor de 50 features, con un presupuesto p99 de 5 ms para la recuperación de features. Estos números son supuestos de capacidad para discutir compensaciones (trade-offs), no valores predeterminados de la industria.

Las features incluyen un agregado de monto de transacciones de una hora a partir de un flujo de eventos y la antigüedad de la cuenta actualizada diariamente. Algunos eventos llegan tarde, los datos históricos pueden ser objeto de backfill y una actualización del modelo puede cambiar las definiciones de las features. Explica cómo construir datos de entrenamiento correctos en el tiempo (point-in-time), servir valores online con baja latencia, manejar datos faltantes y obsoletos, desplegar nuevas versiones y demostrar que la semántica offline y online coincide.

Esta pregunta aplica a entrevistas de ingeniería de datos, ingeniería de machine learning y plataformas de ML. El objetivo no es recitar "agregar un feature store". Es conectar la definición, el cómputo, el almacenamiento, el servicio y la verificación de una feature en una única ruta rastreable.

Qué Está Evaluando el Entrevistador

Primero, ¿puede el candidato definir la semántica de las features antes de dibujar una arquitectura de almacenamiento? Una respuesta sólida coloca la clave de entidad, el tipo de datos, la fuente, la versión de transformación, el tiempo del evento (event time), el tiempo de disponibilidad (availability time), la ventana de agregación, el requisito de frescura, la política por defecto y el propietario en un contrato de features. Tanto los sistemas offline como online implementan ese contrato en lugar de adivinar el significado a partir de un nombre.

Segundo, ¿puede el candidato razonar correctamente sobre el tiempo? event_at indica cuándo ocurrió un evento en el dominio del negocio; available_at indica cuándo el sistema realmente se enteró de él. Un evento puede haber ocurrido antes de una predicción pero haber llegado después, por lo que el servicio no pudo haberlo utilizado. Un join de entrenamiento que solo verifique event_at <= prediction_at aún puede arrastrar información tardía o de backfill hacia el pasado.

Tercero, ¿puede el candidato elegir el cómputo y el almacenamiento para diferentes patrones de acceso? El entrenamiento offline necesita historial temporal y joins point-in-time, mientras que el servicio online generalmente necesita el valor más reciente para una entidad. Los agregados de ventana son buenos candidatos para el precálculo y la materialización. Las features económicas que dependen únicamente de la solicitud actual pueden calcularse bajo demanda. Los motores de ejecución offline y online pueden diferir, pero su semántica debe coincidir y la equivalencia debe demostrarse con datos.

Cuarto, ¿puede el candidato diseñar un despliegue de versiones seguro y un comportamiento ante fallas? Un modelo debe fijar la versión del conjunto de features que consume, y las versiones antiguas y nuevas deben coexistir durante las ventanas de canary y rollback. Faltante no significa cero. Los datos obsoletos, las caídas del almacén y las versiones incompatibles necesitan, cada uno, una política explícita.

Finalmente, el entrevistador busca una verificación ejecutable: verificaciones de contratos, registros dorados (golden records), pruebas históricas point-in-time, vectores de features online muestreados, reproducción offline, inyección de eventos tardíos y desordenados, simulacros de backfill y rollback, además de métricas de latencia, frescura, valores faltantes y paridad.

Preguntas para Aclarar Primero

• ¿Cuál es el momento de la predicción y la ventana de etiquetas? Asume que la puntuación ocurre cuando llega una transacción y las etiquetas de contracargo (chargeback) maduran en los siguientes 30 días. La información de las etiquetas nunca debe fluir de regreso hacia las features.
• ¿Qué incluye el presupuesto de latencia online? ¿Los 5 ms p99 cubren solo la recuperación de features, o también la red, la serialización y la inferencia? Esta respuesta lo trata como el presupuesto exclusivo de recuperación de features.
• ¿Qué tan fresca debe ser cada feature? Un total de transacciones de una hora puede necesitar una frescura a nivel de minutos, mientras que la antigüedad de la cuenta puede tolerar actualizaciones diarias. No se debe aplicar un único TTL a todas las features.
• ¿Qué tan tardíos, duplicados o desordenados pueden estar los eventos? Esto determina los watermarks, la deduplicación, el recálculo y las reglas de sobrescritura online.
• ¿Debe un backfill histórico reproducir "lo que se sabía entonces" o "la verdad corregida más reciente"? Reproducir el servicio pasado necesita lo primero; el análisis post-hoc puede necesitar lo segundo. No se pueden mezclar en un solo conjunto de datos.
• ¿Cómo debe degradarse el negocio ante datos online faltantes u obsoletos? Los sistemas de fraude pueden utilizar un modelo base, revisión manual o una decisión conservadora en lugar de convertir cada valor faltante en cero.
• ¿Cómo se despliegan los modelos y las features de forma independiente? Necesitamos saber si se pueden materializar múltiples versiones en paralelo, cuánto tiempo permanecen las versiones antiguas y cuál es el objetivo de rollback.
• ¿Qué infraestructura existe ya? Para un solo modelo por lotes (batch) de bajo tráfico, las transformaciones versionadas compartidas y las instantáneas (snapshots) inmutables pueden ser suficientes. No se debe asumir una plataforma completa de features como punto de partida.

Estructura de Respuesta en 30 Segundos

"Primero crearía un contrato de features que contenga claves de entidad, dos relojes, ventanas, versiones y requisitos de frescura. Los eventos sin procesar permanecen inmutables y las mismas definiciones generan el historial offline y los valores online más recientes. Los ejemplos de entrenamiento utilizan un join point-in-time en prediction_at, restringido tanto por event_at como por available_at, de modo que los datos que lleguen más tarde no puedan viajar al pasado. El modelo fija feature_set_version; las versiones antiguas y nuevas se materializan en paralelo y se comparan en la sombra (shadow) antes de mover el tráfico. Muestreo los vectores de features online reales, los reproduzco offline a partir de eventos sin procesar con las mismas definiciones, comparo valores, valores faltantes y frescura feature por feature, e inyecto eventos tardíos, backfills, fallas del almacén y rollbacks".

Análisis Detallado Paso a Paso

Paso 1: Convertir la definición de cada feature en un contrato ejecutable.

Registra al menos los siguientes campos para cada feature:

Una vez que se publica el nombre de una feature, su definición no debe cambiar silenciosamente. Si txn_amount_sum_1h cambia de "transacciones autorizadas" a "todas las transacciones intentadas", publica una nueva versión o nombre de feature. Un modelo antiguo no debe consumir sin saberlo el nuevo significado.

Paso 2: Hacer que las rutas offline y online comiencen a partir de los mismos hechos.

Las transacciones, los cambios de cuenta y otros eventos de origen ingresan primero a un registro inmutable o a una capa de historial reproducible. El procesamiento en streaming calcula features de ventana de alta frescura; el procesamiento batch calcula dimensiones que cambian lentamente y backfills históricos. Ambas rutas escriben el historial de tiempo completo en el almacén offline y materializan el valor válido más reciente por entidad en el almacén online.

"Misma definición" no requiere que los jobs de batch y stream utilicen el mismo lenguaje. Es preferible utilizar transformaciones declarativas compartidas o código compartido. Si son necesarias dos implementaciones, los registros dorados y la paridad en la reproducción se convierten en puertas de lanzamiento (release gates). Un feature store organiza estas restricciones; no elimina automáticamente la divergencia entre dos implementaciones.

Las escrituras online deben ser idempotentes. Los eventos llevan IDs estables para que los duplicados no incrementen los agregados dos veces. Al escribir un valor más reciente, compara las marcas de tiempo y las versiones de las features para que un resultado tardío más antiguo no pueda sobrescribir un valor más nuevo. Las features de ventana también necesitan un intervalo de retraso permitido (allowed lateness), un watermark y una regla de corrección explícitos.

Paso 3: Construir datos de entrenamiento genuinamente correctos en el tiempo (point-in-time).

Cada ejemplo de entrenamiento tiene un prediction_at. Para la misma entidad, un as-of join básico selecciona la versión de feature más reciente con event_at <= prediction_at. Cuando los eventos pueden ser tardíos o provenir de un backfill, también debe satisfacer available_at <= prediction_at:

eligible_feature = same_entity
  AND event_at <= prediction_at
  AND available_at <= prediction_at

selected_feature = latest eligible_feature by event_at, then available_at

La segunda condición es fundamental. Supongamos que una transacción ocurrió el lunes, llegó el miércoles y la predicción histórica ocurrió el martes. Está en el pasado según el tiempo del negocio, pero todavía en el futuro según el conocimiento del sistema. Si la plataforma de datos no puede preservar available_at, utiliza la instantánea inmutable o el registro de features online de ese momento. No presentes la tabla corregida de hoy como el estado que el servicio histórico realmente vio.

"Tal como se conocía entonces" y "última corrección" deben ser modos explícitos de datasets. El primero reproduce lo que un modelo podía ver en un momento histórico; el segundo admite la conciliación o el análisis post-hoc. Las etiquetas se manejan por separado: solo los ejemplos con ventanas de observación maduras entran al entrenamiento, y los datos de generación de etiquetas nunca participan en los joins de features.

Paso 4: Elegir entre materialización y cómputo en lectura (compute-on-read).

Los agregados de ventana, como el monto de transacciones de una hora o el conteo de dispositivos de siete días, son costosos y sensibles a la frescura, por lo que deben calcularse incrementalmente y materializarse a partir del stream. Las features de baja frecuencia, como la antigüedad de la cuenta, pueden actualizarse por lotes. Una feature económica que dependa solo de la solicitud actual y no necesite historial de entrenamiento puede calcularse bajo demanda, reduciendo el almacenamiento y la superficie de sincronización.

El almacén online recupera los valores más recientes por clave de entidad y feature_set_version en lugar de escanear el historial en el momento de la solicitud. El almacén offline conserva las series temporales para entrenamiento, backfills y auditorías. Junto con los valores, la API de recuperación debe devolver o registrar las marcas de tiempo de las features, las versiones de cómputo y los estados de valores faltantes para que el servicio pueda detectar la obsolescencia y la incompatibilidad.

Paso 5: Definir el comportamiento ante datos faltantes, obsoletos y caídas del servicio.

Cada feature o grupo de features tiene su propio presupuesto de frescura. En el momento de la lectura, calcula prediction_at - feature_timestamp y marca los valores como obsoletos cuando superen ese presupuesto. Faltante, obsoleto y el valor numérico legítimo cero son tres estados distintos. Los datos de entrenamiento deben representar los valores faltantes de la misma manera que el servicio.

El riesgo determina la degradación. Una feature no crítica puede usar un valor por defecto que se incluyó en el entrenamiento del modelo. Una feature a la que se le permita estar brevemente obsoleta puede usar su valor anterior. Si una feature crítica de fraude no está disponible, redirige a un modelo que no dependa de ella, envía el caso a revisión manual o toma una decisión más conservadora. Registra cada motivo de degradación para que el sistema no permanezca silenciosamente con valores por defecto durante un período prolongado.

Paso 6: Desplegar versiones preservando la capacidad de rollback.

El artefacto del modelo fija un feature_set_version que contiene nombres de features, esquemas y versiones de transformación. Para lanzar la v2, materializa v1 y v2 en paralelo. Realiza lecturas en la sombra (shadow reads) de las mismas entidades y reproduce casos históricos. Después de que la cobertura, la frescura, las distribuciones de valores y las diferencias por feature cumplan con sus puertas de calidad, despliega el modelo que consume la v2. Mantén la v1 hasta que haya finalizado la ventana de rollback.

Las reglas de compatibilidad de esquemas también deben ser explícitas. Agregar una feature opcional puede ser retrocompatible; eliminar una feature, cambiar su tipo o cambiar su semántica generalmente requiere una nueva versión. Antes del despliegue del modelo, verifica que el almacén online ya tenga la versión y cobertura requeridas. No despliegues el modelo primero para dejar que el backfill de features se ponga al día después.

Paso 7: Verificar la paridad utilizando hechos del servicio online.

Muestrea solicitudes online y registra la entidad, prediction_at, feature_set_version, cada valor de feature, la marca de tiempo de la feature, el estado faltante/obsoleto y la versión final del modelo. Registrar únicamente la puntuación del modelo imposibilita localizar si una discrepancia provino de un valor, un límite temporal o una versión.

El verificador comienza a partir de eventos de origen inmutables, utiliza la misma versión de definición, reconstruye el vector offline en el mismo momento de predicción y compara feature por feature:

• los valores coinciden, con tolerancias declaradas para features de punto flotante;
• los estados faltantes, por defecto y obsoletos coinciden;
• los límites de las ventanas de eventos y las zonas horarias coinciden;
• la versión de la feature online coincide con la declaración del modelo;
• los eventos tardíos, duplicados, desordenados y de backfill se reproducen de forma determinista.

Antes del lanzamiento, inyecta indisponibilidad del almacén online, claves parcialmente faltantes, tiempos de espera de datos y un rollback de v2 a v1. En tiempo de ejecución, monitorea la latencia de recuperación p50/p95/p99, el retraso de materialización (materialization lag), la tasa de faltantes, la tasa de valores por defecto, la tasa de obsoletos, la tasa de discrepancia de versiones y la tasa de discrepancia en la reproducción. El monitoreo del rendimiento del modelo puede exponer las consecuencias, pero no puede reemplazar esta evidencia a nivel de features.

Ejemplo de una Respuesta Sólida

"Definiría un contrato de features antes de elegir una base de datos. Para cada feature, registro la clave de entidad, el tipo, la fuente, la versión de transformación, el tiempo del evento, el tiempo de disponibilidad del sistema, la ventana, el presupuesto de frescura y la regla de degradación. Los eventos sin procesar van a una capa de historial inmutable. El procesamiento en streaming maneja agregados de alta frescura, como el monto de transacciones de una hora; el procesamiento batch maneja dimensiones de cuentas y backfills. Ambos escriben el historial temporal offline y materializan el valor válido más reciente por entidad online.

Los ejemplos de entrenamiento utilizan prediction_at como ancla para los joins point-in-time. Una feature debe satisfacer tanto event_at <= prediction_at como available_at <= prediction_at. Eso excluye los registros que ocurrieron antes pero que aún no habían llegado. Para reproducir el servicio histórico, utilizo un dataset tal como se conocía entonces (as-known); los datos corregidos se mantienen por separado para análisis post-hoc. Las etiquetas de contracargo entran solo después de que madura su ventana de 30 días, y las fuentes de etiquetas nunca ingresan al pipeline de features.

El servicio online recupera aproximadamente 50 valores por entidad y feature_set_version, junto con marcas de tiempo y estados. Los agregados de ventana se precalculan; las features económicas exclusivas de la solicitud se calculan bajo demanda. Los IDs de eventos estables evitan actualizaciones duplicadas, y las versiones tardías más antiguas no pueden sobrescribir valores online más nuevos. Cada feature tiene su propio presupuesto de frescura. Faltante, obsoleto y cero se mantienen distintos. Si una feature crítica de fraude no está disponible, el servicio utiliza un modelo base validado o revisión manual en lugar de rellenar con cero silenciosamente.

El artefacto del modelo fija su versión del conjunto de features. Para la v2, materializo v1 y v2 en paralelo, realizo lecturas en la sombra y comparaciones de reproducción, muevo el modelo solo después de que la cobertura pase su puerta de calidad, y retengo la v1 para rollback. Para demostrar la paridad, muestreo vectores de features online reales con tiempos y versiones, reconstruyo los mismos vectores offline a partir de eventos inmutables y comparo cada valor y estado. Las puertas de lanzamiento también cubren eventos tardíos y desordenados, backfills, fallas del almacén y rollback de versiones. Las métricas en tiempo de ejecución incluyen p99 de recuperación, retraso de materialización, tasas de faltantes/obsoletos, discrepancias de versiones y discrepancias de reproducción.

Si solo hay un modelo batch de bajo tráfico, comenzaría con una transformación versionada y snapshots de entrenamiento inmutables. Introduciría una plataforma completa de features solo cuando múltiples modelos compartan genuinamente features y necesiten tanto recuperación histórica como servicio de baja latencia".

Errores Comunes

• Elegir una base de datos online antes de definir la semántica → el almacenamiento de baja latencia no puede evitar que features con el mismo nombre tengan significados diferentes → crea primero un contrato de features ejecutable.
• Usar únicamente event_at en joins históricos → los registros que llegaron más tarde viajan al pasado → restringe también available_at o reproduce la instantánea histórica.
• Asumir que un feature store compartido garantiza paridad → las rutas de batch y stream aún pueden usar ventanas, valores por defecto o zonas horarias diferentes → demuestra la equivalencia con definiciones compartidas, registros dorados y reproducción.
• Permitir que un resultado tardío sobrescriba el valor online → una ventana más antigua puede hacer retroceder el estado de la entidad → compara marcas de tiempo y versiones de features, y haz que las escrituras sean idempotentes.
• Convertir cada valor faltante en cero → el cero puede ser legítimo, mientras que las caídas de servicio se convierten en señales del modelo → distingue entre faltante, por defecto, obsoleto y cero real.
• Editar una feature publicada directamente en el lugar → los modelos antiguos consumen una nueva semántica sin un cambio de versión → publica una nueva versión y fija las dependencias del modelo.
• Desplegar el modelo antes de que termine el backfill de features → el tráfico inicial ve versiones faltantes o mezcladas → materializa primero, valida la cobertura y luego mueve el modelo.
• Comparar únicamente distribuciones offline y online → distribuciones similares pueden ocultar joins de entidad o límites de ventana incorrectos → reproduce y compara cada feature para la misma solicitud.
• Registrar solo las puntuaciones de predicción → las fallas no se pueden localizar en valores, tiempos o versiones → muestrea vectores reales y sus metadatos.
• Construir una plataforma de features completa para cada caso de uso → un único modelo batch puede absorber una complejidad innecesaria → introduce capacidades de acuerdo con las necesidades reales de uso compartido, historial y latencia.

Preguntas de Seguimiento

Pregunta de seguimiento 1: ¿Por qué no se pueden fusionar el tiempo del evento y el tiempo de disponibilidad?

El tiempo del evento responde "¿cuándo ocurrió esto en el dominio del negocio?" El tiempo de disponibilidad responde "¿cuándo se enteró el sistema?" Los eventos tardíos, las correcciones manuales y los backfills hacen que diverjan. Reproducir una predicción histórica requiere ambos límites temporales; de lo contrario, el modelo utiliza información no disponible en ese momento. Pueden ser iguales si la llegada síncrona es una garantía real y auditable, pero esa suposición no debe tratarse como un hecho por defecto.

Pregunta de seguimiento 2: ¿Deben el procesamiento batch y stream compartir exactamente el mismo código?

El código compartido reduce la divergencia y es preferible, pero no es el único diseño válido. Los motores de ejecución, la gestión de estado o los requisitos de rendimiento pueden requerir dos implementaciones. En ese caso, comparte el contrato y los datos de prueba, verifica la equivalencia con casos dorados, límites y reproducción de eventos históricos, y haz que las pruebas de divergencia sean puertas de lanzamiento.

Pregunta de seguimiento 3: ¿Cómo debe corregir un evento tardío a una feature de ventana online?

Primero define la latencia permitida y las reglas de cierre de ventana. Un evento dentro de ese intervalo se puede deduplicar y actualizar la ventana afectada, mientras que solo una versión de feature más nueva puede sobrescribir el valor online. Los eventos fuera del intervalo entran en un job de corrección o backfill. El hecho de que los datos de entrenamiento pasados cambien depende del modo del dataset: as-known reproduce el servicio pasado, mientras que corrected refleja la verdad más reciente. Almacénalos por separado.

Pregunta de seguimiento 4: ¿Cómo decides si materializar o calcular una feature bajo demanda?

Compara el costo de cómputo, la reutilización, la frescura, la latencia de recuperación y el riesgo de paridad. Un agregado de ventana sobre muchos eventos históricos que se reutiliza intensamente y es sensible a la latencia es un fuerte candidato para la materialización. Una feature económica exclusiva de la solicitud sin necesidad de entrenamiento histórico es una buena candidata para compute-on-read. Incluye el costo de backfill y la superficie de fallas, en lugar de mirar solo el tiempo de CPU para una sola solicitud.

Pregunta de seguimiento 5: ¿Cómo puede cambiar la definición de una feature sin interrumpir el servicio?

Lanza una nueva versión del conjunto de features y materializa las versiones antigua y nueva en paralelo. Valida el esquema y la cobertura, realiza lecturas en la sombra de las entidades online y compara el impacto en el modelo antes de mover una pequeña porción del tráfico al nuevo modelo. Los modelos antiguos permanecen fijados a la versión anterior y los datos antiguos se mantienen durante la ventana de rollback. Nunca reemplaces la semántica in situ bajo el mismo nombre.

Pregunta de seguimiento 6: ¿Qué sucede si los resultados de punto flotante offline y online no son idénticos?

Separa el error numérico aceptable de las diferencias semánticas. Declara tolerancias absolutas o relativas por feature y utiliza las mismas reglas para nulos, zonas horarias, redondeos y límites de ventana. Una diferencia sistemática por entidad o límite debe tratarse como un error. No utilices una tolerancia global amplia para ocultar joins incorrectos, truncamiento de precisión o diferentes órdenes de agregación.

Pregunta de seguimiento 7: ¿Debe el servicio fallar o degradarse cuando el almacén de features online no está disponible?

La decisión depende del riesgo y la capacidad de recuperación. Las recomendaciones de bajo riesgo pueden utilizar brevemente una caché o un ranking base. Las decisiones de fraude de alto riesgo pueden pasar a revisión manual, utilizar una regla conservadora o rechazar solicitudes que no se puedan evaluar de forma segura. La estrategia debe contemplarse en el entrenamiento y los simulacros, registrar el motivo y tener límites de duración y tráfico para que un modo de falla no se convierta en una operación normal.

Pregunta de seguimiento 8: ¿Cómo demuestras que el nuevo pipeline redujo el training-serving skew?

Selecciona solicitudes históricas que cubran casos normales, faltantes, límites de ventana, tardíos y de backfill, y guarda los vectores y versiones online reales. Reconstrúyelos offline en el mismo prediction_at a partir de eventos inmutables, luego compara cada valor y estado. Continúa muestreando la misma conciliación después del lanzamiento y exige que la tasa de discrepancias se mantenga por debajo de una puerta de calidad predefinida. Los gráficos de distribución y las métricas del modelo complementan esta evidencia; no pueden reemplazar la reproducción sobre la misma solicitud.