El mejor modelo de embeddings para RAG es el que gana con sus datos

Los equipos suelen elegir un modelo de embeddings abriendo una tabla de clasificación pública, seleccionando uno de los primeros nombres y comenzando a indexar sus documentos.

Seis meses después aparecen los problemas.

Los códigos exactos de producto no aparecen en los resultados de búsqueda. Las consultas multilingües recuperan la política equivocada. Cláusulas parecidas pero jurídicamente distintas quedan una junto a la otra. Los costos de infraestructura suben a medida que crece el índice. Y entonces el equipo descubre que cambiar de modelo implica volver a generar los embeddings de todo el corpus y reconstruir el índice vectorial.

Puede que el modelo original no fuera malo. Lo que estaba incompleto era el proceso de decisión.

El modelo de embeddings adecuado no es el que obtiene la puntuación más alta en un benchmark general. Es el modelo que recupera la evidencia correcta de sus datos, dentro de sus restricciones de latencia, costo, seguridad y operación.

Qué controla realmente un modelo de embeddings

Un modelo de embeddings convierte texto, código, imágenes u otro contenido en vectores numéricos. Un sistema de recuperación compara estos vectores para identificar el contenido semánticamente relacionado con la consulta del usuario.

En un pipeline de RAG típico, el modelo de embeddings forma parte de una secuencia más amplia:

Ingesta de documentos - análisis (parsing) - fragmentación (chunking) - embedding - indexación - recuperación - reordenamiento (reranking) - generación

Un modelo de embeddings débil puede impedir que la evidencia correcta llegue al modelo de lenguaje. Pero un modelo fuerte no puede compensar todos los demás problemas de arquitectura.

Por ejemplo: un análisis deficiente puede eliminar encabezados y relaciones de tablas; los fragmentos demasiado grandes pueden combinar hechos no relacionados; los fragmentos demasiado pequeños pueden destruir el contexto necesario; la falta de metadatos puede hacer imposible filtrar por permisos de acceso; un reordenamiento débil puede colocar contenido superficialmente parecido por encima de la respuesta correcta; y un LLM todavía puede malinterpretar evidencia recuperada correctamente.

Por eso la selección del modelo de embeddings debe tratarse como una decisión de arquitectura, no como un ejercicio de compra de modelos.

Por qué las tablas de clasificación públicas son útiles, pero insuficientes

MTEB se creó porque los modelos de embeddings se evaluaban antes con conjuntos de tareas limitados e incompatibles entre sí. Abarca recuperación, agrupamiento, clasificación, reordenamiento, similitud semántica y otras cargas de trabajo. Los hallazgos originales del benchmark mostraron que ningún método dominaba en todas las tareas. Más adelante, MMTEB amplió de forma significativa la cobertura multilingüe y de dominios. (arXiv)

Una tabla de clasificación puede responder:

¿Qué modelos merecen entrar en nuestra prueba?

No puede responder de forma confiable:

¿Qué modelo debería ejecutar nuestro sistema en producción?

Un conjunto de datos público rara vez reproduce su combinación de: terminología interna; abreviaturas; identificadores de producto; estructura de los documentos; idiomas; contenido duplicado; preguntas incompletas de los usuarios; restricciones de acceso; y distinciones propias de su industria.

Para RAG, la categoría de benchmark relevante suele ser la recuperación. Aun así, una puntuación media de recuperación puede ocultar debilidades serias justo en los tipos de consulta que importan para su negocio.

Qué debe guiar la decisión sobre el modelo

Calidad de recuperación en su corpus

El modelo debe encontrar la evidencia necesaria para responder la pregunta real, no simplemente un documento con vocabulario parecido.

Su conjunto de evaluación debe incluir varias clases de consultas:

Un modelo que funciona bien con preguntas comunes pero falla con condiciones negativas o identificadores puede no ser adecuado para búsquedas legales, financieras u operativas.

Adecuación al dominio y al idioma

