ooligo
TIPO · definition

Retrieval-augmented generation (RAG)

Por Marius Bughiu Última atualização 2026-07-27 RevOpsLegal OpsRecrutamento e TACustomer Success

Retrieval-augmented generation (RAG) é o padrão em que uma ferramenta de AI busca dentro de um conjunto de documentos antes de responder e depois escreve a resposta a partir dos trechos que encontrou, e não a partir do que o modelo absorveu durante o treinamento. Chega uma pergunta, um passo de busca traz de volta um punhado de trechos que ele pontua como relevantes, esses trechos são colados no prompt do modelo, e o modelo responde em cima deles. Isso importa para quem compra porque RAG é a maquinaria por trás de quase toda afirmação de fornecedor sobre estar “fundamentado”, “citar as fontes” ou “treinado com os seus dados” — e qual dessas três o fornecedor realmente quer dizer muda o que você precisa testar antes de assinar.

RAG não é treinamento. Seus documentos nunca entram nos pesos do modelo; eles são lidos na hora da pergunta e descartados depois. Um fornecedor que diz “o modelo aprende os seus contratos” está descrevendo RAG de forma imprecisa ou está fazendo algo que merece uma pergunta direta sobre onde os seus dados vão parar. RAG também não resolve alucinação, e não é uma propriedade do modelo — é um pipeline montado em volta de um modelo que continua igual. Dois produtos rodando o modelo idêntico se comportam de forma completamente diferente dependendo de quão bem esse pipeline acha as coisas.

As duas metades, e só uma aparece na demo

Todo sistema RAG tem uma metade de recuperação — indexar o corpus, cortar em chunks, buscar, ranquear o que volta — e uma metade de geração, onde o modelo escreve o texto a partir do que a primeira metade entregou.

As demos de fornecedor exercitam a metade de geração. É a parte que parece impressionante, e não é onde os erros começam. Quando o passo de recuperação erra, o modelo não sabe que errou: ele escreve uma resposta fluente e bem citada a partir dos três trechos errados e não reporta problema nenhum. O modelo não tem como te avisar que o trecho de que ele precisava nunca chegou até ele. Esse fato sozinho deveria reformular o jeito como você roda um piloto, porque significa que testar a qualidade das respostas em perguntas que a ferramenta acerta não te diz quase nada.

”Fundamentado” é uma afirmação sobre encanamento, não sobre acurácia

A evidência pública mais forte vem do direito, onde as afirmações foram mais barulhentas e alguém as mediu. O RegLab de Stanford rodou uma avaliação pré-registrada das ferramentas de pesquisa jurídica baseadas em RAG vendidas por LexisNexis e Thomson Reuters — Lexis+ AI, Westlaw AI-Assisted Research e Ask Practical Law AI — e encontrou que elas alucinam entre 17% e 33% das vezes. A LexisNexis tinha divulgado citações vinculadas “livres de alucinação”; a Thomson Reuters dizia que suas ferramentas evitam alucinações por se apoiarem em conteúdo confiável. As duas afirmações estavam superdimensionadas. A leitura honesta não é que RAG falhou: essas ferramentas de fato bateram o GPT-4 de propósito geral nas mesmas perguntas. A leitura é que recuperação sobre um corpus curado derruba a taxa de erro e nunca a leva a zero, então “fundamentado” descreve uma arquitetura, não uma garantia.

Daí saem duas formas de falha, e elas não são igualmente perigosas. Uma é a resposta claramente errada, que um especialista do domínio pega. A outra é a resposta mal fundamentada — o conteúdo está errado, mas vem com uma citação real anexada, apontando para um documento real que não diz o que a resposta afirma. Essa sobrevive à revisão, porque a citação é exatamente o sinal que um revisor apressado usa para decidir que a resposta já foi conferida.

Perguntas de diagnóstico para um fornecedor

