← Voltar a RAG — Arquitetura de Ingestion e Retrieval

📥 Ingestão — Visão Geral

RAG — Arquitetura de Ingestion e Retrieval

Apresentação

Arquitetura de Ingestion

Visão Geral

Esta documentação descreve uma arquitetura completa de ingestion para sistemas RAG, pensada para suportar:

  • Retrieval responde: "Como é que encontro e componho a resposta?"
  • Ingestion responde: "Como é que os dados entram, mudam, são versionados, validados e ficam prontos para retrieval?"

Benefícios

ObjetivoResultado
ConsistênciaAlinhamento entre docs, SQL e graph
Atualização incrementalSó reprocessar o que mudou
Menos reindexaçõesDiff por chunks, reusar embeddings
Histórico e auditabilidadeVersioning, lineage, valid_from/valid_to
Freshness-aware retrievalMetadata para queries temporais

Suporte

  • Ficheiros: YAML, MD, PDF, JSON, CSV
  • SQL (tabelas, schemas, watermarks)
  • Graph (nós, relações, propriedades)
  • Alterações ao longo do tempo
  • Reprocessamento parcial
  • Versioning
  • Observability

Documentação

DocumentoConteúdo
01-ARCHITECTUREDiagrama geral, blocos principais, regra de ouro
02-CANONICAL-MODELDocumentRecord, StructuredRecord, GraphRecord
03-PIPELINESDocument, SQL e Graph pipelines
04-SCENARIOSAlterações ao longo do tempo (9 cenários)
05-REGISTRY-DEPENDENCIESAsset registry e dependency tracking
06-VERSIONING-REPROCESSINGEstratégias de versioning e rebuild
07-RETRIEVALLigações com retrieval
08-OBSERVABILITYMétricas, logs, alertas
09-MODULESEstrutura de módulos recomendada
10-EXAMPLESFluxos completos com exemplos
11-THEORY-IMPLEMENTATIONTeoria vs implementação atual, gaps, prioridades
12-ADVANCED-INGESTION-TECHNIQUESParent-child, OCR, tabelas, semantic chunking, dedupe

Regra de Ouro

Nunca enviar uma fonte diretamente para vector DB / SQL / graph sem passar por um modelo canónico intermédio.

Ou seja:

  • PDF entra → normaliza para DocumentRecord
  • YAML entra → normaliza para DocumentRecord ou StructuredRecord
  • CSV entra → normaliza para StructuredRecord
  • Tabela SQL entra → normaliza para StructuredRecord
  • Graph export entra → normaliza para GraphRecord

Tudo passa primeiro por uma representação interna comum. Isto evita caos.


Resumo para Entrevista

"Eu separaria ingestion de retrieval, mas ligaria os dois através de metadata, versioning e dependency tracking. A ingestion teria loaders por tipo de fonte, um bloco de change detection, normalização para um modelo canónico e pipelines específicos para documentos, SQL e graph. Para documentos, usaria versioning e diff por chunks para reindexação incremental. Para SQL, combinaria upserts com SCD Type 2 nas entidades importantes. Para graph, controlaria diffs de nós e relações com noção de validade temporal. Tudo seria registado num asset registry com lineage e dependências, para saber exatamente o que reprocessar quando uma fonte muda."

Zona de prática

Sem perguntas. Clica em Editar para adicionar.