O que é um embedding?

Um embedding é a lista de números que um modelo produz para um trecho de texto, posicionada de forma que textos com significado parecido caiam perto uns dos outros. Numa busca, é isso que faz a pergunta “como cancelo?” encontrar o parágrafo sobre rescisão antecipada, que não tem uma palavra em comum com ela. O vetor não guarda o texto. Guarda uma posição.

É a terceira peça de um RAG e a primeira que você não escreve. Você corta o documento em chunks, manda cada chunk para um modelo de embedding e guarda o vetor que volta. Na hora da pergunta, o mesmo modelo transforma a pergunta em vetor e o sistema procura os vetores mais próximos. Todo o resto do pipeline opera sobre esses números, sem olhar o texto de novo.

Duas decisões vizinhas costumam ser confundidas com esta. Onde os vetores moram e como eles são varridos é assunto de banco vetorial; qual fórmula mede a distância entre dois deles é assunto de métrica de similaridade. Aqui a pergunta vem antes das duas: de onde o vetor sai, o que ele carrega e o que ele deixa cair no caminho.

O que “perto” quer dizer

Nenhum eixo do espaço tem nome. A dimensão 412 não é “formalidade” nem “assunto financeiro”. É o que o treino colocou ali, e não há razão para que ela seja interpretável por uma pessoa. O número isolado não diz nada. O que diz é a posição de um vetor em relação aos outros vetores gerados pelo mesmo modelo. É também por isso que vetor de um modelo não se compara com o de outro, mesmo com dimensão igual: cada espaço tem a própria orientação arbitrária.

A proximidade também não é uma propriedade natural do texto. Ela foi treinada. Um modelo de embedding moderno aprende com pares que alguém declarou relacionados: pergunta e resposta, título e corpo, uma frase e sua tradução. O objetivo puxa esses pares para perto enquanto empurra pares aleatórios para longe. “Perto”, no espaço resultante, quer dizer exatamente “parecido com o tipo de relação que estava nos pares de treino”. Nada além disso.

O melhor jeito de ver que a peça decisiva é o treino, e não a arquitetura, está no paper do Sentence-BERT. Pegar um BERT de prateleira e tirar a média dos vetores de token, que é o gesto óbvio, dá correlação de Spearman média de 54,81 em sete conjuntos de similaridade textual; usar o vetor do token de classificação dá 29,19. Os dois perdem para a média de vetores estáticos do GloVe, que dá 61,32. Treinar o mesmo BERT em pares, numa rede siamesa, leva o número a 74,89¹. A capacidade de gerar vetores estava lá desde o começo. Faltava alguém dizer ao modelo o que deveria ficar perto de quê.

O CLIP faz o mesmo com imagem e legenda, num espaço só, pela mesma régua: perto quer dizer que o treino viu os dois juntos.

Do texto ao vetor

O caminho tem quatro etapas, e é na terceira que a informação some.

O texto é tokenizado. Cada token vira um vetor, e o transformer refina esses vetores camada a camada, de modo que o vetor de “banco” numa frase sobre juros sai diferente do vetor de “banco” numa frase sobre praça. Até aqui você tem uma sequência: um vetor por token.

Aí vem o pooling, que na maioria dos modelos é uma média aritmética. Trezentos vetores viram um, e o que você tem daí em diante é o centro de massa do trecho.

Sobrevive à média o que é redundante no trecho: assunto, intenção, entidades citadas, registro. Não sobrevive o que dependia de uma posição específica. A ordem das palavras é a perda mais fácil de enxergar — “a empresa paga o fornecedor” e “o fornecedor paga a empresa” acabam vizinhas. Negação é a mais perigosa, porque um “não” é um token entre trezentos e mal move a média: “o plano Pro inclui suporte 24/7” e “o plano Pro não inclui suporte 24/7” ficam quase no mesmo ponto. E há o que só serve se for literal: número exato, código de erro, SKU, identificador de pedido. Tudo isso vira fragmento de token e se dilui na média.

Que o pooling é uma média é fato do código. Que negação sobrevive mal é observação empírica repetida em avaliação de similaridade, não uma lei com constante. Você mede isso na sua base em vinte minutos: embede dez pares de frases idênticas exceto pelo “não” e olhe o cosseno. Se ele vier acima de 0,9, você acabou de descobrir uma distinção que a sua busca não faz.

O tamanho do trecho interage com tudo isso e é assunto de chunking. Fica aqui só o limite duro: todo modelo de embedding tem um comprimento máximo de entrada, e a maioria das APIs corta o excesso em silêncio.

Quantas dimensões

Em julho de 2026, os modelos de embedding de texto em produção entregam vetores de 384 a 4.096 números, com 768, 1.024 e 1.536 sendo os tamanhos mais comuns. O que a dimensão compra é espaço para manter distinções separadas: com poucos eixos, conceitos diferentes acabam empurrados para o mesmo canto.

