No entanto, quando você resolve esse problema, acaba com outras consultas porque não pôde testar todos os casos manualmente. Mas como você ou sua equipe de QA podem testar se uma mudança em uma consulta tem efeito dominó em outras? Ou, mais importante ainda, como você pode ter certeza de que suas mudanças realmente melhoraram uma consulta?

Rumo a uma avaliação sistemática

É aqui que as listas de julgamento se tornam úteis. Em vez de depender de testes manuais e subjetivos toda vez que você faz uma alteração, você pode definir um conjunto fixo de consultas relevantes para seu caso de negócio, juntamente com os resultados relevantes.

Esse conjunto se torna sua referência. Toda vez que você implementa uma mudança, você a usa para avaliar se você buscou uma melhoria ou não.

O valor dessa abordagem é:

• Elimina a incerteza: você não precisa mais se perguntar se suas alterações afetam outras consultas; os dados dirão isso a você.

• Interrompe os testes manuais: assim que os conjuntos de julgamento são registrados, o teste é automático.

• Dá suporte à mudanças: você pode apresentar métricas claras que sustentam os benefícios de uma mudança.

Como começar a construir sua lista de julgamentos

Uma das formas mais fáceis de começar é pegar uma consulta representativa e selecionar manualmente os documentos relevantes. Existem duas maneiras de fazer esta lista:

• Julgamentos binários: cada documento associado a uma consulta recebe uma marcação simples: relevante (geralmente com uma pontuação de “1”) e não-relevante (“0”).

• Julgamentos graduados: aqui, cada documento recebe uma pontuação com diferentes níveis. Por exemplo: definir uma escala de 0 a 4, semelhante à Escala Likert, onde 0 = "nada relevante" e 4 = "totalmente relevante", com variações como "relevante", "um pouco relevante" etc.

Julgamentos binários funcionam bem quando a intenção de buscar tem limites claros: esse documento deve estar nos resultados ou não?

Julgamentos graduados são mais úteis quando há áreas cinzentas: alguns resultados são melhores que outros, então você pode ter resultados "muito bons", "bons" e "inúteis" e usar métricas que valorizam a ordem dos resultados e o feedback do usuário. No entanto, as escalas graduadas também introduzem desvantagens: diferentes avaliadores podem usar os níveis de pontuação de maneira diferente, o que torna os julgamentos menos consistentes. E porque as métricas graduadas dão mais peso às pontuações mais altas, mesmo uma pequena mudança (como classificar algo com 3 em vez de 4) pode criar uma mudança muito maior na métrica do que o avaliador pretendia. Essa subjetividade adicional torna os julgamentos graduados mais complicados e difíceis de gerenciar ao longo do tempo.

Preciso classificar os documentos eu mesmo?

Não necessariamente, pois existem diferentes maneiras de criar sua lista de julgamentos, cada uma com suas próprias vantagens e desvantagens:

• Julgamentos explícitos: aqui, os SMEs analisam cada consulta/documento e decidem manualmente se é relevante e qual a dimensão da relevância. Embora isso ofereça qualidade e controle, tem menos escalabilidade.

• Julgamentos implícitos: com esse método, você infere os documentos relevantes com base no comportamento real dos usuários, como cliques, taxa de rejeição e compras, entre outros. Essa abordagem permite coletar dados automaticamente, mas pode ser tendenciosa. Por exemplo, os usuários tendem a clicar mais vezes nos resultados principais, mesmo que não sejam relevantes.

• Julgamentos gerados por IA: essa última opção utiliza modelos (como LLMs) para avaliar automaticamente consultas e documentos, chamados LLM como juiz. É rápido e fácil de redimensionar, mas a qualidade dos dados depende da qualidade do modelo que você está usando e de como os dados de treinamento do LLM se alinham aos seus interesses comerciais. Assim como acontece com as notas humanas, os LLMs como juiz podem apresentar os próprios preconceitos ou inconsistências, por isso é importante validar o resultado em relação a um conjunto menor de julgamentos confiáveis. Modelos LLM são probabilísticos por natureza, então não é incomum ver um modelo LLM dando diferentes graus ao mesmo resultado, independentemente de definir o parâmetro de temperatura como 0.

A seguir, apresentamos algumas recomendações para escolher o melhor método para criar seu conjunto de julgamentos:

• Decida a importância de alguns recursos que somente os usuários possam avaliar de forma adequada (como preço, marca, idioma, estilo e detalhes do produto). Se eles forem importantes, você precisará de julgamentos explícitos para pelo menos uma parte da sua lista de julgamentos.

