Jhon Guzmán - Elasticsearch Labs

Evaluación de la relevancia de las consultas de búsqueda con listas de evaluaciones

Jhon Guzmán — Thu, 11 Dec 2025 00:00:00 GMT

Los desarrolladores que trabajan en motores de búsqueda a menudo se encuentran con el mismo problema: el equipo empresarial no está satisfecho con una búsqueda concreta porque los documentos que esperan que estén en la parte superior de los resultados de búsqueda aparecen en tercer o cuarto lugar en la lista de resultados.

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:

PUT movies { "mappings": { "properties": { "text": { "type": "text" } } } }

Solicitud en masa:

POST /movies/_bulk { "index": { "_id": "doc1" } } { "text": "DiCaprio performance in The Revenant was breathtaking." } { "index": { "_id": "doc2" } } { "text": "Inception shows Leonardo DiCaprio in one of his most iconic roles." } { "index": { "_id": "doc3" } } { "text": "Brad Pitt delivers a solid performance in this crime thriller." } { "index": { "_id": "doc4" } } { "text": "An action-packed adventure with stunning visual effects." } { "index": { "_id": "doc5" } } { "text": "A heartbreaking story of love and loss that made me cry for hours." } { "index": { "_id": "doc6" } } { "text": "One of the saddest movies ever made -- bring tissues!" } { "index": { "_id": "doc7" } } { "text": "A lighthearted comedy that will make you laugh." } { "index": { "_id": "doc8" } } { "text": "A science-fiction epic full of action and excitement." }

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

GET movies/_search { "query": { "match": { "text": { "query": "DiCaprio performance", "minimum_should_match": "100%" } } } }

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:

POST /movies/_rank_eval { "requests": [ { "id": "dicaprio-performance", "request": { "query": { "match": { "text": { "query": "DiCaprio performance", "minimum_should_match": "100%" } } } }, "ratings": [ { "_index": "movies", "_id": "doc1", "rating": 1 }, { "_index": "movies", "_id": "doc2", "rating": 1 }, { "_index": "movies", "_id": "doc3", "rating": 0 }, { "_index": "movies", "_id": "doc4", "rating": 0 } ] }, { "id": "sad-movies", "request": { "query": { "match": { "text": { "query": "sad movies that make you cry", "minimum_should_match": "100%" } } } }, "ratings": [ { "_index": "movies", "_id": "doc5", "rating": 1 }, { "_index": "movies", "_id": "doc6", "rating": 1 }, { "_index": "movies", "_id": "doc7", "rating": 0 }, { "_index": "movies", "_id": "doc8", "rating": 0 } ] } ], "metric": { "recall": { "k": 10, "relevant_rating_threshold": 1 } } }

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.

{ "metric_score": 0.5, "details": { "dicaprio-performance": { "metric_score": 1, "unrated_docs": [], "hits": [ { "hit": { "_index": "movies", "_id": "doc1", "_score": 2.4826927 }, "rating": 1 }, { "hit": { "_index": "movies", "_id": "doc2", "_score": 2.0780432 }, "rating": 1 } ], "metric_details": { "recall": { "relevant_docs_retrieved": 2, "relevant_docs": 2 } } }, "sad-movies": { "metric_score": 0, "unrated_docs": [], "hits": [], "metric_details": { "recall": { "relevant_docs_retrieved": 0, "relevant_docs": 2 } } } }, "failures": {} }

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.

POST /movies/_rank_eval { "requests": [ { "id": "dicaprio-performance", "request": { "query": { "match": { "text": { "query": "DiCaprio performance" } } } }, "ratings": [ { "_index": "movies", "_id": "doc1", "rating": 1 }, { "_index": "movies", "_id": "doc2", "rating": 1 }, { "_index": "movies", "_id": "doc3", "rating": 0 }, { "_index": "movies", "_id": "doc4", "rating": 0 } ] }, { "id": "sad-movies", "request": { "query": { "match": { "text": { "query": "sad movies that make you cry" } } } }, "ratings": [ { "_index": "movies", "_id": "doc5", "rating": 1 }, { "_index": "movies", "_id": "doc6", "rating": 1 }, { "_index": "movies", "_id": "doc7", "rating": 0 }, { "_index": "movies", "_id": "doc8", "rating": 0 } ] } ], "metric": { "recall": { "k": 10, "relevant_rating_threshold": 1 } } }

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.

