ember-memory-test/episodes/TRAZA_enjambre-lanzado_S20260823.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md
Ember 9b97053e15 feat(episode): TRAZA_enjambre-lanzado_S20260823.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD
Skill: NONE | Type: troubleshooting
Summary: EPISODIO 1 — HyDE: Enjambre lanzado
2026-08-23 16:51:09 +00:00

3.2 KiB

episode_id puente_flat session_code acto_dialogico actor_flujo criticidad_aegis skill_dominante fase_proyecto tipo_semantico summary_one_line source_type trust_boundary created_at relectura_tagged forgejo_commit_sha
819b4198-8aba-46fa-92de-93e445a66bd9 TRAZA_enjambre-lanzado_S20260823.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD S20260823.SID4BCC8DB97BCD informar multi_actor low NONE operations troubleshooting EPISODIO 1 — HyDE: Enjambre lanzado claude_code internal 2026-08-23T16:51:06.564191+00:00 false pending

Enjambre lanzado

Run: wf_1c8c96af-1a7 · puedes verlo en vivo con /workflows

Qué está corriendo

Fable diseña los carriles sobre los 6 pendientes que descubrí en el scout (no inventé): campos de curación degenerados · marca de curación write-time · prueba discriminante de HyDE · techo con pool mayor · los dos instrumentos sin veredicto · si conectar LiveBench.

Luego trabajadores Opus analizan cada carril, y tres lentes adversariales distintas (correctitud · evidencia reproducible · consecuencia real) intentan refutar el hallazgo principal de cada uno. Sobrevive lo que aguanta 2 de 3. Cierra Fable auditando.

Tamaño: ~26 agentes. Dentro del rango sano — el propio skill documenta que un enjambre de 173 agentes agotó el límite de sesión y perdió el 89% de sus verificadores.

Antes de eso: el reranker quedó cerrado con dato

Denso Denso + BGE
recall@1 0,167 0,050
recall@5 0,333 0,200

Empeoró 45 casos frente a 19 que mejoró. No se adopta.

Y el hallazgo que vale más que ese veredicto: en 54 de 120 preguntas el episodio correcto ni aparece en el top-20. El techo de cualquier reordenación es 0,55.

Eso confirma con números lo que los tres auditores externos dijeron leyendo un dossier: el cuello está en la recuperación, no en el orden. Y deja una lección incómoda: la fusión V1 primero y el reranker después fueron dos intentos de arreglar la ordenación, cuando el 45% del problema ocurre antes. Dos capas de reordenación sobre un pool que no contiene la respuesta.

Commit 17af266f, verificado presente en los tres remotos.

Hice — Cerré el reranker con medición válida (0% error, n=120) y descubrí el techo de 0,55. Lancé el enjambre sobre los 6 pendientes restantes, con dos guardarraíles: ningún carril escribe (hay otra instancia commiteando) y ninguno hace SSH (ya nos cortó dos veces).

Falta — El resultado del enjambre. Te aviso cuando termine.

Mi consejo — Cuando llegue, mira primero R2: atacar el techo, no el orden. Hoy quedó demostrado que llevábamos dos intentos invirtiendo en el sitio equivocado. Ese es el aprendizaje caro de la jornada, y conviene que no se diluya entre los demás hallazgos.

Para avanzar, elige:

  • 🟢 A (recomendado) — Esperamos el enjambre y cerramos con su veredicto.
  • 🟡 B — Mientras corre, mido el techo con K=50 y K=100 (responde si ampliar el pool arregla el 45%).
  • C — Paramos aquí; el enjambre seguirá y su resultado quedará para el próximo chat.

🟢 GREEN ~845K