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.htmlexiste 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)porxavier_init(W) * 100. - Sin warmup. Poner
warmup_steps = 0. - Máscara rota. Reemplazar
tril_mask(L)pornp.ones((L, L), dtype=bool).
Bloque B — ejecutar cada rotura¶
Para cada uno de 01, 02, 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.yamldel repo incluye un hook que avisa si haces stage desolutions/03-three-failures-ref.mdantes queborja-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:
- Los tres ficheros
dashboard.htmlexisten y renderizan. borja-diagnoses.mdestá commiteado con tres diagnósticos forenses, ANTES de consultar soluciones.diagnosis-score.mdestá commiteado DESPUÉS de consultar soluciones.- 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:
- Borja commitea las tres ejecuciones de rotura y
borja-diagnoses.md. - El subagente
phase-gatekeeperverifica el commit. - Claude escribe los ficheros de solución.
- 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.