Por ADRIEN GRAND
Existen diferentes enfoques para implementar bases de datos vectoriales y tienen diferentes compensaciones. En este blog, aprenderá más sobre cómo se integró la búsqueda vectorial en Elastisearch y las compensaciones que hicimos.
¿Estás interesado en conocer las características y el diseño de Elasticsearch para búsquedas vectoriales? Como siempre, las decisiones de diseño tienen sus pros y sus contras. Este blog tiene como objetivo detallar cómo elegimos crear una búsqueda vectorial en Elasticsearch.
Vector Search integrado en Elasticsearch a través de Apache Lucene
Primero, algunos antecedentes sobre Lucene: Lucene organiza los datos en segmentos inmutables que se fusionan periódicamente. Agregar más documentos requiere agregar más segmentos. Modificar documentos existentes requiere agregar automáticamente más segmentos y marcar las versiones anteriores de esos documentos como eliminadas. Cada documento dentro de un segmento se identifica mediante un ID de documento, que es el índice del documento dentro del segmento, similar a un índice de matriz. La motivación para este enfoque es gestionar índices invertidos, que no son buenos para la modificación in situ, pero que se pueden fusionar de manera eficiente.
Además de los índices invertidos, Lucene admite el almacenamiento de campos (almacenamiento de documentos), valores de documentos (almacenamiento de columnas), vectores de términos (índice invertido por documento) y puntos multidimensionales en segmentos . Los vectores se han integrado de la misma forma:
- Los nuevos vectores se almacenan en la memoria a medida que se indexan.
- Estos búferes en memoria se serializan como parte del segmento cuando se excede el tamaño de los búferes de tiempo de índice o cuando los cambios deben hacerse visibles.
- Los segmentos se fusionan periódicamente en segundo plano para controlar el número total de segmentos y limitar el tiempo de búsqueda general para cada segmento. Como son parte de segmentos, los vectores también deben fusionarse.
- La búsqueda debe combinar los resultados de vectores principales de todos los segmentos del índice.
- Las búsquedas en vectores deben mirar el conjunto de documentos activos para excluir los documentos cuyo token se elimina.
El sistema anterior se basa en la forma en que funciona Lucene.
Lucene utiliza actualmente el algoritmo Hierarchical Navigable Small World ( HNSW ) para indexar vectores. En un nivel alto, HNSW organiza los vectores en un gráfico donde se pueden conectar vectores similares. HNSW es una opción popular para la búsqueda de vectores porque es bastante simple, funciona bien en pruebas comparativas de algoritmos de búsqueda de vectores y admite la inserción incremental. La implementación de HNSW por parte de Lucene sigue las pautas de Lucene de mantener los datos en el disco y confiar en el caché de la página para acelerar el acceso a los datos a los que se accede con frecuencia.
La búsqueda de vectores aproximada se expone en la API _search de Elasticsearch a través de la sección knn . El uso de esta función aprovechará directamente la funcionalidad de búsqueda vectorial de Lucene. Los vectores también están integrados en la API de secuencias de comandos de Elasticsearch, lo que permite realizar búsquedas exactas de fuerza bruta o volver a puntuar utilizando vectores.
Ahora profundicemos en los pros y los contras de integrar la búsqueda vectorial con Apache Lucene.
defecto
La principal desventaja de la búsqueda de vectores con Apache Lucene es que Lucene asocia vectores con segmentos. Sin embargo, como veremos más adelante en la sección " Ventajas ", asociar vectores con segmentos también es lo que permite funciones clave como un filtrado previo eficiente, una búsqueda híbrida eficiente y coherencia de visibilidad.
La fusión requiere volver a calcular el gráfico HNSW
La fusión de segmentos toma N segmentos de entrada (normalmente 10 para la estrategia de fusión predeterminada) y los fusiona en un solo segmento. Actualmente, Lucene crea una copia del gráfico HNSW a partir del segmento de entrada más grande sin eliminarlo y luego agrega vectores de otros segmentos a este gráfico HNSW. En comparación con la mutación de un único gráfico HNSW in situ durante la vida útil del índice, este enfoque genera una sobrecarga de tiempo de indexación porque los segmentos se fusionan.
Resultados de búsqueda que requieren combinar varios segmentos
Dado que el índice consta de varios segmentos, la búsqueda debe calcular los k top-k vectores en cada segmento y luego combinar estos top-k hits por segmento en un top-k hit global. El impacto en la latencia se puede mitigar buscando segmentos en paralelo, pero este enfoque todavía genera cierta sobrecarga en comparación con la búsqueda de un único gráfico HNSW.
La RAM debe escalar con el tamaño del conjunto de datos para mantener un rendimiento óptimo
Atravesar el gráfico HNSW produce mucho acceso aleatorio. Para una ejecución eficiente, el conjunto de datos debe caber en la caché de la página, lo que requiere que la RAM tenga un tamaño acorde al tamaño del conjunto de datos vectoriales que se administra. Además de HNSW, existen otros algoritmos para la búsqueda de vectores que tienen patrones de acceso más amigables con el disco, pero también tienen otras desventajas, como una mayor latencia de consulta o una peor recuperación.
ventaja
Los conjuntos de datos pueden crecer más allá del tamaño total de la RAM
Dado que los datos se almacenan en el disco, Elasticsearch permitirá conjuntos de datos mayores que la cantidad total de RAM disponible en el host local, y el rendimiento se degradará a medida que disminuya la proporción de datos HNSW que pueden caber en el caché de la página. Como se mencionó en la sección anterior, los usuarios preocupados por el rendimiento deberán ajustar el tamaño de la RAM según el tamaño del conjunto de datos para mantener un rendimiento óptimo.
búsqueda sin bloqueo
Los sistemas que actualizan las estructuras de datos in situ generalmente requieren bloqueo para garantizar la seguridad de los subprocesos durante la indexación y la búsqueda simultáneas. Los índices basados en segmentos de Lucene nunca requieren bloqueo durante la búsqueda, incluso en el caso de indexación simultánea. En cambio, el conjunto de segmentos que componen el índice se actualiza periódicamente de forma atómica.
Soporte para cambios incrementales
Se pueden agregar, eliminar o actualizar nuevos vectores en cualquier momento. Algunos otros algoritmos de búsqueda aproximada del vecino más cercano requieren que se proporcione todo el conjunto de datos vectoriales. Luego, una vez que se proporcionan todos los vectores, se realiza un paso de entrenamiento de índice. Para estos otros algoritmos, cualquier actualización significativa del conjunto de datos vectoriales requiere que se realice nuevamente el paso de entrenamiento, lo que puede resultar costoso desde el punto de vista computacional.
Coherencia de visibilidad con otras estructuras de datos.
Uno de los beneficios de integrarse en Lucene a un nivel tan bajo es que podemos ser consistentes con otras estructuras de datos listas para usar cuando miramos una vista puntual de un índice. Si realiza una actualización del documento para actualizar su vector y algunos otros campos clave, se garantiza que las búsquedas simultáneas verán el valor anterior del campo vectorial y el valor anterior del campo clave, si la vista de punto en el tiempo se creó antes de la actualizar, o El nuevo valor del campo vectorial y el nuevo valor del campo clave si la vista de un momento dado se creó después de la actualización. Lo mismo ocurre con las eliminaciones, si el documento está marcado como eliminado, todas las estructuras de datos, incluidos los almacenes de vectores, lo ignorarán o lo verán si operan en una vista de un momento dado creada antes de la eliminación.
instantánea incremental
El hecho de que un vector sea parte de un segmento ayuda a que las instantáneas sigan siendo incrementales al aprovechar el hecho de que dos instantáneas posteriores suelen compartir la mayoría de sus segmentos, especialmente las más grandes. No es posible realizar instantáneas incrementales con un único gráfico HNSW que cambia in situ .
Soporte de filtrado y mezcla
La integración directa en Lucene también permite una integración eficiente con otras funciones de Lucene, como el filtrado previo de búsquedas vectoriales con filtros Lucene arbitrarios o la combinación de resultados de consultas vectoriales con resultados de consultas tradicionales de texto completo.
Al tener su propio gráfico HNSW asociado con segmentos, donde los nodos se indexan por ID de documento, Lucene puede tomar decisiones interesantes sobre la mejor manera de filtrar previamente las búsquedas vectoriales: ya sea escaneando linealmente documentos que coincidan con el filtro (si se le dan las propiedades de opción), o atravesando el gráfico y considerando solo los nodos que coinciden con el filtro como candidatos para los k vectores superiores.
Compatibilidad con otras características
Dado que el almacenamiento de vectores es como cualquier otra estructura de datos de Lucene, muchas funciones son automáticamente compatibles con los vectores y las búsquedas de vectores, entre ellas:
- polimerización
- Seguridad a nivel de documento
- seguridad a nivel de campo
- clasificación de índice
- Acceda a los vectores a través de un script (por ejemplo, consulte o reordene desde script_score)
De cara al futuro: separación de la indexación y la búsqueda
Como se analizó en otra publicación de blog , las versiones futuras de Elasticsearch ejecutarán cargas de trabajo de indexación y búsqueda en instancias separadas. Básicamente, la implementación parece como si constantemente estuvieras tomando instantáneas de los inodos y restaurándolas en los nodos de búsqueda. Esto ayudará a evitar que el alto costo de la indexación de vectores afecte las búsquedas. No es posible lograr esta separación de indexación y búsqueda utilizando un único gráfico HNSW compartido en lugar de múltiples segmentos sin enviar el gráfico HNSW completo a través de la red cada vez que un cambio deba reflejarse en una nueva búsqueda.
en conclusión
En general, Elasticsearch proporciona excelentes capacidades de búsqueda vectorial y se integra con otras funciones de Elasticsearch:
- Las búsquedas vectoriales se pueden filtrar previamente mediante cualquier filtro compatible, incluidos los más complejos.
- Las visitas vectoriales se pueden combinar con visitas de consultas arbitrarias.
- Las búsquedas vectoriales son compatibles con agregación, seguridad a nivel de documentos, seguridad a nivel de campo, clasificación de índices y más.
- Los índices que contienen vectores siguen la misma semántica que otros índices, incluidas las API _refresh, _flush y _snapshot. También admitirán la separación de la indexación y la búsqueda en Elasticsearch sin estado.
Esto se hace a costa de algo de tiempo de indexación y tiempo de búsqueda adicional. Dicho esto, las búsquedas vectoriales todavía suelen ejecutarse en el orden de decenas o cientos de milisegundos y son mucho más rápidas que las búsquedas exactas por fuerza bruta. En términos más generales, tanto el tiempo de indexación como el tiempo de búsqueda parecen ser manejables en comparación con otros almacenes de vectores en los puntos de referencia existentes* (busque la línea "luceneknn"). También creemos que gran parte del valor de la búsqueda vectorial se puede desbloquear combinándola con otras capacidades. Además, le recomendamos que revise la Guía de ajuste de búsqueda de KNN , que enumera una serie de medidas que pueden ayudar a mitigar los efectos negativos de las deficiencias antes mencionadas.
Espero que disfrutes este blog. Si tiene preguntas, no dude en contactarnos a través de la discusión . No dudes en probar Vector Search en una implementación existente o probar Elasticsearch Service gratis en Elastic Cloud (siempre ten la última versión de Elasticsearch).
*En el momento de redactar este artículo, estos puntos de referencia aún no han utilizado la vectorización. Para obtener más información sobre la vectorización, lea este blog .
El lanzamiento y el momento de cualquier característica o funcionalidad descrita en este artículo quedan a exclusivo criterio de Elastic. Es posible que cualquier característica o funcionalidad que no esté disponible actualmente no se entregue a tiempo o no se entregue en absoluto.
Ejemplo: Búsqueda de vectores en Elasticsearch: la lógica detrás del diseño — Elastic Search Labs