Como funciona a busca semântica: embeddings e busca híbrida
guides

Como funciona a busca semântica: embeddings e busca híbrida

Como funciona a busca semântica em 2026: embeddings, vetores e busca híbrida em linguagem simples, e por que a palavra-chave continua perdendo seus favoritos.

SavedThat team14 min de leitura

Você digita «quanto custa adquirir clientes» na busca dos seus favoritos e nada aparece. O vídeo que você procura está na sua biblioteca, você mesmo o salvou. O palestrante disse «CAC» dezesseis vezes. Sua busca dizia «custo de aquisição de cliente». As palavras não coincidem, e a busca não encontra nada.

Essa falha tem nome: o problema da divergência de vocabulário. É por isso que a busca por palavra-chave continua perdendo, e é por isso que a busca semântica virou o padrão em toda ferramenta séria que busca em qualquer coisa que seja texto. A seguir: como a busca semântica realmente funciona em 2026, em linguagem simples e sem exigir pós-graduação em matemática, e por que a maioria dos apps de consumo que anuncia «busca com IA» ainda erra.

O problema da divergência de vocabulário em 60 segundos

Os sistemas de busca antigos comparavam sequências de texto literais. Você digitava custo de aquisição de cliente e o sistema encontrava documentos com essas palavras exatas. Documentos que diziam «CAC», «o custo de trazer compradores novos» ou «o que pagamos por inscrição» ficavam invisíveis.

A área de recuperação de informação mede isso há quarenta anos. A divergência típica de vocabulário fica em torno de 70-80%: na maior parte do tempo, as pessoas usam palavras diferentes para o mesmo conceito. Se a sua busca só compara texto literal, você perde quatro de cada cinco documentos relevantes. É um jeito educado de dizer que «a busca por palavra-chave não funciona desde 1985».

Duas coisas resolveram isso. A primeira são os embeddings: uma forma de representar significado como números, para que duas frases que querem dizer a mesma coisa fiquem «próximas» mesmo sem compartilhar palavras. A segunda são os bancos de dados vetoriais: armazenamento e índices capazes de encontrar rapidamente os vetores mais próximos, mesmo quando o acervo tem milhões de documentos.

Juntas, elas são o que torna a «busca semântica» possível.

O que é um embedding, em termos simples

Pegue uma frase e passe-a por uma rede neural. A rede devolve uma lista de números, normalmente 384, 768 ou 1.536. Essa lista é o embedding da frase.

O truque é que a rede é treinada para que frases com significados parecidos produzam listas parecidas. Um exemplo concreto:

Os embeddings A e B vão ficar próximos no espaço de 1.536 dimensões em que existem. C vai ficar longe. A proximidade é medida pela similaridade de cosseno, ou seja, o quanto os dois vetores estão alinhados nesse espaço de alta dimensão. Valores perto de 1,0 indicam significado quase idêntico; perto de 0, nenhuma relação.

Dá para imaginar cada frase como um ponto numa galáxia de 1.536 dimensões, em que a direção representa o significado. As coordenadas em si não querem dizer nada; o que importa é quais frases ficam perto de quais.

O modelo que faz isso

Vários modelos são competitivos em 2026. O text-embedding-3-small da OpenAI gera 1.536 dimensões nativamente e suporta Matryoshka representation (dá para truncar para 768 ou 256 dimensões e economizar armazenamento sem treinar de novo). O embed-v3 da Cohere é competitivo com conteúdo multilíngue. Alternativas de código aberto como bge-large e nomic-embed-text ficam a poucos pontos de precisão e rodam num Mac.

Para uso multilíngue, com consultas em qualquer idioma (no SavedThat, os vídeos salvos pelos usuários somam 24 idiomas em 30 de setembro de 2026), o text-embedding-3-small é hoje o melhor equilíbrio entre precisão, custo e dimensões. No SavedThat usamos a versão truncada de 768 dimensões: metade do armazenamento, cerca de 99% da qualidade de busca. (Mais sobre Matryoshka representation.)

Por que «é só usar IA» não é a mesma coisa que busca semântica

Muitos apps de consumo anunciam «busca com IA» em 2026. Quase sempre isso quer dizer uma de três coisas:

  1. Busca semântica de verdade: embeddings mais recuperação vetorial, como descrito acima.
  2. Um LLM por cima de uma busca por palavra-chave: o sistema faz a busca por palavra-chave, pega os resultados e pede a um LLM que os reformule ou resuma. A recuperação continua limitada às palavras-chave; o LLM só disfarça as falhas.
  3. Perguntas e respostas só com o LLM: você pergunta, o LLM responde com base no treinamento geral, e o seu conteúdo salvo nem é consultado.

Só a primeira resolve de fato a divergência de vocabulário nos seus dados. As outras duas viram recurso de produto, mas não ajudam a achar o que você salvou.

Um diagnóstico rápido: se você busca pelo conceito e não encontra o documento, mas o encontra buscando uma das palavras exatas dele, a ferramenta está fazendo o item 2 ou o 3 com o rótulo de «busca com IA». Se você encontra o documento por uma paráfrase, é o item 1.

