![\"A](\"/0b282edb43fc0f154ffc07f5bdbef0fb/pdf-ingestion-pipeline.svg\")
Most RAG (retrieval-augmented generation) demos start with a folder of clean Markdown. Most real RAG projects start with a shared drive full of PDFs nobody has looked at in three years. Between the two sits the parsing step, and that is where retrieval quality quietly leaks away. You can pick the best embedding model and the sharpest reranker (the model that re-scores retrieved chunks). But if the parser turned a financial table into a run-on sentence of numbers, the retriever will happily fetch that chunk and the model will happily answer with the wrong figure.
\nI hit this on two fronts. Archi is the RAG copilot I led for CMS computing operations. Its ingestion crawler pulls from internal portals, ticketing systems, and logbooks, and a good share of that source material is PDF. ARGRAG is the enterprise-document system that took second at the Argusa AI Challenge, and there the whole problem was heterogeneous documents: contracts, reports, and scanned forms, all in one corpus. Both taught me the same lesson. The parser is not plumbing you set up once and forget. It decides what your model can and cannot know.
\nThis post is for engineers building a RAG pipeline who have moved past the “hello world” of .txt files and now have to ingest real PDFs. It covers why PDFs are hard, how to tell a born-digital file from a scan, and how to extract tables without destroying them. It also covers when OCR is worth the cost, and the failure modes that will embarrass you in a demo.
The common mistake is to assume a PDF contains text the way an HTML page does. It does not. A PDF describes how to paint a page: place this glyph (one drawn character shape) at these coordinates, draw a line here, show an image there. Often there is no notion of a paragraph, a column, a table cell, or even reading order. A two-column academic paper stores its glyphs in whatever order the layout engine emitted them, and that is frequently not the order a human reads them in.
\nSo “extracting text from a PDF” really means “reconstructing logical structure from a pile of positioned glyphs.” Some PDFs make that easy. They were exported from Word or LaTeX and carry a clean text layer, meaning the file stores the actual characters alongside their positions. Others make it impossible. They are a photo of a page wrapped in a PDF container, with no text at all. Treating both kinds the same way is the first mistake.
\nThe rest of this post follows the pipeline below: triage each page, extract its text and tables directly or send it to OCR, then normalize, chunk, and embed.
\n
Before you extract anything, decide what you are holding. A born-digital PDF, one generated by software rather than scanned from paper, has a real text layer you can read directly and cheaply. A scanned PDF is just images. The only way to get text out of it is optical character recognition (OCR), which is slower and lossier. Getting this wrong hurts in both directions:
\nThe cheap, reliable test is to extract text and count how much you got per page. PyMuPDF (imported as fitz) is my default for this because it is fast and gives you page-level access. The function below counts the pages that yield almost no text and returns them as a fraction of the document.
import fitz # PyMuPDF\n\ndef looks_scanned(pdf_path, min_chars_per_page=50):\n doc = fitz.open(pdf_path)\n scanned_pages = 0\n for page in doc:\n text = page.get_text(\"text\").strip()\n if len(text) < min_chars_per_page:\n scanned_pages += 1\n return scanned_pages / max(len(doc), 1) # fraction that look scannedIf most pages come back nearly empty, the file is scanned and needs the OCR branch. Make the decision per page, though, not per document. Mixed files are common in the wild, such as a born-digital report with three scanned appendix pages stapled on. If you decide “scanned or not” once for the whole file, you either OCR everything needlessly or drop the scanned appendix. Deciding per page costs nothing and handles both cases.
\nFor born-digital pages, page.get_text("text") gets you most of the way, and PyMuPDF’s default already does a decent job of following reading flow. It falls down on multi-column layouts and on anything with sidebars, footnotes, or callout boxes. There, the glyphs for the left and right columns can interleave, and you get sentences spliced together across the gutter (the blank strip between columns).
When order matters, switch to the structured output. page.get_text("dict") returns blocks, lines, and spans, each with its bounding box (the rectangle it occupies on the page). You can then sort and group them by position yourself. The snippet below handles a simple two-column page: it splits blocks at the page’s horizontal midpoint and reads each column top to bottom.
blocks = page.get_text(\"dict\")[\"blocks\"]\n# Each block has a \"bbox\" (x0, y0, x1, y1). For a two-column page,\n# split on the page midpoint, then read each column top-to-bottom.\nmid = page.rect.width / 2\nleft = sorted((b for b in blocks if b[\"bbox\"][0] < mid), key=lambda b: b[\"bbox\"][1])\nright = sorted((b for b in blocks if b[\"bbox\"][0] >= mid), key=lambda b: b[\"bbox\"][1])\nordered = left + rightThis is crude, and it works for simple two-column layouts. For genuinely messy pages, hand-rolled geometry logic stops paying off. You want a layout-detection model instead, one trained to recognize columns, headers, and tables. That is where tools like Docling (IBM’s open-source document converter, Apache 2.0) or unstructured earn their keep. They run a layout model, recover reading order, and emit clean Markdown or a structured list of elements. The tradeoff is speed and a heavier dependency. For a large corpus I profile both, and I usually end up with a fast path for clean files and the heavier model only for the files that need it.
\nTables are the single biggest reason a RAG answer comes out confidently wrong. A table’s meaning lives in the relationships between its rows and columns, and naive text extraction throws those away. Read a table left to right and top to bottom as a stream of glyphs, and you get a line like Site Jobs Fail % CERN 4200 1.2 FNAL 3100 3.8. Embed that line and it will still be retrieved for a question about failure rates. The model will then answer with a number pulled from the wrong cell.
![\"Why](\"/a0f674105511d1b2753c5274d62f6003/table-flattening.svg\")
For born-digital tables with visible ruling lines (the drawn borders between cells), pdfplumber is precise, because it works from the actual line and rectangle objects in the PDF. The code below pulls every table from every page and rebuilds each one as a Markdown table, treating the first row as the header.
\nimport pdfplumber\n\nwith pdfplumber.open(pdf_path) as pdf:\n for page in pdf.pages:\n for table in page.extract_tables():\n # table is a list of rows, each a list of cell strings\n header, *rows = table\n md = \"| \" + \" | \".join(h or \"\" for h in header) + \" |\\n\"\n md += \"|\" + \"|\".join(\"---\" for _ in header) + \"|\\n\"\n for row in rows:\n md += \"| \" + \" | \".join(c or \"\" for c in row) + \" |\\n\"PyMuPDF now ships table detection too (page.find_tables()). Its implementation is ported from pdfplumber, so the behavior will feel familiar.
The hard case is a table with no ruling lines, where only whitespace implies the grid. Line-based detection finds nothing there, and you fall back to one of two options:
\nWhatever produces the table, store it in the chunk as Markdown (or HTML), not as a flattened line. The pipe-delimited form keeps the header attached to each value, which is exactly the context the model needs to read a cell correctly. It also survives chunking better, which matters once a big table gets split. That ties back to how you chunk documents for RAG in the first place.
\nIf triage says a page is scanned, it has no text layer, so you have to generate one. Tesseract is the standard open-source OCR engine, and you call it from Python through pytesseract. The function below renders one page to an image and runs OCR on that image.
import fitz, pytesseract\nfrom PIL import Image\nimport io\n\ndef ocr_page(page, dpi=300):\n pix = page.get_pixmap(dpi=dpi) # render page to raster\n img = Image.open(io.BytesIO(pix.tobytes(\"png\")))\n return pytesseract.image_to_string(img) # OCR to textTwo things decide OCR quality more than anything else:
\nVision-language models (VLMs, models that read images as well as text) have recently changed the calculus for OCR. A capable multimodal model can read a scanned page, preserve its table structure, and emit Markdown in one shot. On messy layouts that is genuinely better than Tesseract. The catch is cost and latency: you pay for a model call per page instead of running a local binary. For a small corpus of gnarly scans, that is a fine trade. For millions of pages it is not, and you want the cheap engine with good preprocessing.
\nOn ARGRAG we mixed both. Fast local extraction handled the clean majority, and we held heavier tools in reserve for the documents that actually needed them. Paying VLM prices for every page in the corpus would have been the wrong default.
\nThe happy path is a few dozen lines. The interesting part, as always, is where it breaks.
\nSilent empty extractions. Plain extraction on a scanned page returns an empty string, not an error. Without the triage step, those pages vanish from your index, and nobody notices until a user asks about content that simply is not there. Log a per-page character count during ingestion and alert on pages that extracted almost nothing; it is the cheapest observability you will ever add.
\nReading order scrambled across columns. Two-column PDFs are the classic case. The extracted text looks fine to a regex but reads as nonsense to a model, because sentences jump the gutter. If retrieval quality is oddly bad on a subset of documents, render a few and check whether they are multi-column before you blame the embedding model.
\nHeaders, footers, and page numbers as noise. Running headers and footers repeat on every page, and once chunked they dilute your embeddings with boilerplate. A footer that repeats the document title on all 80 pages will match a query about the title and bury the page you actually wanted. Before chunking, strip lines that repeat in the same position across most pages.
\nTables split mid-row by chunking. A fixed-size chunker can cut even a perfectly extracted Markdown table in half, orphaning the second half from its header. Keep each table intact as its own chunk when it fits. When a table is too big, repeat the header row in each piece.
\nLigatures and hyphenation. Extracted text often contains ligatures, two letters stored as a single glyph (the “fi” in “efficient”), and words hyphenated across line breaks. Both quietly hurt exact-match retrieval. A small normalization pass cleans up most of it: Unicode NFKC normalization, which splits ligatures back into plain letters, plus rejoining words that were hyphenated at a line break.
\nEncrypted or malformed files. Real corpora contain password-protected PDFs, truncated files, and PDFs that claim one page count and deliver another. Wrap extraction for each file in error handling, record which files failed and why, and keep going. One bad file should never take down a batch ingest of ten thousand.
\nIf I were starting a PDF ingestion pipeline fresh, this order saves the most pain:
\nI keep coming back to this because parsing sets the ceiling for everything downstream. The most careful work on choosing an embedding model or contextual retrieval is capped by what the parser managed to recover from the page. Get a clean, structured, correctly ordered representation out of the PDF, and the rest of the RAG stack has something real to work with. Feed it flattened tables and scrambled columns, and no reranker will save you. The same instinct is behind the Archi ingestion pipeline: retrieval is only ever as good as the parse that fed it.
\nDiagrams by M. Hassan Ahmed, released under CC0. No external image was used for this post; the figures are original work by the author.
","frontmatter":{"title":"Parsing PDFs for RAG: Text, Tables, and OCR","date":"2026-09-07T00:00:00.000Z","description":"How to parse PDFs for a RAG pipeline: detect born-digital vs scanned files, pull out tables without flattening them, and reach for OCR only when you must.","thumbnail":{"childImageSharp":{"fluid":{"base64":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAALCAIAAADwazoUAAAACXBIWXMAAAsSAAALEgHS3X78AAACAklEQVQoz0WQWVPbMBSF81JI7HiT5D22LG+yvMUEShzbIQkM9KGFKXT6QP//D+kNzLQz35w5vjpndK2ZwUejGFExGnzQst5pT+L4lg7P+fgCmo3Pye57Nr4kux/l8c1p79Wsh+RHfpxJqiervqR4OmbYTm1frK+PdbcX9a5eT931kVe9aHZF1Zft6IU1tjOdMMhDayajUDbOLBFVCFuiaKGtFloAOgdUf6GfvaSHcy1Y4ugzIxkhMJP1QEGRiiIFMwX6OFI/DHIyyxfEL0yXY5crKNQIHAEUFDwkYW1fj2+s7hvKelKdMB9IfSLijhR7a/1Eyr07/LLSr4wVIc1plEdxSWkaJ6XtxVB2UTF5+3dSHuztT7N5cO/e3cMfs3tyx9+4PDj7d7ucymqTZnWeN1xs4jiv2q23Ss4PptMrzCcjuUVpD5jrRwBWwNmA0i1pHkh6w5iIYs4Yj5MqDNM4rV24ea44qpVi2mqeQKtKdbjuCc0tlnaOglrzChQ2qpOFQeT71LRXlDJs+nEUY3M1WygO/DOpjrC81ZyS6TWdXs+6f7Pbexga4uBVQyt4U9bT9vo43NxedbUosziBsrV0CzXq1LA12MbKt1Z+C9i8N+INDBXaobCiQcRYniY8+SCiiesGs/nSmsvmJ5cSuVjgf8Dn/7lkXkjkC7AATy5l80I2/wIPgFRej56GUAAAAABJRU5ErkJggg==","aspectRatio":1.899441340782123,"src":"/static/2cd1baef737ff704c51e7dc49d568c7e/40a76/hero.png","srcSet":"/static/2cd1baef737ff704c51e7dc49d568c7e/c972b/hero.png 340w,\n/static/2cd1baef737ff704c51e7dc49d568c7e/27625/hero.png 680w,\n/static/2cd1baef737ff704c51e7dc49d568c7e/40a76/hero.png 1360w,\n/static/2cd1baef737ff704c51e7dc49d568c7e/ed396/hero.png 2000w","sizes":"(max-width: 1360px) 100vw, 1360px"}}}}}},"pageContext":{"slug":"/2026-09-07-parsing-pdfs-for-rag/","previous":"blog/2026-09-08-ivf-index-vector-search/","next":"blog/2026-09-11-cosine-dot-product-euclidean-vector-search/"}},"staticQueryHashes":["32046230"]}