Um modelo de embedding pega um trecho de texto — uma frase, um parágrafo, um documento inteiro — e o comprime em um vetor de comprimento fixo de números de ponto flutuante, tipicamente entre 384 e 4096 dimensões. A mágica está em como esses números são arranjados: durante o treinamento, o modelo aprende a colocar textos semanticamente similares próximos nesse espaço de alta dimensionalidade e empurrar textos dissimilares para longe. A abordagem de treinamento padrão usa aprendizado contrastivo, onde o modelo vê pares de textos que são relacionados (uma pergunta e sua resposta, uma frase e sua paráfrase) e aprende a minimizar a distância entre seus vetores enquanto maximiza a distância de pares não relacionados. Modelos como bge-large-en da BAAI, text-embedding-3 da OpenAI e embed-v3 da Cohere usam essa receita geral, embora difiram em arquitetura, dados de treinamento e objetivos contrastivos específicos que otimizam.
Na prática, você usa embeddings primeiro codificando seus documentos em vetores e armazenando-os em um banco de dados vetorial como Qdrant, Pinecone, Milvus ou FAISS. No momento da consulta, você codifica a pergunta do usuário em um vetor usando o mesmo modelo e realiza uma busca por vizinhos mais próximos para encontrar os vetores de documentos mais similares. A métrica de distância importa — similaridade de cosseno é a mais comum, mas alguns modelos são treinados para produto escalar ou distância euclidiana. Uma coisa que confunde as pessoas: você deve usar o mesmo modelo de embedding tanto para documentos quanto para consultas. Vetores de modelos diferentes vivem em espaços completamente diferentes e não podem ser comparados, mesmo que aconteçam de ter o mesmo número de dimensões.
A dimensionalidade do vetor de embedding representa um trade-off entre expressividade e custo. Um vetor de 1536 dimensões pode capturar mais nuances do que um de 384 dimensões, mas também custa quatro vezes mais para armazenar e buscar. Para um milhão de documentos, a diferença é dezenas de gigabytes de RAM no seu banco de dados vetorial versus alguns gigabytes. Alguns modelos mais novos suportam embeddings Matryoshka, onde você pode truncar o vetor para menos dimensões com degradação graciosa — use as 1024 dimensões completas para sua coleção mais importante e as primeiras 256 para uma menos crítica. Quantização também ajuda: armazenar vetores como INT8 em vez de float32 corta a memória em 4x com surpreendentemente pouca perda de precisão, e é por isso que sistemas em produção cada vez mais usam embeddings quantizados.
Um equívoco comum é que modelos de embedding entendem significado da mesma forma que humanos. Eles são muito bons em similaridade semântica de superfície — sinônimos, paráfrases, conceitos relacionados — mas podem ter dificuldade com negação ("o restaurante não era bom" e "o restaurante era bom" frequentemente acabam próximos), com relações lógicas complexas e com jargão específico de domínio no qual não foram treinados. É por isso que sistemas de retrieval-augmented generation frequentemente combinam busca vetorial com busca por palavra-chave (busca híbrida) e usam um modelo reranker como segunda passagem para melhorar a precisão. O embedding recupera um conjunto amplo de candidatos; o reranker, que é mais lento mas mais preciso, os ordena por relevância real. Acertar esse pipeline importa muito mais do que escolher o modelo de embedding com a pontuação mais alta no leaderboard do MTEB.