Como o MATCH e TO_TEXT habilitam a busca de texto completo em qualquer expressão ES|QL

Vamos começar com uma consulta que era impossível no Elasticsearch 9.4, que usa o comando EVAL:

Neste exemplo, resumo não possui mapeamento ou configuração de analisador. Também não está associado a nenhum índice invertido. Ele existe apenas durante a vida útil dessa consulta, mas agora você pode buscar mesmo assim. Duas adições fazem isso funcionar.

Primeiro, MATCH agora aceita qualquer expressão como seu primeiro argumento, não apenas um campo mapeado. Isso inclui colunas produzidas pelo EVAL e resultados de funções usados em linha. Também inclui campos não mapeados carregados diretamente do documento original. Além disso, todos os tipos de dados normalmente aceitos pelo MATCH são suportados neste novo caso de uso.

A segunda parte disso é a nova função TO_TEXT, que é a primeira função de conversão ES|QL que produz saída do tipo texto. Até agora, colunas de texto só podiam vir de campos mapeados indexados, e todas as strings produzidas pelas expressões ES|QL eram valores de palavras-chave em vez de texto. A distinção importa porque o MATCH trata os dois de forma diferente: os valores do texto são analisados, enquanto os valores das palavras-chave são comparados exatamente, espelhando como uma consulta MATCH em um campo indexado se reescreve para uma consulta de termo. TO_TEXT(x) é como você diz ao ES|QL: trate essa sequência como texto completo.

Este é incluído como uma prévia técnica no Elasticsearch 9.5 e, por isso, possui algumas limitações:

• No momento, funciona apenas para filtragem. Um MATCH em uma expressão ainda não contribui para a pontuação de relevância; apenas correspondências em campos indexados afetam a pontuação.

• Opções de consulta como fuzziness e outras ainda não são suportadas ao combinar uma expressão.

• O texto em tempo de execução é analisado com o analisador padrão. Isso ainda não é configurável.

Trabalhos estão em andamento para abordar essas limitações.

Por que usar a busca em texto completo em vez de LIKE ou RLIKE no ES|QL?

ES|QL já tinha duas formas de buscar strings sem índice: LIKE (padrões curinga) e RLIKE (expressões regulares). Ambos funcionam em qualquer expressão de string, então é justo perguntar o que o MATCH adiciona. A resposta é análise, uma forma mais avançada de busca que utiliza técnicas como stemming e sinônimos. Também utiliza o tratamento de stopwords.

LIKE é simples correspondência de substrings, sem qualquer compreensão das palavras que compõem uma string. Digamos, por exemplo, que você esteja procurando mensagens de log sobre uma raposa:

Isso perde "Fox avistado perto do galinheiro" devido à capitalização, ao mesmo tempo em que iguala "Outfoxed pela competição", que não tem nada a ver com uma raposa. Ele falha em ambas as direções, com falsos negativos devido à capitalização e falsos positivos em substrings contidas em outras palavras.

Expressões regulares podem corrigir o problema do caso, mas o problema da fronteira de palavras fica feio rapidamente. Algo como:

E nem isso está certo ainda. Ele deixa de encontrar "fox" no final de uma frase seguida de ! ou ?, e não considera tabulações, aspas ou parênteses. Cada correção faz o padrão mais longo, e a próxima pessoa que ler a consulta precisa fazer engenharia reversa do que ele realmente está fazendo.

MATCH faz o problema desaparecer, pois executa tanto a consulta quanto o valor por um analisador, que tokeniza texto em termos minúsculos e então faz a correspondência termo contra termo:

Essa consulta corresponderá a valores como "A rápida raposa marrom" e "FOX avistada perto do galinheiro", mas não a "Enganada pela concorrência" ou "protocolo FOXTROT ativado", independentemente de qualquer pontuação ao redor das palavras. Claro, tudo isso funciona para consultas de múltiplos termos, como MATCH(TO_TEXT(message), "brown fox"), exatamente do jeito que você esperaria.

Estão em andamento trabalhos para viabilizar o uso dos 36 analisadores de linguagem dedicados, com suporte para linguagens naturais em dados que nunca foram indexados ou mapeados.

Casos de uso de busca de texto completo para dados não indexados e não mapeados

Os exemplos acima pesquisaram valores calculados a partir de campos mapeados. Os casos de uso mais interessantes do ES|QL MATCH em expressões envolvem dados que nunca foram pesquisáveis. Vamos examinar alguns.

