Cuando se construye RAG o búsqueda semántica, los embeddings suelen ser la primera pieza que se externaliza: el texto se envía a una API gestionada, se recibe el vector y se guarda en una base vectorial. Es rápido para empezar, pero cuando el volumen crece, el cumplimiento se vuelve más estricto o la factura resulta impredecible, los equipos empiezan a buscar alternativas.

Hay tres rutas habituales: la API de embeddings gestionada, el despliegue propio de modelos de pesos abiertos y la vectorización integrada en la base vectorial. Ninguna es mejor en abstracto; las diferencias se concentran en cinco aspectos: dimensiones e idioma, latencia, privacidad, costo y operación.

Este artículo desglosa esas cinco dimensiones, ofrece una tabla de selección por escenario y una lista de migración. Los modelos, dimensiones y precios concretos deben consultarse en la documentación oficial de cada proveedor y en los precios de los modelos del sitio.

Nota: OpenAI, Azure, Cohere, Pinecone, Qdrant, Milvus, Weaviate, BAAI y Qwen son marcas de sus respectivos titulares. Este artículo solo compara rutas técnicas y no implica relación de colaboración ni autorización alguna. Las especificaciones y los límites de interfaz pueden cambiar según la versión; prevalece la documentación oficial.

1. Primero, distinguir las tres rutas

API de embeddings gestionada. Incluye la conexión directa con el proveedor del modelo, los servicios de modelos de las plataformas cloud y las pasarelas compatibles con OpenAI. La ventaja es que no hay que operar infraestructura, se paga por uso y el cambio es rápido; la desventaja es que el texto sale de la red propia y el costo crece con el número de llamadas.

Modelos de pesos abiertos. Por ejemplo, BGE-M3, Qwen3-Embedding, EmbeddingGemma, multilingual-e5 y la familia jina. Los pesos se pueden descargar y desplegar en servidores propios o en una nube privada. La ventaja es que los datos no salen de la intranet; la desventaja es que hay que preparar recursos de inferencia y encargarse de versiones, escalado y monitoreo.

Vectorización integrada en la base vectorial. Pertenecen a esta categoría el integrated embedding de Pinecone, el vectorizer de Weaviate, FastEmbed de Qdrant y la embedding function de Milvus. Al escribir se envía directamente el texto y la base de datos, o el modelo que esta invoca, genera el vector, con lo que se ahorra una capa de código de unión. Sin embargo, vectorización integrada no siempre significa inferencia local: muchas implementaciones siguen llamando a un servicio de modelos externo. pgvector solo se encarga del almacenamiento y la recuperación; no genera vectores.

2. Dimensiones: más no siempre es mejor

La dimensión determina la capacidad de representación y también, de forma directa, el costo de almacenamiento y recuperación. Algunos ejemplos habituales: text-embedding-3-small de OpenAI usa 1536 dimensiones por defecto y 3-large, 3072; BGE-M3 tiene 1024; las variantes 0.6B, 4B y 8B de Qwen3-Embedding corresponden a 1024, 2560 y 4096 dimensiones; EmbeddingGemma usa 768 por defecto y puede truncarse a 512, 256 o 128. Son solo ejemplos; prevalece la documentación oficial.

El almacenamiento se puede estimar de forma aproximada: número de vectores × dimensión × bytes por número en coma flotante. Un millón de vectores de 1024 dimensiones en float32 ocupa unos 4 GB de datos brutos; con 3072 dimensiones, unos 12 GB, sin contar índices, réplicas ni metadatos.

# Estimación del espacio bruto de los vectores, sin índice, réplicas ni metadatos
chunks = 1_000_000
for dim in (768, 1024, 1536, 3072):
    gb = chunks * dim * 4 / 1024**3
    print(f"{dim} dimensiones: {gb:.1f} GB")

Lo esencial es que la dimensión y el modelo van unidos. Los vectores generados por modelos distintos o con valores diferentes del parámetro dimensions no se pueden mezclar en el mismo índice; al cambiar de modelo hay que recalcular todo, no rellenar con ceros ni truncar para igualar la longitud.

3. Cobertura de idiomas: el español y los idiomas mixtos exigen pruebas propias

Muchos modelos afirman cubrir cientos de idiomas, pero "soportar" no equivale a obtener buenos resultados con tu corpus. El español, los textos mixtos español-inglés, el ruso, los códigos de producto, las abreviaturas y las faltas de ortografía afectan la recuperación.

