Benchmark de bases de datos vectoriales: 7 motores de código abierto para RAG

Evaluamos siete bases de datos vectoriales de código abierto y autogestionadas como capa de recuperación de un pipeline de RAG, cada una ejecutada una a la vez sobre los mismos embeddings bge-m3 y consultas médicas y técnicas reales, de modo que el índice de la base de datos fuera la única variable. La carga de trabajo abarcó MedRAG-50k, TechQA-28k y un corpus de 2.25M vectores en ocho dimensiones, desde la exactitud y la calidad de recuperación hasta la velocidad, la memoria, la búsqueda filtrada e híbrida, el coste de construcción y la rotación en vivo.

Velocidad de un solo hilo

Cada motor se evalúa en el mismo nivel de recall, el punto de operación común donde su parámetro de búsqueda (ya sea ef o nprobe) se ajusta hasta alcanzar una Recall@10 de 0.95, lo que permite una comparación justa de las cifras de velocidad.

En un solo hilo de cliente, Redis sirve 764 QPS en MedRAG-50k con 559 MB de RAM pico, el mayor rendimiento y la menor memoria del conjunto. El orden en un solo hilo es Redis 764, Qdrant 377, Milvus 342, Weaviate 341, pgvector 257, Chroma 197, LanceDB 70, una diferencia de 10x de arriba a abajo. LanceDB es el caso atípico en disco, ya que cambia RAM por latencia con un p95 cercano a 22 ms. Redis sigue siendo el más rápido y LanceDB el más lento en TechQA-28k (651 a 81) y en 2.25M (495 a 28), aunque el grupo intermedio se reordena a escala, donde Milvus cae del tercero al sexto.

Para RAG, la latencia de cola condiciona la experiencia del usuario más que el rendimiento bruto. La latencia por consulta, agregada en 100 ejecuciones de 154 consultas con recall coincidente, sigue el orden del rendimiento.

Redis se ejecutó con persistencia desactivada (sin instantánea RDB ni archivo de solo adjuntar), por lo que sus cifras de velocidad y memoria corresponden a una configuración volátil y sin durabilidad.

Rendimiento bajo concurrencia

El QPS de un solo hilo responde qué tan rápida es una consulta. La pregunta de producción es el rendimiento bajo muchos clientes concurrentes, y la respuesta depende de cómo esté construido el cliente, no solo de la base de datos.

Un cliente de bucle cerrado puede manejarse de dos maneras, y ambas son comunes en aplicaciones Python de RAG. Un solo proceso asíncrono o con hilos deserializa cada resultado concurrente (gRPC/protobuf o RESP) bajo un solo GIL, por lo que el cliente, no el servidor, limita el rendimiento. Muchos procesos trabajadores (el patrón gunicorn -w N) obtienen cada uno su propio GIL, lo que expone mucha más capacidad del servidor. Medimos ambos en una caja de 32 vCPU con ef=128 y verificamos cada punto con recall.

A medida que la concurrencia de solicitudes aumenta de 1 a 512 en hasta 32 procesos trabajadores, las líneas de rendimiento se cruzan. Redis comienza más alto con una solicitud y termina más bajo, mientras que Weaviate sube desde la parte inferior del grupo hasta una meseta de 8330 QPS con 512 solicitudes, pasando por 7.114 en el camino con 32. En un solo proceso asíncrono, la clasificación sigue más bien la eficiencia de análisis del cliente Python, ya que el RESP de Redis es el más ligero de deserializar y pierde lo mínimo frente al GIL.

El pico de un solo proceso de cada motor y el pico de 32 procesos son los techos en todo el barrido de 1 a 512, no el rendimiento en un recuento de solicitudes concreto.

