You already built a framework (the small version)

Across this track you hand-wrote every stage of RAG: chunk_by_tokens, an embedding call, an index, a retrieve, an answer, plus hybrid fusion, reranking, and an eval harness. A "RAG framework" is just those stages, packaged as reusable, swappable components with connectors to dozens of vector stores and models. Nothing here is new capability — it's less glue code and more batteries included, at the cost of a layer of abstraction between you and the mechanics.

Here's the mapping — read it as "the thing you wrote → the thing the framework calls it":

Your hand-rolled code	LangChain	LlamaIndex
chunk_by_tokens / recursive_split	TextSplitter (e.g. RecursiveCharacterTextSplitter)	NodeParser / SentenceSplitter
embed()	Embeddings	embed_model
the (text, vector) index	VectorStore	VectorStoreIndex
retrieve()	Retriever	Retriever / query_engine
rerank / MMR	retriever search_type / ContextualCompression	NodePostprocessor (reranker)
the answer() prompt+LLM	PromptTemplate → LLM (LCEL)	response_synthesizer
the eval harness	LangSmith evals	LlamaIndex evaluators

LlamaIndex — index-first

LlamaIndex is built around retrieval. Its happy path gets you a working RAG in a handful of lines because the index owns chunking, embedding, storage, and query orchestration:

from llama_index.core import VectorStoreIndex, SimpleDirectoryReader

docs = SimpleDirectoryReader("./corpus").load_data()   # load files from a folder → Documents
index = VectorStoreIndex.from_documents(docs)          # chunk + embed + index, all in one call
query_engine = index.as_query_engine(similarity_top_k=4)  # a retriever + generator bundled together
print(query_engine.query("What does the Pro plan cost?"))  # retrieve top-4 → generate a grounded answer

That one from_documents call hides the entire embed→chunk→index loop from RAG Fundamentals. You trade visibility for speed — great for getting to a baseline fast, and its data connectors (100+ loaders for PDFs, Notion, Slack, SQL, …) are its real strength.

LangChain — composition-first (LCEL)

LangChain is built around composition. Its LCEL (LangChain Expression Language) pipes components with |, so a RAG chain reads as a data flow you assemble explicitly:

from langchain_core.runnables import RunnablePassthrough
from langchain_core.output_parsers import StrOutputParser

# `retriever`, `prompt`, and `llm` are components built earlier (a vector store's retriever, a PromptTemplate, a chat model).
rag_chain = (
    {"context": retriever, "question": RunnablePassthrough()}   # run retriever on the input; pass the question through unchanged
    | prompt                                                     # fill the prompt template with {context, question}
    | llm                                                        # generate
    | StrOutputParser()                                          # pull the plain string out of the model message
)
rag_chain.invoke("What does the Pro plan cost?")                 # runs the whole pipe end to end

The win is explicit control and composability: every stage is visible and swappable, streaming and async come for free, and the same idiom extends into agents and tools (the Agentic Engineering track). The cost is a steeper learning curve and more moving parts than LlamaIndex's index-first path.

Choosing — and the third option

	LlamaIndex	LangChain	Hand-roll
Best when	RAG/search is the core; you want fast indexing + many data loaders	complex multi-step chains/agents; you want explicit control	a simple, stable pipeline you fully understand
Strength	index-first ergonomics, connectors	composition, agents, ecosystem	zero abstraction, zero dependency risk, total control
Cost	less control over the internals	more concepts, faster-moving API	you maintain the glue and the connectors

They aren't mutually exclusive — teams routinely use LlamaIndex for ingestion/retrieval inside a LangChain agent. And "hand-roll" is a legitimate answer: you've seen that a competent RAG core is ~40 lines. If your pipeline is a single vector store, a fixed prompt, and no agentic branching, a framework can be more code and a moving dependency for no gain.

Keeping it swappable

Whichever you pick, wrap the framework behind your own thin interface (retrieve(question) -> chunks, answer(question) -> str) so your application code doesn't depend on framework classes directly. Then a framework migration — or a drop back to hand-rolled — touches one adapter, not your whole codebase. The evaluation harness from the last topic is what makes such a swap safe: run the golden set before and after and confirm the scorecard didn't regress.

Pitfalls

• Reaching for a framework reflexively. For a simple, stable pipeline it can be more code and a moving dependency than the ~40 lines you understand.
• Letting framework classes leak everywhere. Bind your app to your own retrieve/answer interface, not to VectorStoreIndex or LCEL runnables, so you can swap later.
• Copying tutorial imports blindly. These APIs change fast — verify against current docs, don't trust a months-old snippet (including this one).
• Skipping eval after adoption. Moving to a framework changes defaults (chunking, k, prompt); re-run the golden set to confirm quality held.
• Framework lock-in as a decision. Neither library is a one-way door if you keep the adapter thin.

Recap

• A RAG framework is the same embed → chunk → index → retrieve → generate stages you hand-built, packaged as reusable, connector-rich components.
• LlamaIndex is index-first — fastest path to a retrieval baseline, strongest data connectors.
• LangChain is composition-first (LCEL) — explicit, swappable stages that extend into agents; more concepts, faster-moving API.
• Hand-rolling is valid: a competent RAG core is ~40 lines; a framework earns its place when you need connectors, agentic complexity, or built-in streaming/observability/eval.
• Keep the framework behind a thin adapter and re-run the golden set after any swap.
• Worked examples map to the exercises: LlamaIndex 5-line RAG (Ex 1), LangChain LCEL chain (Ex 2), the hand-rolled→framework mapping + component swap (Ex 3), and the framework-vs-hand-roll decision (Ex 4).

from llama_index.core import VectorStoreIndex, SimpleDirectoryReader

docs = SimpleDirectoryReader("./corpus").load_data()        # load every file in ./corpus as Documents
index = VectorStoreIndex.from_documents(docs)               # chunk + embed + index in one call
qe = index.as_query_engine(similarity_top_k=4)              # bundle retriever + generator
print(qe.query("What does the Pro plan cost?"))             # grounded answer from the top-4 chunks

from langchain_core.runnables import RunnablePassthrough
from langchain_core.output_parsers import StrOutputParser

retriever = vectorstore.as_retriever(search_kwargs={"k": 4})      # baseline similarity retriever
rag = ({"context": retriever, "question": RunnablePassthrough()}
       | prompt | llm | StrOutputParser())
print(rag.invoke("What does the Pro plan cost?"))

# Swap to MMR for diversity — only the retriever line changes; the chain is untouched:
retriever = vectorstore.as_retriever(search_type="mmr", search_kwargs={"k": 4, "fetch_k": 20})
rag = ({"context": retriever, "question": RunnablePassthrough()}
       | prompt | llm | StrOutputParser())

from langchain.retrievers import ContextualCompressionRetriever
# Wrap your existing cross-encoder as a compressor, then layer it over the base retriever:
compression = ContextualCompressionRetriever(base_compressor=my_reranker, base_retriever=retriever)
rag = ({"context": compression, "question": RunnablePassthrough()} | prompt | llm | StrOutputParser())