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 vimos na postagem anterior, a consistência proporcionada pela chamada de função não é apenas uma mera otimização; é essencial. Uma vez removidos os erros estruturais do ciclo de avaliação, os resultados em cenários padrão (como os do conjunto de dados de nível 4) melhoraram significativamente.

No entanto, há uma pergunta óbvia a ser respondida:

Essa abordagem ainda funciona quando as coisas realmente ficam confusas?

A resolução de entidades no mundo real raramente falha por causa de casos simples. Ela falha quando nomes cruzam línguas, culturas, sistemas de escrita, períodos de tempo e fronteiras organizacionais. Ela falha quando as pessoas são referenciadas por títulos em vez de nomes, quando as empresas mudam de nome, quando as transliterações não são consistentes e quando o contexto (não a ortografia) é a única coisa que vincula uma menção a uma entidade do mundo real.

Então, para o post final desta série, colocamos o sistema no que chamamos de desafio definitivo.

O que faz disso o desafio definitivo?

Em avaliações anteriores, testamos o sistema usando conjuntos de dados cada vez mais complexos. Quando chegamos ao nível 4, discutido no post anterior, já estávamos lidando com uma mistura de apelidos, títulos, nomes multilíngues e referências semânticas. Esses testes mostraram que a arquitetura em si era sólida, mas que problemas de confiabilidade, especialmente JSON malformado, estavam prejudicando o recall.

Com a chamada de função implementada, finalmente tivemos uma base estável. Isso nos deu a oportunidade de fazer uma pergunta mais interessante:

Um único pipeline unificado consegue lidar com vários tipos diferentes de problemas de resolução de entidades simultaneamente?

O conjunto de dados de desafio definitivo foi projetado para explorar precisamente essa dimensão.

Em vez de se concentrar em uma única dificuldade (como apelidos ou transliteração), este conjunto de dados combina mais de 50 tipos de desafios distintos, incluindo:

• Convenções culturais de nomeação.

• Referências baseadas em títulos.

• Relações comerciais e mudanças históricas de nome.

• Menções multilíngues e em diferentes sistemas de escrita.

• Desafios complexos que misturam vários dos itens acima.

O mais importante é que isso não se trata de otimizar para um caso de uso específico. Trata-se de testar se o padrão de design se sustenta quando as regras mudam de entidade para entidade.

Visão geral do conjunto de dados

O conjunto de dados de desafio definitivo consiste em:

• 50 entidades, abrangendo pessoas, organizações e instituições.

• Cerca de 60 artigos, com estrutura e complexidade linguística variadas.

• 51 categorias distintas de desafios, agrupadas de forma ampla em:

  • Convenções culturais de nomeação.

  • Títulos e o contexto profissional.

  • Relacionamentos empresariais e organizacionais.

  • Desafios multilíngues e de transliteração.

  • Cenários combinados e casos limite.

No início da série, vimos que usar IA generativa (GenAI) para criar conjuntos de dados pode ser uma faca de dois gumes. Sem ele, reunir dados de teste suficientemente grandes e diversos seria extremamente difícil. Mas, se não for controlado, o modelo tende a simplificar demais as coisas.

Em uma etapa inicial de geração, por exemplo, descobrimos que o modelo incluía frases como "o presidente russo" como apelidos explícitos para Vladimir Putin. Isso pode parecer razoável hoje, mas anula o propósito de testar a resolução contextual. O que acontece se o artigo estiver discutindo a Rússia nos anos 1990? O sistema deve inferir a entidade correta a partir do contexto, não depender de um alias fixo.

Por esse motivo, este conjunto de dados foi deliberadamente projetado para que os atalhos não funcionem. Os pseudônimos não são explicitamente listados quando se espera que o sistema deduza o significado. Frases descritivas não são vinculadas previamente a entidades. As correspondências corretas frequentemente dependem do contexto em nível de artigo, não apenas do texto local.

Observação importante: embora demonstremos os recursos do sistema em diversos cenários, este ainda é um protótipo educacional. Os sistemas de produção que lidam com o monitoramento real de entidades sob sanção exigiriam validação adicional, verificações de conformidade, trilhas de auditoria e tratamento especializado para casos de uso sensíveis.

Por que esses cenários são difíceis?

No primeiro post desta série, apresentamos um exemplo simples, mas ambíguo: "A nova atualização do Swift chegou!" O desafio é que "Swift" pode corresponder a múltiplas entidades do mundo real, dependendo do contexto. Esse exemplo captura uma verdade mais ampla: a linguagem natural é inerentemente ambígua.

A resolução de entidades, portanto, não é apenas um problema de correspondência de strings. As pessoas normalmente se baseiam normalmente em conhecimento compartilhado, normas culturais e contexto situacional para resolver referências, e raramente percebemos que estamos fazendo isso.

Considere alguns casos comuns:

• Um título como “o presidente” não tem significado sem contexto geopolítico e temporal.

• O nome de uma empresa pode se referir a uma controladora, uma subsidiária ou uma marca anterior, dependendo de quando o artigo foi escrito.

• O nome de uma pessoa pode aparecer em diferentes ordens, sistemas de escrita ou transliterações, dependendo da língua e da cultura.

• A mesma frase pode se referir legitimamente a diferentes entidades em diferentes contextos, e o sistema deve ser capaz de rejeitar correspondências com a mesma confiança com que as aceita.

Não existe um conjunto único de regras que lide com tudo isso de forma clara. É por isso que este protótipo separa as responsabilidades de forma tão clara:

• O Elasticsearch reduz o conjunto de candidatos de forma eficiente e transparente.

• O LLM é usado apenas quando o julgamento é necessário e é obrigado a se explicar.

• Recuperação e raciocínio continuam sendo etapas distintas.

Essa separação se torna ainda mais importante à medida que a diversidade de tipos de desafios aumenta.

Como o sistema lida com a diversidade sem exceções específicas

Um dos resultados mais interessantes desta avaliação é o que não mudou:

• Não adicionamos lógica especial para nomes japoneses.

• Não adicionamos regras personalizadas para patronímicos árabes.

• Não adicionamos mapeamentos fixos para nomes históricos de empresas.

Em vez disso, o sistema se baseou nos mesmos elementos centrais apresentados anteriormente na série:

• Entidades enriquecidas por contexto indexadas para busca semântica.

• Recuperação híbrida (exata, alias e semântica) no Elasticsearch.

• Um pequeno e bem definido conjunto de correspondências candidatas.

• Julgamento de LLM restrito por chamada de função e esquemas mínimos.

Isso sugere que a flexibilidade do sistema vem da representação e da arquitetura, não de uma coleção de regras em constante crescimento.

Quando o sistema tem sucesso, é porque os candidatos certos são recuperados e o LLM tem contexto suficiente para explicar por que uma referência corresponde (ou não) a uma entidade específica.

Resultados: Como foi o desempenho?

No conjunto de dados de desafio definitivo, o sistema produziu os seguintes resultados gerais:

• Precisão: ~91%

• Recall: ~86%

• Pontuação F1: ~89%

• Taxa de aceitação em LLM: ~72%

Desempenho em diferentes tipos de desafio

A análise dos resultados por tipo de desafio revela pontos fortes e limitações:

O desempenho mais forte (100% na pontuação F1) foi observado em áreas como:

• Correspondência de entidades entre sistemas de escrita (cirílico, coreano e chinês).

• Cenários hebraicos (patronímicos, títulos profissionais, títulos religiosos, transliteração).

• Hierarquias de negócios (aeroespacial, manufatura diversificada, corporações multidivisionais).

• Títulos profissionais (acadêmicos, militares, políticos, religiosos).

• Cenários combinados em japonês envolvendo múltiplos sistemas de escrita.

Forte desempenho (pontuação F1 de 80–99%) incluiu:

• Figuras políticas internacionais (98%).

• Alterações históricas de nome (90%).

• Hierarquias empresariais complexas (89%).

• Nomes de empresas japonesas (93%).

• Transliteração entre escrituras (86%).

• Patrônimos árabes (86%).

Áreas mais desafiadoras incluíram:

• Transliteração avançada (chinês, coreano): 0% de pontuação F1.

• Certos cenários japoneses (honoríficos, ordem dos nomes, variação do sistema de escrita): ~67% F1.

• Alguns cenários árabes (nomes de empresas, referências institucionais): ~40% F1.

O que é importante aqui é por que o sistema teve dificuldades nesses casos. As falhas não foram causadas por problemas na abordagem geral, mas por limitações em componentes específicos, especialmente o modelo vetorial denso usado para busca semântica em determinados cenários multilíngues.