Bancos de dados vetoriais: guardar e encontrar embeddings rapidamente

Os embeddings sozinhos não ajudam se for preciso comparar cada consulta com milhões de vetores, um por um. Uma busca completa num índice de 50.000 documentos leva centenas de milissegundos com o método ingênuo, lento demais para uso interativo.

A solução é a indexação por vizinhos mais próximos aproximados (ANN, approximate nearest neighbour). Estruturas de dados especializadas, como HNSW (Hierarchical Navigable Small World), IVF e ScaNN, organizam os vetores para que os mais próximos sejam encontrados em menos de 10 milissegundos, mesmo em bibliotecas com dezenas de milhões de vetores.

O estado da arte atual (maio de 2026) para busca semântica em produção:

Na escala do SavedThat (o índice inteiro tinha cerca de 230 mil trechos de transcrição em 30 de setembro de 2026), o índice ainda cabe na memória RAM.

O porém: a busca semântica sozinha erra em frases exatas

Agora vem o detalhe que a maioria dos tutoriais ignora: em frases exatas, a busca semântica perde para a busca por palavra-chave.

Se você busca "text-embedding-3-small" (um nome de produto exato), a busca por palavra-chave devolve em primeiro lugar o documento que menciona exatamente esse texto. A busca semântica pode dar posição melhor a um documento sobre «embeddings da OpenAI em geral», porque ele está semanticamente mais próximo do sentido médio da consulta, mesmo sem conter o texto literal.

Isso acontece de verdade. Benchmarks públicos mostram de forma consistente que a busca semântica pura tem desempenho pior que a busca por palavra-chave em consultas muito específicas: nomes de produto, assinaturas de função, citações exatas, datas, nomes de marca. O problema que a busca semântica deveria resolver (a divergência de vocabulário) não existe nessas consultas, porque o usuário digitou exatamente o texto que queria.

A solução é rodar as duas buscas e combinar os resultados.

Busca híbrida com Reciprocal Rank Fusion

A busca híbrida é a técnica que, sem alarde, virou o padrão nos sistemas de busca sérios em produção desde 2024:

  1. Faça uma busca semântica (similaridade vetorial) e pegue os K primeiros ordenados por cosseno.
  2. Faça uma busca de texto completo (palavra-chave, tsvector, BM25, o que for) e pegue os K primeiros ordenados pela pontuação de relevância.
  3. Combine as duas listas com o reciprocal rank fusion (RRF): a pontuação RRF de cada documento é 1 / (rank + 60), somada entre os dois métodos. Documentos bem posicionados nas duas listas ganham um reforço significativo; documentos que aparecem em só uma delas ainda contam.
  4. Ordene pela pontuação RRF combinada.

A constante 60 é um número mágico testado à exaustão e que funciona na maioria dos acervos. Dá para ajustá-la, mas em geral não é preciso.

O resultado: consultas parafraseadas continuam encontrando o conceito (pelo lado semântico), e consultas com a frase exata continuam colocando a correspondência literal em primeiro lugar (pelo lado das palavras-chave). O ponto cego de cada método é coberto pelo outro.

É assim que funciona a busca padrão do SavedThat. A função RPC search_chunks no nosso Postgres roda as duas consultas em paralelo, calcula as pontuações RRF e devolve os resultados ordenados. De ponta a ponta, incluindo a chamada que gera o embedding da consulta, a busca levou em mediana cerca de 1,3 segundo em setembro de 2026. (Microsoft sobre busca híbrida)

Um nível acima: reordenação

Em casos de alto valor, como e-discovery jurídico, literatura médica e busca corporativa em milhões de documentos, o RRF híbrido costuma ser a penúltima camada. A última é a reordenação com um modelo cross-encoder.

Um cross-encoder é um modelo menor e mais lento que recebe a consulta completa e o documento candidato completo e calcula uma pontuação de relevância mais precisa, analisando os dois juntos. Não dá para rodá-lo em um milhão de documentos (seria lento demais); ele roda nos 50 a 200 primeiros resultados da busca híbrida para reordená-los com precisão.

A Cohere oferece o rerank-v3 para isso. Alternativas de código aberto: bge-reranker-large e jina-reranker-v2. Para uso na escala de consumo, como o SavedThat, o ganho marginal não justifica os 100 ms a mais de latência. Na busca corporativa de e-discovery jurídico, a reordenação com cross-encoder é padrão.

Vamos adicioná-la quando nosso acervo ou nosso caso de uso exigir. Antes disso, não.

Quanto custa

O processo inteiro custa mais ou menos isto:

EtapaCusto
Embeddings de 1.000 trechos (~50 vídeos)~0,02 $ em créditos da OpenAI
Armazenar 1 milhão de trechos no pgvector~25 $/mês numa instância pequena de Postgres
Construir o índice HNSW para 1 milhão de trechos~30 segundos, uma vez a cada grande mudança nos dados
Uma consulta de busca (embedding + consulta HNSW + busca de texto completo + RRF)~0,0001 $, cerca de 1,3 s no total

