Capítulo 9 — RAG: costurando informação fresca no contexto

Nono post do passeio capítulo a capítulo pelo LLM Primer I: How Generative AI Works. O caso mais comum de uso de ferramentas, em detalhe.

O problema que o RAG resolve

RAG — Retrieval-Augmented Generation, geração com recuperação — resolve algo bem específico. Trazer, do lado de fora, informação que o modelo não viu durante o treinamento, e injetar essa informação no contexto antes de o modelo responder.

Por que pesa tanto? Porque duas das fraquezas do capítulo 5 — lacuna temporal e oscilação factual — nascem do fato de que o modelo está preso ao que aprendeu. Tentar consertar isso por dentro do modelo é caro e frágil. Já alimentar o contexto, a cada nova chamada, com a informação relevante extraída de uma base externa, é muito mais barato e muito mais robusto.

Em uma frase: RAG não muda o modelo. Adiciona ao contexto. Essa simplicidade — poder atualizar a fonte a cada chamada, mantendo o modelo intacto — é a maior força do padrão.

Como uma chamada de RAG roda, passo a passo

Olhada um passo de cada vez, uma chamada de RAG não tem mistério.

1. Chega a pergunta do usuário. "Qual é a política de devolução da nossa empresa?", por exemplo.

2. A pergunta vira embedding. Voltamos ao embedding do capítulo 3 — a frase é convertida em vetor com algumas centenas de dimensões.

3. Busca vetorial. Entre os trechos já indexados — manuais, políticas, documentação interna — encontram-se os mais próximos do embedding da pergunta. "Próximo" aqui é proximidade semântica, não literal.

4. O recuperado entra no contexto. Os trechos achados são colados no contexto do modelo, prefaciados por algo como "responda com base nestes trechos".

5. O modelo gera em cima. A partir daí, o modelo combina o que aprendeu no treinamento com o que acabou de receber e produz a resposta.

O que separa RAG bom de RAG ruim

Montar a primeira versão é fácil. Fazê-la valer a pena, nem tanto. O livro trata, com franqueza, do que separa um RAG decente de um RAG que escala.

O corte (chunking). Como dividir os documentos define metade do efeito. Pedaços curtos demais perdem contexto; longos demais embaçam a busca. Idealmente, cada pedaço fecha em si — uma seção, um parágrafo coerente, uma resposta inteira.

A escolha do embedding. Não existe um modelo de embedding único, ideal. Domínios — médico, jurídico, código — têm embeddings que pegam o vocabulário deles com mais precisão. Escolher direito é metade do caminho.

Reranqueamento. Antes de mandar para o modelo, fazer um segundo passo, mais caro e mais preciso, sobre o conjunto inicial — para reordenar e separar o que mais importa.

Grounding. Forçar a resposta a se manter dentro do que foi recuperado — por exemplo, citando a fonte de cada afirmação. Esse hábito, simples, costuma puxar para baixo a taxa de alucinação.

Vale lembrar: RAG ruim costuma parecer assim — "a busca traz resultado, mas o modelo responde como se não tivesse visto". RAG bom é busca afiada, reranqueamento sensato e grounding firme — costurados de modo que a resposta nasça da fonte.

Os limites — também honestamente

Fama exagerada cerca RAG. Vale calibrar. RAG complementa o modelo, mas não altera a forma como ele raciocina. Recuperação ruim leva a resposta confiante e errada. Dá pra mitigar com camadas — múltipla recuperação, validação cruzada, controle de qualidade da indexação — mas a fonte e o modelo precisam andar juntos.

O fio do Capítulo 9

O que fica do capítulo: RAG é, hoje, talvez a forma mais barata e mais efetiva de cobrir a lacuna factual e temporal sem trocar de modelo. O mesmo modelo, com fontes atualizadas, resolve problemas que antes pareciam pedir um treinamento novo.

Amanhã — Capítulo 10: Multimodal — para além do texto. Expandimos o escopo. Como o mesmo transformer passa a aceitar imagens e áudio, e o que muda — e o que continua igual — quando isso acontece.

Quer o quadro inteiro? O livro abre cada etapa do RAG e mostra como ajustar cada uma para o seu caso — com diagramas. Ver 『LLM Primer I』 na Amazon →