Por que RAG: o problema de conhecimento dos LLMs

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.

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.

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.