RAG na prática: arquitetando um agente sobre a base de conhecimento da empresa

RAG (Retrieval-Augmented Generation) virou sigla de slide. Mas por trás do buzzword há uma arquitetura simples e poderosa, que resolve o problema mais comum de IA aplicada em empresa: fazer um LLM responder com base no seu conhecimento, não no que ele aprendeu na internet, com fonte verificável e sem re-treinar nada.

O problema que o RAG resolve

Um LLM puro sabe muito sobre o mundo e nada sobre a sua empresa. Pergunte sobre a sua política interna de troca, o seu catálogo, ou o histórico de um cliente, e ele vai inventar uma resposta plausível — alucinar — porque foi treinado para sempre responder, não para dizer "não sei".

Duas saídas erradas aparecem primeiro. Fine-tuning, que é caro, lento e endurece o conhecimento no modelo (você atualiza o conteúdo e precisa re-treinar). E colar tudo no prompt, que estoura o limite de contexto e mistura informação relevante com ruído. RAG é a terceira via, e quase sempre a certa.

Como o RAG funciona

A ideia central: em vez de o modelo saber tudo, ele busca o que precisa no momento da pergunta, e responde só com base no que encontrou.

O fluxo tem duas fases. Na indexação (offline), você quebra os seus documentos em pedaços (chunks), gera um embedding de cada um — um vetor que representa o significado do texto — e guarda esses vetores em um banco vetorial (pgvector, por exemplo). Na consulta (online), a pergunta do usuário também vira embedding, você busca os chunks mais semelhantes por proximidade vetorial, e injeta esses trechos no prompt do LLM junto com a pergunta. O modelo responde ancorado naqueles trechos — e cita de onde tirou.

A diferença prática é enorme: o modelo deixa de adivinhar e passa a citar. Atualizou um documento? Re-indexa só ele, e a próxima resposta já usa o conteúdo novo. Sem re-treino, sem custo de fine-tuning.

O que faz o RAG funcionar de verdade

O fluxo básico cabe num tutorial. O que separa uma demo de um sistema em produção são os detalhes.

Chunking inteligente. Quebrar por número fixo de caracteres parte frases no meio e destrói o sentido. Quebrar por seção, parágrafo ou estrutura lógica do documento preserva o contexto e melhora a recuperação.

Qualidade da recuperação. Se o sistema busca os chunks errados, o modelo responde errado com confiança. Vale medir: para um conjunto de perguntas conhecidas, os trechos certos estão sendo recuperados? Técnicas como re-ranking e busca híbrida (vetorial + palavra-chave) elevam muito a precisão.

Citação de fonte. Em produção, a resposta tem que dizer de onde veio. Isso permite ao usuário verificar e cria confiança — além de ser requisito em setores regulados.

Avaliação (evals). Sem um conjunto de perguntas de teste com respostas esperadas, você não sabe se uma mudança melhorou ou piorou o sistema. Evals transformam "parece melhor" em "accuracy subiu de 78% para 91%".

Quando RAG não é a resposta

RAG brilha quando há uma base de conhecimento textual que muda com frequência e respostas precisam citar fonte. Não é a ferramenta certa para tudo: se a tarefa é cálculo determinístico, consulta estruturada a um banco, ou uma decisão com regras fixas, uma query SQL ou um agente com ferramentas resolve melhor do que recuperação semântica. E se o conhecimento é estável e cabe no contexto, às vezes colar no prompt basta.

O caminho prático

Comece pequeno: uma base de documentos, pgvector, chunking por seção, e um conjunto de 20-30 perguntas de avaliação. Meça a accuracy, ajuste o chunking e a recuperação, adicione re-ranking se precisar. Só então pense em escala — cache de embeddings, atualização incremental do índice, observabilidade das consultas.

RAG não é mágica. É engenharia de recuperação somada a um LLM, feita com critério. Bem arquitetado, transforma o conhecimento espalhado da empresa em um assistente que responde com fonte — e que você controla por inteiro.