feat(episode): BACKFILL_q-d5372b3b-d146-5783-a20f-64527d7cbe68_S20260413_XX.bkf.0.warm_qdr.orphan.in.cc.es.000.BKF_J.B993E_E.255-7

Skill: NONE | Type: chronicle
Summary: Activando NEXUS L3. La pregunta central es: ¿cuál modelo de embedding maximiza l

episodes/BACKFILL_q-d5372b3b-d146-5783-a20f-64527d7cbe68_S20260413_XX.bkf.0.warm_qdr.orphan.in.cc.es.000.BKF_J.B993E_E.255-7.md

@@ -0,0 +1,19 @@
+---
+episode_id: "b993e255-7282-5b82-b91d-a0adf6b63219"
+puente_flat: "BACKFILL_q-d5372b3b-d146-5783-a20f-64527d7cbe68_S20260413_XX.bkf.0.warm_qdr.orphan.in.cc.es.000.BKF_J.B993E_E.255-7"
+session_code: "S20260413"
+acto_dialogico: "informar"
+actor_flujo: "ember_internal"
+criticidad_aegis: "moderate"
+skill_dominante: "NONE"
+fase_proyecto: "maintenance"
+tipo_semantico: "chronicle"
+summary_one_line: "Activando NEXUS L3. La pregunta central es: ¿cuál modelo de embedding maximiza la calidad de retrieval para un sistema de memoria bilingüe (ES/EN) con contenido heterogéneo (técnico, filosófico, opera"
+source_type: "claude_code"
+trust_boundary: "default"
+created_at: "2026-05-10T00:00:00+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+Activando NEXUS L3. La pregunta central es: ¿cuál modelo de embedding maximiza la calidad de retrieval para un sistema de memoria bilingüe (ES/EN) con contenido heterogéneo (técnico, filosófico, operativo)? **Fase N — Definición del espacio de búsqueda** Criterios de evaluación definidos: 1. Calidad semántica general (benchmark MTEB) 2. Rendimiento en español (benchmark STS-ES, MIRACL-ES) 3. Dimensionalidad (mayor = más resolución, pero más costo de storage) 4. Accesibilidad API (sin vendor lock-in) 5. Costo por 1M tokens 6. Tamaño del contexto de input (algunos truncan a 512 tokens) **Fase E — Búsqueda exhaustiva** Modelos candidatos identificados en la literatura y benchmarks actuales: | Modelo | Proveedor | Dims | Max input | MTEB avg | Acceso | |--------|-----------|------|-----------|----------|--------| | text-embedding-3-large | OpenAI | 3072 | 8191 | 64.6 | API directa | | text-embedding-3-small | OpenAI | 1536 | 8191 | 62.3 | API directa | | Gemini Embedding 001 | Google | 3072 | 2048 | 66.1 | OpenRouter/API | | voyage-3-large | Voyage AI | 1024 | 32000 | 65.4 | API directa | | Cohere embed-v3 | Cohere | 1024 | 512 | 64.5 | API directa | | mxbai-embed-large-v1 | Mixedbread | 1024 | 512 | 64.7 | Open source | | e5-mistral-7b-instruct | Microsoft | 4096 | 32768 | 66.6 | Open source (requiere GPU) | **Fase X — Análisis cruzado** Descubrimientos clave de la investigación: 1. **e5-mistral-7b-instruct** lidera en MTEB (66.6) pero requiere GPU dedicada. En LUMEN con QwQ-32B ya ocupando 27GB de 30GB, no hay espacio. Descartado por restricción de hardware. 2. **Gemini Embedding 001** tiene el segundo mejor score general (66.1) y una ventaja crucial: Google lo entrena con datos multilingües nativos — no es un modelo inglés fine-tuned a español, sino entrenado con español desde el inicio. En MIRACL-ES (benchmark de retrieval en español), supera a text-embedding-3-large por 3.2 puntos. 3. **text-embedding-3-large** de OpenAI tiene el modelo evaluado dimensionalidad (3072) pero menor calidad reportada en MTEB y significativamente peor en español. Además, OpenAI ha mostrado historial de deprecación agresiva de modelos sin backward compatibility. 4. **voyage-3-large** tiene input window de 32K tokens (excelente para documentos largos) pero solo 1024 dims — menos resolución semántica. Para nuestros episodios de ~200-500 palabras, el window largo no agrega valor. 5. **Cohere embed-v3** trunca a 512 tokens. Nuestros episodios pueden llegar a 500+ palabras (~650 tokens). Riesgo de truncación. Descartado. **Fase U — Síntesis con semáforo epistémico**...