Como RAG funciona — o padrão arquitetural que faz LLMs deixarem de alucinar

Felipe Vieira 23 de maio de 2026 🇧🇷 Português 10 min read

Como RAG funciona — o padrão arquitetural que faz LLMs deixarem de alucinar — cover

Todo LLM que você já usou mentiu pra você — com confiança, fluência e frequência. Pergunte a qualquer modelo sobre algo que aconteceu semana passada. Ele não sabe. Não pode saber. O conhecimento dele foi congelado meses atrás. Se tentar responder, alucina.

Isso não é bug. É limitação arquitetural fundamental. LLMs guardam conhecimento em parameters — bilhões de pesos numéricos aprendidos durante o treino. Quando o treino acaba, o conhecimento fica trancado. O modelo não sabe o que não sabe, então preenche as lacunas com fabricação confiante. Estudos mostram que taxas de hallucination podem ser tão baixas quanto 1% pra summarização simples — mas passam de 58% em tarefas complexas (survey de hallucination da ACM).

É exatamente isso que Retrieval-Augmented Generation (RAG) resolve. RAG não embute conhecimento no modelo — em vez disso, puxa contexto relevante quando você faz a pergunta. O modelo continua inteligente, seus dados ficam atualizados, e cada resposta é rastreável até a fonte.

O problema do conhecimento — por que LLMs sozinhos não bastam

Conhecimento congelado no tempo

Todo LLM tem uma data de corte. Tudo que ele sabe foi raspado, processado e comprimido em parameters durante o treino. Depois dessa data, o modelo é cego — não sabe do lançamento do seu produto, do incidente de segurança de ontem, da mudança da política de RH desta manhã.

Em negócios, precisão importa. Customer support, análise jurídica, busca interna, compliance — modelo que não acessa informação atual é liability, não asset.

"Context windows enormes resolvem" — não, não resolvem

A abordagem força-bruta é tentadora: joga tudo no prompt. Context windows cresceram muito — alguns modelos já lidam com mais de um milhão de tokens. Mas tem três problemas fatais:

  1. É caro. Você paga por token. Mandar a base de conhecimento inteira em toda query queima o budget rapidamente.
  2. Tem limite duro. 1M de tokens não cobre os documentos de uma enterprise grande, muito menos os databases.
  3. Modelos pioram com mais contexto — e essa é a que a maioria ignora.

Pesquisa de Stanford e UC Berkeley mostra que performance de LLM segue curva em U. Modelos vão bem quando informação-chave está no início ou no fim, mas a acurácia despenca quando fatos importantes estão enterrados no meio. Nos experimentos de multi-document QA de Liu et al. ("Lost in the Middle"), acurácia caiu pra ~25% quando a informação-chave foi colocada no meio de 20 documentos. Ou seja: mais contexto não garante que o modelo vai usar.

"Então fine-tune" — também não

Fine-tuning ajusta os pesos do modelo pra incorporar novo conhecimento. Em teoria, dá pra ensinar o modelo sobre o seu domínio. Na prática, gera mais problemas que resolve:

O que se precisa: fornecer ao LLM a informação certa no momento certo pra cada query, sem mudar o modelo. Isso é RAG.

O que RAG realmente é — a analogia da prova com consulta

RAG é um padrão arquitetural, não produto. A melhor analogia: prova com consulta vs. prova sem consulta.

Estudante em prova sem consulta depende do que decorou — esse é o LLM padrão. É inteligente, sabe raciocinar, mas está limitado ao que está nos parameters. Estudante em prova com consulta tem a mesma capacidade de raciocínio, mas pode checar páginas relevantes antes de responder. Esse é RAG.

A definição formal vem do paper de 2020 de Lewis et al. (Facebook AI Research e University College London) que introduziu RAG. Modelos RAG combinam parametric memory (o modelo pretreinado) com non-parametric memory (um índice externo de conhecimento) acessado por um neural retriever.

Você atualiza o conhecimento do modelo apenas trocando o índice de retrieval. Sem retraining. Loop de 3 passos:

  1. Query chega: usuário faz pergunta.
  2. Retrieve: sistema busca na base externa os melhores chunks de informação.
  3. Pergunta + contexto → LLM: o modelo gera resposta baseada nos documentos recuperados.

Você não está mudando o modelo. Está mudando o que ele vê. Essa distinção é o que torna RAG tão poderoso e prático.

Como RAG funciona por baixo do capô

Um sistema RAG tem duas partes principais:

Embeddings — o mecanismo central

Espaço vetorial mostrando duas frases diferentes mapeadas para pontos próximos por similaridade semântica, com visualização do ângulo cosseno entre vetores

Antes de qualquer coisa, você precisa entender embeddings. É o conceito que habilita semantic search.

Text embeddings transformam texto em vetores densos de números (arrays de floats, tipicamente 1.536 ou 3.072 dimensões) que capturam o significado. Palavras e sentenças com intenção similar ficam próximas no espaço vetorial — mesmo com palavras diferentes.

Considere: "Como eu redefino minha senha?" e "Não consigo entrar na minha conta" usam palavras completamente diferentes. Quando convertidas em embeddings, produzem vetores quase idênticos. A distância entre eles é minúscula porque os significados são similares. Medido via cosine similarity, dot product ou distância Euclidiana.

O insight chave: o sistema acha conteúdo relevante mesmo quando a pergunta do usuário não usa as palavras exatas do documento. Busca por significado, não por keyword. Provedores populares de embeddings em 2026:

Pipeline de ingestão (offline)

Pipeline de ingestão de 5 passos — load, chunk, embed, store, tag — com setas brilhantes conectando os estágios

Quando rodar? Quando documento novo entra, quando documento existente é editado, quando database muda, ou em schedule (nightly, weekly). Times mais avançados disparam re-ingestion automaticamente quando a qualidade do retrieval cai.

Cinco passos:

  1. Load: carregar documentos de qualquer fonte (PDFs, databases, APIs, wikis, Slack, Confluence). LangChain e LlamaIndex oferecem conectores prontos pra dezenas de fontes.
  2. Chunking: dividir documentos em pedaços semanticamente coerentes. Este é o passo de maior alavanca. Estratégias: tamanho fixo (simples mas quebra parágrafos), sentence-based (NLTK/spaCy), recursive (LangChain default), semantic (custosa mas melhor qualidade), late chunking (técnica de 2024 que embedda o doc todo antes de cortar).
  3. Embedding: converter cada chunk em vetor com o modelo escolhido.
  4. Storage: armazenar os vetores em vector DB otimizado pra similarity search. Top picks: Pinecone, Qdrant, Weaviate, Milvus, pgvector (sobre Postgres).
  5. Metadata tagging: tagear cada chunk com fonte, timestamp, categoria, ACL. Essa metadata vira crítica depois pra filtering, attribution e security.

Pipeline de retrieval (online)

Arquitetura de retrieval híbrido combinando busca por keyword esparsa e busca vetorial densa, fundidas via RRF, output como lista ranqueada

Quando o usuário pergunta, o pipeline de retrieval dispara:

  1. Query embedding: pergunta vira vetor, usando o mesmo modelo de embedding da ingestão. Crítico: query e documentos têm que viver no mesmo vector space.
  2. Similarity search: encontra os top-K chunks mais similares comparando o vetor da query com cada vetor no DB.
  3. Retrieval strategy: aqui é onde decisões reais de engenharia acontecem. Três abordagens primárias:
    • Sparse retrieval (BM25): método estatístico que casa keywords exatas via TF-IDF.
    • Dense retrieval (embeddings): busca semântica via vetores. Acha conteúdo conceitualmente relevante mesmo com palavras diferentes.
    • Hybrid search: usa os dois e funde resultados com Reciprocal Rank Fusion (RRF). Documentos que ranqueiam alto nos dois sistemas ganham boost.
  4. Re-ranking: depois de recuperar, um modelo cross-encoder (ex: Cohere Rerank, BGE Reranker) re-pontua os top-K. Cross-encoders processam query + documento como input único, capturando relevância fina que bi-encoders perdem.

Generation phase

Com os chunks mais relevantes em mão, o sistema monta o prompt final:

O modelo gera resposta grounded nos documentos recuperados. Os fatos-chave estão no prompt — o modelo usa-os pra raciocinar em vez de depender da memória de treino.

Citation e attribution: bom RAG sempre mostra de qual documento veio cada afirmação ("Baseado na Seção 3.2 do Manual do Funcionário..."). Essa é uma das maiores vantagens de RAG sobre fine-tuning: transparência.

RAG vs. alternativas — quando usar (e quando não)

RAG vs. Fine-tuning

A comparação mais comum. Nuance importante: não são competidores, são complementares.

Os melhores sistemas em produção fazem os dois: fine-tune pra estilo + RAG pra conhecimento.

RAG vs. Long Context

Por que não jogar tudo na context window enorme? Custo e precisão. RAG retrieva só os 5-20 chunks mais relevantes. Long context enfia tudo e torce pro modelo achar a agulha. RAG é mais barato por query, mais preciso no que encontra, e pode buscar em milhões de documentos sem limite de tokens.

Funcionam bem juntos: primeiro RAG pra trazer os 20 chunks certos, depois long context pra processar todos de uma vez. A pesquisa "lost in the middle" mostra que chunks pequenos e relevantes funcionam melhor que context windows gigantes.

Traditional RAG vs. Agentic RAG — o salto de 2024-2026

Traditional RAG segue o loop linear: query → retrieve → generate → done. Agentic RAG adiciona uma camada de raciocínio que decide:

Frameworks pra agentic RAG: LlamaIndex Agents, LangGraph, Haystack. Self-RAG e CRAG (Corrective RAG) são as duas variantes mais influentes.

Erros comuns que vi em produção

  1. Chunk size errado. Chunks grandes demais (>1.000 tokens) diluem o sinal. Pequenos demais (<100) perdem contexto. Comece com 256-512 tokens com overlap de 50-100.
  2. Não fazer rerank. Top-5 puro de vector search é mediano. Rerank com cross-encoder dobra precisão sem custo proibitivo.
  3. Ignorar metadata filtering. Buscar "política de férias" sem filtrar por company_id retorna lixo cross-tenant.
  4. Não monitorar drift. Quando seus docs mudam, índice envelhece. Reembedding agendado ou triggered por evento é obrigatório.
  5. Pular eval. "Pareceu bom no demo" não vale. Use Ragas, TruLens ou golden test set custom pra medir faithfulness, answer relevancy, context precision.

Stack recomendada pra começar

Conclusão

RAG não é trend — é a arquitetura que torna LLMs úteis em domínios reais. Sem ele, você está restrito ao conhecimento congelado do treino e às alucinações que vêm junto. Com ele, seus dados ficam no controle, atualizações são instantâneas (basta re-indexar), respostas são rastreáveis, e custo escala com query — não com retraining.

O esqueleto que cobrimos aqui é o ponto de partida. Em produção, você empilha agentic loops, multi-modal retrieval (texto + imagem + tabela), graph RAG, e estratégias de chunking mais sofisticadas. Mas se você não acerta o básico — chunking, embedding consistente entre query e docs, hybrid retrieval, rerank, eval contínuo — nenhuma camada extra salva.