Nuestros benchmarks en un corpus de documentos de 20M muestran que Elasticsearch ofrece hasta 8 veces más rendimiento que OpenSearch para búsqueda vectorial filtrada, además de lograr mayores Recall@100 en las configuraciones que probamos. La ingeniería de contexto depende de más que la rápida recuperación de vectores. Los equipos también necesitan fuertes controles de relevancia, como búsqueda y filtrado híbridos, simplicidad operativa y rendimiento predecible, a medida que los flujos de trabajo se repiten. Pero como los agentes suelen ejecutar bucles de recuperación y razonamiento muchas veces por cada solicitud, la latencia de la recuperación se convierte en un factor multiplicador, por lo que las mejoras en este aspecto se traducen directamente en una mejor capacidad de respuesta de extremo a extremo y en un menor costo.

En la ingeniería de contexto, la recuperación no es un paso único. Los agentes y las aplicaciones ejecutan bucles repetidamente, como recuperar → razonar → recuperar, para refinar consultas, verificar hechos, reunir contexto fundamentado y completar tareas. Este patrón es común en los flujos de trabajo agénticos y en la Retrieval-Augmented Generation (RAG) iterativa. Como la recuperación puede invocarse muchas veces por cada consulta del usuario, agrega demora a la respuesta o aumenta los costos de infraestructura.

¿Por qué es crítico el rendimiento de la búsqueda de vectores?

Imagina un asistente de compras respondiendo la pregunta: "Necesito una mochila de equipaje de mano de menos de $60 que quepa una laptop de 15 pulgadas, sea resistente al agua y pueda llegar para el viernes".

En producción, el asistente rara vez emite una consulta vectorial y se detiene ahí. Ejecuta un ciclo de recuperación para crear el contexto correcto, y cada paso suele estar limitado por filtros, como disponibilidad, región, promesa de envío, reglas de marca y elegibilidad de políticas.

Paso 1: Interpretar la intención y traducirla a restricciones.

El agente convierte la solicitud en filtros estructurados y una consulta semántica, tales como:

• Filtros: En stock, entregable al código postal del usuario, entrega antes del viernes, precio inferior a $60, listado válido

• Consulta vectorial: "Mochila de equipaje de mano computadora portátil de 15 pulgadas resistente al agua"

Paso 2: Recuperar candidatos y luego refinar la selección.

A menudo repite la recuperación con variaciones para evitar perder buenas coincidencias:

• "mochila de viaje de equipaje de mano con funda para computadora portátil"

• "mochila de viaje resistente al agua de 15 pulgadas"

• “mochila de cabina ligera”

Cada consulta utiliza los mismos filtros de elegibilidad, porque recuperar elementos irrelevantes o no disponibles es un desperdicio de contexto.

Paso 3: Expandir para confirmar detalles y reducir el riesgo.

A continuación, el agente vuelve a consultar para verificar los atributos clave que influyen en la respuesta final:

• Palabras utilizadas para describir los materiales y la resistencia al agua

• Dimensiones y ajuste del compartimento de la computadora portátil

• Restricciones de la garantía o política de devolución

• Opciones alternativas si hay poco inventario

Esto es ingeniería de contexto en múltiples pasos: recuperar, razonar, recuperar, ensamblar.

¿Por qué la latencia y la recuperación son importantes para la ingeniería de contexto?

Estas interacciones pueden implicar decenas de llamadas de recuperación filtradas por sesión de usuario. Eso hace que la latencia por llamada sea un multiplicador directo en el tiempo de respuesta de extremo a extremo, y la baja recuperación obliga a reintentos adicionales o hace que el agente pierda elementos elegibles, lo que degrada la calidad de la respuesta.

Conclusión: En sistemas diseñados con contexto, los vecinos más cercanos aproximados (ANN, por su sigla en inglés) filtrados no son una sola consulta. Es una operación repetida bajo restricciones, por lo que el rendimiento de la búsqueda vectorial se nota enseguida en la latencia, la capacidad de procesamiento y el costo, incluso cuando el modelo de lenguaje grande (LLM) es el componente más visible.

Evaluación comparativa

Resultados

En el grafo 2, cada punto representa una configuración de prueba. Los mejores resultados aparecen hacia la parte superior izquierda, lo que significa una mayor recuperación con menor latencia. Los resultados de Elasticsearch se sitúan sistemáticamente más cerca de la esquina superior izquierda que los de OpenSearch, lo que indica una mayor velocidad y precisión con los mismos ajustes de carga de trabajo.

