O que é RAG e como funciona (guia iniciante)

#RAG em 30 segundos

RAG significa Retrieval-Augmented Generation: geração de texto aumentada por pesquisa. Em vez de pedir diretamente ao LLM «responda a essa pergunta», começa-se buscando em uma base de documentos os trechos mais relevantes, depois esses trechos são inseridos no prompt com a instrução: «aqui estão as fontes, responda com base nelas».

Uma boa analogia: um LLM sozinho é um estudante brilhante que responde de memória em uma prova. Um RAG é o mesmo estudante com permissão para consultar o material das aulas sobre a mesa. Ele inventa menos, cita a página certa e, se receber um material que nunca viu (seus PDFs, seus e-mails, sua wiki interna), ainda assim consegue responder sobre ele.

#Por que (e quando) precisar dele

Um LLM tem dois grandes defeitos que ficam evidentes assim que você o usa seriamente: ele inventa quando não sabe (as famosas “alucinações”) e só conhece os dados vistos durante o treinamento. O Qwen 3.5 9B nunca leu seu contrato, seu wiki no Notion nem sua base de incidentes. Pedir que ele responda diretamente sobre isso é pedir a alguém que imagine o conteúdo de um livro que não abriu.

O RAG resolve os dois ao mesmo tempo: injeta os bons trechos no prompt, o LLM os usa como base factual e as respostas tornam-se rastreáveis — você pode exibir as fontes.

Falar com seus PDFs

Documentação técnica, contratos, artigos científicos, manuais — tudo que pesa demais para caber em uma janela de contexto.

Assistente interno da equipe

Wiki, base de conhecimento de suporte, documentação do produto. Em vez de uma busca Ctrl+F aproximada, uma resposta em francês que cita as páginas corretas.

Monitoramento e síntese

Indexar centenas de artigos ou relatórios, fazer perguntas transversais, comparar fontes.

Dados recentes ou privados

Tudo o que o LLM não pôde ver: seu código, seus e-mails, publicações posteriores à sua data de corte.

#Pipeline em 4 etapas

Um RAG é composto por duas fases: a indexação (uma vez, antes) e a consulta (para cada pergunta). Aqui estão as quatro peças que se conectam.

1. 01
   1. Chunking — dividir os documentos

   Seus arquivos PDF, Markdown ou páginas web são divididos inicialmente em trechos (chunks) de aproximadamente 200 a 800 palavras. Não é possível gerar embeddings de um livro inteiro de uma vez e, de qualquer forma, queremos encontrar o trecho exato que responde à pergunta, e não todo o documento.
2. 02
   2. Embeddings — transformar o texto em vetores

   Cada chunk passa por um modelo de embeddings que o transforma em um vetor de números (tipicamente 384 a 1024 dimensões). Dois trechos que falam da mesma coisa gerarão vetores próximos nesse espaço — é essa magia que permite a pesquisa semântica.
3. 03
   3. Armazenamento em base vetorial

   Os vetores + o texto original são armazenados em uma base especializada (Chroma, Qdrant, FAISS…) que sabe responder rapidamente à pergunta « quais são os vetores mais próximos do meu? ».
4. 04
   4. Recuperação + geração

   Ao receber a pergunta do usuário, calcula-se o embedding da pergunta, recuperam-se os 3 a 10 chunks mais próximos, inserem-se esses chunks no prompt do LLM com uma instrução do tipo “responda com base nesses trechos”, e o LLM gera a resposta.

# Phase 1 : INDEXATION (une fois)
for doc in documents:
    chunks = split(doc, taille=500)              # 1. chunking
    for chunk in chunks:
        vector = embedder.embed(chunk)            # 2. embedding
        vector_db.add(vector, chunk)              # 3. stockage

# Phase 2 : INTERROGATION (à chaque question)
question = "Quel est le délai de résiliation ?"
q_vector = embedder.embed(question)               # même modèle qu'à l'indexation
top_chunks = vector_db.search(q_vector, k=5)      # 4a. retrieval

prompt = f"""Réponds en t'appuyant uniquement sur les extraits ci-dessous.

Extraits :
{top_chunks}

Question : {question}"""
reponse = llm.generate(prompt)                    # 4b. génération

