Diagrama de arquitectura MLOps: de los datos de entrenamiento a un modelo monitorizado

Un modelo en un notebook no es un sistema. La famosa figura de Hidden Technical Debt in Machine Learning Systems (Sculley et al., NeurIPS 2015) lo muestra con cajas: solo una pequeña parte de un sistema de ML real es código de ML. El resto es recogida de datos, extracción de características, servicio, monitorización y la fontanería que hay entre todo ello, y de ahí salen los problemas en producción.

Un diagrama de arquitectura MLOps dibuja ese resto. Este artículo construye uno para un modelo de puntuación de fraude, explica los dos bucles que tiene todo modelo en producción y enumera qué etiquetar para que el diagrama responda a las preguntas que surgen cuando un modelo se comporta mal.

Dos bucles y un disparador

Todo modelo en producción tiene un bucle de entrenamiento y un bucle de servicio:

• Bucle de entrenamiento. Los datos se recogen, se convierten en características, se usan para entrenar un candidato, se comparan con el modelo actual y se registran.
• Bucle de servicio. Llega una petición, se consultan las características, el modelo la puntúa y la predicción se registra.
• El disparador conecta ambos. La monitorización del bucle de servicio, una programación o los datos nuevos vuelven a iniciar el bucle de entrenamiento.

La guía de MLOps de Google describe tres niveles de madurez: el nivel 0 es un proceso manual, el nivel 1 automatiza el pipeline de entrenamiento para el entrenamiento continuo y el nivel 2 añade CI/CD para el propio pipeline. Dibuja el nivel que tienes, no el que planeas, y marca los pasos manuales.

El desfase entre entrenamiento y servicio

El error que un diagrama MLOps evita con más frecuencia es el desfase entre entrenamiento y servicio (training-serving skew): una característica calculada de una forma en el SQL de entrenamiento y de otra en el código de servicio. El modelo parece bueno offline y peor en producción, y nadie sabe decir por qué. La misma guía de Google recomienda un feature store como única fuente para la experimentación, el entrenamiento continuo y el servicio en línea, de modo que cada característica tenga una sola definición.

El segundo error clásico es la fuga a través del tiempo. Una fila de entrenamiento para un pago debe usar los valores de las características tal como eran en el momento de ese pago, no como son hoy. Escribe este requisito de punto en el tiempo (point-in-time) en la conexión entre el feature store y el pipeline de entrenamiento.

El ejemplo: puntuación de fraude para pagos con tarjeta

Una API de pagos pide a un modelo una puntuación de fraude antes de autorizar un pago con tarjeta. El diseño:

1. Eventos. La API de pagos publica cada pago en Kafka. Un trabajo de streaming mantiene características móviles, como los pagos por tarjeta en la última hora, en un almacén en línea. Los mismos eventos llegan al almacén de datos.
2. Etiquetas. Que un pago era fraude se sabe por los contracargos, que llegan semanas o meses después. Se cargan en el almacén de datos y se cruzan con los pagos originales.
3. Características. El feature store define cada característica una vez, calcula los valores offline a partir del almacén de datos y materializa los últimos valores en el almacén en línea.
4. Entrenamiento. Un pipeline orquestado construye un conjunto de entrenamiento en un punto en el tiempo, valida los datos, entrena un candidato, lo compara con el modelo en producción sobre el mismo conjunto de evaluación y lo registra con sus métricas.
5. Lanzamiento. Una versión aprobada se despliega en el endpoint de puntuación, primero en modo sombra, puntuando copias del tráfico real sin afectar a las decisiones, después para una pequeña parte del tráfico y después para todo.
6. Monitorización. Cada puntuación se registra con sus características. La monitorización compara las distribuciones de entradas y puntuaciones con los datos de entrenamiento y, a medida que llegan las etiquetas, calcula la precisión y la exhaustividad. Una alerta de deriva o de calidad inicia el reentrenamiento.

Cómo leerlo:

• Fila superior, el entrenamiento. Las etiquetas de contracargos y el historial de eventos se juntan en el almacén de datos. El feature store construye conjuntos de entrenamiento para el pipeline, que registra candidatos en el registro de modelos.
• Fila inferior, el servicio. La API de pagos publica eventos en Kafka y llama al endpoint de puntuación de forma síncrona. El endpoint lee las características del almacén en línea y escribe cada puntuación en el registro de predicciones.
• La conexión del registro es la única vía por la que un modelo llega a producción: una versión aprobada, nunca un archivo copiado desde un notebook.
• A la derecha, el bucle de vuelta. La monitorización lee las predicciones y las etiquetas tardías. La deriva o una caída de calidad generan una alerta que inicia el pipeline de entrenamiento.

