Embeddings e busca vetorial
Como significado vira vetor, similaridade por cosseno e o que é um vector store.
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. Terminar o áudio ou o vídeo, ou passar no quiz, já conta a aula como concluída.
Antes de montar qualquer pipeline RAG, você precisa entender o que acontece quando um texto vira um vetor, porque é essa transformação que torna possível buscar por significado, não apenas por palavras. Nesta aula você vai entender embeddings, similaridade por cosseno, índices vetoriais e como escolher o modelo de embedding certo para o seu caso.
O que é um embedding, de verdade
Um modelo de linguagem não entende texto como string, ele entende texto como posição num espaço de alta dimensão. Um embedding é exatamente isso: uma lista de números (o vetor) que representa onde aquele texto "mora" nesse espaço.
A propriedade mais importante: textos com significado parecido ficam próximos no espaço. "Cancelar assinatura" e "encerrar plano" vão parar perto um do outro. "Cancelar assinatura" e "receita de bolo" ficam distantes. Isso não é magia, é o resultado de treinar o modelo em bilhões de exemplos onde essas relações aparecem juntas.
Pense assim: imagine que cada documento é uma estrela no céu. O modelo de embedding é o telescópio que projeta o significado de cada texto em coordenadas. Quando você busca algo, você está perguntando "quais estrelas estão mais perto das coordenadas da minha pergunta?"
Essa representação carrega contexto semântico que busca por palavra-chave jamais captura. É por isso que RAG funciona onde CTRL+F falha: você encontra o trecho certo mesmo que ele use vocabulário completamente diferente da sua query.
Fluxo: texto → embedding → índice → busca
Como um texto percorre o pipeline de embedding até virar um resultado de busca
- Documento · (chunk de texto)
- Query do usuário · (pergunta)
- Embedding Model · Titan / Cohere
- Índice Vetorial · ANN index
- Metadados · source, date, id
- Similaridade · por cosseno
- Top-K chunks · resultados
Similaridade por cosseno e o índice vetorial
Para comparar dois vetores, o método mais comum é a similaridade por cosseno: em vez de medir a distância absoluta entre dois pontos, você mede o ângulo entre eles. Dois vetores apontando na mesma direção têm cosseno 1 (idênticos em significado). Direções opostas dão cosseno -1. Perpendiculares, zero.
Por que ângulo e não distância euclidiana? Porque embeddings normalizados (comprimento 1) tornam as duas métricas equivalentes, e normalização é o padrão na maioria dos modelos. O que importa é a direção semântica, não o tamanho do vetor.
Agora o problema prático: se você tem 10 milhões de chunks indexados, comparar a query com todos eles um a um é inviável em tempo real. É aqui que entra o ANN: Approximate Nearest Neighbor. Algoritmos como HNSW (usado no OpenSearch e pgvector) constroem uma estrutura de grafo que permite encontrar os vizinhos mais próximos sem varrer o índice inteiro.
O "aproximado" não é um defeito, é uma escolha deliberada de engenharia. Você troca um recall de 100% por latência de milissegundos. Na prática, com parâmetros bem calibrados, o recall fica em 95-99% e a latência cai de segundos para dezenas de milissegundos. Para RAG, esse trade-off é sempre válido.
Na prática, o modelo de embedding que você escolhe na fase de indexação fica preso ao seu índice para sempre, ou até você reindexar tudo. Trocar de modelo depois significa reprocessar cada chunk e reconstruir o índice do zero. Por isso eu trato essa escolha com o mesmo peso que a escolha do banco de dados: avalie antes, teste com seus dados reais, e documente a decisão. O Amazon Titan Embeddings V2 é meu ponto de partida padrão em projetos AWS pelo custo baixo e integração nativa com Bedrock Knowledge Bases. Cohere Embed v3 entra quando preciso de multilingual robusto ou quando o benchmark no meu domínio específico justifica o custo extra. Nunca escolho modelo de embedding por popularidade, escolho por recall no meu corpus.
Dimensão, normalização e escolha do modelo
Todo embedding tem uma dimensão: o número de valores no vetor. Titan Embeddings V2 suporta 256, 512 ou 1024 dimensões. Cohere Embed v3 usa 1024. Modelos open-source como all-MiniLM-L6-v2 usam 384.
Mais dimensões = mais capacidade de capturar nuances semânticas, mas também mais custo de armazenamento e latência de busca. Para a maioria dos casos de RAG corporativo em português, 1024 dimensões é o ponto ótimo. Dimensões menores (256-512) fazem sentido quando o volume é enorme e o domínio é restrito.
Normalização significa que o vetor gerado tem comprimento (norma L2) igual a 1. Quase todos os modelos modernos normalizam por padrão. Isso importa porque garante que a similaridade por cosseno e o produto interno dão o mesmo resultado, e simplifica a configuração do índice.
Alguns critérios concretos para escolher o modelo:
- Idioma: Titan V2 e Cohere v3 têm boa cobertura de português. Modelos só-inglês degradam silenciosamente em textos PT-BR.
- Tamanho máximo de input: Titan V2 aceita até 8192 tokens. Cohere v3 aceita 512 tokens por padrão (com chunking adequado isso não é problema, veja a aula 03).
- Custo por token: avalie com o volume real do seu projeto antes de decidir.
- Latência de inferência: em pipelines síncronos, o tempo de embedding da query soma na latência total do RAG.
Na aula 04 você vai ver como esse vetor de query se encaixa no pipeline completo de recuperação e geração.
Termos de busca vetorial
Toque num cartão para virar.
Modelos de embedding disponíveis no Amazon Bedrock
| Modelo | Dimensões | Max tokens input | Multilingual | Melhor para |
|---|---|---|---|---|
| Amazon Titan Embeddings V2 | 256 / 512 / 1024 | 8192 | Sim (25+ idiomas) | RAG geral na AWS, integração nativa com Knowledge Bases |
| Cohere Embed v3 (English) | 1024 | 512 | Não | Corpora em inglês com alta precisão semântica |
| Cohere Embed v3 (Multilingual) | 1024 | 512 | Sim (100+ idiomas) | Documentos multilíngues, PT-BR com alta qualidade |
O que fixar desta aula
Perguntas frequentes
Posso usar o mesmo modelo de embedding para indexar e para a query?
Sim, e você deve. Documento e query precisam estar no mesmo espaço vetorial para que a comparação faça sentido. Usar modelos diferentes para cada um é um bug silencioso que destrói a qualidade da busca.
Qual a diferença entre produto interno (dot product) e similaridade por cosseno?
Para vetores normalizados (norma L2 = 1), os dois são equivalentes. A maioria dos modelos modernos normaliza por padrão, então na prática você pode usar qualquer um. Se o seu modelo não normaliza, use cosseno explicitamente.
Preciso de GPU para gerar embeddings em produção?
Não quando você usa modelos via API (Bedrock, Cohere API). A inferência roda na infraestrutura do provedor. Se você hospedar o modelo você mesmo (ex.: SageMaker com modelo open-source), GPU acelera significativamente, mas para a maioria dos casos de RAG na AWS, a API é mais simples e mais barata.
O que acontece se meu chunk for maior que o limite de tokens do modelo de embedding?
O modelo trunca silenciosamente, você perde o conteúdo além do limite sem nenhum erro. É um dos motivos pelos quais a estratégia de chunking (aula 03) precisa levar em conta o limite do modelo de embedding escolhido.