Por que RAG: o problema de conhecimento dos LLMs
O que RAG resolve, quando usar e quando NÃO usar, versus fine-tuning e contexto longo.
5 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. Terminar o áudio ou o vídeo, ou passar no quiz, já conta a aula como concluída.
Todo LLM tem uma data de corte e nunca viu seus dados internos, e quando não sabe a resposta, ele inventa uma com confiança. RAG (Retrieval-Augmented Generation) resolve exatamente isso: antes de gerar, o modelo recupera os trechos certos e os usa como base. Este curso mostra como fazer isso de forma confiável, barata e observável na AWS.
O problema: o que o LLM não sabe, e o que ele faz quando não sabe
Um LLM é treinado em um snapshot do mundo. Depois disso, ele congela. Não sabe o que aconteceu ontem, não conhece a sua documentação interna, não leu o contrato que você assinou na semana passada.
Mas o problema maior não é o que ele não sabe. É o que ele faz quando não sabe: ele preenche a lacuna com texto plausível. Isso se chama alucinação, e não é um bug que vai ser corrigido numa próxima versão. É uma consequência direta de como modelos de linguagem funcionam: eles sempre produzem o token mais provável dado o contexto, independentemente de ser verdade.
Em produção, isso é crítico. Um chatbot de suporte que inventa políticas de reembolso. Um assistente jurídico que cita jurisprudência inexistente. Um copiloto de código que referencia uma API que não existe. O dano não vem do modelo ser "burro", vem do modelo ser convincente mesmo quando está errado.
A solução não é treinar mais. É mudar a arquitetura: em vez de pedir ao modelo que lembre, você entrega a ele o contexto relevante no momento da pergunta. Isso é RAG.
O que RAG faz: a ideia central em três passos
RAG é simples na essência. Quando o usuário faz uma pergunta, o sistema não vai direto ao LLM. Ele primeiro busca os trechos de texto mais relevantes em uma base de conhecimento, documentos, wikis, contratos, tickets, o que for. Depois injeta esses trechos no prompt, junto com a pergunta. Só então o LLM gera a resposta.
O resultado é uma resposta fundamentada: o modelo não está lembrando, está lendo. E como você sabe exatamente quais trechos foram usados, a resposta é rastreável, você pode mostrar as fontes, auditar o raciocínio, detectar quando o modelo extrapolou além do que foi fornecido.
Três propriedades que isso garante:
- Atualizável sem retreinar: adicione um documento novo à base e o sistema já sabe no próximo query.
- Rastreável: cada resposta tem uma trilha de evidências. Isso é ouro em contextos regulados.
- Controlável: você decide o que entra na base. O modelo só pode usar o que você autorizou.
O diagrama abaixo mostra o fluxo completo, da pergunta do usuário até a resposta com fontes. As próximas aulas detalham cada etapa.
Fluxo RAG: da pergunta à resposta fundamentada
Dois momentos distintos: ingestão (offline) e consulta (online). Na ingestão, documentos são fragmentados, transformados em vetores e armazenados. Na consulta, a pergunta do usuário percorre o mesmo caminho e recupera os trechos mais relevantes antes de chegar ao LLM.
- Documentos · S3, wikis, PDFs
- Chunking · fragmentar texto
- Embedding Model · texto → vetor
- Vector Store · OpenSearch / FAISS
- Usuário · pergunta
- Embedding Model · pergunta → vetor
- Retriever · busca top-k chunks
- Prompt Builder · pergunta + chunks
- LLM · Bedrock / Claude
- Resposta · com fontes citadas
RAG vs fine-tuning vs contexto longo: quando usar cada um
Essa é a pergunta que mais recebo de arquitetos. E a resposta honesta é: depende do que você está tentando resolver.
Fine-tuning ensina o modelo a se comportar diferente, seguir um estilo, adotar um tom, entender jargão do domínio. Ele não é bom para injetar fatos novos. Se você treina o modelo com os seus documentos internos, ele vai "absorver" aquele conhecimento de forma difusa, sem garantia de fidelidade. E quando os documentos mudarem, você retreina. Caro e lento.
Contexto longo (janelas de 128k, 200k tokens) parece resolver tudo: joga o documento inteiro no prompt. Funciona bem para documentos únicos e tarefas de análise pontual. Mas não escala: custo cresce linearmente com o tamanho do contexto, latência aumenta, e modelos degradam em qualidade quando o contexto fica muito cheio, o famoso "lost in the middle".
RAG é a escolha certa quando você tem uma base de conhecimento grande, dinâmica ou privada, e precisa de respostas rastreáveis. Você recupera apenas o que é relevante para aquela pergunta específica, contexto cirúrgico, não contexto total.
Na prática, os três podem coexistir: fine-tuning para comportamento, RAG para conhecimento, contexto longo para análise de documentos individuais. O exercício a seguir vai ajudar a fixar quando cada abordagem faz sentido.
RAG × fine-tuning × contexto longo
Toque num conceito e depois na definição.
Na prática, o maior erro que vejo é times que tentam usar RAG para ensinar o modelo a escrever no tom da empresa, ou fine-tuning para fazer o modelo 'lembrar' de documentos técnicos. Nenhum dos dois funciona bem fora do seu propósito. RAG é sobre conhecimento recuperável e rastreável. Fine-tuning é sobre comportamento e estilo. Quando você confunde os dois, gasta dinheiro e ainda assim tem alucinações. Comece sempre pela pergunta: 'o que eu preciso mudar, o que o modelo sabe ou como ele age?'
O que você leva desta aula
Dúvidas frequentes
RAG elimina completamente as alucinações?
Não. RAG reduz alucinações ao fornecer contexto factual, mas o modelo ainda pode extrapolar além dos trechos fornecidos ou combinar informações de forma incorreta. Por isso o curso dedica uma aula inteira a avaliação e guardrails.
Preciso de GPU para rodar RAG em produção?
Não necessariamente. Na AWS, você pode usar o Amazon Bedrock para embeddings e geração via API, sem gerenciar infraestrutura de GPU. O custo é por token, não por instância. Veremos isso em detalhes nas aulas de Knowledge Bases e custos.
Qual é a diferença entre RAG e busca semântica?
Busca semântica é a etapa de recuperação dentro do RAG, ela encontra os trechos relevantes. RAG é o pipeline completo: recuperar + injetar no contexto + gerar uma resposta em linguagem natural. Sem a etapa de geração, você tem busca. Com ela, você tem RAG.