Creación de un plano de control para gestionar las búsquedas en el comercio electrónico

La parte 1 y la parte 2 de esta serie establecieron por qué la búsqueda de comercio electrónico necesita una capa de gobernanza, una capa de decisión entre la consulta del usuario y el motor de recuperación que clasifica la intención, impone restricciones y enruta a la estrategia de recuperación correcta (p. ej., BM25, semántica, híbrida). Esta publicación muestra cómo construir esa capa utilizando una primitiva arquitectónica simple, en la cual las políticas de interpretación de consultas se almacenan como documentos y se recuperan en tiempo de consulta mediante coincidencia inversa rápida. Debido a que las nuevas políticas de recuperación (p. ej., “reforzar la marca X” o “mostrar solo la categoría Y”) no requieren cambios en el código, el resultado es una capa de enrutamiento que se mantiene estable mientras las políticas evolucionan y que mantiene los motores de recuperación seguros en entornos de alto riesgo. Si quieres ver el resultado final de esta arquitectura antes de seguir leyendo, mira este video: Mejorar la relevancia de búsqueda en segundos: presentamos PRISM.

Por qué interpretar consultas suele ser complicado

Almacenar políticas como código (bloques if/else en la capa de aplicación) produce decenas de miles de líneas de lógica frágil que carece de cualquier indexación para una recuperación eficiente de políticas en tiempo de consulta. La iteración es lenta (un simple cambio en el comportamiento de una consulta puede requerir un ciclo de despliegue de seis semanas), la responsabilidad no está clara (¿por qué cambiaron los resultados?) y los usuarios de negocio no pueden modificar el comportamiento de búsqueda sin la intervención del equipo de ingeniería. Esto se muestra en el lado izquierdo de la siguiente imagen:

En la parte derecha de la imagen de arriba se muestra cómo almacenar políticas como datos en un índice de Elasticsearch. Este enfoque resuelve todos los problemas asociados con la lógica de resolución de consultas codificada de forma rígida. Sin embargo, para que esto funcione, necesitas una manera de determinar rápidamente qué políticas coinciden con la consulta del usuario y cómo se deben resolver los conflictos. Aquí es donde entra en juego el plano de control gobernado.

El patrón del plano de control

Entre la consulta original del usuario y la recuperación de Elasticsearch se interpone un plano de control gestionado. Recibe texto del usuario como entrada, y su salida es un plan de ejecución que incluye filtros, refuerzos y decisiones de enrutamiento de recuperación.

Un pipeline del plano de control consiste en:

1. Consulta del usuario: un usuario ingresa un texto de lo que está buscando, como “naranjas” o “regalo para el abuelo”.
2. Búsqueda de políticas: hacer coincidir la consulta del usuario con el índice de políticas.
3. Arrojar políticas coincidentes: las políticas que coinciden con la consulta del usuario se recuperan del índice de políticas.
4. Aplicación de políticas: la capa de control analiza las políticas arrojadas y combina las políticas coincidentes en un único plan de ejecución coherente que incluye filtros, refuerzos, anulaciones y barreras de seguridad, y aplica el método de recuperación adecuado (por ejemplo, recuperación léxica, recuperación semántica o híbrida).
5. Ejecutar: la consulta consciente de la intención modificada de Elasticsearch se pasa a la aplicación para ejecutarse contra un índice de catálogo de productos.
6. Explicar (opcional): además de crear una consulta que proporciona resultados alineados con el negocio y la intención, el plano de control ofrece una carga útil opcional de explicabilidad para mostrar qué políticas se activaron y cómo se combinaron.

Encontrar qué políticas deben aplicarse para el texto de búsqueda de un usuario requiere una primitiva de coincidencia inversa rápida, que resolvemos con la búsqueda percolator. Después de recuperar las políticas relevantes, es necesario un marco de trabajo de juicio para combinar múltiples políticas emparejadas en un plan de ejecución unificado: prioridades, estrategias de conflicto, seguimiento de frases consumidas y transformaciones en cascada que aplican las políticas en secuencia en vez de forma independiente. Además, se debe seleccionar la tecnología de recuperación más adecuada (por ejemplo, BM25 para “naranjas” frente a la búsqueda semántica de “regalo para el abuelo”).