Como recuperação e julgamento estão claramente separados, melhorar o desempenho não exige reescrever o sistema. A substituição por um modelo de embeddings multilíngue mais capaz, o enriquecimento do contexto da entidade ou o refinamento das estratégias de recuperação melhoraria os resultados nessas categorias sem alterar a arquitetura central.

Do ponto de vista arquitetônico, essa é a verdadeira métrica de sucesso.

O que isso nos diz sobre o design

Olhando para trás na série, alguns padrões se destacam:

• A preparação é mais importante do que a combinação inteligente. Enriquecer entidades com contexto desde o início reduz drasticamente a ambiguidade depois.

• Os LLMs são mais valiosos como juízes, não como recuperadores. Pedir que expliquem por que uma combinação faz sentido é muito mais poderoso do que pedir que busquem.

• A confiabilidade possibilita precisão. A chamada de funções não apenas limpou o JSON; ela revelou o recall que já estava latente na etapa de recuperação.

• A generalização supera a especialização. Um pequeno número de abstrações bem definidas lidou com dezenas de tipos de desafios sem lógica personalizada.

Por isso, o protótipo é intencionalmente nativo do Elasticsearch e conservador na forma como utiliza LLMs. O objetivo não é substituir a busca; é tornar a busca explicável em situações onde o significado importa.

Conclusão

O desafio final não era buscar métricas perfeitas; era sobre responder a uma pergunta mais fundamental:

Uma arquitetura transparente, orientada para busca e assistida por LLM, pode lidar com a ambiguidade de entidades no mundo real sem se limitar a regras ou caixas-pretas?

Para este protótipo educacional, a resposta é sim, com claras ressalvas sobre robustez para produção, conformidade, monitoramento e qualidade dos dados. Se você estiver criando sistemas que precisem justificar por que foi feita uma correspondência de entidade, vale a pena considerar seriamente esse padrão. Espero que esta série tenha mostrado que a resolução de entidades não precisa ser algo misterioso. Com a separação certa das preocupações, torna-se algo sobre o qual você pode refletir, medir e melhorar.

Este trabalho também sugere um padrão arquitetônico mais amplo. O que surge é uma leve, mas importante, evolução da Retrieval-Augmented Generation (RAG). Em vez de permitir que a recuperação alimente diretamente a geração, introduzimos uma etapa explícita de avaliação. O LLM é usado primeiro para avaliar e verificar a consistência dos candidatos recuperados, e apenas os resultados aprovados podem ampliar a geração. Você pode pensar nisso como Retrieval-Augmented Generation com Avaliação, ou GARAGE, porque quem não gosta de uma boa sigla.

Quais outros casos de uso poderiam se beneficiar desse padrão? Sistemas que exigem confiança, transparência e raciocínio defensável são candidatos naturais. Trabalhos futuros nessa área devem ser tão interessantes quanto os resultados que vimos aqui, e estou entusiasmado para ver para onde a comunidade vai levar isso a seguir.

Próximos passos: Experimente por conta própria

Quer ver o desafio definitivo em ação? Confira o Notebook do desafio definitivo para ver um passo a passo completo, com implementações reais, explicações detalhadas e exemplos práticos.

O pipeline completo de resolução de entidades demonstra os conceitos centrais e a arquitetura necessários para uso em produção. Você pode usá-lo como base para construir sistemas que monitorem artigos de notícias, rastreiem menções de entidades e respondam a perguntas sobre quais entidades aparecem em quais artigos, tudo isso mantendo transparência e explicabilidade.

1. A nova atualização do Swift chegou! Os desenvolvedores estão ansiosos para experimentar os novos recursos.

2. A nova atualização do Swift chegou! O novo álbum será lançado no próximo mês.

Com esse contexto adicional, devemos conseguir resolver o nome "Swift" para a entidade correta.

Na postagem anterior, configuramos nossa lista de observação e enriquecemos as entidades com contexto adicional. Olhando nossos exemplos acima, precisamos ter pelo menos as seguintes duas entidades na lista: Taylor Swift e Swift Programming Language. Também abordamos como extraímos menções a entidades do texto. Ambos os exemplos extrairiam "Swift". Com esses ingredientes prontos, a lista de observação enriquecida e as entidades extraídas, finalmente estamos prontos para apresentar a estrela do show: a correspondência de entidades.

Lembre-se: este é um protótipo educacional projetado para ensinar conceitos de correspondência de entidades. Os sistemas de produção podem usar diferentes modelos de linguagem grande (LLMs), regras de correspondência personalizadas, pipelines de julgamento especializados ou abordagens de conjunto que combinam várias estratégias de correspondência.

O problema: por que a correspondência é difícil

A linguagem humana é algo extraordinário. Uma das propriedades mais interessantes é sua criatividade infinita. Podemos gerar e entender um número infinito de novas frases. Será que é de se estranhar, então, que correspondências exatas na resolução das entidades sejam raras? Autores se esforçam para ser criativos quando podem. Ficaria bastante cansativo se tivéssemos que escrever e ler nomes completos sempre que uma entidade fosse mencionada. Portanto, embora as correspondências exatas sejam fáceis, a realidade é que precisamos de uma abordagem mais sofisticada para a resolução de entidades: uma que seja robusta o suficiente para lidar com pelo menos parte da criatividade ilimitada de autores humanos. Por isso, dividimos o problema em duas etapas: usar o Elasticsearch para recuperar candidatos plausíveis em larga escala, e depois usar um LLM para julgar se esses candidatos realmente se referem à mesma entidade do mundo real.

A solução: correspondência em três etapas com julgamento transparente do LLM

Estamos no meio de uma mudança de paradigma na forma como usamos computadores. Assim como a ascensão da Internet nos levou da computação localizada para uma rede conectada globalmente, a IA generativa (GenAI) está mudando fundamentalmente a forma como o conteúdo, o código e as informações são criados. Na verdade, o protótipo educacional que acompanha essa série foi quase exclusivamente "codificado por vibração" usando um LLM, com orientação cuidadosa do autor. Isso não quer dizer que os LLMs tenham ou que alcançarão o tipo de produtividade inerente à linguagem humana, mas significa que agora temos um recurso poderoso para ajudar na resolução de entidades.

Um padrão comum que usamos com GenAI é a retrieval augmented generation (RAG). Aqui, retrieval significa recuperar entidades candidatas (não gerar respostas), e o LLM é usado estritamente para avaliação e explicação da correspondência. Embora pudéssemos pedir a um LLM para nos ajudar com a resolução de entidades de ponta a ponta, essa abordagem é dispendiosa, tanto em termos de tempo quanto de dinheiro. A RAG ajuda os LLMs a realizar seu trabalho usando maneiras mais eficientes de fornecer contexto ao LLM, capacitando-o a auxiliar de forma eficiente na resolução de entidades.

Para a parte de recuperação do RAG, voltamos novamente ao Elasticsearch. Primeiro, encontramos possíveis correspondências usando uma combinação de correspondência exata, correspondência com aliases e busca híbrida, que combina busca semântica e por palavra-chave. Assim que encontramos essas possíveis correspondências, as enviamos para um LLM para julgamento. O LLM atua como avaliador final de correspondência. Também fazemos o LLM explicar seu raciocínio, um diferenciador importante em relação a outros sistemas de resolução de entidades. Sem essas explicações, a resolução de entidades é uma caixa preta; com elas, podemos ver por nós mesmos por que uma correspondência faz sentido.

Conceitos-chave: correspondência em três etapas, busca híbrida e julgamento transparente de LLM

O que é a correspondência em três etapas? No início deste projeto, hipotetizamos que a busca semântica será uma parte crucial do sistema, mas nem toda correspondência exige uma busca tão sofisticada. Para encontrar correspondências de forma eficiente, adotamos uma abordagem progressiva ao problema. Primeiro, verificamos correspondências exatas usando busca por palavras-chave. Se encontrarmos essa correspondência, nosso trabalho estará feito e poderemos seguir em frente. Se a correspondência exata falhar, recorremos à correspondência de alias. No protótipo, a correspondência de alias também é feita usando correspondência exata com palavras-chave, para simplificar. Na produção, você pode expandir essa etapa com normalização, regras de transliteração, correspondência fuzzy ou tabelas de alias curadas. Se ainda não encontramos uma possível correspondência nas duas primeiras etapas, é hora de introduzir a busca semântica por meio da busca híbrida do Elasticsearch com fusão recíproca de classificação (RRF).

