Thanks Patrick for a very good question, and I appreciate the nuance you're bringing to this!

When I used the term “types” in the blog, I aimed to highlight distinct approaches or flavors of RAG that can serve different purposes… -

Thanks Patrick for a very good question, and I appreciate the nuance you're bringing to this!

When I used the term “types” in the blog, I aimed to highlight distinct approaches or flavors of RAG that can serve different purposes depending on the specific use case or system constraints. However, I completely agree with your point—these are not rigid categories that demand exclusivity. In practice, many of these can indeed be thought of as modular techniques or building blocks that can be combined to create more powerful and versatile RAG systems.

For example, as you rightly pointed out, Agentic RAG’s dynamic tool usage can seamlessly complement the iterative refinement of Self-RAG. In fact, many production-grade systems employ a hybrid approach—blending aspects of Graph RAG for structured data, Memory-Augmented RAG for session retention, and Agentic RAG for real-time decision-making.

So to clarify:

“Types” in the blog serves more as a framework to explain different capabilities and how they fit into RAG design.

In practical terms, these are better approached as techniques or modular patterns that can be mixed, matched, and layered to optimize performance.

I’d recommend treating them as complementary elements in your RAG design, allowing you to craft solutions that are not just functional but adaptive and context-aware. Flexibility is key, and the ability to mix Agentic RAG with Self-RAG—or even combine Streaming RAG with Graph RAG—can result in more responsive, intelligent systems.

If you have a specific use case in mind, I’d love to dive deeper into how different techniques can be fused to build a robust RAG architecture for that scenario.