Entender cómo funciona el filtrado en la búsqueda vectorial te ayudará a equilibrar los compromisos entre rendimiento y recordación, así como descubrir algunas de las optimizaciones que se usan para que la búsqueda vectorial sea eficiente al usar filtrado.

¿Por qué filtrar?

La búsqueda vectorial revolucionó la forma en que encontramos información relevante en grandes conjuntos de datos, permitiéndonos descubrir elementos que son semánticamente similares a una consulta.

Sin embargo, simplemente encontrar objetos similares no es suficiente. A menudo necesitamos reducir los resultados de búsqueda en función de criterios o atributos específicos.

Imagina que buscas un producto en una tienda online. Una búsqueda vectorial pura puede mostrarte artículos visualmente similares, pero también podrías filtrar por rango de precio, marca, disponibilidad o valoraciones de clientes. Sin filtrar, te presentarías con una gran variedad de productos similares, lo que dificultaría encontrar exactamente lo que buscas.

El filtrado permite un control preciso sobre los resultados de búsqueda, cerciorando que los elementos recuperados no solo se alineen semánticamente, sino que también cumplan todos los requisitos necesarios. Esto conduce a una experiencia de búsqueda mucho más precisa, eficiente y fácil de usar.

Aquí es donde Elasticsearch y Apache Lucene excelen: usar filtrado efectivo entre varios tipos de datos es una de las diferencias clave con otras bases de datos vectoriales.

Filtrado para búsqueda vectorial exacta

Existen dos formas principales de realizar búsquedas vectoriales exactas:

• Usar un tipo de índice flat para tu campo de dense_vector. Esto hace que knn búsquedas empleen la búsqueda exacta en lugar de aproximada.

• Emplear una consulta script_score que emplea funciones vectoriales para calcular el puntaje. Esto puede usar con cualquier tipo de índice.

Al ejecutar una búsqueda vectorial exacta, todos los vectores se comparan con la consulta. En este escenario, el filtrado ayudará al rendimiento, ya que solo se necesitan comparar los vectores que pasan el filtro.

Esto no afecta a la calidad del resultado, ya que todos los vectores se consideran de todos modos. Simplemente filtramos de antemano los resultados que no son interesantes, para poder reducir el número de operaciones.

Esto es muy importante, ya que puede ser más eficiente ejecutar una búsqueda exacta en lugar de una búsqueda aproximada cuando los filtros aplicados resultan en un pequeño número de documentos.

La regla general es usar la búsqueda exacta cuando menos de 10.000 documentos pasan el filtro. Los índices BBQ son mucho más rápidos para comparar, así que tiene sentido usar la búsqueda exacta cuando hay menos de 100k para los índices basados. Consulta esta entrada del blog para más detalles.

Si tus filtros siempre son muy restrictivos, puedes considerar indexar centrado en la búsqueda exacta en lugar de en la búsqueda aproximada, usando un tipo de índice flat en lugar de uno basado en HNSW. Para más detalles, ver las propiedades de index_options.

Filtrado para búsqueda vectorial aproximada

Al ejecutar búsqueda vectorial aproximada, cambiamos la precisión de los resultados por el rendimiento. Las estructuras de datos de búsqueda vectorial como HNSW buscan eficientemente vecinos aproximados en millones de vectores. Se centran en recuperar los vectores más similares haciendo la menor cantidad posible de comparaciones vectoriales, que son costosas de calcular.

Esto significa que otros atributos de filtrado no forman parte de los datos vectoriales. Diferentes tipos de datos tienen sus propias estructuras de indexación que son eficientes para encontrarlos y filtrarlos, como diccionarios de términos, listas de publicación y valores de documentos.

Dado que estas estructuras de datos son independientes del mecanismo de búsqueda vectorial, ¿cómo aplicamos el filtrado a la búsqueda vectorial? Hay dos opciones: aplicar filtros luego de la búsqueda vectorial (postfiltrado) o antes de la búsqueda vectorial (prefiltrado).

Cada una de esas opciones tiene sus pros y sus contras. ¡Vamos a profundizar en ellos!

Postfiltrado

El postfiltrado aplica filtros después de que se realizó la búsqueda vectorial. Esto significa que los filtros se aplican después de que se encontraron los k primeros resultados vectoriales más similares.

Obviamente, podemos obtener menos de k resultados aplicando los filtros a los resultados. Por supuesto, podríamos obtener más resultados de la búsqueda vectorial (valores k más altos), pero no estaremos seguros de obtener k o más tras aplicar los filtros.

El beneficio del postfiltrado es que no cambia el comportamiento en tiempo de ejecución de la búsqueda vectorial: la búsqueda vectorial no es consciente del filtrado. Pero sí cambia el número final de resultados obtenidos.

A continuación se muestra un ejemplo de postfiltrado usando la consulta knn. Comprueba que la cláusula de filtrado esté separada de la consulta knn:

El filtrado de postfiltrado también está disponible para la búsqueda de knn usando el filtro de postfiltro:

Ten en cuenta que necesitas usar una sección explícita de filtro posterior con la búsqueda de knn. Si no usas un filtro de post, la búsqueda de knn combinará los resultados de vecinos más cercanos con otras consultas o filtros en lugar de hacer un filtro de post.

Prefiltrado

Aplicar filtros antes de la búsqueda vectorial primero recuperará los documentos que cumplan con los filtros y luego transmitirá esa información a la búsqueda vectorial.

Lucene emplea BitSets para almacenar eficientemente los documentos que cumplen la condición de filtro. La búsqueda vectorial recorre entonces el grafo HNSW, teniendo en cuenta los documentos que cumplen la condición. Antes de agregar un candidato a los resultados, comprueba que esté contenido en el BitSet de documentos válidos.

Sin embargo, el candidato debe ser explorado y comparado con la consulta, aunque no sea un documento válido. La efectividad de HNSW depende de la conexión entre los vectores del grafo: si dejáramos de explorar un candidato, significaría que podríamos estar saltándonos también sus vecinos.

Piénsalo como manejar para llegar a una gasolinera. Si descartas cualquier carretera que no tenga gasolinera, es poco probable que llegues a tu destino. Puede que otras carreteras no sean lo que necesitas, pero te conectan con tu destino. ¡Lo mismo ocurre con los vectores en un grafo HNSW!

Por tanto, aplicar prefiltrado es menos eficiente que no aplicar filtros. Tenemos que trabajar en todos los vectores que visitamos en nuestra búsqueda, y desechar aquellos que no coinciden con el filtro. Estamos trabajando más y tardando más en conseguir los mejores resultados de la k.

A continuación se muestra un ejemplo de pretfiltering en la DSL de Elasticsearch Consult. Comprueba que la cláusula de filtrado ahora forma parte de la sección knn:

El prefiltrado está disponible tanto para la búsqueda como para la consulta knn:

Optimizaciones de prefiltrado

Hay un par de optimizaciones que podemos aplicar para cerciorar que el prefiltrado sea eficiente.

Podemos cambiar a búsqueda exacta si el filtro es muy restrictivo. Cuando hay pocos vectores para comparar, es más rápido realizar una búsqueda exacta en los pocos documentos que cumplen con el filtro.

Esta es una optimización que se aplica automáticamente en Lucene y Elasticsearch.

Otro método de optimización implica ignorar los vectores que no satisfacen el filtro. En su lugar, este método comprueba los vecinos de los vectores filtrados que sí pasan el filtro. Este enfoque reduce efectivamente el número de comparaciones ya que no se consideran los vectores filtrados, y continúa explorando vectores conectados al camino actual.

Este algoritmo es ACORN-1, y el proceso se describe en detalle en esta entrada del blog.

Filtrado usando la seguridad a nivel de documento

La Seguridad a Nivel de Documento (DLS) es una función de Elasticsearch que especifica los documentos que los roles de usuario pueden recuperar.

DLS se realiza mediante consultas. Un rol puede tener una consulta asociada a índices, lo que limita efectivamente los documentos que un usuario que pertenece a ese rol puede recuperar de los índices.

La consulta de rol se emplea como filtro para recuperar los documentos que coinciden con ella, y se almacenan en caché como un BitSet. Este BitSet se emplea entonces para envolver el lector Lucene subyacente, de modo que solo los documentos que se devolvieron de la consulta se consideran activos,es decir, existen en el índice y no fueron eliminados.

A medida que los documentos en tiempo real se recuperan del lector para realizar la consulta knn, solo se considerarán los documentos disponibles para el usuario. Si hay un prefiltro, se agregarán los documentos DLS a él.

