Por Que o RAG Acerta no Teste e Erra em Produção: Como Separar Falha de Recuperação de Falha de Geração

Uma pergunta antes de qualquer ajuste: qual porcentagem das perguntas reais chega ao modelo já com o trecho correto dentro do contexto? Quem não tem esse número não está otimizando um assistente — está ajustando prompt no escuro e esperando que a média suba.

É o cenário mais comum em projetos de RAG que passam da prova de conceito. O time monta um conjunto de trinta perguntas, roda, vê acerto alto, libera para a área de negócio. Duas semanas depois chega o relato de que o assistente inventa procedimento, cita política revogada e responde com segurança sobre coisas que não existem. E a discussão vira sobre trocar de modelo, quando o problema quase nunca está ali.

Uma métrica agregada esconde duas falhas com causas opostas

Acurácia de resposta é uma métrica de saída. Ela mistura, num número só, duas etapas que falham por motivos diferentes e se corrigem com intervenções diferentes.

A primeira é a recuperação: dada a pergunta, o sistema encontrou e colocou no contexto o trecho que continha a informação. A segunda é a geração: tendo o trecho em mãos, o modelo produziu uma resposta fiel ao que estava escrito.

Quando as duas etapas são medidas juntas, cada queda de acurácia comporta pelo menos quatro histórias distintas — o trecho não existe no acervo, existe mas não foi recuperado, foi recuperado mas ficou soterrado entre passagens irrelevantes, ou chegou íntegro e o modelo respondeu outra coisa. As quatro exigem times, prazos e orçamentos diferentes. Tratar todas com engenharia de prompt é o desperdício mais frequente nesse tipo de projeto.

O teto de recuperação, e por que ele define o resto

Existe um número que limita todos os outros. Se o trecho correto entra no contexto em, digamos, 70% das perguntas, então 70% é o teto de acurácia final do sistema. Nas outras 30% o modelo está sendo convidado a responder sem a informação — e o comportamento esperado ali é recusar, não acertar.

Esse raciocínio inverte a ordem natural das tentativas. A maioria dos times começa pela camada mais visível — o prompt — porque é a mais barata de mexer. Só que a camada mais barata de mexer é também a que tem menos margem quando o teto está baixo. Vale medir o teto primeiro e só depois decidir onde investir.

O teste do oráculo: quinze minutos que localizam a falha

Há um experimento simples que separa as duas etapas sem instrumentação sofisticada. Pegue as perguntas que o sistema errou. Para cada uma, localize manualmente o trecho correto na documentação e cole esse trecho no contexto, ignorando a busca. Rode a geração de novo.

A leitura do resultado é direta:

1. O modelo passa a acertar com o trecho colado. A falha é de recuperação. Prompt não é o problema, e mexer nele vai consumir semanas sem mover o indicador.
2. O modelo continua errando mesmo com o trecho correto no contexto. A falha é de geração — instrução ambígua, contexto longo demais, conflito entre o que o documento diz e o que o modelo já sabia, ou pergunta que exige combinar duas fontes.
3. O trecho correto não existe no acervo. Não é um problema de IA. É um problema de documentação, e nenhuma camada técnica resolve.

Esse terceiro caso costuma responder por uma fatia maior do que os times esperam quando o acervo veio de wiki interna acumulada por anos. Vale conferir antes de abrir qualquer ticket de engenharia.

Duas variações do teste rendem informação adicional por pouco esforço. A primeira é repetir a geração com o trecho correto sozinho no contexto e depois com o trecho correto misturado às passagens que a busca havia trazido. Se o acerto aparece no primeiro caso e some no segundo, o problema não é nem busca nem modelo — é ruído de contexto, e a correção passa por reordenação. A segunda é rodar a mesma pergunta reescrita com as palavras que a documentação usa, em vez das palavras que o usuário usou. Quando isso resolve, o desencontro é de vocabulário, e reescrita de consulta ou busca por termo entram na lista de intervenções antes de qualquer coisa mais cara.

As quatro métricas que substituem a média única

Para acompanhar o sistema ao longo do tempo, quatro indicadores dão conta e se calculam sem ferramenta paga:

1. Recall@k — em que porcentagem das perguntas o trecho-âncora anotado aparece entre os k documentos recuperados. É o teto descrito acima.
2. Precisão do contexto — que fração do que entrou no contexto era de fato relevante. Precisão baixa com recall alto significa que o trecho certo está lá, cercado de ruído, e o problema é de ordenação, não de busca.
3. Fidelidade ao contexto — que fração das afirmações da resposta é sustentada por alguma passagem recuperada. É a métrica que captura alucinação de forma auditável, porque cada afirmação pode ser rastreada até um trecho ou até a ausência dele.
4. Taxa de recusa apropriada — com que frequência o sistema diz que não sabe quando o contexto realmente não continha a resposta. Esse indicador costuma ser esquecido, e é o que separa um assistente confiável de um que responde bonito sobre qualquer coisa.

