RAG

O que é RAG?

RAG é a sigla para Retrieval-Augmented Generation, expressão geralmente traduzida como Geração Aumentada por Recuperação. É uma arquitetura que combina um sistema de recuperação de informação com um modelo generativo. Antes de produzir a resposta, a aplicação busca conhecimento externo relevante e o fornece ao modelo como contexto.

A ideia resolve uma limitação fundamental dos LLMs. O modelo possui conhecimento paramétrico adquirido durante treinamento, mas não conhece automaticamente documentos privados, mudanças ocorridas depois do treinamento, dados de uma empresa ou qualquer informação que esteja fora do contexto disponível.

RAG cria uma ponte entre esses dois mundos. O LLM continua responsável por interpretar instruções e gerar linguagem, enquanto a camada de recuperação procura fatos, documentos ou registros que podem fundamentar a resposta.

O termo ganhou projeção a partir do trabalho Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, de Patrick Lewis e coautores, publicado em 2020. O artigo combinava memória paramétrica de um modelo pré-treinado com memória não paramétrica recuperada de um índice externo.

RAG não significa treinar a IA com seus documentos

Essa é uma das confusões mais comuns. Quando uma empresa conecta seus contratos, manuais ou projetos a um sistema RAG, esses documentos não precisam ser incorporados aos pesos do LLM.

A informação continua armazenada externamente. Quando uma pergunta é feita, o sistema procura apenas o material considerado relevante, inclui esse conteúdo no contexto e pede ao modelo que responda com base nele.

Isso é diferente de fine-tuning. Fine-tuning modifica parâmetros de um modelo por meio de treinamento adicional. RAG modifica o contexto de cada execução. A distinção é importante porque documentos empresariais mudam com frequência e podem precisar de regras de acesso que seriam difíceis de administrar se o conhecimento estivesse simplesmente incorporado aos pesos.

Em termos simples: fine-tuning muda o modelo; RAG muda a informação que o modelo recebe antes de responder.

Como funciona um sistema RAG?

Uma implementação comum possui duas fases: preparação da base e execução da consulta. Na preparação, documentos são coletados, limpos e divididos em trechos menores. Esses trechos podem receber embeddings e ser armazenados em um índice ou banco vetorial junto com metadados como data, autor, projeto, categoria e permissões.

Quando chega uma pergunta, o sistema prepara a consulta e procura os conteúdos mais relevantes. A busca pode ser semântica, lexical, híbrida ou até uma consulta estruturada em banco de dados. Os melhores resultados são selecionados e inseridos no contexto do LLM.

O modelo recebe então a pergunta original, as instruções da aplicação e o material recuperado. Sua tarefa é produzir uma resposta que utilize essas evidências.

A documentação do Google resume o processo em três verbos: retrieve, augment e generate. Recuperar informação relevante, aumentar o prompt com essa informação e gerar uma resposta baseada no contexto ampliado.

O papel de embeddings, chunking e bancos vetoriais

Embeddings são frequentemente usados para transformar perguntas e trechos de documentos em vetores que podem ser comparados por similaridade semântica. Isso permite encontrar um trecho relevante mesmo quando ele não contém as mesmas palavras da pergunta.

Antes dessa etapa, documentos extensos costumam ser divididos em chunks. O tamanho e a forma desses trechos importam. Um chunk muito pequeno pode perder contexto; um trecho enorme pode misturar assuntos e prejudicar a recuperação.

Bancos vetoriais ou índices vetoriais ajudam a realizar busca eficiente sobre grandes coleções de embeddings. Mas RAG não exige que toda recuperação seja vetorial. Pesquisa por palavra-chave, filtros, SQL, grafos, APIs e mecanismos híbridos também podem fazer parte do pipeline.

O sistema de recuperação deve ser escolhido a partir da natureza da informação e das perguntas reais dos usuários, não por moda tecnológica.

Busca híbrida, reranking e qualidade da recuperação

Uma busca apenas semântica pode ser excelente para perguntas conceituais e ruim para códigos, versões, nomes exatos e identificadores. Por isso, arquiteturas de produção frequentemente combinam busca vetorial com busca lexical.

Depois da primeira recuperação, um reranker pode reavaliar os resultados e ordenar novamente os trechos segundo sua relevância para a pergunta. Essa etapa pode melhorar significativamente a qualidade do contexto enviado ao LLM.

Sistemas também podem reescrever a consulta, decompor perguntas complexas em subconsultas, aplicar filtros por data ou projeto e recuperar fontes de tipos diferentes.

Esse ponto é decisivo: um excelente LLM não compensa automaticamente uma recuperação ruim. Se o sistema encontra o documento errado, a geração pode ser fluente e ainda assim estar fundamentada na evidência errada.

Um exemplo prático

Imagine uma incorporadora com milhares de arquivos de projetos, contratos, memoriais, atas, relatórios e manuais. Um diretor pergunta: 'quais empreendimentos tiveram alteração de fachada depois da aprovação inicial e quais foram os motivos registrados?'