Esto significa que el filtrado DLS funciona como prefiltro para la búsqueda vectorial aproximada, con las mismas participaciones de rendimiento y optimizaciones.

DLS con búsqueda exacta tendrá los mismos beneficios que aplicar cualquier filtro: cuantos menos documentos se recuperen de DLS, más eficiente será una búsqueda exacta. Considera también el número de documentos devueltos por DLS; si los roles DLS son muy restrictivos, puedes considerar usar búsqueda exacta en lugar de búsqueda aproximada.

Evaluación comparativa

En Elasticsearch, queremos cerciorarnos de que el filtrado de búsqueda vectorial sea eficiente. Disponemos de un benchmark específico para el filtrado vectorial que realiza búsquedas vectoriales aproximadas con diferentes filtros para cerciorar que la búsqueda vectorial siga recuperando resultados relevantes lo más rápido posible.

Consulta las mejoras cuando se introdujo ACORN-1. Para pruebas en las que solo el 2% de los vectores pasan el filtro, la latencia de consulta se reduce al 55% de la duración original:

Conclusión

El filtrado es una parte integral de la búsqueda. Cerciorar que el filtrado sea eficiente en la búsqueda vectorial y comprender los compromisos y optimizaciones es lo que hace que una búsqueda sea eficiente y precisa o fracase.

El filtrado afecta al rendimiento de la búsqueda vectorial:

• La búsqueda exacta es más rápida cuando se usa filtrado. Deberías considerar usar la búsqueda exacta en lugar de la aproximada si tu filtrado es lo suficientemente restrictivo. Esta es una optimización automática en Elasticsearch.

• La búsqueda aproximada es más lenta cuando se emplea prefiltrado. El prefiltrado nos permite obtener los k primeros resultados que coinciden con el filtro, a costa de una búsqueda más lenta.

• El postfiltrado no necesariamente recupera los k primeros resultados, ya que pueden filtrar mediante el filtro cuando se aplica.

¡Feliz filtrado!

Podrías preguntarte, ¿por qué usar varios gráficos? Este es un efecto secundario de una elección arquitectónica en Lucene: segmentos inmutables. Como ocurre con la mayoría de las opciones arquitectónicas, hay pros y contras. Por ejemplo, recientemente lanzamos Elasticsearch sin servidor con GA. En este contexto, obtuvimos beneficios muy significativos de los segmentos inmutables, incluida la replicación eficiente de índices y la capacidad de desacoplar el índice y el proceso de consulta y escalarlos automáticamente de forma independiente. Para la cuantificación vectorial, las fusiones de segmentos nos dan la oportunidad de actualizar los parámetros para adaptarlos a las características de los datos. En este sentido, creemos que hay otros beneficios que ofrece tener oportunidades para medir las características de los datos y revisar las opciones de indexación.

En esta publicación, discutiremos el trabajo que estuvimos haciendo para reducir significativamente la sobrecarga de crear múltiples gráficos HNSW y, en individuo, para reducir el costo de fusionar gráficos.

Fondo

Para mantener un número manejable de segmentos, Lucene verifica periódicamente si debe fusionar segmentos. Esto equivale a comprobar si el recuento de segmentos actual supera un recuento de segmentos de destino, que está determinado por el tamaño del segmento base y la política de combinación. Si se supera el recuento, Lucene combina grupos de segmentos mientras se infringe la restricción. Este proceso se describió en detalle en otra parte.

Lucene elige fusionar segmentos de tamaño similar porque esto logra un crecimiento logarítmico en la amplificación de escritura. En el caso de un índice vectorial, la amplificación de escritura es el número de veces que se insertará un vector en un gráfico. Lucene intentará fusionar segmentos en grupos de aproximadamente 10. En consecuencia, los vectores se insertan en un gráfico aproximadamente veces, donde es el recuento de vectores índice y es el recuento de vectores de segmento base esperado. Debido al crecimiento logarítmico, la amplificación de escritura es de un solo dígito incluso para índices enormes. Sin embargo, el tiempo total dedicado a fusionar gráficos es linealmente proporcional a la amplificación de escritura.

Al fusionar gráficos HNSW ya hacemos una pequeña optimización: retener el gráfico para el segmento más grande e insertar vectores de los otros segmentos en él. Esta es la razón del factor 9/10 anterior. A continuación, mostramos cómo podemos hacerlo significativamente mejor empleando información de todos los gráficos que estamos fusionando.

Fusión de grafos HNSW

Antes conservábamos el grafo más grande e insertábamos vectores de los otros ignorando los gráficos que los contenían. La idea clave que aprovechamos a continuación es que cada grafo HNSW que descartamos contiene información importante de proximidad sobre los vectores que contiene. Nos gustaría usar esta información para acelerar la inserción, al menos algunos, de los vectores.

Nos enfocamos en el problema de insertar un gráfico más pequeño en un gráfico más grande , ya que esta es una operación atómica que podemos usar para construir cualquier política de combinación.

La estrategia consiste en encontrar un subconjunto de vértices de insertarlos en el gráfico grande. Luego usamos la conectividad de estos vértices en el gráfico pequeño para acelerar la inserción de los vértices restantes . A continuación, usamos y para denotar los vecinos de un vértice en el grafo pequeño y grande, respectivamente. Esquemáticamente, el proceso es el siguiente.

MERGE-HNSW

Inputs and

1Find to insert into using COMPUTE-JOIN-SET 2Insert each vertex into 3for do 4 5 6FAST-SEARCH-LAYER 7SELECT-NEIGHBORS-HEURISTIC 8

Calculamos el conjunto empleando un procedimiento que discutimos a continuación (línea 1). Luego insertamos cada vértice en en el gráfico grande usando el procedimiento de inserción HNSW estándar (línea 2). Para cada vértice que no insertamos encontramos sus vecinos que insertamos y sus vecinos en el gráfico grande (líneas 4 y 5). Usamos un procedimiento FAST-SEARCH-LAYER sembrado con este conjunto (línea 6) para encontrar los candidatos para el SELECT-NEIGHBORS-HEURISTIC del artículo HNSW (línea 7). En efecto, estamos reemplazando SEARCH-LAYER para encontrar el conjunto candidato en el método INSERT (Algoritmo 1 del artículo), que de lo contrario no cambia. Finalmente, agregamos el vértice que acabamos de insertar en (línea 8).

Está claro que para que esto funcione, cada vértice en debe tener al menos un vecino en . De hecho, requerimos que para cada vértice en que para algunos , la máxima conectividad de capa. Observamos que en los gráficos reales de HNSW vemos una gran dispersión de grados de vértice. La siguiente figura muestra una función de densidad acumulativa típica del grado de vértice para la capa inferior de un gráfico HNSW de Lucene.

Exploramos el uso de un valor fijo para así como convertirlo en una función del grado del vértice. Esta segunda opción conduce a mayores aceleramientos con un impacto mínimo en la calidad del gráfico, por lo que optó por lo siguiente

Tenga en cuenta que | es igual al grado del vértice en el gráfico pequeño por definición. Tener un límite inferior de dos significa que insertaremos cada vértice cuyo grado sea menor que dos.

Un argumento de conteo simple sugiere que si elegimos con cuidado, solo necesitamos insertar alrededor en directamente. Específicamente, coloreamos una arista del grafo si insertamos exactamente uno de sus vértices finales en . Entonces sabemos que para que cada vértice en tenga al menos vecinos en , necesitamos colorear al menos aristas. Además, esperamos que

Aquí, es el grado medio del vértice en la gráfica pequeña. Para cada vértice coloreamos como máximo Bordes. Por lo tanto, el número total de bordes que esperamos colorear es como máximo . Esperamos que al elegir con cuidado coloreemos cerca de este número de aristas y así cubrir todos los vértices necesidades para satisfacer

Esto implica que .

Siempre que SEARCH-LAYER domine el tiempo de ejecución, esto sugiere que podríamos lograr un aceleramiento de hasta en el tiempo de fusión. Dado el crecimiento logarítmico de la amplificación de escritura, esto significa que incluso para índices muy grandes, normalmente solo duplicaríamos el tiempo de construcción en comparación con la construcción de un gráfico.

El riesgo en esta estrategia es que dañamos la calidad del gráfico. Inicialmente lo intentamos con un FAST-SEARCH-LAYERsin operación. Descubrimos que esto degrada la calidad del gráfico en la medida en que la recuperación en función de la latencia se vio afectada, particularmente cuando se fusiona en un solo segmento. Luego exploramos varias alternativas empleando una búsqueda limitada del gráfico. Al final, la elección más efectiva fue la más simple. Usar SEARCH-LAYER pero con un ef_constructionbajo. Con esta parametrización pudimos lograr gráficos de excelente calidad y aún así disminuir el tiempo de fusión en un poco más del 30% en promedio.