Um conjunto de avaliação de algumas dezenas a poucas centenas de perguntas reais, cada uma com o trecho-âncora anotado por alguém da área, já entrega leitura estável. O que muda o resultado não é o tamanho do conjunto — é a origem das perguntas. Conjunto escrito pelo time de engenharia mede o sistema contra a linguagem da engenharia, que não é a linguagem de quem usa.

Sintoma, etapa provável e teste correspondente

Na prática, a leitura desses quatro indicadores fica mais rápida quando o ponto de partida é o sintoma relatado pelo usuário. A tabela abaixo faz esse caminho inverso — do que se ouve na reclamação até a medição que confirma ou descarta a hipótese.

Duas crenças que consomem orçamento sem mover indicador

A primeira é a de que ampliar a janela de contexto resolve recuperação ruim. Enfiar cinquenta passagens no contexto porque a busca não é confiável aumenta o custo por chamada, aumenta a latência e piora a precisão do contexto. Modelos tendem a dar menos peso ao que está no meio de contextos longos, então a passagem correta pode estar presente e ainda assim ser ignorada. Reordenar bem dez passagens costuma render mais do que despejar cinquenta.

A segunda é a de que trocar o modelo de geração é a alavanca principal. Modelo melhor ajuda quando a falha é de geração — raciocínio sobre duas fontes, síntese, obediência a formato. Quando a falha é de recuperação, o modelo mais caro do mercado continua respondendo sobre um contexto que não tem a informação, e o ganho fica na margem de erro da medição.

Há ainda uma terceira crença, mais discreta: a de que ajuste fino do modelo ensina o conhecimento da empresa e dispensa a recuperação. Ajuste fino é eficiente para formato, tom e obediência a instrução, e ineficiente como forma de armazenar fato que muda. Acervo corporativo é revisado, revogado e substituído — e cada revisão exigiria treinar de novo, com custo recorrente e sem rastreabilidade. Quando alguém pergunta de onde saiu determinada resposta, um sistema baseado em recuperação aponta o documento; um modelo ajustado aponta para si mesmo. Em contexto sujeito a auditoria, essa diferença costuma valer mais do que qualquer ponto percentual de acurácia.

Ordem de intervenção, do mais barato ao mais caro

Havendo teto de recuperação baixo, a sequência que costuma render mais por hora investida é esta. Primeiro, higiene do acervo: eliminar duplicata, marcar vigência, retirar o que está revogado. É trabalho de conteúdo, não de engenharia, e frequentemente é o que devolve mais pontos de recall.

Depois, revisar fragmentação e metadados — respeitar limite de seção, manter tabela inteira em um mesmo bloco, carimbar área, produto e data em cada trecho para permitir filtro antes da busca. Em seguida, busca híbrida, combinando busca vetorial com busca por termo. Vocabulário interno, sigla e código de produto costumam ser mal representados em embedding genérico, e é justamente isso que o usuário digita.

Só então entram reordenador dedicado e ajuste de prompt com exigência de citação de trecho. Ajuste fino do modelo fica por último, e na maioria dos casos corporativos não chega a ser necessário — quando chega, é para formato e tom, raramente para conhecimento.

Se fosse preciso escolher uma única mudança para um assistente interno que já está em produção e decepciona, a escolha seria a busca híbrida com filtro por metadado de vigência. É a intervenção que ataca ao mesmo tempo o vocabulário interno e o problema de documento velho, que juntos explicam boa parte dos erros relatados pelo usuário final.

Perguntas frequentes

Quantas perguntas o conjunto de avaliação precisa ter?

Algumas dezenas já revelam padrão; algumas centenas dão estabilidade para comparar versões. Prioridade absoluta para perguntas extraídas de log real, não escritas pelo time técnico.

Dá para medir fidelidade sem revisão manual?

Dá, usando um modelo como avaliador que verifica cada afirmação contra o contexto. Vale calibrar o avaliador contra uma amostra revisada por pessoa antes de confiar no número em série.

Qual valor de k usar na recuperação?

Depende do tamanho do bloco e do custo aceitável. O método é medir recall@k para valores crescentes e parar onde a curva achata — aumentar k depois desse ponto adiciona ruído sem adicionar informação.

Busca vetorial pura nunca basta?

Basta quando o vocabulário do usuário se parece com o do documento e não há sigla nem código proprietário. Em base corporativa isso é raro, e o teste de recall com perguntas reais mostra a diferença em poucas horas.

Com que frequência reavaliar?

A cada alteração relevante no acervo e a cada troca de componente do pipeline. Acervo vivo degrada recuperação em silêncio, e sem reavaliação periódica a queda só aparece na reclamação do usuário.