text-embedding-3 de OpenAI: qué cambia respecto al anterior

Actualizado: 2026-05-03

OpenAI liberó text-embedding-3 el 25 de enero de 2024, en dos variantes: text-embedding-3-small (más barato, 1536 dim) y text-embedding-3-large (calidad superior, 3072 dim). Es el primer cambio mayor en embeddings de OpenAI desde text-embedding-ada-002 de diciembre de 2022. Para equipos que construyen RAG sobre OpenAI, la pregunta inmediata es: ¿migrar? Y si sí, ¿cuándo y a qué coste? Este artículo cubre qué aporta, cómo comparar y estrategias para el cambio.

Qué hay de nuevo en cinco puntos

Cambios concretos respecto a ada-002:

• Calidad MTEB: text-embedding-3-large alcanza ~64% en el benchmark multi-tarea (vs 61% de ada-002). 3-small consigue ~62%.
• Dimensiones variables: puedes truncar los embeddings a menos dimensiones sin reentrenar. 3072 → 512 mantiene ~80% de calidad con un tercio del almacenamiento.
• Multilingüe mejorado: 3-large en MIRACL (benchmark multilingüe) sube de 31% a 54% vs ada-002.
• Precio menor para small: $0.02 / 1M tokens frente a $0.10 de ada-002. large es $0.13 / 1M.
• Mejor manejo de documentos largos: el contexto máximo sigue en 8191 tokens, pero mejora en documentos extensos.

El combo “más barato + mejor calidad” es raro; normalmente hay que pagar uno con el otro. Esta es la razón de que la actualización genere tanto interés.

Dimensiones variables: cómo funciona

La técnica se llama Matryoshka Representation Learning: el modelo está entrenado para que los primeros N componentes del vector sean una representación funcional por sí mismos:

from openai import OpenAI
client = OpenAI()

# Generar embedding con dimensiones reducidas directamente en servidor
res = client.embeddings.create(
    input="Texto de ejemplo",
    model="text-embedding-3-small",
    dimensions=512  # trunca server-side
)

# O bien truncar del lado cliente
full = res.data[0].embedding
truncated = full[:512]

Truncar permite tres cosas:

• Índices más pequeños: 3x menos memoria en pgvector, Qdrant o Pinecone.
• Búsquedas más rápidas: menos dimensiones equivale a menos cómputo por query.
• A/B testing fácil: probar 256 vs 512 vs 1536 sin reindexar todo el corpus.

Regla práctica: para RAG en español/inglés, 512 dim es buen punto intermedio. Para multilingüe complejo, 1024 dim.

Migración desde ada-002

El cambio no es plug-and-play si ya tienes embeddings indexados. Tres opciones:

• Reindexar todo: reprocesar el corpus con el nuevo modelo. Para 10M docs de 1KB, ~10B tokens × $0.02/M = $200 con 3-small. El más limpio para la mayoría.
• Migración gradual: mantener ada-002 para docs existentes, 3-small para nuevos, con índices separados y búsqueda sobre ambos. Complica la arquitectura.
• Hybrid search: embeddings nuevos y viejos coexisten por un tiempo, con un re-rank final unificado.

Para la mayoría, reindexar de golpe es más limpio. El coste es manejable y la ganancia de calidad compensa. La clave es medir el recall real antes y después, no solo confiar en los benchmarks públicos.

Comparación con alternativas open source

Dónde queda frente a embeddings abiertos en MTEB:

BGE-large y E5-large están casi a la par con OpenAI en calidad, pero requieren infraestructura propia. El trade-off es el clásico: OpenAI es simple pero dependencia externa; self-hosted es control pero carga operativa. Para quienes ya gestionan Ollama para modelos locales, self-hosted puede ser coherente con la estrategia existente.

Consideraciones de latencia

OpenAI embedding API: ~50-200ms p50, puede llegar a 1s+ en picos. Para batch processing no importa; para queries en tiempo real puede ser problemático.

Estrategias para mitigarlo:

• Cache agresivo: queries similares pueden reutilizar embeddings cacheados. Una buena capa de Redis para caché aquí da retorno rápido.
• Modelo local para la query, OpenAI para docs: la query se embebe con un modelo local rápido; los documentos se indexaron offline con OpenAI. Funciona si el modelo local tiene suficiente calidad.
• Batch embeddings: OpenAI acepta hasta 2048 inputs por llamada — amortizar la latencia de red.

Residencia de datos

OpenAI procesa en US por defecto. Para compliance europeo:

• Azure OpenAI ofrece regiones EU (West Europe, etc.).
• text-embedding-3 está disponible en Azure con el mismo SLA.
• Los precios son similares.

Para empresas europeas reguladas, Azure es la vía; para el resto, OpenAI directo suele ser más ágil. Ver Cohere Embed v3 para la alternativa con residencia EU nativa.

Benchmark propio antes de migrar

No te fíes solo del MTEB. Mide con tu corpus real:

# Golden set: 500 pares query-documento relevante, curados manualmente
for q, expected_doc in golden_set:
    # Ada-002
    old_emb = client.embeddings.create(input=q, model="text-embedding-ada-002")
    old_results = search(old_emb, index_ada)
    old_hits.append(expected_doc in old_results[:10])

    # Embedding-3
    new_emb = client.embeddings.create(input=q, model="text-embedding-3-small")
    new_results = search(new_emb, index_new)
    new_hits.append(expected_doc in new_results[:10])

print(f"ada: {sum(old_hits)/len(old_hits)*100:.1f}%")
print(f"new: {sum(new_hits)/len(new_hits)*100:.1f}%")

500 pares bien seleccionados son más informativos que millones de benchmarks públicos con datasets distintos al tuyo.

Errores comunes al migrar

Lo que vemos romper con más frecuencia:

• Olvidar normalizar: distancia coseno vs producto interno no son siempre intercambiables. OpenAI normaliza los embeddings, pero doblar la normalización por accidente causa problemas sutiles.
• Mezclar modelos en el mismo índice: buscar embeddings de distintos modelos en el mismo índice da resultados basura.
• Dimensiones mal truncadas: [1:N+1] en vez de [:N]. Un off-by-one mata calidad.
• No medir recall real post-migración: solo verificar que la API responde no es suficiente.

Cuándo migrar

Migrar ya si:

• El recall o la precisión son el bottleneck de tu RAG.
• Tienes corpus multilingüe (la ganancia en MIRACL es mayor).
• Volumen alto en ada-002 donde ahorrarías con 3-small.

Esperar si:

• RAG funciona bien con métricas estables.
• Hay cambios inminentes en tu producto que obligarán a reindexar de todos modos.
• Volumen bajo donde el coste de reindexar no se recupera en meses razonables.

Para arquitecturas que usan pgvector como backend vectorial, ver pgvector en 2024 para la perspectiva de indexado con HNSW.

Conclusión

text-embedding-3 es una mejora real y mensurable sobre ada-002. La opción de dimensiones variables es especialmente interesante por su impacto operativo — menor memoria, queries más rápidas, A/B testing más barato. La migración merece la pena para la mayoría de casos RAG serios, aunque hay que presupuestar el reindexado con cuidado. Frente a alternativas open source, la decisión sigue siendo la clásica entre simplicidad managed vs control self-hosted — y ambas son respuestas correctas según el contexto.