Cálculo del conjunto de unión

Encontrar un buen conjunto de unión puede formular como un problema de cobertura de grafos HNSW. Una heurística codiciosa es una heurística simple y efectiva para aproximar cubiertas óptimas de grafos. El enfoque que tomamos elige vértices uno a uno para sumar a en orden decreciente de ganancia. La ganancia se define de la siguiente manera:

Aquí, denota el recuento de vecinos de un vector en y es la función indicadora. La ganancia incluye el cambio en el recuento del vértice que agregamos a , es decir, ya que nos acercamos a nuestro objetivo al agregar un vértice menos cubierto. El cálculo de la ganancia se ilustra en la siguiente figura para el vértice naranja central.

Mantenemos el siguiente estado para cada vértice :

1. Ya sea rancio,

2. Su ganancia

3. El recuento de vértices adyacentes en denotado

4. Un número aleatorio en el rango [0,1] que se usa para el desempate.

El pseudocódigo para calcular el conjunto de combinaciones es el siguiente.

COMPUTE-JOIN-SET

Inputs

1 2 3for do 4 5 6 7while do 8 maximum gain vertex in 9Remove the state for from 10if is not stale then 11 12 13for do 14mark as stale if 15mark neighbors of stale if 16 17else 18 19if then 20 21return

Primero inicializamos el estado en las líneas 1-5.

En cada iteración del bucle principal extraemos inicialmente el vértice de ganancia máxima (línea 8), rompiendo los empates al azar. Antes de realizar cualquier cambio, debemos verificar si la ganancia del vértice está obsoleta. En individuo, cada vez que agregamos un vértice a afectamos la ganancia de otros vértices:

1. Dado que todos sus vecinos tienen un vecino adicional en , sus ganancias pueden cambiar (línea 14)

2. Si alguno de sus vecinos ahora está completamente cubierto, todas las ganancias de sus vecinos pueden cambiar (líneas 14-16)

Recalculamos las ganancias de manera perezosa, por lo que solo recalculamos la ganancia de un vértice si queremos insertarlo en (líneas 18-20). Dado que las ganancias solo disminuyen, nunca podemos perder un vértice que debamos insertar.

Tenga en cuenta que simplemente necesitamos realizar un seguimiento de la ganancia total de vértices que agregamos a para determinar cuándo salir. Además, al menos un vértice tendrá una ganancia distinta de cero, por lo que siempre progresamos.

Resultados

Realizamos experimentos en cuatro conjuntos de datos que juntos cubren nuestras tres métricas de distancia admitidas (euclidiana, coseno y producto interno):

1. quora-E5-small: 522931 documentos, 384 dimensiones y emplea la similitud del coseno,

2. cohe-wikipedia-v2: 1M de documentos, 768 dimensiones y emplea similitud de coseno,

3. gist: 1M documentos, 960 dimensiones y emplea la distancia euclidiana, y

4. cohe-wikipedia-v3: 1M de documentos, 1024 dimensiones y emplea el máximo producto interno.

Para cada conjunto de datos evaluamos dos niveles de cuantificación:

1. int8: que emplea un entero de 1 byte por dimensión y

2. BBQ: que emplea un solo bit por dimensión.

Finalmente, para cada experimento evaluamos la calidad de la búsqueda a dos profundidades de recuperación y examinamos luego de construir el índice y luego luego de forzar la fusión en un solo segmento.

En resumen, logramos aceleramientos sustanciales consistentes en la indexación y la fusión mientras mantenemos la calidad del gráfico y, por lo tanto, el rendimiento de búsqueda en todos los casos.

Experimento 1: cuantización int8

Los aceleramientos promedio desde la línea de base hasta el candidato, los cambios propuestos, son:

Aceleramiento del tiempo del índice: 1.28

Forzar la velocidad de combinación: 1.72

Esto corresponde al siguiente desglose en tiempos de ejecución

Para completar, los tiempos exactos son

Índice

Fusionar

Conjunto de datos

referencia

candidato

Desarrolla

candidato

quora-E5-pequeño

112.41s

81.55s

113.81s

70.87s

wiki-cohesión-v2

158.1s

122,95 segundos

425.20s

239.28s

quid

141.82s

119.26s

536.07s

279.05s

wiki-cohesión-v3

211.86s

168.22s

654,97 segundos

414.12s

A continuación, mostramos los gráficos de recuperación frente a latencia que comparan el candidato (líneas discontinuas) con la línea de base en dos profundidades de recuperación: recall@10 y recall@100 para índices con múltiples segmentos (el resultado final de nuestra estrategia de fusión predeterminada luego de indexar todos los vectores) y luego de forzar la fusión en un solo segmento. Una curva más alta y más a la izquierda es mejor, lo que significa una mayor recuperación con una latencia más baja.

Como puede ver, para índices de múltiples segmentos, el candidato es mejor para el conjunto de datos Cohere v3 y un poco peor, pero casi comparable, para todos los demás conjuntos de datos. Luego de fusionar en un solo segmento, las curvas de recuperación son casi idénticas para todos los casos.

Experimento 2: Cuantización de asado

Los aceleramientos promedio desde la línea de base hasta el candidato son:

Aceleramiento del tiempo de índice: 1.33

Forzar la velocidad de combinación: 1.34

Esto corresponde al siguiente desglose en tiempos de ejecución

Para completar, los tiempos exactos son

Índice

Fusionar

Conjunto de datos

referencia

candidato

Desarrolla

candidato

quora-E5-pequeño

70.71s

58.25s

59.38s

40.15s

wiki-cohesión-v2

203.08s

142.27s

107.27s

85.68s

quid

110.35s

105,52 segundos

323,66 segundos

202.2s

wiki-cohesión-v3

313.43s

190.63s

165,98 segundos

159,95 segundos

Para índices de segmentos múltiples, el candidato es mejor para casi todos los conjuntos de datos, excepto cohere v2, donde la línea de base es ligeramente mejor. Para los índices de un solo segmento, las curvas de recuperación son casi idénticas para todos los casos.

Conclusión

El algoritmo discutido en este blog estará disponible en el próximo Lucene 10.2 y en la versión de Elasticsearch que se basa en él. Los usuarios podrán aprovechar el rendimiento mejorado de la combinación y el tiempo de compilación de índices reducido en estas nuevas versiones. Este cambio es parte de nuestro esfuerzo continuo para hacer que Lucene y Elasticsearch sean rápidos y eficientes para la búsqueda vectorial e híbrida.

Depurar bugs de concurrencia no es nada fácil, pero vamos a entrar en ello. Entra en escena Fray, un marco determinista de pruebas de concurrencia del laboratorio PASTA de CMU, que convierte fallos irregulares en fallos fiables y reproducibles. Gracias al ingenioso diseño de shadow lock de Fray y su control preciso del hilo, localizamos un bug complicado de Lucene y finalmente lo superamos. Esta entrada explora cómo los héroes y herramientas del código abierto están haciendo que la depuración concurrente sea menos dolorosa—y que el mundo del software sea mucho mejor.

Errores de concurrencia: la maldición de los ingenieros de software

Los errores de concurrencia son los peores. No solo son difíciles de arreglar, sino que simplemente conseguir que fallen de forma fiable es la parte más complicada. Tomemos este fallo de prueba, TestIDVersionPostingsFormat#testGlobalVersions, como ejemplo. Genera múltiples hilos de redacción y actualización de documentos, desafiando el modelo optimista de concurrencia de Lucene. Esta prueba expuso una condición de carrera en el control optimista de concurrencia. Es decir, una operación de documento puede afirmar erróneamente ser la última de una secuencia de operaciones 😱. Es decir, en ciertas condiciones, una operación de actualización o eliminación podría tener éxito cuando debería fallar dadas las limitaciones optimistas de concurrencia.

Disculpas a quienes odian los rastreos de Java Stack. Ten en cuenta que eliminar no significa necesariamente "eliminar". También puede indicar una "actualización" de documento, ya que los segmentos de Lucene son de solo lectura.

