Comparativa de Bases de Datos Vectoriales: 7 Motores de Código Abierto para RAG

Comparamos siete bases de datos vectoriales autogestionadas de código abierto como capa de recuperación de un pipeline de RAG, ejecutándose cada una por separado sobre los mismos embeddings bge-m3 y consultas reales médicas y técnicas, de modo que el índice de la base de datos fue la única variable. La carga de trabajo abarcó MedRAG-50k, TechQA-28k y un corpus de 2,25M de vectores en ocho dimensiones, desde la precisión 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 actividad continua.

Velocidad en un solo hilo

Cada motor se evalúa al mismo nivel de recall, el punto operativo compartido donde su parámetro de búsqueda (ef o nprobe) se ajusta hasta alcanzar un Recall@10 de 0,95, permitiendo una comparación justa de las cifras de velocidad.

En un solo hilo de cliente, Redis sirve 764 QPS en MedRAG-50k con un pico de 559 MB de RAM, 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 del primero al último. LanceDB es el valor atípico en disco, intercambiando 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 orden intermedio se reorganiza a escala, donde Milvus cae del tercer al sexto puesto.

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

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

Rendimiento bajo concurrencia

Los QPS en un solo hilo responden a cuán rápido es una consulta. La pregunta en 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 operarse de dos maneras, y ambas son comunes en aplicaciones Python de RAG. Un proceso asíncrono o con hilos deserializa cada resultado concurrente (gRPC/protobuf o RESP) en un solo GIL, por lo que el cliente, no el servidor, limita el rendimiento. Muchos procesos worker (el patrón gunicorn -w N) obtienen cada uno su propio GIL, exponiendo mucho más de la capacidad del servidor. Medimos ambos en una caja de 32 vCPU con un ef fijo de 128, y verificamos el recall en cada punto.

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

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

Redis mantiene la latencia de consulta única más baja del conjunto (alrededor de 1,6 ms), y su núcleo de búsqueda monohilo se satura alrededor de 1642 QPS a 32 solicitudes concurrentes, 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 de Postgres independiente por conexión) escalan a través de los 32 núcleos. pgvector tiene el pico de un solo proceso más bajo (536) y el segundo pico más alto de 32 procesos (4832). Con un presupuesto de p99 por debajo de 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 número coubicado esté limitado por el cliente en lugar de por el servidor, ya que el número de procesos por sí solo lo mueve 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 a 512 solicitudes, y LanceDB está embebido, por lo que la historia del 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 a 2,25M, donde se abre la compensación entre memoria y disco.

La RAM pico a 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 7,5 GB a 27,7 GB por millón de vectores. Milvus se mantiene como el más ligero porque descarga el índice en disco (estilo DiskANN), mientras que los motores HNSW completamente en RAM crecen más rápido, por lo que Milvus, el más pesado a 50k (3.300 MB), es el más ligero a 2,25M (17,0 GB), con Chroma como el más pesado con 62,4 GB.

Los dos motores en disco quedan fuera de esta comparación de RAM porque su huella está en disco en lugar de en RAM. pgvector tiene un índice en disco de 18,4 GB y LanceDB uno de 12,0 GB a 2,25M, y su RAM de servicio es un caché de página sobre ese índice en lugar del conjunto de trabajo completo, lo cual no se midió. También hay una advertencia sobre las cifras en memoria. Son una marca de agua alta de construcción y servicio, no una huella solo de servicio, por lo que una remedición solo de servicio es un refinamiento pendiente.

Frescura, escrituras y eliminaciones bajo actividad continua

Las otras siete dimensiones miden una carga estática de lectura tras carga masiva. Las bases de conocimiento RAG reales añaden, actualizan y eliminan documentos continuamente mientras el índice se fusiona en segundo plano. Esta carga de trabajo de actividad continua 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 (verificaciones de recall y de borrado lógico) son independientes del hardware.

Frescura (lectura tras escritura). Con la configuración de consistencia con la que se configuró cada motor, todos muestran lectura tras escritura. Un documento recién escrito se puede buscar inmediatamente, con cero de aproximadamente 150 escrituras no visibles. La latencia desde la confirmación de escritura hasta la 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 en crecimiento aún no sellado (el vector entra en el grafo HNSW persistente más tarde), por lo que sus 12 ms son la capacidad de búsqueda del segmento en crecimiento, 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 cada motor, 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 es cercano 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, razón por la cual los constructores estáticos más rápidos son los más lentos bajo actividad continua. El rendimiento de escritura aquí es la tasa alcanzada contra un objetivo de 150/s bajo lecturas concurrentes, por lo que los motores rápidos están limitados cerca de 150 en lugar de mostrar su pico. Léase esto 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 prueba aquí.