Como buscar campos não mapeados no ES|QL sem adicionar um mapeamento

Às vezes, você deliberadamente deixa um campo fora dos seus mapeamentos, como um rastreamento de pilha verboso ou uma carga útil da requisição bruta. Você pode até mesmo omitir um blob para depuração. Indexar um desses consumiria espaço em disco e na heap em cada documento e não valeria a pena para um campo que você pode consultar uma vez por trimestre.

Essa decisão sempre foi final, porque campos não mapeados eram totalmente invisíveis para consultas. No Elasticsearch 9.5, você pode usar SET unmapped_fields="load" para fazer o ES|QL carregar campos não mapeados diretamente do documento de origem como palavras-chave. Em seguida, envolva isso em TO_TEXT, e agora você pode executar uma busca de texto completo:

Aqui, stack_trace nunca foi mapeado. Cada valor é obtido dos documentos originais e analisado em tempo real. Eles são combinados linha por linha. Isso dá trabalho de verdade e nunca será tão rápido quanto uma pesquisa por índice invertido. Mas agora, aquele campo que você não indexou pode ser pesquisado. Você pode manter o mapeamento pequeno para o caso do dia a dia e ainda responder à pergunta uma vez por trimestre quando importa.

Busca de texto completo em um campo de palavra-chave sem reindexação

Os campos de palavras-chave podem fazer muito. Eles oferecem correspondência exata, agregações rápidas e ordenação, por isso tantos campos acabam mapeados dessa forma. Mas os mapeamentos são decididos quando os dados chegam, e é fácil acabar em uma situação em que você queira fazer algo diferente do que pretendia originalmente com seus dados. Talvez product_name tenha sido mapeado como palavra-chave porque os dashboards fazem agregações com ele e, depois de receber um ano de dados de produto, alguém queira poder buscar valores dentro de product_name.

A resposta antiga era mudar o mapeamento para texto (ou adicionar um multicampo) e reindexar tudo. Isso pode ser demorado e caro, e em muitos casos, os usuários simplesmente não vão querer se preocupar com isso. A nova resposta é uma chamada de função:

TO_TEXT converte os valores das palavras-chave em texto em tempo real, então o MATCH os analisa em vez de compará-los exatamente. Isso permite consultar um campo de palavra-chave sem criar um mapeamento ou reindexar o documento de origem. Se a busca se tornar uma consulta diária, indexar o campo como texto ainda é a melhor opção a longo prazo, mas TO_TEXT lhe dá uma resposta hoje, sem nenhum esforço extra.

Buscar no mesmo campo entre índices com mapeamentos diferentes

ES|QL pode abranger muitos índices, e o mesmo campo não precisa ser sempre igual em todos eles. Quando o mesmo campo tem tipos diferentes em índices distintos, ES|QL o trata como um tipo de união, e uma função de conversão resolve o conflito. Vamos considerar um exemplo em que o campo mensagem é do tipo texto no modelo de índice deste ano, mas era uma palavra-chave no do ano passado:

Cada valor é analisado no momento da consulta, seja do índice de texto ou do índice de palavras-chave. Os valores das palavras-chave dos índices antigos são tokenizados e em minúsculas como todo o resto, então "connection reset" encontra "Connection RESET by peer", não importa em qual índice esteja.

Outro caso interessante é quando um campo é mapeado em apenas um índice, mas também presente (e não mapeado) no outro:

Há uma nuance que vale a pena destacar aqui. Se error_details estiver mapeado em logs-2026, mas não em logs-2025, o Elasticsearch não pode enviar essa consulta para Lucene, porque os índices onde o campo não está mapeado retornariam silenciosamente nenhuma correspondência. Em vez disso, o planejador percebe que o campo pode não estar mapeado e avalia toda a MATCH linha por linha, de onde quer que as linhas tenham vindo. Você não precisa saber quais índices têm o campo mapeado; a consulta apenas responde à questão.

Como ES|QL analisa texto no momento da consulta sem um índice invertido

Quando o ES|QL planeja uma correspondência (match) contra uma expressão, ele analisa a string de consulta uma vez, no início, em um conjunto de termos. A forma como cada linha é então avaliada depende do tipo da expressão:

Tipo de expressão

Processamento

Comportamento de correspondência

texto (via TO_TEXT)

O analisador divide o valor em termos minúsculos

Comparação token-contra-token; uma linha corresponde se qualquer token for igual a qualquer termo de consulta (semântica OU)

palavra-chave, IP, data, numérico

