把 10 篇长文档，压成一张可比较、可约束、可复现的结构化表
这篇论文真正要解决的，不是“让 LLM 再抽点信息”，而是把多文档比较分析这件事， 从单文生成升级成 schema-first 的结构化流程： 先决定表该长什么样，再决定每个格子该填什么。
先用白话看懂：这篇文章到底在做什么
如果你不想一上来就看公式、benchmark 和大表格，那只看这一节就够了。 这篇文章做的事，可以理解成：让 AI 先决定表格该有哪些列，再去 10 篇长文档里找值填进去。
现实里我们经常不是看 1 篇文档，而是要同时看 10 篇，最后整理成一张方便比较的表。 比如 10 篇招标公告、10 篇财报、10 份判决书。
以前很多方法让模型直接从文档生成整张表。这样很容易表头乱起名、字段不统一、或者漏掉重要信息。
不要直接填表。先判断领域，再先设计“这张表应该长什么样”，也就是先定 schema，最后再去逐篇抽值。
特别具体的例子：10 篇招标公告怎么变成 1 张表
下面这 5 步基本就是这篇论文最核心的工作流。把它理解了，后面的 DDST、JSON Schema、实验表格都会顺很多。
AI 先判断这 10 篇是不是政府采购公告，而不是财报或法律文书。
比如项目名称、采购单位、预算金额、开标时间、代理机构、联系人。
把“采购人”“采购单位”“招标人”这类近义表达统一成同一列。
对每一篇文档，去抽预算、时间、地点、联系人等字段，找不到就留空。
每篇公告变成一行，这样人就能一眼比较 10 个项目的关键差异。
| 项目名称 | 采购单位 | 预算金额 | 开标时间 | 代理机构 |
|---|---|---|---|---|
| 宜宾自然灾害应急能力提升项目 | 某采购单位 | 6040613.00 | 2025/01/21 10:00 | 某招标公司 |
| 某医院液氮供应系统采购 | 某医院 | 2200000.00 | 2025/01/20 10:30 | 某国际招标公司 |
| 某学校供餐服务采购 | 某小学 | null | 2025/01/25 09:00 | 某咨询公司 |
因为 AI 不是“边想列名边填表”，而是先把表格结构定下来。这样每一列的含义更稳定，最后做横向比较时不会乱。
这篇文章最重要的观点就是：先定表结构，再抽每篇文档里的值，而不是一上来就让模型直接生成整张表。
研究动机：旧任务太“平”，现实问题太“立体”
论文的出发点很直接：已有 Text-to-Table 大多只处理单文档，而且很多数据集来自 table-to-text 反向构造， 文本和表之间几乎是同构的。现实里真正难的是：多篇长文档、跨段落聚合、跨文档比较、领域特定字段、 以及对表头和取值约束的控制。
- 大量数据集来自 table-to-text 任务的逆向变体。
- 文本与表几乎一一映射，缺乏真实业务文档的噪声与冗余。
- 模型更像在做“重写”而非“综合分析”。
- 真实场景需要识别多篇文档中的共性、差异、冲突与缺失。
- 像财报、招标公告、判决文书、药品说明书，本质都不是单文概括。
- 结构化表格的意义在于“横向可比”，不是单篇摘要。
- 零样本 LLM 容易多生字段，也容易把字段名写得很散。
- 表头一旦漂移，后续单元格抽取就会整体错位。
- 所以本文把 JSON Schema 提到中间层，专门管结构。
旧范式：Text-to-Table
单文档，重点是从一段文本恢复一个结构化表。本文范式：Docs-to-Table
多文档，重点是比较、综合、抽象 schema，再填表。这项工作的意义，在于它把“多文档综合表格生成”从已有任务边缘地带拉出来，单独立题。 这对于金融对比、政策比较、法务检索、医学整理都更贴近真实使用方式。
本文其实在说一个更大的命题：当任务目标是结构化知识而不是自由文本时， 中间表示设计常常比“换一个更大的模型”更决定上限。
任务定义、数学表示与等价建模
论文正文给出了输入、输出与文档相似度约束；但没有把完整的 DDST 写成显式方程。 所以下面我会把 论文原始定义 和 便于复现的等价形式化 分开写。
这一节其实只是在把上面的白话再说得严格一点。输入是一组相关文档，输出是一张表。 论文额外加了一个限制：这些文档之间得“有点像”，不能完全不相关地硬拼。
公式不是这篇文章最难懂的地方，它们只是把“输入是什么、输出是什么、文档之间怎么判定相关”写清楚。 真正的方法核心还是后面的 DDST 流水线。
输入是一组相关文档 D = {d1, d2, ..., dn}， 每个 di 是非结构化或半结构化文本。
输出是一张结构化表 T， 其中行对应文档实例，列对应动态推断出的属性。
这里 rj 是第 j 行， vjk 是属性 ck 的取值。
为避免拿一堆完全无关的文档硬拼成表，论文先引入 TF-IDF + cosine similarity 约束：
当 sim_cos(di, dj) ≥ τcos 时， 文档才会被纳入分析集合。
论文没有把 DDST 的三步写成统一数学系统，但从 Figure 3、Section 4 和 appendix prompt， 可以整理出下面的可复现实验表达。
其中 g_gate 是领域门控， pz 是领域 prompt， St 是滑窗生成的局部 schema， S* 是最终 schema， Y 是列优先 JSON 表格。
- 论文 appendix 明确说实际实现里“每 4 篇文章生成一个 schema”，所以可以把窗口大小记成 w = 4。
- 正文只说 step size 小于 window size，没有给具体 overlap，所以 步长未披露。
- schema merge 的真实实现也没有算法细节，只能从 prompt 看出其逻辑接近“对齐后取公共字段”。
Step 1 · 文档相似度计算
Figure 3 明确有这一步，正文定义见 2.3。- 对文档做 TF-IDF 表示。
- 计算 cosine similarity。
- 筛掉关联度太低的文档组合。
Step 2 · Domain Gating
随机选 2 篇文档，判断领域并产出领域 prompt。- 领域标签 finance / government / law / medicine
- 生成 domain characteristics
- 生成 article topic
Step 3 · Schema 生成与集成
以 4 文档滑窗生成 JSON Schema，再整合成最终 schema。- 字段名、类型、描述、约束一起生成。
- 倾向保留各 schema 公共字段。
- 字段名要求简洁，且使用中文。
Step 4 · 结构化表生成
严格按 schema 抽值，输出列优先 JSON。- 每个字段对应 10 个值。
- 数值字段强调单位一致。
- 找不到时设为 null。
Input: 10 related documents D 1. Filter or verify document coherence with TF-IDF + cosine similarity 2. Randomly sample 2 docs from D 3. Use LLM to infer domain z and domain prompt p_z 4. Slide over D with window size 4 to generate local schemas S_1 ... S_T 5. Merge local schemas into a final schema S* 6. Use S* to fill a column-first JSON table Y Output: structured table Y
- 把结构推断和内容填充拆开，减少直接 end-to-end 生成的漂移。
- 用领域门控给 schema 生成提供“归纳偏置”。
- 用 JSON Schema 作为硬约束中间层，尤其适合头部字段一致性控制。
数据集：FGLM 是这篇工作最硬的地基
FGLM 是本文最重要的资产之一。它不是把短文本和小表格拼起来，而是把四个真实业务域的长文档 拉进统一任务范式里，让模型必须做跨文档理解、字段抽象与约束生成。
302 条样本，来自上市公司分析报告，关心 stock code、rating、revenue forecast、EPS、PE 等。
500 条样本，来自政府采购公告，关心 project、budget、agency、contact、bid opening 等。
500 条样本，来自公开裁判文书，关心 case no.、court、legal basis、parties、outcome 等。
500 条样本，来自药品说明书，关心 active ingredient、dosage form、route、specification、approval 等。
Finance
上市公司研报- Stock Code
- Rating / Rating Change
- EPS 2024 / 2025
- PE / Industry
Government
公开采购公告- Project Name
- Budget
- Procurement Unit
- Agency / Contact
Law
公共裁判文书- Case No.
- Court
- Case Name
- Legal Basis
Medicine
药品说明书- Drug Name
- Active Ingredient
- Dosage Form
- Route / Specification
- 每条样本包含 10 篇文档，对应 1 张总结表。
- 短文本被过滤，保留长文本，stop words 和 POS tags 被清洗，只保留核心内容，论文称约保留 88% 内容。
- 表中那些在文档中找不到的字段会被删掉，保证 gold table 与 source 对齐。
- 法律和政府数据中的个人信息用 NER 随机替换，论文在 ethics statement 中专门提到这一点。
FGLM 的难点不只是样本数，而是 平均文档长度 9734.48。 这比传统 Text-to-Table 基准长一个量级。也就是说，模型面对的不是“几段摘要”，而是接近业务原文。
四个领域的 appendix 样例浏览器
下方内容都来自论文 appendix 的真实样例或样例表，图片本身如果没有直接重嵌，就给出对应 Figure 与 PDF 页码，方便你回原文核对。
文本是上市公司研报，字段既有实体信息，也有分析师观点与未来预测。结构最难的部分是把 narrative commentary 压缩成统一字段。
节选自 Figure 5 / Figure 6（按论文样例整理）： Stock Code: 600998 Company: Jiuzhou Tong Report Title: first medical REIT approved; asset structure optimization Rating: Buy / Maintained Broker: China Galaxy Securities EPS 2024: 0.44 PE 2024: 11.86 EPS 2025: 0.51 PE 2025: 10.27 Industry: Healthcare Distribution Stock Code: 1308 Company: Konka Tech Rating: Hold / Initiated EPS 2024: 1.25 PE 2024: 22 EPS 2025: 1.64 PE 2025: 17
Financial analysis reports of listed companies
打开 PDF 第 15 页Financial Table
打开 PDF 第 16 页政府采购公告的字段很细，且很多是时间、地址、联系方式、招标地点等规范化信息，非常适合测 schema 质量。
节选自 Figure 13： "Project Name": [ "Fushun County 2024 Poverty Prevention Insurance Service Procurement Project", "Public Security Network Risk Perception Equipment", "2025 Information Operation and Maintenance Service Procurement" ], "Procurement Unit": [ "Fushun County Rural Revitalization Center", "Mianyang Public Security Bureau", "Sichuan Province Qionglai Prison" ], "Announcement Time": [ "2024/12/27 19:24", "2024/12/27 18:48", "2024/12/27 18:17" ], "Agency Name": [ "Sichuan Huilong Bidding Consulting Co., Ltd.", "Mianyang Municipal Government Procurement Center", "Sichuan Hongjie Bidding Agency Co., Ltd." ]
Government open procurement announcements
打开 PDF 第 23 页Government Table Json
打开 PDF 第 24 页法律文书字段名看似稳定，但正文极长且叙述冗余多；真正难的是从长叙述里找到统一字段，并避免把细节误当成新表头。
节选自 Figure 15： "Case No.": [ "(2021) Liao0404 Minchu 2915", "(2021) Liao0124 Minte 261", "(2021) Qing0105 Zhi 2127" ], "Case Name": [ "Civil Ruling ... Property Service Contract ...", "Civil ruling on the special procedure for confirming the validity ...", "Execution notice on the execution of the loan contract dispute ..." ], "Court": [ "Fushun Wanghua District People's Court", "Faku County People's Court of Liaoning Province", "Chengbei District People's Court of Xining City" ]
Legal public archives data
打开 PDF 第 25 页Law Table Json
打开 PDF 第 26 页药品说明书字段最规整，但也最容易因为命名细节、单位和剂型差异而出错。这里 schema 的 type constraint 特别重要。
节选自 Figure 17： "Active ingredients": [ "Lenalidomide", "Metformin Hydrochloride", "Candesartan Cilexetil" ], "Drug name": [ "Lenalidomide Capsules", "Metformin Hydrochloride Tablets", "Candesartan Cilexetil Tablets" ], "Dosage Form": [ "Capsules", "Tablets", "Tablets" ], "Route of Administration": [ "Oral", "Oral", "Oral" ]
Medical instructions
打开 PDF 第 27 页Medical Table Json
打开 PDF 第 28 页方法：Docs-Domain-Schema-Table 的关键不是“多一步”，而是“先立规矩”
DDST 的精髓在于，它不让模型一上来就从 10 篇文档端到端吐出整表，而是先判断领域、再生成 schema、 再做表填充。这个拆分非常符合结构化抽取任务的真实误差传递方式。
DDST 就像一个做表格很认真的助理：它不会直接把 10 篇文档胡乱总结成一张表，而是先问清楚“我要做哪种表、每一列叫什么、每一列该填什么类型的值”。
因为一旦列名没定好，后面所有单元格都会跟着乱。对于这类任务，很多错误其实不是“没看懂文章”，而是“先把表头定错了”。
随机从 10 篇里选 2 篇，让 LLM 判断领域，并生成面向后续 schema 生成的 domain prompt。 论文明确说这个设计灵感来自 Mixture-of-Experts 风格的 gate。
用滑窗切文档，为每个窗口生成局部 JSON Schema。Schema 不只包含字段名， 还包含类型、描述与约束。然后再把多份 schema 统一成最终 schema。
最终按统一 schema 去抽值。输出是 column-first JSON，也就是每个字段对应一个长度为 10 的数组。 这个格式天然接近表格列。
- 如果直接 end-to-end 抽表，表头和表格内容会一起漂移，很难知道问题出在哪一步。
- 一旦先固定 schema，后续 filling 就更像 constrained extraction，而不是自由生成。
- 对于多文档任务，真正难的是决定“哪些维度值得比较”，这恰好是 schema 层的问题。
- 任何前置 schema 错误都会级联影响 filling。
- 随机选 2 篇做门控，可能造成高方差；论文没有给 variance 或多次运行稳定性。
- 领域门控对跨领域混合样本是否鲁棒，论文没有展开。
Prompt 链条：appendix 给出的最重要复现材料
论文把 prompt 放到了 appendix，这其实比很多论文更良心。下面是最关键的三段半：领域判别、schema 生成、schema 集成、按 schema 填表。
Please analyze the following two articles
{articles}
Please complete the following tasks:
1. Determine the field to which the article belongs
(financial / medical / legal / government / ...)
2. Based on the content of the article, generate an expert prompt suitable
for the field for subsequent JSON Schema generation
Return JSON:
{
"domain": "Field English name",
"domain_prompt": "You are an expert in the {domain} field ..."
}
{domain_prompt}
Article content:
{articles}
Please design a suitable JSON Schema to extract the key information.
Requirements:
1. Fields should be common to all articles in the window
2. Generate descriptions for each field
3. Each attribute is a first-level title
4. Attribute names should be concise and use Chinese
Return JSON only.
Please analyze multiple schemas in the following {domain} domain:
{schemas}
Please design a final schema with the following requirements:
1. Keep common attributes contained in each schema
2. Each attribute is a first-level title
3. Ensure unified field names
4. Provide a clear description for each attribute
5. Make the final schema concise and useful for observing similarities and differences
Return the JSON object directly.
1. The returned field name must be in Chinese. 2. Strictly abide by the field type defined in the Schema: - string: if it exceeds 20 characters, set to null - number: extract numbers with correct precision - array: extract in array format 3. Ensure semantic correctness. 4. For numeric fields, keep units consistent. 5. Each field corresponds to 10 values from 10 articles. Return valid JSON only.
填表 prompt 里写了：string type 超过 20 个字符就设为 null。 这会极大影响政府、法律领域的长字段召回。也就是说，论文的方法本身带有强压缩 bias。
Table 3 里 DDSHT 很差，论文解释是：生成的 header 往往是抽象压缩过的词，和原文 chunk 不一定直接 lexical match。 这非常合理，也说明“检索”不是所有结构化任务的通用良药。
实验设计：模型分组、评价指标、AUTO-QA 与复现清单
实验部分的价值在于它不只比一个模型，而是把 fine-tuned、zero-shot、CoT、thinking LLM、thinking + DDST 全摆在一起。 但同样明显的是，真正能复现到位的细节并没有全部给出。
- 现有 fine-tuned 模型、SOTA LLM、thinking LLM 以及 DDST 结合后在 FGLM 上表现如何？
- DDST 的提升来自哪里，各组件贡献如何？
- DDST 相比其它方法，在不同领域和不同评价维度上如何？
- Fine-tune：Mistral-7B-Instruct-v0.3、TableLLM-7B、StructLM-7B
- Zero-shot：Qwen2.5-72B、DeepSeekV3、GPT-4o、Llama-3.3-70B、Qwen3-32B
- Zero-shot + DDST：同一批基础模型叠加 DDST
- Thinking LLMs：DeepSeek-r1、o4-mini、Grok3、Gemini 2.5 Pro
- Thinking + DDST：上述 thinking 模型再接 DDST
看模型能否抽出核心实体或主对象。论文同时报告 Exact Match、ChrF、BERTScore 三种版本。
看生成的表头是不是准确、稳定、可比较。对 Docs2Table 来说，这是最关键的一层结构信号。
看字段值填得准不准。这个指标最接近“最终整张表到底能不能用”。
论文额外定义了两个头部指标： EHR 是生成表头里“覆盖率超过 80%”的比例， ERROR 是“覆盖率低于 20%”的比例。 前者衡量额外但有用的字段，后者衡量明显失败的字段。
论文把 AUTO-QA 扩展到 5 个维度：coverage、formatting、reasoning、comprehension、hallucination control。 这里用的是 GPT-4.1 来生成 QA，并比较 GPT-4o、GPT-4o(T3)、GPT-4o(DDST)。
- 每条样本 10 篇文档。
- 领域共 4 类。
- schema 生成实践里窗口大小为 4。
- 领域门控随机选 2 篇文档。
- 字段名要求中文。
- 按 schema 填表时，字符串超过 20 字符可设为 null。
- AUTO-QA 使用 GPT-4.1，并在四个领域上各评 12 个 QA pair。
- 相似度阈值 τcos 的数值。
- 滑窗步长 / overlap。
- 各 API 的 temperature、top-p、max tokens、seed。
- train / val / test 的具体划分数量。
- schema merge 的程序化规则，而不只是 prompt 文字。
- 不同模型运行成本、时延与失败重试策略。
Figures 7 / 8 / 9 / 10 / 11: click to expand
These figures are prompt templates from the paper. Expand this section to view the original figure images directly.
实验结果与核心结论：DDST 不是全能，但它确实稳稳推高了上限
如果把结果压缩成一句话：DDST 对 header 与 cell 的提升尤其明显， 尤其是在推理能力强的模型上；但它并不保证 first-column 最优，也不总能把 error rate 压到最低。
- `Fine-Tune` = Mistral / TableLLM / StructLM
- `SOTA` = GPT-4o / Qwen / DeepSeekV3 / Llama
- `Thinking` = Grok3 / DeepSeek-r1 / Gemini / o4-mini
- `(DDST)` = 接上 DDST 后的版本
Fine-tuned 小模型在 FGLM 上很吃力。Mistral-7B-Instruct-v0.3 已是该组最好，但 ERROR 仍在 6.54% 左右。
CoT 对非 thinking LLM 有稳定但不夸张的帮助，First Column Exact 一般涨 1%–2%，Header ChrF 涨 0.5%–1%。
DDST 最大的提升集中在 header 与 data cell，而不是总能把第一列实体抽取得最好。
Table 2（LaTeX 重排）· Fine-tuned + Zero-shot
Table 2（LaTeX 重排）· DDST 变体 + Thinking 模型
DDST 对零样本模型的提升最明显地体现在 header 与 data cell 上。 论文特别点名 GPT-4o：Data Cell F1 (BS) 从 28.34 提升到 46.97，这是非常实打实的跃升。
thinking 模型本来就强，DDST 更像是给它们加了一层结构控制。 最亮眼的是 Grok3 + DDST 在 Data Cell BS 上到 70.34， 而 o4-mini + DDST 把 ERROR 压到了 1.21。
Table 3（LaTeX 重排）· Ablation
Table 4（LaTeX 重排）· AUTO-QA 五维比较
我的评论：这篇工作挺聪明，但也还远没到“闭眼复现、放心部署”
如果我是 reviewer，我会给这篇文章一个偏正面的评价，但不会轻易给高分。它抓住了一个真问题，也给了一个很合理的中间层方案； 可与此同时，实验协议与系统细节还不够“硬”，一些地方更像 prompt engineering paper，而不是 fully specified system paper。
优点 1 · 任务定义真有价值
把多文档到表格的生成任务独立出来，这个问题设定本身就值得。很多实际场景根本不是 summary，而是 comparative table construction。
优点 2 · schema-first 的 bias 很对
把 JSON Schema 放进中间层是本文最关键的设计。对结构化任务来说，这比单纯要求“请一步一步思考”有更强的结构收益。
优点 3 · 结果不是只在一个模型上成立
从 GPT-4o 到 Qwen，再到 thinking LLM，DDST 的提升模式大体一致，说明它不是某个 API prompt 的偶然特例。
优点 4 · appendix 给 prompt，诚意不错
虽然还没到完全可复现，但至少把 prompt 主链条贴出来了，这已经比很多“只给图不贴字”的论文强不少。
不足 1 · 关键超参与运行协议缺失
没有给相似度阈值、滑窗步长、API 参数、随机种子、重试策略。对于一个高度依赖 prompt 与 pipeline 的系统，这些不是细枝末节。
不足 2 · gate 只看随机两篇，太脆
如果 10 篇文档中恰好有边缘样本，随机 2 篇做领域判别可能会把整个 pipeline 带歪。论文没有分析这件事的方差与鲁棒性。
不足 3 · AUTO-QA 评价仍有 LLM judge 偏置
用 GPT-4.1 生成并评价 QA，能帮助做细粒度比较，但也会引入 judge bias。尤其是 formatting / comprehension 这类维度，很难完全客观。
不足 4 · prompt 里的人为规则可能伤 recall
“string 超过 20 字符设为 null” 这种规则虽然能降噪，却可能系统性牺牲法律、政府场景的长字段抽取。这个 trade-off 没被量化。
- 把 gate 从“随机两篇”升级成“全局 doc-set classifier”或可学习 gate。
- 把 schema merge 从纯 prompt 变成半符号算法：字段归一、类型统一、冲突消解、coverage 统计。
- 填表阶段接一个 JSON Schema validator，做自动修复而不是只靠 prompt self-control。
- 把 RAG 从 lexical retrieval 改成 field-semantic retrieval，检索对象是“字段语义”而不是原始词面。
- 你们的方法在 few-shot 下怎么样？论文自己也承认没做。
- 在成本相同的条件下，DDST 相对直接 CoT 到底值不值？缺少 cost-performance 分析。
- 如果释放完整代码与 splits，这个方法的增益还能否稳定复现？
这篇论文真正值得带走的，不只是 DDST，而是“schema is the bottleneck”
读完这篇 paper，我最想强调的不是“DDST 比 T3 强多少”，而是一个更普遍的 insight： 当任务是把复杂文本变成结构化资产时，最稀缺的并不是抽取能力，而是 结构选择能力。
多文档结构化抽取的关键问题不是“模型看没看懂句子”，而是“模型知不知道哪些维度值得放进一张对比表”。
在这类任务里，retrieval 可能不如 schema induction 关键。因为表头往往是抽象概念，不一定是原文里直接出现的短语。
thinking LLM 的价值也被这篇文章重新定义了：不是让它写更长的思维链，而是让它在有结构约束时把 reasoning 用在“守规则”上。
最后的复现建议
如果你真的要复现，最可行的切入点不是先追求论文表 2 的数值，而是先复现四阶段链路： domain gate → local schema → schema merge → table filling。等这四步都能稳定产出，再去调阈值、步长、模型和 validator。
最值得补的实验是：few-shot、成本分析、跨运行方差、以及人工评估 schema 实用性。