#Embeddings: o coração do retrieval

Um modelo de embedding é um mini-LLM especializado em uma única tarefa: transformar um trecho de texto em um vetor de números que captura seu "sentido". Duas frases que falam do mesmo assunto gerarão vetores próximos, mesmo que não tenham nenhuma palavra em comum. É isso que diferencia o RAG de um simples Ctrl+F.

A qualidade final do RAG depende tanto do modelo de embeddings quanto do LLM por trás — muitas vezes, depende até mais do primeiro. Um embedding ruim recupera os trechos errados, e o melhor LLM do mundo não conseguirá responder corretamente a partir de trechos sem relação com o assunto.

nomic-embed-text

137 milhões de parâmetros, 768 dimensões, contexto de 8192 tokens. Uma escolha padrão sensata proposta pelo Ollama. Bom em inglês, razoável em francês.

mxbai-embed-large

335M parâmetros, 1024 dimensões. Mais preciso, 3 vezes mais lento. Útil quando a qualidade da recuperação é o fator limitante.

multilingual-e5-large

560M, 1024 dimensões. A melhor escolha se seus documentos estiverem em francês ou forem multilíngues.

bge-m3

Excelente em francês, suporta contextos longos. Mais pesado para rodar, mas é referência em conteúdo multilíngue.

#A base vetorial: onde os vetores vivem

Uma base vetorial é uma base de dados especializada em uma operação: "encontre para mim os N vetores mais próximos desse". Por trás, ela utiliza algoritmos (HNSW, IVF...) que tornam essa busca rápida mesmo com milhões de vetores. Para começar, você não precisa entender nada sobre esses algoritmos — basta saber qual escolher.

Chroma

Base vetorial de código aberto, integrada ao seu projeto Python ou executada como servidor. Ideal para começar: sem configuração, persistência em disco.

Qdrant

Mais robusto para produção: servidor dedicado, filtros, multi-tenant. Roda em um contêiner Docker com apenas um comando.

FAISS

Biblioteca do Facebook (Meta). Muito rápida, mas é apenas um índice — sem gerenciamento de metadados. Boa para casos em que o desempenho é crítico.

Armazenada na ferramenta

Open WebUI, AnythingLLM, LM Studio trazem a sua própria base vetorial. Isso é invisível — você carrega um PDF, ele é indexado. Perfeito para começar sem codar.

#O LLM: geração orientada

O LLM é o último elo. Ele recebe um prompt parecido com este: «Aqui estão 5 trechos extraídos da documentação. Responda à pergunta com base exclusivamente nesses trechos. Se a informação não estiver nos trechos, diga isso.»

Esse enquadramento muda tudo. Sem contexto injetado, o LLM responde a partir de sua memória de treinamento — e inventa se houver lacunas. Com os trechos certos no prompt, ele tem uma base factual à vista e se limita a reformular ou sintetizar.

Qual o tamanho do LLM?

Para um RAG simples, um modelo pequeno de 2026 que caiba em 8 GB (Qwen 3.5 9B, Granite 4.2 8B) é mais que suficiente. A qualidade do retrieval importa mais do que o tamanho do LLM.

Qual o tamanho da janela de contexto?

Pelo menos 4096 tokens. Os chunks recuperados + a pergunta + a instrução do sistema consomem rapidamente 2000-3000 tokens. Com 8192 ou mais, você tem uma boa margem.

Qual prompt de sistema?

Algo do tipo: 'você responde em francês, baseando-se apenas nos trechos fornecidos. Se a informação não estiver presente, diga isso claramente.'

#RAG local vs API na nuvem

Você pode montar um RAG com a API OpenAI ou Claude (rápido de implementar, desempenho máximo) ou totalmente local com Ollama + uma base vetorial + um modelo de embeddings (sem vazamento de dados, sem custo de uso). A escolha depende da sensibilidade dos documentos e do seu orçamento.

RAG via API na nuvem

Seus documentos são enviados ao prestador (OpenAI, Anthropic, Mistral…) durante a indexação e a cada pergunta. Desempenho e qualidade excelentes, mas uso incompatível com dados confidenciais (RGPD, sigilo médico, contratos de clientes).

