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.

El contenido de este blog se ha elaborado y verificado utilizando las versiones 9.2.8 y 8.19.14 de Elastic, junto con las versiones 2.3.0 y 1.2.0 de Filestream Integration.

Nota importante: Dependiendo de tu entorno, algunos pasos pueden requerir modificaciones específicas. Además, ten en cuenta que las plantillas dinámicas se eliminaron de la plantilla del componente @package a partir de la versión 2.3.3 de Filestream Integration.

Antes de comenzar el proceso de reindexación, es importante considerar la asignación actual de almacenamiento en tu entorno. Los pasos descritos a continuación implican crear una copia del índice de respaldo existente, que residirá temporalmente en el nivel de datos caliente.

Niveles de datos de Elasticsearch

• Caliente: el nivel caliente es el punto de entrada de Elasticsearch para los datos temporales, donde se almacenan los datos más recientes y buscados con frecuencia. Los nodos de nivel caliente requieren lecturas y escrituras rápidas, lo que necesita más recursos y almacenamiento más rápido (SSD). Este nivel es obligatorio y los nuevos índices de flujos de datos se asignan automáticamente aquí.

• Tibio: los Datos temporales pueden pasar al nivel tibio una vez que se consultan con menos frecuencia que los datos indexados recientemente en el nivel caliente. El nivel tibio suele contener datos de las últimas semanas. Las actualizaciones siguen estando permitidas, pero probablemente sean poco frecuentes. Los nodos en el nivel tibio generalmente no necesitan ser tan rápidos como los del nivel caliente. Para la resiliencia, los índices en el nivel tibio deben configurarse para usar una o más réplicas.

• Frío: los datos que son de búsqueda poco frecuente pueden pasar del nivel tibio al frío. El nivel frío, aunque sigue permitiendo realizar búsquedas, prioriza los costos de almacenamiento más bajos frente a la velocidad de búsqueda. Alternativamente, el nivel frío puede almacenar índices regulares con réplicas en lugar de snapshots buscables, lo que permite el uso de hardware menos costoso para datos antiguos sin reducir los requisitos de espacio en disco en comparación con el nivel tibio.

• Congelado: los datos que se consultan con poca frecuencia o que ya no se consultan se mueven del nivel frío al congelado para su ciclo de vida restante. Este nivel utiliza un repositorio de snapshot e índices parcialmente montados para almacenar y cargar datos, lo que reduce el almacenamiento local y los costos al tiempo que permite la búsqueda. Las búsquedas en el nivel congelado suelen ser más lentas que en el nivel frío, ya que es posible que Elasticsearch tenga que recuperar los datos congelados del repositorio de snapshot. Recomendamos nodos de nivel congelado dedicados.

Requisitos previos: determinar qué campos presentan conflictos

Para determinar qué campos tienen conflictos de mapping, navega a Stack Management -> Data Views -> logs-* (usar la vista de datos logs-* es la jerarquía más alta de datos presente con el prefijo logs-). Si hay algún conflicto, habrá un cuadro amarillo que lo indique. Puedes hacer clic en Ver conflictos o, en el cuadro de tipo de campo junto al cuadro de búsqueda , seleccionar conflicto.

Al hacer clic en el botón amarillo Conflicto, se mostrará qué índices están asociados con qué tipos de mapping.

Esta situación (donde el campo se mapea como un keyword y un long) generalmente ocurre porque los datos se ingirieron antes de que se definiera un tipo de mapping específico en la plantilla de componente para el flujo de datos relevante. En esos casos, Elasticsearch intenta configurar el mapping basándose en sus plantillas dinámicas.

Para determinar qué mapeo es apropiado para el campo y si el campo es un campo ECS, se necesita verificación con referencia de campo ECS. Si el campo en cuestión no es un campo ECS, hay que revisar su valor para determinar el mapeo correcto.

Si un campo, como log.offset en este ejemplo, no está documentado en el ECS, los siguientes pasos son investigar el valor del campo, determinar qué tipo de mapping conflictivo tiene más índices de respaldo y examinar las plantillas componentes de los otros índices.

Por lo general, el tipo de mapeo asociado al mayor número de índices es el correcto, pero te recomendamos que compruebes el valor del campo en cuestión para asegurarte de ello. Para confirmar la validez de un tipo de mapeo (por ejemplo, long), también debes verificar que el valor del campo sea apropiado para ese tipo. Esta verificación se puede realizar empleando Discover para buscar el campo en cuestión. Revisar otros flujos de datos que contengan el mismo campo también puede servir como confirmación adicional.

Para revisar los valores presentes en el campo con el problema de mapping, vuelve al botón amarillo Conflictomencionado anteriormente, haz clic en el botón Conflicto, selecciona uno de los índices de respaldo y péguelo en una sesión de Discover . Tu declaración del lenguaje de búsqueda de Kibana (KQL) debería verse como la siguiente captura de pantalla, para incluir el delimitador de campo _index:.

Prepara la nueva plantilla de componente personalizado del índice de respaldo

Para abordar el conflicto de mapping en el flujo de datos, primero examina la plantilla de componentes correspondiente @package. Puedes encontrar esto en Stack Management -> Gestión de indexación> Plantilla de componentes. Busca el flujo de datos y selecciona el enlace @package correspondiente. Esta plantilla contiene mapping para el campo listos para usar y, aunque no es común tener una falta de coincidencia de mapping, es posible que se pase por alto el tipo más apropiado.

Revisa la plantilla para asegurarte de que contiene el anidamiento y el mapeo de campos necesarios para el campo en cuestión. Por ejemplo, si la plantilla indica incorrectamente log.offset como keyword, esta es la fuente del problema.

Importante: Debido a que no se recomienda modificar las plantillas @package/administradas, debes usar o crear una plantilla de componente @custom para corregir el tipo de mapeo (por ejemplo, para log.offset) para todos los datos futuros.

• No recomendamos modificar las plantillas @package/administradas, ya que cuando actualices la integración a una versión más reciente, cualquier cambio que realices en la plantilla @package se sobrescribirá. Por eso recomendamos usar las plantillas de @custom .