• Use julgamentos implícitos quando seu mecanismo de busca já tiver tráfego suficiente para que você possa usar cliques, conversões e métricas de tempo persistentes para detectar tendências de uso. Você ainda deve interpretá-los com cuidado, comparando-os com seus conjuntos de julgamento explícitos para evitar qualquer viés (por exemplo: os usuários tendem a clicar nos resultados mais bem classificados com mais frequência, mesmo que os resultados com classificação inferior sejam mais relevantes)

Para resolver isso, técnicas de posicionamento de debiasing ajustam ou reponderam os dados de cliques para refletir melhor o verdadeiro interesse do usuário. Algumas abordagens incluem:

• Reorganização de resultados: altere a ordem dos resultados de busca para um subconjunto de usuários a fim de estimar como a posição afeta os cliques.

• Os modelos de clique incluemRede bayesiana dinâmica DBN, Modelo de Navegação do Usuário UBM. Esses modelos estatísticos estimam que a probabilidade de um clique reflete o interesse real em vez de apenas posição, usando padrões como rolagem, tempo de espera, sequência de cliques e retorno à página de resultados.

Exemplo: app de avaliação de filmes

Pré-requisitos

Para executar este exemplo, você precisa de um cluster Elasticsearch 8.x em execução, localmente ou no Elastic Cloud (hospedado ou sem servidor), e acesso à REST API ou ao Kibana.

Pense em um app no qual os usuários possam carregar as opiniões sobre filmes e também buscar filmes para assistir. Como os textos são escritos pelos próprios usuários, eles podem ter erros de digitação e muitas variações em termos de expressão. Portanto, é fundamental que o mecanismo de busca seja capaz de interpretar essa diversidade e fornecer resultados úteis para os usuários.

Para poder iterar consultas sem impactar o comportamento geral de busca, a equipe de negócios da sua empresa criou o seguinte conjunto de julgamento binário, baseado nas buscas mais frequentes:

Consulta

DocID

Texto

Performance de DiCaprio

doc1

A atuação de DiCaprio em O Regresso foi de tirar o fôlego.

Performance de DiCaprio

doc2

A Origem mostra Leonardo DiCaprio em um dos papéis mais icônicos que ele já fez.

Performance de DiCaprio

doc3

Brad Pitt entrega uma atuação sólida neste thriller policial.

Performance de DiCaprio

doc4

Uma aventura cheia de ação com efeitos visuais impressionantes.

filmes tristes que fazem você chorar

doc5

Uma história comovente de amor e perda que me fez chorar muito.

filmes tristes que fazem você chorar

doc6

Um dos filmes mais tristes já feitos — traga lenços!

filmes tristes que fazem você chorar

doc7

Uma comédia leve que vai fazer rir

filmes tristes que fazem você chorar

doc8

Uma saga de ficção científica épica repleta de ação e emoção.

Criando o índice:

SOLICITAÇÃO em massa:

Abaixo está a consulta Elasticsearch que o aplicativo está usando:

Do julgamento às métricas

Sozinho, as listas de julgamento não fornecem muitas informações; eles são apenas uma expectativa dos resultados das nossas consultas. O momento importante deles é quando os usamos para calcular métricas objetivas para medir nosso desempenho na busca.

Hoje em dia, a maioria das métricas populares inclui

• Precisão: mede a proporção de resultados relevantes em todos os resultados de busca.

• Recall: mede a proporção de resultados relevantes que o mecanismo de busca encontrou entre x resultados.

• Ganho cumulativo descontado (DCG):mede a qualidade do ranking do resultado, considerando que os resultados mais relevantes devem estar no topo.

• Classificação Recíproca Média (MRR): mede a posição do primeiro resultado relevante. Quanto mais alto na lista, maior a pontuação.

Usando o mesmo app de avaliação de filmes como exemplo, calcularemos a métrica de recordação para ver se há alguma informação que está sendo omitida em nossas consultas.

No Elasticsearch, podemos usar as listas de julgamentos para calcular métricas via API de avaliação de classificação. Essa API recebe como entrada a lista de julgamentos, a consulta e a métrica que você deseja avaliar e retorna um valor, que é uma comparação do resultado da consulta com a lista de julgamentos.

Vamos executar a lista de julgamento para as duas consultas que temos:

Vamos usar dois pedidos para _rank_eval: um para a consulta do DiCaprio e outro para filmes tristes. Cada solicitação inclui uma consulta e a lista de julgamento (avaliações). Não precisamos classificar todos os documentos, pois aqueles que não estão incluídos nas classificações são considerados sem julgamento. Para realizar os cálculos, o sistema considera apenas o "conjunto relevante", ou seja, os documentos que são considerados relevantes na avaliação.