Redis mantiene la latencia de consulta individual más baja del conjunto (alrededor de 1.6 ms), y su núcleo de búsqueda de un solo hilo se satura alrededor de 1642 QPS con 32 solicitudes concurrentes, y luego antiescala más allá de eso (el pool de hilos de consulta WORKERS de RediSearch está desactivado por defecto). Weaviate y Milvus (servidores multihilo) y pgvector (un backend Postgres independiente por conexión) escalan en los 32 núcleos. pgvector tiene el pico de un solo proceso más bajo (536) y el segundo pico de 32 procesos más alto (4832). Bajo un presupuesto de p99 inferior a 100ms, el orden multiproceso es Weaviate 8290, pgvector 4828, Milvus 4725, Qdrant 1737, Redis 1642.

El análisis gRPC más pesado de Qdrant hace que su cifra co-ubicada esté limitada por el cliente y no por el servidor, ya que solo el número de procesos la lleva de 455 QPS en un proceso a 1859 en 32. Chroma y LanceDB quedaron fuera de la ejecución multiproceso. Chroma fija ef en la creación de la colección y antiescala, con un p99 de 13 segundos con 512 solicitudes, y LanceDB está integrado, por lo que el escenario de cliente de red no aplica.

Huella de memoria

Con 50k vectores, la RAM pico va desde 559 MB (Redis, en RAM, persistencia desactivada) hasta 3.300 MB (Milvus), con Weaviate en 1.201, LanceDB en 1.574, Chroma en 1.800 y pgvector en 2.024. La clasificación cambia con 2.25M, donde se abre la compensación entre memoria y disco.

El pico de RAM con 2.25M, en los cinco motores en memoria, va desde 17.0 GB (Milvus) hasta 62.4 GB (Chroma), un rango de 3.7x, o de 7.5 GB a 27.7 GB por millón de vectores. Milvus sigue siendo el más ligero porque descarga el índice en disco (estilo DiskANN), mientras que los motores HNSW todos en RAM crecen más rápido, de modo que Milvus, el más pesado con 50k (3.300 MB), es el más ligero con 2.25M (17.0 GB), y Chroma el más pesado con 62.4 GB.

Los dos motores en disco quedan fuera de esta comparación de RAM porque su huella es de disco y no de RAM. pgvector mantiene un índice en disco de 18.4 GB y LanceDB uno de 12.0 GB con 2.25M, y su RAM de servicio es una caché de páginas sobre ese índice, no el conjunto de trabajo completo, que no se midió. Una advertencia también afecta a las cifras en memoria. Son una marca máxima de construcción y servicio, no una huella solo de servicio, por lo que una nueva medición solo de servicio es un refinamiento pendiente.

Frescura, escrituras y eliminaciones bajo rotación en vivo

Las otras siete dimensiones miden un corpus de carga masiva estática y luego lectura. Las bases de conocimiento reales de RAG añaden, actualizan y eliminan documentos continuamente mientras el índice se fusiona en segundo plano. Esta carga de rotación se ejecutó en MedRAG-50k en una caja separada de 8 vCPU, por lo que su rendimiento es interno a esta sección y no es comparable con las cifras de velocidad de 32 núcleos. Las señales de corrección (comprobaciones de recall y tombstone) son independientes del hardware.

Frescura (lectura tras escritura). Con el ajuste de consistencia con el que se configuró cada motor, todos son de lectura tras escritura. Un documento recién escrito se puede buscar inmediatamente, con cero escrituras no visibles de unas 150. La latencia de confirmación de escritura a visibilidad en búsqueda es de 2 ms p50 para Redis, 4 ms para Weaviate, 9 ms para Qdrant, 12 ms para Milvus, 14 ms para pgvector, 31 ms para LanceDB y 41 ms para Chroma. Milvus encuentra la nueva fila mediante un escaneo de consistencia fuerte del segmento creciente aún no sellado (el vector entra en el grafo HNSW persistente más tarde), por lo que sus 12 ms son capacidad de búsqueda del segmento creciente, una lectura tras escritura válida de cara al usuario.

Escrituras y lecturas bajo carga mixta. Con un escritor apuntando a 150 escrituras/s y seis lectores consultando durante 60 segundos, el recall de lectura se mantuvo entre 0.96 y 1.00 para todos los motores, y ningún índice se degradó bajo escrituras concurrentes. El rendimiento de escritura de una sola fila separa los motores por 57x, y el orden se acerca al inverso de la clasificación de construcción estática.

