Base de datos vectorial: qué es, para qué sirve y cómo elegirla

Publicado: 2026-03-09 · Actualizado: 2026-10-28

Por Goiko, Founder & AI Solutions CTO de GUGŌ Creative

Qué es una base de datos vectorial (vector database), cómo funciona con embeddings, su papel en RAG, cuándo basta pgvector y cómo elegir la adecuada.

Una base de datos vectorial (vector database) almacena embeddings —listas de números que representan el significado de un texto, una imagen o un producto— y encuentra rápidamente los más parecidos a una consulta. Eso permite la búsqueda semántica: recuperar contenido por lo que significa, aunque no comparta palabras con la pregunta. En inteligencia artificial, su uso principal es la recuperación en los sistemas RAG, donde selecciona los fragmentos de documentación que el modelo de lenguaje usa para responder.

La necesitas cuando tu documentación no cabe en el contexto del modelo y las preguntas llegan en lenguaje natural, sobre todo si además hay que filtrar por permisos, fechas o departamentos. Si ya usas PostgreSQL y el volumen es moderado, empieza con la extensión pgvector; pasa a una base vectorial dedicada —Qdrant, Weaviate, Milvus o Pinecone— cuando el volumen, los filtros o la operación lo justifiquen. En el presupuesto pesa poco: un asistente con RAG cuesta entre 10.000 y 25.000 €, y la base vectorial es solo una de sus piezas.

A continuación tienes cómo funciona, su papel en RAG, una tabla comparativa con la búsqueda por palabras clave y pgvector, criterios para elegir, ejemplos y costes.

Qué es una base de datos vectorial

Para entenderla hay que empezar por los embeddings. Según la guía de embeddings de OpenAI, un embedding es un vector de números de coma flotante, y la distancia entre dos vectores mide cuánto se relacionan. Lo genera un modelo de embeddings, distinto del que redacta las respuestas: textos que tratan de lo mismo obtienen vectores cercanos aunque usen palabras distintas. Su tamaño depende del modelo: en esa misma guía, text-embedding-3-small devuelve por defecto 1.536 dimensiones y text-embedding-3-large, 3.072, reducibles con el parámetro «dimensions».

Una base de datos vectorial guarda cada vector junto al texto original y sus metadatos —fuente, fecha, departamento, permisos— y, dado el vector de una pregunta, devuelve los más próximos. Comparar la pregunta con todos uno a uno es exacto, pero lento con millones de vectores; por eso estas bases usan índices de vecinos más próximos aproximados (ANN).

Búsqueda exacta y búsqueda aproximada

La documentación de pgvector lo explica con claridad: por defecto hace búsqueda exacta, con recall (exhaustividad) perfecto, y con un índice aproximado cambia algo de recall por velocidad. Ofrece dos índices: HNSW, con mejor equilibrio entre velocidad y recall, a cambio de una construcción más lenta y más memoria, e IVFFlat, que se construye antes y ocupa menos, con peor rendimiento de consulta. HNSW es un grafo jerárquico descrito por Malkov y Yashunin que implementan, entre otros, pgvector, Qdrant y Milvus. «Aproximado» significa que a veces no devolverá el fragmento más parecido, y por eso la recuperación se mide con preguntas reales.

Cómo se mide la similitud

Las métricas habituales son la distancia coseno, el producto interno y la distancia euclídea; pgvector admite además L1, Hamming y Jaccard. OpenAI recomienda la similitud coseno para sus embeddings y advierte de que la elección no suele cambiar mucho el resultado.

Para qué sirve una base de datos vectorial en IA y en RAG

Su uso más extendido es la recuperación en RAG (generación aumentada por recuperación). El término procede del artículo de Lewis et al. (2020), que combinaba un modelo generativo con un índice vectorial denso de la Wikipedia. En un sistema empresarial, el índice contiene la documentación propia y el flujo es este:

1. Ingesta: se recogen los documentos vigentes —manuales, políticas, fichas, contratos— y se trocean en fragmentos con sentido propio.
2. Embeddings: cada fragmento pasa por el modelo de embeddings y se guarda con su texto y sus metadatos.
3. Consulta: la pregunta del usuario se convierte en vector con el mismo modelo.
4. Recuperación: la base de datos devuelve los fragmentos más próximos, filtrados por permisos, fecha o tipo de documento; opcionalmente, un segundo modelo los reordena.
5. Respuesta: el modelo de lenguaje responde a partir de esos fragmentos y cita de dónde sale cada dato.

La base vectorial resuelve la parte de encontrar; la calidad final depende también del troceado, del modelo de embeddings y de la evaluación. La arquitectura completa está en cómo funciona un sistema RAG, y la diferencia con reentrenar el modelo, en fine-tuning o RAG.

