Uma empresa tem 400 páginas de procedimentos, contratos e perguntas frequentes. O funcionário pergunta ao assistente: “Qual é o prazo para devolver um produto comprado no site?” A resposta surge em segundos, com uma frase convincente. O ponto decisivo não é a velocidade. É saber qual documento sustentou a frase, se ele ainda vale e se aquele funcionário podia consultá-lo.
É essa a promessa prática da geração aumentada por recuperação, conhecida pela sigla RAG. Em vez de esperar que o modelo “lembre” a política da empresa, o sistema procura trechos de uma coleção de documentos e os oferece como contexto para a resposta. A documentação da Microsoft sobre RAG descreve a combinação de busca e modelo de linguagem, com teste de precisão e citações. A técnica pode transformar conhecimento disperso em consulta útil. Também pode dar aparência de prova a uma informação errada.
O que é RAG, em linguagem simples?
Pense numa pessoa que responde a uma dúvida depois de consultar uma pasta, em vez de responder apenas de memória. O sistema recebe a pergunta, procura documentos relevantes, seleciona trechos e pede ao modelo que produza uma resposta baseada neles. Se a aplicação foi bem desenhada, o leitor pode abrir a fonte e conferir o trecho. A explicação do Google Cloud apresenta esse processo como forma de conectar respostas a informações externas.
Isso não significa que todo documento esteja correto nem que a resposta seja verdadeira por ter um link. Uma regra interna pode estar vencida; uma busca pode trazer uma página parecida, mas sobre outro produto; o modelo pode juntar dois trechos que não deveriam ser combinados. O valor da tecnologia está na rastreabilidade e na possibilidade de corrigir a base, não numa garantia automática de verdade.
O caminho de uma pergunta até a resposta
- Preparar o acervo. Selecionar arquivos autorizados, extrair texto legível, registrar proprietário, versão, data e nível de acesso. Cópias antigas devem ser removidas ou claramente marcadas como históricas.
- Recuperar trechos. A busca encontra partes relacionadas à pergunta. Termos exatos, contexto e permissões importam tanto quanto a semelhança de sentido.
- Compor com limites. O modelo recebe apenas o contexto necessário e uma instrução para reconhecer lacunas. A aplicação deve mostrar a fonte e evitar uma resposta categórica quando não há evidência.
- Verificar e melhorar. Perguntas reais revelam respostas incompletas, documentos ausentes e trechos ambíguos. Uma pessoa responsável corrige o acervo e mede o resultado novamente.
No bloco interativo desta reportagem, três situações mostram por que uma citação, por si só, não basta. Tente responder antes de revelar a explicação.
Quando usar RAG e quando é desperdício?
RAG faz sentido quando as respostas dependem de documentos que mudam e cujo conteúdo o leitor precisa conferir: manuais internos, normas de atendimento, catálogo técnico, orientação de suporte e políticas com versões. Uma pequena empresa pode começar com uma única coleção bem cuidada e dez perguntas frequentes, em vez de importar todos os arquivos disponíveis.
Se a informação é curta, estável e cabe numa página simples, uma boa página de perguntas frequentes pode resolver melhor. Se a tarefa exige cálculos exatos, aprovação de pagamentos, verificação de identidade ou aplicação de regras jurídicas a um caso concreto, a resposta do modelo não deve virar decisão automática. O fluxo pode ajudar a localizar documentos, mas a ação crítica pertence a processos verificáveis e pessoas autorizadas.
Há uma diferença importante entre RAG e treinamento do modelo. Atualizar a coleção de documentos não muda, por si só, os pesos do modelo. A busca passa a fornecer novo contexto a cada pergunta. Isso pode facilitar correções rápidas, mas só funciona se a indexação e o controle de versões acompanharem a mudança. A equipe precisa testar se o documento novo substituiu o antigo nas respostas.
O risco invisível: uma resposta pode usar o documento errado
Imagine uma loja que mantém duas políticas de devolução: uma atual e outra guardada para resolver compras antigas. Se ambas aparecem sem data, a busca pode trazer o prazo antigo. O modelo talvez redija uma resposta clara e cite a política errada. O problema não começa na “alucinação”; começa na organização do acervo.
Outro exemplo é mais grave. Um contrato de um cliente entra no índice global e aparece para um funcionário de outra área. Um aviso ao modelo, como “não divulgue contratos”, não substitui a barreira de acesso. A orientação da Microsoft para aplicações RAG recomenda aplicar controle no momento da recuperação. O documento que o usuário não pode ler não deve ser entregue ao modelo em nome dele.
Também existe a injeção de instruções. Um arquivo pode conter texto que tenta dar ordens ao assistente, como se fosse uma regra do sistema. A OWASP explica que documentos externos são entrada não confiável e que RAG não elimina esse risco. A defesa inclui separar conteúdo de instruções, limitar privilégios, validar saídas e exigir aprovação humana para ações sensíveis. Não há um comando mágico que resolva tudo.
Como avaliar sem se deixar convencer por uma demonstração bonita
Escolha perguntas que uma pessoa faria no trabalho, inclusive as difíceis. Inclua uma questão sem resposta no acervo, outra com documento desatualizado e outra com acesso restrito. Para cada uma, registre o documento esperado, a resposta aceitável e o que seria um erro grave. Depois, teste o sistema sem mostrar a solução à equipe que o opera.
Avalie pelo menos quatro dimensões: recuperação (o trecho certo apareceu?), fundamentação (a resposta realmente decorre dele?), completude (faltou uma exceção?) e segurança (o usuário recebeu apenas o que podia ver?). A documentação de avaliação da Microsoft separa métricas de busca e de qualidade da resposta. Nenhuma nota única dispensa revisão de casos concretos.
Uma métrica útil é a taxa de respostas que exigiram correção humana. Outra é a taxa de recusas corretas quando falta informação. “Respondeu a tudo” pode ser um péssimo resultado se parte das respostas foi inventada. Registre custo por consulta e tempo de resposta também: busca, processamento de documentos e uso do modelo adicionam trabalho e despesa.
Um piloto possível para uma empresa pequena
Comece por um processo de baixo risco, como orientação interna sobre onde encontrar procedimentos. Escolha uma pessoa responsável por cada fonte, registre a última revisão e restrinja o acesso. Separe 30 perguntas reais. Teste primeiro se a busca mostra o trecho certo; só depois adicione geração de texto. Exija links para a origem, uma frase clara quando não houver base suficiente e um canal para reportar erro. Reavalie sempre que a política mudar.
Não envie dados pessoais, contratos ou segredos a qualquer serviço antes de entender as condições de tratamento e os controles de acesso. O desenho precisa respeitar a finalidade e as permissões dos arquivos originais. Para compreender a camada de automação que pode vir depois, veja nosso guia sobre agentes de IA no trabalho e a calculadora de custo de API de IA. A calculadora ajuda a estimar custo; não mede qualidade nem segurança.
Perguntas frequentes sobre RAG
RAG acaba com respostas inventadas?
Não. Uma boa recuperação reduz a chance de responder sem contexto, mas a busca pode falhar e o modelo pode interpretar mal o material. Exija fonte verificável e permita que o sistema diga “não encontrei base suficiente”.
Preciso criar um modelo próprio?
Não necessariamente. RAG é um desenho de aplicação que combina uma coleção pesquisável com um modelo. A escolha de serviços depende de privacidade, custo, idioma, manutenção e requisitos do negócio.
Quanto mais documentos, melhor?
Não. Um acervo menor, atualizado e com responsáveis definidos costuma ser mais útil do que milhares de versões conflitantes. Qualidade editorial é parte da engenharia.
Posso deixar o assistente tomar decisões sozinho?
Perguntas de consulta são diferentes de ações. Pagamentos, mudanças cadastrais, concessão de acesso e decisões que afetam pessoas exigem controles próprios, validações e aprovação humana.
O que levar desta reportagem
Uma resposta baseada em documentos só merece confiança quando o leitor consegue seguir o caminho de volta à fonte, ver sua data e entender seus limites. A tecnologia pode acelerar o acesso ao conhecimento da empresa. A confiança nasce da curadoria, da permissão correta, do teste de erros e da disposição de dizer “não sei”.
Como apuramos: consultamos a documentação técnica da Microsoft, do Google Cloud, os critérios de avaliação de RAG e o guia da OWASP sobre injeção de instruções. Os exemplos de empresa são hipotéticos; não descrevem um produto auditado.