Consulta de políticas: verificación de la consulta antes de buscar productos

Cuando un comprador escribe una consulta, un sistema de búsqueda con un plano de control regulado no envía esa consulta directamente para que se ejecute en el catálogo de productos. Primero, la consulta se compara con un conjunto de políticas almacenadas y se modifica para reflejar la intención de la consulta y las prioridades del negocio.

Estructura de la política

Cada póliza es un documento simple que define dos cosas:

• Criterio de coincidencia: Qué texto de búsqueda debería activar esta política. Esto puede ser una frase exacta, una sola palabra, un patrón o una combinación.
• Acción: qué hacer cuando se activa la política. Esto podría consistir en aplicar un filtro de categoría, excluir productos, establecer un límite de precio o cambiar la estrategia de búsqueda.

El sistema busca todas las políticas que coinciden, las integra en un plan de ejecución y solo entonces ejecuta la búsqueda de productos. Tomadas en conjunto, las políticas actúan como un asociado conocedor de la tienda que entiende lo que estás buscando y te guía hacia el pasillo correcto.

El patrón de política

Los primeros artículos de esta serie introdujeron ejemplos de políticas en acción: restringir "naranjas" a la categoría de productos, tratar "sin maní" como una exclusión y dirigir "regalo para el abuelo" a la recuperación semántica. El punto arquitectónico clave es que, en cada caso, la consulta se verifica con las políticas almacenadas antes de que comience la búsqueda del producto. Las políticas determinan qué restricciones aplicar, qué texto modificar y qué estrategia de recuperación utilizar. La consulta al catálogo de productos se realiza después de que se hayan aplicado las políticas y se haya creado una nueva consulta reescrita.

Por qué es rápido

Un sistema de comercio electrónico empresarial puede tener millones de productos, pero solo cientos o miles de políticas. El paso de búsqueda de políticas implica buscar en un índice pequeño y curado, no en el catálogo completo de productos, y por lo tanto es rápido. Y como las políticas se almacenan como datos en su propio índice, un comerciante que agregue una nueva política no tiene que tocar el código de la aplicación, y un ingeniero que optimice la búsqueda de productos no tiene que tocar el índice de políticas. Las dos preocupaciones evolucionan por su cuenta.

Los ejemplos anteriores describen qué sucede a nivel conceptual. Detrás de escena, la búsqueda de políticas se implementa usando el tipo de consulta percolator de Elasticsearch, que está diseñado específicamente para este tipo de patrón: hacer coincidir el texto entrante con un conjunto de consultas almacenadas. La Parte 4 de esta serie proporciona una inmersión práctica y profunda en la implementación de percolator, incluyendo mapeos de índices, marcadores de límite y seguimiento de frases impulsado por resaltado. Ya que la Parte 4 cubre la totalidad del mecanismo de búsqueda, pasemos a lo que realmente contiene un documento de política y cómo el plano de control compone múltiples políticas en un solo plan de ejecución.

Ejemplos de políticas

Ahora que ya sabemos qué hacen las políticas en teoría, veamos qué contienen en realidad. Las dos políticas que aparecen a continuación se han diseñado para que entren en conflicto de forma intencionada, lo que servirá para demostrar el sistema de resolución de conflictos que se describe en las secciones siguientes.

Chocolate barato

La política que se muestra a continuación detecta si un usuario ha enviado una búsqueda que contiene la frase “chocolate barato”. Si es así, los resultados se restringen a las categorías de “chocolates” y “chocolates con leche”. Esta política también aplica un filtro de precio de $2. Además, observa que esta política tiene una prioridad de 210; retomaremos esto cuando veamos la resolución de conflictos con más detalle.

La configuración del modo de filtro y la estrategia de conflicto que se muestran aquí (hard_filter, soft_boost, restrict, override) se explican en detalle en la sección de resolución de conflictos a continuación.

Cuando se activa la política anterior, una búsqueda de “chocolate barato” respeta el filtro de precio de $2 y restringe los resultados a las categorías de “chocolates” y “chocolates de leche”. A continuación se muestran los resultados de ejemplo:

Chocolate de Navidad

La política que se muestra a continuación es un ejemplo de una política que uno podría imaginar aplicando en Navidad. Este ejemplo restringe los resultados a “comidas y bebidas navideñas” y “dulces navideños”, refuerza cualquier producto que también esté en la categoría “calendarios de Adviento” y aplica un filtro de precio de menos de $7 para enfocarse en artículos de temporada asequibles. Además, ten en cuenta que esta política tiene una prioridad de 300. Lo retomaremos cuando veamos la resolución de conflictos con más detalle.

Cuando la política anterior se activa sin ninguna política conflictiva, una búsqueda de “chocolate” respeta el filtro de precio de $7, y restringe los resultados a las categorías de “comida y bebidas navideñas” y “dulces navideños”, y refuerza cualquier producto etiquetado como “calendarios de Adviento”. A continuación se muestran los resultados de ejemplo:

Combinación de políticas coincidentes

La consulta de políticas que acabamos de describir es solo la mitad de la cuestión. La otra mitad es lo que sucede cuando varias políticas coinciden con la misma búsqueda.

En cualquier despliegue no trivial, una sola consulta activará de forma rutinaria varias políticas a la vez. "Chocolate barato" coincidirá con ambas políticas que ya demostramos. Cada política es correcta de forma aislada. La parte difícil consiste en combinarlas en un único plan de ejecución coherente, sin contradicciones, sin contar dos veces lo mismo y sin que una política anule en silencio el trabajo de otra.

Esto no es un problema de búsqueda; es un problema de juicio. El sistema debe decidir:

• Orden de solicitud: si una política de negación elimina "sin maní" de la consulta, ¿la política de precios sigue viendo el texto original o el texto modificado?
• Filtrar conflictos: si dos políticas establecen diferentes límites de precio, ¿cuál gana? ¿El perdedor se elimina en silencio o se degrada poco a poco en un refuerzo leve?
• Propiedad de frase: si dos políticas coincidieron en la misma palabra y la primera ya la consumió, ¿debería activarse la segunda?

Una implementación ingenua (aplicar todas las políticas coincidentes de forma independiente, combinar los resultados) falla apenas interactúan las políticas. La arquitectura necesita un modelo explícito de cómo se componen las políticas. Las siguientes dos secciones describen ese modelo: un marco de trabajo de prioridad y resolución de conflictos; y un modelo de transformación en cascada que hace que la interacción de políticas sea determinista.

La idea clave es que la aplicación de políticas no es un conjunto de operaciones independientes, sino una transformación en cascada. Cada política recibe el estado de reescritura producido por todas las políticas de mayor prioridad y lo transforma aún más:

estado inicial → [Política A] → estado' → [Política B] → estado'' →... → plan de ejecución

El estado lleva el texto de la consulta reescrito, los filtros acumulados, la intención actual y cualquier expansión de sinónimos. Una política de alta prioridad puede eliminar texto de la consulta, y cada política subsiguiente ve la consulta modificada, no la original. El contexto se acumula. El orden importa.

Precedencia y resolución de conflictos: el determinismo importa

Las estrategias específicas de conflicto son una elección de diseño. Cada organización puede resolver los conflictos de manera diferente, según sus necesidades empresariales. El siguiente enfoque ilustra el tipo de marco de trabajo que necesita un plano de control. Lo importante no son estas estrategias concretas, sino que el sistema cuente con estrategias explícitas y deterministas, en lugar de dejar que los conflictos se resuelvan mediante interacciones impredecibles.

Orden de prioridad

Las políticas se ordenan por prioridad (la más alta primero). Cuando varias políticas coinciden con la misma consulta, se aplican en orden de prioridad. Si dos políticas intentan establecer el mismo campo de filtro, la estrategia declarada por la política de mayor prioridad para ese campo tiene prioridad. Si hay varias políticas activadas que tienen la misma prioridad, entonces se da preferencia a la política con el ID más alto (como si se le hubiera asignado una prioridad más alta); esta elección asegura un comportamiento determinista cuando surgen conflictos.

Resolución por campo, no por política

Un principio fundamental de diseño: la resolución de conflictos opera por campo (por ejemplo, marca, categoría o descripción), no por política. Cuando dos políticas producen filtros que se superponen en campos específicos, solo esos campos específicos se ven afectados por la estrategia de resolución de conflictos, y la estrategia de resolución la define la política de coincidencia de mayor prioridad. Los campos no conflictivos de ambas políticas permanecen intactos.

Esto importa porque la alternativa de un enfoque por política obligaría al sistema a aceptar o rechazar una política completa cuando solo uno de sus campos entra en conflicto.

La resolución por campo conserva la mayor cantidad posible de información útil sobre restricciones.

Tres configuraciones por campo del filtro

Cada campo de filtro de una política tiene tres configuraciones independientes:

Modo de filtro: cómo se aplica el filtro cuando no hay conflicto.

• hard_filter (predeterminado): se aplica como una cláusula Elasticsearch bool.filter. Esto es útil para excluir por completo productos no relacionados. Por ejemplo, restringir la búsqueda de "naranjas" a la categoría de productos elimina resultados como jugo de naranja y mermelada de naranja. Los documentos que no coinciden se excluyen por completo de los resultados.
• soft_boost: aplicado como un peso de Elasticsearch function_score con un boost_weight configurable. Los documentos que coinciden obtienen un refuerzo en la clasificación, pero los documentos que no coinciden no se excluyen. Esto es útil, por ejemplo, para reforzar una marca sin dejar de lado a las demás.

Estrategia de conflicto

Qué ocurre cuando una política de menor prioridad establece el mismo campo:

• override: El valor de esta política de alta prioridad gana; el valor de menor prioridad se descarta por completo. Válido para todos los tipos de campos.
• restrict: Tomemos el valor numérico más restrictivo (por ejemplo, el techo inferior para el precio__max, the higher floor for price__min). Válido solo para campos numéricos de rango.
• merge: Combina ambos valores en una unión. Válido solo para campos no numéricos.
• soft_boost: Convierte el filtro en conflicto a un peso function_score con un boost_weight configurable en lugar de un filtro estricto. Para más detalles sobre el aumento de function_score, consulta Cómo influir en el ranking de BM25 con aumento multiplicativo en Elasticsearch. Esto solo es válido para campos no negativos.

Valor: el valor real del filtro (por ejemplo, una lista de categorías, un umbral de precio).

Estrategias por tipo de campo: no todas las estrategias tienen sentido para todos los tipos de campo. Por ejemplo, una exclusión es inherentemente binaria, por lo que no se puede reforzar de forma leve. La siguiente tabla muestra qué estrategias están disponibles para cada tipo de campo:

Los campos de negación no se pueden reforzar de forma leve porque las exclusiones son binarias. Convertir "nunca mostrar alimentos enlatados" a "leve preferencia por alimentos no enlatados" cambia fundamentalmente la semántica; un producto de "alimentos enlatados" aún aparecería, solo clasificado ligeramente más abajo, lo que anula el propósito de la exclusión.

Un ejemplo concreto: buscar "chocolate barato" durante una campaña de Navidad

Suponga que un comerciante ha creado las dos políticas para el chocolate que demostramos previamente, una de menor prioridad para el chocolate barato y otra política relacionada con el chocolate de mayor prioridad que se habilitará durante Navidad. Si ambas de estas políticas están habilitadas, entonces cómo se combinan depende del modo de filtro y la estrategia de conflicto de la política de mayor precedencia. Si ambas de las políticas previamente discutidas están habilitadas, se combinarán de la siguiente manera:

Esto muestra dos conflictos, uno en categorías y uno en precio. Vale la pena señalar que la consulta que se ejecutará después de esta transformación tiene las siguientes características:

• Solo se mostrarán productos de las categorías “Comidas y bebidas navideñas” y “Dulces navideños”.
• Dentro de esas categorías, si los productos también están etiquetados como pertenecientes a la categoría “Calendarios de Adviento”, recibirán un impulso de 3x.
• Se aplica un filtro de precio por $2, que proviene de la política de menor prioridad (porque la política de mayor prioridad especificada es “Restringir” en caso de conflicto).
• La palabra “barato” se elimina, así que se arrojan solo los productos que coinciden con “chocolate”.

Con ambas políticas habilitadas, “chocolate barato” devuelve resultados similares a la imagen que se muestra a continuación:

Relajación de restricciones

Tal vez el minorista no quiere excluir productos en las categorías de “chocolates” y “chocolates de leche” durante Navidad. La configuración de la política de Navidad podría haber excedido los límites y eliminado inadvertidamente las categorías aplicadas por la política de "chocolate barato". Este es un ejemplo que muestra por qué podría ser más deseable combinar políticas de menor prioridad con políticas en conflicto de mayor prioridad. Por ejemplo, podríamos modificar la promoción de chocolates de Navidad para que, en lugar de "anular" en caso de conflicto, hagamos un refuerzo leve. El cambio a esa política sería el siguiente:

Después de esta modificación, la ejecución de la pipeline de transformación del reescritor de consultas para “chocolate barato” tiene el siguiente aspecto:

Con el refuerzo leve en caso de conflicto, los filtros conflictivos se convierten en refuerzos leves en vez de ser descartados. La consulta que se ejecutará en el catálogo de productos luego de esta transformación tiene las siguientes características:

• Debido a que “En conflicto” se especifica como “Refuerzo leve” en la política de mayor prioridad, los conflictos se convertirán en impulsos de la siguiente manera:
  • Los productos de las categorías “comidas y bebidas de Navidad” y “dulces de Navidad” tendrán un refuerzo de 1 vez aplicado.
  • A los productos de las categorías “chocolates” y “chocolates con leche” se les aplicará un refuerzo de 3 veces.
• Como en el ejemplo anterior, si los productos también están etiquetados como en la categoría “calendarios de Adviento”, se reforzará tres veces.
• Como en el ejemplo anterior, se aplica un filtro de precio de $2.
• La palabra “barato” se elimina, así que se arrojan solo los productos que coinciden con “chocolate”.

Con filtrado relajado, los resultados se ven así:

Anulando precio desde una política de alta prioridad

O tal vez el minorista quiere permitir que se muestren chocolates un poco más caros durante Navidad aumentando el precio máximo a $7. Para asegurarnos de que el precio máximo de la política de chocolates navideños no se invalide si alguien hace una "búsqueda de chocolates baratos", podemos establecer el modo de conflicto en el precio en "anular" en lugar de "restringir", de la siguiente manera:

Con esta anulación, la consulta para “chocolate barato” ignora el precio máximo que se define en la “política de chocolate barato” y solo aplica el precio especificado en la “política de chocolates de Navidad”, de la siguiente manera:

Esto es similar al ejemplo anterior, con la diferencia de que el precio máximo se establece en el valor de $7 de la política de mayor prioridad porque esa política especificó “Anular” en caso de conflicto. Con el filtro de precios de Navidad como prioridad, los resultados se ven así:

Estas tres variantes (override, soft_boost y override on price) demuestran una propiedad clave del sistema: un comerciante puede cambiar cómo interactúan dos políticas modificando una configuración en un solo campo dentro de una sola política, sin necesidad de desplegar ningún código. La estrategia de conflicto es el interruptor que controla el comportamiento empresarial.

Seguimiento de frases consumidas

