Bases de Datos Vectoriales

¿Qué es?

Una base de datos vectorial es un sistema de almacenamiento optimizado para guardar, indexar y buscar vectores de alta dimensión — típicamente embeddings generados por modelos de IA. A diferencia de las bases de datos tradicionales que buscan por coincidencia exacta, las bases vectoriales encuentran los vectores más similares a una consulta.

Son la infraestructura fundamental para búsqueda semántica y RAG a escala.

¿Por qué no usar una base de datos tradicional?

Buscar el vector más cercano entre millones requiere comparar distancias con cada uno — O(n) por consulta. Las bases vectoriales usan índices aproximados (ANN — Approximate Nearest Neighbors) que reducen esto a O(log n) o mejor, sacrificando precisión perfecta por velocidad práctica.

Algoritmos de indexación

• HNSW (Hierarchical Navigable Small World): grafos navegables que permiten búsqueda eficiente. El más popular por su balance velocidad/precisión
• IVF (Inverted File Index): particiona el espacio en clusters y busca solo en los más cercanos
• PQ (Product Quantization): comprime vectores para reducir memoria, útil para datasets masivos
• Flat: búsqueda exacta sin índice — preciso pero lento, solo para datasets pequeños

Tuning de HNSW

HNSW tiene dos parámetros clave que controlan el tradeoff entre velocidad y recall:

La regla práctica: empezar con m=16, ef_construction=128, ef_search=64 y ajustar midiendo recall@10 contra búsqueda exacta.

Opciones de bases vectoriales

Bases dedicadas

Extensiones de bases existentes

Ejemplo: búsqueda semántica con pgvector

pgvector es la opción más pragmática cuando ya tienes PostgreSQL — evita agregar otro servicio a la infraestructura.

-- Habilitar la extensión y crear tabla
CREATE EXTENSION IF NOT EXISTS vector;
 
CREATE TABLE documents (
  id SERIAL PRIMARY KEY,
  content TEXT NOT NULL,
  metadata JSONB DEFAULT '{}',
  embedding vector(1536)
);
 
-- Crear índice HNSW para búsqueda rápida
CREATE INDEX ON documents
  USING hnsw (embedding vector_cosine_ops)
  WITH (m = 16, ef_construction = 128);
 
-- Búsqueda semántica: los 5 documentos más similares
SELECT id, content, 1 - (embedding <=> $1::vector) AS similarity
FROM documents
ORDER BY embedding <=> $1::vector
LIMIT 5;

Búsqueda híbrida

La búsqueda puramente vectorial falla cuando el usuario busca un término exacto (un nombre de producto, un código de error). La búsqueda híbrida combina similitud semántica con búsqueda de texto completo:

-- Búsqueda híbrida: combinar vector + full-text con RRF
WITH semantic AS (
  SELECT id, ROW_NUMBER() OVER (ORDER BY embedding <=> $1::vector) AS rank_s
  FROM documents
  LIMIT 20
),
keyword AS (
  SELECT id, ROW_NUMBER() OVER (ORDER BY ts_rank(to_tsvector(content), plainto_tsquery($2)) DESC) AS rank_k
  FROM documents
  WHERE to_tsvector(content) @@ plainto_tsquery($2)
  LIMIT 20
)
SELECT COALESCE(s.id, k.id) AS id,
       COALESCE(1.0 / (60 + s.rank_s), 0) + COALESCE(1.0 / (60 + k.rank_k), 0) AS rrf_score
FROM semantic s FULL OUTER JOIN keyword k ON s.id = k.id
ORDER BY rrf_score DESC
LIMIT 5;

Este patrón usa Reciprocal Rank Fusion (RRF) para combinar los rankings de ambas búsquedas. La constante 60 es el valor estándar que suaviza la fusión.

Consideraciones de diseño

• Dimensionalidad: más dimensiones = más almacenamiento y cómputo. 1536 (OpenAI) vs 384 (MiniLM) hace diferencia a escala
• Filtrado de metadatos: combinar búsqueda vectorial con filtros (fecha, categoría, usuario) — pre-filtrar reduce el espacio de búsqueda pero puede perder resultados relevantes; post-filtrar es más preciso pero más lento
• Actualizaciones: algunos índices son costosos de actualizar — considerar estrategias de batch
• Consistencia: muchas bases vectoriales priorizan disponibilidad sobre consistencia estricta

¿Por qué importa?

Las bases de datos vectoriales son la infraestructura que hace posible la búsqueda semántica y RAG a escala. Para equipos que ya usan PostgreSQL, pgvector elimina la necesidad de un servicio adicional y cubre la mayoría de casos hasta millones de vectores. Cuando el volumen supera eso o se necesitan filtros complejos con baja latencia, las bases dedicadas como Qdrant o Pinecone justifican la complejidad operacional adicional.

Referencias

• Efficient and robust approximate nearest neighbor search using HNSW — Malkov & Yashunin, 2016. El paper original de HNSW.
• pgvector: Open-source vector similarity search for Postgres — Extensión de PostgreSQL para búsqueda vectorial.
• Qdrant Documentation — Qdrant, 2024. Base de datos vectorial de alto rendimiento.
• What is a Vector Database? — Pinecone, 2024. Guía introductoria con comparaciones de algoritmos de indexación.
• ANN Benchmarks — Benchmarks comparativos de algoritmos de búsqueda de vecinos más cercanos.