Neste artigo, você aprenderá como usar o parâmetro de pontuação mínima para aumentar a precisão dos seus resultados de busca semânticos. Se você quiser testar os exemplos fornecidos neste post do blog, acesse o caderno Jupyter associado.

Contexto: Precisão e recall

Na relevância da pesquisa, a precisão e a recall são conceitos-chave. Qualquer leitor que ainda não esteja familiarizado é altamente incentivado a pesquisar sobre eles. Segue abaixo um resumo.

• Precisão: a fração dos resultados de busca retornados que são relevantes para o usuário.

• Recall: a fração de todos os documentos relevantes no corpus que estão incluídos no conjunto de resultados de busca.

Ou, em outras palavras, a precisão retorna apenas resultados relevantes e o recall retorna todos os resultados relevantes. Como você pode imaginar, esses são requisitos frequentemente concorrentes. A busca semântica tende a ter uma memória muito alta, mas pode ter dificuldades com precisão. Continue lendo para saber como se locomover por esta propriedade.

Apresentando o parâmetro de pontuação mínima

O parâmetro ‘min_score’ nos permite melhorar a precisão ao definir uma pontuação mínima, que truncará o conjunto de resultados removendo quaisquer correspondências com uma pontuação inferior ao limite definido. Aqui está um exemplo simples:

Normalização da pontuação

Definir uma pontuação mínima é muito bom; no entanto, nem todos os modelos semânticos retornam uma pontuação adequada para um limite estático. ELSER, por exemplo, retorna uma pontuação que é ilimitada. Algumas pontuações de modelos densos estão fortemente agrupadas e só fazem sentido no contexto da consulta específica.

Para a maioria dos casos de busca semântica, recomendamos usar uma abordagem de normalização antes de aplicar o 'min_score'. A normalização garante que a pontuação do documento esteja dentro de um intervalo definido. Os recuperadores Elasticsearch fornecem dois desses normalizadores, 'l2_norm' e 'minmax'. O mais comumente usado é o 'minmax', pois é fácil de entender e funciona bem em muitos cenários. As principais propriedades do 'minmax' incluem:

• As pontuações dos documentos são distribuídas entre 0 e 1.

• O documento com maior pontuação é sempre pontuado como 1.

• O documento com menor pontuação sempre é pontuado como 0.

  • Isso pode torná-lo menos adequado para buscar palavras-chave. Consulte a seção “Busca híbrida” para uma discussão mais aprofundada.

A seguir está um exemplo de consulta semântica normalizada com min_score. O tamanho da janela de classificação foi aumentado para 500 para permitir que possamos retornar uma lista maior de resultados de busca, começando em 100.

O tamanho foi ajustado para um valor maior do que o normalmente visto na produção. Isso é para que possamos inspecionar a qualidade dos resultados de busca e ajustar os resultados.

Busca híbrida usando o recuperador linear

Para busca híbrida, a abordagem mais simples é normalizar todas as pontuações, atribuir pesos e aplicar uma pontuação mínima. Note que, ao escolher pesos cuja soma seja 1, você mantém a pontuação total dentro de um intervalo de 0 a 1. Isso facilita entender as pontuações finais e afinar min_score. A seguir está um exemplo:

Busca híbrida usando o RRF

Com o BM25, muitas vezes controlamos a precisão por outros meios, como usando o operador AND ou minimum_should_match. Além disso, consultas compostas por termos únicos, precisos e raros naturalmente causam resultados de busca com poucos resultados, muitas vezes todos altamente relevantes. Isso pode resultar em:

• Os resultados mais distantes na lista recebem uma pontuação normalizada baixa no recuperador BM25, mesmo que a pontuação absoluta do BM25 esteja próxima das pontuações mais altas.

• Ao adicionar uma pontuação BM25 muito baixa à pontuação semântica, o total pode ser aproximado como a pontuação semântica.

• A falta de contribuição da pontuação BM25 pode fazer com que o documento seja descartado pelo min_score threshold.

Como solução, podemos usar a fusão de classificação recíproca (RRF) para combinar os resultados BM25 e semânticos. O RRF contorna o desafio de comparar pontuações de diferentes algoritmos de busca focando na posição em cada conjunto de resultados. Nesse cenário, o min_score é aplicado apenas ao recuperador semântico.

Conclusão

Usando min_score, mostramos como podemos reduzir o número de falsos positivos em nossos conjuntos de resultados causados pela alta recordação de algoritmos de busca semântica. Para saber mais sobre recuperadores, consulte este post do blog e a documentação do Elasticsearch.

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.

O problema da amplitude de pontuação

Para contextualizar, vamos analisar um dos principais motivos pelos quais a busca híbrida pode ser difícil: a variação nos intervalos de pontuação. Nosso velho amigo BM25 produz pontuações ilimitadas. Em outras palavras, o BM25 pode gerar pontuações que variam de perto de 0 até (teoricamente) o infinito. Em contraste, as consultas aos campos dense_vector produzirão pontuações limitadas entre 0 e 1. Exacerbando este problema, semantic_text ofusca o tipo de campo usado para indexar embeddings, portanto, a menos que você tenha conhecimento detalhado sobre a configuração do seu índice e endpoint de inferência, pode ser difícil dizer qual será o intervalo de pontuação da sua consulta. Isso representa um problema ao tentar intercalar resultados de busca lexical e semântica, já que os resultados lexicais podem ter precedência sobre os semânticos, mesmo que os resultados semânticos sejam mais relevantes. A solução geralmente aceita para esse problema é normalizar as pontuações antes de intercalar os resultados. O Elasticsearch possui duas ferramentas para isso: os recuperadores lineares e RRF .

O recuperador RRF aplica o algoritmo RRF, usando a classificação do documento como medida de relevância e descartando a pontuação. Como a pontuação não é considerada, as discrepâncias na faixa de pontuação não representam um problema.

O recuperador linear utiliza uma combinação linear para determinar a pontuação final de um documento. Isso envolve pegar a pontuação de cada consulta de componente para o documento, normalizá-la e somá-las para gerar a pontuação total. Matematicamente, a operação pode ser expressa como:

Onde N é a função de normalização e SX é a pontuação para a consulta X. A função de normalização é fundamental aqui, pois transforma a pontuação de cada consulta para usar o mesmo intervalo. Você pode aprender mais sobre o recuperador linear aqui.

Analisando detalhadamente

Os usuários podem implementar uma busca híbrida eficaz com essas ferramentas, mas isso requer algum conhecimento sobre o seu índice. Vejamos um exemplo com o recuperador linear, onde consultaremos um índice com dois campos:

1. semantic_text_field é um campo semantic_text que usa E5, um modelo de incorporação de texto.

2. text_field é um campo text padrão

1. Usamos uma consulta match em nosso campo semantic_text , para o qual adicionamos suporte no Elasticsearch 8.18/9.0

Ao construir a consulta, precisamos ter em mente que semantic_text_field usa um modelo de incorporação de texto, portanto, quaisquer consultas sobre ele gerarão uma pontuação entre 0 e 1. Precisamos também saber que text_field é um campo text padrão e, portanto, as consultas nele gerarão uma pontuação ilimitada. Para criar um conjunto de resultados com a relevância adequada, precisamos usar um mecanismo de recuperação que normalize as pontuações das consultas antes de combiná-las. Neste exemplo, usamos o recuperador linear com normalização minmax , que normaliza a pontuação de cada consulta para um valor entre 0 e 1.

A construção da consulta neste exemplo é bastante simples, pois envolve apenas dois campos. No entanto, a situação pode se complicar rapidamente à medida que mais campos, e de tipos variados, são adicionados. Isso demonstra como escrever uma consulta de pesquisa híbrida eficaz geralmente requer um conhecimento mais profundo do índice consultado, para que as pontuações das consultas componentes sejam devidamente normalizadas antes da combinação. Isso representa uma barreira para a adoção mais ampla da busca híbrida.

Agrupamento de consultas

Vamos expandir o exemplo: E se quiséssemos consultar um campo text e dois campos semantic_text ? Poderíamos construir uma consulta como esta:

Isso parece bom à primeira vista, mas existe um problema em potencial. Agora, as correspondências do campo semantic_text representam ⅔ da pontuação total:

Provavelmente não é isso que você deseja, pois cria uma pontuação desequilibrada. Os efeitos podem não ser tão perceptíveis em um exemplo como este, com apenas 3 campos, mas tornam-se problemáticos quando mais campos são consultados. Por exemplo, a maioria dos índices contém muito mais campos lexicais do que semânticos (ou seja, dense_vector, sparse_vector ou semantic_text). E se estivéssemos consultando um índice com 9 campos lexicais e 1 campo semântico usando o padrão acima? As correspondências lexicais representariam 90% da pontuação, diminuindo a eficácia da busca semântica.

Uma forma comum de resolver isso é agrupar as consultas em categorias lexicais e semânticas e atribuir pesos iguais a ambas. Isso impede que qualquer uma das categorias domine a pontuação total.

Vamos colocar isso em prática. Como seria essa abordagem de consultas agrupadas neste exemplo ao usar o recuperador linear?

Uau, isso está ficando prolixo! Você pode até ter precisado rolar a página para cima e para baixo várias vezes para examinar toda a consulta! Aqui, utilizamos dois níveis de normalização para criar os grupos de consulta. Matematicamente, pode ser expresso como:

Este segundo nível de normalização garante que as consultas aos campos semantic_text e text sejam ponderadas igualmente. Observe que omitimos a normalização de segundo nível para text_field neste exemplo, uma vez que há apenas um campo lexical, poupando-o de ainda mais verbosidade.

Essa estrutura de consulta já é complexa demais, e estamos consultando apenas três campos. À medida que se consultam mais campos, a tarefa torna-se cada vez mais difícil de gerir, mesmo para profissionais de pesquisa experientes.

O formato de consulta com vários campos

Adicionamos o formato de consulta com vários campos para os recuperadores lineares e RRF no Elasticsearch 8.19, 9.1 e serverless para simplificar tudo isso. Agora você pode realizar a mesma consulta acima apenas com:

O que reduz a consulta de 55 linhas para apenas 9! O Elasticsearch usa automaticamente os mapeamentos de índice para:

• Determine o tipo de cada campo consultado.

• Agrupe cada campo em uma categoria lexical ou semântica.

• Dê o mesmo peso a cada categoria na pontuação final.

Isso permite que qualquer pessoa execute uma consulta de pesquisa híbrida eficaz sem precisar saber detalhes sobre o índice ou os endpoints de inferência utilizados.

Ao usar o RRF, você pode omitir o normalizer, já que a classificação é usada como um indicador de relevância:

Aumento por campo

Ao usar o recuperador linear, você pode aplicar um reforço por campo para ajustar a importância das correspondências em determinados campos. Por exemplo, digamos que você esteja consultando quatro campos: dois campos semantic_text e dois campos text :

Por padrão, cada campo tem o mesmo peso em seu grupo (lexical ou semântico). A distribuição da pontuação é a seguinte:

Em outras palavras, cada área corresponde a 25% da pontuação total.