Hay un tipo de conflicto más sutil: dos políticas que coinciden en la misma frase. Si una política de mayor prioridad elimina "sin maní" de la consulta, una política de menor prioridad que también coincidió con "sin" no tiene nada sobre lo que actuar. El sistema detecta si la frase coincidente ya no está presente en la consulta reescrita y omite la política de menor prioridad.

Las políticas de intención están exentas del seguimiento de frases consumidas: establecen la estrategia de recuperación basada en la coincidencia de la consulta original, independientemente del texto que se haya eliminado por políticas de mayor prioridad.

El orden de prioridad, la resolución de conflictos por campo y el seguimiento de frases consumidas juntos otorgan al plano de control un modelo de composición determinista. Con esa base establecida, el sistema puede tomar una decisión de enrutamiento que sería arriesgada sin ella.

La gobernanza hace que la estrategia de recuperación sea segura

Una información importante sobre el enrutamiento al método de recuperación correcto (texto, semántico o híbrido) es que se ejecuta luego de la gobernanza. Si tus políticas ya han aplicado la categoría de "producto", entonces la recuperación semántica se vuelve mucho menos riesgosa porque el conjunto de candidatos está restringido. Una búsqueda semántica sobre 500 productos es una propuesta muy diferente a una búsqueda semántica sobre 500 000 SKU. La gobernanza reduce el radio del impacto antes de que comience la recuperación.

Por ejemplo, sin gobernanza, una consulta semántica para “fruta con alto contenido de vitamina C por menos de $4”, además de frutas, podría devolver botellas de vitaminas, zanahorias y pimientos verdes. El plano de control se encarga de que esos resultados no deseados ni siquiera se tengan en cuenta como parte de la expansión semántica.

Con esa restricción en vigor, el plano de control aplica una lógica de enrutamiento práctica:

• Léxico para consultas de navegación y principales donde la precisión determinista es importante.
• Semántico para consultas de descubrimiento descriptivo donde la coincidencia de conceptos ayuda.
• Híbrido selectivamente, cuando las restricciones ya han sido aplicadas y el negocio acepta una recuperación más amplia.

De la arquitectura a la implementación

El plano de control gestionado traduce la intención comercial en planes de ejecución deterministas y componibles, sin incorporar esa lógica en el código de la aplicación. Las políticas son datos: se emparejan en el momento de la consulta, se resuelven mediante estrategias explícitas de conflicto por campo y se aplican como transformaciones en cascada que producen resultados explicables. Elastic Services Engineering ha construido y desplegado esta arquitectura para equipos de comercio electrónico empresarial, utilizando patrones repetibles y aceleradores que abarcan el camino desde el concepto hasta la producción. Puedes ver una demostración de nuestra implementación de un plano de control en YouTube en: Mejorar la relevancia de búsqueda en segundos: presentamos PRISM.

Lo que se viene

La siguiente publicación aborda la implementación de forma práctica: cómo el percolator de Elasticsearch impulsa la consulta de políticas, incluso los mapeos de índices, los marcadores de límites, el seguimiento de frases basado en resaltados y los ejemplos concretos de consultas.

Pon en práctica la búsqueda gobernada de comercio electrónico

La arquitectura del plano de control descrita en esta publicación (resolución de conflictos por campo, transformaciones en cascada de políticas y enrutamiento de recuperación con restricciones de gobernanza) fue diseñada y construida por Elastic Services Engineering. Todos los patrones, capturas de pantalla y pipeline de transformación que se muestran en esta serie provienen de un sistema operativo creado por Elastic Services Engineering y validado con catálogos de productos a escala empresarial.

Si quieres implementar un plano de control regulado y basado en políticas en Elasticsearch, Elastic Services te ayuda a lograrlo más rápido.

Únete a la discusión

¿Tienes preguntas sobre la gestión de búsquedas, las estrategias de recuperación o la arquitectura de búsqueda en el comercio electrónico? Únete a la conversación general de la comunidad de Elastic.