Por qué los modelos de embedding volvieron a ser el "principal campo de batalla del rendimiento"
En los primeros días del boom de RAG de 2023, los modelos de embedding tendían a subestimarse como factor diferenciador, pensando que "text-embedding-ada-002 es suficiente". La situación en 2026 es completamente diferente. Mientras que el rendimiento de generación de los LLM se acerca a la saturación en algunas tareas, se ha convertido en un entendimiento común que la información que se pierde en el lado Retrieval determina el límite superior de todo el RAG, y la selección y el ajuste de modelos de embedding ha recuperado su lugar como la área de inversión con mayor ROI.
El leaderboard MTEB (Massive Text Embedding Benchmark) de Hugging Face tiene más de 200 modelos clasificados a partir de abril de 2026, pero las opciones prácticas para productos en español/japonés se reducen a alrededor de 10 modelos. En este artículo comparamos horizontalmente OpenAI, Voyage, Cohere, BAAI y Jina, mostrando las puntuaciones de MTEB/BEIR/JMTEB y la facilidad de manejo en la implementación.
Tabla de puntuaciones de abril de 2026 (resumen)
- OpenAI text-embedding-3-large: MTEB 64,6, JMTEB 75,2, 3072 dimensiones, 8192 tokens, $0,13/M tokens
- OpenAI Embed-4 (lanzado en 02/2026): MTEB 68,9, JMTEB 79,8, 4096 dimensiones, 32k tokens, $0,18/M tokens
- Voyage-3-large: MTEB 67,8, BEIR 58,3, 1024/2048/4096 dimensiones, 32k tokens, $0,18/M tokens
- Voyage-3: MTEB 64,2, 1024 dimensiones, 32k tokens, $0,06/M tokens (mejor relación precio-rendimiento)
- Cohere Embed v4: MTEB 68,1, JMTEB 77,5, 1536 dimensiones, compatible con 128k tokens, $0,12/M tokens, multimodal
- BGE-M3 (BAAI): MTEB 59,4, JMTEB 73,1, 1024 dimensiones, 8192 tokens, OSS (MIT)
- Jina Embeddings v3: MTEB 65,5, JMTEB 74,8, 1024 dimensiones (Matryoshka), 8192 tokens, OSS + API
Solo mirando las puntuaciones, Embed-4 y Voyage-3-large están en la cima, pero "qué usar en producción" se determina por los siguientes 4 ejes: (1) posibilidad de fine-tuning en el dominio, (2) latencia y dimensiones, (3) rendimiento multilingüe/en japonés, (4) cumplimiento de datos transfronterizos.
Rendimiento en japonés: donde JMTEB importa
JMTEB es la versión japonesa de MTEB desarrollada por el laboratorio Okazaki del Instituto Tecnológico de Tokio, que evalúa integralmente Retrieval, STS, Classification, Clustering y Reranking. Incluso los que están arriba en el MTEB en inglés, su clasificación cambia significativamente en japonés.
Tendencias de JMTEB a abril de 2026:
- En el subconjunto de Retrieval en japonés: Embed-4 > Voyage-3-large > Cohere Embed v4 > BGE-M3 > text-embedding-3-large
- En STS (similitud de oraciones), Cohere Embed v4 lidera. Es fuerte en las variaciones de keigo (lenguaje honorífico) y expresiones en japonés
- En búsqueda semántica cruzada (inglés-japonés), BGE-M3 rinde mejor de lo esperado, quedando cerca de Voyage-3-large
En proyectos domésticos donde la transferencia de datos al exterior está prohibida (financieros, públicos), OpenAI/Voyage/Cohere no se pueden usar, y no hay más camino que alojar BGE-M3 de forma propia. En 2026, con Llama.cpp y vLLM se puede procesar BGE-M3 cuantizado GGUF/AWQ en 1 H100 a 2000 req/s, por lo que se ha establecido como el embedding estándar para RAG on-premise.
Matryoshka Representation: jerarquizar las dimensiones
Una tecnología importante de 2026 común a Voyage-3, Jina v3 y OpenAI text-embedding-3-* es Matryoshka Representation Learning (MRL). Es una técnica que hace que usar solo los primeros k dimensiones del vector obtenido de un solo modelo sea suficiente para preservar el significado, jerarquizando la función de pérdida durante el entrenamiento.
Anteriormente, "3072 dimensiones son precisas pero pesadas, reducir a 256 dimensiones colapsa la precisión", pero con modelos compatibles con MRL es posible el enfoque en dos etapas: "indexar con 3072 dimensiones y usar 256 dimensiones para la búsqueda en primera etapa de forma rápida, y usar todos los 3072 dimensiones en la segunda etapa para reranking".
```python from openai import OpenAI import numpy as np
client = OpenAI() resp = client.embeddings.create( model="text-embedding-3-large", input=texts, dimensions=256, # Con MRL, devuelve solo los primeros 256 dimensiones ) short_vecs = np.array([d.embedding for d in resp.data])
# La versión de 3072 dimensiones completas se obtiene por separado para el reranking completo resp_full = client.embeddings.create( model="text-embedding-3-large", input=texts, ) full_vecs = np.array([d.embedding for d in resp_full.data]) ```
Mantener 100M vectores con 3072 dimensiones solo en datos brutos son 1,2 TB. Al recortar a 256 dimensiones con MRL baja a 100 GB, y tanto la construcción de HNSW como la residencia en memoria se vuelven realistas. Esto se vuelve aún más poderoso combinado con la funcionalidad multi-vector de Qdrant/Weaviate.
ColBERT y Late Interaction
En 2026, aumentaron los RAG de producción que implementan Late Interaction (tipo ColBERT) en lugar de solo vectores densos. ColBERT no comprime el documento a 1 vector, sino que lo retiene como un grupo de vectores a nivel de token, y calcula la similitud con los vectores de tokens del lado de la consulta mediante la operación MaxSim.
- La capacidad de preservar matices en documentos largos es muy superior a los vectores densos individuales
- El costo de almacenamiento es 10-50 veces mayor que el denso (depende del número de tokens)
- Qdrant 1.12, Vespa y Weaviate 1.28 tienen soporte nativo para multi-vector
Jina-ColBERT-v2 y ColBERTv2 (Stanford) producen un rendimiento de Retrieval asimétrico que se acerca a los modelos densos top, mientras que son menos propensos a degradarse en dominios ligeramente alejados de los datos de entrenamiento. Son especialmente efectivos en dominios donde "no se puede comprimir en un solo vector", como contratos extensos, artículos académicos y código fuente.
```python from ragatouille import RAGPretrainedModel
rag = RAGPretrainedModel.from_pretrained("jinaai/jina-colbert-v2") rag.index( collection=documents, index_name="contracts", max_document_length=512, split_documents=True, ) hits = rag.search("cláusula sobre el período de garantía del panel LCD", k=20) ```
Fine-tuning específico del dominio
Los modelos de embedding de uso general son ampliamente buenos en promedio, pero siempre pierden en áreas especializadas (medicina, derecho, terminología interna). En 2026 se estableció una cadena de herramientas donde el fine-tuning basado en aprendizaje contrastivo se puede ejecutar en pocas horas.
- sentence-transformers 3.x: fine-tuning con LoRA con `SentenceTransformerTrainer`
- Voyage Fine-tuning API: genera un modelo especializado en 2 horas a partir de pares de consulta/documento de tu propio dominio
- Cohere Custom Models: permite aprendizaje de dominio tanto para Rerank como para Embed
En el proyecto médico de KGA, fine-tuneamos BGE-M3 con 50.000 pares de Q&A internos y obtuvimos una mejora de 8 puntos en el subconjunto de Retrieval médico de JMTEB y 14 puntos en nDCG@10 en el conjunto de prueba interno. La importancia de poder romper la dependencia del modelo de uso general más poderoso es significativa.
Reglas de selección
- Dominio amplio, centrado en inglés, API aceptable → Voyage-3-large
- Centrado en japonés, necesidad de 128k para textos largos → Cohere Embed v4
- Requiere on-premise, licencia MIT → BGE-M3
- Máxima prioridad en relación precio-rendimiento → Voyage-3 o text-embedding-3-small
- Búsqueda integrada de imágenes + texto → Cohere Embed v4 (multimodal)
- Máxima prioridad en matices de texto largo → Jina-ColBERT-v2 (Late Interaction)
El embedding no es "elegir un modelo y listo", sino que el estándar de producción de 2026 es el diseño en capas de dense de primera etapa + Late Interaction de segunda etapa + reranker de dominio.