1.5亿篇论文进入AI语料库,撤稿和更正还能追得上吗?

一篇论文今天进入语料库，明天可能被更正，一年后也可能因为数据或同行评议问题被撤稿。期刊网页会留下这些变化，文献数据库也会更新标记。可论文一旦被加工成语料，分批交给不同模型，后来的更正和撤稿还能沿着原路追上去吗？

7月17日，中国科学院“敖仓·科技语料库”正式发布。按照官方口径，其数据来源覆盖超过320PB科学数据、1.5亿篇科技论文、1.2亿件发明专利和500万本科技图书。相关资料还要经过清洗整编、解构重组和关联融合，再以不同层次的语料供给科学基础模型和领域模型。

这里要把“来源覆盖”四个字读准。现有公开材料没有说1.5亿篇论文全文都已完成同等深度加工，也没有说它们已经进入某个模型的训练集。但即便只把这个数字理解为来源范围，问题也足够具体：如此大规模的论文记录，怎样跟上出版状态的变化？

这条供给链把一个熟悉的出版问题重新摆到了编辑面前：模型读到的究竟是哪一个版本？

编辑部很清楚，“已发表”并不等于一篇论文从此定型。

作者可能发现图表标注有误，期刊随后发布更正。研究结论受到质疑时，编辑部可能先发关注声明，调查完成后再决定撤稿或解除关注。预印本、作者接受稿和正式出版版本也可能同时留在网上，被不同平台收录。

对读者来说，期刊网页上的红色“Retracted”标记已经很醒目。对机器来说，网页上出现一则通知还不够。机器需要知道通知指向哪篇原文、属于更正还是撤稿、何时生效、有没有恢复，以及当前检索应该展示哪个版本。

Crossref为这类关系提供了一套已有的表达办法。按照其登记更新的做法，具有编辑意义的更正或撤稿通常应当发布为独立通知，取得独立DOI，再通过update-to等关系指向原论文。原文一端则可以得到updated-by关系。

这样做保留了原文、通知和二者的关系，也让机器能够读取。编辑部若只修改网页，或上传一份没有稳定标识的通知，外部系统很难准确匹配已经收录的记录。

Crossmark可以显示内容的当前状态，也能嵌入PDF，让早先下载的文件在被打开时仍有机会查询后来的更正和撤稿。但它并非一条自动完成所有同步的管道。Crossref明确提醒，成员需要及时、准确地登记更新，Crossmark标识本身不能构成保证。

这里还有一个现实缺口。部分撤稿没有由出版商及时报告给Crossref，Retraction Watch从出版商网站搜集、核对相关记录，补进了其中一部分。其数据在工作日更新，也已进入Crossref的REST API。不过，Retraction Watch同样不能被视为完整真值库，对更正、关注声明等类型的覆盖也弱于撤稿。

所以，一篇论文状态的变化，至少要走过这样一段路：期刊或出版商作出决定并登记，Crossref/Crossmark或Retraction Watch等基础设施汇聚，下游语料库重新抓取，再把更新匹配到库内版本。任何一段没有登记、没有覆盖或没有刷新，后面的系统都有可能晚一步。

语料库收到一条撤稿记录，工作才完成了一半。

它要先找到库内对应对象。DOI是最稳妥的连接点之一；没有DOI时，还可能需要结合题名、作者、期刊和年份匹配。若同一成果同时存在预印本、正式出版版和更正版，系统还要分清“同一文本的副本”和“有出版意义的不同版本”。匹配错了，可能给无关论文挂上撤稿状态；匹配漏了，旧记录仍会以普通论文身份被检索。

接下来是语料本身怎样记账。来源网址、获取日期、语料版本号、生成日期和变更日志，都决定一次更新能不能被复核。更正了哪些字段，新增了哪份通知，原文本是否保留，哪个语料批次受到影响，也应有可追踪记录。

撤稿论文也不宜从所有场景中消失。研究诚信和科学史研究仍可能需要它。语料库可以保留记录与状态关系，在一般知识检索中警示、降权或过滤，在特定研究用途下有条件开放。直接删除文本，也会抹掉撤稿发生过的记录。

截至7月21日，本次核到的敖仓官方公开材料介绍了清洗整编、三阶语料、质量控制、安全流通和运维，也提到语料已多批次、按需供给相关模型。公开材料尚未说明论文状态取自哪些权威来源、刷新频率多高、怎样建模版本关系，以及如何向已交付的下游发送增量变化。

