Vector database

Definición

Una vector database (base de datos vectorial, o vector store) es una base de datos especializada en almacenar y consultar vectores de embeddings de alta dimensionalidad mediante búsqueda por similitud. Es la pieza fundamental del stack moderno de RAG, búsqueda semántica, recomendación y cualquier sistema donde la pregunta "¿qué se parece a esto?" sea más útil que "¿qué es exactamente igual a esto?".

Las bases tradicionales (PostgreSQL, MySQL) están optimizadas para búsquedas exactas o por rango sobre datos estructurados. Las vector DBs están optimizadas para encontrar los K vectores más cercanos (top-K) a un vector de consulta en un espacio de 384-4096 dimensiones, sobre colecciones de millones o miles de millones de vectores, en milisegundos.

A 2026 el ecosistema está maduro: Pinecone (SaaS pionero), Qdrant, Weaviate, Milvus, Chroma (open source), pgvector (extensión de PostgreSQL), y motores integrados en cloud (OpenAI Vector Store, Vertex AI Matching Engine).

Cómo funciona

El reto técnico central: encontrar los K vectores más cercanos en un espacio de alta dimensionalidad es computacionalmente caro. Búsqueda exhaustiva (comparar contra todos) escala linealmente — inviable a millones de vectores.

La solución: Approximate Nearest Neighbors (ANN) — algoritmos que sacrifican un poco de precisión por velocidad masiva:

1. HNSW (Hierarchical Navigable Small World): el más usado hoy. Construye un grafo jerárquico donde cada vector está conectado a sus vecinos. Búsqueda navega el grafo desde el nivel superior hacia abajo. Recall típico >95%, tiempos sub-milisegundo.

2. IVF (Inverted File Index): agrupa vectores en clusters (centroides), busca primero el cluster correcto, luego dentro. Usado por Faiss/Milvus.

3. LSH (Locality-Sensitive Hashing): hash que pone vectores similares en el mismo bucket. Más simple, menos preciso, en desuso.

4. PQ (Product Quantization): cuantiza vectores para ahorrar memoria masiva. Se combina con IVF.

5. DiskANN: optimizado para conjuntos masivos que no caben en RAM (sirve desde SSD).

En la práctica, HNSW domina el mercado por su balance entre velocidad, precisión y simplicidad.

Métricas de distancia

Tres principales para comparar vectores:

• Cosine similarity: ángulo entre vectores. Ignora magnitud. Lo más usado en embeddings de texto.
• Dot product: producto escalar. Equivalente a coseno si vectores normalizados.
• Euclidean distance (L2): distancia "física" en el espacio. Sensible a magnitud.

La mayoría de embeddings de texto modernos vienen normalizados → coseno y dot product son equivalentes y más eficientes computacionalmente.

Ejemplo práctico

En antonioecheverria.es la búsqueda semántica del diccionario usa una versión muy simplificada de vector DB (un JSON estático con vectores precomputados + cosine similarity en cliente). Para 65 términos basta. Pero si creciéramos a 50.000 términos + comentarios de usuarios + chunks de blog, ya necesitaríamos una vector DB real.

Para AE Works desarrollamos un asistente RAG sobre 200.000 documentos de un cliente del sector legal:

1. Indexación:

   • Cada documento se chunkea en piezas de ~500 tokens (overlap 50).
   • Cada chunk se embebe con un modelo apropiado (~1.500 dimensiones).
   • Se guarda en Qdrant con metadatos: cliente_id, tipo_documento, fecha, jurisdicción.

2. Búsqueda:

   • Query del usuario → embedding del query.
   • Qdrant devuelve top-50 chunks más cercanos (con filtro de cliente_id y fecha).
   • Re-ranker (Cohere) reordena los 50 a top-10 por relevancia real.
   • El LLM recibe esos 10 chunks como contexto.

Volumen: ~3M de chunks indexados, 1.500 dimensiones. Qdrant los maneja con HNSW en ~80GB de RAM. Latencia de búsqueda: 20-50ms.

Sin vector DB, esa búsqueda sería imposible a esa escala con latencia razonable.

Comparativa de opciones populares

Para la mayoría de proyectos nuevos a 2026 las elecciones razonables son: Qdrant (autohospedado/managed) si quieres open source con buen rendimiento, Pinecone si quieres mínimo overhead operacional, pgvector si ya tienes PostgreSQL y el volumen es manejable.

Features modernas más allá de la búsqueda básica

Las vector DBs serias hoy ofrecen mucho más que "top-K más cercanos":

• Filtros con metadatos: combinar similitud vectorial con WHERE típico de SQL (categoría, fecha, cliente, etc.). Imprescindible en producción.
• Hybrid search: combinar búsqueda densa (embeddings) con búsqueda léxica (BM25) para mejor recall.
• Multi-tenancy: aislamiento de datos por cliente / namespace.
• Re-ranking integrado: algunos motores hacen el re-ranking en el server, no hay que sacar los datos.
• Sparse + Dense vectors: combinar SPLADE u otros sparse con embeddings densos.
• CRUD eficiente: insert, update, delete con re-indexación incremental.
• Snapshots y replicación: backup, alta disponibilidad.
• API streaming: para grandes datasets que se procesan en batches.

Errores comunes al usar vector DBs

• Pensar que son intercambiables con bases tradicionales: una vector DB no sustituye a Postgres. Coexisten.
• No usar filtros con metadatos: buscar entre los 200.000 documentos del cliente Y los del cliente B en cada consulta es lento y peligroso.
• Embeddings de modelos distintos en la misma colección: incompatibles. Cada espacio vectorial es independiente.
• Reindexar todo cuando cambia un documento: las vector DBs modernas soportan updates incrementales. Úsalos.
• Subestimar el coste de embeddings: generar embeddings de 1M chunks puede costar 50-500€ en APIs.
• No medir recall@K: si tu top-10 no contiene lo relevante, ningún re-ranker lo va a arreglar. Mide.
• Confundir "vector DB" con "RAG": la vector DB es UN componente del RAG, no el sistema completo.

Cuándo usar una vector DB

Sí, una vector DB tiene sentido cuando:

• Construyes RAG sobre cualquier volumen > unas pocas docenas de documentos.
• Necesitas búsqueda semántica (intención, no palabras exactas).
• Tienes recomendación basada en similitud.
• Detectas duplicados o variantes de contenido.
• Tu corpus es dinámico y necesitas updates eficientes.

No es necesaria cuando:

• Tu volumen es trivial (<200 documentos) → JSON estático + cosine in-memory basta.
• Solo necesitas búsqueda léxica (Pagefind, Elasticsearch text, Postgres FTS).
• El caso es transaccional/estructurado puro.

Referencias

• Malkov & Yashunin · HNSW paper — el algoritmo que domina las vector DBs modernas
• Qdrant Benchmarks — comparativa imparcial de motores de búsqueda vectorial
• pgvector Documentation — la extensión que llevó capacidad vectorial a PostgreSQL