RAG: como conectar uma LLM aos dados da sua aplicação, e quando isso faz sentido

Imagine um assistente que precisa responder a uma pergunta sobre as regras da sua empresa. O modelo consegue escrever uma resposta convincente, mas de onde virão as informações sobre aquele regulamento interno?

Você poderia enviar todos os documentos junto com cada pergunta. Isso pode funcionar para um conjunto pequeno, mas fica mais difícil conforme aumentam o volume, a diversidade e a frequência de atualização das informações.

Uma alternativa é procurar primeiro o conteúdo necessário e fornecer esse material ao modelo. Essa é a ideia central de RAG.

Este artigo faz parte da série “IA aplicada ao desenvolvimento de software” Vamos explorar o que significa Retrieval-Augmented Generation, como suas etapas funcionam e quais decisões aparecem ao aplicar essa arquitetura. No final, vou conectar os conceitos à análise de uma aplicação educacional minha.

RAG significa Retrieval-Augmented Generation, ou geração aumentada por recuperação. É uma abordagem que combina a recuperação de informações em fontes externas com a geração de uma resposta por um modelo de linguagem.

Em vez de depender apenas do conhecimento aprendido durante o treinamento, o modelo recebe conteúdo recuperado para aquela solicitação.

Qual é o procedimento para solicitar reembolso de uma viagem?

A aplicação pode buscar a política de viagens, selecionar os trechos sobre despesas reembolsáveis e prazos e enviá-los à LLM junto com a pergunta. O modelo usa esse contexto para elaborar a resposta.

Os documentos não são automaticamente incorporados aos parâmetros do modelo. Nesse fluxo, eles são disponibilizados durante a geração, sem exigir um novo treinamento a cada atualização da política.

O trabalho de Lewis e colaboradores, publicado em 2020, apresentou uma arquitetura que combina recuperação e geração para tarefas intensivas em conhecimento. Desde então, o termo também passou a ser usado para diferentes sistemas que seguem esse princípio.

Uma LLM não conhece automaticamente os dados privados e atuais da sua aplicação. Mesmo quando consegue acessar ferramentas, alguém precisa definir como essas ferramentas consultam as fontes e quais resultados chegam ao modelo.

Isso importa quando a resposta depende de informações como contratos, manuais internos, documentação de produtos ou procedimentos que mudam com frequência.

RAG oferece um caminho para selecionar conteúdo dessas fontes e disponibilizá-lo como evidência. Também permite associar a resposta aos documentos utilizados, desde que a aplicação preserve essa relação.

Mas ele não garante que a informação recuperada seja correta nem que o modelo a interprete adequadamente. A qualidade continua dependendo das fontes, da recuperação e da geração.

Uma implementação comum tem dois momentos: a preparação das fontes e o atendimento de uma solicitação.

A aplicação extrai o conteúdo dos documentos, organiza os metadados e cria uma estrutura que permita pesquisar esse material.

Dependendo da abordagem, isso pode envolver:

Essa divisão ajuda a perceber que RAG vai além de “colocar documentos no prompt”. Existe uma etapa de recuperação que precisa encontrar o material adequado para cada solicitação.

Um manual pode ter centenas de páginas, mas a pergunta talvez dependa de apenas uma seção. Dividir o conteúdo em partes menores, os chamados chunks, permite recuperar porções específicas.

Um trecho pequeno demais pode separar uma regra de suas condições. Um trecho grande demais pode trazer várias informações sem relação com a pergunta.

Imagine uma política com esta estrutura:

Despesas de hospedagem são reembolsáveis, desde que respeitem os limites e as condições definidos na seção seguinte.

Se a recuperação encontra apenas a primeira parte, o modelo pode receber uma regra incompleta.

Por isso, o tamanho do trecho não deve ser a única preocupação. Títulos, seções, tabelas, referências e continuidade entre parágrafos também importam. Em determinados casos, faz sentido buscar um trecho e incluir a seção maior à qual ele pertence.

