💻 computer science

The Reciprocal Impact of Science and Software: A Cross-Corpus Analysis of How Research Shapes Software and Software Enables Research

本研究构建了一个连接科学文献与软件仓库的大规模跨语料库图谱，以揭示尽管科学与软件通过不同且互补的影响层进行协同演化，但目前的测量方法仍然稀缺且对方法论的选择较为敏感，从而阻碍了对其相互影响做出确定性结论。

原作者： Audris Mockus

发布于 2026-07-07

📖 1 分钟阅读☕ 轻松阅读

原作者： Audris Mockus

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

请想象科学发现的世界是一座繁忙、喧闹的大都市。长期以来，这座城市一直被分割成两个几乎互不往来的独立区：

图书馆区（The Library District）： 这里是科学家发表论文的地方。衡量标准是人们借阅书籍（引用量）的数量以及作者的名气。
工作坊区（The Workshop District）： 这里是构建实际工具、代码和软件的地方。其衡量标准是 GitHub 上有多少人为项目“点赞”（stars）或有多少人进行“分叉”（forks）。

问题在于，这两个区使用的是不同的地图。一位科学家可能在工作坊里制造了一个革命性的工具，但图书馆却对此一无所知。反之，一篇在图书馆里声名显赫的论文，可能依赖于一个在工作坊里微小且隐形的工具，却从未被提及。

Audris Mockus 的这篇论文试图在两个区之间架起一座桥梁，以创建一个统一的、完整的地图，来展示科学究竟是如何运作的。作者称之为**“科学-软件供应链”（Science-Software Supply Chain）**。

以下是该研究结果的解释，通过简单的类比呈现：

1. 双向街道

研究人员连接了两个巨大的数据库：一个包含几乎所有的公开软件代码（World of Code），另一个是科学论文数据库（Semantic Scholar/OpenAlex）。他们从两个方向观察了这种联系：

方向 A（科学 $\rightarrow$ 软件）：哪些科学论文实际上塑造了科学家使用的工具？
- 令人惊讶的发现： 并不是那些拥有最高引用量的最著名论文在起作用。相反，被采用最多的工具是那些帮助科学家打包和组织其工作的工具（例如 “nf-core” 或 “Nextflow”）。
- 类比： 这就像一个建筑工地。最著名的建筑师（高引用的论文）可能会设计出一座美丽的建筑，但被每一支施工队使用的工具通常是脚手架和起重机（打包工具）。论文统计的是建筑师的名望，而软件统计的是脚手架的实用性。
方向 B（软件 $\rightarrow$ 科学）：哪些软件工具实际上促成了新的科学发现？
- 令人惊讶的发现： 那些促成最多科学发现的工具通常是隐形的。它们是像 PyTorch（用于人工智能）或数据可视化工具这样的“隐藏基础设施”。它们很少出现在论文标题中，但成千上万的其他项目都依赖于它们。
- 类比： 想象一座巨大的城市，每个人都在公路上行驶。你在新闻报道中只会看到汽车，而不会看到道路。但如果道路消失了，汽车也会停止行驶。这些软件工具就是道路。它们至关重要，但因为无处不在，所以没人会专门写篇论文说：“我今天用了一段路。”

2. “点赞”评分陷阱

在软件世界中，人们经常通过 GitHub 上的“点赞”（stars）数量来判断一个工具的重要性。研究发现，点赞数并不能很好地预测其实际用途。

类比： 想象一家餐厅。一个在社交媒体应用上有 500 个“赞”的地方，可能是一个人们为了拍照而去打卡的网红店。但一个只有 10 个“赞”的地方，可能是每天为 10,000 家其他餐厅供应面包的当地面包房。
研究结果： 研究发现，“点赞数”与“依赖关系”（即有多少其他项目实际使用了该代码）之间的联系非常微弱。一个拥有 150 个赞的工具可能被 9,000 个其他项目使用，而一个拥有 50,000 个赞的工具可能实际被极少使用。受欢迎程度并不等于实用性。

3. “隐形”的差距

研究人员尝试统计论文提及软件的频率。他们发现了一个巨大的鸿沟。

