Prueba A/B de API en la nube vs IA en el dispositivo en produccion

Tienes una funcion de IA en la nube en produccion. Tienes un modelo fine-tuned en el dispositivo listo para desplegar. Antes de migrar a todos los usuarios, necesitas evidencia de que el modelo en el dispositivo iguala o supera la calidad del modelo en la nube.

Una prueba A/B en produccion te da esa evidencia con usuarios reales, consultas reales y comportamiento real.

Que probar

El objetivo no es probar que el modelo en el dispositivo es "tan bueno" como el modelo en la nube. El objetivo es medir si los usuarios notan o les importa alguna diferencia, y cuantificar las mejoras operativas (latencia, costo, capacidad offline).

Metricas primarias

Metricas secundarias

Metricas a evitar

Puntuaciones de calidad del modelo (perplejidad, BLEU, ROUGE): A los usuarios no les importa la perplejidad. Les importa si la funcion resolvio su problema. Las metricas de calidad automatizadas son utiles durante el desarrollo pero no como metricas primarias de prueba A/B.

Longitud de respuesta: Mas largo no es mejor. Mas corto no es peor. La longitud es un proxy de nada util.

Diseno de cohortes

Asignacion aleatoria

Asigna usuarios a cohortes en la primera interaccion de IA:

fun getAiCohort(userId: String): AiCohort {
    // Hash deterministico asegura que el mismo usuario siempre obtiene la misma cohorte
    val hash = userId.hashCode().absoluteValue
    return if (hash % 100 < 50) AiCohort.CLOUD else AiCohort.ON_DEVICE
}

Usa el hash del ID de usuario (no aleatorio) para que cada usuario permanezca en su cohorte entre sesiones.

Tamanos de cohorte

Para una division 50/50 con 10K MAU, tienes 5,000 usuarios por cohorte. Dos semanas te dan resultados estadisticamente significativos para diferencias de 5% o mas.

Despliegue gradual

Comienza conservador:

1. Semana 1: 10% en dispositivo, 90% nube (detectar crashes y problemas criticos)
2. Semana 2: 25% en dispositivo, 75% nube (recopilar metricas iniciales)
3. Semana 3-4: 50/50 (prueba A/B completa con poder estadistico)
4. Despues de resultados: Escalar a 100% en dispositivo si las metricas pasan

Arquitectura de implementacion

La abstraccion del proveedor de IA

Ambas variantes deben pasar por la misma interfaz:

interface AiProvider {
  generate(prompt: string, options: GenerateOptions): Promise<AiResponse>;
  isAvailable(): boolean;
}

class CloudProvider implements AiProvider {
  async generate(prompt, options) {
    const response = await callCloudAPI(prompt, options);
    return { text: response.text, source: "cloud", latencyMs: response.latency };
  }
  isAvailable() { return navigator.onLine; }
}

class OnDeviceProvider implements AiProvider {
  async generate(prompt, options) {
    const response = await llamaGenerate(prompt, options);
    return { text: response.text, source: "on_device", latencyMs: response.latency };
  }
  isAvailable() { return this.modelLoaded; }
}

Enrutamiento

function getProvider(userId: string): AiProvider {
  const cohort = getAiCohort(userId);

  if (cohort === "on_device" && onDeviceProvider.isAvailable()) {
    return onDeviceProvider;
  }

  // Respaldo a nube si el modelo en dispositivo no esta cargado aun
  return cloudProvider;
}

Registro de eventos

Registra cada interaccion de IA con cohorte y metricas:

function logAiInteraction(event: AiInteractionEvent) {
  analytics.track("ai_interaction", {
    cohort: event.cohort,           // "cloud" o "on_device"
    action: event.action,           // "generate", "accept", "retry", "abandon"
    latency_ttft_ms: event.ttft,    // Tiempo al primer token
    latency_total_ms: event.total,  // Tiempo total de respuesta
    tokens_generated: event.tokens,
    user_action: event.userAction,  // Que hizo el usuario despues (enviar, editar, descartar)
    offline: !navigator.onLine,
    device_model: getDeviceModel(),
    timestamp: Date.now(),
  });
}

Analizando resultados

Significancia estadistica

Usa una prueba chi-cuadrado para metricas de tasa (tasa de completacion, tasa de reintento) y una prueba t para metricas continuas (latencia, tiempo a accion).

Nivel de confianza minimo: 95% (p menor a 0.05). Para metricas criticas, usa 99%.

Resultados esperados

Basado en migraciones tipicas de en dispositivo vs nube:

Cuando enviar en dispositivo

Envia si:

• La tasa de completacion de tarea esta dentro del 3% de la nube (no estadisticamente peor)
• Sin aumento en tasa de crashes
• La latencia es mediblemente mejor (esperado)
• El engagement de la funcion es estable o mejorado

No envies si:

• La tasa de completacion de tarea es significativamente menor (caida mayor al 5%)
• La tasa de crashes aumenta (problemas de memoria en algunos dispositivos)
• Los usuarios en la cohorte en dispositivo tienen satisfaccion mediblemente menor

Cuando iterar

Si el modelo en dispositivo tiene menor rendimiento en completacion de tarea pero gana en latencia y engagement, la calidad del modelo necesita mejora. Opciones:

• Agregar mas datos de entrenamiento y re-entrenar
• Cambiar a un modelo mas grande (1B a 3B)
• Mejorar fine-tuning (mas epocas, diferentes hiperparametros)
• Expandir cobertura de datos de entrenamiento para los casos fallidos

Re-ejecuta la prueba A/B con el modelo mejorado.

Casos extremos

Modelo en dispositivo aun no descargado

Los usuarios en la cohorte en dispositivo que no han descargado el modelo aun deben recurrir a la nube. Rastrea cuanto tiempo toma para que la cohorte en dispositivo se active completamente (todos los usuarios tienen el modelo).

Desajuste de capacidad de dispositivo

Algunos dispositivos de usuarios pueden no soportar el modelo en dispositivo (RAM insuficiente). Estos usuarios deben permanecer en la nube independientemente de la asignacion de cohorte. Rastrea que porcentaje de la cohorte en dispositivo recurre a la nube y en que dispositivos.

Comparacion offline

La cohorte en dispositivo tiene una capacidad que la cohorte nube no: IA offline. Rastrea el uso de IA offline por separado. Esto es valor incremental que no aparece en una comparacion directa de calidad.

El caso de negocio

La prueba A/B produce los datos para la decision de migracion:

• Delta de calidad: La experiencia del usuario es equivalente?
• Delta de costo: Cuanto cuesta la cohorte nube por mes?
• Delta de engagement: Los usuarios interactuan mas con IA mas rapida?
• Nueva capacidad: Cuanto uso de IA offline existe?

Para la mayoria de modelos bien fine-tuned, la prueba A/B confirma lo que el equipo de ingenieria espera: calidad equivalente, mejor latencia, cero costo, mas capacidad offline. Los datos hacen que la decision de migracion sea directa.

La calidad del fine-tuning es la variable clave. Plataformas como Ertas habilitan iteracion rapida: re-entrena con datos mejorados, exporta GGUF, despliega a la cohorte en dispositivo y mide de nuevo.