Embeddings para empresa: comparativa OpenAI, Cohere, Voyage, Jina

TL;DR

Una comparativa embeddings empresa no se gana en MTEB, se gana en tu propio dominio. En 2026, los cuatro modelos comerciales que dominan producción son text-embedding-3-large de OpenAI, embed-v4 de Cohere, voyage-3 de Voyage AI y jina-embeddings-v4, con BGE-M3 y GTE-large como referencias open source serias. Para RAG en español, Cohere y OpenAI lideran calidad; Voyage gana en código; Jina gana en multimodal y latencia; BGE-M3 gana cuando el on-premise no es negociable. La elección correcta depende de cinco variables: idioma dominante, dominio, presupuesto, restricciones de privacidad y si necesitas multimodal. Cualquier comparativa de modelos de embeddings que no evalúe en tu corpus real es decoración.

¿Qué es exactamente un embedding y por qué la elección importa en empresa?

Un embedding es la representación numérica densa de un fragmento de información —texto, imagen, audio, código— en un espacio vectorial de alta dimensión donde la cercanía geométrica aproxima la similitud semántica. En la práctica, esto significa convertir un párrafo de un contrato, una reseña de cliente o un fragmento de código Python en un vector de entre 256 y 4.096 dimensiones que se puede indexar, buscar y comparar a escala. Suena trivial; en producción no lo es. La calidad de ese vector marca la diferencia entre un sistema RAG que responde con precisión y uno que alucina con confianza.

En los proyectos que llevamos en Datalvar, el patrón se repite con una insistencia que ya no nos sorprende: el equipo elige el modelo de embeddings en quince minutos —“usamos text-embedding-ada-002 porque viene en el ejemplo de OpenAI”— y luego invierte seis meses peleándose con un pipeline de retrieval que rinde un 60% por debajo de lo que podría. Cambiar de modelo a mitad de proyecto implica re-embebido masivo, migración del índice vectorial, re-evaluación end-to-end y, casi siempre, regresión temporal de calidad antes de ganar. Por eso una embeddings empresa comparativa seria importa: la decisión es costosa de revertir y compone durante todo el ciclo de vida del sistema.

Lo que sí ha cambiado en 2026 respecto al 2023 es que ya no estamos eligiendo entre “OpenAI o no OpenAI”. El ecosistema se ha diversificado lo suficiente como para que existan opciones técnicamente superiores según el caso de uso: Voyage AI domina en código y dominios verticales, Cohere ha consolidado liderazgo multilingüe, Jina ha apostado fuerte por multimodal y context largo, y la familia open source —BGE, GTE, E5, Nomic— ha cerrado el gap hasta el punto de que en muchos benchmarks compiten de tú a tú con los comerciales. Esta comparativa de modelos de embeddings está diseñada para que la decisión la tomes sobre datos, no sobre marketing.

¿Qué métricas importan al evaluar un modelo de embeddings para empresa?

Antes de mirar precios o nombres comerciales, conviene fijar qué se está comparando. Una embeddings empresa comparativa mal diseñada compara modelos en un benchmark genérico, ignora latencia, ignora coste de re-embebido masivo y termina recomendando el modelo que mejor suena en Twitter. Las métricas que de verdad importan son seis, y conviene tenerlas claras antes de empezar a probar.

¿Qué es MTEB y hasta dónde es fiable como benchmark?

MTEB (Massive Text Embedding Benchmark) es el benchmark de facto para evaluar modelos de embeddings. Agrega 56 datasets repartidos en 8 tareas (retrieval, clustering, clasificación, reranking, STS, summarization, pair classification, bitext mining) y produce una puntuación media. En la práctica, los modelos top de 2026 puntúan entre 65 y 72 en MTEB-eng, una franja relativamente estrecha donde las diferencias absolutas son pequeñas pero las relativas en retrieval —la tarea que nos importa para RAG— pueden ser significativas.

El problema de MTEB, y conviene decirlo claramente, es que es un benchmark agregado en inglés genérico (existe MTEB-multilingual y MTEB-fr, MTEB-es, etc., pero con coberturas variables). Un modelo que rinde 70 en MTEB puede rendir 45 en tu corpus de contratos jurídicos en español, y otro que rinde 67 puede rendir 58 en el mismo corpus. MTEB es útil como filtro inicial —descarta modelos por debajo de cierto umbral— pero no como criterio único de elección. Cualquier comparativa que se quede en MTEB y no evalúe en dominio propio está incompleta.

En Datalvar usamos MTEB para hacer una preselección de tres o cuatro candidatos y luego ejecutamos nuestro propio gold standard. La diferencia entre la puntuación MTEB y la puntuación en dominio suele ser del 15-25% en casos verticales (legal, médico, técnico), y por eso ningún cliente debería tomar una decisión solo con la cifra del leaderboard. El leaderboard es el aperitivo, no el plato principal.

¿Cómo afectan latencia y coste por millón de tokens a la elección?

En empresa, la latencia del embedding importa en dos momentos: en el ingest (indexar el corpus inicial, que puede ser millones de documentos) y en el query time (embeber la pregunta del usuario antes de hacer búsqueda vectorial). El ingest se puede paralelizar y batchear agresivamente, así que lo que importa ahí es throughput total y coste por millón de tokens. El query time es lo que el usuario percibe: si tu embedding tarda 400 ms y el reranker 600 ms y el LLM 1.500 ms, ya estás en 2,5 segundos solo de cómputo.

Los precios de 2026 en los modelos comerciales se mueven en un rango razonablemente comparable. text-embedding-3-small de OpenAI cuesta del orden de 0,02 $ por millón de tokens, text-embedding-3-large alrededor de 0,13 $, embed-v4 de Cohere ronda 0,12 $, voyage-3 está cerca de 0,06 $ y Jina ofrece tiers desde gratuito (con rate limits) hasta planes empresariales. Para un corpus de 100 millones de tokens, la diferencia entre el modelo más barato y el más caro es del orden de 10-13 dólares; nada que justifique elegir mal. Para un corpus de 10.000 millones de tokens (ingesta masiva de logs, transcripciones, web scraping), la diferencia se vuelve real: hablamos de 1.300 dólares vs 200 dólares.

La latencia varía más de lo que las hojas de spec dicen. En nuestras pruebas, los proveedores comerciales sirven embeddings con P95 entre 80 y 250 ms para batches pequeños desde un cliente en Madrid, mientras que un BGE-M3 desplegado en GPU dedicada (A10G o L4) sirve en 30-60 ms sin coste por token pero con coste por hora de máquina. El cálculo de “cuándo sale rentable on-premise” depende del volumen de queries: por debajo de 1 millón de queries/mes, la API gana; por encima de 20 millones, el deploy propio gana siempre. En medio, hay que calcular.

