可调参数的世界大学排名：把评价标准交还给用户

大学排名通常给人一种确定性：一张表、一组分数和一个不容置疑的顺序。但任何排名都隐含着价值判断——研究成果、资金实力、师资力量和校友影响究竟哪个更重要，不同用户很难给出相同答案。

这个项目尝试换一种思路：不只发布一份固定榜单，而是把评价维度和权重开放给用户，让他们生成符合自身关注点的大学排名。

五个维度，一套可以重组的评价体系

产品围绕五个一级维度组织综合排名：声誉、学术能力、资金、师资力量和校友影响力。每个维度背后又由更具体的数据构成：

• 声誉参考大学在维基百科知识网络中的多层引用关系；
• 学术能力结合论文网络的 PageRank 与学者 H-index；
• 资金同时考察学校资金规模和生均资金；
• 师资力量结合师生比与教师数量；
• 校友影响力综合校友数量、人均指标和知识网络中的引用关系。

用户可以按 5% 的步长调节各项权重。如果权重总和不是 100%，系统会按相对比例重新归一化；如果所有维度都为零，则不允许提交。最终得分还会经过标准化处理，同分学校共享同一名次。

这套交互的意义在于让排名更可解释：用户看到的不再只是结果，还能理解结果如何随评价标准变化。

原始指标怎样变成可加权分数

源码显示，系统并没有用一种统一公式处理所有指标，而是按数据分布选择四种标准化方式：

• 百科链接数、H-index 和资金等长尾计数使用 log10(x + 1) × 100 / log10(max)；
• 论文 PageRank 先取八次方根，再除以样本最大值并映射到 0—100，以强力压缩头部差距；
• 师生比等比例指标直接用 x / max × 100；
• 已经生成分数的数据保持原值。

这里的 max 来自参与计算的学校集合。若先按国家筛选再重新取最大值，同一学校在不同筛选条件下就可能得到不同标准化分数；如果先对固定全球母体标准化，再筛选，则分数可跨视图比较。现存代码把取数、筛选和计算放在大型控制器中，无法仅靠方法名确认所有版本都遵守同一顺序。这是重建时必须冻结的口径。

综合排名的一版实现接收十张“学校—分数”映射：声誉独占一级权重；学术内部按论文 PageRank 70%、教师 H-index 30% 分配；资金和人均资金各占资金维度的一半；师生比与教师数按 70%/30%；三个校友信号按 30%/30%/40%。另一版扩展到十四项，将论文数量、师均论文、获奖、头部校友和人均校友信号加入计算。它不是简单加字段，而是改变了每个维度内部的贡献结构。

学科排名还有缺失数据降级逻辑：获奖数据为空时，校友维度在人物数与 H-index 之间按 70%/30% 重分；如果其中任一关键集合也为空，整个校友贡献会归零。这个规则避免把不存在的数据当作零分，却也意味着不同学科可能使用不同的实际公式，界面如果不返回“本次采用的子权重”，用户无法解释横向差异。

下面的源码节选（已脱敏）来自十项指标版本的权重组合。变量分别对应五个一级维度；数据读取和返回包装已省略，但计算顺序保持原样：

ArrayList<Double> weights = new ArrayList<>();
weights.add(reputation);
weights.add(academic * 0.7);
weights.add(academic * 0.3);
weights.add(funding * 0.5);
weights.add(funding * 0.5);
weights.add(faculty * 0.7);
weights.add(faculty * 0.3);
weights.add(alumni * 0.3);
weights.add(alumni * 0.3);
weights.add(alumni * 0.4);
for (String university : metrics.get(0).keySet()) {
  double score = 0.0;
  for (int i = 0; i < metrics.size(); i++) {
    if (metrics.get(i).get(university) != null) {
      score += metrics.get(i).get(university) * weights.get(i);
      result.put(university, score);
    }
  }
}

PageRank 的实现与数值风险

论文引用图以“论文—被引论文列表”存入内存。每轮计算把当前分数按出度均分，以 0.8 的停留概率传给被引节点，再为每个节点加入 (1 - 0.8) / N 的随机跳转项。学校的论文影响随后按作者顺序权重汇总，学者 H-index 则先对作者打分，再累加到学校。

这段原型代码留下两个会改变结果的细节。没有出边的悬挂节点把下一轮贡献直接置零，没有把概率质量重新分配给全图；迭代停止条件比较的是有符号差值，并使用“残差仍大或轮数不超过 100”的组合，因此至少运行百轮，却不能保证以绝对残差正确收敛。八次方根标准化缓解了 PageRank 长尾，却不能修复底层质量流失。

这些问题不能简单归结为“旧代码风格”。排名产品一旦公开，数值实现就是方法定义的一部分。可复现版本应使用小型已知图验证质量守恒、悬挂节点和收敛，再保存每次运行的数据快照、图构造规则及残差。

从榜单扩展为大学信息产品

项目最初聚焦全球综合排名和权重调整，随后逐步增加国家与地区筛选、学科排名、学校搜索、中英文切换和分页。大学详情页则整合了简介、基本信息、校徽、校园图片、地图、课程、申请要求、录取信息、相关新闻和社交媒体等内容。

