MLOps frente a LLMOps: infraestructura para foundation models

Viacheslav Dubrov

2025-05-06 · Actualizado 2026-07-15 · 9 min · Infraestructura de IA

Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.

Cuando una release de un foundation model introduce una regresión, el fichero de pesos puede no haber cambiado: el elemento variable puede ser un prompt, un índice de retrieval, un permiso de herramienta, una ruta o una policy. Por tanto, para los ingenieros de ML, de plataforma y de aplicaciones de AI que ya operan MLOps convencional, el artefacto práctico es un manifiesto de release que nombre esas dependencias e indique el primer control que se debe inspeccionar cuando aparece un fallo.

Este es un modelo operativo editorial, no una afirmación de que todas las aplicaciones necesiten la misma plataforma. Conserva el lineage de MLOps, el despliegue por fases, la monitorización y el rollback; amplía la unidad que versionas cuando las respuestas generadas o las acciones de las herramientas hacen que el comportamiento dependa de algo más que de los pesos.

TL;DR. Conserva el lineage, la automatización, el despliegue por fases, la monitorización y el rollback de MLOps. Amplía el manifiesto de release para incluir el proveedor o los pesos, los prompts, los esquemas, el estado del retrieval, las herramientas, el routing y la policy. Promueve ese manifiesto mediante evaluaciones por capas y utiliza traces que respeten la privacidad para convertir los fallos en producción en nuevos tests.

Qué ha resuelto ya MLOps

MLOps estableció controles que no dejan de ser necesarios cuando el modelo genera texto:

• lineage desde los datos, el código, la configuración y el modelo hasta una release
• pipelines de entrenamiento o build reproducibles
• validación offline antes de la promoción
• registries e identidad inmutable de los artefactos
• despliegue por fases, objetivos de nivel de servicio, rollback y respuesta ante incidentes
• telemetría de la infraestructura y planificación de capacidad
• control de acceso, retención y policy de auditoría para los datos

Los foundation models no eliminan estas necesidades. Hacen que la antigua expresión «versión del modelo» se quede pequeña.

La unidad de release se convirtió en un manifiesto del sistema

Para un sistema basado en un foundation model, recomiendo un manifiesto que registre, como mínimo:

application code revision
model provider + model/revision + serving configuration
system and task prompts
response schema + decoding parameters
retrieval corpus snapshot + parser + chunker + embedding model + index
tool definitions + implementation revisions + permission policy
routing, fallback, caching, and budget policy
safety and business-rule revisions
evaluation dataset + scorer revisions

La lista exacta depende del sistema. La regla editorial es identificar cada componente que cambie de forma independiente y pueda alterar el comportamiento visible para el usuario.

Trata el nombre de un modelo de un proveedor como mutable, salvo que el proveedor documente una revisión inmutable. Un hash del checkpoint ayuda a identificar los pesos self-hosted, pero aun así registraría el runtime, la cuantización, la plantilla y la configuración de paralelismo.

Cinco superficies de fallo ampliadas

La diferencia entre MLOps y LLMOps se aprecia mejor en el análisis de fallos que en las listas de herramientas.

1. Modelo y serving

Para planificar, separa los aspectos de los modelos hosted (disponibilidad del proveedor, cuotas, procesamiento regional y coste de uso) de los aspectos self-hosted (disponibilidad de pesos, capacidad de GPU, batching, policy de caché, cuantización y serving). Los controles relevantes dependen del despliegue elegido.

En ambos modos, incluye latencia, errores, throughput, saturación, coste y comprobaciones de calidad de la tarea en la decisión de release.

2. Prompt, esquema y orquestación

En un sistema que ensambla requests en runtime, versiona el request ensamblado en lugar del texto del prompt por sí solo: el orden de los mensajes, las descripciones de las herramientas, el esquema de respuesta, el decoding, los reintentos, la truncación y el código circundante pueden cambiar el comportamiento.

Trata el JSON parseable como una comprobación de transporte y prueba por separado los invariantes de negocio de la tarea.

3. Retrieval y contexto

El retrieval añade un data product independiente entre la fuente de verdad y el modelo:

En un sistema con retrieval aumentado, conserva la revisión de la fuente, las versiones del parser y del chunker, la identidad del embedding, el build del índice, los metadatos de control de acceso y el estado de borrado. El diseño original de RAG separa el retrieval de la generación; utiliza esa separación para probar de forma independiente la recuperación de evidencias, el filtrado de autorización y el uso de evidencias. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks describe la arquitectura retrieve-then-generate.

No utilices un índice vectorial como sustituto de un feature store o un data warehouse: el similarity retrieval, las features point-in-time y los datos analíticos tienen necesidades distintas de consulta y consistencia.

4. Herramientas y acciones

Cuando un modelo puede llamar a APIs, incluye la autenticación de las herramientas, el principio de mínimo privilegio, la validación de argumentos, los timeouts, la idempotencia, la policy de aprobación y las comprobaciones de postcondiciones dentro del perímetro operativo. El Generative AI Profile de NIST identifica riesgos relacionados con el contenido dañino, la privacidad y la seguridad; los controles enumerados son una recomendación de ingeniería acotada, no un catálogo de controles completo.

Traza qué herramienta se ofreció, se seleccionó, se llamó, se rechazó, se reintentó y se confirmó. Una respuesta final fluida no demuestra que la ruta de acción fuese correcta.

5. Safety, seguridad y policy

Los filtros de contenido son un control, no una capa de guardrails completa. Las amenazas también incluyen prompt injection, retrieval entre tenants, divulgación de secretos, exceso de autonomía, código no confiable del modelo o del nodo y argumentos de herramientas inseguros.

Expresa las reglas de negocio deterministas fuera del modelo siempre que sea posible. Define los riesgos residuales, prueba casos adversariales y asigna un responsable para los cambios de policy. El Generative AI Profile de NIST es un inventario de riesgos útil, no un acceptance test listo para usar.

La evaluación se convierte en una release gate

Para decidir una release sobre outputs libres, no dependas de un único número agregado de accuracy. Utiliza varios tipos de evidencias y define cuál es la autoridad para cada modo de fallo.

Construye un stack de evaluación con varios tipos de evidencias:

1. Comprobaciones deterministas: validez del esquema, presencia de citas, herramientas permitidas, restricciones de argumentos, reglas de policy, latencia y presupuesto.
2. Métricas de componentes: recall y ranking del retrieval, accuracy de selección de herramientas, corrección de los argumentos de las herramientas y selección de rutas.
3. Tareas end-to-end: inputs representativos con criterios de éxito explícitos y etiquetas de slice.
4. Scoring basado en modelos: valoraciones guiadas por rúbricas, calibradas frente a etiquetas de expertos y monitorizadas para detectar drift del judge.
5. Revisión humana: casos ambiguos, críticos, novedosos o muestreados en los que la automatización no es la autoridad.
6. Tests adversariales: inyección, límites de datos, abuso, rechazo y casos con efectos secundarios vinculados al threat model.

Almacena los resultados por ejemplo, no solo las medias, para que la revisión de la release pueda inspeccionar regresiones por idioma, tenant, tipo de documento o clase de acción.

Para una deployment gate, compara un manifiesto candidato con la release actual usando la misma suite versionada. Define conjuntamente umbrales de calidad, safety, latencia y coste; una ruta más barata que no completa la tarea no es una optimización.

Las traces conectan producción con la evaluación

Las métricas de infraestructura pueden mostrar que una llamada al modelo es lenta. No pueden mostrar que el retrieval haya devuelto un documento no autorizado o que una herramienta se haya llamado con la cuenta equivocada. La documentación de tracing de MLflow describe traces que capturan los pasos intermedios y los metadatos necesarios para inspeccionar esta ruta.

Captura una trace a lo largo de la ruta de decisión:

• identidad del manifiesto de release y correlación del request
• llamadas al modelo y al proveedor, latencia, uso y estado de finalización
• query de retrieval, identificadores de documentos, scores y decisiones de filtrado
• revisión del prompt/template sin almacenar contenido sensible de forma indiscriminada
• ofertas de herramientas, argumentos, aprobaciones, resultados e identificadores de efectos secundarios
• decisiones de policy, reintentos, fallbacks y resultado final

