Documento AI
MLOps sin la palabra de moda: lo que realmente se necesita para mantener en funcionamiento un sistema AI
Vincent Wahidi
MLOps es la disciplina de mantener útil un sistema de aprendizaje automático después de su lanzamiento. En términos sencillos, cubre cuatro tareas: monitoreo (ver si el modelo aún funciona en el mundo real), reentrenamiento (actualizándolo a medida que cambian los datos), control de versiones (saber exactamente qué modelo y datos produjeron qué resultado) y la instalación de implementación que envía una nueva versión de manera segura. Un modelo no es un producto terminado el día que entra en funcionamiento. Es un componente perecedero que se encuentra dentro de un sistema que debe ser alimentado, vigilado y corregido. MLOps es el nombre de ese trabajo en curso. Si se ignora, el modelo se desvía silenciosamente de la realidad, la precisión disminuye y, una mañana, las predicciones son erróneas de maneras que nadie está comprobando. El lanzamiento es el comienzo del trabajo, no el final del mismo.
¿Qué significa realmente MLOps en producción?
MLOps es lo que DevOps es para el software común, adaptado al hecho de que un modelo depende de datos, no solo de código. Una aplicación normal se comporta hoy de la misma manera que el día que la envió, hasta que alguien cambia el código. Un modelo no. El mundo del que aprendió sigue moviéndose, por lo que su precisión puede degradarse mientras cada línea de código permanece intacta.
Esa diferencia es el punto. Con el software que usted pregunta, ¿todavía se ejecuta? Con un modelo también hay que preguntar si todavía se mantiene. MLOps es el conjunto de prácticas y herramientas que le permiten responder la segunda pregunta todos los días, no una vez al trimestre cuando un cliente se queja.
¿Cuál es el trabajo después del lanzamiento de un modelo?
El trabajo del segundo día se divide en cuatro trabajos recurrentes. Ninguno de ellos es glamoroso, y todos ellos son los que separan a un sistema que se gana la vida de otro que se pudre.
- Monitoreo. Realice un seguimiento de las entradas y salidas del modelo en producción. Esté atento a la desviación de los datos (los datos en vivo comienzan a verse diferentes de los datos de entrenamiento) y a la caída de la precisión en comparación con los resultados reales una vez que se conocen. La alerta que desea es la que se activa antes de que el cliente se dé cuenta, no después.
- Reentrenamiento. Cuando el rendimiento disminuye o los datos se han movido claramente, actualice el modelo con datos más nuevos y envíe la actualización. Decida de antemano si esto se desencadena por una métrica que cruza una línea o se ejecuta según un cronograma, y conviértalo en una rutina, no en un simulacro de incendio.
- Control de versiones. Registre qué versión del código, los datos y el modelo entrenado produjeron un resultado determinado. Cuando se cuestiona una salida, es necesario reconstruir exactamente lo que se ejecutó. Sin esto, toda investigación parte de conjeturas.
- Validación e implementación. Pruebe un nuevo modelo con el actual antes de que llegue al tráfico real, libérelo gradualmente y mantenga un camino rápido de regreso a la versión anterior si tiene un rendimiento inferior.
Esta es la misma disciplina de ingeniería que convierte un piloto en un sistema que sobrevive al contacto con usuarios reales. La demostración demuestra que el modelo puede funcionar una vez. Este trabajo demuestra que sigue funcionando.
¿Por qué los sistemas AI se pudren sin MLOps?
Porque los datos que hay debajo nunca dejan de cambiar, y un modelo no monitoreado no tiene forma de decirle que se ha quedado atrás. Un modelo de fraude entrenado en los patrones del año pasado poco a poco pierde el de este año. Un extractor de documentos adaptado a las facturas de un proveedor comienza a eliminar campos cuando llega el formato de un nuevo proveedor. El código está bien. El modelo simplemente ha envejecido y ha dejado de ser la realidad para la que fue construido.
El peligro es que este fracaso sea silencioso. Un servidor fallado llama a alguien a las 3 a.m. Un modelo a la deriva simplemente arroja respuestas ligeramente peores, día tras día, y sigue devolviéndolas con confianza. No llaman a nadie. Cuando alguien detecta un número extraño, es posible que el sistema lleve meses funcionando silenciosamente mal. Eso es lo que la gente quiere decir cuando dice que un sistema AI se pudrió: no es que se rompió, sino que nadie estaba viendo cómo se deterioraba.
Es por eso que los sistemas duraderos, como el tipo necesario para documento AI en una empresa, tratan el monitoreo y el reentrenamiento como parte de la construcción, no como algo que agregar si queda presupuesto.
¿Cuánto MLOps necesita realmente un proyecto?
Menos de lo que implica el panorama de proveedores y más de lo que la mayoría de los pilotos presupuestan. La cantidad correcta depende de lo que está en juego, no del tamaño del catálogo de herramientas.
| Tipo de sistema | Qué seguimiento necesita | Cadencia de reentrenamiento |
|---|---|---|
| Insumos estables y de bajo riesgo | Registro de salida básico y una simple verificación de precisión | En raras ocasiones, sólo cuando surge un problema |
| Insumos cambiantes y críticos para el negocio | Alertas de deriva y precisión con un propietario designado | Según un desencadenante definido o un horario regular |
| Decisiones consecuentes sobre las personas | Registro completo, revisión humana de casos extremos, seguimiento de auditoría | Programado, con cada versión grabada |
Dos principios mantienen esto honesto. En primer lugar, cree el monitoreo antes de que lo necesite, mientras el sistema sea pequeño, porque modernizar la visibilidad en un sistema activo es mucho más difícil que diseñarlo. En segundo lugar, asigne un propietario designado al sistema en ejecución. El trabajo operativo sin dueño no ocurre, y un modelo sin nadie vigilándolo es un modelo en camino a pudrirse.
La conclusión práctica
Cuando ponga en marcha un sistema AI, pregunte quién es responsable del mismo en el sexto mes y cómo sabrán si deja de funcionar. Si la respuesta es una fecha de lanzamiento y silencio después, estás comprando una demostración con una pista más larga. Si la respuesta nombra a una persona, un conjunto de métricas que observa y un plan para actualizar el modelo, estás comprando algo creado para seguir siendo útil. MLOps es simplemente la poco glamorosa costumbre de cumplir una promesa una vez finalizada la fiesta de lanzamiento. Encelyte construye documento de sistemas AI y AI con ese trabajo del segundo día diseñado desde el principio.

Vincent Wahidi
Autor
Vincent Wahidi is the director of Encelyte, a computer engineer who builds production AI, automation, and custom software for enterprises across Cyprus and the wider region. He writes the strategy, cost and decision-maker pieces himself; the practical how-to guides are curated under the five mission-cat bylines below.
Leer a continuación
Adónde van los datos de su empresa cuando utiliza AI: una respuesta clara para la junta directiva
¿Tienes un problema que valga la pena resolver?
Cuéntanos qué estás construyendo o arreglando. Te responderemos en un día laborable con un siguiente paso claro.
