O que é RAG (geração aumentada por recuperação) e quando usar

RAG (Retrieval-Augmented Generation, ou geração aumentada por recuperação) é um método que busca a informação relevante numa base de conhecimento e a anexa ao pedido do usuário antes de o modelo responder.

O modelo de IA não conhece o seu negócio. Um assistente de suporte precisa saber de produtos e políticas da empresa, e um assistente jurídico precisa conhecer um grande volume de casos anteriores. O RAG é o jeito mais comum, segundo a Anthropic, de dar esse conhecimento ao modelo: em vez de reescrever o modelo, o sistema entrega a ele, a cada pergunta, os trechos certos dos seus documentos.

A Anthropic divide o RAG em duas fases. A primeira é a preparação da base, feita antes de qualquer pergunta:

1. 01

   Cortar em pedaços (chunks)

   Os documentos são divididos em trechos pequenos, em geral de no máximo algumas centenas de tokens.

2. 02

   Gerar embeddings

   Um modelo converte cada trecho em um vetor numérico que codifica o sentido do texto.

3. 03

   Guardar num banco vetorial

   Os vetores ficam num banco que permite buscar por semelhança de sentido.

A segunda fase acontece quando alguém pergunta: o sistema usa o banco para achar os trechos mais próximos da pergunta e os adiciona ao pedido enviado ao modelo, que então escreve a resposta com base neles.

Sentido e palavra exata

Embeddings são bons em captar relações de sentido, mas podem deixar escapar correspondências exatas. O exemplo da Anthropic é uma consulta por “Error code TS-999”: o embedding encontra conteúdo sobre códigos de erro em geral, e pode perder o trecho com o código exato. Para isso existe o BM25, um método mais antigo que procura a palavra ou a frase idêntica. Sistemas de RAG melhores combinam os dois, e a Anthropic conclui que embeddings mais BM25 superam embeddings sozinhos.

O ponto fraco do RAG tradicional é que, ao cortar documentos em pedaços, ele perde contexto. O exemplo da Anthropic: numa base de documentos financeiros, o trecho “a receita da empresa cresceu 3% em relação ao trimestre anterior” não diz de qual empresa nem de que período está falando. Se alguém perguntar sobre a ACME no segundo trimestre de 2023, o sistema pode não achar esse trecho, ou achá-lo e não saber usá-lo.

A técnica que a Anthropic propõe, chamada Contextual Retrieval, acrescenta a cada trecho uma pequena explicação de onde ele vem antes de indexá-lo. Nos testes da própria Anthropic, o número de buscas que falharam em trazer o trecho certo entre os 20 primeiros caiu 35% só com embeddings contextuais e 49% combinando com BM25, de 5,7% para 2,9%. Somando uma etapa de reclassificação (reranking), a queda foi de 67%, de 5,7% para 1,9%.

A Anthropic faz uma ressalva que muita gente esquece. Se a sua base de conhecimento tiver menos de 200.000 tokens, cerca de 500 páginas, dá para colocar tudo no pedido ao modelo, sem RAG. Em 2024, ela apontava que o cache de prompts tornava essa abordagem mais rápida e mais barata, com redução de latência de mais de 2 vezes e de custo de até 90%. Esses números são de setembro de 2024 e podem ter mudado. O RAG passa a ser necessário quando a base cresce além da janela de contexto do modelo.

Esta seção é da Invisible Work e não vem das fontes, que não comparam as duas abordagens. A diferença que importa para quem decide é o que cada uma muda. O RAG entrega ao modelo, a cada pergunta, a informação que a empresa tem agora, e por isso acompanha documentos que mudam e permite apontar de qual trecho veio a resposta. O fine-tuning altera o próprio modelo, com exemplos de treino, e é mais indicado para mudar o jeito como ele se comporta do que para ensinar fatos que mudam toda semana.

O limite do RAG é o da base. Se o conhecimento da empresa está desatualizado, espalhado em e-mails ou só na cabeça de quem opera o processo, o sistema recupera o que existe, e o que existe pode estar errado. Por isso, em projetos de RAG, boa parte do trabalho é entender e organizar a informação, e não só montar a busca.