RAG 100% local

Ollama para o LLM, nomic ou bge para os embeddings, Chroma ou Qdrant para a base. Nenhum dado sai da máquina. Ideal para profissionais (jurista, médico, RH), empresas sujeitas ao RGPD, e todos que querem manter o controle.

Híbrido

Embeddings locais, LLM via API: limita a exposição (os documentos completos permanecem locais; apenas os blocos relevantes são enviados para a nuvem quando você faz uma pergunta). Uma solução pragmática, mas não recomendada se os próprios blocos forem sensíveis.

#Por onde começar concretamente

Três caminhos de acordo com seu perfil. Todos os três rodam 100% localmente na sua máquina.

1. 01
   Sem codificar, com uma interface (Open WebUI ou AnythingLLM)

   Você instala Ollama, inicia Open WebUI ou AnythingLLM no Docker, carrega seus PDFs em uma « Knowledge Base » e conversa. Tudo — chunking, embeddings, recuperação — é gerenciado para você. 30 minutos do início ao fim.
2. 02
   Sem codar, no modo tudo-em-um (LM Studio)

   Desde a versão 0.3, o LM Studio tem a funcionalidade “Chat with Documents”: você anexa um arquivo ao chat, e ele cuida do resto. Limite: 5 arquivos por chat e formatos restritos (PDF com texto, DOCX, TXT, MD). Perfeito para perguntas pontuais sobre um documento.
3. 03
   Em Python com LangChain ou LlamaIndex

   Controle total: escolha do chunker, do modelo de embeddings, da base, do LLM e do prompt. Reserve meio dia para um primeiro protótipo bem feito, mais se quiser otimizar (reranker, pesquisa híbrida, etc.).

# 1. Installer Ollama (https://ollama.com)
# 2. Récupérer un LLM et un modèle d'embeddings
ollama pull qwen3.5:9b
ollama pull nomic-embed-text

# 3. Vérifier que le daemon répond
curl http://localhost:11434/api/tags

# 4. Lancer Open WebUI (interface ChatGPT-like avec RAG intégré)
docker run -d -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

# Ouvrir http://localhost:3000
# Settings -> Documents -> uploader des PDF
# Dans un chat : taper # pour attacher une Knowledge Base

#As armadilhas comuns para quem está começando

Embedder em inglês, documentos em francês

Causa número 1 de RAG decepcionante na França. Verifique se seu modelo de embeddings suporta o francês (multilingual-e5, bge-m3).

Chunks muito grandes ou muito pequenos

500 palavras são um bom ponto de partida. Se forem pequenos demais (< 100 palavras), os chunks perdem seu contexto; se forem grandes demais (> 1500), o embedding calcula a média de tudo e perde precisão.

Mudar o embedder sem reindexar

Os vetores de um modelo não são compatíveis com os de outro. Se você passar de nomic para bge, é preciso reindexar tudo — caso contrário, o retrieval retorna qualquer coisa.

Demasiados chunks no contexto

Acima de 8 a 10 blocos, o LLM começa a se perder. É melhor ter 5 blocos muito relevantes do que 20 moderadamente relevantes (é aí que um reranker entra em ação, em um nível mais avançado).

Sem citações exibidas

Para verificar se um RAG realmente funciona, exiba as fontes utilizadas em cada resposta. Se você não tiver essa visibilidade, não saberá diferenciar uma boa resposta de uma alucinação convincente.

#Para se aprofundar

Agora que você sabe o que é o RAG, estes guias são o próximo passo natural para colocar esse conhecimento em prática.

RAG local com Ollama sem programar

Guia passo a passo Open WebUI + AnythingLLM para montar seu primeiro RAG em 30 minutos, mesmo sem GPU.

Os melhores modelos de embeddings para francês

Comparativo detalhado para escolher entre nomic, multilingual-e5, bge-m3 e Solon de acordo com o seu corpus.

RAG local: introdução

Guia conceitual aprofundado: chunking, recuperação, reordenação dos resultados, métricas de avaliação.

O que é o Ollama e como ele funciona

Se você ainda não instalou Ollama, clique aqui.