Para isso, utilizamos o SigLIP-2 do Google para gerar representações vetoriais tanto para imagens quanto para texto, e as armazenamos no banco de dados vetorial Elasticsearch. No momento da consulta, convertemos a entrada da pesquisa, seja texto ou imagem, em representações vetoriais (embeddings) e executamos buscas vetoriais kNN rápidas para recuperar os resultados. Essa configuração permite uma busca eficiente de texto para imagem e de imagem para imagem. A interface Streamlit UI dá vida a este projeto, fornecendo-nos um frontend que não só permite realizar buscas textuais para encontrar e visualizar as fotos correspondentes no álbum, como também nos permite identificar o pico da montanha na imagem carregada e visualizar outras fotos dessa montanha no álbum. Abordamos também as medidas que tomamos para melhorar a precisão da pesquisa, juntamente com dicas e truques práticos. Para uma exploração mais aprofundada, disponibilizamos um repositório no GitHub e um notebook no Colab.

Como tudo começou

Este post do blog foi inspirado por uma criança de 10 anos que me pediu para mostrar todas as fotos do Monte Ama Dablam que tirei na minha trilha até o Acampamento Base do Everest. Enquanto examinávamos o álbum de fotos, também me pediram para identificar vários outros picos de montanhas, alguns dos quais eu não sabia o nome.

Isso me deu a ideia de que este pode ser um projeto divertido de visão computacional. O que queríamos alcançar:

• Encontre fotos de um pico de montanha pelo nome.

• Adivinhe o nome do pico da montanha a partir de uma imagem e encontre picos semelhantes no álbum de fotos.

• Fazer com que as consultas de conceito funcionem (pessoa, rio, bandeiras de oração, etc.)

Montando a equipe dos sonhos: SigLIP-2, Elasticsearch e Streamlit

Rapidamente ficou claro que, para isso funcionar, precisaríamos transformar tanto o texto (“Ama Dablam”) quanto as imagens (fotos do meu álbum) em vetores que pudessem ser comparados de forma significativa, ou seja, no mesmo espaço vetorial. Uma vez feito isso, a busca se torna simplesmente "encontrar os vizinhos mais próximos".

Para gerar representações vetoriais de imagens, usamos um codificador multilíngue de visão e linguagem, de modo que uma foto de uma montanha e uma frase como "Ama Dablam" fiquem no mesmo espaço vetorial.

O SigLIP-2, lançado recentemente pelo Google, se encaixa bem aqui. Ele consegue gerar embeddings sem treinamento específico para a tarefa (uma configuração zero-shot ) e funciona bem para o nosso caso de uso: fotos não rotuladas e picos com nomes e idiomas diferentes. Como foi treinado para correspondência de texto ↔ imagem, uma foto da montanha tirada durante a trilha e um breve texto de exemplo resultam em representações vetoriais muito semelhantes, mesmo quando o idioma ou a ortografia da consulta variam.

O SigLIP-2 oferece um excelente equilíbrio entre qualidade e velocidade, suporta múltiplas resoluções de entrada e funciona tanto na CPU quanto na GPU. O SigLIP-2 foi projetado para ser mais resistente a fotos tiradas ao ar livre em comparação com modelos anteriores, como o CLIP original. Durante nossos testes, o SigLIP-2 gerou resultados confiáveis de forma consistente. Além disso, conta com amplo suporte, o que a torna a escolha óbvia para este projeto.

Em seguida, precisamos de um banco de dados vetorial para armazenar os embeddings e realizar buscas avançadas. Deveria suportar não apenas a busca kNN de cosseno em embeddings de imagem, mas também aplicar filtros de geolocalização e texto em uma única consulta. O Elasticsearch se encaixa bem aqui: ele lida muito bem com vetores (HNSW kNN em campos dense_vector), suporta busca híbrida que combina consultas de texto, vetores e geolocalização, e oferece filtragem e classificação prontas para uso. Ele também se adapta à escala horizontal, facilitando a expansão de um punhado de fotos para milhares. O cliente oficial do Elasticsearch para Python mantém a infraestrutura simples e se integra perfeitamente ao projeto. Por fim, precisamos de uma interface leve onde possamos inserir consultas de pesquisa e visualizar os resultados. Para uma demonstração rápida baseada em Python, o Streamlit é uma ótima opção. Ele fornece os recursos básicos de que precisamos: upload de arquivos, uma grade de imagens responsiva e menus suspensos para classificação e geolocalização. É fácil clonar e executar localmente, e também funciona em um notebook do Colab.

Implementação

Design e estratégia de indexação do Elasticsearch

Usaremos dois índices para este projeto: peaks_catalog e photos.

Índice do catálogo de picos

Este índice serve como um catálogo compacto dos picos de montanhas mais proeminentes que podem ser vistos durante a trilha até o Acampamento Base do Everest. Cada documento neste índice corresponde a um único pico de montanha, como o Monte Everest. Para cada documento de pico de montanha, armazenamos nomes/apelidos, coordenadas opcionais de latitude e longitude e um único vetor protótipo construído pela combinação de prompts de texto SigLIP-2 (e imagens de referência opcionais).

Mapeamento do índice:

Campo

Tipo

Exemplo

Objetivo/Observações

Vetor/Indexação

eu ia

palavra-chave

ama-dablam

Slug/ID estável

—

nomes

texto + subcampo de palavra-chave

["Ama Dablam","Amadablam"]

Aliases / nomes multilíngues; names.raw para filtros exatos

—

latlon

ponto_geográfico

{"lat":27.8617,"lon":86.8614}

Coordenadas GPS do pico como uma combinação de latitude/longitude (opcional)

—

elev_m

inteiro

6812

Elevação (opcional)

—

texto incorporado

dense_vector

768

Protótipo misto (com instruções e, opcionalmente, 1 a 3 imagens de referência) para este pico.

índice:true, similaridade:"cosseno", opções_de_índice:{type:"hnsw", m:16, ef_construction:128}

Este índice é usado principalmente para buscas de imagem para imagem, como identificar picos de montanhas a partir de imagens. Também utilizamos esse índice para aprimorar os resultados de busca de texto para imagem.

Em resumo, o peaks_catalog transforma a pergunta "Que montanha é esta?" em um problema de vizinho mais próximo focado, separando efetivamente a compreensão conceitual das complexidades dos dados da imagem.

Estratégia de indexação para o índice peaks_catalog: Começamos criando uma lista dos picos mais proeminentes visíveis durante a trilha do Campo Base do Everest. Para cada pico, armazenamos sua localização geográfica, nome, sinônimos e altitude em um arquivo YAML. O próximo passo é gerar o embedding para cada pico e armazená-lo no campo text_embed . Para gerar embeddings robustos, utilizamos a seguinte técnica:

• Crie um protótipo de texto usando:

  • nomes dos picos

  • Conjunto de prompts (usando vários prompts diferentes para tentar responder à mesma pergunta), por exemplo:

    • “uma foto natural do pico da montanha {name} no Himalaia, Nepal”

    • “{name} pico emblemático na região de Khumbu, paisagem alpina”

    • “{name} cume da montanha, neve, crista rochosa”

  • Anti-conceito opcional (indicando ao SigLIP-2 o que não deve ser correspondido): subtrair um pequeno vetor para "pintura, ilustração, pôster, mapa, logotipo" para que haja uma preferência por fotos reais.

• Opcionalmente, crie um protótipo de imagem se forem fornecidas imagens de referência do pico.

Em seguida, combinamos o texto e o protótipo da imagem para gerar a incorporação final. Finalmente, o documento é indexado com todos os campos necessários:

Documento de exemplo do índice peaks_catalog :

Índice de fotos

Este índice principal armazena informações detalhadas sobre todas as fotos do álbum. Cada documento representa uma única fotografia, contendo as seguintes informações:

• Caminho relativo até a foto no álbum de fotos. Isso pode ser usado para visualizar a imagem correspondente ou carregar a imagem na interface de pesquisa.

• Informações de GPS e horário da imagem.

• Vetor denso para codificação de imagem gerado por SigLIP-2.

• predicted_peaks Isso nos permite filtrar pelo nome do pico. Mapeamento de índice

Campo

Tipo

Exemplo

Objetivo/Observações

Vetor / Indexação

caminho

palavra-chave

dados/imagens/IMG_1234.HEIC

Como a interface do usuário abre a miniatura/imagem completa

—

imagem_recortada

dense_vector

768

Incorporação de imagem SigLIP-2

índice:true, similaridade:"cosseno", opções_de_índice:{type:"hnsw", m:16, ef_construction:128}

picos_previstos

palavra-chave

["ama-dablam","pumori"]

Top-K palpites no momento da indexação (filtro/faceta de UX barato)

—

GPS

ponto_geográfico

{"lat":27.96,"lon":86.83}

Ativa filtros geográficos

—

tempo_de_tiro

date

2023-10-18T09:41:00Z

Tempo de captura: classificar/filtrar

—

Estratégia de indexação para o índice de fotos: Para cada foto no álbum, fazemos o seguinte: Extrair informações das imagens shot_time e gps dos metadados da imagem.

• Incorporação de imagem SigLIP-2: passe a imagem pelo modelo e normalize o vetor usando a notação L2. Armazene o embedding no campo clip_image .

• Preveja os picos e armazene-os no campo predicted_peaks . Para fazer isso, primeiro pegamos o vetor de imagem da foto gerado na etapa anterior e, em seguida, executamos uma busca kNN rápida no campo text_embed no índice peaks_catalog . Mantemos os 3 ou 4 picos mais altos e ignoramos o resto.

• Calculamos o campo _id fazendo um hash no nome e caminho da imagem. Isso garante que não teremos duplicatas após várias execuções.

Após determinarmos todos os campos da foto, os documentos fotográficos são indexados em lotes usando indexação em massa :

Exemplo de documento do índice de fotos:

Em resumo, o índice de fotos é um armazenamento rápido, filtrável e compatível com kNN de todas as fotos do álbum. Seu mapeamento é propositalmente minimalista — apenas a estrutura necessária para recuperar rapidamente, exibir de forma clara e segmentar os resultados por espaço e tempo. Este índice serve para ambos os casos de uso de pesquisa. O script em Python para criar ambos os índices pode ser encontrado aqui.

