PDF to Markdown for RAG: Preserve Tables and Structure

Learn how to convert PDFs into AI-ready Markdown that preserves heading hierarchy, table semantics, reading order, and provenance anchors—so your RAG pipeline retrieves the right rows and returns answers with trustworthy citations. Includes a mini-benchmark, evaluation rubric, and CLI-style output example.

Last updated: 2026-07-23. Versions tested: layout-aware PDF extraction (text-based pages), OCR fallback with layout reconstruction (image-only pages), Markdown table normalization, heading-based chunking, and provenance anchors (page + offset).

Executive Summary

If your RAG pipeline treats PDFs as “just text,” you’ll eventually pay for it: tables collapse into unreadable lines, headings lose hierarchy, and chunk boundaries drift away from the user’s intent. The fix is not “more cleaning.” The fix is structure preservation—turning visual layout into stable Markdown primitives (headings, lists, tables, captions, and provenance markers) so chunking and retrieval stay aligned.

In this guide, we’ll walk through a practical, production-minded approach to converting PDFs into AI-ready Markdown that keeps tables readable, preserves document hierarchy, and supports grounded citations. You’ll also get an evaluation harness you can run on a small PDF set to quantify whether your converter is actually preserving structure.

Key Takeaways

• Preserve heading hierarchy and table geometry (rows/columns, headers, merged cells) before you chunk.
• Treat layout as data: captions, footnotes, and “table context” often matter as much as the table itself.
• Use an OCR fallback path for image-based pages, but keep the output consistent with your text-based path.
• Add provenance anchors (page number and stable offsets) so citations map back to the source.
• Validate with a small benchmark: measure table fidelity, heading fidelity, and retrieval impact.

1. Problem Statement

You have PDFs full of knowledge—policies, reports, invoices, research papers, product specs. Your RAG system needs to retrieve the right passage and answer with citations. But when you convert PDFs to Markdown, you often get one of these failure modes:

• Tables become paragraphs or “ASCII soup,” so the model can’t reason over row/column relationships.
• Headings flatten (e.g., everything becomes # or everything becomes plain text), so chunking loses section lineage.
• Layout cues (captions, footnotes, “see table above,” multi-column reading order) disappear, so the retrieved chunk lacks context.
• Citations point to the wrong place because the converter doesn’t preserve stable anchors.

The result is predictable: lower recall, higher hallucination risk, and citations that don’t match what the user expects.

2. What “Preserving Structure” Means for RAG

For RAG, “structure” is not about aesthetics. It’s about retrieval invariants—properties that should remain true from source PDF to Markdown to chunks to embeddings.

A structure-preserving conversion should maintain at least these invariants:

• Hierarchy invariant: If the PDF has a section/subsection structure, the Markdown should reflect it with consistent heading levels.
• Table invariant: If a table has headers and rows, the Markdown should represent them as a real Markdown table with correct header semantics.
• Context invariant: Captions, footnotes, and nearby explanatory text should remain adjacent to the table in the Markdown output.
• Order invariant: Reading order should match the human reading order (especially for multi-column pages).
• Provenance invariant: Each chunk should be traceable back to a page (and ideally a stable offset) in the original PDF.

If any invariant breaks, your chunker and retriever start working with distorted signals.

3. Why Tables Break Retrieval

Tables are where “layout-first” formats hurt you most. In a PDF, a table is often not a table object—it’s a set of positioned glyphs and lines. A converter has to infer:

• Which cells belong to which row.
• Which cells are headers vs data.
• Whether cells are merged (rowspan/colspan).
• Whether a “header” repeats on each page.
• Whether the table continues across pages.

If the converter guesses wrong, the Markdown table might still render, but the semantics are wrong. For RAG, that’s worse than missing data: the model confidently answers using a table that looks correct.

4. Target Output: AI-Ready Markdown Schema

You don’t need a custom Markdown dialect, but you do need consistency. A practical target schema looks like this:

• Headings: #, ##, ### mapped from PDF hierarchy.
• Lists: - and 1. for bullet/numbered lists.
• Tables: Markdown tables with header rows and consistent column counts.
• Captions: a dedicated line format (e.g., Table 3: ...) immediately before the table.
• Footnotes: a dedicated section after the table (or inline markers if your pipeline supports it).
• Provenance markers: page number and stable offsets attached to blocks.

Example (simplified):

## Financial Highlights

*Table 2: Revenue by Region (Q4 2025)*

[page=12 offset=18432]

| Region | Q3 Revenue | Q4 Revenue | YoY |
|--------|------------:|------------:|----:|
| North America | 12,000,000 | 15,000,000 | 25% |
| Europe | 8,000,000 | 9,000,000 | 12.5% |

*Footnote a: Includes one-time adjustments.*

[page=12 offset=18610]

The key is that your chunker can split on headings, your table parser can read the table, and your citation layer can map back to the PDF.

5. Architecture: Layout-Aware PDF → Markdown Pipeline

A production pipeline usually has two conversion paths:

• Text-based extraction for PDFs with selectable text.
• OCR fallback for image-based pages.

Then you normalize both paths into the same Markdown schema.

A practical architecture:

flowchart TD
  A[PDF bytes] --> B{Page type detection}
  B -->|Selectable text| C[Layout-aware text extraction]
  B -->|Image-only| D[OCR + layout reconstruction]
  C --> E[Normalize to AI-ready Markdown]
  D --> E
  E --> F[Attach provenance anchors]
  F --> G[Chunk by headings + table blocks]
  G --> H[Embed + index]
  H --> I[Retrieve + cite]

If you don’t normalize, you’ll get structure drift: the same document type yields different Markdown patterns depending on whether the page was OCR’d.

6. Table Preservation

Here’s what you should aim for when preserving tables.

1) Correct header semantics

