RAG 與知識系統

RAG data preprocessing in practice: complete workflow and checklist for PDFs, tables, and scanned files

Most RAG failures come from data corruption during conversion, not model problems. Specification sheets split across PDF pages. Merged table cells losing field references. OCR errors in tolerance specifications. These problems break more systems than algorithm issues do. This article covers the preprocessing pipeline and a pre-launch checklist.

By

Tenten AI 研究團隊

AI 基礎設施

Published

December 30, 2025

Read time

7 分鐘

RAG資料前處理知識庫工程OCR檢索品質企業 AI 導入

A manufacturing client contacted us after integrating RAG on their own. The answers were often wrong. We tested thirty questions and found errors in nineteen. Of those nineteen, sixteen had nothing to do with the model or the retrieval algorithm. The problem was in the data itself. Text that got chunked was already corrupted. A specification sheet that PDF split into top and bottom halves. An OCR pass that turned '0.05mm' into '0.O5rnrn' in a tolerance note. A price list with three levels of merged cells, compressed into noise with no field mapping.

The model faithfully reads back the corrupted text it receives.

RAG data preprocessing: what are we actually processing?

RAG data preprocessing means converting raw files into clean text that is semantically complete, structurally correct, and independently understandable by retrieval units, before chunking and vectorization. The question is not whether content is correct, but whether it survived conversion unchanged. When this layer breaks, adjusting embedding models or adding reranking won't help. You're still working from corrupted text.

Most enterprise problems fall into three areas: PDFs with complex layouts, tables with merged cells, and scanned OCR files. Here's how to handle each.

PDF: first distinguish digital from scanned

Start by detecting the document type. Extract text from one page using pdfplumber or PyMuPDF. If text appears, it's digital (text-based). If extraction returns empty, it's scanned (image-based) and needs OCR. These two paths diverge completely, and mixing them is the single most common mistake.

For digital PDFs, the core challenge is reading order. Two-column layouts, headers, footers, side notes. Calling extract_text() directly often produces the wrong sequence. The first line of the left column gets followed by the first line of the right column, breaking semantic coherence. The solution is to use layout detection to segment text blocks first, reorder by coordinates, then filter repetitive noise (headers, footers, page numbers, watermarks) with rule-based filtering. Table regions need separate handling; extracting them as regular text causes numbers to run together.

Tables: merged cells are semantic killers

Tables break silently in RAG systems. Text gets extracted, just incorrectly. Merged cells cause the worst problems. A human sees "East Region / Tier-1 City / Unit Price 120" but plain text extraction produces "East Region [space] [space] Tier-1 City 120." The downstream system never knows what 120 refers to.

Three principles handle this. First, restore merged cells through forward fill. Put the merged value back into each cell to recreate a proper two-dimensional table. Second, don't convert tables to unstructured text. Use Markdown tables or key-value pairs with explicit field names, so each row stands alone. Third, when chunking large tables, include the headers with each chunk. A 200-row table split into ten chunks should carry field titles in every chunk. Otherwise chunk seven's numbers have no column context and become useless to retrieval.

Scanned OCR: garbage in, garbage out

Scanned files require the most work. OCR output always has errors; the goal is controlling error rates, not eliminating errors entirely. Image preprocessing upstream (deskew, binarize, denoise, increase resolution to 300 DPI or above) often works better than paying for a more expensive OCR engine. These steps significantly improve recognition.

For Chinese documents, specify the correct language pack. Traditional, Simplified, and Japanese text requires separate configuration when mixed; otherwise tolerance specs and part numbers combining Traditional characters with alphanumerics render poorly.

After OCR, implement confidence score filtering and post-processing. Mark low-confidence fields for manual review. Use domain dictionaries (part number formats, units, terminology) for rule-based correction. This step can't be skipped. We encountered this with a healthcare client's scanned medical records where OCR changed the dosage unit 'mg' to 'mq'. The model confidently used it in answers. No one noticed. It was only caught during pre-launch spot-checking.

Data TypeCore RiskPrimary ToolsKey ProcessingValidation Metric
Digital PDFReading order corruption, noisepdfplumber, PyMuPDF, layout analysisBlock reordering, header/footer removal, table isolationExtracted text matches original order
Complex TablesMerged cells lose correspondenceTable parsing, pandasForward fill, convert to Markdown/key-values, headers with chunksEach row independently understandable by column
Scanned OCRCharacter recognition silently propagatesImage preprocessing, OCR engine, dictionary correctionDeskew, binarize, language pack spec, confidence filteringSampled character error rate below threshold

A reusable preprocessing pipeline

Build a standard workflow where every document follows the same steps.

  1. Type detection: Digital files go to text extraction, scanned files to OCR, no mixing.
  2. Extraction: Reorder layouts in digital files, preprocess images and run recognition on scanned files.
  3. Table separation: Handle table regions separately, restore merged cells, convert to structured format.
  4. Cleaning: Remove headers, footers, excess whitespace, garbled text, control characters; standardize units and character widths.
  5. Quality gate: Check OCR confidence scores, table field completeness, blank ratios; any failure goes to manual review.
  6. Structured chunking: Split by semantic boundaries, tables include headers, long sections preserve title hierarchy.

Pre-launch cleanup checklist

  • Every document format has been spot-checked against originals by hand; order and numbers are correct.
  • Scanned OCR error rates have been measured; low-confidence fields are marked for manual review.
  • All table merged cells have been restored; after chunking, each row still has field context.
  • Headers, footers, page numbers, watermarks, and other repetitive noise have been filtered.
  • Units, part numbers, and terminology have been corrected using domain dictionaries; character widths are standardized.
  • A fixed regression test suite exists; run it with every data update to catch degradation early.

This checklist gets used on every RAG project, before model selection happens. Field experience shows the pattern: most RAG projects fail because of data problems, not models. The barrier is that cleaning takes time, and most teams skip it. Unglamorous work. Invisible in demos. But it determines whether the system gets trusted after launch. In more than half the rescue projects we take on, the bulk of repair effort ends up at this layer.

One stuck workflow
is enough to begin

Tell us what the team does today, where it breaks down, and what a better working day should look like.