ScheMatiQ 论文解读 | From Research Question to Structured Data

研究动机：Deep Research 不等于可分析数据

论文抓住了一个很容易被忽略的问题：很多研究不是要“读完文档写总结”，而是要把文档变成一张能继续分析的数据表。

传统流程慢

专家先设计 annotation schema，再让研究助理逐篇标注。这一步需要领域知识、语料熟悉度和大量人工时间，且会受到人类预设、遗漏变量、标注不一致的影响。

现有 LLM 工具偏检索

很多 “deep research” 系统擅长找资料和总结，但不擅长穷尽处理 corpus，也不擅长输出可编辑、可验证、可被统计建模消费的 database。

关键对象没有被定义

同一批文档，不同研究问题会导致不同的行粒度。例如同样是法院判决，问题可以要求一行表示一个 judge，也可以要求一行表示一个 court ruling。

Query-drivenHuman-in-the-loopGrounded outputs

这篇论文的 significance 在于把“结构化数据挖掘”的第一步前移：不是先假设表结构，再做 extraction；而是从研究问题和文档集合共同推断 observation unit 与 schema。对 Excel/Word/PDF 混合数据处理 agent 来说，这个思路很关键：agent 不应只回答问题，而应能构造一个被人类审计的数据资产。

论文 Figure 1：系统工作流

Figure 1：ScheMatiQ workflow。给定自然语言问题和文档集合，系统依次发现 observation unit、发现 query-guided schema、抽取 structured values，并通过 feedback/refinement 回路让研究者修正 schema 与结果。

论文 Figure 6：同一语料，不同问题，不同行粒度

Figure 6 different research questions imply different observation units

Figure 6：同一批法律文档，如果问题关注“不同总统任命的法官是否判决不同”，表格应一行一个 judge；如果问题关注“移民 injunction cases 在 court level 上 outcome 如何”，表格应一行一个 court ruling。这个图是 ScheMatiQ 最重要的概念锚点之一。

数学表示：把方法压缩成一个函数

论文原文没有把方法写成完整数学模型。这里用一个简单形式化帮助理解：输入是问题 \(q\) 和文档集合 \(D\)，输出不是答案，而是一张带证据的数据表。

输入与输出

给定自然语言研究问题 \(q\) 和文档集合 \(D=\{d_i\}_{i=1}^{N}\)，目标不是直接生成答案 \(a\)，而是生成一个 grounded database \(T\)。

\[\operatorname{ScheMatiQ}(q,D)\rightarrow\left(u,\;S,\;T,\;E\right)\]

其中 \(u\) 是 observation-unit type，\(S\) 是 schema，\(T\) 是结构化表，\(E\) 是每个 cell 的证据集合。

行粒度：Observation Unit

系统首先估计 \(u=f_{\theta}^{OU}(q,B)\)，其中 \(B\subset D\) 是一批文档。它输出 name、definition、example_names 和 reasoning。这个选择决定最终表格的行语义。

\[u=\{\text{name},\text{definition},\text{examples},\text{reasoning}\}\]

重要的是，文档和 observation unit 是多对多关系：一个 \(d_i\) 可包含多个 \(o_{ij}\)，同一个 \(o\) 也可出现在多个文档中。

Schema 发现

Schema 是一组列 \(S=\{c_1,\ldots,c_K\}\)。每个字段 \(c_k\) 不只是列名，还应包含 definition、rationale、allowed values/type。

\[c_k=\left(n_k,\;\delta_k,\;r_k,\;A_k\right)\]

Schema discovery 以 batch 为单位迭代：如果新文档包含对回答 \(q\) 有帮助但当前 \(S_t\) 缺失的信息，则产生 \(S_{t+1}=S_t\cup\Delta S_t\)。

单元格抽取与证据约束

对每个文档 \(d_i\)，先抽取 observation-unit instances \(O_i=\{o_{ij}\}\)。再对每个 \(o_{ij}\) 和字段 \(c_k\) 抽取值。

\[T[j,k]=\begin{cases}(v_{jk},e_{jk}),&e_{jk}\subset d_i\land e_{jk}\models v_{jk}\\\varnothing,&\text{no clear support}\end{cases}\]

