Capítulo 4 — Elegir la base de datos vectorial correcta

Cuarta entrega del recorrido capítulo por capítulo de LLM Primer III: Enhancing Enterprise AI with RAG. La parte de un sistema RAG que más rápido crece, que más cuesta a escala y que con más fuerza encierra al equipo — elegida por méritos técnicos y decidida por consideraciones operativas.

Por qué existe este capítulo

La base de datos vectorial es la capa de almacenamiento del sistema de recuperación, y la elección es una decisión multi-eje — rendimiento, residencia de datos, la forma operativa del equipo, el coste total de propiedad durante la vida útil del sistema. Una elección equivocada te encierra durante años, porque mover mil millones de embeddings entre sistemas es un proyecto que ningún equipo emprende a la ligera. Las comparaciones técnicas son útiles, pero la elección normalmente se decide en los tres ejes que las comparaciones técnicas obvian: dónde se permite que vivan los datos, qué puede operar el equipo y cuánto cuesta el sistema durante su vida útil.

4.1 Arquitecturas: dedicadas frente a extensiones

La primera decisión, a menudo sin nombrar, es entre adoptar un sistema nuevo dedicado a cargas vectoriales y extender un sistema que el equipo ya opera. Una base de datos dedicada — Pinecone, Qdrant, Milvus, Weaviate, Vespa — está diseñada desde el índice hacia fuera. Planificador de consultas, layout de almacenamiento, modelo de replicación y API están todos diseñados para consultas approximate nearest-neighbor sobre vectores de alta dimensión. Techos de rendimiento más altos, especialmente en consultas híbridas de filtro más vector; otro sistema que operar.

Un enfoque de extensión — pgvector, Elasticsearch dense_vector, MongoDB Atlas Vector Search, Redis con RediSearch — añade búsqueda vectorial a una base de datos que el equipo ya corre. Sin nueva autenticación, ni nuevo procedimiento de backup, ni nueva rotación de guardia, ni cadencia de parches. El techo de rendimiento lo fija la arquitectura del anfitrión y normalmente está muy por encima de lo que requieren las aplicaciones por debajo de la franja de decenas de millones de vectores. La decisión rara vez es una pregunta pura de rendimiento. Es más a menudo una pregunta sobre dónde está dispuesto el equipo a gastar su presupuesto operativo — un equipo que corre una Postgres no quiere operar una segunda; un equipo que corre diez servicios de datos no parpadea por un undécimo.

4.2 Líderes gestionados: Pinecone y Vertex

Pinecone es la base de datos vectorial gestionada canónica. Simplicidad operativa, latencia predecible, un SDK maduro y un tier serverless que desacopla almacenamiento de cómputo y cobra por uso real en lugar de por capacidad provisionada. El valor por defecto correcto para nuevos despliegues, salvo que la carga se beneficie específicamente de capacidad reservada. El precio es el lock-in arquitectónico que arrastra cualquier sistema propietario gestionado — los embeddings son portables en principio, pero el coste de exportar y reindexar es real. Vertex AI Vector Search es la oferta de Google, construida sobre la librería ScaNN que impulsa la búsqueda por similitud a gran escala del propio Google. Techo de escala más alto, integración estrecha con el resto de GCP — modelos de embedding, IAM, Cloud Monitoring — y el compromiso estratégico correspondiente con una única nube. Azure AI Search ocupa la misma posición para equipos comprometidos con Microsoft. La elección entre las tres opciones nativas de plataforma suele seguir al compromiso de nube existente, lo cual es razonable mientras el equipo haya verificado escala y residencia.

4.3 Open-source: Qdrant, Milvus, Weaviate

La categoría open-source es para equipos que quieren controlar su propia infraestructura — por coste, por residencia o por razones estratégicas — y tienen capacidad operativa para correr sistemas distribuidos. Qdrant es el más pequeño y el más enfocado: escrito en Rust, desplegable como binario único, diseñado para búsqueda vectorial de baja latencia con buen soporte de filtrado y cuantización. Lo bastante accesible para estar corriendo en minutos; la elección correcta para la huella operativa más pequeña posible. Milvus es el más grande y el más orientado a empresa — arquitectura cloud-native que separa cómputo, almacenamiento y metadatos, con el techo de escala más alto de la categoría (corpus a escala de mil millones, índices acelerados por GPU, almacenamiento por niveles). Complejidad operativa significativa, mitigada por Zilliz Cloud. Weaviate se sitúa entre los dos — más rico en funcionalidades que Qdrant, menos complejo que Milvus, con módulos integrados para embedding, reranking y multi-tenancy. Una plataforma de búsqueda más que un índice de búsqueda. Los tres son Apache en su núcleo con ofertas gestionadas de pago, y los benchmarks están dentro de un factor constante pequeño entre ellos. La decisión es ajuste, no rendimiento crudo.

