Skip to content

English · Español

Lab 02 — Ejecutar las tres roturas provocadas; diagnosticar cada una desde el dashboard

Objetivo: practicar el diagnóstico. Diagnostica tres fallos provocados usando sólo el dashboard, antes de mirar el código.

Tiempo estimado: 2-3 horas (cada rotura corre en ~30 min, más el tiempo de diagnóstico).

Prerrequisito: Lab 01 (renderer del dashboard) commiteado; experiments/19-healthy/dashboard.html existe como patrón de referencia.


Lo que produces

Un directorio experiments/19-break-it/ que contenga tres sub-experimentos:

experiments/19-break-it/
├── 01/
│   ├── train.py
│   ├── config.yaml
│   ├── inspector.log.jsonl
│   ├── dashboard.html
│   └── manifest.json
├── 02/
│   └── (igual que 01)
├── 03/
│   └── (igual que 01)
└── borja-diagnoses.md      ← TUS diagnósticos, ANTES de mirar

Y, tras el diagnóstico:

  • experiments/19-break-it/diagnosis-score.md — tu auto-puntuación 3/3, ⅔ o ⅓ con notas.

TODOs

Bloque A — escribir los tres scripts de rotura (Claude aporta esqueletos; Borja confirma)

Los tres scripts 01/train.py, 02/train.py, 03/train.py copian cada uno el driver de entrenamiento sano de la Fase 18 y lo corrompen de una forma conocida. Claude los aporta como stubs deliberados al abrir la fase (para que Borja no haga trampa leyendo el código).

Crucial: los nombres de directorio 01, 02, 03 están BARAJADOS. Borja no sabe qué directorio contiene qué rotura. El orden lo determina la receta just break-it-shuffled.

Las tres roturas (en orden aleatorio — Borja las ve como 01/02/03 pero no conoce el mapeo):

  • Init malo. Reemplazar xavier_init(W) por xavier_init(W) * 100.
  • Sin warmup. Poner warmup_steps = 0.
  • Máscara rota. Reemplazar tril_mask(L) por np.ones((L, L), dtype=bool).

Bloque B — ejecutar cada rotura

Para cada uno de 01, 02, 03:

just run-break 01
just run-break 02
just run-break 03

(La receta del Justfile entra en el directorio correspondiente y ejecuta train.py con la config corrupta.)

Cada run produce inspector.log.jsonl y renderiza dashboard.html. Abre cada dashboard en un navegador. Compáralo con la referencia sana.

Bloque C — escribir tus diagnósticos ANTES de mirar

En experiments/19-break-it/borja-diagnoses.md, para cada uno de 01, 02, 03:

## Break 01

**Síntomas observados en el dashboard:**
- Panel 1 (loss): [tu observación]
- Panel 2 (LR): [tu observación]
- Panel 3 (grad norm): [tu observación]
- Panel 4 (activaciones): [tu observación]
- Panel 5 (espectral): [tu observación]
- Panel 6 (muertos): [tu observación]
- Panel 7 (regulares vs irregulares): [tu observación]

**Anomalía más llamativa:** [qué panel se desvió primero / más]

**Hipótesis:** [tu mejor conjetura sobre qué fallo provocado se aplicó]

**Justificación:** [por qué esos síntomas implican ese fallo]

Presta especial atención al Panel 7. El fallo de máscara rota se manifiesta ahí con una firma distintiva: las curvas de regulares e irregulares colapsan a casi cero al unísono, sin gap. Eso no es aprender; es el modelo copiando el token futuro.

Tres secciones, una por rotura. Escribe las tres ANTES de consultar solutions/03-three-failures-ref.md (que revela el mapeo).

Bloque D — revelar y puntuar

Abre solutions/03-three-failures-ref.md (escrito al abrir la fase por Claude después de que Borja commitee borja-diagnoses.md — lo fuerza el hook phase-gatekeeper).

Para cada uno de 01, 02, 03, compara tu hipótesis con el fallo provocado real: - coincidencia - cerca (familia correcta, causa específica equivocada) - fallo

Escribe experiments/19-break-it/diagnosis-score.md:

- Break 01: [actual: bad-init | warmup | mask] — tu hipótesis: [...] — veredicto: [coincidencia/cerca/fallo]
- Break 02: ...
- Break 03: ...

Global: X/3.

Reflexión: [qué aprendiste leyendo el dashboard. ¿Qué panel infravaloraste? ¿Qué heurística funcionó?]

La puntuación de diagnóstico y la reflexión aparecen en PHASE_19_REPORT.md.

Restricciones

  • Sin inspección del código hasta que los diagnósticos estén commiteados. Este es todo el sentido del lab. El .pre-commit-config.yaml del repo incluye un hook que avisa si haces stage de solutions/03-three-failures-ref.md antes que borja-diagnoses.md.
  • Cada rotura corre desde un clon fresco de la config sana. No arrastres estado por accidente.
  • Los diagnósticos son forenses. Cita el panel y la anomalía específica, no "se ve mal".

Condiciones de parada

Hecho cuando:

  1. Los tres ficheros dashboard.html existen y renderizan.
  2. borja-diagnoses.md está commiteado con tres diagnósticos forenses, ANTES de consultar soluciones.
  3. diagnosis-score.md está commiteado DESPUÉS de consultar soluciones.
  4. La puntuación está registrada en PHASE_19_REPORT.md.

Trampas

  • Mirar antes. La restricción más dura. La recompensa de no mirar es la memoria muscular para futuros debugs; si miras, aprendes mucho menos.
  • Leer mal el dashboard. Es fácil pasar por alto el panel 2 (LR) porque es "aburrido" — la rotura de warmup se esconde precisamente ahí. Mira los seis paneles para cada rotura.
  • Confundir paneles. Init malo y máscara rota tienen ambos síntomas de "el Panel 1 de loss se ve raro", pero la dirección es opuesta (explosión a NaN vs sospechosamente bajo). Sé preciso.
  • Correr las roturas en paralelo. No lo hagas. Cada una necesita toda tu atención. El hardware de Borja tampoco puede ejecutarlas en paralelo (NumPy en un solo proceso).

Cuándo consultar solutions/

solutions/02-break-it-ref.md y solutions/03-three-failures-ref.md (compañero teórico) los escribe Claude después de que Borja commitee borja-diagnoses.md. Este es el orden:

  1. Borja commitea las tres ejecuciones de rotura y borja-diagnoses.md.
  2. El subagente phase-gatekeeper verifica el commit.
  3. Claude escribe los ficheros de solución.
  4. Borja los lee y escribe diagnosis-score.md.

Este es el lab más estricto del currículo porque diagnosticar-sin-mirar es una habilidad que no se puede instalar a posteriori.


Siguiente lab: lab/03-overfit-on-purpose.md.