第02章 AI 研究的七类失败模式

在 上一篇文章 中,我们提到 Lu 等人(2026)的 The AI Scientist 虽然通过了盲审,但其 Limitations 章节揭示了一系列结构性失败模式。ARS 将这些失败模式系统化为一份 7 类阻断式检查清单,在 Stage 2.5 和 Stage 4.5 两个诚信闸门强制运行。

这篇文章逐一剖析每一类失败模式:它是什么、为什么危险、以及 ARS 如何检测。

分类法的来源

这 7 类模式有两个来源:

  1. Lu et al. (2026) 在 The AI Scientist 的 Limitations、Figure 2 和 Supplementary A.2.9 中记录的失败案例
  2. GPTZero × NeurIPS 2025 提出的 5 类引用幻觉分类法(TF/PAC/IH/PH/SH),被整合为 Mode 2

ARS v3.2 将两者合并,形成了覆盖从实验执行到引用的完整失败模式分类。


Mode 1:实施错误通过 AI 自审

问题本质:分析或实验代码中存在 bug(off-by-one、变量写错、静默除零、类型强制转换、参数传错),但 AI 运行代码后只看顶层指标"看起来合理",于是将错误结果原样写入论文。

Lu 2026 案例:Supplementary A.2.9 的调试记录显示,The AI Scientist 多次接受了包含静默崩溃或数值不稳定性的实验运行。Figure 2 展示了一个 ICLR 审稿人抓到的案例:论文的主要分析依赖于一个代码并未实际实现的设置。

为什么危险:这是最难被下游环节发现的失败——同行评审者看不到代码和实验日志,无法区分"运行了正确实验得到的数字"和"bug 产生的数字"。而顶层指标(准确率、F1 等)在 bug 存在时可能看起来完全正常。

ARS 如何在 Stage 2.5 检测:

  • 对论文中每个数值结果追问:用户是否有保存的运行日志?退出码是否为 0?是否有警告?
  • 检查效应量是否可疑地"整齐"(恰好 0.5、恰好是基线的 2 倍、多个条件下方差完全一致)
  • 检查误差棒/置信区间在不同条件下是否有合理变化

Mode 2:幻觉引用

问题本质:引用了一篇不存在的论文、写错了年份/期刊/作者、或将某篇论文未包含的发现归因于它。

危险程度最高的子类型:

  • TF(Total Fabrication):论文完全不存在——标题、作者、期刊全部是 AI 生成
  • PAC(Plausible Author Combination):作者名来自不同真实论文的组合,但论文本身不存在
  • IH(Incorrectly attributed Hallucination):论文存在但被赋予了它没有的发现

ARS 的检测体系(v3.3 升级后):

  • Tier 0:Semantic Scholar API 批量验证——程序化检查 DOI 和标题匹配(Levenshtein ≥ 0.70)
  • Tier 1:DOI 一致性检查——DOI 指向的论文是否与引用中描述的论文一致
  • Tier 2:WebSearch 手动验证——对前两层无法确定的引用做人工级 web 搜索

三层检查由 source_verification_agent 和 integrity_verification_agent 协作完成。任何一层发现的不一致都会被标记为 SUSPECTED。

一个值得注意的数据:ARS v2.7 的出版后稽核对全部 68 篇引用做了逐一 WebSearch 验证,发现 21 篇存在问题(31% 错误率),其中包括 4 篇完全捏造的引用和 6 篇作者错误。这证明了外部程序化验证的不可替代性——即使经过了三轮诚信审查,仍有漏网之鱼。


Mode 3:幻觉实验结果

问题本质:论文声称"我们观察到了 12% 的提升",但没有一次实际实验运行产生了 12% 这个数字。AI 可能以不同于论文声称的方式做了平均、或者报告了崩溃运行的输出、或者编造了数字来匹配叙事。

Lu 2026 案例:Lu 等人将"幻觉实验结果"专门列为 Limitations,指出自动审稿系统难以检测此类问题,因为审稿者无法访问底层运行数据。

为什么比 Mode 2 更难检测:引用的存在性可以通过外部数据库验证。但实验结果的真实性只能通过与用户的实际实验日志对比来验证——没有"实验结果的 Semantic Scholar"。

ARS 的检测策略:

  • 对每个"X% 提升"或"优于基线 Y"的声明,要求用户提供原始数据来源
  • 检查论文中的表格是否与保存的 CSV/张量日志/wandb 记录匹配
  • 检查论文声称的"运行了 N 个种子"是否与实际运行目录数量一致

Mode 4:取巧特征依赖

问题本质:报告的指标是真实的,但模型是通过利用取巧特征(而非学习预期的泛化模式)达到的。典型案例:在色彩偏置的 MNIST 上,模型通过识别背景颜色而非数字形状达到 99% 准确率。

Lu 2026 案例:Figure 2b——The AI Scientist 提出了一种方法,在色彩偏置 MNIST 上测试后获得高准确率,撰写论文声称方法"解决"了该任务。审稿人指出模型实际上利用的是颜色捷径,而非学习数字形状。