Sem análise; constante de consulta convertida uma vez para o tipo nativo

Comparação exata por linha

Ambos os caminhos ignoram completamente o Lucene e avaliam os valores linha por linha. O caminho não textual reflete exatamente o que uma consulta match faz quando executada no Lucene para esses tipos de campo, de modo que a semântica permanece consistente independentemente de a sua consulta atingir ou não um índice.

Uma consulta de índice invertido faz seu trabalho no momento da ingestão e nunca acessa documentos que não correspondem no momento da consulta. Um match em tempo de execução faz essa análise no momento da consulta, para cada linha que a alcança. Uma é rápida porque o trabalho já aconteceu; a outra é flexível porque os dados não precisam ter sido indexados de forma alguma.

O que vem a seguir para a busca de texto completo no ES|QL

Tudo o que está neste post é a primeira parte de um esforço maior para fazer a busca no ES|QL funcionar em qualquer coisa, não apenas no que você indexou antes. As limitações mencionadas anteriormente estão sendo trabalhadas ativamente, e o roadmap vai além:

• Pontuação. Correspondências em tempo de execução contribuem para _score, então você pode ordenar por relevância mesmo quando os dados nunca foram indexados.

• MATCH_PHRASE em expressões. Já disponível no Elastic Cloud Serverless, e chegando ao Elastic Stack na versão 9.6.

• Analisadores configuráveis. Suporte a analisadores para MATCH e MATCH_PHRASE em expressões, permitindo analisadores de linguagem, derivação (stemming) e sinônimos no momento da consulta.

• Opções do MATCH. Opções como fuzziness e operador para correspondências em tempo real.

• Busca vetorial. Gerando vetores de incorporação por linha e executando k-nearest neighbors (kNN) em expressões dense_vector em tempo de execução, trazendo também a pesquisa semântica para dados não indexados.

Experimente hoje a busca de texto completo do ES|QL em expressões

Você pode experimentar a busca em tempo de execução hoje mesmo. Já está disponível no Elastic Cloud Serverless, onde as novas capacidades do ES|QL são lançadas primeiro, e ele é disponibilizado como uma prévia técnica no Elasticsearch 9.5. Comece consultando a referência das funções de pesquisa e verifique a página de limitações do ES|QL para conhecer os limites atuais. É uma prévia técnica porque queremos seu feedback: se você buscar algo que nunca foi indexado e isso o surpreender, seja positiva ou negativamente, gostaríamos muito de saber.

1. Utilizando a API _mapping para recuperar informações de campo

2. Utilizando a API _search para exibir valores de campo

3. Exibição de subcampos

4. _source sintética

5. Campos de tempo de execução

1. Utilizando a API _mapping para recuperar informações de campo

A API _mapping permite recuperar a definição de mapeamento para um índice ou vários índices. Isso inclui informações sobre os campos, seus tipos de dados e outras propriedades. Para recuperar o mapeamento de um índice específico, utilize a seguinte solicitação:

Por exemplo, se você tiver um índice chamado my_index, poderá recuperar seu mapeamento com a seguinte solicitação:

A resposta incluirá a definição de mapeamento para o índice, que contém informações sobre os campos e suas propriedades.

Também é possível recuperar o mapeamento de um campo específico. Isso pode ser útil se o seu mapeamento for muito extenso e você quiser se concentrar apenas em um campo específico. Para obter o mapeamento de um campo específico, utilize a seguinte solicitação:

Você também pode recuperar os mapeamentos de vários campos separando seus nomes por vírgulas, como na seguinte solicitação:

2. Usando a API _search para exibir valores de campo

Para exibir os valores dos campos em um índice do Elasticsearch, você pode usar a API _search . A API _search oferece várias maneiras de controlar quais campos são retornados; as duas principais são:

1. _sourceO campo _source contém o corpo original do documento JSON exatamente como foi indexado, incluindo quaisquer alterações feitas pelos pipelines de ingestão ou etapas de pré-processamento. Para exibir campos específicos do documento de origem, implemente a filtragem de origem, como veremos a seguir.

2. fieldsO parâmetro fields permite recuperar campos específicos dos seus documentos ao realizar uma pesquisa, com base no mapeamento do índice. Ao contrário de _source, fields também pode retornar valores de campos armazenados, valores de documentos ou campos de tempo de execução sem fazer referência a _source, embora para campos padrão sem valores de documentos ou configurações armazenadas, ele recorra a _source. Isso pode trazer muitos benefícios, como melhoria de desempenho e outros, como veremos a seguir.