A visualização do mapa Kibana abaixo exibe documentos do álbum de fotos como pontos verdes e picos de montanhas do índice peaks_catalog como triângulos vermelhos, com os pontos verdes alinhando-se bem com a trilha da caminhada até o Acampamento Base do Everest.

Pesquisar casos de uso

Busca por nome (texto para imagem): Este recurso permite que os usuários localizem fotos de picos de montanhas (e até mesmo conceitos abstratos como "bandeiras de oração") usando consultas de texto. Para isso, o texto de entrada é convertido em um vetor de texto usando o SigLIP-2. Para geração robusta de vetores de texto, empregamos a mesma estratégia usada para criar embeddings de texto no índice peaks_catalog : combinando a entrada de texto com um pequeno conjunto de prompts, subtraindo um vetor de anti-conceito menor e aplicando a normalização L2 para produzir o vetor de consulta final. Uma consulta kNN é então executada no campo photos.clip_image para recuperar os picos correspondentes principais, com base na similaridade de cosseno para encontrar as imagens mais próximas. Opcionalmente, os resultados da pesquisa podem ser tornados mais relevantes aplicando filtros geográficos e de data e/ou um filtro de termo photos.predicted_peaks como parte da consulta (veja exemplos de consulta abaixo). Isso ajuda a excluir picos semelhantes que, na verdade, não estão visíveis durante a trilha.

Consulta Elasticsearch com filtro geográfico:

Busca por imagem (imagem para imagem): Este recurso permite identificar uma montanha em uma imagem e encontrar outras imagens dessa mesma montanha no álbum de fotos. Quando uma imagem é carregada, ela é processada pelo codificador de imagens SigLIP-2 para gerar um vetor de imagem. Uma busca kNN é então realizada no campo peaks_catalog.text_embed para identificar os nomes de picos que melhor correspondem. Em seguida, um vetor de texto é gerado a partir desses nomes de picos correspondentes, e outra busca kNN é realizada no índice de fotos para localizar as imagens correspondentes.

Consulta do Elasticsearch:

Passo 1: Encontre os nomes de pico correspondentes.

Etapa 2: Realize uma busca no índice photos para encontrar as imagens correspondentes (mesma consulta mostrada no caso de uso de busca de texto para imagem):

Interface de usuário Streamlit

Para integrar tudo, criamos uma interface de usuário Streamlit simples que nos permite executar ambos os casos de uso de pesquisa. A barra lateral esquerda exibe uma lista rolável de picos (agregados de photos.predicted_peaks) com caixas de seleção e um minimapa/filtro geográfico. Na parte superior, há uma caixa de pesquisa por nome e um botão para identificar o usuário a partir de uma foto enviada. O painel central apresenta uma grade de miniaturas interativa que exibe as pontuações kNN, os indicadores de pico previsto e os horários de captura. Cada imagem inclui um botão "Ver imagem" para pré-visualizações em resolução total.

Pesquisa por upload de imagem: Prevemos o pico e encontramos picos correspondentes no álbum de fotos.

Pesquisa por texto: Encontre os picos correspondentes no álbum a partir do texto.

Conclusão

Tudo começou com uma pergunta: "Podemos ver as fotosdo Ama Dablam ?" transformou-se em um pequeno sistema de busca multimodal funcional. Capturamos fotos brutas da trilha, transformamos em embeddings SigLIP-2 e usamos o Elasticsearch para realizar uma rápida análise kNN sobre vetores, além de filtros geográficos/temporais simples para exibir as imagens relevantes. Ao longo do processo, separamos as preocupações com dois índices: um pequeno peaks_catalog de protótipos combinados (para identificação) e um índice escalável photos de vetores de imagem e EXIF (para recuperação). É prático, reproduzível e fácil de expandir.

Se você quiser ajustá-lo, existem algumas configurações que você pode modificar:

• Configurações de tempo de consulta: k (quantos vizinhos você deseja retornar) e num_candidates (quão ampla a pesquisa antes da pontuação final). Essas configurações são discutidas no blog aqui.

• Configurações de tempo de indexação: m (conectividade do grafo) e ef_construction (precisão do tempo de construção vs. memória). Para consultas, experimente também com ef_search — um valor maior geralmente significa melhor recuperação com alguma compensação de latência. Consulte este blog para obter mais detalhes sobre essas configurações.

Olhando para o futuro, modelos/reclassificadores nativos para busca multimodal e multilíngue chegarão em breve ao ecossistema Elastic, o que deverá tornar a recuperação de imagens/texto e a classificação híbrida ainda mais robustas e prontas para uso. ir.elastic.co+1

Se você quiser experimentar você mesmo:

• Repositório do GitHub: https://github.com/navneet83/multimodal-mountain-peak-search

• Guia rápido do Colab: https://github.com/navneet83/multimodal-mountain-peak-search/blob/main/notebooks/multimodal_mountain_peak_search.ipynb

Com isso, nossa jornada chegou ao fim e é hora de voltar para casa. Espero que isso tenha sido útil e, se você quebrar alguma coisa (ou melhorar alguma coisa), adoraria saber o que você mudou.

E se pudéssemos usar interações reais de usuários com nosso aplicativo de busca para criar esses dados de treinamento? Utilizar dados de Renda Básica Universal (RBU) nos permite fazer exatamente isso. Criar um sistema automático capaz de capturar e usar nossas buscas, cliques e outras interações para gerar uma lista de julgamentos. Esse processo pode ser dimensionado e repetido com muito mais facilidade do que uma interação manual e tende a produzir melhores resultados. Neste blog, exploraremos como podemos consultar dados de UBI armazenados no Elasticsearch para calcular sinais relevantes e gerar um conjunto de dados de treinamento para um modelo LTR .

Você pode encontrar o experimento completo aqui.

Por que os dados de UBI podem ser úteis para treinar seu modelo LTR?

Os dados UBI oferecem diversas vantagens em relação à anotação manual:

• Volume: Dado que os dados da Renda Básica Universal (RBU) provêm de interações reais, podemos coletar muito mais dados do que poderíamos gerar manualmente. Isso pressupõe que tenhamos tráfego suficiente para gerar esses dados, é claro.

• Intenção real do usuário: Tradicionalmente, uma lista de julgamento manual provém de uma avaliação especializada dos dados disponíveis. Por outro lado, os dados da UBI refletem o comportamento real do usuário. Isso significa que podemos gerar melhores dados de treinamento que aprimorarão a precisão do nosso sistema de busca, pois ele se baseia em como os usuários realmente interagem com o seu conteúdo e encontram valor nele, em vez de suposições teóricas sobre o que deveria ser relevante.

• Atualizações contínuas: As listas de julgamentos precisam ser atualizadas periodicamente. Se criarmos essas listas a partir de dados da Renda Básica Universal (RBU), poderemos obter dados atuais que resultarão em listas de julgamento atualizadas.

• Relação custo-benefício: Sem o trabalho extra de criar manualmente uma lista de julgamento, o processo pode ser repetido de forma eficiente quantas vezes forem necessárias.

• Distribuição natural de consultas: os dados UBI representam consultas reais de usuários, o que pode gerar mudanças mais profundas. Por exemplo, nossos usuários utilizam linguagem natural para pesquisar em nosso sistema? Nesse caso, talvez devêssemos implementar uma abordagem de busca semântica ou de busca híbrida.

No entanto, isso vem com alguns avisos:

• Amplificação de viés: conteúdo popular tem maior probabilidade de receber cliques, simplesmente por ter mais visibilidade. Isso pode acabar amplificando os itens populares e possivelmente ofuscando opções melhores.

• Cobertura incompleta: O conteúdo novo não possui interações, portanto, pode ser difícil para ele aparecer em posições elevadas nos resultados. Consultas raras também podem não ter pontos de dados suficientes para criar dados de treinamento significativos.

• Variações sazonais: Se você espera que o comportamento do usuário mude drasticamente ao longo do tempo, os dados históricos podem não lhe dizer muito sobre o que é um bom resultado.

• Ambiguidade da tarefa: um clique nem sempre garante que o usuário encontrou o que procurava.

Cálculo das notas

Notas para treinamento LTR

Para treinar modelos LTR, precisamos fornecer alguma representação numérica da relevância de um documento para uma consulta. Em nossa implementação, esse número é uma pontuação contínua que varia de 0,0 a 5,0+, onde pontuações mais altas indicam maior relevância.

Para demonstrar como funciona esse sistema de avaliação, considere este exemplo criado manualmente:

Consulta

Conteúdo do documento

Nota

Explicação

"Melhor receita de pizza"

"Receita autêntica de massa de pizza italiana com fotos passo a passo"

4.0

Altamente relevante, exatamente o que o usuário está procurando.

"Melhor receita de pizza"

"História da Pizza na Itália"

1.0

Ainda que relacionado ao assunto, trata-se de pizza, mas não é uma receita.

"Melhor receita de pizza"

"Receita rápida de pizza em 15 minutos para iniciantes"

3.0

Relevante, um bom resultado, mas talvez não chegue a ser a "melhor" receita.

"Melhor receita de pizza"

"Guia de Manutenção Automotiva"

0,0

Completamente irrelevante, sem qualquer relação com a pergunta.

Como podemos ver aqui, a nota é uma representação numérica da relevância de um documento para nossa consulta de exemplo: "melhor receita de pizza". Com essas pontuações, nosso modelo LTR pode aprender quais documentos devem ser apresentados em posições mais altas nos resultados.

A forma de calcular as notas é o ponto central do nosso conjunto de dados de treinamento. Existem várias abordagens para fazer isso, cada uma com seus pontos fortes e fracos. Por exemplo, poderíamos atribuir uma pontuação binária de 1 para relevante e 0 para irrelevante, ou poderíamos simplesmente contar o número de cliques em um documento resultante para cada consulta.

Neste post do blog, usaremos uma abordagem diferente, considerando o comportamento do usuário como entrada e calculando uma nota como saída. Também corrigiremos o viés que pode ocorrer devido ao fato de que resultados mais altos tendem a receber mais cliques, independentemente da relevância do documento.