问题所在： 当科学家撰写论文时，他们通常在正文中间（“方法”部分）提到软件，而不是在正式的参考文献列表中。自动化工具往往会遗漏这些提及。
结果： 论文与所使用的软件之间的联系是“稀疏”且“嘈杂”的。这就像试图仅通过人们在聚会上大喊的名字，而不是通过查看实际的出生证明，来绘制一份家谱。由于数据如此不完整，研究人员无法给出一个单一、完美的数字来衡量软件对科学的影响程度。相反，他们展示了不同的测量方式会得出不同的答案，我们不能仅仅依赖于某一个数字。

4. 新型劳动者：AI 代理

研究还观察了一种新现象：AI 编码代理（编写代码的机器人）。

研究结果： 这些 AI 代理开始出现在科学软件项目中。它们目前还没有取代人类，但正在加入劳动力队伍。
谁在使用它们？ 这与科学的类型（如生物学对比物理学）无关。相反，AI 代理被用于快速迭代、活跃度高的项目。如果一个项目很年轻，且开发者正在疯狂编写代码，他们更有可能使用 AI 助手。这就像一家正在快速发展的初创公司，比起成熟稳健的工厂，更倾向于使用新的科技产品。

核心启示

这篇论文认为，我们应该停止将科学和软件视为两个独立的事物。

旧观点： 科学是论文；软件只是工具。
新观点： 科学是一个供应链。论文和软件是平等的产出。

要真正理解科学的进步，我们不能只计算引用量或“点赞”数。我们需要看到依赖关系——即支撑一切的隐形代码网络。正如一座城市需要了解其水管和电网，而不仅仅是著名的建筑一样，科学界也需要重视那些让发现成为可能的“隐形英雄”式的软件，即使没有人会专门为此写一篇论文。

简而言之： 在科学领域，最重要的工具往往是你从未听闻过的，而最受欢迎的工具往往是你并不真正需要的。为了解决这个问题，我们需要一张能将“图书馆”与“工作坊”连接起来的更好地图。

技术摘要：科学与软件的相互影响

问题陈述
科学知识与软件共同演化，但它们被记录在互不相干的账本中：软件记录在版本控制生态系统（如 GitHub）中，而科学记录在文献数据库（如 Semantic Scholar, OpenAlex）中。这种分离使得“科学-软件供应链”（S3C）变得不可观测。当前的指标未能捕捉到这种相互关系：文献计量学统计了引用次数，却忽略了软件的复用；而软件指标（星标、分叉）则无法反映学术影响力。此外，现有关于文献中软件提及的研究存在召回率低以及与实际制品关联不可靠的问题，且依赖性分析往往局限于单一生态系统，无法解决开发者身份识别问题。本文认为，如果没有一个全球性的、基于身份解析的论文与软件制品之间的链接，科学生产的溯源过程将保持不透明，从而阻碍风险管理（例如，识别“隐形英雄”依赖项）和高效的信用分配。

方法论
作者构建了一个类型化跨语料库图谱，将近乎完整的公开版本控制历史（World of Code, V2604）与文献语料库（Semantic Scholar 和 OpenAlex）联系起来。

数据源：
- 软件： World of Code (WoC) 提供提交（commits）、作者、项目以及项目间的依赖边（project-to-project dependency edges）。
- 科学： Semantic Scholar 和 OpenAlex 提供论文、引用和软件提及。
- 种子集： 来自 SciCat 数据集的 18,247 个科学仓库，该数据集通过 LLM 分类进行科学意图筛选。
图谱构建：
- 该图包含 6,980 万条边，分布在八个层级中，包括 depends on（软件到软件）、mentions doi（软件引用论文）、mentions repo（论文命名软件）以及身份桥接（same as，用于协调作者与 DOI 的一致性）。
- 身份解析利用 WoC 的作者别名映射和 ORCID/所属机构数据，将开发者链接到规范身份。
影响力度量（相互关系问题）：
- RQ1 (科学 $\to$ 软件)： 衡量论文对软件的“触达范围”。对于一篇论文，这是引用它的不同科学仓库的数量。对于一个作者，这是其论文所驱动的仓库的触达范围。
- RQ2 (软件 $\to$ 科学)： 衡量软件对科学的“赋能作用”。
  - 严格度量： 命名了某个仓库的论文（稀疏， $n=137$ ）。
  - 代理度量： 生态系统影响力，定义为反向 depends on 入度（依赖于该仓库的不同项目数量）。由于直接的“论文-软件”通道过于稀疏，难以进行有效排序，因此使用此项作为科学赋能的代理指标。
