¿Cómo gestionas las versiones de modelo para poder volver atrás rápido cuando algo sale mal?

Trata los modelos como artefactos versionados e inmutables en un registro, nunca como un fichero sobrescrito en el sitio. Cada versión registra el commit del código de entrenamiento, la instantánea de datos, sus métricas y una etapa como staging o producción. El servicio lee de la configuración qué versión cargar, así que la vuelta atrás es un cambio de configuración que tarda segundos, y la versión anterior sigue siendo cargable en vez de necesitar una reconstrucción.

Regla uno: un artefacto de modelo es inmutable. Recibe una versión, se escribe una vez, y nada lo sobrescribe nunca, porque el día que necesitas volver atrás es el día que descubres que el fichero viejo fue reemplazado. Cada versión lleva su linaje: el SHA de git del código de entrenamiento, el identificador de la instantánea de datos, la configuración de hiperparámetros, las métricas de evaluación y quién la promovió. Eso significa que cuando alguien pregunte dentro de tres meses por qué el modelo empezó a comportarse distinto en abril, es una consulta y no un proyecto de arqueología. El servicio no tiene la versión escrita a fuego. Lee un puntero de la configuración, así que promover es cambiar el puntero y volver atrás es cambiarlo de vuelta, ambos en segundos. Mantengo la versión anterior cargada en memoria donde la huella lo permite, así que una vuelta atrás no necesita redespliegue ni arranque en frío en un contenedor nuevo. Y la ensayo, porque una ruta de vuelta atrás sin probar no es una ruta de vuelta atrás. En el último equipo hacíamos una a propósito en una ventana de poco tráfico de vez en cuando, y así descubrimos que el cambio de configuración se propagaba bien pero una caché aguas abajo se quedaba con el umbral viejo otros diez minutos.