Podemos usar a sintaxe field^boost para adicionar um aumento por campo a qualquer campo. Vamos aplicar um aumento de 2 a semantic_text_field_1 e text_field_1:

Agora a distribuição da pontuação é a seguinte:

Cada grupo de consultas ainda tem o mesmo peso, mas agora o peso dos campos dentro dos grupos foi alterado:

• semantic_text_field_1 representa 66% da pontuação do grupo de consultas semânticas e 33% da pontuação total.

• text_field_1 representa 66% da pontuação do grupo de consulta lexical e 33% da pontuação total.

ℹ️ Observe que o intervalo de pontuação total não será alterado quando um aumento por campo for aplicado. Este é um efeito colateral intencional da normalização de pontuação, que garante que as pontuações das consultas lexicais e semânticas permaneçam diretamente comparáveis entre si.

ℹ️ O reforço por campo também pode ser usado com o recuperador RRF no Elasticsearch 9.2+

Resolução curinga

Você pode usar o caractere curinga * no parâmetro fields para corresponder a vários campos. Continuando o exemplo acima, esta consulta é funcionalmente equivalente a consultar explicitamente semantic_text_field_1, semantic_text_field_2 e text_field_1 :

É interessante notar que o padrão *_field_1 corresponde tanto text_field_1 quanto a semantic_text_field_1. Isso é tratado automaticamente; a consulta será executada como se cada um dos campos tivesse sido consultado explicitamente. Também não há problema em que semantic_text_field_1 corresponda a ambos os padrões; todas as correspondências de nomes de campos são desduplicadas antes da execução da consulta.

Você pode usar o caractere curinga de diversas maneiras:

• Correspondência de prefixo (ex: *_text_field)

• Correspondência em linha (ex: semantic_*_field)

• Correspondência de sufixo (ex: semantic_text_field_*)

Você também pode usar vários curingas para aplicar uma combinação do acima, como *_text_field_*.

Campos de consulta padrão

O formato de consulta com vários campos também permite consultar um índice sobre o qual você não sabe nada. Se você omitir o parâmetro fields , a consulta abrangerá todos os campos especificados pela configuração de índice index.query.default_field:

Por padrão, index.query.default_field é definido como *. Este caractere curinga será resolvido para todos os tipos de campo no índice que suportam consultas por termo, que são a maioria. As exceções são:

• dense_vector campos

• rank_vector campos

• Campos geométricos: geo_point, shape

Essa funcionalidade é especialmente útil quando você deseja realizar uma consulta de pesquisa híbrida em um índice fornecido por terceiros. O formato de consulta com vários campos permite executar uma consulta adequada de forma simples. Basta excluir o parâmetro fields e todos os campos aplicáveis serão consultados.

Conclusão

O problema do intervalo de pontuação pode tornar a implementação de uma busca híbrida eficaz bastante complexa, especialmente quando há pouca informação sobre o índice consultado ou os endpoints de inferência em uso. O formato de consulta com múltiplos campos para os mecanismos de recuperação linear e RRF atenua esse problema, integrando uma abordagem de busca híbrida automatizada, baseada em agrupamento de consultas, em uma API simples e acessível. Funcionalidades adicionais, como reforço por campo, resolução de curingas e campos de consulta padrão, ampliam a funcionalidade para abranger diversos casos de uso.

Experimente o formato de consulta com vários campos hoje mesmo.

Você pode conferir os mecanismos de recuperação linear e RRF com o formato de consulta de múltiplos campos em projetos Elasticsearch Serverless totalmente gerenciados, com um período de avaliação gratuito. Também está disponível em versões de pilha a partir das versões 8.19 e 9.1.

Comece em minutos no seu ambiente local com um único comando:

Como muitos de nós, me sinto ao mesmo tempo entusiasmado e surpreso com a velocidade com que as capacidades da IA estão evoluindo. Vimos pela primeira vez os grandes modelos de linguagem (LLMs) e a busca vetorial nos lançarem na revolução semântica, onde não precisávamos mais ficar procurando coisas com palavras-chave. Em seguida, os LLMs nos mostraram novas maneiras de interagir com nossos dados, usando interfaces de bate-papo para transformar solicitações em linguagem natural em respostas que destilam vastas bases de conhecimento em resumos facilmente assimiláveis. Nós agora (já!) Possuem os primórdios da lógica automatizada orientada por LLM na forma de fluxos de trabalho de "IA agente" que podem compreender semanticamente uma solicitação recebida, raciocinar sobre as etapas a serem seguidas e, em seguida, escolher entre as ferramentas disponíveis para executar iterativamente ações para atingir esses objetivos.

A promessa da IA agente está nos forçando a evoluir, deixando de usar principalmente a "engenharia de prompts" para moldar nossas interações generativas de IA, e passando a nos concentrar em como podemos ajudar as ferramentas agentes a obter as informações adicionais mais relevantes e eficientes que o LLM precisa considerar ao gerar suas respostas — a "engenharia de contexto" é a próxima fronteira. A busca híbrida é, de longe, o meio mais poderoso e flexível para revelar contexto relevante, e a plataforma Search AI da Elastic abre uma nova maneira de aproveitar os dados a serviço da engenharia de contexto. Neste artigo, discutiremos como os Modelos de Aprendizagem Baseados em Liderança (LLMs) transformaram o mundo da recuperação de informação sob duas perspectivas e, em seguida, como eles podem trabalhar em conjunto para alcançar melhores resultados. Há muito terreno a percorrer…

Parte I: Como os LLMs mudaram a busca

Vamos começar pela perspectiva de como os LLMs (mestrados em direito) mudaram a forma como acessamos e recuperamos informações.

Nosso legado lexical

Há muito tempo que vivemos num mundo de busca lexical um tanto limitado (ou quase, da melhor forma possível). A busca é a primeira ferramenta que utilizamos ao pesquisar ou iniciar um novo projeto e, até recentemente, dependia de nós formular nossas consultas de uma maneira que um mecanismo de busca lexical entendesse. A busca lexical baseia-se na correspondência de algum tipo de termo de consulta com palavras-chave encontradas em um conjunto de documentos — independentemente de o conteúdo ser estruturado ou não estruturado. Para que uma busca lexical retorne um documento como resultado, ele precisa ter correspondido àquela palavra-chave (ou ter um vocabulário controlado, como uma lista de sinônimos ou um dicionário, para fazer a conexão conceitual para nós).

Um exemplo de consulta lexical de correspondência múltipla

Ao menos os mecanismos de busca têm a capacidade de retornar resultados com uma pontuação de relevância. Os mecanismos de busca oferecem uma ampla gama de opções de sintaxe de consulta para segmentar dados indexados de forma eficaz, além de algoritmos de relevância integrados que classificam os resultados de acordo com a intenção da sintaxe de consulta do usuário. Os mecanismos de busca se beneficiam de décadas de avanços em algoritmos de classificação por relevância, o que os torna uma plataforma eficiente de recuperação de dados, capaz de fornecer resultados pontuados e classificados de acordo com sua relevância para a consulta. Bancos de dados e outros sistemas que usam SQL como principal método para recuperar dados estão em desvantagem nesse aspecto: não existe o conceito de relevância em uma consulta de banco de dados; o máximo que podem fazer é classificar os resultados alfabeticamente ou numericamente. A boa notícia é que você obterá todos os resultados (recall) com essas palavras-chave, mas eles não estarão necessariamente em uma ordem útil em relação ao motivo pelo qual você os solicitou (precisão). Esse é um ponto importante, como veremos em breve…

Entre o dragão (semântico)

O potencial das representações vetoriais de informações como alternativa à busca por palavras-chave vem sendo pesquisado há bastante tempo. Os vetores são muito promissores porque nos libertam do modo de correspondência de conteúdo baseado apenas em palavras-chave — como são representações numéricas de termos e pesos, os vetores permitem que os conceitos sejam matematicamente próximos com base na compreensão do modelo de linguagem sobre como os termos se relacionam entre si no domínio de treinamento. A longa demora na busca por vetores de propósito geral se devia ao fato de os modelos serem, em sua maioria, limitados a domínios específicos; eles simplesmente não eram grandes o suficiente para compreender adequadamente os muitos conceitos diferentes que um termo poderia representar em diferentes contextos.

Foi somente com o surgimento dos Modelos de Linguagem de Grande Porte (LLMs, na sigla em inglês), há alguns anos, e sua capacidade de serem treinados com quantidades muito maiores de dados (usando transformadores e atenção), que a busca vetorial se tornou viável — o tamanho e a profundidade dos LLMs finalmente permitiram que os vetores armazenassem nuances suficientes para, de fato, capturar o significado semântico. Esse aumento repentino na profundidade de compreensão permitiu que os LLMs (Learning Language Machines) passassem a desempenhar diversas funções de processamento de linguagem natural (PLN) que antes estavam bloqueadas, sendo talvez a mais impactante a capacidade de inferir o próximo termo mais provável em uma sequência, dado o contexto do que já estava presente na sequência. A inferência é o processo que confere à IA generativa sua capacidade quase humana de produzir texto. O texto gerado por IA é baseado na compreensão do LLM sobre como os termos se relacionam em seus dados de treinamento e também utiliza a formulação da solicitação para diferenciar os diversos contextos em que os termos podem aparecer.

Por mais mágica que seja a IA generativa, os LLMs têm limitações que causam erros de qualidade e precisão, comumente chamados de alucinações. As alucinações ocorrem quando o profissional de saúde mental não tem acesso à informação (ou não é guiado ao contexto correto) para basear sua resposta na verdade, então, na tentativa de ser prestativo, ele gera uma resposta confiante e plausível que, na verdade, é inventada. Parte da causa é que, embora os LLMs aprendam o uso da linguagem em grandes domínios de informações diversas, eles precisam interromper o treinamento em um determinado momento, portanto, há um fator de temporalidade em sua compreensão — o que significa que o modelo só pode saber o que era preciso até o momento em que o treinamento foi interrompido. Outro fator que contribui para as alucinações é que o modelo geralmente desconhece dados privados (dados não disponíveis na internet pública), e isso é especialmente significativo quando esses dados contêm termos e nomenclatura específicos.

Bancos de dados vetoriais

Os LLMs vetorizam o conteúdo para seu espaço de modelo usando uma técnica chamada incorporação de texto, que se refere à incorporação ou mapeamento do significado semântico do conteúdo na visão de mundo do modelo com base no treinamento que ele recebeu. Existem algumas etapas envolvidas na preparação e no processamento de conteúdo para incorporação, incluindo a segmentação e a tokenização (e a tokenização de subpalavras). O resultado é tipicamente um conjunto de vetores densos que representam a compreensão do modelo sobre o significado daquele trecho de conteúdo dentro de seu espaço vetorial. O chunking é um processo impreciso que visa ajustar o conteúdo às limitações de processamento de um modelo para gerar embeddings, tentando também agrupar textos relacionados em um chunk usando construções semânticas como indicadores de sentença e parágrafo.