Al elegir, no basta con mirar rankings públicos: conviene montar una evaluación pequeña con preguntas reales de usuarios, fragmentos reales de documentos y casos difíciles (paráfrasis, consultas en otro idioma, cláusulas con numeración). Como mínimo, mide recall@k y MRR, y después revisa si el orden coincide con lo que espera el negocio. Todos estos modelos destacan sus capacidades multilingües, pero la decisión final debe basarse en tus propios datos.

También importa la eficiencia de la tokenización. Con el mismo límite de 8192 tokens, la cantidad de caracteres que caben en español, inglés o código varía. Es más seguro fragmentar dejando margen en tokens.

4. Latencia y rendimiento: mirar el p95, no la media

La latencia de una API gestionada se compone de ida y vuelta de red, cola e inferencia. Las llamadas entre regiones, la variación de la red y las colas en hora punta hacen que el p95 sea superior al p50. Las solicitudes por lotes diluyen el costo, pero alargan el tiempo de respuesta individual, así que encajan mejor en la carga offline.

En un despliegue propio, la latencia proviene sobre todo de la cola de inferencia y del procesamiento por lotes. Los modelos pequeños pueden ejecutarse en CPU, aunque con rendimiento limitado; los grandes necesitan GPU y obligan a considerar memoria de video, concurrencia y arranque en frío. Cuando no hay equipo de operaciones, esta parte del costo suele subestimarse.

La vectorización integrada en la base añade un eslabón a la cadena: tanto la escritura como la consulta esperan la respuesta del modelo. Ahorra complejidad de código, no necesariamente latencia. Conviene medir por separado el rendimiento de ingesta y el p95 de consulta.

5. Privacidad y cumplimiento: adónde va el texto

Una API gestionada implica que el texto sale de la red propia. Hay que confirmar si los datos se usan para entrenar, cuánto tiempo se conservan, en qué región residen y si se ofrece un acuerdo de datos empresarial. Cuando hay datos personales, contratos o información financiera, primero se pasa por una evaluación de cumplimiento.

El despliegue propio de modelos abiertos mantiene el texto dentro de la VPC, pero no equivale automáticamente a cumplimiento: la licencia del modelo, los registros, las copias de seguridad y el control de acceso corren por cuenta del equipo. Con la vectorización integrada hay que revisar qué modelo se invoca por debajo y a qué región viajan las solicitudes.

El vector en sí también puede filtrar información. Un embedding no es cifrado, y un atacante puede hacer inferencias por similitud. Las etiquetas de permisos, el aislamiento por inquilino y los registros de acceso deben tratarse con el mismo rigor que el texto original.

6. Estructura de costos: el precio unitario es solo una partida

Al comparar opciones, no basta con mirar la tarifa por millón de tokens. El costo completo incluye al menos:

  • Tokens de ingesta: vectorización inicial de documentos y actualizaciones incrementales.
  • Tokens de consulta: cada pregunta debe vectorizarse de nuevo.
  • Recálculo y migración: reprocesar toda la base al cambiar de modelo o de regla de fragmentación, además de la escritura doble, el desvío de tráfico y la reversión.
  • Almacenamiento y memoria: vectores, índices, réplicas y metadatos.
  • Inferencia y operación: GPU, CPU, electricidad, despliegue, actualizaciones y monitoreo en el caso del despliegue propio.

El costo de recálculo es el que más se subestima. Un reprocesamiento completo puede durar horas o incluso días. Las tarifas concretas deben consultarse en los precios de los modelos; los precios cambian según el proveedor y la versión, por lo que este artículo no fija cifras.

7. Elegir la ruta según el escenario

Escenario Ruta prioritaria Motivo Qué vigilar
Equipo pequeño que valida rápido API gestionada Sin operación y pago por uso Registrar modelo, dimensión y versión de fragmentación
Datos que no pueden salir de la intranet Despliegue propio abierto El texto permanece en la VPC Evaluar GPU, licencia y copias de seguridad
Base vectorial ya en uso y volumen bajo Vectorización integrada Una capa menos de código Confirmar el modelo subyacente y la región de las solicitudes
Ingesta offline masiva y costo sensible Despliegue propio o API por lotes El procesamiento por lotes diluye el costo Evaluar recuperación antes de procesar todo
Atención al cliente multilingüe y comercio transfronterizo Modelo gestionado multilingüe o familia BGE-M3 Amplia cobertura de idiomas Validar los idiomas minoritarios con corpus real
Consultas en línea sensibles a la latencia API gestionada cercana o modelo local pequeño Menos ida y vuelta de red Mirar el p95, no solo la media
Recuperación híbrida densa y dispersa Modelo abierto con múltiples salidas Una inferencia produce varios vectores El índice y la puntuación se complican

