MLOps para equipos de investigación: del notebook a producción

El modelo funciona. El doctorando lo entrenó, lo validó sobre un conjunto de test reservado, presentó los resultados en tres reuniones de grupo y lo recogió en el artículo que ahora está en revisión. El problema es que el modelo vive en un notebook de Jupyter en el portátil del doctorando. El doctorando se gradúa en cuatro meses. El financiador preguntó cuándo estará disponible el modelo validado "como un servicio usable". La respuesta del equipo es una combinación de ya lo resolveremos y no sabemos qué significa eso.

Esto es el MLOps para equipos de investigación, y casi nada de lo escrito sobre MLOps se escribió para ellos.

La literatura estándar de MLOps está pensada para equipos de plataforma en empresas que operan cientos de modelos en producción. Kubeflow, Seldon, MLflow Model Registry, feature stores, inferencia serverless, monitorización de drift, pipelines de testing A/B, autoescalado de GPU. Todo real. Nada de eso es lo que necesita un grupo de investigación de cuatro personas con un modelo validado.

Este artículo trata de cómo es realmente el despliegue de modelos de machine learning cuando el equipo no tiene un equipo de plataforma de MLOps, el modelo sirve a decenas de usuarios y no a millones, y el objetivo es "documentado, usable y mantenible" y no "infraestructura a hiperescala".

Qué significa "MLOps" para la investigación, en concreto

El MLOps para equipos de investigación no es una versión reducida del MLOps empresarial. Tiene una forma completamente distinta. Las restricciones son distintas, los criterios de éxito son distintos y la arquitectura correcta es distinta.

El MLOps empresarial optimiza para la escala, la latencia y el reentrenamiento continuo de muchos modelos. El MLOps de investigación optimiza para la reproducibilidad, la documentación y la capacidad de que alguien distinto del autor original opere el sistema. El número de modelos es uno o un puñado. El de usuarios es de decenas o pocos cientos. La cadencia de reentrenamiento es "cuando llega el siguiente dataset", no "cada quince minutos".

Si aciertas con esas restricciones, la arquitectura se simplifica drásticamente. El stack de MLOps del proveedor cloud se reduce a quizá cuatro o cinco componentes. El equipo puede operarlo sin ingeniería de plataforma dedicada. El financiador recibe un entregable que puede verificar.

Si fallas con ellas, importando el stack empresarial a un proyecto de investigación, construyes algo que el equipo no puede mantener tras el traspaso. En el peor caso, la complejidad de la plataforma sobrevive a la financiación y el modelo queda inaccesible.

Los cuatro antipatrones que vemos con más frecuencia

1. El notebook como despliegue de producción

El equipo despliega subiendo el notebook a una unidad compartida y pidiendo a los usuarios que "ejecuten las celdas en orden". Esto no es un despliegue. Es un procedimiento manual con dependencias implícitas. Cualquiera con una versión distinta de Python, un estado distinto de paquetes o una máquina distinta produce salidas distintas. El modelo existe técnicamente; el despliegue no.

Lo que debería ser: una API de inferencia o un script invocable que cargue el modelo entrenado, reciba entradas documentadas, devuelva salidas documentadas y se ejecute de principio a fin sin intervención manual. Incluso un script de Python de un solo archivo con una CLI es un orden de magnitud mejor que un notebook.

2. La plataforma sobredimensionada

El equipo (o, más a menudo, la consultora que contrató) despliega en Kubernetes, monta Kubeflow, configura workflows de Argo, integra Seldon Core, añade Prometheus + Grafana para monitorización y lo envuelve todo en charts de Helm. Para un único modelo que sirve a 40 usuarios.

Seis meses después, la consultora se ha ido, el ingeniero de plataforma ha rotado a otro proyecto y nadie del equipo sabe cómo actualizar el modelo. La infraestructura tiene más piezas móviles que la propia ciencia. Es el modo de fallo más caro porque al principio funciona y se rompe despacio.

Lo que debería ser: el despliegue viable más pequeño que cubra el patrón de uso real. A menudo es un servicio FastAPI containerizado en una sola VM, desplegado mediante un script documentado. El MLOps como servicio para investigación consiste en ajustar la complejidad del despliegue a la complejidad operativa, no en buscar la máxima sofisticación.

