Una base de datos vectorial (vector database) es la pieza que transforma texto, imagen, audio y código en coordenadas matemáticas (embeddings) y permite encontrar lo que es semánticamente parecido, y no solo lo que tiene la misma palabra. Es la base técnica de RAG, búsqueda semántica, recomendación inteligente, deduplicación y casi todo lo que va más allá del keyword search en las aplicaciones modernas con IA.
Esta guía explica qué es un embedding, cómo funciona un vector DB, cómo elegir entre Pinecone, Qdrant, Weaviate, Milvus, pgvector y Chroma, cómo diseñar índices para escala y cómo evitar los errores que destruyen la calidad del RAG en la práctica.
Qué es un embedding y por qué importa
Un embedding es un vector de números (típicamente 768, 1024, 1536 o 3072 dimensiones) que representa el significado de un contenido. Los textos que dicen lo mismo, aun con palabras diferentes, quedan cerca en el espacio vectorial. "Cómo cancelar mi suscripción" y "quiero dejar de pagar" tendrán embeddings vecinos, aunque no compartan ninguna palabra clave.
Los embeddings los generan modelos específicos: OpenAI text-embedding-3, Voyage, Cohere Embed, BGE, Nomic Embed, y variantes especializadas por idioma y dominio. La elección del modelo de embedding tiene un impacto enorme en la calidad del RAG, más de lo que mucha gente imagina.
Qué hace una base de datos vectorial
Tres operaciones son el corazón. 1. Ingesta: recibir un documento, dividirlo en chunks, generar el embedding de cada chunk, almacenarlo con metadatos. 2. Búsqueda por similitud: dado un vector de consulta, retornar los k vectores más cercanos según distancia coseno, producto interno o euclidiana. 3. Filtro híbrido: combinar la similitud vectorial con filtros tradicionales (fecha, autor, categoría, ACL) para obtener resultados útiles.
Por debajo, el motor usa algoritmos como HNSW, IVF, ScaNN o DiskANN para una indexación aproximada que escala a miles de millones de vectores con latencia de milisegundos. La búsqueda exacta en alta dimensión es cara; la gracia del vector DB es entregar un resultado casi exacto con un costo viable.
Comparativo de las principales opciones en 2026
Pinecone: managed, simple, escala fácil, costo alto a partir de cierto volumen. Bueno para empezar rápido. Qdrant: open-source, self-host o cloud, rendimiento excelente, filtros poderosos, soporte para payloads ricos. Favorito de la comunidad. Weaviate: open-source, multimodal, GraphQL nativo, integración con varias fuentes. Milvus: open-source, enfoque en escala (miles de millones de vectores), comunidad china fuerte, más complejo de operar. pgvector: una extensión de Postgres. Ganó una tracción inmensa en 2025 por permitir reusar Postgres como vector DB, con todo lo que eso trae (transacciones, ACID, herramientas conocidas). Chroma: liviano, enfocado en desarrollo local y prototipos, simple de levantar.
La elección depende de tres ejes: volumen (miles vs miles de millones de vectores), operación (managed vs self-host) y requisitos (filtros complejos, multi-tenant, ACL). Para la mayoría de los casos corporativos en 2026, pgvector o Qdrant resuelven de sobra.
Estrategia de chunking
La forma en que divides el documento en chunks determina la calidad del RAG más que cualquier otra decisión. Chunks pequeños (256-512 tokens): precisión alta, contexto limitado, riesgo de perder cohesión. Chunks medios (512-1024 tokens): buen equilibrio para la mayoría de los casos. Chunks grandes (1024-2048 tokens): cohesión alta, costo mayor, diluye la señal.
Patrones avanzados que mejoran resultados: chunking por estructura (párrafo, sección, código), no por conteo ciego; overlap entre chunks para preservar el contexto; parent-child, indexando chunks pequeños pero retornando el chunk padre más grande; contextual chunks, agregando el título y el breadcrumb del documento en cada chunk.
Híbrido: vector + keyword
La búsqueda puramente vectorial pierde en queries específicas con términos exactos (nombre de producto, código, sigla). La búsqueda puramente keyword pierde en queries con paráfrasis. El camino moderno es híbrido: combinar BM25 (keyword) y similitud vectorial, con un re-ranking final. Herramientas como Qdrant, Weaviate y Elasticsearch ya ofrecen esto de forma nativa.
En un RAG serio, agregar un re-ranker (Cohere Rerank, Voyage Reranker, BGE Reranker) sobre los top-K iniciales suele elevar la precisión de forma notable, con un costo aceptable.
Operación en producción
Cuatro cuidados que separan un prototipo de la producción. 1. Métricas de retrieval: mide recall@k, precision@k, MRR en conjuntos de evaluación representativos. 2. Reindexación controlada: cambiar el modelo de embedding implica reindexar todo. Ten un pipeline y una versión de embedding por documento. 3. Backup y disaster recovery: el vector DB es la base del producto; trátalo como una base crítica. 4. Control de acceso: un vector DB puede filtrar datos sensibles si los filtros de ACL se aplican mal. Aplica el filtro de permiso en el índice, no solo en la respuesta.
Costo: trampas comunes
El costo de un vector DB suele sorprender. Los culpables frecuentes: los chunks demasiado pequeños multiplican el número de vectores; los embeddings de 3072 dimensiones cuestan 2x de almacenamiento vs 1536; la reindexación por cambio de modelo duplica el costo temporalmente; el cloud managed cobra por solicitud además del almacenamiento. Buenas prácticas: monitorear el costo por feature (no solo el total), cuantización de vectores en índices grandes, tiered storage separando datos "hot" y "cold".
RAG no es solo el vector DB
Un error frecuente es confundir RAG con "instalar un vector DB". El vector DB es una pieza. Un buen RAG exige un pipeline de ingesta que extrae contenido de PDFs, sitios y bases internas con fidelidad; chunking inteligente; generación de embeddings con el modelo adecuado; retrieval híbrido con filtros y re-ranking; un prompt que inyecta el contexto de la forma correcta; la citación de la fuente en la respuesta; evaluación continua con dataset propio. Saltarse cualquier pieza rompe la calidad.
Cuándo un vector DB no es la respuesta
Para volumen bajo (hasta algunos miles de documentos), un cache en memoria o un índice simple ya resuelven. Para queries con término exacto (id, código, nombre), la búsqueda tradicional con inverted index gana. Para datos tabulares estructurados, SQL sigue siendo imbatible. La regla: usa un vector DB donde la semántica importa y el conjunto es lo bastante grande como para justificar la complejidad. Si no, mantenlo simple.