LanceDB paga una confirmación de copia en escritura por fila y Chroma una adición HTTP por fila, por lo que los constructores estáticos más rápidos son los más lentos bajo rotación. El rendimiento de escritura aquí es la tasa lograda contra un objetivo de 150/s bajo lecturas concurrentes, de modo que los motores rápidos se limitan cerca de 150 en lugar de mostrar su pico. Léase como comportamiento de escritura en línea de una sola fila y alta frecuencia, no como ingesta por lotes, que es el punto de diseño de estos motores y no se probó aquí.

Eliminación y compactación. Al eliminar un 20 % aleatorio del conjunto activo y reinsertar 20 % de documentos nuevos, la fuga de tombstone fue cero para todos los motores. Un id eliminado nunca reapareció en la búsqueda, y Recall@10 se mantuvo entre 0.97 y 1.00 tras el ciclo completo. La corrección se mantiene bajo rotación en todas partes. El coste difiere según el motor. pgvector paga un VACUUM de 53 segundos y Milvus una compactación de 11 segundos, mientras que la reinserción de los motores de escritura lenta domina (Chroma 276 s, LanceDB 1139 s para unos 6.000 documentos).

Weaviate ejecutó esta sección con 3.000 documentos iniciales en lugar de 30.000 (su ingesta masiva síncrona es lenta en la caja pequeña), por lo que su QPS de lectura se da en un corpus menor. A esa escala, su frescura corregida es de unos 5 ms y su tasa de escritura de unos 102/s, lo que coloca ambos a mitad del grupo.

Métricas explicadas

ANN Recall@10 es la fracción de los 10 verdaderos vecinos más cercanos (según un oráculo kNN exacto de fuerza bruta sobre los mismos embeddings que indexó la base de datos) que devolvió el índice aproximado. Aísla la base de datos (tipo de índice, ef/nprobe, implementación), no el embedding.

nDCG@10 es una puntuación ponderada por posición de 0 a 1 sobre si el documento correcto etiquetado por humanos queda cerca del principio de la lista de resultados. Mide la relevancia de recuperación de extremo a extremo, que es en gran medida una propiedad del model de embedding, mantenido constante aquí en todos los motores.

Δ (puente delta) es el nDCG@10 del oráculo menos el nDCG@10 de la base de datos en un ajuste de búsqueda dado. Convierte el error de aproximación de cada motor en la calidad de respuesta que cuesta su velocidad, algo que se puede informar porque disponemos tanto de un oráculo como de etiquetas humanas.

Hallazgos del benchmark de bases de datos vectoriales

Los siete motores empatan en exactitud de recuperación

Con Recall@10 = 0.95 en MedRAG-50k, nDCG@10 se sitúa entre 0.803 (pgvector) y 0.817 (LanceDB), una diferencia de 0.014. El puente delta al oráculo va de 0.009 (LanceDB) a 0.023 (pgvector), por lo que la aproximación de la base de datos cuesta como máximo 0.023 puntos de nDCG de calidad de respuesta.

Bajo este embedding, corpus, punto de operación k=10 y 0.95, la elección de base de datos mueve nDCG@10 como máximo 0.014, frente a la diferencia de 10x en rendimiento de un solo hilo y la diferencia de 3.7x en memoria pico mostradas arriba. La elección de índice empieza a mover la calidad con Recall@10 = 0.99 o superior, con k mayor, con corpus mucho más grandes o con índices cuantizados.

La fiabilidad de la recuperación varía más por lo que pide una consulta que por qué base de datos la responde. En las 154 consultas de MedRAG con el oráculo kNN exacto, las búsquedas de tipo factoid obtienen 0.888 nDCG@10, las preguntas condicionales 0.836, las comparativas 0.779 y las de existencia de cláusula 0.763. La brecha de 0.125 entre factoid y existencia de cláusula está presente de forma idéntica en los siete motores.