O que é busca híbrida? No Elasticsearch, podemos usar a busca semântica para encontrar correspondências significativas que levem em conta o contexto. O Elasticsearch é amplamente utilizado para busca vetorial e recuperação híbrida. A semelhança semântica é poderosa para o significado, mas não substitui a filtragem estruturada (por exemplo, por intervalos de tempo, locais ou identificadores) e geralmente é desnecessária quando uma correspondência exata está disponível. O Elasticsearch se destacou com a busca lexical, que é ótima em tarefas onde a busca semântica não se encaixa. Para aproveitar ao máximo ambas as abordagens, usamos a busca lexical junto com a busca semântica em uma única consulta híbrida. Depois, juntamos os resultados para encontrar as correspondências mais prováveis usando o RRF. No protótipo, os dois melhores resultados tornam-se correspondências potenciais que podem ser enviadas para avaliação do LLM.

Por que julgamento de LLM? Julgamentos e explicações de LLM permitem que nosso sistema trate ambiguidade e contexto de forma transparente. Isso é vital para casos como "o presidente", que pode se referir a múltiplas entidades, dependendo do contexto, mas também faz com que apelidos e variações culturais funcionem bem no sistema. Finalmente, quando consideramos tarefas de missão crítica, como identificar entidades a partir de listas de sanções, precisamos saber por que uma combinação foi aceita para confiar no sistema. Crucialmente, o LLM não busca o corpus completo; ele avalia apenas o pequeno conjunto de candidatos retornados pelo Elasticsearch.

Resultados do mundo real: correspondência com raciocínio de LLM

Um dos principais desafios de qualquer tarefa de processamento de linguagem natural é a criação de um documento de referência, um "gabarito" que nos diga quais são os resultados esperados. Sem isso, é praticamente impossível avaliar o desempenho de um sistema em uma tarefa, mas criar um documento desse tipo pode ser um processo trabalhoso. Para o protótipo de resolução de entidades, recorremos novamente à GenAI para nos ajudar a configurar os dados que pudéssemos usar para os testes.

Primeiro, definimos vários tipos de desafios, como apelidos e transliteração, e então pedimos ao LLM para criar uma coleção em camadas de conjuntos de dados que se tornariam progressivamente maiores e mais desafiadores para o sistema. A criação dos conjuntos de dados foi menos simples do que se esperava. O LLM tinha uma forte propensão para "trapacear" ao tornar muito fácil obter a resposta certa. Por exemplo, um dos tipos de desafio focou no contexto semântico. Este tipo incluiu coisas como resolver "autor russo" para "Liev Tolstói". O LLM incorretamente colocou "autor russo" como um alias para "Leo Tolstoy", o que negou a necessidade de uma busca híbrida para encontrar a correspondência.

Após várias refatorações para corrigir problemas como esse, tínhamos cinco níveis de conjunto de dados para trabalhar. Os níveis 1 a 4 eram progressivamente maiores, com mais tipos de desafio. O Tier 5 era o conjunto de dados do "desafio supremo", composto pelos exemplos mais difíceis de todos os tipos de desafio. Todos os dados dos testes estão disponíveis no diretório de avaliação completo.

Para avaliar nossa abordagem de resolução de entidades baseada em prompts, focamos nossa atenção no conjunto de dados de nível 4. Um ponto importante é que a avaliação foi realizada como um experimento controlado para que pudéssemos focar na qualidade da correspondência de entidades. Os dados da lista de observação foram pré-enriquecidos com contexto, e as entidades foram extraídas do artigo antecipadamente. Isso garantiu que a avaliação fosse focada em correspondência, e não na precisão da extração. Isso isola a qualidade da correspondência; o desempenho de ponta a ponta também dependeria da qualidade do recall e do enriquecimento da extração.

Conjunto de dados de avaliação

O conjunto de dados de avaliação de nível 4 fornece um teste abrangente das capacidades do sistema:[1]

• Entidades da lista de observação: 66 entidades de diversos tipos (pessoas, organizações, locais).

• Artigos de teste: 69 artigos que abrangem cenários reais de resolução de entidades.

• Correspondências esperadas: 206 correspondências de entidades esperadas em todos os artigos.

• Tipos de desafio: 15 tipos diferentes de desafio que testam vários aspectos da resolução de entidades.

Os tipos de desafios incluídos no conjunto de dados são:

• Apelidos: "Bob Smith" → "Robert Smith" (sete artigos).

• Títulos e honoríficos: "Dr. Sarah Williams" → "Sarah Williams" (cinco artigos).

• Contexto semântico: "autor russo" → "Liev Tolstói" (oito artigos).

• Nomes multilíngues: manuseio de nomes em diferentes scripts (seis artigos).

• Entidades empresariais: variações de nome corporativo (sete artigos).

• Referências executivas: "CEO da Microsoft" → "Satya Nadella" (cinco artigos).

• Líderes políticos: referências baseadas em títulos (cinco artigos).

• Iniciais: "J. Smith" → "John Smith" (três artigos).

• Variações na ordem dos nomes: diferentes convenções de ordenação de nomes (três artigos).

• Nomes truncados: correspondências parciais de nomes (três artigos).

• Divisão de nomes: nomes divididos no texto (três artigos).

• Falta de espaços/hífens: variações de formatação (dois artigos).

• Transliteração: correspondência de nomes entre escrituras (dois artigos).

• Desafios combinados: Vários desafios em um único artigo (seis artigos).

• Negócios complexos: relações comerciais hierárquicas (cinco artigos).

Vamos ver como a resolução de entidades baseada em prompts foi realizada.

Desempenho geral

Os resultados mostram que a avaliação de correspondência baseada no LLM é muito promissora, mas também revelam um problema significativo de confiabilidade. Como cada par de candidatos deve ser avaliado pelo LLM, falhas na saída estruturada podem suprimir a aceitação e a recuperação, mesmo quando a recuperação está funcionando bem.

Métrica

Valor

Precisão

83,8%

Recall

62,6%

Pontuação F1

71,7%

Total de correspondências encontradas

344

Taxa de aceitação do LLM

44,8%

Taxa de erro

30,2%

O problema da taxa de erro

Lembre-se de que o primeiro passo que damos no protótipo é criar potenciais pares de correspondência usando o Elasticsearch. Cada uma dessas possíveis correspondências precisa ser avaliada pelo LLM. Para processar eficientemente todas essas correspondências, agrupamos as chamadas de LLM em lote. Isso reduz os custos da API e a latência, mas também há um risco aumentado de obter JSON malformado na saída. À medida que o tamanho do lote aumenta, o JSON se torna mais longo e complexo, tornando mais provável que o LLM gere JSON inválido. É daí que decorre a taxa de erro de 30%. Na avaliação, usamos um tamanho de lote de cinco correspondências por solicitação. Mesmo com este tamanho de lote conservador, ainda vemos falhas na análise JSON, o que distorce significativamente os resultados da avaliação.

O que vem a seguir: otimização da integração com LLMs

Agora que combinamos entidades usando busca semântica e julgamento de LLM, temos um pipeline completo de resolução de entidades. Essa abordagem introduz um novo modo de falha, no entanto, quando o julgamento do modelo está correto, mas sua saída não é utilizável. Podemos otimizar a integração do LLM para maior confiabilidade e eficiência de custos. No próximo post, exploraremos como usar o chamado de função para saída estruturada, que garante estrutura e segurança de tipos, ao mesmo tempo em que reduz erros e custos.

Experimente você mesmo

Quer ver a correspondência de entidades em ação? Confira o notebook do Entity Matching para ver um passo a passo completo com implementações reais, explicações detalhadas e exemplos práticos. O caderno mostra exatamente como combinar entidades usando busca em três etapas, busca híbrida com RRF e julgamento baseado em LLM com raciocínio.

Lembre-se: este é um protótipo educacional projetado para ensinar os conceitos. Ao construir sistemas de produção, considere fatores adicionais, como seleção de modelos, otimização de custos, requisitos de latência, validação de qualidade, tratamento de erros e monitoramento, que não são abordados neste protótipo focado em aprendizado.

Notas

1. Esses conjuntos de dados são sintéticos e projetados para educação; eles se aproximam de desafios reais, mas não representam nenhum domínio de produção específico.

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

Contexto: Precisão e recall

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

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

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

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

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

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

Normalização da pontuação

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

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

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

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

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

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

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

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

Busca híbrida usando o recuperador linear

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

Busca híbrida usando o RRF

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

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

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

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

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

Conclusão

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

Os conectores personalizados permitem que você combine seus conectores ChatGPT existentes com fontes adicionais de dados, como o Elasticsearch, para obter respostas abrangentes.