"Multilingüe" no es una propiedad binaria.

Un modelo puede admitir un idioma en el plano técnico y aun así rendir mal con: vocabulario especializado; formas flexionadas; nombres transliterados; documentos en varios idiomas; abreviaturas del sector; y consultas escritas en un idioma sobre documentos en otro.

En los sistemas multilingües, incluya en el conjunto de referencia consultas en el idioma nativo y entre idiomas. No deduzca el rendimiento a partir de los resultados de MTEB en inglés.

Qwen3 Embedding admite más de 100 idiomas y dimensiones configurables de hasta 4096. BGE-M3 admite recuperación densa, dispersa y multivector, y procesa entradas de hasta 8192 tokens. Snowflake Arctic Embed 2.0 se diseñó para la recuperación multilingüe bajo una licencia Apache 2.0. Son buenos candidatos para una lista corta, no ganadores automáticos. (Hugging Face)

Comportamiento con consultas y documentos

Algunos modelos admiten modos separados para consultas y documentos, o instrucciones específicas por tarea.

Esto importa porque una consulta de búsqueda y un pasaje fuente cumplen funciones distintas: la consulta expresa una necesidad de información y el documento contiene la posible evidencia.

Usar el modo de entrada equivocado puede reducir la calidad de la recuperación incluso cuando el modelo en sí es fuerte.

Por lo tanto, la evaluación debe replicar exactamente la configuración de producción: el prefijo o la instrucción de consulta correctos; el modo de documento correcto; la misma normalización; la misma dimensión de salida; y la misma métrica de similitud.

Probar un modelo con la configuración predeterminada y desplegarlo con otra invalida la comparación.

Dimensiones de los vectores y costo del índice

Los vectores más grandes no son automáticamente mejores.

Pueden aumentar: el almacenamiento bruto; la memoria del índice; la transferencia por red; el costo de calcular distancias; el tamaño de los respaldos; y el tiempo de reindexación.

Varios modelos administrados ya admiten dimensiones flexibles. Los modelos de embeddings de tercera generación de OpenAI tienen por defecto 1536 y 3072 dimensiones, aunque la API permite acortar su salida. Cohere Embed v4 admite de 256 a 1536 dimensiones, y Voyage 4 admite de 256 a 2048. (OpenAI Platform)

Para un millón de vectores float32, la diferencia de almacenamiento bruto es considerable:

Estas cifras no incluyen el índice vectorial, los metadatos, las réplicas ni los respaldos.

La pregunta correcta no es:

¿Cuál es la mayor dimensión disponible?

Es:

¿A partir de qué dimensión la calidad adicional de recuperación deja de justificar el costo adicional de infraestructura?

Pruebe al menos dos dimensiones admitidas antes de comprometerse con el esquema del índice.

Longitud de contexto y estrategia de fragmentación

Un límite de contexto amplio es útil, pero no elimina la necesidad de diseñar los documentos.

Cohere Embed v4 admite un contexto de 128K, Voyage 4 admite 32K y los modelos de embeddings actuales de tercera generación de OpenAI aceptan hasta 8192 tokens. (Documentación de Cohere)

Eso no significa que un informe completo de 100 páginas deba convertirse en un solo vector.

Un fragmento útil debe conservar suficiente contexto para responder la pregunta y, al mismo tiempo, ser lo bastante acotado como para representar un único tema coherente.

Por eso su prueba debe evaluar combinaciones de modelo y fragmentación:

Un modelo más débil con una estrategia eficaz de fragmentación y reordenamiento puede superar a un modelo más fuerte dentro de un pipeline deficiente.

Despliegue, gobernanza y licencias

La lista corta de modelos debe cambiar cuando el sistema maneja: datos confidenciales de clientes; registros regulados; propiedad intelectual; información con restricciones de jurisdicción; documentos con permisos de usuario granulares; y cargas de trabajo que deben permanecer on-premises.

