Durante un tiempo, la idea sonaba convincente: si los grandes modelos de lenguaje ampliaban su ventana de contexto hasta tamaños enormes, quizá la búsqueda vectorial dejaría de ser una pieza central. Para muchos equipos de arquitectura, las bases de datos vectoriales parecían una solución de transición propia de la era RAG (retrieval-augmented generation), útil mientras los modelos no pudieran “llevarse” dentro todo lo necesario.
El aterrizaje en producción está contando otra historia. Con la llegada de la IA agente —sistemas que no solo responden, sino que planifican, consultan herramientas, verifican y vuelven a consultar— el problema de recuperar información no se ha encogido: se ha multiplicado. Según explicaba Andre Zayarni, CEO y cofundador de Qdrant, a VentureBeat, el contraste es radical: una persona hace unas pocas consultas cada cierto tiempo; un agente puede lanzar cientos o miles por segundo solo para reunir contexto y tomar decisiones.
Esa diferencia no es un matiz técnico. Es como comparar a alguien buscando un libro en una biblioteca con un equipo entero de documentalistas corriendo a la vez por los pasillos, abriendo índices, cotejando ediciones y trayendo referencias en paralelo. La biblioteca puede ser la misma, pero el sistema de catálogo y la logística ya no sirven igual.
Por qué la memoria de agentes y el contexto largo no sustituyen la recuperación
La ventana de contexto funciona bien para mantener el hilo de una conversación o el estado inmediato de una tarea. Se parece a la encimera de la cocina: puedes dejar ahí los ingredientes que estás usando “ahora”, pero no pretendes guardar en la encimera la despensa entera. Los agentes operan con información que el modelo no trae de fábrica: datos privados de la empresa, documentación interna, cambios diarios, millones de archivos que se actualizan, contratos, tickets, correos, bases de conocimiento y registros históricos.
Ahí entra el punto clave: el contexto largo no garantiza búsqueda de alta recuperación (high recall) sobre grandes colecciones, no conserva la calidad de resultados cuando el corpus cambia y, sobre todo, no soporta el volumen de consultas que genera un agente autónomo. El propio Zayarni subrayaba que muchos marcos de “memoria” de agentes ya se apoyan por debajo en algún tipo de almacenamiento vectorial. Dicho de otra forma: aunque el producto se venda como “memoria”, el músculo suele seguir siendo recuperación de información.
Cuando esa capa no está diseñada para el ritmo y el tamaño de los agentes, aparecen fallos que no se reducen a “va un poco lento”. Un resultado perdido en un corpus enorme es un error de calidad que se propaga: si el agente no encuentra una pieza clave en la primera pasada, su plan puede desviarse y sus siguientes consultas se construyen sobre un mapa incompleto. Con ingestas constantes, la frescura se vuelve un campo minado: lo recién añadido puede quedarse temporalmente en segmentos menos optimizados, y justo lo más nuevo —lo que suele importar más— termina siendo más lento de encontrar o se ordena peor. En entornos distribuidos, la latencia de una sola réplica puede arrastrar toda una “turn” del agente, porque sus llamadas a herramientas suelen ser paralelas: un nodo lento no es una molestia para un humano, es un cuello de botella para un sistema que intenta decidir en tiempo real.
Qdrant 1.17 y la apuesta por una capa de recuperación para agentes
En ese contexto encaja la noticia que recogía VentureBeat: Qdrant, compañía berlinesa de código abierto, anunció una ronda Serie B de 50 millones de dólares, dos años después de una Serie A de 28 millones, y presentó la versión 1.17 de su plataforma. Más allá del titular financiero, el mensaje que intenta trasladar es que la infraestructura para recuperar información no era un parche: con agentes, se convierte en carretera principal.
La versión 1.17 apunta directamente a los puntos débiles que se vuelven críticos a escala. Por un lado, incorpora un mecanismo de “relevance feedback” que ajusta el scoring de similitud en una siguiente pasada con señales ligeras generadas por modelo, sin reentrenar el modelo de embeddings. En la práctica, esto funciona como cuando alguien te dice “no, no me refiero a ese tipo de documento; busco el que habla de X con este enfoque”: el sistema afina la búsqueda sin tener que rehacer todo el índice ni cambiar el lenguaje en el que está “pensando” el embedding.
Por otro lado, añade “delayed fan-out”: si la primera réplica excede un umbral de latencia configurable, se lanza la consulta a una segunda réplica. Es un enfoque que recuerda a tener dos cajas abiertas en el supermercado: si una fila se atasca, el sistema no se queda esperando con el carrito inmóvil; prueba otra vía para mantener el flujo.
La tercera pieza es una nueva API de telemetría a nivel de clúster, pensada para sustituir el diagnóstico nodo a nodo por una vista unificada. En sistemas con agentes, observar qué ocurre no es un lujo. Es la diferencia entre arreglar un incidente con linterna y hacerlo con el cuadro eléctrico delante.
“No me llames base de datos”: la batalla semántica por la calidad de búsqueda
Otro giro interesante del relato es cómo cambia la etiqueta. Zayarni insiste en que ya no quiere que a Qdrant se le llame base de datos vectorial. El motivo es estratégico y técnico a la vez: hoy casi cualquier base de datos importante admite vectores como tipo de dato, desde soluciones en la nube hasta sistemas relacionales tradicionales. Los vectores se han vuelto “lo mínimo”.
Lo especializado ya no es guardar vectores. Es entregar calidad de búsqueda bajo carga real, con datos cambiantes, con consultas en paralelo, con necesidades de trazabilidad. En su comparación, una base de datos sirve para almacenar datos de usuario; si la calidad del resultado importa, necesitas un motor de búsqueda, una capa de information retrieval.
Su recomendación para equipos que arrancan también es pragmática: empieza con el soporte vectorial que ya tengas en tu stack. El salto a una solución dedicada suele ocurrir cuando el sistema deja de aguantar el ritmo, no cuando lo dice una moda.
Cuando Postgres “vale”… hasta que deja de valer: lo que cuentan dos equipos en producción
VentureBeat recogía dos casos que ilustran el cambio de escala. El primero es GlassDollar, que ayuda a empresas como Siemens y Mahle a evaluar startups. Su producto es, literalmente, búsqueda: el usuario describe una necesidad en lenguaje natural y recibe una lista priorizada a partir de un corpus de millones de compañías. Su patrón no es el RAG más sencillo de “una consulta, unos documentos, una respuesta”. Usan expansión de consulta: una sola petición se convierte en múltiples búsquedas paralelas “desde distintos ángulos”, se combinan candidatos y se reordenan. Eso se parece más a un agente que investiga que a un chatbot que cita.
En su transición, el equipo migró desde Elasticsearch al escalar hacia decenas de millones de documentos indexados. Tras el cambio a Qdrant, indicaron una reducción aproximada del 40% en costes de infraestructura, pudieron retirar una capa de compensación basada en keywords que mantenían para corregir huecos de relevancia, y vieron un aumento de engagement de tres veces. Kamen Kanev, responsable de producto, lo resumía con una métrica que suena casi obvia y por eso es potente: el éxito se mide por recall. Si los mejores resultados no aparecen, el usuario pierde confianza.
El segundo caso es &AI, que desarrolla infraestructura para litigios de patentes. Su agente, Andy, realiza búsqueda semántica sobre cientos de millones de documentos a lo largo de décadas y jurisdicciones. Aquí el matiz es importante: los abogados no van a actuar sobre texto generado si no está anclado en documentos reales. Su arquitectura busca minimizar el riesgo de alucinación poniendo la recuperación como primitiva central, no la generación. En palabras de su CTO, el agente es la interfaz y el sistema vectorial es el “ground truth”.
Señales de que tu vector search “incluido” se está quedando pequeño
Para muchos equipos, el camino práctico seguirá empezando con lo disponible: Postgres con extensiones, un servicio gestionado en la nube, o el vector search integrado en una base de datos existente. El punto de inflexión suele llegar cuando la calidad de recuperación impacta directamente en el negocio, cuando aparecen patrones de consulta con expansión, re-ranking y llamadas paralelas propias de agentes, o cuando el volumen salta a decenas de millones de documentos y la observabilidad del clúster se vuelve un problema cotidiano.
Ahí cambia la pregunta. Ya no es “¿tenemos embeddings?”. Es “¿podemos sostener miles de consultas por segundo sin degradar relevancia, frescura y latencia, y con visibilidad operativa suficiente?”. En ese marco, lo que antes parecía accesorio —un motor especializado de recuperación de información— empieza a parecerse a la base de todo lo demás.