Google Cloud actualizó el índice ScaNN de AlloyDB, con un límite oficial de escala superior a 10.000 millones de vectores. A esa escala, los datos de prueba muestran una latencia P95 de como máximo 51 milisegundos y un recall del 95%. AlloyDB es el servicio de base de datos gestionado de Google Cloud, compatible con la interfaz de PostgreSQL.
El cambio está en la estructura del índice. Antes, ScaNN organizaba los vectores en árboles de dos o tres niveles; ahora pasa a usar cuatro niveles.
Un nivel más en el árbol, dos órdenes de magnitud menos en la búsqueda
La búsqueda aproximada del vecino más cercano agrupa primero los vectores por similitud en clústeres organizados por niveles; en cada consulta se recorre de arriba hacia abajo, y en cada nivel solo se exploran las ramas más cercanas. El número de niveles determina la complejidad de la búsqueda: un árbol de dos niveles es O(N^1/2), con tres niveles baja a O(N^1/3), y con cuatro niveles se reduce aún más a O(N^1/4).
Estos exponentes difieren mucho a escala de decenas de miles de millones. Haciendo un cálculo aproximado: con N igual a 10.000 millones, la raíz cuadrada de N es de unos 100.000, la raíz cúbica es de unos 2.150, y la raíz cuarta es de unos 316. El número de candidatos que una misma consulta debe tocar cae del orden de cientos de miles al orden de cientos. De ahí viene la cifra de 51 milisegundos.
Entre las medidas concretas que enumera Google están la estrategia de ramificación Top-K, el algoritmo SOAR, el ajuste de centroides y la construcción de árboles equilibrados, además de un muestreo dinámico para evitar los límites de memoria. Google señala dos cuellos de botella de la estructura anterior: cuanto más grande es el árbol, mayor es el costo computacional tanto al construir el índice como al recorrer la consulta; y al muestrear miles de millones de vectores es fácil agotar la memoria disponible.
Han sido los agentes de IA los que han disparado el volumen de datos
Según Google, la demanda de las aplicaciones de agentes de IA de nivel empresarial está empujando los casos de uso hacia miles de millones de vectores, y las bases de datos vectoriales subyacentes a menudo no dan abasto.
Esta frase señala el origen de esta ronda de expansión. En los escenarios tradicionales de búsqueda aumentada (RAG), una empresa divide todos sus documentos internos en fragmentos, normalmente en un orden de decenas a cientos de millones. Con los agentes de IA es distinto: en cada paso de ejecución necesitan revisar el historial, consultar descripciones de herramientas y comprobar preferencias del usuario; una sola tarea puede disparar más de una decena de búsquedas. Las fuentes de datos también se han ampliado de documentos a registros de conversación, logs de operaciones y resultados intermedios, que se acumulan cada día.
Otro cálculo: con una P95 de 51 milisegundos, si una tarea de un agente realiza 15 búsquedas, solo en la base de datos vectorial eso consume unos 0,77 segundos. Y eso es solo la parte de la base de datos; la inferencia del modelo, las llamadas a herramientas y los viajes de red se cuentan aparte. La latencia de búsqueda parece insignificante en una sola interacción, pero dentro de una cadena de múltiples pasos pasa a formar parte de la experiencia percibida.
Las bases de datos de propósito general están absorbiendo a los productos especializados
Integrar la búsqueda vectorial a escala de decenas de miles de millones en un servicio gestionado compatible con PostgreSQL apunta en la misma dirección: los vectores ya no necesitan una infraestructura propia y separada.
Para los clientes empresariales, la cuenta es fácil. Los datos de negocio ya están en bases de datos relacionales: las tablas de usuarios, de pedidos y las reglas de permisos ya están ahí. Mantener los vectores en una base de datos especializada aparte implica dos sistemas de backup, dos esquemas de permisos, dos garantías de consistencia, y tener que gestionar por cuenta propia los límites de transacción entre ambas bases. Si basta con añadir un índice a la base existente, la complejidad operativa se reduce a la mitad.
La posición de las bases de datos vectoriales especializadas también ha cambiado en los últimos dos años. Siguen teniendo ventaja en rendimiento extremo y en la velocidad de iteración de los algoritmos de búsqueda, pero las bases de datos de propósito general no dejan de elevar el umbral de lo suficiente: de millones a cientos de millones, y ahora a decenas de miles de millones. El espacio que queda para los productos especializados se ha reducido a ese pequeño segmento con las exigencias más estrictas de latencia y throughput.
Esta vez, AlloyDB no ha publicado el número de particiones, la dimensión de los vectores, el tiempo de construcción del índice ni el límite de QPS. Estos parámetros suelen tener más valor práctico a la hora de elegir tecnología que la escala máxima, especialmente cuánto tarda en construirse el índice, ya que el costo de reconstrucción a escala de decenas de miles de millones puede resultar desproporcionadamente alto.
Fuentes: blog oficial de Google Cloud, documentación del índice ScaNN de AlloyDB, CocoLoop; las cifras de escala de vectores, latencia P95 y recall siguen el anuncio oficial, las conversiones de complejidad son estimaciones editoriales.