Neste artigo, criaremos um servidor MCP que conecta o ChatGPT a um índice Elasticsearch contendo informações sobre problemas internos e solicitações de pull do GitHub. Isso permite que consultas em linguagem natural sejam respondidas usando os dados do seu Elasticsearch.

Implantaremos o servidor MCP usando o FastMCP no Google Colab com ngrok para obter um URL público ao qual o ChatGPT possa se conectar, eliminando a necessidade de uma configuração de infraestrutura complexa.

Para uma visão geral do MCP e seu ecossistema, consulte O Estado Atual do MCP.

Pré-requisitos

Antes de começar, você precisará de:

• Cluster do Elasticsearch (8.X ou superior)

• Chave de API do Elasticsearch com acesso de leitura ao seu índice

• Conta do Google (para o Google Colab)

• Conta Ngrok (versão gratuita funciona)

• Conta do ChatGPT com plano Pro/Empresarial/Business ou Edu

Entendendo os requisitos do conector MCP do ChatGPT

Os conectores MCP do ChatGPT exigem a implementação de duas ferramentas: search e fetch. Para mais detalhes, consulte OpenAI Docs.

Ferramenta de busca

Retorna uma lista de resultados relevantes do seu índice Elasticsearch com base em uma consulta do usuário.

O que ele recebe:

• Uma única string com a consulta de linguagem natural do usuário.

• Exemplo: "Encontre problemas relacionados à migração do Elasticsearch."

O que ele retorna: 

• Um objeto com uma chave result contendo um array de objetos de resultado. Cada resultado inclui:

  • id - Identificador único do documento

  • title - Título da issue ou do PR

  • url - Link para o problema/PR

Na nossa implementação:

Ferramenta de recuperação

Recupera o conteúdo completo de um documento específico.

O que ele recebe:

• Uma única string com o ID do documento Elasticsearch do resultado de busca

• Exemplo: "Me dê os detalhes do PR-578."

O que ele retorna:

• Um objeto de documento completo com:

  • id - Identificador único do documento

  • title - Título da issue ou do PR

  • text - Complete a descrição e os detalhes do problema/PR

  • url - Link para o problema/PR

  • type - Tipo de documento (issue, pull_request)

  • status - Status atual (aberto, em_andamento, resolvido)

  • priority - Nível de prioridade (baixo, médio, alto, crítico)

  • assignee - Pessoa designada para o problema/PR

  • created_date - Quando foi criado

  • resolved_date - Quando foi resolvido (se aplicável)

  • labels - Tags associadas ao documento

  • related_pr - ID de pull request relacionado

Observação: este exemplo usa uma estrutura plana onde todos os campos estão no nível raiz. Os requisitos do OpenAI são flexíveis e também permitem objetos de metadados aninhados.

Questões do GitHub e conjunto de dados PRs

Para este tutorial, vamos usar um conjunto de dados interno do GitHub contendo problemas e solicitações de pull. Isso representa um cenário em que você deseja consultar dados privados e internos por meio do ChatGPT.

O conjunto de dados pode ser encontrado aqui. E atualizaremos o índice dos dados usando a bulk API.

Esse conjunto de dados inclui:

• Problemas com descrições, status, prioridade e responsáveis

• Solicitações de pull com alterações de código, revisões e informações de implantação

• Relações entre problemas e PRs (por exemplo, PR-578 corrige o ISSUE-1889)

• Rótulos, datas e outros metadados

Mapeamentos de índice

O índice usa os seguintes mapeamentos para permitir a pesquisa híbrida com o ELSER. A text_semantic é usada para busca semântica, enquanto outros campos permitem a busca por palavras-chave.

Construa o servidor MCP

Nosso servidor MCP implementa duas ferramentas seguindo as especificações da OpenAI, usando busca híbrida para combinar correspondência semântica e de texto para obter melhores resultados.

Ferramenta de busca

Utiliza busca híbrida com RRF (Reciprocal Rank Fusion), combinando buscar semântica com correspondência de texto:

Pontos principais:

• Busca híbrida com RRF: combina busca semântica (ELSER) e busca por texto (BM25) para melhores resultados.

• Consulta multi-correspondência: busca em múltiplos campos com aumento de relevância (title^3, text^2, assignee^2). O símbolo de caret (^) multiplica as pontuações de relevância, priorizando as correspondências nos títulos em detrimento do conteúdo.

• Correspondência inexata: fuzziness: AUTO lida com erros de digitação e ortografia, permitindo correspondências aproximadas.

• Ajuste dos parâmetros do RRF:

  • rank_window_size: 50 - Especifica quantos resultados principais de cada recuperador (semântico e textual) são considerados antes da mesclagem.

  • rank_constant: 60 - Esse valor determina quanta influência os documentos em conjuntos de resultados individuais têm sobre o resultado final classificado.

• Retorna somente os campos obrigatórios: id, title, url de acordo com a especificação da OpenAI e evita a exposição desnecessária de campos adicionais.

Ferramenta de recuperação

Recupera detalhes do documento pelo ID do documento, quando existe:

Pontos principais:

• Buscar por campo de ID do documento: Utiliza consulta de termo no campo personalizado id

• Retorna o documento completo: inclui o campo text completo com todo o conteúdo

• Estrutura plana: Todos os campos no nível da raiz, correspondendo à estrutura de documentos do Elasticsearch.

Implantar no Google Colab

Usaremos o Google Colab para executar nosso servidor MCP e o ngrok para expô-lo publicamente, permitindo que o ChatGPT se conecte a ele.

Etapa 1: Abra o notebook do Google Colab

Acesse nosso notebook pré-configurado Elasticsearch MCP para ChatGPT.

Etapa 2: Configure suas credenciais

Você precisará de três informações:

• URL do Elasticsearch: seu URL do cluster do Elasticsearch.

• Chave da API do Elasticsearch: Chave da API com permissão de leitura do seu índice.

• Token de autenticação Ngrok: token grátis do ngrok. Vamos usar o ngrok para expor a URL do MCP à internet para que o ChatGPT possa se conectar a ela.

Obter seu token ngrok

1. Cadastre-se para uma conta gratuita em ngrok

2. Acesse seu painel do ngrok

3. Copie seu token de autenticação.

Adicionando segredos ao Google Colab

No notebook do Google Colab:

1. Clique no ícone de chave na barra lateral esquerda para abrir Secrets.

2. Adicione estes três segredos:

3. Habilitar o acesso ao notebook para cada segredo

Passo 3: Execute o notebook

1. Clique em Runtime e depois em Executar tudo para executar todas as células

2. Aguarde o servidor iniciar (cerca de 30 segundos)

3. Procure a saída mostrando seu URL público do ngrok

4. A saída exibirá algo como:

Conectar-se ao ChatGPT

Agora vamos conectar o servidor MCP à sua conta do ChatGPT.

1. Abra o ChatGPT e vá para Configurações.

2. Navegue até Conectores. Se você estiver usando uma conta Pro, precisará ativar o modo de desenvolvedor nos conectores.

Se você está usando o ChatGPT em empresas ou negócios, precisa disponibilizar o conector para seu local de trabalho.

3. Clique em Criar.

Observação: nos espaços de trabalho Business, Empresarial e Edu, somente os proprietários, administradores e usuários com a respectiva configuração ativada (para Empresarial/Edu) podem adicionar conectores personalizados. Usuários com a função de membro padrão não têm permissão para adicionar conectores personalizados.

Após um conector ser adicionado e habilitado por um proprietário ou usuário administrador, ele fica disponível para todos os membros do espaço de trabalho.

4. Insira as informações necessárias e sua URL ngrok que termina em /sse/. Repare no "/" após "sse". Não vai funcionar sem ele:

• Nome: Elasticsearch MCP

• Descrição: MCP personalizado para pesquisar e recuperar informações internas do GitHub.

5. Pressione Criar para salvar o MCP personalizado.

A conexão será instantânea se seu servidor estiver em execução. Não é necessária autenticação adicional, pois a chave da API do Elasticsearch está configurada no seu servidor.

Teste o servidor MCP

Antes de fazer perguntas, você precisa selecionar qual conector o ChatGPT deve usar.

Prompt 1: Buscar por problemas

Pergunte: "Encontre problemas relacionados à migração do Elasticsearch" e confirme a chamada da ferramenta de ações.

O ChatGPT chamará a ferramenta search com sua consulta. Você pode ver que ele está procurando as ferramentas disponíveis, se preparando para chamar a ferramenta Elasticsearch e confirma com o usuário antes de tomar qualquer medida em relação à ferramenta.