Eliminación y compactación. Eliminando un 20% aleatorio del conjunto activo y reinsertando un 20% de nuevos documentos, la fuga de borrado lógico fue cero para todos los motores. Un id eliminado nunca reapareció en la búsqueda, y el Recall@10 se mantuvo entre 0,97 y 1,00 después del ciclo completo. La corrección se mantiene bajo actividad continua en todos los casos. 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 sus QPS de lectura corresponden a un corpus más pequeño. A esa escala, su frescura corregida es de unos 5 ms y su tasa de escritura de unos 102/s, lo que sitúa a ambos en la mitad del grupo.

Métricas explicadas

ANN Recall@10 es la fracción de los 10 vectores verdaderos más cercanos (según un oráculo exacto de fuerza bruta kNN sobre los mismos embeddings que la BD indexó) que el índice aproximado devolvió. 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 que mide si el documento correcto etiquetado por humanos se sitúa cerca de la parte superior de la lista de resultados. Mide la relevancia de la recuperación de extremo a extremo, que es en gran medida una propiedad del modelo de embedding, que se mantiene 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 una configuración de búsqueda dada. Convierte el error de aproximación de cada motor en la calidad de respuesta que cuesta su velocidad, reportable porque disponemos tanto de un oráculo como de etiquetas humanas.

Hallazgos de la comparativa de bases de datos vectoriales

Los siete motores empatan en precisión de recuperación

A Recall@10 = 0,95 en MedRAG-50k, nDCG@10 se sitúa entre 0,803 (pgvector) y 0,817 (LanceDB), una dispersión 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 nDCG de calidad de respuesta.

Bajo este embedding, corpus, k=10 y punto operativo de 0,95, la elección de la base de datos mueve el nDCG@10 como máximo 0,014, frente a la dispersión de 10x en rendimiento monohilo y la dispersión de 3,7x en memoria pico mostradas anteriormente. La elección del índice empieza a mover la calidad a Recall@10 = 0,99 o superior, a k más grandes, en corpus mucho más grandes o con índices cuantizados.

La fiabilidad de la recuperación varía más según lo que pregunta una consulta que según qué base de datos la responde. En las 154 consultas MedRAG en el oráculo kNN exacto, las búsquedas factuales puntúan 0,888 nDCG@10, las preguntas condicionales 0,836, las preguntas comparativas 0,779 y las preguntas de existencia de cláusula 0,763. La brecha de 0,125 entre factuales y de 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 (dispersos y agrupados). La separación está en el rendimiento filtrado.

La separación está en el rendimiento. Chroma (11-19 QPS) y pgvector (10-56 QPS) mantienen el recall con un rendimiento filtrado de 20 a 40x menor que el resto. Milvus mantiene el recall más alto en el peor caso (0,984) con 268 a 732 QPS a través de la selectividad, mientras que Redis es el más rápido a baja selectividad (1.374 QPS al 1%) con un suelo de recall más bajo (0,968). Con una selectividad del 1-5%, un recall de 1,00 es en gran medida la rama de escaneo completo exacto del planificador de consultas por debajo del umbral de escaneo completo de cada motor, no HNSW filtrable, divulgado por motor.

*El recall filtrado de LanceDB se midió inicialmente en 0,24 en 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 el 9% de las particiones. Re-medido con nprobes adecuados, el Recall@10 agrupado se recupera de 0,24 a 0,76 (nprobes=128) hasta aproximadamente 1,00 (nprobes=256), con QPS de 3 a 5x menores. LanceDB mantiene el recall filtrado, lentamente. Una remedición del rendimiento filtrado con recall equiparado en el mismo host aún está pendiente, por lo que los QPS filtrados de LanceDB no se listan.

La búsqueda híbrida añade hasta 0,067 nDCG

