RAG sem mistério: dos documentos à recuperação confiável
RAG não é “colocar PDFs num banco vetorial”. É um pipeline de dados que transforma fontes em constante mudança em evidências rastreáveis, encontra os trechos certos para uma pergunta e fornece contexto para o modelo responder com citações verificáveis. Quando a resposta falha, a causa pode estar na extração, nas permissões, nos limites dos trechos, no ranking ou na geração. Cada etapa precisa ser observável e mensurável; aumentar o prompt não deve ser o primeiro reflexo.
Publicado em 28 de setembro de 202615 min de leituraBusca documental e IA aplicada
Rastreie a evidência por todo o sistema
Cada resposta deve permitir voltar da passagem recuperada à versão exata da fonte
1 / OrigemResponsável, versão, acesso e validade.
2 / ExtraçãoPreserve texto, tabelas e estrutura.
3 / SegmentaçãoDivida por sentido e mantenha metadados.
4 / ÍndiceGere embeddings e guarde procedência.
5 / BuscaPesquise, filtre, ordene e selecione evidências.
6 / RespostaGere com citações ou abstenção.
Comece pela identidade e pelo acesso aos documentos
Atribua a cada fonte um ID estável, versão, hash de conteúdo, responsável, vigência, data de ingestão e política de acesso. Uma nova versão deve substituir a anterior de forma explícita, não criar evidências duplicadas sem controle. Exclusões e mudanças de permissão precisam alcançar os trechos derivados e os índices. Remover o arquivo original enquanto suas passagens continuam pesquisáveis é uma exposição de dados.
Registre a versão do parser, avisos de extração e configuração de segmentação em cada execução. Quando a política de retenção permitir, preserve o original ou uma referência controlada para investigar respostas ruins. Texto recuperado de documentos não confiáveis é dado, não instrução: não deve substituir políticas do sistema nem autorizar ferramentas.
Extraia estrutura, não apenas volume de texto
A extração de PDF pode misturar colunas, perder cabeçalhos ou separar uma tabela das unidades. HTML pode trazer menus e trechos repetidos; OCR adiciona incerteza. Preserve títulos, páginas, rótulos de tabelas e links de origem como metadados e encaminhe extrações de baixa qualidade para revisão. Em tabelas, mantenha o contexto de linha e coluna para que um valor não perca a relação com seu cabeçalho.
Escolha limites de trechos conforme o conteúdo
Formato
Limite inicial útil
Risco comum
Políticas e manuais
Título e seção coerente, com contexto do documento pai
Separar uma exceção da regra que ela altera
Código e documentação de API
Símbolo, endpoint ou exemplo completo
Separar assinatura de parâmetros ou versão
Tabelas e catálogos
Linhas com cabeçalhos e unidades repetidos
Recuperar números sem categoria
Atendimentos
Problema, solução e metadados de produto/versão
Remover a pergunta que dá sentido à resposta
Janelas fixas de tokens são uma boa linha de base reproduzível, não uma regra universal. Sobreposição protege contexto nas bordas, mas aumenta o índice e pode gerar resultados duplicados. Segmentação que respeita a estrutura, combinada com recuperação pai-filho, pode trazer um trecho objetivo e manter a seção maior para o modelo. Compare estratégias usando seus documentos e perguntas, não uma medida escolhida por tradição.
Embedding é apenas um sinal de busca
Um embedding transforma texto em vetor para aproximar passagens semanticamente relacionadas, mesmo com palavras diferentes. Isso não garante relevância, correção factual nem autorização. Guarde a versão do modelo, dimensões e identidade do trecho; trocar o modelo normalmente exige reindexação planejada. Para códigos, nomes, datas e mensagens de erro exatas, a busca lexical pode ser melhor. Busca híbrida combina sinais e pode usar reranking se custo e latência compensarem.
Aplique filtros de autorização antes de enviar conteúdo ao modelo. Use organização, público, estado do documento e vigência como metadados e teste consultas entre clientes de forma explícita. Não se corrige uma falha de acesso pedindo ao modelo que ignore passagens que nunca deveria ter recebido.
Avalie a busca separadamente da resposta
Monte um conjunto representativo de perguntas reais com documentos ou passagens esperadas. Meça se a evidência correta aparece entre os primeiros resultados e se filtros de acesso funcionam. Depois avalie a resposta gerada: aderência às fontes, relevância, completude e precisão das citações. Acompanhe busca e geração separadamente para que uma resposta fluente não esconda uma recuperação ruim.
Inclua casos comuns e adversariais: pergunta sem resposta no acervo, versões conflitantes, regra vencida, termos ambíguos, tabelas, perguntas em outros idiomas e instruções maliciosas dentro de arquivos. Defina quando o sistema deve se abster, pedir esclarecimento ou chamar uma pessoa. Classifique falhas por etapa e repita os mesmos testes depois de cada mudança.
Faça as citações ajudarem quem lê
Exiba título, versão ou data, seção/página e link estável da fonte. A citação deve apontar para a passagem que sustentou a resposta, não apenas para um arquivo com título parecido. Mantenha o vínculo entre trecho e posição original para mostrar contexto e permitir conferência. Se a busca não encontrou evidência suficiente, não invente certeza com conhecimento geral do modelo.
Em resumo
Um RAG confiável combina ingestão governada, busca inspecionável e geração avaliada. Preserve identidade, permissões e procedência; extraia a estrutura; teste segmentação e busca híbrida; meça recuperação separadamente da resposta e trate abstenção como resultado válido. O banco vetorial é um componente, não a arquitetura inteira.