Rapidez vs. precisión: medición de recuperación de la búsqueda vectorial cuantificada

Todos quieren que la búsqueda de vectores sea instantánea. Pero los vectores de alta dimensión son pesados. Un único vector float-32 de 1024 dimensiones ocupa una memoria significativa, y compararlo con millones de otros es computacionalmente costoso.

Para resolver esto, los motores de búsqueda como Elasticsearch usan dos estrategias principales de optimización:

1. Búsqueda aproximada (mundo pequeño jerárquico navegable [HNSW]): en lugar de examinar cada documento, construimos un grafo de navegación para saltar rápidamente al vecindario probable de la respuesta.
2. Cuantización: Comprimimos los vectores (por ejemplo, de flotantes de 32 bits a enteros de 8 bits o incluso valores binarios de 1 bit) para reducir el uso de memoria y acelerar los cálculos.

Pero la optimización a menudo tiene un precio: la precisión.

El miedo es válido: "Si comprimo mis datos y tomo atajos durante la búsqueda, ¿me perderé los mejores resultados?". "¿Esta optimización degrada la relevancia de mi motor de búsqueda?".

Para demostrar que la cuantificación de Elastic no degrada los resultados, construimos un marco de pruebas repetible mediante el conjunto de datos de DBPedia-14 para calcular exactamente cuánta precisión intercambiamos (específicamente, la recuperación) por velocidad al usar las optimizaciones predeterminadas en Elasticsearch.

Resumen: es probable que sea mucho menos de lo que piensas. Echa un vistazo al cuaderno aquí e inténtalo por tu cuenta

Las definiciones (para los no expertos)

Antes de ver el código, establezcamos algunos términos.

• Relevancia versus recuperación: La relevancia es subjetiva (¿encontré cosas buenas?). La recuperación es matemática. Si hay 10 documentos en la base de datos que son las coincidencias matemáticas perfectas para tu consulta, y el motor de búsqueda encuentra nueve de ellos, tu recuperación es del 90 % (o 0,9).
• Búsqueda exacta (plana): A veces denominado el método de "fuerza bruta". El motor de búsqueda analiza cada uno de los documentos de un índice y calcula la distancia.
  • Pros: 100 % de recuperación perfecta.
  • Contras: computacionalmente caro y lento en escala.
• Búsqueda aproximada (HNSW): El método del "atajo". El motor de búsqueda crea un grafo HNSW. Recorre el grafo para encontrar a los vecinos más cercanos.
  • Ventajas: extremadamente rápido y escalable.
  • Desventajas: podrías perderte algún vecino si el recorrido del grafo se detiene demasiado pronto.

El experimento: exactitud versus aproximación

Para probar la recuperación, usamos el conjunto de datos DBPedia-14, un gran set de datos de títulos y resúmenes de 14 clases de ontología que normalmente se utilizan para entrenar y evaluar modelos de categorización de texto. En concreto, nos centraremos en la categoría de "Cine". Queríamos comparar los ajustes de producción optimizados con una verdad de base matemáticamente perfecta.

Para este experimento, utilizamos el modelo jina-embeddings-v5-text-small, un modelo multilingüe de última generación que lidera los estándares de la industria para la representación de texto. Elegimos este modelo porque define el estándar actual para embeddings de alto rendimiento. Al combinar la precisión de élite de Jina v5 con la cuantización nativa de Elasticsearch, podemos demostrar una arquitectura de búsqueda que es tanto computacionalmente eficiente como intransigente en la calidad de la recuperación.

Configuramos un índice con un mapeo doble. Ingerimos el mismo texto en dos campos diferentes de forma simultánea:

1. content.raw con el tipo: flat. Esto obliga a Elasticsearch a realizar un escaneo por fuerza bruta de los vectores Float32 completos. Esto devuelve resultados de coincidencia exacta y se utilizará para nuestra línea de base.
2. content con tipo semantic_text. Con valores predeterminados que utilizan HNSW + la mejor cuantificación binaria (BBQ). Esta es la configuración de producción estándar y optimizada para una coincidencia aproximada.

La prueba de recall@10

Para nuestra métrica, usamos Recall@10.

Elegimos 50 películas aleatorias y ejecutamos la misma consulta en ambos campos.

• Si la búsqueda exacta (plana) indica que los 10 vecinos más cercanos son los ID [1, 2, 3... 10].
• Y la búsqueda aproximada (HNSW) devuelve los ID [1, 2, 3... 9, 99].
• Encontramos nueve de los 10 principales correctamente. La puntuación es 0,9.

Este es el mapeo que utilizamos:

Los resultados: la "línea plana" del éxito

Realizamos una prueba de escala, recargando el conjunto de datos completo y probando con tamaños de índice de entre 1000 y 40 000 documentos.

Esto es lo que sucedió con la puntuación de recuperación:

Los resultados fueron increíblemente estables. Incluso a medida que escalábamos, la búsqueda aproximada coincidió con la búsqueda exacta de fuerza bruta >99 % del tiempo.

¿Por qué funcionó tan bien?

Podrías esperar que comprimir vectores a valores binarios perjudicaría más la precisión. La razón por la que esto no ocurre está en la forma en que Elasticsearch gestiona la recuperación.

La mayoría de los modelos de incrustación actuales dan como salida vectores Float32, que son grandes. Para hacer la búsqueda eficiente, Elasticsearch emplea cuantización para vectores de alta dimensión. Concretamente, desde la versión 9.2, usa BBQ por defecto.

BBQ usa un mecanismo de recalificación:

1. Recorrido: el motor de búsqueda utiliza los vectores comprimidos (cuantificados) para recorrer rápidamente el grafo HNSW. Como los vectores son pequeños, puedes realizar un sobremuestreo de manera eficiente, recopilando una lista más amplia de candidatos (por ejemplo, los 100 documentos más parecidos) sin que afecte al rendimiento.
2. Recálculo de la puntuación: una vez que obtiene esos candidatos, recupera los valores de precisión completa solo para esos pocos documentos para calcular la clasificación final y precisa.

Esto te brinda lo mejor de ambos mundos, la velocidad de la cuantización para el trabajo pesado y la precisión de los flotantes para la ordenación final.

¿Podemos hacerlo mejor?

Cabe destacar que los resultados que vemos aquí utilizan la configuración predeterminada y una muestra aleatoria de datos. Piensa en esto como un punto de partida de alto rendimiento. Aunque Jina v5 es una bestia, estas puntuaciones de recuperación no son una garantía de "talla única" para todos los conjuntos de datos. Cada conjunto de datos tiene sus propias peculiaridades, y aunque sin duda puedes seguir ajustando los parámetros para obtener un mejor rendimiento, siempre debes realizar pruebas con tus propios datos específicos para ver cuál es tu límite.

Conclusión

Esta es una prueba a muy pequeña escala. Pero el punto del ejercicio no es medir el modelo de incrustación o BBQ específicamente, sino demostrar cómo puedes medir fácilmente la recuperación de tu conjunto de datos con una configuración mínima.

Si quieres ejecutar esta prueba con tus propios datos, puedes consultar el cuaderno aquí e intentarlo por tu cuenta.