Algunas ideas clave

• s_n_r_value: La abreviatura de size_numCandidates_rescoreOversample (k y numCandidates iguales a numCandidates en estas pruebas), por ejemplo, 100_500_1 significa tamaño=100, numCandidates=500 y k=500, rescore oversample=1

• Recuperación: Mide Recall@100 para esa configuración

• Latencia promedio (ms): Latencia de extremo a extremo promedio por consulta

• Rendimiento: Búsquedas por segundo

• Recall %: Mejora relativa de recuperación de Elasticsearch frente a OpenSearch (Elasticsearch menos OpenSearch)/OpenSearch

• Latencia Xs: Latencia promedio de OpenSearch dividida por la latencia media de Elasticsearch

• Rendimiento Xs: rendimiento de Elasticsearch dividido por el rendimiento de OpenSearch

Motor

's_n_r_value'

Recuperación

Latencia promedio (ms)

Rendimiento

Porcentaje de recuperación

Latencia Xs

Rendimiento Xs

Elasticsearch

100_250_1

0.7704

25

534.75

9.70 %

2.28

1.91

OpenSearch

100_250_1

0.7023

57.08

279.58

Elasticsearch

100_500_1

0.8577

25.42

524.14

7.20 %

2.4

2

OpenSearch

100_500_1

0.8001

60.9

262.12

Elasticsearch

100_750_1

0.8947

29.67

528.09

5.72 %

2.25

2.21

OpenSearch

100_750_1

0.8463

66.76

239.11

Elasticsearch

100_1000_1

0.9156

29.65

534.5

4.66 %

2.46

2.44

OpenSearch

100_1000_1

0.8748

72.88

219.01

Elasticsearch

100_1500_1

0.9386

31.84

497.3

3.38 %

2.71

2.68

OpenSearch

100_1500_1

0.9079

86.16

185.4

Elasticsearch

100_2000_1

0,9507

34.69

457.2

2.57 %

2.98

2.96

OpenSearch

100_2000_1

0.9269

103.36

154.55

Elasticsearch

100_2500_1

0.9582

37.9

418.43

1.99 %

3.28

3.26

OpenSearch

100_2500_1

0.9395

124.29

128.53

Elasticsearch

100_3000_1

0.9636

41.86

379.4

1.62 %

3.46

3.44

OpenSearch

100_3000_1

0.9482

144.67

110.34

Elasticsearch

100_4000_1

0.9705

50.28

316.21

1,06%

3.87

3.85

OpenSearch

100_4000_1

0.9603

194.36

82.22

Elasticsearch

100_5000_1

0.9749

58.77

270.91

0.73 %

4.43

4.41

OpenSearch

100_5000_1

0.9678

260.33

61.38

Elasticsearch

100_6000_1

0.9781

66.75

238.59

0.52 %

4.91

4.89

OpenSearch

100_6000_1

0.973

327.44

48.81

Elasticsearch

100_7000_1

0.9804

74.64

213.49

0.38 %

5.28

5.27

OpenSearch

100_7000_1

0.9767

394.24

40.53

Elasticsearch

100_8000_1

0.9823

82.28

193.59

0.27 %

6.86

6.83

OpenSearch

100_8000_1

0.9797

564.14

28.33

Elasticsearch

100_9000_1

0.9837

90.08

176.96

0.16 %

7.63

7.61

OpenSearch

100_9000_1

0.9821

687.25

23.25

Elasticsearch

100_10000_1

0.9848

97.64

163.31

0.08 %

8.38

8.36

OpenSearch

100_10000_1

0.984

818.64

19.53

Por ejemplo, en 100_9000_1, OpenSearch tiene un promedio de 687 milisegundos por recuperación frente a 90 milisegundos en Elasticsearch, y en un bucle de recuperación de 10 pasos eso equivale a aproximadamente 10 × (687 - 90) = seis segundos de tiempo de espera adicional.

Consulta los resultados completos.

Metodología

Al usar Python para enviar las consultas y rastrear el tiempo de respuesta y otras estadísticas, enviamos las siguientes consultas a los motores. Ten en cuenta que el rendimiento de cualquier motor de búsqueda vectorial depende de cómo ajustes sus parámetros núcleo: cuántos candidatos considerar, cuán agresivamente volver a puntuar y cuánto contexto devolver. Estos ajustes afectan directamente tanto la exhaustividad (la probabilidad de encontrar la respuesta correcta) como la latencia (la rapidez con la que obtienes los resultados).