Apache Lucene gestiona cada hilo que consiste en escribir documentos a través de la clase DocumentsWriter . Esta clase creará o reutilizará hilos para la redacción de documentos y cada acción de escritura controla su información dentro de la clase DocumentsWriterPerThread (DWPT). Además, el autor lleva un registro de qué documentos se eliminan en el DocumentsWriterDeleteQueue (DWDQ). Estas estructuras mantienen todas las acciones de mutación de los documentos en memoria y periódicamente se vacian, liberando recursos en memoria y estructuras persistentes en disco.

Para evitar bloquear hilos y cerciorar un alto rendimiento en sistemas concurrentes, Apache Lucene intenta sincronizar solo en secciones muy críticas. Aunque esto puede ser bueno en la práctica, como en cualquier sistema concurrente, hay dragones.

Una falsa esperanza

Mi investigación inicial me llevó a un par de secciones críticas que no estaban sincronizadas adecuadamente. Todas las interacciones con un DocumentsWriterDeleteQueue dado están controladas por su DocumentsWriterque encierra . Así que, aunque los métodos individuales pueden no estar adecuadamente sincronizados en el DocumentsWriterDeleteQueue, su acceso al mundo lo es (o debería estar). (No profundicemos en cómo esto confunde la propiedad y el acceso: es un proyecto de larga duración escrito por muchos colaboradores. Ten un poco de margen.)

Sin embargo, encontré un sitio durante un flush que no estaba sincronizado.

Estas acciones no están sincronizadas en una sola operación atómica. Es decir, entre newQueue de creación y llamada a getMaxSeqNo, otro código podría haber ejecutado incrementando el número de secuencia en la clase documentsWriter . ¡Encontré el bicho!

Pero, como ocurre con la mayoría de los bugs complejos, encontrar la causa raíz no fue sencillo. Fue entonces cuando intervino un héroe.

Un héroe en la refriega

Entran en escena nuestro héroe: Ao Li y sus colegas del Laboratorio PATA. Le dejaré explicar cómo salvaron el día con Fray.

Fray es un marco determinista de pruebas de concurrencia desarrollado por investigadores del PASTA Lab, Universidad Carnegie Mellon. La motivación detrás de la construcción de Fray proviene de una brecha notable entre la academia y la industria: aunque las pruebas de concurrencia deterministas se estudiaron extensamente en la investigación académica durante más de 20 años, los profesionales siguen confiando en las pruebas de estrés —un método ampliamente reconocido como poco fiable e inestable— para poner a prueba sus programas concurrentes. Por ello, queríamos diseñar e implementar un marco determinista de pruebas de concurrencia con generalidad y aplicabilidad práctica como objetivo principal.

La idea central

En esencia, Fray aprovecha un principio sencillo pero poderoso: la ejecución secuencial. El modelo de concurrencia de Java proporciona una propiedadclave: si un programa está libre de carreras de datos, todas las ejecuciones aparecerán secuencialmente consistentes. Esto significa que el comportamiento del programa puede representar como una secuencia de sentencias del programa.

Fray funciona correr el programa destino de forma secuencial: en cada paso, pausa todos los hilos excepto uno, permitiendo a Fray controlar con precisión la planeación de hilos. Los hilos se seleccionan aleatoriamente para simular la concurrencia, pero las elecciones se registran para una posterior repetición determinista. Para optimizar la ejecución, Fray solo realiza cambios de contexto cuando un hilo está a punto de ejecutar una instrucción de sincronización, como el bloqueo o acceso atómico/volátil. Una buena característica de la libertad entre datos y razas es que este cambio limitado de contexto es suficiente para explorar todos los comportamientos observables debidos a cualquier entrelazado de hilos (nuestro artículo tiene un esbozo de demostración).

El reto: controlar la planeación de hilos

Aunque la idea central parece sencilla, implementar Fray presentó desafíos significativos. Para controlar la planeación de hilos, Fray debe gestionar la ejecución de cada hilo de aplicación. A primera vista, esto podría parecer sencillo: reemplazar primitivas de concurrencia por implementaciones personalizadas. Sin embargo, el control de concurrencia en la JVM es complejo, implicando una mezcla de instrucciones de bytecode, bibliotecas de alto nivel y métodos nativos.

Esto resultó ser un agujero de conejo:

• Por ejemplo, cada MONITORENTER instrucción debe tener un MONITOREXIT correspondiente en el mismo método. Si Fray reemplaza MONITORENTER por una llamada a método a un stub/mock, también debe reemplazar MONITOREXIT.

• En el código que emplea object.wait/notify, si MONITORENTER se reemplaza, también debe ser reemplazada la object.wait correspondiente. Esta cadena de reemplazo se extiende hasta object.notify y más allá.

• La JVM invoca ciertos métodos relacionados con la concurrencia (por ejemplo, object.notify cuando termina un hilo) dentro del código nativo. Reemplazar estas operaciones requeriría modificar la propia JVM.

• Las funciones de la JVM, como cargadores de clases e hilos de recogida de basura (GC), también emplean primitivas de concurrencia. Modificar estas primitivas puede crear desajustes con esas funciones de la JVM.

• Reemplazar primitivas de concurrencia en el JDK suele provocar fallos de la JVM durante su fase de inicialización.

Estos desafíos dejaron claro que una sustitución integral de los primitivos de concurrencia no era factible.

Nuestra solución: diseño de cerraduras de sombra

Para abordar estos desafíos, Fray emplea un novedoso mecanismo de bloqueo de sombra para orquestar la ejecución de hilos sin reemplazar primitivas de concurrencia. Los bloqueos sombra actúan como intermediarios que guían la ejecución del hilo. Por ejemplo, antes de adquirir un bloqueo, un hilo de aplicación debe interactuar con su correspondiente bloqueo de sombra. El bloqueo sombra determina si el hilo puede adquirir el bloqueo. Si el hilo no puede continuar, el bloqueo sombra lo bloquea y permite que otros hilos se ejecuten, evitando bloqueos y permitiendo una concurrencia controlada. Este diseño permite a Fray controlar el entrelazado de hilos de forma transparente mientras preserva la corrección de la semántica de concurrencia. Cada primitiva de concurrencia está cuidadosamente modelada dentro del marco de bloqueo de sombra para garantizar la solidez y la completitud. Más detalles técnicos pueden encontrar en nuestro artículo.

Además, este diseño pretende ser a prueba de futuro. Al requerir únicamente la instrumentación de bloqueos de sombra alrededor de primitivas de concurrencia, se garantiza compatibilidad con versiones más recientes de JVM. Esto es factible porque las interfaces de las primitivas de concurrencia en la JVM son relativamente estables y permanecieron sin cambios durante años.

Probando la batalla

Luego de construir Fray, el siguiente paso fue la evaluación. Afortunadamente, muchas aplicaciones, como Apache Lucene, ya incluyen pruebas de concurrencia. Estas pruebas de concurrencia son pruebas JUnit regulares que generan múltiples hilos, realizan algo de trabajo, luego (normalmente) esperan a que terminen esos hilos y luego afirman alguna propiedad. La mayoría de las veces, estas pruebas se aprueban porque solo hacen un entrecalado. Peor aún, algunas pruebas solo fallan ocasionalmente en el entorno CI/CD, como se describió antes, lo que hace que estos fallos sean extremadamente difíciles de depurar. Cuando ejecutamos las mismas pruebas con Fray, descubrimos numerosos errores. Cabe destacar que Fray redescubrió errores previamente reportados que no fueron corregidos debido a la falta de una reproducción fiable, incluyendo el enfoque de este blog: TestIDVersionPostingsFormat.testGlobalVersions. Por suerte, con Fray, podemos reproducirlos de forma determinista y proporcionar a los desarrolladores información detallada, permitiéndoles reproducir y solucionar el problema de forma fiable.

Próximos pasos para Fray

Nos entusiasma escuchar de los desarrolladores de Elastic que Fray fue útil para depurar errores de concurrencia. Seguiremos trabajando en Fray para que esté disponible para más desarrolladores.

Nuestros objetivos a corto plazo incluyen mejorar la capacidad de Fray para reproducir determinísticamente el calendario, incluso en presencia de otras operaciones no deterministas como un generador de valores aleatorios o el uso de object.hashcode. También pretendemos mejorar la usabilidad de Fray, permitiendo a los desarrolladores analizar y depurar pruebas de concurrencia existentes sin intervención manual. Lo más importante es que, si tienes dificultades para depurar o probar problemas de concurrencia en tu programa, nos encantaría saber de ti. Por favor, no dudes en crear un problema en el repositorio Fray Github.

Hora de arreglar el bug de la concurrencia

