Como fazer um RAG responder isso não está no documento com provas

A resposta mais útil que um sistema de RAG (geração aumentada por recuperação) pode dar, às vezes, é justamente “isso não está neste documento”. Mas há um problema: quando recebe uma pergunta, um modelo de linguagem tende a responder de qualquer jeito. O “não encontrado” honesto precisa ser construído de propósito — e acertar quando diz “não” é mais difícil do que acertar quando diz “sim”.

Por que um “não” simples não basta

Imagine perguntar ao chatbot corporativo “quanto de eletricidade a IA consome globalmente?” e receber “não consigo encontrar uma resposta neste documento”. Você reformula, e a resposta é a mesma. A maioria das pessoas desiste e vai para o Google.

O sistema pode até ter feito a coisa certa — o documento em questão pode não conter aquela informação. Mas o usuário não aprendeu nada de útil. Ele não consegue saber se o pipeline realmente procurou em todos os lugares, ou se desistiu depois de uma busca superficial por similaridade de embeddings. Um “não encontrado” precisa vir acompanhado de uma defesa — senão soa como falha, não como fato.

Quatro tijolos, quatro provas

A arquitetura de RAG corporativo costuma se dividir em quatro etapas, e cada uma delas precisa entregar uma peça de evidência quando a resposta correta é “não”:

• Análise (parsing): o custo de uma falha de extração é assimétrico. Extrair ruído torna a recuperação mais bagunçada, mas é recuperável. Deixar de extrair um token real é silencioso: o “não encontrado” parece correto, mas está errado — a resposta estava lá e o pipeline não viu. A evidência aqui é um relatório de cobertura: quantas páginas foram analisadas, quantas tinham texto, quantas imagens passaram por OCR, quantas referências cruzadas não foram resolvidas.
• Análise da pergunta: a recuperação só é boa quanto as palavras-chave que usa. Se o especialista lista “IA” mas esquece “inteligência artificial”, a busca perde todas as linhas que escrevem o conceito por extenso. A evidência é o conjunto de palavras-chave validado pelo especialista, idealmente ampliado por agrupamento de embeddings como rede de segurança.
• Recuperação: para uma resposta normal, a busca retorna o top-k (as páginas mais prováveis). Para provar ausência, isso não funciona — é preciso fazer uma varredura exaustiva em todas as páginas que mencionam qualquer conceito. A evidência é a lista de ocorrências: “na página P, linha L, a variante V do conceito C foi encontrada”.
• Geração: o modelo não inventa os campos — ele recebe o relatório de cobertura, o conjunto de palavras-chave e a lista de ocorrências das etapas anteriores. Seu trabalho é apenas escolher o motivo da ausência, apontar as menções mais próximas e explicar, em uma frase, por que aquela passagem não responde à pergunta.

O que muda na prática

Ao estruturar a ausência dessa forma, o usuário aprende três coisas de uma vez: que o sistema procurou pelo conceito sob nove nomes diferentes e não encontrou nada em 63 páginas; que existe uma passagem sobre eletricidade, mas ela trata da demanda de energia movida a carvão na Índia, não de IA; e que, se ele quiser a resposta, aquele corpus é o lugar errado para perguntar.

O “não encontrado” deixa de ser um beco sem saída e passa a ser uma resposta útil e verificável. A mesma disciplina que torna um “sim” auditável — forçar o modelo a citar suas evidências — também se aplica ao “não”: forçar o pipeline a expor sua busca.