Cálculo das notas - Algoritmo COEC

O algoritmo COEC (Clicks over Expected Clicks) é uma metodologia para calcular notas de avaliação a partir dos cliques do usuário. Como já mencionamos, os usuários tendem a clicar nos resultados posicionados mais acima, mesmo que o documento não seja o mais relevante para a consulta; isso é chamado de Viés de Posição. A ideia central por trás do uso do algoritmo COEC é que nem todos os cliques têm a mesma importância; um clique em um documento na posição 10 indica que o documento é muito mais relevante para a consulta do que um clique em um documento na posição 1. Citando o artigo de pesquisa sobre o algoritmo COEC (link acima):

“É sabido que a taxa de cliques (CTR) dos resultados de pesquisa ou anúncios diminui significativamente dependendo da posição dos resultados.”

Você pode ler mais sobre viés de posição aqui.

Para resolver isso com o algoritmo COEC, seguimos estes passos:

1. Estabelecer linhas de base de posicionamento: Calculamos a taxa de cliques (CTR) para cada posição de pesquisa de 1 a 10. Isso significa que determinamos qual a porcentagem de usuários que normalmente clicam na posição 1, na posição 2 e assim por diante. Esta etapa captura a tendência natural de posicionamento dos usuários. Calculamos a CTR usando:

Onde:

p = Posição. De 1 a 10 Cp = Total de cliques (em qualquer documento) na posição p em todas as consultas Ip = Impressões totais: Quantas vezes um documento apareceu na posição p em todas as consultas.

Aqui, esperamos que posições mais altas recebam mais cliques.

2. Calcular os cliques esperados (CE):

Essa métrica estabelece quantos cliques um documento "deveria" ter recebido com base nas posições em que apareceu e na taxa de cliques (CTR) dessas posições. Calculamos o EC usando:

Onde:

Qd = Todas as consultas em que o documento d apareceu pos(d,q) = Posição do documento d nos resultados da consulta q

3. Contagem de cliques reais: Contamos o total real de cliques que um documento recebeu em todas as consultas em que apareceu, daqui em diante denominado A(d).

4. Calcule a pontuação COEC: Esta é a razão entre os cliques reais (A(d)) e os cliques esperados (EC(d)):

Essa métrica normaliza o viés de posição da seguinte forma:

• Uma pontuação de 1,0 significa que o documento teve o desempenho exatamente como esperado, considerando as posições em que foi apresentado.

• Uma pontuação acima de 1,0 significa que o documento teve um desempenho melhor do que o esperado, considerando suas posições. Portanto, este documento é mais relevante para a consulta.

• Uma pontuação inferior a 1,0 significa que o documento teve um desempenho pior do que o esperado, considerando suas posições. Portanto, este documento é menos relevante para a consulta.

O resultado final é uma nota que reflete o que os usuários procuram, levando em consideração as expectativas baseadas na posição, extraídas de interações reais com nosso sistema de busca.

Implementação técnica

Criaremos um script para gerar uma lista de julgamentos para treinar um modelo LTR.

A entrada para este script são os dados UBI indexados no Elastic (consultas e eventos).

O resultado é uma lista de julgamentos em um arquivo CSV gerado a partir desses documentos de Renda Básica Universal (RBU) usando o algoritmo COEC. Essa lista de julgamentos pode ser usada com o Eland para extrair características relevantes e treinar um modelo LTR.

Início rápido

Para gerar uma lista de julgamentos a partir dos dados de exemplo deste blog, você pode seguir estes passos:

1. Clone o repositório:

2. Instale as bibliotecas necessárias

Para este script, precisamos das seguintes bibliotecas:

• pandas: para salvar a lista de julgamentos

• elasticsearch: Para obter os dados UBI da nossa implementação do Elasticsearch.

Também precisamos do Python 3.11.

3. Atualize as variáveis de ambiente para sua implantação do Elasticsearch em um arquivo .env.

• ES_HOST

• API_KEY

Para adicionar as variáveis de ambiente, utilize:

4. Crie os índices ubi_queries e ubi_events e carregue os dados de exemplo. Execute o arquivo setup.py:

5. Execute o script Python:

Seguindo esses passos, você deverá ver um novo arquivo chamado judgment_list.csv com a seguinte aparência:

Este script calcula as notas aplicando o algoritmo COEC discutido anteriormente, utilizando a função calculate_relevance_grade() mostrada abaixo.

Arquitetura de dados

Consultas Ubi

Nosso índice de consultas UBI contém informações sobre as consultas executadas em nosso sistema de busca. Este é um documento de exemplo:

Aqui podemos ver dados do usuário (client_id), dos resultados da consulta (query_response_object_ids) e da própria consulta (timestamp, user_query).

Eventos de clique Ubi

Nosso índice ubi_events contém dados de cada vez que um usuário clicou em um documento nos resultados. Este é um documento de exemplo:

Script de geração de lista de julgamentos

Visão geral do roteiro

Este script automatiza a geração da lista de julgamento usando dados UBI de consultas e eventos de clique armazenados no Elasticsearch. Ele executa estas tarefas:

• Busca e processa os dados UBI no Elasticsearch.

• Correlaciona eventos de UBI com suas consultas.

• Calcula o CTR para cada posição.

• Calcula os cliques esperados (CE) para cada documento.

• Contabiliza os cliques reais em cada documento.

• Calcula a pontuação COEC para cada par consulta-documento.

• Gera uma lista de julgamentos e a grava em um arquivo CSV.

Vamos analisar cada função:

conectar_ao_elasticsearch()

Essa função retorna um objeto cliente Elasticsearch usando o host e a chave da API.

buscar_dados_ubi()

Esta função é a camada de extração de dados; ela se conecta ao Elasticsearch para buscar consultas UBI usando uma consulta match_all e filtra os eventos UBI para obter apenas os eventos 'CLICK_THROUGH'.

processar_dados_ubi()

Esta função é responsável pela geração da lista de julgamentos. O processamento dos dados UBI começa por associar eventos e consultas UBI. Em seguida, chama a função calculate_relevance_grade() para cada par documento-consulta, a fim de obter as entradas para a lista de julgamento. Por fim, retorna a lista resultante como um dataframe do pandas.

calcular_nota_de_relevância()

Esta é a função que implementa o algoritmo COEC. Ele calcula a CTR para cada posição, depois compara os cliques reais para um par documento-consulta e, finalmente, calcula a pontuação COEC real para cada um.

gerar_estatísticas_de_julgamento()

Ele gera estatísticas úteis a partir da lista de julgamentos, como o total de consultas, o total de documentos únicos ou a distribuição de notas. Esta informação é meramente informativa e não altera a lista de julgamentos resultante.

Resultados e impacto

Seguindo as instruções da seção Início rápido, você deverá obter um arquivo CSV contendo uma lista de julgamentos com 320 entradas (você pode ver um exemplo de saída no repositório). Com estes campos:

• qid: ID único da consulta

• docid: identificador único para um documento resultante

• nota: a nota calculada para o par consulta-documento.

• consulta: A consulta do usuário

Vejamos os resultados da pesquisa “receitas italianas”:

qid

docid

nota

Consulta

q1-receitas-italianas

receita_básica_de_massa

0,0

receitas italianas

q1-receitas-italianas

receita_pizza_margherita

3,333333

receitas italianas

q1-receitas-italianas

guia_de_receitas_de_risoto

10.0

receitas italianas

q1-receitas-italianas

receita_croissant_francês

0,0

receitas italianas

q1-receitas-italianas

receita_paella_espanhola

0,0

receitas italianas

q1-receitas-italianas

receita_moussaka_grega

1,875

receitas italianas

Podemos ver pelos resultados que para a consulta “receitas italianas”:

• A receita de risoto é definitivamente o melhor resultado para a pesquisa, recebendo 10 vezes mais cliques do que o esperado.

• A pizza Margherita também é um ótimo resultado.

• A mousaka grega (surpreendentemente) também obteve um bom resultado e teve um desempenho melhor do que sua posição nos resultados sugeriria. Isso significa que alguns usuários que procuravam receitas italianas se interessaram por esta receita em vez desta. Talvez esses usuários estejam interessados em pratos mediterrâneos em geral. Em suma, isso nos indica que esse poderia ser um bom resultado para ser apresentado entre as outras duas partidas "melhores" que discutimos anteriormente.

Conclusão

Utilizar dados UBI nos permite automatizar o treinamento de modelos LTR, criando listas de julgamento de alta qualidade a partir de nossos próprios usuários. Os dados do UBI fornecem um grande conjunto de dados que reflete como nosso sistema de busca está sendo usado. Ao usar o algoritmo COEC para gerar as notas, levamos em consideração o viés inerente e, ao mesmo tempo, refletimos o que um usuário considera um resultado melhor. O método descrito aqui pode ser aplicado a casos de uso reais para proporcionar uma melhor experiência de busca que evolua com as tendências reais de uso.

O Elasticsearch 8.12 e 8.13 trouxeram suporte básico para tipos geoespaciais ao ES|QL. Isso foi significativamente aprimorado com a adição de recursos de busca geoespacial na versão 8.14. Mais importante ainda, esse suporte foi projetado para estar em estrita conformidade com o padrão Simple Feature Access do Open Geospatial Consortium (OGC), usado por outros bancos de dados espaciais como o PostGIS, tornando-o muito mais fácil de usar para especialistas em SIG familiarizados com esses padrões.

Neste blog, mostraremos como usar o ES|QL para realizar buscas geoespaciais e como ele se compara aos seus equivalentes em SQL e Query DSL. Também mostraremos como usar o ES|QL para realizar junções espaciais e como visualizar os resultados no Kibana Maps. Note que todos os recursos descritos aqui estão em "prévia técnica" e gostaríamos muito de receber seu feedback sobre como podemos melhorá-los.

Pesquisa de dados geoespaciais

Vamos começar com um exemplo de consulta:

Esta função realiza uma busca por quaisquer polígonos de limites urbanos que se intersectem com um polígono de busca retangular ao redor do Aeroporto Internacional de Sanya Phoenix (SYX).

