Embeddings e espaço vetorial: a base da busca semântica
Como transformar significado em números e por que isso destrava busca por sentido (e o RAG).
5 min de leitura
Escolha como aprender
— combine como quiserDica: o vídeo é um resumo visual rápido — o áudio e o texto trazem a aula completa.
Para um computador, texto é só uma sequência de caracteres — sem noção de que 'cachorro' e 'cão' significam a mesma coisa, ou que 'banco financeiro' e 'banco de praça' são mundos diferentes. Embeddings resolvem exatamente esse problema: eles traduzem significado em coordenadas numéricas, abrindo a porta para busca por sentido, recomendação e — como veremos na lição 06 — RAG.
O que é um embedding, de verdade
Um embedding é um vetor — uma lista ordenada de números de ponto flutuante — que representa um pedaço de texto (ou imagem, ou áudio) de forma que o significado fique codificado na posição desse vetor num espaço de alta dimensão.
Pense assim: você tem um mapa. Cada cidade é um ponto. Cidades próximas geograficamente ficam perto no mapa. Agora imagine um mapa onde o eixo não é latitude/longitude, mas significado. 'Rei' e 'Rainha' ficam perto. 'Rei' e 'Maçã' ficam longe. 'Paris' fica perto de 'França' e também perto de 'capital europeia'.
Na prática, esse espaço tem centenas ou milhares de dimensões (modelos comuns usam 768, 1536 ou 3072 dimensões). Você não consegue visualizar diretamente, mas a geometria funciona: textos com sentido parecido ocupam regiões vizinhas, textos com sentido oposto ficam em regiões opostas.
O modelo de embedding aprende essas coordenadas durante o treino — exatamente o processo que vimos na lição 02. Ele é treinado em enormes corpora de texto para que palavras e frases que aparecem em contextos similares acabem com vetores similares. O resultado é que a posição no espaço carrega semântica real, não só estatística de frequência.
Espaço vetorial: proximidade = similaridade de significado
Cada texto vira um ponto no espaço. A distância entre pontos reflete diferença de significado. Textos semanticamente próximos formam clusters naturais — mesmo sem compartilhar nenhuma palavra.
- "cachorro" · [0.82, 0.14, ...]
- "cão" · [0.81, 0.15, ...]
- "gato" · [0.78, 0.21, ...]
- "banco financeiro" · [0.11, 0.88, ...]
- "investimento" · [0.09, 0.91, ...]
- "banco de praça" · [0.55, 0.12, ...]
- "árvore" · [0.58, 0.10, ...]
- Query do usuário · "animal de estimação"
- Resultados · cachorro, cão, gato
Similaridade por cosseno: a régua do espaço vetorial
Quando você quer saber se dois textos são semanticamente próximos, você compara os vetores deles. A métrica mais usada é a similaridade por cosseno — mas você não precisa da fórmula para entender o que ela faz.
Imagine dois vetores como setas saindo da origem de um gráfico. Se as duas setas apontam na mesma direção, o ângulo entre elas é zero: similaridade máxima (valor 1). Se apontam em direções perpendiculares, o ângulo é 90°: sem relação (valor 0). Se apontam em direções opostas: similaridade negativa (valor -1).
O que torna o cosseno útil é que ele mede direção, não comprimento. Um texto curto e um texto longo sobre o mesmo assunto podem ter vetores de magnitudes diferentes, mas apontam na mesma direção — e o cosseno captura isso corretamente.
Na prática: você gera o embedding da query do usuário, calcula a similaridade de cosseno contra todos os embeddings no seu índice, e retorna os mais próximos. Isso é busca semântica. Ela encontra 'cão' quando o usuário digita 'cachorro', encontra 'como cancelar minha assinatura' quando o documento diz 'procedimento de cancelamento de conta' — sem nenhuma palavra em comum.
Um erro comum é confundir o modelo de embedding com o LLM que gera texto. São modelos diferentes, com objetivos diferentes. O LLM prevê o próximo token (lição 03). O modelo de embedding transforma texto em vetor — ele não gera nada, só codifica. Na AWS, você vai usar o Amazon Titan Embeddings ou Cohere Embed via Bedrock para gerar vetores, e um modelo como Claude ou Llama para gerar respostas. Eles trabalham juntos no RAG, mas são peças separadas. Misturar os dois na cabeça causa confusão na hora de escolher, escalar e precificar.
Vector store: onde os embeddings vivem e como são consultados
Gerar um embedding é a metade do trabalho. A outra metade é armazenar e consultar esses vetores de forma eficiente. É aí que entra o vector store (ou índice vetorial).
Um vector store é um banco de dados otimizado para uma operação específica: dado um vetor de query, encontre os K vetores mais próximos no índice — a operação chamada kNN (k-nearest neighbors) ou, na versão aproximada e mais rápida, ANN (approximate nearest neighbors).
Algoritmos como HNSW (Hierarchical Navigable Small World) constroem grafos de navegação que permitem encontrar vizinhos próximos em tempo sub-linear, sem comparar contra todos os vetores do índice. É o que torna a busca viável em milhões de documentos.
Cada entrada no vector store tem três partes: o vetor em si, um identificador e um payload (os metadados — o texto original, a fonte, a data, o que você precisar). Quando a busca retorna os K vizinhos mais próximos, você usa o payload para recuperar o conteúdo real e entregá-lo ao LLM.
Na AWS, o Amazon OpenSearch Service com o plugin k-NN e o Amazon Aurora PostgreSQL com pgvector são as opções mais comuns. O Bedrock Knowledge Bases abstrai tudo isso — mas entender o que está por baixo é o que diferencia quem configura de quem arquiteta. Na lição 06 (RAG) e na lição 18 (Knowledge Bases), você vai ver esse fluxo completo em ação.
O que ficou desta lição
Dúvidas frequentes
Preciso treinar meu próprio modelo de embedding?
Quase nunca. Modelos como Titan Embeddings v2 ou Cohere Embed Multilingual funcionam muito bem para a maioria dos casos, incluindo português. Fine-tuning de embedding faz sentido em domínios muito específicos (jargão médico denso, código proprietário) — e mesmo assim, comece com o modelo pronto e meça antes de investir em treino.
Qual o tamanho ideal de chunk para gerar embeddings?
Depende do modelo e do caso de uso, mas chunks de 256–512 tokens com overlap de ~20% são um ponto de partida sólido. Chunks muito grandes diluem o sinal semântico; chunks muito pequenos perdem contexto. Isso é um parâmetro que você vai ajustar com evals — assunto da lição 09.
Busca vetorial substitui busca por palavras-chave (BM25)?
Não necessariamente — elas são complementares. Busca vetorial é ótima para intenção e paráfrase; BM25 é ótima para termos exatos, nomes próprios e códigos. Hybrid search (combinar os dois com RRF ou similar) costuma bater qualquer uma isolada. OpenSearch e pgvector suportam isso nativamente.
Checagem rápida
1. O que um embedding representa?
2. Busca semântica é melhor que busca por palavra-chave porque…