El tracing crea una nueva superficie de gobierno de datos. Aplica minimización, redacción, aislamiento de tenants, cifrado, sampling, retención y revisión de accesos antes de recopilar prompts o documentos completos. Las convenciones semánticas de GenAI de OpenTelemetry pueden ayudar con la interoperabilidad, pero siguen en desarrollo. Fija la versión de la convención o del esquema, la instrumentación y las versiones del collector.

El bucle de mejora es:

production trace → triaged failure → labeled regression case
                 → candidate change → offline comparison
                 → staged release → monitored outcome

El feedback de los usuarios puede ayudar a priorizar la investigación, pero un pulgar hacia arriba no es ground truth. Conserva la trace circundante y obtén etiquetas de expertos para los casos críticos.

El gateway de serving es un límite de policy

Un gateway puede desacoplar los clientes de la aplicación de los proveedores o de los engines self-hosted. Entre las responsabilidades que merece la pena situar ahí están:

• autenticación, presupuestos por tenant, cuotas y rate limits
• contratos estables de request y response
• selección de rutas por capacidad, región, latencia o calidad evaluada
• reintentos acotados, circuit breakers y semántica explícita de fallback
• particionado de caché y policy de datos sensibles
• atribución de uso y propagación del manifiesto de release

El fallback es tanto un cambio de comportamiento como un mecanismo de fiabilidad. Si un modelo más pequeño, un proveedor alternativo o un contexto reducido cambia la calidad de la tarea, evalúa y traza esa rama como una ruta propia.

No introduzcas todas las decisiones de orquestación en el gateway. Mantén las reglas de dominio cerca de la aplicación y haz visible la ownership.

El fine-tuning es una intervención, no una escalera de madurez

Elige la intervención a partir del fallo observado:

LoRA congela los pesos pretrained y añade matrices low-rank entrenables, lo que reduce el número de parámetros entrenables para la tarea downstream. Esta optimización no elimina el gobierno del dataset, la licencia del modelo base, la evaluación, la compatibilidad con el serving ni los requisitos de rollback.

Una secuencia práctica de adopción

1. Define la tarea del usuario, los límites de daño, los objetivos de servicio y el marco de costes.
2. Crea el manifiesto de release antes de introducir un registro de prompts, una base de datos vectorial o un producto gateway.
3. Construye un conjunto de evaluación pequeño y segmentado, junto con tests deterministas de componentes.
4. Instrumenta una trace end-to-end con controles de privacidad e identidades de release estables.
5. Promueve mediante shadow, canary o tráfico limitado con un trigger de rollback explícito.
6. Convierte los fallos revisados en producción en casos de regresión y repite.

Añade infraestructura solo cuando sea responsable de un control identificado o elimine un cuello de botella medido. «LLMOps platform» no es un requisito de arquitectura.

Conclusión

LLMOps es MLOps aplicado a una unidad de comportamiento más amplia. El modelo sigue siendo importante, pero los prompts, las evidencias recuperadas, los permisos de las herramientas, el routing y la policy pueden cambiar el resultado sin modificar los pesos.

Versiona toda esa unidad, evalúala antes de la release, trázala con límites de privacidad y haz rollback del sistema completo.

Referencias

• MLflow: evaluating production traces - Reutiliza las traces de producción para la evaluación y puntúa la información intermedia de las traces.
• MLflow: LLM and agent tracing - Captura pasos intermedios y metadatos de traces para la investigación.
• OpenTelemetry GenAI semantic conventions - Convenciones en desarrollo para spans, métricas, eventos y datos específicos del proveedor de GenAI.
• NIST AI 600-1: Generative AI Profile - Categorías de riesgo para prompt injection, privacidad, seguridad y otros aspectos relacionados con la AI generativa.
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks - Arquitectura original retrieve-then-generate.
• LoRA: Low-Rank Adaptation of Large Language Models - Pesos pretrained congelados y matrices low-rank entrenables para la adaptación downstream.