En este artículo, aprenderás cómo puedes utilizar el parámetro de puntuación mínima para aumentar la precisión de tus resultados de búsqueda semántica. Si deseas probar los ejemplos en esta publicación de blog, ve al cuaderno de Jupyter asociado.

Antecedentes: Precisión y recuperación

En la búsqueda, la relevancia, la precisión y la recuperación son conceptos clave. Se recomienda encarecidamente a todo lector que no esté familiarizado que se interiorice sobre estos conceptos. A continuación se presenta un resumen.

• Precisión: La fracción de resultados de búsqueda devueltos que son relevantes para el usuario.

• Recuerda: La fracción de todos los documentos relevantes del corpus que se incluyen en el conjunto de resultados de búsqueda.

O, en otras palabras, la precisión está devolviendo solo resultados relevantes; y la recuperación está devolviendo todos los resultados relevantes. Como puedes imaginar, estos son, a menudo, requisitos contradictorios. La búsqueda semántica tiende a tener una recuperación muy alta, pero puede tener dificultades con la precisión. Continúa leyendo para saber cómo moverte por esta propiedad.

Introducción del parámetro de puntaje mínimo

El parámetro "min_score" nos permite mejorar la precisión al establecer una puntuación mínima, lo que truncará el conjunto de resultados y eliminará cualquier coincidencia con una puntuación inferior al umbral definido. A continuación se muestra un ejemplo sencillo:

Normalizando la puntuación.

Establecer una puntuación mínima está bien; sin embargo, no todos los modelos semánticos devuelven una puntuación adecuada para un umbral estático. ELSER, por ejemplo, devuelve una puntuación que no tiene límite. Algunas puntuaciones de un modelo denso están estrechamente agrupadas y solo tienen sentido en el contexto de la consulta específica.

Para la mayoría de los casos de búsqueda semántica, recomendamos usar un enfoque de normalización antes de aplicar el "min_score". La normalización garantiza que la puntuación del documento esté dentro de un intervalo definido. Elasticsearch ofrece dos normalizadores, "l2_norm" y "minmax". El más comúnmente usado es "minmax", ya que es fácil de entender y funciona bien en muchos escenarios. Las propiedades clave de "minmax" incluyen:

• Las puntuaciones de los documentos se distribuyen entre 0 y 1.

• El documento con la puntuación más alta siempre tiene una puntuación de 1.

• El documento con la puntuación más baja siempre tiene una puntuación de 0.

  • Esto puede hacer que sea menos adecuado para la búsqueda por palabras clave. Consulta la sección “Búsqueda híbrida” para más información.

A continuación se muestra un ejemplo de una consulta semántica normalizada con min_score. El tamaño de la ventana de clasificación se ha aumentado a 500 para permitirnos devolver una lista más larga de resultados de búsqueda, comenzando en 100.

El tamaño se ha establecido en un valor más alto de lo que normalmente se ve en producción. Esto es para que podamos inspeccionar la calidad de los resultados de búsqueda y ajustar los resultados.

Búsqueda híbrida usando el retriever lineal

Para la búsqueda híbrida, el enfoque más sencillo es normalizar todos las puntuaciones, asignar ponderaciones y aplicar una puntuación mínima. Ten en cuenta que al elegir ponderaciones con una suma de 1, mantienes la puntuación total dentro de un rango de 0–1. Esto hace que sea más fácil entender las puntuaciones finales y afinar min_score. A continuación se muestra un ejemplo:

Búsqueda híbrida usando RRF.

Con BM25, a menudo controlamos la precisión por otros medios, usando, por ejemplo, el operador de AND o minimum_should_match. Además, las consultas que consisten en términos únicos, precisos y poco frecuentes naturalmente generarán resultados con pocos resultados de búsqueda, a menudo todos muy relevantes. Esto puede llevar a:

• Los resultados más lejanos en el resultado reciben una puntuación normalizada baja en el recuperador BM25, incluso si la puntuación absoluta de BM25 está cerca de las puntuaciones más altas.

• Al agregar una puntuación BM25 muy baja a la puntuación semántica, el total puede aproximarse a la puntuación semántica.

• La falta de contribución de la puntuación BM25 puede hacer que el documento sea descartado por el min_score threshold.

Como solución, podemos utilizar la fusión de rangos recíprocos (RRF) para combinar BM25 y los resultados semánticos. RRF consigue sortear el desafío de comparar puntuaciones de diferentes algoritmos de búsqueda al colocar el foco en la posición en cada conjunto de resultados. En este escenario, la min_score solo se aplica al recuperador semántico.

Conclusión

Al usar min_score, hemos demostrado cómo podemos reducir el número de falsos positivos en nuestros conjuntos de resultados causados por la alta recuperación de algoritmos de búsqueda semántica. Para saber más sobre los recuperadores, consulta esta publicación de blog y la documentación de Elasticsearch.

Sin embargo, cuando solucionas este problema, accidentalmente rompes otras consultas porque no pudiste probar todos los casos manualmente. Pero, ¿cómo puedes tú o tu equipo de control de calidad comprobar si un cambio en una consulta tiene un efecto dominó en otras consultas? O aún más importante, ¿cómo puedes estar seguro de que tus cambios realmente mejoraron una consulta?

Hacia una evaluación sistemática

Aquí es donde las listas de evaluación resultan útiles. En lugar de depender de pruebas manuales y subjetivas cada vez que realices un cambio, puedes definir un conjunto fijo de búsquedas que sean relevantes para tu caso de negocio, junto con sus resultados relevantes.

Este conjunto se convierte en tu referencia. Cada vez que implementas un cambio, lo utilizas para evaluar si tu búsqueda realmente mejoró o no.

El valor de este enfoque radica en que:

• Elimina la incertidumbre: ya no necesitas preguntarte si tus cambios afectan a otras consultas; los datos te lo dirán.

• Detiene las pruebas manuales: una vez que se registran los conjuntos de evaluación, la prueba es automática.

• Soporta cambios: puedes mostrar métricas claras que respaldan los beneficios de un cambio.

Cómo empezar a crear tu lista de evaluaciones

Una de las maneras más fáciles de comenzar es tomar una búsqueda representativa y seleccionar manualmente los documentos relevantes. Hay dos formas de hacer esta lista:

• Evaluaciones binarias: cada documento asociado con una búsqueda recibe una etiqueta simple: relevante (generalmente con una puntuación de “1”) y no relevante (“0”).

• Evaluaciones graduadas: aquí, cada documento obtiene una puntuación con diferentes niveles. Por ejemplo: establecer un escala de 0 a 4, similar a un escala Likert, donde 0 = “nada relevante” y 4 = “totalmente relevante”, con variaciones como “relevante”, “algo relevante”, etc.

Los juicios binarios funcionan bien cuando la intención de búsqueda tiene límites claros: ¿Debería este documento estar en los resultados o no?

Las evaluaciones graduadas son más útiles cuando hay áreas grises: algunos resultados son mejores que otros, así que puedes obtener resultados “muy buenos”, “buenos” e “inútiles” y usar métricas que valoren el orden de los resultados y los comentarios del usuario. Sin embargo, las escalas graduadas también presentan inconvenientes: diferentes revisores pueden usar los niveles de puntuación de manera diferente, lo que hace que las evaluaciones sean menos consistentes. Y debido a que las métricas graduadas dan más peso a las puntuaciones más altas, incluso un pequeño cambio (como calificar algo con un 3 en lugar de un 4) puede crear un cambio mucho mayor en la métrica de lo que el revisor pretendía. Esta subjetividad añadida hace que las evaluaciones graduadas sean más complicadas y difíciles de manejar con el tiempo.

¿Necesito clasificar los documentos por mi cuenta?

No necesariamente, ya que hay diferentes formas de crear tu lista de evaluaciones, cada una con sus propias ventajas y desventajas:

• Evaluaciones explícitas: aquí, los expertos revisan cada búsqueda/documento y deciden manualmente si es relevante (o qué tan relevante es). Si bien esto proporciona calidad y control, tiene menos escalabilidad.

• Evaluaciones implícitas: con este método, infieres los documentos relevantes en función del comportamiento real del usuario, como clics, tasa de rebote y compras, entre otros. Este enfoque te permite recopilar datos automáticamente, aunque puede estar sesgado. Por ejemplo, los usuarios tienden a hacer clic en los primeros resultados con más frecuencia, incluso si no son relevantes.

• Evaluaciones generadas por IA: esta última opción utiliza modelos (como LLM) para evaluar automáticamente consultas y documentos, a menudo referidos como jurados de LLM. Es rápido y fácil de escalar, pero la calidad de los datos depende de la calidad del modelo que estés utilizando y de qué tan bien los datos de entrenamiento de LLM se alinean con tus intereses comerciales. Al igual que con las calificaciones humanas, los jurados LLM pueden introducir sus propios sesgos o inconsistencias, por lo que es importante validar su salida contra un conjunto más pequeño de evaluaciones confiables. Los modelos LLM son probabilísticos por naturaleza, por lo que no es raro ver un modelo LLM dando diferentes calificaciones al mismo resultado independientemente de que el parámetro de temperatura sea 0.

A continuación, se incluyen algunas recomendaciones para elegir el mejor método para crear tu conjunto de evaluaciones:

• Decide cuán importantes son para ti algunas características que solo los usuarios puedan juzgar correctamente (como precio, marca, idioma, estilo y detalles del producto). Si esos son críticos, necesitas evaluaciones explícitas para al menos alguna parte de tu lista de evaluaciones.

• Usa evaluaciones implícitas cuando tu motor de búsqueda ya tenga suficiente tráfico para que puedas usar clics, conversiones y métricas de tiempo persistente para detectar tendencias de uso. Aun así, deberías interpretarlos con cuidado, contrastándolos con tus evaluaciones explícitas para prevenir sesgos (por ejemplo: los usuarios tienden a hacer clic más a menudo en los resultados mejor clasificados, incluso si los de menor rango son más relevantes)

Para abordar esto, las técnicas de eliminación del sesgo de posición ajustan o reponderan los datos de clics para reflejar mejor el verdadero interés del usuario. Algunos enfoques incluyen:

• Reordenación de resultados: cambia el orden de los resultados de búsqueda para un subconjunto de usuarios con el fin de estimar cómo afecta la posición a los clics.

• Los modelos de clics incluyenla red bayesiana dinámica (DBN) y el modelo de navegación del usuario (UBM). Estos modelos estadísticos estiman la probabilidad de que un clic refleje un interés real en lugar de solo la posición, utilizando patrones como el desplazamiento, el tiempo de permanencia, la secuencia de clics y el retorno a la página de resultados.

Ejemplo: app de valoración de películas

Requisitos previos

Para ejecutar este ejemplo, necesitas un cluster Elasticsearch 8.x en funcionamiento, localmente o Elastic Cloud Hosted (alojado o sin servidor), y acceso a la API REST o Kibana.

Imagina una app en la que los usuarios puedan realizar el monitoreo de tiempo de actividad de sus opiniones sobre películas y también hacer una búsqueda de películas para ver. Como los textos son escritos por los propios usuarios, pueden contener errores tipográficos y muchas variaciones en cuanto a la expresión. Por eso es fundamental que el motor de búsqueda sea capaz de interpretar esa diversidad y ofrecer resultados útiles para los usuarios.