Fuera de RAG, la misma técnica sirve para:

• Búsqueda semántica en una intranet o un helpdesk: «anular un pedido» encuentra el procedimiento de cancelación.
• Recomendaciones de productos o contenidos parecidos.
• Detección de duplicados en tickets, leads o fichas que dicen lo mismo con otras palabras.

Búsqueda vectorial, por palabras clave e híbrida

La búsqueda vectorial no sustituye a la búsqueda por palabras clave. La de texto completo, como la de PostgreSQL, reduce las palabras a su forma base, ordena por relevancia y se acelera con índices. Es la mejor opción para referencias de producto, nombres propios o números de expediente, donde importa la coincidencia exacta. La vectorial gana cuando el usuario pregunta con palabras distintas a las del documento.

Por eso muchos sistemas combinan ambas. Weaviate define la búsqueda híbrida como la combinación de búsqueda vectorial y por palabras clave (BM25), con un parámetro alpha que fija el peso de cada una; Qdrant fusiona por defecto por rango recíproco (RRF) y aconseja no tocar los pesos salvo que una evaluación demuestre la mejora. En las pruebas que publicó Anthropic sobre recuperación contextual, combinar embeddings contextuales y BM25 contextual redujo un 49 % la tasa de fallos de recuperación entre los 20 primeros fragmentos, y un 67 % al añadir reordenación.

Tabla comparativa: palabras clave vs pgvector vs base de datos vectorial dedicada

Cuándo necesitas una base de datos vectorial (y cuándo no)

Señales de que la necesitas

• Tu documentación no cabe en el contexto del modelo, o meterla entera en cada petición es caro y lento.
• Las preguntas llegan en lenguaje natural y no coinciden con las palabras de los documentos.
• Hay muchos documentos y la búsqueda debe filtrarse por permisos, cliente, departamento o vigencia.
• El contenido cambia y quieres actualizarlo sin reentrenar ningún modelo.
• Necesitas encontrar elementos parecidos, no solo idénticos.

Cuándo no hace falta

• La base de conocimiento es pequeña. Anthropic indica que, por debajo de unos 200.000 tokens, se puede incluir entera en el prompt sin RAG; compara aun así coste y latencia con tu volumen de consultas.
• Las búsquedas son por campos estructurados. Buscar por NIF, fecha, estado o referencia es trabajo de SQL.
• Estás validando la idea. En una prueba de concepto puedes empezar con pocos documentos en el contexto y añadir la base vectorial cuando el caso demuestre valor.
• No hay datos propios que recuperar. Si el asistente solo usa el conocimiento general del modelo, no hay nada que indexar.

Cómo elegir una base de datos vectorial

Antes de comparar productos, responde a estas preguntas con datos de tu caso:

1. ¿Cuántos fragmentos tendrás y cómo crecerán? No es lo mismo un manual que todo el archivo documental de la empresa.
2. ¿Qué filtros son obligatorios? Si cada consulta debe respetar permisos, comprueba cómo combina cada opción filtros y búsqueda aproximada.
3. ¿Necesitas búsqueda híbrida? Si los usuarios buscan referencias, códigos o nombres, sí.
4. ¿Quién la va a operar? Un servicio gestionado reduce trabajo de sistemas; una instalación propia da más control sobre dónde están los datos.
5. ¿Hay datos personales? Entonces el proveedor actúa como encargado del tratamiento y la región de alojamiento importa.
6. ¿Qué recall y qué latencia necesitas? Mídelo con tus documentos y tus preguntas; las comparativas de los fabricantes son solo orientativas.

pgvector: la opción por defecto si ya usas PostgreSQL

pgvector guarda los vectores junto al resto de los datos y se consulta con SQL, así que permisos, uniones y copias de seguridad siguen en un solo sitio. Su documentación avisa de dos detalles: los índices aproximados aplican los filtros después del escaneo, por lo que una consulta muy filtrada puede devolver menos filas de las pedidas (desde la versión 0.8.0, los escaneos iterativos lo mitigan), y el tipo vector solo se indexa hasta 2.000 dimensiones. Con un modelo de 3.072, como text-embedding-3-large, hay que usar halfvec, que llega a 4.000, o reducir dimensiones.

Bases de datos vectoriales dedicadas

• Qdrant (documentación): código abierto o servicio gestionado; con los campos indexados, filtra por metadatos dentro del recorrido del índice HNSW.
• Weaviate (documentación): búsqueda híbrida nativa que combina vectores y BM25 con un peso ajustable.
• Milvus (documentación): código abierto, desde Milvus Lite para prototipos hasta Milvus Distributed sobre Kubernetes; admite BM25 y vectores dispersos.
• Pinecone (documentación): índices serverless, namespaces para separar clientes, filtros por metadatos y vectores densos y dispersos.