¡Gracias a Ao Li y al laboratorio de PATA, ahora tenemos un caso fiable que suspende esta prueba! Por fin podemos arreglar esto. El problema clave residía en cómo DocumentsWriterPerThreadPool permitía la reutilización de hilos y recursos.

Aquí podemos ver cada hilo creado, haciendo referencia a la cola inicial de eliminación en la generación 0.

Después, el avance de cola ocurrirá al encajar la cola y se verán correctamente las 7 acciones anteriores en la cola.

Pero, antes de que todos los hilos terminen de enjuagar, dos se reutilizan para un documento adicional:

Estos incrementarán el seqNo por encima del máximo asumido, que se calculó durante el flush como 7. Notar el numDocsInRAM adicional para los segmentos _3 y _0

Lo que provoca que Lucene tenga en cuenta incorrectamente la secuencia de acciones del documento durante un vaciado y activa este fallo de prueba.

Como todas las buenas correcciones de errores, la corrección real tiene unas 10 líneas de código. Pero dos ingenieros tardaron varios días en entenderlo realmente:

No todos los héroes llevan capa

Sí, es un cliché, pero es verdad.

La depuración concurrente de programas es increíblemente importante. Estos complicados errores de concurrencia requieren una cantidad desproporcionada de tiempo para depurar y resolver. Aunque nuevos lenguajes como Rust tienen mecanismos incorporados para ayudar a prevenir condiciones raciales como esta, la mayoría del software del mundo ya está escrito, y escrito en algo distinto a Rust. Java, incluso luego de todos estos años, sigue siendo uno de los lenguajes más empleados. Mejorar la depuración en lenguajes basados en JVM mejora el mundo de la ingeniería de software. Y dado que algunos piensan que el código será escrito por grandes modelos de lenguaje, quizá nuestro trabajo como ingenieros acabe siendo simplemente depurar código malo de LLM en lugar de solo nuestro propio código malo. Pero, sea cual sea el futuro de la ingeniería de software, la depuración concurrente de programas seguirá siendo fundamental para el mantenimiento y desarrollo de software.

Gracias a Ao Li y a sus colegas del PASTA Lab por hacerlo aún mejor.

Lucene y la comunidad

Un proyecto solo es tan fuerte como la comunidad que lo apoya. A pesar de más de 20 años de desarrollo, el proyecto Lucene sigue siendo vibrante y prospera gracias a sus colaboradores apasionados y activos.

En 2024, el proyecto Lucene recibió más de 2.000 commits de 98 colaboradores únicos y casi 800 pull requests. El número de colaboradores sigue creciendo, con nuevos comprometedores y afiliados a PMC que se unen al proyecto y contribuyen a su éxito.

Lucene 10

En 2024 se produjo el primer gran lanzamiento en casi 3 años: Lucene 10, con más de 2.000 commits de 185 colaboradores únicos. Aunque el modelo de desarrollo que sigue Lucene permite ofrecer muchas mejoras y características en lanzamientos menores, un lanzamiento importante ofrece la oportunidad de aportar funciones y modernizaciones más grandes. Por ejemplo, Lucene 10 requiere un mínimo de Java 21. Aumentar la versión mínima de Java garantiza que Lucene pueda seguir aprovechando las mejoras que ofrece Java moderno.

El objetivo principal de Lucene 10 es aprovechar mejor el hardware sobre el que se ejecuta. Echemos un vistazo rápido a algunos de los principales puntos destacados:

• Más paralelismo en la búsqueda : aunque la ejecución de búsqueda ya está paralelizada entre segmentos, ahora vamos más allá, paralelizando dentro de los segmentos. Esto desacopla la representación en disco del rendimiento de ejecución, permitiendo que incluso segmentos individuales se beneficien del número de núcleos en sistemas modernos.

• Mejor paralelismo de E/S : el modelo sincrónico de E/S sencillo que emplea Lucene fue mejorado con una etapa de prelectura. Esto informa al sistema operativo de que se necesitará una región de un archivo índice en un futuro muy próximo, sin bloquear el hilo que llama.

• Mejor eficiencia de CPU y almacenamiento con indexación dispersa - Lucene 10 introduce soporte para indexación dispersa, a veces llamada indexación de clave primaria o indexación por zonas en otros almacenes de datos.

Para más información sobre Lucene 10, consulta el artículo dedicado a Lucene 10.

Investigación e innovación de Lucene

En 2024, Lucene experimentó un auge de investigación e innovación, especialmente en las áreas de integración de aprendizaje automático, búsqueda vectorial y optimización para conjuntos de datos a gran escala, con 10 artículos y publicaciones de investigación de referencia separados. Algunas de las áreas y desarrollos clave de investigación incluyen:

• Soporte para búsqueda vectorial e incrustación - Lucene ofrece una solución poderosa y escalable para la búsqueda basada en vectores, permitiendo la recuperación semántica a gran escala. Aprovechando la robusta infraestructura de indexación y búsqueda de Lucene, los usuarios pueden combinar lo mejor de la búsqueda tradicional de texto con las avanzadas capacidades de la búsqueda vectorial moderna, convirtiendo Lucene en una solución integral para una amplia gama de tareas de búsqueda y recuperación de información.

• Modelos de búsqueda híbrida - La investigación también profundizó en técnicas de búsqueda híbrida, donde Lucene combina la búsqueda tradicional basada en palabras clave con la recuperación moderna basada en vectores. Al combinar índices basados en términos con representaciones vectoriales densas, Lucene puede ofrecer resultados de búsqueda más precisos y contextualmente relevantes, cerrando la brecha entre la precisión de los motores de búsqueda tradicionales y la flexibilidad de la búsqueda semántica.

Los esfuerzos de investigación en curso en 2024 demuestran la adaptabilidad de Lucene a las necesidades cambiantes de las tecnologías de búsqueda modernas, especialmente en el contexto de la IA, la búsqueda semántica y las aplicaciones de big data. El proyecto sigue creciendo como una plataforma poderosa, flexible y eficiente tanto para casos de búsqueda tradicionales como de vanguardia.

Lanzamientos de Lucene en 2024

Aunque no es un reflejo exacto, el gran volumen de lanzamientos pone de manifiesto la dedicación y energía continua de la comunidad. Estas actualizaciones incluyen mejoras importantes en el rendimiento y eficiencia de la búsqueda vectorial, soporte para madvise, optimizaciones para la decodificación de listas de anuncios, mejoras de velocidad adicionales mediante SIMD y mucho más.

Aquí tienes la lista completa de lanzamientos:

• 10.1.0 (2024-12-20)

• 9.12.1 (2024-12-13)

• 10.0.0 (2024-10-14)

• 9.12.0 (28-09-2024)

• 8.11.4 (2024-09-24)

• 9.11.1 (27-06-2024)

• 9.11.0 (2024-06-06)

• 9.10.0 (2024-02-20)

• 8.11.3 (2024-02-08)

• 9.9.2 (29-01-2024)

Puedes encontrar más información y notas de lanzamiento en la página de Lucene Core . Además, existen ediciones equivalentes de PyLucene .

Concluyendo

A medida que Lucene madura, sigue prosperando gracias a su comunidad dedicada y vibrante. Como vimos, 2024 fue un año increíblemente productivo, y ahora miramos hacia adelante los emocionantes desarrollos que traerá 2025.

Este blog en individuo es diferente de lo habitual. No es una explicación de una nueva función ni un tutorial. Esto trata sobre una sola línea de código que tardó tres días en escribir. Estaremos corrigiendo una posible corrupción en el índice Apache Lucene. Algunas conclusiones que espero que tengáis:

• Todas las pruebas poco estables son repetibles, si se tiene tiempo suficiente y las herramientas adecuadas

• Muchas capas de pruebas son clave para sistemas robustos. Sin embargo, niveles más altos de pruebas se vuelven cada vez más difíciles de depurar y reproducir.

• Sleep es un excelente depurador

Cómo prueba Elasticsearch

En Elastic, tenemos una gran cantidad de pruebas que se ejecutan contra la base de código de Elasticsearch. Algunas son pruebas funcionales simples y enfocadas, otras son pruebas de integración de "happy path" de un solo nodo, y otras intentan romper el clúster para cerciorar de que todo funcione correctamente en un caso de fallo. Cuando una prueba falla continuamente, un ingeniero o automatización de herramientas crea un problema en github y lo señala para que un equipo en individuo lo investigue. Este error en individuo fue descubierto mediante una prueba del último tipo. Estas pruebas son complicadas, a veces solo repetibles tras muchas pruebas.

¿Qué es realmente esta prueba?