Para poder repetir consultas sin afectar el comportamiento general de búsqueda, el equipo de negocios de tu empresa creó el siguiente conjunto de evaluaciones binarias, basado en las búsquedas más frecuentes:

Búsqueda

DocID

Texto

Actuación de DiCaprio

doc1

La actuación de DiCaprio en El renacido fue impresionante.

Actuación de DiCaprio

doc2

El origen muestra a Leonardo DiCaprio en uno de sus papeles más icónicos.

Actuación de DiCaprio

doc3

Brad Pitt ofrece una actuación estable en este thriller policial.

Actuación de DiCaprio

doc4

Una aventura llena de acción con impresionantes efectos visuales.

películas tristes que te hacen llorar

doc5

Una historia desgarradora de amor y pérdida que me hizo llorar durante horas.

películas tristes que te hacen llorar

doc6

Una de las películas más tristes de todos los tiempos: ¡trae pañuelos!

películas tristes que te hacen llorar

doc7

Una comedia ligera que te hará reír

películas tristes que te hacen llorar

doc8

Una epopeya de ciencia ficción llena de acción y emoción.

Creación del índice:

Solicitud en masa:

A continuación se muestra la consulta Elasticsearch que emplea la app:

De juicio a métricas

Por sí solas, las listas de evaluaciones no proporcionan mucha información; son solo una expectativa de los resultados de nuestras consultas. Donde realmente destacan es cuando los usamos para calcular métricas objetivo que midan nuestro rendimiento en búsqueda.

Actualmente, la mayoría de las métricas populares incluyen

• Precisión: mide la proporción de resultados que son realmente relevantes dentro de todos los resultados de búsqueda.

• Recuperación: mide la proporción de resultados relevantes que el motor de búsqueda encontró entre x resultados.

• Ganancia acumulada descontada (DCG):mide la calidad de la clasificación del resultado, considerando que los resultados más relevantes deben estar en la parte superior.

• Rango recíproco medio (MRR): mide la posición del primer resultado relevante. Cuanto más alto estés en la lista, mayor será tu puntuación.

Usando la misma app de clasificación de películas como ejemplo, calcularemos la métrica de recuperación para ver si hay alguna información que se esté excluyendo de nuestras consultas.

En Elasticsearch, podemos usar las listas de evaluaciones para calcular métricas mediante la API de Evaluación de Rankings. Esta API recibe como entrada la lista de evaluaciones, la consulta y la métrica que deseas evaluar, y devuelve un valor, que es una comparación del resultado de la consulta con la lista de evaluaciones.

Vamos a ejecutar la lista de evaluaciones para las dos consultas que tenemos:

Usaremos dos solicitudes para _rank_eval: una para la búsqueda de DiCaprio y otra para películas tristes. Cada solicitud incluye una búsqueda y su lista de evaluaciones (calificaciones). No necesitamos calificar todos los documentos ya que los que no se incluyen en las calificaciones se consideran sin evaluación. Para realizar los cálculos, recuerda que la recuperación solo considera “el conjunto relevante”, los documentos que se consideran relevantes en la clasificación.

En este caso, la búsqueda de DiCaprio tiene una recuperación de 1, mientras que las películas tristes obtuvieron 0. Esto significa que para la primera búsqueda, pudimos obtener todos los resultados relevantes, mientras que en la segunda búsqueda, no obtuvimos ninguno. Por tanto, la recuperación medio es de 0,5.

Tal vez estamos siendo demasiado estrictos con el parámetro minimum_should_match ya que al exigir que el 100 % de las palabras en la consulta se encuentren en los documentos, probablemente estamos excluyendo resultados relevantes. Eliminemos el parámetro minimum_should_match para que un documento se considere relevante si solo se encuentra una palabra de la consulta en él.

Como puedes ver, al eliminar el parámetro minimum_should_match en una de las dos consultas, ahora obtenemos una recuperación promedio de 1 en ambas.

En resumen, al eliminar la cláusula minimum_should_match: 100%, podemos obtener una recuperación perfecta para ambas búsquedas.

¡Lo logramos! ¿Cierto?

¡No tan rápido!

Al mejorar la memoria, abrimos la puerta a un rango más amplio de resultados. Sin embargo, cada ajuste implica una compensación. Por esto es importante definir casos de prueba completos, utilizando diferentes métricas para evaluar los cambios.

El uso de listas de evaluaciones y métricas previene que hagas cambios a ciegas, ya que ahora tienes datos para respaldarlos. La validación ya no es manual y repetitiva, y puedes probar tus cambios en más de un caso de uso. Además, las pruebas A/B te permiten probar en tiempo real qué configuración funciona mejor para tus usuarios y tu caso de negocio, cerrando así la brecha entre métricas técnicas y métricas reales.

Recomendaciones finales para el uso de listas de evaluaciones

Trabajar con listas de evaluaciones no solo consiste en medir, sino también en crear un marco de trabajo que te permita iterar con confianza. Para lograr esto, puedes seguir estas recomendaciones:

1. Empieza poco a poco, pero empieza. No es necesario que tengas 10 000 consultas con 50 listas de evaluaciones cada una. Solo necesitas identificar las 5 a 10 consultas más críticas para tu caso de negocio y definir qué documentos esperas ver en la parte superior de los resultados. Esto ya te da una base. Por lo general, te conviene comenzar con las consultas principales y las consultas sin resultados. También puedes comenzar a probar con una métrica fácil de configurar como Precisión y luego ir aumentando la complejidad.

2. Valida con los usuarios. Complementa los números con pruebas A/B en producción. De esta manera, sabrás si los cambios que se ven bien en las métricas también están generando un impacto real.

3. Haz un mantenimiento de la lista. Tu caso de negocio evolucionará, y también lo harán tus consultas críticas. Actualiza tu evaluación de forma periódica para reflejar las necesidades nuevas.

4. Haz que sea parte del flujo. Integra listas de evaluaciones en tus pipelines de desarrollo. Asegúrate de que cada cambio de configuración, sinónimo o análisis de texto se valide automáticamente contra tu lista base.

5. Conecta conocimientos técnicos con estrategia. No te limites a medir parámetros técnicos como la precisión o la recuperación. Usa tus resultados de la evaluación para influir en los resultados comerciales.

El problema del rango de puntaje

Para contextualizar, repasemos una de las principales razones por las que la búsqueda híbrida puede ser difícil: los rangos de puntaje variables. Nuestro viejo amigo BM25 produce puntajes ilimitados. En otras palabras, BM25 puede generar puntajes que van desde cerca de 0 hasta (teóricamente) infinitas. En cambio, las consultas contra dense_vector campos producirán puntajes acotados entre 0 y 1. Para empeorar este problema, semantic_text ofusca el tipo de campo empleado para indexar incrustaciones, así que a menos que tengas un conocimiento detallado sobre tu configuración de índices y endpoints de inferencia, puede ser difícil saber cuál será el rango de puntaje de tu consulta. Esto presenta un problema al intentar entrecalar resultados de búsqueda léxica y semántica, ya que los resultados léxicos pueden tener prioridad sobre los semánticos incluso si los resultados semánticos son más relevantes. La solución generalmente aceptada para este problema es normalizar los puntajes antes de entrelazar los resultados. Elasticsearch dispone de dos herramientas para esto: los retrievers lineales y RRF .

El recuperador RRF aplica el algoritmo RRF, usando el rango del documento como medida de relevancia y descartando el puntaje. Como el puntaje no se tiene en cuenta, las discrepancias en el rango de puntaje no son un problema.

El retriever lineal emplea una combinación lineal para determinar el puntaje final de un documento. Esto implica tomar el puntaje de cada consulta componente para el documento, normalizarla y sumarla para generar el puntaje total. Matemáticamente, la operación puede expresar como:

Donde N es la función de normalización, y SX es el puntaje para la consulta X. La función de normalización es clave aquí, ya que transforma el puntaje de cada consulta para usar el mismo rango. Puedes aprender más sobre el retriever lineal aquí.

Desglosándolo

Los usuarios pueden implementar una búsqueda híbrida eficaz con estas herramientas, pero requiere cierto conocimiento sobre tu índice. Veamos un ejemplo con el retriever lineal, donde consultaremos un índice con dos campos:

1. semantic_text_field es un campo semantic_text que emplea E5, un modelo de incrustación de texto

2. text_field es un campo estándar de text

1. Usamos una consulta match en nuestro campo semantic_text , para la que agregamos soporte en Elasticsearch 8.18/9.0

Al construir la consulta, debemos tener en cuenta que semantic_text_field emplea un modelo de incrustación de texto, por lo que cualquier consulta generará un puntaje entre 0 y 1. También necesitamos saber que text_field es un campo de text estándar y, por tanto, las consultas sobre él generarán un puntaje no acotada. Para crear un conjunto de resultados con la relevancia adecuada, necesitamos usar un retriever que normalice los puntajes de consulta antes de combinarlas. En este ejemplo, usamos el retriever lineal con minmax normalización, que normaliza el puntaje de cada consulta a un valor entre 0 y 1.

La construcción de la consulta en este ejemplo es bastante sencilla porque solo están involucrados dos campos. Sin embargo, puede complicar muy rápido a medida que se agregan más campos, y de diferentes tipos. Esto demuestra cómo escribir una consulta híbrida eficaz suele requerir un conocimiento más profundo del índice que se consulta, de modo que los puntajes de los componentes se normalicen correctamente antes de la combinación. Esto supone una barrera para la adopción más amplia de la búsqueda híbrida.

Agrupación de consultas

Ampliemos el ejemplo: ¿Y si quisiéramos consultar un campo text y dos campos semantic_text ? Podríamos construir una consulta así:

Eso parece bueno a simple vista, pero hay un posible problema. Ahora los semantic_text partidos de campo representan dos tercios del total del puntaje:

Probablemente esto no es lo que buscas porque crea un puntaje desequilibrado. Los efectos pueden no ser tan evidentes en un ejemplo como este con solo 3 campos, pero se vuelve problemático cuando se consultan más campos. Por ejemplo, la mayoría de los índices contienen muchos más cuerpos léxicos que la semántica (es decir, dense_vector, sparse_vector, o semantic_text). ¿Y si consultáramos un índice con 9 campos léxicos y 1 campo semántico usando el patrón anterior? Las coincidencias léxicas representarían el 90% del puntaje, lo que reduce la efectividad de la búsqueda semántica.

Una forma común de abordar esto es agrupar las consultas en categorías léxicas y semánticas y ponderar ambas de forma uniforme. Esto impide que cualquiera de las dos categorías domine el puntaje total.

Pongámoslo en práctica. ¿Cómo sería este enfoque de consultas agrupadas en este ejemplo al usar el retriever lineal?

¡Vaya, esto se está poniendo muy extenso! ¡Puede que incluso tuviste que desplazarte arriba y abajo varias veces para revisar toda la consulta! Aquí, usamos dos niveles de normalización para crear los grupos de consultas. Matemáticamente, puede expresar como:

Este segundo nivel de normalización garantiza que las consultas contra los campos semantic_text y text campo tengan un peso uniforme. Ten en cuenta que en este ejemplo omitimos la normalización de segundo nivel para text_field ya que solo hay un cuerpo léxico, lo que te ahorra aún más verbosidad.

Esta estructura de consulta ya es engorrosa y solo estamos consultando tres campos. Se vuelve cada vez más inmanejable, incluso para los profesionales experimentados en búsqueda, a medida que consultas más campos.

El formato de consulta multicampo

Agregamos el formato de consulta multicampo para los retrievers lineales y RRF en Elasticsearch 8.19, 9.1 y serverless para simplificar todo esto. Ahora puedes realizar la misma consulta que antes con simplemente:

¡Lo que reduce la consulta de 55 líneas a solo 9! Elasticsearch emplea automáticamente los mapeos de índice para:

• Determinar el tipo de cada campo consultado

• Agrupa cada cuerpo en una categoría léxica o semántica

• Pondera cada categoría de forma equitativa en el puntaje final

Esto permite a cualquiera ejecutar una consulta híbrida eficaz sin necesidad de conocer detalles sobre el índice o los endpoints de inferencia empleados.

Al usar RRF, puedes omitir la normalizer, ya que rango se usa como indicador de relevancia:

Impulso por campo

Al usar el retriever lineal, puedes aplicar un aumento por campo para ajustar la importancia de los combates en ciertos campos. Por ejemplo, supongamos que consultas cuatro campos: dos campos semantic_text y dos campos text :

Por defecto, cada cuerpo tiene un peso igual en su grupo (léxico o semántico). El desglose del puntaje es el siguiente:

En otras palabras, cada campo representa el 25% del puntaje total.

Podemos usar la sintaxis field^boost para agregar un impulso por campo a cualquier campo. Vamos a aplicar un aumento de 2 a semantic_text_field_1 y text_field_1:

Ahora el desglose del puntaje es así:

Cada grupo de consulta sigue teniendo un peso igual, pero ahora el peso del campo dentro de los grupos cambió:

• semantic_text_field_1 es el 66% del puntaje del grupo de consultas semánticas, 33% del puntaje total

• text_field_1 es el 66% del puntaje del grupo de consultas léxicas, 33% del puntaje total

i️ Ten en cuenta que el rango total de puntaje no cambiará cuando se aplica un aumento por campo. Este es un efecto secundario previsto de la normalización de puntajes, que garantiza que los puntajes de consulta léxica y semántica sigan siendo directamente comparables entre sí.

i️ El aumento por campo también puede usar con el recuperador RRF en Elasticsearch 9.2+

Resolución comodín

Puedes usar el comodín * en el parámetro fields para que coincida con varios campos. Continuando con el ejemplo anterior, esta consulta es funcionalmente equivalente a consultar semantic_text_field_1, semantic_text_field_2, y text_field_1 explícitamente:

Es interesante notar que el patrón de *_field_1 coincide tanto con text_field_1 como con semantic_text_field_1. Esto se gestiona automáticamente; La consulta se ejecutará como si cada uno de los campos fuera consultado explícitamente. También está bien que el semantic_text_field_1 coincida con ambos patrones; Todas las coincidencias de nombres de campo se deduplican antes de la ejecución de la consulta.

Puedes usar el comodín de varias maneras:

• Coincidencia de prefijos (ej: *_text_field)

• Emparejamiento en línea (ej: semantic_*_field)

• Coincidencia de sufijos (ej: semantic_text_field_*)

También puedes usar varios comodines para aplicar una combinación de lo anterior, como *_text_field_*.

Campos de consulta predeterminados

El formato de consulta multicampo también te permite consultar un índice del que no sabes nada. Si omites el parámetro fields , consultará todos los campos especificados por la configuración de índice index.query.default_field:

Por defecto, index.query.default_field está configurado como *. Este comodín se resolverá a todos los tipos de campo del índice que admitan consultas de término, que es la mayoría. Las excepciones son:

• dense_vector Campos

• rank_vector Campos

• Campos geométricos: geo_point, shape

Esta funcionalidad es especialmente útil cuando se quiere realizar una consulta de búsqueda híbrida sobre un índice proporcionado por un tercero. El formato de consulta multicampo permite ejecutar una consulta adecuada de forma sencilla. Simplemente excluye el parámetro fields y se consultarán todos los campos aplicables.

Conclusión

El problema del rango de puntaje puede hacer que la búsqueda híbrida efectiva sea un dolor de cabeza de implementar, especialmente cuando hay poca comprensión del índice que se consulta o de los endpoints de inferencia empleados. El formato de consulta multicampo para los retrievers lineales y RRF alivia este problema al empaquetar un enfoque automatizado de búsqueda híbrida basado en agrupación de consultas en una API simple y accesible. Funcionalidades adicionales, como el aumento por campo, la resolución de comodines y los campos de consulta por defecto, amplían la funcionalidad para cubrir muchos casos de uso.

Prueba hoy el formato de consulta multicampo

Puedes consultar los retrievers lineales y RRF con el formato de consulta multicampo en proyectos Serverless totalmente gestionados de Elasticsearch con una prueba gratis. También está disponible en versiones de pila a partir de la 8.19 y 9.1.

Empieza en minutos en tu entorno local con un solo comando:

Como muchos de nosotros, me siento a la vez eufórico y asombrado por el ritmo al que evolucionan las capacidades de la IA. Primero vimos cómo los grandes modelos de lenguaje (LLMs) y la búsqueda vectorial nos lanzaron a la revolución semántica, donde ya no buscábamos ni explorábamos palabras clave para encontrar cosas. Después, los LLMs nos mostraron nuevas formas de interactuar con nuestros datos, usando interfaces de chat para transformar solicitudes en lenguaje natural en respuestas que destilan vastas bases de conocimiento en resúmenes fáciles de consumir. Ya sabemos (¡ya!) tienen los inicios de la lógica automatizada impulsada por LLM en forma de flujos de trabajo de "IA agente" que pueden entender semánticamente una petición entrante, razonar los pasos a seguir y luego elegir entre las herramientas disponibles para ejecutar iterativamente acciones y alcanzar esos objetivos.

La promesa de la IA agente nos está obligando a evolucionar desde el uso principal de 'ingeniería de prompts' para moldear nuestras interacciones generativas con IA, hasta centrarnos en cómo podemos ayudar a las herramientas agenticas a obtener la información adicional más relevante y eficiente que el LLM debe tener en cuenta al generar sus respuestas — la 'ingeniería de contexto' es la próxima frontera. La búsqueda híbrida es, con diferencia, el medio más poderoso y flexible para sacar a la luz el contexto relevante, y la plataforma de Search AI de Elastic abre una nueva vía para aprovechar los datos en servicio de la ingeniería contextual. En este artículo, vamos a hablar de cómo los LLM cambiaron el mundo de la recuperación de información desde dos ángulos, y luego de cómo pueden trabajar juntos para obtener mejores resultados. Hay bastante terreno que cubrir...

Parte I: Cómo cambiaron los LLM la búsqueda

Empecemos desde el ángulo de cómo los LLM cambiaron la forma en que accedemos y recuperamos información.

Nuestro legado léxico

Todos vivimos en el mundo de la búsqueda léxica algo limitado (bastante bien, en la medida de lo posible) durante mucho tiempo. La búsqueda es la primera herramienta a la que recurrimos cuando investigamos o empezamos un nuevo proyecto, y hasta hace poco, nos correspondía formular nuestras consultas de una manera que un motor de búsqueda léxico comprenda. La búsqueda léxica se basa en asociar algún tipo de término de consulta con palabras clave que se encuentran en un corpus documental — independientemente de si el contenido es no estructurado o no estructurado. Para que una búsqueda léxica devuelva un documento como resultado, debe coincidir con esa palabra clave (o tener un vocabulario controlado como una lista de sinónimos o diccionario para establecer la conexión conceptual para nosotros).

Un ejemplo de consulta léxica multi-match

Al menos los motores de búsqueda tienen la capacidad de devolver resultados con un puntaje de relevancia. Los motores de búsqueda ofrecen una gran variedad de opciones de sintaxis de consulta para dirigir eficazmente los datos indexados y algoritmos de relevancia incorporados que puntuan los resultados en función de la intención de la sintaxis de consulta del usuario. Los motores de búsqueda se benefician de décadas de avances en algoritmos de clasificación de relevancia, y eso los convierte en una plataforma eficiente de recuperación de datos capaz de ofrecer resultados puntuados y ordenados según su relevancia para la consulta. Las bases de datos y otros sistemas que emplean SQL como su método principal para recuperar datos están en desventaja aquí: no existe un concepto de relevancia en una consulta de base de datos; Lo mejor que pueden hacer es ordenar los resultados alfabéticamente o numéricamente. La buena noticia es que obtendrás todos los resultados (recordación) con esas palabras clave, pero no necesariamente están en un orden útil respecto al motivo por el que las pediste (precisión). Es un punto importante, como veremos en breve...

Entra en escena el dragón (semántico)

El potencial de las representaciones vectoriales de la información como alternativa a la búsqueda por palabras clave se investigó durante bastante tiempo. Los vectores tienen mucho potencial porque nos sacan del modo de emparejamiento de contenido basado solo en palabras clave — al ser representaciones numéricas de términos y pesos, los vectores permiten que los conceptos sean matemáticamente cercanos según la comprensión que tiene un modelo de lenguaje sobre cómo se relacionan los términos entre sí en el ámbito de entrenamiento. El largo retraso en la búsqueda vectorial de propósito general se debió a que los modelos estaban mayormente limitados a dominios específicos, simplemente no eran lo suficientemente grandes para comprender suficientemente los muchos conceptos diferentes que un término podría representar en distintos contextos.

No fue hasta que los Grandes Modelos de Lenguaje (LLMs) aparecieron hace unos años, con su capacidad de capacitar con cantidades mucho mayores de datos (usando transformadores y atención), que la búsqueda vectorial se volvió práctica: el tamaño y la profundidad de los LLMs finalmente permitieron que los vectores almacenaran suficiente matiz para captar realmente el significado semántico. Ese aumento repentino en la profundidad de comprensión permitió que los LLMs ahora sirvieran a un gran número de funciones de procesamiento del lenguaje natural (PLN) que antes estaban bloqueadas, siendo quizás la más impactante la capacidad de inferir el siguiente término más probable de una secuencia dado el contexto de lo que hay en la secuencia hasta ese momento. La inferencia es el proceso que otorga a la IA generativa su capacidad casi humana para producir texto. El texto generado por IA se basa en la comprensión que tiene el LLM sobre cómo se relacionan los términos dentro de sus datos de entrenamiento y también emplea la redacción de la petición para desambiguar entre diferentes contextos en los que los términos pueden aparecer.

Por mágica que sea la IA generativa , existen limitaciones en los LLM que causan errores de calidad y precisión, comúnmente llamados alucinaciones. Las alucinaciones ocurren cuando el LLM no tiene acceso a la información (o no es guiado al contexto correcto) para basar su respuesta en la verdad, por lo que, siendo útil, generará en su lugar una respuesta segura y plausible que es inventada. Parte de la causa es que, aunque los LLMs aprenden el uso del lenguaje dentro de grandes dominios de información diversa, tienen que dejar de capacitar en un momento determinado, por lo que su comprensión tiene un factor de puntualidad — es decir, que el modelo solo puede saber qué era preciso hasta el momento en que dejó de capacitar. Otro factor para las alucinaciones es que el modelo normalmente no conoce datos privados (datos no disponibles en Internet público), y eso es especialmente significativo cuando esos datos contienen términos y nomenclatura específicos.

