Building Document Structure with Loop Engineering: Recovering a PDF's Outline from Body Typography for RAG

A structured RAG pipeline depends on the document's table of contents: retrieval scopes by section, and the chunker cuts at heading boundaries rather than mid-sentence. However, some documents lack this structure entirely. A paper exported directly from LaTeX has neither a native outline nor a printed contents page, leaving no toc_df for the pipeline to consume. Yet, the headings are visibly present in the body—section by section, larger and bolder than surrounding text. Article 5septies (TOC reconstruction from a table of content) addressed documents with a printed contents page; this article tackles those without one. The pipeline rebuilds the toc_df from the only available signal: the typographic appearance of headings.

This article is a document parsing companion in Enterprise Document Intelligence, a series that constructs an enterprise RAG system from four foundational components. It belongs to brick 1 (document parsing) and concludes the TOC-reconstruction thread initiated by Article 5 (document parsing), Article 5B (the relational data model), and Article 5septies (TOC reconstruction from a table of content).

📓 The runnable notebook guides you through the attention paper (data/paper/1706.03762v7.pdf) using the loop from line_df plus span_df to a 24-entry toc_df, containing 21 real headings and 3 false positives that LLM validation filters out. Access it at doc-intel/notebooks-vol1.

1. Context and Objectives

Article 5septies (TOC reconstruction from a table of content) established a clear boundary: TOC detection relies on existing pages (native outlines or printed tables of content), while recovering structure from body typography was relegated to summarisation. This pragmatic approach kept the TOC cascade small and testable. However, summarisation introduces different failure modes (e.g., long-context limitations, prompt sensitivity) and weaker guarantees (no fixed shape or source column). For documents with clear typographic headings in the body, summarisation is unnecessary. Instead, we require the same toc_df shape used elsewhere, populated with signals extracted from the body itself. Thus, the frontier shifts: body-typography reconstruction becomes a fourth detection case—not a summarisation fallback—within the pipeline.

Input: a line_df (plus a span_df when the parser exposes typography) where both the native TOC and printed table of contents are empty. Output: a toc_df following the standard Article 5B structure, ensuring retrieval, chunking, and summarisation operate seamlessly without modification.

With this fourth case in place, three related scenarios are handled effortlessly:

• The PDF has no structure at all, as described above.
• The PDF has a partial native outline that stops at level 2, while the body clearly shows level 3 headings (e.g., 3.2.1, 3.2.2). The body-typography pass deepens the outline's coverage.
• The PDF has a structure that is incomplete or inconsistent, where typographic analysis fills gaps or corrects misalignments. As of 2026, with the increasing adoption of AI-generated documents and varied PDF exporters, such inconsistencies are more prevalent, making this reconstruction capability essential for robust RAG pipelines.

via Towards Data Science