A Practical Guide to RAG Failure Modes: Scan Corruption, Duplicate Chunks, and Index Leakage

The prototype demo works flawlessly. A month after launch, your internal Q&A tool has become a punching bag: "It pulled a quote from an unrelated contract," "The same page came back three times," "Why can it retrieve customer phone numbers?"

When these problems surface, teams instinctively reach for the model layer — swapping embedding models, re-tuning chunk sizes, bolting on a reranker. Sometimes that works. But more often, the real root cause lives before embedding, in the document processing pipeline. This article breaks down three high-frequency failure modes, explains why they are structurally invisible during the demo phase, and quantifies the actual impact of fixes on storage and token costs.

Failure Mode One: Scan Corruption

A large share of enterprise documents are "images wearing a PDF costume" — scanned contracts, photocopied HR files, faxes that were photographed from printouts and digitized. Standard chunkers take them at face value: split pages, compute embeddings on the OCR layer's text output, store in the vector database. A real chunk from a low-quality scan looks roughly like this:

...pursuant to the Agreement, the Vendor shall pay
1?.3?4?5?6?.78 within 30 (3O) days of invoice...
[SEAL overlaps signature block]
[unreadable line — table column lost]

This failure is silent by construction. The embedding of noisy text still lands near the right region of vector space. At retrieval time, the returned chunk has a perfectly normal cosine similarity. The generator then produces a confident answer on top of a corrupted premise — and nothing in the chain throws an exception. Retrieval quality just quietly drifts, undetectable by any error budget.

Three subtypes worth watching:

• Tables rendered as pixels. A price table that exists only as an image becomes prose-like mush after OCR, with row-column relationships completely destroyed.
• Seals and cross-page stamps. In some markets (e.g., government and financial documents standardized on the OFD layout format), official seals are stamped directly over the fields you care about most. General-purpose OCR pipelines are helpless against this.
• Confidence theater. OCR engines report confidence scores, and teams treat high averages as proof the text is fine. But averages are exactly what mask critical fields. Before data enters the index, a human must spot-check sample pages at full size.

The fix is structural recovery before chunking: rebuild the document's logical layout (headings, tables, reading order) so chunks consist of complete sentences rather than smeared text. This is a data engineering step, not a model step — and a large number of "RAG gives weird answers" tickets actually originate here.

The interaction between OCR (Optical Character Recognition) and the embedding layer deserves further explanation. OCR engines analyze scanned images pixel by pixel and output a text stream with coordinates; but modern chunkers typically read only the plain-text layer of OCR output, discarding coordinate information. This means that two adjacent columns of cells in a table may be concatenated into a meaningless string in the OCR plain-text output, and the chunker treats it as a semantically complete paragraph to embed. The embedding model still generates vectors close to normal contract sentences for such syntactically broken text, because it is essentially counting character co-occurrence patterns, not checking grammar. Therefore, the harm of scan corruption is not vector space misalignment, but "semantically correct yet factually wrong" — the retrieval system recalls a false premise with high confidence, and the downstream LLM has no way to tell.

Failure Mode Two: Duplicate Chunks

Vector databases do not deduplicate. Imagine the lifecycle of an important contract: draft, review draft, final, final-final, plus the copy someone emailed to the vendor in March. Five versions describe nearly identical content, and their embeddings cluster tightly together. When a query lands in that region, the top-k window fills up with clones of the same passage. The authoritative paragraph that actually answers the question gets squeezed out by its own "siblings."

This is both a diversity problem and a ranking problem, and it amplifies a statistical fact about enterprise corpora. A survey commissioned by M-Files found that 96% of employees struggle to find the latest version of a document, and 83% have been forced to redo work because they couldn't find the original. In other words: the corpus you are indexing is produced by a process that mass-produces duplicate files. Duplication is not an edge case — it is the native state.

Measures ranked by increasing investment:

1. Exact deduplication via content hashing — low cost, do this first.
2. Near-duplicate clustering based on embedding similarity, keeping one canonical chunk per cluster.
3. Establish a normalization policy: determine the "version of truth" for each document, and downweight — not delete — other versions using metadata.
4. Weight by source metadata at query time so retrieval prioritizes authoritative copies.

None of these require touching the model, but all of them change what the top-k window looks like — and the top-k window is the only thing the answer generator ever sees.

Vector similarity and top-k diversity: Vector retrieval ranks by cosine similarity, but cosine similarity measures directional alignment and is insensitive to subtle semantic differences. When five contract versions are nearly identical, their embedding vectors have very small angles between them, and their similarities to the query vector are nearly equal. As a result, the top-k may consist entirely of k chunks from different versions but with identical content, while the final draft with revision marks — the one you actually need — ranks lower because slight formatting noise got mixed into its embedding. This phenomenon is called "redundant ranking" in information retrieval. It does not cause empty results, but it does cause answers to lack information gain, and can even produce self-contradictory generation due to version conflicts.

Failure Mode Three: Index Leakage

Retrieval itself is an access control bypass. Document-level permissions cannot survive in a chunk-level index: the vector database flattens "only the finance team can open this file" into "anyone whose query matches this embedding gets this text."

