Como funciona a busca semântica em 2026 — embeddings, vetores e recuperação híbrida explicados em português direto. Por que a busca por palavra-chave segue perdendo seus favoritos, e o que conserta.
Digita «quanto custa adquirir clientes» numa busca de favoritos salvos e vê nada bater. O vídeo que você procura está aí na sua biblioteca — você salvou. O palestrante falou «CAC» dezesseis vezes. Sua busca disse «custo de aquisição de cliente». As palavras não se sobrepõem. O match falha.
Esse modo de falha tem nome: o problema do desencontro de vocabulário. É por isso que a busca por palavra-chave continua perdendo, e é por isso que a busca semântica agora é o default em toda ferramenta séria que busca qualquer coisa com forma de texto. Abaixo: como a busca semântica realmente funciona em 2026 — em português direto, sem precisar de pós em matemática — e por que a maioria dos apps de consumo que entrega «busca IA» ainda erra.
Sistemas de busca velhos faziam match de strings literais. Você digitava custo de aquisição de cliente, o sistema achava documentos contendo essas palavras exatas. Documentos que diziam «CAC» ou «o custo de trazer compradores novos» ou «o que pagamos por inscrição» ficavam invisíveis.
Em pesquisa de information retrieval isso é medido há quarenta anos. O desencontro típico de vocabulário fica em torno de 70-80%: as pessoas usam palavras diferentes pro mesmo conceito a maior parte do tempo. Se sua busca só faz match de strings literais, você perde quatro a cada cinco documentos relevantes. É um jeito polido de dizer «a busca por palavra-chave está quebrada desde 1985».
Duas coisas consertaram. A primeira são os embeddings: um jeito de representar significado como números, pra duas frases que querem dizer a mesma coisa acabarem «próximas» mesmo sem compartilhar palavras. A segunda são as bases de dados vetoriais: armazenamento e índices que conseguem achar os vetores mais próximos rápido, mesmo quando o corpus é de milhões de documentos.
Juntas, são o que faz «busca semântica» existir.
Pega uma frase. Passa 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 pra frases com significados parecidos produzirem listas parecidas. Exemplo literal:
"O que é custo de aquisição de cliente" → embedding A"Quanto a gente paga pra trazer um cliente novo" → embedding B"Como estão as gaivotas hoje" → embedding COs embeddings A e B vão estar próximos no espaço de 1.536 dimensões em que vivem. C vai estar longe. Proximidade é medida por similaridade cosseno — o quão alinhados estão os dois vetores naquele espaço de alta dimensão. Números perto de 1,0 significam significado quase idêntico; perto de 0, sem relação.
Pode imaginar como plotar cada frase como um ponto numa galáxia de 1.536 dimensões onde a direção codifica significado. As coordenadas reais não querem dizer nada sozinhas — o que importa é quais outras frases caem perto de quais.
Vários modelos são competitivos em 2026. O text-embedding-3-small da OpenAI entrega 1.536 dimensões nativamente e suporta Matryoshka representation (dá pra truncar pra 768 ou 256 dimensões pra economizar armazenamento sem retreinar). O embed-v3 da Cohere é competitivo em conteúdo multilíngue. Alternativas open-source tipo bge-large e nomic-embed-text ficam a alguns pontos de precisão e rodam num Mac.
Pra cargas multilíngues — tipo vídeos salvos em 30 idiomas com consultas em qualquer um deles — o text-embedding-3-small é hoje o melhor equilíbrio entre precisão, custo e dimensões. No SavedThat a gente usa a truncação Matryoshka de 768 dimensões: metade do armazenamento, ~99% da qualidade de busca. (Mais sobre Matryoshka representation.)
Muitos apps de consumo em 2026 anunciam «busca IA». A maioria quer dizer uma de três coisas:
Só a primeira realmente resolve o desencontro de vocabulário nos seus dados. As outras duas são produtizadas mas não úteis pra achar o que você salvou.
Diagnóstico rápido: se você consegue buscar o conceito e não acha o documento, mas acha buscando uma das palavras específicas dele, a ferramenta está fazendo #2 ou #3 embrulhado como «busca IA». Se você acha o documento via paráfrase, é #1.
Embeddings sozinhos não ajudam se você precisa comparar cada consulta com milhões de vetores um por um. A busca completa de um índice de 50.000 documentos leva centenas de milissegundos no jeito ingênuo — lento demais pra uso interativo.
O conserto é indexação por approximate nearest neighbour (ANN). Estruturas de dados especializadas — HNSW (Hierarchical Navigable Small World), IVF, ScaNN — armazenam vetores pra os matches mais próximos serem achados em menos de 10 milissegundos mesmo em bibliotecas com dezenas de milhões de vetores.
O estado da arte atual (maio de 2026) pra busca semântica em produção:
pgvector; bases de dados vetoriais standalone tipo Qdrant, Pinecone e Weaviate usam todas HNSW ou variantes próximas. O SavedThat roda HNSW no pgvector porque manter os vetores ao lado dos metadados relacionais é operacionalmente mais simples que manter dois bancos.halfvec(768) no pgvector é hoje o default pra qualquer deploy preocupado com custo.Na escala do SavedThat (atualmente ~120 vídeos salvos × ~50 chunks cada = 6.000 vetores), o índice cabe em RAM e as buscas são sub-milissegundo.
Agora a graça que a maioria dos tutoriais pula: a busca semântica perde pra busca por palavra-chave em frases exatas.
Se você busca "text-embedding-3-small" (um nome de produto exato), a busca por palavra-chave devolve o documento mencionando essa string exata no rank 1. A busca semântica pode classificar mais alto um documento que fala de «embeddings da OpenAI em geral» porque é semanticamente mais próximo do significado médio da consulta, mesmo com a string literal faltando.
Isso é real. Benchmarks públicos mostram consistentemente que a semântica pura performa pior que palavra-chave pra consultas de alta especificidade: nomes de produto, assinaturas de função, citações exatas, datas, nomes de marca. A coisa que a semântica deveria consertar (desencontro de vocabulário) não existe pra essas consultas porque o usuário digitou a string literal que queria.
O conserto é rodar as duas e fundir os resultados.
A recuperação híbrida é a técnica que silenciosamente virou o default em sistemas de busca em produção sérios desde 2024:
1 / (rank + 60), somado entre os dois métodos. Documentos que aparecem bem nos dois recebem um boost significativo; documentos aparecendo só em um ainda contribuem.A constante 60 é um número mágico benchmarkeado até cansar e que funciona na maioria dos corpora. Dá pra tunar; geralmente não precisa.
O resultado: consultas parafraseadas ainda acham matches de conceito (via o lado semântico), e consultas de frase exata ainda classificam o match literal em #1 (via o lado palavra-chave). O ponto cego de cada método é coberto pelo outro.
É isso que o SavedThat entrega como busca padrão. O RPC search_chunks no nosso Postgres roda as duas consultas em paralelo, calcula scores RRF e devolve hits classificados em ~80ms pro tamanho atual do nosso corpus. (Microsoft sobre busca híbrida)
Pra casos de uso de alto valor — e-discovery legal, literatura médica, busca enterprise em milhões de documentos — o RRF híbrido geralmente é a penúltima camada. A última é re-ranking com modelo cross-encoder.
Um cross-encoder é um modelo menor e mais lento que pega a consulta completa e o documento candidato completo e calcula um score de relevância apertado prestando atenção nos dois juntos. Você não consegue rodar isso em um milhão de documentos (lento demais); roda nos top 50-200 resultados da recuperação híbrida pra reordenar com precisão.
A Cohere entrega rerank-v3 pra isso. Alternativas open-source: bge-reranker-large, jina-reranker-v2. Pra cargas de escala de consumo tipo SavedThat, o ganho marginal não justifica os 100ms de latência. Pra busca enterprise de e-discovery legal, re-ranking com cross-encoder é padrão.
A gente vai adicionar quando nosso corpus ou caso de uso exigir. Antes não.
O pipeline inteiro é aproximadamente:
| Etapa | Custo |
|---|---|
| Embedding de 1.000 chunks (~50 vídeos) | ~0,02 $ em créditos OpenAI |
| Armazenar 1M de chunks no pgvector | ~25 $/mês numa instância pequena de Postgres |
| Build de índice HNSW pra 1M de chunks | ~30 segundos, uma vez por mudança maior de dados |
| Uma consulta de busca (embed + lookup HNSW + FTS + RRF) | ~0,0001 $ + 80ms |
No pricing do SavedThat, uma assinatura Pro (6,99 $/mês) cobre milhares de buscas e várias centenas de novos salvos. A economia fecha na escala de consumo; o que não dá pra fazer é financiar isso com um plano gratuito-pra-sempre-ilimitado porque a conta da OpenAI cresce linearmente com o conteúdo enquanto a receita capeia em zero.
Três razões:
halfvec e MRL a conta dobra.As ferramentas que entregam busca semântica desde o dia 1 — Mem, Reflect, o tier premium do Glasp, SavedThat — são majoritariamente builds pós-2022 porque foi quando o custo dos embeddings caiu abaixo do limiar em que a escala de consumo pode ser precificada de jeito sustentável.
Quando avaliar uma ferramenta de buscar-dentro-de-X em 2026, pergunta:
text-embedding-3-small funciona em 100+ idiomas; modelos mais velhos ou menores não.Pra salvar vídeos e achar depois: SavedThat entrega os quatro (visão geral da arquitetura aqui). Glasp entrega só palavra-chave (gratuito) e semântica (pago). Mem entrega semântica sem híbrida. A «busca IA» do Notion é item 2 — LLM em cima de palavra-chave.
Esse é o panorama em maio de 2026.
Funcionalmente nenhuma — na prática os termos são usados de forma intercambiável. Estritamente, um embedding é a *representação* que um modelo produz, e um vetor é só uma lista de números. Todo embedding é um vetor; nem todo vetor é um embedding (uma coluna de intensidades de pixel é um vetor mas não um embedding). A maioria dos papers e documentação de engenharia usa «vetor» como termo de armazenamento e «embedding» como termo conceitual.
Depende do modelo de embedding. O text-embedding-3-small da OpenAI foi treinado em 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 similares do espaço vetorial. Modelos open-source menores costumam degradar significativamente em não-inglês. Se multilíngue é requisito, verifica que a model card mencione explicitamente alinhamento cross-lingual.
Rodar duas buscas e concatenar os resultados só te dá o dobro de resultados. A busca híbrida funde por score (RRF ou fusão ponderada) pra que o ranking final reflita o acordo entre os dois métodos. Um documento no rank 1 em palavra-chave e rank 1 em semântica acaba no rank 1 geral; um documento no rank 1 em palavra-chave mas rank 50 em semântica cai no meio. Sem fundir, você não sabe em quais resultados confiar.
Embeddings codificam significado semântico, não strings literais. Uma consulta como 'text-embedding-3-small' tem seu significado em 'membro da família de embeddings da OpenAI' mais do que na sequência literal de tokens. O vetor da consulta é similar aos vetores de documentos que falam dos embeddings da OpenAI em geral, que podem classificar mais alto que o documento específico mencionando o nome exato. A busca por palavra-chave tem zero ambiguidade em strings exatas — elas aparecem ou não. Híbrida cobre os dois modos.
Relacionados mas não a mesma. A busca semântica é o passo de recuperação — achar documentos próximos de uma consulta no espaço vetorial. RAG (Retrieval-Augmented Generation) é um sistema que usa busca semântica pra buscar documentos e depois passa pra um LLM generativo que escreve uma resposta usando os documentos como contexto. RAG inclui busca semântica como um componente; dá pra ter busca semântica sem RAG (quando você só quer achar os documentos, não gerar texto em cima).
Pra inferência — buscar contra um índice já construído — não. CPU dá conta da recuperação em escala de consumo. Pra construir o índice — rodar o modelo de embedding no seu conteúdo — uma GPU é rápida mas não obrigatória. A API da OpenAI faz os embeddings no datacenter deles, devolvendo o vetor pra você armazenar; a única coisa do seu lado é a base de dados vetorial e o embedding da consulta (uma chamada curta de API por consulta). O custo são centavos por mil buscas.
Search inside saved videos by what was actually said — across YouTube, Instagram, and TikTok. How transcript search works in 2026, and four tools that do it.
The 7 best video transcript search tools in 2026, ranked by what they actually do well. SavedThat, Glasp, Otter, Fireflies, Reduct, Trint, plus DIY Whisper.
The best AI video bookmark manager in 2026 depends on what you save. Honest comparison of SavedThat, Mymind, Raindrop, and Glasp — pricing, search, platforms.