In RAGFlow, what does DeepDoc parsing do that plain PDF text extraction cannot?

## Where parsing sits in RAGFlow In RAGFlow, uploading a file to a knowledge base does not index it. Parsing is a separate, explicitly triggered background job, and DeepDoc is what runs during that job before any chunking or embedding happens. The output of parsing is a set of chunks; everything downstream — embeddings, retrieval, the citations shown in chat — is only ever as good as what DeepDoc produced here. This is why RAGFlow markets itself as a "deep document understanding" engine rather than a chain library: the differentiator is the extraction layer, not the orchestration. ## Why plain extraction fails on real documents A PDF is a drawing program, not a document model. Text is a list of glyph-placement instructions with coordinates; there is no notion of "paragraph", "column", or "table". A generic text extractor emits those instructions in the order they appear in the content stream, which produces three recurring failures: - **Reading order** — a two-column paper or a magazine layout comes out with the left and right columns interleaved line by line, so sentences are spliced from unrelated columns. - **Furniture** — running headers, footers, page numbers and watermarks are text objects like any other, so they land in the middle of chunks and get embedded as if they were content. - **Tables** — the cells are just positioned text runs. Extraction gives you the values with no row/column association, so "Region: EMEA, Q3 revenue: 4.1M" becomes a bag of tokens that answers no question correctly. And a scanned document contains no text objects at all. A plain extractor returns an empty string, which silently produces a knowledge base with zero useful chunks. ## The three DeepDoc vision stages **OCR.** DeepDoc detects text regions in the rendered page image and recognizes the characters inside them. This is what makes scanned PDFs, photographs of documents and image files usable at all. It also means DeepDoc does not depend on the file having a text layer, so it behaves the same whether the PDF was exported from a word processor or produced by a scanner. **Layout recognition.** A detection model classifies each region of the page into layout categories — text, title, figure, figure caption, table, table caption, header, footer, reference, equation. Two things follow. First, RAGFlow can *discard* categories that are noise for retrieval (headers, footers, page numbers). Second, it can establish a sensible reading order and keep a caption attached to the figure or table it describes, so the chunk that contains a table also contains the sentence that explains what the table is. **Table-structure recognition (TSR).** For regions labelled as tables, a further model infers the grid: row and column boundaries, header rows, merged/spanning cells. RAGFlow serializes the result as HTML and stores it in the chunk. That is important twice over — an LLM reads an HTML table far more reliably than a whitespace-mangled one, and the table stays a single retrievable unit instead of being cut in half by a character-count splitter. ## What the chunker receives Because of this, RAGFlow's chunk methods are not operating on raw text. They receive typed, ordered regions, which is precisely what lets templates like Paper split at section titles, Presentation split at slides, or Manual split at heading hierarchy. Layout information is the input that makes per-document-type templates possible in the first place. ## What it costs, and when to skip it DeepDoc is neural inference on every page, so parse time scales with page count and is orders of magnitude slower than reading a text layer — a large scanned corpus is an hours-long, one-time job, and it is CPU/GPU-bound rather than I/O-bound. RAGFlow exposes a layout-recognition setting on the General chunk method precisely so you can turn it off and fall back to plain text extraction for clean, single-column, born-digital documents where DeepDoc buys you nothing. ## Failure modes to expect OCR misreads low-resolution scans, unusual fonts and handwriting; layout detection struggles with dense multi-column journals, sidebars and forms; TSR mis-splits borderless tables and deeply nested headers. None of these are announced as errors — you get a plausible-looking chunk with wrong content. That is exactly why RAGFlow pairs parsing with a chunk-review UI: the correct operational habit is to parse a sample, read the chunks, and only then bulk-load the corpus.