Enfrentamiento de cuantificación binaria

Almacenar vectores de alta dimensión en su forma original puede requerir mucha memoria. Las técnicas de cuantificación comprimen estos vectores en una representación compacta, lo que reduce significativamente la huella de memoria. Luego, la búsqueda opera en el espacio comprimido, lo que reduce la complejidad computacional y hace que las búsquedas sean más rápidas, especialmente en grandes conjuntos de datos.

Elastic está comprometida a convertir Lucene en un motor vectorial de alto rendimiento. Introdujimos Better Binary Quantization (BBQ) en Elasticsearch 8.16 sobre Lucene y lo evolucionamos aún más en 8.18 y 9.0. BBQ se basa en un nuevo enfoque de cuantización escalar que reduce las dimensiones float32 a bits, ofreciendo una reducción de memoria del ~95% manteniendo una alta calidad de clasificación.

OpenSearch, por otro lado, emplea múltiples motores vectoriales: nmslib (ahora obsoleto), Lucene y FAISS. En un blog anterior, comparamos Elasticsearch y OpenSearch para la búsqueda vectorial. Empleamos tres conjuntos de datos diferentes y probamos diferentes combinaciones de motores y configuraciones en ambos productos.

Este blog se centra en los algoritmos de cuantificación binaria disponibles actualmente en ambos productos. Probamos Elasticsearch con BBQ y OpenSearch con la cuantificación binaria de FAISS empleando la pista openai_vector Rally.

El objetivo principal fue evaluar el desempeño de ambas soluciones bajo el mismo nivel de recuperación. ¿Qué significa recordar ? La recuperación es una métrica que mide cuántos de los resultados relevantes son recuperados con éxito por un sistema de búsqueda.

En esta evaluación, recall@k es particularmente importante, donde k representa el número de resultados principales considerados. Recall@10, Recall@50 y Recall@100 medir cuántos de los resultados relevantes reales aparecen en los 10, 50 y 100 elementos principales recuperados, respectivamente. La recuperación se expresa en una escala de 0 a 1 (o de 0% a 100% de precisión). Y eso es importante porque estamos hablando de KNN aproximado (ANN) y no de KNN exacto, donde la recordación es siempre 1 (100%).

Para cada valor de k también especificamos n, que es el número de candidatos considerados antes de aplicar la clasificación final. Esto significa que para Recall@10, Recall@50 y Recall@100, el sistema primero recupera n candidatos empleando el algoritmo de cuantificación binaria y luego los clasifica para determinar si los k resultados principales contienen los elementos relevantes esperados.

Al controlar n, podemos analizar el equilibrio entre eficiencia y precisión. Un n más alto generalmente aumenta la recuperación, ya que hay más candidatos disponibles para la clasificación, pero también aumenta la latencia y disminuye el rendimiento. Por el contrario, un n más bajo acelera la recuperación, pero puede reducir la recordación si se incluyen muy pocos candidatos relevantes en el conjunto inicial.

En esta comparación, Elasticsearch demostró una latencia más baja y un rendimiento más alto que OpenSearch en configuraciones idénticas.

Metodología

La configuración completa, junto con los scripts de Terraform, los manifiestos de Kubernetes y la pista de Rally específica está disponible en este repositorio en openai_vector_bq.

Al igual que con los puntos de referencia anteriores, empleamos un clúster de Kubernetes compuesto por:

• 1 pool de nodos para Elasticsearch 9.0 con 3 máquinas e2-standard-32 (128 GB de RAM y 32 CPU)

• 1 grupo de nodos para OpenSearch 2.19 con 3 máquinas e2-standard-32 (128 GB de RAM y 32 CPU)

• 1 grupo de nodos para Rally con 2 máquinas e2-standard-4 (16 GB de RAM y 4 CPU)

Configuramos un clúster de Elasticsearch versión 9.0 y un clúster de OpenSearch versión 2.19.

Tanto Elasticsearch como OpenSearch se probaron exactamente con la misma configuración: usamos openai_vector pista de Rally con algunas modificaciones , que emplea 2,5 millones de documentos del conjunto de datos NQ enriquecidos con incrustaciones generadas con el modelo text-embedding-ada-002 de OpenAI.

Los resultados informan sobre la latencia y el rendimiento medidos en diferentes niveles de recuperación (recall@10, recall@50 y recall@100) empleando 8 clientes simultáneos para realizar operaciones de búsqueda. Usamos un solo fragmento y no réplicas.

Ejecutamos las siguientes combinaciones de k-n-rescore, p. ej. 10-2000-2000, o K:10, N:2000 y Rescore:2000 recuperarían los mejores K (10) sobre N candidatos (2000) aplicando un Rescore sobre 2000 resultados (que es equivalente a un "factor de sobremuestreo" de 1). Cada búsqueda se ejecutó 10.000 veces con 1000 búsquedas como calentamiento:

Recall@10