Solicitação de chamada de ferramenta:

Resposta da ferramenta:

O ChatGPT processa os resultados e os apresenta em um formato natural e conversacional.

Nos bastidores

Prompt: "Encontrar problemas relacionados à migração do Elasticsearch"

1. Chamadas do ChatGPT search(“Elasticsearch migration”)

2. O Elasticsearch realiza uma busca híbrida

• A busca semântica compreende conceitos como "atualização" e "compatibilidade de versões".

• A busca de texto encontra correspondências exatas para "Elasticsearch" e "migração".

• O RRF combina e classifica os resultados de ambas as abordagens

3. Retorna os 10 melhores eventos de correspondência com id, title, url

4. O ChatGPT identifica "ISSUE-1712: migrar do Elasticsearch 7.x para o 8.x" como o resultado mais relevante

Prompt 2: Obter todos os detalhes

Perguntar: "Informe detalhes sobre o ISSUE-1889"

O ChatGPT reconhece que você quer informações detalhadas sobre um problema específico e aciona a ferramenta fetch, confirmando com o usuário antes de tomar qualquer medida em relação à ferramenta.

Solicitação de chamada de ferramenta:

Resposta da ferramenta:

O ChatGPT sintetiza as informações e as apresenta claramente.

Nos bastidores

Prompt: “Informe mais detalhes sobre ISSUE-1889”

1. Chamadas do ChatGPT fetch(“ISSUE-1889”)

2. O Elasticsearch recupera o documento completo

3. Retorna um documento completo com todos os campos no nível raiz

4. O ChatGPT sintetiza as informações e responde com citações adequadas.

Conclusão

Neste artigo, criamos um servidor MCP personalizado que conecta o ChatGPT ao Elasticsearch usando ferramentas MCP dedicadas de busca e recuperação, permitindo consultas em linguagem natural sobre dados privados.

Este padrão MCP funciona para qualquer índice Elasticsearch, documentação, produtos, log ou quaisquer outros dados que você queira consultar por meio de linguagem natural.

O problema da amplitude de pontuação

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

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

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

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

Analisando detalhadamente

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

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

2. text_field é um campo text padrão

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

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

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

Agrupamento de consultas

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

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

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

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

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

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

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

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

O formato de consulta com vários campos

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

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

• Determine o tipo de cada campo consultado.

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

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

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

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

Aumento por campo

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

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

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

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

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

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

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

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

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

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

Resolução curinga

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

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

Você pode usar o caractere curinga de diversas maneiras:

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

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

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

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

Campos de consulta padrão

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

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

• dense_vector campos

• rank_vector campos

• Campos geométricos: geo_point, shape

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

Conclusão

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

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

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

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

A busca não morreu, apenas mudou de lugar.

Assim, tivemos essa mudança de uma abordagem que consistia principalmente em buscar contexto por meio de uma caixa de texto e usar as informações (o contexto) retornadas para construir as respostas nós mesmos, para agora usar a linguagem natural para dizer a um agente o que queremos e deixar que ele pesquise e compile automaticamente a resposta para nós. Muitos no mundo da tecnologia estão apontando para essa mudança e proclamando que "a busca está morta" (bem, o mundo do SEO e do AdWords está definitivamente mudando: alguém aí se lembra do GEO ?), mas a busca ainda é absolutamente crucial para as operações de agentes — ela só é realizada, em grande parte, fora do campo de visão, por meio de ferramentas.

Anteriormente, os humanos eram os principais árbitros da relevância subjetiva: cada usuário tem seus próprios motivos para realizar a busca, e sua experiência pessoal influencia a precisão relativa dos resultados. Para confiarmos que os agentes podem chegar à mesma conclusão (ou melhor) que nós, precisamos garantir que as informações contextuais a que eles têm acesso sejam as mais próximas possíveis da nossa intenção subjetiva. Temos que estruturar o contexto que oferecemos aos mestrados em Direito (LLM) de forma a atingir esse objetivo!

Geração de contexto com recuperação de pesquisa híbrida

Só para relembrar, lá da Parte I, que a busca híbrida da Elastic combina os pontos fortes da busca tradicional baseada em palavras-chave (flexibilidade de sintaxe, precisão de palavras-chave e pontuação de relevância) com a compreensão semântica da busca por similaridade vetorial e oferece múltiplas técnicas de reclassificação. Essa sinergia (nunca se encontrou um uso mais preciso dessa palavra!) Permite resultados altamente relevantes, com consultas que podem ser muito mais específicas na forma como direcionam o conteúdo. Não se trata apenas de poder aplicar a relevância subjetiva como uma das etapas de recuperação; trata-se, na verdade, de que a recuperação na primeira etapa pode incluir a pontuação de relevância juntamente com todos os outros métodos simultaneamente.

Precisão e eficiência superiores

Utilizar uma plataforma de dados que possa fornecer busca, recuperação e reclassificação distribuídas como seu principal mecanismo de recuperação de contexto faz muito sentido. Você pode usar uma sintaxe de consulta avançada para adicionar o componente ausente da intenção subjetiva e filtrar o conteúdo que possa distrair ou obscurecer o valor das informações contextuais retornadas. Você pode selecionar qualquer uma das opções de sintaxe individuais disponíveis ou combinar modalidades em uma única pesquisa que visa cada tipo de dado da maneira que melhor o compreende e, em seguida, combiná-los/reordená-los com a reclassificação. Você pode filtrar a resposta para incluir apenas os campos/valores desejados, mantendo os dados irrelevantes afastados. Em termos de suporte aos agentes, essa flexibilidade de segmentação permite criar ferramentas extremamente precisas na forma como recuperam o contexto.

Refinamento de contexto (agregações e sinais não relacionados ao conteúdo)

As agregações podem ser especialmente úteis para moldar o conteúdo que uma ferramenta fornece à janela de contexto. As agregações fornecem naturalmente informações numéricas sobre o formato dos dados contextuais retornados, o que facilita e torna mais preciso o raciocínio dos Modelos de Aprendizagem Baseados em Leis (LLMs). Como as agregações podem ser hierarquicamente aninhadas, é uma maneira fácil de adicionar detalhes em vários níveis para o LLM, a fim de gerar uma compreensão mais matizada. As agregações também podem ajudar no gerenciamento do tamanho da janela de contexto — você pode facilmente reduzir o resultado de uma consulta de 100 mil documentos para algumas centenas de tokens de insights agregados.

Os sinais não relacionados ao conteúdo são os indicadores inerentes aos seus dados que fornecem uma visão mais ampla do que você está analisando; são as características adicionais dos resultados, como popularidade, atualidade, localização geográfica, categorias, diversidade de hospedagem ou faixas de preço. Essas informações podem ser úteis para orientar o agente na avaliação da importância do contexto recebido. Alguns exemplos simples podem ajudar a ilustrar isso melhor:

• Impulsionando conteúdo popular e publicado recentemente - Imagine que você tenha uma base de conhecimento com artigos. Você deseja encontrar artigos relevantes para a consulta de um usuário, mas também quer priorizar artigos que sejam recentes e que tenham sido considerados úteis por outros usuários (por exemplo, que tenham um grande número de "curtidas"). Nesse cenário, podemos usar uma busca híbrida para encontrar artigos relevantes e, em seguida, reclassificá-los com base em uma combinação de sua data de publicação e popularidade.

• Busca em e-commerce com ajuste de vendas e estoque - Em um ambiente de e-commerce, você deseja mostrar aos clientes produtos que correspondam ao termo de busca, mas também promover produtos que estejam vendendo bem e disponíveis em estoque. Você também pode querer diminuir a classificação de produtos com baixo estoque para evitar a frustração do cliente.

• Priorizando problemas de alta gravidade em um sistema de rastreamento de bugs - Para uma equipe de desenvolvimento de software, ao procurar problemas, é crucial que os problemas de alta gravidade, alta prioridade e atualizados recentemente sejam exibidos primeiro. Você pode usar indicadores não-sinais, como "criticidade" e "mais discutido", para ponderar diferentes fatores de forma independente, garantindo que as questões mais críticas e ativamente discutidas cheguem ao topo.

Essas consultas de exemplo e outras podem ser encontradas na página de conteúdo do Elasticsearch Labs que acompanha este artigo.

aplicação das leis de segurança