O que ela não compra é qualidade. Um modelo de 3.072 dimensões não é automaticamente melhor que um de 768 — quem decide é o dado e o objetivo de treino, e a diferença entre dois modelos de mesma dimensão costuma ser maior que a diferença entre duas dimensões do mesmo modelo. A dimensão vira critério de escolha porque é o número que aparece na ficha técnica, não porque prevê alguma coisa.

Do lado do custo, a conta é direta. Um vetor em float32 ocupa 4 bytes por dimensão: 3 KB a 768 dimensões, 12 KB a 3.072. Um milhão de chunks são 3 GB ou 12 GB, e essa diferença reaparece no tempo de varredura, que cresce linearmente com a dimensão em busca exata.

Existe uma saída para não ter que decidir isso na indexação. O Matryoshka Representation Learning, de 2022, treina a representação de modo que os primeiros números do vetor já formem sozinhos uma representação utilizável: você corta 3.072 em 512 e perde pouco, porque a informação foi organizada do grosso para o fino. O resultado principal que eles publicaram é de visão, com até 14 vezes menos dimensões pela mesma acurácia em classificação no ImageNet-1K, e a técnica foi estendida a BERT e a outras modalidades². É por isso que algumas APIs de embedding aceitam hoje um parâmetro de dimensão: por baixo, é truncar o vetor.

“Rei menos homem mais mulher”

Essa é a demonstração mais citada sobre embeddings e a origem da ideia de que o espaço é um sistema de coordenadas onde direções têm significado. Ela vem dos vetores de palavra da linhagem word2vec; o paper de 2013 que popularizou o método montou o conjunto de teste de analogias que virou padrão de avaliação por quase uma década: 8.869 questões semânticas e 10.675 sintáticas³. Como intuição inicial ela é útil. Como modelo mental para quem constrói busca, ela engana.

O método por trás é literal: some os vetores e ache o vetor mais próximo do resultado. O detalhe que quase nunca é contado é que a implementação padrão exclui as três palavras de entrada da lista de candidatos. Um trabalho de 2016 mediu o que acontece sem essa exclusão: o vizinho mais próximo do resultado era a palavra de partida em 93% dos casos e o segundo termo da analogia em 5%⁴. A conta devolve, quase sempre, o ponto de onde você saiu. “Rainha” é o que sobra depois de proibir “rei”, “homem” e “mulher”.

O mesmo trabalho mostrou que boa parte do acerto não vem do deslocamento. Uma linha de base que ignora o deslocamento inteiro, devolvendo simplesmente o vizinho mais próximo do terceiro termo, acertou 70% na categoria de plurais, contra 80% do método completo. Andar na direção oposta ao deslocamento ainda acertou 45%. E a acurácia do método variou de 13% a 90% conforme a categoria de analogia, o que já é sinal de que não se está medindo uma propriedade única do espaço.

Para quem monta recuperação, três coisas caem dessa história. A primeira é que direções não são manipuláveis com a confiabilidade que a demonstração sugere; “subtrair a direção da formalidade” do vetor de um chunk é uma ideia que soa boa e não sobrevive à medição. A segunda é que os embeddings de hoje são de frase e de passagem, treinados para outro objetivo — a estrutura de analogia não é o que eles otimizam. A terceira é que o que você tem na prática é um ranking: a ordem dos vizinhos é a saída útil, e o valor absoluto do cosseno informa muito menos do que parece.

Esse último ponto tem sustentação formal. Um trabalho de 2024 analisou embeddings derivados de modelos lineares regularizados, onde existe solução fechada, e mostrou que o cosseno entre eles pode produzir similaridades arbitrárias: em alguns casos nem sequer únicas, em outros determinadas implicitamente pela regularização usada no treino⁵. Em modelo profundo, onde várias regularizações se combinam, os autores alertam contra aplicar cosseno às cegas. A leitura prática é curta: um limiar de 0,8 não significa a mesma coisa em dois modelos, nem no mesmo modelo em duas bases diferentes.

Como escolher o modelo

O leaderboard resolve menos do que parece. O MTEB, publicado em 2022, avaliou 33 modelos em 8 tarefas de embedding, 58 datasets e 112 idiomas, e o achado central foi que nenhum método dominou todas as tarefas⁶. Um modelo bom em similaridade textual não é automaticamente bom em recuperação, que é a tarefa que você tem.

Pior: desempenho dentro do domínio não prevê desempenho fora dele. O BEIR, de 2021, avaliou dez sistemas de recuperação em 18 datasets e encontrou que o BM25, busca por palavra-chave sem vetor nenhum, perde de 7 a 18 pontos para os métodos neurais dentro do domínio de treino, no MS MARCO, e vira uma linha de base forte fora dele. O DPR, um recuperador denso, ficou 47,7% abaixo do BM25 na média dos 18 datasets. No BioASQ, que é biomédico, o BM25 fez 0,465 de nDCG@10 contra 0,127 do DPR⁷.

