Embeddings abiertos comparados: BGE, E5, GTE y Nomic

Tercera entrega del bloque de modelos. Los embeddings abiertos se descargan, se ejecutan en tu infraestructura y no envían nada a nadie. La pregunta interesante no es si son buenos —lo son—, sino a partir de qué volumen salen más baratos que una API y qué operativa hay que asumir a cambio.

Un modelo de embeddings abierto es un conjunto de pesos publicado con una licencia que permite descargarlo y ejecutarlo. Lo cargas, le pasas texto y obtienes vectores, exactamente igual que con una API pero sin salir de tu red. Cambia el modelo de coste —de variable por token a fijo por máquina—, cambia la responsabilidad operativa, y cambian algunos detalles de integración que producen fallos silenciosos si no se conocen.

Las cuatro familias más usadas

BGE

Publicada por la Beijing Academy of Artificial Intelligence, es probablemente la familia abierta más extendida en proyectos RAG. Ofrece los tres tamaños habituales —small, base y large—, versiones específicamente multilingües y una variante que produce a la vez representación densa, dispersa y multivector, pensada para hacer búsqueda híbrida con un solo modelo. La misma familia incluye rerankers, de los que hablaremos en la entrega 27.

Su punto fuerte es la madurez del ecosistema: hay documentación, integraciones en todos los orquestadores y mucha experiencia acumulada de terceros.

E5

Desarrollada por Microsoft, con la misma escala de tamaños y variantes multilingües bien consideradas. Su rasgo característico —y su trampa— es que exige prefijos de instrucción en el texto de entrada, como veremos enseguida. Es una familia sólida y conservadora, con versiones basadas en modelos de lenguaje grandes para quien quiera calidad por encima de coste.

GTE

De Alibaba, orientada a dar buena relación entre calidad y tamaño. Sus versiones recientes destacan por ventanas de contexto largas, lo que la hace atractiva cuando el troceado produce fragmentos grandes o cuando se indexan documentos con estructura que no conviene partir más.

Nomic

Su diferencia no es técnica sino de transparencia: publica datos y procedimiento de entrenamiento además de los pesos, algo poco habitual. Ofrece contexto largo, dimensionalidad reducible por truncamiento y una API gestionada opcional que permite empezar sin infraestructura y migrar a autoalojado sin cambiar de espacio vectorial. Usa también prefijos de instrucción.

El error de integración que casi nadie ve

Varios de estos modelos —E5 y Nomic de forma explícita, BGE con matices según versión— fueron entrenados con prefijos de instrucción: cadenas cortas que se anteponen al texto para indicar si lo que se está codificando es un documento del corpus o una consulta de usuario. En E5 son del tipo query: y passage:; en Nomic, search_query: y search_document:; en BGE, una instrucción en lenguaje natural que se antepone sólo a la consulta.

# Correcto con un modelo que exige prefijos
vec_doc = modelo.encode("passage: " + texto_del_fragmento)
vec_qry = modelo.encode("query: " + pregunta_del_usuario)

# Incorrecto: mismo tratamiento para los dos
vec_doc = modelo.encode(texto_del_fragmento)
vec_qry = modelo.encode(pregunta_del_usuario)

La versión incorrecta no lanza ningún error. Devuelve vectores de la dimensión esperada, la búsqueda funciona y los resultados son plausibles. Simplemente son peores de lo que deberían, y como no hay nada con que compararlos nadie lo detecta. Peor aún es el caso mixto: indexar con prefijo y consultar sin él, o al revés, que desalinea sistemáticamente los dos lados de la búsqueda.

La regla operativa es simple. Antes de indexar nada, lee la tarjeta del modelo y averigua si exige prefijos y cuáles. Encapsula la codificación en dos funciones, una para documentos y otra para consultas, de modo que sea imposible aplicar el tratamiento equivocado. Y guarda como metadato del índice qué prefijos se usaron, porque dentro de seis meses nadie se acordará.

Cómo se sirven

Hay tres niveles de sofisticación, y conviene no saltar al tercero antes de tiempo.

El primero es sentence-transformers dentro del propio proceso de la aplicación. Tres líneas de código, cero infraestructura. Es lo correcto para prototipos y para indexaciones puntuales, y es un problema en producción: cada réplica de tu aplicación carga su propia copia del modelo en memoria, el proceso de la API se bloquea mientras codifica y no hay forma de escalar el embedding por separado.

El segundo es un servidor de inferencia dedicado: Text Embeddings Inference, vLLM, Infinity, TorchServe o similares. El modelo vive en un servicio propio con su GPU, expone un endpoint HTTP y agrupa automáticamente las peticiones que llegan a la vez. Es lo que corresponde a un sistema en producción, y tiene la ventaja de que la interfaz se parece tanto a la de una API comercial que migrar entre ambas es cuestión de configuración.