Bases de datos vectoriales

Los LLM vectorizan el contenido a su espacio de modelo empleando una técnica llamada incrustación de texto, que se refiere a incrustar o mapear el significado semántico del contenido dentro de la visión del mundo del modelo en función del entrenamiento recibido. Hay varios pasos para preparar y procesar contenido para incrustar, incluyendo el chunking y la tokenización (y tokenización de subpalabras). El resultado suele ser un conjunto de vectores densos que representan la comprensión del modelo sobre el significado de ese fragmento de contenido dentro de su espacio vectorial. El chunking es un proceso inexacto que pretende encajar el contenido en las limitaciones de las restricciones de procesamiento de un modelo para generar incrustaciones, mientras intenta agrupar texto relacionado en un bloque usando construcciones semánticas como indicadores de oraciones y párrafos.

La necesidad de hacer chunks puede crear cierta flexibilidad semántica en un documento incrustado porque los chunks individuales no están completamente asociados con otros chunks del mismo documento. La opacidad inherente de las redes neuronales puede empeorar esta flexibilidad: un LLM es realmente una "caja negra" donde las conexiones entre términos y conceptos establecidas durante el entrenamiento no son deterministas y no pueden interpretar para los humanos. Esto genera problemas de explicabilidad, repetibilidad, sesgos inconscientes y, potencialmente, pérdida de confianza y precisión. Aun así, la capacidad de conectar ideas semánticamente, sin estar atado a palabras clave específicas al enviar consultas, es extremadamente poderosa:

Un ejemplo de consulta semántica

Hay un aspecto más a considerar para las bases de datos vectoriales: ¡no son motores de búsqueda, son bases de datos! Cuando se realiza una búsqueda de similitud vectorial , los términos de consulta se codifican para encontrar un conjunto de coordenadas (incrustadas) dentro del espacio vectorial del modelo. Esas coordenadas se emplean entonces como el centro para encontrar los documentos que son los "vecinos más cercanos" al centro — es decir, el rango (o la posición en los resultados) de un documento se determina por la distancia de similitud calculada de las coordenadas de ese documento respecto a las coordenadas de la consulta. ¿En qué dirección debe prevalecer el ranking, cuál de los posibles contextos está más cerca de la intención del usuario? La imagen con la que la comparo es una escena de la película Stargate, donde tenemos los seis puntos de coordenada que se cruzan para indicarnos el destino (el centro), pero no podemos llegar sin conocer el "séptimo símbolo" — las coordenadas del punto de partida que representan la intención subjetiva del usuario. Así que, en lugar de que la clasificación relativa de los vectores se base en una esfera de similitud en constante expansión e indiferenciada, al considerar la intención subjetiva de la consulta mediante la sintaxis expresiva y el puntaje de relevancia, podemos obtener algo que se asemeje a un cilindro de relevancia subjetiva graduada.

Las capacidades de inferencia de un LLM podrían ayudar a identificar el contexto más probable que tiene para la consulta, pero el problema es que sin ayuda, las coordenadas de la consulta entrante solo pueden determinar por cómo se capacitó originalmente el modelo.

En cierto modo, se podría decir que la similitud vectorial va al extremo opuesto a una coincidencia estricta de palabras clave — su fortaleza radica en su capacidad para superar los problemas de desajuste de términos, pero casi en exceso: los LLM tienden a unificar conceptos relacionados en lugar de diferenciarlos. La similitud vectorial mejora nuestra capacidad para emparejar contenido semánticamente, pero no garantiza precisión porque puede pasar por alto palabras clave exactas y detalles específicos que el modelo no desambiguó lo suficiente. La búsqueda por similitud vectorial es poderosa en sí misma, pero necesitamos formas de correlacionar los resultados que recuperamos de una base de datos vectorial con los resultados de otros métodos de recuperación.

Técnicas de reclasificación

Ahora es un buen momento para mencionar una técnica general llamada reclasificación, que vuelve a puntuar o normalizar conjuntos de resultados a un orden de rangos unificado. La necesidad de reclasificar podría deber a que los resultados de múltiples fuentes o métodos de recuperación tengan mecanismos de clasificación/puntaje diferentes (¡o ninguno, SQL!), o bien se podría usar la reclasificación para alinear semánticamente los resultados de fuentes no semánticas con la consulta del usuario. La reclasificación es una operación de segunda etapa, es decir, un conjunto de resultados que fueron recogidos mediante algún método inicial de recuperación (es decir, SQL, búsqueda léxica, búsqueda vectorial) se reordenan con un método de puntaje diferente.

Existen varios enfoques disponibles, incluyendo Learning-To-Rank (LTR) y Reciprocal Rank Fusion (RRF) — LTR es útil para capturar características de los resultados de búsqueda (me gusta, valoraciones, clics, etc.) y usarlas para puntuar y potenciar o sesgar resultados. RRF es perfecto para fusionar resultados retornados de diferentes modalidades de consulta (por ejemplo, búsquedas en bases de datos léxicas y vectoriales) juntas en una única lista de resultados. Elastic también ofrece la flexibilidad de ajustar los puntajes mediante métodos de reclasificación lineal .

Sin embargo, una de las técnicas de reclasificación más efectivas es la reclasificación semántica, que emplea la comprensión semántica de un LLM para analizar las incrustaciones vectoriales tanto de la consulta como de los resultados juntos, y luego aplicar el puntaje/repuntuación de relevancia para determinar el orden final. El reranking semántico requiere, por supuesto, una conexión a un modelo de reclasificación, y Elasticsearch proporciona una API de inferencia que permite crear endpoints de reclasificación que aprovechan modelos integrados (Elastic Rerank), modelos importados de terceros o servicios alojados externamente como Cohere o Google Vertex AI. Luego puedes realizar un reordenamiento mediante la sintaxis de abstracción de la consulta del retriever :

Un ejemplo de operación de reclasificación de recuperadores en varias etapas

Suena genial, ¿verdad? Podemos realizar reclasificaciones con resultados de fuentes dispares y acercarnos a una comprensión semántica de todo tipo de contenido... La reclasificación semántica puede ser costosa tanto computacionalmente como en el tiempo de procesamiento requerido, y por ello, la reclasificación semántica solo puede hacer con un número limitado de resultados, lo que significa que la forma en que se recuperan esos resultados iniciales es importante.

El método de recuperación del contexto es importante

La intención subjetiva es un factor importante para determinar la precisión de un resultado y para valorar su relevancia. Sin la capacidad de considerar la intención del usuario para realizar la consulta (expresada mediante sintaxis flexible, o mediante reclasificación en la segunda etapa), solo podemos seleccionar de los contextos existentes ya codificados dentro del espacio del modelo. La forma en que normalmente abordamos esta falta de contexto es mediante técnicas como la Generación de Aumentos por Recuperación (RAG). El funcionamiento de RAG es que desplaza efectivamente las coordenadas de la consulta al incluir términos relacionados adicionales devueltos de una consulta previa para datos contextualmente relevantes. ¡Eso hace que el motor que proporciona ese contexto adicional y su método inicial para realizar la recuperación sean aún más importantes para la precisión del contexto!

Repasemos los diferentes métodos de recuperación de contexto y cómo pueden ayudar o perjudicar a una operación RAG:

• La recuperación de búsqueda híbrida sin motor de búsqueda sigue careciendo de relevancia subjetiva. Si la plataforma que proporciona RAG es principalmente SQL (lo que incluye la mayoría de las plataformas "data lake"), carece de puntaje de relevancia en la fase inicial de recuperación. Muchas plataformas de data lake ofrecen su propia versión de recuperación híbrida (no de búsqueda), normalmente combinando técnicas de reclasificación como la reclasificación semántica y la RRF en sus resultados de recuperación basada en SQL y bases de datos vectoriales. Un ordenamiento simple es obviamente insuficiente para la clasificación subjetiva, pero incluso cuando se usa como base para una operación de reclasificación semántica de segunda etapa, SQL como recuperación de primera etapa se convierte en un problema cuando el reclasificación semántica se realiza solo en los "k primeros resultados" — sin alguna forma de puntuar resultados en la recuperación, ¿qué garantía tenemos de que los mejores resultados estén realmente en los primeros resultados?

• La similitud vectorial por sí sola no es suficiente para RAGs. Realmente se debe a un conjunto de problemas que se acumulan: es la rapidez del embedding, junto con métodos ingenuos de fragmentación, cómo se calcula la similitud y el componente crucial que falta de la intención subjetiva. Uno de los principales objetivos de RAG es fundamentar las interacciones generativas de IA en la verdad objetiva, tanto para prevenir alucinaciones como para informar al LLM sobre la información privada que no conocía durante el entrenamiento. Podemos emplear el contexto adicional proporcionado por RAG para restringir y dirigir a los LLMs a considerar las conexiones y detalles que sabemos que son más importantes para responder a la pregunta que nos planteamos. Para ello, necesitamos usar tanto enfoques semánticos como léxicos.

• RAG grep/regex basado en archivos. Hay algunos sectores del universo de IA agente que apuntan al uso de ventanas de contexto enormemente ampliadas que acceden a archivos locales mediante grep y regex para RAG en lugar de plataformas externas de recuperación. La idea es que, con una ventana de contexto mucho más amplia disponible, los LLMs podrán establecer conexiones conceptuales dentro de su propio espacio de pensamiento en lugar de depender de fragmentos y múltiples métodos/plataformas de recuperación para recopilar información relevante. Aunque en teoría es cierto que tener un documento completo ofrece una imagen más completa que los segmentos del documento, esto solo puede funcionar en pequeños dominios de datos (o, por ejemplo, al suministrar archivos para vibecoding), y aun así, el método inicial de recuperación es un escaneo de todos los documentos con una coincidencia solo por palabra clave.

La búsqueda es más que una recuperación

Los motores de búsqueda están diseñados específicamente para hacer que las consultas sean lo más rápidas y flexibles posible. Internamente, emplean estructuras de datos especializadas para almacenar y recuperar diferentes tipos de datos de manera que se adapten a esos tipos de datos. Elasticsearch proporciona almacenamiento y consulta optimizados de prácticamente todo tipo de datos, incluyendo búsqueda léxica no estructurada/texto completo (coincidencia, frase, proximidad, multi-coincidencia), coincidencia y filtrado rápido de palabras clave (coincidencia exacta), rangos numéricos, fechas, direcciones IP, y es muy flexible en cómo almacena las estructuras de documentos (por ejemplo, Docs anidados o aplanados). Elasticsearch es también una base de datos vectorial nativa que puede almacenar y consultar tanto tipos vectoriales dispersos como densos, y seguimos explorando formas innovadoras (por ejemplo, Better Binary Quantization (BBQ) y DiskBBQ) para mantener la fidelidad de búsqueda mientras mejoramos la velocidad, escalabilidad y costos asociados al contenido vectorizado. La plataforma Elasticsearch también proporciona resiliencia y alta disponibilidad de datos integradas, e incluye capacidades de gestión del ciclo de vida de los datos como Searchable Snapshots que permiten mantener datos de poca frecuencia o de retención a largo plazo en un almacenamiento de objetos rentable, pero aún totalmente buscables.

