Embeddings comerciales comparados: OpenAI, Cohere, Voyage y Jina

Segunda entrega del bloque de modelos. Con los seis criterios de la entrega anterior en la mano, toca aplicarlos a los cuatro proveedores comerciales de embeddings más presentes en proyectos reales, y hablar sin adornos de lo que significa poner una API ajena en el camino crítico de tu sistema.

Un modelo de embeddings comercial se consume por HTTP: envías texto, recibes vectores, pagas por tokens procesados. No hay GPU que aprovisionar, ni contenedor que actualizar, ni límite de memoria que vigilar. Ese es el argumento, y es bueno. La parte que se cuenta menos es que has metido una dependencia externa en el punto exacto del que depende que tu índice y tus consultas hablen el mismo idioma.

Los cuatro proveedores y su rasgo distintivo

OpenAI

Es el punto de partida por defecto de la mayoría de proyectos, casi siempre porque el equipo ya tiene una clave de API para el modelo generador y añadir embeddings no cuesta ninguna integración nueva. Su familia actual ofrece dos tamaños —uno pequeño y económico, otro grande y algo mejor— con una ventana de contexto amplia y, sobre todo, con dimensionalidad ajustable: puedes pedir el vector recortado a menos dimensiones y ahorrar memoria e índice con una pérdida de calidad pequeña. Esa palanca es más útil de lo que parece cuando el corpus crece.

Su calidad multilingüe es correcta sin ser su bandera. Para español general funciona bien; para casos exigentes conviene compararlo con alternativas antes de darlo por bueno.

Cohere

Su rasgo propio es que trata el multilingüismo como una característica de primer orden, no como un añadido, y que distingue explícitamente entre el embedding de un documento y el de una consulta: la API pide que declares el tipo de entrada. No es un detalle cosmético. El modelo aplica un tratamiento distinto a cada uno, y usar el tipo equivocado degrada la recuperación de forma silenciosa. Es, de hecho, el error de integración más frecuente con esta familia.

Cohere ofrece además versiones comprimidas de los vectores —enteros de 8 bits, binarios— que reducen el almacenamiento en un orden de magnitud a cambio de algo de precisión, y es el mismo proveedor que da el reranker del que hablaremos en la entrega 27, lo que simplifica tener un solo contrato para las dos piezas.

Voyage

Es el proveedor más especializado del grupo. Su catálogo se organiza por finalidad: modelos generales, modelos orientados a código, modelos pensados para texto jurídico o financiero, y variantes optimizadas para latencia o para calidad. También ofrece ventanas de contexto largas y dimensionalidad configurable.

La promesa de los modelos por dominio es razonable —un embedding entrenado con código entiende que dos funciones equivalentes se parecen aunque no compartan identificadores—, pero es exactamente el tipo de afirmación que hay que verificar con tu propio corpus. Un modelo «de dominio» entrenado sobre un dominio parecido al tuyo pero no idéntico no garantiza nada.

Jina

Es el más híbrido en su planteamiento: publica pesos abiertos de varios de sus modelos y a la vez ofrece una API gestionada, de modo que puedes empezar por la API y migrar a autoalojado sin cambiar de espacio vectorial. Esa propiedad es valiosa precisamente por lo que vimos en la entrega anterior: es la única forma de cambiar de modo de despliegue sin reindexar.

Sus rasgos técnicos habituales son ventanas de contexto largas, buen soporte multilingüe y variantes orientadas a recuperación de código y a entradas multimodales. Como proveedor es más pequeño que los tres anteriores, lo que conviene tener en cuenta al evaluar riesgo de continuidad.

Comparativa por características

La tabla compara rasgos estructurales, no tarifas ni puntuaciones de benchmark: ambas cosas cambian cada pocos meses y envejecerían mal.

Cómo está estructurado el precio

Los cuatro cobran por millón de tokens de entrada. No hay coste por vector devuelto ni por dimensión: el mismo texto cuesta lo mismo pidas 256 o 3.072 dimensiones, lo que significa que recortar dimensiones ahorra en tu base de datos, no en la factura del proveedor.

Dentro de un mismo proveedor, los modelos grandes cuestan típicamente entre tres y cinco veces más que los pequeños, y entre proveedores las diferencias para modelos de gama equivalente están en el mismo orden de magnitud. Es un dato liberador: el precio rara vez debería decidir entre estos cuatro, porque la diferencia absoluta en un proyecto normal es menor que un par de días de ingeniería.