¿Por qué importa el multilingüe y dónde fallan los modelos solo-inglés?

Si tu corpus o tu audiencia operan en español —caso típico en proyectos que vemos en agencia—, el rendimiento multilingüe es la métrica más infravalorada. Muchos modelos open source ampliamente recomendados en blogs anglosajones (todo el linaje de all-MiniLM, varios E5 antiguos, GTE-small) están entrenados predominantemente en inglés y degradan significativamente en español, especialmente en consultas cortas o en jerga vertical. Un retrieval que en inglés daba recall@10 de 0,82 puede caer a 0,58 en el mismo corpus traducido al español.

Los modelos que sí están entrenados con masa real multilingüe en 2026 son Cohere embed-v4 (uno de los más fuertes en español por construcción), Jina v4 (entrenado en 89 idiomas), BGE-M3 (multilingüe nativo, uno de los mejores resultados open source en español) y text-embedding-3-large de OpenAI, que aunque no es estrictamente multilingüe-first se comporta bien en español por el tamaño del modelo y la cobertura del corpus de entrenamiento. Voyage AI tiene modelos multilingües (voyage-multilingual-2) que rinden bien en romances pero no son su producto estrella.

En la práctica, recomendamos siempre evaluar con un set en español antes de cerrar la decisión. En uno de nuestros proyectos legal-tech, un modelo que rendía 0,71 nDCG@10 en inglés cayó a 0,49 en español jurídico; tuvimos que cambiar a un modelo multilingüe que en inglés rendía algo peor (0,68) pero en español alcanzaba 0,66. La métrica agregada en el leaderboard no contaba esta historia.

¿Cuántas dimensiones necesitas realmente y qué es Matryoshka?

Las dimensiones del vector tienen impacto directo en tres cosas: precisión semántica, coste de almacenamiento en la vector DB y velocidad de búsqueda. Más dimensiones generalmente significan más precisión, pero también más coste y más latencia. Un modelo de 3.072 dimensiones (como text-embedding-3-large por defecto) ocupa el triple que uno de 1.024 y la búsqueda ANN es proporcionalmente más cara.

Matryoshka Representation Learning (MRL) es una técnica que entrena el modelo para que las primeras N dimensiones del vector ya contengan la mayor parte de la información semántica, de modo que se puede truncar el vector a 512 o 256 dimensiones manteniendo el 90-95% de la calidad. OpenAI implementó MRL en text-embedding-3-*, lo que permite, por ejemplo, almacenar vectores de 256 dimensiones (12 veces más baratos que los de 3.072) con una pérdida de calidad típicamente menor al 5% en retrieval. Cohere y Nomic han adoptado patrones similares.

En empresa, esto cambia el cálculo económico. En un proyecto de RAG sobre 50 millones de chunks, almacenar vectores de 3.072 vs 512 dimensiones supone la diferencia entre necesitar una instancia de Pinecone Enterprise y poder vivir con un Qdrant en una sola máquina. Recomendamos siempre evaluar el modelo truncado a 512 o 768 dimensiones primero, y solo subir si el dominio lo exige.

¿Qué cambia cuando un modelo soporta long context (32k+ tokens)?

Los modelos clásicos de embeddings tenían ventanas de 512 o 8.192 tokens. En 2026 ya no es así: Voyage voyage-3 soporta 32.000 tokens, Jina v4 va hasta 32k, Cohere embed-v4 permite contextos largos y los modelos open source recientes (Nomic, GTE-large-en-v1.5) también han ampliado ventana. Esto no significa que sea buena idea embeber documentos de 32k tokens en un solo vector: aunque la API lo acepta, la información semántica se diluye y el retrieval empeora.

El long context sirve sobre todo para no tener que partir documentos cortos-medianos (5-15 páginas) en chunks excesivamente pequeños, y para casos específicos como embedding de logs de conversación, tickets de soporte multi-turno o secciones largas de manuales técnicos. En la mayoría de pipelines RAG bien diseñados, chunks de 500-1.000 tokens siguen siendo el sweet spot independientemente de la ventana máxima del modelo. Es una capacidad útil para no chocar con límites, no una invitación a embeber documentos enteros.

¿Cómo se comparan los modelos top de embeddings en 2026?

Entrando en la comparativa concreta, nos centramos en los cinco grupos que cubren el 95% de los casos de uso empresariales reales. Esta selección no incluye modelos experimentales ni los que han perdido tracción (text-embedding-ada-002 está deprecated, sentence-transformers/all-MiniLM-L6-v2 sigue vigente como baseline pero no compite en producción seria). Una comparativa modelos embeddings honesta tiene que reconocer que el mercado se ha consolidado.

Modelo	MTEB-eng (aprox.)	Dim. por defecto	Matryoshka	Ventana	Precio / M tokens	Multilingüe	Open source
OpenAI text-embedding-3-large	64.6	3.072 (trunc. 256-3.072)	Sí	8.191	~0,13 $	Aceptable	No
OpenAI text-embedding-3-small	62.3	1.536 (trunc. 256-1.536)	Sí	8.191	~0,02 $	Aceptable	No
Cohere embed-v4	67-68	1.536 (configurable)	Sí	128k	~0,12 $	Fuerte (100+ idiomas)	No
Voyage AI voyage-3-large	69-70	1.024	Sí	32.000	~0,18 $	Medio	No
Voyage AI voyage-3	67-68	1.024	Sí	32.000	~0,06 $	Medio	No
Jina embeddings v4	66-67	2.048 (trunc.)	Sí	32.768	Free tier + paid	Fuerte (89 idiomas)	Pesos publicados
BGE-M3	65-66 (M3 retrieval)	1.024	No nativo	8.192	Coste compute	Fuerte (100+ idiomas)	Sí (Apache 2.0)
GTE-large-en-v1.5	65.4	1.024	No nativo	8.192	Coste compute	Inglés principalmente	Sí

¿Cuándo elegir OpenAI text-embedding-3-large o small?

text-embedding-3-large es probablemente el “default seguro” para empresa en 2026 si ya operas en el ecosistema OpenAI/Azure y no tienes restricciones de soberanía de datos fuertes. Es robusto, multilingüe aceptable (no líder), soporta Matryoshka, escalable a través de Azure OpenAI con SLAs empresariales y la integración con el resto del stack (GPT-4o, gpt-5, herramientas) es trivial. Su debilidad es que no lidera ningún benchmark concreto: es un buen modelo “todo en uno” más que un especialista. En la documentación oficial de OpenAI sobre embeddings está el detalle de pricing, dimensiones y mejores prácticas.