Não existe um tamanho universal que funcione igualmente bem para contratos, perguntas frequentes e documentação técnica.

Embeddings são representações numéricas de informações, como textos. Eles podem ser usados para comparar proximidade entre uma pergunta e os trechos disponíveis.

Um documento pode usar a expressão “redefinição de senha”, sem repetir exatamente as palavras da pergunta. Uma busca baseada em embeddings pode ajudar a encontrar essa relação semântica.

Normalmente, a aplicação calcula embeddings dos trechos durante a preparação e calcula uma representação da consulta durante a busca. Depois, compara essas representações para selecionar candidatos.

Ainda assim, proximidade semântica não significa que um trecho seja verdadeiro, atual, autorizado ou suficiente para responder. Essas condições precisam de tratamento próprio.

Não necessariamente. A recuperação pode usar diferentes mecanismos.

O importante é entender o problema de recuperação. Se a solicitação contém um número de contrato, uma consulta exata pode ser mais apropriada do que procurar contratos semanticamente semelhantes.

Também podemos combinar abordagens: obter os dados de um cliente por chave e recuperar trechos de um manual relacionados à sua dúvida.

Um banco com suporte a vetores pode fazer parte da solução, mas sua adoção não substitui essa análise.

Uma busca inicial pode encontrar vários trechos potencialmente relevantes. O reranking é uma etapa adicional que reordena esses candidatos de acordo com sua relação com a solicitação.

Por exemplo, a busca pode retornar vinte trechos sobre viagens corporativas. Uma etapa posterior compara os candidatos com a pergunta específica e prioriza aqueles que tratam de reembolso de hospedagem.

Isso pode melhorar a seleção, mas acrescenta custo, latência e outro componente para avaliar.

A quantidade de trechos recuperados também exige cuidado. Enviar mais candidatos pode aumentar a chance de incluir a evidência necessária, mas também pode acrescentar conteúdo redundante ou contraditório.

O modelo ter espaço para receber muitos tokens não significa que todos eles contribuirão para a resposta.

O estudo Lost in the Middle mostrou, nos modelos e nas tarefas avaliadas, que a posição da informação relevante dentro de contextos longos podia afetar o desempenho. Isso não determina o comportamento de toda aplicação ou modelo, mas reforça a necessidade de avaliar como o contexto é utilizado.

Por outro lado, cortar informações também pode prejudicar a resposta. Uma exceção antiga, uma observação complementar ou uma condição específica pode mudar a interpretação.

O objetivo é fornecer contexto suficiente, relevante e organizado. Reduzir o tamanho do prompt é uma possibilidade de otimização, não uma prova de qualidade.

Não. Ele pode fornecer evidências que ajudam a fundamentar a resposta, mas ainda existem diferentes formas de falhar.

A recuperação pode selecionar um documento antigo, deixar de encontrar a seção correta ou retornar apenas parte de uma regra. Mesmo com bons trechos, o modelo pode interpretar mal o conteúdo ou apresentar uma conclusão que não está sustentada pelas fontes.

Por isso, é importante definir o comportamento quando faltam evidências. Em alguns produtos, a resposta adequada é informar que não foi possível confirmar a informação, em vez de completar a lacuna.

Referências também precisam ser verificadas. Uma resposta citar um documento existente não significa que aquele documento sustente a afirmação feita.

Se um documento muda, a representação usada na recuperação precisa acompanhar essa mudança. Isso pode exigir atualizar índices, recalcular embeddings e remover versões substituídas.

Também precisamos preservar as permissões. Em uma aplicação com várias instituições, o usuário só deve recuperar conteúdo que está autorizado a acessar.

Não basta recuperar informações de todas as instituições e pedir ao modelo que ignore as demais. A restrição deve acontecer antes de o conteúdo ser disponibilizado à geração.