这只能说明公开信息还没有到这一粒度，不能据此推定相关机制不存在。它留下的是一组应该被问清的问题：每个批次能否追溯来源和获取日期？撤稿、更正、关注声明与恢复如何编码？一次状态变化会生成怎样的增量包？收件方是否需要确认已经处理？

“多批次供给”意味着版本治理不能停在总库里。只要语料离开库内环境，更新就需要有收件人、有版本号，也要有回执。否则，语料库里已经改正，下游仍在使用旧批次，两边都可以声称自己掌握的是“高质量数据”，却说不清对应哪个日期。

讨论下游更新时，训练、微调和检索增强常被混成一件事。三者处理旧论文的难度差得很远。

检索增强生成，也就是常说的RAG，相对容易处理。论文通常以文档或文本块的形式存在索引中。状态变化后，系统可以更新元数据，替换相关文本块，重新建立索引，并在检索阶段过滤或降低撤稿记录的排序。更稳妥的做法，是回答生成前再查询一次当前出版状态。这样即使旧内容仍被保存，用户也能看到醒目的更正或撤稿提示。

但索引有副本，检索结果可能被缓存，引用链也可能仍指向旧文本。语料库发出补丁后，模型服务是否重建索引，仍要靠下游执行和反馈。

微调数据已经把论文变成问答、摘要、指令或领域样本。若微调尚未开始，可以替换数据集并重新生成样本；模型权重已经更新后，改单条数据库记录不会同步改掉参数。常见处理会涉及清理数据、开展新一轮微调、加入状态提示，随后重新评测。原论文如果只是局部更正，还要判断受影响的是哪条事实、哪组问答，不能把整篇文献粗暴地当成同一种问题。

基础模型训练更难。大量论文信息已经与其他文本混合进入参数，很难沿着一篇DOI准确找到并改写对应权重。重新训练代价很高，机器遗忘等方法也需要逐案验证效果。在线状态核验、检索过滤和回答警示可以降低使用风险，但这些外层措施不会自动清除参数中已有的信息。

一项2026年4月提交的预印本给出了一个直观提醒。研究者让三个离线开放权重模型判断161篇高关注撤稿论文。仅提供题名和摘要时，GPT OSS 120B、Gemma 3 27B和DeepSeek R1 72B分别在82%、84%和88%的案例中声称论文“未撤稿”。研究对象与敖仓无关，论文也尚未经过同行评议。它能支持的判断很有限：静态模型不能被假定已经记住论文后来的出版状态，联网核验会成为重要条件。

由此看，语料库向下游发送“某论文已撤稿”只是起点。RAG服务可以改索引，微调模型可能要重做数据和评测，基础模型则更多依赖训练批次升级与外部状态层。若交付协议只写“提供语料”，没有约定更新落到哪一层，同一份增量通知会得到完全不同的处理结果。

这件事离期刊编辑部并不远。语料版本治理的第一站，仍是出版者。

编辑部发布更正、撤稿或关注声明时，需要给通知稳定标识，补齐通知与原文之间的DOI关系，并更新原文元数据。网页标记、PDF水印和人能读懂的说明当然要保留，同时还要让聚合平台通过字段读懂。恢复论文状态时，也应登记新的关系，不能只把原来的红色提示撤下。

这会改变编辑部对“发完通知”的理解。通知上线只是面向读者的一步；DOI元数据是否登记、关系是否能从两端查询、第三方数据库是否已经抓到，决定机器端有没有收到。对于已被广泛收录的论文，编辑部还可以把状态传播情况纳入撤稿或更正后的复核，而非把责任止于本刊页面。

语料库一端承担另一段责任。它需要说明论文从哪里来、何时取得、属于哪个语料版本；定期核对更正、撤稿、关注声明和恢复状态；保存变更日志，并把受影响对象整理成可供下游处理的增量。更重要的是，通知不能止于“补丁已发布”，还要知道哪些RAG索引完成刷新、哪些微调数据等待重制、哪些训练批次只能先加外层警示。

1.5亿篇论文带来的冲击，当然来自规模。但论文越多，越不能把它们看成一次入库后就凝固的文本。今天有效，明天被更正；当前仍可引用，调查后也可能撤稿。模型读过多少，只能说明它见过多大的知识世界。语料能不能跟住出版记录的变化，才决定模型此刻拿出的那条知识，还应不应该被信任。