text-embedding-3-small es el caballo de batalla cuando el coste manda y la calidad “buena” basta. A 0,02 $ por millón de tokens, embeber 1.000 millones de tokens cuesta 20 dólares; difícil rivalizar. En proyectos donde el RAG tiene un reranker fuerte detrás (ver más abajo), la diferencia entre 3-small y 3-large se cierra significativamente, porque el reranker compensa imperfecciones del retrieval inicial. Para POCs, prototipos y proyectos con presupuestos ajustados, es nuestra recomendación por defecto.

Donde no recomendaríamos OpenAI es cuando tienes obligaciones contractuales o regulatorias de no enviar datos fuera de tu infraestructura, cuando trabajas con dominios muy especializados donde modelos fine-tuneables (open source) tienen ventaja, o cuando necesitas multilingüe agresivo en idiomas no-anglosajones donde Cohere o Jina rinden mejor.

¿Cuándo elegir Cohere embed-v4?

Cohere embed-v4 es, en nuestra experiencia, el modelo más fuerte para RAG empresarial en español y otros idiomas no-anglosajones. Cohere lleva años invirtiendo en multilingüe como diferenciador, y se nota: en pruebas internas, embed-v4 supera a text-embedding-3-large en español jurídico, español administrativo y español técnico por márgenes consistentes (típicamente 3-7 puntos de nDCG@10). El soporte de 100+ idiomas con calidad real es difícilmente igualable.

Sus puntos fuertes adicionales son la ventana de contexto larga (128k), un buen tier empresarial con SLAs y disponibilidad en AWS Bedrock y Azure AI Foundry, lo que facilita los temas de compliance. Cohere también ha publicado un reranker excelente (rerank-3) que se acopla naturalmente al embedder y produce mejoras de 10-20% en métricas de retrieval cuando se usan juntos. Para una arquitectura RAG en español o multilingüe, “embed-v4 + rerank-3” es uno de los stacks más sólidos que hemos puesto en producción.

El precio es ligeramente superior a OpenAI 3-large, pero la diferencia es marginal a escala razonable. Donde Cohere no encaja: cuando ya estás 100% atado al ecosistema OpenAI sin razón para diversificar, o cuando tu caso es código (donde Voyage gana), o multimodal (donde Jina v4 ofrece un paquete más integrado).

¿Cuándo elegir Voyage AI voyage-3?

Voyage AI ha construido una propuesta interesante: modelos generalistas competitivos (voyage-3, voyage-3-large) y modelos verticalizados que son los mejores del mercado en su nicho. voyage-code-3 es el modelo más fuerte para embeber código fuente y queries técnicas; voyage-law-2 lidera en contenido jurídico inglés; voyage-finance-2 en documentos financieros. Si tu caso de uso encaja en uno de esos verticales, no hay debate.

voyage-3-large puntúa entre los más altos en MTEB en 2026 y, en evaluaciones independientes, ha demostrado liderar en retrieval técnico inglés. La ventana de 32k tokens es generosa, el output dimensional es eficiente (1.024) y el soporte de Matryoshka permite truncar a 512 sin pérdida significativa. La limitación principal de Voyage es que su multilingüe no es tan robusto como el de Cohere o Jina: en proyectos donde el español es central, hay que evaluar específicamente antes de comprometerse.

Para empresas que construyen copilotos de código, sistemas RAG sobre repositorios internos o búsqueda semántica en bases de conocimiento técnicas en inglés, voyage-3-large o voyage-code-3 son la elección que recomendamos sin dudar. El precio es algo superior al de OpenAI pero la calidad en esos nichos lo justifica.

¿Cuándo elegir Jina embeddings v4?

Jina embeddings v4 es el modelo más interesante de la generación 2026 si necesitas multimodal (texto + imagen en el mismo espacio vectorial) y/o multilingüe agresivo. Jina ha apostado fuerte por publicar los pesos (Apache 2.0 con restricciones para producción comercial intensiva, conviene leer la licencia con cuidado), por soportar 89 idiomas y por tener una variante multimodal que rinde competitivamente frente a CLIP y sus sucesores.

Su sweet spot son los casos donde necesitas embeber catálogos con imagen + descripción, sistemas de recomendación con assets visuales, búsqueda en e-commerce o documentos técnicos con figuras donde el contexto visual aporta. El modelo jina-embeddings-v4 produce vectores de hasta 2.048 dimensiones truncables, ventana de 32k tokens y soporte nativo para query/passage asimétrico (prefijos query: y passage: que mejoran retrieval).

Donde Jina no encaja: si tu caso es puramente texto en inglés y dispones de presupuesto, OpenAI o Voyage probablemente te darán algo más de calidad raw. Si tu caso es texto puro en español, Cohere suele ganar. Pero como modelo “navaja suiza” multimodal/multilingüe con pesos publicados, Jina es la opción más interesante de su categoría.

¿Cuándo elegir open source: BGE, GTE, E5 y compañía?

La familia open source ha cerrado el gap más de lo que muchos esperaban. BGE-M3 (de BAAI) es nuestra primera recomendación cuando un cliente necesita on-premise estricto y multilingüe robusto: rinde a nivel de los comerciales en español, soporta dense retrieval + sparse retrieval + multi-vector en un solo modelo (algo único), y se despliega cómodamente en una GPU de 16 GB. La licencia Apache 2.0 elimina dudas legales.

GTE-large-en-v1.5 y el linaje E5 (intfloat/e5-large-v2, multilingual-e5-large-instruct) son alternativas sólidas: rinden bien en MTEB, son fáciles de servir con sentence-transformers o text-embeddings-inference de HuggingFace y permiten fine-tuning con datos propios sin restricciones. Para presupuestos ajustados y equipos con capacidad de gestionar infra ML, son alternativas reales a los modelos comerciales.

Donde el open source pierde: cuando el equipo no tiene capacidades MLOps para mantener el deploy (gestión de versiones, escalado, latencia P99, monitorización), cuando se necesita un SLA empresarial firme contra terceros, o cuando los volúmenes son tan bajos que no compensa el OPEX del cluster. Para una startup de 5 personas haciendo POC, BGE-M3 es overhead; para una empresa con 50 millones de queries/mes y un equipo ML competente, es la decisión obvia.

¿Qué modelo elegir según tu caso de uso real?

