Para novos usuários, esta é a maneira mais rápida de colocar a busca vetorial de alta qualidade em funcionamento. Se você já usa o Elasticsearch, a nova oferta é a busca vetorial na plataforma onde seus dados já estão, sem nenhum novo sistema para adotar. O Elasticsearch Vector Database oferece suporte a uma variedade de cenários, desde a fundamentação de um grande modelo de linguagem (LLM) e o fornecimento de recuperação e memória para um agente de IA até o atendimento de centenas de bilhões de vetores. Crie um novo projeto e comece em minutos.

Um motor, todos os casos de uso vetoriais

O banco de dados vetorial do Elasticsearch foi desenvolvido para qualquer pessoa que crie aplicativos usando vetores:

• RAG: recupere o contexto certo para o seu LLM com a recuperação de vetores densos e esparsos, ou opte pela busca híbrida combinando a recuperação vetorial e lexical. A qualidade da sua geração melhora com a qualidade da sua recuperação.

• Agentes de IA: forneça aos agentes recuperação rápida e filtrada de documentos e memória de conversação, com as baixas latências que loops de agentes em várias etapas exigem.

• Busca semântica: faça a correspondência por significado, não por palavras-chave, com um tipo de campo e zero código de pipeline.

• Recomendações e similaridade: encontre vizinhos mais próximos em produtos, imagens ou qualquer conteúdo que você tenha, em escala.

Tudo o que sua carga de trabalho vetorial precisa, otimizado e pronto para uso

Criar uma aplicação baseada em vetores significa conectar várias partes separadas: configurar e hospedar modelos de embedding, fazer a indexação dos seus documentos por meio deles, armazenar os vetores com eficiência, aplicar o modelo de embedding a cada consulta, fazer a correspondência com o armazenamento de vetores e, por fim, recuperar os documentos por trás das correspondências. O Elasticsearch Vector Database cuida de tudo isso para você, sem necessidade de configuração ou setup adicional.

Indexação de vetores com o modo de índice vectordb_document

O modo de índice vectordb_document, uma nova configuração de índice desenvolvida especificamente para cargas de trabalho que priorizam vetores, vem ativado por padrão, para que você obtenha as configurações que os especialistas escolheriam. Veja o que ele ativa:

• bfloat16 por padrão: os vetores são armazenados com metade do tamanho do float32 com impacto insignificante no recall, reduzindo o consumo de disco aproximadamente pela metade antes mesmo de a quantização entrar em cena.

• Vetores de origem excluídos: no Elasticsearch, seus embeddings já residem nas estruturas de índice usadas para busca; manter uma segunda cópia bruta no _source apenas infla o armazenamento e desacelera a recuperação de resultados. Excluímos a duplicata para que as respostas retornem mais rápido e você armazene menos.

• Os arquivos certos pré-carregados no cache: as estruturas de dados que as consultas vetoriais acessam primeiro são carregadas na memória antecipadamente, para que sua primeira consulta (e também a milésima) seja ultrarrápida.

• Mesclagem paralela: a mesclagem consolida segmentos em estruturas de vetores mais bem organizadas, o que melhora o recall e reduz a latência, e executar essas mesclagens com várias threads significa que você chega lá mais rápido.

Armazenamento de vetores, compressão e ajuste automático

• Seus vetores são compactados automaticamente. O Better Binary Quantization (BBQ) reduz o consumo de memória dos vetores em até 32x enquanto preserva o recall, e o DiskBBQ reduz ainda mais os requisitos de memória para cargas de trabalho em grande escala. 

• Opte pela calibração automática, que ajusta a quantização de cada segmento aos seus dados e a reajusta a cada mesclagem conforme os dados sofrem desvios. Quando testado em 18 conjuntos de dados, o número de consultas por segundo (QPS) melhorou em uma média de 16,7%, com ganhos de recall na maioria deles.

Embeddings em inferência gerenciada por GPU

• Gere embeddings com os modelos nativos de embedding e reranking da Jina AI, ou traga modelos de terceiros, tudo em GPUs gerenciadas via Elastic Inference Service (EIS), sem precisar operar servidores de modelos. Ou faça a auto-hospedagem, se preferir usar seu próprio modelo.

• O tipo de campo semantic_text lida automaticamente com o particionamento e a geração de embeddings, além de consultas, o caminho mais simples para a busca semântica no mercado. 

Busca híbrida e busca vetorial filtrada

• A busca híbrida é integrada, combinando a recuperação de texto completo e de vetores em uma única consulta. Combine os resultados com reciprocal rank fusion (RRF) ou qualquer outro mecanismo de combinação que você quiser. A busca vetorial normalmente é a parte mais difícil de configurar bem na busca híbrida. Com o banco de dados vetorial do Elasticsearch, você tem tudo sob controle e toda a sua stack híbrida fica ainda melhor. 

• Com a busca vetorial filtrada, aplique filtros de metadados como parte da própria recuperação vetorial, e não como uma etapa adicionada posteriormente que prejudica o recall.

Empresarial desde o primeiro dia

Você também conta com controle de acesso baseado em funções (RBAC), logging de auditoria e as certificações de conformidade que geralmente faltam nos bancos de dados exclusivamente vetoriais.

Acessível em escala e previsível

O banco de dados vetorial do Elasticsearch foi desenvolvido para continuar acessível à medida que você cresce: a compressão com BBQ e DiskBBQ, que mantém o armazenamento linear e o uso de memória baixo, significa que redimensionar para centenas de bilhões de vetores não faz sua conta disparar. E o que você paga é calculado com base em números que já conhece: a quantidade de dados que armazena e indexa, além da capacidade de busca de que precisa. Estime a quantidade de documentos e as dimensões dos vetores, além da carga de consultas, e você poderá calcular o que vai pagar antes de criar o projeto. Você também pode entender sua conta linha por linha no fim do mês. Não há unidades de computação opacas nem cobranças surpresa por operações em segundo plano.

Como começar com o banco de dados vetorial do Elasticsearch

Crie um projeto de banco de dados vetorial serverless

Crie um novo projeto serverless de banco de dados vetorial no Elastic Cloud. Aponte seus dados para o endpoint, e você estará pronto para indexar.

Criar um índice usando semantic_text

O modo de índice vetorial gerencia a configuração do vetor. Usar semantic_text significa que a configuração de embeddings e particionamento, assim como a configuração do índice, é gerenciada para você com inferência gerenciada por GPU, sem a necessidade de criar um pipeline de embeddings.

Ingerir documentos

Indexe texto, e os embeddings são gerados para você.

Execute uma consulta de busca semântica

Consulte o mesmo campo semântico que você acabou de criar:

E você recebe os resultados de volta:

A busca semântica é apenas o começo. Execute consultas totalmente textuais ou combine os dois tipos em consultas híbridas. Você pode até criar suas próprias consultas vetoriais para ter controle total. Siga o guia de início rápido da busca semântica na documentação para obter as instruções completas.

O que vem por aí para a busca vetorial no Elasticsearch

Já estamos trabalhando nas próximas melhorias:

• Melhor gerenciamento multitenant: se os seus dados precisarem permanecer separados por tenant, vamos oferecer uma maneira de fazer isso mais rápido e com menos código.

• Otimização automática de índice: de "índice novo em folha" a "totalmente otimizado", com o mínimo de ajustes possível.

• Melhorias contínuas de infraestrutura: ajuste contínuo das configurações e da infraestrutura do banco de dados vetorial para que você tenha sempre a melhor taxa de transferência e as respostas mais rápidas.

Experimente o banco de dados vetorial do Elasticsearch no Elastic Cloud Serverless

Vá de um projeto vazio a uma consulta vetorial híbrida e filtrada em minutos, com padrões de nível de produção fazendo o ajuste para você. Crie apps de IA rápidos e escaláveis, não infraestrutura.

Comece no Elastic Cloud Serverless, ou mergulhe na documentação completa e na referência da API.

O que é recall?

O recall mede em uma escala de 0 a 1 quantos dos documentos que seus usuários realmente querem aparecem em algum lugar dos seus resultados de busca. Se uma consulta aparecer em três produtos e sua busca devolver apenas dois deles entre os 10 primeiros, recall@10 = 0.67 nessa consulta. É uma métrica baseada em conjuntos: ela não se importa com a posição dos documentos relevantes dentro desses k resultados. Um documento relevante na posição 10 conta o mesmo que um na posição 1. Ter um recall alto significa que você não está perdendo resultados relevantes.

O diagrama mostra dois conjuntos: todos os documentos relevantes (à esquerda) e o que o BM25 realmente recuperou (top 10, à direita). Apenas a interseção conta para a recuperação, prod_1 e prod_2 foram encontrados, enquanto prod_3, prod_4 e prod_6 foram completamente perdidos. Resultado: Recall@10 = 2/5 = 0.40.

Pré-requisitos

Vamos direto ao ponto para entender melhor como o recall funciona. Esta demonstração usa Python. Você pode acompanhar no notebook complementar (notebook.ipynb), onde cada bloco de código é uma célula pronta para ser executada.

O código fornecido utiliza o seguinte:

• Elasticsearch 9.3+

• Python 3.10+

• Um arquivo .env com suas credenciais do Elasticsearch

O conjunto de dados

Usaremos um catálogo de produtos com 1.000 produtos, abrangendo categorias como calçados, eletrônicos, ferramentas e outros.

Cada documento tem quatro campos:

Campo

Tipo

`title`

texto

`description`

texto

`marca`

palavra-chave

`category`

palavra-chave

O conjunto de dados é carregado a partir de dataset.csv.

O poder e os limites da busca lexical

BM25 é o algoritmo padrão de ranqueamento no Elasticsearch e na maioria dos mecanismos de busca. Ele classifica os documentos de acordo com a frequência com que seus termos de consulta aparecem neles, ajustados ao tamanho do documento e à frequência desses termos em todo o índice. Você tem analisadores na parte superior: normalização de letras minúsculas, stemming e retirada de stopwords. Uma busca por "tênis de corrida" retornará resultados como "Tênis de corrida" e provavelmente também "correr".

Isso funciona bem para uma grande classe de consultas:

• "tênis de corrida" faz a correspondência imediata dos produtos com esses tokens exatos no título.

• "alto-falante Bluetooth" destaca produtos de áudio portáteis porque os tokens aparecem literalmente.

Os resultados são determinísticos e explicáveis: um documento tem classificação alta porque os termos de consulta aparecem nele. Depurar a relevância é simples.

Onde ocorre a falha

Agora, vamos testar essas consultas no mesmo catálogo:

• "rotina de cuidados com a pele": a palavra "rotina" não aparece em nenhum título de produto. O BM25 pode corresponder parcialmente com "cuidados com a pele", mas séruns faciais, óleos corporais e hidratantes são descritos usando termos como "vitamina C", "retinol" ou "iluminador", nenhum dos quais se sobrepõe à consulta. Produtos que formam uma rotina completa de cuidados com a pele ficam espalhados pelo índice, sem nenhum token compartilhado para ancorá-los.

• "acessórios de viagem para pets": é um agrupamento de casos de uso, não uma categoria de produto. Um sling para cães, uma cadeirinha para pets e uma caixa de viagem são todos relevantes, mas as descrições falam sobre portabilidade, segurança e conforto, em vez de "acessórios de viagem". O BM25 corresponde amplamente a palavra "pet", mas não tem sinal para distinguir produtos específicos para viagens do restante do catálogo de pets.

Esse é um problema de recall. Os documentos relevantes existem no seu índice. O BM25 simplesmente não os encontra porque as palavras do usuário e as do documento não coincidem o suficiente.

Adicionar sinônimos ajuda em casos conhecidos. Mas não dá para enumerar todas as formas como o usuário pode expressar uma intenção. É aí que entram os vetores.

Por que medir o recall

Antes de corrigir um problema, você precisa quantificá-lo.

Recall@k mede quantos documentos que seus usuários realmente desejam aparecem nos resultados de busca. Formalmente:

Precision@k mede os k principais resultados e quantos são realmente relevantes:

Alta precisão mostra que os resultados que você retorna são bons. No comércio eletrônico, perder um produto relevante (baixo recall) geralmente é pior do que mostrar um resultado um pouco imperfeito (menor precisão), porque o produto oculto é venda perdida.

A API rank_eval do Elasticsearch permite medir os dois de forma sistemática. Você fornece uma lista de consultas, cada uma com um conjunto de documentos avaliados, e o Elasticsearch calcula as métricas para você em todas elas.

Configuração da avaliação

A API rank_eval precisa de um conjunto de dados de avaliações: um mapeamento das consultas para os documentos relevantes para cada um, junto com uma nota de relevância (0 = não relevante, 1 = relevante, 2 = altamente relevante).

No bloco de notas, esta é a lista de julgamentos:

A combinação é intencional: q1 é uma consulta que o BM25 lida bem (tokens exatos nos títulos dos produtos), enquanto q2, q3 e q4 são consultas orientadas à intenção, nas quais a intenção do usuário é expressa como um conceito, não como palavras-chave específicas de produto.

Medindo o recall de base do BM25

Primeiro, configure o cliente do Elasticsearch e indexe os dados de texto bruto:

Agora, crie a solicitação rank_eval para o BM25. Cada solicitação na lista combina uma consulta com as classificações correspondentes:

Resultado:

0.43 significa que, em todas as quatro consultas, o BM25 encontra apenas 43% dos documentos que deveria. A deficiência se concentra nas consultas baseadas na intenção: "rotina de cuidados com a pele" não inclui séruns faciais e óleos corporais, pois "rotina" nunca aparece nos títulos dos produtos. Já "acessórios de viagem para pets" retorna produtos para pets fora do tópico, enquanto não inclui transportadoras e caixas de transporte descritas em termos de portabilidade e segurança, em vez de "acessórios de viagem".

Esta é a nossa linha de base. Agora, temos um número a superar.

Adicionando busca vetorial com embeddings do Jina

Vector search codifica documentos e consultas como vetores de alta dimensão, tipo de vetor composto por centenas ou milhares de valores numéricos, cada um codificando um recurso específico dos dados que representa. Documentos com significado semelhante acabam próximos uns dos outros no espaço vetorial, mesmo que não compartilhem palavras. "Equipamento de ginástica" e "conjunto de halteres" ficam próximos porque os conceitos estão relacionados. Escolhi o Elasticsearch como meu banco de dados vetorial porque ele faz busca híbrida, oferecendo compreensão semântica e precisão de palavras-chave prontas para uso.

EIS inclui suporte pronto para uso de modelos via API de inferência.

Passo 1: usando embeddings Jina v5 como endpoint de inferência

Se seu cluster tem recursos de GPU (disponíveis no Elastic Cloud e Elasticsearch 9.3+), as incorporações são geradas na GPU, o que é bem mais rápido do que a inferência da CPU e elimina o tradeoff de desempenho que historicamente encarecia os vetores em larga escala.

Por que as incorporações Jina especificamente? jina-embeddings-v5-text é um modelo multilíngue (mais de 119 idiomas) com uma janela de contexto de 32 mil tokens e suporte para adaptadores de Adaptação de Baixa Ordem (LoRA) específicos para cada tarefa. Ele funciona bem para descrições curtas de produtos, prontamente utilizável. Saiba mais sobre o modelo jina-embeddings-v5-text aqui.

Passo 2: criar o índice com um campo semântico

O tipo de campo semantic_text é essencial aqui. É uma abstração de nível mais alto sobre dense_vector: você aponta para um endpoint de inferência, e o Elasticsearch cuida de gerar automaticamente os embeddings.

A propriedade copy_to em title e description significa que o conteúdo de ambos os campos flui para semantic_field para incorporação, de modo que um único vetor captura a representação completa do produto.

Passo 3: indexar os produtos

No momento do índice, o Elasticsearch chama o endpoint de inferência para cada documento e armazena a incorporação resultante em semantic_field. Sem código extra do seu lado.

Busca híbrida: combinando BM25 e vetores com RRF

Adicionar vetores melhora a recuperação, mas usar vetores sozinhos pode prejudicar a precisão em consultas de correspondência exata; "tênis de corrida" ainda deve priorizar correspondências exatas. A busca híbrida mantém o componente léxico especificamente para preservar essa precisão.

A busca híbrida com Fusão de Classificação Recíproca (RRF) mantém o melhor dos dois mundos:

• O BM25 lida com consultas exatas e quase exatas com alta precisão.

• A busca semântica processa consultas baseadas em intenção e multilíngues com alta precisão.

• O RRF combina as duas listas classificadas em uma única classificação.

A fórmula RRF atribui a cada documento uma pontuação baseada em sua classificação em cada lista de resultados:

Um documento bem classificado em ambas as listas recebe uma pontuação combinada maior. O rank_constant controla quanto peso documentos de menor classificação recebem.

Resultado:

O Hybrid melhora substancialmente em relação ao BM25 (0.43) e preserva a precisão para consultas de correspondência exata como "tênis de corrida".

Resultados: Antes e depois

Eis a comparação completa entre as três abordagens:

Resultado:

Método

Recall@10

BM25 (Léxico)

0,43

Híbrido (BM25 + Vetores)

0,75

Analisando por consulta:

Conclusão

Ao longo deste artigo, vimos que a busca léxica do BM25 é confiável quando os usuários digitam consultas exatas, mas perde a capacidade de recuperação quando buscam por intenção em vez de palavras-chave. Usando rank_eval, estabelecemos uma linha base reprodutível para medir essa lacuna com números reais. A partir daí, adicionamos um campo semantic_text alimentado por embeddings Jina e rodamos a avaliação novamente. O resultado: a buscar híbrida melhorou a capacidade de recuperação de 0.43 para 0.75 enquanto preservava a precisão nas consultas de correspondência exata, embora a margem real dependa da sua mistura de consultas.

O padrão se estende além deste exemplo: colete julgamentos das consultas reais de seus usuários, execute rank_eval como linha de base, adicione semantic_text e meça novamente. Você saberá exatamente o que melhorou e em quanto.

Próximas etapas

• Aprofunde-se no recall e na busca vetorial: quantização de busca vetorial e recall, de Jeff Vestal

• Adicione o reranking para melhorar ainda mais a precisão nos resultados principais

• Consulte a documentação de busca híbrida do Elasticsearch

• Leia mais sobre a rank_eval API

Como construímos o Elasticsearch com simdvec

Toda consulta de busca vetorial no Elasticsearch, seja por meio de percurso Hierarchical Navigable Small World (HNSW), varredura de arquivo invertido (IVF) ou reclassificação, se resume ao mesmo problema: calcular as distâncias entre vetores, milhões de vezes por consulta. O Elasticsearch é compatível com uma ampla variedade de tipos de dados e estratégias de quantização, desde float32 até int8, bfloat16, binário e Quantização Binária Aprimorada (BBQ). Cada uma traz diferentes contrapartidas entre memória, taxa de transferência e recuperação. Por trás de tudo isso há um único mecanismo: simdvec.

Criamos o simdvec para tornar cada cálculo de distância o mais rápido que o hardware permite. Neste post, explicamos por que o criamos, o que está dentro e onde ele entrega o maior impacto.

Construído como um carro de corrida

Como entusiastas da Fórmula 1, e um de nós tendo trabalhado anteriormente com a equipe Ferrari de Fórmula 1, vemos um paralelo claro. Um carro de Fórmula 1 é projetado com um único propósito: alcançar o melhor tempo de volta. Potência do motor, aerodinâmica e design do chassi só importam na medida em que contribuem para esse resultado. O mesmo vale para um banco de dados vetorial, onde a taxa de transferência de indexação, a latência de consulta e o recall definem o sucesso.

Embora o resultado final seja o que importa, alcançar os mais altos níveis de desempenho exige que cada componente esteja no estado ideal. Não pode ser só bom o suficiente, tem que ser o melhor na categoria. O Simdvec foi construído com essa mentalidade, focando uma parte crítica do sistema: o mecanismo. Trata-se de uma biblioteca de kernel otimizada para SIMD (Single Instruction Multiple Data), criada especificamente para fornecer funções de distância nativas em C++ ajustadas manualmente, chamadas a partir do Java via interface de função estrangeira (FFI) Panama. Ele trabalha com pontuação em lote, pré-busca de linhas de cache e todos os tipos e layouts vetoriais usados no Elasticsearch.

Esse é o mecanismo por trás de cada consulta.

Por que criamos nosso

Começamos em 2023 com a Panama Vector API no Apache Lucene. Funcionou bem para produtos dot float32, mas as necessidades do Elasticsearch logo superaram o que ele podia oferecer. O Elasticsearch é compatível com uma ampla variedade de tipos de vetores quantizados: int8, int4, bfloat16, bit único e BBQ assimétrico. Cada um possui estratégias SIMD diferentes, layouts de empacotamento e requisitos de acumuladores. Além da cobertura de tipos, os caminhos de pontuação do Elasticsearch exigem mais do que a taxa de transferência de pares únicos: o HNSW precisa pontuar vários vizinhos do gráfico em uma única passagem, o IVF precisa da pontuação em lote de milhares de candidatos com pré-busca e a pontuação baseada em disco precisa funcionar diretamente na memória mapeada em memória (mmap) sem cópia. Vimos o que estava disponível e nada abrangia o conjunto completo.

Então, criamos o simdvec: kernels C++ nativos ajustados manualmente, chamados de Java via FFI, com pontuação em massa, pré-busca e suporte para cada tipo de vetor que o Elasticsearch usa. Ao possuir a biblioteca, controlamos toda a stack. Quando adicionamos um novo tipo de quantização como BBQ, ele recebe um kernel SIMD ajustado ligado por todo o sistema. Não esperamos uma biblioteca upstream para suportá-lo e não comprometemos o desempenho de nenhum tipo. Toda consulta vetorial no Elasticsearch, seja HNSW, IVF, de reclassificação ou híbrida, pode ser executada nesse mecanismo, construído em torno das operações e tipos que realmente usamos.

O Simdvec possui bibliotecas nativas separadas para x86 e ARM, cada uma com múltiplos níveis de arquitetura de conjunto de instruções (ISA) selecionados no início. A sobrecarga de chamadas do Java via FFI é muito baixa, com nanossegundos de um dígito.

O cenário

Não somos os únicos a construir kernels de distância vetorial otimizados para SIMD. O ecossistema é rico, e queríamos entender como o simdvec funciona. Não para classificar projetos, mas para fornecer contexto e explicar onde o mecanismo do Elasticsearch está localizado. Selecionamos três projetos como pontos de referência, cada um representando uma abordagem diferente:

• jvector: uma biblioteca Java de busca aproximada de vizinhos mais próximos (ANN) que usa a Panama Vector API para cálculo vetorizado de distância, com aceleração nativa em C opcional no x86.

• FAISS: um framework de busca vetorial open source amplamente utilizada, com kernels AVX2/AVX-512 otimizados manualmente.

• NumKong (anteriormente SimSIMD): um conjunto abrangente de mais de 2.000 kernels SIMD ajustados manualmente, abrangendo funções de distância, operações matriciais e computação geoespacial.

Cada projeto tem um propósito diferente e realiza diferentes compensações. Incluímos números de referência deles para dar contexto sobre o desempenho do simdvec nas operações específicas que o Elasticsearch precisa.

Como medimos

Os benchmarks simdvec e jvector são escritos em Java com o JMH, o conjunto padrão de microbenchmark da JVM, com a sobrecarga de FFI incluída. Para os benchmarks NumKong e FAISS, criamos programas em C/C++ reduzidos usando o Google Benchmark, que é a estrutura padrão de microbenchmarks em C++. Ambos os frameworks reportam nanossegundos por operação com calibração de aquecimento e iteração. Verificamos por meio de contadores de desempenho de hardware que todas as bibliotecas estão usando SIMD em ambas as plataformas. Todo o código do benchmark está disponível publicamente nos repositórios vinculados do GitHub (e, no caso do simdvec, no repositório elasticsearch).

Software: JDK 25.0.2, JMH 1.37, GCC 14, Google Benchmark (a versão mais recente).

Um vetor de cada vez

A operação mais fundamental na busca vetorial é calcular a distância entre dois vetores. Cada avaliação de vizinho HNSW, cada pontuação de candidata a IVF, cada comparação de reclassificação se reduz a esse ciclo interno.

Medimos a taxa de transferência de pares individuais em 1024 dimensões em ambas as plataformas, começando com float32, o tipo de referência e aquele em que o ecossistema é mais competitivo. Comparamos simdvec com FAISS e jvector; excluímos o NumKong porque ele usa acumuladores float64 para float32, tornando-o 3,2x-5,3x mais lento (dependendo da plataforma), priorizando precisão numérica em vez de throughput. Para manter a comparação comparável, comparamos o NumKong no int8, onde ele usa a mesma estratégia de acumulador do simdvec.

No x86, o FAISS AVX-512 é o kernel de par único mais rápido, com 23 ns. O Simdvec AVX-512 segue a 28 ns, uma lacuna que reflete a sobrecarga de chamadas FFI. Ambos usam FMA de 512 bits com desenrolamento de multi-acumuladores. No nível AVX2, os dois são muito mais próximos, 36 ns e 39 ns respectivamente, ambos limitados pela largura de carga de registrador e memória de 256 bits. O jvector é executado em 44 ns usando a API Java Panama Vector. O Panama gera um bom código SIMD, mas os intrínsecos do C++ ajustados manualmente mantêm uma vantagem.

No ARM, o simdvec lidera com 70 ns, bem à frente do jvector com 110 ns e do FAISS com 156 ns. O Simdvec tem kernels NEON ajustados manualmente para aarch64. O Jvector não tem código ARM nativo e depende do Panama. O FAISS depende da autovetorização do compilador em vez de intrínsecos explícitos do NEON, o que explica a lacuna maior. Isso reflete uma vantagem prática de ter a biblioteca do kernel: quando o Elasticsearch expandiu para o Graviton, adicionamos kernels NEON construídos especificamente para isso. Nem o jvector, nem o FAISS priorizaram código nativo ARM na mesma medida.

Mas o Elasticsearch não pontua apenas em float32. A quantização Int8 reduz a memória em 4x, bfloat16 em 2x e BBQ em 32x. Cada tipo precisa de sua própria estratégia SIMD, e o simdvec fornece kernels nativos ajustados manualmente para todos eles.

Das bibliotecas que comparamos, apenas a NumKong tem kernels comparáveis para int8. Medimos o produto escalar int8, euclidiano ao quadrado e cosseno em 1.024 dimensões.

Pontuação Int8 par único (1024 dimensões, ns/vec op – quanto menor, melhor)

Em ambas as arquiteturas, o NumKong é igual ou mais rápido em dimensões pequenas a médias, onde a diferença se deve em grande parte à menor sobrecarga de chamadas (chamada direta em C vs Java FFI). Em dimensões maiores, o simdvec alcança o desempenho do kernel, onde a implementação mais eficiente (que usa desenrolamento em cascata) amortiza o custo da chamada: conforme a dimensão aumenta, essa diferença diminui e eventualmente se inverte. O crossover está em dimensões entre 768 e 1.536, dependendo da função e arquitetura.

Apesar da sobrecarga ligeiramente maior do Java FFI, o simdvec está no mesmo nível das bibliotecas altamente otimizadas em C/C++. Além de ser a única biblioteca com kernels otimizados tanto para float32 quanto para int8, também lidera em ARM e fica apenas um pouco atrás de FAISS em x86 (para float32), e muito próxima de NumKong em ambas as arquiteturas (para int8). E, para bfloat16, int4, binário e BBQ, embora existam alternativas, o simdvec se destaca graças ao SIMD ajustado manualmente, adaptado ao layout de dados de cada tipo.

Mas um mecanismo de busca de produção não pontua um vetor de cada vez; ele marca milhares por consulta. A próxima pergunta é o que acontece nessa escala.

Milhares de uma só vez

O desempenho de um único par é apenas parte do panorama. O que importa na prática é como os sistemas se comportam sob carga. Uma única consulta HNSW pode pontuar centenas de vizinhos do gráfico. Uma varredura de IVF pode pontuar milhares de entradas da lista de postagens. Uma passagem de reclassificação pode pontuar dezenas de milhares de candidatos. A taxa de transferência de pares individuais é importante, mas o que importa ainda mais é a rapidez com que você consegue pontuar vários vetores e a suavidade com que o desempenho se degrada à medida que o conjunto de trabalho transborda dos caches da CPU.

O Simdvec fornece pontuação em lote para todos os tipos de dados. Esses não são apenas loops sobre kernels de par único; eles usam loops internos multiacumuladores que carregam o vetor de consulta uma vez por passo dimensional e o compartilham entre múltiplos vetores de documentos, com pré-busca explícita de linha de cache para o lote seguinte. Nem jvector, nem FAISS oferecem algo equivalente (no momento em que escrevo). O Jvector não tem bulk API, então os chamadores marcam um par por vez em um loop. O FAISS expõe fvec_inner_products_ny, que, no momento da escrita, é implementado como um ciclo sobre a função de distância de par único, sem amortização de consulta ou pré-busca.

Float32. Para medir o impacto no nível do kernel, avaliamos uma única consulta contra números crescentes de vetores de documento float32 de 1.024 dimensões, usando padrões de acesso aleatório que simulam buscas de vizinhos de gráficos dispersos semelhantes ao HNSW. Os três tamanhos de conjunto de dados, 32, 625 e 32.500 vetores, são escolhidos para que o conjunto de trabalho exceda o cache L1, L2 e L3, respectivamente.

Quando os dados cabem no cache, o simdvec é o mais rápido em ambas as plataformas, mas as margens são modestas, já que a aritmética do kernel predomina. A verdadeira separação surge à medida que o conjunto de trabalho cresce além do nível L3. Em x86, o simdvec atinge 95 ns por vetor, enquanto o FAISS precisa de 165 ns e o jvector, de 412 ns. Em ARM, o padrão é o mesmo: o simdvec se mantém em 162 ns, enquanto o FAISS sobe para 347 ns e o jvector para 476 ns. A pré-busca e a amortização de consultas no simdvec mantêm a latência de memória oculta de uma forma que um simples loop sobre kernels de par único não consegue igualar, e a vantagem se amplia precisamente onde as cargas de trabalho de busca reais operam, nas profundezas da memória principal.

Int8. O mesmo padrão se aplica aos tipos quantizados. Medimos a pontuação em lote do produto escalar int8 em 1.024 dimensões, com tamanhos de conjuntos de dados escolhidos para exceder os mesmos limites do cache L1, L2 e L3, comparando a pontuação em lote do simdvec com a pontuação de par único do NumKong em um ciclo.

No x86, o simdvec é de 1,2x a 1,9x mais rápido, impulsionado pela combinação de pré-busca explícita e processamento em lote. No ARM, o simdvec vence novamente (1,7x a 1,9x mais rápido) em todos os tamanhos de conjuntos de dados. A vantagem vem do processamento em lote de quatro vetores por vez, oferecendo paralelismo em nível de memória por meio de um padrão de acesso intercalado. Em ambos os casos, o resultado mais impressionante é o que ocorre no maior tamanho de conjunto de dados, onde mais importa.

Os resultados para distância ao quadrado e cosseno mostram um padrão semelhante, com acelerações de 1,4x a 1,8x para ARM e de 1,3x a 3,0x para x86 (detalhes aqui).

Quando a memória é o mais importante

Índices vetoriais de produção normalmente não cabem no cache da CPU. Um índice int8 de 10 milhões de vetores, com 1.024 dimensões, tem 10 GB. Pontuar candidatos significa fazer streaming de dados a partir da DRAM e é aí que a arquitetura de pontuação em lote faz a diferença.

Usamos contadores de desempenho de hardware para medir o que acontece dentro da CPU durante a pontuação em lote e descobrimos que ocultar a latência de memória exige duas estratégias fundamentalmente diferentes, uma por arquitetura.

No x86, a pré-busca explícita elimina os erros de cache. O kernel em massa processa os vetores sequencialmente, um totalmente computado antes do próximo, enquanto emite instruções de pré-busca para o próximo lote. Os dados futuros são puxados para L1 antes que a CPU precise deles.

Em ARM, a mesma abordagem sequencial teve desempenho ruim, mesmo com prefetching. Em vez disso, o kernel bulk intercala leituras de quatro vetores em cada posição do stride, dando ao mecanismo de execução fora de ordem quatro fluxos de memória independentes. A CPU não está buscando dados mais rápido, mas sim esperando menos, porque sempre há outra coisa para calcular enquanto as requisições de memória estão em voo. Você pode encontrar uma análise detalhada nesta edição do GitHub.

Os números contam duas histórias diferentes:

1. Em x86, a pré-busca transforma 139K erros de cache em 19K, e as instruções por ciclo (IPC) mais que dobram. A grande vantagem aumenta com o tamanho do conjunto de dados, de 1,2x em L2 para 2,8x além de L3, porque a pré-busca oculta viagens de ida e volta de DRAM cada vez mais caras.

2. No ARM, as falhas de cache mal mudam. O que muda é o uso: as estagnações de backend caem 40% porque o padrão de acesso intercalado mantém o pipeline alimentado. Essa vantagem se mantém consistente em 1,8x, independentemente do tamanho do conjunto de dados, porque o paralelismo no nível da memória se aplica independentemente de os dados virem do cache ou da DRAM.

Duas arquiteturas, duas estratégias, um resultado: em escala de produção, o simdvec mantém o pipeline da CPU ocupado mesmo quando os vetores estão espalhados pela memória principal.

O que isso significa para os usuários do Elasticsearch

Essas capacidades em nível de kernel se acumulam. Uma única consulta vetorial pode calcular milhões de operações de distância: percurso de gráficos HNSW, pontuação de candidatos, reclassificação. Ao longo de milhares de consultas concorrentes, nanossegundos por operação se traduzem diretamente em latência de consulta e transferência do cluster. Seja usando float32, int8, bfloat16 ou BBQ, seja seu índice na memória ou no disco, simdvec é o motor por baixo, e cada uma dessas operações executa pelo mesmo motor, ajustado até o último nanosegundo.

A principal conclusão é que, em escala de produção, o desempenho da busca vetorial não é determinado principalmente pela taxa de transferência SIMD bruta. Ele é dominado pela eficiência com que o sistema oculta a latência da memória e, ao mesmo tempo, mantém a computação em milhões de pequenas operações.

Os kernels simdvec são aprimorados em quase todas as versões do Elasticsearch. Quando surgem novos tipos de quantização e plataformas de hardware, eles recebem kernels ajustados desde o primeiro dia. E os tipos existentes continuam a ficar mais rápidos à medida que refinamos as implementações que já estão sendo lançadas.

As organizações acumulam grandes coleções de documentos, como chamados de suporte, processos judiciais, notícias, artigos de pesquisa, e precisam entender o que eles contêm antes de poderem fazer as perguntas certas. Sem rótulos nem dados de treinamento, revisar manualmente milhares de documentos é impraticável. A busca tradicional não ajuda quando você não sabe o que procurar.

Esta publicação tem uma abordagem nativa do Elasticsearch para clustering de documentos não supervisionados e rastreamento de histórias temporais que lida com esse problema de descoberta. Ao final, você poderá acompanhar arcos narrativos como este ao longo de vários dias:

O que você vai descobrir:

• Por que embeddings de clustering (e não embeddings de recuperação) são importantes quando se deseja descobrir tópicos sem uma consulta?

• Como a classificação de centroides sondada por densidade agrupa documentos por tópico usando Elasticsearch k-nearest neighbor (kNN) e processamento em lote msearch.

• Como significant_text pode automaticamente rotular clusters para que os temas sejam legíveis sem precisar treinar um modelo?

• Como as cadeias temporais de histórias conectam clusters diários para mostrar como os temas evoluem dia após dia.

O pipeline utiliza ~8.500 artigos de fevereiro de 2025 da BBC News e do The Guardian como um corpus de teste. As notícias são convenientes porque apresentam um comportamento temporal claro, mas esse padrão se aplica a qualquer situação em que a descoberta de documentos seja importante: revisão jurídica, monitoramento de conformidade, síntese de pesquisas, triagem de suporte ao cliente.

Stack:

• Jina v5 clustering embeddings: adaptadores LoRA (Low-Rank Adaptation) específicos para tarefas no agrupamento de tópicos. Jina ingressou na Elastic e os modelos estão disponíveis nativamente por meio do Elastic Inference Service (EIS).

• Elasticsearch: kNN escalável, rotulagem significant_text e armazenamento de vetores.

• DiskBBQ: um formato de índice vetorial baseado em disco que combina quantização binária aprimorada (BBQ) com particionamento hierárquico k-means para aceleração aproximada de vizinhos mais próximos (ANN). Essa partição de índice é interna à busca vetorial e separada do algoritmo de clustering baseado em densidade usado nesta postagem. bbq_disk armazena vetores quantizados em disco e mantém apenas metadados de partição no heap, reduzindo os requisitos de recursos, em comparação com bbq_hnsw, mantendo alta recuperação.

• Clustering global + vinculação temporal diária: descoberta e evolução da narrativa.

O que você precisará:

• Uma implementação do Elasticsearch (Elastic Cloud, Elasticsearch Serverless ou Elastic Self-Managed 8.18+/9.0+): bbq_disk requer a versão 8.18 ou posterior. A seção opcional do diversificador retriever exige 9.3+ ou serverless.

• Uma chave de API Jina: o nível gratuito inclui 10 milhões de tokens, o que cobre o pipeline principal de clusterização (aproximadamente 4,25 milhões de tokens). A comparação opcional entre recuperação e clustering usa uma segunda passagem de incorporação.

• Uma chave de API do Guardian (gratuita).

Configuração

Instale os pacotes necessários:

Opcional (somente se você executar ferramentas de scraping deste repositório):

Depois, configure chaves de API em um arquivo .env na raiz do projeto:

Este notebook chama load_dotenv(override=True), portanto os valores locais .env têm precedência.

Parte 1: clustering de descoberta – Por que fazer clustering de embeddings?

A maioria das buscas vetoriais utiliza embeddings de recuperação treinados para associar uma consulta a documentos relevantes. Isso é perfeito para buscas, mas não para descobertas. Quando você quer descobrir quais tópicos existem em um corpus sem qualquer consulta, precisa de embeddings que agrupem documentos semelhantes.

O Jina v5 resolve isso com adaptadores Low-Rank Adaptation (LoRA) específicos para cada tarefa. O LoRa adiciona pequenas atualizações de baixa classificação às camadas internas específicas, mantendo a maioria dos pesos do modelo base congelados, de modo que o comportamento do modelo se adapta a uma tarefa específica sem a necessidade de um novo treinamento completo. O mesmo modelo base produz embeddings diferentes dependendo do parâmetro task:

Tarefa

Preparado para

Caso de uso

retrieval.passage

Correspondência entre consulta e documento

Busca, retrieval augmented generation (RAG)

clustering

Agrupamento de tópicos (otimizado para clusters compactos)

Descoberta, categorização

O adaptador de clustering é treinado para aproximar documentos sobre o mesmo tópico no espaço de incorporação e distanciar documentos sobre tópicos diferentes. A comparação visual abaixo torna a diferença concreta.

Recuperação vs. clustering: uma comparação visual

Para ver a diferença, uma amostra de documentos recebe embedding de ambos os tipos de tarefa. O clustering é realizado no espaço de incorporação original de 1024 dimensões; a aproximação e projeção uniforme de variedades (UMAP) é usada apenas para projetar essas incorporações em 2D para visualização. A UMAP preserva a estrutura local de vizinhança, tornando-a útil para comparar a separação de clusters.

Abaixo, o mesmo exemplo de 480 documentos é incorporado com ambos os tipos de tarefas e projetado para 2D com UMAP. Procure grupos de cores mais fechados e separados no painel de clustering.

Os embeddings de recuperação (à esquerda) espalham amplamente os tópicos; os embeddings de clustering (à direita) produzem grupos mais coesos e separados a partir dos mesmos documentos.

Os embeddings de clustering produzem grupos mais compactos e visualmente distintos. Os embeddings de recuperação distribuem os tópicos de maneira mais uniforme, ideais para busca (similaridade refinada); mas, para descoberta, o que importa são os clusters temáticos compactos.

É por isso que o task="clustering" é usado no restante deste guia.

Carregando o conjunto de dados

O corpus combina duas fontes de notícias para fevereiro de 2025:

• BBC News através do conjunto de dados RealTimeData/bbc_news_alltime HuggingFace.

• The Guardian através da API da Guardian Open Platform.

Ter múltiplas fontes ajuda a validar se o clustering encontra tópicos em vez de estilos específicos de cada fonte.

Embedding com a tarefa de clustering

A API Jina v5 é chamada com task="clustering" para todos os documentos. Os embeddings são armazenados em cache no disco, portanto, as execuções subsequentes ignoram a API completamente.

A chamada da API é direta. O parâmetro task é a principal diferença em relação ao uso típico de embeddings:

O tempo abaixo reflete uma taxa de acerto do cache. A primeira execução contra a API demora mais, dependendo do tamanho do corpus.

Indexação em um único índice do Elasticsearch

Para clustering de descoberta, o mês inteiro é dedicado a um índice (docs-clustering-all). A partição diária vem depois para a ligação temporal da história.

O mapeamento do índice usa bbq_disk para o campo vetorial:

Um vetor float32 de dimensão 1024 tem 4 KB. bbq_disk utiliza k-means hierárquicos para particionar vetores em pequenos clusters, quantificá-los de forma binária e armazenar os vetores de precisão total no disco para repontuação. Apenas os metadados de partição permanecem no heap, então os requisitos de memória permanecem baixos mesmo para corpora grandes. Para cargas de trabalho que podem suportar mais heap, bbq_hnsw constrói um gráfico Hierarchical Navigable Small World (HNSW) para consultas mais rápidas com mais custo de recursos.

O tipo de campo dense_vector suporta múltiplas estratégias de quantização: bbq_disk e bbq_hnsw são os melhores ajustes para embeddings de alta dimensão como os vetores de dimensão 1024 usados aqui.

Clusteringo: classificação de centroides baseada em densidade

Algoritmos de clustering tradicionais, como o HDBSCAN, pressupõem que você possa manter a matriz vetorial completa de N×d na memória e executar atualizações de passagem completa repetidas. Para 8.495 documentos em 1024 dimensões, isso é administrável (aproximadamente 35 MB), mas a abordagem não é escalável para milhões de documentos sem infraestrutura adicional.

Este algoritmo é conceitualmente semelhante à inicialização do KMeans++ com atribuição de Voronoi e um nível de ruído, mas utiliza a busca kNN do Elasticsearch como primitiva de computação, mantendo quase todo o trabalho no lado do servidor:

1. Amostra de 5% de documentos como sondas de densidade (amostra aleatória, mínimo de 50).

2. Densidade da sonda por meio de lote msearch kNN. Cada sonda dispara uma consulta kNN e registra a semelhança média dos vizinhos. Alta similaridade média = região densa do espaço de embedding. msearch envia várias solicitações de pesquisa em uma única chamada HTTP, o que é fundamental aqui: a sondagem de densidade gera centenas de consultas kNN e processá-las em lote evita a sobrecarga por solicitação.

3. Selecione sementes de alta densidade com diversificação: os candidatos acima da densidade média são classificados por densidade decrescente e aceitos avidamente somente quando a semelhança de cosseno com cada semente existente estiver abaixo de um limite de separação. Este é o único processamento do lado do cliente (~0,01s para 8k documentos).

4. Classificar todos os documentos em relação aos centroides via msearch kNN: cada semente atua como um centroide; uma pesquisa kNN recupera documentos próximos acima de um limite de similaridade. Cada documento é atribuído ao centroide que o retornou com a maior pontuação. Pequenos clusters são dissolvidos em ruído.

O Elasticsearch cuida do trabalho pesado: msearch para sondas de densidade, msearch para classificação e significant_text para rotulagem. Para esse corpus (8.495 documentos), a amostra de sonda de densidade de 5% executa consultas de sonda de 425 kNN, que msearch agrupam lotes em nove chamadas HTTP (no tamanho de lote 50), evitando a sobrecarga de uma solicitação por sonda. Combinado com bbq_disk busca ANN, isso mantém a etapa de clustering rápida e escalável. As consultas kNN usam um valor mínimo de num_candidates para velocidade durante a passagem de clustering; consultas de busca em produção devem usar valores de num_candidates mais altos para melhorar a recordação, mas isso custa latência.

Clusters têm tamanhos naturais determinados pela densidade do espaço de embedding ao redor de cada centroide, não por um limite de k rígido. Regiões temáticas densas produzem clusters maiores; tópicos de nicho produzem agrupamentos menores.

Por que escolher KMeans ou HDBSCAN?

O algoritmo KMeans pressupõe clusters esféricos e requer a matriz completa N×d na memória. Para corpora que cabem na memória, HDBSCAN é uma excelente alternativa. Ele lida com formatos de cluster arbitrários e possui semântica de densidade bem compreendida.

A abordagem de centroide sondado por densidade mira em um nicho diferente: corpora onde você quer armazenamento, recuperação e clustering em um único sistema, ou onde a escala torna as operações matriciais do lado do cliente impraticáveis. Ele usa o Elasticsearch kNN como primitiva de computação, lida com tamanhos arbitrários de cluster e mantém quase toda a computação no lado do servidor.

Entendendo a taxa de ruído

A taxa de ruído de ~28% é intencional, não uma falha. Documentos que não cabem em nenhum cluster denso na similarity_threshold configurada ficam sem atribuição, em vez de serem forçados a uma correspondência ruim. Isso funciona como um filtro de qualidade: colunas de opinião, artigos curtos e reportagens isoladas naturalmente resistem ao clustering porque falta a densidade temática que define um grupo coerente.

O limiar é ajustável: reduzir similarity_threshold produz clusters mais abrangentes (mais documentos atribuídos, mas clusters menos coesos), enquanto aumentá-lo torna os clusters mais compactos e aumenta a fração de ruído. Para este corpus de conteúdo de notícias misto, ~30% de ruído é um ponto de operação razoável. Implantações em produção devem ajustar o limiar com base em critérios de qualidade específicos do domínio.

Rótulos automáticos com significant_text

Agora, cada cluster precisa de um rótulo de fácil compreensão. A agregação significant_text do Elasticsearch encontra termos que aparecem com frequência incomum em um conjunto em primeiro plano (o cluster) em comparação com um conjunto em segundo plano (o corpus completo).

Nos bastidores, ele usa uma heurística estatística (pontuação JLH por padrão) que equilibra mudanças de frequência absolutas e relativas, sem machine learning, sem chamadas de grandes modelo de linguagem (LLM). Um cluster sobre política do Reino Unido pode apresentar termos como starmer, labour, downing porque esses termos são desproporcionalmente comuns nesse cluster em comparação ao conjunto geral de notícias.

Para essa passagem global, os rótulos são calculados diretamente contra docs-clustering-all, então tanto o plano de frente quanto o plano de fundo são extraídos do mês inteiro. Na parte 2, a rotulagem utiliza o padrão de indexação diário (docs-clustering-*), um caractere curinga que permite que consultas abranjam todos os índices correspondentes simultaneamente, para dar significant_text um plano de fundo mais amplo e melhor contraste.

Um formato de consulta mínimo tem a seguinte aparência:

significant_text serve também como um filtro de qualidade: clusters que não produzem termos significativos não possuem vocabulário distintivo. São agrupamentos incoerentes que devem ser dissolvidos e reduzidos a ruído, em vez de receberem um rótulo enganoso.

Uma etapa de limpeza determinística e leve remove termos de rótulos irrelevantes (tokens numéricos, palavras genéricas) e recorre a um título representativo quando necessário. Isso mantém os rótulos nativos do Elasticsearch enquanto melhora a legibilidade.

Visualizando os clusters

As visualizações abaixo mostram o que a análise de clustering global descobriu: uma análise por data de documentos agrupados versus documentos de ruído, uma projeção UMAP para o mês inteiro e um gráfico de composição de fontes confirmando que os agrupamentos refletem tópicos em vez de fontes.

Distribuição diária de documentos agrupados versus ruídos ao longo de fevereiro de 2025.

Cada ilha colorida no UMAP representa um cluster: um grupo de artigos sobre o mesmo tema descobertos puramente por similaridade de incorporação. Os pontos de ruído cinza são artigos que não se encaixavam perfeitamente em nenhum cluster (artigos curtos, artigos de opinião ou histórias isoladas).

O gráfico de detalhamento da fonte confirma que os clusters contêm artigos de ambos BBC News e The Guardian. O clustering está encontrando tópicos, não fontes, exatamente o que a descoberta não supervisionada deve produzir.

Explorando a amplitude do cluster com o diversificador

O algoritmo kNN simples retorna os documentos mais semelhantes ao centroide de um cluster (o núcleo denso). Mas clusters reais abrangem subtópicos. O recuperador de diversificação usa a relevância marginal máxima (MMR) para destacar documentos que são relevantes para o centroide, mas também diferentes entre si.

O parâmetro chave é λ (lambda):

• λ = 1,0 → relevância pura (o mesmo que kNN simples).

• λ = 0,0 → diversidade pura (resultados de distribuição máxima).

• λ = 0,5 → equilibrado: relevante para o tópico, mas abordando diferentes perspectivas.

Uma forma mínima de solicitação de recuperador é assim:

Os parâmetros type, field, e query_vector são necessários no nível de diversificação: field informa à MMR qual campo dense_vector usar para similaridade entre resultados, e query_vector fornece o ponto de referência para a pontuação de relevância.

Isso permite que você responda: "O que esse cluster cobre de fato?" em vez de apenas "Qual é o ponto central?"

Os resultados simples kNN se agrupam em torno de um ângulo do tema: os documentos mais semelhantes ao centroide e entre si. O recurso de recuperação de diversidade revela diferentes facetas do mesmo cluster: subtópicos, fontes diversas e perspectivas variadas.

A métrica de diversidade confirma isso quantitativamente: a similaridade média entre pares é menor para os resultados do recuperador diversificado, o que significa que os documentos retornados abrangem um espectro mais amplo.

Isso é útil para você:

• Entender o que um cluster cobre, não apenas o centro, mas também as bordas.

• Geração de resumos. Documentos representativos diversos oferecem um material melhor para um LLM.

• Encontrar exemplos representativos para análise humana ou rotulagem posterior.

• Verificações de qualidade. Se os resultados diversos parecerem incoerentes, o cluster pode precisar ser dividido.

Parte 2: Cadeias de histórias temporais

Acompanhando histórias ao longo dos dias

A parte 1 fez o clustering de todo o mês global para descoberta de tópicos. Para o fluxo temporal, a mesma classificação de centroides sondados por densidade é executada independentemente por dia em índices diários, e depois os clusters são vinculados ao longo de dias consecutivos. Observe que os clusters diários são independentes dos clusters globais da parte 1; cada dia produz as próprias atribuições de agrupamento e rótulos ajustados ao conteúdo daquele dia.

A abordagem de vinculação: amostragem e consulta

Para cada cluster no dia A:

1. Você pode ver uma amostra de alguns documentos representativos.

2. Executar kNN contra o índice do dia B.

3. Conte quantos acessos caem em cada cluster B do dia.

4. Se a fração de acerto ultrapassar um limite (fração de kNN ≥ 0,4), registre um link.

Isso é rápido (apenas alguns documentos por cluster são consultados, nem todos) e usa o kNN nativo do Elasticsearch, sem necessidade de ferramentas externas.

Uma fração de kNN de 100% significa que todos os documentos mostrados do cluster de origem foram atribuídos ao mesmo cluster de destino, o vínculo mais forte possível entre os dias. A maioria dos links acima está relacionada ao futebol, o que faz sentido: a cobertura da Premier League é feita diariamente com alta consistência de tópicos.

O link score | operator | gedling → league | striker | season é um exemplo de um cluster de futebol local de nicho (Gedling é um clube fora da liga) sendo absorvido pelo cluster mais amplo da Premier League no dia seguinte, um efeito natural do clustering diário em diferentes granularidades.

Criar cadeias de histórias

Uma cadeia de histórias é uma sequência de clusters ligados ao longo de dias consecutivos.

Ligações pareadas individuais indicam que o cluster "política do Reino Unido" de segunda-feira está conectado ao de terça-feira. As cadeias revelam o arco completo: uma história que começa na segunda-feira, evolui durante a semana e encerra na sexta-feira.

As cadeias são construídas de forma ávida a partir de links com uma fração kNN ≥ 0,4, o que significa que pelo menos 40% dos documentos mostrados do cluster de origem chegaram a um único cluster de destino. A partir do cluster mais antigo, o algoritmo sempre segue o link de saída mais forte.

A rede mais longa acompanha a cobertura Ucrânia–Rússia por 19 dias consecutivos, o que não surpreende dada a intensidade geopolítica em fevereiro de 2025. O segundo mais longo acompanha o futebol da Premier League ao longo de 19 dias do mês. Cadeias mais curtas captam a temporada de premiações (filme/prêmios, seis dias), o rúgbi Six Nations (10 dias) e a cobertura da liderança política do Reino Unido (sete dias). Cada cadeia representa um arco narrativo que o algoritmo descobriu ao incorporar similaridade entre índices diários.

Sankey: Visualizando o fluxo da história

Um diagrama de Sankey é uma visualização de fluxo onde a largura da ligação representa a força da conexão. Aqui, cada faixa vertical representa um dia, cada nó é um cluster diário (dimensionado pela contagem de documentos), e cada caminho colorido traça uma cadeia de histórias ao longo do tempo. A largura do link codifica a força de sobreposição kNN: links mais espessos indicam que mais documentos mostrados caíram no cluster alvo. As cores são consistentes por cadeia, então um único caminho colorido da esquerda para a direita representa o progresso de uma história.

Por exemplo, a cadeia Ucrânia-Rússia (visível como um dos caminhos mais longos) flui continuamente desde o início de fevereiro até a terceira semana, com elos consistentemente espessos indicando forte continuidade temática ao longo dos dias.

Cadeias temporais de histórias que fluem ao longo de fevereiro de 2025. Cada caminho colorido representa uma história que persiste ao longo dos dias; com a largura indicando a força de sobreposição do kNN.

O que essa abordagem oferece

Esta análise abordou um pipeline completo de clustering de documentos não supervisionado construído no Elasticsearch:

1. Embeddings de clustering: os adaptadores específicos de tarefa do Jina v5 produzem embeddings otimizadas para agrupamento de tópicos, e não apenas para correspondência de consulta-documento.

2. Clustering de descoberta global: clustering o mês inteiro em um único índice maximiza a descoberta de tópicos ao longo dos dias.

3. Classificação de centroides com base na densidade: amostra 5%, sondar a densidade via msearch kNN, selecionar sementes diversas de alta densidade, classificar todos os documentos em relação aos centroides. O Elasticsearch cuida do processamento pesado; apenas a seleção de sementes executa do lado do cliente (~0,01s).

4. significant_text rotulagem: o teste de significância produz rótulos de cluster significativos sem qualquer modelo de ML ou anotação manual. Clusters que não produzem termos significativos são incoerentes e são rebaixados a ruído, uma porta de qualidade integrada.

5. Vinculação temporal de histórias: índices diários e kNN de índice cruzado entre amostra e consulta rastreiam como as histórias evoluem ao longo do tempo.

Principais conclusões:

• O tipo de tarefa de incorporação importa: embeddings de clustering produzem grupos tópicos mensuravelmente mais compactos.

• O Elasticsearch pode atuar tanto como camada de armazenamento quanto como motor de clustering por meio da busca kNN.

• A classificação de centroides baseada em densidade mantém quase toda a computação no lado do servidor e produz clusters com tamanhos naturais determinados pela densidade do espaço de incorporação.

• significant_text é rápido, compreensível e eficaz tanto para autorrotulagem quanto para controle de qualidade.

Quando essa abordagem é útil:

• Você tem texto com carimbo de data e hora e quer descobrir tópicos sem dados de treinamento rotulados.

• Você precisa de uma plataforma para armazenamento, busca vetorial, rotulagem e ligação temporal.

Extensões para explorar:

• Clustering por múltiplos períodos (semanal, pacotes mensais).

• Ingestão em tempo real com atribuição incremental de cluster.

• Resumos de cluster gerados pelo LLM usando os termos significant_text como sementes.

• Em escala maior, centroides KMeans mostrados podem servir como sementes de aquecimento para clustering baseado em densidade, reduzindo o custo da fase da sonda.

Experimente você mesmo

Troque seu próprio corpus de documentos com carimbo de data; qualquer coleção de texto com datas funciona com esse pipeline. O notebook completo e o código de suporte estão disponíveis no repositório complementar.

• Inicie uma avaliação gratuita do Elastic Cloud: instale um cluster gerenciado com suporte bbq_disk em questão de minutos.

• Experimente o Elasticsearch Serverless: sem gerenciamento de cluster, escala automática e com suporte.

O Elasticsearch estava rejeitando métricas de chegada tardia. Essas rejeições fizeram o pipeline ficar atrasado, resultando em dados mais tardios, o que desencadeou ainda mais rejeições. Com o tempo, o pipeline parou completamente.

Tivemos que restaurar a partir do snapshot, reindexar os dados e redesenhar o pipeline de ingestão para recuperar.

A causa raiz não era a gestão de ciclo de vida de índices (ILM) em si. Tratava-se de fluxos de dados de séries temporais (TSDS) e como eles aplicam índices de apoio com limite temporal.

O TSDS pode reduzir os requisitos de armazenamento para métricas em 40–70%, mas as mudanças na arquitetura que tornam o TSDS eficiente também alteram a forma como os índices se comportam ao longo do tempo. Essas mudanças são importantes ao projetar políticas de ILM ou quando seus pipelines de ingestão podem produzir dados tardios.

TL;DR

Ao usar o TSDS:

• Índices de suporte aceitam apenas documentos dentro de uma janela de tempo específica.

• Se dados tardios chegarem após um índice se tornar frio ou congelado, o Elasticsearch rejeitará esses documentos ou os encaminhará para o armazenamento de falhas, caso esteja configurado.

Regra de design:

O que é um fluxo de dados de séries temporais?

Um fluxo de dados de série temporal (TSDS) é um fluxo de dados especializado otimizado para dados métricos. Os dados são roteados de modo que documentos relacionados fiquem localizados dentro dos mesmos fragmentos, otimizando-os para consulta e recuperação. Como o Elasticsearch faz isso:

Cada documento contém:

• Um registro de data e hora.

• Campos dimensionais que identificam a série de tempo.

• Campos métricos representando valores medidos.

Alguns exemplos:

• Uso da CPU por host.

• Solicitar latência por serviço.

• Leituras de temperatura por sensor.

As dimensões identificam o que queremos medir, enquanto as métricas representam valores que mudam com o tempo.

Dimensões

Dimensões descrevem a entidade medida.

Exemplos:

Definimos eles em mapeamentos com:

Métricas

Métricas representam valores numéricos e são definidas usando:

Tipos comuns de métricas:

• Indicador: Valores que sobem e descem.

• Contador: valores que aumentam até serem reiniciados.

O Elastic Agent coleta principalmente métricas e dados de log. Mesmo que você não tenha habilitado manualmente nenhum índice TSDS, ainda pode tê-los no seu cluster.

O campo _tsid

O Elasticsearch gera internamente um valor _tsid a partir dos campos de dimensão. Isso permite que documentos com dimensões idênticas sejam roteados para o mesmo shard, melhorando:

• Compressão.

• Local da consulta.

• Desempenho de agregações.

A principal diferença: índices de apoio com prazo definido

Os fluxos de dados tradicionais sempre gravam no índice de suporte mais recente, chamado índice de gravação, mas o TSDS se comporta de maneira diferente.

Cada índice de apoio TSDS tem uma janela de tempo definida e aceita apenas documentos com @timestamp valores que se encaixam nessa janela:

Quando um documento é indexado, o Elasticsearch encaminha o documento para o índice de suporte responsável por aquele timestamp, o que significa que, ao contrário dos índices tradicionais, um TSDS pode gravar em vários índices de suporte simultaneamente.

Por exemplo:

• Dados em tempo real → índice mais recente.

• Dados tardios → índice anterior cobrindo esse intervalo de tempo.

Projetando para dados tardios

Os pipelines de ingestão reais raramente entregam métricas perfeitamente no prazo. As métricas podem ser atrasadas por interrupções de rede, acúmulos no caminho, ingestão em lote e perda de dispositivos de borda, que se reconectam e começam a recuperar o atraso.

Índices tradicionais absorvem silenciosamente esses atrasos. O TSDS não.

Se o carimbo de data/hora de um documento estiver fora da faixa de índices de apoio graváveis, o Elasticsearch o rejeitará, o que significa que sua política de ILM deve considerar os dados tardios.

A restrição crítica

Os índices de suporte precisam permanecer com permissão de escrita por tempo suficiente para receber dados com atraso.

Em termos práticos:

Como o ILM mede o tempo de existência a partir do rollover, a regra operacional passa a ser:

Por exemplo, se as métricas podem chegar até seis horas atrasadas, os índices devem permanecer graváveis pelo menos seis horas após o rollover.

Desconsiderar essa restrição foi exatamente o que causou a falha de ingestão descrita anteriormente. Os dados tardios eram direcionados para um índice anterior, que já estava na camada cold e, portanto, era bloqueado para escrita.

Tratamento de documentos rejeitados

Quando o TSDS rejeita um documento, o Elasticsearch retorna um erro, indicando que o carimbo de data e hora não está dentro da faixa de índices graváveis. Como seu pipeline de ingestão lida com esse erro determina se você perde dados ou trava a ingestão de dados.

O principal mecanismo para lidar com documentos rejeitados é o armazenamento de falhas.

Repositório de falhas (recomendado no Elasticsearch 9.1+)

O Elasticsearch 9.1 introduziu o armazenamento de falhas, que captura automaticamente documentos rejeitados. Em vez de retornar erros aos clientes, o Elasticsearch grava documentos rejeitados em um índice dedicado de falhas dentro do fluxo de dados.

Você pode inspecionar falhas usando:

O uso do armazenamento de falhas impede que os pipelines de ingestão travem devido a erros de rejeição, enquanto preserva os dados com falha para análise ou reindexação.

Monitoramento de questões de rejeição

Os problemas de chegada tardia geralmente aparecem primeiro como anomalias de ingestão. Você pode notá-los primeiro como:

• Quedas repentinas na taxa de indexação.

• Picos nos documentos rejeitados.

• Um número crescente de entradas de lojas que falham.

• Diferenças de incompatibilidade entre entradas e saídas do pipeline contagem.

Alertas nesses sinais permitem que os operadores detectem problemas antes que os pipelines parem. Fluxos de trabalho, trabalhos de Machine Learning e outros mecanismos podem ser usados para automatizar a detecção e notificação.

Lista de verificação de migração para TSDS + ILM

Se você estiver migrando um cluster de métricas para o TSDS, introduzindo a hierarquização do ILM ou atualizando para uma versão do Elasticsearch em que as métricas são TSDS por padrão, revise esses itens primeiro.

1. Medir a latência de ingestão

Antes de mudar as políticas de ILM, determine:

• Atraso normal na ingestão de dados.

• Pior caso de atraso durante os incidentes.

• Atrasos causados por pipelines em lote.

O projeto do seu ILM deve acomodar o máximo de atraso realista.

2. Verificar as janelas de tempo do índice

Inspecione seus índices de respaldo de TSDS:

Analise:

• time_series.start_time

• time_series.end_time

Esses limites determinam quais índices podem aceitar documentos. Entender essas janelas pode ajudar a determinar o quanto os dados podem estar atrasados antes de serem rejeitados.

3. Dimensione o nível hot para chegadas tardias

Garanta que os índices backing permaneçam graváveis por tempo suficiente para os dados tardios.

Regra operacional:

• warm_min_age > rollover_max_age + maximum_expected_lateness

Lembre-se, os índices devem permanecer graváveis por pelo menos seis horas se as métricas chegarem com seis horas de atraso.

4. Decida o que fazer com documentos rejeitados

Escolha uma estratégia antes de ativar o TSDS:

• Armazenamento de falhas (recomendado no Elasticsearch 9.1+).

• Fila de dead letter do Logstash.

• Índice de contingência para chegadas tardias.

• Aceitar a perda limitada de dados.

5. Monitorar a saúde da ingestão

Adicionar alertas para:

• A taxa de indexação cai.

• Documentos rejeitados.

• Crescimento do armazenamento de falhas.

• Desajustes de entrada/saída do pipeline.

Problemas de dados tardios geralmente aparecem primeiro como anomalias de ingestão.

Resumo

Fluxos de dados de séries temporais oferecem grandes melhorias de armazenamento e desempenho para cargas de trabalho de métricas, mas introduzem uma mudança arquitetônica importante: os índices de suporte têm limite temporal, o que afeta o comportamento do ILM.

Ao usar o TSDS:

• Os índices devem permanecer graváveis tempo suficiente para aceitar dados tardios.

• Os pipelines de ingestão devem lidar com documentos rejeitados com segurança.

A regra fundamental a lembrar é:

Se você projetar políticas de ILM em torno dessa restrição, o TSDS funcionará extremamente bem para cargas de trabalho de métricas.

Se ignorar isso, seu pipeline de ingestão pode descobrir esses limites de tempo da pior forma.

Sua primeira consulta

Comece definindo um objeto CLR simples (POCO) que mapeia para o seu índice Elasticsearch. Os nomes das propriedades são resolvidos para nomes de coluna ES|QL via atributos System.Text.Json padrão, como [JsonPropertyName], ou via JsonNamingPolicy configurado. As mesmas regras de serialização de origem que se aplicam ao restante do cliente também se aplicam aqui.

Com o tipo definido, uma consulta fica assim:

O provedor traduz isso para o seguinte ES|QL:

Há alguns detalhes a serem observados:

• Resolução do nome da propriedade: p.Price se torna price_usd por causa do atributo [JsonPropertyName], e p.Brand se torna brand seguindo a política de nomenclatura padrão camelCase.

• Captura de parâmetros: As variáveis C# minPrice e brand são capturadas como parâmetros nomeados (?minPrice, ?brand). Eles são enviados separadamente da string de consulta na carga JSON, o que evita injeções e permite o armazenamento em cache do plano de consulta no lado do servidor.

• Streaming: QueryAsync<T> retorna IAsyncEnumerable<T>. As linhas são materializadas uma de cada vez à medida que chegam do Elasticsearch.

Você também pode inspecionar a consulta gerada e seus parâmetros sem executá-la:

Como funciona? Uma breve revisão sobre o LINQ

O mecanismo que torna possíveis os provedores LINQ é a distinção entre IEnumerable<T> e IQueryable<T>.

Quando você chama .Where(p => p.Price > 100) em um IEnumerable<T>, o lambda compila para um Func<Product, bool>, um delegado regular que o runtime executa em processo. Isto é LINQ-to-Objects.

Quando você chama o mesmo método em um IQueryable<T>, o compilador C# envolve o lambda em um Expression<Func<Product, bool>> em vez disso. Essa é uma estrutura de dados que representa a estrutura do código em vez de sua forma executável. A árvore de expressões pode ser inspecionada, analisada e traduzida para outra linguagem em tempo de execução.

A interface IQueryProvider é o ponto de extensão. Qualquer provedor pode implementar CreateQuery<T> e Execute<T> para traduzir essas árvores de expressão para um idioma de destino. O Entity Framework usa isso para emitir SQL. O provedor LINQ to ES|QL o usa para emitir ES|QL.

A árvore de expressões para a consulta acima fica assim:

Árvore de expressões para a consulta de exemplo.

A árvore é aninhada do avesso: Take envolve OrderByDescending, que envolve Where, que envolve From, que envolve a raiz EsqlQueryable<Product> constante. O predicado Where é ele próprio uma subárvore de BinaryExpression nós para os operadores &&, >= e ==, com folhas MemberExpression para acessos a propriedades e capturas de fechamento para as variáveis minPrice e brand. Essa é a estrutura de dados que o provedor percorre para produzir o ES|QL final.

Nos bastidores: O pipeline de tradução

O caminho de uma expressão LINQ até os resultados da consulta segue um pipeline de seis estágios:

Visão geral do pipeline de tradução.

1. Captura da árvore de expressão

Quando você encadeia .Where(), .OrderBy(), .Take() e outros operadores em um IQueryable<T>, a infraestrutura padrão do LINQ constrói uma árvore de expressões. EsqlQueryable<T> implementa IQueryable<T> e delega para EsqlQueryProvider.

2. Tradução

Quando a consulta é executada (enumerando, chamando ToList() ou usando await foreach)), o EsqlExpressionVisitor percorre a árvore de expressões de dentro para fora. Ele despacha cada chamada de método LINQ para um visitante especializado:

Visitante

Traduz

Para

WhereClauseVisitor

.Where(predicate)

Condição ONDE

SelectProjectionVisitor

.Select(selector)

EVAL + KEEP + RENOMEAR

GroupByVisitor

.GroupBy().Select()

ESTATÍSTICAS ... POR

OrderByVisitor

.OrderBy() / .ThenBy()

Campo SORT [ASC\|DESC]

EsqlFunctionTranslator

EsqlFunctions.*, Math.*, métodos de string

80+ funções ES|QL

Durante a tradução, as variáveis C# referenciadas em expressões são capturadas como parâmetros nomeados.

3. Modelo de consulta

Os visitantes não produzem diretamente as strings. Em vez disso, produzem QueryCommand objetos, uma representação intermediária imutável. Um FromCommand, um WhereCommand, um SortCommand, e um LimitCommand, cada um representando um comando de processamento ES|QL. Eles são coletados para um modelo EsqlQuery.

Modelo de consulta e padrão de comando.

Esse modelo intermediário é desacoplado tanto da árvore de expressão quanto do formato de saída. Ele pode ser inspecionado, interceptado (via IEsqlQueryInterceptor) ou modificado antes da formatação.

4. Formatação

EsqlFormatter visita cada QueryCommand em ordem e gera a string final do ES|QL. Cada comando se transforma em uma linha, separada pelo operador pipe (|), que o ES|QL utiliza para encadear comandos de processamento. Identificadores que contêm caracteres especiais são automaticamente escapados com backticks.

5. Execução

A string ES|QL formatada e os parâmetros capturados são enviados para o endpoint /_query do Elasticsearch no corpo da requisição, como JSON. A interface IEsqlQueryExecutor abstrai a camada de transporte, e é aí que a arquitetura de pacotes em camadas se aplica.

6. Materialização

EsqlResponseReader transmite a resposta JSON sem armazenar todo o conjunto de resultados na memória. Uma árvore ColumnLayout , pré-computada uma vez por consulta, mapeia ES|QL nomes de colunas (como address.street, address.city) para propriedades aninhadas do POCO. Cada linha é montada em uma instância T e gerada uma de cada vez via IEnumerable<T> ou IAsyncEnumerable<T>.

A arquitetura em camadas

A funcionalidade LINQ para ES|QL é dividida em três pacotes:

Arquitetura de pacotes. Elastic.Esql é o motor de tradução puro. Ele não tem dependência HTTP e contém os visitantes de expressões, o modelo de consulta, o formatador e o leitor de resposta. Você pode usá-lo de forma independente para criar e inspecionar consultas ES|QL sem nenhuma conexão com o Elasticsearch. Isso é útil para testes, logging de consultas ou para criar a sua camada de execução.

Elastic.Clients.Esql é um cliente ES|QL leve e independente. Ele adiciona a execução HTTP além de Elastic.Esql via Elastic.Transport. Se sua aplicação só precisa do ES|QL e nenhuma das outras APIs do Elasticsearch, essa é a opção de dependência mínima.

Elastic.Clients.Elasticsearch é o cliente completo do Elasticsearch .NET. Também se baseia em Elastic.Esql e expõe o provedor LINQ via espaço de nome client.Esql. Esse é o ponto de entrada recomendado para a maioria das aplicações.

Ambos os pacotes da camada de execução fornecem a própria implementação do IEsqlQueryExecutor, a interface estratégica que conecta tradução e transporte.

Todos os três pacotes são compatíveis com o Native AOT quando usados com um JsonSerializerContext gerado por fonte. Para as informações completas sobre o cliente, consulte a documentação do Native AOT.

Além do básico

O exemplo acima abordou filtragem, classificação e paginação. O provedor aceita um conjunto mais amplo de operações.

Agregações

GroupBy, combinado com funções agregadas em Select, traduz-se em ES|QL STATS ... BY:

Projeções

Select, com tipos anônimos gera os comandos EVAL, KEEP e RENAME:

Biblioteca repleta de funções

Mais de 80 funções ES|QL estão disponíveis via classe EsqlFunctions, cobrindo data/hora, string, matemática, IP, correspondência de padrões e pontuação. Métodos Math.* padrão e string.* também são traduzidos:

PESQUISAR ENTRAR

Consultas cruzadas de índice traduzem-se para ES|QL LOOKUP JOIN:

Acesso direto ao ES|QL bruto

Para recursos do ES|QL que ainda não são cobertos pelo provedor LINQ, você pode adicionar fragmentos brutos:

Consultas assíncronas do lado do servidor

Para consultas de longa duração, envie-as para processamento em segundo plano no servidor:

Consultas assíncronas do lado do servidor são úteis principalmente em consultas analíticas de longa duração/processamento de grandes conjuntos de dados que podem exceder os tempos-limite típicos, ou em ambientes sensíveis a tempo-limite com balanceadores de carga, gateways de API ou proxies que impõem tempos-limite de HTTP rigorosos. Consultas assíncronas evitam quedas de conexão ao separar o envio da obtenção dos resultados.

Para começar

LINQ to ES|QL está disponível a partir de:

• Elastic.Clients.Elasticsearch v9.3.4 (9.x branch)

• Elastic.Clients.Elasticsearch v8.19.18 (8.x branch)

Instale do NuGet:

dotnet add package Elastic.Clients.Elasticsearch

Os pontos de entrada estão em client.Esql:

Método

Returns

Caso de uso

Query<T>(...)

IEnumerable<T>

Execução síncrona

QueryAsync<T>(...)

IAsyncEnumerable<T>

Streaming assíncrono

CreateQuery<T>()

IEsqlQueryable<T>

Composição avançada e inspeção

SubmitAsyncQueryAsync<T>(...)

EsqlAsyncQuery<T>

Consultas de longa duração no servidor

Para obter a referência completa de recursos, incluindo opções de consulta, acesso a vários campos, objetos aninhados e tratamento de campos de vários valores, consulte a documentação do LINQ to ES|QL.

Conclusão

Do LINQ para ES|QL traz toda a expressividade do C# LINQ para a linguagem de consulta ES|QL do Elasticsearch, para que você escreva consultas componíveis e com tipagem forte sem precisar criar manualmente as strings de consulta. Com captura automática de parâmetros, materialização em streaming e arquitetura de pacotes em camadas que se adapta de traduções independentes ao cliente completo do Elasticsearch, ele se integra naturalmente a aplicações .NET de qualquer tamanho. Instale o cliente mais recente, direcione suas expressões LINQ para um índice e deixe o provedor cuidar do resto.

Para resolver isso, mecanismos de busca como o Elasticsearch utilizam duas estratégias principais de otimização:

1. Busca aproximada (mundo pequeno hierárquico navegável [HNSW]): em vez de analisar cada documento, construímos um grafo de navegação para acessar rapidamente a vizinhança provável da resposta.

2. Quantização: Compactamos os vetores (por exemplo, de floats de 32 bits para inteiros de 8 bits ou até mesmo valores binários de 1 bit) para reduzir o uso de memória e acelerar os cálculos.

Mas a otimização geralmente vem acompanhada de uma taxa: a precisão.

O medo é válido: "Se eu compactar meus dados e usar atalhos durante a busca, perderei os melhores resultados?" "Essa otimização degrada a relevância do meu mecanismo de busca?"

Para provar que a quantização do Elastic não degrada os resultados, criamos um ambiente de testes repetíveis usando o DBPedia-14 como conjunto de dados para calcular exatamente quanta precisão (especificamente, recall) sacrificamos em prol da velocidade ao usar as otimizações padrão do Elasticsearch.

Resumindo: é provavelmente muito menos do que você pensa. Confira o caderno aqui e teste você mesmo

As definições (para os não especialistas)

Antes de analisarmos o código, vamos definir alguns termos.

• Relevância versus recuperação: A relevância é subjetiva (encontrei informações úteis?). A recuperação é matemática. Se houver 10 documentos no banco de dados que correspondam perfeitamente à sua consulta, e o mecanismo de busca encontrar nove deles, sua recuperação será de 90% (ou 0,9).

• Busca exata (plana): às vezes chamada de método "força bruta". O mecanismo de busca analisa cada documento em um índice e calcula a distância.

  • Prós: recall perfeito de 100%.

  • Contras: computacionalmente caro e lento em larga escala.

• Busca aproximada (HNSW): O método do "atalho". O mecanismo de busca cria um HNSW gráfico e percorre o gráfico para encontrar os vizinhos mais próximos.

  • Prós: extremamente rápido e escalável.

  • Contras: Você pode perder um vizinho se a travessia do gráfico parar muito cedo.

O experimento: exato x aproximado

Para testar a recuperação, usamos o conjunto de dados DBPedia-14, um grande conjunto de dados de títulos e resumos em 14 classes de ontologia, muito usado para treinar e avaliar modelos de categorização de texto. Especificamente, vamos focar a categoria "Filme". Decidimos comparar as configurações otimizadas de produção com uma verdade matematicamente perfeita.

Neste experimento, estamos usando o modelo jina-embeddings-v5-text-small, um modelo multilíngue de última geração que lidera os benchmarks do setor de representação de textos. Escolhemos esse modelo porque ele define o padrão atual para embeddings de alto desempenho. Ao combinar a precisão de elite do Jina v5 com a quantização nativa do Elasticsearch, podemos demonstrar uma arquitetura de busca que é computacionalmente eficiente e sem prejudicar a qualidade da recuperação.

Configuramos um índice com mapeamento duplo. Ingerimos o mesmo texto em dois campos diferentes simultaneamente:

1. content.rawcom tipo: flat. Isso força o Elasticsearch a realizar uma varredura de força bruta dos vetores Float32 completos. Isso retorna resultados de correspondência exatos e será usado na nossa linha de base.

2. contentcom o tipo semantic_text. Com padrões usando HNSW + melhor quantização binária (BBQ). Esse é o padrão otimizado de produção para correspondência aproximada.

O teste Recall@10

Para nossa métrica, usamos o Recall@10.

Escolhemos 50 filmes aleatórios e executamos a mesma consulta nos dois campos.

• Se a busca exata (plana) indicar que os 10 principais vizinhos são IDs [1, 2, 3... 10], você pode usar a busca exata.

• E a busca aproximada (HNSW) retorna IDs [1, 2, 3... 9, 99].

• Encontramos corretamente nove dos 10 principais. A pontuação é 0,9.

Aqui está o mapeamento que usamos:

Os resultados: a "estagnação" do sucesso

Realizamos um teste de escala, recarregando todo o conjunto de dados e testando com tamanhos de índice de 1.000 a 40.000 documentos.

Veja o que aconteceu com a pontuação de recall:

Documentos

Recall@10 score

1.000

1.000 (100%)

5.000

0,998 (100%)

10.000

0,992 (99,4%)

20.000

0,999 (99,0%)

40.000

0.992 (98,8%)

Os resultados foram incrivelmente estáveis. Mesmo com o aumento da escala, a busca aproximada coincidiu com a busca exata por força bruta em mais de 99% dos casos.

Por que funcionou tão bem?

Você poderia esperar que comprimir vetores em valores binários prejudicasse mais a precisão do que isso. A razão para isso não ocorrer está em como o Elasticsearch lida com a recuperação.

A maioria dos modelos de embedding hoje gera vetores Float32, que são volumosos. Para deixar a busca eficiente, o Elasticsearch usa quantização para vetores de alta dimensionalidade. Especificamente, desde a versão 9.2, ele usa BBQ como padrão.

O BBQ usa um mecanismo de reclassificação:

1. Percurso: o mecanismo de busca utiliza os vetores comprimidos (quantizados) para percorrer rapidamente o gráfico HNSW. Como os vetores são pequenos, ele pode superamostrar com eficiência, reunindo uma lista maior de candidatos (p. ex., os 100 principais documentos aproximadamente semelhantes) sem penalidade no desempenho.

2. Reclassificação: com esses candidatos, ele recupera os valores de precisão total apenas para esses poucos documentos para calcular a classificação final e precisa.

Ele oferece o melhor dos dois mundos: rapidez na quantização para o trabalho pesado e precisão dos números de ponto flutuante para a classificação final.

Podemos fazer melhor?

É importante notar que os resultados aqui usam configurações padrão e uma amostra aleatória de dados. Pense nisso como um ponto de partida de alto desempenho. Embora o Jina v5 seja excelente, essas pontuações de recall não são garantia de que funcione em todos os conjuntos de dados. Cada coleta de dados tem as próprias peculiaridades e, embora você possa definitivamente ajustar ainda mais as coisas para ter ainda mais desempenho, deve sempre comparar seus dados específicos para saber seu limite.

Conclusão

Este é um teste em pequena escala. Mas o objetivo do exercício não é medir especificamente o modelo de embeddings nem o BBQ, e sim mostrar como medir facilmente o recall do seu conjunto de dados com o mínimo de configuração.

Se você quiser executar esse teste com seus próprios dados, pode conferir o notebook aqui e tentar você mesmo.

No HNSW, a busca prossegue expandindo iterativamente os nós candidatos no gráfico, mantendo um conjunto limitado de vizinhos mais próximos descobertos até então. Cada expansão tem um custo (operações vetoriais, acessos aleatórios ao disco, e mais), e o benefício marginal desse custo tende a diminuir conforme a busca avança.

Uma forma de otimizar a travessia de gráficos HNSW é parar de buscar quando a probabilidade marginal de encontrar novos vizinhos verdadeiros não aumenta. Por essa razão, no Elasticsearch 9.2 introduzimos um novo mecanismo de terminação antecipada. Isso interrompe o processo de busca quando visitar nós do gráfico não fornece vizinhos novos mais próximos suficientes, consecutivamente, por um número fixo de vezes.

Este artigo mostra como aprimoramos o mecanismo de terminação antecipada mencionado no HNSW para torná-lo mais adequado para diferentes conjuntos de dados e distribuições de dados.

Terminação antecipada no HNSW

No HNSW, a busca prossegue expandindo iterativamente os nós candidatos no gráfico de proximidade, mantendo um conjunto limitado de vizinhos mais próximos descobertos até então, até que tenha visitado todo o gráfico ou atenda a alguns critérios iniciais de parada.

Portanto, a terminação antecipada nem sempre é necessariamente uma otimização, faz parte do próprio algoritmo de busca. O momento em que decidimos parar determina o equilíbrio entre eficiência e recall. No Elasticsearch, já existem várias maneiras de uma consulta no HNSW terminar antecipadamente:

• Um número máximo fixo de nós é visitado.

• Um tempo limite fixo é atingido.

Embora simples e previsíveis, essas regras são em grande parte agnósticas em relação ao que a busca realmente está fazendo. Além disso, elas são usadas principalmente para garantir que a consulta seja concluída em um tempo razoável para o usuário final.

Em uma postagem anterior do blog, apresentamos o conceito de redundância no HNSW. Em resumo, cálculos redundantes ocorrem quando o HNSW continua a avaliar novos nós candidatos que não resultam em encontrar mais vizinhos mais próximos.

Paciência: Medindo progresso em vez de esforço

A noção de paciência reformula a terminação antecipada, focando no progresso em vez do esforço.

Em vez de perguntar:

"Quantos passos já demos?"

A nova pergunta passa a ser:

“Qual é a quantidade de computação que aceitamos desperdiçar até perdermos a esperança?”

Durante a busca HNSW, a exploração precoce normalmente produz melhorias de pico no conjunto de candidatos top-k. Durante as primeiras etapas da exploração do gráfico HNSW, o conjunto de vizinhos é continuamente atualizado à medida que o algoritmo continua descobrindo vizinhos cada vez mais próximos do vetor de consulta. Com o tempo, essas melhorias se tornam mais raras à medida que a busca converge. A terminação antecipada baseada em paciência monitora esse padrão e finaliza a busca assim que as melhorias cessarem por um período prolongado.

Na prática, ao visitar o gráfico HNSW, também calculamos a razão de saturação da fila ao pular entre os nós candidatos. Isso mede a porcentagem de vizinhos mais próximos que permaneceram inalterados ao visitar o nó mais recente do gráfico (ou o inverso do número de novos vizinhos introduzidos na última iteração). Quando essa proporção se torna grande demais para muitas iterações consecutivas, paramos de visitar o gráfico.

Conceitualmente, a paciência trata a busca HNSW como um processo de retornos decrescentes. Quando os retornos se estabilizam, continuar explorando o gráfico traz pouco benefício.

Esse enquadramento é poderoso porque vincula a interrupção diretamente a resultados observáveis, e não a limites fixos arbitrários.

A vantagem de usar essa técnica inteligente de terminação antecipada é que as explorações do gráfico HNSW tendem a visitar um número menor de nós gráficos, mantendo uma taxa de recall quase perfeita.

Para visualizar isso, podemos visualizar em um gráfico a quantidade de recall por nó visitado que obtivemos com a terminação antecipada baseada em paciência (rotulada como et=static), quando comparada ao comportamento padrão do HNSW (rotulado como et=no) em alguns conjuntos de dados, FinancialQA e Quora, e modelos, JinaV3 e E5-small.

Limiares estáticos e dinâmicas do HNSW

Na prática, no Elasticsearch, isso é implementado usando limites estáticos. Um limite refere-se ao limite de saturação, ou seja, a proporção de saturação que consideramos abaixo do ideal. O outro limite refere-se ao número de nós de gráfico consecutivos que permitimos serem visitados enquanto ainda mantêm uma saturação de fila abaixo do ideal: ou seja, o limiar de paciência.

Quando introduzimos essa estratégia de terminação antecipada no Elasticsearch 9.2, decidimos optar por padrões conservadores, de modo a preservar o recall o máximo possível, enquanto ainda obtemos ganhos em termos de latência e consumo de memória. Por esse motivo, definimos o limiar de saturação para 100% e o limiar de paciência para ser definido como 30% (limitado) do num_candidates na consulta KNN.

Em muitos cenários, essas configurações funcionaram bem; no entanto, duas consultas que solicitam o mesmo número de vizinhos podem ter comportamentos de convergência radicalmente diferentes. Algumas consultas encontram vizinhanças locais densas e saturam rapidamente; outras precisam percorrer caminhos longos e esparsos antes de encontrar candidatos competitivos. Este último mostrou-se o mais difícil de lidar de forma eficaz.

Como resultado, por vezes notamos:

• Exploração excessiva para consultas fáceis.

• Encerramento prematuro para consultas complexas.

Portanto, descobrimos que valores de limite fixos codificam suposições globais sobre convergência, enquanto poderíamos fazer com que o HNSW se adaptasse melhor a diferentes dinâmicas.

Tornando o HNSW adaptativo à terminação antecipada

A terminação antecipada adaptativa aborda esse problema de um ângulo diferente. Em vez de impor limiares de parada pré-definidos, o algoritmo infere quando parar a partir da própria dinâmica da busca.

Então, em vez de comparar a taxa de saturação da fila entre dois candidatos consecutivos, decidimos introduzir uma taxa de descoberta instantânea suavizada (quantos novos vizinhos foram introduzidos para uma consulta q,na última visita i) junto com a média móvel e o desvio padrão dessa taxa de descoberta durante a visita ao gráfico (usando o algoritmo de Welford). Essas estatísticas sobre a taxa de descoberta são calculadas por consulta, de modo que essas informações podem ser usadas para determinar diferentes níveis de paciência para cada consulta.

Os limites anteriormente estáticos se tornam adaptáveis às estatísticas da taxa de descoberta: o limite de saturação se torna a média contínua mais o desvio padrão; enquanto fazemos com que a paciência se adapte e redimensione inversamente com o desvio padrão.

As regras de saída antecipada permanecem as mesmas; a saturação ocorre quando a taxa de descoberta instantânea é menor que o limite de saturação adaptativa. A visita ao gráfico é interrompida se a saturação persistir por um número consecutivo de visitas candidatas maior que a paciência adaptativa.

Dessa forma, obtemos um comportamento que não depende do parâmetro num_candidates na consulta KNN (que pode estar sempre definido ou deixado como padrão, independentemente de sair cedo) e que se adapta melhor a cada consulta e distribuição vetorial de forma dinâmica.

O recall por nó visitado no FinancialQA e Quora com a estratégia adaptativa (rotulada como et=adaptive) apresenta um recall maior por nó visitado, quando comparado à estratégia estática (et=static) e ao comportamento padrão do HNSW (et=no).

A terminação antecipada adaptativa está ativada por padrão no Elasticsearch 9.3 para campos vetoriais densos HNSW (e pode ser desativada posteriormente por meio da mesma configuração no nível do índice).

Nossos benchmarks em um corpus de 20 milhões de documentos mostram que o Elasticsearch entrega uma taxa de transferência até 8 vezes maior que o OpenSearch para busca vetorial filtrada, além de alcançar um Recall@100 superior nas configurações que testamos. A engenharia de contexto depende de mais do que apenas uma recuperação vetorial rápida. As equipes também precisam de fortes controles de relevância, como busca e filtragem híbridas, simplicidade operacional e desempenho previsível, à medida que os fluxos de trabalho evoluem. Mas como os agentes geralmente executam loops de recuperação, raciocínio e recuperação várias vezes por solicitação, a latência de recuperação se torna um multiplicador, então as melhorias aqui se traduzem diretamente em melhor capacidade de resposta de ponta a ponta e menor custo.

Para engenharia de contexto, recuperação não é um passo único. Agentes e aplicativos executam repetidamente loops, como recuperar → raciocinar → recuperar, para refinar consultas, verificar fatos, reunir contexto fundamentado e concluir tarefas. Esse padrão é comum em fluxos de trabalho agentivos e Retrieval-Augmented Generation iterativa (RAG). Como a recuperação pode ser invocada muitas vezes por solicitação do usuário, ela adiciona atraso à resposta e/ou aumenta os custos de infraestrutura.

Por que o desempenho da busca vetorial é crítico?

Imagine um assistente de compras respondendo à pergunta: “Preciso de uma mochila de mão por menos de R$ 300 que comporte um laptop de 15 polegadas, seja resistente à água e possa chegar até sexta-feira.”

Em produção, o assistente raramente emite uma consulta vetorial e para. Ele executa um ciclo de recuperação para criar o contexto certo, e cada etapa normalmente é limitada por filtros, como disponibilidade, região, promessa de envio, regras de marca e elegibilidade de políticas.

Passo 1: Interprete a intenção e traduza para restrições.

O agente transforma a solicitação em filtros estruturados e uma consulta semântica, como:

• Filtros: em estoque, disponível para entrega no CEP do usuário, entrega até sexta-feira, preço abaixo de R$ 300, listagem válida

• Consulta vetorial: “Mochila de bordo resistente à água para notebook de 15 polegadas”

Passo 2: Recuperar candidatos e, em seguida, refinar.

Frequentemente, repete a recuperação com variações para evitar perder boas correspondências:

• "Mochila de viagem com compartimento para laptop"

• "Mochila urbana resistente à água 15 polegadas"

• "Mochila leve para cabine"

Cada consulta usa os mesmos filtros de elegibilidade, porque recuperar itens irrelevantes ou indisponíveis é contexto desperdiçado.

Passo 3: Expanda para confirmar detalhes e reduzir riscos.

O agente então recupera novamente para verificar os atributos-chave que afetam a resposta final:

• Texto sobre materiais e resistência à água

• Dimensões e ajuste do compartimento para laptop

• Política de devolução ou restrições de garantia

• Opções alternativas se o estoque estiver baixo

Isso é engenharia de contexto multietapas: recuperar, raciocinar, recuperar, montar.

Por que latência e recall importam para a engenharia de contexto

Essas interações podem envolver dezenas de chamadas de recuperação filtradas por sessão de usuário. Isso faz com que a latência por chamada seja um multiplicador direto no tempo de resposta de ponta a ponta, e o baixo recall força tentativas extras ou faz com que o agente perca itens elegíveis, degradando a qualidade da resposta.

Conclusão: em sistemas de engenharia de contexto, os vizinhos mais próximos aproximados (ANN) filtrados não são uma pesquisa única. É uma operação repetida sob restrições, portanto, o desempenho da busca vetorial aparece imediatamente em latência, taxa de transferência e custo, mesmo quando o modelo de linguagem de grande porte (LLM) é o componente mais visível.

Benchmark

Resultados

No gráfico 2, cada ponto representa uma configuração de teste. Os melhores resultados aparecem no canto superior esquerdo, o que significa maior recall com menor latência. Os resultados do Elasticsearch estão consistentemente mais próximos do canto superior esquerdo do que os do OpenSearch, indicando melhor velocidade e precisão sob as mesmas configurações de carga de trabalho.

Alguns insights importantes

• s_n_r_value: Abreviação de size_numCandidates_rescoreOversample (k e numCandidates=500 definidos como numCandidates nesses testes), por exemplo, 100_500_1 significa size=100, numCandidates=500 e k=500, rescore oversample=1

• Recall: Recall@100 medido para essa configuração

• Latência média (ms): latência média de ponta a ponta por consulta

• Taxa de transferência: consultas por segundo

• Recall (%): elevação relativa do recall do Elasticsearch x OpenSearch (Elasticsearch menos OpenSearch)/OpenSearch

• Latência Xs: a latência média do OpenSearch dividida pela latência média do Elasticsearch

• Throughput Xs: Throughput do Elasticsearch dividido pelo throughput do OpenSearch

Mecanismo

`s_n_r_value`

Recall

Latência Média (ms)

Taxa de transferência

Recall %

Latência Xs

Taxa de transferência Xs

Elasticsearch

100_250_1

0,7704

25

534,75

9,70%

2,28

1,91

OpenSearch

100_250_1

0,7023

57,08

279,58

Elasticsearch

100_500_1

0,8577

25,42

524,14

7,20%

2,4

2

OpenSearch

100_500_1

0,8001

60,9

262,12

Elasticsearch

100_750_1

0,8947

29,67

528,09

5,72%

2,25

2,21

OpenSearch

100_750_1

0,8463

66,76

239,11

Elasticsearch

100_1000_1

0,9156

29,65

534,5

4,66%

2,46

2,44

OpenSearch

100_1000_1

0,8748

72,88

219,01

Elasticsearch

100_1500_1

0,9386

31,84

497,3

3,38%

2,71

2,68

OpenSearch

100_1500_1

0,9079

86,16

185,4

Elasticsearch

100_2000_1

0,9507

34,69

457,2

2,57%

2,98

2,96

OpenSearch

100_2000_1

0,9269

103,36

154,55

Elasticsearch

100_2500_1

0,9582

37,9

418,43

1,99%

3,28

3,26

OpenSearch

100_2500_1

0,9395

124,29

128,53

Elasticsearch

100_3000_1

0,9636

41,86

379,4

1,62%

3,46

3,44

OpenSearch

100_3000_1

0,9482

144,67

110,34

Elasticsearch

100_4000_1

0,9705

50,28

316,21

1,06%

3,87

3,85

OpenSearch

100_4000_1

0,9603

194,36

82,22

Elasticsearch

100_5000_1

0,9749

58,77

270,91

0,73%

4,43

4,41

OpenSearch

100_5000_1

0,9678

260,33

61,38

Elasticsearch

100_6000_1

0,9781

66,75

238,59

0,52%

4,91

4,89

OpenSearch

100_6000_1

0,973

327,44

48,81

Elasticsearch

100_7000_1

0,9804

74,64

213,49

0,38%

5,28

5,27

OpenSearch

100_7000_1

0,9767

394,24

40,53

Elasticsearch

100_8000_1

0,9823

82,28

193,59

0,27%

6,86

6,83

OpenSearch

100_8000_1

0,9797

564,14

28,33

Elasticsearch

100_9000_1

0,9837

90,08

176,96

0,16%

7,63

7,61

OpenSearch

100_9000_1

0,9821

687,25

23,25

Elasticsearch

100_10000_1

0,9848

97,64

163,31

0,08%

8,38

8,36

OpenSearch

100_10000_1

0,984

818,64

19,53

Por exemplo, em 100_9000_1, o OpenSearch tem uma média de 687 milissegundos por recuperação contra 90 milissegundos no Elasticsearch, e em um ciclo de recuperação de 10 etapas, isso equivale a cerca de 10 x (687 - 90) = seis segundos de tempo adicional de espera.

Veja os resultados completos.

Metodologia

Usando Python para enviar as consultas e acompanhar o tempo de resposta e outras estatísticas, enviamos as seguintes consultas para os motores. Lembre-se de que o desempenho de qualquer mecanismo de busca vetorial depende de como você ajusta seus parâmetros principais: quantos candidatos considerar, quão agressivamente reclassificar e quanto contexto devolver. Essas configurações afetam diretamente tanto o recall (a probabilidade de encontrar a resposta certa) quanto a latência (a rapidez com que você obtém resultados).

Em nossos benchmarks, usamos as mesmas configurações de candidato, reclassificação e tamanho do resultado que você normalmente ajusta em um ciclo de recuperação orientado por agente, e medimos o desempenho do Elasticsearch sob essa carga de trabalho. Depois, executamos o OpenSearch com as mesmas configurações como referência.

OpenSearch

• "size": <RESULT_SIZE>: Número de resultados retornados ao cliente. Neste benchmark, o tamanho do resultado é 100 para calcular o Recall@100.

• "k": <NUMBER_OF_CANDIDATES>: O número de candidatos a vizinhos mais próximos.

• "ef_search": <NUMBER_OF_CANDIDATES>: O número de vetores a examinar.

• "oversample_factor": <OVERSAMPLE>: Quantos vetores candidatos são recuperados antes da reclassificação.

Elasticsearch

• "size": <RESULT_SIZE>: Número de resultados retornados ao cliente. Neste benchmark, o tamanho do resultado é 100 para calcular o Recall@100.

• "k": <NUMBER_OF_CANDIDATES>: Número de vizinhos mais próximos a retornar de cada shard.

• "num_candidates": <NUMBER_OF_CANDIDATES>: Número de candidatos a vizinhos mais próximos a serem considerados por shard durante a busca knn.

• "oversample": <OVERSAMPLE>: Quantos vetores candidatos são recuperados antes da reclassificação.

Exemplo

Knn consulta, (100_500_1), seria a seguinte:

OpenSearch

Elasticsearch

A configuração completa, juntamente com os scripts do Terraform, os manifestos do Kubernetes e o código de benchmark, está disponível neste repositório na pasta es-9.3-vs-os-3.5-vector-search.

Configuração do Cluster

Executamos nossos testes em seis servidores em nuvem e2-standard-16, cada um com 16 vCPUs e 64 GB de RAM. Em cada servidor, alocamos 15 vCPUs e 56 GB de RAM para cada pod Kubernetes executando o Node do mecanismo de busca, com 28 GB reservados para o heap da JVM.

Os clusters executavam Elasticsearch 9.3.0 e OpenSearch 3.5.0 (Lucene 10.3.2). Como ambos os sistemas usam a mesma versão do Lucene neste teste de desempenho, as diferenças de taxa de transferência e latência que observamos não podem ser atribuídas apenas ao Lucene, mas sim refletem diferenças na forma como cada mecanismo integra e executa a recuperação e reavaliação filtrada do algoritmo k-vizinhos mais próximos (kNN). Usamos um único índice com três shards principais e uma réplica (ou seja, 6 shards no total, 1 por nó).

Também usamos um servidor separado na mesma região para executar o cliente de benchmark e coletar estatísticas de tempo.

O conjunto de dados

Para este benchmark, usamos um catálogo em grande escala no estilo de comércio eletrônico com conjuntos de dados de 20 milhões de documentos, projetado para refletir a recuperação vetorial filtrada do mundo real em escala.

Cada documento representa um item do catálogo e inclui:

• Um embedding vetorial denso de 128 dimensões utilizado para recuperação aproximada de kNN.

• Campos de metadados estruturados usados para filtragem (por exemplo, validade e disponibilidade do item, além de outras restrições do catálogo), permitindo o padrão comum de produção de recuperar os vizinhos mais próximos, mas somente dentro de um subconjunto elegível.

Escolhemos este conjunto de dados porque ele captura o principal desafio de desempenho que observamos em sistemas agentivos e do tipo RAG em produção: a similaridade vetorial por si só não é suficiente, a recuperação é frequentemente limitada por filtros, e o sistema deve manter um alto índice de recall enquanto mantém a latência baixa sob essas restrições. Comparado a conjuntos de dados menores no estilo QA, um corpus de 20 milhões de documentos também reflete melhor a escala e a pressão dos candidatos que sistemas ANN filtrados enfrentam na prática.

Conclusão

Nas arquiteturas modernas de IA, especialmente aquelas construídas baseadas em engenharia de contexto, a velocidade da busca vetorial não é um pequeno detalhe de implementação. É um multiplicador. Quando agentes e fluxos de trabalho iteram por meio de recuperar → raciocinar → recuperar, o desempenho da recuperação molda diretamente a latência de ponta a ponta, a taxa de transferência e a qualidade do contexto inserido no modelo.

Em nossos benchmarks, o Elasticsearch consistentemente entregou um recall maior com menor latência do que o OpenSearch em cenários onde a correção depende de recuperar o documento correto, e não apenas de um vetor semelhante. Em um conjunto de dados controlado, a diferença é clara, e na produção esses ganhos se acumulam em grandes volumes de chamadas de recuperação, melhorando a capacidade de resposta, aumentando a margem de capacidade e reduzindo custos de infraestrutura.

Para ler mais

1. O que é engenharia de contexto?

2. A evolução da busca híbrida e da engenharia de contexto

3. O impacto da relevância na engenharia de contexto para agentes de IA

Resumo

Primeiro, vamos atualizá-lo. O Elasticsearch se estabeleceu como um poderoso banco de dados vetorial, oferecendo um rico conjunto de recursos e um forte desempenho para buscas por similaridade em larga escala. Com recursos como quantização escalar, Better Binary Quantization (BBQ), operações vetoriais SIMD e algoritmos mais eficientes em termos de disco, como DiskBBQ, ele já oferece opções eficientes e flexíveis para o gerenciamento de cargas de trabalho vetoriais.

Ao integrar o NVIDIA cuVS como um módulo chamável para tarefas de busca vetorial, buscamos entregar ganhos significativos no desempenho e eficiência da indexação vetorial para melhor suportar cargas de trabalho vetoriais em grande escala.

O desafio

Um dos maiores desafios na construção de um banco de dados vetorial de alto desempenho é a construção do índice vetorial - o gráfico HNSW. Rapidamente, a construção de índices se torna dominada por milhões ou até bilhões de operações aritméticas, à medida que cada vetor é comparado com muitos outros. Além disso, operações do ciclo de vida do índice, como compactação e fusões, podem aumentar ainda mais a sobrecarga total de processamento da indexação. À medida que os volumes de dados e os embeddings vetoriais associados crescem exponencialmente, GPUs de computação acelerada, construídas para paralelismo massivo e matemática de alto rendimento, estão idealmente posicionadas para lidar com essas cargas de trabalho.

Apresentando o plugin Elasticsearch-GPU

NVIDIA cuVS é uma biblioteca open source CUDA-X para busca vetorial acelerada por GPU e clustering de dados que permite a construção rápida de índices e recuperação de embeddings para cargas de trabalho de IA e recomendação.

O Elasticsearch utiliza o cuVS através do cuvs-java, uma biblioteca de open source desenvolvida pela comunidade e mantida pela NVIDIA. A biblioteca cuvs-java é leve e se baseia na API C do cuVS, utilizando a função estrangeira Panama para expor os recursos do cuVS de uma maneira idiomática em Java, mantendo-se moderna e eficiente.

A biblioteca cuvs-java está integrada a um novo plugin do Elasticsearch; portanto, a indexação na GPU pode ocorrer no mesmo node e processo do Elasticsearch, sem a necessidade de provisionar qualquer código ou hardware externo. Durante a criação do índice, se a biblioteca cuVS estiver instalada e uma GPU estiver presente e configurada, o Elasticsearch usará a GPU para acelerar o processo de indexação vetorial. Os vetores são fornecidos à GPU, que constrói um gráfico CAGRA. Esse gráfico é então convertido para o formato HNSW, tornando-o imediatamente disponível para busca vetorial na CPU. O formato final do gráfico construído é o mesmo que seria construído na CPU; isso permite que o Elasticsearch utilize GPUs para indexação de alto desempenho quando o hardware subjacente a suporta, liberando poder de processamento da CPU para outras tarefas (buscar, processamento de dados, etc.).

Aceleração de construção de índice

Como parte da integração da aceleração de GPU no Elasticsearch, várias melhorias foram feitas no cuvs-java, focando na entrada/saída eficiente de dados e na invocação de funções. Uma melhoria importante é o uso de cuVSMatrix para modelar vetores de forma transparente, independentemente de estarem na heap do Java, fora da heap ou na memória da GPU. Isso permite que os dados se movam eficientemente entre a memória e a GPU, evitando cópias desnecessárias de potencialmente bilhões de vetores.

Graças a essa abstração subjacente de cópia zero, tanto a transferência para a memória da GPU quanto a recuperação do gráfico podem ocorrer diretamente. Durante a indexação, os vetores são primeiro armazenados em buffer na memória do heap Java e depois enviados para a GPU para construir o gráfico CAGRA. O gráfico é posteriormente recuperado da GPU, convertido para o formato HNSW e persistido no disco.

No momento da fusão, os vetores já estão armazenar no disco, ignorando completamente o heap Java. Os arquivos de índice são mapeados em memória, e os dados são transferidos diretamente para a memória da GPU. O projeto também acomoda facilmente diferentes larguras de bits, como float32 ou int8, e se estende naturalmente a outros esquemas de quantização.

Drumroll... então, como funciona?

Antes de entrarmos nos números, um pouco de contexto é útil. A fusão de segmentos no Elasticsearch normalmente é executada de forma automática em segundo plano durante a indexação, o que dificulta a realização de testes de desempenho isoladamente. Para obter resultados reprodutíveis, usamos a fusão forçada para desencadear explicitamente a fusão de segmentos em um experimento controlado. Como a fusão forçada realiza as mesmas operações subjacentes de fusão que a fusão em segundo plano, seu desempenho serve como um indicador útil das melhorias esperadas, mesmo que os ganhos exatos possam diferir nas cargas de trabalho de indexação do mundo real.

Agora, vamos ver os números.

Nossos resultados iniciais de benchmark são muito promissores. Executamos o benchmark em uma instância AWS g6.4xlarge com armazenamento NVMe conectado localmente. Um único node do Elasticsearch foi configurado para usar o número padrão e ideal de threads de indexação (8 - uma para cada núcleo físico) e para desativar a limitação de mesclagem (o que é menos aplicável com discos NVMe rápidos).

Para o conjunto de dados, usamos 2,6 milhões de vetores com 1.536 dimensões da trilha vetorial do OpenAI Rally, codificados como strings base64 e indexados como float32 hnsw. Em todos os cenários, os gráficos construídos atingem níveis de recall de até 95%. Veja o que descobrimos:

• Taxa de transferência de indexação: ao transferir a construção de gráficos para a GPU durante as descargas de buffer na memória, aumentamos a taxa de transferência em cerca de 12 vezes.

• Fusão forçada: após a conclusão da indexação, a GPU continua acelerando a fusão de segmentos, acelerando a fase de mesclagem forçada em aproximadamente 7x.

• Uso da CPU: o descarregamento da construção de gráficos para a GPU reduz significativamente a utilização média e de pico da CPU. Os gráficos abaixo ilustram o uso da CPU durante a indexação e a fusão, destacando o quanto é menor quando essas operações são executadas na GPU. Menor utilização da CPU durante a indexação da GPU libera ciclos de CPU que podem ser redirecionados para melhorar o desempenho da busca.

• Lembrete: a precisão permanece efetivamente a mesma entre as execuções de CPU e GPU, com o gráfico construído por GPU alcançando um recall marginalmente mais alto.

Comparando em outra dimensão: Preço

A comparação anterior usava intencionalmente hardware idêntico, com a única diferença sendo se a GPU era usada durante a indexação. Essa configuração é útil para isolar efeitos brutos de computação, mas também podemos olhar para a comparação dos custos.

Por aproximadamente o mesmo preço por hora da configuração acelerada por GPU, é possível provisionar uma configuração apenas CPU com aproximadamente o dobro dos recursos comparáveis de CPU e memória: 32 vCPUs (AMD EPYC) e 64 GB de RAM, permitindo dobrar o número de threads de indexação para 16.

Para manter a comparação justa e consistente, executamos esse experimento apenas com CPU em uma instância AWS g6.8xlarge, com a GPU explicitamente desativada. Isso nos permitiu manter todas as outras características de hardware constantes ao avaliar a relação custo-desempenho da aceleração da GPU em comparação com a indexação somente da CPU.

A instância mais potente da CPU mostra desempenho melhor em comparação com os benchmarks da seção acima, como era de se esperar. No entanto, ao compararmos essa instância de CPU mais potente com os resultados originais acelerados por GPU, a GPU ainda oferece ganhos de desempenho substanciais: melhoria de aproximadamente 5 vezes na taxa de transferência de indexação e aproximadamente 6 vezes na fusão forçada, tudo isso enquanto constrói gráficos que atingem níveis de recall de até 95%.

Conclusão

Em cenários de ponta a ponta, a aceleração de GPU com NVIDIA cuVS proporciona quase 12x de melhoria na taxa de indexação e uma redução de 7x na latência de fusão forçada, com uma utilização significativamente menor da CPU. Isso mostra que a indexação vetorial e as cargas de trabalho de fusão se beneficiam significativamente da aceleração da GPU. Em uma comparação ajustada ao custo, a aceleração da GPU continua a gerar ganhos substanciais de desempenho, com taxa de transferência de indexação aproximadamente 5 vezes maior e operações de fusão forçada 6 vezes mais rápidas.

A indexação de vetores acelerada por GPU está atualmente planejada para Prévia Técnica no Elasticsearch 9.3, que está programada para ser lançada no início de 2026.

Fique ligado para mais.

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.

Na última parte desta série, mostramos como implantar o modelo pré-treinado E5 da Elastic (bem como outros modelos de incorporação de texto multilíngue da Hugging Face) e exploramos a geração de embeddings vetoriais densos a partir de seus dados de texto usando o Elasticsearch e o Kibana. Neste blog, examinaremos os resultados dessas incorporações e destacaremos as vantagens significativas de se utilizar um modelo multilíngue.

Agora que temos nosso índice coco_multilingual, realizar a busca nos retornará documentos em vários idiomas, com o campo “en” para referência:

Realizar uma pesquisa em inglês

Vamos tentar realizar a pesquisa em inglês e ver como funciona:

Aqui, embora a consulta pareça enganosamente simples, estamos buscando, nos bastidores, as representações numéricas da palavra 'kitty' em todos os documentos e em todos os idiomas. E como estamos realizando uma busca vetorial, podemos pesquisar semanticamente todas as palavras que possam estar relacionadas a 'gatinho': “gato”, “gatinho”, “felino”, “gatto” (italiano), “mèo” (vietnamita), 고양이 (coreano), 猫 (chinês), etc. Consequentemente, mesmo que minha consulta seja em inglês, podemos pesquisar conteúdo em todos os outros idiomas também. Por exemplo, pesquisar por um gatinho lying on something também retorna documentos em italiano, holandês ou vietnamita. Que eficiência!

Realizar uma busca por conteúdo em outros idiomas.

Da mesma forma, realizar uma busca pela palavra-chave “gato” em coreano (“고양이”) também retornará resultados relevantes. O mais impressionante é que não temos nenhum documento em coreano neste índice!

Isso funciona porque o modelo de incorporação representa o significado em um espaço semântico compartilhado, permitindo a recuperação de imagens relevantes mesmo com uma consulta em um idioma diferente do das legendas indexadas.

Aumentando os resultados de pesquisa relevantes com pesquisa híbrida e reclassificação.

Estamos satisfeitos por os resultados relevantes terem surgido conforme o esperado. Mas, no mundo real, digamos, no comércio eletrônico ou em aplicações RAG que precisam filtrar os resultados para os 5 a 10 mais relevantes, podemos usar um modelo de reclassificação para priorizar os resultados mais pertinentes.

Nesse caso, uma busca em vietnamita, como "qual a cor do gato?", retornará muitos resultados, mas os dois primeiros podem não ser os mais relevantes.

Todos os resultados mencionam gato ou alguma forma de cor:

Então vamos melhorar isso! Vamos integrar o modelo de reclassificação multilíngue do Coherepara melhorar o raciocínio correspondente à nossa pergunta.

Agora, com os melhores resultados, nosso aplicativo pode afirmar com segurança que a cor do gatinho é preta ou marrom com listras. O que é ainda mais interessante é que nossa busca vetorial detectou uma omissão na legenda em inglês do conjunto de dados original. O programa consegue encontrar o gato marrom listrado, mesmo que a tradução de referência em inglês tenha omitido esse detalhe. Este é o poder da busca vetorial.

Conclusão

Neste blog, exploramos a utilidade de um modelo de incorporação multilíngue e como aproveitar o Elasticsearch para integrar os modelos, gerar incorporações e melhorar efetivamente a relevância e a precisão com uma busca e reclassificação híbrida. Você pode criar seu próprio cluster na nuvem para experimentar a busca semântica multilíngue usando nosso modelo E5 pronto para uso, no idioma e conjunto de dados de sua escolha.

Em um mundo de usuários globais, a recuperação de informações multilíngue (CLIR) é crucial. Em vez de limitar as buscas a um único idioma, o CLIR permite encontrar informações em qualquer idioma, aprimorando a experiência do usuário e simplificando as operações. Imagine um mercado global onde os clientes de comércio eletrônico possam pesquisar itens em seu idioma e os resultados corretos apareçam, sem a necessidade de localizar os dados antecipadamente. Ou seja, onde pesquisadores acadêmicos podem buscar artigos em seu idioma nativo, com nuances e complexidade, mesmo que a fonte esteja em outro idioma.

Os modelos de incorporação de texto multilíngue nos permitem fazer exatamente isso. Os embeddings são uma forma de representar o significado do texto como vetores numéricos. Esses vetores são projetados de forma que textos com significados semelhantes fiquem localizados próximos uns dos outros em um espaço de alta dimensão. Os modelos de incorporação de texto multilíngue são projetados especificamente para mapear palavras e frases com o mesmo significado em diferentes idiomas para um espaço vetorial semelhante.

Modelos como o Multilingual E5, de código aberto, são treinados com grandes quantidades de dados textuais, frequentemente utilizando técnicas como o aprendizado contrastivo. Nessa abordagem, o modelo aprende a distinguir entre pares de textos com significados semelhantes (pares positivos) e aqueles com significados diferentes (pares negativos). O modelo é treinado para ajustar os vetores que produz de forma a maximizar a similaridade entre pares positivos e minimizar a similaridade entre pares negativos. Para modelos multilíngues, esses dados de treinamento incluem pares de textos em diferentes idiomas que são traduções uns dos outros, permitindo que o modelo aprenda um espaço de representação compartilhado para vários idiomas. Os embeddings resultantes podem então ser usados para diversas tarefas de PNL (Processamento de Linguagem Natural), incluindo buscas multilíngues, onde a similaridade entre os embeddings de texto é usada para encontrar documentos relevantes independentemente do idioma da consulta.

Benefícios da busca vetorial multilíngue

• Nuance: A busca vetorial se destaca na captura do significado semântico, indo além da correspondência por palavras-chave. Isso é crucial para tarefas que exigem a compreensão do contexto e das sutilezas da linguagem.

• Compreensão Interlinguística: Permite a recuperação eficaz de informações em diferentes idiomas, mesmo quando a consulta e os documentos utilizam vocabulário diferente.

• Relevância: Oferece resultados mais relevantes ao focar na similaridade conceitual entre consultas e documentos.

Por exemplo, considere um pesquisador acadêmico que estuda o "impacto das mídias sociais no discurso político" em diferentes países. Com a pesquisa vetorial, eles podem inserir consultas como "l'impatto dei social media sul discorso politico" (italiano) ou "ảnh hưởng của mạng xã hội đối với diễn ngôn chính trị" (vietnamita) e encontrar artigos relevantes em inglês, espanhol ou qualquer outro idioma indexado. Isso ocorre porque a busca vetorial identifica artigos que discutem o conceito da influência das mídias sociais na política, e não apenas aqueles que contêm as palavras-chave exatas. Isso amplia consideravelmente o alcance e a profundidade de suas pesquisas.

Introdução

Veja como configurar o CLIR usando o Elasticsearch - com o modelo E5 que já vem instalado por padrão. Usaremos o conjunto de dados multilíngue de código aberto COCO, que contém legendas de imagens em vários idiomas, para nos ajudar a visualizar 2 tipos de pesquisas:

1. Consultas e termos de pesquisa em outros idiomas em um conjunto de dados em inglês, e

2. Consultas em vários idiomas sobre um conjunto de dados que contém documentos em vários idiomas.

Em seguida, aproveitaremos o poder da busca híbrida e do reclassificação para melhorar ainda mais os resultados da pesquisa.

Pré-requisitos

• Python 3.6+

• Elasticsearch 8+

• Cliente Python do Elasticsearch: pip install elasticsearch

Conjunto de dados

O conjunto de dados COCO é um conjunto de dados de legendagem em larga escala. Cada imagem no conjunto de dados possui legenda em vários idiomas diferentes, com diversas traduções disponíveis para cada idioma. Para fins de demonstração, indexaremos cada tradução como um documento individual, juntamente com a primeira tradução em inglês disponível para referência.

Passo 1: faça o download do conjunto de dados COCO multilíngue.

Para simplificar o blog e facilitar o acompanhamento, estamos carregando as primeiras 100 linhas do restval em um arquivo JSON local com uma simples chamada de API. Alternativamente, você pode usar os conjuntos de dados da biblioteca do HuggingFace para carregar o conjunto de dados completo ou subconjuntos dele.

Se os dados forem carregados com sucesso em um arquivo JSON, você deverá ver algo semelhante a isto:

Data successfully downloaded and saved to multilingual_coco_sample.json

Etapa 2: (Inicie o Elasticsearch) e indexe os dados no Elasticsearch.

a) Inicie o servidor Elasticsearch local.

b) Inicie o cliente Elasticsearch.

c) Dados de índice

Após a indexação dos dados, você deverá ver algo semelhante a isto:

Successfully bulk indexed 4840 documents

Indexing complete!

Etapa 3: Implantar o modelo treinado E5

No Kibana, navegue até a página Gerenciamento de Pilha > Modelos Treinados e clique em Implantar para o modelo .multilingual-e5-small_linux-x86_64. opção. Este modelo E5 é um sistema operacional multilíngue compacto, otimizado para Linux x86_64, que podemos usar imediatamente. Ao clicar em "Implantar", será exibida uma tela onde você poderá ajustar as configurações de implantação ou as configurações de vCPUs. Para simplificar, vamos usar as opções padrão, com recursos adaptáveis selecionados, que dimensionarão automaticamente nossa implantação dependendo do uso.

Opcionalmente, se desejar, você pode usar outros modelos de incorporação de texto. Por exemplo, para usar o BGE-M3, você pode usar o cliente Python Eland da Elastic para importar o modelo do HuggingFace.

Em seguida, acesse a página Modelos Treinados para implantar o modelo importado com as configurações desejadas.

Etapa 4: Vetorizar ou criar embeddings para os dados originais com o modelo implantado

Para criar os embeddings, primeiro precisamos criar um pipeline de ingestão que nos permita pegar o texto e executá-lo através do modelo de inferência de embeddings de texto. Você pode fazer isso na interface do usuário do Kibana ou através da API do Elasticsearch.

Para fazer isso através da interface do Kibana, após implantar o modelo treinado, clique no botão Testar . Isso lhe dará a possibilidade de testar e visualizar as imagens incorporadas geradas. Crie uma nova visualização de dados para o cocoindex, defina a visualização de dados para a visualização de dados coco recém-criada e defina o campo para description porque esse é o campo para o qual queremos gerar embeddings.

Isso funciona perfeitamente! Agora podemos prosseguir com a criação do pipeline de ingestão e reindexar nossos documentos originais, passá-los pelo pipeline e criar um novo índice com os embeddings. Você pode fazer isso clicando em Criar pipeline, que o guiará pelo processo de criação do pipeline, com processadores preenchidos automaticamente, necessários para ajudá-lo a criar os embeddings.

O assistente também pode preencher automaticamente os processadores necessários para lidar com falhas durante a ingestão e o processamento dos dados.

Vamos agora criar o pipeline de ingestão. Estou nomeando o pipeline coco_e5. Após a criação bem-sucedida do pipeline, você pode usá-lo imediatamente para gerar os embeddings, reindexando os dados indexados originais para um novo índice no assistente. Clique em Reindexar para iniciar o processo.

Para configurações mais complexas, podemos usar a API do Elasticsearch.

Para alguns modelos, devido à forma como foram treinados, pode ser necessário adicionar ou acrescentar certos textos à entrada real antes de gerar os embeddings; caso contrário, observaremos uma degradação no desempenho.

Por exemplo, com o e5, o modelo espera que o texto de entrada siga “passagem: {content of passage}”. Vamos utilizar os pipelines de ingestão para realizar isso: Criaremos um novo pipeline de ingestão chamado vectorize_descriptions. Neste pipeline, criaremos um novo campo temporário temp_desc , adicionaremos “passagem: “ ao texto description , executaremos temp_desc através do modelo para gerar embeddings de texto e, em seguida, excluiremos o temp_desc.

Além disso, podemos querer especificar qual tipo de quantização desejamos usar para o vetor gerado. Por padrão, o Elasticsearch usa int8_hnsw, mas aqui eu quero Better Binary Quantization (ou bqq_hnsw), que reduz cada dimensão a uma precisão de um único bit. Isso reduz a necessidade de memória em 96% (ou 32 vezes), ao custo de uma maior perda de precisão. Estou optando por esse tipo de quantização porque sei que usarei um reclassificador posteriormente para melhorar a perda de precisão.

Para isso, criaremos um novo índice chamado coco_multi e especificaremos os mapeamentos. A mágica está no campo vector_description, onde especificamos o tipo de index_optionscomo bbq_hnsw.

Agora, podemos reindexar os documentos originais para um novo índice, com nosso pipeline de ingestão que irá "vetorizar" ou criar embeddings para o campo de descrição.

E é isso! Implementamos com sucesso um modelo multilíngue com Elasticsearch e Kibana e aprendemos passo a passo como criar representações vetoriais (embeddings) com seus dados usando o Elastic, seja pela interface do usuário do Kibana ou pela API do Elasticsearch. Na segunda parte desta série, exploraremos os resultados e as nuances da utilização de um modelo multilíngue. Enquanto isso, você pode criar seu próprio cluster na nuvem para experimentar a busca semântica multilíngue usando nosso modelo E5 pronto para uso no idioma e conjunto de dados de sua escolha.

Compreender como a filtragem funciona na busca vetorial ajudará você a equilibrar as vantagens e desvantagens em termos de desempenho e recall, além de descobrir algumas das otimizações usadas para tornar a busca vetorial eficiente quando a filtragem é utilizada.

Por que filtrar?

A busca vetorial revolucionou a forma como encontramos informações relevantes em grandes conjuntos de dados, permitindo-nos descobrir itens semanticamente semelhantes a uma consulta.

No entanto, simplesmente encontrar itens semelhantes não é suficiente. Frequentemente precisamos refinar os resultados da pesquisa com base em critérios ou atributos específicos.

Imagine que você está procurando um produto em uma loja de comércio eletrônico. Uma busca puramente vetorial pode mostrar itens visualmente semelhantes, mas você também pode querer filtrar por faixa de preço, marca, disponibilidade ou avaliações de clientes. Sem filtros, você se depararia com uma vasta gama de produtos similares, dificultando a busca exatamente pelo que procura.

A filtragem permite um controle preciso sobre os resultados da pesquisa, garantindo que os itens recuperados não apenas estejam alinhados semanticamente, mas também atendam a todos os requisitos necessários. Isso resulta em uma experiência de busca muito mais precisa, eficiente e fácil de usar.

É aqui que o Elasticsearch e o Apache Lucene se destacam — o uso de filtragem eficaz em vários tipos de dados é uma das principais diferenças em relação a outros bancos de dados vetoriais.

Filtrar para pesquisa vetorial exata

Existem duas maneiras principais de realizar buscas vetoriais exatas:

• Utilizando um tipo de índice flat para o seu campo dense_vector. Isso faz com que as buscas knn usem busca exata em vez de aproximada.

• Utilizando uma consulta script_score que usa funções vetoriais para calcular a pontuação. Isso pode ser usado com qualquer tipo de índice.

Ao executar uma busca vetorial exata, todos os vetores são comparados à consulta. Nesse cenário, a filtragem ajudará no desempenho, pois somente os vetores que passarem pelo filtro precisarão ser comparados.

Isso não afeta a qualidade do resultado, pois todos os vetores são considerados de qualquer forma. Estamos apenas filtrando antecipadamente os resultados que não são interessantes, para que possamos reduzir o número de operações.

Isso é muito importante, pois pode ser mais eficiente executar uma pesquisa exata em vez de uma pesquisa aproximada quando os filtros aplicados resultam em um pequeno número de documentos.

A regra geral é usar a pesquisa exata quando menos de 10 mil documentos passarem pelo filtro. Os índices BBQ são muito mais rápidos para comparações, portanto, faz sentido usar a pesquisa exata quando o número de índices baseados for inferior a 100 mil. Confira esta postagem no blog para obter mais detalhes.

Caso seus filtros sejam sempre muito restritivos, você pode considerar indexar focando na busca exata em vez da busca aproximada usando um tipo de índice flat em vez de um baseado em HNSW. Para obter mais detalhes, consulte as propriedades de index_options.

Filtragem para busca vetorial aproximada

Ao executar uma busca vetorial aproximada, trocamos precisão do resultado por desempenho. Estruturas de dados de busca vetorial, como o HNSW, pesquisam de forma eficiente os vizinhos mais próximos aproximados em milhões de vetores. Eles se concentram em recuperar os vetores mais semelhantes realizando o mínimo de comparações vetoriais possível, que são computacionalmente dispendiosas.

Isso significa que outros atributos de filtragem não fazem parte dos dados vetoriais. Diferentes tipos de dados possuem suas próprias estruturas de indexação, que são eficientes para encontrá-los e filtrá-los, como dicionários de termos, listas de postagens e valores de documentos.

Dado que essas estruturas de dados são separadas do mecanismo de busca vetorial, como aplicamos a filtragem à busca vetorial? Existem duas opções: aplicar filtros após a busca vetorial (pós-filtragem) ou antes da busca vetorial (pré-filtragem).

Cada uma dessas opções tem vantagens e desvantagens. Vamos analisar esses assuntos mais a fundo!

Pós-filtragem

A pós-filtragem aplica filtros após a pesquisa vetorial ter sido realizada. Isso significa que os filtros são aplicados depois que os k resultados vetoriais mais semelhantes forem encontrados.

Obviamente, podemos obter menos de k resultados após aplicar os filtros aos resultados. É claro que poderíamos obter mais resultados com a busca vetorial (valor k maior), mas não teríamos certeza de que obteríamos k ou mais resultados após a aplicação dos filtros.

A vantagem da pós-filtragem é que ela não altera o comportamento em tempo de execução da busca vetorial — a busca vetorial não leva em consideração a filtragem. Mas isso altera o número final de resultados obtidos.

Segue abaixo um exemplo de pós-filtragem usando a consulta knn. Verifique se a cláusula de filtragem está separada da consulta KNN:

O pós-filtro também está disponível para a pesquisa knn usando o comando post-filter:

Lembre-se de que é necessário usar uma seção de pós-filtragem explícita na pesquisa KNN. Se você não usar um filtro posterior, a pesquisa KNN combinará os resultados dos vizinhos mais próximos com outras consultas ou filtros, em vez de aplicar um filtro posterior.

Pré-filtragem

Aplicar filtros antes da busca vetorial primeiro recuperará os documentos que atendem aos filtros e, em seguida, passará essa informação para a busca vetorial.

O Lucene utiliza BitSets para armazenar de forma eficiente os documentos que satisfazem a condição do filtro. A busca vetorial percorre então o grafo HNSW, levando em consideração os documentos que satisfazem a condição. Antes de adicionar um candidato aos resultados, o sistema verifica se ele está contido no BitSet de documentos válidos.

No entanto, o candidato deve ser analisado e comparado à consulta, mesmo que não seja um documento válido. A eficácia do HNSW depende da conexão entre os vetores no grafo — se parássemos de explorar um candidato, isso significaria que também poderíamos estar ignorando seus vizinhos.

Imagine que você está dirigindo até um posto de gasolina. Se você descartar todas as estradas que não têm um posto de gasolina, é improvável que você chegue ao seu destino. Outras estradas podem não ser o que você precisa, mas elas te levam ao seu destino. O mesmo se aplica aos vetores em um grafo HNSW!

Conclui-se, portanto, que aplicar pré-filtragem tem um desempenho inferior a não aplicar filtros. Precisamos processar todos os vetores que visitamos em nossa busca e descartar aqueles que não correspondem ao filtro. Estamos trabalhando mais e dedicando mais tempo para obter nossos melhores resultados.

Segue abaixo um exemplo de pré-filtragem na DSL de consulta do Elasticsearch. Verifique se a cláusula de filtragem agora faz parte da seção knn:

O pré-filtro está disponível tanto para a pesquisa KNN quanto para a consulta KNN:

Otimizações de pré-filtragem

Existem algumas otimizações que podemos aplicar para garantir que a pré-filtragem seja eficiente.

Podemos alternar para a pesquisa exata se o filtro for muito restritivo. Quando há poucos vetores para comparar, é mais rápido realizar uma busca exata nos poucos documentos que satisfazem o filtro.

Essa é uma otimização que é aplicada automaticamente no Lucene e no Elasticsearch.

Outro método de otimização envolve desconsiderar os vetores que não satisfazem o filtro. Em vez disso, esse método verifica os vizinhos dos vetores filtrados que passam pelo filtro. Essa abordagem reduz efetivamente o número de comparações, pois os vetores filtrados não são considerados, e continua a explorar vetores conectados ao caminho atual.

Este algoritmo é o ACORN-1, e o processo é descrito em detalhes nesta postagem do blog.

Filtragem usando segurança em nível de documento

A Segurança em Nível de Documento (DLS, na sigla em inglês) é um recurso do Elasticsearch que especifica os documentos que as funções de usuário podem recuperar.

A DLS é realizada por meio de consultas. Uma função pode ter uma consulta associada a índices, o que efetivamente limita os documentos que um usuário pertencente a essa função pode recuperar dos índices.

A consulta de função é usada como um filtro para recuperar os documentos que correspondem a ela e são armazenados em cache como um BitSet. Esse BitSet é então usado para encapsular o leitor Lucene subjacente, de forma que apenas os documentos retornados pela consulta sejam considerados ativos —ou seja, eles existem no índice e não foram excluídos.

À medida que os documentos ativos são recuperados do leitor para executar a consulta KNN, somente os documentos disponíveis para o usuário serão considerados. Caso exista um pré-filtro, os documentos DLS serão adicionados a ele.

Isso significa que a filtragem DLS funciona como um pré-filtro para a busca vetorial aproximada, com as mesmas implicações de desempenho e otimizações.

A busca DLS com pesquisa exata terá os mesmos benefícios que a aplicação de qualquer filtro — quanto menos documentos forem recuperados da DLS, mais eficiente será a pesquisa exata. Considere também o número de documentos retornados pelo DLS — se as funções do DLS forem muito restritivas, você pode considerar usar a pesquisa exata em vez da pesquisa aproximada.

Benchmarking

Na Elasticsearch, queremos garantir que a filtragem por vetores seja eficiente. Temos um benchmark específico para filtragem vetorial que realiza buscas vetoriais aproximadas com diferentes filtros para garantir que a busca vetorial continue recuperando resultados relevantes o mais rápido possível.

Confira as melhorias implementadas com a introdução do ACORN-1. Para testes em que apenas 2% dos vetores passam pelo filtro, a latência da consulta é reduzida para 55% da duração original:

Conclusão

A filtragem é parte integrante da pesquisa. Garantir que a filtragem seja eficiente na busca vetorial e compreender as compensações e otimizações envolvidas é o que determina o sucesso ou o fracasso de uma busca eficiente e precisa.

A filtragem afeta o desempenho da busca vetorial:

• A busca exata é mais rápida ao usar filtros. Se a sua filtragem for suficientemente restritiva, considere usar a pesquisa exata em vez da pesquisa aproximada. Esta é uma otimização automática no Elasticsearch.

• A busca aproximada é mais lenta quando se utiliza pré-filtragem. A pré-filtragem permite obter os k melhores resultados que correspondem ao filtro, ao custo de uma pesquisa mais lenta.

• A pós-filtragem não recupera necessariamente os k melhores resultados, pois eles podem ser filtrados pelo filtro quando este é aplicado.

Boa filtragem!

Neste artigo, discutiremos esses tipos de campos, quando usar cada um deles e como eles se relacionam com as estratégias de geração e uso de embeddings, tanto durante a indexação quanto na consulta.

Tipo de vetor denso

O tipo de campo dense_vector no Elasticsearch é usado para armazenar vetores densos, que são representações numéricas de dados como texto, imagens e áudio, onde quase todas as dimensões são relevantes. Esses vetores são gerados usando modelos de incorporação fornecidos por plataformas como OpenAI, Cohere ou Hugging Face, e são projetados para capturar o significado semântico geral dos dados, mesmo quando eles não compartilham termos exatos com outros documentos.

No Elasticsearch, vetores densos podem ter até 4096 dimensões, dependendo do modelo utilizado. Por exemplo, o modelo all-MiniLM-L6-v2 gera vetores com 384 dimensões, enquanto o text-embedding-ada-002 da OpenAI produz vetores com 1536 dimensões.

O campo dense_vector é geralmente adotado como o tipo padrão para armazenar esse tipo de incorporação quando é necessário maior controle, como usar vetores pré-gerados, aplicar funções de similaridade personalizadas ou integrar com modelos externos.

Quando e por que usar o tipo dense_vector?

Vetores densos são excelentes para capturar a similaridade semântica entre frases, parágrafos ou documentos inteiros. Funcionam muito bem quando o objetivo é comparar o significado geral dos textos, mesmo que não compartilhem os mesmos termos.

O campo vetorial denso é ideal quando você já possui um pipeline externo de geração de embeddings usando modelos fornecidos por plataformas como OpenAI, Cohere ou Hugging Face e deseja apenas armazenar e consultar esses vetores manualmente. Este tipo de campo oferece alta compatibilidade com modelos de incorporação e total flexibilidade na geração e consulta, permitindo controlar como os vetores são produzidos, indexados e usados durante a busca.

Além disso, oferece suporte a diferentes formas de busca semântica, com consultas como k-NN ou script_score para casos em que seja necessário ajustar a lógica de classificação. Essas possibilidades tornam o vetor denso ideal para aplicações como RAG (Retrieval-Augmented Generation), sistemas de recomendação e buscas personalizadas baseadas em similaridade.

Finalmente, o campo permite personalizar a lógica de relevância, usando funções como cosineSimilarity, dotProduct ou l2norm para adaptar a classificação de acordo com as necessidades do seu caso de uso.

Vetores densos continuam sendo a melhor opção para quem precisa de flexibilidade, personalização e compatibilidade com casos de uso avançados, como os mencionados acima.

Como usar a consulta para o tipo vetor denso?

As pesquisas em campos definidos como dense_vector usam a consulta dos k vizinhos mais próximos. Esta consulta é responsável por encontrar documentos cujo vetor denso seja o mais próximo do vetor de consulta. Abaixo, segue um exemplo de como aplicar uma consulta k-NN a um campo vetorial denso:

Além da consulta k-NN, caso haja necessidade de personalizar a pontuação do documento, também é possível usar a consulta script_score, combinando-a com funções de comparação vetorial, como cossenosimilaridade, produto escalar ou norma l2, para calcular a relevância de forma mais controlada. Veja o exemplo:

Se você quiser se aprofundar no assunto, recomendo explorar o artigo Como configurar a pesquisa vetorial no Elasticsearch.

Tipo de vetor esparso

O tipo de campo sparse_vector é usado para armazenar vetores esparsos, que são representações numéricas onde a maioria dos valores é zero e apenas alguns termos têm pesos significativos. Esse tipo de vetor é comum em modelos baseados em termos, como o SPLADE ou o ELSER (Elastic Learned Sparse EncodeR).

Quando e por que usar vetores esparsos?

Vetores esparsos são ideais quando você precisa de uma busca mais precisa em termos lexicais, sem sacrificar a inteligência semântica. Eles representam o texto como pares de token/valor, destacando apenas os termos mais relevantes com pesos associados, o que proporciona clareza, controle e eficiência.

Esse tipo de campo é especialmente útil quando você gera vetores com base em termos, como nos modelos ELSER ou SPLADE, que atribuem pesos diferentes a cada token com base em sua importância relativa no texto.

Para as ocasiões em que você deseja controlar a influência de palavras específicas na consulta, os tipos de vetores esparsos permitem ajustar manualmente o peso dos termos para otimizar a classificação dos resultados.

Entre os principais benefícios estão a transparência na busca, já que é possível entender claramente por que um documento foi considerado relevante, e a eficiência de armazenamento, pois apenas os tokens com valor diferente de zero são salvos, ao contrário dos vetores densos que armazenam todas as dimensões.

Além disso, vetores esparsos são o complemento ideal em estratégias de busca híbridas, podendo inclusive ser combinados com vetores densos para unir precisão lexical à compreensão semântica.

Como usar a consulta para o tipo vetor esparso?

A consulta sparse_vector permite pesquisar documentos com base em um vetor de consulta no formato token/valor. Veja um exemplo da consulta abaixo:

Se preferir usar um modelo treinado, é possível utilizar um endpoint de inferência que transforma automaticamente o texto da consulta em um vetor esparso:

Para explorar este tópico mais a fundo, sugiro a leitura de Understanding sparse vector embeddings with trained ML models.

Tipo de texto semântico

O tipo de campo semantic_text é a maneira mais simples e direta de usar a pesquisa semântica no Elasticsearch. Ele lida automaticamente com a geração de embeddings, tanto no momento da indexação quanto no momento da consulta, por meio de um endpoint de inferência. Isso significa que você não precisa se preocupar em gerar ou armazenar vetores manualmente.

Quando e por que usar texto semântico?

O campo semantic_text é ideal para quem quer começar com o mínimo de esforço técnico e sem ter que lidar com vetores manualmente. Este campo automatiza etapas como a geração de incorporações e o mapeamento de busca vetorial, tornando a configuração mais rápida e conveniente.

Você deve considerar usar semantic_text quando valoriza simplicidade e abstração, pois isso elimina a complexidade de configurar manualmente mapeamentos, geração de incorporações e pipelines de ingestão. Basta selecionar o modelo de inferência e o Elasticsearch cuida do resto.

As principais vantagens incluem a geração automática de embeddings, realizada durante a indexação e a consulta, e o mapeamento pronto para uso, que já vem pré-configurado para suportar o modelo de inferência selecionado.

Além disso, o campo oferece suporte nativo para a divisão automática de textos longos (fragmentação de texto), permitindo que textos extensos sejam divididos em trechos menores, cada um com seu próprio embedding, o que melhora a precisão da busca. Isso aumenta consideravelmente a produtividade, especialmente para equipes que desejam entregar valor rapidamente sem se preocupar com a engenharia subjacente da busca semântica.

No entanto, embora semantic_text proporcione velocidade e simplicidade, esta abordagem tem algumas limitações. Permite a utilização de modelos padrão de mercado, desde que estejam disponíveis como endpoints de inferência no Elasticsearch. Mas não suporta incorporações geradas externamente, como é possível com o campo dense_vector .

Se você precisar de mais controle sobre como os vetores são gerados, quiser usar seus próprios embeddings ou precisar combinar vários campos para estratégias avançadas, os campos dense_vector e sparse_vector fornecem a flexibilidade necessária para cenários mais personalizados ou específicos do domínio.

Como usar a consulta para o tipo de texto semântico

Antes de semantic_text, era necessário usar uma consulta diferente dependendo do tipo de incorporação (densa ou esparsa). Uma consulta sparse_vector foi usada para campos esparsos, enquanto campos dense_vector exigiram consultas KNN.

Com o tipo de texto semântico, a busca é realizada utilizando a consulta semântica, que gera automaticamente o vetor de consulta e o compara com os embeddings dos documentos indexados. O tipo semantic_text permite definir um ponto de extremidade de inferência para incorporar a consulta, mas se nenhum for especificado, o mesmo ponto de extremidade usado durante a indexação será aplicado à consulta.

Para saber mais, sugiro a leitura do artigo Elasticsearch new semantic_text mapping: Simplifying semantic search.

Conclusão

Ao escolher como mapear embeddings no Elasticsearch, é essencial entender como você deseja gerar os vetores e qual o nível de controle necessário sobre eles. Se você busca simplicidade, o campo de texto semântico permite buscas semânticas automáticas e escaláveis, tornando-o ideal para muitos casos de uso iniciais. Quando é necessário maior controle, desempenho mais preciso ou integração com modelos personalizados, os campos vetoriais densos e esparsos oferecem a flexibilidade necessária.

O tipo de campo ideal depende do seu caso de uso, da infraestrutura disponível e do nível de maturidade da sua pilha de aprendizado de máquina. Mais importante ainda, a Elastic oferece as ferramentas para construir sistemas de busca modernos e altamente adaptáveis.

Referências

• Tipo de campo de texto semântico

• Tipo de campo vetorial esparso

• Tipo de campo vetorial denso

• Consulta semântica

• Consulta de vetor esparso

• pesquisa kNN

• Novo mapeamento semantic_text do Elasticsearch: Simplificando a busca semântica

• Compreendendo incorporações vetoriais esparsas com modelos de aprendizado de máquina treinados

Todas as consultas e saídas completas mencionadas neste artigo podem ser encontradas em nosso repositório de código do Elasticsearch Labs.

Por que implementar a Quantização Binária Aprimorada (BBQ) no seu caso de uso?

Embora a matemática seja fascinante, é crucial entender completamente por que suas buscas vetoriais permanecem precisas. Em última análise, tudo se resume à compressão, já que, com os algoritmos de busca vetorial atuais, o limite é a velocidade de leitura dos dados. Portanto, se você conseguir armazenar todos esses dados na memória, obterá um aumento significativo de velocidade em comparação com a leitura do armazenamento (a memória é aproximadamente 200 vezes mais rápida que os SSDs).

Há algumas coisas que você precisa ter em mente:

• Índices baseados em gráficos como HNSW (Hierarchical Navigable Small World) são os mais rápidos para recuperação de vetores.

  • HNSW: Um algoritmo de busca aproximado do vizinho mais próximo que constrói uma estrutura de gráfico multicamadas para permitir buscas eficientes de similaridade de alta dimensão.

• O HNSW é fundamentalmente limitado em velocidade pela velocidade de leitura de dados da memória ou, no pior caso, do armazenamento.

  • O ideal é que você consiga carregar todos os seus vetores armazenados na memória.

• Os modelos de incorporação geralmente produzem vetores com precisão float32, 4 bytes por número de ponto flutuante.

• E, finalmente, dependendo de quantos vetores e/ou dimensões você tem, você pode rapidamente ficar sem memória para manter todos os seus vetores.

Considerando isso como certo, você verá que um problema surge rapidamente quando você começa a ingerir milhões ou até bilhões de vetores, cada um com potencialmente centenas ou até milhares de dimensões. A seção intitulada “Números aproximados sobre as taxas de compressão” fornece alguns números aproximados.

O que você precisa para começar?

Para começar, você precisará do seguinte:

• Se estiver usando o Elastic Cloud ou no local, você precisará de uma versão do Elasticsearch superior a 8.18. Embora o BBQ tenha sido introduzido na versão 8.16, neste artigo, você usará vector_rescore, que foi introduzido na versão 8.18.

• Além disso, você também precisará garantir que haja um nó de aprendizado de máquina (ML) no seu cluster. (Observação: um nó de ML com no mínimo 4 GB é necessário para carregar o modelo, mas você provavelmente precisará de nós muito maiores para cargas de trabalho de produção completas.)

• Se estiver usando o Serverless, você precisará selecionar uma instância otimizada para vetores.

• Você também precisará de um nível básico de conhecimento sobre bancos de dados vetoriais. Se você ainda não estiver familiarizado com os conceitos de pesquisa vetorial no Elastic, talvez seja interessante primeiro conferir os seguintes recursos:

  • Navegando em um banco de dados de vetores elásticos

  • As grandes ideias por trás da geração aumentada de recuperação

Implementação de Quantização Binária Aprimorada (BBQ)

Para manter este blog simples, você usará funções integradas quando elas estiverem disponíveis. Neste caso, você tem o modelo de incorporação vetorial .multilingual-e5-small que será executado diretamente dentro do Elasticsearch em um nó de aprendizado de máquina. Observe que você pode substituir o modelo text_embedding pelo incorporador de sua escolha (OpenAI, Google AI Studio, Cohere e muitos outros). Se o seu modelo preferido ainda não estiver integrado, você também pode trazer seus próprios embeddings de vetores densos.)

Primeiro, você precisará criar um ponto final de inferência para gerar vetores para um determinado trecho de texto. Você executará todos esses comandos no Kibana Dev Tools Console. Este comando fará o download do .multilingual-e5-small. Se ainda não existir, ele configurará seu endpoint; isso pode levar um minuto para ser executado. Você pode ver a saída esperada no arquivo 01-create-an-inference-endpoint-output.json na pasta Saídas.

Quando isso retornar, seu modelo será configurado e você poderá testar se ele funciona conforme o esperado com o seguinte comando. Você pode ver a saída esperada no arquivo 02-embed-text-output.json na pasta Saídas.

Se você tiver problemas com seu modelo treinado não sendo alocado a nenhum nó, talvez seja necessário iniciar seu modelo manualmente.

Agora vamos criar um novo mapeamento com 2 propriedades, um campo de texto padrão (my_field) e um campo vetorial denso (my_vector) com 384 dimensões para corresponder à saída do modelo de incorporação. Você também substituirá o index_options.type to bbq_hnsw. Você pode ver a saída esperada no arquivo 03-create-byte-qauntized-index-output.json na pasta Saídas.

Para garantir que o Elasticsearch gere seus vetores, você pode usar um Ingest Pipeline. Este pipeline exigirá 3 coisas: o ponto final, (model_id), o input_field para o qual você deseja criar vetores e o output_field para armazenar esses vetores. O primeiro comando abaixo criará um pipeline de ingestão de inferência, que usa o serviço de inferência nos bastidores, e o segundo testará se o pipeline está funcionando corretamente. Você pode ver a saída esperada no arquivo 04-create-and-simulate-ingest-pipeline-output.json na pasta Outputs. 

Agora você está pronto para adicionar alguns documentos com os dois primeiros comandos abaixo e testar se suas pesquisas funcionam com o terceiro comando. Você pode verificar a saída esperada no arquivo 05-bbq-index-output.json na pasta Outputs. 

Conforme recomendado nesta publicação, a repontuação e a sobreamostragem são recomendadas quando você dimensiona para quantidades não triviais de dados porque elas ajudam a manter alta precisão de recall enquanto se beneficiam das vantagens da compressão. A partir da versão 8.18 do Elasticsearch, você pode fazer isso dessa maneira usando rescore_vector. A saída esperada está no arquivo 06-bbq-search-8-18-output.json na pasta Outputs.

Como essas pontuações se comparam àquelas que você obteria com dados brutos? Se você fizer tudo acima novamente, mas com index_options.type: hnsw, verá que as pontuações são muito comparáveis. Você pode ver a saída esperada no arquivo 07-raw-vector-output.json na pasta Outputs.

Números aproximados sobre as taxas de compressão

Os requisitos de armazenamento e memória podem rapidamente se tornar um desafio significativo ao trabalhar com pesquisa vetorial. A análise a seguir ilustra como diferentes técnicas de quantização reduzem drasticamente o consumo de memória de dados vetoriais.

Vetores (V)

Dimensões (D)

cru (V x D x 4)

int8 (V x (D x 1 + 4))

int4 (V x (D x 0,5 + 4))

churrasco (V x (D x 0,125 + 4))

10.000.000

384

14,31 GB

3,61 GB

1,83 GB

0,58 GB

50.000.000

384

71,53 GB

18,07 GB

9,13 GB

2,89 GB

100.000.000

384

143,05 GB

36,14 GB

18,25 GB

5,77 GB

Conclusão

BBQ é uma otimização que você pode aplicar aos seus dados vetoriais para compressão sem sacrificar a precisão. Ele funciona convertendo vetores em bits, permitindo que você pesquise os dados de forma eficaz e capacitando você a dimensionar seus fluxos de trabalho de IA para acelerar pesquisas e otimizar o armazenamento de dados.

Aprendizagem adicional

Se você estiver interessado em aprender mais sobre churrasco, não deixe de conferir os seguintes recursos:

• Quantização Binária (BBQ) em Lucene e Elasticsearch

• Melhor Quantização Binária (BBQ) vs. Quantização de Produto

• Quantização Escalar Otimizada: Quantização Binária Ainda Melhor

• Melhor Quantização Binária (BBQ): De Bytes a BBQ, O Segredo para uma Melhor Busca Vetorial por Ben Trent

Confronto de quantização binária

Armazenar vetores de alta dimensão em sua forma original pode exigir muita memória. Técnicas de quantização comprimem esses vetores em uma representação compacta, reduzindo drasticamente o consumo de memória. A busca então opera no espaço comprimido, o que reduz a complexidade computacional e torna as buscas mais rápidas, especialmente em grandes conjuntos de dados.

A Elastic está empenhada em fazer do Lucene um mecanismo vetorial de alto desempenho. Introduzimos a Quantização Binária Aprimorada (BBQ) no Elasticsearch 8.16, com base no Lucene, e aprimoramos ainda mais nas versões 8.18 e 9.0. O BBQ é baseado em uma nova abordagem de quantização escalar que reduz as dimensões de ponto flutuante de 32 bits, proporcionando uma redução de memória de aproximadamente 95%, mantendo uma alta qualidade de classificação.

O OpenSearch, por outro lado, usa vários mecanismos de vetores: nmslib (agora obsoleto), Lucene e FAISS. Em um blog anterior, comparamos o Elasticsearch e o OpenSearch para pesquisa vetorial. Usamos três conjuntos de dados diferentes e testamos diferentes combinações de mecanismos e configurações em ambos os produtos.

Este blog se concentra nos algoritmos de quantização binária atualmente disponíveis em ambos os produtos. Testamos o Elasticsearch com BBQ e o OpenSearch com a Quantização Binária do FAISS usando a trilha Rally openai_vector .

O objetivo principal era avaliar o desempenho de ambas as soluções sob o mesmo nível de recall. O que significa recall ? Recall é uma métrica que mede quantos resultados relevantes são recuperados com sucesso por um sistema de pesquisa.

Nesta avaliação, recall@k é particularmente importante, onde k representa o número de resultados principais considerados. Recall@10, Recall@50 e Recall@100 medem, portanto, quantos dos resultados verdadeiramente relevantes aparecem nos 10, 50 e 100 principais itens recuperados, respectivamente. A recordação é expressa em uma escala de 0 a 1 (ou precisão de 0% a 100%). E isso é importante porque estamos falando de KNN Aproximado (ANN) e não de KNN Exato, onde a recordação é sempre 1 (100%).

Para cada valor de k também especificamos n, que é o número de candidatos considerados antes de aplicar a classificação final. Isso significa que para Recall@10, Recall@50 e Recall@100, o sistema primeiro recupera n candidatos usando o algoritmo de quantização binária e depois os classifica para determinar se os k principais resultados contêm os itens relevantes esperados.

Ao controlar n, podemos analisar o trade-off entre eficiência e precisão. Um n mais alto normalmente aumenta a recuperação, pois mais candidatos estão disponíveis para classificação, mas também aumenta a latência e diminui a taxa de transferência. Por outro lado, um n menor acelera a recuperação, mas pode reduzir a recordação se poucos candidatos relevantes forem incluídos no conjunto inicial.

Nesta comparação, o Elasticsearch demonstrou menor latência e maior rendimento que o OpenSearch em configurações idênticas.

Metodologia

A configuração completa, juntamente com os scripts do Terraform, os manifestos do Kubernetes e a trilha Rally específica estão disponíveis neste repositório em openai_vector_bq.

Assim como nos benchmarks anteriores, usamos um cluster Kubernetes composto por:

• 1 pool de nós para Elasticsearch 9.0 com 3 máquinas e2-standard-32 (128 GB de RAM e 32 CPUs)

• 1 pool de nós para OpenSearch 2.19 com 3 máquinas e2-standard-32 (128 GB de RAM e 32 CPUs)

• 1 pool de nós para Rally com 2 máquinas e2-standard-4 (16 GB de RAM e 4 CPUs)

Configuramos um cluster Elasticsearch versão 9.0 e um cluster OpenSearch versão 2.19.

Tanto o Elasticsearch quanto o OpenSearch foram testados com exatamente a mesma configuração: usamos o Rally track openai_vector com algumas modificações , que usa 2,5 milhões de documentos do conjunto de dados NQ enriquecidos com embeddings gerados usando o modelo text-embedding-ada-002 do OpenAI.

Os resultados relatam a latência e a taxa de transferência medidas em diferentes níveis de recall (recall@10, recall@50 e recall@100) usando 8 clientes simultâneos para executar operações de pesquisa. Usamos um único fragmento e nenhuma réplica.

Executamos as seguintes combinações de kn-rescore, por exemplo 10-2000-2000, ou k:10, n:2000 e rescore:2000 recuperariam os k (10) principais sobre n candidatos (2000) aplicando uma rescore sobre 2000 resultados (o que é equivalente a um “fator de sobreamostragem” de 1). Cada pesquisa foi executada 10.000 vezes, com 1.000 pesquisas como aquecimento:

Recall@10

• 10-40-40

• 10-50-50

• 10-100-100

• 10-200-200

• 10-500-500

• 10-750-750

• 10-1000-1000

• 10-1500-1500

• 10-2000-2000

Recall@50

• 50-150-150

• 50-200-200

• 50-250-250

• 50-500-500

• 50-750-750

• 50-1000-1000

• 50-1200-1200

• 50-1500-1500

• 50-2000-2000

Lembre-se @100

• 100-200-200

• 100-250-250

• 100-300-300

• 100-500-500

• 100-750-750

• 100-1000-1000

• 100-1200-1200

• 100-1500-1500

• 100-2000-2000

Para replicar o benchmark, os manifestos do Kubernetes para rally-elasticsearch e rally-opensearch têm todas as variáveis relevantes externalizadas em um ConfigMap, disponível aqui (ES) e aqui (OS). O parâmetro search_ops pode ser personalizado para testar qualquer combinação de k, n e rescore.

Configuração do OpenSearch Rally

/k8s/rally-openai_vector-os-bq.yml

Configuração do índice Opensearch

As variáveis do ConfigMap são então usadas na configuração do índice, alguns parâmetros são deixados inalterados. A quantização de 1 bit no OpenSearch é configurada definindo o nível de compressão como “32x”.

index-vectors-only-mapping-with-docid-mapping.json

Configuração do Elasticsearch Rally

/k8s/rally-openai_vector-es-bq.yml

Configuração do índice do Elasticsearch

index-vectors-only-mapping-with-docid-mapping.json

Resultados

Há várias maneiras de interpretar os resultados. Tanto para latência quanto para taxa de transferência, criamos um gráfico simplificado e detalhado em cada nível de recall. É fácil ver diferenças se considerarmos “quanto maior, melhor” para cada métrica. No entanto, a latência é negativa (quanto menor, melhor), enquanto a taxa de transferência é positiva. Para os gráficos simplificados, usamos (recall / latência) * 10000 (chamado simplesmente de “velocidade”) e recall * throughput, então ambas as métricas significam que mais velocidade e mais throughput são melhores. Vamos lá.

Recall @ 10 - simplificado

Nesse nível de recall, o Elasticsearch BBQ é até 5x mais rápido (3,9x mais rápido em média) e tem 3,2x mais taxa de transferência em média do que o OpenSearch FAISS.

Recall @ 10 - Detalhado

tarefa

latência.média

rendimento.média

recuperação média

Elasticsearch-9.0-BBQ

10-100-100

11,70

513,58

0,89

Elasticsearch-9.0-BBQ

10-1000-100

27,33

250,55

0,95

Elasticsearch-9.0-BBQ

10-1500-1500

35,93

197,26

0,95

Elasticsearch-9.0-BBQ

10-200-200

13,33

456,16

0,92

Elasticsearch-9.0-BBQ

10-2000-2000

44,27

161,40

0,95

Elasticsearch-9.0-BBQ

10-40-40

10,97

539,94

0,84

Elasticsearch-9.0-BBQ

10-50-50

11h00

535,73

0,85

Elasticsearch-9.0-BBQ

10-500-500

19,52

341,45

0,93

Elasticsearch-9.0-BBQ

10-750-750

22,94

295,19

0,94

OpenSearch-2.19-faiss

10-100-100

35,59

200,61

0,94

OpenSearch-2.19-faiss

10-1000-1000

156,81

58,30

0,96

OpenSearch-2.19-faiss

10-1500-1500

181,79

42,97

0,96

OpenSearch-2.19-faiss

10-200-200

47,91

155,16

0,95

OpenSearch-2.19-faiss

10-2000-2000

232,14

31,84

0,96

OpenSearch-2.19-faiss

10-40-40

27,55

249,25

0,92

OpenSearch-2.19-faiss

10-50-50

28,78

245,14

0,92

OpenSearch-2.19-faiss

10-500-500

79,44

97,06

0,96

OpenSearch-2.19-faiss

10-750-750

104,19

75,49

0,96

Recall @ 50 - simplificado

Nesse nível de recall, o Elasticsearch BBQ é até 5x mais rápido (4,2x mais rápido em média) e tem 3,9x mais rendimento em médiado que o OpenSearch FAISS.

Resultados detalhados - Recall @ 50

Tarefa

Média de latência

Média de rendimento

Recall médio

Elasticsearch-9.0-BBQ

50-1000-1000

25,71

246,44

0,95

Elasticsearch-9.0-BBQ

50-1200-1200

28,81

227,85

0,95

Elasticsearch-9.0-BBQ

50-150-150

13,43

362,90

0,90

Elasticsearch-9.0-BBQ

50-1500-1500

33,38

202,37

0,95

Elasticsearch-9.0-BBQ

50-200-200

12,99

406,30

0,91

Elasticsearch-9.0-BBQ

50-2000-2000

42,63

163,68

0,95

Elasticsearch-9.0-BBQ

50-250-250

14,41

373,21

0,92

Elasticsearch-9.0-BBQ

50-500-500

17h15

341,04

0,93

Elasticsearch-9.0-BBQ

50-750-750

31,25

248,60

0,94

OpenSearch-2.19-faiss

50-1000-1000

125,35

62,53

0,96

OpenSearch-2.19-faiss

50-1200-1200

143,87

54,75

0,96

OpenSearch-2.19-faiss

50-150-150

43,64

130,01

0,89

OpenSearch-2.19-faiss

50-1500-1500

169,45

46,35

0,96

OpenSearch-2.19-faiss

50-200-200

48,05

156,07

0,91

OpenSearch-2.19-faiss

50-2000-2000

216,73

36,38

0,96

OpenSearch-2.19-faiss

50-250-250

53,52

142,44

0,93

OpenSearch-2.19-faiss

50-500-500

78,98

97,82

0,95

OpenSearch-2.19-faiss

50-750-750

103,20

75,86

0,96

Recall @ 100

Nesse nível de recall, o Elasticsearch BBQ é até 5x mais rápido (média de 4,6x mais rápido) e tem 3,9x mais taxa de transferência em média do que o OpenSearch FAISS.

Resultados detalhados - Recall @ 100

tarefa

latência.média

rendimento.média

recuperação média

Elasticsearch-9.0-BBQ

100-1000-1000

27,82

243,22

0,95

Elasticsearch-9.0-BBQ

100-1200-1200

31.14

224.04

0,95

Elasticsearch-9.0-BBQ

100-1500-1500

35,98

193,99

0,95

Elasticsearch-9.0-BBQ

100-200-200

14.18

403,86

0,88

Elasticsearch-9.0-BBQ

100-2000-2000

45,36

159,88

0,95

Elasticsearch-9.0-BBQ

100-250-250

14,77

433,06

0,90

Elasticsearch-9.0-BBQ

100-300-300

14,61

375,54

0,91

Elasticsearch-9.0-BBQ

100-500-500

18,88

340,37

0,93

Elasticsearch-9.0-BBQ

100-750-750

23,59

285,79

0,94

OpenSearch-2.19-faiss

100-1000-1000

142,90

58,48

0,95

OpenSearch-2.19-faiss

100-1200-1200

153,03

51,04

0,95

OpenSearch-2.19-faiss

100-1500-1500

181,79

43,20

0,96

OpenSearch-2.19-faiss

100-200-200

50,94

131,62

0,83

OpenSearch-2.19-faiss

100-2000-2000

232,53

33,67

0,96

OpenSearch-2.19-faiss

100-250-250

57,08

131,23

0,87

OpenSearch-2.19-faiss

100-300-300

62,76

120,10

0,89

OpenSearch-2.19-faiss

100-500-500

84,36

91,54

0,93

OpenSearch-2.19-faiss

100-750-750

111,33

69,95

0,94

Melhorias no churrasco

BBQ percorreu um longo caminho desde seu primeiro lançamento. No Elasticsearch 8.16, para fins de comparação, incluímos uma execução de benchmark da versão 8.16 junto com a atual, e podemos ver como a recuperação e a latência melhoraram desde então.

No Elasticsearch 8.18 e 9.0, reescrevemos o algoritmo principal para quantizar os vetores. Então, embora o BBQ na versão 8.16 fosse bom, as versões mais recentes são ainda melhores. Você pode ler sobre isso aqui e aqui. Em resumo, cada vetor é quantizado individualmente por meio de quantis escalares otimizados. Como resultado, os usuários se beneficiam de maior precisão na pesquisa de vetores sem comprometer o desempenho, tornando a recuperação de vetores do Elasticsearch ainda mais poderosa.

Conclusão

Nesta comparação de desempenho entre o Elasticsearch BBQ e o OpenSearch FAISS, o Elasticsearch supera significativamente o OpenSearch para pesquisa vetorial, alcançando velocidades de consulta até 5x mais rápidas e uma taxa de transferência 3,9x maior, em média, em vários níveis de recuperação.

As principais descobertas incluem:

• Recall@10: O Elasticsearch BBQ é até 5x mais rápido (3,9x mais rápido em média) e tem 3,2x mais taxa de transferência em média em comparação ao OpenSearch FAISS.

• Recall@50: O Elasticsearch BBQ é até 5x mais rápido (4,2x mais rápido em média) e tem 3,9x mais taxa de transferência em média em comparação ao OpenSearch FAISS.

• Recall@100: O Elasticsearch BBQ é até 5x mais rápido (4,6x mais rápido em média) e tem 3,9x mais taxa de transferência em média em comparação ao OpenSearch FAISS.

Esses resultados destacam as vantagens de eficiência e desempenho do Elasticsearch BBQ, particularmente em cenários de pesquisa vetorial de alta dimensão. A técnica Better Binary Quantization (BBQ), introduzida no Elasticsearch 8.16, proporciona redução substancial de memória (~95%) enquanto mantém alta qualidade de classificação, tornando-a uma escolha superior para aplicações de pesquisa vetorial em larga escala.

Na Elastic, estamos inovando incansavelmente para melhorar o Apache Lucene e o Elasticsearch para fornecer o melhor banco de dados vetorial para casos de uso de pesquisa e recuperação, incluindo RAG (Retrieval Augmented Generation). Nossos avanços recentes aumentaram drasticamente o desempenho, tornando a pesquisa vetorial mais rápida e mais eficiente em termos de espaço do que antes, aproveitando os ganhos do Lucene 10. Este blog é outra ilustração dessa inovação.

Os desenvolvedores agora podem criar seus aplicativos RAG em uma jornada unificada, fundamentando suas experiências de bate-papo em seus dados privados de maneira flexível e com pouco código. Seja para criar agentes de IA para seus clientes e funcionários internos ou para aproveitar a geração de LLMs (Modelos de Aprendizagem Baseados em Aprendizagem) em seu software, a plataforma Vertex AI coloca a relevância do Elasticsearch ao seu alcance com configuração mínima. Essa integração permite uma adoção mais fácil e rápida dos modelos Gemini em casos de uso de produção, levando o GenAI de provas de conceito a cenários da vida real.

Neste blog, mostraremos como integrar o Elasticsearch com a plataforma Vertex AI do Google Cloud para obter uma base de dados perfeita e criar aplicativos GenAI totalmente personalizáveis. Vamos descobrir como.

Os modelos Vertex AI e Gemini do Google Cloud são baseados nos seus dados com o Elasticsearch.

Usuários que utilizam serviços e ferramentas da Vertex AI para criar aplicativos GenAI agora podem acessar a nova opção “Grounding” para trazer seus dados privados para suas interações de conversação automaticamente. O Elasticsearch agora faz parte desse recurso e pode ser usado por meio de:

• APIs LLM da Vertex AI, que enriquecem diretamente os modelos Gemini do Google no momento da geração (preferencial);

• API Grounded Generation, usada no ecossistema Vertex AI Agent Builder para criar experiências de agente.

Com essa integração, o Elasticsearch — o banco de dados vetorial mais baixado e implantado — levará seus dados empresariais relevantes para onde forem necessários em seus chats internos com clientes finais, o que é crucial para a adoção real do GenAI em processos de negócios.

As APIs mencionadas permitirão que os desenvolvedores adotem esse novo recurso de parceria em seu código. No entanto, a engenharia e os testes rápidos continuam sendo etapas cruciais no desenvolvimento do aplicativo e servem como um playground de descoberta inicial. Para dar suporte a isso, o Elasticsearch foi projetado para fácil avaliação pelos usuários na ferramenta de console do Vertex AI Studio.

Bastam alguns passos simples para configurar os endpoints do Elastic com os parâmetros desejados (índice a ser pesquisado, número de documentos a serem recuperados e modelo de pesquisa desejado) na aba “Personalizar aterramento” na interface do usuário, conforme mostrado abaixo (observe que, para que isso funcione, você precisa digitar a chave da API com a palavra "ApiKey" na interface do usuário e nos exemplos de código abaixo). Agora você está pronto para gerar com seu conhecimento privado!

Aplicações GenAI prontas para produção com facilidade

A Elastic e o Google Cloud trabalham para proporcionar experiências completas, agradáveis e voltadas para o desenvolvedor. A conexão nativa ao Elastic no LLM e na Grounding Generation API reduz a complexidade e a sobrecarga ao criar aplicativos GAI no Vertex AI, evitando APIs adicionais desnecessárias e orquestração de dados durante o aterramento em apenas uma chamada unificada.

Vamos ver como isso funciona em ambos os cenários.

O primeiro exemplo é executado com a API LLM:

No exemplo acima, com o campo retrieval da API solicitando geração de conteúdo para o Gemini 2.0 Flash, podemos definir contextualmente um mecanismo de recuperação para a solicitação. Definir api_spec como “ELASTIC_SEARCH” permite o uso de parâmetros de configuração adicionais, como a chave de API e o ponto de extremidade do cluster (necessário para rotear uma solicitação para seu cluster Elastic), o índice do qual recuperar dados e o modelo de pesquisa a ser usado para sua lógica de pesquisa.

Da mesma forma, o mesmo resultado pode ser alcançado com a API Grounding Generation, definindo o parâmetro groundingSpec :

Com ambas as abordagens, a resposta fornecerá uma resposta com os documentos privados mais relevantes encontrados no Elasticsearch – e as fontes de dados conectadas relacionadas – para dar suporte à sua consulta.

Simplicidade, no entanto, não deve ser confundida com falta de personalização para atender às suas necessidades e casos de uso específicos. Pensando nisso, nós o projetamos para permitir que você adapte perfeitamente a configuração de pesquisa ao seu cenário.

Pesquisa totalmente personalizável na ponta dos dedos: modelos de pesquisa

Para fornecer a máxima personalização ao seu cenário de pesquisa, criamos, em colaboração com o Google Cloud, a experiência com base em nossos conhecidos Modelos de Pesquisa. Os modelos de pesquisa do Elasticsearch são uma excelente ferramenta para criar consultas de pesquisa dinâmicas, reutilizáveis e fáceis de manter. Eles permitem que você predefina e reutilize estruturas de consulta. Eles são particularmente úteis ao executar consultas semelhantes com parâmetros diferentes, pois economizam tempo de desenvolvimento e reduzem a chance de erros. Os modelos podem incluir espaços reservados para variáveis, tornando as consultas dinâmicas e adaptáveis a diferentes requisitos de pesquisa.

Ao usar as APIs do Vertex AI e o Elasticsearch para aterramento, você deve referenciar um modelo de pesquisa desejado — conforme mostrado nos trechos de código acima — onde a lógica de pesquisa é implementada e enviada ao Elasticsearch. Usuários avançados do Elastic podem gerenciar, configurar e atualizar de forma assíncrona as abordagens de pesquisa e adaptá-las aos índices, modelos e dados específicos de forma totalmente transparente para usuários do Vertex AI, desenvolvedores de aplicativos da web ou engenheiros de IA, que precisam apenas especificar o nome do modelo na API de aterramento.

Este design permite personalização completa, colocando os amplos recursos de recuperação do Elasticsearch à sua disposição em um ambiente de IA do Google Cloud, ao mesmo tempo em que garante modularidade, transparência e facilidade de uso para diferentes desenvolvedores, mesmo aqueles não familiarizados com o Elastic.

Sempre que você precisar de pesquisa BM25, pesquisa semântica ou uma abordagem híbrida entre as duas (você já explorou os recuperadores ? Técnicas de recuperação componíveis em uma única chamada de API de pesquisa), você pode definir sua lógica personalizada em um modelo de pesquisa, que o Vertex AI pode aproveitar automaticamente.

Isso também se aplica a incorporações e modelos de reclassificação que você escolhe para gerenciar vetores e resultados. Dependendo do seu caso de uso, você pode hospedar modelos nos nós de ML da Elastic, usar um ponto de extremidade de serviço de terceiros por meio da API de Inferência ou executar seu modelo local no local. Isso pode ser feito por meio de um modelo de pesquisa, e veremos como funciona na próxima seção.

Comece com modelos de referência e depois crie os seus próprios

Para ajudar você a começar rapidamente, fornecemos um conjunto de exemplos de modelos de pesquisa compatíveis para serem usados como referência inicial; você pode então modificar e criar seus próprios modelos personalizados com base em:

• Busca Semântica com modelo ELSER (vetores esparsos e fragmentação)

• Pesquisa semântica com modelo multilíngue e5 (vetores densos e fragmentação)

• Pesquisa híbrida com modelo de incorporação de texto Vertex AI

Você pode encontrá-los neste repositório do GitHub.

Vejamos um exemplo: criar embeddings com as APIs Vertex AI do Google Cloud em um catálogo de produtos. Primeiro, precisamos criar o modelo de pesquisa no Elasticsearch, conforme mostrado abaixo:

Neste exemplo, executaremos a pesquisa KNN em dois campos dentro de uma única pesquisa: title_embedding – o campo vetorial que contém o nome do produto – e description_embedding – aquele que contém a representação de sua descrição.

Você pode aproveitar a sintaxe excludes para evitar retornar campos desnecessários ao LLM, o que pode causar ruído em seu processamento e afetar a qualidade da resposta final. Em nosso exemplo, excluímos os campos contendo vetores e URLs de imagens.

Os vetores são criados dinamicamente no momento da consulta na entrada enviada por meio de um ponto de extremidade de inferência para a API de incorporação do Vertex AI, googlevertexai_embeddings_004, definida anteriormente da seguinte forma:

Você pode encontrar informações adicionais sobre como usar a API de Inferência da Elastic aqui.

Agora estamos prontos para testar nossa pesquisa de modelo:

Os campos params substituirão as variáveis que definimos nos scripts de modelo entre colchetes duplos. Atualmente, as APIs Vertex AI LLM e Grounded Generation podem enviar ao Elastic as seguintes variáveis de entrada:

• “consulta” - a consulta do usuário a ser pesquisada

• “index_name” - o nome do índice onde pesquisar

• “num_hits” - quantos documentos queremos recuperar na saída final

Aqui está um exemplo de saída:

A consulta acima é exatamente o que o Vertex AI do Google Cloud executará no Elasticsearch nos bastidores ao consultar o modelo de pesquisa criado anteriormente. Os modelos Gemini usarão os documentos de saída para fundamentar sua resposta: quando você perguntar "O que preciso para consertar minha parede de gesso?" em vez de receber uma sugestão genérica, o agente de chat fornecerá produtos específicos!

Jornada GenAI de ponta a ponta com Elastic e Google Cloud

A Elastic faz parceria com o Google Cloud para criar experiências e soluções GenAI completas e prontas para produção. Como acabamos de ver, o Elastic é o primeiro ISV a ser integrado diretamente à interface do usuário e ao SDK da plataforma Vertex AI, permitindo prompts e agentes de modelos Gemini integrados e fundamentados usando nossos recursos de pesquisa de vetores. Além disso, o Elastic integra-se aos modelos de incorporação, reclassificação e conclusão do Vertex AI e do Google AI Studiopara criar e classificar vetores sem sair do cenário do Google Cloud, garantindo os princípios da IA responsável . Ao oferecer suporte a abordagens multimodais, facilitamos conjuntamente aplicações em diversos formatos de dados.

Você pode ajustar, testar e exportar seu código de pesquisa GenAI por meio do nosso Playground.

Mas não se trata apenas de criar aplicativos de pesquisa: a Elastic utiliza os modelos Gemini para fortalecer as operações de TI, como nos recursos Elastic AI Assistants, Attack Discovery e Automatic Import, reduzindo a fadiga diária de analistas de segurança e SREs em tarefas de baixo valor e permitindo que eles se concentrem em melhorar seus negócios. O Elastic também permite o monitoramento abrangente do uso do Vertex AI, rastreando métricas e logs, como tempos de resposta, tokens e recursos, para garantir o desempenho ideal. Juntos, gerenciamos o ciclo de vida completo do GenAI, desde a ingestão de dados e geração de incorporação até a consolidação com pesquisa híbrida, ao mesmo tempo em que garantimos a observabilidade e a segurança robustas das ferramentas GenAI com ações baseadas em LLM.

Explore mais e experimente!

Você está interessado em experimentar isso? O recurso está atualmente disponível em seus projetos do Google Cloud!

Se você ainda não o fez, uma das maneiras mais fáceis de começar a usar o Elastic Search AI Platform e explorar nossos recursos é com seu teste gratuito do Elastic Cloud ou assinando pelo Google Cloud Marketplace.

O lançamento e o cronograma de quaisquer recursos ou funcionalidades descritos nesta publicação permanecem a critério exclusivo da Elastic. Quaisquer recursos ou funcionalidades não disponíveis no momento podem não ser entregues no prazo ou não serem entregues. Elastic, Elasticsearch e marcas associadas são marcas comerciais, logotipos ou marcas registradas da Elasticsearch NV nos Estados Unidos e em outros países. Todos os outros nomes de empresas e produtos são marcas comerciais, logotipos ou marcas registradas de seus respectivos proprietários.

Você pode perguntar: por que usar vários gráficos? Este é um efeito colateral de uma escolha arquitetônica no Lucene: segmentos imutáveis. Como acontece com a maioria das escolhas arquitetônicas, há prós e contras. Por exemplo, recentemente disponibilizamos o Elasticsearch sem servidor. Nesse contexto, obtivemos benefícios muito significativos de segmentos imutáveis, incluindo replicação de índice eficiente e a capacidade de desacoplar índice e computação de consulta e dimensioná-los automaticamente de forma independente. Para quantização vetorial, as fusões de segmentos nos dão a oportunidade de atualizar parâmetros para adaptá-los às características dos dados. Nessa linha, acreditamos que há outras vantagens proporcionadas pela oportunidade de medir características de dados e revisitar opções de indexação.

Nesta postagem, discutiremos o trabalho que temos feito para reduzir significativamente a sobrecarga de construção de vários gráficos HNSW e, em particular, para reduzir o custo de mesclagem de gráficos.

Histórico

Para manter um número gerenciável de segmentos, o Lucene verifica periodicamente se deve mesclar segmentos. Isso equivale a verificar se a contagem de segmentos atual excede uma contagem de segmentos de destino, que é determinada pelo tamanho do segmento base e pela política de mesclagem. Se a contagem for excedida, o Lucene mescla grupos de segmentos enquanto a restrição for violada. Este processo foi descrito em detalhes em outro lugar.

Lucene opta por mesclar segmentos de tamanhos semelhantes porque isso atinge um crescimento logarítmico na amplificação de gravação. No caso de um índice vetorial, a amplificação de escrita é o número de vezes que um vetor será inserido em um gráfico. O Lucene tentará mesclar segmentos em grupos de aproximadamente 10. Consequentemente, os vetores são inseridos em um gráfico aproximadamente vezes, onde é a contagem do vetor de índice e é a contagem do vetor de segmento base esperado. Devido ao crescimento logarítmico, a amplificação da gravação é de um dígito, mesmo para índices grandes. Entretanto, o tempo total gasto na fusão de gráficos é linearmente proporcional à amplificação da gravação.

Ao mesclar gráficos HNSW, já fazemos uma pequena otimização: mantendo o gráfico do maior segmento e inserindo vetores dos outros segmentos nele. Esta é a razão do fator 9/10 acima. Abaixo mostramos como podemos melhorar significativamente usando informações de todos os gráficos que estamos mesclando.

Fusão de gráficos HNSW

Anteriormente, mantínhamos o grafo maior e inseríamos vetores dos demais, ignorando os grafos que os continham. A principal conclusão que utilizamos a seguir é que cada grafo HNSW descartado contém informações importantes sobre a proximidade dos vetores que ele contém. Gostaríamos de usar essas informações para acelerar a inserção, pelo menos de alguns, dos vetores.

Nós nos concentramos no problema de inserir um gráfico menor em um gráfico maior , já que esta é uma operação atômica que podemos usar para construir qualquer política de mesclagem.

A estratégia é encontrar um subconjunto de vértices de para inserir no gráfico grande. Em seguida, usamos a conectividade desses vértices no pequeno gráfico para acelerar a inserção dos vértices restantes . A seguir, usamos e para denotar os vizinhos de um vértice no gráfico pequeno e grande, respectivamente. Esquematicamente o processo é o seguinte.

MERGE-HNSW

Inputs and

1Find to insert into using COMPUTE-JOIN-SET 2Insert each vertex into 3for do 4 5 6FAST-SEARCH-LAYER 7SELECT-NEIGHBORS-HEURISTIC 8

Calculamos o conjunto usando um procedimento que discutiremos abaixo (linha 1). Em seguida, inserimos cada vértice em no gráfico grande usando o procedimento de inserção padrão HNSW (linha 2). Para cada vértice que não inserimos, encontramos seus vizinhos que inserimos e seus vizinhos no gráfico grande (linhas 4 e 5). Usamos um procedimento FAST-SEARCH-LAYER semeado com este conjunto (linha 6) para encontrar os candidatos para o SELECT-NEIGHBORS-HEURISTIC do artigo HNSW (linha 7). Na verdade, estamos substituindo SEARCH-LAYER para encontrar o conjunto de candidatos no método INSERT (Algoritmo 1 do artigo), que de outra forma não será alterado. Por fim, adicionamos o vértice que acabamos de inserir em (linha 8).

É claro que para que isso funcione, cada vértice em deve ter pelo menos um vizinho em . Na verdade, exigimos que para cada vértice em que para algum , a conectividade máxima da camada. Observamos que em gráficos HNSW reais vemos uma grande dispersão de graus de vértices. A figura abaixo mostra uma função de densidade cumulativa típica do grau do vértice para a camada inferior de um gráfico Lucene HNSW.

Exploramos o uso de um valor fixo para e também o tornamos uma função do grau do vértice. Esta segunda opção leva a maiores acelerações com impacto mínimo na qualidade do gráfico, então optei pela seguinte opção

Observe que | é igual ao grau do vértice no gráfico pequeno por definição. Ter um limite inferior de dois significa que inseriremos todos os vértices cujo grau seja menor que dois.

Um argumento de contagem simples sugere que se escolhermos cuidadosamente, precisamos apenas inserir em torno de em diretamente. Especificamente, colorimos uma aresta do gráfico se inserirmos exatamente um de seus vértices finais em . Então sabemos que para cada vértice em ter pelo menos vizinhos em precisamos colorir pelo menos arestas. Além disso, esperamos que

Aqui, é o grau médio do vértice no pequeno gráfico. Para cada vértice colorimos no máximo arestas. Portanto, o número total de arestas que esperamos colorir é no máximo . Esperamos que, ao escolher cuidadosamente, possamos colorir perto desse número de arestas e, portanto, para cobrir todos os vértices, precisa satisfazer

Isso implica que .

Se SEARCH-LAYER dominar o tempo de execução, isso sugere que poderíamos atingir uma velocidade de até maior no tempo de mesclagem. Dado o crescimento logarítmico da amplificação de gravação, isso significa que mesmo para índices muito grandes, normalmente dobraríamos apenas o tempo de construção em comparação à construção de um gráfico.

O risco dessa estratégia é que prejudicamos a qualidade do gráfico. Inicialmente tentamos com um no-op FAST-SEARCH-LAYER. Descobrimos que isso degrada a qualidade do gráfico a ponto de a recuperação como função da latência ser impactada, principalmente ao mesclar em um único segmento. Em seguida, exploramos várias alternativas usando uma busca limitada do gráfico. No final, a escolha mais eficaz foi a mais simples. Use SEARCH-LAYER mas com um ef_construction baixo. Com essa parametrização conseguimos obter gráficos de excelente qualidade e ainda diminuir o tempo de mesclagem em pouco mais de 30% em média.

Calculando o conjunto de junção

Encontrar um bom conjunto de junção pode ser formulado como um problema de cobertura de grafos HNSW. Uma heurística gulosa é uma heurística simples e eficaz para aproximar coberturas ótimas de grafos. A abordagem que adotamos seleciona os vértices um de cada vez para adicionar a em ordem decrescente de ganho. O ganho é definido da seguinte forma:

Aqui, denota a contagem de vizinhos de um vetor em e é a função indicadora. O ganho inclui a mudança na contagem do vértice que adicionamos a , ou seja, , pois nos aproximamos do nosso objetivo adicionando um vértice menos coberto. O cálculo do ganho é ilustrado na figura abaixo para o vértice central laranja.

Mantemos o seguinte estado para cada vértice :

1. Seja velho,

2. Seu ganho ,

3. A contagem de vértices adjacentes em denotada por ,

4. Um número aleatório no intervalo [0,1] que é usado para desempate.

O pseudocódigo para calcular o conjunto de junções é o seguinte.

COMPUTE-JOIN-SET

Inputs

1 2 3for do 4 5 6 7while do 8 maximum gain vertex in 9Remove the state for from 10if is not stale then 11 12 13for do 14mark as stale if 15mark neighbors of stale if 16 17else 18 19if then 20 21return

Primeiro inicializamos o estado nas linhas 1-5.

Em cada iteração do loop principal, extraímos inicialmente o vértice de ganho máximo (linha 8), desfazendo empates aleatoriamente. Antes de fazer qualquer alteração, precisamos verificar se o ganho do vértice está obsoleto. Em particular, cada vez que adicionamos um vértice em , afetamos o ganho de outros vértices:

1. Como todos os seus vizinhos têm um vizinho adicional em seus ganhos podem mudar (linha 14)

2. Se algum dos seus vizinhos estiver agora totalmente coberto, os ganhos de todos os seus vizinhos podem mudar (linhas 14-16)

Nós recalculamos os ganhos de forma lenta, então só recalculamos o ganho de um vértice se quisermos inseri-lo em (linhas 18-20). Como os ganhos sempre diminuem, nunca podemos perder um vértice que devemos inserir.

Observe que precisamos apenas monitorar o ganho total de vértices que adicionamos a para determinar quando sair. Além disso, enquanto pelo menos um vértice terá ganho diferente de zero, então sempre progredimos.

Resultados

Realizamos experimentos em quatro conjuntos de dados que juntos abrangem nossas três métricas de distância suportadas (euclidiana, cosseno e produto interno):

1. quora-E5-small: 522931 documentos, 384 dimensões e usa similaridade de cosseno,

2. cohere-wikipedia-v2: 1 milhão de documentos, 768 dimensões e usa similaridade de cosseno,

3. gist: 1M documentos, 960 dimensões e utiliza distância euclidiana e

4. cohere-wikipedia-v3: 1 milhão de documentos, 1.024 dimensões e usa o produto interno máximo.

Para cada conjunto de dados, avaliamos dois níveis de quantização:

1. int8 – que usa um inteiro de 1 byte por dimensão e

2. Churrasco – que usa um único bit por dimensão.

Por fim, para cada experimento, avaliamos a qualidade da pesquisa em duas profundidades de recuperação e examinamos depois da construção do índice e depois da fusão forçada em um único segmento.

Em resumo, alcançamos acelerações substanciais e consistentes na indexação e mesclagem, mantendo a qualidade do gráfico e, consequentemente, o desempenho da pesquisa em todos os casos.

Experimento 1: quantização int8

As acelerações médias da linha de base até o candidato, as mudanças propostas, são:

Aceleração do tempo de índice: 1,28

Forçar aceleração de fusão: 1,72

Isso corresponde à seguinte repartição nos tempos de execução

Para completar, os horários exatos são

Índice

Mesclar

Conjunto de dados

linha de base

candidato

Criar

candidato

quora-E5-pequeno

112,41s

81,55s

113,81s

70,87s

wiki-cohere-v2

158,1s

122,95s

425,20s

239,28s

essência

141,82s

119,26s

536,07s

279,05s

wiki-cohere-v3

211,86s

168,22s

654,97s

414,12s

Abaixo, mostramos os gráficos de recall versus latência que comparam o candidato (linhas tracejadas) à linha de base em duas profundidades de recuperação: recall@10 e recall@100 para índices com vários segmentos (o resultado final da nossa estratégia de mesclagem padrão após indexar todos os vetores) e após a mesclagem forçada para um único segmento. Uma curva mais alta e mais à esquerda é melhor, o que significa maior recuperação com menor latência.

Como você pode ver, para índices de múltiplos segmentos, o candidato é melhor para o conjunto de dados Cohere v3 e um pouco pior, mas quase comparável, para todos os outros conjuntos de dados. Após a fusão em um único segmento, as curvas de recall são quase idênticas para todos os casos.

Experimento 2: quantização BBQ

As acelerações médias da linha de base até o candidato são:

Aceleração do tempo de índice: 1,33

Forçar aceleração de fusão: 1,34

Isso corresponde à seguinte repartição nos tempos de execução

Para completar, os horários exatos são

Índice

Mesclar

Conjunto de dados

linha de base

candidato

Criar

candidato

quora-E5-pequeno

70,71s

58,25s

59,38s

40,15s

wiki-cohere-v2

203,08s

142,27s

107,27s

85,68s

essência

110,35s

105,52s

323,66s

202,2s

wiki-cohere-v3

313,43s

190,63s

165,98s

159,95s

Para índices de múltiplos segmentos, o candidato é melhor para quase todos os conjuntos de dados, exceto o Cohere v2, onde a linha de base é ligeiramente melhor. Para os índices de segmento único, as curvas de recall são quase idênticas para todos os casos.

Conclusão

O algoritmo discutido neste blog estará disponível no próximo Lucene 10.2 e na versão do Elasticsearch baseada nele. Os usuários poderão aproveitar o desempenho de mesclagem aprimorado e o tempo reduzido de criação de índice nessas novas versões. Essa mudança faz parte do nosso esforço contínuo para tornar o Lucene e o Elasticsearch rápidos e eficientes para pesquisas vetoriais e híbridas.

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.

Como parte da nossa missão de não deixar nada para trás em termos de eficiência, estamos explorando oportunidades de aceleração com esses curiosos chips de computador, dos quais você provavelmente já ouviu falar: GPUs NVIDIA! (Sério, não é mesmo?).

Quando nos preocupamos com desempenho, temos vários espaços problemáticos a explorar: como indexar exponencialmente mais dados, como recuperar insights deles e como fazer isso quando seus modelos de ML estão envolvidos. Você deve conseguir aproveitar todos os benefícios disponíveis quando tiver GPUs.

Nesta postagem, mergulhamos em nossa colaboração com a equipe de pesquisa de vetores da NVIDIA enquanto exploramos a pesquisa de vetores acelerada por GPU no Elasticsearch. Este trabalho abre caminho para casos de uso em que os desenvolvedores podem usar uma combinação de GPUs e CPUs para aplicativos reais baseados no Elasticsearch. Tempos emocionantes!

GPUs Elasticsearch

Estamos felizes em compartilhar que a equipe de engenharia do Elasticsearch está ajudando a criar a experiência da API Java cuVS de código aberto para desenvolvedores, que expõe vinculações para algoritmos de pesquisa vetorial. Este trabalho aproveita nossa experiência anterior com a Panama FFI. O Elasticsearch e o Apache Lucene usam a API NVIDIA cuVS para criar o gráfico durante a indexação. Certo, vamos avançar; vamos voltar um pouco.

NVIDIA cuVS, uma biblioteca C++ de código aberto, está no centro desta colaboração. O objetivo é levar a aceleração da GPU para a pesquisa vetorial, fornecendo maior rendimento, menor latência e tempos de construção de índice mais rápidos. Mas o Elasticsearch e o Apache Lucene são escritos em Java; como isso funcionará?

Entre em contato com o lucene-cuvs e a colaboração Elastic-NVIDIA-SearchScale para trazê-lo ao ecossistema Lucene para explorar a pesquisa vetorial acelerada por GPU no Elasticsearch. Na versão recente do NVIDIA cuVS 25.02, adicionamos uma API Java para cuVS. A nova API é experimental e continuará evoluindo, mas atualmente está disponível para uso. Pode surgir a pergunta: as chamadas de funções nativas do Java não são lentas? Não mais! Estamos usando a nova Panama FFI (Foreign Function Interface) para as vinculações, que tem sobrecarga mínima para downcalls Java para nativos.

Já faz algum tempo que usamos o Panama FFI no Elasticsearch e no Lucene . É incrível! Mas... sempre tem um “mas”, não é mesmo? O FFI tem desafios de disponibilidade nas versões do Java. Superamos isso compilando a API do cuVS para o Java 21 e encapsulando a implementação em um jar de várias versões voltado para o Java 22. Isso permite o uso do cuVS Java diretamente no Lucene e no Elasticsearch.

Ok, agora que temos a API Java do cuVS, o que mais precisaríamos?

Um conto de dois algoritmos para CPU

O Elasticsearch oferece suporte ao algoritmo HNSW para pesquisa KNN aproximada e escalável. No entanto, para obter o máximo da GPU, usamos um algoritmo diferente, CAGRA [CUDA ANN GRAph], que foi projetado especificamente para os altos níveis de paralelismo oferecidos pela GPU.

Antes de entrarmos em como pretendemos adicionar suporte ao CAGRA, vamos ver como o Elasticsearch e o Lucene acessam dados de índice por meio de um “formato de codec”. Isso consiste em

1. a representação no disco,

2. as interfaces para leitura e escrita de dados,

3. e a maquinaria para lidar com a arquitetura baseada em segmentos do Lucene.

Estamos implementando um novo formato de vetor KNN (k-vizinhos mais próximos) que usa internamente a API Java do cuVS para indexar e pesquisar na GPU. A partir daqui, “analisamos” esse tipo de codec por meio dos mapeamentos do Elasticsearch para um tipo de campo no índice. Como resultado, suas consultas KNN existentes continuam funcionando independentemente de o índice de apoio estar usando um gráfico CAGRA ou HNSW. É claro que isso encobre muitos detalhes, que planejamos abordar em um blog futuro. A seguir está a arquitetura de alto nível para um Elasticsearch acelerado por GPU.

Este novo formato de codec tem como padrão o CAGRA. No entanto, ele também suporta a conversão de um gráfico CAGRA em um gráfico HNSW para pesquisa na CPU.

Indexação e pesquisa na GPU: tomando algumas decisões “essenciais”

Com a arquitetura sem estado do Elasticsearch Serverless, que separa indexação e pesquisa, agora há uma delimitação clara de responsabilidades. Selecionamos o melhor perfil de hardware para cumprir cada uma dessas responsabilidades independentes.

Esperamos que os usuários considerem duas estratégias principais de implantação:

1. Indexação e pesquisa na GPU: durante a indexação, crie um gráfico CAGRA e use-o durante a pesquisa — ideal quando uma pesquisa com latência extremamente baixa é necessária.

2. Indexar na GPU e pesquisar na CPU: durante a indexação, crie um gráfico CAGRA e converta-o em um gráfico HNSW. O gráfico HNSW é armazenado no índice, que pode ser usado posteriormente na CPU para pesquisa.

Essa flexibilidade oferece diferentes modelos de implantação, oferecendo compensações entre custo e desempenho. Por exemplo, um serviço de indexação pode usar GPU para criar e mesclar gráficos de forma eficiente e oportuna, enquanto usa uma CPU de menor potência para pesquisa.

Então aqui está o plano para pesquisa vetorial acelerada por GPU no Elasticsearch

Estamos ansiosos para oferecer ganhos de desempenho e flexibilidade com estratégias de implantação aos usuários, oferecendo vários botões para equilibrar custo e desempenho. Aqui está a sessão do NVIDIA GTC 2025 onde este trabalho foi apresentado em detalhes.

Gostaríamos de agradecer às equipes de engenharia da NVIDIA e da SearchScale pela fantástica colaboração. Em um próximo blog, exploraremos os detalhes da implementação e a análise de desempenho com mais profundidade. Segurem seus chapéus de curiosidade 🎩!

Esta primeira parte tem como objetivo fornecer uma introdução geral aos conceitos básicos de incorporação de vetores e como a busca vetorial funciona internamente.

Munido de todo o conhecimento adquirido no primeiro artigo, a segunda parte irá guiá-lo pelos meandros de como configurar a pesquisa vetorial no Elasticsearch.

Na terceira parte, aproveitaremos o que aprendemos nas duas primeiras partes, expandiremos esse conhecimento e exploraremos como criar consultas de pesquisa híbridas poderosas no Elasticsearch.

Antes de abordarmos o tema principal deste artigo, vamos voltar no tempo e revisar um pouco da história dos vetores, um conceito fundamental na busca semântica.

Vetores não são novidade

Tenho quase certeza de que todos concordariam que, desde o surgimento do ChatGPT em novembro de 2022, não passa um único dia sem que se ouça ou leia sobre "busca vetorial". Está por toda parte e é tão difundida que muitas vezes temos a impressão de que se trata de uma tecnologia de ponta recém-lançada, quando na verdade ela já existe há mais de seis décadas! A pesquisa sobre o assunto começou em meados da década de 1960, e os primeiros artigos científicos foram publicados em 1978 por Gerard Salton, um especialista em recuperação de informação, e seus colegas da Universidade Cornell. O trabalho de Salton sobre modelos vetoriais densos e esparsos constitui a base da tecnologia moderna de busca vetorial.

Nos últimos 20 anos, muitos SGBDs vetoriais diferentes, baseados em sua pesquisa, foram criados e lançados no mercado. Isso inclui o Elasticsearch, baseado no projeto Apache Lucene, que começou a trabalhar em busca vetorial em 2019.

Os vetores estão por toda parte e são tão difundidos que é importante primeiro compreender bem a teoria subjacente e o funcionamento interno deles antes de começar a usá-los. Antes de nos aprofundarmos nisso, vamos revisar rapidamente as diferenças entre busca lexical e busca vetorial para que possamos entender melhor como elas diferem e como podem se complementar.

Busca vetorial versus busca lexical

Uma maneira fácil de introduzir a busca vetorial é compará-la à busca lexical mais convencional com a qual você provavelmente já está familiarizado. A busca vetorial, também conhecida como busca semântica, e a busca lexical funcionam de maneiras muito diferentes. A busca lexical é o tipo de busca que todos nós usamos há anos no Elasticsearch. Resumindo brevemente, o algoritmo não tenta compreender o significado real do que é indexado e consultado. Em vez disso, ele se esforça para encontrar correspondências lexicais entre os literais das palavras ou suas variantes (como lematização, sinônimos etc.) digitadas pelo usuário em uma consulta e todos os literais previamente indexados no banco de dados, utilizando algoritmos de similaridade como TF-IDF.

Como podemos ver, os três documentos no canto superior esquerdo foram tokenizados e analisados. Em seguida, os termos resultantes são indexados em um índice invertido, que simplesmente mapeia os termos analisados aos IDs dos documentos que os contêm. Note que todos os termos aparecem apenas uma vez e nenhum deles é repetido em qualquer outro documento. A busca por “professor alemão legal” retornará os três documentos com pontuações variadas, embora nenhum deles realmente capture o verdadeiro significado da consulta.

Como pode ser visto na Figura 2, abaixo, a situação fica ainda mais complicada quando se trata de polissemia ou homógrafos, ou seja, palavras que são escritas da mesma forma, mas têm significados diferentes (right, palm, bat, mean, etc.). Vamos pegar a palavra "right", que pode ter três significados diferentes, e ver o que acontece.

A busca por “I'm not right” retorna um documento que tem o significado exatamente oposto ao do primeiro resultado encontrado. Se você pesquisar exatamente os mesmos termos, mas ordená-los de forma diferente para produzir um significado diferente, por exemplo, "virar à direita" e "virar à direita", o resultado será exatamente o mesmo (ou seja, o terceiro documento "Vire à direita"). É verdade que nossas consultas são excessivamente simplificadas e não utilizam recursos mais avançados, como a correspondência de frases, mas isso ajuda a ilustrar que a busca lexical não compreende o verdadeiro significado por trás do que é indexado e do que é pesquisado. Se isso não estiver claro, não se preocupe, voltaremos a este exemplo no terceiro artigo para ver como a busca vetorial pode ajudar neste caso.

Para fazer justiça à busca lexical, quando você tem controle sobre como indexa seus dados estruturados (pense em mapeamentos, análise de texto, pipelines de ingestão, etc.) e como elabora suas consultas (pense em consultas DSL bem elaboradas, análise de termos de consulta, etc.), você pode fazer maravilhas com mecanismos de busca lexical, não há dúvida! O histórico do Elasticsearch em relação às suas capacidades de busca lexical é simplesmente incrível. O que conseguiu alcançar e o quanto popularizou e aprimorou o campo da busca lexical nos últimos anos é verdadeiramente notável.

No entanto, quando se trata de fornecer suporte para consultas a dados não estruturados (como imagens, vídeos, áudios, texto bruto, etc.) para usuários que precisam fazer perguntas em texto livre, a busca lexical deixa a desejar. Além disso, às vezes a consulta nem sequer é um texto, pode ser uma imagem, como veremos em breve. A principal razão pela qual a busca lexical é inadequada em tais situações é que os dados não estruturados não podem ser indexados nem consultados da mesma forma que os dados estruturados. Ao lidar com dados não estruturados, a semântica entra em jogo. O que significa semântica? Muito simplesmente, o significado!

Vamos pegar o exemplo simples de um mecanismo de busca de imagens (por exemplo, a Busca de Imagens do Google ou o Lens). Você arrasta e solta uma imagem, e o mecanismo de busca semântica do Google encontrará e retornará as imagens mais semelhantes àquela que você pesquisou. Na Figura 3, abaixo, podemos ver à esquerda a imagem de um pastor alemão e à direita todas as imagens semelhantes que foram recuperadas, sendo o primeiro resultado a mesma imagem que a fornecida (ou seja, a mais semelhante).

Mesmo que isso pareça simples e lógico para nós, humanos, para os computadores é uma história completamente diferente. É isso que a busca vetorial possibilita e ajuda a alcançar. O poder desbloqueado pela busca vetorial é imenso, como o mundo testemunhou recentemente. Vamos agora levantar o capô e descobrir o que se esconde por baixo.

Incorporação de vetores

Como vimos anteriormente, com mecanismos de busca lexical, dados estruturados como texto podem ser facilmente tokenizados em termos que podem ser correspondidos no momento da busca, independentemente do significado real dos termos. Os dados não estruturados, no entanto, podem assumir diferentes formas, como grandes objetos binários (imagens, vídeos, áudios, etc.), e não são adequados para o mesmo processo de tokenização. Além disso, o objetivo principal da busca semântica é indexar os dados de forma que possam ser pesquisados com base no significado que representam. Como podemos alcançar isso? A resposta está em duas palavras: Aprendizado de Máquina! Ou, mais precisamente, Aprendizado Profundo!

Aprendizado profundo é uma área específica do aprendizado de máquina que se baseia em modelos de redes neurais artificiais compostas por múltiplas camadas de processamento, capazes de extrair progressivamente o verdadeiro significado dos dados. O funcionamento desses modelos de redes neurais é fortemente inspirado no cérebro humano. A Figura 4, abaixo, mostra a aparência de uma rede neural, com suas camadas de entrada e saída, bem como múltiplas camadas ocultas:

A verdadeira façanha das redes neurais é a capacidade de transformar um único dado não estruturado em uma sequência de valores de ponto flutuante, conhecidos como vetores de incorporação ou simplesmente incorporações. Como seres humanos, conseguimos entender muito bem o que são vetores, desde que os visualizemos em um espaço bidimensional ou tridimensional. Cada componente do vetor representa uma coordenada em um plano xy bidimensional ou em um espaço xyz tridimensional.

No entanto, os vetores de incorporação nos quais os modelos de redes neurais funcionam podem ter centenas ou até milhares de dimensões e simplesmente representar um ponto em um espaço multidimensional. Cada dimensão vetorial representa uma característica ou um atributo dos dados não estruturados. Vamos ilustrar isso com um modelo de aprendizado profundo que transforma imagens em vetores de incorporação de 2048 dimensões. Esse modelo transformaria a imagem do pastor alemão que usamos na Figura 3 no vetor de incorporação mostrado na tabela abaixo. Note que mostramos apenas os três primeiros e os três últimos elementos, mas haveria mais 2.042 colunas/dimensões na tabela.

é vermelho

é_cachorro

céu azul

…

sem_grama

pastor_alemão

é_árvore

Pastor alemão incorporações

0,0121

0,9572

0,8735

…

0,1198

0,9712

0,0512

Cada coluna representa uma dimensão do modelo e corresponde a uma característica que a rede neural subjacente procura modelar. Cada entrada fornecida ao modelo será caracterizada dependendo de quão semelhante essa entrada é a cada uma das 2048 dimensões. Assim, o valor de cada elemento no vetor de incorporação denota a similaridade dessa entrada a uma dimensão específica. Neste exemplo, podemos ver que o modelo detectou uma alta similaridade entre cães e pastores alemães, bem como a presença de céu azul.

Ao contrário da busca lexical, onde um termo pode ser correspondido ou não, com a busca vetorial podemos ter uma noção muito melhor de quão semelhante um conjunto de dados não estruturados é a cada uma das dimensões suportadas pelo modelo. Dessa forma, os vetores de incorporação servem como uma representação semântica fantástica de dados não estruturados.

O molho secreto

Agora que sabemos como os dados não estruturados são segmentados e analisados por redes neurais de aprendizado profundo em vetores de incorporação que capturam a similaridade dos dados ao longo de um grande número de dimensões, precisamos entender como funciona a correspondência desses vetores. Acontece que a resposta é bem simples. Os vetores de incorporação que estão próximos uns dos outros representam dados semanticamente semelhantes . Assim, quando consultamos um banco de dados vetorial, a entrada da pesquisa (imagem, texto, etc.) é primeiro transformada em um vetor de incorporação usando o mesmo modelo que foi usado para indexar todos os dados não estruturados, e o objetivo final é encontrar os vetores vizinhos mais próximos desse vetor de consulta. Portanto, tudo o que precisamos fazer é descobrir como medir a "distância" ou "similaridade" entre o vetor de consulta e todos os vetores existentes indexados no banco de dados; é basicamente isso.

Distância e semelhança

Felizmente para nós, medir a distância entre dois vetores é um problema fácil de resolver graças à aritmética vetorial. Vamos então analisar as funções de distância e similaridade mais populares que são suportadas por bancos de dados de busca vetorial modernos, como o Elasticsearch. Atenção, contém matemática!

Distância L1

A distância L1, também chamada de distância de Manhattan, entre dois vetores x e y é medida somando-se a diferença absoluta entre todos os seus elementos. Obviamente, quanto menor a distância d, mais próximos estarão os dois vetores. A fórmula é bastante simples, como pode ser visto abaixo:

Visualmente, a distância L1 pode ser ilustrada como mostrado na Figura 5, abaixo:

Vamos pegar dois vetores x e y, tais como x = (1, 2) e y = (4, 3), então a distância L1 de ambos os vetores seria | 1 - 4 | + | 2 - 3 | = 4.

Distância L2

A distância L2, também chamada de distância euclidiana, entre dois vetores x e y é medida somando-se primeiro o quadrado da diferença entre todos os seus elementos e, em seguida, extraindo-se a raiz quadrada do resultado. É basicamente o caminho mais curto entre dois pontos (também chamado de hipotenusa). De forma semelhante a L1, quanto menor a distância d, mais próximos estão os dois vetores:

A distância L2 é mostrada na Figura 6 abaixo:

Vamos reutilizar os mesmos dois vetores de amostra x e y que usamos para a distância L1, e agora podemos calcular a distância L2 como . A raiz quadrada de 10 resulta em 3,16.

Distância Linf

A distância Linf (para L infinito), também chamada de distância de Chebyshev ou distância do tabuleiro de xadrez, entre dois vetores x e y é definida simplesmente como a maior distância entre quaisquer dois de seus elementos ou a maior distância medida ao longo de um dos eixos/dimensões. A fórmula é muito simples e está ilustrada abaixo:

A representação da distância Linf é mostrada na Figura 7 abaixo:

Novamente, tomando os mesmos dois vetores de amostra x e y, podemos calcular a distância infinita L como max ( | 1 - 4 | , | 2 - 3 | ) = max (3, 1) = 3.

Semelhança de cosseno

Ao contrário de L1, L2 e Linf, a similaridade de cosseno não mede a distância entre dois vetores x e y, mas sim o ângulo relativo entre eles, ou seja, se ambos apontam aproximadamente na mesma direção. Quanto maior a similaridade s, mais "próximos" estão os dois vetores. A fórmula é novamente muito simples e está apresentada abaixo:

Uma forma de representar a similaridade de cosseno entre dois vetores é mostrada na Figura 8 abaixo:

Além disso, como os valores do cosseno estão sempre no intervalo [-1, 1], -1 significa similaridade oposta (ou seja, um ângulo de 180° entre os dois vetores), 0 significa similaridade não relacionada (ou seja, um ângulo de 90°) e 1 significa idêntico (ou seja, um ângulo de 0°), conforme mostrado na Figura 9 abaixo:

Mais uma vez, vamos reutilizar os mesmos vetores de amostra x e y e calcular a similaridade de cosseno usando a fórmula acima. Primeiro, podemos calcular o produto escalar de ambos os vetores como . Então, multiplicamos o comprimento (também chamado de magnitude) de ambos os vetores: Finalmente, dividimos o produto escalar pelo comprimento multiplicado 10 / 11,18034 = 0,894427 (ou seja, um ângulo de 26°), que é bastante próximo de 1, então ambos os vetores podem ser considerados bastante semelhantes.

similaridade do produto escalar

Uma desvantagem da similaridade de cosseno é que ela leva em consideração apenas o ângulo entre dois vetores, mas não sua magnitude (ou seja, comprimento), o que significa que, se dois vetores apontam aproximadamente na mesma direção, mas um é muito mais longo que o outro, ambos ainda serão considerados semelhantes. A similaridade por produto escalar, também chamada de produto interno, aprimora isso ao levar em consideração tanto o ângulo quanto a magnitude dos vetores, o que proporciona uma métrica de similaridade muito mais precisa.

Duas fórmulas equivalentes são usadas para calcular a similaridade do produto escalar. A primeira é a mesma que vimos anteriormente no numerador da semelhança de cosseno:

A segunda fórmula simplesmente multiplica o comprimento de ambos os vetores pelo cosseno do ângulo entre eles:

A similaridade do produto escalar é visualizada na Figura 10, abaixo:

Mais uma vez, pegamos os vetores de amostra x e y e calculamos sua similaridade de produto escalar usando a primeira fórmula, como fizemos para a similaridade de cosseno anteriormente, como (1 4) + (2 3) = 10.

Usando a segunda fórmula, multiplicamos o comprimento de ambos os vetores: e multiplicamos isso pelo cosseno do ângulo de 26° entre ambos os vetores, e obtemos 11,18034 cos(26°) = 10.

Vale ressaltar que, se todos os vetores forem normalizados primeiro (ou seja, seu comprimento for 1), a similaridade do produto escalar se torna exatamente a mesma que a similaridade do cosseno (porque |x| |y| = 1), ou seja, o cosseno do ângulo entre os dois vetores. Como veremos mais adiante, a normalização de vetores é uma boa prática a ser adotada para tornar a magnitude do vetor irrelevante, de modo que a similaridade se concentre simplesmente no ângulo. Isso também acelera o cálculo da distância no momento da indexação e da consulta, o que pode ser um grande problema ao operar com bilhões de vetores.

Resumo rápido

Uau, já vimos MUITA informação até agora, então vamos parar um minuto e fazer um breve resumo do que temos a dizer. Aprendemos que…

• …a busca semântica é baseada em modelos de redes neurais de aprendizado profundo que se destacam na transformação de dados não estruturados em vetores de incorporação multidimensionais.

• …cada dimensão do modelo representa uma característica ou propriedade dos dados não estruturados.

• …um vetor de incorporação é uma sequência de valores de similaridade (um para cada dimensão) que representam o quão semelhante a cada dimensão um determinado conjunto de dados não estruturados é.

• …quanto mais “próximos” dois vetores estiverem (ou seja, quanto mais próximos forem os vizinhos), mais eles representarão conceitos semanticamente semelhantes.

• …as funções de distância (L1, L2, Linf) permitem medir a proximidade entre dois vetores.

• …as funções de similaridade (cosseno e produto escalar) permitem medir o quanto dois vetores estão apontando na mesma direção.

Agora, a última peça que precisamos analisar é o próprio mecanismo de busca vetorial. Quando uma consulta é recebida, ela é primeiro vetorizada e, em seguida, o mecanismo de busca vetorial encontra os vetores vizinhos mais próximos desse vetor de consulta. A abordagem de força bruta, que consiste em medir a distância ou similaridade entre o vetor de consulta e todos os vetores no banco de dados, pode funcionar para conjuntos de dados pequenos, mas rapidamente se torna insuficiente à medida que o número de vetores aumenta. Em outras palavras, como podemos indexar milhões, bilhões ou até trilhões de vetores e encontrar os vizinhos mais próximos do vetor de consulta em um tempo razoável? É aí que precisamos usar a inteligência e descobrir maneiras ideais de indexar vetores para que possamos localizar os vizinhos mais próximos o mais rápido possível, sem comprometer muito a precisão.

Algoritmos e técnicas de busca vetorial

Ao longo dos anos, muitas equipes de pesquisa diferentes investiram muito esforço no desenvolvimento de algoritmos de busca vetorial muito inteligentes. Aqui, vamos apresentar brevemente os principais. Dependendo do caso de uso, alguns são mais adequados do que outros.

Busca linear

Já mencionamos brevemente a busca linear, ou indexação plana, quando citamos a abordagem de força bruta de comparar o vetor de consulta com todos os vetores presentes no banco de dados. Embora possa funcionar bem em conjuntos de dados pequenos, o desempenho diminui rapidamente à medida que o número de vetores e dimensões aumenta (complexidade O(n)).

Felizmente, existem abordagens mais eficientes chamadas de vizinho mais próximo aproximado (ANN, na sigla em inglês), onde as distâncias entre os vetores de incorporação são pré-computadas e vetores semelhantes são armazenados e organizados de forma a mantê-los próximos uns dos outros, por exemplo, usando clusters, árvores, hashes ou grafos. Essas abordagens são chamadas de "aproximadas" porque geralmente não garantem 100% de precisão. O objetivo final é reduzir o escopo da busca o máximo e o mais rápido possível, a fim de focar apenas nas áreas com maior probabilidade de conter vetores semelhantes, ou reduzir a dimensionalidade dos vetores.

Árvores K-dimensionais

Uma árvore K-dimensional, ou árvore KD, é uma generalização de uma árvore de busca binária que armazena pontos em um espaço k-dimensional e funciona dividindo continuamente o espaço de busca em árvores menores à esquerda e à direita, onde os vetores são indexados. No momento da busca, o algoritmo simplesmente precisa visitar alguns ramos da árvore ao redor do vetor de consulta (o ponto vermelho na Figura 11) para encontrar o vizinho mais próximo (o ponto verde na Figura 11). Se forem solicitados mais de k vizinhos, a área amarela será expandida até que o algoritmo encontre mais vizinhos.

A maior vantagem do algoritmo da árvore KD é que ele nos permite focar rapidamente apenas em alguns ramos localizados da árvore, eliminando assim a maioria dos vetores da análise. No entanto, a eficiência desse algoritmo diminui à medida que o número de dimensões aumenta, pois é necessário visitar muito mais ramos do que em espaços de dimensões inferiores.

Índice de arquivo invertido

A abordagem de índice de arquivo invertido (IVF) também é um algoritmo de particionamento espacial que atribui vetores próximos uns dos outros ao seu centroide comum. No espaço bidimensional, isso é melhor visualizado com um diagrama de Voronoi, como mostrado na Figura 12:

Podemos ver que o espaço 2D acima está dividido em 20 clusters, cada um com seu centroide representado por pontos pretos. Todos os vetores de incorporação no espaço são atribuídos ao cluster cujo centroide está mais próximo deles. No momento da busca, o algoritmo primeiro determina o cluster no qual se concentrar, encontrando o centroide mais próximo do vetor de consulta. Em seguida, ele pode simplesmente focar nessa área e nas áreas vizinhas, se necessário, para encontrar os vizinhos mais próximos.

Este algoritmo sofre do mesmo problema que as árvores KD quando usado em espaços de alta dimensionalidade. Isso é chamado de maldição da dimensionalidade e ocorre quando o volume do espaço aumenta tanto que todos os dados parecem esparsos e a quantidade de dados necessária para obter resultados mais precisos cresce exponencialmente. Quando os dados são esparsos, torna-se mais difícil para esses algoritmos de particionamento espacial organizarem os dados em clusters. Felizmente para nós, existem outros algoritmos e técnicas que atenuam esse problema, conforme detalhado abaixo.

quantização

A quantização é uma abordagem baseada em compressãoque nos permite reduzir o tamanho total do banco de dados, diminuindo a precisão dos vetores de incorporação. Isso pode ser alcançado usando quantização escalar (SQ) , convertendo os valores vetoriais de ponto flutuante em valores inteiros. Isso não apenas reduz o tamanho do banco de dados em um fator de 8, mas também diminui o consumo de memória e acelera o cálculo da distância entre vetores no momento da busca.

Outra técnica é chamada de quantização de produto (PQ), que primeiro divide o espaço em subespaços de dimensão inferior e, em seguida, os vetores que estão próximos uns dos outros são agrupados em cada subespaço usando um algoritmo de agrupamento (semelhante ao k-means).

Note que a quantização é diferente da redução de dimensionalidade, onde o número de dimensões é reduzido, ou seja, os vetores simplesmente se tornam mais curtos.

Mundos Pequenos Navegáveis Hierárquicos (HNSW)

Se o nome parece complexo, não se preocupe, na verdade não é! Em resumo, o Hierarchical Navigable Small Worlds é um algoritmo baseado em grafos multicamadas muito popular e eficiente. É utilizado por diversos bancos de dados vetoriais, incluindo o Apache Lucene. Uma representação conceitual do HNSW pode ser vista na Figura 13, abaixo.

Na camada superior, podemos ver um gráfico com muito poucos vetores que possuem as ligações mais longas entre si, ou seja, um gráfico de vetores conectados com a menor similaridade. Quanto mais nos aprofundamos nas camadas mais baixas, mais vetores encontramos e mais denso o grafo se torna, com cada vez mais vetores próximos uns dos outros. Na camada mais baixa, podemos encontrar todos os vetores, sendo que os mais semelhantes estão localizados mais próximos uns dos outros.

No momento da busca, o algoritmo começa na camada superior, em um ponto de entrada arbitrário, e encontra o vetor mais próximo do vetor de consulta (indicado pelo ponto cinza). Em seguida, o algoritmo desce uma camada e repete o mesmo processo, partindo do mesmo vetor que deixou na camada anterior, e assim por diante, camada após camada, até atingir a camada mais baixa e encontrar o vizinho mais próximo do vetor de consulta.

Hashing sensível à localidade (LSH)

Da mesma forma que todas as outras abordagens apresentadas até agora, o hashing sensível à localidade busca reduzir drasticamente o espaço de busca para aumentar a velocidade de recuperação. Com essa técnica, os vetores de incorporação são transformados em valores de hash, preservando as informações de similaridade, de modo que o espaço de busca se torna, em última análise, uma tabela hash simples que pode ser consultada em vez de um grafo ou árvore que precisa ser percorrido. A principal vantagem dos métodos baseados em hash é que vetores contendo um número arbitrário (grande) de dimensões podem ser mapeados para hashes de tamanho fixo, o que acelera enormemente o tempo de recuperação sem sacrificar muita precisão.

Existem muitas maneiras diferentes de realizar o hash de dados em geral e de incorporar vetores em particular, mas este artigo não se aprofundará nos detalhes de cada uma delas. Os métodos convencionais de hashing geralmente produzem hashes muito diferentes para dados que parecem muito semelhantes. Como os vetores de incorporação são compostos de valores de ponto flutuante, vamos pegar dois valores de ponto flutuante de exemplo que são considerados muito próximos um do outro na aritmética vetorial (por exemplo, 0,73 e 0,74) e executá-los através de algumas funções de hash comuns. Analisando os resultados abaixo, fica bastante óbvio que as funções de hash comuns não preservam a similaridade entre as entradas.

Função de hash

0,73

0,74

MD5

1342129d04cd2924dd06cead4cf0a3ca

0aec1b15371bd979cfa66b0a50ebecc5

SHA1

49d2c3e0e44bff838e1db571a121be5ea874e8d9

a534e76482ade9d9fe4bff3035a7f31f2f363d77

SHA256

99d03fc3771fe6848d675339fc49eeb1cb8d99a12e6358173336b99a2ec530ea

5ecbc825ba5c16856edfdaf0abc5c6c41d0d8a9c508e34188239521dc7645663

Enquanto os métodos de hashing convencionais tentam minimizar as colisões de hashing entre dados semelhantes, o principal objetivo do hashing sensível à localidade é fazer exatamente o oposto, ou seja, maximizar as colisões de hashing para que dados semelhantes caiam no mesmo bucket com alta probabilidade. Dessa forma, vetores de incorporação que estejam próximos uns dos outros em um espaço multidimensional serão agrupados em um valor de tamanho fixo, pertencendo ao mesmo grupo. Como o LSH permite que esses vetores hash mantenham sua proximidade, essa técnica é muito útil para agrupamento de dados e buscas por vizinhos mais próximos.

Todo o trabalho pesado ocorre no momento da indexação, quando os hashes precisam ser calculados, enquanto no momento da busca precisamos apenas aplicar o hash ao vetor de consulta para localizar o bucket que contém os vetores de incorporação mais próximos. Uma vez encontrado o bucket candidato, geralmente ocorre uma segunda rodada para identificar os vetores vizinhos mais próximos do vetor de consulta.

Vamos concluir

Para introduzir a busca vetorial, tivemos que abordar bastante conteúdo neste artigo. Após comparar as diferenças entre a busca lexical e a busca vetorial, aprendemos como os modelos de redes neurais de aprendizado profundo conseguem capturar a semântica de dados não estruturados e transcodificar seu significado em vetores de incorporação de alta dimensão, uma sequência de números de ponto flutuante que representa a similaridade dos dados ao longo de cada uma das dimensões do modelo. Vale ressaltar também que a busca vetorial e a busca lexical não são técnicas de recuperação de informação concorrentes, mas sim complementares (como veremos na terceira parte desta série, quando nos aprofundaremos na busca híbrida).

Em seguida, introduzimos um elemento fundamental da busca vetorial, ou seja, as funções de distância (e similaridade) que nos permitem medir a proximidade de dois vetores e avaliar a similaridade dos conceitos que eles representam.

Por fim, analisamos diferentes variações dos algoritmos e técnicas de busca vetorial mais populares, que podem ser baseados em árvores, grafos, clusters ou hashes, cujo objetivo é restringir rapidamente a uma área específica do espaço multidimensional para encontrar os vizinhos mais próximos sem ter que percorrer todo o espaço, como faria uma busca linear por força bruta.

Se você gostou do que leu, não deixe de conferir as outras partes desta série:

• Parte 2: Como configurar a pesquisa vetorial no Elasticsearch

• Parte 3: Busca Híbrida usando o Elasticsearch

O conector Semantic Kernel Elasticsearch Vector Store, pronto para uso, oferece suporte às abstrações de armazenamento vetorial do Semantic Kernel, o que facilita muito para os desenvolvedores a integração do Elasticsearch como um armazenamento vetorial durante a criação de agentes de IA.

O Elasticsearch possui uma base sólida na comunidade de código aberto e adotou recentemente a licença AGPL. Em conjunto com o Microsoft Semantic Kernel de código aberto, essas ferramentas oferecem uma solução poderosa e pronta para uso empresarial. Você pode começar localmente executando o Elasticsearch em poucos minutos executando este comando curl -fsSL https://elastic.co/start-local | sh (consulte start-local para obter detalhes) e migrar para versões hospedadas na nuvem ou auto-hospedadas à medida que coloca seus agentes de IA em produção.

Neste blog, veremos como usar o conector Elasticsearch Vector Store do Semantic Kernel ao utilizar o Semantic Kernel. Uma versão em Python do conector será disponibilizada futuramente.

Cenário geral: Construindo um aplicativo RAG com Semantic Kernel e Elasticsearch.

Na seção seguinte, analisaremos um exemplo. Em linhas gerais, estamos construindo um aplicativo RAG (Retrieval Augmented Generation) que recebe uma pergunta do usuário como entrada e retorna uma resposta. Usaremos o Azure OpenAI (também é possível usar um LLM local ) como LLM, o Elasticsearch como repositório de vetores e o Semantic Kernel (.NET) como framework para integrar todos os componentes.

Se você não estiver familiarizado com arquiteturas RAG, pode ter uma breve introdução com este artigo: https://www.elastic.co/search-labs/blog/retrieval-augmented-generation-rag.

A resposta é gerada pelo LLM, que é alimentado com contexto relevante para a pergunta, obtido do armazenamento de vetores do Elasticsearch. A resposta também inclui a fonte que foi usada como contexto pelo LLM.

Exemplo RAG

Neste exemplo específico, criamos um aplicativo que permite aos usuários fazer perguntas sobre hotéis armazenados em um banco de dados interno de hotéis. O usuário poderia, por exemplo... Pesquise um hotel específico com base em diferentes critérios ou solicite uma lista de hotéis.

Para o banco de dados de exemplo, geramos uma lista de hotéis contendo 100 entradas. O tamanho da amostra é intencionalmente pequeno para permitir que você experimente a demonstração do conector da maneira mais fácil possível. Em uma aplicação do mundo real, o conector Elasticsearch mostraria suas vantagens sobre outras opções, como a implementação de armazenamento vetorial `InMemory`, especialmente ao trabalhar com quantidades extremamente grandes de dados.

A aplicação de demonstração completa pode ser encontrada no repositório do conector de armazenamento vetorial do Elasticsearch.

Vamos começar adicionando os pacotes NuGet necessários e usando as diretivas ao nosso projeto:

Agora podemos criar nosso modelo de dados e fornecer a ele atributos específicos do Semantic Kernel para definir o esquema do modelo de armazenamento e algumas dicas para a pesquisa de texto:

Os atributos do esquema do modelo de armazenamento (`VectorStore*`) são os mais relevantes para o uso prático do conector Elasticsearch Vector Store, a saber:

• VectorStoreRecordKey Marcar uma propriedade em uma classe de registro como a chave sob a qual o registro é armazenado em um armazenamento vetorial.

• VectorStoreRecordData Marcar uma propriedade em uma classe de registro como 'dados'.

• VectorStoreRecordVector Para marcar uma propriedade em uma classe de registro como um vetor.

Todos esses atributos aceitam vários parâmetros opcionais que podem ser usados para personalizar ainda mais o modelo de armazenamento. No caso de VectorStoreRecordKey , por exemplo, é possível especificar uma função de distância diferente ou um tipo de índice diferente.

Os atributos de pesquisa de texto (TextSearch*) serão importantes na última etapa deste exemplo. Voltaremos a eles mais tarde.

Na próxima etapa, inicializamos o mecanismo do Kernel Semântico e obtemos referências aos serviços principais. Em uma aplicação do mundo real, a injeção de dependência deve ser usada em vez de acessar diretamente a coleção de serviços. O mesmo se aplica à configuração e aos segredos embutidos no código, que devem ser lidos usando um provedor de configuração :

O serviço vectorStoreCollection agora pode ser usado para criar a coleção e para inserir alguns registros de demonstração:

Isso demonstra como o Semantic Kernel reduz o uso de um armazenamento vetorial com toda a sua complexidade a algumas chamadas de método simples.

Nos bastidores, um novo índice é criado no Elasticsearch e todos os mapeamentos de propriedades necessários são criados. Nosso conjunto de dados é então mapeado de forma completamente transparente para o modelo de armazenamento e, finalmente, armazenado no índice. Abaixo, você pode ver como os mapeamentos aparecem no Elasticsearch.

As chamadas embeddings.GenerateEmbeddingsAsync() invocaram de forma transparente o serviço de geração de incorporações de IA do Azure configurado.

Ainda mais magia pode ser observada na última etapa desta demonstração.

Com apenas uma chamada para InvokePromptAsync, todas as seguintes operações são realizadas quando o usuário faz uma pergunta sobre os dados:

1. É gerado um elemento incorporado para a pergunta do usuário.

2. O repositório de vetores é pesquisado em busca de entradas relevantes.

3. Os resultados da consulta são inseridos em um modelo de prompt.

4. A consulta propriamente dita, na forma da mensagem final, é enviada ao serviço de autocompletar do chat por IA.

Lembra-se dos atributos TextSearch* que definimos anteriormente em nosso modelo de dados? Esses atributos nos permitem usar marcadores correspondentes em nosso modelo de prompt, que são preenchidos automaticamente com as informações de nossas entradas no repositório vetorial.

A resposta final à nossa pergunta "Por favor, mostre-me todos os hotéis que possuem um bar na cobertura" é a seguinte:

A resposta correta refere-se à seguinte entrada em nosso arquivo hotels.csv.

Este exemplo demonstra muito bem como a utilização do Microsoft Semantic Kernel permite uma redução significativa da complexidade através das suas abstrações bem concebidas, além de proporcionar um elevado nível de flexibilidade. Ao alterar uma única linha de código, por exemplo, o armazenamento de vetores ou os serviços de IA utilizados podem ser substituídos sem a necessidade de refatorar qualquer outra parte do código.

Ao mesmo tempo, a estrutura fornece um enorme conjunto de funcionalidades de alto nível, como a função `InvokePrompt`, ou o sistema de plugins de modelo ou de pesquisa.

A aplicação de demonstração completa pode ser encontrada no repositório do conector de armazenamento vetorial do Elasticsearch.

O que mais é possível fazer com o Elasticsearch?

• Novo mapeamento semantic_text do Elasticsearch: Simplificando a busca semântica

• Reclassificação semântica no Elasticsearch com retrievers

• Técnicas avançadas de RAG, parte 1: Processamento de dados

• Técnicas avançadas de RAG, parte 2: Consultas e testes

• Construindo o RAG com Llama 3 de código aberto e Elastic

• Um tutorial sobre como construir um agente local usando LangGraph, LLaMA3 e o armazenamento de vetores Elasticsearch do zero.

Elasticsearch e Semantic Kernel: O que vem a seguir?

• Mostramos como o armazenamento de vetores do Elasticsearch pode ser facilmente integrado ao Semantic Kernel durante a criação de aplicações GenAI em .NET. Fique atento para a integração com Python em breve.

• À medida que o Semantic Kernel cria abstrações para recursos de pesquisa avançados, como a pesquisa híbrida, a conexão com o Elasticsearch permitirá que os desenvolvedores .NET os implementem facilmente ao usar o Semantic Kernel.

Além de integrar a busca híbrida, demonstraremos como adicionar recursos que tornarão sua solução de busca ainda mais robusta. Isso inclui segmentação por facetas e promoções de produtos personalizadas. Além disso, mostraremos como capturar interações do usuário e gerar insights valiosos usando a ferramenta de Análise Comportamental da Elastic.

Nesta implementação, você verá como construir tanto a interface que permite aos usuários visualizar e interagir com os resultados da pesquisa quanto a API responsável por retornar as informações. Para acessar os repositórios com o código-fonte, os links são fornecidos abaixo:

• https://github.com/elastic/elasticsearch-labs/tree/main/supporting-blog-content/hybrid-search-for-an-e-commerce-product-catalogue/product-store-search

• https://github.com/elastic/elasticsearch-labs/tree/main/supporting-blog-content/hybrid-search-for-an-e-commerce-product-catalogue/app-product-store

Dividimos este guia em várias etapas, desde a criação do índice até a implementação de recursos avançados, como facetas e personalização de resultados. Ao final, você terá uma solução de busca robusta, pronta para ser usada em um cenário de comércio eletrônico.

Configuração do ambiente para pesquisa híbrida de comércio eletrônico

Antes de iniciarmos a implementação, precisamos configurar o ambiente. Você pode optar por usar um serviço na Elastic Cloud ou uma solução em contêineres para gerenciar o Elasticsearch. Se você optar pela conteinerização, uma configuração via Docker Compose pode ser encontrada neste repositório: docker-compose.yml.

Criação de índice e ingestão de catálogo de produtos

O índice será criado com base em um catálogo de produtos cosméticos, que inclui campos como nome, descrição, foto, categoria e etiquetas. Os campos usados para pesquisa de texto completo, como "nome" e "descrição", serão mapeados como text, enquanto os campos usados para agregações, como "categoria" e "marca", serão mapeados como keyword para permitir a filtragem facetada.

O campo "descrição" será usado para a busca vetorial, pois fornece mais contexto sobre os produtos. Este campo será definido como dense_vector, , armazenando a representação vetorial da descrição.

O mapeamento do índice será o seguinte:

O script para criar o índice pode ser encontrado aqui.

Geração de incorporação

Para vetorizar as descrições dos produtos, utilizamos o modelo all-MiniLM-L6-v2. Neste caso, a aplicação é responsável por gerar os embeddings antes da indexação. Outra opção seria importar o modelo para o cluster Elasticsearch, mas para este ambiente local, optamos por realizar a vetorização diretamente dentro da aplicação.

Utilizamos o conjunto de dados de cosméticos disponível no Kaggle para preencher o índice e, para melhorar a eficiência da ingestão de dados, usamos o processamento em lote. Durante essa mesma etapa de ingestão, geraremos os embeddings para o campo "description" e os indexaremos no novo campo "description_embeddings".

Todo o processo de ingestão de dados pode ser acompanhado e executado diretamente através do Jupyter Notebook disponível no repositório. O notebook fornece um guia passo a passo sobre como os dados são lidos, processados e indexados no Elasticsearch, permitindo fácil replicação e experimentação.

Você pode acessar o notebook no seguinte link: Notebook de Ingestão.

Implementação de busca híbrida

Agora, vamos implementar a busca híbrida. Para a pesquisa baseada em palavras-chave, usamos a consulta multi_match , direcionada aos campos "nome", "categoria" e "descrição". Isso garante que os documentos que contenham o termo de pesquisa em qualquer um desses campos sejam recuperados.

Para a busca vetorial, utilizamos a consulta KNN. O termo de pesquisa precisa ser vetorizado antes da execução da consulta, e isso é feito usando o método que vetoriza o termo de entrada. Note que o mesmo modelo usado durante a ingestão também é usado para o termo de pesquisa.

A combinação das duas buscas é realizada utilizando o algoritmo Reciprocal Rank Fusion (RRF) , que mescla os resultados das duas consultas e aumenta a precisão da busca ao reduzir o ruído. O RRF permite que as buscas baseadas em palavras-chave e em vetores funcionem em conjunto, aprimorando a compreensão da consulta do usuário.

Comparação de resultados: pesquisa por palavra-chave vs. pesquisa híbrida

Agora, vamos comparar os resultados de uma pesquisa tradicional por palavras-chave com a pesquisa híbrida. Ao pesquisar por "base para pele seca" usando a busca por palavras-chave, obtemos os seguintes resultados:

1. Base Revlon ColorStay para Pele Normal/SecaDescrição: A Base Revlon ColorStay oferece cobertura de longa duração com uma fórmula leve que não craquela, desbota ou transfere. Com a tecnologia de liberação gradual, esta fórmula sem óleo e com equilíbrio de hidratação foi especialmente desenvolvida para peles normais ou secas, proporcionando hidratação contínua. Características: Maquiagem confortável e com duração de até 24 horas. Cobertura média a total. Disponível em uma variedade de lindas cores.

2. Base Mousse Dream Smooth da Maybelline: Por que você vai amar? Esta base cremosa exclusiva proporciona uma pele 100% macia como a de um bebê. Pele com aparência e sensação de hidratação por 14 horas - nunca áspera ou ressecada. Fórmula leve que proporciona cobertura perfeitamente hidratante. Mistura-se perfeitamente e proporciona uma sensação de frescor o dia todo. Sem óleo, sem fragrância, testado por dermatologistas, testado contra alergias, não comedogênico – não obstrui os poros. Seguro. Para peles sensíveis.

Análise: Ao pesquisar por "base para pele seca", os resultados foram obtidos pela correspondência exata entre as palavras-chave do termo de pesquisa e os títulos e descrições dos produtos. No entanto, essa combinação nem sempre representa a melhor escolha. Por exemplo, a base Revlon ColorStay para pele normal/seca é uma boa opção, pois é formulada especificamente para pele seca. Apesar de ser isento de óleo, sua fórmula foi desenvolvida para proporcionar hidratação contínua. Em contrapartida, também recebemos a base Maybelline Dream Smooth Mousse, que, embora seja livre de óleo e mencione hidratação, geralmente é mais recomendada para peles oleosas ou mistas, já que os produtos sem óleo tendem a se concentrar no controle da oleosidade em vez de fornecer a hidratação extra necessária para peles secas. Isso evidencia a limitação das buscas baseadas em palavras-chave, que podem retornar produtos que não atendem completamente às necessidades específicas de pessoas com pele seca.

Agora, ao realizar a mesma pesquisa usando a abordagem híbrida:

1. Base Cremosa CoverGirl Outlast Stay Luminous Natural (820): Descrição: A Base CoverGirl Outlast Stay Luminous é perfeita para obter um acabamento luminoso e um brilho sutil. É livre de óleo, com uma fórmula não oleosa que proporciona à sua pele uma luminosidade natural que dura o dia todo! Esta base de longa duração hidrata a pele enquanto proporciona uma cobertura impecável. Análise: Este produto é uma excelente opção, pois prioriza a hidratação, que é fundamental para usuários com pele seca. Os termos "hidrata a pele" e "acabamento luminoso" estão alinhados com a intenção do usuário de encontrar uma base para pele seca. A busca vetorial provavelmente compreendeu o conceito de hidratação e o relacionou à necessidade de uma base que trate a pele seca.

2. Base Revlon ColorStay para Pele Normal/Seca: Descrição: A base Revlon ColorStay oferece cobertura de longa duração com uma fórmula leve que não craquela, desbota ou transfere. Com a tecnologia de liberação gradual, esta fórmula sem óleo e com equilíbrio de hidratação foi especialmente desenvolvida para peles normais ou secas, proporcionando hidratação contínua. Análise: Este produto aborda diretamente as necessidades de usuários com pele seca, mencionando explicitamente que sua fórmula é indicada para pele normal ou seca. A "fórmula de equilíbrio de umidade" e a hidratação contínua são ideais para quem busca uma base que atenda às necessidades da pele seca. A busca vetorial recuperou com sucesso esse resultado, não apenas pela correspondência de palavras-chave, mas também pelo foco na hidratação e pela menção específica de pele seca como público-alvo.

3. Descrição da Base Sérum: As bases sérum são fórmulas leves com cobertura média, disponíveis em uma ampla gama de 21 tons. Essas bases oferecem cobertura moderada com aparência natural e uma sensação de sérum muito leve. Possuem viscosidade muito baixa e são dispensados com a bomba fornecida ou com o conta-gotas de vidro opcional, disponível para compra separadamente, caso seja de preferência. Análise: Neste caso, a descrição enfatiza uma base sérum leve com toque natural, o que está de acordo com as necessidades de pessoas com pele seca, que geralmente buscam produtos suaves, hidratantes e que proporcionem um acabamento sem efeito craquelado. A busca vetorial provavelmente captou o contexto mais amplo de cobertura leve e natural e a textura semelhante a um sérum, que está associada à retenção de umidade e a uma aplicação confortável, tornando-a relevante para pele seca, mesmo que o termo "pele seca" não seja mencionado explicitamente.

Implementação de facetas

Os filtros são essenciais para refinar e filtrar os resultados da pesquisa de forma eficiente, proporcionando aos usuários uma navegação mais direcionada, especialmente em cenários com grande variedade de produtos, como no comércio eletrônico. Elas permitem que os usuários ajustem os resultados com base em atributos como categoria, marca ou preço, tornando a busca mais precisa. Para implementar este recurso, usamos agregações de termos nos campos category e brand , que foram definidos como keyword durante o estágio de criação do índice.

O código completo da implementação pode ser encontrado aqui.

Veja abaixo os resultados da busca por "base para pele seca":

Personalizando resultados: consultas fixadas

Em alguns casos, pode ser benéfico promover determinados produtos nos resultados da pesquisa. Para isso, utilizamos Consultas Fixadas, que permitem que produtos específicos apareçam no topo dos resultados. A seguir, realizaremos uma busca pelo termo "Fundação" sem promover nenhum produto:

Em nosso exemplo, podemos promover produtos que tenham a etiqueta "Sem Glúten". Ao utilizarmos os IDs dos produtos, garantimos que eles sejam priorizados nos resultados da pesquisa. Especificamente, promoveremos os seguintes produtos: Base Sérum (ID: 1043), Base de Alta Cobertura (ID: 1042) e Pó Translúcido Realista (ID: 1039).

Utilizamos IDs de produto específicos para garantir que eles sejam priorizados nos resultados da consulta. A estrutura da consulta inclui uma lista de IDs de produtos que devem ser "fixados" no topo (neste caso, os IDs 1043, 1042 e 1039), enquanto os resultados restantes seguem o fluxo orgânico da pesquisa, usando uma combinação de condições como a consulta de texto nos campos "nome", "categoria" e "descrição". Dessa forma, é possível promover itens de maneira controlada, garantindo sua visibilidade, enquanto o restante da busca permanece baseado na relevância usual.

Abaixo, você pode ver o resultado da execução da consulta com os produtos promovidos:

O código completo da consulta pode ser encontrado aqui.

Analisando o comportamento de busca com análise comportamental.

Até o momento, já adicionamos funcionalidades para melhorar a relevância dos resultados de busca e facilitar a descoberta de produtos. Agora, vamos finalizar nossa solução de busca incluindo um recurso que nos ajudará a analisar o comportamento de busca do usuário, identificando padrões como consultas com ou sem resultados e cliques nos resultados da busca. Para isso, usaremos o recurso de Análise Comportamental fornecido pela Elastic. Com ele, em apenas alguns passos, podemos monitorar e analisar o comportamento de busca do usuário, obtendo informações valiosas para otimizar a experiência de busca.

Criando a coleta de dados de análise comportamental

Nossa primeira ação será criar uma coleção, que será responsável por receber todos os eventos de análise comportamental. Para criar a coleção, acesse a interface do Kibana em Pesquisa > Análise Comportamental. No exemplo abaixo, criamos a coleção chamada tracking-search.

Integrar a análise comportamental à interface.

Nosso aplicativo front-end foi desenvolvido em JavaScript e, para integrar o Behavioral Analytics, seguiremos os passos descritos na documentação oficial da Elastic para instalar o Behavioral Analytics JavaScript Tracker.

Implementando o rastreador JavaScript

Agora, vamos importar o cliente rastreador para nosso aplicativo e usar os métodos trackPageView, trackSearch e trackSearchClick para capturar as interações do usuário.

Aviso: Embora utilizemos uma ferramenta para coletar dados de interação do usuário, é essencial garantir a conformidade com o GDPR. Isso significa informar claramente os usuários sobre quais dados estão sendo coletados, como serão usados e fornecer a opção de desativar o rastreamento. Além disso, devemos implementar medidas de segurança robustas para proteger as informações coletadas e respeitar os direitos do usuário, como o acesso e a exclusão de dados, garantindo que todas as etapas estejam em conformidade com os princípios do GDPR.

Etapa 1: Criando a instância do rastreador

Primeiro, criaremos a instância do rastreador que monitorará as interações. Nessa configuração, definimos o endpoint de destino, o nome da coleção e a chave da API:

Etapa 2: Capturando visualizações de página

Para rastrear visualizações de página, podemos configurar o evento trackPageView :

Para obter mais detalhes sobre o evento trackPageView , você pode consultar esta documentação.

Etapa 3: Capturar consultas de pesquisa

Para monitorar as ações de busca dos usuários, utilizaremos o método trackSearch :

Aqui estamos coletando o termo de pesquisa e os resultados da pesquisa.

Etapa 4: Rastreamento de cliques nos resultados da pesquisa

Finalmente, para capturar cliques nos resultados da pesquisa, usaremos o método trackSearchClick :

Coletamos informações sobre o ID do documento clicado, bem como o termo de pesquisa e os resultados da pesquisa.

Analisando os dados no Kibana

Agora que os eventos de interação do usuário estão sendo capturados, podemos obter dados valiosos sobre as ações de busca. O Kibana utiliza a ferramenta de Análise Comportamental para visualizar e analisar esses dados comportamentais. Para visualizar os resultados, basta navegar até Pesquisa > Análise Comportamental > Minha Coleção, onde será exibida uma visão geral dos eventos capturados.

Nesta visão geral, obtemos uma perspectiva ampla dos eventos registrados para cada ação integrada à nossa interface. A partir dessas informações, podemos obter insights valiosos sobre o comportamento de busca do usuário. No entanto, se você deseja criar painéis personalizados com métricas mais relevantes para o seu cenário específico, o Kibana oferece ferramentas poderosas para a criação de painéis, permitindo que você crie diversas visualizações de suas métricas.

Abaixo, criei algumas visualizações e gráficos para monitorar, por exemplo, os termos mais pesquisados ao longo do tempo, as consultas que não retornaram resultados, uma nuvem de palavras destacando os termos mais pesquisados e, finalmente, uma visualização geográfica para identificar a origem do acesso à pesquisa.

Conclusão

Neste artigo, implementamos uma solução de busca híbrida que combina busca por palavras-chave e busca vetorial, fornecendo resultados mais precisos e relevantes para os usuários. Exploramos também como usar recursos adicionais, como filtros e personalização de resultados com Consultas Fixadas, para criar uma experiência de busca mais completa e eficiente.

Além disso, integramos o Behavioral Analytics da Elastic para capturar e analisar o comportamento do usuário durante suas interações com o mecanismo de busca. Ao usar métodos como trackPageView, trackSearch e trackSearchClick, conseguimos monitorar consultas de pesquisa, cliques em resultados de pesquisa e visualizações de página, gerando informações valiosas sobre o comportamento de pesquisa.

Referências

Conjunto de dados

https://www.kaggle.com/datasets/shivd24coder/cosmetic-brand-products-dataset

Transformador

https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2

Fusão de Classificação Recíproca

https://www.elastic.co/guide/en/elasticsearch/reference/current/rrf.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/retriever.html#rrf-retriever

Consulta Knn

https://www.elastic.co/guide/en/elasticsearch/reference/current/knn-search.html

Consulta fixada

https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-pinned-query.html

APIs de análise comportamental

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

https://www.elastic.co/guide/en/elasticsearch/reference/current/behavioral-analytics-overview.html

NOTA: Se você estiver familiarizado com a versão antiga do cliente C# do Elasticsearch, o NEST, leia esta postagem do blog sobre a descontinuação do cliente NEST e seus novos recursos. O NEST era a geração anterior do cliente .NET, que foi substituído pelo Elastic.Clients.Elasticsearch package

• O que é Blazor?

• O que é ESRE?

• Configurando o ELSER

• Dados de indexação

• Aplicação de construção

O que é Blazor?

Blazor é um framework web de código aberto baseado em HTML, CSS e C#, criado pela Microsoft para permitir que desenvolvedores criem aplicações web que rodam tanto no cliente quanto no servidor. O Blazor também permite criar componentes reutilizáveis para desenvolver aplicações mais rapidamente; ele possibilita que os desenvolvedores criem a visualização HTML e as ações em C# no mesmo arquivo, o que ajuda a manter um código legível e limpo. Além disso, com o Blazor Hybrid, você pode criar aplicativos móveis nativos acessando os recursos nativos da plataforma por meio de código .NET.

Algumas das características que fazem do Blazor uma ótima estrutura para se trabalhar:

• Opções de renderização do lado do servidor e do lado do cliente

• Componentes de interface do usuário reutilizáveis

• Atualizações em tempo real com SignalR

• Gerenciamento de estado integrado

• Sistema de roteamento integrado

• Tipagem forte e verificações em tempo de compilação

Por que Blazor?

O Blazor oferece diversas vantagens em relação a outros frameworks e bibliotecas: permite que os desenvolvedores usem C# tanto para o código do cliente quanto para o código do servidor, fornecendo tipagem forte e verificação em tempo de compilação, o que aumenta a confiabilidade. Ele se integra perfeitamente ao ecossistema .NET, permitindo a reutilização de bibliotecas e ferramentas .NET, e oferece suporte robusto para depuração.

O que é ESRE?

O Elasticsearch Relevance Engine ™ (ESRE) é um conjunto de ferramentas para criar aplicações de busca utilizando aprendizado de máquina e inteligência artificial sobre o poderoso mecanismo de busca Elasticsearch.

Para saber mais sobre ESRE, você pode ler nossa postagem esclarecedora no blog, que está disponível aqui.

Configurando o ELSER

Para aproveitar os recursos do ESRE da Elastic, usaremos o ELSER como nosso provedor de modelos.

Para usar os modelos ELSER do Elasticsearch, você precisa de uma licença Platinum ou Enterprise e de um nó dedicado para Machine Learning (ML) com no mínimo 4 GB de espaço. Saiba mais aqui.

Comece criando o ponto de extremidade de inferência:

Se esta for a sua primeira vez usando o ELSER, você poderá encontrar um erro 502 Bad Gateway enquanto o modelo é carregado em segundo plano. Você pode verificar o status do modelo em Machine Learning > Trained Models no Kibana. Após a implantação, você poderá prosseguir para a próxima etapa.

Dados de indexação

Você pode baixar o conjunto de dados aqui e, em seguida, importar os dados usando o Kibana. Para isso, acesse a página inicial e clique em "Carregar dados". Em seguida, carregue o arquivo e clique em Import. Por fim, acesse a aba Advanced e cole os seguintes mapeamentos:

Vamos criar um índice capaz de executar consultas semânticas e de texto completo. O tipo de campo semantic_text cuidará do agrupamento e da incorporação dos dados. Observe que estamos indexando longDescription como semantic_text, você pode usar copy_to se quiser indexar um campo como semantic_text e text`.

Construindo o aplicativo com Blazor e Elasticsearch

Chave de API

A primeira coisa que precisamos fazer é criar uma chave de API para autenticar nossas solicitações ao Elasticsearch. A chave da API deve ser somente leitura e permitir apenas consultas ao índice books-blazor .

Você verá algo parecido com isto:

Salve o valor do campo de resposta encoded , pois ele será necessário posteriormente. Se você estiver usando o Elastic Cloud, também precisará do seu ID da nuvem. (Você pode encontrá-lo aqui).

Criando o projeto Blazor

Comece instalando o Blazor e criando um projeto de exemplo seguindo as instruções oficiais.

Após a criação do projeto, a estrutura de pastas e arquivos deve ser semelhante a esta:

O aplicativo modelo inclui o Bootstrap v5.1.0. para estilização.

Finalize a configuração do projeto instalando o cliente Elasticsearch .NET :

Após concluir esta etapa, sua página deverá ter esta aparência:

Estrutura de pastas

Agora, vamos organizar nossas pastas da seguinte forma:

Explicação dos arquivos:

• Components/Pages/Search.razor: página principal contendo a barra de pesquisa, os resultados e os filtros.

• Components/Pages/Search.razor.css: estilos de página.

• Components/Elasticsearch/SearchBar.razor: componente da barra de pesquisa.

• Components/Elasticsearch/Results.razor: componente de resultados.

• Components/Elasticsearch/Facet.razor: componente de filtros.

• Components/Svg/GlassIcon.razor: ícone de pesquisa.

• Components/_Imports.razor: este arquivo importará todos os componentes.

• Models/Book.cs: este arquivo armazenará o esquema do campo do livro.

• Models/Response.cs: este arquivo armazenará o esquema de resposta, incluindo os resultados da pesquisa, as facetas e o total de resultados.

• Services/ElasticsearchService.cs: Serviço Elasticsearch. Ele será responsável pela conexão e pelas consultas ao Elasticsearch.

Configuração inicial

Vamos começar com uma limpeza.

Apague os arquivos:

• Components/Pages/Counter.razor

• Componentes/Páginas/Weather.razor

• Componentes/Páginas/Home.razor

• Components/Layout/NavMenu.razor

• Components/Layout/NavMenu.razor.css

Verifique o arquivo /Components/_Imports.razor . Você deve ter as seguintes importações:

Integrando o Elastic ao projeto

Agora, vamos importar os componentes do Elasticsearch:

Vamos remover a barra lateral padrão para termos mais espaço para nossa aplicação, removendo-a do arquivo /Components/Layout/MainLayout.razor :

Agora vamos inserir as credenciais do Elasticsearch para os segredos do usuário:

Usando esta abordagem, o .Net 8 armazena dados sensíveis em um local separado, fora da pasta do projeto e os torna acessíveis usando a interface IConfiguration . Essas variáveis estarão disponíveis para qualquer projeto .NET que utilize os mesmos segredos de usuário.

Em seguida, vamos modificar o arquivo Program.cs para ler os segredos e montar o cliente Elasticsearch:

Primeiro, importe as bibliotecas necessárias:

• BlazorApp.Services: contém o serviço Elasticsearch.

• Elastic.Clients.Elasticsearch: importa a biblioteca cliente Elasticsearch para .NET 8.

• Elastic.Transport: importa a biblioteca de transporte do Elasticsearch, que nos permite usar a classe ApiKey para autenticar nossas solicitações.

Em segundo lugar, insira o seguinte código antes da linha var app = builder.Build() :

Este código lerá as credenciais do Elasticsearch a partir dos segredos do usuário e criará uma instância de cliente Elasticsearch.

Após a inicialização do cliente Elasticsearch, adicione a seguinte linha para registrar o serviço Elasticsearch:

O próximo passo será construir a lógica de busca no arquivo /Services/ElasticsearchService.cs :

Primeiro, importe as bibliotecas e os modelos necessários:

Em segundo lugar, adicione a classe ElasticsearchService, o construtor e as variáveis:

Configurando a pesquisa

Agora, vamos construir nossa lógica de busca:

• BuildFilters irá construir os filtros para a consulta de pesquisa usando as facetas selecionadas pelo usuário.

• BuildHybridQuery irá construir uma consulta de pesquisa híbrida que combina pesquisa de texto completo e pesquisa semântica.

Em seguida, adicione o método de pesquisa:

• SearchBooksAsyncA função realizará a busca usando a consulta híbrida e retornará os resultados, incluindo as agregações para a construção das facetas.

• FormatFacets: irá formatar a resposta de agregações em um dicionário.

• ConvertFacetDictionary: irá converter o dicionário de facetas em um formato mais legível.

O próximo passo é criar os modelos que representarão os dados retornados no hits da consulta Elasticsearch que serão impressos como resultados em nossa página de pesquisa.

Começamos criando o arquivo /Models/Book.cs e adicionando o seguinte:

Em seguida, configure a resposta do Elastic no arquivo /Models/Response.cs e adicione o seguinte:

Configurando uma interface de usuário básica

Em seguida, adicione o componente SearchBar. No arquivo /Components/Elasticsearch/SearchBar.razor , adicione o seguinte:

Este componente contém uma barra de pesquisa e um botão para realizar a pesquisa.

O Blazor oferece grande flexibilidade ao permitir a geração dinâmica de HTML usando código C# dentro do mesmo arquivo.

Em seguida, no arquivo /Components/Elasticsearch/Results.razor construiremos o componente de resultados que exibirá os resultados da pesquisa:

Por fim, precisaremos criar facetas para filtrar os resultados da pesquisa.

Nota: Os facets são filtros que permitem aos usuários refinar os resultados da pesquisa com base em atributos ou categorias específicos, como tipo de produto, faixa de preço ou marca. Esses filtros geralmente são apresentados como opções clicáveis, frequentemente na forma de caixas de seleção, para ajudar os usuários a refinar sua pesquisa e encontrar resultados relevantes com mais facilidade. No contexto do Elasticsearch, os facets são criados usando agregações.

Configuramos as facetas inserindo o seguinte código no arquivo /Components/Elasticsearch/Facet.razor:

Este componente lê de uma agregação terms nos campos author, categories e status e, em seguida, produz uma lista de filtros para enviar de volta ao Elasticsearch.

Agora, vamos juntar tudo.

No arquivo /Components/Pages/Search.razor :

Nossa página está funcionando!

Como você pode ver, a página é funcional, mas carece de estilo. Vamos adicionar um pouco de CSS para deixar a aparência mais organizada e responsiva.

Vamos começar a substituir os estilos de layout. No arquivo Components/Layout/MainLayout.razor.css :

Adicione os estilos para a página de pesquisa no arquivo Components/Pages/Search.razor.css :

Nossa página está começando a ficar melhor:

Vamos dar os toques finais:

Crie os seguintes arquivos:

• Components/Elasticsearch/Facet.razor.css

• Components/Elasticsearch/Results.razor.css

E adicione os estilos para Facet.razor.css:

Para Results.razor.css:

Resultado final:

Para executar o aplicativo, você pode usar o seguinte comando:

dotnet watch

Você conseguiu! Agora você pode pesquisar livros em seu índice Elasticsearch usando a barra de pesquisa e filtrar os resultados por autor, categoria e status.

Realização de buscas semânticas e de texto completo

Por padrão, nosso aplicativo realizará uma pesquisa híbrida usando tanto pesquisa de texto completo quanto pesquisa semântica. Você pode alterar a lógica de pesquisa criando dois métodos separados, um para pesquisa de texto completo e outro para pesquisa semântica, e então selecionando um dos métodos para construir a consulta com base na entrada do usuário.

Adicione os seguintes métodos à classe ElasticsearchService no arquivo /Services/ElasticsearchService.cs :

Ambos os métodos funcionam de forma semelhante ao método BuildHybridQuery , mas realizam apenas pesquisa de texto completo ou pesquisa semântica.

Você pode modificar o método SearchBooksAsync para usar o método de pesquisa selecionado:

Você pode encontrar o formulário de inscrição completo aqui.

Conclusão

Blazor é uma estrutura eficaz que permite criar aplicações web usando C#. O Elasticsearch é um mecanismo de busca poderoso que permite criar aplicativos de busca. Combinando ambos, você pode facilmente criar aplicativos de busca robustos, aproveitando o poder do ESRE para criar uma experiência de busca semântica em pouco tempo.

• Inicie uma discussão com os LLMs implementando um ChatLanguageModel e um ChatMemory

• Manter o histórico do chat na memória para relembrar o contexto de uma discussão anterior com um LLM

Esta postagem do blog aborda como:

• Criar vetores incorporados a partir de exemplos de texto

• Armazene os vetores de incorporação no repositório de incorporações do Elasticsearch.

• Buscar vetores semelhantes

Criar incorporações

Para criar embeddings, precisamos definir um EmbeddingModel para usar. Por exemplo, podemos usar o mesmo modelo mistral que usamos na postagem anterior. Estava correndo com a lhama:

Um modelo é capaz de gerar vetores a partir de texto. Aqui podemos verificar o número de dimensões geradas pelo modelo:

Para gerar vetores a partir de um texto, podemos usar:

Ou, se também quisermos fornecer metadados para nos permitir filtrar por coisas como texto, preço, data de lançamento ou qualquer outra coisa, podemos usar Metadata.from(). Por exemplo, estamos adicionando aqui o nome do jogo como um campo de metadados:

Se você quiser executar este código, consulte a classe Step5EmbedddingsTest.java .

Adicionar o Elasticsearch para armazenar nossos vetores.

LangChain4j fornece um armazenamento de incorporação em memória. Isso é útil para executar testes simples:

Mas, obviamente, isso não funcionaria com conjuntos de dados muito maiores, porque esse armazenamento de dados guarda tudo na memória e não temos memória infinita em nossos servidores. Assim, poderíamos armazenar nossos embeddings no Elasticsearch, que é, por definição, "elástico" e pode ser dimensionado verticalmente e horizontalmente conforme a demanda de dados. Para isso, vamos adicionar o Elasticsearch ao nosso projeto:

Como você deve ter notado, também adicionamos o módulo Elasticsearch TestContainers ao projeto, para que possamos iniciar uma instância do Elasticsearch a partir de nossos testes:

Para usar o Elasticsearch como um armazenamento de dados incorporado, você "simplesmente" precisa trocar o armazenamento de dados em memória do LangChain4j pelo armazenamento de dados do Elasticsearch:

Isso armazenará seus vetores no Elasticsearch em um índice default . Você também pode alterar o nome do índice para algo mais significativo:

Se você quiser executar este código, consulte a classe Step6ElasticsearchEmbedddingsTest.java .

Buscar vetores semelhantes

Para buscar vetores semelhantes, primeiro precisamos transformar nossa pergunta em uma representação vetorial usando o mesmo modelo que usamos anteriormente. Já fizemos isso, então não é difícil fazer de novo. Note que, neste caso, não precisamos dos metadados:

Podemos construir uma solicitação de pesquisa com essa representação da nossa pergunta e pedir ao repositório de embeddings para encontrar os primeiros vetores principais:

Agora podemos iterar sobre os resultados e imprimir algumas informações, como o nome do jogo, que vem dos metadados, e a pontuação:

Como era de se esperar, isso nos dá "Out Run" como o primeiro sucesso:

Se você quiser executar este código, consulte a classe Step7SearchForVectorsTest.java .

Nos bastidores

A configuração padrão do Elasticsearch Embedding Store utiliza a consulta kNN aproximada nos bastidores.

Mas isso poderia ser alterado fornecendo uma configuração diferente (ElasticsearchConfigurationScript) da configuração padrão (ElasticsearchConfigurationKnn) para o armazenamento de incorporação:

A implementação ElasticsearchConfigurationScript executa em segundo plano uma consulta script_score usando uma função cosineSimilarity .

Basicamente, ao ligar:

Isto agora exige:

Nesse caso, o resultado não muda em termos de "ordem", apenas a pontuação é ajustada, pois a chamada cosineSimilarity não usa nenhuma aproximação, mas calcula o cosseno para cada um dos vetores correspondentes:

Se você quiser executar este código, consulte a classe Step7SearchForVectorsTest.java .

Conclusão

Já abordamos a facilidade com que você pode gerar embeddings a partir do seu texto e como você pode armazenar e pesquisar os vizinhos mais próximos no Elasticsearch usando duas abordagens diferentes:

• Usando a consulta aproximada e rápida knn com a opção padrão ElasticsearchConfigurationKnn

• Usando a consulta exata, porém mais lenta, script_score com a opção ElasticsearchConfigurationScript

O próximo passo será construir uma aplicação RAG completa, com base no que aprendemos aqui.

Bem-vindo(a) à Parte 2 do nosso artigo sobre Técnicas Avançadas de RAG! Na parte 1 desta série, configuramos, discutimos e implementamos os componentes de processamento de dados do pipeline RAG avançado:

Nesta parte, vamos prosseguir com a consulta e o teste da nossa implementação. Vamos direto ao assunto!

Índice

• Pesquisar e recuperar, gerar respostas

  • Enriquecendo as consultas com sinônimos

  • HyDE (Incorporação Hipotética de Documentos)

  • Busca híbrida

• Experimentos

  • Resumo dos resultados

  • Teste 1: Quem audita a Elastic?

    • RAG Avançado

    • SimpleRAG

  • Teste 2: receita total em 2023

    • RAG Avançado

    • SimpleRAG

  • Teste 3: De qual produto depende principalmente o crescimento? Quanto?

    • RAG Avançado

    • SimpleRAG

  • Teste 4: Descreva o plano de benefícios para funcionários

    • RAG Avançado

    • SimpleRAG

  • Teste 5: Quais empresas a Elastic adquiriu?

    • RAG Avançado

    • SimpleRAG

• Conclusão

• Apêndice

  • Prompts

    • Pergunta RAG para responder:

    • prompt do gerador de consultas elásticas

    • Possíveis perguntas para o gerador

    • prompt do gerador HyDE

  • Exemplo de consulta de pesquisa híbrida

Pesquisar e recuperar, gerar respostas

Vamos fazer nossa primeira pergunta, idealmente alguma informação encontrada principalmente no relatório anual. Que tal:

Agora, vamos aplicar algumas de nossas técnicas para aprimorar a consulta.

Enriquecendo as consultas com sinônimos

Em primeiro lugar, vamos aumentar a diversidade na formulação da consulta e transformá-la em um formato que possa ser facilmente processado em uma consulta do Elasticsearch. Vamos utilizar o GPT-4o para converter a consulta em uma lista de cláusulas OR. Vamos escrever esta pergunta:

Quando aplicado à nossa consulta, o GPT-4o gera sinônimos da consulta base e vocabulário relacionado.

Na classe ESQueryMaker , defini uma função para dividir a consulta:

Sua função é pegar essa sequência de cláusulas OR e dividi-las em uma lista de termos, permitindo-nos fazer uma correspondência múltipla em nossos campos-chave do documento:

Finalmente, cheguei a esta pergunta:

Isso abrange muito mais aspectos do que a consulta original, reduzindo, esperamos, o risco de perder um resultado de pesquisa por termos esquecido um sinônimo. Mas podemos fazer mais.

Voltar ao topo

HyDE (Incorporação Hipotética de Documentos)

Vamos recorrer ao GPT-4o novamente, desta vez para implementar o HyDE.

A premissa básica do HyDE é gerar um documento hipotético – o tipo de documento que provavelmente conteria a resposta à consulta original. A veracidade ou exatidão do documento não é uma preocupação. Com isso em mente, vamos escrever a seguinte pergunta:

Como a busca vetorial normalmente opera com base na similaridade de vetores de cosseno, a premissa do HyDE é que podemos obter melhores resultados combinando documentos com documentos em vez de consultas com documentos.

O que nos interessa é a estrutura, a fluidez e a terminologia. Não se trata tanto de factualidade. O GPT-4o gera um documento HyDE como este:

Parece bastante convincente, como o candidato ideal para os tipos de documentos que gostaríamos de indexar. Vamos incorporar isso e usar para busca híbrida.

Voltar ao topo

Busca híbrida

Este é o núcleo da nossa lógica de busca. Nosso componente de busca lexical serão as strings da cláusula OR geradas. Nosso componente vetorial denso será um documento HyDE incorporado (também conhecido como vetor de busca). Utilizamos o KNN para identificar de forma eficiente vários documentos candidatos mais próximos do nosso vetor de busca. Por padrão, denominamos nosso componente de busca lexical como "Pontuação com TF-IDF e BM25" . Finalmente, as pontuações lexicais e de vetor denso serão combinadas usando a proporção 30/70 recomendada por Wang et al.

Finalmente, podemos montar uma função RAG. Nosso processo RAG, da pergunta à resposta, seguirá este fluxo:

1. Converter consulta em cláusulas OR.

2. Gere o documento HyDE e incorpore-o.

3. Passe ambos como entradas para a Busca Híbrida.

4. Recuperar os n melhores resultados, inverter a ordem para que a pontuação mais relevante seja a "mais recente" na memória contextual do LLM (Empacotamento Inverso). Exemplo de Empacotamento Inverso: Consulta: "Técnicas de otimização de consultas do Elasticsearch". Documentos recuperados (ordenados por relevância): Ordem invertida para o contexto do LLM: Ao inverter a ordem, a informação mais relevante (1) aparece por último no contexto, potencialmente recebendo mais atenção do LLM durante a geração de respostas.

   1. "Use consultas booleanas para combinar vários critérios de pesquisa de forma eficiente."

   2. "Implementar estratégias de cache para melhorar os tempos de resposta das consultas."

   3. "Otimize os mapeamentos de índice para um desempenho de pesquisa mais rápido."

   4. "Otimize os mapeamentos de índice para um desempenho de pesquisa mais rápido."

   5. "Implementar estratégias de cache para melhorar os tempos de resposta das consultas."

   6. "Use consultas booleanas para combinar vários critérios de pesquisa de forma eficiente."

5. Passe o contexto para o LLM para geração.

Vamos executar nossa consulta e obter a resposta:

Legal. Isso mesmo.

Voltar ao topo

Experimentos

Há uma pergunta importante a ser respondida agora. O que ganhamos investindo tanto esforço e complexidade adicional nessas implementações?

Vamos fazer uma pequena comparação. O pipeline RAG que implementamos em comparação com a busca híbrida básica, sem nenhuma das melhorias que fizemos. Realizaremos uma pequena série de testes para verificar se notamos alguma diferença significativa. Vamos nos referir ao RAG que acabamos de implementar como AdvancedRAG e ao pipeline básico como SimpleRAG.

Resumo dos resultados

Esta tabela resume os resultados de cinco testes de ambos os pipelines RAG. Avaliei a superioridade relativa de cada método com base no detalhamento e na qualidade das respostas, mas essa é uma avaliação totalmente subjetiva. As respostas corretas estão reproduzidas abaixo desta tabela para sua análise. Dito isso, vamos dar uma olhada em como eles se saíram!

O SimpleRAG não conseguiu responder às perguntas 1 e 5. O AdvancedRAG, por sua vez, apresentou respostas muito mais detalhadas nas perguntas 2, 3 e 4. Com base nesse maior nível de detalhamento, considerei as respostas do AdvancedRAG de melhor qualidade.

Teste

Pergunta

Desempenho AdvancedRAG

Desempenho SimpleRAG

Latência RAG Avançada

Latência SimpleRAG

Ganhador

1

Quem audita a Elastic?

Identificou corretamente a PwC como auditora.

Não foi possível identificar o auditor.

11,6s

4,4s

RAG Avançado

2

Qual foi a receita total em 2023?

Forneceu o valor correto da receita. Incluímos contexto adicional com a receita de anos anteriores.

Forneceu o valor correto da receita.

13,3s

2,8s

RAG Avançado

3

De qual produto depende principalmente o crescimento? Quanto?

Identificamos corretamente o Elastic Cloud como o principal fator impulsionador. Inclui contexto geral de receita e detalhes adicionais.

Identificamos corretamente o Elastic Cloud como o principal fator impulsionador.

14,1s

12,8s

RAG Avançado

4

Descreva o plano de benefícios para funcionários.

Apresentou uma descrição completa dos planos de aposentadoria, programas de saúde e outros benefícios. Inclui valores de contribuição específicos para diferentes anos.

Apresentou uma boa visão geral dos benefícios, incluindo remuneração, planos de aposentadoria, ambiente de trabalho e o programa Elastic Cares.

26,6s

11,6s

RAG Avançado

5

Quais empresas a Elastic adquiriu?

As aquisições recentes mencionadas no relatório foram listadas corretamente (CmdWatch, Build Security, Optimyze). Foram fornecidas algumas datas de aquisição e preços de compra.

Não foi possível recuperar informações relevantes do contexto fornecido.

11,9s

2,7s

RAG Avançado

Teste 1: Quem audita a Elastic?

RAG Avançado

SimpleRAG

Resumo: A SimpleRAG não identificou a PwC como auditora.

Bem, isso é realmente surpreendente. Parece ser uma falha de busca por parte do SimpleRAG. Não foram recuperados documentos relacionados à auditoria. Vamos diminuir um pouco a dificuldade no próximo teste.

Teste 2: receita total em 2023

RAG Avançado

SimpleRAG

Resumo: Ambas as equipes RAG acertaram a resposta: receita total de US$ 1.068.989.000 em 2023.

Ambos estavam bem aqui. Parece que a AdvancedRAG pode ter adquirido uma gama mais ampla de documentos? Certamente a resposta é mais detalhada e incorpora informações de anos anteriores. Isso era de se esperar, considerando as melhorias que fizemos, mas ainda é muito cedo para afirmar algo com certeza.

Vamos aumentar a dificuldade.

Teste 3: De qual produto depende principalmente o crescimento? Quanto?

RAG Avançado

SimpleRAG

Resumo: Ambos os RAGs identificaram corretamente o Elastic Cloud como o principal motor de crescimento. No entanto, o AdvancedRAG inclui mais detalhes, levando em consideração as receitas de assinaturas e o crescimento da base de clientes, e menciona explicitamente outras ofertas da Elastic.

Teste 4: Descreva o plano de benefícios para funcionários

RAG Avançado

SimpleRAG

Resumo: A AdvancedRAG aborda o assunto com muito mais profundidade e detalhes, mencionando o plano 401K para funcionários baseados nos EUA, além de definir planos de contribuição fora dos EUA. O texto também menciona planos de saúde e bem-estar, mas omite o programa Elastic Cares, que é citado pela SimpleRAG.

Teste 5: Quais empresas a Elastic adquiriu?

RAG Avançado

SimpleRAG

Resumo: O SimpleRAG não recupera nenhuma informação relevante sobre aquisições, resultando em uma resposta incorreta. A AdvancedRAG lista corretamente a CmdWatch, a Build Security e a Optimyze, que foram as principais aquisições mencionadas no relatório.

Voltar ao topo

Conclusão

Com base em nossos testes, nossas técnicas avançadas parecem aumentar o alcance e a profundidade das informações apresentadas, potencialmente melhorando a qualidade das respostas RAG.

Além disso, pode haver melhorias na confiabilidade, já que perguntas formuladas de maneira ambígua, como Which companies did Elastic acquire? e Who audits Elastic foram respondidas corretamente pelo AdvancedRAG, mas não pelo SimpleRAG.

No entanto, vale a pena ter em mente que, em 3 de 5 casos, o pipeline RAG básico, incorporando a Busca Híbrida, mas nenhuma outra técnica, conseguiu produzir respostas que capturaram a maior parte das informações essenciais.

Devemos observar que, devido à incorporação de LLMs nas fases de preparação e consulta de dados, a latência do AdvancedRAG é geralmente de 2 a 5 vezes maior que a do SimpleRAG. Este é um custo significativo que pode tornar o AdvancedRAG adequado apenas para situações em que a qualidade da resposta é priorizada em detrimento da latência.

Os custos significativos de latência podem ser atenuados usando um modelo de linguagem latente (LLM) menor e mais barato, como o Claude Haiku ou o GPT-4o-mini, na fase de preparação dos dados. Salve os modelos avançados para geração de respostas.

Isso está de acordo com as conclusões de Wang et al. Conforme demonstram os resultados, quaisquer melhorias realizadas são relativamente incrementais. Resumindo, o método RAG básico e simples permite chegar a um produto final bastante satisfatório, sendo ainda mais barato e rápido. Para mim, é uma conclusão interessante. Para casos de uso em que velocidade e eficiência são essenciais, o SimpleRAG é a escolha sensata. Para casos de uso em que é necessário extrair o máximo desempenho possível, as técnicas incorporadas no AdvancedRAG podem oferecer uma solução.

Voltar ao topo

Apêndice

Prompts

Pergunta RAG para responder:

Solicitação para que o LLM gere respostas com base na consulta e no contexto.

prompt do gerador de consultas elásticas

Solicitação para enriquecer as consultas com sinônimos e convertê-las para o formato OU.

Possíveis perguntas para o gerador

Solicitação para gerar possíveis perguntas e enriquecer os metadados do documento.

prompt do gerador HyDE

Solicitação para gerar documentos hipotéticos usando o HyDE

Exemplo de consulta de pesquisa híbrida

O artigo recente "Searching for Best Practices in Retrieval-Augmented Generation" avalia empiricamente a eficácia de várias técnicas de aprimoramento de RAG (Geração Aumentada de Recuperação), com o objetivo de convergir para um conjunto de melhores práticas para RAG.

Implementaremos algumas dessas boas práticas propostas, principalmente aquelas que visam melhorar a qualidade da busca (Fragmentação de Sentenças, HyDE, Empacotamento Reverso).

Por uma questão de brevidade, omitiremos as técnicas focadas na melhoria da eficiência (Classificação e Sumarização de Consultas).

Implementaremos também algumas técnicas que não foram abordadas, mas que eu pessoalmente considero úteis e interessantes (Inclusão de Metadados, Incorporação Composta de Múltiplos Campos, Enriquecimento de Consultas).

Por fim, realizaremos um breve teste para verificar se a qualidade dos nossos resultados de pesquisa e das respostas geradas melhorou em comparação com a linha de base. Vamos lá!

Visão geral do RAG

O RAG visa aprimorar os LLMs (Modelos de Aprendizagem Baseados em Aprendizagem) recuperando informações de bases de conhecimento externas para enriquecer as respostas geradas. Ao fornecer informações específicas do domínio, os LLMs podem ser rapidamente adaptados para casos de uso fora do escopo de seus dados de treinamento; sendo significativamente mais baratos do que o ajuste fino e mais fáceis de manter atualizados.

As medidas para melhorar a qualidade do RAG normalmente se concentram em duas vertentes:

1. Aprimorar a qualidade e a clareza da base de conhecimento.

2. Melhorar a abrangência e a especificidade das consultas de pesquisa.

Essas duas medidas alcançarão o objetivo de aumentar as chances de o mestrando em Direito ter acesso a fatos e informações relevantes e, portanto, ser menos propenso a ter alucinações ou recorrer ao seu próprio conhecimento, que pode estar desatualizado ou ser irrelevante.

A diversidade de métodos é difícil de esclarecer em poucas frases. Vamos direto à implementação para que as coisas fiquem mais claras.

Índice

• Visão geral

  • Índice

• Configurar

• Ingestão, processamento e incorporação de documentos

  • Ingestão de dados

  • Segmentação por tokens e em nível de frase

  • Inclusão e geração de metadados

    • Palavras-chave extraídas pelo TextRank

    • Possíveis perguntas geradas pelo GPT-4o

    • Entidades extraídas pelo Spacy

  • Incorporações compostas de múltiplos campos

    • Indexação para Elastic

• Pausa para o gato

• Apêndice

  • Definições

Configurar

Todo o código pode ser encontrado no repositório Searchlabs.

Em primeiro lugar, o mais importante. Você precisará do seguinte:

1. Implantação na Nuvem Elástica

2. Uma API LLM - Neste notebook, estamos usando uma implantação do GPT-4o no Azure OpenAI.

3. Python versão 3.12.4 ou posterior

Executaremos todo o código do notebook main.ipynb.

Faça o clone do repositório usando o Git, navegue até supporting-blog-content/advanced-rag-techniques e execute os seguintes comandos:

Feito isso, crie um arquivo .env. Abra o arquivo e preencha os seguintes campos (Referenciado em .env.example). Agradecimentos ao meu coautor, Claude-3.5, pelos comentários úteis.

Em seguida, selecionaremos o documento a ser importado e o colocaremos na pasta de documentos. Para este artigo, usaremos o Relatório Anual da Elastic NV de 2023. É um documento bastante complexo e denso, perfeito para testar a resistência das nossas técnicas RAG.

Agora que está tudo pronto, vamos à ingestão. Abra o arquivo main.ipynb e execute as duas primeiras células para importar todos os pacotes e inicializar todos os serviços.

Voltar ao topo

Ingestão, processamento e incorporação de documentos

Ingestão de dados

• Nota pessoal: Estou impressionado com a praticidade do LlamaIndex. Antigamente, antes dos mestrados em direito e do LlamaIndex, importar documentos de vários formatos era um processo doloroso de coletar pacotes esotéricos de todos os cantos. Agora, tudo se resume a uma única chamada de função. Selvagem.

O SimpleDirectoryReader carregará todos os documentos em directory_path. Para arquivos .pdf , ele retorna uma lista de objetos de documento, que eu converto em dicionários Python porque acho mais fácil trabalhar com eles.

Cada dicionário contém o conteúdo da chave no campo text . Também contém metadados úteis, como número da página, nome do arquivo, tamanho do arquivo e tipo.

Voltar ao topo

Segmentação por tokens e em nível de frase

A primeira coisa a fazer é reduzir nossos documentos a blocos de tamanho padrão (para garantir consistência e facilidade de gerenciamento). Os modelos de incorporação possuem limites de token únicos (tamanho máximo de entrada que podem processar). Os tokens são as unidades básicas de texto que modelam o processo. Para evitar a perda de informações (truncamento ou omissão de conteúdo), devemos fornecer textos que não excedam esses limites (dividindo textos mais longos em segmentos menores).

O particionamento (chunking) tem um impacto significativo no desempenho. Idealmente, cada bloco representaria uma informação autossuficiente, capturando informações contextuais sobre um único tópico. Os métodos de fragmentação incluem a fragmentação ao nível da palavra, em que os documentos são divididos pela contagem de palavras, e a fragmentação semântica, que utiliza um modelo de lógica de divisão (LLM) para identificar pontos de quebra lógicos.

A segmentação em nível de palavra é barata, rápida e fácil, mas apresenta o risco de dividir frases e, assim, quebrar o contexto. A fragmentação semântica torna-se lenta e dispendiosa, especialmente se estivermos lidando com documentos como o Relatório Anual da Elastic, com 116 páginas.

Vamos optar por uma abordagem intermediária. A segmentação em nível de frase ainda é simples, mas pode preservar o contexto de forma mais eficaz do que a segmentação em nível de palavra, além de ser significativamente mais barata e rápida. Além disso, implementaremos uma janela deslizante para capturar parte do contexto circundante e atenuar o impacto da divisão de parágrafos.

A classe Chunker recebe o tokenizador do modelo de incorporação para codificar e decodificar o texto. Agora vamos construir blocos de 512 tokens cada, com uma sobreposição de 20 tokens. Para isso, vamos dividir o texto em frases, tokenizar essas frases e, em seguida, adicionar as frases tokenizadas ao nosso bloco atual até que não possamos adicionar mais sem ultrapassar nosso limite de tokens.

Finalmente, decodifique as frases de volta ao texto original para incorporação, armazenando-o em um campo chamado original_text. Os blocos são armazenados em um campo chamado chunk. Para reduzir o ruído (ou seja, documentos inúteis), descartaremos quaisquer documentos com menos de 50 tokens de comprimento.

Vamos executar o programa em nossos documentos:

E receba trechos de texto com a seguinte aparência:

Voltar ao topo

Inclusão e geração de metadados

Dividimos nossos documentos em partes menores. Agora é hora de enriquecer os dados. Desejo gerar ou extrair metadados adicionais. Esses metadados adicionais podem ser usados para influenciar e melhorar o desempenho da busca.

Vamos definir uma classe DocumentEnricher , cuja função é receber uma lista de documentos (dicionários Python) e uma lista de funções de processamento. Essas funções serão executadas na coluna original_text dos documentos e armazenarão suas saídas em novos campos.

Primeiro, extraímos as palavras-chave usando o TextRank. O TextRank é um algoritmo baseado em grafos que extrai frases e sentenças-chave de um texto, classificando sua importância com base nas relações entre as palavras.

Em seguida, vamos gerar perguntas potenciais usando o GPT-4o.

Por fim, vamos extrair as entidades usando o Spacy.

Como o código para cada um deles é bastante extenso e complexo, vou evitar reproduzi-lo aqui. Caso tenha interesse, os arquivos estão marcados nos exemplos de código abaixo.

Vamos executar o enriquecimento de dados:

E veja os resultados:

Palavras-chave extraídas pelo TextRank

Essas palavras-chave representam os tópicos principais do bloco. Se a consulta estiver relacionada à segurança cibernética, a pontuação desse segmento será aumentada.

Possíveis perguntas geradas pelo GPT-4o

Essas perguntas em potencial podem corresponder diretamente às consultas do usuário, oferecendo um aumento na pontuação. Solicitamos ao GPT-4o que gere perguntas que possam ser respondidas usando as informações encontradas no bloco atual.

Entidades extraídas pelo Spacy

Essas entidades têm uma finalidade semelhante à das palavras-chave, mas capturam os nomes de organizações e indivíduos, que a extração por palavras-chave pode não incluir.

Voltar ao topo

Incorporações compostas de múltiplos campos

Agora que enriquecemos nossos documentos com metadados adicionais, podemos aproveitar essas informações para criar representações vetoriais mais robustas e sensíveis ao contexto.

Vamos recapitular o ponto em que nos encontramos no processo. Cada documento contém quatro áreas de interesse.

Cada campo representa uma perspectiva diferente sobre o contexto do documento, podendo destacar uma área-chave para o mestrado em Direito (LLM) se concentrar.

O plano é incorporar cada um desses campos e, em seguida, criar uma soma ponderada das incorporações, conhecida como Incorporação Composta.

Com sorte, essa incorporação composta permitirá que o sistema se torne mais sensível ao contexto, além de introduzir mais um hiperparâmetro ajustável para controlar o comportamento de busca.

Primeiro, vamos incorporar cada campo e atualizar cada documento no local, usando nosso modelo de incorporação definido localmente e importado no início do notebook main.ipynb.

Cada função de incorporação retorna o campo da incorporação, que é simplesmente o campo de entrada original com um sufixo _embedding .

Vamos agora definir os pesos da nossa incorporação composta:

Os pesos permitem atribuir prioridades a cada componente, com base no seu caso de uso e na qualidade dos seus dados. Intuitivamente, a magnitude dessas ponderações depende do valor semântico de cada componente. Como o texto em si é de longe o mais rico, atribuo uma ponderação de 70%. Como as entidades são as menores, sendo apenas uma lista de nomes de organizações ou pessoas, atribuo a elas uma ponderação de 5%. A configuração precisa desses valores deve ser determinada empiricamente, caso a caso, para cada situação específica.

Finalmente, vamos escrever uma função para aplicar as ponderações e criar nossa representação composta. Também excluiremos todos os elementos incorporados dos componentes para economizar espaço.

Com isso, concluímos o processamento de nossos documentos. Agora temos uma lista de objetos de documento com a seguinte aparência:

Indexação para Elastic

Vamos fazer o upload em massa de nossos documentos para o Elastic Search. Para esse propósito, há muito tempo defini um conjunto de funções auxiliares elásticas em elastic_helpers.py. É um trecho de código muito extenso, então vamos nos ater à análise das chamadas de função.

es_bulk_indexer.bulk_upload_documents Funciona com qualquer lista de objetos de dicionário, aproveitando os convenientes mapeamentos dinâmicos do Elasticsearch.

Acesse o Kibana e verifique se todos os documentos foram indexados. Deveriam ser 224. Nada mal para um documento tão grande!

Voltar ao topo

Pausa para o gato

Vamos fazer uma pausa, o artigo está um pouco denso, eu sei. Vejam só o meu gato:

Adorável. O chapéu sumiu e eu suspeito que ela o roubou e escondeu em algum lugar :(

Parabéns por ter chegado até aqui :)

Junte-se a mim na Parte 2 para testes e avaliação do nosso pipeline RAG!

Apêndice

Definições

1. Segmentação de Frases

• Uma técnica de pré-processamento usada em sistemas RAG para dividir o texto em unidades menores e significativas.

• Processo:

  1. Entrada: Bloco grande de texto (ex.: documento, parágrafo)

  2. Saída: Segmentos de texto menores (normalmente frases ou pequenos grupos de frases)

• Propósito:

  • Cria segmentos de texto granulares e específicos ao contexto.

  • Permite uma indexação e recuperação mais precisas.

  • Melhora a relevância das informações recuperadas em sistemas RAG.

• Características:

  • Os segmentos têm significado semântico.

  • Podem ser indexados e recuperados independentemente.

  • Frequentemente preserva algum contexto para garantir a compreensibilidade de forma independente.

• Benefícios:

  • Aumenta a precisão de recuperação

  • Permite uma ampliação mais focada em pipelines RAG.

2. HyDE (Incorporação Hipotética de Documentos)

• Uma técnica que utiliza um modelo de lógica latente (LLM) para gerar um documento hipotético para expansão de consultas em sistemas RAG.

• Processo:

  1. Inserir consulta em um LLM

  2. O LLM gera um documento hipotético que responde à pergunta.

  3. Incorpore o documento gerado

  4. Use o embedding para busca vetorial

• Principal diferença:

  • RAG tradicional: relaciona a consulta aos documentos.

  • HyDE: Correspondência entre documentos.

• Propósito:

  • Melhorar o desempenho de recuperação de dados, especialmente para consultas complexas ou ambíguas.

  • Captura um contexto semântico mais rico do que uma consulta curta.

• Benefícios:

  • Aproveita o conhecimento do LLM para ampliar as consultas.

  • Pode potencialmente melhorar a relevância dos documentos recuperados.

• Desafios:

  • Requer inferência LLM adicional, aumentando a latência e o custo.

  • O desempenho depende da qualidade do documento hipotético gerado.

3. Reembalagem reversa

• Uma técnica utilizada em sistemas RAG para reordenar os resultados da pesquisa antes de passá-los para o LLM.

• Processo:

  1. O mecanismo de busca (por exemplo, Elasticsearch) retorna documentos em ordem decrescente de relevância.

  2. A ordem é invertida, colocando o documento mais relevante por último.

• Propósito:

  • Explora o viés de recência dos mestrados em direito, que tendem a se concentrar mais nas informações mais recentes em seu contexto.

  • Garante que as informações mais relevantes sejam as mais "atualizadas" na janela de contexto do LLM.

• Exemplo: Ordem original: [Mais relevante, Segundo mais relevante, Terceiro mais relevante, ...] Ordem inversa: [..., Terceiro mais relevante, Segundo mais relevante, Mais relevante]

4. Classificação de consultas

• Uma técnica para otimizar a eficiência do sistema RAG, determinando se uma consulta requer RAG ou se pode ser respondida diretamente pelo LLM.

• Processo:

  1. Desenvolver um conjunto de dados personalizado específico para o LLM em uso.

  2. Treinar um modelo de classificação especializado

  3. Utilize o modelo para categorizar as consultas recebidas.

• Propósito:

  • Melhore a eficiência do sistema evitando o processamento desnecessário de RAG (raiz, grafite e agregação).

  • Direcione as consultas para o mecanismo de resposta mais apropriado.

• Requisitos:

  • Conjunto de dados e modelo específicos para LLM

  • Aperfeiçoamento contínuo para manter a precisão.

• Benefícios:

  • Reduz a sobrecarga computacional para consultas simples.

  • Potencialmente melhora o tempo de resposta para consultas que não sejam RAG.

5. Resumo

• Uma técnica para condensar documentos recuperados em sistemas RAG.

• Processo:

  1. Recuperar documentos relevantes

  2. Gere resumos concisos de cada documento.

  3. Utilize resumos em vez de documentos completos no pipeline RAG.

• Propósito:

  • Melhore o desempenho RAG concentrando-se em informações essenciais.

  • Reduzir o ruído e a interferência de conteúdo menos relevante

• Benefícios:

  • Potencialmente melhora a relevância das respostas do LLM

  • Permite a inclusão de mais documentos dentro dos limites do contexto.

• Desafios:

  • Risco de perder detalhes importantes na sumarização.

  • Sobrecarga computacional adicional para geração de resumos.

6. Inclusão de Metadados

• Uma técnica para enriquecer documentos com informações contextuais adicionais.

• Tipos de metadados:

  • Palavras-chave

  • Títulos

  • Datas

  • Detalhes da autoria

  • Resumos

• Propósito:

  • Aumentar a informação contextual disponível para o sistema RAG

  • Proporcionar aos alunos de mestrado em Direito uma compreensão mais clara do conteúdo e da relevância dos documentos.

• Benefícios:

  • Potencialmente melhora a precisão da recuperação.

  • Aumenta a capacidade do LLM de avaliar a utilidade dos documentos.

• Implementação:

  • Pode ser feito durante o pré-processamento do documento.

  • Pode exigir etapas adicionais de extração ou geração de dados.

7. Incorporações compostas de múltiplos campos

• Uma técnica avançada de incorporação para sistemas RAG que cria incorporações separadas para diferentes componentes do documento.

• Processo:

  1. Identifique os campos relevantes (ex.: título, palavras-chave, sinopse, conteúdo principal).

  2. Gere embeddings separados para cada campo.

  3. Combine ou armazene esses embeddings para uso na recuperação de informações.

• Diferença em relação à abordagem padrão:

  • Tradicional: Incorporação única para todo o documento.

  • Composição: Incorporação múltipla para diferentes aspectos do documento

• Propósito:

  • Criar representações de documentos mais matizadas e sensíveis ao contexto.

  • Capturar informações de uma variedade maior de fontes em um documento.

• Benefícios:

  • Potencialmente melhora o desempenho em consultas ambíguas ou multifacetadas.

  • Permite uma ponderação mais flexível de diferentes aspectos do documento na recuperação.

• Desafios:

  • Aumento da complexidade na incorporação de processos de armazenamento e recuperação

  • Pode exigir algoritmos de correspondência mais sofisticados.

8. Enriquecimento de consultas

• Uma técnica para expandir a consulta original com termos relacionados, a fim de melhorar o alcance da pesquisa.

• Processo:

  1. Analise a consulta original

  2. Gere sinônimos e frases semanticamente relacionadas.

  3. Aprimore a consulta com estes termos adicionais.

• Propósito:

  • Aumentar o leque de correspondências potenciais no conjunto de documentos.

  • Melhorar o desempenho de recuperação de dados para consultas com linguagem específica ou técnica.

• Benefícios:

  • Pode recuperar documentos relevantes que não correspondam exatamente aos termos da consulta original.

  • Pode ajudar a superar a incompatibilidade de vocabulário entre consultas e documentos.

• Desafios:

  • Risco de desvio de consulta se não for implementado com cuidado.

  • Pode aumentar a sobrecarga computacional no processo de recuperação.

Voltar ao topo

A busca vetorial está revolucionando a maneira como realizamos buscas de similaridade, principalmente em campos como IA e machine learning. Com a crescente adoção de modelos de incorporação vetorial, a capacidade de buscar com eficiência milhões de vetores de alta dimensão torna-se crítica.

Quando se trata de melhorar bancos de dados vetoriais, a Elastic e o OpenSearch adotaram abordagens notavelmente diferentes. A Elastic investiu muito na otimização do Apache Lucene junto com o Elasticsearch para elevá-los como a melhor opção para aplicações de busca vetorial. Em contraste, o OpenSearch ampliou seu foco, integrando outras implementações de busca vetorial e explorando além do escopo do Lucene. Nosso foco no Lucene é estratégico, permitindo-nos fornecer suporte altamente integrado na nossa versão do Elasticsearch, resultando em um conjunto aprimorado de recursos em que cada componente complementa e amplifica as capacidades do outro.

Este blog apresenta uma comparação detalhada entre o Elasticsearch 8.14 e o OpenSearch 2.14, levando em conta diferentes configurações e motores vetoriais. Nesta análise de desempenho, o Elasticsearch provou ser a plataforma superior para operações de busca vetorial, e os próximos recursos ampliarão as diferenças ainda mais significativamente. Quando comparado com o OpenSearch, ele se destacou em todas as faixas de benchmark — oferecendo desempenho de 2x a 12x mais rápido em média. Isso ocorreu em situações que usam quantidades e dimensões vetoriais variadas, incluindo so_vector (2 milhões de vetores, 768D), openai_vector (2,5 milhões de vetores, 1536D) e dense_vector (10 milhões de vetores, 96D), todos disponíveis neste repositório junto com os scripts do Terraform para provisão de toda a infraestrutura necessária nos manifestos do Google Cloud e do Kubernetes para executar os testes.

Os resultados detalhados neste blog complementam os resultados de um estudo publicado antes e validado por terceiros que mostra que o Elasticsearch é 40%–140% mais rápido do que o OpenSearch nas operações de análise de busca mais comuns: consulta de texto, ordenação, intervalo, histograma de data e filtro de termos. Agora podemos adicionar outro diferenciador: busca vetorial.

Até 12x mais rápido, pronto para uso

Nossos benchmarks focados nos quatro conjuntos de dados vetoriais envolveram buscas de KNN aproximado e KNN exato, considerando diferentes tamanhos, dimensões e configurações, totalizando 40.189.820 solicitações de busca não armazenadas em cache. Os resultados: o Elasticsearch é até 12 vezes mais rápido do que o OpenSearch para busca vetorial e, portanto, requer menos recursos computacionais.

Figura 1: Tarefas agrupadas para ANN e KNN Exato em diferentes combinações no Elasticsearch e OpenSearch.

Os grupos como knn-10-100 significam uma busca KNN com e . Na busca vetorial HNSW, determina o número de vizinhos mais próximos a serem recuperados para um vetor de consulta. Especifica quantos vetores semelhantes devem ser encontrados como resultado. define o número de vetores candidatos a serem recuperados em cada segmento. Mais candidatos podem melhorar a precisão, mas exigem maiores recursos computacionais.

Também testamos com diferentes técnicas de quantização e aproveitamos otimizações específicas do mecanismo; os resultados detalhados para cada trilha, tarefa e mecanismo de vetor estão disponíveis abaixo.

KNN exato e KNN aproximado

Ao lidar com conjuntos de dados e casos de uso variados, a abordagem correta para busca vetorial será diferente. Neste blog, todas as tarefas declaradas como knn-* como knn-10-100 usam KNN aproximado e script-score-* se referem ao KNN exato, mas qual é a diferença entre elas e por que são importantes?

Em essência, se você estiver lidando com conjuntos de dados mais substanciais, o método preferido é o Approximate K-Nearest Neighbor (ANN) devido à escalabilidade superior. Para conjuntos de dados mais modestos que podem exigir um processo de filtragem, o método Exact K-Nearest Neighbor (KNN) é ideal.

O KNN exato utiliza um método de força bruta, calculando a distância entre um vetor e todos os outros vetores no conjunto de dados. Em seguida, classifica essas distâncias para encontrar os vizinhos mais próximos. Embora esse método garanta uma correspondência exata, ele enfrenta desafios de escalabilidade para conjuntos de dados grandes e de alta dimensão. No entanto, há muitos casos em que o KNN exato é necessário:

• Reclassificação: em casos que envolvem buscas lexicais ou semânticas seguidas de reclassificação baseada em vetores, o KNN exato é essencial. Por exemplo, em um mecanismo de busca de produtos, os resultados de busca iniciais podem ser filtrados com base em consultas textuais (por exemplo, palavras-chave, categorias) e, em seguida, os vetores associados aos itens filtrados são usados para uma avaliação de similaridade mais precisa.

• Personalização: ao lidar com um grande número de usuários, cada um representado por um número relativamente pequeno (como 1 milhão) de vetores distintos, a ordenação do índice por metadados específicos do usuário (por exemplo, user_id) e a pontuação de força bruta com vetores torna-se eficiente. Essa abordagem permite recomendações personalizadas ou entrega de conteúdo com base em comparações precisas de vetores adaptadas às preferências individuais do usuário.

O Exact KNN, portanto, garante que a classificação final e as recomendações baseadas na similaridade vetorial sejam precisas e adaptadas às preferências do usuário.

O KNN aproximado (ou ANN), por outro lado, utiliza métodos para deixar a busca de dados mais rápida e eficiente do que o KNN exato, principalmente em conjuntos de dados grandes e de alta dimensão. Em vez de uma abordagem de força bruta, que mede a distância exata mais próxima entre uma consulta e todos os pontos, gerando desafios de computação e redimensionamento, a ANN utiliza certas técnicas para reestruturar eficientemente os índices e as dimensões dos vetores buscáveis no conjunto de dados. Embora isso possa causar uma pequena imprecisão, aumenta significativamente a velocidade do processo de busca, sendo uma alternativa eficaz para lidar com grandes conjuntos de dados.

Neste blog, todas as tarefas declaradas como knn-*, como knn-10-100, usam KNN aproximado e script-score-* referem-se a KNN exato.

Metodologia de teste

Embora o Elasticsearch e o OpenSearch sejam semelhantes em termos de API para operações de busca do BM25, já que o último é uma bifurcação do primeiro, não é o caso do Vector Search, que foi introduzido após o fork. O OpenSearch adotou uma abordagem diferente do Elasticsearch quando se trata de algoritmos, introduzindo dois outros mecanismos — nmslib e faiss — além do lucene, cada um com configurações e limitações específicas (por exemplo, nmslib no OpenSearch não permite filtros, um recurso essencial para muitos casos de uso).

Todos os três mecanismos usam o algoritmo Hierarchical Navigable Small World (HNSW), que é eficiente para busca aproximada do vizinho mais próximo e principalmente poderoso ao lidar com dados de alta dimensão. É importante observar que o faiss também aceita um segundo algoritmo, ivf, mas como ele requer pré-treinamento no conjunto de dados, vamos nos concentrar exclusivamente no HNSW. A ideia de núcleo do HNSW é organizar os dados em várias camadas de gráficos conectados, com cada camada representando uma granularidade diferente do conjunto de dados. A busca começa na camada superior com a visualização mais grosseira e avança para camadas cada vez mais finas até chegar ao nível básico.

Ambos os mecanismos de busca foram testados sob condições idênticas em um ambiente controlado para garantir condições de teste justas. O método aplicado é semelhante a esta comparação de desempenho já publicada, com pools de node dedicados para Elasticsearch, OpenSearch e Rally. O script terraform está disponível (junto com todas as fontes) para fazer a provisão de um cluster Kubernetes com:

• 1 Node pool para Elasticsearch com 3 máquinas e2-standard-32 (128 GB de RAM e 32 CPUs)

• 1 Node pool para OpenSearch com 3 máquinas e2-standard-32 (128 GB de RAM e 32 CPUs)

• 1 Node pool para Rally com 2 t2a-standard-16 máquinas (64GB de RAM e 16 CPUs)

Cada "trilha" (ou teste) foi executada 10 vezes em cada configuração, que incluía diferentes motores, diferentes configurações e diferentes tipos de vetor. As trilhas têm tarefas que se repetem entre 1.000 e 10.000 vezes, dependendo da trilha. Se uma das tarefas em uma trilha falhou, por exemplo, devido a um tempo-limite de rede, então todas as tarefas foram descartadas, de modo que todos os resultados representam trilhas que começaram e terminaram sem problemas. Todos os resultados dos testes são validados estatisticamente, garantindo que as melhorias não sejam coincidência.

Resultados detalhados

Por que comparar usando o 99º percentil e não a latência média? Considere um exemplo hipotético de preços médios de casas em um determinado bairro. O preço médio pode indicar uma área cara, mas, em uma inspeção mais detalhada, pode ser que a maioria das casas tenha um valor muito mais baixo, com apenas algumas propriedades de luxo inflando o valor médio. Isso ilustra como o preço médio pode não representar com precisão todo o espectro de valores das casas na área. Isso é semelhante a examinar os tempos de resposta, onde a média pode ocultar problemas críticos.

Tarefas

• KNN aproximado com k:10 n:50

• KNN Aproximado com k:10 n:100

• KNN aproximado com k:100 n:1000

• KNN aproximado com k:10 n:50 e filtros de palavras-chave

• KNN aproximado com k:10 n:100 e filtros de palavras-chave

• KNN aproximado com k:100 n:1000 e filtros de palavras-chave

• KNN aproximado com k:10 n:100 em conjunto com indexação

• KNN exato (pontuação do script)

Motores vetoriais

• lucene no Elasticsearch e OpenSearch, ambos na versão 9.10

• faiss no OpenSearch

• nmslib no OpenSearch

Tipos de vetor

• hnsw no Elasticsearch e OpenSearch

• int8_hnsw no Elasticsearch (HNSW com quantização automática de 8 bits: link)

• sq_fp16 hnsw no OpenSearch (HNSW com quantização automática de 16 bits: link)

Busca de segmento simultânea e pronta para uso

Como você provavelmente sabe, o Lucene é uma biblioteca de mecanismo de busca de texto de alto desempenho escrita em Java que serve como espinha dorsal para muitas plataformas de busca, como Elasticsearch, OpenSearch e Solr. No núcleo, o Lucene organiza os dados em segmentos, que são essencialmente índices independentes que permitem ao Lucene executar buscas com mais eficiência. Portanto, quando você emite uma busca para qualquer mecanismo de busca baseado em Lucene, sua busca acabará sendo executada nesses segmentos, sequencialmente ou em paralelo.

O OpenSearch introduziu a busca simultânea por segmentos como uma opção e não a utiliza como padrão. Você deve habilitá-la usando uma configuração especial de índice index.search.concurrent_segment_search.enabled conforme detalhado aqui, com algumas limitações.

O Elasticsearch, por outro lado, busca em segmentos simultaneamente prontos para uso; portanto, as comparações que fazemos neste blog levarão em consideração, além dos diferentes mecanismos vetoriais e tipos de vetores, também as diferentes configurações:

• Elasticsearch ootb: Elasticsearch pronto para uso, com busca de segmento simultânea;

• OpenSearch ootb: sem busca de segmento simultânea habilitada;

• OpenSearch css: com busca de segmento simultânea habilitada

Agora vamos nos aprofundar em alguns resultados detalhados para cada conjunto de dados vetoriais testado:

2,5 milhões de vetores, 1536 dimensões (openai_vector)

Começando com a faixa mais simples, mas também a maior em termos de dimensões, openai_vector - que usa o conjunto de dados NQ enriquecido com embeddings gerados usando o modelo text-embedding-ada-002 do OpenAI. É o mais simples, pois testa apenas o KNN aproximado e tem apenas 5 tarefas. Ele testa de forma autônoma (sem indexação) e junto com a indexação, usando um único cliente e 8 clientes simultâneos.

Tarefas

• standalone-search-knn-10-100-multiple-clients: buscando em 2,5 milhões de vetores com 8 clientes simultaneamente, k: 10 e n:100

• standalone-search-knn-100-1000-multiple-clients: buscando em 2,5 milhões de vetores com 8 clientes simultaneamente, k: 100 e n:1000

• standalone-search-knn-10-100-single-client: buscando em 2,5 milhões de vetores com um único cliente, k: 10 e n:100

• standalone-search-knn-100-1000-single-client: buscando em 2,5 milhões de vetores com um único cliente, k: 100 e n:1000

• parallel-documents-indexing-search-knn-10-100: buscando em 2,5 milhões de vetores e, ao mesmo tempo, indexando 100.000 documentos adicionais, k:10 e n:100

O desempenho médio do p99 é descrito abaixo:

Aqui, observamos que o Elasticsearch é entre 3x-8x mais rápido do que o OpenSearch ao realizar a busca vetorial junto com a indexação (i.e. leitura+escrita) com :10 e :100 e 2x-3x mais rápido sem indexação para os mesmos k e n. Para :100 e :1000 (standalone-search-knn-100-1000-single-client e standalone-search-knn-100-1000-multiple-clients ), o Elasticsearch é 2x a 7x mais rápido que o OpenSearch, em média.

Os resultados detalhados mostram os casos exatos e os mecanismos vetoriais comparados:

Recall

knn-recall-10-100

knn-recall-100-1000

Elasticsearch-8.14.0@lucene-hnsw

0,969485

0,995138

Elasticsearch-8.14.0@lucene-int8_hnsw

0,781445

0,784817

OpenSearch-2.14.0@lucene-hnsw

0,96519

0,995422

OpenSearch-2.14.0@faiss

0,984154

0,98049

OpenSearch-2.14.0@faiss-sq_fp16

0,980012

0,97721

OpenSearch-2.14.0@nmslib

0,982532

0,99832

10 milhões de vetores, 96 dimensões (dense_vector)

Em dense_vector com 10 milhões de vetores e 96 dimensões. Ele é baseado no conjunto de dados de imagens Yandex DEEP1B. O conjunto de dados é criado a partir dos primeiros 10 milhões de vetores do arquivo "sample data" chamado learn.350M.fbin. As operações de busca usam vetores da consulta do arquivo "query data".public.10K.fbin.

Tanto o Elasticsearch quanto o OpenSearch têm um desempenho muito bom nesse conjunto de dados, principalmente após uma fusão forçada, que geralmente é feita em índices somente leitura e é semelhante à desfragmentação do índice para ter uma única "tabela" para buscas.

Tarefas

Cada tarefa é aquecida para 100 solicitações e, em seguida, 1.000 solicitações são medidas

• knn-search-10-100: buscando em 10 milhões de vetores, k: 10 e n:100

• knn-search-100-1000: buscando em 10 milhões de vetores, k: 100 e n:1000

• knn-search-10-100-force-merge: buscando em 10 milhões de vetores após uma fusão forçada, k: 10 e n:100

• knn-search-100-1000-force-merge: buscando em 10 milhões de vetores após uma fusão forçada, k: 100 e n:1000

• knn-search-100-1000-concorrente-com-indexação: buscando em 10 milhões de vetores enquanto também atualiza 5% do conjunto de dados, k: 100 e n:1000

• script-score-query: busca KNN exata de 2000 vetores específicos.

Tanto o Elasticsearch quanto o OpenSearch tiveram bom desempenho para Approximate KNN. Quando o índice é mesclado (tem apenas um único segmento) em knn-search-100-1000-force-merge e knn-search-10-100-force-merge, o OpenSearch tem um desempenho melhor do que os outros ao usar nmslib e faiss, mesmo que todos estejam em torno de 15ms e muito próximos.

No entanto, quando o índice tem múltiplos segmentos (situação típica em que um índice recebe atualizações nos documentos) em knn-search-10-100 e knn-search-100-1000, o Elasticsearch mantém a latência em cerca de ~7 ms e ~16 ms, enquanto todos os outros mecanismos OpenSearch são mais lentos.

Além disso, quando o índice está sendo buscado e gravado ao mesmo tempo (knn-search-100-1000-concurrent-with-indexing), o Elasticsearch mantém a latência abaixo de 15ms (13,8ms), sendo quase 4 vezes mais rápido do que o OpenSearch pronto para uso (49,3ms) e ainda mais rápido quando a busca de segmento simultânea está ativada (17,9ms), mas muito próximo para ser significativo.

Quanto ao Exact KNN, a diferença é muito maior: o Elasticsearch é 6x mais rápido que o OpenSearch (~260ms vs ~1600ms).

Recall

knn-recall-10-100

knn-recall-100-1000

Elasticsearch-8.14.0@lucene-hnsw

0,969843

0,996577

Elasticsearch-8.14.0@lucene-int8_hnsw

0,775458

0,840254

OpenSearch-2.14.0@lucene-hnsw

0,971333

0,996747

OpenSearch-2.14.0@faiss

0,9704

0,914755

OpenSearch-2.14.0@faiss-sq_fp16

0,968025

0,913862

OpenSearch-2.14.0@nmslib

0,9674

0,910303

2 milhões de vetores, 768 dimensões (so_vector)

Essa trilha, so_vector, é derivada de um dump de postagens do StackOverflow baixadas em 21 de abril de 2022. Ele contém apenas documentos de perguntas — todos os documentos que representam respostas foram retirados. O título de cada pergunta foi codificado em um vetor usando o modelo de transformador de sentença multi-qa-mpnet-base-cos-v1. Este conjunto de dados contém as primeiras 2 milhões de perguntas.

Diferente da trilha anterior, cada documento aqui contém outros campos além de vetores para aceitar recursos de teste como KNN Aproximado com filtragem e busca híbrida. nmslib para OpenSearch está notavelmente ausente neste teste, já que ele não aceita filtros.

Tarefas

Cada tarefa é aquecida com 100 solicitações e, em seguida, 100 solicitações são medidas. Observe que as tarefas foram agrupadas para simplificar, pois o teste contém 16 tipos de busca * 2 valores de k diferentes * 3 valores de n diferentes.

• knn-10-50: buscando em 2 milhões de vetores sem filtros, k:10 e n:50

• knn-10-50-filtrado: buscando em 2 milhões de vetores com filtros, k:10 e n:50

• knn-10-50-após-fusão-forçada: buscando em 2 milhões de vetores com filtros e após uma fusão forçada, k:10 e n:50

• knn-10-100: buscando em 2 milhões de vetores sem filtros, k:10 e n:100

• knn-10-100-filtered: buscando em 2 milhões de vetores com filtros, k:10 e n:100

• knn-10-100-after-force-merge: buscando em 2 milhões de vetores com filtros e após uma fusão forçada, k:10 e n:100

• knn-100-1000: buscando em 2 milhões de vetores sem filtros, k:100 e n:1000

• knn-100-1000-filtered: buscando em 2 milhões de vetores com filtros, k:100 e n:1000

• knn-100-1000-after-force-merge: buscando em 2 milhões de vetores com filtros e após uma fusão forçada, k:100 e n:1000

• exact-knn: busca KNN exata com e sem filtros.

O Elasticsearch é consistentemente mais rápido que o OpenSearch pronto para uso neste teste, apenas em dois casos o OpenSearch é mais rápido, e não muito (knn-10-100 e knn-100-1000). Tarefas envolvendo knn-10-50, knn-10-100 e knn-100-1000 em combinação com filtros mostram uma diferença de até 7x (112ms vs 803ms).

O desempenho de ambas as soluções parece se equilibrar após uma "force merge", o que é compreensível, conforme evidenciado por knn-10-50-after-force-merge, knn-100-after-force-merge e knn-100-1000-after-force-merge. Nessas tarefas, faiss é mais rápido.

O desempenho do Exact KNN mais uma vez é muito diferente, com o Elasticsearch sendo 13 vezes mais rápido que o OpenSearch desta vez (~385ms vs ~5262ms).

Recall

knn-recall-10-100

knn-recall-100-1000

knn-recall-10-50

Elasticsearch-8.14.0@lucene-hnsw

1

1

1

Elasticsearch-8.14.0@lucene-int8_hnsw

1

0,986667

1

OpenSearch-2.14.0@lucene-hnsw

1

1

1

OpenSearch-2.14.0@faiss

1

1

1

OpenSearch-2.14.0@faiss-sq_fp16

1

1

1

OpenSearch-2.14.0@nmslib

0,9674

0,910303

0,976394

Elasticsearch e Lucene como vencedores claros

Na Elastic, estamos inovando incessantemente o Apache Lucene e o Elasticsearch para garantir que sejamos capazes de fornecer o principal banco de dados vetorial para casos de uso de busca e recuperação, incluindo RAG (retrieval-augmented generation). Nossos avanços recentes aumentaram drasticamente o desempenho, tornando a busca vetorial mais rápida e mais eficiente em termos de espaço do que antes, com base nos ganhos do Lucene 9.10. Esse blog apresentou um estudo que mostra que, ao comparar versões atualizadas, o Elasticsearch é até 12 vezes mais rápido que o OpenSearch.

Vale a pena observar que ambos os produtos usam a mesma versão do Lucene (notas de lançamento do Elasticsearch 8.14 e notas de lançamento do OpenSearch 2.14).

O ritmo de inovação na Elastic proporcionará ainda mais não apenas para nossos clientes no local e do Elastic Cloud, mas também para aqueles que usam nossa plataforma sem estado. Recursos como suporte para quantização escalar para int4 serão oferecidos com testes rigorosos para que os clientes possam utilizar essas técnicas sem uma queda significativa no recall, semelhante aos nossos testes para int8.

A eficiência da busca vetorial está sendo um recurso inegociável nos mecanismos de busca modernos devido à proliferação de aplicações de IA e machine learning. Nas organizações que procuram um mecanismo de busca poderoso, capaz de acompanhar as demandas de dados vetoriais de alto volume e alta complexidade, o Elasticsearch é a resposta definitiva.

Seja expandindo uma plataforma estabelecida ou iniciando novos projetos, a integração do Elasticsearch para as necessidades de busca vetorial é um movimento estratégico que produzirá benefícios tangíveis e de longo prazo. Com a vantagem de desempenho comprovada, o Elasticsearch está pronto para sustentar a próxima onda de inovações em busca.

É exatamente aí que os mecanismos de busca de vetores brilham. Eles podem indexar o mesmo texto de forma que ele possa ser pesquisado com base no significado que ele representa e em suas relações com outros conceitos que tenham significado semelhante ou relacionado.

Neste blog, abordaremos brevemente como os vetores são um ótimo conceito matemático para transmitir o significado do texto. Em seguida, nos aprofundaremos nas diferentes técnicas de similaridade suportadas pelo Elasticsearch quando se trata de pesquisar vetores vizinhos, ou seja, pesquisar vetores com significado semelhante, e como pontuá-los.

O que são embeddings vetoriais?

Este artigo não se aprofunda nas complexidades das incorporações de vetores. Se você quiser explorar mais esse tópico ou precisar de uma introdução antes de continuar, recomendamos conferir o guia a seguir.

Em poucas palavras, os embeddings vetoriais são obtidos por meio de um processo de aprendizado de máquina (por exemplo, redes neurais de aprendizado profundo) que transformam qualquer tipo de dado de entrada não estruturado (por exemplo, texto bruto, imagem, vídeo, som, etc.) em dados numéricos que carregam seu significado e relacionamentos. Diferentes tipos de dados não estruturados exigem diferentes tipos de modelos de aprendizado de máquina que foram treinados para "entender" cada tipo de dado.

Cada vetor localiza um dado específico como um ponto em um espaço multidimensional e essa localização representa um conjunto de características que o modelo usa para caracterizar os dados. O número de dimensões depende do modelo de aprendizado de máquina, mas geralmente varia de algumas centenas a alguns milhares. Por exemplo, os modelos OpenAI Embeddings possuem 1536 dimensões, enquanto os modelos Cohere Embeddings podem variar de 382 a 4096 dimensões. O tipo de campo dense_vector do Elasticsearch suporta até 4.096 dimensões na versão mais recente.

O verdadeiro feito das incorporações vetoriais é que os pontos de dados que compartilham significados semelhantes ficam próximos no espaço. Outro aspecto interessante é que as incorporações vetoriais também ajudam a capturar relacionamentos entre pontos de dados.

Como comparamos vetores?

Sabendo que dados não estruturados são fatiados e divididos por modelos de aprendizado de máquina em incorporações vetoriais que capturam a similaridade dos dados ao longo de um grande número de dimensões, agora precisamos entender como funciona a correspondência desses vetores. Acontece que a resposta é bem simples.

Incorporações de vetores que estão próximas umas das outras representam partes de dados semanticamente semelhantes . Então, quando consultamos um banco de dados vetorial, a entrada da pesquisa (imagem, texto, etc.) é primeiro transformada em embeddings vetoriais usando o mesmo modelo de aprendizado de máquina que foi usado para indexar todos os dados não estruturados, e o objetivo final é encontrar os vetores vizinhos mais próximos daquele vetor de consulta. Portanto, tudo o que precisamos fazer é descobrir como medir a "distância" ou "similaridade" entre o vetor de consulta e todos os vetores existentes indexados no banco de dados - é simples assim.

Distância, similaridade e pontuação

Felizmente para nós, medir a distância ou similaridade entre dois vetores é um problema fácil de resolver graças à aritmética vetorial. Então, vamos dar uma olhada nas funções de distância e similaridade mais populares suportadas pelo Elasticsearch. Atenção, matemática à frente!

Antes de começarmos, vamos dar uma olhada rápida na pontuação. Na verdade, o Lucene só permite que as pontuações sejam positivas. Todas as funções de distância e similaridade que apresentaremos em breve fornecem uma medida de quão próximos ou similares dois vetores são, mas esses números brutos raramente são adequados para serem usados como pontuação, pois podem ser negativos. Por esse motivo, a pontuação final precisa ser derivada do valor de distância ou similaridade de uma forma que garanta que a pontuação será positiva e uma pontuação maior corresponde a uma classificação mais alta (ou seja, para vetores mais próximos).

Distância L1

A distância L1, também chamada de distância de Manhattan, de dois vetores e é medida pela soma da diferença absoluta em pares de todos os seus elementos. Obviamente, quanto menor a distância , mais próximos os dois vetores estarão. A fórmula da distância L1 (1) é bastante simples, como pode ser visto abaixo:

Visualmente, a distância L1 pode ser ilustrada conforme mostrado na imagem abaixo (em vermelho):

O cálculo da distância L1 dos dois vetores a seguir e resultaria em

Importante: Vale ressaltar que a função de distância L1 só é suportada para pesquisa vetorial exata (também conhecida como pesquisa de força bruta) usando a consulta DSL script_score , mas não para pesquisa kNN aproximada usando a opção de pesquisa knnou a consulta DSL knn .

Distância L2

A distância L2, também chamada de distância euclidiana, de dois vetores e é medida primeiro somando o quadrado da diferença de pares de todos os seus elementos e depois tirando a raiz quadrada do resultado. É basicamente o caminho mais curto entre dois pontos. Similarmente a L1, quanto menor a distância , mais próximos os dois vetores estão:

A distância L2 é mostrada em vermelho na imagem abaixo:

Vamos reutilizar os mesmos dois vetores de amostra e que usamos para a distância , e agora podemos calcular a distância como .

Em termos de pontuação, quanto menor a distância entre dois vetores, mais próximos (ou seja, mais semelhantes) eles são. Então, para derivar uma pontuação, precisamos inverter a medida de distância, de modo que a menor distância produza a maior pontuação. A maneira como a pontuação é calculada ao usar a distância L2 é mostrada na fórmula (3) abaixo:

Reutilizando os vetores de amostra do exemplo anterior, sua pontuação seria . Dois vetores muito próximos um do outro tenderão a uma pontuação de 1, enquanto a pontuação de dois vetores muito distantes um do outro tenderá a 0.

Concluindo as funções de distância L1 e L2, uma boa analogia para compará-las é pensar em A e B como dois edifícios em Manhattan, Nova York. Um táxi indo de A para B teria que dirigir pelo caminho L1 (ruas e avenidas), enquanto um pássaro provavelmente usaria o caminho L2 (linha reta).

Similaridade de cosseno

Ao contrário de L1 e L2, a similaridade do cosseno não mede a distância entre dois vetores e , mas sim seu ângulo relativo, ou seja, se ambos estão apontando aproximadamente na mesma direção. Quanto maior a similaridade , menor o ângulo entre os dois vetores e, portanto, mais "próximos" eles são e mais "semelhantes" são seus significados transmitidos.

Para ilustrar isso, vamos pensar em duas pessoas em uma área selvagem olhando em direções diferentes. Na figura abaixo, a pessoa de azul olha na direção simbolizada pelo vetor e a pessoa de vermelho na direção do vetor . Quanto mais eles direcionarem sua visão na mesma direção (ou seja, quanto mais próximos seus vetores estiverem), mais seu campo de visão simbolizado pelas áreas azul e vermelha se sobreporá. O quanto seus campos de visão se sobrepõem é a similaridade de seus cossenos. Entretanto, observe que a pessoa B parece mais distante do que a pessoa A (ou seja, o vetor é maior). A pessoa B pode estar olhando para uma montanha distante no horizonte, enquanto a pessoa A pode estar olhando para uma árvore próxima. Para similaridade de cosseno, isso não desempenha nenhum papel, pois é apenas uma questão de ângulo.

Agora vamos calcular essa similaridade de cosseno. A fórmula (4) é bastante simples, onde o numerador consiste no produto escalar de ambos os vetores e o denominador contém o produto de sua magnitude (ou seja, seu comprimento):

A similaridade do cosseno entre e é mostrada na imagem abaixo como uma medida do ângulo entre eles (em vermelho):

Vamos fazer um rápido desvio para explicar o que esses valores de similaridade de cosseno significam concretamente. Como pode ser visto na imagem abaixo representando a função cosseno, os valores sempre oscilam no intervalo .

Lembre-se de que, para que dois vetores sejam considerados semelhantes, seu ângulo deve ser o mais agudo possível, idealmente próximo de um ângulo , o que se resumiria a uma semelhança perfeita de . Em outras palavras, quando os vetores são...

1. ...próximos um do outro, o cosseno do seu ângulo se aproxima (ou seja, próximo de )

1. ...não relacionados, o cosseno do seu ângulo se aproxima (ou seja, próximo de )

1. ...oposto, o cosseno do seu ângulo se aproxima (ou seja, próximo de )

Agora que sabemos como calcular a similaridade do cosseno entre dois vetores e temos uma boa ideia de como interpretar o valor resultante, podemos reutilizar os mesmos vetores de amostra e e calcular sua similaridade do cosseno usando a fórmula (4) que vimos anteriormente.

Obtemos uma similaridade de cosseno de , que é mais próxima de do que de , o que significa que os dois vetores são um tanto similares, ou seja, não são perfeitamente similares, mas também não são completamente independentes e certamente não têm significados opostos.

Para derivar uma pontuação positiva de qualquer valor de similaridade de cosseno, precisamos usar a seguinte fórmula (5), que transforma os valores de similaridade de cosseno que oscilam dentro do intervalo em pontuações no intervalo :

A pontuação para os vetores de amostra e seria: .

Similaridade do produto escalar

Uma desvantagem da similaridade de cosseno é que ela leva em conta apenas o ângulo entre dois vetores, mas não sua magnitude, o que significa que se dois vetores apontam aproximadamente na mesma direção, mas um é muito maior que o outro, ambos ainda serão considerados semelhantes. A similaridade do produto escalar, também chamada de similaridade escalar ou de produto interno, melhora isso ao levar em conta tanto o ângulo quanto a magnitude dos vetores, o que fornece uma métrica de similaridade mais precisa. Para tornar a magnitude dos vetores irrelevante, a similaridade do produto escalar exige que os vetores sejam normalizados primeiro, de modo que, em última análise, estamos apenas comparando vetores de comprimento unitário 1.

Vamos tentar ilustrar isso novamente com as mesmas duas pessoas de antes, mas, desta vez, as colocamos no meio de uma sala circular, de modo que seu alcance de visão seja exatamente o mesmo (ou seja, o raio da sala). De forma semelhante à similaridade do cosseno, quanto mais eles se voltam na mesma direção (ou seja, quanto mais próximos seus vetores ficam), mais seus campos de visão se sobrepõem. Entretanto, ao contrário da similaridade de cosseno, ambos os vetores têm o mesmo comprimento e ambas as áreas têm a mesma superfície, o que significa que as duas pessoas olham exatamente para a mesma imagem localizada à mesma distância. O quão bem essas duas áreas se sobrepõem denota sua similaridade de produto escalar.

Antes de introduzir a fórmula de similaridade do produto escalar, vamos ver rapidamente como um vetor pode ser normalizado. É bem simples e pode ser feito em duas etapas triviais:

1. calcular a magnitude do vetor

2. divida cada componente pela magnitude obtida em 1.

Como exemplo, vamos pegar o vetor . Podemos calcular sua magnitude como vimos anteriormente ao revisar a similaridade do cosseno, ou seja, . Então, dividindo cada componente do vetor por sua magnitude, obtemos o seguinte vetor normalizado :

Passar pelo mesmo processo para o segundo vetor produziria o seguinte vetor normalizado :

Para derivar a fórmula de similaridade do produto escalar, podemos calcular a similaridade do cosseno entre nossos vetores normalizados e usando a fórmula (4), conforme mostrado abaixo:

E como a magnitude de ambos os vetores normalizados é agora , a fórmula de similaridade do produto escalar (6) simplesmente se torna... você adivinhou, um produto escalar de ambos os vetores normalizados:

Na imagem abaixo, mostramos os vetores normalizados e e podemos ilustrar sua similaridade de produto escalar como a projeção de um vetor sobre o outro (em vermelho).

Usando nossa nova fórmula (6), podemos calcular a similaridade do produto escalar de nossos dois vetores normalizados, o que, sem surpresa, produz exatamente o mesmo valor de similaridade que o do cosseno:

Ao aproveitar a similaridade do produto escalar, a pontuação é calculada de forma diferente dependendo se os vetores contêm valores flutuantes ou de bytes. No primeiro caso, a pontuação é calculada da mesma forma que para a similaridade do cosseno usando a fórmula (7) abaixo:

Entretanto, quando o vetor é composto de valores de bytes, a pontuação é calculada de forma um pouco diferente, conforme mostrado na fórmula (8) abaixo, onde é o número de dimensões do vetor:

Além disso, uma restrição para produzir pontuações precisas é que todos os vetores, incluindo o vetor de consulta, devem ter o mesmo comprimento, mas não necessariamente 1.

Similaridade máxima do produto interno

Desde a versão 8.11, há uma nova função de similaridade que é menos restrita do que a similaridade do produto escalar, pois os vetores não precisam ser normalizados. O principal motivo para isso é explicado detalhadamente no artigo a seguir, mas, para resumir muito brevemente, certos conjuntos de dados não são muito bem adaptados para ter seus vetores normalizados (por exemplo, incorporações Cohere) e isso pode causar problemas de relevância.

A fórmula para calcular a similaridade máxima do produto interno é exatamente a mesma que a do produto escalar (6). O que muda é a maneira como a pontuação é calculada, escalando a similaridade máxima do produto interno usando uma função por partes cuja fórmula depende se a similaridade é positiva ou negativa, conforme mostrado na fórmula (9) abaixo:

O que essa função por partes faz é dimensionar todos os valores negativos de similaridade do produto interno máximo no intervalo e todos os valores positivos no intervalo .

Resumindo

Foi uma jornada e tanto, matematicamente falando, mas aqui estão algumas lições que você pode achar úteis.

A função de similaridade que você pode usar depende, em última análise, se seus embeddings vetoriais são normalizados ou não. Se seus vetores já estiverem normalizados ou se seu conjunto de dados for independente da normalização vetorial (ou seja, a relevância não será afetada), você pode prosseguir e normalizar seus vetores e usar a similaridade do produto escalar, pois é muito mais rápido de calcular do que o cosseno, pois não há necessidade de calcular o comprimento de cada vetor. Ao comparar milhões de vetores, esses cálculos podem somar bastante.

Se seus vetores não estiverem normalizados, você tem duas opções:

1. use similaridade de cosseno se normalizar seus vetores não for uma opção

2. use a nova similaridade máxima do produto interno se quiser que a magnitude dos seus vetores contribua para a pontuação porque eles carregam significado (por exemplo, incorporações Cohere)

Neste ponto, calcular a distância ou similaridade entre incorporações vetoriais e como derivar suas pontuações deve fazer sentido para você. Esperamos que você tenha achado este artigo útil.

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.

Pré-requisitos

Assim como na primeira parte desta série, os seguintes pré-requisitos são necessários para este exemplo:

1. Instalação do Go versão 1.21 ou posterior

2. Crie seu próprio repositório Go usando a estrutura recomendada e o gerenciamento de pacotes abordados na documentação do Go.

3. Criando seu próprio cluster Elasticsearch, preenchido com um conjunto de páginas baseadas em roedores, incluindo para o nosso amigável Gopher, da Wikipédia:

Conectando-se ao Elasticsearch

Lembrando que, em nossos exemplos, utilizaremos a API tipada oferecida pelo cliente Go. Para estabelecer uma conexão segura para qualquer consulta, é necessário configurar o cliente usando um dos seguintes métodos:

1. ID da nuvem e chave de API, caso esteja utilizando o Elastic Cloud.

2. URL do cluster, nome de usuário, senha e certificado

A conexão com nosso cluster localizado no Elastic Cloud seria feita da seguinte forma:

A conexão client pode então ser usada para pesquisa, como demonstrado nas seções subsequentes.

Impulsionamento manual para pesquisa híbrida

Ao combinar qualquer conjunto de algoritmos de busca, a abordagem tradicional tem sido configurar manualmente constantes para otimizar cada tipo de consulta. Especificamente, um fator é definido para cada consulta, e o conjunto de resultados combinados é comparado ao conjunto esperado para determinar a recuperação da consulta. Em seguida, repetimos o processo para vários conjuntos de fatores e escolhemos aquele que mais se aproxima do estado desejado.

Por exemplo, combinar uma consulta de pesquisa de texto simples, ampliada por um fator de 0.8 , com uma consulta KNN com um fator menor de 0.2 pode ser feito especificando o campo Boost em ambos os tipos de consulta, como mostrado no exemplo abaixo:

O fator especificado na opção Boost para cada consulta é adicionado à pontuação do documento. Ao aumentar a pontuação da nossa consulta de correspondência por um fator maior do que a consulta knn, os resultados da consulta por palavra-chave recebem um peso maior.

O desafio da otimização manual, especialmente se você não for um especialista em buscas, é que ela exige ajustes para descobrir os fatores que levarão ao conjunto de resultados desejado. Trata-se simplesmente de experimentar valores aleatórios para ver o que o aproxima do resultado desejado.

Fusão de classificação recíproca em pesquisa híbrida e cliente Go

O Reciprocal Rank Fusion, ou RRF, foi lançado em versão de pré-visualização técnica para busca híbrida no Elasticsearch 8.9. Tem como objetivo reduzir a curva de aprendizado associada ao ajuste fino e diminuir o tempo gasto experimentando diferentes fatores para otimizar o conjunto de resultados.

Com o RRF, a pontuação do documento é recalculada combinando as pontuações pelo algoritmo abaixo:

A vantagem de usar o RRF é que podemos aproveitar os valores padrão adequados do Elasticsearch. A constante de classificação k assume o valor padrão 60. Para proporcionar um equilíbrio entre a relevância dos documentos retornados e o desempenho da consulta ao pesquisar em grandes conjuntos de dados, o tamanho do conjunto de resultados para cada consulta considerada é limitado ao valor de window_size, que por padrão é 100 conforme descrito na documentação.

k e windows_size também pode ser configurado dentro da configuração Rrf dentro do método Rank no cliente Go, conforme o exemplo abaixo:

Conclusão

Aqui discutimos como combinar a pesquisa vetorial e a pesquisa por palavra-chave no Elasticsearch usando o cliente Elasticsearch Go.

Confira o repositório do GitHub para acessar todo o código desta série. Caso ainda não tenha feito, confira a parte 1 e a parte 2 para ver todo o código desta série.

Boa caçada aos esquilos!

Recursos

1. Guia do Elasticsearch

2. Cliente Go do Elasticsearch

3. O que é busca vetorial? | Elástico

4. Fusão de Classificação Recíproca

Assim como os animais, as linguagens de programação e seu amigável autor, a busca passou por uma evolução de diferentes práticas, o que pode dificultar a escolha da melhor opção para o seu caso específico. Neste blog, compartilharemos uma visão geral da busca vetorial, juntamente com exemplos de cada abordagem usando o Elasticsearch e o cliente Elasticsearch Go. Estes exemplos mostrarão como encontrar esquilos-da-terra e determinar o que eles comem usando a busca vetorial no Elasticsearch e em Go.

Pré-requisitos

Para dar continuidade a este exemplo, certifique-se de que os seguintes pré-requisitos sejam atendidos:

1. Instalação do Go versão 1.21 ou posterior

2. Criação do seu próprio repositório Go com o

3. Criação do seu próprio cluster Elasticsearch, preenchido com um conjunto de páginas baseadas em roedores, incluindo para o nosso amigável Gopher, da Wikipédia:

Conectando-se ao Elasticsearch

Em nossos exemplos, utilizaremos a API tipada oferecida pelo cliente Go. Para estabelecer uma conexão segura para qualquer consulta, é necessário configurar o cliente usando um dos seguintes métodos:

1. ID da nuvem e chave de API, caso esteja utilizando o Elastic Cloud.

2. URL do cluster, nome de usuário, senha e certificado.

A conexão com nosso cluster localizado no Elastic Cloud seria feita da seguinte forma:

A conexão client pode então ser usada para busca vetorial, como mostrado nas seções subsequentes.

Busca vetorial

A busca vetorial tenta resolver esse problema convertendo-o em uma comparação matemática usando vetores. O processo de incorporação de documentos possui uma etapa adicional de conversão do documento, utilizando um modelo, em uma representação vetorial densa, ou simplesmente em um fluxo de números. A vantagem dessa abordagem é que você pode pesquisar documentos não textuais, como imagens e áudio, convertendo-os em um vetor juntamente com uma consulta.

Em termos simples, a busca vetorial é um conjunto de cálculos de distância vetorial. Na ilustração abaixo, a representação vetorial da nossa consulta Go Gopheré comparada com os documentos no espaço vetorial, e os resultados mais próximos (denotados pela constante k) são retornados:

Dependendo da abordagem usada para gerar os embeddings dos seus documentos, existem duas maneiras diferentes de descobrir o que os gophers comem.

Abordagem 1: Traga seu próprio modelo

Com uma licença Platinum, é possível gerar os embeddings dentro do Elasticsearch, carregando o modelo e usando a API de inferência. A configuração do modelo envolve seis etapas:

1. Selecione um modelo PyTorch para carregar a partir de um repositório de modelos. Neste exemplo, estamos usando o sentence-transformers/msmarco-MiniLM-L-12-v3 da Hugging Face para gerar os embeddings.

2. Carregue o modelo no Elastic usando o cliente Eland Machine Learning para Python usando as credenciais para nosso cluster Elasticsearch e tipo de tarefa text_embeddings. Se você não tiver o Eland instalado, poderá executar a etapa de importação usando o Docker, conforme mostrado abaixo:

1. Após o carregamento, teste rapidamente o modelo sentence-transformers__msmarco-minilm-l-12-v3 com um documento de exemplo para garantir que os embeddings sejam gerados conforme o esperado:

1. Crie um pipeline de ingestão contendo um processador de inferência. Isso permitirá que a representação vetorial seja gerada usando o modelo carregado:

1. Crie um novo índice contendo o campo text_embedding.predicted_value do tipo dense_vector para armazenar os vetores de incorporação gerados para cada documento:

1. Reindexe os documentos usando o pipeline de ingestão recém-criado para gerar os embeddings de texto como o campo adicional text_embedding.predicted_value em cada documento:

Agora podemos usar a opção Knn na mesma API de pesquisa usando o novo índice vector-search-rodents, como mostrado no exemplo abaixo:

A conversão do objeto JSON resultante por meio de desserialização é feita exatamente da mesma forma que no exemplo de pesquisa por palavra-chave. As constantes K e NumCandidates permitem configurar o número de documentos vizinhos a serem retornados e o número de candidatos a serem considerados por fragmento. Note que aumentar o número de candidatos aumenta a precisão dos resultados, mas leva a uma consulta mais demorada, pois mais comparações são realizadas.

Quando o código é executado usando a consulta What do Gophers eat?, os resultados retornados são semelhantes aos abaixo, destacando que o artigo do Gopher contém as informações solicitadas, diferentemente da pesquisa anterior por palavra-chave:

Abordagem 2: API de inferência do Hugging Face

Outra opção é gerar esses mesmos embeddings fora do Elasticsearch e ingeri-los como parte do seu documento. Como essa opção não utiliza um nó de aprendizado de máquina do Elasticsearch, ela pode ser executada no nível gratuito.

A Hugging Face disponibiliza uma API de inferência gratuita e com limite de requisições que, mediante uma conta e um token de API, pode ser usada para gerar manualmente os mesmos embeddings para experimentação e prototipagem, ajudando você a começar. Não é recomendado para uso em produção. Invocar seus próprios modelos localmente para gerar embeddings ou usar a API paga também pode ser feito usando uma abordagem semelhante.

Na função abaixo GetTextEmbeddingForQuery usamos a API de inferência em nossa string de consulta para gerar o vetor retornado de uma solicitação POST ao endpoint:

O vetor resultante, do tipo []float32 é então passado como QueryVector em vez de usar a opção QueryVectorBuilder para aproveitar o modelo previamente carregado no Elastic.

Note que as opções K e NumCandidates permanecem as mesmas, independentemente das duas opções, e que os mesmos resultados são gerados, pois estamos usando o mesmo modelo para gerar os embeddings.

Conclusão

Aqui discutimos como realizar uma busca vetorial no Elasticsearch usando o cliente Elasticsearch Go. Confira o repositório do GitHub para acessar todo o código desta série. Continue para a parte 3 para obter uma visão geral da combinação da pesquisa vetorial com os recursos de pesquisa por palavra-chave abordados na parte 1 em Go.

Até lá, boa caçada aos esquilos!

Recursos

1. Guia do Elasticsearch

2. Cliente Go do Elasticsearch

3. O que é busca vetorial? | Elástico

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.

Com o avanço da tecnologia, os chatbots são usados para lidar com tarefas mais complexas — e rapidamente — sem deixar de oferecer uma experiência personalizada aos usuários. O processamento de linguagem natural (PLN) permite que os chatbots processem a linguagem do usuário, identifiquem a intenção por trás da mensagem e extraiam informações relevantes dela. Por exemplo, o Reconhecimento de Entidades Nomeadas extrai informações importantes de um texto, classificando-as em um conjunto de categorias. A Análise de Sentimentos identifica o tom emocional, e o Question Answering (Resposta a Perguntas) a “resposta” a uma consulta. O objetivo do PNL (Processamento de Linguagem Natural) é permitir que algoritmos processem a linguagem humana e executem tarefas que historicamente apenas os humanos eram capazes de realizar, como encontrar trechos relevantes em grandes quantidades de texto, resumir textos e gerar conteúdo novo e original.

Essas capacidades avançadas de PNL (Processamento de Linguagem Natural) são baseadas em uma tecnologia conhecida como busca vetorial. O Elasticsearch oferece suporte nativo para busca vetorial, realizando buscas exatas e aproximadas de k-vizinhos mais próximos (kNN), e para PNL (Processamento de Linguagem Natural), permitindo o uso de modelos personalizados ou de terceiros diretamente no Elasticsearch.

Neste artigo, exploraremos como a busca vetorial e o PNL (Processamento de Linguagem Natural) trabalham juntos para aprimorar as capacidades dos chatbots e demonstraremos como o Elasticsearch facilita esse processo. Vamos começar com uma breve visão geral da busca vetorial.

Busca vetorial

Embora os seres humanos consigam compreender o significado e o contexto da linguagem escrita, as máquinas não conseguem fazer o mesmo. É aí que entram os vetores. Ao converter o texto em representações vetoriais (representações numéricas do significado do texto), as máquinas podem superar essa limitação. Em comparação com uma busca tradicional, em vez de depender de palavras-chave e busca lexical baseada em frequências, os vetores permitem o processamento de dados textuais usando operações definidas para valores numéricos.

Isso permite que a busca vetorial localize dados que compartilham conceitos ou contextos semelhantes, usando distâncias no "espaço de incorporação" para representar a similaridade, dado um vetor de consulta. Quando os dados são semelhantes, os vetores correspondentes também serão semelhantes.

A busca vetorial não é utilizada apenas em aplicações de PNL (Processamento de Linguagem Natural), mas também em vários outros domínios que envolvem dados não estruturados, incluindo processamento de imagem e vídeo.

Em um fluxo de chatbot, podem existir diversas abordagens para as consultas dos usuários e, consequentemente, diferentes maneiras de aprimorar a recuperação de informações para uma melhor experiência do usuário. Como cada alternativa possui seu próprio conjunto de vantagens e possíveis desvantagens, é essencial levar em consideração os dados e recursos disponíveis, bem como o tempo de treinamento (quando aplicável) e a precisão esperada. Na seção seguinte, abordaremos esses aspectos para modelos de PNL (Processamento de Linguagem Natural) de resposta a perguntas.

Respostas a perguntas

Um modelo de perguntas e respostas (QA, na sigla em inglês) é um tipo de modelo de PNL (Processamento de Linguagem Natural) projetado para responder a perguntas feitas em linguagem natural. Quando os usuários têm dúvidas que exigem a inferência de respostas a partir de múltiplas fontes, sem que haja uma resposta preexistente nos documentos, os modelos generativos de perguntas e respostas podem ser úteis. No entanto, esses modelos podem ser computacionalmente dispendiosos e exigem grandes quantidades de dados para treinamento relacionado ao domínio, o que pode torná-los menos práticos em algumas situações, embora esse método possa ser particularmente valioso para lidar com questões fora do domínio.

Por outro lado, quando os usuários têm dúvidas sobre um tópico específico e a resposta correta está presente no documento, podem ser utilizados modelos de perguntas e respostas extrativas. Esses modelos extraem a resposta diretamente do documento original, fornecendo resultados transparentes e verificáveis, o que os torna uma opção mais prática para empresas ou organizações que desejam oferecer uma maneira simples e eficiente de responder a perguntas.

O exemplo abaixo demonstra o uso de um modelo de perguntas e respostas extrativo pré-treinado, disponível no Hugging Face e implantado no Elasticsearch, para extrair respostas de um determinado contexto:

Implantar modelos treinados.

Adicionar um modelo a um pipeline de ingestão de inferência.

Existem diversas maneiras de lidar com consultas de usuários e recuperar informações, e o uso de múltiplos modelos de linguagem e fontes de dados pode ser uma alternativa eficaz ao lidar com dados não estruturados. Para ilustrar isso, temos um exemplo do processamento de dados de um chatbot utilizado para responder a perguntas com respostas que consideram dados extraídos de documentos selecionados.

Processamento de dados de chatbots: PNL e busca vetorial

Conforme mostrado acima, o processamento de dados do nosso chatbot pode ser dividido em três partes:

• Processamento vetorial: Esta etapa converte documentos em representações vetoriais.

• Processamento da entrada do usuário: Esta etapa extrai informações relevantes da consulta do usuário e realiza busca semântica e recuperação híbrida.

• Otimização: Esta etapa inclui o monitoramento e é crucial para garantir a confiabilidade do chatbot, o desempenho ideal e uma ótima experiência do usuário.

Processamento vetorial

Na etapa de processamento , o primeiro passo é determinar os componentes de cada documento para, em seguida, converter cada elemento em uma representação vetorial; essas representações podem ser criadas para uma ampla variedade de formatos de dados.

Existem vários métodos que podem ser usados para calcular embeddings, incluindo modelos pré-treinados e bibliotecas.

É importante notar que a eficácia da busca e recuperação nessas representações depende dos dados existentes e da qualidade e relevância do método utilizado.

À medida que os vetores são calculados, eles são armazenados no Elasticsearch com um tipo de campo dense_vector .

Processamento de entrada do usuário do chatbot

Do ponto de vista do usuário , após receber uma pergunta, é útil extrair todas as informações possíveis dela antes de prosseguir. Isso ajuda a entender a intenção do usuário e, neste caso, estamos usando um modelo de Reconhecimento de Entidades Nomeadas (NER) para auxiliar nesse processo. NER é o processo de identificar e classificar entidades nomeadas em categorias de entidades predefinidas.

Embora não seja um passo necessário, ao usar dados estruturados ou o resultado do modelo de PNL acima ou de outro modelo para categorizar a consulta do usuário, podemos restringir a pesquisa kNN usando um filtro. Isso ajuda a melhorar o desempenho e a precisão, reduzindo a quantidade de dados que precisam ser processados.

Busca semântica e recuperação híbrida

Como a solicitação surge de consultas do usuário e o chatbot precisa processar a linguagem humana com sua variabilidade e ambiguidade, a busca semântica é uma ótima opção. No Elasticsearch, você pode realizar uma busca semântica em uma única etapa, passando a string de consulta e o ID do modelo de incorporação para um objeto `query_vector_builder`. Isso vetorizará a consulta e realizará uma busca kNN para recuperar as k correspondências mais próximas em significado à consulta:

Exemplo completo: Como implantar um modelo de incorporação de texto e usá-lo para pesquisa semântica. O Elasticsearch utiliza a implementação Lucene do Okapi BM25, um modelo esparso , para classificar as consultas de texto quanto à relevância, enquanto modelos densos são usados para busca semântica. Para combinar os pontos fortes das correspondências vetoriais e das correspondências obtidas a partir da consulta de texto, você pode realizar uma recuperação híbrida :

A combinação de modelos esparsos e densos geralmente produz os melhores resultados.

Os modelos esparsos geralmente têm melhor desempenho em consultas curtas e terminologias específicas, enquanto os modelos densos aproveitam o contexto e as associações. Se você quiser saber mais sobre como esses métodos se comparam e se complementam, aqui comparamos o BM25 com dois modelos densos que foram treinados especificamente para recuperação de dados.

O resultado mais relevante geralmente é a primeira resposta fornecida ao usuário; o_score é um número usado para determinar a relevância do documento retornado.

Otimização de chatbot

Para ajudar a melhorar a experiência do usuário, o desempenho e a confiabilidade do seu chatbot, além de aplicar a pontuação híbrida, você pode incorporar as seguintes abordagens: Análise de Sentimento: Para fornecer informações sobre os comentários e reações dos usuários à medida que o diálogo se desenrola, você pode incorporar um modelo de análise de sentimento:

Funcionalidades do GPT : Como alternativa para aprimorar a experiência geral, você pode combinar a relevância de pesquisa do Elasticsearch com os recursos de resposta a perguntas do GPT da OpenAI, utilizando a API Chat Completion para retornar ao usuário respostas geradas pelo modelo, considerando esses k documentos principais como contexto. Prompt: "responda a esta pergunta <user_question> usando apenas este documento <top_search_result>"

Observabilidade: Garantir o desempenho de qualquer chatbot é crucial, e o monitoramento é um componente essencial para atingir esse objetivo. Além dos registros que capturam as interações do chatbot, é importante monitorar o tempo de resposta, a latência e outras métricas relevantes do chatbot. Dessa forma, você pode identificar padrões, tendências e até mesmo detectar anomalias. As ferramentas do Elastic Observability permitem coletar e analisar essas informações.

Resumo

Esta postagem do blog aborda o que são PNL (Processamento de Linguagem Natural) e busca vetorial e explora um exemplo de um chatbot usado para responder a perguntas de usuários, considerando dados extraídos da representação vetorial de documentos.

Conforme demonstrado, utilizando PNL (Processamento de Linguagem Natural) e busca vetorial, os chatbots são capazes de executar tarefas complexas que vão além de dados estruturados e direcionados. Isso inclui fazer recomendações e responder a perguntas específicas relacionadas a produtos ou negócios, usando múltiplas fontes e formatos de dados como contexto, além de proporcionar uma experiência personalizada ao usuário.

Os casos de uso variam desde o atendimento ao cliente, auxiliando os clientes com suas dúvidas, até o auxílio a desenvolvedores com suas perguntas, fornecendo orientações passo a passo, sugerindo recomendações ou até mesmo automatizando tarefas. Dependendo do objetivo e dos dados existentes, outros modelos e métodos também podem ser utilizados para alcançar resultados ainda melhores e aprimorar a experiência geral do usuário.

Aqui estão alguns links sobre o assunto que podem ser úteis:

1. Como implementar o processamento de linguagem natural (PLN): Primeiros passos

2. Visão geral da busca por similaridade de imagens no Elasticsearch

3. ChatGPT e Elasticsearch: OpenAI encontra dados privados

4. Monitor OpenAI API and GPT models with OpenTelemetry and Elastic (Monitore a API do OpenAI e os modelos do GPT com o OpenTelemetry e a Elastic)

5. 5 motivos pelos quais os líderes de TI precisam da busca vetorial para melhorar a experiência de busca.

Ao incorporar PNL (Processamento de Linguagem Natural) e busca vetorial nativa no Elasticsearch, você pode aproveitar sua velocidade, escalabilidade e recursos de busca para criar chatbots altamente eficientes e eficazes, capazes de lidar com grandes quantidades de dados, sejam eles estruturados ou não estruturados.

Pronto para começar? Inicie um teste gratuito do Elastic Cloud.

Neste artigo, podemos ter usado ou podemos fazer referência a ferramentas de IA generativa de terceiros, que são propriedade e operadas por seus respectivos proprietários. A Elastic não tem qualquer controle sobre as ferramentas de terceiros e não nos responsabilizamos pelo seu conteúdo, funcionamento ou utilização, nem por quaisquer perdas ou danos que possam resultar da sua utilização. Tenha cautela ao usar ferramentas de IA com informações pessoais, sensíveis ou confidenciais. Quaisquer dados que você enviar poderão ser usados para treinamento de IA ou outros fins. Não há garantia de que as informações fornecidas serão mantidas em segurança ou confidenciais. Você deve se familiarizar com as práticas de privacidade e os termos de uso de quaisquer ferramentas de IA generativa antes de utilizá-las.

Elastic, Elasticsearch e marcas associadas são marcas comerciais, logotipos ou marcas registradas da Elasticsearch NV nos Estados Unidos e em outros países. Todos os outros nomes de empresas e produtos são marcas comerciais, logotipos ou marcas registradas de seus respectivos proprietários.

Este artigo aborda uma técnica específica chamada busca por similaridade de texto. Nesse tipo de busca, o usuário insere uma breve consulta em texto livre, e os documentos são classificados com base em sua similaridade com a consulta. A similaridade textual pode ser útil em diversos casos de uso:

• Resposta a perguntas: Dada uma coleção de perguntas frequentes, encontre perguntas semelhantes àquela que o usuário inseriu.

• Busca de artigos: Em uma coleção de artigos de pesquisa, retornar artigos com títulos intimamente relacionados à consulta do usuário.

• Busca por imagem: Em um conjunto de dados de imagens com legendas, encontre imagens cuja legenda seja semelhante à descrição do usuário.

Uma abordagem direta para a busca por similaridade seria classificar os documentos com base em quantas palavras eles compartilham com a consulta. Mas um documento pode ser semelhante à consulta mesmo que tenha pouquíssimas palavras em comum — uma noção mais robusta de similaridade levaria em conta também seu conteúdo sintático e semântico .

A comunidade de processamento de linguagem natural (PLN) desenvolveu uma técnica chamada incorporação de texto que codifica palavras e frases como vetores numéricos. Essas representações vetoriais são projetadas para capturar o conteúdo linguístico do texto e podem ser usadas para avaliar a similaridade entre uma consulta e um documento.

Este artigo explora como os embeddings de texto e o tipo dense_vector do Elasticsearch podem ser usados para dar suporte à busca por similaridade. Primeiramente, apresentaremos uma visão geral das técnicas de incorporação e, em seguida, demonstraremos um protótipo simples de busca por similaridade usando o Elasticsearch.

O que são embeddings de texto?

Vamos analisar mais de perto os diferentes tipos de incorporação de texto e como eles se comparam às abordagens de busca tradicionais.

Incorporação de palavras

Um modelo de incorporação de palavras representa uma palavra como um vetor numérico denso. Esses vetores visam capturar as propriedades semânticas da palavra — palavras cujos vetores estejam próximos uns dos outros devem ser semelhantes em termos de significado semântico. Numa boa incorporação, as direções no espaço vetorial estão ligadas a diferentes aspectos do significado da palavra. Por exemplo, o vetor para "Canadá" pode estar próximo de "França" em uma direção e próximo de "Toronto" em outra.

As comunidades de PNL (Processamento de Linguagem Natural) e de busca têm demonstrado interesse em representações vetoriais de palavras há bastante tempo. Nos últimos anos, houve um ressurgimento do interesse em word embeddings, quando muitas tarefas tradicionais foram revisitadas usando redes neurais. Alguns algoritmos de incorporação de palavras bem-sucedidos foram desenvolvidos, incluindo o word2vec e o GloVe. Essas abordagens utilizam grandes coleções de texto e examinam o contexto em que cada palavra aparece para determinar sua representação vetorial:

• O modelo Skip-gram do word2vec treina uma rede neural para prever as palavras de contexto ao redor de uma palavra em uma frase. Os pesos internos da rede fornecem os embeddings de palavras.

• Em GloVe, a similaridade entre palavras depende da frequência com que elas aparecem em conjunto com outras palavras do mesmo contexto. O algoritmo treina um modelo linear simples com base na contagem de coocorrência de palavras.

Muitos grupos de pesquisa distribuem modelos que foram pré-treinados em grandes corpora de texto, como a Wikipédia ou o Common Crawl, tornando-os convenientes para baixar e usar em tarefas subsequentes. Embora versões pré-treinadas sejam às vezes usadas diretamente, pode ser útil ajustar o modelo para que ele se adeque ao conjunto de dados e à tarefa específicos. Isso geralmente é feito executando uma etapa de "ajuste fino" no modelo pré-treinado.

Os word embeddings provaram ser bastante robustos e eficazes, e agora é prática comum usar embeddings em vez de tokens individuais em tarefas de PNL, como tradução automática e classificação de sentimentos.

Incorporação de frases

Mais recentemente, os pesquisadores começaram a se concentrar em técnicas de incorporação que representam não apenas palavras, mas também trechos de texto mais longos. A maioria das abordagens atuais baseia-se em arquiteturas complexas de redes neurais e, por vezes, incorpora dados rotulados durante o treinamento para auxiliar na captura de informações semânticas.

Uma vez treinados, os modelos são capazes de pegar uma frase e produzir um vetor para cada palavra em contexto, bem como um vetor para a frase inteira. Assim como no caso do word embedding, versões pré-treinadas de muitos modelos estão disponíveis, permitindo que os usuários ignorem o dispendioso processo de treinamento. Embora o processo de treinamento possa ser bastante intensivo em recursos, a invocação do modelo é muito mais leve — os modelos de incorporação de sentenças são normalmente rápidos o suficiente para serem usados em aplicações em tempo real.

Algumas técnicas comuns de incorporação de sentenças incluem InferSent, Universal Sentence Encoder, ELMo e BERT. A melhoria dos embeddings de palavras e frases é uma área ativa de pesquisa, e é provável que modelos robustos adicionais sejam introduzidos.

Comparação com abordagens de busca tradicionais

Na recuperação de informação tradicional, uma forma comum de representar texto como um vetor numérico é atribuir uma dimensão para cada palavra do vocabulário. O vetor para um trecho de texto é então baseado no número de vezes que cada termo do vocabulário aparece. Essa forma de representar o texto é frequentemente chamada de "saco de palavras", porque simplesmente contamos as ocorrências de palavras sem levar em consideração a estrutura da frase.

Os embeddings de texto diferem das representações vetoriais tradicionais em alguns aspectos importantes:

• Os vetores codificados são densos e de dimensionalidade relativamente baixa, geralmente variando de 100 a 1.000 dimensões. Em contraste, os vetores de saco de palavras são esparsos e podem conter mais de 50.000 dimensões. Os algoritmos de incorporação codificam o texto em um espaço de menor dimensão como parte da modelagem de seu significado semântico. Idealmente, palavras e frases sinônimas acabam com uma representação semelhante no novo espaço vetorial.

• Os embeddings de sentenças podem levar em consideração a ordem das palavras ao determinar a representação vetorial. Por exemplo, a expressão "tune in" pode ser representada por um vetor muito diferente de "in tune".

• Na prática, os embeddings de frases geralmente não se generalizam bem para grandes trechos de texto. Não são comumente usados para representar textos com mais de um parágrafo curto.

Utilizando embeddings para busca de similaridade

Suponhamos que tivéssemos uma grande coleção de perguntas e respostas. Um usuário pode fazer uma pergunta, e queremos recuperar a pergunta mais semelhante em nossa coleção para ajudá-lo a encontrar uma resposta.

Poderíamos usar incorporações de texto para permitir a recuperação de perguntas semelhantes:

• Durante a indexação, cada pergunta é processada por um modelo de incorporação de sentenças para produzir um vetor numérico.

• Quando um usuário insere uma consulta, ela é processada pelo mesmo modelo de incorporação de sentenças para produzir um vetor. Para classificar as respostas, calculamos a similaridade vetorial entre cada pergunta e o vetor de consulta. Ao comparar vetores de incorporação, é comum usar a similaridade de cosseno.

Este repositório fornece um exemplo simples de como isso pode ser feito no Elasticsearch. O script principal indexa cerca de 20.000 perguntas do conjunto de dados do StackOverflow e, em seguida, permite que o usuário insira consultas de texto livre no conjunto de dados.

Em breve, analisaremos cada parte do script em detalhes, mas primeiro vamos dar uma olhada em alguns exemplos de resultados. Em muitos casos, o método consegue captar semelhanças mesmo quando não há uma sobreposição significativa de palavras entre a consulta e a pergunta indexada:

• "Compactar arquivos" retorna "Comprimir/Descomprimir Pastas e Arquivos"

• "Determinar se algo é um IP" retorna "Como saber se uma string é um IP ou um nome de host?"

• "Converter bytes em doubles" retorna "Converter bytes em números de ponto flutuante em Python"

Detalhes da implementação

O script começa baixando e criando o modelo de incorporação no TensorFlow. Optamos pelo Universal Sentence Encoder do Google, mas é possível usar muitos outros métodos de incorporação. O script utiliza o modelo de incorporação tal como está, sem qualquer treinamento ou ajuste fino adicional.

Em seguida, criamos o índice do Elasticsearch, que inclui mapeamentos para o título da pergunta, tags e também o título da pergunta codificado como um vetor:

No mapeamento para dense_vector, é necessário especificar o número de dimensões que os vetores conterão. Ao indexar um campo title_vector, o Elasticsearch verificará se ele possui o mesmo número de dimensões especificado no mapeamento.

Para indexar os documentos, aplicamos o modelo de incorporação ao título da pergunta para obter uma matriz numérica. Essa matriz é adicionada ao documento no campo title_vector.

Quando um usuário insere uma consulta, o texto é primeiro processado pelo mesmo modelo de incorporação e armazenado no parâmetro `query_vector`. A partir da versão 7.3, o Elasticsearch fornece uma função de similaridade de cosseno em sua linguagem de script nativa. Para classificar as perguntas com base na sua similaridade com a consulta do usuário, utilizamos uma consulta `script_score`:

Garantimos passar o vetor de consulta como um parâmetro de script para evitar recompilar o script() em cada nova consulta. Como o Elasticsearch não permite pontuações negativas, é necessário adicionar um à similaridade de cosseno.

Nota: esta publicação no blog usava originalmente uma sintaxe diferente para funções vetoriais , disponível no Elasticsearch 7.3, mas que foi descontinuada na versão 7.6. |

Limitações importantes

A consulta script_score foi projetada para encapsular uma consulta restritiva e modificar as pontuações dos documentos retornados. No entanto, fornecemos uma consulta match_all, o que significa que o script será executado em todos os documentos do índice. Essa é uma limitação atual da similaridade vetorial no Elasticsearch — vetores podem ser usados para pontuar documentos, mas não na etapa inicial de recuperação. O suporte para recuperação baseada na similaridade vetorial é uma importante área de trabalho em andamento.

Para evitar a varredura de todos os documentos e manter um desempenho rápido, a consulta match_all pode ser substituída por uma consulta mais seletiva. A consulta correta a ser usada para recuperação de dados provavelmente dependerá do caso de uso específico.

Embora tenhamos visto alguns exemplos encorajadores acima, é importante notar que os resultados também podem ser inconsistentes e pouco intuitivos. Por exemplo, "compactar arquivos" também atribui pontuações altas a ".csproj parcial". Arquivos" e "Como evitar arquivos .pyc" arquivos?". E quando o método retorna resultados inesperados, nem sempre é claro como depurar o problema — o significado de cada componente do vetor costuma ser opaco e não corresponde a um conceito interpretável. Com as técnicas tradicionais de pontuação baseadas na sobreposição de palavras, muitas vezes é mais fácil responder à pergunta "por que este documento está bem classificado?".

Conforme mencionado anteriormente, este protótipo serve como um exemplo de como os modelos de incorporação podem ser usados com campos vetoriais, e não como uma solução pronta para produção. Ao desenvolver uma nova estratégia de busca, é fundamental testar o desempenho da abordagem em seus próprios dados, certificando-se de compará-la com uma base de referência sólida, como uma consulta de correspondência. Pode ser necessário fazer mudanças significativas na estratégia antes que ela alcance resultados sólidos, incluindo o ajuste fino do modelo de incorporação para o conjunto de dados alvo ou a tentativa de diferentes maneiras de incorporar embeddings, como a expansão de consultas em nível de palavra.

Conclusões

As técnicas de incorporação oferecem uma maneira poderosa de capturar o conteúdo linguístico de um texto. Ao indexar representações vetoriais e atribuir pontuações com base na distância vetorial, podemos comparar documentos usando uma noção de similaridade que vai além da sobreposição em nível de palavras.

Estamos ansiosos para introduzir mais funcionalidades baseadas no tipo de campo vetorial. O uso de vetores para busca é uma área complexa e em constante desenvolvimento — como sempre, adoraríamos saber mais sobre seus casos de uso e experiências no Github e nos fóruns de discussão!