• Si un flujo de datos experimenta conflictos de mapeo, debes agregar cualquier anidamiento o mapeo de campos faltantes (ECS y no ECS) a la plantilla de componente @custom del flujo de datos. Crea esta plantilla si aún no existe y asegúrate de especificar el tipo de mapeo correcto para el campo.

• Si tienes varios conflictos en tu data view, aplica todos los mapping faltantes necesarios para el flujo de datos en simultáneo para que la reindexación se realice una vez en lugar de varias veces. Contar con entradas para el ingreso de datos correcto en la plantilla de componentes @custom plantilla de componentes garantizará que cualquier futura ingesta de datos siga la misma pauta de mapping.

Para crear la plantilla de componente @custom (o verificar que está en uso y rellenada), navega a Plantillas de Índice, escribe el nombre del flujo de datos en cuestión y haz clic en la plantilla de @custom correspondiente que esté usando el flujo de datos. Si la plantilla aún no está creada, aparecerá un cuadro amarillo que te permitirá crear la plantilla a través de la UI.

La captura de pantalla a continuación muestra la página siguiente una vez que se selecciona Crear plantilla de componente. Deja los valores predeterminados tal como están en la primera página y haz clic en Mappings o Siguiente hasta que llegues a la página Mappings.

Para establecer explícitamente el mapeo de un nuevo campo que entra o para actualizar un campo que tenga un conflicto de mapeo, cuando el flujo de datos se revierte debido a la configuración establecida en la política de ciclo de vida del índice, se necesita una entrada para el campo en el que existe el conflicto.

Lo siguiente establecerá el mapeo para el campo log.offset en la plantilla de componente @custom para el flujo de datos filestream. Repite los pasos para agregar cualquier campo personalizado o actualizar los campos necesarios del @package con los mapeos adecuados, si es necesario, para este set de datos. En este ejemplo, al establecer el desplazamiento en Long, el tipo de campo será Numeric y el tipo numérico será Long. Haz clic en Agregar campo y luego fuera del área para continuar.

Una vez que se hayan agregado todos los campos necesarios, haz clic para revisar y selecciona Crear plantilla de componente cuando esté listo. Todos los nuevos datos que se ingesten a partir de este paso tendrán log.offset configurado en long.

Creación de la nueva estructura de índice de respaldo

El nuevo índice de respaldo debe tener los mappings existentes de la plantilla de componentes del flujo de datos, así como la plantilla de componentes ECS ecs@mappings. La ecs@mappings plantilla de componente se aplica después del componente del flujo de datos como un recurso general para mappings adicionales que potencialmente no se capturaron en las plantillas de componentes anteriores.

Ve a la pestaña del navegador para ver el mapeo @package del flujo de datos. (Go to Stack Management -> Gestión de índices -> Plantilla de componentes -> logs-filestream.generic@package -> Gestionar -> Editar.) Una vez allí, haz clic en la sección Revisión, luego en Solicitar y finalmente en el botón Copiar a la derecha. El contenido JSON de la plantilla de componentes copiada garantizará que se conserven los mapeos y configuraciones de campo restantes mientras actualizamos el mapeo del campo log.offset. El JSON formará la estructura de respaldo para el índice de respaldo recién reindexado.

Importante: si no se copiara el JSON de la plantilla y se continuara trabajando con la reindexación, el log.offset conflicto se resolvería, pero habría nuevos conflictos con la integración, ya que no se mantendría la integridad de las asignaciones actuales, lo que crearía un doble trabajo para resolver el problema original.

Abre una segunda pestaña del navegador, navega a Herramientas de desarrollo y pega el contenido copiado. Ahora, para limpiar lo que se pegó:

Modificaciones a la solicitud

1. Nombre del índice: Reemplaza _component_template/logs-filestream.generic@package con el nombre del índice de respaldo que pretendes reindexar, añadiendo -1 al final. Por ejemplo, usa PUT <backing index to reindex>-1.

• El adjunto -1 indica una reindexación y no entrará en conflicto con la configuración predeterminada de rollover de ILM, que se basa en la fecha de creación del índice.