• 10-40-40

• 10-50-50

• 10-100-100

• 10-200-200

• 10-500-500

• 10-750-750

• 10-1000-1000

• 10-1500-1500

• 10-2000-2000

Recall@50

• 50-150-150

• 50-200-200

• 50-250-250

• 50-500-500

• 50-750-750

• 50-1000-1000

• 50-1200-1200

• 50-1500-1500

• 50-2000-2000

Recall@100

• 100-200-200

• 100-250-250

• 100-300-300

• 100-500-500

• 100-750-750

• 100-1000-1000

• 100-1200-1200

• 100-1500-1500

• 100-2000-2000

Para replicar el punto de referencia, los manifiestos de Kubernetes para rally-elasticsearch y rally-opensearch tienen todas las variables relevantes externalizadas en un ConfigMap, disponible aquí (ES) y aquí (SO). El parámetro search_ops se puede personalizar para probar cualquier combinación de k, n y rescore.

Configuración de OpenSearch Rally

/k8s/rally-openai_vector-os-bq.yml

Configuración del índice de Opensearch

Las variables de ConfigMap se emplean en la configuración del índice, algunos parámetros se dejan sin cambios. La cuantización de 1 bit en OpenSearch se configura estableciendo el nivel de compresión en "32x".

index-vectors-only-mapping-with-docid-mapping.json

Configuración de Elasticsearch Rally

/k8s/rally-openai_vector-es-bq.yml

Configuración del índice de Elasticsearch

index-vectors-only-mapping-with-docid-mapping.json

Resultados

Hay varias formas de interpretar los resultados. Tanto para la latencia como para el rendimiento, trazamos un gráfico simplificado y detallado en cada nivel de recuperación. Es fácil ver diferencias si consideramos que "más alto es mejor" para cada métrica. Sin embargo, la latencia es negativa (más baja es mejor), mientras que el rendimiento es positivo. Para los gráficos simplificados, usamos (recuperación / latencia) * 10000 (llamado simplemente "velocidad") y recuperación * rendimiento, por lo que ambas métricas significan que más velocidad y más rendimiento son mejores. Vamos a ello.

Recuperación @ 10 - simplificado

En ese nivel de recuperación, Elasticsearch BBQ es hasta 5 veces más rápido (3,9 veces más rápido en promedio) y tiene 3,2 veces más rendimiento en promedio que OpenSearch FAISS.

Retiro @ 10 - Detallado

tarea

latencia.media

rendimiento.mean

avg_recall

Elasticsearch-9.0-BBQ

10-100-100

11.70

513.58

0.89

Elasticsearch-9.0-BBQ

10-1000-100

27.33

250.55

0.95

Elasticsearch-9.0-BBQ

10-1500-1500

35.93

197.26

0.95

Elasticsearch-9.0-BBQ

10-200-200

13.33

456.16

0.92

Elasticsearch-9.0-BBQ

10-2000-2000

44.27

161.40

0.95

Elasticsearch-9.0-BBQ

10-40-40

10.97

539.94

0.84

Elasticsearch-9.0-BBQ

10-50-50

11.00

535.73

0.85

Elasticsearch-9.0-BBQ

10-500-500

19.52

341.45

0.93

Elasticsearch-9.0-BBQ

10-750-750

22.94

295.19

0.94

OpenSearch-2.19-faiss

10-100-100

35.59

200.61

0.94

OpenSearch-2.19-faiss

10-1000-1000

156.81

58.30

0.96

OpenSearch-2.19-faiss

10-1500-1500

181.79

42.97

0.96

OpenSearch-2.19-faiss

10-200-200

47.91

155.16

0.95

OpenSearch-2.19-faiss

10-2000-2000

232.14

31.84

0.96

OpenSearch-2.19-faiss

10-40-40

27.55

249.25

0.92

OpenSearch-2.19-faiss

10-50-50

28.78

245.14

0.92

OpenSearch-2.19-faiss

10-500-500

79.44

97.06

0.96

OpenSearch-2.19-faiss

10-750-750

104.19

75.49

0.96

Recuperación @ 50 - simplificado

En ese nivel de recuperación, Elasticsearch BBQ es hasta 5 veces más rápido (4,2 veces más rápido en promedio) y tiene 3,9 veces más rendimiento en promedioque OpenSearch FAISS.

Resultados detallados - Recall @ 50

Tarea

Latencia media

Media de rendimiento

Retiro promedio

Elasticsearch-9.0-BBQ

50-1000-1000

25.71

246.44

0.95

Elasticsearch-9.0-BBQ

50-1200-1200

28.81

227.85

0.95

Elasticsearch-9.0-BBQ

50-150-150

13.43

362.90

0.90

Elasticsearch-9.0-BBQ

50-1500-1500

33.38

202.37

0.95

Elasticsearch-9.0-BBQ

50-200-200

12.99

406.30

0.91

Elasticsearch-9.0-BBQ

