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.

Ahora, ¿y si pudiéramos usar interacciones reales de usuario con nuestra aplicación de búsqueda para crear estos datos de entrenamiento? Emplear datos de RBU nos permite hacer precisamente eso. Crear un sistema automático que pueda capturar y usar nuestras búsquedas, clics y otras interacciones para generar una lista de juicios. Este proceso puede escalar y repetir mucho más fácilmente que una interacción manual y tendería a dar mejores resultados. En este blog, exploraremos cómo podemos consultar datos de RBU almacenados en Elasticsearch para calcular señales significativas que generen un conjunto de datos de entrenamiento para un modelo LTR .

Puedes encontrar el experimento completo aquí.

Por qué los datos de RBU pueden ser útiles para capacitar tu modelo de LTR

Los datos de la RBU ofrecen varios beneficios sobre una anotación manual:

• Volumen: Dado que los datos de RBU provienen de interacciones reales, podemos recopilar muchos más datos de los que generamos manualmente. Esto suponiendo que tengamos suficiente tráfico para generar estos datos, por supuesto.

• Intención real del usuario: Tradicionalmente, una lista de juicios manual proviene de una evaluación experta de los datos disponibles. Por otro lado, los datos de RBU reflejan el comportamiento real de los usuarios. Esto significa que podemos generar mejores datos de entrenamiento que mejorarán la precisión de nuestro sistema de búsqueda, porque se basan en cómo los usuarios interactúan y encuentran valor en tu contenido, más que en suposiciones teóricas sobre lo que debería ser relevante.

• Actualizaciones continuas: Las listas de juicios necesitan actualizar con el tiempo. Si los creamos a partir de datos de la RBU, podemos tener datos actuales que resulten en listas de juicios actualizadas.

• Rentabilidad: Sin la carga de crear manualmente una lista de juicios, el proceso puede repetir eficientemente cualquier número de veces.

• Distribución natural de consultas: Los datos de RBU representan consultas reales de usuario, lo que puede impulsar cambios más profundos. Por ejemplo, ¿nuestros usuarios usan lenguaje natural para buscar en nuestro sistema? Si es así, podríamos querer implementar un enfoque de búsqueda semántica o de búsqueda híbrida.

Sin embargo, viene con algunas advertencias:

• Amplificación de polarización: El contenido popular tiene más probabilidades de recibir clics, simplemente porque tiene más visibilidad. Así que esto podría acabar amplificando los productos populares y posiblemente ahogando opciones mejores.

• Cobertura incompleta: El contenido nuevo carece de interacciones, por lo que puede ser difícil que los resultados sean altos. Las consultas raras también pueden carecer de suficientes puntos de datos para crear datos de entrenamiento significativos.

• Variaciones estacionales: Si esperas que el comportamiento del usuario cambie significativamente con el tiempo, los datos históricos pueden no decirte mucho sobre qué es un buen resultado.

• Ambigüedad de la tarea: Un clic no siempre garantiza que el usuario encontró lo que buscaba.

Cálculo de calificaciones

Calificaciones para el entrenamiento a largo plazo

Para capacitar modelos LTR, necesitamos proporcionar alguna representación numérica de cuán relevante es un documento para una consulta. En nuestra implementación, este número es un puntaje continuo que va de 0,0 a 5,0+, donde puntajes más altos indican mayor relevancia.

Para mostrar cómo funciona este sistema de calificación, consideremos este ejemplo creado manualmente:

Búsqueda

Contenido del documento

Grado

Explicación

"La mejor receta de pizza"

"Receta auténtica de masa de pizza italiana con fotos paso a paso"

4.0

Muy relevante, exactamente lo que el usuario busca

"La mejor receta de pizza"

"Historia de la pizza en Italia"

1.0

Algo en el tema, trata sobre pizza pero no es una receta

"La mejor receta de pizza"

"Receta rápida de pizza de 15 minutos para principiantes"

3.0

Relevante, un buen resultado pero quizá no cumpla con la "mejor" receta.

"La mejor receta de pizza"

"Guía de mantenimiento de autos"

0.0

No tiene nada que ver, completamente ajeno a la consulta

Como podemos ver aquí, la calificación es una representación numérica de cuán relevante es un documento para nuestra consulta de ejemplo de "mejor receta de pizza". Con estos puntajes, nuestro modelo de LTR puede aprender qué documentos deben presentar mejor en los resultados.

Cómo calcular las notas es el núcleo de nuestro conjunto de datos de entrenamiento. Existen múltiples enfoques para hacerlo, cada uno con sus propias fortalezas y debilidades. Por ejemplo, podríamos asignar un puntaje binario de 1 para el 0 relevante para no relevante o simplemente contar el número de clics en un documento resultante para cada consulta.

En esta entrada del blog, emplearemos un enfoque diferente, teniendo en cuenta el comportamiento del usuario como nuestra entrada y calculando un número de calificación como resultado. También corregiremos el sesgo que podría surgir por el hecho de que los resultados más altos tienden a ser más clicados, independientemente de la relevancia del documento.

Cálculo de las calificaciones - algoritmo COEC

El algoritmo COEC (Clics over Expected Clics) es una metodología para calcular las calificaciones de juicio a partir de clics de los usuarios. Como mencionamos antes, los usuarios tienden a hacer clic en resultados de mejor posición incluso si el documento no es el más relevante para la consulta; esto se llama sesgo de posición. La idea central para usar el algoritmo COEC es que no todos los clics son igual de significativos; Un clic en un documento en la posición 10 indica que el documento es mucho más relevante para la consulta que un clic en un documento en la posición 1. Para citar el artículo de investigación sobre el algoritmo COEC (enlazado arriba):