Usando o campo _source

Por padrão, a API _search retorna o campo _source , que contém o documento JSON original que foi indexado. Para exibir campos específicos, você pode adicionar filtros no parâmetro _source da solicitação de pesquisa; isso é chamado de filtragem de origem.

Aqui está um exemplo de uma solicitação de pesquisa que retorna os valores dos campos title e author para documentos no índice my_index :

Neste exemplo, o parâmetro _source especifica os campos a serem retornados.

Se você precisar de ainda mais controle, pode usar as propriedades includes e excludes do objeto _source . Por exemplo, a consulta abaixo retorna o campo de nível superior title e todos os subcampos de author exceto author.description.

Neste exemplo, usamos o padrão author.* para recuperar todos os subcampos diretos do objeto author . Então excluímos explicitamente author.description para que apenas os outros campos de autor sejam retornados. Note que isso não traz nenhuma melhoria de desempenho, já que ainda precisa carregar e analisar o JSON de origem, mas pode reduzir o tamanho da resposta enviada pela rede.

Usando o parâmetro de campos

Você pode usar o parâmetro fields para filtrar os campos retornados na resposta da pesquisa. O uso de fields em vez de _source oferece diversas vantagens, incluindo:

• Desempenho aprimorado: fields pode retornar valores diretamente de campos armazenados ou valores de documentos sem ter que carregar o _source completo, tornando o tamanho da carga útil da resposta menor.

• Saída formatada: Para campos padrão, fields pode recorrer a _source para obter os valores, mas ele analisa o mapeamento do índice para formatar corretamente a saída, como datas formatadas, tornando-as consistentes com o que é usado para agregações e classificação.

• Acesso a campos de tempo de execução: fields pode retornar campos de tempo de execução, que não existem no _source original.

• Você pode encontrar mais benefícios aqui.

Por exemplo, para retornar apenas os campos title e author no índice my_index , você pode usar a seguinte solicitação de pesquisa:

Na consulta acima, definimos o campo _source como falso para não retornarmos o documento de origem. Isso pode minimizar drasticamente o tamanho da carga útil da resposta, mas lembre-se de que isso só funciona porque os campos title e author são do tipo de campo keyword , que têm doc_values habilitado por padrão. Se o campo não tiver doc_values habilitado e _source estiver definido como falso, o Elasticsearch não terá como recuperá-los e eles serão ignorados na resposta.

É importante notar que a resposta fields sempre retorna uma matriz de valores para cada campo, mesmo que haja apenas um único valor. Isso ocorre porque o Elasticsearch não possui um tipo de array dedicado, e qualquer campo pode ter vários valores. Para obter mais informações sobre arrays no Elasticsearch, clique aqui.

Outras formas de recuperar campos

Embora a recuperação de campos usando _source ou fields sejam os métodos recomendados, existem outros métodos disponíveis para casos de uso específicos, como:

Campos de valor do documento: Se você quiser evitar _source completamente, você pode pesquisar usando o parâmetro docvalue_fields . Os valores do documento armazenam os mesmos valores de campo que _source , mas em uma estrutura de dados em disco, otimizada para classificação e agregações.

Como é separado dos valores armazenados com _source, você pode solicitar campos específicos sem carregar todo o _source. Isso é útil se você estiver consultando documentos grandes, mas precisar apenas de alguns campos pequenos que suportem valores do tipo "doc". Outro caso de uso para usar docvalue_fields é quando você deseja usar formatação personalizada nos campos date e numeric , como veremos no exemplo abaixo.

Observe que isso só funciona para campos que você habilita doc_values ou para tipos de campo que o têm habilitado por padrão, como keyword, date, tipos numéricos e boolean, não para text ou annotated_text.

Neste exemplo, usamos o parâmetro docvalue_fields para recuperar os campos title, author e published sem carregar o documento _source completo:

Quando esta consulta é executada, o Elasticsearch obtém os valores diretamente de seu armazenamento colunar em disco, em vez de referenciar o _source para cada documento. O campo published é retornado com o formato epoch_millis em vez do formato padrão, graças ao parâmetro format fornecido na consulta.

Campos armazenados: Se você marcou explicitamente campos específicos como armazenados no mapeamento, você pode usar o parâmetro stored_fields para filtrar esses campos. Isso é útil se você deseja respostas resumidas apenas com esses campos específicos ou para campos que você armazenou deliberadamente para recuperação posterior. É armazenado separadamente de _source, portanto, este método também é útil para evitar a necessidade de carregar _source.