A necessidade de fragmentação pode gerar alguma perda semântica em um documento incorporado, porque os fragmentos individuais não estão totalmente associados a outros fragmentos do mesmo documento. A opacidade inerente das redes neurais pode agravar essa perda de informação — um modelo de aprendizagem linear é verdadeiramente uma “caixa preta”, onde as conexões entre termos e conceitos feitas durante o treinamento não são determinísticas e não podem ser interpretadas por humanos. Isso acarreta problemas de explicabilidade, repetibilidade, viés inconsciente e, potencialmente, perda de confiança e precisão. No entanto, a capacidade de conectar ideias semanticamente, de não estar vinculado a palavras-chave específicas ao fazer buscas, é extremamente poderosa:

Um exemplo de consulta semântica

Há ainda outra questão a considerar em relação às bases de dados vetoriais: elas não são motores de busca, são bases de dados! Quando uma busca por similaridade vetorial é realizada, os termos da consulta são codificados para encontrar um conjunto de coordenadas (de incorporação) dentro do espaço vetorial do modelo. Essas coordenadas são então usadas como o alvo para encontrar os documentos que são os "vizinhos mais próximos" do alvo — o que significa que a classificação de um documento (ou sua posição nos resultados) é determinada pela distância de similaridade calculada entre as coordenadas desse documento e as coordenadas da consulta. Em que direção a classificação deve ter prioridade? Qual dos contextos possíveis está mais próximo da intenção do usuário? A imagem que me vem à mente é uma cena do filme Stargate, onde temos os seis pontos de coordenadas que se cruzam para nos indicar o destino (o alvo), mas não conseguimos chegar lá sem conhecer o "sétimo símbolo" - as coordenadas do ponto de partida que representam a intenção subjetiva do usuário. Assim, em vez de a classificação relativa dos vetores ser baseada em uma esfera de similaridade cada vez maior e indiferenciada, ao considerarmos a intenção subjetiva da consulta por meio de sintaxe expressiva e pontuação de relevância, podemos obter algo semelhante a um cilindro de relevância subjetiva graduada.

As capacidades de inferência de um LLM podem ajudar a identificar o contexto mais provável para a consulta, mas o problema é que , sem essa ajuda, as coordenadas da consulta recebida só podem ser determinadas pela forma como o modelo foi originalmente treinado.

De certa forma, pode-se dizer que a similaridade vetorial vai ao extremo oposto da correspondência estrita por palavras-chave — sua força reside na capacidade de superar os problemas de incompatibilidade de termos, mas quase em excesso: os modelos de similaridade de palavras tendem a unificar conceitos relacionados em vez de diferenciá-los. A similaridade vetorial melhora nossa capacidade de combinar conteúdo semanticamente, mas não garante precisão, pois pode ignorar palavras-chave exatas e detalhes específicos que não são suficientemente desambiguados pelo modelo. A busca por similaridade vetorial é poderosa por si só, mas precisamos de maneiras de correlacionar os resultados que obtemos de um banco de dados vetorial com os resultados de outros métodos de recuperação.

Técnicas de reclassificação

Agora é um bom momento para mencionar uma técnica geral chamada reclassificação, que reavalia ou normaliza os conjuntos de resultados para uma ordem de classificação unificada. A necessidade de reclassificação pode ser devida a resultados de múltiplas fontes ou métodos de recuperação que possuem mecanismos de classificação/pontuação diferentes (ou nenhum, como no caso do SQL!), ou a reclassificação pode ser usada para alinhar semanticamente os resultados de fontes não semânticas à consulta do usuário. A reclassificação é uma operação de segunda etapa, ou seja, um conjunto de resultados que foram coletados por algum método de recuperação inicial (ou seja, Em seguida, os métodos de busca (SQL, busca lexical, busca vetorial) são reordenados com um método de pontuação diferente.

Existem diversas abordagens disponíveis, incluindo Learning-To-Rank (LTR) e Reciprocal Rank Fusion (RRF) — o LTR é útil para capturar características dos resultados de pesquisa (curtidas, avaliações, cliques, etc.) e usá-las para pontuar e impulsionar ou influenciar os resultados. O RRF é perfeito para mesclar resultados retornados de diferentes modalidades de consulta (por exemplo, pesquisas lexicais e em bancos de dados vetoriais) juntas em uma única lista de resultados. O Elastic também oferece a flexibilidade de ajustar as pontuações usando métodos de reclassificação linear .

Uma das técnicas de reclassificação mais eficazes, no entanto, é a reclassificação semântica, que utiliza a compreensão semântica de um modelo de aprendizado de máquina para analisar os vetores de incorporação da consulta e dos resultados em conjunto e, em seguida, aplicar a pontuação/repontuação de relevância para determinar a ordem final. A reclassificação semântica requer, obviamente, uma conexão com um modelo de reclassificação, e o Elasticsearch fornece uma API de Inferência que permite criar endpoints de reclassificação que utilizam modelos integrados (Elastic Rerank), modelos de terceiros importados ou serviços hospedados externamente, como Cohere ou Google Vertex AI. Em seguida, você pode realizar a reclassificação por meio da sintaxe de abstração de consulta do recuperador :

Um exemplo de operação de reclassificação de recuperação em múltiplos estágios

Parece ótimo, não é? Podemos realizar uma reclassificação de resultados de fontes distintas e chegar perto de uma compreensão semântica de todos os tipos de conteúdo... A reclassificação semântica pode ser dispendiosa tanto em termos computacionais quanto de tempo de processamento, e por isso, só pode ser feita de forma viável em um número limitado de resultados, o que significa que a forma como esses resultados iniciais são obtidos é importante.

O método de recuperação de contexto é importante.

A intenção subjetiva é um fator importante para determinar a precisão de um resultado e avaliar sua relevância. Sem a possibilidade de considerar a intenção do usuário ao realizar a consulta (expressa por meio de sintaxe flexível ou por reclassificação em um segundo estágio), só podemos selecionar entre os contextos existentes já codificados no espaço do modelo. Normalmente, lidamos com essa falta de contexto por meio de técnicas como a Geração de Aumento de Recuperação (RAG). O RAG funciona alterando as coordenadas da consulta ao incluir termos relacionados adicionais retornados de uma pré-consulta para obter dados contextualmente relevantes. Isso torna o mecanismo que fornece esse contexto adicional e seu método inicial de recuperação ainda mais importantes para a precisão do contexto!

Vamos analisar os diferentes métodos de recuperação de contexto e como eles podem ajudar ou prejudicar uma operação RAG:

• A recuperação de pesquisa híbrida sem um mecanismo de busca ainda carece de relevância subjetiva. Se a plataforma que fornece o RAG for baseada principalmente em SQL (o que inclui a maioria das plataformas de "data lake"), ela não terá pontuação de relevância na fase inicial de recuperação. Muitas plataformas de data lake oferecem sua própria versão de recuperação híbrida (não busca), geralmente combinando técnicas de reclassificação como reclassificação semântica e RRF em seus resultados de recuperação baseados em SQL e em bancos de dados vetoriais. Uma simples ordenação é obviamente insuficiente para uma classificação subjetiva, mas mesmo quando usada como base para uma operação de reclassificação semântica de segundo estágio, o SQL como recuperação de primeiro estágio torna-se um problema quando a reclassificação semântica é realizada apenas nos "k melhores" resultados — sem alguma forma de pontuar os resultados na recuperação, que garantia temos de que os melhores resultados estão realmente entre os primeiros resultados?

• A similaridade vetorial por si só não é suficiente para o RAG. Na verdade, isso se deve a uma série de problemas que se acumulam: a perda de dados inerente ao processo de incorporação, juntamente com métodos ingênuos de segmentação, a forma como a similaridade é calculada e a ausência crucial do componente de intenção subjetiva. Um dos principais objetivos do RAG é fundamentar as interações da IA generativa na verdade objetiva, tanto para evitar alucinações quanto para informar o LLM sobre informações privadas que ele desconhecia durante o treinamento. Podemos usar o contexto adicional fornecido pelo RAG para restringir e direcionar os LLMs a considerarem as conexões e os detalhes que sabemos serem mais importantes para responder à questão em análise. Para isso, precisamos usar abordagens semânticas e lexicais.

• RAG baseado em grep/regex de arquivo. Há setores do universo da IA agente que apontam para o uso de janelas de contexto vastamente ampliadas que acessam arquivos locais via grep e regex para RAG (Random Access Groups - Grupos de Acesso Aleatório) em vez de plataformas de recuperação externas. A ideia é que, com uma janela contextual muito maior disponível, os profissionais de Letras e Literatura (LLMs) poderão fazer conexões conceituais dentro de seu próprio espaço de pensamento, em vez de depender de fragmentos isolados e de múltiplos métodos/plataformas de recuperação de informações para coletar informações relevantes. Embora seja verdade, em teoria, que ter um documento inteiro forneça uma visão mais completa do que segmentos de um documento, isso só funciona em domínios de dados pequenos (ou, por exemplo, ao fornecer arquivos para vibecoding) e, mesmo assim, o método de recuperação inicial é uma varredura de todos os documentos com correspondência apenas por palavra-chave.

A busca é mais do que a recuperação de informações.

Os mecanismos de busca são projetados especificamente para tornar as consultas o mais rápidas e flexíveis possível. Internamente, utilizam estruturas de dados especializadas para armazenar e recuperar diferentes tipos de dados de maneiras que atendam às necessidades específicas de cada tipo de dado. O Elasticsearch oferece armazenamento e consulta otimizados para praticamente todos os tipos de dados, incluindo busca lexical em texto completo/não estruturado (correspondência, frase, proximidade, correspondência múltipla), correspondência e filtragem rápidas por palavra-chave (correspondência exata), intervalos numéricos, datas, endereços IP, e é muito flexível na forma como armazena estruturas de documentos (por exemplo, documentos aninhados ou achatados). O Elasticsearch também é um banco de dados vetorial nativo que pode armazenar e consultar tipos de vetores esparsos e densos, e continuamos a explorar maneiras inovadoras (por exemplo, Better Binary Quantization (BBQ) e DiskBBQ) para manter a fidelidade da pesquisa, ao mesmo tempo que melhoramos a velocidade, a escalabilidade e os custos associados ao conteúdo vetorizado. A plataforma Elasticsearch também oferece resiliência de dados e alta disponibilidade integradas, e inclui recursos de gerenciamento do ciclo de vida dos dados, como Snapshots pesquisáveis , que permitem manter dados acessados com pouca frequência ou com retenção de longo prazo em armazenamento de objetos econômico — mas ainda totalmente pesquisáveis.

A busca híbrida oferece o melhor de todos os mundos.

Busca híbrida (e não apenas recuperação híbrida!) Combina os pontos fortes da busca lexical tradicional com a compreensão semântica dos Modelos de Aprendizagem Lógica (LLMs) e da busca por similaridade vetorial. Essa sinergia permite direcionar resultados altamente relevantes na fase de recuperação por meio de qualquer uma das opções flexíveis de sintaxe de consulta que um mecanismo de busca oferece: opções de sintaxe orientadas por intenção e pontuação de relevância, recuperação de dados multimodais, filtragem, agregações e direcionamento. Com sintaxes de busca como ES|QL e mecanismos de recuperação em múltiplos estágios, podemos combinar de forma flexível a busca tradicional com a busca semântica, filtros e múltiplas técnicas de reclassificação, tudo em uma única requisição.

Uma das maiores vantagens da pesquisa híbrida é que suas consultas podem usar sintaxe especializada para vários tipos de dados diferentes simultaneamente. Essas diferentes sintaxes de consulta podem ser usadas não apenas para encontrar resultados, mas também como filtros ou agregações nos resultados. Por exemplo, um dos tipos de consulta mais comuns que frequentemente é combinado com outras sintaxes é a análise geoespacial. Você pode realizar ações como consultar resultados que possuam coordenadas geográficas dentro de uma distância específica de um ponto, solicitar agregações de seus resultados por região ou ainda agregações para rastrear e alertar sobre movimentos de entrada e saída de uma zona. Com a pesquisa híbrida, você tem a flexibilidade de combinar sintaxes para direcionar os resultados da maneira mais precisa, recuperando o conteúdo mais próximo do seu contexto.

Intervalo

Esta primeira parte conta a história de como a busca vetorial mudou a forma como conseguimos recuperar dados e prepara o terreno para as mudanças que os Modelos de Aprendizagem Baseados em Lógica (LLMs) trouxeram aos mecanismos de consulta que usamos para interagir com os dados. Vamos fingir que tivemos que dividir isso em várias partes para que os LLMs pudessem entender sem perder o contexto… ;-) Vamos aprender mais sobre por que isso é importante na Parte II: IA Agêntica e a necessidade de engenharia de contexto, e na Parte III, retornaremos à nossa discussão sobre busca híbrida.

