Cómo elegir un modelo de embedding (incluido el eslovaco)

Cuando un cliente llega con el requisito «desplieguen un RAG sobre nuestra documentación técnica», el debate inicial casi siempre gira en torno al modelo de lenguaje grande: ¿Claude o GPT? ¿Llama o Mistral? ¿Local o cloud? El modelo de embedding queda fuera del foco — la mayoría de equipos tira de OpenAI text-embedding-ada-002 porque lo vieron en el primer quickstart, o de lo que aparezca en la documentación del framework que estén usando.

Realidad de campo: el modelo de embedding es el lugar donde se decide el 15–20 % de la calidad total del pipeline de retrieval. Un modelo mal elegido hace que los documentos relevantes aparezcan en los top-20 resultados pero no en el top-5 — y el LLM responde a partir de contexto irrelevante. Para contenido en eslovaco este efecto es más pronunciado que para el inglés, porque la mayoría de los modelos populares están entrenados principalmente con datos en EN. Este artículo ofrece un marco concreto de selección, incluido qué funciona y qué no en eslovaco.

Qué hace un modelo de embedding — y por qué importa la elección

Un modelo de embedding convierte texto (documento, pregunta, frase) en un vector — una lista de números donde textos similares tienen vectores geométricamente próximos. El retrieval busca entonces vectores cercanos a la consulta. Todo lo demás en el pipeline RAG depende de si «cerca en el espacio» significa realmente «semánticamente relevante».

Dos dimensiones en las que los modelos difieren:

Dimensión del vector (768, 1 024, 3 072, 4 096) — una dimensión mayor permite capturar más información semántica, pero aumenta los requerimientos de memoria, el coste de almacenamiento y la latencia del similarity search. Los modelos Matryoshka modernos permiten reducir la dimensión tras el entrenamiento (p. ej., de 3 072 a 768) con una pérdida mínima de calidad — esto es relevante al escalar a decenas de millones de vectores.

Ventana de contexto — cuántos tokens procesa el modelo efectivamente al embeber un chunk. Los modelos más antiguos tenían una ventana efectiva de unos 512 tokens incluso con límite nominal de 8 192; los modelos modernos (BGE-M3, Qwen3-Embedding, NV-Embed-v2) manejan documentos largos sin pérdida significativa de calidad. Para un pipeline RAG con document-aware chunking esto es directamente relevante — si vuestros chunks tienen 600–800 tokens, un modelo con ventana efectiva de 512 tokens los recortará.

MTEB: referencia orientativa, no dogma

MTEB (Massive Text Embedding Benchmark) es el benchmark más utilizado para modelos de embedding. Mide el rendimiento en decenas de tareas: retrieval, clustering, classification, semantic similarity. Los resultados son públicos en el leaderboard de Hugging Face y son un buen punto de partida.

Tres limitaciones que hay que tener presentes:

• MTEB es principalmente inglés. Existe una pista multilingüe, pero cubre solo algunos idiomas — el eslovaco no es una ruta de idioma estándar en MTEB. Los resultados en MTEB multilingüe son orientativos, no una garantía de rendimiento en eslovaco.
• Los datos del benchmark difieren de vuestros datos. Un modelo con puntuación MTEB 70 puede dar resultados mucho peores en vuestro contenido de dominio específico (documentación técnica, textos jurídicos, manuales de servicio) que un modelo con puntuación 65 entrenado sobre contenido similar.
• La puntuación del benchmark no mide latencia ni coste. Un modelo con MTEB 70 y 400 ms de latencia es peor elección para una aplicación en tiempo real que uno con MTEB 67 y 15 ms.

MTEB es, por tanto, una buena herramienta para construir una lista corta de 3–5 candidatos. La decisión final hay que tomarla en base a pruebas con vuestros propios datos.

Modelos open-weight: cuándo y por qué

Para empresas SK/UE el argumento a favor del modelo de embedding self-hosted es más sólido que para el LLM en sí. Un modelo de embedding:

• Funciona en un servidor GPU convencional. BGE-M3 gestiona un servidor GPU estándar con latencias en el orden de decenas de milisegundos por request. No es el mismo requerimiento de HW que para un LLM de 70B.
• Sin fugas de datos. Los documentos permanecen en vuestra infraestructura — relevante para sectores regulados y cumplimiento GDPR.
• Coste predecible. El coste amortizado del servidor GPU es fijo; el coste de la API cloud crece linealmente con el volumen.
• Personalización. Con suficientes datos de dominio es posible hacer fine-tuning del modelo sobre vuestros textos — esto no es posible con una API cloud.

