RAG: dar memória e fatos ao modelo
Retrieval-Augmented Generation explicado de ponta a ponta: quando usar e como arquitetar.
6 min de leitura
Escolha como aprender
— combine como quiserDica: o vídeo é um resumo visual rápido — o áudio e o texto trazem a aula completa.
Um LLM sabe muito sobre o mundo — até a data em que foi treinado. Ele não sabe nada sobre seus documentos internos, suas políticas atualizadas de ontem ou o ticket de suporte aberto agora. RAG (Retrieval-Augmented Generation) resolve exatamente isso: em vez de treinar o modelo com seus dados, você recupera os trechos relevantes no momento da pergunta e os injeta no contexto antes de gerar a resposta.
O problema que RAG resolve
LLMs têm dois limites fundamentais que você precisa entender antes de desenhar qualquer sistema.
Limite de conhecimento: o modelo foi treinado em um corpus fixo. Tudo que aconteceu depois — ou que nunca foi público — é invisível para ele. Se você perguntar sobre a versão 3.2 do seu produto interno, ele vai inventar uma resposta plausível. Isso é alucinação por falta de fato.
Limite de contexto: mesmo que você queira colar todos os seus documentos no prompt, a janela de contexto tem tamanho finito. Você não pode jogar 50 mil páginas de documentação numa única chamada — e mesmo que pudesse, o custo e a latência seriam proibitivos.
RAG ataca os dois problemas de uma vez. Em vez de dar tudo ao modelo, você encontra o que é relevante para aquela pergunta específica e entrega só isso. O modelo recebe contexto cirúrgico, com fatos reais, e gera uma resposta fundamentada — não uma confabulação.
Na aula 04 você viu como embeddings transformam texto em vetores e como a busca semântica encontra trechos similares em significado, não só em palavras. RAG é a aplicação direta disso: o embedding é o motor de recuperação.
Pipeline RAG: ingestão e consulta
Dois fluxos independentes: ingestão (offline, prepara os dados) e consulta (online, responde ao usuário). O vector store é o ponto de encontro entre eles.
- Documentos · PDFs, wikis, DBs
- Chunking · divisão em trechos
- Embedding Model · texto → vetor
- Vector Store · vetores + metadados
- Usuário · pergunta
- Embedding Model · pergunta → vetor
- Retriever · top-k chunks
- Context Builder · monta o prompt
- LLM · gera resposta
- Resposta · com citações
O pipeline em detalhe: ingestão e consulta
RAG tem dois fluxos distintos. Confundi-los é uma das primeiras armadilhas.
Ingestão (offline): você pega seus documentos brutos, divide em pedaços menores (chunks), gera um embedding para cada chunk e armazena os vetores num vector store junto com metadados (fonte, página, data). Esse processo roda uma vez — ou de forma incremental quando os documentos mudam. O resultado é um índice semântico dos seus dados.
Consulta (online): quando o usuário faz uma pergunta, você gera o embedding da pergunta usando o mesmo modelo de embedding da ingestão — isso é crítico. Depois, busca os top-k chunks mais próximos no vector store (similaridade por cosseno ou produto interno). Com esses trechos em mãos, você monta o prompt: instrução do sistema + contexto recuperado + pergunta. O LLM recebe tudo isso e gera uma resposta que pode citar as fontes.
Um detalhe importante: o modelo de embedding e o LLM são componentes separados. Você pode usar Amazon Titan Embeddings para indexar e Claude Sonnet para gerar. Eles têm papéis diferentes — o embedding encontra, o LLM raciocina.
Na AWS, o Bedrock Knowledge Bases (que você vai ver em detalhes no Módulo 4) gerencia esse pipeline inteiro: ingestão automática, chunking configurável, vector store gerenciado e retrieval integrado. Mas entender o pipeline manualmente é o que te permite depurar quando algo dá errado.
Na prática, a qualidade do RAG depende 80% da qualidade da ingestão — não do LLM. Se os chunks são grandes demais, o retriever traz ruído. Se são pequenos demais, perdem contexto. Se os metadados estão errados, você não consegue filtrar. Já vi sistemas de RAG que funcionavam mal não por causa do modelo, mas porque os PDFs eram scans sem OCR. O LLM só pode raciocinar sobre o que você entregou a ele. Lixo entra, lixo sai — com uma resposta muito bem escrita.
RAG, fine-tuning ou só prompt? A decisão certa
Essa é a pergunta que todo arquiteto enfrenta. A resposta depende do que você quer resolver.
Use RAG quando: seus dados mudam com frequência, são privados/proprietários, ou você precisa de citações rastreáveis. RAG é dinâmico — você atualiza o índice sem retreinar nada. É também mais barato e mais rápido de colocar em produção.
Use fine-tuning quando: você quer mudar o comportamento ou o estilo do modelo — não injetar fatos. Fine-tuning ensina o modelo a responder de um jeito específico, usar um formato proprietário, ou dominar um jargão técnico. Não é bom para injetar conhecimento factual que muda.
Use só prompt quando: o conhecimento cabe no contexto, é estável, e você não tem volume de dados que justifique infraestrutura de indexação. Para muitos casos de uso, um prompt bem construído com algumas regras de negócio já resolve.
Na prática, RAG e fine-tuning não são excludentes. Você pode fine-tunar um modelo para ter o estilo certo e usar RAG para dar fatos atuais. Mas comece pelo mais simples: prompt → RAG → fine-tuning. Cada passo tem custo e complexidade crescentes.
Uma regra de ouro: se a pergunta é "o modelo não sabe esse fato", a resposta é RAG. Se a pergunta é "o modelo não se comporta do jeito que eu quero", a resposta pode ser fine-tuning.
Ordene o pipeline de consulta RAG
Da pergunta do usuário à resposta com fontes.
- 1Gerar o embedding da pergunta do usuário
- 2Montar o contexto com os trechos recuperados
- 3Gerar a resposta com o LLM, citando as fontes
- 4Buscar os trechos mais similares no vector store
RAG vs Fine-tuning vs Prompt
| Critério | Só Prompt | RAG | Fine-tuning | |
|---|---|---|---|---|
| Dados privados/atuais | ❌ Não | ✅ Sim | ⚠️ Snapshot fixo | — |
| Custo de implementação | Baixo | Médio | Alto | — |
| Citações rastreáveis | ❌ | ✅ | ❌ | — |
| Mudar comportamento/estilo | ⚠️ Parcial | ❌ Não | ✅ Sim | — |
| Atualização de dados | Imediata | Re-indexar | Retreinar | — |
Armadilhas comuns em RAG
Perguntas frequentes sobre RAG
Quantos chunks devo recuperar (top-k)?
Depende do tamanho dos chunks e da janela de contexto do modelo. Um ponto de partida razoável é top-3 a top-5 com chunks de 300-500 tokens. Mais do que isso começa a diluir o contexto e aumenta custo. Avalie com evals (aula 09).
RAG elimina alucinação?
Reduz significativamente para perguntas cobertas pelo índice, mas não elimina. O LLM ainda pode ignorar o contexto ou misturar informações. Guardrails e evals (aulas 09 e 10) são complementares.
Qual vector store usar?
Na AWS, o Bedrock Knowledge Bases gerencia isso por você (OpenSearch Serverless por baixo). Para controle próprio: pgvector no RDS/Aurora é ótimo para quem já usa PostgreSQL. Para escala maior, OpenSearch ou um serviço dedicado. O critério principal é latência de busca e custo operacional.
Preciso de RAG se meu documento cabe no contexto?
Não necessariamente. Se o documento é pequeno, estável e você tem poucos usuários, jogar tudo no prompt pode ser mais simples. RAG vale a pena quando o volume de dados é grande, os documentos mudam, ou o custo de tokens por chamada começa a pesar.
RAG é a fundação da maioria dos sistemas de IA corporativos
Se você vai construir um único padrão de IA aplicada, que seja RAG. Ele resolve o problema mais comum — o modelo não sabe dos seus dados — sem o custo e a rigidez do fine-tuning. Mas RAG bem feito é engenharia séria: chunking bem calibrado, modelo de embedding consistente, retriever avaliado, metadados ricos para filtragem. Na próxima aula, você vai ver como o modelo pode ir além do contexto estático e chamar ferramentas externas em tempo real — o que abre um nível novo de capacidade.
Checagem rápida
1. Qual problema o RAG resolve melhor?