Estão ordenadas de modo que as duas primeiras façam a maior parte do trabalho.

  1. Me mostre uma pergunta que a ferramenta erra, e diga se a causa foi recuperação ou geração. Um fornecedor que nunca caracterizou as próprias falhas de recuperação não avaliou o sistema, só a demo.
  2. Uma citação aponta para um trecho ou para um documento? Citação em nível de documento é impossível de verificar em volume real — ninguém lê um MSA de 60 páginas para confirmar uma frase. Citação em nível de trecho ou de cláusula é o que barateia a revisão a ponto de ela realmente acontecer.
  3. O que ele faz quando a resposta não está no corpus? Os dois comportamentos são “não tenho isso” e uma queda silenciosa para o conhecimento geral do modelo base. O segundo é por onde entra a bobagem com tom seguro, e raramente aparece numa página de preços.
  4. As permissões são aplicadas na recuperação ou depois da geração? A resposta certa é na recuperação: o modelo só enxerga documentos que o usuário que perguntou já tem direito de ver. A Glean construiu a indexação dela em torno de recuperação recortada por permissão exatamente por isso. Filtrar a resposta depois que o modelo leu um documento restrito não é controle de acesso, é tarja com vazamento.
  5. Quanto tempo depois de um documento mudar a versão nova passa a ser a que responde? Minutos, de hora em hora ou toda noite são todas defensáveis. Não saber, não.
  6. Consigo ver o que foi recuperado, e não só o que foi escrito? Sem esse painel, você não depura uma resposta errada, e o suporte deles também não.

Uma janela de contexto maior torna RAG desnecessário?

Não, e os fornecedores que vendem janelas de contexto de um milhão de tokens não estão afirmando isso. Três coisas mantêm a recuperação na arquitetura: um corpus de dezenas de milhares de documentos não cabe em nenhuma janela de contexto do mercado; o custo de entrada escala com tokens, então empurrar uma base de conhecimento inteira pelo modelo a cada pergunta é cobrado por pergunta; e um corpus que muda de hora em hora sai mais barato reindexar do que reenviar.

O que mudou até 2026 foi a mistura. O padrão que funciona é recuperar e então raciocinar — puxar uma fatia generosa de material relevante em vez dos três chunks mais apertados possíveis, e deixar um modelo de contexto longo trabalhar em cima de tudo. Isso afrouxa a precisão exigida do passo de recuperação sem removê-lo. Trate qualquer pitch construído sobre “nossa janela de contexto é tão grande que não precisamos de recuperação” como uma afirmação sobre o tamanho do seu corpus que eles não terminaram de pensar.

Armadilhas comuns

Rodar o piloto no corpus do fornecedor. Uma demo ajustada durante meses em cima de um conjunto de documentos de amostra te diz quão boa é a amostra deles.

Proteção: Forneça os seus próprios documentos e escreva de 30 a 50 perguntas reais antes da primeira demo. Inclua 5 cujas respostas estejam deliberadamente ausentes do corpus, e pontue o comportamento de recusa nessas como um item passa/não passa.

Ler uma citação como verificação. A citação é justamente o que faz uma resposta mal fundamentada parecer revisada.

Proteção: Durante o piloto, abra o trecho citado sobre uma amostra fixa — 20 respostas por semana bastam — e acompanhe a taxa de mal fundamentadas separada da taxa de erradas. Uma ferramenta com 5% de erradas e 15% de mal fundamentadas é pior para o seu time do que uma com 15% de erradas e 2% de mal fundamentadas.

Assumir que as permissões vêm junto dos sistemas de origem. Indexação por conector copia conteúdo; se copiou também a lista de controle de acesso é uma pergunta à parte, com uma resposta à parte para cada conector.

Proteção: Durante o piloto, rode as mesmas três consultas sensíveis como dois usuários de níveis de permissão diferentes e compare os resultados. Faça isso por conector, não uma vez só para o produto.

Deixar o corpus apodrecer depois do go-live. A qualidade da recuperação cai conforme políticas superadas, contratos vencidos e playbooks velhos se acumulam, porque o passo de busca não tem como saber qual versão é a vigente.

Proteção: Nomeie um dono do corpus antes do lançamento e dê a ele um mandato de exclusão, não só de upload. Refaça o teste a cada trimestre com um documento editado naquela manhã e com um documento que já deveria ter sido removido.

Relacionado

  • O que é um MCP server — a outra forma de uma ferramenta de AI alcançar os seus sistemas: chamá-los ao vivo em vez de buscar num índice copiado
  • AI agent para ops — onde a recuperação fica dentro de um agente que também executa ações, e os testes de autonomia que vêm junto
  • AI agent vs RPA — a decisão de compra vizinha, e por que falhas de agente são invisíveis para monitoramento de uptime
  • Glean e Hebbia — busca corporativa horizontal contra extração estruturada sobre um corpus grande, duas respostas diferentes para o mesmo problema de recuperação
  • Gestão do Conhecimento Jurídico — a disciplina de propriedade do corpus que decide se algo disso funciona num time jurídico