Que pasa cuando OpenAI depreca el modelo del que depende tu app

El 6 de junio de 2024, OpenAI depreco gpt-4-32k, gpt-4-vision-preview y varios otros modelos. Las apps que usaban estos modelos tenian hasta una fecha especifica para migrar. Despues de esa fecha, las llamadas a la API devolvian errores.

Esta no fue la primera deprecacion. OpenAI ha retirado mas de 15 versiones de modelo desde 2023. GPT-3.5-turbo-0301, GPT-4-0314, text-davinci-003, code-davinci-002. Cada deprecacion forzo a cada app dependiente a migrar.

Si tu app movil depende de un modelo especifico de OpenAI, esto te pasara. La pregunta no es "si" sino "cuando" y "que tan disruptivo."

El patron de deprecacion

El ciclo de vida de modelos de OpenAI sigue un patron:

1. Se lanza un nuevo modelo con una version fechada (ej., gpt-4o-2024-08-06)
2. El alias apunta al mas reciente (ej., gpt-4o apunta a la ultima version fechada)
3. Las versiones fechadas antiguas se deprecan con 3-6 meses de aviso
4. Despues de la fecha de deprecacion, las llamadas al modelo antiguo devuelven errores o se redirigen automaticamente a un reemplazo

El periodo de aviso suena generoso. En la practica, no lo es.

Por que 3-6 meses no es suficiente

Una deprecacion no solo significa cambiar un string de modelo en tu codigo. Cuando cambias de modelo, el comportamiento cambia:

Cambios de formato de salida: Tus prompts fueron afinados para las tendencias de un modelo especifico. Un nuevo modelo puede formatear JSON diferente, usar frases diferentes o manejar casos extremos de forma diferente.

Cambios de precision: Un prompt que logra 90% de precision en gpt-4-0613 podria lograr 85% o 95% en gpt-4o. No sabes cual hasta que pruebes.

Cambios en uso de tokens: Diferentes modelos tokenizan diferente y generan respuestas de diferente longitud. Tu modelo de costos cambia.

Cambios de latencia: Los modelos mas nuevos pueden ser mas rapidos o mas lentos. Tus suposiciones de tiempo de UX pueden romperse.

Cada uno de estos requiere pruebas, re-afinacion de prompts y potencialmente cambios de codigo. Para una app movil, esto tambien significa una nueva version de la app a traves del proceso de revision de App Store.

El problema de las apps moviles

Las web apps pueden desplegar una correccion en minutos. Las apps moviles no.

Revision de App Store: La revision de iOS App Store toma 24-48 horas en promedio. Si necesitas cambiar tu string de modelo, necesitas enviar un nuevo build, esperar la revision y esperar que los usuarios actualicen.

Retraso de actualizacion de usuarios: Incluso despues de enviar una actualizacion, los usuarios no actualizan inmediatamente. El tiempo mediano para que el 80% de usuarios actualicen una app iOS es 1-2 semanas. Android es peor. Puedes tener usuarios en la version antigua llamando a un modelo deprecado por semanas despues de que tu correccion salga.

Requisitos de pruebas: Cada nueva version de modelo necesita pruebas de regresion en todo tu conjunto de funciones de IA. Las pruebas automatizadas ayudan, pero la IA basada en prompts es inherentemente no determinista. El QA manual frecuentemente es requerido.

El riesgo en cascada

Si tu app llama al modelo deprecado directamente (string de modelo hardcodeado), la linea de tiempo luce asi:

1. OpenAI anuncia deprecacion (Dia 0)
2. Notas el anuncio (Dia 1-14, dependiendo del monitoreo)
3. Pruebas el modelo de reemplazo contra tus prompts (Dia 14-30)
4. Re-afinas los prompts que no funcionan con el nuevo modelo (Dia 30-60)
5. Envias un nuevo build de la app (Dia 60-65)
6. Apple revisa el build (Dia 65-67)
7. Los usuarios actualizan (Dia 67-80+)

Con una ventana de deprecacion de 90 dias, estas justo en el limite. Con una ventana de 60 dias, podrias no lograrlo.

No es solo OpenAI

Todos los proveedores de IA en la nube deprecan modelos:

Anthropic ha deprecado Claude 2, Claude 2.1 y Claude Instant. Los modelos de Claude 3 seguiran.

Google ha deprecado PaLM, Bard y versiones antiguas de Gemini. La linea de modelos Gemini cambia regularmente.

El patron es de toda la industria: El desarrollo de modelos de IA se mueve rapido. Los proveedores no tienen incentivo para mantener modelos antiguos indefinidamente. El costo de computo de servir modelos obsoletos es real, y el reemplazo siempre es "mejor" desde la perspectiva del proveedor.

Estrategias de mitigacion (dentro del modelo de nube)

Usa alias, no versiones fechadas

Llama a gpt-4o en lugar de gpt-4o-2024-08-06. El alias apunta automaticamente a la ultima version. Obtienes el nuevo modelo sin cambios de codigo.

La desventaja: Pierdes control sobre cuando cambia el comportamiento. El modelo puede cambiar debajo de ti sin aviso. Tus prompts que funcionaban ayer pueden funcionar diferente hoy.

Configuracion de modelo del lado del servidor

No hardcodees el nombre del modelo en tu app movil. Almacenalo en una configuracion del lado del servidor que la app obtiene al iniciar:

{
  "ai_model": "gpt-4o-mini",
  "ai_provider": "openai"
}

Esto te permite cambiar modelos sin enviar una actualizacion de app. Pero no resuelve el problema de pruebas de comportamiento. Sigues enviando un modelo no probado a produccion.

Versionado de prompts

Mantiene un registro de prompts que empareja cada prompt con el modelo contra el que fue probado. Cuando cambias modelos, el registro marca que prompts necesitan re-pruebas.

Es buena practica de ingenieria pero agrega complejidad operativa.

La solucion estructural

El problema de deprecacion existe porque dependes de la infraestructura de alguien mas y del calendario de alguien mas. Cuando eres dueno del modelo, no hay deprecacion.

Los modelos en el dispositivo que fine-tuneas y despliegas son tuyos:

• El archivo GGUF en el dispositivo del usuario no expira
• Ningun tercero puede deprecar tu modelo
• Tu controlas cuando y si actualizar
• Las actualizaciones de modelo ocurren en tu calendario, no el de un proveedor

El camino de actualizacion del modelo se convierte en:

1. Tu decides actualizar (basado en tus propias pruebas, no en un plazo)
2. Fine-tuneas la nueva version
3. Pruebas contra tus benchmarks de calidad
4. Envias la actualizacion a usuarios via tu pipeline normal de entrega de modelos
5. El modelo antiguo continua funcionando para usuarios que no han actualizado

Sin plazos forzados. Sin migraciones de emergencia. Sin presion de revision de App Store.

El costo de la estabilidad

Fine-tunear un modelo cuesta $5-50 por ejecucion en plataformas como Ertas. Ese es el costo de completa independencia de calendarios de deprecacion, cambios de comportamiento y plazos de proveedores.

Compara eso con el costo de ingenieria de una migracion forzada: 2-4 semanas de tiempo de desarrollador para pruebas, re-afinacion de prompts y despliegue. A costos tipicos de desarrollador, una sola respuesta a deprecacion cuesta $5,000-$20,000 en tiempo de ingenieria.

La ruta de fine-tuning no es solo mas estable. Es mas economica por evento de migracion.

Que hacer ahora

1. Inventaria tus dependencias de modelo. Que modelos llama tu app? Son versiones fechadas o alias?
2. Configura monitoreo de deprecaciones. Suscribete al changelog de OpenAI, anuncios de Anthropic y actualizaciones de API de Google.
3. Construye un plan de migracion. Si tu modelo principal fuera deprecado manana, cuanto tomaria enviar una correccion?
4. Comienza a recopilar datos de entrenamiento. Cada llamada a la API que haces hoy es un potencial ejemplo de fine-tuning para el modelo que seras dueno manana.
5. Evalua la ruta al dispositivo. Fine-tunea un modelo pequeno con tus datos de dominio, exporta GGUF, prueba en el dispositivo. Cuando iguale tu barra de calidad, despliegalo.

El objetivo no es evitar las APIs en la nube completamente. El objetivo es dejar de depender de infraestructura que no controlas para funciones de las que dependen tus usuarios.