Para los nuevos usuarios, esta es la forma más rápida de poner en marcha la búsqueda de vectores de alta calidad. Si ya usas Elasticsearch, la nueva oferta es la búsqueda de vectores en la plataforma donde ya residen tus datos, sin necesidad de adoptar un sistema nuevo. Elasticsearch Vector Database admite una variedad de situaciones, desde fundamentación para un modelo de lenguaje grande (LLM) hasta dotar a un agente de IA de recuperación y memoria, y prestar servicio a cientos de miles de millones de vectores. Crea un nuevo proyecto y comienza en minutos.

Un motor, todos los casos de uso vectoriales

La base de datos vectorial de Elasticsearch está diseñada para cualquier persona que desarrolle aplicaciones con vectores:

• RAG: recupera el contexto adecuado para tu LLM con la recuperación de vectores densos y dispersos, o elige la búsqueda híbrida combinando la recuperación vectorial y léxica. La calidad de tu generación mejora con la calidad de tu recuperación.

• Agentes de IA: brinda a los agentes una recuperación rápida y filtrada de documentos y memoria de conversación, con las bajas latencias que demandan los bucles de agentes de varios pasos.

• Búsqueda semántica: busca coincidencias según el significado, no por palabras clave, con un tipo de campo y cero código de pipeline.

• Recomendaciones y similitud: encuentra los vecinos más cercanos en productos, imágenes o cualquier contenido que tengas, a escala.

Todo lo que tu carga de trabajo vectorial necesita, optimizado y listo para usar

Crear una aplicación basada en vectores implica conectar varias piezas independientes: configurar y alojar modelos de incrustación, indexar tus documentos a través de ellos, almacenar los vectores de forma eficiente, aplicar el modelo de incrustación a cada búsqueda, comparar con el almacenamiento vectorial y, por último, recuperar los documentos detrás de las coincidencias. La base de datos vectorial de Elasticsearch se encarga de todo por ti, sin configuración ni ajustes adicionales.

Indexación de vectores con el modo de índice vectordb_document

El modo de índice vectordb_document, una nueva configuración de índice diseñada especialmente para cargas de trabajo centradas en vectores, está activado de forma predeterminada, por lo que obtienes la configuración que elegirían los expertos. Esto es lo que activa:

• bfloat16 de forma predeterminada: Los vectores se almacenan con la mitad del tamaño de float32 y un impacto insignificante en la recuperación, lo que reduce aproximadamente a la mitad el espacio en disco incluso antes de que entre en juego la cuantización.

• Vectores de origen excluidos: en Elasticsearch, tus incrustaciones ya se encuentran en las estructuras de índice que se usan para la búsqueda; mantener una segunda copia sin procesar in _source solo infla el almacenamiento y ralentiza la recuperación de resultados. Excluimos el duplicado para que las respuestas se devuelvan más rápido y almacenes menos.

• Los archivos adecuados precargados en caché: las estructuras de datos a las que primero acceden las búsquedas vectoriales se cargan en la memoria con anticipación, para que tu primera (y tu milésima) búsqueda sea ultrarrápida.

• Combinación paralela: La combinación consolida los segmentos en estructuras vectoriales mejor organizadas, lo que mejora tanto la recuperación como la latencia, y ejecutar esas combinaciones en varios hilos permite lograrlo más rápido.

Almacenamiento de vectores, compresión y ajuste automático

• Tus vectores se comprimen automáticamente. Better Binary Quantization (BBQ) reduce la huella de memoria de los vectores hasta 32 veces mientras conserva la recuperación, y DiskBBQ reduce aún más los requisitos de memoria para cargas de trabajo a gran escala. 

• Opta por la autocalibración, que ajusta la cuantización de cada segmento a tus datos y la vuelve a calibrar en cada fusión a medida que los datos varían. Al probarse en 18 sets de datos, las búsquedas por segundo (QPS) mejoraron un promedio de 16.7 %, con mejoras en la recuperación en la mayoría de ellos.

Incrustaciones en inferencia por GPU administrada

• Genera incrustaciones con modelos nativos de incrustación y reclasificación de Jina AI, o incorpora modelos de terceros, todo en GPU administradas a través de Elastic Inference Service (EIS) sin tener que operar servidores de modelos. O autohospeda, si prefieres el tuyo propio.

• El tipo de campo semantic_text maneja automáticamente la fragmentación y la generación de incrustaciones, junto con las consultas, el camino más simple hacia la búsqueda semántica en el mercado. 

Búsqueda híbrida y búsqueda vectorial filtrada

• La búsqueda híbrida viene integrada, combinando la recuperación de texto completo y vectorial en una sola búsqueda. Combina los resultados con la fusión de rango recíproco (RRF) o cualquier otro mecanismo de combinación que quieras. La búsqueda vectorial suele ser la parte de la búsqueda híbrida más difícil de configurar bien. Con la base de datos vectorial de Elasticsearch, lo tienes resuelto y toda tu pila híbrida mejora. 

• Con la búsqueda de vectores filtrada, aplica filtros de metadatos como parte de la propia recuperación de vectores y no como una idea de último momento que arruina la exhaustividad.

Empresarial desde el primer día

También obtienes control de acceso basado en roles (RBAC), logs de auditoría y las certificaciones de cumplimiento de las que generalmente carecen las bases de datos vectoriales dedicadas.

Accesible a escala y predecible

La base de datos vectorial de Elasticsearch está diseñada para seguir siendo accesible a medida que creces: la compresión BBQ y DiskBBQ que mantiene el almacenamiento lineal y la memoria baja significa que el escalado a cientos de miles de millones de vectores no disparará tu factura. Y lo que pagas se calcula a partir de números que ya conoces: cuántos datos almacenas y cuántos indexas, junto con cuánta capacidad de búsqueda necesitas. Estima tu cantidad de documentos y dimensiones de vectores, además de tu carga de búsqueda, y podrás calcular lo que pagarás antes de crear el proyecto. También puedes entender todos los conceptos de tu factura al final del mes. No hay unidades de cómputo opacas ni cargos sorpresa por operaciones en segundo plano.

Cómo comenzar con la base de datos vectorial de Elasticsearch

Crea un proyecto serverless de base de datos vectorial

Crea un nuevo proyecto sin servidor de base de datos vectorial en Elastic Cloud. Apunta los datos al endpoint y todo estará listo para indexar.

Crea un índice usando semantic_text

El modo de índice de vectores gestiona la configuración de vectores. Usar semantic_text significa que la configuración de las incrustaciones y la fragmentación se gestiona por ti, al igual que la configuración del índice, en inferencia de GPU gestionada, sin necesidad de crear un pipeline de incrustaciones.

Ingestar documentos

Indexa texto y las incrustaciones se generan para ti.

Ejecuta una consulta de búsqueda semántica

Consulta el mismo campo semántico que acabas de crear:

Y recibes los resultados:

La búsqueda semántica es solo el comienzo. Ejecuta búsquedas totalmente textuales o combina ambas en búsquedas híbridas. Incluso puedes crear tus propias búsquedas de vectores para tener control total. Sigue la guía de inicio rápido de búsqueda semántica en la documentación para obtener todas las instrucciones.

Qué sigue para la búsqueda de vectores en Elasticsearch

Ya estamos trabajando en las próximas mejoras:

• Mejor manejo de varios inquilinos: si tus datos deben mantenerse separados por inquilino, te daremos una forma de hacerlo más rápido y con menos código.

• Optimización automática del índice: de "índice completamente nuevo" a "totalmente optimizado", con los menores ajustes posibles.

• Mejoras continuas de la infraestructura: Ajuste continuo de la configuración y la infraestructura de la base de datos vectorial para obtener siempre el mejor rendimiento y las respuestas más rápidas.

Prueba la base de datos vectorial de Elasticsearch en Elastic Cloud Serverless

Pasa de un proyecto vacío a una búsqueda vectorial híbrida y filtrada en minutos, con valores predeterminados de nivel de producción que se encargan del ajuste por ti. Crea apps de IA rápidas y escalables en lugar de infraestructura.

Comienza con Elastic Cloud Serverless o explora la documentación completa y la referencia de la API.

¿Qué es la recuperación?

La recuperación mide en una escala de 0 a 1 cuántos de los documentos que realmente quieren tus usuarios aparecen en algún lugar de los resultados de búsqueda. Si una consulta debe mostrar tres productos y la búsqueda solo arroja dos de ellos en los 10 principales, recall@10 = 0.67 para esa consulta. Es una métrica basada en conjuntos: no le importa la posición de los documentos relevantes dentro de esos k resultados. Un documento relevante en la posición 10 cuenta igual que uno en la posición 1. Tener una recuperación alta significa que no estás perdiendo resultados relevantes.

El diagrama muestra dos conjuntos: todos los documentos relevantes (izquierda) y lo que BM25 realmente recuperó (10 principales, derecha). Solo la intersección cuenta para la recuperación, se encontraron prod_1 y prod_2, mientras que prod_3, prod_4 y prod_6 se perdieron por completo. Resultado: Recall@10 = 2/5 = 0.40.

Requisitos previos

Pongamos manos a la obra para comprender mejor cómo funciona la recuperación. Esta demostración utiliza Python. Puedes seguirlo en el cuaderno complementario (notebook.ipynb), donde cada bloque de código es una celda lista para ejecutarse.

El código proporcionado utiliza lo siguiente:

• Elasticsearch 9.3+

• Python 3.10+

• Un archivo .env con tus credenciales de Elasticsearch

El set de datos

Emplearemos un catálogo con 1000 productos, que abarcan categorías como calzado, electrónica, herramientas y más.

Cada documento tiene cuatro campos:

Campo

Tipo

`título`

texto

'descripción'

texto

`marca`

palabra clave

'categoría'

palabra clave

El set de datos se carga desde dataset.csv.

El poder y los límites de la búsqueda léxica

BM25 es el algoritmo de clasificación predeterminado en Elasticsearch y en la mayoría de los motores de búsqueda. Califica los documentos según la frecuencia con la que aparecen tus términos de consulta en ellos, ajustado por la longitud del documento y la frecuencia de esos términos en todo el índice. Los analizadores aparecen en la parte superior: normalización de minúsculas, derivación y eliminación de palabras vacías. Una búsqueda de "zapatillas para correr" coincidirá con "Zapatillas para correr" y probablemente también con "correr".

Esto funciona bien para una amplia clase de consultas:

• "zapatillas de correr" muestra de inmediato los productos que contienen exactamente esas palabras en el título.

• "parlante con bluetooth" muestra productos de audio portátiles porque los tokens aparecen textualmente.

Los resultados son deterministas y explicables: un documento se clasifica alto porque los términos de la consulta aparecen en él. Depurar la relevancia es sencillo.

Cuándo falla

Ahora probemos estas búsquedas en el mismo catálogo:

• "rutina de skincare": la palabra "rutina" no aparece en ningún título de producto. BM25 puede hacer una coincidencia parcial con "skincare", pero los sueros faciales, aceites corporales y humectantes se describen utilizando términos como "vitamina C", "retinol" o "aclarante", ninguno de los cuales se superpone con la consulta. Los productos que forman una rutina completa de skincare están dispersos en el índice sin ningún token compartido para anclarlos.

• "accesorios de viaje para mascotas": esta es una agrupación de casos de uso, no una categoría de producto. Un transportín para perros, un asiento para mascotas en el automóvil y una jaula de viaje son todos relevantes, pero sus descripciones hablan sobre portabilidad, seguridad y comodidad en vez de "accesorios de viaje". BM25 coincide con "mascota" de manera amplia, pero no tiene ninguna señal para distinguir los productos específicos de viaje del resto del catálogo de mascotas.

Este es un problema de recuperación. Los documentos relevantes están en tu índice. BM25 simplemente no puede encontrarlos porque las palabras del usuario y las del documento no coinciden lo suficiente.

Agregar sinónimos es útil en casos conocidos. Pero no se puede enumerar todas las formas en que un usuario podría expresar una intención. Ahí es donde entran los vectores.

Por qué deberías medir el recall

Antes de solucionar un problema, necesitas cuantificarlo.

Recall@k mide cuántos de los documentos que realmente buscan tus usuarios aparecen en algún lugar de los resultados de búsqueda. Es decir:

Precision@k mide los mejores k resultados y cuántos son realmente relevantes:

La alta precisión significa que los resultados que se devuelven son buenos. En el comercio electrónico, no mostrar un producto relevante (baja recuperación) suele ser peor que mostrar un resultado ligeramente imperfecto (menor precisión), porque un producto oculto es una venta perdida.

La API rank_eval de Elasticsearch te permite medir ambos de forma sistemática. Proporcionas una lista de consultas, cada una con un conjunto de documentos calificados, y Elasticsearch calcula las métricas por ti en todas las consultas.

Configuración de la evaluación

La API rank_eval necesita un set de datos de calificaciones: un mapeo de consultas a los documentos que son relevantes para cada uno, junto con un grado de relevancia (0 = no relevante, 1 = relevante, 2 = altamente relevante).

En el cuaderno, esta es la lista de evaluaciones:

La combinación es intencionada: q1 es una consulta que BM25 maneja bien (tokens exactos en los títulos de productos), mientras que q2, q3 y q4 son consultas basadas en la intención donde la intención del usuario se expresa como un concepto en lugar de palabras clave específicas de producto.

Medición de la recuperación basal de BM25

Primero, configura el cliente de Elasticsearch e indexa los datos de texto sin procesar:

Ahora crea la solicitud rank_eval para BM25. Cada solicitud en la lista combina una consulta con sus calificaciones:

Resultado:

0.43 significa que en las cuatro consultas, BM25 encuentra solo el 43 % de los documentos que debería encontrar. La deficiencia se concentra en las consultas basadas en la intención: "rutina de skincare" no encuentra sueros faciales ni aceites corporales porque la palabra "rutina" nunca aparece en los títulos de los productos, y "accesorios de viaje para mascotas" recupera productos para mascotas que no tienen relación con el tema, mientras que no encuentra transportines ni jaulas descritos en términos de portabilidad y seguridad en vez de "accesorios de viaje".

Esta es nuestra referencia base. Ahora tenemos un número que superar.

Agregar búsqueda vectorial con embeddings de Jina

Vector search Codifica documentos y consultas como vectores de alta dimensión, un tipo de vector compuesto por cientos o miles de valores numéricos, cada uno de los cuales codifica una característica específica de los datos que representa. Los documentos con significado similar terminan cerca unos de otros en el espacio vectorial, incluso si no comparten palabras. "Equipo de gimnasio" y "conjunto de mancuernas" estarán cerca porque los conceptos están relacionados. Elegí Elasticsearch como mi base de datos vectorial porque admite la búsqueda híbrida, lo que me brinda comprensión semántica y precisión de palabras clave de inmediato.

EIS incluye soporte integrado para la incorporación de modelos a través de su API de inferencia.

Paso 1: usar las incrustaciones de Jina v5 como endpoint de inferencia

Si tu clúster tiene recursos de GPU (disponibles en Elastic Cloud y Elasticsearch 9.3+), las incrustaciones se generan en GPU, lo cual es mucho más rápido que la inferencia de CPU y elimina el compromiso de rendimiento que históricamente hacía que los vectores fueran caros a gran escala.

¿Por qué las incrustaciones de Jina en particular? jina-embeddings-v5-text es un modelo multilingüe (más de 119 idiomas) con una ventana de contexto de 32 000 tokens y soporte para adaptadores de Adaptación de Rango Bajo (LoRA) específicos para tareas. Funciona bien para descripciones cortas de productos que están listas para usar. Lee más sobre el modelo jina-embeddings-v5-text aquí.

Paso 2: Crear el índice con un campo semántico

El tipo de campo semantic_text es la clave aquí. Es una abstracción de mayor nivel sobre dense_vector: la apuntas a un endpoint de inferencia, y Elasticsearch se encarga de generar incrustaciones de forma automática.

La propiedad copy_to en title y description significa que el contenido de ambos campos fluye hacia semantic_field para su incrustación, por lo que un solo vector captura la representación completa del producto.

Paso 3: Indexar los productos

En tiempo de indexación, Elasticsearch llama al endpoint de inferencia para cada documento y almacena la incrustación resultante en semantic_field. No necesitas agregar ningún código adicional.

Búsqueda híbrida: combinación de BM25 y vectores con RRF

Agregar vectores mejora la recuperación, pero usar solo vectores corre el riesgo de perder precisión en las consultas de coincidencia exacta; "zapatillas para correr" aún debe clasificar primero las coincidencias literales. La búsqueda híbrida retiene el componente léxico específicamente para preservar esa precisión.

La búsqueda híbrida con Reciprocal Rank Fusion (RRF) combina lo mejor de ambos:

• BM25 se ocupa de consultas exactas y casi exactas con alta precisión.

• La búsqueda semántica gestiona consultas basadas en la intención y multilingües con alto nivel de recuperación.

• RRF combina las dos listas clasificadas en una sola clasificación.

La fórmula RRF asigna a cada documento una puntuación basada en su clasificación en cada lista de resultados:

Un documento que se clasifica en una posición alta en ambas listas obtiene una puntuación combinada más alta. El rank_constant controla cuánto peso reciben los documentos de menor rango.

Resultado:

La búsqueda híbrida mejora sustancialmente sobre BM25 (0.43) y preserva la precisión para consultas de coincidencia exacta como "zapatillas para correr".

Resultados: Antes y después

Aquí está la comparación completa entre los tres enfoques:

Resultado:

Método

Recall@10

BM25 (Lexical)

0,43

Híbrido (BM25 + Vectores)

0,75

Desglose por consulta:

Conclusión

A lo largo de esta publicación, vimos que la búsqueda léxica BM25 es confiable cuando los usuarios teclean consultas exactas, pero pierde recuperación cuando buscan por intención en lugar de palabras clave. Usando rank_eval, establecimos una línea de base reproducible para medir esa brecha con números reales. A partir de ahí, agregamos un semantic_text campo impulsado por incrustaciones de Jina y volvimos a ejecutar la evaluación. El resultado: la búsqueda híbrida mejoró la recuperación de 0.43 a 0.75 a la vez que conservó la precisión en las consultas de coincidencia exacta, aunque el margen real dependerá de tu combinación de consultas.

El patrón escala más allá de este ejemplo: recopila juicios de las consultas reales de tus usuarios, ejecuta rank_eval como línea de base, agrega semantic_text y vuelve a medir. Sabrás exactamente qué mejoró y en qué medida.

Pasos siguientes

• Aprende más sobre la recuperación y la búsqueda de vectores: Recuperación y cuantización de la búsqueda de vectores por Jeff Vestal

• Añade reclasificación para una precisión aún mejor en los resultados principales

• Explora la documentación de búsqueda híbrida de Elasticsearch

• Lee más sobre la API rank_eval

Cómo construimos Elasticsearch SIMDvec

Cada consulta de búsqueda vectorial en Elasticsearch, ya sea un recorrido de mundo pequeño jerárquico navegable (HNSW), un escaneo de archivo invertido (IVF) o una pasada de reclasificación, se reduce al mismo problema: calcular distancias entre vectores, millones de veces por búsqueda. Elasticsearch admite una amplia gama de tipos de datos y estrategias de cuantificación, desde float32 hasta int8, bfloat16, binario y Mejor cuantificación binaria (BBQ). Cada una tiene distintas compensaciones entre memoria, rendimiento y recuperación. Detrás de todo esto hay un único motor: simdvec.

Creamos simdvec para que cada cálculo de distancia sea tan rápido como el hardware lo permita. En esta publicación, explicamos por qué lo creamos, qué contiene y dónde produce el mayor impacto.

Creado como un auto de carreras

Como aficionados a la Fórmula 1, y dado que uno de nosotros trabajó anteriormente con el equipo Ferrari de Fórmula 1, vemos un claro paralelismo. Un auto de Fórmula 1 está diseñado con un solo propósito: lograr el mejor tiempo de vuelta. La potencia del motor, la aerodinámica y el diseño del chasis solo importan en la medida en que contribuyen a ese resultado. Lo mismo ocurre con una base de datos vectorial, donde el rendimiento de indexación, la latencia de búsqueda y la recuperación definen el éxito.

Aunque lo que importa es el resultado final, para alcanzar los máximos niveles de rendimiento es necesario que cada componente funcione a la perfección. No puede ser solo lo suficientemente bueno, tiene que ser el mejor en su categoría. Simdvec está construido con esa mentalidad, que se enfoca en una parte fundamental del sistema: el motor. Es una biblioteca de kernel optimizada para una sola instrucción y múltiples datos (SIMD) diseñada específicamente, que proporciona funciones nativas de distancia en C++ ajustadas a mano, llamadas desde Java a través de la interfaz para funciones externas (FFI) de Panamá. Admite evaluación masiva, precarga de líneas de caché y todos los tipos de vectores y diseños utilizados en Elasticsearch.

Ese es el motor que hay detrás de cada búsqueda.

Por qué creamos nuestro propio motor

Comenzamos en 2023 con la API Panama Vector en Apache Lucene. Funcionaba bien para productos punto float32, pero las necesidades de Elasticsearch superaron rápidamente lo que podía ofrecer. Elasticsearch admite una amplia gama de tipos de vectores cuantificados: int8, int4, bfloat16, de un solo bit y BBQ asimétrico. Cada uno tiene diferentes estrategias SIMD, diseños de empaquetado y requisitos de acumulador. Más allá de la cobertura de tipos, las rutas de puntuación de Elasticsearch exigen algo más que un rendimiento de un solo par: HNSW necesita puntuar varios vecinos del grafo en una sola pasada, IVF necesita puntuar en masa miles de candidatos con precarga y la puntuación basada en disco debe funcionar directamente en la memoria mapeada con mmap sin necesidad de copiar. Examinamos lo que estaba disponible y nada abarcaba el conjunto completo.

Así que construimos simdvec: kerneles C++ nativos ajustados a mano llamados desde Java a través de FFI, con puntuación masiva, precarga y soporte para cada tipo de vector que usa Elasticsearch. Al ser propietarios de la biblioteca, controlamos el stack completo. Cuando añadimos un nuevo tipo de cuantificación, como BBQ, se le asigna un kernel SIMD optimizado que se integra en todo el sistema. No esperamos a que una biblioteca upstream le de soporte y no comprometemos el rendimiento para ningún tipo. Cada consulta vectorial en Elasticsearch, ya sea HNSW, IVF, reranking o híbrida, se ejecuta en este motor, construido en torno a las operaciones y los tipos que realmente usamos.

Simdvec tiene bibliotecas nativas separadas para x86 y ARM, cada una con múltiples niveles de arquitectura de conjunto de instrucciones (ISA) seleccionados al inicio. La sobrecarga de llamadas desde Java vía FFI es muy baja, con nanosegundos de un solo dígito.

El panorama

No somos los únicos que construimos kerneles de distancia vectorial optimizados para SIMD. El ecosistema es rico y queríamos comprender cómo se desempeña simdvec. No para clasificar proyectos, sino para proporcionar contexto y explicar dónde se encuentra el motor de Elasticsearch. Seleccionamos tres proyectos como puntos de referencia, cada uno representando un enfoque diferente:

• jvector: Una biblioteca de Java de vecino más cercano aproximado (ANN) que emplea la API Panama Vector para el cálculo vectorizado de distancias, con aceleración nativa en C opcional en x86.

• FAISS: Un marco de trabajo de búsqueda vectorial de open source ampliamente desplegado, con kerneles AVX2/AVX-512 ajustados a mano.

• NumKong (anteriormente SimSIMD): un conjunto completo de más de 2 000 kerneles SIMD ajustados a mano que abarcan funciones de distancia, operaciones matrices y computación geoespacial.

Cada proyecto cumple un propósito diferente y realiza diferentes concesiones. Incluimos números de referencia de ellos para dar contexto al rendimiento de simdvec en las operaciones específicas que Elasticsearch necesita.

Cómo medimos

Las evaluaciones de simdvec y jvector están escritos en Java con JMH, la microevaluación estándar de JVM, lo que incluye la sobrecarga de FFI. Para las evaluaciones de NumKong y las evaluaciones de FAISS, escribimos pequeños marcos de prueba de C/C++ con Google Benchmark, que es el marco de trabajo estándar para microevaluaciones de C++. Ambos marcos de trabajo reportan nanosegundos por operación con calibración de calentamiento e iteración. Verificamos mediante contadores de rendimiento de hardware que todas las bibliotecas usan SIMD en ambas plataformas. Todo el código de evaluación está disponible públicamente en los repositorios enlazados de GitHub (y, en el caso de simdvec, en el repositorio elasticsearch).

Software: JDK 25.0.2, JMH 1.37, GCC 14, Google Benchmark (última versión).

Un vector a la vez

La operación más básica en la búsqueda vectorial es calcular la distancia entre dos vectores. Cada evaluación de un vecino de HNSW, cada puntaje de un candidato a IVF, cada comparación de reclasificación se reduce a este bucle interno.

Medimos el rendimiento de un solo par en 1024 dimensiones en ambas plataformas, empezando por float32, el tipo base y el donde el ecosistema es más competitivo. Comparamos simdvec con FAISS y jvector; hemos excluido NumKong porque utiliza acumuladores float64 para float32, lo que lo hace entre 3,2 y 5,3 veces más lento (dependiendo de la plataforma), ya que prioriza la precisión numérica por encima del rendimiento. Para mantener la comparación de igual a igual, evaluamos NumKong en int8 en su lugar, donde utiliza la misma estrategia de acumulador que simdvec.

En la arquitectura x86, FAISS AVX-512 es el kernel de par único más rápido, con un tiempo de ejecución de 23 ns. A continuación, se ejecuta Simdvec AVX-512 a los 28 ns, un intervalo que refleja la sobrecarga de la llamada FFI. Ambos emplean FMA de 512 bits con desenrollado de múltiples acumuladores. A nivel AVX2, los dos valores son mucho más similares, 36 ns y 39 ns respectivamente, ambos limitados por el ancho de carga de memoria y registro de 256 bits. jvector tarda 44 ns usando la API de Java Panama Vector. Panamá genera buen código SIMD, pero las funciones intrínsecas de C++ ajustadas manualmente siguen teniendo ventaja.

En ARM, simdvec lidera a 70 ns, muy por delante de jvector a 110 ns y FAISS a 156 ns. Simdvec tiene kernels NEON ajustados a mano para aarch64. Jvector no tiene código ARM nativo y depende de Panama. FAISS se basa en la auto-vectorización del compilador en lugar de en las intrínsecas NEON explícitas, lo que explica la mayor brecha. Esto refleja una ventaja práctica de poseer la biblioteca del kernel: cuando Elasticsearch se expandió a Graviton, agregamos kerneles NEON especialmente diseñados. Ni jvector ni FAISS priorizaron el código nativo de ARM en la misma medida.

Sin embargo, Elasticsearch no solo puntúa float32. La cuantificación Int8 reduce la memoria en 4x, bfloat16 en 2x y BBQ en 32x. Cada tipo necesita su propia estrategia SIMD, y simdvec proporciona kernels nativos ajustados a mano para todos ellos.

De todas las bibliotecas que comparamos, solo NumKong tiene kernels comparables para int8. Medimos el producto escalar int8, la distancia euclidiana al cuadrado y el coseno en 1024 dimensiones.

Puntuación de par único Int8 (1024 dimensiones, ns/vec op — cuanto más bajo, mejor)

En ambas arquitecturas, NumKong es igual o más rápido en dimensiones pequeñas y medias, donde la diferencia se debe en gran parte a una menor sobrecarga de llamadas (llamada C directa vs FFI en Java). En dimensiones mayores, simdvec se pone al día, donde la implementación más eficiente del kernel (que emplea desenrollamiento en cascada) amortiza el costo de llamada: a medida que aumenta la dimensión, esta brecha se cierra y finalmente se revierte. El cruce está en dimensiones entre 768 y 1536, dependiendo de la función y la arquitectura.

A pesar de la sobrecarga ligeramente mayor de Java FFI, simdvec está a la par con las bibliotecas altamente optimizadas de C/C++. No solo es la única librería con kernels optimizados tanto para float32 como para int8, sino que también lidera en ARM y solo está ligeramente por detrás de FAISS en x86 (para float32), y muy cerca de NumKong en ambas arquitecturas (para int8). Y en el caso de bfloat16, int4, binary y BBQ, aunque existen alternativas, simdvec se distingue por su SIMD ajustado manualmente y adaptado a la estructura de datos de cada tipo.

Pero un motor de búsqueda en producción no califica un vector a la vez; califica miles por consulta. La siguiente pregunta es qué sucede a esa escala.

Miles a la vez

El rendimiento de un solo par es solo una parte del panorama. Lo que importa en la práctica es cómo se comportan los sistemas bajo carga. Una sola consulta HNSW puede puntuar cientos de vecinos de grafos. Un escaneo de IVF puede puntuar miles de entradas en la lista de publicaciones. Un paso de reclasificación puede puntuar decenas de miles de candidatos. El rendimiento por par individual es importante, pero lo que más importa es la rapidez con la que puedes puntuar muchos vectores, y cómo se degrada el rendimiento de forma gradual a medida que el conjunto de trabajo se desborda de las cachés de la CPU.

Simdvec proporciona evaluación masiva para todos los tipos de datos. No son solo bucles sobre kernels de un solo par; usan bucles internos de varios acumuladores que cargan el vector de búsqueda una vez por paso de dimensión y lo comparten entre varios vectores de documentos, con precarga explícita de líneas de caché para el siguiente batch. Ni jvector ni FAISS ofrecen un equivalente (en el momento de redacción de esta publicación). Jvector no tiene una API de bulk, así que quien llama puntúa un par a la vez en un bucle. FAISS expone fvec_inner_products_ny que, en el momento de redacción de esta publicación, está implementado como un bucle sobre su función de distancia de un solo par, sin amortización de la búsqueda ni precarga.

Float32. Para medir el impacto a nivel del kernel, puntuamos una sola consulta contra un número creciente de vectores de documentos float32 de 1024 dimensiones con patrones de acceso aleatorio que simulan búsquedas de vecinos de grafos dispersos similares a HNSW. Los tres tamaños de sets de datos, 32, 625 y 32 500 vectores, se eligen para que el conjunto de trabajo supere la caché L1, L2 y L3, respectivamente.

Cuando los datos caben en la caché, simdvec es el más rápido en ambas plataformas, pero las diferencias son modestas, ya que predomina la aritmética del kernel. La separación real se nota cuando el conjunto de trabajo supera el tamaño de L3. En x86, simdvec alcanza los 95 ns por vector, mientras que FAISS necesita 165 ns y jvector 412 ns. En ARM, la tendencia es la misma: simdvec se mantiene en 162 ns, mientras que FAISS sube a 347 ns y jvector a 476 ns. La precarga y la amortización de búsquedas en simdvec mantienen la latencia de memoria oculta de una manera que un bucle simple sobre kerneles de par único no puede coincidir y el beneficio se amplía precisamente donde operan las cargas de búsqueda reales, en lo profundo de la memoria principal.

Int8. Lo mismo ocurre con los tipos cuantificados. Medimos el rendimiento del cálculo del producto escalar int8 en 1024 dimensiones con sets de datos de un tamaño tal que superaran los límites de las cachés L1, L2 y L3, en comparación con el cálculo en bloque de simdvec con el cálculo de pares individuales de NumKong en un bucle.

En x86, simdvec es entre 1,2 y 1,9 veces más rápido, impulsado por la combinación de precarga explícita y procesamiento por lotes. En ARM, simdvec gana de nuevo (1,7 a 1,9 veces más rápido) en todos los tamaños de sets de datos. La ventaja radica en el procesamiento por lotes de cuatro vectores a la vez, lo que proporciona paralelismo a nivel de memoria mediante un patrón de acceso intercalado. En ambos casos, el resultado más llamativo es lo que ocurre en el mayor tamaño de set de datos, donde más importa.

Los resultados para la distancia al cuadrado y el coseno muestran un patrón similar, con aceleraciones de 1,4 a 1,8 veces para ARM, y de 1,3 a 3,0 veces para x86 (detalles aquí).

Cuando la memoria importa

Los índices de vectores de producción normalmente no caben en la caché de la CPU. Un índice de 10M-vectores int8 a 1024 dimensiones es de 10 GB. La evaluación de candidatos implica el procesamiento en flujo continuo de datos desde la DRAM y ahí es donde la arquitectura de evaluación masiva marca la diferencia.

Usamos contadores de rendimiento de hardware para medir lo que sucede dentro de la CPU durante la puntuación masiva y descubrimos que ocultar la latencia de la memoria requiere dos estrategias fundamentalmente diferentes, una por arquitectura.

En x86, la precarga explícita elimina los fallos de caché. El kernel masivo procesa los vectores secuencialmente, uno completamente calculado antes del siguiente, mientras emite instrucciones de precarga para el siguiente batch. Los datos futuros se cargan en la L1 antes de que la CPU los necesite.

En ARM, el mismo enfoque secuencial tuvo un rendimiento deficiente, incluso con precarga. En cambio, el kernel masivo entrelaza las cargas de cuatro vectores en cada posición de zancada, lo que proporciona al motor fuera de orden cuatro flujos de memoria independientes. La CPU no recoge datos más rápido, sino que espera menos al tener siempre algo más que calcular mientras las solicitudes de memoria están en curso. Puedes encontrar un análisis detallado en este ticket de GitHub.

Los números cuentan dos historias diferentes:

1. En x86, la precarga convierte 139K fallos de caché en 19K y las instrucciones por ciclo (IPC) se duplican más de dos veces. La ventaja de masa crece con el tamaño de los sets de datos, de 1,2 veces en L2 a 2,8 veces más allá de L3, porque la precarga oculta progresivamente viajes de ida y vuelta de DRAM más costosos.

2. En ARM, los fallos de caché apenas cambian. Lo que cambia es la utilización: las interrupciones del backend disminuyen un 40 % porque el patrón de acceso intercalado mantiene el pipeline alimentado. Esta ventaja se mantiene en un consistente 1,8 veces independientemente del tamaño del sets de datos, porque el paralelismo a nivel de memoria se aplica tanto si los datos provienen de la caché como de la DRAM.

Dos arquitecturas, dos estrategias y un resultado: a escala de producción, simdvec mantiene la pipeline de la CPU ocupada incluso cuando los vectores están dispersos por la memoria principal.

Qué significa esto para los usuarios de Elasticsearch

Estas capacidades a nivel de kernel se potencian entre sí. Una única consulta de búsqueda vectorial puede calcular millones de operaciones de distancia: recorrido del grafo HNSW, puntuación de candidatos, reclasificación. En miles de búsquedas concurrentes, los nanosegundos por operación se traducen directamente en latencia de búsqueda y rendimiento del cluster. Tanto si usas float32, int8, bfloat16 o BBQ, tanto si tu índice está en la memoria como en el disco, simdvec es el motor subyacente, y cada una de esas operaciones pasa por el mismo motor, lo que optimiza hasta el último nanosegundo.

La conclusión clave es que, a escala de producción, el rendimiento de la búsqueda vectorial no está determinado principalmente por el rendimiento bruto de SIMD. Lo que marca la diferencia es la eficiencia con la que el sistema oculta la latencia de la memoria mientras mantiene el rendimiento computacional en millones de operaciones pequeñas.

Los kerneles de simdvec mejoran prácticamente con cada versión de Elasticsearch. Cuando surgen nuevos tipos de cuantización y plataformas de hardware, reciben kerneles ajustados desde el primer día. Y los tipos existentes siguen ganando velocidad a medida que perfeccionamos las implementaciones que ya están disponibles.

Las organizaciones acumulan grandes colecciones de documentos, como tickets de soporte, presentaciones legales, feeds de noticias y trabajos de investigación, pero para poder hacer las preguntas correctas, primero necesitan entender lo que contienen. Sin etiquetas o datos de entrenamiento, revisar manualmente miles de documentos es poco práctico. La búsqueda tradicional no es útil cuando no sabes qué buscar.

Esta publicación describe un enfoque nativo de Elasticsearch para la agrupación no supervisada de documentos y el seguimiento temporal de temas que aborda este problema de descubrimiento. Después de leerla, podrás seguir la evolución de distintos temas a lo largo de varios días:

Lo que descubrirás:

• Por qué las incrustaciones de agrupación (y no las incrustaciones de recuperación) son fundamentales para descubrir temas sin una consulta.

• Cómo la clasificación de centroides con sonda de densidad agrupa documentos por tema usando Elasticsearch k vecinos más cercanos (kNN) y lotes de msearch.

• ¿Cómo puede significant_text autoetiquetar clústeres para que los temas sean legibles sin entrenar un modelo?

• De qué forma las cadenas temporales de temas conectan los clústeres de datos diarios para mostrar la evolución de los temas día a día.

El pipeline utiliza unos 8500 artículos de febrero de 2025 de BBC News y The Guardian como corpus de prueba. Si bien las noticias son convenientes porque tienen un comportamiento temporal claro, el patrón es aplicable si el descubrimiento de documentos es importante: revisión legal, monitoreo del cumplimiento normativo, síntesis de investigación, triage de atención al cliente.

Stack:

• Jina v5 incrustaciones de agrupación: adaptadores específicos de Low-Rank Adaptation (LoRA) para la agrupación de temas. Jina se unió a Elastic, y sus modelos están disponibles de forma nativa a través del Elastic Inference Service (EIS).

• Elasticsearch: kNN escalable, etiquetado significant_text y almacenamiento de vectores.

• DiskBBQ: un formato de índice vectorial basado en disco que combina Better Binary Quantization (BBQ) con una partición jerárquica k-medios para la aceleración aproximada de los vecinos más cercanos (ANN). Esta partición de índice es interna a la búsqueda vectorial y separada del algoritmo de agrupación con sonda de densidad utilizado en esta publicación. bbq_disk almacena vectores cuantificados en el disco y mantiene solo los metadatos de partición en el heap, lo que reduce drásticamente los requisitos de recursos en comparación con bbq_hnsw, mientras mantiene un alto nivel de recuperación.

• Agrupación global + vinculación temporal diaria: descubrimiento y evolución del tema.

Lo que necesitarás:

• Un despliegue de Elasticsearch (Elastic Cloud, Elasticsearch Serverless o Elastic Self-Managed 8.18+/9.0+): bbq_disk requiere la versión 8.18 o posterior. La sección opcional de recuperación diversificada requiere 9.3+ o sin servidor.

• Una clave de API de Jina: la capa gratuita incluye 10 millones de tokens, lo que cubre la pipeline de agrupación del núcleo (~4.25 millones de tokens). La comparación opcional entre recuperación y agrupación usa una segunda pasada de incrustación.

• Una clave API de Guardian (gratis).

Configuración

Instala los paquetes requeridos:

Opcional (solo si ejecutas los asistentes de raspado desde este repositorio):

Luego configura las claves API en un archivo .env en la raíz del proyecto:

Este cuaderno llama a load_dotenv(override=True), por lo que los valores locales .env tienen prioridad.

Parte 1: agrupación de descubrimiento - ¿Por qué agrupar incrustaciones?

La mayoría de las búsquedas vectoriales usan incrustaciones de recuperación entrenadas para hacer coincidir una consulta con documentos relevantes. Eso es ideal para la búsqueda, pero no para el descubrimiento. Cuando quieras encontrar qué temas existen en un corpus sin ninguna consulta, necesitas incrustaciones que agrupen documentos similares.

Jina v5 resuelve esto con adaptadores de Low-Rank Adaptation (LoRA) específicos para cada tarea. LoRA agrega pequeñas actualizaciones de bajo rango a las capas internas específicas mientras mantiene la mayoría de los pesos del modelo base congelados, por lo que el comportamiento del modelo se desplaza hacia una tarea específica sin repetir el entrenamiento completo. El mismo modelo base produce diferentes incrustaciones según el parámetro task:

Tarea

Capacitado para

Caso de uso

retrieval.passage

Coincidencia búsqueda-documento

Búsqueda, Retrieval-Augmented Generation (RAG)

agrupación

Agrupación de temas (optimizada para clústeres estrechos)

Descubrimiento, categorización

El adaptador de agrupación está entrenado para hacer que los documentos sobre el mismo tema estén más cerca en el espacio de incrustaciones y que los documentos sobre temas diferentes estén más separados. La comparación visual a continuación muestra la diferencia de forma concreta.

Recuperación frente a agrupación: una comparación visual

Para ver la diferencia, se incrusta una muestra de documentos con ambos tipos de tareas. La agrupación se realiza en el espacio de incrustación original de 1024 dimensiones; Uniform Manifold Approximation and Projection (UMAP) se usa solo para proyectar esas incrustaciones en 2D para su visualización. UMAP preserva la estructura de vecindad local, por lo cual es útil para comparar la separación entre clústeres.

A continuación, se muestra la misma muestra de 480 documentos con ambos tipos de tareas y proyectada en 2D con UMAP. Busca grupos de colores más compactos y mejor diferenciados en el panel de agrupación.

Las incrustaciones de recuperación (izquierda) distribuyen los temas ampliamente; las incrustaciones de agrupación (derecha) producen grupos más ajustados y separados de los mismos documentos.

Las incrustaciones de agrupación producen grupos más compactos y visualmente más distintivos. Las incrustaciones de recuperación distribuyen los temas de manera más uniforme, ideales para la búsqueda (similitud de grano fino); pero para el descubrimiento, los clústeres temáticos compactos son lo que importa.

Esta es la razón por la que task="clustering" se usa para el resto de este recorrido.

Carga de los sets de datos

El corpus combina dos fuentes de noticias para febrero de 2025:

• BBC News a través del set de datos RealTimeData/BBC_News_AllTime HuggingFace.

• The Guardian a través de la API de Guardian Open Platform.

Tener varias fuentes permite validar que la agrupación encuentra temas en lugar de estilo específico de la fuente.

Incrustar con la tarea de agrupación

La API de Jina v5 se llama con task="clustering" para todos los documentos. Las incrustaciones se almacenan en caché en disco, por lo que las ejecuciones posteriores se saltan la API por completo.

La llamada a la API es muy sencilla. El parámetro task es la diferencia clave con respecto al uso típico de incrustación:

El tiempo que se muestra a continuación refleja un acierto de caché. La primera ejecución contra la API lleva más tiempo, según el tamaño del corpus.

Indexar un índice único de Elasticsearch

Para la agrupación por descubrimiento, el mes completo se destina a un índice (docs-clustering-all). La partición diaria se realiza más tarde para la vinculación temporal de temas.

El mapeo de índices emplea bbq_disk para el campo vectorial:

Un vector float32 de 1024 dimensiones es de 4 KB. bbq_disk usa k-medios jerárquicos para particionar vectores en pequeños clústeres, los cuantifica en binario y almacena los vectores de precisión completa en el disco para volver a guardarlos. Solo los metadatos de partición permanecen en el heap, por lo que los requisitos de memoria permanecen bajos incluso para corpus grandes. Para las cargas de trabajo que pueden permitirse más memoria dinámica, bbq_hnsw crea un grafo HNSW (Hierarchical Navigable Small World) para agilizar las búsquedas, aunque a costa de un mayor consumo de recursos.

El tipo de campo dense_vector brinda soporte para múltiples estrategias de cuantización: bbq_disk y bbq_hnsw son las más adecuadas para embeddings de alta dimensión, como los vectores de 1024 dimensiones usados aquí.

Agrupación: clasificación del centroide sondeada por densidad

Los algoritmos de agrupación tradicionales como HDBSCAN asumen que puedes mantener la matriz de vectores N × d completa en memoria y ejecutar actualizaciones de pasada completa repetidas. Para 8495 documentos con 1024 dimensiones, esto es manejable (~35 MB), pero el enfoque no escala a millones de documentos sin infraestructura adicional.

Este algoritmo es conceptualmente similar a la inicialización de KMedios++ con asignación de Voronoi y un nivel de ruido, pero emplea la búsqueda kNN de Elasticsearch como primitiva de cálculo, manteniendo casi todo el trabajo en el servidor:

1. Muestrea el 5 % de los documentos como sondas de densidad (muestra aleatoria, mínimo 50).

2. Densidad de sondas vía lotes de msearch kNN. Cada sonda dispara una búsqueda kNN y registra la similitud media de sus vecinos. Alta similitud media = región densa del espacio de incrustación. msearch envía múltiples solicitudes de búsqueda en una sola llamada HTTP, lo cual es fundamental en este caso: el sondeo de densidad genera cientos de consultas kNN, y agruparlas evita la sobrecarga por solicitud.

3. Seleccione semillas de alta densidad con diversificación: los candidatos por encima de la densidad mediana se ordenan por densidad descendente y se aceptan de manera ávida solo cuando su similitud del coseno con cada semilla existente está por debajo de un umbral de separación. Este es el único cómputo del lado del cliente (~0.01s para 8k docs).

4. Clasifica todos los documentos frente a los centroides mediante msearch kNN: cada semilla actúa como un centroide; una búsqueda kNN recupera documentos cercanos por encima de un umbral de similitud. Cada documento se asigna al centroide que lo devolvió con la puntuación más alta. Los clústeres pequeños se disuelven en ruido.

Elasticsearch se encarga del trabajo pesado: msearch para sondas de densidad, msearch para clasificación y significant_text para etiquetado. Para este corpus (8495 documentos), la muestra del 5 % de sondeo de densidad lanza 425 consultas kNN de sondeo, que msearch agrupa en nueve llamadas HTTP (con lotes de 50), lo que evita la sobrecarga de una solicitud por sondeo. Combinado con la búsqueda ANN de bbq_disk, esto mantiene la etapa de agrupación rápida y escalable. Las consultas kNN usan un valor mínimo de num_candidates para mayor velocidad durante la pasada de agrupación; las consultas de búsqueda de producción deben usar valores más altos de num_candidates para mejorar la recuperación a costa de la latencia.

Los clústeres tienen tamaños naturales determinados por la densidad del espacio de incrustación alrededor de cada centroide, no por un límite rígido de k. Las regiones temáticas densas producen clústeres más grandes; los temas de nicho producen clústeres más pequeños.

¿Por qué no KMeans o HDBSCAN?

KMedios asume clústeres esféricos y requiere la matriz N×d completa en memoria. Para corpus que caben en memoria, HDBSCAN es una alternativa estable. Maneja formas arbitrarias de clústeres y tiene una semántica de densidad bien entendida.

El enfoque de centroides con sondeo de densidad apunta a un nicho diferente: corpus con almacenamiento, recuperación y agrupación en un solo sistema, o en los que la escala hace que las operaciones matriciales del lado del cliente sean poco prácticas. Usa Elasticsearch kNN como primitiva de cómputo, maneja tamaños de clúster arbitrarios y mantiene casi todo el procesamiento del lado del servidor.

Comprender la tasa de ruido

La tasa de ruido de ~28 % es intencional, no un modo de falla. Los documentos que no encajan en ningún clúster denso en el similarity_threshold configurado quedan sin asignar en vez de ser forzados a una coincidencia deficiente. Esto actúa como un control de calidad: las columnas de opinión, los artículos cortos y las historias aisladas resisten naturalmente la acción de agrupar porque carecen de la densidad temática que define un grupo coherente.

El umbral es ajustable: reducir similarity_threshold produce una agrupación más agresiva (más documentos asignados, pero clústeres más dispersos), mientras que aumentarlo ajusta los clústeres e incrementa la fracción de ruido. Para este corpus de contenido de noticias mixtas, ~30 % de ruido es un punto de operación razonable. Los despliegues de producción deben ajustar el umbral según criterios de calidad específicos del dominio.

Etiquetas automáticas con significant_text

Ahora cada clúster necesita una etiqueta legible para humanos. La agregación significant_text de Elasticsearch encuentra términos que aparecen inusualmente a menudo en un conjunto en primer plano (el clúster) en comparación con un conjunto de fondo (el corpus completo).

En el fondo, utiliza una heurística estadística (puntuación JLH de forma predeterminada) que equilibra los cambios de frecuencia absoluta y relativa, sin machine learning, sin llamadas a modelos de lenguaje grandes (LLM). Un clúster sobre política del Reino Unido podría mostrar términos como starmer, labour, downing porque esos términos son desproporcionadamente comunes en ese clúster en comparación con el corpus de noticias general.

Para esta pasada global, las etiquetas se calculan directamente con respecto a docs-clustering-all, por lo que tanto el primer plano como el fondo se extraen del mes completo. En la parte 2, el etiquetado usa el patrón de índice diario (docs-clustering-*), un comodín que permite que las búsquedas abarquen todos los índices coincidentes simultáneamente, para darle a significant_text un fondo más amplio y lograr un mejor contraste.

Una forma mínima de consulta se ve así:

significant_text también sirve como control de calidad: los clústeres que no producen términos importantes no tienen vocabulario distintivo. Son agrupaciones incoherentes que deberían disolverse de nuevo en ruido en lugar de recibir una etiqueta engañosa.

Un paso de limpieza determinista y ligero elimina los términos de etiqueta ruidosos (tokens numéricos, palabras genéricas) y recurre a un titular representativo cuando es necesario. Esto mantiene las etiquetas nativas de Elasticsearch y, al mismo tiempo, mejora la legibilidad.

Visualizar los clústeres

Las visualizaciones a continuación muestran lo que descubrió la pasada global de agrupación: un desglose por fecha de los documentos agrupados frente a los documentos de ruido, una proyección UMAP del mes completo y un gráfico de combinación de fuentes que confirma que los clústeres reflejan temas en lugar de fuentes.

Distribución diaria de documentos agrupados frente a documentos de ruido a lo largo de febrero de 2025.

Cada isla coloreada en el UMAP representa un clúster: un grupo de artículos sobre el mismo tema descubiertos únicamente a partir de la similitud de incrustación. Los puntos de ruido gris son artículos que no encajaban perfectamente en ningún clúster (a menudo artículos cortos, artículos de opinión o historias únicas).

El gráfico de desglose de fuentes confirma que los clústeres contienen artículos de ambas BBC News y The Guardian. La agrupación está encontrando temas, no fuentes: exactamente lo que el descubrimiento no supervisado debería arrojar.

Explorar la amplitud del clúster con el recuperador diversificado

El kNN simple devuelve los documentos más similares al centroide de un clúster (el núcleo compacto). Pero los clústeres reales cubren subtemas. El recuperador diversificado utiliza Maximal Marginal Relevance (MMR) para mostrar documentos que son relevantes para el centroide pero también diferentes entre sí.

El parámetro clave es λ (lambda):

• λ = 1.0 → pura relevancia (igual que kNN simple).

• λ = 0.0 → diversidad pura (resultados de máxima distribución).

• λ = 0.5 → equilibrado: es relevante para el tema, pero cubre diferentes ángulos.

Una solicitud mínima de recuperador tiene el siguiente aspecto:

Los parámetros type, field y query_vector son necesarios a nivel de diversificación: field indica al MMR qué campo dense_vector usar para la similitud entre resultados, y query_vector proporciona el punto de referencia para el puntaje de relevancia.

Esto te permite responder: “¿Qué abarca realmente este clúster?” en vez de solo “¿Qué hay en su centro?”

Los resultados simples de kNN se agrupan en torno a un ángulo del tema: los documentos más similares al centroide y entre sí. El recuperador diversificado muestra diferentes facetas del mismo clúster: subtemas, fuentes diferentes y perspectivas variadas.

La métrica de diversidad confirma esto cuantitativamente: la similitud promedio por pares es menor en los resultados del recuperador diversificado, lo que significa que los documentos arrojados tienen mayor alcance.

Esto es útil para:

• Comprender el alcance real de un clúster: no solo su centro, sino también sus bordes.

• Generar resúmenes. Los documentos diversos y representativos le dan a un LLM mejor material.

• Encontrar ejemplos representativos para revisión humana o etiquetado posterior.

• Controles de calidad. Si los diversos resultados parecen incoherentes, es posible que el clúster deba dividirse.

Parte 2: cadenas temáticas temporales

Seguimiento de temas con el paso de los días

La parte 1 agrupó todo el mes a nivel global para el descubrimiento de temas. Para el flujo temporal, la misma clasificación de centroides con sonda de densidad se ejecuta independientemente por día en los índices diarios, y luego los clústeres se vinculan en días adyacentes. Tenga en cuenta que los clústeres diarios son independientes de los clústeres globales de la parte 1; cada día produce sus propias asignaciones y etiquetas de clúster ajustadas al contenido de ese día.

El enfoque de enlazado: muestra y consulta

Para cada clúster el día A:

1. Muestra algunos documentos representativos.

2. Ejecuta kNN contra el índice del día B.

3. Cuenta cuántas coincidencias se registran en cada clúster del día B.

4. Si la fracción de aciertos excede un umbral (fracción kNN ≥ 0.4), registra un enlace.

Esto es rápido (solo se consultan unos pocos documentos por clúster, no todos) y usa el kNN nativo de Elasticsearch, sin necesidad de herramientas externas.

Una fracción kNN del 100 % significa que cada documento muestreado del clúster de origen llegó al mismo clúster de destino, el vínculo entre días más fuerte posible. La mayoría de los vínculos anteriores están relacionados con el fútbol, lo que tiene sentido: la cobertura de la Premier League se ejecuta a diario con alta consistencia temática.

El enlace score | operator | gedling → league | striker | season es un ejemplo de un clúster de fútbol local de nicho (Gedling es un club de liga no profesional) que se integra en el clúster más amplio de la Premier League al día siguiente, una consecuencia natural de la reagrupación diaria a diferentes niveles de granularidad.

Construyendo cadenas de historias

Una cadena de temas es una secuencia de agrupaciones vinculadas en días consecutivos.

Los enlaces individuales por pares indican que el clúster "Política del Reino Unido" del lunes se conecta con el del martes. Las cadenas revelan la evolución completa: una historia que comienza el lunes, evoluciona a lo largo de la semana y se desvanece el viernes.

Las cadenas se construyen de forma voraz a partir de enlaces con una fracción kNN ≥ 0.4, lo que significa que al menos el 40 % de los documentos muestreados del clúster de origen terminaron en un único clúster de destino. Comenzando desde el clúster más antiguo, el algoritmo siempre sigue el enlace saliente más fuerte.

La cadena más larga rastrea la cobertura Ucrania-Rusia durante 19 días consecutivos, lo cual no es sorprendente dado el sostenido nivel de intensidad geopolítica en febrero de 2025. El segundo más largo sigue al fútbol de la Premier League durante 19 días del mes. Las cadenas más cortas capturan la temporada de premios (cine/premios, seis días), el rugby de las Seis Naciones (10 días) y la cobertura del liderazgo político del Reino Unido (siete días). Cada cadena representa una evolución temática que el algoritmo descubrió puramente a partir de la similitud de incrustaciones a través de índices diarios.

Sankey: visualizando el flujo de la historia

Un diagrama de Sankey es una visualización de un flujo en la que el grosor de los enlaces indica la intensidad de la conexión. Aquí, cada banda vertical es un día, cada nodo es un clúster diario (dimensionado por el recuento de documentos) y cada ruta de color traza una cadena de temas a lo largo del tiempo. El ancho del enlace codifica la fuerza de superposición de kNN: los enlaces más gruesos significan que más documentos muestreados llegaron al clúster de destino. Los colores son consistentes por cadena, así que una sola ruta de color de izquierda a derecha se lee como la progresión de un tema.

Por ejemplo, la cadena Ucrania-Rusia (que se ve como una de las rutas más largas) fluye de manera continua desde principios de febrero hasta la tercera semana, con enlaces que se mantienen gruesos, lo que indica una fuerte continuidad temática a lo largo de los días.

Cadenas temporales de temas que se desarrollan a lo largo de febrero de 2025. Cada camino coloreado es un tema que persiste a lo largo de los días; el ancho del enlace indica la fuerza de superposición kNN.

Qué ofrece este enfoque

Esta guía cubrió una pipeline completa de agrupación de documentos sin supervisión desarrollada sobre Elasticsearch:

1. Agrupar incrustaciones: los adaptadores específicos de la tarea de Jina v5 producen incrustaciones optimizadas para la agrupación por temas, no solo para la coincidencia entre consulta y documento.

2. Agrupación de descubrimiento global: agrupar el mes completo en un índice maximiza el descubrimiento de temas entre días.

3. Clasificación de centroides con densidad probada: muestrea el 5 %, sondea densidad vía msearch kNN, selecciona semillas diversas de alta densidad, clasifica todos los documentos contra los centroides. Elasticsearch maneja el cómputo pesado; solo la selección de semillas se ejecuta del lado del cliente (~0.01 s).

4. significant_text etiquetado: las pruebas de significancia producen etiquetas de clúster significativas sin ningún modelo de ML o anotación manual. Los clústeres que no producen términos significativos son incoherentes y se degradan a ruido: una barrera de calidad integrada.

5. Vinculación temporal de temas: los índices diarios y el rastreo de muestras y consultas de kNN entre índices permiten rastrear cómo evolucionan los temas a lo largo del tiempo.

Conclusiones clave:

• El tipo de tarea de incrustación es importante: las incrustaciones de agrupación producen grupos temáticos notablemente más compactos.

• Elasticsearch puede funcionar tanto como capa de almacenamiento como motor de agrupación mediante búsqueda kNN.

• La clasificación de centroides con sonda de densidad mantiene casi todos los datos del lado del servidor y produce clústeres con tamaños naturales determinados por la densidad de espacio de incrustaciones.

• significant_text es rápido, interpretable y efectivo tanto para el etiquetado automático como para el control de calidad.

Este enfoque es útil en los siguientes casos:

• Tienes texto con fecha y quieres descubrir un tema sin datos de entrenamiento etiquetados.

• Deseas una pila para almacenamiento, búsqueda de vectores, etiquetado y vinculación temporal.

Extensiones para explorar:

• Agrupación de varios períodos (resúmenes semanales y mensuales).

• Ingesta en tiempo real con asignación incremental de clúster.

• Resúmenes de clústeres generados por LLM usando los términos de significant_text como semillas.

• A mayor escala, los centroides de K-Medios obtenidos mediante muestreo pueden servir como semillas de inicio rápido para la agrupación basada en densidad, lo que reduce el costo de la fase de exploración.

Pruébalo tú mismo

Sustituye el corpus de documentos con marcas de tiempo por el tuyo; cualquier colección de texto con fechas funciona con este pipeline. El cuaderno completo y el código de soporte están disponibles en el repositorio complementario.

• Activa una prueba gratuita de Elastic Cloud: crea un clúster administrado con soporte para bbq_disk en cuestión de minutos.

• Prueba Elasticsearch Serverless: sin gestión de clústeres, escala automáticamente y brinda soporte para todo en este tutorial.

Elasticsearch rechazaba métricas que llegaban con retraso. Esos rechazos hicieron que el pipeline se retrasara, lo que dio como resultado más datos tardíos, lo que desencadenó aún más rechazos. Finalmente, el pipeline se detuvo por completo.

Tuvimos que restaurar desde un snapshot, reindexar los datos y rediseñar el pipeline de ingesta para recuperarnos.

La causa raíz no era la gestión del ciclo de vida de los índices (ILM) en sí. Eran los flujos de datos temporales (TSDS) y cómo imponen índices de respaldo acotados en el tiempo.

TSDS puede reducir las necesidades de almacenamiento para las métricas en un 40–70 %, pero los cambios de arquitectura que hacen que TSDS sea eficiente también alteran el comportamiento de los índices con el tiempo. Esos cambios importan al diseñar políticas de ILM o cuando tus Pipelines de ingesta pueden generar datos que llegan con retraso.

TL;DR

Al usar TSDS:

• Los índices de respaldo solo aceptan documentos dentro de una ventana de tiempo específica.

• Si llegan datos tardíos después de que un índice pasa a frío o congelado, Elasticsearch rechaza esos documentos o los envía al almacén de fallas, si está configurado.

Regla de diseño:

¿Qué es un flujo de datos temporales?

Un flujo de datos temporales (TSDS) es un flujo de datos especializado optimizado para datos de métricas. Los datos se distribuyen de manera que los documentos relacionados se encuentren dentro de los mismos fragmentos, lo que optimiza su búsqueda y recuperación. Así es como lo hace Elasticsearch:

Cada documento contiene:

• Una marca de tiempo.

• Campos de dimensión que identifican las series temporales.

• Campos métricos que representan valores medidos.

Entre los ejemplos, se incluyen los siguientes:

• Uso de CPU por host.

• Latencia de las solicitudes por servicio.

• Lecturas de temperatura por sensor.

Las dimensiones identifican lo que queremos medir, mientras que las métricas representan valores que cambian con el tiempo.

Dimensiones

Las dimensiones describen la entidad medida.

Ejemplos:

Los definimos en mapeos con:

Métricas

Las métricas representan valores numéricos y se definen mediante:

Tipos comunes de métricas:

• Indicador: valores que suben y bajan.

• Contador: valores que aumentan hasta que se reinician.

Elastic Agent recopila principalmente métricas y datos de logs, por lo que, incluso si no has habilitado ningún índice TSDS manualmente, puedes tenerlos aún en tu clúster.

El campo _tsid

Elasticsearch genera internamente un valor _tsid a partir de campos dimensionales. Esto permite que los documentos con dimensiones idénticas se dirijan al mismo shard, lo que mejora:

• Compresión.

• Localidad de búsqueda.

• Rendimiento de agregación.

La diferencia clave: índices de respaldo limitados en el tiempo

Los flujos de datos tradicionales siempre escriben en el índice de respaldo más reciente, llamado índice de escritura, pero TSDS se comporta de manera diferente.

Cada índice de respaldo TSDS tiene una ventana de tiempo definida y solo acepta documentos con @timestamp valores que se encuentren en esa ventana:

Cuando se indexa un documento, Elasticsearch lo dirige al índice de respaldo responsable de esa marca de tiempo, lo que significa que, a diferencia de los índices tradicionales, un TSDS puede escribir en varios índices de respaldo al mismo tiempo.

Por ejemplo:

• Datos en tiempo real → índice más reciente.

• Datos tardíos → índice anterior que abarca ese intervalo de tiempo.

Diseño para datos con retraso

Las pipelines de ingesta reales rara vez entregan métricas perfectamente a tiempo. Las métricas pueden retrasarse por interrupciones de la red, retrasos en el camino, ingesta por batch y pérdida de dispositivos periféricos, que se vuelven a conectar y comienzan a ponerse al día.

Los índices tradicionales absorben silenciosamente esos retrasos. TSDS no lo hace.

Si la marca de tiempo de un documento queda fuera del intervalo de índices de respaldo con capacidad de escritura, Elasticsearch lo rechaza, lo que significa que tu política de ILM debe tener en cuenta los datos que llegan con retraso.

La restricción crítica

Los índices de respaldo deben mantenerse con permisos de escritura el tiempo suficiente para aceptar datos tardíos.

En términos prácticos:

Debido a que ILM mide las antigüedades desde el desplazamiento, la regla operativa se convierte en:

Por ejemplo, si las métricas pueden llegar con hasta seis horas de retraso, los índices deben permanecer editables al menos seis horas después de la transferencia.

No tener en cuenta esta restricción fue exactamente lo que causó la falla de ingesta descrita anteriormente. Los datos que llegaban tarde se dirigieron a un índice anterior, que ya estaba en el nivel frío y, por tanto, bloqueaba la escritura.

Gestión de documentos rechazados

Cuando TSDS rechaza un documento, Elasticsearch devuelve un error, lo que indica que la marca de tiempo no está dentro del rango de índices de escritura. La forma en que tu pipeline de ingesta maneja ese error determina si pierdes datos o si la ingesta se detiene.

El mecanismo principal para manejar documentos rechazados es el almacén de fallas.

Almacén de fallas (recomendado en Elasticsearch 9.1+)

Elasticsearch 9.1 introdujo el almacén de fallas, que captura automáticamente los documentos rechazados. En lugar de devolver errores a los clientes, Elasticsearch escribe los documentos rechazados en un índice de fallas dedicado dentro del flujo de datos.

Puedes inspeccionar las fallas usando:

Usar el almacén de fallas evita que los pipelines de ingesta se bloqueen por errores de rechazo, a la vez que conserva los datos fallidos para analizarlos o reindexarlos.

Monitoreo de problemas de rechazo

Los problemas de retraso suelen aparecer primero como anomalías de ingesta. Puedes notarlos primero como:

• Caídas repentinas en la tasa de indexación.

• Aumentos repentinos en el número de documentos rechazados.

• Una cantidad cada vez mayor de entradas del almacén de fallas.

• Discrepancias entre el número de entradas y salidas del pipeline.

Alertar sobre estas señales permite a los operadores detectar problemas antes de que los pipelines se detengan. Se pueden utilizar flujos de trabajo, tareas de machine learning y otros mecanismos para automatizar la detección y la notificación.

Lista de verificación de migración para TSDS + ILM

Si estás migrando un cluster de métricas a TSDS, introduciendo la organización en niveles con ILM o actualizando a una versión de Elasticsearch en la que las métricas son TSDS por defecto, revisa primero estos elementos.

1. Mide la latencia de la ingesta

Antes de cambiar las políticas de ILM, determina:

• Retraso normal de ingesta.

• Retraso en el peor de los casos durante incidentes.

• Retrasos causados por pipelines de batch.

Tu diseño de ILM debe contemplar el retraso máximo realista.

2. Verifica las ventanas de tiempo de indexación

Inspecciona tus índices de respaldo TSDS:

Busca:

• time_series.start_time

• time_series.end_time

Estos límites determinan qué índices pueden aceptar documentos. Entender estas ventanas puede ayudarte a determinar cuán tarde pueden llegar los datos antes de que se rechacen.

3. Dimensiona el nivel caliente para llegadas tardías

Garantiza que los índices de respaldo permanezcan con permisos de escritura el tiempo suficiente para los datos retrasados.

Regla operativa:

• warm_min_age > rollover_max_age + maximum_expected_lateness

Recuerda, los índices deben permanecer en modo de escritura durante al menos seis horas si las métricas pueden llegar con seis horas de retraso.

4. Decide cómo manejar los documentos rechazados

Elige una estrategia antes de habilitar TSDS:

• Almacén de fallas (recomendado en Elasticsearch 9.1+).

• Cola de mensajes no procesados de Logstash.

• Índice de respaldo para retrasos.

• Aceptar la pérdida de datos limitada.

5. Monitorea el estado de la ingesta

Agrega alertas para:

• La tasa de indexación disminuye.

• Documentos rechazados.

• Crecimiento del almacén de fallas.

• Desajustes de entrada/salida en la pipeline.

Los problemas de datos tardíos a menudo aparecen primero como anomalías de ingesta.

Resumen

Los flujos de datos temporales ofrecen importantes mejoras de almacenamiento y rendimiento para las cargas de trabajo de métricas, pero introducen un cambio arquitectónico importante: los índices de respaldo están acotados en el tiempo, lo que afecta el comportamiento de ILM.

Al usar TSDS:

• Los índices deben mantenerse con permisos de escritura el tiempo suficiente para aceptar datos tardíos.

• Los pipelines de ingesta deben gestionar los documentos rechazados de forma segura.

La regla clave a recordar es:

Si diseñas políticas de ILM teniendo en cuenta esa limitación, TSDS funciona muy bien para cargas de trabajo de métricas.

Sin embargo, si lo ignoras, tu pipeline de ingesta puede descubrir esos límites de tiempo de la manera difícil.

Tu primera búsqueda

Comienza por definir un objeto CLR (POCO) simple que se mapea a tu índice de Elasticsearch. Los nombres de las propiedades se resuelven a nombres de columnas ES|QL a través de atributos System.Text.Json estándar, como [JsonPropertyName], o a través de un JsonNamingPolicy configurado. Las mismas reglas de serialización de origen que se aplican en el resto del cliente también se aplican aquí.

Con el tipo ya definido, una consulta se ve así:

El proveedor traduce esto al siguiente ES|QL:

Algunos detalles a tener en cuenta:

• Resolución de nombres de propiedades: p.Price se vuelve price_usd debido al atributo [JsonPropertyName], y p.Brand se convierte en brand siguiendo la política predeterminada de nombres camelCase.

• Captura de parámetros: Las variables C# minPrice y brand se capturan como parámetros nombrados (?minPrice, ?brand). Se envían por separado del texto de búsqueda en la carga útil JSON, lo que previene la inyección y habilita el almacenamiento en caché del plan de búsqueda del lado del servidor.

• Streaming: QueryAsync<T> devuelve IAsyncEnumerable<T>. Las filas se materializan una a la vez a medida que llegan desde Elasticsearch.

También puedes inspeccionar la búsqueda generada y sus parámetros sin ejecutarla:

¿Cómo funciona esto? Un repaso rápido de LINQ

El mecanismo que hace posibles los proveedores LINQ es la distinción entre IEnumerable<T> y IQueryable<T>.

Cuando llamas a .Where(p => p.Price > 100) en un IEnumerable<T>, la lambda se compila en un Func<Product, bool>, un delegado común que el runtime ejecuta en proceso. Esto es LINQ a objetos.

Cuando llamas al mismo método en un IQueryable<T>, el compilador de C# encapsula la expresión lambda en un Expression<Func<Product, bool>> en su lugar. Esta es una estructura de datos que representa la estructura del código en lugar de su forma ejecutable. El árbol de expresión puede inspeccionarse, analizarse y traducirse a otro idioma en tiempo de ejecución.

La interfaz IQueryProvider es el punto de extensión. Cualquier proveedor puede implementar CreateQuery<T> y Execute<T> para traducir estos árboles de expresiones a un idioma destino. Entity Framework usa esto para emitir SQL. El proveedor de LINQ a ES|QL lo usa para emitir ES|QL.

El árbol de expresión para la búsqueda anterior se ve así:

Árbol de expresiones para la búsqueda de ejemplo.

El árbol está anidado al revés: Take envuelve OrderByDescending, que envuelve Where, que envuelve From, que envuelve la constante raíz EsqlQueryable<Product>. El predicado Where es en sí mismo un subárbol de BinaryExpression nodos para los operadores &&, >= y ==, con MemberExpression hojas para accesos a propiedades y capturas de cierre para las variables minPrice y brand. Esta es la estructura de datos que el proveedor recorre para producir el ES|QL final.

En detalle: el pipeline de traducción

La ruta de una expresión LINQ a los resultados de la búsqueda sigue un pipeline de seis etapas:

Visión general del pipeline de traducción.

1. Captura del árbol de expresiones

Cuando se encadenan .Where(), .OrderBy(), .Take() y otros operadores en un IQueryable<T>, la infraestructura LINQ estándar crea un árbol de expresiones. EsqlQueryable<T> implementa IQueryable<T> y delega a EsqlQueryProvider.

2. Traducción

Cuando se ejecuta la búsqueda (al enumerar, llamar a ToList() o usar await foreach), EsqlExpressionVisitor recorre el árbol de expresiones de adentro hacia afuera. Envía cada llamada al método LINQ a un visitante especializado:

Visitante

Traduce

En

whereClauseVisitor

.Where(predicado)

Condición WHERE

SelectProjectionVisitor

.Select(selector)

EVAL + KEEP + RENAME

GroupByVisitor

.GroupBy().Select()

STATS ... BY

OrderByVisitor

.OrderBy() / .ThenBy()

Campo SORT [ASC\|DESC]

EsqlFunctionTranslator

EsqlFunctions.*, Math.*, métodos de texto

Más de 80 funciones ES|QL

Durante la traducción, las variables de C# a las que se hace referencia en las expresiones se capturan como parámetros con nombre.

3. Modelo de búsqueda

Los visitantes no producen textos directamente. En cambio, producen objetos QueryCommand, una representación intermedia inmutable. Un FromCommand, un WhereCommand, un SortCommand y un LimitCommand, cada uno representa un comando de procesamiento de ES|QL. Estos se recopilan en un modelo EsqlQuery.

Modelo de búsqueda y patrón de comandos.

Este modelo intermedio está desacoplado tanto del árbol de expresiones como del formato de salida. Se puede inspeccionar, interceptar (vía IEsqlQueryInterceptor) o modificar antes de dar formato.

4. Formato

EsqlFormatter visita cada QueryCommand en orden y produce el texto final de ES|QL. Cada comando se convierte en una línea, separada por el operador de barra vertical (|) que ES|QL usa para encadenar comandos de procesamiento. Los identificadores que contienen caracteres especiales se escapan automáticamente con comillas invertidas.

5. Ejecución

El texto ES|QL formateado y los parámetros capturados se envían al endpoint /_query de Elasticsearch como carga útil JSON. La interfaz IEsqlQueryExecutor abstrae la capa de transporte, que es donde entra en juego la arquitectura de paquetes en capas.

6. Materialización

EsqlResponseReader transmite la respuesta JSON sin almacenar en memoria todo el conjunto de resultados. Un árbol ColumnLayout, precomputado una vez por búsqueda, mapea nombres de columnas planas de ES|QL (como address.street, address.city) a propiedades anidadas de POCO. Cada fila se ensambla en una instancia T y se genera una a la vez a través de IEnumerable<T> o IAsyncEnumerable<T>.

La arquitectura en capas

La funcionalidad de LINQ a ES|QL se divide en tres paquetes:

Arquitectura de paquetes. Elastic.Esql es el motor puro de traducción. No tiene dependencias HTTP y contiene los visitantes de expresiones, el modelo de búsqueda, el formateador y el lector de respuestas. Puedes usarlo de forma independiente para crear e inspeccionar búsquedas de ES|QL sin una conexión de Elasticsearch, lo que es útil para pruebas, logging de búsquedas o para crear tu propia capa de ejecución.

Elastic.Clients.Esql es un cliente ES|QL ligero e independiente. Añade ejecución HTTP sobre Elastic.Esql a través de Elastic.Transport. Si tu aplicación solo necesita ES|QL y ninguna de las otras API de Elasticsearch, esta es la opción de dependencia mínima.

Elastic.Clients.Elasticsearch es el cliente completo de Elasticsearch .NET. También se basa en Elastic.Esql y expone al proveedor LINQ a través del espacio de nombres client.Esql. Este es el punto de entrada recomendado para la mayoría de las aplicaciones.

Ambos paquetes de capa de ejecución proporcionan su propia implementación de IEsqlQueryExecutor, la interfaz estratégica que une la traducción y el transporte.

Los tres paquetes son compatibles con Native AOT cuando se usan con un JsonSerializerContext generado por el código fuente. Para el cliente completo, consulta la documentación de Native AOT.

Mas allá de los conceptos básicos

El ejemplo anterior cubrió el filtrado, la clasificación y la paginación. El proveedor admite un conjunto más amplio de operaciones.

Agregaciones

GroupBy, combinado con funciones agregadas en Select, se traduce a ES|QL STATS ... BY:

Proyecciones

Select, con tipos anónimos genera comandos EVAL, KEEP, y RENAME:

Biblioteca de funciones enriquecida

Hay más de 80 funciones ES|QL disponibles a través de la clase EsqlFunctions, que abarcan fecha/hora, texto, matemáticas, IP, coincidencia de patrones y puntuación. También se traducen los métodos estándar Math.* y string.*:

LOOKUP JOIN

Las consultas cruzadas de índices se traducen a ES|QL LOOKUP JOIN:

Acceso directo a ES|QL sin procesar

Para las características de ES|QL que aún no están cubiertas por el proveedor de LINQ, puedes anexar fragmentos sin procesar:

Búsquedas asíncronas del lado del servidor

Para búsquedas de ejecución prolongada, envíalas para procesamiento en segundo plano en el servidor:

Las búsquedas asíncronas del lado del servidor son especialmente útiles para búsquedas analíticas de larga duración/procesamiento de grandes sets de datos que pueden superar los umbrales típicos de tiempo de espera, o en entornos sensibles al tiempo de espera con balanceadores de carga, gateways API o proxies que imponen tiempos de espera HTTP estrictos. Las búsquedas asíncronas evitan las caídas de conexión al separar el envío de la solicitud de la recuperación de los resultados.

Primeros pasos

LINQ a ES|QL está disponible a partir de:

• Elastic.Clients.Elasticsearch v9.3.4 (rama 9.x)

• Elastic.Clients.Elasticsearch v8.19.18 (rama 8.x)

Instalar desde NuGet:

dotnet add package Elastic.Clients.Elasticsearch

Los puntos de entrada están en client.Esql:

Método

Devuelve

Caso de uso

Query<T>(...)

IEnumerable<T>

Ejecución sincrónica

QueryAsync<T>(...)

IAsyncEnumerable<T>

Transmisión asíncrona

CreateQuery<T>()

IEsqlQueryable<T>

Composición e inspección avanzadas

SubmitAsyncQueryAsync<T>(...)

EsqlAsyncQuery<T>

Búsquedas de larga ejecución del lado del servidor

Para consultar la referencia completa de características, incluidas las opciones de búsqueda, el acceso a múltiples campos, los objetos anidados y el manejo de campos de valores múltiples, consulta la documentación de LINQ a ES|QL.

Conclusión

LINQ a ES|QL aporta toda la expresividad de LINQ de C# al lenguaje de búsqueda ES|QL de Elasticsearch, lo que te permite realizar búsquedas con tipado fuerte y combinables sin crear manualmente cadenas de texto. Con captura automática de parámetros, materialización de streaming y una arquitectura de paquetes en capas que escala desde el paquete de traducción autónomo hasta el cliente completo de Elasticsearch, se adapta naturalmente a aplicaciones .NET de cualquier tamaño. Instala el cliente más reciente, dirige tus expresiones LINQ a un índice y deja que el proveedor se encargue del resto.

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

1. Búsqueda aproximada (mundo pequeño jerárquico navegable [HNSW]): en lugar de examinar cada documento, construimos un grafo de navegación para saltar rápidamente al vecindario probable de la respuesta.

2. Cuantización: Comprimimos los vectores (por ejemplo, de flotantes de 32 bits a enteros de 8 bits o incluso valores binarios de 1 bit) para reducir el uso de memoria y acelerar los cálculos.

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

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

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

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

Las definiciones (para los no expertos)

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

• Relevancia versus recuperación: La relevancia es subjetiva (¿encontré cosas buenas?). La recuperación es matemática. Si hay 10 documentos en la base de datos que son las coincidencias matemáticas perfectas para tu consulta, y el motor de búsqueda encuentra nueve de ellos, tu recuperación es del 90 % (o 0,9).

• Búsqueda exacta (plana): A veces denominado el método de "fuerza bruta". El motor de búsqueda analiza cada uno de los documentos de un índice y calcula la distancia.

  • Pros: 100 % de recuperación perfecta.

  • Contras: computacionalmente caro y lento en escala.

• Búsqueda aproximada (HNSW): El método del "atajo". El motor de búsqueda crea un grafo HNSW. Recorre el grafo para encontrar a los vecinos más cercanos.

  • Ventajas: extremadamente rápido y escalable.

  • Desventajas: podrías perderte algún vecino si el recorrido del grafo se detiene demasiado pronto.

El experimento: exactitud versus aproximación

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

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

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

1. content.rawcon el tipo: flat. Esto obliga a Elasticsearch a realizar un escaneo por fuerza bruta de los vectores Float32 completos. Esto devuelve resultados de coincidencia exacta y se utilizará para nuestra línea de base.

2. contentcon tipo semantic_text. Con valores predeterminados que utilizan HNSW + la mejor cuantificación binaria (BBQ). Esta es la configuración de producción estándar y optimizada para una coincidencia aproximada.

La prueba de recall@10

Para nuestra métrica, usamos Recall@10.

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

• Si la búsqueda exacta (plana) indica que los 10 vecinos más cercanos son los ID [1, 2, 3... 10].

• Y la búsqueda aproximada (HNSW) devuelve los ID [1, 2, 3... 9, 99].

• Encontramos nueve de los 10 principales correctamente. La puntuación es 0,9.

Este es el mapeo que utilizamos:

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

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

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

Documentos

Puntuación de recall@10

1000

1000 (100 %)

5000

0,998 (100 %)

10,000

0,992 (99,4 %)

20 000

0,999 (99,0 %)

40 000

0,992 (98,8 %)

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

¿Por qué funcionó tan bien?

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

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

BBQ usa un mecanismo de recalificación:

1. Recorrido: el motor de búsqueda utiliza los vectores comprimidos (cuantificados) para recorrer rápidamente el grafo HNSW. Como los vectores son pequeños, puedes realizar un sobremuestreo de manera eficiente, recopilando una lista más amplia de candidatos (por ejemplo, los 100 documentos más parecidos) sin que afecte al rendimiento.

2. Recálculo de la puntuación: una vez que obtiene esos candidatos, recupera los valores de precisión completa solo para esos pocos documentos para calcular la clasificación final y precisa.

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

¿Podemos hacerlo mejor?

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

Conclusión

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

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

En HNSW, la búsqueda avanza expandiendo iterativamente los nodos candidatos en el grafo, lo que mantiene un conjunto acotado de vecinos más cercanos descubiertos hasta ahora. Cada expansión tiene un costo (operaciones vectoriales, búsquedas aleatorias en el disco y más), y el beneficio marginal de ese costo tiende a disminuir a medida que avanza la búsqueda.

Una forma de optimizar el recorrido de grafos de HNSW es dejar de buscar cuando la probabilidad marginal de encontrar nuevos vecinos verdaderos no aumenta. Por esta razón, en Elasticsearch 9.2, introdujimos un nuevo mecanismo de terminación temprana. Esto detiene el proceso de búsqueda cuando visitar nodos del grafo no proporciona suficientes vecinos más cercanos nuevos, consecutivamente, para un número fijo de veces.

En este artículo, te orientamos sobre cómo mejoramos el mecanismo de terminación temprana mencionado en HNSW para hacerlo más adecuado para diferentes sets de datos y distribuciones de datos.

Terminación temprana en HNSW

En HNSW, la búsqueda avanza expandiendo iterativamente nodos candidatos en el grafo de proximidad, lo que mantiene un conjunto limitado de vecinos más cercanos descubiertos hasta el momento, hasta que haya visitado todo el grafo o cumpla con algunos criterios de terminación temprana.

Por lo tanto, la terminación temprana no siempre es necesariamente una optimización, sino que es parte del algoritmo de búsqueda en sí. El momento en que decidimos detenernos determina el equilibrio entre eficiencia y recuperación. En Elasticsearch, ya hay varias formas en que una consulta en HNSW puede terminar de forma temprana:

• Se visita una cantidad máxima fija de nodos.

• Se alcanza un tiempo de espera fijo.

Si bien son simples y previsibles, estas reglas son, en gran medida, independientes de lo que realmente está haciendo la búsqueda. También se emplean, principalmente, para garantizar que la búsqueda finalice en un tiempo razonable para el usuario final.

En una entrada anterior del blog, presentamos el concepto de redundancia en HNSW. En resumen, los cálculos redundantes ocurren cuando HNSW continúa evaluando nuevos nodos candidatos que no dan como resultado la búsqueda de más vecinos más cercanos.

Paciencia: medir el progreso en lugar del esfuerzo

La noción de paciencia replantea la terminación temprana en torno al progreso, en lugar del esfuerzo.

En lugar de preguntar:

“¿Cuántos pasos hemos dado?”

La nueva pregunta es:

“¿Qué cantidad de cómputo aceptamos desperdiciar hasta que perdemos la esperanza?”

Durante la búsqueda de HNSW, por lo general, la exploración temprana produce mejoras máximas en el conjunto de candidatos top-k. Durante los primeros pasos de la exploración de grafos de HNSW, el conjunto de vecinos se actualiza continuamente a medida que el algoritmo sigue descubriendo vecinos cada vez más cercanos al vector de búsqueda. Con el tiempo, estas mejoras se vuelven más raras a medida que la búsqueda converge. La terminación basada en la paciencia monitorea este patrón y finaliza la búsqueda una vez que las mejoras han cesado durante un período prolongado.

En la práctica, al visitar el grafo de HNSW, también calculamos la relación de saturación de la cola al saltar entre nodos candidatos. Esto mide el porcentaje de vecinos más cercanos que se dejaron sin cambios al visitar el nodo del grafo más reciente (o el inverso del número de nuevos vecinos introducidos durante la última iteración). Cuando esa proporción se vuelve demasiado grande para demasiadas iteraciones consecutivas, dejamos de visitar el grafo.

Conceptualmente, la paciencia trata la búsqueda de HNSW como un proceso de rendimientos decrecientes. Cuando los rendimientos se estabilizan, seguir analizando el grafo aporta pocos beneficios.

Esta estructura es poderosa porque vincula la terminación directamente a resultados observables, en lugar de a límites fijos arbitrarios.

El beneficio de usar esta técnica inteligente de terminación temprana es que las exploraciones del grafo de HNSW tienden a visitar un número menor de nodos del grafo, mientras mantienen una recuperación relativa casi perfecta.

Para visualizar esto, podemos graficar la cantidad de recuperación por nodo visitado que obtuvimos con la terminación temprana basada en la paciencia (etiquetada como et=static), en comparación con el comportamiento predeterminado de HNSW (etiquetado como et=no) en un par de sets de datos, FinancialQA y Quora, y modelos, JinaV3 y E5-small.

Umbrales estáticos y dinámicas de HNSW

En la práctica, en Elasticsearch esto se implementa utilizando umbrales estáticos. Un umbral se refiere al umbral de saturación, es decir, la proporción de saturación que consideramos subóptima. El otro umbral se refiere al número de nodos del grafo consecutivos que permitimos que se visiten sin dejar de tener una saturación de cola subóptima: es decir, el umbral de paciencia.

Cuando introdujimos esta estrategia de terminación temprana en Elasticsearch 9.2, decidimos optar por valores predeterminados conservadores, para permitir la recuperación tanto como fuera posible, mientras se mejora la latencia y el consumo de memoria. Por esta razón, establecemos el umbral de saturación al 100 % y el umbral de paciencia se establece como un 30 % (limitado) del num_candidates en la búsqueda de KNN.

En muchas situaciones, estas configuraciones resultaron funcionar bien; sin embargo, dos búsquedas que solicitan el mismo número de vecinos podrían tener comportamientos de convergencia radicalmente diferentes. Algunas búsquedas encuentran vecindarios locales densos y se saturan rápidamente; otras deben atravesar caminos largos y dispersos antes de encontrar candidatos competitivos. Estas últimas resultaron ser las más difíciles de manejar con eficacia.

Como resultado, a veces notamos lo siguiente:

• Sobreexploración para búsquedas sencillas.

• Terminación prematura para búsquedas difíciles.

Por lo tanto, consideramos que los valores de umbral fijos codifican suposiciones globales sobre la convergencia, mientras que podríamos hacer que HNSW se adapte mejor a diferentes dinámicas.

Hacer que la terminación temprana de HNSW sea adaptativa

La terminación temprana adaptativa aborda este problema desde otro ángulo. En lugar de imponer umbrales de parada predefinidos, el algoritmo infiere cuándo detenerse de la propia dinámica de búsqueda.

Entonces, en lugar de comparar la proporción de saturación de cola entre dos candidatos consecutivos, decidimos introducir una tasa de descubrimiento suavizada instantánea (cuántos vecinos nuevos se introdujeron para una búsqueda q en la última visita i) junto con el promedio móvil y la desviación estándar de tal tasa de descubrimiento durante la visita del grafo (usando el algoritmo de Welford). Estas estadísticas sobre la tasa de descubrimiento se calculan por búsqueda, de modo que esta información pueda utilizarse para decidir diferentes grados de paciencia para cada búsqueda.

Los umbrales anteriormente estáticos se vuelven adaptativos a las estadísticas de tasa de descubrimiento: el umbral de saturación se convierte en el promedio móvil más la desviación estándar; mientras tanto, hacemos que la paciencia se adapte y escale inversamente con la desviación estándar.

Las reglas de salida anticipada siguen siendo las mismas; la saturación se produce cuando la tasa de descubrimiento instantáneo es menor que el umbral de saturación adaptativa. La visita al grafo se detiene si la saturación persiste durante un número de visitas consecutivas de candidatos que es mayor que la paciencia adaptativa.

De este modo, obtenemos un comportamiento que no depende del parámetro num_candidates en la búsqueda de KNN (que puede estar siempre establecido o dejado como predeterminado, independientemente de si sale pronto) y que se adapta mejor dinámicamente a cada consulta y distribución vectorial.

La recuperación por nodo visitado en FinancialQA y Quora con la estrategia adaptativa (etiquetada como et=adaptive) reporta una mayor recuperación por nodo visitado, en comparación con la estrategia estática (et=static) y el comportamiento predeterminado de HNSW (et=no).

La terminación temprana adaptativa está activada de manera predeterminada en Elasticsearch 9.3 para los campos vectoriales densos de HNSW (y, eventualmente, se puede desactivar a través de la misma configuración de nivel de índice).

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

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

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

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

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

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

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

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

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

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

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

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

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

• “mochila de cabina ligera”

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

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

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

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

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

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

• Opciones alternativas si hay poco inventario

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

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

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

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

Evaluación comparativa

Resultados

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

Algunas ideas clave

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

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

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

• Rendimiento: Búsquedas por segundo

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

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

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

Motor

's_n_r_value'

Recuperación

Latencia promedio (ms)

Rendimiento

Porcentaje de recuperación

Latencia Xs

Rendimiento Xs

Elasticsearch

100_250_1

0.7704

25

534.75

9.70 %

2.28

1.91

OpenSearch

100_250_1

0.7023

57.08

279.58

Elasticsearch

100_500_1

0.8577

25.42

524.14

7.20 %

2.4

2

OpenSearch

100_500_1

0.8001

60.9

262.12

Elasticsearch

100_750_1

0.8947

29.67

528.09

5.72 %

2.25

2.21

OpenSearch

100_750_1

0.8463

66.76

239.11

Elasticsearch

100_1000_1

0.9156

29.65

534.5

4.66 %

2.46

2.44

OpenSearch

100_1000_1

0.8748

72.88

219.01

Elasticsearch

100_1500_1

0.9386

31.84

497.3

3.38 %

2.71

2.68

OpenSearch

100_1500_1

0.9079

86.16

185.4

Elasticsearch

100_2000_1

0,9507

34.69

457.2

2.57 %

2.98

2.96

OpenSearch

100_2000_1

0.9269

103.36

154.55

Elasticsearch

100_2500_1

0.9582

37.9

418.43

1.99 %

3.28

3.26

OpenSearch

100_2500_1

0.9395

124.29

128.53

Elasticsearch

100_3000_1

0.9636

41.86

379.4

1.62 %

3.46

3.44

OpenSearch

100_3000_1

0.9482

144.67

110.34

Elasticsearch

100_4000_1

0.9705

50.28

316.21

1,06%

3.87

3.85

OpenSearch

100_4000_1

0.9603

194.36

82.22

Elasticsearch

100_5000_1

0.9749

58.77

270.91

0.73 %

4.43

4.41

OpenSearch

100_5000_1

0.9678

260.33

61.38

Elasticsearch

100_6000_1

0.9781

66.75

238.59

0.52 %

4.91

4.89

OpenSearch

100_6000_1

0.973

327.44

48.81

Elasticsearch

100_7000_1

0.9804

74.64

213.49

0.38 %

5.28

5.27

OpenSearch

100_7000_1

0.9767

394.24

40.53

Elasticsearch

100_8000_1

0.9823

82.28

193.59

0.27 %

6.86

6.83

OpenSearch

100_8000_1

0.9797

564.14

28.33

Elasticsearch

100_9000_1

0.9837

90.08

176.96

0.16 %

7.63

7.61

OpenSearch

100_9000_1

0.9821

687.25

23.25

Elasticsearch

100_10000_1

0.9848

97.64

163.31

0.08 %

8.38

8.36

OpenSearch

100_10000_1

0.984

818.64

19.53

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

Consulta los resultados completos.

Metodología

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

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

OpenSearch

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

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

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

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

Elasticsearch

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

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

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

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

Ejemplo

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

OpenSearch

Elasticsearch

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

La configuración del cluster

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

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

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

El set de datos

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

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

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

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

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

Conclusión

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

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

Lecturas adicionales

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

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

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

Resumen

Primero, pongámonos al día. Elasticsearch se consolidó como una poderosa base de datos vectorial, que ofrece un amplio conjunto de características y un sólido rendimiento para la búsqueda de similitudes a gran escala. Con capacidades como la cuantificación escalar, Better Binary Quantization (BBQ), operaciones vectoriales SIMD y algoritmos más eficientes en disco como DiskBBQ, ya ofrece opciones eficientes y flexibles para gestionar cargas de trabajo vectoriales.

Al integrar NVIDIA cuVS como un módulo invocable para tareas de búsqueda vectorial, nuestro objetivo es ofrecer beneficios significativos en el rendimiento y la eficiencia de la indexación vectorial para soportar mejor las cargas de trabajo vectoriales a gran escala.

El desafío

Uno de los mayores desafíos al construir una base de datos vectorial de alto rendimiento es construir el índice vectorial: el grafo HNSW. La construcción de índices se ve dominada con rapidez por millones o incluso miles de millones de operaciones aritméticas a medida que cada vector se compara con muchos otros. Además, las operaciones del ciclo de vida del índice, como la compactación y las fusiones, pueden aumentar aún más la sobrecarga total de cálculo de la indexación. A medida que los volúmenes de datos y las incrustaciones vectoriales asociadas crecen de manera exponencial, las GPU de cómputo acelerado, diseñadas para el paralelismo masivo y las matemáticas de alto rendimiento, se posicionan idealmente para manejar estas cargas de trabajo.

Ingresa al plugin Elasticsearch-GPU

NVIDIA cuVS es una biblioteca open source de CUDA-X para la búsqueda vectorial acelerada por GPU y la agrupación de datos, que permite una rápida construcción de índices y recuperación de incrustaciones para cargas de trabajo de AI y de sistemas de recomendación.

Elasticsearch utiliza cuVS a través de cuvs-java, una biblioteca open source desarrollada por la comunidad y que mantiene NVIDIA. La biblioteca cuvs-java es ligera, se basa en la API C de cuVS y usa la función externa del Proyecto Panamá para exponer las características de cuVS de una manera idiomática en Java, al tiempo que es moderna y presenta un alto rendimiento.

La biblioteca cuvs-java está integrada en un nuevo plugin de Elasticsearch; por lo tanto, la indexación vectorial en la GPU puede ocurrir en el mismo nodo y proceso de Elasticsearch, sin la necesidad de provisionar ningún código o hardware externo. Durante la construcción del índice, si se instala la biblioteca cuVS y hay una GPU presente y configurada, Elasticsearch usará la GPU para acelerar el proceso de indexación vectorial. Los vectores se asignan a la GPU, que construye un grafo CAGRA. Este grafo se convierte entonces al formato HNSW, y hace que esté disponible de inmediato para la búsqueda vectorial en la CPU. El formato final del grafo construido es el mismo que el que se construiría en la CPU; esto permite a Elasticsearch aprovechar las GPU para indexar vectores de alto rendimiento cuando el hardware subyacente lo admite, al tiempo que libera poder de la CPU para otras tareas (búsqueda simultánea, procesamiento de datos, etc.).

Aceleración en la generación de índices

Como parte de la integración de la aceleración de GPU en Elasticsearch, se realizaron varias mejoras en cuvs-java, centradas en la entrada/salida eficiente de datos y la invocación de funciones. Una mejora clave es el uso de cuVSMatrix para modelar vectores de forma transparente, ya sea que residan en la memoria heap de Java, fuera de la memoria heap o en la memoria de la GPU. Esto permite que los datos se muevan de manera eficiente entre la memoria y la GPU, lo que evita copias innecesarias de potencialmente miles de millones de vectores.

Gracias a esta abstracción subyacente de copia cero, tanto la transferencia a la memoria de la GPU como la recuperación del grafo se pueden realizar directamente. Durante la indexación, los vectores se almacenan primero en búfer en la memoria heap de Java, y luego se envían a la GPU para construir el grafo CAGRA. Después, el grafo se recupera de la GPU, se convierte al formato HNSW y se mantiene en el disco.

En el momento de la fusión, los vectores ya están almacenados en disco, sin pasar por la memoria heap de Java. Los archivos de índice se mapean en memoria, y los datos se transfieren directamente a la memoria de la GPU. El diseño también se adapta fácilmente a diferentes anchos de bits, como float32 o int8, y se extiende de forma natural a otros esquemas de cuantificación.

Redoble de tambores… entonces, ¿cómo se funciona?

Antes de entrar en los números, un poco de contexto es útil. La fusión de segmentos en Elasticsearch suele ejecutarse automáticamente en segundo plano durante la indexación, lo que dificulta hacer benchmarks de forma aislada. Para obtener resultados reproducibles, utilizamos la fusión forzosa para activar explícitamente la combinación de segmentos en un experimento controlado. Dado que la fusión forzosa hace las mismas operaciones de fusión subyacentes que la fusión en segundo plano, su rendimiento sirve como un indicador útil de las mejoras esperadas, aunque las ganancias exactas pueden diferir en las cargas de trabajo de indexación del mundo real.

Ahora, veamos los números.

Nuestros resultados iniciales de evaluaciones comparativas son muy prometedores. Ejecutamos la evaluación comparativa en una instancia de AWS g6.4xlarge con almacenamiento NVMe conectado a nivel local. Se configuró un único nodo de Elasticsearch para que use el número predeterminado y óptimo de subprocesos de indexación (8, uno por cada núcleo físico) y deshabilite la limitación de la fusión (que es menos aplicable con discos NVMe rápidos).

Para el conjunto de datos, utilizamos 2,6 millones de vectores con 1536 dimensiones del vector de pista de Rally de OpenAI, codificados como cadenas de texto base64 e indexados como float32 hnsw. En todos los escenarios, los grafos construidos alcanzan niveles de recuperación de hasta el 95 %. A continuación, presentamos nuestros hallazgos:

• Rendimiento de indexación: al trasladar la construcción de grafos a la GPU durante los vaciados de búferes en memoria, aumentamos el rendimiento en aproximadamente 12 veces.

• Fusión forzada: una vez que finaliza la indexación, la GPU continúa acelerando la fusión de segmentos, lo que acelera la fase de fusión forzada en alrededor de 7 veces.

• Uso de la CPU: descargar la construcción de grafos a la GPU reduce de manera significativa el uso promedio y máximo de la CPU. Los grafos a continuación ilustran el uso de la CPU durante la indexación y la fusión, y permiten ver cuánto menor es cuando estas operaciones se ejecutan en la GPU. Un menor uso de la CPU durante la indexación por GPU libera ciclos de CPU que pueden redirigirse para mejorar el rendimiento de la búsqueda.

• Recuperación: la precisión se mantiene prácticamente igual entre las ejecuciones de CPU y GPU, y el grafo construido por la GPU alcanza una recuperación un poco mayor.

Comparación en otra dimensión: el precio

La comparación anterior utilizaba intencionalmente hardware idéntico, y la única diferencia era si se usaba la GPU durante la indexación o no. Esa configuración es útil para aislar los efectos de la computación en bruto, pero también podemos analizar la comparación desde una perspectiva de costos.

A un precio horario similar al de la configuración acelerada por GPU, se puede provisionar una configuración de solo CPU con aproximadamente el doble de recursos comparables de CPU y memoria: 32 vCPUs (AMD EPYC) y 64 GB de RAM, lo que permite duplicar el número de hilos de indexación a 16.

Para mantener la comparación justa y consistente, ejecutamos este experimento solo de CPU en una instancia AWS g6.8xlarge, con la GPU explícitamente desactivada. Esto nos permitió mantener constantes todas las demás características del hardware mientras evaluábamos la compensación entre costo y rendimiento de la aceleración de GPU frente al indexado solo con CPU.

Como era de esperar, la instancia de CPU más potente sí muestra un mejor rendimiento en comparación con las evaluaciones comparativas de la sección anterior. Sin embargo, cuando comparamos esta instancia de CPU más potente con los resultados acelerados por GPU originales, la GPU aún ofrece beneficios sustanciales en cuanto al rendimiento: ~ 5 veces de mejora en el rendimiento de indexación y ~ 6 veces en la fusión forzada, todo ello mientras se construyen grafos que alcanzan niveles de recuperación de hasta un 95 %.

Conclusión

En escenarios completos, la aceleración por GPU con NVIDIA cuVS ofrece una mejora de casi 12 veces en el rendimiento de la indexación y una disminución de 7 veces en la latencia de fusión forzada, con un uso de CPU significativamente menor. Esto demuestra que la indexación vectorial y las cargas de trabajo de fusión se benefician de manera significativa de la aceleración por GPU. En una comparación ajustada por costos, la aceleración por GPU continúa mostrando beneficios sustanciales en cuanto al rendimiento, con alrededor de 5 veces más rendimiento de indexación y 6 veces más rapidez en las operaciones de fusión forzada.

La indexación vectorial acelerada por GPU tiene planificada hoy en día una vista previa técnica en Elasticsearch 9.3, cuyo lanzamiento está programado para principios de 2026.

Mantente atento a lo que viene.

Para lograrlo, empleamos SigLIP-2 de Google para generar incrustaciones vectoriales tanto para imágenes como para texto, y las almacenamos en la base de datos vectorial Elasticsearch. En el momento de la consulta, convertimos la entrada de búsqueda, texto o imagen, en incrustaciones y realizamos búsquedas rápidas con vectores kNN para obtener resultados. Esta configuración permite una búsqueda eficiente de texto a imagen y de imagen a imagen. Una interfaz Streamlit da vida a este proyecto proporcionándonos una interfaz no solo para hacer búsquedas por texto para encontrar y ver las fotos coincidentes del álbum, sino también para identificar la cima de la montaña a partir de la imagen subida y ver otras fotos de esa montaña en el álbum. También cubrimos los pasos que seguimos para mejorar la precisión de las búsquedas, junto con consejos y trucos prácticos. Para una exploración más profunda, proporcionamos un repositorio de GitHub y un cuaderno de Colab.

Cómo empezó todo

Esta entrada del blog fue inspirada por un niño de 10 años que me pidió que les mostrara todas las fotos del Monte Ama Dablam de mi travesía al campamento base del Everest. Mientras revisábamos el álbum de fotos, también me pidieron que identificara varias otras cumbres montañosas, algunas de las cuales no podía nombrar.

Eso me dio la idea de que esto puede ser un proyecto divertido de visión por computadora. Lo que queríamos conseguir:

• Encuentra fotos de un pico montañoso por nombre

• Adivina el nombre de la cima de la montaña a partir de una imagen y también encuentra picos similares en el álbum de fotos

• Haz que las consultas conceptuales funcionen (persona, río, banderas de oración, etc.)

Formando el equipo soñado: SigLIP-2, Elasticsearch y Streamlit

Pronto quedó claro que, para que esto funcionara, tendríamos que convertir tanto el texto ("Ama Dablam") como las imágenes (fotos de mi álbum) en vectores que puedan comparar de forma significativa, es decir, en el mismo espacio vectorial. Una vez que hacemos eso, la búsqueda es simplemente "encontrar a los vecinos más cercanos".

Para generar incrustaciones de imágenes, usamos un codificador multilingüe visión-lenguaje, de modo que una foto de una montaña y una frase como "Ama Dablam" caen en el mismo espacio vectorial.

SigLIP-2, lanzado recientemente por Google, encaja bien aquí. Puede generar incrustaciones sin entrenamiento específico de tarea (un ajuste de cero disparos ) y funciona bien para nuestro caso: fotos sin etiqueta y picos con diferentes nombres e idiomas. Como está capacitado para la coincidencia de imágenes de texto ↔, una foto de montaña de la travesía y un breve prompt de texto acaban siendo similares a incrustaciones, incluso cuando el idioma de consulta o la ortografía varían.

SigLIP-2 ofrece un fuerte equilibrio calidad-velocidad, soporta múltiples resoluciones de entrada y funciona tanto en CPU como en GPU. El SigLIP-2 está diseñado para ser más robusto para fotos exteriores en comparación con modelos anteriores como el CLIP original. Durante nuestras pruebas, SigLIP-2 generó resultados fiables de forma constante. Además, está muy bien apoyado, lo que lo convierte en la opción obvia para este proyecto.

A continuación, necesitamos una base de datos vectorial para almacenar los embebidos y la búsqueda de potencia. Debe soportar no solo búsqueda kNN coseno sobre incrustaciones de imágenes, sino también aplicar filtros de geocerca y texto en una sola consulta. Elasticsearch encaja bien aquí: maneja vectores (HNSW kNN en campos dense_vector), soporta búsqueda híbrida que combina texto, vectores y consultas geográficas, y ofrece filtrado y ordenación desde el principio. Además, escala horizontalmente, lo que facilita crecer de unas pocas fotos a miles. El cliente oficial de Python de Elasticsearch mantiene la fontanería sencilla y se integra perfectamente con el proyecto. Por último, necesitamos un frontend ligero donde podamos introducir consultas de búsqueda y ver resultados. Para una demostración rápida basada en Python, Streamlit es una opción ideal. Proporciona las primitivas que necesitamos: carga de archivos, una cuadrícula de imágenes responsiva y menús desplegables para ordenar y geovaller. Es fácil de clonar y ejecutar localmente, y también funciona en un cuaderno de Colab.

Implementación

Diseño y estrategia de indexación de Elasticsearch

Emplearemos dos índices para este proyecto: peaks_catalog y photos.

Peaks_catalog índice

Este índice sirve como un catálogo compacto de picos montañosos prominentes visibles durante la travesía al Campamento Base del Everest. Cada documento de este índice corresponde a una sola cima montañosa, como el Monte Everest. Para cada documento de pico de montaña, almacenamos nombres/alias, coordenadas opcionales de latitud-longitud y un único vector prototipo construido mediante la mezcla de prompts de texto SigLIP-2 (+ imágenes de referencia opcionales).

Mapeo indexado:

Campo

Tipo

Ejemplo

Propósito/Notas

Vector/Indexación

identificación

palabra clave

ama-dablam

Slug/id estable

—

Nombres

Subcampo texto + palabra clave

["Ama Dablam","Amadablam"]

Alias / nombres multilingües; names.raw para filtros exactos

—

Latlon

geo_point

{"lat":27.8617,"lon":86.8614}

Coordenadas GPS de pico como combinación de latitud/longitud (opcional)

—

elev_m

entero

6812

Elevación (opcional)

—

text_embed

dense_vector

768

Prototipo mezclado (prompts y, opcionalmente, 1–3 imágenes de referencia) para este pico

Index:True, Similitud:"Coseno", index_options:{type:"hnsw", m:16, ef_construction:128}

Este índice se emplea principalmente para búsquedas imagen a imagen, como identificar picos montañosos a partir de imágenes. También empleamos este índice para mejorar los resultados de búsqueda de texto a imagen.

En resumen, el peaks_catalog transforma la pregunta "¿Qué montaña es esta?" en un problema enfocado del vecino más cercano, separando efectivamente la comprensión conceptual de las complejidades de los datos de imagen.

Estrategia de indexación para el índice peaks_catalog: Comenzamos creando una lista de los picos más destacados visibles durante la travesía por el EBC. Para cada pico, almacenamos su ubicación geográfica, nombre, sinónimos y elevación en un archivo yaml. El siguiente paso es generar la incrustación de cada pico y almacenarla en text_embed campo. Para generar incrustaciones robustas, empleamos la siguiente técnica:

• Crea un prototipo de texto usando:

  • Nombres de los picos

  • Conjunto de prompts (usando varios prompts diferentes para intentar responder a la misma pregunta), por ejemplo:

    • "una foto natural de la cima de la montaña {name} en el Himalaya, Nepal"

    • "{name} pico emblemático en la región del Khumbu, paisaje alpino"

    • "{name} cima de montaña, nieve, cresta rocosa"

  • anticoncepto opcional (indicar a SigLIP-2 en qué no debe coincidir): resta un pequeño vector para "pintura, ilustración, afiche, mapa, logo" para inclinarnos hacia fotos reales.

• Opcionalmente , crea un prototipo de imagen si se proporcionan imágenes de referencia del pico.

Luego mezclamos el prototipo de texto e imagen para generar la incrustación final. Finalmente, el documento está indexado con todos los campos requeridos:

Documento de ejemplo de peaks_catalog índice:

Índice de fotos

Este índice principal almacena información detallada sobre todas las fotos del álbum. Cada documento representa una sola foto, que contiene la siguiente información:

• Camino relativo a la foto del álbum. Esto puede usar para ver la imagen correspondiente o cargarla en la interfaz de búsqueda.

• GPS e información horaria de la imagen.

• Vector denso para codificación de imágenes generado por SigLIP-2.

• predicted_peaks Eso nos permite filtrar por nombre de pico. Mapeo de índices

Campo

Tipo

Ejemplo

Propósito/Notas

Vector / Indexación

camino

palabra clave

datos/imágenes/IMG_1234.HEIC

Cómo se abre la interfaz en miniatura/imagen completa

—

clip_image

dense_vector

768

Incrustación de imágenes SigLIP-2

Index:True, Similitud:"Coseno", index_options:{type:"hnsw", m:16, ef_construction:128}

predicted_peaks

palabra clave

["ama-dablam", "pumori"]

Top-K suposiciones en el tiempo del índice (filtro UX barato / facet)

—

GPS

geo_point

{"lat":27.96,"lon":86.83}

Activa los filtros geográficos

—

shot_time

date

2023-10-18T09:41:00Z

Tiempo de captura: ordenar/filtrar

—

Estrategia de indexación para el índice de fotos: Para cada foto del álbum, hacemos lo siguiente: Extrae shot_time de imagen y gps información de los metadatos de las imágenes.

• Embedding de imagen SigLIP-2: pasar la imagen por el modelo y normalizar el vector en modo L2. Almacena el embedding en clip_image campo.

• Predecir los picos y almacenarlos en el campo predicted_peaks . Para ello, primero tomamos el vector de imagen de la foto generado en el paso anterior y luego ejecutamos una búsqueda rápida kNN en el campo text_embed en el índice de peaks_catalog . Mantenemos los 3-4 primeros picos e ignoramos el resto.

• Calculamos el campo _id haciendo un hash en el nombre y el camino de la imagen. Esto cerciora que no acabemos con duplicados tras varias partidas.

Una vez que determinamos todos los campos para la foto, los documentos fotográficos se indexan en lotes usando indexación masiva :

Documento de ejemplo del índice de fotos:

En resumen, el índice de las fotos es el almacén rápido, filtrable y listo para kNN de todas las fotos del álbum. Su mapeo es mínimo a propósito: la estructura justa para recuperar rápidamente, mostrar limpiamente y recortar los resultados por espacio y tiempo. Este índice sirve tanto para casos de búsqueda como para el uso. Aquí se puede encontrar un script en Python para crear ambos índices.

La visualización de mapas de Kibana que aparece a continuación muestra documentos del álbum de fotos como puntos verdes y picos montañosos del índice de peaks_catalog como triángulos rojos, con los puntos verdes alinear bien con el sendero de la ruta del campamento base del Everest.

Casos de uso de búsqueda

Buscar por nombre (texto a imagen): Esta función permite a los usuarios localizar fotos de picos montañosos (e incluso conceptos abstractos como "banderas de oración") mediante consultas de texto. Para lograrlo, la entrada de texto se convierte en un vector de texto usando SigLIP-2. Para una generación robusta de vectores de texto, empleamos la misma estrategia que se usa para crear incrustaciones de texto en el índice peaks_catalog : combinar la entrada de texto con un pequeño conjunto de prompts, restar un pequeño vector anti-concepto y aplicar la normalización L2 para producir el vector de consulta final. A continuación, se ejecuta una consulta kNN en el campo photos.clip_image para recuperar los picos que coinciden con la parte superior, basar en la similitud coseno para encontrar las imágenes más cercanas. Opcionalmente, los resultados de búsqueda pueden ser más relevantes aplicando filtros geográficos y de fecha, y/o un filtro de photos.predicted_peaks términos como parte de la consulta (ver ejemplos de consultas más abajo). Esto ayuda a excluir picos que se parecen y que en realidad no se ven durante la travesía.

Consulta de Elasticsearch con filtro geográfico:

Buscar por imagen (imagen a imagen): Esta función nos permite identificar una montaña en una imagen y encontrar otras imágenes de esa misma montaña dentro del álbum. Cuando se sube una imagen, el codificador de imagen SigLIP-2 la procesa para generar un vector de imagen. A continuación, se realiza una búsqueda kNN en el campo peaks_catalog.text_embed para identificar los nombres de picos que mejor coinciden. Posteriormente, se genera un vector de texto a partir de estos nombres de picos coincidentes, y se realiza otra búsqueda kNN en el índice de fotos para localizar las imágenes correspondientes.

Consulta Elasticsearch:

Paso 1: Encontrar los nombres de picos que coincidan

Paso 2: Realiza una búsqueda en el índice de photos para encontrar las imágenes coincidentes (misma consulta que se muestra en el caso de búsqueda text-to-image):

Interfaz Streamlit

Para unir todo, creamos una interfaz sencilla de Streamlit que nos permite realizar ambos casos de uso de búsqueda. El riel izquierdo muestra una lista desplazable de picos (agregados a partir de photos.predicted_peaks) con casillas de verificación y un minimapa/filtro geográfico. En la parte superior hay una caja de búsqueda por nombre y un botón de identificación por subida de fotos . El panel central presenta una cuadrícula en miniatura sensible que muestra puntajes kNN, insignias de picos predichos y tiempos de captura. Cada imagen incluye un botón para ver imagen para vistas previas en resolución completa.

Busca subiendo una imagen: Predecimos el pico y encontramos picos coincidentes del álbum de fotos.

Buscar por texto: Encuentra los picos coincidentes en el álbum a partir del texto

Conclusión

¿Qué empezó como , ¿podemos simplemente ver las imágenesde Ama Dablam? se convirtió en un pequeño sistema de búsqueda multimodal funcional. Tomamos fotos en bruto de trekking, las convertimos en incrustaciones SigLIP-2 y usamos Elasticsearch para hacer kNN rápido sobre vectores, además de filtros geo/temporales simples para mostrar las imágenes correctas por significado. En el camino, separamos las preocupaciones con dos índices: un pequeño peaks_catalog de prototipos combinados (para identificación) y un índice escalable de photos de vectores de imagen y EXIF (para recuperación). Es práctica, reproducible y fácil de ampliar.

Si quieres afinarla, hay algunos ajustes con los que puedes experimentar:

• Ajustes de tiempo de consulta: k (cuántos vecinos quieres que devuelvan) y num_candidates (qué ancho buscar antes del puntaje final). Estos ajustes se discuten en el blog aquí.

• Ajustes de tiempo de índice: m (conectividad de grafos) y ef_construction (precisión en tiempo de construcción frente a memoria). Para consultas, experimenta también con ef_search : más alto suele significar mejor recordación con cierto compromiso de latencia. Consulta este blog para más detalles sobre estos entornos.

De cara al futuro, los modelos nativos/reclasificadores para búsqueda multimodal y multilingüe pronto llegarán al ecosistema Elastic, lo que debería mejorar aún más la recuperación de imágenes/texto y el ranking híbrido desde el primer momento. ir.elastic.co+1

Si quieres probar esto tú mismo:

• Repositorio de GitHub: https://github.com/navneet83/multimodal-mountain-peak-search

• Inicio rápido de Colab: https://github.com/navneet83/multimodal-mountain-peak-search/blob/main/notebooks/multimodal_mountain_peak_search.ipynb

Con esto, nuestro viaje llegó a su fin y es hora de volar de regreso. Espero que esto te fue útil y si lo rompes (o lo mejoras), me encantaría saber qué cambiaste.

En la última parte de este serial, explicamos cómo desplegar el modelo E5 preentrenado de Elastic (así como otros modelos multilingües de incrustación de texto de Hugging Face) y nos adentramos en la generación de incrustaciones vectoriales densas a partir de tus datos textuales usando Elasticsearch y Kibana. En este blog, analizaremos los resultados de estas incrustaciones y destacaremos los beneficios significativos de aprovechar un modelo multilingüe.

Ahora que tenemos nuestro índice coco_multilingual, realizar la búsqueda nos dará documentos en varios idiomas, con el campo "en" para que podamos consultar:

Realizando una búsqueda en inglés

Intentemos hacer la búsqueda en inglés y ver qué tal va:

Aquí, aunque la consulta parezca engañosamente simple, estamos buscando las incrustaciones numéricas de la palabra 'kitty' en todos los documentos y todos los idiomas que aparecen debajo del capó. Y como realizamos búsqueda vectorial, podemos buscar semánticamente todas las palabras que puedan estar relacionadas con 'kitty': "cat", "kitten", "felino", "gatto" (italiano), "meo" (vietnamita), 고양이 (coreano), 猫 (chino), etc. Como resultado, aunque mi consulta esté en inglés, también podemos buscar contenido en todos los demás idiomas. Por ejemplo, buscar un gatitoying on something también devuelve documentos en italiano, neerlandés o vietnamita. ¡Eso sí que es eficiencia!

Realizar una búsqueda de contenido en otros idiomas

De manera similar, realizar una búsqueda por palabra clave de "cat" en coreano ("고양이") también devolverá resultados significativos. Lo espectacular aquí es que ni siquiera tenemos documentos en coreano en este índice.

Esto funciona porque el modelo de incrustación representa el significado en un espacio semántico compartido, permitiendo la recuperación de imágenes relevantes incluso con una consulta en un idioma diferente al de los subtítulos indexados.

Aumento de resultados de búsqueda relevantes con búsqueda híbrida y reposicionamiento

Estamos contentos de que los resultados relevantes llegaron como se esperaba. Pero, en el mundo real, por ejemplo en comercio electrónico o en aplicaciones RAG que necesitan reducir a los 5-10 resultados más aplicables, podemos usar un modelo de reclasificación para priorizar los resultados más relevantes.

Aquí, realizar una consulta que pregunte "¿de qué color es el gato?" en vietnamita dará muchos resultados, pero el top 1 o 2 puede no ser el más relevante.

Todos los resultados mencionan gato, o algún tipo de color:

¡Así que vamos a mejorar eso! Integremos el modelo multilingüe de reclasificación de Coherepara mejorar el razonamiento correspondiente a nuestra pregunta.

Ahora, con los mejores resultados, nuestra solicitud puede responder con confianza que el color del gatito es negro o marrón con rayas. Lo que resulta aún más interesante aquí es que nuestra búsqueda vectorial detectó una omisión en el pie de foto en inglés del conjunto de datos original. Es capaz de encontrar al gato de rayas marrones aunque la traducción de referencia al inglés no mencionó ese detalle. Este es el poder de la búsqueda vectorial.

Conclusión

En este blog, explicamos la utilidad de un modelo de incrustación multilingüe y cómo aprovechar Elasticsearch para integrar los modelos y generar embeddings, y mejorar eficazmente la relevancia y la precisión mediante una búsqueda híbrida y un reclasificador. Puedes crear tu propio clúster en la nube para probar la búsqueda semántica multilingüe usando nuestro modelo E5 estándar en el idioma y conjunto de datos que elijas.

En un mundo de usuarios globales, la recuperación de información multilingüe (CLIR) es fundamental. En lugar de limitar las búsquedas a un solo idioma, CLIR te permite encontrar información en cualquier idioma, mejorando la experiencia del usuario y agilizando las operaciones. Imagina un mercado global donde los clientes de comercio electrónico puedan buscar artículos en su idioma, y los resultados adecuados aparezcan, sin necesidad de localizar los datos de antemano. O bien, donde los investigadores académicos pueden buscar artículos en su lengua materna, con matices y complejidad, incluso si la fuente está en otro idioma.

Los modelos de incrustación de texto multilingüe nos permiten hacer precisamente eso. Las incrustaciones son una forma de representar el significado del texto como vectores numéricos. Estos vectores están diseñados para que textos con significados similares estén situados cerca unos de otros en un espacio de alta dimensión. Los modelos de incrustación de texto multilingüe están diseñados específicamente para mapear palabras y frases con el mismo significado entre diferentes idiomas en un espacio vectorial similar.

Modelos como el Multilingüe E5 de código abierto se capacitan con enormes cantidades de datos textuales, a menudo empleando técnicas como el aprendizaje contrastivo. En este enfoque, el modelo aprende a distinguir entre pares de textos con significados similares (pares positivos) y aquellos con significados diferentes (pares negativos). El modelo se capacita para ajustar los vectores que produce de modo que se maximice la similitud entre pares positivos y se minimice la similitud entre pares negativos. Para modelos multilingües, estos datos de entrenamiento incluyen pares de texto en diferentes idiomas que son traducciones entre sí, permitiendo al modelo aprender un espacio de representación compartido para múltiples idiomas. Las incrustaciones resultantes pueden usar para diversas tareas de PLN, incluyendo la búsqueda cross-lingual, donde la similitud entre incrustaciones de texto se emplea para encontrar documentos relevantes independientemente del idioma de la consulta.

Beneficios de la búsqueda vectorial multilingüe

• Matiz: La búsqueda vectorial destaca en captar el significado semántico, yendo más allá de la simple búsqueda de palabras clave. Esto es crucial para tareas que requieren comprender el contexto y las sutilezas del lenguaje.

• Comprensión interlingüe: Permite una recuperación efectiva de información entre idiomas, incluso cuando la consulta y los documentos emplean vocabulario diferente.

• Relevancia: Ofrece resultados más relevantes centrar en la similitud conceptual entre consultas y documentos.

Por ejemplo, consideremos a un investigador académico que estudia el "impacto de las redes sociales en el discurso político" en diferentes países. Con la búsqueda vectorial, pueden introducir consultas como "l'impacto dei social media sul discorso politico" (italiano) o "ảnh hưởng của mạng xã hội đối với diễn ngôn chính trị" (vietnamita) y encontrar artículos relevantes en inglés, español o cualquier otro idioma indexado. Esto se debe a que la búsqueda vectorial identifica artículos que discuten el concepto de influencia de las redes sociales en la política, no solo aquellos que contienen las palabras clave exactas. Esto mejora enormemente la amplitud y profundidad de su investigación.

Primeros pasos

Así es como configurar CLIR usando Elasticsearch, con el modelo E5 que se proporciona de fábrica. Emplearemos el conjunto de datos multilingüe de código abierto COCO, que contiene pies de foto en varios idiomas, para ayudarnos a visualizar dos tipos de búsquedas:

1. Consultas y términos de búsqueda en otros idiomas en un conjunto de datos en inglés, y

2. Consultas en varios idiomas sobre un conjunto de datos que contiene documentos en varios idiomas.

Luego, aprovecharemos el poder de la búsqueda híbrida y el reposicionamiento para mejorar aún más los resultados de búsqueda.

Prerrequisitos

• Python 3.6+

• Elasticsearch 8+

• Cliente Python de Elasticsearch: instalación de pip elasticsearch

Conjunto de datos

El conjunto de datos COCO es un conjunto de datos de subtitulado a gran escala. Cada imagen del conjunto de datos está subtitulada en varios idiomas diferentes, con varias traducciones disponibles por idioma. Para fines demostrativos, indexaremos cada traducción como un documento individual, junto con la primera traducción al inglés disponible para referencia.

Paso 1: descargar el conjunto de datos multilingüe COCO

Para simplificar el blog y facilitar el seguimiento, aquí estamos cargando las primeras 100 filas de Restval en un archivo JSON local con una llamada API sencilla. Alternativamente, puedes usar los conjuntos de datos de la biblioteca de HuggingFace para cargar el conjunto de datos completo o subconjuntos del conjunto.

Si los datos se cargan correctamente en un archivo JSON, deberías ver algo similar a lo siguiente:

Data successfully downloaded and saved to multilingual_coco_sample.json

Paso 2: (Iniciar Elasticsearch) e indexar los datos en Elasticsearch

a) Inicia tu servidor local de Elasticsearch.

b) Iniciar el cliente Elasticsearch.

c) Datos de índice

Una vez indexados los datos, deberías ver algo similar a lo siguiente:

Successfully bulk indexed 4840 documents

Indexing complete!

Paso 3: Desplegar el modelo capacitado con E5

En Kibana, accede a la página de Stack Management > Trained Models y haz clic en Desplegar para el .multilingual-e5-small_linux-x86_64 opción. Este modelo E5 es un pequeño multilingüe optimizado para linux-x86_64, que podemos usar de fábrica. Al hacer clic en 'Desplegar' aparecerá una pantalla donde puedes ajustar la configuración de despliegue o las configuraciones de los vCPU. Para simplificar, optaremos por las opciones predeterminadas, con recursos adaptativos seleccionados, que escalarán automáticamente nuestro despliegue según el uso.

Opcionalmente, si quieres usar otros modelos de incrustación de texto, puedes hacerlo. Por ejemplo, para usar el BGE-M3, puedes usar el cliente Eland Python de Elastic para importar el modelo desde HuggingFace.

Luego, ve a la página de Modelos Capacitados para desplegar el modelo importado con las configuraciones deseadas.

Paso 4: Vectorizar o crear incrustaciones para los datos originales con el modelo desplegado

Para crear los embeddings, primero necesitamos crear un pipeline de ingesta que nos permita tomar el texto y pasarlo por el modelo de embedding de texto de inferencia. Puedes hacerlo en la interfaz de usuario de Kibana o a través de la API de Elasticsearch.

Para hacerlo a través de la interfaz Kibana, tras desplegar el Modelo Capacitado, haz clic en el botón Test . Esto te dará la posibilidad de probar y previsualizar los embeddings generados. Crea una nueva vista de datos para elíndice de coco, configura la vista de datos en la vista de datos coco recién creada y pon el campo en description porque ese es el campo para el que queremos generar incrustaciones.

¡Eso funciona genial! Ahora podemos proceder a crear la pipeline de ingest, reindexar nuestros documentos originales, pasarlos por la pipeline y crear un nuevo índice con los embeddings. Puedes conseguirlo haciendo clic en Crear pipeline, lo que te guiará durante el proceso de creación de pipeline, con procesadores auto-repoblados necesarios para ayudarte a crear los embeddings.

El asistente también puede rellenar automáticamente los procesadores necesarios para gestionar fallos mientras se ingieren y procesan los datos.

Ahora creemos la canalización de ingest. Voy a nombrar el oleoducto coco_e5. Una vez que la tubería se crea correctamente, puedes usarla inmediatamente para generar las incrustaciones reindexando los datos originales indexados a un nuevo índice en el asistente. Haz clic en Reindexar para iniciar el proceso.

Para configuraciones más complejas, podemos usar la API de Elasticsearch.

Para algunos modelos, debido a la forma en que se capacitaron, puede que necesitemos anteponer o agregar ciertos textos a la entrada real antes de generar los embeddings; de lo contrario, veremos una degradación del rendimiento.

Por ejemplo, con el e5, el modelo espera que el texto de entrada siga a "passage: {content of passage}". Empleemos los pipelines de ingest para lograrlo: crearemos un nuevo pipeline de ingest vectorize_descriptions. En esta canalización, crearemos un nuevo campo de temp_desc temporal, antepondremos "passage: " al texto description , pasaremos temp_desc por el modelo para generar incrustaciones de texto y luego eliminaremos el temp_desc.

Además, podríamos querer especificar qué tipo de cuantización queremos usar para el vector generado. Por defecto, Elasticsearch usa int8_hnsw, pero aquí quiero Better Binary Quantization (o bqq_hnsw), que reduce cada dimensión a una precisión de un solo bit. Esto reduce la huella de memoria en un 96% (o 32 veces) a un costo mayor en la precisión. Opto por este tipo de cuantización porque sé que usaré un reclasificador más adelante para mejorar la pérdida de precisión.

Para ello, crearemos un nuevo índice llamado coco_multi y especificaremos los mapeos. La magia aquí está en el campo vector_description, donde especificamos que el tipo del index_optionsdebe ser bbq_hnsw.

Ahora, podemos reindexar los documentos originales a un nuevo índice, con nuestra pipeline de ingesta que "vectorizará" o creará incrustaciones para el campo de descripciones.

¡Y eso es todo! Desplegamos con éxito un modelo multilingüe con Elasticsearch y Kibana y aprendido paso a paso cómo crear las incrustaciones vectoriales con tus datos con Elastic, ya sea a través de la interfaz de usuario de Kibana o con la API de Elasticsearch. En la segunda parte de este serial, exploraremos los resultados y las particularidades del uso de un modelo multilingüe. Mientras tanto, puedes crear tu propio clúster en la nube para probar la búsqueda semántica multilingüe usando nuestro modelo E5 estándar en el idioma y conjunto de datos que elijas.

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!

En este artículo, discutiremos estos tipos de campos, cuándo usar cada uno y cómo se relacionan con la generación y las estrategias de uso de incrustaciones, tanto durante la indexación como durante la consulta.

Tipo vectorial denso

El tipo de campo dense_vector en Elasticsearch se emplea para almacenar vectores densos, que son representaciones numéricas de datos como texto, imágenes y audio, donde casi todas las dimensiones son relevantes. Estos vectores se generan empleando modelos de incrustación proporcionados por plataformas como OpenAI, Cohere o Hugging Face, y están diseñados para captar el significado semántico general de los datos, incluso cuando no comparten términos exactos con otros documentos.

En Elasticsearch, los vectores densos pueden tener hasta 4096 dimensiones dependiendo del modelo empleado. Por ejemplo, el modelo totalmente MiniLM-L6-v2 genera vectores con 384 dimensiones, mientras que el text-embedding-ada-002 de OpenAI produce vectores con 1536 dimensiones.

El campo dense_vector se adopta comúnmente como el tipo predeterminado para almacenar este tipo de incrustación cuando se necesita mayor control, como usando vectores pregenerados, aplicando funciones de similitud personalizadas o integrando con modelos externos.

¿Cuándo y por qué usar dense_vector tipo?

Los vectores densos son excelentes para capturar similitudes semánticas entre oraciones, párrafos o documentos completos. Funcionan muy bien cuando el objetivo es comparar el significado general de los textos, aunque no compartan los mismos términos.

El campo vectorial denso es ideal cuando ya tienes una pipeline externa de generación de embedding usando modelos proporcionados por plataformas como OpenAI, Cohere o Hugging Face y solo quieres almacenar y consultar estos vectores manualmente. Este tipo de campo ofrece alta compatibilidad con modelos de incrustación y total flexibilidad en la generación y consulta, permitiéndote controlar cómo se producen, indexan y emplean los vectores durante la búsqueda.

Además, soporta diferentes formas de búsqueda semántica, con consultas como k-NN o script_score para casos en los que sea necesario ajustar la lógica de clasificación. Estas posibilidades hacen que el vector denso sea ideal para aplicaciones como RAG (Generación Aumentada por Recuperación), sistemas de recomendación y búsquedas personalizadas basadas en similitudes.

Por último, el campo te permite personalizar la lógica de relevancia, usando funciones como cosineSimilarity, dotProduct o l2norm para adaptar la clasificación según las necesidades de tu caso de uso.

Los vectores densos siguen siendo la mejor opción para quienes necesitan flexibilidad, personalización y compatibilidad con casos de uso avanzados como los mencionados anteriormente.

¿Cómo usar la consulta para el tipo de vector denso?

Las búsquedas en campos definidos como dense_vector emplean la consulta k-vecinos más cercanos. Esta consulta es responsable de encontrar documentos cuyo vector denso está más cercano al vector de consulta. A continuación se muestra un ejemplo de cómo aplicar una consulta k-NN a un campo vectorial denso:

Además de la consulta k-NN, si es necesario personalizar el puntaje del documento, también es posible usar la consulta script_score, combinándola con funciones de comparación vectorial como cosenoSimilitud, Producto PuntoPunto o l2norm para calcular la relevancia de forma más controlada. Mira el ejemplo:

Si quieres profundizar más, te recomiendo explorar el artículo Cómo configurar la búsqueda vectorial en Elasticsearch.

Tipo vectorial disperso

El tipo de campo sparse_vector se emplea para almacenar vectores dispersos, que son representaciones numéricas donde la mayoría de los valores son cero y solo unos pocos términos tienen pesos significativos. Este tipo de vector es común en modelos basados en términos como SPLADE o ELSER (Elastic Learned Sparse EncodeR).

¿Cuándo y por qué usar tipo vectorial disperso?

Los vectores dispersos son ideales cuando se necesita una búsqueda más precisa en términos léxicos, sin sacrificar la inteligencia semántica. Representan el texto como pares token/valor, resaltando solo los términos más relevantes con pesos asociados, lo que proporciona claridad, control y eficiencia.

Este tipo de campo es especialmente útil cuando se generan vectores basados en términos, como en los modelos ELSER o SPLADE, que asignan diferentes pesos a cada token según su importancia relativa en el texto.

Para las ocasiones en las que quieres controlar la influencia de palabras específicas en la consulta, los tipos vectoriales dispersos te permiten ajustar manualmente el peso de los términos para optimizar el orden de los resultados.

Entre los principales beneficios están la transparencia en la búsqueda, ya que es posible entender claramente por qué un documento se consideraba relevante, y la eficiencia de almacenamiento, ya que solo se almacenan los tokens con valor distinto de cero, a diferencia de los vectores densos que almacenan todas las dimensiones.

Además, los vectores dispersos son el complemento ideal en estrategias de búsqueda híbrida, e incluso pueden combinar con vectores densos para combinar precisión léxica con comprensión semántica.

¿Cómo usar la consulta para el tipo de vector disperso?

La consulta sparse_vector te permite buscar documentos basándote en un vector de consulta en formato token/valor. Consulta un ejemplo de la consulta a continuación:

Si prefieres usar un modelo capacitado, es posible emplear un punto final de inferencia que transforme automáticamente el texto de consulta en un vector disperso:

Para profundizar en este tema, sugiero leer Understanding sparse vector embeddings with trained ML models.

Tipo de texto semántico

El tipo de campo semantic_text es la forma más sencilla y directa de usar la búsqueda semántica en Elasticsearch. Gestiona automáticamente la generación de incrustaciones, tanto en tiempo de indexación como en tiempo de consulta, a través de un punto final de inferencia. Esto significa que no tienes que preocuparte por generar o almacenar vectores manualmente.

¿Cuándo y por qué usar texto semántico?

El campo semantic_text es ideal para quienes quieren empezar con el mínimo esfuerzo técnico y sin tener que manejar vectores manualmente. Este campo automatiza pasos como la generación de incrustaciones y el mapeo de búsqueda vectorial, haciendo que la configuración sea más rápida y cómoda.

Deberías considerar usar semantic_text cuando valoras la simplicidad y la abstracción, ya que elimina la complejidad de configurar manualmente mapeos, generación de incrustaciones y pipelines de ingestión. Solo tienes que seleccionar el modelo de inferencia, y Elasticsearch se encarga del resto.

Los principales beneficios incluyen la generación automática de incrustaciones, realizada tanto durante la indexación como durante la consulta, y el mapeo listo para usar, que viene preconfigurado para soportar el modelo de inferencia seleccionado.

Además, el campo ofrece soporte nativo para la división automática de textos largos (fragmentación de texto), permitiendo dividir textos grandes en pasajes más pequeños, cada uno con su propia incrustación, lo que mejora la precisión en la búsqueda. Esto aumenta enormemente la productividad, especialmente para equipos que quieren ofrecer valor rápidamente sin tener que lidiar con la ingeniería subyacente de la búsqueda semántica.

Sin embargo, aunque semantic_text proporciona rapidez y simplicidad, este enfoque tiene algunas limitaciones. Permite el uso de modelos estándar de mercado, siempre que estén disponibles como puntos finales de inferencia en Elasticsearch. Pero no soporta incrustaciones generadas externamente, como es posible con el campo dense_vector .

Si necesitas más control sobre cómo se generan los vectores, quieres usar tus propios embeddings o necesitas combinar varios campos para estrategias avanzadas, los campos dense_vector y sparse_vector ofrecen la flexibilidad necesaria para escenarios más personalizados o específicos de dominio.

Cómo usar la consulta para el tipo de texto semántico

Antes de semantic_text, era necesario usar una consulta diferente según el tipo de incrustación (densa o dispersa). Se empleaba una consulta sparse_vector para campos dispersos, mientras que dense_vector campos requerían consultas KNN.

Con el tipo de texto semántico, la búsqueda se realiza usando la consulta semántica, que genera automáticamente el vector de consulta y lo compara con las incrustaciones de los documentos indexados. El tipo semantic_text permite definir un extremo de inferencia para incrustar la consulta, pero si no se especifica ninguno, se aplicará el mismo punto final que se usa durante la indexación a la consulta.

Para saber más, te sugiero leer el artículo Elasticsearch nueva semantic_text mapeo: Simplificando la búsqueda semántica.

Conclusión

Al elegir cómo mapear incrustaciones en Elasticsearch, es esencial entender cómo quieres generar los vectores y qué nivel de control necesitas sobre ellos. Si buscas simplicidad, el campo de texto semántico permite una búsqueda semántica automática y escalable, lo que lo hace ideal para muchos casos de uso iniciales. Cuando se requiere más control, un rendimiento ajustado o integración con modelos personalizados, los campos vectoriales densos y dispersos proporcionan la flexibilidad necesaria.

El tipo de campo ideal depende de tu caso de uso, la infraestructura disponible y la madurez de tu pila de aprendizaje automático. Lo más importante es que Elastic ofrece las herramientas para construir sistemas de búsqueda modernos y altamente adaptables.

Referencias

• Tipo de campo de texto semántico

• Tipo de campo vectorial disperso

• Tipo de campo vectorial denso

• Consulta semántica

• Consulta vectorial dispersa

• Búsqueda kNN

• Mapeado de nuevas semantic_text de Elasticsearch: Simplificación de la búsqueda semántica

• Comprendiendo las incrustaciones de vectores dispersos con modelos de aprendizaje automático capacitados

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

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

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

Hay algunas cosas a tener en cuenta:

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

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

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

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

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

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

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

¿Qué necesitas para empezar?

Para comenzar, necesitará lo siguiente:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Números aproximados en las relaciones de compresión

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

Vectores (V)

Dimensiones (D)

sin procesar (V x P x 4)

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

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

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

10,000,000

384

14,31 GB

3,61 GB

1,83 GB

0,58 GB

50,000,000

384

71,53 GB

18,07 GB

9,13 GB

2,89 GB

100,000,000

384

143,05 GB

36,14 GB

18,25 GB

5,77 GB

Conclusión

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

Aprendizaje adicional

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

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

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

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

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

Enfrentamiento de cuantificación binaria

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

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

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

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

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

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

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

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

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

Metodología

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

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

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

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

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

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

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

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

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

Recall@10

• 10-40-40

• 10-50-50

• 10-100-100

• 10-200-200

• 10-500-500

• 10-750-750

• 10-1000-1000

• 10-1500-1500

• 10-2000-2000

Recall@50

• 50-150-150

• 50-200-200

• 50-250-250

• 50-500-500

• 50-750-750

• 50-1000-1000

• 50-1200-1200

• 50-1500-1500

• 50-2000-2000

Recall@100

• 100-200-200

• 100-250-250

• 100-300-300

• 100-500-500

• 100-750-750

• 100-1000-1000

• 100-1200-1200

• 100-1500-1500

• 100-2000-2000

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

Configuración de OpenSearch Rally

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

Configuración del índice de Opensearch

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

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

Configuración de Elasticsearch Rally

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

Configuración del índice de Elasticsearch

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

Resultados

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

Recuperación @ 10 - simplificado

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

Retiro @ 10 - Detallado

tarea

latencia.media

rendimiento.mean

avg_recall

Elasticsearch-9.0-BBQ

10-100-100

11.70

513.58

0.89

Elasticsearch-9.0-BBQ

10-1000-100

27.33

250.55

0.95

Elasticsearch-9.0-BBQ

10-1500-1500

35.93

197.26

0.95

Elasticsearch-9.0-BBQ

10-200-200

13.33

456.16

0.92

Elasticsearch-9.0-BBQ

10-2000-2000

44.27

161.40

0.95

Elasticsearch-9.0-BBQ

10-40-40

10.97

539.94

0.84

Elasticsearch-9.0-BBQ

10-50-50

11.00

535.73

0.85

Elasticsearch-9.0-BBQ

10-500-500

19.52

341.45

0.93

Elasticsearch-9.0-BBQ

10-750-750

22.94

295.19

0.94

OpenSearch-2.19-faiss

10-100-100

35.59

200.61

0.94

OpenSearch-2.19-faiss

10-1000-1000

156.81

58.30

0.96

OpenSearch-2.19-faiss

10-1500-1500

181.79

42.97

0.96

OpenSearch-2.19-faiss

10-200-200

47.91

155.16

0.95

OpenSearch-2.19-faiss

10-2000-2000

232.14

31.84

0.96

OpenSearch-2.19-faiss

10-40-40

27.55

249.25

0.92

OpenSearch-2.19-faiss

10-50-50

28.78

245.14

0.92

OpenSearch-2.19-faiss

10-500-500

79.44

97.06

0.96

OpenSearch-2.19-faiss

10-750-750

104.19

75.49

0.96

Recuperación @ 50 - simplificado

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

Resultados detallados - Recall @ 50

Tarea

Latencia media

Media de rendimiento

Retiro promedio

Elasticsearch-9.0-BBQ

50-1000-1000

25.71

246.44

0.95

Elasticsearch-9.0-BBQ

50-1200-1200

28.81

227.85

0.95

Elasticsearch-9.0-BBQ

50-150-150

13.43

362.90

0.90

Elasticsearch-9.0-BBQ

50-1500-1500

33.38

202.37

0.95

Elasticsearch-9.0-BBQ

50-200-200

12.99

406.30

0.91

Elasticsearch-9.0-BBQ

50-2000-2000

42.63

163.68

0.95

Elasticsearch-9.0-BBQ

50-250-250

14.41

373.21

0.92

Elasticsearch-9.0-BBQ

50-500-500

17.15

341.04

0.93

Elasticsearch-9.0-BBQ

50-750-750

31.25

248.60

0.94

OpenSearch-2.19-faiss

50-1000-1000

125.35

62.53

0.96

OpenSearch-2.19-faiss

50-1200-1200

143.87

54.75

0.96

OpenSearch-2.19-faiss

50-150-150

43.64

130.01

0.89

OpenSearch-2.19-faiss

50-1500-1500

169.45

46.35

0.96

OpenSearch-2.19-faiss

50-200-200

48.05

156.07

0.91

OpenSearch-2.19-faiss

50-2000-2000

216.73

36.38

0.96

OpenSearch-2.19-faiss

50-250-250

53.52

142.44

0.93

OpenSearch-2.19-faiss

50-500-500

78.98

97.82

0.95

OpenSearch-2.19-faiss

50-750-750

103.20

75.86

0.96

Retiro @ 100

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

Resultados detallados - Recall @ 100

tarea

latencia.media

rendimiento.mean

avg_recall

Elasticsearch-9.0-BBQ

100-1000-1000

27.82

243.22

0.95

Elasticsearch-9.0-BBQ

100-1200-1200

31.14

224.04

0.95

Elasticsearch-9.0-BBQ

100-1500-1500

35.98

193.99

0.95

Elasticsearch-9.0-BBQ

100-200-200

14.18

403.86

0.88

Elasticsearch-9.0-BBQ

100-2000-2000

45.36

159.88

0.95

Elasticsearch-9.0-BBQ

100-250-250

14.77

433.06

0.90

Elasticsearch-9.0-BBQ

100-300-300

14.61

375.54

0.91

Elasticsearch-9.0-BBQ

100-500-500

18.88

340.37

0.93

Elasticsearch-9.0-BBQ

100-750-750

23.59

285.79

0.94

OpenSearch-2.19-faiss

100-1000-1000

142.90

58.48

0.95

OpenSearch-2.19-faiss

100-1200-1200

153.03

51.04

0.95

OpenSearch-2.19-faiss

100-1500-1500

181.79

43.20

0.96

OpenSearch-2.19-faiss

100-200-200

50.94

131.62

0.83

OpenSearch-2.19-faiss

100-2000-2000

232.53

33.67

0.96

OpenSearch-2.19-faiss

100-250-250

57.08

131.23

0.87

OpenSearch-2.19-faiss

100-300-300

62.76

120.10

0.89

OpenSearch-2.19-faiss

100-500-500

84.36

91.54

0.93

OpenSearch-2.19-faiss

100-750-750

111.33

69.95

0.94

Mejoras en el asado

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

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

Conclusión

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

Los hallazgos clave incluyen:

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

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

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

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

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

Los desarrolladores ahora pueden crear sus aplicaciones RAG dentro de un viaje unificado, basando sus experiencias de chat en sus datos privados de una forma flexible y low-code. Ya sea que estés construyendo agentes de IA para tus clientes y empleados internos o aprovechando la generación de LLMs dentro de tu software, la plataforma Vertex AI pone la relevancia de Elasticsearch al alcance de tus dedos con una configuración mínima. Esta integración permite una adopción más fácil y rápida de los modelos Gemini en casos de uso de producción, impulsando la GenAI de PoCs a escenarios reales.

En este blog, te guiaremos a través de la integración de Elasticsearch con la plataforma Vertex AI de Google Cloud para una base de datos fluida y la creación de aplicaciones GenAI totalmente personalizables. Descubramos cómo.

Los modelos Vertex AI y Gemini de Google Cloud están basados en tus datos con Elasticsearch

Los usuarios que aprovechan los servicios y herramientas de Vertex AI para crear aplicaciones GenAI ahora pueden acceder a la nueva opción "Grounding" para incorporar sus datos privados a su interacción conversacional automáticamente. Elasticsearch ahora es parte de esta característica y se puede usar a través de:

• API de Vertex AI LLM, que enriquecen directamente los modelos Gemini de Google en el momento de la generación (preferido);

• Grounded Generation, que se usa en su lugar en el ecosistema de Vertex AI Agent Builder para crear experiencias agenciales.

Con esta integración, Elasticsearch, la base de datos vectorial más descargada e implementada, llevará tus datos empresariales relevantes donde sea necesario en tus chats internos de cara al cliente final, lo cual es crucial para la adopción de GenAI en los procesos de negocio en la vida real.

Las API mencionadas permitirán a los desarrolladores adoptar esta nueva característica asociada en su código. Sin embargo, la ingeniería y las pruebas rápidas siguen siendo pasos cruciales en el desarrollo de aplicaciones y sirven como un campo de descubrimiento inicial. Para respaldar esto, Elasticsearch está diseñado para que los usuarios puedan evaluarlo fácilmente dentro de la herramienta de consola Vertex AI Studio.

Todo lo que se necesita son unos simples pasos para configurar los puntos finales de Elastic con los parámetros deseados (índice a buscar, la cantidad de documentos a recuperar y la plantilla de búsqueda deseada) dentro de la pestaña "Personalizar conexión a tierra" en la interfaz de usuario, como se muestra a continuación (tenga en cuenta que para que funcione, debe escribir la clave API con la palabra "ApiKey" en la interfaz de usuario y los ejemplos de código a continuación). ¡Ahora estás listo para generar con tu conocimiento privado!

Aplicaciones GenAI listas para producción con facilidad

Elastic y Google Cloud trabajan para proporcionar experiencias integrales, agradables y que priorizan a los desarrolladores. La conexión a Elastic de forma nativa tanto en LLM como en la API de generación de conexión a tierra reduce la complejidad y la sobrecarga al crear aplicaciones GAI en Vertex AI, lo que evita API adicionales innecesarias y la orquestación de datos mientras se basa en una sola llamada unificada.

Veamos cómo funciona en ambos escenarios.

El primer ejemplo se ejecuta con la API de LLM:

En el ejemplo anterior, con el campo retrieval de la API que aplicar la generación de contenido a Gemini 2.0 Flash, podemos configurar contextualmente un motor de recuperación para la solicitud. Establecer api_spec en "ELASTIC_SEARCH" permite el uso de parámetros de configuración adicionales, como la clave de API y el punto de enlace del clúster (necesarios para enrutar una solicitud a tu clúster de Elastic), el índice del que recuperar datos y la plantilla de búsqueda que se empleará para tu lógica de búsqueda.

Del mismo modo, se podría lograr el mismo resultado con la API de generación de puesta a tierra, estableciendo el parámetro groundingSpec :

Con ambos enfoques, la respuesta proporcionará una respuesta con los documentos privados más relevantes que se encuentran en Elasticsearch, y las fuentes de datos conectadas relacionadas, para respaldar tu consulta.

Sin embargo, la simplicidad no debe confundir con la falta de personalización para satisfacer sus necesidades y casos de uso específicos. Con esto en mente, lo diseñamos para permitirle adaptar perfectamente la configuración de búsqueda a su escenario.

Búsqueda totalmente personalizable al alcance de tu mano: plantillas de búsqueda

Para proporcionar la máxima personalización a tu escenario de búsqueda, creamos, en colaboración con Google Cloud, la experiencia sobre nuestras conocidas plantillas de búsqueda. Las plantillas de búsqueda de Elasticsearch son una excelente herramienta para crear consultas de búsqueda dinámicas, reutilizables y mantenibles. Permiten predefinir y reutilizar estructuras de consulta. Son particularmente útiles cuando se ejecutan consultas similares con diferentes parámetros, ya que ahorran tiempo de desarrollo y reducen la posibilidad de errores. Las plantillas pueden incluir marcadores de posición para variables, lo que hace que las consultas sean dinámicas y adaptables a diferentes requisitos de búsqueda.

Al usar las API de Vertex AI y Elasticsearch para la conexión a tierra, debes hacer referencia a una plantilla de búsqueda deseada, como se muestra en los fragmentos de código anteriores, donde se implementa la lógica de búsqueda y se envía a Elasticsearch. Los usuarios avanzados de Elastic pueden gestionar, configurar y actualizar de forma asíncrona los enfoques de búsqueda y adaptarlos a los índices, modelos y datos específicos de una manera totalmente transparente para los usuarios de Vertex AI, los desarrolladores de aplicaciones sitio web o los ingenieros de IA, que solo necesitan especificar el nombre de la plantilla en la API de fundamentación.

Este diseño permite una personalización completa, poniendo a tu disposición las amplias funciones de recuperación de Elasticsearch en un entorno de IA de Google Cloud, al tiempo que garantiza la modularidad, la transparencia y la facilidad de uso para diferentes desarrolladores, incluso aquellos que no están familiarizados con Elastic.

Siempre que necesite la búsqueda BM25, la búsqueda semántica o un enfoque híbrido entre los dos (¿Ya exploró los retrievers ? Técnicas de recuperación componibles en una sola llamada a la API de búsqueda), puedes definir tu lógica personalizada en una plantilla de búsqueda, que Vertex AI puede aprovechar automáticamente.

Esto también se aplica a las incrustaciones y reclasificaciones de modelos que elija para gestionar vectores y resultados. Según tu caso de uso, es posible que desees alojar modelos en los nodos de ML de Elastic, usar un endpoint de servicio de terceros a través de la API de inferencia o ejecutar tu modelo local en las instalaciones. Esto se puede hacer a través de una plantilla de búsqueda, y veremos cómo funciona en la siguiente sección.

Comience con plantillas de referencia y luego cree las suyas propias

Para ayudarlo a empezar rápidamente, proporcionamos un conjunto de ejemplos de plantillas de búsqueda compatibles que se emplearán como referencia inicial; Luego puede modificar y construir sus personalizados sobre:

• Búsqueda semántica con modelo ELSER (vectores dispersos y fragmentación)

• Búsqueda semántica con modelo multilingüe e5 (vectores densos y fragmentación)

• Búsqueda híbrida con modelo de incrustación de texto Vertex AI

Puede encontrarlos en este repositorio de GitHub.

Veamos un ejemplo: crear incrustaciones con las API de IA de Vertex de Google Cloud en un catálogo de productos. Primero, necesitamos crear la plantilla de búsqueda en Elasticsearch como se muestra a continuación:

En este ejemplo, ejecutaremos la búsqueda KNN en dos campos dentro de una sola búsqueda: title_embedding – el campo vectorial que contiene el nombre del producto – y description_embedding – el que contiene la representación de su descripción.

Puede aprovechar la sintaxis excludes para evitar devolver campos innecesarios al LLM, lo que puede causar ruido en su procesamiento y afectar la calidad de la respuesta final. En nuestro ejemplo, excluimos los campos que contienen vectores y url de imágenes.

Los vectores se crean sobre la marcha en el momento de la consulta en la entrada enviada a través de un extremo de inferencia a la API de incrustaciones de Vertex AI, googlevertexai_embeddings_004, definida anteriormente de la siguiente manera:

Puedes encontrar información adicional sobre cómo usar la API de inferencia de Elastic aquí.

Ahora estamos listos para probar nuestra búsqueda con plantillas:

Los campos params reemplazarán las variables que establezcamos en los scripts de plantilla entre corchetes dobles. Actualmente, las API de Vertex AI LLM y Grounded Generation pueden enviar a Elastic las siguientes variables de entrada:

• "query" - la consulta del usuario que se va a buscar

• "index_name" - el nombre del índice donde buscar

• "num_hits": cuántos documentos queremos recuperar en la salida final

Aquí hay un ejemplo de salida:

La consulta anterior es precisamente lo que Vertex AI de Google Cloud ejecutará en Elasticsearch en segundo plano cuando se refiera a la plantilla de búsqueda creada anteriormente. Los modelos de Gemini usarán los documentos de salida para fundamentar su respuesta: cuando pregunte "¿Qué necesito para parchear mi panel de yeso?" en lugar de recibir una sugerencia genérica, ¡el agente de chat le proporcionará productos específicos!

Viaje de GenAI de extremo a extremo con Elastic y Google Cloud

Elastic se asocia con Google Cloud para crear experiencias y soluciones GenAI integrales y listas para la producción. Como acabamos de ver, Elastic es el primer ISV que se integra directamente en la interfaz de usuario y el SDK para la plataforma Vertex AI, lo que permite que los modelos de Gemini sean precisos y fundamentados con indicaciones y agentes que emplean nuestras funciones de búsqueda vectorial. Además, Elastic se integra con Vertex AI y los modelos de inserción, reclasificación y finalización de Google AI Studiopara crear y clasificar vectores sin salir del panorama de Google Cloud, lo que garantiza los principios de IA responsable . Al admitir enfoques multimodales, facilitamos conjuntamente las aplicaciones en diversos formatos de datos.

Puedes ajustar, probar y exportar tu código de búsqueda de GenAI a través de nuestro Playground.

Pero no se trata solo de crear aplicaciones de búsqueda: Elastic aprovecha los modelos de Gemini para potenciar las operaciones de TI, como en las funciones Elastic AI Assistants, Attack Discovery y Automatic Import, lo que reduce la fatiga diaria de los analistas de seguridad y los SRE en tareas de bajo valor y les permite concentrar en mejorar su negocio. Elastic también permite un monitoreo integral del uso de Vertex AI, el seguimiento de métricas y logs, como tiempos de respuesta, tokens y recursos, para garantizar un rendimiento óptimo. Juntos, gestionamos todo el ciclo de vida de GenAI, desde la ingesta de datos y la generación de incrustaciones hasta la conexión a tierra con búsqueda híbrida, al tiempo que garantizamos una estable observabilidad y seguridad de las herramientas de GenAI con acciones impulsadas por LLM.

¡Explora más y pruébalo!

¿Estás interesado en probar esto? ¡La función está actualmente disponible con disponibilidad general en tus proyectos de Google Cloud!

Si aún no lo hiciste, una de las formas más fáciles de comenzar a usar Elastic Search AI Platform y explorar nuestras capacidades es con tu prueba gratis de Elastic Cloud o suscribiéndote a través de Google Cloud Marketplace.

El lanzamiento y el momento de cualquier característica o funcionalidad descrita en esta publicación quedan a discreción exclusiva de Elastic. Es posible que cualquier característica o funcionalidad que no esté disponible actualmente no se entregue a tiempo o no se entregue en absoluto. Elastic, Elasticsearch y las marcas asociadas son marcas comerciales, logotipos o marcas comerciales registradas de Elasticsearch N.V. en los Estados Unidos y otros países. Todos los demás nombres de empresas y productos son marcas comerciales, logotipos o marcas comerciales registradas de sus respectivos propietarios.

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.

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.

Como parte de nuestra misión de no dejar atrás la eficiencia, estamos explorando oportunidades de aceleramiento con estos curiosos chips de computadora, de los que quizás oíste hablar: ¡las GPU NVIDIA! (En serio, ¿no es así?).

Cuando nos obsesionamos con el rendimiento, tenemos varios espacios problemáticos para explorar: cómo indexar exponencialmente más datos, cómo recuperar información de ellos y cómo hacerlo cuando sus modelos de ML están involucrados. Debería poder obtener hasta el último beneficio disponible cuando tenga GPU.

En esta publicación, nos sumergimos en nuestra colaboración con el equipo de búsqueda vectorial de NVIDIA mientras exploramos la búsqueda vectorial acelerada por GPU en Elasticsearch. Este trabajo allana el camino para casos de uso en los que los desarrolladores podrían usar una combinación de GPU y CPU para aplicaciones con tecnología de Elasticsearch del mundo real. ¡Tiempos emocionantes!

GPU de Elasticsearch

Nos complace compartir que el equipo de ingeniería de Elasticsearch está ayudando a crear la experiencia de la API de Java cuVS de código abierto para desarrolladores, que expone enlaces para algoritmos de búsqueda vectorial. Este trabajo aprovecha nuestra experiencia previa con Panama FFI. Elasticsearch y Apache Lucene emplean la API NVIDIA cuVS para crear el gráfico durante la indexación. Bien, estamos saltando hacia adelante; Rebobinemos un poco.

NVIDIA cuVS, una biblioteca de C++ de código abierto, está en el corazón de esta colaboración. Su objetivo es llevar el aceleramiento de GPU a la búsqueda vectorial al proporcionar un mayor rendimiento, menor latencia y tiempos de compilación de índices más rápidos. Pero Elasticsearch y Apache Lucene están escritos en Java; ¿Cómo funcionará esto?

Ingrese lucene-cuvs y la colaboración Elastic-NVIDIA-SearchScale para llevarlo al ecosistema de Lucene para explorar la búsqueda vectorial acelerada por GPU en Elasticsearch. En la reciente versión 25.02 de NVIDIA cuVS, agregamos una API de Java para cuVS. La nueva API es experimental y seguirá evolucionando, pero actualmente está disponible para su uso. Puede surgir la pregunta: ¿no son lentas las llamadas de Java a funciones nativas? ¡Ya no! Estamos usando la nueva FFI (interfaz de funciones externas) de Panamá para los enlaces, que tiene una sobrecarga mínima para Java a las llamadas descendentes nativas.

Estuvimos usando Panama FFI en Elasticsearch y Lucene desde hace un tiempo. ¡Es asombroso! Pero... Siempre hay un "pero", ¿no? FFI tiene desafíos de disponibilidad en todas las versiones de Java. Superamos esto compilando la API de cuVS en Java 21 y encapsulando la implementación dentro de un jar de varias versiones dirigido a Java 22. Esto permite el uso de cuVS Java directamente en Lucene y Elasticsearch.

Ok, ahora que tenemos la API de Java de cuVS, ¿qué más necesitaríamos?

Una historia de dos algoritmos para CPU

Elasticsearch admite el algoritmo HNSW para una búsqueda KNN aproximada escalable. Sin embargo, para sacar el máximo provecho de la GPU, empleamos un algoritmo diferente, CAGRA [CUDA ANN GRAph], que fue diseñado específicamente para los altos niveles de paralelismo que ofrece la GPU.

Antes de entrar en cómo buscamos agregar soporte para CAGRA, veamos cómo Elasticsearch y Lucene acceden a los datos del índice a través de un "formato de códec". Consiste en

1. la representación en disco,

2. las interfaces para leer y escribir datos,

3. y la maquinaria para lidiar con la arquitectura basada en segmentos de Lucene.

Estamos implementando un nuevo formato vectorial KNN (k-vecinos más cercanos) que emplea internamente la API de Java de cuVS para indexar y buscar en la GPU. A partir de aquí, "sondeamos" este tipo de códec a través de las asignaciones de Elasticsearch a un tipo de campo en el índice. Como resultado, las consultas KNN existentes siguen funcionando independientemente de si el índice de respaldo emplea un gráfico CAGRA o HNSW. Por supuesto, esto pasa por alto muchos detalles, que planeamos cubrir en un blog futuro. La siguiente es la arquitectura de alto nivel para un Elasticsearch acelerado por GPU.

Este nuevo formato de códec tiene como valor predeterminado CAGRA. Sin embargo, también admite la conversión de un gráfico CAGRA en un gráfico HNSW para la búsqueda en la CPU.

Indexación y búsqueda en la GPU: Tomar algunas decisiones "básicas"

Con la arquitectura sin estado de Elasticsearch Serverless, que separa la indexación y la búsqueda, ahora hay una clara delimitación de responsabilidades. Elegimos el mejor perfil de hardware para cumplir con cada una de estas responsabilidades independientes.

Anticipamos que los usuarios considerarán dos estrategias de implementación principales:

1. Indexación y búsqueda en la GPU: durante la indexación, cree un gráfico CAGRA y empléelo durante la búsqueda, ideal cuando se requiere una búsqueda de latencia extremadamente baja.

2. Indexar en GPU y buscar en CPU: durante la indexación, cree un gráfico CAGRA y conviértalo en un gráfico HNSW. El gráfico HNSW se almacena en el índice, que luego se puede usar en la CPU para la búsqueda.

Esta flexibilidad proporciona diferentes modelos de implementación, ofreciendo compensaciones entre costo y rendimiento. Por ejemplo, un servicio de indexación podría usar GPU para compilar y combinar gráficos de manera eficiente de manera oportuna mientras usa una CPU de menor potencia para la búsqueda.

Así que aquí está el plan para la búsqueda vectorial acelerada por GPU en Elasticsearch

Esperamos brindar ganancias de rendimiento y flexibilidad con estrategias de implementación a los usuarios, ofreciendo varias perillas para equilibrar el costo y el rendimiento. Aquí está la sesión de NVIDIA GTC 2025 donde se presentó este trabajo en detalle.

Nos gustaría agradecer a los equipos de ingeniería de NVIDIA y SearchScale por su fantástica colaboración. En un próximo blog, exploraremos los detalles de implementación y el análisis de rendimiento con mayor profundidad. ¡Agárrate a tus sombreros de 🎩 curiosidad!

Esta primera parte se centra en ofrecer una introducción general a los conceptos básicos de incrustación de vectores y cómo funciona la búsqueda vectorial en el interior.

Armado con todo el conocimiento aprendido en el primer artículo, la segunda parte te guiará por los ménsilos de cómo configurar la búsqueda vectorial en Elasticsearch.

En la tercera parte, aprovecharemos lo que aprendimos en las dos primeras partes, construiremos sobre ese conocimiento y profundizaremos en cómo crear poderosas consultas híbridas de búsqueda en Elasticsearch.

Antes de adentrarnos en el asunto real de este artículo, volvamos atrás en el tiempo y repasemos parte de la historia de los vectores, que es un concepto clave en la búsqueda semántica.

Los vectores no son nuevos

Estoy bastante seguro de que todo el mundo estaría de acuerdo en que desde la llegada de ChatGPT en noviembre de 2022, no pasa ni un solo día sin oír o leer sobre la "búsqueda vectorial". Está en todas partes y es tan común que a menudo tenemos la impresión de que es una tecnología de vanguardia que acaba de salir, ¡pero la verdad es que esta tecnología lleva más de seis décadas en el mercado! La investigación sobre el tema comenzó a mediados de los años 60, y los primeros artículos científicos se publicaron en 1978 por Gerard Salton, un experto en recuperación de información, y sus colegas de la Universidad de Cornell. El trabajo de Salton sobre modelos vectoriales densos y dispersos constituye la raíz de la tecnología moderna de búsqueda vectorial.

En los últimos 20 años, se crearon y llevado al mercado muchos SGBD vectoriales diferentes basados en su investigación. Entre ellos se encuentra Elasticsearch, impulsado por el proyecto Apache Lucene, que comenzó a trabajar en búsqueda vectorial en 2019.

Los vectores están ahora en todas partes y son tan omnipresentes que es importante primero comprender bien su teoría subyacente y su funcionamiento interno antes de experimentar con ellos. Antes de profundizar en eso, repasemos rápidamente las diferencias entre la búsqueda léxica y la búsqueda vectorial para entender mejor cómo difieren y cómo pueden complementar entre sí.

Búsqueda vectorial vs. búsqueda léxica

Una forma sencilla de introducir la búsqueda vectorial es comparándola con la búsqueda léxica más convencional a la que probablemente estés acostumbrado. La búsqueda vectorial, también conocida comúnmente como búsqueda semántica, y la búsqueda léxica funcionan de forma muy diferente. La búsqueda léxica es el tipo de búsqueda que todos estuvimos usando durante años en Elasticsearch. Resumiéndolo muy brevemente, no intenta entender el verdadero significado de lo que se indexa y consulta, sino que hace un gran esfuerzo por hacer coincidir léxicamente los literales de las palabras o variantes de ellas (piensa en stemming, sinónimos, etc.) que el usuario escribe en una consulta con todos los literales que fueron indexados previamente en la base de datos usando algoritmos de similitud, como la TF-IDF

Como podemos ver, los tres documentos de la esquina superior izquierda están tokenizados y analizados. Luego, los términos resultantes se indexan en un índice invertido, que simplemente mapea los términos analizados a los IDs de los documentos que los contienen. Ten en cuenta que todos los términos solo están presentes una vez y ninguno es compartido por ningún documento. Buscar "buen profesor de alemán" hará coincidir los tres documentos con puntajes variables, aunque ninguno capte realmente el significado real de la consulta.

Como se puede ver en la Figura 2, más abajo, se complica aún más cuando se trata de polisemia u homógrafos, es decir, palabras que se escriben igual pero tienen significados diferentes (derecha, palma, murciélago, media, etc.) Tomemos la palabra "correcto", que puede significar tres cosas diferentes, y veamos qué ocurre.

Buscar "I'm not right" devuelve un documento que tiene el significado exactamente opuesto al resultado original. Si buscas exactamente los mismos términos pero los ordenas de forma diferente para producir un significado distinto, por ejemplo, "voltea a la derecha" y "giro a la derecha", obtienes el mismo resultado exacto (es decir, el tercer documento "Toma un giro a la derecha"). Es cierto que nuestras consultas son excesivamente simplificadas y no emplean consultas más avanzadas como la comparación de frases, pero esto ayuda a ilustrar que la búsqueda léxica no entiende el verdadero significado detrás de lo que se indexa y lo que se busca. Si no queda claro, no te preocupes, retomaremos este ejemplo en el tercer artículo para ver cómo la búsqueda vectorial puede ayudar en este caso.

Para hacer justicia a la búsqueda léxica, cuando tienes control sobre cómo indexas tus datos estructurados (piensa en mapeos, análisis de texto, pipelines de ingest, etc.) y cómo elaboras tus consultas (piensa en consultas DSL ingeniosamente diseñadas, análisis de términos de consulta, etc.), puedes hacer maravillas con motores de búsqueda léxicos, ¡no hay duda! El historial de Elasticsearch en cuanto a sus capacidades de búsqueda léxica es simplemente asombroso. Lo que logró y cuánto popularizó y mejorado el campo de la búsqueda léxica en los últimos años es realmente notable.

Sin embargo, cuando se te encarga proporcionar soporte para consultar datos no estructurados (piensa en imágenes, videos, audios, texto en bruto, etc.) a usuarios que necesitan hacer preguntas de texto libre, la búsqueda léxica no funciona. Además, a veces la consulta ni siquiera es texto, podría ser una imagen, como veremos en breve. La principal razón por la que la búsqueda léxica es inadecuada en estas situaciones es que los datos no estructurados no pueden ni indexar ni consultar de la misma manera que los datos estructurados. Cuando se trata de datos no estructurados, entra en juego la semántica . ¿Qué significa la semántica? Muy simplemente, ¡el significado!

Tomemos el ejemplo sencillo de un motor de búsqueda de imágenes (por ejemplo, Google Image Search o Lens). Arrastras y soltas una imagen, y el motor de búsqueda semántica de Google encontrará y devolverá las imágenes más similares a la que consultaste. En la Figura 3, a continuación, podemos ver a la izquierda la imagen de un pastor alemán y a la derecha todas las imágenes similares que se recuperaron, siendo el primer resultado la misma imagen que la proporcionada (es decir, la más parecida).

Aunque esto parezca simple y lógico para nosotros, para las computadoras es otra historia completamente distinta. Eso es lo que permite y ayuda a lograr la búsqueda vectorial. El poder desbloqueado por la búsqueda vectorial es enorme, como el mundo presenció recientemente. Ahora levantemos la capucha y descubramos qué se esconde debajo.

Vectores de incrustación

Como vimos antes, con los motores de búsqueda léxicos, los datos estructurados como el texto pueden tokenizarse fácilmente en términos que pueden coincidir en el momento de la búsqueda, independientemente del significado real de los términos. Sin embargo, los datos no estructurados pueden adoptar diferentes formas, como grandes objetos binarios (imágenes, videos, audios, etc.), y no son en absoluto adecuados para el mismo proceso de tokenización. Además, el propósito principal de la búsqueda semántica es indexar los datos de tal manera que puedan buscar según el significado que representan. ¿Cómo lo logramos? La respuesta está en dos palabras: ¡Aprendizaje Automático! ¡O más concretamente, Aprendizaje Profundo!

El aprendizaje profundo es un área específica del aprendizaje automático que se basa en modelos basados en redes neuronales artificiales compuestas por múltiples capas de procesamiento que pueden extraer progresivamente el verdadero significado de los datos. La forma en que funcionan esos modelos de redes neuronales está fuertemente inspirada en el cerebro humano. La figura 4, a continuación, muestra cómo es una red neuronal, con sus capas de entrada y salida, así como múltiples capas ocultas:

La verdadera hazaña de las redes neuronales es que son capaces de convertir un solo dato no estructurado en una secuencia de valores de punto flotante, conocidos como vectores de incrustación o simplemente incrustaciones. Como seres humanos, podemos entender bastante bien qué son los vectores siempre que los visualizemos en un espacio bidimensional o tridimensional. Cada componente del vector representa una coordenada en un plano x-y 2D o en un espacio 3D x-y-z.

Sin embargo, los vectores de incrustación sobre los que trabajan los modelos de redes neuronales pueden tener varios cientos o incluso miles de dimensiones y simplemente representar un punto en un espacio multidimensional. Cada dimensión vectorial representa una característica, o una característica, de los datos no estructurados. Ilustremos esto con un modelo de aprendizaje profundo que convierte imágenes en vectores de incrustación de 2048 dimensiones. Ese modelo convertiría la imagen del pastor alemán que usamos en la Figura 3 en el vector de incrustación mostrado en la tabla siguiente. Ten en cuenta que solo mostramos el primer y último tres elementos, pero habría 2.042 columnas/dimensiones más en la tabla.

is_red

is_dog

blue_sky

…

no_gras

german_shepherd

is_tree

Pastor alemán Incrustaciones

0.0121

0.9572

0.8735

…

0.1198

0.9712

0.0512

Cada columna es una dimensión del modelo y representa una característica, o característica, que la red neuronal subyacente busca modelar. Cada entrada dada al modelo se caracterizará dependiendo de lo similar que sea esa entrada a cada una de las 2048 dimensiones. Por tanto, el valor de cada elemento en el vector de incrustación denota la similitud de esa entrada con una dimensión específica. En este ejemplo, podemos ver que el modelo detectó una alta similitud entre perros y pastores alemanes, así como la presencia de algo de cielo azul.

A diferencia de la búsqueda léxica, donde un término puede ser emparejado o no, con la búsqueda vectorial podemos obtener una idea mucho mejor de cuán similar es un dato no estructurado a cada una de las dimensiones soportadas por el modelo. Por tanto, los vectores de incrustación sirven como una representación semántica fantástica de los datos no estructurados.

La salsa secreta

Ahora que sabemos cómo los datos no estructurados son segmentados y fragmentados por redes neuronales de aprendizaje profundo en vectores de incrustación que capturan la similitud de los datos a lo largo de un gran número de dimensiones, necesitamos entender cómo funciona la coincidencia de esos vectores. Resulta que la respuesta es bastante sencilla. Los vectores de incrustación que están cerca entre sí representan piezas de datos semánticamente similares . Así que, cuando consultamos una base de datos vectorial, la entrada de búsqueda (imagen, texto, etc.) se convierte primero en un vector de incrustación usando el mismo modelo que se usó para indexar todos los datos no estructurados, y el objetivo final es encontrar los vectores vecinos más cercanos a ese vector de consulta. Por tanto, solo tenemos que averiguar cómo medir la "distancia" o "similitud" entre el vector de consulta y todos los vectores existentes indexados en la base de datos, y eso es básicamente todo.

Distancia y similitud

Por suerte para nosotros, medir la distancia entre dos vectores es un problema fácil de resolver gracias a la aritmética vectorial. Así que, veamos las funciones de distancia y similitud más populares que soportan las bases de datos modernas de búsqueda vectorial, como Elasticsearch. ¡Aviso, matemáticas adelante!

Distancia L1

La distancia L1, también llamada distancia de Manhattan, de dos vectores x e y se mide sumando la diferencia absoluta por pares de todos sus elementos. Obviamente, cuanto menor es la distancia d, más cerca están los dos vectores. La fórmula es bastante sencilla, como se puede ver a continuación:

Visualmente, la distancia L1 puede ilustrar como se muestra en la Figura 5, a continuación:

Tomemos dos vectores x e y, como x = (1, 2) y y = (4, 3), entonces la distancia L1 de ambos vectores sería | 1 - 4 | + | 2 - 3 | = 4.

Distancia L2

La distancia L2, también llamada distancia euclidiana, de dos vectores x e y se mide primero sumando el cuadrado de la diferencia de pares de todos sus elementos y luego tomando la raíz cuadrada del resultado. Básicamente es el camino más corto entre dos puntos (también llamado hipotenusa). De forma similar a L1, cuanto menor sea la distancia d, más cerca estarán los dos vectores:

La distancia L2 se muestra en la Figura 6 a continuación:

Reutilicemos los mismos dos vectores de muestra x e y que usamos para la distancia L1, y ahora podemos calcular la distancia L2 como . Tomando la raíz cuadrada de 10, obtendría 3,16.

Distancia de Linf

La distancia de Linf (por L infinito), también llamada distancia de Chebyshev o distancia del tablero de ajedrez, de dos vectores x e y se define simplemente como la distancia más larga entre dos de sus elementos o la distancia más larga medida a lo largo de uno de los ejes/dimensiones. La fórmula es muy sencilla y se muestra a continuación:

Una representación de la distancia Linf se muestra en la Figura 7 a continuación:

De nuevo, tomando los mismos dos vectores muestrales x e y, podemos calcular la distancia infinita L como max ( | 1 - 4 | , | 2 - 3 | ) = max (3, 1) = 3.

Similitud coseno

A diferencia de L1, L2 y Linf, la similitud coseno no mide la distancia entre dos vectores x e y, sino su ángulo relativo, es decir, si ambos apuntan aproximadamente en la misma dirección. Cuanto mayor sea la similitud s, más "cerca" están los dos vectores. La fórmula es de nuevo muy sencilla y se muestra a continuación:

Una forma de representar la similitud coseno entre dos vectores se muestra en la Figura 8 a continuación:

Además, como los valores del coseno siempre están en el intervalo [-1, 1], -1 significa similitud opuesta (es decir, un ángulo de 180° entre ambos vectores), 0 significa similitud no relacionada (es decir, un ángulo de 90°) y 1 significa idéntico (es decir, un ángulo 0°), como se muestra en la Figura 9 más abajo:

Una vez más, reutilicemos los mismos vectores muestrales x e y calculemos la similitud coseno usando la fórmula anterior. Primero, podemos calcular el producto escalar de ambos vectores como . Luego, multiplicamos la longitud (también llamada magnitud) de ambos vectores: Finalmente, dividimos el producto escalar por la longitud multiplicada 10 / 11,18034 = 0,894427 (es decir, un ángulo de 26°), que es bastante cercano a 1, por lo que ambos vectores pueden considerar bastante similares.

Similitud del producto escalar

Una desventaja de la similitud entre coseno es que solo tiene en cuenta el ángulo entre dos vectores pero no su magnitud (es decir, la longitud), lo que significa que si dos vectores apuntan aproximadamente en la misma dirección pero uno es mucho más largo que el otro, ambos seguirán considerar similares. La similitud del producto escalar, también llamada escalar o producto interior, mejora esto teniendo en cuenta tanto el ángulo como la magnitud de los vectores, lo que proporciona una métrica de similitud mucho más precisa.

Se emplean dos fórmulas equivalentes para calcular la similitud del producto escalar. La primera es la misma que vimos anteriormente en el numerador de similitud coseno:

La segunda fórmula simplemente multiplica la longitud de ambos vectores por el coseno del ángulo entre ellos:

La similitud del producto escalar se visualiza en la Figura 10, a continuación:

Una última vez, tomamos los vectores de muestra x e y calculamos su similitud del producto escalar usando la primera fórmula, como hicimos antes para la similitud coseno, como (1 4) + (2 3) = 10.

Usando la segunda fórmula, multiplicamos la longitud de ambos vectores: y multiplicamos eso por el coseno del ángulo de 26° entre ambos vectores, y obtenemos 11,18034 cos(26°) = 10.

Algo que vale la pena señalar es que si todos los vectores se normalizan primero (es decir, su longitud es 1), entonces la similitud del producto escalar se convierte exactamente en la misma que la similitud del coseno (porque |x| |y| = 1), es decir, el coseno del ángulo entre ambos vectores. Como veremos más adelante, normalizar vectores es una buena práctica para hacer que la magnitud del vector sea irrelevante y que la similitud se centre simplemente en el ángulo. También acelera el cálculo de distancias en el tiempo de indexación y consulta, lo que puede ser un gran problema al operar con miles de millones de vectores.

Resumen rápido

Vaya, revisamos MUCHÍSIMA información hasta ahora, así que vamos a hacer una pausa un momento y hacer un breve resumen de dónde estamos. Aprendimos que...

• … La búsqueda semántica se basa en modelos de redes neuronales de aprendizaje profundo que destacan en transformar datos no estructurados en vectores de incrustación multidimensionales.

• … Cada dimensión del modelo representa una característica o característica de los datos no estructurados.

• … Un vector de incrustación es una secuencia de valores de similitud (uno para cada dimensión) que representa lo similar que es a cada dimensión un dato no estructurado dado.

• … cuanto más "cercanos" estén dos vectores (es decir, los vecinos más cercanos), más representan conceptos semánticamente similares.

• … Las funciones de distancia (L1, L2, Linf) nos permiten medir la proximidad de dos vectores.

• … Las funciones de similitud (coseno y producto escalar) nos permiten medir cuánto se dirigen dos vectores en la misma dirección.

Ahora, la última pieza en la que tenemos que profundizar es el propio motor de búsqueda vectorial. Cuando llega una consulta, primero se vectoriza y luego el motor de búsqueda vectorial encuentra los vectores vecinos más cercanos a ese vector. El enfoque de fuerza bruta de medir la distancia o similitud entre el vector de consulta y todos los vectores de la base de datos puede funcionar para conjuntos de datos pequeños, pero pronto se queda corto a medida que aumenta el número de vectores. Dicho de otro modo, ¿cómo podemos indexar millones, miles de millones o incluso billones de vectores y encontrar los vecinos más cercanos del vector de consulta en un tiempo razonable? Ahí es donde necesitamos ser inteligentes y encontrar formas óptimas de indexar vectores para poder centrarnos en los vecinos más cercanos lo más rápido posible sin degradar demasiado la precisión.

Algoritmos y técnicas de búsqueda vectorial

A lo largo de los años, muchos equipos de investigación invirtieron mucho esfuerzo en desarrollar algoritmos de búsqueda vectorial muy ingeniosos. Aquí vamos a presentar brevemente los principales. Dependiendo del caso de uso, algunos son más adecuados que otros.

Búsqueda lineal

Hablamos brevemente de la búsqueda lineal, o indexación plana, cuando mencionamos el enfoque de fuerza bruta de comparar el vector de consulta con todos los vectores presentes en la base de datos. Aunque puede funcionar bien en conjuntos de datos pequeños, el rendimiento disminuye rápidamente a medida que aumenta el número de vectores y dimensiones (complejidad O(n)).

Por suerte, existen enfoques más eficientes llamados vecinos aproximados (ANN), donde las distancias entre vectores de incrustación se precalculan y se almacenan y organizan vectores similares de forma que se mantengan cerca unos de otros, por ejemplo usando clústeres, árboles, hashes o grafos. Estos enfoques se denominan "aproximados" porque normalmente no garantizan una precisión del 100%. El objetivo final es reducir el alcance de la búsqueda tanto y lo más rápido posible para centrar solo en las áreas que tienen más probabilidades de contener vectores similares o reducir la dimensionalidad de los vectores.

Árboles de dimensión K

Un árbol de dimensión K, o árbol KD, es una generalización de un árbol binario de búsqueda que almacena puntos en un espacio de dimensión k y funciona dividiendo continuamente el espacio de búsqueda en árboles más pequeños a la izquierda y a la derecha donde se indexan los vectores. En el momento de buscar, el algoritmo simplemente tiene que visitar algunas ramas del árbol alrededor del vector de consulta (el punto rojo de la Figura 11) para encontrar el vecino más cercano (el punto verde de la Figura 11). Si se aplicar más de k vecinos, entonces el área amarilla se extiende hasta que el algoritmo encuentre más vecinos.

El mayor beneficio del algoritmo del árbol KD es que nos permite centrarnos rápidamente solo en algunas ramas localizadas del árbol, eliminando así la mayoría de los vectores de la consideración. Sin embargo, la eficiencia de este algoritmo disminuye a medida que aumenta el número de dimensiones, ya que es necesario visitar muchas más ramas que en espacios de dimensiones inferiores.

Índice de archivos invertido

El enfoque de índice de archivos invertido (IVF) también es un algoritmo de partición de espacio que asigna vectores cercanos entre sí a su centroide compartido. En el espacio 2D, esto se visualiza mejor con un diagrama de Voronoi, como se muestra en la Figura 12:

Podemos ver que el espacio 2D anterior está dividido en 20 grupos, cada uno con su centroide denotado como puntos negros. Todos los vectores de incrustación en el espacio se asignan al clúster cuyo centroide está más cercano a ellos. En el momento de buscar, el algoritmo primero determina el clúster en el que centrar encontrando el centroide más cercano al vector de consulta, y luego puede simplemente enfocar en esa zona, y también en las circundantes si es necesario, para encontrar los vecinos más cercanos.

Este algoritmo sufre el mismo problema que los árboles KD cuando se usa en espacios de alta dimensión. Esto se llama la maldición de la dimensionalidad, y ocurre cuando el volumen del espacio aumenta tanto que todos los datos parecen escasos y la cantidad de datos que se necesitaría para obtener resultados más precisos crece exponencialmente. Cuando los datos son escasos, resulta más difícil para estos algoritmos de partición del espacio organizar los datos en clústeres. Por suerte para nosotros, existen otros algoritmos y técnicas que alivian este problema, como se detalla a continuación.

Cuantificación

La cuantización es un enfoque basado en compresiónque nos permite reducir el tamaño total de la base de datos disminuyendo la precisión de los vectores de incrustación. Esto se puede lograr usando cuantización escalar (SQ) convirtiendo los valores vectoriales de punto flotante en valores enteros. Esto no solo reduce el tamaño de la base de datos en un factor de 8, sino que también disminuye el consumo de memoria y acelera el cálculo de distancias entre vectores en el momento de búsqueda.

Otra técnica se llama cuantización por producto (PQ), que primero divide el espacio en subespacios de dimensión inferior, y luego los vectores muy cercanos se agrupan en cada subespacio usando un algoritmo de agrupamiento (similar a las k-medias).

Cabe señalar que la cuantización es diferente de la reducción de dimensionalidad, donde se reduce el número de dimensiones, es decir, los vectores simplemente se acortan.

Pequeños Mundos Jerárquicos Navegables (HNSW)

Si parece complejo solo con leer el nombre, no te preocupes, ¡no lo es realmente! En resumen, Jerarchical Navigable Small Worlds es un algoritmo basado en grafos de múltiples capas que es muy popular y eficiente. Es empleado por muchas bases de datos vectoriales diferentes, incluyendo Apache Lucene. Una representación conceptual de HNSW puede ver en la Figura 13, a continuación.

En la capa superior, podemos ver un grafo de muy pocos vectores que tienen los enlaces más largos entre ellos, es decir, un grafo de vectores conectados con la menor similitud. Cuanto más profundizamos en capas inferiores, más vectores encontramos y más denso se vuelve el grafo, con cada vez más vectores más cerca entre sí. En la capa más baja, podemos encontrar todos los vectores, siendo los más similares los más cercanos entre sí.

En el momento de la búsqueda, el algoritmo comienza desde la capa superior en un punto de entrada arbitrario y encuentra el vector más cercano al vector de consulta (mostrado por el punto gris). Luego, se mueve una capa por debajo y repite el mismo proceso, empezando por el mismo vector que dejó en la capa anterior, y así sucesivamente, capa tras capa, hasta llegar a la capa más baja y encontrar al vecino más cercano al vector de consulta.

Hashing sensible a la localidad (LSH)

En la misma línea que todos los demás enfoques presentados hasta ahora, el hashing sensible a la localidad busca reducir significativamente el espacio de búsqueda para aumentar la velocidad de recuperación. Con esta técnica, los vectores de incrustación se transforman en valores hash, todo preservando la información de similitud, de modo que el espacio de búsqueda se convierte finalmente en una simple tabla hash que se puede consultar en lugar de un grafo o árbol que hay que recorrer. El principal beneficio de los métodos basados en hash es que los vectores que contienen un número arbitrario (grande) de dimensiones pueden mapearse a hashes de tamaño fijo, lo que acelera enormemente el tiempo de recuperación sin sacrificar demasiada precisión.

Existen muchas formas diferentes de hacer hashing de datos en general, y de incrustar vectores en individuo, pero este artículo no profundizará en los detalles de cada una de ellas. Los métodos de hashing convencionales suelen producir hashes muy diferentes para datos que parecen muy similares. Dado que los vectores de incrustación están compuestos por valores flotantes, tomemos dos valores de flotación de muestra que se consideran muy cercanos entre sí en aritmética vectorial (por ejemplo, 0,73 y 0,74) y los pasemos por algunas funciones de hash comunes. Al mirar los resultados a continuación, es bastante obvio que las funciones de hash comunes no mantienen la similitud entre las entradas.

Función de hash

0.73

0.74

MD5

1342129d04cd2924dd06cead4cf0a3ca

0aec1b15371bd979cfa66b0a50ebecc5

SHA1

49d2c3e0e44bff838e1db571a121be5ea874e8d9

a534e76482ade9d9fe4bff3035a7f31f2f363d77

SHA256

99d03fc3771fe6848d675339fc49eeb1cb8d99a12e6358173336b99a2ec530ea

5ecbc825ba5c16856edfdaf0abc5c6c41d0d8a9c508e34188239521dc7645663

Mientras que los métodos convencionales de hashing intentan minimizar las colisiones de hashing entre fragmentos de datos similares, el objetivo principal del hashing sensible a la localidad es hacer exactamente lo contrario, es decir, maximizar las colisiones de hashing para que datos similares caigan dentro del mismo cubo con alta probabilidad. Al hacerlo, los vectores de incrustación que están muy cerca en un espacio multidimensional se hashearán hasta un valor de tamaño fijo que cae en el mismo cubo. Dado que LSH permite que esos vectores hasheados mantengan su proximidad, esta técnica resulta muy útil para agrupar datos y búsquedas de vecinos más cercanos.

Todo el trabajo pesado ocurre en el momento de indexación, cuando hay que calcular los hashes, mientras que en busca solo necesitamos hacer hash del vector de consulta para buscar el cubo que contiene los vectores de incrustación más cercanos. Una vez encontrado el cubo candidato, normalmente se realiza una segunda ronda para identificar los vectores vecinos más cercanos al vector de consulta.

Concluyamos

Para introducir la búsqueda vectorial, tuvimos que cubrir bastante terreno en este artículo. Tras comparar las diferencias entre la búsqueda léxica y la búsqueda vectorial, aprendimos cómo los modelos de redes neuronales de aprendizaje profundo logran capturar la semántica de los datos no estructurados y transcodificar su significado en vectores de incrustación de alta dimensión, una secuencia de números de coma flotante que representan la similitud de los datos a lo largo de cada una de las dimensiones del modelo. También cabe destacar que la búsqueda vectorial y la búsqueda léxica no son técnicas de recuperación de información complementarias en competencia (como veremos en la tercera parte de este serial cuando profundizaremos en la búsqueda híbrida).

Luego de eso, introdujimos un bloque fundamental de la búsqueda vectorial, a saber, las funciones de distancia (y similitud) que nos permiten medir la proximidad de dos vectores y evaluar la similitud de los conceptos que representan.

Por último, revisamos diferentes variantes de los algoritmos y técnicas de búsqueda vectorial más populares, que pueden basar en árboles, grafos, clústeres o hashes, cuyo objetivo es acotar rápidamente una zona específica del espacio multidimensional para encontrar a los vecinos más cercanos sin tener que recorrer todo el espacio como haría una búsqueda lineal por fuerza bruta.

Si te gusta lo que estás leyendo, cerciórate de echar un vistazo a las otras partes de este serial:

• Parte 2: Cómo configurar la búsqueda vectorial en Elasticsearch

• Parte 3: Búsqueda híbrida usando Elasticsearch

El conector de almacenamiento vectorial de Semantic Kernel Elasticsearch, ya de fábrica , soporta las abstracciones de almacenamiento vectorial Semantic Kernel, lo que facilita mucho a los desarrolladores integrar Elasticsearch como un almacén vectorial mientras crean agentes de IA.

Elasticsearch tiene una estable base en la comunidad de código abierto y recientemente adoptó la licencia AGPL. Combinadas con el kernel semántico de código abierto de Microsoft, estas herramientas ofrecen una solución poderosa y preparada para compañías. Puedes empezar localmente activando Elasticsearch en unos minutos ejecutando este curl -fsSL https://elastic.co/start-local | sh de comandos (consulta start-local para más detalles) y pasar a versiones alojadas en la nube o autoalojadas mientras produces tus agentes de IA.

En este blog analizamos cómo usar Semantic Kernel Elasticsearch Vector Store Connector al usar Semantic Kernel. En el futuro se pondrá a disposición una versión en Python del conector.

Escenario de alto nivel: Construcción de una aplicación RAG con Kernel Semántico y Elasticsearch

En la siguiente sección repasamos un ejemplo. A un nivel general, estamos construyendo una aplicación RAG (Recuperación Generación Aumentada) que toma la pregunta del usuario como entrada y devuelve una respuesta. Usaremos Azure OpenAI (también se puede usar un LLM local ) como LLM, Elasticsearch como almacén vectorial y Semantic Kernel (.net) como marco para unir todos los componentes.

Si no estás familiarizado con las arquitecturas RAG, puedes hacer una breve introducción con este artículo: https://www.elastic.co/search-labs/blog/retrieval-augmented-generation-rag.

La respuesta la genera el LLM, que se alimenta con el contexto relevante para la pregunta, recuperado de Elasticsearch vectorstore. La respuesta también incluye la fuente que el LLM empleó como contexto.

Ejemplo RAG

En este ejemplo concreto, construimos una aplicación que permite a los usuarios hacer preguntas sobre hoteles almacenados en una base de datos interna de hoteles. El usuario podría, por ejemplo, Busca un hotel específico, según diferentes criterios, o pide una lista de hoteles.

Para la base de datos de ejemplo, generamos una lista de hoteles con 100 entradas. El tamaño de la muestra es intencionadamente pequeño para que puedas probar la demo del conector lo más fácilmente posible. En una aplicación real, el conector Elasticsearch mostraría sus beneficios sobre otras opciones, como la implementación de almacenamiento vectorial 'InMemory', especialmente cuando se trabaja con cantidades extremadamente grandes de datos.

La aplicación de demostración completa se puede encontrar en el repositorio de conectores de almacenamiento vectorial de Elasticsearch.

Empecemos agregando los paquetes NuGet necesarios y aplicando directivas a nuestro proyecto:

Ahora podemos crear nuestro modelo de datos y proporcionarle atributos específicos del Núcleo Semántico para definir el esquema del modelo de almacenamiento y algunas pistas para la búsqueda de texto:

Los atributos del Esquema del Modelo de Almacenamiento ('VectorStore*') son los más relevantes para el uso real del Conector de Almacenamiento Vectorial Elasticsearch, a saber:

• VectorStoreRecordKey para marcar una propiedad en una clase de registro como la clave bajo la cual el registro se almacena en un almacén vectorial.

• VectorStoreRecordData para marcar una propiedad en una clase de registro como 'datos'.

• VectorStoreRecordVector para marcar una propiedad en una clase de registro como vector.

Todos estos atributos aceptan varios parámetros opcionales que pueden emplear para personalizar aún más el modelo de almacenamiento. En el caso de VectorStoreRecordKey , por ejemplo, es posible especificar una función de distancia diferente o un tipo de índice distinto.

Los atributos de búsqueda de texto (TextSearch*) serán importantes en el último paso de este ejemplo. Volveremos a ellos más tarde.

En el siguiente paso, inicializamos el motor Semantic Kernel y obtenemos referencias a los servicios principales. En una aplicación real, se debe usar inyección de dependencias en lugar de acceder directamente a la colección de servicios. Lo mismo se aplica a la configuración y secretos codificados en fija, que deberían leer usando un proveedor de configuración en su lugar:

El servicio de vectorStoreCollection ahora puede usar para crear la colección e incorporar algunos discos demo:

Esto muestra cómo Semantic Kernel reduce el uso de un almacén vectorial con toda su complejidad a unas pocas llamadas a métodos simples.

En el fondo, se crea un nuevo índice en Elasticsearch y se generan todas las asignaciones de propiedades necesarias. Nuestro conjunto de datos se mapea de forma completamente transparente en el modelo de almacenamiento y finalmente se almacena en el índice. A continuación se muestra cómo se ven los mapeos en Elasticsearch.

El embeddings.GenerateEmbeddingsAsync() llama de forma transparente al servicio configurado Azure AI Embeddings Generation.

Se puede observar aún más magia en el último paso de esta demo.

Con una sola llamada a InvokePromptAsync, se realizan todas las siguientes operaciones cuando el usuario hace una pregunta sobre los datos:

1. Se genera una incrustación para la pregunta del usuario

2. Se busca en el almacén vectorial las entradas relevantes

3. Los resultados de la consulta se insertan en una plantilla de prompt

4. La consulta real en forma de prompt final se envía al servicio de finalización de chat con IA

¿Recuerdas los atributos TextSearch* que definimos previamente en nuestro modelo de datos? Estos atributos nos permiten usar marcadores de posición correspondientes en nuestra plantilla de prompts, que se llenan automáticamente con la información de nuestras entradas en el almacén vectorial.

La respuesta final a nuestra pregunta "Por favor, muéstrame todos los hoteles que tengan un bar en la azotea" es la siguiente:

La respuesta correcta se refiere a la siguiente entrada de nuestro hotels.csv

Este ejemplo muestra muy bien cómo el uso de Microsoft Semantic Kernel logra una reducción significativa de la complejidad gracias a sus abstracciones bien pensadas, además de permitir un nivel muy alto de flexibilidad. Por ejemplo, al cambiar una sola línea de código, el almacén vectorial o los servicios de IA empleados pueden ser reemplazados sin necesidad de refactorizar ninguna otra parte del código.

Al mismo tiempo, el framework proporciona un enorme conjunto de funcionalidades de alto nivel, como la función 'InvokePrompt', o el sistema de plantillas o plugins de búsqueda.

La aplicación de demostración completa se puede encontrar en el repositorio de conectores de almacenamiento vectorial de Elasticsearch.

¿Qué más es posible con Elasticsearch?

• Mapeado de nuevas semantic_text de Elasticsearch: Simplificación de la búsqueda semántica

• Reclasificación semántica en Elasticsearch con los retrievers

• Técnicas avanzadas de RAG parte 1: Procesamiento de datos

• Técnicas avanzadas de RAG parte 2: Consultas y pruebas

• Construyendo RAG con Llama 3 de código abierto y Elastic

• Un tutorial para construir agentes locales usando LangGraph, LLaMA3 y almacenamiento vectorial de Elasticsearch desde cero

Elasticsearch & Semantic Kernel: ¿Qué sigue?

• Mostramos cómo la tienda vectorial de Elasticsearch puede conectarse fácilmente a Semantic Kernel mientras se construyen aplicaciones GenAI en .NET. Estad atentos para la próxima integración de Python.

• A medida que Semantic Kernel construye abstracciones para funciones avanzadas de búsqueda como la búsqueda híbrida, el Elasticsearch Connect permitirá a los desarrolladores .NET implementarlas fácilmente usando Semantic Kernel.

Además de integrar la búsqueda híbrida, demostraremos cómo agregar funciones que hagan que tu solución de búsqueda sea aún más robusta. Estas incluyen facetados y promociones personalizadas de productos. Además, te mostraremos cómo capturar las interacciones del usuario y generar información valiosa empleando la herramienta de Análisis de Comportamiento de Elastic.

En esta implementación, verás cómo construir tanto la interfaz que permite a los usuarios ver e interactuar con los resultados de búsqueda como la API responsable de devolver la información. Para acceder a los repositorios con el código fuente, los enlaces se proporcionan a continuación:

• https://github.com/elastic/elasticsearch-labs/tree/main/supporting-blog-content/hybrid-search-for-an-e-commerce-product-catalogue/product-store-search

• https://github.com/elastic/elasticsearch-labs/tree/main/supporting-blog-content/hybrid-search-for-an-e-commerce-product-catalogue/app-product-store

Dividimos esta guía en varios pasos, desde la creación del índice hasta la implementación de funciones avanzadas como el facetado y la personalización de resultados. Al final, tendrás una solución de búsqueda robusta lista para usar en un escenario de comercio electrónico.

Configuración de entornos para búsqueda híbrida de comercio electrónico

Antes de comenzar la implementación, necesitamos configurar el entorno. Puedes elegir usar un servicio en Elastic Cloud o una solución contenedora para gestionar Elasticsearch. Si eliges contenerización, en este repositorio puedes encontrar una configuración mediante Docker Compose: docker-compose.yml.

Creación de índices e ingesta de catálogos de productos

El índice se creará a partir de un catálogo de productos cosméticos, que incluye campos como nombre, descripción, foto, categoría y etiquetas. Los campos usados para la búsqueda en texto completo, como "nombre" y "descripción", se mapearán como text, mientras que los campos usados para agregaciones, como "categoría" y "marca", se mapearán como keyword para permitir el facetado.

El campo "descripción" se empleará para la búsqueda vectorial, ya que proporciona más contexto sobre los productos. Este campo se definirá como dense_vector, almacenar la representación vectorial de la descripción.

El mapeo del índice será el siguiente:

El script para crear el índice se puede encontrar aquí.

Generación de incrustación

Para vectorizar las descripciones de productos, empleamos el modelo all-MiniLM-L6-v2. En este caso, la aplicación es responsable de generar las incrustaciones antes de indexar. Otra opción sería importar el modelo al clúster de Elasticsearch, pero para este entorno local, elegimos realizar la vectorización directamente dentro de la aplicación.

Empleamos el conjunto de datos cosméticos disponible en Kaggle para poblar el índice y, para mejorar la eficiencia de la ingesta de datos, empleamos procesamiento por lotes. Durante esta misma etapa de ingestión, generaremos las incrustaciones para el campo "descripción" e indexarémolas en el nuevo campo "description_embeddings".

El proceso completo de ingesta de datos puede seguir y ejecutar directamente a través del Jupyter Notebook disponible en el repositorio. El cuaderno ofrece una guía paso a paso sobre cómo se leen, procesan e indexan los datos en Elasticsearch, permitiendo una fácil replicación y experimentación.

Puedes acceder al cuaderno en el siguiente enlace: Cuaderno de Ingestión.

Implementación de búsqueda híbrida

Ahora, implementemos la búsqueda híbrida. Para la búsqueda basada en palabras clave, usamos la consulta multi_match , dirigida a los campos "nombre", "categoría" y "descripción". Esto garantiza que se recuperen los documentos que contienen el término de búsqueda en cualquiera de estos campos.

Para la búsqueda vectorial, usamos la consulta KNN. El término de búsqueda debe vectorizarse antes de ejecutar la consulta, y esto se hace usando el método que vectoriza el término de entrada. Ten en cuenta que el mismo modelo usado durante la ingestión también se emplea para el término de búsqueda.

La combinación de ambas búsquedas se realiza mediante el algoritmo de Fusión de Rango Recíproco (RRF), que fusiona los resultados de ambas consultas y aumenta la precisión de la búsqueda al reducir el ruido. RRF permite que tanto las búsquedas basadas en palabras clave como las vectoriales trabajen conjuntamente, mejorando la comprensión de la consulta del usuario.

Comparando resultados: búsqueda por palabras clave vs. búsqueda híbrida

Ahora, comparemos los resultados de una búsqueda tradicional por palabras clave con la búsqueda híbrida. Al buscar "base para piel seca" usando la búsqueda por palabras clave, obtenemos los siguientes resultados:

1. Maquillaje Revlon ColorStay para piel normal / secaDescripción: Revlon ColorStay Makeup ofrece una cobertura duradera con una fórmula ligera que no se desvanece, ni se desvanece. Con Time Release \nTechnology, esta fórmula sin aceites y con equilibrio de humedad está especialmente formulada para piel normal o seca para proporcionar hidratación continua. Características: El maquillaje resulta cómodo y se usa hasta 24 horas\nCobertura media a total\nDisponible en una gama de tonos preciosos

2. Maybelline Dream Smooth Mousse BaseDescripción: Por qué te encantaráLa base única batida con crema ofrece una perfección 100% suave para bebés.\n\nPiel Se ve y se siente hidratado durante 14 horas - nunca áspero ni seco\tLa fórmula ligera ofrece una cobertura perfectamente hidratante\�Se difumina perfectamente y se siente fresca todo el día\tSin aceite, sin fragancia, probado por dermatólogos, probado por alergias, no comedogénico \u2019 no obstruirá los poros.\nSeguro Para piel sensible.

Análisis: Al buscar "base para piel seca", los resultados se obtuvieron mediante la coincidencia exacta entre las palabras clave de búsqueda y los títulos y descripciones de los productos. Sin embargo, este partido no siempre refleja la mejor elección. Por ejemplo, el maquillaje Revlon ColorStay para piel normal / seca es una buena opción, ya que está formulado específicamente para piel seca. Aunque no contiene aceite, su fórmula está diseñada para proporcionar hidratación continua. En cambio, también recibimos la Maybelline Dream Smooth Mousse Foundation, que, aunque sin aceite y mencionando hidratación, suele recomendar más para piel grasa o mixta, ya que los productos sin aceite tienden a centrar en controlar el sebo en lugar de proporcionar la hidratación extra necesaria para la piel seca. Esto pone de manifiesto la limitación de las búsquedas basadas en palabras clave, que pueden devolver productos que no satisfacen completamente las necesidades específicas de las personas con piel seca.

Ahora, al realizar la misma búsqueda usando el enfoque híbrido:

1. CoverGirl Outlast Stay Luminous Foundation Creamy Natural (820):D escription: CoverGirl Outlast Stay Luminous Foundation es perfecta para lograr un acabado luminoso y un brillo sutil. Es sin aceites, con una fórmula no grasienta que da a tu piel una luminosidad natural que dura todo el día. Esta base de maquillaje durante todo el día hidrata la piel y proporciona una cobertura impecable. Análisis: Este producto es una combinación relevante porque enfatiza la hidratación, algo fundamental para usuarios con piel seca. Los términos "hidrata la piel" y "acabado húmedo" coinciden con la intención del usuario de encontrar una base para piel seca. La búsqueda vectorial probablemente entendió el concepto de hidratación y lo relacionó con la necesidad de una base que trate la piel seca.

2. Maquillaje Revlon ColorStay para piel normal / seca: Descripción: El maquillaje Revlon ColorStay ofrece una cobertura duradera con una fórmula ligera que no se empacha, no se desvanece ni se desprende de la piel. Con la Tecnología de Liberación Prolongada, esta fórmula sin aceites y equilibrada por la humedad está especialmente formulada para pieles normales o secas para proporcionar hidratación continua. Análisis: Este producto responde directamente a las necesidades de los usuarios con piel seca, mencionando explícitamente que está formulado para piel normal o seca. La "fórmula de equilibrio de humedad" y la hidratación continua son ideales para quien busca una base adaptada a la piel seca. La búsqueda vectorial recuperó con éxito este resultado, no solo por la coincidencia de palabras clave, sino también por el enfoque en la hidratación y la mención específica de la piel seca como grupo objetivo.

3. Base de SérumDescripción: Las bases sérum son formulaciones ligeras de cobertura media disponibles en una amplia gama de tonos en 21 tonos. Estas bases ofrecen una cobertura moderada que parece natural y con una sensación de sérum muy ligera. Tienen una viscosidad muy baja y se dispensan con la bomba suministrada o con el gotero de vidrio opcional, disponible para su compra por separado si se prefiere. Análisis: En este caso, la descripción enfatiza una base sérum ligera con un toque natural, que se adapta a las necesidades de las personas con piel seca, ya que suelen buscar productos suaves, hidratantes y que ofrezcan un acabado no empalagoso. La búsqueda vectorial probablemente captó el contexto más amplio de la ligera y la cobertura natural y la textura similar al sérum, que se asocia con la retención de humedad y una aplicación cómoda, lo que la hace relevante para piel seca, aunque el término "piel seca" no se mencione explícitamente.

Implementación de facetas

Los aspectos son esenciales para refinar y filtrar los resultados de búsqueda de forma eficiente, proporcionando a los usuarios una navegación más enfocada, especialmente en escenarios con una gran variedad de productos, como el comercio electrónico. Permiten a los usuarios ajustar los resultados según atributos como categoría, marca o precio, haciendo la búsqueda más precisa. Para implementar esta función, empleamos agregaciones de términos en los campos category y brand , que se definieron como keyword durante la fase de creación del índice.

El código completo de la implementación se puede encontrar aquí.

A continuación se vean los resultados de la búsqueda de "base para piel seca":

Personalización de resultados: consultas fijadas

En algunos casos, puede ser beneficioso promocionar ciertos productos en los resultados de búsqueda. Para esto, usamos Consultas Fijadas, que permiten que productos específicos aparezcan en la parte superior de los resultados. A continuación, realizaremos una búsqueda del término "Fundación" sin promocionar ningún producto:

En nuestro ejemplo, podemos promocionar productos que lleven la etiqueta "Sin gluten". Al emplear los identificadores de producto, nos cercioramos de que se prioricen en los resultados de búsqueda. En concreto, promocionaremos los siguientes productos: Serum Foundation (ID: 1043), Coverage Foundation (ID: 1042) y Realist Invisible Setting Powder (ID: 1039).

Empleamos identificadores de producto específicos para cerciorarnos de que se prioricen en los resultados de la consulta. La estructura de la consulta incluye una lista de IDs de producto que deben estar "fijados" en la parte superior (en este caso, IDs 1043, 1042 y 1039), mientras que los resultados restantes siguen el flujo orgánico de la búsqueda, usando una combinación de condiciones como la consulta de texto en los campos "nombre", "categoría", y "descripción". De este modo, es posible promocionar los elementos de forma controlada, cerciorando su visibilidad, mientras que el resto de la búsqueda se basa en la relevancia habitual.

A continuación, puedes ver el resultado de la ejecución de la consulta con los productos promovidos:

El código completo de la consulta se puede encontrar aquí.

Análisis del comportamiento de búsqueda con análisis conductual

Hasta ahora, ya agregamos funcionalidades para mejorar la relevancia de los resultados de búsqueda y facilitar la descubribilidad del producto. Ahora, finalizaremos nuestra solución de búsqueda incluyendo una función que nos ayudará a analizar el comportamiento de búsqueda de los usuarios, identificando patrones como consultas con o sin resultados y clics en los resultados. Para ello, emplearemos la función de Análisis de Comportamiento proporcionada por Elastic. Con él, en solo unos pocos pasos, podemos monitorizar y analizar el comportamiento de búsqueda de los usuarios, obteniendo información valiosa para optimizar la experiencia de búsqueda.

Creación de la colección de análisis de comportamiento

Nuestra primera acción será crear una colección que será responsable de recibir todos los eventos de análisis de conducta. Para crear la colección, accede a la interfaz Kibana en Search > Behavioral Analytics. En el ejemplo siguiente, creamos la colección llamada tracking-search.

Integración del análisis de comportamiento en la interfaz

Nuestra aplicación front-end fue desarrollada en JavaScript y, para integrar Behavioral Analytics, seguiremos los pasos descritos en la documentación oficial de Elastic para instalar el Behavioral Analytics JavaScript Tracker.

Implementación del rastreador JavaScript

Ahora, importaremos el cliente tracker a nuestra aplicación y usaremos los métodos trackPageView, trackSearchy trackSearchClick para capturar las interacciones del usuario.

Aviso legal: Aunque estamos empleando una herramienta para recopilar datos de interacción de usuarios, es esencial garantizar el cumplimiento del RGPD. Esto significa informar claramente a los usuarios sobre qué datos se están recopilando, cómo se emplearán y ofrecer la opción de optar por no participar en el seguimiento. Además, debemos implementar medidas de seguridad estables para proteger la información recopilada y respetar los derechos de los usuarios, como el acceso y la eliminación de datos, cerciorando que todos los pasos cumplan con los principios del RGPD.

Paso 1: Creación de la instancia del rastreador

Primero, crearemos la instancia tracker que monitorizará las interacciones. En esta configuración, definimos el punto final objetivo, el nombre de la colección y la clave API:

Paso 2: Captura de vistas de página

Para registrar las visualizaciones de página, podemos configurar el evento trackPageView :

Para más detalles sobre el evento trackPageView , puedes consultar esta documentación.

Paso 3: Captura de consultas de búsqueda

Para monitorizar las acciones de búsqueda de los usuarios, emplearemos el método trackSearch :

Aquí estamos recopilando el término de búsqueda y los resultados de la búsqueda.

Paso 4: Seguimiento de clics en los resultados de búsqueda

Por último, para capturar clics en los resultados de búsqueda, emplearemos el método trackSearchClick :

Recopilamos información sobre el ID del documento al que se hace clic, así como el término de búsqueda y los resultados.

Análisis de los datos en Kibana

Ahora que se están capturando eventos de interacción de usuarios, podemos obtener datos valiosos sobre las acciones de búsqueda. Kibana emplea la herramienta de Análisis del Comportamiento para visualizar y analizar estos datos conductuales. Para ver los resultados, simplemente navega a Búsqueda > Análisis de Comportamiento > Mi Colección, donde se mostrará un resumen de los eventos capturados.

En esta visión general, obtenemos una visión general de los eventos capturados para cada acción integrada en nuestra interfaz. A partir de esta información, podemos obtener información valiosa sobre el comportamiento de búsqueda de los usuarios. Sin embargo, si quieres crear paneles personalizados con métricas más relevantes para tu escenario específico, Kibana ofrece herramientas poderosas para crear paneles, permitiéndote crear diversas visualizaciones de tus métricas.

A continuación, creé algunas visualizaciones y gráficos para monitorizar, por ejemplo, los términos más buscados a lo largo del tiempo, consultas que no devolvieron resultados, una nube de palabras que resalta los términos más buscados y, finalmente, una visualización geográfica para identificar de dónde proviene el acceso a las búsquedas.

Conclusión

En este artículo, implementamos una solución de búsqueda híbrida que combina búsqueda por palabras clave y vectorial, ofreciendo resultados más precisos y relevantes para los usuarios. También exploramos cómo emplear funciones adicionales, como facetas y personalización de resultados con Consultas Fijadas, para crear una experiencia de búsqueda más completa y eficiente.

Además, integramos el Análisis Conductual de Elastic para capturar y analizar el comportamiento del usuario durante sus interacciones con el motor de búsqueda. Empleando métodos como trackPageView, trackSearchy trackSearchClick, pudimos monitorizar consultas de búsqueda, clics en los resultados y vistas de página, generando información valiosa sobre el comportamiento de búsqueda.

Referencias

Conjunto de datos

https://www.kaggle.com/datasets/shivd24coder/cosmetic-brand-products-dataset

Transformador

https://huggingface.co/sentence-transformers/all-minilm-l6-v2

Fusión recíproca de rangos

https://www.elastic.co/guide/en/elasticsearch/reference/current/rrf.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/retriever.html#rrf-retriever

Consulta Knn

https://www.elastic.co/guide/en/elasticsearch/reference/current/knn-search.html

Consulta fijada

https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-pinned-query.html

APIs de Análisis de Comportamiento

https://www.elastic.co/guide/en/elasticsearch/reference/current/behavioral-analytics-apis.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/behavioral-analytics-overview.html

NOTA Si conoces la versión anterior del cliente Nest de Elasticsearch en C#, lee esta entrada del blog sobre la deprecación del cliente NEST y las nuevas funciones. NEST fue la generación anterior del cliente .NET que fue reemplazado por el Elastic.Clients.Elasticsearch package

• ¿Qué es Blazor?

• ¿Qué es ESRE?

• Configuración de ELSER

• Datos de indexación

• Aplicación en edificios

¿Qué es Blazor?

Blazor es un framework sitio web de código abierto basado en HTML, CSS y C# creado por Microsoft para permitir a los desarrolladores crear aplicaciones sitio web que se ejecuten en el cliente o en el servidor. Blazor también permite crear componentes reutilizables para construir aplicaciones más rápido; permite a los desarrolladores construir la vista HTML y las acciones en C# dentro del mismo archivo, lo que ayuda a mantener un código legible y limpio. Además, con Blazor Hybrid puedes crear aplicaciones móviles nativas accediendo a las capacidades nativas de la plataforma mediante código .NET.

Algunas de las características que hacen de Blazor un excelente marco para trabajar:

• Opciones de renderizado tanto en el lado servidor como en el cliente

• Componentes reutilizables de la interfaz

• Actualizaciones en tiempo real con SignalR

• Gestión del estado integrada

• Sistema de enrutamiento integrado

• Comprobaciones fuertes de tipado y tiempo de compilación

¿Por qué Blazor?

Blazor ofrece varios beneficios sobre otros frameworks y librerías: permite a los desarrolladores usar C# tanto para el código cliente como para el servidor, proporcionando una fuerte verificación de tipado y compilación que mejora la fiabilidad. Se integra perfectamente con el ecosistema .NET, permitiendo la reutilización de librerías y herramientas .NET, y ofrece un soporte robusto para depuración.

¿Qué es ESRE?

El Elasticsearch Relevance Engine™ (ESRE) es un conjunto de herramientas para construir aplicaciones de búsqueda empleando aprendizaje automático e inteligencia artificial sobre el poderoso motor de búsqueda Elasticsearch.

Para saber más sobre ESRE, puedes leer nuestra interesante entrada de blog aquí

Configuración de ELSER

Para aprovechar las capacidades ESRE de Elastic, vamos a emplear ELSER como nuestro proveedor de modelos.

Nota: para usar los modelos ELSER de Elasticsearch, debes tener una licencia Platinum o Enterprise, y disponer de un nodo mínimo dedicado de Machine Lerning (ML) de 4GB de tamaño. Lee más sobre esto aquí.

Empieza creando el punto final de inferencia:

Si es la primera vez que usas ELSER, puede que te encuentres con un error 502 de Mal Gateway mientras el modelo se carga en segundo plano. Puedes consultar el estado del modelo en Machine Learning > Trained Models en Kibana. Una vez desplegado, puedes pasar al siguiente paso.

Datos de indexación

Puedes descargar el conjunto de datos aquí y luego importar los datos usando Kibana. Para ello, ve a la página principal y haz clic en "Subir datos". Luego, sube el archivo y haz clic Import. Por último, ve a la pestaña Advanced y pega los siguientes mapeos:

Vamos a crear un índice capaz de ejecutar consultas semánticas y de texto completo. El tipo de campo semantic_text se encargará del fragmento de datos y la incrustación. Ten en cuenta que estamos indexando longDescription como semantic_text, puedes usar copy_to si quieres indexar un campo tanto como semantic_text como texto'.

Construcción de la app con Blazor & Elasticsearch

Clave API

Lo primero que tenemos que hacer es crear una clave API para autenticar nuestras solicitudes a Elasticsearch. La clave API debe ser de solo lectura y solo permitir consultar el índice de books-blazor .

Verás algo así:

Almacena el valor del campo de respuesta encoded cuando sea necesario más adelante. Si usas Elastic Cloud, también necesitarás tu ID de la nube. (Puedes encontrarlo aquí).

Creación del proyecto Blazor

Empieza instalando Blazor y creando un proyecto de muestra siguiendo las instrucciones oficiales.

Una vez que tengas el proyecto creado, la estructura de carpetas y los archivos deberían ver así:

La aplicación plantilla incluye Bootstrap v5.1.0 para peinar.

Termina la configuración del proyecto instalando el cliente Elasticsearch .NET :

Una vez que completes este paso, tu página debería ver así:

Estructura de carpetas

Ahora, vamos a organizar nuestras carpetas de la siguiente manera:

Archivos explicados:

• Components/Pages/Search.razor: página principal que contiene la barra de búsqueda, los resultados y los filtros.

• Componentes/Páginas/Search.razor.css: estilos de página.

• Components/Elasticsearch/SearchBar.razor: componente de la barra de búsqueda.

• Components/Elasticsearch/Results.razor: componente de resultados.

• Components/Elasticsearch/Facet.razor: componente de filtros.

• Components/Svg/GlassIcon.razor: icono de búsqueda.

• Components/_Imports.razor: esto importará todos los componentes.

• Modelos/Book.cs: esto almacenará el esquema del campo libro.

• Modelos/Response.cs: esto almacenará el esquema de respuesta, incluyendo los resultados de búsqueda, facetas y resultados totales.

• Servicios/ElasticsearchService.cs: Servicio Elasticsearch. Se encargará de la conexión y las consultas a Elasticsearch.

Configuración inicial

Empecemos con una limpieza.

Elimina los archivos:

• Componentes/Páginas/Counter.razor

• Componentes/Páginas/Weather.razor

• Componentes/Páginas/Home.razor

• Componentes/Layout/NavMenu.razor

• Componentes/Diseño/NavMenu.razor.css

Revisa el archivo /Components/_Imports.razor . Deberías tener las siguientes importaciones:

Integración de Elastic en el proyecto

Ahora, importemos los componentes de Elasticsearch:

Vamos a eliminar la barra lateral predeterminada para tener más espacio para nuestra aplicación eliminándola del archivo /Components/Layout/MainLayout.razor :

Ahora introduzcamos las credenciales de Elasticsearch para los secretos de usuario:

Con este enfoque, .Net 8 almacena datos sensibles en una ubicación separada, fuera de la carpeta del proyecto, y los hace accesibles mediante la interfaz IConfiguration . Estas variables estarán disponibles para cualquier proyecto .Net que emplee los mismos secretos de usuario.

Luego, modifiquemos el archivo Program.cs para leer los secretos y montar el cliente Elasticsearch:

Primero, importa las bibliotecas necesarias:

• BlazorApp.Services: contiene el servicio Elasticsearch.

• Elastic.Clients.Elasticsearch: importa la biblioteca cliente .Net 8 de Elasticsearch.

• Elastic.Transport: importa la biblioteca de transporte Elasticsearch, que nos permite usar la clase ApiKey para autenticar nuestras solicitudes.

Segundo, inserta el siguiente código antes de la línea var app = builder.Build() :

Este código leerá las credenciales de Elasticsearch de los secretos de usuario y creará una instancia cliente de Elasticsearch.

Tras la inicialización del cliente ElasticSearch, agrega la siguiente línea para registrar el servicio Elasticsearch:

El siguiente paso será construir la lógica de búsqueda en el archivo /Services/ElasticsearchService.cs :

Primero, importa las bibliotecas y modelos necesarios:

Segundo, agregar la clase ElasticsearchService, constructor y variables:

Configuración de búsqueda

Ahora, vamos a construir nuestra lógica de búsqueda:

• BuildFilters construirá los filtros para la consulta de búsqueda usando las facetas seleccionadas por el usuario.

• BuildHybridQuery construirá una consulta de búsqueda híbrida que combine texto completo y búsqueda semántica.

A continuación, agrega el método de búsqueda:

• SearchBooksAsync: realizará la búsqueda usando la consulta híbrida y devolverá los resultados incluidas agregaciones para construir las facetas.

• FormatFacets: formateará la respuesta de agregación en un diccionario.

• ConvertFacetDictionary: convertirá el diccionario de facetas en un formato más legible.

El siguiente paso es crear los modelos que representarán los datos devueltos en el hits de la consulta de Elasticsearch que se imprimirán como resultados en nuestra página de búsqueda.

Comenzamos creando el /Models/Book.cs de archivo y agregando lo siguiente:

Luego, configurar la respuesta Elastic en el archivo /Models/Response.cs y agregar lo siguiente:

Configuración de una interfaz básica

A continuación, agrega el componente Barra de búsqueda. En el archivo /Components/Elasticsearch/SearchBar.razor y agrega lo siguiente:

Este componente contiene una barra de búsqueda y un botón para realizar la búsqueda.

Blazor ofrece una gran flexibilidad al permitir generar HTML dinámicamente usando código C# dentro del mismo archivo.

Después, en el archivo /Components/Elasticsearch/Results.razor construiremos el componente de resultados que mostrará los resultados de búsqueda:

Finalmente, necesitaremos crear facetas para filtrar los resultados de búsqueda.

Nota: Los facetos son filtros que permiten a los usuarios reducir los resultados de búsqueda en función de atributos o categorías específicas, como el tipo de producto, el rango de precio o la marca. Estos filtros suelen presentar como opciones clicables, a menudo en forma de casillas para marcar, para ayudar a los usuarios a refinar su búsqueda y encontrar resultados relevantes con mayor facilidad. En el contexto de Elasticsearch, las facetas se crean mediante agregaciones.

Configuramos facetas poniendo el siguiente código en el archivo /Components/Elasticsearch/Facet.razor:

Este componente lee de una agregación terms en los campos author, categoriesy status , y luego produce una lista de filtros para enviar de vuelta a Elasticsearch.

Ahora, vamos a juntar todo.

En /Components/Pages/Search.razor expediente:

¡Nuestra página funciona!

Como puedes ver, la página es funcional pero carece de estilos. Vamos a agregar algo de CSS para que parezca más organizado y receptivo.

Empecemos a reemplazar los estilos de distribución. En el archivo Components/Layout/MainLayout.razor.css :

Agrega los estilos de la página de búsqueda en el archivo Components/Pages/Search.razor.css :

Nuestra página empieza a ver mejor:

Vamos a darle los toques finales:

Crea los siguientes archivos:

• Componentes/Elasticsearch/Facet.razor.css

• Components/Elasticsearch/Results.razor.css

Y agrega los estilos para Facet.razor.css:

Para Results.razor.css:

Resultado final:

Para ejecutar la aplicación puedes usar el siguiente comando:

dotnet watch

¡Lo conseguiste! Ahora puedes buscar libros en tu índice de Elasticsearch usando la barra de búsqueda y filtrar los resultados por autor, categoría y estado.

Realización de búsqueda en texto completo y semántica

Por defecto, nuestra app realiza una búsqueda híbrida usando tanto texto completo como búsqueda semántica. Puedes cambiar la lógica de búsqueda creando dos métodos separados, uno para texto completo y otro para búsqueda semántica, y luego seleccionar uno para construir la consulta basar en la entrada del usuario.

Agrega los siguientes métodos a la clase ElasticsearchService en el archivo /Services/ElasticsearchService.cs :

Ambos métodos funcionan de forma similar al método BuildHybridQuery , pero solo realizan búsqueda en texto completo o semántica.

Puedes modificar el método SearchBooksAsync para usar el método de búsqueda seleccionado:

Puedes encontrar la solicitud completa aquí

Conclusión

Blazor es un framework eficaz que te permite crear aplicaciones sitio web usando C#. Elasticsearch es un poderoso motor de búsqueda que te permite crear aplicaciones de búsqueda. Combinando ambos, puedes construir fácilmente aplicaciones de búsqueda robustas, aprovechando el poder de ESRE para crear una experiencia de búsqueda semántica en poco tiempo.

• Habla con los LLMs implementando un ChatLanguageModel y un ChatMemory

• Conserva el historial de chats en memoria para recordar el contexto de una conversación previa con un LLM

Esta entrada del blog trata sobre cómo:

• Crear incrustaciones vectoriales a partir de ejemplos de texto

• Almacenar incrustaciones vectoriales en el almacenamiento de incrustaciones de Elasticsearch

• Búsqueda de vectores similares

Crear incrustaciones

Para crear embeddings, necesitamos definir un EmbeddingModel a emplear. Por ejemplo, podemos usar el mismo modelo de mistral que usamos en la publicación anterior. Estaba corriendo con ollama:

Un modelo es capaz de generar vectores a partir de texto. Aquí podemos comprobar el número de dimensiones generadas por el modelo:

Para generar vectores a partir de un texto, podemos usar:

O si también queremos proporcionar metadatos para filtrar cosas como texto, precio, fecha de lanzamiento o lo que sea, podemos usar Metadata.from(). Por ejemplo, aquí agregamos el nombre del juego como campo de metadatos:

Si quieres ejecutar este código, por favor echa un vistazo a la clase Step5EmbedddingsTest.java .

Agregar Elasticsearch para almacenar nuestros vectores

LangChain4j proporciona un almacén de incrustación en memoria. Esto es útil para realizar pruebas sencillas:

Pero obviamente, esto no podría funcionar con un conjunto de datos mucho mayor porque este almacén almacena todo en memoria y no tenemos memoria infinita en nuestros servidores. Así que, en su lugar, podríamos almacenar nuestras incrustaciones en Elasticsearch, que por definición es "elástico" y puede escalar hacia arriba y hacia fuera con tus datos. Para ello, agregamos Elasticsearch a nuestro proyecto:

Como notasteis, también agregamos el módulo Elasticsearch TestContainers al proyecto, para poder iniciar una instancia de Elasticsearch a partir de nuestras pruebas:

Para usar Elasticsearch como almacén de embebed, "solo" tienes que cambiar del almacén de datos en memoria de LangChain4j al de Elasticsearch:

Esto almacenará tus vectores en Elasticsearch en un índice default . También puedes cambiar el nombre del índice por algo más significativo:

Si quieres ejecutar este código, por favor echa un vistazo a la clase Step6ElasticsearchEmbedddingsTest.java .

Búsqueda de vectores similares

Para buscar vectores similares, primero necesitamos transformar nuestra pregunta en una representación vectorial usando el mismo modelo que usamos anteriormente. Ya lo hicimos, así que no es difícil hacerlo de nuevo. Ten en cuenta que en este caso no necesitamos los metadatos:

Podemos construir una solicitud de búsqueda con esta representación de nuestra pregunta y pedir al almacén de incrustaciones que encuentre los primeros vectores principales:

Podemos iterar sobre los resultados ahora e imprimir algo de información, como el nombre del juego que proviene de los metadatos y el puntaje:

Como era de esperar, esto nos da "Out Run" como primer éxito:

Si quieres ejecutar este código, por favor echa un vistazo a la clase Step7SearchForVectorsTest.java .

Tras bambalinas

La configuración predeterminada para la tienda de incrustación de Elasticsearch emplea la consulta aproximada kNN detrás de escena.

Pero esto podría cambiar proporcionando otra configuración (ElasticsearchConfigurationScript) distinta a la predeterminada (ElasticsearchConfigurationKnn) en la tienda de incrustación:

La implementación ElasticsearchConfigurationScript ejecuta entre bastidores una consulta script_score usando una función cosineSimilarity.

Básicamente, al llamar:

Esto ahora llama:

En ese caso, el resultado no cambia en términos de "orden", sino que solo se ajusta el puntaje porque la llamada cosineSimilarity no emplea ninguna aproximación, sino que calcula el coseno para cada uno de los vectores emparejados:

Si quieres ejecutar este código, por favor echa un vistazo a la clase Step7SearchForVectorsTest.java .

Conclusión

Explicamos lo fácil que es generar incrustaciones a partir de tu texto y cómo puedes almacenar y buscar los vecinos más cercanos en Elasticsearch usando dos enfoques diferentes:

• Usando la consulta de knn aproximada y rápida con la opción de ElasticsearchConfigurationKnn por defecto

• Usando la consulta de script_score exacta pero más lenta con la opción ElasticsearchConfigurationScript

El siguiente paso será construir una aplicación completa de RAG, basada en lo que aprendimos aquí.

¡Bienvenidos a la Parte 2 de nuestro artículo sobre Técnicas Avanzadas de RAG! En la parte 1 de este serial, establecimos, discutimos e implementamos los componentes de procesamiento de datos de la avanzada tubería RAG:

En esta parte, vamos a proceder con la consulta y la prueba de nuestra implementación. ¡Vamos al grano!

Índice

• Búsqueda y recuperación, generando respuestas

  • Enriqueciendo consultas con sinónimos

  • HyDE (Incrustación de Documentos Hipotéticos)

  • Búsqueda híbrida

• Experimentos

  • Resumen de resultados

  • Prueba 1: ¿Quién audita a Elastic?

    • AdvancedRAG

    • SimpleRAG

  • Test 2: ingresos totales 2023

    • AdvancedRAG

    • SimpleRAG

  • Prueba 3: ¿De qué producto depende principalmente el crecimiento? ¿Cuánto?

    • AdvancedRAG

    • SimpleRAG

  • Prueba 4: Describe el plan de beneficios para empleados

    • AdvancedRAG

    • SimpleRAG

  • Prueba 5: ¿Qué compañías adquirió Elastic?

    • AdvancedRAG

    • SimpleRAG

• Conclusión

• Apéndice

  • Prompts

    • Prompt de respuesta a preguntas RAG

    • Prompt generador de consultas elástico

    • Prompt generador de preguntas potenciales

    • Prompt generador de HyDE

  • Consulta de búsqueda híbrida de ejemplo

Búsqueda y recuperación, generando respuestas

Hagamos nuestra primera pregunta, idealmente alguna información que se encuentre principalmente en el reporte anual. ¿Qué tal esto:

Ahora, apliquemos algunas de nuestras técnicas para mejorar la consulta.

Enriqueciendo consultas con sinónimos

Primero, mejoremos la diversidad de la redacción de la consulta y convirtiéramos en un formulario que pueda procesar fácilmente en una consulta de Elasticsearch. Aplicar la ayuda de GPT-4o para convertir la consulta en una lista de cláusulas OR. Vamos a escribir este prompt:

Cuando se aplica a nuestra consulta, GPT-4o genera sinónimos de la consulta base y el vocabulario relacionado.

En la clase ESQueryMaker , definí una función para dividir la consulta:

Su función es tomar esta cadena de cláusulas OR y dividirlas en una lista de términos, permitiéndonos hacer una coincidencia múltiple en nuestros campos clave del documento:

Por fin terminando con esta pregunta:

Esto cubre muchas más bases que la consulta original, con suerte reduciendo el riesgo de perder un resultado de búsqueda porque olvidamos un sinónimo. Pero podemos hacer más.

Volver arriba

HyDE (Incrustación de Documentos Hipotéticos)

Vamos a reclutar de nuevo GPT-4o, esta vez para implementar HyDE.

La premisa básica de HyDE es generar un documento hipotético: el tipo de documento que probablemente contenga la respuesta a la consulta original. La veracidad o exactitud del documento no es un problema. Con eso en mente, escribamos el siguiente prompt:

Dado que la búsqueda vectorial suele operar sobre similitud vectorial coseno, la premisa de HyDE es que podemos obtener mejores resultados emparejando documentos con documentos en lugar de consultas con documentos.

Lo que nos importa es la estructura, el flujo y la terminología. No tanto la factualidad. GPT-4o genera un documento HyDE así:

Parece bastante creíble, como el candidato ideal para los tipos de documentos que queremos indexar. Vamos a incrustar esto y usarlo para búsqueda híbrida.

Volver arriba

Búsqueda híbrida

Esta es la base de nuestra lógica de búsqueda. Nuestro componente de búsqueda léxica serán las cadenas de cláusulas OR generadas. Nuestro componente vectorial denso será el documento HyDE embebido (también conocido como el vector de búsqueda). Empleamos KNN para identificar eficientemente varios documentos candidatos más cercanos a nuestro vector de búsqueda. Por defecto, llamamos a nuestro componente de búsqueda léxico Puntaje con TF-IDF y BM25 . Finalmente, los puntajes léxicos y vectoriales densas se combinarán usando la proporción 30/70 recomendada por Wang et al.

Finalmente, podemos reconstruir una función RAG. Nuestro RAG, desde la consulta hasta la respuesta, seguirá este flujo:

1. Convertir la consulta en cláusulas OR.

2. Genera un documento HyDE e incrustalo.

3. Pásame ambos como entradas a la búsqueda híbrida.

4. Recuperar los resultados top-n, invertirlos para que el puntaje más relevante sea la "más reciente" en la memoria contextual del LLM (Empaquetado inverso) Ejemplo de empaquetado inverso: Consulta: "Técnicas de optimización de consultas Elasticsearch" Documentos recuperados (ordenados por relevancia): Orden invertido para el contexto del LLM: Al invertir el orden, la información más relevante (1) aparece al final en el contexto, Potencialmente recibiendo más atención del LLM durante la generación de respuestas.

   1. "Emplea consultas bool para combinar múltiples criterios de búsqueda de forma eficiente."

   2. "Implementar estrategias de caché para mejorar los tiempos de respuesta a las consultas."

   3. "Optimizar los mapeos de índice para un rendimiento de búsqueda más rápido."

   4. "Optimizar los mapeos de índice para un rendimiento de búsqueda más rápido."

   5. "Implementar estrategias de caché para mejorar los tiempos de respuesta a las consultas."

   6. "Emplea consultas bool para combinar múltiples criterios de búsqueda de forma eficiente."

5. Pasa el contexto al LLM para que genere.

Vamos a hacer nuestra consulta y obtener nuestra respuesta:

Muy bien. Así es.

Volver arriba

Experimentos

Hay una pregunta importante que responder ahora. ¿Qué obtuvimos invirtiendo tanto esfuerzo y complejidad adicional en estas implementaciones?

Hagamos una pequeña comparación. La pipeline RAG que implementamos frente a la búsqueda híbrida base, sin ninguna de las mejoras que hicimos. Haremos un pequeño serial de pruebas para ver si notamos diferencias sustanciales. Nos referiremos al RAG que acabamos de implementar como AdvancedRAG, y al pipeline básico como SimpleRAG.

Resumen de resultados

Esta tabla resume los resultados de cinco pruebas de ambas tuberías RAG. Juzgué la superioridad relativa de cada método basándome en el detalle y la calidad de las respuestas, pero este es un juicio totalmente subjetivo. Las respuestas reales se reproducen a continuación de esta tabla para que lo consideres. Dicho esto, ¡echemos cómo les fue!

SimpleRAG no pudo responder a las preguntas 1 y 5. AdvancedRAG también profundizó mucho más en las preguntas 2, 3 y 4. Basándome en el mayor detalle, evalué mejor la calidad de las respuestas de AdvancedRAG.

Prueba

Pregunta

Rendimiento avanzado de RAG

Rendimiento de SimpleRAG

Latencia de AdvancedRAG

Latencia de SimpleRAG

Ganador

1

¿Quién audita Elastic?

Identificó correctamente a PwC como contralor.

No se identificó al contralor.

11,6

4,4

AdvancedRAG

2

¿Cuál fue el total de ingresos en 2023?

Proporcionó la cifra correcta de ingresos. Incluyó contexto adicional sobre ingresos de años anteriores.

Proporcionó la cifra correcta de ingresos.

13,3s

2,8

AdvancedRAG

3

¿De qué producto depende principalmente el crecimiento? ¿Cuánto?

Identificamos correctamente a Elastic Cloud como el motor clave. Incluyó el contexto general de ingresos y mayor detalle.

Identificamos correctamente a Elastic Cloud como el motor clave.

14.1

12,8

AdvancedRAG

4

Describe el plan de beneficios para empleados

Ofreció una descripción completa de los planes de jubilación, programas de salud y otros beneficios. Incluyó cantidades específicas de contribución para distintos años.

Ofreció una buena visión general de los beneficios, incluyendo compensación, planes de jubilación, entorno laboral y el programa Elastic Cares.

26,6

11,6

AdvancedRAG

5

¿Qué compañías adquirió Elastic?

Listé correctamente las adquisiciones recientes mencionadas en el reporte (CmdWatch, Build Security, Optimyze). Proporcioné algunas fechas de adquisición y precios de compra.

No se consiguió recuperar la información relevante del contexto proporcionado.

11,9

2,7

AdvancedRAG

Prueba 1: ¿Quién audita a Elastic?

AdvancedRAG

SimpleRAG

Resumen: SimpleRAG no identificó a PWC como contralor

Vale, eso en realidad es bastante sorprendente. Eso parece un fallo de búsqueda por parte de SimpleRAG. No se recuperaron documentos relacionados con la auditoría. Bajemos un poco la dificultad con la siguiente prueba.

Test 2: ingresos totales 2023

AdvancedRAG

SimpleRAG

Resumen: Ambos RAG obtuvieron la respuesta correcta: 1.068.989.000 dólares de ingresos totales en 2023

Ambos estaban justo aquí. ¿Parece que AdvancedRAG adquirió una gama más amplia de documentos? Sin duda, la respuesta es más detallada e incorpora información de años anteriores. Eso es de esperar dadas las mejoras que hicimos, pero es demasiado pronto para decidir.

Subamos la dificultad.

Prueba 3: ¿De qué producto depende principalmente el crecimiento? ¿Cuánto?

AdvancedRAG

SimpleRAG

Resumen: Ambos RAGs identificaron correctamente a Elastic Cloud como el principal motor de crecimiento. Sin embargo, AdvancedRAG incluye más detalles, teniendo en cuenta los ingresos por subscripción y el crecimiento de clientes, y menciona explícitamente otras ofertas de Elastic.

Prueba 4: Describe el plan de beneficios para empleados

AdvancedRAG

SimpleRAG

Resumen: AdvancedRAG entra en mucho más detalle y profundidad, mencionando el plan 401K para empleados con base en EE. UU., así como definiendo planes de contribución fuera de EE. UU. También menciona planes de salud y bienestar, pero no incluye el programa Elastic Cares, que menciona SimpleRAG.

Prueba 5: ¿Qué compañías adquirió Elastic?

AdvancedRAG

SimpleRAG

Resumen: SimpleRAG no recupera ninguna información relevante sobre adquisiciones, lo que lleva a una respuesta fallida. AdvancedRAG lista correctamente CmdWatch, Build Security y Optimyze, que fueron las adquisiciones clave listadas en el reporte.

Volver arriba

Conclusión

Según nuestras pruebas, nuestras técnicas avanzadas parecen aumentar el rango y la profundidad de la información presentada, lo que podría mejorar la calidad de las respuestas RAG.

Además, puede haber mejoras en la fiabilidad, ya que preguntas formuladas de forma ambigua como Which companies did Elastic acquire? y Who audits Elastic fueron respondidas correctamente por AdvancedRAG pero no por SimpleRAG.

Sin embargo, conviene tener en cuenta que en 3 de cada 5 casos, la tubería básica de RAG, que incorpora Búsqueda Híbrida pero ninguna otra técnica, logró producir respuestas que capturaron la mayor parte de la información clave.

Cabe señalar que, debido a la incorporación de LLMs en las fases de preparación y consulta de datos, la latencia de AdvancedRAG suele ser entre 2 y 5 veces mayor que la de SimpleRAG. Este es un costo significativo que puede hacer que AdvancedRAG sea adecuado solo para situaciones donde la calidad de la respuesta se prioriza sobre la latencia.

Los importantes costos de latencia pueden aliviar usando un LLM más pequeño y barato como Claude Haiku o GPT-4o-mini en la fase de preparación de datos. Almacena los modelos avanzados para generar respuestas.

Esto está en línea con los hallazgos de Wang et al. Como muestran sus resultados, cualquier mejora realizada es relativamente incremental. En resumen, un RAG básico te lleva casi hasta un producto final decente, siendo además más barato y rápido. Para mí, es una conclusión interesante. Para casos de uso donde la velocidad y la eficiencia son clave, SimpleRAG es la opción sensata. Para casos de uso en los que hay que exprimir hasta la última gota de rendimiento, las técnicas incorporadas en AdvancedRAG pueden ofrecer una vía a seguir.

Volver arriba

Apéndice

Prompts

Prompt de respuesta a preguntas RAG

Prompt para que el LLM genere respuestas basadas en la consulta y el contexto.

Prompt generador de consultas elástico

Prompt para enriquecer consultas con sinónimos y convertirlas al formato OR.

Prompt generador de preguntas potenciales

Prompt para generar posibles preguntas, enriquecer metadatos del documento.

Prompt generador de HyDE

Prompt para generar documentos hipotéticos usando HyDE

Consulta de búsqueda híbrida de ejemplo

El reciente artículo Searching for Best Practices in Retrieval-Augmented Generation evalúa empíricamente la eficacia de diversas técnicas de mejora del RAG, con el objetivo de converger en un conjunto de mejores prácticas para el RAG.

Implementaremos algunas de estas mejores prácticas propuestas, concretamente aquellas que buscan mejorar la calidad de la búsqueda (fragmentación de oraciones, HyDE, empaquetado inverso).

Por brevedad, omitiremos aquellas técnicas centradas en mejorar la eficiencia (Clasificación de Consultas y Resumen).

También implementaremos algunas técnicas que no se trataron, pero que personalmente encuentro útiles e interesantes (Inclusión de Metadatos, Incrustaciones Compuestas Multi-Campo, Enriquecimiento de Consultas).

Finalmente, realizaremos una breve prueba para ver si la calidad de nuestros resultados de búsqueda y respuestas generadas mejoró respecto a la línea base. ¡Vamos a ello!

Resumen de RAG

RAG tiene como objetivo mejorar los LLMs recuperando información de bases de conocimiento externas para enriquecer las respuestas generadas. Al proporcionar información específica de dominio, los LLM pueden adaptar rápidamente a casos de uso fuera del alcance de sus datos de entrenamiento; Significativamente más barato que el ajuste fino y más fácil de mantener actualizado.

Las medidas para mejorar la calidad de RAG suelen centrar en dos pistas:

1. Mejorar la calidad y claridad de la base de conocimiento.

2. Mejorar la cobertura y especificidad de las consultas de búsqueda.

Estas dos medidas lograrán el objetivo de mejorar las probabilidades de que el LLM tenga acceso a hechos e información relevantes, y así sea menos probable que alucine o se base en su propio conocimiento, que puede estar desactualizado o irrelevante.

La diversidad de métodos es difícil de aclarar en solo unas pocas frases. Vamos directamente a la implementación para aclarar las cosas.

Índice

• Visión general

  • Índice

• Preparación

• Ingestión, procesamiento e incrustación de documentos

  • Ingesta de datos

  • Fragmentación a nivel de frase, por fichas

  • Inclusión y generación de metadatos

    • Frases clave extraídas por TextRank

    • Posibles preguntas generadas por GPT-4o

    • Entidades extraídas por Spacy

  • Incrustaciones compuestas multicampo

    • Indexación a Elastic

• Ruptura de gato

• Apéndice

  • Definiciones

Preparación

Todo el código puede encontrar en el repositorio de Searchlabs.

Primero lo primero. Necesitarás lo siguiente:

1. Un despliegue de nube elástica

2. Una API LLM - Estamos usando un despliegue GPT-4o en Azure OpenAI en este cuaderno

3. Python Versión 3.12.4 o posterior

Ejecutaremos todo el código desde el cuaderno main.ipynb.

Adelante, clona el repositorio por git, navega a supporting-blog-content/advanced-rag-techniques y luego ejecuta los siguientes comandos:

Una vez hecho esto, crea un .env y rellenar los siguientes campos (Referenciado en .env.example). Créditos a mi coautor, Claude-3.5, por los comentarios útiles.

A continuación, elegimos el documento a ingerir y lo colocaremos en la carpeta de documentos. Para este artículo, emplearemos el Reporte Anual 2023 de Elastic N.V. Es un documento bastante exigente y denso, perfecto para poner a prueba nuestras técnicas RAG.

Ahora que estamos listos, vamos a ingestión. Abre main.ipynb y ejecuta las dos primeras celdas para importar todos los paquetes e iniciar todos los servicios.

Volver arriba

Ingestión, procesamiento e incrustación de documentos

Ingesta de datos

• Nota personal: Me sorprende la comodidad de LlamaIndex. En la antigüedad, antes de los LLMs y LlamaIndex, ingerir documentos de varios formatos era un proceso doloroso de recopilar paquetes esotéricos de todas partes. Ahora se reduce a una sola llamada de función. Salvaje.

El SimpleDirectoryReader cargará todos los documentos del directory_path. Para .pdf archivos, devuelve una lista de objetos documento, que convierto a diccionarios de Python porque me resultan más fáciles de manejar.

Cada diccionario contiene el contenido clave en el campo text . También contiene metadatos útiles como número de página, nombre de archivo, tamaño y tipo.

Volver arriba

Fragmentación a nivel de frase, por fichas

Lo primero que hay que hacer es reducir nuestros documentos a fragmentos de una longitud estándar (para garantizar la coherencia y la manejabilidad). Los modelos de incrustación tienen límites únicos de tokens (tamaño máximo de entrada que pueden procesar). Los tokens son las unidades básicas de texto que procesan los modelos. Para evitar la pérdida de información (truncamiento u omisión de contenido), deberíamos proporcionar texto que no exceda esos límites (dividiendo textos más largos en segmentos más pequeños).

El chunking tiene un impacto significativo en el rendimiento. Idealmente, cada fragmento representaría una pieza de información autónoma, capturando información contextual sobre un único tema. Los métodos de fragmentación incluyen el fragmento a nivel de palabra, donde los documentos se dividen por el recuento de palabras, y el fragmento semántico, que emplea un LLM para identificar puntos de interrupción lógicos.

El fragmento a nivel de palabra es barato, rápido y sencillo, pero corre el riesgo de fragmentar las frases y así romper el contexto. El fragmento semántico se vuelve lento y caro, especialmente si se trata de documentos como el Reporte Anual de Elastic de 116 páginas.

Elijamos un enfoque intermedio. El fragmento a nivel de oración sigue siendo sencillo, pero puede preservar el contexto de forma más eficaz que el fragmento a nivel de palabra, siendo significativamente más barato y rápido. Además, implementaremos una ventana deslizante para capturar parte del contexto circundante y aliviar el impacto de dividir los párrafos.

La clase Chunker incorpora el tokenizador del modelo de incrustación para codificar y decodificar texto. Ahora construiremos fragmentos de 512 tokens cada uno, con una superposición de 20 tokens. Para ello, dividiremos el texto en frases, tokenizaremos esas frases y luego agregaremos las frases tokenizadas a nuestro fragmento actual hasta que no podamos agregar más sin superar nuestro límite de tokens.

Finalmente, decodifica las frases de nuevo al texto original para incrustarlas, almacenándola en un campo llamado original_text. Los chunks se almacenan en un campo llamado chunk. Para reducir el ruido (es decir, documentos inútiles), descartaremos cualquier documento de menos de 50 tokens de longitud.

Vamos a repasarla por nuestros documentos:

Y que me devolvan fragmentos de texto que se parezcan a esto:

Volver arriba

Inclusión y generación de metadatos

Dividimos nuestros documentos. Ahora es el momento de enriquecer los datos. Quiero generar o extraer metadatos adicionales. Estos metadatos adicionales pueden emplear para influir y mejorar el rendimiento en las búsquedas.

Definiremos una clase DocumentEnricher , cuyo papel es incluir una lista de documentos (diccionarios de Python) y una lista de funciones del procesador. Estas funciones se ejecutarán sobre la columna original_text de los documentos y almacenarán sus salidas en nuevos campos.

Primero, extraemos las frases clave usando TextRank. TextRank es un algoritmo basado en gráficos que extrae frases clave y oraciones del texto clasificando su importancia en función de las relaciones entre palabras.

A continuación, generaremos potential_questions usando GPT-4o.

Finalmente, extraeremos entidades usando Spacy.

Dado que el código de cada uno de estos es bastante extenso y complejo, me abstendré de reproducirlo aquí. Si te interesa, los archivos están marcados en los ejemplos de código que aparecen a continuación.

Vamos a ejecutar el enriquecimiento de datos:

Y echa un vistazo a los resultados:

Frases clave extraídas por TextRank

Estas frases clave son un sustituto de los temas centrales del fragmento. Si una consulta tiene que ver con ciberseguridad, el puntaje de este segmento se incrementará.

Posibles preguntas generadas por GPT-4o

Estas posibles preguntas pueden coincidir directamente con las consultas de los usuarios, ofreciendo un aumento en el puntaje. Pedimos a GPT-4o que genere preguntas que pueden responder usando la información encontrada en el fragmento actual.

Entidades extraídas por Spacy

Estas entidades cumplen un propósito similar al de las frases clave, pero capturan los nombres de organizaciones e individuos, que la extracción de frases clave puede pasar por alto.

Volver arriba

Incrustaciones compuestas multicampo

Ahora que enriquecimos nuestros documentos con metadatos adicionales, podemos aprovechar esta información para crear incrustaciones más robustas y conscientes del contexto.

Repasemos nuestro punto actual en el proceso. Tenemos cuatro campos de interés en cada documento.

Cada campo representa una perspectiva diferente sobre el contexto del documento, lo que puede destacar un área clave en la que el LLM debe centrar.

El plan es incrustar cada uno de estos campos y luego crear una suma ponderada de las incrustaciones, conocida como Incrustación Compuesta.

Con suerte, esta Incrustación Compuesta permitirá que el sistema sea más consciente del contexto, además de introducir otro hiperparámetro ajustable que controla el comportamiento de búsqueda.

Primero, embebamos cada campo y actualicemos cada documento en su lugar, usando nuestro modelo de incrustación definido localmente importado al inicio del cuaderno main.ipynb.

Cada función de incrustación devuelve el campo de la incrustación, que es simplemente el campo de entrada original con un _embedding postfijo.

Ahora definamos las ponderaciones de nuestra incrustación compuesta:

Las ponderaciones te permiten asignar prioridades a cada componente, basándote en tu caso de uso y la calidad de tus datos. Intuitivamente, el tamaño de estos pesos depende del valor semántico de cada componente. Como el texto en fragmentos en sí es, con diferencia, el más rico, asigno un peso del 70%. Como las entidades son las más pequeñas, siendo solo una lista de nombres de organizaciones o personas, le asigno un peso del 5%. La configuración precisa de estos valores debe determinar empíricamente, caso de uso por caso.

Finalmente, escribamos una función para aplicar los pesos y creemos nuestra incrustación compuesta. También eliminaremos todas las incrustaciones de componentes para ahorrar espacio.

Con esto, completamos el procesamiento de los documentos. Ahora tenemos una lista de objetos documento que se ven así:

Indexación a Elastic

Subamos nuestros documentos en masa a Elastic Search. Para este propósito, hace mucho tiempo definí un conjunto de funciones auxiliares elásticas en elastic_helpers.py. Es un código muy largo, así que vamos a centrarnos en las llamadas a funciones.

es_bulk_indexer.bulk_upload_documents funciona con cualquier lista de objetos de diccionario, aprovechando los convenientes mapeos dinámicos de Elasticsearch.

Ve a Kibana y verifica que todos los documentos fueron indexados. Deberían ser 224. ¡No está mal para un documento tan extenso!

Volver arriba

Ruptura de gato

Vamos a hacer una pausa, el artículo es un poco pesado, lo sé. Mira a mi gato:

Adorable. El sombrero desapareció y sospecho que lo robó y escondió en algún sitio :(

¡Enhorabuena por llegar hasta aquí :)

¡Únete a mí en la Parte 2 para probar y evaluar nuestra cadena RAG!

Apéndice

Definiciones

1. Fragmentación de frases

• Una técnica de preprocesamiento empleada en sistemas RAG para dividir el texto en unidades más pequeñas y significativas.

• Proceso:

  1. Entrada: Gran bloque de texto (por ejemplo, documento, párrafo)

  2. Salida: Segmentos de texto más pequeños (normalmente oraciones o pequeños grupos de oraciones)

• Propósito:

  • Crea segmentos de texto granulares y específicos de contexto

  • Permite una indexación y recuperación más precisas

  • Mejora la relevancia de la información recuperada en sistemas RAG

• Características:

  • Los segmentos tienen significado semántico

  • Puede ser indexado y recuperado de forma independiente

  • A menudo preserva cierto contexto para garantizar la comprensibilidad independiente

• Beneficios:

  • Mejora la precisión de la recuperación

  • Permite una ampliación más enfocada en las canalizaciones RAG

2. HyDE (Embedding de Documentos Hipotéticos)

• Una técnica que emplea un LLM para generar un documento hipotético para la expansión de consultas en sistemas RAG.

• Proceso:

  1. Consulta de entrada a un LLM

  2. El LLM genera un documento hipotético que responde a la consulta

  3. Incrustar el documento generado

  4. Emplea la incrustación para búsqueda vectorial

• Diferencia clave:

  • RAG tradicional: Empareja la consulta con documentos

  • HyDE: Empareja documentos con documentos

• Propósito:

  • Mejorar el rendimiento de la recuperación, especialmente para consultas complejas o ambiguas

  • Captura un contexto semántico más rico que una consulta corta

• Beneficios:

  • Aprovecha el conocimiento de LLM para ampliar las consultas

  • Puede mejorar potencialmente la relevancia de los documentos recuperados

• Desafíos:

  • Requiere inferencia adicional de LLM, aumentando la latencia y el costo

  • El rendimiento depende de la calidad del documento hipotético generado

3. Empaquetado inverso

• Una técnica empleada en sistemas RAG para reordenar los resultados de búsqueda antes de pasarlos al LLM.

• Proceso:

  1. El motor de búsqueda (por ejemplo, Elasticsearch) devuelve los documentos en orden descendente de relevancia.

  2. El orden se invierte, colocando el documento más relevante al final.

• Propósito:

  • Aprovecha el sesgo de actualidad de los LLM, que tienden a centrar más en la información más reciente en su contexto.

  • Garantiza que la información más relevante esté "más fresca" en la ventana de contexto del LLM.

• Ejemplo: Orden original: [Más relevante, Segundo más, Tercero más, ...] Orden invertido: [..., Tercero más, segundo más relevante]

4. Clasificación de consultas

• Una técnica para optimizar la eficiencia del sistema RAG determinando si una consulta requiere RAG o puede ser respondida directamente por el LLM.

• Proceso:

  1. Desarrollar un conjunto de datos personalizado específico para el LLM en uso

  2. Capacitar un modelo de clasificación especializado

  3. Emplea el modelo para categorizar las consultas entrantes

• Propósito:

  • Mejorar la eficiencia del sistema evitando el procesamiento innecesario de RAG

  • Consulta directa al mecanismo de respuesta más adecuado

• Requisitos:

  • Conjunto de datos y modelo específicos de LLM

  • Refinamiento continuo para mantener la precisión

• Beneficios:

  • Reduce la sobrecarga computacional para consultas simples

  • Potencialmente mejora el tiempo de respuesta para consultas que no son RAG

5. Resumen

• Una técnica para condensar documentos recuperados en sistemas RAG.

• Proceso:

  1. Recuperar documentos relevantes

  2. Genera resúmenes concisos de cada documento

  3. Emplea resúmenes en lugar de documentos completos en la tubería RAG

• Propósito:

  • Mejora el rendimiento de RAG centrándote en la información esencial

  • Reducir el ruido y las interferencias de contenido menos relevante

• Beneficios:

  • Potencialmente mejora la relevancia de las respuestas de los LLM

  • Permite incluir más documentos dentro de los límites del contexto

• Desafíos:

  • Riesgo de perder detalles importantes en la resumen

  • Sobrecarga computacional adicional para la generación de resúmenes

6. Inclusión de metadatos

• Una técnica para enriquecer documentos con información contextual adicional.

• Tipos de metadatos:

  • Frases clave

  • Títulos

  • Fechas

  • Detalles de la autoría

  • Resumen

• Propósito:

  • Aumentar la información contextual disponible para el sistema RAG

  • Proporcionar a los LLMs una comprensión más clara del contenido y la relevancia del documento

• Beneficios:

  • Potencialmente mejora la precisión de la recuperación

  • Mejora la capacidad del LLM para evaluar la utilidad de los documentos

• Implementación:

  • Se puede hacer durante el preprocesamiento de documentos

  • Puede requerir pasos adicionales de extracción de datos o generación

7. Incrustaciones compuestas multicampo

• Una técnica avanzada de incrustación para sistemas RAG que crea incrustaciones separadas para diferentes componentes del documento.

• Proceso:

  1. Identificar campos relevantes (por ejemplo, título, frases clave, resúmenes, contenido principal)

  2. Genera incrustaciones separadas para cada campo

  3. Combina o almacena estos embeddings para su uso en la recuperación

• Diferencia con el enfoque estándar:

  • Tradicional: Embedding único para todo el documento

  • Compuesto: Múltiples incrustaciones para diferentes aspectos del documento

• Propósito:

  • Crear representaciones documentales más matizadas y conscientes del contexto

  • Captura información de una mayor variedad de fuentes dentro de un documento

• Beneficios:

  • Potencialmente mejora el rendimiento en consultas ambiguas o multifacéticas

  • Permite una ponderación más flexible de los diferentes aspectos del documento en la recuperación

• Desafíos:

  • Mayor complejidad en los procesos de incrustación, almacenamiento y recuperación

  • Puede requerir algoritmos de emparejamiento más sofisticados

8. Enriquecimiento de consultas

• Una técnica para ampliar la consulta original con términos relacionados para mejorar la cobertura de búsqueda.

• Proceso:

  1. Analizar la consulta original

  2. Generar sinónimos y frases semánticamente relacionadas

  3. Complementa la consulta con estos términos adicionales

• Propósito:

  • Ampliar el rango de posibles coincidencias en el corpus documental

  • Mejorar el rendimiento de recuperación para consultas con lenguaje específico o técnico

• Beneficios:

  • Potencialmente recupera documentos relevantes que no coinciden exactamente con los términos originales de la consulta

  • Puede ayudar a superar la discrepancia de vocabulario entre consultas y documentos

• Desafíos:

  • Riesgo de deriva de consulta si no se implementa cuidadosamente

  • Puede aumentar la sobrecarga computacional en el proceso de recuperación

Volver arriba

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.

Ahí es exactamente donde brillan los motores de búsqueda vectorial. Pueden indexar el mismo texto de tal manera que se pueda buscar tanto en función del significado que representa como de sus relaciones con otros conceptos que tienen un significado similar o relacionado.

En este blog, abordaremos brevemente cómo los vectores son un gran concepto matemático para transmitir el significado del texto. Luego, profundizaremos en las diferentes técnicas de similitud compatibles con Elasticsearch cuando se trata de buscar vectores vecinos, es decir, buscar vectores que tengan un significado similar y cómo puntuarlos.

¿Qué son las incrustaciones de vectores?

Este artículo no profundiza en las complejidades de las incrustaciones de vectores. Si quieres explorar este tema más a fondo o necesitas una introducción antes de continuar, te recomendamos que consultes la siguiente guía.

En pocas palabras, las incrustaciones vectoriales se obtienen a través de un proceso de aprendizaje automático (p. ej. redes neuronales de aprendizaje profundo) que transforma cualquier tipo de datos de entrada no estructurados (por ejemplo, texto sin procesar, imagen, video, sonido, etc.) en datos numéricos que llevan su significado y relaciones. Los diferentes tipos de datos no estructurados requieren diferentes tipos de modelos de aprendizaje automático que fueron capacitados para "comprender" cada tipo de datos.

Cada vector localiza un dato específico como un punto en un espacio multidimensional y esa ubicación representa un conjunto de características que el modelo emplea para caracterizar los datos. El número de dimensiones depende del modelo de aprendizaje automático, pero generalmente oscilan entre un par de cientos y unos pocos miles. Por ejemplo, los modelos OpenAI Embeddings cuentan con 1536 dimensiones, mientras que los modelos Cohere Embeddings pueden variar de 382 a 4096 dimensiones. El tipo de campo Elasticsearch dense_vector admite hasta 4096 dimensiones a partir de la última versión.

La verdadera hazaña de las incrustaciones vectoriales es que los puntos de datos que comparten un significado similar están muy juntos en el espacio. Otro aspecto interesante es que las incrustaciones vectoriales también ayudan a capturar relaciones entre puntos de datos.

¿Cómo comparamos vectores?

Sabiendo que los datos no estructurados son divididos por modelos de aprendizaje automático en incrustaciones vectoriales que capturan la similitud de los datos a lo largo de una gran cantidad de dimensiones, ahora necesitamos comprender cómo funciona la coincidencia de esos vectores. Resulta que la respuesta es bastante simple.

Las incrustaciones vectoriales que están cerca unas de otras representan datos semánticamente similares . Entonces, cuando consultamos una base de datos vectorial, la entrada de búsqueda (imagen, texto, etc.) se convierte primero en incrustaciones vectoriales empleando el mismo modelo de aprendizaje automático que se empleó para indexar todos los datos no estructurados, y el objetivo final es encontrar los vectores vecinos más cercanos a ese vector de consulta. Por lo tanto, todo lo que tenemos que hacer es averiguar cómo medir la "distancia" o "similitud" entre el vector de consulta y todos los vectores existentes indexados en la base de datos, es así de simple.

Distancia, similitud y puntaje

Por suerte para nosotros, medir la distancia o similitud entre dos vectores es un problema fácil de resolver gracias a la aritmética vectorial. Entonces, veamos las funciones de distancia y similitud más populares que son compatibles con Elasticsearch. ¡Advertencia, matemáticas por delante!

Justo antes de sumergirnos, echemos un vistazo rápido al puntaje. De hecho, Lucene solo permite que los puntajes sean positivos. Todas las funciones de distancia y similitud que presentaremos en breve producen una medida de qué tan cerca o similares están dos vectores, pero esas cifras en bruto rara vez son aptas para usar como puntaje, ya que pueden ser negativas. Por esta razón, el puntaje final debe derivar del valor de distancia o similitud de una manera que garantice que el puntaje sea positivo y que un puntaje mayor corresponda a una clasificación más alta (es decir, a vectores más cercanos).

Distancia L1

La distancia L1, también llamada distancia de Manhattan, de dos vectores y se mide sumando la diferencia absoluta por pares de todos sus elementos. Obviamente, cuanto menor sea la distancia , más cerca estarán los dos vectores. La fórmula de la distancia L1 (1) es bastante simple, como se puede ver a continuación:

Visualmente, la distancia L1 se puede ilustrar como se muestra en la imagen a continuación (en rojo):

Calculando la distancia L1 de los siguientes dos vectores y obtendría

Importante: Vale la pena señalar que la función de distancia L1 solo es compatible con la búsqueda vectorial exacta (también conocida como búsqueda de fuerza bruta) empleando la consulta DSL script_score, pero no para la búsqueda aproximada de kNN empleando la opción de búsqueda knno knn consulta DSL.

Distancia L2

La distancia L2, también llamada distancia euclidiana, de dos vectores y se mide sumando primero el cuadrado de la diferencia por pares de todos sus elementos y luego tomando la raíz cuadrada del resultado. Es básicamente el camino más corto entre dos puntos. De manera similar a L1, cuanto menor sea la distancia , más cerca estarán los dos vectores:

La distancia L2 se muestra en rojo en la siguiente imagen:

Reutilicemos los mismos dos vectores de muestra y que usamos para la distancia , y ahora podemos calcular la distancia como .

En cuanto al puntaje, cuanto menor es la distancia entre dos vectores, más cerca (es decir, más similares) están. Entonces, para derivar un puntaje, necesitamos invertir la medida de distancia, de modo que la distancia más pequeña produzca el puntaje más alta. La forma en que se calcula el puntaje cuando se usa la distancia L2 se ve como se muestra en la fórmula (3) a continuación:

Reutilizando los vectores de muestra del ejemplo anterior, su puntaje sería . Dos vectores que están muy cerca uno del otro se acercarán a un puntaje de 1, mientras que el puntaje de dos vectores que están muy lejos uno del otro tenderá hacia 0.

Terminando con las funciones de distancia L1 y L2, una buena analogía para compararlas es pensar en A y B como dos edificios en Manhattan, Nueva York. Un taxi que va de A a B tendría que manejar por el camino L1 (calles y avenidas), mientras que un pájaro probablemente usaría el camino L2 (línea recta).

Similitud de coseno

A diferencia de L1 y L2, la similitud del coseno no mide la distancia entre dos vectores y , sino su ángulo relativo, es decir, si ambos apuntan aproximadamente en la misma dirección. Cuanto mayor sea la similitud , menor será el ángulo entre los dos vectores y, por lo tanto, más "cercanos" están y "similar" es su significado transmitido.

Para ilustrar esto, pensemos en dos personas en la naturaleza que miran en diferentes direcciones. En la siguiente figura, la persona en azul mira en la dirección simbolizada por el vector y la persona en rojo en la dirección del vector . Cuanto más dirijan su vista hacia la misma dirección (es decir, cuanto más se acerquen sus vectores), más se superpondrá su campo de visión simbolizado por las áreas azul y roja. Cuánto se superpone su campo de visión es su similitud con el coseno. Sin embargo, tenga en cuenta que la persona B mira más lejos que la persona A (es decir, el vector es más largo). La persona B podría estar mirando una montaña lejana en el horizonte, mientras que la persona A podría estar mirando un árbol cercano. Para la similitud del coseno, eso no juega ningún papel, ya que solo se trata del ángulo.

Ahora calculemos esa similitud de coseno. La fórmula (4) es bastante simple, donde el numerador consiste en el producto punto de ambos vectores y el denominador contiene el producto de su magnitud (es decir, su longitud):

La similitud del coseno entre y se muestra en la imagen de abajo como una medida del ángulo entre ellos (en rojo):

Tomemos un desvío rápido para explicar qué significan concretamente estos valores de similitud de coseno. Como se puede ver en la imagen a continuación que muestra la función de coseno, los valores siempre oscilan en el intervalo

Recuerde que para que dos vectores se consideren similares, su ángulo debe ser lo más agudo posible, idealmente cerca de un ángulo de , lo que se reduciría a una similitud perfecta de . En otras palabras, cuando los vectores son...

1. ...cerca uno del otro, el coseno de su ángulo se acerca a (es decir, cerca de )

1. ...sin relación, el coseno de su ángulo se acerca a (es decir, cerca de )

1. ...opuesto, el coseno de su ángulo se acerca a (es decir, cerca de )

Ahora que sabemos cómo calcular la similitud del coseno entre dos vectores y tenemos una buena idea de cómo interpretar el valor resultante, podemos reutilizar los mismos vectores y y calcular su similitud de coseno usando la fórmula (4) que vimos anteriormente.

Obtenemos una similitud de coseno de , que está más cerca de que de , lo que significa que los dos vectores son algo similares, es decir, no perfectamente similares, pero tampoco completamente desrelacionados, y ciertamente no tienen un significado opuesto.

Para obtener un puntaje positivo de cualquier valor de similitud de coseno, necesitamos usar la siguiente fórmula (5), que transforma los valores de similitud de coseno que oscilan dentro del intervalo en puntajes en el intervalo

El puntaje para los vectores y sería: .

Similitud de productos Dot

Un inconveniente de la similitud del coseno es que solo tiene en cuenta el ángulo entre dos vectores pero no su magnitud, lo que significa que si dos vectores apuntan aproximadamente en la misma dirección pero uno es mucho más largo que el otro, ambos se considerarán similares. La similitud de producto punto, también llamada similitud de producto escalar o interno, mejora eso al tener en cuenta tanto el ángulo como la magnitud de los vectores, lo que proporciona una métrica de similitud más precisa. Para hacer que la magnitud de los vectores sea irrelevante, la similitud del producto punto requiere que los vectores se normalicen primero, por lo que, en última instancia, solo estamos comparando vectores de longitud unitaria 1.

Intentemos ilustrar esto nuevamente con las mismas dos personas que antes, pero esta vez, las colocamos en el medio de una habitación circular, de modo que su alcance visual sea exactamente el mismo (es decir, el radio de la habitación). De manera similar a la similitud del coseno, cuanto más volteen hacia la misma dirección (es decir, cuanto más se acerquen sus vectores), más se superpondrá su campo de visión. Sin embargo, al contrario de la similitud del coseno, ambos vectores tienen la misma longitud y ambas áreas tienen la misma superficie, lo que significa que las dos personas miran exactamente la misma imagen ubicada a la misma distancia. La superposición de esas dos áreas denota su similitud de producto punto.

Antes de introducir la fórmula de similitud de producto punto, veamos rápidamente cómo se puede normalizar un vector. Es bastante simple y se puede hacer en dos pasos triviales:

1. calcular la magnitud del vector

2. Divida cada componente por la magnitud obtenida en 1.

Como ejemplo, tomemos el vector . Podemos calcular su magnitud como vimos anteriormente al revisar la similitud del coseno, es decir, . Luego, dividiendo cada componente del vector por su magnitud, obtenemos el siguiente vector estandarizado :

Pasar por el mismo proceso para el segundo vector obtendría el siguiente vector estandarizado :

Para derivar la fórmula de similitud de producto punto, podemos calcular la similitud de coseno entre nuestros vectores estandarizados y usando la fórmula (4), como se muestra a continuación:

Y dado que la magnitud de ambos vectores estandarizados es ahora , la fórmula de similitud del producto punto (6) simplemente se convierte en... Lo adivinaste, un producto punto de ambos vectores estandarizados:

En la imagen a continuación, mostramos los vectores estandarizados y y podemos ilustrar su similitud de producto punto como la proyección de un vector sobre el otro (en rojo).

Usando nuestra nueva fórmula (6), podemos calcular la similitud del producto punto de nuestros dos vectores estandarizados, lo que como era de esperar produce exactamente el mismo valor de similitud que el del coseno:

Al aprovechar la similitud de productos puntos, el puntaje se calcula de forma diferente en función de si los vectores contienen valores flotantes o de bytes. En el primer caso, el puntaje se calcula de la misma manera que para la similitud del coseno empleando la fórmula (7) a continuación:

Sin embargo, cuando el vector se compone de valores de bytes, el puntaje se calcula de manera un poco diferente, como se muestra en la fórmula (8) a continuación, donde es el número de dimensiones del vector:

Además, una restricción para obtener puntajes precisos es que todos los vectores, incluido el vector de consulta, deben tener la misma longitud, pero no necesariamente 1.

Máxima similitud interna del producto

Desde la versión 8.11, hay una nueva función de similitud que está menos restringida que la similitud del producto punto, ya que no es necesario normalizar los vectores. La razón principal de esto se explica en detalle en el siguiente artículo, pero para resumirlo muy brevemente, ciertos conjuntos de datos no están muy bien adaptados a tener sus vectores estandarizados (por ejemplo, incrustaciones coherentes) y hacerlo puede causar problemas de relevancia.

La fórmula para calcular la similitud máxima del producto interno es exactamente la misma que la del producto punto (6). Lo que cambia es la forma en que se calcula el puntaje escalando la similitud máxima del producto interno empleando una función por partes cuya fórmula depende de si la similitud es positiva o negativa, como se muestra en la fórmula (9) a continuación:

Lo que hace esta función por partes es que escala todos los valores negativos de similitud del producto interno máximo en el intervalo y todos los valores positivos en el intervalo .

En resumen

Fue un gran viaje, matemáticamente hablando, pero aquí hay algunas conclusiones que pueden resultarle útiles.

La función de similitud que puede usar, en última instancia, depende de si sus incrustaciones vectoriales están normalizadas o no. Si sus vectores ya están estandarizados o si su conjunto de datos es independiente de la normalización de vectores (es decir, la relevancia no se verá afectada), puede continuar y normalizar sus vectores y usar la similitud de producto punto, ya que es mucho más rápido de calcular que el de coseno ya que no es necesario calcular la longitud de cada vector. Al comparar millones de vectores, esos cálculos pueden sumar bastante.

Si los vectores no están estandarizados, tiene dos opciones:

1. Use la similitud de coseno si normalizar sus vectores no es una opción

2. use la nueva similitud de producto interno máximo si desea que la magnitud de sus vectores contribuya al puntaje porque tienen significado (por ejemplo, incrustaciones coherentes)

En este punto, calcular la distancia o similitud entre las incrustaciones vectoriales y cómo derivar sus puntajes debería tener sentido para usted. Esperamos que este artículo le resultó útil.

Hay una distinción entre inspiración y parafraseo. Es posible leer un contenido, inspirar y luego explorar la idea con tus propias palabras, incluso si llegas a una conclusión similar.

Aunque el plagio fue un tema de debate durante mucho tiempo, el aceleramiento de la producción y publicación de contenido lo mantuvo relevante y supuso un desafío constante.

Este desafío no se limita a libros, investigaciones académicas o documentos judiciales, donde con frecuencia se realizan comprobaciones de plagio. También puede extender a los periódicos e incluso a las redes sociales.

Con la abundancia de información y el fácil acceso a la publicación, ¿cómo se puede controlar el plagio de forma eficaz a un nivel escalable?

Las universidades, entidades gubernamentales y compañías emplean herramientas diversas, pero aunque una búsqueda léxica sencilla puede detectar el plagio directo, el principal desafío radica en identificar contenido parafraseado.

Detección de plagio con IA generativa

Surge un nuevo reto con la IA generativa. ¿Se considera plagio el contenido generado por IA cuando se copia?

Los términos de uso de OpenAI, por ejemplo, especifican que OpenAI no reclamará derechos de autor sobre el contenido generado por la API para los usuarios. En este caso, las personas que usan su IA generativa pueden emplear el contenido generado como prefieran sin necesidad de citas.

Sin embargo, la aceptación del uso de IA generativa para mejorar la eficiencia sigue siendo un tema de debate.

En un esfuerzo por contribuir a la detección de plagio, OpenAI desarrolló un modelo de detección , pero más tarde reconoció que su precisión no es suficientemente alta.

"Creemos que esto no es lo suficientemente preciso para una detección independiente y debe combinar con enfoques basados en metadatos, juicio humano y educación pública para ser más efectivo."

El desafío persiste; sin embargo, con la disponibilidad de más herramientas, ahora hay más opciones para detectar plagio, incluso en casos de contenido parafraseado y de IA.

Detección de plagio con Elasticsearch

Reconociendo esto, en este blog exploramos un caso de uso más con los modelos de Procesamiento del Lenguaje Natural (PLN) y la búsqueda vectorial, la detección de plagio, más allá de las búsquedas de metadatos.

Esto se demuestra con ejemplos en Python, donde empleamos un conjunto de datos de SentenceTransformers que contiene artículos relacionados con el PLN. Comprobamos los resúmenes en busca de plagio realizando una 'similitud textual semántica' considerando incrustaciones 'abstractas' generadas con un modelo de incrustación de texto previamente importado a Elasticsearch. Además, para identificar contenido generado por IA — plagio por IA, también se importó un modelo de PLN desarrollado por OpenAI a Elasticsearch.

La siguiente imagen ilustra el flujo de datos:

Durante la tubería de ingesta con un procesador de inferencia, el párrafo 'abstracto' se mapea a un vector de 768 dimensiones, el 'valor_predicho abstract_vector.predicho'.

Cartografía:

La similitud entre representaciones vectoriales se mide mediante una métrica de similitud vectorial, definida mediante el parámetro de 'similitud'.

El coseno es la métrica de similitud por defecto, calculada como '(1 + coseno(consulta, vector)) / 2'. A menos que necesites preservar los vectores originales y no puedas normalizarlos de antemano, la forma más eficiente de realizar similitud coseno es normalizar todos los vectores a longitud unitaria. Esto ayuda a evitar realizar cálculos adicionales de longitud vectorial durante la búsqueda, y en su lugar emplea 'dot_product'.

En esta misma canalización, otro procesador de inferencia que contiene el modelo de clasificación de texto detecta si el contenido es 'real' probablemente escrito por humanos, o 'falso' probablemente escrito por IA, agregando el 'openai-detector.predicted_value' a cada documento.

Pipeline de ingestión:

En el momento de la consulta, también se emplea el mismo modelo de incrustación de texto para generar la representación vectorial de la consulta 'model_text' en un objeto 'query_vector_builder'.

Una búsqueda de k vecinos más cercanos (kNN) encuentra el k vector más cercano al vector de consulta medido por la métrica de similitud.

El _score de cada documento se deriva de la similitud, cerciorando que un puntaje mayor corresponda a una clasificación más alta. Esto significa que el documento es más similar semánticamente. Como resultado, imprimimos tres posibilidades: si el puntaje > 0,9, consideramos 'alta similitud'; si < 0,7, 'baja similitud', de lo contrario, 'similitud moderada'. Tienes la flexibilidad de establecer diferentes valores umbral para determinar qué nivel de _score califica como plagio o no, según tu caso de uso.

Además, se realiza la clasificación de texto para comprobar también la presencia de elementos generados por IA en la consulta de texto.

Consulta:

Salida:

En este ejemplo, tras emplear uno de los valores 'abstractos' de nuestro conjunto de datos como consulta de texto 'model_text', se identificó plagio. El puntaje de similitud es 1,0, lo que indica un alto nivel de similitud: plagio directo. La consulta vectorizada y el documento no fueron reconocidos como contenido generado por IA, lo cual era de esperar.

Consulta:

Salida:

Al actualizar la consulta de texto 'model_text' con un texto generado por IA que transmite el mismo mensaje minimizando la repetición de palabras similares, la similitud detectada seguía siendo alta, pero el puntaje era de 0,9302529 en lugar de 1,0 — plagio de paráfrasis. También se esperaba que esta consulta, generada por IA, fuera detectada.

Por último, considerando la consulta de texto 'model_text' como texto sobre Elasticsearch, que no es un resumen de ninguno de estos documentos, la similitud detectada fue 0,68991005, lo que indica baja similitud según los valores umbral considerados.

Consulta:

Salida:

Aunque el plagio se identificó correctamente en la consulta de texto generada por IA, así como en casos de paráfrasis y contenido copiado directamente, navegar por el panorama de la detección de plagio implica reconocer diversos aspectos.

En el contexto de la detección de contenido generado por IA, exploramos un modelo que aporta una contribución valiosa. Sin embargo, es fundamental reconocer las limitaciones inherentes a la detección independiente, lo que requiere incorporar otros métodos para mejorar la precisión.

La variabilidad introducida por la elección de modelos de incrustación de texto es otra consideración. Diferentes modelos, capacitados con conjuntos de datos distintos, resultan en distintos niveles de similitud, lo que destaca la importancia de las incrustaciones de texto generadas.

Por último, en estos ejemplos, usamos el resumen del documento. Sin embargo, la detección de plagio suele implicar documentos grandes, por lo que es esencial abordar el reto de la longitud del texto. Es común que el texto supere el límite de tokens de un modelo, requiriendo segmentación en fragmentos antes de construir incrustaciones. Un enfoque práctico para manejar esto implica emplear estructuras anidadas con dense_vector.

Conclusión

En este blog, hablamos sobre los desafíos de detectar plagio, especialmente en contenido parafraseado y generado por IA, y cómo la similitud textual semántica y la clasificación de texto pueden emplear para este propósito.

Combinando estos métodos, proporcionamos un ejemplo de detección de plagio donde identificamos con éxito contenido generado por IA, plagio directo y parafraseado.

El objetivo principal era establecer un sistema de filtrado que simplificara la detección, pero la evaluación humana sigue siendo esencial para la validación.

Si te interesa aprender más sobre similitud textual semántica y PNL, te animamos a que también consultes estos enlaces:

• ¿Qué es la búsqueda semántica?

• ¿Qué es el procesamiento del lenguaje natural (PLN)?

• Búsqueda léxica y semántica con Elasticsearch

• Fragmentar documentos grandes mediante pipelines de ingesta más vectores anidados equivale a una búsqueda de pasajes fácil

Prerrequisitos

Al igual que en la primera parte de este serial, se requieren los siguientes requisitos previos para este ejemplo:

1. Instalación de Go versión 1.21 o posterior

2. Crea tu propio repositorio de Go usando la estructura recomendada y la gestión de paquetes que se menciona en la documentación de Go

3. Creando tu propio clúster de Elasticsearch, poblado con un conjunto de páginas basadas en roedores, incluyendo nuestro amigable Gopher, de Wikipedia:

Conexión con Elasticsearch

Como recordatorio, en nuestros ejemplos emplearemos la API tipada que ofrece el cliente Go. Establecer una conexión segura para cualquier consulta requiere configurar al cliente usando cualquiera de:

1. ID de la nube y clave API si se emplea Elastic Cloud

2. URL del clúster, nombre de usuario, contraseña y el certificado

Conectarse a nuestro clúster ubicado en Elastic Cloud sería así:

La conexión client puede entonces emplear para búsqueda, como se demuestra en las secciones posteriores.

Impulso manual para búsqueda híbrida

Al combinar cualquier conjunto de algoritmos de búsqueda, el enfoque tradicional fue configurar manualmente las constantes para potenciar cada tipo de consulta. Específicamente, se especifica un factor para cada consulta, y el conjunto de resultados combinados se compara con el conjunto esperado para determinar la recuperación de la consulta. Luego repetimos para varios conjuntos de factores y elegimos el que esté más cerca de nuestro estado deseado.

Por ejemplo, combinar una consulta de búsqueda de texto individual potenciada por un factor de 0.8 con una consulta knn de menor factor de 0.2 puede hacer especificando el campo Boost en ambos tipos de consulta, como se muestra en el siguiente ejemplo:

El factor especificado en la opción de Boost para cada consulta se suma al puntaje del documento. Al aumentar el puntaje de nuestra consulta de coincidencia en un factor mayor que la consulta knn, los resultados de la consulta por palabra clave tienen un peso más fuerte.

El reto del aumento manual, especialmente si no eres un experto en búsquedas, es que requiere ajuste para identificar los factores que manejarán al conjunto de resultados deseado. Simplemente se trata de probar valores aleatorios para ver qué te acerca más al conjunto de resultados deseado.

Fusión de rangos recíprocos en un cliente híbrido de búsqueda y Go

Reciprocal Rank Fusion, o RRF, se publicó en formato de vista previa técnica para búsqueda híbrida en Elasticsearch 8.9. Su objetivo es reducir la curva de aprendizaje asociada al ajuste y disminuir el tiempo dedicado a experimentar con factores para optimizar el conjunto de resultados.

Con RRF, el puntaje del documento se recalcula mezclando los puntajes mediante el siguiente algoritmo:

El beneficio de usar RRF es que podemos aprovechar los valores predeterminados sensatos dentro de Elasticsearch. La constante de clasificación k por defecto es 60. Para proporcionar un equilibrio entre la relevancia de los documentos devueltos y el rendimiento de la consulta al buscar sobre grandes conjuntos de datos, el tamaño del conjunto de resultados para cada consulta considerada se limita al valor de window_size, que por defecto es 100 según se indica en la documentación.

k y windows_size también pueden configurar dentro de la configuración Rrf dentro del método Rank en el cliente Go, como se muestra en el siguiente ejemplo:

Conclusión

Aquí hablamos de cómo combinar la búsqueda vectorial y la búsqueda por palabras clave en Elasticsearch usando el cliente Elasticsearch Go.

Echa un vistazo al repositorio de GitHub para ver todo el código de este serial. Si no lo hiciste ya, echa un vistazo a la parte 1 y la parte 2 para ver todo el código de este serial.

¡Feliz caza de topos!

Recursos

1. Guía Elasticsearch

2. Cliente Elasticsearch Go

3. ¿Qué es la búsqueda vectorial? | Elástico

4. Fusión recíproca de rangos

Al igual que los animales, los lenguajes de programación y tu autor amable, la búsqueda experimentó una evolución de diferentes prácticas que pueden ser difíciles de elegir para tu propio caso de uso. En este blog, compartiremos una visión general de la búsqueda vectorial junto con ejemplos de cada enfoque usando Elasticsearch y el cliente Elasticsearch Go. Estos ejemplos te mostrarán cómo encontrar topos y determinar qué comen usando búsqueda vectorial en Elasticsearch y Go.

Prerrequisitos

Para seguir con este ejemplo, cerciorar de cumplir los siguientes requisitos:

1. Instalación de Go versión 1.21 o posterior

2. Creación de tu propio repositorio Go con el

3. Creación de tu propio clúster Elasticsearch, poblado con un conjunto de páginas basadas en roedores, incluyendo para nuestro amable Gopher, de Wikipedia:

Conexión con Elasticsearch

En nuestros ejemplos, emplearemos la API tipada que ofrece el cliente Go. Establecer una conexión segura para cualquier consulta requiere configurar al cliente usando cualquiera de:

1. Cloud ID y clave API si se emplea Elastic Cloud.

2. URL del clúster, nombre de usuario, contraseña y el certificado.

Conectarse a nuestro clúster ubicado en Elastic Cloud sería así:

La conexión client puede entonces emplear para búsqueda vectorial, como se muestra en secciones posteriores.

Búsqueda de vectores

La búsqueda vectorial intenta resolver este problema convirtiendo el problema de búsqueda en una comparación matemática usando vectores. El proceso de incrustación de documentos tiene una etapa adicional de convertir el documento usando un modelo en una representación vectorial densa, o simplemente en un flujo de números. El beneficio de este enfoque es que puedes buscar documentos no textuales, como imágenes y audio, traduciéndolos a un vector junto con una consulta.

En términos simples, la búsqueda vectorial es un conjunto de cálculos de distancia vectorial. En la ilustración siguiente, la representación vectorial de nuestro Go Gopherde consulta se compara con los documentos en el espacio vectorial, y se devuelven los resultados más cercanos (denotados por kconstantes):

Dependiendo del método que se emplee para generar los embeddings de tus documentos, hay dos formas diferentes de saber qué comen los topos.

Enfoque 1: Trae tu propio modelo

Con una licencia Platinum, es posible generar las incrustaciones dentro de Elasticsearch subiendo el modelo y usando la API de inferencia. Hay seis pasos implicados para establecer el modelo:

1. Selecciona un modelo de PyTorch para subirlo desde un repositorio de modelos. Para este ejemplo, estamos usando los transformadores de frase/msmarco-MiniLM-L-12-v3 de Hugging Face para generar los embeddings.

2. Carga el modelo en Elastic usando el cliente Eland Machine Learning para Python usando las credenciales de nuestro clúster Elasticsearch y tipo de tarea text_embeddings. Si no tienes Eland instalado, puedes ejecutar el paso de importación usando Docker, como se muestra a continuación:

1. Una vez cargado, prueba rápidamente el sentence-transformers__msmarco-minilm-l-12-v3 del modelo con un documento de muestra para cerciorarte de que las incrustaciones se generan como se espera:

1. Crear una tubería de ingesta que contenga un procesador de inferencia. Esto permitirá generar la representación vectorial usando el modelo subido:

1. Crea un nuevo índice que contenga el text_embedding.predicted_value de campo de tipo dense_vector para almacenar las incrustaciones vectoriales generadas para cada documento:

1. Reindexa los documentos usando la nueva tubería de ingesta para generar las incrustaciones de texto como el campo adicional text_embedding.predicted_value en cada documento:

Ahora podemos usar la opción Knn en la misma API de búsqueda usando el nuevo índice vector-search-rodents, como se muestra en el siguiente ejemplo:

La conversión del objeto de resultado JSON mediante desmaravillamiento se realiza exactamente de la misma manera que en el ejemplo de búsqueda por palabra clave. Las constantes K y NumCandidates nos permiten configurar el número de documentos vecinos que devolver y el número de candidatos a considerar por fragmento. Ten en cuenta que aumentar el número de candidatos incrementa la precisión de los resultados pero conduce a una consulta de mayor duración a medida que se realizan más comparaciones.

Cuando el código se ejecuta usando la consulta What do Gophers eat?, los resultados devuelto se ven similares a los siguientes, destacando que el artículo de Gopher contiene la información aplicar, a diferencia de la búsqueda por palabra clave anterior:

Enfoque 2: API de inferencia de rostros de abrazo

Otra opción es generar estas mismas incrustaciones fuera de Elasticsearch e ingerirlas como parte de tu documento. Como esta opción no emplea un nodo de aprendizaje automático de Elasticsearch, puede hacer en la capa libre.

Hugging Face expone una API de inferencia gratis y limitada a la velocidad que, con una cuenta y un token de API, puede usar para generar manualmente las mismas incrustaciones para experimentación y prototipado que te ayude a empezar. No se recomienda para uso en producción. Invocar tus propios modelos localmente para generar embeddings o usar la API de pago también puede hacer con un enfoque similar.

En la función GetTextEmbeddingForQuery siguiente usamos la API de inferencia contra nuestra cadena de consulta para generar el vector devuelto de una petición POST al punto final:

El vector resultante, de tipo []float32 , se pasa entonces como QueryVector en lugar de usar la opción QueryVectorBuilder para aprovechar el modelo previamente subido a Elastic.

Cabe señalar que las opciones de K y NumCandidates siguen siendo las mismas independientemente de las dos opciones y que se generan los mismos resultados, ya que estamos usando el mismo modelo para generar las incrustaciones

Conclusión

Aquí discutimos cómo realizar búsqueda vectorial en Elasticsearch usando el cliente Elasticsearch Go. Echa un vistazo al repositorio de GitHub para ver todo el código de este serial. Sigue la parte 3 para obtener una visión general de cómo combinar la búsqueda vectorial con las capacidades de búsqueda por palabras clave que se tratan en la primera parte de Go.

Hasta entonces, ¡feliz caza de topos!

Recursos

1. Guía Elasticsearch

2. Cliente Elasticsearch Go

3. ¿Qué es la búsqueda vectorial? | Elástico

Teniendo en cuenta este objetivo, en esta entrada de blog exploraremos diferentes enfoques para recuperar información usando Elasticsearch, con un enfoque específico en la búsqueda de texto: búsqueda léxica y semántica.

Prerrequisitos

Para lograrlo, proporcionaremos ejemplos en Python que demuestren diversos escenarios de búsqueda en un conjunto de datos generado para simular información de productos de comercio electrónico.

Este conjunto de datos contiene más de 2.500 productos, cada uno con una descripción. Estos productos se clasifican en 76 categorías distintas, cada una conteniendo un número variable de productos, como se muestra a continuación:

Visualización de treemap: 22 valores principales de category.keyword (categorías de productos)

Para la configuración necesitarás:

• Python 3.6 o posterior

• El cliente Python Elástico

• Despliegue Elastic 8.8 o posterior, con nodo de aprendizaje automático de 8GB de memoria

• El modelo Elastic Learned Sparse EncodeR , que viene preinstalado en Elastic, se instaló y comenzó en tu despliegue

Usaremos Elastic Cloud, hay una prueba gratis disponible.

Además de las consultas de búsqueda que se proporcionan en esta entrada del blog, un cuaderno de Python te guiará a través de los siguientes procesos:

• Establece una conexión con nuestro despliegue de Elastic usando el cliente de Python

• Carga un modelo de incrustación de texto en el clúster de Elasticsearch

• Crea un índice con mapeos para indexar vectores de características y vectores densos.

• Crear una tubería de ingesta con procesadores de inferencia para incrustación y expansión de texto

Búsqueda léxica - recuperación dispersa

La forma tradicional en que los documentos se clasifican para relevancia según Elasticsearch basar en una consulta de texto emplea la implementación Lucene del modelo BM25 , un modelo disperso para la búsqueda léxica. Este método sigue el enfoque tradicional de búsqueda de texto, buscando coincidencias exactas de términos.

Para hacer posible esta búsqueda, Elasticsearch convierte los datos de los campos de texto en un formato buscable mediante análisis de texto.

El análisis de texto se realiza mediante un analizador, un conjunto de reglas que regulan el proceso de extracción de tokens relevantes para la búsqueda. Un analizador debe tener exactamente un tokenizador. El tokenizador recibe una secuencia de caracteres y la divide en fichas individuales (normalmente palabras individuales), como en el ejemplo siguiente:

Tokenización de cadenas para búsqueda léxica

Salida

En este ejemplo estamos usando el analizador por defecto, el analizador estándar , que funciona bien para la mayoría de los casos de uso ya que proporciona tokenización basada en gramática inglesa. La tokenización permite la coincidencia en términos individuales, pero cada token sigue siendo emparejado literalmente.

Si quieres personalizar tu experiencia de búsqueda, puedes elegir otro analizador integrado diferente. Por ejemplo, actualizando el código para usar el analizador de atajada , se descompone el texto en tokens en cualquier carácter que no sea letra, con soporte para eliminar palabras de atajada.

Salida

Cuando los analizadores integrados no satisfacen tus necesidades, puedes crear un analizador personalizado, que emplee la combinación adecuada de filtros de cero o más caracteres, un tokenizador y filtros de cero o más tokens.

En el ejemplo anterior, que combina un tokenizador y filtros de token, el texto se pondrá en minúsculas con el filtro minúsculo antes de ser procesado por el filtro de sinónimos.

Emparejamiento léxico

BM25 medirá la relevancia de los documentos para una consulta de búsqueda determinada en función de la frecuencia de los términos y su importancia.

El código siguiente realiza una consulta de coincidencia, buscando hasta dos documentos que consideren los valores del campo "descripción" del índice "ecommerce-search" y la consulta de búsqueda "Muebles cómodos para un balcón grande".

Refinar los criterios para que un documento se considere compatible con esta consulta puede mejorar la precisión. Sin embargo, los resultados más específicos tienen el costo de una menor tolerancia a las variaciones.

Salida

Analizando el resultado, el resultado más relevante es el producto "Barbie Dreamhouse", en la categoría "Juguetes", y su descripción es muy relevante ya que incluye los términos "muebles", "grande" y "balcón";este es el único producto con 3 términos en la descripción que coinciden con la consulta de búsqueda, El producto es también el único que tiene el término "balcón" en la descripción.

El segundo producto más relevante es una "Mecedora Cómoda" categorizada como "Mobiliario de Interior" y su descripción incluye los términos "cómodo" y "mueble". Solo 3 productos en el conjunto de datos coinciden con al menos 2 términos de esta consulta de búsqueda, este producto es uno de ellos.

"Cómodo" aparece en la descripción de 105 productos y "muebles" en la descripción de 4 productos con 4 categorías diferentes: Juguetes, Muebles de interior, Muebles de exterior y 'Suministros y Juguetes para perros y gatos'.

Como puedes ver, el producto más relevante para la pregunta es un juguete y el segundo producto más relevante son los muebles de interior. Si quieres información detallada sobre el cálculo de puntaje para saber por qué estos documentos coinciden, puedes poner el parámetro de explicación __query en verdadero.

A pesar de que ambos resultados son los más relevantes, considerando tanto el número de documentos como la presencia de términos en este conjunto de datos, la intención detrás de la consulta "Cómodos muebles para un balcón grande" es buscar muebles para un balcón grande real, excluyendo, entre otros, juguetes y muebles de interior.

La búsqueda léxica es relativamente sencilla y rápida, pero tiene limitaciones ya que no siempre es posible conocer todos los términos y sinónimos posibles sin necesariamente conocer la intención y las consultas del usuario. Un fenómeno común en el uso del lenguaje natural es la desadaptación del vocabulario. Las investigaciones muestran que, de media, el 80% de las veces diferentes personas (expertos en el mismo campo) nombran el mismo nombre de forma distinta.

Estas limitaciones nos motivan a buscar otros modelos de puntaje que incorporen conocimientos semánticos. Los modelos basados en transformadores, que destacan en el procesamiento de tokens de entrada secuenciales como el lenguaje natural, capturan el significado subyacente de tu búsqueda considerando representaciones matemáticas tanto de documentos como de consultas. Esto permite una representación vectorial densa y consciente del contexto del texto, impulsando la Búsqueda Semántica, una forma refinada de encontrar contenido relevante.

Búsqueda semántica - recuperación densa

En este contexto, tras convertir tus datos en valores vectoriales significativos, se emplea el algoritmo de búsqueda de k-vecinos más cercanos (kNN) para encontrar representaciones vectoriales en un conjunto de datos que sean más similares a un vector de consulta. Elasticsearch soporta dos métodos para la búsqueda en kNN: kNN exacto de fuerza bruta y kNN aproximado, también conocido como ANN.

La kNN de fuerza bruta garantiza resultados precisos pero no escala bien con grandes conjuntos de datos. El kNN aproximado encuentra eficientemente a los vecinos más cercanos sacrificando cierta precisión para mejorar el rendimiento.

Con el soporte de Lucene para la búsqueda kNN y los índices vectoriales densos, Elasticsearch aprovecha el algoritmo Hierarchical Navigable Small World (HNSW), que demuestra un rendimiento estable en búsquedas en una variedad de conjuntos de datos ann-benchmark. Se puede realizar una búsqueda aproximada de kNN en Python usando el código de ejemplo siguiente.

Búsqueda semántica con kNN aproximado

Este bloque de código emplea kNN de Elasticsearch para devolver hasta dos productos con una descripción similar a la consulta vectorizada (query_vector_build) de "Cómodo mobiliario para un balcón grande" considerando las incrustaciones del campo "descripción" en el conjunto de datos de productos.

Las incrustaciones de productos se generaban previamente en una tubería de ingesta con un procesador de inferencia que contenía el modelo de incrustación de texto "all-mpnet-base-v2" para inferir contra los datos que se estaban ingeriendo en la canalización.

Este modelo se eligió basar en la evaluación de modelos preentrenados usando "sentence_transformers.evaluation" donde se emplean diferentes clases para evaluar un modelo durante el entrenamiento. El modelo "all-mpnet-base-v2" mostró el mejor rendimiento medio según la clasificación de Sentence-Transformers y también cercioró una posición favorable en la tabla de clasificación del Massive Text Embedding Benchmark (MTEB ). El modelo preentrenado es Microsoft y mpnet-base y ajustado finamente en un conjunto de datos de pares de oraciones de 1B, que mapea oraciones a un espacio vectorial denso de 768 dimensiones.

Alternativamente, existen muchos otros modelos disponibles que se pueden emplear, especialmente aquellos ajustados para los datos específicos de tu dominio.

Salida

La salida puede variar según el modelo elegido, los filtros y la afinación aproximada de kNN.

Los resultados de búsqueda de kNN están ambos en la categoría de "Muebles de exterior", aunque la palabra "exterior" no se mencionó explícitamente en la consulta, lo que resalta la importancia de la comprensión semántica en este contexto.

La búsqueda vectorial densa ofrece varios beneficios:

• Activación de la búsqueda semántica

• Escalabilidad para manejar conjuntos de datos muy grandes

• Flexibilidad para manejar una amplia variedad de tipos de datos

Sin embargo, la búsqueda vectorial densa también conlleva sus propios desafíos:

• Seleccionar el modelo de incrustación adecuado para tu caso de uso

• Una vez elegido un modelo, puede ser necesario ajustarlo para optimizar el rendimiento en un conjunto de datos específico de un dominio, un proceso que requiere la participación de expertos en el dominio

• Además, indexar vectores de alta dimensión puede ser computacionalmente costoso

Búsqueda semántica - recuperación escasa aprendida

Exploremos un enfoque alternativo: la recuperación esparsa aprendida, otra forma de realizar búsqueda semántica.

Como modelo escaso, emplea el índice invertido basado en Lucene de Elasticsearch, que se beneficia de décadas de optimizaciones. Sin embargo, este enfoque va más allá de simplemente agregar sinónimos con funciones de puntaje léxico como BM25. En su lugar, incorpora asociaciones aprendidas empleando un conocimiento más profundo a escala del lenguaje para optimizar su relevancia.

Al ampliar las consultas de búsqueda para incluir términos relevantes que no están presentes en la consulta original, el Codificador Escaso Aprendido Elástico mejora las incrustaciones vectoriales dispersas, como puedes ver en el ejemplo siguiente.

Búsqueda vectorial dispersa con codificador elástico aprendido de dispersión

Salida

Los resultados en este caso incluyen la categoría "Muebles de jardín", que ofrece productos bastante similares a los "Muebles de Exterior".

Analizando "ml.tokens", el campo "rank_features" que contiene tokens generados por Recuperación Escasa Aprendida, se hace evidente que entre los diversos tokens generados hay términos que, aunque no forman parte de la consulta de búsqueda, siguen siendo relevantes en su significado, como "relax" (cómodo), "sofá" (muebles) y "exterior" (balcón).

La imagen de abajo destaca algunos de estos términos junto con la consulta, tanto con como sin ampliación de términos.

Como se observó, este modelo proporciona una búsqueda consciente del contexto y ayuda a mitigar el problema de la descoordinación de vocabulario, a la vez que proporciona resultados más interpretables. Incluso puede superar a los modelos vectoriales densos cuando no se aplica un reentrenamiento específico de dominio.

Búsqueda híbrida: resultados relevantes combinando la búsqueda léxica y semántica

Cuando se trata de búsqueda, no hay una solución universal. Cada uno de estos métodos de recuperación tiene sus fortalezas pero también sus desafíos. Dependiendo del caso de uso, la mejor opción puede cambiar. A menudo, los mejores resultados entre los métodos de recuperación pueden ser complementarios. Por tanto, para mejorar la relevancia, veremos la combinación de las fortalezas de cada método.

Existen múltiples formas de implementar una búsqueda híbrida, incluyendo la combinación lineal, que da un peso a cada puntaje y la fusión recíproca de rangos (RRF), donde no es necesario especificar un peso.

Elasticsearch: lo mejor de ambos mundos con búsqueda léxica y semántica

En este código, realizamos una búsqueda híbrida con dos consultas que tenían el valor "Una mesa de comedor y sillas cómodas para un balcón grande". En lugar de usar "muebles" como término de búsqueda, especificamos lo que buscamos, y ambas búsquedas consideran los mismos valores de campo, "descripción". La clasificación se determina mediante una combinación lineal con el mismo peso para los puntajes BM25 y ELSER.

Salida

En el código siguiente, usaremos el mismo valor para la consulta, pero combinaremos los puntajes de BM25 (parámetro de consulta) y kNN (parámetro knn) usando el método de fusión de rangos recíprocos para combinar y clasificar los documentos.

La funcionalidad de RRF está en vista previa técnica. La sintaxis probablemente cambiará antes de GA.

Salida

Aquí también podríamos usar diferentes campos y valores; algunos de estos ejemplos están disponibles en el cuaderno de Python.

Como puedes ver, con Elasticsearch tienes lo mejor de ambos mundos: la búsqueda léxica tradicional y la búsqueda vectorial, ya sea escasa o densa, para alcanzar tu objetivo y encontrar la mejor respuesta posible a tu pregunta.

Si quieres seguir aprendiendo sobre los enfoques mencionados aquí, estos blogs pueden ser útiles:

• Mejorar la recuperación de información en el Elastic Stack: Recuperación híbrida

• Búsqueda vectorial en Elasticsearch: La razón detrás del diseño

• Cómo obtener lo mejor de la búsqueda léxica y basada en IA con la base de datos vectorial de Elastic

• Presentamos Elastic Learned Sparse Encoder: el modelo de IA de Elastic para búsqueda semántica

• Mejorando la recuperación de información en el Elastic Stack: Presentamos Elastic Learned Sparse Encoder, nuestro nuevo modelo de recuperación

Elasticsearch proporciona una base de datos vectorial, junto con todas las herramientas que necesitas para construir la búsqueda vectorial:

• Base de datos de vectoresElasticsearch

• Casos de uso de búsqueda vectorial con Elastic

Conclusión

En esta entrada del blog, exploramos varios enfoques para recuperar información usando Elasticsearch, centrándonos específicamente en la búsqueda textual, léxica y semántica. Para demostrarlo, proporcionamos ejemplos en Python que muestran diferentes escenarios de búsqueda empleando un conjunto de datos que contiene información de productos de comercio electrónico.

Revisamos la búsqueda léxica tradicional con BM25 y discutimos sus beneficios y desafíos, como la descoordinación del vocabulario. Destacamos la importancia de incorporar el conocimiento semántico para superar este problema. Además, hablamos sobre la búsqueda vectorial densa, que permite la búsqueda semántica, y abordamos los retos asociados a este método de recuperación, incluyendo el costo computacional al indexar vectores de alta dimensión.

Por otro lado, mencionamos que los vectores dispersos comprimen excepcionalmente bien. Por ello, hablamos del Learned Sparse Encoder de Elastic, que amplía las consultas de búsqueda para incluir términos relevantes que no estaban presentes en la consulta original.

No existe una solución única para todos en cuanto a búsqueda. Cada método de recuperación tiene sus fortalezas y desafíos. Por ello, también discutimos el concepto de búsqueda híbrida.

Como puedes ver, con Elasticsearch puedes tener lo mejor de ambos mundos: ¡búsqueda léxica tradicional y búsqueda vectorial!

¿Listo para empezar? Consulta el cuaderno Python disponible y comienza una prueba gratis de Elastic Cloud.

A medida que avanza la tecnología, los chatbots se emplean para gestionar tareas más complejas —y de forma rápida— sin dejar de ofrecer una experiencia personalizada para los usuarios. El procesamiento del lenguaje natural (PLN) permite a los chatbots procesar el lenguaje del usuario, identificar la intención detrás de su mensaje y extraer información relevante de él. Por ejemplo, el Reconocimiento de Entidades Nombradas extrae información clave de un texto clasificándolos en un conjunto de categorías. El análisis de sentimiento identifica el tono emocional y la pregunta responde a la "respuesta" a una consulta. El objetivo del PLN es permitir que los algoritmos procesen el lenguaje humano y realicen tareas que históricamente solo los humanos eran capaces de realizar, como encontrar pasajes relevantes entre grandes cantidades de texto, resumir textos y generar contenido nuevo y original.

Estas avanzadas capacidades de PLN se basan en una tecnología conocida como búsqueda vectorial. Elastic tiene soporte nativo para búsqueda vectorial, realizando búsqueda exacta y aproximada de k-nearest neighbor (kNN), y para NLP, permitiendo el uso directo de modelos personalizados o de terceros en Elasticsearch.

En esta entrada del blog, exploraremos cómo la búsqueda vectorial y el PLN mejoran las capacidades de los chatbots y demostraremos cómo Elasticsearch facilita este proceso. Empecemos con una breve visión general de la búsqueda vectorial.

Búsqueda de vectores

Aunque los humanos pueden comprender el significado y el contexto del lenguaje escrito, las máquinas no pueden hacer lo mismo. Aquí es donde entran los vectores. Al convertir el texto en representaciones vectoriales (representaciones numéricas del significado del texto), las máquinas pueden superar esta limitación. En comparación con una búsqueda tradicional, en lugar de depender de palabras clave y búsqueda léxica basada en frecuencias, los vectores permiten el proceso de datos textuales mediante operaciones definidas para valores numéricos.

Esto permite la búsqueda vectorial localizar datos que comparten conceptos o contextos similares empleando distancias en el "espacio de incrustación" para representar similitud dado un vector de consulta. Cuando los datos son similares, los vectores correspondientes serán iguales.

La búsqueda vectorial no solo se emplea en aplicaciones de PLN, sino que también se emplea en varios otros ámbitos donde se involucran datos no estructurados, incluyendo el procesamiento de imágenes y video.

En un flujo de chatbot, puede haber varios enfoques para las consultas de los usuarios y, como resultado, existen diferentes formas de mejorar la recuperación de información para una mejor experiencia de usuario. Dado que cada alternativa tiene su propio conjunto de beneficios y posibles desventajas, es esencial tener en cuenta los datos y recursos disponibles, así como el tiempo de entrenamiento (cuando corresponda) y la precisión esperada. En la siguiente sección, trataremos estos aspectos para modelos de PLN con preguntas frecuentes.

Preguntas frecuentes

Un modelo de preguntas frecuentes (QA) es un tipo de modelo de PLN diseñado para responder preguntas formuladas en lenguaje natural. Cuando los usuarios tienen preguntas que requieren inferir respuestas a partir de múltiples fuentes, sin una respuesta objetivo preexistente disponible en los documentos, los modelos de QA generativa pueden ser útiles. Sin embargo, estos modelos pueden ser computacionalmente costosos y requieren grandes cantidades de datos para el entrenamiento relacionado con el dominio, lo que puede hacerlos menos prácticos en algunas situaciones, aunque este método puede ser especialmente valioso para tratar preguntas fuera del dominio.

Por otro lado, cuando los usuarios tienen preguntas sobre un tema específico y la respuesta real está presente en el documento, se pueden emplear modelos extractivos de control de calidad. Estos modelos extraen directamente la respuesta del documento fuente, proporcionando resultados transparentes y verificables, lo que los convierte en una opción más práctica para compañías u organizaciones que desean ofrecer una forma sencilla y eficiente de responder a sus preguntas.

El ejemplo siguiente demuestra el uso de un modelo extractivo de control de calidad preentrenado, disponible en Hugging Face y desplegado en Elasticsearch, para extraer respuestas de un contexto dado:

Despliega modelos capacitados.

Agrega un modelo a una tubería de ingestión de inferencia.

Existen varias formas de gestionar consultas de usuarios y recuperar información, y emplear múltiples modelos de lenguaje y fuentes de datos puede ser una alternativa eficaz al tratar con datos no estructurados. Para ilustrar esto, tenemos un ejemplo del procesamiento de datos de un chatbot empleado para responder a consultas con respuestas que consideran datos extraídos de documentos seleccionados.

Procesamiento de datos en chatbots: PLN y búsqueda vectorial

Como se mostró anteriormente, el procesamiento de datos para nuestro chatbot puede dividir en tres partes:

• Procesamiento vectorial: Esta parte convierte documentos en representaciones vectoriales.

• Procesamiento de entrada por parte del usuario: Esta parte extrae información relevante de la consulta del usuario y realiza búsqueda semántica y recuperación híbrida.

• Optimización: Esta parte incluye la monitorización y es fundamental para garantizar la fiabilidad del chatbot, su rendimiento óptimo y una excelente experiencia de usuario.

Procesamiento vectorial

Para la parte de procesamiento , el primer paso es determinar las partes componentes de cada documento para luego convertir cada elemento a una representación vectorial; Estas representaciones pueden crear para una amplia variedad de formatos de datos.

Existen varios métodos que pueden usar para calcular incrustaciones, incluyendo modelos y bibliotecas preentrenadas.

Es importante señalar que la efectividad de la búsqueda y recuperación en estas representaciones depende de los datos existentes y de la calidad y relevancia del método empleado.

A medida que se calculan los vectores, se almacenan en Elasticsearch con un tipo de campo dense_vector .

Procesamiento de entrada de usuario en chatbots

Para el usuario , tras recibir una pregunta, es útil extraer toda la información posible antes de continuar. Esto ayuda a entender la intención del usuario y, en este caso, estamos empleando un modelo de Reconocimiento de Entidades Nombradas (NER) para ayudar con ello. NER es el proceso de identificar y clasificar entidades nombradas en categorías de entidades predefinidas.

Aunque no es un paso necesario, usando datos estructurados o el anterior u otro resultado de modelo NLP para categorizar la consulta del usuario, podemos restringir la búsqueda kNN usando un filtro. Esto ayuda a mejorar el rendimiento y la precisión al reducir la cantidad de datos que deben ser procesados.

Búsqueda semántica y recuperación híbrida

Dado que el prompt se origina en consultas de usuarios y el chatbot necesita procesar el lenguaje humano con su variabilidad y ambigüedad, la búsqueda semántica es una excelente opción. En Elasticsearch, puedes realizar búsqueda semántica en un solo paso pasando la cadena de consulta y el ID del modelo de incrustación a un objeto query_vector_builder. Esto vectorizará la consulta y realizará una búsqueda kNN para recuperar las k coincidencias principales que sean las más cercanas en significado a la consulta:

Ejemplo de extremo a extremo: Cómo desplegar un modelo de incrustación de texto y usarlo para búsqueda semántica. Elasticsearch emplea la implementación Lucene del Okapi BM25, un modelo disperso , para clasificar consultas de texto y determinar su relevancia, mientras que los modelos densos se emplean para la búsqueda semántica. Para combinar las fortalezas de ambos , coincidencias vectoriales y coincidencias obtenidas a partir de la consulta de texto, puedes realizar una recuperación híbrida :

Combinar modelos dispersos y densos suele dar los mejores resultados

Los modelos dispersos generalmente rinden mejor en consultas cortas y terminologías específicas, mientras que los modelos densos aprovechan el contexto y las asociaciones. Si quieres aprender más sobre cómo estos métodos se comparan y complementan, aquí comparamos BM25 con dos modelos densos que fueron capacitados específicamente para la recuperación.

El resultado más relevante suele ser la primera respuesta dada al usuario, el_score es un número usado para determinar la relevancia del documento devuelto.

Optimización de chatbots

Para ayudar a mejorar la experiencia del usuario, el rendimiento y la fiabilidad de tu chatbot, además de aplicar puntaje híbrido, puedes incorporar los siguientes enfoques: Análisis de Sentimiento: Para proporcionar conciencia de los comentarios y reacciones de los usuarios a medida que se desarrolla el diálogo, puedes incorporar un modelo de análisis de sentimiento:

Capacidades de GPT : Como alternativa para mejorar la experiencia global, puedes combinar la relevancia de búsqueda de Elasticsearch con las capacidades de respuesta a preguntas de GPT de OpenAI, empleando la API de Finalización de Chat para devolver a las respuestas generadas por el modelo de usuario considerando estos k primeros documentos como contexto. Prompt: "responder a esta pregunta <user_question> usando solo este documento <top_search_result>"

Observancia: Garantizar el rendimiento de cualquier chatbot es crucial, y la monitorización es un componente esencial para lograrlo. Además de los registros que capturan las interacciones con chatbots, es importante hacer un seguimiento del tiempo de respuesta, la latencia y otras métricas relevantes del chatbot. De este modo, puedes identificar patrones, tendencias e incluso detectar anomalías.Las herramientas de observabilidad elástica te permiten recopilar y analizar esta información.

Resumen

Esta entrada de blog explica qué son el PLN y la búsqueda vectorial y profundiza en un ejemplo de chatbot empleado para responder a consultas de usuarios considerando datos extraídos de la representación vectorial de documentos.

Como se demostró, usando PLN y búsqueda vectorial, los chatbots son capaces de realizar tareas complejas que van más allá de los datos estructurados y dirigidos. Esto incluye hacer recomendaciones y responder a consultas específicas relacionadas con productos o negocios empleando múltiples fuentes de datos y formatos como contexto, además de proporcionar una experiencia de usuario personalizada.

Los casos de uso van desde ofrecer atención al cliente ayudando a los clientes con sus consultas hasta ayudar a los desarrolladores con sus consultas, proporcionando orientación paso a paso, sugiriendo recomendaciones o incluso automatizando tareas. Dependiendo del objetivo y de los datos existentes, también se pueden emplear otros modelos y métodos para lograr resultados aún mejores y mejorar la experiencia global del usuario.

Aquí tienes algunos enlaces sobre el tema que pueden ser útiles:

1. Cómo desplegar el procesamiento de lenguaje natural (PLN): Comienzo

2. Resumen de la búsqueda por similitud de imágenes en Elasticsearch

3. ChatGPT y Elasticsearch: OpenAI se encuentra con datos privados

4. Monitoriza los modelos de OpenAI API y GPT con OpenTelemetry y Elastic

5. 5 razones por las que los líderes de TI necesitan la búsqueda vectorial para mejorar la experiencia de búsqueda

Al incorporar PLN y búsqueda vectorial nativa en Elasticsearch, puedes aprovechar su velocidad, escalabilidad y capacidades de búsqueda para crear chatbots altamente eficientes y eficaces, capaces de manejar grandes cantidades de datos, ya sean estructurados o no.

¿Listo para empezar? Comienza una prueba gratis de Elastic Cloud.

En esta entrada del blog, es posible que empleamos o podamos referirnos a herramientas de IA generativa de terceros, que son propiedad y están gestionadas por sus respectivos propietarios. Elastic no tiene ningún control sobre las herramientas de terceros y no tenemos responsabilidad ni responsabilidad por su contenido, funcionamiento o uso, ni por ninguna pérdida o daño que pueda surgir por su uso de dichas herramientas. Por favor, ten precaución al emplear herramientas de IA con información personal, sensible o confidencial. Cualquier dato que envíes puede usar para entrenamiento de IA u otros fines. No hay garantía de que la información que proporciones se mantenga segura o confidencial. Deberías familiarizarte con las prácticas de privacidad y los términos de uso de cualquier herramienta de IA generativa antes de emplearla.

Elastic, Elasticsearch y las marcas asociadas son marcas registradas, logotipos o marcas registradas de Elasticsearch N.V. en Estados Unidos y otros países. Todos los demás nombres de empresas y productos son marcas registradas, logotipos o marcas registradas de sus respectivos propietarios.

Esta publicación se centra en una técnica particular llamada búsqueda por similitud textual. En este tipo de búsqueda, un usuario introduce una consulta corta en texto libre, y los documentos se clasifican según su similitud con la consulta. La similitud de texto puede ser útil en una variedad de casos de uso:

• Respuestas a preguntas: Dada una colección de preguntas frecuentes, busca preguntas similares a la que introdujo el usuario.

• Búsqueda de artículos: En una colección de artículos de investigación, devuelven artículos con un título estrechamente relacionado con la consulta del usuario.

• Búsqueda de imágenes: En un conjunto de datos de imágenes con subtítulos, encuentra imágenes cuyo pie de foto sea similar a la descripción del usuario.

Un enfoque sencillo para la búsqueda por similitud sería clasificar los documentos según cuántas palabras compartan con la consulta. Pero un documento puede ser similar a la consulta aunque tengan muy pocas palabras en común; una noción más robusta de similitud tendría en cuenta también su contenido sintáctico y semántico .

La comunidad de procesamiento de lenguaje natural (PLN) desarrolló una técnica llamada incrustación de texto que codifica palabras y oraciones como vectores numéricos. Estas representaciones vectoriales están diseñadas para capturar el contenido lingüístico del texto y pueden emplear para evaluar la similitud entre una consulta y un documento.

Esta publicación explora cómo las incrustaciones de texto y el tipo de dense_vector de Elasticsearch podrían usar para apoyar la búsqueda por similitud. Primero daremos una visión general de las técnicas de incrustación y luego pasaremos por un prototipo sencillo de búsqueda por similitud usando Elasticsearch.

¿Qué son las incrustaciones de texto?

Echemos un vistazo más de cerca a los diferentes tipos de incrustaciones de texto y cómo se comparan con los enfoques tradicionales de búsqueda.

Incrustaciones de palabras

Un modelo de incrustación de palabras representa una palabra como un vector numérico denso. Estos vectores buscan capturar las propiedades semánticas de la palabra: palabras cuyos vectores están muy cerca deben ser similares en términos de significado semántico. En una buena incrustación, las direcciones en el espacio vectorial están ligadas a diferentes aspectos del significado de la palabra. Por ejemplo, el vector de "Canadá" podría estar cerca de "Francia" en una dirección y cerca de "Toronto" en otra.

Las comunidades de PLN y búsqueda llevan tiempo interesadas en representaciones vectoriales de palabras. En los últimos años hubo un resurgimiento del interés por las incrustaciones de palabras, cuando muchas tareas tradicionales se revisaban empleando redes neuronales. Se desarrollaron algunos algoritmos exitosos de incrustación de palabras, incluyendo word2vec y GloVe. Estos enfoques emplean grandes colecciones de texto y examinan el contexto en el que aparece cada palabra para determinar su representación vectorial:

• El modelo Skip-gram word2vec capacita una red neuronal para predecir las palabras de contexto alrededor de una palabra en una oración. Los pesos internos de la red dan la palabra embeddings.

• En GloVe, la similitud de las palabras depende de la frecuencia con la que aparecen junto a otras palabras contextuales. El algoritmo capacita un modelo lineal simple sobre los conteos de co-ocurrencia de palabras.

Muchos grupos de investigación distribuyen modelos que fueron preentrenados en grandes corpus de texto como Wikipedia o Common Crawl, lo que los hace cómodos de descargar e integrar en tareas posteriores. Aunque a veces se emplean versiones preentrenadas directamente, puede ser útil ajustar el modelo para ajustarlo al conjunto de datos y tarea objetivo específicos. Esto a menudo se logra ejecutando un paso de 'ajuste fino' sobre el modelo preentrenado.

Las incrustaciones de palabras demostraron ser bastante robustas y efectivas, y ahora es práctica común usar incrustaciones en lugar de tokens individuales en tareas de PLN como la traducción automática y la clasificación de sentimiento.

Incrustaciones de sentencias

Más recientemente, los investigadores empezaron a centrar en técnicas de incrustación que representan no solo palabras, sino también secciones más largas de texto. La mayoría de los enfoques actuales se basan en arquitecturas de redes neuronales complejas y, a veces, incorporan datos etiquetados durante el entrenamiento para ayudar a capturar información semántica.

Una vez capacitados, los modelos pueden tomar una oración y producir un vector para cada palabra en contexto, así como un vector para toda la oración. De forma similar a la incrustación de palabras, existen versiones preentrenadas de muchos modelos, lo que permite a los usuarios saltar el costoso proceso de entrenamiento. Aunque el proceso de entrenamiento puede ser muy intensivo en recursos, invocar el modelo es mucho más ligero — los modelos de incrustación de oraciones suelen ser lo suficientemente rápidos como para usar como parte de aplicaciones en tiempo real.

Algunas técnicas comunes de incrustación de oraciones incluyen InferSent, Universal Sentence Encoder, ELMo y BERT. Mejorar la incrustación de palabras y frases es un área activa de investigación, y es probable que se introduzcan modelos más estables.

Comparación con los enfoques tradicionales de búsqueda

En la recuperación tradicional de información, una forma común de representar el texto como un vector numérico es asignar una dimensión a cada palabra del vocabulario. El vector de un fragmento de texto se basa entonces en el número de veces que aparece cada término en el vocabulario. Esta forma de representar el texto suele denominar "bolsa de palabras", porque simplemente contamos las apariciones de palabras sin tener en cuenta la estructura de las oraciones.

Las incrustaciones de texto difieren de las representaciones vectoriales tradicionales en algunos aspectos importantes:

• Los vectores codificados son densos y relativamente de baja dimensión, a menudo con una dimensión que oscila entre 100 y 1.000 dimensiones. En cambio, los vectores de la bolsa de palabras son escasos y pueden comprender 50.000+ dimensiones. Los algoritmos de incrustación codifican el texto en un espacio de dimensión inferior como parte del modelado de su significado semántico. Idealmente, las palabras y frases sinónimas terminan con una representación similar en el nuevo espacio vectorial.

• Las incrustaciones de oraciones pueden tener en cuenta el orden de las palabras al determinar la representación vectorial. Por ejemplo, la frase "tune in" puede asignar como un vector muy diferente a "in tune".

• En la práctica, las incrustaciones de oraciones a menudo no se generalizan bien a grandes secciones de texto. No se usan comúnmente para representar textos más largos que un párrafo corto.

Uso de incrustaciones para la búsqueda de similitud

Supongamos que tuviéramos una gran colección de preguntas frecuentes. Un usuario puede hacer una pregunta, y queremos recuperar la pregunta más similar de nuestra colección para ayudarlo a encontrar una respuesta.

Podríamos usar incrustaciones de texto para permitir recuperar preguntas similares:

• Durante la indexación, cada pregunta se pasa por un modelo de incrustación de oraciones para producir un vector numérico.

• Cuando un usuario introduce una consulta, esta se ejecuta a través del mismo modelo de incrustación de frases para producir un vector. Para clasificar las respuestas, calculamos la similitud del vector entre cada pregunta y el vector de consulta. Al comparar vectores de incrustación, es común usar similitud coseno.

Este repositorio ofrece un ejemplo sencillo de cómo esto podría lograr en Elasticsearch. El script principal indexa ~20.000 preguntas del conjunto de datos StackOverflow, y luego permite al usuario introducir consultas en texto libre sobre el conjunto de datos.

Pronto repasaremos cada parte del guion en detalle, pero primero veamos algunos resultados de ejemplo. En muchos casos, el método es capaz de captar similitudes incluso cuando no hubo una fuerte superposición de palabras entre la consulta y la pregunta indexada:

• "comprimir archivos" devuelve "Comprimir / Descomprimir carpetas y archivos"

• "determinar si algo es una IP" devuelve "¿Cómo sabes si una cadena es una IP o un nombre de host"

• "translate bytes to doubles" devuelve "Convert Bytes to Floating Points Numbers in Python"

Detalles de implementación

El script comienza descargando y creando el modelo de incrustación en TensorFlow. Elegimos el Codificador Universal de Oraciones de Google, pero es posible usar muchos otros métodos de incrustación. El script emplea el modelo de incrustación tal cual, sin ningún entrenamiento o ajuste fino adicional.

A continuación, creamos el índice Elasticsearch, que incluye mapeos para el título de la pregunta, las etiquetas y también el título de la pregunta codificado como vector:

En el mapeo para dense_vector, debemos especificar el número de dimensiones que contendrán los vectores. Al indexar un campo title_vector, Elasticsearch comprueba que tenga el mismo número de dimensiones especificado en el mapeo.

Para indexar documentos, pasamos el título de la pregunta por el modelo de incrustación para obtener un array numérico. Este array se agrega al documento en el campo title_vector.

Cuando un usuario introduce una consulta, el texto se pasa primero por el mismo modelo de incrustación y se almacena en el parámetro query_vector. A partir de la versión 7.3, Elasticsearch proporciona una función cosineSimilarity en su lenguaje de scripting nativo. Así que para clasificar las preguntas según su similitud con la consulta del usuario, usamos una consulta script_score:

Nos cercioramos de pasar el vector de consulta como parámetro de script para evitar recompilar el script() en cada nueva consulta. Como Elasticsearch no permite puntajes negativos, es necesario agregar una a la similitud coseno.

| Nota: esta entrada de blog originalmente usaba una sintaxis diferente para funciones vectoriales que estaba disponible en Elasticsearch 7.3, pero que fue obsoleta en la 7.6. |

Limitaciones importantes

La consulta script_score está diseñada para envolver una consulta restrictiva y modificar los puntajes de los documentos que devuelve. Sin embargo, proporcionamos una consulta match_all, lo que significa que el script se ejecutará sobre todos los documentos del índice. Esta es una limitación actual de la similitud vectorial en Elasticsearch: los vectores pueden usar para puntuar documentos, pero no en el paso inicial de recuperación. El soporte para la recuperación basado en la similitud vectorial es un área importante de trabajo en curso.

Para evitar escanear todos los documentos y mantener un rendimiento rápido, la consulta de match_all puede ser reemplazada por una consulta más selectiva. La consulta adecuada para la recuperación probablemente dependerá del caso de uso específico.

Aunque vimos algunos ejemplos alentadores arriba, es importante señalar que los resultados también pueden ser ruidosos y poco intuitivos. Por ejemplo, "comprimir archivos" también asigna puntajes altos a "Partial .csproj Archivos" y "Cómo evitar .pyc ¿archivos?". Y cuando el método arroja resultados sorprendentes, no siempre está claro cómo depurar el problema: el significado de cada componente vectorial suele ser opaco y no corresponde a un concepto interpretable. Con las técnicas tradicionales de puntaje basadas en solapamientos de palabras, a menudo es más fácil responder a la pregunta "¿por qué este documento está muy bien clasificado?"

Como se mencionó antes, este prototipo está pensado como un ejemplo de cómo los modelos de incrustación podrían usar con campos vectoriales, y no como una solución lista para producción. Al desarrollar una nueva estrategia de búsqueda, es fundamental probar cómo funciona el enfoque con tus propios datos, cerciorándote de comparar con una línea base estable como una consulta de coincidencia. Puede ser necesario realizar cambios importantes en la estrategia antes de que logre resultados estables, incluyendo afinar el modelo de incrustación para el conjunto de datos objetivo o probar diferentes formas de incorporar incrustaciones como la expansión de consultas a nivel de palabra.

Conclusiones

Las técnicas de incrustación proporcionan una forma poderosa de captar el contenido lingüístico de un texto. Indexando incrustaciones y puntaje basándonos en la distancia vectorial, podemos comparar documentos usando una noción de similitud que va más allá de su solapamiento a nivel de palabra.

Esperamos introducir más funcionalidades basadas en el tipo de campo vectorial. El uso de vectores para la búsqueda es un área matizada y en desarrollo — como siempre, nos encantaría conocer vuestros casos de uso y experiencias en Github y en los foros de discusión.