ARS 的检测位置:这个检查主要由 Stage 3 的魔鬼代言人审稿者执行,但在 Stage 2.5 需要标志出——让用户知道在进入 Stage 3 之前需要准备好消融实验。

Stage 2.5 的探测问题:

  • 是否有可控消融实验排除了最明显的取巧特征?
  • 论文的"消融研究"部分是否真正消融了声称的机制,还是只是消融了无关超参数?
  • 基线是否足够强,使得超越它需要提出的机制而不仅仅是更多算力?

Mode 5:实施错误被包装为意外发现

问题本质:这是 Mode 1(bug)和叙事生成的复合失败。管线生成了一个意外的结果(实际上是 bug 导致的),但写作阶段将意外结果重新包装为新颖发现。论文声称"我们发现在条件 Y 下 X 表现出意外行为",而实际上 X 的行为完全符合预期,是条件 Y 被错误实现了。

Lu 2026 案例:Lu 等人将此识别为复合失败模式——它需要 Mode 1(bug)加上写作阶段的错误,AI 的叙事生成器将 bug 的输出当作真实结果,并围绕它构建故事。

为什么特别危险:包含这种失败的论文,读起来比没有 bug 的版本更"有趣"。“意外发现"天然具有叙事吸引力,但它是建立在沙地上的城堡。

ARS 的检测信号:

  • 检查论文中是否包含"surprisingly"“unexpectedly"“counterintuitively"或"与我们的假设相反"等措辞
  • 对每个"意外"声明,追问用户能否指出预测相反结果的文献——如果没有文献预测相反方向,这个"意外"可能就不是意外,而是 bug
  • “意外"结果是否在第一次运行就出现?首次运行的意外是高风险信号

Mode 6:方法论伪造

问题本质:Methods 段落描述了并未实际执行的实验、超参数、数据集或流程。AI 基于"合理的实验应该是什么样"撰写了 Methods 段落,而非基于实际发生的实验。

Lu 2026 案例:Lu 等人指出,The AI Scientist 的写作阶段有时产出了与实际超参数记录脱节的 Methods 文本。他们增加了与实验运行配置的交叉检查来缓解此问题。

ARS 的检测:

  • Methods 段落中的每个数字(学习率、batch size、epochs、数据集大小、训练/验证集划分)是否在用户的实际运行配置/日志中出现?
  • Methods 段落是否描述了用户代码中找不到的预处理步骤?
  • Methods 段落是否在实验并未实际运行的情况下使用了 past tense?

Mode 7:管线早期阶段的框架锁定

问题本质:在管线早期阶段(研究问题定义、方法论选择、超参数方向)做出的错误承诺,后续阶段无法修正,因为它们在结构上处于下游。最终产出是一篇执行精良但回答了错误问题或使用了不适当方法的论文。

Lu 2026 案例:Figure 3a 追踪了 The AI Scientist 的 Agent 树搜索,显示大多数失败论文在 Stage 2(超参数调优)阶段已失败——Agent 早期锁定了某个方向,后续无法恢复。

ARS 的应对:

  • 如果用户知道了现在知道的一切,是否会回到 Stage 1 改变研究问题或方法论?
  • 论文的 Discussion 是否包含"事后看来"或"我们后来意识到"等措辞?这些是框架锁定的迹象
  • 如果 Stage 2.5 检测到此模式,用户可以选择回到 Stage 1 或 Stage 2,而非继续推进到 Stage 3

诚信闸门的运行机制

Stage 2.5(第一次诚信闸门)

对全部 7 类模式逐一运行,每类输出三个可能结论之一:

结论含义
CLEAR有证据排除该模式
SUSPECTED至少一个检测问题返回了令人担忧的答案
INSUFFICIENT EVIDENCE没有足够信息判断(需要用户提供实验日志等)

阻断条件:任何一个模式被标记为 SUSPECTED → pipeline 阻断。Mode 1/3/5/6 出现 INSUFFICIENT EVIDENCE → 阻断(这四类需要用户提供日志才能排除)。Mode 2/4/7 的 INSUFFICIENT EVIDENCE 可以带警告通过,但在 Stage 4.5 会重新检查。

Stage 4.5(最终诚信闸门)

以零容忍标准重新运行全部 7 类模式。附加规则:任何在 Stage 2.5 被标记为 SUSPECTED 的模式,在 Stage 4.5 必须被解决(CLEAR 或用户提供理由的 Override)。如果同一模式在 Stage 4.5 仍为 SUSPECTED,pipeline 拒绝进入 Finalize 阶段。

Stage 6(过程记录)

在 AI 自我反思报告中记录一份"失败模式审计日志”,列出每类模式的最终状态、检测时间和用户决定。


理解了这 7 类失败模式之后,接下来让我们看看 ARS 的实际使用——如何在 30 秒内完成安装并选择适合自己的部署方式。

参考来源:

  • source/academic-research-skills/academic-pipeline/references/ai_research_failure_modes.md
  • Lu et al. (2026). Nature 651, 914-919
  • GPTZero × NeurIPS 2025 citation hallucination taxonomy

相关内容

如果这篇文章对你有帮助,欢迎请我喝杯咖啡 ☕
Cygnus Yang 支付宝支付宝
Cygnus Yang 微信微信