English · Español

Lab — Inyección de spikes (reproducir una spike de loss controlada y aplicar el checklist de estabilidad)¶

Esta práctica te deja causar una spike a propósito en un punto conocido del entrenamiento, y luego recorrer el árbol de stability-check.md para confirmar que tu diagnóstico coincide con la spike inyectada. Es el ejercicio de "saber leer el dashboard" en su forma más limpia.

Setup¶

Prerrequisito: el mini-GPT de la Fase 18 entrena limpio con seed 42 sobre el corpus de §A13. Tienes experiments/18-baseline/ con un dashboard.html sano.

Este lab añade un knob de inyección a src/minitrain/loop.py que te permite perturbar el entrenamiento de forma determinista en un paso elegido. Las inyecciones son reparables a posteriori — el modelo se recupera si la perturbación cesa.

Tipos de inyección¶

Implementarás y probarás tres inyecciones, en orden de sutileza.

Inyección A: gradiente escalado (ruidoso)¶

En un paso elegido \(K\), multiplica cada gradiente por 50× antes del clip-y-step del optimizador. Cancela el multiplicador después del paso \(K\).

def maybe_inject(step, grads, cfg):
    if cfg.injection == "scale" and step == cfg.injection_step:
        return {k: 50.0 * g for k, g in grads.items()}
    return grads

Esperado: spike visible en el panel de loss en \(K\), grad-norm pre-clip ~50× sobre la línea base, el clipping se activa (post-clip ~1.0), el loss se recupera en 20-40 pasos porque los momentos sólo vieron un update malo.

Inyección B: bad-batch (sutil)¶

En el paso \(K\), reemplaza el batch por un batch sintético "malo": 8 copias de la misma frase con un token raro (p. ej., 8 copias de She has written the letter.). Cancela tras el paso \(K\).

def maybe_inject(step, batch, cfg):
    if cfg.injection == "bad_batch" and step == cfg.injection_step:
        return [BAD_SENTENCE] * batch.size
    return batch

Esperado: spike menor en loss, spike mayor en grad-norm (la concentración de tokens raros es exactamente el patrón long-tail de §A13), recuperación más larga (~50 pasos).

Inyección C: corrupción de estado del optimizador (taimada)¶

En el paso \(K\), multiplica v_t por 100× para un parámetro (por ejemplo, el bias de la LM-head). Cancela tras \(K\), pero la corrupción persiste en el estado de momentos.

def maybe_inject(step, optimizer_state, cfg):
    if cfg.injection == "v_corrupt" and step == cfg.injection_step:
        optimizer_state["v"]["lm_head.bias"] *= 100.0

Esperado: no hay spike en loss en el paso \(K\). En su lugar, una elevación lenta en los siguientes 30 pasos a medida que el bias de la LM-head se subactualiza (porque \(\hat v\) es demasiado grande, así que el step efectivo del bias es demasiado pequeño) hasta que la EMA de \(v\) decae la corrupción. Es la inyección más taimada — no parece una spike, parece un plateau temporal.

Procedimiento¶

Ejecuta la baseline: seed=42 injection=none just phase-19-train.
Ejecuta la Inyección A en el paso 500: seed=42 injection=scale injection_step=500 just phase-19-train.
Ejecuta la Inyección B en el paso 500: seed=42 injection=bad_batch injection_step=500 just phase-19-train.
Ejecuta la Inyección C en el paso 500: seed=42 injection=v_corrupt injection_step=500 just phase-19-train.
Para cada una: abre el dashboard. Recorre stability-check.md desde §1 hasta la primera hoja que coincida. Escribe tu diagnóstico en learners/<name>/phase-19/spike-diagnoses.md:
ID de la inyección (qué run)
en qué nodo de stability-check.md te paraste
tu diagnóstico (una frase)
tu remediación (una frase)
Revela las inyecciones: las soluciones están en solutions/04-spike-injection-ref.md (no mires antes del paso 5).
Puntúa: número de diagnósticos correctos / 3.

Condición de parada¶

Estás listo cuando las tres inyecciones están diagnosticadas correctamente y tu learners/<name>/phase-19/notes/lessons.md tiene tres líneas nuevas describiendo los tres modos de fallo.

Definition of Done¶

src/minitrain/loop.py tiene un hook maybe_inject limpio (por defecto no-op).
Tres runs en experiments/19-injection-{A,B,C}/ con manifests.
spike-diagnoses.md rellenado antes de mirar las soluciones.
Los tres diagnósticos coinciden con la inyección provocada.

Por qué este lab es distinto de `02-break-it.md`¶

02-break-it.md aporta tres configuraciones pre-rotas y te pide diagnosticarlas una vez. Este lab te da el mecanismo de inyección y te pide causar el fallo en un paso elegido. La diferencia:

02-break-it.md mide: "¿sabes leer el dashboard?"
04-spike-injection.md mide: "¿sabes predecir la respuesta del dashboard a una perturbación conocida?"

La segunda habilidad es más difícil y más útil. Cuando depures runs de entrenamiento reales en la Fase 26 o 28, no sabrás qué rotura se aplicó — pero necesitarás hipotetizar una perturbación que produciría el patrón observado. Este lab es la dirección inversa de esa habilidad, practicada en limpio.

Referencias cruzadas¶

theory/04-loss-spike-postmortem-template.md — escribe un post-mortem para cada inyección.
stability-check.md — el árbol que recorres para el diagnóstico.
lab/02-break-it.md — el lab prerrequisito (forma distinta, mismo dominio).