Calculadora de dimensionamiento y selección de bases de datos vectoriales
La pregunta práctica detrás de una base de datos vectorial autogestionada para RAG es qué motor se ajusta a un servidor dado y cuál descarta la carga de trabajo. La calculadora a continuación responde ambas, a partir de nuestro benchmark de siete bases de datos vectoriales autogestionadas ejecutadas con recall emparejado sobre incrustaciones idénticas.
Métricas de la calculadora explicadas
Cinco casillas de verificación en la parte superior de la calculadora nombran cinco cargas de trabajo comunes de RAG, y cada una se mapea a un límite medido del benchmark en lugar de una afirmación del proveedor. Marcar una filtra la lista de motores contra un número específico. Dejarla sin marcar significa que la carga de trabajo no se aplica y ningún motor se filtra por ella. Lo que cada interruptor pregunta y la medición detrás de él:
Selección y dimensionamiento
Dos decisiones preceden a un índice en ejecución. La primera es la selección, porque algunos motores no pueden realizar una tarea determinada. La calculadora verifica cada motor contra los cinco interruptores de requisitos anteriores y descarta los que fallan. La segunda es el dimensionamiento, es decir, cuáles de los motores supervivientes caben en la caja y con qué margen. Para cada superviviente informa si encaja, ajustado o no encaja, más el número de vectores que el servidor podría albergar. Ninguna decisión depende de la calidad de recuperación, porque los siete motores empatan dentro de una dispersión de 0.014 nDCG frente a un oráculo kNN exacto.
Huella a 2.25M vectores
A 2.25M vectores el benchmark midió dos huellas, divididas por dónde reside el índice. Para los cinco motores en memoria registró el pico de RAM durante la construcción y el servicio, desde 17.0 GB (Milvus) hasta 62.4 GB (Chroma). Para los dos motores en disco registró el índice en disco, 12.0 GB para LanceDB y 18.4 GB para pgvector, lo que cuesta mucho menos por gigabyte. Esas cifras son las mediciones brutas, no las entradas de dimensionamiento de la calculadora. La calculadora dimensiona el servicio en estado estacionario.
Para los motores en memoria, eso queda por debajo del pico de construcción y servicio, y para los motores en disco añade la copia de la tabla y el texto del fragmento sobre el índice medido, de modo que para el mismo corpus de 2.25M sus cifras resultan más bajas en RAM y más altas en disco que las barras aquí. El desglose medido versus modelado a continuación reconcilia ambos. El benchmark completo por motor detrás de la calculadora, que abarca precisión, velocidad, búsqueda filtrada e híbrida, coste de construcción y rotación en vivo, comparación de bases de datos vectoriales de código abierto.
El modelo de dimensionamiento
Las entradas son el tamaño del corpus, el fragmentado y el modelo de incrustación, y la calculadora deriva los dos números que impulsan el dimensionamiento. El tamaño del corpus y el fragmentado dan el recuento de vectores. Un corpus de 2 GB (decimal, 2 mil millones de bytes) a 4 bytes por token son 500M tokens, y fragmentos de 512 tokens con un 15% de solapamiento avanzan un paso de 512 × 0.85 = 435.2 tokens, por lo que el recuento es round(500M ÷ 435.2) = 1,148,897 vectores. El modelo de incrustación da la dimensión, de modo que la entrada es una elección de modelo, no un número bruto, y bge-m3 la establece en 1024.
La huella de cada motor es entonces un coste por vector multiplicado por el recuento de vectores, más un suelo fijo de proceso: footprint = base_gb + bytes_per_vector × N. El coste por vector es donde divergen los motores, porque una base de datos vectorial almacena más que el vector bruto. También guarda el grafo del índice que acelera la búsqueda y, para un RAG real, el texto del fragmento que debe devolver. La tabla siguiente es el coste por vector que produce la disposición de almacenamiento de cada motor a 1024 dimensiones en float32.
Dos hechos de disposición producen la mayor parte de la separación. Redis mantiene una segunda copia de cada vector (un hash fuente más una copia en el índice) y no puede descargar el texto del fragmento, por lo que es el más pesado en RAM. pgvector almacena cada vector dos veces en disco también, una vez en el montón de la tabla y otra dentro del índice HNSW, y su índice redondea a páginas de 8 KB de Postgres, de modo que un vector float32 de 1024 dimensiones llena una página completa por sí solo. Los otros cuatro motores en memoria descargan el texto del fragmento a disco, por lo que su coste en RAM es el vector más un grafo pequeño. El interruptor Almacenar texto del fragmento controla esa carga útil, aproximadamente 2 KB por vector a 512 tokens. Redis lo mantiene en RAM, todos los demás motores lo mantienen en disco, y desactivar el interruptor lo elimina en todas partes.
El suelo de proceso se añade una vez por motor: 2.0 GB para Milvus, 0.5 para Weaviate, 0.3 para Chroma, 0.2 para Qdrant, 0.05 para Redis, y 0 para los dos motores en disco. Reuniéndolo para el corpus predeterminado de 2 GB (1.15M vectores) en un servidor de 16 GB, 200 GB, Qdrant necesita 5.1 GB de RAM, Milvus y Weaviate 6.9 GB, Redis 12.5 GB, mientras que pgvector necesita 16.5 GB de disco y LanceDB 8.5 GB.
El veredicto compara esa huella con la caja en el recurso vinculante, y la línea del 80% es margen deliberado. En o por debajo del 80% de RAM o disco se lee como encaja, lo que deja aproximadamente una quinta parte de la caja para la caché de páginas del sistema operativo, los búferes de consulta y el crecimiento. Del 80 al 100% es ajustado, y más no encaja. La cifra es de servicio en estado estacionario, por lo que construir o reconstruir el índice en la misma caja necesita más RAM durante ese tiempo, más cercana al pico medido. Ejecutar la misma fórmula hacia atrás da la capacidad, (box − base) ÷ bytes_per_vector: el mismo servidor de 16 GB aloja nominalmente 1.47M vectores en Redis, 3.7M en Qdrant y, en su disco de 200 GB, 14.0M en pgvector y 27.1M en LanceDB, cada uno dentro de la banda de error que la herramienta muestra junto a él en lugar de una línea fija. Activar la cuantización divide la parte del vector (int8 por 4x, cuantización de producto por 16x, binaria por 32x) para los motores que lo admiten, y cambiar el modelo de incrustación reescala cada número a través de la dimensión.
Medido versus modelado
La calculadora separa lo que el benchmark midió de lo que modela, ya que ambos conllevan diferente confianza. Las cifras de RAM que el benchmark registró son un pico de construcción y servicio, que es aproximadamente dos o tres veces mayor que el servicio en estado estacionario, y para Weaviate se infló por un límite de memoria Go alto. La calculadora no dimensiona a partir de ese pico. Dimensiona los cinco motores en memoria a partir de la fórmula de servicio documentada de cada proveedor, los costes aditivos de vector más grafo de la tabla, y mantiene el pico medido como comprobación de límite superior. Así, la medición registra lo que el benchmark observó, mientras que el dimensionamiento queda por debajo a propósito.
Los dos motores en disco son lo contrario. Su índice en disco se midió directamente y se mantuvo dentro del 1 al 2 por ciento en un corpus reservado, por lo que la calculadora los dimensiona a partir de la medición. Cada capacidad lleva una banda de error visible que refleja esta división: 25 a 30 por ciento para las estimaciones modeladas de servicio en memoria, 15 por ciento para pgvector, y 1 a 2 por ciento para el disco medido de LanceDB. Dos entradas se etiquetan como suposiciones en lugar de mediciones. La caché de RAM para los motores en disco se fija en el 25 por ciento del índice y es editable, porque su RAM de servicio nunca se midió, y las relaciones de cuantización provienen de la literatura en lugar de este benchmark, por lo que la pérdida de recall real varía con los datos.
La puerta de capacidades
La mitad de selección de la calculadora es un conjunto de hechos binarios, no una puntuación. La tabla siguiente es el lado por motor de los interruptores anteriores. Para cada motor, muestra las cargas de trabajo que lo descartan y las que aún realiza pero a una tasa señalada. Milvus y Weaviate no presentan eliminación en ningún interruptor, razón por la cual se leen como los generalistas limpios.
Redis está señalado en lugar de eliminado en durabilidad porque puede hacerse a prueba de fallos con un archivo de solo añadir. Se benchmarkeó con persistencia desactivada, por lo que la señal indica que el límite es nuestra configuración, no el motor.
Añadir como fuente preferidaMetodología del benchmark
Los números provienen de un benchmark en un solo servidor de los siete motores, cada uno ejecutándose por separado en un contenedor Docker anclado en un Hetzner CCX53 (32 vCPU, 128 GB RAM, NVMe). Cada motor indexó los mismos vectores bge-m3 (1024-dim, coseno sobre float32 normalizado L2) y se leyó con un Recall@10 emparejado de 0.95 alcanzado barriendo su ef o nprobe, con k=10 y semilla 42. Los corpora fueron MedRAG-50k y TechQA-28k para calidad y un nivel MedRAG de 2.25M vectores para escala. Las estadísticas completas, los intervalos de confianza y las versiones por motor están en el artículo del benchmark.
Limitaciones
Las cifras de servicio en memoria son fórmulas de proveedor calibradas contra un pico de construcción y servicio, no una medición directa de servicio, por lo que conllevan la banda del 25 al 30 por ciento que muestra la calculadora. La RAM de servicio para pgvector y LanceDB es una suposición de caché no medida, razón por la cual la calculadora dimensiona esos dos en disco. Las formas de despliegue también difieren por diseño. LanceDB es una biblioteca embebida, pgvector es una extensión de PostgreSQL, los otros cinco son servidores independientes, y Redis se ejecutó con persistencia desactivada, de modo que la huella y las tasas de cada motor reflejan su propia forma operativa en lugar de una configuración idéntica. El benchmark utilizó un modelo de incrustación a 1024 dimensiones, por lo que un modelo diferente o un recuento de dimensiones distinto desplaza cada huella, razón por la cual el modelo es una entrada en lugar de un número fijo. Los motores gestionados y alojados en la nube son una comparación separada.
Conclusión
Para una base de datos vectorial autogestionada en RAG, la elección es un problema de dimensionamiento y selección más que de precisión, ya que los siete motores se sitúan dentro de 0.014 nDCG entre sí. La calculadora convierte las matemáticas de la huella y los límites de carga de trabajo medidos en una respuesta para un servidor específico en lugar de una tabla de clasificación. En una caja de 16 GB a 1024 dimensiones aloja 1.5M vectores en Redis hasta 3.7M en Qdrant en RAM, y de 14M a 27M en los motores en disco, y al activar una carga de trabajo con alta rotación se descartan Chroma y LanceDB mientras se deja libres a Milvus y Weaviate. El benchmark medido detrás de cada uno de esos números es la comparación de bases de datos vectoriales de código abierto.
Lecturas adicionales
- Benchmark de modelos de incrustación
- Benchmark de rerankers
- Base de datos vectorial para RAG
- Modelos de incrustación de código abierto
- Modelos de incrustación multilingües
- Incrustaciones multimodales
- Frameworks de RAG agéntico
Cita este benchmark
Elige el formato que se ajuste al lugar donde vas a publicar. Pegar la versión con enlace en tu CMS conserva el enlace de retroceso.
@misc{sari2026,
author = {Sarı, Ekrem},
title = {{Calculadora de dimensionamiento y selección de bases de datos vectoriales}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/vector-database-for-rag}},
note = {AIMultiple. Recuperado el 20 de Julio de 2026}
}Siguiente para leer
Comparativa de Recuperación ante Desastres: Acronis vs Comet vs MSP360
Benchmark de software de archivado de correo electrónico
Índice de precios de alquiler de GPU en la nube
Sé el primero en comentar
Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios. Los comentarios se dejan en su idioma original.