{ "metric_score": 1, "details": { "dicaprio-performance": { "metric_score": 1, "unrated_docs": [], "hits": [ { "hit": { "_index": "movies", "_id": "doc1", "_score": 2.0661702 }, "rating": 1 }, { "hit": { "_index": "movies", "_id": "doc3", "_score": 0.732218 }, "rating": 0 }, { "hit": { "_index": "movies", "_id": "doc2", "_score": 0.6271719 }, "rating": 1 } ], "metric_details": { "recall": { "relevant_docs_retrieved": 2, "relevant_docs": 2 } } }, "sad-movies": { "metric_score": 1, "unrated_docs": [], "hits": [ { "hit": { "_index": "movies", "_id": "doc7", "_score": 2.1307156 }, "rating": 0 }, { "hit": { "_index": "movies", "_id": "doc5", "_score": 1.3160692 }, "rating": 1 }, { "hit": { "_index": "movies", "_id": "doc6", "_score": 1.190063 }, "rating": 1 } ], "metric_details": { "recall": { "relevant_docs_retrieved": 2, "relevant_docs": 2 } } } }, "failures": {} }

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:

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.
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.
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.
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.
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.

Introducción de la interfaz de reglas de consulta Elasticsearch en Kibana

Jhon Guzmán — Fri, 07 Nov 2025 00:00:00 GMT

La función de un motor de búsqueda es devolver resultados relevantes. Sin embargo, hay necesidades empresariales que van más allá de eso, como destacar las ventas, priorizar productos de temporada o mostrar artículos patrocinados, y los desarrolladores no siempre pueden hacer esto en la consulta de búsqueda.

Además, estos casos de uso suelen ser sensibles al tiempo, y pasar por las etapas típicas de desarrollo (crear una rama de código y luego esperar una nueva versión) es un proceso que consume mucho tiempo.

Entonces, ¿y si pudiéramos hacer todo este proceso solo con una llamada a la API, o mejor aún, con solo unos clics en Kibana?

Interfaz de Reglas de Consulta

Elasticsearch 8.10 introdujo Reglas de Consulta y Retriever de Reglas. Estas son herramientas diseñadas para inyectar resultados fijados en las consultas sin afectar la clasificación de los resultados orgánicos según reglas. Solo agregan lógica de negocio encima de los resultados de forma declarativa y sencilla.

Algunos casos de uso comunes para las Reglas de Consulta son:

Destacar anuncios u ofertas promocionadas: Mostrar artículos en oferta o patrocinados en la parte superior.
Excluyendo por contexto o geolocalización: ocultar ciertos objetos cuando la normativa local no permite mostrarlos.
Priorizar los resultados clave: Cerciorar de que las búsquedas populares o fijas estén siempre en la cima, independientemente del ranking orgánico.

Para acceder a la interfaz e interactuar con estas herramientas, necesitas hacer clic en el menú lateral de Kibana e ir a Reglas de consulta, en Relevancia:

Cuando aparezca el menú de reglas de consulta, haz clic en Crear tu primer conjunto de reglas:

A continuación, tienes que nombrar tu conjunto de normas.

La forma para definir cada regla tiene tres componentes clave:

Criterios: Las condiciones que deben cumplir para que la norma se aplique. Por ejemplo, "cuando el campo query_string contiene el valor Christmas" o "cuando el campo del país es CO."
Acción: Esto es lo que quieres que ocurra cuando se cumplan las condiciones. Puede fijar (fijar un documento a los resultados superiores) o excluir (ocultar un documento).
Metadatos: Estos son los campos que acompañan la consulta cuando se ejecuta. Pueden incluir la información del usuario (como ubicación o idioma), así como datos de búsqueda (query_string). Estos son los valores que emplean los criterios para decidir si aplicar o no una regla.

Ejemplo: objetos populares