3. La brecha entre validación y despliegue

El modelo se validó sobre un dataset de benchmark curado. El despliegue recibe datos del mundo real que no se parecen del todo al benchmark. Las puntuaciones de confianza del modelo siguen altas, pero las predicciones son erróneas. Nadie se da cuenta porque no hay una vía de revisión humana.

Lo que debería ser: una distinción deliberada entre predicciones de confianza alta y de confianza baja, con los casos de confianza baja derivados a revisión humana. No porque todo modelo necesite HITL, sino porque los modelos en fase de investigación, con datos de despliegue limitados, se benefician de un tratamiento explícito de los casos límite. Un sistema de evaluación de CV narrativos que construimos hacía esto: la evaluación por IA resolvía los casos claros de forma automática, los casos de confianza baja pasaban a revisores humanos, y el sistema generaba un registro de auditoría de qué decisiones habían usado cada vía.

4. El modelo sin documentar

El archivo del modelo (model.pkl, weights.pt, lo que sea) vive en un servidor. Los datos de entrenamiento, el script de entrenamiento, la pipeline de preprocesado, las métricas de evaluación y el historial de versiones viven en un sitio completamente distinto. Para reentrenar, o para defender el modelo en un contexto regulatorio o de revisión por pares, alguien tiene que reconstruir la mitad de memoria.

Lo que debería ser: una model card. Un documento estructurado, junto al archivo del modelo, que recoja la procedencia de los datos de entrenamiento, los pasos de preprocesado, las métricas de evaluación, el uso previsto, las limitaciones conocidas y el historial de versiones. Cada vez más financiadores lo exigen (sobre todo en trabajo cercano a salud, donde aplican consideraciones de IRB o MDR). La model card lleva un día escribirla y ahorra semanas en el momento de la auditoría.

Cómo es realmente un MLOps mínimo viable

Para un equipo de investigación con un modelo validado, un despliegue mantenible suele tener estas piezas, y no mucho más.

| Componente | Qué hace | Cómo es lo "mínimo viable" | |---|---|---| | Artefacto del modelo | El modelo entrenado + el preprocesado | Archivo versionado en almacenamiento de objetos o en un model registry | | Servicio de inferencia | Recibe la entrada → devuelve la predicción | Servicio FastAPI / Flask en un contenedor Docker | | Destino de despliegue | Dónde corre el servicio | Una sola VM, un servicio gestionado de contenedores o un cluster institucional | | Validación de entradas | Detecta peticiones malformadas | Esquemas de Pydantic o validación de tipos equivalente | | Logging | Registra entradas + predicciones para auditoría | Logs estructurados a un archivo o a un servicio central de logs | | Enrutado por confianza | Separa los casos de confianza alta de los de baja | Comprobación de umbral + cola para revisión humana | | Documentación | Model card + runbook | Un archivo markdown para cada uno, bajo control de versiones | | Vía de reentrenamiento | Cómo se despliega una nueva versión del modelo | Un procedimiento documentado, no necesariamente automatizado |

Eso es todo. Ocho componentes, ninguno requiere un equipo de plataforma y todos cumplen el listón de "documentado, usable y mantenible" que les importa a la mayoría de los evaluadores de financiadores de investigación.

Puedes añadir por encima monitorización, detección de drift, reentrenamiento automatizado y feature stores, pero solo si tienes una razón real. Para un modelo con poco tráfico y reentrenamiento infrecuente, esas capas son coste sin beneficio.

Cómo pensar el momento del despliegue del modelo

El momento adecuado para empezar a pensar en el despliegue es cuando los resultados de validación son estables. No cuando se envía el artículo. No cuando lo pide el financiador. El modelo validado es el artefacto que vas a desplegar; todo lo anterior es investigación, todo lo posterior es ingeniería.

Los equipos de investigación a menudo lo invierten: retrasan pensar en el despliegue hasta que la ciencia está "terminada", y entonces descubren que tienen ocho semanas para convertir un notebook en algo que el financiador pueda verificar. Es el mismo patrón que el cierre de un proyecto financiado: el trabajo de ingeniería se infradotó desde el arranque y se comprime al final.

