O que é RAG? Geração aumentada por recuperação explicada

Um modelo de linguagem de grande dimensão é confiante, fluente e completamente alheio ao seu negócio. Pergunte-lhe sobre os seus preços, os seus manuais internos ou os números do último trimestre e ele responderá com a mesma naturalidade com que responde a tudo o resto; só que não estará correto. O conhecimento que tem está congelado no momento do treino e provém da internet pública, não dos seus sistemas. A geração aumentada por recuperação, ou RAG, é o padrão que fecha essa lacuna: permite que o modelo consulte os seus dados antes de responder.

O RAG tornou-se discretamente a arquitetura predefinida para aplicações empresariais de LLM, e com razão. É a forma mais barata, mais rápida e mais auditável de pôr um modelo a trabalhar sobre conhecimento que nunca viu durante o treino. Este artigo explica o que é de facto o RAG, porque supera as alternativas, como funciona cada fase do pipeline e onde vai parar o verdadeiro esforço de engenharia quando se passa da demonstração.

O que é, de facto, a geração aumentada por recuperação

O RAG é uma ideia simples com muita engenharia por trás. Em vez de depender apenas do que o modelo aprendeu durante o treino, dá-se-lhe uma forma de ir buscar informação relevante a uma fonte autoritativa no momento da pergunta e, depois, responder usando esse contexto recuperado. O modelo continua a fazer o raciocínio e a escrita; os factos vêm de si.

Mecanicamente, coloca-se um sistema de recuperação à frente do modelo. Quando chega uma pergunta, pesquisa-se o seu próprio conteúdo pelas passagens com maior probabilidade de a responder, colam-se essas passagens no prompt e instrui-se o modelo a responder a partir delas. O conhecimento paramétrico do modelo (o que memorizou no treino) passa a ser apoiado por conhecimento não paramétrico (o que recuperou em tempo de execução). Essa separação é o cerne de tudo, e corrige os modos de falha que tornam os LLM em bruto arriscados em produção:

• Alucinação: fundamentado em passagens recuperadas, o modelo tem muito menos margem para inventar. Está a responder a um exame de consulta em vez de recitar de memória.
• Conhecimento desatualizado: o treino de um modelo tem uma data de corte, e tudo o que vem depois é invisível. Atualize os documentos subjacentes e as respostas acompanham, sem retreinar e sem novo deploy.
• Sem proveniência: como sabe exatamente quais as passagens recuperadas, pode devolver citações e deixar os utilizadores verificar as afirmações na fonte. Em trabalho regulado, jurídico ou clínico, essa rastreabilidade é muitas vezes inegociável.
• Controlo de acessos: o conhecimento vive num repositório que possui, por isso pode filtrar a recuperação em função de quem pergunta. Um modelo que memorizou os dados não os consegue esquecer para um utilizador; uma camada de recuperação pode simplesmente não os devolver.

Porquê não retreinar ou afinar o modelo?

Esta é a primeira pergunta de qualquer equipa, por isso vale a pena responder a sério, porque as três abordagens resolvem problemas diferentes.

Retreinar ou continuar o pré-treino de um modelo fundacional com os seus dados é enormemente caro e lento, exige uma equipa de ML séria e orçamento de GPU, e tem de ser repetido sempre que os dados mudam. Para uma base de conhecimento que muda semanalmente, é inviável à partida.

Afinar (fine-tuning) é bastante mais barato, mas ensina ao modelo forma muito melhor do que factos: tom, formato, estilo da casa, como seguir um determinado tipo de instrução. É fraco a injetar conhecimento específico e mutável, e cristaliza o que aprende nos pesos, pelo que uma correção implica outro treino. Pior, afinar sobre um corpus estreito pode fazer o modelo esquecer capacidade geral.

O RAG mantém o conhecimento fora do modelo, onde ele deve estar. Os seus dados permanecem num sistema que controla, pode alterá-los em segundos e pode impor quem tem autorização para ver o quê. Acrescentar um documento é um insert, não um trabalho de treino. Para a maioria dos problemas de “responder a perguntas sobre o nosso próprio conteúdo”, essa é a arquitetura certa.