Em um conjunto de dados de exemplo contendo aeroportos, cidades e limites urbanos, esta busca encontra o polígono de interseção e retorna os campos desejados do documento correspondente:

abreviar

aeroporto

região

cidade

localização da cidade

SYX

Sanya Phoenix Int'l

天涯区

Sanya

PONTO(109,5036 18,2533)

Isso foi fácil! Agora compare isso com a DSL de consulta clássica do Elasticsearch para a mesma consulta:

Ambas as consultas são razoavelmente claras em sua intenção, mas a consulta ES|QL se assemelha bastante ao SQL. A mesma consulta no PostGIS se parece com isto:

Relembre o exemplo em ES|QL. São muito parecidos, não é?

Constatamos que os usuários existentes da API Elasticsearch consideram o ES|QL muito mais fácil de usar. Agora, esperamos que os usuários atuais de SQL, especialmente os usuários de SQL Espacial, achem o ES|QL muito familiar ao que já estão acostumados a ver.

Por que não usar SQL?

E quanto ao Elasticsearch SQL? Já existe há algum tempo e possui algumas funcionalidades geoespaciais. No entanto, o Elasticsearch SQL foi escrito como um wrapper sobre a API de consulta original, o que significa que apenas as consultas que podiam ser transpiladas para a API original eram suportadas. ES|QL não possui essa limitação. Por ser uma pilha de tecnologias completamente nova, permite muitas otimizações que não eram possíveis em SQL. Nossos testes de desempenho mostram que o ES|QL é frequentemente mais rápido que a API de consulta, principalmente em operações de agregação!

Diferenças em relação ao SQL

Claramente, pelo exemplo anterior, o ES|QL é de certa forma semelhante ao SQL, mas existem algumas diferenças importantes. Por exemplo, ES|QL é uma linguagem de consulta encadeada, começando com um comando de origem como FROM e, em seguida, encadeando todos os comandos subsequentes com o caractere pipe |. Isso torna muito fácil entender como cada comando recebe uma tabela de dados e realiza alguma ação nessa tabela, como filtrar com WHERE, adicionar colunas com EVAL ou realizar agregações com STATS. Em vez de começar com SELECT para definir as colunas de saída finais, pode haver um ou mais comandos KEEP , com o último especificando os resultados de saída finais. Essa estrutura simplifica o raciocínio sobre a consulta.

Analisando o comando WHERE no exemplo acima, podemos ver que ele é bastante semelhante ao exemplo do PostGIS:

ES|QL

PostGIS

Além da diferença nos caracteres de aspas da string, a maior diferença está em como convertemos a string para um tipo espacial. No PostGIS, usamos o sufixo ::geometry , enquanto no ES|QL, usamos o sufixo ::geo_shape . Isso ocorre porque o ES|QL é executado dentro do Elasticsearch e o operador de conversão de tipo :: pode ser usado para converter uma string em qualquer um dos tipos ES|QL suportados, neste caso, um geo_shape. Além disso, os tipos geo_shape e geo_point no Elasticsearch implicam o sistema de coordenadas espaciais conhecido como WGS84, mais comumente referido usando o número SRID 4326. No PostGIS, isso precisa ser explícito, daí o uso do prefixo SRID=4326; na string WKT. Se esse prefixo for removido, o SRID será definido como 0, que é mais parecido com os tipos do Elasticsearch cartesian_point e cartesian_shape, que não estão vinculados a nenhum sistema de coordenadas específico.

Tanto o ES|QL quanto o PostGIS também fornecem sintaxe para funções de conversão de tipo:

ES|QL

PostGIS

Funções OGC

O Elasticsearch 8.14 introduz as seguintes quatro funções de pesquisa espacial OGC:

ES|QL

PostGIS

Descrição

ST_INTERSETOS

ST_Interseções

Retorna verdadeiro se duas geometrias se intersectam e falso caso contrário.

ST_DISJOINT

ST_Disjunto

Retorna verdadeiro se as duas geometrias não se intersectarem e falso caso contrário. O inverso de ST_INTERSETOS.

ST_CONTÉM

ST_Contém

Retorna verdadeiro se uma geometria contém outra, e falso caso contrário.

ST_DENTRO

ST_Dentro

Retorna verdadeiro se uma geometria estiver dentro de outra, e falso caso contrário. O inverso de ST_CONTAINS.

Essas funções se comportam de maneira semelhante às suas contrapartes no PostGIS e são usadas da mesma forma. Por exemplo, ST_INTERSECTS retorna verdadeiro se duas geometrias se intersectam e falso caso contrário. Se você seguir os links de documentação na tabela acima, poderá notar que todos os exemplos ES|QL estão dentro de uma cláusula WHERE após uma cláusula FROM , enquanto todos os exemplos PostGIS estão usando geometrias literais. Na verdade, ambas as plataformas suportam o uso das funções em qualquer parte da consulta onde façam sentido.

O primeiro exemplo na documentação do PostGIS para ST_INTERSECTS é:

O equivalente em ES|QL seria:

Observe que não especificamos o SRID no exemplo do PostGIS. Isso ocorre porque no PostGIS, ao usar o tipo geometry , todos os cálculos são feitos em um sistema de coordenadas planas e, portanto, se ambas as geometrias tiverem o mesmo SRID, não importa qual seja o SRID. No Elasticsearch, isso também é verdade para a maioria das funções, no entanto, existem exceções onde geo_shape e geo_point usam cálculos esféricos, como veremos no próximo blog sobre pesquisa de distância espacial.

Versatilidade ES|QL

Então, vimos exemplos acima de uso de funções espaciais em cláusulas WHERE e em comandos ROW . Em que outro lugar fariam sentido? Um local muito útil é no comando EVAL . Este comando permite avaliar uma expressão e retornar o resultado. Por exemplo, vamos determinar se os centroides de todos os aeroportos agrupados por seus nomes de país estão dentro de um limite que delimita o país:

Os resultados são os esperados: o centroide dos aeroportos do Reino Unido está dentro das fronteiras do Reino Unido, e não dentro das fronteiras da Islândia, e vice-versa.

centroide

Contagem

no Reino Unido

na Islândia

dentro do Reino Unido

dentro da Islândia

PONTO (-21,946634463965893 64.13187285885215)

1

falso

verdadeiro

falso

verdadeiro

PONTO (-2,597342072712148 54,33551226578214)

17

verdadeiro

falso

verdadeiro

falso

PONTO (0,04453958108176276 23,74658354606057)

873

falso

falso

falso

falso

Na verdade, essas funções podem ser usadas em qualquer parte da consulta onde sua assinatura faça sentido. Todas elas recebem dois argumentos, que podem ser um objeto espacial literal ou um campo de um tipo espacial, e todas retornam um valor booleano. Uma consideração importante é que o sistema de referência de coordenadas (SRC) das geometrias deve coincidir, caso contrário, será retornado um erro. Isso significa que você não pode misturar os tipos geo_shape e cartesian_shape na mesma chamada de função. Você pode, no entanto, misturar os tipos geo_point e geo_shape , já que o tipo geo_point é um caso especial do tipo geo_shape e ambos compartilham o mesmo sistema de referência de coordenadas. A documentação de cada uma das funções definidas acima lista as combinações de tipos suportadas.

Além disso, qualquer um dos argumentos pode ser um literal espacial ou um campo, em qualquer ordem. Você pode até especificar dois campos, dois literais, um campo e um literal, ou um literal e um campo. O único requisito é que os tipos sejam compatíveis. Por exemplo, esta consulta compara dois campos no mesmo índice:

A consulta basicamente pergunta se a localização da cidade está dentro dos limites da cidade, o que geralmente deve ser verdade, mas sempre há exceções:

cardinalidade

Contagem

na cidade

alguns

29

falso

muitos

740

verdadeiro

Uma questão muito mais interessante seria saber se a localização do aeroporto está dentro dos limites da cidade que ele serve. No entanto, a localização do aeroporto reside em um índice diferente daquele que contém os limites da cidade. Isso requer um método para consultar e correlacionar dados de forma eficaz a partir desses dois índices separados.

Junções espaciais

ES|QL não suporta comandos JOIN , mas você pode obter um caso especial de junção usando o comando ENRICH , que se comporta de forma semelhante a uma 'junção esquerda' em SQL. Este comando funciona de forma semelhante a uma 'junção à esquerda' em SQL, permitindo enriquecer os resultados de um índice com dados de outro índice com base em uma relação espacial entre os dois conjuntos de dados.

Por exemplo, vamos enriquecer os resultados de uma tabela de aeroportos com informações adicionais sobre a cidade que eles atendem, encontrando o limite da cidade que contém a localização do aeroporto e, em seguida, realizar algumas análises estatísticas dos resultados:

Isso retorna as 5 principais regiões com o maior número de aeroportos, juntamente com o centroide de todos os aeroportos que possuem regiões correspondentes e o intervalo de comprimento da representação WKT dos limites das cidades dentro dessas regiões:

centroide

Contagem

min_wkt

max_wkt

região

PONTO (-32,56093470960719 32,598117914802714)

90

207

207

nulo

PONTO (-73,94515332765877 40,70366442203522)

9

438

438

Cidade de Nova York

PONTO (-83.10398317873478 42.300230911932886)

9

473

473

Detroit

PONTO (-156.3020245861262 20,176383580081165)

5

307

803

Havaí

PONTO (-73,88902732171118 45.57078813901171)

4

837

837

Montreal

Então, o que realmente aconteceu aqui? Onde ocorreu o suposto JOIN ? O ponto crucial da questão reside no comando ENRICH :

Este comando instrui o Elasticsearch a enriquecer os resultados recuperados do índice airports e a realizar uma junção intersects entre o campo city_location do índice original e o campo city_boundary do índice airport_city_boundaries , que usamos em alguns exemplos anteriores. Mas algumas dessas informações não estão claramente visíveis nesta consulta. O que vemos é o nome de uma política de enriquecimento city_boundaries e a informação em falta está encapsulada na definição dessa política.

