AI Watch · LLM concepts explained
Embeddings: how meaning becomes math
Every RAG pipeline, semantic search box, and recommendation feature people build "on top of AI" today rests on the same idea underneath: turning content into vectors so a computer can compare meaning, not just characters.
1. What an embedding actually is
An embedding is a dense numerical vector — a long list of numbers, typically hundreds to a few thousand dimensions — that represents a piece of content: a word, a sentence, a whole document, an image, even audio. A model trained specifically for this task (an embedding model) reads the content and outputs that vector. The key property is that vectors end up positioned in space so that distance approximates meaning: two sentences that mean similar things land close together, even if they don't share a single word in common.
Concrete example
The sentences "the cat sat on the mat" and "a feline rested on the rug" share almost no vocabulary, but a good embedding model places their vectors close together in that high-dimensional space — because their meaning is nearly identical.
2. Why this matters more than keyword search
Classic keyword search matches literal strings: search "car" and you won't find a document that only says "automobile," unless someone manually maintained a synonym list. Embeddings sidestep that entirely — instead of comparing text character-by-character, the system compares vectors and finds the nearest ones, even when the query's wording is completely different from the source text. This is what makes "semantic search" possible: matching on intent, not spelling.
3. Vector databases: storing and searching embeddings at scale
Once you've embedded millions or billions of pieces of content, you need a way to ask "which vectors are closest to this new one?" fast. That's the job of a vector database — it indexes embeddings and answers nearest-neighbor queries in milliseconds using approximate nearest-neighbor (ANN) algorithms like HNSW, IVF-PQ, or ScaNN, which trade a small amount of accuracy for a huge amount of speed compared to checking every vector one by one.
4. Where embeddings meet RAG
Retrieval-Augmented Generation (RAG) is the most common production use of embeddings today. The pipeline looks like this:
- Embed the user's query into a vector.
- Run a nearest-neighbor search over a vector index built from your documents (already embedded ahead of time).
- Take the top-K most relevant chunks found.
- Feed those chunks to the LLM as context, alongside the original question.
Why this quality gate matters: the retrieval step directly determines whether the LLM has good context or poor context to work with — and therefore whether it answers accurately or hallucinates. A great LLM fed irrelevant retrieved chunks will still produce a bad answer.
5. What embeddings don't fix
Embeddings solve the "find semantically similar content" problem, but they don't solve everything people hope RAG will solve. Chunking strategy (how you split documents before embedding them), embedding model quality, and how many results you retrieve all affect final answer quality independently of the LLM itself. Bad chunking — splitting a document mid-sentence or mid-table — can produce embeddings that don't represent anything coherent, no matter how good the underlying model is.
6. A minimal practical example
Conceptually, using an embedding API looks like this — the same shape whether you're using OpenAI's, Anthropic's, or an open-source embedding model:
Pseudocode
vector = embed("How do I reset my password?")
results = vector_db.search(vector, top_k=5)
answer = llm.generate(question, context=results)
That's the entire shape of most "chat with your docs" products on the market today: embed, search, and hand the results to the model as context.
IA Watch · Conceitos fundamentais de LLMs
Embeddings: como significado vira matemática
Todo pipeline de RAG, caixa de busca semântica e feature de recomendação que as pessoas constroem "em cima de IA" hoje se apoia na mesma ideia por baixo: transformar conteúdo em vetores pra um computador comparar significado, não só caracteres.
1. O que um embedding de fato é
Um embedding é um vetor numérico denso — uma lista longa de números, tipicamente de centenas a alguns milhares de dimensões — que representa um pedaço de conteúdo: uma palavra, uma frase, um documento inteiro, uma imagem, até áudio. Um modelo treinado especificamente pra essa tarefa (um modelo de embedding) lê o conteúdo e devolve esse vetor. A propriedade chave é que os vetores acabam posicionados no espaço de forma que distância aproxima significado: duas frases que significam coisas parecidas caem perto uma da outra, mesmo que não compartilhem uma única palavra em comum.
Exemplo concreto
As frases "o gato sentou no tapete" e "um felino descansou no carpete" quase não compartilham vocabulário, mas um bom modelo de embedding coloca os vetores delas perto um do outro nesse espaço de alta dimensão — porque o significado é quase idêntico.
2. Por que isso importa mais que busca por palavra-chave
Busca por palavra-chave clássica combina strings literais: busque "carro" e você não vai encontrar um documento que só diz "automóvel", a menos que alguém tenha mantido manualmente uma lista de sinônimos. Embeddings contornam isso completamente — em vez de comparar texto caractere por caractere, o sistema compara vetores e encontra os mais próximos, mesmo quando a formulação da busca é completamente diferente do texto original. É isso que torna a "busca semântica" possível: casar por intenção, não por ortografia.
3. Bancos de dados vetoriais: armazenando e buscando embeddings em escala
Depois que você embedou milhões ou bilhões de pedaços de conteúdo, precisa de uma forma de perguntar "quais vetores estão mais próximos desse novo?" rápido. Esse é o trabalho de um banco de dados vetorial — ele indexa embeddings e responde consultas de vizinho mais próximo em milissegundos usando algoritmos aproximados de vizinho mais próximo (ANN) como HNSW, IVF-PQ ou ScaNN, que trocam um pouco de precisão por uma enorme velocidade comparado a checar cada vetor um por um.
4. Onde embeddings encontram RAG
Retrieval-Augmented Generation (RAG) é o uso de produção mais comum de embeddings hoje. O pipeline é assim:
- Transformar a pergunta do usuário num vetor (embed).
- Rodar uma busca de vizinho mais próximo sobre um índice vetorial construído a partir dos seus documentos (já embedados antecipadamente).
- Pegar os top-K trechos mais relevantes encontrados.
- Alimentar esses trechos pro LLM como contexto, junto com a pergunta original.
Por que essa etapa de qualidade importa: a etapa de recuperação determina diretamente se o LLM tem um contexto bom ou ruim pra trabalhar — e, portanto, se ele responde com precisão ou alucina. Um LLM ótimo alimentado com trechos recuperados irrelevantes ainda vai produzir uma resposta ruim.
5. O que embeddings não resolvem
Embeddings resolvem o problema de "encontrar conteúdo semanticamente parecido", mas não resolvem tudo que as pessoas esperam que o RAG resolva. Estratégia de chunking (como você divide os documentos antes de embedá-los), qualidade do modelo de embedding, e quantos resultados você recupera afetam a qualidade final da resposta independentemente do LLM em si. Um chunking ruim — cortando um documento no meio de uma frase ou de uma tabela — pode produzir embeddings que não representam nada coerente, não importa quão bom seja o modelo por trás.
6. Um exemplo prático mínimo
Conceitualmente, usar uma API de embedding é assim — a mesma forma seja usando a da OpenAI, da Anthropic, ou um modelo de embedding open-source:
Pseudocódigo
vetor = embed("Como eu reseto minha senha?")
resultados = vector_db.search(vetor, top_k=5)
resposta = llm.generate(pergunta, context=resultados)
Essa é a forma inteira da maioria dos produtos "converse com seus documentos" no mercado hoje: embedar, buscar, e entregar os resultados pro modelo como contexto.