Esta prueba en individua es interesante. Creará un mapeo particular y lo aplicará a un fragmento primario. Luego, al intentar crear una réplica. La diferencia clave es que cuando la réplica intenta analizar el documento, la prueba inyecta una excepción, lo que provoca que la recuperación falle de una manera sorprendente (pero esperada).

Sin embargo, todo funcionaba como se esperaba, con un inconveniente importante. Durante la limpieza de la prueba, validamos la consistencia, y ahí esta prueba se topó con un problema.

Esta prueba estaba fallando de la manera esperada. Durante la comprobación de consistencia verificábamos que todos los archivos replicados y los principales de segmentos de Lucene fueran consistentes. Es decir, no corrompido y completamente replicado. Tener datos parciales o corruptos es mucho peor que que algo falle por completo. Aquí está la pista aterradora y abreviada de la pila del fallo.

De alguna manera, durante el fallo de replicación forzada, ¡el fragmento replicado acabó corrompido! Permítanme explicar la parte clave del error en un lenguaje sencillo.

Lucene es una arquitectura basada en segmentos, lo que significa que cada segmento conoce y gestiona sus propios archivos de solo lectura. Este segmento en individuo estaba siendo validado a través de sus SegmentCoreReaders para cerciorar que todo estuviera en orden. Cada lector central almacena metadatos que indican qué tipos de campos y archivos existen para un segmento determinado. Sin embargo, al validar el Lucene90PointsFormat, faltaban ciertos archivos esperados. Con los segmentos _0.cfs archivo esperábamos un archivo de formato puntual llamado kdi. cfs significa "sistema de archivos compuesto" en el que Lucene a veces combina todos los tipos de campos y todos los archivos diminutos en un único archivo más grande para una replicación y uso de recursos más eficiente. De hecho, faltaban las tres extensiones de archivo de puntos: kdd, kdiy kdm . ¿Cómo podríamos llegar al punto en que un segmento de Lucene espera encontrar un archivo puntual pero falta?! ¡Parece un error de corrupción aterrador!

El primer paso para cada corrección de error es replicarlo

Replicar el fallo de este error en individuo fue extremadamente doloroso. Aunque aprovechamos las pruebas de valor aleatorizadas en Elasticsearch, nos cercioramos de proporcionar a cada fallo una semilla aleatoria (esperemos) reproducible para que todos puedan ser investigados. Bueno, esto funciona muy bien para todos los fallos excepto los causados por una condición de carrera.

Por mucho que lo intentara, la semilla en individua nunca repetía el fallo localmente. Pero hay formas de poner a prueba las pruebas y avanzar hacia un fracaso más repetible.

Nuestro conjunto de pruebas en individua permite que una prueba se ejecute más de una vez en el mismo comando mediante el parámetro -Dtests.iters . Pero esto no era suficiente, necesitaba cerciorarme de que los hilos de ejecución estuvieran cambiando y así aumentaran la probabilidad de que ocurriera esta condición de carrera. Otro problema era que la prueba tardaba tanto en ejecutar que el corredor de pruebas se apagaba. Al final, usé el siguiente pesadilla para ejecutar la prueba de forma repetida:

Entra el estrés. Esto te permite iniciar rápidamente un proceso que solo consumirá núcleos de CPU durante la comida. Spamear stress-ng aleatoriamente mientras ejecutaba varias iteraciones de la prueba fallida finalmente me permitió replicar el fallo. Un paso más. Para estresar el sistema, simplemente abre otra ventana de terminal y ejecuta:

Revelando el error

Ahora que el fallo de la prueba que revela el error es mayormente repetible, es hora de intentar encontrar la causa. Lo que hace extraño este test en individuo es que Lucene lanza porque espera valores de puntos, pero no se agregan directamente por la prueba. Solo valores de texto. Esto me llevó a considerar los cambios recientes en nuestros optimistas campos de control de concurrencia : _seq_no y _primary_term. Ambos están indexados como puntos y existen en todos los documentos de Elasticsearch.

¡De hecho, un commit cambió nuestro _seq_no mapeador! ¡SÍ! ¡Esta tiene que ser la causa! Pero mi entusiasmo duró poco. Esto solo cambió el orden en que se agregaron los campos al documento. Antes de este cambio, _seq_no campos se agregaron al último en el documento. Después, ellos fueron agregados primero. No hay manera de que el orden de agregar campos a un documento Lucene causara este fallo...

Sí, cambiar el orden en que se agregaron los campos causó el fallo. ¡Esto fue sorprendente y resultó ser un error en Lucene mismo! Cambiar el orden de los campos analizados no debería modificar el comportamiento de analizar un documento.

El bicho en Lucene

De hecho, el insecto en Lucene se centró en las siguientes condiciones:

• Indexación de un campo de valor de puntos (por ejemplo, _seq_no)

• Intentando indexar un lanzamiento de campo de texto durante el análisis

• En este estado extraño, abrimos un Lector en Tiempo Casi Real del autor que experimenta la excepción de análisis de índice de texto

Pero por muchas formas que lo intentara, no pude replicarlo completamente. Agregué directamente puntos de pausa para depurar en toda la base de código de Lucene. Intenté abrir lectores al azar durante el camino de excepción. Incluso imprimí megabytes y megabytes de registros intentando encontrar la ruta exacta por donde ocurrió este fallo. Simplemente no pude hacerlo. Pasé todo un día luchando y perdiendo.

Luego me dormí.

Al día siguiente volví a leer el rastro original de la pila y descubrí la siguiente línea:

En todos mis intentos de recreación, nunca establecí específicamente la política de fusión de retención. La Política de Fusión SoftDeletesRetentionMergePolicy la emplea Elasticsearch para que podamos replicar con precisión las eliminaciones en réplicas y cerciorarnos de que todos nuestros controles de concurrencia se encarguen de cuándo se eliminan realmente los documentos. Por lo demás, Lucene tiene el control total y los eliminará en cualquier fusión.

Una vez que agregué esta política y replicé los pasos más básicos mencionados anteriormente, el fallo se replicó inmediatamente.

Nunca estuve más feliz de abrir un micrófono en Lucene.

Aunque se presentaba como una condición de raza en Elasticsearch, era sencillo escribir una prueba repetidamente suspendida en Lucene una vez cumplidas todas las condiciones.

Al final, como todos los buenos errores, se solucionó con solo una línea de código. Varios días de trabajo, solo por una línea de código.

Pero valió la pena.

No es el final

¡Espero que disfrutaste de esta aventura salvaje conmigo! Escribir software, especialmente software tan empleado y complejo como Elasticsearch y Apache Lucene, es gratificante. Sin embargo, a veces resulta excepcionalmente frustrante. Me encanta y odio el software a la vez. ¡La corrección de errores nunca termina!

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.

Aunque HNSW es una forma poderosa y flexible de almacenar y buscar vectores, requiere una cantidad significativa de memoria para funcionar rápidamente. Por ejemplo, consultar vectores float32 de 1 MM de 768 dimensiones requiere aproximadamente de RAM. Una vez que empiezas a buscar un número significativo de vectores, esto se vuelve caro. Una forma de usar alrededor menos de memoria es mediante cuantización por bytes. Lucene y, en consecuencia, Elasticsearch soportaron la indexación de durante algún tiempo, pero la construcción de estos vectores fue responsabilidad del usuario. Esto está a punto de cambiar, ya que introdujimos la cuantización en Lucene.

Cuantización escalar 101

Todas las técnicas de cuantización se consideran transformaciones con pérdida de los datos en bruto. Es decir, se pierde algo de información por el bien del espacio. Para una explicación detallada de la cuantización escalar, ver: Cuantización Escalar 101. A un nivel general, la cuantización escalar es una técnica de compresión con pérdida. Unas matemáticas sencillas ofrecen un ahorro significativo de espacio con muy poco impacto en la memoria.

Explorando la arquitectura

Quienes están acostumbrados a trabajar con Elasticsearch quizá ya estén familiarizados con estos conceptos, pero aquí tienes un resumen rápido de la distribución de los documentos para la búsqueda.

Cada índice de Elasticsearch está compuesto por múltiples fragmentos. Aunque cada fragmento solo puede asignar a un solo nodo, múltiples fragmentos por índice te dan paralelismo de cálculo entre nodos.

