Opus 5.5被悄悄削弱了吗？LiveNerf基准实时追踪模型能力

一个持续困扰用户的疑问：模型是否被"降智"

AI社区长期存在一种普遍怀疑：大模型在发布之后会被厂商悄悄削弱能力，业内俗称"nerf"（削弱）。用户常常抱怨"这个模型最近变笨了"，但这类抱怨往往停留在主观感受层面，缺乏可量化的证据支撑。

针对Anthropic旗下的Opus 5.5，一位Reddit开发者决定用数据说话。他推出了一个名为 LiveNerf 的开源基准项目，从模型发布第一天起就持续追踪其表现，试图回答一个简单却棘手的问题：Opus 5.5到底有没有被削弱？

LiveNerf 是如何工作的

这个项目的核心思路是每日复测、长期追踪。作者每天重新运行一批独立基准测试，例如 GPQA（研究生水平的科学问答）和 SWE-bench（软件工程任务基准），并把结果绘制成图表记录在GitHub仓库中，形成一条随时间变化的能力曲线。

测试题目的挑选逻辑

值得关注的是题目选取方式。作者并非随机抽题，而是借助Claude来筛选出"Opus 5.5最容易出错"的那部分题目。这种设计意在提高灵敏度——如果模型能力真的出现下滑，那么它在薄弱环节上的表现会最先崩坏，从而更早暴露问题。

对照组与判定阈值

为了建立参照系，作者选择用上一代的 Opus 5 作为对照基准（control benchmark）。判定标准也相当明确：如果Opus 5.5在LiveNerf上的得分偏离超过 7.5分，就会被视为潜在的能力下降信号。

这套方法的价值在于，它把"模型变笨了"这种模糊的群体感受，转化成了一个有明确阈值、可长期验证的量化指标。

GPQA（Graduate-Level Google-Proof Q&A）是一套由领域专家设计的研究生水平科学题库，涵盖物理、化学、生物等学科，题目经过刻意筛选以确保无法通过简单搜索获得答案，是衡量大模型深度推理能力的主流基准之一。SWE-bench 则专注于软件工程任务，要求模型根据 GitHub Issue 描述直接生成可通过测试的代码补丁，被认为是评估模型实际编程能力（而非代码补全）的更严苛标准。两者都属于"高门槛、低天花板"的困难基准——在这类题目上，性能的细微波动更容易被放大，因此比通用基准更适合用于检测模型能力的边际变化。

目前的结论：暂未检测到削弱

截至作者发帖时，监测结果显示 尚未检测到任何nerf迹象。Opus 5.5的日常表现保持稳定，没有跨越那条7.5分的警戒线。

不过作者对自己的数据保持谨慎态度。他明确表示，需要到第10天才能建立起可靠的基线（baseline），而在第20天之前不会做出任何正式判断。这种克制的态度恰恰是这类监测项目最需要的——避免用几天的噪声数据得出草率结论。

"降智"是集体幻觉还是真实现象？

这个项目触及了AI社区一个反复出现的争论焦点：所谓的模型削弱，究竟有多少是真实发生的技术调整，又有多少是用户的心理预期在作祟？

作者对此有清醒的认识。他计划在未来一两周内，如果社区中"模型被削弱"的声音突然集中爆发，就再次公布LiveNerf的数据，用以检验这波抱怨"到底是集体歇斯底里（hysteria），还是确有数据支撑"。

这种把主观舆论与客观数据并置对照的做法，比单纯的争吵更有建设性。它至少提供了一个可以证伪的框架：如果数据没有波动而抱怨突然增多，那么问题可能更多出在用户的使用场景或预期变化上；反之，如果数据同步下滑，则厂商确实可能进行了某种调整。

这类监测项目的意义与局限

LiveNerf 代表了社区对AI厂商透明度的一种自发监督。在模型能力和服务质量高度不透明的当下，第三方持续追踪工具填补了一个重要的信任空白。

但也要看到它的局限性。单一开发者维护的项目，其题库规模、测试频率和方法论都可能存在偏差；用Claude来挑选"最难题目"本身也可能引入选择性偏差。此外，模型输出的随机性、API负载波动、温度参数等因素都可能影响单日成绩，这正是作者强调需要长期基线的原因。

对于关心Opus 5.5长期稳定性的开发者来说，这个开源仓库提供了一个值得持续关注的数据窗口。是否被削弱，最终还是要交给时间和图表来回答。

温度参数（temperature）是控制大模型输出随机性的核心超参数，数值越高输出越多样，越低则越确定性。在基准测试场景中，如果每次运行不固定温度，同一道题在不同日期可能得到不同答案，由此产生的分数波动会被误读为能力变化。此外，API服务端的负载均衡可能将请求路由到不同版本或不同硬件的模型副本，进一步引入噪声。这也是为什么严谨的持续监测项目需要控制随机种子（seed）、固定温度、并依赖足够大的样本量来平均掉单次测试的随机误差——在此之前，单日数据点的参考价值非常有限。