Não são mutuamente exclusivos. Um padrão de produção comum é afinar um modelo mais pequeno para o comportamento (responder neste formato, citar sempre, recusar com educação em caso de dúvida) e usar RAG para o conhecimento. O fine-tuning molda como o modelo fala; o RAG decide o que ele sabe.

Como funciona o RAG, passo a passo

Nos bastidores, um sistema RAG é um pipeline de recuperação acoplado a um passo de geração. Há uma metade offline que prepara o conhecimento e uma metade online que responde às perguntas. Quatro fases importam.

1. Preparar e indexar a base de conhecimento

Pegue no seu material de origem; documentos, páginas de wiki, tickets, registos de bases de dados, PDF, e divida-o em blocos. A divisão em blocos (chunking) não é mera formalidade: blocos grandes demais diluem a frase relevante em ruído e esgotam o orçamento de tokens; blocos pequenos demais retiram o contexto necessário para os compreender. Divida em fronteiras semânticas como títulos, secções e parágrafos, e não por uma contagem fixa de carateres, mantendo alguma sobreposição entre blocos para que uma frase que atravessa uma fronteira não fique órfã. Leve metadados com cada bloco (fonte, título, autor, data, permissões); vai usá-los depois para filtragem e citações.

Cada bloco passa depois por um modelo de embedding, que converte o seu significado num vetor, uma lista de números posicionada de modo a que textos com significado semelhante fiquem próximos no espaço. Esses vetores vão para uma base de dados vetorial (ou um índice vetorial dentro do seu repositório atual) capaz de responder rapidamente a “quais os blocos mais próximos deste ponto?”, usando um algoritmo de vizinho mais próximo aproximado para se manter rápido sobre milhões de vetores.

2. Recuperar o contexto relevante

Quando um utilizador pergunta algo, gere o embedding da consulta com o mesmo modelo e pesquise no índice os blocos mais próximos; as passagens mais semelhantes em significado, não apenas na formulação. É aqui que os sistemas ingénuos falham em silêncio, por isso a recuperação em produção costuma ir mais longe:

• Pesquisa híbrida combina semelhança vetorial densa com um método de palavras-chave (BM25). Os vetores lidam com paráfrases e sinónimos; a pesquisa por palavras-chave acerta em termos exatos, códigos de produto e nomes raros que os embeddings esbatem.
• Filtragem por metadados restringe a pesquisa à partida (este cliente, documentos posteriores a uma data, apenas conteúdo que este utilizador pode ver), o que é ao mesmo tempo um ganho de relevância e a sua fronteira de controlo de acessos.
• Reordenação (re-ranking) recupera um conjunto amplo de candidatos e depois usa um cross-encoder para pontuar cada um face à consulta e guardar só os melhores. É mais preciso do que a semelhança de primeira passagem, e barato porque corre sobre uma lista curta em vez do corpus inteiro.

3. Aumentar o prompt

Monte as passagens recuperadas no prompt, junto da pergunta do utilizador, com uma instrução de sistema para responder apenas a partir do contexto fornecido e para dizer quando o contexto não contém a resposta. A ordem e o orçamento importam: os modelos prestam mais atenção fiável ao início e ao fim de um contexto longo do que ao meio, por isso coloque as passagens mais fortes onde serão lidas e mantenha o total dentro da janela de contexto, com margem para a resposta. Dê a cada passagem um identificador para o modelo poder citar. Um modelo mínimo:

Responda à pergunta usando apenas o contexto abaixo.
Cite o id da fonte entre parênteses retos após cada afirmação.
Se o contexto não contiver a resposta, diga que não sabe.

Contexto:
[doc-12] {passagem_recuperada_1}
[doc-07] {passagem_recuperada_2}

Pergunta: {pergunta_do_utilizador}

4. Manter a base de conhecimento atual