论文明确要求 strict evidence rule：只有当文档文本清楚支持时才能填值；每个输出 cell 包含 extracted value 和 supporting evidence。

算法流程：三步走，先设计表，再填表

Observation-unit discovery

输入 \(q\) 和 sample documents，调用 backbone LLM 识别“每一行应该表示什么”。输出包含 type、definition、examples。专家可手动覆盖。

Iterative schema discovery

系统按 batch 处理文档，反复询问 LLM：这些文档是否建议添加或细化 schema？输出字段 definition、rationale、allowed values，直到没有新字段或 corpus 耗尽。

Structured data extraction

每篇文档先找所有 observation units，再一次性填充所有 schema 字段；若仍有空字段，则进行 targeted follow-up extraction。专家可修正 cell 并添加新文档。

论文 Figure 2：三个组件

Figure 2：三个系统组件。Schema discovery 是增量收敛过程；structured extraction 先找 observation units，再填字段，并对 missing fields 进行 fallback pass。

实验设计：两个真实领域，看它能不能帮专家建表

这篇论文的实验不是刷榜，而是找两个已经有人类标注数据的真实研究场景，看系统生成的表结构和人工结果能不能对上。

模型与系统设置

组件	论文设置
Observation-unit discovery	Gemini-2.5-flash
Schema discovery	Gemini-2.5-flash
Structured data extraction	Gemini-2.5-flash-lite
成本	约 1 USD / 100 documents
可替换模型	Together AI 支持的模型；系统也支持 OpenAI GPT-4、Gemini、HuggingFace Transformers 本地开源模型
系统架构	React + TypeScript + Tailwind 前端；FastAPI 后端；WebSocket 实时进度；Python core library；Supabase；Railway + Docker

可复现实验对象

论文不是用通用 benchmark 刷榜，而是选了两个已有人工标注基础的真实研究场景，用来比较 ScheMatiQ 生成的 schema 与人工 schema 是否对齐。

法律领域

89court decisions

Judgeobservation unit

问题：Trump 任命的法官是否更支持 Trump administration immigration policies？

人工基准：Klerman (2025) 标注 judge name、appointing president、decision outcome。

难点：长篇法律论证、多法官 panel、政策背景与判决倾向需要对齐到单个 judge。

计算生物学

96 / 110NESdb papers

Proteinobservation unit

问题：给定 protein sequence，能否判断是否包含 NES、强度如何、置信度如何？

人工基准：NESdb curated protein annotations。

难点：蛋白、突变体、实验条件、定位信号和证据强度容易混在同一篇文献中。

复现时最关键的是拿到原始文档、人工 schema、人工标注表，以及专家对齐规则。当前 GitHub 更适合复现系统流程；论文精确数字还依赖这些实验材料。

论文 Figure 7：简化 prompt 截图

Figure 7a：Observation unit discovery 的简化 prompt，强调 one row equals one answer。

Figure 7b：Schema discovery 的简化 prompt，要求只添加 essential missing columns。

Appendix A 给出的完整 Schema

法律领域 26 个字段

法官与法院信息

Judge NamesJudges On PanelAppointing Presidents On PanelAppointing Parties On PanelCourt NameCourt LevelDecision Date

政策与行政背景

Immigration Policy At IssueAdministration At IssuePolicy Instrument TypePolicy Instrument PurposePolicy Instrument DatePolicy Instrument Issuing AuthorityPolicy Instrument Target Group

诉讼与主体类型

Case Subject MatterCase Proceeding TypePlaintiff Entity TypesPlaintiff Immigration Status TypeDefendant Entity TypesLegal Challenge Grounds

判决结果与命令

Judge Decision OutcomeJudge Decision TendencyCourt Decision Legal BasisInjunction ScopeExecutive Order NameExecutive Order Number

计算生物学 26 个字段

Protein / NES 基本识别

Protein NameSource OrganismNES IdentifierIdentified NES SequenceNES Residue CoordinatesNES Motif Count

NES 状态、强度与证据

NES Presence StatusNES Strength CharacterizationNES Determination EvidenceNES Binding AffinityNES Functional ImpactReclassification Status

结构与机制

Export Mechanism TypeExport ReceptorNES Regulation MechanismNES Structural DomainNES Critical ResiduesNES Consensus ConformityNES Conservation Status

