# Day 12: Why retrieval quality starts before search

Everyone wants to tune the retriever. Nobody wants to clean the documents.

The order of operations is unforgiving, though: **retrieval quality cannot exceed ingestion quality**. If broken content enters the index, no embedding model, reranker, or prompt rewrite un-breaks it downstream. You can only rank what you stored, and you stored whatever the pipeline let through.

## Why this stays invisible

Ingestion problems do not fail at ingestion time. The job runs, the count goes up, the dashboard is green.

They surface weeks later, at query time, wearing someone else's uniform, as a retrieval miss, a hallucination complaint, an unauthorised disclosure. The team debugs the retriever, swaps the embedding model, rewrites prompts. The actual defect is that page 4 of a PDF became a column of single characters back in March.

This misattribution is the expensive part. Teams spend weeks on the visible layer because the broken layer produced no error.

## What actually has to happen at the gate

Treat ingestion the way an airport treats arrivals. Inspection, not a turnstile:

- **Extraction that survives real formats.** PDFs with multi-column layouts, tables that mean nothing once flattened, scanned documents that need OCR. Validate the output, not just the exit code.
- **Boilerplate removal.** Navigation menus, cookie banners, and repeated footers embed just as happily as your actual content, and they poison similarity scores across the whole corpus.
- **Metadata at entry.** Owner, effective date, document type, audience, permissions. You cannot filter at query time on a field you never captured, and backfilling it across a live index is miserable.
- **An exclusion policy.** Drafts, duplicates, superseded versions, someone's personal notes from 2019. Deciding what stays *out* is half the job and gets almost none of the attention.

<details>
<summary>The pre-index checklist I actually use</summary>

- Does every document have an owner and an effective date?
- Did tables survive extraction as tables?
- Are permissions captured as queryable fields, not assumed?
- Are there duplicates or superseded versions competing with the current one?
- Is boilerplate stripped, or is it now part of your semantic space?
- Can each chunk be traced back to a source and version for citation?

</details>

## The cheapest diagnostic in RAG

Open your index. Read twenty random entries.

Not the ingestion config, not the strategy doc, the actual stored text. Twenty minutes of scrolling will tell you more than a week of benchmark tuning, and it is the single highest-yield hour available to most RAG teams.

If a human winces at what is in there, the model is already answering from it. It just does not wince.

Ingestion is unglamorous, hard to demo, and impossible to skip. It is also the one stage where a day of work reliably raises the ceiling on every answer the system will ever give.

Before buying a better vector database, spend an afternoon reading what is inside your current one.

*Day 12 of 60 Days of Production AI Systems.*

---

**Previous:** [Day 11: Why RAG is an evidence design problem, not a buzzword](https://blog.vamsiannamreddy.com/day-11-why-rag-is-an-evidence-design-problem-not-a-buzzword)  
**Next:** [Day 13: Why chunk boundaries shape answer quality](https://blog.vamsiannamreddy.com/day-13-why-chunk-boundaries-shape-answer-quality)  

*Day 12 of 60 · From LLM Demo to AI Product (chapter 2 of 10)*