Cómo elegir un modelo de embeddings para RAG: el coste de cambiar pesa más que el precio

En 2026, las comparativas de modelos de embeddings suelen hacerse con cuidado y, aun así, resuelven una cuestión que apenas importa. Las hojas de cálculo listan el precio por millón de tokens. Las pruebas de recuperación se ejecutan en paralelo sobre doscientos documentos de muestra. Se va una semana en dimensiones de vectores. Luego se elige un modelo, el sistema sale a producción y, medio año después, el equipo se topa con un coste que nadie había presupuestado.

Este es un argumento que al principio suena equivocado, pero se sostiene. En la mayoría de sistemas RAG en producción, la diferencia de gasto mensual entre las opciones de embeddings alojadas es casi un error de redondeo. La cifra que de verdad da forma a la arquitectura es lo que cuesta cambiar de rumbo más adelante. Toda la argumentación es aritmética, así que va primero.

Tres ejes que suelen ponderarse al revés

Los modelos de embeddings se diferencian en tres aspectos, y los equipos a menudo los ordenan mal.

• La calidad de recuperación es lo primero que se mide. Se mide públicamente en MTEB y es real, pero la distancia entre los líderes es mucho menor de lo que da a entender el marketing.
• El coste acaba en la presentación. Normalmente se indica por millón de tokens, lo que lo hace parecer la variable dominante. No lo es, como muestran las cifras de abajo.
• La parte operativa casi nunca se puntúa. ¿Quién ejecuta el modelo? ¿Qué pasa cuando el proveedor lo retira? ¿Cuánto tarda una reconstrucción completa del índice? ¿Puede siquiera funcionar el modelo cuando cumplimiento normativo exige que los documentos no salgan de la red?

La tesis: las diferencias de calidad en la cima son demasiado pequeñas para cambiar el resultado de un producto, las diferencias de coste son demasiado pequeñas para cambiar un presupuesto, y la parte operativa es el eje que decide en silencio cuánto acabas atado.

Lo que cuestan de verdad los embeddings

El precio es la referencia de todo, así que empecemos por ahí. text-embedding-3-small de OpenAI cuesta $0.02 por millón de tokens, lo que la convierte en una de las opciones alojadas más rentables de 2026.

Ahora apliquémoslo a una carga realista. Toma un corpus de cien millones de tokens, una base de conocimiento interna realmente grande, e indexa todo:

corpus_tokens      = 100_000_000
price_per_million  = 0.02            # text-embedding-3-small
index_build_cost   = corpus_tokens / 1_000_000 * price_per_million
# 2.0

Dos dólares. Esa es toda la factura de la API por generar una vez los embeddings de un corpus de cien millones de tokens.

En el lado de las consultas pasa algo parecido. Con quinientas mil consultas al mes en text-embedding-3-small, generar los embeddings de las consultas cuesta unos $3.25 mensuales. Al lado de una factura de inferencia, una factura del almacén vectorial y la tarde de un solo ingeniero, eso es ruido.

¿Y la más grande, text-embedding-3-large? Cuesta más por token y puntúa más alto en los benchmarks públicos. La regla honesta para recurrir a ella: solo después de medir un fallo de recuperación que unos embeddings mejores arreglarían. Si el primer resultado es incorrecto porque los fragmentos están mal cortados, o porque las consultas no se parecen a los documentos en términos de similitud coseno, un codificador más potente no ayudará. Solo hará que una recuperación errónea sea algo más segura de sí misma.

El mismo razonamiento vale para la cuestión de la antigua ada-002 frente a 3-small. 3-small es más barata y en general más potente, así que un proyecto desde cero tiene una respuesta fácil. Si ya hay un índice construido, el precio no entra en juego, como explica la sección sobre migración más abajo.

OpenAI frente a Cohere

Esta comparación aparece en casi todas las revisiones de arquitectura y suele plantearse como una cuestión de calidad, cuando en realidad es una cuestión de encaje. Una advertencia: aquí no se dispone de los precios ni de las cifras de benchmark publicadas actualmente por Cohere, así que no se inventa ninguna. Lo que sí se puede decir es en qué se diferencia la forma de la decisión.

Cohere posicionó Embed v3 en torno a la recuperación multilingüe y la relevancia de búsqueda, no como el codificador generalista más barato. Para un corpus realmente multilingüe, sobre todo uno en el que los usuarios preguntan en un idioma sobre documentos en otro, ese es el eje que hay que probar con tus propios datos en lugar de fiarse de un ranking. La recuperación entre idiomas es donde la elección del modelo todavía cambia lo que ven los usuarios, porque un modelo que la maneja mal no se degrada con suavidad. Devuelve documentos irrelevantes con total seguridad.

La instrucción práctica es acotada. Con una carga monolingüe en inglés, la comparación es sobre todo académica, así que decide por motivos operativos. Cualquier otro caso debería construir un conjunto de evaluación de unas cien consultas en los idiomas reales y ejecutarlo antes de comprometerse, ya que aquí es donde peor generalizan los benchmarks.

Los modelos locales cambian la pregunta

Una cifra cambia el panorama: los modelos de embeddings locales como Nomic Embed y BGE quedan a menos de un cinco por ciento de text-embedding-3-large en MTEB, y reducen a cero el coste por token cuando el volumen es alto.

