[Informe de Clase] Introducción al Desarrollo de Sistemas – Semana 29: Verificación de mejoras e introducción al A/B testing

En la Semana 29 implementamos mejoras para los problemas detectados en el análisis de logs de la semana pasada y aprendimos lo básico sobre retesteo y A/B testing (evaluación comparativa) para medir su impacto. Al experimentar el ciclo implementar → verificar → comparar, esta semana fomentó la idea de que “la mejora no está terminada hasta que los números lo demuestran”.

■ Inicio del instructor: “Formula una hipótesis, verifícala y vuelve a refinar”

Prof. Tanaka: “Aunque creas que algo ha mejorado, sin números no lo sabes. El A/B testing es un método muy útil para decidir objetivamente qué versión es realmente mejor.”

■ Objetivos de hoy

1. Implementar las mejoras de la semana pasada (p. ej., extender el TTL de la caché, límites de longitud de entrada, ajustes de fallback).
2. Comparar métricas clave como tiempo de respuesta, tasa de éxito y tasa de reintento (regenerate) antes y después de las mejoras.
3. Diseñar un A/B test sencillo y medir cuál de dos variantes es más efectiva.

■ Ejercicio ①: Implementar y desplegar mejoras (en el entorno de laboratorio)

Cada equipo seleccionó dos o tres mejoras prioritarias del análisis previo, las implementó y las desplegó en el entorno de pruebas. Ejemplos representativos:

• Extensión del TTL de caché: 300 segundos → 900 segundos (reduce peticiones duplicadas en ventanas cortas).
• Preprocesamiento de entrada más estricto: sustituir entradas demasiado largas por un prompt de resumen.
• Texto de fallback mejorado: proporcionar acciones siguientes concretas al usuario (p. ej., “Consulta el sitio oficial”).

Tras la implementación, volvimos a ejecutar pruebas de carga y recolectamos logs usando el mismo script de carga.

■ Ejercicio ②: Medición y comparación de KPIs clave

A partir de los logs recopilados, comparamos las métricas clave de la versión antes de las mejoras (control) y después de las mejoras (test). Métricas de ejemplo vistas en clase:

• Tiempo de respuesta promedio (ms)
• Tasa de éxito (ok / total de peticiones)
• Tasa de reintento (proporción de usuarios que hicieron clic en “regenerate”)
• Tasa de ocurrencia de fallback (proporción de estado fallback)

Fragmento sencillo de agregación (para uso en clase):

# logs_control / logs_test son las listas de logs respectivas
def summarize(logs):
    total = len(logs)
    ok = sum(1 for l in logs if l["status"] == "ok")
    return {
        "total": total,
        "ok_rate": ok / total,
        "avg_latency": sum(l["latency_ms"] for l in logs) / total
    }

Observaciones de estudiantes (ejemplos):

• Extender el TTL de la caché mejoró el tiempo de respuesta promedio alrededor de un 15%.
• Los equipos que añadieron resumen de entradas vieron menos timeouts y mejores tasas de éxito.
  (Las cifras son mediciones de ejemplo de clase y variaron según el equipo.)

■ Ejercicio ③: Diseñar y ejecutar un A/B test sencillo

Aprendimos el propósito y los pasos de diseño de un A/B test y ejecutamos una prueba A/B sencilla en clase.

Pasos básicos del A/B testing

1. Formular una hipótesis: p. ej., “Extender el TTL de caché reduce el tiempo de respuesta promedio y baja la tasa de reintento.”
2. Crear variantes: A = actual (TTL = 300), B = mejorada (TTL = 900).
3. Dividir el tráfico: dirigir la mitad de las peticiones a cada variante (en el laboratorio lo simulamos con asignación aleatoria o por franjas de tiempo).
4. Recolectar suficientes muestras: ventanas muy cortas generan mucha variación.
5. Comparar métricas: evaluar diferencias en KPIs clave y comentar la significancia estadística (solo la introdujimos de forma ligera en clase).
6. Concluir y alimentar el siguiente ciclo de mejora.

En clase usamos un método ligero: ejecutar A y B en ventanas separadas de una hora y después comparar métricas.

■ Discusión: cómo leer los resultados y qué tener en cuenta

Puntos clave que confirmamos en clase a la hora de interpretar resultados:

• Tamaños de muestra pequeños pueden llevar a juicios erróneos.
• Estacionalidad y condiciones de red pueden causar variación.
• Considerar múltiples métricas para una visión global (no solo tiempo de respuesta; valorar también tasa de éxito y métricas de UX).
• Tener en cuenta efectos secundarios de las mejoras (p. ej., un TTL más largo puede reducir la frescura del contenido).

Conclusión de estudiantes: “La Variante A es más rápida, pero la Variante B tiene una tasa de reintento menor… cuál priorizar depende de nuestro objetivo.”

■ Comentario de cierre del instructor

“El A/B testing construye una cultura basada en datos. Formular una pequeña hipótesis, verificarla y conectar los resultados con la siguiente hipótesis: este es un buen hábito para ingenieros. La clave es enfrentarse a los resultados con honestidad.”

■ Reflexiones de los estudiantes

• “Al comparar de verdad vimos que los resultados a menudo no coinciden con nuestras expectativas.”
• “Diseñar A/B parece simple pero es difícil: evitar sesgos es lo esencial.”
• “El ciclo de aprendizaje más corto es mejora → verificación en ciclos breves.”

■ Avance de la próxima semana: operacionalizar mejoras y documentación

La próxima semana vamos a operacionalizar estas mejoras para un uso parecido a producción (crear checklists) y documentar el historial de cambios y los informes de impacto. Trabajaremos en los “sistemas” que sostienen la mejora continua.

Al implementar mejoras y verificarlas con números, la Semana 29 permitió al alumnado vivir el ciclo hipótesis → implementación → verificación → nueva hipótesis, dando un paso firme hacia habilidades prácticas de mejora.