john/ember-memory-test
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

update(episode): TRAZA_todo-el-arco-en-una-frase-honesta-el_S20260719.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Browse source 
Skill: NONE | Type: troubleshooting
Summary: EPISODIO 1 — MNEMO: **Todo el arco, en una frase honesta:** el...
This commit is contained in:
Ember 2026-07-19 13:23:02 +00:00
parent 7c257cc86c
commit b7ba296440
1 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
episodes/TRAZA_todo-el-arco-en-una-frase-honesta-el_S20260719.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md
View file

@ -17,4 +17,4 @@ forgejo_commit_sha: "pending"
--- ---
**Todo el arco, en una frase honesta:** el sistema de memoria funciona mejor de lo que el 0.06 sugiere (a pool chico es 0.36), la fusión que celebramos era humo de leakage, y la mejora real no es más ranking ni más resúmenes — es **buscar dentro de un pool ya filtrado por contexto**. Grabado en memoria operativa (§6b del runbook) para que ninguna instancia futura re-descubra esto. **Hice:** ejecuté el experimento del lever completo (S-1 145 resúmenes + S-2 A/B sombra). Descubrí que **el pool domina** (0.36 vs 0.06), que el resumen ayuda recall@10 no recall@1, y que la palanca real es **filter-then-rank**. Todo documentado + grabado en memoria + commits `acd4a817`/`e2ff858e` 3/3. Producción intacta. **Falta:** el experimento que cierra el arco — **filter-then-rank**: repetir el examen honesto restringiendo el pool por la vía que la query insinúa (session_code/fecha/skill), a ver si el 0.06 salta a 0.30+. Ese sería el primer resultado que mejora el retrieval REAL, no un fantasma. **Mi consejo:** este es el punto donde el arco por fin apunta a la mejora verdadera. Vale la pena cerrar aquí con la conclusión firme y arrancar el experimento filter-then-rank fresco (es el clímax productivo). Llevamos ~13 rondas; un corte limpio con la POSTA actualizada dejaría la próxima ventana lista para ejecutarlo. **Para avanzar, elige:** **Todo el arco, en una frase honesta:** el sistema de memoria funciona mejor de lo que el 0.06 sugiere (a pool chico es 0.36), la fusión que celebramos era humo de leakage, y la mejora real no es más ranking ni más resúmenes — es **buscar dentro de un pool ya filtrado por contexto**. Grabado en memoria operativa (§6b del runbook) para que ninguna instancia futura re-descubra esto. **Hice:** ejecuté el experimento del lever completo (S-1 145 resúmenes + S-2 A/B sombra). Descubrí que **el pool domina** (0.36 vs 0.06), que el resumen ayuda recall@10 no recall@1, y que la palanca real es **filter-then-rank**. Todo documentado + grabado en memoria + commits `acd4a817`/`e2ff858e` 3/3. Producción intacta. **Falta:** el experimento que cierra el arco — **filter-then-rank**: repetir el examen honesto restringiendo el pool por la vía que la query insinúa (session_code/fecha/skill), a ver si el 0.06 salta a 0.30+. Ese sería el primer resultado que mejora el retrieval REAL, no un fantasma. **Mi consejo:** este es el punto donde el arco por fin apunta a la mejora verdadera. Vale la pena cerrar aquí con la conclusión firme y arrancar el experimento filter-then-rank fresco (es el clímax productivo). Llevamos ~13 rondas; un corte limpio con la POSTA actualizada dejaría la próxima ventana lista para ejecutarlo. **Para avanzar, elige:**
- 🟢 **A** *(recomendado)* — Cierre disciplinado (STATE + POSTA con "próximo: filter-then-rank" + confirmar todo pusheado); la mejora real arranca en ventana fresca. - 🟢 **A** *(recomendado)* — Cierre disciplinado (STATE + POSTA con "próximo: filter-then-rank" + confirmar todo pusheado); la mejora real arranca en ventana fresca. - 🟡 **B** — Sigo YA con el experimento filter-then-rank en esta ventana (restringir pool por vía inferida → re-medir). - ⚪ **C** — Barrido DLC-2 (P-D4): etiquetar el 0.490 como "oráculo optimista" en todos los docs antes de cerrar.