Las recomendaciones genéricas son útiles como mapa, pero la elección depende del caso de uso concreto. Esta sección resume las recomendaciones que damos en agencia cuando un cliente describe su proyecto. Cualquier embeddings empresa comparativa que termine en “depende” sin aterrizar es inútil; aquí aterrizamos.

¿Qué embedding para RAG documental en español?

Para RAG sobre documentación corporativa en español —el caso de uso más frecuente en empresa española—, la recomendación principal es Cohere embed-v4 combinado con Cohere rerank-3 como reranker, o como alternativa de coste reducido OpenAI text-embedding-3-large + reranker (Cohere rerank-3 o un cross-encoder open source como bge-reranker-v2-m3). En proyectos que hemos puesto en producción, esta combinación rinde nDCG@10 entre 0,72 y 0,82 en corpus reales (contratos, manuales, knowledge bases) frente al 0,55-0,65 que da un embedder mediano sin reranker.

La razón es doble: Cohere tiene fortaleza específica en español y el reranker compensa cualquier limitación del retrieval inicial, lo que permite usar incluso un embedder de gama media. En proyectos con presupuesto ajustado, hemos visto que text-embedding-3-small + rerank-3 rinde mejor que text-embedding-3-large solo, y cuesta menos.

Si la restricción es on-premise, BGE-M3 + bge-reranker-v2-m3 es la combinación open source equivalente. Las métricas son comparables a las del stack comercial, aunque el coste total (GPUs + ingeniería) solo sale rentable a partir de cierto volumen.

¿Qué embedding para búsqueda en código fuente?

Para búsqueda semántica en código, copilotos sobre repos privados o documentación técnica con snippets, Voyage voyage-code-3 es el líder claro en 2026. Está entrenado específicamente con corpus de código y queries técnicas asimétricas (la query es lenguaje natural, el doc es código), y rinde 10-15 puntos mejor que modelos generalistas en benchmarks de code retrieval.

Como alternativa open source, nomic-embed-code y jina-embeddings-v4 con prefijo de code retrieval son opciones razonables. Lo que no recomendamos es usar un embedder generalista de texto sobre código: la asimetría query-doc (natural language → código) requiere entrenamiento específico, y los modelos genéricos rinden por debajo del 0,5 nDCG@10 en estos casos.

¿Qué embedding para multilingüe agresivo (>5 idiomas)?

Cuando el corpus o las queries cruzan más de 5 idiomas con peso real (no inglés + traducciones), Cohere embed-v4 y Jina embeddings v4 son los líderes. Cohere tiene la ventaja de SLA empresarial y disponibilidad en hyperscalers; Jina tiene la ventaja de pesos publicados y un perfil multilingüe nativo.

BGE-M3 es la alternativa open source más sólida y, en algunos pares de idiomas (español-portugués, francés-italiano, alemán-inglés), rinde a nivel de los comerciales. Para casos que mezclan idiomas asiáticos (chino, japonés, coreano) con europeos, evaluar específicamente: las diferencias entre modelos pueden ser grandes en esos pares.

¿Qué embedding para on-premise estricto sin envío de datos a terceros?

Si el cliente tiene obligación de no enviar datos a APIs externas —banca, sanidad, defensa, sector público crítico—, las opciones son open source. BGE-M3 es nuestra primera recomendación por su balance multilingüe + Apache 2.0 + densidad/dispersión configurable. GTE-large-en-v1.5 si el caso es inglés. multilingual-e5-large-instruct como alternativa de peso ligero (560 M parámetros) que rinde bien en latencia.

Para servir estos modelos en producción recomendamos text-embeddings-inference de HuggingFace, que ofrece servidor optimizado con batching, ONNX runtime y soporte de GPU. Una A10G de AWS o una L4 puede servir ~10.000 embeddings/seg con latencia P95 sub-50 ms para queries cortas.

¿Qué embedding para coste agresivo (millones de docs, presupuesto mínimo)?

Cuando el factor crítico es coste —típicamente ingestas masivas de logs, web scraping, transcripciones de audio—, OpenAI text-embedding-3-small truncado a 512 dimensiones es nuestra recomendación. A 0,02 $/M tokens, indexar 10.000 millones de tokens cuesta 200 dólares, y los vectores truncados a 512 dim ocupan una cuarta parte que los de 1.536, abaratando la vector DB.

Como alternativa con tier gratuito, Jina embeddings v3-small ofrece un free tier generoso para volúmenes pequeños-medianos. Para volúmenes verdaderamente masivos, montar BGE-small en una instancia spot puede salir más barato que la API, pero el OPEX de gestionar esa infra raramente justifica el ahorro por debajo de 100 millones de queries/mes.

Tabla resumen: recomendación por caso de uso

Caso de uso	Primera opción	Alternativa	Open source
RAG documental español	Cohere embed-v4 + rerank-3	OpenAI 3-large + rerank-3	BGE-M3 + bge-reranker-v2-m3
Búsqueda en código	Voyage voyage-code-3	Jina v4 (code prefix)	nomic-embed-code
Multilingüe agresivo (>5 idiomas)	Cohere embed-v4	Jina embeddings v4	BGE-M3
On-premise estricto	BGE-M3	multilingual-e5-large-instruct	GTE-large-en-v1.5
Coste agresivo (M de docs)	OpenAI 3-small (trunc. 512)	Jina v3-small (free tier)	BGE-small / E5-small
Multimodal (texto + imagen)	Jina embeddings v4	Voyage multimodal	OpenCLIP / SigLIP
Vertical legal inglés	Voyage voyage-law-2	Cohere embed-v4 + fine-tune	BGE-M3 + fine-tune
Vertical finanzas	Voyage voyage-finance-2	Cohere embed-v4 + fine-tune	BGE-M3 + fine-tune

¿Cómo evaluar embeddings en tu propio dominio (gold standard)?

Insistimos en este punto porque es donde se gana o se pierde la decisión: ningún MTEB ni leaderboard externo te dirá qué modelo rinde mejor en tu corpus. El único método válido es construir un gold standard propio y evaluar candidatos sobre él. Es trabajo, pero no es opcional para una decisión que va a durar 2-3 años en producción.

¿Cómo construir un set de evaluación de 100-500 queries con relevant docs?

El gold standard mínimo viable son 100 queries reales con sus documentos relevantes marcados manualmente. 100 es el suelo estadísticamente útil (intervalos de confianza razonables para diferencias de 3-5 puntos); 300-500 es el ideal para diferenciar modelos cercanos con confianza. Más de 500 es casi siempre overkill salvo en casos muy críticos.

