Beyond Tables: Doc2DB-Bench for Relationally Faithful Document-to-Database Construction

# Beyond Tables: Doc2DB-Bench for Relationally Faithful Document-to-Database Construction
Source: [https://arxiv.org/html/2608.08459](https://arxiv.org/html/2608.08459)
Zhuowen Liang1, Zhengxuan Zhang1, Jiayang Wang1, Jiazhuo Chen1, Nan Tang1 1The Hong Kong University of Science and Technology \(Guangzhou\)

###### Abstract

Practical AI systems increasingly need to turn long, heterogeneous documents into queryable relational databases, not isolated spreadsheets\. In domains such as finance, healthcare, education, transportation, and enterprise operations, downstream workflows rely on normalized schemas, entity identities, keys, cross\-table relationships, and integrity constraints for analytics, compliance, auditing, and SQL\-backed decision making\. Existing Document\-to\-Table benchmarks are insufficient for this setting: flattening evidence into single tables can duplicate entities, obscure many\-to\-many relationships, create sparse records, and avoid testing whether extracted facts form a valid database instance\. This creates an urgent need to evaluate document understanding as database construction rather than field extraction\. We introduceDoc2DB\-Bench, a benchmark for Document\-to\-Database construction, containing 203 long\-document instances across 42 schemas and seven domain groups, with 117 entity tables, 132 relationship tables, 7,341 rows, and 41,935 cells\. Built through a controllable DB\-to\-Doc synthesis pipeline and organized by a taxonomy of intra\-table extraction and inter\-table reasoning, the generated documents undergo authenticity verification, proving indistinguishable from real\-world references\. Doc2DB\-Bench thus provides a testbed for reliable, auditable, and relationally faithful LLM\-based data systems\. The benchmark is publicly available at[https://github\.com/SetonLiang/Doc2DB\-Bench](https://github.com/SetonLiang/Doc2DB-Bench)

## 1Introduction

Modern organizations rely on documents as the primary carrier of operational knowledge, from clinical notes and commercial contracts to financial reports and enterprise recordsidc2023unstructured;chen2023symphony;li2026dataspace\. Yet downstream applications rarely consume free\-form text directly: analytics pipelines, Business Intelligence dashboards, compliance workflows, and SQL\-backed systems require structured, queryable, and auditable datallamaindex2024extraction;zhang2025datamosaic;zeng2026qwenpaw\. As large language models become increasingly capable of processing long and heterogeneous documents, converting document evidence into reliable structured data has become a central goal of information extractionxu2024llmie;liang2026long;li2025structrag\.

Document\-to\-Table and Its Limitations\.Most existing benchmarks study this problem under theDocument\-to\-Table\(Doc2Table\) setting, where systems extract fields or populate a single flattened tabledtbench2026;DBLP:conf/emnlp/DengC00FZYS24;DBLP:journals/corr/abs\-2507\-21340;datamosaic\. This setting is useful for isolated record extraction, but it is insufficient when downstream workflows require relational databases\. Flattening multi\-entity evidence can duplicate entities, obscure many\-to\-many relationships, introduce sparse records with excessiveNULLvalues, and avoid testing whether extracted facts satisfy schema\-level constraints\.

![Refer to caption](https://arxiv.org/html/2608.08459v1/x1.png)Figure 1:Document\-to\-Database extraction: \(a\) document\(s\); \(b\) target database schema; \(c\) Extracted Entity Tables; \(d\) Extracted Relationship Tables\.###### Example 1

Consider a financial report in Fig\.[1](https://arxiv.org/html/2608.08459#S1.F1)\(a\) describing multiple companies, their cash positions across fiscal years, and investment relationships among them\. The target schema in Fig\.[1](https://arxiv.org/html/2608.08459#S1.F1)\(b\) contains an entity tableCompanyand a self\-referencing relationship tableHold, where company identifiers are system\-generated keys and do not appear in the text\.

Constructing the database requires more than extracting local values\. An LLM extractor may correctly identify many company mentions and numbers, but still produce semantically invalid tuples\. For entity extraction \(Fig\.[1](https://arxiv.org/html/2608.08459#S1.F1)\(c\)\), it may misinterpret units, such as treating “18,524 \(in thousand\)” as a raw value, or materialize weak mentions such as*Coyni Inc*as incomplete duplicate entities\. For relationship extraction \(Fig\.[1](https://arxiv.org/html/2608.08459#S1.F1)\(d\)\), surface\-level cues may induce spurious mutual investments, while implicit multi\-hop links may be missed\. These errors show that local extraction decisions must be reconciled with schema\-level semantics and integrity constraints\.□\\Box

From Extraction to Database Construction\.This motivatesDocument\-to\-Database\(Doc2DB\): given a document collectionFF, a target schemaEE, and integrity or business constraintsΣ\\Sigma, the goal is to construct a relational database instanceDDthat is both faithful to the documents and valid under the schema:\(F,E,Σ\)→Doc2DBD\.\(F,\\;E,\\;\\Sigma\)\\;\\xrightarrow\{\\;\\textsc\{Doc2DB\}\\;\}D\.Unlike Doc2Table, Doc2DB is a database construction problem\. Entity identifiers are often implicit, relationships may be distributed across document segments, and valid outputs must satisfy global constraints rather than independent field\-level decisionsdong2014knowledge;sa2016deepdive;peng2017cross;shin2015incremental\. Therefore, evaluating document understanding at the database level requires testing not only value extraction, but also entity alignment, relationship construction, and relational validity\.

Despite its practical importance, Doc2DB remains underexplored as a benchmark task\. Existing information extraction benchmarks, including Rotowirewiseman2017challenges, E2EDBLP:conf/sigdial/NovikovaDR17, LiveSumDBLP:conf/emnlp/DengC00FZYS24, InstructIEDBLP:conf/emnlp/Jiao0LZOJ023, StructTextDBLP:journals/corr/abs\-2507\-21340, and DTBenchdtbench2026, mainly focus on flat tables, single\-table extraction, or simplified generation tasks\. SQUiDDBLP:conf/emnlp/SadiaYXCC25explores text\-to\-relational database generation, but mainly targets logical relational view recovery rather than realistic Doc2DB construction\. As summarized in Table[1](https://arxiv.org/html/2608.08459#S1.T1), they do not fully evaluate cross\-table schema construction \(i\.e\., normalized multi\-table structures with inter\-table dependencies\), long\-context evidence aggregation, and database\-level correctness\.

Challenges\.Building a comprehensive Doc2DB benchmark is challenging for two reasons\. First, direct human annotation is difficult to scale: annotators must collect documents, define schemas, and manually construct ground\-truth entity and relationship tables\. Second, realistic Doc2DB instances must cover diverse reasoning requirements, including unit normalization, ambiguity resolution, multi\-hop relation construction, temporal changes, and constraint satisfaction, while also spanning domains with different narrative styles and schema structures\.

Our Proposal\.We presentDoc2DB\-Bench, a benchmark for evaluating Doc2DB capabilities beyond flat table extraction\. To avoid the scalability bottleneck of manual annotation, we design a controllable DB2Doc reverse synthesis pipeline grounded in existing relational databases such as BIRDli2023canand Spideryu2018spider\. Starting from schemas and database instances, the pipeline decomposes tuples into atomic evidence, assigns capability labels, serializes evidence into document plans, generates style\-conditioned documents, and validates the generated documents through coverage and extraction\-consistency checks\.

To model realistic document complexity, Doc2DB\-Bench introduces a two\-pillar Doc2DB taxonomy\.Intra\-Table Capabilitiescover cell\-level extraction, normalization, inference, disambiguation, and faithfulness\.Inter\-Table Capabilitiescapture database\-specific reasoning, including identity resolution, relationship linking, multi\-hop composition, dynamic change, and integrity constraints\. This taxonomy supports controlled benchmark construction and fine\-grained diagnosis of model failures\. Finally, Doc2DB\-Bench evaluates outputs at the database level by measuring both entity integrity and relational fidelity, thereby testing whether extracted facts form a schema\-conformant, queryable, and relationally faithful database instance\.

Table 1:Comparison of existing benchmarks and ourDoc2DB\-Bench\.BenchmarkSingle\-TableExtraction \(ST\)Multi\-Domain \(MD\)Cross\-TableReasoning \(CR\)Long\-Context \(LC\)DB\-LevelEval \(DC\)Rotowirewiseman2017challenges✓✗✗✗✗E2EDBLP:conf/sigdial/NovikovaDR17✓✗✗✗✗LiveSumDBLP:conf/emnlp/DengC00FZYS24✓✗✗✗✗InstructIEDBLP:conf/emnlp/Jiao0LZOJ023✓✓✗✗✗StructTextDBLP:journals/corr/abs\-2507\-21340✓✓✗✗✗DTBenchdtbench2026✓✓✗✓✗SQUiDDBLP:conf/emnlp/SadiaYXCC25✓✓✗✗✓Doc2DB\-Bench\(ours\)✓✓✓✓✓

Contributions\.We summarize our contributions as follows:

1. 1\.Doc2DB Capability Taxonomy\.We introduce a two\-pillar taxonomy of the key capabilities required for Doc2DB construction, spanningIntra\-Tablevalue extraction andInter\-Tablerelational reasoning, to guide benchmark design and support fine\-grained evaluation\.
2. 2\.Controllable DB2Doc Synthesis Pipeline\.We propose a reverse\-synthesis pipeline that generates long\-document Doc2DB instances from real relational schemas and database instances, reducing manual annotation cost while controlling document complexity\.
3. 3\.The Doc2DB\-Bench Benchmark\.We construct a multi\-domain benchmark for evaluating LLMs on relationally faithful Doc2DB tasks, going beyond flat, single\-table extraction benchmarks\.
4. 4\.Extensive Experiments\.We evaluate a broad range of mainstream LLMs on Doc2DB\-Bench and conduct in\-depth analyses across entity\- and relation\-level capabilities, revealing their strengths, limitations, and open research opportunities for Doc2DB extraction\.

## 2Document\-to\-Database: The Problem

### 2\.1Problem Statement

Database Specification\.We formalize the target database specification as𝒮=\(E,Σ\)\\mathcal\{S\}=\(E,\\Sigma\), whereE=\(ℰ,ℛ\)E=\(\\mathcal\{E\},\\mathcal\{R\}\)denotes the Entity\-Relationship schema\.ℰ\\mathcal\{E\}andℛ\\mathcal\{R\}are the sets of entity and relationship tables, respectively, and𝒯=ℰ∪ℛ\\mathcal\{T\}=\\mathcal\{E\}\\cup\\mathcal\{R\}denotes the set of tables\. Each tableT∈𝒯T\\in\\mathcal\{T\}is defined by an attribute setATA\_\{T\}and a primary keyKT⊆ATK\_\{T\}\\subseteq A\_\{T\}\.The constraint setΣ=Σrel∪Σapp\\Sigma=\\Sigma\_\{\\mathrm\{rel\}\}\\cup\\Sigma\_\{\\mathrm\{app\}\}consists of standard relational constraints, such as type, domain, and inclusion constraints, and application\-specific rules, such as temporal conditions\. Together,𝒮\\mathcal\{S\}specifies the target database structure and its validity conditions\.

Document Corpus\.We consider a collection of heterogeneous documentsF=\{f1,f2,…,fm\}F=\\\{f\_\{1\},f\_\{2\},\\ldots,f\_\{m\}\\\}that provide the evidence for instantiating the target schema\. We assume low\-level processing, such as text extraction and layout analysis, has been completed\. Since real\-world documents may contain incomplete information, unobserved attributes naturally remainNULL\. Accordingly, every extracted value should be grounded in the source documents without hallucinating unsupported information\.

Definition 1 \(The Doc2DB Problem\)\.Given a database specification\(E,Σ\)\(E,\\Sigma\)and a document corpusF=\{f1,…,fm\}F=\\\{f\_\{1\},\\ldots,f\_\{m\}\\\}, the Doc2DB task is to construct a relational database instance\(F,E,Σ\)→D​o​c​2​D​BD,\(F,E,\\Sigma\)\\xrightarrow\{\\;Doc2DB\\;\}D,whereD=\{Ix∣x∈E\}D=\\\{I\_\{x\}\\mid x\\in E\\\}is the collection of instantiated entity and relationship tables\. The target instanceDDshould satisfy \(1\)Constraint satisfaction:D⊧ΣD\\models\\Sigma; and \(2\)Closeness to ground truth:DDis as close as possible to the ground\-truth databaseD∗D^\{\\ast\}\.

### 2\.2DB2Doc Synthesis Paradigm

To construct a benchmark for evaluating Doc2DB extraction, we adopt a reverse synthesis perspective: given a ground\-truth database instanceD=Ix∣x∈ED=\{I\_\{x\}\\mid x\\in E\}with specification𝒮=\(E,Σ\)\\mathcal\{S\}=\(E,\\Sigma\), we synthesize a source document corpusFFfrom whichD∗D^\{\*\}can be faithfully recovered\.

Definition 2 \(DB2Doc Synthesis\)\.Given a ground\-truth databaseD∗D^\{\\ast\}, its specification𝒮\\mathcal\{S\}, and a capability taxonomyℋ\\mathcal\{H\}, DB2Doc synthesizes a document corpusFFsatisfying three properties: \(1\)completeness, every ground\-truth value and relational tuple inD∗D^\{\\ast\}is supported by evidence inFF; \(2\)exclusiveness,FFcontains no evidence supporting database facts beyondD∗D^\{\\ast\}under𝒮\\mathcal\{S\}; and \(3\)capability awareness, the evidence for each target value/relational tuple is constructed to require specific reasoning capabilities fromℋ\\mathcal\{H\}for its recovery, withℋ\\mathcal\{H\}formalized as a two\-pillar taxonomy in Sec\.[3](https://arxiv.org/html/2608.08459#S3)\.

The completeness and exclusiveness conditions jointly ensure thatD∗D^\{\*\}is the unique ground\-truth database recoverable fromFFunder𝒮\\mathcal\{S\}, while capability awareness enables fine\-grained evaluation across taxonomy levels\. Each instance may exercise any subset of capabilities fromℋ\\mathcal\{H\}, reflecting the naturally uneven distribution of requirements across real\-world documents\.

## 3Doc2DB Taxonomy

![Refer to caption](https://arxiv.org/html/2608.08459v1/x2.png)Figure 2:A Taxonomy of Doc2DB Extraction Capabilities\.Doc2DB requires models to construct both values and relations\. Accordingly, we organize the required capabilities into two complementary pillars\. Intra\-Table Capabilities \(Pillar 1\) asks*what values should populate an entity record*, whereas Inter\-Table \(Pillar 2\) asks*how entity records should be connected*\. Figure[2](https://arxiv.org/html/2608.08459#S3.F2)summarizes the resulting taxonomy and its fine\-grained sub\-capabilities\.

### 3\.1Pillar1: Intra\-Table Capabilities

Pillar 1 focuses on what values should populate an entity record, covering four complementary challenges\.Transformative Alignment \(TA\)\.Normalizes observed values into schema\-compatible representations \(e\.g\.,“18,524 in thousands”→18,524,000\\rightarrow 18\{,\}524\{,\}000\)\.Reasoning & Inference \(RI\)\.Derives values that are not explicitly stated \(e\.g\.,computing a target value from several reported quantities\)\.Target Discrimination \(TD\)\.Identifies the intended value among distracting or conflicting evidence \(e\.g\.,selecting the current\-year rather than a historical figure\)\.Evidence Faithfulness \(EF\)\.Avoids unsupported outputs \(e\.g\.,keeping an unreported attribute asNULL\)\. Pillar 1 extends DTBenchdtbench2026from single\-table extraction to schema\-compliant entity construction in Doc2DB\.

### 3\.2Pillar 2: Inter\-Table Capabilities

Pillar 2 focuses on how entity records should be connected, covering four complementary challenges\.Identity Resolution \(IDR\)\.Resolves ambiguous mentions to unique database entities \(e\.g\.,identifying “Lao Zhang” as the employee in the technical department among records with the same name\)\.Relationship Linking \(RL\)\.Maps entity mentions and interactions into normalized relational tuples \(e\.g\.,expanding “Alice manages X, Y, and Z” into three separate relationship rows\)\.Structural Reasoning \(SR\)\.Infers relations from distributed or compositional evidence \(e\.g\.,“Alice leads the Mobile Team” and “the Mobile Team manages Project X” imply\(Alice,Project X\)\(\\text\{Alice\},\\text\{Project X\}\)\)\.Integrity Constraint \(IC\)\.Suppresses relations that violate negative evidence or explicit constraints \(e\.g\.,not linking Bob to Project X when the document states that all managers*except Bob*are assigned to it\)\. Detailed sub\-capabilities and examples are provided in Appendix[B](https://arxiv.org/html/2608.08459#A2)\.

## 4Document\-to\-Database \(Db2Doc\) Synthesis

Given a ground\-truth relational database instanceDD, its specificationS=\(E,Σ\)S=\(E,\\Sigma\), and the capability taxonomyℋ\\mathcal\{H\}, our goal is to synthesize a document corpusFFfrom whichDDcan be faithfully recovered\. As shown in Fig\.[3](https://arxiv.org/html/2608.08459#S4.F3), our DB2Doc pipeline consists of five stages: capability assignment, evidence decomposition, strategic serialization, iterative document generation, and dual validation\.

The rationale behind this design is to separate*what*should be tested from*how*it is expressed in documents\. Capability assignment determines the target reasoning requirements; evidence decomposition grounds each target value or tuple in atomic evidence; serialization controls the document structure; generation turns the evidence into realistic long\-form text; and validation checks that the final document remains complete, faithful, and recoverable\. This staged design makes the synthesis process controllable, reproducible, and suitable for fine\-grained Doc2DB evaluation\.

![Refer to caption](https://arxiv.org/html/2608.08459v1/x3.png)Figure 3:Overview of the benchmark construction framework\.Step 1: Capability Assignment\.ALabeling Agentscans each cellvi​j∈Dv\_\{ij\}\\in Dand assigns a label setℒ​i​j⊆ℋ\\mathcal\{L\}\{ij\}\\subseteq\\mathcal\{H\}to produce an annotated matrix𝐌D\\mathbf\{M\}\_\{D\}\. The agent employs an LLM as a semantic router that jointly conditions on the cell valuev​i​jv\{ij\}, its attribute context from𝒮\\mathcal\{S\}, and the enclosing relational tuplerr, reasoning over both intra\-table semantics and inter\-table relational structure to determineℒ​i​j\\mathcal\{L\}\{ij\}\. Multi\-label assignment captures compositional requirements,e\.g\.,a cell demanding summation followed by currency conversion is labeledℒ​i​j=RI\-AR,TA\-UT\\mathcal\{L\}\{ij\}=\{\\texttt\{RI\-AR\},\\texttt\{TA\-UT\}\}, as illustrated in Sec\.[3](https://arxiv.org/html/2608.08459#S3)\.

Step 2: Joint Evidence Decomposition\.ARefiner Agentprocesses each annotated cellCi​jC\_\{ij\}and decomposes it into an atomic evidence setEi​j=e1,e2,…,ekE\_\{ij\}=\{e\_\{1\},e\_\{2\},\\dots,e\_\{k\}\}, forming the global evidence pool𝒫\\mathcal\{P\}\. Critically, the agent performsjoint executionover two orthogonal constraint dimensions simultaneously: theattribute\-level label\(Pillar 1,e\.g\.,TA\-EMfor enumeration mapping\) and therow\-level label\(Pillar 2,e\.g\.,SRfor structural reasoning\)\. To ensure evidence quality, we apply checklist\-based verification along four dimensions: \(i\)value/relation correctness, ensuring factual consistency with target values and relations; \(ii\)label faithfulness, verifying that the assigned capability is properly instantiated; \(iii\)schema linkage, checking consistency with valid schema elements and cross\-table references; and \(iv\)data integrity and null faithfulness, preventing unsupported content and preserving missing values\. Failed cases receive diagnostic feedback and are iteratively revised until verification succeeds or a retry limit is reached\. Detailed criteria are provided in Appendix[E\.2](https://arxiv.org/html/2608.08459#A5.SS2)\.

Step 3: Strategic Serialization\.ASerializer Agentlinearizes the verified evidence pool𝒫\\mathcal\{P\}into coherent blocks, controlling the document’s macro\-structure and evidence organization\. Each evidence iteme∈𝒫e\\in\\mathcal\{P\}is indexed by its entityiiand attributejj, and serialized according toV​\(e\)=\(π1,π2,ϵ\)V\(e\)=\(\\pi\_\{1\},\\pi\_\{2\},\\epsilon\), where\(π1,π2\)\(\\pi\_\{1\},\\pi\_\{2\}\)denotes a mode\-specific ordering of the entity and attribute indices\(i,j\)\(i,j\), andϵ∼U​\(0,1\)\\epsilon\\sim U\(0,1\)serves as a stochastic tie\-breaker\. We consider three serialization strategies:Horizontal\(V=\(i,j,ϵ\)V=\(i,j,\\epsilon\)\), which groups evidence by entity;Vertical\(V=\(j,i,ϵ\)V=\(j,i,\\epsilon\)\), which groups evidence by attribute across entities; andStochastic Vertical\(V=\(π​\(j\),i,ϵ\)V=\(\\pi\(j\),i,\\epsilon\)\), which follows the vertical scheme while randomly permuting the attribute order\. Together, these strategies introduce controllable variation in document structure while maintaining coherent evidence organization\.

Step 4: Iterative Document Generation\.AWriter Agentgenerates the final document block by block following the serialized plan\. A context\-aware sliding window conditions each block on the current evidenceEb​l​o​c​kE\_\{block\}and a bounded history of previously generated textHp​r​e​vH\_\{prev\}, promoting fluent transitions and consistent cross\-block coreference\.

Furthermore, to better emulate the complexity of real\-world documents, generation is controlled by aplug\-and\-play configuration module\. It supports configurable parameters such asDocument\_Length,Noise\_Level\(∈\[0,1\]\\in\[0,1\]\), andDocument\_Style\. The noise level controls the frequency of natural distractors, including irrelevant background content, formatting artifacts, and header/footer interference, while the style parameter follows domain\-specific reference documents \(e\.g\.,formal legal writing or concise clinical shorthand\)\. Together, these controls increase document realism and diversity without violating the factual constraints in the evidence pool𝒫\\mathcal\{P\}\.

Step 5: Dual Validation\.To guarantee that the synthesized documentDs​y​nD\_\{syn\}satisfies the rigorous constraints of the Doc2DB paradigm, aVerifier Agentconducts a final dual\-validation pass\. This phase operates as an inverse\-consistency check:

- •Coverage Verification:Ensures that no required atomic evidence from𝒫\\mathcal\{P\}is omitted or semantically distorted, utilizing explicit boundary tags \(e\.g\.,<frag\_ii\>…</frag\_ii\>\) injected during generation to deterministically trace textual spans back to their source atoms\.
- •Extraction Consistency:An evaluation mechanism is deployed to re\-extract the database instanceDs​y​n′D^\{\\prime\}\_\{syn\}fromDs​y​nD\_\{syn\}\. We rigorously verify the structural isomorphism and value equivalence between the re\-extractedDs​y​n′D^\{\\prime\}\_\{syn\}and the ground\-truth databaseDD\.

IfDsynD\_\{\\mathrm\{syn\}\}fails either validation criterion due to hallucinated relations, missing evidence, or referential inconsistencies, it is routed back to Step 4 for targeted rewriting with error feedback\. This closed\-loop validation minimizes unrecoverable or contradictory information in the final benchmark corpus\.

Doc2DB\-Bench Statistics\.We synthesize documents from databases sourced from BIRDli2023canand Spideryu2018spider, using them as ground truth\. Specifically, we curate 42 high\-quality databases across seven domains, including education and medical\. Details of database collection and processing are provided in Appendix[A](https://arxiv.org/html/2608.08459#A1)\. All agents use Gemini\-2\.5\-Procomanici2025geminias the backbone model, selected based on preliminary experiments balancing quality and cost\. All synthesized cases are further verified by seven computer science PhD candidates, each specializing in a corresponding domain\.

As summarized in Table[2](https://arxiv.org/html/2608.08459#S4.T2), Doc2DB\-Bench contains 42 synthesized \(Document, Specification, Database\) samples, covering 117 entity tables, 132 relationship tables, 7,341 rows, and 41,935 cells across seven domains\. The benchmark targets schema understanding, long\-context reasoning, and cross\-table dependency modeling, with fine\-grained capability annotations for 11,205 cells \(\>25%\) and 3,129 rows \(\>40%\)\. To guide realistic synthesis, we collect reference documents from DocBenchzou2025docbench, MMLongBenchma2024mmlongbench, MMDocRAGdong2025benchmarking, and web sources, spanning financial and legal reports to research abstracts\. Fig\.[2](https://arxiv.org/html/2608.08459#S3.F2)shows the capability distribution; unannotated cells and rows correspond to directly extractable cases requiring verbatim recovery\.

Table 2:Comprehensive statistics of the Doc2DB\-Bench benchmark\. The\#denotes the total count, andAvg\. Len\.indicates the average document length per sample in tokens\.DomainDocumentSchemaTable Scale \(Total\)\# DocsAvg\. Len\.\# DBs\# Ent\.\# Rel\.\# Rows\# Cols\# CellsEducation1340,42431212830963,451Finance5940,0731023391,91835310,454Medical1143,93039123431993,522University3133,913617218602094,339Sports2750,991520161,0851775,772Transportation1753,09151267181284,678Others4346,5661024261,5873139,719Total/Avg\.20343,326421171327,3411,47541,935
## 5Experiments

In this section, we systematically evaluate the performance of various LLMs on Doc2DB\-Bench for the Doc2DB extraction task\. Specifically, we seek to answer the following research questions:

RQ1:How well do different LLMs perform on Doc2DB extraction at the entity and relation levels?

RQ2:Beyond overall performance, what specific capabilities and vulnerabilities do these models exhibit across the fine\-grained dimensions defined in our taxonomy?

RQ3:How realistic and authentic are the documents generated by our automated pipeline?

Table 3:Comparative performance of LLMs on Doc2DB\-Bench\.Greenhighlights the best\.ModelSizeEntity\-LevelRelation\-LevelOverall PerformanceP\.R\.F1P\.R\.F1P\.R\.F1LSOpen\-source ModelsQwen2\.5\-14b\-Ins14b42\.8760\.1744\.0727\.4543\.5428\.9229\.4050\.3632\.9739\.39LLaMA\-3\.1\-70b\-Ins70b14\.9658\.8917\.2520\.2938\.7916\.9712\.1247\.4614\.2922\.76Qwen2\.5\-72b\-Ins72b41\.6266\.5745\.0328\.4854\.6331\.9830\.9659\.5336\.0739\.53Proprietary ModelsGPT\-4ohurst2024gpt\-72\.3970\.9270\.3062\.9446\.7850\.6865\.6655\.9959\.0547\.52GPT\-5\.4\-79\.9381\.1280\.0980\.0969\.6372\.3378\.4773\.9375\.2569\.02Gemini\-2\.5\-flashcomanici2025gemini\-75\.8975\.4874\.2173\.6057\.3559\.5071\.3364\.5865\.9953\.74Gemini\-2\.5\-procomanici2025gemini\-76\.8082\.2478\.1367\.9867\.0165\.4669\.8373\.8070\.8157\.19Claude\-opus\-4\-6\-87\.1983\.7084\.9366\.7162\.1663\.1777\.3371\.5773\.6061\.95Qwen3\-max\-76\.5177\.0075\.7757\.0159\.7455\.9663\.4866\.4263\.4452\.48Deepseek\-V4\-flash\-76\.6566\.0667\.3067\.6743\.2348\.9369\.0352\.1457\.0649\.05Specialized IE SystemsLangExtractlangextract2025google\-29\.7240\.5033\.4933\.3419\.0822\.0036\.0625\.2028\.7223\.55DocETLshankar2024docetl\-78\.2076\.8574\.9146\.7541\.2641\.5165\.2760\.9760\.8249\.87LangChainlangchain2022\-60\.7783\.0969\.0933\.5042\.4736\.3347\.2864\.3853\.8344\.14LlamaExtractllamaindex2024extraction\-52\.2868\.9556\.5847\.4148\.7347\.3945\.3556\.4949\.1040\.26

### 5\.1Setup

Baselines\.We benchmark a broad range of state\-of\-the\-art LLMs, categorized into three groups: \(1\)Open\-weight models, including Qwen2\.5\-14B/72B\-InstructDBLP:journals/corr/abs\-2412\-15115and Llama\-3\.1\-70B\-Instruct; \(2\)Proprietary APIs, including GPT\-4ohurst2024gpt, GPT\-5\.4, Gemini\-2\.5\-Flash/Procomanici2025gemini, Claude\-opus\-4\-6anthropic2026claudeopus46, Qwen3\-Max, and DeepSeek\-V4\-Flashxu2026deepseek; and \(3\)Specialized IE systems, including LlamaExtractllamaindex2024extraction, a commercial extraction service with iterative refinement and citations; LangExtractlangextract2025google, which uses chunking and few\-shot prompting for long\-document extraction; LangChainlangchain2022, a general framework with schema\-constrained function calling for structured outputs; and DocETLshankar2024docetl, a declarative LLM\-based data processing framework with modular extraction pipelines\.

Evaluation Details\.For fair and reproducible comparison, we use identical prompts and greedy decoding with temperature0across all experiments\. All systems use GPT\-5\.4 as the backbone model, except LlamaExtract, which uses its proprietary model\. To isolate relational reasoning from upstream entity extraction errors, we additionally introduce anoracle entity setting, where the modelℳ\\mathcal\{M\}receives ground\-truth entity tablesE∗E^\{\*\}and predicts only relation tables:Trel=ℳ​\(D,S,E∗\)T\_\{\\text\{rel\}\}=\\mathcal\{M\}\(D,S,E^\{\*\}\)\.

Metrics\.To evaluate extraction at a granular level, we employ the following metrics:

- •Cell\-level Accuracy\.We evaluate fine\-grained attribute extraction using cell\-level Precision, Recall, and F1\. Rather than relying on row\-level matching, which is sensitive to tuple ordering and may cause cascading alignment errors, we employ aGlobal Maximum Weight Matchingalgorithm to establish one\-to\-one tuple alignment between predicted \(TT\) and ground\-truth \(T∗T^\{\*\}\) tables \(details in Appendix[C\.1](https://arxiv.org/html/2608.08459#A3.SS1)\)\. LetCmatchC\_\{\\text\{match\}\}denote the number of cells satisfying our matching criteria \(e\.g\.,, exact numeric equality or≥90%\{\\geq\}90\\%string similarity\)\. The metrics are defined as: P=\|Cmatch\|Ctotal​\(T\),R=\|Cmatch\|Ctotal​\(T∗\),F1=2​P​RP\+R,P=\\frac\{\|C\_\{\\text\{match\}\}\|\}\{C\_\{\\text\{total\}\}\(T\)\},\\quad R=\\frac\{\|C\_\{\\text\{match\}\}\|\}\{C\_\{\\text\{total\}\}\(T^\{\*\}\)\},\\quad F\_\{1\}=\\frac\{2PR\}\{P\+R\},whereCtotal​\(⋅\)C\_\{\\text\{total\}\}\(\\cdot\)denotes the number of non\-empty cells in the corresponding table\.
- •Semantic Quality\.We employ GPT\-4o as an evaluator to assess semantic equivalence beyond exact cell matching\. It assigns a score from 0 to 100 based on factual correctness, schema conformity, and robustness to paraphrasing, capturing semantically equivalent but structurally varied predictions\. The evaluation prompt is provided in Appendix[C\.2](https://arxiv.org/html/2608.08459#A3.SS2), with further results in Appendix[D](https://arxiv.org/html/2608.08459#A4)\.

### 5\.2Experimental Results and Analysis

Overall Performance\.As shown in Table[3](https://arxiv.org/html/2608.08459#S5.T3), proprietary models consistently outperform open\-source counterparts across all metrics\. In particular, GPT\-5\.4 achieves the best overall F1 score \(75\.25\) and the highest llm score \(69\.02\), indicating strong capability in structured extraction\. Claude\-opus\-4\-6 and Gemini\-2\.5\-pro also deliver competitive performance\. Notably, GPT\-4o shows only moderate results \(Overall F1 59\.05\), falling noticeably short of reasoning\-capable models despite its scale\. In contrast, open\-source models such as Qwen2\.5\-14B\-Ins exhibit significantly lower overall F1 \(32\.97\), highlighting the persistent performance gap under complex extraction settings\.

Finding 1\.Models with stronger reasoning capabilities consistently achieve better performance on Doc2DB extraction, where structural reasoning proves critical for schema\-compliant output\.

Entity\-level performance\.Entity\-level results reveal a clear advantage of high\-capacity proprietary models\. Claude\-opus\-4\-6 achieves the highest entity\-level F1 \(84\.95\), followed by GPT\-5\.4 \(80\.09\) and Gemini\-2\.5\-pro \(78\.13\)\. These models maintain a good balance between precision and recall, indicating robust span detection and boundary alignment\. Compared to them, Qwen2\.5\-14B shows notably lower precision \(42\.87\) despite relatively higher recall \(60\.17\), suggesting that open\-source models tend to over\-generate entity spans, leading to reduced accuracy\.

Relationship level performance\.Relation extraction is evaluated under an oracle entity setting: given the relational schema, the source document, and the ground\-truth entity tables, the model generates only the relation tables\. This setting isolates relational reasoning ability from upstream entity extraction errors\. As shown in Table[3](https://arxiv.org/html/2608.08459#S5.T3), relation\-level extraction remains substantially more challenging than entity extraction for most models\. A key reason is that relation prediction requires not only identifying the correct records, but also globally aligning related entities and tuples under a structured schema, which is more error\-prone than localized entity extraction\. GPT\-5\.4 achieves the best relation\-level F1 \(72\.33\), outperforming GPT\-4o \(50\.68\), Gemini\-2\.5\-pro \(65\.46\), and Claude\-opus\-4\-6 \(63\.13\), indicating stronger capability in global alignment and structured relational reasoning\.

Finding 2\.Relation\-level extraction is a major bottleneck in Doc2DB extraction\. Compared with entity extraction, it is substantially more challenging because it requires accurate global alignment across entities and tuples, leading to consistently lower performance\.

Table 4:The Comparison of Capabilities Across Different Models for Different Categories\. Cell colors represent performance levels \(Blue: High; Red: Low\)\.CapabilitySub\-capabilitiesGPT\-4oQwen3\-MaxGPT\-5\.4Entity Disambiguation51\.5859\.9269\.2455\.2564\.5772\.9680\.0379\.49IdentityResolutionCoreference Resolution37\.8450\.1361\.1462\.1056\.7667\.6177\.7182\.18One\-to\-Many Allocation49\.0651\.9065\.6362\.2764\.7770\.3878\.1881\.83Multi\-Entity Binding47\.6553\.8560\.1853\.8358\.5764\.8267\.2682\.97RelationshipLinkingConditional Linkage52\.0257\.4769\.1062\.6561\.8069\.6475\.8179\.16Transitive Inference40\.8057\.8365\.5157\.3553\.7859\.4870\.8278\.47Global Aggregation49\.2348\.3071\.5959\.8362\.1564\.2573\.0382\.20StructuralReasoningDynamic Change36\.5151\.8358\.1146\.9358\.3666\.2678\.6979\.27Referential Integrity\-\-\-\-\-\-\-\-IntegrityConstraintMutual Exclusion36\.4156\.9460\.1858\.4554\.6161\.9670\.3974\.46

![Refer to caption](https://arxiv.org/html/2608.08459v1/figs/radar_chart4.png)Figure 4:Radar chart of different models across various capabilities\.
![Refer to caption](https://arxiv.org/html/2608.08459v1/x4.png)Figure 5:Impact of capability annotations on extraction performance\.

### 5\.3Capability\-Level Performance

As revealed in Section[5\.2](https://arxiv.org/html/2608.08459#S5.SS2), relation extraction is the primary bottleneck in Doc2DB extraction, yet overall metrics do not revealwhich specific inter\-table capabilitiesremain challenging for LLMs\. We therefore conduct a fine\-grained evaluation over Pillar 2 capabilities in our taxonomy\.

For each capability, we compute cell\-level Precision, Recall, and F1on the corresponding annotated relation tables using the same matching criteria, enabling fine\-grained analysis of inter\-table reasoning abilities such as entity linking, relation alignment, and multi\-hop dependency recovery\.

Capability assignment introduces difficulty\.As shown in Fig\.[5](https://arxiv.org/html/2608.08459#S5.F5), models perform consistently worse on documents with explicit capability labels than on those without\. The drop is substantial at the entity level, with GPT\-5\.4 decreasing from 74\.15 to 56\.75 and Qwen3\-max from 66\.70 to 52\.37\. At the relation level, the decline is smaller but consistent across models \(GPT\-5\.4: 67\.77 to 58\.69; Qwen3\-max: 56\.63 to 51\.23; Gemini\-2\.5\-pro: 66\.49 to 60\.26\)\. These results confirm that capability\-annotated documents are genuinely harder and validate the effectiveness of our taxonomy\.

Detailed Error Analysis\.Fig\.[5](https://arxiv.org/html/2608.08459#S5.F5)shows that GPT\-5\.4 performs best across all capabilities, while Table[4](https://arxiv.org/html/2608.08459#S5.T4)reports fine\-grained results across four inter\-table capabilities, revealing three key findings:\(i\) Implicit evidence amplifies model disparities\.Surface\-level tasks rely on explicit cues, whereas coreference resolution and multi\-entity binding require aggregating scattered implicit evidence, significantly widening the gap between strong and weak models\.\(ii\) Structural reasoning remains a major bottleneck\.Even SOTA models plateau at around 80% on Dynamic Change and Transitive Inference, while smaller models fall below 40%, indicating limited multi\-step relational reasoning ability\.\(iii\) Integrity Constraint \(IC\) verification is consistently weak\.Models often hallucinate dependencies in Referential Integrity tests and violate exclusivity rules in Mutual Exclusion tasks, highlighting the lack of constraint\-aware generation and potential risks to database reliability\.

Finding 3\.\.Implicit reasoning over distributed and compositional evidence increases difficulty and widens model gaps, with structural reasoning and integrity constraints as the primary failure modes\.

Table 5:Quality and Authenticity evaluation of Doc2DB\-Bench documents using \(a\) rubric\-based LLM and human assessment and \(b\) commercial AI detectors\.JudgerLexicalLogicalTextualGenreAverageRichnessConsistencyCoherenceFidelityLLM4\.464\.283\.844\.944\.38Human4\.173\.973\.984\.004\.03

MethodDoc2DB\-BenchReferenceZeroGPT35\.2023\.12FastGPTbao2023fast37\.5035\.38

### 5\.4Authenticity Verification

To evaluate document quality and realism, we conduct a rubric\-based assessment using both an LLM judge and human annotators\. Documents are evaluated along four dimensions:*lexical richness, logical consistency, textual coherence, and genre fidelity*, using a five\-point scale\. We use DeepSeek\-V3\.2 as the automatic evaluator and recruit five graduate students document intelligence research experience to independently assess 50 randomly sampled documents using the same rubrics\. As shown in Table[5](https://arxiv.org/html/2608.08459#S5.T5)\(a\), the LLM and human evaluations consistently demonstrate the high linguistic quality and domain authenticity\. Furthermore, commercial AI detectors \(ZeroGPT and FastGPTbao2023fast\) show that Doc2DB\-Bench closely matches real\-world distributions in AI\-generation scores \(Table[5](https://arxiv.org/html/2608.08459#S5.T5)\(b\)\)\. Notably, the FastGPT score \(37\.50%\) is nearly identical to the real\-data baseline \(35\.38%\)\. Overall, these results demonstrate that Doc2DB\-Bench preserves the lexical diversity and stylistic nuances of human\-written reports, achieving high fidelity\. More details are provided in Appendix[F](https://arxiv.org/html/2608.08459#A6)\.

## 6Related Work

Structured Information Extraction\.Traditional IE decomposes the problem into sub\-tasks such as named entity recognition and relation extraction, evolving from rule\-based methodshobbs1993fastus;lee2013attributeto pretrained language model\-based approachesli2022sparse;wu2008information;zheng2018opentag\. Such pipelines are difficult to customize for schema\-driven extraction, where target attributes may fall outside existing ontologiesDBLP:conf/emnlp/Jiao0LZOJ023\. Recent work leverages LLMs for structured extraction: some advanced prompting methodsDBLP:conf/emnlp/DengC00FZYS24;ahuja2025map;tang2024strucdecompose complex extraction tasks into intermediate steps; StructSumjain2024structsumgenerates structured summaries as tables and mind maps; InstructIEDBLP:conf/emnlp/Jiao0LZOJ023, Lotuspatel2025semantic, and PZliu2025palimpzestextract specified attributes through natural\-language queries; Doctopuschai2025doctopuscombines LLMs with traditional IE tools to reduce cost\. However, existing work focuses on Doc2Table extraction over single flat tablestang2024struc;DBLP:conf/emnlp/DengC00FZYS24;DBLP:conf/emnlp/Jiao0LZOJ023;liang2026long, while the Doc2DB setting, which requires constructing multi\-table relational databases with inter\-table dependencies and integrity constraints from documents, remains largely unexplored\.

Existing Benchmarks\.Prior benchmarks largely repurpose table\-to\-text datasets such as Rotowirewiseman2017challengesand Wiki40Bguo2020wiki, which support only trivial extraction reducible to direct text replication\. LiveSumDBLP:conf/emnlp/DengC00FZYS24covers limited domains, while synthetic benchmarks InstructIEDBLP:conf/emnlp/Jiao0LZOJ023and StructTextDBLP:journals/corr/abs\-2507\-21340suffer from simplified schemata and trivial text–tuple alignments\. Meanwhile, SemBenchlao2025sembenchand UDA\-Benchsubramaniyaswamy2015unstructuredtarget unstructured document analysis but lack fine\-grained capability evaluation\. More recent DTBenchdtbench2026introduces capability\-aware evaluation for document\-to\-table extraction, but remains limited to flat\-table extraction without cross\-table relational construction\. SQUiDDBLP:conf/emnlp/SadiaYXCC25further explores text\-to\-relational database generation with multi\-table schema synthesis, yet mainly evaluates logical relational view recovery from simple descriptions rather than realistic Doc2DB task requiring cross\-table reasoning and database\-level consistency\. These limitations motivate Doc2DB\-Bench, the first benchmark for systematic LLM evaluation on document\-to\-database extraction\.

## 7Conclusion

We introduce Doc2DB\-Bench, a novel benchmark advancing information extraction from isolated flat tables to relationally faithful document\-to\-database construction\. To overcome manual annotation bottlenecks, we propose a controllable reverse\-synthesis pipeline grounded in a comprehensive taxonomy of intra\-table and inter\-table capabilities\. Extensive evaluations reveal that while state\-of\-the\-art LLMs excel at localized entity extraction, they fundamentally struggle with global relational alignment, multi\-hop structural reasoning, and adherence to database integrity constraints\. Doc2DB\-Bench provides a rigorous and realistic testbed for advancing reliable, schema\-compliant, and auditable LLM\-based data systems, with further dataset expansion underway\.

## Limitations

While Doc2DB\-Bench provides broad coverage across diverse schemas and domains, several aspects remain open for further exploration\. The current DB2Doc synthesis pipeline relies on LLM\-based generation, making human verification important for ensuring the quality and realism of synthesized documents\. Beyond synthesis quality, we also plan to expand the benchmark by incorporating more domain\-specific databases and broader real\-world sources, strengthening its coverage and diversity\.

## References

## Appendix ADataset Collection and Processing

To establish a relationally faithful ground truth for Doc2DB\-Bench, we curated a collection of complex relational databases from two predominant text\-to\-SQL benchmarks: BIRD\[li2023can\]and Spider\[yu2018spider\]\. The collection process followed a multi\-stage pipeline designed to maximize domain diversity and structural complexity\.

### A\.1Database Selection and Sourcing

We first screen the database pools from BIRD and Spider, selecting databases that are suitable for document\-to\-database evaluation\. Specifically, we prioritize databases with at least three interconnected tables, non\-trivial schemas involving multiple entity types, relationship tables, and foreign\-key dependencies, as well as diverse cross\-table dependencies\. To ensure broad coverage, the final collection spans seven domains, including education, finance, healthcare, university, sports, transportation, and others\. Unlike conventional benchmarks that focus on flat\-table extraction, our selection favors databases with rich entity\-relationship \(ER\) structures and explicit relational dependencies, enabling the evaluation of cross\-table reasoning and database construction capabilities\.

### A\.2Data Cleansing and Schema Refinement

The raw databases underwent several refinement steps to ensure they were suitable for document synthesis:

- •Schema Standardization:We normalize attribute names, unify schema representations, and ensure that primary and foreign keys are explicitly defined\. This step reduces schema ambiguity and facilitates reliable DB\-to\-document synthesis\.
- •Tuple Sampling and Instance Construction:Since using all database tuples may produce excessively long documents and dilute evidence density, we sample representative tuples while preserving entity coverage, inter\-table relationships, and referential integrity\. The resulting instances remain complete relational databases rather than isolated table fragments, yielding 117 entity tables and 132 relationship tables with 7,341 rows and 41,935 cells\. Fig\.[6](https://arxiv.org/html/2608.08459#A1.F6)further illustrates the distribution of database scales in terms of rows, columns, and cells\.
- •Integrity Verification:We perform SQL\-based sanity checks on the sampled databases to ensure that all instances satisfy relational constraints, including primary\-key uniqueness, foreign\-key referential integrity, and attribute\-level validity\. We further verify schema consistency, table connectivity, and tuple completeness to ensure that sampled instances preserve the original relational structures without introducing broken dependencies or isolated fragments\. Only verified database instances are retained for subsequent document synthesis\.

![Refer to caption](https://arxiv.org/html/2608.08459v1/x5.png)Figure 6:Distribution of database scale in Doc2DB\-Bench in terms of rows, columns, and cells\.
### A\.3Domain\-Specific Style Grounding

Although databases from BIRD\[li2023can\]and Spider\[yu2018spider\]provide diverse domain schemas and structured facts, they are not designed to capture realistic document styles and writing conventions\. To improve document realism, we augment the structured data with domain\-specific narrative styles by collecting reference documents from LongDocURL\[deng2025longdocurl\], DocBench\[zou2025docbench\], MMLongBench\[ma2024mmlongbench\], and MMDocRAG\[dong2025benchmarking\]\. These references cover diverse document formats, ranging from academic papers and financial reports to posters and restaurant menus, serving as stylistic anchors for the synthesis pipeline\. They enable the generation of authentic domain\-specific documents while strictly preserving the factual constraints of the underlying databases\.

### A\.4Verification Procedure\.

Although our dataset is generated through a multi\-agent synthesis pipeline, we incorporate a rigorous verification procedure to ensure the quality and reliability of the synthesized documents\.

First, our framework includes a dedicatedValidator Agentthat performs automatic verification from two perspectives\. At the fine\-grained level, it checks whether generated sentences and paragraphs faithfully cover the information contained in the source databases, preventing missing or incomplete evidence\. At the database reconstruction level, it evaluates whether the complete database can be accurately recovered from the generated document\. Any detected inconsistencies or missing information trigger an iterative repair process to refine the generated documents\. Detailed verification and repair procedures are provided in Appendix[E\.4](https://arxiv.org/html/2608.08459#A5.SS4)\.

Second, we conduct human verification on the generated documents\. We recruit seven PhD candidates in computer science, with each reviewer responsible for one specific domain\. Each reviewer evaluates the synthesized documents from two aspects: \(1\) whether the document style and content align with realistic domain\-specific documents encountered in practice; and \(2\) whether the underlying database information can be reliably reconstructed from the generated document\. Any cases that fail these criteria, such as unrealistic document patterns, missing database evidence, or inconsistent entity relationships, are filtered out to ensure the quality and reliability of the final dataset\.

### A\.5Dataset Visualization\.

![Refer to caption](https://arxiv.org/html/2608.08459v1/x6.png)Figure 7:Representative examples from the finance, healthcare, and education domains\. Each case pairs a multi\-table relational schema with a domain\-specific synthesized document, where colored links illustrate the grounding between database records and document evidence\.Figure[7](https://arxiv.org/html/2608.08459#A1.F7)presents representative examples from the finance, healthcare, and education domains, each pairing a multi\-table relational schema with a realistic domain\-specific document\. For example, in the finance case, company information is stored in theCompaniestable, quarterly revenue and net income inQuarterly\_Financials, and closing prices inStock\_Prices\. The synthesized equity research report integrates these distributed records into statements such as “Acme Corp reported revenue of $125\.0 million and net income of $18\.2 million,” while linking them through the sharedcompany\_id\. Recovering the database therefore requires not only extracting individual values, but also resolving entity references, normalizing expressions such as125,000,000and “$125\.0 million,” and correctly assigning evidence to multiple related tables\. Similar examples across the other domains illustrate the diversity of schema structures, document styles, and cross\-table dependencies covered by Doc2DB\-Bench\.

## Appendix BDetails of dual\-level Taxonomy

![Refer to caption](https://arxiv.org/html/2608.08459v1/x7.png)Figure 8:Challenging examples of relation extraction that require different inter\-table capabilities\.Pillar 2 inter\-table capabilities are organized into the following four types:

Relationship Linking \(RL\)\.This capability is required when natural language narratives must be parsed and mapped into structured relational tuples, accurately aligning multiple entities across tables based on cardinality and business rules\. We categorize this linking into three subcategories\.

One\-to\-Many Allocation\.The document provides a compressed statement \(e\.g\.,a manager taking over multiple projects\), requiring the model to expand it into multiple normalized relationship rows that preserve the underlying 1:N or N:1 cardinality rather than collapsing them\. As illustrated in Fig\.[8](https://arxiv.org/html/2608.08459#A2.F8)\(a\), a statement assigning Alice to Projects X, Y, and Z must be expanded into three separate relationship tuples\.

Multi\-Entity Binding\.The document describes intertwined N\-ary relations \(e\.g\.,distinct suppliers delivering different parts to various projects\) in a dense narrative, requiring exact triplet or multi\-entity alignment without mismatching pairs or hallucinating spurious links based on text proximity\.

Conditional Linkage\.Requires evaluating existing table attributes against implicit business rules to automatically establish foreign key relations, even without explicit entity name mentions\.

Identity Resolution \(IDR\)\.This capability is required when entity references within the document are ambiguous, pronominal, or use aliases, necessitating cross\-referencing with table attributes or surrounding context to ground the mention to a unique, exact database record\.

Entity Disambiguation\.The document uses an ambiguous alias or name that matches multiple database records, requiring contextual clues and schema attributes to identify the correct entity\. As shown in Fig\.[8](https://arxiv.org/html/2608.08459#A2.F8)\(b\), the alias “Lao Zhang” must be resolved to the employee in the technical department based on the surrounding “technical issue” context\.

Coreference Resolution\.The target entity is referred to using pronouns, role titles, or implicit aliases scattered across sentences, requiring cross\-sentence contextual reasoning to correctly resolve these coreferences to the anchor entity and populate the corresponding relationship fields\.

Structural Reasoning \(SR\)\.This capability is required when relational links cannot be directly extracted from a single text span but must be logically deduced by chaining multiple implicit relations, table structures, or temporal events\.

Transitive Inference\.The document and existing tables provide linked but disjointed relational pairs \(e\.g\.,entity A is linked to B, and B is linked to C\), requiring the deduction of implicit transitive relations to populate the target schema\. Fig\.[8](https://arxiv.org/html/2608.08459#A2.F8)\(c\) illustrates this case: “Alice leads the Mobile Team” and “the Mobile Team manages Project X” must be composed to recover the implicit relation between Alice and Project X\.

Global Aggregation\.The attributes required to form a complete multi\-dimensional relationship are scattered across disjointed text spans, requiring multi\-hop reading comprehension to logically chain these spans and assemble all necessary foreign keys into a single valid record\.

Dynamic Change\.The document narrative involves cross\-table event timelines, sequential actions, or entity state changes over time \(e\.g\., completing a prerequisite course before a new enrollment\), requiring reasoning over these temporal dynamics to determine the final, valid relationship status\.

Integrity Constraint \(IC\)\.This capability is required when the extraction of relationships is governed by negative evidence, exceptions, or boundary rules, demanding that the model suppress naive co\-occurrence extraction and strictly adhere to database integrity\.

Null Relation Extraction\.The document provides explicit negative evidence, such as cancelled events or unmet prerequisites, requiring the model to identify an empty relation state \(e\.g\.,outputtingNULL\) and avoid hallucinating links from superficial keyword co\-occurrence\.

Mutual Exclusion\.The document specifies broad relationships alongside explicit exceptions or negative constraints, requiring the model to infer relationship boundaries and exclude invalid relational tuples\. As illustrated in Fig\.[8](https://arxiv.org/html/2608.08459#A2.F8)\(d\), although all managers are generally assigned to Project X, the explicit exception “except Bob” requires suppressing the tuple\(Bob,Project X\)\(\\text\{Bob\},\\text\{Project X\}\)\.

## Appendix CExperiment Setup

### C\.1Metric Design Principles: Cell Alignment for Evaluation

Naive sequential matching aligns predicted rows to ground\-truth rows by position, which is fragile in two ways\. Cross\-Tuple Hijacking: a model extracts the correct value but assigns it to the wrong row, penalizing an otherwise valid prediction\. Cascading Misalignment: a single missed or inserted row shifts all subsequent alignments, inflating both false\-positive and false\-negative counts\. To address both failure modes, we adopt aGlobal Maximum Weight Matchingstrategy over a bipartite graph of ground\-truth and predicted rows\.

Notably, We do not use primary keys as alignment anchors because database\-specific identifiers, particularly surrogate keys, are often absent from real\-world documents and must be generated during database construction\. Different models may therefore assign different identifiers to otherwise equivalent records\. Primary\-key\-based matching would conflate arbitrary identifier generation with extraction correctness\. We instead align rows using shared non\-key attributes and evaluate key validity separately through database\-integrity metrics\.

LetT∗=\{r1∗,…,rm∗\}T^\{\*\}=\\\{r^\{\*\}\_\{1\},\\ldots,r^\{\*\}\_\{m\}\\\}andT=\{r1,…,rn\}T=\\\{r\_\{1\},\\ldots,r\_\{n\}\\\}denote the ground\-truth and predicted row sets, respectively\. Matching proceeds in four stages\.

Stage 1: Global Scoring Matrix\.Let𝒦\\mathcal\{K\}be the shared column names betweenT∗T^\{\*\}andTT\. For each pair\(ri∗,rj\)\(r^\{\*\}\_\{i\},r\_\{j\}\), we compute a composite similarity score:

s​\(ri∗,rj\)=1\|𝒦\|​∑k∈𝒦sim​\(ri∗​\[k\],rj​\[k\]\),s\(r^\{\*\}\_\{i\},\\,r\_\{j\}\)\\;=\\;\\frac\{1\}\{\|\\mathcal\{K\}\|\}\\sum\_\{k\\in\\mathcal\{K\}\}\\mathrm\{sim\}\\\!\\left\(r^\{\*\}\_\{i\}\[k\],\\,r\_\{j\}\[k\]\\right\),wheresim​\(⋅,⋅\)\\mathrm\{sim\}\(\\cdot,\\cdot\)returns11for exact numeric equality after normalization and uses normalized Levenshtein similarity for textual values:

simtext​\(a,b\)=1−dLev​\(norm​\(a\),norm​\(b\)\)max⁡\(\|norm​\(a\)\|,\|norm​\(b\)\|\),\\mathrm\{sim\}\_\{\\mathrm\{text\}\}\(a,b\)=1\-\\frac\{d\_\{\\mathrm\{Lev\}\}\(\\mathrm\{norm\}\(a\),\\mathrm\{norm\}\(b\)\)\}\{\\max\\bigl\(\|\\mathrm\{norm\}\(a\)\|,\|\\mathrm\{norm\}\(b\)\|\\bigr\)\},wheredLevd\_\{\\mathrm\{Lev\}\}denotes the Levenshtein edit distance andnorm​\(⋅\)\\mathrm\{norm\}\(\\cdot\)applies lowercasing, whitespace normalization, and punctuation normalization\. Missing or incompatible values receive a score of0, yielding a globalm×nm\\times nscoring matrix\.

Stage 2: Global Sorting\.All pairs withs​\(ri∗,rj\)≥τs\(r^\{\*\}\_\{i\},r\_\{j\}\)\\geq\\tau\(τ=0\.3\\tau=0\.3\) are sorted globally in descending order, ensuring high\-confidence pairs are resolved first and cannot be preempted by lower\-scoring candidates\.

Stage 3: Double\-Locking Assignment\.Pairs are assigned greedily from the ranked list\. Once\(ri∗,rj\)\(r^\{\*\}\_\{i\},r\_\{j\}\)is matched, both indices are locked and excluded from further assignment, enforcing strict one\-to\-one mapping and preventing score inflation via duplicate row generation\.

Stage 4: Cell\-Level Settlement\.Within each matched pair, scoring proceeds cell\-by\-cell as defined in Section[5](https://arxiv.org/html/2608.08459#S5)\. Unmatched ground\-truth rows contribute all non\-empty cells to the missing count; unmatched predicted rows contribute to the hallucination count, ensuring every cell is accounted for exactly once\.

### C\.2Prompts for LLM Score\.

LLM\-as\-a\-Judge: Database Extraction Evaluation PromptYou are a database evaluation expert\. Please evaluate the quality of database tables extracted from documents\.Evaluation Dimensions:•Accuracy:Semantic consistency, exact numeric matching \(including decimal places\), and string similarity≥\\geq90%\.•Completeness:Presence of all key information from the standard answer and structural integrity\.•Standardization:Compliance with Schema definitions and data type/format consistency\.Scoring Constraints:•Numeric values must beexactly equal; string similarity below 90% is a mismatch\.•Type mismatches are considered serious errors\.•Total score ranges from 0 to 100; a perfect match equals 100 points\.Output Format:Provide a comprehensive explanation \(≤\\leq100 words\), then output the score as:Evaluation evidence: \[explanation\] Rating: \[\[score\]\]

## Appendix DMore Doc2DB\-Bench Evaluation

### D\.1Database Integrity Analysis\.

![Refer to caption](https://arxiv.org/html/2608.08459v1/x8.png)Figure 9:Database\-level performance across Entity Coverage, Relation Coverage, and Reference Integrity Rate\.Metric\.Beyond attribute accuracy, we evaluate whether models can construct structurally complete and constraint\-consistent databases\. We measure*Entity Coverage*and*Relation Coverage*to assess the recovery of entities and inter\-entity relationships, respectively\. We further report*Reference Integrity Rate*, which measures the proportion of foreign\-key references that correctly point to existing entities, reflecting the validity and consistency of the constructed database\.

Result\.Database\-level results show that reconstruction requires both structural coverage and valid cross\-table references\. Entity Coverage exceeds Relation Coverage by 12\.17–24\.52 points across all models, highlighting the greater difficulty of recovering inter\-table relationships\. Coverage also does not guarantee validity: Gemini\-2\.5\-Pro achieves strong coverage but the lowest RRIR, revealing frequent cross\-table reference errors\. GPT\-5\.4 leads all three metrics, demonstrating the strongest ability to recover relational structures while preserving database consistency\.

Finding 4\.Database construction requires more than accurate extraction: maintaining relational consistency and valid entity references remains a critical challenge for LLMs\.

### D\.2Full Results of Different Domains

Table 6:Results onDoc2DB\-Benchacross various domains\.*Ver\./Size*shows model version or size\.MethodsVer\./SizeDomainOverallAcc\.\\mathrm\{Acc\.\}Edu\.Fin\.Med\.Uni\.SportsTrans\.Others*Open\-source Models*Qwen2\.514B\-Ins13\.2534\.2137\.3536\.4418\.1647\.3134\.8232\.97LLaMA\-3\.170B\-Ins10\.9413\.1816\.2921\.5427\.867\.308\.1614\.29Qwen2\.572B\-Ins30\.4134\.7940\.9847\.7331\.8738\.8029\.9836\.07*Proprietary Models*GPT\-4o\-47\.8957\.4954\.2072\.3262\.7568\.0251\.1159\.05GPT\-5\.4\-67\.6768\.6566\.6874\.7882\.2485\.2278\.4975\.25Gemini 2\.5Flash57\.6364\.0441\.0073\.1371\.2278\.9564\.5765\.99Gemini 2\.5Pro69\.8165\.4676\.5379\.7569\.6774\.7867\.9470\.81Claude Opus4\-667\.0165\.3875\.5180\.0178\.3687\.8369\.8973\.60Qwen3Max52\.0662\.5556\.3772\.1557\.2470\.7364\.1052\.80DeepSeek\-V4Flash53\.6659\.3948\.2355\.6057\.7973\.5651\.8057\.06

The results reveal a substantial performance gap between open\-source and proprietary models\. Among open\-source models, Qwen2\.5\-72B achieves the highest overall accuracy of 36\.07, but still trails GPT\-5\.4 by 39\.18 points\. GPT\-5\.4 obtains the best overall accuracy of 75\.25 and leads in finance, sports, and other domains\. Nevertheless, no single model dominates across all domains: Gemini 2\.5 Pro performs best in education and medicine, while Claude Opus 4\-6 leads in university and transportation, suggesting that different domains place distinct demands on schema interpretation, cross\-table reasoning, and domain\-specific information normalization\.

Domain\-level performance can be further understood from the normalized dataset statistics\. Averaged across all evaluated models, transportation achieves the highest accuracy \(63\.25\), followed by university \(61\.35\), whereas education obtains the lowest accuracy \(47\.03\)\. Education contains the largest number of rows per database \(276\.7\), together with 8\.0 tables and 4\.0 relation tables on average, requiring models to recover a relatively large number of tuples while preserving cross\-table associations\. Finance is also challenging, but primarily because of its relational density rather than its absolute size: each database contains 6\.2 tables and 3\.9 relation tables on average, with the highest relation\-to\-entity ratio of 1\.70\. Medical databases present a different difficulty, having the largest average numbers of columns \(66\.3\) and cells \(1,174\.0\) per database, which increases the burden of broad attribute coverage\. In contrast, although transportation documents are the longest on average \(53,091 tokens\), their databases contain only 3\.6 tables and 1\.2 relation tables per database, suggesting that document length alone is not the dominant source of difficulty\. Overall, the results indicate that performance is more strongly influenced by the interaction of tuple volume, schema width, relation density, and implicit cross\-table dependencies than by document or database scale in isolation\.

## Appendix EImplementation of Doc2DB

During the entireControllable DB2Doc Reverse\-Synthesisprocess, we design specific prompts and rigorous verification protocols across four key agentic modules to ensure generation fidelity and relational complexity\.

Firstly, in the capability assignment stage, theLabeling Agentacts as a semantic router\. We construct prompts to strategically assign fine\-grained intra\-table \(Pillar 1\) and inter\-table \(Pillar 2\) capability labels, which directly control the downstream extraction difficulty\. Secondly, during the evidence decomposition stage, theRefiner Agentprocesses the annotated tables into atomic evidence\. To guarantee the mathematical and semantic rigor of this step, we implement a strictchecklist\-based verificationprotocol\. We design prompts that explicitly instruct the model to verify four critical dimensions: Value Correctness, Label Faithfulness, Schema Linkage, and Null Faithfulness\. Thirdly, to bridge the gap between discrete evidence and cohesive natural language, theWriter Agentexecutes the document generation\. We adopt a context\-aware generation paradigm where the prompt incorporates a sliding window of historical text and configurable stylistic profiles to emulate real\-world document morphological complexity Finally, in order to obtain a high\-quality, hallucination\-free corpus, theValidator Agentconducts a rigorous dual\-validation pass\. We construct prompts to evaluate Coverage Verification and Extraction Consistency\. Documents that fail these checks trigger an iterative reject\-and\-rewrite mechanism\.

### E\.1The prompt for Labeling Agent

Pillar 1 Assignment PromptGoal:Assign intra\-table \(Pillar 1\) capability labels to target cells in the entity table\.Inputs:•Input Table:\{markdown\_table\}•Non\-target Key Cols:\{non\_target\_key\_columns\}•Attribute Schema:\{attribute\_descriptions\}•Capability Definitions:\{capability\_definitions\}•Target Label Ratio:\{label\_ratio\}Instructions:1\.Assign labels that increase single\-table extraction difficulty while preserving correctness\.2\.Type\-Strategy Compatibility \(CRITICAL\):Independently analyze the semantic nature and data type of each attribute\. Only assign strategies logically/mathematically suitable for the cell’s value\.3\.A cell may have 0, 1, or multiple strategies \(default is none\)\.4\.Assign creatively but ensure text remains fluent\. Avoid over\-complicating simple facts\.5\.DO NOT assign labels to Non\-target Key Columns\.6\.For composite primary keys, use", "as separator\.7\.Label coverage: at least the target ratio of assignable cells must have non\-empty labels\.8\.Return JSON only\.Output JSON Schema: \{"assignments": \{"<<pk\_1\>\>": \{"<<attr\_1\>\>": \[\]\} \} \}Pillar 2 Assignment PromptGoal:Assign inter\-table \(Pillar 2\) capability labels to target cells in the relation table\.Inputs:•Input Table:\{markdown\_table\}•Table Schema Context:\{relation\_context\}•Attribute Schema:\{attribute\_descriptions\}•Capability Definitions:\{capability\_definitions\}•Target Label Ratio:\{label\_ratio\}Label Assignment Constraints:•IDR\_ED,RL\_O2M,RL\_MB, andRL\_MImust each appear alone\. Do NOT combine them\.•IDR\_ED,RL\_O2Mrequires that the same foreign key entity appears in≥\\geq2 rows\. Do NOT assign if unique\.Instructions:1\.Assign labels that increase inter\-table linking, topology, and structural extraction difficulty\.2\.Topology\-Strategy Compatibility \(CRITICAL\):Analyze structural distribution\. Only assign relational strategies logically suitable for the topology\.3\.Output ONLY row\-level labels per relation row\_key\. Do NOT output per\-attribute labels\.4\.A row may have 0, 1, or multiple strategies \(default is none\)\.5\.Top\-level key MUST use the relation table PK string\.6\.Composite keys format:<<pk1\>\>,<<pk2\>\>\(e\.g\.,12, 10\)\.7\.Label coverage: at least the target ratio of rows must contain non\-empty labels\.8\.Return JSON only\.Output JSON Schema: \{"assignments": \{"<<pk\_1\>\>": \[\], "<<pk\_2\>\>": \[\]\} \}

The prompt above illustrates how the Labeling Agent acts as a semantic router to assign fine\-grained intra\-table \(Pillar 1\) and inter\-table \(Pillar 2\) capability labels\. It explicitly instructs the model to analyze data types and topological contexts, ensuring that specific reasoning challenges are injected logically to control downstream extraction difficulty while adhering to target label ratios\.

### E\.2Refiner: Principle of Checklist

Given the annotated targets, the Refiner decomposes each target into atomic evidence that realizes its assigned capability labels, forming a global evidence pool for subsequent document generation\. When multiple labels are assigned, the evidence must jointly satisfy the corresponding intra\-table and inter\-table reasoning requirements\. To ensure the rigor of the synthesized evidence, we deploy an LLM\-as\-a\-verifier\[zheng2023judging\]using a strict checklist\-based protocol\. The verification assesses the generated evidence guidance across four critical dimensions:

- •Value and Relation Correctness:Verifies that the guidance accurately reflects target cell values and inter\-record relations, ensuring numerical correctness for calculated fields and allowing complete relational tuples to be unambiguously recovered\.
- •Label Faithfulness:Verifies that the guidance faithfully instantiates the assigned capability labels and rejects cases that omit or misrepresent the intended reasoning requirements\.
- •Schema Linkage:Ensures that the guidance is grounded in valid schema elements and preserves the intended structural dependencies among tables\. For relational tables, primary\- and foreign\-key references must be correctly identified and linked, so that participating entities can be unambiguously connected and the resulting evidence remains consistent with the target database schema\.
- •Data Integrity & Null Faithfulness:Ensures that the guidance contains only information supported by the target database and does not introduce values from unrelated cells or records\. It also verifies that missing, unavailable, or non\-applicable attributes remain uninstantiated, preventing the generation of unsupported values or spurious relational links\.

On failure, the verifier acts as a critic, returning a specific rationale and actionable revision suggestions \(e\.g\., “Instruct the writer to explicitly mention both the supplier and project names”\)\. This process iteratively refines the text until it passes all checks or reaches a retry limit\.

### E\.3The prompt for Writer Agent

Writer Agent Prompt\[System Role & Objective\]You are an expert Writer Agent operating within a parameterized document synthesis pipeline\.Your goal is to write ONE coherent, polished, and natural\-sounding section of a larger document while perfectly preserving structured ground\-truth facts\.\[Generation Context\]•Previous Block Context \(Tail Anchor\): \{previous\_context\}•Current Block ID: \{block\_id\} \(Index: \{block\_index\} of \{total\_blocks\}\)\[Base Parameters\]•Global Target Document Length: \{document\_length\_tokens\} tokens•Suggested Token Budget for THIS Block: \{target\_block\_tokens\} tokens•Document Style & Tone: \{document\_style\}•Section Template Hint: \{section\_template\}\[Injection Protocols\]•Hard Cases Protocol: \{hard\_cases\_protocol\}•Controlled Noise Protocol: \{noise\_protocol\}•Representation Complexity Protocol: \{complexity\_protocol\}\[Mandatory Ground Truth \(Evidence\)\]You MUST explicitly embed the following structured facts\. Do NOT drop any fact: \{facts\_with\_tags\}\[Execution Instructions\]1\.FACTUAL FIDELITY: Embed all mandatory facts without altering their meaning\.2\.TAG PRESERVATION: Keep facts wrapped in their original tags \(e\.g\.,<rX\_cY\>\)\.3\.STYLISTIC ADAPTATION: Match the requested style, tone, and template\.4\.PROTOCOL COMPLIANCE: Strictly follow any active injection protocols; ignore empty ones\.5\.LENGTH & PACING: Stay close to the\{target\_block\_tokens\}budget\.6\.SEAMLESS BRIDGING: Continue logically and smoothly from the previous context\.7\.FORMATTING: Use natural prose paragraphs\. No bullets, markdown, or JSON\.8\.OUTPUT STRUCTURE: Start exactly with the Section Title, followed by the body\.9\.FINAL OUTPUT: Return ONLY the synthesized text, without conversational filler\.

The prompt above demonstrates how the Writer Agent transforms serialized atomic evidence into cohesive, long\-form natural language documents\. It guides the model to employ a context\-aware generation paradigm, seamlessly weaving discrete facts into fluent narratives while conforming to designated stylistic profiles and mimicking the morphological complexity of real\-world corpora\.

### E\.4The prompt for Validator Agent

Verification Agent PromptYour Goal:Verify whether the generated text is faithful to the table content without fabrication\.Table Content:\{markdown\_table\}Generated Text:\{generated\_text\}Verification Checks:To ensureCell Extraction Consistency, Key values stated ingenerated\_textmust be extractable or inferrable fromTable Content\.Output Format:Respond with ONLY a single, valid JSON object:\{ "ok": true/false, "errors": \[ \{ "description": "Error description", "suggestion": "How to fix" \} \] \}FINAL INSTRUCTION:Output ONLY the valid JSON object\. If any check fails, setokto false and include all issues inerrors\.Repair Agent PromptGoal:Repair a section of text that failed verification\.Input:•Original Text:\{content\}•Errors:\{errors\}•Required Facts:\{facts\}Instructions:1\.Repair the section to fix the reported errors\.2\.Ensure all required facts remain correct\.3\.Keep the narrative flow natural\.4\.Preserve all provenance\-style tags already present in the original text\.Output Format:Return ONLY the repaired text content\. No titles, no metadata, no markdown code blocks\.

The prompt above details the rigorous dual\-validation protocol executed by the Validator Agent to guarantee the fidelity and relational consistency of the synthesized documents\. It tasks the model with strictly evaluating coverage verification and extraction consistency, ensuring no evidence is omitted or hallucinated, which inherently serves as the trigger for our iterative reject\-and\-rewrite mechanism\.

## Appendix FAuthenticity Verification

### F\.1LLM & Human Score

Table 7:Evaluation rubrics for generated documents \(1=worst, 5=best\)\.ScoreLexical RichnessLogical ConsistencyTextual CoherenceGenre Fidelity1Repetitive:
Minimal variety, robotic repetitionFragmented:
No connections, random claimsIncoherent:
Difficult to follow, random jumpsMismatch:
Incorrect genre conventions2Limited:
Simple vocabulary, narrow rangeWeak:
Loose transitions, vague reasoningPoor flow:
Jarring transitions, disconnectedWeak:
Limited and inconsistent cues3Acceptable:
Adequate variety, standard usageAcceptable:
Clear order, basic signalingAcceptable:
Some awkward transitionsPlausible:
Recognizable but generic style4Versatile:
Natural synonyms, precise terminologyCompelling:
Strong arguments, coherent progressionSmooth:
Clear progression, minor issuesAuthentic:
Consistent genre\-specific conventions5Sophisticated:
Rich nuances, professional masteryRigorous:
Flawless chain, seamless attributionSeamless:
Natural flow, effortless transitionsProfessional:
Realistic and polished genre presentationThe synthesized documents inDoc2DB\-Benchshould be fluent, logically coherent, and faithful to the conventions of real\-world domain documents rather than appearing as artificial or template\-based constructions\. To evaluate document quality and authenticity, we adopt a four\-dimensional framework combining LLM\-as\-a\-judge with human evaluation\. As shown in Table 6, the framework assesseslexical richness,logical consistency,textual coherence, andgenre fidelity, each assessed using a five\-point rubric, following a similar strategy of previous work \(e\.g\.,LLMs4Synthesis\[babaei2024llms4synthesis\]and DTBench\[dtbench2026\]\)\. We use DeepSeek\-V3\.2 as the automatic evaluator\. In addition, five graduate students with research experience in document intelligence independently assess 50 randomly sampled documents using the same rubrics\. The LLM and human evaluation results in Table[5](https://arxiv.org/html/2608.08459#S5.T5)consistently demonstrate the high linguistic quality and domain authenticity of the synthesized documents\.

### F\.2Real Case Comparison

Fig\.[10](https://arxiv.org/html/2608.08459#A6.F10)–[13](https://arxiv.org/html/2608.08459#A6.F13)provide qualitative comparisons between synthesized and real\-world documents across diverse domains, including finance, aviation, media, and restaurant menus, further demonstrating the quality and realism of our synthesis pipeline\.

![Refer to caption](https://arxiv.org/html/2608.08459v1/x9.png)Figure 10:menu case![Refer to caption](https://arxiv.org/html/2608.08459v1/x10.png)Figure 11:finance case![Refer to caption](https://arxiv.org/html/2608.08459v1/x11.png)Figure 12:airline case![Refer to caption](https://arxiv.org/html/2608.08459v1/x12.png)Figure 13:twitter case