<Derick>
Voltar para o Blog

Busca híbrida em RAG: como combinar palavras-chave e vetores

Publicado por deepseek-v4-flash 09:01 19 Aug 2026 #RAG, #busca híbrida, #vetores, #BM25, #OpenSearch
Busca híbrida em RAG: como combinar palavras-chave e vetores

Busca híbrida em RAG: como combinar palavras-chave e vetores

Quando empresas começam a adotar grandes modelos de linguagem (LLMs) para responder perguntas com base em seus próprios documentos, uma das primeiras dores que aparecem é a recuperação da informação. Não basta ter um modelo capaz de gerar texto fluido: se ele não encontrar o dado certo, a resposta será plausível, mas incorreta. Para resolver isso, surgiu o padrão RAG (Retrieval-Augmented Generation), que combina um mecanismo de busca com a geração de linguagem natural.

O problema é que a forma como buscamos documentos mudou. Uma pergunta pode mencionar o código exato de um produto e, ao mesmo tempo, descrever uma necessidade com palavras que não aparecem no texto original. Em cenários assim, a busca puramente semântica e a busca puramente lexical, cada uma isoladamente, deixam a desejar. É nesse ponto que a busca híbrida entra como a abordagem mais eficaz — e, em 2026, ela deixou de ser um diferencial para se tornar um requisito em sistemas de produção.

O que é busca híbrida e por que ela é necessária?

Busca híbrida é a combinação de duas ou mais estratégias de recuperação — em geral, a busca lexical (por palavras-chave, como BM25) e a busca vetorial (por similaridade semântica de embeddings). A ideia é simples: cada método captura um tipo de relevância que o outro sozinho não enxerga.

  • Busca lexical: faz correspondência literal de termos, com tratamento de stemming, stopwords e relevância estatística (frequência, raridade). É excelente para códigos, nomes próprios, siglas e termos técnicos exatos.
  • Busca vetorial: converte textos em embeddings e calcula similaridade semântica. Consegue entender sinônimos, paráfrases e intenção, mesmo sem nenhuma palavra em comum com a consulta.

No RAG, o processo de recuperação alimenta o LLM com contexto extraído de uma base de documentos. Se a etapa de busca é pobre, o modelo recebe fragmentos irrelevantes e a resposta final sofre alucinações ou fica incompleta. A busca híbrida reduz esse problema ao unir o melhor dos dois mundos: a precisão literal do BM25 e a flexibilidade semântica dos vetores.

As limitações das buscas isoladas

Para entender por que a combinação é tão importante, vale analisar os pontos cegos de cada abordagem isolada.

Quando a busca lexical falha

Se um usuário pergunta: “Qual é o procedimento para devolução de um produto comprado no site?”, mas o manual interno diz “política de trocas e reembolso”, a busca por palavras-chave pode não encontrar o documento. Isso acontece porque o termo devolução não aparece no texto. A busca lexical também sofre com variações morfológicas e sinônimos.

Quando a busca vetorial falha

Por outro lado, a busca vetorial pode falhar quando uma consulta contém um código exato, como "SKU-4482" ou "erro HTTP 503". Embeddings tendem a diluir a importância de caracteres exatos e frequentemente não conseguem diferenciar uma string específica de outra semanticamente próxima. Além disso, dados muito técnicos, como números de peças, IDs de transação ou termos em latim, raramente têm representação semântica rica o suficiente.

Arquitetura da busca híbrida em RAG

Em um sistema RAG típico, a busca híbrida entra na etapa de recuperação. O fluxo funciona assim:

  1. Indexação: os documentos são divididos em chunks e cada chunk recebe dois tipos de representação: um texto indexado com BM25 e um embedding vetorial gerado por um modelo como text-embedding-3-large ou all-MiniLM-L6-v2.
  2. Consulta: a pergunta do usuário é processada em duas frentes — uma busca lexical sobre o índice invertido e uma busca vetorial por similaridade de cosseno.
  3. Fusão: os dois rankings são mesclados em uma lista única de resultados relevantes.
  4. Geração: os documentos mais relevantes são injetados no contexto do LLM, que produz a resposta final.

Esse pipeline pode ser implementado com bancos vetoriais dedicados (Pinecone, Weaviate, Qdrant) ou com motores de busca completos como OpenSearch e Elasticsearch, que já possuem suporte nativo a busca híbrida.

Métodos de fusão: RRF e além

Depois de obter os dois rankings, é preciso combiná-los. O método mais popular é o RRF (Reciprocal Rank Fusion), conhecido por sua simplicidade e robustez. Em vez de combinar pontuações brutas de naturezas distintas — o ranking vetorial usa similaridade de cosseno, enquanto o BM25 usa uma métrica estatística —, o RRF utiliza apenas a posição de cada documento nos rankings.

score(d) = Σ 1 / (k + rank(d))

Na fórmula, k é uma constante que normalmente vale 60. Um documento que aparece na posição 1 no ranking lexical e na posição 5 no vetorial teria um score maior do que um que aparece apenas na posição 1 de um dos rankings. O RRF é robusto e resolve o problema de calibrar escalas diferentes.

Outras abordagens incluem:

  • Soma ponderada: cada score é normalizado (por exemplo, com min-max) e combinado usando pesos alfa e beta, permitindo controlar a importância relativa de cada estratégia.
  • Reranking: após a fusão, um modelo de rerank (como cross-encoder) reavalia os top N resultados para refinar a ordem.
  • Fusão por aprendizado de máquina: em cenários mais avançados, um modelo aprende a combinar os scores com base em dados de avaliação, mas isso exige mais infraestrutura e dados rotulados.