Los filtros de metadatos cuestan rendimiento, no recall

Con un predicado de metadatos aplicado, el Recall@10 en el peor caso se mantiene entre 0.968 (Redis) y 1.00 (Weaviate, pgvector, LanceDB) en una cuadrícula de selectividad (1/5/20/50 %) y correlación de predicados (dispersa y agrupada). La separación está en el rendimiento filtrado.

La separación es el rendimiento. Chroma (11-19 QPS) y pgvector (10-56 QPS) mantienen el recall con un rendimiento filtrado de 20 a 40x más bajo que el resto. Milvus mantiene el recall más alto en el peor caso (0.984) con 268 a 732 QPS en toda la selectividad, mientras que Redis es el más rápido con selectividad baja (1.374 QPS al 1 %) con un piso de recall más bajo (0.968). Con selectividad del 1-5 %, un recall de 1.00 corresponde en gran medida a la rama de escaneo completo exacto del planificador de consultas por debajo del umbral de escaneo completo de cada motor, no a HNSW filtrable, según se declara por motor.

*El recall filtrado de LanceDB se midió primero en 0.24 con filtros agrupados y luego se retiró. El barrido varió ef, pero el control de recall de LanceDB es nprobes, por lo que se ejecutó con un valor predeterminado de aproximadamente 9 % de las particiones. Al volver a medir con nprobes adecuado, el Recall@10 agrupado se recupera de 0.24 a 0.76 (nprobes=128) y a aproximadamente 1.00 (nprobes=256), con un QPS de 3 a 5x más bajo. LanceDB mantiene el recall filtrado, lentamente. Aún está pendiente una remedición del rendimiento filtrado en el mismo host y con recall coincidente, por lo que el QPS filtrado de LanceDB no se lista.

La búsqueda híbrida añade hasta 0.067 nDCG

Añadir un brazo estándar de palabras clave BM25 y fusionarlo con el brazo denso mediante fusion de rango recíproco (RRF, k=60) eleva el nDCG@10 entre 0.030 y 0.067 para todos los motores con brazo de palabras clave. En MedRAG, los brazos denso y BM25 están cerca de tener la misma fuerza individual (alrededor de 0.80 cada uno), por lo que la mejora recupera los errores de cada brazo en lugar de que uno domine.

Los motores con un brazo BM25 fuerte ganan más, y pgvector y Weaviate ganan menos, en línea con sus brazos de palabras clave más débiles (0.740 y 0.782). Ningún híbrido de ningún motor cae por debajo de su brazo denso una vez medido correctamente.

Lo que separa a los motores es la fusion nativa frente a los viajes de ida y vuelta del lado del cliente, desde Milvus con 340 QPS nativos hasta pgvector con 12 QPS del lado del cliente. Cuatro motores fusionan de forma nativa (Qdrant, Milvus, Weaviate, LanceDB). Redis ejecuta BM25 nativo y KNN, pero no tiene fusion del lado del servidor en esta versión, por lo que el cliente hace dos viajes de ida y vuelta y fusiona en Python. pgvector no tiene fusion API, fusiona del lado del cliente y su brazo de palabras clave es ts_rank de Postgres (frecuencia de términos con normalización de longitud, sin IDF), que con un escaneo de texto completo OR se ejecuta a 12 QPS. Chroma autoalojado no tiene búsqueda por palabras clave con clasificación en absoluto (BM25 es una función de Chroma Cloud), por lo que no tiene fila híbrida.

El tiempo de construcción del índice abarca 13x

Con 50k vectores, construir el índice va desde 7 segundos (LanceDB) y de 11 a 13 (Weaviate, Milvus) hasta 88 segundos (pgvector). Con 2.25M la diferencia alcanza 13x. LanceDB y Milvus terminan en 7 a 8 minutos, frente a 44 minutos para Redis y 92 para pgvector. Normalizado a la tarifa de la caja, el coste de construcción va desde €0.04 por 1M de vectores (LanceDB) y €0.05 (Milvus) hasta €0.58 (pgvector). La construcción es un coste único, que se paga de nuevo solo cuando se reindexa el corpus.

