Ha decidido utilizar la búsqueda vectorial en su aplicación, producto o negocio. Ha investigado cómo y por qué las incrustaciones y la búsqueda vectorial hacen que un problema tenga solución o pueden habilitar nuevas funciones. Ha sumergido los dedos de los pies en el área emergente y candente de los algoritmos aproximados del vecino más cercano y las bases de datos vectoriales.
Casi inmediatamente después de producir aplicaciones de búsqueda vectorial, comenzará a encontrarse con dificultades muy difíciles y potencialmente imprevistas. Este blog intenta brindarle algunos conocimientos sobre su futuro, los problemas que enfrentará y las preguntas que quizás aún no sepa y que debe hacer.
La búsqueda de vectores y todos los algoritmos inteligentes asociados son la inteligencia central de cualquier sistema que intente aprovechar los vectores. Sin embargo, toda la infraestructura asociada para que sea de máxima utilidad y esté listo para la producción es enorme y muy, muy fácil de subestimar.
Para decirlo lo más claramente posible: una base de datos vectorial lista para producción resolverá muchos, muchos más problemas de “base de datos” que problemas “vectoriales” . De ninguna manera la búsqueda de vectores en sí misma es un problema “fácil” (y cubriremos muchos de los subproblemas difíciles a continuación), pero la montaña de problemas de bases de datos tradicionales que una base de datos de vectores necesita resolver ciertamente sigue siendo la “parte difícil”. "
Las bases de datos resuelven una serie de problemas muy reales y muy bien estudiados, desde atomicidad y transacciones, coherencia, optimización del rendimiento y consultas, durabilidad, copias de seguridad, control de acceso, multiinquilino, escalado y fragmentación y mucho más. Las bases de datos vectoriales requerirán respuestas en todas estas dimensiones para cualquier producto, negocio o empresa.
Tenga mucho cuidado con la “infraestructura de búsqueda vectorial” casera. No es tan difícil descargar una biblioteca de búsqueda de vectores de última generación y comenzar el camino aproximado hacia el vecino más cercano hacia un prototipo interesante. Sin embargo, continuar por este camino es un camino para reinventar accidentalmente su propia base de datos. Probablemente esa sea una elección que quieras tomar conscientemente.
Debido a la naturaleza de los algoritmos de búsqueda de vectores ANN más modernos, actualizar incrementalmente un índice de vectores es un desafío enorme. Este es un "problema difícil" bien conocido. El problema aquí es que estos índices están cuidadosamente organizados para búsquedas rápidas y cualquier intento de actualizarlos incrementalmente con nuevos vectores deteriorará rápidamente las propiedades de búsqueda rápida. Como tal, para mantener búsquedas rápidas a medida que se agregan vectores, estos índices deben reconstruirse periódicamente desde cero.
Cualquier aplicación que desee transmitir nuevos vectores continuamente, con el requisito de que ambos vectores aparezcan rápidamente en el índice y las consultas permanezcan rápidas, necesitará un soporte serio para el problema de la “indexación incremental”. Esta es un área muy importante que debe comprender sobre su base de datos y un buen lugar para hacer una serie de preguntas difíciles.
Hay muchos enfoques potenciales que una base de datos podría adoptar para ayudarle a resolver este problema. Un estudio adecuado de estos enfoques llenaría muchas publicaciones de blog de este tamaño. Es importante comprender algunos de los detalles técnicos del enfoque de su base de datos porque puede tener compensaciones o consecuencias inesperadas en su aplicación. Por ejemplo, si una base de datos elige realizar una reindexación completa con cierta frecuencia, puede provocar una carga elevada de la CPU y, por lo tanto, afectar periódicamente las latencias de las consultas.
Debe comprender la necesidad de indexación incremental de sus aplicaciones y las capacidades del sistema en el que confía para brindarle servicios.
Cada aplicación debe comprender su necesidad y tolerancia a la latencia de datos. Los índices basados en vectores tienen, al menos según otros estándares de bases de datos, costos de indexación relativamente altos. Existe una importante compensación entre costo y latencia de datos.
¿Cuánto tiempo después de "crear" un vector necesita que se pueda buscar en su índice? Si es pronto, la latencia vectorial es un punto de diseño importante en estos sistemas.
Lo mismo se aplica a los metadatos de su sistema. Como regla general, la mutación de metadatos es bastante común (por ejemplo, cambiar si un usuario está en línea o no), por lo que suele ser muy importante que las consultas filtradas de metadatos reaccionen rápidamente a las actualizaciones de los metadatos. Tomando el ejemplo anterior, ¡no es útil si su búsqueda vectorial devuelve una consulta para alguien que se ha desconectado recientemente!
Si necesita transmitir vectores continuamente al sistema, o actualizar los metadatos de esos vectores continuamente, necesitará una arquitectura de base de datos subyacente diferente a la que sería aceptable para su caso de uso, por ejemplo, reconstruir el índice completo cada noche para usarlo al día siguiente. .
Voy a afirmar firmemente este punto: creo que en casi todas las circunstancias, la experiencia del producto será mejor si la infraestructura de búsqueda vectorial subyacente se puede aumentar mediante el filtrado de metadatos (o búsqueda híbrida).
Muéstrame todos los restaurantes que me podrían gustar (una búsqueda vectorial) que estén ubicados dentro de un radio de 10 millas y que tengan precios bajos a medios (filtro de metadatos).
La segunda parte de esta consulta es una cláusula WHERE
tradicional similar a SQL intersectada con, en la primera parte, un resultado de búsqueda vectorial. Debido a la naturaleza de estos índices vectoriales grandes, relativamente estáticos y relativamente monolíticos, es muy difícil realizar una búsqueda conjunta de vector + metadatos de manera eficiente. Este es otro de los conocidos “problemas difíciles” que las bases de datos vectoriales deben abordar en su nombre.
Hay muchos enfoques técnicos que las bases de datos pueden adoptar para resolver este problema. Puede "prefiltrar", lo que significa aplicar el filtro primero y luego realizar una búsqueda de vectores. Este enfoque adolece de no poder aprovechar eficazmente el índice vectorial prediseñado. Puede "postfiltrar" los resultados después de haber realizado una búsqueda vectorial completa. Esto funciona muy bien a menos que su filtro sea muy selectivo, en cuyo caso pasa mucho tiempo buscando vectores que luego descarta porque no cumplen con los criterios especificados. A veces, como es el caso de Rockset, se puede realizar un filtrado de "etapa única", que consiste en intentar fusionar la etapa de filtrado de metadatos con la etapa de búsqueda de vectores de una manera que preserve lo mejor de ambos mundos.
Si cree que el filtrado de metadatos será fundamental para su aplicación (y postulé anteriormente que casi siempre lo será), las compensaciones y la funcionalidad del filtrado de metadatos se convertirán en algo que deberá examinar con mucho cuidado.
Si estoy en lo cierto y el filtrado de metadatos es crucial para la aplicación que está creando, felicidades, tiene otro problema más. Necesita una forma de especificar filtros sobre estos metadatos. Este es un lenguaje de consulta.
Desde el punto de vista de la base de datos, y como este es un blog de Rockset, probablemente puedas esperar adónde voy con esto. SQL es la forma estándar de la industria de expresar este tipo de declaraciones. Los “filtros de metadatos” en lenguaje vectorial son simplemente “la cláusula WHERE
” para una base de datos tradicional. Tiene la ventaja de ser también relativamente fácil de transferir entre diferentes sistemas.
Además, estos filtros son consultas y las consultas se pueden optimizar. La sofisticación del optimizador de consultas puede tener un gran impacto en el rendimiento de sus consultas. Por ejemplo, los optimizadores sofisticados intentarán aplicar primero el más selectivo de los filtros de metadatos porque esto minimizará el trabajo que requieren las etapas posteriores del filtrado, lo que resultará en una gran ganancia de rendimiento.
Si planea escribir aplicaciones no triviales utilizando búsqueda vectorial y filtros de metadatos, es importante comprender y sentirse cómodo con el lenguaje de consulta, tanto en ergonomía como en implementación, que se está registrando para usar, escribir y mantener.
Muy bien, has llegado hasta aquí. Tiene una base de datos vectorial que tiene todos los fundamentos de base de datos correctos que necesita, tiene la estrategia de indexación incremental adecuada para su caso de uso, tiene una buena historia sobre sus necesidades de filtrado de metadatos y mantendrá su índice actualizado con las latencias. puedes tolerar. Impresionante.
Su equipo de ML (o tal vez OpenAI) presenta una nueva versión de su modelo de integración. Tienes una base de datos gigantesca llena de vectores antiguos que ahora necesitan ser actualizados. ¿Ahora que? ¿Dónde va a ejecutar este gran trabajo de aprendizaje automático por lotes? ¿Cómo vas a almacenar los resultados intermedios? ¿Cómo vas a hacer el cambio a la nueva versión? ¿Cómo planea hacer esto de una manera que no afecte su carga de trabajo de producción?
La búsqueda vectorial es un área que emerge rápidamente y estamos viendo que muchos usuarios comienzan a llevar aplicaciones a producción. Mi objetivo para esta publicación era brindarle algunas de las preguntas difíciles y cruciales que quizás aún no sepa formular. Y se beneficiará enormemente si recibe una respuesta lo antes posible.
En esta publicación, lo que no cubrí fue cómo Rockset ha trabajado y está trabajando para resolver todos estos problemas y por qué algunas de nuestras soluciones son innovadoras y mejores que la mayoría de los otros intentos de vanguardia. Cubrir eso requeriría muchas publicaciones de blog de este tamaño, que es, creo, precisamente lo que haremos. Mantente sintonizado para más.