Skip to content

English · Español

Lab 03 — Entrenar más allá de la convergencia; ver abrirse la brecha train/val

Objetivo: prolongar el entrenamiento más allá de la convergencia sobre el corpus mínimo y observar la brecha train/val en el dashboard. Aquí el sobreajuste (overfitting) es una característica, no un bug.

Tiempo estimado: 1-2 horas (1 run de entrenamiento largo + análisis).

Prerrequisito: Lab 02 commiteado (dashboard validado contra fallos provocados).

Lo que produces

Un directorio experiments/19-overfit/ que contenga:

  • train.py — driver de la Fase 18 modificado con T = 4 × Phase_18_T, sin parada temprana.
  • config.yaml — igual que el sano, salvo que T es mucho mayor.
  • inspector.log.jsonl.
  • dashboard.html — dashboard de larga duración que muestra la progresión del overfitting.
  • gap-analysis.md — tu análisis escrito de dónde y cómo se manifiesta el overfitting.
  • manifest.json.

TODOs

Bloque A — preparar el run de entrenamiento largo

En experiments/19-overfit/config.yaml:

training:
  batch_size: 32
  T: 8000              # 4× los 2000 de la Fase 18
  warmup: 100
  lr_max: 3e-3
  lr_min: 3e-4
  weight_decay: 0.1
  grad_clip: 1.0
  betas: [0.9, 0.95]
  eps: 1.0e-8
  eval_every: 50
  ckpt_every: 500

El schedule sigue haciendo decaimiento cosenoidal sobre todo T=8000; el learning rate en el paso 2000 ya no es el mínimo (lo era en la Fase 18), sino el punto medio del coseno. Eso es parte del experimento.

Bloque B — ejecutar el entrenamiento y producir el dashboard

just run-overfit

Expectativa de wall-clock: ~2-3 horas en el i5-8250U de Borja. Usa un gestor de sesiones (tmux, screen) para que sobreviva al cierre del terminal.

Tras el entrenamiento, renderiza dashboard.html con el dashboard.render(...) estándar.

Bloque C — encontrar el inicio del overfitting

Abre dashboard.html. En el Panel 1 (curvas de loss):

  1. ¿Dónde toca fondo la val loss? Registra t_val_min y val_loss(t_val_min).
  2. ¿Dónde toca fondo la train loss? Registra t_train_min y train_loss(t_train_min).
  3. El inicio del overfitting \(t^*\) es aproximadamente t_val_min. Después de \(t^*\), la val loss sube (o se estanca mientras la train sigue cayendo).

Verifica con el gap_t que calcula el detector de inicio de overfitting del dashboard (a partir de la fórmula de theory/02). Debe coincidir con tu lectura visual dentro de ±100 pasos.

Bloque D — escribir gap-analysis.md

En experiments/19-overfit/gap-analysis.md, 3-5 párrafos:

  1. Los números. Indica t_val_min, val_loss(t_val_min), train_loss(t_train_min), el gap final en T=8000.

  2. Qué te dice el dashboard. Más allá del Panel 1, ¿qué cambia? ¿Aumenta el número de neuronas muertas (el overfitting suele "olvidar" patrones raros, matando las cabezas que los gestionan)? ¿Drifta la magnitud de las activaciones por capa?

  3. Implicaciones para la Fase 20. Cuando llegue el harness de evaluación (siguiente fase), el "mejor checkpoint" estará en t_val_min, no en T. La Fase 18 guardó checkpoints cada 500 pasos — confirma que experiments/19-overfit/ tiene un checkpoint en o cerca de t_val_min disponible para las comparaciones de eval de la Fase 20.

  4. Por qué esto es sano. El overfitting sobre un corpus mínimo es una sonda, no un modo de fallo. Indica, en una frase, qué revela el gap train/val sobre la capacidad del modelo.

  5. ¿Qué evitaría el overfitting? Tres opciones: más datos (expansión de la Fase 12), más regularización (weight decay, dropout), o parada más temprana (que configuraríamos con la eval de la Fase 20). No implementes ninguna; sólo indica a cuál acudirías primero y por qué.

Restricciones

  • Sin parada temprana. El sentido del lab es entrenar a través y más allá del inicio del overfitting.
  • Sin ajuste de regularización. Mismo weight_decay que la Fase 18.
  • Una sola configuración. No barras sobre T. Un número, un experimento.

Condiciones de parada

Hecho cuando:

  1. experiments/19-overfit/dashboard.html muestra que la train loss sigue cayendo mientras la val loss ha tocado fondo o ha subido.
  2. gap-analysis.md responde a los cinco párrafos anteriores.
  3. El mejor checkpoint según val (en o cerca de t_val_min) se conserva (no lo sobrescriben checkpoints posteriores).

Trampas

  • A veces el dashboard muestra la val loss bajando muy lentamente más allá de \(t^*\). No es una contradicción — más lento que train significa una brecha que se ensancha. Usa el detector de gap, no el ojo.
  • Olvidarse de extender el schedule. Si mantienes T = 2000 en el schedule pero corres 8000 pasos, el schedule se queda fijo en lr_min durante los últimos 6000 pasos. El experimento sigue siendo válido, pero el panel de LR del dashboard se verá raro. En cualquier caso, documenta qué hiciste.
  • Presión de memoria en un run largo. El log file del Inspector crece linealmente con los pasos. Para T=8000, espera ~50-100 MB de JSONL. Aceptable en la máquina de 62 GiB de Borja.

Cuándo consultar solutions/

Tras commitear gap-analysis.md. La solución en solutions/03-overfit-on-purpose-ref.md (escrita al abrir la fase) compara tus números de gap con la referencia y discute qué hará la Fase 20 con estos datos.

Fin de los labs de la Fase 19. Siguiente fase: docs/phase-20-evaluation-harness/.