Comparativa de modelos de embedding 2026: text-embedding-3, Cohere, BGE-M3, Voyage & Jina

Un modelo de embedding convierte texto en vectores numéricos que hacen medible la similitud semántica. Estos vectores son la base de todo sistema RAG. Una comparativa sólida de modelos de embedding evalúa a los candidatos según dimensiones, longitud de contexto, benchmarks MTEB/MMTEB, capacidad multilingüe, costes, capacidad de self-hosting y licencia. Para contenidos en alemán rige lo siguiente: el puesto en el MTEB en inglés no equivale a un puesto en alemán. Lo determinante son MMTEB, MIRACL y MTEB-DE.

• Mejor alemán (propietario): Cohere Embed v4, líder multilingüe, utilizable vía API, a través de Azure o como Private Deployment en tu propia VPC u on-premises (datos de 2026).
• Estándar open source para RAG multilingüe: BGE-M3 (MIT), SOTA en MIRACL, combina dense, sparse y multivector en un solo modelo.
• Valor MMTEB más alto de los modelos abiertos de la comparativa: Qwen3-Embedding-8B (Apache 2.0), aunque necesita bastante más potencia de GPU que BGE-M3.
• Open weights con reserva de licencia: Jina v3/v4, desarrollados en Berlín y parte de Elastic desde octubre de 2025. v4 es multimodal y también procesa documentos visuales. Los pesos solo son libres para uso no comercial. Para uso comercial, utilizas Jina vía API o con una licencia aparte.

Por qué el ranking MTEB en inglés lleva a engaño

MTEB v1 está dominado por tareas en inglés. Las referencias correctas para contenidos en alemán son MMTEB (el Massive Multilingual Text Embedding Benchmark, con más de 500 tareas y más de 250 idiomas), MIRACL (recuperación monolingüe en 18 idiomas) y subconjuntos alemanes como MTEB-DE, GermanQuAD-Retrieval y MIRACL-de. Estos benchmarks reordenan el leaderboard con regularidad: los modelos que brillan en inglés suelen perder en alemán 5-15 puntos de nDCG@10, sobre todo con palabras compuestas, lenguaje técnico, terminología jurídica y médica y recuperación de palabras largas muy dependiente de la tokenización.

En los corpus B2B en alemán se suma una dificultad: entidades nombradas, códigos de producto, números de artículos de leyes, códigos CIE, números de material de SAP, IBAN y números de expediente son exactamente los tokens con los que flaquean los modelos de dense retrieval puros. Por eso, la elección del modelo es siempre una decisión sobre la calidad del alemán, no sobre el leaderboard global.

Comparativa de los principales modelos de embedding de 2026

La siguiente tabla resume los criterios de selección clave. Salvo que estén enlazados, los valores de benchmark proceden de la base de investigación interna (datos de 2026). Los datos de licencia de los modelos open weight proceden de las fichas de modelo en Hugging Face (datos de octubre de 2026).

API propietarias: OpenAI, Cohere, Voyage

OpenAI text-embedding-3-large ofrece, con 3.072 dimensiones y 8.192 tokens de contexto, valores sólidos en inglés, pero en tareas especializadas en alemán se queda notablemente por detrás de Cohere y BGE. Sigue siendo solo API (también a través de Azure OpenAI en regiones europeas como Sweden Central o Switzerland North), por lo que la jurisdicción estadounidense se mantiene. Cohere Embed v4 es el líder multilingüe propietario con el mejor rendimiento en alemán, hasta 128k de contexto y truncado Matryoshka de 256 a 1.536 dimensiones. De forma soberana lo operas como Private Deployment en tu propia VPC u on-premises. Voyage (en MongoDB desde febrero de 2025) está especializado en inglés, finanzas, ámbito legal y código; para la recuperación en alemán no es la referencia.

Modelos open weight: BGE-M3, Jina, Qwen3

BGE-M3 (BAAI, MIT) es el estándar open source para RAG multilingüe: 1.024 dimensiones, 8.192 tokens de contexto, SOTA en MIRACL y, como particularidad, embeddings dense, sparse y multivector en un solo modelo. Jina v3 y v4 se desarrollaron en Berlín, pero Jina AI pertenece a Elastic desde octubre de 2025. Con 32k de contexto, v4 procesa además documentos visualmente ricos (tablas, gráficos, diagramas) y alcanza ViDoRe 90,17 en modo multivector. Atención a las licencias: jina-embeddings-v3 está bajo CC BY-NC 4.0 y jina-embeddings-v4, bajo la Qwen Research License. Ambas permiten el self-hosting solo con fines no comerciales. Para uso comercial, los utilizas vía API o con una licencia aparte. Por el mismo motivo, NV-Embed-v2 (NVIDIA, CC-BY-NC) queda descartado para despliegues comerciales. En cambio, son de uso libre jina-embeddings-v2-base-de (Apache 2.0), que con 322 MB es la opción bilingüe pragmática para stacks de pymes sin GPU, y Qwen3-Embedding (Apache 2.0).

Ejemplo práctico: costes de almacenamiento y Matryoshka

Ejemplo de cálculo concreto para 10 millones de vectores con 1.024 dimensiones e índice HNSW:

• float32 (línea base): vectores en bruto 40 GB, más un 50-100 % de overhead de HNSW -> working set efectivo de 60-80 GB.
• halfvec (float16): unos 30-40 GB con una pérdida de recall insignificante.
• Scalar Quantization (SQ8): unos 10-20 GB con solo un 1-3 % de pérdida de recall.
• Binary + Rescore: unos 5-10 GB, pero solo con un rescore de vector completo del top-N; de lo contrario, un 30-60 % de pérdida de recall.

A esto se suma Matryoshka: text-embedding-3-large con 3.072 dimensiones está sobredimensionado para la mayoría de los casos de RAG empresarial. Truncar a 1.024 o 512 dimensiones cuesta solo alrededor de un 1-3 % de calidad de recuperación, pero ahorra 3-6x en almacenamiento y latencia ANN. Para ello no hace falta entrenamiento adicional. Lo mismo vale para Cohere Embed v4, mxbai-2d y Voyage 4. Para proyectos nuevos, la recomendación es elegir un modelo compatible con Matryoshka y almacenar con 512-1.024 dimensiones. BGE-M3 no está entrenado con Matryoshka, pero con sus 1.024 dimensiones fijas ya se sitúa en ese rango.

No olvides el reranker

La elección del modelo es solo la mitad del trabajo. Un reranker cross-encoder tras la primera etapa de recuperación es la medida individual más eficaz del pipeline: eleva el recall@5 típicamente entre 5 y 15 puntos porcentuales. Según el estudio de Anthropic sobre Contextual Retrieval, los embeddings contextualizados más BM25 contextualizado reducen la tasa de error en la recuperación top-20 un 49 %, y con un reranker adicional un 67 %, en ambos casos frente a embeddings estándar. Rerankers soberanos que puedes alojar tú mismo son BGE Reranker v2-m3 (Apache 2.0) y mxbai-rerank-large-v2 (Apache 2.0). Los Jina Reranker v2 y v3 están bajo CC BY-NC 4.0 y necesitan una licencia aparte para uso comercial. Como alternativa propietaria existe Cohere Rerank, vía API o como Private Deployment en tu propia VPC u on-premises.

Recomendación para contenidos en alemán y casos de uso multilingües

La clasificación concreta para RAG empresarial en alemán (datos de 2026) sopesa calidad, necesidad de recursos y licencia: 1. Cohere Embed v4 (mejor alemán, propietario, soberano solo como Private Deployment), 2. BGE-M3 (estándar open source para RAG multilingüe, MIT, totalmente soberano, bastante más económico de operar), 3. Qwen3-Embedding-8B (Apache 2.0, el valor MMTEB más alto (~70,58) entre los modelos abiertos de esta comparativa, aunque necesita bastante más potencia de GPU), 4. Jina v3/v4 (desarrollado en Berlín, parte de Elastic desde 10/2025, v4 multimodal, uso comercial solo vía API o con licencia), 5. BGE-multilingual-gemma2 (aún más pesado, pero fuerte en varios splits). OpenAI text-embedding-3-large queda claramente por detrás en tareas en alemán.

El stack más soberano: BGE-M3 o Qwen3-Embedding, autoalojado en una sola GPU L4/A10G y complementado con BGE Reranker v2-m3. Los tres modelos están bajo licencia MIT o Apache 2.0, y todas las capas funcionan en nubes soberanas de la región DACH (STACKIT, IONOS, OTC, Hetzner). Cohere Embed v4 se añade allí donde una calidad algo mejor en alemán justifica el compromiso comercial. Para una soberanía total sobre los datos, Cohere también ofrece Embed como Private Deployment en tu propia VPC u on-premises. Importante para el cumplimiento normativo: los embeddings derivados de datos personales se consideran, con alta probabilidad, datos personales en sí mismos (véase el dictamen 28/2024 del CEPD). Por eso, para cargas de trabajo reguladas, los modelos autoalojables son la opción de menor riesgo. Si un proveedor externo calcula o almacena los embeddings por ti, también en una nube de la UE, necesitas un contrato de encargo del tratamiento conforme al art. 28 del RGPD. Una API estadounidense no está excluida, pero necesita además una base para la transferencia conforme a los arts. 44 y ss. del RGPD. Si el proveedor está certificado en el EU-US Data Privacy Framework, basta con la decisión de adecuación. Con cláusulas contractuales tipo, además tienes que comprobar si el derecho del país de destino socava la protección (evaluación de impacto de la transferencia).

Para agencias y responsables de decisión B2B

La elección del modelo de embedding determina por igual la calidad de recuperación, los costes de almacenamiento y la conformidad con el RGPD de tu sistema RAG. Quien trabaja con contenidos en alemán no debería elegir según el ranking MTEB en inglés, sino según la calidad demostrada en alemán y la soberanía. Como agencia de Viena, Blck Alpaca diseña e implementa stacks soberanos y multilingües de RAG y agentes de IA y te acompaña desde la selección del modelo y el self-hosting hasta la integración del reranker. Habla con nosotros si quieres montar una configuración de embeddings conforme al RGPD para contenidos en alemán u optimizar un sistema existente para la calidad de recuperación en alemán.