Infraestructura de recuperación y almacenes vectoriales

Una prueba de concepto de búsqueda vectorial y un sistema en producción que resiste bajo un volumen de consultas real son dos problemas de ingeniería distintos. Construimos y operamos la capa de infraestructura de recuperación que se sitúa bajo tu pipeline de RAG, tus flujos de trabajo agénticos o tu producto de búsqueda semántica: el motor vectorial, el pipeline de embeddings que lo alimenta, la gestión del ciclo de vida del índice que lo mantiene sano y la pila de observabilidad que detecta la degradación de calidad antes de que los usuarios la noten.

Somos neutrales respecto al motor. Nuestra práctica es agnóstica al motor en Qdrant, Milvus, Weaviate, pgvector y Elasticsearch kNN, y cuál recomendamos depende de tu número de vectores, tus patrones de consulta, tus requisitos de multitenencia y tu capacidad operativa.

De una demo de 50.000 vectores a una producción de 200 millones

La brecha entre una demo y un sistema en producción es casi por completo un problema de infraestructura. La demo carga 50.000 vectores en Pinecone, ejecuta una consulta de similitud coseno y devuelve resultados en 40 ms. La producción no se parece en nada a eso.

• 200 millones de vectores y 500 consultas por segundo sostenidas
• 15 dimensiones de filtrado por metadatos y documentos que se actualizan cada hora
• Tres equipos compartiendo un mismo clúster bajo un aislamiento estricto de inquilinos

A esa escala, los picos de compactación de HNSW disparan tu P99 hasta los 800 ms, la exhaustividad se degrada en silencio tras una semana de actualizaciones incrementales, y el pipeline de embeddings no puede seguir el ritmo de cambio de tus documentos. Aquí es donde trabajamos.

La selección del motor es un ejercicio de benchmarking, no una decisión de marca

Todos los proveedores afirman ofrecer un rendimiento de primer nivel; los benchmarks cuentan una historia más matizada. No elegimos una base de datos a partir de una matriz de funciones: cargamos tus vectores reales, ejecutamos tus consultas reales con tus filtros de metadatos reales y medimos la exhaustividad con valores de k operativamente relevantes junto con la latencia P50/P95/P99 bajo carga concurrente.

Los resultados contradicen con frecuencia el marketing de los proveedores. El nivel serverless de Pinecone parece rentable hasta que las cargas sostenidas de QPS elevado empujan el coste de las unidades de lectura más allá del punto de equilibrio del autoalojamiento, y pgvector parece limitado hasta que los escaneos iterativos cierran la brecha de la búsqueda filtrada.

El pipeline de embeddings es donde la recuperación en producción realmente se rompe

Los equipos dedican el 60 % de su esfuerzo de ingeniería de búsqueda vectorial al pipeline, no al almacén. El pipeline se encarga de la ingesta de documentos, la fragmentación, la inferencia del modelo de embeddings, la reindexación incremental ante actualizaciones de documentos y la propagación de metadatos — y cada etapa tiene modos de fallo que degradan en silencio la calidad de la recuperación.

• Conocimiento obsoleto — el segundo fallo más común de RAG en producción. Un documento se actualiza en Confluence pero el índice sigue sirviendo el embedding antiguo. La solución son disparadores de captura de datos de cambios (CDC) que reincrustan de forma incremental, no la reindexación por lotes nocturna.
• Documentos fantasma — un documento de origen se elimina pero su vector permanece, devolviendo resultados de contenido que ya no existe. Dado que las transacciones atómicas entre un sistema de fuente de verdad y un almacén vectorial son casi imposibles en arquitecturas divididas, construimos capas de reconciliación que detectan y purgan los vectores huérfanos.

La selección del modelo de embeddings importa más de lo que la mayoría de los equipos cree, y cambiarlo más tarde es caro: reincrustar 8 millones de documentos cuando actualizas de text-embedding-ada-002 a text-embedding-3-large cuesta días de cómputo y requiere una infraestructura de doble escritura para evitar tiempo de inactividad. Evaluamos los modelos frente a tu conjunto de consultas específico del dominio antes de que te comprometas.

• Cohere embed-v4 — lidera la recuperación multilingüe a 0,01 dólares por millón de tokens en más de 100 idiomas.
• Nomic Embed v2 — 137 millones de parámetros, se ejecuta en CPU, con la mejor relación calidad-tamaño del mercado.
• OpenAI text-embedding-3-large — un sólido todoterreno.

La elección correcta depende de tu mezcla de idiomas, tus requisitos de latencia y de si puedes aceptar una dependencia de API o necesitas inferencia on-premises.

Ciclo de vida del índice: el problema operativo del que nadie te advierte

Los índices HNSW se degradan — no es un error, es una realidad arquitectónica. Con 160 millones de vectores, una reconstrucción completa de HNSW tarda de 3 a 6 horas. Las actualizaciones incrementales vuelven subóptima la estructura del grafo y erosionan la exhaustividad con el tiempo; los eventos de compactación disparan la latencia de consulta; y cada inserción-actualización, eliminación y fusión de segmentos desencadena reconstrucciones de subíndices que consumen CPU en mantenimiento en lugar de en servir consultas. La disyuntiva es ineludible: pasar de una exhaustividad de 0,8 a 0,95 aumenta la latencia de HNSW en aproximadamente un 31 %.