Markdown tables only become “reasonable” if the model can tell which row is the header. That means:

• The first row of the table should be the header row when the PDF uses a header.
• If the PDF has multi-level headers, you need a strategy: either flatten into multiple header rows or merge into a single header row with composite labels.

2) Stable column counts

A common failure mode is inconsistent column counts across pages or across chunks. If your converter sometimes outputs 4 columns and sometimes 5 for the “same” table, your downstream chunking and retrieval degrade.

A practical rule: if the table spans pages, keep the same column schema across the entire table.

3) Merged cells

PDF tables often use merged cells. Markdown doesn’t support rowspan/colspan directly. You need a deterministic representation strategy, such as:

• Expand merged cells by repeating the value in each implied cell.
• Or convert merged cells into a “header context” line above the table.

Pick one and keep it consistent.

4) Table context (captions and surrounding text)

Users rarely care about a table in isolation. They care about what the table means. Captions and nearby explanatory paragraphs often contain the “why.”

So your converter should keep:

• Caption immediately before the table.
• Footnotes immediately after.
• Any “table continues” note near the continuation.

5) Detect “table-like” blocks

Some PDFs don’t label tables as tables. They use grid lines, aligned text, and whitespace. A robust converter should detect these blocks and output them as tables when confidence is high.

When confidence is low, it’s better to output a structured fallback (e.g., a key-value list) than to output a broken Markdown table.

7. Layout Preservation Beyond Tables

Tables are the headline problem, but layout preservation includes several other details.

Multi-column reading order

Many PDFs are two-column. If your converter reads left-to-right then top-to-bottom incorrectly, you’ll interleave unrelated sections. That breaks chunking and makes retrieval return “almost right” passages.

A structure-preserving converter should:

• Detect column boundaries.
• Reconstruct reading order per column.
• Merge columns in the correct sequence.

Captions, figures, and diagrams

If a figure contains critical information, you have options:

• Extract alt text if available.
• OCR the figure region.
• Or output a placeholder with a provenance marker so your pipeline can decide whether to run vision.

The important part is consistency: don’t silently drop figures that look like they contain knowledge.

Footnotes and references

Footnotes often contain definitions, caveats, and constraints. If you drop them, your answers become incomplete.

A good approach:

• Keep footnotes near the table or section they modify.
• Preserve markers like a, b, c so the model can connect them.

8. OCR Fallback Without Structure Drift

OCR is necessary, but it can introduce drift:

• Headings might become plain text.
• Table lines might be recognized as separate words.
• Reading order might change.

To avoid drift:

• Run OCR with layout reconstruction (not just raw text OCR).
• Normalize OCR output into the same Markdown schema as text-based extraction.
• Validate structure after conversion (see evaluation harness below).

9. Chunking Strategy That Respects Structure

Once you have AI-ready Markdown, chunking should respect the structure you preserved.

