ember-memory-test/episodes/EXPLORA_investigacin-nexus-embedding-model-para_S20260216.R3_XX.imp.2.hot_exp.pr.fi.es.000.HPQ_J.ADDFK_E.SPNFD.md
Ember 293ec3dc28 feat(episode): EXPLORA_investigacin-nexus-embedding-model-para_S20260216.R3_XX.imp.2.hot_exp.pr.fi.es.000.HPQ_J.ADDFK_E.SPNFD
Skill: NONE | Type: advisory
Summary: EPISODIO 4 — EN: Investigación NEXUS: embedding model para MNEMO
2026-04-13 13:08:02 +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
4c66cda4-d025-4fb4-97c2-6eacd66dcf36 EXPLORA_investigacin-nexus-embedding-model-para_S20260216.R3_XX.imp.2.hot_exp.pr.fi.es.000.HPQ_J.ADDFK_E.SPNFD S20260413 explicar multi_actor low NONE implementation advisory EPISODIO 4 — EN: Investigación NEXUS: embedding model para MNEMO chat_ember private 2026-04-13T12:07:29.870357+00:00 false 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...