调控、定位与转移性

NES Activation ConditionsRegulatory Interacting ProteinNES Masking AgentCompeting Localization SignalsObserved Subcellular LocalizationNES OriginNES Transferability

Prompt 设计：项目里到底有哪些 prompt

论文正文只展示了简化 prompt，但 GitHub 里的实现更完整。可以把它们理解成两组：第一组负责“设计表”，第二组负责“按表填值”。

主链路

1. 发现一行是什么2. 发现有哪些列3. 找文档里的具体行4. 给每一行填字段值

对应代码链路是 SYSTEM_PROMPT_OBSERVATION_UNIT → SYSTEM_PROMPT_STANDARD → SYSTEM_PROMPT_UNIT_IDENTIFICATION → SYSTEM_PROMPT_VAL_WITH_UNIT 或 SYSTEM_PROMPT_VAL。

Schema discovery 相关 prompt

Prompt	位置	作用	关键约束
SYSTEM_PROMPT_OBSERVATION_UNIT	core/prompts.py	根据 query + sample passages 判断表格每一行代表什么。	One Row = One Answer to the Query；name 必须 1-3 个词；experiments、variants、measurements 通常不是行。
USER_PROMPT_TMPL_OBSERVATION_UNIT	core/prompts.py	把 query 和 joined_passages 填进 observation unit prompt。	提醒模型同一实体的实验和变体不要拆成多行。
SYSTEM_PROMPT_STANDARD	core/prompts.py	标准 schema discovery：同时使用 query 和 documents 发现字段。	只添加真正缺失、有价值、可抽取、对多数文档有用、且属于 observation unit 属性的字段。
USER_PROMPT_TMPL_STANDARD	core/prompts.py	把研究问题和当前 passages 批次交给 schema prompt。	后续会追加 draft schema 和 observation unit context。
SYSTEM_PROMPT_DOCUMENT_ONLY	core/prompts.py	只看文档、不看 query 的消融模式。	默认不加列；只保留通用、跨文档适用的字段。
SYSTEM_PROMPT_QUERY_ONLY	core/prompts.py	只看 query、不看 documents 的规划模式。	生成回答问题所需的 3-10 个计划字段，之后由文档再细化。
DRAFT_SCHEMA_TMPL	core/prompts.py	把已有 schema 放回 prompt，支持迭代补列。	先 review 已有字段，只 append 真正缺失的信息。
OBSERVATION_UNIT_CONTEXT_TMPL	core/prompts.py	在 schema discovery 时告诉模型“一行是什么”。	每个字段都应该是该 observation unit 的属性，避免 document-level 字段混入。

Value extraction 相关 prompt

Prompt	位置	作用	关键约束
SYSTEM_PROMPT_VAL	value_extraction/config/prompts.py	根据 requested columns 从文档中抽取具体字段值。	只输出 JSON；找不到就省略字段；必须带 supporting excerpts；禁止 unknown/N/A。
SYSTEM_PROMPT_VAL_STRICT	value_extraction/config/prompts.py	更严格的字段抽取模式。	只有直接被文本支持且能给 excerpt 的值才输出。
SYSTEM_PROMPT_VAL_REEXTRACT	value_extraction/config/prompts.py	第一次没抽到某些字段时二次查找。	重点检查 tables、figures、captions、footnotes、appendices、synonyms 和 implicit expressions。
SYSTEM_PROMPT_UNIT_IDENTIFICATION	value_extraction/config/prompts.py	在单篇文档中列出具体 observation unit instances。	这不是值抽取；用 Subject Test 排除工具、方法、control、baseline；倾向 consolidate variants。
USER_PROMPT_TMPL_UNIT_IDENTIFICATION	value_extraction/config/prompts.py	把 query、unit definition 和 document text 交给 unit identification prompt。	输出具体 unit_name、confidence，可选 relevant_passages。
SYSTEM_PROMPT_VAL_WITH_UNIT	value_extraction/config/prompts.py	针对某一个具体 unit 抽字段值。	只抽当前 unit 的值，不能把其他 entities 的数据串进来。
PromptBuilder	value_extraction/utils/prompt_builder.py	不是 prompt 原文，而是组装 value extraction messages。	把 query、paper title、paper text、columns 组织进 XML-like 标签；遇到 Markdown table 会提醒模型看表头和单元格。