Añadir un brazo de palabras clave BM25 estándar y fusionarlo con el brazo denso mediante fusión de rango recíproco (RRF, k=60) eleva el nDCG@10 entre 0,030 y 0,067 para cada motor con un brazo de palabras clave. En MedRAG, los brazos denso y BM25 tienen una fuerza casi igual individualmente (alrededor de 0,80 cada uno), por lo que la mejora recupera los errores de cada brazo en lugar de que un brazo 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). El 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 fusión nativa frente a los recorridos de ida y vuelta del lado del cliente, desde Milvus a 340 QPS nativos hasta pgvector a 12 QPS del lado del cliente. Cuatro motores fusionan de forma nativa (Qdrant, Milvus, Weaviate, LanceDB). Redis ejecuta BM25 y KNN nativos pero sin fusión del lado del servidor en esta versión, por lo que el cliente realiza dos viajes de ida y vuelta y fusiona en Python. pgvector no tiene API de fusión, fusiona del lado del cliente, y su brazo de palabras clave es ts_rank de Postgres (frecuencia de término con normalización de longitud, sin IDF), que con un escaneo de texto completo OR se ejecuta a 12 QPS. Chroma autogestionado no tiene búsqueda de palabras clave clasificada en absoluto (BM25 es una característica de Chroma Cloud), por lo que no tiene fila híbrida.

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

A 50k vectores, construir el índice va desde 7 segundos (LanceDB) y de 11 a 13 (Weaviate, Milvus) hasta 88 segundos (pgvector). A 2,25M la dispersión alcanza 13x. LanceDB y Milvus terminan en 7 a 8 minutos, frente a 44 minutos de Redis y 92 de 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 a 2,25M de vectores

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

El recall geométrico de ANN se mantiene a escala. Cada motor sigue alcanzando Recall@10 por encima de 0,973 a 2,25M (Qdrant y Milvus en 0,999), por lo que el índice encuentra los verdaderos vectores más cercanos. La calidad semántica de la respuesta no se mantiene. nDCG@10 cae de aproximadamente 0,81 a 50k a aproximadamente 0,56 a 2,25M para cada motor, porque el documento correcto está enterrado entre 2,2M de distractores.

El colapso no es un efecto de la base de datos. Afecta al oráculo kNN exacto de forma idéntica (nDCG@10 del oráculo a 2,25M es 0,572, y cada motor se sitúa en ese techo alrededor de 0,55 a 0,57). No se dirime aquí si la causa es el techo del embedding, la ambigüedad del corpus o etiquetas de un solo positivo que pasan por alto cuasi-duplicados ahora relevantes. Separar esas causas requiere reetiquetar humanamente los documentos recién clasificados en primer lugar. El hecho reportable es que escalar el corpus 45x borró aproximadamente un tercio de la calidad de la respuesta (nDCG@10 de 0,81 a 0,56) mientras que cada índice ANN reportaba un recall casi perfecto, un efecto que una comparativa solo geométrica pasaría por alto.

Durabilidad, alta disponibilidad y seguridad por motor

La velocidad, la memoria y el recall son los ejes medidos. Para un despliegue de RAG en producción, los ejes no medidos (durabilidad, alta disponibilidad, control de acceso) también separan 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 de conmutación por error real, la ventana de pérdida de datos en recuperación de fallos y el aislamiento de inquilinos bajo carga no se miden aquí.

