中心性不等于活力：警惕PageRank在依赖图中的误用Centrality is not vitality

过去几周里，我深入研究了《周末在伯尼家》和《开源的误测》背后的数据，反复遇到同一个指标：将 PageRank 应用于包依赖图。几乎每篇试图对依赖图进行量化分析的学术论文都会用到它，通常将其作为“关键性”、“重要性”或“中心性”的全部定义。它在各种图库中都有体现，每个节点只产生一个数值，且图的表面结构与 PageRank 最初设计的网页结构相似，因此当人们需要一个默认的中心性度量时，往往会选择它。

Pfeiffer 在 MSR 2021 年发表的关于 PageRank 和卡车因子的论文、Mujahid 等人 ASE 2023 年发表的关于推荐 npm 包替代品的论文、Tsakpinis 和 Pretschner 2024 年对仓库可访问性的研究、Chowdhury 和 Abdalkareem 的 npm trivial-packages 论文，以及最近对 Maven Central 拓扑结构的研究，都将 PageRank 作为首要信号。过去五年中，大量生态系统图相关的工作也属于这一范畴。

依赖图是映射开源生态系统实际连接和交织方式的最强结构，这也是 ecosyste.ms 目前索引了数十个注册中心和数亿个源代码仓库中约 250 亿条依赖边的原因。过去十年的大部分工作都建立在这些图之上，PageRank 只是人们在图上进行计算的众多指标之一，其信息量远不如学术文献所暗示的那样丰富。

PageRank 最初是为一种边代表推荐、用户通过点击链接在节点间移动（偶尔会因无聊而随机跳转）的图而设计的。这两种假设在翻译到依赖图时均不成立。Borgatti 的《中心性与网络流》指出，每种中心性度量都编码了对事物如何在网络中流动的假设，若重用的流动过程与领域不匹配，则产生的数值将无法合理解释。

添加依赖意味着消费者代码需要目标提供的内容，但声明并未包含消费者是否审查过目标、对其形成意见，甚至是否见过其源代码的信息。许多传递性依赖在消费者项目中根本无人知晓。

解析过程通过求解约束问题而非遍历图来完成，包以集合形式被选中，模拟无聊冲浪者跳转到随机页面的阻尼因子在 npm install 或 cargo build 中并无对应物。此外，依赖图在解析方向上大多是无环的，因此 PageRank 在网页上表现良好的平稳分布直觉在此几乎无法发挥作用。

该数值衡量的是什么

无论何种情况，计算该数值都是可行的：输出结果明确定义，且对入链单调递增，具备中心性评分应有的所有属性。更困难的问题在于它最终描述的是什么——大致上是节点在图中的位置。读者往往将其视为某种更深层含义的替代品，例如包的“重要性”、风险、使用量，或是否仍有人维护。

一个健康的软件包可能因为直接依赖它的其他包正在衰落，从而传递给它更少的中心性，所以中心性排名中大部分的变化都来自与该软件包无关的外部因素。

跨生态系统的比较会遇到另一个问题，即数值不在同一个尺度上。PyPI 的惯例发布一个软件包，而 npm 的微包文化则发布三十个；一个 Rust 工作空间可能包含四十个相互引用的 crate。因此，名义上等效的项目的 PageRank 值会因打包约定本身而产生数量级的差异，这使得不同注册表的绝对数值即使使用相同的算法也无法比较。

该指标有时被报告为趋势而非绝对值，而在此情况下，其严谨性大多消失殆尽。中心性的变化与声明的依赖项趋势一致，而这两者又与下载量趋势同步。声明依赖项的数量所传达的信息与 PageRank 趋势完全相同，无需计算特征向量——这正是 ecosyste.ms 在此类分析中所采用的方法。

四个问题，一个标量

将关于软件包的多个不同问题折叠成一个标量存在范畴错误：如果它消失会造成多少影响（关键性）、依赖它所带来的风险（暴露度）、是否还有人维护该账户（活力），以及你能否轻松替换它（可替代性）。

PageRank 告诉你的是图中节点的位置，这是关于图的属性而非软件包本身的属性，而这个位置仅部分回答了上述四个问题中的第一个，对其他问题几乎毫无涉及。

我在《周末在伯尼家》中提到的那些软件包在中心性方面得分都很高，因为一个已停止更新但拥有稳定入链和数百万依赖项的软件包具有很高的 PageRank：伯尼的问题在于缺乏活跃度而非入链数量。fast-deep-equal、fast-json-stable-stringify、utils-merge 和 require-directory 在 npm 的任何中心性度量中都位列前百分之几，并且即使最后一个维护者提交后数年，它们仍将保持这一位置。

根据 bernies.db 的运行结果，在十六个生态系统中，约有 12% 的依赖最多的软件包已被确认死亡，另有 19% 未经测试，因为没有人提交 issue 或 PR 来验证是否有人仍在维护，这意味着图的上部大约三分之一处于某种“伯尼状态”。

一个实际案例

Mujahid 等人发表的《Where to Go Now? Finding Alternatives for Declining Packages in the npm Ecosystem》一文基于 PageRank 构建了一个真实的推荐系统，其做法正体现了这种范畴错误。该方法利用随时间变化的 PageRank 趋势来标记正在衰落的软件包，然后推荐那些 PageRank 未下降的软件包作为替代方案。

作者列出的四个选择标准（源包衰落、目标包未衰落、近期迁移证据、由流行项目执行迁移）都是图位置信号或消费者行为信号，并未检查目标包是否有权发布的人是否对 issue 或 pull request 作出响应。一个原本安静的包可能已沦为“伯尼”，但仍能通过测试，导致推荐系统将项目从一个已知死亡的源包路由到一个同样不再维护的目标包。

推荐某个包作为迁移目标时，其依赖项数量也会随之增加，而 PageRank 趋势也随之上升。下一次模型运行时，该包的分数会因这一变化显得更具吸引力。然而，这些循环过程在仅基于图位置构建的指标中是不可见的——因此，推荐系统可以无限次地将 Bernie 推来推去作为答案，而分数却毫无察觉。

Abandabot 采取了不同的路径：它的设计承认，仅凭图信号无法判断被废弃的依赖项是否重要，而是利用语言模型来推理其对使用该项目的影响。它向模型提出的问题关注的是影响而非维护者的存在，但至少在设计上承认了图位置本身不足以独立回答问题。

依赖图之所以存在，是因为有廉价、丰富且机器可读的数据支持，因此能够用图操作表达的问题才会被提出，无论这些问题是否真正回答了人们关心的问题。这种模式在《周末在伯尼家》和其他关于误测的文章中反复出现。PageRank 在这一领域备受推崇，并非因为它准确反映了依赖图的实际运作方式，而是因为相关数据易于获取。