30 sec6 min coredeep dive optional
RAG techniques, as collected by Nir Diamant’s RAG_Techniques repository, fall into three working groups: how you cut documents, how you retrieve, and how you make the pipeline correct itself, and each group has a notebook you can run today.
- More than 30 techniques, each a runnable notebook, most with LangChain and LlamaIndex variants plus plain Python scripts.
- The chunking family alone spans five approaches, from fixed sizing to proposition chunking.
- Correctness techniques like Reliable RAG and Corrective RAG add checkpoints that catch bad retrievals before they become answers.
- Companion videos and newsletter essays explain the intuition behind many notebooks.
Retrieval-augmented generation has accumulated a intimidating pile of named techniques, and most explanations stop at the acronym. Nir Diamant’s RAG techniques collection, at RAG_Techniques on GitHub, does the opposite: every technique is a notebook you open in Colab, run against real data, and inspect. This guide maps the collection into the three groups that actually matter when you are debugging a pipeline.
We have covered Diamant’s work twice before, his GenAI agents tutorials and his production-agents course, and this repository is the third leg of that curriculum: the retrieval layer those agents depend on. At 29,593 stars and updated this week, it is the reference implementation library for the RAG vocabulary our RAG glossary defines. Where the glossary explains what a term means, the collection shows the term running, with inputs, outputs, and the failure that motivated it, which is the difference between recognizing a technique name and knowing when to deploy it.
Ingestion: the chunking family and its trade-offs
Half the collection’s early entries attack one decision: how a document becomes chunks. The progression is worth reading in order because each technique fixes the previous one’s failure mode:
- Choose Chunk Size: the baseline experiment, showing what fixed sizing costs you in recall and precision.
- Semantic Chunking: cut where the meaning shifts instead of every N characters, so chunks stop splitting mid-thought.
- Proposition Chunking: a model rewrites each chunk as single self-contained facts, trading indexing cost for retrieval precision.
- Contextual Chunk Headers: prepend document context so a chunk that says “it” still embeds what “it” means.
- Contextual Compression: strip the irrelevant span of a retrieved chunk before it reaches the prompt.
The honest takeaway from the notebooks: proposition chunking and contextual headers deliver the biggest jumps for document-heavy corpora, but both add an LLM call per chunk at index time, so re-indexing a large corpus under either one is a bill as well as a quality decision. The compression notebook matters most for teams watching token spend, a cost lens we dug into separately for query-aware compression on Bedrock.
Retrieval: fixing the question before blaming the index
The second group assumes your index is fine and the query is the problem. The notebooks here are the ones to reach for when you can grep the answer in your documents but the pipeline misses it:
| Technique | The failure it fixes | Cost |
|---|---|---|
| Query Transformations | Question wording never matches document wording | One rewrite call per query |
| HyDE | Short questions sit far from long documents in embedding space | Generate a hypothetical answer, embed that |
| HyPE | HyDE’s guess drifts from real content | Precompute hypothetical prompts at index time |
| Fusion Retrieval | Vector search misses exact identifiers | Merge vector and keyword results |
| Intelligent Reranking | The right chunk is retrieved but ranks last | A reranker pass over top candidates |
HyDE deserves its fame and its caution in equal measure: the hypothetical document never has to be factually right, only stylistically close, and the notebook shows both where that rescues recall and where it fails outright, which is exactly the honesty most blog posts about the method lack. HyPE, documented in a linked preprint, moves the guessing to indexing time and is the collection’s own research contribution.
Correctness: checkpoints between retrieval and answer
The third group is what separates demos from systems. Reliable RAG brackets the pipeline with validation on the way in and groundedness checking on the way out, with source highlighting so a reader can verify the claim. Self RAG lets the model decide when retrieval is needed at all. Corrective RAG evaluates retrieved chunks and falls back to search when they fail. The GraphRAG entries, including the Microsoft variant, restructure the index itself around entities and relationships for corpus-level questions that chunk retrieval cannot answer.
These notebooks pair naturally with the evaluation discipline in Diamant’s production-agents material: a checkpoint without a measurement of whether it fires correctly is just latency. Start with Reliable RAG if hallucinated citations are the pain; start with Corrective RAG if stale documents are.
The notebook contract: why running beats reading
Every entry in the collection follows the same shape, and the shape is the teaching device. A short explanation of the failure mode, the implementation in runnable cells, a run against sample data, and an inspection of what changed in the retrieved context. The RAG techniques that look abstract in a diagram become concrete when you watch a rewritten query surface a chunk the original question missed.
The Colab badges remove every excuse: no environment setup, no dependency conflicts, one click to a running notebook. The linked video explanations cover the intuition for many entries in under ten minutes each, and the newsletter essays go deeper on the methods with research grounding, including a preprint for HyPE. A realistic cadence for a working engineer is two notebooks per evening for a month, which is what it takes to see the whole map of RAG techniques with your own eyes on real output.
What to measure while you experiment
The collection shows you the techniques; proving one works on your corpus is your job, and the measurement changes which group you invest in. Recall problems announce themselves as answers that cite the wrong chunk or none at all. Precision problems look like answers drowned in irrelevant context. Trust problems are answers that cite a chunk correctly and still overclaim. Run Simple RAG as your baseline, record its failures by type, and let the failure types route you through the three groups. Re-measure after each change, one technique at a time, because stacking query transformations plus reranking plus compression in one commit tells you nothing about which one earned its keep. The discipline sounds slow and in practice takes an evening per change, which is cheaper than a quarter of production degradation from a technique nobody validated.
How to work through the collection
The repository’s own entry path is the right one. Clone it, open Simple RAG in Colab, and run it end to end before touching anything advanced, because every later notebook assumes that mental model. From there, diagnose your actual failure and jump to its group of RAG techniques: recall problems live in ingestion and query techniques, trust problems in the correctness family. Each technique’s notebook documents its own prerequisite chain, and the runnable Python scripts mirror the notebooks for pipeline integration without notebook overhead. Budget the most time for the ingestion group, because chunking decisions are the hardest to reverse once real documents are indexed at scale.
For teams writing the source documents rather than only chunking them, the techniques are half the story; the writing side is what our RAG document-writing guide covers, and the two efforts compound.
When does GraphRAG beat plain retrieval, honestly?
GraphRAG restructures the index around extracted entities and the relationships between them, which changes which questions are answerable at all. Plain chunk retrieval answers point questions: what did the policy say about remote work. Graph retrieval answers corpus questions: how do these five vendors relate to each other across two years of contracts, where no single chunk contains the answer. That power has a real price. Building the graph means an extraction pass over the entire corpus, re-indexing is not incremental in the way vector insertion is, and query latency includes graph traversal. The collection’s three entries, community-built graph RAG, knowledge graph integration, and the Microsoft implementation, let you measure that trade on your own data before committing. The pattern that holds: document collections under a few thousand chunks rarely justify the graph, and corpus-wide synthesis questions without it rarely get good answers. One more planning note: graph construction cost scales with corpus size and extraction quality, so budget a validation run on a slice before pointing it at everything, and keep the plain vector index alongside the graph during any migration so you can A/B answers between them.
Are the LangChain and LlamaIndex notebooks interchangeable?
Mostly, with a caveat worth knowing before you pick a track. The collection implements many techniques in both frameworks, and the concepts transfer exactly: proposition chunking is proposition chunking regardless of the import statements. What differs is the surrounding machinery, how each framework handles document loaders, indexes, and retriever composition, and a few techniques exist in only one variant because the other framework ships an equivalent under a different name. The practical advice is to pick the framework your production stack already uses and stay in that lane through the collection, then read the other variant only for the techniques you are evaluating seriously. The runnable Python scripts are the third lane and the most honest one for learning, because nothing is hidden behind an abstraction and every step is visible in one file.
How current are the techniques against 2026 practice?
Refreshed weekly, which matters in a field where last year’s advanced technique becomes this year’s framework default. The collection tracks that drift: contextual chunk headers landed as notebooks before framework vendors shipped native contextual retrieval, and the reranking entries have been updated as reranking moved from specialist library to expected pipeline stage. Reading the update cadence is itself informative, because the techniques that keep getting revised are the ones production users keep reporting edge cases on. Two gaps to know about: the collection is technique-first, so serving concerns like caching and concurrency live elsewhere, and vendor-specific optimizations like Bedrock’s managed retrieval are out of scope by design. Pair it with platform documentation when you deploy for real, and check a technique’s last-commit badge before building on it, because the fast-moving entries occasionally rename notebooks as methods mature.
Do small corpora need any of this?
No, and saying so saves beginners weeks. Under a few hundred chunks, plain vector retrieval with sensible fixed chunking answers most questions, and the added techniques often cost more in latency and complexity than they return in quality. The collection’s own ordering implies this: Simple RAG is entry one among the RAG techniques for a reason. The thresholds where techniques start paying are roughly observable in the notebooks. Query transformations start earning their keep when users ask questions in language that never appears in the documents. Reranking pays when the corpus is large enough that the right chunk is retrieved but not ranked first. The correctness family pays the moment answers reach a customer instead of a terminal. Evaluate at your size, not at the size the technique was invented for, and revisit the decision whenever the corpus doubles, because thresholds that held at ten thousand chunks move by the time you reach a hundred thousand.
How do these RAG techniques map onto managed services?
Mostly one-to-one, with the plumbing removed. Managed retrieval on Bedrock, Vertex, or OpenAI’s platform implements several of these collection entries natively: hybrid or fusion retrieval, metadata filtering, and reranking are configuration rather than code on the major platforms. What the managed versions remove is exactly what the notebooks teach, the mechanism, which is why running the notebook first makes you a better user of the managed feature. The mapping to watch is cost: techniques that add an LLM call per query or per chunk, HyDE, proposition chunking, compression, translate directly into per-request spend on a managed platform, and our Bedrock cost walkthrough shows what that looks like in practice. Techniques that are pure computation, fusion, filtering, hierarchical indices, are usually cheap enough to adopt freely.
What does an evaluation harness for these experiments look like?
Small and boring beats elaborate and abandoned. The minimum viable harness is a golden set of 30 to 50 real questions with known source chunks, a retrieval scorer that checks whether the right chunk appears in the top k results, and a judgment call on answer quality that starts human and can graduate to an LLM judge once you trust your rubric. Score the baseline, score each technique variant, and keep a one-line log of what changed, because three weeks of experiments blur together fast and the log is what turns a pile of notebook runs into a decision record your team can review. The collection gives you the intervention; the harness is what tells you the intervention worked. Two failure modes ruin most harnesses: questions written by the person who built the index, which encode the vocabulary mismatch away, and evaluating retrieval and answer quality as one number, which hides whether the fix helped the right stage.
What is the special advanced technique at the end of the list?
The repository flags one entry as its special advanced technique, kept visually separate from the numbered progression. Treating it as a destination rather than a starting point is the right instinct: it composes several earlier techniques into a single pipeline and assumes fluency with the pieces. The pedagogical value is in seeing the composition, because real systems are exactly these combinations of RAG techniques, chunking choices plus query transformation plus a correctness gate, rather than one technique deployed alone. If you have worked through the three groups in this guide, that final entry is a reasonable capstone exercise: predict what each stage contributes, run it, and check your predictions against the output. Getting a prediction wrong there is the cheapest education the collection offers, because it pinpoints which group you understood least and sends you back to the right notebook with a question in mind.
In what order should a fresh build adopt these techniques?
A defensible default order for a new pipeline: fixed chunking with a size experiment, fusion retrieval, reranking, then one correctness gate, and only then the expensive refinements like proposition chunking or HyDE. The logic is cost of reversal. Chunking is hard to change after indexing a large corpus, so it goes first and gets the most care. Fusion and reranking are query-time changes, reversible in an afternoon. Correctness gates matter the moment answers have an audience, so they slot in before launch. The expensive per-call techniques come last because they need production traffic to justify themselves, and adding them early optimizes failures you have not measured yet. Every stage should be gated on the evaluation harness picking up real failures, and any stage that does not move a metric gets removed, which is how a pipeline stays a system instead of becoming a museum.
Run Simple RAG first, then fix your actual failure: chunking family for recall, query techniques for wording mismatches, correctness entries for trust. The RAG techniques collection earns its stars by making each fix a ten-minute experiment instead of a redesign, and that experiment habit is the real takeaway.