Español

Llevar Modelos a Producción sin Romperlos

El notebook marcó 0.91 de AUC en su laptop. El modelo ya está en producción, devuelve -infinito para el 3% de las solicitudes, el ingeniero de guardia fue alertado a las 2 a.m. y usted no puede reproducir el entrenamiento original porque nunca fijó la semilla aleatoria. Bienvenido a la brecha entre "el modelo funciona" y "el modelo se despliega".

He visto esta escena repetirse en seis empresas, con cinco stacks de ML diferentes, y el patrón no cambia. Las pérdidas no son algorítmicas. Son operativas. La discrepancia entre entrenamiento y servicio reduce silenciosamente el AUC en producción entre 4 y 7 puntos. Una canalización de características que funcionó ayer emite NaN hoy porque alguien cambió un esquema upstream y no se lo dijo. Ingeniería trata su modelo como una caja negra porque usted trató su servicio como una.

Este es el Playbook que hubiera querido que alguien me entregara antes de mi primer incidente en producción. Cubre las siete cosas que deciden si su modelo se convierte en una línea de ingresos silenciosa o en un tema recurrente de análisis posterior.

Por qué esto importa ahora

La mayoría de los equipos de ciencia de datos pierde entre el 30 y el 50% del valor del modelo entre el AUC offline y el impacto en el negocio online. Eso no es una métrica que inventé. Ejecute los números de sus últimos tres modelos desplegados: incremento offline, incremento online, tiempo desde "mergeado" hasta "completamente activo". La brecha casi siempre tiene forma de problema de personal, no de algoritmo.

El DS que domina la disciplina de reversión, el monitoreo y la interfaz con ingeniería despliega 5 veces más valor que el DS con una arquitectura de modelo marginalmente mejor. La preparación para producción es una disciplina, no una elección de herramientas. Puede hacerlo con AWS Batch y una tabla de Postgres. También puede fallar de forma espectacular con el almacén de características más costoso del mercado.

Canalización de características: Feast vs Tecton vs solución propia

Cada falla de ML en producción que he causado personalmente se remonta a las características. Específicamente: las características con las que entrenó el modelo no eran las características que el modelo veía en el momento de la puntuación. A esto lo llamamos discrepancia entre entrenamiento y servicio, y es el asesino silencioso.

Tres opciones:

Solución propia (tabla de Postgres o vista del almacén). Está bien cuando tiene un modelo, puntuación por lotes, y el mismo SQL produce los datos de entrenamiento y los datos de servicio. La mayoría de las empresas debería empezar aquí y quedarse más tiempo del que cree. La trampa: cuando empieza a agregar características en tiempo real, el SQL que escribió para el entrenamiento (una suma acumulada de 7 días desde el almacén) no es el SQL que ejecuta el servicio de despliegue (un agregado en streaming desde Redis). Divergen. Silenciosamente.

Feast (código abierto). Gratuito, usted lo aloja. Vale la pena cuando tiene 3 o más modelos que comparten características, quiere que la misma definición se use en el entrenamiento y en el servicio online, y está dispuesto a operar Redis/DynamoDB y una canalización de Spark o Flink. El costo real: pasará un trimestre en la incorporación antes de que las características empiecen a fluir. Vale la pena si ya superó la fase de un solo modelo.

Tecton (gestionado). Cómprelo cuando la ingeniería de características sea un cuello de botella real, tenga un presupuesto de $80,000 a $200,000 USD al año y prefiera no ejecutar infraestructura de streaming. Tecton resuelve la discrepancia entre entrenamiento y servicio haciendo que una sola definición produzca tanto backfills como valores online. Su seguimiento de linaje detecta "esta característica cambió el martes pasado" antes de que usted lo haga.

La decisión no es "¿cuál herramienta es mejor?". Es: ¿tengo uno o varios modelos, puntuación por lotes o en tiempo real, y la deriva de características es actualmente invisible para mí? Si sí-sí-sí, necesita un almacén. Si no-no-no, una vista del almacén y un archivo feature_definitions.py que importa tanto en el entrenamiento como en el servicio es más que suficiente.

Reproducibilidad de la canalización de entrenamiento

Si le pidiera que volviera a ejecutar el trabajo de entrenamiento exacto que produjo el modelo en producción ahora mismo, desde los datos brutos, con las mismas divisiones y las mismas métricas, ¿podría hacerlo en 30 minutos?

Si la respuesta es no, no tiene una canalización reproducible. Tiene un souvenir.