Donde sí importa el precio es en el pico de indexación. Un corpus de decenas de millones de tokens indexado con un modelo caro y reindexado tres veces durante el desarrollo —porque cambiaste el troceado, porque probaste otro modelo, porque encontraste un fallo en la ingesta— convierte una cifra pequeña en una incómoda. Conviene probar las estrategias de troceado sobre un subconjunto del corpus y reservar la indexación completa para cuando la decisión esté tomada.

Límites de tasa y latencia: lo que se nota en producción

Todos imponen límites de peticiones por minuto y de tokens por minuto, escalonados por nivel de cuenta. Esto casi nunca molesta en consulta —un embedding de una pregunta corta es trivial— y casi siempre molesta en indexación, que es exactamente el momento en que quieres ir rápido.

Las consecuencias prácticas son tres. La primera: agrupa los textos en lotes; todas las APIs aceptan varios textos por petición y hacerlo de uno en uno multiplica el tiempo total sin ahorrar nada. La segunda: implementa reintentos con espera exponencial desde el primer día, porque vas a recibir respuestas de límite excedido y una indexación que se cae a la mitad es un problema de estado, no sólo de tiempo. La tercera: haz la indexación reanudable, guardando qué fragmentos ya tienen vector, para no repetir trabajo ni pagar dos veces.

En latencia, la llamada de red añade en el mejor caso decenas de milisegundos y en el peor unos cientos, dependiendo de la región del proveedor y del tamaño del lote. En una consulta RAG completa eso es normalmente menos del cinco por ciento del tiempo total —la generación domina—, pero no es despreciable si tu diseño hace varias llamadas de embedding por consulta, como ocurre con multi-query o con HyDE, que vimos en las entregas 17 y 18. Ahí conviene paralelizar y cachear: los embeddings de consultas repetidas son un candidato obvio a caché.

Qué asumes cuando dependes de una API ajena

Esta es la parte que las páginas de producto no destacan, y merece enunciarse con precisión.

• Retirada de modelos. Un proveedor puede anunciar la depreciación del modelo que usas. Como cambiar de modelo obliga a reindexar todo el corpus, esa fecha de retirada se convierte en un plazo de proyecto impuesto desde fuera. Conviene mirar el historial de depreciaciones del proveedor y sus plazos de aviso antes de comprometerse.
• Cambios de precio. Históricamente han bajado más que subido, pero no hay contrato que lo garantice y tu volumen de indexación puede crecer más deprisa que la bajada.
• Tratamiento de datos. Estás enviando el corpus entero a un tercero. Hay que leer qué se retiene, cuánto tiempo, si se usa para entrenar, en qué región se procesa y qué opciones de exclusión existen. Para material regulado, sanitario, jurídico o con datos personales, esta es una conversación con el departamento legal, no una decisión de ingeniería.
• Disponibilidad. Una caída del proveedor no degrada tu sistema: lo detiene. Sin embedding de la consulta no hay búsqueda vectorial. Un plan de contingencia razonable es poder caer a BM25 puro y avisar de que el servicio está en modo reducido.
• Determinismo. Un modelo que cambia por debajo sin cambiar de nombre produce vectores incompatibles con los ya indexados. Fija siempre la versión concreta del modelo en la configuración y guárdala como metadato de cada vector.

Cuándo un comercial es la elección correcta

Cuando el corpus es de tamaño moderado, cuando el equipo no tiene experiencia operando GPU, cuando la prioridad es llegar a producción pronto y cuando los datos no tienen restricciones de salida. Es la mayoría de proyectos que empiezan.

Deja de serlo cuando el volumen de indexación es muy alto y continuo, cuando el corpus no puede salir de tu infraestructura, o cuando necesitas garantías de que el modelo seguirá existiendo dentro de cinco años exactamente como hoy. Ese es el terreno de los modelos abiertos.

Qué viene ahora

La siguiente entrega recorre las familias abiertas más usadas —BGE, E5, GTE y Nomic—, cómo se sirven, qué GPU piden, qué rendimiento por lote dan, cómo afecta la cuantización y dónde está el punto de equilibrio frente a la API: coste fijo de una máquina frente a coste variable por token. Incluye además un detalle de integración que rompe muchos despliegues sin dar la cara.

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.