La Guía de la Agencia de IA para Versionado de Modelos y Rollbacks de Clientes

Son las 3am. Tu teléfono suena. El modelo en producción de un cliente — el que maneja 2,000 tickets de soporte al cliente por día — está generando basura. Sinsentido completo. Su VP de Experiencia del Cliente ya está redactando un correo a tu CEO.

La pregunta que determina si sobrevives los próximos 30 minutos: ¿puedes revertir a la última versión funcional conocida ahora mismo?

Si no tienes versionado, la respuesta es no. Pasarás horas averiguando qué cambió, cuándo cambió y si siquiera tienes los pesos del adaptador anterior guardados en algún lado. Si tienes versionado, la respuesta es: "Ya está hecho. Revertido en 47 segundos. Investigando la causa raíz ahora."

Esta guía trata sobre construir el sistema que hace posible la segunda respuesta.

Por Qué el Versionado Importa Más para IA que para Software

En software tradicional, un despliegue sale mal y redespliegas el último commit. El código es determinista — misma entrada, misma salida, siempre. Los artefactos son pequeños (megabytes de código compilado), y el rollback es bien entendido.

Los modelos de IA son diferentes en cada dimensión:

• Salidas no deterministas. La misma entrada puede producir diferentes salidas. "Funciona" es probabilístico, no binario.
• Artefactos grandes. Los adaptadores LoRA son de 20-200MB. Los pesos completos del modelo son de 4-30GB. No puedes simplemente hacer "git revert" a estos.
• Linaje complejo. El comportamiento de un modelo depende del modelo base, los pesos del adaptador, los datos de entrenamiento, la configuración de entrenamiento, la configuración de inferencia y a veces la plantilla del prompt. Cambia cualquiera de estos y la salida cambia.
• Degradación silenciosa. El código malo usualmente crashea. Los modelos malos producen basura de aspecto plausible. Podrías no detectarlo por días.

El versionado para modelos de IA debe rastrear más estado, manejar artefactos más grandes y soportar rollbacks más rápidos que el despliegue tradicional de software.

El Esquema de Versionado

Usa versionado semántico adaptado para modelos de IA:

v{major}.{minor}.{patch}

Versión mayor (v1 a v2): Cambió el modelo base. Este es un cambio fundamental — diferente arquitectura, diferentes capacidades, diferentes modos de fallo. Requiere re-evaluación completa y aprobación del cliente.

Versión menor (v1.1 a v1.2): Reentrenó el adaptador LoRA con datos nuevos o actualizados. Mismo modelo base, pero el conocimiento o comportamiento del modelo ha cambiado significativamente. Requiere evaluación automatizada + revisión humana puntual.

Versión de parche (v1.2.0 a v1.2.1): Cambió la configuración de inferencia, plantilla del prompt o parámetros de servicio. Los pesos del modelo no han cambiado. Requiere una prueba rápida de humo.

Ejemplos en práctica:

• acme-support-v1.0.0 → Despliegue inicial en Llama 3 8B
• acme-support-v1.1.0 → Reentrenado con 3 meses de datos de producción
• acme-support-v1.1.1 → Ajustada temperatura de 0.3 a 0.2 para reducir creatividad
• acme-support-v2.0.0 → Migrado a modelo base Llama 3.1 8B

Qué Rastrear Por Versión

Cada entrada de versión en tu registro necesita estos campos. Sin excepciones:

Almacena esto como un archivo YAML o JSON estructurado junto a los pesos del adaptador. Cuando algo sale mal a las 3am, necesitas esta información accesible en segundos, no enterrada en hilos de Slack.

El Registro de Versiones

Mantén un registro central — una única fuente de verdad para lo que está desplegado y dónde:

clients:
  acme:
    models:
      support:
        production: v1.2.1
        staging: v1.3.0
        available_versions:
          - v1.2.1
          - v1.2.0
          - v1.1.0
        rollback_target: v1.2.0
  baker:
    models:
      legal-review:
        production: v2.1.0
        staging: v2.2.0
        available_versions:
          - v2.1.0
          - v2.0.0
          - v1.5.0
        rollback_target: v2.0.0