El proceso que seguimos en agencia: extraer queries reales del log del producto (si existe), o queries representativas que el equipo de negocio considera frecuentes. Para cada query, un humano experto en el dominio identifica los 3-10 documentos que considera relevantes en el corpus completo. Es trabajo lento (10-30 minutos por query) pero no se delega: la calidad del gold standard determina la fiabilidad de toda la evaluación posterior.

Trucos prácticos: usar BM25 o un embedder mediano para generar candidatos top-50 que el evaluador valida en vez de buscar desde cero (reduce el tiempo a la mitad), categorizar queries por tipo (factual, comparativa, ambigua) para detectar dónde un modelo brilla o falla, y guardar trazas con relevancia graduada (no solo binario relevante/no, sino 0/1/2/3) para calcular nDCG con más precisión.

¿Qué métricas usar: recall@k, MRR, nDCG?

Las tres métricas estándar que reportamos en cualquier evaluación de embeddings:

• Recall@k: porcentaje de queries donde al menos uno de los documentos relevantes aparece en el top-k. Es la métrica más directa de “el retrieval funciona o no”. Para RAG, lo que importa es recall@5 y recall@10 (los chunks que efectivamente pasarán al LLM o al reranker).
• MRR (Mean Reciprocal Rank): 1 dividido entre la posición del primer documento relevante, promediado. Mide qué tan arriba aparece el primer hit. Útil para casos donde solo el primer resultado importa (búsqueda navegacional).
• nDCG@k (normalized Discounted Cumulative Gain): la métrica más completa, considera la posición y la relevancia graduada de todos los hits en el top-k. Es la que usamos como métrica principal en evaluaciones serias.

En proyectos en producción, además medimos métricas downstream: si el RAG genera respuestas, ¿qué porcentaje son correctas según evaluador humano o juez LLM? Esto cierra el loop entre retrieval y output final, y a veces revela que un modelo con peor recall@10 produce mejores respuestas finales porque ordena mejor el top-3 que efectivamente se inyecta al LLM.

¿Cómo comparar candidatos y elegir el ganador?

El protocolo que usamos: seleccionar 3-4 candidatos (no más, no menos) basados en filtros previos (presupuesto, restricciones, MTEB > umbral), embeber el corpus completo con cada uno, ejecutar las queries del gold standard, calcular recall@5/10, MRR y nDCG@10 para cada uno. Reportar diferencias con intervalos de confianza bootstrap (si los datos son pocos, la diferencia entre dos modelos puede no ser significativa).

El ganador no se elige solo por la métrica más alta: se considera el balance calidad/coste/operabilidad. A veces el segundo en métrica es el primero en decisión final porque cuesta la mitad. Documentar esta decisión es importante: dejar por escrito por qué se eligió Cohere sobre OpenAI con un delta de +4 puntos nDCG facilita defender la decisión en revisiones futuras y reduce el riesgo de “el siguiente CTO viene y cambia todo sin entender por qué”.

¿Cómo gestionar la migración entre modelos de embeddings sin caída?

Una pregunta que llega tarde en muchos proyectos: cuando el modelo actual queda obsoleto o cuando el resultado de la evaluación dice que hay uno mejor, ¿cómo se cambia sin parar el servicio? Los embeddings no son intercambiables —vectores generados por modelos distintos viven en espacios distintos y no son comparables—, así que migrar implica re-embebido completo del corpus. Hay tres estrategias razonables.

¿Cuánto cuesta un re-embedding masivo y cómo planificarlo?

Calcular: tokens totales del corpus × precio por millón. Un corpus de 50 millones de tokens (típico de una empresa media-grande con knowledge base seria) cuesta 6,5 dólares con text-embedding-3-large y se completa en horas con paralelización. Un corpus de 5.000 millones de tokens (transcripciones de call center, logs, web scraping a gran escala) cuesta 650 dólares y puede llevar varios días. Si el corpus es de billones de tokens, hay que negociar pricing con el proveedor.

El re-embebido en sí no es lo caro: lo caro es la coordinación. Hay que coordinar con el equipo de vector DB para no quedarse sin capacidad de almacenamiento, gestionar versiones (los nuevos vectores conviven temporalmente con los viejos), validar la nueva calidad antes de hacer cutover y tener plan de rollback si algo va mal. En proyectos serios, planificamos re-embebidos como migraciones de base de datos, con ventanas, backups y monitorización.

¿Cómo hacer dual storage temporal?

La técnica más segura: mantener ambos índices (viejo y nuevo) en paralelo durante un periodo de 1-4 semanas. Las queries van por defecto al índice antiguo (producción estable) pero se ejecutan también contra el nuevo y se loggea la comparación: top-K de cada uno, métricas downstream si la query produce respuesta. Esto permite detectar regresiones específicas antes del cutover.

El coste de dual storage es real: el doble de almacenamiento vectorial durante la migración. En vector DBs gestionadas (Pinecone, Weaviate Cloud), esto puede duplicar la factura temporalmente. Compensa la seguridad que aporta: el porcentaje de migraciones de embeddings que se descubren problemáticas en la primera semana es alto, y un rollback limpio sin dual storage es mucho más doloroso que el coste extra de almacenamiento.

¿Cómo hacer A/B testing por porcentaje de tráfico?

Para migraciones donde se quiere validar impacto downstream (no solo métricas de retrieval sino satisfacción real del usuario), routear un 5% del tráfico al nuevo modelo durante 1-2 semanas, medir métricas de negocio (tasa de éxito de respuesta, tiempo en respuesta, escalation a humano si aplica, NPS si se mide) y comparar contra el control. Si las métricas son neutras o positivas, escalar a 25%, luego 50%, luego 100%.

Este protocolo es overkill para muchos casos pero imprescindible cuando el RAG es central al producto (search interno, copiloto crítico, asistente comercial). Lo hemos aplicado en migraciones donde la métrica de retrieval mejoraba 8 puntos pero la satisfacción del usuario caía 3 puntos: el modelo nuevo respondía con respuestas más precisas pero menos “explicativas”, y los usuarios percibían eso como peor. Sin A/B downstream, la decisión basada solo en retrieval habría sido equivocada.

¿Cuándo merece la pena fine-tunear embeddings con datos propios?

El fine-tuning de embeddings se ha vuelto progresivamente más accesible (LoRA sobre modelos de 100-500 M parámetros, frameworks como sentence-transformers con soporte directo) pero sigue siendo una decisión de inversión seria. Conviene saber cuándo justifica el esfuerzo y cuándo no.

¿Qué dominios justifican fine-tuning?

