Construindo um plano de controle para gerenciar a busca de comércio eletrônico

A parte 1 e a parte 2 desta série estabeleceram por que a busca no comércio eletrônico precisa de uma camada de governança, uma camada de decisão entre a consulta do usuário e o mecanismo de recuperação que classifica a intenção, impõe restrições e direciona para a estratégia de recuperação correta (por exemplo, BM25, semântica, híbrida). Este post mostra como construir essa camada usando uma primitiva arquitetônica simples onde as políticas de interpretação de consultas são armazenadas como documentos e recuperadas no momento da consulta por meio de correspondência reversa rápida. Como as novas políticas de recuperação (por exemplo, "destacar a marca X" ou "mostrar apenas a categoria Y") não exigem alterações no código, o resultado é uma camada de roteamento que permanece estável enquanto as políticas evoluem e que mantém os mecanismos de recuperação seguros em ambientes de alto risco. Se você quiser ver o resultado final dessa arquitetura antes de continuar a leitura, confira este vídeo: Corrigindo a relevância da busca em segundos: apresentando o PRISM.

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:

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.