FactReview：基于证据的同行评审，融合文献定位与执行式声明验证 FactReview: Evidence-Grounded Reviews with Literature Positioning and Execution-Based Claim Verification
把论文拆成可验证声明，文献检索+代码执行双管齐下，标注证据等级但不替代人类判断。
前置知识
LLM-based 同行评审
用大语言模型作为论文评审者，常见做法是直接把稿件喂给模型，让它输出评审意见。代表系统包括 Reviewer2、MARG、OpenReviewer、DeepReview、ReviewerToo 等。问题在于这些系统通常只看论文正文，无法判断声明是否被外部证据支持。
FactReview 的定位是改进这一类系统，所以读者需要了解现有 LLM 评审系统的能力边界（草拟批评、生成结构化反馈）以及它们共有的局限（依赖文风、无法核实声明）才能理解本文的切入角度。
科学声明验证 (Scientific Claim Verification)
判断一条科学声明是否被证据支持或反驳的任务，典型方法有 SciBERT、S2ORC、PaperQA、OpenScholar 等检索增强的学术助手。给定一句声明，从文献库中检索证据并给出真伪判定。
FactReview 直接借鉴这一范式，把评审重新定义为'声明级证据评估'，但更进一步加入了'执行证据'（跑代码）。理解这条线索能帮助读者看到 FactReview 如何把声明验证从纯文献扩展到文献+代码。
RAG 与文献定位 (Literature Grounding)
检索增强生成（RAG）从外部知识库中检索相关信息再让模型生成答案；文献定位特指把论文与领域内相邻工作做对比，证明 novelty 或放置技术位置。工具通常包括 Semantic Scholar、OpenAlex、arXiv API 等。
FactReview 用 RAG 来验证 novelty 类声明和定位论文，因此读者需要知道怎么用学术搜索引擎拉取候选论文、如何比对方法机制。
代码复现与执行式验证 (Execution-based Verification)
论文声称的实验结果需要通过运行公开的代码来核对。NeurIPS 复现报告等多项研究表明代码复现常发现论文未报告的差异。难点在环境搭建、依赖管理、随机种子、规模成本。
FactReview 把'执行证据'作为四类证据之一，且发现去掉执行证据会让 17% 的声明状态发生改变——是单一证据源里影响最大的。这要求读者理解'跑代码'为何能比纯文本分析提供更强的证据。
研究动机
近年来 ML 论文投稿量激增，但评审仍要求评审人把论文放进文献脉络、判断贡献实质、核对声明与证据、复现代码。这种'证据密集型'工作在时间压力下最容易被砍掉。现有的 LLM 评审系统（如 Reviewer2、MARG、OpenReviewer、DeepReview-v2、ReviewerToo）几乎都只读论文手稿，普遍存在三个问题：评审意见对论文写作质量敏感、容易不加验证地接受作者主张、每条判断的依据不透明。即使是较先进的 DeepReview-v2 也只部分支持文献检索，没有执行验证。最严重的场景是经验性 ML 论文——论文可能声称准确率或可复现性上的提升，但最强的检验需要查仓库、重建环境并实际运行代码；Starace 等 2025、Zhao 等 2025、Hua 等 2025 等论文证明，先进 LLM 也难以把论文、代码、跑出来的结果端到端串起来。
本文的目标是作者提出 FactReview 系统，把自动同行评审重新定义为'基于证据的声明验证'。目标不是生成一篇流畅的评审文本或给出接收/拒稿决定，而是把论文拆解为评审相关的'主要声明'，对每条声明调动三类证据：手稿证据、文献与引用完整性证据、（若代码可获取）执行证据，然后给出四种证据标签之一（Supported / Partially supported / In conflict / Inconclusive），并把每条判断都链接到具体证据。系统明确不做接收-拒稿决定，把最终判断留给人类评审人。这一定位也回应了 Li 2025、Wang 2026b、Zhu 2025a 等文献对 LLM 评审'公平性、可靠性、安全性'的担忧，并通过将输出空间约束为可审计的标签 + 证据链接来降低 LLM 评审被滥用的风险。
与已有工作不同的是，现有系统的目标都是'评审生成'，CLAIMCHECK 是最接近的诊断工作，但它是在评审文本写完后再去审计其是否被声明支撑，属于后置检查。FactReview 的差异在于：工作流更靠前——在评审文本生成之前就把声明抽出来、用证据逐条评估；同时证据来源不止手稿，还包括文献检索、引用完整性核查以及代码执行（且执行严格限制为环境/启动修复，不改科学逻辑）。另一个独特切入是把'执行证据'作为头等公民：实验证明单独去掉执行证据会让 17.0% 的声明状态变化，比去掉文献（5.7%）、去掉检索（8.4%）都大；纯手稿设置则会让 26.1% 的声明发生改变，是单一最大降幅。
核心方法
FactReview 整体采用'证据汇聚 → 声明级评估 → 报告合成'的三段式 pipeline。第一段用 MinerU 把 PDF 解析为带元数据的结构化文本块，再用 schema 约束的 LLM 把论文拆成主要声明、结果、数据集、基线、指标，每个声明保留原文 span 和位置。第二段并行构建三类证据：(1) 文献证据——对 novelty/定位类声明，从引用基线、命名方法、Semantic Scholar 检索结果、目标 paper_search/read_paper 构造一个'方法族分组 × 提交任务轴'的技术定位表，并用一个名为 RefCopilot 的内部模块把每条引文规范化、跨 arXiv/Semantic Scholar/OpenReview/OpenAlex 验证、标记撤稿/不匹配/缺失；(2) 执行证据——若提供代码仓库，则进入一个六步有状态循环 prepare → plan → run → judge → fix → finalize，环境/启动层面的修复预算封顶为 修复轮数 $K=3$，每条执行任务只允许'环境、路径、启动脚本、参数'级修复，绝不修改模型架构、损失、数据集、评估逻辑或基线；(3) 引用完整性证据——RefCopilot 给出 verification 标签和简短修复建议。第三段是声明级评估：每条声明按手稿、文献、引用、执行四类证据对齐后打四种标签之一（Supported / Partially supported / In conflict / Inconclusive），标签集保持简洁，'证据来源'作为单独 provenance 字段记录以便审计；最后系统写出一份精简的评审 + 链接的证据报告（metadata、定位表、声明级评估、支撑证据、执行结果），并由同一批证据记录生成一张 teaser 图作为视觉摘要。
核心创新是把'评审'问题从'生成一段评审文本'重新定义为'为每条主要声明打一个可审计的证据标签'，并把'执行跑出来的数字'作为可选项但又是影响最大的证据源。和已有系统的本质区别在三点：(1) 证据维度上，首次把'代码执行结果'与文献检索、手稿、引用核查放在同等位置，并设计了保守的 Run-Review-Fix 协议，修复只限环境层而不改科学逻辑；(2) 输出形态上，放弃单段评审 prose，输出'声明级证据报告 + 紧凑的 teaser 图'，让每条判断都可追溯到具体证据；(3) 价值定位上，明确不做 accept/reject，把系统定位为'评审人审计层'，避免越权替代人类判断，这一点和 OpenReviewer、DeepReview-v2、ReviewerToo 等都以生成可被使用的最终评审意见为目标的系统形成鲜明对比。
方法步骤详情
完整的 FactReview 流程可拆为四步。步骤 1（文档解析与声明抽取）——输入 PDF 论文，用 MinerU 解析为带 section 感知、表格、公式、图注、引用锚点和页位置的结构化文本块；用一个 schema 受约束的 LLM 提取器把论文拆成主要声明、报告结果、数据集、基线、指标、声明位置，每条声明返回类型化 JSON（含 text、type、scope、source span、linked evidence、evidence targets）；若一条声明横跨多个任务/数据集/指标则拆成更细的子声明，便于后续按 scope 判断支持度。步骤 2（文献定位与引用验证）——为 novelty/定位类声明构造 comparison set，来源包括被引方法、命名基线、metadata、abstracts、Semantic Scholar 相似论文；再对高风险 novelty/overlap 声明调用 paper_search/read_paper 做深入阅读；输出是'方法族分组 × 提交任务轴'的技术定位表（机制/任务/评估/资源假设），而非笼统 novelty 分数；同时 RefCopilot 把每条引文规范化成 title/author/year/venue/arXiv id/DOI/URL，跨 arXiv、Semantic Scholar、OpenReview、OpenAlex 匹配候选记录，按 title+metadata 协议核验，标记 unresolved / withdrawn / mismatch / incomplete，并返回 verification 标签和简短修复建议。步骤 3（执行式声明验证）——若论文提供代码仓库，则进入 prepare→plan→run→judge→fix→finalize 的有状态循环：先从 README、配置、入口脚本、目录结构推导候选执行任务，得到显式 execution plan；每条任务在 time/resource budget 下执行，FactReview 记录 commands、return codes、logs、intermediate outputs、metrics、alignment decisions、archived artifacts；judge 步骤把观察到的输出与论文里抽取的指标和数字对比，按'声明相关性'而非'仓库是否跑通'评估；fix 步骤严格限制为环境/启动/路径/参数级修复（依赖安装、路径纠正、启动脚本微调、补缺失参数），修复轮数封顶 $K=3$，修复痕迹作为执行 trace 的一部分被记录但不修改模型架构、损失、数据集、评估逻辑或基线；若执行成功但无法对齐到声明则保持 Inconclusive 而不强行给出正负判定。步骤 4（声明评估与报告合成）——把每条声明与手稿、文献、引用、执行四类证据对齐后打 Supported / Partially supported / In conflict / Inconclusive 之一；标签是结果、provenance 是来源，两者解耦以便审计；最后写出一份精简评审 + 链接的 evidence report（含 metadata、技术定位表、声明级评估、支撑证据、实验/执行结果），teaser 图则由同一批 evidence records 生成，作为视觉摘要。
技术新颖性
技术新颖性体现在四个层面：(1) 形式化创新——把'评审'重新形式化为声明级证据评估问题，输出空间被约束为四标签，provenance 与 verdict 解耦，使评审判断可审计、可复现；(2) 证据融合创新——首次系统地把执行证据作为与文献、引用完整性并列的'头等公民'，并设计了保守的 Run-Review-Fix 协议（K=3 轮、修复只限环境层）以避免越权修改科学内容；(3) 流程创新——把声明抽取放在评审生成之前，文献定位走'方法族分组 × 提交任务轴'的结构化表而非 novelty 分数，引用验证走 RefCopilot 这种专门的引文规范化与跨库匹配模块；(4) 评估创新——评测不是单一分数，而是把 Groundedness / Specificity / Coverage / Overall 四个维度分开的 evidence-aware rubric，并报告了 claim pass rate、paper success、RRF overhead、backend model sensitivity 等多维指标。
实验结果
在 35 篇 ML 论文、463 条人工标注主要声明的 benchmark 上，FactReview 抽取出 435 条声明（覆盖率 84.4%），平均 12.43 条/论文。表 2 显示在 1-5 分的 evidence-aware rubric 上 FactReview 取得 Overall 4.86、Groundedness 4.97、Specificity 4.94、Coverage 4.66，是所有对比系统中最高：比 DeepReview-v2（Overall 4.17）的 Overall 高 0.69、比最强的直评 LLM GPT-5.4（Overall 3.63）高 1.23、也比 24 篇配套的 OpenReview 人类评审（Overall 3.33）高 1.53；最大提升出现在 Groundedness（4.97 vs DeepReview-v2 的 4.23）和 Specificity（4.94 vs 4.26）两个维度，正是'判断是否被证据支撑'和'是否讨论具体声明/数据集/指标'这两条最直接被外部证据影响的轴。声明状态分布（图 3）显示 149 条 Supported、250 条 Partially supported、4 条 In conflict、32 条 Inconclusive，与 benchmark 分布（38.4% / 56.4% / 0.6% / 4.5%）接近，反映了 §3 的保守标签策略：只有当证据能覆盖到声明所述 scope 时才打 Supported。图 4-6 分析了执行失败模式：36 个 multi-label 失败中环境失败 10 个最多、runtime 8、metrics 6、baselines 5、import 4、alignment 3；funnel view 显示证据在环境搭建、运行、指标抽取、声明对齐四个阶段都可能被丢。表 6/7/8 给出 Run-Review-Fix 的恢复轨迹：起始 paper success 55.0%、claim pass 67.7%，经 3 轮修复后提升至 65.0% 和 82.3%，第二轮达到饱和；代价是平均 2.30 次尝试、1.45× 运行时、1.58× token；表 7 的组件消融显示去掉 fix loop 让 paper success 从 65.0% 跌到 55.0%、claim pass 从 82.3% 跌到 67.7%，证明 bounded repair 是主要恢复来源。表 9 的后端模型对比（12 个执行任务）显示 Claude Opus 4.6 成功率 83.3%、24.1 min、US$0.68 是最优，GPT-5.4 75.0% 紧随其后，Claude Haiku 4.5 仅 41.7%，跨度极大，说明执行式评审同时依赖 workflow 和背后模型能力。图 9 的证据源消融量化了每类证据的边际价值：去掉执行证据改变 17.0% 的声明状态，去掉文献检索改变 5.7%，去掉 Semantic Scholar 检索改变 8.4%，纯手稿设置改变 26.1%——执行是单一证据源里影响最大的。表 4 / 图 7 的评审人辅助实验最有说服力：单独看论文平均 50.6 分钟、声明覆盖 86.9%；加上 FactReview report 缩短到 31.6 分钟、覆盖提升到 97.8%；再加上 teaser 图进一步压到 21.3 分钟、覆盖 98.9%；时间几乎减半、覆盖提高 12 个百分点，提示 FactReview 帮助评审人更高效地定位和评估声明、不是让他们写得更短。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 整体评审质量 (Evidence-aware Overall) | Overall (1-5) | 4.86 | DeepReview-v2 4.17 / OpenReview 人类 3.33 / GPT-5.4 3.63 | 比 DeepReview-v2 高 0.69，比 OpenReview 人类高 1.53，比最强直评 LLM 高 1.23 |
| 评审 groundedness (判断是否被证据支撑) | Groundedness (1-5) | 4.97 | DeepReview-v2 4.23 / OpenReview 人类 2.96 / GPT-5.4 3.26 | 比 DeepReview-v2 高 0.74，比 OpenReview 人类高 2.01 |
| 评审 specificity (是否讨论具体声明/数据集/指标) | Specificity (1-5) | 4.94 | DeepReview-v2 4.26 / OpenReview 人类 3.17 / GPT-5.4 3.26 | 比 DeepReview-v2 高 0.68，比 OpenReview 人类高 1.77 |
| 声明覆盖率 | Coverage (1-5) | 4.66 | DeepReview-v2 4.03 / OpenReview 人类 3.88 / GPT-5.4 4.37 | 在 groundedness/specificity 主导维度领先；GPT-5.4 在 coverage 上 4.37 略高，说明直评 LLM 也能逐条覆盖但支撑度低 |
| 基准声明抽取覆盖率 | Extraction coverage (%) | 84.4% (435/463) | 平均 12.43 claims/paper vs 13.23 in benchmark | Rec 84% 主要声明；剩余 16% 主要是声明合并/拆分粒度差异 |
| 执行式复现 (Run-Review-Fix 3 轮后) | Paper success / Claim pass | 65.0% (13/20) / 82.3% (79/96) | 无修复 55.0% / 67.7% | Paper success +10.0pp，Claim pass +14.6pp；代价 2.30 次尝试、1.45× 运行时、1.58× token |
| 执行证据对声明状态的影响 | ΔStatus accuracy | 完整系统作为基准 | w/o Execution -17.0% / w/o Literature -5.7% / w/o Retrieval -8.4% / Manuscript only -26.1% | 执行是单一最大证据源；纯手稿设置损失最大 26.1% |
| 评审人辅助 - 评审时间 | Mean review time (min) | +Report 31.6 / +Report+Teaser 21.3 | Paper only 50.6 | 时间 -58%（50.6→21.3） |
| 评审人辅助 - 声明覆盖 | Benchmark claim coverage (%) | +Report 97.8% / +Report+Teaser 98.9% | Paper only 86.9% | Coverage +12pp（86.9%→98.9%） |
| 后端模型鲁棒性 (12 个执行任务) | Success rate (%) | 默认 Codex/gpt-5.5 backend | Claude Opus 4.6 83.3% / GPT-5.4 75.0% / Claude Sonnet 4.5 66.7% / GPT-4.1 58.3% / GPT-4o 50.0% / Claude Haiku 4.5 41.7% | 跨模型 success 跨度 83.3%→41.7%，证明 workflow 之外模型能力仍是关键 |
局限与改进
作者在'Limitations'一节明确承认五点：(1) 35 篇论文、463 条声明的 benchmark 仍偏小，子领域、venue、仓库风格的覆盖度需要扩展，深度定性分析目前只有 CompGCN 一个案例（Figure 10）；(2) 执行式验证受 wall-clock、算力预算、保守修复策略约束，对需要长时间训练、专有数据或大规模基础设施的实验可能只能给 Inconclusive，即便原则上是可复现的；(3) 后端模型分析只覆盖 6 个当前通用 LLM，专用科学/代码模型行为可能不同，且绝对数字会随模型演进而漂移；(4) 评审人辅助研究的评审人池较小且论文集合固定，时间/覆盖收益能否泛化到更大群体未知；review-quality 对比也只反映本文 evidence-aware rubric 而非 venue-specific 标准；(5) 系统针对有公开代码的经验性 ML 论文，纯理论、dataset-oriented、systems-oriented 投稿可能需要不同的证据源和声明 taxonomy。在我自己看来，还可以补充：(a) evidence-aware rubric 是作者自定，虽然更精准但缺少与 ICLR/NeurIPS 真实评审 rubric 的相关性研究；(b) Backend 对比里 API cost 是绝对美元数，没有归一化到'每成功一篇'，单纯看 $/episode 会让小模型显得便宜而忽略其低成功率带来的隐性成本；(c) Run-Review-Fix 的 2.30 次尝试和 1.45× runtime 是平均值，最坏情况（如需 3 轮修复+大仓库冷启动）可能远超均值，论文没给分布；(d) 论文没有评估 reviewer 是否会过度信任 system output（'automation bias'），只在'Ethical Considerations'里定性提到，没有定量实验。
独立分析的弱点
独立分析可识别四个具体弱点并对应改进方向：(a) 声明抽取仍是 schema 约束的 LLM 调用，对高度跨学科、或带大量公式的论文，84.4% 覆盖率意味着 15%+ 的主要声明会漏检——改进方向是把抽取器改成 self-consistency + 主动澄清的多 pass 流水线，或对公式/图表另开一个 symbol-aware 抽取通道；(b) 文献定位高度依赖 Semantic Scholar，对某些冷门领域（量化交易、芯片 EDA）候选集稀薄，paper_search 预算 1-3 次会很快耗尽——可改为把 S2 与 OpenAlex、Crossref、Connected Papers 混合检索并自适应分配预算；(c) Run-Review-Fix 的修复只限环境/启动层，对依赖链断裂（PyTorch 大版本不兼容、CUDA 驱动错配）的恢复能力有限，这是 Claude Haiku 4.5 成功率仅 41.7% 的部分原因——改进方向是引入 Dockerfile 自动生成 + 容器回放，把'环境层'扩展到 'container-as-artifact'；(d) reviewer assistance 的人因实验里 participants 是直接邀请的小池子，存在 selection bias（都是有 ML 评审经验的研究者），无法代表新手评审或领域外评审——可扩展到不同经验梯度，并把'对 system 输出的依赖度'作为额外因变量测量。
未来方向
作者在结论里提出三条方向：(1) 扩大 reviewer 与论文覆盖——既扩子领域/venue 风格，也扩评审人池和接受反馈机制；(2) 加强环境恢复与结果对齐——具体指向 RRF 的下一阶段，自动化环境重建、更鲁棒的 metric 抽取和声明对齐；(3) 扩展 evidence taxonomy 超出经验性 ML 论文——例如对理论性论文接入 proof checking / Lean 形式化验证，对 dataset-only 论文接入数据质量审计，对 systems 论文接入 profiling/baseline 复跑。基于结果还可以延伸的方向有：(a) 把执行证据从 K=3 轮扩展为带 early-stop 的 budget-aware 调度，对'可低成本验证'的 claim 优先跑；(b) 引入人机协作界面，让 reviewer 在声明级粒度上确认/反驳系统标签，作为 RLHF 训练信号；(c) 借鉴 PaperBench、ResearchCodeBench 等基准做更细粒度的复现评估，区分'跑通'与'对齐到声明'两种成功标准；(d) 把四标签扩展为带 confidence 的概率分布或对冲突证据做对抗式解释，缓解'单一证据被去掉 17% 状态变化'这种脆弱性。
复现评估
代码已公开在 https://github.com/DEFENSE-SEU/FactReview，prompt 模板在论文附录 B 完整给出（包括 SYSTEM role、检索规则、tool policy、search budget、anti-stall rule、技术定位 contract、claim extraction contract），实现细节（backend model、parser、retrieval source、fix budget K=3）也都明确披露。benchmark 是 35 篇 ML 论文 + 463 条人工标注声明，其中 24 篇有匹配的 OpenReview 人类评审，但 benchmark 本身和 OpenReview 评论数据没有全部公开（受版权与隐私限制），第三方复现时需要自行获取论文和 OpenReview 评论，但 prompt、code、评测 rubric 都是开源的。算力需求较友好：单台 8 卡 RTX 4090 本地服务器即可，单篇 pipeline 成本约 357.33K tokens + 773.14 秒（其中 Report 阶段 321.09K tokens + 633 秒是主开销，Parse 阶段 0 tokens + 57.44 秒，Analysis 36.24K tokens + 82.29 秒，Teaser 0 tokens + 0.42 秒）；执行后端 12 任务对比里 Claude Opus 4.6 单次成本 US$0.68、GPT-5.4 US$0.55。复现难度中等：MinerU 解析和 RefCopilot 跨库查询门槛低，但 Run-Review-Fix 涉及真实仓库环境重建，环境层修复是主要不确定来源，作者在表中给出 env/runtime/metric/alignment 4 类失败占比有助于定位。整体而言代码+prompt+rubric+benchmark construction recipe 公开，复现可行性较高，绝对数字会随 backend model 升级而漂移。
论文图表
左侧是一个 manuscript-only 的 LLM 评审流程（手稿 → LLM → 评审文本），中间用红色批注强调'unverified author claims'和'no execution check'，右侧是 FactReview 的流程：手稿+代码+文献 → 抽取声明 → 调取文献 + 执行代码 → 给每条声明打证据标签 → 链接到证据的评审。视觉上把'单点'和'多源'的对比直接画出。
直观说明 FactReview 与现有 LLM 评审系统的根本差异：现有系统是端到端单段 prose，FactReview 是声明级、多源证据、可审计的流程。这是理解全文 motivation 的入口图。