How to Build a Reliable RAG Document Ingestion Pipeline

The practical pipeline has seven stages: register the source, detect its format and risk, extract into a structured intermediate model, normalize without erasing meaning, validate the result, create traceable retrieval units, and publish a versioned index. Keep the raw file and every transformation manifest so a reviewer can move from an answer to a chunk, page region, extracted element, and original source.

Do not send every PDF through one parser and accept whatever Markdown appears. A born-digital report, scanned form, slide deck, spreadsheet, and email thread fail differently. Route them by observable properties. Use native text extraction where it preserves characters and geometry; add OCR for image regions; use layout and table models where spatial relationships carry meaning. Quarantine low-confidence outputs instead of filling gaps with plausible text.

The design goal is not beautiful Markdown. It is evidence that remains findable and interpretable after conversion. A clean paragraph with the wrong heading, a table flattened in the wrong column order, or a footnote attached to the wrong clause can all retrieve convincingly and support the wrong answer.

Begin with an immutable source record. Assign a document ID, retain the original bytes, calculate a content hash, and record the canonical location, media type, size, language, owner, access scope, received time, and any effective or publication date supplied by the source system. Keep ingestion time separate from the document's own dates. They answer different questions.

Profile the file before choosing an extractor. Check whether text is embedded, pages are scanned, fonts map to valid characters, columns or rotated pages are present, tables cross pages, and attachments or tracked changes exist. Password protection, corruption, unsupported formats, and unexpectedly empty pages should produce explicit states, not silent success.

This routing step prevents expensive models from becoming the default for simple documents and weak text extractors from handling visual ones. It also makes the pipeline reproducible: given the same file and configuration, a team can explain which path ran and why. Store parser name, model version, configuration, code version, start and finish times, and warnings with each run.

Treat access control as source data. Permissions must travel into every derived element and retrieval unit, but the originating system should remain authoritative. Ingestion should not broaden access because a converted copy landed in a different store.

Plain text is a lossy interchange format for visually rich documents. Use an intermediate representation that keeps elements such as title, heading, paragraph, list item, table, figure, caption, footnote, formula, header, and footer. Each element needs page coordinates, reading-order position, parent section, and the text or structured payload produced by extraction.

The READoc benchmark frames realistic document structured extraction as converting whole PDFs into semantically rich Markdown rather than scoring isolated OCR or layout subtasks. Its 3,576 documents come from arXiv, GitHub, and Zenodo. That is a useful test of diverse technical documents, not a guarantee for policies, handwritten forms, or a company's internal scans.

Several open systems illustrate why extraction is a pipeline rather than a single OCR call. The Docling technical report combines layout analysis and table structure recognition for PDF conversion. The MinerU paper describes layout-aware OCR, formula handling, an intermediate JSON structure, and post-processing. These are implementation examples. Evaluate them against your corpus instead of choosing by a general benchmark or a polished demo.

Preserve both machine structure and source geometry. A heading tree supports coherent retrieval and parent expansion. Bounding boxes let a reviewer highlight the cited region on the original page. Do not discard coordinates after rendering Markdown; Markdown is a view of the extracted document, not the complete evidence record.

Tables are not paragraphs with extra spaces. Preserve their caption, header hierarchy, row and column spans, units, footnotes, page range, and surrounding section. Generate a readable representation for retrieval, but retain the cell grid or HTML-like structure for calculation and display. When a table continues on the next page, repeat headers only in the presentation layer and link the physical fragments to one logical table.

The 2026 revision of PubTables-v2 explicitly benchmarks table extraction with cropped, full-page, and multi-page context. Its results show that model rankings can change with the task boundary: larger frontier models led on full-document multi-page extraction, while narrower targeted systems closed or reversed the gap on cropped tables. The lesson is operational. Evaluate the context your pipeline actually provides, not the word “table” in a capability list.

Figures need a similar treatment. Store the image region, caption, figure number, nearby references, and any extracted labels. An automatically generated description is derived metadata, not a substitute for the image. Mark its model and confidence, and let the answer cite the original figure. Forms require key-value and grouping relationships; a list of tokens loses which checkbox, label, or signature belongs together.