Lo que la reproducibilidad realmente requiere:

  1. Fije cada semilla. No solo random_state=42 en la división de entrenamiento y prueba. Fije numpy, fije PyTorch/TensorFlow, fije su muestreador, fije su mezclador de datos, fije cualquier aumento. Depuré un modelo donde dos ingenieros obtuvieron 0.86 y 0.91 de AUC del "mismo notebook" porque el RNG de CUDA de torch no estaba fijado. Tres días perdidos.

  2. Use hash para sus divisiones. No confíe en que train_test_split sea determinista entre versiones de pandas. Calcule un hash estable a partir de un identificador de fila (user_id, transaction_id) módulo el ratio de división. La misma fila, la misma división, para siempre. Bonus: cuando reentrene con datos nuevos, las filas del conjunto de prueba antiguo permanecen en el conjunto de prueba.

  3. Registre el SHA del dataset en el artefacto del modelo. La ficha del modelo debe incluir: SHA-256 del dataset de entrenamiento (después de la ingeniería de características), ventana de entrenamiento (2025-10-01 a 2026-03-31), versión del esquema de características, commit de código, hash del archivo de bloqueo de dependencias, métricas de evaluación en el conjunto de retención, métricas de evaluación en un conjunto de referencia congelado. Esto va en el mismo artefacto de Git LFS o MLflow que los pesos del modelo.

  4. Bloquee el entorno de ejecución. Un requirements.lock, poetry.lock o uv.lock confirmado junto con el modelo. La deriva de versiones de dependencias rompe la reproducibilidad silenciosamente. La diferencia entre scikit-learn 1.3 y 1.4 es suficiente para cambiar las predicciones.

La prueba de "volver a ejecutar el entrenamiento de hace 6 semanas" no es negociable. Si no puede superarla, no puede depurar una regresión de forma creíble. Solo está adivinando.

Servicio por lotes vs en tiempo real: cuándo usar cada uno

La mayoría de los modelos "en tiempo real" deberían ser por lotes. Lo diré dos veces porque siempre se ignora. La mayoría de los modelos "en tiempo real" deberían ser por lotes.

El árbol de decisión:

  • Presupuesto de latencia superior a 1 hora, predicción de cambio lento: lotes nocturnos. Puntúe a todos a las 2 a.m., escriba en una tabla, el producto lee de la tabla. Lead scoring, riesgo de churn, recomendaciones de contenido para usuarios que no son de arranque en frío. Latencia p99: un SELECT.
  • Presupuesto de latencia de 5 a 60 minutos, la predicción necesita frescura horaria: lotes por hora. Misma forma, más frecuente. Pronóstico de inventario, señales de demanda.
  • Presupuesto de latencia de 30 segundos a 5 minutos, depende de la actividad de la sesión: microlotes. Un consumidor de streaming puntúa en lotes de 100 a 1,000 registros cada 30 segundos. Señales de fraude, detección de anomalías donde la acción puede esperar un minuto.
  • Presupuesto de latencia inferior a 200 ms, solicitud impredecible: tiempo real. Ranking de anuncios, relevancia de búsqueda, bloqueos de fraude en el checkout, personalización en tiempo real. Este es el costoso. El presupuesto de latencia p99 debe establecerse en el contrato de interfaz antes de entrenar, no después de desplegar.

La diferencia de costo es enorme. Un trabajo de lotes nocturno se ejecuta en una sola instancia grande durante una hora. Un servicio en tiempo real necesita autoescalado, grupos calientes, monitoreo p99 y un SRE en rotación. Elija lotes a menos que tenga una razón real para no hacerlo.

Una historia de advertencia: desplegamos un modelo de recomendación "en tiempo real" que llamaba a Postgres de forma síncrona para tres búsquedas de características por solicitud. La latencia p99 llegó a 4 segundos antes de que lo detectáramos. La solución no fue un Postgres más rápido. Fue admitir que el modelo no necesitaba ser en tiempo real, moverlo a lotes y servirlo desde una tabla precomputada. La latencia bajó a 8 ms. El equipo de producto no notó el cambio porque las recomendaciones no dependían realmente de la sesión.

Monitoreo del modelo: deriva, cambio de concepto, métrica de negocio

Cuatro cosas que monitorear. Tres son diagnósticas. Solo una paga las facturas.

Deriva de entrada. ¿Las características que ve el modelo hoy están distribuidas como las características con las que fue entrenado? Rastree el Índice de Estabilidad de Población (PSI) por característica, diariamente. PSI mayor a 0.1: investigue. PSI mayor a 0.25: su distribución de entrenamiento y su distribución en producción ya no son las mismas. Genere una alerta. Para características continuas, también ejecute una prueba de Kolmogorov-Smirnov contra una ventana de referencia. Barato, rápido, detecta rupturas de esquema antes de que las predicciones empeoren.