Dominios con vocabulario muy específico no cubierto en el pretraining: terminología médica especializada, jerga jurídica vertical (no derecho general, sino p. ej. derecho marítimo), código propietario con APIs internas, productos químicos o farmacéuticos, jerga militar/defensa, lenguaje de un sector industrial concreto. En estos casos, los modelos genéricos no han visto suficientes ejemplos en pretraining como para distinguir matices que para el experto del dominio son críticos.

La señal que indica que necesitas fine-tuning: ejecutas tu gold standard sobre 3-4 candidatos comerciales, el mejor rinde por debajo del 0,6 nDCG@10 y, al inspeccionar los errores, ves que el modelo confunde términos que un humano del dominio nunca confundiría. En ese momento, ningún modelo genérico te va a sacar del agujero; necesitas ajustar el embedder a tu corpus.

¿Qué datos necesitas para fine-tunear?

El formato más útil son pares query-documento con relevancia binaria o graduada. Mínimo viable: 1.000-5.000 pares de entrenamiento + 200-500 de evaluación. Ideal: 10.000-50.000 pares. Los pares pueden venir de logs de búsqueda con clics, de FAQs internas (la pregunta es la query, el doc de respuesta es relevante), de datasets de QA del dominio o de generación sintética con LLMs (con validación humana).

Una técnica que funciona bien: usar un LLM (gpt-5, Claude) para generar queries sintéticas a partir de documentos del corpus (“genera 3 preguntas que esta sección respondería”), validar con humano una muestra del 10-20% y usar el resto como datos débilmente supervisados. Esto reduce drásticamente el coste de etiquetado manual.

¿Qué uplift es realista esperar?

En dominios verticales con corpus medio (10-100k documentos) y 5.000+ pares de entrenamiento, hemos visto uplifts típicos de 5-15 puntos en nDCG@10 partiendo de un modelo base ya competente (BGE-M3, E5-large). En dominios muy específicos con corpus pequeño y datos limitados, el uplift puede ser de 3-7 puntos. Por debajo de 3 puntos, normalmente no compensa el esfuerzo de mantener un modelo custom.

El coste de operar un modelo fine-tuneado en producción es real: hay que versionar el modelo, mantener el pipeline de re-entrenamiento, monitorizar drift y re-evaluar periódicamente. En agencia, recomendamos fine-tuning solo cuando el caso de uso es central al negocio y el cliente tiene capacidad MLOps para sostenerlo en producción durante años.

¿Cómo se montan embeddings multimodales en empresa?

Los embeddings multimodales —texto + imagen, texto + audio, texto + vídeo en un espacio compartido— han pasado de ser experimento académico a producto real en 2026. Los casos de uso empresariales son cada vez más comunes: búsqueda en catálogo de e-commerce, recomendación con assets visuales, búsqueda en documentación técnica con figuras, moderación de contenido, análisis de transcripciones de call center con sentiment del audio.

¿Texto + imagen: CLIP, Jina v4 y Voyage multimodal?

CLIP sigue siendo la referencia conceptual, pero los modelos derivados (OpenCLIP, SigLIP de Google) han superado al original en calidad. En 2026, los modelos prácticos para empresa son Jina embeddings v4 (multimodal nativo, 89 idiomas, ventana de contexto grande), Voyage multimodal y, en open source, SigLIP-large y EVA-02-CLIP.

El caso típico que implementamos: un cliente de e-commerce con 500.000 productos quiere búsqueda semántica donde la query puede ser texto (“zapatos rojos para boda”) y el resultado considere tanto la descripción como la imagen del producto. Solución: embeber descripción y al menos una foto principal por producto, almacenar ambos vectores en el índice, en query time embeber el texto y buscar contra el índice combinado con ponderación (0,6 imagen + 0,4 texto o similar, según evaluación).

La elección entre Jina y Voyage para multimodal depende de presupuesto y de si necesitas multilingüe. Jina es más fuerte en multilingüe; Voyage es más fuerte en inglés y en verticales específicos. SigLIP es la opción open source si on-premise es requisito.

¿Texto + audio: dónde estamos en 2026?

El espacio de embeddings de audio es más experimental. Para casos donde se necesita búsqueda semántica en transcripciones de audio, lo pragmático sigue siendo transcribir con Whisper o similar y embeber el texto resultante. Para búsqueda semántica directa en audio (sin transcribir), modelos como CLAP (Contrastive Language-Audio Pretraining) y derivados ofrecen resultados razonables pero no llegan al nivel de calidad de texto puro.

Recomendamos no perseguir embeddings nativos de audio salvo casos muy específicos (búsqueda en música, búsqueda en sonidos ambientales, análisis acústico). Para call centers, ATC, contact centers en general, la solución estándar sigue siendo transcripción + embedding de texto + posibles features auxiliares de audio (tono, prosodia) como metadata, no como espacio vectorial principal.

¿Casos: recomendador con imagen, búsqueda en catálogo?

Los dos casos más rentables que hemos puesto en producción: recomendador en e-commerce (“clientes que vieron X también vieron Y” con embeddings de catálogo combinando texto e imagen, lo que captura similitud visual que el catálogo textual no captura) y búsqueda en catálogo extenso donde la query natural (“una mesa de comedor moderna con patas metálicas”) devuelve resultados que combinan match textual y match visual.

El ROI de estos casos suele ser tangible: incrementos de CTR del 8-15% y de conversión del 3-7% comparado contra búsqueda solo textual o filtros tradicionales. La inversión es relativamente contenida si se usa un proveedor comercial (Jina, Voyage), porque la complejidad principal está en el pipeline de embedding del catálogo y en la integración con el frontend de búsqueda, no en el embedder en sí.

¿Qué errores típicos cometen los equipos al implementar embeddings?

Después de auditar decenas de pipelines RAG y sistemas de búsqueda semántica, los errores se repiten con una uniformidad casi cómica. Listamos los cinco que vemos en cada segundo proyecto y que cuestan más dolor del que parecen.

¿Por qué usar dimensiones excesivas es un error caro?

El error típico: “usamos 3.072 dimensiones porque es el default de OpenAI y queremos máxima calidad”. Resultado: el índice vectorial ocupa 6× más, las búsquedas ANN son 2-3× más lentas, la factura de Pinecone se triplica y la diferencia en métrica de retrieval frente a 512 dimensiones es de 0,5 puntos nDCG. Es la decisión más costosa por defecto que vemos.

La recomendación es: truncar a 512 o 768 dimensiones por defecto, evaluar en tu gold standard si la pérdida es aceptable (en >90% de los casos lo es), y solo subir si el dominio realmente lo demanda. Esto aplica especialmente a modelos con soporte Matryoshka, que están entrenados para que las primeras N dimensiones contengan la mayor parte de la información semántica.