Um sistema RAG está apenas tão atualizado quanto a sua última indexação. Os documentos mudam, são acrescentados e apagados, por isso volte a gerar embeddings e a reindexar de forma agendada ou, melhor, a cada escrita, e garanta que as eliminações se propagam para o modelo não poder citar um documento que já não existe. Vigie a deriva à medida que o seu modelo de embedding, a estratégia de chunking ou a mistura de conteúdos evoluem; uma reindexação é o momento para voltar a correr o seu conjunto de avaliação e confirmar que a qualidade não caiu.

RAG vs. pesquisa semântica

Por vezes confundem-se as duas, mas estão em camadas diferentes. A pesquisa semântica é a metade da recuperação; a tecnologia que percorre a sua base de conhecimento e devolve passagens por significado em vez de palavras-chave exatas, ordenadas por relevância. Responde a “que passagens se relacionam com esta consulta?” e entrega uma lista.

O RAG usa pesquisa semântica (geralmente em conjunto com pesquisa por palavras-chave) e depois acrescenta o passo de geração por cima, transformando essa lista de passagens numa única resposta escrita, com citações, em linguagem natural. Em suma: a pesquisa semântica encontra; o RAG encontra e depois explica. Uma boa recuperação é o que faz o RAG funcionar, por isso uma camada forte de pesquisa semântica é um pré-requisito, não um concorrente. Se voltarem as passagens erradas, o modelo mais capaz do mundo não tem nada de útil em que se fundamentar, e o resultado é uma resposta errada com toda a confiança.

Onde o RAG compensa, e onde morde

O RAG brilha onde quer que o valor esteja no seu próprio conteúdo: assistentes de conhecimento interno, apoio ao cliente sobre a sua documentação, pesquisa em contratos ou estudos, resposta a perguntas que tem de se manter atual e citar as fontes. Sempre que a resposta honesta é “depende do que dizem os nossos documentos”, o RAG é o encaixe natural.

A ressalva honesta é que o RAG desloca o problema difícil em vez de o eliminar. A qualidade da resposta é limitada pela qualidade da recuperação, e esta depende de trabalho pouco glamoroso:

• Falhas de recuperação são a principal causa de más respostas; o bloco certo nunca foi obtido, por isso nenhuma magia de prompt salva a resposta. Meça a recuperação por si só, com um conjunto rotulado de perguntas e as passagens que as devem responder, e acompanhe o recall antes de tocar no modelo.
• Avaliação tem de ser sistemática. Construa um conjunto de teste de perguntas reais com o comportamento esperado e corra-o a cada mudança, pontuando tanto a recuperação (obtivemos as passagens certas?) como a geração (a resposta estava fundamentada e correta?). Sem isto, está a afinar às cegas.
• Observabilidade significa registar a consulta, os blocos recuperados e a resposta final, para que, quando um utilizador reportar uma má resposta, consiga ver se a culpa foi da recuperação ou da geração.
• Governança é uma vantagem genuína do RAG, mas só se a usar: imponha permissões no momento da recuperação, mantenha um rasto de auditoria através das citações e impeça que blocos sensíveis cheguem sequer a entrar num prompt.
• Custo e latência somam-se; cada pergunta envolve agora uma chamada de embedding, uma pesquisa vetorial, muitas vezes uma reordenação e um prompt maior. Caching, limites sensatos de top-k e o dimensionamento certo do modelo mantêm-no económico à escala.

Uma demo leva uma tarde; um sistema em que se pode confiar à frente de clientes leva engenharia a sério. As equipas que têm sucesso tratam a qualidade da recuperação como uma métrica que monitorizam, não uma caixa que assinalam uma vez.

Conclusão

O RAG é a forma mais fiável de tornar um modelo de linguagem útil sobre dados em que nunca foi treinado, sem o custo de retreinar e com a proveniência que o trabalho regulado e de alto risco exige. Trate-o como um problema de dados primeiro e um problema de modelo depois: acerte no chunking e na recuperação, mantenha a base de conhecimento atual, imponha os acessos na camada de recuperação e meça ambas as metades do pipeline. Faça isso e o modelo passa a ser a parte fácil. Se está a ponderar RAG para os seus próprios dados, é exatamente disto que trata o nosso trabalho em IA e machine learning e engenharia de dados, e teremos todo o gosto em conversar sobre o assunto.