50-2000-2000

42.63

163.68

0.95

Elasticsearch-9.0-BBQ

50-250-250

14.41

373.21

0.92

Elasticsearch-9.0-BBQ

50-500-500

17.15

341.04

0.93

Elasticsearch-9.0-BBQ

50-750-750

31.25

248.60

0.94

OpenSearch-2.19-faiss

50-1000-1000

125.35

62.53

0.96

OpenSearch-2.19-faiss

50-1200-1200

143.87

54.75

0.96

OpenSearch-2.19-faiss

50-150-150

43.64

130.01

0.89

OpenSearch-2.19-faiss

50-1500-1500

169.45

46.35

0.96

OpenSearch-2.19-faiss

50-200-200

48.05

156.07

0.91

OpenSearch-2.19-faiss

50-2000-2000

216.73

36.38

0.96

OpenSearch-2.19-faiss

50-250-250

53.52

142.44

0.93

OpenSearch-2.19-faiss

50-500-500

78.98

97.82

0.95

OpenSearch-2.19-faiss

50-750-750

103.20

75.86

0.96

Retiro @ 100

En ese nivel de recuperación, Elasticsearch BBQ es hasta 5 veces más rápido (promedio 4,6 veces más rápido) y tiene 3,9 veces más rendimiento en promedio que OpenSearch FAISS.

Resultados detallados - Recall @ 100

tarea

latencia.media

rendimiento.mean

avg_recall

Elasticsearch-9.0-BBQ

100-1000-1000

27.82

243.22

0.95

Elasticsearch-9.0-BBQ

100-1200-1200

31.14

224.04

0.95

Elasticsearch-9.0-BBQ

100-1500-1500

35.98

193.99

0.95

Elasticsearch-9.0-BBQ

100-200-200

14.18

403.86

0.88

Elasticsearch-9.0-BBQ

100-2000-2000

45.36

159.88

0.95

Elasticsearch-9.0-BBQ

100-250-250

14.77

433.06

0.90

Elasticsearch-9.0-BBQ

100-300-300

14.61

375.54

0.91

Elasticsearch-9.0-BBQ

100-500-500

18.88

340.37

0.93

Elasticsearch-9.0-BBQ

100-750-750

23.59

285.79

0.94

OpenSearch-2.19-faiss

100-1000-1000

142.90

58.48

0.95

OpenSearch-2.19-faiss

100-1200-1200

153.03

51.04

0.95

OpenSearch-2.19-faiss

100-1500-1500

181.79

43.20

0.96

OpenSearch-2.19-faiss

100-200-200

50.94

131.62

0.83

OpenSearch-2.19-faiss

100-2000-2000

232.53

33.67

0.96

OpenSearch-2.19-faiss

100-250-250

57.08

131.23

0.87

OpenSearch-2.19-faiss

100-300-300

62.76

120.10

0.89

OpenSearch-2.19-faiss

100-500-500

84.36

91.54

0.93

OpenSearch-2.19-faiss

100-750-750

111.33

69.95

0.94

Mejoras en el asado

BBQ recorrió un largo camino desde su primer lanzamiento. En Elasticsearch 8.16, en aras de la comparación, incluimos una ejecución de referencia de 8.16 junto con la actual, y podemos ver cómo la recuperación y la latencia mejoraron desde entonces.

En Elasticsearch 8.18 y 9.0, reescribimos el algoritmo central para cuantificar los vectores. Entonces, si bien BBQ en 8.16 fue bueno, las versiones más nuevas son aún mejores. Puedes leer sobre esto aquí y aquí. En resumen, cada vector se cuantifica individualmente a través de cuantiles escalares optimizados. Como resultado, los usuarios se benefician de una mayor precisión en la búsqueda vectorial sin comprometer el rendimiento, lo que hace que la recuperación vectorial de Elasticsearch sea aún más poderosa.

Conclusión

En esta comparación de rendimiento entre Elasticsearch BBQ y OpenSearch FAISS, Elasticsearch supera significativamente a OpenSearch para la búsqueda vectorial, logrando velocidades de consulta hasta 5 veces más rápidas y un rendimiento 3,9 veces mayor en promedio en varios niveles de recuperación.

Los hallazgos clave incluyen:

• Recall@10: Elasticsearch BBQ es hasta 5 veces más rápido (3,9 veces más rápido en promedio) y tiene 3,2 veces más rendimiento en promedio en comparación con OpenSearch FAISS.

• Recall@50: Elasticsearch BBQ es hasta 5 veces más rápido (4,2 veces más rápido en promedio) y tiene 3,9 veces más rendimiento en promedio en comparación con OpenSearch FAISS.

• Recall@100: Elasticsearch BBQ es hasta 5 veces más rápido (4,6 veces más rápido en promedio) y tiene 3,9 veces más rendimiento en promedio en comparación con OpenSearch FAISS.

