Contexto
Una buena métrica offline no demuestra que el sistema pueda responder cuando llegan muchos eventos, faltan fuentes o cambia el contexto operacional.
La arquitectura final debe elegirse después de comparar alternativas reproducibles. El coste y la mantenibilidad forman parte del resultado, no son tareas posteriores.
Ejemplo didáctico · situación inventada
Una predicción correcta que llega después de la decisión
El modelo supera la referencia offline. Bajo concurrencia, la cola de ingestión retrasa los eventos y la respuesta llega cuando ya se ha cerrado la ventana operativa.
Qué decisión cambia. Mide desde la recepción del evento hasta la entrega utilizable, incluyendo colas y reintentos. Define una salida degradada o una abstención cuando venza el plazo; acelerar solo la inferencia puede no resolver el cuello de botella.
Qué comprobar antes de empezar
- Evento que dispara la predicción y horizontes que debe cubrir.
- Momento real de disponibilidad de cada dato, no solo su fecha nominal.
- Baseline y partición temporal reservada para la aceptación.
- Regímenes de alta carga, casos poco frecuentes y segmentos críticos.
- Latencia máxima, concurrencia y respuesta ante entradas inválidas o tardías.
- Artefactos necesarios para reproducir, vigilar y reentrenar una versión.
Método de trabajo
Reconstruir el instante
Cada ejemplo conserva qué datos estaban disponibles y qué versión de las fuentes produjo la decisión.
Comparar en el tiempo
Las alternativas se evalúan contra el baseline en periodos futuros y en escenarios de carga separados.
Elegir arquitectura
Solo continúan los componentes cuya mejora compensa su latencia, coste y dificultad de mantenimiento.
Probar el servicio
Repetimos escenas históricas y medimos ingestión, inferencia concurrente, errores, telemetría y recuperación.
Promover con evidencia
Datos, código, configuración, métricas y contenedor quedan unidos a un identificador antes de aceptar una versión.
Señales para detener la prueba
- La evaluación utiliza datos que en operación llegarían después de la predicción.
- La media global oculta una degradación relevante en alta carga o casos críticos.
- El servicio no cumple latencia o pierde eventos cuando aumenta la concurrencia.
- No se puede reconstruir qué datos, código y configuración generaron una salida.
- No existe una respuesta acordada para datos tardíos, deriva o pérdida de calibración.
Para seguir con esta decisión
- ¿Cómo validar mantenimiento predictivo cuando hay pocas averías?
- ¿Cómo evaluar un modelo predictivo cuando el servicio se satura?
- ¿Cómo saber si el intervalo de una predicción es fiable?
Servicio de Machine learning y modelos predictivos: alcance y entregables
Publicado por Ordantis el .