Diseñamos una gestión del ciclo de vida que absorbe la ingesta continua sin pérdida de calidad:

• Rotación de índices azul-verde — reconstruir en una infraestructura separada e intercambiar de forma atómica sin tiempo de inactividad.
• Puertas automatizadas de validación de exhaustividad — comparar un conjunto de consultas de referencia (golden query set) con el índice actual tras cada operación importante; si la exhaustividad cae por debajo del umbral, el intercambio no se produce.
• La construcción de HNSW acelerada por GPU en Qdrant y Elasticsearch reduce los tiempos de reconstrucción en un orden de magnitud, aunque la orquestación de cuándo reconstruir, cómo validar y cómo intercambiar es ingeniería a medida.

La cuantización lleva esto aún más lejos. Qdrant ahora ofrece cuantización de 1,5 bits, 2 bits y asimétrica , y Elasticsearch BBQ reduce el heap en más de un 95 % en comparación con float32. Estas técnicas ahorran memoria y mejoran el rendimiento, pero cada esquema tiene un perfil de exhaustividad diferente frente a distintas distribuciones de datos — por eso caracterizamos el impacto en la exhaustividad sobre tus vectores concretos antes de desplegar la cuantización en producción.

Multitenencia y aislamiento a escala real

Los equipos de plataforma que dan servicio a más de 200 equipos internos de ML, o los productos SaaS con miles de inquilinos de clientes, necesitan una infraestructura que garantice el aislamiento: las consultas del inquilino A nunca deben devolver datos del inquilino B, los registros de auditoría deben rastrear cada consulta hasta una identidad de inquilino, y los inquilinos fríos no deben consumir recursos que los inquilinos activos necesitan.

• Weaviate — el modelo de un shard por inquilino con estados de inquilino (ACTIVE, INACTIVE, OFFLOADED a S3) es la implementación más madura para despliegues con un alto número de inquilinos.
• Milvus — admite aislamiento a nivel de base de datos, colección, partición o clave de partición, ajustando la granularidad a tus requisitos de cumplimiento.

Ambos requieren orquestación a medida a escala — el aprovisionamiento de inquilinos, las transiciones de estado, la gestión de cuotas y la detección de fugas entre inquilinos no los gestiona la propia base de datos. Construimos la capa operativa que hace que la multitenencia sea manejable para despliegues regulados que requieren cumplimiento de SOC 2 o ISO 27001 .

Los flujos de trabajo agénticos están reconfigurando los requisitos de infraestructura

La ola de la IA agéntica cambia lo que deben hacer los almacenes vectoriales. El RAG estático recupera documentos frente a un corpus fijo. Los flujos de trabajo agénticos requieren memoria episódica (historial de conversación y razonamiento intermedio), búsqueda semántica sobre un gran corpus documental, y capas de perfil de usuario — a menudo accediendo a las tres en un solo paso del agente. El requisito de latencia por debajo de 400 ms es más estricto que en el RAG por lotes, y el soporte de transacciones ACID se está volviendo esencial para los agentes de varios pasos que actualizan estado sin escrituras parciales.

Ninguna base de datos vectorial por sí sola gestiona bien las tres capas de memoria, así que los equipos ensamblan arquitecturas multialmacén: Redis para el estado de sesión, Qdrant o Milvus para la búsqueda semántica, y una base de datos de grafos para el seguimiento de relaciones. Unified Memory Core de Oracle (marzo de 2026) intenta converger consultas vectoriales, JSON, de grafos, relacionales y espaciales en un solo motor. Diseñamos la capa de recuperación para sistemas agénticos: qué almacenes gestionan qué tipos de memoria, cómo se enrutan las consultas entre almacenes y cómo se mantiene la consistencia cuando un agente actualiza el estado en varios backends dentro de un único paso de razonamiento.

Lo que entregamos

Cada proyecto comienza con una fase de benchmarking: cargamos tus vectores, ejecutamos tus consultas y producimos recomendaciones de motor cuantificadas. A partir de ahí construimos la infraestructura de producción:

• El clúster del almacén vectorial, con planificación de capacidad y runbooks de escalado.
• El pipeline de embeddings, con reindexación incremental disparada por CDC y gestión de versiones de modelo.
• La automatización del ciclo de vida del índice, con rotación azul-verde y puertas de validación de exhaustividad.
• La capa de orquestación de multitenencia, cuando necesitas aislamiento de inquilinos.
• La pila de observabilidad, con detección de deriva, alertas de regresión de exhaustividad y monitorización de latencia P95/P99.
• Herramientas de migración para los equipos que se mueven entre motores, usando formatos Parquet intermedios para preservar los embeddings donde la dimensionalidad coincide en lugar de forzar una reincrustación completa.

Definimos el alcance de cada proyecto con proyecciones mensuales explícitas de costes de infraestructura, para que sepas cuánto costará la producción antes de comprometerte.