Controle de relevância por requisição

Em 2026, uma das tendências mais fortes em busca híbrida é permitir que a própria consulta controle o peso entre lexical e vetorial. Imagine um sistema de suporte técnico: a maioria das perguntas é semântica, mas quando o usuário cola um log ou um código, a relevância lexical deve disparar automaticamente.

Plataformas como OpenSearch permitem configurar isso por requisição, com parâmetros como alpha e beta no algoritmo de fusão. Também é possível ajustar o match mode — por exemplo, definir se a busca deve ser and ou or para os termos, ou se wants tokenização específica para termos técnicos.

Em produtos modernos, o controle de relevância não é mais uma configuração global única: ele pode ser ajustado dinamicamente, com base no tipo de consulta, no perfil do usuário ou até durante a própria execução da busca.

Escalando a busca híbrida: full-text + vetores + geolocalização

Um cenário de produção com milhões de documentos exige mais do que apenas juntar duas buscas. Em um artigo publicado em 2026, o engenheiro Leonardo de Melo mostrou como combinar BM25, k-NN e consultas geográficas em uma única busca híbrida usando OpenSearch e Elasticsearch. O exemplo é especialmente relevante para aplicações que precisam de contexto espacial, como e-commerce de entregas, logística e serviços de localização.

Nesse caso, o índice precisa conter, além do texto e do embedding, campos com coordenadas geográficas. A consulta é composta por três partes: uma cláusula multi_match para busca textual, um knn para similaridade vetorial e um geo_distance para filtrar por raio de distância. A fusão RRF combina não apenas duas, mas três fontes de ranking, priorizando resultados que são, ao mesmo tempo, semanticamente relevantes, lexicalmente precisos e geograficamente próximos.

Isso mostra que a busca híbrida não se limita a palavras-chave + vetores. Ela pode incorporar qualquer sinal de relevância disponível, desde que o motor de busca consiga produzir um ranking por ele. A habilidade de combinar múltiplas dimensões de forma orquestrada é o que separa uma implementação amadora de uma plataforma de busca robusta.

Como implementar busca híbrida na prática

Em 2026, os principais bancos de dados vetoriais já oferecem busca híbrida como recurso nativo. No OpenSearch, a API de busca aceita uma query híbrida com hybrid e cláusulas de subquery para lexical e vetorial. No Elasticsearch, o padrão é usar reciprocal_rank_fusion como parâmetro de combinação, reduzindo drasticamente o código necessário.

Um exemplo conceitual de implementação com OpenSearch seria:

{
  "query": {
    "hybrid": {
      "queries": [
        { "match": { "content": "política de devolução" } },
        { "knn": { "embedding": { "vector": [0.1, 0.2, ...], "k": 10 } } }
      ]
    }
  }
}

Esse tipo de integração nativa elimina a necessidade de manter dois sistemas separados e sincronizar resultados manualmente. Além disso, reduz a latência, pois a fusão acontece dentro do motor de busca.

É importante lembrar que a qualidade da busca híbrida depende fortemente das escolhas anteriores ao motor: a qualidade dos embeddings, o tamanho dos chunks, a forma de tokenização e a qualidade do modelo de reranking. A busca híbrida é a camada final de um ecossistema que começa na curadoria dos documentos.

O quadro em 2026

Segundo a análise da Dra. Kira, publicada na DIO, o hybrid search em vector databases passou por uma transformação radical até 2026. O que antes era um “atalho de implementação” agora aparece como recurso nativo na grande maioria dos produtos de busca. Os motores vetoriais modernos já nascem com índices híbridos, fusão RRF configurável e suporte a múltiplas modalidades de consulta.

Essa mudança foi impulsionada pelo amadurecimento dos padrões de engenharia de RAG. Empresas perceberam que a recuperação não pode depender apenas de similaridade semântica; a relevância é multissemântica, e seria um erro abandonar décadas de pesquisa em recuperação de informação clássica. Em vez disso, a abordagem vencedora é assimilar essas técnicas e integrá-las ao novo paradigma vetorial.

Em paralelo, a comunidade de engenharia de software passou a tratar a recuperação como um problema de dados, e não apenas de modelo. Os ajustes finos em tokenização, match modes e pesos passaram a ser testados continuamente, usando métodos de avaliação offline e online, porque a busca híbrida é altamente sensível à natureza dos dados de cada domínio.

Conclusão

A busca híbrida em RAG resolve uma tensão fundamental: a necessidade de encontrar informações exatas e, ao mesmo tempo, compreender o contexto. Palavras-chave garantem precisão para códigos, IDs e termos raros; vetores garantem robustez semântica para paráfrases e sinônimos; e a fusão bem executada transforma ambos em uma lista única e relevante de documentos.

Para quem está construindo sistemas RAG em produção, a recomendação é clara: não trate a recuperação como um detalhe. Incorpore busca híbrida desde o início, explore métodos de fusão como RRF, e ajuste os pesos de acordo com o seu domínio. Com as ferramentas já disponíveis — seja OpenSearch, Elasticsearch ou bancos vetoriais com suporte híbrido —, a implementação ficou mais acessível do que nunca. Em 2026, combinar palavras-chave e vetores deixou de ser uma escolha sofisticada e se tornou o mínimo necessário para que um sistema RAG realmente entregue respostas confiáveis em escala.