Ler seus documentos

Buscar antes de responder

Um LLM sabe o que foi comprimido em seus pesos durante o treinamento. Mas sua documentação interna, suas notas, suas faturas ou uma página publicada ontem não estão necessariamente ali.

O RAG adiciona uma etapa antes da geração: buscar documentos relevantes, colocá-los no contexto e deixar o modelo responder usando essa informação.

Escolha uma pergunta: ela é embedded, comparada aos chunks do corpus, e os mais relevantes são injetados no prompt antes da geração. É esse desvio que permite a um LLM responder sobre documentos que nunca viu durante o treinamento.

Duas coisas a guardar dessa manipulação. Primeiro, os chunks recuperados não são os que contêm as palavras da pergunta — pergunte "qual é o maior planeta?" e você recebe os gigantes gasosos, embora a palavra "maior" não apareça em nenhum desses trechos. Quem decide é a proximidade no espaço vetorial, não o vocabulário. Segundo, o modelo nunca vê o corpus inteiro: ele só recebe o punhado de trechos selecionados. Toda a qualidade de um RAG se joga, portanto, antes da geração. Se o chunk certo não for recuperado, nenhuma sutileza de prompt vai compensar — é por isso que o resto deste capítulo fala sobretudo de corte e de busca.

De documentos a vetores

Primeiro cortamos documentos em chunks. Cada chunk vira um embedding e é salvo em uma base vetorial.

Quando chega uma pergunta, ela também vira vetor. Depois buscamos os chunks mais próximos por similaridade semântica. Não buscamos apenas palavras iguais: buscamos significado próximo. (Na verdade, não comparamos com todos os chunks: passando de algumas dezenas de milhares de vetores, as bases vetoriais usam índices aproximados — HNSW, IVF — que encontram os vizinhos mais próximos sem percorrer tudo. É até a razão de existirem.)

É isso a busca semântica: "próximo" não quer dizer "que contém as mesmas palavras", e sim "que exprime um sentido parecido".

O prompt aumentado

Os chunks recuperados são inseridos no prompt:

Pergunta do usuário + contexto recuperado + instruções de resposta

O modelo não "aprende" esses documentos permanentemente. Ele os lê naquele momento, dentro da janela de contexto.

Por que é útil

RAG resolve três problemas práticos:

• atualidade — você pode responder com informação mais recente que o treinamento
• especialização — pode usar documentos privados ou técnicos
• rastreabilidade — pode mostrar de onde veio uma resposta

Mas não é magia. Se a busca recupera chunks ruins, o modelo raciocina com dados ruins.

Qual modelo de embedding usar?

Nem toda pergunta leva aos chunks certos com o mesmo embedding. Um modelo treinado em português generalista vai recuperar mal código Python; um modelo treinado em código vai recuperar mal trocas médicas.

As escolhas que aparecem na prática:

• text-embedding-3-small / -large (OpenAI) — qualidade sólida, generalista, multilíngue. Por muito tempo o default de quem estava começando; hoje ultrapassado nos benchmarks, mas ainda perfeitamente utilizável.
• bge-large / bge-m3 (BAAI) — open-source, excelente em multilíngue. Dominaram os benchmarks MTEB em 2024.
• Gemini Embedding (Google) — na liderança do MTEB em inglês.
• Qwen3-Embedding (Alibaba) — o melhor dos modelos de pesos abertos, que você pode hospedar por conta própria.
• Voyage 3.x, Cohere embed-v4, Jina v4 — as referências comerciais do momento, sendo a última multimodal (texto e imagens no mesmo espaço).
• all-MiniLM-L6-v2 (Sentence-Transformers) — pequeno, rápido, possível de implantar localmente. Boa relação qualidade/custo para casos simples.
• Modelos especializados por domínio (código, biomédico, jurídico) — sempre melhores no nicho, mais fracos em outros lugares.

Esse ranking muda a cada seis meses. E cuidado ao lê-lo: as pontuações do MTEB v2 não se comparam com as da v1, as tarefas mudaram entre as duas.

Uma regra prática: testar dois ou três modelos com seus dados e suas perguntas. O ranking MTEB diz pouco sobre seu caso de uso específico.

O reranker: uma segunda passagem

A busca vetorial tem um defeito: é rápida mas grosseira. Um embedding de algumas centenas de dimensões é uma média difusa de um texto. Muitos chunks "mais ou menos relevantes" flutuam no topo, e os realmente bons às vezes ficam afogados.

Por isso uma segunda etapa virou padrão em sistemas RAG sérios: o reranker.

A ideia em duas etapas:

1. Primeira passagem (busca vetorial) — recupera os 50 ou 100 chunks mais próximos. Rápido.
2. Segunda passagem (reranking) — um modelo pequeno (frequentemente um cross-encoder) avalia cada par (pergunta, chunk) junto, dá uma pontuação precisa, e mantém o top 5–10. Lento por chunk, mas só é executado nos 50 candidatos da primeira passagem.

O reranker vê a pergunta e o chunk ao mesmo tempo, o que o embedding não faz. Ele capta sutilezas semânticas que a busca vetorial perde. Cohere, Jina AI, BAAI oferecem rerankers prontos para usar.

Sem reranker, seu RAG estagna. Com ele, a qualidade salta um nível sem mudar o resto do pipeline.

Fragilidades

Um pipeline RAG pode falhar por vários motivos:

• chunks grandes ou pequenos demais
• embeddings pouco adaptados ao domínio
• perguntas que precisam combinar muitas fontes
• contexto recuperado contraditório
• modelo que ignora parte do contexto

A qualidade depende tanto do retrieval quanto do modelo gerativo.

O próximo passo

Com RAG, o modelo pode consultar documentos. Mas o pipeline clássico — embed, retrieve, generate — é uma arquitetura "passiva": o modelo recebe uma pergunta, busca chunks, responde. Desde 2025, ele vem sendo concorrido em muitos casos de uso pela busca agêntica: damos ao modelo uma ferramenta de busca e o deixamos buscar em loop, reformular, cavar até ter o que precisa. Com ferramentas, ele pode fazer ainda mais: calcular, chamar APIs, navegar, escrever arquivos. Isso nos leva aos agentes.

Atualizado em 2 de agosto de 2026