Esta postagem final pergunta: O que muda quando a entrada vem de um agente de IA?

A resposta é que a arquitetura não muda, mas o que está em jogo, sim. Todas as propriedades do plano de controle governado que importam para consultas criadas por humanos tornam-se ainda mais importantes quando o tomador de decisão é um modelo de linguagem de grande porte (LLM). Determinismo, auditabilidade, resolução de conflitos e aplicação de restrições tornam-se proteções fundamentais em vez de conveniências operacionais, porque o sistema que produz os dados de entrada é probabilístico por natureza.

O problema de busca agêntica

A abordagem mais comum para a busca impulsionada por IA é direta: forneça ao LLM o esquema do banco de dados, insira as regras de negócio no prompt e permita que o agente gere a consulta diretamente.

Para um chatbot de e-commerce, isso significa injetar o mapeamento de índice do Elasticsearch, os tipos de campo, as taxonomias de categorias, a lógica de preços e as restrições de negócio na janela de contexto do agente e pedir ao LLM que traduza a linguagem natural para um DSL válido de consulta Elasticsearch. O LLM se torna o autor da consulta.

Essa abordagem funciona em demonstrações. Ela falha na produção por quatro motivos.

Excesso de contexto

Um mapeamento de índice de e-commerce empresarial não é um documento trivial. Definições de campos, objetos aninhados, configurações de múltiplos campos e configurações de analisador podem conter milhares de tokens antes que qualquer lógica de negócio seja adicionada. Além do mapeamento, o agente precisa de taxonomias de categorias (que, no e-commerce empresarial, podem conter dezenas de milhares de valores), regras de preços, hierarquias de marcas, restrições de elegibilidade e lógica de campanhas.

O resultado é uma janela de contexto dominada por metadados estruturais em vez da real intenção do usuário. Isso aumenta a latência, aumenta o custo do token e degrada a capacidade do LLM de seguir instruções à medida que o contexto cresce. Este é um fenômeno bem documentado, às vezes chamado decomposição de contexto: conforme o prompt fica mais longo, a atenção do modelo a qualquer instrução específica enfraquece.

Alucinação probabilística

Os LLMs geram consultas com base em padrões em dados de treinamento e no contexto fornecido. Quando recebe a solicitação de produzir Elasticsearch Query DSL, o modelo pode alucinar nomes de campos que não existem, criar cláusulas de consulta sintaticamente inválidas, aplicar incorretamente tipos de filtro aos tipos de campo errados ou produzir consultas que são sintaticamente válidas, mas semanticamente erradas, retornando resultados que não correspondem à intenção do usuário.

O benchmark BIRD do Google Cloud para Text-to-SQL ilustra o limite dessa abordagem. O resultado de última geração do Google, baseado em um único modelo, alcançou uma precisão entre 70% e 80%, o que significa que quase uma em cada quatro consultas geradas estava incorreta. Isso é para SQL, que é muito mais padronizado do que o DSL de Consulta Elasticsearch. A taxa de erro para consultas do Elasticsearch geradas pelo LLM em um ambiente de produção real, com mapeamentos complexos e semântica específica do negócio, provavelmente seria maior.

Para um sistema de e-commerce crítico para a receita, uma taxa de erro de um para quatro consultas não é um problema de ajuste a ser resolvido iterativamente. É uma limitação arquitetônica da abordagem.

A lacuna de segurança

Quando o LLM tem acesso ao esquema do banco de dados e age como o autor da consulta, o sistema fica vulnerável à injeção indireta de prompt. Um usuário interagindo com um chatbot de e-commerce pode criar entradas projetadas para manipular o agente a gerar consultas não intencionais.

Isso não é um risco teórico. Injeção de prompt é uma das superfícies de ataque mais ativamente pesquisadas em sistemas LLM implantados. A questão fundamental é que, quando o agente cria a consulta, não há uma fronteira estrutural entre a intenção do usuário e a execução da consulta. O LLM interpreta simultaneamente a solicitação do usuário e constrói a operação do banco de dados. Qualquer manipulação do primeiro afeta diretamente o segundo.

Falha de redimensionamento em alta cardinalidade

Certos campos de e-commerce têm cardinalidade extrema. Um catálogo de produtos pode ter 17.000 valores de categoria, milhares de marcas e centenas de combinações de atributos. Fluxos de trabalho agênticos padrão exigem a injeção desses valores no contexto para que o LLM possa selecionar o correto ao construir uma consulta.

Isso cria um trade-off impossível: ou se injetam todos os valores possíveis (consumindo um contexto enorme e degradando o desempenho), se injeta um subconjunto (e se aceita que o agente não pode referenciar valores fora desse subconjunto) ou se recorre à busca não governada. Isso se conecta diretamente ao problema central da Parte 1: se o LLM pesquisar por “laranjas” e o Elasticsearch retornar refrigerante de laranja, a experiência do chat se degrada da mesma forma que uma experiência de busca. A ausência de governança significa que o sistema não consegue aplicar a resolução pretendida pelo consumidor.

Recuperar valores relevantes de forma dinâmica com base na consulta é uma alternativa conhecida, mas introduz uma etapa adicional não determinística onde a própria recuperação pode perder valores relevantes. Além disso, adiciona latência e complexidade a cada consulta.

A alternativa arquitetônica: desacoplar intenção da execução

O plano de controle governado descrito nas Partes 1 a 7 oferece uma abordagem fundamentalmente diferente. Em vez de o LLM criar a consulta final, a função do LLM é reduzida a uma tarefa única e bem delimitada: extrair uma string de intenção de busca da entrada de linguagem natural do usuário.

O usuário diz: "Estou procurando sapatos marrons baratos." O trabalho do agente não é gerar uma consulta Elasticsearch. É extrair e repassar a intenção de busca (neste caso, algo como "sapatos marrons baratos") para o plano de controle. O plano de controle então faz o que sempre fez: permeia a string de intenção contra políticas armazenadas, compõe políticas correspondentes por meio de transformações em cascata, resolve conflitos deterministicamente e produz uma consulta Elasticsearch governada.

O LLM nunca vê o mapeamento do índice. Ele nunca sabe sobre tipos de campo, taxonomias de categorias ou limites de preço. Ele nunca cria uma cláusula de consulta. Ele opera no lado da linguagem natural de uma fronteira arquitetônica que chamamos de lacuna de metadados, uma separação estrita entre o componente probabilístico (o LLM) e a camada de dados estruturados (esquema, políticas e construção de consultas).

O que a separação de metadados oferece

• Cegueira ao esquema. O LLM não tem acesso ao esquema do banco de dados e, portanto, não pode gerar consultas inválidas, inventar nomes de campos ou ser manipulado para expor informações estruturais. O esquema existe apenas no lado determinístico do air gap.

• Contexto mínimo. Em vez de milhares de tokens de dados de mapeamento, regras de negócios e taxonomias de categorias, o prompt do LLM contém apenas instruções para extração de persona e intenção. Isso reduz drasticamente o custo do token, a latência e a deterioração do contexto.

• Execução determinística. Toda consulta que chega ao Elasticsearch é construída pelo plano de controle usando modelos de políticas avaliados por humanos, e não gerada probabilisticamente por um LLM. A validade sintática é garantida. A correção semântica é imposta pelo mesmo framework de políticas que as Partes 1 a 6 descreveram.

• Segurança pela arquitetura. A injeção rápida se torna estruturalmente ineficaz. Mesmo que um usuário manipule o agente para produzir uma string de intenção incomum, essa string é permeada contra políticas armazenadas. Se nenhuma política corresponde, nenhuma consulta é gerada. O usuário não pode instruir o agente a construir uma consulta porque o agente não cria consultas. O plano de controle sim, e o plano de controle é determinístico.

Como as peças se conectam

O guia a seguir mostra como o plano de controle governado lida com uma consulta mediada por agente.

Passo 1: O usuário fala com o agente

Um comprador interagindo com um chatbot de e-commerce diz: "Estou procurando chocolate barato, sem amendoim."

Etapa 2: O agente extrai a intenção

O papel do LLM é extração de intenções, não geração de consultas. Com uma solicitação mínima que o instrui a identificar a intenção do produto, o agente produz uma string de intenção de buscar: "chocolate barato sem amendoim".

Esta é uma tarefa de classificação leve. O LLM não precisa do mapeamento de índice, taxonomia de categorias ou regras de precificação para realizá-lo. Ele precisa entender linguagem natural, que é exatamente no que os LLMs são bons.

Etapa 3: O plano de controle governa a consulta

A string de intenção "chocolate barato sem amendoim" é passada para o plano de controle, que a filtra contra o índice de política. Três políticas coincidem:

• A política "barato" (extrai "barato", aplica um filtro de preço com base na categoria do produto).

• A política de "chocolate" (restringe os resultados a categorias de chocolate).

• A política de negação "sem" (extrai o alvo de exclusão e aplica um filtro must_not )

O plano de controle aplica essas políticas por meio da mesma transformação em cascata descrita nas Partes 3 e 4: ordenação de prioridade, resolução de conflitos por campo e rastreamento de frases consumidas. Se uma política de "campanha de Natal" também estiver ativa, ela se compõe com as políticas de produto exatamente como descrito na Parte 3, o envolvimento do agente não altera em nada o modelo de governança.

Etapa 4: A consulta controlada é executada

O plano de controle gera uma consulta Elasticsearch totalmente governada: uma busca por "chocolate", restrita às categorias apropriadas, com um limite de preço derivado da política de "barato", um filtro de exclusão para produtos que contenham amendoim e quaisquer impulsionamentos de campanha ativos aplicados. Se a política de “chocolate” também incluir pesos de otimização econômica (Parte 7), estes também serão aplicados. O aumento de margem está definido em 3,0x porque "chocolate" é uma consulta de navegação em que o varejista se beneficia ao promover produtos com margens mais altas. Se o comprador tiver um histórico de compras(Parte 6), os sinais de personalização serão colocados em camadas. Essa consulta é sintaticamente válida por construção e semanticamente correta de acordo com a política de projeto.

Etapa 5: Retorno dos resultados pelo agente

Os resultados do produto são retornados ao agente, que os apresenta de forma conversacional ao usuário. O papel do agente no caminho de retorno é a apresentação: formatar resultados, responder perguntas de acompanhamento e fornecer detalhes do produto. A própria recuperação era governada, determinística e explicável.

No que o agente é bom (e no que não é)

Essa arquitetura aproveita o LLM para o que ele faz bem e protege o sistema do que ele faz mal.

Os LLMs se destacam em compreender a intenção da linguagem natural. "Estou procurando chocolate barato, sem amendoim" é uma tarefa de compreensão de linguagem natural, analisando a intenção, identificando referências de produtos e reconhecendo a negação. Os LLMs lidam com isso de forma confiável porque é um problema de classificação, não de geração. A saída é uma string curta de intenção, não uma consulta complexa e estruturada.