Conheça o retriever linear!

Nesta postagem, apresentamos o recuperador linear , nossa mais recente adição para oferecer suporte à pesquisa híbrida! Ao contrário de rrf, o recuperador linear calcula uma soma ponderada em todas as consultas que correspondem a um documento. Essa abordagem preserva a importância relativa de cada documento dentro de um conjunto de resultados, ao mesmo tempo que permite controle preciso sobre a influência de cada consulta na pontuação final. Como resultado, ele fornece uma maneira mais intuitiva e flexível de ajustar a pesquisa híbrida.

Definindo um recuperador linear onde a pontuação final será calculada como:

É tão simples quanto:

Percebeu como é simples e intuitivo? (e muito parecido com rrf!) Essa configuração permite que você controle precisamente quanto cada tipo de consulta contribui para a classificação final, ao contrário de rrf, que depende apenas de classificações relativas.

Uma ressalva permanece: as pontuações knn podem ser estritamente limitadas, dependendo da métrica de similaridade usada. Por exemplo, com similaridade de cosseno ou produto escalar de vetores normalizados por unidade, as pontuações sempre estarão dentro do intervalo [0, 1] . Em contraste, as pontuações bm25 são menos previsíveis e não têm limites claramente definidos.

Escalando as pontuações: kNN vs BM25

Um desafio da busca híbrida é que diferentes recuperadores produzem pontuações em escalas diferentes. Considere, por exemplo, o seguinte cenário:

Pontuações da consulta A:

doc1

doc2

doc3

doc4

knn

0,347

0,35

0,348

0,346

bm25

100

1,5

1

0,5

Pontuações da consulta B:

doc1

doc2

doc3

doc4

knn

0,347

0,35

0,348

0,346

bm25

0,63

0,01

0,3

0,4

Você pode ver a disparidade acima: as pontuações kNN variam entre 0 e 1, enquanto as pontuações bm25 podem variar muito. Essa diferença dificulta a definição de pesos estáticos ideais para combinar os resultados.

Normalização para o resgate: o normalizador MinMax

Para resolver isso, introduzimos um normalizador minmax opcional que dimensiona as pontuações, independentemente para cada consulta, para o intervalo [0, 1] usando a seguinte fórmula:

Isso preserva a importância relativa de cada documento dentro do conjunto de resultados de uma consulta, facilitando a combinação de pontuações de diferentes recuperadores. Com a normalização, as pontuações se tornam:

Pontuações da consulta A:

doc1

doc2

doc3

doc4

knn

0,347

0,35

0,348

0,346

bm25

1,00

0,01

0,005

0,000

Pontuações da consulta B:

doc1

doc2

doc3

doc4

knn

0,347

0,35

0,348

0,346

bm25

1,00

0,000

0,465

0,645

Todas as pontuações agora estão no intervalo [0, 1] e otimizar a soma ponderada é muito mais simples, pois agora capturamos a importância (em relação à consulta) de um resultado em vez de sua pontuação absoluta e mantemos a consistência entre as consultas.

Exemplo de recuperador linear

Vamos ver um exemplo agora para mostrar a aparência do exemplo acima e como o recuperador linear aborda algumas das deficiências do rrf. O RRF depende somente de classificações relativas e não considera diferenças reais de pontuação. Por exemplo, dadas estas pontuações:

doc1

doc2

doc3

doc4

knn

0,347

0,35

0,348

0,346

bm25

100

1,5

1

0,5

pontuação rrf

0,03226

0,03252

0,03200

0,03125

rrf classificaria os documentos como:

No entanto, doc1 tem uma pontuação bm25 significativamente maior que as outras, o que rrf não consegue capturar porque só analisa classificações relativas. O recuperador linear , combinado com a normalização, contabiliza corretamente as pontuações e suas diferenças, produzindo uma classificação mais significativa:

doc1

doc2

doc3

doc4

knn

0,347

0,35

0,348

0,346

bm25

1

0,01

0,005

0

Como podemos ver acima, a ótima classificação do doc1 e score para bm25 são devidamente contabilizadas e refletidas nas pontuações finais. Além disso, todas as pontuações agora estão no intervalo [0, 1] para que possamos compará-las e combiná-las de uma forma muito mais intuitiva (e até mesmo criar processos de otimização offline).

Juntando tudo

Para aproveitar ao máximo o recuperador linear com normalização, a solicitação de pesquisa ficaria assim:

Essa abordagem combina o melhor dos dois mundos: ela mantém a flexibilidade e a pontuação intuitiva do recuperador linear , ao mesmo tempo em que garante uma escala de pontuação consistente com a normalização MinMax.

Assim como todos os nossos recuperadores, o recuperador linear pode ser integrado a qualquer nível de uma árvore hierárquica de recuperadores, com suporte para explicabilidade, destaque de correspondência, recolhimento de campo e muito mais.

Quando escolher o retriever linear e por que isso faz a diferença

O recuperador linear :

• Preserva a importância relativa aproveitando pontuações reais, não apenas classificações.

• Permite ajustes finos com contribuições ponderadas de diferentes consultas.

• Melhora a consistência usando a normalização, tornando a pesquisa híbrida mais robusta e previsível.

Conclusão

O recuperador linear já está disponível no Elasticsearch Serverless e nas versões 8.18 e 9.0! Mais exemplos e parâmetros de configuração também podem ser encontrados em nossa documentação. Experimente e veja como ele pode melhorar sua experiência de pesquisa híbrida — aguardamos seu feedback. Boa busca!

A Quepid auxilia as equipes de busca no processo de avaliação da qualidade da pesquisa:

• Criar conjuntos de consultas

• Criar listas de julgamento

• Calcular métricas de qualidade de pesquisa

• Compare diferentes algoritmos/classificadores de busca com base em métricas de qualidade de busca calculadas.

Para o nosso blog, vamos supor que administramos uma locadora de filmes e que nosso objetivo é melhorar a qualidade dos nossos resultados de busca.

Pré-requisitos

Este blog utiliza os dados e os mapeamentos do repositório es-tmdb. Os dados são do The Movie Database. Para acompanhar, crie um índice chamado tmdb com os mapeamentos e indexe os dados. Não importa se você configurar uma instância local ou usar uma implantação do Elastic Cloud para isso - qualquer uma funciona bem. Para este blog, pressupomos uma implementação no Elastic Cloud. Você pode encontrar informações sobre como indexar os dados no arquivo README do repositório es-tmdb.

Faça uma consulta de correspondência simples no campo de título para rocky para confirmar que você tem dados para pesquisar:

Você deverá ver 8 resultados.

Faça login no Quepid

O Quepid é uma ferramenta que permite aos usuários medir a qualidade dos resultados de pesquisa e executar experimentos offline para melhorá-la.

Você pode usar o Quepid de duas maneiras: usando a versão gratuita e disponível publicamente em https://app.quepid.com, ou instale o Quepid em uma máquina à qual você tenha acesso. Este post pressupõe que você esteja usando a versão gratuita hospedada. Se você deseja configurar uma instância do Quepid em seu ambiente, siga o Guia de Instalação.

Independentemente da configuração escolhida, você precisará criar uma conta, caso ainda não tenha uma.

Como configurar um caso do Quepid

O Quepid é organizado em torno de "Casos". Um Case armazena consultas juntamente com configurações de ajuste de relevância e instruções sobre como estabelecer uma conexão com seu mecanismo de busca.

• Para usuários iniciantes, selecione Criar seu primeiro caso de relevância.

• Usuários recorrentes podem selecionar Casos de Relevância no menu principal e clicar em + Criar um caso.

Dê um nome descritivo ao seu caso, por exemplo, "Linha de Base da Busca de Filmes", pois queremos começar a medir e aprimorar nossa busca de referência.

Confirme o nome selecionando Continuar.

Em seguida, estabelecemos uma conexão do Quepid com o mecanismo de busca. O Quepid pode se conectar a uma variedade de mecanismos de busca, incluindo o Elasticsearch.

A configuração irá variar dependendo da sua instalação do Elasticsearch e do Quepid. Para conectar o Quepid a uma implementação do Elastic Cloud, precisamos habilitar e configurar o CORS para nossa implementação do Elastic Cloud e ter uma chave de API pronta. Instruções detalhadas estão disponíveis no guia correspondente na documentação do Quepid.