Worse, sensitive fields leak without any sophisticated attack. A question about a customer retrieves the chunk containing that customer's phone number, because the text matches. What leaks is not a vulnerability — it is the entire library.

Industry data provides hard numbers on the surrounding risk. IBM's Cost of a Data Breach Report found that one in five companies experienced a breach related to employees' unsanctioned use of AI tools (i.e., "shadow AI"), and those organizations paid an average of $670,000 more per breach than their peers. Among organizations that suffered a breach, 63% had no formal AI governance policy. The same report found that customer PII accounted for 53% of the data stolen in breaches — precisely the category hidden in contracts, invoices, and HR files.

Two design rules follow. First, detect and mask sensitive fields before embedding and indexing, rather than relying on post-hoc filtering that is always one step behind. Second, masking must run inside your own environment — sending raw documents to a third-party masking API just pushes the leak one stage earlier in the pipeline. Rule-based detection for common categories (ID numbers, bank card numbers, phone numbers) plus industry-specific structures is a workable baseline, and the rule set should remain tunable, because every document mix is different.

The failure mechanism of document-level permissions in chunk-level indexes: Traditional file systems bind users to file IDs via ACLs (Access Control Lists), and permission checks occur when a file is opened. The retrieval unit of a vector database is the chunk, and the metadata each chunk carries is typically just the source document ID, page number, and embedding vector — not access control labels. Even if the system performs document-level authentication at the API layer, the retrieval process itself already treats all chunks as equal candidates. Once a chunk is recalled and fed to the generator, its content has bypassed the permission boundary of the original file. More insidiously, the embedding model may encode sensitive information (such as the semantic features of a phone number) into vectors, so that even if the original text is masked, vector similarity may still allow indirect retrieval through other passages containing PII. This is why masking must be completed before embedding.

The Three-Stage Fix

The upstream pipeline can be summarized in one sentence: Clean → Mask → Compress → Index.

• Clean: Exact duplicate hashing, near-duplicate clustering, layout and table recovery for scans, encoding and whitespace normalization.
• Mask: Deterministic detection of sensitive fields, masking completed before embedding, executed entirely locally.
• Compress: Lossless compression of the storage-heavy files, preserving text and layout integrity.

One implementation of this workflow is the "RAG Data Engineering Base" by UglyPear Data — search for that name if you want a reference architecture. But regardless of vendor, this ordering applies, and capable in-house teams can build all three stages from basic components.

The Numbers After Fixing

Start with storage. IDC classifies 80% to 90% of enterprise data as unstructured formats, and a Komprise survey shows that 60% to 70% of data on enterprise NAS has not been accessed in over 90 days, yet occupies the most expensive storage tier. Scan-heavy documents are exactly this heavy tail: a few-hundred-page scanned contract can reach hundreds of MB in raw size.

Lossless compression changes that math directly. Compression engines that strip redundant data without touching text can reduce PDFs, images, Office documents, and scans by 60% to 80%. Run the numbers: a 2TB scan-heavy repository becomes roughly 400GB to 800GB after preprocessing — and that's before accounting for smaller vector stores and fewer embedding batches.

Token cost is the second, less obvious benefit. Multimodal tokenizers charge heavily for image content, and any retrieval pipeline that passes charts and scanned pages to the model inherits that bill on every call. Measured against GPT-4o as a baseline, image-heavy content saw token costs drop by 85.9% after compression — and unlike one-time storage savings, per-token savings compound with every query, every day, for as long as the repository runs.

The calculation basis for lossless compression and token cost: The "85.9% token cost reduction" mentioned in the article is based on GPT-4o's image tokenization mechanism — the model splits images into multiple tiles, each billed at a fixed token count, and a high-resolution scanned page can consume over a thousand tokens. Lossless compression reduces image byte size by stripping JPEG redundancy, resampling, and removing blank margins while keeping text and layout readable, which reduces the number of tiles the multimodal tokenizer processes, directly lowering token consumption per API call. The difference between this and storage savings is: storage savings are a one-time capital expenditure, while token savings are operational expenditure that grows linearly with query volume. For enterprises processing thousands of queries per day, the compounding effect of token costs can exceed total storage savings within months.

Evaluating a Preprocessing Pipeline: Five Dimensions

Whether you build or buy, the criteria should be the following five, not a feature checklist:

1. Fidelity: Is text preserved verbatim, and is layout (tables, seals, reading order) fully conveyed?
2. Masking coverage and locality: Which sensitive categories are covered, and does processing complete within your own network?
3. Throughput: Pages per second at real-world data volumes, including pathological formats.
4. Integration: Can the output feed into your existing vector database without rebuilding?
5. Observability: Can you do full-size before-and-after sample comparisons and diff extracted text?

Pre-Flight Checklist

• Spot-check OCR output at full size with your own eyes — never trust average confidence scores.
• Measure the duplication rate of retrieved chunks on a test query set.
• Grep the index for PII patterns; assume you will find them.
• Calculate per-query storage and token costs before and after compression.
• Keep masking inside your own network.

The spotlight is on the model, but the answers come from the pipeline. Debug upstream.