Embeddings en RAG: Cómo Elegir el Modelo Correcto
El MTEB leaderboard no te va a decir qué modelo necesitas. Análisis práctico de modelos, dimensionalidad y fine-tuning para sistemas RAG en producción.
En el artículo sobre chunking dije que el modelo de embedding importa menos de lo que crees. Lo mantengo — si tu chunking está mal, da igual qué modelo uses. Pero una vez que la segmentación está resuelta, el modelo se convierte en la siguiente palanca. Y aquí es donde veo el segundo error más frecuente: equipos que eligen modelo mirando el MTEB leaderboard como si fuera la clasificación de la Liga.
He visto a un equipo pasar dos semanas evaluando modelos de embeddings para un RAG de soporte técnico. Probaron los cinco primeros del MTEB. Al final eligieron el número uno. En producción, sus usuarios escribían cosas como “no me va el wifi” o “me cobráis de más” — frases cortas, coloquiales, con faltas de ortografía — y el modelo, entrenado con corpus académicos, no entendía la intención detrás de esas queries. Lo cambiaron por uno con mejor rendimiento en short-text retrieval y el recall subió un 30%. El número uno del leaderboard no era el número uno para su caso.
Antes de complicarlo: qué hace un modelo de embeddings
Todo el mundo habla de embeddings, pero pocos paran a explicar qué significa elegir uno u otro en la práctica. Voy a intentarlo.
Un modelo de embeddings es, simplificando, el criterio con el que tu sistema decide qué se parece a qué. Cuando alguien pregunta “¿cuál es el plazo de entrega?”, el modelo es quien decide si un chunk que dice “los materiales se enviarán en un máximo de 30 días hábiles” se parece a esa pregunta. Si el modelo entiende que “plazo de entrega” y “se enviarán en un máximo de” hablan de lo mismo, el retriever encuentra el chunk correcto. Si no lo entiende, te devuelve un chunk sobre política de devoluciones y el LLM inventa una respuesta con total confianza.
Piénsalo como un traductor. Tus documentos están en castellano (o en inglés, o en lo que sea) y tus queries también. Pero el sistema no busca por texto — busca por significado. El modelo de embeddings es el traductor que convierte texto en significado numérico. Un traductor generalista pilla la idea general: “esto va de logística”. Un traductor especializado en tu dominio entiende que “plazo de entrega”, “lead time”, “tiempo de envío” y “SLA de fulfillment” son lo mismo. Esa diferencia, en un sistema con miles de chunks, es la diferencia entre devolver el documento correcto y devolver uno que se parece vagamente.
Todo lo que el LLM recibe pasa primero por este filtro. Si el modelo de embeddings está mal calibrado para tu dominio, da igual lo bueno que sea el LLM — trabaja con los documentos equivocados. Basura entra, basura sale.
El MTEB no te dice lo que crees
El Massive Text Embedding Benchmark es el ranking de referencia. También es una fuente de confusión masiva, porque a día de hoy coexisten tres versiones con scores que no son comparables entre sí:
- MTEB v1 (legacy): 56 tareas en inglés. Lidera NV-Embed-v2 con 72.31.
- MMTEB (actual): 250+ idiomas, ranking por Borda Count. Lidera Gemini con 68.32.
- MTEB English v2: Lidera Qwen3-Embedding-8B con 75.22.
Tres leaderboards, tres ganadores distintos. Eso ya debería hacer saltar alarmas.
Pero el problema de fondo es más simple: el MTEB es un promedio de tareas muy distintas — clasificación de sentimiento, clustering, reranking, recuperación… Si construyes un RAG, te importa una: retrieval. Un modelo puede arrasar clasificando tweets y ser mediocre encontrando el fragmento relevante en documentación técnica.
Un benchmark independiente de AIMultiple (febrero 2026) hizo algo que casi nadie hace: evaluar modelos con datos reales — reviews de Amazon, no datasets sintéticos. Resultado: mistral-embed primero con 77.8%. Gemini, líder del MMTEB, quedó en 71.5%. Voyage-4: 68.6%. OpenAI y Cohere por debajo.
El líder del leaderboard no fue el líder con datos de un dominio concreto. Esto pasa constantemente.
Mi recomendación: usa el MTEB como filtro de descarte — si un modelo no llega a 60 en tareas de retrieval, probablemente no vale. Para decidir entre los de arriba, no hay atajo: necesitas evaluar con tus datos. Veinte queries representativas de lo que realmente preguntan tus usuarios, evaluadas a mano, te dicen más que cualquier score agregado.
Los modelos que importan hoy
Hay demasiados modelos. Estos son los que considero relevantes para RAG en producción a febrero de 2026:
| Modelo | MTEB | Dimensiones | Contexto | $/1M tokens | Licencia |
|---|---|---|---|---|---|
| text-embedding-3-large (OpenAI) | 64.6% | 3072 (MRL) | 8K | $0.13 | Propietario |
| text-embedding-3-small (OpenAI) | 62.3% | 1536 (MRL) | 8K | $0.02 | Propietario |
| Voyage 3.5 | +8% vs OpenAI large | 2048 (MRL) | 32K | $0.06 | Propietario |
| Voyage 3.5-lite | +6% vs OpenAI large | 2048 (MRL) | 32K | $0.02 | Propietario |
| Cohere Embed v4 | 65.2% | 1536 (MRL) | 128K | $0.12 | Propietario |
| BGE-M3 (BAAI) | ~59-63% | 1024 | 8K | Gratis | MIT |
| nomic-embed-text-v1.5 | 62.4% | 768 (MRL) | 8K | Gratis/API | Apache 2.0 |
| Qwen3-Embedding-8B | 75.2% (EN v2) | 4096 (MRL) | 32K | Gratis | Apache 2.0 |
| gemini-embedding-001 | 68.3% (MMTEB) | 3072 (MRL) | 2K | $0.15* | Propietario |
*Free tier disponible.
Los números están bien para filtrar. Pero lo que de verdad quieres saber es cuándo usar cada uno:
Voyage 3.5-lite es lo que pongo por defecto en proyectos nuevos. Cuesta lo mismo que text-embedding-3-small ($0.02/1M tokens), lo supera en retrieval y tiene 32K de contexto frente a los 8K de OpenAI. En un proyecto reciente con documentación de producto, migramos de OpenAI 3-small a Voyage 3.5-lite sin cambiar nada más del pipeline. El hit rate subió 4 puntos. Misma factura. No sé por qué no se habla más de este modelo.
OpenAI text-embedding-3-large: sigue siendo el más usado. No porque sea el mejor — ya no lo es — sino por inercia y por lo fácil que es integrarlo. Si ya lo usas y funciona razonablemente, no urge migrar. Si empiezas de cero, hay opciones mejores y más baratas.
Qwen3-Embedding-8B es la opción open source más seria. Apache 2.0, lidera MTEB English v2 y MMTEB multilingual. Pero necesitas GPU para self-hosting. En un proyecto donde el cliente no podía mandar datos a APIs externas (compliance), Qwen3 fue la elección natural — rendimiento top sin salir de su infraestructura.
BGE-M3 hace algo que ningún otro modelo ofrece: retrieval híbrida dense+sparse integrada. Es técnicamente elegante. Pero en producción he visto que duplica tiempos de ingestión sin GPUs dedicadas — y para la mayoría de casos, un buen modelo dense con búsqueda híbrida a nivel de base de datos da el mismo resultado.
Gemini: líder MMTEB, pero con 2K tokens de contexto. Para chunks de 512-1.024 tokens va bien. Si usas Contextual Retrieval o chunks más largos, te quedas corto. Es un modelo brillante con una limitación que duele.
Si trabajas en español: jina-embeddings-v2-base-es supera a BGE-M3 y a los multilingual genéricos en benchmarks MTEB-es. Lo he usado en proyectos con corpus bilingüe español-inglés y la diferencia se nota — especialmente en jerga técnica donde los modelos generalistas traducen “en frío” sin entender el contexto.
768 dimensiones son suficientes
Uno de los desperdicios más comunes que veo: equipos que usan las dimensiones por defecto del modelo — 1536, 3072 — sin preguntarse si necesitan tantas. Es como alquilar un almacén de 500m² para guardar tres cajas.
Casi todos los modelos relevantes hoy soportan Matryoshka Representation Learning (MRL). La idea es intuitiva: el modelo se entrena para que las primeras N dimensiones del vector ya sean una representación válida por sí solas. Piénsalo como describir una película. Con 3 palabras: “thriller espacial romántico”. Con 10: “thriller espacial romántico con viajes en el tiempo y giro final”. Con 50, mucho más matiz. MRL entrena al modelo para que las primeras dimensiones capturen lo esencial, y cada dimensión adicional añada detalle. Puedes quedarte con la descripción corta y sigue funcionando.
Los números lo confirman. En benchmarks BEIR con Gemini embedding:
| Dimensiones | Almacenamiento | Pérdida vs 3072d |
|---|---|---|
| 768 | 25% del original | 0.26% |
| 1536 | 50% | 0% |
| 3072 | 100% | Baseline |
0.26% de pérdida por un cuarto del almacenamiento. Con OpenAI text-embedding-3-large: de 3072 a 256 dimensiones — compresión 12x — retiene el 93.1% del rendimiento. Y a 256d sigue superando a ada-002 a sus 1536d completas.
¿Qué significa esto en la práctica? En un proyecto con 3 millones de documentos técnicos, el equipo usaba text-embedding-3-large a 3072d por defecto. Los vectores ocupaban 34 GB. La factura del vector store escalaba con eso. Bajamos a 768d — mismos chunks, mismas queries, mismo pipeline. Recall prácticamente idéntico. Almacenamiento: 8.5 GB. La factura de infraestructura cayó a la cuarta parte. Literalmente, cambiar un parámetro.
Mi recomendación por tipo de contenido:
| Caso de uso | Dimensiones |
|---|---|
| FAQ, preguntas factuales | 256-512 |
| RAG de documentación general | 384-768 |
| Técnico o científico | 768-1.024 |
| Legal, médico (distinciones finas) | 768-1.536 |
| Multilingüe | 768 mínimo |
Empieza por 768 y baja hasta que notes degradación en tus queries de evaluación. Es la optimización con mejor ratio esfuerzo/ahorro de todo el stack RAG. Y si combinas MRL con cuantización binaria — tema para el artículo sobre bases de datos vectoriales — los ahorros se multiplican: hasta 200x de compresión con menos de un 2% de pérdida.
Un detalle que se suele olvidar: después de truncar con MRL, re-normaliza los vectores (L2). Truncar sin renormalizar degrada la búsqueda de forma silenciosa — todo parece funcionar, pero los resultados son sutilmente peores.
Cuándo fine-tunear (y cuándo no perder el tiempo)
Fine-tunear un modelo de embeddings es adaptarlo a tu dominio. La pregunta no es si funciona — funciona:
| Estudio | Dominio | Mejora |
|---|---|---|
| Phil Schmid, 2024 | SEC filings financieros | +6.9% NDCG@10 |
| Databricks | FinanceBench | +20 puntos porcentuales de accuracy |
| AWS SageMaker | Amazon Bedrock FAQs | +61% en similarity score (0.54 → 0.87) |
La pregunta es si lo necesitas. Porque tiene un coste oculto que poca gente menciona al principio.
Un caso que lo ilustra: un equipo con documentación farmacéutica nos contactó porque su RAG confundía medicamentos. Un usuario preguntaba por efectos secundarios de ibuprofeno y el sistema devolvía chunks sobre paracetamol — porque para el modelo genérico, ambos son “medicamentos antiinflamatorios” y sus vectores estaban demasiado cerca. Fine-tuneamos el modelo con 150 pares de query-documento generados sintéticamente. El sistema empezó a distinguir entre principios activos. NDCG subió un 12%.
Pero — y esto es lo importante — tuvimos que re-embeddear y re-indexar los 2 millones de documentos del corpus. Dos días de ingestión. Si ese equipo hubiera tenido 20 millones de documentos, la migración habría costado más que la mejora.
Cuándo sí: vocabulario de dominio que los modelos genéricos no distinguen bien (legal, médico, financiero con jerga específica), y tu evaluación confirma que el problema es el modelo, no el chunking ni las queries.
Cuándo no: si un modelo genérico ya da resultados aceptables, si tu corpus tiene menos de 1.000 documentos, o si no tienes quién mantenga el pipeline de entrenamiento.
Un hallazgo que me parece clave: Databricks encontró que fine-tunear el retriever produce más ganancia que fine-tunear el LLM generador. Es contraintuitivo — el LLM parece el componente “importante” — pero tiene todo el sentido. Si el retriever no encuentra los documentos correctos, da igual lo brillante que sea el modelo que genera la respuesta. Optimiza desde la base.
Lo que necesitas: 100-200 pares de query-documento relevante. Se pueden generar con un LLM a partir de tus documentos — sin etiquetado manual. Entrenamiento en horas con una GPU consumer de 24 GB VRAM. La barrera real no es técnica. Es decidir si el beneficio justifica re-indexar todo.
Antes de fine-tunear: mejora las queries
Antes de meterte en fine-tuning, hay dos técnicas que mejoran retrieval sin tocar el modelo ni re-indexar nada. Las implementas en horas. Si funcionan, te ahorras semanas.
HyDE (Hypothetical Document Embeddings) fue lo que salvó un proyecto de soporte al cliente que estaba a punto de ir a fine-tuning. Los usuarios escribían cosas como “tema factura” o “cobro raro”. Dos palabras. El retriever no tenía nada con qué trabajar — esos vectores eran tan vagos que matcheaban con medio corpus.
HyDE funciona así: antes de buscar, le pides al LLM que genere una respuesta hipotética a la query. “Tema factura” se convierte en algo como “El cliente reporta un problema con su factura, posiblemente un cargo incorrecto, un error en la fecha de emisión o un importe que no coincide con lo esperado”. Embedizas esa respuesta hipotética — no la query original — y buscas con ella. El vector de una respuesta está mucho más cerca en el espacio semántico de los documentos reales que el vector de una pregunta de dos palabras.
El retriever pasó de devolver ruido a devolver los chunks relevantes. Añade ~300ms por query (la llamada al LLM), pero para ese equipo fue la diferencia entre un sistema que funcionaba y uno que no.
Multi-query: genera 3-5 reformulaciones de la pregunta, busca con cada una, y fusiona los resultados. “¿Cuál es la política de cancelación?” se convierte en “política de cancelación”, “cómo cancelar suscripción”, “condiciones para dar de baja el servicio”, “plazo de cancelación sin penalización”. Cada reformulación captura documentos que las otras no habrían encontrado.
Si alguna de las dos mejora tu retrieval, te acabas de ahorrar un fine-tuning y una re-indexación. Si ninguna lo hace, has descartado que el problema sea la query — y puedes tomar la decisión de fine-tunear con datos, no con intuición.
Lo que me llevo
La elección de modelo de embeddings no es un concurso de puntuaciones. Es una decisión de ingeniería con tres ejes: tu dominio, tu escala y tu presupuesto.
Si empiezo un proyecto RAG mañana y no conozco el dominio: Voyage 3.5-lite a 768 dimensiones. Barato, rápido, sorprendentemente competitivo. Veinte queries de evaluación antes de cambiar nada. Si el retrieval falla, primero HyDE o multi-query. Si sigue fallando, evaluar fine-tuning con 150 pares sintéticos.
Y si después de todo eso el retrieval no mejora cambiando de modelo ni mejorando queries, el problema casi seguro no está en el embedding. Está en lo que estás embedizando.
Este artículo forma parte de una serie sobre arquitectura de sistemas RAG en producción. Los siguientes cubrirán bases de datos vectoriales, hybrid search + reranking, y evaluación con RAGAS.