"Es bien sabido que la tasa de clics (CTR) de los resultados de búsqueda o anuncios disminuye significativamente dependiendo de la posición de los resultados."

Puedes leer más sobre el sesgo de posición aquí.

Para abordar esto con el algoritmo COEC, seguimos estos pasos:

1. Establecer líneas base de posición: Calculamos la tasa de clics (CTR) para cada posición de búsqueda del 1 al 10. Esto significa que determinamos qué porcentaje de usuarios suelen hacer clic en la posición 1, posición 2, y así sucesivamente. Este paso captura el sesgo natural de posición de los usuarios. Calculamos el CTR usando:

Dónde:

p = Posición. Del 1 al 10 Cp = Total de clics (en cualquier documento) en la posición p en todas las consultas Ip = Total de impresiones: Cuántas veces apareció cualquier documento en la posición p en todas las consultas

Aquí, esperamos que los puestos más altos consigan más clics.

2. Calcular los clics esperados (EC):

Esta métrica establece cuántos clics "debería" recibir un documento en función de las posiciones en las que apareció y el CTR para esas posiciones. Calculamos la EC usando:

Dónde:

Qd = Todas las consultas donde apareció el documento d pos(d,q)= Posición del documento d en los resultados de la consulta q

3. Contar clics reales: Contamos el total real de clics que un documento recibió en todas las consultas donde apareció, en adelante llamado A(d).

4. Calcular el puntaje del COEC: Esta es la proporción de clics reales (A(d)) sobre los clics esperados (EC(d)):

Esta métrica normaliza para el sesgo de posición como este:

• Un puntaje de 1,0 significa que el documento funcionó exactamente como se espera dadas las posiciones en las que apareció.

• Un puntaje superior a 1,0 significa que el documento tuvo un mejor rendimiento de lo esperado al observar sus posiciones. Así que este documento es más relevante para la consulta.

• Un puntaje inferior a 1,0 significa que el documento tuvo un rendimiento peor de lo esperado al observar sus posiciones. Así que este documento es menos relevante para la consulta.

El resultado final es un número de calificación que captura lo que los usuarios buscan, teniendo en cuenta expectativas basadas en la posición extraídas de interacciones reales con nuestro sistema de búsqueda.

Implementación técnica

Crearemos un script para crear una lista de juicios y capacitar un modelo de LTR.

La entrada para este script es los datos de la RBU indexados en Elastic (consultas y eventos).

La salida es una lista de juicios en un archivo CSV generada a partir de estos documentos de RBU empleando el algoritmo COEC. Esta lista de juicios puede usar con Eland para extraer características relevantes y capacitar un modelo LTR.

Inicio rápido

Para generar una lista de juicios a partir de los datos de muestra de este blog, puedes seguir estos pasos:

1. Clonar el repositorio:

2. Instalar las librerías necesarias

Para este guion, necesitamos las siguientes librerías:

• Pandas: Para salvar la lista de juicios

• elasticsearch: Para obtener los datos de RBU de nuestro despliegue de Elastic

También necesitamos Python 3.11

3. Actualizar las variables de entorno para tu despliegue de Elastic en un archivo .env

• ES_HOST

• API_KEY

Para agregar las variables de entorno, emplea:

4. Crear el ubi_queries, ubi_events índices y subir los datos de muestra. Ejecuta el archivo setup.py:

5. Ejecutar el script en Python:

Si sigues estos pasos, deberías ver un archivo nuevo llamado judgment_list.csv que se ve así:

Este script calcula las calificaciones aplicando el algoritmo COEC discutido antes de usar la función calculate_relevance_grade() que se muestra a continuación.

Arquitectura de datos

Consultas Ubi

Nuestro índice de consultas de RBU contiene información sobre las consultas ejecutadas en nuestro sistema de búsqueda. Este es un documento de ejemplo:

Aquí podemos ver datos del usuario (client_id), de los resultados de la consulta (query_response_object_ids) y de la propia consulta (marca de tiempo, user_query)

Eventos de Ubi Clic

Nuestro índice de ubi_events contiene datos de cada vez que un usuario hizo clic en un documento en los resultados. Este es un documento de ejemplo:

Script de generación de lista de sentencias

Resumen general de la escritura

Este script automatiza la generación de la lista de juicios empleando datos de RBU de los eventos de Consultas y Clics almacenados en Elasticsearch. Ejecuta estas tareas:

• Recupera y procesa los datos de la RBU en Elasticsearch.

• Correlaciona los eventos de RBU con sus consultas.

• Calcula el CTR para cada posición.

• Calcula los clics esperados (EC) para cada documento.

• Cuenta los clics reales de cada documento.

• Calcula el puntaje del COEC para cada par consulta-documento.

• Genera una lista de juicios y la escribe en un archivo CSV.

Repasemos cada función:

connect_to_elasticsearch()

Esta función devuelve un objeto cliente de Elasticsearch usando la clave host y API.

fetch_ubi_data()

Esta función es la capa de extracción de datos; se conecta con Elasticsearch para obtener consultas de RBU usando una consulta match_all y filtra los eventos de RBU para obtener solo eventos 'CLICK_THROUGH'.