验证：
- 内部验证： 通过比较两个独立的提取器（Semantic Scholar 全文 vs. OpenAlex 摘要）来评估召回率。
- 外部验证： 使用留出的 Softcite v2 金标准语料库（人工标注的生物医学/经济学提及）来界定召回率并识别结构性偏差（例如，方法部分提及 vs. 摘要提及）。
- 三角测量： 在多个锚点（SciCat, JOSS, Softcite 工具名称, CRAN/conda 注册表）上进行分析，以测试鲁棒性。

关键结果

截然不同的生态系统阶层： 两种影响方向呈现出基本不相交的生态层级。
- 科学 $\to$ 软件： 由复现性/打包层（例如 nf-core, Nextflow, Singularity, Bioconda）和序列分析工具（SAMtools, STAR）主导。这些工具被大量流水线（pipelines）整体采用。
- 软件 $\to$ 科学 (代理指标)： 由隐形的 ML/数据科学基础设施层（例如 PyTorch, seaborn, NLTK, einops）主导。这些工具具有高依赖入度，但很少被直接作为赋能基质进行引用。
- 学者： 支撑该生态系统的作者主要是工具制作者（例如，Paolo Di Tommaso 对应 Nextflow，Heng Li 对应 SAMtools）。
度量指标的弱耦合：
- 复用 vs. 流行度： 依赖入度与 GitHub 星标仅呈弱相关（Spearman $\rho = 0.36$ ）。高依赖工具如 cloudflare/circl（9,459 个依赖项）可能只有极少的星标（150 个）。
- 复用 vs. 引用： 软件复用与学术引用的相关性是脆弱且对缺口敏感的。
  - 当通过命名仓库的论文进行配对时（ $n=137$ ），相关性无法检测（ $\rho = 0.05$ ，置信区间跨越零）。
  - 当通过仓库声明的 DOI 进行配对时（ $n=1,067$ ），出现了微弱的正相关（ $\rho = 0.13$ , CI [0.07, 0.19]）。
  - 作者得出结论，相关性的正负号是由于所容忍的链路缺口不同而产生的伪影；鉴于当前数据密度，得出强脱节结论尚显过早。
链路限制：
- 召回率较低： 外部金标准基准显示，该图谱对方法部分提及的召回率接近于零。该图谱捕捉的是一个“薄且具有结构性偏差的切片”（摘要、落地页、参考文献），而非完整的论文方法文本。
- 种子集偏差： SciCat 种子集仅覆盖了 WoC 中约 11% 的经人工标注的工具，且与 JOSS 仓库的重叠度较低。通过多个锚点进行的三角测量证实，没有任何单一种子集能捕捉全貌。
AI 编程智能体 (AI Coding Agents)：
- 研究识别出 58 个采用了 AI 编程智能体的科学仓库（2023+）。
- 采用行为与开发强度（活跃月份、提交量）和相对年轻度相关，但与领域、流行度（星标）或团队规模无关。
- 关于采用后的结果研究因时间不足（影响存量如引用/依赖尚未积累）而暂缓。

意义与主张
本文将其贡献定位为可行性证据，而非确定性的统计。

概念转变： 它成功地将科学生产重新定义为一个论文与软件作为对等商品的供应链，证明了构建一个全球性的、基于身份解析的“物料清单”是可行的。
方法论洞察： 它证明了从不同方向阅读同一个全局图谱会揭示出截然不同且弱耦合的层级。至关重要的是，它表明引用计数和流行度（星标）无法替代基于依赖关系的复用作为衡量科学影响力的指标。
局限性： 作者明确指出，由于链路缺口（选择偏差、召回率问题）的存在，目前的量化耦合程度过于敏感，尚不足以支持强因果关系主张。相关性的“正负号”会根据配对方法的变化而改变。
未来用途： 构建的图谱提供了必要的底层结构，用于追踪新兴现象（如 AI 智能体），并最终管理供应链风险（例如，识别目前在文献计量学中不可见的“隐形英雄”库）。

本文结论认为，虽然目前的链路密度不足以进行精确的点估计，但研究结果的方向性是稳健的，足以证明将软件感知、基于依赖关系的指标纳入“科学学”（science-of-science）工具箱的必要性。