Nesse caso, a consulta do DiCaprio tem resultado de 1, enquanto os filmes tristes receberam 0 resultados. Isso significa que na primeira consulta, conseguimos obter todos os resultados relevantes, enquanto na segunda consulta, não obtivemos nenhum resultado. Portanto, a média de recall é de 0,5.

Talvez estejamos sendo muito rigorosos com o parâmetro minimum_should_match , já que ao exigir que 100% das palavras da consulta estejam nos documentos, provavelmente estamos deixando de fora os resultados relevantes. Vamos remover o parâmetro minimum_should_match para que um documento seja considerado relevante se apenas uma palavra na consulta seja encontrada nele.

Como você pode ver, ao remover o parâmetro minimum_should_match em uma das duas consultas, agora obtemos uma taxa de acerto média de 1 em ambas.

Em resumo, remover a cláusula minimum_should_match: 100% nos permite ter um recall perfeito para ambas as consultas.

Conseguimos! Certo?

Não tão depressa!

Ao melhorar o recall, abrimos as portas para uma gama maior de resultados. No entanto, cada ajuste implica uma contrapartida. É por isso que definimos casos de teste completos, usando diferentes métricas para avaliar as mudanças.

Usar listas de julgamento e métricas evita que você fique às cegas ao fazer alterações, pois agora você tem dados para respaldá-las. A validação não é mais manual e repetitiva, e você pode testar as mudanças em mais de um caso de uso. Além disso, o teste A/B permite que você teste ao vivo qual configuração funciona melhor para seus usuários e seu caso de negócios, completando assim as métricas técnicas e as métricas do mundo real.

Recomendações finais para o uso de listas de julgamento

Trabalhar com listas de julgamento não é apenas medir, mas também criar um framework que permita iterar com confiança. Para atingir isso, você pode seguir estas recomendações:

1. Comece pequeno, mas comece de algum lugar. Você não precisa ter 10.000 consultas com 50 listas de julgamento cada. Você só precisa identificar de 5 a 10 consultas mais importantes para seu case de negócios e definir quais documentos espera ver no topo dos resultados. Isso já te dá uma base. Normalmente, você quer começar com as principais consultas mais as que não obtiveram resultados. Você também pode começar a testar com uma métrica fácil de configurar, como Precision, e depois ir aumentando a complexidade.

2. Validar com os usuários. Complemente os números com testes A/B em produção. Dessa forma, você saberá se mudanças que parecem boas nas métricas também estão gerando um impacto real.

3. Mantenha a lista atualizada. Seu caso de negócio vai evoluir, assim como suas consultas importantes. Atualize seu julgamento periodicamente para refletir novas necessidades.

4. Faça disso parte do fluxo. Integre listas de julgamento aos seus pipelines de desenvolvimento. Certifique-se de que cada alteração de configuração, sinônimo ou análise de texto seja automaticamente validada em relação à sua lista base.

5. Conecte conhecimento técnico com estratégia. Não se limite a medir métricas técnicas como a precisão ou o recall. Use os resultados da sua avaliação para informar os resultados do negócio.

Além disso, esses casos de uso geralmente são sensíveis ao tempo, e passar pelas etapas típicas de desenvolvimento (criar uma ramificação de código e depois esperar por um novo lançamento) é um processo demorado.

E se pudéssemos realizar todo esse processo com apenas uma chamada de API, ou melhor ainda, com apenas alguns cliques no Kibana?

Interface do usuário de regras de consulta

O Elasticsearch 8.10 introduziu as Regras de Consulta e o Recuperador de Regras. São ferramentas projetadas para inserir resultados fixados nas consultas sem afetar a classificação dos resultados orgânicos com base em regras. Eles apenas adicionam lógica de negócios aos resultados de forma declarativa e simples.

Alguns casos de uso comuns para regras de consulta são:

• Destacar anúncios ou promoções: Exibir itens em promoção ou patrocinados no topo.

• Exclusão por contexto ou geolocalização: Ocultar determinados itens quando as regulamentações locais não permitem que você os mostre.

• Priorizar resultados-chave: Garantir que as pesquisas populares ou fixas estejam sempre no topo, independentemente do ranking orgânico.

Para acessar a interface e interagir com essas ferramentas, você precisa clicar no menu lateral do Kibana e ir para Regras de Consulta, em Relevância:

Assim que o menu de regras de consulta aparecer, clique em Criar seu primeiro conjunto de regras:

Em seguida, você precisa dar um nome ao seu conjunto de regras.

O formulário para definir cada regra possui três componentes principais:

• Critérios: As condições que devem ser cumpridas para que a regra se aplique. Por exemplo, “quando o campo query_string contém o valor Christmas” ou “quando o campo country é CO”.

• Ação: Isto é o que você deseja que aconteça quando as condições forem atendidas. Ele pode ser fixado (fixando um documento nos primeiros resultados) ou excluído (ocultando um documento).

