Referencia rápida

Bases de datos vectoriales y arquitectura de recuperación: hoja de trucos (conceptos, índices, cuantización y selección)

Guía de referencia compacta sobre bases de datos vectoriales y búsqueda semántica: métricas de distancia, índices ANN (HNSW, IVF, DiskANN, ScaNN), cálculo de memoria por cuantización, filtrado inline, búsqueda híbrida RRF y comparativa por niveles de motores nativos, extensiones y servicios cloud.

· Publicado

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ípico 16–64): mayor M mejora el recall en alta dimensión, pero eleva RAM y tiempo de construcción.
  • efConstruction (tamaño de lista candidata al construir, típico 100–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

Temas relacionados