Uma vantagem crucial de utilizar uma camada de velocidade baseada em pesquisa, como o Elastic, para engenharia de contexto é sua estrutura de segurança integrada. A plataforma da Elastic garante que o contexto fornecido às operações de IA generativa e agente respeite e proteja informações confidenciais mantidas em sigilo por meio de controle de acesso baseado em funções (RBAC) e controle de acesso baseado em atributos (ABAC) granulares. Isso significa que não apenas as consultas são processadas com eficiência, mas também que os resultados são filtrados de acordo com as permissões específicas do agente ou do usuário que iniciou a solicitação.

Os agentes são executados como o usuário autenticado, portanto a segurança é aplicada implicitamente por meio dos recursos de segurança integrados à plataforma:

• Permissões refinadas: Defina o acesso no nível do documento, do campo ou até mesmo do termo, garantindo que os agentes de IA recebam apenas os dados que estão autorizados a visualizar.

• Controle de acesso baseado em funções (RBAC): Atribua funções a agentes ou usuários, concedendo acesso a conjuntos de dados ou funcionalidades específicas com base em suas responsabilidades definidas.

• Controle de acesso baseado em atributos (ABAC): Implemente políticas de acesso dinâmicas com base em atributos dos dados, do usuário ou do ambiente, permitindo uma segurança altamente adaptável e contextualizada.

• Segurança em nível de documento (DLS) e segurança em nível de campo (FLS): Esses recursos garantem que, mesmo dentro de um documento recuperado, apenas as partes autorizadas sejam visíveis, impedindo que informações confidenciais sejam expostas.

• Integração com segurança corporativa: Integre-se perfeitamente com sistemas de gerenciamento de identidade existentes (como LDAP, SAML, OIDC) para aplicar políticas de segurança consistentes em toda a organização.

Ao integrar essas medidas de segurança diretamente no mecanismo de recuperação de contexto, a Elastic atua como um guardião seguro, garantindo que os agentes de IA operem dentro de limites de dados definidos, evitando a exposição não autorizada de dados e mantendo a conformidade com as regulamentações de privacidade de dados. Isso é fundamental para construir confiança em sistemas de IA que lidam com informações confidenciais ou proprietárias.

Como benefício adicional, ao usar uma camada unificada de velocidade de dados sobre suas fontes de dados corporativas, você alivia as cargas inesperadas de consultas ad hoc nesses repositórios que as ferramentas de agentes criariam. Você obtém um local centralizado para pesquisar tudo em tempo quase real e um único lugar para aplicar controles de segurança e governança.

Ferramentas híbridas baseadas em pesquisa

Existem algumas funcionalidades essenciais (e outras estão sendo adicionadas constantemente) da plataforma Elastic que impulsionam a busca pela engenharia de contexto. O principal aqui é que a plataforma oferece uma infinidade de maneiras de atingir objetivos, com a flexibilidade para adaptar, alterar e expandir os métodos à medida que o ecossistema de IA avança.

Apresentando o Construtor de Agentes

O Elastic Agent Builder é nossa primeira incursão no mundo das ferramentas de IA com agentes, criadas para interagir com os dados que você já armazena no Elastic. O Agent Builder oferece uma interface de chat que permite aos usuários criar e gerenciar seus próprios agentes e ferramentas dentro do Kibana. Ele vem com servidores MCP e A2A integrados, APIs programáticas e um conjunto de ferramentas de sistema pré-construídas para consultar e explorar índices do Elasticsearch, além de gerar consultas ES|QL a partir de linguagem natural. O Agent Builder permite criar ferramentas personalizadas que visam e moldam os dados contextuais retornados ao agente por meio de uma sintaxe de consulta ES|QL expressiva.

Como o ES|QL realiza buscas híbridas, você pergunta? A funcionalidade principal é alcançada através da combinação do tipo de campo semantic_text e dos comandos FORK/FUSE (o FUSE usa RRF por padrão para mesclar os resultados de cada fork). Aqui está um exemplo simples de uma busca fictícia de produto:

A cláusula EVAL incluída em cada um dos ramos FORK no exemplo acima não é estritamente necessária; ela está incluída apenas para demonstrar como você pode rastrear de qual modalidade de pesquisa um determinado resultado foi retornado.

Modelos de pesquisa

Digamos que você queira direcionar suas próprias ferramentas externas de gerenciamento de agentes para sua implantação do Elasticsearch. E em vez de ES|QL, você deseja usar recuperadores de vários estágios ou reutilizar a sintaxe DSL existente que você desenvolveu, e também deseja poder controlar as entradas que a consulta aceita, a sintaxe usada para executar a pesquisa e os campos retornados na saída. Os modelos de pesquisa permitem que os usuários definam estruturas predefinidas para padrões de pesquisa comuns, melhorando a eficiência e a consistência na recuperação de dados. Isso é particularmente benéfico para ferramentas de agentes que interagem com APIs de busca, pois ajuda a padronizar o código repetitivo e permite uma iteração mais rápida na lógica de busca. E se alguma vez precisar ajustar algum desses fatores, basta atualizar o modelo de pesquisa e pronto, as alterações são implementadas. Se você procura um exemplo de modelos de pesquisa em ação com ferramentas agentivas, confira o blog do Elasticsearch Labs " MCP para pesquisa inteligente", que utiliza um modelo de pesquisa por trás de uma chamada de ferramenta de um servidor MCP externo.

Fluxos de trabalho integrados (SIM!)

Um dos aspectos mais difíceis de lidar em nosso novo mundo de IA com agentes é a natureza não determinística de agentes "racionais" semiautônomos e autodirigidos. A engenharia de contexto é uma disciplina crítica para a IA ativa: são as técnicas que ajudam a restringir as possíveis conclusões que nosso agente pode gerar ao que sabemos ser verdade fundamental. Mesmo com uma janela de contexto altamente precisa e relevante (quando saímos do âmbito dos fatos numéricos), ainda nos falta aquela garantia de que a resposta do agente seja totalmente repetível e confiável.

Ao executar a mesma solicitação para um agente várias vezes, as respostas podem ser essencialmente as mesmas, com apenas uma pequena diferença na forma como são enviadas. Isso geralmente funciona bem para consultas simples, talvez seja quase imperceptível, e podemos tentar moldar a saída com técnicas de engenharia de contexto. Mas, à medida que as tarefas que solicitamos aos nossos agentes se tornam mais complexas, aumenta a probabilidade de que uma ou mais subtarefas introduzam uma variação que altere ligeiramente o resultado final. É provável que a situação piore à medida que começarmos a depender mais da comunicação entre agentes, e essas variações se tornarão cumulativas. Isso reforça a ideia de que as ferramentas com as quais nossos agentes interagem precisam ser muito flexíveis e ajustáveis para direcionar com precisão os dados contextuais, e que devem responder em um formato de saída esperado. Isso também indica que, para muitos casos de uso, precisamos direcionar as interações entre agentes e ferramentas — é aí que os fluxos de trabalho entram em cena!

Em breve, a Elastic terá fluxos de trabalho totalmente personalizáveis integrados ao núcleo da plataforma. Esses fluxos de trabalho poderão operar com agentes e ferramentas de forma bidirecional, ou seja, os fluxos de trabalho poderão chamar agentes e ferramentas, e os agentes e ferramentas poderão chamar fluxos de trabalho. Ter essas funcionalidades totalmente integradas na mesma plataforma de IA de busca onde todos os seus dados residem será transformador; o potencial dos fluxos de trabalho é extremamente empolgante! Em breve, muito em breve!

Elástico como banco de memória unificado

Por ser uma plataforma de dados distribuída, criada para buscas quase em tempo real, a Elastic executa naturalmente as funções de memória de longo prazo para sistemas de IA com agentes. Com a experiência de chat integrada do Agent Builder, também temos rastreamento e gerenciamento da memória de curto prazo e do histórico de conversas. E como toda a plataforma é orientada a APIs, é extremamente fácil utilizar o Elastic como plataforma para persistir a saída contextual de uma ferramenta (e poder consultá-la posteriormente), o que poderia sobrecarregar a janela de contexto do agente; essa técnica às vezes é chamada de "anotações " em círculos de engenharia de contexto.

Ter memória de curto e longo prazo na mesma plataforma de busca traz muitos benefícios intrínsecos: imagine poder usar históricos de bate-papo e respostas contextuais persistentes como parte dos influenciadores semânticos em interações futuras, ou para realizar análises de ameaças, ou para criar produtos de dados persistentes que são gerados automaticamente a partir de chamadas de ferramentas repetidas com frequência… As possibilidades são infinitas!

Conclusão

