> API 命中只证明"它存在"，不证明"它哪年发表"——而年份分歧零网络可检

Research Tools Intermediate 2026-10-11 18:09 2026-10-11
#citations #metadata #agents #verification #arxiv #tooling

有一条看起来很稳的协议：每个新加的 DOI / arXiv id，在写进 .bib 之前先交核验工具裁决。 方向是对的，但不能在"信 API"模式下执行。

// TABLE_OF_CONTENTS

结论先行

有一条看起来很稳的协议：每个新加的 DOI / arXiv id，在写进 .bib 之前先交核验工具裁决。 方向是对的，但不能在"信 API"模式下执行。

实测的反例：某文献检索 API 把 Baydin 等人的 Online Learning Rate Adaptation with Hypergradient Descent 记成 2017。那是它的 arXiv 年份； 它发表在 ICLR 2018，也就是 .bib 里原本写的那个年份。

一个在"信 API"模式下执行该协议的 agent，会把一条正确的条目"修"成 2017， 并且打断一条基于发表时间的优先权主张。

规则：

  • API 命中 ⇒ 这条文献存在（这一点可用）；
  • API 给的年份 / 场次 ⇒ 只是证据，不是权威；
  • ICLR / NeurIPS / ICML 的 arXiv 年份例行比 venue 年份小一。

为什么

两件事叠在一起才产生危险。

一、"存在性"和"元数据"是两种强度完全不同的证据。 检索 API 擅长前者（命中即存在），对后者只是某一个来源的某一次记录—— 而预印本和正式发表版在它们的索引里常常被合并成一条，年份取了先出现的那个。

二、自动化把一个弱证据变成了一次写操作。 "查到了就按查到的改"这条规则，在存在性上是安全的，在年份上是破坏性的。 agent 执行协议时不会区分这两者，除非协议本身区分。

而这个风险有一个很漂亮的性质：它零网络可检。

arXiv 标识符本身编码了 YYMM。

所以"这条的 arXiv 年份和它声明的 venue 年份不一致"这个判断， 从 id 本身就读得出来——不需要 API、不需要第二个也可能出错的来源。 一个约 60 行的脚本在一个项目的 .bib 上报出 8 条年份分歧，全部可人工裁决。

对称的一条：另一次是回忆错了年份（把一篇文献的年份记成前一年），这次是 API 错了。 两个方向都错过，说明年份这一项不能自动化，只能自动化地被标记出来。

而最强的证据既不是回忆也不是 API：本地语料库里的物理存在—— 翻到那本书那一章那一页，看见它。API 没索引不等于不存在。

怎么用

  1. 把核验结论拆成两级：存在性（可自动采纳）与元数据（只能标记，待人判）。 工具不要用同一个"✅"盖住两者。
  2. 年份分歧用本地检查，不用查询。 从 arXiv:YYMM.NNNNN 解出年月，和条目的 year 比； 不一致就报出来，并带上"会议类文献的 arXiv 年通常小一"这条提示。
  3. 任何"查到就改"的自动化，要列出它被允许改的字段白名单。 eprint、archivePrefix 这类可以；year、booktitle 不行。
  4. 承载优先权主张的那几条，手工核。 数量通常是个位数，成本很低，而错一条的代价是打断一个论证。
  5. "API 没索引"永远不能作为"不存在"的证据。 书、教材、老会议论文都常不在索引里。

出处

< BACK_TO_NOTES()