El tercero es ONNX o TensorRT en CPU para modelos pequeños. Un modelo de tamaño small exportado a ONNX corre en CPU a una velocidad razonable, y si tu volumen de consultas es bajo puede evitarte la GPU por completo. Es una opción infravalorada.

GPU y rendimiento por lote

Los modelos de esta gama son pequeños comparados con un modelo generador. Un modelo base ronda los cientos de millones de parámetros; en precisión de 16 bits, eso son unos pocos gigabytes de memoria de vídeo, activaciones incluidas. Cabe holgadamente en cualquier GPU de gama media actual, y las versiones small caben en tarjetas modestas.

Lo que determina el rendimiento no es la memoria sino el tamaño de lote. Codificar de uno en uno desaprovecha la GPU por completo: el coste está dominado por la transferencia y la latencia de lanzamiento, no por el cálculo. Agrupar en lotes de decenas o cientos de fragmentos multiplica el rendimiento por un factor grande sin coste adicional. Dos matices prácticos: los lotes se llenan hasta el fragmento más largo, así que ordenar por longitud antes de agrupar ahorra cómputo desperdiciado; y el rendimiento se mide en tokens por segundo, no en fragmentos por segundo, porque un fragmento de 512 tokens cuesta mucho más que uno de 100.

Como orden de magnitud, una GPU de gama media con un modelo base y lotes bien formados indexa millones de fragmentos en horas, no en días. Para la mayoría de corpus corporativos, la indexación completa es un trabajo de una tarde.

Cuantización

Hay dos cosas distintas que se llaman igual y conviene separarlas.

La primera es cuantizar el modelo: ejecutarlo en 8 bits en lugar de 16. Reduce la memoria y acelera algo la inferencia, con una pérdida de calidad pequeña. En modelos de este tamaño el beneficio es moderado porque la memoria rara vez es el cuello de botella.

La segunda es cuantizar los vectores, y esa sí mueve la aguja. Pasar de coma flotante de 32 bits a enteros de 8 bits divide el almacenamiento por cuatro; la cuantización binaria lo divide por treinta y dos. La pérdida de precisión en la recuperación es menor de lo que la intuición sugiere, sobre todo si se aplica el patrón habitual: buscar sobre los vectores comprimidos para obtener un conjunto amplio de candidatos y reordenar ese conjunto con los vectores completos. Cuando el índice no cabe en memoria, esta es la primera palanca que hay que probar, antes de reducir dimensiones o de cambiar de modelo.

El punto de equilibrio frente a la API

El razonamiento, en órdenes de magnitud y sin tarifas concretas, es este.

Con una API pagas por token procesado. El coste crece linealmente y no tiene suelo: indexar mil documentos cuesta mil veces menos que indexar un millón, y si un mes no indexas nada, no pagas nada.

Autoalojando pagas por hora de GPU, indexes o no. Una GPU de gama media alquilada por horas cuesta al mes lo mismo que procesar por API un volumen de tokens del orden de las centenas de millones o los miles de millones, dependiendo del modelo comercial elegido y de la tarjeta. Esa es la frontera aproximada, y de ella salen tres consecuencias.

• Corpus estable con indexación puntual. La API gana casi siempre. Pagar una GPU parada las veinticuatro horas para indexar una vez al mes no tiene sentido; y si el pico es grande, se alquila una GPU por horas sólo para ese trabajo.
• Indexación continua de alto volumen. Autoalojar gana con claridad. Un corpus que ingiere flujo constante —noticias, tickets, registros, correo— satura una API cara y amortiza la máquina.
• Mucho tráfico de consulta. Depende del volumen, pero aquí pesa más la latencia que el coste: un servidor local elimina la ida y vuelta de red, que en consultas con varias llamadas de embedding se nota.

Falta un sumando en el lado de autoalojar que casi nadie contabiliza: el tiempo de ingeniería. Desplegar el servidor, monitorizarlo, actualizar versiones, gestionar reinicios y responder a una caída a las tres de la mañana tiene un coste real. Para un equipo pequeño, ese coste supera con frecuencia la diferencia de factura, y esa es la razón honesta por la que muchos proyectos que «deberían» autoalojar no lo hacen.

Límites

Autoalojar no elimina la dependencia, la traslada: pasas de depender de un proveedor a depender de tu propia capacidad operativa. Y no elimina el problema de la portabilidad, porque cambiar de modelo abierto obliga a reindexar exactamente igual que cambiar de comercial. Lo que sí garantiza es que el modelo que elegiste hoy seguirá existiendo mañana, con los mismos pesos y los mismos vectores. Para un sistema con vida prevista de años, esa garantía es un argumento de peso propio.

Qué viene ahora

La siguiente entrega aterriza todo esto en el caso que más lectores de esta serie tienen delante: el español. Modelos multilingües frente a modelos entrenados en inglés, qué se pierde exactamente al usar los segundos con texto español, cómo tratar corpus mezclados de documentación inglesa y preguntas españolas, y cómo montar una evaluación propia cuando los rankings públicos no cubren bien tu idioma.

Los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).

Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.