Os LLMs enfrentam dificuldades para gerar resultados estruturados precisos sob restrições complexas. A geração de DSL válida do Elasticsearch Query exige nomes de campo exatos, aninhamento correto de cláusulas, tipos de filtro apropriados para cada campo e aplicação consistente de regras de negócios em milhares de casos extremos. Essas são exatamente as propriedades que um sistema determinístico impõe trivialmente e que um sistema probabilístico aplica de forma pouco confiável.

O plano de controle governado coloca cada componente onde ele pertence: o LLM no lado da linguagem natural, o mecanismo de política determinística no lado da construção de consultas e um limite arquitetônico entre eles.

A governança restringe o raio da explosão

Essa é a mesma percepção da Parte 3, ampliada ao contexto agêntico. Na Parte 3, observamos que a governança torna a recuperação semântica mais segura ao restringir o conjunto de candidatos antes do início da recuperação. Uma busca semântica sobre 500 produtos em uma categoria governada é uma proposta fundamentalmente diferente de uma busca semântica sobre 500.000 SKUs.

O mesmo princípio se aplica a consultas mediadas por agentes. Sem governança, um agente que interprete mal "chocolate barato" poderia gerar uma consulta que buscasse todo o catálogo sem restrição de preço, sem filtro de categoria e sem exclusões. Com governança, mesmo que o agente produza uma string de intenção imperfeita, o plano de controle restringe a consulta às políticas que correspondem. O pior cenário é que menos políticas sejam ativadas, não que uma consulta ilimitada entre no catálogo de produtos.

A governança reduz o raio de explosão de erros probabilísticos. Isso é verdade tanto para o componente probabilístico quanto para um modelo semântico de recuperação ou um agente de LLM.

Políticas sugeridas pelo LLM: ampliar a cobertura

A Parte 2 introduziu a ideia de que um LLM pode sugerir novas políticas que entram no mesmo pipeline Author → Test → Promote que as criadas por humanos. No contexto agente, isso se torna um poderoso ciclo de retroalimentação.

Um LLM pode analisar os logs de consulta, identificar padrões em que o plano de controle não tem uma política correspondente (consultas que passam por uma recuperação não modificada) e sugerir novas políticas para cobrir essas lacunas. Um comerciante analisa cada sugestão, testa e a promove se ela produzir o comportamento esperado. O modelo de governança garante que nenhuma política sugerida pelo LLM chegue à produção sem validação humana.

Com o tempo, isso cria um ciclo virtuoso: a abrangência das políticas do plano de controle se expande, a proporção de consultas que exigem recuperação sem modificações diminui e o sistema se torna progressivamente mais governado, com cada política auditável, versionada e reversível individualmente.

O padrão mais amplo: proteções determinísticas para sistemas probabilísticos

A arquitetura descrita nesta série, um plano de controle determinístico que se situa entre uma fonte de entrada probabilística e um sistema de recuperação de dados, não é específica para busca em e-commerce. O mesmo padrão se aplica sempre que um agente de IA precisa interagir com dados estruturados.

Um agente que consulta um banco de dados SQL enfrenta os mesmos desafios: excesso de contexto devido à injeção de esquema, nomes de colunas alucinados, riscos de injeção imediata e seleção de valores de alta cardinalidade. Um agente interagindo com um sistema de emissão de tíquetes como o Jira, um sistema de gerenciamento de relacionamento com o cliente (CRM) como o Salesforce ou um repositório de código como o GitHub enfrenta problemas análogos. Em todos os casos, a questão arquitetônica do núcleo é a mesma: o LLM deve criar a consulta ou o LLM deve extrair a intenção e passá-la para uma camada determinística que cria a consulta?

O plano de controle governado fornece uma resposta repetível para essa pergunta. As políticas são dados. A extração de intenções é tarefa do LLM. A construção de consultas é tarefa do plano de controle. O espaço de metadados os mantém separados. E o framework de governança (ordenação de prioridades, resolução de conflitos, transformações em cascata, auditabilidade) garante que a camada determinística seja operacionalmente gerenciável à medida que o número de políticas cresce.

Conclusão

Os padrões de governança de pesquisa de e-commerce descritos nesta série (políticas como dados, fluxo de trabalho Autor → Teste → Promover, transformações em cascata, resolução de conflitos por campo, correspondência reversa baseada em permeações e fallback de várias camadas) foram projetados para um mundo em que um comerciante cria políticas e um comprador digita consultas. Mas a arquitetura pode permitir muito mais do que seu caso de uso inicial.

Quando a fonte de entrada é um agente de IA em vez de um comprador humano, o plano de controle governado torna-se a camada de segurança crítica entre um sistema probabilístico e um armazenar de dados de produção. Ele oferece as garantias determinísticas (validade sintática, correção semântica, auditabilidade e segurança) que os sistemas corporativos exigem e que os LLMs não podem fornecer sozinhos.

O plano de controle determinístico não substitui o agente de IA. Isso torna o agente de IA seguro para implantação.

Coloque em prática o buscar governado de comércio eletrônico

A arquitetura do plano de controle governado descrita nesta série, desde o paradigma de política como dados até a busca baseada em permeação, passando pela personalização, otimização econômica e o espaço aéreo agente, foi projetada e construída pela Elastic Services Engineering. Cada padrão descrito nesta série provém de um sistema funcional construído e validado em catálogos de produtos de escala empresarial.

Se sua equipe está desenvolvendo experiências de busca com inteligência artificial e precisa de diretrizes determinísticas para consultas mediadas por agentes, ou se deseja implementar uma arquitetura de busca governada e editável pela empresa no Elasticsearch, o Elastic Professional Services pode acelerar a implementação. Entre em contato com o Elastic Professional Services.

Participe da discussão

Tem dúvidas sobre governança de buscar, estratégias de recuperação ou arquitetura de buscar para e-commerce? Participe da conversa mais ampla da comunidade Elastic.

Este post apresenta dois mecanismos de personalização que ampliam o plano de controle governado sem alterar a arquitetura. Ambos os mecanismos se acumulam multiplicativamente com a camada de governança das Partes 1 a 5: as políticas ainda são acionadas, as restrições ainda são aplicadas, os conflitos ainda são resolvidos e os sinais de personalização são compostos na mesma consulta governada, garantindo que os resultados retornados pelo Elasticsearch já estejam personalizados.

O primeiro mecanismo impulsiona produtos que o cliente individual já comprou antes. O segundo ativa políticas específicas de grupo com base no perfil do cliente. Juntos, eles demonstram que a personalização não é um sistema separado acoplado à busca ou aplicado como processamento pós-recuperação; é uma extensão natural do plano de controle orientado por políticas.

Para uma análise aprofundada da matemática por trás das técnicas de personalização usadas nesta postagem, veja Busca personalizada no Elasticsearch sem pós-processamento de ML e Classificação com reconhecimento de agrupamento no Elasticsearch.

Para ver uma demonstração em tempo real de como o histórico de compras pode ser usado para melhorar os resultados de busca para clientes recorrentes, assista ao vídeo: Personalização explicável: melhora na busca com o histórico de compras.

Impulsionamento do histórico de compras individual

A forma mais simples de personalização também é uma das mais eficazes: se um cliente já comprou um produto antes, valorize-o quando ele buscar algo relacionado ao produto. Um comprador que compra regularmente uma marca específica de cookies com gotas de chocolate deve ver esses biscoitos listados primeiro ao buscar por "cookies", não porque um modelo previu uma preferência, mas porque há evidências comportamentais diretas.

Como funciona

Quando uma solicitação de pesquisa inclui um identificador de usuário, como seria o caso de um usuário que tem uma sessão aberta, o plano de controle executa duas consultas Elasticsearch em paralelo usando um thread pool:

1. A consulta percolador no índice de políticas (a mesma pesquisa de governança descrita nas Partes 3 e 4).

2. Uma consulta de histórico de compras em um índice user_purchases , filtrada para o usuário específico por term(user_id) e comparação da string de pesquisa atual com os títulos de produtos desse usuário.

Essas operações executam de forma concomitante (nenhuma espera pela outra), então a busca de personalização não adiciona latência significativa ao pipeline de governança.

A consulta do histórico de compras usa a análise de texto do Elasticsearch (stemming, tokenização) ao comparar a string de busca atual com os títulos de produtos armazenados. Isso significa que ao buscar por "cookies" corresponderá a uma compra anterior de "cookies de brownie" por meio da análise de texto padrão, sem exigir a correspondência exata de string.

Cálculo dos pesos de impulso

Nem todas as compras passadas merecem o mesmo impulso. O peso é responsável por dois fatores intuitivos: a frequência com que o comprador comprou o produto e há quanto tempo. Um produto comprado 15 vezes na semana passada é um sinal muito mais forte do que um produto comprado uma vez há seis meses. A ponderação usa redimensionamento logarítmico na frequência (para que um único item muito comprado não sobrecarregue todos os outros) e decaimento exponencial na atualidade (para que compras antigas desapareçam naturalmente com o tempo).

Para saber os detalhes matemáticos da fórmula de impulso, veja Busca personalizada no Elasticsearch sem pós-processamento de ML.

Como isso se torna uma consulta

Os impulsos do histórico de compras são incorporados à consulta como a camada de pontuação mais externa, envolvendo os filtros de política de governança e os impulsos das Partes 3 e 4, além de quaisquer impulsos de sinais de negócios, como margem e popularidade (que exploraremos na Parte 7). Isso significa que um produto removido por uma política de governança não reaparecerá devido a um impulso no histórico de compras. A governança controla o conjunto de resultados; a personalização ajusta a ordenação dentro dele. Produtos sem histórico de compras não são penalizados. A classificação que possuíam é mantida, embora produtos com histórico de compras relevante fiquem acima deles, considerando todos os outros fatores iguais.

Por que consultar o Elasticsearch em cada busca?

O histórico de compras é consultado no Elasticsearch a cada busca, em vez de ficar em cache na camada de aplicação. Esta é uma escolha de design deliberada. Como a consulta faz a correspondência da string de busca atual com os títulos dos produtos usando o pipeline de análise de texto do Elasticsearch, o sistema se beneficia da mesma stemização, da tokenização e do tratamento de idioma que melhoram a própria busca de produtos. Uma consulta em cache na memória exigiria reimplementar essa análise ou aceitar uma correspondência menos precisa.

Para ver por que essa ordenação importa, considere um comprador que já comprou suco de laranja e agora busca por "laranjas". A consulta do histórico de compras faz a correspondência de "suco de laranja" com o termo de busca "laranjas" por meio da análise de texto e calcula um impulso para esse produto. Mas a camada de governança já restringiu "laranjas" à categoria de hortifruti, excluindo por completo o suco de laranja. O impulso do histórico de compras para suco de laranja está presente na consulta, mas não tem efeito porque não há nenhum documento correspondente, no conjunto de resultados governado, sobre o qual ele possa atuar. O comprador vê laranjas frescas, ranqueadas por relevância e personalização. A proteção de governança continua valendo.

