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

feat(episode): EXPLORA_investigacin-nexus-embedding-model-para_S20260216.R3_XX.imp.2.hot_exp.pr.fi.es.000.HPQ_J.ADDFK_E.SPNFD

Browse source 
Skill: NONE | Type: advisory
Summary: EPISODIO 4 — EN: Investigación NEXUS: embedding model para MNEMO
This commit is contained in:
Ember 2026-04-13 13:08:02 +00:00
parent fb540f1b79
commit 293ec3dc28
1 changed files with 19 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
episodes/EXPLORA_investigacin-nexus-embedding-model-para_S20260216.R3_XX.imp.2.hot_exp.pr.fi.es.000.HPQ_J.ADDFK_E.SPNFD.md Normal file
View file

@ -0,0 +1,19 @@
---
episode_id: "4c66cda4-d025-4fb4-97c2-6eacd66dcf36"
puente_flat: "EXPLORA_investigacin-nexus-embedding-model-para_S20260216.R3_XX.imp.2.hot_exp.pr.fi.es.000.HPQ_J.ADDFK_E.SPNFD"
session_code: "S20260413"
acto_dialogico: "explicar"
actor_flujo: "multi_actor"
criticidad_aegis: "low"
skill_dominante: "NONE"
fase_proyecto: "implementation"
tipo_semantico: "advisory"
summary_one_line: "EPISODIO 4 — EN: Investigación NEXUS: embedding model para MNEMO"
source_type: "chat_ember"
trust_boundary: "private"
created_at: "2026-04-13T12:07:29.870357+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**...