Proveniência de dados para sistemas RAG
Uma citação diz ao leitor onde procurar. Proveniência explica qual versão exata da fonte, transformação, chunk, índice, decisão de retrieval e contexto do modelo produziu o claim lido.
Uma URL não é proveniência suficiente
O artigo original de RAG, de Patrick Lewis e coautores, descreveu geração apoiada em memória não paramétrica explícita e colocou proveniência entre as motivações. Em produção, exibir uma URL ajuda, mas é incompleto. Uma página muda, um PDF é substituído, o criador desaparece e uma citação pode apontar para documento que não sustenta o claim próximo.
Proveniência útil responde a uma pergunta de reprodutibilidade: qual evidência exata estava disponível no momento da resposta? Preserve identidade imutável, hash, versão ou timestamp, autor ou criador, publisher, licença, acesso, parser, chunks, embedding, snapshot do índice, transformações da query, ranking, contexto, prompt, modelo, claims e mapeamento de citações.
OrigemO usuário identifica criador, publisher, fonte canônica, direitos e versão exata?
TransformaçãoOperadores reconstroem parsing, OCR, normalização, chunking, enriquecimento e embedding?
AutorizaçãoACLs e tenants foram respeitados na ingestão, retrieval, cache e resposta?
AtribuiçãoCada claim material aponta para passagens que o sustentam com granularidade útil?
AtualidadeConteúdo alterado, revogado, removido ou substituído pode sair das respostas futuras?
Modele proveniência como entidades, atividades e agentes
W3C PROV oferece um modelo prático: entidades como documentos, chunks, embeddings, índices, prompts e respostas são geradas ou derivadas por atividades como ingestão, chunking, indexação, retrieval e geração, associadas a agentes como criadores, publishers, serviços, usuários e modelos.
OpenLineage captura datasets, jobs, runs e facets extensíveis do pipeline de ingestão. Não substitui lineage de resposta, mas conecta um chunk ou snapshot à execução que os produziu. IDs estáveis são essenciais; nomes de arquivo e URLs de exibição não são identificadores.
Grafo RAG do criador ao claim da resposta
01 FonteCriador e publicaçãoCriador, publisher, URI canônica, data, versão, licença, jurisdição e hash.
02 AdquirirEvento de ingestãoConector, fetch, resposta HTTP, assinatura ou credential, ACL, consentimento e retenção.
03 TransformarDocumento parseadoParser ou OCR, estrutura, normalização, idioma, tabelas, imagens e flags de qualidade.
04 SegmentarLinhagem do chunkID estável, documento pai, intervalo, headings, overlap e versão do chunker.
05 RepresentarEmbedding e índiceModelo, dimensões, hash do vetor, filtros, coleção e snapshot imutável.
06 RecuperarDecisão de seleçãoUsuário, tenant, variantes da query, filtros, scores, reranker, chunks e ordem.
07 GerarContexto da respostaTemplate, modelo, parâmetros, posições, truncamento, tools e ID da resposta.
08 AtribuirClaims e citaçõesSpans do claim e suporte, checks de entailment, confiança, crédito ao criador e link.
Logs de retrieval devem preservar a decisão, não texto sensível bruto
No momento da resposta, registre snapshot do índice, contexto de autorização, filtros, reescrita de query, IDs e scores candidatos, reranker, deduplicação, chunks selecionados, ordem e passagens descartadas. As convenções GenAI do OpenTelemetry incluem eventos de retrieval e IDs de documentos para correlacionar operações.
Não transforme observabilidade em exfiltração. Query, documentos e prompts podem conter dados pessoais ou de tenants. Prefira IDs, hashes, classificações, snippets limitados e evidence stores protegidos. Mantenha proveniência de alta cardinalidade em sistema de auditoria ou lineage, não em métricas normais.
Citações devem ser por claim e reconhecer os criadores
Uma citação deve conectar um claim a spans exatos de suporte. A referência visível deve creditar o criador quando disponível, nomear obra e publisher, mostrar data, apontar para fonte canônica e informar licença ou restrição relevante. Um domínio genérico esconde pessoas e organizações que criaram o conhecimento.
Não permita que o modelo invente referências de memória. Entregue IDs opacos ao gerador e resolva citações no servidor pelo registry. Valide que os chunks estavam no contexto e sustentam o claim. Pesquisas como RAGAS, ARES, ReClaim e CiteFix mostram que relevância, faithfulness e correção de citações são problemas diferentes.
| Falha | Por que parece confiável | Evidência que expõe o problema | Controle |
|---|---|---|---|
| URL correta, versão errada | A página existe, mas mudou após a indexação. | Hash, versão, timestamp, archive ou ID imutável. | Mostre versão usada e detecte source drift antes de reutilizar. |
| Documento correto, claim sem suporte | A citação é relacionada, mas não implica a frase. | Mapeamento claim-spans e resultado do support check. | Validação por claim e abstention quando não houver suporte. |
| Fonte antiga ou revogada | O vetor continua recuperável após remoção ou correção. | Status, evento de remoção, snapshot, caches e respostas afetadas. | Tombstone nos derivados, rebuild, invalidação e replay auditável. |
| Retrieval cross-tenant | A resposta é fluida e talvez não revele a fonte vazada. | Usuário, tenant, ACL, filtros, candidatos e chunks selecionados. | Autorização antes do retrieval, índices security-trimmed e testes de leakage. |
| Criador ou licença perdidos | A resposta aponta para mirror e remove metadados. | Fonte canônica, criador, publisher, licença, aquisição e transformação. | Exija atribuição antes de indexar e preserve-a nos derivados. |
| Contexto distorcido pelo chunk | Passagem aparece sem heading, tabela, ressalva ou exceção. | Intervalo pai, headings, chunks vizinhos, estrutura e ordem. | Chunking estrutural, citações expansíveis e checks de completude. |
| Regressão de índice ou modelo | A mesma query passa a produzir resposta diferente. | Embedding, índice, reranker, prompt, modelo, parâmetros e avaliação. | Replay versionado, comparação por lineage, canário e rollback. |
Remoção e correção precisam percorrer o grafo
Quando uma fonte é corrigida, revogada, expira, muda licença ou recebe solicitação de remoção, encontre todos os chunks, embeddings, snapshots, caches, amostras e respostas derivados. Proveniência permite impact analysis; sem ela, a origem é apagada enquanto derivados antigos continuam respondendo.
Mantenha tombstones e evidência de revogação sem reter conteúdo sensível excluído. Repare índices, invalide semantic caches e marque respostas anteriores como stale quando o suporte deixar de ser válido. O grafo de proveniência também é o grafo de remoção.
A avaliação deve diagnosticar qual estágio falhou
Um score único de qualidade é fraco. Meça atualidade e direitos, recall e relevância do retrieval, leakage de ACL, completude de contexto, faithfulness, precisão e recall de citações, cobertura de criadores e qualidade de abstention. Preserve lineage de cada resultado para ligar regressões a fonte, parser, chunker, embedding, retriever, reranker, prompt ou modelo.
O perfil de IA generativa da NIST recomenda avaliar proveniência em cenários reais e contra métricas definidas. Em RAG, isso significa testar não só se a resposta parece correta, mas se o suporte é rastreável, autorizado, atual e apresentado honestamente.
O que eu construiria
Eu construiria um registry de proveniência com IDs imutáveis para fontes, versões, chunks, embeddings, índices, retrievals, context bundles, respostas, claims e citações. A ingestão emitiria eventos compatíveis com OpenLineage; requests online emitiriam traces ligados ao registry.
A interface mostraria citações concisas e permitiria expandir criador, publicação, versão, licença, passagem exata, horário do retrieval e status de atualidade. Operadores teriam reverse lineage: partindo de fonte ruim ou parser defeituoso, localizar toda resposta afetada.
O princípio de design
Confiança em RAG não nasce de texto com formato de nota de rodapé. Preserve o grafo do criador ao claim, resolva citações a partir de evidência imutável, aplique direitos e autorização a cada derivado e faça correção e remoção percorrerem a mesma linhagem.