Deriva de predicción. ¿Las salidas del modelo están distribuidas como la semana pasada? A veces la deriva de entrada es invisible (las interacciones de características cambian) pero la deriva de predicción es evidente. Rastree p10/p50/p90 de la salida del modelo diariamente.

Deriva de concepto (con conciencia del retraso de etiquetas). ¿Ha cambiado la relación entre las características y la etiqueta? Solo puede verificar esto cuando lleguen las etiquetas, lo cual para muchos modelos ocurre días o semanas después. Construya una canalización de evaluación diferida: cuando lleguen las etiquetas, recalcule AUC/MAE en esas filas y grafíquela a lo largo del tiempo. La trampa es generar alertas sobre AUC el día después del despliegue cuando aún no tiene etiquetas. Solo estará mirando un 0.

La métrica de negocio. Ingresos. Tasa de conversión. CAC. Valor de vida del cliente. La cosa que el modelo existe para mover. Esta es la única métrica que decide si el modelo permanece activo. Los umbrales de alerta sobre la deriva de entrada y predicción son diagnósticos. Los umbrales de alerta sobre la métrica de negocio son existenciales.

He visto equipos desplegar un modelo con Dashboards de deriva perfectamente calibrados y cero visibilidad sobre si los ingresos se movieron. No sea ese equipo. El primer Dashboard es el de negocio. Los Dashboards de deriva existen para explicar por qué se movió la métrica de negocio, no para sustituirla.

El despliegue en "modo sombra"

Puntúe pero no actúe. Durante una o dos semanas. Con el mismo tráfico. Compare las predicciones del nuevo modelo contra las predicciones del modelo vigente y contra los resultados reales cuando lleguen las etiquetas.

Esta es la práctica de mayor impacto que conozco en ML de producción, y la mayoría de los equipos la omite.

El flujo del despliegue en modo sombra:

  1. Despliegue el nuevo modelo junto al modelo vigente. Ambos puntúan cada solicitud. Solo las predicciones del modelo vigente afectan el comportamiento del producto.
  2. Registre ambas predicciones más todas las características usadas.
  3. Después de 7 a 14 días, compare:
    • Superposición de distribución: ¿están los dos modelos haciendo predicciones similares sobre las mismas entradas? Si el 30% difiere, averigüe por qué antes de cambiar.
    • Comparación con las expectativas offline: ¿el comportamiento online del nuevo modelo coincide con lo que predijo su evaluación en el conjunto de retención? Si offline decía +5% de incremento y el modo sombra dice que son idénticos, sus datos de entrenamiento tenían fuga de datos.
    • Latencia, tasa de errores, casos extremos (entradas NaN, características faltantes): ¿el nuevo modelo maneja la cola larga?
  4. Solo cambie el interruptor cuando los datos del modo sombra confirmen la historia offline.

El enfoque campeón/retador es la misma idea, formalizada. El modelo vigente es el campeón. El nuevo modelo es el retador. No promueve al retador hasta que haya ganado bajo tráfico real, no solo en un conjunto de prueba.

El despliegue en sí debe ser gradual: 1% a 5% a 25% a 50% a 100%, con al menos 24 a 48 horas entre pasos y la métrica de negocio monitoreada en cada etapa. Si algo se mueve en la dirección equivocada, haga una pausa. No lo racionalice.

Patrones de colaboración con ingeniería: contratos de interfaz

El modelo de "lanzar el pickle por encima del muro" falla siempre. Esto es lo que funciona en su lugar.

Antes de comenzar el entrenamiento, siéntese con el ingeniero de plataforma y escriba un contrato de interfaz de una página. Cubre:

  • Esquema del API. Campos de entrada, tipos, nulos permitidos, reglas de validación. Campos de salida, tipos, rangos. ¿Cómo se ve la respuesta cuando el modelo no puede puntuar (características faltantes, servidor del modelo caído)?
  • SLO de latencia. p50, p95, p99 en milisegundos. Esto determina si puede hacer búsquedas de características en tiempo real, qué arquitecturas de modelo están descartadas, si se requiere inferencia en GPU.
  • SLO de rendimiento. Solicitudes por segundo en el pico. Configura el autoescalado.
  • Presupuesto de errores. ¿Qué porcentaje de solicitudes puede fallar el servicio? ¿0.1%? ¿1%? Esto establece el nivel de exigencia de la validación de entrada.
  • Límite de propiedad. ¿Quién recibe la alerta cuando el modelo devuelve predicciones incorrectas vs cuando el servicio devuelve errores 500? DS es dueño del primero. Ingeniería es dueña del segundo. Ambos son dueños del tercero (el modelo está activo pero las predicciones son malas).
  • Autoridad de reversión. ¿Quién puede activar el interruptor de emergencia sin escalar? A las 3 a.m., la respuesta debe ser "el ingeniero de guardia", no "alerte a Camellia".