Estos resultados resaltan los beneficios de eficiencia y rendimiento de Elasticsearch BBQ, particularmente en escenarios de búsqueda vectorial de alta dimensión. La técnica Better Binary Quantization (BBQ), introducida en Elasticsearch 8.16, proporciona una reducción sustancial de la memoria (~95%) al tiempo que mantiene una alta calidad de clasificación, lo que la convierte en una opción superior para aplicaciones de búsqueda vectorial a gran escala.

En Elastic, estamos innovando incansablemente para mejorar Apache Lucene y Elasticsearch para proporcionar la mejor base de datos vectorial para casos de uso de búsqueda y recuperación, incluida RAG (Retrieval Augmented Generation). Nuestros avances recientes aumentaron significativamente el rendimiento, haciendo que la búsqueda vectorial sea más rápida y eficiente en cuanto al espacio que antes, basar en las ganancias de Lucene 10. Este blog es otra ilustración de esa innovación.

La búsqueda vectorial está revolucionando la forma en que hacemos búsquedas de similitud, particularmente en campos como la IA y el machine learning. Con la creciente adopción de modelos de incrustación de vectores, la capacidad de búsqueda eficiente a través de millones de vectores de alta dimensionalidad se vuelve crítica.

Cuando se trata de habilitar bases de datos vectoriales, Elastic y OpenSearch han adoptado enfoques notablemente diferentes. Elastic ha invertido mucho en la optimización de Apache Lucene junto con Elasticsearch para elevarlos como la opción de primer nivel para las aplicaciones de búsqueda vectorial. Por el contrario, OpenSearch ha ampliado su enfoque, integrando otras implementaciones de búsqueda vectorial y explorando más allá del alcance de Lucene. Nuestro enfoque en Lucene es estratégico, lo que nos permite brindar soporte sumamente integrado en nuestra versión de Elasticsearch, resultando en un conjunto de características mejorado en el que cada componente complementa y amplifica las capacidades del otro.

Este blog presenta una comparación detallada entre Elasticsearch 8.14 y OpenSearch 2.14, considerando diferentes configuraciones y motores vectoriales. En este análisis de rendimiento, Elasticsearch demostró ser la plataforma superior para las operaciones de búsqueda de vectores. Incluso las próximas características ampliarán las diferencias de forma más significativa. Cuando se enfrentó a OpenSearch, sobresalió en todas las pistas de referencia, con un rendimiento de 2 a 12 veces más rápido en promedio. Esto sucedió en todos los casos que utilizaban cantidades y dimensiones vectoriales variables, como so_vector (2M vectores, 768D), openai_vector (2.5M vectores, 1536D) y dense_vector (10M vectores, 96D), todos disponibles en este repositorio junto con los scripts de Terraform para provisionar toda la infraestructura requerida en Google Cloud y los manifiestos de Kubernetes para ejecutar las pruebas.

Los resultados detallados en este blog complementan los resultados de un estudio previamente publicado y validado por terceros que muestra que Elasticsearch es 40%–140% más rápido que OpenSearch para las operaciones de análisis de búsqueda más comunes: consulta de texto, clasificación, rango, histograma de fechas y filtrado de términos. Ahora podemos agregar otro diferenciador: la búsqueda vectorial.

Hasta 12 veces más rápido desde el primer momento

Nuestros puntos de referencia enfocados en los cuatro conjuntos de datos vectoriales involucraron tanto búsquedas de KNN aproximados como de KNN exactos, considerando diferentes tamaños, dimensiones y configuraciones, totalizando 40.189.820 solicitudes de búsqueda no almacenadas en caché. Los resultados: Elasticsearch es hasta 12 veces más rápido que OpenSearch para la búsqueda vectorial y, por lo tanto, requiere menos recursos computacionales.

Figura 1: Tareas agrupadas para ANN y KNN exacto en diferentes combinaciones en Elasticsearch y OpenSearch.

Los grupos como knn-10-100 implican una búsqueda KNN con y . En la búsqueda vectorial HNSW, determina el número de vecinos más cercanos a recuperar para un vector de consulta. Especifica cuántos vectores similares se deben encontrar como resultado. establece el número de vectores candidatos a recuperar en cada segmento. Más candidatos pueden mejorar la precisión, pero requieren mayores recursos computacionales.

También probamos con diferentes técnicas de cuantización y aprovechamos las optimizaciones específicas del motor; los resultados detallados para cada pista, tarea y motor vectorial están disponibles a continuación.

KNN exacto y KNN aproximado

Al tratar con conjuntos de datos y casos de uso variados, el enfoque correcto para la búsqueda vectorial será diferente. En este blog, todas las tareas indicadas como knn-* como knn-10-100 utilizan KNN aproximado y script-score-* se refieren a KNN exacto, pero ¿en qué se diferencian y por qué son importantes?