Isso não é argumento contra embedding. É argumento contra escolher o modelo pela tabela de outra pessoa. A ordem que funciona:

1. Filtre pelo que é binário. Idioma da sua base, comprimento máximo de entrada e licença. Isso corta a lista pela metade sem medição nenhuma.
2. Meça na sua base. Trinta perguntas reais, com o trecho que deveria voltar anotado, e a métrica sendo quantas vezes ele aparece no top-5. Dois ou três candidatos, mil documentos, uma tarde de trabalho.
3. Só então olhe dimensão e preço. Truncar e quantizar são decisões de custo, e você só sabe quanto elas custam depois de ter uma linha de base de qualidade.

Uma ressalva de operação: trocar o modelo obriga a reindexar tudo, e é a decisão mais cara de reverter no pipeline. Cara em coordenação, não em dinheiro — em julho de 2026, embedding continua sendo a chamada mais barata de qualquer catálogo.

Onde falha

Parecido não é relevante. Um modelo treinado com pares simétricos coloca “como cancelo minha assinatura?” perto de “como cancelo meu plano?”, que é outra pergunta, em vez do parágrafo que responde. O sintoma é uma busca que devolve o FAQ em vez da resposta. A correção costuma ser um modelo assimétrico ou o prefixo de instrução que alguns modelos exigem, do tipo query: e passage:; omitir esse prefixo degrada a busca sem nenhum aviso.

O que o treino nunca viu. Número de pedido, código de erro, SKU, nome de função: o tokenizador quebra em fragmentos e a média dilui o que sobrou. Vocabulário jurídico, médico ou de produto cai no mesmo buraco por outro motivo, o de estar fora do domínio de treino. Os dois são o argumento mais forte a favor de manter uma busca por palavra-chave ao lado da vetorial.

O vetor não é reversível. Não dá para reconstruir o texto a partir dele. Parece óbvio, e mesmo assim aparece índice em produção que guardou só os números; na hora de montar o prompt não há texto para colar.

A versão do modelo some do índice. Reindexação parcial com uma versão diferente do mesmo modelo produz um índice com dois espaços misturados, e o sintoma é uma busca que vai bem para alguns documentos e mal para outros, sem padrão aparente. Guardar o nome e a versão do modelo em cada linha custa alguns bytes e é o que permite enxergar o problema.

Pontuações todas parecidas. Quando os cossenos do top-20 ficam entre 0,71 e 0,74, você não tem um ranking, tem ruído ordenado. A causa costuma ser texto repetido em todo chunk empurrando os vetores para o mesmo lado, ou simplesmente o modelo errado para aquele domínio.

Quanto custa

Ordem de grandeza, para ver a forma da conta.

Indexar é uma passada por todo o corpus. Um milhão de chunks de 300 tokens são 300 milhões de tokens de embedding, pagos uma vez — e de novo a cada troca de modelo ou de corte.

Guardar é o custo contínuo, e é onde a dimensão pesa. Um milhão de vetores de 1.024 dimensões em float32 são 4 GB; os mesmos vetores em int8, 1 GB. A quantização é a alavanca de custo mais barata do pipeline e quase sempre é puxada antes de alguém ter medido o efeito dela na qualidade.

Consultar é desprezível do lado do embedding. Uma pergunta tem algumas dezenas de tokens, e o custo por pergunta está na geração, não aqui.

Footnotes

1. Reimers e Gurevych (2019) mediram que a média dos vetores de token de um BERT sem treino de pares fica abaixo da média de vetores estáticos do GloVe em similaridade textual, e que o treino siamês em pares reverte isso. ↩

2. Kusupati et al. (2022) treinaram representações aninhadas em que um prefixo do vetor funciona sozinho, com até 14 vezes menos dimensões pela mesma acurácia em classificação no ImageNet-1K. ↩

3. Mikolov et al. (2013) propuseram as arquiteturas que ficaram conhecidas como word2vec e montaram o conjunto de analogias com 8.869 questões semânticas e 10.675 sintáticas usado para medir regularidade linear no espaço. ↩

4. Linzen (2016) mostrou que o método de deslocamento depende da exclusão das palavras de entrada: sem ela, o vizinho mais próximo do resultado é o terceiro termo em 93% dos casos. Uma linha de base que ignora o deslocamento chegou a 70% em plurais. ↩

5. Steck et al. (2024) derivaram analiticamente que o cosseno entre embeddings de modelos lineares regularizados pode ser arbitrário, e que em modelo profundo o valor é afetado por regularizações que ninguém escolheu pensando em similaridade. ↩

6. Muennighoff et al. (2022) avaliaram 33 modelos em 8 tarefas e 58 datasets e não encontraram nenhum método que dominasse todas as tarefas. ↩

7. Thakur et al. (2021) mostraram que desempenho dentro do domínio não prevê generalização: o BM25 perde de 7 a 18 pontos no MS MARCO e é linha de base forte nos 18 datasets do BEIR, onde o DPR ficou 47,7% abaixo dele na média. ↩