Anótelo. Fírmelo. Fíjelo en un lugar visible. Cuando ocurra el inevitable incidente en producción, el contrato es lo que mantiene la conversación enfocada en solucionar el problema en lugar de negociar responsabilidades.

El DS que llega a esa reunión con un borrador del contrato gana confianza en el momento en que entra. El DS que llega con un notebook y pregunta "¿cómo desplegamos esto?" empieza desde cero.

Disciplina de reversión

Cada despliegue incluye un camino de reversión probado. No documentado. Probado.

Tres componentes:

  1. Etiquetado de versiones. Cada modelo recibe una versión (pricing-model-v23). Cada predicción registrada incluye la versión que la puntuó. Cuando investiga una regresión, puede filtrar por versión.
  2. El interruptor de emergencia. Un flag de configuración que cambia el tráfico del nuevo modelo al anterior en menos de 60 segundos. No una redistribución. Un cambio de flag. El servicio de despliegue lee el flag en el momento de la solicitud.
  3. Ejercicios de reversión. Cada trimestre, ejercite la reversión en producción durante 5 minutos durante una ventana de bajo tráfico. Si no ha ejecutado el proceso en 90 días, la reversión es teórica, lo que significa que no funciona.

La primera vez que necesite una reversión no es el momento para descubrir que el artefacto del modelo anterior fue eliminado de S3, que la canalización de características fue refactorizada, o que el interruptor de emergencia nunca funcionó. Yo he vivido personalmente los tres.

Errores comunes

  • Entrenar con datos que el modelo no puede ver en el momento del servicio. Fuga de datos. La forma más común: una característica que solo es calculable después del evento que está prediciendo. Una característica de "días desde el último inicio de sesión" calculada desde el almacén incluirá inicios de sesión posteriores al timestamp de la predicción a menos que lo corte explícitamente.
  • Fijar random_state=42 pero no fijar el muestreador upstream. Sus divisiones son deterministas, su entrenamiento no lo es.
  • Desplegar sin campeón/retador. Está adivinando si el nuevo modelo es mejor.
  • Alertar sobre AUC en lugar de ingresos. El AUC bajó de 0.84 a 0.82: ¿es malo? No lo sabe. Tal vez los ingresos subieron.
  • Sin prueba de reversión en 90 días. No tiene una reversión. Tiene un deseo.
  • Tratar a ingeniería como una mesa de servicio en lugar de un socio. Tratarán su modelo de la misma manera.

Plantillas y herramientas

Los cuatro documentos que todo modelo desplegado debe tener:

  • Ficha del modelo. SHA del dataset, ventana de entrenamiento, semilla, versión del esquema de características, métricas de evaluación en el conjunto de retención y en el conjunto de referencia congelado, SLO de servicio, propietario, fecha de despliegue, procedimiento de reversión.
  • Lista de verificación de comparación en modo sombra. Superposición de distribución, coincidencia offline-online, latencia, tasa de errores, manejo de casos extremos, requisitos de aprobación por parte interesada.
  • Runbook de reversión. Paso a paso para activar el interruptor de emergencia, cómo verificar que el modelo anterior está sirviendo tráfico, a quién notificar, plantilla de análisis posterior.
  • Contrato de interfaz ingeniería/DS. Una página. Esquema del API, SLOs, presupuesto de errores, límite de propiedad, autoridad de reversión. Firmado por DS, líder de ingeniería y la rotación de guardia.

Cómo medir el éxito

Usted lo está haciendo bien cuando:

  • Puede volver a ejecutar el entrenamiento exacto de cualquier modelo en producción desde los datos brutos en menos de 30 minutos.
  • Cada despliegue tiene una reversión probada que se ha ejercido en los últimos 90 días.
  • El monitoreo detecta la deriva antes de que se mueva la métrica de negocio, no después.
  • Su ingeniero de plataforma dice "trabajar contigo es fácil" sin que nadie se lo pida.
  • Los últimos tres despliegues fueron aburridos.

Los despliegues aburridos son el objetivo. El drama es un fracaso. El DS que despliega de forma aburrida es el DS que despliega con frecuencia, y el DS que despliega con frecuencia acumula valor más rápido que cualquiera con una arquitectura de modelo marginalmente mejor.

Aprenda Más