Document Parsing for RAG

Compare Docling and Unstructured for converting PDFs and HTML into traceable, reviewable elements and chunks for retrieval augmented generation.

Why parsing belongs in the data pipeline

A RAG corpus begins with source documents, not embeddings. PDFs and HTML contain layout, headings, tables, links, and metadata that may be lost when a pipeline extracts plain text without preserving structure. Parsing turns a source file into elements that can be validated, filtered, chunked, and traced. Docling describes conversion into a structured document representation with export options; Unstructured describes partitioning raw documents into elements such as titles and narrative text. Both projects expose a pipeline stage before chunking and vectorization.

The data engineer should treat parsed output as a derived dataset. Record source URI or stable source ID, content hash, parser and configuration version, extraction time, page or section context, and any review flags. Store enough provenance to recreate a chunk and return a citation to its source. Do not assume a parser can infer whether an extracted number, table cell, or footnote is semantically correct. Sampling and validation are still necessary, especially for scanned pages and complex layouts.

A useful pipeline separates acquisition, parsing, normalization, chunking, embedding, indexing, and serving. This makes failures easier to localize: a missing table can be an extraction issue, a broken passage can be a chunk boundary issue, and an irrelevant result can be an embedding or retrieval issue. Preserve an intermediate representation so parser changes can be compared without rerunning every downstream stage immediately.

Docling and Unstructured in context

Docling's official project page lists support for multiple formats and a structured DoclingDocument representation, with exports including Markdown and JSON. Its repository quickstart demonstrates installation and conversion using DocumentConverter. The documentation also includes separate examples for simple conversion, advanced options, formats, and chunking. Consider Docling when its document model, conversion flow, and integrations fit the formats and deployment constraints you have verified.

Unstructured's open-source documentation describes partition functions that detect a file type and produce typed elements, with format-specific functions and strategies for PDFs and images. Its chunking documentation explains that chunking operates on document elements and generally preserves whole elements except where a single element exceeds the configured maximum. Consider this workflow when element-oriented processing and the documented partition/chunk sequence fit your ingestion design. Check the specific package and system requirements for the formats you will process.

This comparison is limited to documented workflow shape, not extraction accuracy. Neither a feature list nor an example PDF establishes which parser performs better on your documents. Build a representative, permissioned corpus that includes born-digital PDFs, scanned pages, tables, headings, and the HTML patterns you actually receive. Compare extraction completeness, element structure, processing errors, runtime environment, and downstream retrieval on manually reviewed examples.

Turn parsed documents into RAG chunks

Start by checking element quality before chunking. Confirm that headings and paragraphs remain in useful order, that tables retain enough structure to interpret values, and that page references can be carried into citations. Exclude navigation or boilerplate only with a documented rule. Preserve the source text or an approved raw artifact so a reviewer can resolve differences between parser output and the original document.

Chunking should respect the source structure where possible. A heading can be attached to its following paragraphs; a table should remain together when feasible; a very long section can be split with enough repeated metadata to keep each chunk interpretable. The Unstructured docs expose options such as maximum and preferred character counts, while Docling documents chunking and serialization examples. Treat example defaults as starting points. Tune using retrieval queries and human judgments, not a generic chunk length rule.

Keep provenance in every chunk: document ID, source version, section or page, parser version, chunker configuration, and any access-control attributes needed by retrieval. If the same content appears in multiple source files, define deduplication and canonical-source rules. The index should be rebuildable from the source and transformations. If the parser changes, compare old and new output and decide whether existing embeddings must be refreshed.

Choosing between the tools

Choose by format coverage and deployment fit first. If documents must remain in a restricted environment, confirm local processing behavior and model dependencies. If you receive HTML, validate the actual page structure rather than assuming every page behaves like a static file. If PDFs contain tables or scans, inspect those cases directly and review OCR output. A tool that handles one sample does not establish reliable support for your full corpus.

Then compare developer workflow and operational costs. Record setup friction, configuration needed for each format, output schema stability, error visibility, reproducibility, and memory or compute requirements on the target host. Identify whether the pipeline can retry a failed document without duplicating its index records. Treat parser upgrades as data migrations: a changed output can affect chunk IDs, citations, embeddings, and answer quality.

A practical rollout begins with a shadow corpus. Run both parsers over an approved sample, compare extracted elements and chunk boundaries, then ask a domain reviewer to inspect the differences. Follow with a retrieval evaluation using known questions and source passages. Record the limitations and select a default with a fallback path for files requiring manual review. Do not publish a universal accuracy or speed ranking without a measured, documented experiment.

Gotchas for documents in production

Parsing can be expensive and inconsistent across input types. Capture per-file status, warnings, and enough error context to retry. Quarantine unsupported or corrupted documents rather than silently indexing empty text. Control batch size and worker parallelism based on the target machine, and keep untrusted files isolated from systems with broad credentials.

HTML and PDFs may include sensitive or copyrighted content. Confirm permission to store, transform, and send each source to any external service. If using a hosted parser or model, review data handling and regional requirements. Do not send restricted content to an API merely because a local prototype did not need credentials.

A parser output is not a citation by itself. Preserve exact source references and render them in the application in a way a user can open and verify. Test deletions and source replacements through the full chain so obsolete chunks cannot continue appearing in search. Monitor parser error rates and retrieval failures with privacy-safe identifiers, then sample output quality after material parser, OCR, or chunking changes.

Key resources

• Docling usage docs

  Check conversion examples, supported formats, output options, and chunking references.

• Unstructured partitioning

  Review element extraction and format-specific partition strategies.

• Unstructured chunking

  Understand element-aware chunk construction and current options.

• RAG

  Connect document processing to retrieval, evaluation, and freshness.

• Training data

  Apply dataset ownership and quality controls to parsed content.