En esta última publicación nos preguntamos: ¿Qué cambia cuando la entrada proviene de un agente de IA?

La respuesta es que la arquitectura no cambia, pero las implicancias sí. Cada propiedad del plano de control regulada que es relevante para las consultas de autor humano es más importante cuando quien toma decisiones en sentido ascendente es un modelo de lenguaje grande (LLM). El determinismo, la auditabilidad, la resolución de conflictos y la aplicación de restricciones se convierten en medidas de seguridad fundamentales, en vez de simples comodidades operativas, ya que el sistema que genera los datos de entrada es de naturaleza probabilística.

El problema de la búsqueda con agentes

El enfoque más común para la búsqueda impulsada por IA es sencillo: proporciona al LLM el esquema de base de datos y las reglas de negocio en la indicación, y deja que el agente genere la consulta directamente.

Para un chatbot de comercio electrónico, esto significa inyectar el mapeo del índice, los tipos de campos, las taxonomías de categorías, la lógica de precios y las restricciones de negocio de Elasticsearch en la ventana de contexto del agente, y luego pedir al LLM que traduzca el lenguaje natural a un DSL de búsqueda de Elasticsearch válido. El LLM se convierte en el autor de la consulta.

Este enfoque funciona en demostraciones. Sin embargo, falla en producción por cuatro razones.

Exceso de contexto

El mapeo de índices de comercio electrónico empresarial no es un documento trivial. Las definiciones de campo, los objetos anidados, las configuraciones de varios campos y la configuración del analizador pueden ejecutarse en miles de tokens antes de que se agregue cualquier lógica de negocio. Además del mapeo, el agente necesita taxonomías de categorías (que en el comercio electrónico empresarial pueden contener decenas de miles de valores), reglas de precios, jerarquías de marcas, restricciones de elegibilidad y lógica de campañas.

El resultado es una ventana de contexto en la que predominan los metadatos estructurales en vez de la intención real del usuario. Esto aumenta la latencia, incrementa el costo de los tokens y reduce la capacidad del LLM para seguir instrucciones a medida que aumenta el contexto. Este es un fenómeno bien documentado, a veces llamado descomposición de contexto: a medida que el mensaje se hace más largo, la atención del modelo a cualquier instrucción particular se debilita.

Alucinación probabilística

Los LLM generan consultas basadas en patrones en sus datos de entrenamiento y el contexto proporcionado. Cuando se le solicita al modelo que genere un DSL de consulta de Elasticsearch, este puede inventar nombres de campos inexistentes, elaborar cláusulas de consulta sintácticamente inválidas, aplicar de forma errónea tipos de filtro a campos equivocados o generar consultas que son sintácticamente válidas pero semánticamente incorrectas, por lo cual arroja resultados que no coinciden con la intención del usuario.

La prueba de rendimiento BIRD de Google Cloud para la conversión de texto a SQL muestra los límites de este enfoque. El resultado de vanguardia de un solo modelo de Google alcanzó entre un 70% y un 80% de precisión, lo que significa que casi una de cada cuatro consultas generadas era incorrecta. Esto es para SQL, que está mucho más estandarizado que Elasticsearch Query DSL. La tasa de error para consultas de Elasticsearch generadas por LLM en un entorno de producción real, con mapeos complejos y semántica específica del negocio, probablemente sería mayor.

Una tasa de error de una de cada cuatro consultas en un sistema de comercio electrónico que es fundamental para los ingresos no es un problema de ajuste que deba resolverse de forma iterativa. Es una limitación arquitectónica del enfoque.

La brecha de seguridad

Cuando el LLM tiene acceso al esquema de la base de datos y actúa como el autor de la consulta, el sistema es vulnerable a la inyección indirecta de indicaciones. Un usuario que interactúa con un chatbot de comercio electrónico puede crear entradas diseñadas para manipular al agente y que genere consultas no intencionadas.

No se trata de un riesgo teórico. La inyección de indicaciones es una de las superficies de ataque que más se investiga de forma activa en sistemas de MLM desplegados. El problema fundamental es que, cuando el agente crea la consulta, no hay una separación clara entre la intención del usuario y la ejecución de la consulta. El LLM interpreta la solicitud del usuario y, al mismo tiempo, crea la operación de la base de datos. Cualquier manipulación de la primera afecta directamente a la segunda.

Fallo de escalado de alta cardinalidad

Ciertos campos del comercio electrónico tienen una cardinalidad extrema. Un catálogo de productos puede tener 17 000 valores de categoría, miles de marcas y cientos de combinaciones de atributos. Los flujos de trabajo estándar de los agentes requieren inyectar estos valores en el contexto para que el LLM pueda seleccionar el correcto al construir una consulta.

Esto crea un dilema imposible: se inyectan todos los valores posibles (consumiendo un contexto enorme y degradando el rendimiento), se inyecta un subconjunto (y se acepta que el agente no puede hacer referencia a valores fuera de ese subconjunto) o se recurre a una búsqueda no regulada. Esto se conecta directamente con el problema principal de la Parte 1: si el LLM busca “naranjas” y Elasticsearch devuelve refresco de naranja, la experiencia de chat se degrada de la misma manera que lo hace una experiencia de búsqueda.| La ausencia de gobernanza significa que el sistema no puede aplicar la resolución prevista por el comprador.

Recuperar valores relevantes que estén dinámicamente basados en la consulta es una alternativa conocida, pero introduce un paso adicional no determinista donde la recuperación en sí puede omitir valores relevantes. Además, esto agrega latencia y complejidad a cada consulta.

La alternativa arquitectónica: desacoplar la intención de la ejecución

El plano de control regulado descrito en las Partes 1 a 7 ofrece un enfoque totalmente diferente. En vez de que el LLM elabore la consulta final, su papel se reduce a una sola tarea bien delimitada: extraer un texto de intención de búsqueda de la entrada de lenguaje natural del usuario.

El usuario dice: "Estoy buscando zapatos marrones baratos". La función del agente no es generar una consulta de Elasticsearch. Su función es extraer y transmitir la intención de búsqueda (en este caso, algo como "zapatos marrones baratos") al plano de control. Entonces, el plano de control hace lo de siempre: filtra la intención de texto por las políticas almacenadas, compone las políticas coincidentes mediante transformaciones en cascada, resuelve los conflictos de forma determinista y produce una consulta de Elasticsearch controlada.

El LLM nunca ve el mapeo de índice. Nunca sabe sobre tipos de campos, taxonomías de categorías o umbrales de precios. Nunca construye una cláusula de consulta. Opera en el lado del lenguaje natural de un límite arquitectónico que llamamos el espacio aéreo de metadatos, una separación estricta entre el componente probabilístico (el LLM) y la capa de datos estructurados (esquema, políticas y construcción de consultas).

Lo que proporciona el aislamiento de metadatos

• Ceguera de esquema. El LLM no tiene acceso al esquema de la base de datos y, por lo tanto, no puede generar consultas inválidas, alucinar nombres de campo ni ser manipulado para exponer información estructural. El esquema existe solo en el lado determinista del aislamiento.

• Contexto mínimo. En vez de miles de tokens de datos de mapeo, reglas de negocio y taxonomías de categorías, la indicación del LLM contiene solo instrucciones de extracción de persona e intención. Esto reduce drásticamente el costo de tokens, la latencia y la degradación del contexto.

• Ejecución determinista. Cada consulta que llega a Elasticsearch está construida por el plano de control usando plantillas de políticas controladas por humanos, no generadas probabilísticamente por un LLM. La validez sintáctica está garantizada. La corrección semántica se aplica mediante el mismo marco de políticas descrito en las Partes 1 a 6.

• Seguridad por arquitectura. La inyección inmediata deja de ser eficaz desde el punto de vista estructural. Incluso si un usuario manipula al agente para que produzca un texto de intención inusual, ese texto se filtrará por las políticas almacenadas. Si ninguna política coincide, no se genera ninguna consulta. El usuario no puede pedirle al agente que cree una consulta porque el agente no crea consultas. El plano de control lo hace, y el plano de control es determinista.

Cómo se conectan las piezas

El siguiente recorrido muestra cómo el plano de control regulado maneja una consulta mediada por agente.

Paso 1: El usuario habla con el agente

Un comprador que interactúa con un chatbot de comercio electrónico dice: "Estoy buscando chocolate barato, nada con maní."

Paso 2: El agente extrae la intención

La función del LLM es extraer intenciones, no generar consultas. Con un prompt mínimo que le indica identificar la intención del producto, el agente produce un texto de intención de búsqueda: "chocolate barato sin maní".

Esta es una tarea de clasificación sencilla. El LLM no necesita el mapeo de índice, la taxonomía de categorías ni las reglas de precios para realizarlo. Necesita entender el lenguaje natural, que es precisamente la fortaleza de los LLM.

Paso 3: El plano de control regula la consulta

El texto de intención "chocolate barato sin maní" se pasa al plano de control, que lo filtra por el índice de políticas. Tres políticas coinciden:

• La política de "barato" (extrae "barato", aplica un filtro de precio basado en la categoría del producto).

• La política de "chocolate" (limita los resultados a categorías de chocolate).

• La política de negación "sin" (extrae el objetivo de exclusión y aplica un filtro must_not )

El plano de control aplica estas políticas mediante la misma transformación en cascada descrita en la Parte 3 y la Parte 4: orden de prioridad, resolución de conflictos por campo, seguimiento de frases consumidas. Si una política de “campaña navideña” también está activa, se compone con las políticas del producto exactamente como se describe en Parte 3, la participación del agente no cambia el modelo de gobernanza en absoluto.

Paso 4: Se ejecuta la consulta regulada

El plano de control produce una consulta de Elasticsearch completamente regulada: una búsqueda de “chocolate”, limitada a las categorías adecuadas, con un límite de precio derivado de la política “barato”, un filtro de exclusión para productos que contienen maní y cualquier impulso activo de campaña aplicado. Si la política de “chocolate” también incluye pesos de optimización económica (Parte 7), estos también se aplican. El aumento de margen está establecido en 3.0x porque “chocolate” es una consulta de navegación donde el minorista se beneficia de promover productos de mayor margen. Si el comprador tiene historial de compras (Parte 6), las señales de personalización se superponen. Esta consulta es sintácticamente válida por construcción y semánticamente correcta por diseño de políticas.

Paso 5: Los resultados se envían a través del agente

Los resultados del producto se arrojan al agente, que los presenta de forma conversacional al usuario. El papel del agente en la ruta de retorno es la presentación: formatear resultados, responder preguntas de seguimiento, proporcionar detalles del producto. La recuperación en sí fue regulada, determinista y explicable.

En qué es bueno el agente (y en qué no lo es)

Esta arquitectura aprovecha las fortalezas del LLM y protege al sistema de sus debilidades.

Los LLM sobresalen en la comprensión de la intención del lenguaje natural. “Estoy buscando chocolate barato, nada con maní” es una tarea de comprensión del lenguaje natural, análisis de intención, identificación de referencias de productos, reconocimiento de negación. Los LLM gestionan esto de forma fiable porque es un problema de clasificación, no de generación. La salida es un texto corto de intenciones, no una consulta estructurada y compleja.

A los modelos de lenguaje grande (LLM) les cuesta generar salidas estructuradas con precisión bajo restricciones complejas. La generación de una DSL de consulta de Elasticsearch válida requiere nombres de campo exactos, anidación correcta de cláusulas, tipos de filtro adecuados para cada campo y una aplicación coherente de reglas de negocio en miles de casos límite. Estas son exactamente las propiedades que un sistema determinista impone de forma trivial y que un sistema probabilístico impone de forma poco fiable.

El plano de control regulado coloca cada componente donde corresponde: el LLM en el lado del lenguaje natural, el motor de políticas deterministas en el lado de construcción de consultas, y un límite arquitectónico entre ellos.

La gobernanza limita el alcance del impacto

Esta es la misma información de la Parte 3, extendida al contexto agente. En la Parte 3, observamos que la gobernanza hace que la recuperación semántica sea más segura, ya que reduce el conjunto de candidatos antes de que comience la recuperación. Una búsqueda semántica sobre 500 productos en una categoría regulada es una propuesta muy diferente a una búsqueda semántica sobre 500 000 SKU.

El mismo principio se aplica a las consultas mediadas por agentes. Sin gobernanza, un agente que malinterprete "chocolate barato" podría generar una consulta que realice una búsqueda en todo el catálogo sin restricciones de precio, sin filtro de categoría y sin exclusiones. Con gobernanza, incluso si el agente produce un texto de intención imperfecto, el plano de control restringe la consulta a las políticas que coinciden. El peor caso es que se activen menos políticas, no que una consulta sin límite acceda al catálogo de productos.

La gobernanza reduce el alcance de los errores probabilísticos. Esto es cierto tanto si el componente probabilístico es un modelo de recuperación semántica como un agente LLM.

Políticas sugeridas por LLM: ampliar la cobertura

La Parte 2 presentó la idea de que un LLM puede sugerir nuevas políticas que ingresen en el mismo pipeline Author → Test → Promote que las de autoría humana. En el contexto de agentes, esto se convierte en un ciclo de retroalimentación poderoso.

Un LLM puede analizar registros de consultas, identificar patrones donde el plano de control no tiene una política coincidente (consultas que llegan a la recuperación sin modificaciones) y sugerir nuevas políticas para cubrir esas brechas. Un comerciante revisa cada sugerencia, la prueba y la promueve si produce el comportamiento esperado. El modelo de gobernanza asegura que ninguna política sugerida por LLM llegue a producción sin validación humana.

Con el tiempo, esto crea un ciclo virtuoso: la cobertura de políticas del plano de control se expande, la proporción de consultas que requieren una recuperación sin modificar se reduce, y el sistema se vuelve cada vez más regulado, con cada política auditable, versionada e individualmente reversible.

El patrón general: barreras de seguridad deterministas para sistemas probabilísticos

La arquitectura descrita en este serial, un plano de control determinista situado entre una fuente de entrada probabilística y un sistema de recuperación de datos, no es específica de la búsqueda en el comercio electrónico. El mismo patrón se aplica siempre que un agente de IA necesite interactuar con datos estructurados.

Un agente que consulta una base de datos SQL se enfrenta a los mismos desafíos: exceso de contexto por inyección de esquemas, nombres de columnas alucinados, riesgos de inyección inmediata y selección de valores de alta cardinalidad. Un agente que trabaja con un sistema de gestión de incidencias como Jira, un sistema de gestión de relaciones con los clientes (CRM) como Salesforce o un repositorio de código como GitHub se enfrenta a problemas similares. En todos los casos, la pregunta arquitectónica del núcleo es la misma: ¿Debe el LLM crear la consulta, o debe el LLM extraer la intención y pasarla a una capa determinista que crea la consulta?

El plano de control regulado proporciona una respuesta repetible a esa pregunta. Las políticas son datos. La función del LLM es extraer intenciones. El plano de control se ocupa de desarrollar consultas. El espacio de metadatos los mantiene separados. Y el marco de trabajo (orden de prioridad, resolución de conflictos, transformaciones en cascada, auditabilidad) asegura que la capa determinista sea operacionalmente manejable a medida que aumenta el número de políticas.

Conclusión

Los patrones de gobernanza de búsqueda en comercio electrónico descritos en este serial (políticas como datos, el flujo de trabajo Author → Test → Ascender flujo de trabajo, transformaciones en cascada, resolución de conflictos por campo, coincidencia inversa basada en filtro y respaldo multinivel) se diseñaron para un mundo donde el comerciante redacta políticas y el cliente tipifica consultas. Pero la arquitectura tiene más potencial que su caso de uso inicial.

Cuando la fuente de entrada es un agente de IA en vez de un comprador humano, el plano de control regulado se convierte en la capa de seguridad fundamental entre un sistema probabilístico y un almacén de datos de producción. Ofrece las garantías determinísticas (validez sintáctica, corrección semántica, auditabilidad y seguridad) que necesitan los sistemas empresariales y que los modelos de lenguaje grande (LLM) no pueden ofrecer por sí solos.

El plano de control determinista no reemplaza al agente de IA. Hace que el agente de IA sea seguro para desplegar.

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

La arquitectura del plano de control regulado descrita en este serial, desde el paradigma de política como datos hasta la búsqueda basada en filtro, personalización, optimización económica y el aislamiento de agente, fue diseñada y desarrollada por Elastic Services Engineering. Todos los patrones que se describen en esta serie provienen de un sistema operativo creado y validado con catálogos de productos a escala empresarial.

Si tu equipo está desarrollando experiencias de búsqueda impulsadas por IA y necesita límites deterministas para consultas mediadas por agentes, o si quieres implementar una arquitectura de búsqueda regulada y editable por el negocio en Elasticsearch, Elastic Professional Services puede acelerar tu implementación. Ponte en contacto con Elastic Professional Services.

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

En esta publicación se presentan dos mecanismos de personalización que amplían el plano de control gestionado sin modificar su arquitectura. Ambos mecanismos se apilan multiplicativamente con la capa de gobernanza de las partes 1 a 5: las políticas aún se activan, las restricciones aún se aplican, los conflictos aún se resuelven y las señales de personalización se componen en la misma consulta gobernada, lo que asegura que los resultados que devuelve Elasticsearch ya están personalizados.

El primer mecanismo impulsa los productos que el comprador individual ha adquirido anteriormente. El segundo activa políticas específicas de cohorte basadas en el perfil del comprador. En conjunto, demuestran que la personalización no es un sistema separado que se combina con la búsqueda ni se aplica como procesamiento posterior a la recuperación; es una extensión natural del plano de control orientado a políticas.

Para profundizar en las matemáticas de las técnicas de personalización utilizadas en esta publicación, consulta Personalización de la búsqueda en Elasticsearch sin postprocesamiento de ML y Clasificación basada en cohortes en Elasticsearch.

Para ver una demostración en vivo de cómo se puede usar el historial de compras para mejorar los resultados de búsqueda de los clientes que regresan, mira el video: Personalización explicable: cómo impulsar la búsqueda con historial de compras.

Impulso del historial de compras individuales

La forma más simple de personalización es también una de las más efectivas: si un comprador ha adquirido un producto antes, promuévalo cuando haga una búsqueda de algo relacionado. Un comprador que adquiere habitualmente una marca concreta de galletas con pepitas de chocolate debería ver esas galletas mejor posicionadas en los resultados de búsqueda cuando busque “galletas”, no porque un modelo predijo una preferencia, sino porque existe evidencia conductual directa.

Cómo funciona

Cuando una solicitud de búsqueda incluye un identificador de usuario, como sería el caso de un usuario que tiene una sesión abierta, el plano de control ejecuta dos consultas de Elasticsearch en paralelo utilizando un thread pool:

1. La consulta del percolador contra el índice de políticas (la misma búsqueda de gobernanza descrita en las partes 3 y 4).

2. Una búsqueda de historial de compras contra un índice de user_purchases, filtrada al usuario específico por term(user_id) y luego comparando el texto de búsqueda actual con los títulos de producto de ese usuario.

Estos procesos se ejecutan en paralelo (ninguno espera al otro), así que la búsqueda de personalización no agrega una latencia significativa al pipeline de gobernanza.

La búsqueda del historial de compras utiliza el análisis de texto de Elasticsearch (derivación, tokenización) al comparar la cadena de búsqueda actual con los títulos de los productos almacenados. Esto significa que una búsqueda de “cookies” coincidirá con una compra anterior de “galletas brownie” a través del análisis de texto estándar, sin requerir una coincidencia exacta de cadenas.

Cálculo de pesos de aumento

No todas las compras anteriores merecen el mismo impulso. La ponderación considera dos factores intuitivos: la frecuencia con la que el comprador adquirió el producto y qué tan reciente fue la compra. Un producto comprado 15 veces la semana pasada es una señal mucho más fuerte que un producto comprado una vez hace seis meses. La ponderación utiliza una escala logarítmica basada en la frecuencia (para que un único artículo comprado en grandes cantidades no eclipse al resto) y un decaimiento exponencial basado en la antigüedad (para que las compras más antiguas pierdan relevancia de forma natural con el tiempo).

Para conocer los detalles matemáticos de la fórmula de aumento, consulta Cómo personalizar la búsqueda en Elasticsearch sin posprocesamiento de ML.

Cómo se convierte en una consulta

Los impulsos del historial de compras se integran en la consulta como la capa de puntuación más externa, envolviendo los filtros de política de gobernanza y los impulsos de las partes 3 y 4 y cualesquier impulso de señales comerciales, como margen y popularidad (que exploraremos en la parte 7). Esto significa que un producto que se elimina por una política de gobernanza no reaparecerá debido a un impulso en el historial de compras. La gobernanza controla el conjunto de resultados; la personalización ajusta el orden dentro de él. Los productos sin historial de compras no se penalizan. Se mantiene su clasificación gobernada, aunque los productos con un historial de compras relevante aparecerán por encima de ellos, en igualdad de condiciones.

¿Por qué consultar Elasticsearch en cada búsqueda?

El historial de compras se consulta desde Elasticsearch en cada búsqueda, en lugar de almacenarse en caché en la capa de la aplicación. Esta es una decisión de diseño deliberada. Como la consulta compara la cadena de búsqueda actual con los títulos de productos mediante el pipeline de análisis de texto de Elasticsearch, el sistema se beneficia de la misma reducción a la raíz, tokenización y manejo del lenguaje que usa la propia búsqueda de productos. Una consulta en memoria caché requeriría reimplementar ese análisis o aceptar una coincidencia menos precisa.

Para ver por qué este orden es importante, considere a un comprador que previamente adquirió jugo de naranja y ahora busca “naranjas”. La consulta de historial de compras compara “jugo de naranja” con el término de búsqueda “naranjas” mediante análisis de texto y calcula un impulso para ese producto. Pero la capa de gobernanza ya ha restringido las “naranjas” a la categoría de productos, filtrando completamente el jugo de naranja. El impulso del historial de compras para el jugo de naranja está presente en la consulta, pero no tiene efecto porque no hay un documento coincidente en el conjunto de resultados gobernado sobre el que pueda actuar. El comprador ve naranjas frescas, ordenadas por relevancia y personalización. La barrera de seguridad de gobernanza se mantiene.

El costo de rendimiento es mínimo: el índice de historial de compra es pequeño (el historial de compra de un usuario suele ser de decenas o cientos de documentos, no de millones), y la consulta se ejecuta en paralelo con la búsqueda del percolador, por lo que no alarga la ruta crítica.

Ejemplo de búsqueda para “agua de manantial” sin historial de usuario

Si un usuario que no ha iniciado sesión o un usuario que nunca ha comprado “agua de manantial” busca, es posible que vea resultados similares a los siguientes:

Ejemplo de historial de compra del usuario

Por otro lado, una usuaria llamada Carol tiene un historial de compras que contiene los siguientes productos:

Ejemplo de búsqueda de “agua de manantial” con el historial de compras anterior

Si Carol busca “agua de manantial”, verá resultados personalizados que reflejan lo que ha comprado en el pasado. Al observar el historial de compras anterior, ella compró “agua de manantial carbonatada” (la botella verde) unas 40 veces, y más recientemente hace dos días. Si busca “agua de manantial”, ese producto aparecerá en los primeros resultados, ya que sabemos que le gusta. Observa que en los resultados no personalizados, el agua de manantial Rubicon fue el primer resultado en aparecer.

Activación de políticas con reconocimiento de cohortes

El historial de compras individual funciona bien para los clientes habituales con un comportamiento ya establecido. Pero muchos compradores son nuevos, anónimos o navegan fuera de sus hábitos habituales. Para estos compradores, la membresía de cohorte proporciona un tipo diferente de personalización, una basada en quién es el comprador, no en lo que han hecho.

Un comprador vegano que busque “chocolate” debería ver el chocolate vegano clasificado más alto. Un comprador que sigue las normas halal y busca “refrigerios” debería ver opciones con certificación halal en un lugar destacado. Un comprador consciente de la salud que busca “yogur” debería ver opciones probióticas resaltadas.

Cohortes como políticas, no como etiquetas de productos

Los productos ya llevan sus atributos normales, incluidos campos como dietary_restrictions: ["vegan"] o dietary_restrictions: ["halal"]. La pregunta es dónde reside la lógica que conecta la cohorte de un comprador con esos atributos de producto.

El enfoque ingenuo sería codificar ese mapping en la capa de aplicación o en la plantilla de búsqueda: si el usuario es vegano, agrega un impulso a dietary_restrictions: "vegan". Pero este es el mismo código espagueti de la parte 1, y crea la misma fricción operativa: agregar una nueva cohorte o cambiar lo que significa una cohorte requiere un cambio de código.

En cambio, el plano de control gestionado mantiene la lógica de cohortes en el motor de políticas. Una política de cohorte combina dos cosas: la membresía de cohorte de un comprador (por ejemplo, “vegana”) y un atributo de producto (por ejemplo, dietary_restrictions: “vegan”). La política define la conexión: cuando un comprador en la cohorte vegana realiza una búsqueda, impulsa los productos donde dietary_restrictions incluye “vegano”.

Como la lógica de cohortes reside en el motor de políticas y no en el código de aplicación, esto significa lo siguiente:

• Para añadir una nueva cohorte, basta con crear una nueva política; no es necesario volver a indexar el producto.

• Las políticas de cohorte utilizan el motor de reglas completo: pueden agregar filtros, aplicar impulsos suaves, expandir sinónimos, cambiar la estrategia de recuperación o realizar cualquier otra acción que una política pueda tomar.

• El comportamiento de la cohorte se gestiona a través de la misma interfaz de administración que todas las demás políticas: un comerciante puede crear, probar y promover políticas de cohorte a través del flujo de trabajo Autor → Prueba → Promoción descrito en la parte 2.

Ejemplo de política de cohorte vegana

Un merchandiser crea una política de cohorte con las siguientes características:

• Cohortes: ["vegan"].

• Criterio de coincidencia: coincide con cualquier búsqueda (o una categoría específica de producto).

Acción: refuerzo leve en dietary_restrictions: "vegan" con una ponderación de refuerzo de 2.

Cómo funciona la activación de cohortes

Cada documento de política tiene un campo cohorts. Las políticas universales que se aplican a todos los compradores independientemente de la cohorte pueden dejar este campo en blanco, e internamente se les asignará un valor de "_all" por el plano de control. Las políticas específicas de cohorte almacenan los nombres de sus cohortes objetivo, como ["vegan", "kosher", “sweet_tooth”].

Cuando una solicitud de búsqueda incluye un perfil de usuario, el plano de control construye un filtro terms simple para la consulta del percolador:

Este filtro único incluye todas las políticas universales, además de las políticas específicas de la cohorte del usuario. El _all centinela hace que este sea un filtro de inclusión limpio: no se necesitan búsquedasmust_not o exists para manejar el caso en el que una política no tiene restricción de cohorte.

A continuación, el percolador evalúa las coincidencias de políticas como de costumbre. La única diferencia es que el conjunto de políticas candidatas se redujo a aquellas relevantes para las cohortes de este comprador. Todo el flujo descendente (transformaciones en cascada, resolución de conflictos por campo, seguimiento de frases consumidas) funciona de manera idéntica al flujo no personalizado descrito en las partes 3 y 4.

Resultados de usuarios no veganos (estándar) al buscar “chocolate”

Cuando un usuario no vegano realiza una búsqueda de chocolate, no se aplica ningún aumento de cohorte vegano a sus resultados. A menudo veía chocolates no veganos entre los resultados más populares, como por ejemplo:

Resultados de la política de cohorte vegana al buscar “chocolate”

Cuando un comprador de cohorte vegana realiza una búsqueda de “chocolate”, esta política se incluye en el conjunto de candidatos del percolador. Coincide, y el plano de control aplica un impulso suave a los chocolates certificados como veganos. El aumento es multiplicativo: los chocolates veganos tienen un rango más alto, pero los chocolates no veganos no están completamente excluidos porque el filtro anterior se define como un impulso suave, que describimos en detalle en la parte 3 de esta serie.

Sin embargo, si el comprador busca explícitamente “chocolate con leche Hershey”, la preferencia vegana sigue siendo aplicable, pero puede verse superada por la mayor relevancia textual de los productos de chocolate con leche Hershey.

Un comprador fuera de la cohorte vegana que busca la misma consulta nunca ve la política de la “cohorte vegana”; no está en su conjunto de candidatos. La capa de gobernanza es idéntica; solo el conjunto de políticas activas difiere.

Cohortes con historial de compra

Un comprador vegano con un historial de compra extenso obtiene la activación de políticas específicas para la cohorte vegana, así como impulsos en el historial de compra. Para compradores nuevos o anónimos, la membresía implícita en la cohorte por sí sola proporciona una personalización significativa sin requerir datos de comportamiento (por ejemplo, quizás un usuario anónimo solo buscó productos veganos, por lo que lo clasificamos como afiliado a la cohorte vegana). Un comprador que se autoidentifica como seguidor de las normas de halal durante la creación de la cuenta recibe inmediatamente resultados adaptados a halal en su primera búsqueda.

Cómo se componen las capas de personalización

El orden de anidación de function_score capas importa. De lo más interno a lo más externo:

1. Búsqueda base: la palabra clave o coincidencia semántica con consultas nombradas (fulltext_match, title_phrase_match).

2. Capa de política de gobernanza: filtros duros como cláusulas bool.filter, impulsos suaves como funciones function_score (Partes 3 y 4).

3. Impulsos de señales de negocio: aumento de margen y popularidad (que exploraremos en la parte 7).

4. Impulsos del historial de compra: La capa function_score más externa.

Este orden garantiza que la gobernanza controle el conjunto de resultados (lo que aparece), que las señales de negocio ajusten la clasificación dentro de ese conjunto (lo que aparece primero desde la perspectiva del minorista) y que el historial de compras ajuste aún más la clasificación según el comportamiento individual (lo que aparece primero desde la perspectiva del comprador). Cada capa envuelve a la anterior de manera multiplicativa, por lo que los efectos se acumulan en lugar de entrar en conflicto.

Qué significa esto a nivel operativo

La personalización a través del plano de control gobernado preserva todas las propiedades operativas descritas en las Partes 1 y 2:

• Cambios sin necesidad de despliegue. Las políticas de cohorte se crean, prueban y promueven a través de la IU de administración. Agregar una nueva cohorte dietética o ajustar un peso de refuerzo no requiere cambios en el código ni participación de ingeniería.

• Auditabilidad. Cada política de cohorte es un documento independiente y versionado. Cuando un comercializador pregunta: “¿Por qué los productos veganos aparecen mejor posicionados para este usuario?”, la respuesta es una política específica con una prioridad determinada, visible en el panel de depuración junto con todas las demás políticas que se activaron para esa consulta.

• Resolución de conflictos. Las políticas de cohorte participan en la misma resolución de conflictos por campo descrita en la Parte 3. Si el aumento de categoría de una política de cohorte entra en conflicto con la anulación de categoría de una política de campaña, el conflicto se resuelve de forma determinista mediante el mismo marco de trabajo de prioridades y estrategia, sin necesidad de una gestión especial.

• Mensurabilidad. Debido a que las políticas de cohorte son discretas y se pueden activar individualmente, su impacto en las tasas de conversión, clics y agregados al carrito puede medirse de forma independiente, al igual que cualquier otra política en el sistema.

Lo que se viene

En la próxima publicación se explora otra dimensión del plano de control gestionado: cómo el margen y el impulso de la popularidad pueden ajustarse por consulta a través de políticas, lo que convierte la optimización económica en una decisión de gobernanza en lugar de una configuración estática.

Consulta la parte 7: optimización económica gobernada por consultas: margen por búsqueda y aumento de popularidad

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

Los patrones de personalización descritos en esta publicación (aumento del historial de compras individuales y activación de políticas consciente de la cohorte) fueron diseñados y desarrollados por Elastic Services Engineering como parte de nuestro acelerador de búsqueda de comercio electrónico repetible. Ambos mecanismos se integran con la arquitectura del plano de control gobernado descrita a lo largo de esta serie. Ponte en contacto con Elastic Professional Services.

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

De la arquitectura a la implementación

La Parte 3 describió la arquitectura del plano de control: coincidencia inversa como primitiva de búsqueda, documentos de políticas que separan la coincidencia de la acción y transformaciones en cascada que componen varias políticas en un solo plan de ejecución. Esta publicación pone en práctica la búsqueda del percolador de Elasticsearch, la función que permite la búsqueda de políticas.

El percolador se adapta naturalmente a la gobernanza porque invierte la dirección de búsqueda exactamente de la forma que necesita un plano de control. Esta publicación analiza la implementación paso a paso, comenzando con una explicación clara de la función del percolador y por qué es importante, pasando luego por el diseño del índice, el almacenamiento de políticas, la evaluación del tiempo de búsqueda y la composición de políticas múltiples.

Cómo funciona la búsqueda normal

En un sistema de comercio electrónico, puedes tener cientos de miles o millones de documentos de productos que contienen campos como title, category, y price. Cuando un usuario busca documentos coincidentes, le estás pidiendo a Elasticsearch que compare el texto de búsqueda del usuario con uno o más campos almacenados en estos documentos de producto. El analizador predeterminado de Elasticsearch, el analizador estándar, convierte el texto a minúsculas y lo divide en tokens. Una búsqueda de “naranjas” coincide con “Naranjas” debido a las minúsculas. Con un analizador sensible al idioma que incluye derivación, también coincide con “naranja” porque ambas formas se reducen a la misma raíz. Por ejemplo, la siguiente consulta de coincidencia devuelve documentos que tienen “naranja” o “naranjas” en su campo “title”.

Entonces, para la búsqueda anterior, Elasticsearch devuelve los documentos del producto cuyo campo title coincide con “naranjas”, que podrían incluir resultados como “Mermelada de naranja”, “Jugo de naranja”, “Naranjas jugosas”, “Mermelada de naranja”, etc. El punto clave a recordar es que Elasticsearch se usa comúnmente para comparar un texto de búsqueda con documentos y para devolver los documentos que coinciden con el texto de búsqueda.

El problema de la gobernanza: encontrar políticas relevantes antes de buscar productos

Como se ha explicado en las Partes 1 a 3, un sistema de búsqueda gestionado no envía el texto de búsqueda del usuario directamente al catálogo de productos. Primero, comprueba si alguna política se aplica a ese texto de búsqueda.

Un vendedor decidió que cuando alguien busca exactamente "naranjas", los resultados deben restringirse a la categoría Naranjas y eliminar el jugo de naranja, la mermelada de naranja y el refresco de naranja. Esa decisión empresarial se almacena como una política. Cuando un usuario escriba "naranjas", el plano de control necesita encontrar esa política, leer sus instrucciones y modificar la búsqueda en el catálogo de productos en consecuencia. Para ello, el plano de control tiene que determinar qué políticas almacenadas son relevantes para esta cadena de búsqueda.

Un despliegue empresarial podría tener cientos o miles de políticas de este tipo. Comprobarlas una por una con lógica condicional (si/entonces) es el antipatrón de la capa de aplicación descrito en la Parte 2. Lo que necesitamos es una forma de almacenar todas esas políticas en un índice y encontrar instantáneamente las que coincidan con un texto de búsqueda determinado. Aquí es donde entra en juego el percolador.

Cambiando la dirección: el percolador

Como mencionamos anteriormente, en una búsqueda normal, Elasticsearch se usa comúnmente para comparar un texto de búsqueda con documentos y devolver los documentos que contienen ese texto de búsqueda.

El percolador hace justo lo contrario. Con un percolador, tienes un índice donde cada documento almacena un patrón de búsqueda, y luego se comprueba un texto de búsqueda entrante contra estas búsquedas almacenadas para determinar cuál de estos patrones de búsqueda almacenados se activó.

En materia de gobernanza, los "patrones de búsqueda almacenados" son políticas. Cada política contiene un patrón que describe el tipo de texto de búsqueda con el que debe coincidir. Por ejemplo, ¿el texto de búsqueda coincide exactamente con “naranjas” o el texto de búsqueda contiene “aceite de oliva”? La cadena entrante es el texto de búsqueda del usuario, que llega en el momento de la búsqueda y debe comprobarse con todos los patrones de políticas almacenados. Esto se cubre en un video relacionado con PRISM a las 4:09.

Paso a paso: cómo una búsqueda de "naranjas" encuentra su política

La política

Un vendedor ha creado una política que produce una coincidencia si un usuario busca exactamente "naranjas" sin ninguna otra palabra. Una vez que el percolador genera una coincidencia, el resto del documento incluye las reglas que el plano de control usará para crear la búsqueda del producto; en este ejemplo, una de las reglas es restringir (filtrar) los resultados a la categoría Frutas.

El campo percolator contiene el patrón que define cuándo debe ejecutarse esta política. En este caso, coincide con la expresión "START oranges END". Los campos rule_type y rule_args definen lo que debe hacer la política cuando se activa. Los tokens START y END son marcadores de límites, que explicaremos en breve.

Puedes ver cómo se crea una política en la UI de PRISM Studio en el minuto 2:52 del video relacionado de PRISM.

El usuario busca

Un comprador escribe "naranjas" en la barra de búsqueda.

El plano de control verifica las políticas de coincidencia

Antes de buscar en el catálogo de productos, el plano de control intercepta la cadena de búsqueda del usuario, la contiene entre marcadores de límite y la envía al percolador:

El texto "START oranges END" se comprueba con todos los patrones de políticas almacenados. Internamente, Elasticsearch ejecuta los patrones de políticas almacenados relacionados con este texto y devuelve los que coinciden. Ese es el percolador. La cadena de búsqueda del usuario se comprobó según todos los patrones de políticas almacenados, y se devolvieron los que coincidían. No se permiten cadenas si/entonces. Sin evaluación secuencial. El índice maneja la coincidencia.

El plano de control aplica la política

El plano de control lee las acciones de las políticas coincidentes. La política anterior indica al plano de control que limite los resultados a la categoría Frutas. El plano de control crea la búsqueda final de Elasticsearch sobre el catálogo de productos de la siguiente manera:

El usuario buscó "naranjas". El catálogo de productos recibe una búsqueda para "naranjas" restringida a la categoría Frutas. Debido a esta restricción, se excluyen el jugo de naranja, la mermelada de naranja y el refresco de naranja.

¿Por qué la "mermelada de naranja" no activa la política de naranjas?

Supongamos que otro usuario busca "mermelada de naranja". El plano de control envuelve el texto y se filtra: "START orange marmalade END". El patrón de la política de naranjas es match_phrase: "START oranges END". La política de naranjas no coincide y, por lo tanto, la política no se aplica, y los resultados no están limitados a la categoría Frutas.

Este es el propósito de los marcadores de límite START y END. Sin ellos, una política que coincida con la palabra "naranjas" podría activarse accidentalmente en una búsqueda como "mermelada de naranja". Al envolver el texto de búsqueda del usuario con START y END e incluir esos marcadores en el patrón de la política, nos aseguramos de que la política solo se activa cuando “naranjas” sea el texto de búsqueda completo, sin otras palabras. Esto coincide con la intención tanto de los compradores como de los comerciantes.

Una segunda política: "aceite de oliva" en el campo derivado.

No todas las políticas necesitan una coincidencia exacta de texto. La política de “aceite de oliva” coincide con un campo derivado, por lo que se aplica independientemente de variaciones menores en la forma de las palabras:

El patrón de esta política coincide con query.stemmed en lugar de query. Cuando llega la cadena de búsqueda del usuario, se almacena tanto en un campo query (el texto exacto) como en un campo query.stemmed (analizado con un analizador de derivación que reduce las palabras a sus derivaciones, por lo que "aceitunas" y "aceituna" se reducen a la misma derivación, al igual que "aceites" y "aceite"). El patrón de la política se comprueba con la versión derivada del texto, por lo que se activa independientemente de las variaciones menores en la forma de la palabra.

Los marcadores de límites START y END también funcionan en el campo derivado, lo que garantiza que esta política solo se activa cuando "aceite de oliva" es el texto de búsqueda completo, no cuando aparece como parte de un texto más largo.

El resto de esta publicación cubre los detalles de implementación que hacen que esto esté listo para producción: la asignación de índices que admite ambos modos de coincidencia, cómo los resaltados impulsan la eliminación de frases y el seguimiento de las frases procesadas, y cómo múltiples políticas conflictivas se combinan en un único plan de ejecución.

El mapping del índice de políticas

El índice de políticas necesita un campo percolador para almacenar patrones de búsqueda y un campo de texto que refleje la estructura de la cadena de búsqueda entrante con la que el percolador coincidirá. El mapping a continuación se simplifica para mayor claridad. Un despliegue en producción es más complejo, ya que utiliza analizadores personalizados para manejar marcadores de límite, la coincidencia de patrones variables (por ejemplo, reconocer que "menos de $4" contiene un valor de moneda) y otros tipos de análisis.

El índice se llama policies porque cada documento representa una política regida completa como se define en la Parte 2. Esto incluye criterios de coincidencia, acción, prioridad y metadato. Los campos rule_type y rule_args contienen el componente de acción de la política, que incluyen las instrucciones que utilizará el plano de control para crear la búsqueda para su ejecución en el catálogo de productos.

El campo query es el texto con el que coincide el percolador. Tiene dos variantes: una versión exacta y una versión derivada. Cuando llega el texto de búsqueda del usuario, se coloca en este campo del índice temporal en memoria. Las políticas que coinciden en query ven el texto exacto; las políticas que coinciden en query.stemmed ven la versión derivada.

Filtrar con resaltados, análisis y clasificación

Los ejemplos simples anteriores mostraron solicitudes mínimas de percolación. En la práctica, el plano de control añade resaltado, filtra políticas deshabilitadas y clasifica por prioridad:

La configuración de resaltado usa "query" como clave de campo con "query.stemmed" en matched_fields. Esto le indica al resaltador unificado de Elasticsearch que devuelva resaltados en el campo original query, pero que también considere las coincidencias del subcampo query.stemmed al determinar qué tokens resaltar. Esto es lo que permite que una política que coincide en el campo derivado siga produciendo resaltados precisos en el texto original, que el plano de control necesita para la eliminación de frases y el seguimiento de frases procesadas.

El filtro enabled: true garantiza que se omitan las políticas deshabilitadas. La sort como prioridad asegura que las políticas de mayor prioridad se devuelvan primero, para que el plano de control pueda procesarlas en el orden correcto para las transformaciones en cascada. El campo highlight es la adición más importante; nos indica exactamente qué palabras en el texto de búsqueda del usuario activaron cada coincidencia.

La respuesta a una búsqueda de "aceite de oliva" podría ser la siguiente:

Por qué los resaltados son importantes

Observen el punto destacado en la respuesta: "<em>START olive oil END</em>". Elasticsearch nos dice exactamente qué palabras en el texto de búsqueda del usuario hicieron que la política coincidiera. Esto no es solo superficial. El metadato destacado impulsa dos comportamientos posteriores críticos:

Eliminación de frases. Algunas políticas necesitan eliminar el texto coincidente de la cadena de búsqueda antes de crear la búsqueda del catálogo de productos. Por ejemplo, una política que coincide con "barato" elimina esa palabra y la convierte en un filtro de precio en su lugar. El resaltado identifica exactamente con qué tramo del texto de búsqueda coincidía la política, para que el sistema sepa qué eliminar.

Seguimiento de frases procesadas. Como se describe en la Parte 3, cuando varias políticas coinciden con el mismo texto de búsqueda, una política de mayor prioridad podría eliminar palabras con las que también coincidía una política de menor prioridad. Al comparar el resaltado de cada política con el texto de búsqueda actual (en evolución), el sistema puede detectar que se ha procesado una frase y omitir la política de menor prioridad. Esto evita el doble procesamiento y asegura un comportamiento determinista.

Puedes obtener más información sobre cómo funciona el resaltado en este artículo.

De la percolación al plan de ejecución

El percolador devuelve un conjunto de políticas coincidentes. Pero tal como se describió en la Parte 3, la búsqueda es solo la mitad de la historia. La otra mitad consiste en integrar esas coincidencias en un plan de ejecución coherente. Así es como se ve para una búsqueda concreta.

Ejemplo trabajado: "chocolate barato" durante una campaña de Navidad

Imaginemos que el sistema tiene dos políticas activas: la política de "Chocolate barato" (prioridad 210) y la política de "Chocolates navideños" (prioridad 300), ambas descritas en detalle en la Parte 3.

Paso 1: Filtra. El usuario busca "chocolate barato". El plano de control envuelve el texto de búsqueda como "START cheap chocolate END" y lo envía al percolador. Dos políticas coinciden: El patrón de la política de "Chocolate barato" coincide con la frase "chocolate barato"; y el patrón de la política de "Chocolates navideños" coincide con "chocolate" a través del campo derivado.

Paso 2: ordena por prioridad. El percolador devuelve ambas políticas, ordenadas por prioridad en orden descendente. La política de “chocolates de Navidad” (300) se procesa primero, seguida de la política de “chocolate barato” (210).

Paso 3: aplica la transformación en cascada. Este es el modelo initial state → [Policy A] → state' → [Policy B] → state'' → execution plan de la Parte 3.

La política de “chocolates de Navidad” (prioridad 300) se aplica primero:

• Agrega un filtro de categoría estricto: "comidas y bebidas de Navidad", "dulces de Navidad".

• Agrega un filtro de precio: menos de $7.

• Añade un impulso suave de categoría: "calendarios de Adviento" (3x).

La política de “chocolate barato” (prioridad 210) se aplica a continuación contra el estado modificado:

• Se intenta agregar un filtro de categoría estricto: "Chocolates", "Chocolates con leche"; pero la política navideña ya estableció este campo con on_conflict: override, por lo que se eliminan las categorías de chocolate barato.

• Se intenta agregar un filtro de precio: $2, la política de Navidad estableció on_conflict: restrict para el precio, y $2 es más restrictivo que $7, por lo que $2 gana.

• Elimina "barato" del texto de búsqueda.

Paso 4: crea la búsqueda en Elasticsearch. El plano de control organiza el plan de ejecución en una sola búsqueda de Elasticsearch sobre el catálogo de productos:

El texto de búsqueda original era "chocolate barato". La búsqueda que llega al catálogo de productos es un plan de recuperación regulado y consciente de la intención: la palabra "barato" ha sido procesada y convertida en una restricción de precio, los resultados están restringidos a categorías estacionales de Navidad, los productos de calendario de Adviento reciben un impulso en el ranking y el techo de precio refleja el valor más restrictivo de la política de menor prioridad. Cada transformación es determinista, rastreable y explicable.

Para una visión general de cómo estos multiplicadores interactúan con el puntaje base de BM25, ver el punto 8:45 en el video relacionado de PRISM, donde hablamos brevemente de los aumentos multiplicativos.

¿Por qué esto funciona a escala?

El percolador es eficiente para este caso de uso debido a la asimetría: un sistema de comercio electrónico empresarial puede tener millones de productos, pero solo cientos o miles de políticas de gobernanza. El percolador está comprobando un texto de búsqueda entrante contra ese conjunto de patrones de políticas almacenados, no escaneando el catálogo completo de productos. El costo es proporcional a la cantidad de políticas y Elasticsearch aplica optimizaciones internas (indexación de términos a partir de patrones de búsqueda almacenados, con evaluación de cortocircuito de la lógica booleana) para mantener la coincidencia rápida.

Agregar una nueva política es simplemente indexar un nuevo documento. Deshabilitar una es una actualización de campo. Sin cambios de código, sin despliegues, sin reinicios.

De búsqueda a recuperación regulada

El percolador ofrece la primitiva de retrocompatibilidad rápida que hace que la arquitectura del plano de control de la Parte 3 sea práctica a gran escala. Las políticas son datos que se almacenan e indexan, y se comparan eficientemente con los textos de búsqueda entrantes. El plano de control compone políticas coincidentes en un plan de ejecución regulado a través de la transformación en cascada y la resolución de conflictos por campo descrita en la Parte 3. Y el motor de recuperación ejecuta el plan de ejecución definido sobre el catálogo de productos.

El resultado es un sistema en el que un vendedor puede crear una nueva política sin modificar el código de la aplicación, probarla con búsqueda representativas, implementarla en producción y observar el efecto de inmediato. El percolador agiliza la búsqueda de políticas; el plano de control hace que la composición de políticas sea determinista; y el flujo de trabajo regulado asegura la seguridad de todo el proceso.

Lo que se viene

La próxima publicación en esta serie extiende el plano de control gestionado a un nuevo territorio. Introduce una arquitectura de búsqueda de varios niveles, que explica cómo organizar una recuperación estricta, flexible y semántica mientras se mantiene la paginación y las facetas estables.

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

El plano de control basado en percolador descrito en esta publicación, desde los mapeos de índices y marcadores de límite hasta el seguimiento de frases basado en resaltados y la composición de políticas en cascada, fue desarrollado por Elastic Services Engineering como parte de nuestros aceleradores de búsqueda de comercio electrónico repetibles. Cada ejemplo de búsqueda y estructura de políticas que aparece aquí proviene de un sistema funcional validado en relación 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 puede acercarte a tu objetivo más rápido. Ponte en contacto con Elastic Professional Services.

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

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:

Tipo de campo

Estrategias disponibles

Predeterminado

Campos de negación (__not, __match__not)

anular, fusionar

anular

Campos de rango numérico (__max, __mín, __gt, __lt)

restringir, anular, soft_boost

restringir

Todos los demás campos (palabra clave, texto)

soft_boost, anular, fusionar

soft_boost

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.

La recuperación léxica (coincidencia de texto), la recuperación semántica (coincidencia de conceptos) ni la recuperación híbrida (combinación de señales léxicas y semánticas) resuelven estos problemas por sí solas. La recuperación léxica puede arrojar cualquier resultado que contenga la palabra “naranjas”, mientras que la recuperación semántica pura en una consulta de alta intención como “naranjas” puede ampliarse hacia elementos relacionados como limones o toronjas. La recuperación híbrida combina estas señales léxicas y semánticas, pero aún no determina si esta consulta debe considerarse navegacional, qué restricciones deben aplicarse o qué políticas comerciales deben implementarse. La brecha no es la tecnología de recuperación en sí; es la ausencia de una capa de gobernanza que entienda de qué tipo de consulta se trata y qué restricciones deben implementarse antes de que comience la recuperación.

En este blog, abordamos la gobernanza de la búsqueda en el comercio electrónico, su relevancia y cómo garantizar una recuperación predecible y precisa con una capa de control.

Qué significa la gobernanza en la búsqueda en el comercio electrónico

Gobernanza, en este contexto, significa introducir una capa de decisión entre la consulta del usuario y el motor de recuperación. Esta capa realiza las siguientes funciones:

• Clasifica la intención de la consulta: ¿se trata de navegación ("naranjas") o descubrimiento ("regalo para el abuelo")?

• Aplica restricciones comerciales: ¿qué límites de categoría, reglas de elegibilidad, restricciones de disponibilidad o políticas de comercialización se aplican?

• Apunta hacia la estrategia adecuada: ¿debería usar recuperación léxica, recuperación semántica o híbrida?

Una capa de gobernanza determina qué método de recuperación debe emplearse para cada consulta, qué restricciones deben aplicarse y qué políticas empresariales deben implementarse antes de que comience la recuperación. Es importante no confundir la gobernanza con la recuperación híbrida: la recuperación híbrida es una estrategia que combina señales léxicas y semánticas, mientras que la gobernanza es la capa de decisión previa que determina si deben usarse señales léxicas, semánticas o híbridas.

Situación actual: la implementación "espagueti" de la capa de aplicación

Hoy en día, muchos minoristas intentan resolver esto agregando lógica directamente en la capa de aplicación. A menudo resulta en código espagueti, es decir, miles de líneas de afirmaciones “si-entonces” codificadas de forma rígida, regex y plantillas de búsqueda complejas.

Este enfoque puede proporcionar los resultados de búsqueda deseados como se muestra arriba; sin embargo, crea una fricción operativa significativa:

• Dependencia de ingeniería: los usuarios empresariales y los comercializadores no pueden modificar el comportamiento de búsqueda sin tickets de ingeniería y largos ciclos de despliegue que a menudo abarcan varias semanas.

• Fragmentación: la lógica de búsqueda queda dispersa entre el código de la aplicación y las plantillas de búsqueda, y es difícil de explicar o auditar, lo que vuelve su evolución arriesgada.

Incluso cuando los equipos reconocen la necesidad de enrutamiento, el debate a menudo se centra en la pregunta equivocada: qué método de recuperación elegir.

La falsa elección: léxico vs. semántico vs. híbrido

Los equipos de búsqueda suelen enmarcar el desafío como una elección estratégica de recuperación: léxico/BM25 frente a semántico/vectores frente a híbrido. Ese encuadre es comprensible (los métodos de recuperación importan), pero pasa por alto el modo de fallo más común en despliegues reales: usar un único enfoque de recuperación para todas las consultas dará resultados subóptimos.

La búsqueda comercial es una mezcla de intenciones fundamentalmente diferentes:

• Navegación determinista y de alta intención ("naranjas", "leche", "chocolate sin maní", "aceite de oliva barato").

• Descubrimiento exploratorio ("chaqueta para hacer senderismo en las montañas", "regalo para una niña o niño de 12 años a quien le gusta la robótica").

• Restricciones operativas (disponibilidad, tamaño, precio, color).

• Merchandising y campañas (impulsar, relegar, campañas estacionales).

Cuando el sistema enruta todo esto a través de la misma estrategia de recuperación, los resultados a menudo son sistemáticamente incorrectos de manera predecible porque el modelo operativo carece de gobernanza. Cuando los equipos no se dan cuenta de que esto es una falla en la gobernanza, responden con la única herramienta que tienen: ajustar más el sistema.

Por qué “afinar la relevancia” puede volverse algo cíclico

Sin una capa de enrutamiento, la "relevancia" suele convertirse en una lista de pendientes interminable:

• ¿Por qué esta búsqueda muestra accesorios por encima del producto núcleo?

• ¿Por qué esta búsqueda principal de repente comenzó a mostrar elementos relacionados?

• ¿Por qué cambiaron los resultados después de que agregamos sinónimos, ajustamos los analizadores o habilitamos el híbrido?

• ¿Por qué el equipo de negocios necesita un lanzamiento de ingeniería para arreglar una consulta única?

Los equipos responden con más ajustes: más sinónimos, más mejoras, más experimentos de reordenamiento, más excepciones en el código de la aplicación. Esto puede funcionar por un tiempo, pero a menudo produce un comportamiento frágil porque el sistema aún carece de una capa de decisión explícita para determinar el tipo de consulta y aplicar las restricciones adecuadas antes de la recuperación.

La anatomía de la intención del comercio electrónico: cabeza y cola

En esta sección, usamos “cabeza” y “cola” como una notación práctica para patrones comunes de búsqueda navegacional y exploratoria en el comercio electrónico. En el mundo real, muchas búsquedas contienen aspectos de ambos:

Consultas de cabeza (intención determinista)

Estas son consultas directas y de navegación en las que el usuario sabe exactamente lo que quiere:

• Intención de un solo artículo ("naranjas", "leche", "pan").

• Marcas exactas o familias de productos ("iPhone 15 Pro", "Coca Light").

• Referencias, números de modelo, tallas ("ABC123", "air max 270").

Para estas consultas, la recuperación léxica puede ocuparse de la correspondencia de tokens (palabras coincidentes), pero la empresa también espera respetar las restricciones, arrojar clasificaciones predecibles y tener resultados controlables. Un comerciante necesita asegurarse de que una consulta se resuelva dentro de los límites correctos de la categoría, respete la elegibilidad y muestre prioridades específicas del negocio.

Se necesita una estructura de gobernanza para garantizar el cumplimiento de la resolución prevista. Por ejemplo, las “naranjas” deben mapearse a la categoría de productos, no a jugo de naranja, mermelada de naranja o soda de naranja.

Consultas de cola (descubrimiento exploratorio)

Estas son búsquedas descriptivas y ricas en intención donde los compradores están explorando:

• "Regalo para el abuelo que tiene debilidad por lo dulce"

• "Chaqueta para senderismo en la montaña"

• "Zapatos para estar de pie todo el día"

La recuperación léxica a menudo tiene dificultades en este punto. La búsqueda semántica destaca porque puede conectar el concepto de la consulta con el producto, incluso cuando las palabras no coinciden. Pero la recuperación semántica por sí sola no suele ser suficiente. Las consultas reales a menudo requieren que se apliquen restricciones, independientemente del método de recuperación que se utilice.

Las restricciones son ortogonales al método de recuperación

Aplicar restricciones a la recuperación semántica no significa que sea una búsqueda híbrida. Son conceptos ortogonales. Las restricciones, como los filtros y las mejoras (boosts) en Elasticsearch, se pueden aplicar a cualquier recuperación léxica, semántica o híbrida. El desafío es decidir cómo interpretar la consulta, qué restricciones se deben aplicar y qué estrategia de recuperación se debe usar.

A continuación se muestran algunos ejemplos de consultas que combinan la recuperación con restricciones rígidas:

• Naranjas: recuperación léxica para “naranjas” más una restricción de categoría, como “frutas” o “productos”, eliminando mermelada de naranja, jugo de naranja y soda de naranja.

• Frutas ricas en vitamina C por menos de $4: búsqueda semántica basada en la intención nutricional, además de filtros que limitan los resultados a la categoría de frutas y a productos por menos de $4.

• Zapatos cómodos para el trabajo: búsqueda semántica basada en la intención contextual, además de una restricción de categoría que limita los resultados a los zapatos.

Estas consultas no se pueden manejar con un solo enfoque:

• La recuperación léxica pura a menudo es insuficiente en este caso porque frases como “alto contenido de vitamina C” o “cómodo” pueden no existir como atributos limpios y estructurados. Puede que sea necesario inferirlos a partir de descripciones de productos, reseñas o especificaciones.

• La recuperación semántica pura tampoco es suficiente porque, sin restricciones explícitas, una consulta como “frutas con alto contenido de vitamina C” podría ampliarse hacia suplementos vitamínicos, bebidas con sabor a fruta o vegetales con alto contenido de vitaminas fuera de la categoría y el rango de precios previstos.

Una capa de gobernanza determina si una consulta necesita recuperación léxica, comprensión semántica, aplicación de restricciones o alguna combinación de estas. Sin esta capa, los equipos de comercio electrónico pueden caer en lo siguiente:

• Restricción excesiva: uso de recuperación léxica para solicitudes semánticas (por ejemplo, "regalo para el abuelo").

• Restricción insuficiente: emplear consultas semánticas para consultas de cabeza con alta intención (por ejemplo, "naranjas").

El desafío de la gobernanza es construir un sistema que pueda tomar la decisión correcta para cada clase de consulta.

Qué sucede sin gobernanza

El modo de falla más común es sencillo: los equipos toman la consulta del usuario sin procesar y la pasan directamente a una única estrategia de recuperación (léxica, semántica o híbrida), sin una capa de gobernanza intermedia.

La búsqueda léxica no da el resultado esperado

Cuando un usuario busca “naranjas”, una estrategia de recuperación léxica puede devolver cualquier cosa que contenga ese token: jugo de naranja, mermelada de naranja o soda de naranja. El sistema hizo coincidir el término correctamente, pero sin gobernanza es posible que no resuelva el contexto de compra previsto (la fruta).

La recuperación semántica se amplía más allá de las limitaciones previstas

Cuando un usuario busca “naranjas”, un sistema semántico puede recuperar elementos conceptualmente relacionados a través de conceptos de productos cercanos. El sistema puede comprender correctamente el dominio más amplio (fruta o productos), pero sin gobernanza explícita aún puede ampliarse más allá de la restricción intencionada del usuario (específicamente naranjas).

La brecha es la gobernanza

Lo que se requiere es una capa de decisión previa que determine la intención de la consulta y aplique las restricciones adecuadas antes de que comience la recuperación. Esto soluciona problemas como los siguientes:

• Elementos similares o relacionados que aparecen junto a lo que el usuario realmente quería.

• Límites difusos de categorías ("bebidas" en vez de "frutas").

• Incapacidad para implementar mejoras o campañas estacionales.

• Resultados impredecibles e inexplicables.

Comprensión de intenciones y enrutamiento: el plano de control necesario

Un sistema de búsqueda gestionada incorpora un plano de control ligero antes de la recuperación (antes de ejecutar una consulta en Elasticsearch). El control se explicará en detalle en las partes 3 y 4 de esta serie de blogs; por ahora, solo abarcaremos lo que puede hacer pero no cómo funciona:

Un plano de control puede detectar la intención, aplicar políticas comerciales y garantizar la estrategia de recuperación apropiada de la siguiente manera:

1. Detectar señales de intención

• ¿Es probable que esta búsqueda sea de navegación en vez de descubrimiento?

• ¿Es una búsqueda principal conocida (leche, pan, bananas)?

• Existe una interpretación conocida de producto, marca o categoría (por ejemplo, “naranjas” debería resolverse como fruta).

• ¿La consulta tiene un patrón tipo SKU?

• ¿La consulta se enmarca dentro de una campaña activa o una política estacional (por ejemplo, durante la Navidad, mejorar los resultados relacionados con el pavo)?

• ¿La consulta implica restricciones (categoría, atributos, exclusiones, precio, tamaño o color)?

2. Aplicar políticas empresariales y de gobernanza

• Primero aplica restricciones deterministas (categoría, atributo, negación, disponibilidad).

• Aplicar políticas activas de merchandising (mejorar/enterrar/fijar/anular).

• Resuelve los conflictos con reglas de precedencia (por ejemplo, anulaciones de campaña frente a políticas globales).

3. Dirige a la estrategia de recuperación adecuada

• Léxico (rápido, determinista) para consultas de navegación o de alta intención.

• Recuperación semántica para búsquedas de descubrimiento real.

• Híbrido en el que la combinación de señales léxicas y semánticas aporta valor añadido dentro de unos límites empresariales explícitos.

En la práctica, la salida del plano de control no es simplemente “usar híbrido” o “usar semántico”. Es un plan de recuperación regulado: una interpretación de la intención del comprador, las restricciones y políticas que deben aplicar, y la estrategia de recuperación que debe ejecutar. Unos pocos ejemplos sencillos lo demuestran:

Consulta de comprador

Interpretación regulada

Ejemplo de plan de recuperación

“chocolate sin maní”

Consulta orientada al producto con una restricción de exclusión estricta

Recuperación léxica para chocolate más un filtro de exclusión para productos que contienen maní

“aceite de oliva barato”

Búsqueda de producto o categoría con restricción de precio

Recuperación léxica para aceite de oliva más un filtro de precio limitado al umbral del minorista para ser económico

“Fruta con alto contenido de vitamina C por menos de $4”

Consulta de descubrimiento que requiere comprensión semántica y restricciones estrictas

Búsqueda semántica basada en la intención nutricional, limitada a la categoría de frutas y filtrada a productos con un precio inferior a 4 dólares

Un plano de control selecciona la política y la estrategia de recuperación correctas para cada búsqueda de forma consistente, predecible y a escala. Esto hace que los métodos de recuperación avanzados sean más predecibles en producción porque las restricciones alineadas con la intención se aplican primero y las decisiones de enrutamiento son explícitas en lugar de implícitas.

Cómo esto se relaciona con otros enfoques

Algunos equipos usan modelos de incrustación mejorados para captar mejor la semántica de los productos, lo que puede mejorar de forma considerable la calidad de la búsqueda semántica. Otros utilizan enfoques de reclasificación, como Learning To Rank (LTR), para optimizar el orden de los resultados basado en la participación o señales de negocio después de la recuperación. Ambos son valiosos y a menudo complementarios. Las incrustaciones superiores mejoran la coincidencia de similitudes. La reclasificación mejora el ordenamiento entre los candidatos recuperados.

La gobernanza aborda un aspecto diferente del problema: se sitúa en una etapa previa a la recuperación. Decide qué estrategia de recuperación utilizar (por ejemplo, léxica, semántica o híbrida), qué restricciones deterministas se requieren y qué consultas deben combinar varias políticas de negocio.

Qué aporta un plano de control gestionado

Una vez que se establece una capa de gobernanza, el modelo operativo cambia de forma rotunda. Las consultas críticas para los ingresos se vuelven predecibles. Los equipos de negocio pueden actualizar el comportamiento de búsqueda sin esperar los ciclos de lanzamiento de ingeniería. Y los métodos de recuperación avanzados (como los semánticos y los híbridos) pueden adoptarse de forma gradual, con mecanismos de enrutamiento y controles de seguridad, en vez de como un interruptor global de encendido o apagado.

La siguiente publicación de esta serie explora cómo se ve ese modelo operativo en la práctica y por qué puede ser tan importante como la tecnología de recuperación subyacente.

Si un comerciante tiene que abrir un ticket de Jira y esperar un despliegue para corregir una búsqueda crítica para los ingresos, el cuello de botella no es el motor; es el modelo operativo. La búsqueda moderna de comercio electrónico necesita una manera de traducir la intención comercial en un comportamiento de búsqueda controlado y auditable de manera rápida y segura, sin dejar de usar recuperación avanzada cuando aporta un valor medible.

Lo que se viene

Los patrones explorados en esta serie operan río arriba de la recuperación: traduciendo la intención del negocio en la estrategia de búsqueda correcta antes de que comience la generación de la búsqueda. En la siguiente publicación, pasamos del problema técnico al operativo: qué ocurre cuando los equipos de negocio pueden cambiar el comportamiento de búsqueda sin un despliegue de ingeniería, y por qué la gobernanza hace que eso sea seguro.

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

Los cuellos de botella de ingeniería, la lógica frágil de la capa de aplicación y los resultados de búsqueda impredecibles son problemas que Elastic Services puede ayudarte a resolver en los proyectos de servicios de comercio electrónico empresarial. La arquitectura del plano de control gobernado que se describe en esta serie fue desarrollada por Elastic Services Engineering.

Si tu equipo está dedicando recursos de ingeniería a convertir las solicitudes de merchandising en cambios de código, o si la lista de tareas pendientes relacionadas con la relevancia de las búsquedas parece no reducirse nunca, podemos ayudarte a evaluar tu arquitectura actual y a trazar un plan para lograr un sistema de búsqueda controlado y editable por el equipo de negocios. Ponte en contacto con Elastic Services.

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