RAG_Techniques: The Repo That Teaches You Retrieval Is a Decision System

From HyDE to agentic loops and evaluation, this collection shows why advanced RAG is less about prompting a model and more about shaping what the model sees, when it sees it, and how you know it worked.

10 to 12 min read • View on GitHub • More from NirDiamant

A wide editorial scene of a researcher facing a split retrieval machine. One path feeds a short question straight into a search box and returns a thin stack of documents. The other path turns that question into a denser surrogate, then routes it through multiple retrieval lines before an answer emerges. The image explains that advanced RAG is signal engineering, not just lookup. — The core idea in the repo is simple to miss: the user’s question is not always the best retrieval object.

Key Takeaways

RAG_Techniques argues that retrieval is a design problem, not a single API call, because the best search object is often a rewritten or synthetic query.
The repo works because it pairs intuition with runnable code, so learners can see the same technique as a notebook, a script, and an evaluation path.
Its quiet superpower is the shared helper layer, which turns dozens of techniques into variations on one ingestion and indexing backbone.
Evaluation is treated as part of the system, not an afterthought, which is what turns the collection into an engineering playbook instead of a demo dump.

The first surprise: the question is not the retrieval target

Most RAG demos teach a simple reflex. Embed the user question, fetch the nearest chunks, stuff them into a prompt, hope for the best. RAG_Techniques starts by challenging that reflex. Its HyDE notebook makes the case that a short question often searches badly, while a synthetic answer-like document can search much better.

That idea changes the mental model. The query is no longer a fixed input. It becomes one stage in a retrieval decision system, where the job is to shape the signal before the database ever sees it.

A close editorial illustration of a small question seed being pressed into a printing press and emerging as a dense hypothetical document. The dense page then attracts a cluster of retrieval magnets much more strongly than the original question. The image explains why query rewriting can outperform direct search in semantic space. — HyDE is the repo’s clearest proof that better retrieval can start by changing the shape of the question.

A cookbook built for both learners and deployers

The repository is organized like a teaching lab, but one that respects production constraints. The notebooks in all_rag_techniques/ are for intuition. The runnable scripts in all_rag_techniques_runnable_scripts/ are for reuse. The evaluation/ folder turns the project from a gallery of ideas into something you can measure.

That split is the first sign that this is not a loose collection of experiments. It is a curriculum with a deployment path.

The repo is engineered around reuse. The same plumbing supports learning, scripts, and evaluation.

Layer	What it does	Why it matters
Notebooks	Explain each technique in a readable, runnable form	They make the idea visible before the implementation gets abstract
Helper functions	Standardize loading, splitting, cleaning, embedding, and FAISS indexing	They remove boilerplate so the technique stays the focus
Runnable scripts	Translate the notebooks into command-line Python	They make the examples easier to integrate into real workflows
Evaluation	Score faithfulness and relevance	They answer the only question that matters after the demo: did it work?

Why the helper layer matters

The quiet center of the codebase is helper_functions.py. It standardizes the boring parts that every advanced RAG technique needs: ingest, split, clean, embed, index, retrieve. That matters because the differences between HyDE, hybrid search, semantic chunking, and agentic retrieval only read clearly when the plumbing stays consistent.

# Shared pipeline pattern in the repo
# Load -> Split -> Clean -> Embed -> Index -> Retrieve

def encode_pdf(path):
    docs = load_pdf(path)
    chunks = split_docs(docs)
    clean_chunks = clean_text(chunks)
    vectors = embed(clean_chunks)
    index = build_faiss_index(vectors)
    return index.as_retriever()


def encode_from_string(text):
    chunks = split_text(text)
    clean_chunks = clean_text(chunks)
    vectors = embed(clean_chunks)
    index = build_faiss_index(vectors)
    return index.as_retriever()

That pattern is the real architecture lesson. Advanced RAG is not defined by one clever retrieval trick. It is defined by how many decision points you are willing to own around the trick.