En definitiva, si estás manejando conjuntos de datos más sustanciales, el método preferido es Approximate K-Nearest Neighbor (ANN) debido a su escalabilidad superior. Para conjuntos de datos más modestos que pueden requerir un proceso de filtración, el método Exact KNN es ideal.

El KNN exacto utiliza un método de fuerza bruta, calculando la distancia entre un vector y todos los demás vectores en el conjunto de datos. Luego clasifica estas distancias para encontrar los vecinos más cercanos. Si bien este método garantiza una coincidencia exacta, enfrenta desafíos de escalabilidad para conjuntos de datos grandes y de alta dimensionalidad. Sin embargo, hay muchos casos en los que se necesita un KNN exacto:

• Recalificación: En escenarios que involucran búsquedas léxicas o semánticas seguidas de recalificación basada en vectores, el KNN exacto es esencial. Por ejemplo, en un motor de búsqueda de productos, los resultados de búsqueda iniciales se pueden filtrar en función de consultas textuales (por ejemplo, palabras clave, categorías) y luego se emplean vectores asociados con los elementos filtrados para una evaluación de similitud más precisa.

• Personalización: Al tratar con un gran número de usuarios, cada uno representado por un número relativamente pequeño (como 1 millón) de vectores distintos, la clasificación del índice por metadatos específicos del usuario (por ejemplo, user_id) y el cálculo de puntajes mediante fuerza bruta con vectores se vuelve eficiente. Este enfoque permite recomendaciones personalizadas o la entrega de contenido basadas en comparaciones vectoriales precisas adaptadas a las preferencias individuales del usuario.

Por lo tanto, Exact KNN garantiza que la clasificación final y las recomendaciones basadas en la similitud de vectores sean precisas y estén adaptadas a las preferencias del usuario.

Por otro lado, el KNN aproximado (o ANN) emplea métodos para que la búsqueda de datos sea más rápida y eficaz que el KNN exacto, especialmente en conjuntos de datos grandes y de alta dimensionalidad. En lugar de un enfoque de fuerza bruta, que mide la distancia más cercana exacta entre una consulta y todos los puntos, lo que plantea problemas de cálculo y escalado, el ANN emplea ciertas técnicas para reestructurar de forma eficiente los índices y las dimensiones de los vectores buscables en el conjunto de datos. Aunque esto puede provocar una ligera imprecisión, aumenta considerablemente la velocidad del proceso de búsqueda, lo que lo convierte en una alternativa eficaz para tratar con grandes conjuntos de datos.

En este blog, todas las tareas indicadas como knn-* como knn-10-100 usan KNN aproximado y script-score-* se refieren a KNN exacto.

Metodología de prueba

Si bien Elasticsearch y OpenSearch son similares en términos de API para las operaciones de búsqueda BM25, ya que este último es una bifurcación del primero, no ocurre lo mismo con la búsqueda vectorial, que se introdujo después de la bifurcación. OpenSearch adoptó un enfoque diferente al de Elasticsearch en lo que respecta a los algoritmos, al introducir otros dos motores — nmslib y faiss — además de lucene, cada uno con sus configuraciones y limitaciones específicas (por ejemplo, nmslib en OpenSearch no permite filtros, una característica esencial para muchos casos de uso).

Los tres motores utilizan el algoritmo Hierarchical Navigable Small World (HNSW), que es eficiente para la búsqueda aproximada de vecinos más cercanos y especialmente potente al trabajar con datos de alta dimensionalidad. Es importante señalar que faiss también admite un segundo algoritmo, ivf, pero dado que requiere entrenamiento previo en el conjunto de datos, nos centraremos únicamente en HNSW. La idea núcleo de HNSW es organizar los datos en varias capas de grafos conectados, donde cada capa representa una granularidad diferente del conjunto de datos. La búsqueda comienza en la capa superior con la vista más burda y progresa hacia capas cada vez más finas hasta llegar al nivel base.

Ambos motores de búsqueda se probaron en condiciones idénticas en un entorno controlado para asegurar la imparcialidad. El método aplicado es similar a esta comparación de rendimiento publicada anteriormente, con grupos de nodo dedicados para Elasticsearch, OpenSearch y Rally. El script de terraform está disponible (junto con todas las fuentes) para provisionar un clúster de Kubernetes con:

• 1 grupo de nodo para Elasticsearch con 3 e2-standard-32 máquinas (128 GB de RAM y 32 CPU)

• Grupo de 1 Node para OpenSearch con 3 máquinas e2-standard-32 (128 GB de RAM y 32 CPU)

• Grupo de 1 Node para Rally con 2 máquinas t2a-standard-16 (64 GB de RAM y 16 CPU)