Este archivo debería estar versionado en sí mismo. Quieres una pista de auditoría completa de cada decisión de despliegue.

El Pipeline de Despliegue

Una actualización de modelo debería pasar por cuatro etapas. Saltarse etapas es como terminas con llamadas telefónicas a las 3am.

Etapa 1: Staging

Despliega la nueva versión en un entorno de staging. Ejecuta tu suite completa de evaluación automatizada. Compara puntuaciones contra la versión actual de producción. Si alguna métrica cae más de 2 puntos porcentuales, detente e investiga.

Etapa 2: Revisión Humana

Haz que alguien — idealmente alguien que conoce el dominio del cliente — revise 20-30 salidas del modelo de staging. Enfócate en:

• ¿El tono coincide con lo que espera el cliente?
• ¿Hay nuevos modos de fallo?
• ¿Arreglamos los problemas que el reentrenamiento debía abordar?

Etapa 3: Despliegue Canary

Dirige el 10% del tráfico de producción a la nueva versión. Monitorea por 24-48 horas. Compara latencia, tasas de error y — si tienes métricas de calidad automatizadas — calidad de salida entre las dos versiones.

Si el canary se ve saludable, sube al 50% por otras 24 horas.

Etapa 4: Despliegue Completo

Redirige el 100% del tráfico a la nueva versión. Mantén la versión anterior cargada y lista para rollback instantáneo por al menos 7 días.

Línea temporal total para una actualización de modelo: 3-5 días desde staging hasta despliegue completo. Esto se siente lento hasta que lo comparas con los 2-3 días de limpieza después de un despliegue instantáneo malo.

Procedimiento de Rollback

El rollback debe ser rápido, confiable y ensayado. Aquí está el procedimiento:

Preparación (Haz Esto Antes de Necesitarlo)

1. Mantén las últimas 3 versiones calientes. Los pesos de sus adaptadores deben estar en la misma máquina que tu infraestructura de servicio, listos para cargar. No archives versiones antiguas a almacenamiento frío hasta que tengas 3 versiones más nuevas por delante.

2. Define el objetivo de rollback. Para cada cliente, nombra explícitamente cuál versión es el objetivo de rollback. Usualmente es la versión de producción anterior, pero a veces quieres retroceder más.

3. Prueba el rollback. Una vez al mes, practica revertir un modelo no crítico. Cronometrálo. Si toma más de 60 segundos, arregla tus herramientas.

Ejecución (Cuando las Cosas Salen Mal)

1. Intercambia el puntero del adaptador. Cambia la configuración de servicio para apuntar a los pesos del adaptador de la versión de rollback. Como el modelo base permanece cargado, esto es un intercambio en caliente de adaptador — no se necesita reinicio.

2. Confirma el intercambio. Envía 5-10 entradas de prueba conocidas a través del modelo y verifica que las salidas coincidan con el comportamiento esperado para la versión de rollback.

3. Notifica al cliente. Envía un mensaje breve y factual: "Identificamos un problema con la última actualización del modelo y hemos revertido a la versión estable anterior (v1.2.0). El servicio está restaurado. Estamos investigando la causa raíz y proporcionaremos una actualización dentro de 24 horas."

4. Investiga. Compara las salidas de la versión fallida contra las salidas de la versión de rollback en las mismas entradas. Encuentra qué salió mal. Causas comunes: contaminación de datos de entrenamiento, error de configuración, actualización del modelo base que cambió la tokenización.

Tiempo objetivo de rollback: menos de 60 segundos desde la decisión hasta el rollback confirmado. Esto es alcanzable con intercambio de adaptadores LoRA en Ertas.

Plantilla de Registro de Cambios para Clientes

Cada actualización de modelo debería venir con un registro de cambios orientado al cliente. Mantenlo claro, no técnico y enfocado en resultados:

## Actualización de Modelo: Asistente de Soporte v1.3.0
**Fecha:** 10 de marzo de 2026
**Tipo:** Reentrenamiento mensual

### Qué Cambió
- Incorporados 3 meses de datos nuevos de tickets de soporte (1,247 tickets)
- Mejorado el manejo de preguntas relacionadas con reembolsos
- Reducidas las escalaciones falsas a agentes humanos

