43天17040条AI信号：趋势榜单不会告诉你的四个真相

运行一条自动管线，从公开渠道持续采集AI信号43天，累计获得17040条数据，日均约398条。这个数据集最初只是为了支撑一份每日摘要，但最后发现数据本身比摘要更有意思——尤其是它无法告诉你的那些事。

以下是构建任何AI趋势应用之前，最值得先知道的四个发现。

一、1493个被追踪模型中，只有23个有足够历史数据计算趋势

这是最核心的问题。采集器抓取的是趋势榜单——GitHub trending、Hugging Face trending等等。但榜单本身是轮换的：今天排第4的模型，明天可能就消失了，历史记录也随之丢失。

实际结果：

类别	追踪数	曾入榜	有≥20天历史
Hugging Face 模型	1493	228	23
GitHub 仓库	63	63	14

也就是说，当某个工具向你展示一个AI模型的"势头（momentum）"时，应当追问它的基线是什么。如果一个实体只被观测到两次，那么所谓"趋势"就只是两个点和一条直线。

作者的选择是：输出 unranked 并附上原因，而不是用看似合理的数字填补空白。JSON中的每一行要么有可推导的数值，要么带有明确的"未排名，原因如下"。这个决定牺牲了很多"吸睛"数字，但依然正确——一个编造的排名，对下游消费者来说和真实排名无法区分。

如果你要自己构建，解决方案是：追踪一个固定集合（按稳定指标取前N名，每天记录），并与轮换的趋势榜单并行。轮换榜单负责发现新事物，固定集合负责时间序列。没有后者，两者都得不到。

趋势榜单（trending list）是GitHub、Hugging Face等平台按近期活跃度动态生成的排行，通常基于下载量、星标增速、fork 等短窗口指标滚动计算。它的本质是「当日快照」，并不保证某个条目次日仍在榜；一旦跌出榜单，采集器就再也拿不到它的指标读数。这带来一个致命后果：对榜单驱动的管线而言，历史序列是幸存者偏差的产物——你只留下了那些持续热门的实体，而它们恰恰是变化最慢的一批。因此，想让榜单数据支持时间序列分析，必须把「被发现」和「被追踪」拆成两件事：榜单负责发现，另行维护一份固定实体清单负责逐日记录。这也是文章反复强调「轮换榜单 + 固定集合」并行采集的根本原因。

二、头部实体稳定得无聊，真正有趣的信号是"流动"

本来预期领先者会频繁变动，但48天每日快照显示：

• Hugging Face下载量最大变化：−11.7%（moonshotai/Kimi-K3）
• 同列最大增长：+7.6%（deepseek-ai/DeepSeek-R1）
• 前8名中其余全部在−5%到−10%之间
• GitHub stars，头部仓库：48天内仅**+0.08%到+0.54%**

排行榜几乎是静止的，而且大多数大模型下载量缓慢衰减。增长是例外，不是常态。

同时，单日变化（2026-10-12→2026-10-13）却是这样的：2个模型进入，41个不再出现，201个排名发生变化。 真正的运动在边缘，不在顶部。

如果要做告警，应该针对进入和退出，而不是顶部的排名移动。"这个模型首次出现／这个模型消失了"所携带的信息量，远大于"上升3位"。

**排名流动（rank churn）**指的是榜单条目在相邻两次快照之间进入、退出与位次变化的总量。它是衡量榜单「新陈代谢速度」的指标，与排名绝对值无关。经验上，榜单顶部往往被少数强势实体长期占据，位次波动被压缩在几个百分点内；而榜单中后段则高频替换。这意味着基于「排名上升N位」的告警会在顶部产生大量噪声或干脆沉默，而基于「首次进入 / 不再出现」的告警能更早捕捉新事物。计算流动时需注意口径统一：是统计全体实体的位次变化，还是只统计两次都在榜的交集？两者含义完全不同，混淆会导致指标随榜单长度波动而失真。

