SciCoQA：科学论文与代码对齐的质量保证 SciCoQA: Quality Assurance for Scientific Paper--Code Alignment
首个检测论文-代码不一致的基准数据集，揭示LLM仅能捕获46.7%的真实差异
前置知识
论文-代码不一致（Paper-Code Discrepancy）
指科学论文中描述的方法与其实现代码之间的语义冲突。例如论文描述使用L2归一化，但代码实现的是L1归一化。这种不一致不同于代码bug（bug与论文描述无关）或超参数配置差异（通常可通过配置文件解决）。论文-代码不一致会直接影响实验结果的可复现性，因为读者无法从论文准确推断代码的实际行为。
这是本文研究的核心对象，理解其定义边界（什么算、什么不算不一致）是理解整个数据集构建和评估方法的基础。
可复现性危机（Reproducibility Crisis）
指科学研究结果难以被独立复现的系统性问题。在AI和计算科学领域，Baker (2016)的调查显示超过70%的研究者曾尝试复现他人实验失败。即使提供了代码，实现细节也可能与论文描述存在偏差，导致性能差异未被报告（Henderson et al., 2018）。这种危机随着AI科学家（自动化研究系统）的兴起而加剧，因为人类无法验证机器生成的海量研究产出。
本文的动机正是源于这一危机——需要自动化工具来检测论文-代码不一致，以确保科学产出的可靠性。
LLM-as-a-Judge
使用大语言模型作为评估器来判断模型输出质量的方法。本文采用GPT-OSS 20B作为judge来判断预测的不一致是否与参考答案匹配。这种方法存在自我偏好偏差（self-preference bias），即模型倾向于给自己的输出更高评分（Panickssery et al., 2024）。为缓解这一问题，本文使用了与被评估模型不同的模型作为judge。
理解评估方法对于正确解读实验结果至关重要，因为评估指标的可靠性直接影响对模型能力的判断。
跨模态验证（Cross-Modal Verification）
指在不同模态（本文中是自然语言文本与代码）之间进行一致性检查的任务。与传统的文本-文本或代码-代码验证不同，跨模态验证需要模型同时理解科学论文的语义描述和代码的实现逻辑，并识别两者之间的语义冲突。这比单一模态的理解更具挑战性，因为它要求模型具备深层次的推理能力。
本文将论文-代码不一致检测定义为跨模态验证任务，理解这一概念有助于把握任务的本质难度和技术定位。
召回率（Recall）与精确率（Precision）的权衡
在本文的评估场景中，召回率指模型能检测出多少比例的真实不一致，精确率指模型预测的不一致中有多少是正确的。对于质量保证场景，低召回率意味着遗漏的不一致会给研究者带来虚假的安全感，而低精确率产生的误报可以通过人工审核过滤。因此，召回率是更关键的瓶颈。
本文的核心发现之一就是模型的召回率严重不足，理解这一权衡有助于评估模型在实际应用中的可靠性。
研究动机
在AI和计算科学领域，论文与代码之间的不一致是一个普遍但难以系统检测的问题。这些不一致表现为多种形式：论文描述使用L1归一化但代码实现的是L2归一化、论文中的FiLM模块对参数施加sigmoid激活但论文未提及此约束、论文描述使用宏F1指标但代码实际计算的是微F1等。这些差异往往在复现研究或发表后才被发现，导致大量研究资源的浪费并侵蚀科学信任。随着AI科学家系统的兴起（如自动生成代码仓库、端到端自动化研究流程），这个问题变得更加紧迫——人类无法手动验证机器生成的海量研究产出，而现有LLM系统存在上下文限制、复合错误和自我纠正困难等问题。然而，LLM能否可靠检测论文-代码不一致从未被系统测量过，这正是本文要填补的空白。
本文的目标是本文的具体目标是：（1）构建SCICOQA，首个用于检测论文-代码不一致的基准数据集，包含635个不一致实例（92个真实数据，543个合成数据），覆盖计算机科学、物理学、定量生物学等多个计算科学领域；（2）系统评估22个最先进的LLM（包括商业模型和开源模型）在这一任务上的表现；（3）建立不一致类型的分类体系（Difference、Paper Omission、Code Omission三种类型，以及Algorithm、Model、Loss、Evaluation、Data、Training六个类别），为未来研究提供标准化的分析框架。
与已有工作不同的是，与已有工作相比，本文的独特切入角度在于将论文-代码不一致检测定义为跨模态验证任务。之前的研究要么只分析论文文本（如检测AI论文中的计算错误），要么局限于代码注释不一致性检测（CCI，通常只处理单个函数和内联注释），而本文要求模型在密集的科学论文和多文件代码仓库之间进行全局对齐推理。此外，本文利用真实GitHub issues和可复现性报告作为真实数据源，同时设计了合成数据生成流水线来扩展数据规模和领域多样性，这种混合策略在数据质量和规模之间取得了平衡。
核心方法
SCICOQA的方法论可以用一个类比来理解：想象你要检查一份菜谱（论文）和厨师的实际操作（代码）是否一致。你不仅要对比每个步骤的描述，还要识别菜谱中遗漏的关键操作、代码中多余的步骤，以及两者的根本性差异。技术路线上，本文采用三阶段数据收集策略：首先从GitHub issues和ML Reproducibility Challenge报告中提取真实世界的论文-代码不一致；然后设计合成数据生成流水线，在真实代码库中注入可控的不一致以扩展数据规模和领域覆盖；最后通过LLM-as-Judge框架评估模型检测不一致的能力。整个流程确保了数据的高质量（真实数据经过严格人工验证）和可扩展性（合成数据可自动生成）。
本文的核心创新在于将论文-代码不一致检测形式化为一个有明确定义边界的跨模态验证任务。关键区别在于：（1）定义了严格的不一致类型分类——Difference（代码实现与论文描述不同）、Paper Omission（代码包含论文未描述的关键组件）、Code Omission（论文描述的步骤在代码中缺失），并明确排除了bug、超参数配置差异和琐碎的工程实现细节；（2）设计了一种混合数据收集策略，结合真实世界数据（GitHub issues和可复现性报告，提供高保真但稀疏的不一致实例）和合成数据（通过GPT-5在真实代码库中注入不一致，提供可控且可扩展的数据），并通过实验证明合成数据与真实数据的模型排名高度相关（r=0.94），验证了合成数据作为相对模型比较代理的有效性；（3）建立了不一致的分类体系（6个类别），使得后续分析能够精确诊断模型在哪些类型的不一致上表现较弱。
方法步骤详情
SCICOQA的构建包含以下关键步骤：（1）真实数据收集——从GitHub搜索引用arXiv论文的代码仓库（2020-2025年发布，至少有一个issue），爬取10,636个issues，用Qwen3 4B Thinking自动分类筛选出232个候选不一致，人工验证后得到59个有效不一致；同时从ML Reproducibility Challenge（2020-2025年）的171篇可复现性报告中，用GPT-5提取132个候选不一致，人工验证后得到65个有效不一致。（2）验证与标准化表述——所有人工筛选的不一致由Gemini 3.1 Pro和GPT-5独立验证，确保不一致确实存在，并生成标准化的3-8句描述（包含论文描述、代码实现、差异说明）。（3）合成数据生成——从GitHub爬取中采样204个仓库（102个CS领域，102个非CS领域），对每个仓库用GPT-5生成5个代码diff，采样最多3个，额外添加13个Paper Omission类型，共得543个合成不一致。（4）评估框架——给定论文和代码，提示模型生成不一致列表，用GPT-OSS 20B作为judge判断预测是否匹配参考答案，计算recall作为主要指标。
技术新颖性
SCICOQA的技术新颖性体现在三个层面。首先，在任务定义上，这是首个将论文-代码不一致检测作为系统化基准的研究，与之前的代码注释不一致性检测（CCI）相比，SCICOQA要求在完整的科学论文和多文件代码仓库之间进行全局推理，而非局限于单个函数的局部检查。其次，在数据构建上，本文创新性地结合了真实世界数据（来自GitHub issues和可复现性报告）和合成数据（通过LLM在真实代码库中注入不一致），并通过严格的实验证明了合成数据的相对排名有效性（r=0.94），为在非CS领域（如物理学、定量生物学）扩展数据提供了可行路径。第三，在评估方法上，本文采用了基于推理模型的LLM-as-Judge框架（使用GPT-OSS 20B），并通过人工验证确认了其与人类判断的高度一致性（F1=87.5%），同时引入了类似信息检索中的池化（pooling）方法来构建更完整的ground truth，缓解了不完全标注对recall估计的影响。
实验结果
本文对22个最先进的LLM进行了系统评估，核心发现如下：（1）最佳模型的recall严重不足——Gemini 3.1 Pro和GPT-5 Mini在真实数据上仅达到46.7%的recall，意味着超过一半的真实不一致未被检测到。在合成数据上，GPT-5的recall为70.0%，表明合成任务相对更容易。（2）不一致类型影响显著——Code Omission最容易检测（因为代码中的缺失可以直接与论文对比），Difference次之，Paper Omission最困难（因为需要区分代码中的实现细节是合理的工程选择还是与论文的实质性偏差）。（3）输入长度与性能负相关——将数据按prompt token数分为5个bin，从最短（≤31k）到最长（≥131k），recall呈现一致的下降趋势。例如GPT-5从77.5%降至50.7%，Gemini 3.1 Pro从64.4%降至37.3%。（4）预训练数据污染效应——模型在2025年发表的论文（大部分不在预训练数据中）上表现最差，支持了数据污染的担忧。（5）论文输入不可或缺——移除论文仅保留代码输入时，所有模型性能平均下降19.2个百分点（真实数据，相对下降48.3%），确认了跨模态推理的必要性。（6）精确率较高但不足以弥补低recall——在20篇NLP/CV论文的precision分析中，Gemini 2.5 Pro达到94.1%的precision，GPT-5为85.7%，但GPT-OSS 20B仅为67.0%。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 真实数据论文-代码不一致检测 | Recall | Gemini 3.1 Pro: 46.7%, GPT-5 Mini: 46.7% | 次优模型GPT-OSS 20B: 42.4% | 最佳模型仅比次优高4.3个百分点，整体recall普遍偏低 |
| 合成数据论文-代码不一致检测 | Recall | GPT-5: 70.0% | GPT-5 Mini: 64.3% | 合成数据比真实数据recall高约23个百分点 |
| 20篇NLP/CV论文precision分析 | Precision | Gemini 2.5 Pro: 94.1% | GPT-5: 85.7%, GPT-OSS 20B: 67.0% | Gemini精确率最高，误报率最低 |
| 129个pooled不一致的F1评估 | F1 | GPT-5: 72.4% | GPT-5 Mini: 66.5%, GPT-OSS 20B: 66.1% | GPT-5在precision-recall权衡上表现最佳 |
局限与改进
本文存在以下主要局限性：（1）领域偏向——真实数据主要集中在计算机科学和AI领域，非CS领域的论文-代码不一致基础设施几乎不存在。虽然合成数据可以扩展到物理学、定量生物学等领域，但合成数据的分布可能与真实不一致的分布存在差异，非CS领域的性能应谨慎解读。（2）数据集规模——635个不一致实例相对于大规模预训练语料库较小，这是数据质量与规模之间的权衡：真实世界的不一致天然稀疏，且经过严格的人工验证过程。（3）合成数据生成者的双重角色——GPT-5既是合成数据的生成者，也是被评估的模型，存在潜在的利益冲突。虽然相关性分析（r=0.94）表明相对排名仍然有效，但GPT-5在合成数据上的recall偏高，排除GPT-5家族后相关性升至r=0.98。（4）评估框架的自偏好偏差——GPT-OSS 20B作为judge存在自我偏好，给自己的输出更高评分。虽然使用了不同的模型作为judge来缓解，但这种偏差仍可能影响绝对性能的估计。（5）不一致定义的局限——本文排除了bug、超参数配置差异和琐碎的工程实现细节，这意味着SCICOQA不覆盖软件工程缺陷的完整光谱。
独立分析的弱点
本文存在以下可改进的弱点：（1）数据规模不足——635个不一致实例对于训练专门的检测模型来说可能不够，未来可以通过更自动化的流水线（如利用多个LLM交叉验证）来扩大真实数据规模，同时保持质量。（2）评估指标单一——本文主要使用recall作为指标，但实际应用中precision-recall曲线和F1-score同样重要。特别是对于质量保证场景，应考虑引入成本敏感的评估指标，将漏检不一致（false negative）和误报（false positive）的代价进行量化比较。（3）缺乏对检测结果的定位能力——当前模型只输出不一致的描述，但不指出具体是论文的哪一段和代码的哪一行。引入结构化的定位输出（类似信息检索中的段落级或行级定位）可以显著提升工具的实用性。（4）合成数据的多样性限制——虽然合成数据覆盖了多个科学领域，但不一致类型主要集中在Algorithm（26%）和Model（21%），其他类型的覆盖可以进一步平衡。（5）缺乏对检测结果的可解释性分析——模型为什么能或不能检测某个不一致？是否与特定的代码模式、论文表述方式或领域知识相关？这类分析可以帮助改进模型设计。
未来方向
未来研究方向包括：（1）开发专门的论文-代码对齐模型——当前评估表明通用LLM的recall严重不足，未来可以探索基于检索增强生成（RAG）的方法，先从论文中提取关键方法描述，再在代码中搜索对应实现，缩小搜索空间以提升recall。（2）构建更大规模的多领域数据集——随着可复现性挑战和期刊的扩展（如ReScience C、Replication Research），可以系统收集更多真实不一致，同时改进合成数据生成流水线以覆盖更多科学领域。（3）开发端到端的自动化质量保证系统——将不一致检测集成到论文提交流程中，作为同行评审的辅助工具，帮助审稿人快速定位潜在问题。（4）探索多模态输入——当前仅使用文本输入，未来可以引入论文中的图表、代码执行结果等多模态信息，提供更全面的验证。（5）研究不一致的自动修复——在检测到不一致后，自动生成修复建议（如更新论文描述或修改代码实现），形成闭环的质量保证流程。
复现评估
本文在可复现性方面做得较好：代码和数据均已开源（GitHub: https://github.com/ukplab/scicoqa, HuggingFace: https://hf.co/datasets/ukplab/scicoqa），采用CC-BY-4.0许可证。合成数据使用的代码仓库均来自宽松许可证（MIT、Apache 2.0、BSD、CC-BY），确保了合法的代码再分发。复现本文的实验需要访问多个商业LLM的API（GPT-5、Gemini等），以及1-4块A100 80GB GPU来部署开源模型。评估框架使用GPT-OSS 20B作为judge，这是一个开源模型，可完全复现。数据集构建过程涉及大量人工验证（对候选不一致进行筛选和确认），这部分工作量较大但可通过论文中提供的详细prompt模板来标准化。总体而言，复现难度中等——数据和评估代码开源，但需要显著的计算资源和API访问权限。
论文图表
图中展示了一个具体的FiLM（Feature-wise Linear Modulation）模块的不一致：论文描述将损失参数向量λ通过两个MLP生成σ和μ，然后对特征图进行仿射变换f̃=σ⊙f+μ；但代码实现中对μ和σ都施加了sigmoid激活函数，将两者限制在(0,1)范围内，而论文未提及此约束。
这张图直观展示了什么是论文-代码不一致，是理解整个研究问题的起点，帮助读者快速建立对任务的具象认知。