Outro cuidado é tratar os documentos recuperados como dados, e não como instruções confiáveis. Um texto encontrado pode conter comandos que tentem alterar o comportamento do assistente. A arquitetura precisa considerar esse risco ao montar o contexto e disponibilizar ferramentas.

A primeira pergunta é: a recuperação encontrou as evidências necessárias? Para responder, precisamos de casos em que sabemos quais documentos ou trechos deveriam estar disponíveis.

A segunda é: o modelo produziu uma resposta adequada a partir dessas evidências? Aqui entram fidelidade, completude, clareza e utilidade.

Uma resposta bem escrita pode esconder uma recuperação incompleta. Avaliar apenas a aparência do texto final deixa parte importante do sistema sem verificação.

Na minha aplicação, a LLM gera um Relatório Geral, um relatório relacionado ao Plano Educacional Individualizado, quando aplicável, e sugestões para a família.

O backend reúne avaliações, boletins, observações, registros pedagógicos e documentos institucionais. Comecei a investigar RAG porque suspeitava que estava enviando informações demais aos modelos.

A análise da implementação trouxe uma situação mais interessante: alguns prompts recebiam documentos completos, enquanto determinadas evidências pedagógicas não estavam sendo carregadas ou incluídas corretamente.

Ou seja, o contexto podia ser extenso e, ao mesmo tempo, insuficiente para a tarefa.

Os dados do aluno já pertencem a uma matrícula, uma instituição e um período conhecidos. Não preciso procurar por similaridade qual boletim ou avaliação utilizar. Preciso consultar corretamente os registros e preservar as evidências obrigatórias.

Os documentos institucionais apresentam outra possibilidade. Diretrizes e orientações poderiam ser recuperadas conforme a finalidade do relatório. Porém, o diagnóstico indicou alternativas anteriores: melhorar filtros, selecionar documentos pertinentes e avaliar orientações resumidas e revisadas.

Por isso, decidi não adicionar recuperação documental neste momento. A prioridade é corrigir a montagem do contexto e criar uma seleção específica para cada relatório.

Essa conclusão vale para o fluxo analisado. Uma aplicação educacional com um acervo extenso e perguntas abertas sobre documentos poderia apresentar uma necessidade diferente.

A análise foi feita a partir do código. Ainda não há economia ou melhoria de qualidade comprovada.

As mudanças precisam ser comparadas usando casos equivalentes, medindo consumo, latência, completude e fidelidade. Corrigir a ausência de evidências pode aumentar os tokens em algumas seções e, ainda assim, ser uma melhoria necessária.

Se os documentos institucionais continuarem representando um problema depois dessas correções, a recuperação poderá ser reavaliada com critérios mais claros.

RAG merece investigação quando a geração depende de conhecimento externo e existe uma necessidade real de selecionar esse conteúdo: um acervo grande, documentos distribuídos ou perguntas cujo contexto varia bastante.

Também pode ser útil quando precisamos atualizar fontes sem retreinar o modelo e preservar a origem das informações usadas nas respostas.

As respostas ajudam a escolher entre consultas diretas, seleção determinística, busca documental ou uma combinação dessas estratégias.

RAG conecta a geração de linguagem a informações recuperadas para uma solicitação. Essa ideia abre possibilidades importantes, mas sua qualidade depende de várias decisões: preparar as fontes, preservar contexto, encontrar evidências, aplicar permissões e avaliar as respostas.

Embeddings e bancos vetoriais são ferramentas possíveis dentro dessa arquitetura. A escolha começa pelo tipo de informação e pela forma como ela precisa ser acessada.

Na minha aplicação, estudar RAG ajudou a identificar uma prioridade anterior: construir melhor o contexto obtido por consultas que já eram conhecidas. Em outro cenário, a recuperação pode ser justamente a parte que falta.

Entender o mecanismo permite fazer essa distinção e adotar a tecnologia com um problema definido e uma forma de verificar o resultado.