Imaginemos que tenemos un sitio de comercio electrónico con diferentes artículos. Al analizar las métricas, observamos que uno de los artículos más vendidos en la categoría de consolas es el "DualShock 4 Wireless Controller", especialmente cuando los usuarios buscan las palabras clave "PS4" o "PlayStation 4". Así que decidimos poner este producto encima de los resultados cada vez que un usuario busque esas palabras clave.

Primero, indexemos los documentos de cada elemento usando una solicitud Bulk API:

POST _bulk { "index": { "_index": "products", "_id": "1" } } { "id": "1", "name": "PlayStation 4 Slim 1TB", "category": "console", "brand": "Sony", "price": 1200 } { "index": { "_index": "products", "_id": "2" } } { "id": "2", "name": "DualShock 4 Wireless Controller", "category": "accessory", "brand": "Sony", "price": 250 } { "index": { "_index": "products", "_id": "3" } } { "id": "3", "name": "PlayStation 4 Camera", "category": "accessory", "brand": "Sony", "price": 200 } { "index": { "_index": "products", "_id": "4" } } { "id": "4", "name": "PlayStation 4 VR Headset", "category": "accessory", "brand": "Sony", "price": 900 } { "index": { "_index": "products", "_id": "5" } } { "id": "5", "name": "Charging Station for DualShock 4", "category": "accessory", "brand": "Sony", "price": 80 }

Si no intervenimos en la consulta, el elemento suele aparecer en cuarto lugar. Aquí está la pregunta:

GET products/_search { "query": { "match": { "name": "PlayStation 4" } } }

Y aquí están los resultados

{ "took": 1, "timed_out": false, "_shards": { "total": 1, "successful": 1, "skipped": 0, "failed": 0 }, "hits": { "total": { "value": 5, "relation": "eq" }, "max_score": 0.6973252, "hits": [ { "_index": "products", "_id": "3", "_score": 0.6973252, "_source": { "id": "3", "name": "PlayStation 4 Camera", "category": "accessory", "brand": "Sony", "price": 200 } }, { "_index": "products", "_id": "1", "_score": 0.6260078, "_source": { "id": "1", "name": "PlayStation 4 Slim 1TB", "category": "console", "brand": "Sony", "price": 1200 } }, { "_index": "products", "_id": "4", "_score": 0.6260078, "_source": { "id": "4", "name": "PlayStation 4 VR Headset", "category": "accessory", "brand": "Sony", "price": 900 } }, { "_index": "products", "_id": "2", "_score": 0.08701137, "_source": { "id": "2", "name": "DualShock 4 Wireless Controller", "category": "accessory", "brand": "Sony", "price": 250 } }, { "_index": "products", "_id": "5", "_score": 0.07893815, "_source": { "id": "5", "name": "Charging Station for DualShock 4", "category": "accessory", "brand": "Sony", "price": 80 } } ] } }

Vamos a crear una regla de consulta para cambiar esto. Primero, vamos a agregarlo al reglamento de esta manera:

O solicitud API equivalente:

PUT _query_rules/my-rules { "rules": [ { "rule_id": "rule-1232", "type": "pinned", "criteria": [ { "type": "exact", "metadata": "query_string", "values": [ "PS4", "PlayStation 4" ] } ], "actions": { "docs": [ { "_index": "products", "_id": "2" } ] } } ] }

Para usar el conjunto de reglas en nuestra consulta, debemos usar un tipo de regla de consulta. Este tipo de consulta se compone de dos partes principales:

GET /products/_search { "retriever": { "rule": { "retriever": { "standard": { "query": { "match": { "name": "PlayStation 4" } } } }, "match_criteria": { "query_string": "PlayStation 4" }, "ruleset_ids": ["my-rules"] } } }

match_criteria: Estos son los metadatos que se emplean para comparar con la consulta del usuario. En este ejemplo, el conjunto de reglas se activa cuando el campo query_string tiene el valor "PlayStation 4."
Consulta: La consulta real que se usará para buscar y obtener los resultados orgánicos.

De este modo, primero ejecutas la consulta orgánica y luego Elasticsearch aplica las reglas de tu conjunto de reglas:

{ "took": 17, "timed_out": false, "_shards": { "total": 1, "successful": 1, "skipped": 0, "failed": 0 }, "hits": { "total": { "value": 5, "relation": "eq" }, "max_score": 1.7014122e+38, "hits": [ { "_index": "products", "_id": "2", "_score": 1.7014122e+38, "_source": { "id": "2", "name": "DualShock 4 Wireless Controller", "category": "accessory", "brand": "Sony", "price": 250 } }, { "_index": "products", "_id": "3", "_score": 0.6973252, "_source": { "id": "3", "name": "PlayStation 4 Camera", "category": "accessory", "brand": "Sony", "price": 200 } }, { "_index": "products", "_id": "1", "_score": 0.6260078, "_source": { "id": "1", "name": "PlayStation 4 Slim 1TB", "category": "console", "brand": "Sony", "price": 1200 } }, { "_index": "products", "_id": "4", "_score": 0.6260078, "_source": { "id": "4", "name": "PlayStation 4 VR Headset", "category": "accessory", "brand": "Sony", "price": 900 } }, { "_index": "products", "_id": "5", "_score": 0.07893815, "_source": { "id": "5", "name": "Charging Station for DualShock 4", "category": "accessory", "brand": "Sony", "price": 80 } } ] } }

Ejemplo: metadatos basados en el usuario

Otra aplicación interesante de las Reglas de Consulta es usar metadatos para mostrar documentos específicos basar en información contextual del usuario o del sitio web.

Por ejemplo, imaginemos que queremos destacar artículos o ventas personalizadas basándonos en el nivel de fidelidad del usuario, representado como un valor numérico.

Podemos hacerlo ingiriendo estos metadatos directamente en la consulta para que las reglas se activen cuando dicho valor cumple ciertos criterios.

Primero, indexaremos un documento que solo los usuarios con un alto nivel de lealtad puedan ver:

POST _bulk { "index": { "_index": "products", "_id": "6" } } { "id": "6", "name": "PlayStation Plus Deluxe Card - 12 months", "category": "membership", "brand": "Sony", "price": 300 }

Ahora, creemos una nueva regla dentro del mismo conjunto de reglas para que cuando el loyalty_level sea igual o superior a 80, el elemento aparezca encima de los resultados.

Almacena la regla y el reglamento.

Aquí está la solicitud REST equivalente:

PUT _query_rules/my-rules { "rules": [ { "rule_id": "pin-premiun-user", "type": "pinned", "criteria": [ { "type": "gte", "metadata": "loyalty_level", "values": [ 80 ] } ], "actions": { "docs": [ { "_index": "products", "_id": "6" } ] } } ] }

Ahora, al ejecutar una consulta, necesitamos incluir el nuevo parámetro loyalty_level en los metadatos. Si se cumple la condición de la regla, el nuevo documento aparecerá encima de los resultados.

Por ejemplo, al enviar una consulta donde el loyalty_level es 80:

POST /products/_search { "retriever": { "rule": { "retriever": { "standard": { "query": { "match": { "name": "PlayStation" } } } }, "match_criteria": { "query_string": "PlayStation", "loyalty_level": 80 }, "ruleset_ids": ["my-rules"] } } }

Veremos el documento de lealtad encima de los resultados:

{ "took": 31, "timed_out": false, "_shards": { "total": 1, "successful": 1, "skipped": 0, "failed": 0 }, "hits": { "total": { "value": 4, "relation": "eq" }, "max_score": 1.7014122e+38, "hits": [ { "_index": "products", "_id": "6", "_score": 1.7014122e+38, "_source": { "id": "6", "name": "PlayStation Plus Deluxe Card - 12 months", "category": "membership", "brand": "Sony", "price": 300 } }, { "_index": "products", "_id": "3", "_score": 0.5054567, "_source": { "id": "3", "name": "PlayStation 4 Camera", "category": "accessory", "brand": "Sony", "price": 200 } }, { "_index": "products", "_id": "1", "_score": 0.45618832, "_source": { "id": "1", "name": "PlayStation 4 Slim 1TB", "category": "console", "brand": "Sony", "price": 1200 } }, { "_index": "products", "_id": "4", "_score": 0.45618832, "_source": { "id": "4", "name": "PlayStation 4 VR Headset", "category": "accessory", "brand": "Sony", "price": 900 } } ] } }

