La version de modelo no basta: define la frontera de release en IA

Versionar el modelo es insuficiente para garantizar la estabilidad de una aplicacion de IA en produccion. El problema real surge cuando cambian componentes independientes como el retrieval, los prompts o el preprocessing, alterando el comportamiento sin modificar la version del modelo base. Para resolverlo, se necesita un limite de release claro que agrupe todos los componentes que deben funcionar en conjunto.

El articulo propone empezar con un manifiesto de release versionado. Este documento debe listar identificadoras concretas para la revision de la app, el snapshot del modelo, la version del prompt, la configuracion del retrieval (indice, embeddings, pipeline) y las configuraciones de runtime como timeouts o limites de tokens. Cada referencia debe apuntar a artefactos inspeccionables retenidos, no a alias flotantes. Es importante documentar las limitaciones, como la no deterministica de la generacion o la imposibilidad de snapshots inmutables en algunos proveedores, en lugar de disfrazar cambios como versiones fijas.

La evaluacion debe ser la puerta de entrada a produccion. No basta con verificar la disponibilidad del endpoint (HTTP 200); hay que evaluar la calidad semantica y operativa. Se recomienda usar datasets versionados que incluyan casos normales, fallos previos, solicitudes ambiguas y intentos de violacion de permisos. Los criterios de aceptacion deben definirse antes de probar el candidato: bloqueo ante violaciones de control de acceso, tolerancia maxima de regresion en slices semanticos y respeto a presupuestos de latencia y coste.

Las metricas de rendimiento deben ir mas alla de las peticiones por segundo. Para cargas de trabajo de LLM, es crucial analizar distribuciones de longitud de entrada y salida, concurrencia y colas. Herramientas como vLLM permiten exponer metricas especificas para time-to-first-token, velocidad de tokenizacion y profundidad de cola, diferenciando el tiempo de espera en la cola del tiempo de generacion. Esto complementa, pero no sustituye, la latencia visible en el cliente que incluye retrieval y renderizado.

Cuando una release falla, el sistema debe generar un artefacto de depuracion que incluya los IDs de release, la revision del dataset usado, los casos fallidos y las trazas relevantes. Un fallo en el pipeline de evaluacion no debe ser una caja negra, sino un punto de entrada para la investigacion.

Esta enfoque posiciona MLOps no como una plataforma mas, sino como el workflow que permite testear, observar y revertir unidades de release coherentes. La madurez operativa en IA depende de tratar la aplicacion como un sistema de componentes interdependientes, no como una caja negra de inferencia.