Insira as informações do seu endpoint Elasticsearch (https://YOUR_ES_HOST:PORT/tmdb/_search) e quaisquer informações adicionais necessárias para conectar (a chave da API no caso de uma implantação do Elastic Cloud nas opções de configuração avançadas ), teste a conexão clicando em ping e selecione Continuar para ir para a próxima etapa.

Agora definimos quais campos queremos que sejam exibidos no caso. Selecione todas as opções que ajudarão nossos avaliadores humanos a avaliar posteriormente a relevância de um documento para uma determinada consulta.

Defina title como o Campo de Título, deixe _id como o Campo de ID e adicione overview, tagline, cast, vote_average, thumb:poster_path como Campos de Exibição Adicionais. A última entrada exibe pequenas imagens em miniatura dos filmes em nossos resultados para nos guiar visualmente, assim como aos avaliadores humanos.

Confirme as configurações de exibição selecionando o botão Continuar .

O último passo é adicionar consultas de pesquisa ao caso. Adicione as três consultas star wars, harrison ford e best action movie uma de cada vez através do campo de entrada e clique em Continuar.

Idealmente, um caso contém consultas que representam consultas reais de usuários e ilustram diferentes tipos de consultas. Por ora, podemos imaginar "Star Wars" como uma consulta que representa todas as buscas por títulos de filmes, "Harrison Ford" como uma consulta que representa todas as buscas por membros do elenco e "Melhor Filme de Ação" como uma consulta que representa todas as buscas por filmes de um gênero específico. Isso geralmente é chamado de conjunto de consultas.

Em um cenário de produção, amostraríamos consultas de dados de rastreamento de eventos aplicando técnicas estatísticas como a amostragem de Probabilidade Proporcional ao Tamanho e importaríamos essas consultas amostradas para o Quepid para incluir consultas do início (consultas frequentes) e da cauda (consultas infrequentes) em relação à sua frequência, o que significa que damos preferência a consultas mais frequentes sem excluir as raras.

Por fim, selecione Concluir e você será redirecionado para a interface do caso, onde verá as três consultas definidas.

Consultas e necessidades de informação

Para atingirmos nosso objetivo principal de criar uma lista de julgamentos, avaliadores humanos precisarão julgar um resultado de busca (normalmente um documento) para uma determinada consulta. Isso é chamado de par consulta/documento.

Às vezes, parece fácil saber o que um usuário queria ao analisar a consulta. A intenção por trás da consulta harrison ford é encontrar filmes estrelados por Harrison Ford, o ator. E quanto à consulta action? Sei que eu teria a tentação de dizer que a intenção do usuário é encontrar filmes do gênero ação. Mas quais? Os mais recentes, os mais populares, os melhores de acordo com as avaliações dos usuários? Ou será que o usuário quer encontrar todos os filmes que se chamam "Ação"? Existem pelo menos 12 (!) filmes chamados “Action” no The Movie Database e seus nomes diferem principalmente no número de pontos de exclamação no título.

Dois avaliadores humanos podem divergir na interpretação de uma pergunta cuja intenção não seja clara. Entenda a Necessidade de Informação: Uma Necessidade de Informação é um desejo consciente ou inconsciente por informação. Definir uma necessidade de informação ajuda os avaliadores humanos a julgarem os documentos em relação a uma consulta, desempenhando, portanto, um papel importante no processo de elaboração de listas de julgamento. Usuários experientes ou especialistas no assunto são bons candidatos para especificar as necessidades de informação. É uma boa prática definir as necessidades de informação a partir da perspectiva do usuário, pois são essas necessidades que os resultados da busca devem satisfazer.

Necessidades de informação para as consultas do nosso caso de “Linha de Base de Pesquisa de Filmes”:

1. Star Wars: O usuário deseja encontrar filmes ou séries da franquia Star Wars. Documentários sobre Star Wars podem ser relevantes.

2. Harrison Ford: O usuário deseja encontrar filmes estrelados pelo ator Harrison Ford. Filmes em que Harrison Ford desempenha um papel diferente, como o de narrador, podem ser relevantes.

3. Melhor filme de ação: O usuário deseja encontrar filmes de ação, de preferência aqueles com alta média de votos dos usuários.

Como definir necessidades de informação no Quepid

Para definir uma necessidade de informação no Quepid, acesse a interface do caso:

1. Abra uma pesquisa (por exemplo, star wars) e selecione Alternar notas.

2. Insira a necessidade de informação no primeiro campo e quaisquer observações adicionais no segundo campo:

3. Clique em Salvar.

Para um pequeno número de consultas, esse processo funciona bem. No entanto, ao expandir seu caso de três para 100 consultas (os casos do Quepid geralmente variam de 50 a 100 consultas), você pode querer definir as necessidades de informação fora do Quepid (por exemplo, em uma planilha) e, em seguida, carregá-las por meio da opção Importar e selecionar Necessidades de Informação.

Criar uma equipe no Quepid e compartilhar seu caso

Julgamentos colaborativos melhoram a qualidade das avaliações de relevância. Para formar uma equipe:

1. Navegue até "Equipes" no menu principal.

2. Clique em + Adicionar novo, insira um nome para a equipe (por exemplo, "Avaliadores de relevância de pesquisa") e clique em Criar.

3. Adicione membros digitando seus endereços de e-mail e clicando em Adicionar Usuário.

4. Na interface do caso, selecione Compartilhar caso.

5. Selecione a equipe apropriada e confirme.

Criar um livro de julgamentos no Quepid

Um livro no Quepid permite que vários avaliadores avaliem pares de consulta/documento de forma sistemática. Para criar um:

1. Na interface do processo, acesse Julgamentos e clique em + Criar um Livro.

2. Configure o livro com um nome descritivo, atribua-o à sua equipe, selecione um método de pontuação (por exemplo, DCG@10) e defina a estratégia de seleção (avaliadores únicos ou múltiplos). Utilize as seguintes configurações para o livro:

• Nome: “Pesquisa de Filmes em Escala de 0 a 3”

• Equipes com as quais você deseja compartilhar este livro: Marque a caixa da equipe que você criou.

• Marcador: DCG@10

3. Clique em Criar livro.

O nome é descritivo e contém informações sobre o que é pesquisado em (“Filmes”) e também a escala das avaliações (“0-3”). O Scorer DCG@10 selecionado define a forma como a métrica de pesquisa será calculada. “DCG” é a abreviação de Ganho Cumulativo Descontado e “@10” é o número de resultados do topo considerados no cálculo da métrica.

Neste caso, estamos usando uma métrica que mede o ganho de informação e o combina com a ponderação posicional. Pode haver outras métricas de pesquisa mais adequadas ao seu caso de uso, e escolher a correta é um desafio por si só.

Preencha o livro com pares de consulta/documento

Para adicionar pares de consulta/documento para avaliação de relevância, siga estes passos:

1. Na interface do processo, navegue até "Sentenças".

2. Selecione o livro que você criou.

3. Clique em "Preencher Livro" e confirme selecionando "Atualizar Pares de Consulta/Documento para o Livro".

Esta ação gera pares com base nos principais resultados de pesquisa para cada consulta, prontos para avaliação pela sua equipe.

Deixar sua equipe de avaliadores humanos julgar

Até o momento, as etapas concluídas foram de natureza bastante técnica e administrativa. Agora que essa preparação necessária foi concluída, podemos deixar nossa equipe de juízes fazer seu trabalho. Em essência, a função do juiz é avaliar a relevância de um determinado documento para uma questão específica. O resultado desse processo é a lista de julgamentos, que contém todos os rótulos de relevância para os pares de documentos de consulta avaliados. A seguir, esse processo e sua interface serão explicados com mais detalhes.

Visão geral da interface Human Rating

A interface de Avaliação Humana do Quepid foi projetada para avaliações eficientes:

• Consulta: Exibe o termo de pesquisa.

• Necessidade de informação: Mostra a intenção do usuário.

• Diretrizes de pontuação: Fornece instruções para avaliações consistentes.

• Metadados do documento: Apresentam detalhes relevantes sobre o documento.

• Botões de avaliação: Permitem que os avaliadores atribuam julgamentos com os respectivos atalhos de teclado.

Usando a interface de Human Rating

Como avaliador humano, acesso a interface através da visão geral do livro:

1. Navegue até a interface do caso e clique em Julgamentos.

2. Clique em Mais avaliações são necessárias!

O sistema apresentará um par consulta/documento que ainda não foi avaliado e que requer julgamentos adicionais. Isso é determinado pela estratégia de seleção do livro:

• Avaliador único: Um único julgamento por par consulta/documento.

• Avaliadores Múltiplos: Até três avaliações por par consulta/documento.

Avaliando pares de consulta/documento

Vamos analisar alguns exemplos. Ao seguir este guia, você provavelmente se deparará com diferentes filmes. No entanto, os princípios de classificação permanecem os mesmos.

Nosso primeiro exemplo é o filme “Heroes” para a consulta harrison ford:

Primeiro analisamos a consulta, depois a necessidade de informação e, em seguida, avaliamos o filme com base nos metadados fornecidos.

Este filme é um resultado relevante para nossa pesquisa, já que Harrison Ford faz parte do elenco. Podemos considerar os filmes mais recentes como subjetivamente mais relevantes, mas isso não faz parte da nossa necessidade de informação. Assim, classificamos este documento como "Perfeito", o que corresponde a um 3 em nossa escala de notas.

Nosso próximo exemplo é o filme “Ford vs Ferrari” para a pesquisa “Harrison Ford”:

Seguindo a mesma prática, avaliamos esta consulta/documento analisando a consulta, a necessidade de informação e, em seguida, o quão bem os metadados do documento correspondem à necessidade de informação.

Este é um resultado ruim. Provavelmente vemos esse resultado porque um dos nossos termos de pesquisa, "ford", corresponde ao título. Mas Harrison Ford não desempenha nenhum papel neste filme, nem em nenhum outro. Assim, classificamos este documento como "Ruim", o que corresponde a 0 em nossa escala de notas.

Nosso terceiro exemplo é o filme “Action Jackson” para a busca “melhor filme de ação”:

Parece um filme de ação, então a necessidade de informação está pelo menos parcialmente satisfeita. No entanto, a média dos votos é de 5,4 em 10. E isso faz com que este filme provavelmente não seja o melhor filme de ação da nossa coleção. Isso me levaria, como juiz, a classificar este documento como "Razoável", o que corresponde a 1 em nossa escala de classificação.

Esses exemplos ilustram o processo de avaliação de pares de consulta/documento com o Quepid, em particular, em um nível mais alto e também em geral.

Práticas recomendadas para avaliadores humanos

Os exemplos apresentados podem dar a impressão de que é fácil chegar a julgamentos explícitos. Mas criar um programa confiável de avaliação humana não é tarefa fácil. É um processo repleto de desafios que podem facilmente comprometer a qualidade dos seus dados:

• Os avaliadores humanos podem ficar fatigados devido a tarefas repetitivas.

• Preferências pessoais podem distorcer julgamentos.

• O nível de conhecimento especializado varia de juiz para juiz.

• Os avaliadores frequentemente precisam conciliar múltiplas responsabilidades.

• A relevância percebida de um documento pode não corresponder à sua real relevância para uma consulta.

Esses fatores podem resultar em julgamentos inconsistentes e de baixa qualidade. Mas não se preocupe – existem práticas recomendadas comprovadas que podem ajudá-lo a minimizar esses problemas e a construir um processo de avaliação mais robusto e confiável:

• Avaliação consistente: Analise a consulta, a necessidade de informação e os metadados do documento em ordem.

• Consulte as diretrizes: Utilize as diretrizes de pontuação para manter a consistência. As diretrizes de avaliação podem conter exemplos de quando aplicar cada nota, ilustrando o processo de julgamento. Realizar uma consulta com avaliadores humanos após o primeiro lote de julgamentos provou ser uma boa prática para identificar casos extremos desafiadores e onde é necessário suporte adicional.

• Utilize as opções: Em caso de dúvida, use "Vou avaliar depois" ou "Não sei dizer", fornecendo explicações quando necessário.

• Faça pausas: Pausas regulares ajudam a manter a qualidade do julgamento. O Quepid ajuda nas pausas regulares, lançando confetes sempre que um avaliador humano termina um lote de julgamentos.

Seguindo esses passos, você estabelece uma abordagem estruturada e colaborativa para a criação de listas de julgamento no Quepid, aumentando a eficácia dos seus esforços de otimização da relevância da busca.

Próximas etapas

Para onde ir a partir daqui? As listas de julgamento são apenas um passo fundamental para melhorar a qualidade dos resultados de pesquisa. Eis os próximos passos:

Calcule métricas e comece a experimentar

Uma vez que as listas de avaliações estejam disponíveis, aproveitar essas avaliações e calcular as métricas de qualidade da busca é uma progressão natural. O Quepid calcula automaticamente a métrica configurada para o caso atual quando os julgamentos estão disponíveis. As métricas são implementadas como "Pontuadores" e você pode fornecer as suas próprias caso as opções suportadas não incluam a sua favorita!

Acesse a interface do caso, navegue até Selecionar Avaliador, escolha DCG@10 e confirme clicando em Selecionar Avaliador. O Quepid agora calculará o DCG@10 por consulta e também a média geral das consultas para quantificar a qualidade dos resultados da pesquisa para o seu caso.

Agora que a qualidade dos seus resultados de pesquisa foi quantificada, você pode executar os primeiros experimentos. A experimentação começa com a geração de hipóteses. Ao analisar as três consultas na captura de tela após classificá-las, fica evidente que elas apresentam desempenhos muito diferentes em termos de qualidade de busca: "Star Wars" tem um desempenho bastante bom, "Harrison Ford" parece razoável, mas o maior potencial reside em "Melhor Filme de Ação".

Expandindo essa consulta, vemos seus resultados e podemos mergulhar nos detalhes minuciosos, explorando por que os documentos corresponderam e o que influencia suas pontuações:

Ao clicar em “Explicar consulta” e acessar a guia “Análise”, vemos que a consulta é uma DisjunctionMaxxQuery que pesquisa em três campos: cast, overview e title:

Normalmente, como engenheiros de busca, conhecemos alguns detalhes específicos do domínio da nossa plataforma de busca. Nesse caso, podemos saber que temos um campo de gêneros . Vamos adicionar isso à consulta e ver se a qualidade da pesquisa melhora.

Usamos o ambiente de testes de consulta (Query Sandbox) que é aberto ao selecionar "Ajustar Relevância" na interface do caso. Explore esta opção adicionando o campo de gêneros que você pesquisou:

Clique em "Executar minhas pesquisas novamente"! E veja os resultados. Será que mudaram? Infelizmente não. Agora temos muitas opções para explorar, basicamente todas as opções de consulta que o Elasticsearch oferece:

• Poderíamos aumentar o peso do campo de gêneros.

• Poderíamos adicionar uma função que aumentasse a relevância dos documentos com base na média de votos.

• Poderíamos criar uma consulta mais complexa que priorizasse documentos com base na média de votos apenas se houvesse uma forte correspondência de gêneros.

• …

A melhor coisa de ter todas essas opções e explorá-las no Quepid é que temos uma maneira de quantificar os efeitos não apenas na consulta específica que estamos tentando melhorar, mas em todas as consultas que temos em nosso caso. Isso nos impede de melhorar uma consulta com baixo desempenho sacrificando a qualidade dos resultados de pesquisa em outras consultas. Podemos iterar de forma rápida e barata e validar o valor de nossa hipótese sem qualquer risco, tornando a experimentação offline uma capacidade fundamental de todas as equipes de busca.

Medir a confiabilidade entre avaliadores

Mesmo com descrições de tarefas, necessidades de informação e uma interface de avaliação humana como a que a Quepid oferece, os avaliadores humanos podem discordar.

A discordância em si não é algo ruim, muito pelo contrário: medir a discordância pode revelar problemas que você talvez queira abordar. A relevância pode ser subjetiva, as consultas podem ser ambíguas e os dados podem estar incompletos ou incorretos. O coeficiente Kappa de Fleiss é uma medida estatística de concordância entre avaliadores, e existe um exemplo de planilha no Quepid que você pode usar. Para encontrá-lo, selecione Notebooks na navegação de nível superior e selecione o notebook Fleiss Kappa.ipynb na pasta examples .

Conclusão

O Quepid permite que você enfrente até mesmo os desafios mais complexos de relevância de pesquisa e continua a evoluir: a partir da versão 8, o Quepid oferece suporte a julgamentos gerados por IA, o que é particularmente útil para equipes que desejam dimensionar seu processo de geração de julgamentos.

Os fluxos de trabalho do Quepid permitem criar listas de julgamento escaláveis de forma eficiente, o que resulta em resultados de pesquisa que realmente atendem às necessidades do usuário. Com as listas de critérios de avaliação estabelecidas, você terá uma base sólida para medir a relevância da pesquisa, implementar melhorias e proporcionar melhores experiências ao usuário.

Ao prosseguir, lembre-se de que o ajuste de relevância é um processo contínuo. Listas de avaliação permitem que você avalie seu progresso de forma sistemática, mas são mais eficazes quando combinadas com experimentação, análise de métricas e melhorias iterativas.

Para ler mais

• Documentação Quepid:

  • Relevância é um esporte coletivo

  • Quépid para avaliadores humanos

  • Como conectar o Quepid ao Elastic Cloud

• Repositório Quepid no Github

• Conheça Pete, uma série de posts no blog sobre como melhorar a busca em e-commerce.

• Slack de Relevância: entre no canal #quepid

Faça parceria com a Open Source Connections para transformar suas capacidades de busca e IA e capacitar sua equipe a evoluí-las continuamente. Nosso histórico comprovado abrange o mundo todo, com clientes alcançando consistentemente melhorias significativas na qualidade da busca, na capacidade da equipe e no desempenho dos negócios. Entre em contato conosco hoje mesmo para saber mais.

Filtros vs facetas

Antes de começarmos, vamos definir o que são filtros e facetas. Os filtros são atributos predefinidos usados para restringir um conjunto de resultados. Em um mercado online, por exemplo, os filtros estão disponíveis mesmo antes de uma busca ser realizada. O usuário pode selecionar uma categoria, como "Videogames", antes de pesquisar por "PS5", refinando a busca para um subconjunto mais específico em vez de toda a base de dados. Isso aumenta significativamente as chances de se obter resultados mais relevantes.

Os facets funcionam de forma semelhante aos filtros, mas só ficam disponíveis após a realização da pesquisa. Em outras palavras, a pesquisa retorna resultados e, com base neles, é gerada uma nova lista de opções de refinamento. Por exemplo, ao pesquisar um console PS5, características como capacidade de armazenamento, custo de envio e cor podem ser exibidas para ajudar os usuários a escolher o produto ideal.

Agora que definimos filtros e facetas, vamos discutir o impacto das abordagens clássicas e baseadas em Aprendizado de Máquina (ML) em sua implementação e uso. Cada método possui vantagens e desafios que influenciam a eficiência da busca.

Abordagem clássica de filtros e facetas

Nessa abordagem, os filtros e as facetas são definidos manualmente com base em regras predefinidas. Isso significa que os atributos disponíveis para refinar a busca são fixos e planejados antecipadamente, levando em consideração a estrutura do catálogo e as necessidades do usuário.

Por exemplo, em um marketplace, categorias como "Eletrônicos" ou "Moda" podem ter filtros específicos como marca, formato e faixa de preço. Essas regras são criadas estaticamente, garantindo consistência na experiência de busca, mas exigindo ajustes manuais sempre que novos produtos ou categorias surgirem.

Embora essa abordagem proporcione previsibilidade e controle sobre os filtros e facetas exibidos, ela pode ser limitada quando surgem novas tendências que exigem refinamento dinâmico.

Prós:

• Previsibilidade e controle: Como os filtros e as facetas são definidos manualmente, o gerenciamento torna-se mais fácil.

• Baixa complexidade: Não há necessidade de treinar modelos.

• Facilidade de manutenção: Como as regras são predefinidas, ajustes e correções podem ser feitos rapidamente.

Contras:

• Reindexação necessária para novos filtros: Sempre que um novo atributo precisar ser usado como filtro, todo o conjunto de dados deverá ser reindexado para garantir que os documentos contenham essa informação.

• Falta de adaptação dinâmica: os filtros são estáticos e não se ajustam automaticamente às mudanças no comportamento do usuário.

Implementação de filtros/facetas – Abordagem clássica

Nas Ferramentas de Desenvolvimento, Kibana, criaremos uma demonstração de filtros/facetas usando a abordagem clássica.

Primeiro, definimos o mapeamento para estruturar o índice:

Os campos de marca e armazenamento são definidos como palavras-chave, permitindo que sejam usados diretamente em agregações (facetas). O campo de preço é do tipo float, permitindo a criação de intervalos de preço.

Na próxima etapa, os dados do produto serão indexados:

Agora, vamos recuperar as características clássicas agrupando os resultados por marca, armazenamento e faixa de preço. Na consulta, foi definido o tamanho:0. Nesse cenário, o objetivo é recuperar apenas os resultados da agregação, sem incluir os documentos correspondentes à consulta.

A resposta incluirá contagens para Marca, Armazenamento e Preço, ajudando a criar filtros e segmentações.

Abordagem baseada em machine learning/IA para filtros e facetas

Nessa abordagem, modelos de Aprendizado de Máquina (ML), incluindo técnicas de Inteligência Artificial (IA), analisam atributos de dados para gerar filtros e facetas relevantes. Em vez de depender de regras predefinidas, o aprendizado de máquina/inteligência artificial aproveita as características dos dados indexados. Isso possibilita a descoberta dinâmica de novas facetas e filtros.

Prós:

• Atualizações automáticas: Novos filtros e facetas são gerados automaticamente, sem a necessidade de ajustes manuais.

• Descoberta de novos atributos: Pode identificar características de dados anteriormente não consideradas como filtros, enriquecendo a experiência de busca.

• Redução do esforço manual: a equipe não precisa definir e atualizar constantemente as regras de filtragem, pois a IA aprende com os dados disponíveis.

Contras:

• Complexidade de manutenção: O uso de modelos pode exigir pré-validação para garantir a consistência dos filtros gerados.

• Requer experiência em aprendizado de máquina e inteligência artificial: A solução exige profissionais qualificados para ajustar e monitorar o desempenho do modelo.

• Risco de filtros irrelevantes: Se o modelo não estiver bem calibrado, poderá gerar facetas que não sejam úteis para os usuários.

• Custo: O uso de aprendizado de máquina e inteligência artificial pode exigir serviços de terceiros, aumentando os custos operacionais.

Vale ressaltar que, mesmo com um modelo bem calibrado e um prompt bem elaborado, as facetas geradas ainda devem passar por uma etapa de revisão. Essa validação pode ser manual ou baseada em regras de moderação, garantindo que o conteúdo seja apropriado e seguro. Embora não seja necessariamente uma desvantagem, é importante considerar a qualidade e a adequação dos recursos antes que sejam disponibilizados aos usuários.

Implementação de filtros/facetas – abordagem de IA

Nesta demonstração, utilizaremos um modelo de IA para analisar automaticamente as características do produto e sugerir atributos relevantes. Com um prompt bem estruturado, extraímos informações do catálogo e as transformamos em filtros e facetas. A seguir, apresentamos cada etapa do processo.

Inicialmente, usaremos a API de Inferência para registrar um endpoint para integração com um serviço de aprendizado de máquina. Abaixo, segue um exemplo de integração com o serviço da OpenAI.

Agora, definimos o pipeline para executar o prompt e obter os novos filtros gerados pelo modelo.

Executando uma simulação desse pipeline para o produto "PlayStation 5", com a seguinte descrição:

Jogabilidade impressionante: Maravilhe-se com gráficos deslumbrantes e experimente os recursos do novo PS5.

Imersão de tirar o fôlego: Descubra uma experiência de jogo mais profunda com suporte para feedback tátil, gatilhos adaptáveis e tecnologia de áudio 3D.

Design fino: Com o PS5 Digital Edition, os jogadores têm acesso a uma poderosa tecnologia de jogos em um design elegante e compacto.

1 TB de armazenamento: Tenha seus jogos favoritos prontos para jogar com 1 TB de armazenamento SSD integrado.

Compatibilidade com versões anteriores e Game Boost: O console PS5 pode rodar mais de 4.000 jogos de PS4. Com o Game Boost, você pode desfrutar de taxas de quadros mais rápidas e suaves até mesmo em alguns dos melhores jogos para PS4.

Vamos observar a saída de comando gerada por esta simulação.

Agora, um novo campo, dynamic_facets, será adicionado ao novo índice para armazenar as facetas geradas pela IA.

Utilizando a API Reindex, vamos reindexar o índice de videogames para videogames_1, aplicando o pipeline generate_filter_ai durante o processo. Este pipeline irá gerar automaticamente facetas dinâmicas durante a indexação.

Agora, vamos executar uma pesquisa e obter os novos filtros:

Resultados:

Para simbolizar a implementação das facetas, segue abaixo um exemplo simples de interface:

O código da interface do usuário apresentado está aqui.

Conclusão

Ambas as abordagens para a criação de filtros e facetas têm seus benefícios e pontos de atenção. A abordagem clássica, baseada em regras manuais, oferece controle e custos mais baixos, mas requer atualizações constantes e não se adapta dinamicamente a novos produtos ou recursos.

Por outro lado, a abordagem baseada em IA e Aprendizado de Máquina automatiza a extração de facetas, tornando a busca mais flexível e permitindo a descoberta de novos atributos sem intervenção manual. No entanto, essa abordagem pode ser mais complexa de implementar e manter, exigindo calibração para garantir resultados consistentes.

A escolha entre as abordagens clássicas e as baseadas em IA depende das necessidades e da complexidade do negócio. Para cenários mais simples, onde os atributos dos dados são estáveis e previsíveis, a abordagem clássica pode ser mais eficiente e fácil de manter, evitando custos desnecessários com infraestrutura e modelos de IA. Por outro lado, o uso de aprendizado de máquina/inteligência artificial para extrair facetas pode agregar valor significativo, melhorando a experiência de busca e tornando a filtragem mais inteligente.

O importante é avaliar se a automação justifica o investimento ou se uma solução mais tradicional já atende às necessidades do negócio de forma eficaz.

Este blog explora como grandes modelos de linguagem (LLMs) podem ser usados para identificar e gerar sinônimos automaticamente, permitindo que esses termos sejam carregados programaticamente na API de sinônimos do Elasticsearch.

Quando usar sinônimos?

O uso de sinônimos pode ser uma solução mais rápida e econômica em comparação com a busca vetorial. Sua implementação é mais simples, pois não requer conhecimento profundo de embeddings ou um processo complexo de ingestão de vetores.

Além disso, o consumo de recursos é menor, uma vez que a busca vetorial exige maior capacidade de armazenamento e memória para indexação e recuperação de dados.

Outro aspecto importante é a regionalização da busca. Com sinônimos, é possível adaptar os termos de acordo com o idioma e os costumes locais. Isso é útil em situações em que os embeddings podem não corresponder a expressões regionais ou termos específicos de cada país. Por exemplo, algumas palavras ou siglas podem ter significados diferentes dependendo da região, mas são naturalmente tratadas como sinônimos pelos usuários locais. No Brasil, isso é bastante comum. "Abacaxi" e "ananás" são a mesma fruta (abacaxi), mas o segundo termo é mais comumente usado em algumas regiões do Nordeste. Da mesma forma, o conhecido "pão francês" no Sudeste pode ser conhecido como "pão careca" no Nordeste.

Como usar LLMs para gerar sinônimos?

Para obter sinônimos automaticamente, podemos usar Modelos de Aprendizagem Baseados em Lógica (LLMs), que analisam o contexto de um termo e sugerem variações apropriadas. Essa abordagem permite a expansão dinâmica de sinônimos, garantindo uma busca mais ampla e precisa sem depender de um dicionário fixo.

Nesta demonstração, usaremos um modelo de linguagem natural (LLM) para gerar sinônimos para produtos de comércio eletrônico. Muitas pesquisas retornam poucos ou nenhum resultado devido a variações nos termos pesquisados. Com sinônimos, podemos resolver esse problema. Por exemplo, uma busca por "smartphone" pode abranger diferentes modelos de celulares, garantindo que os usuários encontrem os produtos que procuram.

Pré-requisitos

Antes de começarmos, precisamos configurar o ambiente e definir as dependências necessárias. Utilizaremos a solução fornecida pela Elastic para executar o Elasticsearch e o Kibana localmente em um contêiner Docker. O código será escrito em Python, versão 3.9.6, com as seguintes dependências:

Criando o índice de produtos

Inicialmente, criaremos um índice de produtos sem suporte a sinônimos. Isso nos permitirá validar as consultas e compará-las com um índice que inclui sinônimos.

Para criar o índice, carregamos em massa um conjunto de dados de produtos usando o seguinte comando no Kibana DevTools:

Gerando sinônimos com LLM

Nesta etapa, utilizaremos um modelo de lógica latente (LLM) para gerar sinônimos dinamicamente. Para atingir esse objetivo, integraremos a API da OpenAI, definindo um modelo e um prompt adequados. O LLM receberá a categoria e o nome do produto, garantindo que os sinônimos sejam contextualmente relevantes.

A partir do índice de produtos criado, recuperaremos todos os itens da categoria "Eletrônicos" e enviaremos seus nomes para o LLM. O resultado esperado será algo como:

Com os sinônimos gerados, podemos registrá-los no Elasticsearch usando a API de Sinônimos.

Gerenciando sinônimos com a API de Sinônimos

A API de Sinônimos oferece uma maneira eficiente de gerenciar conjuntos de sinônimos diretamente dentro do sistema. Cada conjunto de sinônimos consiste em regras de sinonímia, onde um grupo de palavras é tratado como equivalente nas buscas.

Exemplo de criação de um conjunto de sinônimos

Isso cria um conjunto chamado "meu-conjunto-de-sinônimos", onde "olá" e "oi" são tratados como equivalentes, assim como "tchau" e "adeus".

Implementação da criação de sinônimos para o catálogo de produtos.

A seguir, está o método responsável por construir um conjunto de sinônimos e inseri-lo no Elasticsearch. As regras de sinônimos são geradas com base no mapeamento de sinônimos sugerido pelo LLM. Cada regra possui um ID, correspondente ao nome do produto no formato slug, e a lista de sinônimos calculada pelo LLM.

A seguir, está a carga útil da solicitação para criar o conjunto de sinônimos:

Com o conjunto de sinônimos criado no cluster, podemos prosseguir para a próxima etapa, que é a criação de um novo índice com suporte a sinônimos usando o conjunto definido.

O código Python completo, com os sinônimos gerados pelo LLM e a criação do conjunto de sinônimos definida pela API de Sinônimos, encontra-se abaixo:

Criando um índice com suporte a sinônimos

Um novo índice será criado onde todos os dados do índice products serão reindexados. Este índice usará o synonyms_filter, que aplica o products-synonyms-set criado anteriormente.

A seguir, o mapeamento de índice configurado para usar sinônimos:

Reindexando o índice products

Agora, usaremos a API Reindex para migrar os dados do índice products para o novo índice products_02 , que inclui suporte a sinônimos. O seguinte código foi executado no Kibana DevTools:

Após a migração, o índice products_02 será preenchido e estará pronto para validar pesquisas usando o conjunto de sinônimos configurado.

Validação da pesquisa com sinônimos

Vamos comparar os resultados da pesquisa entre os dois índices. Executaremos a mesma consulta em ambos os índices e validaremos se os sinônimos estão sendo usados para recuperar os resultados.

Pesquisar no índice products (sem sinônimos)

Usaremos o Kibana para realizar buscas e analisar os resultados. No menu Analytics > Discovery, criaremos uma visualização de dados para visualizar os dados dos índices que criamos.

Dentro do Discovery, clique em Visualização de Dados e defina um nome e um padrão de índice. Para o índice "produtos", usaremos o padrão "produtos ". Em seguida, repetiremos o processo para criar uma nova visualização de dados para o índice "products_02", usando o padrão "products_02" .

Com as visualizações de dados configuradas, podemos retornar a Analytics > Discovery e iniciar as validações.

Aqui, após selecionar os produtos DataView e pesquisar pelo termo "tablet", não obtemos resultados, embora saibamos que existem produtos como "Kindle Paperwhite" e "Apple iPad Air".

Pesquisar no índice products_02 (suporta sinônimos)

Ao executar a mesma consulta na visualização de dados "products_synonyms", que suporta sinônimos, os produtos foram recuperados com sucesso. Isso demonstra que o conjunto de sinônimos configurado está funcionando corretamente, garantindo que diferentes variações dos termos pesquisados retornem os resultados esperados.

Podemos obter o mesmo resultado executando a mesma consulta diretamente no Kibana DevTools. Basta pesquisar o índice products_02 usando a API de pesquisa do Elasticsearch:

Conclusão

A implementação de sinônimos no Elasticsearch melhorou a precisão e a abrangência das buscas no catálogo de produtos. O principal diferencial foi o uso de um LLM ( Language-Level Model), que gerou sinônimos automaticamente e contextualmente, eliminando a necessidade de listas predefinidas. O modelo analisou nomes e categorias de produtos, garantindo sinônimos relevantes para o comércio eletrônico.

Além disso, a API de Sinônimos simplificou o gerenciamento de dicionários, permitindo que os conjuntos de sinônimos fossem modificados dinamicamente. Com essa abordagem, a busca tornou-se mais flexível e adaptável a diferentes padrões de consulta do usuário.

Esse processo pode ser continuamente aprimorado com novos dados e ajustes de modelo, garantindo uma experiência de pesquisa cada vez mais eficiente.

Referências

Executar o Elasticsearch localmente

https://www.elastic.co/guide/en/elasticsearch/reference/current/run-elasticsearch-locally.html

API de sinônimos

https://www.elastic.co/guide/en/elasticsearch/reference/current/synonyms-apis.html

Partindo dos exemplos da parte 1, este post explora como usar diferentes técnicas e o conjunto avançado de ferramentas de busca vetorial do Elasticsearch para preparar vetores de interação tardia para cargas de trabalho de produção em grande escala.

Os exemplos completos de código estão disponíveis no GitHub.

Desafios dos modelos de interação tardia

O ColPali cria mais de 1.000 vetores por página para os documentos do nosso índice.

Isso resulta em dois desafios ao trabalhar com vetores de interação tardia:

1. Espaço em disco: salvar todos esses vetores em disco gera um volume significativo de armazenamento, o que se torna caro em ambientes de grande escala.

2. Computação: ao classificar documentos usando a comparação maxSimDotProduct(), precisamos comparar todos esses vetores de cada documento com os N vetores da consulta.

Vamos analisar algumas técnicas para lidar com esses desafios.

Técnicas para otimizar modelos de interação tardia

Vetores de bits

Para reduzir o espaço em disco, podemos comprimir as imagens em vetores de bits. Podemos usar uma função simples em Python para transformar nossos multivetores em vetores de bits:

O conceito central da função é simples: valores acima de 0 se tornam 1, e valores abaixo de 0 se tornam 0. Isso resulta em uma matriz de 0s e 1s, que depois transformamos em uma string hexadecimal que representa nosso vetor de bits.

Para o mapeamento de índice, configuramos o parâmetro element_type para bit:

Depois de gravar todos os novos vetores de bits no índice, podemos ranquear nossos vetores de bits usando o código a seguir:

Ao abrir mão de um pouco de precisão, isso nos permite usar a distância de Hamming (maxSimInvHamming(...)), que consegue explorar otimizações como bit masks, SIMD, entre outras. Saiba mais sobre vetores de bits e distância de Hamming em nosso blog.

Como alternativa, podemos não converter o vetor de consulta em vetores de bits e realizar a busca usando o vetor de interação tardia com fidelidade total:

Nesse caso, os vetores são comparados usando uma função de similaridade assimétrica.

Vamos considerar uma distância de Hamming padrão entre dois vetores de bits. Suponha que temos um vetor de documento D:

E um vetor de consulta Q:

A quantização binária simples transforma o vetor D em 10101101 e o vetor Q em 11111011. Para calcular a distância de Hamming, precisamos apenas de operações diretas em bits, algo extremamente rápido. Nesse caso, a distância de Hamming é 01010110, que possui uma contagem de bits igual a 4.Assim, a pontuação passa a ser o inverso dessa distância de Hamming. Lembre-se de que vetores mais semelhantes têm uma distância de Hamming MENOR, portanto inverter esse valor permite que vetores mais semelhantes recebam pontuações mais altas. Especificamente aqui, a pontuação seria 1/4 = 0.25.

No entanto, observe que perdemos a magnitude de cada dimensão. Um 1 é um 1. Assim, para Q, a diferença entre 0.01 e 0.79 desaparece. Como estamos simplesmente quantizando de acordo com >0, podemos aplicar um pequeno truque em que o vetor Q não é quantizado. Isso não permite a matemática bit a bit extremamente rápida, mas mantém o custo de armazenamento baixo, já que D continua quantizado.

Em resumo, essa abordagem preserva as informações contidas em Q, aumentando a qualidade da estimativa de distância e mantendo baixo o custo de armazenamento.

O uso de vetores de bits permite economizar significativamente espaço em disco e reduzir a carga computacional no momento da consulta. Mas ainda há mais que podemos fazer.

Vetores médios

Para redimensionar a busca para centenas de milhares de documentos, mesmo os ganhos de desempenho proporcionados pelos vetores de bits não serão suficientes. Para dar conta desse tipo de carga, será necessário aproveitar a estrutura de índice HNSW do Elasticsearch para busca vetorial.

O ColPali gera cerca de 1.000 vetores por documento, o que é excessivo para adicionar ao grafo HNSW. Portanto, precisamos reduzir a quantidade de vetores. Para isso, podemos criar uma única representação do significado do documento calculando a média de todos os vetores do documento produzidos pelo ColPali quando incorporamos a imagem.

No momento, isso não é possível diretamente no Elastic, sendo necessário pré-processar os vetores antes de ingeri-los no Elasticsearch.

Isso pode ser feito com o Logstash ou com pipelines de ingestão, mas aqui usaremos uma função simples em Python:

Também normalizamos o vetor para que possamos usar a similaridade por produto escalar.

Depois de transformar todos os vetores do ColPali em vetores médios, podemos indexá-los no campo dense_vector:

Precisamos considerar que isso aumentará o uso total de disco, pois estamos salvando mais informações junto com nossos vetores de interação tardia. Além disso, usaremos RAM adicional para manter o grafo HNSW, o que nos permite redimensionar a busca para bilhões de vetores. Para reduzir o uso de RAM, podemos recorrer ao nosso conhecido recurso BBQ. Com isso, obtemos resultados de busca rápidos em conjuntos de dados massivos que, de outra forma, não seriam viáveis.

Agora, simplesmente fazemos a busca com a consulta knn para encontrar os documentos mais relevantes.

O que antes era a melhor correspondência acabou caindo para a 3ª posição.

Para corrigir esse problema, podemos usar uma recuperação em vários estágios. No primeiro estágio, usamos a consulta knn para buscar os melhores candidatos para a consulta em meio a milhões de documentos. No segundo estágio, fazemos a reclassificação apenas dos top k (neste caso, 10) usando a maior fidelidade dos vetores de interação tardia do ColPali. 

Aqui, estamos usando o rescore retriever, introduzido na versão 8.18, para reclassificar nossos resultados. Após a reclassificação, vemos que a melhor correspondência volta a ocupar a primeira posição.

Observação: em uma aplicação de produção, podemos usar um valor de k muito maior que 10, já que a função max sim ainda é relativamente eficiente em termos de performance.

Agrupamento de tokens

O agrupamento de tokens reduz o comprimento da sequência de embeddings multivetoriais ao agrupar informações redundantes, como regiões de fundo branco. Essa técnica diminui o número de embeddings ao mesmo tempo que preserva a maior parte do sinal da página.

O agrupamento de tokens funciona reunindo embeddings de tokens semelhantes dentro de um documento em clusters, usando um algoritmo de clusterização. Em seguida, calcula-se a média dos vetores em cada cluster para criar uma única representação agregada. Esse vetor agregado substitui os tokens originais do grupo, reduzindo o número total de vetores sem perda significativa do sinal do documento.

O artigo do ColPali propõe um valor inicial de agrupamento factor igual a 3 para a maioria dos conjuntos de dados, mantendo 97,8% da performance original ao mesmo tempo que reduz o número total de vetores em 66,7%. 

Mas é preciso cautela: o conjunto de dados Shift, que contém documentos muito densos e com grande volume de texto e pouco espaço em branco, apresenta uma queda rápida de desempenho conforme o fator de agrupamento aumenta.

Para criar os vetores agrupados, podemos usar a biblioteca colpali_engine:

Agora temos um vetor que teve suas dimensões reduzidas em cerca de 66,7%. Nós o indexamos normalmente e conseguimos realizar buscas usando nossa função maxSimDotProduct().

Conseguimos obter bons resultados de busca ao custo de uma leve perda de precisão nos resultados.

Dica: com um pool_factor mais alto (100-200), também é possível encontrar um meio-termo entre a solução de vetor médio e a abordagem discutida aqui. Com cerca de 5 a 10 vetores por documento, torna-se viável indexá-los em um campo aninhado para aproveitar o índice HNSW.

Cross-encoder vs. interação tardia vs. bi-encoder

Com tudo o que aprendemos até aqui, onde isso posiciona os modelos de interação tardia, como ColPali ou ColBERT, em comparação com outras técnicas de recuperação baseadas em IA?

Embora a função max sim seja mais barata do que o uso de cross-encoders, ela ainda exige muito mais comparações e processamento do que a busca vetorial com bi-encoders, em que comparamos apenas dois vetores para cada par consulta-documento.

Por isso, nossa recomendação para modelos de interação tardia é, em geral, usá-los apenas para reclassificação dos primeiros k resultados de busca. Também refletimos isso no nome do tipo de campo: rank_vectors.

Mas e o cross-encoder? Modelos de interação tardia são melhores por serem mais baratos de executar no momento da consulta? Como acontece com frequência, a resposta é: depende. Os cross-encoders normalmente produzem resultados de maior qualidade, mas exigem muito processamento, já que cada par consulta-documento precisa passar completamente pelo modelo transformer. Eles também se beneficiam do fato de não exigirem indexação de vetores e poderem operar de forma stateless. Isso resulta em:

• Menor uso de espaço em disco

• Um sistema mais simples

• Maior qualidade nos resultados de busca

• Maior latência, o que limita a profundidade da reclassificação

Por outro lado, os modelos de interação tardia podem deslocar parte desse custo computacional para o momento da indexação, tornando a consulta mais barata. O preço a pagar é a necessidade de indexar vetores, o que torna os pipelines de indexação mais complexos e exige mais espaço em disco para armazená-los.

No caso específico do ColPali, a análise de informações provenientes de imagens é muito custosa, já que elas contêm grandes volumes de dados. Nesse cenário, o equilíbrio pende a favor do uso de um modelo de interação tardia como o ColPali, pois avaliar essas informações no momento da consulta seria lento demais e exigiria muitos recursos.

Já para um modelo de interação tardia como o ColBERT, que trabalha com dados textuais, assim como a maioria dos cross-encoders, por exemplo o elastic-rerank-v1, a decisão pode favorecer o uso do cross-encoder, aproveitando a economia de disco e a maior simplicidade operacional.

Recomendamos que você avalie esses prós e contras no seu caso de uso e experimente as diferentes ferramentas que o Elasticsearch oferece para criar as melhores aplicações de busca.

Conclusão

Neste blog, exploramos várias técnicas para otimizar modelos de interação tardia, como o ColPali, para busca vetorial em grande escala no Elasticsearch. Embora esses modelos ofereçam um forte equilíbrio entre eficiência de recuperação e qualidade de classificação, eles também introduzem desafios relacionados a armazenamento e computação.

Para enfrentar esses desafios, analisamos diferentes abordagens e técnicas:

• Vetores de bits para reduzir significativamente o uso de espaço em disco, ao mesmo tempo que aproveitam computações de similaridade eficientes, como a distância de Hamming ou a similaridade máxima assimétrica.

• Vetores médios para comprimir múltiplos embeddings em uma única representação densa, permitindo recuperação eficiente com indexação HNSW.

• Agrupamento de tokens para unir embeddings redundantes de forma inteligente, mantendo a integridade semântica e reduzindo a sobrecarga computacional no momento da consulta.

O Elasticsearch oferece um conjunto poderoso de ferramentas para personalizar e otimizar aplicações de busca de acordo com suas necessidades. Seja priorizando velocidade de recuperação, qualidade de ranqueamento ou eficiência de armazenamento, essas técnicas permitem equilibrar desempenho e qualidade conforme as exigências de aplicações do mundo real.