La búsqueda híbrida es lo mejor de todos los mundos

Búsqueda híbrida (¡no solo recuperación híbrida!) combina las fortalezas de la búsqueda léxica tradicional con la comprensión semántica de los LLMs y la búsqueda por similitud vectorial. Esta sinergia permite dirigir resultados altamente relevantes en la fase de recuperación mediante cualquiera de las opciones flexibles de sintaxis de consulta que ofrece un motor de búsqueda: opciones de sintaxis impulsadas por intención y puntaje de relevancia, recuperación de datos multimodales, filtrado, agregaciones y sesgos. Con sintaxis de búsqueda como ES|QL y recuperadores de varias etapas, podemos combinar de forma flexible la búsqueda tradicional con búsqueda semántica, filtros y múltiples técnicas de reclasificación, todo en una sola petición.

Uno de los mayores beneficios de la búsqueda híbrida es que tus consultas pueden usar sintaxis especializada para múltiples tipos de datos diferentes simultáneamente. Esas diferentes sintaxis de consulta pueden usar no solo para encontrar resultados, sino también como filtros o agregaciones en los resultados. Por ejemplo, uno de los tipos de consulta más comunes que frecuentemente se combina con otra sintaxis es el análisis geoespacial. Puedes hacer cosas como consultar resultados que tengan coordenadas geográficas dentro de una distancia especificada de un punto, o aplicar agregaciones de tus resultados por región, o agregaciones para rastrear y alertar sobre movimientos dentro o fuera de una zona. Con la búsqueda híbrida tienes la flexibilidad de combinar sintaxis para dirigir los resultados de la manera más precisa, para recuperar el contenido más cercano a tu contexto.

Entreacto

Esta primera parte cuenta la historia de cómo la búsqueda vectorial cambió la forma en que podemos recuperar datos y sienta el terreno para los cambios que los LLMs trajeron a los mecanismos de consulta que empleamos para interactuar con los datos. Vamos a fingir que tuvimos que descomponer esto en varias partes para que los LLM pudieran entenderlo sin perder el contexto... ;-) Aprendamos más sobre por qué esto es importante en la Parte II: IA Agente y la necesidad de ingeniería de contexto, y en la Parte III volveremos a nuestra discusión sobre la búsqueda híbrida.

¡Conoce al retriever lineal!

En esta publicación, presentamos el  linear retriever, ¡nuestra última incorporación para apoyar la búsqueda híbrida! A diferencia de rrf, el recuperador de linear calcula una suma ponderada en todas las consultas que coinciden con un documento. Este enfoque conserva la importancia relativa de cada documento dentro de un conjunto de resultados al tiempo que permite un control preciso sobre la influencia de cada consulta en el puntaje final. Como resultado, proporciona una forma más intuitiva y flexible de ajustar la búsqueda híbrida.

Definición de un recuperador lineal donde el puntaje final se calculará como:

Es tan simple como:

¿Notas lo simple e intuitivo que es? (¡y muy similar a rrf!) Esta configuración le permite controlar con precisión cuánto contribuye cada tipo de consulta a la clasificación final, a diferencia de rrf, que se basa únicamente en clasificaciones relativas.

Queda una advertencia: knn puntajes pueden estar estrictamente limitados, dependiendo de la métrica de similitud empleada. Por ejemplo, con la similitud del coseno o el producto punto de los vectores estandarizados por unidades, los puntajes siempre estarán dentro del rango [0, 1] . Por el contrario, bm25 puntajes son menos previsibles y no tienen límites claramente definidos.

Escalando los puntajes: kNN vs BM25

Un desafío de la búsqueda híbrida es que diferentes recuperadores producen puntajes en diferentes escalas. Considere, por ejemplo, el siguiente escenario:

Puntajes de la consulta A:

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

100

1.5

1

0.5

Puntajes de la consulta B:

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

0.63

0.01

0.3

0.4

Puede ver la disparidad arriba: kNN puntajes oscilan entre 0 y 1, mientras que bm25 puntajes pueden variar enormemente. Esta diferencia hace que sea difícil establecer pesos óptimos estáticos para combinar los resultados.

Normalización al rescate: el normalizador MinMax

Para solucionar esto, introdujimos un normalizador de minmax opcional que escala los puntajes, de forma independiente para cada consulta, al rango de [0, 1] mediante la siguiente fórmula:

Esto conserva la importancia relativa de cada documento dentro del conjunto de resultados de una consulta, lo que facilita la combinación de puntajes de diferentes recuperadores. Con la normalización, los puntajes se convierten en:

Puntajes de la consulta A:

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

1.00

0.01

0.005

0.000

Puntajes de la consulta B:

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

1.00

0.000

0.465

0.645

Todos los puntajes ahora se encuentran en el rango de [0, 1] y optimizar la suma ponderada es mucho más sencillo, ya que ahora capturamos la importancia (relativa a la consulta) de un resultado en lugar de su puntaje absoluto y mantenemos la coherencia entre las consultas.

Ejemplo de recuperador lineal

Veamos un ejemplo ahora para mostrar cómo se ve lo anterior y cómo el linear retriever aborda algunas de las deficiencias de rrf. RRF se basa únicamente en rangos relativos y no considera las diferencias de puntaje reales. Por ejemplo, dadas estos puntajes:

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

100

1.5

1

0.5

puntaje de la fuerza de avance

0.03226

0.03252

0.03200

0.03125

RRF clasificaría los documentos como:

Sin embargo, doc1 tiene un puntaje de bm25 significativamente más alta que los demás, que rrf no logra capturar porque solo analiza los rangos relativos. El recuperador de linear , combinado con la normalización, explica correctamente tanto los puntajes como sus diferencias, produciendo una clasificación más significativa:

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

1

0.01

0.005

0

Como podemos ver en lo anterior, la gran clasificación y score de doc1 para bm25 se contabiliza adecuadamente y se refleja en los puntajes finales. Además de eso, todos los puntajes se encuentran ahora en el rango [0, 1] para que podamos compararlas y combinarlas de una manera mucho más intuitiva (e incluso construir procesos de optimización offline).

Poniéndolo todo junto

Para aprovechar al máximo el recuperador de linear con normalización, la solicitud de búsqueda tendría el siguiente aspecto:

Este enfoque combina lo mejor de ambos mundos: conserva la flexibilidad y el puntaje intuitivo del recuperador de linear , al tiempo que garantiza una escala de puntaje consistente con la normalización MinMax.

Al igual que con todos nuestros retrievers, el linear retriever se puede integrar en cualquier nivel de un árbol jerárquico de retriever, con soporte para explicabilidad, resaltado de coincidencias, colapso de campo y más.

Cuándo elegir el retriever lineal y por qué marca la diferencia

El linear retriever:

• Preserva la importancia relativa al aprovechar los puntajes reales, no solo los rangos.

• Permite el ajuste fino con contribuciones ponderadas de diferentes consultas.

• Mejora la coherencia mediante la normalización, lo que hace que la búsqueda híbrida sea más estable y previsible.

Conclusión

El recuperador de linear ya está disponible en Elasticsearch Serverless y en las versiones 8.18 y 9.0. También se pueden encontrar más ejemplos y parámetros de configuración en nuestra documentación. Pruébelo y vea cómo puede mejorar su experiencia de búsqueda híbrida: esperamos sus comentarios. ¡Feliz búsqueda!

Quepid apoya a los equipos de búsqueda en el proceso de evaluación de la calidad de búsqueda:

• Construcción de conjuntos de consultas

• Crear listas de juicios

• Calcular métricas de calidad de búsqueda

• Compara diferentes algoritmos/rankingers de búsqueda basándote en métricas calculadas de calidad de búsqueda

Para nuestro blog, supongamos que gestionamos una tienda de alquiler de películas y que tenemos como objetivo mejorar la calidad de los resultados de búsqueda.

Prerrequisitos

Este blog emplea los datos y los mapeos del repositorio es-tmdb. Los datos provienen de The Movie Database. Para seguir el ritmo, configura un índice llamado tmdb con los mapeos e indexa los datos. No importa si configuras una instancia local o usas un despliegue de Elastic Cloud para esto: cualquiera de las dos funciona bien. Asumimos un despliegue de Elastic Cloud para este blog. Puedes encontrar información sobre cómo indexar los datos en el README del repositorio es-tmdb.

Haz una consulta sencilla de coincidencias en el campo del título para rocky confirmar que tienes datos para buscar:

Deberías ver 8 resultados.

Iniciar sesión en Quepid

Quepid es una herramienta que permite a los usuarios medir la calidad de los resultados de búsqueda y ejecutar experimentos offline para mejorarla.

Puedes usar Quepid de dos maneras: o bien usar la versión gratis y disponible públicamente alojada en https://app.quepid.com, o configura Quepid en una máquina a la que tengas acceso. Esta publicación asume que estás usando la versión alojada gratis. Si quieres configurar una instancia de Quepid en tu entorno, sigue la Guía de Instalación.

Sea cual sea la configuración que elijas, tendrás que crear una cuenta si aún no tienes una.

Cómo configurar un caso de Quepid

Quepid está organizado en torno a los "Casos". Un caso almacena consultas junto con ajustes de relevancia y cómo establecer una conexión con tu motor de búsqueda.

• Para usuarios primerizos, selecciona Crear tu primer caso de relevancia.

• Los usuarios que regresan pueden seleccionar Casos de Relevancia desde el menú superior y hacer clic en + Crear un caso.

Nombra tu caso de forma descriptiva, por ejemplo, "Línea base de búsqueda de películas", ya que queremos empezar a medir y mejorar nuestra búsqueda de referencia.

Confirma el nombre seleccionando Continuar.

A continuación, establecemos una conexión de Quepid con el motor de búsqueda. Quepid puede conectarse a una variedad de motores de búsqueda, incluido Elasticsearch.

La configuración variará según tu configuración de Elasticsearch y Quepid. Para conectar Quepid a un despliegue de Elastic Cloud, necesitamos habilitar y configurar CORS para nuestro despliegue de Elastic Cloud y tener lista una clave de API. Las instrucciones detalladas están en el tutorial correspondiente en la documentación de Quepid.