¿Por qué no usar reranker es dejar calidad sobre la mesa?

El reranker (cross-encoder que reordena los top-50 del retrieval inicial) es la mejora más barata de calidad disponible en 2026. Cohere rerank-3, bge-reranker-v2-m3 open source o Jina reranker añaden 200-400 ms de latencia y mejoran las métricas de retrieval entre 8 y 20 puntos típicamente. No usarlo en un sistema RAG serio es un error que ahora cuesta defender.

El patrón que recomendamos: embedder mediano (rápido, barato) recupera top-50 candidatos, reranker procesa esos 50 y devuelve top-5 ordenados, top-5 va al LLM. Esta arquitectura “retrieve-then-rerank” es prácticamente el estándar en 2026, y permite usar embedders más baratos sin sacrificar calidad final.

¿Por qué no evaluar en tu propio dominio condena el proyecto?

Lo dijimos arriba y lo repetimos: elegir el modelo solo por MTEB es la causa nº 1 de proyectos RAG que decepcionan en producción. El benchmark genérico te da un mapa de “esto no es horrible”, no un termómetro de “esto va a funcionar en tu caso”. Sin gold standard propio, estás eligiendo a ciegas y las consecuencias se notan en el primer mes en producción.

El esfuerzo de construir un gold standard (1-2 semanas de un experto de dominio + un ingeniero) es despreciable frente al coste de elegir mal: re-embebido, migración de índice, replanteo de arquitectura. Esta es la inversión con mejor ROI que un equipo de RAG puede hacer al inicio del proyecto.

¿Por qué mezclar versiones distintas en el mismo índice rompe todo?

El error que más veces hemos diagnosticado a posteriori: el índice vectorial contiene documentos embebidos con dos o más versiones de modelo distintas (porque el equipo cambió de modelo y solo re-embebió los documentos nuevos). Los vectores viven en espacios distintos, no son comparables, y el retrieval da resultados aparentemente aleatorios.

La regla es simple: un índice = un modelo + una versión + una configuración de dimensiones. Cualquier cambio requiere re-embebido completo o índice nuevo. Esto debe documentarse en el ADR del proyecto, monitorizarse y revisarse cada vez que se considera cambiar de modelo.

¿Por qué confundir similitud semántica con relevancia condena el RAG?

Un error conceptual: los embeddings miden similitud semántica, no relevancia para una intención específica. Dos textos pueden ser muy similares semánticamente y, sin embargo, uno responde la pregunta y otro no. Esto se ve sobre todo en queries comparativas (“diferencia entre X e Y”) o queries con intención específica donde un documento sobre X solo, muy similar semánticamente, no responde la query comparativa.

La mitigación: reranker, prompt engineering en el LLM para reformular queries, descomposición de queries complejas en sub-queries, y siempre evaluación downstream (no solo recall del retrieval sino calidad de la respuesta final). Si el equipo solo mide recall@10 y nunca mira las respuestas reales que el sistema produce, está optimizando para una métrica que no captura el valor final.

¿Cuáles son los próximos pasos para implementar embeddings bien en tu empresa?

Hemos cubierto la teoría, las métricas, los modelos, los casos de uso, la evaluación, la migración, el fine-tuning, el multimodal y los errores típicos. Si tienes que aterrizar una decisión esta semana, este es el orden que recomendamos seguir y que aplicamos en cada proyecto nuevo que arranca en Datalvar.

Primero, define el caso de uso con precisión: idioma dominante, volumen estimado de documentos y queries/mes, restricciones de privacidad y compliance, presupuesto disponible para infraestructura recurrente, y si el caso requiere multimodal. Sin estas cinco variables claras, cualquier comparativa modelos embeddings es un ejercicio académico. Si el caso de uso es un RAG documental clásico en español sin restricciones especiales, ya tienes el 80% de la respuesta: Cohere embed-v4 + rerank-3 o, si el presupuesto manda, OpenAI text-embedding-3-small truncado + reranker open source.

Segundo, construye un gold standard mínimo de 100-300 queries con sus documentos relevantes marcados por un humano que entienda el dominio. Esta es la inversión con mejor ROI del proyecto y la única defensa real contra elegir mal. Cualquier proveedor te enseñará sus números; lo que importa es cómo rinden en tus datos. Sin gold standard, cualquier embeddings empresa comparativa que hagas será adivinación informada.

Tercero, evalúa 3-4 candidatos sobre ese gold standard, reporta recall@10, MRR y nDCG@10 con intervalos de confianza, considera el balance calidad/coste/operabilidad y elige. Documenta la decisión por escrito —por qué este modelo, por qué no los otros, qué métricas justifican la elección— para que sea defendible en revisiones futuras. En proyectos en los que entramos a auditar 6-12 meses después, la falta de esta documentación es la causa nº 1 de cambios apresurados y costosos. Una buena comparativa de modelos de embeddings es un documento vivo que orienta decisiones durante años, no un PDF que se archiva.

Preguntas frecuentes

¿Cuál es la diferencia real entre text-embedding-3-large y embed-v4 de Cohere para empresa?

text-embedding-3-large y Cohere embed-v4 son los dos modelos comerciales más usados en RAG empresarial en 2026 y tienen perfiles bastante distintos. OpenAI lidera en integración con su ecosistema (GPT-4o, Azure OpenAI, herramientas) y en facilidad de adopción; Cohere lidera en calidad multilingüe real (especialmente español, francés, alemán y portugués) y ofrece su reranker rerank-3 como complemento natural. En benchmarks neutrales con corpus en español, embed-v4 supera a OpenAI 3-large en 3-7 puntos nDCG@10 consistentemente.

La decisión práctica depende de tres cosas: en qué idioma trabajas (si es español o multilingüe, Cohere; si es inglés con presupuesto y ya estás en OpenAI/Azure, OpenAI), cuál es tu reranker (si vas a usar Cohere rerank-3, embed-v4 se acopla mejor; si usas un reranker open source, los dos embedders quedan equivalentes en pipeline final), y cuál es tu presupuesto (precios similares, diferencia marginal a escala razonable). En proyectos donde hemos evaluado ambos sobre el mismo gold standard español, Cohere ha ganado en 7 de cada 10 casos, pero la magnitud de la ventaja varía mucho según el corpus específico.

¿Es viable BGE-M3 como alternativa open source a OpenAI para producción seria?