O custo de desempenho é mínimo: o índice do histórico de compras é pequeno (o histórico de compras de um usuário normalmente tem de dezenas a centenas de documentos, não milhões), e a consulta é executada em paralelo à busca pelo percolador, portanto não estende o caminho importante.

Exemplo de consulta para “água mineral” sem histórico do usuário

Se um usuário não logado ou um usuário que nunca comprou "água mineral" pesquisar, pode encontrar resultados semelhantes aos seguintes:

Exemplo de histórico de compras do usuário

Por outro lado, uma usuária chamada Carol tem um histórico de compras que contém os seguintes produtos:

Exemplo de busca por "água mineral" com o histórico de compras acima

Se Carol buscar por “água mineral”, verá resultados personalizados que refletem o que ela comprou no passado. Olhando o histórico de compras acima, ela comprou "água mineral" (a garrafa verde) cerca de 40 vezes, e a compra mais recente foi há dois dias. Se ela buscar por "água mineral", esse produto é potencializado, pois sabemos que ela gosta disso. Note que, nos resultados não personalizados, a água mineral Rubicon foi o primeiro resultado.

Ativação de políticas sensível à coorte

O histórico de compras individual funciona bem para clientes recorrentes com comportamento definido. Mas muitos compradores são novos, anônimos ou estão navegando fora dos padrões habituais. Para esses compradores, a participação no grupo oferece um tipo diferente de personalização, uma personalização baseada em quem o comprador é, não no que ele fez.

Um comprador vegano que procura por "chocolate" deve ver o chocolate vegano listado nas primeiras posições. Um comprador que segue as práticas halal e busca por "snacks" deve ver opções certificadas halal em destaque. Um consumidor preocupado com a saúde que busca por "iogurte" deve ver as opções probióticas em destaque.

Agrupamentos como políticas, não como tags de produto

Os produtos já possuem atributos normais, incluindo campos como dietary_restrictions: ["vegan"] ou dietary_restrictions: ["halal"]. A questão é onde reside a lógica que conecta o grupo de compradores a esses atributos do produto.

A abordagem mais ingênua seria codificar esse mapeamento na camada da aplicação ou no modelo de busca: se o usuário for vegano, adicione um impulso à dietary_restrictions: "vegan". Mas este é o mesmo emaranhado de código na camada de aplicação descrito na Parte 1, e cria o mesmo atrito operacional: adicionar um novo grupo ou alterar o que um agrupamento significa exige uma alteração no código.

O plano de controle governado mantém a lógica de agrupamento no mecanismo de políticas. Uma política de agrupamento faz a ponte entre duas coisas: a associação de um comprador a agrupamento (por exemplo, "vegano") e um atributo de produto (por exemplo, dietary_restrictions: “vegan”). A política define a conexão: quando um comprador do grupo vegano pesquisa, priorize produtos onde dietary_restrictions incluir "vegano".

Como a lógica de coorte está no motor de políticas e não no código do aplicativo, isso significa:

• Adicionar um novo grupo é algo que pode ser feito criando uma nova política; não é necessário reindexar produtos.

• As políticas de agrupamento usam o mecanismo de regras completo: elas podem adicionar filtros, aplicar reforços flexíveis, expandir sinônimos, alterar a estratégia de recuperação ou qualquer outra ação que uma política possa realizar.

• O comportamento da agrupamento é gerenciado por meio da mesma admin UI de todas as outras políticas: um comerciante pode criar, testar e promover políticas de agrupamento por meio do fluxo de trabalho Autor → Testar → Promover descrito na Parte 2.

Exemplo de política de coorte vegana

Um merchandiser cria uma política de coorte com as seguintes características:

• Agrupamentos: ["vegan"].

• Critérios de correspondência: corresponde a qualquer consulta (ou a uma categoria de produto específica).

Ação: Impulso suave no dietary_restrictions: "vegan" com um peso de impulso de 2.

Como funciona a ativação por coorte

Cada documento de política tem um campo cohorts. Políticas universais que se aplicam a todos os compradores, independentemente do grupo, podem deixar este campo em branco, e estes serão internamente atribuídos um valor de "_all" pelo plano de controle. Políticas específicas de agrupamento armazenam os nomes de agrupamento-alvo, como ["vegan", "kosher", “sweet_tooth”].

Quando uma solicitação de busca inclui um perfil de usuário, o plano de controle cria um filtro simples de terms para a consulta do percolador:

Esse filtro único inclui todas as políticas universais mais as políticas específicas de agrupamento do usuário. O sentinela _all limpa esse filtro de inclusão: não são necessárias consultas must_not ou exists para lidar com o caso em que uma política não possui restrição de agrupamento.

O percolador então avalia as correspondências de política normalmente. A única diferença é que o conjunto de políticas do candidato foi restringido àquelas relevantes para os grupos desse cliente. Tudo o que vem depois (transformações em cascata, resolução de conflitos por campo, rastreamento de frases consumidas) funciona de forma idêntica ao fluxo não personalizado descrito nas Partes 3 e 4.

Resultados de usuários não veganos (padrão) ao buscar por "chocolate"

Quando um usuário não vegano pesquisa por chocolate, não há um aumento de agrupamento vegano aplicado aos seus resultados. Eles viam chocolates não veganos entre os principais resultados, conforme segue:

Resultados da política de agrupamento vegana ao buscar por "chocolate"

Quando um comprador vegano busca por "chocolate", essa política está incluída no conjunto de candidatos a percolador. Há correspondência e o plano de controle aplica um leve impulso aos chocolates certificados veganos. O aumento é multiplicativo: chocolates veganos têm uma classificação mais alta, mas chocolates não veganos não são totalmente excluídos porque o filtro acima é definido como leve impulso, que descrevemos em detalhes na Parte 3 desta série.

No entanto, se o comprador buscar explicitamente por "chocolate ao leite Hershey", o impulso para produtos veganos ainda se aplica, mas pode ser superado pela relevância textual mais forte dos produtos de chocolate ao leite Hershey.

Um consumidor que não faz parte do grupo vegano e busca pela mesma consulta nunca vê a política de "grupo vegano"; ela não está no conjunto de resultados possíveis. A camada de governança é idêntica; somente o conjunto de políticas ativo é diferente.

Agrupamentos com histórico de compras

Um consumidor vegano com um extenso histórico de compras recebe ativação de políticas específicas para o grupo de clientes veganos, além de impulso no histórico de compras. Para compradores novos ou anônimos, a simples associação implícita a um grupo proporciona uma personalização significativa sem exigir quaisquer dados comportamentais (por exemplo, talvez um usuário anônimo tenha pesquisado apenas produtos veganos e, portanto, o classificamos como membro do grupo vegano). Um comprador que se identifica como halal durante a criação da conta recebe imediatamente resultados personalizados halal na primeira busca.

Como as camadas de personalização são compostas

A ordem de nidificação das function_score camadas importa. Do mais interno ao mais externo:

1. Consulta básica: a palavra-chave ou a correspondência semântica com consultas nomeadas (fulltext_match, title_phrase_match).

2. Camada de política de governança: Filtros rígidos como cláusulas bool.filter, reforços suaves como funções function_score (Partes 3 e 4).

3. Impulsionamentos de sinal de negócio: aumento de margem e popularidade (que exploraremos na Parte 7).

4. O histórico de compras aumenta: a camada mais externa function_score.

Essa ordenação garante que a governança controle o conjunto de resultados (o que aparece), os sinais de negócios ajustam a classificação dentro desse conjunto (o que aparece primeiro da perspectiva do varejista) e o histórico de compras ajusta ainda mais a classificação com base no comportamento individual (o que aparece primeiro da perspectiva do comprador). Cada camada envolve a camada anterior multiplicativamente, de modo que os efeitos se acumulam em vez de entrarem em conflito.

O que isso significa operacionalmente

A personalização por meio do plano de controle governado preserva todas as propriedades operacionais descritas nas Partes 1 e 2:

• Mudanças de implantação zero. As políticas de agrupamento são criadas, testadas e promovidas através da UI. Adicionar um novo agrupamento alimentar ou ajustar um impulso de peso não requer alterações no código nem envolvimento de engenharia.

• Auditabilidade. Cada política de agrupamento é um documento discreto e com uma versão. Quando um comerciante pergunta: "Por que os produtos veganos estão classificados mais alto para esse usuário?", a resposta é uma política específica com prioridade específica, visível no painel de fazer debug junto com todas as outras políticas que foram acionadas por aquela consulta.

• Resolução de conflitos. As políticas de agrupamento participam da mesma resolução de conflitos por campo descrita na Parte 3. Se o impulso de categoria de uma política de agrupamento entrar em conflito com a substituição de categoria de uma política de campanha, o conflito será resolvido deterministicamente pela mesma estrutura de prioridade e estratégia, sem necessidade de tratamento especial.

• Mensurabilidade. Como as políticas de coorte são discretas e podem ser alternadas individualmente, seu impacto nas taxas de conversão, cliques e adição ao carrinho pode ser medido de forma independente, assim como qualquer outra política do sistema.

O que vem a seguir nesta série

O próximo post explora outra dimensão do plano de controle governado: como o aumento de margem e popularidade pode ser ajustado por consulta por meio de políticas, transformando a otimização econômica em uma decisão de governança, em vez de uma configuração estática.

Veja a Parte 7: otimização econômica governada por consulta: impulso de margem e popularidade por consulta

Coloque em prática o buscar governado de comércio eletrônico

Os padrões de personalização descritos neste post (impulsionamento do histórico de compras individual e ativação de políticas com reconhecimento de agrupamento) foram projetados e desenvolvidos pela Elastic Services Engineering como parte de nosso acelerador de busca de e-commerce reutilizável. Ambos os mecanismos se integram à arquitetura do plano de controle governado descrita ao longo desta série. Entre em contato com o Elastic Professional Services.

Participe da discussão

Tem dúvidas sobre governança de buscar, estratégias de recuperação ou arquitetura de buscar para e-commerce? Participe da conversa mais ampla da comunidade Elastic.

Da arquitetura à implementação

A parte 3 descreveu a arquitetura do plano de controle: correspondência reversa como uma primitiva de pesquisa, documentos de política que separam a correspondência da ação e transformações em cascata que compõem várias políticas em um único plano de execução. Este artigo explora na prática o recurso do Elasticsearch que viabiliza a busca de políticas: a consulta percolator.

O percolador é uma solução natural para governança porque inverte a direção da busca exatamente da forma que um plano de controle precisa. Este post percorre a implementação passo a passo, começando com uma explicação clara do que o percolador faz e por que isso importa, e depois passando pelo design do índice, armazenamento de políticas, avaliação em tempo de consulta e composição de múltiplas políticas.

Como funciona a busca normal