BGE-M3 (BAAI/FlagEmbedding) es en 2026 el estándar de producción para despliegues multilingüe open-weight. Combina en un solo paso tres tipos de retrieval: dense (semántico), sparse (keyword-based estilo BM25) y multi-vector (estilo ColBERT, más preciso). Más de 100 idiomas, incluido el eslovaco. Ventana de contexto de 8 192 tokens. Dimensión 1 024 (dense). Este es nuestro default interno para clientes de la UE con despliegue local.

Qwen3-Embedding (familia de modelos de Alibaba, incluida la variante 8B) alcanza en 2026 las puntuaciones más altas en el leaderboard multilingüe de MTEB — alrededor de 70,58 en Qwen3-Embedding-8B. Dimensión Matryoshka flexible (32–4 096), ventana de contexto larga de 32 768 tokens. Para retrieval no inglés es actualmente el candidato open-weight más potente, si disponéis del HW suficiente (el modelo 8B requiere del orden de 16 GB de VRAM a plena precisión, menos con cuantización).

Llama-Embed-Nemotron-8B (NVIDIA) se sitúa en la cúspide del MTEB multilingüe (250+ idiomas, open-weight, gratuito). Si tenéis HW de NVIDIA y necesitáis la puntuación máxima en la categoría open-weight, es un candidato sólido.

Para prototipado rápido o despliegues de bajo coste bastan modelos más pequeños de la familia sentence-transformers — all-mpnet-base-v2 o paraphrase-multilingual-mpnet-base-v2 — pero su rendimiento en eslovaco es notablemente inferior al de BGE-M3.

APIs cloud: cuándo tienen sentido

Las APIs de embedding cloud (OpenAI, Google, Cohere, Voyage AI) tienen sentido en tres situaciones:

1. 1.No tenéis GPU propio. Desplegar sobre una API cloud es más sencillo, sin gestión de HW.
2. 2.Las llamadas son esporádicas y el volumen bajo. Con unos pocos miles de requests al día no compensa amortizar un servidor propio.
3. 3.Requisitos multimodales. Si embedéis combinaciones de texto e imágenes (p. ej., catálogos con planos técnicos), los modelos cloud como Cohere Embed v4 llevan ventaja en este ámbito.

OpenAI text-embedding-3-large (3 072 dimensiones, Matryoshka, ~$0,13/1M tokens) es una elección fiable y bien documentada para contenido en inglés. Para contenido en eslovaco el rendimiento es algo inferior al de los modelos optimizados para multilingüe.

OpenAI text-embedding-3-small (~$0,02/1M tokens) resulta interesante por su precio — para inglés ofrece una buena relación rendimiento/coste, pero para multilingüe recomendamos 3-large o el salto a Cohere.

Cohere Embed v4 se distingue por dos características: ventana de contexto de 128 000 tokens (documentos extremadamente largos sin necesidad de chunking) y soporte multimodal nativo (texto + imágenes). Precio ~$0,12/1M tokens. Para empresas que embedan documentación técnica con imágenes o esquemas, esta combinación es relevante.

Gemini Embedding 001 (Google) mantiene en 2026 una de las puntuaciones más altas en MTEB English (~68), con soporte Matryoshka de 768 a 3 072 dimensiones. Precio ~$0,004/1K caracteres. Para retrieval en inglés es una opción cloud sólida; para contenido en SK aplica la misma reserva que con los modelos de OpenAI.

Eslovaco: qué funciona y qué no

El eslovaco no es una ruta de idioma independiente en el benchmark estándar de MTEB. No existen benchmarks verificados específicos de SK para modelos de embedding disponibles públicamente. Lo que sabemos por la práctica y por benchmarks afines (MIRACL, MKQA):

