1536 vs 3072 embeddings: comparación para búsqueda en documentos y RAG

Cuando un equipo construye un pipeline RAG y la recuperación devuelve resultados irrelevantes, la reacción típica es: "necesitamos un modelo de embedding más grande". La lógica es clara: más dimensiones → más información → mejor búsqueda. Pero los datos dicen lo contrario.

Este artículo es un análisis técnico para desarrolladores que diseñan RAG bajo restricciones específicas de RAM, costo y calidad. Analizamos cifras: benchmarks MTEB, costos de almacenamiento, latencia, y comparamos alternativas, en particular el reranking, que en la mayoría de los escenarios proporciona un mayor aumento en la calidad de recuperación por un menor costo que cambiar a un modelo de 3072 dimensiones.

Si aún se encuentra en la etapa de elegir un enfoque para el análisis de documentos antes de la vectorización, lea primero los artículos anteriores de la serie: "Cómo el OCR afecta la calidad de los sistemas RAG" y "Vision RAG vs OCR: comparación de enfoques". Datos de entrada deficientes anulan cualquier ventaja de un mejor modelo de embedding.

¿Qué es un vector de embedding y qué significa su dimensionalidad?

Un modelo de embedding convierte texto en un vector numérico, una lista de números de longitud fija. Este vector es la "coordenada" del texto en un espacio semántico n-dimensional. Los textos con significado similar tienen vectores cercanos (alta similitud coseno); los textos con significado diferente están lejos.

La dimensionalidad del vector es la cantidad de números en esta lista. text-embedding-3-small devuelve 1536 números por texto de entrada. text-embedding-3-large, 3072.

¿Qué mide la dimensionalidad?

Importante: la dimensionalidad es una propiedad de la arquitectura del modelo y su entrenamiento, no simplemente "más es mejor". Estudios de sistemas RAG en producción muestran que reducir de 1536 a 384 dimensiones en algunos escenarios no produce una caída medible en la precisión de recuperación, al tiempo que reduce la latencia a la mitad y el almacenamiento en un 75%.

Matryoshka Representation Learning (MRL): usa large, almacena menos

text-embedding-3-large y text-embedding-3-small soportan MRL, un enfoque donde las primeras dimensiones del vector llevan la señal semántica más general, y cada una adicional agrega detalle. Esto permite "recortar" el vector después de la generación sin un reentrenamiento completo del modelo.

En la práctica: generas un vector de 3072 dimensiones a través de la API, pero almacenas solo las primeras 256, 512, 1024 o 1536 dimensiones a través del parámetro dimensions. La calidad no cae proporcionalmente, sino de forma no lineal:

Reducir de 3072 a 1536 dimensiones proporciona un −50% de RAM con una pérdida de solo el 1.6% de calidad. Hasta 1024, un −66% de RAM con un −2.8% de calidad. Este es el compromiso más práctico para la mayoría de los escenarios.

Importante: MRL solo funciona con modelos entrenados explícitamente con esta técnica (text-embedding-3-* de OpenAI, algunos modelos de Cohere y Nomic). El simple "recorte" de un vector de un modelo arbitrario dará lugar a una degradación sin garantías.

Cómo la dimensionalidad afecta la calidad de la búsqueda semántica

La ventaja teórica de una mayor dimensionalidad no siempre se realiza y no de manera uniforme. El impacto depende de tres factores: la naturaleza de los documentos, el tipo de consultas y la presencia de otros componentes del pipeline.

Dónde la dimensionalidad es realmente importante

Dónde la dimensionalidad es casi irrelevante

text-embedding-3-small (1536) vs text-embedding-3-large (3072): diferencias reales

Benchmark MTEB: cifras

MTEB (Massive Text Embedding Benchmark) es un benchmark estándar para comparar modelos de embedding. Para RAG, la métrica más relevante es MTEB Retrieval (nDCG@10).

Fuente: ICLERB Benchmark, MTEB Leaderboard noviembre 2024.

Un aumento del 8.5% en nDCG@10 es una diferencia real, pero es importante entender el contexto: es un benchmark en un conjunto general de tareas. En su corpus específico, la diferencia puede ser mayor o menor. Y por un costo de embedding 6.5 veces mayor, más un costo de almacenamiento 2 veces mayor.

Contexto del mercado: OpenAI ya no es el líder

text-embedding-3-large no se ha actualizado desde enero de 2024. Según el MTEB Leaderboard de abril de 2026, el panorama ha cambiado significativamente:

Qwen3-Embedding-0.6B con 1024 dimensiones (70.70 MTEB) supera a text-embedding-3-large con 3072 dimensiones (66.43 MTEB), con una dimensionalidad menor y total disponibilidad autoalojada. Esto recuerda el mensaje principal del artículo: la dimensionalidad no es igual a la calidad.

