Una base de datos vectorial almacena embeddings densos y dispersos de alta dimensión junto con metadatos, ofreciendo búsqueda de similitud mediante vecinos más cercanos aproximados (ANN) en milisegundos como capa base de memoria y recuperación para RAG, búsqueda semántica y agentes de IA.
| Carga de trabajo / Restricción | Categoría recomendada | Soluciones representativas | Motivo de elección |
|---|---|---|---|
| Stack PostgreSQL existente, bajo ~10M de vectores | Extensión de BD relacional | pgvector (+ halfvec / HNSW) | Reutiliza transacciones ACID, JOIN SQL y operación actual sin nueva infraestructura |
| Búsqueda híbrida texto completo BM25 + vectores | Extensión de motor de búsqueda | Elasticsearch / OpenSearch / Vespa | Ecosistema maduro de índices invertidos y ranking híbrido multietapa |
| Servicio independiente de alto QPS y filtrado complejo | BD vectorial distribuida dedicada | Qdrant / Milvus / Weaviate | Motor de almacenamiento especializado, filtrado rápido de payload y escalado horizontal |
| Desarrollo local, apps edge/escritorio o lectura directa en data lake | BD embebida / columnar | LanceDB / Chroma / FAISS | Ejecución en proceso con integración zero-copy de Apache Arrow / Parquet |
| Volúmenes masivos fríos/tibios a mínimo coste de almacenamiento | SaaS nativo en almacenamiento de objetos | Turbopuffer | Object Storage (S3/GCS) como fuente de verdad + caché local NVMe/RAM |
| Serverless sin operación ligado a ecosistemas cloud | Servicio cloud totalmente gestionado | Pinecone / Vertex AI Vector Search / Azure AI Search | Escalado serverless elástico e integración nativa con IAM y monitorización cloud |
🔗 Hojas de trucos relacionadas: Conceptos de LLM y Agentes IA · Algoritmos de IA modernos · Comandos de PostgreSQL · Comandos de Redis · Comandos de MongoDB
1. Conceptos clave y métricas de distancia
1.1 Terminología esencial
| Término | Definición | Consideraciones de ingeniería |
|---|---|---|
| Embedding | Vector de flotantes de longitud fija que codifica semántica de texto, imagen o audio | Dimensiones habituales: 384 / 768 / 1024 / 1536 / 3072; RAM y cómputo crecen linealmente |
| ANN (Approximate Nearest Neighbor) | Búsqueda indexada que cede un mínimo de recall (95 %–99 %) a cambio de 100×–1000× más velocidad | Equilibrio clave latencia vs recall frente al escaneo exacto k-NN |
| Metadata Filtering | Filtrado de la búsqueda vectorial mediante atributos escalares (tenant, fecha, ACL, categoría) | Distinguir Pre-filtering, Single-stage / Inline y Post-filtering |
| Hybrid Search | Combinación de vectores densos (semántica) y vectores dispersos / BM25 (coincidencia léxica) | Resuelve fallos de la búsqueda semántica pura en SKUs, códigos de error y acrónimos |
| Sparse Vector | Vector de alta dimensión con casi todo ceros (ej. SPLADE, pesos BM25) | Almacena solo índices y pesos no nulos; complemento natural de la búsqueda densa |
1.2 Tres métricas de distancia y similitud
Cosine(u, v) = (u · v) / (‖u‖₂ · ‖v‖₂)
IP(u, v) = u · v = ∑ᵢ (uᵢ × vᵢ)
L₂(u, v) = √( ∑ᵢ (uᵢ − vᵢ)² )
| Métrica | Significado | Equivalencia matemática | Casos de uso habituales |
|---|---|---|---|
| Similitud del coseno (Cosine) | Mide solo el ángulo ignorando la magnitud (−1 a 1; distancia = 1 - cos) |
Orden idéntico al producto interno con vectores normalizados L₂ | Búsqueda semántica de texto, RAG, embeddings de frases (opción por defecto) |
| Producto interno (IP / Dot) | Refleja ángulo y magnitud; menor coste computacional | En vectores unitarios sustituye a Cosine ahorrando raíces y divisiones | Sistemas de recomendación dos torres, embeddings normalizados (p. ej. OpenAI) |
| Distancia euclidiana (L₂) | Distancia geométrica en línea recta; menor = más cercano | Para vectores unitarios: L₂² = 2 − 2 · cos(u, v) |
Embeddings de imagen/rostro, clustering espacial, rasgos sensibles a magnitud |
2. Algoritmos de indexación ANN y cuantización
2.1 Comparativa de índices vectoriales
| Tipo de índice | Mecanismo | Uso de RAM | Latencia y Recall | Escala y motores representativos |
|---|---|---|---|---|
| Flat (Escaneo exacto) | Cálculo exhaustivo de distancia frente a todos los vectores | Moderado (solo vectores crudos/cuantizados) | 100 % recall; la latencia se dispara >~100k filas | Conjuntos pequeños (<100k) y benchmarks de verdad base |
| IVF-Flat (Archivo invertido) | Clustering K-Means en nlist cubos; escanea los nprobe más cercanos |
Bajo (sin sobrecarga de grafo) | Ajustable con nprobe; recall medio-alto |
1M–10M filas con presupuesto de RAM ajustado (FAISS / Milvus / pgvector) |
| IVF-PQ (IVF + Cuantización de producto) | Particionado en cubos más compresión por subespacios y codebooks | Muy bajo (16×–64× menor) | Ultrarrápido; menor recall inicial (requiere rescoring) | 100M+ en memoria (FAISS / Milvus / LanceDB) |
| HNSW (Grafo jerárquico) | Grafo multicapa tipo skip-list (capas altas gruesas, capa base fina) | Alto (vectores + aristas en RAM o mmap caliente) | Milisegundos + 95 %–99 % recall; estándar industrial | 1M–100M+ baja latencia en tiempo real (Qdrant / Milvus / Weaviate / pgvector) |
| DiskANN (Grafo Vamana) | Grafo para SSD: vectores comprimidos en RAM, grafo completo en NVMe | Bajo (5×–10× menos RAM) | 100M+ por nodo en ms; depende de IOPS NVMe rápidos | 100M–1B+ con RAM limitada (Milvus / LanceDB / Azure) |
| ScaNN | Cuantización vectorial anisotrópica + particionado en árbol | Bajo–Moderado | Mejor curva recall/latencia bajo producto interno | Recomendación y búsqueda a gran escala (Vertex AI Vector Search / OSS) |
Parámetros clave de ajuste HNSW:
M(enlaces bidireccionales máx. por nodo, típico16–64): mayorMmejora el recall en alta dimensión, pero eleva RAM y tiempo de construcción.efConstruction(tamaño de lista candidata al construir, típico100–400): solo afecta el tiempo de indexación y mejora la calidad del grafo.efSearch(ancho de exploración en consulta, debe ser ≥top_k): único parámetro ajustable por consulta; aumentarlo sube el recall y baja el QPS.
2.2 Cuantización y estimación de memoria
Línea base para 10 millones de vectores × 1536 dimensiones (FP32 sin comprimir):
Tamaño bruto ≈ N × D × 4 Bytes (el grafo HNSW añade ~1,2×–1,5× de sobrecarga RAM)
| Cuantización | Ancho / dim | Compresión | Tamaño 10M × 1536-dim | Balance de precisión y uso |
|---|---|---|---|---|
| FP32 (Sin comprimir) | 32 bits (4 B) | 1× | ~57,2 GB | Precisión de referencia; costoso en RAM residente |
| FP16 / BF16 (Media precisión) | 16 bits (2 B) | 2× | ~28,6 GB | Recall prácticamente sin pérdida (ej. pgvector halfvec), gran ROI |
| SQ8 (Cuantización escalar Int8) | 8 bits (1 B) | 4× | ~14,3 GB | Suele conservar 97 %+ de recall; estándar en producción |
| PQ (Product Quantization) | Subespacios | 16×–64× | ~1–4 GB | Requiere entrenar codebook; combinar con oversampling + rescore |
| BQ (Cuantización binaria 1 bit) | 1 bit | 32× | ~1,79 GB | Escaneo Hamming ultrarrápido; usar con rescore 3×–5× (ideal ≥1024 dim) |
3. Comparativa estratificada de bases y motores
3.1 Bases de datos vectoriales nativas dedicadas
| Producto | Licencia / Despliegue | Lenguaje y almacenamiento | Índices y capacidades | Encaje ideal |
|---|---|---|---|---|
| Qdrant | Apache 2.0 / Self-hosted & Cloud | Rust; en memoria, mmap en disco y cuantización en disco | HNSW + SQ8/BQ; vectores dispersos nativos e índices rápidos de payload | Servicio independiente de alto QPS, multi-tenant y filtros complejos |
| Milvus | Apache 2.0 / Distribuido & Zilliz Cloud | Control plane en Go + ejecución C++; object storage + MQ desacoplados | IVF, HNSW, DiskANN, GPU CAGRA; particiones multi-tenant | Plataformas empresariales de escala mil millones |
| Weaviate | BSD-3-Clause (algunos extras enterprise cerrados) | Go; object storage + índice invertido integrados | HNSW + cuantización dinámica/PQ/BQ; GraphQL/REST, módulos vectorizadores | Apps RAG con pipeline de embeddings integrado |
| Chroma | Apache 2.0 / Embebida & Client-Server | Núcleo Python / Rust; SQLite + almacenamiento local o distribuido | HNSW; API mínima, estrecha integración con LangChain / LlamaIndex | Prototipado rápido y RAG en Python pequeño/mediano |
| LanceDB | Apache 2.0 / Embebida & Enterprise | Rust; formato columnar Lance y Apache Arrow | IVF-PQ, HNSW, DiskANN; I/O zero-copy, multimodal nativo (audio/vídeo/tablas) | Apps locales embebidas, lectura serverless en S3, data lakes multimodales |
| Pinecone | SaaS Serverless propietario | Motor distribuido gestionado (de Pods a Serverless) | Índice propietario desacoplado; híbrido sparse-dense, aislamiento por Namespace | Equipos cloud cero-ops que priorizan simplicidad gestionada |
| Turbopuffer | SaaS propietario / BYOC | Rust; object storage (S3/GCS) como verdad + caché NVMe/RAM | Índice por centroides (tipo SPFresh) evitando saltos aleatorios I/O; texto + vector | Datos masivos fríos/tibios (ej. indexación de código) a coste mínimo |
3.2 Bibliotecas de búsqueda vectorial (no son BD completas)
| Producto | Licencia | Alcance y límites | Casos de uso |
|---|---|---|---|
| FAISS (Meta) | MIT | Biblioteca de búsqueda C++ / Python (sin persistencia de metadatos, transacciones distribuidas ni servidor auth); CPU SIMD y multi-GPU | Cálculo batch offline, investigación ML, núcleo embebido en motores propios |
3.3 Extensiones de bases de datos y buscadores tradicionales
| Producto | Base | Indexación y capacidades vectoriales | Fortalezas y límites |
|---|---|---|---|
| pgvector | Extensión PostgreSQL (incl. Supabase) | Tipos vector / halfvec / sparsevec / bit; HNSW e IVFFlat |
Pros: ACID, JOIN SQL, cero nueva operación; Contras: amplificación de escritura y presión RAM >10M–50M filas |
| Elasticsearch / OpenSearch | Índice invertido Lucene + HNSW | Híbrido nativo Dense Vector + BM25, fusión RRF, filtros anidados | Pros: reutiliza equipos de búsqueda actuales; Contras: alto uso de RAM off-heap JVM y merges de segmentos |
| Redis (Query Engine) | Almacén KV en memoria | Flat y HNSW, latencia submilisegundo, streaming en tiempo real | Pros: ideal para caché semántica y feature stores; Contras: alto coste RAM a escala |
| MongoDB Atlas Search | BD documental (Atlas / Local CLI) | HNSW sobre Lucene junto a documentos BSON | Pros: evita doble escritura doc/vector; Contras: búsqueda principal ligada a Atlas |
| SingleStore | BD SQL HTAP distribuida | SQL + funciones vectoriales nativas (dot / L₂), columnas + filas | Cargas empresariales que mezclan analítica SQL en tiempo real y transacciones |
| Vespa | Motor big-data Apache 2.0 | HNSW + híbrido exacto/aproximado, ranking ML multifase (Tensor/XGBoost/ONNX) | Plataformas masivas de búsqueda/recomendación; mayor curva operativa |
3.4 Servicios cloud totalmente gestionados
| Servicio | Proveedor | Arquitectura y aspectos destacados |
|---|---|---|
| Vertex AI Vector Search (antes Matching Engine) | Google Cloud (GCP) | Basado en ScaNN; actualizaciones streaming a escala de miles de millones e híbrido sparse-dense |
| Amazon OpenSearch Serverless / Aurora pgvector | AWS | Clústeres serverless gestionados y extensiones RDS/Aurora con integración nativa Amazon Bedrock |
| Azure AI Search | Microsoft Azure | Semantic Ranker integrado, pipelines de vectorización y control RBAC empresarial por documento |
4. Estrategias de filtrado y búsqueda híbrida
4.1 Modos de ejecución del filtrado de metadatos
| Estrategia | Orden de ejecución | Fallo típico y mitigación |
|---|---|---|
| Pre-filtering | Evalúa el índice escalar para generar un bitmap de ID y luego ejecuta la búsqueda vectorial | Con filtros muy selectivos (<1 %), el grafo se desconecta; Mitigación: fallback automático a escaneo exacto |
| Post-filtering | Obtiene el Top-K vectorial global y descarta filas que no cumplen el filtro | Devuelve menos de K resultados (o ninguno); Mitigación: nunca usar solo sin gran oversampling |
| Single-stage / Inline | Comprueba dinámicamente el bitmap de filtro en cada salto del grafo HNSW | Estándar actual (Qdrant / Milvus / Weaviate / pgvector 0.8+ iterative scan), equilibrando recall y latencia |
4.2 Reciprocal Rank Fusion (RRF)
Como los puntajes de búsqueda densa y BM25 tienen escalas distintas, RRF combina las listas directamente por rango sin calibración:
RRF_Score(d) = ∑_{r ∈ R} 1 / (k + rank_r(d)) (constante de suavizado estándar k = 60)
5. Fragmentos listos para producción
5.1 Esquema pgvector, HNSW y escaneo iterativo (SQL)
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE documents (
id BIGSERIAL PRIMARY KEY,
tenant_id INT NOT NULL,
content TEXT NOT NULL,
embedding halfvec(1536), -- float16 ahorra 50 % de memoria frente a float32
fts tsvector GENERATED ALWAYS AS (to_tsvector('simple', content)) STORED
);
CREATE INDEX idx_docs_emb_hnsw ON documents
USING hnsw (embedding halfvec_cosine_ops)
WITH (m = 16, ef_construction = 128);
CREATE INDEX idx_docs_fts ON documents USING gin (fts);
SET hnsw.ef_search = 100;
SET hnsw.iterative_scan = relaxed_order;
SELECT id, content, 1 - (embedding <=> $1::halfvec) AS cosine_sim
FROM documents
WHERE tenant_id = 42
ORDER BY embedding <=> $1::halfvec
LIMIT 10;
Operadores de distancia pgvector:
<->Euclidiana (L₂) ·<=>Distancia coseno (1 - cos) ·<#>Producto interno negativo ·<+>Manhattan (L₁).
5.2 Qdrant: cuantización binaria y filtrado por Payload (Python)
from qdrant_client import QdrantClient, models
client = QdrantClient(url="http://localhost:6333")
client.create_collection(
collection_name="knowledge_base",
vectors_config=models.VectorParams(
size=1536,
distance=models.Distance.COSINE,
on_disk=True,
),
quantization_config=models.BinaryQuantization(
binary=models.BinaryQuantizationConfig(always_ram=True)
),
)
client.create_payload_index(
collection_name="knowledge_base",
field_name="tenant_id",
field_schema=models.PayloadSchemaType.KEYWORD,
)
hits = client.query_points(
collection_name="knowledge_base",
query=[0.012, -0.045, ...],
query_filter=models.Filter(
must=[models.FieldCondition(key="tenant_id", match=models.MatchValue(value="org_a"))]
),
search_params=models.SearchParams(
quantization=models.QuantizationSearchParams(rescore=True, oversampling=3.0)
),
limit=10,
).points