• Metadados: São os campos que acompanham a consulta quando ela é executada. Podem incluir informações do usuário (como localização ou idioma), bem como dados de pesquisa (query_string). Esses são os valores usados pelos critérios para decidir se uma regra deve ou não ser aplicada.

Exemplo: itens populares

Vamos imaginar que temos um site de comércio eletrônico com diversos itens. Ao analisarmos as métricas, notamos que um dos itens mais vendidos na categoria de consoles é o "Controle sem fio DualShock 4", especialmente quando os usuários pesquisam pelas palavras-chave "PS4" ou "PlayStation 4". Assim, decidimos colocar este produto no topo dos resultados, sempre que um usuário pesquisar por essas palavras-chave.

Primeiro, vamos indexar os documentos de cada item usando uma solicitação de API em lote:

Se não intervirmos na consulta, o item geralmente aparece em quarto lugar. Eis a pergunta:

E aqui estão os resultados.

Vamos criar uma regra de consulta para alterar isso. Primeiro, vamos adicioná-lo ao conjunto de regras assim:

Ou solicitação de API equivalente:

Para usar o conjunto de regras em nossa consulta, devemos usar um tipo de regra de consulta. Esse tipo de consulta é composto por duas partes principais:

• match_criteria: São os metadados usados para comparar com a consulta do usuário. Neste exemplo, o conjunto de regras é ativado quando o campo query_string tem o valor “PlayStation 4”.

• consulta: a consulta propriamente dita que será usada para pesquisar e obter os resultados orgânicos.

Dessa forma, primeiro você executa a consulta orgânica e, em seguida, o Elasticsearch aplica as regras do seu conjunto de regras:

Exemplo: metadados baseados no usuário

Outra aplicação interessante das Regras de Consulta é usar metadados para exibir documentos específicos com base em informações contextuais do usuário ou da página da web.

Por exemplo, vamos supor que queremos destacar itens ou ofertas personalizadas com base no nível de fidelidade do usuário, representado por um valor numérico.

Podemos fazer isso inserindo esses metadados diretamente na consulta, de forma que as regras sejam ativadas quando o valor atender a determinados critérios.

Primeiro, vamos indexar um documento que somente usuários com um alto nível de fidelidade podem ver:

Agora, vamos criar uma nova regra dentro do mesmo conjunto de regras para que, quando o nível de lealdade for igual ou superior a 80, o item apareça no topo dos resultados.

Salve a regra e o conjunto de regras.

Aqui está a solicitação REST equivalente:

Agora, ao executar uma consulta, precisamos incluir o novo parâmetro loyalty_level nos metadados. Se a condição da regra for atendida, o novo documento aparecerá no topo dos resultados.

Por exemplo, ao enviar uma consulta onde o nível de lealdade é 80:

Veremos o documento de fidelidade acima dos resultados:

No caso abaixo, como o nível de fidelidade é 70, a regra não é atendida e o item não deve aparecer no topo:

Aqui estão os resultados:

Exemplo: exclusão imediata

Vamos supor que nosso Controle Sem Fio DualShock 4 (ID 2) esteja temporariamente indisponível e não possa ser vendido. Assim, em vez de excluir o documento manualmente ou esperar que algum processamento de dados seja iniciado, a equipe comercial decide removê-lo dos resultados da pesquisa enquanto isso.

Usaremos um processo semelhante ao que acabamos de aplicar aos itens populares, mas desta vez, em vez de selecionar "Fixados", escolheremos "Excluir". Essa regra funciona como uma espécie de lista negra. Altere os critérios para "Sempre" para que a exclusão funcione sempre que a consulta for executada.

A regra deve ser assim:

Salve a regra e o conjunto de regras para aplicar as alterações. Aqui está a solicitação REST equivalente:

Agora, ao executar a consulta novamente, você verá que o item não está mais nos resultados, mesmo que a regra anterior fosse fixá-lo. Isso ocorre porque as exclusões têm prioridade sobre a fixação dos resultados.

Conclusão

As regras de consulta tornam muito fácil ajustar a relevância sem qualquer alteração de código. A nova interface do Kibana permite que vocêPara fazer essas alterações em questão de segundos, você e sua equipe terão mais controle sobre os resultados da pesquisa.

Além do comércio eletrônico, as Regras de Consulta podem ser aplicadas em muitos outros cenários: destacar guias de solução de problemas em portais de suporte, exibir documentos internos importantes em bases de conhecimento, promover notícias de última hora em sites de notícias ou filtrar anúncios de emprego ou conteúdo expirados. Eles podem até mesmo impor regras de conformidade, como ocultar material restrito por função de usuário ou região.