Em um sistema de comércio eletrônico, você pode ter centenas de milhares ou milhões de documentos de produto contendo campos como title, category e price. Quando um usuário busca documentos correspondentes, você está pedindo ao Elasticsearch para comparar a string de busca do usuário com um ou mais campos armazenados nesses documentos de produto. O analisador padrão do Elasticsearch, o analisador padrão, converte texto em minúsculas e o divide em tokens. Uma busca por "laranjas" corresponde a "Laranjas" por causa da conversão para minúsculas. Com um analisador sensível à linguagem que inclui a redução ao radical, ele também corresponde a "laranja" porque ambas as formas se reduzem ao mesmo radical. Por exemplo, a seguinte consulta de correspondência retorna documentos que têm "laranja" ou "laranjas" em seu campo “title”.

Então, para a consulta acima, o Elasticsearch retorna os documentos do produto cujo campo title corresponde a "laranjas", que podem incluir resultados como "Pasta de Fruta de Laranja", "Suco de Laranja", "Laranjas Suculentas", "Marmelada de Laranja" e assim por diante. O ponto principal a ser lembrado é que o Elasticsearch é comumente usado para comparar uma string de busca com documentos e retornar os documentos que correspondem à string de busca.

O problema da governança: encontrar políticas relevantes antes de buscar produtos

Conforme estabelecido nas Partes 1 a 3, um sistema de busca governado não envia a string de busca do usuário diretamente para o catálogo de produtos. Primeiro, verifica se alguma política se aplica àquela string de busca.

Um comerciante decidiu que, quando alguém busca exatamente por "laranjas", os resultados devem ser restritos à categoria Laranjas, eliminando suco de laranja, geleia de laranja e refrigerante de laranja. Essa decisão de negócios é armazenada como uma política. Quando um usuário digita "laranjas", o plano de controle precisa encontrar essa política, ler as instruções e modificar adequadamente a busca no catálogo de produtos. Para isso, o plano de controle precisa descobrir quais políticas armazenadas são relevantes para essa string de busca.

Uma implantação corporativa pode ter centenas ou milhares dessas políticas. Verificá-las uma por uma com a lógica if/else é o antipadrão da camada de aplicação descrito na Parte 2. O que precisamos é de uma maneira de armazenar todas essas políticas em um índice e encontrar instantaneamente aquelas que correspondem a uma determinada string de busca. É aqui que entra o percolador.

Invertendo a direção: O percolador

Anteriormente mencionamos que, em uma busca normal, o Elasticsearch é comumente usado para comparar uma string de busca com documentos e retornar os documentos que contêm essa string de busca.

O percolador inverte isso. Com um percolador, você tem um índice em que cada documento armazena um padrão de consulta e, em seguida, uma string de busca recebida é verificada em relação a essas consultas armazenadas para determinar quais desses padrões de consulta armazenados foram acionados.

Para governança, os "padrões de consulta armazenados" são políticas. Cada política contém um padrão que descreve o tipo de string de busca que ela deve corresponder. Por exemplo, a string de busca corresponde exatamente a "laranjas" ou também contém "azeite de oliva"? A string recebida é o texto de busca do usuário, que chega no momento da consulta e precisa ser verificada contra todos os padrões de políticas armazenados. Isso é abordado em um vídeo relacionado ao PRISM em 4:09.

Passo a passo: como uma busca por "laranjas" encontra sua política

A política

Um comerciante criou uma política que corresponde ao caso de um usuário buscar exatamente por "laranjas" sem outras palavras. Uma vez que o percolador encontra correspondência, o restante do documento inclui as regras que o plano de controle usará para construir a consulta do Produto; neste exemplo, uma das regras é restringir (filtrar) os resultados à categoria Frutas.

O campo percolator contém o padrão que define quando essa política deve ser acionada. Nesse caso, ele corresponde à frase "START oranges END". Os campos rule_type e rule_args definem o que a política deve fazer quando for acionada. Os tokens START e END são marcadores de limite, que explicaremos em breve.

Você pode ver como uma política é criada na interface do usuário do PRISM Studio às 2:52 do vídeo relacionado do PRISM.

O usuário realiza a busca.

Um comprador digita "laranjas" na barra de busca.

O plano de controle verifica se há políticas correspondentes.

Antes de buscar o catálogo de produtos, o plano de controle intercepta a string de busca do usuário, envolve-a em marcadores de limite e a envia para o percolador:

A string "START oranges END" é verificada contra todos os padrões de políticas armazenados. Internamente, o Elasticsearch executa os padrões de políticas armazenados contra essa string e retorna as que coincidem. Esse é o percolador. A string de busca do usuário foi verificada em relação a todos os padrões de políticas armazenados, e os que coincidiam eram retornados. Não há cadeias if/else. Sem avaliação sequencial. O índice cuida da correspondência.

O plano de controle aplica a política

O plano de controle lê as ações das políticas correspondentes. A política acima instrui o plano de controle a restringir os resultados à categoria Frutas. O plano de controle constrói a consulta final do Elasticsearch com base no catálogo de produtos da seguinte forma:

O usuário buscou por "laranjas". O catálogo de produtos recebe uma consulta para "laranjas" restrita à categoria Frutas. Por causa dessa limitação, suco de laranja, geleia de laranja e refrigerante de laranja são excluídos.

Por que "marmelada de laranja" NÃO aciona a política das laranjas

Suponha que outro usuário busque por "geleia de laranja". O plano de controle encapsula a string e a percola: "START orange marmalade END". O padrão da política de laranjas é match_phrase: "START oranges END". A política de laranjas não corresponde; portanto, ela não é aplicada, e os resultados não ficam restritos à categoria Frutas.

Este é o propósito dos marcadores de limite START e END. Sem elas, uma política que corresponde à palavra "laranjas" poderia acidentalmente ser acionada em uma consulta como "orange marmalade". Ao envolver a string de busca do usuário com START e END e incluir esses marcadores no padrão da política, garantimos que a política só seja acionada quando "oranges" for a string completa de busca, sem outras palavras. Isso corresponde tanto à intenção dos compradores quanto à do comerciante.

Uma segunda política: "azeite de oliva" no campo com redução ao radical

Nem toda política precisa de uma correspondência exata de string. A política do "azeite de oliva" corresponde a um campo com redução ao radical, então ela dispara independentemente de pequenas variações na forma das palavras:

O padrão dessa política corresponde a query.stemmed em vez de query. Quando a string de busca do usuário chega, ela é armazenada em um campo query (o texto exato) e em um campo query.stemmed (analisado com um analisador de redução ao radical que reduz as palavras aos seus radicais, de modo que "olivas" e "oliva" são reduzidos ao mesmo radical, assim como "azeites" e "azeite"). O padrão da política é verificado em relação à versão com redução ao radical da string, portanto, ela é acionada independentemente de pequenas variações na forma da palavra.

Os marcadores de limite START e END também funcionam no campo com redução ao radical, garantindo que essa política só seja acionada quando "azeite de oliva" for toda a string de busca, e não quando aparecer como parte de algo mais longo.

O restante deste artigo aborda os detalhes de implementação que tornam isso pronto para uso em produção: o mapeamento de índice que suporta ambos os modos de correspondência, como os destaques direcionam a remoção de frases e o rastreamento de frases consumidas, e como várias políticas conflitantes se combinam em um único plano de execução.

O mapeamento do índice de políticas

O índice de política precisa de um campo percolador para manter padrões de consulta armazenados e um campo de texto que espelhe a estrutura da string de busca recebida com a qual o percolador fará a correspondência. O mapeamento abaixo é simplificado para maior clareza. Uma implantação de produção é mais complexa, usando analisadores personalizados para lidar com marcadores de limite, correspondência de padrões variáveis (por exemplo, reconhecer que "menos de US$ 4" contém um valor de moeda) e outros tipos de análise.

O índice é denominado policies porque cada documento representa uma política governada completa, conforme definida na Parte 2. Isso inclui critérios de correspondência, ação, prioridade e metadados. Os campos rule_type e rule_args contêm o componente de ação da política, que contém as instruções que o plano de controle usará para compor a consulta para execução no catálogo de produtos.

O campo query é a string contra a qual o percolador faz a correspondência. Possui duas variantes: uma versão exata e uma versão com redução ao radical. Quando a string de busca do usuário chega, ela é inserida neste campo no índice temporário em memória. Políticas que correspondem a query veem a string exata; políticas que correspondem a query.stemmed veem a versão com redução ao radical.

Percolação com destaques, filtragem e ordenação

Os exemplos simples acima mostraram pedidos mínimos de percolação. Na prática, o plano de controle adiciona destaque, filtra políticas desativadas e ordena por prioridade:

A configuração de destaque usa "query" como chave de campo com "query.stemmed" em matched_fields. Isso diz ao destacador unificado do Elasticsearch para retornar destaques no campo query principal, mas também para considerar correspondências do subcampo query.stemmed ao determinar quais tokens destacar. Isso é o que permite que uma política que corresponde ao campo com redução ao radical ainda produza destaques precisos no texto original, que o plano de controle precisa para remoção e rastreamento de frases consumidas.

O filtro enabled: true garante que as políticas desativadas sejam ignoradas. A prioridade sort garante que as políticas de maior prioridade sejam retornadas primeiro, para que o plano de controle possa processá-las na ordem correta para transformações em cascata. O campo highlight é a adição mais importante; ela nos diz exatamente quais palavras na string de busca do usuário acionaram cada partida.

A resposta para uma busca por "azeite de oliva" pode ser a seguinte:

Por que os destaques são importantes

Observe o destaque na resposta: "<em>START olive oil END</em>". O Elasticsearch nos diz exatamente quais palavras na string de busca do usuário fizeram a política corresponder. Isso não é cosmético. Os metadados de destaque determinam dois comportamentos críticos subsequentes:

Remoção de frases. Algumas políticas precisam remover o texto correspondente da string de busca antes de construir a consulta do catálogo de produtos. Por exemplo, uma política que corresponda a "barato" remove essa palavra e a converte em um filtro de preço. O destaque identifica exatamente qual trecho da string de busca correspondeu à política, para que o sistema saiba o que remover.

Rastreamento de frases consumidas. Conforme descrito na Parte 3, quando várias políticas correspondem à mesma string de buscar, uma política de prioridade mais alta pode remover palavras que também foram correspondidas por uma política de prioridade mais baixa. Ao comparar o destaque de cada política com a string de busca atual (em evolução), o sistema pode detectar que uma frase foi consumida e ignorar a política de menor prioridade. Isso evita o processamento duplo e garante um comportamento determinístico.

Você pode saber mais sobre como os destaques funcionam neste artigo.

Da percolação ao plano de execução

O percolador retorna um conjunto de políticas correspondentes. Mas como a Parte 3 descreveu, a pesquisa é apenas metade da história. A outra metade é compor essas correspondências em um plano de execução coerente. Veja como fica para uma consulta concreta.

Exemplo resolvido: "Chocolate barato" durante uma campanha de Natal

