Walk through LlamaIndex's Document → Node → Index → QueryEngine pipeline and explain why this shape slots into RAG more naturally than LangChain's Runnable model

LlamaIndex's RAG pipeline has four named stages, and each stage corresponds to a real noun in the RAG workflow. **Document.** The raw input. A PDF, a webpage, a markdown file, a database row. A `Document` object carries the text plus metadata (source path, author, date). It is what comes into the system. **Node.** A chunk derived from a Document. The ingestion pipeline splits Documents into Nodes. Fixed-size text chunks, semantically split chunks, or sentence-level chunks depending on the splitter you pick. Each Node has its own metadata (parent Document ID, position, hash) and is the unit of retrieval. **Index.** The data structure that organises Nodes for fast lookup. The `VectorStoreIndex` embeds Nodes and stores the embeddings; the `KeywordTableIndex` builds an inverted term map; the `TreeIndex` builds a hierarchical summary. You pick the index based on the retrieval shape you need. **QueryEngine.** The callable that takes a user query and returns an answer. Internally it pairs a `Retriever` (pulls candidate Nodes from the Index) with a `ResponseSynthesizer` (composes the final answer from the retrieved Nodes). The equivalent in LangChain is to build a chain like `query | retriever | format | model | parser` from LCEL Runnables. It works, but you are assembling RAG semantics from generic plumbing. LlamaIndex names those concepts directly.

LlamaIndex's four-stage pipeline is named for the RAG nouns themselves, which is what makes the framework feel productive on RAG-shaped problems. **Document.** Raw input plus metadata. Loaders (`SimpleDirectoryReader`, vendor connectors via LlamaHub) produce them. **Node.** A retrievable chunk. `NodeParser` implementations (`SimpleNodeParser`, `SentenceSplitter`, `SemanticSplitterNodeParser`) decide the splitting strategy. Each Node carries its own metadata, position, and embedding handle. **Index.** The organising structure. `VectorStoreIndex` (the default) embeds Nodes and stores them in a vector database; `SummaryIndex` keeps all Nodes for sequential reads; `KeywordTableIndex` builds an inverted term map; `KnowledgeGraphIndex` extracts entities and relations. Each index type implements the same interface, so swapping retrieval shapes is a one-line change. **QueryEngine.** The packaged callable. It bundles a `Retriever` (gives candidate Nodes for a query), an optional list of `NodePostprocessors` (re-ranking, similarity filtering, recency weighting), and a `ResponseSynthesizer` (refine, tree-summarize, accumulate, simple). One call site, one configurable object. The productivity argument over LangChain is not that LangChain cannot do RAG. It can. It is that the default path is shorter in LlamaIndex because the primitives are already RAG-shaped. Response synthesizer strategies, hybrid retrievers, node postprocessors, and metadata filtering are first-class concepts with documented modes. On LangChain you assemble equivalent behaviour by composing generic Runnables, which means more code, more decisions, and a longer ramp.