Es un cinco por ciento en un benchmark público, que ya de por sí exagera cuánto mueve los resultados la elección del modelo en un corpus concreto.

Por eso ejecutar un modelo en local no tiene que ver con ahorrar dinero. La factura de la API alojada ya era minúscula, y alojar por tu cuenta un modelo al estilo de sentence-transformers en tu propia GPU también tiene costes: la instancia, el despliegue y quien esté de guardia a las tres de la madrugada.

El autoalojamiento gana en tres aspectos, todos operativos:

1. Residencia de datos. Si los documentos no pueden salir de tu infraestructura, el debate termina, y la única pregunta abierta es qué modelo local usar.
2. Rendimiento predecible. Nada limita las peticiones salvo los ajustes que elijas, y no hay una factura por uso que prever. Un pipeline que reconstruye su índice a todas horas gana más con esa estabilidad que con ahorrarse las tarifas por token.
3. Control sobre tu propio espacio vectorial, que es lo que más importa y lo que menos se discute.

El verdadero coste de cambiar

Cada vector de un índice procede de un modelo concreto. Los vectores de modelos distintos no se pueden comparar y no existe conversión entre ellos. Cambia de modelo y cada vector almacenado pierde sentido frente a las nuevas consultas.

Así que cambiar de modelo significa reconstruir todo el índice. Aquí la forma habitual de presentar el coste confunde. Se citan cifras alarmantes por volver a generar los embeddings de un corpus grande, pero con los precios reales por token la parte de la API es pequeña. Toma cien millones de tokens a $0.02 por millón: son dos dólares, y un modelo diez veces más caro sigue dejando el total en unos pocos cientos.

El coste real no es una línea en el presupuesto de tokens. Es todo lo que la rodea:

• El pipeline que debe volver a sacar cada documento del almacenamiento y aplicar el mismo esquema de fragmentación, que quizá no se conservó.
• El índice paralelo que tiene que funcionar mientras ambas versiones están activas, porque un almacén vectorial en producción no se puede sustituir de forma atómica en horario laboral.
• La evaluación de la recuperación, que hay que rehacer desde cero porque cada umbral de relevancia se ajustó al antiguo espacio vectorial.
• Dos o tres semanas de atención de ingeniería, justo en el trimestre en que aflore el problema.

Esa es la trampa. No llega como una factura inesperada. Llega como un proyecto inesperado.

De ahí sale una regla sencilla para elegir: prefiere el modelo que tenga menos probabilidades de desaparecer bajo tus pies. La trayectoria del proveedor, una política de retirada clara y la opción de fijar una versión cuentan más que un punto extra en un benchmark, porque determinan si alguna vez te verás obligado a migrar. Es mejor mantener cuatro años un modelo ligeramente más débil que adoptar uno ligeramente más fuerte y abandonarlo a los dieciocho meses.

Guía rápida de decisión

• Corpus en inglés, desarrollo nuevo: text-embedding-3-small. Es el comienzo creíble más barato y su coste es insignificante con volúmenes reales.
• Fallos de recuperación medidos que un codificador más potente arreglaría: text-embedding-3-large, pero solo cuando haya pruebas.
• Recuperación multilingüe o entre idiomas: Cohere Embed v3, evaluado con tus propios datos, ya que aquí la elección del modelo todavía se nota en la experiencia de usuario.
• Documentos que no pueden salir de la red: Nomic Embed o BGE autoalojados. Aquí decide el cumplimiento normativo, no el coste.
• Volumen muy alto de reindexación continua: un modelo local, que saca del diseño los límites de peticiones y la facturación por petición.

Solo dos de esas filas las decide el propio modelo. El resto lo deciden restricciones que existen sea cual sea el modelo que elijas.

Preguntas frecuentes

¿Cuál es el modelo de embeddings más barato en 2026? Entre las opciones alojadas, text-embedding-3-small a $0.02 por millón de tokens está casi en lo más bajo en precio sin dejar de ser creíble. Las opciones locales como Nomic Embed y BGE no tienen ninguna tarifa por token, aunque lo pagas en hardware y mantenimiento. En cualquier caso, las cantidades son lo bastante pequeñas como para que el coste no deba zanjar la cuestión para la mayoría de equipos.

¿Los embeddings deberían venir de OpenAI o de Cohere? Para cargas solo en inglés, decide por motivos operativos, ya que la diferencia de calidad no será lo que limite el producto. Para cargas multilingües o entre idiomas, construye un conjunto de evaluación en los idiomas reales y prueba ambos, porque ahí es donde los usuarios notan la diferencia.

¿Cuánto cuesta volver a generar los embeddings de un corpus grande? En tarifas de API, menos de lo que la mayoría cree: unos dos dólares por cien millones de tokens a $0.02 por millón. Lo que duele es el trabajo que lo rodea, que incluye volver a extraer y fragmentar cada documento, mantener dos índices vivos durante la transición y repetir todas las evaluaciones de recuperación en el nuevo espacio vectorial. Planifica en semanas, no en tokens.

La conclusión: haz la comparación de modelos, pero dedica la preocupación ahorrada a la ruta de migración y no a la lista de precios. Elegir un modelo es una decisión menor de lo que parece. El índice construido a su alrededor es una mucho mayor.