Diferencia práctica en tareas reales

Impact on RAM, disk space, and search speed

The cost of storing vectors is linear with dimensionality. Each float32 takes 4 bytes. 1536 dimensions × 4 = 6,144 bytes (~6 KB) per vector. 3072 dimensions is exactly twice as much.

Specific numbers for typical collections

Source: Qdrant documentation; arXiv 2505.00105 — Optimization of embeddings storage for RAG.

Cost of managed vector DB at scale

According to the Vector DB Costs 2026 analysis, one embedding call to text-embedding-3-large generates a 3072-dimensional vector — 10M documents yield 120 GB of raw vector data before indexing. Management costs for Pinecone for 10M vectors with 3072 dimensions are ~$70–120+/month versus $35–65 for 1536 dimensions.

With self-hosted Qdrant: 1M vectors of 1536 dimensions require a minimum 4GB RAM tier (~$36/month on Qdrant Cloud). 3072 dimensions for the same volume require an 8GB RAM tier, ~$72/month.

Search speed (ANN latency)

Practical advice: pgvector and 3072 dimensions

If you are using pgvector, pay attention to an important limitation: GCP PostgreSQL does not allow creating HNSW indexes for vectors with >2000 dimensions. text-embedding-3-large with 3072 dimensions on pgvector in GCP means brute-force search without an index — a catastrophic degradation of latency on collections of 100,000+ chunks. Either reduce to 1536 using the API's dimensions parameter, or switch to Qdrant/Weaviate.

Comparison on typical RAG scenarios: legal documents, technical documentation, FAQ

Scenario 1: Legal documents

Legal texts are a complex case for dense retrieval. They contain both precise numerical values (sums, dates, articles) and subtle semantic differences (responsibility vs. obligation).

Key takeaway for legal documents: the difference between 1536 and 3072 in the dense component is minimal compared to the effect of adding BM25 in a hybrid pipeline. Research on T2-RAGBench financial documents (2026) shows that hybrid + reranker yields Recall@5 = 0.816 versus 0.587 for pure dense retrieval with text-embedding-3-large — a +39% increase without changing the embedding model.

Scenario 2: Technical documentation

Technical documentation (API guides, specifications, RFCs) contains highly specialized terminology. Here, a 3072-dimensional model provides a more noticeable effect — narrow terms are encoded more precisely in a larger space.

However, there's a nuance here too: if the documentation contains exact names (functions, parameters, versions), BM25 or hybrid remains the better option for precise queries. The dense component helps with "how to do X" queries.

Scenario 3: FAQ and helpdesk

FAQ is the simplest scenario for embedding models. Queries and answers are semantically straightforward. For FAQ and helpdesk systems, even a 384-dimensional model provides acceptable quality — the difference between 1536 and 3072 on this data is minimal.

For FAQs, the optimal strategy is to start with text-embedding-3-small or even BGE-small (384 dimensions), measure Recall@5 on a test set of questions, and only if there's a measurable deficit, move to a larger model.

Overall table by scenario

Why model quality is more important than dimensionality

Comparing text-embedding-3-small (1536) and text-embedding-3-large (3072) is a comparison of two products from the same vendor. But the real picture is broader: there are models with lower dimensionality and higher quality.

The already mentioned Qwen3-Embedding-0.6B (1024 dimensions, MTEB 70.70) outperforms text-embedding-3-large (3072 dimensions, MTEB 66.43) on the overall MTEB benchmark with lower dimensionality. Apache 2.0, fully self-hostable.

Factors determining embedding quality beyond dimensionality

The "FAISS Hybrid Paradox": when a larger model is worse

The study "Rethinking Hybrid Retrieval" (2025) revealed a counterintuitive result: MiniLM-v6 (a compact model) consistently outperforms BGE-Large when integrated with LLM-based reranking in tri-modal hybrid retrieval. The difference: up to 23.1% better nDCG@10 and 36.5% better nDCG@1 in the financial domain — with 93% fewer parameters and 63% smaller embeddings.

The reason is the "FAISS Hybrid Paradox": the embedding space of large models may not align with the relevance criteria of an LLM reranker. A larger model creates a more "stretched" space that the LLM reranker re-ranks less effectively than a compact one.

Conclusion: if your pipeline includes a reranker, it's not guaranteed that a larger embedding model will improve results. Test on your data.

Reranking as an alternative to increasing dimensionality

Reranker (or cross-encoder) is the second stage of retrieval. In the first stage, the embedding model finds top-k candidates by cosine similarity (fast, but not precise). In the second stage, the reranker re-ranks these candidates, evaluating each pair (query, document) together (slow, but much more precise).

Why a reranker is more accurate than an embedding