Suponha que o sistema tenha duas políticas ativas: a política "Chocolate barato" (prioridade 210) e a política "Chocolates de Natal" (prioridade 300), ambas descritas em detalhes na Parte 3.

Etapa 1: Percolação. O usuário busca por "chocolate barato". O plano de controle encapsula a string de busca como "START cheap chocolate END" e a envia para o percolador. Duas políticas coincidem: o padrão da política "chocolate barato" corresponde à expressão "chocolate barato"; e o padrão da política de "chocolates de Natal" corresponde ao "chocolate" pelo campo com redução ao radical.

Etapa 2: Ordenação por prioridade. O percolador retorna ambas as políticas, ordenadas por prioridade em ordem decrescente. A política de "chocolates de Natal" (300) é processada primeiro, seguida pela política de "Chocolate barato" (210).

Etapa 3: Aplicação da transformação em cascata. Este é o modelo initial state → [Policy A] → state' → [Policy B] → state'' → execution plan da Parte 3.

A política "chocolates de Natal" (prioridade 300) aplica-se primeiro:

• Adiciona um filtro rígido por categoria: "Comidas e bebidas de Natal", "Doces de Natal".

• Adiciona um filtro de preço: menos de US$ 7.

• Adiciona um impulso leve na categoria: "Calendários do Advento" (3x).

A política "Chocolate barato" (prioridade 210) é a próxima a ser aplicada ao estado modificado:

• Tenta adicionar um filtro rígido de categoria: "Chocolates", "Chocolates ao leite"; mas a política de Natal já definiu esse campo com on_conflict: override, então as categorias de chocolate barato foram descartadas.

• Tenta adicionar um filtro de preço: US$ 2, a política de Natal definiu on_conflict: restrict para o preço, e US$ 2 é mais restritivo do que US$ 7, então US$ 2 vence.

• Remove "barato" da string de busca.

Etapa 4: Criação da consulta do Elasticsearch. O plano de controle monta o plano de execução em uma única consulta Elasticsearch contra o catálogo de produtos:

A string original de busca era "chocolate barato". A consulta que chega ao catálogo de produtos é um plano de recuperação governado e orientado pela intenção: a palavra "barato" foi consumida e convertida em uma restrição de preço, os resultados são restritos a categorias sazonais de Natal, os produtos de calendários do Advento recebem um impulso de classificação, e o limite de preço reflete o valor mais restritivo da política de menor prioridade. Toda transformação é determinística, rastreável e explicável.

Para uma visão geral rápida sobre como esses multiplicadores interagem com a pontuação básica do BM25, consulte 8:45 no vídeo PRISM relacionado, onde discutimos brevemente os aumentos multiplicativos.

Por que isso escala

O percolador é eficiente para este caso de uso devido à assimetria: um sistema de comércio eletrônico empresarial pode ter milhões de produtos, mas apenas centenas ou milhares de políticas de governança. O percolador está verificando uma string de busca recebida contra esse conjunto de padrões de política armazenadas, não escaneando o catálogo completo de produtos. O custo é proporcional ao número de políticas, e o Elasticsearch aplica otimizações internas (indexação de termos de padrões de consulta armazenados, curto-circuito lógico) para manter a correspondência rápida.

Adicionar uma nova política é apenas indexar um novo documento. Desativar um é apenas uma atualização de campo. Sem alterações de código, sem implantações, sem reinicializações.

Da pesquisa à recuperação governada

O percolador fornece a primitiva de correspondência reversa rápida que torna a arquitetura do plano de controle da Parte 3 viável em grande escala. Políticas são dados que são armazenados e indexados, e eficientemente comparados com as strings de busca recebidas. O plano de controle compõe políticas correspondentes em um plano de execução governado por meio da transformação em cascata e da resolução de conflitos por campo descritas na Parte 3. E o motor de recuperação executa o plano de execução governado contra o catálogo de produtos.

O resultado é um sistema onde um comerciante pode criar uma nova política sem tocar no código da aplicação, testá-la contra consultas representativas, promovê-la para produção e imediatamente ver o efeito. O percolador agiliza a pesquisa de políticas; o plano de controle torna a composição da política determinística; e o fluxo de trabalho governado torna todo o processo seguro.

O que vem a seguir nesta série

O próximo post desta série estende o plano de controle governado para novos territórios. Ele introduz uma arquitetura de busca em múltiplos níveis, explicando como orquestrar uma recuperação rigorosa, relaxada e semântica, mantendo a estabilidade da paginação e das facetas.

Coloque em prática o buscar governado de comércio eletrônico

O plano de controle baseado em percolador descrito neste post — desde mapeamentos de índice e marcadores de limite até o rastreamento de frases com base em destaques e a composição de políticas em cascata — foi desenvolvido pela Elastic Services Engineering como parte de nossos aceleradores de busca de comércio eletrônico reutilizáveis. Todos os exemplos de consultas e estruturas de políticas mostrados aqui são provenientes de um sistema em funcionamento validado com base em catálogos de produtos em escala empresarial.

Se você deseja implementar um plano de controle governado e orientado por políticas no Elasticsearch, o Elastic Services pode ajudá-lo a chegar lá mais rapidamente. Entre em contato com o Elastic Professional Services.

Participe da discussão

Tem dúvidas sobre governança de buscar, estratégias de recuperação ou arquitetura de buscar para e-commerce? Participe da conversa mais ampla da comunidade Elastic.

Por que a interpretação de consultas é frequentemente um desafio

O armazenamento de políticas como código (blocos if/else na camada de aplicação) produz dezenas de milhares de linhas de lógica frágil que não possui indexação para recuperação eficiente de políticas no momento da consulta. A iteração é lenta (uma única alteração de comportamento de consulta pode exigir um ciclo de implantação de seis semanas), a responsabilidade não é clara (por que os resultados foram alterados?) e os usuários corporativos não podem modificar o comportamento de busca sem o envolvimento da engenharia. Isso é mostrado no lado esquerdo da imagem a seguir:

O armazenamento de políticas como dados em um índice Elasticsearch é mostrado no lado direito da imagem acima. Essa abordagem resolve todos os problemas associados à lógica de resolução de consultas codificadas. No entanto, para que isso funcione, você precisa determinar rapidamente quais políticas correspondem à consulta do usuário e como os conflitos devem ser resolvidos. É aqui que entra o plano de controle governado.

O padrão do plano de controle

Um plano de controle governado fica entre a consulta bruta do usuário e uma recuperação do Elasticsearch. Ele recebe o texto do usuário como entrada, e sua saída é um plano de execução que inclui filtros, impulsionamentos e decisões de roteamento de recuperação.

Um pipeline de plano de controle consiste em:

1. Consulta do usuário: o usuário digita uma string do que está procurando, como "laranjas" ou "presente para o avô".

2. Consulta de política: compare a consulta do usuário com o índice de políticas.

3. Retorno das políticas correspondentes: as políticas que correspondem à consulta do usuário são retornadas do índice de políticas.

4. Aplicação de políticas: o plano de controle analisa as políticas retornadas e compõe as políticas correspondentes em um único plano de execução coerente que inclui filtros, reforços, substituições e salvaguardas, e que aplica o método de recuperação apropriado (por exemplo, lexical, semântico ou híbrido).

5. Execução: a consulta modificada do Elasticsearch, consciente da intenção é passada para a aplicação para ser executada em um índice de catálogo de produtos.

6. Explicação (opcional): além de criar uma consulta que fornece resultados alinhados aos negócios e às intenções, o plano de controle fornece uma carga útil opcional de explicabilidade para mostrar quais políticas foram acionadas e como elas foram combinadas.

Encontrar quais políticas devem ser aplicadas ao termo de busca de um usuário requer uma primitiva de correspondência reversa rápida, que resolvemos com a consulta de percolador. Após recuperar as políticas relevantes, combinar várias políticas correspondentes em um plano de execução unificado requer uma estrutura de julgamento: prioridades, estratégias de conflito, rastreamento de frases consumidas e transformações em cascata que aplicam políticas em sequência, em vez de independentemente. Além disso, a tecnologia de recuperação mais apropriada precisa ser selecionada (por exemplo, BM25 para "laranjas" versus busca semântica para "presente para o avô").

Consulta de política: checar a consulta antes de buscar produtos

Quando um comprador digita uma consulta, um sistema de busca com plano de controle regulado não envia essa consulta diretamente para ser executada no catálogo de produtos. Primeiro, a consulta é verificada em relação a um conjunto de políticas armazenadas e modificada para refletir a intenção da consulta e as prioridades de negócio.

Estrutura da política

Cada política é um documento simples que define duas coisas:

• Critérios de correspondência: qual texto de consulta deve acionar esta política. Isso poderia ser uma frase exata, uma única palavra, um padrão ou uma combinação.

• Ação: o que você deve fazer quando a política for acionada. Isso pode ser a aplicação de um filtro de categoria, excluindo produtos, extraindo uma restrição de preço ou mudando a estratégia de recuperação.

O sistema encontra todas as políticas correspondentes, as compõe em um plano de execução e só então executa a busca pelo produto. Juntas, as políticas agem como um atendente de loja experiente que entende o que você procura e leva você até o corredor certo.

O padrão de política

Os primeiros artigos desta série apresentaram exemplos de políticas em ação: restringir "laranjas" à categoria de produtos agrícolas, tratar "sem amendoim" como uma exclusão e direcionar "presente para o avô" para a recuperação semântica. O ponto arquitetônico fundamental é que, em cada caso, a consulta é verificada em relação às políticas armazenadas antes do início da busca pelo produto. As políticas determinam quais restrições aplicar, qual texto modificar e qual estratégia de recuperação utilizar. A consulta ao catálogo de produtos ocorre após a aplicação das políticas e a criação de uma nova consulta reescrita.

Por que isso é rápido

Um sistema de e-commerce corporativo pode ter milhões de produtos, mas apenas centenas ou milhares de políticas. A etapa de pesquisa de políticas consiste em buscar em um pequeno índice curado, não no catálogo completo de produtos, e por isso é rápida. E como as políticas são armazenadas como dados em seu próprio índice, um responsável por merchandising que adiciona uma nova política não toca no código da aplicação, e um engenheiro que otimiza a busca do produto não toca no índice da política. As duas preocupações evoluem independentemente.

Os exemplos acima descrevem o que acontece conceitualmente. Nos bastidores, a pesquisa de políticas é implementada usando o tipo consulta de percolador do Elasticsearch, criado especificamente para esse tipo de padrão: comparar o texto recebido com um conjunto de consultas armazenadas. A Parte 4 desta série oferece uma análise prática e aprofundada da implementação do percolador, incluindo mapeamentos de índice, marcadores de limite e rastreamento de frases orientado por destaque. Com o mecanismo de pesquisa abordado em profundidade na Parte 4, vamos ver o que um documento de política realmente contém e como o plano de controle compõe várias políticas em um único plano de execução.

