Validando respostas RAG antes do usuário ver: spans, citações e o feedback loop

Uma resposta tipada não é uma resposta verificada. O output estruturado é o começo da validação, não o fim. Modelos ainda citam linhas fora do intervalo dos documentos, parafraseiam citações que juraram ser literais, declaram complete_answer_found=True em respostas parciais e retornam formatos que o brief nem sequer pediu. Em sistemas RAG empresariais, onde respostas incorretas podem ter consequências legais ou financeiras, isso não é aceitável.

Este artigo fecha a série Enterprise Document Intelligence de Kezhan Shi, que constrói um sistema RAG corporativo do zero. Depois de cobrir parsing de documentos, parsing de perguntas e recuperação, chegamos ao quarto e último bloco: geração com validação.

Confie, mas verifique

A correção proposta é a validação pós-geração. O validador recebe a pergunta parseada junto com a resposta para identificar incompatibilidades de formato. Três verificações se combinam:

• Forma (Shape): a resposta deve ser uma instância do schema que o registry selecionou para o brief, com items populados quando answer_found=True.
• Evidência (Evidence): cada Span deve referenciar um intervalo real de linhas do documento fonte. Toda citação literal deve ser substring das linhas citadas após normalização tolerante de whitespace.
• Formato (Format): ISO 8601 para datas, ISO 4217 para moedas, e outras validações de padrão.

O pulo do gato está no loop per-item, per-span: cada problema é reportado individualmente para que o modo de falha seja visível de relance. Um span errado no item 2 não esconde uma moeda errada no item 3.

“Not found” como output de primeira classe

Um dos avanços mais importantes do sistema é tratar “não encontrado” como uma resposta válida e desejável. Em vez de forçar o modelo a inventar algo quando a evidência não está nos documentos, o sistema aceita que a resposta honesta é dizer que não há dados suficientes. Isso elimina alucinações por pressão e aumenta drasticamente a confiabilidade em produção.

Feedback loop: da geração de volta ao pipeline

A validação não é um passo terminal — ela alimenta de volta o pipeline. Quando o validador encontra problemas, o sistema pode:

1. Re-consultar o modelo com o erro específico para correção
2. Re-recuperar documentos adicionais se as evidências forem insuficientes
3. Emitir “not found” com confiança quando todas as tentativas falharem

Isso transforma a geração de um passo terminal em um passo que o pipeline pode reagir — essencial para sistemas que precisam de confiabilidade em escala empresarial.

Citações que viram retângulos no PDF

Um detalhe prático impressionante: o sistema faz o join das citações validadas com as coordenadas do PDF original, permitindo destacar visualmente no documento exatamente de onde cada resposta veio. Isso é crucial para auditabilidade em setores regulados como financeiro e jurídico.

Todo o código está disponível como notebooks executáveis no GitHub (doc-intel/notebooks-vol1), cobrindo cada etapa do pipeline. Para equipes brasileiras construindo RAG em produção — especialmente em setores regulados como bancos e seguradoras — essa abordagem de validação tripla com feedback loop é o padrão que separa um protótipo de um sistema pronto para produção.