Introduce la información de tu endpoint de Elasticsearch (https://YOUR_ES_HOST:PORT/tmdb/_search) y cualquier información adicional necesaria para conectarte (la clave API en caso de un despliegue de Elastic Cloud en las opciones de configuración avanzada ), prueba la conexión haciendo clic en ping y selecciona Continuar para pasar al siguiente paso.

Ahora definimos qué campos queremos que se muestren en el caso. Selecciona todos los que ayuden a nuestros evaluadores humanos a evaluar posteriormente la relevancia de un documento para una consulta determinada.

Establece title como Campo de Título, deja _id como Campo ID y agrega overview, tagline, cast, vote_average, thumb:poster_path como Campos de Visualización Adicionales. La última entrada muestra pequeñas imágenes en miniatura de las películas en nuestros resultados para guiarnos visualmente a nosotros y a los evaluadores humanos.

Confirma la configuración de pantalla seleccionando el botón Continuar .

El último paso es agregar consultas de búsqueda al caso. Agrega las tres consultas Star Wars, Harrison Ford y la mejor película de acción una por una a través del campo de entrada y Continúa.

Idealmente, un caso contiene consultas que representan consultas reales de usuarios e ilustran diferentes tipos de consultas. Por ahora, podemos imaginar que Star Wars es una consulta que representa todas las consultas de títulos de películas, Harrison Ford una consulta que representa todas las consultas de los miembros del reparto, y Best Action Movie una consulta que representa todas las consultas que buscan películas de un género específico. Esto se denomina típicamente conjunto de consultas.

En un escenario de producción, muestrearíamos consultas de datos de seguimiento de eventos aplicando técnicas estadísticas como ejemplificación de probabilidad proporcional al tamaño e importaríamos estas consultas muestreadas a Quepid para incluir consultas desde la cabeza (consultas frecuentes) y cola (consultas poco frecuentes) en relación con su frecuencia, lo que significa que tendemos a optar por consultas más frecuentes sin excluir las raras.

Finalmente, selecciona Terminar y serás redirigido a la interfaz de casos donde verás las tres consultas definidas.

Búsquedas y necesidades de información

Para llegar a nuestro objetivo general de una lista de juicios, los evaluadores humanos deberán juzgar un resultado de búsqueda (normalmente un documento) para una consulta determinada. Esto se llama par consulta/documento.

A veces, parece fácil saber qué quería un usuario al revisar la consulta. La intención detrás de la harrison ford es encontrar películas protagonizadas por Harrison Ford, el actor. ¿Y qué pasa con la actionde la consulta? Sé que me tentaría decir que la intención del usuario es encontrar películas del género de acción. ¿Pero cuáles? ¿Los más recientes, los más populares, los mejores según las valoraciones de los usuarios? ¿O quizá el usuario quiere encontrar todas las películas que se llaman "Acción"? Hay al menos 12 (!) películas llamadas "Acción" en The Movie Database y sus nombres difieren principalmente en el número de signos de exclamación en el título.

Dos evaluadores humanos pueden diferir en la interpretación de una consulta cuando la intención no está clara. Entra en escena la necesidad de información: Una necesidad de información es un deseo consciente o inconsciente de información. Definir una necesidad de información ayuda a los evaluadores humanos a juzgar documentos para una consulta, por lo que desempeñan un papel importante en el proceso de elaboración de listas de juicio. Los usuarios expertos o expertos en la materia son buenos candidatos para especificar necesidades de información. Es buena práctica definir las necesidades de información desde la perspectiva del usuario, ya que es su necesidad la que los resultados de búsqueda deben satisfacer.

Necesidades de información para las consultas de nuestro caso "Línea de Base de Búsqueda de Películas":

1. Star Wars: El usuario quiere encontrar películas o seriales de la franquicia Star Wars. Potencialmente relevantes son los documentales sobre Star Wars.

2. Harrison Ford: El usuario quiere encontrar películas protagonizadas por el actor Harrison Ford. Potencialmente relevantes son las películas en las que Harrison Ford tiene un papel diferente, como el de narrador.

3. mejor película de acción: El usuario quiere encontrar películas de acción, preferiblemente aquellas con votos medios altos.

Cómo definir las necesidades de información en Quepid

Para definir una necesidad de información en Quepid, accede a la interfaz de casos:

1. Abre una consulta (por ejemplo,s tar wars) y selecciona Alternar Notas.

2. Introduce la Necesidad de Información en el primer campo y cualquier nota adicional en el segundo campo:

3. Haz clic en almacenar.

Para un puñado de consultas, este proceso está bien. Sin embargo, cuando amplías tu caso de tres a 100 consultas (los casos de Quepid suelen estar en el rango de 50 a 100 consultas), puede que quieras definir necesidades de información fuera de Quepid (por ejemplo, en una hoja de cálculo) y luego subirlas mediante Importar y seleccionar Necesidades de Información.

Crea un equipo en Quepid y comparte tu caso

Los juicios colaborativos mejoran la calidad de las evaluaciones de relevancia. Para formar un equipo:

1. Navega a Teams en el menú superior.

2. Haz clic + Agregar Nuevo, introduce el nombre de un equipo (por ejemplo, "Search Relevance Raters") y haz clic en Crear.

3. Agregar miembros escribiendo sus direcciones de email y haciendo clic en Agregar usuario.

4. En la interfaz de casos, selecciona Compartir Caso.

5. Elegir el equipo adecuado y confirmarlo.

Crea un libro de evaluaciones en Quepid

Un libro en Quepid permite a varios evaluadores evaluar sistemáticamente los pares consulta/documento. Para crear uno:

1. Ve a Sentencias en la interfaz del caso y haz clic + Crear un libro.

2. Configura el libro con un nombre descriptivo, asigna el libro a tu equipo, selecciona un método de puntaje (por ejemplo, DCG@10) y establece la estrategia de selección (uno o varios evaluadores). Emplea los siguientes ajustes para el libro:

• Nombre: "Búsqueda de películas a escala 0-3"

• Equipos con los que compartir este libro: Marca la casilla con el equipo que creaste

• Goleador: DCG@10

3. Haz clic en Crear libro.

El nombre es descriptivo y contiene información sobre lo que se busca en ("Películas") y también la escala de las sentencias ("0-3"). El DCG@10 seleccionado de Scorer define la forma en que se calculará la métrica de búsqueda. "DCG" es la abreviatura de Ganancia Acumulada Descontada y "@10" es el número de resultados desde la parte superior que se tiene en cuenta al calcular la métrica.

En este caso, estamos usando una métrica que mide la ganancia de información y la combina con ponderación posicional. Puede que haya otras métricas de búsqueda más adecuadas para tu caso de uso y elegir la adecuada es un desafío en sí mismo.

Llena el libro con pares de búsqueda/documento

Para agregar pares de consulta/documento para la evaluación de relevancia, sigue estos pasos:

1. En la interfaz del caso, navega a "Sentencias".

2. Selecciona tu libro creado.

3. Haz clic en "Poblar libro" y confirma seleccionando "Actualizar pares de consulta/documentos para libro."

Esta acción genera pares basados en los principales resultados de búsqueda de cada consulta, listos para su evaluación por parte de su equipo.

Deja que tu equipo de evaluadores humanos juzgue

Hasta ahora, los pasos completados fueron bastante técnicos y administrativos. Ahora que esta preparación necesaria está hecha, podemos dejar que nuestro equipo de jueces haga su trabajo. En esencia, el trabajo del juez es valorar la relevancia de un documento concreto para una consulta determinada. El resultado de este proceso es la lista de juicios que contiene todas las etiquetas de relevancia para los pares de documentos de consulta evaluados. A continuación, se explica este proceso y la interfaz para él con más detalle.

Visión general de la interfaz de calificación humana

La interfaz de calificación humana de Quepid está diseñada para evaluaciones eficientes:

• Consulta: Muestra el término de búsqueda.

• Necesidad de información: Muestra la intención del usuario.

• Directrices de puntaje: Proporciona instrucciones para evaluaciones consistentes.

• Metadatos del documento: Presenta detalles relevantes sobre el documento.

• Botones de valoración: Permite a los evaluadores asignar juicios con los atajos de teclado correspondientes.

Uso de la interfaz de calificación humana

Como evaluador humano, accedo a la interfaz a través de la visión general del libro:

1. Navega a la interfaz del caso y haz clic en Sentencias.

2. ¡Haz clic en Más Juicios Se Necesitan!

El sistema presentará un par de consulta/documento que aún no fue valorado y que requiere juicios adicionales. Esto está determinado por la estrategia de selección del Libro:

• Evaluador único: Un único juicio por par de consulta/documento.

• Evaluadores múltiples: hasta tres juicios por par de consulta/documento.

Calificación de pares de búsqueda/documento

Vamos a repasar un par de ejemplos. Al seguir esta guía, lo más probable es que te presenten diferentes películas. Sin embargo, los principios de clasificación se mantienen igual.

Nuestro primer ejemplo es la película "Heroes" para la consulta de Harrison Ford:

Primero analizamos la consulta, seguida de la necesidad de información y después juzgamos la película en función de los metadatos proporcionados.

Esta película es un resultado relevante para nuestra consulta, ya que Harridson Ford forma parte del reparto. Puede que consideremos las películas más recientes como más relevantes subjetivamente, pero esto no forma parte de nuestra necesidad informativa. Así que calificamos este documento con "Perfecto", que es un 3 en nuestra escala de calificación.

Nuestro siguiente ejemplo es la película "Ford v Ferrari" para la consulta Harrison Ford:

Siguiendo la misma práctica, juzgamos esta consulta/documento analizando la consulta, la necesidad de información y luego cuán bien los metadatos del documento coinciden con la necesidad de información.

Este es un resultado pobre. Probablemente veamos este resultado como uno de nuestros términos de consulta, "ford", coincide en el título. Pero Harrison Ford no tiene ningún papel en esta película, ni en ningún otro. Así que calificamos este documento como "Pobre", que es un 0 en nuestra escala de calificación.

Nuestro tercer ejemplo es la película "Action Jackson" para la mejor película de acción que se pregunta:

Esto parece una película de acción, así que la necesidad de información está al menos parcialmente cubierta. Sin embargo, la media de votos es de 5,4 sobre 10. Y eso hace que esta película probablemente no sea la mejor de acción de nuestra colección. Esto me llevaría, como juez, a calificar este documento como "Justo", que es un 1 en nuestra escala de calificación.

Estos ejemplos ilustran el proceso de valorar pares de consulta/documento con Quepid en individua, tanto a nivel general como en general.

Mejores prácticas para evaluadores humanos

Los ejemplos mostrados pueden hacer que parezca fácil llegar a juicios explícitos. Pero establecer un programa fiable de valoración humana no es tarea fácil. Es un proceso lleno de desafíos que pueden comprometer fácilmente la calidad de tus datos:

• Los evaluadores humanos pueden fatigar por tareas repetitivas.

• Las preferencias personales pueden sesgar los juicios.

• Los niveles de experiencia en el sector varían de un juez a otro.

• Los evaluadores suelen compaginar múltiples responsabilidades.

• La relevancia percibida de un documento puede no coincidir con su verdadera relevancia para una consulta.

Estos factores pueden dar lugar a juicios inconsistentes y de baja calidad. Pero no te preocupes: existen buenas prácticas probadas que pueden ayudarte a minimizar estos problemas y construir un proceso de evaluación más estable y fiable:

• Evaluación constante: Revisa la consulta, la necesidad de información y los metadatos del documento en orden.

• Consulte las Directrices: Emplea directrices de puntaje para mantener la consistencia. Las directrices de puntaje pueden incluir ejemplos de cuándo aplicar cada nota, lo que ilustra el proceso de evaluación. Tener una consulta con evaluadores humanos tras la primera tanda de sentencias resultó ser una buena práctica para aprender sobre casos límite difíciles y dónde se necesita apoyo adicional.

• Aprovecha las opciones: Si tienes dudas, emplea "Juzgaré más tarde" o "No puedo saberlo", proporcionando explicaciones cuando sea necesario.

• Toma descansos: Las pausas regulares ayudan a mantener la calidad del juicio. Quepid ayuda con los descansos regulares haciendo estallar confeti cada vez que un evaluador humano termina un serial de juicios.

Siguiendo estos pasos, estableces un enfoque estructurado y colaborativo para crear listas de juicios en Quepid, mejorando la eficacia de tus esfuerzos de optimización de relevancia en búsqueda.

Pasos siguientes

¿A dónde ir a partir de aquí? Las listas de juicio son solo un paso fundamental para mejorar la calidad de los resultados de búsqueda. Aquí están los siguientes pasos:

Calcula métricas y comienza a experimentar

Una vez que hay listas de juicios disponibles, aprovechar dichos juicios y calcular métricas de calidad de búsqueda es una progresión natural. Quepid calcula automáticamente la métrica configurada para el caso actual cuando hay sentencias disponibles. Las métricas se implementan como "Puntuadores" y puedes proporcionar las tuyas propias cuando las compatibles no incluyen a tu favorito.

Ve a la interfaz del caso, navega hasta Seleccionar Anotador, elige DCG@10 y confirma haciendo clic en Seleccionar Anotador. Quepid ahora calculará DCG@10 por consulta y también promediará el número total de consultas para cuantificar la calidad de los resultados de búsqueda de tu caso.

Ahora que la calidad de los resultados de búsqueda está cuantificada, puedes realizar los primeros experimentos. La experimentación comienza generando hipótesis. Mirar las tres consultas en la captura de pantalla tras hacer algunas valoraciones queda claro que las tres consultas rinden de forma muy diferente en cuanto a la métrica de calidad de búsqueda: Star Wars funciona bastante bien, Harrison Ford parece aceptable pero el mayor potencial está en la mejor película de acción.

Ampliando esta consulta, vemos sus resultados y podemos profundizar en los detalles más minuciosos y explorar por qué los documentos coincidieron y qué influye en sus puntajes:

Al hacer clic en "Explicar la consulta" y entrar en la pestaña "Análisis sintáctico" vemos que la consulta es una búsqueda de DisjunctionMaxxQuery en tres campos: cast, resumen y título:

Normalmente, como ingenieros de búsqueda, conocemos algunos detalles específicos de nuestro dominio sobre nuestra plataforma de búsqueda. En este caso, puede que sepamos que tenemos un campo de géneros . Vamos a agregar eso a la consulta y ver si la calidad de búsqueda mejora.

Usamos el Sandbox de Consultas que se abre al seleccionar Relevancia de Ajuste en la interfaz de casos. Adelante, explora esto agregando el campo de géneros en el que busques:

¡Haz clic en Volver a Ejecutar Mis Búsquedas! Y mira los resultados. ¿Cambiaron? Desgraciadamente no. Ahora tenemos muchas opciones para explorar, básicamente todas las opciones de consulta que ofrece Elasticsearch:

• Podríamos aumentar el peso del campo en el campo de géneros.

• Podríamos agregar una función que aumente los documentos por su media de votos.

• Podríamos crear una consulta más compleja que solo mejore los documentos por su promedio de votos si hay una coincidencia fuerte de géneros.

• …

Lo mejor de tener todas estas opciones y explorarlas en Quepid es que tenemos una forma de cuantificar los efectos no solo en la única consulta que intentamos mejorar, sino en todas las consultas que tenemos en nuestro caso. Eso nos impide mejorar una consulta que no rinde sacrificando la calidad de los resultados de búsqueda para otras. Podemos iterar rápida y barata y validar el valor de nuestra hipótesis sin ningún riesgo, haciendo de la experimentación offline una capacidad fundamental de todos los equipos de búsqueda.

Mide la confiabilidad entre evaluadores

Incluso con descripciones de tareas, necesidades de información y una interfaz de evaluador humano como la que ofrece Quepid, los evaluadores humanos pueden discrepar.

El desacuerdo en sí mismo no es algo malo, todo lo contrario: medir el desacuerdo puede sacar a la luz cuestiones que quizá quieras abordar. La relevancia puede ser subjetiva, las consultas pueden ser ambiguas y los datos pueden ser incompletos o incorrectos. El Kappa de Fleiss es una medida estadística del acuerdo entre evaluadores y hay un cuaderno de ejemplo en Quepid que puedes usar. Para encontrarlo, selecciona Cuadernos en la navegación superior y selecciona el cuaderno Fleiss Kappa.ipynb en la carpeta de ejemplos .

Conclusión

Quepid te permite afrontar incluso los retos de relevancia en búsquedas más complejos y sigue evolucionando: desde la versión 8, Quepid soporta juicios generados por IA, lo cual es especialmente útil para equipos que quieren escalar su proceso de generación de juicios.

Los flujos de trabajo quepid te permiten crear listas de juicios escalables de forma eficiente, lo que finalmente resulta en resultados de búsqueda que realmente satisfacen las necesidades de los usuarios. Con listas de juicios establecidas, tienes una base estable para medir la relevancia en las búsquedas, iterar mejoras y mejorar la experiencia de usuario.

A medida que avanzas, recuerda que la afinación de la relevancia es un proceso continuo. Las listas de juicio te permiten evaluar sistemáticamente tu progreso, pero son más poderosos cuando se combinan con experimentación, análisis métrico y mejoras iterativas.

Lecturas adicionales

• Documentos de Quepid:

  • La relevancia es un deporte de equipo

  • Quepid para evaluadores humanos

  • Cómo conectar Quepid a Elastic Cloud

• Repositorio de Quepid en Github

• Conoce a Pete, un serial de blogs sobre cómo mejorar la búsqueda en comercio electrónico

• Relevance Slack: únete al canal #quepid

Colabora con Open Source Connections para transformar tus capacidades de búsqueda e inteligencia artificial y empoderar a tu equipo para que las evolucione continuamente. Nuestro historial probado abarca todo el mundo, con clientes que logran de forma constante mejoras notables en la calidad de búsqueda, la capacidad del equipo y el rendimiento empresarial. Contacta con nosotros hoy mismo para obtener más información.

Filtros vs facetas

Antes de empezar, definamos qué son los filtros y las facetas. Los filtros son atributos predefinidos que se emplean para restringir un conjunto de resultados. En un mercado, por ejemplo, los filtros están disponibles incluso antes de que se realice una búsqueda. El usuario puede seleccionar una categoría, como "Juegos de video", antes de buscar "PS5", refinando la búsqueda a un subconjunto más específico en lugar de a toda la base de datos. Esto aumenta significativamente las posibilidades de obtener resultados más relevantes.

Las facetas funcionan de forma similar a los filtros, pero solo están disponibles luego de realizar la búsqueda. En otras palabras, la búsqueda devuelve resultados y, a partir de ellos, se genera una nueva lista de opciones de refinamiento. Por ejemplo, al buscar una consola PS5, pueden mostrar aspectos como la capacidad de almacenamiento, el costo de envío y el color para ayudar a los usuarios a elegir el producto ideal.

Ahora que definimos filtros y facetas, hablemos del impacto de los enfoques tradicionales y basados en Aprendizaje Automático (ML) en su implementación y uso. Cada método tiene beneficios y desafíos que influyen en la eficiencia de búsqueda.

Enfoque tradicional de filtros y facetas

En este enfoque, los filtros y facetas se definen manualmente basar en reglas predefinidas. Esto significa que los atributos disponibles para perfeccionar la búsqueda están fijos y planeados con antelación, teniendo en cuenta la estructura del catálogo y las necesidades del usuario.

Por ejemplo, en un mercado, categorías como "Electrónica" o "Moda" pueden tener filtros específicos como marca, formato y rango de precio. Estas reglas se crean de forma estática, garantizando la coherencia en la experiencia de búsqueda pero requiriendo ajustes manuales cada vez que surgen nuevos productos o categorías.

Aunque este enfoque proporciona previsibilidad y control sobre los filtros y facetas mostrados, puede ver limitado cuando surgen nuevas tendencias que exigen refinamiento dinámico.

Pros:

• Previsibilidad y control: Como los filtros y facetas se definen manualmente, la gestión se vuelve más sencilla.

• Baja complejidad: No hace falta capacitar modelos.

• Facilidad de mantenimiento: Como las reglas están predefinidas, se pueden hacer ajustes y correcciones rápidamente.

Contras:

• Reindexación necesaria para nuevos filtros: Cada vez que un nuevo atributo necesita usar como filtro, todo el conjunto de datos debe reindexar para cerciorar que los documentos contengan esta información.

• Falta de adaptación dinámica: Los filtros son estáticos y no se ajustan automáticamente a los cambios en el comportamiento del usuario.

Implementación de filtros/facetas – Enfoque tradicional

En Dev Tools, Kibana, crearemos una demostración de filtros/facetas usando el enfoque tradicional.

Primero, definimos la asignación para estructurar el índice:

Los campos de marca y almacenamiento se establecen como palabra clave, lo que permite usarlos directamente en agregaciones (facetas). El campo de precios es de tipo float, lo que permite la creación de rangos de precio.

En el siguiente paso, los datos del producto se indexarán:

Ahora, recuperemos los aspectos tradicionales agrupando los resultados por marca, almacenamiento y rango de precio. En la consulta, se definió size:0. En este escenario, el objetivo es recuperar solo los resultados de la agregación sin incluir los documentos correspondientes a la consulta.

La respuesta incluirá recuentos para Marca, Almacenamiento y Precio, ayudando a crear filtros y facetas.

Machine learning y enfoque basado en IA para filtros y facetas

En este enfoque, los modelos de Aprendizaje Automático (ML), incluidas las técnicas de Inteligencia Artificial (IA), analizan atributos de datos para generar filtros y facetas relevantes. En lugar de depender de reglas predefinidas, ML/IA aprovecha características de datos indexados. Esto permite el descubrimiento dinámico de nuevas facetas y filtros.

Beneficios:

• Actualizaciones automáticas: Se generan automáticamente nuevos filtros y facetas, sin necesidad de ajustes manuales.

• Descubrimiento de nuevos atributos: Puede identificar características de datos previamente no consideradas como filtros, enriqueciendo la experiencia de búsqueda.

• Reducción del esfuerzo manual: El equipo no necesita definir y actualizar constantemente las reglas de filtrado mientras la IA aprende de los datos disponibles.

Contras:

• Complejidad del mantenimiento: El uso de modelos puede requerir una pre-validación para cerciorar la consistencia de los filtros generados.

• Requiere conocimientos en ML e IA: La solución requiere profesionales cualificados para afinar y monitorizar el rendimiento del modelo.

• Riesgo de filtros irrelevantes: Si el modelo no está bien calibrado, puede generar facetas que no son útiles para los usuarios.

• Costar: El uso de aprendizaje automático e inteligencia artificial puede requerir servicios de terceros, aumentando los costos operativos.

Cabe destacar que, incluso con un modelo bien calibrado y un prompt bien elaborado, los aspectos generados deberían pasar por un paso de revisión. Esta validación puede ser manual o basar en normas de moderación, cerciorando que el contenido sea adecuado y seguro. Aunque no necesariamente supone un inconveniente, es importante cerciorar la calidad e idoneidad de los aspectos antes de que estén disponibles para los usuarios.

Implementación de filtros/facetas – enfoque de IA

En esta demostración, emplearemos un modelo de IA para analizar automáticamente las características del producto y sugerir atributos relevantes. Con un prompt bien estructurado, extraemos información del catálogo y la transformamos en filtros y facetas. A continuación, presentamos cada paso del proceso.

Inicialmente, emplearemos la API de Inferencia para registrar un endpoint para su integración con un servicio de ML. A continuación se muestra un ejemplo de integración con el servicio de OpenAI.

Ahora, definimos la tubería para ejecutar el prompt y obtener los nuevos filtros generados por el modelo.

Ejecutando una simulación de esta tubería para el producto "PlayStation 5", con la siguiente descripción:

Juegos impresionantes: Maravíllate con unos gráficos impresionantes y disfruta de las características de la nueva PS5.

Inmersión impresionante: Descubre una experiencia de juego más profunda con soporte para retroalimentación háptica, disparadores adaptativos y tecnología de audio 3D.

Diseño Slim: Con la Edición Digital PS5, los jugadores cuentan con una tecnología de juego poderoso en un diseño elegante y compacto.

1TB de almacenamiento: Ten tus juegos favoritos listos y esperando para jugar con 1TB de almacenamiento SSD integrado.

Retrocompatibilidad y mejora del juego: La consola PS5 puede reproducir más de 4.000 juegos de PS4. Con Game Boost, incluso puedes disfrutar de tasas de fotogramas más rápidas y fluidas en algunos de los mejores juegos de consola de PS4.

Observemos la salida de prompt generada por esta simulación.

Ahora se agregará un nuevo campo, dynamic_facets, al nuevo índice para almacenar las facetas generadas por la IA.

Usando la API Reindex, reindexaremos el índice de juegos de video a videogames_1, aplicando la generate_filter_ai pipeline durante el proceso. Esta tubería generará automáticamente facetas dinámicas durante la indexación.

Ahora, haremos una búsqueda y obtendremos los nuevos filtros:

Resultados:

Para simbolizar la implementación de las facetas, a continuación se muestra una interfaz sencilla:

El código de la interfaz que se presenta está aquí.

Conclusión

Ambos enfoques para crear filtros y facetas tienen sus beneficios y puntos de preocupación. El enfoque tradicional, basado en reglas manuales, ofrece control y costos más bajos, pero requiere actualizaciones constantes y no se adapta dinámicamente a nuevos productos o funcionalidades.

Por otro lado, el enfoque basado en IA y Aprendizaje Automático automatiza la extracción de facetas, haciendo la búsqueda más flexible y permitiendo el descubrimiento de nuevos atributos sin intervención manual. Sin embargo, este enfoque puede ser más complejo de implementar y mantener, requiriendo calibración para garantizar resultados consistentes.

La elección entre los enfoques tradicionales y basados en IA depende de las necesidades y la complejidad del negocio. Para escenarios más simples, donde los atributos de los datos son estables y previsibles, el enfoque tradicional puede ser más eficiente y fácil de mantener, evitando costos innecesarios con infraestructuras y modelos de IA. Por otro lado, el uso de ML/IA para extraer facetas puede aportar un valor significativo, mejorando la experiencia de búsqueda y haciendo que el filtrado sea más inteligente.

Lo importante es evaluar si la automatización justifica la inversión o si una solución más tradicional ya satisface eficazmente las necesidades del negocio.

Este blog explora cómo los grandes modelos de lenguaje (LLMs) pueden usar para identificar y generar sinónimos automáticamente, permitiendo que estos términos se carguen programáticamente en la API de sinónimos de Elasticsearch.

¿Cuándo usar sinónimos?

El uso de sinónimos puede ser una solución más rápida y rentable en comparación con la búsqueda vectorial. Su implementación es más sencilla ya que no requiere un conocimiento profundo de embeddings ni un proceso complejo de ingestión vectorial.

Además, el consumo de recursos es menor, ya que la búsqueda vectorial exige mayor capacidad de almacenamiento y memoria para incrustar, indexar y recuperar.

Otro aspecto importante es la regionalización de la búsqueda. Con los sinónimos, es posible adaptar términos según el idioma y las costumbres locales. Esto es útil en situaciones donde las incrustaciones pueden no coincidir con expresiones regionales o términos específicos de cada país. Por ejemplo, algunas palabras o siglas pueden tener significados diferentes según la región, pero los usuarios locales los tratan naturalmente como sinónimos. En Brasil, esto es bastante común. "Abacaxi" y "ananás" son la misma fruta (piña), pero el segundo término se usa más comúnmente en algunas regiones del noreste. De manera similar, el conocido "pão francês" en el sudeste puede ser conocido como "pão careca" en el noreste.

¿Cómo usar los LLMs para generar sinónimos?

Para obtener sinónimos automáticamente, podemos usar LLMs, que analizan el contexto de un término y sugieren variaciones apropiadas. Este enfoque permite expandir dinámicamente los sinónimos, cerciorando una búsqueda más amplia y precisa sin depender de un diccionario fijo.

En esta demostración, emplearemos un LLM para generar sinónimos de productos de comercio electrónico. Muchas búsquedas demuestran pocos o ningún resultado debido a las variaciones en los términos consultados. Con sinónimos, podemos resolver este problema. Por ejemplo, una búsqueda de "smartphone" puede abarcar diferentes modelos de teléfonos móviles, cerciorando que los usuarios encuentren los productos que buscan.

Prerrequisitos

Antes de empezar, necesitamos configurar el entorno y definir las dependencias necesarias. Emplearemos la solución proporcionada por Elastic para ejecutar Elasticsearch y Kibana localmente en Docker. El código estará escrito en Python, v3.9.6, con las siguientes dependencias:

Creación del índice de productos

Inicialmente, crearemos un índice de productos sin soporte de sinónimos. Esto nos permitirá validar consultas y luego compararlas con un índice que incluya sinónimos.

Para crear el índice, cargamos en masa un conjunto de datos de producto usando el siguiente comando en Kibana DevTools:

Generación de sinónimos con LLM

En este paso, emplearemos un LLM para generar sinónimos dinámicamente. Para lograrlo, integraremos la API de OpenAI, definiendo un modelo y un prompt apropiados. El LLM recibirá la categoría y el nombre del producto, cerciorando que los sinónimos sean relevantes en el contexto.

A partir del índice de productos creados, recuperaremos todos los artículos de la categoría "Electrónica" y enviaremos sus nombres al LLM. La salida esperada será algo así:

Con los sinónimos generados, podemos registrarlos en Elasticsearch usando la API de Sinónimos.

Gestión de sinónimos con la API de Sinónimos

La API de Sinónimos proporciona una forma eficiente de gestionar conjuntos de sinónimos directamente dentro del sistema. Cada conjunto de sinónimos consiste en reglas de sinónimos, donde un grupo de palabras se considera equivalente en las búsquedas.

Ejemplo de creación de un conjunto de sinónimos

Esto crea un conjunto llamado "mis-sinónimos-conjunto", donde "hola" y "hola" se tratan como equivalentes, así como "adiós" y "adiós".

Implementación de la creación de sinónimos para el catálogo de productos

A continuación se muestra el método responsable de construir un conjunto de sinónimos e insertarlo en Elasticsearch. Las reglas de sinónimos se generan a partir del mapeo de sinónimos sugerido por el LLM. Cada regla tiene un ID, correspondiente al nombre del producto en formato slug, y a la lista de sinónimos calculada por el LLM.

A continuación se muestra la carga útil de la solicitud para crear el conjunto de sinónimos:

Con el conjunto de sinónimos creado en el clúster, podemos pasar al siguiente paso, que es crear un nuevo índice con soporte de sinónimos usando el conjunto definido.

El código completo en Python con los sinónimos generados por LLM y la creación de conjuntos de sinónimos definida por la API de Sinónimos es el siguiente:

Creación de un índice con soporte de sinónimos

Se creará un nuevo índice donde todos los datos del índice de products serán reindexados. Este índice usará la synonyms_filter, que aplica la products-synonyms-set creada anteriormente.

A continuación se muestra el mapeo de índices configurado para usar sinónimos:

Reindexando el índice de products

Ahora, usaremos la API Reindex para migrar los datos del índice de products al nuevo índice de products_02 , que incluye soporte para sinónimos. El siguiente código se ejecutó en Kibana DevTools:

Tras la migración, el índice de products_02 estará llenado y listo para validar búsquedas usando el conjunto de sinónimos configurado.

Validación de la búsqueda con sinónimos

Comparemos los resultados de búsqueda entre los dos índices. Ejecutaremos la misma consulta en ambos índices y validaremos si los sinónimos se están empleando para obtener resultados.

Buscar en el índice de products (sin sinónimos)

Emplearemos a Kibana para realizar búsquedas y analizar los resultados. En el menú de Analítica > Descubrimiento, crearemos una Vista de Datos para visualizar los datos de los índices que creamos.

Dentro de Discovery, haz clic en Vista de datos y define un nombre y un patrón de índice. Para el índice de "productos", usaremos el patrón de "productos". Luego, repetiremos el proceso para crear una nueva Vista de Datos para el índice "products_02", usando el patrón "products_02".

Con las Vistas de Datos configuradas, podemos volver a Analytics > Discovery y comenzar las validaciones.

Aquí, tras seleccionar productos DataView y buscar el término "tablet", no obtenemos resultados, aunque sabemos que existen productos como "Kindle Paperwhite" y "Apple iPad Air".

Buscar en el índice de products_02 (sinónimos de soporte)

Al realizar la misma consulta en la Vista de Datos "products_synonyms", que soporta sinónimos, los productos se recuperaron con éxito. Esto demuestra que el conjunto de sinónimos configurado funciona correctamente, cerciorando que diferentes variaciones de los términos buscados devuelvan los resultados esperados.

Podemos lograr el mismo resultado ejecutando la misma consulta directamente en Kibana DevTools. Simplemente busca en el índice de products_02 usando la API de búsqueda de Elasticsearch:

Conclusión

La implementación de sinónimos en Elasticsearch mejoró la precisión y cobertura de las búsquedas en catálogos de productos. El diferenciador clave era el uso de un LLM, que generaba sinónimos automáticamente y contextualmente, eliminando la necesidad de listas predefinidas. El modelo analizó nombres y categorías de productos, cerciorando sinónimos relevantes para el comercio electrónico.

Además, la API de Sinónimos simplificó la gestión de diccionarios, permitiendo modificar dinámicamente los conjuntos de sinónimos. Con este enfoque, la búsqueda se volvió más flexible y adaptable a diferentes patrones de consulta de usuario.

Este proceso puede mejorar continuamente con nuevos datos y ajustes de modelos, cerciorando una experiencia de investigación cada vez más eficiente.

Referencias

Ejecuta Elasticsearch localmente

https://www.elastic.co/guide/en/elasticsearch/reference/current/run-elasticsearch-locally.html

Sinónimos API

https://www.elastic.co/guide/en/elasticsearch/reference/current/synonyms-apis.html

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.