Partiendo de los ejemplos de la parte 1, este blog analiza cómo usar diferentes técnicas y el poderoso kit de herramientas de búsqueda vectorial de Elasticsearch para preparar vectores de interacción tardía para cargas de trabajo de producción a gran escala.

Los ejemplos de código completos se pueden encontrar en GitHub.

Desafíos de los modelos de interacción tardía

ColPali crea más de 1000 vectores por página para los documentos de nuestro índice.

Esto plantea dos desafíos al trabajar con vectores de interacción tardía:

1. Espacio en disco: almacenar todos estos vectores en los discos implicará un uso considerable de almacenamiento, lo que será costoso a escala.

2. Cómputo: al clasificar los documentos mediante la comparación maxSimDotProduct(), necesitamos comparar todos estos vectores de cada documento con los N vectores de nuestra búsqueda.

Veamos algunas técnicas para abordar estos problemas.

Técnicas para optimizar modelos de interacción tardía

Vectores de bits

Para reducir el espacio en disco, podemos comprimir las imágenes en vectores de bits. Podemos usar una función sencilla en Python para transformar nuestros multivectores en vectores de bits:

El principio básico de la función es simple: los valores mayores que 0 se convierten en 1 y los valores menores que 0 se convierten en 0. Esto da como resultado un arreglo de 0 y 1, que luego se convierte en una cadena hexadecimal que representa el vector de bits.

Para nuestro mapping de índice, establecemos el parámetro element_type en bit:

Después de haber escrito todos nuestros nuevos vectores de bits en nuestro índice, podemos clasificar nuestros vectores de bits usando el siguiente código:

A cambio de una pequeña pérdida de precisión, esto nos permite utilizar la distancia de Hamming (maxSimInvHamming(...)), la cual aprovecha optimizaciones como máscaras de bits, SIMD, etc. Obtén más información sobre los vectores de bits y la distancia de Hamming en nuestro blog.

De forma alternativa, podemos no convertir nuestro vector de búsqueda en vectores de bits y realizar una búsqueda con el vector de interacción tardía de fidelidad completa:

Esto comparará nuestros vectores usando una función de similitud asimétrica.

Pensemos en una distancia de Hamming regular entre dos vectores de bits. Supongamos que tenemos un vector de documento D:

Y un vector de búsqueda Q:

La cuantificación binaria simple transformará los vectores D en 10101101 y Q en 11111011. Para encontrar la distancia de Hamming, necesitamos matemáticas de bits directas; es extremadamente rápido. En este caso, la distancia de Hamming es 01010110, que tiene un recuento de bits de 4. Así que, el puntaje se convierte en el inverso de esa distancia de Hamming. Hay que recordar que cuanto más vectores similares haya, menor será la distancia de Hamming, por lo que invertirla permite que los vectores más similares tengan una puntuación más alta. Concretamente aquí, el puntaje sería 1/4 = 0.25.

Sin embargo, observa cómo perdemos la magnitud de cada dimensión. Un 1 es un 1. Así que, para Q, la diferencia entre 0.01 y 0.79 desaparece. Como simplemente estamos cuantizando según >0, podemos hacer un pequeño truco donde el vector Q no está cuantizado. Esto no permite realizar operaciones matemáticas bit a bit extremadamente rápidas, pero mantiene bajo el costo de almacenamiento, ya que D sigue cuantificado.

En resumen, esto conserva la información proporcionada en Q, lo que aumenta la calidad de estimación de distancia y mantiene el almacenamiento bajo.

El uso de vectores de bits nos permite ahorrar significativamente en espacio en disco y carga computacional en el momento de la búsqueda. Pero hay más que podemos hacer.

Vectores promedio

Para escalar nuestra búsqueda a cientos de miles de documentos, ni siquiera las ventajas de rendimiento que nos ofrecen los vectores de bits serán suficientes. Para escalar a este tipo de cargas de trabajo, querremos aprovechar la estructura de índice HNSW de Elasticsearch para la búsqueda vectorial.