### Comparación de Rendimiento
| Métrica | Anterior (v1.2.1) | Actualizado (v1.3.0) |
|--------|-------------------|-------------------|
| Precisión | 94.2% | 95.8% |
| Tasa de alucinación | 2.1% | 1.4% |
| Tiempo promedio de respuesta | 1.3s | 1.2s |

### Limitaciones Conocidas
- Todavía tiene dificultades con preguntas de paquetes multi-producto (trabajando en esto para la próxima actualización)

### Plan de Rollback
La versión anterior (v1.2.1) está disponible para rollback instantáneo si surge algún problema.

Este nivel de transparencia construye confianza. Los clientes que reciben reportes de rendimiento no cancelan — actualizan su plan.

Almacenamiento de Artefactos

Cada versión necesita un paquete de artefactos completo y autocontenido:

adapters/acme/support/v1.3.0/
├── adapter_weights/        # Los pesos LoRA reales
├── training_config.yaml    # Hiperparámetros exactos de entrenamiento
├── training_data.hash      # SHA-256 de datos de entrenamiento (no los datos en sí)
├── eval_results.json       # Resultados completos de suite de evaluación
├── inference_config.yaml   # Parámetros de servicio
├── changelog.md            # Registro de cambios orientado al cliente
└── metadata.yaml           # Todos los campos del registro de versiones

Almacena estos en almacenamiento local rápido para las últimas 3 versiones por cliente. Archiva versiones más antiguas en almacenamiento de objetos (S3, GCS o equivalente). Rara vez los necesitarás, pero cuando lo hagas — auditoría regulatoria, disputa con cliente, reproducción de un problema histórico — estarás agradecido de que existan.

Almacenamiento total por versión para un adaptador LoRA de 7B: aproximadamente 50-250MB dependiendo del rango. Con 3 versiones calientes por 12 clientes = 36 paquetes de versiones, estás viendo 2-9GB. Trivial.

Errores Comunes

Sobrescribir en lugar de versionar. "Solo guardaré el nuevo adaptador en la misma ruta." Felicidades, has destruido tu capacidad de rollback. Siempre escribe en una nueva ruta versionada.

Sin evaluación antes de desplegar. "La loss de entrenamiento bajó, así que debe ser mejor." La loss de entrenamiento te dice que el modelo memorizó tus datos. Las puntuaciones de evaluación te dicen que puede realmente realizar la tarea. Son cosas diferentes.

No rastrear qué datos entrenaron qué modelo. Seis meses a partir de ahora, un cliente te pide eliminar ciertos datos del conjunto de entrenamiento de su modelo (GDPR, discovery legal, lo que sea). Si no sabes qué datos produjeron qué versión, estás atascado reentrenando todo desde cero.

Saltarse el despliegue canary. "Pasó la evaluación, simplemente desplegémoslo." Las suites de evaluación no capturan todo. El tráfico real de producción descubre casos extremos que tu conjunto de prueba no cubrió. Canary al 10% por 24 horas. Siempre.

Sin pruebas de rollback. No has probado tu procedimiento de rollback desde que lo configuraste hace 6 meses. El formato de configuración cambió. La ruta del script cambió. La clave SSH expiró. Pruébalo mensualmente.

La Ventaja de Ertas

Ertas Studio incorpora el versionado en el flujo de trabajo de despliegue. Cada modelo desplegado a través de Ertas obtiene rastreo automático de versiones, almacenamiento de artefactos y rollback con un clic. El registro de versiones es tu dashboard — ves qué está desplegado dónde, qué está disponible para rollback y qué está en staging para despliegue.

El pipeline de despliegue soporta enrutamiento canary de serie. Configura tu porcentaje canary, período de monitoreo y umbrales de auto-rollback. Si el canary falla tus puertas de calidad, se revierte automáticamente antes de que siquiera te despiertes.

Porque a las 3am, la mejor respuesta a incidentes es la que ya sucedió.

---

Para más sobre operaciones de agencia, consulta nuestra guía de DIY vs. fine-tuning con Ertas para agencias y la guía de operaciones multi-modelo.