process_ubi_data()

Esta función se encarga de la generación de la lista de juicios. Comienza a procesar los datos de RBU asociando eventos y consultas de RBU. Luego llama a la función calculate_relevance_grade() para cada par documento-consulta para obtener las entradas de la lista de juicios. Finalmente, devuelve la lista resultante como un dataframe pandas.

calculate_relevance_grade()

Esta es la función que implementa el algoritmo COEC. Calcula el CTR para cada posición, luego compara los clics reales de un par documento-consulta, y finalmente calcula el puntaje real del COEC para cada una.

generate_judgment_statistics()

Genera estadísticas útiles a partir de la lista de valores, como el total de consultas, el total de documentos únicos o la distribución de calificaciones. Esto es puramente informativo y no cambia la lista de sentencias resultante.

Resultados e impacto

Si sigues las instrucciones de la sección de Inicio rápido, deberías ver un archivo CSV resultante que contiene una lista de juicios con 320 entradas (puedes ver una salida de ejemplo en el repositorio). Con estos campos:

• qid: ID único de la consulta

• DocID: Identificador único para un documento resultante

• Grado: la calificación calculada para el par consulta-documento

• consulta: La consulta de usuario

Veamos los resultados de la consulta "recetas italianas":

Qid

docid

grado

Búsqueda

Q1-recetas-italianas

recipe_pasta_basics

0.0

Recetas italianas

Q1-recetas-italianas

recipe_pizza_margherita

3.333333

Recetas italianas

Q1-recetas-italianas

recipe_risotto_guide

10.0

Recetas italianas

Q1-recetas-italianas

recipe_french_croissant

0.0

Recetas italianas

Q1-recetas-italianas

recipe_spanish_paella

0.0

Recetas italianas

Q1-recetas-italianas

recipe_greek_moussaka

1.875

Recetas italianas

Podemos ver en los resultados que para la consulta "recetas italianas":

• La receta de risotto es sin duda el mejor resultado para la consulta, recibiendo 10 veces más clics de lo esperado

• Pizza Margherita también es un gran resultado.

• La mousaka griega (sorprendentemente) también es un buen resultado y rinde mejor de lo que su posición en los resultados sugeriría. Esto significa que algunos usuarios que buscaban recetas italianas se interesaron por esta receta. Quizá estos usuarios estén interesados en platos mediterráneos en general. Al final, esto nos dice que podría ser un buen resultado para mostrar bajo los otros dos partidos 'mejores' que mencionamos antes.

Conclusión

Emplear datos de RBU nos permite automatizar el entrenamiento de modelos de LTR, creando listas de juicios de alta calidad de nuestros propios usuarios. Los datos de RBU proporcionan un gran conjunto de datos que refleja cómo se está empleando nuestro sistema de búsqueda. Al emplear el algoritmo de la COEC para generar las calificaciones, tenemos en cuenta el sesgo inherente y, al mismo tiempo, refleja lo que el usuario considera un mejor resultado. El método descrito aquí puede aplicar a casos de uso reales para ofrecer una mejor experiencia de búsqueda que evoluciona con las tendencias reales de uso.

Elasticsearch 8.12 y 8.13 llevaron soporte básico para tipos geoespaciales a ES|QL. Esto se mejoró significativamente con la incorporación de capacidades de búsqueda geoespacial en la versión 8.14. Más importante aún, este soporte fue diseñado para ajustar estrechamente al estándar Simple Feature Access del Open Geospatial Consortium (OGC) empleado por otras bases de datos espaciales como PostGIS, facilitando mucho su uso para expertos en SIG familiarizados con estos estándares.

En este blog, te mostraremos cómo usar ES|QL para realizar búsquedas geoespaciales y cómo se compara con los equivalentes SQL y Query DSL. También te mostraremos cómo usar ES|QL para realizar uniones espaciales y cómo visualizar los resultados en Kibana Maps. Ten en cuenta que todas las funciones descritas aquí están en "vista previa técnica", y nos encantaría conocer vuestros comentarios sobre cómo podemos mejorarlas.

Búsqueda de datos geoespaciales

Empecemos con una consulta de ejemplo:

Esto realiza una búsqueda de cualquier polígono de límite de ciudad que intersecte con un polígono rectangular alrededor del Aeropuerto Internacional Sanya Phoenix (SYX).

En un conjunto de datos de ejemplo de aeropuertos, ciudades y límites urbanos, esta búsqueda encuentra el polígono que se cruza y devuelve los campos deseados del documento correspondiente:

Abbrev

aeropuerto

región

ciudad

city_location

SYX

Sanya Phoenix Internacional

天涯区

Sanya

POINT(109.5036 18.2533)

¡Eso fue fácil! Ahora compáralo con el tradicional DSL de Elasticsearch Query para la misma consulta:

Ambas consultas son bastante claras en su intención, pero el ES|La consulta QL se parece mucho a SQL. La misma consulta en PostGIS es la siguiente:

Mira atrás en el ES|Ejemplo de QL. Muy parecido, ¿verdad?

Comprobamos que los usuarios actuales de la API de Elasticsearch encuentran ES|QL mucho más fácil de usar. Ahora esperamos que los usuarios existentes de SQL, especialmente los de SQL Espacial, descubran que ES|QL se siente muy familiar con lo que están acostumbrados a ver.

¿Por qué no SQL?