Exemplo de políticas

Agora que vimos o que as políticas fazem conceitualmente, vamos analisar o que elas realmente contêm. As duas políticas abaixo foram projetadas para conflitar intencionalmente, o que demonstrará o sistema de resolução de conflitos descrito nas seções seguintes.

Chocolate barato

A política mostrada abaixo detecta se um usuário enviou uma busca contendo a expressão "chocolate barato". Nesse caso, os resultados são restritos às categorias “Chocolates” e “Chocolates ao leite”. Esta política também aplica um filtro de preço de $ 2. Além disso, observe que essa política tem uma prioridade de 210; voltaremos a isso quando discutirmos a resolução de conflitos com mais detalhes.

As configurações do modo de filtro e da estratégia de conflito mostradas aqui (hard_filter, soft_boost, restrict, override) são explicadas em detalhes na seção de resolução de conflitos abaixo.

Quando a política acima é ativada, a busca por “chocolate barato” respeita o filtro de preço de $2 e restringe os resultados às categorias “Chocolates” e “Chocolates ao leite”. Exemplos de resultados são mostrados abaixo:

Chocolate de Natal

A política mostrada abaixo é um exemplo de uma política poderia ser aplicada no Natal. Este exemplo restringe os resultados a “comidas e bebidas de Natal” e “Doces de Natal”, impulsiona quaisquer produtos que também estejam na categoria “Calendários do Advento” e aplica um filtro de preço de menos de $ 7 para focar em itens sazonais acessíveis. Além disso, observe que esta política tem uma prioridade de 300. Voltaremos a isso quando discutirmos a resolução de conflitos em mais detalhes.

Quando a política acima é ativada sem políticas conflitantes, uma busca por "chocolate" respeita o filtro de preço de $ 7 e restringe os resultados às categorias "Comidas e bebidas de Natal" e "Doces de Natal" e aumenta todos os produtos marcados como "Calendários do Advento". Exemplos de resultados são mostrados abaixo:

Combinando políticas correspondentes

A consulta de políticas descrita acima é apenas metade da história. A outra metade é o que acontece quando várias políticas correspondem à mesma consulta.

Em qualquer implantação não trivial, uma única consulta rotineiramente acionará várias políticas ao mesmo tempo. "Chocolate barato" vai combinar com as duas políticas que demonstramos acima. Cada política está correta isoladamente. O desafio é compô-los em um único plano de execução coerente, sem contradições, sem contagem dupla e sem que uma política desfaça silenciosamente o trabalho de outra.

Isso não é um problema de busca; é um problema de julgamento. O sistema deve decidir:

• Ordem de aplicação: se uma política de negação remover "sem amendoim" da consulta, a política de preço ainda verá o texto original ou o texto modificado?

• Conflitos de filtros: se duas políticas estabelecem tetos de preços diferentes, qual delas vence? O perdedor é descartado silenciosamente ou se degrada de forma suave para um aumento leve?

• Propriedade da frase: Se duas apólices corresponderem à mesma palavra e a primeira já a tiver consumido, a segunda ainda deverá ser acionada?

Uma implementação ingênua (aplicar todas as políticas correspondentes de forma independente e mesclar os resultados) falha assim que as políticas interagem. A arquitetura precisa de um modelo explícito de como as políticas se compõem. As próximas duas seções descrevem esse modelo: um framework de prioridade e resolução de conflitos e um modelo de transformação em cascata que torna a interação entre políticas determinística.

O principal insight é que a aplicação de políticas não é um conjunto de operações independentes; é uma transformação em cascata. Cada política recebe o estado de reescrita produzido por todas as políticas de maior prioridade e o transforma ainda mais:

estado inicial → [Política A] → estado' → [Política B] → estado'' → ... → plano de execução

O estado contém o texto da consulta reescrito, filtros acumulados, intenção atual e quaisquer expansões de sinônimos. Uma política de alta prioridade pode remover texto da consulta, e toda política subsequente vê a consulta modificada, não a original. O contexto se acumula. A ordem importa.

Precedência e resolução de conflitos: O determinismo importa

As estratégias específicas de conflito são uma escolha de design. Diferentes organizações podem resolver conflitos de forma diferente, dependendo das necessidades de seus negócios. A abordagem a seguir ilustra o tipo de estrutura de julgamento que um plano de controle precisa. O importante não são essas estratégias específicas, mas que o sistema tenha estratégias explícitas e determinísticas, em vez de permitir que os conflitos sejam resolvidos por meio de interações imprevisíveis.

Pedido prioritário

As políticas são ordenadas por prioridade (maior primeiro). Quando várias políticas correspondem à mesma consulta, elas são aplicadas em ordem de prioridade. Se duas políticas tentarem definir o mesmo campo de filtro, a estratégia declarada pela política de maior prioridade para esse campo terá precedência. Se houver múltiplas políticas acionadas com a mesma prioridade, então a política com o ID mais alto recebe precedência (como se tivesse uma prioridade maior); essa escolha garante um comportamento determinístico quando surgem conflitos.

Resolução por campo, não por política

Um princípio crítico de design: a resolução de conflitos opera por campo (por exemplo, marca, categoria ou descrição), não por política. Quando duas políticas produzem filtros que se sobrepõem em campos específicos, apenas esses campos específicos são afetados pela estratégia de resolução de conflitos, e a estratégia de resolução é definida pela política de correspondência de maior prioridade. Campos não conflitantes de ambas as políticas sobrevivem intactos.

Isso é importante porque a alternativa de uma abordagem por política forçaria o sistema a aceitar ou rejeitar uma política inteira quando apenas um de seus campos entrasse em conflito.

A resolução por campo preserva a quantidade máxima de informação útil sobre restrições.

Três configurações por campo de filtro

Cada campo de filtro em uma política tem três configurações independentes:

Modo de filtro: como o filtro é aplicado quando não há conflito.

• hard_filter (padrão): aplicado como uma cláusula Elasticsearch bool.filter. Isso é útil para excluir completamente produtos não relacionados. Por exemplo, restringir a busca por "laranjas" à categoria de hortifruti elimina resultados como suco de laranja e geleia de laranja. Documentos que não correspondem são completamente excluídos dos resultados.

• soft_boost: aplicado como um Elasticsearch function_score peso com um boost_weight configurável. Documentos que coincidem recebem um aumento de ranking, mas documentos que não correspondem não são excluídos. Isso é útil para algo como impulsionar uma marca, sem excluir outras marcas.

Estratégia de conflito

O que acontece quando uma política de menor prioridade define o mesmo campo:

• override: o valor dessa apólice de alta prioridade vence; o valor de menor prioridade é completamente eliminado. Válido para todos os tipos de campo.

• restrict: pegue o valor numérico mais restritivo (por exemplo, o teto inferior para preço__max, the higher floor for price__min). Válido somente para campos de intervalo numérico.

• mergeCombine ambos os valores em uma união. Válido apenas para campos não numéricos.

• soft_boost: converta o filtro conflitante para um peso function_score com um boost_weight configurável em vez de um filtro rígido. Para mais detalhes sobre function_score boosting, veja Influenciando o ranking BM25 com boosting multiplicativo no Elasticsearch. Isso é válido apenas para campos sem negação.

Valor: O valor efetivo do filtro (por exemplo, uma lista de categorias, um limite de preço).

Estratégias por tipo de campo: nem todas as estratégias fazem sentido para todos os tipos de campo. Por exemplo, uma exclusão é inerentemente binária, então não pode ser suavemente impulsionada. A tabela a seguir mostra quais estratégias estão disponíveis para cada tipo de campo:

Tipo de campo

Estratégias disponíveis

Padrão

Campos de negação (__not, __match__not)

substituir, mesclar

substituir

Campos de intervalo numérico (__max, __min, __gt, __lt)

restrict, override, soft_boost

restringir

Todos os outros campos (palavra-chave, texto)

soft_boost, sobrescrever, mesclar

soft_boost

Campos de negação não podem ser soft-boosted porque as exclusões são binárias. A conversão de "nunca mostrar enlatados" para "leve restrição a enlatados" altera fundamentalmente a semântica; um produto "enlatado" ainda apareceria, apenas com uma classificação ligeiramente inferior, o que anula o objetivo da exclusão.

Um exemplo concreto: Procurando por "chocolate barato" durante uma campanha de Natal

Suponha que um comerciante tenha criado duas políticas para chocolate que demonstramos anteriormente: uma de menor prioridade para chocolate barato e outra, de maior prioridade, que será ativada durante o Natal. Se ambas as políticas estiverem ativadas, a forma como são combinadas dependerá do modo de filtro e da estratégia de conflito da política de maior precedência. Se ambas as políticas discutidas anteriormente estiverem habilitadas, elas serão combinadas da seguinte forma:

Isso mostra dois conflitos: um em categorias e outro em preço. Vale destacar que a consulta executada após essa transformação tem as seguintes características:

• Somente produtos das categorias “Comidas e bebidas de Natal” e “Doces de Natal” serão exibidos.

• Dentro dessas categorias, se os produtos também forem marcados como "Calendários do Advento", eles terão um aumento de 3 vezes.

• É aplicado um filtro de preço de $2, proveniente da política de menor prioridade (porque a política de maior prioridade especificou “Restringir” em caso de conflito).

• A palavra "barato" é removida, devolvendo apenas produtos que correspondam a "chocolate".

Com ambas as políticas ativadas, o "chocolate barato" retorna resultados semelhantes à imagem mostrada abaixo:

Relaxamento das restrições

Talvez o varejista não queira excluir produtos nas categorias de "Chocolates" e "Chocolates ao leite" durante o Natal. As configurações da política de Natal podem ter ultrapassado e removido inadvertidamente as categorias aplicadas pela política de "chocolate barato". Este é um exemplo que mostra por que pode ser mais desejável combinar políticas de menor prioridade com políticas conflitantes de prioridade mais alta. Por exemplo, poderíamos modificar a promoção de chocolates de Natal para que, em vez de "sobrescrever" no conflito, façamos um ajuste suave. A mudança para essa política seria a seguinte:

Após essa modificação, a execução do pipeline de transformação do rewriter de consultas para "chocolate barato" é a seguinte:

Com o soft boost no conflito, os filtros conflitantes são convertidos em soft boosts em vez de serem descartados. A consulta que será executada no catálogo de produtos após essa transformação possui as seguintes características:

• Como “Em conflito” é especificado como “reforço suave” na política de maior prioridade, os conflitos serão convertidos em reforços da seguinte forma:

  • Os produtos das categorias “Comidas e bebidas de Natal” e “Doces de Natal” receberão um aumento de 1 vez.

  • Produtos das categorias "Chocolates" e "Chocolates ao leite" receberão um aumento de 3x aplicado a eles.

• Como no exemplo anterior, se os produtos também forem marcados como pertencentes à categoria "Calendários do Advento", eles terão sua relevância aumentada em 3 vezes.