Calidad de recuperación con 2.25M vectores

Para probar la calidad a escala manteniendo etiquetas humanas reales, construimos un corpus de 2.25M vectores. Combina los 50k documentos etiquetados de MedRAG con 2.2M distractores de pubmed, todos en el mismo espacio bge-m3, con verificación de integridad para que ningún distractor sea un objetivo mal etiquetado. Los datasets ANN estándar de miles de millones no llevan etiquetas de relevancia humana, por lo que no pueden mostrar lo que ocurre después.

El recall ANN geométrico se mantiene a escala. Todos los motores siguen alcanzando un Recall@10 superior a 0.973 con 2.25M (Qdrant y Milvus con 0.999), por lo que el índice encuentra los verdaderos vecinos más cercanos. La calidad semántica de las respuestas no se mantiene. El nDCG@10 cae de aproximadamente 0.81 con 50k a aproximadamente 0.56 con 2.25M para todos los motores, porque el documento correcto queda enterrado entre 2.2M distractores.

El colapso no es un efecto de la base de datos. Afecta por igual al oráculo kNN exacto (el nDCG@10 del oráculo con 2.25M es 0.572, y todos los motores se sitúan en ese techo alrededor de 0.55 a 0.57). Si la causa es el techo del embedding, la ambigüedad del corpus o las etiquetas de un solo positivo que pasan por alto duplicados cercanos ahora relevantes no se decide aquí. Separar esas causas requiere reetiquetar humanamente los documentos que quedaron en los primeros puestos. El hecho reportable es que escalar el corpus 45x eliminó aproximadamente un tercio de la calidad de respuesta (nDCG@10 de 0.81 a 0.56) mientras que todos los índices ANN seguían reportando un recall casi perfecto, un efecto que un benchmark solo geométrico pasaría por alto.

Durabilidad, alta disponibilidad y seguridad por motor

La velocidad, la memoria y el recall son los ejes medidos. Para una implementación de RAG en producción, los ejes no medidos (durabilidad, alta disponibilidad, control de acceso) también diferencian a estos motores. Este inventario de capacidades se basa en la documentación oficial de cada motor en la edición de código abierto evaluada. Es un inventario de capacidades, no una prueba de caos. El tiempo real de conmutación por error, la ventana de pérdida de datos en recuperación de fallos y el aislamiento entre inquilinos bajo carga no se miden aquí.

Entre los siete, solo pgvector ofrece recuperación a un punto en el tiempo (mediante archivado WAL de Postgres) y seguridad a nivel de fila. Qdrant, Milvus y Weaviate incluyen replicación y RBAC en sus compilaciones de código abierto, con la salvedad de que la alta disponibilidad de Milvus reside en el modo distribuido más pesado, no en la compilación autónoma medida aquí. Ninguno de los siete cifra los datos en disco de forma nativa. Todos dependen del cifrado de disco o volumen en la capa de infraestructura.

Para RAG multiinquilino, donde un filtro actúa también como límite de control de acceso, Qdrant, Milvus, Weaviate y pgvector pueden imponer aislamiento de inquilinos dentro de la base de datos. Chroma y LanceDB embebido lo trasladan a la aplicación. Un prefiltro correcto produce subresultados, un riesgo de completitud, en lugar de filtrar documentos de otro inquilino. Una fuga entre inquilinos requeriría un postfiltro defectuoso, que ninguno de estos motores utilizó.

Cómo funciona la búsqueda de vecinos más cercanos aproximados

Una base de datos vectorial almacena un vector de alta dimensión por documento y, dado un vector de consulta, devuelve los k más cercanos según una métrica de distancia (aquí coseno sobre vectores normalizados L2). La búsqueda exacta de vecinos más cercanos compara la consulta con cada vector almacenado, lo que es correcto pero escala linealmente con el tamaño del corpus. Con 50k vectores es rápida. Con millones es demasiado lenta para servir.