En nuestras pruebas comparativas, empleamos la misma configuración de candidatos, repuntuación y tamaño de resultados que normalmente ajustarías en un bucle de recuperación basado en agentes, y medimos el rendimiento de Elasticsearch bajo esa carga de trabajo. Luego ejecutamos OpenSearch con la misma configuración como referencia.

OpenSearch

• "size": <RESULT_SIZE>: Número de resultados devueltos al cliente. En esta prueba de rendimiento, el tamaño del conjunto de datos es 100 para calcular el Recall@100.

• "k": <NUMBER_OF_CANDIDATES>: El número de candidatos a vecinos más cercanos.

• "ef_search": <NUMBER_OF_CANDIDATES>: El número de vectores a examinar.

• "oversample_factor": <OVERSAMPLE>: ¿Cuántos vectores candidatos se recuperan antes de volver a calcular la puntuación?

Elasticsearch

• "size": <RESULT_SIZE>: Número de resultados devueltos al cliente. En esta prueba de rendimiento, el tamaño del conjunto de datos es 100 para calcular el Recall@100.

• "k": <NUMBER_OF_CANDIDATES>: Número de vecinos más cercanos que se debe devolver desde cada shard.

• "num_candidates": <NUMBER_OF_CANDIDATES>: Número de candidatos de vecinos más cercanos a considerar por shard mientras se realiza la búsqueda de knn.

• "oversample": <OVERSAMPLE>: ¿Cuántos vectores candidatos se recuperan antes de volver a calcular la puntuación?

Ejemplo

Knn la búsqueda, (100_500_1), sería de la siguiente manera:

OpenSearch

Elasticsearch

La configuración completa, junto con scripts de Terraform, manifiestos de Kubernetes y el código de benchmarking, está disponible en este repositorio en la carpeta es-9.3-vs-os-3.5-vector-search.

La configuración del cluster

Ejecutamos nuestras pruebas en seis servidores cloud e2-standard-16, cada uno con 16 vCPUs y 64 GB de RAM. En cada servidor, asignamos 15 vCPUs y 56 GB de RAM a cada pod de Kubernetes que ejecutaba el nodo del motor de búsqueda, con 28 GB reservados para el heap de JVM.

Los clústeres ejecutaban Elasticsearch 9.3.0 y OpenSearch 3.5.0 (Lucene 10.3.2). Dado que ambos sistemas emplean la misma versión de Lucene en esta prueba comparativa, las diferencias de rendimiento y latencia que observamos no pueden atribuirse únicamente a Lucene, sino que reflejan diferencias en la forma en que cada motor integra y ejecuta la recuperación y recalculación filtradas del algoritmo k-vecinos más cercanos (kNN). Usamos un único índice con tres shards primarios y una réplica (es decir, 6 shards en total, 1 por nodo).

También usamos un servidor independiente en la misma región para ejecutar el cliente de pruebas de rendimiento y recopilar estadísticas de tiempos.

El set de datos

Para este benchmark, empleamos un set de datos de incrustación de catálogos de tipo comercio electrónico a gran escala con 20 millones de documentos, diseñado para reflejar la recuperación vectorial filtrada a escala del mundo real.

Cada documento representa un artículo del catálogo e incluye:

• Un vector denso incrustado de 128 dimensiones utilizado para la recuperación aproximada de kNN.

• Campos estructurados de metadatos usados para filtrar (por ejemplo, validez y disponibilidad de artículos más otras restricciones del catálogo) que permiten el patrón común de producción de recuperar a los vecinos más cercanos, pero solo dentro de un subconjunto elegible.

Elegimos este set de datos porque captura el núcleo del desafío principal de rendimiento que vemos en sistemas agentes y de estilo RAG en producción: la similitud vectorial por sí sola no es suficiente, la recuperación está frecuentemente limitada por filtros y el sistema debe mantener una alta recuperación a la vez que mantiene baja la latencia bajo esas restricciones. En comparación con sets de datos más pequeños de estilo QA, un corpus de 20M de documentos también refleja mejor la escala y la presión de los candidatos que enfrentan los sistemas de ANN filtrados en la práctica.

Conclusión

