Esta publicación es un análisis técnico detallado de la implementación en Elasticsearch de la arquitectura del plano de control descrita en la Parte 3, y muestra cómo crearla utilizando el percolador de Elasticsearch. Describe los patrones utilizados para implementar un motor de políticas determinista y regulado en producción.
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: restrictpara 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.
Contenido relacionado
11 de mayo de 2026
Personalización de la búsqueda en comercio electrónico: integración del historial de compras y cohortes de usuarios
Aprende a crear una experiencia de búsqueda personalizada en Elasticsearch sin infringir la gobernanza. En esta publicación se explica cómo destacar los productos que un comprador ha adquirido previamente y cómo activar políticas específicas de cohortes basadas en perfiles de usuario.
1 de mayo de 2026
Creación de un plano de control para gestionar las búsquedas en el comercio electrónico
Cómo construir un plano de control gobernado para el comercio electrónico que integre políticas de búsqueda conflictivas en un solo plan de ejecución (sin cambios de código).
24 de abril de 2026
Reindexación de flujos de datos debido a conflictos de mapping
Descubre cómo solucionar los conflictos de mapeo de Elasticsearch reindexando los flujos de datos. Este blog explica el proceso de reindexación y la verificación del mapeo correcto.
9 de abril de 2026
Por qué la búsqueda en el comercio electrónico necesita gobernanza
Conoce por qué la búsqueda de ecommerce queda corta sin gobernanza, y cómo una capa de control garantiza resultados predecibles e impulsados por la intención, a la vez que mejora la recuperación.
14 de enero de 2026
Mayor rendimiento y menor latencia: Elastic Cloud Serverless en AWS recibe un aumento significativo del rendimiento
Hemos actualizado la infraestructura de AWS para Elasticsearch Serverless con hardware más nuevo y rápido. Descubre cómo este aumento masivo del rendimiento ofrece consultas más rápidas, mejor escalado y menores costos.