← Voltar a RAG — Arquitetura de Ingestion e Retrieval

📐 Teoria vs Implementação

RAG — Arquitetura de Ingestion e Retrieval

Apresentação

11. Teoria vs Implementação — O Que Está Planeado

Este documento mapeia o que está desenhado na arquitetura de ingestion vs o que está implementado hoje. Útil para artigos e planeamento.

1. Estado Geral

A documentação em ingestion/ descreve uma arquitetura completa pensada para produção. A implementação atual em ingest-rag/ é parcial — foca-se em:

Documentos Markdown → Chroma (via script ingest_docs.py)
Sem change detection, sem versioning, sem modelo canónico
Sem SQL pipeline, sem graph pipeline
Sem registry, dependency tracking, observability

2. Por Bloco

Bloco A — Data Sources

Fonte	Teoria	Implementação
Markdown	✅ Loader, chunking	✅ `ingest_docs.py`
PDF	✅ Loader planeado	❌
YAML, JSON, CSV	✅ Loaders planeados	❌
SQL tables	✅ SqlTableLoader	❌ (dados vêm de adaptive-rag/seed)
Graph	✅ GraphLoader	❌ (Neo4j seed externo)
APIs	✅ Futuro	❌

Bloco B — Source Connectors

Loader	Teoria	Implementação
MarkdownLoader	Interface definida	Implícito em `ingest_docs.py`
Outros	Módulos em `loaders/`	❌

Bloco C — Change Detection

Funcionalidade	Teoria	Implementação
Hash/checksum	✅	❌
New/updated/deleted	✅	❌ (sempre full reindex)
Schema diff (SQL)	✅	❌
Graph diff	✅	❌

Bloco D — Canonical Normalization

Record	Teoria	Implementação
DocumentRecord	✅ Schema completo	❌ (chunks vão direto para Chroma)
StructuredRecord	✅	❌
GraphRecord	✅	❌

Bloco E — Pipelines

Pipeline	Teoria	Implementação
Document	Versioning, chunk diff, reindex parcial	Chunking + embed + upsert total
SQL	Validate, upsert, SCD2	❌ (seed externo)
Graph	Node/edge diff, versioning	❌ (seed externo)

Bloco F — Metadata e Observability

Funcionalidade	Teoria	Implementação
Asset registry	✅ Schema completo	❌
Lineage store	✅	❌
Dependency tracker	✅	❌
Métricas por run	✅	❌
Logs estruturados	✅	❌
Alertas	✅	❌
Reindex triggers	✅	❌

3. Cenários — Estado

Cenário	Teoria	Implementação
MD alterado	Diff, version, reindex parcial	Full reindex manual
PDF novo	Fingerprint, version	❌
YAML em cascata	Dependency-driven	❌
Nova linha SQL	Watermark, upsert	Seed único
Update SQL	SCD2	❌
Relação graph muda	Edge versioning	❌
Documento apagado	Soft delete	❌
Chunking strategy muda	Nova index_version	❌
Embedding model muda	Nova coleção	❌

4. O Que Existe Hoje (ingest-rag)

Script scripts/ingest_docs.py:
- Lê .md de data/generated/docs
- Chunking fixo (600/100)
- Embedding com sentence-transformers
- Upsert em Chroma (coleção "docs")
Dados: symlink ou copy de adaptive-rag/data/generated
Sem change detection: cada run reindexa tudo
Sem metadados version/freshness nos chunks

5. Prioridade para Implementação

Ordem	Componente	Impacto	Depende de
1	Change detection (hash)	Evitar reindex desnecessário	—
2	DocumentRecord canónico	Base para diff e versioning	—
3	Chunk diff	Reindex parcial	1, 2
4	Asset registry (mínimo)	Saber o que está indexado	—
5	Loaders PDF, YAML	Mais fontes	—
6	SQL pipeline	Dados estruturados	adaptive-rag
7	Graph pipeline	Relações	adaptive-rag
8	Dependency tracker	Cascatas	4
9	Observability	Produção	4

6. Resumo para Artigo

"A arquitetura de ingestion está completamente especificada em teoria: 6 blocos (Sources → Connectors → Change Detection → Canonical → Pipelines → Metadata), 3 tipos de Records (Document, Structured, Graph), versioning, dependency tracking, e ligação com retrieval via metadados de freshness. A implementação actual cobre apenas o path mais simples: documentos Markdown → chunking → Chroma, sem change detection nem versioning. O gap principal é o modelo canónico e a change detection, que permitiriam reindexação incremental e consistência com SQL/graph. A documentação serve como blueprint para evoluir a implementação de forma ordenada."

Zona de prática

Sem perguntas. Clica em Editar para adicionar.