• Como no exemplo anterior, é aplicado um filtro de preço para $2.

• A palavra "barato" é removida, devolvendo apenas produtos que correspondam a "chocolate".

Com filtragem relaxada, os resultados são os seguintes:

Substituição de preço por uma política de alta prioridade

Ou talvez o varejista queira permitir que chocolates um pouco mais caros sejam exibidos durante o Natal, aumentando o preço máximo para US$ 7. Para garantir que o preço máximo da política de chocolates de Natal não seja sobrescrito se alguém buscar por "chocolates baratos", podemos definir o modo de conflito do preço como "sobrescrever" em vez de "restringir", da seguinte forma:

Com essa substituição, a consulta por "chocolate barato" ignora o preço máximo definido na "política de chocolate barato" e aplica apenas o preço especificado na "política de chocolates de Natal", da seguinte forma:

Este exemplo é semelhante ao anterior, com a diferença de que o preço máximo é definido como o valor de US$ 7 da política de maior prioridade, porque essa política especificou "Substituir" em caso de conflito. Com o filtro de preços de Natal em primeiro lugar, os resultados são os seguintes:

Essas três variações (override, soft_boost e override on price) demonstram uma propriedade fundamental do sistema: um comerciante pode mudar a forma como duas políticas interagem modificando uma configuração em um único campo dentro de uma única política, sem implantar nenhum código. A estratégia de conflito é a alavanca que controla o comportamento empresarial.

Rastreamento de frases utilizadas

Existe uma forma mais sutil de conflito: duas políticas que correspondem à mesma frase. Se uma política de maior prioridade remover "sem amendoim" da consulta, uma política de menor prioridade que também correspondeu a "sem" não terá mais nada sobre o que agir. O sistema detecta se a frase correspondente não está mais presente na consulta reescrita e ignora a política de menor prioridade.

As políticas de intenção estão isentas do rastreamento de frases consumidas: elas definem a estratégia de recuperação com base na correspondência da consulta original, independentemente do texto removido pelas políticas de maior prioridade.

Juntos, a ordenação prioritária, a resolução de conflitos por campo e o rastreamento de frases consumidas fornecem ao plano de controle um modelo de composição determinística. Com essa base estabelecida, o sistema pode tomar uma decisão de roteamento que seria arriscada sem ela.

A governança torna segura a estratégia de recuperação.

Um insight importante sobre o roteamento para o método correto de recuperação (texto, semântica ou híbrido) é que ele é executado após a governança. Se suas políticas já aplicaram a "categoria de produção", então a recuperação semântica se torna muito menos arriscada porque o conjunto candidato é restrito. Uma busca semântica sobre 500 itens de produto é uma proposta muito diferente de uma busca semântica com mais de 500.000 SKUs. A governança reduz o raio da explosão antes do início da recuperação.

Por exemplo, sem governança, uma consulta semântica por "Frutas ricas em vitamina C por menos de US$ 4", além de frutas, poderia retornar frascos de vitaminas, cenouras e pimentão verde. O plano de controle garante que esses resultados indesejados nem sequer sejam considerados como parte da expansão semântica.

Com essa restrição em vigor, o plano de controle aplica lógica de roteamento pragmática:

• Lexical para consultas de navegação e principais, onde a precisão determinística é importante.

• Semântica para consultas descritivas de descoberta, onde a correspondência de conceitos é útil.

• Híbrido seletivamente, quando as restrições já foram aplicadas e o negócio aceita uma recuperação mais ampla.

da arquitetura à implementação

O plano de controle governado traduz a intenção de negócios em planos de execução determinísticos e componíveis, sem incorporar essa lógica no código do aplicativo. As políticas são dados: correspondidas no momento da consulta, resolvidas por meio de estratégias explícitas de conflito por campo e aplicadas como transformações em cascata que produzem resultados explicáveis. A Elastic Services Engineering desenvolveu e implantou essa arquitetura para equipes de comércio eletrônico corporativo, usando padrões e aceleradores reutilizáveis que reduzem o caminho do conceito à produção. Você pode assistir a uma demonstração da nossa implementação de um plano de controle no YouTube em: Corrigindo a relevância da busca em segundos: Apresentando o PRISM.

O que vem a seguir nesta série

O próximo post aborda a implementação: como o percolador Elasticsearch alimenta a consulta de políticas, incluindo mapeamentos de índice, marcadores de limite, rastreamento de frases guiado por destaque e exemplos concretos de consultas.

Coloque em prática o buscar governado de comércio eletrônico

A arquitetura do plano de controle descrita neste post (resolução de conflitos por campo, transformações de políticas em cascata e roteamento de recuperação com restrição de governança) foi projetada e construída pela Elastic Services Engineering. Cada padrão, captura de tela e pipeline de transformação mostrados nesta série vem de um sistema operacional criado pela Elastic Services Engineering e validado em catálogos de produtos em escala empresarial.

Se você quiser implementar um plano de controle governado e orientado por políticas no Elasticsearch, Elastic Services pode ajudá-lo a chegar lá mais rápido.

Participe da discussão

Tem dúvidas sobre governança de buscar, estratégias de recuperação ou arquitetura de buscar para e-commerce? Participe da conversa mais ampla da comunidade Elastic.

Recuperação lexical (correspondência de texto), recuperação semântica (correspondência de conceitos) e recuperação híbrida (combinação de sinais lexicais e semânticos) não resolvem esses problemas por si só. A recuperação lexical pode retornar qualquer conteúdo que contenha a palavra "laranjas", enquanto a recuperação semântica pura, em uma consulta com alta intenção como "laranjas", pode ampliar o escopo para itens relacionados, como limões ou toranjas. A recuperação híbrida mescla esses sinais lexicais e semânticos, mas ainda não determina se essa consulta deve ser tratada como uma consulta de navegação, quais restrições devem ser impostas ou quais políticas de negócios se aplicam. A lacuna não está na tecnologia de recuperação em si; está na ausência de uma camada de governança que entenda que tipo de consulta é esta e quais restrições devem ser impostas antes de a recuperação começar.

Neste blog, exploramos a governança de busca para e-commerce, por que isso é importante e como uma camada de controle garante uma recuperação previsível e precisa.

O que significa governança na busca para e-commerce

Governança, neste contexto, significa introduzir uma camada de decisão entre a consulta do usuário e o mecanismo de recuperação de dados. Esta camada realiza as seguintes funções:

• Classifica a intenção da consulta: isso é navegação ("laranjas") ou descoberta ("presente para o avô")?

• Aplica restrições comerciais: Quais limites de categoria, regras de elegibilidade, restrições de disponibilidade ou políticas de comercialização se aplicam?

• Caminhos para a estratégia apropriada: deve-se usar recuperação lexical, semântica ou híbrida?

Uma camada de governança determina qual abordagem de recuperação deve ser usada para cada consulta, quais restrições devem ser aplicadas e quais políticas de negócios devem ser aplicadas antes do início da recuperação. É importante não confundir governança com recuperação híbrida: híbrida é uma estratégia de recuperação que combina sinais lexicais e semânticos, enquanto a governança é a camada inicial de decisão que determina se deve ser usada a recuperação lexical, semântica ou híbrida.

O status quo: a implementação da camada de aplicação "spaghetti"

Atualmente, muitos varejistas tentam resolver isso inserindo lógica diretamente na camada de aplicação. Isso geralmente resulta em código espaguete, ou seja, milhares de linhas de instruções if-then fixas no código, regex e templates de busca complexos.

Essa abordagem pode fornecer resultados de busca desejados, como mostrado acima; no entanto, ela cria atritos operacionais significativos:

• Dependência da engenharia: usuários da área de negócios e a equipe de merchandising não conseguem modificar o comportamento de busca sem abrir chamados para a engenharia e enfrentar longos ciclos de implantação, que muitas vezes levam várias semanas.

• Fragmentação: a lógica de busca fica dispersa entre o código da aplicação e os modelos de busca, sendo difícil de explicar ou auditar, tornando arriscado evoluir.

Mesmo quando as equipes reconhecem a necessidade de roteamento, o debate frequentemente se concentra na questão errada: qual método de recuperação escolher.

A falsa escolha: lexical vs. semântico vs. híbrido

As equipes de busca costumam enquadrar o desafio como uma escolha de estratégia de recuperação: lexical/BM25 versus semântica/vetores versus híbrida. Esse enquadramento é compreensível (os métodos de recuperação são importantes), mas ignora a falha mais comum em implantações reais: usar uma única abordagem de recuperação para todas as consultas gera resultados abaixo do ideal.

A busca de comércio é uma combinação de intenções fundamentalmente diferentes:

• Navegação determinística e de alta intenção ("laranjas", "leite", "chocolate sem amendoim", "azeite de oliva barato").

• Descoberta exploratória ("jaqueta para caminhar nas montanhas", "presente para uma criança de 12 anos que gosta de robótica").

• Restrições operacionais (disponibilidade, tamanho, preço, cor).

• Merchandising e campanhas (impulsionar, enterrar, campanhas sazonais).

Quando o sistema encaminha todos esses elementos pela mesma estratégia de recuperação, os resultados frequentemente apresentam erros sistemáticos e previsíveis, devido à falta de governança no modelo operacional. Quando as equipes não percebem isso como uma lacuna de governança, elas recorrem à única ferramenta que possuem: mais ajustes.

Por que o "ajuste de relevância" pode se tornar cíclico

Sem uma camada de roteamento, a "relevância" frequentemente se transforma em um amontoado interminável:

• Por que essa consulta mostra acessórios acima do produto núcleo?

• Por que essa consulta principal passou a exibir itens relacionados de repente?

• Por que os resultados mudaram depois que adicionamos sinônimos, ajustamos analisadores ou ativamos a funcionalidade híbrida?

• Por que a equipe de negócios precisa de um release de engenharia para corrigir uma única consulta?

As equipes respondem com mais ajustes: mais sinônimos, mais impulsos, mais experimentos de reclassificação, mais exceções no código da aplicação. Isso pode funcionar por um tempo, mas frequentemente produz um comportamento frágil, porque o sistema ainda não possui uma camada de decisão explícita para determinar o tipo de consulta e impor as restrições corretas antes da recuperação.

A anatomia da intenção do e-commerce: cabeça e cauda

Nesta seção, usamos "cabeça" e "cauda" como abreviações práticas para padrões comuns de navegação e exploração de consultas no comércio eletrônico. No mundo real, muitas consultas contêm aspectos de ambos:

Consultas principais (intenção determinística)

São consultas diretas e navegacionais onde o usuário sabe exatamente o que quer:

• Intenção de item único ("laranjas", "leite", "pão").

• Marcas exatas ou famílias de produtos ("iPhone 15 Pro", "Coca Coke").

• SKUs, números de modelo, tamanhos ("ABC123", "Air Max 270").

