Document processing — extracting clean, usable text from real-world source documents — is the unglamorous but critical first step of RAG ingestion. Messy extraction produces messy chunks, which produces poor retrieval, no matter how good the rest of the pipeline is.
The Ingestion Sub-Pipeline
Source document (PDF, web page, Markdown, scanned image, etc.)
↓ format-specific extraction
Raw extracted text
↓ cleaning
Clean text
↓ chunking
Chunks ready for embeddingFormat-Specific Extraction Challenges
| Source Format | Key Challenge | Deep Dive |
|---|---|---|
| Layout, tables, multi-column text can confuse naive extraction | PDF for RAG | |
| Scanned documents / images | No embedded text at all — requires OCR | OCR for RAG |
| HTML / web pages | Navigation, ads, and boilerplate need to be stripped from actual content | HTML for RAG |
| Markdown | Generally clean, but structure (headings, code blocks) should be preserved meaningfully | Markdown for RAG |
See Document Parsing for a closer look at extraction techniques generally, and Document Cleaning for what happens after extraction.
Why This Step Deserves Real Attention
A common, underestimated failure mode: garbled or incomplete text extraction from a poorly-parsed PDF silently degrades every downstream step — the chunks are wrong, the embeddings represent wrong content, and retrieval returns wrong or missing results, with nothing in the pipeline obviously signaling that the root cause was extraction quality, not retrieval logic.
Practical Use Case
Before investing effort tuning chunking strategies or retrieval parameters, it's worth manually inspecting extracted text for a sample of real source documents — catching extraction problems early is far cheaper than debugging seemingly-inexplicable retrieval quality issues later.
Common Mistakes
- Never inspecting the actual extracted text, assuming a library "just works" for every document format and layout
- Using the same generic extraction approach for structurally very different document types (a clean Markdown file vs a complex multi-column PDF) without adapting
- Not handling extraction failures explicitly — a document that fails to parse should be flagged, not silently skipped or partially ingested
Interview Relevance
"A RAG system gives poor answers for one specific document but works fine for others. What would you check first?" — inspecting the raw extracted text for that specific document is a strong, practical first diagnostic step, before assuming the issue is retrieval or the LLM itself.
Practice Question
List two things that could go wrong specifically when extracting text from a two-column academic PDF, and how you'd verify extraction quality.