En el caso siguiente, dado que el nivel de lealtad es 70, la regla no se cumple y el objeto no debería aparecer arriba:

Aquí están los resultados:

{ "took": 7, "timed_out": false, "_shards": { "total": 1, "successful": 1, "skipped": 0, "failed": 0 }, "hits": { "total": { "value": 4, "relation": "eq" }, "max_score": 0.5054567, "hits": [ { "_index": "products", "_id": "3", "_score": 0.5054567, "_source": { "id": "3", "name": "PlayStation 4 Camera", "category": "accessory", "brand": "Sony", "price": 200 } }, { "_index": "products", "_id": "1", "_score": 0.45618832, "_source": { "id": "1", "name": "PlayStation 4 Slim 1TB", "category": "console", "brand": "Sony", "price": 1200 } }, { "_index": "products", "_id": "4", "_score": 0.45618832, "_source": { "id": "4", "name": "PlayStation 4 VR Headset", "category": "accessory", "brand": "Sony", "price": 900 } }, { "_index": "products", "_id": "6", "_score": 0.3817649, "_source": { "id": "6", "name": "PlayStation Plus Deluxe Card - 12 months", "category": "membership", "brand": "Sony", "price": 300 } } ] } }

Ejemplo: exclusión inmediata

Supongamos que nuestro mando inalámbrico DualShock 4 (ID 2) está temporalmente indisponible y no puede vender. Así que, en lugar de eliminar manualmente el documento o esperar a que algún proceso de datos se active, el equipo de negocio decide eliminarlo de los resultados de búsqueda mientras tanto.

Usaremos un proceso similar al que acabamos de aplicar a los objetos populares, pero esta vez en lugar de seleccionar Fijado, elegiremos Excluir. Esta regla funciona como una especie de lista negra. Cambia los criterios a Siempre para que la exclusión funcione cada vez que se ejecute la consulta.

La regla debería ser así:

Almacena la regla y el conjunto de reglas para aplicar los cambios. Aquí está la solicitud REST equivalente:

PUT _query_rules/my-rules { "rules": [ { "rule_id": "rule-6358", "type": "pinned", "criteria": [ { "type": "always" } ], "actions": { "docs": [ { "_index": "products", "_id": "2" } ] } } ] }

Ahora, cuando ejecutamos la consulta de nuevo, verás que el elemento ya no aparece en los resultados, aunque la regla anterior sea fijarlo. Esto se debe a que las exclusiones tienen prioridad sobre los resultados de fijación.

{ "took": 6, "timed_out": false, "_shards": { "total": 1, "successful": 1, "skipped": 0, "failed": 0 }, "hits": { "total": { "value": 4, "relation": "eq" }, "max_score": 2.205655, "hits": [ { "_index": "products", "_id": "3", "_score": 2.205655, "_source": { "id": "3", "name": "PlayStation 4 Camera", "category": "accessory", "brand": "Sony", "price": 200 } }, { "_index": "products", "_id": "1", "_score": 1.9738505, "_source": { "id": "1", "name": "PlayStation 4 Slim 1TB", "category": "console", "brand": "Sony", "price": 1200 } }, { "_index": "products", "_id": "4", "_score": 1.9738505, "_source": { "id": "4", "name": "PlayStation 4 VR Headset", "category": "accessory", "brand": "Sony", "price": 900 } }, { "_index": "products", "_id": "5", "_score": 0.69247496, "_source": { "id": "5", "name": "Charging Station for DualShock 4", "category": "accessory", "brand": "Sony", "price": 80 } } ] } }

Conclusión

Las Reglas de Consulta facilitan mucho ajustar la relevancia sin ningún cambio en el código. La nueva interfaz Kibana tepermite realizar estos cambios en cuestión de segundos, dándote a ti y a tu equipo empresarial más control sobre los resultados de búsqueda.

Más allá del comercio electrónico, las Reglas de Consulta pueden impulsar muchos otros escenarios: destacar guías de resolución de problemas en portales de soporte, mostrar documentos internos clave en bases de conocimiento, promover noticias de última hora en sitios de noticias o filtrar ofertas de empleo o contenido caducado. Incluso pueden hacer cumplir normas de cumplimiento, como ocultar material restringido por rol de usuario o región.