2. Configuración: Elimina la línea "template" (línea 3), así como la última llave de cierre para toda la carga útil JSON; la línea 3 debería comenzar con "settings": {.

• Sustituye el contenido interior de la sección de ajustes por "index.codec": "best_compression". Esta acción aplicará la mejor compresión de Elastic al índice al momento de la creación.

• Agrega "index.lifecycle.name": "logs", así como una línea para "index.lifecycle.rollover_alias": "".

  1. La "index.lifecycle.name": "logs" entrada aplicará la política de ILM de logs al nuevo índice de respaldo. Modifica el nombre de la política de ILM si no usas logs.

  2. El "index.lifecycle.rollover_alias": "" está en blanco, ya que este índice de respaldo no se rotará, pero la configuración es necesaria para evitar errores de rotación de ILM en la siguiente fase de ILM después de hot.

3. Estructura: la solicitud ahora debería incluir tanto una sección Settings como una sección Mappings. Dentro de "mappings": {deberías encontrar "dynamic_templates" y una sección de "properties" que contiene campos codificados y sus mappings.

4. Modificación de plantillas dinámicas: La sección actual de plantillas dinámicas contiene entradas para campos que pueden sobrescribirse cuando se agregan las ecs@mappings plantillas dinámicas a continuación, lo que provoca redundancia y líneas adicionales que no son necesarias.

• Elimina todas las secciones de "dynamic_templates" excepto la segunda sección llamada "_embedded_ecs-data_stream_to_constant": {.

• Repite el mismo proceso descrito anteriormente, ya que reúne los mappings dinámicos para la plantilla del componente @package , pero esta vez los mappings dinámicos para la plantilla del componente ecs@mappings.

  • Puede ser más fácil copiar todo el contenido de los mapeos de la interfaz de usuario para la plantilla del componente ecs@mappings, pegarlo en la sección Herramientas de desarrollo dynamic_templates que funcione y eliminar las líneas duplicadas e innecesarias cuando sea apropiado. Incluye estos contenidos de configuración de plantilla dinámica después de la entrada"_embedded_ecs-data_stream_to_constant": {. La sección dynamic_templates debería tener un aspecto muy similar al contenido de muestra a continuación en Dev Tools.

• Si dynamic_templates no se incluyen o eliminan por completo, otros campos (revisa la captura de pantalla abajo) tendrán doble mapeo: text y keyword frente a los mapeos adecuados, si la sección de dynamic_templates se dejó incluida. Lo que queda debería ser la sección "properties" debajo de "mappings". Esto también creará problemas en la Data view, ya que los campos se mapearán dos veces (si no se mapearon ya de esta manera) y provocará conflictos de mapeo adicionales.

5. Eliminación de metadatos: elimina la última sección etiquetada "_meta", así como la sección etiquetada "version", si está presente.

6. Formato: indentación automática de las secciones restantes y ajuste o eliminación de cualquier corchete innecesario que impida una ejecución exitosa.

7. Cambio de mapeo: Navega hasta la sección "properties" , encuentra "log"y luego localiza "offset" anidado debajo. Cambia el tipo de keyword a long, y elimina la entrada de línea (incluida la coma) etiquetada "ignore_above": 1024,. Si se agregaste más de una entrada a la plantilla de componente @custom creada anteriormente, inclúyela aquí.

Tu vista de consola de herramientas de desarrollo ahora debería ser similar al ejemplo que se proporciona a continuación.

Una vez que su consola se parezca al ejemplo (incluyendo cualquier campo personalizado adicional y valores personalizados específicos de su entorno), ejecute el comando para crear la estructura básica del nuevo índice de respaldo, haciendo una pausa para resolver cualquier error que surja.

Comenzar el proceso de reindexación

Con el shell del nuevo índice de respaldo creado correctamente, el siguiente paso es reindexar y resolver los conflictos de mapping.

Importante: si el índice de respaldo que presenta el conflicto de mapping es el índice más reciente y es el índice de escritura actual (por ejemplo, el número final del índice de respaldo es -000001), el flujo de datos debe reiniciarse. Es necesario reiniciar el flujo de datos, ya que el índice de escritura actual, al que se le están introduciendo documentos, es un índice de respaldo activo y no se puede modificar.

Con el mapping de campo correcto ahora aplicado al índice de escritura más nuevo a través de la plantilla de componente @custom creada anteriormente, todos los documentos nuevos reflejarán este cambio.

Esto se realiza ejecutando lo siguiente:

Por ejemplo:

La reindexación implica copiar los datos de un índice de respaldo existente a uno nuevo dentro de la misma convención de nomenclatura, generalmente para aplicar los cambios necesarios. Estas modificaciones podrían incluir actualizaciones de una plantilla de componente o la incorporación de un nuevo pipeline de ingesta para procesar los datos.

A continuación, los datos se copiarán desde el índice de respaldo que tiene los mappings incorrectos a un nuevo índice de respaldo. El índice de respaldo original se ha desplazado, lo que significa que no se pueden agregar nuevos documentos. El nuevo índice de respaldo seguirá la misma convención de nombres, que preserva la visibilidad e integridad de los datos al aplicar la política ILM correcta, pero incluirá un sufijo -1 para indicar que fue reindexado.

Ajusta los nombres de los índices según sea necesario y pega el siguiente código en la consola. Al incluir wait_for_completion=false, puedes seguir el progreso de la copia de documentos, lo que ayuda a estimar el tiempo restante de reindexación. Sin esta configuración, no puedes rastrear el estado con el comando GET _tasks a continuación y solo podrás verificar el recuento de documentos en el índice de respaldo más nuevo con GET <backing index name>-1/_count.

Importante: si surgen problemas durante el proceso de reindexación, no vuelvas a ejecutar el comando reindex; hacerlo reiniciará el proceso y creará registros duplicados en el índice que terminan en -1. Si es necesario reiniciar, primero elimina el índice que termina en -1, y luego ejecuta el comando PUT anterior para recrear la nueva shell de índice de respaldo.

Tras la ejecución, la respuesta incluirá un ID de tarea. Puedes monitorear el progreso de la reindexación usando este ID con el comando: GET _tasks/<task ID>.

La duración de la reindexación depende del volumen de datos del índice original. La finalización se puede rastrear si se busca "completed": true al ejecutar el comando GET, lo que debería producir una salida similar.

GET _tasks/<task ID>

Con el proceso de reindexación ya finalizado para el recuento de documentos, el siguiente paso es verificar que los mapeos para el nuevo índice de respaldo y el campo específico en cuestión sean correctas.

Por ejemplo:

Puedes verificar que el mapeo para log.offset es como se muestra a continuación. Para confirmar que otros campos tienen solo una entrada de mapeo (no ambas text y keyword), compáralos con un campo que no formaba parte de la sección de plantilla dinámica en el comando PUT anterior.

Si el índice de respaldo que se está reindexando tiene una gran cantidad de documentos, es útil verificar el estado de esos documentos que se están copiando al nuevo índice de respaldo; esto se puede hacer con los siguientes dos comandos de Herramientas de desarrollo para comparar los recuentos.

GET .ds-logs-filestream.generic-default-2026.04.14-000001/_count

GET .ds-logs-filestream.generic-default-2026.04.14-000001-1/_count

Una vez que se verifique que los recuentos coinciden y que los mapeos correctos están presentes, actualiza el flujo de datos para incluir el nuevo índice de respaldo, para prevenir un índice de respaldo huérfano en la administración de índices, donde la política de ILM nunca se ejecutará en el índice de respaldo.

• El retorno debería ser un reconocimiento de verdadero, si tiene éxito.

Verifica que el nuevo índice de respaldo se haya agregado con el siguiente comando, cerciorándote de que la ilm_policy sea correcta:

Verifique el estado de ILM del índice de respaldo a continuación con el siguiente comando:

• Es normal ver que el índice esté en caliente, ya que fue creado muy recientemente (revisa la línea 8 o 10).

Ejecuta lo siguiente para hacer la transición del índice de respaldo del nivel activo al siguiente nivel apropiado después de la fase caliente de la política de ILM para este flujo de datos. Los valores específicos para phase, action, y name en el current_step siguiente pueden referenciarse a partir de las líneas 11, 13 y 15, respectivamente, en la captura de pantalla proporcionada arriba.

El valor next_step indica la fase de ILM o el nivel de datos posterior al que el índice hará la transición.

Por ejemplo:

• No es necesario, pero como medida de seguridad, puedes ejecutar el comando _ilm/explain de nuevo para cerciorarte de que el índice de respaldo pasó a la siguiente fase y ya no está en caliente.

Una vez que se cumplan las siguientes condiciones, puedes eliminar de forma segura el índice de respaldo original que tenía conflictos de mapeo:

1. Se ha creado correctamente un nuevo índice de respaldo.

2. Los documentos se han trasladado al nuevo índice y la cantidad de documentos coincide.

3. Los mapeos se han corregido (tanto específicos del flujo de datos como ECS).

4. El flujo de datos incorpora el nuevo índice de respaldo.

5. La política de ILM se ha aplicado y ha movido el índice fuera de la fase caliente.

Importante: Como alternativa, antes de eliminar el índice original, puedes consultar la página Data Views. Selecciona logs-* y verifica que el índice de respaldo reindexado (que termina en -1) ahora aparece en la sección long. El índice de respaldo original debería seguir presente en keyword. Si el índice de respaldo reindexado no está en la sección long, vuelve atrás y revisa los pasos anteriores y realiza las correcciones necesarias.

Por ejemplo:

Luego de resolver los conflictos, vuelve a la página Data Views y selecciona logs-*. Si el conflicto estuviera relacionado únicamente con log.offset, ya no debería ver ningún conflicto listado. Si hubiera otros conflictos, el índice de respaldo original ya no debería aparecer en la lista de conflictos; en cambio, el nuevo índice de respaldo debería aparecer ahora en la sección long.

También puedes verificar en Discover que el campo log.offset ahora muestra los iconos correspondientes.

Continúe este proceso, repitiendo los pasos anteriores para cada índice de respaldo que tenga un conflicto de mapeo hasta que todos se resuelvan con éxito.

Referencias:

• Referencia de campo de ECS

• Reindexar documentos

Reflexiones finales

Si sigues los pasos de este blog, resolverás los conflictos de mapping y te asegurarás de que todos los datos nuevos estén correctamente mapeados. Esto se consigue vinculando las plantillas de componentes necesarias a tu fuente de datos. Este flujo de trabajo no solo resuelve los problemas inmediatos, sino que también establece un proceso seguro y repetible para gestionar los cambios en el esquema a medida que tus datos y requisitos evolucionan.

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.

Completamos una importante actualización de infraestructura para todos los proyectos de Elastic Cloud Serverless que funcionan en AWS, al migrar a hardware más nuevo y rápido. Este cambio se ha implementado automáticamente en todos los proyectos sin servidor. Ofrece mayor rendimiento y menor latencia para proyectos serverless de Elasticsearch, Elastic Observability y Elastic Security en AWS.

Beneficios clave de rendimiento para desarrolladores

La nueva infraestructura de hardware de AWS sustenta todo lo que haces con Elastic Cloud Serverless, lo que se traduce en beneficios tangibles para la velocidad y la capacidad de respuesta de tus aplicaciones.

Latencia de consulta reducida… rendimiento aumentado.

El hardware mejorado aumenta drásticamente la velocidad de los recursos informáticos, lo que significa que tus consultas de búsqueda se procesan más rápido que nunca.

• Búsqueda y búsqueda vectorial: ya sea que estés ejecutando búsquedas de texto tradicionales o empleando una búsqueda vectorial de vanguardia para tus aplicaciones de inteligencia artificial generativa y RAG, verás una marcada disminución en la latencia. La evaluación interna mostró una disminución promedio del 35% en la latencia de búsqueda.

• Indexación más rápida: Las tasas de ingesta de datos están optimizadas, lo que te permite indexar volúmenes masivos de datos y documentos complejos con mayor rendimiento. Esto es crucial para las aplicaciones que requieren visibilidad de datos casi en tiempo real. La evaluación comparativa interna mostró un aumento promedio del 26% en el rendimiento al indexar.

Rendimiento constante bajo carga

Elastic Cloud Serverless está diseñado para escalar dinámicamente en tiempo real y satisfacer la demanda, lo que minimiza la latencia, independientemente de tu carga de trabajo. Gracias a esta actualización de hardware, ahora el escalado es más eficaz y ofrece una mayor capacidad de respuesta.

• Manejar los picos con facilidad: ya sea que te enfrentes a un aumento repentino en el tráfico de usuarios o a una ingesta masiva de datos batch, la nueva infraestructura garantiza que tus recursos de búsqueda e indexación se escalen de manera más eficiente para mantener una latencia constantemente baja.

• Desacoplamiento optimizado de computación y almacenamiento: La arquitectura serverless separa computación y almacenamiento, lo que permite que las cargas de trabajo escalen de forma independiente para lograr un rendimiento óptimo y eficiencia de costos. El hardware más rápido mejora la capa de cómputo, lo que maximiza la eficiencia de este diseño desacoplado.

Por dentro: Resultados de evaluación comparativa interna

Para cuantificar el impacto de la actualización de nuestra infraestructura de AWS, el equipo de ingeniería de Elastic llevó a cabo una exhaustiva evaluación comparativa interna con una serie de cargas de trabajo sin servidor. Estas cargas de trabajo proporcionaron evidencia empírica de mejoras de rendimiento que puedes esperar en todas tus aplicaciones, independientemente de tu caso de uso.

El enfoque comparativo

Centramos nuestras pruebas en las métricas clave que afectan directamente a la experiencia de los desarrolladores y a la capacidad de respuesta de las aplicaciones: el tiempo de respuesta (es decir, la latencia) y el rendimiento en las operaciones de búsqueda e indexación.

• Cargas de trabajo probadas: Las pruebas incluyeron operaciones de búsqueda de alta concurrencia típicas de las aplicaciones orientadas al usuario, consultas de búsqueda vectorial complejas y la ingesta/indexación de grandes volúmenes de datos para casos de uso de observabilidad y seguridad. En concreto, nuestra metodología de pruebas utilizó sets de datos disponibles públicamente para Rally, la herramienta de evaluación comparativa de Elastic.

  • wikipedia: Un conjunto de datos derivado de un snapshot del contenido textual de Wikipedia, para medir el rendimiento de la búsqueda de texto de propósito general.

  • MSMARCO-Passage-Ranking: Un conjunto de datos derivado de la comprensión de lectura automática de Microsoft (MS MARCO), para medir el rendimiento de búsqueda en campos vectoriales dispersos.

  • OpenAI_Vector: Un set de datos derivado del NQ de BEIR y enriquecido con incrustaciones generadas por el modelo text-embedding-ada-002 de OpenAI, para medir el rendimiento de búsqueda en campos vectoriales densos.

• Medición: Comparamos el rendimiento en la infraestructura antigua y nueva, al medir la latencia en el percentil 99 (P99) para capturar el peor de los casos, el rendimiento de latencia en la cola y las operaciones por segundo. Cada pista se ejecutó cinco veces para cada perfil de hardware para garantizar la consistencia en los resultados.

• El objetivo: nuestro objetivo era validar la capacidad de la infraestructura para ofrecer un rendimiento más rápido y predecible de forma constante en todos los ámbitos, incluso durante los periodos de autoescalado rápido.

Resumen de datos de rendimiento

Los resultados confirman un aumento significativo en la eficiencia y la velocidad. Estas ganancias se traducen directamente en tiempos de respuesta más bajos para tus usuarios y menores costos operativos como resultado de la capacidad de completar la misma cantidad de trabajo con menos recursos de cómputo.

Las siguientes tablas detallan las mejoras cuantitativas. Los valores más altos son mejores para el rendimiento; los valores más bajos son mejores para la latencia.

Búsqueda de resultados del índice de referencia:

Benchmark

Comparación

Infraestructura antigua

Nueva infraestructura

Diferencial

`wikipedia` (texto sin formato)

Rendimiento de operaciones de búsqueda (ops/s)

729

1107

+52 %

`wikipedia` (texto sin formato)

Latencia de la operación de búsqueda (p99, ms)

56

35

-37 %

`MSMARCO-Passage-Ranking` (vectores dispersos)

Rendimiento de operaciones de búsqueda (ops/s)

22

31

+40 %

`MSMARCO-Passage-Ranking` (vectores dispersos)

Latencia de la operación de búsqueda (p99, ms)

108

67

-38 %

`OpenAI_Vector` (vectores densos)

Rendimiento de operaciones de búsqueda (ops/s)

475

624

+31 %

`OpenAI_Vector` (vectores densos)

Latencia de la operación de búsqueda (p99, ms)

35

22

-37 %

Resultados de referencia de indexación:

Benchmark

Comparación

Infraestructura antigua

Nueva infraestructura

Diferencial

`wikipedia` (texto sin formato)

Rendimiento de operaciones de búsqueda (ops/s)

2845

3220

+13 %

`wikipedia` (texto sin formato)

Latencia de la operación de búsqueda (p99, ms)

1769

1120

-37 %

`MSMARCO-Passage-Ranking` (vectores dispersos)

Rendimiento de operaciones de búsqueda (ops/s)

7087

8900

+26 %

`MSMARCO-Passage-Ranking` (vectores dispersos)

Latencia de la operación de búsqueda (p99, ms)

824

677

-18 %

`OpenAI_Vector` (vectores densos)

Rendimiento de operaciones de búsqueda (ops/s)

2972

3187

+7 %

`OpenAI_Vector` (vectores densos)

Latencia de la operación de búsqueda (p99, ms)

2946

2944

0 %

La ventaja adicional: reducción de costos

Aunque nuestro objetivo es ofrecer un rendimiento de baja latencia, la eficiencia del nuevo hardware también tiene un impacto directo y positivo en los costos de los proyectos de Elasticsearch.

El precio de Elasticsearch Serverless se basa en el uso, lo que significa que solo pagas por los recursos de ingesta y búsqueda que consumes. Debido a que el hardware más nuevo y rápido es más eficiente, tus cargas de trabajo a menudo completarán tareas empleando menos recursos, lo que genera una reducción de costos inherente para la mayoría de los proyectos. Obtendrás un aumento de rendimiento superior sin un precio premium: la definición de eficiencia optimizada.

¿Qué significa esto para ti, el desarrollador?

Esta actualización de infraestructura está gestionada íntegramente por Elastic, así que no tienes que mover un dedo: no hay migraciones ni cambios de configuración. La mejora es inmediata y automática en todos tus proyectos serverless basados en AWS.

Esta actualización te permite:

• Crea aplicaciones más rápidas: concéntrate en la velocidad de las características, sabiendo que tu plataforma de búsqueda subyacente ofrece la velocidad que exigen tus usuarios.

• Innova con confianza: despliega nuevas características de búsqueda, observabilidad y seguridad, incluidas capacidades complejas de IA, como búsqueda vectorial y clasificación de relevancia, con la seguridad de que la Platform puede manejar la carga al máximo rendimiento.

• Simplifica tu stack: Usa un servicio totalmente gestionado que gestione la infraestructura, la planificación de la capacidad y el escalado, para que puedas centrarte en tu código y datos.

En la última parte de este serial, explicamos cómo desplegar el modelo E5 preentrenado de Elastic (así como otros modelos multilingües de incrustación de texto de Hugging Face) y nos adentramos en la generación de incrustaciones vectoriales densas a partir de tus datos textuales usando Elasticsearch y Kibana. En este blog, analizaremos los resultados de estas incrustaciones y destacaremos los beneficios significativos de aprovechar un modelo multilingüe.

Ahora que tenemos nuestro índice coco_multilingual, realizar la búsqueda nos dará documentos en varios idiomas, con el campo "en" para que podamos consultar:

Realizando una búsqueda en inglés

Intentemos hacer la búsqueda en inglés y ver qué tal va:

Aquí, aunque la consulta parezca engañosamente simple, estamos buscando las incrustaciones numéricas de la palabra 'kitty' en todos los documentos y todos los idiomas que aparecen debajo del capó. Y como realizamos búsqueda vectorial, podemos buscar semánticamente todas las palabras que puedan estar relacionadas con 'kitty': "cat", "kitten", "felino", "gatto" (italiano), "meo" (vietnamita), 고양이 (coreano), 猫 (chino), etc. Como resultado, aunque mi consulta esté en inglés, también podemos buscar contenido en todos los demás idiomas. Por ejemplo, buscar un gatitoying on something también devuelve documentos en italiano, neerlandés o vietnamita. ¡Eso sí que es eficiencia!

Realizar una búsqueda de contenido en otros idiomas

De manera similar, realizar una búsqueda por palabra clave de "cat" en coreano ("고양이") también devolverá resultados significativos. Lo espectacular aquí es que ni siquiera tenemos documentos en coreano en este índice.

Esto funciona porque el modelo de incrustación representa el significado en un espacio semántico compartido, permitiendo la recuperación de imágenes relevantes incluso con una consulta en un idioma diferente al de los subtítulos indexados.

Aumento de resultados de búsqueda relevantes con búsqueda híbrida y reposicionamiento

Estamos contentos de que los resultados relevantes llegaron como se esperaba. Pero, en el mundo real, por ejemplo en comercio electrónico o en aplicaciones RAG que necesitan reducir a los 5-10 resultados más aplicables, podemos usar un modelo de reclasificación para priorizar los resultados más relevantes.

Aquí, realizar una consulta que pregunte "¿de qué color es el gato?" en vietnamita dará muchos resultados, pero el top 1 o 2 puede no ser el más relevante.

Todos los resultados mencionan gato, o algún tipo de color:

¡Así que vamos a mejorar eso! Integremos el modelo multilingüe de reclasificación de Coherepara mejorar el razonamiento correspondiente a nuestra pregunta.

Ahora, con los mejores resultados, nuestra solicitud puede responder con confianza que el color del gatito es negro o marrón con rayas. Lo que resulta aún más interesante aquí es que nuestra búsqueda vectorial detectó una omisión en el pie de foto en inglés del conjunto de datos original. Es capaz de encontrar al gato de rayas marrones aunque la traducción de referencia al inglés no mencionó ese detalle. Este es el poder de la búsqueda vectorial.

Conclusión

En este blog, explicamos la utilidad de un modelo de incrustación multilingüe y cómo aprovechar Elasticsearch para integrar los modelos y generar embeddings, y mejorar eficazmente la relevancia y la precisión mediante una búsqueda híbrida y un reclasificador. Puedes crear tu propio clúster en la nube para probar la búsqueda semántica multilingüe usando nuestro modelo E5 estándar en el idioma y conjunto de datos que elijas.

En un mundo de usuarios globales, la recuperación de información multilingüe (CLIR) es fundamental. En lugar de limitar las búsquedas a un solo idioma, CLIR te permite encontrar información en cualquier idioma, mejorando la experiencia del usuario y agilizando las operaciones. Imagina un mercado global donde los clientes de comercio electrónico puedan buscar artículos en su idioma, y los resultados adecuados aparezcan, sin necesidad de localizar los datos de antemano. O bien, donde los investigadores académicos pueden buscar artículos en su lengua materna, con matices y complejidad, incluso si la fuente está en otro idioma.

Los modelos de incrustación de texto multilingüe nos permiten hacer precisamente eso. Las incrustaciones son una forma de representar el significado del texto como vectores numéricos. Estos vectores están diseñados para que textos con significados similares estén situados cerca unos de otros en un espacio de alta dimensión. Los modelos de incrustación de texto multilingüe están diseñados específicamente para mapear palabras y frases con el mismo significado entre diferentes idiomas en un espacio vectorial similar.

Modelos como el Multilingüe E5 de código abierto se capacitan con enormes cantidades de datos textuales, a menudo empleando técnicas como el aprendizaje contrastivo. En este enfoque, el modelo aprende a distinguir entre pares de textos con significados similares (pares positivos) y aquellos con significados diferentes (pares negativos). El modelo se capacita para ajustar los vectores que produce de modo que se maximice la similitud entre pares positivos y se minimice la similitud entre pares negativos. Para modelos multilingües, estos datos de entrenamiento incluyen pares de texto en diferentes idiomas que son traducciones entre sí, permitiendo al modelo aprender un espacio de representación compartido para múltiples idiomas. Las incrustaciones resultantes pueden usar para diversas tareas de PLN, incluyendo la búsqueda cross-lingual, donde la similitud entre incrustaciones de texto se emplea para encontrar documentos relevantes independientemente del idioma de la consulta.

Beneficios de la búsqueda vectorial multilingüe

• Matiz: La búsqueda vectorial destaca en captar el significado semántico, yendo más allá de la simple búsqueda de palabras clave. Esto es crucial para tareas que requieren comprender el contexto y las sutilezas del lenguaje.

• Comprensión interlingüe: Permite una recuperación efectiva de información entre idiomas, incluso cuando la consulta y los documentos emplean vocabulario diferente.

• Relevancia: Ofrece resultados más relevantes centrar en la similitud conceptual entre consultas y documentos.

Por ejemplo, consideremos a un investigador académico que estudia el "impacto de las redes sociales en el discurso político" en diferentes países. Con la búsqueda vectorial, pueden introducir consultas como "l'impacto dei social media sul discorso politico" (italiano) o "ảnh hưởng của mạng xã hội đối với diễn ngôn chính trị" (vietnamita) y encontrar artículos relevantes en inglés, español o cualquier otro idioma indexado. Esto se debe a que la búsqueda vectorial identifica artículos que discuten el concepto de influencia de las redes sociales en la política, no solo aquellos que contienen las palabras clave exactas. Esto mejora enormemente la amplitud y profundidad de su investigación.

Primeros pasos

Así es como configurar CLIR usando Elasticsearch, con el modelo E5 que se proporciona de fábrica. Emplearemos el conjunto de datos multilingüe de código abierto COCO, que contiene pies de foto en varios idiomas, para ayudarnos a visualizar dos tipos de búsquedas:

1. Consultas y términos de búsqueda en otros idiomas en un conjunto de datos en inglés, y

2. Consultas en varios idiomas sobre un conjunto de datos que contiene documentos en varios idiomas.

Luego, aprovecharemos el poder de la búsqueda híbrida y el reposicionamiento para mejorar aún más los resultados de búsqueda.

Prerrequisitos

• Python 3.6+

• Elasticsearch 8+

• Cliente Python de Elasticsearch: instalación de pip elasticsearch

Conjunto de datos

El conjunto de datos COCO es un conjunto de datos de subtitulado a gran escala. Cada imagen del conjunto de datos está subtitulada en varios idiomas diferentes, con varias traducciones disponibles por idioma. Para fines demostrativos, indexaremos cada traducción como un documento individual, junto con la primera traducción al inglés disponible para referencia.

Paso 1: descargar el conjunto de datos multilingüe COCO

Para simplificar el blog y facilitar el seguimiento, aquí estamos cargando las primeras 100 filas de Restval en un archivo JSON local con una llamada API sencilla. Alternativamente, puedes usar los conjuntos de datos de la biblioteca de HuggingFace para cargar el conjunto de datos completo o subconjuntos del conjunto.

Si los datos se cargan correctamente en un archivo JSON, deberías ver algo similar a lo siguiente:

Data successfully downloaded and saved to multilingual_coco_sample.json

Paso 2: (Iniciar Elasticsearch) e indexar los datos en Elasticsearch

a) Inicia tu servidor local de Elasticsearch.

b) Iniciar el cliente Elasticsearch.

c) Datos de índice

Una vez indexados los datos, deberías ver algo similar a lo siguiente:

Successfully bulk indexed 4840 documents

Indexing complete!

Paso 3: Desplegar el modelo capacitado con E5

En Kibana, accede a la página de Stack Management > Trained Models y haz clic en Desplegar para el .multilingual-e5-small_linux-x86_64 opción. Este modelo E5 es un pequeño multilingüe optimizado para linux-x86_64, que podemos usar de fábrica. Al hacer clic en 'Desplegar' aparecerá una pantalla donde puedes ajustar la configuración de despliegue o las configuraciones de los vCPU. Para simplificar, optaremos por las opciones predeterminadas, con recursos adaptativos seleccionados, que escalarán automáticamente nuestro despliegue según el uso.

Opcionalmente, si quieres usar otros modelos de incrustación de texto, puedes hacerlo. Por ejemplo, para usar el BGE-M3, puedes usar el cliente Eland Python de Elastic para importar el modelo desde HuggingFace.

Luego, ve a la página de Modelos Capacitados para desplegar el modelo importado con las configuraciones deseadas.

Paso 4: Vectorizar o crear incrustaciones para los datos originales con el modelo desplegado

Para crear los embeddings, primero necesitamos crear un pipeline de ingesta que nos permita tomar el texto y pasarlo por el modelo de embedding de texto de inferencia. Puedes hacerlo en la interfaz de usuario de Kibana o a través de la API de Elasticsearch.

Para hacerlo a través de la interfaz Kibana, tras desplegar el Modelo Capacitado, haz clic en el botón Test . Esto te dará la posibilidad de probar y previsualizar los embeddings generados. Crea una nueva vista de datos para elíndice de coco, configura la vista de datos en la vista de datos coco recién creada y pon el campo en description porque ese es el campo para el que queremos generar incrustaciones.

¡Eso funciona genial! Ahora podemos proceder a crear la pipeline de ingest, reindexar nuestros documentos originales, pasarlos por la pipeline y crear un nuevo índice con los embeddings. Puedes conseguirlo haciendo clic en Crear pipeline, lo que te guiará durante el proceso de creación de pipeline, con procesadores auto-repoblados necesarios para ayudarte a crear los embeddings.

El asistente también puede rellenar automáticamente los procesadores necesarios para gestionar fallos mientras se ingieren y procesan los datos.

Ahora creemos la canalización de ingest. Voy a nombrar el oleoducto coco_e5. Una vez que la tubería se crea correctamente, puedes usarla inmediatamente para generar las incrustaciones reindexando los datos originales indexados a un nuevo índice en el asistente. Haz clic en Reindexar para iniciar el proceso.

Para configuraciones más complejas, podemos usar la API de Elasticsearch.

Para algunos modelos, debido a la forma en que se capacitaron, puede que necesitemos anteponer o agregar ciertos textos a la entrada real antes de generar los embeddings; de lo contrario, veremos una degradación del rendimiento.

Por ejemplo, con el e5, el modelo espera que el texto de entrada siga a "passage: {content of passage}". Empleemos los pipelines de ingest para lograrlo: crearemos un nuevo pipeline de ingest vectorize_descriptions. En esta canalización, crearemos un nuevo campo de temp_desc temporal, antepondremos "passage: " al texto description , pasaremos temp_desc por el modelo para generar incrustaciones de texto y luego eliminaremos el temp_desc.

Además, podríamos querer especificar qué tipo de cuantización queremos usar para el vector generado. Por defecto, Elasticsearch usa int8_hnsw, pero aquí quiero Better Binary Quantization (o bqq_hnsw), que reduce cada dimensión a una precisión de un solo bit. Esto reduce la huella de memoria en un 96% (o 32 veces) a un costo mayor en la precisión. Opto por este tipo de cuantización porque sé que usaré un reclasificador más adelante para mejorar la pérdida de precisión.

Para ello, crearemos un nuevo índice llamado coco_multi y especificaremos los mapeos. La magia aquí está en el campo vector_description, donde especificamos que el tipo del index_optionsdebe ser bbq_hnsw.

Ahora, podemos reindexar los documentos originales a un nuevo índice, con nuestra pipeline de ingesta que "vectorizará" o creará incrustaciones para el campo de descripciones.

¡Y eso es todo! Desplegamos con éxito un modelo multilingüe con Elasticsearch y Kibana y aprendido paso a paso cómo crear las incrustaciones vectoriales con tus datos con Elastic, ya sea a través de la interfaz de usuario de Kibana o con la API de Elasticsearch. En la segunda parte de este serial, exploraremos los resultados y las particularidades del uso de un modelo multilingüe. Mientras tanto, puedes crear tu propio clúster en la nube para probar la búsqueda semántica multilingüe usando nuestro modelo E5 estándar en el idioma y conjunto de datos que elijas.

Tradicionalmente, gestionar los rastreadores era un proceso manual y propenso a errores. Implicaba editar configuraciones directamente en la interfaz y luchar con clonar configuraciones de rastreo, retrocesos, versionear y más. Tratar las configuraciones de rastreadores como código resuelve esto al proporcionar los mismos beneficios que esperamos en el desarrollo de software: repetibilidad, trazabilidad y automatización.

Este flujo de trabajo facilita la incorporación del Open Sitio web Crawler a tu pipeline CI/CD para rollbacks, copias de seguridad y migraciones, tareas que eran mucho más complicadas con los Elastic Crawlers anteriores, como el Elastic Sitio web Crawler o el App Search Crawler.

En este artículo, vamos a aprender cómo:

• Gestiona nuestras configuraciones de rastreo usando GitHub

• Tener una configuración local para probar pipelines antes de desplegar

• Crea una configuración de producción para ejecutar el rastreador sitio web con nuevos ajustes cada vez que enviemos cambios a nuestra rama principal

Puedes encontrar el repositorio de proyectos aquí. Según escribo, estoy usando Elasticsearch 9.1.3 y Open Sitio web Crawler 0.4.2.

Prerrequisitos

• Escritorio Docker

• Instancia de Elasticsearch

• Máquina virtual con acceso SSH (por ejemplo, AWS EC2) y Docker instalados

Pasos

1. Estructura de carpetas

2. Configuración del orugador

3. Docker-compose (entorno local)

4. Acciones en Github

5. Pruebas locales

6. Desplegando a la producción

7. Realización de cambios y re-despliegue

Estructura de carpetas

Para este proyecto, tendremos la siguiente estructura de archivos:

Configuración del orugador

Bajo crawler-config.yml, pondremos lo siguiente:

Esto se rastreará desde https://sitio web-scraping.dev/products, un sitio simulado de productos. Solo rastrearemos las tres primeras páginas del producto. La configuración max_crawl_depth evitará que el rastreador descubra más páginas de las definidas como seed_urls al no abrir los enlaces que contienen.

Elasticsearch host y api_key se llenarán dinámicamente dependiendo del entorno en el que ejecutemos el script.

Docker-compose (entorno local)

Para la docker-compose.yml, local desplegaremos el rastreador y un único clúster Elasticsearch + Kibana, para poder visualizar fácilmente los resultados del rastreo antes de desplegarlos en producción.

Fíjate en cómo el rastreador espera hasta que Elasticsearch esté listo para ejecutar.

Acciones en Github

Ahora necesitamos crear una acción en GitHub que copie la nueva configuración y ejecute el rastreador en nuestra máquina virtual en cada envío a main. Esto garantiza que siempre tengamos la última configuración desplegada, sin tener que entrar manualmente en la máquina virtual para actualizar archivos y ejecutar el rastreador. Vamos a usar AWS EC2 como proveedor de máquinas virtuales.

El primer paso es agregar el host (VM_HOST), el usuario de la máquina (VM_USER), la clave SSH RSA (VM_KEY), el host de Elasticsearch (ES_HOST) y la clave API de Elasticsearch (ES_API_KEY) a los secretos de acción de GitHub:

De este modo, la acción podrá acceder a nuestro servidor para copiar los archivos nuevos y ejecutar el rastreo.

Ahora, creemos nuestro archivo .github/workflows/deploy.yml :

Esta acción ejecutará los siguientes pasos cada vez que empujemos cambios en el archivo de configuración del rastreador:

1. Llenar el host y la clave API de Elasticsearch en la configuración de yml

2. Copia la carpeta config a nuestra máquina virtual

3. Conéctate vía SSH a nuestra máquina virtual

4. Ejecuta el rastreo con la configuración que acabamos de copiar del repositorio

Pruebas locales

Para probar nuestro rastreador localmente, creamos un script bash que llena el host de Elasticsearch con el local de Docker y comienza un rastreo. Puedes ejecutar ./local.sh para ejecutarlo.

Veamos Kibana DevTools para confirmar que el web-crawler-index se rellenó correctamente:

Desplegando a la producción

Ahora estamos listos para enviar a la rama principal, que desplegará el rastreador en tu máquina virtual y comenzará a enviar registros a tu instancia Serverless Elasticsearch.

Esto activará la Acción de GitHub, que ejecutará el script de despliegue dentro de la máquina virtual y comenzará a rastrear.

Puedes confirmar que la acción se ejecutó yendo al repositorio de GitHub y visitando la pestaña "Acciones":

Realización de cambios y re-despliegue

Algo que quizá notaste es que el price de cada producto forma parte del cuerpo del documento. Lo ideal sería almacenar el precio en un campo aparte para poder aplicar filtros sobre él.

Vamos a agregar este cambio al archivo crawler.yml para usar reglas de extracción que extraigan el precio de la clase CSS de product-price :

También vemos que el precio incluye un signo de dólar ($), que debemos eliminar si queremos hacer consultas por rango. Podemos usar una canalización de ingesta para eso. Ten en cuenta que lo estamos haciendo referencia en nuestro nuevo archivo de configuración del rastreador arriba:

Podemos ejecutar ese comando en nuestro clúster de Elasticsearch en producción. Para el desarrollo, al ser efímero, podemos hacer que la creación de pipeline forme parte del archivo docker-compose.yml agregando el siguiente servicio. Ten en cuenta que también agregamos un depends_on al servicio de rastreo para que empiece después de que la tubería se creó con éxito.

Ahora vamos a ejecutar `./local.sh` para ver el cambio localmente:

¡Bien! Ahora impulsemos el cambio:

Para confirmar que todo funciona, puedes comprobar tu Kibana de producción, que debería reflejar los cambios y mostrar el precio como un nuevo campo sin el signo del dólar.

Conclusión

El Elastic Open Sitio web Crawler te permite gestionar tu rastreador como código, lo que significa que puedes automatizar toda la pipeline —desde el desarrollo hasta el despliegue— y agregar entornos locales efímeros y pruebas programáticas contra los datos rastreados, por nombrar algunos ejemplos.

Se te invita a clonar el repositorio oficial y empezar a indexar tus propios datos usando este flujo de trabajo. También puedes leer este artículo para aprender a realizar búsqueda semántica en índices producidos por el rastreador.