{"slug": "hexagonal-architecture-for-provider-agnostic-rag-pipelines", "title": "Hexagonal Architecture for Provider-Agnostic RAG Pipelines", "summary": "A developer built a provider-agnostic RAG pipeline using hexagonal architecture, decoupling the application from specific LLMs, vector databases, and document-processing frameworks through lazy imports and abstract interfaces. The demo stack combines LangChain, llama.cpp, Mistral.ai, Qwen embeddings, PostgreSQL with pgvector, and Telegraf/Prometheus observability on Docker, with the full implementation published on GitHub as yoga1290/rag.", "body_md": "Demo stack: LangChain, Llama.cpp, Mistral.ai, Qwen Embeddings, PostgreSQL, Telegraf, Prometheus on Docker.\n\nI recently came across [**Machine Learning Mastery's guide**](https://machinelearningmastery.com/building-a-rag-pipeline-with-llama-cpp-in-python/) on **Building a RAG Pipeline with llama.cpp** and decided to try it myself.\n\nOne thing quickly became apparent: some of the APIs and methods used in the example had already changed or become deprecated.\n\nThat led me to a bigger question:\n\n**How do you design a RAG system that can evolve as the underlying technologies change?**\n\nInstead of tightly coupling the application to a specific LLM, vector database, or document-processing framework, I experimented with a more modular architecture.\n\nThis way I get a more resilient architecture, for instance if I need a transition between local on-premise to fully on cloud or just hybrid; ability to switch to different database like PostgreSQL instead of ChromaDB, due to the data integration and ACID compliance!\n\nA few principles became particularly important:\n\n``` python\ndef importOnCall(..):\n    from.. import .. # Lazy import\n    return ResultModel(..) # tied to Abstracts & Models\nvectorstore: VectorStore = PGVectorStore(...)\nvectorstore: VectorStore = OtherVectorDBService(..)\n```\n\n**🛠️ Separation of responsibilities**\n\nEach layer has a focused responsibility:\n\n📦️ **Observability, Containerization & Resource/Network monitoring**, Confiurations are pass in form of **Environment Variables**, see [`sample.env`](https://github.com/yoga1290/rag/raw/master/sample.env). **Telegraf** is used to monitor the **resource consumsion** and **network traffic**, and project metrics to **Prometheus**. See the 👁️ Observability section.\n\nThe complete implementation is available on GitHub: `yoga1290/rag`", "url": "https://wpnews.pro/news/hexagonal-architecture-for-provider-agnostic-rag-pipelines", "canonical_source": "https://dev.to/yoga1290/hexagonal-architecture-for-provider-agnostic-rag-pipelines-4p67", "published_at": "2026-09-25 15:50:46+00:00", "updated_at": "2026-09-25 16:01:08.769806+00:00", "lang": "en", "topics": ["ai-tools", "large-language-models", "ai-infrastructure", "mlops", "developer-tools"], "entities": ["LangChain", "llama.cpp", "Mistral.ai", "Qwen", "PostgreSQL", "Telegraf", "Prometheus", "GitHub"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/hexagonal-architecture-for-provider-agnostic-rag-pipelines", "markdown": "https://wpnews.pro/news/hexagonal-architecture-for-provider-agnostic-rag-pipelines.md", "text": "https://wpnews.pro/news/hexagonal-architecture-for-provider-agnostic-rag-pipelines.txt", "jsonld": "https://wpnews.pro/news/hexagonal-architecture-for-provider-agnostic-rag-pipelines.jsonld"}}