Databricks anunció el 28 de julio la disponibilidad general del escalado de alto QPS en Databricks AI Search, su servicio de búsqueda vectorial. Los endpoints estándar pueden ahora sostener más de 1.000 consultas por segundo configurando un único parámetro, target_qps, que se fija al crear el endpoint o se actualiza sobre uno existente desde el SDK, la API REST o la interfaz. Sin réplicas que contar, sin nodos que dimensionar y sin balanceadores que cablear.
El detalle es más relevante de lo que sugiere su aparente sencillez. La búsqueda vectorial nació en la mayoría de plataformas como una pieza para prototipos de RAG: volúmenes bajos, latencias tolerantes y un puñado de usuarios internos probando un chatbot documental. El salto a producción cambia el perfil de carga por completo. Databricks cita como casos de uso cajas de búsqueda de comercio electrónico, descubrimiento de contenido en plataformas de medios y búsqueda por voz en dispositivos conectados: tráfico de usuario final, sostenido y sensible a la latencia. Para esos escenarios la compañía recomienda autenticación OAuth con service principal y el uso de la URL del índice.
Lo que se está resolviendo aquí es un problema de operación, no de algoritmo. Dimensionar manualmente un servicio de búsqueda vectorial obliga a estimar réplicas, vigilar la saturación y rehacer el cálculo cada vez que cambia el patrón de tráfico; convertir eso en un número declarativo traslada la complejidad al proveedor. Es el mismo movimiento que ya vimos en el almacenamiento y en el cómputo elástico, aplicado ahora a la capa de recuperación que alimenta a los modelos.
Para un arquitecto de datos, la lectura es que la búsqueda vectorial está dejando de ser un componente experimental para convertirse en infraestructura de servicio con expectativas de disponibilidad y latencia equiparables a las de una base de datos operacional. Eso obliga a tratarla como tal: presupuesto asignado, monitorización de percentiles de latencia, pruebas de carga previas y un plan de degradación cuando el índice no responde. Un RAG que falla en producción es un producto que falla, no una demo que se cae.
Conviene, eso sí, no confundir capacidad con calidad. Escalar a mil consultas por segundo no mejora la relevancia de los resultados, que sigue dependiendo del troceado de los documentos, del modelo de embeddings elegido y de la estrategia de reordenación. Y el coste real del alto QPS habrá que medirlo sobre cargas propias antes de comprometerse: el parámetro es simple, la factura asociada no tiene por qué serlo.
Más en Dataprix: Análisis de plataformas de datos y servicios cloud.
Fuente: Databricks Blog.