• Los modelos entrenados principalmente en inglés (el antiguo ada-002, all-MiniLM) tienen para textos en SK un rendimiento claramente por debajo de su puntuación de benchmark EN.
• BGE-M3, Qwen3-Embedding y Llama-Embed-Nemotron cubren el eslovaco como parte de su conjunto de entrenamiento multilingüe — su rendimiento es cercano al de idiomas eslavos próximos (checo, polaco), lo que en la práctica funciona.
• Para documentación técnica en SK (manuales de maquinaria, proyectos eléctricos, normas ČSN/STN) hemos realizado pruebas internas de BGE-M3 frente a OpenAI text-embedding-3-large — BGE-M3 mostró de forma consistente una precision@5 un 8–12 % más alta. No es una diferencia dramática, pero se acumula con contenido más complejo.
• Si disponéis de suficientes datos de dominio en SK (~5 000+ documentos), es posible hacer fine-tuning del modelo de embedding sobre vuestro contenido (fine-tuning mediante la biblioteca sentence-transformers). En sectores regulados (derecho, medicina) esto puede mejorar la precisión entre un 5–10 % adicional.

Para la búsqueda híbrida (BM25 + vectores), en contenido eslovaco con terminología precisa (números de normas, artículos de ley, códigos de piezas) la capa de keywords BM25 es más importante que en inglés — el modelo de embedding puede normalizar formas morfológicas («del accionamiento» vs «accionamiento»), pero las cadenas de texto exactas las captura BM25 con mayor fiabilidad.

Dimensión vs. calidad vs. coste: marco práctico

No es cierto que mayor dimensión = mejor rendimiento. Los modelos Matryoshka permiten entrenar a plena dimensión (3 072 o 4 096) e inferir a dimensión reducida (256, 512, 768) — la pérdida de calidad es mínima y la ganancia en velocidad y coste de almacenamiento es real.

Rangos orientativos para distintos escenarios:

• PoC rápido, contenido en inglés, cloud: text-embedding-3-small (1 536 dim, bajo coste) o text-embedding-3-large reducido a 512 dim vía Matryoshka.
• Cloud de producción, contenido multilingüe EU: Cohere Embed v4 (multimodal + contexto largo) o Gemini Embedding 001.
• Self-hosted, contenido SK/CZ/PL: BGE-M3 es el default. Para un modelo mayor con mayor puntuación: Qwen3-Embedding-8B o Llama-Embed-Nemotron-8B.
• Escalado a decenas de millones de vectores: considerad la reducción de dimensiones Matryoshka (p. ej., a 768) — con 50 M vectores el ahorro en almacenamiento es significativo.
• Contenido multimodal (texto + imágenes): Cohere Embed v4 o Voyage AI voyage-multimodal-3.5.

Para comparar las bases de datos vectoriales concretas donde almacenaréis estos embeddings, consultad Bases de datos vectoriales — comparativa de Qdrant, Weaviate, pgvector y Milvus.

Ajuste de dominio: el factor más ignorado

La puntuación MTEB habla del rendimiento medio en conjuntos de prueba variados. Vuestro contenido real es estrecho y específico:

• Documentación de maquinaria (notas de planos, manuales de servicio, normas ISO) — lenguaje técnico con terminología precisa, abreviaturas, números de piezas. El embedding dense captura la semántica; la capa BM25 captura los códigos exactos. El modo hybrid de BGE-M3 es ventajoso aquí.
• Textos jurídicos (código laboral, contratos, normativas) — lenguaje formal, referencias a artículos, énfasis en la redacción exacta. Los tests muestran que un modelo afinado para el dominio (fine-tuned sobre textos jurídicos en SK) supera al modelo genérico en un 10–15 % de precisión.
• Base de conocimiento interna (correos, actas de reuniones, documentos de proceso) — lenguaje variable, distintos estilos de escritura. Aquí el modelo genérico funciona bien; el fine-tuning tiene sentido solo a gran volumen (50k+ documentos).
• Catálogo de productos (SKU, descripciones, parámetros técnicos) — textos cortos, coincidencias exactas. Para e-commerce o catálogos de distribuidores BM25 tiene un peso importante; el modelo de embedding complementa la semántica («tornillo azul con rosca métrica» = «tornillo azul M6 DIN 912»).

Antes de elegir el modelo, respondeos a esta pregunta: ¿qué proporción de vuestras consultas requiere comprensión semántica frente a coincidencia léxica exacta? Para empresas industriales con documentación técnica el retrieval híbrido es casi siempre la elección correcta — y con retrieval híbrido necesitáis un modelo de embedding que soporte nativamente vectores sparse (BGE-M3) o estar dispuestos a gestionar un índice BM25 separado.

Evaluación: cómo testear antes del despliegue

