Último consumidor del curso: el modelo tabular en producción — el ML clásico que decide si la transacción parece fraude o qué cliente va a fugarse — que necesita sus features (las variables calculadas que el modelo consume: “compras de los últimos 30 días”, “días desde el último reclamo”) disponibles en milisegundos al momento de predecir. Este módulo cierra el puente con MLOps: aquel curso presentó el feature store desde el ciclo del modelo; este lo construye desde el ciclo del dato — y agrega la pregunta que el vendedor no hace: cuándo no lo necesitas.

La tesis del módulo

El problema que justifica toda esta maquinaria tiene nombre: training/serving skew — la feature calculada de una forma para entrenar (SQL tranquilo sobre el warehouse) y de otra para servir (código apurado en la API) diverge tarde o temprano, y el modelo en producción recibe variables distintas de las que aprendió. El feature store lo resuelve con una idea: definir cada feature una sola vez, y que de esa definición única se sirvan tanto el entrenamiento (offline, histórico) como la predicción (online, en milisegundos). Todo lo demás es plomería de esa idea.

El bug más caro: el skew contado en dos actos

Acto 1 — entrenamiento: el data scientist calcula compras_30d con SQL sobre el warehouse (módulo 5): limpio, con toda la historia. El modelo aprende y evalúa bien.

Acto 2 — producción: el equipo de la API necesita esa misma feature en 20 ms. El warehouse no responde a esa velocidad, así que reimplementan el cálculo en el servicio — otra fuente, otro lenguaje, otras decisiones de borde (¿30 días calendario o hábiles? ¿incluye la compra en curso? ¿zona horaria?). La divergencia es invisible en el despliegue y letal en la acumulación: el modelo recibe features sutilmente distintas de las que aprendió, degrada sin mensaje de error, y el diagnóstico (¿deriva? ¿datos? ¿modelo?) consume semanas — porque el bug no está en ningún lugar: está entre dos lugares.

El feature store: definir una vez, servir dos veces

La pieza (Feast como el estándar open source; Tecton, SageMaker/Vertex/Databricks Feature Store como administrados) organiza tres componentes:

   EL FEATURE STORE — UNA DEFINICIÓN, DOS TIENDAS

        definición única de la feature
        "compras_30d = suma de compras
         del cliente en ventana de 30d"
                    │
        ┌───────────┴───────────┐
        ▼                       ▼
  ┌────────────┐         ┌────────────┐
  │ tienda     │         │ tienda     │
  │ OFFLINE    │         │ ONLINE     │
  │ (lakehouse:│         │ (Redis/    │
  │ historia   │         │ DynamoDB:  │
  │ completa)  │         │ el valor   │
  └─────┬──────┘         │ actual, ms)│
        │                └─────┬──────┘
        ▼                      ▼
  entrenamiento          predicción en
  point-in-time          producción
  (sin futuro)           (sin skew)

La tienda offline vive en el lakehouse del módulo 4: la historia completa de cada feature, para armar datasets de entrenamiento.
La tienda online es el caché caliente de la serie cloud (Redis/DynamoDB): el valor actual de cada feature por entidad, servido en milisegundos. Se puebla desde las mismas definiciones — por batch programado (módulo 6) para features que toleran horas, por streaming (módulo 3) para las que el caso exige al minuto — el árbol batch/streaming, aplicado feature por feature.
El registro es el catálogo: qué features existen, su definición, su dueño, quién las usa — el linaje del módulo 2 para variables de modelo, y la pieza que habilita la reutilización (el segundo modelo que necesita compras_30d la toma del catálogo en vez de reinventarla con otros bordes).

Point-in-time: no entrenar con el futuro

El segundo problema serio que la tienda offline resuelve — y que el dataset artesanal comete por defecto: al armar ejemplos históricos, cada fila debe llevar el valor de la feature como era en el momento del evento, no el actual. El ejemplo canónico: entrenas en septiembre un modelo de fuga con datos de marzo — si compras_30d sale de la tabla actual, la fila de marzo lleva información de agosto: fuga temporal (data leakage), el modelo “aprende” con datos del futuro, la métrica de validación brilla y producción decepciona. La tienda offline con point-in-time correctness hace el join correcto por diseño: para cada evento del pasado, el valor vigente entonces. Es la fuga del módulo 8 en su versión temporal — y la más difícil de detectar a ojo, porque el dataset se ve perfectamente normal.

Ojo — cuándo NO necesitas un feature store: la maquinaria se justifica por el problema, y el problema tiene condiciones: predicción online con latencia de milisegundos + features que también sirven para entrenar + idealmente varios modelos compartiendo variables. Si tu modelo puntúa por batch nocturno (la mayoría de los casos de churn, priorización, scoring), no hay tienda online que necesitar: las features son marts del módulo 5, el point-in-time se resuelve con SQL cuidadoso sobre el lakehouse, y el “feature store” es una carpeta de modelos dbt bien testeados. Adoptar Feast para un batch nocturno es el streaming-por-currículum del módulo 3 con otro logo. El caso del curso lo ilustra: el triaje de correos usa el contexto del propio correo (sin features online), y la única candidata real sería un scoring de prioridad por cliente — que tolera batch horario. Veredicto honesto: marts, no store.

Errores comunes

Reimplementar la feature en la API. El acto 2 del skew: dos cálculos, dos verdades, un modelo confundido. La definición es una — o hay store, o la misma transformación sirve a ambos caminos.
Dataset histórico con valores actuales. La fuga temporal que infla la validación y decepciona en producción. Point-in-time correctness: cada fila con el valor vigente en su momento.
Feature store para modelos batch. La tienda online sin consumidor online es infraestructura de currículum. Marts + SQL point-in-time cubren el caso batch con la disciplina que ya tienes.
Features sin dueño ni catálogo. La misma variable reinventada tres veces con tres bordes distintos — el skew multiplicado por copias. El registro con dueño es la mitad del valor de la pieza.
Streaming para toda feature online. La tienda online se puebla al ritmo que cada feature exige: batch frecuente para lo que tolera horas, streaming solo donde minutos cambian la predicción. El árbol del módulo 3, feature por feature.
Monitorear el modelo y no las features. La feature rota (fuente cambió, pipeline atrasado) degrada al modelo con silencio de datos. Las features llevan la calidad del módulo 7 — frescura, rangos, distribución — como todo dato servido.

La frase para llevarse

“El skew nace de calcular dos veces lo que debía definirse una: si sirves predicciones en milisegundos, el feature store une entrenamiento y producción en una definición; si puntúas por batch, tus features son marts y la maquinaria extra es un logo. Y en ambos mundos: nunca entrenes con el futuro — el point-in-time no es un lujo, es la diferencia entre validar y alucinar.”

Qué viene

Módulo 12, el cierre: gobernanza, linaje y costo. El pipeline completo funciona; falta que sobreviva a la organización: el catálogo que responde “¿qué datos tenemos y qué significan?”, el linaje de punta a punta que responde “¿de dónde salió esto y a quién rompo?”, la clasificación y los accesos que el cumplimiento exige, y el FinOps del pipeline — porque el 80% del trabajo también es el 80% de una factura que alguien debe poder leer.

Data Engineering — Módulo 11: features y tiempo real