大模型更新得越来越快，但想回答“现在有哪些模型值得关注”，往往要在厂商发布页、技术报告、模型卡和多个公开榜单之间来回翻找。即使找到了分数，还要继续确认评测版本、测试口径、模型别名和数据来源。
于是我做了 知行录（leaderboard.cn）：一个面向中文社区的 AI 模型榜单与评测资料站。它不想用一张总榜替所有场景下结论，而是把分散的公开数据整理成一套可以继续追溯、筛选和比较的资料。
截至 2026 年 7 月 24 日，站内数据快照包括：
| 项目 | 数量 |
|---|---|
| 模型 | 211 个 |
| 基准评测 | 414 项 |
| 数据源 | 79 份 |
| 已发布排名领域 | 8 个 |
这些数字只是文章发布时的快照，网站仍会随着模型和公开资料的更新而变化。
为什么还要做一个排行榜
只看一项评测，很容易把“擅长某一道题”误认为“什么都强”；直接平均不同评测的原始分数也不合理，因为百分比、Elo、通过率和内部评分本来就不在同一把尺子上。
另一方面，厂商通常会优先公布自家模型表现较好的项目。同名基准在不同报告中，也可能使用了不同的提示模板、抽样子集、评判模型或推理配置。数字看起来可以横向排列，实际测试条件却未必完全一致。
因此，知行录在整理数据时遵循三个原则：
- 数据可溯：尽量保留原始报告、采集快照、评分单位和备注，方便回到来源核对。
- 横向整理：把分散在模型卡、厂商报告和公开榜单中的结果，统一关联到模型、基准和厂商。
- 谨慎比较：排名只描述已收录数据中的相对表现，不把它包装成模型在所有真实场景中的绝对能力。
先看榜单，再回到证据
首页按用途展示当前的前沿模型。除了总体榜，还有开放权重、本地部署、代码、科研、Agent、视觉和长上下文等领域。某个领域至少收录 3 项基准后才会在首页发布，样本不足的方向会继续等待数据。
首页同时展示各领域榜单、聚合基准数量和更新时间。
总体榜适合快速观察近期前沿，领域榜则更接近真实的选型问题：写代码时不必让视觉成绩主导结论，准备本地部署时也不必和无法下载权重的模型一起比较。
这里的“开源”是界面上的短标签，准确含义是开放权重。它只表示发布方提供了可获取的模型权重，并不自动代表训练数据、训练代码和许可证都符合开源软件或开源 AI 的完整定义。
排名是怎么计算的
知行录没有直接平均原始分数，而是使用 Bradley-Terry / Elo 配对评分方法：
在每一项基准中按成绩排序，把模型转换成两两胜负关系；同分按平局处理。
同一模型在同一基准有多个公开来源时，取其中的最佳成绩参与排名。
使用全部配对结果迭代拟合模型的相对强度，预期胜率沿用 Elo 的逻辑函数：
E = 1 / (1 + 10^((R_对手 - R_自己) / 400))只有一个或没有有效数据源的基准按 0.5 权重计入；聚合了大量真实用户投票的 Arena.ai 数据不受这项降权影响。
没有直接比较关系的模型组分别以 1500 为中心，避免凭空制造跨组差距。
每个领域的最高分会归一化为 100。因此，100 分的含义是“当前收录数据中该领域的相对第一”，不是正确率，也不代表模型有 100% 的能力。不同领域的分数同样不宜直接横向比较。
这套方法能把不同量纲的评测放到一张相对排名中，但它仍然有边界：它只看名次、不看分差；无法消除厂商报告的选择偏差；对数据源可靠性的权重目前也比较粗。榜单适合用来发现候选模型，不适合代替自己的业务评测。
从一个名次走到模型全貌
排行榜只是入口。每个模型都有独立详情页，把规格、能力、评测和部署信息放在一起：
- 发布时间、参数量、上下文长度、输入输出模态、许可证与官方链接；
- 总体及各领域排名、数据覆盖范围、代表评测和对应来源；
- 官方 API 的输入、缓存命中和输出价格，并保留原始货币及阶梯计价口径；
- 在资料齐全时提供模型文件、显存与存储估算、推理引擎配置和启动命令；
- 前代、后继、同系列模型，以及评测中出现的别名或运行模式。
模型详情页把排名放回规格、数据覆盖和原始评测之中。
如果需要做实际选型，还可以使用这些工具：
- 历史趋势：按模型发布时间观察开放权重与闭源模型的前沿变化；
- 本地模型：根据浏览器可见的硬件信息和 Q4、Q5、Q8 量化内存估算，推荐当前机器可能运行的高评分开放权重模型，检测结果只在浏览器本地计算；
- 模型对比：最多并排比较 4 个模型的规格、能力、价格和各领域评分；
- 全局搜索：从模型、厂商、基准评测和数据源之间快速跳转。
给榜单再加一点可玩性
站内的“榜单工坊”可以直接载入任一领域榜单，也可以粘贴自己的评测结果，生成经典、柱状图或紧凑三种样式的排行榜卡片。标题、颜色、坐标起点和条目都能调整，最终图片在浏览器本地生成，不会上传自定义数据。
榜单工坊既能分享站内榜单，也能为自己的基准测试制作卡片。
数据背后的工程
知行录的前端使用 Next.js 与 TypeScript，后端使用 FastAPI 与 PostgreSQL。模型与评测数据通过结构化录入和独立采集流程进入系统，再经过标准化、模型身份映射和审计。
身份映射是数据处理中很重要的一层。同一个模型在不同来源里可能带有厂商前缀、日期后缀、Thinking 模式或服务商别名。如果把它们当成多个模型，排名和数据覆盖都会失真；如果贸然合并，又可能把实际不同的模型混在一起。站内会将有明确证据的别名关联到 canonical 模型，无法确定的身份进入隔离状态，不参与前沿排名。
生产站在构建时从 API 导出一致性数据快照，预生成页面后由 Nginx 提供静态内容。这样既保留了结构化后端便于持续维护，也让公开页面保持简单、快速，并能完整生成模型、厂商、基准和数据源详情页。网站同时提供中文与英文界面、深浅色模式、RSS 和可分享链接。
写在最后
我希望知行录解决的不是“替所有人选出唯一最强模型”，而是让找模型这件事少一点信息搬运，多一点可验证的依据：先从排名发现候选项，再沿着模型、评测和数据源一路核对，最后回到自己的任务做判断。
可以从下面几个入口开始：
数据纠错、缺失模型和功能建议，都可以通过页面右下角的“反馈”入口提交。群峰之上，仍有未名之山。