Sí, con matices. BGE-M3 (de BAAI) es uno de los modelos open source más fuertes en 2026: multilingüe nativo (100+ idiomas), soporte de dense + sparse + multi-vector retrieval en un solo modelo, licencia Apache 2.0 sin restricciones comerciales, y rendimiento competitivo con los comerciales en MTEB y especialmente en retrieval multilingüe. Para casos donde on-premise es requisito (banca, sanidad, sector público), es nuestra primera recomendación.

Los matices: requiere capacidad MLOps real para servirlo en producción (GPUs, scaling, monitorización), el throughput máximo en una sola GPU es menor que el de una API comercial bien dimensionada, y no hay SLA empresarial contra un tercero al que escalar problemas. Para una empresa con equipo ML competente y volúmenes que justifiquen el deploy (>10 millones de queries/mes típicamente), es viable y rentable. Para un equipo pequeño sin capacidad de infraestructura ML, la API comercial sale más barata cuando se cuenta el coste total (no solo compute).

¿Cómo de importante es el reranker en un pipeline de embeddings empresarial?

Crítico, y subestimado por equipos sin experiencia. El reranker (un cross-encoder que recibe la query y un documento candidato y produce un score de relevancia más preciso que el dot product de embeddings) mejora las métricas de retrieval entre 8 y 20 puntos típicamente, con un coste de latencia de 200-400 ms adicionales para top-50. Es la mejora más rentable disponible en arquitectura RAG en 2026.

El patrón estándar: embedder rápido y barato recupera top-50 candidatos del índice vectorial; reranker procesa esos 50 (uno a uno, en cross-encoder) y devuelve top-5 reordenados; top-5 va al LLM. Esto permite usar embedders de gama media (e incluso text-embedding-3-small o BGE-small) sin sacrificar calidad final, porque el reranker compensa imperfecciones del retrieval inicial. En proyectos donde un cliente nos pide “mejorar el RAG” y no tienen reranker, añadirlo suele ser la primera intervención y la que más mueve la aguja.

¿Cuánto cuesta realmente embeber 10 millones de documentos con un modelo comercial?

Depende del tamaño medio de cada documento. Asumiendo 500 tokens por documento (chunk típico), 10 millones de documentos son 5.000 millones de tokens. Con text-embedding-3-small a 0,02 $/M tokens, el coste es 100 dólares. Con text-embedding-3-large a 0,13 $/M tokens, 650 dólares. Con Cohere embed-v4 a ~0,12 $/M, 600 dólares. Con Voyage voyage-3 a 0,06 $/M, 300 dólares.

A esto hay que sumar el coste de almacenamiento en vector DB —que depende de las dimensiones, no del proveedor del embedding— y el coste de queries en producción (que normalmente es 10-100× menor que el ingest porque las queries se embeben de a una, no por billones). El coste total típico de un sistema RAG empresarial bien dimensionado (50M docs, 1M queries/mes) se mueve entre 800 y 3.000 € al mes en infraestructura, dominado por vector DB y LLM de generación, no por embeddings.

¿Cuándo conviene fine-tunear un embedder propio en lugar de usar uno comercial o open source de stock?

Cuando concurren tres condiciones: dominio muy específico con vocabulario que los modelos genéricos no han visto suficiente (medicina especializada, jerga legal vertical, código propietario con APIs internas), datos de entrenamiento disponibles (5.000+ pares query-doc con relevancia marcada, idealmente más), y el RAG es central al producto con justificación de inversión a 2-3 años. Si falta cualquiera de las tres, suele ser mejor seguir con un modelo de stock + reranker + posibles trucos de prompt engineering.

El uplift realista en condiciones favorables es de 5-15 puntos nDCG@10 frente al mejor stock disponible, partiendo de un modelo base ya competente (BGE-M3, E5-large) y aplicando LoRA con datos del dominio. Por debajo de 3-5 puntos de uplift, raramente compensa el coste recurrente de mantener un modelo custom en producción: hay que versionar, re-entrenar periódicamente, monitorizar drift, mantener pipeline de evaluación. En proyectos en agencia, recomendamos fine-tuning solo cuando el caso de uso lo exige y el cliente tiene capacidad MLOps para sostenerlo.

¿Qué pasa si mezclo documentos embebidos con dos modelos distintos en el mismo índice vectorial?

El sistema deja de funcionar de forma predecible. Vectores generados por modelos distintos viven en espacios vectoriales distintos: no son comparables ni con dot product ni con coseno. El resultado del retrieval será aparentemente aleatorio, con documentos del modelo A apareciendo en queries que deberían recuperar del modelo B y viceversa. Lo peor es que no falla con un error claro: simplemente da resultados malos sin avisar.

La regla operativa: un índice vectorial = un modelo + una versión + una configuración de dimensiones. Cambiar cualquiera de estos parámetros obliga a re-embebido completo del corpus. Esto debe documentarse explícitamente, monitorizarse con metadata por documento (modelo y versión usados para embeber) y validarse en CI antes de cualquier deploy. Hemos visto sistemas en producción durante meses con esta corrupción silenciosa hasta que alguien preguntó por qué las búsquedas eran “extrañas”; recuperar la integridad requirió re-embebido completo y migración del índice.

¿Qué embedder elegirías hoy para un RAG en español sobre 5 millones de documentos corporativos?

Recomendación con presupuesto razonable: Cohere embed-v4 truncado a 1.024 dimensiones + Cohere rerank-3 como reranker, almacenado en un Qdrant o un Pinecone serverless según volumen de queries. Es el stack que mejor balance calidad/coste/operabilidad ofrece para RAG documental en español en 2026, con SLA empresarial, soporte multilingüe robusto por si el corpus evoluciona, y reranker integrado del mismo proveedor.

Recomendación con presupuesto ajustado: OpenAI text-embedding-3-small truncado a 768 dimensiones + bge-reranker-v2-m3 open source como reranker, sobre Qdrant self-hosted en una instancia mediana. Esta combinación cuesta una fracción del stack anterior y rinde a un 90-95% de su calidad con un buen gold standard que valide la decisión. Para 5 millones de documentos con chunks de 500 tokens, hablamos de 2.500 millones de tokens a embeber: 50 dólares con OpenAI 3-small vs 300 dólares con Cohere; la diferencia se nota en la factura pero rara vez justifica la elección por sí sola.

Recomendación con restricción on-premise estricta: BGE-M3 truncado funcionalmente a 1.024 dimensiones + bge-reranker-v2-m3, servidos con text-embeddings-inference de HuggingFace en una A10G o L4, con Qdrant self-hosted. Stack 100% open source, sin envío de datos a terceros, calidad competitiva con los comerciales en español, y operativamente sostenible si el equipo tiene capacidad MLOps básica.