Elasticsearch 8.11 lança o ELSER em GA: busca semântica sem treinar seu próprio modelo

Uma história familiar: o usuário digita na busca «how to cancel subscription», enquanto na sua documentação o artigo se chama «Terminating your plan». O BM25 clássico não vai encontrar esse artigo: não há palavras em comum. É exatamente esse problema que a Elastic resolve com o modelo ELSER (Learned Sparse EncodeR), que na versão 8.11 recebeu o status GA. Ele já pode ir para produção, e não apenas ser testado em ambiente de laboratório.

Em que o ELSER se diferencia dos embeddings tradicionais

A busca semântica comum é construída sobre vetores densos. Você pega um modelo externo de embeddings, passa todos os documentos por ele, armazena centenas de números para cada trecho e busca os vizinhos mais próximos. Isso funciona, mas traz consigo infraestrutura: um serviço à parte, questões de versões do modelo e a escolha de um modelo para o domínio.

O ELSER é concebido de outra forma. Ele transforma o texto em um vetor esparso, ou seja, um conjunto de palavras com pesos. Nesse conjunto entram também palavras que não estão no texto, mas que têm relação de sentido com ele. Um documento sobre «terminating your plan» receberá no índice também um peso para «cancel», «subscription» e termos semelhantes. Depois disso, entra em ação a mecânica habitual do índice invertido, com a qual a equipe do Elasticsearch já está acostumada.

Como isso fica na prática

O esquema é simples. Na indexação, os documentos passam por um ingest pipeline com um processador inference, e o modelo adiciona a cada um deles uma representação esparsa. Na busca, usa-se uma consulta text_expansion com o identificador do modelo. A consulta também é expandida para termos ponderados e comparada com os indexados.

A principal comodidade é que o modelo é treinado previamente e deve entregar qualidade aceitável no seu corpus sem retreinamento. Para uma equipe sem engenheiro de ML dedicado, é uma economia notável: não é preciso montar um dataset rotulado nem subir um treinamento. O modelo roda nos nós de ML do próprio cluster, e os dados não saem para uma API externa.

Na mesma versão, a Elastic ampliou o conjunto de conectores que puxam dados de sistemas externos, como repositórios corporativos de documentos e bases de conhecimento. A lista exata é melhor consultar nas release notes, mas a direção é clara: ficou mais fácil carregar seus dados em um índice e obter de imediato busca semântica sobre eles. Para cenários de RAG, é exatamente a combinação de que se precisa.

Limitações que vale conhecer

Primeira: o ELSER é voltado ao inglês. Se o seu conteúdo é em russo ou multilíngue, não convém esperar a mesma qualidade, e será preciso olhar outros modelos ou vetores densos.

Segunda: o recurso faz parte dos níveis pagos de assinatura. Para testar hipóteses basta o período de avaliação, mas é preciso prever isso no orçamento do projeto.

Terceira: as representações esparsas incham o índice, e a inferência durante a indexação exige recursos dos nós de ML. Para coleções grandes, estime com antecedência a carga e o tempo da indexação inicial.

E quarta: GA significa estabilidade da interface, e não garantia de qualidade no seu domínio. A relevância você ainda terá de medir por conta própria.

O que fazer com isso

Se você já tem Elasticsearch com conteúdo em inglês e reclamações de que «a busca não entende o que eu quero dizer», esta é a forma mais barata de testar a semântica. Não é preciso introduzir um novo banco de dados vetorial nem mudar a stack.

O plano prático é este: pegue de 50 a 100 consultas reais em que o BM25 falha, passe-as pelo ELSER e compare os resultados. Depois experimente o modo híbrido, em que a busca lexical e a semântica são combinadas em um único resultado. Em geral, é a combinação, e não a substituição de uma pela outra, que dá o melhor resultado. Se o ganho for visível, passe para o pipeline em produção; se não, você gastou um dia, e não um trimestre.