¿Y qué pasa con Elasticsearch SQL? Lleva un tiempo existiendo y tiene algunas características geoespaciales. Sin embargo, Elasticsearch SQL se escribía como un envoltorio sobre la API original de Consultas, lo que significaba que solo se soportaban consultas que podían transpilarse a la API original. ES|QL no tiene esta limitación. Ser una pila completamente nueva permite muchas optimizaciones que no eran posibles en SQL. Nuestros benchmarks muestran ES|QL suele ser muy rápido que la API de Consultas, ¡especialmente con agregaciones!

Diferencias con SQL

Claramente, por el ejemplo anterior, ES|QL es algo similar a SQL, pero hay algunas diferencias importantes. Por ejemplo, ES|QL es un lenguaje de consulta por pipes, que comienza con un comando fuente como FROM y luego encadena todos los comandos posteriores junto con el pipe | carácter. Esto facilita mucho entender cómo cada comando recibe una tabla de datos y realiza alguna acción sobre esa tabla, como filtrar con WHERE, agregar columnas con EVAL, o realizar agregaciones con STATS. En lugar de comenzar con SELECT para definir las columnas de salida finales, puede haber uno o más comandos KEEP , siendo el último el que especifica los resultados finales. Esta estructura simplifica el razonamiento sobre la consulta.

Centrándonos en el comando WHERE del ejemplo anterior, podemos ver que se parece bastante al ejemplo de PostGIS:

ES|QL

PostGIS

Aparte de la diferencia en los caracteres de comillas de cadena, la mayor diferencia está en cómo tipificamos la cadena a un tipo espacial. En PostGIS, usamos el sufijo ::geometry , mientras que en ES|QL, usamos el sufijo ::geo_shape . Esto se debe a que ES|QL se ejecuta dentro de Elasticsearch, y el operador de typecasting :: puede usar para convertir una cadena a cualquiera de los ES| soportadosQL tipia, en este caso, un geo_shape. Además, los tipos geo_shape y geo_point en Elasticsearch implican el sistema de coordenadas espaciales conocido como WGS84, más comúnmente conocido con el número SRID 4326. En PostGIS, esto debe ser explícito, de ahí el uso del prefijo SRID=4326; a la cadena WKT. Si se elimina ese prefijo, el SRID se pondrá en 0, que es más parecido a los tipos de Elasticsearch cartesian_point y cartesian_shape, que no están vinculados a ningún sistema de coordenadas específico.

Ambos ES|QL y PostGIS también proporcionan sintaxis de funciones de conversión de tipos:

ES|QL

PostGIS

Funciones OGC

Elasticsearch 8.14 introduce las siguientes cuatro funciones de búsqueda espacial OGC:

ES|QL

PostGIS

Descripción

ST_INTERSECTS

ST_Intersects

Devuelve verdadero si dos geometrías se cruzan, y falso en caso contrario.

ST_DISJOINT

ST_Disjoint

Devuelve verdadero si dos geometrías no se intersectan, y falso en caso contrario. El inverso de ST_INTERSECTS.

ST_CONTAINS

ST_Contains

Devuelve verdadero si una geometría contiene otra, y falso en caso contrario.

ST_WITHIN

ST_Within

Devuelve verdadero si una geometría está dentro de otra, y falso en caso contrario. El inverso de ST_CONTAINS.

Estas funciones se comportan de forma similar a sus contrapartes PostGIS y se emplean de la misma manera. Por ejemplo, ST_INTERSECTS devuelve verdadero si dos geometrías se intersectan y falso en caso contrario. Si sigues los enlaces de documentación de la tabla anterior, puede que notes que todos los ES|Los ejemplos de QL están dentro de una cláusula de WHERE luego de una cláusula de FROM , mientras que todos los ejemplos de PostGIS usan geometrías literales. De hecho, ambas plataformas soportan el uso de las funciones en cualquier parte de la consulta donde tengan sentido.

El primer ejemplo en la documentación de PostGIS para ST_INTERSECTS es:

El ES|El equivalente en QL de esto sería:

Fíjate en que no especificamos el SRID en el ejemplo de PostGIS. Esto se debe a que en PostGIS, al usar el tipo geometry , todos los cálculos se realizan en un sistema de coordenadas planas, por lo que si ambas geometrías tienen el mismo SRID, no importa cuál sea el SRID. En Elasticsearch, esto también es cierto para la mayoría de las funciones, sin embargo, hay excepciones donde geo_shape y geo_point emplean cálculos esféricos, como veremos en el próximo blog sobre búsqueda por distancia espacial.

ES|Versatilidad en QL

Vimos ejemplos arriba de usar funciones espaciales en cláusulas WHERE y en comandos ROW . ¿Dónde más tendrían sentido? Un lugar muy útil es en el comando EVAL . Este comando te permite evaluar una expresión y devolver el resultado. Por ejemplo, determinemos si los centroides de todos los aeropuertos agrupados por el nombre de sus países están dentro de un límite que delimita el país:

Se esperan los resultados: el centroide de los aeropuertos del Reino Unido está dentro del límite del Reino Unido, y no dentro del límite de Islandia, y viceversa:

centroide

Recuento

in_uk

in_iceland

within_uk

within_iceland

POINT (-21.946634463965893 64.13187285885215)

1

falso

true

falso

true

POINT (-2.597342072712148 54.33551226578214)

17

true

falso

true

falso

