RAG Frameworks: What They Decide for You
The abstractions each framework imposes, and which pipeline decisions it takes out of your hands.
A RAG framework is an abstraction layer around ingestion, indexing, retrieval and orchestration, and its main effect is not model quality by itself but which pipeline decisions it hides, automates or constrains. This hub defines that abstraction layer once, then routes you to the framework profile or decision page that fits the question you actually have.
What does a RAG framework actually decide for you?
A framework decides how documents become nodes or chunks, how retrievers and tools are wired together, and how much of the pipeline you can inspect or override when something breaks. That is why frameworks can speed up a first build while making debugging harder later: the abstraction removes glue code, but it also moves important retrieval behavior behind its own interfaces. In practice, the choice usually turns on indexing depth, orchestration breadth and how much raw control you want to keep.
Which framework properties matter most for RAG?
Three properties matter more than GitHub stars. Indexing and retrieval depth decide how much control you get over corpus structure and query-time behavior. Orchestration and agent tooling decide whether the framework fits tool-using or stateful systems. Dependency churn and debugging surface decide how expensive the abstraction becomes once the demo grows up. If you are already deciding among LangChain, LlamaIndex and building from scratch, the verdict page is LangChain vs LlamaIndex vs Building It Yourself.
Which RAG frameworks does this site cover here?
This site covers the frameworks that recur most often in practical RAG choices, with one-line promises instead of star-count marketing.
Adjacent framework pages go deeper on narrower jobs without collapsing this hub into another round-up: LangGraph for stateful agent runtimes, DSPy for compile-your-prompts programs, and Semantic Kernel for Microsoft/.NET plugin agents.
When should you go to the framework decision page instead of this hub?
Go to the decision page when you are actively choosing between LangChain, LlamaIndex and building it yourself for a live project. This hub defines the abstraction layer and routes to profiles. The decision page gives the verdict-first comparison and asks the one question most listicles bury: are you solving orchestration or indexing?
What is a RAG framework?
A RAG framework is an abstraction layer around ingestion, indexing, retrieval and orchestration. Its main effect is not to make a model smarter by itself, but to decide which parts of the pipeline are automated, hidden behind interfaces, or easier to compose.
Do you need a framework to build RAG?
No. A framework is optional scaffolding, not the definition of RAG. Teams often start without one when they want direct control over chunking, retrieval and debugging, then adopt a framework later when orchestration complexity starts to dominate.
What is the difference between LangChain and LlamaIndex?
The cleanest distinction is the bottleneck each one fits best. LangChain is usually the stronger fit when orchestration, tool use and broader application workflows dominate. LlamaIndex is usually the stronger fit when indexing and retrieval over a document corpus dominate.
Which RAG framework should I choose?
Choose based on the abstraction problem you need solved, not on GitHub-star roundups. If the question is broad orchestration, LangChain often fits better. If the question is document indexing and retrieval depth, LlamaIndex often fits better. If the main need is raw control and fewer dependencies, building without a framework may be the better path.