ColPali genera alrededor de mil vectores por documento, lo que es demasiado para agregar a nuestro grafo HNSW. Por lo tanto, necesitamos reducir el número de vectores. Para esto, se puede crear una única representación del significado del documento promediando todos los vectores del documento que genera ColPali al incrustar nuestra imagen.

Por ahora, esto no es posible dentro de Elastic, por lo que tendremos que procesar previamente los vectores antes de ingestarlos en Elasticsearch.

Podemos hacer esto con Logstash o pipelines de ingesta, pero aquí usaremos una función sencilla en Python:

Además, normalizamos el vector; de este modo, podremos usar la similitud por producto punto.

Luego de transformar todos nuestros vectores de ColPali en vectores promedio, podemos indexarlos en nuestro campo dense_vector:

Debemos tener en cuenta que esto aumentará el uso total del disco, ya que estamos almacenando más información junto con nuestros vectores de interacción tardíos. Además, usaremos RAM adicional para almacenar el grafo HNSW, lo que nos permitirá escalar la búsqueda a miles de millones de vectores. Para reducir el uso de RAM, podemos utilizar nuestra popular característica BBQ. A cambio, obtenemos resultados de búsqueda rápidos en conjuntos de datos masivos que de otra manera no serían posibles.

Ahora, simplemente hacemos una búsqueda con la consulta knn para encontrar nuestros documentos más relevantes.

La mejor coincidencia anterior, lamentablemente, cayó al tercer rango.

Para solucionar este problema, podemos realizar una recuperación en varias etapas. En nuestra primera etapa, utilizamos la búsqueda knn para buscar los mejores candidatos para nuestra búsqueda en millones de documentos. En la segunda etapa, solo reclasificamos los principales k (aquí: 10) con la mayor fidelidad de los vectores de interacción tardía de ColPali. 

Aquí, usamos el recalificador introducido en 8.18 para reclasificar nuestros resultados. Después de la recalificación, vemos que nuestra mejor coincidencia está nuevamente en la primera posición.

Nota: En una aplicación de producción, podemos usar un valor de k mucho mayor que 10, ya que la función de similitud máxima sigue siendo comparativamente eficiente.

Agrupación de tokens

La agrupación de tokens reduce la longitud de la secuencia de incrustaciones de vectores múltiples al agrupar información redundante, como parches de fondo blanco. Esta técnica reduce el número de incrustaciones, al tiempo que conserva la mayor parte de la señal de la página.

El agrupamiento de tokens funciona mediante la agrupación de incrustaciones similares de tokens dentro de un documento en clústeres con un algoritmo de agrupamiento en clusters. A continuación, se calcula la media de los vectores de cada grupo para crear una representación única y agregada. Este vector agregado reemplaza los tokens originales en el grupo, lo que reduce el número total de vectores sin una pérdida significativa de la señal del documento.

El documento de ColPali propone un valor inicial de factor de agrupación de 3 para la mayoría de los sets de datos, lo que mantiene el 97,8 % del rendimiento original y al mismo tiempo reduce el número total de vectores en un 66,7 %. 

Pero debemos tener cuidado: el set de datos “Shift”, que contiene documentos muy densos y con mucho texto con poco espacio en blanco, disminuye rápidamente en rendimiento a medida que aumentan los factores de grupo.

Para crear los vectores agrupados, podemos usar la biblioteca colpali_engine:

Ahora tenemos un vector que se redujo en aproximadamente un 66,7 % en sus dimensiones. Lo indexamos como siempre y podemos hacer búsquedas en él con nuestra función maxSimDotProduct().

Podemos obtener buenos resultados de búsqueda a costa de cierta precisión en los resultados.

Sugerencia: con un pool_factor más alto (100-200), también puedes tener un término medio entre la solución vectorial promedio y la que analizamos aquí. Con unos 5 a 10 vectores por documento, es viable indexarlos en un campo anidado para aprovechar el índice HNSW.