Los índices de vecinos más cercanos aproximados (ANN) sacrifican algo de exactitud para buscar en una fracción de los vectores almacenados. La estructura dominante en estos motores es HNSW, un grafo de proximidad por capas que camina desde un punto de entrada grueso hasta un vecindario denso, visitando un número acotado de candidatos fijado por un control de búsqueda (ef para HNSW, nprobe para IVF). Un ef mayor visita más candidatos, lo que eleva el recall y reduce el QPS. Un ef menor hace lo contrario.

Dado que ese control intercambia continuamente recall por velocidad, comparar dos motores con un único ajuste fijo es engañoso, ya que uno puede estar gastando más exactitud a cambio de su velocidad. La comparación justa barre el control, traza la curva de recall frente a QPS de cada motor y los lee a todos con el mismo recall. Ese punto de recall coincidente (Recall@10 = 0.95 aquí) es donde se toman las cifras de QPS, latencia y memoria de este benchmark.

No te pierdas nuestros análisis comparativos e insights basados en datos. El botón abre Google; seleccionar AIMultiple confirma que deseas ver AIMultiple con más frecuencia en los resultados de búsqueda de Google.

Añadir como fuente preferida

Metodología del benchmark

Motores. Qdrant v1.18.1, Milvus v2.6.0, Weaviate 1.38.0, pgvector 0.8.x (Postgres 17), Chroma 1.5.0, Redis/RediSearch 8.2 y LanceDB 0.34.0, con imágenes Docker fijadas. Redis se ejecutó con persistencia desactivada (sin instantánea RDB ni archivo de solo adjuntar).

Hardware. Un Hetzner CCX53 (32 vCPU dedicadas, 128 GB de RAM, NVMe, nbg1) para exactitud, velocidad, memoria, filtrado y construcción, un contenedor activo a la vez, un contenedor nuevo por cada construcción de índice y un cliente de un solo hilo co-ubicado. La dimensión de rotación en vivo se ejecutó en un CCX33 (8 vCPU, 32 GB).

Embedding. bge-m3, 1024-dim, coseno sobre float32 normalizado L2, k=10, semilla 42, idénticos a nivel de bytes entre motores. Las consultas llevan etiquetas humanas de un solo positivo (target_doc_id).

Corpora. MedRAG-50k (154 consultas) y TechQA-28k (151 consultas) para la calidad de recuperación, y un corpus de 2.25M vectores (50k etiquetados más 2.2M distractores) para el nivel de escala. La dimensión híbrida se volvió a ejecutar en Docker local, por lo que su QPS es comparable entre filas híbridas, no con las cifras de la caja. Su nDCG y Δ son independientes del hardware.

Estadísticas. 100 o más ejecuciones por medición, recorte de valores atípicos IQR a 3.0x, cronometraje perf_counter_ns. Los pools de consultas de 154 a 246 limitan el informe de cola en p95, ocasionalmente p99. p99.9 no está definido con estos conteos.

Verdad fundamental dual. Una base de datos vectorial tiene dos verdades fundamentales independientes, y este benchmark puntúa ambas. La verdad fundamental geométrica (ANN Recall@10 contra el oráculo exacto de fuerza bruta sobre los mismos vectores) pregunta si el índice devolvió los verdaderos vecinos más cercanos, aislando la base de datos. La verdad fundamental semántica (nDCG@10, MRR, Hit@k contra etiquetas humanas) pregunta si los documentos devueltos son relevantes, lo que en gran medida es el embedding, mantenido constante. Dado que el embedding está congelado, clasificar los motores por puntuaciones semánticas brutas clasificaría el embedding. La potencia de la base de datos se manifiesta como velocidad y memoria con recall ANN coincidente, y el puente Δ traduce su pérdida de aproximación en calidad de respuesta.