É importante notar que esta opção está desativada por padrão e geralmente não é recomendada. Em vez disso, utilize a filtragem de origem para retornar determinados subconjuntos do documento de origem original.

Na consulta de exemplo abaixo, usamos o parâmetro stored_fields para recuperar o campo summary , que tem a configuração de mapeamento de índice de ”store”: true.

Quando esta consulta é executada, o Elasticsearch verifica se este campo foi marcado com ”store”: true, se não o encontrar, irá ignorar o campo completamente.

3. Exibição de subcampos

Se o seu índice contiver subcampos, você pode usar a notação de ponto para especificar o caminho do campo no parâmetro fields . Note que os subcampos são diferentes do tipo de campo aninhado. Por exemplo, se você tiver um subcampo chamado address.city, poderá incluí-lo na resposta da pesquisa desta forma:

Neste exemplo, a resposta da pesquisa incluirá os valores dos campos title, author e address.city .

4. Fonte sintética

Se você quiser manter a funcionalidade de usar _source , mas também economizar espaço em disco, você tem a opção de usar _source sintético em seu mapeamento de índice. _source sintético é um recurso que permite ao Elasticsearch reconstruir o _source a partir de dados existentes, como campos armazenados e valores de documentos, mesmo quando _source está desativado. Isso permite economizar bastante espaço de armazenamento, ao custo de velocidades ligeiramente menores no momento da consulta, já que a reconstrução ocorre em tempo real. Ative este recurso usando os valores abaixo nas configurações do seu índice:

Algumas vantagens de usar _source sintético incluem: exibição do documento completo ao usar a API _search , filtragem de origem e compatibilidade com outros recursos e ferramentas como o Kibana que esperam que _source esteja disponível, tudo isso evitando a necessidade de armazenar o documento _source completo.

5. Campos de tempo de execução

Os campos de tempo de execução permitem definir campos com script no momento da consulta ou no mapeamento do índice, dentro de um bloco de tempo de execução. Esses campos nunca são indexados, portanto, adicionar um campo de tempo de execução não aumenta o tamanho do índice, mas nunca aparecerá em _source. Os campos de tempo de execução definidos no mapeamento são persistentes e estão disponíveis para todas as consultas, enquanto os campos de tempo de execução definidos no momento da consulta são temporários e estão disponíveis apenas nessa solicitação de pesquisa.

A principal vantagem de usar campos em tempo de execução é a capacidade de adicionar campos aos documentos depois de já os ter importado, simplificando as decisões de mapeamento. Os campos de tempo de execução também são ótimos para enriquecer seus documentos com valores que não existem no documento original, mas são gerados por meio de um script, como formatar uma string ou calcular uma pontuação.

Vale ressaltar também que os campos de tempo de execução podem prejudicar o desempenho, pois será necessário executar um script para cada documento no conjunto de resultados. Para recuperar um campo de tempo de execução, você também pode usar o parâmetro fields na API _search .

Conclusão

A exibição de campos de um índice Elasticsearch pode variar desde a simples recuperação de valores usando o mapeamento de índice ou o _source, até métodos mais avançados usando fields, docvalue_fields ou campos de tempo de execução para maior controle e eficiência. Compreender as vantagens e desvantagens de diferentes métodos é fundamental para otimizar suas experiências de busca. Seja para otimizar payloads, enriquecer documentos ou usar dados sintéticos _source para economizar armazenamento, o Elasticsearch oferece diversas ferramentas e recursos para encontrar os dados que você precisa, da maneira que você precisa. Essas técnicas podem ajudá-lo a entender a estrutura de seus dados, identificar campos específicos e solucionar problemas.

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

Tipo de vetor denso

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

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

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

Quando e por que usar o tipo dense_vector?

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

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

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

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

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

Como usar a consulta para o tipo vetor denso?

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

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

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

Tipo de vetor esparso

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

Quando e por que usar vetores esparsos?

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

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

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

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

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

Como usar a consulta para o tipo vetor esparso?

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

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

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

Tipo de texto semântico

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

Quando e por que usar texto semântico?

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

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

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

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

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

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

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

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

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

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

Conclusão

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

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

Referências

• Tipo de campo de texto semântico

• Tipo de campo vetorial esparso

• Tipo de campo vetorial denso

• Consulta semântica

• Consulta de vetor esparso

• pesquisa kNN

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

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