前端使用 Vue 2 构建，并分别提供桌面端和移动端组件。界面同时适配中文与英文环境，并根据访问环境选择不同地图服务。后端以 Spring Boot、MyBatis 和 JWT 鉴权为基础，对外提供排名列表、学校详情和地区列表等接口。

排名请求不是查询一张提前排好的静态表。接口会接收五个维度的权重，以及国家、地区、学科和学校名称等筛选条件，在服务端重新计算并分页返回结果。代码中还保留了综合排名、文理学院和学科排名的不同处理路径。

代码历史还保存了一个更早的 Java 排名快照。大学、商学院、医学院、电影和图书等榜单分别由独立类处理，并连接百科类别、人物和学校数据。它证明可组合排名并非从最终网站突然出现，而是从多个垂直榜单实验逐步收敛而来。早期实现以根目录脚本和数据库计算为主，后期才形成 Spring Boot API 与 Vue 前端的清晰边界。

这种收敛并不彻底。后端同时保留三代排名控制器和多套数据管理类；综合榜、文理学院榜和学科榜各自组合指标。两个文理学院版本甚至忽略请求中的权重，分别写死 20/35/20/5/20 与 20/40/15/5/20。若没有显式方法版本，相同请求在不同入口下可能含义不同。

围绕大学详情的数据补充则采用多个薄适配器：Node.js 与浏览器自动化采集教育榜单，Python 工具补充社交账号资料，百科网络程序计算学校和人物关系。按来源拆分便于快速试验，但实体主键和字段契约没有集中管理，最终把匹配压力留给后端和人工测试。

真正困难的是把同一所学校认出来

项目后期的问题记录揭示了数据产品最昂贵的一面：来自不同来源的数据并不会自然对齐。

同一所大学可能有中文名、英文名、旧名、缩写和重定向名称。名称稍有差异，校徽、地图、申请要求、录取分数或校友 H-index 就可能被匹配到错误学校，或者完全无法展示。历史记录中还出现过同名大学混淆、地区字段不统一、繁简体混用、坐标异常和学校详情缺失等问题。

其中一个典型案例来自校友学术影响力：采集流程先从维基百科获取校友及学校关系，再到学术数据源查找 H-index。如果人物页面没有学校信息，整条关联链就会断开，即使对方是高影响力学者也可能被遗漏。

这说明排名算法只是最终一环。更基础的能力是建立稳定的大学实体主键、维护多语言别名、记录来源与置信度，并允许人工校正冲突。否则，算法越复杂，只会更精确地放大底层数据问题。

从快速上线转向集中质量治理

项目在 2019 年 4 月开始集中迭代，先完成基础排名和英文版本，5 月围绕筛选、调参和展示细节进行优化。6 月至 7 月进入密集测试期，问题重心明显转向学校详情与数据一致性。之后的代码记录还出现了移动端、文理学院版本和持续部署配置。

Jira 共保留 83 条相关事项，其中 59 条为故障。最终有 75 条处于“完成”或“关闭”状态，仍有 6 条待办、2 条处理中。故障数量并不只是质量不佳的信号，它也说明团队进入了真实数据逐校核验阶段；地图、图片、别名和申请要求这类问题，往往只有在产品被实际浏览时才会集中暴露。

项目留下的经验

• 可调权重让排名方法更加透明，但必须同时解释指标来源、标准化方式和数据缺失如何处理。
• 多来源数据项目应先建设实体解析层，不能长期依赖字符串直接匹配学校或人物。
• 中英文不只是界面翻译，还涉及名称体系、地区口径、字段结构与内容来源的整体本地化。
• 详情页的数据丰富度会显著增加质量治理成本，应为每个字段保留来源、更新时间和缺失状态。
• 自动化测试应覆盖权重边界、语言切换、分页与筛选组合；这些交互状态曾产生多项关联故障。
• 排名响应应返回每项原值、标准化值、实际子权重与贡献值，不能只返回总分。
• 标准化母体和方法版本必须固定；筛选条件不应悄悄改变同一学校的基础分。
• PageRank 应用小图基准测试悬挂节点、质量守恒和绝对残差收敛。

证据边界

现有证据包括 DXPM 的 83 条 Jira 事项、DXPMDATA 的 1 条数据待办、18 篇 Confluence 页面、前后端两个主仓库，以及早期排名和多来源补充工具。后端主仓保留 8 次提交，前端主仓保留 70 次提交；前端可追踪到多个版本分支，提交时间延续至 2020 年 5 月。数据待办专门记录了维基页面缺少学校信息时，部分校友 H-index 无法关联的问题。

文档曾描述产品覆盖 90 多个国家和地区、接近 2000 所大学，并记录英文版本已经上线，但当前材料不足以独立核验实际访问量、完整学校数量或长期服务状态。方法文档、API 示例与代码中的默认权重也存在版本差异，因此本文只确认五个评价维度和可调权重机制，不把某一组默认比例表述为唯一最终标准。