Entre los siete, pgvector por sí solo ofrece recuperación a un punto en el tiempo (a través del 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 independiente 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 multi-inquilino, donde un filtro funciona como límite de control de acceso, Qdrant, Milvus, Weaviate y pgvector pueden imponer el aislamiento de inquilinos dentro de la base de datos. Chroma y LanceDB embebido trasladan eso a la aplicación. Un prefiltro correcto infradevuelve, un riesgo de completitud, en lugar de filtrar documentos de otro inquilino. Una fuga entre inquilinos necesitaría un postfiltro defectuoso, que ninguno de estos motores utilizó.

Cómo funciona la búsqueda aproximada del vecino más cercano

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 del vecino más cercano compara la consulta con cada vector almacenado, lo cual es correcto pero escala linealmente con el tamaño del corpus. Con 50k vectores eso es rápido. Con millones es demasiado lento para servir.

Los índices aproximados del vecino más cercano (ANN) renuncian a algo de precisión para buscar en una fracción de los vectores almacenados. La estructura dominante en estos motores es HNSW, un grafo de proximidad en capas que camina desde un punto de entrada general hasta un vecindario denso, visitando un número limitado de candidatos establecido por un control de búsqueda (ef para HNSW, nprobe para IVF). Un ef más grande visita más candidatos, aumentando el recall y disminuyendo los QPS. Un ef más pequeño hace lo contrario.

Dado que ese control intercambia recall por velocidad de forma continua, comparar dos motores en un solo ajuste fijo es engañoso, ya que uno puede estar gastando más precisión a cambio de su velocidad. La comparación justa barre el control, dibuja la curva de recall frente a QPS de cada motor y los lee a todos al mismo recall. Ese punto de recall equiparado (Recall@10 = 0,95 aquí) es donde se toman las cifras de QPS, latencia y memoria en esta comparativa.

Descubre más de nuestros análisis comparativos e insights basados en datos en la Búsqueda de Google.

Añadir como fuente preferida

Metodología de la comparativa

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, en imágenes Docker fijadas. Redis se ejecutó con la persistencia desactivada (sin instantánea RDB ni archivo de solo anexado).

Hardware. Un Hetzner CCX53 (32 vCPU dedicadas, 128 GB de RAM, NVMe, nbg1) para precisión, velocidad, memoria, filtrado y construcción, un contenedor activo a la vez, un contenedor nuevo por construcción de índice, y un cliente monohilo coubicado. La dimensión de actividad continua 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 byte en todos los 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 de vectores (50k etiquetados más 2,2M distractores) para el nivel de escala. La dimensión híbrida se reejecutó en Docker local, por lo que sus QPS son comparables entre filas híbridas, no con las cifras de la caja. Su nDCG y Δ son independientes del hardware.

Estadísticas. 100+ ejecuciones por medición, recorte de valores atípicos IQR a 3,0x, temporización perf_counter_ns. Los grupos de consultas de 154 a 246 limitan el informe de cola a p95, ocasionalmente p99. p99.9 no está definido con estos recuentos.

Doble verdad fundamental. Una base de datos vectorial tiene dos verdades fundamentales independientes, y esta comparativa 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 vectores 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 cual es en gran medida 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 muestra como velocidad y memoria con un recall ANN equiparado, y el puente Δ traduce su pérdida de aproximación en calidad de respuesta.

Ancla de corrección. Cada receta por motor (filtrado 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 señala 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 de índice asíncrono en Weaviate, una función de clasificación de Postgres incorrecta y un error de fusión SQL que hizo que HNSW ignorara su configuración de ef), que solucionamos re-midiendo los siete motores en un entorno consistente, donde los cinco motores ya correctos reprodujeron sus números exactamente. Las dimensiones de concurrencia y actividad continua llevan la misma ancla (reverificaciones de recall y borrado lógico), por lo que ningún número reportado es rápido pero incorrecto.

Significación estadística

Cada número reportado es una estimación puntual bootstrap sobre 100+ ejecuciones, con un intervalo de confianza del 95% de 1.000 remuestreos, y una diferencia se considera real cuando los dos intervalos no se superponen.

La mejora híbrida es el caso límite, por lo que sus intervalos son la evidencia decisiva. Cuatro motores superan el cero y dos no:

La precisión de recuperación es la misma regla leída al revés. El nDCG@10 de los siete motores cae dentro de intervalos superpuestos en una dispersión de 0,014, por lo que ninguno gana, que es lo que significa el empate. Las ordenaciones de velocidad y memoria se sitúan muy lejos de esa incertidumbre, con brechas (10x de rendimiento monohilo, 3,7x de memoria pico) que empequeñecen el ruido bootstrap.

Motores evaluados

Limitaciones

Redis se ejecutó con la persistencia desactivada, por lo que una configuración de fsync AOF cambiaría su latencia de escritura y huella 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, dimensiones y comportamiento multilingüe son una comparativa separada. Esta ejecución aísla la capa de recuperación. Las etapas de reranker (cross-encoder) y generación de respuestas con LLM de un pipeline de RAG están 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

• Comparativa de modelos de embedding
• Comparativa de rerankers
• Calculadora de bases de datos vectoriales
• Modelos de embedding de código abierto
• Modelos de embedding multilingües
• Embeddings multimodales
• Frameworks de RAG agéntico

Cita esta investigación

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  = {{Comparativa 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}
}

Ekrem Sarı

Investigador de IA

Síguenos

Ekrem es un Investigador de IA y Analista 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