Mejor: empieza a delimitar el despliegue en paralelo a la validación final. Aunque no construyas hasta más tarde, saber cómo será el despliegue cambia cómo escribes el código de validación, cómo serializas el modelo y qué supuestos incorporas al preprocesado.

Cuándo incorporar ayuda externa

Las señales son claras. Si alguna de estas describe tu proyecto, es probable que el trabajo de despliegue exceda lo que tu equipo debería absorber internamente:

• El modelo está validado pero no tienes un ingeniero de software o de ML dedicado en el equipo
• Tu único despliegue anterior fue una demo de Streamlit que "más o menos funciona"
• El financiador espera un servicio o una API usable como entregable, no solo un artículo
• Las restricciones regulatorias o institucionales (datos clínicos, PII, IRB) hacen que no puedas simplemente desplegar en un cloud de capa gratuita y cruzar los dedos
• Necesitas que el despliegue siga siendo mantenible más allá de la graduación del doctorando

Para los equipos de salud y ciencias de la vida en particular, la dimensión regulatoria importa. Un modelo que toca datos clínicos, soporte a la decisión cercano a producto sanitario, o cualquier cosa que pueda acabar en un artículo que reclame utilidad clínica, necesita una infraestructura de despliegue con registros de auditoría adecuados, control de acceso y vías de revisión humana. Tiene solución, pero no es un despliegue de Streamlit.

Qué entrega un buen MLOps para equipos de investigación

El estado final es poco vistoso. Un pequeño conjunto de archivos. Un servicio en marcha. Documentación que un nuevo miembro del equipo puede seguir. El equipo que usa el modelo no piensa en MLOps: solo envía entradas y recibe salidas. El despliegue sigue funcionando cuando el desarrollador original se va. El financiador puede ejecutar un script de verificación y comprobar que el servicio responde correctamente.

Eso es todo. Sin un dashboard con doce gráficos. Sin pipeline de reentrenamiento automatizado. Sin framework de testing A/B. El modelo está en producción, la producción está documentada y es del equipo.

Cuando un proyecto de investigación necesita más que esto (escala real, varios modelos, reentrenamiento frecuente), ha superado el punto donde aplica el MLOps de investigación. En ese momento eres un equipo de plataforma de ML, y el stack empresarial empieza a tener sentido. Pero para casi todos los despliegues de ML en investigación financiada, no estás en ese punto. Estás intentando sacar un solo modelo de un solo notebook y llevarlo a un solo servicio en marcha que usará un solo equipo.

Ese es un problema mucho más pequeño y mucho más resoluble.

Dónde encaja Pragma

Pragma construye MLOps para equipos de investigación sin la sobrecarga empresarial. Hemos desplegado modelos validados con pipelines de enrutado por confianza para flujos de evaluación, integrado inferencia de ML en MVPs de herramientas de investigación y reconstruido prototipos en fase de notebook hasta convertirlos en servicios documentados y mantenibles. El proyecto suele durar de 4 a 8 semanas, deja al equipo con código que posee y opera, y termina sin permanencia ni cuotas recurrentes.

Si tu proyecto de investigación tiene un modelo que necesita salir del notebook, ese es el proyecto para el que existimos.

Tres cosas que hacer esta semana

1. Abre el notebook en el que vive el modelo. Anota cada dependencia implícita (versión de Python, versiones de paquetes, rutas, pasos de limpieza manual). Esa es tu lista de carencias.
2. Define el despliegue mínimo viable para tu patrón de uso real. Una respuesta honesta a "¿cuántos usuarios, con qué frecuencia, a qué velocidad?" vale más que una arquitectura aspiracional.
3. Si la distancia entre el estado actual y el mínimo viable es mayor de lo que tu equipo puede absorber en 4 a 6 semanas, solicita una revisión de alcance. Te diremos si tu caso es de verdad 4 semanas o de verdad 12, y qué aspecto tiene cada opción.

El ML de investigación en producción no necesita ser de nivel empresarial. Necesita ser honesto sobre la escala, implacable con el alcance y estar construido para durar más que el desarrollador original.