最值得注意的设计

Schema prompt 不是简单“从文档找字段”。它先做 research question decomposition：比较轴、outcome、independent variables、confounders、领域专家会关心的概念，都应该优先成为字段候选。

最强的防幻觉约束

Value extraction prompt 明确要求：没有证据就省略字段，不允许输出 unknown、N/A 或 not provided；每个值都要有 supporting excerpt。这是它把自然语言文档转成可信表格的关键。

实验结果与核心结论

Schema 覆盖：Figure 4

专家先把人工 schema 和 ScheMatiQ schema 对齐，再评估各自独有字段。论文结论：两域中 ScheMatiQ 都只漏掉两个宽泛 miscellaneous 字段，同时提出大量专家认为有用的新字段。

\[\begin{array}{lccc}\text{Domain}&\text{ScheMatiQ-only}&\text{Mutual}&\text{Manual-only}\\\hline\text{Legal}&61\%&31\%&8\%\\\text{Computational Biology}&59\%&32\%&9\%\end{array}\]

新增字段 relevance rating：计算生物学平均 \(4.2/5\)，法律领域平均 \(3.6/5\)。法律领域有用新增字段包括 court decision legal basis、injunction scope、administration at issue。

输入消融：Figure 5

作者比较三种输入条件：只给 research question、只给 documents、同时给两者。结论是 question-only 产生高层通用字段，document-only 产生不一定对齐研究目标的宽泛字段，而 \(q+D\) 才产生 context-specific 字段。

\[S(q,D)\neq S(q,\varnothing)\cup S(\varnothing,D)\]

Figure 5 中没有 three-way overlap，这被作者解释为：有意义的 schema 不是由问题或文档单独决定，而是由二者交互决定。

Observation unit recall

这里评估的是系统能不能把“每一行应该出现的对象”找全。论文报告：计算生物学中识别出 \(87\%\) proteins；法律领域识别出 \(74\%\) judges；测试样例上 precision 为 \(100\%\)。

领域	Observation unit	Recall	Precision
计算生物学	Protein	87%	100%
法律	Judge	74%	100%

错误主要来自高密度文档：一篇文档里包含很多 proteins 或 judges 时，系统更容易漏掉对象；如果文档只包含单个核心对象，recall 接近完美。

现象	含义
Precision 高	模型很少凭空造不存在的 observation unit。
Recall 仍有缺口	真正风险是漏抽，而不是乱抽。
高密度文档更难	需要 entity enumeration、分块抽取、去重和二次校验。

对 Excel/Word/PDF agent 的启发是：如果一个文件里有很多项目、负责人、截止日期或合同条款，不能只做一次整体抽取，应该先枚举对象，再逐对象填字段。

论文 Figure 3/4/5

Figure 3：Web interface。用户输入问题与文档，检查并修正 observation unit 与 schema，再查看带证据的 extracted table。

Figure 4：Schema-field coverage。法律领域 61/31/8，计算生物学 59/32/9。

Figure 5：Query-only、documents-only、combined 的 schema-field overlap。

四个核心 insight

Insight	解释	对数据处理 agent 的含义
行粒度比字段更先验	先决定 row 是 judge、case、protein，后面的 schema 才有意义。	Excel agent 应先识别“每行代表什么”，再做字段抽取或透视。
Schema 是研究问题驱动的	同一语料可导出不同数据库。	不要把“自动 schema discovery”做成纯文档摘要；必须显式输入任务目标。
证据 grounding 是可信度基础	每个 cell 都要有 supporting evidence。	输出表格应带 cell-level provenance，而不是只有最终值。
人机协同不是 UI 装饰	专家能改 observation unit、schema、cell，是系统可靠性的组成部分。	复杂领域数据挖掘中，human approval 应是 pipeline 状态，而不是事后评论。

复现清单：重做这篇工作需要什么

论文给的信息足以复现系统思想，但不足以完全复现实验数字，因为完整 prompt、代码版本、Gemini API 行为、抽样测试集和专家对齐细节需要从 GitHub 或作者资源补齐。