Advanced RAG is really a family of retrieval tricks

The repo’s breadth is its argument. Hybrid search combines dense and sparse signals. Semantic and proposition chunking try to preserve meaning before retrieval starts. HyDE rewrites the query into something search engines can actually use. Agentic retrieval asks whether the context is enough before the system answers. Self-RAG critiques retrieval quality. GraphRAG changes the retrieval substrate entirely. Multimodal retrieval widens the input surface.

These are not random variations. They are responses to different failure modes. Short questions under-specify intent. Chunking can shred meaning. Dense retrieval can miss exact terms. A single pass can return plausible but insufficient context. The repo is valuable because it frames each technique as a targeted repair.

The most teachable way to read it is as a ladder: first improve the query, then improve the signal mix, then improve the chunk shape, then let the system decide whether to loop again.

How the retrieval loop changes the game

The shift from naive to advanced RAG is a shift from one search to many searches. A user question can be rewritten, expanded into a hypothetical document, routed through dense retrieval, paired with BM25, checked for sufficiency, and then scored after the fact. The system is no longer asking only, “What matches this query?” It is also asking, “Should we trust what we found?”

Technique family	Primary move	Failure mode it addresses
Query rewriting	Turn the question into a better search surrogate	Short queries that do not embed well
Hybrid retrieval	Combine sparse and dense signals	Semantic misses and exact-term misses
Chunking strategies	Split text to preserve meaning	Bad boundaries that erase context
Agentic loops	Let the model decide whether to read again	Answers built on weak or incomplete evidence

The repo’s most underrated move: evaluation is treated as first-class

A lot of RAG content stops at retrieval. This repo does not. Its evaluation/ directory makes faithfulness and relevance part of the workflow, not a postscript. That is the difference between a tutorial and an engineering system.

A community-driven hub of 42+ runnable notebooks covering RAG techniques from foundational to cutting-edge - the intuition, the code, and the references to build more accurate, context-rich retrieval systems.

Nir Diamant, Author/Maintainer · GitHub - NirDiamant/RAG_Techniques

That quote is the repo in one sentence. Intuition, code, and references are all present. The evaluation folder is what makes the promise credible. It says the project is not satisfied with a working notebook. It wants evidence that the notebook improved the answer.

Question	Demo-first RAG	Evaluated RAG
Did it run?	Yes	Yes
Did it answer well?	Sometimes	Measured
Did it stay faithful?	Unknown	Scored
Can we compare techniques?	Not reliably	Yes

What this repo is really competing with

This repository does not compete with LangChain or LlamaIndex on framework power. It competes on pedagogy and scope. Framework docs tell you what is possible inside a toolkit. RAG_Techniques shows you how to think across techniques, and when one path is better than another.

That puts it in a strange and useful niche. It is broader than a single-method repo like GraphRAG or MemoRAG. It is more opinionated than docs. It is less about building the plumbing from scratch and more about helping you choose the right plumbing in the first place.

Resource	Best for	Main strength	Main limitation
RAG_Techniques	Teams learning advanced retrieval choices	Breadth plus runnable examples	Not a production framework
LangChain docs	Builders wiring RAG into apps	Ecosystem and integrations	Technique comparison is scattered
LlamaIndex docs	Ingestion and retrieval workflows	Strong retrieval primitives	Less like a curriculum
GraphRAG / MemoRAG	Single advanced approach	Depth on one method	Narrower learning surface

Why it matters now

The industry has moved past simple RAG demos. Teams need to defend their retrieval choices, not just ship them. That is why this repo lands so well: it teaches a practical way to think about retrieval as a chain of decisions, then gives you code paths and scoring hooks to back those decisions up.

The value is not only that it covers many techniques. It is that it normalizes the idea that retrieval can be rewritten, mixed, checked, looped, and judged. Once you see RAG that way, the naive version starts to look less like a baseline and more like a shortcut.