No toméis la decisión basándoos solo en MTEB — construid un mini conjunto de evaluación:

1. 1.Seleccionad 100–200 consultas reales que reflejen vuestro caso de uso en producción.
2. 2.Para cada consulta identificad manualmente los documentos fuente «ideales» (ground truth).
3. 3.Ejecutad el retrieval (top-5 o top-10) para cada modelo candidato.
4. 4.Medid precision@5 y recall@10 — el porcentaje de documentos relevantes en el top-5/10.
5. 5.Comparad también la latencia y el coste de embeber todo el corpus.

Este test, en 2–3 días de trabajo, os mostrará la diferencia real entre modelos sobre vuestros datos. Experiencia de campo: en contenido inglés los candidatos difieren en un 3–8 % de precisión. En contenido técnico eslovaco las diferencias son más pronunciadas — hemos visto diferencias del 15–20 % entre un modelo más débil principalmente EN y BGE-M3.

Para la evaluación del pipeline RAG completo (no solo retrieval, sino también la calidad de generación) consultad Cómo evaluar RAG (RAGAS).

Preguntas frecuentes

¿Sigue siendo BGE-M3 una elección válida en 2026?

Sí. BGE-M3 sigue siendo el estándar de producción para despliegues open-weight multilingüe precisamente gracias a la combinación única de retrieval dense + sparse + multi-vector en un solo paso — ningún otro modelo open-weight ofrece esto en un único modelo. Qwen3-Embedding-8B alcanza puntuaciones MTEB más altas, pero requiere más HW y no proporciona retrieval sparse nativo. Para la mayoría de clientes de la UE con un servidor GPU existente, BGE-M3 sigue siendo un buen default.

¿Necesito un modelo especial para el eslovaco?

No necesariamente. BGE-M3, Qwen3-Embedding y Llama-Embed-Nemotron cubren el eslovaco como parte de su conjunto de entrenamiento y funcionan en la práctica. No existe un modelo de embedding entrenado específicamente para SK disponible como SOTA open-weight público en 2026. Si disponéis de un gran volumen de datos de dominio en SK (10k+ documentos), hacer fine-tuning de un modelo multilingüe genérico sobre vuestro contenido puede dar mejores resultados — pero es un proyecto en sí mismo, no algo que venga de serie.

¿Puedo usar el mismo modelo de embedding para retrieval y para reranking?

No — el modelo de embedding (bi-encoder) y el reranker (cross-encoder) son arquitectónicamente distintos. El modelo de embedding codifica documentos y consultas en vectores de forma independiente (rápido); el reranker evalúa el par (consulta + documento) conjuntamente (más preciso, más lento). Para un pipeline completo necesitáis ambos — más detalles en el artículo Pipeline RAG — 3 ajustes que deciden la calidad.

¿Cuánto cuesta embeber toda la base de conocimiento de una empresa?

Depende del volumen. De forma orientativa: 1 millón de tokens con OpenAI text-embedding-3-large cuesta ~$0,13; con 3-small ~$0,02. Para un corpus de 10 000 páginas PDF (~5 M tokens) el coste puntual de embedding ronda las decenas de dólares con una API cloud. Con BGE-M3 self-hosted el coste es prácticamente nulo una vez pagado el servidor GPU. El re-embedding (al cambiar de modelo o de chunking) tiene el mismo coste de nuevo — por eso conviene elegir el modelo correcto desde el principio.

¿Cuándo tiene sentido hacer fine-tuning del modelo de embedding?

Cuando tenéis contenido de dominio en el que el modelo genérico falla sistemáticamente (precisión por debajo del 70 %), disponéis de suficientes datos (típicamente 5 000+ pares consulta-documento relevantes) y tenéis un sistema en producción donde cada punto porcentual de precisión tiene valor comercial. Los sectores regulados (derecho, medicina) son el ejemplo clásico. Para una base de conocimiento interna ordinaria el fine-tuning va más allá de lo necesario — BGE-M3 o Qwen3-Embedding son suficientes.

*MP Industrial Solutions ayuda a las empresas a diseñar y desplegar arquitecturas RAG desde la elección del modelo de embedding, pasando por la estrategia de chunking, hasta la base de datos vectorial y el harness de evaluación. Si estáis ante una decisión de selección o queréis medir el rendimiento de un despliegue existente, realizamos con gusto una auditoría gratuita de 90 minutos de vuestro pipeline.*