Esta tabla es solo un punto de partida. La elección real depende de la infraestructura existente: si ya se usa una nube, conviene mirar primero sus servicios de modelos; si ya hay un clúster de GPU, el costo marginal del despliegue propio es menor; si ya hay una base vectorial, la vectorización integrada ahorra tiempo de ingeniería.

8. Lista de migración

  1. Inventariar el estado actual: nombre del modelo, dimensión, métrica de distancia, reglas de fragmentación, parámetros del índice y llamadas diarias.
  2. Construir un conjunto de evaluación con cientos de preguntas reales y sus documentos correctos, y usarlo como regresión fija.
  3. Elegir dos o tres candidatos y no cambiar demasiadas variables a la vez.
  4. Hacer escritura doble con poco tráfico: guardar vectores nuevos y antiguos, consultar el índice nuevo y registrar las diferencias de recuperación.
  5. Verificar dimensión, normalización y métrica de distancia; confirmar que coseno, producto escalar y configuración del índice son coherentes.
  6. Crear una colección nueva y recalcular todo; no mezclar vectores de dimensiones distintas en el índice antiguo.
  7. Desviar el tráfico por porcentajes, conservar el índice antiguo y un interruptor de reversión, y observar al menos un ciclo de negocio.
  8. Archivar versión del modelo, dimensión, versión de fragmentación y fecha de recálculo en el diccionario de datos.

El fallo más común en una migración no es la mala calidad, sino la incoherencia en dimensión, normalización o métrica de distancia. Primero se alinean los detalles de ingeniería y después se habla de resultados.

Preguntas frecuentes

¿Se puede sustituir por completo una API de embeddings con modelos abiertos?

En la mayoría de los casos sí, sobre todo en equipos con datos sensibles o volumen estable de llamadas. Pero hay que mantener el servicio de inferencia, hacer evaluaciones de modelos y asumir las actualizaciones de versión. En una fase de validación rápida, una API gestionada requiere menos esfuerzo.

¿Qué diferencia hay entre la vectorización integrada en la base vectorial y llamar directamente a la API?

La vectorización integrada incorpora la generación del vector al flujo de escritura de la base, lo que reduce el código, pero por debajo suele seguir llamando a un servicio de modelos externo. No resuelve por sí sola los problemas de privacidad ni de costo; antes de contratar hay que confirmar el origen del modelo, la región y la facturación.

¿Hay que recalcular todo al cambiar de modelo de embeddings?

Sí. Los espacios vectoriales de modelos distintos no son compatibles, y mezclarlos vuelve poco fiables los resultados de recuperación. Que la dimensión coincida no significa que se puedan mezclar. Antes del recálculo completo conviene hacer una evaluación a pequeña escala.

¿A mayor dimensión, mejor resultado?

No necesariamente. Una dimensión mayor refuerza la capacidad de representación, pero también aumenta el costo de almacenamiento y recuperación. Muchos modelos admiten truncamiento Matryoshka, que permite equilibrar calidad y costo, aunque después del truncamiento hay que volver a evaluar.

¿Qué GPU necesita un despliegue propio de embeddings?

Depende del tamaño del modelo, el lote, el objetivo de latencia y la concurrencia. Los modelos pequeños pueden atender escenarios de QPS bajo en CPU; los grandes suelen requerir GPU y procesamiento por lotes. Primero se hace una prueba de carga con tráfico real y después se decide la configuración.

Siguiente paso

Si se quiere validar primero el resultado con una opción gestionada, se puede crear una clave de prueba en ZSQH AI Gateway, ejecutar la ingesta y la consulta con una interfaz compatible con OpenAI y, después, decidir si conviene un despliegue propio. La disponibilidad de modelos y los precios figuran en los precios de los modelos.

Lecturas relacionadas: