O que é RAG (Retrieval-Augmented Generation): o guia claro de 2026

Perguntas ao ChatGPT pela política de férias da tua empresa e ele solta-te uma resposta perfeitamente redigida... e completamente inventada. O modelo não faz ideia da tua empresa, mas não o diz: preenche o vazio com algo plausível. A isto chamamos alucinação, e é o maior problema dos modelos de linguagem quando os tiras da sua zona de conforto.

O RAG é a solução que se tornou padrão para o resolver. Não muda o modelo: muda-lhe os trabalhos de casa. Em vez de lhe pedir que responda de memória, dás-lhe os apontamentos abertos à frente. Vamos vê-lo sem jargão.

Que problema resolve o RAG

Um modelo de linguagem aprende durante o treino e depois "congela". A partir daí arrasta três limitações que nenhum prompt elegante conserta:

• Não conhece os teus dados. Nunca viu a tua wiki interna, o teu catálogo de produtos nem os contratos dos teus clientes. É um génio que nunca pisou o teu escritório.
• Tem data de validade. O seu conhecimento para no dia em que terminou o seu treino. O que aconteceu depois, para ele, não existe.
• Quando não sabe, inventa. Em vez de dizer "não sei", produz algo que soa bem. Para um texto criativo tanto faz; para uma resposta legal ou médica é perigoso.

O RAG ataca as três de uma só vez. Ligas-lhe uma base de conhecimento externa —os teus documentos, a tua base de dados, os teus PDF— e o sistema recupera o relevante no momento de responder. O modelo deixa de puxar da memória e começa a puxar de provas. A consequência direta: menos alucinações, dados sempre atualizáveis (mudas o documento, não o modelo) e a possibilidade de citar a fonte de cada resposta.

A melhor analogia é o exame. Um LLM normal faz o exame de memória. Um LLM com RAG faz o mesmo exame, mas com o livro aberto e com um buscador que lhe encontra a página exata antes de escrever cada resposta.

Como funciona o fluxo do RAG

Aqui está o coração de tudo. Um sistema RAG não é magia: são quatro passos encadeados, e entendê-los dá-te 80% do conceito.

Os dois primeiros passos (ingestão e embeddings) ocorrem uma vez, quando preparas a tua base de conhecimento. Os dois últimos (retrieval e geração) ocorrem cada vez que alguém pergunta. Convém tê-lo claro: indexas uma vez, consultas muitas. Vejamos cada peça com calma.

Os componentes, um a um

Chunking: trocear bem

Não podes meter ao modelo um manual de 300 páginas de uma vez: não cabe na sua janela de contexto e, mesmo que coubesse, diluiria o sinal num mar de ruído. Por isso o primeiro passo é trocear os documentos em fragmentos (chunks).

O tamanho do pedaço é uma decisão crítica e pouco glamorosa. Pedaços demasiado grandes metem informação irrelevante em cada resposta; pedaços demasiado pequenos partem uma ideia ao meio e perdem o sentido. A boa prática de 2026 é trocear respeitando a estrutura do documento —por secções, parágrafos ou cabeçalhos— em vez de cortar às cegas a cada X caracteres. Um bom chunking costuma melhorar mais os resultados do que pagar pelo modelo mais caro.

Embeddings: converter significado em números

Um embedding é a tradução de um texto para uma lista de números (um vetor) que captura o seu significado. A graça é que textos com sentido parecido acabam com vetores parecidos, mesmo que não partilhem uma única palavra. "Como cancelo a minha subscrição" e "dar baixa da conta" caem perto nesse espaço matemático.

Isto é o que permite procurar por conceito e não por coincidência literal de termos, que é o grande salto face ao buscador de sempre. Cada fragmento da tua base de conhecimento converte-se num embedding usando um modelo especializado (da OpenAI, da Cohere ou um open source que corras tu).

Base de dados vetorial: o armazém com buscador semântico

Todos esses vetores há que guardá-los nalgum sítio que saiba procurá-los depressa. Para isso existe a base de dados vetorial: um armazém otimizado para encontrar, entre milhões de vetores, os mais próximos de um dado usando métricas de distância como a similaridade do cosseno.

As opções habituais em 2026: Pinecone (gerida, sem dores de cabeça), Qdrant e Weaviate (open source potentes), Chroma (a mais simples para começar e prototipar) e pgvector (se já usas PostgreSQL e não queres mais uma peça). Para aprender, Chroma em local chega e sobra; para produção à escala costuma saltar-se para uma gerida ou para Qdrant.

Retrieval: encontrar o relevante

Chega a pergunta do utilizador. O sistema converte-a num embedding com o mesmo modelo e pede à base vetorial os top-k fragmentos mais próximos em significado (tipicamente entre 3 e 8). Isso é o retrieval.

Geração: redigir com o contexto à frente

Por último, os fragmentos recuperados injetam-se no prompt junto à pergunta original, com uma instrução do tipo "responde usando só este contexto e, se não estiver aqui, di-lo". O modelo lê esse pacote e redige uma resposta fundamentada nos teus dados, não na sua memória. É aqui que lhe podes ainda pedir que cite de que fragmento tirou cada afirmação, que é o que torna o RAG auditável.

Responde à pergunta do utilizador usando EXCLUSIVAMENTE o contexto abaixo.
Se a resposta não estiver no contexto, diz "Não tenho essa informação" e não a inventes.
Cita entre parênteses retos o número do fragmento que sustenta cada afirmação.

Contexto:
{fragmentos_recuperados}

Pergunta:
{pergunta_do_utilizador}

RAG vs. fine-tuning: quando cada um

É a confusão mais comum. As pessoas pensam que, para que um modelo "saiba" da sua empresa, há que retreiná-lo (fine-tuning). Quase nunca é assim. São duas ferramentas para problemas diferentes.

A regra que resume tudo: o conhecimento que muda vai na recuperação; o comportamento estável vai nos pesos. O RAG injeta-te factos frescos sem tocar no modelo; o fine-tuning molda como responde, não o que sabe.

E se precisas das duas coisas? Pois combina-las, que é justamente o padrão de produção em 2026: um fine-tuning ligeiro (um adaptador LoRA fino sobre um bom modelo base) para fixar a voz e o formato, acompanhado de RAG para o conhecimento que muda. A sequência sensata para lá chegar é: primeiro espreme o prompt, depois adiciona RAG, e só se for preciso, faz fine-tuning. Não comeces pelo caro.

Ferramentas para montar o teu RAG

Não tens de construir as quatro peças à mão. O ecossistema está maduro:

• Frameworks de orquestração. O LlamaIndex está pensado de raiz para RAG: ingestão, indexação e recuperação com pouco código e muito boa precisão. O LangChain é mais generalista —trata o RAG como mais uma peça de um sistema maior— e brilha quando montas fluxos complexos ou agentes. Um padrão habitual em 2026 é usar LlamaIndex para a recuperação e LangGraph para orquestrar o agente que a usa.
• Modelos de embeddings. Da OpenAI e da Cohere se queres algo gerido e de qualidade; modelos open source se precisas de correr em local por privacidade ou custo.
• Bases vetoriais. Pinecone, Qdrant, Weaviate, Chroma ou pgvector, conforme o visto acima.
• Observabilidade. Ferramentas como Langfuse ou LangSmith para ver que fragmentos se recuperaram e por que falhou uma resposta. Assim que o teu RAG é sério, isto deixa de ser opcional.

Se só queres entendê-lo mexendo-lhe, monta o mínimo: LlamaIndex + um modelo de embeddings + Chroma em local, com um punhado dos teus PDF. Numa tarde tens um RAG a funcionar contra os teus próprios documentos.

Erros típicos (e como evitá-los)

• Culpar o modelo quando falha a recuperação. Se a resposta é má, o primeiro não é mudar de LLM: é olhar que fragmentos se recuperaram. Quase sempre o problema está aí.
• Chunking à bruta. Cortar a cada 500 caracteres sem olhar à estrutura parte ideias ao meio. Troceia por secções e testa vários tamanhos.
• Confiar só na busca semântica. Para nomes próprios, códigos ou termos exatos, a busca por significado falha. A busca híbrida (semântica + palavras-chave) resolve-o.
• Não dizer ao modelo que pode não saber. Se não lhe dás permissão explícita para responder "não está no contexto", volta a inventar. A instrução anti-alucinação é obrigatória.
• Recuperar demasiado ou demasiado pouco. Meter 30 fragmentos dilui o sinal e dispara o custo; meter 1 fica curto. Ajusta o top-k e mede-o.

Para quem é o RAG?

O RAG não é um capricho académico: é a forma mais direta e barata de fazer com que uma IA fale do que é teu com dados reais.

Interessa-te se: queres um chatbot que responda sobre a tua documentação, os teus produtos ou a tua base de conhecimento; lidas com informação que muda e não queres retreinar nada de cada vez; precisas de respostas citáveis e auditáveis; ou estás a construir um agente que deve consultar fontes antes de agir.

Talvez não precises se: o teu problema é de estilo ou formato e não de conhecimento (isso é fine-tuning), ou se o que pedes cabe de sobra no conhecimento geral do modelo e não requer dados privados nem frescos.

A pergunta honesta não é "RAG ou fine-tuning?", porque quase nunca é um contra o outro. A pergunta é "o meu problema é que ao modelo lhe faltam dados, ou que se comporta como não quero?". Se é o primeiro, o RAG é a tua ferramenta, e é das poucas que podes ter a funcionar com os teus documentos esta mesma tarde.