Cada "pista" (o prueba) se ejecutó 10 veces para cada configuración, que incluyó diferentes motores, diferentes configuraciones y diferentes tipos de vectores. Las pistas tienen tareas que se repiten entre 1000 y 10 000 veces, dependiendo de la pista. Si una de las tareas de una pista fallaba, por ejemplo, debido a un tiempo de espera de red, todas las tareas se descartaban, por lo que todos los resultados representan pistas que comenzaron y terminaron sin problemas. Todos los resultados de las pruebas se validan estadísticamente, lo que garantiza que las mejoras no sean una coincidencia.

Resultados detallados

¿Por qué comparar usando el percentil 99 y no el promedio de latencia? Consideremos un ejemplo hipotético de los precios promedio de las viviendas en un barrio determinado. El precio promedio puede indicar una zona cara, pero en una inspección más cercana, puede resultar que la mayoría de las viviendas estén valoradas mucho más bajo, con solo unas pocas propiedades de lujo inflando la cifra promedio. Esto ilustra cómo el precio promedio puede no representar con precisión el espectro completo de valores de las viviendas en esa zona. Esto es similar a examinar los tiempos de respuesta, en los que el promedio puede ocultar problemas críticos.

Tareas

• KNN aproximado con k:10 n:50

• KNN aproximado con k:10 n:100

• KNN aproximado con k:100 n:1000

• KNN aproximado con k:10 n:50 y filtros de palabras clave

• KNN aproximado con k:10 n:100 y filtros de palabras clave

• KNN aproximado con k:100 n:1000 y filtros de palabras clave

• KNN aproximado con k:10 n:100 en combinación con indexación

• KNN exacto (puntaje del script)

Motores vectoriales

• lucene en Elasticsearch y OpenSearch, ambos en la versión 9.10

• faiss en OpenSearch

• nmslib en OpenSearch

Tipos de vectores

• hnsw en Elasticsearch y OpenSearch

• int8_hnsw en Elasticsearch (HNSW con cuantificación automática de 8 bits: enlace)

• sq_fp16 hnsw en OpenSearch (HNSW con cuantificación automática de 16 bits: enlace)

Búsqueda de segmentos concurrentes y lista para usar

Como probablemente sabes, Lucene es una biblioteca de motor de búsqueda de texto de alto rendimiento escrita en Java que sirve como estructura para muchas plataformas de búsqueda como Elasticsearch, OpenSearch y Solr. Básicamente, Lucene organiza los datos en segmentos, que son esencialmente índices autónomos que permiten a Lucene ejecutar búsquedas de manera más eficiente. Entonces, cuando emites una búsqueda a cualquier motor de búsqueda basado en Lucene, tu búsqueda terminará siendo ejecutada en esos segmentos, ya sea secuencialmente o en paralelo.

OpenSearch introdujo la búsqueda de segmentos concurrentes como una opción adicional y no la utiliza por defecto; debes habilitarla mediante una configuración especial del índice index.search.concurrent_segment_search.enabled como se detalla aquí, con algunas limitaciones.

Elasticsearch, por otro lado, hace búsquedas en segmentos de forma concurrente listas para usar, por lo que las comparaciones que hacemos en este blog tendrán en cuenta, además de los diferentes motores de vectores y tipos de vectores, también las diferentes configuraciones:

• Elasticsearch ootb: Elasticsearch listo para usar, con búsqueda concurrente por segmentos;

• OpenSearch ootb: sin búsqueda concurrente de segmentos habilitada;

• OpenSearch css: con búsqueda concurrente de segmentos habilitada

Comencemos con algunos resultados detallados para cada conjunto de datos vectoriales probado:

2,5 millones de vectores, 1536 dimensiones (openai_vector)

Comenzando con la ruta más simple, pero también la más grande en términos de dimensiones, openai_vector, que utiliza el conjunto de datos NQ enriquecido con incrustaciones generadas usando el modelo text-embedding-ada-002 de OpenAI. Es el más simple ya que solo prueba KNN aproximado y tiene solo 5 tareas. Se prueba de forma independiente (sin indexar) así como junto con la indexación, y utilizando un solo cliente y 8 clientes simultáneos.

Tareas

• standalone-search-knn-10-100-multiple-clients: búsqueda en 2,5 millones de vectores con 8 clientes simultáneamente, k: 10 y n:100

• standalone-search-knn-100-1000-multiple-clients: búsqueda en 2,5 millones de vectores con 8 clientes simultáneamente, k: 100 y n:1000

• standalone-search-knn-10-100-single-client: búsqueda en 2,5 millones de vectores con un solo cliente, k: 10 y n:100

• standalone-search-knn-100-1000-single-client: búsqueda en 2,5 millones de vectores con un solo cliente, k: 100 y n: 1000

• parallel-documents-indexing-search-knn-10-100: búsqueda en 2.5 millones de vectores mientras se indexan 100 000 documentos adicionales, k:10 y n:100

El rendimiento promedio del p99 se describe a continuación:

