¿Qué es el desajuste entre entrenamiento y serving?

Respuesta directa

Qué debe cubrir una buena respuesta

Cómo funciona

El desajuste surge cuando las entradas que el modelo ve en producción se calculan de forma distinta a las de entrenamiento: una feature implementada dos veces, en SQL para entrenar y en Python para servir, un valor por defecto que difiere, una marca de tiempo que significa tiempo de evento en un sitio y de proceso en otro, o una distribución que cambia porque la población servida difiere de la muestra de entrenamiento. El modelo corre y devuelve números, pero su exactitud se degrada en silencio. La prevención es estructural: una única implementación de cada transformación compartida por ambas rutas, joins en el tiempo para los datos de entrenamiento, esquemas de features versionados y una prueba de paridad que puntúa los mismos registros por ambas rutas y compara.

Ejemplo

Un modelo de fraude entrenó con una feature definida como transacciones en las últimas 24 horas calculada por un job batch a medianoche, mientras la ruta de serving la calculaba como ventana móvil de 24 horas en tiempo real; ambas discrepaban la mayor parte del día y el recall en producción estaba 20 puntos por debajo de la validación. Pasar ambas a una definición compartida materializada por el mismo código y añadir una comprobación diaria de paridad sobre 1.000 registros muestreados cerró la brecha.

Errores frecuentes

• Reimplementar la lógica de features en el lenguaje de serving y suponer que coincide.
• Entrenar con features calculadas al final del día para predicciones hechas por la mañana.
• No comparar nunca los valores de features en producción con los de entrenamiento para los mismos registros.

Una estructura útil para responder

Responde desde tu propia experiencia.

No memorices un guion: usa solo ejemplos que puedas explicar con honestidad en preguntas posteriores.