Com os preços do SavedThat, uma assinatura Pro (9,99 $/mês) cobre milhares de buscas e várias centenas de novos salvos. A conta fecha na escala de consumo; o que não dá é bancar isso com um plano gratuito e ilimitado para sempre, porque a conta da OpenAI cresce na mesma proporção que o conteúdo, enquanto a receita fica travada em zero.

Por que a maioria das ferramentas de «segundo cérebro» não oferece isso

Três motivos:

  1. Complexidade de engenharia. A busca híbrida com RRF exige rodar dois sistemas de recuperação e combiná-los. A maioria das equipes implementa só um, e em geral é a busca por palavra-chave, porque é mais antiga e as ferramentas são maduras.
  2. Custo de armazenamento. Embeddings de 1.536 dimensões × 4 bytes por dimensão = ~6 KB por trecho. Uma biblioteca de 100.000 trechos ocupa 600 MB de armazenamento vetorial, além do texto original. Sem halfvec e MRL, a conta dobra.
  3. Inércia. A maioria das ferramentas de notas existentes foi lançada antes de os embeddings de frases se tornarem baratos e comuns. Adaptar busca semântica ao Evernote ou ao Pocket exigiria um projeto de banco vetorial que essas empresas nunca priorizaram.

As ferramentas que oferecem busca semântica desde o primeiro dia (Mem, Reflect, o plano premium do Glasp, SavedThat) foram quase todas criadas depois de 2022, porque foi quando o custo dos embeddings caiu abaixo do ponto em que dá para cobrar por eles de forma sustentável na escala de consumo.

O que isso significa na prática

Ao avaliar uma ferramenta para buscar dentro de alguma coisa em 2026, pergunte:

Para salvar vídeos e encontrá-los depois: o SavedThat cumpre os quatro pontos (visão geral da arquitetura aqui). O Glasp oferece só palavra-chave (grátis) e semântica (pago). O Mem oferece semântica sem busca híbrida. A «busca com IA» do Notion é o item 2: um LLM por cima de palavras-chave.

Esse é o panorama em maio de 2026.

Continue lendo

Perguntas frequentes (2026)

Qual a diferença entre um embedding e um vetor?

Na prática, nenhuma: os termos são usados como sinônimos. A rigor, um embedding é a *representação* que um modelo produz, e um vetor é só uma lista de números. Todo embedding é um vetor, mas nem todo vetor é um embedding (uma coluna de intensidades de pixels é um vetor, mas não um embedding). A maioria dos artigos científicos e da documentação técnica usa «vetor» para falar de armazenamento e «embedding» para falar do conceito.

A busca semântica funciona em qualquer idioma?

Depende do modelo de embedding. O text-embedding-3-small da OpenAI foi treinado em mais de 100 idiomas e produz vetores aproximadamente alinhados entre eles: uma consulta em russo e um documento em inglês sobre o mesmo conceito caem em regiões parecidas do espaço vetorial. Modelos de código aberto menores costumam piorar bastante fora do inglês. Se o uso multilíngue é um requisito, confira se a documentação do modelo menciona explicitamente o alinhamento entre idiomas.

Qual a diferença entre a busca híbrida e rodar duas buscas e mostrar as duas?

Rodar duas buscas e juntar os resultados só dá o dobro de resultados. A busca híbrida os combina pela pontuação (RRF ou fusão ponderada), para que a ordem final reflita o quanto os dois métodos concordam. Um documento em primeiro lugar na busca por palavra-chave e em primeiro na semântica fica em primeiro no geral; um documento em primeiro na palavra-chave, mas em 50º na semântica, fica no meio. Sem essa combinação, você não sabe em quais resultados confiar.

Por que a busca semântica pura perde para a palavra-chave em frases exatas?

Embeddings codificam significado, não texto literal. Uma consulta como «text-embedding-3-small» tem seu significado mais em «membro da família de embeddings da OpenAI» do que na sequência literal de tokens. O vetor da consulta fica parecido com os vetores de documentos que falam dos embeddings da OpenAI em geral, e eles podem ficar à frente do documento específico que menciona o nome exato. A busca por palavra-chave não tem ambiguidade nenhuma com texto exato: ou ele aparece, ou não. A busca híbrida cobre os dois casos.

RAG é a mesma coisa que busca semântica?

São coisas relacionadas, mas não iguais. A busca semântica é a etapa de recuperação: encontrar documentos próximos de uma consulta no espaço vetorial. RAG (Retrieval-Augmented Generation) é um sistema que usa a busca semântica para encontrar documentos e depois os entrega a um LLM generativo, que escreve uma resposta usando esses documentos como contexto. O RAG inclui a busca semântica como um componente; dá para ter busca semântica sem RAG (quando você só quer encontrar os documentos, sem gerar texto a partir deles).

Preciso de GPU para rodar busca semântica?

Para a consulta, ou seja, buscar num índice já construído, não. Uma CPU dá conta da recuperação na escala de consumo. Para construir o índice, ou seja, rodar o modelo de embedding no seu conteúdo, uma GPU acelera, mas não é obrigatória. A API da OpenAI gera os embeddings nos servidores dela e devolve o vetor para você armazenar; do seu lado ficam só o banco vetorial e o embedding da consulta (uma chamada curta à API por consulta). O custo é de centavos por mil buscas.