4.4 Embebido y Postgres: Chroma y pgvector

La mayoría de los despliegues reales de RAG sirven decenas de consultas por segundo sobre unos cientos de miles de vectores, no millones por segundo sobre miles de millones. Para estas cargas la herramienta correcta corre dentro del proceso de la aplicación o junto a él. Chroma es la opción embebida — en proceso por defecto, persiste a disco local, el caso más simple no requiere configuración. Correcta para prototipos, herramientas que se entregan con sus propios datos y despliegues de producción que caben en una sola máquina. pgvector añade un tipo vector, operadores de distancia e indexación HNSW/IVFFlat a Postgres. Para corpus hasta unos diez millones de vectores en un anfitrión bien provisionado, pgvector es una elección de producción creíble y la opción operativamente más simple para equipos que ya corren Postgres. La búsqueda vectorial se vuelve una consulta SQL contra una tabla que el ORM existente entiende; las joins con metadatos estructurados son de primera clase. La virtud oculta de estas opciones es que bajan el coste de cambiar de opinión — la migración a un sistema distribuido, si llega, queda acotada.

4.5 Residencia, operaciones y coste — los ejes que de verdad deciden

Los tres ejes operativos merecen tener nombre porque son donde las decisiones de producción se deciden de verdad. La residencia de datos estrecha la lista de candidatos antes de que ninguna comparación técnica sea significativa. Protección de datos de la UE, regulación de servicios financieros, compromisos de nube soberana — estas restricciones no son negociables, y la primera pregunta a cualquier proveedor es qué regiones soporta y cuáles son sus compromisos contractuales de tratamiento de datos. Un escollo en particular: los embeddings son datos derivados, pero siguen siendo datos personales bajo la mayoría de los marcos regulatorios, porque pueden invertirse o usarse para recuperar el original vía búsqueda por similitud. Un contrato que cubre documentos en bruto pero es ambiguo sobre embeddings está incompleto.

La forma operativa es la propia capacidad del equipo. Un equipo de tres ingenieros corriendo un único servicio de aplicación debería elegir la opción que añada la menor superficie operativa — pgvector, un Pinecone o Qdrant Cloud gestionado, Chroma embebido. Un equipo de treinta puede absorber la complejidad de un sistema distribuido open-source por las ventajas de coste y capacidad. El error es elegir un sistema que no encaja con la capacidad real del equipo para operarlo. El coste total a lo largo de la vida del sistema incluye aprovisionamiento, monitorización, backup, simulacros de restore, planificación de capacidad, trabajo de actualización y el coste proporcional del tiempo de guardia. El planteamiento honesto pregunta el coste en tres escenarios — carga actual, 10x, 100x — porque la pendiente de la curva importa tanto como el punto de partida.

Lo que prepara el Capítulo 4

La base de datos vectorial determina qué puede contener la capa de almacenamiento, qué tan rápido puede consultarse y qué patrones de filtro y metadatos soporta. Ninguna de estas propiedades decide por sí sola la calidad de la recuperación — deciden lo que se puede construir encima. Lo que se construye encima es la pipeline de recuperación, donde las ganancias se componen: búsqueda híbrida combinando vectores densos con BM25, reciprocal rank fusion sobre retrievers heterogéneos, reranking con cross-encoder y la capa de comprensión de consultas que tiende el puente entre cómo preguntan los usuarios y cómo responden los documentos.

Próximamente — Capítulo 5: Arquitectura de la pipeline de recuperación. Cómo la búsqueda vectorial densa y la recuperación por palabras clave se combinan a través de reciprocal rank fusion, el paso de reranking con cross-encoder que cierra la mayor parte del hueco de calidad restante y la capa de comprensión de consultas que hace el resto.