A bi-encoder (embedding model) encodes the query and document *independently*. This allows for fast ANN search, but means the model doesn't "see" the query and document simultaneously during encoding.

A cross-encoder (reranker) encodes the pair (query + document) *together*. Self-attention "sees" both texts simultaneously and can evaluate subtle semantic interactions. This is computationally much more expensive — but also much more precise.

Real numbers: what a reranker provides

Hybrid + reranker yields Recall@5 = 0.816 versus 0.587 for pure dense — a +39% increase without changing the embedding model. For comparison, switching from text-embedding-3-small to large provides ~8.5% improvement on MTEB Retrieval.

Popular reranker solutions

When a reranker is not enough

A reranker only re-ranks what made it into the top-k from the first stage. If a relevant chunk didn't even make it into the top 50 candidates, the reranker won't help. In this case, a better embedding model or hybrid retrieval with a larger k is needed.

Also important: a reranker adds latency (~100–500 ms for 50 candidates). For real-time systems with requirements of <500 ms end-to-end, this can be a limitation.

Lógica de selección matricial: tamaño de la colección × precisión × presupuesto

Algoritmo de toma de decisiones

Preguntas frecuentes: preguntas comunes sobre la dimensionalidad de los embeddings

¿Vale la pena pasar de 1536 a 3072?

Desde mi experiencia, en la mayoría de los casos no, al menos no como primer paso. Pasar de small a large da un aumento de ~8.5% en MTEB Retrieval, pero cuesta 6.5 veces más por API y el doble en almacenamiento. Antes de cambiar el modelo, siempre compruebo primero: si está implementada la recuperación híbrida (BM25 + denso), si hay un reranker. Estos dos componentes juntos dan un +39% en Recall@5, sin cambiar la dimensionalidad en absoluto. Si después de esto persiste el déficit de calidad, entonces sí, pasar a 3072 o a un mejor modelo está justificado.

¿Cuánto aumenta el consumo de RAM?

Exactamente el doble, la dependencia es lineal. 1M de fragmentos con 1536 dimensiones ocupan ~6.1 GB de RAM, con 3072 son ~12.2 GB. Con 10M de fragmentos, ya es la diferencia entre 61 GB y 122 GB, básicamente un nivel de servidor diferente y un presupuesto de infraestructura diferente. Para colecciones pequeñas (hasta 100K fragmentos), la diferencia no es crítica: 600 MB frente a 1.2 GB caben en cualquier instancia moderna. Pero al escalar, se convierte en la primera limitación.

¿Afecta la dimensionalidad a la velocidad de pgvector?

Afecta, y hay una trampa práctica importante. En primer lugar, dimensiones más altas significan más operaciones al calcular la similitud del coseno: la latencia de la consulta aumenta. En segundo lugar, y esto es crítico: GCP PostgreSQL no admite la creación de índices HNSW para vectores de más de 2000 dimensiones. Si usas text-embedding-3-large (3072) con pgvector en GCP, obtienes búsqueda por fuerza bruta sin índice, lo que en colecciones de 100K+ fragmentos provoca una degradación catastrófica de la latencia. Solución: o reduce a 1536 a través del parámetro dimensions en la API, o pasa a Qdrant o Weaviate.

¿Son necesarias 3072 dimensiones para un RAG pequeño?

No. Con una colección de hasta 50K fragmentos, la diferencia entre 1536 y 3072 es prácticamente imperceptible; cualquier modelo encontrará el fragmento correcto en un índice pequeño. Recomiendo empezar con text-embedding-3-small o incluso BGE-small (384 dimensiones), medir el Recall@5 en un conjunto de preguntas de prueba y solo entonces tomar una decisión. La mayoría de los equipos con los que he trabajado han descubierto que el problema no es la dimensionalidad, sino la calidad del texto de entrada o la ausencia de un reranker.

¿Qué es más importante: el modelo o la dimensionalidad?

El modelo es siempre más importante. El mejor ejemplo: Qwen3-Embedding-0.6B con 1024 dimensiones obtiene 70.70 MTEB, mientras que text-embedding-3-large con 3072 dimensiones obtiene 66.43. Menor dimensionalidad, mejor resultado. Desde mi experiencia, el orden de prioridad de optimización de RAG es el siguiente: primero la calidad del texto de entrada, luego la estrategia de chunking, luego la recuperación híbrida y el reranker, y solo después de eso la elección o el cambio del modelo de embedding. La dimensionalidad es la última variable que vale la pena ajustar.

Conclusiones

La elección entre 1536 y 3072 dimensiones no es la decisión principal al diseñar un pipeline RAG. Está mucho más abajo en la prioridad que la calidad de los datos de entrada, la estrategia de chunking y la presencia de recuperación híbrida con reranker.

Conclusiones clave