Aqui podemos ver que ele executará uma consulta geo_match (intersects é o padrão), o campo para comparar é city_boundary e os enrich_fields são os campos que queremos adicionar ao documento original. Um desses campos, o region foi na verdade usado como chave de agrupamento para o comando STATS , algo que não poderíamos ter feito sem essa capacidade de 'junção à esquerda'. Para obter mais informações sobre políticas de enriquecimento, consulte a documentação de enriquecimento. Ao ler esses documentos, você notará que eles descrevem o uso de índices de enriquecimento para enriquecer dados no momento da indexação, configurando pipelines de ingestão. Isso não é necessário para ES|QL, pois o comando ENRICH funciona no momento da consulta. Basta preparar o índice de enriquecimento com os dados necessários e a política de enriquecimento e, em seguida, usar o comando ENRICH em suas consultas ES|QL.

Você também pode notar que a região mais comumente encontrada foi null. O que isso poderia implicar? Lembre-se de que comparei este comando a um 'left join' em SQL, o que significa que se nenhum limite de cidade correspondente for encontrado para um aeroporto, o aeroporto ainda será retornado, mas com valores null para os campos do índice airport_city_boundaries . Descobriu-se que havia 89 aeroportos que não encontraram nenhum city_boundary correspondente e um aeroporto com uma correspondência onde o campo region era null. Isso levou a uma contagem de 90 aeroportos sem nenhum region nos resultados. Outro detalhe interessante é a necessidade do comando MV_EXPAND . Isso é necessário porque o comando ENRICH pode retornar vários resultados para cada linha de entrada e MV_EXPAND ajuda a separar esses resultados em várias linhas, uma para cada resultado. Isso também esclarece por que "Havaí" mostra resultados diferentes min_wkt e max_wkt : havia várias regiões com o mesmo nome, mas limites diferentes.

Mapas do Kibana

O Kibana adicionou suporte para Spatial ES|QL no aplicativo Maps. Isso significa que agora você pode usar o ES|QL para pesquisar dados geoespaciais no Elasticsearch e visualizar os resultados em um mapa.

Existe uma nova opção de camada no menu "Adicionar camadas", chamada "ES|QL". Assim como todos os recursos geoespaciais descritos até agora, este está em "prévia técnica". Selecionar esta opção permite adicionar uma camada ao mapa com base nos resultados de uma consulta ES|QL. Por exemplo, você poderia adicionar uma camada ao mapa que mostrasse todos os aeroportos do mundo.

Ou você poderia adicionar uma camada que mostre os polígonos do índice airport_city_boundaries , ou ainda melhor, que tal aquela consulta complexa ENRICH acima que gera estatísticas de quantos aeroportos existem em cada região?

O que vem a seguir?

Você deve ter notado que em dois dos exemplos acima incluímos mais uma função espacial ST_CENTROID_AGG. Esta é uma função de agregação usada no comando STATS e a primeira de muitas funcionalidades de análise espacial que planejamos adicionar ao ES|QL. Vamos publicar um artigo sobre isso quando tivermos mais informações para mostrar!

Antes disso, gostaríamos de falar mais sobre um recurso particularmente interessante no qual trabalhamos: a capacidade de realizar buscas por distância espacial, um dos recursos de busca espacial mais utilizados do Elasticsearch. Você consegue imaginar como seria a sintaxe para buscas por distância? Talvez semelhante a uma função OGC? Fique ligado(a) no próximo post desta série para descobrir!

Alerta de spoiler: o Elasticsearch 8.15 acaba de ser lançado e inclui pesquisa por distância espacial com ES|QL!

Entendendo o benchmark BEIR na avaliação de relevância de busca

Para melhorar qualquer sistema, é preciso conseguir medir o quão bem ele está funcionando. No contexto de busca, o BEIR (ou, de forma equivalente, a seção de recuperação da tabela de classificação do MTEB) é considerado o “santo graal” pela comunidade de recuperação de informação, e isso não é por acaso. Trata-se de um benchmark muito bem estruturado, com conjuntos de dados variados que abrangem diferentes tarefas. Mais especificamente, as seguintes áreas são contempladas:

• Recuperação de argumentos (ArguAna, Touche2020)

• QA de domínio aberto (HotpotQA, Natural Questions, FiQA)

• Recuperação de passagens (MSMARCO)

• Recuperação de perguntas duplicadas (Quora, CQADupstack)

• Verificação de fatos (FEVER, Climate-FEVER, Scifact)

• Recuperação de informações biomédicas (TREC-COVID, NFCorpus, BioASQ)

• Recuperação de entidades (DBPedia)

• Previsão de citações (SCIDOCS)

O benchmark fornece uma única métrica, nDCG@10, relacionada a quão bem um sistema corresponde aos documentos mais relevantes para cada exemplo de tarefa entre os principais resultados retornados. Para um sistema de busca com o qual pessoas interagem, a relevância dos primeiros resultados é fundamental. No entanto, existem muitas nuances na avaliação de busca que uma única métrica resumida não consegue capturar.

Estrutura de um conjunto de dados BEIR

Cada benchmark é composto por três artefatos:

• o corpus, ou seja, os documentos a serem recuperados

• as consultas

• Os julgamentos de relevância para as consultas (também conhecidos como qrels).

Os julgamentos de relevância são fornecidos como uma pontuação igual ou maior que zero. Pontuações diferentes de zero indicam que o documento tem alguma relação com a consulta.

Conjunto de dados

Tamanho do corpus

#Consultas no conjunto de testes

#qrels com rótulo positivo

#qrels igual a zero

#duplicatas no corpus

ArguAna

8.674

1.406

1.406

0

96

Climate-FEVER

5.416.593

1.535

4.681

0

0

DBPedia

4.635.922

400

15.286

28.229

0

FEVER

5.416.568

6.666

7.937

0

0

FiQA-2018

57.638

648

1.706

0

0

HotpotQA

5.233.329

7.405

14.810

0

0

Natural Questions

2.681.468

3.452

4.021

0

16.781

NFCorpus

3.633

323

12.334

0

80

Quora

522.931

10.000

15.675

0

1.092

SCIDOCS

25.657

1.000

4.928

25.000

2

SciFact

5.183

300

339

0

0

Touche2020

382.545

49

932

1.982

5.357

TREC-COVID

171.332

50

24.763

41.663

0

MSMARCO

8.841.823

6.980

7.437

0

324

CQADupstack (soma)

457.199

13.145

23.703

0

0

Tabela 1: Estatísticas dos conjuntos de dados. Os números foram calculados com base na porção de teste dos conjuntos de dados (dev para MSMARCO).

A Tabela 1 apresenta algumas estatísticas dos conjuntos de dados que compõem o benchmark BEIR, como o número de documentos no corpus, o número de consultas no conjunto de teste e o número de pares positivos/negativos (consulta, documento) no arquivo qrels. Com uma análise rápida dos dados, é possível inferir imediatamente o seguinte:

• maioria dos conjuntos de dados não contém relações negativas no arquivo qrels, ou seja, pontuações zero que indicariam explicitamente que um documento é irrelevante para determinada consulta.