En las arquitecturas de IA modernas, especialmente aquellas construidas alrededor de la ingeniería de contexto, la velocidad de búsqueda vectorial no es un detalle de implementación menor. Es un multiplicador. Cuando los agentes y los flujos de trabajo iteran a través de recuperar → razonar → recuperar, el rendimiento de la recuperación da forma directamente a la latencia de extremo a extremo, al rendimiento y a la calidad del contexto que se introduce en el modelo.

En nuestras pruebas de referencia, Elasticsearch ofreció consistentemente una mayor recuperación con menor latencia que OpenSearch en escenarios donde la corrección depende de recuperar el documento correcto, no solo de un vector similar. En un set de datos controlado, la diferencia es clara, y en producción esos avances se acumulan a lo largo de grandes volúmenes de llamadas de recuperación, lo que mejora la capacidad de respuesta, aumenta el margen de capacidad y reduce los costos de infraestructura.

Lecturas adicionales

1. ¿Qué es la ingeniería de contexto?

2. La evolución de la búsqueda híbrida y la ingeniería de contexto

3. El impacto de la relevancia en la ingeniería de contexto para agentes de IA

Todas las consultas y salidas completas mencionadas en este artículo se pueden encontrar en nuestro repositorio de código de Elasticsearch Labs.

¿Por qué implementar Better Binary Quantization (BBQ) en tu caso de uso?

Aunque las matemáticas son interesantes, son cruciales si quieres comprender completamente por qué tus búsquedas vectoriales siguen siendo precisas. En última instancia, todo esto se reduce a la compresión, ya que resulta que con los algoritmos actuales de búsqueda vectorial estás limitado por la velocidad de lectura de los datos. Por lo tanto, si puedes meter todos esos datos en la memoria, obtienes un aumento significativo de velocidad en comparación con leer desde el almacenamiento (la memoria es aproximadamente 200 veces más rápida que los SSD).

Hay algunas cosas a tener en cuenta:

• Los índices basados en gráficos como HNSW (Hierarchical Navigable Small World) son los más rápidos para la recuperación de vectores.

  • HNSW: Un algoritmo de búsqueda aproximado del vecino más cercano que construye una estructura de gráficos multicapa para permitir búsquedas eficientes de similitud de alta dimensión.

• HNSW está fundamentalmente limitado en velocidad por la velocidad de lectura de datos de la memoria o, en el peor de los casos, del almacenamiento.

  • Idealmente, desea poder cargar todos sus vectores almacenados en la memoria.

• Los modelos de incrustación generalmente producen vectores con precisión float32, 4 bytes por número de punto flotante.

• Y finalmente, dependiendo de cuántos vectores y / o dimensiones tenga, puede quedar sin memoria muy rápidamente para mantener todos sus vectores.

Dando esto por sentado, ve que surge un problema rápidamente una vez que comienza a ingerir millones o incluso miles de millones de vectores, cada uno con potencialmente cientos o incluso miles de dimensiones. La sección titulada "Números aproximados en las relaciones de compresión" proporciona algunos números aproximados.

¿Qué necesitas para empezar?

Para comenzar, necesitará lo siguiente:

• Si usas Elastic Cloud o en las instalaciones, necesitarás una versión de Elasticsearch superior a la 8.18. Si bien BBQ se introdujo en 8.16, en este artículo, usará vector_rescore, que se introdujo en 8.18.

• Además, también deberá cerciorar de que haya un nodo de aprendizaje automático (ML) en el clúster. (Nota: se necesita un nodo de ML con un mínimo de 4 GB para cargar el modelo, pero es probable que necesite nodos mucho más grandes para cargas de trabajo de producción completas).

• Si emplea Serverless, deberá seleccionar una instancia optimizada para vectores.

• También necesitará un nivel básico de conocimiento sobre bases de datos vectoriales. Si aún no estás familiarizado con los conceptos de búsqueda vectorial en Elastic, es posible que desees consultar primero los siguientes recursos:

  • Navegación por una base de datos vectorial elástica

  • Las grandes ideas detrás de la generación aumentada de recuperación

Mejor implementación de cuantización binaria (BBQ)

Para simplificar este blog, empleará funciones integradas cuando estén disponibles. En este caso, tienes el modelo de incrustación de vectores .multilingual-e5-small que se ejecutará directamente dentro de Elasticsearch en un nodo de aprendizaje automático. Tenga en cuenta que puede reemplazar el modelo text_embedding con el incrustador de su elección (OpenAI, Google AI Studio, Cohere y muchos más). Si su modelo preferido aún no está integrado, también puede traer sus propias incrustaciones de vectores densos).