POINT (0.04453958108176276 23.74658354606057)

873

falso

falso

falso

falso

De hecho, estas funciones pueden usar en cualquier parte de la consulta donde su firma tenga sentido. Todos toman dos argumentos, que son o bien un objeto espacial literal o un campo de un tipo espacial, y todos devuelven un valor booleano. Una consideración importante es que el sistema de referencia de coordenadas (CRS) de las geometrías debe coincidir, o se devolverá un error. Esto significa que no puedes mezclar geo_shape y cartesian_shape tipos en la misma llamada de función. Sin embargo, puedes mezclar geo_point y geo_shape tipos, ya que el tipo geo_point es un caso especial del tipo geo_shape , y ambos comparten el mismo sistema de referencia de coordenadas. La documentación de cada una de las funciones definidas anteriormente lista las combinaciones de tipos soportadas.

Además, cualquiera de los dos argumentos puede ser un literal espacial o un campo, en cualquiera de los dos ordenes. Incluso puedes especificar dos campos, dos literales, un campo y un literal, o un literal y un campo. El único requisito es que los tipos sean compatibles. Por ejemplo, esta consulta compara dos campos en el mismo índice:

La consulta básicamente pregunta si la ubicación de la ciudad está dentro del límite de la ciudad, lo cual generalmente debería ser cierto, pero siempre hay excepciones:

cardinalidad

Recuento

in_city

poco

29

falso

mucho

740

true

Una pregunta mucho más interesante sería si la ubicación del aeropuerto está dentro de los límites de la ciudad a la que sirve el aeropuerto. Sin embargo, la ubicación del aeropuerto se encuentra en un índice diferente al que contiene los límites de la ciudad. Esto requiere un método para consultar y correlacionar eficazmente los datos de estos dos índices separados.

Unirías espaciales

ES|QL no soporta comandos JOIN, pero puedes lograr un caso especial de unión usando el comando ENRICH, que se comporta de forma similar a una 'unión izquierda' en SQL. Este comando funciona de forma similar a una 'unión por la izquierda' en SQL, permitiéndote enriquecer resultados de un índice con datos de otro índice basar en una relación espacial entre los dos conjuntos de datos.

Por ejemplo, enriquezcamos los resultados de una tabla de aeropuertos con información adicional sobre la ciudad a la que sirven encontrando el límite de la ciudad que contiene la ubicación del aeropuerto, y luego realicemos algunas estadísticas sobre los resultados:

Esto devuelve las 5 regiones con más aeropuertos, junto con el centroide de todos los aeropuertos que tienen regiones coincidentes, y el rango en longitud de la representación WKT de los límites de la ciudad dentro de esas regiones:

centroide

Recuento

min_wkt

max_wkt

región

PUNTO (-32.56093470960719 32.598117914802714)

90

207

207

nulo

POINT (-73.94515332765877 40.70366442203522)

9

438

438

Ciudad de Nueva York

POINT (-83.10398317873478 42.300230911932886)

9

473

473

Detroit

POINT (-156.3020245861262 20.176383580081165)

5

307

803

Hawai

POINT (-73.88902732171118 45.57078813901171)

4

837

837

Montréal

Entonces, ¿qué pasó realmente aquí? ¿Dónde ocurrió la supuesta JOIN ? El núcleo de la consulta reside en el comando ENRICH :

Este comando instruye a Elasticsearch para enriquecer los resultados recuperados del índice de airports y realizar una unión intersects entre el campo city_location del índice original y el campo city_boundary del índice de airport_city_boundaries , que usamos en algunos ejemplos anteriores. Pero parte de esta información no es claramente visible en esta consulta. Lo que sí vemos es el nombre de una política de enriquecimiento city_boundaries, y la información que falta está encapsulada dentro de esa definición de política.

Aquí podemos ver que realizará una consulta geo_match (intersects es el valor predeterminado), el campo a emparejar es city_boundary, y los enrich_fields son los campos que queremos agregar al documento original. Uno de esos campos, el region , se usó como clave de agrupación para el comando STATS , algo que no podríamos hacer sin esta capacidad de 'unión izquierda'. Para más información sobre las pólizas de enriquecimiento, consulte la documentación de enriquecimiento. Al leer esos documentos, notarás que describen el uso de los índices enrich para enriquecer datos en tiempo de indexación, configurando pipelines de ingest. Esto no es necesario para ES|QL, ya que el comando ENRICH funciona en el momento de la consulta. Basta con preparar el índice de enriquecimiento con los datos y la política de enriquecimiento necesarios, y luego usar el comando ENRICH en tu ES|Consultas QL.

También puede que notes que la región más común era null. ¿Qué podría implicar esto? Recuerda que comparé este comando con un 'left join' en SQL, lo que significa que si no se encuentra ningún límite de ciudad coincidente para un aeropuerto, el aeropuerto sigue devolver pero con valores null para los campos del índice de airport_city_boundaries . Resulta que había 89 aeropuertos que no encontraron city_boundarycoincidentes, y un aeropuerto con un region campo de null. Esto llevó a un recuento de 90 aeropuertos sin region en los resultados. Otro detalle interesante es la necesidad del comando MV_EXPAND . Esto es necesario porque el comando ENRICH puede devolver múltiples resultados por cada fila de entrada, y MV_EXPAND ayuda a separar estos resultados en varias filas, una para cada resultado. Esto también aclara por qué "Hawái" muestra resultados min_wkt y max_wkt diferentes: había varias regiones con el mismo nombre pero diferentes límites.