数据准备

法律：收集 89 个 immigration injunction court decisions。
计算生物学：收集 NESdb references；确认使用 96 还是 110 篇。
每篇文档保留原文、段落 ID、页码或 passage span。

Pipeline 参数

选择 batch size \(m\)，构造 \(B_t=\{d_{tm},\ldots,d_{tm+m-1}\}\)。
记录 temperature、top-p、max tokens、model snapshot。
缓存每次 LLM call 的输入、输出和版本。

评测协议

专家对齐 manual schema 与 ScheMatiQ schema。
统计 manual-only、mutual、ScheMatiQ-only 字段比例。
对新增字段打 relevance score。
抽样计算 observation unit precision/recall。

我会额外补的指标

\[\text{CellAccuracy}=\frac{1}{|\Omega|}\sum_{(j,k)\in\Omega}\mathbf{1}\left[\hat v_{jk}=v_{jk}^{gold}\land \hat e_{jk}\text{ supports }\hat v_{jk}\right]\]

论文更强调 schema 层评估，但如果目标是做可靠的数据挖掘 agent，必须进一步报告 cell-level value accuracy、evidence precision、missing-value calibration、跨运行稳定性、专家修正成本，以及高密度文档下的 recall 曲线。

这篇工作很聪明，问题意识也非常对。但它更像一个强系统 paper / vision paper，而不是一个评测闭环非常硬的 benchmark paper。

问题定义：9/10系统设计：8/10实验严谨性：6/10可复现性：6/10研究启发：9/10

优势

抓住了“从问题到数据结构”的核心痛点，比单纯 information extraction 更上游。
Observation unit 的显式建模非常关键，这是很多 document-to-table 系统忽略的。
Schema discovery 同时条件化于 query 与 documents，避免了通用 schema 和纯语料 schema 的错位。
UI、人机协同和 evidence grounding 是系统级可靠性的真实组成部分，不是 demo 外壳。

不足

实验规模偏小，两个领域很好但还不足以证明“跨学科泛化”。
主要结果是 schema coverage 与专家 relevance，缺少系统性的 cell-level accuracy。
闭源 Gemini API 带来复现不稳定，论文也承认固定参数仍可能有小变化。
Appendix 中计算生物学文档数与正文存在 96/110 的口径不一致，需要澄清。
没有和 DocETL、SciDaSynth、LLMs4SchemaDiscovery、Text-to-table 等系统做强 end-to-end baseline 对比。

如果我是 reviewer，我会要求作者补三个东西：第一，给出字段级和单元格级的 error taxonomy；第二，在至少 5 个领域做 leave-domain-out 测试；第三，把 human-in-the-loop 的收益量化成“专家时间节省”和“修正前后准确率提升”。这样这篇工作会从很好的系统 demo，变成真正坚实的数据挖掘方法论文。

One More Thing：这篇论文对 Excel/Word Agent 的启发

不要直接问文件答案，先问数据结构

如果要做泛化数据处理 agent，我会把 ScheMatiQ 的第一步扩展成 file-to-research-table planning：先确定 row unit，再确定列，再确定每列的证据来源、类型、单位和校验规则。

面向 Excel/Word/PDF 的统一 IR

\[\mathcal{I}(x)=\left(\text{blocks},\text{tables},\text{entities},\text{relations},\text{provenance}\right)\]

Excel 的 sheet/range/formula，Word 的 heading/table/comment，PDF 的 page/layout/span，都应进入统一中间表示 \(\mathcal{I}(x)\)。LLM 在 \(\mathcal{I}\) 上做 schema planning，确定性工具负责计算、抽取、校验和写回。

一个更强版本的 ScheMatiQ 应该长这样

模块	增强方向
Schema discovery	加入字段去重、层级 schema、单位标准化、field dependency graph。
Extraction	对每个 cell 输出 value、evidence、confidence、validator result、human edit history。
Reliability	用 self-consistency、retrieval verification、typed constraints 和 deterministic recalculation 共同校验。
Privacy	在 LLM 前做本地 PII 检测与 reversible masking，输出日志也必须脱敏。
Evaluation	构造跨文件类型 benchmark：Excel financial models、Word contracts、PDF papers、CSV operational logs。