Cada fragmento está compuesto como un único Índice Luceno. Un índice Lucene consta de múltiples segmentos de solo lectura. Durante la indexación, los documentos se almacenan en búfer y periódicamente se vacian en un segmento de solo lectura. Cuando se cumplen ciertas condiciones, estos segmentos pueden fusionar en el fondo en un segmento más grande. Todo esto es configurable y tiene su propio conjunto de complejidades. Pero, cuando hablamos de segmentos y fusiones, nos referimos a segmentos Lucene de solo lectura y a la fusión periódica automática de estos segmentos. Aquí tienes una profundización en la fusión de segmentos y las decisiones de diseño.

Cuantización por segmento en Luceno

Cada segmento en Lucene almacena lo siguiente: los vectores individuales, los índices de grafos HNSW, los vectores cuantizados y los cuantiles calculados. Por brevedad, nos centraremos en cómo Lucene almacena vectores cuantizados y en bruto. Para cada segmento, llevamos un seguimiento de los vectores en bruto en el archivo , los vectores cuantizados y un único flotador de multiplicador correctivo en , así como los metadatos alrededor de la cuantización dentro del archivo .

Figura 1: Diseño simplificado de un archivo de almacenamiento vectorial en bruto. Ocupa de espacio en disco ya que los son 4 bytes. Como estamos cuantizando, estos no se cargarán durante la búsqueda HNSW. Solo se emplean si se aplicar específicamente (por ejemplo, secundario de fuerza bruta mediante repuntuación), o para la recuantización durante la fusión de segmentos.

Figura 2: Diseño simplificado del archivo. Ocupa del espacio y se cargará en memoria durante la búsqueda. El bytes es para tener en cuenta el multiplicador correctivo flotante, empleado para ajustar el puntaje y mejorar la precisión y la recuperación.

Figura 3: El diseño simplificado del archivo de metadatos. Aquí es donde hacemos seguimiento de la cuantización y la configuración vectorial junto con los cuantiles calculados para este segmento.

Así que, para cada segmento, almacenamos no solo los vectores cuantizados, sino también los cuantiles usados para fabricar estos vectores cuantizados y los vectores originales en bruto. Pero, ¿por qué mantenemos los vectores en bruto?

Cuantización que crece contigo

Como Lucene vacía periódicamente para leer solo segmentos, cada segmento solo tiene una vista parcial de todos tus datos. Esto significa que los cuantiles calculados solo se aplican directamente a ese conjunto muestral de todos tus datos. Ahora bien, esto no es un gran problema si tu muestra representa adecuadamente todo tu corpus. Pero Lucene te permite ordenar tu índice de varias maneras. Así que podrías indexar datos ordenados de una manera que agregue sesgo para cálculos de cuantil por segmento. ¡Además, puedes vaciar los datos cuando quieras! Tu conjunto de muestras podría ser muy pequeño, incluso solo un vector. Otro inconveniente es que tienes control sobre cuándo ocurren las fusiones. Aunque Elasticsearch tiene configuraciones por defecto y fusiones periódicas, puedes pedir una fusión cuando quieras a través de _force_merge API. Entonces, ¿cómo permitimos toda esta flexibilidad, proporcionando una buena cuantización que proporcione una buena recordación?

La cuantización vectorial de Lucene se ajustará automáticamente con el tiempo. Como Lucene está diseñado con una arquitectura de segmentos de solo lectura, tenemos garantías de que los datos de cada segmento no cambiaron y demarcaciones claras en el código para cuándo se pueden actualizar cosas. Esto significa que durante la fusión de segmentos podemos ajustar los cuantiles según sea necesario y posiblemente volver a cuantizar los vectores.

Figura 4: Tres segmentos de ejemplo con diferentes cuantiles.

¿Pero no es caro la recuantización? Tiene cierta sobrecarga, pero Lucene maneja los cuantiles con inteligencia y solo recuantiza completamente cuando es necesario. Usemos los segmentos de la Figura 4 como ejemplo. Demos a los y documentos cada uno y al solo documentos. Lucene tomará un promedio ponderado de los cuantiles y si ese cuantil combinado resultante está lo suficientemente cerca de los cuantiles originales de los segmentos, no tenemos que volver a cuantificar ese segmento y emplearemos los cuantiles recién fusionados.

Figura 5: Ejemplo de cuantiles fusionados donde los segmentos y tienen documentos y solo .

En la situación visualizada en la figura 5, podemos ver que los cuantiles fusionados resultantes son muy similares a los cuantiles originales en y . Por tanto, no justifican cuantizar los vectores. El segmento parece desviar demasiado. En consecuencia, los vectores en se recuantizarían con los nuevos valores cuantiles fusionados.

De hecho, existen casos extremos en los que los cuantiles fusionados difieren significativamente de cualquiera de los cuantiles originales. En este caso, tomaremos una muestra de cada segmento y recalcularemos completamente los cuantiles.

Rendimiento y números de cuantización

Entonces, ¿es rápido y sigue proporcionando buena recuperación? Los siguientes números se recopilaron ejecutando el experimento en una instancia c3-standard-8 GCP. Para cerciorar una comparación justa con , usamos una instancia lo suficientemente grande como para almacenar vectores en bruto en memoria. Indexamos vectores de Cohere Wiki usando el producto interno máximo.

Figura 6: Recall@10 para vectores cuantizados frente a vectores en bruto. El rendimiento de búsqueda de vectores cuantizados es significativamente más rápido que el en bruto, y la recuperación se recupera rápidamente reuniendo solo 5 vectores más; visible .

La Figura 6 muestra la historia. Aunque hay una diferencia en la retirada, como era de esperar, no es significativa. Y la diferencia de recordación desaparece reuniendo solo 5 vectores más. Todo esto con fusiones de segmentos más rápidas y 1/4 de la memoria de vectores .

Conclusión

Lucene ofrece una solución única a un problema difícil. No se requiere ningún paso de "entrenamiento" ni de "optimización" para la cuantización. En Lucene, simplemente funcionará. No hay que preocupar por tener que "reentrenar" tu índice vectorial si tus datos se desplazan. Lucene detectará cambios significativos y se encargará de esto automáticamente durante la vida útil de tus datos. ¡Espero con ganas que lleguemos a incorporar esta capacidad a Elasticsearch!

Fondo

Mientras desarrollamos Elasticsearch, ocasionalmente nos encontramos con un problema importante sin un enfoque sencillo o establecido para solucionarlo. Es natural preguntar: "hmm, ¿existe algún artículo académico que aborde esto?" Otras veces, el trabajo académico es una fuente de inspiración. Nos encontramos con un artículo que propone un nuevo algoritmo o estructura de datos y pensamos "¡esto sería muy útil!" Aquí tienes solo algunos ejemplos de cómo Elasticsearch y Apache Lucene incorporan el trabajo académico:

• HyperLogLog++ para agregaciones de cardinalidad

• Algoritmo C3 para la selección adaptativa de réplicas

• Grafos jerárquicos navegables de mundos pequeños (HNSW) para búsqueda vectorial más cercana en Lucene

• Estadística MIC para mejorar la clasificación del aprendizaje automático

• WAND de bloqueo máximo para una recuperación más rápida de top-hits en Lucene

• ... y muchos más

Los artículos académicos son un recurso invaluable para los ingenieros que desarrollan sistemas intensivos en datos. Pero implementarlas puede ser intimidante y propenso a errores: las descripciones de algoritmos suelen ser complejas, omitiendo detalles prácticos importantes. Y las pruebas son un verdadero desafío: por ejemplo, ¿cómo podemos probar a fondo un algoritmo de aprendizaje automático cuya salida depende estrechamente del conjunto de datos?

Evalúa el trabajo como si fuera una dependencia de software

Agregar una nueva dependencia de software requiere una evaluación cuidadosa: si el otro paquete es incorrecto, lento o inseguro, nuestro proyecto también podría serlo. Antes de incorporar una dependencia, los desarrolladores se cercioran de evaluar su calidad.

Lo mismo ocurre con los trabajos académicos que estás considerando implementar. Puede parecer que, porque un algoritmo se publicó en un artículo, debe ser correcto y funcionar bien. Pero aunque pasó un proceso de revisión, un artículo académico puede tener problemas. Quizá la demostración de corrección se basa en suposiciones que no son realistas. O quizá la sección de "experimentos" muestra un rendimiento mucho mejor que la línea base, pero esto solo se cumple en un conjunto de datos específico. Aunque el trabajo sea de gran calidad, su enfoque puede no encajar bien con tu proyecto.

Al pensar si tomar una "dependencia" de un artículo académico, es útil plantear las mismas preguntas que haríamos con un paquete de software:

• ¿La biblioteca está ampliamente empleada y "probada en batalla"? → ¿Otros paquetes implementaron este artículo y les funcionó bien?