Codificador cruzado vs. interacción tardía vs. bicodificador

Con lo que hemos aprendido hasta ahora, ¿dónde se sitúan los modelos de interacción tardía, como ColPali o ColBERT, cuando los comparamos con otras técnicas de recuperación mediante AI?

Aunque la función max sim es más económica en comparación con los codificadores cruzados, todavía requiere muchas más comparaciones y cálculos que la búsqueda vectorial con codificadores binarios, en la que solo se comparan dos vectores para cada par de búsqueda-documento.

Por eso, nuestra recomendación para modelos de interacción tardía es usarlos generalmente solo para reclasificar los k mejores resultados de búsqueda. También reflejamos esto en el nombre del tipo de campo: rank_vectors.

¿Pero qué pasa con el codificador cruzado? ¿Son mejores los modelos de interacción tardía porque son más baratos de ejecutar en el momento de la búsqueda? Como suele suceder, la respuesta es: depende. Los codificadores cruzados generalmente producen resultados de mayor calidad, pero requieren una gran cantidad de recursos de cómputo porque los pares de búsqueda-documento necesitan hacer un pase completo a través del modelo transformador. También se benefician del hecho de que no requieren indexar vectores y pueden operar de manera sin estado. Esto da como resultado lo siguiente:

• Menor uso de espacio en disco.

• Un sistema más sencillo.

• Mayor calidad de los resultados de búsqueda

• Una latencia más alta y, por lo tanto, la imposibilidad de realizar una reclasificación tan profunda.

Por otro lado, los modelos de interacción tardía pueden descargar parte de este cálculo en el índice, lo que hace que la búsqueda sea más económica. El precio que pagar es la necesidad de indexar los vectores, lo que aumenta la complejidad de nuestros pipelines de indexación y requiere más espacio en disco para almacenarlos.

En el caso concreto de ColPali, el análisis de la información de las imágenes resulta muy costoso, porque contienen una gran cantidad de datos. En este caso, el equilibrio se desplaza a favor de utilizar un modelo de interacción tardía como ColPali porque evaluar esta información en el momento de la búsqueda consumiría demasiados recursos o sería demasiado lento.

Para un modelo de interacción tardía como ColBERT, que funciona con datos de texto como la mayoría de los codificadores cruzados (por ejemplo, elastic-rerank-v1), la decisión podría inclinarse más hacia usar el codificador cruzado para beneficiarse del ahorro y la simplicidad en disco.

Te recomendamos que evalúes las ventajas y desventajas para tu caso de uso y experimentes con las diferentes herramientas que Elasticsearch te proporciona para crear las mejores aplicaciones de búsqueda.

Conclusión

En este blog, analizamos diversas técnicas para optimizar modelos de interacción tardía como ColPali para búsquedas vectoriales a gran escala en Elasticsearch. Si bien los modelos de interacción tardía proporcionan un sólido equilibrio entre la eficiencia de recuperación y la calidad de clasificación, también presentan desafíos relacionados con el almacenamiento de información y el cómputo.

Para abordar estos desafíos, analizamos:

• Vectores de bits para reducir significativamente el espacio en disco, al tiempo que se aprovechan los cálculos de similitud eficientes como la distancia de Hamming o la similitud máxima asimétrica.

• Promedio de vectores para comprimir múltiples inserciones en una sola representación densa, lo que permite una recuperación eficiente con indexación HNSW.

• Agrupación de tokens para fusionar de forma inteligente las incorporaciones redundantes mientras se mantiene la integridad semántica, lo que reduce la sobrecarga computacional en el momento de la búsqueda.

Elasticsearch ofrece un conjunto potente de herramientas para personalizar y optimizar las aplicaciones de búsqueda en función de tus necesidades. Ya sea que priorices la velocidad de recuperación, la calidad de clasificación o la eficiencia de almacenamiento, estas herramientas y técnicas te permiten equilibrar el rendimiento y la calidad según lo que necesites para tus aplicaciones reales.

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.

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!

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!