[!NOTE] Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.
MLOps frente a LLMOps: Infraestructura para modelos fundamentales y sistemas LLM
La disciplina de MLOps sigue siendo aplicable. Lo que ha cambiado es la unidad operativa: el comportamiento de una aplicación basada en modelos de lenguaje puede depender de prompts, la decodificación, la recuperación de información, los contratos de herramientas, los permisos, el enrutamiento y las políticas, así como de los pesos del modelo. Este artículo explica qué elementos siguen siendo útiles y qué sistemas LLM han sido añadidos.
Resumen. Mantén la trazabilidad de MLOps, la automatización, la entrega por fases, la monitorización y la capacidad de reversión. Amplía el manifiesto de lanzamiento para que incluya al proveedor o los pesos, prompts, esquemas, estado de recuperación, herramientas, enrutamiento y políticas. Valida dicho manifiesto mediante evaluaciones en capas sucesivas, y luego utiliza registros sensibles a la privacidad para convertir los fallos en producción en nuevas pruebas.
Qué ya ha resuelto MLOps
Los controles establecidos en MLOps que no se vuelven obsoletos cuando el modelo genera texto:
- Linaje que va desde los datos, el código, la configuración y el modelo hasta una versión final de lanzamiento
- Entrenamiento o compilación reproducible pipelines
- Validación offline antes de la promoción
- Registros e identidad inmutable de los artefactos
- Despliegue por fases, objetivos a nivel de servicio, capacidad de reversión y respuesta ante incidentes
- Telemetría de infraestructura y planificación de capacidad
- Control de acceso, política de retención y auditoría de datos
Los modelos fundamentales no eliminan estas necesidades. Además, hacen que la expresión tradicional “versión del modelo” resulte insuficiente.
La unidad de lanzamiento pasó a ser un manifiesto del sistema
En un servicio de predicción convencional, el código, la lógica de características y la identidad del modelo suelen explicar la mayor parte de los cambios de comportamiento. En un sistema basado en modelos fundamentales, es necesario registrar al menos:
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 revisionsLa lista exacta depende del sistema. Lo que es constante es que un manifiesto debe identificar cada componente que cambia de forma independiente y que puede modificar el comportamiento visible para el usuario.
El alias de modelo de un proveedor no es necesariamente un artefacto inmutable. Un hash checkpoint autohospedado resulta más preciso, pero las configuraciones de runtime, cuantización, plantilla y paralelismo siguen formando parte del registro de la versión.
Cinco superficies de fallo ampliadas
La diferencia entre MLOps y LLMOps resulta más evidente en el análisis de fallos que en las listas de herramientas.
1. Modelo y serving
Los modelos alojados introducen aspectos como la disponibilidad del proveedor, los límites de cuota, el procesamiento regional, las modificaciones de alias y un modelo económico basado en el pago por token. Por su parte, los modelos autoalojados conllevan desafíos relacionados con las cadenas de suministro de pesos, la capacidad de GPU, el agrupamiento de operaciones, la política de caché, la cuantización y la implementación distribuida de serving.
Ambos requieren controles de latencia, errores, ancho de banda, saturación y costes. Ninguno de los modos de despliegue elimina la evaluación de calidad.
2. Prompt, esquema y orquestación
Un prompt es una configuración de tipo similar al código, pero el texto puro de prompt por sí solo no define el comportamiento. El orden de los mensajes, las descripciones de las herramientas, el esquema de respuesta, la decodificación, las reintentos, la truncación y el código circundante son todos factores importantes.
Versione la solicitud compilada así como la política de orquestación. Pruebe structured outputs mediante parsers e invariantes de negocio, en lugar de considerar que un “JSON” válido equivale a que la tarea se haya completado con éxito.
3. Recuperación y contexto
La recuperación de información introduce un producto de datos independiente entre la fuente de verdad y el modelo:
El pipeline debe conservar la revisión de origen, las versiones del analizador y del fragmentador, la embedding identidad, el proceso de construcción del índice, los metadatos de control de acceso y el estado de eliminación. Es necesario evaluar la recuperación de información antes de generar la respuesta: comprobar si el sistema encontró las pruebas adecuadas, si se aplicaron los filtros de autorización y si la respuesta utilizó correctamente las pruebas proporcionadas.
Un índice vectorial no sustituye a un almacén de características ni a un repositorio de datos. Su función es la recuperación de similitudes; las características estructuradas en un momento específico y los hechos analíticos mantienen requisitos diferentes en cuanto a consistencia y consultas.
4. Herramientas y acciones
Cuando un modelo es capaz de invocar a APIs, las fallas de calidad pueden convertirse en efectos secundarios. Los límites operativos incluyen ahora la autenticación de herramientas, el principio de menor privilegio, la validación de argumentos, los tiempos de espera, la idempotencia, la política de aprobación y las comprobaciones de postcondición.
Rastrea qué herramienta se ofreció, seleccionó, llamó, rechazó, volvió a intentar y se confirmó. Una respuesta final precisa no puede demostrar que la secuencia de acciones fue la correcta.
5. Seguridad, protección y políticas
Los filtros de contenido constituyen un mecanismo de control, pero no representan una capa de protección integral. Las amenazas también incluyen prompt injection, la recuperación de datos entre distintos clientes, la divulgación de información confidencial, un grado excesivo de autonomía por parte de los agentes, código de modelos o nodos no fiable, y parámetros de herramientas inseguros.
Expresen las reglas de negocio deterministas fuera del modelo siempre que sea posible. Definan los riesgos residuales, prueben casos adversariales y asignen un responsable para los cambios en las políticas. El Perfil Generativo AI de NIST constituye un inventario útil de riesgos, pero no constituye una prueba de aceptación lista para usar.
La evaluación se convierte en una puerta de liberación
La salida de formato libre hace que un único valor de precisión agregada resulte insuficiente. No implica, sin embargo, que la calidad sea imposible de cuantificar.
Construye una pila de evaluación que incluya varios tipos de evidencia:
- Verificaciones determinísticas: validez del esquema, presencia de citas, herramientas permitidas, restricciones en los argumentos, reglas de política, latencia y presupuesto.
- Métricas de componentes: recuperación y precisión en la clasificación, exactitud en la selección de herramientas, corrección de argumentos de las herramientas y selección de rutas.
- Tareas de extremo a extremo: entradas representativas con criterios de éxito explícitos y etiquetas de segmentación.
- Puntuación basada en modelos: juicios guiados por rúbricas calibrados según etiquetas de expertos, con monitoreo para detectar desviaciones en los evaluadores.
- Revisión humana: casos ambiguos, de alto impacto, novedosos o seleccionados aleatoriamente en los que la automatización no es fiable.
- Pruebas adversariales: casos de inyección, límites de datos, abuso, rechazos y efectos secundarios relacionados con el modelo de amenazas.
Almacene los resultados por ejemplo, y no solo las medias. Una nueva versión puede mejorar el valor promedio al mismo tiempo que empeora el rendimiento en un idioma específico, un tenant concreto, un tipo de documento determinado o una clase de acción particular.
La puerta de despliegue compara el manifiesto del candidato con la versión actual del mismo conjunto versionado. Los umbrales deben abarcar de forma conjunta aspectos como la calidad, la seguridad, la latencia y el costo; una ruta más económica que no cumple con los requisitos no constituye una optimización.
Las trazas vinculan la producción con las pruebas de evaluación
Las métricas de infraestructura pueden indicar una llamada al modelo lenta. No son capaces de revelar si la recuperación de datos devolvió un documento no autorizado o si se invocó una herramienta con la cuenta incorrecta.
Capturar un rastro a lo largo de la ruta de decisión:
- Correlación de identidades del release-manifest y solicitudes
- Llamadas al modelo y al proveedor, latencia, uso y estado de finalización
- Consultas de recuperación, identificadores de documentos, puntuaciones y decisiones de filtrado
- prompt/revisión de plantillas sin almacenar de forma indiscriminada contenido sensible
- Ofertas de herramientas, argumentos, aprobaciones, resultados e identificadores de efectos secundarios
- Decisiones de política, intentos de reintentos, soluciones alternativas y resultado final
El seguimiento de actividades genera una nueva capa de gobernanza de datos. Es necesario aplicar medidas de minimización, redacción, aislamiento por tenant, cifrado, muestreo, retención y revisión de accesos antes de recopilar los datos completos prompts o los documentos correspondientes. Las convenciones de generación-AI de OpenTelemetry pueden contribuir a la interoperabilidad, pero sus esquemas siguen evolucionando; por lo tanto, es imprescindible fijar las versiones de las herramientas de instrumentación y de los recolectores.
El bucle de mejora es:
production trace → triaged failure → labeled regression case
→ candidate change → offline comparison
→ staged release → monitored outcomeLos comentarios de los usuarios pueden servir para priorizar una investigación, pero un “me gusta” no constituye la verdad objetiva. Es necesario conservar el rastro asociado y obtener etiquetas de expertos en los casos de mayor gravedad.
La pasarela serving constituye un límite de política
Un gateway puede desacoplar a los clientes de aplicaciones de los proveedores o de los motores autohospedados. Entre sus responsabilidades útiles se pueden incluir:
- Autenticación, presupuestos de usuario, cuotas y límites de tasa
- Contratos estables de solicitud y respuesta
- Selección de rutas según capacidad, región, latencia o calidad evaluada
- Repeticiones limitadas, interruptores de circuito y semántica explícita de fallback
- Particionamiento de caché y política de datos sensibles
- Atribución del uso y propagación del manifest de liberación
El fallback representa un cambio de comportamiento, y no solo un mecanismo de fiabilidad. Si un modelo más pequeño, un proveedor alternativo o un contexto reducido afectan negativamente la calidad de la tarea, es necesario evaluar y rastrear esa ruta como si fuera un camino independiente.
No se deben incluir todas las decisiones de orquestación en la pasarela. Es conveniente mantener las reglas del dominio cerca de la aplicación y hacer visible quién es el responsable de su gestión.
Fine-tuning representa una única intervención, y no una escala de madurez.
Elige la intervención correspondiente al fallo observado:
| Fallo | |
|---|---|
| Faltan hechos actuales o privados | recuperación y sincronización de fuentes |
| Formato incorrecto o argumentos inválidos | esquema, salida restringida, validación |
| Comportamiento inconsistente de la tarea | prompt: ejemplos, selección del modelo y, posteriormente, datos de adaptación. |
| Latencia o costo excesivo | ruta, contexto, caché, agrupación por lotes, cuantización |
| Acción no autorizada o insegura | permisos de la herramienta y política determinista |
| El comportamiento del dominio no es recuperable a partir del contexto. | fine-tuning o otro modelo especializado |
LoRA y otros métodos eficientes en términos de parámetros reducen la cantidad de parámetros entrenables; no eliminan las normas de dataset, ni los aspectos relacionados con la licencia del modelo base, la evaluación, la compatibilidad con serving, ni los requisitos de reversión.
Una secuencia práctica de adopción
- Defina la tarea del usuario, los límites de daño, los objetivos del servicio y el rango de costes permitido.
- Cree el manifiesto de lanzamiento antes de introducir un registro prompt, una base de datos vectorial o un producto de pasarela.
- Construya un conjunto de evaluación reducido y dividido en partes, así como pruebas para componentes deterministas.
- Instrumente un seguimiento de extremo a extremo con controles de privacidad e identidades estables para los lanzamientos.
- Implemente la actualización mediante modalidades como shadow, canary o tráfico limitado, con un mecanismo explícito de reversión en caso de problemas.
- Convierta las fallas detectadas en producción en casos de regresión y repita el proceso de evaluación.
Solo se debe añadir infraestructura cuando exista un control con nombre asociado o cuando se elimine un cuello de botella medido. La “plataforma LLMOps” no constituye un requisito arquitectónico.
Conclusión
LLMOps es MLOps aplicado a una unidad de comportamiento más amplia. El modelo sigue siendo fundamental, pero prompts, las pruebas recuperadas, los permisos de las herramientas, la redirección y las políticas pueden influir en el resultado sin necesidad de modificar los pesos del modelo.
Versionar toda la unidad, evaluarla antes del lanzamiento, rastrearla respetando los límites de privacidad, y revertirla como un único sistema. Esa es la diferencia operativa que realmente importa.