• ¿Están disponibles los benchmarks de rendimiento? ¿Te parecen precisos y justos? → ¿El artículo incluye experimentos realistas? ¿Están bien diseñadas?

• ¿Es suficiente una mejora de rendimiento como para justificar la complejidad? → ¿El artículo se compara con un enfoque de línea base fuerte? ¿Cuánto supera esta línea base?

• ¿Se integrará bien este enfoque con nuestro sistema? → ¿Encajan las suposiciones y compensaciones del algoritmo en nuestro caso de uso?

De alguna manera, cuando un paquete de software publica una comparación de rendimiento con sus competidores, ¡el paquete siempre sale más rápido! Si un tercero diseñó los benchmarks, podrían estar más equilibrados. El mismo fenómeno se aplica a los artículos académicos. Si un algoritmo funciona bien no solo en el artículo original, sino que también aparece en otros como una línea base estable, entonces es muy probable que sea estable.

Sé creativo con las pruebas

Los algoritmos de artículos académicos suelen tener un comportamiento más sofisticado que los tipos de algoritmos que habitualmente nos encontramos. Quizá sea un algoritmo de aproximación que sacrifica la precisión por una mejor velocidad. O quizá sea un método de aprendizaje automático que absorbe un gran conjunto de datos y produce resultados (a veces inesperados). ¿Cómo podemos escribir pruebas para estos algoritmos si no podemos caracterizar su comportamiento de forma sencilla?

Enfoque en invariantes

Al diseñar pruebas unitarias, es común pensar en términos de ejemplos: si damos al algoritmo esta entrada de ejemplo, debería tener esa salida. Desafortunadamente, para la mayoría de los algoritmos matemáticos, las pruebas basadas en ejemplos no cubren suficientemente su comportamiento.

Consideremos el algoritmo C3, que Elasticsearch emplea para determinar qué nodo debe gestionar una solicitud de búsqueda. Clasifica cada nodo usando una fórmula matizada que incorpora el servicio y los tiempos de respuesta previos del nodo, así como el tamaño de su cola. Probar un par de ejemplos realmente no verifica que entendiéramos bien la fórmula. Ayuda dar un paso atrás y pensar en probar invariantes: si aumenta el tiempo de servicio, ¿disminuye el rango del nodo? Si el tamaño de la cola es 0, ¿el rango se determina por el tiempo de respuesta, como afirma el artículo?

Centrar en los invariantes puede ayudar en varios casos comunes:

• ¿Se supone que el método es agnóstico respecto al orden? Si es así, pasar los datos de entrada en un orden diferente debería dar el mismo resultado.

• ¿Algún paso del algoritmo produce probabilidades de clase? Si es así, estas probabilidades deberían sumar 1.

• ¿Es la función simétrica alrededor del origen? Si es así, invertir el signo de la entrada debería simplemente invertir el signo de la salida.

Cuando implementamos C3 por primera vez, tuvimos un error en la fórmula donde accidentalmente usamos el inverso del tiempo de respuesta en lugar del tiempo de respuesta. ¡Esto significaba que los nodos más lentos podían estar más bien clasificados! Al solucionar el problema, nos cercioramos de agregar comprobaciones invariantes para evitar futuros errores.

Comparar con una implementación de referencia

Junto al artículo, los autores esperan publicar una implementación del algoritmo. (Esto es especialmente probable si el artículo contiene experimentos, ya que muchas revistas requieren que los autores envíen el código para reproducir los resultados.) Puedes probar tu enfoque con esta implementación de referencia para cerciorarte de que no te perdiste detalles importantes del algoritmo.

Mientras desarrollábamos la implementación HNSW de Lucene para la búsqueda de vecinos más cercanos, probamos contra una biblioteca de referencia de los autores del artículo. Ejecutamos tanto Lucene como la biblioteca con el mismo conjunto de datos, comparando la precisión de sus resultados y el número de cálculos que realizaron. Cuando estos números coinciden de cerca, sabemos que Lucene implementa fielmente el algoritmo.

Al incorporar un algoritmo en un sistema, a menudo necesitas hacer modificaciones o extensiones, como escalarlo a múltiples núcleos o agregar heurísticas para mejorar el rendimiento. Lo mejor es implementar primero una versión "vanilla", probarla con la referencia y luego hacer cambios incrementales. Así puedes estar seguro de que capturaste todas las piezas clave antes de hacer personalizaciones.

Duelo contra un algoritmo existente

La última sección plantea otra idea para un invariante de prueba: comparar la salida del algoritmo con la salida de un algoritmo más simple y mejor entendido. Como ejemplo, consideremos el algoritmo WAND de bloques máximas en Lucene, que acelera la recuperación de documentos saltar documentos que no pueden aparecer en los resultados principales. Es difícil describir exactamente cómo debería comportar la WAND con bloque máximo en todos los casos, pero sí sabemos que aplicarla no debería cambiar los mejores resultados. Así que nuestras pruebas pueden generar varias consultas de búsqueda aleatoria, luego ejecutarlas tanto con como sin la optimización WAND y comprobar que sus resultados siempre coinciden.

Un aspecto importante de estas pruebas es que generan entradas aleatorias sobre las que realizar la comparación. Esto puede ayudar a resolver casos que no consideraste y a sacar a la luz problemas inesperados. Por ejemplo, la prueba de comparación aleatoria de Lucene para el puntaje BM25F ayudó a detectar errores en casos extremos sutiles. La idea de alimentar a un algoritmo con entradas aleatorias está estrechamente relacionada con el concepto de fuzzing, una técnica común de pruebas en seguridad informática.

Elasticsearch y Lucene emplean frecuentemente este enfoque de prueba. Si ves una prueba que menciona un "duelo" entre dos algoritmos (TestDuelingAnalyzers, testDuelTermsQuery...), entonces sabes que esta estrategia está en acción.

Emplea la terminología del artículo

Cuando otro desarrollador trabaje con tu código, necesitará consultar el documento para seguir sus detalles. El comentario sobre la implementación de HyperLogLog++ de Elasticsearch lo dice bien: "Intentar entender qué hace esta clase sin leer el artículo se considera aventurero." Este comentario sobre el método también da un buen ejemplo. Incluye un enlace al artículo académico y destaca qué modificaciones se hicieron al algoritmo tal y como fue descrito originalmente.

Como los desarrolladores basan su comprensión del código en el papel, es útil usar exactamente la misma terminología. Dado que la notación matemática es concisa, esto puede dar lugar a nombres que normalmente no se considerarían de "buen estilo", pero que son muy claros en el contexto del artículo. Las fórmulas de artículos académicos son una de las pocas ocasiones en las que te encontrarás con nombres de variables crípticos en Elasticsearch, como rS y muBarSInverse.

La forma recomendada por el autor de leer un artículo: con un café grande.

Puedes enviar un email al autor

Al trabajar en un trabajo difícil, puedes pasar horas dándole vueltas a una fórmula, sin saber si estás malinterpretando o si simplemente hay un error tipográfico. Si fuera un proyecto de código abierto, podrías hacer una pregunta en GitHub o StackOverflow. Pero, ¿a dónde puedes acudir para un artículo académico? Los autores parecen ocupados y pueden molestar por tus correos.

Al contrario, a muchos académicos les encanta saber que sus ideas se están poniendo en práctica y están encantados de responder preguntas por email. Si trabajas en un producto que ellos conocen, ¡incluso pueden poner la solicitud en su sitio web!

También hay una tendencia creciente de académicos a debatir artículos en público, empleando muchas de las mismas herramientas del desarrollo de software. Si un artículo incluye un paquete de software adjunto, puede que encuentres respuestas a preguntas comunes en Github. Las comunidades de Stack Exchange como "Theoretical Computer Science" y "Cross Validated" también contienen discusiones detalladas sobre artículos populares. Algunas conferencias empezaron a publicar todas las reseñas de artículos en línea. Estas revisiones contienen conversaciones de ida y vuelta con los autores que pueden aportar ideas útiles sobre el enfoque.

Continuará

Esta publicación se centra en los fundamentos para elegir un trabajo académico y

Implementarlo correctamente, pero no cubre todos los aspectos del despliegue real del algoritmo. Por ejemplo, si el algoritmo es solo un componente en un sistema complejo, ¿cómo cercioramos que los cambios en el componente conduzcan a mejoras de extremo a extremo? ¿Y qué pasa si integrar el algoritmo requiere modificaciones o extensiones sustanciales que el artículo original no cubre? Son temas importantes sobre los que esperamos compartir más en futuras publicaciones.