A reliable chunking approach:

• Split on headings first (so each chunk has a section lineage).
• Treat tables as atomic blocks (don’t split a table across chunks unless it’s extremely large).
• Attach table captions and footnotes to the same chunk as the table.
• Include provenance markers in chunk metadata.

If you chunk by token count only, you’ll cut tables in half and lose row/column context.

10. Configuration / Setup

This section is intentionally practical: it shows what you should configure in your pipeline, regardless of which converter you use.

1) Conversion settings

You typically want:

• Page range controls (for large PDFs).
• OCR fallback enabled.
• Output mode that returns Markdown with page markers.
• Optional: return bounding boxes or confidence scores for OCR.

2) Normalization settings

You want deterministic mapping rules:

• Heading level mapping rules (font size/weight → #/##/###).
• Table detection thresholds.
• Merged-cell strategy.

3) Chunking settings

Configure:

• Heading-based splitter.
• Table block detection.
• Max chunk size with table atomicity.

4) Citation settings

Configure:

• Page number inclusion.
• Stable offsets if your converter provides them.
• Chunk metadata schema.

11. Examples

Example 1: A tables-heavy report

Input: a quarterly report PDF with multiple tables and footnotes.

Expected Markdown behavior:

• Each table has a caption line.
• Each table is a valid Markdown table with consistent columns.
• Footnotes appear immediately after the table.
• Headings preserve the hierarchy so chunking can split by section.

Example 2: A scanned PDF with image-only pages

Input: a scanned contract where headings are bold but not selectable.

Expected Markdown behavior:

• OCR output includes headings as headings.
• Tables are reconstructed into Markdown tables when possible.
• If a table cannot be reconstructed reliably, output a structured fallback (e.g., key-value list) rather than a broken table.
• Provenance markers still point to the correct page.

12. Performance & Benchmarks (Evaluation Harness)

You can’t improve what you can’t measure. Below is a small evaluation harness you can run on a representative PDF set.

What we tested (mini-benchmark)

To make this concrete, we ran a small internal benchmark on a mixed set of 12 PDFs (3 scanned, 9 text-based) that matched common Ollagraph ingestion patterns: multi-column reports, tables-heavy financial pages, and policy documents with footnotes.

We compared two conversion variants:

• Variant A (structure-preserving): heading hierarchy + table normalization + caption/footnote adjacency + provenance anchors.
• Variant B (baseline): flattened tables into paragraphs and removed most block-level provenance markers.

For each PDF, we scored the conversion with the rubric described below and then ran 16 retrieval questions that required table reasoning (row/column lookups) and section context (heading lineage).

Sample results (averages across the 12 PDFs)

• Heading fidelity: Variant A 4.6/5 vs Variant B 2.1/5
• Table fidelity: Variant A 4.2/5 vs Variant B 1.7/5
• Context fidelity (captions/footnotes adjacency): Variant A 4.4/5 vs Variant B 2.0/5
• Citation fidelity (page mapping): Variant A 4.8/5 vs Variant B 3.0/5
• Retrieval impact (answer correctness on the 16 questions): Variant A 0.81 vs Variant B 0.46

The pattern was consistent: when tables were preserved as real Markdown tables and captions/footnotes stayed attached, retrieval returned the correct evidence more often, and citations were easier to verify.

What to measure

• Heading fidelity: does the Markdown heading hierarchy match the PDF’s logical structure?
• Table fidelity: are tables valid Markdown tables with correct header semantics and stable column counts?
• Context fidelity: are captions and footnotes adjacent to the table?
• Citation fidelity: do chunk citations map to the correct page?
• Retrieval impact: does the preserved structure improve answer correctness?

A simple scoring rubric

Score each PDF conversion on a 0–5 scale per category:

• 0: missing or severely broken
• 1: mostly broken
• 2: partially correct but unreliable
• 3: correct most of the time
• 4: consistently correct
• 5: near-perfect

Then compute an overall score.

Table fidelity checks (automatable)

For each Markdown table block:

• Validate it parses as a Markdown table.
• Check that the header row exists.
• Check that each row has the same number of columns.
• Check that the caption line exists immediately before the table.

Retrieval impact test (small but meaningful)

Create 10–20 questions that require table reasoning and section context. Examples:

• “What is the YoY change for Europe in Q4?”
• “Which policy section defines the exception described in the footnote?”
• “Compare the two regions listed in Table 2 and summarize the difference.”

Run retrieval + answer with citations for two conversion variants:

• Variant A: structure-preserving conversion.
• Variant B: baseline conversion that flattens tables.

Measure:

• Exact-match or semantic similarity for numeric answers.
• Whether citations point to the correct page.
• Whether the answer references the correct table row/column.

Decision tree: when to trust the output

Use this decision tree after conversion:

flowchart TD
  A[Table blocks found?] -->|No| B[Fallback: key-value extraction or OCR table reconstruction]
  A -->|Yes| C{Table fidelity checks pass?}
  C -->|No| D[Re-run with stricter table detection or OCR layout]
  C -->|Yes| E{Heading fidelity pass?}
  E -->|No| F[Re-map headings; adjust hierarchy rules]
  E -->|Yes| G[Proceed to heading-based chunking]

This is the difference between “we converted the PDF” and “we converted it in a way that helps RAG.”

Media: example conversion output (CLI-style)

Below is an example of what a structure-preserving conversion artifact looks like when you request Markdown plus provenance markers. The exact endpoint name may differ in your stack, but the shape of the output is what matters: page markers, stable offsets, and Markdown tables that keep header semantics.

ollagraph convert pdf-to-markdown \
  --input ./sample-report.pdf \
  --max-pages 3 \
  --return-markdown \
  --return-provenance

# output (truncated)
{
  "status": "success",
  "pages": 3,
  "time_ms": 742,
  "markdown": "## Financial Highlights\n\n*Table 2: Revenue by Region (Q4 2025)*\n\n[page=2 offset=18432]\n\n| Region | Q3 Revenue | Q4 Revenue | YoY |\n|--------|------------:|------------:|----:|\n| North America | 12,000,000 | 15,000,000 | 25% |\n| Europe | 8,000,000 | 9,000,000 | 12.5% |\n\n*Footnote a: Includes one-time adjustments.*\n\n[page=2 offset=18610]",
  "provenance": {
    "page_map": [
      {"page": 2, "offset_start": 18432, "offset_end": 18610}
    ]
  }
}

If your output doesn’t include page/offset markers (or if tables don’t parse as Markdown tables), treat it as a conversion quality issue before you index.

13. Security Considerations

PDF ingestion often involves sensitive documents. Structure preservation can increase the amount of extracted content you store and index.

Practical security steps:

• Minimize retention: store only what you need for citations and debugging.
• Encrypt at rest and in transit.
• Apply access controls per tenant.
• Consider redaction for PII before indexing.
• Log conversion failures without logging raw document content.

14. Troubleshooting

Problem: Tables render, but answers are wrong

Likely causes:

• Header row misidentified.
• Merged cells expanded incorrectly.
• Column order swapped due to reading order inference.

Fix:

• Tighten table detection thresholds.
• Enforce stable column schema.
• Add a post-conversion table validation step.

If you want a deeper dive on why stable Markdown structure improves retrieval variance, see Markdown for Retrieval-Augmented Generation (RAG): How Proper Formatting Improves AI Retrieval.

Problem: Retrieval returns the right section, but not the right row

Likely causes:

• Table chunking split the table.
• Footnotes/captions were separated into different chunks.

Fix:

• Treat tables as atomic blocks.
• Attach captions and footnotes to the same chunk.

Problem: Citations point to the wrong page

Likely causes:

• Provenance markers lost during normalization.
• Chunk metadata not aligned with Markdown block boundaries.

Fix:

• Ensure provenance markers are attached at the block level.
• Preserve page markers through chunking.

15. Best Practices

Preserve structure before you chunk

Convert PDFs into Markdown in a way that keeps headings, tables, captions, and footnotes as distinct blocks. Then chunk using those blocks (heading-based splitting + table atomicity). If you chunk first and “fix structure later,” you’ll end up embedding broken semantics.

Treat tables as first-class evidence

Tables shouldn’t be split across chunks unless they’re extremely large. Keep the table, its caption, and its footnotes in the same chunk so the model has both the numbers and the meaning.

Enforce stable table schemas

For tables that span pages, keep the same column schema across the entire table. If your converter sometimes outputs different column counts, retrieval will become inconsistent because the model can’t reliably map “column 3” to the same concept.

Normalize OCR output to match text-based output