Ancla de corrección. Cada receta por motor (filtro e híbrido) se tomó de la documentación oficial en la versión exacta y se verificó de forma adversarial antes de codificar. La dimensión híbrida lleva una clave de respuestas BM25 independiente (dos referencias coinciden en nDCG alrededor de 0.81), por lo que cualquier motor que puntúe lejos de ella indica un error del arnés, no un hallazgo. Esa salvaguarda detectó tres errores de medición en la primera pasada, todos en nuestro arnés (un artefacto de temporización del índice asíncrono en Weaviate, una función de ranking de Postgres incorrecta y un error de SQL fusion que hizo que HNSW ignorara su ajuste de ef), que corregimos al volver a medir los siete motores en un entorno consistente, donde los cinco motores ya correctos reprodujeron sus cifras exactamente. Las dimensiones de concurrencia y rotación llevan la misma ancla (recomprobaciones de recall y tombstone), por lo que ninguna cifra reportada es rápida pero incorrecta.

Significación estadística

Cada cifra reportada es una estimación puntual bootstrap sobre 100 o más ejecuciones, con un intervalo de confianza del 95 % a partir de 1.000 remuestras, y una diferencia se considera real cuando los dos intervalos no se superponen.

La mejora híbrida es la decisión ajustada, por lo que sus intervalos son la evidencia decisiva. Cuatro motores superan cero y dos no:

La exactitud de recuperación es la misma regla leída al revés. Los nDCG@10 de los siete motores caen dentro de intervalos superpuestos en una diferencia de 0.014, por lo que ninguno gana, que es lo que significa el empate. Los órdenes de velocidad y memoria quedan muy por fuera de esa incertidumbre, con brechas (rendimiento de un solo hilo 10x, memoria pico 3.7x) que empequeñecen el ruido bootstrap.

Motores evaluados

Limitaciones

Redis se ejecutó con persistencia desactivada, por lo que una configuración de fsync AOF cambiaría su latencia de escritura y su huella con respecto a las cifras volátiles reportadas aquí.

Las etiquetas humanas son de un solo positivo (un documento correcto por consulta), sin relevancia graduada ni acuerdo entre anotadores, por lo que nDCG@10, MRR@10 y Hit@10 llevan una señal casi idéntica en estos datos. El embedding se mantiene constante por diseño. Las familias de embedding, las dimensiones y el comportamiento multilingüe son un benchmark aparte. Esta ejecución aísla la capa de recuperación. El reranker (cross-encoder) y las etapas de generación de respuestas de LLM de un pipeline de RAG quedan fuera del alcance. Los motores cloud gestionados (Pinecone, Zilliz y otros) son una fase posterior. La comparación de durabilidad y seguridad se basa en documentación, no en pruebas de caos.

Lecturas adicionales

• Benchmark de embedding models
• Benchmark de rerankers
• Calculadora de bases de datos vectoriales
• Embedding models de código abierto
• Embedding models multilingües
• Embeddings multimodales
• Frameworks de RAG agénticos

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  = {{Benchmark de bases de datos vectoriales: 7 motores de código abierto para RAG}},
  year   = {2026},
  month  = jul,
  howpublished    = {\url{https://aimultiple.com/open-source-vector-databases}},
  note   = {AIMultiple. Recuperado el 17 de Julio de 2026}
}

Registro de cambios

3 actualizaciones

1. 202617 de Jul

   Se reemplazó Faiss por LanceDB en la lista de bases de datos vectoriales evaluadas.

2. 27 de Feb

   Se agregaron actualizaciones recientes a Milvus, Qdrant y Chroma.

3. 202514 de Ago

   Se añadió una nueva sección, "Características clave de las bases de datos vectoriales de código abierto", al artículo.

Ekrem Sarı

Investigador de IA

Síguenos

Ekrem es investigador de IA y científico de datos en AIMultiple. Diseña y ejecuta benchmarks prácticos para sistemas de IA y LLM.

Ver perfil completo

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.

Nombre

Dirección de correo electrónico

Comentario

0/450

Publicar comentario