• O número médio de relações entre documentos por consulta (#qrels / #queries) varia de 1,0 no caso de ArguAna até 493,5 (TREC-COVID), mas fica em torno de <5 na maioria dos casos.

• Alguns conjuntos de dados apresentam documentos duplicados no corpus, o que em certos casos pode levar a avaliações incorretas, por exemplo quando um documento é considerado relevante para uma consulta, mas seu duplicado não é. Como exemplo, em ArguAna, identificamos 96 casos de pares de documentos duplicados em que apenas um documento do par foi marcado como relevante para uma consulta. Ao “expandir” a lista inicial de qrels para incluir também os duplicados, observamos um aumento relativo médio de aproximadamente 1% na pontuação nDCG@10.

Exemplo de pares duplicados no ArguAna. No arquivo qrels, apenas o primeiro aparece como relevante (como contra-argumento) para a consulta (“test-economy-epiasghbf-pro02a”).

Ao comparar modelos na tabela de classificação do MTEB, é tentador focar na qualidade média de recuperação. Essa é uma boa aproximação da qualidade geral do modelo, mas não necessariamente indica como ele vai se comportar no seu caso de uso específico. Como os resultados são reportados por conjunto de dados, vale a pena entender o quanto cada conjunto se relaciona com a sua tarefa de busca e reavaliar os modelos usando apenas os mais relevantes. Se quiser se aprofundar ainda mais, também é possível verificar a sobreposição de tópicos entre os diferentes corpora dos conjuntos de dados. Estratificar as métricas de qualidade por tópico fornece uma avaliação muito mais detalhada de pontos fortes e limitações específicas.

Um ponto importante a destacar é que, quando um documento não está marcado no arquivo qrels , ele é considerado irrelevante para a consulta por padrão. Aprofundamos um pouco mais essa análise e reunimos evidências para esclarecer melhor a seguinte pergunta: “Com que frequência um avaliador se depara com pares (consulta, documento) para os quais não existe informação de comprovação?” Isso é importante porque, quando apenas anotações superficiais estão disponíveis (ou seja, nem todos os documentos relevantes são rotulados como tal), um sistema de recuperação de informação pode ser avaliado como pior do que outro simplesmente porque ele “escolhe” destacar documentos relevantes diferentes, porém não marcados. Essa é uma armadilha comum na criação de conjuntos de avaliação de alta qualidade, especialmente em conjuntos de dados grandes. Para que a rotulagem manual seja viável, ela normalmente se concentra nos principais resultados retornados pelo sistema atual, o que pode deixar de fora documentos relevantes que estão fora do seu campo de visão. Por isso, em geral é preferível concentrar mais recursos em uma anotação mais completa de um número menor de consultas, em vez de realizar uma anotação ampla porém superficial.

Usando o benchmark BEIR para avaliação de relevância de busca

Para iniciar nossa análise, implementamos o seguinte cenário (ver o notebook):

1. Primeiro, carregamos o corpus de cada conjunto de dados em um índice do Elasticsearch.

2. Para cada consulta no conjunto de teste, recuperamos os top 100 documentos usando BM25.

3. Em seguida, fazemos a reclassificação dos documentos recuperados usando uma variedade de modelos de reclassificação de última geração.

4. Por fim, reportamos a “taxa de julgamento” para os top 10 documentos provenientes das etapas 2 (após a recuperação) e 3 (após a reclassificação). Em outras palavras, calculamos a porcentagem média dos top 10 documentos que possuem uma pontuação no arquivo qrels.

A lista de modelos de reclassificação que usamos é a seguinte:

• Cohere rerank-english-v2.0 e rerank-english-v3.0

• BGE-base

• mxbai-rerank-xsmall-v1

• MiniLM-L-6-v2

Recuperação

Reclassificação

Conjunto de dados

BM25 (%)

Cohere Rerank v2 (%)

Cohere Rerank v3 (%)

BGE-base (%)

mxbai-rerank-xsmall-v1 (%)

MiniLM-L-6-v2 (%)

ArguAna

7,54

4,87

7,87

4,52

4,53

6,84

Climate-FEVER

5,75

6,24

8,15

9,36

7,79

7,58

DBPedia

61,18

60,78

64,15

63,9

63,5

67,62

FEVER

8,89

9,97

10,08

10,19

9,88

9,88

FiQa-2018

7,02

11,02

10,77

8,43

9,1

9,44

HotpotQA

12,59

14,5

14,76

15,1

14,02

14,42

Natural Questions

5,94

8,84

8,71

8,37

8,14

8,34

NFCorpus

31,67

32,9

33,91

30,63

32,77

32,45

Quora

12,2

10,46

13,04

11,26

12,58

12,78

SCIDOCS

8,62

9,41

9,71

8,04

8,79

8,52

SciFact

9,07

9,57

9,77

9,3

9,1

9,17

Touche2020

38,78

30,41

32,24

33,06

37,96

33,67

TREC-COVID

92,4

98,4

98,2

93,8

99,6

97,4

MSMARCO

3,97

6,00

6,03

6,07

5,47

6,11

CQADupstack (média)

5,47

6,32

6,87

5,89

6,22

6,16

Tabela 2: Taxa de julgamento por pares (conjunto de dados, reclassificador), calculada sobre os top 10 documentos recuperados/reclassificados

A partir da Tabela 2, com exceção de TREC-COVID (cobertura de >90%), DBPedia (~65%), Touche2020 e nfcorpus (~35%), observamos que a maioria dos conjuntos de dados apresenta uma taxa de rotulagem entre 5% e pouco mais de 10% após a recuperação ou a reclassificação. Isso não significa que todos esses documentos não marcados sejam relevantes, mas pode haver um subconjunto deles — especialmente aqueles posicionados no topo — que seja positivo.

Com a chegada de modelos de linguagem de propósito geral ajustados por instruções, passamos a contar com uma nova e poderosa ferramenta que pode, potencialmente, automatizar a avaliação de relevância. Esses métodos normalmente são computacionalmente caros demais para uso online em sistemas de busca, mas aqui estamos tratando de avaliação offline. A seguir, usamos esses modelos para explorar evidências de que alguns conjuntos de dados do BEIR sofrem com anotações superficiais.

Para investigar melhor essa hipótese, decidimos focar no MSMARCO e selecionar um subconjunto de 100 consultas, juntamente com os top 5 documentos reclassificados (com Cohere v2) que atualmente não estão marcados como relevantes. Primeiro, usamos um prompt cuidadosamente ajustado (falaremos mais sobre isso em um post futuro) para preparar o modelo Phi-3-mini-4k, lançado recentemente, a prever se um documento é ou não relevante para a consulta. Em paralelo, esses mesmos casos também foram rotulados manualmente, de modo a avaliar a taxa de concordância entre a saída do LLM e o julgamento humano. De forma geral, podemos tirar as duas conclusões a seguir:

• A taxa de concordância entre as respostas dos LLMs e os julgamentos humanos ficou próxima de 80%, o que parece um ponto de partida razoável nessa direção.

• Em 57,6% dos casos (com base em julgamento humano), os documentos retornados foram considerados realmente relevantes para a consulta. Colocando isso de outra forma: para 100 consultas, temos 107 documentos julgados como relevantes, mas pelo menos 0,576 × 5 × 100 = 288 documentos adicionais que também são, de fato, relevantes.

Aqui estão alguns exemplos extraídos do conjunto de dados MSMARCO/dev que incluem a consulta, o documento positivo anotado (de qrels) e um documento falso negativo devido a anotações incompletas:

Exemplo 1:

Exemplo 2:

Avaliar manualmente consultas específicas dessa forma é uma técnica geralmente útil para entender a qualidade da busca e complementa métricas quantitativas como o nDCG@10. Se você tiver um conjunto representativo de consultas que sempre executa ao fazer alterações no sistema de busca, isso fornece informações qualitativas importantes sobre como a performance muda, algo que não aparece nas estatísticas. Por exemplo, essa abordagem oferece muito mais visibilidade sobre resultados incorretos retornados pela busca: ajuda a identificar erros evidentes nos documentos recuperados, classes de falhas recorrentes, como interpretações equivocadas de terminologia específica de um domínio, entre outros.

Nossos resultados estão alinhados com pesquisas relevantes sobre avaliação em MSMARCO. Por exemplo, Arabzadeh et al. seguem um procedimento semelhante ao empregar trabalhadores de crowdsourcing para realizar julgamentos de preferência. Entre outros achados, eles mostram que, em muitos casos, os documentos retornados pelos módulos de reclassificação são preferidos em relação aos documentos presentes no arquivo qrels do MSMARCO. Outra evidência vem dos autores do reclassificador RocketQA, que relatam que mais de 70% dos documentos reclassificados foram considerados relevantes após inspeção manual.

Atualização – 9 de setembro: após uma reavaliação cuidadosa do conjunto de dados, identificamos mais 15 casos de documentos relevantes, aumentando o total de 273 para 288.

Principais conclusões e próximos passos

• A busca por uma comprovação melhor é contínua e extremamente importante para benchmarking e comparação de modelos. Os LLMs podem auxiliar em algumas áreas da avaliação, desde que usados com cautela e ajustados com instruções adequadas.

• De forma mais geral, considerando que benchmarks nunca serão perfeitos, pode ser preferível migrar de uma comparação puramente baseada em pontuações para técnicas mais robustas, capazes de capturar diferenças estatisticamente significativas. O trabalho de Arabzadeh et al. oferece um bom exemplo disso: com base em seus resultados, os autores constroem intervalos de confiança de 95% para indicar se as diferenças entre diferentes execuções são estatisticamente significativas ou não. No notebook que acompanha este conteúdo, fornecemos uma implementação de intervalos de confiança usando bootstrapping.

• Do ponto de vista do usuário final, é útil pensar em alinhamento com a tarefa ao interpretar resultados de benchmarks. Por exemplo, para um engenheiro de IA que constrói um pipeline de RAG e sabe que o caso de uso mais comum envolve reunir múltiplas informações de diferentes fontes, faz mais sentido avaliar o desempenho do modelo de recuperação em conjuntos de dados de QA multi-hop, como o HotpotQA, em vez de considerar apenas a média global de todo o benchmark BEIR.

No próximo post do blog, vamos nos aprofundar no uso do Phi-3 como avaliador baseado em LLM e no processo de ajuste do modelo para prever relevância.

Existe uma distinção entre inspiração e paráfrase. É possível ler um conteúdo, se inspirar e depois explorar a ideia com suas próprias palavras, mesmo que você chegue a uma conclusão semelhante.

Embora o plágio seja um tema de discussão há muito tempo, a produção e publicação aceleradas de conteúdo o mantiveram relevante e representaram um desafio constante.

Esse desafio não se limita a livros, pesquisas acadêmicas ou documentos judiciais, onde verificações de plágio são realizadas com frequência. Isso também pode se estender a jornais e até mesmo às redes sociais.

Com a abundância de informações e o fácil acesso à publicação, como o plágio pode ser verificado de forma eficaz e em larga escala?

Universidades, entidades governamentais e empresas utilizam diversas ferramentas, mas, embora uma simples busca lexical possa detectar plágio direto com eficácia, o principal desafio reside na identificação de conteúdo parafraseado.

Detecção de plágio com IA generativa

Um novo desafio surge com a IA generativa. O conteúdo gerado por IA é considerado plágio quando copiado?

Os termos de uso da OpenAI , por exemplo, especificam que a OpenAI não reivindicará direitos autorais sobre o conteúdo gerado pela API para os usuários. Nesse caso, os indivíduos que utilizam sua IA generativa podem usar o conteúdo gerado como preferirem, sem necessidade de citação.

No entanto, a aceitação do uso de IA generativa para melhorar a eficiência ainda é um tema de debate.

Na tentativa de contribuir para a detecção de plágio, a OpenAI desenvolveu um modelo de detecção , mas posteriormente reconheceu que sua precisão não é suficientemente alta.

"Acreditamos que essa precisão não é suficiente para uma detecção independente e precisa ser combinada com abordagens baseadas em metadados, julgamento humano e educação pública para ser mais eficaz."

O desafio persiste; no entanto, com a disponibilidade de mais ferramentas, existem agora mais opções para detectar plágio, mesmo em casos de conteúdo parafraseado e gerado por IA.

Detecção de plágio com Elasticsearch

Reconhecendo isso, neste blog exploraremos mais um caso de uso com modelos de Processamento de Linguagem Natural (PLN) e Busca Vetorial: a detecção de plágio, além das buscas por metadados.

Isso é demonstrado com exemplos em Python, onde utilizamos um conjunto de dados do SentenceTransformers contendo artigos relacionados a PNL (Processamento de Linguagem Natural). Verificamos se os resumos contêm plágio realizando uma 'similaridade textual semântica', considerando representações vetoriais de 'resumos' geradas com um modelo de incorporação de texto previamente importado para o Elasticsearch. Além disso, para identificar conteúdo gerado por IA — plágio por IA —, um modelo de PNL desenvolvido pela OpenAI também foi importado para o Elasticsearch.

A imagem a seguir ilustra o fluxo de dados:

Durante o processo de ingestão com um processador de inferência, o parágrafo 'abstract' é mapeado para um vetor de 768 dimensões, o 'abstract_vector.predicted_value'.

Mapeamento:

A similaridade entre representações vetoriais é medida usando uma métrica de similaridade vetorial, definida pelo parâmetro 'similaridade'.

O cosseno é a métrica de similaridade padrão, calculada como '(1 + cosseno(consulta, vetor)) / 2'. A menos que seja necessário preservar os vetores originais e não seja possível normalizá-los antecipadamente, a maneira mais eficiente de realizar a similaridade de cosseno é normalizar todos os vetores para comprimento unitário. Isso ajuda a evitar cálculos extras de comprimento de vetor durante a busca; em vez disso, use 'produto escalar'.

Nesse mesmo fluxo de trabalho, outro processador de inferência contendo o modelo de classificação de texto detecta se o conteúdo é 'Real', provavelmente escrito por humanos, ou 'Falso', provavelmente escrito por IA, adicionando o 'openai-detector.predicted_value' a cada documento.

Pipeline de ingestão:

No momento da consulta, o mesmo modelo de incorporação de texto também é empregado para gerar a representação vetorial da consulta 'model_text' em um objeto 'query_vector_builder'.

Uma busca por k-vizinhos mais próximos (kNN) encontra os k vetores mais próximos do vetor de consulta, medidos pela métrica de similaridade.

A pontuação de cada documento é derivada da similaridade, garantindo que uma pontuação maior corresponda a uma classificação mais alta. Isso significa que o documento é semanticamente mais semelhante. Como resultado, estamos apresentando três possibilidades: se a pontuação for > 0,9, consideramos 'alta similaridade'; se for < 0,7, 'baixa similaridade'; caso contrário, 'similaridade moderada'. Você tem a flexibilidade de definir diferentes valores de limite para determinar qual nível de _score se qualifica como plágio ou não, com base no seu caso de uso.

Além disso, é realizada uma classificação de texto para verificar também a presença de elementos gerados por IA na consulta textual.

Consulta:

Saída:

Neste exemplo, após utilizar um dos valores 'abstratos' do nosso conjunto de dados como a consulta de texto 'model_text', foi identificado plágio. A pontuação de similaridade é 1,0, indicando um alto nível de similaridade — plágio direto. A consulta vetorizada e o documento não foram reconhecidos como conteúdo gerado por IA, o que era esperado.

Consulta:

Saída:

Ao atualizar a consulta de texto 'model_text' com um texto gerado por IA que transmite a mesma mensagem, minimizando a repetição de palavras semelhantes, a similaridade detectada ainda foi alta, mas a pontuação foi de 0,9302529 em vez de 1,0 — plágio por paráfrase. Também era esperado que essa consulta, gerada por IA, fosse detectada.

Por fim, considerando a consulta de texto 'model_text' como um texto sobre Elasticsearch, que não é um resumo de nenhum desses documentos, a similaridade detectada foi de 0,68991005, indicando baixa similaridade de acordo com os valores de limite considerados.

Consulta:

Saída:

Embora o plágio tenha sido identificado com precisão na consulta de texto gerada pela IA, bem como em casos de paráfrase e conteúdo copiado diretamente, navegar pelo cenário da detecção de plágio envolve reconhecer vários aspectos.

No contexto da detecção de conteúdo gerado por IA, exploramos um modelo que oferece uma contribuição valiosa. No entanto, é crucial reconhecer as limitações inerentes à detecção isolada, o que torna necessária a incorporação de outros métodos para aumentar a precisão.

A variabilidade introduzida pela escolha dos modelos de incorporação de texto é outra consideração importante. Diferentes modelos, treinados com conjuntos de dados distintos, resultam em níveis variados de similaridade, o que destaca a importância das representações vetoriais de texto geradas.

Por fim, nesses exemplos, utilizamos o resumo do documento. No entanto, a detecção de plágio geralmente envolve documentos extensos, tornando essencial abordar o desafio do tamanho do texto. É comum que o texto exceda o limite de tokens de um modelo, exigindo segmentação em partes antes da construção dos embeddings. Uma abordagem prática para lidar com isso envolve a utilização de estruturas aninhadas com dense_vector.

Conclusão

Neste blog, discutimos os desafios da detecção de plágio, particularmente em conteúdo parafraseado e gerado por IA, e como a similaridade textual semântica e a classificação de texto podem ser usadas para esse fim.

Ao combinar esses métodos, fornecemos um exemplo de detecção de plágio no qual identificamos com sucesso conteúdo gerado por IA, plágio direto e plágio por paráfrase.

O objetivo principal era estabelecer um sistema de filtragem que simplificasse a detecção, mas a avaliação humana continua sendo essencial para a validação.

Se você tiver interesse em aprender mais sobre similaridade textual semântica e PNL, recomendamos que você também confira estes links:

• O que é a busca semântica?

• O que é processamento de linguagem natural (PLN)?

• Busca Léxica e Semântica com Elasticsearch

• Fragmentar documentos grandes por meio de pipelines de ingestão, juntamente com vetores aninhados, resulta em uma busca de trechos facilitada.

Considerando esse objetivo, neste post do blog, exploraremos diferentes abordagens para recuperar informações usando o Elasticsearch, com foco específico em busca de texto: busca lexical e busca semântica.

Pré-requisitos

Para isso, forneceremos exemplos em Python que demonstram vários cenários de pesquisa em um conjunto de dados gerado para simular informações de produtos de comércio eletrônico.

Este conjunto de dados contém mais de 2.500 produtos, cada um com uma descrição. Esses produtos estão categorizados em 76 categorias distintas, cada uma contendo um número variável de produtos, conforme mostrado abaixo:

Visualização em mapa de árvore - os 22 principais valores de category.keyword (categorias de produtos)

Para a configuração, você precisará de:

• Python 3.6 ou posterior

• O cliente Elastic Python

• Implantação do Elasticsearch 8.8 ou posterior, com nó de aprendizado de máquina de 8 GB de memória.

• O modelo Elastic Learned Sparse EncodeR que vem pré-carregado no Elastic instalado e em execução na sua implementação.

Usaremos o Elastic Cloud, e um período de teste gratuito está disponível.

Além das consultas de pesquisa fornecidas nesta postagem do blog, um notebook Python irá guiá-lo pelos seguintes processos:

• Estabeleça uma conexão com nossa implantação Elastic usando o cliente Python.

• Carregar um modelo de incorporação de texto no cluster Elasticsearch

• Crie um índice com mapeamentos para indexar vetores de características e vetores densos.

• Crie um pipeline de ingestão com processadores de inferência para incorporação e expansão de texto.

Busca lexical - recuperação esparsa

A forma clássica como os documentos são classificados por relevância pelo Elasticsearch com base em uma consulta de texto utiliza a implementação Lucene do modelo BM25 , um modelo esparso para busca lexical. Este método segue a abordagem tradicional para busca de texto, procurando por correspondências exatas dos termos.

Para tornar essa busca possível, o Elasticsearch converte os dados dos campos de texto em um formato pesquisável, realizando uma análise de texto.

A análise de texto é realizada por um analisador, um conjunto de regras que regem o processo de extração de tokens relevantes para a pesquisa. Um analisador deve ter exatamente um tokenizador. O analisador léxico recebe um fluxo de caracteres e o divide em tokens individuais (geralmente palavras individuais), como no exemplo abaixo:

Tokenização de strings para busca lexical

Saída

Neste exemplo, estamos usando o analisador padrão , que funciona bem para a maioria dos casos de uso, pois fornece tokenização baseada na gramática inglesa. A tokenização permite a correspondência de termos individuais, mas cada token ainda é correspondido literalmente.

Se você deseja personalizar sua experiência de busca, pode escolher um analisador integrado diferente. Por exemplo, ao atualizar o código para usar o analisador de palavras irrelevantes, o texto será dividido em tokens em qualquer caractere que não seja letra, com suporte para a remoção de palavras irrelevantes.

Saída

Quando os analisadores integrados não atendem às suas necessidades, você pode criar um analisador personalizado, que utiliza a combinação apropriada de zero ou mais filtros de caracteres, um analisador léxico e zero ou mais filtros de tokens.

No exemplo acima, que combina um analisador léxico e filtros de tokens, o texto será convertido para minúsculas pelo filtro de minúsculas antes de ser processado pelo filtro de tokens de sinônimos.

Correspondência lexical

O BM25 medirá a relevância dos documentos para uma determinada consulta de pesquisa com base na frequência dos termos e na sua importância.

O código abaixo realiza uma consulta de correspondência , buscando até dois documentos considerando os valores do campo "description" do índice "ecommerce-search" e a consulta de pesquisa "Móveis confortáveis para uma varanda grande".

Refinar os critérios para que um documento seja considerado uma correspondência para esta consulta pode melhorar a precisão. No entanto, resultados mais específicos têm como contrapartida uma menor tolerância a variações.

Saída

Ao analisar os resultados, o mais relevante é o produto "Casa dos Sonhos da Barbie", na categoria "Brinquedos", cuja descrição é altamente relevante por incluir os termos "móveis", "grande" e "varanda". Este é o único produto com três termos na descrição que correspondem à consulta de pesquisa, sendo também o único com o termo "varanda" na descrição.

O segundo produto mais relevante é uma "Cadeira de Balanço Confortável", categorizada como "Móveis para Interiores", cuja descrição inclui os termos "confortável" e "móveis". Apenas 3 produtos no conjunto de dados correspondem a pelo menos 2 termos desta consulta de pesquisa, e este produto é um deles.

"Confortável" aparece na descrição de 105 produtos e "móveis" na descrição de 4 produtos com 4 categorias diferentes: Brinquedos, Móveis para Interior, Móveis para Exterior e 'Suprimentos e Brinquedos para Cães e Gatos'.

Como você pôde ver, o produto mais relevante considerando a consulta é um brinquedo e o segundo produto mais relevante são móveis para interiores. Se você deseja informações detalhadas sobre o cálculo da pontuação para saber por que esses documentos correspondem, pode definir o parâmetro explain __query como verdadeiro.

Apesar de ambos os resultados serem os mais relevantes, considerando tanto o número de documentos quanto a ocorrência de termos neste conjunto de dados, a intenção por trás da consulta "Móveis confortáveis para uma varanda grande" é buscar móveis para uma varanda grande de fato, excluindo, entre outros, brinquedos e móveis de interior.

A busca lexical é relativamente simples e rápida, mas tem limitações, já que nem sempre é possível conhecer todos os termos e sinônimos possíveis sem necessariamente conhecer a intenção e as consultas do usuário. Um fenômeno comum no uso da linguagem natural é a incompatibilidade de vocabulário. Pesquisas mostram que, em média, 80% das vezes, pessoas diferentes (especialistas na mesma área) nomeiam a mesma coisa de maneiras diferentes.

Essas limitações nos motivam a buscar outros modelos de pontuação que incorporem conhecimento semântico. Os modelos baseados em Transformers, que se destacam no processamento de tokens de entrada sequenciais, como a linguagem natural, capturam o significado subjacente da sua pesquisa considerando representações matemáticas tanto dos documentos quanto das consultas. Isso permite uma representação vetorial densa e contextualizada do texto, impulsionando a Busca Semântica, uma maneira refinada de encontrar conteúdo relevante.

Busca semântica - recuperação densa

Nesse contexto, após converter seus dados em valores vetoriais significativos, o algoritmo de busca k-vizinhos mais próximos (kNN) é utilizado para encontrar representações vetoriais em um conjunto de dados que sejam mais semelhantes a um vetor de consulta. O Elasticsearch suporta dois métodos para busca kNN: kNN exato por força bruta e kNN aproximado, também conhecido como ANN.

O kNN de força bruta garante resultados precisos, mas não escala bem com grandes conjuntos de dados. O algoritmo kNN aproximado encontra de forma eficiente os vizinhos mais próximos aproximados, sacrificando um pouco de precisão em troca de um melhor desempenho.

Com o suporte do Lucene para busca kNN e índices vetoriais densos, o Elasticsearch aproveita o algoritmo Hierarchical Navigable Small World (HNSW), que demonstra um forte desempenho de busca em diversos conjuntos de dados de benchmark de redes neurais. Uma busca aproximada por kNN pode ser realizada em Python usando o código de exemplo abaixo.

Busca semântica com kNN aproximado

Este bloco de código usa o kNN do Elasticsearch para retornar até dois produtos com uma descrição semelhante à consulta vetorizada (query_vector_build) de "Móveis confortáveis para uma varanda grande", considerando os embeddings do campo "descrição " no conjunto de dados de produtos.

Os embeddings dos produtos foram gerados previamente em um pipeline de ingestão com um processador de inferência contendo o modelo de embedding de texto "all-mpnet-base-v2" para inferir com base nos dados que estavam sendo ingeridos no pipeline.

Este modelo foi escolhido com base na avaliação de modelos pré-treinados usando "sentence_transformers.evaluation". onde diferentes classes são usadas para avaliar um modelo durante o treinamento. O modelo "all-mpnet-base-v2" demonstrou o melhor desempenho médio de acordo com o ranking do Sentence-Transformers e também garantiu uma posição favorável no ranking do Massive Text Embedding Benchmark (MTEB) . O modelo, pré-treinado a partir do modelo microsoft/mpnet-base e ajustado em um conjunto de dados de 1 bilhão de pares de frases, mapeia as frases para um espaço vetorial denso de 768 dimensões.

Alternativamente, existem muitos outros modelos disponíveis que podem ser utilizados, especialmente aqueles ajustados especificamente para os dados do seu domínio.

Saída

O resultado pode variar dependendo do modelo escolhido, dos filtros e do ajuste aproximado do kNN.

Os resultados da pesquisa kNN estão ambos na categoria "Móveis para Exterior", embora a palavra "exterior" não tenha sido mencionada explicitamente na consulta, o que destaca a importância da compreensão semântica no contexto.

A busca vetorial densa oferece diversas vantagens:

• Habilitar a pesquisa semântica

• Escalabilidade para lidar com conjuntos de dados muito grandes

• Flexibilidade para lidar com uma ampla variedade de tipos de dados.

No entanto, a busca vetorial densa também apresenta seus próprios desafios:

• Selecionando o modelo de incorporação correto para o seu caso de uso.

• Uma vez escolhido o modelo, pode ser necessário ajustá-lo para otimizar o desempenho em um conjunto de dados específico do domínio, um processo que exige o envolvimento de especialistas na área.

• Além disso, a indexação de vetores de alta dimensão pode ser computacionalmente dispendiosa.

Busca semântica - recuperação esparsa aprendida

Vamos explorar uma abordagem alternativa: recuperação esparsa aprendida, outra maneira de realizar buscas semânticas.

Como um modelo esparso, ele utiliza o índice invertido baseado em Lucene do Elasticsearch, que se beneficia de décadas de otimizações. No entanto, essa abordagem vai além da simples adição de sinônimos com funções de pontuação lexical como o BM25. Em vez disso, incorpora associações aprendidas usando um conhecimento mais profundo em escala linguística para otimizar a relevância.

Ao expandir as consultas de pesquisa para incluir termos relevantes que não estão presentes na consulta original, o Elastic Learned Sparse Encoder aprimora os embeddings de vetores esparsos, como você pode ver no exemplo abaixo.

Busca vetorial esparsa com codificador esparso de aprendizado elástico

Saída

Os resultados, neste caso, incluem a categoria "Móveis de Jardim", que oferece produtos bastante semelhantes aos de "Móveis para Exterior".

Ao analisar "ml.tokens", Ao analisar o campo "rank_features" que contém os tokens gerados pela Recuperação Esparsa Aprendida, torna-se evidente que, entre os vários tokens gerados, existem termos que, embora não façam parte da consulta de pesquisa, ainda são relevantes em significado, como "relaxar" (confortável), "sofá" (móveis) e "exterior" (varanda).

A imagem abaixo destaca alguns desses termos juntamente com a consulta, tanto com quanto sem expansão de termos.

Conforme observado, este modelo proporciona uma busca sensível ao contexto e ajuda a mitigar o problema de incompatibilidade de vocabulário, ao mesmo tempo que oferece resultados mais interpretáveis. Ele pode até superar modelos vetoriais densos quando nenhum re-treinamento específico do domínio é aplicado.

Busca híbrida: resultados relevantes combinando busca lexical e semântica.

Quando se trata de pesquisa, não existe uma solução universal. Cada um desses métodos de recuperação tem seus pontos fortes, mas também seus desafios. Dependendo do caso de uso, a melhor opção pode mudar. Muitas vezes, os melhores resultados obtidos com diferentes métodos de recuperação de informação podem ser complementares. Portanto, para melhorar a relevância, vamos analisar a possibilidade de combinar os pontos fortes de cada método.

Existem várias maneiras de implementar uma busca híbrida, incluindo combinação linear, atribuição de um peso a cada pontuação e fusão de classificação recíproca (RRF), onde especificar um peso não é necessário.

Elasticsearch: o melhor dos dois mundos com busca lexical e semântica

Neste código, realizamos uma busca híbrida com duas consultas que tinham o valor "Uma mesa de jantar e cadeiras confortáveis para uma varanda grande". Em vez de usar "móveis" como termo de busca, estamos especificando o que procuramos, e ambas as buscas consideram os mesmos valores de campo, "descrição". A classificação é determinada por uma combinação linear com pesos iguais para as pontuações BM25 e ELSER.

Saída

No código abaixo, usaremos o mesmo valor para a consulta, mas combinaremos as pontuações de BM25 (parâmetro de consulta) e kNN (parâmetro knn) usando o método de fusão de classificação recíproca para combinar e classificar os documentos.

A funcionalidade RRF está em fase de pré-visualização técnica. A sintaxe provavelmente mudará antes do lançamento oficial.

Saída

Aqui também poderíamos usar campos e valores diferentes; alguns desses exemplos estão disponíveis no notebook Python.

Como você pode ver, com o Elasticsearch você tem o melhor dos dois mundos: a busca lexical tradicional e a busca vetorial, seja ela esparsa ou densa, para atingir seu objetivo e encontrar a melhor resposta possível para sua pergunta.

Se você deseja continuar aprendendo sobre as abordagens mencionadas aqui, estes blogs podem ser úteis:

• Aprimorando a recuperação de informações no Elastic Stack: Recuperação híbrida

• Busca vetorial no Elasticsearch: a lógica por trás do design

• Como obter o melhor da busca lexical e da busca com inteligência artificial usando o banco de dados vetorial da Elastic.

• Apresentando o Elastic Learned Sparse Encoder: o modelo de IA da Elastic para busca semântica.

• Aprimorando a recuperação de informações no Elastic Stack: Apresentando o Elastic Learned Sparse Encoder, nosso novo modelo de recuperação.

O Elasticsearch fornece um banco de dados vetorial, juntamente com todas as ferramentas necessárias para criar pesquisas vetoriais:

• banco de dados vetorialElasticsearch

• Casos de uso de busca vetorial com Elastic

Conclusão

Neste artigo, exploramos diversas abordagens para recuperar informações usando o Elasticsearch, com foco específico em busca textual, lexical e semântica. Para demonstrar isso, fornecemos exemplos em Python que mostram diferentes cenários de pesquisa usando um conjunto de dados contendo informações de produtos de comércio eletrônico.

Analisamos a busca lexical clássica com BM25 e discutimos seus benefícios e desafios, como a incompatibilidade de vocabulário. Enfatizamos a importância de incorporar conhecimento semântico para superar esse problema. Além disso, discutimos a busca vetorial densa, que possibilita a busca semântica, e abordamos os desafios associados a esse método de recuperação, incluindo o custo computacional na indexação de vetores de alta dimensão.

Por outro lado, mencionamos que vetores esparsos se comprimem excepcionalmente bem. Assim, discutimos o Learned Sparse Encoder da Elastic, que expande as consultas de pesquisa para incluir termos relevantes não presentes na consulta original.

Não existe uma solução única que sirva para todos quando se trata de pesquisa. Cada método de recuperação tem seus pontos fortes e desafios. Portanto, também discutimos o conceito de busca híbrida.

Como você pôde ver, com o Elasticsearch, você pode ter o melhor dos dois mundos: busca lexical tradicional e busca vetorial!

Pronto para começar? Confira o notebook Python disponível e inicie um teste gratuito do Elastic Cloud.