Una API administrada reduce el trabajo de servir el modelo, pero introduce una dependencia del proveedor, de la transferencia de datos y de la disponibilidad.

Un modelo de pesos abiertos aumenta el control, pero transfiere la responsabilidad de la infraestructura; el escalado; la aplicación de parches; el monitoreo; el servicio del modelo; la seguridad; el cumplimiento de licencias; y la optimización del rendimiento.

Los pesos abiertos tampoco garantizan el permiso de uso comercial. Jina Embeddings v5 Text Small, por ejemplo, se publica bajo CC BY-NC 4.0, mientras que BGE-M3 usa MIT y Qwen3 Embedding usa Apache 2.0. (Hugging Face)

La revisión de licencias debe hacerse antes de que las pruebas de rendimiento se conviertan en adopción en producción.

Migración y resiliencia frente al proveedor

Los espacios de embeddings son específicos de cada modelo. Los vectores generados por modelos no relacionados normalmente no se pueden comparar dentro del mismo índice.

Cambiar de modelo puede requerir: volver a generar los embeddings de todo el corpus; crear un segundo índice; sincronizar los documentos nuevos y actualizados en ambos índices; ejecutar pruebas A/B de recuperación; migrar el tráfico; y retirar el índice anterior.

Cuanto más grande sea el corpus y con más frecuencia cambie, más peso tiene este costo de migración.

La familia de modelos de cuarta generación de Voyage es poco común porque sus variantes large, standard y lite producen embeddings compatibles, lo que puede reducir parte de la fricción al migrar entre niveles de modelo dentro de esa familia. (Voyage AI)

La compatibilidad dentro de la familia de un proveedor no elimina la dependencia más amplia de ese proveedor. La arquitectura de producción debe conservar: los documentos fuente originales; IDs de fragmento deterministas; metadatos de modelo y dimensión; colas de regeneración de embeddings; índices versionados; y la capacidad de revertir cambios.

Una puntuación de decisión para modelos de embeddings

Un modelo debe evaluarse como parte de todo el sistema operativo, no de forma aislada.

La siguiente ponderación predeterminada puede adaptarse al caso de negocio:

Un modelo que gana un benchmark público pero no cumple un requisito obligatorio de residencia de datos recibe una calificación reprobatoria, no una pequeña penalización.

Del mismo modo, un modelo de bajo costo que reduce la recuperación de evidencia por debajo del umbral de aceptación del negocio no es económico. Solo traslada el costo de la infraestructura a respuestas incorrectas, verificaciones manuales y desconfianza de los usuarios.

Cómo realizar la evaluación

Defina el problema operativo

Documente quién usará el sistema; qué decisiones respalda; los tipos de fuente; los idiomas; el tamaño y el crecimiento del corpus; el tiempo de respuesta aceptable; la sensibilidad de los datos; el tope de costo; y las consecuencias de una recuperación incorrecta.

Sin este paso, el equipo evalúa tecnología sin haber definido qué es el éxito.

Construya un conjunto de referencia representativo

Cree aproximadamente 100-300 preguntas validadas para una evaluación inicial orientada a producción.

Cada pregunta debe incluir el documento fuente esperado; el pasaje de evidencia esperado; los pasajes alternativos aceptables; la categoría de la consulta; el idioma; la dificultad; y si el resultado correcto es "no se encontró evidencia".

Las preguntas sintéticas pueden ayudar a ampliar el conjunto, pero los expertos en la materia deben verificar los ejemplos críticos.

Pruebe una lista corta deliberadamente pequeña

Una lista corta razonable podría incluir un modelo administrado de menor costo; un modelo administrado de mayor calidad; una opción multilingüe; un modelo de pesos abiertos con permiso de uso comercial; y una configuración de recuperación híbrida.

Entre los ejemplos actuales están OpenAI text-embedding-3-small y text-embedding-3-large, Voyage 4, Cohere Embed v4, BGE-M3, Qwen3 Embedding y Snowflake Arctic Embed 2.0. Su documentación oficial muestra diferencias sustanciales en dimensiones, ventanas de contexto, modalidades, licencias y características de despliegue. (OpenAI Platform)

