RAG: dar memória e fatos ao modelo

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.

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.

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.