EstevezAlvarez
Engenharia de RAG

RAG 2: documentos com identidade, estrutura e proveniência

O que preservar de um documento oficial ou empresarial antes de dividi-lo em trechos e produzir embeddings.

Neste artigo

Um buscador pode encontrar um parágrafo convincente e ainda devolver a versão errada. Na revisão da Taesa, essa confusão é uma hipótese que precisa de rankings e exemplos revisados; os CSVs históricos não identificam cada causa. Minha proposta começa por tornar verificável a identidade dos documentos. Assim poderei investigar a falha em vez de atribuí-la automaticamente ao embedding.

O arquivo, a versão e a família

Dou um identificador estável a cada documento, outro à sua versão e outro à família quando vários arquivos pertencem ao mesmo caso. Guardo origem, emissor, tipo, data de publicação, data de captura e hash. Quando pertinente, registro vigência e relações de alteração, mas com fonte e estado de verificação. Publicação recente não significa substituição automática de tudo que veio antes.

Duplicatas exatas podem compartilhar conteúdo armazenado sem perder suas diferentes origens. Versões quase iguais não devem desaparecer por uma deduplicação agressiva: uma data, uma exceção ou um valor podem ser justamente o que muda a resposta. O manifesto também deve registrar o que não entrou no índice e por quê.

Preservar três representações

Preservo o original, uma extração estruturada e a representação de busca. Cada transformação registra parser, versão, configuração e relação com o arquivo anterior. Em PDF reviso ordem de leitura, tabelas, notas, sinais e unidades. Uma extração extensa não garante que as colunas estejam corretamente associadas. Os erros vão para uma fila de revisão, não para uma exclusão silenciosa.

{
  "document_id": "doc-001",
  "version_id": "doc-001-v2",
  "family_id": "case-017",
  "chunk_id": "doc-001-v2-section-3-p2",
  "source_locator": {"page": 8, "section": "3.2"},
  "valid_from": null,
  "validity_status": "unverified",
  "original_text": "...",
  "generated_context": null,
  "access_policy_id": "policy-017"
}

Dividir sem apagar as relações

Minha primeira comparação seria entre uma divisão simples por tamanho e outra por seções, artigos, cláusulas e tabelas. Manteria um vínculo entre cada trecho e sua unidade superior para ampliar o contexto depois da recuperação. Não separaria deliberadamente uma regra de sua exceção nem um número de sua unidade. Se uma seção ultrapassar o limite, a subdivisão preserva cabeçalhos e referências.

As tags começam pequenas: tipo documental, entidade, assunto e estado. Distingo o metadado explícito na fonte, o derivado por regra e o inferido por modelo. Uma tag inferida pode ajudar na ordenação, mas transformá-la em filtro obrigatório pode eliminar evidência relevante. Vigência e permissões não são deduzidas de um resumo gerado.

Akoma Ntoso oferece uma referência para estrutura e metadados normativos. Adotar seus princípios não exige implementar toda a especificação. Para aprovar esta etapa eu exigiria rastreabilidade de cada citação ao original, revisão de uma amostra de extrações difíceis e um relatório de perdas por tipo documental. O percentual desejado depende do risco e deve ser definido antes de comparar modelos.

OASIS: estrutura e metadados Akoma Ntoso

Caso Taesa: limites do diagnóstico original

Um preprint de setembro de 2026 avalia conjuntamente parser, chunking e embedding em quatro documentos regulatórios indianos. Encontra interações: a melhor combinação não é deduzida do ranking isolado de cada componente. Suas perguntas são geradas por LLM, com revisão manual de uma amostra, e não avalia respostas finais. Para a Taesa, isso sugere uma pequena comparação fatorial depois do diagnóstico inicial; milhares de avaliações sobre quatro documentos não representam milhares de contextos regulatórios independentes.

Interações entre parser, chunking e embedding

Baixar scripts, manifesto e documentação da revisão

Voltar ao índice do blog