Ejemplos de uso en empresa

Los escenarios siguientes son hipotéticos e ilustrativos, no casos de clientes.

Asistente sobre documentación técnica

Un fabricante quiere que su equipo de soporte consulte manuales y fichas técnicas. Como ya usa PostgreSQL, indexa los fragmentos con pgvector y los combina con búsqueda de texto completo, porque muchas preguntas incluyen referencias de pieza que la búsqueda semántica sola no distingue bien.

Buscador de contratos con permisos

Un departamento legal quiere localizar cláusulas parecidas entre cientos de contratos, pero cada área solo puede ver los suyos. El diseño empieza por los metadatos —área, contraparte, vigencia— y por cómo se aplican esos filtros en cada consulta; la elección de la base vectorial viene después.

Tickets duplicados en soporte

Un equipo de soporte agrupa incidencias que describen el mismo problema con palabras distintas antes de asignarlas. No interviene ningún modelo generativo: solo embeddings, búsqueda por similitud y un umbral que se ajusta revisando ejemplos.

Errores frecuentes al implantar una base de datos vectorial

• Elegir la herramienta antes que el caso de uso. Primero, qué datos, cuántos, qué filtros y qué preguntas; después, el producto.
• Trocear mal los documentos. Los fragmentos largos mezclan temas y los cortos pierden contexto: respeta secciones, artículos y tablas, y evalúa.
• Guardar vectores sin metadatos. Sin fuente, fecha y permisos no puedes filtrar, citar ni auditar.
• Cambiar de modelo de embeddings sin reindexar. Los vectores de modelos distintos no son comparables: hay que regenerar todo el índice.
• Confiar solo en la búsqueda semántica. Para códigos y nombres propios, añade búsqueda por palabras clave.
• No evaluar ni actualizar. Mide con preguntas de referencia si los fragmentos correctos salen entre los primeros, y reindexa cuando cambien los documentos; las estrategias están en testing de sistemas de IA.

Cuánto cuesta una base de datos vectorial en un proyecto de IA

La base vectorial rara vez es la partida principal: se presupuesta el sistema completo, con ingesta, permisos, búsqueda, evaluación, interfaz e integraciones. Estos son los rangos de nuestro informe de precios de software e IA 2026:

• Chatbot o asistente con RAG: 10.000-25.000 €, en 4-8 semanas.
• Copiloto interno con RAG y permisos por rol: 20.000-50.000 €, en 6-12 semanas.
• Automatización con IA de un flujo acotado: 10.000-20.000 €, en 4-6 semanas, por ejemplo para clasificar documentos con revisión humana.

Los costes recurrentes son el uso de modelos por API, desde unos 100 € al mes con poco volumen y entre 2.000 y 5.000 € al mes con volumen alto; la infraestructura cloud, entre 50 y 500 € al mes, donde entra la base vectorial; y el mantenimiento, entre el 15 y el 25 % del coste de desarrollo al año. El desglose está en cuánto cuesta automatizar procesos con IA.

Preguntas frecuentes

¿Qué es una base de datos vectorial en pocas palabras?

Es una base de datos que guarda embeddings —representaciones numéricas del significado de textos, imágenes o productos— y encuentra los más parecidos a una consulta. Permite buscar por significado y no solo por palabras exactas.

¿En qué se diferencia una base de datos vectorial de una SQL?

Una base SQL responde consultas exactas sobre campos: este cliente, esta fecha, este estado. Una base vectorial responde consultas por similitud: los fragmentos más parecidos a esta pregunta. Son complementarias y, con pgvector, conviven en el mismo PostgreSQL.

¿Hace falta una base de datos vectorial para hacer RAG?

Hace falta un mecanismo de recuperación, que suele ser búsqueda vectorial, a menudo combinada con palabras clave. Si la documentación es pequeña, puede bastar con incluirla en el contexto; si ya usas PostgreSQL, pgvector cubre muchos casos sin otro servicio.

¿pgvector es suficiente o necesito Pinecone, Qdrant o Weaviate?

Para muchos proyectos empresariales, pgvector basta y es más sencillo de operar. Una base dedicada compensa con mucho volumen, filtros complejos, multitenencia o requisitos de rendimiento que pgvector no cumpla en tus pruebas.

¿Qué pasa si cambio de modelo de embeddings?

Hay que regenerar los embeddings de todos los documentos, porque los vectores de modelos distintos no son comparables. Conviene guardar el texto original y prever esa reindexación desde el principio.

Lecturas relacionadas

• Sistemas RAG para empresas
• Cómo funciona un sistema RAG
• Copilotos internos con RAG para consultar documentación
• Cómo preparar los datos de tu empresa para IA