O surgimento de grandes modelos de linguagem mudou a forma como conseguimos relacionar conteúdo e os métodos que usamos para analisar nossos dados. Estamos nos afastando rapidamente do mundo atual, onde os humanos realizam a pesquisa, a análise contextual e o raciocínio lógico para responder às suas próprias perguntas, para um mundo onde essas etapas são amplamente automatizadas por meio de inteligência artificial ativa. Para que possamos confiar nas respostas geradas que recebemos, precisamos ter a garantia de que o agente considerou todas as informações mais relevantes (incluindo o fator de relevância subjetiva) ao gerar sua resposta. Nosso principal método para tornar a IA agente confiável é fundamentar as ferramentas que recuperam contexto adicional por meio de técnicas de RAG (Aleatorização, Atribuição e Geração de Respostas) e engenharia de contexto, mas a forma como essas ferramentas realizam a recuperação inicial pode ser crucial para a precisão da resposta.

A plataforma Elastic Search AI oferece a flexibilidade e a vantagem da busca híbrida, juntamente com diversos recursos integrados que auxiliam a IA agente em termos de precisão, desempenho e escalabilidade; em outras palavras, o Elastic é uma plataforma fantástica para vários aspectos da engenharia de contexto! Ao padronizar a recuperação de contexto por meio de uma plataforma de busca, simplificamos as operações das ferramentas de inteligência artificial em várias frentes — e, assim como diz o paradoxo "ir mais devagar para ir mais rápido", a simplicidade na camada de geração de contexto significa uma IA mais rápida e confiável.

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

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

Parte I: Como os LLMs mudaram a busca

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

Nosso legado lexical

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

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

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

Entre o dragão (semântico)

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

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

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

Bancos de dados vetoriais

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

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

Um exemplo de consulta semântica

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

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

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

Técnicas de reclassificação

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Intervalo

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

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.

Leia o artigo "Building AI Agentic Workflows with Elasticsearch" para obter mais informações sobre o panorama geral desse projeto, ou "Your First Elastic Agent: From a Single Query to a AI-Powered Chat" para uma introdução mais prática.

Neste blog, porém, vamos nos aprofundar um pouco em uma das primeiras coisas que acontecem quando você começa a conversar e apresentar algumas das melhorias recentes que implementamos.

O que está acontecendo aqui?

Ao interagir com seus dados do Elasticsearch, nosso agente de IA padrão segue este fluxo padrão:

1. Examine o prompt.

2. Identifique qual índice provavelmente contém as respostas para essa pergunta.

3. Gere uma consulta para esse índice, com base no prompt.

4. Pesquise esse índice com essa consulta.

5. Sintetize os resultados.

6. Os resultados respondem à pergunta? Em caso afirmativo, responda. Caso contrário, repita, mas tente algo diferente.

Isso não deve parecer muito inovador - é apenas Geração Aumentada por Recuperação (RAG). E, como seria de esperar, a qualidade das suas respostas depende muito da relevância dos resultados da sua pesquisa inicial. Enquanto trabalhávamos para melhorar a qualidade de nossas respostas, prestamos muita atenção às consultas que gerávamos na etapa 3 e executávamos na etapa 4. E percebemos um padrão interessante.

Muitas vezes, quando nossas primeiras respostas eram "ruins", não era porque tínhamos executado uma consulta ruim. Isso aconteceu porque tínhamos escolhido o índice errado para consultar. Os passos 3 e 4 geralmente não eram o nosso problema - era o passo 2.

O que estávamos fazendo?

Nossa implementação inicial foi simples. Tínhamos criado uma ferramenta (chamada index_explorer) que efetivamente faria um _cat/indices para listar todos os índices disponíveis para nós e, em seguida, pediria ao LLM para identificar qual desses índices era a melhor correspondência para a mensagem/pergunta/solicitação do usuário. Você pode ver a implementação original aqui.

Quão bem isso estava funcionando? Não tínhamos certeza! Tínhamos exemplos claros de situações em que não estava funcionando bem, mas nosso primeiro desafio real foi quantificar nossa situação atual.

Estabelecer uma linha de base

Tudo começa com dados.

O que precisávamos era de um Conjunto de Dados Ideal para medir a eficácia de uma ferramenta na seleção do índice correto, dada uma solicitação do usuário e um conjunto preexistente de índices. E nós não tínhamos um conjunto de dados desse tipo disponível. Então, nós geramos um.

Reconhecimento: Sabemos que isso não é a "melhor prática". Mas, às vezes, é melhor seguir em frente do que ficar discutindo detalhes irrelevantes. Progresso, SIMPLES Perfeição.

Geramos índices iniciais para vários domínios diferentes usando este prompt. Em seguida, para cada domínio gerado, geramos mais alguns índices usando esse prompt (o objetivo aqui é semear confusão para o LLM com negativos difíceis e exemplos difíceis de classificar). Em seguida, editamos manualmente cada índice gerado e suas respectivas descrições. Por fim, geramos consultas de teste usando esse prompt. Isso nos deixou com dados de exemplo como:

e casos de teste como:

Construindo um arnês de teste

A partir daqui, o processo foi muito simples. Crie uma ferramenta que possa:

1. Crie um ambiente totalmente novo com um cluster Elasticsearch de destino.

2. Crie todos os índices definidos no conjunto de dados de destino.

3. Para cada cenário de teste, execute a ferramenta index_explorer (felizmente, temos uma API Execute Tool).

4. Compare o índice resultante com o índice esperado e registre o resultado.

5. Após concluir todos os cenários de teste, tabule os resultados.

A pesquisa indica…

Os resultados iniciais foram, previsivelmente, medíocres.

No geral, a precisão na identificação do índice correto foi de 77,14%. E isso no cenário "ideal", onde todos os índices têm nomes bons e semanticamente significativos. Qualquer pessoa que já tenha executado um `PUT test2/_doc/foo {...}` sabe que seus índices nem sempre têm nomes significativos.

Portanto, temos uma base de referência, e ela mostra que há muito espaço para melhorias. Chegou a hora de fazer ciência! 🧪

Experimentação

Hipótese 1: Os mapeamentos ajudarão

O objetivo aqui é identificar um índice que contenha dados relevantes para a pergunta original. E a parte de um índice que melhor descreve os dados que ele contém são os mapeamentos do índice. Mesmo sem obter nenhuma amostra do conteúdo do índice, saber que o índice possui um campo de preço do tipo double implica que os dados representam algo que está à venda. Um campo de autor do tipo texto implica alguns dados linguísticos não estruturados. A combinação dos dois pode sugerir que os dados são livros/histórias/poemas. Podemos obter muitas pistas semânticas apenas conhecendo as propriedades de um índice. Então, em uma branch local, eu ajustei nosso arquivo `.index_explorer`. Ferramenta para enviar os mapeamentos completos de um índice (juntamente com seu nome) ao LLM para que este tome uma decisão.

O resultado (dos registros do Kibana):

Os autores originais da ferramenta já haviam previsto isso. Embora o mapeamento de um índice seja uma mina de ouro de informações, ele também é um bloco JSON bastante extenso. E em um cenário realista onde você está comparando inúmeros índices (nosso conjunto de dados de avaliação define 20), esses blocos JSON se acumulam. Assim, queremos fornecer ao LLM mais contexto para sua decisão, não apenas os nomes dos índices de todas as opções, mas também os mapeamentos completos de cada uma.

Hipótese 2: Mapeamentos “achatados” (listas de campos) como solução de compromisso.

Partimos do pressuposto de que os criadores de índices usarão nomes de índice semanticamente significativos. E se estendermos essa suposição também aos nomes dos campos? Nosso experimento anterior falhou porque o mapeamento de JSON inclui MUITOS metadados e código repetitivo desnecessários.

O bloco acima, por exemplo, tem 236 caracteres e define apenas um único campo em um mapeamento do Elasticsearch. Enquanto a string “description_text” possui apenas 16 caracteres. Isso representa um aumento de quase 15 vezes na contagem de caracteres, sem uma melhoria semântica significativa na descrição do que esse campo implica sobre os dados disponíveis. E se buscássemos os mapeamentos para todos os índices, mas antes de enviá-los para o LLM, os "aplanássemos" em uma lista contendo apenas os nomes de seus campos?

Nós experimentamos.

Isso é ótimo! Melhorias em todos os aspectos. Mas será que poderíamos fazer melhor?

Hipótese 3: Descrições no mapeamento _meta