O LLM isolado não conhece esse histórico. Em um sistema RAG, a consulta é usada para procurar documentos relevantes. O sistema pode recuperar atas, revisões de projeto e relatórios associados aos empreendimentos, filtrar por tipo de documento e fornecer os trechos ao modelo.

O LLM organiza as evidências, compara os casos e pode apresentar uma resposta com links ou citações para os documentos originais.

O valor não está apenas em conversar com arquivos. Está em transformar uma base desestruturada em uma camada de conhecimento consultável em linguagem natural.

Onde RAG aparece na prática?

Em arquitetura, engenharia e construção, RAG pode permitir consultas sobre normas, projetos anteriores, especificações, materiais, contratos e decisões registradas em atas. Um escritório consegue recuperar seu próprio repertório sem esperar que um modelo público já conheça esse conteúdo.

No varejo, assistentes podem consultar catálogo, políticas de troca, manuais, estoque, treinamento e características técnicas de produtos. Em turismo e hospitality, um concierge pode combinar informações do hotel, agenda local, serviços e políticas atualizadas.

Em gastronomia, grupos podem consultar fichas técnicas, procedimentos, fornecedores e manuais operacionais. Em educação, sistemas podem responder com base em bibliotecas e materiais oficiais. Em saúde, usos precisam considerar controles rigorosos de acesso, procedência e validação.

Na advocacia e em serviços profissionais, RAG pode ajudar a localizar cláusulas, pareceres, precedentes internos, políticas e documentos de clientes, desde que a arquitetura respeite sigilo e permissões.

RAG, long context e fine-tuning

Uma janela de contexto grande permite enviar mais material diretamente ao LLM. Isso não elimina automaticamente RAG. Se existem milhões de páginas, ainda é preciso decidir quais são relevantes para cada pergunta. Long context aumenta capacidade; RAG melhora seleção.

Fine-tuning atende outro tipo de problema. Pode ser útil para adaptar estilo, comportamento, formato ou desempenho em uma tarefa. Não é necessariamente a melhor estratégia para manter uma base de conhecimento que muda todos os dias.

Em muitos sistemas, as técnicas são complementares. Um modelo pode ter sido fine-tuned para determinado comportamento e ainda usar RAG para obter fatos atualizados, dentro de uma janela de contexto extensa.

RAG e agentes de IA

RAG também pode funcionar como uma ferramenta dentro de um agente. Em vez de executar uma única busca fixa, o agente pode decidir quando pesquisar, reformular uma consulta, consultar fontes diferentes, analisar resultados e buscar novamente antes de responder.

Isso aproxima RAG de arquiteturas chamadas agentic RAG. A recuperação deixa de ser apenas uma etapa linear e passa a fazer parte de um ciclo de decisão.

Mesmo assim, a função essencial continua a mesma: conectar a geração a conhecimento externo recuperado dinamicamente.

Segurança e controle de acesso

Conectar um LLM a documentos internos cria uma responsabilidade importante: a recuperação precisa respeitar exatamente as permissões do usuário. Um assistente não pode recuperar um contrato confidencial apenas porque semanticamente ele é relevante para a pergunta.

Por isso, metadados, autenticação, autorização e filtros precisam fazer parte do desenho da camada de recuperação. Segurança não pode ser aplicada apenas depois que o documento já foi enviado ao modelo.

Também é necessário considerar prompt injection em documentos, vazamento de informação e registros de auditoria. Em aplicações empresariais, saber qual fonte foi recuperada e por que ela entrou na resposta é parte da governança.

Limitações e erros comuns

RAG não elimina alucinações. Ele aumenta a disponibilidade de evidência, mas o LLM ainda pode interpretar incorretamente, extrapolar ou ignorar parte do contexto. Instruções e avaliações precisam controlar esse comportamento.

Outro erro é presumir que mais documentos recuperados significam mais qualidade. Contexto irrelevante aumenta ruído. Também é possível ter uma base correta e uma estratégia de chunking ruim, um modelo de embedding inadequado ou filtros que escondem o documento certo.

RAG deve ser avaliado em pelo menos duas camadas: qualidade da recuperação e qualidade da resposta. É preciso perguntar se os trechos corretos foram encontrados antes de julgar se o LLM escreveu bem.

Fontes também envelhecem. Uma política antiga recuperada com alta similaridade continua sendo antiga. Atualização, versionamento e validade dos documentos são parte do produto.

O que muda na prática?

RAG permite que organizações separem capacidade de linguagem e conhecimento proprietário. O modelo pode ser substituído ou atualizado sem que todo o acervo precise ser treinado novamente. A base pode mudar diariamente e continuar sendo consultada.

Isso transforma arquivos, intranets, manuais e bases operacionais em uma camada de conhecimento potencialmente acessível por linguagem natural.

O ganho real não é fazer o LLM 'saber tudo'. É construir um sistema capaz de encontrar a evidência certa, no momento certo, para que o modelo trabalhe sobre informação relevante e verificável.