三、大部分数据量来自单一来源，而它并不是最有意思的那个

43天内的来源分布：

来源	条数	占比
热点聚合	6455	38%
arXiv	2551	15%
Hugging Face	2107	12%
竞技场榜单	2041	12%
硅谷新闻	1198	7%
硬件/芯片	1089	6%
GitHub	860	5%
YouTube	739	4%

仅聚合来源就占了三分之一以上。它采集成本低，而且大部分内容与主要来源重复。

真正产出摘要的四个来源（GitHub、Hugging Face、YouTube、硅谷新闻）只占29%的数据量。如果按条目数给来源排名，你会优化最喧闹的那个，而不是最有用的那个。作者最终追踪的是每个来源的产出率和去重率，而不是原始数据量——数据量是那种让管线看起来很忙、实际什么也没产出的指标。

**去重率（dedup rate）**指某来源采集到的条目中，与其它来源重复的比例。聚合类来源（如热点聚合、newsletter）天然依赖二次搬运，条目量大但原创信息密度低，去重率往往很高；而一手来源（GitHub、Hugging Face、arXiv、官方博客）条目少，却是信息的第一落点。因此评估来源价值时，更合理的指标是「去重后独立条目数 ÷ 采集成本」，而非原始条数。若按条数分配算力，聚合源会挤占一手源的配额，管线看起来数据量庞大，实际上被同一批信息反复填充。这也是文章提到的「产率 × 去重率」二元评估法的由来。

四、从原始快照推导数字，否则就别发布

每一个发布的推导数字（排名、排名变化、7天势头、arXiv分类中的位置）都由自动化审计从原始快照重新计算，审计还会将渲染页面与JSON接口进行对账。如果两者不一致，那就是失败，不是舍入误差。

原因有两点：

1. 推导数字会静默漂移。 写入时计算并存储的排名，是来自过去的声明；重新计算后，才是你能为之辩护的声明。
2. 它能抓住你自己的bug。 审计已经发现过诸如"内容质量"检查在一个正文实际为空的页面上通过，以及某日版本与同日API响应不匹配之类的错误。

作者的原则是：宁可发布一个能重新推导的无聊数字，也不发布一个无法验证的激动人心的数字。

**推导数字（derived metric）**指并非直接观测、而是由原始数据计算得到的值，例如「7天势头」「排名变化」「分类内位次」。它与「原始快照」的关系，类似于报表与账本。推导数字的隐患在于：一旦写入阶段的计算逻辑有 bug 或口径变更，存储值会静默过期，而下游消费者无法分辨真伪。审计的做法是保存不可变的原始快照，每次发布前用当前代码从快照重算全部派生指标，再渲染结果与 JSON 接口对账——两者不一致即判失败而非容差。这套「可重放」原则的代价是重算开销，收益是任何数字都能追溯到一组具体的原始输入。

这套数据的公开方式

管线无人值守运行（每天采集4次，每日发布一期，每日自审计）。数据公开免费：

• 每日数据集（CC BY 4.0）：github.com/jiangzhangcc-glitch/ai-signals-daily，附带全量 signals.jsonl（全部17040行）
• 今日信号JSON：data.jiangzhang.ca/signals4/api/today.json
• 相对上次快照的变化：.../api/changes.json
• 带引用的模型/仓库排名：.../api/models.json、.../api/repos.json
• 作为Claude/Cursor的MCP工具：signals-api-mcp

一个值得注意的坑：如果用裸 Python-urllib 的User-Agent（或者不带），会从CDN边缘收到403——请求根本不到达服务器，服务器日志什么都看不到。看起来就像一个挂掉的API。requests、httpx、aiohttp、Go、node-fetch、axios和curl都没问题。在示例里记得设置User-Agent。

如果需要超出免费层的规模（8个来源而非4个、每天4次更新、稳定密钥后的完整历史），那是付费feed的范畴。

如果也在构建类似的东西，作者想真诚地知道：你如何处理榜单轮换问题？这是最被低估的部分。