📌 En resumen
Una base de datos vectorial almacena información como vectores numéricos para encontrar contenido por similitud semántica, no por coincidencia exacta de palabras. Es la pieza que hace posible que un chatbot RAG encuentre el párrafo correcto de tu manual técnico cuando alguien pregunta por un proceso, aunque la pregunta no use exactamente las mismas palabras que el manual.
¿Por qué la búsqueda por palabras clave ya no basta?
La búsqueda tradicional por palabras clave (como la que usa un CTRL+F o un motor de búsqueda básico) solo encuentra coincidencias exactas o muy próximas. Si tu manual dice 'procedimiento de reinicio del sistema' y alguien pregunta 'cómo reiniciar el servidor', la búsqueda por palabras clave puede no encontrar la respuesta correcta. La búsqueda vectorial convierte ambas frases en vectores numéricos y mide la similitud matemática entre ellos.
| Característica | Búsqueda por palabras clave | Búsqueda vectorial |
|---|---|---|
| Coincidencia | Exacta o aproximada por texto | Semántica (por significado) |
| Sinónimos | No los reconoce | Los reconoce automáticamente |
| Preguntas en lenguaje natural | Pobre rendimiento | Muy buen rendimiento |
| Velocidad (gran escala) | Rápida | Requiere optimización (índices ANN) |
| Facilidad de implementación | Simple | Requiere modelo de embeddings |
¿Cómo funciona una base de datos vectorial?
- 1Los documentos se dividen en fragmentos (chunks) de 300-800 tokens
- 2Cada chunk se pasa por un modelo de embeddings que lo convierte en un vector (lista de ~1500 números)
- 3Los vectores se almacenan en la base de datos vectorial con metadatos (título, fuente, fecha)
- 4Cuando el usuario hace una pregunta, esta también se convierte en vector
- 5La BD vectorial calcula la similitud entre el vector de la pregunta y todos los vectores almacenados
- 6Devuelve los K fragmentos más similares (top-k)
- 7El LLM recibe la pregunta + los fragmentos recuperados y genera la respuesta
ℹ️ Nota
El modelo de embeddings determina la calidad de la búsqueda. text-embedding-3-small de OpenAI y los modelos de Cohere son buenos puntos de partida para español. Para privacidad total, modelos open source como multilingual-e5-large funcionan en local.
Comparativa de bases de datos vectoriales para empresa
| Herramienta | Tipo | Mejor para | Precio | Hosting |
|---|---|---|---|---|
| Pinecone | SaaS managed | Escala sin gestión de infra | €€ (por índice/vector) | Cloud |
| Weaviate | Open source / managed | Flexibilidad + metadatos ricos | € open source / €€ cloud | Self-hosted o cloud |
| pgvector | Extensión PostgreSQL | Volúmenes medianos, stack existente | € (incluido en Postgres) | Self-hosted |
| Chroma | Open source | Prototipado y desarrollo local | Gratis | Local / Self-hosted |
| Qdrant | Open source / managed | Alta performance, filtros avanzados | € open source / €€ cloud | Ambos |
| Azure AI Search | SaaS Microsoft | Ecosistema Azure/Microsoft 365 | €€€ | Cloud Azure |
¿Cuándo NO necesitas una base de datos vectorial dedicada?
- Colección pequeña de documentos (menos de 50.000 fragmentos): pgvector es suficiente
- Prototipo o prueba de concepto: Chroma en local es más ágil
- Ya tienes Elasticsearch o OpenSearch: ambos tienen soporte vectorial nativo desde 2024
- Stack Azure: Azure AI Search incluye búsqueda vectorial sin infraestructura adicional
💡 Consejo
Si ya tienes PostgreSQL en producción, instala pgvector antes de evaluar soluciones dedicadas. Para la mayoría de casos de uso empresariales con documentos internos (menos de 500.000 fragmentos), pgvector rinde muy bien y elimina una pieza de infraestructura adicional.
¿Cómo elegir tu base de datos vectorial?
- Volumen: cuántos documentos y fragmentos vas a indexar ahora y en 2 años
- Privacidad: ¿los datos pueden salir de tu infraestructura? Si no, descarta SaaS cloud
- Equipo técnico: ¿hay alguien para gestionar infraestructura self-hosted?
- Stack existente: PostgreSQL → pgvector, Azure → AI Search, Databricks → Delta Lake con vectores
- Presupuesto: open source vs managed tiene un impacto significativo a escala
Comparativa detallada: Pinecone, Weaviate, pgvector y Chroma en 2025
La tabla simplificada de herramientas cubre el qué. Esta comparativa entra en los criterios que realmente importan cuando hay que tomar una decisión: precio concreto, límites del tier gratuito, latencia, y capacidades de filtrado que determinan si la herramienta cubre tu caso de uso.
| Criterio | Pinecone | Weaviate | pgvector | Chroma |
|---|---|---|---|---|
| Modelo de despliegue | SaaS managed (serverless o pod-based) | Self-hosted (open source) o Weaviate Cloud | Extensión de PostgreSQL, self-hosted | Open source, local o self-hosted |
| Precio aproximado 2025 | Serverless: desde 0,08 $/M lecturas + 0,05 $/M escrituras. Pod-based: desde ~70 $/mes por pod | Self-hosted: gratis. Cloud: desde 25 $/mes (Sandbox), enterprise bajo contrato | Incluido en PostgreSQL: 0 € de licencia adicional. Coste = infra de PostgreSQL | Open source: gratis. No hay plan cloud oficial (se gestiona en tu infra) |
| Límite tier gratuito | 1 índice serverless con hasta 2M vectores en el plan Starter (con restricciones de acceso) | 14 días de prueba en Weaviate Cloud. Self-hosted sin límite. | Sin límite (depende del disco disponible en PostgreSQL) | Sin límite (local). Sin plan cloud oficial. |
| Latencia típica en consulta | 10-50 ms en serverless para colecciones medianas (<5M vectores) | 5-30 ms en self-hosted con hardware adecuado; similar en cloud | 20-100 ms para <1M vectores. Escala peor con millones de vectores | 5-50 ms en local. No diseñado para producción de alta concurrencia |
| Filtrado por metadatos | Sí, filtros combinados con búsqueda vectorial (pre y post-filtering) | Sí, filtros donde-cláusula nativos, muy potentes y flexibles | Sí, con SQL estándar combinado con el operador de similitud (<->) | Sí, filtros básicos por metadatos en la consulta |
| Multimodalidad | No nativa (solo vectores de texto/imagen pre-generados) | Sí, módulos nativos para texto, imagen y audio con CLIP y otros modelos | No nativa (almacena cualquier vector, pero no genera embeddings multimodales) | No nativa |
| Ideal para | RAG en producción sin querer gestionar infra, volúmenes de 1M-50M vectores | RAG con metadatos ricos, casos multimodales, control total sobre el stack | Empezar con RAG sobre PostgreSQL existente, volúmenes <500K vectores | Desarrollo local, pruebas de concepto, aprendizaje |
💡 Consejo
Si tu empresa ya tiene PostgreSQL en producción y estás en las primeras fases de un proyecto RAG, instala pgvector antes de evaluar cualquier otra opción. El coste es cero, la integración con tu stack existente es inmediata y para la mayoría de casos de uso con documentos internos (menos de 500.000 fragmentos) el rendimiento es perfectamente adecuado.
¿Cómo es el pipeline de PDF a vector?
La base de datos vectorial es solo el almacén. El trabajo real está en el pipeline que convierte los documentos en vectores antes de que lleguen ahí. Un pipeline mal diseñado produce resultados pobres aunque la base de datos vectorial sea excelente. Estos son los cuatro pasos del pipeline de indexación con las decisiones concretas en cada uno.
Paso 1: chunking (división del documento en fragmentos)
El chunking es la decisión más infraestimada del pipeline. Si los chunks son demasiado pequeños pierden contexto; si son demasiado grandes, la búsqueda vectorial mezcla información de distintos temas en el mismo fragmento. No hay un tamaño universal: depende del tipo de documento.
| Estrategia de chunking | Tamaño típico | Mejor para | Inconveniente |
|---|---|---|---|
| Por párrafo | 100-300 tokens | Documentos con párrafos bien delimitados: artículos, guías, normativas | Los párrafos cortos pueden perder contexto; los muy largos mezclan ideas |
| Por sección (heading) | 300-800 tokens | Manuales técnicos, documentación con estructura de títulos clara | Requiere parsing estructurado del documento (no sirve extracción de texto plano) |
| Ventana deslizante (sliding window) | 512 tokens con solapamiento de 50-100 tokens | Documentos densos donde el contexto es continuo: contratos, informes financieros | Genera más vectores (más almacenamiento y coste de embedding) |
| Chunking semántico | Variable (agrupa frases por similitud semántica) | Documentos heterogéneos donde los temas cambian sin sección clara | Más complejo de implementar, requiere un paso adicional de clustering |
Paso 2: generación de embeddings
Cada chunk se convierte en un vector usando un modelo de embeddings. La elección del modelo afecta directamente a la calidad de la búsqueda. Para documentos en español, el modelo text-embedding-3-small de OpenAI (1.536 dimensiones, coste aproximado de 0,02 $/M tokens) es la opción más habitual por su equilibrio entre calidad y precio. Para entornos donde los datos no pueden salir de la infraestructura propia, el modelo open source nomic-embed-text o multilingual-e5-large funcionan bien en local sin depender de la API de OpenAI.
Paso 3: ingesta en la base de datos vectorial con metadatos
El vector solo no es suficiente. Junto con cada vector se almacenan metadatos que permiten filtrar antes o después de la búsqueda vectorial: nombre del documento de origen, número de página, fecha de creación, departamento propietario, tipo de documento (contrato, política, manual). Sin metadatos, la búsqueda vectorial devuelve los fragmentos más similares semánticamente pero no puede discriminar por fuente o fecha. En un sistema RAG empresarial, un usuario de finanzas no debería recibir fragmentos de documentos de RR.HH. aunque sean semánticamente próximos a su pregunta: los metadatos de departamento actúan como filtro.
Paso 4: validar la calidad del índice antes de conectar el LLM
Antes de conectar el índice vectorial al LLM, conviene hacer una batería de pruebas de recuperación: lanza 10-20 preguntas representativas y verifica manualmente que los fragmentos recuperados son los que realmente responden la pregunta. Si los resultados son pobres, el problema está en el chunking o en el modelo de embeddings, no en el LLM. Cambiar el LLM cuando el problema es el pipeline de indexación es el error más habitual en proyectos RAG que no funcionan.
Preguntas frecuentes
¿Una empresa pequeña necesita una base de datos vectorial dedicada?
No en la mayoría de los casos. La regla práctica: si tienes menos de 50 documentos (o menos de ~5.000 fragmentos), una búsqueda lexical con BM25 sobre un campo de texto es suficiente y más rápida de implementar. Si tienes entre 50 y 500 documentos (~5.000-50.000 fragmentos), pgvector sobre tu base de datos PostgreSQL existente cubre el caso de uso sin infraestructura adicional y con coste cero de licencia. Si tienes más de 500 documentos con búsqueda en producción con varios usuarios concurrentes, considera Pinecone serverless (desde 0,08 $/M lecturas) o Weaviate Cloud (desde 25 $/mes). El salto a una herramienta dedicada se justifica cuando el volumen crece, cuando necesitas alta disponibilidad o cuando el equipo técnico no quiere gestionar la infraestructura de PostgreSQL a medida que el índice crece.
¿Puedo usar una base de datos vectorial con PostgreSQL?
Sí. pgvector es una extensión de PostgreSQL que añade soporte para vectores y búsqueda por similitud. Es la opción más económica para empezar y funciona bien hasta volúmenes medianos. La ventaja es que se integra en tu base de datos existente sin infraestructura adicional. La desventaja es que escala peor que soluciones dedicadas para millones de vectores.
¿Qué diferencia hay entre embeddings y vectores?
Los embeddings son el proceso de convertir texto (o imágenes, audio) en vectores numéricos. El vector es el resultado: una lista de números (típicamente 768 o 1.536 dimensiones) que representa el significado semántico del texto. Dos textos con significado similar tienen vectores matemáticamente cercanos, lo que permite la búsqueda por similitud.
Siguiente paso recomendado
Copilot RAG para empresa
Implementamos sistemas RAG con la base de datos vectorial adecuada a tus necesidades de privacidad y escala.
Sin compromiso · Respuesta en < 24h
Autor
Fundador y Consultor de Datos e IA
David Aldomar es fundador y consultor principal de MERIDIAN Data & IA, consultora especializada en ayudar a pymes y empresas medianas en España a tomar mejores decisiones con sus datos. Su trabajo se centra en cuatro áreas: diseño e implantación de plataformas de datos (data warehouses, pipelines ETL con dbt, integración de ERPs y CRMs), reporting y dashboards ejecutivos en Power BI, automatización de procesos de negocio con herramientas como n8n, y desarrollo de soluciones de inteligencia artificial aplicada — desde modelos de forecasting de demanda hasta copilots internos basados en RAG con LangChain y FastAPI. Ha liderado proyectos en sectores como logística y transporte, retail y distribución, servicios financieros, manufacturing y construcción, siempre con un enfoque pragmático: diagnóstico corto, entregables concretos y transferencia de conocimiento al equipo del cliente para que sea autónomo desde el primer día. Antes de fundar MERIDIAN, trabajó como ingeniero de datos y BI en entornos empresariales reales: arquitecturas Data Warehouse por capas (Bronze/Silver/Gold), pipelines ETL/ELT en AWS (S3, Glue, Redshift Serverless, Athena) y stacks Microsoft (SQL Server, Power BI, Azure), integrando fuentes tan dispares como ERPs, CRMs y bases de datos operacionales — PostgreSQL, MariaDB — en una única fuente fiable para negocio, finanzas y reporting. Tiene un Máster en Ciencia de Datos e Ingeniería del Dato en la Nube. Su filosofía es que un buen proyecto de datos no se mide por la tecnología que usa, sino por las decisiones de negocio que permite tomar. Escribe regularmente en el blog de MERIDIAN sobre reporting, gobierno del dato, automatización e IA aplicada, con guías prácticas orientadas a responsables de negocio y equipos técnicos de empresas que quieren sacar partido real a sus datos sin depender de grandes consultoras.
Fuentes
Contenido y servicios relacionados
- Guía completa de RAG en empresa
Todo sobre cómo implementar Retrieval-Augmented Generation en empresa.
- Fine-tuning vs RAG en empresa
Cuándo personalizar un LLM y cuándo usar RAG para adaptar IA a tus datos.
- Preparar datos para un proyecto de IA
Qué hacer con tus datos antes de empezar a construir un sistema de IA.
- Arquitectura de datos para empresas: guía completa
Dónde encaja una base de datos vectorial dentro de la arquitectura de datos general de la empresa.