MLOps / LLMOps Operations
Operar y evolucionar sistemas AI
MLOps / LLMOps Operations es la práctica de versionar, observar, evaluar y evolucionar sistemas respaldados por modelos durante su operación, manteniendo correlación entre artefactos, datos, configuración y comportamiento. MLOps reúne preocupaciones operativas de sistemas de machine learning; LLMOps aplica y extiende esas preocupaciones a sistemas centrados en foundation models, prompts, retrieval, herramientas, guardrails, routing y comportamiento de tokens.
LLMOps no es una disciplina universalmente estandarizada ni un reemplazo de DevOps. Comparte despliegue, disponibilidad, incidentes y automatización con operaciones de software, pero agrega identidad de modelos, datos, evaluación y cambios de comportamiento. La agrupación evita crear una página por cada palabra de la lista sin perder los límites de cada posición.
Este documento especializa Versioning y Monitoring dentro de una práctica operacional coherente, sin redefinir esos conceptos generales ni crear AI Versioning o AI Monitoring duplicados. Deployment y Release siguen siendo conceptos generales; Model Serving tiene su propio canonical. Evaluation in Production y Drift se desarrollan aquí como preocupaciones del ciclo operacional, no como sinónimos de Online Evaluation o Regression Testing.
Qué debe conservar identidad
Un nombre de modelo no es una identidad suficiente para explicar un resultado. Según el sistema, conviene correlacionar:
- artefacto, checkpoint o versión de modelo;
- código y dependencias del runtime;
- prompt, instrucciones y configuración;
- snapshot de datos de entrenamiento o referencia;
- corpus e índice de retrieval;
- dataset y grader de evaluación;
- versión de guardrails, routing y herramientas;
- entorno, hardware y proveedor;
- release y configuración del servicio.
Versionar no significa que la reproducción completa sea siempre posible. Proveedores pueden actualizar modelos, datos pueden cambiar, servicios externos pueden desaparecer y algunas salidas son no deterministas. La identidad compuesta hace explícita la procedencia y reduce atribuciones erróneas; no convierte el sistema en determinista.
Correlación y cambio
Una operación necesita relacionar qué se cambió con qué tráfico observó el cambio. Un rollout que modifica el modelo sin registrar el prompt o el índice puede hacer imposible explicar una caída. Un cambio de corpus que parece una regresión del modelo puede ser una variación de retrieval. Un proveedor que actualiza una API puede cambiar calidad sin un commit local.
La correlación debe ser suficientemente granular para investigar, pero no exigir una etiqueta distinta para cada evento. La identidad puede ser una tupla de artefactos y configuración declarada. Lo importante es que los consumidores sepan qué representa cada versión y qué límites tiene la comparación.
Monitoring operacional
Monitoring sigue indicadores conocidos y condiciones que requieren atención. En sistemas AI puede cubrir disponibilidad, errores, saturación, colas, latencia, timeouts, tasa de fallback, uso de recursos, consumo de tokens y límites. También puede seguir señales de calidad cuando existe un criterio operacional definido, pero el monitoreo no se convierte por eso en evaluación.
AI / LLM Observability conserva la recolección y correlación de evidencia runtime. Monitoring consume señales para detectar condiciones, comparar ventanas, alertar y activar investigación. La separación evita que un dashboard de tokens se presente como juicio de calidad o que una alerta de latencia pretenda explicar una causa sin evidencia suficiente.
No todo cambio merece una alerta. Umbrales, ventanas, muestreo y baselines deben corresponder al riesgo y a la variabilidad esperada. Un sistema probabilístico puede producir fluctuaciones normales; un umbral demasiado rígido genera ruido y un umbral demasiado laxo retrasa la detección.
Evaluation in Production
Evaluation in Production aplica criterios de evaluación a comportamiento observado durante operación real. Puede usar interacciones muestreadas, traces, feedback, shadow evaluation, graders automáticos o revisión humana. Pregunta si el sistema sigue satisfaciendo criterios de tarea, calidad o política en la distribución que realmente enfrenta.
AI Evaluation Fundamentals conserva el modelo general de evaluación y distingue Offline Evaluation de Online Evaluation. Online Evaluation es la modalidad amplia de evaluar con interacción viva; Evaluation in Production es la preocupación operacional de integrar esa evaluación en el ciclo de producción: seleccionar muestras, proteger datos, asignar evidencia, reaccionar y mantener el proceso.
Production Evaluation no es Monitoring. Monitoring puede detectar que aumentó la latencia o que cayó una tasa; Evaluation in Production juzga si las respuestas siguen siendo correctas, grounded, completas, seguras o útiles según criterios declarados. Monitoring puede disparar una evaluación, y una evaluación puede producir una señal monitoreable, pero no son la misma decisión.
Tampoco es simplemente Offline Evaluation repetida después del deploy. La producción aporta distribución real, usuarios, herramientas, contexto y casos raros; también introduce privacidad, retraso de labels y dificultad para establecer causalidad. Offline conserva control y repetibilidad. Ambos modos se complementan.
Drift
Drift es un cambio significativo en datos, entradas, ambiente, relaciones o comportamiento respecto de una referencia que puede afectar supuestos o desempeño. El cambio no implica automáticamente daño. Debe declararse qué distribución o relación se compara y por qué importa.
Data drift describe cambio en la distribución de inputs o features. Concept drift describe cambio en la relación entre inputs y resultado esperado. En aplicaciones AI/LLM también puede hablarse de behavior o quality drift cuando cambian salidas o calidad por actualizaciones del proveedor, prompt, corpus, herramientas, usuarios o ambiente. Esta extensión debe marcarse como uso operacional más amplio que la terminología estadística estricta.
Detectar drift puede usar estadísticas de distribución, cambios de calidad, feedback, comportamiento de usuarios o evaluación de producción. La detección no identifica automáticamente la causa. Un cambio puede ser esperado, beneficioso, dañino o irrelevante para el objetivo.
Drift tampoco es una fluctuación aleatoria de una muestra ni toda variación no determinista de una respuesta. Hace falta evidencia de un cambio persistente, distribuido o relacionado con una referencia que justifique investigar una condición del sistema, no sólo observar un resultado distinto.
Drift, Regression e Incident
Regression Testing compara comportamiento contra un baseline o contrato, normalmente en casos controlados o replays después de un cambio. Drift describe cambio en la distribución, ambiente o relación durante el tiempo. Drift puede causar una regresión; una regresión puede ocurrir sin drift, por ejemplo por un bug introducido en el código con los mismos inputs.
Un incident es un evento operacional que requiere respuesta por impacto o riesgo. Drift es una condición o patrón de cambio; no todo drift es un incidente y no todo incidente es drift. Un proveedor caído es un incidente de disponibilidad, aunque la distribución de inputs no haya cambiado. Una población de usuarios que cambia puede ser drift sin haber degradación todavía.
La separación mejora diagnóstico: primero se describe el cambio observado, después se evalúa impacto y finalmente se investiga causa. No se debe declarar drift sólo porque una métrica empeoró ni declarar una regresión sólo porque una distribución cambió.
Ciclo de evolución
Un ciclo operacional puede:
- declarar artefactos, configuración y baseline;
- validar una versión con evaluación offline y pruebas de regresión;
- desplegar o servir gradualmente;
- observar señales operativas y de comportamiento;
- evaluar muestras de producción con controles de privacidad;
- investigar drift, incidentes y diferencias de distribución;
- decidir mantener, ajustar, revertir o retirar.
La secuencia no es una maturity ladder ni una receta universal. Un endpoint de alto riesgo puede requerir aprobación humana y gates explícitos; un sistema experimental puede usar muestreo limitado. Deployment y Release conservan sus propias decisiones de entrega. Este canonical conecta esas decisiones con la identidad y evidencia específica de modelos.
LLMOps como especialización
LLMOps comparte serving, deployment, monitoring y versionado con MLOps, pero suele necesitar correlacionar prompts, instrucciones, contexto recuperado, índices, herramientas, guardrails, routing, provider y tokens. Estos elementos pueden cambiar el resultado aunque el nombre del modelo permanezca constante.
Eso no justifica afirmar que todos los productos LLM requieren una plataforma idéntica. Una llamada directa a un proveedor puede necesitar sólo configuración y observabilidad; una aplicación agentic con retrieval y efectos externos necesita más identidad y evaluación. El alcance se decide por el riesgo y las dependencias reales.
Feedback y acciones
Feedback de usuarios, graders y evaluadores puede aportar evidencia de producción, pero debe interpretarse con su sesgo de selección, retraso y contexto. Una reacción automática puede ajustar routing, deshabilitar una herramienta, reducir tráfico o activar revisión; no debe cambiar un modelo o prompt crítico sólo por una señal ambigua.
El sistema debe distinguir alerta, investigación, decisión de cambio y ejecución del cambio. Una métrica no tiene autoridad implícita para modificar producción. Permisos, aprobación y rollback dependen del sistema de entrega y del riesgo, no del hecho de que una señal provenga de un evaluator.
Límites
MLOps / LLMOps Operations no es:
- Model Serving, aunque opere su ciclo de vida;
- Versioning general, aunque especialice qué artefactos correlacionar;
- Monitoring general, aunque defina señales adicionales;
- Evaluation general, aunque integre evaluación de producción;
- Regression Testing, aunque use sus baselines;
- Incident Management, aunque pueda activar una respuesta;
- AI Security o AI Economics.
La posición queda materialmente cubierta cuando una organización puede identificar qué versión sirve, observar condiciones relevantes, evaluar comportamiento real y distinguir drift, regresión e incidentes al decidir cómo evolucionar el sistema.