Bases de datos vectoriales

Una base de datos vectorial almacena embeddings y responde una pregunta muy concreta muy rápido: “¿cuáles son los k vectores más parecidos a este?” Es la infraestructura sobre la que corren la búsqueda semántica y el RAG.

El problema que resuelven

Comparar la consulta contra todos los vectores uno por uno (búsqueda exacta) no escala a millones de documentos. Por eso usan índices ANN (Approximate Nearest Neighbor): sacrifican un poco de exactitud a cambio de respuestas en milisegundos. Algoritmos típicos: HNSW, IVF.

Qué ofrecen además del vector

En producción casi nunca buscas solo por similitud. Estas bases añaden:

• Filtros por metadatos: limitar por fecha, autor, permisos, colección.
• Búsqueda híbrida: combinar similitud vectorial con keyword.
• Actualización incremental: insertar/borrar sin reindexar todo.

El panorama (para elegir)

• Dedicadas: Pinecone, Qdrant, Weaviate, Milvus.
• Extensión sobre tu base actual: pgvector (PostgreSQL), Redis, Elasticsearch/OpenSearch.
• Embebidas / locales: Chroma, FAISS (librería, no servicio).

[!TIP] Si ya usas Postgres y tu volumen es moderado, pgvector suele ser suficiente y te ahorra una pieza de infraestructura. No metas una base vectorial dedicada por defecto.

Errores comunes

• Sobredimensionar: montar Pinecone para 5.000 documentos cuando pgvector bastaba.
• Ignorar el coste del reindexado al cambiar de modelo de embedding.
• No versionar el índice: cuando cambias chunking o modelo, necesitas poder reconstruirlo.

Temas relacionados

Guardan vectores y sirven a búsqueda semántica y RAG.