Welcome to PromptMan Discussions!

[VeryComplexAndLongName]

I’ve been working on an open-source Python project called ragflow_orchestrator focused on modular and database-agnostic RAG infrastructure.

Repository:
https://github.com/VeryComplexAndLongName/RagOrchestrator

The original goal was surprisingly simple:

Build a retrieval system that can be integrated into existing applications without forcing an entire AI framework ecosystem.

A few design decisions that shaped the project:

• SQLite / PGVector / Qdrant support
• abstract storage + retrieval layers
• pluggable embeddings
• pluggable retrievers
• pluggable cleaners
• optional reranking
• hybrid retrieval
• deterministic fallback paths
• minimal required parameters
• local/offline-friendly execution

One important architectural decision:

• The system avoids mandatory LLM usage for most pipeline stages.
• LLMs are used only where they actually add meaningful value.

The project already contains:

• integration tests
• runnable scripts
• ingestion examples
• retrieval benchmarks
• migration tooling
• profiling utilities
• PromptOrchestrator interoperability

While building this, I kept running into the same question:

Why are so many RAG systems tightly coupled to:

• a single provider,
• a single orchestration style,
• or a single vector database?

In production systems, flexibility usually matters more than framework completeness.

Some discussion topics I’d genuinely love feedback on:

• Are lightweight retrieval-first systems becoming more practical than agent-heavy architectures?
• How are people handling migrations/versioning in vector stores today?
• Should retrieval orchestration live inside AI frameworks or remain infrastructure-level?
• Are database-agnostic retrieval layers worth the abstraction cost?
• How much of modern RAG complexity actually comes from orchestration rather than retrieval itself?

Curious how others are approaching these problems in real-world systems.