Qué etiquetar

• Las reglas de punto en el tiempo en la conexión del conjunto de entrenamiento.
• La versión y la etapa del modelo en el endpoint y en el registro.
• Los presupuestos de latencia para consultar características y puntuar, porque el pago los espera.
• El retraso de las etiquetas. Si las etiquetas tardan semanas, dilo: eso decide lo rápido que puedes medir la calidad.
• Los disparadores de reentrenamiento: programación, umbral de deriva, volumen de datos.
• Los responsables. Datos, características, modelos y endpoint suelen pertenecer a equipos distintos.

Errores comunes

• Una sola caja llamada "modelo de ML". Oculta el feature store, el registro y el bucle de monitorización, que es donde empiezan los incidentes.
• Sin camino de vuelta. Si las etiquetas nunca vuelven, nadie sabe cuándo empeoró el modelo.
• Notebooks en el camino de producción. Un modelo solo debería llegar al servicio a través del pipeline y del registro.
• Dos implementaciones de una característica. Un SQL de entrenamiento y un código de servicio que calculan "el mismo" valor de forma distinta provocan desfase.
• Sin vuelta atrás. Guarda la versión anterior en el registro y dibuja cómo vuelve a ella el endpoint.
• Monitorizar solo la infraestructura. La latencia y la tasa de errores pueden ser perfectas mientras el modelo se equivoca; monitoriza también entradas, puntuaciones y resultados.

El lado del servicio es trabajo normal de sistemas distribuidos. El diagrama de arquitectura orientada a eventos cubre la parte de Kafka y, para modelos de lenguaje con recuperación, el diagrama de arquitectura RAG cubre la indexación y el servicio.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama.
2. Del pack ML, añade un Almacén de características, un Modelo para el registro y un Punto de conexión para la puntuación.
3. Del pack Datos, añade Kafka, un Almacén de datos, Redis para el almacén en línea y un Tema para el registro de predicciones.
4. Del pack DevOps, añade una Canalización para el entrenamiento, un nodo Métricas para la monitorización del modelo y una Alerta como disparador del reentrenamiento.
5. Añade un Contenedor del pack Modelo C4 para la API de pagos y un Sistema externo para los contracargos de la red de tarjetas.
6. Conéctalos, etiqueta cada conexión con los datos que lleva y haz discontinuas las etiquetas tardías y el disparador de reentrenamiento. Añade un bloque Markdown del pack Básico con los pasos del lanzamiento.

El ejemplo usa 13 nodos de diagrama, dentro del plan Free. Con un agente de IA conectado por MCP puedes describir el pipeline, dejar que coloque los nodos y después ajustar las etiquetas.

Preguntas frecuentes

¿Necesito un feature store? No el primer día. Necesitas una definición por característica que usen tanto el entrenamiento como el servicio. Un feature store es la forma habitual de conseguirlo cuando varios modelos comparten características o necesitas características frescas en línea.

¿Qué diferencia hay entre un registro de modelos y un almacén de artefactos? Un almacén de artefactos guarda archivos. Un registro añade versiones, métricas, linaje y un estado de aprobación, para que el paso de despliegue pueda pedir la versión aprobada en lugar de una ruta.

¿Cada cuánto hay que reentrenar un modelo? Tan a menudo como los datos cambien de forma relevante. Empieza con una programación, añade disparadores de deriva y de calidad cuando tengas monitorización y registra por qué se ejecutó cada reentrenamiento.

¿Cómo monitorizo un modelo cuando las etiquetas llegan tarde? Vigila lo que ya puedes ver, como la distribución de las entradas, la de las puntuaciones y la proporción de pagos marcados, y calcula la precisión y la exhaustividad cuando lleguen las etiquetas. Dibuja ambos caminos.

¿Deberían compartir infraestructura el entrenamiento y el servicio? Pueden compartir las definiciones de características y el registro, pero tienen perfiles de carga distintos. Dibújalos como caminos separados que se encuentran en el feature store y en el registro.

Empieza gratis — un puesto, sin tarjeta de crédito.