En primer lugar, deberá crear un punto de enlace de inferencia para generar vectores para un fragmento de texto determinado. Ejecutarás todos estos comandos desde la consola de herramientas de desarrollo de Kibana. Este comando descargará el .multilingual-e5-small. Si aún no existe, configurará su punto final; Esto puede tardar un minuto en ejecutar. Puede ver la salida esperada en el archivo 01-create-an-inference-endpoint-output.json en la carpeta Salidas.

Una vez que esto regresó, su modelo se configurará y podrá probar que el modelo funciona como se espera con el siguiente comando. Puede ver el resultado esperado en el archivo 02-embed-text-output.json en la carpeta Salidas.

Si tiene problemas relacionados con el modelo capacitado que no se asigna a ningún nodo, es posible que deba iniciar el modelo manualmente.

Ahora vamos a crear una nueva asignación con 2 propiedades, un campo de texto estándar (my_field) y un campo vectorial denso (my_vector) con 384 dimensiones para que coincida con la salida del modelo de incrustación. También anulará el index_options.type to bbq_hnsw. Puede ver el resultado esperado en el archivo 03-create-byte-qauntized-index-output.json en la carpeta Salidas.

Para cerciorarte de que Elasticsearch genere tus vectores, puedes usar una canalización de ingesta. Esta canalización requerirá 3 cosas: el punto final, (model_id), el input_field para el que desea crear vectores y el output_field en el que almacenar esos vectores. El primer comando siguiente creará una canalización de ingesta de inferencia, que usa el servicio de inferencia en segundo plano, y el segundo probará que la canalización funciona correctamente. Puede ver la salida esperada en el archivo 04-create-and-simulate-ingest-pipeline-output.json en la carpeta Salidas. 

Ahora está listo para agregar algunos documentos con los primeros 2 comandos a continuación y para probar que sus búsquedas funcionan con el 3er comando. Puede desproteger el resultado esperado en el archivo 05-bbq-index-output.json en la carpeta Salidas. 

Como se recomienda en esta publicación, se recomienda volver a puntuar y sobremuestrear cuando se escala a cantidades no triviales de datos porque ayudan a mantener una alta precisión de recuperación mientras se benefician de los beneficios de la compresión. A partir de la versión 8.18 de Elasticsearch, puedes hacerlo de esta manera usando rescore_vector. La salida esperada se encuentra en el archivo 06-bbq-search-8-18-output.json en la carpeta Outputs.

¿Cómo se comparan estos puntajes con los que obtendría por los datos sin procesar? Si vuelves a hacer todo lo anterior pero con index_options.type: hnsw, verás que los puntajes son muy comparables. Puede ver el resultado esperado en el archivo 07-raw-vector-output.json en la carpeta Salidas.

Números aproximados en las relaciones de compresión

Los requisitos de almacenamiento y memoria pueden convertir rápidamente en un desafío importante cuando se trabaja con la búsqueda vectorial. El siguiente desglose ilustra cómo las diferentes técnicas de cuantificación reducen significativamente la huella de memoria de los datos vectoriales.

Vectores (V)

Dimensiones (D)

sin procesar (V x P x 4)

int8 (V x (D x 1 + 4))

int4 (V x (D x 0.5 + 4))

asado (V x (D x 0.125 + 4))

10,000,000

384

14,31 GB

3,61 GB

1,83 GB

0,58 GB

50,000,000

384

71,53 GB

18,07 GB

9,13 GB

2,89 GB

100,000,000

384

143,05 GB

36,14 GB

18,25 GB

5,77 GB

Conclusión

BBQ es una optimización que puede aplicar a sus datos vectoriales para la compresión sin sacrificar la precisión. Funciona convirtiendo vectores en bits, lo que le permite buscar los datos de manera efectiva y le permite escalar sus flujos de trabajo de IA para acelerar las búsquedas y optimizar el almacenamiento de datos.

Aprendizaje adicional

Si está interesado en obtener más información sobre el asado, cerciorar de consultar los siguientes recursos:

• Cuantificación binaria (BBQ) en Lucene y Elasticsearch

• Mejor cuantización binaria (BBQ) frente a cuantificación de productos

• Cuantización escalar optimizada: cuantificación binaria aún mejor

• Mejor cuantificación binaria (BBQ): De bytes a BBQ, el secreto para una mejor búsqueda vectorial por Ben Trent