RAG (Retrieval Augmented Generation) Cheat Sheet

Table 1: RAG Building Blocks (Conceptual)

Every RAG pipeline is assembled from the same handful of stages, run in order from ingesting raw data all the way to evaluating the final answer. Knowing this skeleton makes the rest of the cheat sheet easier to navigate — each later table simply zooms into one of these stages and lists the concrete tools you can plug in there.

Table 2: Chunking and Splitting

How you slice documents into chunks quietly decides how good your retrieval can ever be — too big and you bury the answer in noise, too small and you lose the surrounding context. These splitters range from the dependable recursive-character default to semantic and structure-aware options, plus the parent/child and contextual tricks that fix the boundary problems naive splitting creates.

Table 3: Embedding Models

The embedding model is what turns text into the vectors your search runs on, so its quality sets the ceiling on retrieval accuracy. The choice usually comes down to a few trade-offs — proprietary APIs like OpenAI and Cohere versus self-hostable open models like BGE-M3, dimension count and cost, and how well each handles non-English or domain-specific corpora.

Table 4: Dense Indexing and ANN

Once you have millions of vectors, scanning all of them per query is too slow — approximate nearest-neighbor (ANN) indexes trade a sliver of recall for orders-of-magnitude faster search. Here you'll find the graph- and partition-based structures (HNSW, IVFFlat) that power production vector DBs, the exact FAISS baselines, the quantization tricks that shrink memory, and the distance metrics that define "similar."

Table 5: Vector Databases

A vector database is where your embeddings actually live and get queried in production, bundling the ANN index with storage, metadata filtering, and operations. The real decision is which one fits your situation — pgvector if you already run Postgres, managed Pinecone for zero-ops scale, Qdrant or Weaviate for open-source flexibility, Chroma for quick prototyping.

Table 6: Sparse and Hybrid Retrieval

Dense vectors are great at meaning but weak at exact terms — error codes, product names, and rare keywords often slip through. Sparse methods like BM25 catch exactly those, and hybrid retrieval fuses both signals so you don't have to choose; the rest of the rows cover the filtering, fusion, and diversity controls that shape the final candidate set.

Table 7: Query Transformation

Users rarely phrase questions the way your documents are written, and a single raw query often misses relevant chunks. These techniques reshape the query before it ever hits the index — rewriting it, expanding it into several variants, generating a hypothetical answer to search with, or breaking a complex question into sub-questions — to close that gap between how people ask and how content is stored.

Table 8: Reranking and Fusion

First-pass retrieval is tuned for speed and recall, so it usually pulls back more than you need with the best chunk not always on top. A reranker does a second, more expensive pass that scores each query-document pair jointly and reshuffles for precision — Anthropic measured reranking cutting retrieval failures by 67% when combined with contextual retrieval. The fusion and compression rows round out the toolkit for merging multiple ranked lists and trimming context noise.

Table 9: Query Engines and Answer Grounding

This is the generation half of RAG — the components that take retrieved context and turn it into a written answer. Grounding is the key idea: instructing the model to answer only from the provided evidence is the core defense against hallucination, and the citation engines tie each claim back to its source so readers can verify it.

Table 10: Advanced RAG Architectures

Beyond the basic retrieve-then-generate loop sit the patterns that define modern production RAG. Most share one move — letting the system decide how to retrieve rather than hard-coding a single pass: agentic RAG treats retrieval as a tool the LLM calls, corrective and self-RAG grade their own evidence, multi-hop chains several retrievals, and GraphRAG retrieves over a knowledge graph instead of flat chunks.

Table 11: Storage, Persistence, and Caching

The plumbing that keeps a RAG system durable and affordable lives here — where vectors, full documents, and index structures get persisted so you don't rebuild them on every restart. The caching and incremental-indexing rows matter most at scale: re-embedding only changed documents and caching repeat embeddings are where real cost savings come from.

Table 12: RAG Evaluation Metrics and Frameworks

You can't improve what you can't measure, and RAG quality splits cleanly into two questions — did retrieval surface the right context, and did generation stay faithful to it. These metrics (faithfulness, context precision/recall, answer relevancy) pin down each side, and the frameworks below let you run them in CI against a golden dataset so a pipeline change can be graded before it ships.

Table 13: Observability and Security

Once RAG is live you need to see inside it and defend it. The observability rows cover the OpenTelemetry GenAI spans and tracing tools that expose retrieval counts, token usage, and latency for debugging. The security rows map the OWASP LLM risks that hit RAG specifically — prompt injection riding in through retrieved context, data poisoning of the corpus, and sensitive-info leakage.

Table 14: Multimodal RAG

A huge share of real knowledge lives in PDFs full of tables, charts, and scanned layouts that text extraction mangles. Multimodal RAG sidesteps that by treating document pages as images — ColPali-style retrievers embed page images directly and a vision-language model reads them, increasingly replacing the old OCR-then-embed pipeline for complex documents.