Se apenas os nomes dos campos, sem nenhum contexto adicional, causaram um salto tão grande, presumivelmente adicionar um contexto substancial seria ainda melhor! Não é necessariamente convencional que cada índice tenha uma descrição associada, mas é possível adicionar metadados de qualquer tipo ao objeto _meta do mapeamento. Retornamos aos índices gerados e adicionamos descrições para cada índice em nosso conjunto de dados. Contanto que as descrições não sejam excessivamente longas, elas devem usar menos tokens do que o mapeamento completo e fornecer informações significativamente melhores sobre quais dados estão incluídos no índice. Nosso experimento validou essa hipótese.

Uma pequena melhoria, e agora temos mais de 90% de precisão em todos os aspectos.

Hipótese 4: O todo é maior que a soma das partes.

Os nomes dos campos aumentaram nossos resultados. As descrições aumentaram nossos resultados. Portanto, utilizar tanto as descrições quanto os nomes dos campos deve apresentar resultados ainda melhores, certo?

Os dados indicaram "não" (nenhuma mudança em relação ao experimento anterior). A principal teoria era que, como as descrições foram geradas a partir dos campos/mapeamentos do índice, não havia informações suficientes entre esses dois contextos para adicionar algo "novo" ao combiná-los. Além disso, a carga útil que estamos enviando para nossos 20 índices de teste está ficando bastante grande. A linha de raciocínio que seguimos até agora não é escalável. Na verdade, há bons motivos para acreditar que nenhum dos nossos experimentos até agora funcionaria em clusters Elasticsearch, onde existem centenas ou milhares de índices para escolher. Qualquer abordagem que aumente linearmente o tamanho da mensagem enviada ao LLM à medida que o número total de índices aumenta provavelmente não será uma estratégia generalizável.

O que realmente precisamos é de uma abordagem que nos ajude a reduzir um grande número de candidatos apenas às opções mais relevantes…

O que temos aqui é um problema de busca.

Hipótese 5: Seleção via busca semântica

Se o nome de um índice tiver significado semântico, ele poderá ser armazenado como um vetor e pesquisado semanticamente.

Se os nomes dos campos de um índice tiverem significado semântico, eles podem ser armazenados como vetores e pesquisados semanticamente.

Se um índice possui uma descrição com significado semântico, ele também pode ser armazenado como um vetor e pesquisado semanticamente.

Atualmente, os índices do Elasticsearch não tornam nenhuma dessas informações pesquisável (talvez devêssemos!), mas foi bastante trivial improvisar algo que pudesse contornar essa lacuna. Utilizando a estrutura de conectores da Elastic, criei um conector que gera um documento para cada índice em um cluster. Os documentos resultantes seriam algo como:

Enviei esses documentos para um novo índice onde defini manualmente o mapeamento da seguinte forma:

Isso cria um único campo semantic_content, onde todos os outros campos com significado semântico são divididos em blocos e indexados. A busca neste índice torna-se trivial, bastando:

A ferramenta index_explorer modificada agora é muito mais rápida, pois não precisa fazer uma solicitação a um LLM, mas pode solicitar um único embedding para a consulta fornecida e executar uma operação de busca vetorial eficiente. Considerando o resultado mais relevante como nosso índice selecionado, obtivemos os seguintes resultados:

Essa abordagem é escalável. Essa abordagem é eficiente. Mas essa abordagem é pouco melhor do que a nossa abordagem inicial. Isso não é surpreendente; a abordagem de busca aqui é incrivelmente ingênua. Não há nuances. Não há reconhecimento de que o nome e a descrição de um índice devam ter mais peso do que um nome de campo arbitrário que o índice contenha. Não há como priorizar correspondências lexicais exatas em detrimento de correspondências sinônimas. No entanto, construir uma consulta altamente detalhada exigiria muitas suposições sobre os dados disponíveis. Até agora, já fizemos algumas suposições importantes sobre o significado semântico dos nomes de índices e campos, mas precisaríamos ir um passo além e começar a supor o quanto de significado eles têm e como se relacionam entre si. Sem fazer isso, provavelmente não conseguiremos identificar com segurança a melhor correspondência como nosso resultado principal, mas podemos afirmar com mais certeza que a melhor correspondência está em algum lugar entre os N melhores resultados. Precisamos de algo que possa consumir informações semânticas no contexto em que existem, comparando-as com outra entidade que pode se representar de uma maneira semanticamente distinta, e fazendo um julgamento entre elas. Como um mestrado em Direito.

Hipótese 6: Redução do conjunto de candidatos

Houve vários outros experimentos que vou abordar superficialmente, mas o principal avanço foi abandonar a ideia de escolher a melhor correspondência puramente com base em uma busca semântica e, em vez disso, usar a busca semântica como um filtro para eliminar índices irrelevantes da análise do LLM. Combinamos os algoritmos Linear Retrievers, Hybrid Search com RRF e semantic_text em nossa busca, limitando os resultados aos 5 índices de correspondência principais.

Em seguida, para cada correspondência, adicionamos o nome do índice, a descrição e os nomes dos campos a uma mensagem para o LLM. Os resultados foram fantásticos:

A maior precisão obtida em qualquer experimento até hoje! E como essa abordagem não aumenta o tamanho da mensagem proporcionalmente ao número total de índices, ela é muito mais escalável.

Resultados

O primeiro resultado claro foi que nossa linha de base pode ser melhorada. Isso parece óbvio em retrospectiva, mas antes do início da experimentação, houve uma discussão séria sobre se deveríamos abandonar completamente nossa ferramenta index_explorer e confiar na configuração explícita do usuário para limitar o espaço de busca. Embora essa ainda seja uma opção viável e válida, esta pesquisa mostra que existem caminhos promissores para automatizar a seleção de índices quando essas informações fornecidas pelo usuário não estão disponíveis.

A próxima conclusão clara foi que simplesmente adicionar mais caracteres descritivos ao problema tem resultados cada vez menores. Antes desta pesquisa, estávamos debatendo se deveríamos investir na expansão da capacidade do Elasticsearch para armazenar metadados em nível de campo. Atualmente, esses valores meta são limitados a 50 caracteres, e havia uma suposição de que precisaríamos aumentar esse valor para podermos obter uma compreensão semântica de nossos campos. Claramente, esse não é o caso, e o LLM parece funcionar muito bem apenas com os nomes das áreas de estudo. Poderemos investigar isso mais a fundo posteriormente, mas já não parece urgente.

Por outro lado, isso forneceu evidências claras da importância de se ter metadados de índice "pesquisáveis". Para esses experimentos, nós hackeamos um índice de índices. Mas isso é algo que poderíamos investigar, integrando diretamente ao Elasticsearch, criando APIs para gerenciar ou, pelo menos, estabelecendo uma convenção a respeito. Estaremos avaliando nossas opções e discutindo internamente, então fiquem atentos.

Finalmente, esse esforço confirmou o valor de dedicarmos tempo para experimentar e tomar decisões baseadas em dados. Na verdade, isso nos ajudou a reafirmar que nosso produto Agent Builder precisará de recursos robustos de avaliação integrados. Se precisarmos construir toda uma estrutura de testes apenas para uma ferramenta que seleciona índices, nossos clientes certamente precisarão de maneiras de avaliar qualitativamente suas ferramentas personalizadas à medida que fazem ajustes iterativos.

Estou ansioso para ver o que vamos construir, e espero que você também esteja!

Conheça o retriever linear!

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

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

É tão simples quanto:

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

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

Escalando as pontuações: kNN vs BM25

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

Pontuações da consulta A:

doc1

doc2

doc3

doc4

knn

0,347

0,35

0,348

0,346

bm25

100

1,5

1

0,5

Pontuações da consulta B:

doc1

doc2

doc3

doc4

knn

0,347

0,35

0,348

0,346

bm25

0,63

0,01

0,3

0,4

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

Normalização para o resgate: o normalizador MinMax

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

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

Pontuações da consulta A:

doc1

doc2

doc3

doc4

knn

0,347

0,35

0,348

0,346

bm25

1,00

0,01

0,005

0,000

Pontuações da consulta B:

doc1

doc2

doc3

doc4

knn

0,347

0,35

0,348

0,346

bm25

1,00

0,000

0,465

0,645

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

Exemplo de recuperador linear

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

doc1

doc2

doc3

doc4

knn

0,347

0,35

0,348

0,346

bm25

100

1,5

1

0,5

pontuação rrf

0,03226

0,03252

0,03200

0,03125

rrf classificaria os documentos como:

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

doc1

doc2

doc3

doc4

knn

0,347

0,35

0,348

0,346

bm25

1

0,01

0,005

0

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

Juntando tudo

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

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

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

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

O recuperador linear :

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

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

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

Conclusão

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