Preparing Your Data for RAG

RAG data preparation is everything you do to a document corpus — select sources, parse, clean, deduplicate, filter, enrich metadata, and validate samples — before a chunker runs. Most retrieval failures start here: every later stage faithfully encodes that garbage. This page is the ordered checklist and the readiness gate. Format parsers live on document ingestion; splitters live on chunking; the full stage map lives on RAG architecture.

What is data preparation for RAG?

Data preparation for RAG is the index-time work that turns source documents into a clean, filterable corpus ready for chunking — corpus selection, parsing into structured text, cleaning noise, deduplicating, filtering junk or sensitive documents, attaching metadata, and validating samples — before any splitter or embedding model runs.

Databricks’ Ellen Hirt and Pascal Vogel (November 2024) define data preparation as ingesting, cleaning, and structuring diverse data types into a knowledge base ready for retrieval. TechTarget’s Marius Sandbu (August 2025) lists corpus selection, preprocessing and parsing, enrichment, and filtering as the steps that precede chunking and embedding. Unstructured’s Maria Khalusova (May 2025) treats that preprocessing layer as the bedrock: if it fails, chunking, enrichment, embedding, and retrieval are compromised. The border on this site: ingestion owns how to parse a given format; this page owns the ordered checklist and when to stop; chunking starts only after the readiness gate below.

Why do most RAG failures start in data preparation?

Most RAG failures start in data preparation because retrieval and generation can only search and quote what the index contains — mangled parses, boilerplate indexed as content, near-duplicate copies, and missing metadata set a quality ceiling that hybrid search and reranking cannot raise.

sph.sh’s RAG data-preparation guide (live 2026-07-27) opens with that diagnosis: teams spend weeks tuning retrieval while the real problem is poorly parsed documents or unclean text. SearchCans’ ingestion guide calls the same pattern garbage-in, garbage-out. Unstructured is blunt that failed ingestion compromises everything downstream. The practitioner signatures look like this:

• Answers cite navigation or footer text — boilerplate was never stripped and became “content” in the index.
• The same fact returns three near-identical chunks — duplicates from shared drives or draft copies were never removed.
• Table and number questions answer wrong — layout was flattened before the chunker; see why RAG gets numbers and tables wrong.
• Scanned PDFs retrieve empty or garbage — there was no text layer and OCR never ran, or it ran badly.
• You cannot filter by date, source, or ACL — metadata was never attached at prep time.

Published blogs sometimes quote large percentage lifts from “fixing data prep alone.” Those figures are not published with a named primary study on the ranking pages reviewed for this teardown — so this site does not invent one. The structural claim is enough: if the indexed text is wrong, no retriever can invent the missing passage. Symptom taxonomy after the fact lives on RAG failures.

How do you prepare data for a RAG pipeline?

You prepare data for a RAG pipeline in a fixed order — select the corpus, parse to structured text, clean, deduplicate, filter, enrich metadata, validate samples — and only then hand off to the chunker.

TechTarget’s six-step pipeline (Sandbu, August 2025) puts corpus selection, preprocessing and parsing, enrichment, and filtering before chunking and embedding. Databricks’ unstructured-data cookbook (docs.databricks.com, live 2026-07-27) sequences corpus composition → parsing → enrichment → deduplication → filtering → then chunking. sph.sh’s Pitfall 5 is explicit: chunking before cleaning, or embedding before deduplication, creates noisy results. The order this page owns:

1. Corpus selection. Choose sources that can answer the queries you will get. Databricks’ cookbook is blunt: without the right corpus, retrieval cannot find the required information — engage domain experts early.
2. Parse. Extract text, tables, and reading order from each format. Depth on PDF layout, OCR, and table extraction lives on ingestion and its children — this step only asserts that structure must survive extraction.
3. Clean. Strip navigation, ads, repeated headers and footers, and normalize whitespace and unicode so embeddings do not encode noise as signal. Strip-versus-keep rules live on cleaning documents before you chunk them.
4. Deduplicate. Remove exact and near-duplicate documents (shared-drive copies, drafts, mirrored docs). Databricks’ cookbook describes metadata keys for exact matches and MinHash-style near-duplicate detection for subtle copies.
5. Filter. Drop documents that are irrelevant to the use case, too old or unreliable, toxic, or sensitive before they become chunks (Databricks cookbook Filtering; TechTarget step 4). Filtering at prep time is cheaper than explaining a bad answer later.
6. Enrich metadata. Attach source, title, page, date, document type, and ACL tags so retrieval can filter and cite. Field design depth lives on metadata extraction.
7. Validate samples. Inspect parse-and-clean output on a representative sample before full ingest — sph.sh’s building guide starts with validating parsing on sample documents before writing pipeline code.

Only after those seven steps does the corpus move to chunking. Embeddings and indexes come after chunks exist — they are not prep-before-chunker work.

When is a corpus ready for the chunker?

A corpus is ready for the chunker only when sample parses preserve reading order and tables, boilerplate is stripped on the sample set, near-duplicates are resolved, junk and sensitive documents are filtered, required metadata fields exist on every kept document, and a human has spot-checked that the text a chunker would see is the text you intend to retrieve.

Not-ready signals — fix these before you pick a chunk size:

• Multi-column PDFs read left-to-right across columns — the parser destroyed reading order; fix under PDF parsing.
• Scanned pages with empty or garbage text — OCR policy belongs on OCR and scanned documents.
• The same header or nav line appears in every sample — cleaning never ran.
• Near-identical SharePoint or drive copies still in the set — dedupe never ran.
• No source, date, or permission fields on records — enrichment never ran; you will not be able to filter or cite later.

What failure does bad data preparation cause?

Bad data preparation surfaces as retrieval that looks confident while the indexed text is wrong — wrong chunk content, missing documents, flattened tables, stale or duplicated passages — because the chunker and embedder faithfully encoded upstream garbage.

SearchCans lists poor data quality, neglected metadata, and over-reliance on a single dirty source among the ingestion pitfalls that degrade answers without crashing the app. sph.sh’s Pitfall 1 is skipping parsing validation; Pitfall 2 is one-size-fits-all chunking on content that was never cleaned or typed. This page owns the cause layer. Differential diagnosis by symptom lives on RAG failures — especially wrong chunk, missing document, and tables. Fixing prep changes what retrieval can find; it does not replace measuring retrieval on labelled queries.

How do you implement RAG data preparation?

Implement RAG data preparation as a wired sequence — connectors → parser → cleaner → dedupe and filter → metadata → validate → then a chunker — not as a single “load PDF” call.

Named building blocks from the live ranking pages (as of July 2026 — pin library versions before you ship code): TechTarget cites MarkItDown for converting office formats to Markdown before chunking; Couchbase and sph.sh use BeautifulSoup (and readability-style main-content extraction) for HTML; PDF families named across Databricks community, sph.sh, and Unstructured include Unstructured, Docling, and PyMuPDF/PyPDF — the bake-off belongs on PDF parsing, not here. Databricks’ cookbook describes MinHash-style near-duplicate detection for subtle copies. After chunks exist, vectors land in a store such as Weaviate, Pinecone, Qdrant, or Milvus — store choice is not a prep-before-chunker decision.

For a pinned, runnable end-to-end pipeline with choices stated at each stage, see how to build a RAG pipeline from scratch. For the stage map that places this work on the indexing path, see RAG architecture. For format-specific ingest depth, return to document ingestion.