A document-centric multimodal system may retrieve text, table, or image evidence through different paths. Keep those elements connected by document, section, page, and explicit references so the final context can reconstruct the source neighbourhood without treating each modality as an unrelated index.

Normalization should remove mechanical noise while leaving meaning inspectable. Dehyphenate line breaks only when the joined word is credible. Remove repeated headers and footers only after verifying the pattern. Preserve numbered clauses, list nesting, emphasis that changes interpretation, page boundaries, and original text beside corrected OCR. Never let cleanup silently rewrite a date, identifier, decimal, or negation.

Give every element a stable locator. Page and bounding box work well for fixed-layout files; character or text-quote selectors can help when content is available as text. The W3C Web Annotation Data Model offers a useful body-target pattern and selectors for addressing segments of resources. A production system can borrow that idea in ordinary JSON without adopting a full linked-data stack.

Locators must survive downstream chunking. A chunk assembled from three paragraphs should carry the three element IDs and their page regions, not one invented offset. A generated table summary should link to the table element and be labeled as a transformation. This is what makes citations, correction, deletion, and re-indexing precise.

Create retrieval units from the validated structure: sections, clauses, table rows with headers, figure-caption pairs, or parent-child combinations. Do not flatten first and then try to infer structure from token windows. The ingestion model should hand the chunker a document tree with explicit boundaries.

Validation needs document-level and element-level checks. Compare extracted page count with the source. Flag pages with implausibly little text, replacement characters, duplicate blocks, broken reading order, orphan captions, tables without headers, missing list items, and sudden language changes. Validate that every derived element has a parent document, locator, permissions, and transformation record.

Sample difficult pages for human review: the densest table, a two-column page, a scan, a page with footnotes, and any page with low extraction confidence. For high-stakes corpora, require review for specific fields such as monetary values, effective dates, exclusions, or dosage. Confidence scores are routing signals, not proof that text is correct.

A 2026 study, From PDF to RAG-Ready, compared conversion and preprocessing choices on 36 Portuguese administrative documents and 50 questions. It found meaningful downstream differences, especially on table-dependent questions, but the corpus was small, domain-specific, and assessed partly with an LLM judge. Use it as evidence that preprocessing deserves end-to-end evaluation, not as a universal parser leaderboard.

Publish new versions atomically. Build and validate the replacement index before changing the active pointer. If a source changes, use hashes and element identities to reprocess the affected document, retire superseded retrieval units, and invalidate caches. Keep old versions when audit or comparison requires them; otherwise enforce deletion through raw files, derived artifacts, indexes, logs, and backups according to policy.

Create a small gold set before selecting a parser. Include each document family and the failures people care about: a clause split across pages, a table with merged headers, a chart whose caption changes its meaning, a scan with handwriting, an older version beside the current one, and a question whose answer is absent. Mark the exact source regions needed for each answer.

Score extraction separately from retrieval. For extraction, inspect character accuracy on critical fields, reading order, element classification, hierarchy, table structure, and locator validity. For retrieval, ask whether the correct evidence appears within the context budget and whether its citation resolves. Then test answer faithfulness and completeness. This separation tells you whether to repair the parser, chunker, retriever, or generator.

Run controlled comparisons on the same files and questions. Change one dimension at a time: parser, OCR route, table representation, normalization rule, or visual description. Track failures by document type rather than averaging everything into one score. A pipeline that excels on technical papers may still be unsafe for scanned endorsements or spreadsheet-like schedules.

The simplest reliable pipeline may use native parsers for clean office files, OCR and layout models for scans, and manual review for a narrow high-risk class. That is often better than forcing one expensive model across every page. Reliability comes from visible routing, reversible transformations, and evaluation tied to real evidence—not from claiming that ingestion is solved.

If a real knowledge workflow keeps retrieving a plausible answer from a broken table, misplaced clause, or stale document, share the source type and failure path at sahil@granveo.com. That example is more useful than a generic parser benchmark.