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

feat(episode): TRAZA_zero-deuda-tcnica-del-chat-cerrada_S20260801.R2_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Browse source 
Skill: TESSERA | Type: troubleshooting
Summary: EPISODIO 2 — ember_experience: ✅ Zero deuda técnica del chat: cerrada
This commit is contained in:
Ember 2026-08-02 02:39:26 +00:00
parent 7ee7473352
commit 707df9969a
1 changed files with 25 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

25
episodes/TRAZA_zero-deuda-tcnica-del-chat-cerrada_S20260801.R2_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md Normal file
View file

@ -0,0 +1,25 @@
---
episode_id: "9fcab7e4-dac8-4f55-bef4-1322ca2cac68"
puente_flat: "TRAZA_zero-deuda-tcnica-del-chat-cerrada_S20260801.R2_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
session_code: "S20260801.PIPELINE_FIXES"
acto_dialogico: "informar"
actor_flujo: "multi_actor"
criticidad_aegis: "low"
skill_dominante: "TESSERA"
fase_proyecto: "operations"
tipo_semantico: "troubleshooting"
summary_one_line: "EPISODIO 2 — ember_experience: ✅ Zero deuda técnica del chat: cerrada"
source_type: "claude_code"
trust_boundary: "internal"
created_at: "2026-08-02T02:39:16.096430+00:00"
relectura_tagged: false
forgejo_commit_sha: "pending"
---
**De dónde viene:** un cambio silencioso de espacio (probablemente en el deploy del 19jul o un cambio del lado de Google/LiteLLM — el nombre del modelo no cambió) partió tu memoria en dos mitades que no se hablan bien: la mitad vieja responde al 57% en primera posición, la nueva al 72%.
**Consecuencias por camino:** si re-embebes, el recall de la mitad vieja debería volver a niveles pre-escalón (~0.90 medido entonces), a costo de ~731 llamadas de embedding (minutos, centavos) y tocando la colección de producción — con backup Qdrant previo obligatorio. Si no lo haces, no se pierde ningún dato (el contenido está intacto), pero cada búsqueda semántica seguirá viendo borroso todo lo anterior al 19 de julio, y el sesgo empeora relativo a medida que crece la mitad nueva.
**Mi inclinación:** hacerlo — es la reparación cuya métrica de éxito ya existe (el propio gate diario la mediría al día siguiente). **Lo que la cambiaría:** si sospechas que el cambio de espacio del 19jul fue *intencional* (parte del deploy del writer v1.1), primero hay que confirmar cuál espacio es el "bueno" antes de re-embeber hacia él.
**La pregunta esencial:** ¿el cambio de embedding del 19 de julio fue algo que tu equipo/deploy decidió, o nadie lo decidió? Si nadie lo decidió, doy el GO al re-embedding como reparación; si fue decidido, hay que leer esa decisión primero.