¿Más dims siempre es mejor en RAG? Calidad, velocidad y coste
Una vez que entiendes qué son las dimensiones de un embedding, la siguiente pregunta es: ¿más dims dan mejores resultados? La respuesta es "depende" — y este artículo explica exactamente de qué depende.
La pregunta que llega después
Una vez que queda claro que las dims son el tamaño del vector de salida del modelo de embedding, la pregunta siguiente es casi automática: si more dims significa un espacio vectorial más rico para capturar significados, ¿no debería usar siempre el modelo con más dimensiones posibles?
La respuesta corta es no necesariamente. Como casi todo en ingeniería, hay un trade-off. Más dims dan mejor representación semántica, pero a costa de mayor almacenamiento, búsqueda más lenta y mayor coste de ingesta. El punto óptimo depende del tamaño de tu corpus, del presupuesto de latencia y del entorno de ejecución.
La trampa conceptual: más dims no significa que el modelo "sabe más". Significa que usa un espacio de representación más grande. Un modelo con 384 dims bien entrenado puede superar en calidad semántica a un modelo con 768 dims mal entrenado. Las dims y la calidad del entrenamiento son variables independientes.
Los cuatro trade-offs reales
Calidad semántica
Más dims ganaMás dims
El espacio vectorial tiene más "ejes" para separar significados distintos → mejor precisión en búsqueda semántica.
Menos dims
Conceptos similares pueden quedar más cerca de lo deseable → más falsos positivos en la búsqueda.
Velocidad de búsqueda
Menos dims ganaMás dims
Calcular similitud coseno en vectores de 3072 floats es más lento que en 384 floats. El vector store tarda más en comparar.
Menos dims
Búsqueda más rápida. En producción con millones de documentos, la diferencia es notable.
Almacenamiento
Menos dims ganaMás dims
1M documentos × 3072 dims × 4 bytes = ~12 GB solo de vectores. El vector store crece y las operaciones en memoria se encarecen.
Menos dims
1M documentos × 384 dims × 4 bytes = ~1.5 GB. Mucho más manejable en local o en Pinecone/Chroma tier gratuito.
Coste de ingesta
Menos dims ganaMás dims
Modelos más grandes consumen más RAM/GPU y más tiempo por documento durante la fase de indexación.
Menos dims
MiniLM en CPU indexa miles de documentos por minuto. El coste de ingesta inicial es mínimo.
Comparativa práctica por modelo
Los modelos más usados en pipelines RAG con LangChain, ordenados por dims:
| Modelo | Dims | Params | Storage / doc | Velocidad | Mejor para |
|---|---|---|---|---|---|
| all-MiniLM-L12-v2 | 384 | 33M | ~1.5 KB / doc | Muy rápido | Prototipo, CPU, inglés |
| all-mpnet-base-v2 | 768 | 109M | ~3 KB / doc | Moderado | Similitud fina, semántica compleja |
| text-embedding-3-small | 1536 | No público | ~6 KB / doc | API (latencia red) | Producción, multilingüe |
| text-embedding-3-large | 3072 | No público | ~12 KB / doc | API (latencia red) | Alta precisión, corpus técnico denso |
Storage estimado para vectores float32. En Chroma o FAISS en local, añadir metadata e índices puede multiplicar x2–x3 el espacio total.
Señales para elegir dims en la práctica
Estás prototipando o aprendiendo
MiniLM (384 dims) en local, sin API, sin coste. Corre en CPU en segundos.
Corpus técnico en español o con terminología especializada
Sube a 768 dims (mpnet) o usa text-embedding-3-small. Los documentos técnicos densos se benefician de espacios vectoriales más expresivos.
Producción con SLA de latencia < 100 ms
Mide la latencia de búsqueda real con tu tamaño de corpus antes de comprometerte con 3072 dims. Escala solo si la calidad no es suficiente con 1536.
Corpus > 500K documentos en local
El coste de almacenamiento de 3072 dims puede ser prohibitivo sin hardware dedicado. Considera truncar dims con Matryoshka si el modelo lo soporta.
Resumen: cómo pensar en las dims
¿Quieres aplicar esto en tu equipo?
En Kuuli Technologies llevamos estas metodologías a equipos reales. Escríbenos si quieres una sesión de trabajo o una consultoría sobre agentes IA y SDD.