Aquí observamos que Elasticsearch es de 3x a 8x más rápido que OpenSearch al realizar la búsqueda vectorial junto con la indexación (por ej. lectura+escritura) con :10 y :100 y de 2x a 3x más rápido sin indexar para los mismos k y n. Para :100 y :1000 (standalone-search-knn-100-1000-single-client y standalone-search-knn-100-1000-multiple-clients Elasticsearch es de 2x a 7x más rápido que OpenSearch, en promedio.

Los resultados detallados muestran los casos exactos y los motores vectoriales comparados:

Recall

knn-recall-10-100

knn-recall-100-1000

Elasticsearch-8.14.0@lucene-hnsw

0.969485

0.995138

Elasticsearch-8.14.0@lucene-int8_hnsw

0.781445

0.784817

OpenSearch-2.14.0@lucene-hnsw

0.96519

0.995422

OpenSearch-2.14.0@faiss

0.984154

0.98049

OpenSearch-2.14.0@faiss-sq_fp16

0.980012

0.97721

OpenSearch-2.14.0@nmslib

0.982532

0.99832

10 millones de vectores, 96 dimensiones (dense_vector)

En dense_vector con 10M vectores y 96 dimensiones. Se basa en el conjunto de datos de imágenes Yandex DEEP1B. El conjunto de datos se crea a partir de los primeros 10 millones de vectores del archivo "sample data" llamado learn.350M.fbin. Las operaciones de búsqueda utilizan vectores de la búsqueda de archivos "query data".public.10K.fbin.

Tanto Elasticsearch como OpenSearch funcionan muy bien en este conjunto de datos, especialmente después de un force merge, que generalmente se realiza en índices de solo lectura y es similar a desfragmentar el índice para tener una sola "tabla" en la que realizar la búsqueda.

Tareas

Cada tarea se prepara para 100 solicitudes y luego se miden 1000 solicitudes

• knn-search-10-100: búsqueda en 10 millones de vectores, k: 10 y n:100

• knn-search-100-1000: búsqueda en 10 millones de vectores, k: 100 y n: 1000

• knn-search-10-100-force-merge: búsqueda en 10 millones de vectores después de una fusión forzada, k: 10 y n:100

• knn-search-100-1000-force-merge: búsqueda en 10 millones de vectores después de una fusión forzada, k: 100 y n:1000

• knn-search-100-1000-concurrent-with-indexing: búsqueda en 10 millones de vectores mientras también se actualiza el 5 % del conjunto de datos, k: 100 y n: 1000

• script-score-query: búsqueda KNN exacta de 2000 vectores específicos.

Tanto Elasticsearch como OpenSearch tuvieron un buen desempeño para el KNN aproximado. Cuando el índice se fusiona (es decir, tiene un solo segmento) en knn-search-100-1000-force-merge y knn-search-10-100-force-merge, OpenSearch funciona mejor que los demás cuando se usan nmslib y faiss, aunque todos estén alrededor de 15 ms y todos muy cerca.

Sin embargo, cuando el índice tiene varios segmentos (una situación típica en la que un índice recibe actualizaciones de sus documentos) en knn-search-10-100 y knn-search-100-1000, Elasticsearch mantiene la latencia en aproximadamente ~7 ms y ~16 ms, mientras que todos los demás motores de OpenSearch son más lentos.

También cuando se busca en el índice y se indexa en él al mismo tiempo (knn-search-100-1000-concurrent-with-indexing), Elasticsearch mantiene la latencia por debajo de 15 ms (a 13.8 ms), siendo casi 4x más rápido que OpenSearch out-of-the-box (49.3 ms) y aún más rápido cuando se habilita la búsqueda concurrente por segmentos (17.9 ms), pero demasiado cerca para ser significativo.

En cuanto al KNN exacto, la diferencia es mucho mayor: Elasticsearch es 6 veces más rápido que OpenSearch (~260 ms vs ~1600 ms).

Recall

knn-recall-10-100

knn-recall-100-1000

Elasticsearch-8.14.0@lucene-hnsw

0.969843

0.996577

Elasticsearch-8.14.0@lucene-int8_hnsw

0.775458

0.840254

OpenSearch-2.14.0@lucene-hnsw

0.971333

0.996747

OpenSearch-2.14.0@faiss

0.9704

0.914755

OpenSearch-2.14.0@faiss-sq_fp16

0.968025

0.913862

OpenSearch-2.14.0@nmslib

0.9674

0.910303

2 millones de vectores, 768 dimensiones (so_vector)

Esta pista, so_vector, se deriva de un volcado de publicaciones de StackOverflow descargadas el 21 de abril de 2022. Solo contiene documentos de preguntas; se eliminaron todos los documentos que representan respuestas. Cada título de pregunta se codificó en un vector usando el modelo de transformador de oraciones multi-qa-mpnet-base-cos-v1. Este conjunto de datos contiene los primeros 2 millones de preguntas.

A diferencia de la pista anterior, cada documento aquí contiene otros campos además de vectores para soportar características de prueba como KNN aproximado con filtrado y búsqueda híbrida. nmslib para OpenSearch está notablemente ausente en esta prueba ya que no admite filtros.

Tareas

Cada tarea se calienta con 100 solicitudes y luego se miden 100 solicitudes. Tenga en cuenta que las tareas se agruparon por simplicidad, ya que la prueba contiene 16 tipos de búsqueda * 2 valores k diferentes * 3 valores n diferentes.

• knn-10-50: búsqueda en 2 millones de vectores sin filtros, k:10 y n:50

• knn-10-50-filtered: búsqueda en 2 millones de vectores con filtros, k:10 y n:50

• knn-10-50-after-force-merge: búsqueda en 2 millones de vectores con filtros y después de una fusión forzosa, k:10 y n:50

• knn-10-100: búsqueda en 2 millones de vectores sin filtros, k:10 y n:100

• knn-10-100-filtered: búsqueda en 2 millones de vectores con filtros, k:10 y n:100

• knn-10-100-after-force-merge: búsqueda en 2 millones de vectores con filtros y luego de una fusión forzada, k: 10 y n: 100

• knn-100-1000: búsqueda en 2 millones de vectores sin filtros, k:100 y n:1000

• knn-100-1000-filtered: búsqueda en 2 millones de vectores con filtros, k:100 y n:1000

• knn-100-1000-after-force-merge: búsqueda en 2 millones de vectores con filtros y luego de una fusión forzada, k:100 y n:1000

• exact-knn: búsqueda de KNN exacto con y sin filtros.

Elasticsearch es consistentemente más rápido que OpenSearch de manera inmediata en esta prueba, solo en dos casos OpenSearch es más rápido, y no por mucho (knn-10-100 y knn-100-1000). Las tareas que involucran knn-10-50, knn-10-100 y knn-100-1000 en combinación con filtros muestran una diferencia de hasta 7 veces (112 ms versus 803 ms).

El rendimiento de ambas soluciones parece igualarse después de un "force merge" (fusión forzada), lógicamente, como lo demuestran knn-10-50-after-force-merge, knn-10-100-after-force-merge y knn-100-1000-after-force-merge. En esas tareas, faiss es más rápido.

Como mencionamos, el rendimiento para Exact KNN es muy diferente, ya que Elasticsearch fue 13 veces más rápido que OpenSearch esta vez (~385 ms vs ~5262 ms).

Recall

knn-recall-10-100

knn-recall-100-1000

knn-recall-10-50

Elasticsearch-8.14.0@lucene-hnsw

1

1

1

Elasticsearch-8.14.0@lucene-int8_hnsw

1

0.986667

1

OpenSearch-2.14.0@lucene-hnsw

1

1

1

OpenSearch-2.14.0@faiss

1

1

1

OpenSearch-2.14.0@faiss-sq_fp16

1

1

1

OpenSearch-2.14.0@nmslib

0.9674

0.910303

0.976394

Elasticsearch y Lucene como claros vencedores

En Elastic, estamos innovando incansablemente Apache Lucene y Elasticsearch para garantizar que podamos proporcionar la base de datos vectorial de primer nivel para casos de uso de búsqueda y recuperación, incluido RAG (Retrieval Augmented Generation). Nuestros últimos avances han aumentado significativamente el rendimiento, haciendo que la búsqueda vectorial sea más rápida y eficiente en cuanto a espacio que antes, basándose en las mejoras de Lucene 9.10. En este blog, se presentó un estudio que muestra que al comparar versiones actualizadas, Elasticsearch es hasta 12 veces más rápido que OpenSearch.

Vale la pena señalar que ambos productos usan la misma versión de Lucene (Notas de lanzamiento de Elasticsearch 8.14 y Notas de lanzamiento de OpenSearch 2.14).

El ritmo de innovación en Elastic ofrecerá aún más, no solo para nuestros clientes locales y de Elastic Cloud, sino también para aquellos que utilizan nuestra plataforma sin estado. Las características como el soporte para la cuantificación escalar a int4 se ofrecerán con pruebas rigurosas para garantizar que los clientes puedan utilizar estas técnicas sin una caída significativa en la recuperación, similar a nuestras pruebas para int8.

La eficiencia de la búsqueda vectorial se está convirtiendo en una característica no negociable en los motores de búsqueda modernos debido a la proliferación de aplicaciones de inteligencia artificial y machine learning. Para las organizaciones que buscan un motor de búsqueda poderoso capaz de mantenerse al día con las demandas de datos vectoriales de alto volumen y alta complejidad, Elasticsearch es la respuesta definitiva.

Ya sea que quieres expandir una plataforma establecida o iniciar nuevos proyectos, integrar Elasticsearch para las necesidades de búsqueda vectorial es un movimiento estratégico que generará beneficios tangibles a largo plazo. Con su ventaja de rendimiento comprobada, Elasticsearch está a punto de apuntalar la próxima ola de innovaciones en búsqueda.