La lista corta debe ser lo bastante pequeña como para evaluarla correctamente.

Mida la calidad y el costo operativo

Como mínimo, registre:

No combine todos los resultados en un solo promedio antes de revisar las fallas por segmento. Diez fallas en noticias internas poco relevantes pueden ser aceptables. Diez fallas en exclusiones contractuales pueden no serlo.

Ejecute una prueba de aceptación de extremo a extremo

Las métricas de recuperación son necesarias, pero no suficientes.

Conecte las configuraciones de recuperación seleccionadas a los componentes previstos: base de datos vectorial; filtros; reranker; prompt; LLM; y capa de control de acceso.

Luego evalúe si la respuesta final: usa la evidencia correcta; la atribuye con precisión; distingue los hechos de las inferencias; rechaza conclusiones sin sustento; respeta los permisos a nivel de documento; y cumple la latencia requerida.

Esta validación de extremo a extremo sigue los mismos principios que describimos en nuestra guía para evaluar agentes de IA antes de pasar a producción (éxito a nivel de tarea, inspección de trazas, cumplimiento de políticas y economía), que deben medirse antes de comprometerse con la indexación del corpus completo.

¿Qué clase de modelo se ajusta a cada situación?

Cohere Embed v4 admite texto, imágenes y contenido PDF mixto. BGE-M3 puede producir representaciones densas, dispersas y multivector en un solo modelo. Estas capacidades solo aportan valor cuando existe el problema de recuperación correspondiente. (Documentación de Cohere)

Dónde fallan los proyectos de selección

Elegir la puntuación más alta de la tabla de clasificación

Un ganador del benchmark puede fallar con siglas internas, identificadores o consultas multilingües.

Elegir solo por el precio de la API

Generar embeddings puede ser barato en comparación con el almacenamiento vectorial, el servicio del modelo, la revisión humana y las futuras reindexaciones.

Elegir por la ventana de contexto

Admitir entradas largas no demuestra una recuperación precisa en documentos largos.

Suponer que el código abierto significa operación gratuita

La factura de la API desaparece, pero la capacidad de GPU, el despliegue, el monitoreo, las actualizaciones y el trabajo de ingeniería siguen ahí.

Probar modelos con pipelines distintos

Cambiar el tamaño de fragmento, el reranker o el top-K al mismo tiempo que el modelo hace imposible identificar la causa de la mejora.

Ignorar el caso sin respuesta

Un sistema que siempre recupera algo terminará presentando evidencia irrelevante como respaldo.

Tratar el control de acceso como una función para después

Los permisos por documento y por fragmento deben diseñarse antes de indexar. De lo contrario, el almacén vectorial puede convertirse en un segundo repositorio de datos cuyas reglas de acceso se apartan de las de los sistemas de origen.

Qué decidir antes de seleccionar un modelo

No empiece con:

¿Qué modelo de embeddings deberíamos usar?

Empiece con:

¿Qué evidencia debe recuperar este sistema, para quién, con qué restricciones y qué ocurre cuando la recuperación falla?

Una vez respondidas esas preguntas, la lista corta de modelos se reduce y la evaluación se vuelve medible.

La decisión más costosa sobre embeddings rara vez es elegir el segundo mejor modelo público. Es indexar un corpus grande antes de definir los criterios de aceptación, la ruta de migración y las restricciones operativas.

Mediante consultoría en IA y automatización de procesos, Fill System evalúa los requisitos de recuperación, las fuentes de datos, las restricciones de seguridad y el valor de negocio esperado antes de comprometer una arquitectura de embeddings, para que la decisión sobre el modelo se base en su realidad operativa y no en una tabla de clasificación.

Solicite un diagnóstico gratuito para validar la decisión de recuperación antes de pagar por generar embeddings y mantener el sistema equivocado.