Kibana Maps

Kibana agregó soporte para Spatial ES|QL en la aplicación de Mapas. Esto significa que ahora puedes usar ES|QL para buscar datos geoespaciales en Elasticsearch y visualizar los resultados en un mapa.

Hay una nueva opción de capa en el menú de agregar capas, llamada "ES|QL". Como todas las características geoespaciales descritas hasta ahora, esto está en "vista previa técnica". Seleccionar esta opción te permite agregar una capa al mapa basada en los resultados de un ES|Consulta QL. Por ejemplo, podrías agregar una capa al mapa que muestre todos los aeropuertos del mundo.

O podrías agregar una capa que muestre los polígonos del índice de airport_city_boundaries , o mejor aún, ¿qué tal esa compleja consulta de ENRICH arriba que genera estadísticas sobre cuántos aeropuertos hay en cada región?

¿Qué sigue ahora?

Quizá notaste que en dos de los ejemplos anteriores incluimos otra función espacial ST_CENTROID_AGG. Esta es una función agregadora empleada en el comando STATS , y la primera de muchas funciones de análisis espacial que planeamos agregar a ES|QL. ¡Escribiremos sobre ello en el blog cuando tengamos más que mostrar!

Antes de eso, queremos contarte más sobre una función especialmente emocionante en la que trabajamos: la capacidad de realizar búsquedas espaciales, una de las funciones de búsqueda espacial más empleadas en Elasticsearch. ¿Te imaginas cómo sería la sintaxis de las búsquedas a distancia? ¿Quizá similar a una función OGC? ¡Permanece atento al próximo blog de este serial para descubrirlo!

Alerta de spoilers: Elasticsearch 8.15 acaba de ser lanzado, y la búsqueda por distancia espacial con ES|¡QL está incluido!

Comprender el índice de referencia BEIR en la evaluación de la relevancia de búsqueda

Para mejorar cualquier sistema, debes poder medir su eficacia. En el contexto de una búsqueda, BEIR (o, de manera equivalente, la sección de recuperación de la tabla de clasificación de MTEB) se considera el “santo grial” para la comunidad de recuperación de información, y no es de extrañar. Es un índice de referencia muy bien estructurado con sets de datos variados para diferentes tareas. Más específicamente, se cubren las siguientes áreas:

• Recuperación de argumentos (ArguAna, Touche2020)

• QA de dominio abierto (HotpotQA, Natural Questions, FiQA)

• Recuperación de pasajes (MSMARCO)

• Recuperación de preguntas duplicadas (Quora, CQADupstack)

• Verificación de hechos (FEVER, Climate-FEVER, Scifact)

• Recuperación de información biomédica (TREC-COVID, NFCorpus, BioASQ)

• Recuperación de entidades (DBPedia)

• Predicción de citas (SCIDOCS)

Ofrece una única estadística, nDCG@10, relacionada con la capacidad de un sistema para encontrar los documentos más relevantes para cada ejemplo de tarea en los primeros resultados que devuelve. Para un sistema de búsqueda con el que interactúa un ser humano, la relevancia de los resultados principales es fundamental. Sin embargo, hay muchos matices a la hora de evaluar las búsquedas que una sola estadística resumida no refleja.

Estructura de un set de datos BEIR

Cada benchmark tiene tres artefactos:

• el corpus o los documentos que se van a recuperar

• las búsquedas

• los juicios de relevancia para las búsquedas (también conocidos como qrels).

Las evaluaciones de relevancia se ofrecen como una puntuación que es igual a cero o mayor. Las puntuaciones no nulas indican que el documento está algo relacionado con la búsqueda.

Set de datos

Tamaño del corpus

#Búsquedas en el conjunto de pruebas

#qrels etiquetados positivamente

#qrels igual a cero

#duplicados en el corpus

Arguana

8,674

1,406

1,406

0

96

Climate-FEVER

5,416,593

1,535

4,681

0

0

DBPedia

4,635,922

400

15,286

28,229

0

FEVER

5,416,568

6,666

7,937

0

0

FiQA-2018

57,638

648

1,706

0

0

HotpotQA

5,233,329

7,405

14,810

0

0

Preguntas naturales

2,681,468

3,452

4,021

0

16,781

NFCorpus

3,633

323

12,334

0

80

Quora

522,931

10,000

15,675

0

1,092

SCIDOCS

25,657

1000

4,928

25,000

2

SciFact

5,183

300

339

0

0

Touche2020

382,545

49

932

1,982

5,357

TREC-COVID

171,332

50

24,763

41,663

0

MSMARCO

8,841,823

6,980

7,437

0

324

CQADupstack (suma)

457,199

13 145

23,703

0

0

Tabla 1: Estadísticas de los sets de datos. Los números se calcularon en la parte de prueba de los sets de datos (dev para MSMARCO).

La Tabla 1 presenta algunas estadísticas para los sets de datos que comprenden el índice de referencia BEIR, como la cantidad de documentos en el corpus, la cantidad de búsquedas en el set de datos de prueba y la cantidad de pares positivos/negativos (búsqueda, documento) en el archivo qrels. Con una rápida mirada a los datos podemos inferir inmediatamente lo siguiente:

• La mayoría de los sets de datos no contienen relaciones negativas en el archivo qrels, es decir, puntuaciones cero, lo que indicaría explícitamente que los documentos son irrelevantes para la búsqueda dada.

• La cantidad promedio de relaciones de documentos por búsqueda (#qrels / #queries) varía desde 1.0 en el caso de ArguAna hasta 493.5 (TREC-COVID), pero con un valor de <5 para la mayoría de los casos.

• Algunos sets de datos tienen documentos duplicados en el corpus, lo que en algunos casos puede conducir a una evaluación incorrecta, es decir, cuando un documento se considera relevante para una búsqueda, pero su duplicado no lo es. Por ejemplo, en ArguAna hemos identificado 96 casos de pares de documentos duplicados con solo un documento por par marcado como relevante para una búsqueda. Al “expandir” la lista inicial de qrels para incluir también los duplicados, hemos observado un aumento relativo de ~1 % en la puntuación nDCG@10 en promedio.

Ejemplo de pares duplicados en ArguAna. En el archivo qrels solo el primero parece ser relevante (como contra-argumento) para la búsqueda (“test-economy-epiasghbf-pro02a”)

Al comparar modelos en la tabla de líderes de MTEB, es tentador centrarse en la calidad promedio de recuperación. Es un buen indicador de la calidad general del modelo, pero no necesariamente te dice cómo se aplicará en tu caso. Dado que los resultados se reportan por conjunto de datos, vale la pena entender hasta qué punto los diferentes conjuntos de datos se relacionan con tu tarea de búsqueda y volver a calificar modelos usando solo los más relevantes. Si quieres profundizar más, también puedes verificar si hay superposición de temas con los diversos conjuntos de datos. Estratificar las medidas de calidad por tema ofrece una evaluación mucho más detallada de sus fortalezas y debilidades específicas.

Una nota importante aquí es que cuando un documento no está marcado en el archivo qrels, por defecto, se considera irrelevante para la búsqueda. Nos adentramos un poco más en esta área y recopilamos algunas pruebas para aclarar la siguiente pregunta: “¿Con qué frecuencia se presentan pares al evaluador (búsqueda, documento) para los cuales no hay información fidedigna?”. La razón por la que esto es importante es que cuando solo se dispone de marcado superficial (y, por lo tanto, no todos los documentos relevantes están etiquetados como tales), un sistema de recuperación de información puede ser juzgado como peor que otro simplemente porque "elige" mostrar diferentes documentos relevantes (pero no marcados). Este es un problema habitual a la hora de crear conjuntos de evaluación de alta calidad, especialmente en el caso de sets de datos de gran tamaño. Para ser factible, el etiquetado manual generalmente se enfoca en los principales resultados devueltos por el sistema actual, por lo que potencialmente se pierden documentos relevantes en sus puntos ciegos. Por lo tanto, generalmente es preferible enfocar más recursos en un marcado más completo de menos búsquedas que en un marcado amplio y superficial.

Aprovechar el índice de referencia BEIR para la evaluación de relevancia en búsquedas

Para iniciar nuestro análisis implementamos el siguiente escenario (ver el cuaderno):

1. En primer lugar, cargamos el corpus de cada set de datos en un índice de Elasticsearch.

2. Para cada búsqueda en el conjunto de pruebas, recuperamos los 100 documentos principales con BM25.

3. Volvemos a clasificar los documentos recuperados utilizando una variedad de modelos de reclasificación SOTA.

4. Finalmente, presentamos el reporte de la “tasa de evaluación” para los 10 documentos principales que provienen de los pasos 2 (después de la recuperación) y 3 (después de la reclasificación). En otras palabras, calculamos el porcentaje promedio de los 10 documentos principales que tienen una puntuación en el archivo qrels.

La lista de reclasificación de modelos que utilizamos es la siguiente:

• rerank-english-v2.0 de Cohere y rerank-english-v3.0

• BGE-base

• mxbai-rerank-xsmall-v1

• MiniLM-L-6-v2

Recuperación

Reclasificación

Set de datos

BM25 (%)

Cohere Rerank v2 (%)

Cohere Rerank v3 (%)

BGE-base (%)

mxbai-rerank-xsmall-v1 (%)

MiniLM-L-6-v2 (%)

Arguana

7.54

4.87

7.87

4.52

4.53

6.84

Climate-FEVER

5.75

6.24

8.15

9.36

7.79

7.58

DBPedia

61.18

60.78

64.15

63.9

63.5

67.62

FEVER

8.89

9.97

10.08

10.19

9.88

9.88

FiQA-2018

7.02

11.02

10.77

8.43

9.1

9.44

HotpotQA

12.59

14.5

14.76

15.1

14.02

14.42

Preguntas naturales

5.94

8.84

8.71

8.37

8.14

8.34

NFCorpus

31.67

32.9

33.91

30.63

32.77

32.45

Quora

12.2

10.46

13.04

11.26

12.58

12.78

SCIDOCS

8.62

9.41

9.71

8.04

8.79

8.52

SciFact

9.07

9.57

9.77

9.3

9.1

9.17

Touche2020

38.78

30.41

32.24

33.06

37.96

33.67

TREC-COVID

92.4

98.4

98.2

93.8

99.6

97.4

MSMARCO

3.97

6.00

6.03

6.07

5.47

6.11

CQADupstack (promedio)

5.47

6.32

6.87

5.89

6.22

6.16

Tabla 2: Tasa de evaluación por pares (set de datos, reclasificador) calculada en los 10 primeros documentos recuperados/reclasificados

Desde Tabla 2, con la excepción de TREC-COVID (>90 % de cobertura), DBPedia (~65 %), Touche2020 y nfcorpus (~35 %), vemos que la mayoría de los sets de datos tienen una tasa de etiquetado entre el 5 % y un poco más del 10 % después de la recuperación o reclasificación. Esto no significa que todos estos documentos no marcados sean relevantes, pero podría haber un subconjunto de ellos, especialmente aquellos ubicados en las posiciones superiores, que podrían ser positivos.

Con la llegada de los modelos de lenguaje ajustados mediante instrucciones de propósito general, tenemos una nueva herramienta poderosa que potencialmente puede automatizar la evaluación de la relevancia. Estos métodos suelen ser demasiado costosos en cuanto a la complejidad de los procesos para ser utilizados en línea para la búsqueda, pero aquí nos preocupa la evaluación fuera de línea. A continuación, los usamos para explorar la evidencia de que algunos de los sets de datos BEIR tienen un marcado superficial.

Para investigar más a fondo esta hipótesis, decidimos centrarnos en MSMARCO y seleccionar un subconjunto de 100 búsquedas junto con los 5 principales documentos reclasificados (con Cohere v2) que actualmente no están marcados como relevantes. Seguimos dos caminos diferentes de evaluación: Primero, usamos un indicador cuidadosamente ajustado (veremos más sobre esto en una publicación posterior) para preparar el modelo Phi-3-mini-4k recientemente lanzado para predecir la relevancia (o no) de un documento para la búsqueda. Paralelamente, estos casos también se etiquetaron manualmente para evaluar la tasa de concordancia entre el resultado del LLM y el juicio humano. En general, podemos extraer estas dos conclusiones:

• La tasa de acuerdo entre las respuestas de los LLM y los juicios humanos fue cercana al 80 %, lo que parece suficiente como punto de partida en esa dirección.

• En el 57.6 % de los casos (basado en el juicio humano) se descubrió que los documentos devueltos eran realmente relevantes para la búsqueda. Para decirlo de otra manera: Para 100 búsquedas tenemos 107 documentos considerados relevantes, ¡pero al menos 0.576 x 5 x 100 = 288 documentos adicionales que son realmente relevantes!

Aquí, algunos ejemplos extraídos del set de datos MSMARCO/dev que contienen la búsqueda, el documento positivo anotado (de qrels) y un documento falso negativo debido a un marcado incompleto:

Ejemplo 1:

Ejemplo 2:

La evaluación manual de búsquedas específicas como esta es una técnica generalmente útil para comprender la calidad de la búsqueda que complementa las medidas cuantitativas como nDCG@10. Si tienes un conjunto representativo de búsquedas que siempre ejecutas al hacer cambios en la búsqueda, te proporciona información cualitativa importante sobre cómo cambia el rendimiento, lo cual es invisible en las estadísticas. Por ejemplo, te da mucha más información sobre los resultados falsos que devuelve la búsqueda: puede ayudarte a detectar errores evidentes en los resultados recuperados, clases de errores relacionados, como malinterpretar terminología específica de un dominio, y así sucesivamente.

Nuestro resultado concuerda con la investigación relevante sobre la evaluación de MSMARCO. Por ejemplo, Arabzadeh et al. siguen un procedimiento similar en el que emplean trabajadores de crowdsourcing para hacer juicios de preferencia: entre otros puntos, muestran que en muchos casos se prefieren los documentos devueltos por los módulos de reclasificación en comparación con los documentos del archivo MSMARCO qrels. Otra evidencia proviene de los autores del reclasificador RocketQA quienes en su reporte indican que más del 70 % de los documentos reclasificados se consideraron relevantes luego de la inspección manual.

Actualización - 9 de septiembre: Tras una cuidadosa reevaluación del set de datos, identificamos 15 casos más de documentos relevantes, lo que aumenta el total de 273 a 288

Principales puntos clave y próximos pasos

• La búsqueda de mejores datos fidedignos es interminable, ya que es de vital importancia para la evaluación comparativa y la comparación de modelos. Los LLM pueden ayudar en algunas áreas de evaluación si se usan con precaución y se ajustan con las instrucciones adecuadas.

• De forma más general, dado que los índices de referencia nunca serán perfectos, podría ser preferible pasar de una comparación pura de puntaje a técnicas más sólidas que capturen diferencias estadísticamente significativas. El trabajo de Arabzadeh et al. ofrece un buen ejemplo de esto, donde, basándose en sus hallazgos, crean intervalos de confianza del 95 % que indican diferencias significativas (o no) entre las distintas secuencias. En el cuaderno adjunto se encuentra una implementación de intervalos de confianza usando bootstrapping.

• Desde la perspectiva del usuario final, es útil pensar en la alineación de tareas al leer los resultados de los índices de referencia. Por ejemplo, para un ingeniero de IA que crea una pipeline RAG y sabe que el caso de uso más típico implica ensamblar múltiple información de diferentes fuentes, sería más significativo evaluar el rendimiento de su modelo de recuperación en sets de datos de QA multisaltos, como HotpotQA, en lugar de la media global de todo el índice de referencia BEIR

En la próxima publicación del blog profundizaremos en el uso de Phi-3 como juez de LLM y en el proceso de ajustarlo para predecir su relevancia.

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

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.