O que é RAG?

A resposta curta

RAG significa geração aumentada por recuperação. Quer dizer: antes de o modelo responder, você vai buscar a informação relevante e entrega isso ao modelo junto com a pergunta. O modelo então responde usando aquele material em vez de depender só do que absorveu no treinamento.

É essa a ideia inteira. Todo o resto é detalhe de engenharia sobre como achar o material certo rápido o bastante e confiável o bastante.

O problema que o RAG resolve

Um modelo de linguagem sabe o que estava nos dados de treino, até uma data de corte, em termos gerais. Ele não conhece sua tabela de preços, sua política publicada terça passada ou o estado de uma conta específica de cliente. Pergunte mesmo assim e ele produz algo plausível, o que é pior do que não produzir nada.

Só existem três formas de dar a um modelo um conhecimento que ele não tem. Colocar no prompt, o que não escala além de certo tamanho. Gravar nos pesos via fine-tuning, o que é lento e envelhece. Ou recuperar no momento da pergunta, que é RAG.

Para qualquer coisa que muda, recuperação ganha. Sua política muda; os pesos do modelo não deveriam ter que mudar junto.

Como o pipeline funciona de verdade

Cinco passos, e cada um é um lugar onde as coisas dão errado. Primeiro, ingestão: você pega seus documentos e divide em pedaços. Segundo, embedding: cada pedaço vira um vetor, uma lista de números que representa o significado dele. Terceiro, armazenamento: esses vetores vão para um banco feito para buscar por similaridade.

Quarto, recuperação: quando chega uma pergunta, ela é convertida da mesma forma, e o banco devolve os pedaços cujos vetores estão mais próximos. Quinto, geração: esses pedaços entram no prompt e o modelo escreve uma resposta ancorada neles.

Repare que o modelo só participa do último passo. Quatro quintos de um sistema RAG é um problema de busca fantasiado de IA.

Chunking e embeddings, sem jargão

Chunking é decidir como cortar seus documentos. Corte pequeno demais e você fica com fragmentos sem contexto, então o modelo vê uma frase sobre uma exceção sem a regra da qual ela é exceção. Corte grande demais e você dilui o sinal, então uma página sobre doze assuntos casa fracamente com uma pergunta sobre um deles.

Embeddings são como a similaridade é medida. Dois textos que significam coisas parecidas acabam com vetores próximos, mesmo sem compartilhar palavra nenhuma. É por isso que um bom sistema consegue casar a pergunta "consigo meu dinheiro de volta" com um documento chamado "política de reembolso".

A maioria dos times ajusta o modelo primeiro e o chunking por último. Deveria ser o contrário.

Onde o RAG quebra em produção

Quase sempre na recuperação, quase nunca na geração. Se o trecho certo chega ao modelo, modelos modernos resumem com precisão. Se o trecho errado chega, ele vai resumir o trecho errado com confiança total.

As falhas que vemos com frequência: o acervo tem três versões da mesma política e ninguém marcou qual é a vigente. A permissão não foi levada para a recuperação, então o sistema entrega um documento que o usuário que perguntou jamais deveria ver. As atualizações são ingeridas de madrugada mas a área assume tempo real. E a cauda longa, onde as perguntas que mais importam são as raras, e as raras recuperam pior.

Mais uma fácil de perder: recuperação que funciona bem com cem documentos degrada silenciosamente com cem mil. Não dá erro. Só fica menos certa, e ninguém percebe sem avaliação.

RAG ou fine-tuning: problemas diferentes

Isso é apresentado como um versus e não é. Fine-tuning muda como o modelo se comporta: formato, tom, aderência a uma estrutura, tratamento de uma tarefa especializada. RAG muda o que o modelo sabe no momento de responder.

Se a sua reclamação é "ele não conhece nossos produtos", isso é RAG. Se é "ele conhece, mas responde no formato errado", isso é fine-tuning ou prompt melhor. Times gastam um trimestre inteiro fazendo fine-tuning num problema de conhecimento e não saem do lugar.

Muitos sistemas maduros usam os dois. Recuperação para os fatos, tuning para o comportamento.

Como avaliar um sistema RAG

Avalie as duas metades separadamente, ou você não vai saber qual está falhando. Para recuperação, pegue perguntas reais e verifique se o trecho correto aparece no que voltou. Para geração, verifique se a resposta é de fato sustentada pelos trechos entregues, não apenas se ela soa certa.

Essa segunda verificação é a que as pessoas pulam. Uma resposta pode estar factualmente correta e ainda assim não ser sustentada pelos seus documentos, o que significa que o modelo preencheu a lacuna com dado de treino. Em contexto regulado isso é problema real, porque você não consegue mostrar de onde a resposta veio.

Monte um conjunto de referência com cinquenta a duzentas perguntas reais e respostas boas conhecidas, e rode a cada mudança. Sem isso, toda melhoria é achismo.

Quanto custa rodar

Três linhas. Gerar embedding do acervo, que é um custo único por documento mais um custo pequeno contínuo para as mudanças. Armazenar e buscar os vetores, que escala com tamanho do acervo e volume de consulta. E a geração em si, normalmente a maior linha, porque prompt de RAG é longo por natureza.

A parte contraintuitiva: RAG torna cada requisição mais cara que uma chamada simples de modelo, porque você paga para enviar contexto recuperado toda vez. Ainda assim é quase sempre mais barato que a alternativa, que é uma resposta errada que um humano precisa pegar e corrigir.

Quando você não precisa de RAG

Se o conhecimento cabe confortavelmente no prompt e muda pouco, coloque no prompt. Se suas perguntas são respondidas por uma consulta de banco com formato conhecido, escreva a consulta; um modelo não precisa adivinhar algo que SQL responde com exatidão. E se a tarefa é uma decisão em vez de uma busca, o que você precisa está mais perto de um agente do que de recuperação.

Escolher a forma errada é o erro caro, não escolher o fornecedor errado. Escrevemos sobre essa distinção em o que é um agente de IA, e o princípio é o mesmo: a arquitetura segue o problema, e é por isso que construímos IA em produção, ponta a ponta em vez de liderar com uma técnica.