Cómo actualizar modelos de IA sin detener la plataforma | MLOps

Patrones de MLOps, microservicios y eventos para actualizar modelos de churn sin detener servicios críticos de una plataforma de telecomunicaciones.

Este artículo también está disponible en inglés.
Cómo actualizar modelos de IA sin detener la plataforma | MLOps

Si para actualizar el modelo de churn hay que apagar toda la plataforma, el problema no es el modelo 🔧

Por qué una actualización de IA puede detener la plataforma

Se cree que en telecomunicaciones la IA falla por datos insuficientes. En la mayoría de los casos falla porque la arquitectura no permite que la predicción llegue a quienes deben actuar. No es un problema de datos, es un problema de estructura.

Las telecomunicaciones combinan alto volumen, múltiples canales y decisiones que no esperan. Un operador detectando una falla, un agente en una reclamación y un portal de autoservicio comparten infraestructura pero sirven a propósitos distintos. Cuando esa infraestructura no puede moverse por partes, la IA pierde la velocidad que necesita para ser útil.

Imagina una plataforma donde churn, autoservicio y tickets comparten código. Mejorar el modelo de abandono obliga a congelar despliegues, coordinar con otros módulos y planear una ventana de mantenimiento. El cliente que iba a cancelar lo hace mientras el equipo espera la aprobación. No es falta de análisis, es incapacidad de actuar.

Microservicios y model serving para despliegues independientes

Ahí es donde los microservicios, donde cada capacidad del negocio vive como componente separado que puede actualizarse sin detener los demás, cambian el escenario. El modelo de churn se reentrena y despliega sin que el portal ni los tickets sepan que algo cambió. En una encuesta de IBM de 2021 a más de 1.200 desarrolladores y líderes de TI, el 87% de quienes usaban microservicios consideró que la adopción justificaba el costo y el esfuerzo.

BFF y arquitectura orientada a eventos

Pero separar servicios no resuelve todo. Una app móvil, un portal web y un agente no necesitan el mismo formato de respuesta. El patrón BFF, del inglés Backend for Frontend, coloca una capa que adapta la respuesta al canal que la solicita. Así el modelo de incidentes entrega lo justo al agente en la llamada sin saturar otros canales.

Lo mismo ocurre cuando la red detecta una anomalía o facturación identifica un patrón inusual. Una arquitectura orientada a eventos permite que esa señal llegue a quien la necesita sin paralizar el resto. El informe de NVIDIA de 2024 encontró que el 90% de más de 400 profesionales de telecomunicaciones encuestados estaba evaluando, probando, implementando o usando IA. La pregunta no es cuántas organizaciones empezaron, sino cuántas logran que la IA actúe a tiempo.

Si para actualizar el modelo de churn hay que apagar toda la plataforma, el problema no es el modelo.

YouTube — Microservices Architecture Explained

Patrón operativo para actualizar modelos sin downtime

Primero, separar las capacidades en componentes que evolucionen sin coordinación masiva. Luego, conectar esos componentes por eventos para que la información fluya sin que nadie la solicite. Después, adaptar la respuesta al canal que consume la inteligencia. Por último, gobernar con visibilidad centralizada para que la autonomía no se vuelva opacidad.

Fuentes

Explora el hub de IA en Producción →