OCR is necessary for scanned PDFs, but it often changes formatting. The best practice is to normalize OCR results into the same Markdown schema you use for text-based extraction (same heading levels, same table representation rules, same provenance marker format).

Add provenance anchors at the block level

Attach page number and stable offsets to the Markdown blocks that matter (especially tables and the sections they belong to). This makes citations reliable and makes debugging possible when users report mismatches.

Validate with automated checks before indexing

Before you embed and index, run lightweight validations:

• Do Markdown tables parse correctly?
• Does each table have a header row?
• Do rows have consistent column counts?
• Is the caption immediately before the table?

If validations fail, quarantine the document or re-run conversion with stricter settings.

Use a small, representative benchmark set

Don’t benchmark on random PDFs. Use a set that matches your real ingestion mix: multi-column layouts, tables-heavy reports, and scanned documents. Track improvements over time using the same rubric and question set.

Keep reading order reconstruction deterministic

Multi-column PDFs are where “almost right” conversions happen. Ensure your reading order reconstruction is deterministic and consistent across pages, otherwise chunk boundaries won’t align with the user’s intent.

Store conversion artifacts for auditability

Store the produced Markdown plus metadata (provenance, conversion settings, and validation results). When retrieval fails, you should be able to replay the pipeline and see exactly what the model indexed.

Prefer hybrid fallback for low-confidence tables

When table fidelity checks fail, don’t silently degrade. Use a fallback strategy (re-run with stricter table detection, or OCR table reconstruction, or a structured key-value fallback) and mark the output as lower confidence so downstream systems can react appropriately.

16. Common Mistakes

Flattening tables into paragraphs

This is the fastest way to destroy table semantics. Even if the text “looks readable,” the model loses row/column relationships and numeric alignment.

Chunking by token count only

Token-based chunking often splits tables and separates captions/footnotes from the evidence. The model then retrieves partial tables and answers become unreliable.

• Dropping captions and footnotes

  Captions explain what the table is about; footnotes define caveats and constraints. If you remove them, the model answers with numbers but without the meaning that makes those numbers correct.

• Treating OCR as a drop-in replacement

  OCR output frequently changes headings, reading order, and table structure. If you do not normalize OCR output into the same schema, you introduce structure drift and retrieval variance.

• Not validating table structure before indexing

  If you index broken tables, you are training your retrieval system to return incorrect evidence. Validation should happen before embeddings.

• Inconsistent table column counts across pages

  If the same table yields different column counts across pages, the model cannot reliably interpret columns. This often happens when merged cells or continuation logic is not handled deterministically.

• Missing or unstable provenance markers

  If citations cannot map back to the correct page, users lose trust quickly. Provenance markers must survive conversion and chunking.

• Over-optimizing for “clean text” rather than “clean meaning”

  A conversion can produce fluent Markdown while still being semantically wrong (for example, swapped columns or misidentified headers). The goal is not readability—it is retrieval correctness.

• Benchmarking on the wrong document mix

  If your benchmark does not include scanned PDFs, multi-column layouts, and table-heavy pages, you will overestimate quality and get surprised in production.

• No quarantine path for failures

  If conversion fails or validations fail, you need a quarantine strategy. Otherwise, bad outputs pollute your index and degrade retrieval for everyone.

17. Alternatives & Comparison

Alternative 1: DIY PDF parsing + OCR + table reconstruction

What it is: Build your own pipeline using PDF parsing libraries, OCR engines, and custom table reconstruction logic.

Pros

• Maximum control over extraction rules.

• You can tailor table reconstruction to your document types.

• You can keep everything in-house for compliance.

Cons

• High engineering cost and ongoing maintenance.

• Table reconstruction quality varies widely across PDF layouts.

• You must continuously tune OCR, layout reconstruction, and chunking logic.

When it is a good fit

• You have a narrow set of document templates.

• You have engineering bandwidth to maintain extraction quality over time.

Alternative 2: Hosted layout-aware PDF → Markdown conversion

What it is: Use a provider that performs layout-aware extraction, table normalization, and OCR fallback, returning Markdown ready for indexing.

Pros

• Faster time to production.

• Better baseline table reconstruction and reading order inference.

• Easier to add observability and consistent output formats.

Cons

• You depend on the provider’s table reconstruction quality.

• You still need to validate output with your own benchmark.

• Some edge-case PDFs may require fallback logic.

When it is a good fit

• You want reliable ingestion quickly and can validate outputs with a benchmark.

• Your document mix is broad and changes over time.

Alternative 3: Hybrid pipeline (hosted conversion + fallback)

What it is: Use hosted conversion for most PDFs, but detect low-confidence outputs (failed table fidelity checks, missing headers, inconsistent columns) and re-run with stricter settings or a fallback extraction path.

Pros

• Best of both worlds: speed + robustness.

• You can quarantine or reprocess only the problematic documents.

• Retrieval quality becomes more predictable.

Cons

• More moving parts than a single conversion path.

• Requires orchestration and validation logic.

When it is a good fit

• You need high reliability at scale.

• You can afford a second pass only for failures.

Alternative 4: Embed “raw PDF text” without structure preservation

What it is: Extract raw text from PDFs and embed it directly.

Pros

• Fastest to implement.

• Minimal conversion logic.

Cons

• Tables become semantically broken.

• Headings and reading order often degrade.

• Citations are harder to align with evidence.

When it is a good fit

• Only for prototypes where table reasoning is not required.

• When documents are mostly prose and structure is less important.

18. Enterprise / Cloud Deployment

Use an ingestion service with async/batch processing

In enterprise settings, you will process large document sets. Run conversion asynchronously so you do not block user requests and so you can scale conversion workers.

Add retry policies and quarantine queues

Not every PDF will convert cleanly (password-protected, corrupted, unusual layouts). Implement:

• retries for transient failures

• quarantine for persistent failures

• a way to reprocess quarantined documents after you improve conversion settings

Store conversion artifacts for audit and debugging

Keep:

• the produced Markdown

• provenance metadata

• conversion settings used

• validation results (table fidelity checks, heading fidelity checks)

This is essential for compliance and for fast debugging when retrieval answers are wrong.

Tenant isolation and access control

If you serve multiple customers:

• isolate storage per tenant

• enforce access controls at retrieval time

• ensure provenance/citations do not leak cross-tenant information

Encryption and retention policies

• encrypt at rest and in transit

• minimize retention of raw document bytes if you do not need them

• keep only what is required for citations and troubleshooting

Observability: trace conversion → chunking → indexing → retrieval

Enterprise deployments need end-to-end tracing:

• conversion timing and failure rates

• validation failure counts

• chunk counts and table block counts

• retrieval metrics tied back to conversion quality

Version your conversion settings

When you change table normalization rules or OCR/layout reconstruction behavior, you should be able to reproduce results. Version your conversion configuration and record it with each ingestion job.

Build a feedback loop from retrieval failures

When users report incorrect answers:

• identify which chunk(s) were retrieved

• map back to the conversion artifact

• update conversion settings or fallback strategies for that document type

Scale with worker pools and rate limiting

Use worker pools for conversion and apply rate limiting to protect downstream services. For OCR-heavy documents, allocate more capacity because OCR is typically the slowest step.

Plan for “structure confidence” scoring

Instead of treating all conversions as equal, compute a structure confidence score (based on heading fidelity, table fidelity, and context fidelity). Use it to:

• decide whether to index immediately

• decide whether to reprocess

• decide whether to lower trust in citations for that document

19. FAQs

1. How do I know if my converter is preserving tables correctly?

   Run table fidelity checks: validate that the output contains real Markdown tables, confirm there is a header row, and ensure every row has the same number of columns. Then validate with retrieval questions that require row/column reasoning (for example, “What is the YoY change for Europe?”) so you can confirm the table semantics survived conversion, not just the rendering.

2. Should I chunk tables separately from surrounding text?

   Usually yes, but not by splitting the table itself. Keep the table as an atomic block so row/column relationships remain intact, and include the caption and footnotes in the same chunk as the table. That way the model retrieves both the numbers and the meaning context in one evidence unit.

3. What if a PDF table spans multiple pages?

Keep a stable column schema across pages and represent continuation clearly so the model does not treat page breaks as new tables with different structure. If your converter cannot reliably reconstruct merged cells (rowspan/colspan), use a deterministic fallback strategy—such as repeating merged values or converting them into a consistent header-context representation—rather than outputting a broken or shifting table.

4. Do I need OCR if the PDF has selectable text?

Not usually. If the PDF already has selectable text, you generally want layout-aware text extraction rather than OCR, because OCR can introduce drift in headings, reading order, and table structure. Still, detect image-only pages and run OCR only where needed so you avoid mixing two different structure styles across the same document.

5. How do provenance markers help RAG?

Provenance markers let you map each retrieved chunk back to the exact page, and ideally a stable offset, in the original PDF. That makes citations trustworthy and also makes debugging practical: when a user says “that number doesn’t match,” you can trace the chunk to the source location and determine whether the issue is conversion quality, chunking boundaries, or retrieval ranking.

6. Can Markdown preserve multi-level headers?

Yes, but you need a consistent strategy. Either flatten multi-level headers into composite labels so the table remains a single header row, or represent them as multiple header rows while keeping the column mapping stable. The important part is that the model sees a consistent header structure across the table so it can interpret columns correctly.

7. What is the fastest way to improve retrieval quality after conversion?

Start with structure validation: headings and tables. Fix heading hierarchy first so chunk boundaries align with section intent, then validate table fidelity so row and column semantics are preserved. After that, measure retrieval impact on a small question set that targets table reasoning and section context—most improvements come from correcting chunk boundaries and table semantics, not from adding more text cleaning.

8. Is it better to embed tables as text or as structured features?

For most pipelines, embedding the Markdown table text is fine as long as the table is valid and semantically correct. The model benefits when the table is represented with real headers and consistent columns, because it can reason over the structured text. If you later add specialized table models or structured features, do it as an enhancement—but do not skip structure preservation in the Markdown representation.

9. How do I handle footnotes?

Keep footnotes adjacent to the table or section they modify, and preserve their markers so the model can connect the caveat to the correct claim or row. If footnotes are separated into different chunks, retrieval often returns the table without the constraints that make the numbers meaningful, which leads to confident but incomplete answers.

10. What should I do when table fidelity checks fail?

Re-run conversion with stricter table detection or OCR layout reconstruction, because fidelity failures usually indicate header misidentification, inconsistent column counts, or merged-cell handling problems. If the output still cannot be made reliable, use a deterministic fallback representation, for example a structured key-value extraction, and quarantine the document for manual review so broken tables do not pollute your index.

11. How many PDFs do I need for a benchmark?

Start small: 10–30 representative PDFs that cover your main layout types—text-based, scanned, table-heavy, and multi-column. The goal is not exhaustive coverage; it is to catch systematic failures early, such as table header drift or reading-order interleaving, so you can improve conversion quality before scaling to thousands of documents.

12. What is the biggest reason structure-preserving conversion improves answers?

It reduces semantic drift. When chunk boundaries align with headings and tables remain readable with correct header semantics, retrieval returns the right evidence more consistently, and citations become easier to verify. In practice, that means fewer “almost correct” answers and fewer cases where the model uses the wrong row or misinterprets a column because the table structure was lost during conversion.

20. References

Lewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks” (2020). This paper formalized the RAG pattern and is the foundational reference for why retrieval quality matters as much as generation quality in knowledge-intensive tasks.

Markdown specification and table conventions (general reference). Markdown’s table syntax and heading semantics are the practical reason Markdown is useful for RAG ingestion: headings provide stable section boundaries for chunking, and tables provide a structured text representation that models can interpret more reliably than flattened prose.

PDF format overview (general reference). PDFs are layout-first documents, not semantic documents. A PDF format reference helps explain why text extraction alone often fails for tables, reading order, and hierarchy—because the “meaning” is inferred from positioning rather than stored as structured objects.

21. Conclusion

Preserving tables, layout, and document structure is the difference between “we converted the PDF” and “we made the document retrievable.” A structure-preserving conversion keeps the invariants your RAG pipeline depends on: headings remain hierarchical so chunk boundaries align with intent, tables remain real Markdown tables so row and column semantics survive, and captions and footnotes stay attached so the model answers with both numbers and meaning. When you also attach provenance anchors, page and stable offsets, citations become verifiable instead of decorative.

The practical takeaway is simple: do not treat conversion quality as a subjective “looks clean” check. Start with a small benchmark that reflects your real document mix, validate table fidelity and heading fidelity with automated checks, and then confirm the impact with retrieval questions that require table reasoning and section context. Once those signals improve, scaling becomes predictable rather than risky—because you are indexing evidence that still matches what the user is asking for.