Para essas consultas, a recuperação lexical pode lidar com correspondência de tokens (palavras correspondentes), mas o negócio também espera respeitar restrições, devolver rankings previsíveis e ter resultados controláveis. Um profissional de merchandising precisa garantir que uma consulta seja resolvida dentro dos limites da categoria correta, respeite os critérios de elegibilidade e destaque as prioridades específicas do negócio.

A governança é necessária para fazer cumprir a resolução pretendida. Por exemplo, "laranjas" devem corresponder à categoria de hortifrúti, não a suco de laranja, geleia de laranja ou refrigerante de laranja.

Consultas de cauda (descoberta exploratória)

São consultas descritivas e ricas em intenção, nas quais os consumidores exploram:

• "Presente para o avô que adora doces"

• "Jaqueta para caminhadas nas montanhas"

• "Sapatos para ficar em pé o dia todo"

A recuperação lexical costuma apresentar dificuldades nesse caso. A recuperação semântica se destaca porque pode conectar o conceito de consulta ao produto, mesmo quando a redação não corresponde. Mas a recuperação semântica sozinha raramente é suficiente também. Consultas reais frequentemente exigem restrições para serem aplicadas, independentemente do método de recuperação usado.

As restrições são ortogonais ao método de recuperação

Aplicar restrições à recuperação semântica não significa busca híbrida. São conceitos ortogonais. Restrições, como filtros e boosts no Elasticsearch, podem ser aplicadas a qualquer recuperação lexical, semântica ou híbrida. O desafio é decidir como a consulta deve ser interpretada, quais restrições devem ser aplicadas e qual estratégia de recuperação deve ser utilizada.

Abaixo estão alguns exemplos de consultas que combinam recuperação com restrições rígidas:

• Laranjas: recuperação lexical para "laranjas" mais uma restrição de categoria, como "Frutas" ou "Produtos", eliminando geleia de laranja, suco de laranja e refrigerante de laranja.

• Frutas com alto teor de vitamina C por menos de US$ 4: recuperação semântica com foco em intenção nutricional, além de restrições que limitam os resultados à categoria de frutas e produtos por menos de US$ 4.

• Sapatos confortáveis para trabalhar: recuperação semântica para intenção contextual mais uma restrição de categoria que limita os resultados a sapatos.

Essas consultas não podem ser tratadas por uma única abordagem:

• A recuperação lexical pura geralmente é insuficiente aqui porque frases como "rico em vitamina C" ou "confortável" podem não existir como atributos bem definidos e estruturados. Talvez seja necessário inferi-las a partir de descrições, análises ou especificações do produto.

• A recuperação semântica pura também nem sempre é suficiente, pois, sem restrições explícitas, uma consulta como "frutas ricas em vitamina C" pode se expandir para suplementos vitamínicos, bebidas com sabor de frutas ou vegetais ricos em vitaminas fora da categoria e faixa de preço pretendidas.

Uma camada de governança determina se uma consulta precisa de recuperação lexical, compreensão semântica, aplicação de restrições ou alguma combinação dessas. Sem essa camada, as equipes de comércio eletrônico podem acabar:

• Excesso de restrições: usar a recuperação lexical para pedidos semânticos (por exemplo, "presente para o avô").

• Sub-restrição: utilizar consultas semânticas para consultas principais de alta intenção (por exemplo, "laranjas").

O desafio da governança é construir um sistema que possa tomar a decisão correta para cada classe de consulta.

O que acontece sem governança

O modo de falha mais comum é simples: as equipes pegam a consulta bruta do usuário e a encaminham diretamente para uma única estratégia de recuperação (lexical, semântica ou híbrida), sem uma camada intermediária de governança.

A recuperação lexical falha na resolução pretendida

Quando um usuário pesquisa por “laranjas”, uma estratégia de recuperação lexical pode retornar qualquer resultado que contenha esse token: suco de laranja, geleia de laranja ou refrigerante de laranja. O sistema encontrou o termo corretamente, mas, sem governança, pode não resolver o contexto de compra pretendido (a fruta).

A recuperação semântica se expande além das restrições pretendidas

Quando um usuário busca por "laranjas", um sistema semântico pode recuperar itens conceitualmente relacionados entre conceitos de produtos próximos. O sistema pode entender corretamente o domínio mais amplo (frutas ou produtos), mas, sem uma governança explícita, ele ainda pode se expandir além da restrição pretendida pelo usuário (especificamente laranjas).

A lacuna é a governança

O que é necessário é uma camada de decisão a montante que determine a intenção da consulta e impeça as restrições corretas antes do início da recuperação. Isso resolve questões como:

• Itens semelhantes ou relacionados aparecendo ao lado do que o usuário realmente queria.

• Limites de categorias desfocados ("bebidas" versus. "produtos").

• Incapacidade de implementar aumentos sazonais ou campanhas.

• Resultados imprevisíveis e inexplicáveis.

Compreensão e roteamento de intenções: o plano de controle necessário

Um sistema de busca governado introduz um plano de controle leve antes da recuperação (antes de executar uma consulta no Elasticsearch).O controle será discutido em detalhes nas partes 3 e 4 desta série de blog; por enquanto, discutiremos apenas o que ele pode fazer, mas não como funciona:

Um plano de controle pode detectar intenção, aplicar políticas de negócio e garantir a estratégia de recuperação apropriada da seguinte forma:

1. Detectar sinais de intenção

• Essa consulta é provavelmente navegação versus descoberta?

• É uma consulta conhecida como principal (leite, pão, bananas)?

• Existe uma interpretação conhecida de produto, marca ou categoria (por exemplo, "laranjas" deve ser interpretado como hortifrúti).

• A consulta segue um padrão semelhante ao SKU?

• A consulta se enquadra em uma campanha ativa ou em uma política sazonal (por exemplo, durante o Natal, aumentar os resultados relacionados a peru)?

• A consulta implica alguma restrição (categoria, atributos, exclusões, preço/tamanho/cor)?

2. Aplicar governança e políticas de negócios

• Aplique primeiro as restrições determinísticas (categoria/atributo/negação/disponibilidade).

• Aplique políticas de comercialização ativas (impulsionar/enterrar/fixar/substituir).

• Resolva conflitos com regras de precedência (por exemplo, substituições de campanhas versus políticas globais).

3. Encaminhar para a estratégia de recuperação apropriada

• Lexical (rápido, determinístico) para consultas de navegação/de alta intenção.

• Recuperação semântica para consultas verdadeiras de descoberta.

• Híbrido onde sinais lexicais e semânticos combinados agregam valor sob restrições explícitas de negócios.

Na prática, a saída do plano de controle não é simplesmente “usar híbrido” ou “usar semântico”. Trata-se de um plano de recuperação de compras controlado: uma interpretação da intenção do comprador, das restrições e políticas que devem ser aplicadas e da estratégia de recuperação que deve ser executada. Alguns exemplos simples tornam isso concreto:

Consulta do cliente

Interpretação governada

Exemplo de plano de recuperação

"Chocolate sem amendoim"

Consulta orientada a produto com uma restrição de exclusão rígida

Recuperação lexical para chocolate com um filtro de exclusão para produtos que contenham amendoim.

"azeite de oliva barato"

Consulta de produto/categoria com restrição de preço

Recuperação lexical para azeite de oliva mais um filtro de preço limitado no limite do varejista para barato

"frutas ricas em vitamina C abaixo de $ 4"

Consulta de descoberta que exige compreensão semântica mais restrições rígidas

Recuperação semântica por intenção nutricional, restrita à categoria de frutas e filtrada para produtos com preço inferior a $ 4

Um plano de controle seleciona a política e a estratégia de recuperação adequadas para cada consulta de forma consistente, previsível e em escala. Isso torna os métodos avançados de recuperação mais previsíveis em produção porque as restrições alinhadas à intenção são aplicadas primeiro e as decisões de roteamento são explícitas, em vez de implícitas.

Como isso se relaciona com outras abordagens

Algumas equipes usam modelos de incorporação aprimorados para capturar melhor a semântica do produto, o que pode melhorar substancialmente a qualidade da recuperação semântica. Outros utilizam abordagens de reclassificação, como o Learning To Rank (LTR), para otimizar a ordenação dos resultados com base em engajamento ou sinais de negócio após a recuperação. Ambos são valiosos e frequentemente complementares. Embeddings melhores melhoram a correspondência de similaridade. A reclassificação melhora a ordem entre os candidatos recuperados.

A governança aborda uma camada diferente do problema: ela se situa antes da recuperação de dados. Ela decide qual estratégia de recuperação usar (por exemplo, lexical, semântica ou híbrida), quais restrições determinísticas são necessárias e quais consultas devem combinar várias políticas de negócios.

O que um plano de controle governado permite

Depois que uma camada de governança é implementada, o modelo operacional muda de forma fundamental. Consultas de busca críticas para a receita se tornam previsíveis. As equipes de negócios podem atualizar o comportamento de busca sem precisar esperar pelos ciclos de release da engenharia. E métodos avançados de recuperação, como a semântica e a híbrida, podem ser adotados de forma incremental, com roteamento e mecanismos de proteção, em vez de uma chave liga/desliga global.

O próximo post desta série explora como esse modelo operacional funciona na prática e por que ele pode ser tão importante quanto a tecnologia de retrieval que está por trás dele.

Se um comerciante precisar abrir um ticket do Jira e esperar por uma implantação para corrigir uma consulta crítica de receita, o gargalo não é o mecanismo; é o modelo operacional. A pesquisa moderna de comércio eletrônico precisa de uma forma de traduzir a intenção comercial em um comportamento de pesquisa controlado e auditável de forma rápida e segura, sem deixar de usar a recuperação avançada, que agrega valor mensurável.

O que vem a seguir nesta série

Os padrões explorados nesta série operam antes da recuperação: traduzindo a intenção comercial na estratégia de consulta correta antes do início da geração da consulta. No próximo post, passamos do problema técnico para o operacional: o que acontece quando equipes de negócios conseguem mudar o comportamento de busca sem uma implantação de engenharia, e por que a governança torna isso seguro.

Coloque em prática o buscar governado de comércio eletrônico

Gargalos de engenharia, lógica frágil da camada de aplicativos e resultados de busca imprevisíveis são problemas que a Elastic Services pode ajudar a resolver em contratos de serviços de comércio eletrônico corporativo. A arquitetura do plano de controle governado descrita nesta série foi construída pela Elastic Services Engineering.

Se sua equipe está gastando ciclos de engenharia traduzindo solicitações de merchandising em alterações de código, ou se o backlog de relevância de buscar nunca parece diminuir, podemos ajudá-lo a avaliar sua arquitetura atual e construir um caminho para uma buscar governada e editável pela área de negócios. Entre em contato com Elastic Services.

Participe da discussão

Tem dúvidas sobre governança de buscar, estratégias de recuperação ou arquitetura de buscar para e-commerce? Participe da conversa mais ampla da comunidade Elastic.